Policy considerations for credential ecosystems

Verifiable credentials change the architecture of identity verification. They do not eliminate the need for policy. They change where the policy work sits, which existing safeguards still do the work, and which new questions arise that did not exist in the centralized model.

This page is written for policymakers, regulators, and issuing agencies thinking through the governance of a credential ecosystem. It complements Decentralized trust model, which explains the architectural shift, by focusing on the cross-cutting policy questions that follow from it.

The shape of these questions is consistent across jurisdictions. The answers are not, and should not be. Constitutional structure, regulatory tradition, and the assurance profile of each credential all matter. What follows is a map of the questions and the design choices each one opens up, rather than a prescription.

How the credential model reshapes existing policy concerns

The policymaker's task is not to evaluate verifiable credentials in isolation. It is to think through how a credential ecosystem affects the concerns policy already addresses. The credential model changes the shape of each one. Some get easier. Some get harder. Some change character entirely.

Privacy

A well-designed credential ecosystem is structurally more privacy-respecting than the centralized model it replaces, but the gain depends on design choices that policy needs to enable and enforce. Selective disclosure lets a verification answer a question without revealing the underlying data. A bartender confirms a customer is over 18 without learning the date of birth. A landlord confirms a tenant has the right to reside without learning the immigration history. A bank confirms a customer's identity without storing a passport scan.

These outcomes are not the default. They are the result of the wallet, the credential, and the verifier all being set up to support them. Where the design is right, the privacy gain is substantial. Where the design is wrong, the credential model can be more privacy-harmful than what it replaced, because high-assurance data flows in higher volumes through more pathways. The policy task is to make sure the design is right.

Data retention

The traditional pattern was for relying parties to retain copies of identity documents as evidence that a verification had been performed. The credential model makes that retention largely unnecessary. The presentation produces a cryptographically signed proof that a relying party can store as evidence the check was performed, without needing to store the underlying personal data.

Where retention is required, for regulatory compliance, dispute resolution, or statutory limitation periods, it can be calibrated precisely to the use case rather than defaulting to "keep everything indefinitely". Policy can codify this by setting maximum retention periods and requiring deletion confirmation. Some jurisdictions are doing this through privacy law, others through trust framework rules, others through contractual conditions of credential access.

Security

Credentials are cryptographically signed and verifiable offline. This raises the bar significantly above documents that can be forged, photoshopped, or stolen wholesale from a database. The shift from "trust the document I am holding" to "trust the cryptographic signature" closes a category of fraud that has been costly across every jurisdiction.

The new attack surfaces are different. They are concentrated at the issuance platform, which must be hardened, at the wallet, which must resist device compromise, at the relying party software, which must verify properly, and at the trust registry, which establishes who is allowed to issue and verify what. These are smaller, more defined surfaces than the diffuse surface of "every database holding a copy of every customer's documents". Security improves on balance, but the security investment must shift accordingly.

Fraud

The credential model materially reduces the scope for identity fraud. It also raises the stakes when something does go wrong. A fraudulent government-issued credential is more valuable than a fraudulent paper document because it carries higher assurance and is accepted in more places.

Issuance processes therefore need to be more rigorous than the analog equivalents, and revocation needs to be operationally immediate when fraud is detected. The architecture supports this. The issuing authority can revoke a credential in seconds, and the revocation propagates through the ecosystem as relying parties check the credential's status. The policy work is to make sure the revocation pipeline is in place before credentials are issued at scale.

Data integrity

Credentials carry their own integrity guarantees. The cryptographic signature means a credential cannot be altered without detection. The relying party knows the credential came from the named issuer and has not been tampered with. This is a substantial improvement over current arrangements where data is shared between systems through APIs or batch transfers and where errors propagate silently. The credential becomes the canonical source of truth for the attribute it carries, at the moment of presentation, with the issuer's authority cryptographically attached.

Liability

The decentralized model changes who is responsible for what, and the policy answer is not automatic. In the centralized model, the agency that mediated a verification was generally accountable for getting it right. In the decentralized model, the citizen initiates the sharing, the wallet executes it, and the relying party makes the decision.

