Digital Identity Without Surveillance: Understanding SEDI's No-Phone-Home Principle

When you show a physical driver's license at a bar, the bouncer checks it. The state that issued it learns nothing. No notification is sent, no record is created at the DMV, and no mechanism exists for the issuer to observe that you were there on that evening. The interaction is complete once the verifier is satisfied.

Many digital identity systems break this property. They are designed so that each time a credential is presented, a request travels back to the issuer's servers to check revocation status, to validate a token, or to complete an online handshake. The issuer accumulates a log of presentations that a physical license never generates. Utah's State-Endorsed Digital Identity (SEDI) statute prohibits that design by law. But the statutory prohibition only does its full work if the underlying architecture makes issuer observation technically unnecessary. That requires deliberate choices about how verification is structured, and those choices have real limits that any implementation team should understand clearly.

What "phone home" means in a credential system

The phrase "phone home" refers to a verification architecture in which the verifier contacts the issuing authority during each presentation. The forms vary. In some systems, the verifier queries an issuer-hosted endpoint to confirm the credential is still valid. In others, the credential itself embeds a short-lived token that expires unless the wallet fetches a fresh one from the issuer's server. In still others, the verification protocol requires an online handshake that the issuer can observe.

Each of these creates something the physical license never does: a trail of presentations that the issuer can see, log, and potentially correlate. When a state government operates this kind of infrastructure, it becomes technically capable of knowing, even if prohibited by policy from knowing, that a specific person presented their identity at a specific time and place. Policy prohibitions on misusing that data are real protections, but they depend on enforcement after the fact. If the architecture generates the surveillance record in the first place, the question of what gets done with it becomes a matter of organizational discipline rather than technical impossibility.

This distinction is what Utah's SEDI statute is addressing. Under Utah Code 63A-20-301(3), "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." The text targets architecture, not conduct. It does not say the department may not watch; it says the credential may not include a mechanism that would allow watching in the first place.

Why the statute targets architecture

A requirement that issuers refrain from logging presentation data is considerably weaker than a requirement that they architect systems where there is no presentation data to log. Jay Stanley of the ACLU published an independent analysis of Utah's SEDI legislation characterizing it as "the best effort we have yet seen in a state to square privacy protections with the looming dangers to civil liberties that flow from digital identities." That analysis specifically identified the no-phone-home ban as one of the statute's important strengths, because prohibiting observation after the surveillance record exists is a much harder enforcement problem than preventing the record from being created.

This is a core argument SpruceID has made repeatedly in the context of digital credential architecture: that architecture can enforce protections policy alone cannot. The zero trust framework asks a related question about every data flow: why does this system need to contact a central authority at all, and what happens if that authority is unavailable, compromised, or required by subpoena to produce its logs? When applied to digital identity, the answer often points toward verifier-side cryptographic verification rather than issuer-side query.

The statute uses the word "mechanism." That framing matters. A passive logging decision on the issuer's server would not technically be a mechanism inside the credential. The stronger reading, and the one that produces a genuinely surveillance-resistant architecture, is that any presentation flow that necessarily involves issuer infrastructure falls within the prohibition. That reading requires implementing verification in a way that the verifier can complete without contacting the issuer at all.

How verifier-side cryptographic verification works

The alternative to phone-home architectures relies on the same cryptographic properties that make verifiable digital credentials useful in the first place: an issuer signs the credential at issuance, and the verifier checks that signature without asking the issuer anything.

When a credential is issued, the issuer signs the credential data using its private signing key. The corresponding public key is published in a way verifiers can independently retrieve, typically from an open registry or a well-known endpoint. A verifier receiving a presented credential can then verify three things without contacting the issuer: that the signature is valid, that the signing key belongs to the claimed issuer, and that the credential data has not been modified since issuance.

Signing key infrastructure is a meaningful implementation concern in its own right: key rotation, revocation of issuer keys, and publication mechanisms all require careful design. But the core verification operation itself is local to the verifier. No call home is needed to determine that a credential is cryptographically authentic.

This is also what makes offline-capable credential verification possible. If a bar has no internet connection, a police officer's device is in a building with no cellular signal, or an emergency services team is operating in a degraded environment, a credential based on issuer-side query fails at exactly the moment when identity verification may matter most. A credential that can be verified cryptographically by the verifier using a locally cached public key continues to work.

The revocation problem is real, and the statute acknowledges it

Offline cryptographic verification works cleanly at issuance. The harder problem is revocation: what happens when a credential should be invalidated before it expires?

Revocation is the strongest argument for phone-home architectures. If a credential has been compromised, if it was issued on the basis of fraudulent information, or if the holder has requested that it be revoked, a verifier that cannot contact the issuer has no way to know that the credential is no longer valid. A long-lived credential checked only against a signature from two years ago could still verify correctly even after the issuer revoked it.

Utah's statute takes a partial approach to this problem. Under 63A-20-301(5), the department may only revoke a SEDI in three circumstances: the credential has been compromised, the endorsement was issued in error or based on fraudulent information, or the holder requests revocation. The statute does not permit revocation for other reasons, which means the population of legitimately revoked credentials should remain small, and the window during which an unrevoked-but-invalid credential circulates should be manageable.

The technical community has developed several mechanisms for enabling revocation checks that do not reveal which specific credential is being queried. Status lists, cryptographic accumulators, and batch-published revocation sets can all give verifiers current revocation information without telling the issuer which holder's credential was being checked at a particular time. These approaches shift the tradeoff: instead of the issuer knowing when each credential is used, verifiers periodically download a published revocation dataset and check locally. The issuer sees download traffic for the dataset, not individual presentation events.

