The World Wide Web Consortium published Decentralized Identifier Resolution (DID Resolution) v1 as a Candidate Recommendation Snapshot on August 6, 2026, opening a 28-day comment window that closes on September 3, 2026 and setting an interoperability bar that requires two independent implementations of every feature before the document can become a web standard.

The W3C Decentralized Identifier Working Group released the specification at https://www.w3.org/TR/2026/CR-did-resolution-1.0-20260806/. According to the document, the group is requesting that software developers provide experimental implementations "designed to test the implementability of all of the features in this document." That request is the defining characteristic of the Candidate Recommendation phase, which exists to expose a specification to running code before its normative text hardens.

The publication completes a fast progression. W3C published DID Resolution v0.3 as a Working Draft on 8 February 2026. Six months later the same work carries a new title, a new pair of editors, a substantially rewritten error model, and a security section several times its former length.

What the specification actually defines

DID resolution is the process of turning a decentralized identifier into a DID document. According to the specification, that document is a set of information enabling cryptographically verifiable interactions with the DID subject, including mechanisms such as cryptographic public keys. Resolution is one of four operations defined for any DID, alongside create, update and deactivate.

Software or hardware that performs the process is called a DID resolver. The specification defines an abstract function, resolve(did, resolutionOptions), which returns three values: didResolutionMetadata, didDocument, and didDocumentMetadata. All conforming resolvers must implement that function for at least one DID method and must be able to return a DID document. Implementations are barred from altering the signature of the function, though they may expose additional functions alongside it.

A second abstract function, dereference(didUrl, dereferenceOptions), handles DID URL dereferencing, which retrieves a representation of a resource identified by a DID URL. Its return values are dereferencingMetadata, contentStream, and contentMetadata.

The specification names four use cases: a decentralized address book, verification of a verifiable credential, auditability of a DID document's historical state, and DID URL based resource retrieval. The auditability case is the one with the clearest audit-trail application, since resolution can return a document version as it existed at a specific timestamp or version identifier.

Parameters, options and datetime rules

Five DID parameters are formally defined: service, serviceType, relativeRef, versionId, and versionTime. Support for all of them is optional. Resolution options include accept, which signals a preferred media type; expandRelativeUrls, a boolean that instructs a resolver to rewrite relative DID URLs in a document into absolute ones; and the versionId and versionTime parameters.

Datetime handling is now strict. All datetime values must be valid XML datetime strings as defined by the Verifiable Credentials Data Model v2.0, adjusted to UTC and stripped of sub-second decimal precision. The specification gives 2020-12-20T19:17:47Z as the canonical shape.

There is also a warning about numbers in metadata structures. Implementers are advised to avoid non-integer values and integers outside common fixed-width ranges, specifically those larger than a 32-bit unsigned integer, a maximum of 4,294,967,295. Where such values are needed, the document points toward canonical string serialisation instead.

Query normalization enters the specification

One of the more consequential additions since the Working Draft is a section on query normalization, which did not exist in the earlier text. Its premise is operational rather than theoretical: DID URL query strings are constructed, parsed, logged, cached, and compared by multiple independent components across a resolution pipeline, and inconsistent normalization between them can silently produce wrong answers.

Three sub-sections address the problem. Percent-encoding normalization sets a baseline consistent with RFC3986 syntax-based normalization: decode percent-encoded octets that map to unreserved characters, represent remaining octets with uppercase hexadecimal digits, and avoid decoding reserved delimiters within the query component. The relativeRef parameter carries an explicit carve-out, since its encoded path separators are intentional.

Duplicate parameter handling is left largely unspecified, which the document states plainly. Because every parameter it defines carries a scalar value, a repeated parameter is an ambiguous input. The text suggests one reasonable approach: treat such a DID URL as invalid and return an INVALID_DID_URL error.

Canonicalization by DID method pushes three questions down to method authors: value format, whether parameter ordering carries semantic weight, and case sensitivity. Parameter names defined in the specification are case-sensitive ASCII strings.

Five sections carry at-risk flags

The specification marks five separate issues as features at risk, a signal that implementers building against those areas may find them altered or deleted before the document advances.

Issue 1 flags the definition of DID URL dereferencing itself. Issue 2 flags the entire DID URL Dereferencing section, stating that it "is likely to be heavily modified or removed from the specification." Issue 3 covers a provisional alternative dereferencing algorithm based on retrieval strategies, presented alongside the existing one rather than replacing it. Issue 4 marks the DID Resolution Architectures material. Issue 5 marks the DID URL Dereferencing Result data structure.

That is an unusual concentration of instability in a document being offered for implementation. Dereferencing is the mechanism by which a client follows a fragment to extract a specific verification method, or follows a service parameter to reach a service endpoint URL. Any product that resolves a DID URL to a key or an endpoint touches the part of the specification the Working Group is least certain about.

