Summary
- W3C’s active 2024 charter authorized DID Resolution as a Recommendation-track deliverable and has been extended through 28 October 2026. The work is not operating in an authority vacuum.
- DID Resolution became a Candidate Recommendation Snapshot on 6 August. That Patent Review Draft opened an exclusion opportunity through 5 October and set feature-level implementation criteria; it did not become a W3C Recommendation or endorsement.
- The W3C Team opened refinement of a continuity recharter on 10 August. Yet the public draft charter, including its 27 August repository head, still identifies DID Resolution as a Working Draft, lists 10 July as the latest publication and points to the older 2024 exclusion draft.
- W3C’s official history then records a Candidate Recommendation Draft on 28 August. That newer draft integrates intended changes, but it is not another patent-review Snapshot merely because it is the latest text.
- Before Advisory Committee review, the recharter should carry a compact standards-state handoff joining current charter authority, latest readable draft, controlling Snapshot, exclusion window, feature-at-risk state and dated implementation evidence. The join should describe the process, not invent a new gate.
Four accurate clocks can still produce one wrong reading
The easiest mistake is to ask for the status of DID Resolution as though the answer were one date.
There is a publication clock. W3C’s history now lists a Candidate Recommendation Snapshot dated 6 August and a Candidate Recommendation Draft dated 28 August. The latter is the newer readable report.
There is a patent clock. The 6 August Snapshot is the Patent Review Draft. It opened a Call for Exclusions that runs until 5 October. The 28 August Draft does not replace that reference-body function merely because its publication date is later.
There is an implementation clock. The public test report displays a run on 27 March. It contains a matrix and names several implementers, while the August Snapshot defines what evidence is needed at feature level to advance.
There is an institutional clock. The active charter that brought DID Resolution onto the Recommendation track remains in force through 28 October. A successor charter is being refined, but has not been approved and has no effective start date yet.
Each clock is visible. Trouble begins when a reader compresses them into one status label. “Latest” may mean latest integrated text, latest patent reference body, latest test run or current source of group authority. Those are not synonyms.
The governance task is therefore not to choose one master clock. It is to preserve the join among them.
The present charter did more than keep the lights on
The current 2024 charter matters because it explains why the August publications exist at all. It adopted DID Resolution as a new Recommendation-track deliverable. Its initial end date was April 2026; W3C extended it through 28 October 2026.
That means the Candidate Recommendation work took place under an active charter. The later recharter does not need to create authority retroactively. Nor should the new draft be described as though it already displaced the old charter. W3C Process makes charter approval a later institutional act, followed by a Call for Participation and renewed participation commitments.
The Strategy issue for the proposed charter is unusually plain about the intended change. It calls this an existing-group recharter, states “Substantive changes: None,” and says the group simply needs more time because consensus on DID Resolution took longer than expected.
That description strengthens the case for a handoff. If the institutional purpose is continuity rather than a new scope, the record should make continuity provable. Which deliverable is crossing the boundary? Under which charter was its patent-review text produced? Which open evidence obligations travel with it? Which later text is only a work in progress? A continuity document should be exceptionally good at answering continuity questions.
This is not the argument that a proposed charter creates a mandate. It does not. It is the inverse problem: how a future charter accurately receives work already authorized elsewhere.
Snapshot and Draft are two different kinds of “candidate”
The language is deceptively close. W3C publishes both Candidate Recommendation Snapshots and Candidate Recommendation Drafts. The two forms sit in the same maturity phase but do different jobs.
The 6 August Snapshot is a stable review point. W3C’s Process describes a Candidate Recommendation Snapshot as a Patent Review Draft. Its publication triggers a Call for Exclusions. The DID Working Group’s public IPR page consequently names 6 August as the start of the current opportunity and 5 October as its end.
The 28 August Candidate Recommendation Draft has another function. Its status text says it integrates changes from the prior Candidate Recommendation that the Working Group intends to put into a later Snapshot. It is explicitly work in progress and inappropriate to cite as anything else. Under the Process, a CR Draft does not itself provide an exclusion opportunity.
The distinction protects implementers and participants from two opposite errors. Treating the latest Draft as the patent reference body can move the legal comparison point without the procedure that creates it. Treating the older Snapshot as the only current technical text can hide changes that implementers are being asked to review.
Both documents belong in the handoff, with different labels:
- latest integrated technical text: 28 August CR Draft;
- controlling patent-review reference: 6 August CR Snapshot;
- current exclusion opportunity: 6 August to 5 October;
- next patent-review point: not inferred until W3C publishes another Snapshot.
A newer date does not absorb every function of an older institutional act.
The exclusion record is active, not missing
The draft charter’s DID Resolution row still names the 28 November 2024 Working Draft as the exclusion draft and the period ending 27 April 2025. Read alone, that row is behind the current process.
But the live W3C IPR surface is not behind. It shows the new DID Resolution opportunity, the 6 August start and the 5 October deadline. It retains the 2024–2025 opportunity as previous history. The public Call for Exclusions also explains that the new opportunity concerns matter not present or apparent in the previous reference body.
This matters because the finding is reconciliation, not accusation. There is no evidence here that W3C failed to launch the exclusion period, concealed the applicable record or lost its patent-policy history. The evidence shows the opposite: the specialized patent surface is doing its job.
Nor does an open exclusion window imply a patent problem. The group’s IPR page says no patent disclosures have been made for its specifications. An opportunity is a procedural state, not an allegation that a claim exists or will be excluded.
The charter handoff should therefore link the live record, not attempt to restate patent law in prose. It should name the Snapshot, opening and closing dates, prior reference body and public IPR URL. If another Snapshot later creates another opportunity, the handoff can append a new state without rewriting the old one.
That is thin coordination: stable identity, accurate dates, explicit lineage and a correction path. It does not require one committee to decide the substance of every possible patent position.
Implementation evidence is not an implementer headcount
The August Snapshot asks for experimental implementations and sets demanding exit criteria. For every feature, the group expects at least two independent interoperable implementations, verified through open test suites. Machine-testable normative statements need at least two conforming implementations per feature; statements that are not machine-testable need at least two demonstrations. The independent implementations must also support at least two openly specified DID methods, each interoperably implemented by more than one implementation.
Those conditions cannot be reduced to “four names appear in a table.” The public implementation report does name several implementers and exposes a detailed matrix. It also displays a run time of 27 March 2026—months before both August Candidate Recommendation publications.
The date does not prove that the report is obsolete in every respect. A March run may exercise features that remain unchanged. The matrix may be updated through mechanisms not visible from its heading. Nor does a visible failure or “not implemented” cell, taken out of context, establish that the final exit test has failed. Feature definition, test version, conformance statement and independence all matter.
The modest conclusion is stronger than a speculative verdict. A recharter receiving this work should point to a dated feature-to-test-to-implementation receipt:
- the specification commit or publication tested;
- the test-suite commit and run time;
- the normative statements grouped into each feature;
- the two qualifying implementations or demonstrations for that feature;
- the basis for treating implementations as independent;
- the openly specified DID methods used for interoperability;
- unresolved, skipped and at-risk items;
- the person or group responsible for refreshing the report.
That record would let running code discipline the institutional label. It would not let a charter declare implementation reality into existence.
“At risk” is a controlled state, not a verdict of failure
The 6 August status section identifies DID URL dereferencing as a feature at risk and says it is likely to change or be removed. The Working Group is asking implementers whether the feature, as defined, has value. The document also warns that open class 1, 2 or 3 issues can change the specification.
This is healthy information. Candidate Recommendation exists partly to learn from implementation. A feature-at-risk marker is not a confession that the process failed; it is a bounded warning that one part may not survive unchanged.
The risk comes from losing the marker during institutional transition. If a new charter merely says that the group will “maintain” DID Resolution, a later reader needs to know what it inherited: a final feature, an open issue, a removable candidate, a tested interoperability claim or a provisional section.
The handoff should not freeze the answer. It should preserve the question, the responsible decision surface and the evidence required to close it. A status record that can only say “present” or “absent” is too coarse for standards work.
The draft charter is in the phase designed for correction
The public charter page calls itself a draft. Its start and end dates are placeholders, which is unsurprising because the start depends on a future approval and Call for Participation. W3C announced that refinement is expected to continue until approximately 15 September. Under the Process, refinement is when wide review occurs, issues are formally addressed and the Team decides whether to begin Advisory Committee review, extend refinement or abandon the proposal.
The DID Resolution row is also candid about its intended semantics. It says “Draft state” means the state of the deliverable at charter approval, and it links the publication-status page for current information.
That sentence sets the right test. The row does not need to behave like a live ticker throughout every hour of refinement. It does need to be accurate when the charter reaches approval. At the evidence cutoff, however, the live page and the 27 August repository head still say Working Draft, latest publication 10 July, and old exclusion draft—even though the 6 August Snapshot was already three weeks old when that head was merged. The 28 August CR Draft then widened the gap.
This is a correctable draft-state mismatch, not proof of invalidity. Calling it invalid would erase the point of refinement. Ignoring it would waste the point of refinement.
What the standards-state handoff should contain
The answer is not to turn a charter into a second publication database. W3C already has dedicated publication, IPR, group and test surfaces. The common layer should remain thin.
One compact record can bind them through stable identifiers:
Authority
Name the current charter, its effective period, the successor charter commit, refinement status and eventual approval decision. Until approval, label the successor as proposed.
Text
Name the latest readable technical report and its status. Separately name the controlling Candidate Recommendation Snapshot. Do not use a single “latest” field for both.
Patent state
Name the Patent Review Draft, exclusion opening and closing dates, earlier reference body and public IPR page. Record later exclusion opportunities append-only.
Implementation state
Name the implementation-report version, run time, tested specification, feature coverage, independence basis and unresolved cells. Keep the raw test evidence linked.
Review state
Link the feature-at-risk marker, open issues, horizontal reviews, wide-review period and comment disposition. A closed date should not erase the path that produced it.
Custody
Identify the owner responsible for each projection, the correction route and the event that supersedes a field. A later publication should append a transition, not silently overwrite institutional memory.
This record could be rendered as a table and stored as structured data. Its public value comes from preserving boundaries, not from adding another layer of approval.
One broad identity link does not enlarge W3C’s mandate
DID Resolution concerns decentralized identifiers and the process of resolving them to DID documents and resources. That makes identity and access management a relevant surrounding field. It does not mean that W3C authorizes an IAM product, certifies a DID method, governs every identity provider or creates a legal identity regime.
The specification itself excludes authentication and authorization protocols, browser APIs and the ambition of “solving identity” on the Web from the Working Group’s scope. That restraint should survive summary and directory linking. A standards article can point readers toward the broader identity subject without converting subject relevance into institutional jurisdiction.
Participation has the same boundary. Implementers, Members, Invited Experts and public reviewers supply evidence, code, objections and judgment. Their participation does not become authority over absent product operators or governments. The charter authorizes the Working Group’s defined work; the Recommendation process governs W3C publication; external adoption comes from other actors.
The handoff should make those layers easier to see, not blend them into a universal mandate.
Sources
- W3C public-review announcement — Candidate Recommendation Snapshot: DID Resolution v1, 6 August 2026
- W3C — DID Resolution v1 Candidate Recommendation Snapshot, 6 August 2026
- W3C Patent Policy — Call for Exclusions: DID Resolution v1, 6 August 2026
- W3C DID Working Group IPR page
- W3C — Start of refinement for a draft DID Working Group charter, 10 August 2026
- W3C — Draft Decentralized Identifier Working Group Charter
- w3c/did-wg-charter — reviewed commit
a840d21c6f8fac431ee1662d1bedb05940834623 - w3c/strategy issue 562 — DID Working Group charter
- W3C — Current DID Working Group charter, 25 April 2024
- W3C DID Working Group page
- W3C — DID Resolution v1 publication history
- W3C — DID Resolution v1 Candidate Recommendation Draft, 28 August 2026
- W3C DID Resolution implementation report
- W3C Process Document, 18 August 2025
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
