Summary

  • W3C's namespace page says w3.org/2026/08/xmldsig-more# was allocated to XML Security and was last revised on 19 August 2026, but it points to a latest-draft view rather than a numbered revision.
  • RFC 9231bis revision -08 still used w3.org/tbd#; revision -09, posted on 21 August, first substituted the new namespace and also added other material. The public record does not say which bytes the allocation covered.
  • W3C's own guidance says a namespace change policy should state how names may be defined or removed and by whom. The new namespace document states no such rule, and silence proves neither mutability nor immutability.
  • A namespace change constitution should bind allocation to a revision and hash, specify pre-freeze edit authority and compatibility treatment, name the freeze event, and keep W3C, IETF and IANA states separate.
  • This is not an allegation of an invalid allocation, algorithm endorsement, IETF adoption, registry delay or failed collaboration. Early allocation and draft iteration are legitimate; their authority chain is simply not yet public as one joined record.

The namespace arrived before the revision that uses it

The W3C namespace document is only a few lines long. It says the URI “has been allocated to XML Security,” says it corresponds to a specification, links to the Datatracker's current view of draft-eastlake-rfc9231bis-xmlsec-uris, and records: “Last revised by Simone Onofri on 2026-08-19.”

That brevity is not itself a defect. Namespace documents often function as durable signposts. A stable URI lets editors stop inventing provisional identifiers, permits cross-specification review and reduces the chance that independent implementations choose colliding names. Allocation during discussion can therefore be an enabling act rather than premature approval.

But this signpost points to a moving destination. It does not identify a numbered draft, a hash, an allocation request, the person or body that authorized the prefix, or the conditions under which its local names may change. A reader who arrives next month can see the latest draft. The reader cannot see which draft state W3C considered when it granted permission.

The distinction became concrete within two days.

Public coordination changed shape as the draft changed

The W3C Strategy issue began on 17 November 2024 as a proposal for a workshop on post-quantum cryptography in XML Signature and XML Encryption. It described a broad problem, several use cases and a possible update to RFC 9231. That issue is useful evidence of open coordination. It is not a Recommendation, a charter, a transition decision or a vote.

On 21 November 2024, the individual draft's author offered to add algorithms to the RFC 9231bis work. On 14 June 2025, a public comment listed HSS/LMS, ML-DSA, SLH-DSA and ML-KEM, and suggested that perhaps the GitHub issue could do the work originally imagined for a workshop. Those are visible handshakes between people doing useful work. Neither an author's offer nor an issue comment creates W3C or IETF institutional approval.

The pace accelerated in August 2026. A 17 August update said revision -08 covered the four tracked families and that -09 was being prepared with FrodoKEM and SignatureContext material, while another question remained open. The namespace page carries a 19 August revision date. The draft author then announced -09 on 21 August. On 26 August, the issue's public purpose was reframed: it was no longer about holding a workshop, but about tracking the needs to update XML Signature and XML Encryption.

This is what healthy working coordination often looks like: the intended venue changes, a draft absorbs proposals, open questions remain and the public issue is repurposed. It is also why a namespace permission needs a version receipt. A URI allocated into a live workstream can outlast the particular issue, contributors and document state that first justified it.

No public source here establishes which exact draft bytes W3C reviewed. It would be equally unwarranted to assert that no internal record exists. The evidence supports a narrower observation: the namespace page does not expose that join.

The two revisions make the missing join measurable

The current Datatracker record showed revision -09 at the evidence cutoff. It also showed the work as an active individual Internet-Draft, with IESG state I-D Exists, no defined RFC stream and no responsible Area Director. The record warns that anyone may submit an Internet-Draft and that publication in the Repository does not give the document formal IETF standing or endorsement.

The document itself has another, compatible layer of state. It identifies its author as Independent, says “Obsoletes: 9231 (if approved),” gives “Standards Track” as its intended status and expires on 22 February 2027. The header says what the author seeks and what would happen conditionally. The Datatracker says where the institutionally attributable process currently stands. One is not evidence that the other is wrong.

