要約

  • W3C Strategy issue 568は2026年8月19日、既存のSecurity Interest Groupを再憲章化する提案を開始した。文面調整の終了時期は未定である。
  • 案は標準の技術開発をIGの対象外とし、Recommendation Trackの機会を適切なWorking Group、Community Group、Business Groupへ渡すとしている。
  • 同じ案が「この仕様」の主要実装者、各仕様の編集者とテスト責任者を求め、仕様のWorking DraftとEditor’s Draftを公開リポジトリで開発すると記す。
  • 現在の主要成果物はGroup Note Draftであり、Security IGによる支持と、W3Cや会員による支持、Recommendation Trackの特許上の約束は同じではない。
  • 成果物・移管レシートに文書種別、所有グループ、役割の範囲、特許状態、受け手の処分を記録すべきだ。

一つの案に併存する二つの権限語彙

Security Interest Groupの横断的な役割は理解しやすい。他のグループが開発する標準を安全面からレビューし、脅威の把握や緩和策の検討を支援する。現行憲章は2026年11月18日まで有効だ。8月19日に開かれたissue 568は、使命、範囲、成功基準をおおむね維持しつつ、現在の脅威モデルとガイドへのリンク、Privacy Working Groupとの連携表現などを更新すると説明している。

提案文は明らかに未完成である。開始日と終了日はプレースホルダーのまま、電話会議の説明には仮文言が残る。合意形成の回答期間も文として完結していない。履歴表は2024年の初回憲章を同日開始・同日終了と表示するが、現行憲章は2年間である。これらは不正の証拠ではない。現時点の証拠が、完成した権限文書ではなく修正中の草案であることを示す。

ただし本質的な境界は今のうちに整えられる。Out of Scopeは、標準の技術開発がIGの範囲ではないと明記する。Recommendation Trackの候補は適切なWorking Groupへ、インキュベーションが必要ならCommunity GroupかBusiness Groupへ渡す。

ここでは助言、レビュー、インキュベーション、移管という言葉が使われる。

参加条項は別の語彙を使う。「この仕様」の主要実装者、各仕様の現役編集者とテスト責任者を求め、議長、仕様編集者、テスト責任者に週半日の貢献を期待する。コミュニケーション条項は、仕様のWorking DraftとEditor’s Draftを公開リポジトリで開発すると述べる。

IGが「仕様」という語を使うこと自体が問題なのではない。厳密な技術文書を作ることはできる。問題は、役職名に文書種別、所有者、移管状態が付かないことだ。

Note、プロトタイプ、Recommendationは別の対象である

成果物一覧を見ると、IGは仕様を一切編集できないという単純な規則も成り立たない。安全分析、原則、脅威モデル、ガイドライン、範囲内のプロトタイプ仕様を公開できる。これらにも編集や検証は必要だが、自動的にW3C Recommendationになるわけではない。

案が新たに結び付けた二つの文書は、違いを具体化する。7月21日版のThreat Model for the Webと6月23日版のThreat Modeling GuideはいずれもW3C Group Note Draftである。状態欄はSecurity IGが支持する一方、W3C自体と会員は支持していないと説明する。Note Track上の作業中の文書であり、このNoteについてPatent Policy上のライセンス約束も生じない。

それでも価値は失われない。Noteは共通の分析方法を提供できる。プロトタイプは実現性を示せる。横断レビューは欠陥を見つけられる。ただし、いずれも所有するWorking Groupの規範的判断を代行しない。

すべてを「仕様」、維持担当者を「仕様編集者」とだけ呼べば、読者は助言、プロトタイプ、Group Note Draft、Recommendation TrackのWorking Draft、編集者の非公式作業版を別ページで判定しなければならない。一つの肩書が、承認、特許、標準化権限について相反する期待を背負う。

移管には受領側の決定が要る

案は正しい方向を示している。Recommendation Trackの機会は別のグループへ移す。しかし「引き渡す」という一文だけでは公開状態は変わらない。

Security IGは課題を特定し、脅威を説明し、受け手を提案できる。受け手は、憲章の範囲に入るか、先にインキュベーションが必要か、どの文書を所有するか、どの特許制度が適用されるか、編集者、実装者、テストが揃うかを判断する。沈黙は受諾ではない。リポジトリ間のリンクは採択ではない。同じ編集者が双方にいても制度上の権限は移らない。

横断レビューではこの区別が特に重要だ。W3Cのガイドは、横断グループが複数種のグループの提案、仕様、憲章を専門面からレビューすると説明する。Security IGは脅威や緩和策を問える。仕様を所有するグループが規範文をどう変えるか決め、レビューへの処分を記録する。

両者を結ぶ記録がなければ、採用されなかった助言は未受領に見える。移管後もプロトタイプが独自に進み、同じ機能名で異なる定義と異なる特許状態が並ぶ可能性もある。

草案段階だからこそ小さく直せる

Issue 568は公開中で、終了日は未定である。三つの修正で大半の曖昧さを除ける。

第一に、参加条項は成果物種別を明記する。編集者とテスト責任者がIGのGroup Note、質問票、脅威モデル、プロトタイプを維持するならそう書く。他グループの仕様を評価する実装者なら、編集権限ではなくレビュー証拠を提供する役割とする。

第二に、コミュニケーション条項はIGが作るドラフトと、IGがレビューするだけの仕様を分ける。W3CでWorking Draftは単なる一般名詞ではない。各ドラフトにTrackと所有グループが必要だ。

第三に、移管条項は受領記録を指すべきだ。元提案、受け手、日付、処分、現在の所有者を残す。受け手が拒否、延期、または範囲外と判断した場合、元のIG文書が無言で権限を広げるのではなく未解決状態を示す。

成果物・移管レシート

最低限の公開記録には次があればよい。

  • 安定した成果物IDと正確な版；
  • レビュー、質問票、Group Note Draft、プロトタイプ、インキュベーション報告、Recommendation Track文書の別；
  • 所有グループと根拠となる憲章条項；
  • 編集者、テスト責任者、実装者と各役割の範囲；
  • 承認、公開、特許の現在状態；
  • 対象仕様と安全上の論点；
  • 移管条件、予定受け手、日付；
  • 受諾、拒否、延期、インキュベーション要求；
  • 受諾後の文書IDと新所有者；
  • 訂正、置換、終了の履歴。

これは承認機関を増やす提案ではない。Heng LuのMinimum Initial Specificationは、共通層を必要最小限にし、後の変化は宣言ではなく実装と採用で現実になるべきだとする。ここでレシートが判断するのは安全提案の善し悪しではない。文書種別と役割が別のものを装うのを防ぐだけだ。

Security IGは、Recommendation TrackのWorking Groupと誤認されずに、強い助言、精密なNote、有用なプロトタイプを出せるべきだ。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