Summary

  • On 19 June 2026, a W3C Council unanimously overruled a Formal Objection and allowed Digital Credentials to retain a normative reference to ISO/IEC TS 18013-7:2025 Annex C.
  • The Council accepted that a non-free dependency makes review and implementation harder, but found that excluding a protocol used by existing and emerging government-issued credentials would carry the larger architectural and interoperability cost.
  • The decision was expressly narrow. It did not convert fee-gated references into routine practice or settle the concern about access.
  • W3C updated its Normative References Guidebook on 24 July with a five-part case-by-case exception test. The Team had also recommended revisiting this reference when Digital Credentials exits Candidate Recommendation, using implementation feedback.
  • The 27 August Working Draft still identifies org-iso-mdoc through the 2025 Annex C reference. ISO's page still offers that 42-page edition for CHF 181 while marking it for revision and showing a Committee Draft successor.
  • W3C should maintain an exception-state receipt that joins the exact external version, access state, mitigations, implementation evidence, deciding authority and next review trigger. That would keep a justified exception from becoming a permanent dependency by inertia.

The exception is a decision, not a footnote

Normative references often disappear into the back matter of a technical document. To a reader, they can look like bibliography. To an implementer, a normative reference is part of the instruction set. It can define the grammar, algorithm, protocol or behavior needed to claim conformance with the document that points to it.

That difference is what made the W3C Digital Credentials dispute consequential. Pull request 401 changed the specification from a loose registry model to an explicit list of supported protocols. One of those protocols is org-iso-mdoc. The current Working Draft directs the reader to Annex C of ISO/IEC TS 18013-7:2025 for it. The reference is not an optional reading suggestion. It carries a piece of the protocol boundary.

The referenced publication is sold by ISO. Its official page identifies a Technical Specification, Edition 2, published in May 2025, with 42 pages and a price of CHF 181. The page offers a sample, but the normative edition is not presented there as freely readable in full. This is precisely the condition W3C now describes as “not freely available”: access depends on paying a fee, accepting a restricted route or belonging to a permitted audience.

A participant objected. The Working Group retained the reference after dissent. The W3C Team reviewed the case. A Council was then convened and issued the final W3C disposition on 19 June. It unanimously overruled the Formal Objection and allowed the reference to stand.

The sequence matters. “The specification cites ISO” is not the complete state. The complete state is that a known access barrier was challenged, considered through several authority layers and accepted as an exception for stated reasons. If the decision is later reviewed, a reviewer needs that chain—not merely the surviving bibliography entry.

W3C accepted both costs

The Council did not deny the access problem. Its report says that a W3C specification becomes harder to review and implement when it normatively depends on material that cannot be read freely. It connects open access to independent implementation, public review and the ability of the Web community to evaluate a technology it may be asked to adopt.

It then identifies the cost on the other side. Digital Credentials is intended to let browsers mediate presentation of digital credentials. Government issuers already use, or are preparing to use, mobile-driving-licence systems built around ISO/IEC 18013-7. If the W3C document could not carry that protocol, those credentials would sit outside the common browser route. Developers might continue using custom URI schemes, app-to-app handoffs or other less consistent mechanisms.

The Council therefore found that the external annex supplies critical functionality for an important deployment case and that no freely accessible reference currently provides the same function. In this specific comparison, exclusion cost more than retention.

That is a stronger decision than either slogan available to the debate. “All standards must be free” ignores deployed systems and can push an important use case away from the Web surface the specification is trying to make safer. “Running implementations settle the matter” ignores the people who cannot independently inspect the rules on which a public Web standard depends. The Council treated both as real costs.

The result is legitimate only within that comparison. It does not establish that CHF 181 is trivial, that every relevant implementer has access, that the ISO text is defective, or that the W3C specification is invalid. A paywall is an access condition, not a technical verdict. Nor does one deployment case make every non-free reference acceptable. The Council repeatedly framed the result as an exception and said the underlying concern remained.

Deployment reality is evidence, not perpetual authority

The most valuable part of the Council's reasoning is its attention to operating reality. It did not preserve the reference because ISO is prestigious or because the Working Group had already spent time on it. It preserved the reference because government-issued credentials create an interoperability need that a browser-mediated mechanism is intended to serve.