The archived -08 revision, dated 26 May 2026, assigns the proposed new identifier family to w3.org/tbd#. Its frozen file hashes to cd9d7a31d66dabcb692b2bba3804102b5bba9e3376b999b0cb1404a20ff7f10f.

The archived -09 revision, dated 21 August, replaces those placeholders with w3.org/2026/08/xmldsig-more#. It also includes further changes, including additional proposed identifiers and a new schema appendix for the 2026 namespace. Its hash is 09d36d24b05cbc0c1be1579d65fab88e6f9b6cfc13f214d55d4eeed42ad3866b.

The public revision history confirms the 26 May and 21 August upload dates. It displays no Working Group adoption, stream assignment or Area Director handoff by 1 September.

The sequence establishes three facts and no more. First, -08 used a placeholder. Second, the W3C page was revised on 19 August. Third, -09 used the allocated namespace on 21 August. It does not establish the date of the underlying allocation decision, the exact reviewed revision or whether W3C permission automatically covered every other -09 edit.

That missing information matters because a namespace contains a family of durable names, not merely a place to hang one document. Once software, profiles or procurement rules cite a full URI, later editorial movement can create compatibility expectations even before the defining draft reaches an institutional milestone.

Three authorities are visible, but their handoff is not

The current approved anchor is RFC 9231. It documents the preceding generation of additional XML Security URIs and makes an important distinction: an xmldsig-more identifier does not imply official W3C or IETF status for an algorithm. The new draft repeats that defense.

The live IANA XML Security URIs registry still cites RFC 9231 and operates under Specification Required with named designated experts. That is the expected state while a successor draft is unapproved. It is not evidence that IANA is late, hostile to the work or supposed to copy -09 immediately.

The three visible authorities therefore perform different acts:

  1. W3C controls and persists a URI in its web namespace.
  2. An IETF document process can develop, adopt, review and perhaps approve a specification that uses the URI.
  3. IANA applies the registry policy to authoritative registration actions.

The author of an individual draft can edit document text. That does not make the author the custodian of W3C namespace policy. W3C can allocate a URI. That does not make W3C the approving body for an IETF RFC. IANA can maintain a registry. That does not make a registry row a deployment instruction.

Those boundaries are already defensible in the separate records. What is missing is a joined transition map: the exact act that moves the 2026 namespace from editable proposal space to a frozen generation, and the rule for changes on either side of that act.

W3C's guidance asks the question the namespace page does not answer

W3C's namespace allocation guidance recognizes date-coded forms such as /YYYY/MM/.... It says @w3c/transitions allocates and authorizes the listed W3C namespace forms as part of pull requests in w3c/ns. It also explains why early allocation can be useful: W3C maintains persistent URIs so they remain stable during discussion, and allocation does not imply endorsement.

The same guidance does not stop at persistence. It says groups should clearly state how the namespaces they control will or will not change over time, in or clearly linked from the namespace document.

The W3C TAG finding on namespace names makes the expectation precise. Specifications defining namespaces should explicitly state their change policy. If a namespace is not immutable, the specification should describe how names may receive definitions or have them removed, and by whom. If there is a namespace document, the policy should be stated there. In the absence of an explicit statement, a reader cannot infer that the namespace is immutable.

That last sentence blocks two convenient overclaims. Silence does not prove that W3C intends the 2026 namespace to remain open. Silence also does not prove that the -09 set is frozen. The state is not publicly inferable.

W3C's URI persistence policy adds another careful distinction. Date-coded resources fall within the persistence pledge, yet persistent resources may still be modified and their prior state archived. URI persistence protects address continuity. It does not by itself define the mutability of every local name, the compatibility effect of removal or the authority to make a change.

This is not a case for declaring the allocation noncompliant. General guidance can be satisfied through records not found in the short page, and the Article does not know the private or internal decision file. It is a case for making the policy public at the place W3C's own finding tells implementers to look.

