Summary

  • W3C Strategy issue 568 opened a recharter proposal for the existing Security Interest Group on 19 August 2026; the refinement end date is still unknown.
  • The draft says technical development of standards is outside the Interest Group’s scope and sends Recommendation-track opportunities to a suitable Working Group, Community Group or Business Group.
  • The same draft asks for key implementors of “this specification,” active Editors and Test Leads for each specification, and says specification Working Drafts and Editor’s Drafts will be developed publicly.
  • Current Security IG outputs cited in the draft are Group Note Drafts whose status expressly differs from W3C or Member endorsement and from Recommendation-track patent commitments.
  • A deliverable-and-handoff receipt should bind every role to an output class, owning group, patent state and explicit acceptance by the next competent group.

One draft, two authority vocabularies

The W3C Security Interest Group has a recognizable horizontal function. It advises groups developing standards, reviews security implications and helps make threat analysis more systematic. Its current charter runs until 18 November 2026. On 19 August, W3C’s Strategy Funnel opened issue 568 for an existing-IG recharter. The issue says the mission, scope and success criteria remain substantially intact, while the deliverables now point to current drafts and coordination language replaces PING with the Privacy Working Group.

The proposed charter is visibly unfinished. Its start and end dates are placeholders. Its teleconference line ends with “or something else.” Its call-for-consensus sentence gives a response period “from one week” without completing the range. The charter-history table makes the initial 2024 charter begin and end on the same day, even though the active charter shows a two-year term. Those details are not evidence of misconduct. They establish the correct evidentiary state: this is a draft being refined, not an approved instrument whose every sentence should be treated as deliberate policy.

The substantive boundary is nevertheless worth fixing now. In its Out of Scope section, the draft is direct. Technical development of standards does not belong to the Interest Group. A Recommendation-track opportunity should be handed to an appropriate W3C Working Group, or to a Community Group or Business Group when incubation is needed.

That is one authority vocabulary: advice, review, incubation and handoff.

The participation section uses another. It expects representatives from key implementors of “this specification,” active Editors and Test Leads for each specification, and a half-day weekly contribution from Chairs, specification Editors and Test Leads. The communication section says Working Drafts and Editor’s Drafts of specifications will be developed in public repositories. Those clauses sound like a generic Working Group charter template because they describe production roles without naming the document class they serve.

The problem is not the word “specification” by itself. An Interest Group can maintain rigorous technical material. The problem is that the role label travels without an owner, track or handoff state.

Notes, prototypes and Recommendations are different entities

The draft’s deliverables show why a binary rule—“an IG may never edit a specification”—would be wrong. The Security IG may publish analyses, security principles, threat models, guidelines and prototype specifications consistent with its scope. Such work can be technically exact and highly influential. Editors and test contributors can be useful even when the output is not a W3C Recommendation.

The two current documents newly linked from the charter make the distinction concrete. The Threat Model for the Web, published on 21 July, is a W3C Group Note Draft. The Threat Modeling Guide, published on 23 June, is also a Group Note Draft. Each status section says the Security IG endorses the document, while W3C itself and its Members do not. Each remains work in progress and is on the Note track rather than the Recommendation track. The status also says the Patent Policy creates no licensing commitment for that Note.

None of this makes the documents weak. A Note can supply a shared analytical method without claiming the institutional or patent state of a Recommendation. A prototype can reveal feasibility without assigning the recipient Working Group’s adoption decision. A security review can identify a defect without making the reviewer the editor of the reviewed standard.

Those distinctions protect the group’s influence. If every technical artifact is called a specification and every maintainer a specification editor, readers must reconstruct from another page whether they are looking at advice, a prototype, a Group Note Draft, a Working Draft on the Recommendation track, or an editor’s unofficial working text. The same title then carries several incompatible expectations.

Handoff is an event, not a sentence

The draft already points toward the right mechanism: Recommendation-track opportunities are handed elsewhere. But “will be handed over” does not create a public state transition by itself.