Data minimization principles apply directly here: the question is not whether revocation information can be checked, but how to design that check so that it produces only the information each party actually needs. A verifier needs to know whether this credential is valid now. The issuer does not need to know where and when that question was asked.

What selective disclosure adds to this picture

The no-phone-home provision addresses one information flow: from the presentation event to the issuer. A complementary statute, Utah Code 63A-20-101(8), which establishes selective disclosure as a right, addresses the opposite flow: how much information goes from the holder to the verifier.

These two protections work differently, but they reinforce each other. A credential that prevents issuer surveillance but discloses the holder's full identity data to every verifier is still generating surveillance potential; it has just shifted where the record lands. A credential that supports selective disclosure but phones home for every verification check gives holders control over what they share while leaving issuers informed of every interaction.

The strongest privacy posture is both: a system where the verifier learns only the attributes relevant to the specific transaction, and the issuer learns nothing about that transaction at all.

Selective disclosure in verifiable digital credentials is the mechanism that makes attribute-level minimization possible at the credential format level. Whether a specific interaction qualifies (age verification for alcohol purchase, for instance, where the verifier needs to know the holder is over 21 but has no legitimate interest in knowing their birth date, name, or address) depends on both the credential format supporting selective disclosure and the verifier requesting only what the transaction requires. Utah's statute separately requires verifiers to minimize data collection, which is the policy side of this constraint. The technical side is a credential format that makes selective disclosure possible to begin with.

The limits of these protections

Precision about what no-phone-home architectures do and do not accomplish is important for any implementation team working through these requirements.

The no-phone-home provision prevents the issuer from observing presentations. It does not prevent the verifier from logging them. A holder presenting a SEDI at a government office, a healthcare provider, or a private business creates a record at the verifier's end. Utah's processing restrictions under 63A-20-702 limit what verifiers and relying parties may do with that information (they may only process it for the primary purpose of the presentation), but that is a policy constraint on the verifier, not an architectural constraint on data generation.

Similarly, the wallet plays a distinct role in this picture. The statute requires digital wallets to maintain a secure log showing what identity attributes were provided and to whom, a log accessible, exportable, and deletable by the holder. This is a transparency and control feature for holders, not a surveillance feature for issuers. But as the ACLU's analysis has noted, default log retention periods matter: thirty years of technology behavior suggests that most holders will not actively delete logs unless the default supports short retention. How that tension is resolved in conformant wallet implementations will affect the practical privacy posture of the system.

There is also a category of interaction the no-phone-home provision does not fully address: online verification flows where the verifier, rather than the issuer, receives identifying information through a server-side request. The no-phone-home prohibition is specifically about issuer-facing architecture. In presentations that occur through an online channel (not device-to-device but over a web session), the verifier may still see an IP address, session metadata, and contextual signals that were invisible in the in-person physical-credential scenario. These are not unique to SEDI; they are features of any online interaction. But they are worth naming clearly: offline cryptographic verification eliminates issuer surveillance of presentations; it does not eliminate the digital footprint that online transactions generate by their nature.

What this means for implementations working toward SEDI conformance

For an architect or CIO working through SEDI conformance requirements, the no-phone-home principle translates into several concrete questions about how credential and verification systems are designed and deployed.

The most direct question is whether the selected credential format supports verifier-side signature verification without requiring an online issuer query. Standards like ISO/IEC 18013-5 (the mobile document standard underlying many mobile driver's license implementations) and W3C Verifiable Credentials both provide this capability, though their implementation details vary. Choosing a format is not enough; the deployment configuration matters equally.

Revocation deserves separate attention. An architecture that responds to every revocation check with a direct query to issuer-controlled infrastructure has a phone-home problem even if the credential itself is cryptographically offline-verifiable. The choice of revocation mechanism, and whether it reveals individual presentation timing to the issuer, directly affects compliance with the statute's intent, not just its letter.

The trust framework question follows from both of these: how do verifiers reliably obtain and refresh the issuer's public key material without that process becoming a surveillance vector? Key distribution and rotation require design care to ensure that establishing trust in the issuer's key does not inadvertently create presentation-level observation opportunities.

Translating statutory privacy requirements into technical architecture is the underlying challenge across all of these questions. The statute sets the protection goal. The implementation team must select and configure a system that achieves it.

What remains unsettled

The SEDI Implementation Guide (Version 0.1.0-draft, May 2026) represents an interpretation of statutory requirements rather than final authoritative guidance. The Utah Department of Government Operations has not yet published official implementation standards. How the department will specify conformant revocation mechanisms, acceptable key distribution methods, and online presentation flows consistent with 63A-20-301(3) are open questions that will determine whether the no-phone-home principle operates as written or narrows in practice.

The statute also applies to state-endorsed digital identities issued by the department. The Duty of Loyalty and processing restrictions extend to digital wallet providers, verifiers, and relying parties, but the enforcement mechanism runs through the data privacy ombudsperson and the attorney general rather than a private right of action. Whether those channels will be practically sufficient, particularly for claims against well-resourced technology companies, is an open question that implementation teams should monitor.

None of this undermines the significance of what Utah has done. The statutory prohibition on mechanisms that allow issuer surveillance of presentations is a meaningful architectural requirement, not just a policy aspiration. Enforcing it requires verification designs where the surveillance data is never generated in the first place, and that is a concrete, achievable engineering goal when the credential format, revocation mechanism, and key distribution approach are designed together with it in mind. Understanding how the rights established in Utah's Digital Identity Bill of Rights translate into technical system requirements makes the scope of that engineering goal clearer: the no-phone-home principle is one element of a broader architecture in which every statutory right demands a corresponding design commitment.

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.