Earlier namespace generations reveal the missing freeze event

Revision -09 lists four earlier generations. The 2000 XML Signature prefix is “Frozen by W3C.” The 2001 prefix is frozen with RFC 4051, the 2007 prefix with RFC 6931 and the 2021 prefix with RFC 9231. Each line treats freezing as an attributable state transition, not a quality adjective.

The new 2026 prefix appears beneath that history but has no corresponding public freeze rule. Does it remain editable until an RFC is approved? Until a W3C transition decision? Until designated-expert action? Can a local name be removed if a draft algorithm section disappears? Must a name already cited by an implementation remain reserved? Does any post-freeze addition require a new dated prefix?

These are not arguments for one answer. They are fields that a namespace custodian should fill before different communities answer them by habit. A new dated generation is cheap to name early and expensive to reinterpret after dependencies form.

Identifier syntax must remain separate from algorithm judgment

The 2026 draft draws on the standards context of XML Signature 1.1 and XML Encryption 1.1. Those W3C Recommendations explain how XML security structures consume identifiers and why identifier interoperability matters. They do not approve every algorithm that might later receive an identifier.

The draft's proposed IANA policy continues to use Specification Required. RFC 8126 describes that policy as requiring a permanent and publicly available specification plus expert review. That review route can test documentation and registration suitability. It is still not a universal security certification or an operator mandate.

The Article therefore makes no judgment about HSS/LMS, ML-DSA, SLH-DSA, ML-KEM, FrodoKEM, X-WING or SignatureContext. It does not say an algorithm is safe, unsafe, final, required, implemented or broadly deployed. The governance problem would be the same if the local names identified non-cryptographic features: a persistent identifier family needs a public rule for changing its vocabulary while the target document moves.

A namespace change constitution can be short

The repair does not require a new standards body. A versioned page linked from the namespace document could state the constitution in fifteen fields.

It should begin with the namespace URI, its date-coded class and the allocation decision: authorizing actor, date and public pull request or transition record. It should identify the target draft revision and hash at allocation, then separately identify the revision currently linked.

It should enumerate permitted pre-milestone change classes. Adding a local name, correcting prose about an existing name, renaming a name, removing one and marking one deprecated create different compatibility effects. The record should say who may propose each act, who decides it and whether existing citations reserve the old spelling.

It should name the freeze event and the authority that declares it. If approval of an RFC freezes the generation, say so. If W3C freezes earlier or later, say so. The post-freeze rule should explain whether new work goes through expert review beneath the same prefix, an erratum, a successor RFC or a new dated namespace.

The record should then preserve the distinct institutional states: W3C namespace custodian; IETF document class, group, stream, adoption state and responsible Area Director when they exist; IANA registry policy and designated-expert scope. It should name the document that controls identifier syntax and the sources that control algorithm semantics. Finally, it should record corrections, supersession, expiry and the next review trigger.

Six acts should never be compressed into one green label: namespace allocation, draft publication, IETF adoption or stream assignment, RFC approval, IANA registry update, and protocol or operator deployment. Each has a different actor and evidentiary threshold.

The public layer need not expose informal debate, security-sensitive implementation reports or personal correspondence. It needs only enough provenance to let a reader reconstruct what state existed, who could alter it and which later act changed the answer.

The case is about legibility, not misconduct

Nothing in the source set shows an invalid namespace, bad faith, capture, an unauthorized registry action or failed collaboration. The Strategy issue is public. The individual draft is openly archived. The W3C page is persistent. IANA's current state is correct. The draft itself carefully denies that an identifier carries institutional endorsement.

Those are strengths. They make the missing join more tractable because the component records already exist.

The remaining task is to stop asking a dynamic latest-draft link to perform the work of a constitution. Discovery and authority are different functions. A link can take a reader to today's text. Only a versioned change policy can explain what yesterday's permission covered, what tomorrow's editor may alter and which act makes the namespace generation durable.