That is close to Heng Lu's Running-Code Primacy, but with an important institutional boundary. A document does not create operational reality merely by being published. An implementation commitment in a pull request does not prove conformance, user coverage or interoperable deployment. Actual software, tests, credential issuers, wallets, browsers and relying parties supply the later evidence.

At the same time, running code does not silently rewrite a W3C specification. Implementers can demonstrate that a protocol is needed, that two versions do not interoperate or that a free alternative now works. The authority to retain, narrow, replace or remove the normative reference remains with the W3C process at its stated decision points.

This distinction prevents two forms of laundering. Institutional procedure cannot present a document as reality without deployment. Deployment cannot be presented as a permanent mandate without a reviewable decision. Evidence and authority meet at a recorded transition; neither substitutes for the other.

The W3C Team made that transition concrete. It recommended maintaining the reference, pursuing ISO Publicly Available Specification status and revisiting the need when Digital Credentials exits Candidate Recommendation, based on implementation feedback. That is not an expiry date. It is a review trigger tied to a maturity event and an evidence class.

The new Guidebook records admission, not the whole life cycle

The Council recommended clearer policy for exceptional normative references. W3C acted quickly. The Normative References Guidebook records a 24 July update adding free availability as a requirement with exceptions.

The Guidebook now says W3C generally prefers standards-track work not to depend normatively on specifications that are not freely available. If a technically aligned free specification is equivalent, the free document should carry the normative role. In exceptional circumstances, W3C may accept a non-free dependency when the cost of excluding it outweighs the cost of retaining it and a free alternative cannot reasonably supply the critical function.

For each exception, the producing group must document why the external specification is necessary, whether a free alternative exists, what function would be lost, who would be unable to review or implement, and what mitigation is available. Possible mitigations include informative summaries, liaison work, requests for public availability and a narrower reference.

Those five elements are a good admission record. They make a Working Group show its work before treating restricted material as part of a public standard. They also prevent “industry practice” from becoming an unsupported incantation.

Admission is not the same as continuing validity. Necessity can change. A free equivalent can appear. Access terms can improve or deteriorate. An external specification can be corrected, revised or withdrawn. Implementations can converge on a different protocol. A supposedly narrow dependency can grow through interpretation. The people affected by the access barrier can also change as the W3C document moves from specialist review toward wider implementation.

The Council recognized this. It suggested review at subsequent maturity stages and continued liaison by the Team. It also asked the Advisory Board to consider elevating normative-reference guidance from the Guidebook into a standalone policy subject to Advisory Committee Review. The public record examined for this Article shows the July language in the Guidebook; it should not be misdescribed as proof that the proposed standalone policy has already completed that separate path.

The external version is already moving

The current Digital Credentials Working Draft is dated 27 August 2026. Its supported-protocol table still maps org-iso-mdoc to ISO/IEC TS 18013-7:2025 Annex C, and its normative bibliography still names the May 2025 edition. That specificity is valuable. It gives the dependency a version and a part.

ISO's own lifecycle page makes the reason for specificity visible. The 2025 publication remains the published edition, but it is at stage 90.92, marked for revision. A successor, ISO/IEC CD TS 18013-7, is under development as Edition 3 at Committee Draft stage.

These facts do not mean the W3C reference is stale today. The Committee Draft has not replaced the cited edition merely by existing. It may change before publication. The current 2025 annex remains the exact artifact named by the W3C document.

They do mean that “ISO/IEC 18013-7” is too loose a governance label. When the external publisher releases a successor, W3C will face several separate questions. Is the new edition backward compatible at the protocol surface used by Digital Credentials? Does the old annex remain available? Has the access route changed? Do deployed credentials use the old edition, the new one or both? Does a free equivalent now exist? Would updating the reference change behavior or merely correct lineage?

An automatic pointer to “the latest edition” would surrender change control to an external process. Freezing the 2025 edition forever could detach the W3C document from deployed credentials and security corrections. The right answer is a visible choice at a defined W3C transition, supported by evidence.

Give the exception a state receipt

The missing object is not another essay on openness. It is a small, maintained record joining the permission to its current conditions.