Where does liability sit when a fraudulent credential is accepted? When a legitimate credential is rejected? When a relying party misuses received information? The general answer is that liability follows the locus of action and obligation. The issuing authority is accountable for the accuracy and integrity of what it issues. The wallet provider is accountable for executing presentations faithfully and for the security of credentials in storage on the device. The relying party is accountable for verifying properly and for using the received information only within the declared purpose. Trust frameworks typically codify some of these allocations. Contractual terms of credential access cover the rest. The transition period needs particular policy attention because the old liability allocations no longer fit and the new ones are not yet familiar.

Cost recovery

The centralized model often depends on per-verification fees, such as a certified copy from a registry, a check against an agency database, or a transaction through an identity verification service. The credential model has different economics. The cost of issuance is incurred once. The cost of verification is essentially zero per transaction.

This is generally welcome for citizens and relying parties. It can disrupt revenue lines for agencies that have come to depend on per-check fees. The policy question is whether the new model needs a different funding mechanism, such as per-issuance, subscription, or central appropriation, and whether legacy fee structures need to be amended.

Inclusion and equality

This is the concern that needs the most deliberate policy work, because the credential ecosystem can magnify existing exclusion if it is not designed to address it. The model assumes a level of digital literacy, device access, and institutional trust that is not evenly distributed in any population. People without smartphones, people with low digital literacy, people with cognitive disabilities, people experiencing housing instability, and communities with reasons to distrust digital government services can all be left behind. When that happens, the failure tends to be invisible to the agencies designing the system and visible to the community workers who absorb the consequences.

Three policy responses help:

• Accessibility design in the wallet itself, going beyond formal compliance baselines.
• Supported and delegated credential models, where a trusted intermediary can help an individual access and present their credentials without holding them.
• Analog alternative channels that are structurally maintained and funded, not aspirationally committed to.

Equity has to be a design requirement, not an edge case.

Regulation

Trust frameworks bring new regulatory functions into being. An accreditation authority assesses providers against the framework. Standards bodies set technical requirements. Privacy regulators retain their existing role over personal data handling. Sector regulators retain theirs over regulated industries.

Most jurisdictions are running this as a multi-regulator model rather than creating a single new regulator. The coordination among them matters more than the institutional design of any single one. The relationship between the trust framework regulator, the privacy regulator, and any sector regulators is the most important inter-agency relationship in the ecosystem, and it benefits from being made explicit rather than left to emerge.

What the architecture takes care of

A recurring observation across credential programs is that architecture does more protective work than regulation. Where the ecosystem is designed well, problematic data handling becomes structurally difficult rather than merely legally prohibited. This is a meaningful shift, because legal prohibitions depend on enforcement, and enforcement is always imperfect. Structural prevention does not.

Several specific architectural features carry most of the load.

Selective disclosure

A credential containing many attributes can be presented in a way that reveals only the ones needed for the transaction. If the relying party never receives the date of birth, it cannot retain the date of birth, share the date of birth, or have the date of birth stolen from its database. The privacy outcome is achieved without depending on the relying party's compliance with retention rules. The instrument exists in current standards (W3C VC Data Model, SD-JWT VC, ISO/IEC 18013-5) and in all standards-compliant wallet implementations. It is the single most important protective feature in the ecosystem. See Selective disclosure.

Purpose-bound presentation requests

OpenID for Verifiable Presentations (OID4VP) requires the relying party to declare upfront what they are asking for and why before the wallet presents anything. This is a structural filter. What cannot be requested cannot be received. It also creates an auditable record of the purpose for which information was received, which makes downstream misuse easier to detect and harder to defend. Mandating OID4VP in a trust framework turns over-collection from a rule violation into an architectural impossibility.

Cryptographic revocation

The issuing authority retains a fast, prospective instrument for invalidating credentials when source data changes or misuse is detected. Where credentials are issued with appropriate expiry dates and supported by status list infrastructure at the issuance platform, revocation propagates through the ecosystem in seconds. This is materially stronger than the historic position where revoked documents could circulate for months or years before downstream parties caught up.

Importantly, it is also more powerful than surveillance. The issuing authority does not need to watch what happens at the relying party layer. It needs to be able to act decisively when it learns something has gone wrong, and the architecture gives it that.

Anti-phone-home wallet behavior

A wallet should not contact its supplier or the issuing authority every time a credential is presented. The issuing authority therefore has no visibility into who is presenting credentials to whom. This is not a gap. It is a feature. It prevents the wallet ecosystem from becoming a surveillance infrastructure and makes it possible for citizens to use their credentials without their government watching them do so. Trust framework rules in most jurisdictions explicitly require this.

Short expiry and reissuance

Designing credentials with appropriate expiry windows means stored attributes become stale quickly. A relying party that wants to rely on a credential attribute over time must reverify periodically rather than treat the original presentation as a permanent record. This creates natural disposal cycles and makes long-term retention less valuable.

Coordinated disposal through revocation

When an issuing authority revokes a credential, the revocation notification can be propagated to relying parties bound by issuer terms, triggering contractual obligations to delete derived attributes they have retained. This creates a coordinated disposal mechanism that has no analog in the centralized model. The technical capability exists. The contractual framework that makes it legally operative is the remaining work in most jurisdictions.

Zero-knowledge proofs

On a longer horizon, zero-knowledge proofs take the data minimization principle to its logical endpoint. A credential can be used to produce a cryptographic proof that a condition is satisfied without revealing any underlying attribute. The W3C Verifiable Credentials Data Model 2.0 supports ZKP-compatible formats. This is the direction of travel for a category of high-volume, low-sensitivity verifications, such as age confirmation, eligibility checks, and residency, where even derived predicates may be more than the relying party needs.

The policy implication of all this is that architecture takes care of a great deal. Where regulators in the centralized model spend significant effort trying to police downstream behavior through retention rules, purpose limitation, and complaint-driven enforcement, the credential ecosystem does much of that work structurally. Policy attention can be freed up for the questions architecture cannot answer.

What policy still needs to address

The architecture, however well designed, does not answer everything. Several categories of question remain firmly in the policy domain. These are the issues most jurisdictions are still working through.

Trust framework scope and the relying party gap

The architecture provides the tools. The trust framework decides who is bound by which rules. In most jurisdictions, accredited credential services (issuers and wallets) are bound to a coherent set of obligations. Relying parties typically are not, except through general privacy law. This is the most consequential open policy question across credential programs.

The choices include:

• Extending the trust framework to bring relying parties inside it. A hard sell politically and operationally.
• Tiering accreditation so that high-assurance credentials can only be received by accredited parties. A workable compromise.
• Imposing binding terms on relying parties as a contractual condition of credential access. Available immediately, but contractual rather than regulatory.

Most jurisdictions are landing on some combination of these. The right combination depends on the assurance profile of the credentials being issued and the regulatory capacity of the jurisdiction. There is no universal answer.

What should and should not be credentialized

Just because an issuing agency holds data does not mean that data should flow into a credential. Several categories of information warrant exclusion from the default credential attribute set:

• Ethnicity is a special category under most privacy regimes, carries specific discrimination risk, and should be excluded unless explicitly opted into for a defined purpose.
• Sensitive relationship information held in birth registers can expose third parties (parents, siblings) who did not consent.
• Detailed immigration status can be misused in ways that affect employment, housing, and access to services.
• Health and disability inferences should not appear in identity credentials regardless of source.
• Biometric templates should not be credentialized. Only the outcomes of biometric verification ("identity confirmed: yes") should be.
• Information the issuing agency holds but is not authoritative for should be credentialized by the authoritative source agency, not by the holder.

These are policy choices, not technology choices, and they need to be made explicitly at the credential design stage.

Inclusion architecture

The technology cannot solve digital exclusion on its own. Policy needs to make explicit provision for accessibility, supported credential use, delegated authority models (where a trusted intermediary holds credentials for someone who cannot self-manage), and maintained analog channels. The community organizations that absorb digital exclusion failures need to be in the design conversation rather than discovered later as an edge case.

Equity impact assessments before each major rollout phase, public reporting on who is using the credential ecosystem and who is not, and funded analog alternatives with service-level standards are all useful instruments. None of these are technology decisions.

