Conditional fast-track amendments for tracking an external authoritative source (e.g., cryptographic algorithms)

[shigeya]

Problem

This concerns post-publication maintenance of documents that have reached Recommendation — i.e., amendments to a published REC under §6.3.10. It does not touch the pre-REC track. Some Recommendations normatively depend on an external authoritative source whose state changes over time, within a bounded
portion of their text. The clearest case is cryptographic algorithm agility: deprecating a weakened algorithm or adding a newer one. Today, each such change is a substantive change (or new feature) under §6.3.10 requiring full AC Review, even when it is narrow and driven by an external, authoritative
event (e.g., a NIST deprecation).

SRI (sri-2) illustrates the gap: its text MUST support SHA-256/384/512 and anticipates adding/deprecating algorithms over time, yet the valid SRI hash algorithm token set («sha256, sha384, sha512») is normative, so adding or removing one element needs a full substantive revision. The spec is written to expect churn; the Process offers no proportionate path to perform it.

Proposal (sketch)

A conditional amendment clause that a Recommendation may declare at publication time, consisting of:

1. A pre-fixed textual scope — an explicitly delimited portion of the document (e.g., an algorithm token set or table). This scope is fixed at publication and cannot be widened later. This is the primary guardrail: the fast track may only bring the pre-delimited scope into conformance with the named source, and nothing else.
2. A named external authoritative source and the condition on it that may trigger an in-scope update.
3. A trigger + short confirmation step — the WG/maintaining entity declares the condition met (citing the source), followed by a short public confirmation period; the Team verifies procedural conformance.

The Team may route any individual amendment through normal review instead, and the usual Formal Objection path remains available.

Worked example (cryptographic algorithms). Eligible in-scope changes are limited to the deprecation/removal of an algorithm, and the addition of an algorithm already standardized with Royalty-Free terms in an external body. Other changes stay on the normal track.

Retrofit. Existing Recommendations without such a clause (e.g., SRI) gain the capability via one ordinary substantive revision whose sole effect is to add the clause and delimit its scope — keeping the AC fully in the loop for the opt-in itself, then using the fast track for later in-scope updates.

Relationship to existing mechanisms and prior work

• Registry Track (§6.5) is the right tool going forward, but post-dates many Recommendations and does not help specs that reference an authority inline in normative prose (such as SRI) without first restructuring them.
• Candidate Amendments / §6.3.10 batch changes but still route every substantive change through AC Review; they offer no conditional pre-authorization.
• This is not a revival of a separate "Evergreen"/Living-Standard track (cf. the 2019–2020 discussion, which settled on evolving ordinary RECs via amendments rather than new classes). It adds one variety of amendment inside that settled path, requires no new tooling, and keeps the document a normal Recommendation.

Prior art (IETF)

IETF keeps algorithm sets current without re-publishing the defining RFC by relaxing the registration policy of the relevant IANA registry — e.g., RFC 6014 (DNSSEC: Standard Required → RFC Required) and RFC 9847 (several TLS registries → Specification Required, registering after a bounded ~3-week expert review while reserving part of the space for Standards Action). Two lessons transfer: the unit needing a light path is the algorithm-designating portion, not the whole document; and "light" need not mean "unreviewed" — a bounded confirmation step can stand in for full review.

Open questions for the AB / Process CG

