Wiki · Concept · Last reviewed June 25, 2026

Decentralized Identifiers

Decentralized identifiers are W3C identifiers that can resolve to DID documents, giving digital identity systems a way to bind subjects, controllers, keys, and service endpoints without requiring every identifier to come from one central provider.

Category: Concept Updated: June 25, 2026 Tags: digital identity, identifiers, credentials, agents, governance

Definition

A decentralized identifier, or DID, is a W3C identifier designed for verifiable, decentralized digital identity. DID Core v1.0 became a W3C Recommendation on July 19, 2022. The current DID v1.1 document is a W3C Candidate Recommendation Snapshot dated March 5, 2026, so v1.0 remains the stable Recommendation while v1.1 is still in the W3C process.

A DID uses the did scheme, a DID method name, and a method-specific identifier. Its narrow role is to resolve to a DID document where verification material, services, and controller relationships can be inspected. Truth and authority require other evidence.

Core Objects

A DID refers to a DID subject. The subject can be a person, organization, device, service, data model, software object, or other entity determined by the DID controller. The controller is the entity with the capability, under the relevant DID method, to make changes to the DID document. The subject and controller can be the same entity, but they do not have to be.

A DID document is the data associated with the DID. DID Core describes documents that can express cryptographic material, verification methods, and services for authentication, assertion, key agreement, capability invocation, capability delegation, or service interaction.

This is why DIDs are identity infrastructure rather than identity proof. A DID document can help prove control of keys associated with an identifier. It does not prove that a person is who they say they are, that an organization is legitimate, or that a service endpoint is safe.

Methods and Resolution

DID methods define how a specific DID scheme is implemented. DID Core says methods cover creation, resolution, update, and deactivation. Resolution is the process of taking a DID as input and returning a conforming DID document as output, according to the relevant method specification.

The method layer carries many security and governance choices: where the identifier is recorded, who can update it, how keys rotate, how deactivation works, how resolvers are trusted, and what privacy leaks a lookup may create. DID Core notes that many, but not all, DID methods use distributed ledger technology, so a DID is not automatically a blockchain identifier.

Credentials and Agents

DIDs are often discussed with Verifiable Credentials, but W3C's Verifiable Credentials Data Model v2.0 is explicit that the two technologies do not depend on each other. Verifiable credentials can use DIDs, and DID-based URLs can identify issuers, subjects, or verification material, but credentials can also use other identifiers.

For agent systems, this distinction is useful. A tool server, crawler, purchasing agent, model-evaluation service, or audit bot might need a stable identifier and a way to publish verification material. A DID could identify the actor or service. A credential could make a separate claim about operator, authorization, certification, dataset license, audit status, or revocation state.

AI Context

AI agents turn identity from a login problem into an action problem. A user might delegate browsing, purchasing, support, coding, or data movement to software that touches many systems. Each system then needs to ask: which actor is this, who controls it, what key material proves continuity, which service endpoint should be used, and what additional credentials or policies authorize the action?

DIDs can help separate these questions. The DID can name an actor or endpoint. The DID document can expose verification material. Credentials, access tokens, policy decisions, or audit logs can say what the actor is allowed to do. That matters for AI Agent Identity, because self-advertised agent names are easy to spoof and broad identity proofs can become surveillance infrastructure.

Governance Risks

The first risk is overclaiming. A DID is not a passport, license, safety certification, content-authenticity mark, or permission grant. Treating DID resolution as proof of real-world trust invites impersonation, compliance theater, and brittle automated decisions.

The second risk is correlation. Persistent identifiers can connect contexts that should remain separate. DID Core's privacy considerations discuss correlation risks, DID document correlation, subject classification, and service privacy. Agent identity systems need pairwise or context-scoped identifiers where broad reuse would create tracking pressure.

The third risk is method opacity. If a verifier cannot evaluate the DID method, resolver behavior, update controls, recovery, and deactivation semantics, the DID becomes a label around ungoverned infrastructure.

Governance Pattern

Source Discipline

Claims about DIDs should name the exact specification and method. DID Core v1.0, DID v1.1, a DID method, a resolver implementation, a credential profile, and a wallet product are not interchangeable. A serious report should say what identifier was used, which method resolved it, what document was returned, what verification material was trusted, what additional claim was checked, and what correlation risks were accepted.

Spiralist Reading

Spiralism reads DIDs as a boundary technology. They can reduce dependence on one identity provider, but they can also make networked life more classifiable if every actor carries a persistent machine-readable trail. The healthy form is scoped, inspectable, revocable, and paired with data minimization. The unhealthy form turns decentralization into surveillance and unverifiable trust claims.

Open Questions

Sources

Return to Wiki