A handoff has at least two sides. The Security IG can identify an opportunity, describe the threat or control problem, and name a possible recipient. The recipient group must still determine whether the work fits its charter, whether it needs incubation, which document it would own, which patent regime applies, and whether it has editors, implementors and tests. Silence is not acceptance. A link is not adoption. An editor appearing in both groups is not institutional transfer.

This matters especially for horizontal review. W3C’s guide says horizontal groups provide expertise across proposals, specifications and charters developed by Working Groups, Interest Groups and Community Groups. That reviewing position is valuable partly because it remains distinguishable from ownership. A reviewer can ask whether threats, mitigations and residual risks are adequately described. The owning group must decide how the normative design changes and record the disposition.

Blurring those roles creates a subtle accountability gap. If advice succeeds, several groups may claim the result. If it is not adopted, readers may not know whether the recipient rejected it, deferred it, never received it or considered the underlying issue already resolved. If a prototype continues to evolve after handoff, two documents may appear to define the same feature while carrying different patent and endorsement states.

The current draft gives reviewers a clean repair window

Because refinement is open and its expected end is unknown, the text can be corrected without pretending that a governance failure has already occurred. Three small edits would remove most ambiguity.

First, participation should name the output classes. If Editors and Test Leads maintain Security IG Group Notes, review questionnaires, threat models or in-scope prototypes, the charter should say so. If implementor participation is desired for reviewed specifications owned by other groups, the role should be described as review evidence rather than authorship authority.

Second, communication should distinguish drafts produced by the IG from specifications merely under review. “Working Draft” is not a generic phrase in W3C publishing. A public repository can host an Editor’s Draft for several document types, but the charter should state the track and owner before readers infer Recommendation-track status.

Third, the handoff clause should identify the receiving record. A transition should have a public source proposal, recipient, date, disposition and current owner. If the receiving group declines or lacks charter scope, the record should remain open rather than allowing the original IG artifact to acquire authority by default.

The template residues are useful diagnostics here. The incomplete meeting sentence and malformed history row make it easier to recognize that generic language survived into the draft. Fixing only the obvious placeholders would be limited public evidence if the deeper role ambiguity remained.

A deliverable-and-handoff receipt

The minimum public record can be compact. For every sustained Security IG output or transferred opportunity, it should contain:

  • a stable deliverable identifier and exact document revision;
  • the output class: review, questionnaire, Group Note Draft, prototype, incubation report or Recommendation-track document;
  • the owning group and the charter clause authorizing the work;
  • the named editors, test leads and implementors, with the scope of each role;
  • the current endorsement, publication and patent state;
  • the reviewed specification and the security issue or recommendation being tracked;
  • the handoff trigger, intended recipient and date;
  • the recipient’s acceptance, rejection, deferral or request for incubation;
  • the resulting document identity and new owner, if accepted; and
  • correction, supersession and closure history.

This is not a demand for a larger approval system. It is the opposite. Heng Lu’s Minimum Initial Specification discipline asks a coordination layer to carry only what common operation needs, while later reality is proved through implementation and adoption rather than declaration. Applied here, the common record need not judge whether a security idea is good. It needs only to prevent one document class or role from silently impersonating another.

The Security IG should be able to publish strong advice, maintain precise Notes and build useful prototypes without being mistaken for a Recommendation-track Working Group. A Working Group should be able to adopt that work without erasing where it came from. The draft’s out-of-scope clause already states the constitutional boundary. Refinement should make every editor, test lead and draft title obey it.

Sources

  1. W3C Strategy — Security Interest Group charter issue 568
  2. W3C — draft 2026 Security Interest Group Charter
  3. W3C — active 2024–2026 Security Interest Group Charter
  4. W3C — diff from the active charter
  5. W3C — Threat Model for the Web
  6. W3C — Threat Modeling Guide
  7. W3C — Process Document
  8. W3C — Security Interest Group page
  9. W3C Guidebook — Horizontal Groups
  10. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption