W3C's Decentralized Identifiers v1.1 enters Candidate Recommendation on March 5, 2026, inviting implementations of a cryptographic identity standard that could reshape how digital identity works online.
The World Wide Web Consortium this month moved Decentralized Identifiers (DIDs) v1.1 to Candidate Recommendation status, publishing the specification on March 5, 2026, and formally inviting software developers and DID method authors to produce experimental implementations. The document is available at https://www.w3.org/TR/2026/CR-did-1.1-20260305/, and the public comment window runs until 5 April 2026 via GitHub issues.
The move marks a significant procedural step in a standards process that began years before this snapshot. According to the specification, the W3C Decentralized Identifier Working Group is specifically requesting that implementers test "the implementability of all of the features in this document." That phrasing is precise. The Candidate Recommendation phase is not a rubber stamp - it exists to stress-test technical claims with real code before any specification can advance further.
A decentralized identifier is, at its core, a text string made of three parts: a did: URI scheme prefix, a method name, and a method-specific identifier. The result looks something like did:example:123456789abcdefghi. Simple in form. Consequential in function.
According to the specification, DIDs are designed so their controllers can prove ownership "without requiring permission from any other party." That last phrase carries weight. Traditional identifiers - email addresses, phone numbers, social media usernames - are issued and controlled by external authorities. They can be revoked. They can disappear. DIDs, by contrast, are bound to cryptographic keys held by the identifier's controller. As long as the controller retains those keys, the identifier persists.
Each DID resolves to a DID document, a structured data file expressed in JSON or JSON-LD. According to the specification, a DID document can express cryptographic material, verification methods, and service endpoints - the technical mechanisms that enable a DID controller to prove control and engage in trusted interactions with the DID subject. The subject itself can be anything: a person, an organization, a product, a data model, or an abstract entity.
The specification defines a layered architecture with several distinct components. DID subjects are the entities identified by a DID. DID controllers are the entities - human, organizational, or autonomous software - that can make changes to a DID document. These two roles can be held by the same entity or by different ones. A parent can create and maintain a DID for a child; a manufacturer can create a DID for an IoT device.
Verifiable data registries are the underlying systems on which DIDs are recorded. According to the specification, these can include distributed ledgers, decentralized file systems, databases of any kind, peer-to-peer networks, and other trusted data storage mechanisms. The specification explicitly does not mandate any particular technology, which is a deliberate architectural decision. Implementers are free to use distributed ledger technology or not.
DID methods define how a particular type of DID is created, resolved, updated, and deactivated. Each method has its own specification. The relationship between the DID core specification and a specific DID method is analogous to the relationship between the IETF's generic URI specification and a specific URI scheme such as HTTP. Different methods can serve different trust models, jurisdictions, and infrastructure preferences.
The DID URL syntax extends the basic DID to include path, query, and fragment components conformant with RFC 3986. For example, did:example:123456789abcdefghi#keys-1 references a specific verification method within a DID document. According to the specification, DID fragment semantics are identical to generic URI fragment syntax, and implementers are urged to ensure consistent interpretation across representations.
Serialization formats covered by v1.1 include JSON and JSON-LD. A JSON representation maps data model types deterministically - maps become JSON Objects, lists become JSON Arrays, datetime values serialize as XML Schema dateTime in UTC without sub-second precision. A conforming producer must specify the media type application/did to downstream applications. The base JSON-LD context for v1.1 is located at https://www.w3.org/ns/did/v1.1, and the specification provides a hexadecimal SHA2-256 digest value for that context file so implementers can verify integrity: ea216ecc1cb02cd39b693dba2250141e270ba0bf95890be107dd9a9e8e43de85.
The v1.0 specification was published as a W3C Recommendation on 19 July 2022. Version 1.1 introduces several substantive revisions. According to the revision history section of the specification, changes include: consolidated media types to application/did following the IANA registration process completion; an added JSON-LD Context for v1.1; migration of resolution-related sections to the separate Decentralized Identifier Resolution (DID Resolution) v0.3 specification published 8 February 2026; and a structural refactoring to layer the specification on top of the Controlled Identifiers v1.0 specification, which W3C published as a Recommendation on 15 May 2025.
Additional changes since the v1.0 second Candidate Recommendation include converting PNG diagrams to SVG, rearranging appendices for readability, and updating IANA guidance as a result of the IETF Media Type Maintenance Working Group efforts. The specification also non-normatively references the DID Resolution specification to guide implementers toward common DID URL implementation patterns.
To exit the Candidate Recommendation phase and advance toward a full Recommendation, the Working Group requires specific evidence of interoperability. According to the specification, for normative statements that are machine testable, at least two conforming implementations per feature are required - meaning that when a conforming producer implements a feature, at least two conforming consumers must be able to consume it, and vice versa. For normative statements that are not machine testable, at least two demonstrations of implementation per feature are required.
A third condition: the Decentralized Identifier Resolution (DID Resolution) v0.3 specification must independently meet its own exit criteria for the Candidate Recommendation phase. This dependency on a companion specification reflects the integrated nature of the DID ecosystem - resolution is not an afterthought but a defined process with its own conformance requirements.
The Candidate Recommendation is not expected to advance to Recommendation any earlier than 5 April 2026. That date also coincides with the deadline for public comments. How quickly the group can demonstrate the required two-implementation threshold across features will determine the actual timeline.
The Decentralized Identifier Working Group is chartered until 28 April 2026. According to Working Group documents, it currently has 100 participants, including 12 Invited Experts, representing 37 organizations. The chairs are Will Abramson of Legendary Requirements and Otto Mora, a W3C Invited Expert. Pierre-Antoine Champin from W3C serves as Staff Contact.
The participant list spans academia, government agencies, and commercial entities. Contributors include representatives from Digital Bazaar, the Department of Homeland Security, Adobe, Ant Group, China Academy of Information and Communications Technology, Keio University, the University of Oxford, The Washington Post, Identity.com, and Arizona State University, among many others. The presence of government representatives - including Won Choe and Carl Prosack from the US Department of Homeland Security - underscores the specification's relevance beyond purely commercial web applications.
The group holds weekly meetings on Thursdays at 11:00 AM Boston time. According to a calendar notification sent on 10 March 2026, the next meeting on 12 March 2026 was scheduled to cover DID Path pull requests, DID Core error conditions vocabulary, DID Resolution pull request processing, DID Resolution issue processing, and a DID Resolution threat modeling update. The scribe list for that meeting includes names appearing throughout the broader contributor acknowledgements: Ted Thibodeau Jr, Manu Sporny, Otto Mora, and Stephen Curran, among others.
Funding for portions of the specification work came from the United States Department of Homeland Security's Science and Technology Directorate under multiple contracts, as well as the European Union's StandICT.eu program under sub-grantee contract number CALL05/19. Neither endorses the specification's content.
The specification dedicates substantial sections to security and privacy considerations. On non-repudiation: a verifiable data registry that supports verifiable timestamps, combined with adequate opportunity for a subject to revert malicious updates, can support non-repudiation of DID document changes.
On key recovery: according to the specification, recovery is "a reactive security measure whereby a controller that has lost the ability to perform DID operations... is able to regain the ability to perform DID operations." The specification advises proactive rotation on an infrequent but regular basis, and recommends never reusing cryptographic material associated with recovery for other purposes.
On persistence: the specification distinguishes between the persistence of a DID as an identifier and the persistence of the DID subject itself. A DID is designed to be persistent - no administrator can take control away from the controller without the controller's consent - but the resource the DID identifies can, in some DID methods, change over time. This ambiguity is deliberate. The specification notes that "DIDs are to be considered valid contextually rather than absolutely."
On privacy: the specification applies Privacy by Design principles throughout, a framework originating with Ann Cavoukian's 2011 work. Key concerns include group privacy - when a DID subject becomes indistinguishable from others in a group, privacy is available; when engagement itself becomes a recognizable flag, privacy is greatly diminished. The specification explicitly cautions against including encrypted personal data in DID documents, noting that encryption algorithms can fail over time and that "placing encrypted data in a DID document is not an appropriate means to protect personal data."
The DID specification may look remote from programmatic advertising, but its implications for the ad tech ecosystem are concrete. The intersection runs through identity - specifically through the collision between centralized, platform-controlled user identifiers and the growing regulatory and technical pressure to eliminate or replace them.
PPC Land has documented how the EU Digital Identity Wallet framework mandates compliance with W3C Verifiable Credentials and decentralized identifier protocols, predicting that current cookie-based tracking mechanisms become obsolete as users present verified credentials through standardized protocols. Advertising technology providers, the analysis noted, must adapt attribution systems to accommodate anonymous credential presentation.
In February 2025, PPC Land covered the W3C Controlled Identifiers v1.0 specification, the foundational standard on which DID v1.1 now explicitly layers itself. The convergence of these two specifications represents a coherent architecture for cryptographic identity that does not rely on centralized registries - precisely the kind of infrastructure that could underpin post-cookie identity frameworks.
Meanwhile, Google's decision in October 2025 to retire most Privacy Sandbox technologies - including the Attribution Reporting API - shifted its strategy toward developing an interoperable Attribution standard through W3C's Private Advertising Technology Working Group. That shift places W3C processes directly at the center of advertising's measurement infrastructure debates. A maturing DID specification operates within the same institutional context.
The programmatic supply chain's identity problem is not abstract. IAB Tech Lab's PAIR protocol, which uses commutative encryption to match advertiser and publisher first-party datasets without sharing raw user data, addresses a narrower problem: matching known users across walled gardens. DIDs address a deeper structural question - how can a user prove control of an identifier to any party, without any single platform acting as the verification authority?
W3C's updated process document, published in August 2025, removed the Proposed Recommendation stage from the standards track entirely, allowing direct advancement from Candidate Recommendation to Recommendation once exit criteria are met. That procedural change means the DID v1.1 path to full Recommendation status is shorter on paper than it would have been under the previous process - contingent, of course, on implementations meeting the two-conforming-implementation threshold.
For marketing professionals, the practical timeline to watch is the April 5, 2026 comment deadline. Feedback submitted through GitHub issues during this window can influence the final normative text. Organizations building identity infrastructure on top of DID methods - whether for age verification, audience authentication, or cross-platform identity - have a narrow window to shape a specification that will become a W3C Recommendation.
Who: The W3C Decentralized Identifier Working Group, a body of 100 participants from 37 organizations - chaired by Will Abramson and Otto Mora, with Pierre-Antoine Champin as Staff Contact - together with editors Manu Sporny (Digital Bazaar) and Dmitri Zagidulin.
What: Publication of Decentralized Identifiers (DIDs) v1.1 as a W3C Candidate Recommendation Snapshot, inviting experimental implementations designed to test interoperability across all specification features. The specification defines DID syntax, a common data model, core properties, serialization formats in JSON and JSON-LD, DID operations, and the process of resolving DIDs to resources.
When: Published on 5 March 2026. The public comment period runs until 5 April 2026. The specification cannot advance to full Recommendation before that date.
Where: The specification is published at https://www.w3.org/TR/2026/CR-did-1.1-20260305/ and managed through the W3C GitHub repository at https://github.com/w3c/did/. The companion test suite is maintained at https://github.com/w3c/did-test-suite/.
Why: The Candidate Recommendation phase exists to gather real-world implementation experience and verify that the specification's normative requirements are achievable and interoperable across at least two independent implementations per feature. For the advertising and marketing industry, the specification matters because it provides technical infrastructure for cryptographic identity that operates without centralized registries - a foundational capability relevant to post-cookie identity frameworks, verifiable credential systems including the EU Digital Identity Wallet, and any system requiring proof of control over an identifier without reliance on a platform intermediary.