DID explained: what a Decentralized Identifier is
A Decentralized Identifier, almost always written DID, is a name for a party that nobody has to issue and nobody can take back. It is the answer to a question every digital credential runs into sooner or later: the wallet is holding a signed statement, so who signed it, and how do you check that without writing to whoever keeps the register?
This page is the plain-language version. It covers what a DID is made of, what happens when one is looked up, how the common methods differ and, just as importantly, what a DID on its own does not tell you.
What a DID is made of
A DID is one line of text in three parts, separated by colons. The first part never changes. The second names the method, and the third is whatever that method needs in order to find the right document.
That middle part is the only real decision. Everything people mean when they argue about DIDs, where the data sits, who can change it, what it costs to keep running, is decided by the method and by nothing else.
did:web:credenco.com
did
Scheme
Always the same three letters. It says nothing more than: what follows is a Decentralized Identifier.
web
Method
The rules for finding and updating the document. This is the choice that carries real consequences, because it decides who has to keep the identifier reachable.
credenco.com
Method-specific identifier
The part only that method knows how to read. Here it is a domain name, elsewhere it can be a ledger entry or the public key itself.
What happens when one is looked up
On its own a DID does nothing. Its value appears at the moment somebody resolves it: turns the string into the small document behind it, which lists the public keys its subject is using and where the subject can be reached.
1. You have an identifier
A credential arrives naming the party that signed it. So far that is a string, and it proves nothing.
2. A resolver reads the method
The method name tells the resolver where to go: fetch a file from a domain, read a ledger, or unpack the key from the identifier itself.
3. A document comes back
It lists the public keys the subject is using now, and the endpoints where it can be reached.
4. You check the signature
With no account anywhere, no API key, and no request for permission from whoever runs the method.
Why not a domain name or a certificate
The web already has ways to say who somebody is, so the fair question is what a DID adds. A domain name tells you where to send a request, but it says nothing about which keys belong to the party behind it. A certificate does bind a key to a name, and does it well, but only for as long as an authority keeps saying so and only for the key it was issued for.
A credential has an awkward habit of outliving both. A diploma is still a diploma in twenty years, long after the signing key has been rotated and the certificate that covered it has expired. Because a DID separates the name from the keys, the issuer can replace a key without the identifier changing and without reissuing everything it has ever signed.
Keys change, the name does not
Rotating a compromised key means publishing a new document at the same identifier. Every reference to the issuer stays valid.
Checking needs nobody’s permission
A verifier resolves the identifier and checks the maths. There is no account to open with the issuer and no rate limit on somebody else’s service.
The methods you will actually meet
Well over a hundred methods have been registered, and you can safely ignore almost all of them. Three cover nearly everything an organisation in the European ecosystem runs into.
did:web
The document is a file on a domain you already control. Nothing new to run, and the cost of entry is close to zero, which is why most organisations start here. The catch is that whoever controls the domain controls the identifier, and there is no record of what the document said yesterday.
Read the definitiondid:webvh
The same domain-hosted file, plus an append-only log of every version it has ever had. A verifier can see that the key it is trusting today was put there by the party that held the identifier yesterday, which is the gap did:web leaves open.
Read the definitiondid:key
The identifier is the public key, encoded. There is nothing to host and nothing to fetch, which makes it ideal for short-lived and throwaway identities. It also means the key can never be rotated, so it is the wrong choice for anything meant to last.
The rest are listed in the W3C registry of DID methods. Treat a method that is not in it, or that only one product supports, as a dependency on that product.
What a DID does not tell you
This is where most DID explanations quietly stop, and it is the part that decides whether a wallet programme works. A DID proves continuity: the party that signed this credential holds the same key as the party that signed that one. It proves nothing about who that party is in the world.
Anyone can create a DID in a few seconds, including someone impersonating a university. Deciding that an identifier really belongs to an accredited institution is a separate job, done by a trusted list, a qualified certificate, or an attestation from a party the verifier already trusts. Under eIDAS 2.0 that is exactly what the trusted lists and the registration of relying parties are there for.
Read the two together and the picture is straightforward: the DID carries the keys, the trust framework carries the meaning, and a verifier needs both before it accepts anything.
What this means for you
Issuer
One identifier that survives every key rotation, so a credential you signed years ago is still checkable and a compromised key is an operational job rather than a recall.
Verifier
You can check a signature without an account, a contract or an integration per issuer. What you still need is a trusted list telling you which identifiers to accept.
Wallet holder
Nothing to manage. The identifiers sit inside your credentials, and the wallet resolves them for you when it shows you who issued what.
Related terms
Frequently asked questions
Do you need a blockchain to use DIDs?
No. That association comes from the methods that were built first, not from the standard. The specification says nothing about where a document has to live, and the methods in everyday use in Europe, did:web and did:webvh, are both files served over ordinary HTTPS from a domain their owner already has.
Why not just use a domain name?
A domain says where to find something, not which keys belong to it, and a certificate ties keys to a name for as long as an authority says so. A DID gives you both parts at once and keeps the identifier stable while the keys behind it change, which is what makes a credential signed three years ago still checkable today.
Which method should we choose?
Start from how long the identifier has to hold and who is allowed to change it. For an issuer whose credentials outlive their keys, did:webvh gives verifiers the history they need to trust a rotation. For internal pilots and short-lived identities, did:web or did:key is usually enough, and moving later is an ordinary migration rather than a rebuild.
Does a DID prove that an organisation is who it claims to be?
No, and treating it as if it did is the most common mistake. A DID proves that whoever signed two things held the same private key. Whether that key belongs to an accredited university or to somebody who registered a convincing domain is a separate question, answered by a trusted list, a qualified certificate or an attestation from a party you already trust.
Sources
This page is informational and does not constitute legal advice. Consult the W3C specification directly for the authoritative wording.