DID Method

DID Method is the ruleset that makes a particular family of decentralized identifiers actually work. Every DID carries a method name in its second segment — for example did:web:example.com or did:key:z6Mk... — and that name tells software which method specification governs the four core operations: create, resolve (read), update, and deactivate. Without a method, a DID is just a string with a prefix; the method is what binds it to a verifiable source of truth that a resolver can consult and a verifier can check.

Why methods differ

The W3C DID Core specification deliberately refuses to mandate a single backing system. It defines a common data model — every DID resolves to a DID Document containing keys and service endpoints — and lets each method choose where control actually lives. Some methods anchor identifiers to a blockchain, gaining tamper-evident history at the cost of that chain's fees and governance. Some, like did:web, anchor to a web domain: trivially self-hostable, but only as trustworthy as DNS and TLS. Some, like did:key, derive the entire identifier deterministically from a public key with no external registry at all — nothing to host, nothing to query, but also nothing to update. The DID Specification Registries track conforming methods so resolvers know how to dereference each one, and the list runs to well over a hundred, which tells you something: the hard part of decentralized identity was never the identifier format, it was agreeing on the root of trust.

Trade-offs a sovereign user weighs

Choosing a method is a self-custody decision dressed up in standards language: who, if anyone, must you trust to keep your identifier resolvable and under your control? A purely key-derived method needs nothing but the key — but it cannot rotate that key, so a compromise is unrecoverable, exactly like a leaked private key on Bitcoin. A ledger-anchored method survives key rotation and supports revocation, but inherits the ledger's liveness, fee, and governance assumptions — if the ledger dies or forks, your identity's history goes with it. A domain-based method costs nothing and runs on your own server, but a registrar, a court order, or a lapsed renewal can take it from you; anyone who has watched a domain seizure understands the failure mode. There is no free lunch, only a choice of which dependency you can live with and verify.

The Bitcoiner's lens

Nostr made the opposite bet, and the comparison is instructive. A Nostr identity is a bare keypair — effectively the did:key philosophy without the ceremony: no registry, no resolution, no rotation, maximum sovereignty, and the same brutal consequence if the key leaks. DID methods exist for the cases where that is not enough — where you need key rotation, organizational control, revocation, or interoperability with credential ecosystems like verifiable presentations. The sovereign instinct applies unchanged: prefer methods whose root of trust you can run and audit yourself, treat every dependency in the resolution path as an attack surface, and remember that an identifier someone else can un-resolve is an identifier you only rent. The principle is the same one behind self-custody of coins: control is defined by what you can do without permission.

In practice

For most self-hosters experimenting today, two methods cover the ground: did:key for ephemeral or device-bound identities where rotation does not matter, and did:web for organization-level identifiers served from infrastructure you already run. Ledger-anchored methods earn their complexity only when you genuinely need long-lived, rotatable, publicly auditable identity — and when you have honestly answered the question of what happens to your identity if that ledger's future differs from its roadmap.