did:web explained
Every digital credential is signed by someone, and a verifier has to be able to look up who that someone is and which keys they are using today. did:web answers that with the piece of infrastructure almost every organisation already has: its own domain name. The identifier tells you which domain to ask, the answer is an ordinary file served over HTTPS, and nothing else has to exist for it to work.
What did:web actually is
A DID is a permanent identifier that anyone can look up to find the public keys belonging to whoever holds it. A DID method is the rule for doing that lookup, and there are dozens of them. Some write the record onto a blockchain, some onto a purpose-built network, and each one obliges a verifier to learn how that particular system works.
did:web takes the opposite route. The lookup is an HTTPS request to the domain named in the identifier, and the record is a JSON file the domain owner publishes and edits like any other page on their site. There is no network to join, no ledger to write to and no fee to pay.
That is why it turns up so early in almost every project. A team that can deploy a file to their web server can be issuing and verifying credentials the same afternoon, and the identifier they end up with is a real DID that any conformant wallet or verifier will accept, not a stand-in to be replaced later.
How the identifier becomes a URL
The mapping is mechanical, which is the point. A bare domain resolves to a file in the well-known directory that sites already use for machine-readable metadata. Add colon-separated segments after the domain and they become path segments instead, so one organisation can publish a separate identifier per department, per environment or per issuing service without registering anything new.
Two details catch people out. A port number has to have its colon percent-encoded, because a plain colon already separates the parts of the identifier. And the file must be served over HTTPS with a certificate that validates, since the transport is the only thing standing between a verifier and a forged answer.
The identifier someone gives you
did:web:example.com:issuer:euThe HTTPS URL it maps to, with no lookup service in between
https://example.com/issuer/eu/did.jsonThe DID document that comes back, holding the keys and endpoints
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Why organisations choose it
The first reason is recognition. A verifier that sees an identifier pointing at a company domain can check, in the plainest way there is, that the name on the credential matches the name on the website. No registry lookup and no chain of certificates has to be explained to anyone before that lands.
The second is that it costs nothing to run. The document sits behind the same hosting, the same monitoring and the same change process as the rest of the site. There is no separate system to fund, to keep available or to explain to an auditor, and rotating a key is a deployment rather than a transaction.
The third is portability. Because every wallet and verifier library supports it, did:web is the method most likely to work against a partner you have never integrated with before, which makes it the natural choice for pilots, test environments and the interoperability events where European wallet implementations meet.
Where did:web stops
Everything the method gives you rests on the domain. Whoever controls the registration, the name servers and the certificate controls the identifier, so a lapsed renewal, a hijacked DNS account or a mis-issued certificate is enough to speak in your name. There is no second signature underneath to fall back on.
It also has no memory. A verifier sees the document as it is right now and has no way to learn what it said last week, so a replaced key is indistinguishable from a rotated one. did:webvh exists precisely for that: the same web hosting, plus a signed and append-only log of every change, so a verifier can follow the history from the first entry to the current state.
And it is not an identity check. Publishing a document under a domain proves control of that domain and nothing more. When a verifier has to know that a legal entity is who it claims to be, that assurance comes from a trusted list, a qualified certificate or a trust framework built for the purpose, with the DID method only carrying the keys underneath.
What this means for you
Issuer
Treat the document as production infrastructure from day one. Put it under change control, monitor that the URL answers and that the certificate is valid, and keep a retired key listed for verification as long as anything it signed is still in use.
Relying party
Fetching the document is not the same as trusting it. Decide separately which domains you accept, refuse anything whose certificate does not validate, and cache carefully: a stale copy keeps a revoked key alive, a missing one takes your service down with the other side.
Wallet holder
The domain in an issuer identifier is worth a glance. It is the one part of a credential you can read without any tooling, and a name that does not match the organisation you expected is a reason to stop rather than to continue.
Related terms
Frequently asked questions
Do I need special software to resolve a did:web identifier?
No. The identifier is a recipe for building a URL, and fetching that URL over HTTPS returns the document. Any HTTP client can do it, which is why did:web is usually the first method a team gets working. A general-purpose resolver library is still worth using in production, because it applies the encoding rules and the checks on the document consistently rather than leaving them to each caller.
Is did:web less trustworthy because there is no blockchain?
It is differently trustworthy. A ledger-based method spreads the record over many parties so that no single one can quietly rewrite it. did:web puts that responsibility on the domain owner and the certificate authorities behind their TLS. For an organisation whose name and website are already what customers recognise, that is often the honest place for the trust to sit, as long as everyone understands the domain is the weak point.
What happens to credentials already issued when the keys change?
A verifier fetches the document as it stands now, so a credential signed with a key that has since been removed no longer verifies. Keep a retired key in the document, marked so it can verify but no longer sign, for at least as long as the credentials it signed remain valid. If you need a verifier to be able to prove which key was current on a given date, that is the point at which did:webvh earns its extra complexity.
Sources
This page is informational and does not constitute legal advice. For authoritative guidance consult the W3C specifications directly.