The GitHub issue tracker reflects the same unsettled state. The repository showed 27 open issues against 160 closed and seven open pull requests. Open items include a proposal to drop the HTTP binding for dereferencers, which had drawn 17 comments since March 17, a suggestion to replace the term "dereferencer" with "resolving client" opened March 21, a question from February 4 asking whether support for DID parameters should be optional at all, and a January 22 item titled "We probably want to remove proxying resolvers." A separate issue opened by Manu Sporny requests horizontal reviews for DID Resolution v1.0 and carries trackers for accessibility, internationalisation, privacy, security, and the Technical Architecture Group.

The bar for becoming a standard

To exit the Candidate Recommendation phase, the Working Group set out four requirements. At least two independent interoperable implementations of every feature, with interoperability verified by open test suites and two or more implementations interoperating with each other. For machine-testable normative statements, at least two conforming implementations per feature. For statements that are not machine testable, at least two demonstrations of implementation per feature. And each independent implementation must support at least two DID methods that have open specifications and are implemented interoperably by more than one of those implementations.

The practical effect is a matrix rather than a checklist: at least two openly specified DID methods, each implemented by at least two independent implementations. A feature is defined as one or more functionally related normative statements, and interoperability is defined as those statements being interpreted the same way across two different DID methods.

Whether that bar is set correctly is itself an open question inside the group. An issue opened on June 24 asks about charter success criteria implications and whether DID resolvers must support at least two DID methods.

The document states that it is not expected to advance to Recommendation any earlier than September 3, 2026. The Working Group's charter runs until 28 October 2026. That leaves 55 days between the earliest possible advancement and the current charter expiry, a window that will need either fast implementation reports or a charter extension.

Errors, HTTP status codes and TLS

The error model changed materially. Where the earlier draft used simple keyword strings, the Candidate Recommendation directs implementers toward RFC9457 problem details, with error types expressed as URLs under the https://www.w3.org/ns/did# namespace. Nine error types are enumerated: INVALID_DID, INVALID_DID_DOCUMENT, NOT_FOUND, REPRESENTATION_NOT_SUPPORTED, INVALID_DID_URL, METHOD_NOT_SUPPORTED, INVALID_OPTIONS, INTERNAL_ERROR, and FEATURE_NOT_SUPPORTED.

The HTTP binding maps each to a status code. Invalid input returns 400. A missing document returns 404. An unsupported representation returns 406. An unsupported method or feature returns 501. Malformed documents, internal errors, and any unrecognised error URI return 500. A deactivated DID returns 410. Dereferencing that resolves to a service endpoint URL with content type text/uri-list returns 303 with a Location header and an empty body.

All conforming resolvers must implement the GET version of the HTTPS binding and may implement POST. All HTTPS bindings must use TLS. The specification explicitly does not require DNS names in certificates, permitting resolvers to use TLS certificates issued for IP addresses. Three media types are defined: application/did-resolution, application/did-url-dereferencing, and application/did.

Security and privacy sections grew substantially

The Candidate Recommendation adds attack surface analysis absent from the earlier draft. Path traversal via relativeRef receives its own treatment, with a non-exhaustive list of encodings an attacker might use, including doubly-encoded and platform-specific variants. The document states that superficial string matching for the literal sequence is not a reliable detection mechanism.

Normalization inconsistency is framed as a cache bypass vector. Where different components in a proxied architecture apply different normalization rules, an attacker could construct a DID URL served from cache by one component and re-fetched by another, or inflate cache size by causing logically identical URLs to be stored as distinct entries. Parameter injection via string concatenation gets a worked example: a caller-supplied service value containing an ampersand and a second parameter could inject a versionId the caller never authorised.

Dereferencing cycles are treated as a denial-of-service concern. A DID document that references another DID which eventually points back forms a loop, and recursive dereferencers are expected to detect and handle it.

Caching behaviour is now governed by a noCache resolution option. Resolvers that implement it may be more exposed to denial-of-service, since malicious clients can force expensive network requests; resolvers that refuse must return FEATURE_NOT_SUPPORTED so the client can retry without the option.

A standalone privacy section is new. It states that resolvers and dereferencers can log requests, and that those logs could over time be used to track and profile the clients making them. Suggested mitigations include Oblivious HTTP, trusted proxies, and trusted caches.

Who is in the room

The Decentralized Identifier Working Group lists 95 participants, including 13 Invited Experts, representing 35 organizations. It is chaired by Will Abramson of Legendary Requirements and Otto Mora, with Pierre-Antoine Champin as W3C staff contact.

The editors are Stephen Curran, an Invited Expert, and Joe Andrieu of Legendary Requirements. Markus Sabadello of Danube Tech served as editor until 2025-12-10 and remains an author alongside Dmitri Zagidulin.

The participant roster is not confined to identity specialists. Adobe, The Washington Post, GS1, Kaiser Permanente, Ant Group, and OpenLink Software all have named participants, as do the China Academy of Information and Communications Technology, the Electronics and Telecommunications Research Institute in Korea, Taiwan's Ministry of Digital Affairs, Keio University, and the University of Oxford. Two participants are listed under the United States Department of Homeland Security.

