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.

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.