Wiki · Concept · Last reviewed July 1, 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 Published: June 25, 2026 Modified: July 1, 2026 Last reviewed: July 1, 2026 Tags: digital identity, identifiers, credentials, agents, governance

Definition

A decentralized identifier, or DID, is a W3C identifier designed for verifiable, decentralized digital identity. A DID is a URI that normally uses the did scheme, a DID method name, and a method-specific identifier. Its narrow role is to resolve, under the rules of a DID method, to a DID document where verification material, services, and controller relationships can be inspected.

The important boundary is that a DID can help prove control of an identifier. It does not prove civil identity, professional status, permission to act, safety, authenticity of a credential claim, or trustworthiness of a service endpoint. Those require other evidence: issuer trust, credential status, policy decisions, audit trails, legal context, and human or organizational accountability.

Snapshot

Current Context

As of July 1, 2026, DID Core v1.0 remains the stable W3C Recommendation, published on July 19, 2022. DID v1.1 is a W3C Candidate Recommendation Snapshot dated March 5, 2026, which means implementers are being asked to test features before a possible later Recommendation. DID Resolution v0.3 is a W3C Working Draft dated June 11, 2026; the draft explicitly describes itself as work in progress.

The surrounding W3C identity stack is broader than DIDs. Controlled Identifiers v1.0, published as a W3C Recommendation on May 15, 2025, generalizes identifier documents with cryptographic material and service endpoints. Verifiable Credentials Data Model v2.0, also a W3C Recommendation from May 15, 2025, can use DIDs but is not dependent on them. The Digital Credentials API remains Working Draft work for browser-mediated credential presentation and issuance, not a DID specification.

This status matters for procurement and governance. A product can say it "uses DIDs" while relying on a particular DID method, resolver, wallet, ledger, hosted service, bridge, or trust registry. The review question is therefore not whether the string begins with did:. It is which method was used, who controls the document, how keys rotate, how resolution is verified, how deactivation works, and what other credential or policy proves the claim being made.

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. A DID URL can also refer to parts of a DID document or to resources reachable through method and service rules.

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, that a service endpoint is safe, or that a controller should be authorized for a particular action.

Methods and Resolution

DID methods define how a specific DID scheme is implemented. DID Core says methods cover creation, resolution, update, and deactivation. DID Resolution describes resolution as the process of taking a DID and resolution options as input and returning a DID document plus metadata about the resolved document and request, according to the relevant method and resolver behavior.

The method layer carries many security and governance choices: where the identifier is recorded, who can update it, how keys rotate, how recovery works, 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.

Resolver trust is a separate question from identifier syntax. A local resolver, hosted resolver, universal resolver, wallet resolver, or method-specific driver can return different metadata, expose different privacy signals, or fail differently. For high-stakes systems, the resolver and method should be part of the assurance record, not an invisible dependency.

Credentials and Agents

DIDs are often discussed with Verifiable Credentials, but the layers are distinct. Verifiable credentials can use DIDs, and DID-based URLs can identify issuers, subjects, holders, or verification material, but credentials can also use other identifiers. A VC signed by a key found through DID resolution still needs issuer trust, schema validation, status checking, holder binding, and relying-party policy.

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. An access token or policy decision could then authorize a particular action.

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 AI Audit Trails can say what the actor is allowed to do and what it actually did. That matters for AI Agent Identity, because self-advertised agent names are easy to spoof and broad identity proofs can become surveillance infrastructure.

This is not personhood. A DID for an agent should be read as infrastructure for accountable software action, not as a claim that the agent is conscious, morally independent, or legally autonomous. The useful governance move is to bind the DID to an operator, sponsor, model or tool system, permission scope, incident contact, and revocation path.

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.

The fourth risk is endpoint and metadata leakage. A DID document may expose service endpoints, relationship metadata, public keys, controller links, or update history. Even if no private attribute appears directly, repeated resolution can classify a subject, reveal organizational relationships, or show which verifier is asking about which identifier.

Evidence Record

For consequential use, a DID-backed claim should leave enough evidence for later review without forcing every verifier to retain excessive personal data.

Governance Pattern

Source Discipline

Claims about DIDs should name the exact specification, maturity level, method, and resolver. DID Core v1.0, DID v1.1, DID Resolution v0.3, DID Extensions, Controlled Identifiers, a DID method, a resolver implementation, a credential profile, a trust registry, 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.

For current technical claims, use primary sources: W3C Recommendations, Candidate Recommendations, Working Drafts, Group Notes, publication histories, method specifications, resolver documentation, OpenID specifications, IETF RFCs or Internet-Drafts, and official regulator or standards-body materials. Vendor wallet or blockchain marketing can document a product claim, but it should not be treated as proof of interoperability, privacy, or trustworthiness.

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