For this reference, an exception-state receipt should record:

  • the exact external title, edition, date and Annex C boundary;
  • the exact W3C document version and maturity stage in which it is normative;
  • the Working Group decision, Formal Objection, Team recommendation and Council disposition;
  • the necessity claim and the deployment evidence supporting it;
  • the current state of any freely accessible equivalent;
  • the classes of reviewer and implementer affected by restricted access;
  • the publisher's public access route and lifecycle state, without copying protected content;
  • liaison, PAS request and other mitigation state at the level W3C can verify publicly;
  • implementation commitments separately from tests, interoperable implementations and observed deployment;
  • the accountable W3C role and next review trigger;
  • the current disposition: retain, narrow, substitute or remove; and
  • a correction and supersession history.

The receipt should use bounded states. “PAS requested” is not “free access granted.” “Successor under development” is not “reference replaced.” “Implementation commitment” is not “interoperability demonstrated.” “Council exception granted” is not “exception permanently satisfied.”

It also needs dates. A review trigger such as exit from Candidate Recommendation is stronger than “review later” because it is observable. If that transition is delayed, W3C could add a calendar backstop. The point is not to force removal on a date regardless of evidence. It is to prevent the absence of a meeting from becoming the decision.

The public record need not contain the ISO annex. It should not reproduce protected technical content, licensed extracts or access credentials. It records the edge around the content: what exact artifact carries normative force, why W3C accepted it, what has changed around it and who must decide again.

Keep the common layer thin

Heng Lu's Minimum Initial Specification offers a useful design test. The common layer should contain only what independent participants need for interoperability, expressed as narrowly and deterministically as possible. Later institutional ambition should not turn one necessary interface into a wider claim of control.

Applied here, the lesson is not “remove ISO.” It is “do not let the exception spread.” The W3C reference should remain attached to the exact protocol function and the exact annex that justify it. It should not silently import the whole mobile-driving-licence framework, every later edition or every policy choice made around government credentials.

The same discipline protects ISO. A narrow reference makes clear that W3C is not rewriting ISO's publication terms or claiming ownership of its specification. It identifies the interoperability edge at which two standards systems meet. Each institution retains its process, while the shared boundary remains inspectable.

It also protects implementers. A browser vendor can know which protocol identifier and external edition it is being asked to support. A wallet or issuer can distinguish present conformance from preparation for a future edition. An independent reviewer can identify the part that cannot be inspected freely and evaluate the mitigation without being told that the entire external catalogue is necessary.

The narrower the dependency, the more meaningful the review. A broad exception becomes an institutional relationship. A narrow exception remains a technical decision.

What the public record can and cannot prove

At the cutoff, the record proves a completed W3C decision and a current Working Draft reference. It proves that W3C changed its Guidebook after the case. It proves the public price and lifecycle labels displayed by ISO. It proves that pull request 401 identified implementation commitments for WebKit and Chromium.

It does not prove that those browser implementations are complete, interoperable or deployed to a defined user population. It does not prove how many reviewers bought the ISO publication, received access through another channel or abandoned review. It does not prove that ISO will grant PAS status. It does not establish how the Committee Draft will differ from the 2025 edition.

These are not reasons to postpone the receipt. They are the fields the receipt should keep open. Unknown is a valid state when it is explicit, dated and assigned to a later evidence event.

The Council handled the hard first decision responsibly: it acknowledged the barrier, named the deployment need and refused to pretend either cost was zero. The next governance test is quieter. W3C must ensure that a decision made for a specific edition, access condition and deployment problem remains attached to those conditions.

A justified exception does not need a ceremonial sunset. It needs a clock, a custodian and a record that can change the answer.

Sources

  1. W3C Council Report on the Formal Objection concerning ISO/IEC 18013-7 Annex C
  2. W3C Team report on the Formal Objection
  3. Formal Objection, 9 February 2026
  4. Working Group Chairs’ consensus announcement, 27 January 2026
  5. w3c-fedid/digital-credentials pull request 401
  6. W3C Digital Credentials Working Draft, 27 August 2026
  7. W3C Normative References Guidebook
  8. W3C Process Document
  9. W3C Council overview
  10. ISO/IEC TS 18013-7:2025 official product page
  11. ISO/IEC CD TS 18013-7 successor project
  12. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  13. Heng Lu — Running-Code Primacy