Why Wallet Choice and Interoperability Matter in SEDI

Utah's SEDI framework, enacted through SB 275, requires that the state issue credentials using open technological standards that are publicly available and free from licensing fees and patent restrictions (Utah Code 63A-20-301(2)(e)). That statutory requirement is the foundation for an open ecosystem. But an open ecosystem does not automatically follow from a statutory mandate for open standards.

A program can technically use published open standards, issue credentials in documented formats, and still make it practically impossible for holders to change wallet providers, for new verifiers to join without vendor-specific integrations, or for credentials issued in one jurisdiction to function in another. Standards compliance is a necessary condition for interoperability. It is not sufficient. What fills the gap are governance, conformance certification, and architectural choices that either reinforce or undermine the rights the statute enumerates.

Wallet Choice in Statute vs. Wallet Choice in Practice

SEDI's Digital Identity Bill of Rights enumerates a right to choose what identity attributes are disclosed and prohibits government entities from compelling use of any particular digital form of identity assertion. The ACLU specifically praised Utah's decision to create "an open wallet ecosystem" that prevents Apple, Google, and Samsung from monopolizing digital wallet control.

Those protections are meaningful. But they address wallet coercion at the holder level, not structural lock-in at the ecosystem level. A resident who cannot change wallet providers without losing access to their credential, or who cannot use their credential at a new verifier because that verifier integrated only with a specific wallet vendor, is experiencing a practical restriction on wallet choice even if no statute formally compels them.

The statutory definition of a "personal digital identifier" points toward what real portability should look like. Under 63A-20-201, a personal digital identifier must be unique, created by the individual, mathematically provable to be under the holder's control, and "transportable to technical infrastructure of the holder's choosing." That transportability requirement is the statutory hook for genuine wallet portability, as distinct from the weaker form of wallet choice that merely prohibits government compulsion.

The Gap Between Standards and Interoperability

Interoperability in digital identity systems means credentials, wallets, and verifiers from different organizations can work together without prior bilateral negotiation. An issuer publishes a credential. Any conformant wallet can store and present it. Any conformant verifier can cryptographically verify it. No additional API agreements, special partnerships, or vendor-specific integrations required.

The distinction between standards compliance and genuine interoperability is that standards define data formats and protocol flows, while interoperability requires those definitions to be precise enough, tested enough, and governed enough that independent implementations actually work together in production.

Consider ISO/IEC 18013-5. The standard specifies how mDL data is structured and how a device-to-verifier presentation flow should work. But early implementations discovered that different interpretations of optional parameters, different approaches to cryptographic algorithm selection, and different assumptions about the engagement model (NFC vs. QR code) created incompatibilities that were not violations of the standard. They were conformant implementations that did not interoperate. The NCCoE mDL interoperability build was a direct response to that gap, testing multiple vendor implementations against each other to identify exactly these divergences. Similar divergences emerge in any standards ecosystem. W3C Verifiable Credentials face comparable interoperability questions around proof formats, credential status mechanisms, and selective disclosure implementations.

SEDI faces the same challenge at a broader scope. The statute requires open standards but does not name specific ones, and the working Implementation Guide takes a technology-neutral approach, translating statutory requirements into specifications without prescribing particular credential formats. Qualifying open standards could include mdoc, W3C Verifiable Credentials, SD-JWT, KERI, and others. Which format or formats will SEDI actually endorse? How will the presentation protocol be specified? Where will conformance be tested and by whom? Those questions live in the official implementation standards the Department of Government Operations is required to publish, which have not yet been released.

Vendor Lock-In Does Not Require Proprietary Technology

The most counterintuitive aspect of interoperability in digital identity is that vendor lock-in does not require proprietary formats. An ecosystem built entirely on published open standards can still produce practical lock-in through several mechanisms.

Integration complexity. If a verifier must build separate integrations for each wallet app, the ecosystem becomes hub-and-spoke rather than many-to-many. The verifier ends up selecting which wallets to support, which is de facto vendor selection on behalf of holders.

Certification gatekeeping. If a single vendor controls the conformance testing program or the trust registry, that vendor exercises structural influence over the ecosystem regardless of what the underlying standards say.

Selective profile interpretation. If two wallet vendors implement the same standard but use different profiles, their credentials may not work with the same verifiers. Profile fragmentation is one of the most common ways standards-compliant implementations produce a non-interoperable ecosystem.

Trust registry centralization. Verifiers need a way to confirm that an issuer is authorized to make a particular claim. If the only authoritative registry is controlled by the issuer or a preferred vendor, other participants gain access only on the registry operator's terms. The SEDI Implementation Guide calls for a public registry of certified wallets and verifiers maintained by the state, but the detailed governance model for the trust registry remains an open design question.

Portability Requires More Than Format Compatibility

Credential portability in SEDI means a holder can move their state-endorsed credential from one conformant wallet to another without losing functionality. But portability at the credential level depends on resolving several design questions the statute leaves to implementation.

The first question is key custody. The personal digital identifier is cryptographically bound to the holder, and if the private key is generated and stored within a wallet's secure enclave and cannot be exported, changing wallets requires a new identifier and effectively a new credential. Whether SEDI's implementation requires exportable keys, supports key migration, or treats credential re-issuance as the standard portability mechanism is a design decision with significant consequences for what "wallet choice" means in practice.

Beyond the key itself, some wallet providers enhance the baseline credential with additional stored data -- usage history, organizational profiles, customized presentation templates. If that metadata is not portable, changing wallets results in a degraded experience. The statute requires wallet providers to maintain a secure log that is "accessible, exportable, and deletable only by the holder" (63A-20-401), but that does not cover the full scope of wallet-specific data. There is also the relying party side to consider: if organizations that accept SEDI-verified identity have built integrations tested against one or two specific wallets, a holder using a lesser-known conformant wallet may encounter friction at the point of presentation. The credential is portable in principle but faces ecosystem resistance in practice.

Interoperability Is a Governance Problem

Interoperability decisions are fundamentally policy decisions. Who governs the trust registry? Who accredits conformance testing bodies? How are profile disputes resolved? These questions do not have technical answers. They require governance structures with clear authority, transparent processes, and accountability mechanisms.

Utah's statute places governance authority in the Department of Government Operations. That is a reasonable baseline for a state program. The harder question is multistate governance. The "Protecting Liberty" document invites states to join a SEDI Consortium. But multistate credential recognition requires agreed-upon technical profiles, mutual recognition of conformance certifications, and a governance structure with authority to resolve cross-jurisdictional disputes. The detailed governance documents and operational commitments that would make the consortium functional have not yet been published.

SpruceID's position is that existing open standards, which may include ISO/IEC 18013-5/-7, W3C Verifiable Credentials, SD-JWT, KERI, OpenID for Verifiable Presentations, and others, provide a broad technical foundation for such coordination. The statute is deliberately format-agnostic; what matters is that the chosen standards meet its requirements for openness, portability, and selective disclosure. Standards do not, however, substitute for governance. The technical layer can be shared; the policy and accountability layer requires deliberate institutional design.

What a Genuinely Open SEDI Ecosystem Requires

A SEDI ecosystem that delivers on the statutory promise of wallet choice requires several things beyond publishing a credential standard.

The first is specificity in the credential profile itself. Claiming compliance with a standard is not enough. "ISO/IEC 18013-5 compliant" leaves room for implementations that technically conform but diverge on algorithm selection, optional features, and presentation behavior. The same is true for "W3C VC compliant" or any other format label. The official implementation standards need to resolve these ambiguities: which algorithms are mandatory, which optional features are required for conformance, and how the presentation protocol works in practice across age verification, law enforcement, student enrollment, and health care identity scenarios.

Conformance testing is equally important, and who runs it matters. If a single vendor controls the testing program or the certification process, that vendor exercises structural influence regardless of how open the underlying standard is. Test cases and results should be public, the testing body should answer to the program's stakeholders rather than to any wallet or issuer vendor, and certification should create a level playing field rather than a gatekeeping mechanism.

Portability also has to be a design requirement, not an afterthought. When a resident wants to change wallet providers, the process matters. If portability means re-issuance, it should be low-friction and should not require repeating full identity proofing. If it means key migration, the wallet specification needs to define that flow explicitly. The trust registry presents a similar governance challenge: it should be governed under the program rather than owned by a vendor, because whoever controls the registry controls ecosystem access. And verifier onboarding should not require bilateral vendor relationships. A business that wants to accept SEDI credentials should be able to implement from the published specification and obtain conformance certification without negotiating integration terms with any specific wallet provider. That is what an open ecosystem means operationally.

These requirements describe the gap between where SEDI's public materials currently stand and where the ecosystem needs to be before the Digital Identity Bill of Rights provisions on wallet choice, selective disclosure, and freedom from surveillance can function as intended: not just as legal rights on paper, but as practical capabilities holders can actually exercise.

The conformance and governance decisions made during SEDI's initial implementation phase will establish defaults that are difficult to revise. A program that takes wallet choice seriously at the architecture level, as a practical design requirement rather than merely a legal protection against government compulsion, will produce an ecosystem that is genuinely competitive, more resilient to vendor capture, and more likely to remain viable as technology evolves.

About SpruceID: SpruceID builds digital trust infrastructure for government. We help states and cities modernize identity, security, and service delivery — from digital wallets and SSO to fraud prevention and workflow optimization. Our standards-based technology and public-sector expertise ensure every project advances a more secure, interoperable, and citizen-centric digital future.