When states first explore digital identity, the conversation usually starts with the mobile driver's license. It is tangible, understood, and already has a standards pedigree through ISO/IEC 18013-5. A state issues the credential; residents store it in a wallet app; a TSA agent or liquor store scans it. The mDL is a natural entry point into the digital identity discussion.
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 credentials, wallets, issuers, verifiers, and individuals interact. An mDL is one kind of credential that might meet SEDI's requirements. So might a W3C Verifiable Credential bound to a holder-controlled identifier. So might other credential formats, provided they satisfy the statutory and technical requirements for endorsement. SEDI does not mandate a single credential format. It specifies the floor that any endorsed credential must clear.
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 an mDL 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.
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 require states to abandon existing credential programs or pick a single winning format. It requires that any endorsed credential meet the baseline requirements. A state could run a SEDI-conformant mDL alongside a SEDI-conformant W3C Verifiable Credential. An employer credential, an educational record, or a professional license could also earn endorsement if it satisfies the same 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 consistent expectation across credential types rather than an optional feature of one. When SEDI requires selective disclosure as an enumerated right, every endorsed credential, regardless of format, must support it. That consistency simplifies what verifiers need to accept and what residents can expect.
States building mDL programs have confronted a recurring question: if every state issues mDLs, how do they work across state lines? How does a Utah resident's mDL 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's mDL program that conforms to ISO/IEC 18013 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?
An mDL program answers the technical questions. SEDI answers both.
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. What SEDI adds 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, the companion post in this series provides more context.
Utah's SEDI statute took effect May 6, 2026. The Implementation Guide is an interpretation of the statutory requirements, not yet the department's official published implementation standards. Utah's 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. The mDL is one component of that infrastructure. SEDI, or a framework like it, describes the conditions under which that infrastructure can actually be trusted.
Building digital services that scale take the right foundation.
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.