That last affiliation is not incidental. According to the specification, portions of the work were funded by the Department of Homeland Security's Science and Technology Directorate under contract HSHQDC-17-C-00019, with the document noting that its content does not necessarily reflect United States government policy.

Why a resolution specification matters to advertising

The link between a resolution algorithm and media buying runs through identity plumbing. Resolution is the step that turns an identifier into usable cryptographic material. Without an interoperable resolution layer, decentralized identifiers remain strings that different systems interpret differently, which is precisely the fragmentation problem that has dogged identity in programmatic advertising for a decade.

W3C moved DIDs v1.1 to Candidate Recommendation on March 5, 2026, and that specification's own exit criteria included a condition that the resolution work independently clear its Candidate Recommendation bar. The August 6 publication is the step that condition was waiting on. The core identifier specification layers on top of Controlled Identifiers v1.0, which W3C introduced in early 2025 and published as a Recommendation on 15 May 2025.

Procedurally, the path is shorter than it once was. W3C's 2025 Process Document removed the Proposed Recommendation stage entirely, allowing direct advancement from Candidate Recommendation to Recommendation once exit criteria are met. This document is governed by the 18 August 2025 Process Document.

Regulatory pull is arriving from Europe. The EU Digital Identity Wallet framework references the W3C Verifiable Credentials family, and the bloc's age verification programme has been moving on a 2026 timetable. Google began issuing EU digital IDs and an age credential through Google Wallet in June 2026, a deployment that puts government-issued credentials into a consumer wallet at scale. In the consent debate, the EU Council's compromise text on the Digital Omnibus explicitly contemplated privacy signals implemented in a browser or in the EU Digital Identity Wallet before the provision was dropped.

The measurement side has already been pushed toward W3C. Google's decision to retire most Privacy Sandbox technologies in October 2025 redirected its attribution work into a W3C working group, and W3C's own footprint has been expanding, including a Shenzhen office opened in 2026 with decentralized identifiers named as a focus area. The consortium also published an updated Geolocation API as a Recommendation in March 2026.

There is a second pull, from machines rather than regulators. The advertising industry's agentic turn has produced a string of identity proposals with no settled resolution layer beneath them: LiveRamp donated the User Context Protocol to IAB Tech Lab in November 2025, and the IAB Tech Lab Summit in May 2026 treated agent identity and accountability as unfinished infrastructure. A specification that defines how any party resolves an identifier to a public key, with defined error codes and defined cache semantics, is the kind of primitive those proposals currently lack.

None of this makes DID resolution imminent in an ad server. The specification is explicit that a Candidate Recommendation Snapshot must not be cited as a W3C standard, and that publication does not imply endorsement by W3C or its members. What it does carry is royalty-free licensing commitments from Working Group members for implementations, which removes one commercial obstacle for vendors evaluating the work.

The nearer-term signal for anyone tracking identity infrastructure is the September 3 date and the at-risk flags. Comments filed through GitHub issues before that date can still change normative text. After it, the question becomes whether implementation reports arrive fast enough to move a specification whose most contested section may not survive the review it is entering. Standards bodies rarely resolve identity questions quickly. This one has set itself a deadline anyway.

Timeline

Summary

Who: The W3C Decentralized Identifier Working Group, chaired by Will Abramson of Legendary Requirements and Otto Mora, with Pierre-Antoine Champin as W3C staff contact. Stephen Curran and Joe Andrieu are the editors; Markus Sabadello and Dmitri Zagidulin are the authors. The group lists 95 participants, 13 of them Invited Experts, from 35 organizations including Adobe, The Washington Post, GS1, Ant Group, Kaiser Permanente, and the United States Department of Homeland Security.

What: Publication of Decentralized Identifier Resolution (DID Resolution) v1 as a W3C Candidate Recommendation Snapshot, defining resolve and dereference functions, five DID parameters, a nine-item error taxonomy mapped to HTTP status codes, an HTTPS binding requiring TLS, query normalization rules, and expanded security and privacy sections. Five sections carry at-risk flags, concentrated in DID URL dereferencing.

When: Published 6 August 2026. Comments close 3 September 2026, which is also the earliest date the document can advance to Recommendation. The Working Group charter runs to 28 October 2026.

Where: Published on the W3C technical reports site at https://www.w3.org/TR/2026/CR-did-resolution-1.0-20260806/, with feedback routed through the w3c/did-resolution GitHub repository and the public-did-wg mailing list.

Why: The Candidate Recommendation phase exists to collect implementation experience before normative text is finalised. Exit requires at least two independent interoperable implementations of every feature, each supporting at least two openly specified DID methods that are themselves implemented by more than one implementation. For advertising and marketing technology, resolution is the layer that converts a decentralized identifier into usable cryptographic material, making it a prerequisite for any identity architecture built on verifiable credentials, EU wallet infrastructure, or agent authentication rather than cookies.