Decentralized identity is the trust triangle made computable. The DID is the identifier. The verifiable credential is the data model. The wallet is the surface. The resolver is the bridge. The operating model is what keeps the issuer-holder-verifier ecosystem honest.
§ 01 ·
Decentralized identity is the discipline of separating identity from the issuer. The user controls the identifier; the user controls the credential. The issuer signs the credential; the verifier validates the credential. The trust triangle is the architectural primitive.
The trust triangle has three roles.
The triangle is computable: the issuer's signature is verifiable without contacting the issuer. The triangle is portable: the holder can move a credential between wallets without contacting the issuer. The triangle is privacy-preserving: the verifier learns only what the credential claims.
Two failure modes recur.
The right design is the triangle where the holder is the principal, the issuer is a service, and the verifier is the consumer.
§ 02 ·
The architectural primitives that have held up.
Three roles, connected by three relationships. The issuer signs a claim about the holder. The holder presents the claim to the verifier. The verifier validates the signature against the issuer's public key. The triangle is the architectural primitive; the relationships are the contract.
The DID (decentralized identifier) is the identifier. The DID method is the resolution mechanism (how the DID resolves to a DID document that contains the public keys). The DID is portable: the holder can update the DID document without changing the DID. The DID method is the trust anchor: the verifier trusts the DID method that produces the public key.
The verifiable credential is the data model. The credential is a signed JSON-LD document that contains claims about the holder. The signature is the trust anchor: the verifier validates the signature against the issuer's public key. The credential is portable: the holder can move it between wallets without contacting the issuer.
The wallet is the holder's interface. The wallet holds the credentials, controls the DIDs, and generates the presentations. The wallet is the surface where the holder exercises control. The wallet is the boundary the user actually experiences.
The resolver is the bridge between the DID and the DID document. The resolver takes a DID and returns the DID document. The resolver is the service that the verifier depends on. The resolver is the threat model: a compromised resolver can return a fraudulent DID document.
The triangle, the DID, the credential, the wallet, and the resolver are the architectural primitives. The relationships between them are the contract. The issuer is responsible for the credential; the holder is responsible for the wallet; the verifier is responsible for the validate.
§ 03 ·
§ 04 ·
Different problems.
The two can compose: a wallet can present a DID-anchored credential to a verifier that trusts the issuer. The credential is the bridge.
With explicit, documented criteria.
The criteria are documented; the choice is reviewed when the issues change.
Depends on the credential pattern.
The pattern is documented; the choice is reviewed when the security model changes.
With the same discipline as any other user-facing surface.
A wallet that is hard to use is a wallet that the user works around. The work-around is the failure mode.
§ 05 ·
A wallet that is built as a product, not as a holder interface, locks the holder to the wallet operator. The portability that is the triangle's value is gone. The holder is the principal; the wallet is the surface. The surface is replaceable.
An issuer that is a single vendor produces a credential that is portable but an issuer that is not. The dependency on the issuer is the same dependency on the centralised identity provider that the triangle was supposed to replace. The issuer is a service; the issuer is replaceable.
A credential that has no status mechanism is a credential that cannot be revoked. A credential that cannot be revoked is a credential that is wrong forever. The status mechanism is part of the credential; the verifier validates the status.
A resolver that is queried without a trust model is a resolver that can return a fraudulent DID document. The resolver is the bridge between the DID and the DID document; the trust model is the bridge between the resolver and the public key.
A presentation that reveals the entire credential bundle is a presentation that reveals more than the verifier needs. The presentation is the disclosure: the holder discloses only what the use case requires. The selective disclosure is the architecture.
§ 06 ·
Public standards and writing that inform our practice.
The data model. The most useful of the decentralized identity standards because it is the data model, not the presentation, and because it is verification-standard-shaped (you can test against it), not a checklist.
The DID specification. The DID method is the resolution mechanism; the DID document is the trust anchor. The standard is the contract; the DID method is the implementation.
The framing of the issuer as a service, not a vendor. The book's contribution is the reframing of the trust triangle as an architectural primitive, not a vendor relationship.
The founding essay. The framing of self-sovereign identity as the holder's control over the identifier, the credential, and the wallet. The framing is the contribution; the specific architecture has evolved.
The reference implementation of a government-anchored decentralized identity system. The architecture (issuer registry, wallet, presentation) is the contribution; the political model is separate.
Weighing a decentralized identity initiative, designing a credential lifecycle, or trying to make the issuer-holder-verifier ecosystem measurable? Useful at the boundary between the holder and the verifier. A short conversation is the right next step.
Learn more