DID (Decentralized Identifier)

A DID is a W3C-standardized identifier that resolves to a document containing public keys and service endpoints, letting the identified party prove control cryptographically without a central registry. DID methods define where the document lives; did:web, for example, anchors it at a domain the controller operates, trading decentralization for operational simplicity.

The method is where the trade-offs live. A did:web document is fetched over HTTPS from a domain, which means it inherits that domain's trust and its failure modes, and it can be rotated by whoever controls the host. Ledger-anchored methods remove that dependency at the cost of operating or trusting a ledger.

For an enterprise publishing verification keys, the operational simplicity of a domain is usually the deciding factor.

The method is where every trade-off lives, and comparing methods is more useful than comparing the abstraction. A did:web document is fetched over HTTPS from a domain, so it inherits that domain's trust, its outages and its transfer process; whoever controls the host controls the keys, which is either the point or the problem depending on the deployment.

Ledger-anchored methods remove the domain dependency and replace it with a ledger that has to be operated or trusted, along with its own governance and cost model. Neither choice is universally right, and a system that resolves several methods inherits the weakest assumption among them, which is an argument for deciding the accepted set deliberately.

Key rotation is the operational detail that decides whether any of this survives a few years. The document publishes current keys, so a rotation is a document update, and a verifier checking an old signature needs to know which key was current at signing time. Without that history, rotation silently invalidates past verifiable credentials, which is the opposite of what rotation is for.

Recording the key alongside the artifact it signed, rather than resolving the current document and hoping, is what keeps a rotation from rewriting history.

The identifier is the anchor a verifiable credential names as its issuer, which is why key history matters to both.

Method choice also decides who can rotate keys, which is a governance question as much as an attestation one.