Decentralized Identifiers (DIDs) Explained

Most identifiers you use every day belong to someone else. Your email address belongs to your provider. Your username belongs to a platform. Your phone number belongs to a carrier. They can all suspend, reassign, or delete the identifier, and you would have no recourse, because you never controlled it in the first place. A Decentralized Identifier, or DID, is an attempt to flip that: an identifier the subject creates and controls directly, with no issuing authority that can take it away.

DID is a W3C standard, the same standards body behind Verifiable Credentials. The two specifications are designed to work together, and DIDs are a foundational piece of self-sovereign identity.

What a DID actually is

A DID is a string. It looks like this:

did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

It has three parts separated by colons. The first part is the scheme, always did. The second part is the method, here key, which says how this particular DID works. The third part is the method-specific identifier, the actual unique value.

That is the entire surface of a DID: a scheme, a method, and an identifier. Everything interesting happens when you resolve it.

DID documents: what resolution gives you

A bare identifier is not useful on its own. To do anything with a DID, you resolve it, which means looking up its DID document. The DID document is a small structured record that describes how to interact with the subject of that DID.

The most important thing a DID document contains is one or more public keys. It can also list:

• Verification methods. The public keys that can prove control of the DID.
• Authentication entries. Which of those keys are allowed to authenticate as the subject.
• Service endpoints. Optional pointers to where the subject can be reached, for example a credential exchange endpoint.

The public keys are the heart of it. A DID is, in practice, a durable name for a set of keys the subject controls. Resolving the DID tells a verifier which public key to expect, and the subject proves control by signing with the matching private key. The phrase to hold onto is "an identifier you can cryptographically prove you control."

DID methods: how the lookup happens

The method, the second part of the DID, decides how resolution works and where the DID document comes from. There are many methods, and they make very different tradeoffs. Two are worth understanding in plain terms because they cover most practical cases.

did:key

The simplest method. With did:key, there is no lookup anywhere. The identifier itself is a direct encoding of a public key. To resolve it, you decode the string and out comes the key. The DID document is generated on the spot from the identifier, with no network call and no external registry.

This makes did:key ideal when you need a self-contained identifier that works offline and depends on nothing. The tradeoff is that it is static. Because the identifier is the key, you cannot rotate the key without changing the identifier, and there is nowhere to publish extra information like service endpoints. It is perfect for ephemeral or single-purpose use, less suited to a long-lived identity you expect to maintain for years.

did:web

The did:web method anchors a DID to a domain name you already control. A DID like did:web:openkyc.org resolves by fetching a DID document from a well-known path on that domain over HTTPS. If you can publish a file on the domain, you control the DID.

This is pragmatic. It reuses the existing web public key infrastructure and domain ownership, which organizations already understand and manage. Because the document lives on a server you control, you can rotate keys and update service endpoints whenever you need to, just by editing the published file. The tradeoff is that the DID is only as durable and trustworthy as the domain. If you lose the domain, you lose the DID, and whoever controls the domain controls the identifier. For a company identifying itself to partners, that is usually an acceptable and even desirable property.

Between these two, you can see the spectrum the methods occupy. Some prioritize independence from any registry, others prioritize updatability and tie into infrastructure you already run. Choosing a method is choosing a set of tradeoffs, not choosing a different kind of identifier.

How a holder proves control

The mechanism is the same for every method and is worth walking through once, because it is the entire reason DIDs are trustworthy.

1. A subject generates a keypair: a private key kept secret and a public key meant to be shared.
2. The subject's DID is bound to that public key, either by encoding it directly (did:key) or by publishing it in a DID document (did:web and others).
3. When a verifier wants proof, it issues a challenge, typically a random value the subject must sign.
4. The subject signs the challenge with the private key.
5. The verifier resolves the DID, retrieves the public key, and checks the signature.

If the signature verifies against the public key the DID points to, the verifier knows the other party holds the matching private key, and therefore controls the DID. No password crossed the wire, no central authority was asked to vouch, and nothing was stored on a server that could be breached to impersonate the subject. Control is demonstrated by math.

Why this matters for portable identity

The reason DIDs underpin the credential systems we write about is subjects and issuers both need stable identifiers that do not belong to a platform. When an issuer signs a verifiable credential, the credential names the subject by their DID and is signed under the issuer's DID. A verifier later resolves both: the issuer's DID to check the signature on the credential, and the subject's DID to confirm the person presenting it is the one it was issued to.

Because none of those identifiers depend on a single provider staying online or staying in business, the credential stays verifiable even if the company that issued it disappears. That portability is the property repeated, platform-bound identity could never offer. Your identifier is yours, the keys are yours, and the proof works anywhere the DID can be resolved.

A note on maturity: DID methods like did:key and did:web are stable and in real use today. The broader ecosystem has many experimental methods, and not all of them will last. The core idea, a subject-controlled identifier backed by a keypair, is settled even while the long tail of methods is still being sorted out.

Where OpenKYC fits

OpenKYC is building a reusable KYC marketplace on open standards (W3C Verifiable Credentials, OpenID4VC): verify once, hold the credential in your own wallet, reuse it everywhere, and earn every time it is used. DIDs are how the people, issuers, and verifiers in that marketplace name themselves without renting their identity from a platform, which is what keeps a credential portable instead of trapped in one vendor's account system. Join the waitlist at openkyc.org.