SEDI's Digital Identity Bill of Rights creates obligations that policy language alone cannot enforce. Each right implies architectural constraints on verification, credential formats, wallet ecosystems, and governance.
Utah's State-Endorsed Digital Identity framework begins with something unusual for a government technology program: a bill of rights. Eleven enumerated rights, codified in SB 275 and effective since May 2026, establish what individuals can expect from any digital identity system that carries the state's endorsement. The rights cover selective disclosure, freedom from surveillance, wallet choice, voluntary participation, and more.
But a right written into statute is only as durable as the system that enforces it. A law can prohibit surveillance. Whether an architecture actually prevents it depends on how verification works, where cryptographic operations happen, and what information flows back to the issuer. SEDI's most important contribution may be its insistence that these questions are not separate from the policy – they are the policy, expressed in technical terms.
Utah's own framing makes this hierarchy explicit. The "Protecting Liberty in the Digital Age" document, published by the Department of Government Operations, places individual rights above operational goals like interoperability, efficiency, and convenience, stating that operational objectives "may never justify compromising" those higher values. That ordering has consequences for how every component of a SEDI ecosystem gets designed, tested, and governed.
The tenth right in SEDI's Digital Identity Bill of Rights guarantees that an individual is "free from surveillance, profiling, tracking, or persistent monitoring of the individual's assertions of digital identity by the state, except as authorized by law." The statute goes further in Section 63A-20-301(3), specifying that a state-endorsed digital identity "may not include a mechanism that allows the department to monitor, surveil, or track the presentation of a state-endorsed digital identity to another entity."
This provision eliminates an entire class of verification architectures. In many existing credential systems, the issuer is contacted each time a credential is presented – a pattern sometimes called "phone home" verification. The issuer learns when, where, and to whom the credential was shown, creating a detailed activity record that exists independently of whether anyone intended to build one.
Under SEDI, the architecture must make issuer observation technically unnecessary, not just operationally discouraged. Cryptographic verification happens at the point of presentation, using the credential's embedded proof rather than a real-time callback to the issuing authority. The verifier confirms the credential's authenticity, integrity, and status without the issuer learning that a presentation occurred.
The distinction matters because policies can be changed, exceptions can be carved out, and audit logs can be repurposed. An architecture that never generates the data in the first place offers a stronger guarantee than one that generates it and promises not to look. The ACLU's analysis of the legislation specifically praised the no-phone-home provision as one of the law's most important privacy protections.
SEDI's eighth enumerated right gives individuals "the right to choose what identity attributes are disclosed by the individual's state digital identity." The statute also requires digital wallet providers to "enable selective disclosure of identity attributes" and to support "verification of age-minimum without disclosing the holder's age or date of birth."
When selective disclosure is a statutory right rather than an optional product feature, the credential format and presentation protocol must support it natively. A system that transmits a full credential and relies on the verifier to ignore the fields it did not request does not satisfy this requirement. The architecture needs to allow the holder to construct a proof that reveals only the specific claims the verifier asked for, and nothing more.
Consider the age verification requirement. A bar checking whether a patron is over 21 does not need the patron's name, address, date of birth, or license number. Under SEDI, the wallet must be able to produce a cryptographic proof that the holder meets an age threshold without disclosing the underlying date of birth. This is not a hypothetical scenario, it is an explicit statutory requirement for wallet providers under Section 63A-20-401.
The architectural implication extends beyond credential formats. Selective disclosure also constrains how presentation requests are structured and how verifiers specify what they need. If a verifier requests more attributes than necessary for the transaction, the system's data minimization properties are undermined even though the credential format technically supports selective proofs. The governance layer – what verifiers are permitted to request, and how those permissions are enforced – has to work alongside the cryptography.
SEDI defines a "personal digital identifier" as an identifier that is unique, created by or at the direction of the individual, mathematically provable to be under the holder's control, and "transportable to technical infrastructure of the holder's choosing." The ninth right guarantees that individuals cannot be denied services based on their "choice of a lawful format or means of identity assertion."
Together, these provisions require an open wallet ecosystem where individuals can move their credentials between providers without losing functionality. The statute mandates open technological standards that are "publicly available and free from licensing fees and patent restrictions." The ACLU praised this approach for preventing Apple, Google, and Samsung from monopolizing digital wallet control.
But adopting an open standard does not automatically produce interoperability. A wallet provider can implement a published specification while adding proprietary extensions that create practical switching costs. A verifier can technically accept credentials from any wallet while optimizing its user experience for one. Conformance testing, certification requirements, and ongoing governance are what close the gap between a standard on paper and interoperability in practice.
The SEDI Implementation Guide addresses this through a graduated conformance framework with four levels -- Basic, Enhanced, Advanced, and Exemplary -- each adding requirements for privacy controls, interoperability testing, and ecosystem participation. Whether a credential works portably across wallets depends less on which standard it uses than on whether every participant in the ecosystem has been tested against the same set of functional requirements.
SpruceID's experience building credential infrastructure across multiple states reinforces this point. In our response to Utah's SEDI Request for Information, we recommended that the framework support "multiple issuers, wallets, credential technologies, and verification systems" participating through established standards such as ISO 18013-5/7, W3C Verifiable Credentials, and OpenID Connect. Standards provide the common language; governance and conformance determine whether that language is spoken consistently.
The third and fourth rights in SEDI's Bill of Rights protect the right to physical identity and the right not to be compelled to use a digital form of identity in place of a physical one. Section 63A-20-304 reinforces this by prohibiting government entities from conveying "a material benefit" for using digital identity over physical identity, withholding services from individuals using physical identity, or requiring device surrender during presentation.
These provisions turn voluntary participation from a policy aspiration into a system design constraint. Every government service that accepts SEDI must continue to accept physical identification at equivalent service levels. That means the digital pathway cannot offer faster processing, shorter lines, or access to additional services unless the physical pathway offers the same.
The harder question is whether these protections extend beyond government interactions. The ACLU's analysis identifies inadequate private-sector protections as the law's most serious gap. The statute does not limit when private companies may demand digital identification, and does not prevent companies from offering better service, pricing, or access to customers who present digital credentials. The statutory protection for voluntary participation is strong in the public sector and largely unaddressed in the private sector – a gap that follow-up legislation may need to close.
For architects designing SEDI-compatible systems, the practical implication is that nondigital pathways need to be designed as first-class workflows, not afterthoughts. If a digital pathway automates eligibility verification in seconds while the physical pathway requires a manual review that takes days, the service is not equivalent in any meaningful sense, regardless of whether both paths technically lead to the same outcome.
A common assumption in digital identity discussions is that selecting the right standard solves the implementation problem. SEDI's architecture exposes why this assumption fails: a credential built on the right standard can still violate SEDI's rights provisions if governance is absent, conformance is untested, or the verification architecture permits surveillance.
Standards define how credentials are structured, how presentations are formatted, and how cryptographic proofs are verified. They provide the technical foundation. But standards do not determine who is authorized to issue credentials, what identity proofing is sufficient for endorsement, how conformance is tested and certified, what happens when a wallet provider violates processing restrictions, or how the Duty of Loyalty is enforced when a verifier processes identity attributes beyond the primary purpose of the presentation.
Governance answers the institutional questions: who certifies wallet providers, who audits verifiers, who investigates complaints, and who enforces the statute's prohibitions. Under SEDI, complaints go to Utah's data privacy ombudsperson, who may refer cases to the attorney general for civil enforcement. The statute also requires a legislative audit beginning January 1, 2028, evaluating compliance with surveillance and tracking restrictions among other criteria.
Conformance sits between standards and governance. The SEDI Implementation Guide proposes four graduated conformance levels, each adding requirements. A wallet provider at the Basic level meets minimum functional requirements. At the Exemplary level, it demonstrates advanced privacy controls, participates in interoperability testing, and supports the full range of selective disclosure and data minimization capabilities the statute envisions.
All three layers have to work together. A conformant implementation of an open standard, operating under governance that enforces the statute's rights provisions, is what makes SEDI's promises enforceable. Any one layer alone is insufficient.
Utah has published example statutory language for states considering a SEDI-style framework. The National Governors Association has expressed interest. The question for other states is no longer whether digital identity should come with rights protections -- Utah has made a compelling case that it should. The question is how to design systems that make those protections technically enforceable.
That translation work is harder than it looks. Each right in the Bill of Rights implies constraints on architecture, standards selection, governance, and conformance that interact with each other. Freedom from surveillance constrains verification protocols. Selective disclosure constrains credential formats. Wallet choice constrains ecosystem governance. Voluntary participation constrains service design. A state that adopts the rights without doing the corresponding architecture work risks creating protections that exist on paper but not in practice.
In our response to Utah's SEDI Request for Information, SpruceID offered implementation recommendations spanning credential architecture, privacy, standards, interoperability, wallets, verification, and governance. The core argument was straightforward: architecture can enforce protections that policy alone cannot. A system designed so that issuer surveillance is technically impossible offers a stronger guarantee than one where surveillance is merely prohibited. A credential format that supports selective disclosure natively is more durable than one where data minimization depends on verifier self-restraint.
The states that get this right will build digital identity infrastructure that earns public trust because the architecture itself protects the rights the policy promises. The ones that adopt rights language without rethinking their system design will discover that the gap between a right and its enforcement is where trust breaks down.
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.
