When states explore digital identity, they arrive through different doors. Some start with the mobile driver's license, which is tangible, understood, and already has a standards pedigree through ISO/IEC 18013-5. Others begin with workforce credentials, benefits verification modernization, or governance frameworks that define what digital identity infrastructure should look like before any credential is issued. The mDL is one common entry point into the digital identity discussion, but it is not the only one, and for a growing number of states it is not the first.
State-Endorsed Digital Identity, or SEDI, is something different. Not a replacement for the mDL, and not simply a more advanced version of one. SEDI is a governance and architectural framework: the set of statutory requirements, rights, technical standards, and accountability mechanisms that define what it means for digital identity infrastructure to be trustworthy enough to earn state endorsement. An mDL can participate in a SEDI ecosystem. But SEDI is substantially broader than any single credential.
Understanding why that distinction matters is not a semantic exercise. For state CIOs, DMV leaders, and digital identity teams now evaluating what kind of digital identity infrastructure to build, the difference shapes procurement decisions, vendor relationships, wallet strategy, privacy architecture, and long-term interoperability.
A mobile driver's license is a digital credential: a cryptographically signed record containing identity attributes (name, date of birth, address, driving privileges) issued by a DMV and stored in a wallet application on the holder's device. ISO/IEC 18013-5 specifies the data model, the communication protocol for in-person presentations, and the security requirements. ISO/IEC 18013-7 extends that to online use. When implemented correctly, an mDL allows cryptographic verification without requiring the card to be handed over and without revealing more than the verifier needs.
SEDI describes the conditions under which a digital identity system can earn state endorsement. Under Utah's SB 275, enacted in the 2026 General Session and codified at Utah Code Title 63A, Chapter 20, SEDI establishes 11 enumerated rights in a Digital Identity Bill of Rights, defines what a state-endorsed digital identity must do and must not do architecturally, specifies obligations for digital wallet providers, verifiers, and relying parties, and creates a Duty of Loyalty binding every participant in the ecosystem.
Think of SEDI as the trust framework within which the state-endorsed digital identity, wallets, issuers, verifiers, and individuals interact. The state issues a SEDI credential to residents who meet objective, uniform standards. The credential format is open: the state-endorsed identity could be implemented as an mdoc, a W3C Verifiable Credential, or another format that meets the statute's requirements for openness, portability, and selective disclosure. What SEDI prescribes is the rights, governance, and accountability structure, not the underlying data format.
Utah's decision to sunset its existing mDL program (Utah Code 53-3-235, with a January 1, 2027 sunset date) illustrates the distinction practically. The ACLU praised the decision precisely because running two parallel programs, one governed by the full SEDI framework and one governed only by ISO/IEC 18013 without SEDI's rights and accountability requirements, would have created a competing, less-protected path for digital identity. The mDL format is compatible with SEDI. The old mDL program was not, because it lacked the governance structure SEDI requires.
A state mDL program, at minimum, includes a DMV issuing signed credentials in the ISO/IEC 18013 format, one or more wallet applications in which residents store those credentials, reader infrastructure for verifiers (law enforcement, TSA checkpoints, age verification), and some form of revocation and status management. This is a meaningful technical undertaking. It also leaves several questions outside the scope of the standard itself.
ISO/IEC 18013 does not define which wallet applications a resident may use. It does not prohibit the issuer from logging each time a credential is presented. It does not specify what data a verifier may retain after a presentation, or for how long. It does not create rights that residents can assert against wallet providers who misuse their data. It does not establish what happens when a third party demands digital identity as a condition of service.
These are governance and rights questions. They are the questions SEDI is designed to answer.
SEDI's contribution is not primarily technical. It is the combination of legal rights, architectural constraints, and participant obligations that make an entire ecosystem function in the interest of the individual, rather than merely in the interest of the issuer or verifier.
Several of SEDI's provisions are particularly relevant for states thinking through how any digital credential program fits into a larger digital identity strategy.
No phone home. Under Utah Code 63A-20-301(3), a state-endorsed digital identity may not include a mechanism that allows the issuing department to monitor, surveil, or track presentations to other entities. This architectural requirement means that when a resident shows their credential to a verifier, the state does not learn that the presentation happened. Verification is peer-to-peer. The issuer is not in the loop for every transaction. Some mDL implementations satisfy this requirement; some do not. SEDI makes it a legal mandate rather than a design option.
Wallet choice. SEDI prohibits any arrangement that effectively requires a resident to use a particular wallet application. The statute requires open technological standards that are publicly available and free from licensing fees and patent restrictions (63A-20-301(2)(e)). This means Apple, Google, and Samsung cannot lock up wallet control. A resident's identity should be portable to any conformant application. For states that have issued mDLs through a single vendor-controlled wallet, this represents a meaningful policy shift.
Selective disclosure as a right. Under 63A-20-101(8), selective disclosure is not merely a technical capability. It is an enumerated right: the right to choose what identity attributes are disclosed in accordance with standards established by the Legislature. For an age verification scenario, this means a resident may prove they are over 21 without disclosing their name, address, or exact birth date. ISO/IEC 18013-5 includes a technical mechanism for selective disclosure, but the standard does not create a right that verifiers must respect. SEDI does.
The Duty of Loyalty. Under Utah Code 63A-20-701, every participant in the SEDI ecosystem, including the state department, wallet providers, verifiers, and relying parties, is bound by a duty to refrain from practices that conflict with the best interests of the individual, exploit them, create disproportionate risk, or cause harm. This is a departure from notice-and-consent frameworks. A wallet provider cannot simply bury data-monetization terms in a consent flow and claim compliance. The Duty of Loyalty creates affirmative obligations independent of what any agreement says. The concept draws from academic work by Neil M. Richards and Woodrow Hartzog, who proposed in "A Duty of Loyalty for Privacy Law," 99 Wash. U. L. Rev. 961 (2021), that data collectors should be obligated to act in the best interests of the individuals whose data they handle.
Processing restrictions. Under 63A-20-702, information provided in the course of a presentation may only be processed for the primary purpose for which the holder disclosed it. A verifier that accepts a digital ID to confirm age cannot turn around and use that data for targeted advertising. The restriction applies regardless of what the verifier's terms of service claim.
These provisions do not flow from the credential format. They flow from the framework.
The standard trust triangle in digital identity has three participants: an issuer, a holder, and a verifier. The issuer signs the credential; the holder presents it; the verifier checks the signature and reads the attributes. ISO/IEC 18013 governs the mechanics of that exchange.
SEDI extends this model by placing explicit obligations on all three roles and adding a fourth: the digital wallet provider, which holds a distinct position with its own requirements under 63A-20-401. Wallet providers must maintain a secure transaction log that the holder can access, export, and delete. They must enable selective disclosure. They must support both online and offline presentation. They may only process identity attributes when processing is necessary for the presentation and the holder has been given conspicuous notice of what is collected, how it is used, and for how long.
The result is a four-party ecosystem where every participant has specific obligations toward the individual, not just toward the transaction. An mDL program without this governance structure leaves the wallet provider's obligations largely undefined, determined by contract and app store terms rather than statute.
One practical implication for state digital identity teams: SEDI does not mandate a specific credential format for the state-endorsed digital identity. The format is an implementation decision. A state could implement its SEDI credential using mdoc, W3C Verifiable Credentials, or another format that satisfies the statutory requirements.
States that have explored multi-format credential strategies understand the tradeoffs: different use cases may favor different formats, different verifier environments, and different wallet ecosystems. SEDI's framework approach accommodates that heterogeneity while imposing common requirements around privacy, wallet portability, and participant accountability.
This is also where selective disclosure becomes a baseline expectation rather than an optional feature. When SEDI requires selective disclosure as an enumerated right, the state-endorsed credential must support it regardless of which format is chosen. That consistency simplifies what verifiers need to accept and what residents can expect.
States building digital credential programs have confronted a recurring question: if every state issues a state-endorsed digital identity, how does it work across state lines? How does a Utah resident's SEDI credential get accepted by a Virginia verifier, and who decides which wallets that verifier must support?
These are not questions ISO/IEC 18013 answers. They require governance: mutual recognition agreements, trust registries, conformance certification, and some mechanism for establishing that a credential from one state meets another state's requirements.
Cross-state credential recognition depends on governance as much as on technical standards. SEDI's framework approach offers a model for multistate interoperability that goes beyond format compatibility. If multiple states adopt equivalent SEDI frameworks, a credential endorsed under one state's program could, in principle, earn recognition under another's, provided the governance structures align. Utah's "Protecting Liberty" document explicitly envisions a SEDI Consortium of states for this purpose, though multistate governance, mutual recognition, and cross-jurisdictional enforcement are all currently unsettled.
What is clear is that format alone cannot solve this problem. A state credential program that conforms to its chosen technical standard, whether ISO/IEC 18013, the W3C Verifiable Credentials Data Model, or another specification, but lacks the governance and rights structure SEDI establishes may produce credentials that work at the technical layer but lack the accountability and portability protections that residents, advocates, and policymakers increasingly expect.
States evaluating digital identity infrastructure today face a choice that goes beyond technology selection. The credential format, the wallet application, the revocation architecture, the verification protocol: these are important technical questions. But the governance questions matter just as much.
Who is responsible when a wallet provider misuses a resident's data? What can a verifier retain after accepting a credential presentation? Can a resident move their identity from one wallet to another? Does the issuer know every time a resident uses their digital ID? Are residents protected against private-sector pressure to adopt digital identity as a condition of service?
A credential program, whether built around mDL, W3C Verifiable Credentials, or another format, answers the technical questions. SEDI answers both the technical and the governance questions.
For states that have already issued mDLs, that work is not wasted. The credential infrastructure, the DMV integration, the reader ecosystem, the resident experience: all of that carries forward. For states that have not yet launched mDL programs, SEDI offers an opportunity to start with the governance framework first rather than retrofitting governance onto an existing credential program. What SEDI adds in either case is the governance layer that determines whether residents can trust the system long-term, whether the system can be audited and enforced, and whether the ecosystem remains open to competition and innovation rather than locked into a single wallet provider or technology stack.
SpruceID submitted a formal response to Utah's SEDI Request for Information drawing on our experience implementing standards-based digital credential infrastructure across state mDL and verifiable credential programs. Our core recommendation: architecture should enforce the protections that SEDI requires rather than relying on policy commitments alone. A "no phone home" rule should be technically implemented, not just contractually promised. Wallet portability should be built into the open-standards architecture, not dependent on a vendor's willingness to compete. For a broader introduction to what SEDI establishes and why Utah built it the way it did, the companion post in this series provides more context.
Utah's SEDI statute took effect May 6, 2026. The Implementation Guide (Version 0.1.0-draft, May 2026) is an interpretation of the statutory requirements, not yet the department's official published implementation standards. The mDL sunset takes effect January 1, 2027. The first legislative audit begins January 1, 2028. The timeline for issuing the first actual state-endorsed digital identities, publishing conformance requirements for wallets and verifiers, and achieving ecosystem readiness is not yet specified in statute.
What the statute establishes clearly is the framework: the rights, the participant obligations, the architectural constraints, and the governance mechanisms. States watching Utah's implementation have time to understand what these requirements mean before deciding how to adapt them to their own programs.
How open standards strengthen state digital identity governance is a related question worth exploring for states thinking through how technical standards choices interact with policy objectives. The choice of credential format, wallet architecture, and verification protocol affects not just how a system works today but whether it can be audited, ported, and extended as requirements evolve.
States building digital identity infrastructure now are building durable public infrastructure. Credentials issued under formats like mdoc, W3C Verifiable Credentials, or SD-JWT could all participate in that infrastructure. SEDI, or a framework like it, describes the conditions under which that infrastructure can actually be trusted.
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.
