摘要

  • W3C Strategy issue 568 于 2026 年 8 月 19 日启动既有 Security Interest Group 的重新授权；章程完善阶段何时结束仍标为未知。
  • 草案明确把标准的技术开发排除在 Interest Group 范围之外，并要求把 Recommendation Track 的机会移交合适的 Working Group、Community Group 或 Business Group。
  • 同一草案却要求“本规范”的关键实现者、每项规范的编辑和测试负责人参与，还称规范的 Working Draft 与 Editor’s Draft 将在公开仓库中开发。
  • 草案列出的两项现行成果都是 Group Note Draft；其状态页明确区分 Security IG 的认可、W3C 或成员的认可，以及 Recommendation Track 的专利承诺。
  • W3C 应为持续成果和移交事项建立“成果—移交回执”，把角色绑定到文档类别、所属组织、专利状态和接收方的明确处置。

一页文本里的两套权力词汇

Security Interest Group 的横向职责并不模糊。它向开发标准的组织提供安全建议，审查技术风险，并帮助其他组织把威胁分析做成可重复的工作。现行章程有效期至 2026 年 11 月 18 日。8 月 19 日，W3C Strategy Funnel 以 issue 568 启动重新授权。说明文件称，使命、范围和成功标准基本不变，主要更新包括链接最新的威胁模型与指南，并用 Privacy Working Group 替换旧的 PING 协作表述。

这份草案显然尚未完成。开始和结束日期仍是占位符；电话会议安排保留了临时语句；征求共识的答复期限没有写完整；章程历史表甚至把 2024 年初始章程的起止日写成同一天，而现行章程显示的是两年期限。这些痕迹不是恶意或程序无效的证据。它们只说明阅读者必须把页面当作待完善草案，而不是把每个字都当成最终政策。

但其中的实质边界值得现在就修。Out of Scope 条款直截了当地说，标准的技术开发不属于该 Interest Group。发现 Recommendation Track 机会后，应当移交合适的 W3C Working Group；若还需孵化，则交给 Community Group 或 Business Group。

这是第一套词汇：建议、审查、孵化和移交。

Participation 条款却使用另一套词汇。它期待“本规范”的关键实现者代表，以及每项规范的活跃编辑和测试负责人；还要求主席、规范编辑和测试负责人每周投入半个工作日。Communication 条款则说，规范的 Working Draft 和 Editor’s Draft 将在公开仓库中开发。

问题不在于 Interest Group 绝对不能使用“规范”一词。它完全可以维护严谨的技术材料。真正的问题是：角色名称出现时，没有同时标明文档类别、所属组织和移交状态。

Note、原型和 Recommendation 不是同一种对象

草案的成果清单说明，简单宣布“IG 不得编辑规范”同样不准确。Security IG 可以发布安全分析、原则、威胁模型、指南和符合范围的原型规范。这些成果可能需要编辑、实现经验乃至测试，但并不会因此自动成为 W3C Recommendation。

草案新链接的两个文件让区别变得可验证。7 月 21 日发布的 Threat Model for the Web 是 W3C Group Note Draft；6 月 23 日发布的 Threat Modeling Guide 也是 Group Note Draft。两者的状态页都写明：文件得到 Security IG 的认可，但并未得到 W3C 本身或其成员的认可；它们仍是 Note Track 上可以更新、替换或废弃的工作稿，Patent Policy 也没有为此类 Note 产生许可承诺。

这并不削弱它们。一份 Note 可以提供共同的分析方法，原型可以验证可行性，横向审查可以发现设计风险。只是这些行为都不能替代拥有规范的 Working Group 对规范性文本作出的决定。

如果所有技术成果都只叫“规范”，维护者都只叫“规范编辑”，读者就必须去别处判断自己看到的是建议、原型、Group Note Draft、Recommendation Track 的 Working Draft，还是编辑的非正式工作文本。同一个名称开始承载互不兼容的认可、专利和标准权威预期。

移交不是单方面的发送动作

草案已经提供了正确方向：Recommendation Track 机会要移交其他组织。但“将移交”这句话本身并不会生成公开、可核验的状态变化。

Security IG 可以识别机会、描述威胁并提出接收方。接收组织仍需决定事项是否落在其章程范围内、是否需要先孵化、由哪份文档承接、适用何种专利制度，以及是否具备编辑、实现者和测试资源。沉默不是接受，仓库链接不是采纳，同一名编辑同时参与两个组织也不等于制度权力已转移。

这种区分对横向审查尤其重要。W3C 指南把横向组织描述为向不同组织开发的提案、规范和章程提供专业审查。审查者可以要求说明威胁、缓解措施和剩余风险；拥有规范的组织必须决定如何修改规范性设计，并记录对审查意见的处置。

如果两边没有公共连接记录，未被采纳的建议可能看起来像从未收到；原型也可能在移交后继续演进。两个仓库于是可能用同一个功能名称表达不同设计，同时处在不同的认可和专利状态中。

未定稿状态正是干净的修复窗口

Issue 568 仍处于开放状态，结束日期未知。W3C 可以用三项小改动消除大部分歧义。

第一，Participation 应写明成果类别。如果编辑和测试负责人维护的是 Security IG 的 Group Note、问卷、威胁模型或原型，就应明确列出。如果实现者参与的是对其他组织规范的审查，则应把他们的作用写成审查证据，而非暗含编辑权。

第二，Communication 应区分 IG 自己产生的草稿和它仅负责审查的规范。在 W3C 语境中，Working Draft 不是泛称。每份草稿都应有清晰的 Track 和所属组织。

第三，移交条款应指向接收记录：源提案、接收方、日期、处置结果和当前所有者。如果接收方拒绝、延期或没有相应章程权限，记录就应保持开放，不能让原始 IG 文件因无人接手而默认获得更大权威。

一份成果—移交回执

所需的公共记录可以很小。每项持续成果或被移交的机会至少应包含：

  • 稳定成果标识与准确文档修订版；
  • 审查、问卷、Group Note Draft、原型、孵化报告或 Recommendation Track 文档等类别；
  • 所属组织与授权该工作的章程条款；
  • 编辑、测试负责人和实现者，以及各自角色范围；
  • 当前认可、出版与专利状态；
  • 被审查规范及对应的安全问题或建议；
  • 移交触发条件、拟接收方和日期；
  • 接收方的接受、拒绝、延期或孵化要求；
  • 接受后的新文档标识与新所有者；
  • 更正、替代和关闭历史。

这不是再增加一个审批机构。Heng Lu 在 Minimum Initial Specification 中强调，共同层只应携带必要信息，后续变化要通过实现、运行和采用成为现实，而不能只靠声明。应用到这里，回执不负责判断安全建议是否正确；它只防止一种文档类别或角色悄悄冒充另一种。

Security IG 应当能够发布有力建议、维护精确 Note、制作有用原型，而不被误认为 Recommendation Track Working Group。Working Group 也应能够采纳这些成果，同时保留来源与处置链。草案的 Out of Scope 条款已经画出宪法边界；完善程序需要让每个编辑、测试负责人和草稿标题都服从这条边界。

来源

  1. W3C Strategy — Security Interest Group 章程 issue 568
  2. W3C — 2026 年 Security Interest Group 章程草案
  3. W3C — 2024–2026 年现行章程
  4. W3C — 草案与现行章程差异
  5. W3C — Threat Model for the Web
  6. W3C — Threat Modeling Guide
  7. W3C — Process Document
  8. W3C — Security Interest Group 页面
  9. W3C 指南 — Horizontal Groups
  10. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption