What is a decentralized trust model?

Digital trust is moving from a federated model, in which intermediaries authenticate users and assert their identity to relying parties, to a decentralized one, in which the holder receives verifiable credentials and presents them directly. This shift is not a technology upgrade. It is a change in the architecture of trust itself.

Several jurisdictions are operationalizing decentralized digital identity programs, including the European Union (eIDAS 2.0 and the European Digital Identity Wallet), Australia, New Zealand, the United Kingdom, Canada, and Singapore. The standards stack is mature, the architectural model is widely understood, and credential schemes are entering production. The questions that remain are governance questions, and they require policy makers, regulators, and ecosystem stakeholders to reframe assumptions formed in earlier eras.

This page explains what is genuinely different about the decentralized trust model, the technology that enables it, and the shifts in thinking required to govern it well.

The three architectural eras of digital identity

Era one: Paper and the trusted holder

For most of the twentieth century, identity verification meant presenting a physical document. Governments issued passports, birth certificates, and driver licenses. The citizen carried them. A relying party (a bank, an employer, or a border officer) inspected the document, made a judgment about its authenticity, and recorded what they needed.

The safeguards in this era were operational: document security features, controlled issuance, in-person inspection. What happened at the point of presentation was largely outside the issuer's view.

This era's privacy properties were accidental rather than designed. There was no national identity database because there was no practical way to build one. Each relying party kept its own records, and linkage between them was difficult.

Era two: Federated identity and the trusted intermediary

From the early 2000s, governments and large institutions moved identity verification online. The architecture that emerged was federated. A single trusted intermediary, the identity provider, authenticated the user and then asserted to relying parties that the user was who they claimed to be. National schemes followed this model, alongside consumer-grade equivalents such as Login with Google and Login with Apple.

The federated model solved a real problem. It removed the need for every relying party to verify identity independently. But it introduced a new one: the identity provider sees every transaction. Each verification request flows through the intermediary, which can build a complete view of which services a person accesses.

The safeguards in this era were contractual and regulatory. Identity providers were required to handle data carefully, retain it only as long as necessary, and submit to oversight. Privacy law and binding terms did the work. But the architecture itself was surveillance-capable by design: the intermediary had to see the transaction in order to authenticate it.

Era three: Decentralized credentials and the trusted holder, returned

The decentralized model returns the holder to the center, but with cryptographic guarantees the paper era could not offer. An authoritative issuer issues a verifiable credential to the holder's wallet. The holder presents that credential to relying parties directly, without an intermediary in the transaction loop. The credential is cryptographically signed by the issuer, so the relying party can verify its authenticity without contacting the issuer. The issuer cannot see where the credential is being used.

What is genuinely different about era three is not the cryptography itself. It is the consequence: no party in the system holds a complete record of how a person uses their identity. Not the issuer. Not a federation provider. Not a single trust registry. The data minimization that was accidental in era one and contractual in era two is now architectural in era three.

The technology that enables decentralized trust

The decentralized trust model rests on a stack of open, internationally maintained standards that have matured significantly over the last five years.

Together, these standards make it possible for an issuer to mint a credential once, for a holder to store and present it from any compliant wallet, and for a verifier to validate it independently without contacting the issuer or any central intermediary.

Two properties of this stack matter particularly for governance:

• Cryptographic signatures make credentials tamper-evident and bind them to the issuer without requiring a live lookup at verification time. The verifier can confirm authenticity offline.
• Selective disclosure lets the holder present only the specific facts a verifier needs (for example, "over 18" rather than a full date of birth). This is how the architecture enforces data minimization in practice. See Selective disclosure for more.

Trust is anchored in cryptographic keys and governed by explicit trust frameworks rather than inferred from reputation or jurisdiction. See Chain of trust for how issuer keys are anchored to recognized trust roots.

Four layers of a credential ecosystem

It is helpful to read a credential ecosystem in terms of four functional layers, because the policy questions tend to sit cleanly within one or another of them. This framing is not specific to any single jurisdiction. It is a useful way to read what is actually happening in deployed programs. The EU's Architecture and Reference Framework, the ISO 18013 family of standards, and most national trust frameworks make similar distinctions, sometimes with different vocabulary.

Outside all four layers sit relying parties. These are the businesses, agencies, and organizations that receive credential presentations. They are bound by general data protection law, such as the GDPR in Europe and the Privacy Act in New Zealand and Australia, but they are not, in most jurisdictions, bound by the trust framework itself unless they are also operating an accredited service. Closing this gap is one of the most consistent open policy questions across credential programs. See Policy considerations for the design choices it opens up.

This four-layer view lets you point precisely at where each policy question lives, rather than collapsing them all into a single "decentralized identity" conversation. Most of the policy work sits at the issuing authority and trust framework layers. The issuance platform and facilitation mechanism are largely technical, operating to standards set by the layers above them.

Why architectural shifts matter for governance