1. Patent Policy. Does adding an externally RF-established algorithm create an Exclusion Opportunity? Deprecation/removal arguably introduces no new claims; addition is the harder case. Preferred starting position: permit deprecation plus addition of already-RF-established algorithms, but the patent treatment of addition needs AB resolution.
2. Trigger authority & verifiability. This favors WG declaration + short confirmation; alternatives (Team Decision; a machine-verifiable reference to the source's state) should be weighed.
3. Decision type & appeal route for an in-scope fast-track amendment.
4. Is the pre-fixed-scope guardrail sufficient to prevent broad scope clauses from smuggling general substantive change past AC Review?

[frivoal]

I think the Process does offer something to deal with this: registries. You do mention them in passing, but I am not completely sure why you're rejecting them. Yes, you'd need to edit pre-existing recs to start using them, but you'd need to make some change to pre-existing RECs to use any different approach anyway.

Just as you suggested, they let you define a specific section/table that is intended to be updated, you define ahead of time what are the constraints on doing such updates, but after that, you do not need to go through AC review and all that to update it.

You write your REC, you say something like "The set of values usable for the SRI hash algorithm token and their respective meaning are documented in the SRI hashing function registry". Depending on publishing convenience, you either mark a specific section of the document as being the SRI hashing function registry, or you establish a separate document that called that. That registry doesn't specify hashing functions, it just lists those known values, and points to normative definitions some place else. Possibly it also has an extra column to mark some as deprecated. But whether as a separate registry document or as a registry section, you can update it without going through all the REC updating hoops. You just need to go through the hoops you defined for yourself when you established that document.

With regards to the patent policy, the way this is handled is that this registry section/document cannot specify new normative things. It just names things, list things, document things… but the normative meat of these entries must be in some other document somewhere, either itself on the REC track if it is at W3C, or on whatever is appropriate if it's a different standards body. That makes them out of scope for the patent policy, so there's no need for exclusion opportunities on the registry itself (the specs themselves are handled as usual). See https://www.w3.org/policies/process/#reg-ref-specifications

I am not familiar with SRI, so there may be subtleties I am missing, which either would require a slightly different coupling between the normative referencing spec, the registry, and the referenced hashing function specs. Or maybe I'm missing something important entirely. But it seems to me that Registries are likely to be exactly the tool you're looking for.

[shigeya]

Thanks, @frivoal — this is very helpful, and I think you're right that Registries are the relevant tool here.

What I hadn't anticipated is that the Patent Policy concern could be resolved in this particular way. I had been treating the addition of an algorithm as something that might create an exclusion opportunity, and looking for ways to bound or shorten it. The registry approach sidesteps that entirely: because the registry itself carries no normative substance — the normative meat stays in the referencing specification or an external body's spec — there's no exclusion opportunity on the registry to bound in the first place, exactly as you describe and as #reg-ref-specifications sets out. That dissolves what I thought was the hardest part of the problem.

There's one piece of history worth surfacing, though, since you noted you're not familiar with SRI. The "reference an external hash registry" approach was actually proposed for SRI before — referencing the IANA hash-name registry, in w3c/webappsec-subresource-integrity#119 — and it was declined by the editors and closed. The stated reason was that SRI should list only the algorithms user agents actually plan to support, added individually as implementations land, rather than deferring to an external list that may grow independently. As far as I'm aware it hasn't resurfaced since, and sri-2 still keeps the token set inline.

There's also something a registry doesn't, by itself, resolve. In SRI the valid SRI hash algorithm token set is an ordered set whose ordering is normative — it encodes relative algorithm strength, and UAs rely on it (getPrioritizedHashFunction, "get the strongest metadata from set"). The membership question (which tokens are valid) is registry-shaped — the kind of registry reference you sketched would carry the names cleanly enough — but the strength-ordering across entries is implementation-affecting and lives with the referencing spec, not with a list of names. So a registry can carry the names, but the part that actually needs care when an algorithm is added or deprecated — where it sits in the strength order — isn't something the registry settles. I'm not taking a position here on how SRI itself should be structured; only noting that the registry reference, on its own, leaves that piece open.

Given that, I'm not pushing the conditional-amendment framing here — Registries are clearly the better fit for the general case, and I don't want to relitigate that. What keeps me from closing this entirely is that SRI is a case where the editors have, so far, preferred to keep the token set inline rather than move it behind a registry (#119). For specs that make that choice, some lightweight, bounded way to update the in-spec algorithm set might still be worth having — and the ordering/strength point above is part of why the set isn't just a flat list that trivially lifts into a registry. I'd rather not argue that case now, but I'd like to leave the issue open a little longer rather than close it, since the SRI-2 situation seems to be exactly where such a path would help.

[frivoal]

The normative ordering of the algorithms does seem to make the problem harder. As it is normative, it seems like poor fit for being in the registry, but if you need to update the spec every time to deal with that, that kind of defeats the point…

For this very specific case, it feels like granting an exception would be fine. Changing an ordering doesn't seem to have much implications in terms of patents, privacy, internationalization, accessibility… So skipping some amount of review feels temping. But I am not quite sure who we generalize the Process rules to allow for that, while not opening the door to all sorts of abuse.

Or maybe it is the Registry side that can be stretched/generalized/extended a bit? As in: the spec normatively continues to a define a non-changing logic of dealing with an ordered set, and the registry is just data, containing the rank by which you order. That gives updates to the registry normative / conformity implications, but they're very scoped because it's only the data that can change, not the logic which works with that data. That feels a little more constrained and easy to achieved. Then again, the frontier between data and logic can be somewhat fuzzy. Maybe the initial AC Review of the particular rules of this registry would sufficient to deal with this fuzziness? Storing an index or rank with normative implication as data in your registry?→ OK. Storing arbitrary chunks of JS code as data in your registry? → Registry rejected.

[nigelmegitt]

I was about to propose the same fix as @frivoal - include within the registry data a value that can be used to compute the ordering. The algorithm for computing the ordering is not part of the registry, and can be normative. What cannot be normative is any normative behaviour or semantic associated with a particular value in the registry.

An example where I've done something a bit like this is DAPT's <content-descriptor> where there is normative text outside the registry section that defines the permitted syntax of each content-descriptor, being constructed out of delimited tokens, and how to compute if one content-descriptor is a sub-type of another.