Decentralized identifiers (DIDs): what they are and do

A decentralized identifier, or DID, is a text string that identifies something, usually a person, organisation or device, and that its controller can prove they control without asking any central authority. It is standardised by the World Wide Web Consortium (W3C). Unlike an email address or a username, no company or registry hands it out and no one can switch it off at will.

What is a DID, technically?

A DID has the form did:method:identifier. An example is did:web:example.org. The first part is always did, the second names a DID method, which defines how the identifier is created, read, updated and retired, and the third is the identifier within that method.

Looking up a DID is called resolution. The result is a DID document, a small JSON or JSON-LD file that contains:

• the controller of the DID,
• one or more verification methods, typically public keys,
• relationships that say what each key may be used for, for example authentication or assertionMethod,
• optional service endpoints, such as a place to send messages.

The specification, DID Core, became a W3C Recommendation on 19 July 2022. Version 1.1 was published as a Candidate Recommendation on 5 March 2026, which means implementers are invited to test it; it is not yet final. Resolution rules are moving into a separate specification.

How is it different from other identifiers?

In classic federated login, an identity provider owns the identifier and decides whether it still works; see identity federation. Domain names depend on a registry and a registrar. A DID is designed so that the controller holds the keys and can, depending on the method, rotate them or move the DID to different infrastructure.

Note that ‘decentralised’ does not mean ‘trusted’. A DID proves that someone controls a key; it says nothing on its own about who that someone is. Trust comes from credentials issued by parties you recognise.

Common DID methods

Method	Where the DID document lives	Typical trade-off
did:web	A file on a web server under the domain	Simple, but depends on DNS and the web host
did:key	Derived from the public key itself	No infrastructure, but the key cannot be rotated
did:jwk	Derived from a JSON Web Key	Similar to did:key, convenient in JSON tooling
did:ebsi	The European Blockchain Services Infrastructure	Used in European pilots, tied to that network

How do DIDs relate to verifiable credentials?

DIDs identify the parties; verifiable credentials carry the claims. An issuer signs a credential with a key listed in its DID document. A verifier resolves the issuer’s DID, fetches the key and checks the signature. The holder can also be a DID, so a credential can be bound to a key the holder controls. Our guide to verifiable credentials shows the full issuer, holder, verifier triangle.

DIDs are optional in this picture. SD-JWT VC and ISO mdoc can find issuer keys through certificates or well-known web locations instead.

What is the connection to the EUDI Wallet?

The EU’s wallet framework aims at interoperability across 27 Member States. Its architecture relies chiefly on X.509 certificates, national trusted lists and a registration regime for relying parties, rather than on DIDs. That choice is practical: public-key infrastructure and trusted lists already exist under the eIDAS Regulation, and legal liability is easier to place with identifiable certificate holders.

DIDs have nevertheless played a role in European projects, including pilots built on the European Blockchain Services Infrastructure, and some standards used around the wallet, for example OpenID for Verifiable Presentations, can identify a verifier by a DID. For what the wallet actually does, see the EUDI Wallet overview.

Examples

• Organisation identity. A company publishes did:web:company.example and signs credentials such as employment attestations with the key in its DID document.
• Device identity. A sensor uses a DID to sign measurements, so a recipient can attribute data to the device.
• Portable identity for a person. A holder has a DID in a wallet and receives credentials bound to it.

Security considerations

• Key management is the whole game. Whoever controls the private key controls the DID. Loss or theft is hard to recover from; methods differ in whether rotation is possible.
• did:web inherits web risks. Domain takeover or a compromised server means a compromised DID.
• Correlation. Reusing one DID everywhere lets different services link your activity. Pairwise DIDs, one per relationship, reduce this.
• Resolution privacy. Resolving a DID can reveal to the resolver who is checking whom.
• Governance still matters. A DID does not replace the question of why a verifier should trust an issuer. That is what trust frameworks, registries and legal rules are for.

How does it compare with other standards?

DIDs are an identifier and key-discovery layer. OpenID Connect and SAML are login protocols between an identity provider and a service. FIDO2 and passkeys authenticate a user to a service with a device key. DIDs sit closest to verifiable credentials and the wallet world, and they can complement all of these without replacing them.

Status in October 2026

DID Core 1.0 is a stable W3C Recommendation; 1.1 is a Candidate Recommendation and may change. Many DID methods have been registered, but only a handful see real use. If you evaluate a product, ask which methods it supports, and whether that matches the trust model of the ecosystem you must work in.