Each era's safeguards were designed for that era's architecture. When governance instruments from earlier eras are carried forward unchanged, two failure modes follow.

The first is over-collection by reflex: treating a decentralized system as if it were federated and requiring providers to log, retain, or report on individual transactions. This recreates the surveillance properties the architecture was specifically designed to eliminate.

The second is under-protection by assumption: treating decentralization as if it solved every privacy and integrity question on its own. It does not. The new architecture moves the locus of risk away from the identity provider's database and onto the relying party's intake form. If the relying party asks for more than it needs, the holder presents more than necessary, and the data ends up retained in places the architecture cannot reach.

The work of policy in era three is to move the safeguards to where the risks actually sit.

Six shifts in governance focus

Common pitfalls when adopting a decentralized model

Practitioners new to the model often carry forward instincts that no longer serve. Among the most common:

• Logging all verification events centrally, because that is how oversight worked before. This breaks the architecture's privacy guarantees and is often prohibited by the trust framework rules that govern it.
• Requiring every credential to be checked against a live issuer endpoint at presentation time. This re-creates the federated dependency the model was designed to eliminate. Use offline-verifiable signatures and published status lists instead.
• Asking for full credentials when only a single attribute is needed. This pushes the data-minimization principle outside the architecture's enforcement zone. Use selective disclosure by default.
• Treating the wallet as a passive container. In era three, the wallet enforces issuer policy, mediates user consent, and represents the holder. It is a governance-bearing component, not just a user interface.
• Assuming the technology alone delivers privacy. It does not. The architecture removes specific risks (issuer-side surveillance, central correlation) but does not address what relying parties do with the data once they receive it. That work happens in issuance policy, accreditation, and trust framework rules.

What this means for policy makers and stakeholders

Decentralized trust does not reduce the need for governance. It changes where governance is applied and what instruments are available.

The strongest protections in a decentralized ecosystem come from designing the system so that misuse is technically constrained, not from adding compliance obligations on top of an architecture that already permits the harm. Where policy work is grounded in the architecture, the resulting safeguards are durable, technically enforceable, and proportionate. Where it is not, safeguards either become compliance overhead that the architecture has already made redundant, or they reintroduce surveillance properties the architecture was specifically designed to remove.

For policy makers, governance bodies, and ecosystem stakeholders, the recommendation is to use the architecture. Decide what claims may be issued, by whom, to whom, and under what conditions. Specify selective disclosure as the default. Treat trust frameworks and accreditation as primary instruments. Move oversight from transactional logging to aggregate metrics and incident reporting. Recognize that the harder work is not the technology. It is building the institutional capability to operate the ecosystem well: revocation operations, accreditation compliance, relying-party oversight, fraud response, and equity and access management.

The technology is ready. The standards are in place. The remaining work is governance, and it is the right hard work to do.

Frequently asked questions

What is a decentralized trust model?

A decentralized trust model is an approach to digital identity in which an authoritative issuer issues a verifiable credential to a holder's wallet, and the holder presents that credential directly to relying parties without an intermediary in the transaction loop. The credential is cryptographically signed by the issuer so the relying party can verify it independently, and no central party sees where the credential is being used.

How is decentralized trust different from federated identity?

In a federated model, an identity provider authenticates the user and asserts their identity to relying parties, so the intermediary sees every transaction. In a decentralized model, the issuer is out of the loop once the credential is issued. The relying party verifies the credential cryptographically without contacting the issuer, and no party holds a complete record of how a person uses their identity.

What technical standards does decentralized trust rely on?

The decentralized trust model rests on a stack of open international standards. These include the W3C Verifiable Credentials Data Model 2.0 for credential structure, ISO/IEC 18013-5 for mobile driving licenses, SD-JWT VC for selective disclosure, OpenID for Verifiable Presentations (OID4VP) for presentation requests, OpenID for Verifiable Credential Issuance (OID4VCI) for issuance, and the W3C Digital Credentials API for browser integration.

What are the four layers of a credential ecosystem?

A credential ecosystem can be read in four functional layers. The issuing authority decides what may be asserted and holds the revocation mandate. The issuance platform turns those instructions into signed credentials. The trust framework defines accreditation, technical standards, and obligations. The facilitation mechanism, or wallet, holds and presents credentials under the citizen's control. Relying parties sit outside these four layers and are bound by general data protection law.

Does decentralized trust eliminate the need for governance?

No. Decentralized trust does not reduce the need for governance. It changes where governance is applied and what instruments are available. Architectural safeguards do much of the work that contractual rules did in earlier models, but policy is still needed for issuance terms, accreditation, relying party obligations, equity, and enforcement.

Can a decentralized credential be used offline?

Yes. Because the credential carries a cryptographic signature, a verifier can confirm authenticity offline without contacting the issuer for each transaction. Status checks for revocation may require online connectivity depending on the design, but the core verification of issuer authenticity and credential integrity can be performed locally.