DID Document

A DID Document is the payload you get when you resolve a decentralized identifier. It is the serialization of the DID data model — typically a JSON or JSON-LD object — and it answers the only questions a verifier really cares about: which keys can speak for this identifier, and where can I interact with its subject. Everything else in the decentralized-identity stack ultimately reads from this document. If a decentralized identifier (DID) is a name, the DID Document is the name's public record — the thing that turns an opaque string into verifiable cryptographic reality.

What the document contains

The core components are verification methods — public keys or other cryptographic material used to prove control of the DID; verification relationships — declarations of which keys are authorized for which purposes, such as authentication (logging in as the subject), assertionMethod (signing credentials), and keyAgreement (establishing encrypted channels); and service endpoints — network locations for trusted interactions with the subject, such as messaging or credential exchange. A controller field records who is authorized to change the document, which need not be the subject itself — a parent controlling a child's identifier, or an organization controlling a device's. The separation of keys by purpose is deliberate hygiene: the key that authenticates you should not be the key that signs your attestations, so compromising one does not compromise all. Documents also carry their own identifier in an id field, and JSON-LD serializations add a @context that pins the vocabulary, which is what lets software from different vendors parse the same document identically — interoperability lives or dies on this shared data model, not on any particular blockchain or registry.

Resolution: how you obtain it

You never fetch a DID Document from a fixed URL the way you fetch a web page. Instead, the DID's method — the middle segment of the identifier — defines a resolution procedure, and the governing DID Method determines everything about the document's storage and trust properties. A did:web document is a JSON file served from a domain you control, inheriting the trust profile of DNS and TLS. Ledger-anchored methods store the document (or a pointer to it) on a blockchain. Key-derived methods generate the entire document deterministically from the identifier itself, so nothing is stored anywhere. Same data model, radically different sovereignty trade-offs — which is why choosing a method is really choosing who can interfere with your identity.

Why it matters for self-custody

Because the document is the single source of truth for an identifier's keys, controlling the document is controlling the identity. A sovereign user should be able to answer two questions precisely: where does my DID Document live, and who can rewrite it? Key rotation, revocation, and adding services are all just edits to this document — which is a feature, because it means identity recovery does not require asking a platform's support desk, and a threat, because whoever holds write access can silently swap your keys for theirs. The document's integrity and resolution path are the real trust boundary of the whole system, the same way the seed phrase is the real boundary of a Bitcoin wallet regardless of how polished the app on top looks.

The keystone role

Every higher layer leans on this object. When someone presents a verifiable credential, the verifier resolves the issuer's DID, pulls the document, and checks the signature against a key listed under the right verification relationship; the same dance validates the holder's verifiable presentation. No document, no verification. It is the quiet keystone of the architecture — rarely seen by users, read by every verifier, and worth exactly as much as the method and custody practices protecting it.