did:web

did:web is the most pragmatic on-ramp to decentralized identity: a DID method that anchors a decentralized identifier to a web domain you already control. An identifier like did:web:example.com resolves by fetching https://example.com/.well-known/did.json, and a path-based form like did:web:example.com:user:alice maps to the corresponding URL path on the same host. No blockchain, no token, no registry fee, no consortium — just a static JSON file served over TLS from infrastructure you run. For anyone who already administers a domain, the barrier to a working decentralized identifier is one file upload.

How resolution works

Resolution is a mechanical text transformation. A resolver takes the method-specific identifier, swaps colons for slashes, percent-decodes any port, prepends https://, and appends did.json (adding .well-known for bare domains). It then fetches that URL and treats the returned JSON as the DID document — the record listing the identifier's public keys, verification methods, and service endpoints. Updating is just editing the file in place: the DID string stays constant for life while you rotate verification keys or add endpoints behind it. That indirection is the entire value proposition of a decentralized identifier — a stable name whose cryptographic material can change — delivered here with nothing but a web server. The method spec deliberately defines no HTTP API for registration or management; how the file gets written is your business and your tooling. Nothing stops a single domain from hosting many identifiers — one per employee, service, or device under distinct paths — which makes the method a cheap, self-administered namespace for organizational key distribution.

The trust model, honestly stated

did:web inherits the web's security stack wholesale, for better and worse. Trust rests on three legs: DNS says which server the domain names, TLS (via the certificate-authority system) says the connection is authentic, and the file's contents say what keys speak for the identifier. There is no independent verifiability beyond that — a resolver trusts whatever the server serves at that moment. That means no built-in history or audit trail: a server compromise, a coerced host, or a malicious admin can silently rewrite the document, and past states leave no cryptographic trace. Ledger-based DID methods exist precisely to close those gaps, paying for tamper-evidence with infrastructure complexity. did:web makes the opposite trade, and it is honest about it.

Sovereignty trade-offs

For a self-hoster, the appeal is that you are the registry. No third-party ledger, no fee, no gatekeeper between you and your identifier — the same logic as running your own node or serving your own website. The cost is that the identifier's durability equals your domain's durability: lose the DNS registration, the hosting, or the ability to obtain certificates, and the DID stops resolving; lose the domain to an adversary and they become the DID. Domain renewal is thus part of key management. The sober summary: did:web offers excellent verifiable identity for organizations and self-hosters who already maintain domains — a natural fit for a business publishing keys its counterparties can check — and a weak fit where censorship resistance, key-loss recovery, or independence from DNS and certificate authorities is the actual requirement.

Where it fits in the stack

In the broader self-sovereign identity architecture, did:web plays the role of a practical issuer and service identifier: the document it serves is what lets others verify signatures on a verifiable credential you issue or authenticate the endpoints you operate. Many deployments pair it with stronger methods where the threat model demands — organizational identity on did:web, personal identity elsewhere. As a first step out of platform-owned accounts and toward identity you operate yourself, publishing a did.json on a domain you control is about as low-friction as sovereignty gets.