did:web

The did:web method is the most pragmatic on-ramp to decentralized identity: it ties a DID Document to a web domain you already control. An identifier like did:web:example.com resolves by fetching https://example.com/.well-known/did.json, while did:web:example.com:user:alice maps to a path-based URL. No blockchain, no token, no registry fee — just a static JSON file served over TLS.

How resolution works

A resolver mechanically transforms the method-specific identifier into an HTTPS URL, retrieves the did.json, and treats its contents as the DID Document. Updating the identifier means editing that file in place: the DID string stays constant while you can rotate verification keys or add service endpoints. The method spec intentionally defines no HTTP API for registration or management, leaving that to each host's own tooling.

Sovereignty trade-offs

For someone who runs their own server, did:web is appealing precisely because it needs no third-party ledger — you are the registry. The cost is that its durability equals your domain's durability: lose the DNS registration, the hosting, or the TLS certificate and the identifier stops resolving. There is also no built-in cryptographic history, so a server compromise can silently rewrite the document. It is excellent for organizations and self-hosters who want verifiable identity without external dependencies, and weaker where censorship-resistance or key-loss recovery matter most.

did:web is one of dozens of methods governed by a DID Method specification, and the document it serves underpins any later verifiable presentation.