What are Decentralized Identifiers (DIDs)?
Decentralized Identifiers, usually called DIDs, are a way to identify a person, organization, device, or even a digital object on the internet without depending on a single central provider. Instead of having your identity “live” inside one platform, a DID is designed so you (or your organization) can control it directly, typically using cryptographic keys.
If you have ever thought “I want an identifier that works across systems, that I can prove I control, and that no company can turn off”, you are very close to the core idea behind DIDs.
A simple definition
A Decentralized Identifier (DID) is a unique identifier that can be verified cryptographically and resolved to a document that describes how to interact securely with the DID’s owner or subject.
A DID often looks like this:
did:method:some-unique-string
That middle part, the method, matters a lot, because it tells systems how the DID is created, stored, and resolved.
Why DIDs exist
Traditional identifiers are usually issued and controlled by someone else: an email address is tied to an email provider, a username is tied to a platform, many “login identities” depend on centralized identity providers…
These can work well, but they come with tradeoffs: lock in, platform dependency, and sometimes a lack of portability.
DIDs were created to support a different model: verifiable digital identity where control can sit with the DID owner (or controller), not with a central registry or single provider.
The key idea: a DID resolves to a DID Document
A DID is not just a random string. The most important feature is that it can be resolved into a machine-readable document, usually called a DID Document.
A DID Document typically includes things like:
- Verification methods (often public keys) that help prove control of the DID
- Controllers – who is allowed to update the DID Document, depending on the method
Think of it like this:
- The DID is the identifier you share.
- The DID Document is what other systems fetch to learn how to verify you and how to interact with you.
What “decentralized” actually means here
“Decentralized” does not automatically mean “blockchain”.
With DIDs, decentralization is achieved through DID methods, and different methods use different infrastructure. For example:
- Some methods use web infrastructure (like domains and HTTPS)
- Some methods are key based and do not need a registry
- Some methods use distributed systems (including blockchains or similar ledgers)
- Some methods are designed for peer to peer relationships and private interactions
So the DID format is shared, but the underlying system can vary a lot.
DID methods, in plain English
A DID method is basically the rulebook for how a DID works.
It defines things like:
- How the DID is created
- How the DID Document is found (resolution)
- How keys can be rotated or updated
- How the DID can be deactivated
- What the trust and governance assumptions are
Here are a few common examples you will see in real projects:
did:web
This method links a DID to a domain you control and uses standard web hosting and HTTPS to publish the DID Document. It is popular because it is simple to deploy and easy to understand.
did:key
This method derives the DID directly from a public key, which makes it very easy to generate and use. It is often used in demos, testing, and some ecosystems as a lightweight identifier.
peer DIDs
Peer DIDs are designed for private relationships, where you might want a unique DID per connection to reduce correlation and improve privacy.
There are many more, and choosing the right method is a product and security decision, not just a technical detail.
How DIDs are used with Verifiable Credentials
DIDs are commonly used in Verifiable Credentials ecosystems.
A typical flow looks like this:
- An issuer issues a credential and signs it.
- A holder stores it and later presents it.
- A verifier checks the signature and the issuer’s authenticity.
- A Status List can indicate if the credential has been revoked or not by its issuer.
Where do DIDs come in?
- The issuer can be identified by a DID.
- The verifier can resolve that DID to fetch keys for verification.
- The holder can also use a DID in order to identify himself (proof of possession), depending on the use case and privacy goals.
This is one reason DIDs are so often discussed alongside credentials: they help make verification work across organizational boundaries without forcing everyone into one identity platform.
Common real world use cases
DIDs can be used for:
- Educational and professional credentials (diplomas, certificates, licenses)
- Other types of credentials, e.g. supporting documents
- Organization identity for cross company verification
- Wallet to service interactions in credential platforms
- Secure messaging and discovery (finding the right keys and endpoints)
- Device and IoT identity (where managing identities at scale matters)
- Public sector identity frameworks that need interoperability