A decentralized identifier is an ID the user controls directly, proven with cryptography, instead of one handed out and looked up by a central authority. It underpins self-sovereign identity, where a person can prove they own an identifier without relying on a central database.
What is a DID, in plain English?
A decentralized identifier is an identity the user owns and controls directly, rather than one issued and stored by a central authority. Instead of a bank or government holding the record and looking you up, the user holds a cryptographic key that proves control of the identifier. Ownership is demonstrated by signing with that key, not by a lookup in someone else's database.
DIDs are the technical foundation of self-sovereign identity, the idea that a person can carry and prove their own identity without depending on a single central provider. In practice they rarely stand alone; they usually appear alongside verifiable credentials, which are the signed attestations, such as proof of age or address, that a DID can present and prove ownership of.
It is worth being plain that adoption is still early. The standards exist and the model is promising, but real-world use in fraud and AML workflows is limited today. For an operator, the useful thing is to understand what changes when identity control shifts to the user, and where the new risks land.
Centralized identifier versus DID
What changes | Centralized identifier | Decentralized identifier |
Who controls it | An issuing authority holds the record. | The user holds and controls it directly. |
How ownership is proven | A lookup in a central database. | A cryptographic signature with the user's key. |
Recovery | The provider can reset or reissue. | If the key is lost, control can be lost. |
Key risk area | Central breach or provider outage. | Key loss, theft, recovery, and revocation. |
What it looks like in practice
In practice
A fintech pilots accepting a decentralized identifier and a verifiable credential in place of a traditional document check. A user presents a credential attesting they are over eighteen and signs with the key that controls their DID, proving ownership without the fintech querying any central identity provider.
During the pilot, the risk team focuses less on the cryptography, which works, and more on the edge cases: what happens if the user loses the device holding their key, how recovery is handled without reintroducing a central weak point, and how a compromised credential gets revoked. Those questions, not the signing itself, are where the real risk sits, so the pilot's controls are built around key loss, recovery, and revocation.
Why DIDs matter to operators
DIDs shift control of identity from institutions to the user, which changes the risk model rather than removing risk. The cryptographic proof of ownership is strong, but it moves the weak points to new places: instead of worrying mainly about a central database being breached, you have to worry about what happens to an individual user's key.
That is where the operator attention belongs. The real risk areas are key loss, account recovery, and revocation. If a private key is stolen, whoever holds it can act as the identity; if it is lost, so is the user's control, and recovery has to work without quietly recreating the central weak point DIDs were meant to avoid. When assessing any DID-based flow, probe how those three cases are handled, because that is where the model succeeds or fails.
What to watch for
- Key theft. A stolen private key means an attacker can control the identity, so key protection is central to the security model.
- Key loss. If a user loses their key, they lose control of the identifier, which makes recovery design critical.
- Recovery weak points. Recovery that leans on a central helper can reintroduce the very dependency DIDs aim to remove.
- Revocation gaps. A compromised credential must be revocable quickly, or it keeps proving something that is no longer true.
- Early-stage maturity. Adoption is limited today, so real-world integrations may have gaps that pilots need to surface.
Quick questions
How is a DID different from a normal ID?
A normal identifier is issued and stored by a central authority that you rely on to confirm it. A DID is controlled directly by the user and proven with cryptography, so ownership is demonstrated by signing rather than by a central lookup.
What is self-sovereign identity?
It is the model where individuals hold and control their own identity, proving claims without depending on a single central provider. DIDs are the underlying identifiers that make self-sovereign identity possible.
How do DIDs relate to verifiable credentials?
They work together. A DID is the identifier a user controls, and verifiable credentials are the signed attestations, such as proof of age, that the user presents and proves ownership of using their DID.
What is the biggest risk with DIDs?
Key management. If the private key is stolen, control of the identity goes with it; if it is lost, the user is locked out. Key loss, recovery, and revocation are the areas that most need scrutiny.
Are DIDs widely used in fraud and AML today?
Not yet. Adoption is still early. The standards and pilots exist, but real-world use in fraud and AML workflows remains limited, so most operators are assessing rather than depending on them.
Why does revocation matter?
Because a compromised or outdated credential must be able to be invalidated. Without solid revocation, a credential can keep proving something that is no longer true, undermining trust in the whole model.
Go deeper
- NIST Digital Identity Guidelines (SP 800-63) ↗ — The US standard for identity proofing and authentication assurance levels.
- FATF ↗ — The global standard-setter for AML, counter-terrorist-financing, and counter-proliferation. Recommendations, guidance, and jurisdiction lists.