Inter-agency coordination

Where the issuing authority and the issuance platform sit in different agencies, which is increasingly common as governments separate identity policy from digital service delivery, the coordination protocol between them needs explicit design. How does the issuing authority instruct the platform to revoke a credential? On what evidence? Against what timing? What data sharing is permitted between them? Who decides credential policy? Who maintains the trust registry?

These are not technology questions. They are inter-agency governance questions, and they are best resolved before the credential program scales rather than after.

Cross-border interoperability

No jurisdiction issues credentials only for use within its borders. Mobile driving licenses from one jurisdiction are increasingly accepted at airports and other contexts in another. ISO/IEC 18013-5 provides the technical compatibility layer for mDL. The W3C VC Data Model and emerging eIDAS-compatible formats provide it for broader credentials.

The policy work is still maturing. Bilateral and multilateral arrangements for mutual recognition, joint accreditation of wallets and issuers, and shared assurance frameworks are emerging unevenly. The technology is interoperable by design. The policy framework for cross-border recognition is the remaining gap.

Liability allocation during transition

During the period where both centralized and decentralized verification are operating in parallel, policy needs to address what happens when something goes wrong in the new model, who is responsible, and how recourse works. Trust framework rules can codify some of this. Contractual issuer terms can address some. Sectoral regulation may need updates. Litigation will eventually settle the rest, but policy work upfront reduces the cost of getting there.

Enforcement and consequences

Where general privacy law is the principal restraint on relying party behavior, jurisdictions are realising that privacy law's enforcement architecture was designed for a different set of harms. Many privacy regimes do not include meaningful financial penalties for ordinary breaches. Enforcement is complaint-driven and retrospective. The credential ecosystem raises the question of whether the enforcement floor is sufficient when high-assurance government-issued identity information is involved. This is a legislative question in most jurisdictions.

Platform layer governance

Jurisdictions are taking different positions on wallet governance. Some operate a single state wallet. Others have chosen explicit multi-wallet choice. Others are designing for federated wallets across constituent jurisdictions. Each model has trade-offs:

• Single state wallets simplify governance and accountability but raise competition concerns and create single points of failure.
• Multi-wallet ecosystems preserve choice and resilience but increase coordination complexity.
• Federated models distribute governance but require strong cross-jurisdiction agreement.

There is no single right answer. The policy choice is real and consequential and should be made deliberately, with the trade-offs understood.

A starting position for issuing agencies

For an issuing agency considering whether and how to begin credentialling its identity holdings, a few practical observations apply across the programs in production today.

The technology is ready

Verifiable credential infrastructure has matured to the point that platform implementation is no longer the bottleneck. Standards-compliant issuance platforms, wallets, and verification tools have been deployed at scale in several jurisdictions. An agency starting now is not pioneering the technology. It is making policy and design choices within a known technical envelope.

The policy work is most of the work

The harder questions are not "can we issue verifiable credentials" but "what should the credential contain, who should be able to receive it, under what conditions, and what happens when something goes wrong". These are decisions only the issuing agency and its regulator can make. They benefit from being made early rather than late.

Start with a defined use case

The most successful programs have not tried to do everything at once. A focused initial use case, such as a driving license or a single identity attestation, lets the agency develop the operational muscle, including revocation, lifecycle management, and relying party coordination, before the credential set expands.

Build the governance instruments before scale

The technical platform can be implemented quickly. The credential policy, the trust registry, the binding terms for relying parties, the revocation protocols, the coordination with the privacy regulator, the equity impact assessment, the accessibility plan, and the inter-agency coordination protocol all take longer and are harder to retrofit. The mistake to avoid is launching the platform before the governance instruments are in place.

Choose architecture over regulation where you can

For every concern that arises, the first question is whether the architecture answers it. Selective disclosure answers many privacy concerns. OID4VP answers many over-collection concerns. Cryptographic revocation answers many accuracy concerns. Where the architecture answers a concern, the policy task is to make sure the architectural choice is mandated rather than recommended. Where the architecture does not answer the concern, policy needs to do the work. The discipline is to keep the two questions in the right order.

