Decentralized identifiers, usually shortened to DIDs, are a kind of web address for a person, organization or device that the controller creates and manages without asking a central registry for permission. A DID points to a small public document listing keys and service endpoints, and the controller can update that document over time.
This guide focuses on the identifier itself: how it is written, what the linked document contains, how software looks it up, and how different “methods” store and secure it. Credentials that use DIDs, and the broader philosophy of user-controlled identity, are covered in their own articles on this site.
An Identifier Nobody Hands Out to You
Most identifiers you use are assigned by someone else. An email address depends on a mail provider, a username depends on a platform, and a domain name depends on a registrar. If the provider closes the account or the platform shuts down, the identifier disappears along with every relationship built on it.
A DID reverses that relationship. The controller generates a cryptographic key pair, a matched public key and private key, and derives or registers an identifier tied to it. Control is proven by signing with the private key, not by logging in to someone else’s service.
The W3C Decentralized Identifiers specification defines the common rules. It does not dictate where DIDs live; that choice belongs to individual DID methods. This separation lets the same software handle many storage approaches while keeping one consistent format for the identifier and its document.
Reading a DID From Left to Right
A DID is a text string with three parts separated by colons. It always begins with the scheme “did”, followed by a method name, followed by a method-specific identifier. A hypothetical example looks like did:example:123456abcdef, where “example” is the method and the final segment is unique within it.
- Scheme: the fixed prefix “did” tells software this is a decentralized identifier rather than a web link or email address.
- Method name: a short label such as “web” or “key” that tells software which rules to follow for lookup and updates.
- Method-specific identifier: a value, often derived from a public key or a domain name, that is unique under that method.
- Optional path, query or fragment: additions that point to a specific key or service inside the DID document.
The structure is deliberately plain so that it fits into existing systems such as databases, logs and credentials. A DID by itself usually reveals little about the subject, although web-based methods expose a domain name; it is mostly an opaque label until someone resolves it to its document.
What a DID Document Contains
The DID document is the public record associated with the identifier. It tells anyone who looks it up how to interact securely with the controller. It should contain only public information, because anyone who resolves the DID can read it.
The most important entries are verification methods, which list public keys along with their intended purposes. One key may be authorized for authentication, proving control during a login, while another is authorized for assertion, signing credentials. Separating purposes limits the damage if a single key is compromised.
A document may also list service endpoints, network addresses where the controller can be reached for messaging or credential exchange. These are useful but can expose information, such as a personal server address. Privacy-conscious designs keep endpoints out of documents tied to individuals or use intermediaries that do not reveal location.
Resolution: Turning a DID Into Its Document
Resolution is the process of retrieving the current DID document for a given identifier. Software called a DID resolver reads the method name, applies that method’s rules, and returns the document plus metadata such as when it was created or last updated.
How resolution works depends entirely on the method. Some methods compute the document directly from the identifier, with no network call at all. Others fetch a file from a web server, query a distributed ledger, or read from a peer-to-peer storage network. Each approach brings different reliability and privacy properties.
Resolution can leak information. If a verifier queries a public server every time it checks a credential, the server operator may see which DIDs are being looked up and when. Running a local resolver, caching documents responsibly, or choosing methods that resolve offline all reduce that exposure for both verifiers and holders.
Comparing Common DID Method Families
Many methods have been registered, but most fall into a few families. Knowing the family tells you more about security and trust than the method name alone does. The examples below are categories, not endorsements.
Key-Based Methods
In key-based methods such as did:key, the identifier is derived directly from a public key. Resolution needs no network, which is fast and private. The trade-off is that the document cannot change: if the key is lost or compromised, the identifier must be abandoned. These methods suit short-lived or one-relationship uses.
Web-Based Methods
Methods such as did:web host the document on a web domain. Organizations find this familiar, because they already manage domains and certificates. However, control depends on the domain registrar and hosting provider, so the identifier is only as decentralized and durable as that domain. Losing the domain means losing the DID.
Ledger-Anchored Methods
Some methods record documents or their updates on a distributed ledger, a shared database replicated across many computers. This provides a tamper-evident history of changes without a single host. In return, operations may cost fees, updates may be slow, and anything written to a public ledger is effectively permanent and visible.
Key Rotation and Recovery
Keys age, devices get lost and staff leave organizations. Key rotation means replacing an old key with a new one while keeping the same identifier. Methods that support updates let the controller publish a new document listing the new key and removing the old one.
Rotation only works if the controller still has a valid key to authorize the change. That is why careful designs set up separate recovery keys stored offline or with trusted parties. Without them, losing every active key may make the DID permanently uncontrollable, with no help desk to call.
Organizations should document who may authorize updates, where recovery material is stored, and how a compromise is reported. For individuals, wallets often handle rotation automatically, but it is worth checking whether the wallet offers a backup and how restoration works before you rely on a DID for anything important.
Threats to DID Control
Because control rests on private keys, most attacks target keys or the systems that publish documents. Malware on a phone or laptop may try to copy key material. Phishing pages may imitate a wallet and ask the user to approve a signature that actually authorizes a document update.
Method-specific weaknesses matter too. A web-based DID can be hijacked if an attacker takes over the domain or its hosting account. A ledger-anchored DID may be affected by problems in the underlying network. Each method’s specification should describe its security assumptions, and reviewers should read that section carefully.
Defensive basics apply: keep keys in hardware-backed storage where available, require confirmation for document updates, monitor DID documents for unexpected changes, and protect domain and hosting accounts with strong multifactor authentication. Logging every update gives investigators a trail if something goes wrong.
Correlation and Privacy Considerations
A DID that you reuse everywhere becomes a universal tracking key. If you present the same identifier to a bank, a retailer and a social site, those parties could link your activity simply by matching the string. Decentralization of control does not automatically mean privacy.
A common mitigation is the pairwise DID, a different identifier created for each relationship. Your bank sees one DID, the retailer sees another, and neither can link them through the identifier alone. Key-based and peer-style methods make pairwise identifiers cheap to generate.
Public DIDs still make sense for organizations, which want to be found and recognized. Universities, licensing boards and companies benefit from stable, public identifiers so verifiers can confirm credentials they issue. The general guideline is public DIDs for institutions, pairwise or private ones for individuals.
Where DIDs Fit in the Wider Identity Stack
DIDs are a building block, not a complete identity system. On their own they prove control of a key, not anything about the real-world person behind it. Claims such as name, age or qualifications come from verifiable credentials that reference DIDs for the issuer and sometimes the subject.
They also coexist with established technologies. X.509 certificates, the basis of HTTPS and many corporate systems, bind keys to names through certificate authorities. OpenID Connect provides login through identity providers. Some deployments combine these, for example linking an organization’s DID to its web domain and certificate.
Understanding this layering helps avoid inflated expectations. A project that “uses DIDs” may still rely on a central party for identity proofing, governance or recovery. Ask which parts are decentralized, which are not, and who can change or revoke what.
Evaluating DIDs for a Project
Teams considering DIDs should start from requirements rather than enthusiasm. Ask whether identifiers must survive the end of a vendor relationship, whether offline verification matters, and whether the people involved need pairwise privacy. Those answers narrow the suitable methods quickly.
- List which parties need public, discoverable identifiers and which need private ones.
- Choose methods your expected wallets, issuers and verifiers already support.
- Define key management, rotation and recovery procedures before launch.
- Decide whether resolution will be local, hosted, or through a trusted resolver service.
- Review what each DID document publishes and remove anything that is not essential.
Testing with real wallets and verifiers early reveals interoperability gaps that specifications alone hide. Pilot with a small group, monitor resolution failures, and confirm that recovery works by actually performing it, not just by documenting it.
Next Steps for Learners and Builders
If you are new to the topic, read the W3C DID specification’s introduction and examples, then compare two or three method specifications to see how differently they handle updates. That comparison builds intuition faster than any summary can.
Developers can experiment with open-source libraries that generate key-based DIDs and resolve web-based ones in a test environment. Keep test keys separate from anything used in production, and never publish private keys in sample code or repositories.
For everyday users, the most relevant habit is awareness. When a wallet or service mentions DIDs, ask how your keys are backed up, whether identifiers are unique per service, and what happens if you switch wallets. Clear answers to those questions indicate a design that respects your control.