Plan for relying party governance from day one

This is the area where almost every jurisdiction has had to come back and add governance later. The architectural instruments (selective disclosure, OID4VP, short expiry) reduce the relying party governance burden but do not eliminate it. Binding issuer terms imposed through the trust registry as a condition of credential access are among the most powerful tools available within current law, and they should be drafted in parallel with the credential design itself.

Take inclusion seriously as a design requirement

The programs that have succeeded for the broadest population have made inclusion a design constraint from the outset, not an add-on. The programs that have struggled have learned the cost later.

Coordinate internationally where possible

ISO/IEC 18013-5, W3C VC Data Model 2.0, OID4VP, and SD-JWT VC are the technical lingua franca of the global ecosystem. Aligning with these standards from the beginning protects against jurisdictional lock-in and enables cross-border recognition later. Where bilateral or multilateral relationships are particularly important, early coordination on accreditation and mutual recognition pays off.

Expect the policy framework to evolve

Every credential program reviewed to date has revised its trust framework rules and accompanying guidance multiple times as the program has matured. This is healthy, not a sign of failure. The technology and the use cases are still developing, and the policy framework needs to evolve with them. Build the policy infrastructure (the regulator function, the standards-setting body, the consultation mechanisms) for ongoing evolution, not as a one-off settlement.

Summary

Verifiable credentials are not a magic privacy or security solution. They are an infrastructure for moving identity verification from a model based on document exchange and centralized mediation to one based on cryptographic proof and citizen control. They make some things structurally easier (privacy, fraud reduction, data minimization) and some things newly important (issuer governance, relying party accountability, revocation operations, equity by design).

The policy work is real, and it sits primarily with the issuing agency and the trust framework regulator. The credential model is operational, the standards are mature enough to commit to, and the policy framework can be built in stages alongside the technical rollout.

Frequently asked questions

Do verifiable credentials replace privacy law?

No. Verifiable credentials change where privacy protection is applied. Architectural features such as selective disclosure, purpose-bound presentation requests, and anti-phone-home wallet behavior do much of the work that retention rules and purpose limitation did under privacy law. But privacy law still applies to relying parties that receive credentials and to any personal data they retain after a presentation.

Who is liable when something goes wrong with a verifiable credential?

Liability typically follows the locus of action and obligation. The issuing authority is accountable for the accuracy and integrity of what it issues. The wallet provider is accountable for executing presentations faithfully and for the security of credentials on the device. The relying party is accountable for verifying properly and for using received information only within the declared purpose. Trust frameworks usually codify some of these allocations, and contractual terms of credential access cover the rest.

Are relying parties bound by the trust framework?

In most jurisdictions, accredited credential services such as issuers and wallets are bound to the trust framework. Relying parties typically are not, except through general privacy law. Closing this relying party gap is one of the most consistent open policy questions across credential programs. Options include extending the trust framework, tiering accreditation, or imposing binding terms on relying parties as a contractual condition of credential access.

What data should not be put into a verifiable credential?

Several categories warrant exclusion from the default credential attribute set. These include ethnicity, sensitive relationship information that can expose third parties, detailed immigration status, health and disability inferences, and biometric templates. Information the issuing agency holds but is not authoritative for should be credentialized by the authoritative source, not by the holder.

How should an issuing agency start a verifiable credential program?

Start with a defined use case rather than trying to do everything at once. Build the governance instruments, including credential policy, the trust registry, relying party terms, revocation protocols, and the inclusion plan, before the platform scales. Choose architectural safeguards over regulation where possible. Plan for relying party governance from day one. Coordinate internationally by aligning with ISO/IEC 18013-5, the W3C VC Data Model 2.0, OID4VP, and SD-JWT VC.

Do verifiable credentials risk excluding people without smartphones?

Yes, if inclusion is not treated as a design requirement. The credential model assumes a level of digital literacy, device access, and institutional trust that is not evenly distributed. Policy responses include accessibility design in the wallet, supported and delegated credential models where a trusted intermediary can help an individual present credentials, and analog alternative channels that are structurally maintained and funded.