要約

  • W3Cはw3.org/2026/08/xmldsig-more#をXML Securityに割り当てたとするが、ページが示すのは番号付き版ではなく最新ドラフトへのリンクである。
  • -08はw3.org/tbd#を使用し、8月21日の-09で初めて新しい名前空間に置き換わった。W3Cページの更新日はその2日前である。
  • W3C自身の指針は、名前を定義・削除する方法とその決定者を変更方針に書くよう求める。現ページに方針はなく、沈黙から可変とも不変とも判断できない。
  • 名前空間変更憲章は、割当て時の版とハッシュ、凍結前の変更類型、互換性の扱い、凍結行為、W3C・IETF・IANAそれぞれの状態を結ぶべきだ。
  • これは無効な割当て、アルゴリズム承認、IETF採用、IANAの遅延、連携失敗を主張する記事ではない。問うのは公開された版管理と権限の接続である。

「最新」へのリンクでは過去の許可を復元できない

W3Cの名前空間ページは、このURIがXML Securityに割り当てられ、ある仕様に対応すると述べ、RFC 9231bisのDatatrackerページへ案内する。最終更新はSimone Onofriによる2026年8月19日と記されている。

ページが短いこと自体は問題ではない。議論中に永続URIを確保すれば、暫定名の衝突を避け、複数仕様で同じ識別子を検討し、実装試験を始められる。URIを早く割り当てることと、技術内容を承認することは分けられる。

しかし「latest」への案内は現在地しか示さない。割当てを決めた主体、公開の決定記録、対象版、ハッシュ、許可後に可能な編集、凍結条件はページにない。今日の読者は最新テキストを読めるが、19日の許可が何を含んでいたかは確認できない。

公開の協議は、形を変えながら前進した

W3C Strategy issue 484は2024年11月17日、XML SignatureとXML Encryptionの耐量子暗号を扱うワークショップ案として始まった。公開協議の実在を示す一方、Recommendation、チャーター、正式な移行判断ではない。

2024年11月21日、個人ドラフトの著者はRFC 9231bisにアルゴリズムを追加できると申し出た。2025年6月14日にはHSS/LMS、ML-DSA、SLH-DSA、ML-KEMが列挙され、ワークショップではなくissueで進める案が示された。どちらも有用な働きかけだが、個人の申し出やコメントが組織の合意になるわけではない。

2026年8月17日の更新は、-08に四つの対象群が入り、-09には追加要素が準備中だと説明した。名前空間ページの日付は19日である。著者は21日に-09公開を告知した。26日には、issueの目的がワークショップ開催から、XML SignatureとXML Encryptionの更新需要の追跡へと整理し直された。

これは協力が崩れた証拠ではない。作業が状況に応じて適応した証拠である。同時に、作業場所も文書も変わるからこそ、名前空間の許可には版を固定した記録が必要になる。

W3Cが実際に確認したファイルを外部から断定することはできない。内部記録がないとも断定できない。分かるのは、短い公開ページがその接続を示していないことだけだ。

著者の意図とIETFの現在状態は別の情報である

Datatrackerは、証拠締切時点の-09を有効な個人Internet-Draftとして示し、IESG状態をI-D Exists、RFC streamを未定、担当Area Directorをなしとしている。Internet-Draftの公開は通常の開かれた作業であり、IETFによる採用や承認ではない。

文書のヘッダーにはIndependent、Obsoletes: 9231 (if approved)、意図する状態としてStandards Track、失効日として2027年2月22日が記される。ヘッダーは著者の目標と条件付き効果を表す。Datatrackerは帰属可能な制度上の現在地を表す。両者を矛盾や誤記として扱う理由はない。

5月26日付の保存版-08は、新しい識別子にw3.org/tbd#を使っていた。SHA-256はcd9d7a31d66dabcb692b2bba3804102b5bba9e3376b999b0cb1404a20ff7f10fである。

8月21日付の-09は、それをw3.org/2026/08/xmldsig-more#へ置換し、2026年名前空間のschema付録を加え、さらに別の内容も変更した。SHA-256は09d36d24b05cbc0c1be1579d65fab88e6f9b6cfc13f214d55d4eeed42ad3866bである。

公開された改訂履歴は5月26日と8月21日のアップロードを確認できるが、Working Group採用、stream割当て、Area Director引受けは示さない。

従って証明できるのは、プレースホルダー版、19日のW3Cページ、21日の実URI版という順序である。割当て決定そのものの日付、確認された正確なバイト列、-09の全編集が許可に含まれるかは証明できない。

三つの制度は三つの行為を担う

承認済みの基準は今もRFC 9231である。同RFCは前世代の識別子を記録し、xmldsig-more URIがアルゴリズムのW3CまたはIETF公式ステータスを意味しないことを明示する。

IANA XML Security URIsレジストリはRFC 9231を参照し、Specification Requiredと指定専門家の制度で運用されている。後継ドラフトが未承認の段階でこの状態が続くのは正常であり、遅延ではない。

W3Cは自らのWeb空間にあるURIを管理する。IETFの文書プロセスは仕様を発展させ、採用・審査し、場合によってRFCとして承認する。IANAはレジストリ方針を適用する。ドラフト著者が文書を編集してもW3Cの名前空間方針を決める権限は得ない。W3CがURIを割り当ててもIETF文書を承認したことにはならない。IANAが将来識別子を登録しても、運用者への導入命令にはならない。

不足しているのは、三者を一つの承認主体にすることではない。別々の行為がいつ接続したかを示す引継ぎ表である。

W3Cの一般方針は、空欄にすべきでない項目を示している

W3Cの名前空間ガイドは日付形式を認め、@w3c/transitionsがw3c/nsのpull requestを通じて割当てと許可を行うと説明する。議論中の安定した識別子には価値があり、割当ては組織的な承認ではないとも明記する。

同じガイドは、管理する名前空間が将来どのように変わるか、または変わらないかを明確にし、名前空間文書から読めるようにすべきだとする。

W3C TAGのFindingはさらに具体的だ。不変でない名前空間なら、名前を定義または削除する方法と、その権限を持つ者を記述すべきである。明示的な記述がなければ、不変だと推定できない。

この原則は逆方向にも慎重に読むべきだ。ページに方針がないからといって、自由に変更可能とは推定できない。2026年世代の状態は、公開資料だけでは決められない。

W3C URI persistence policyは日付付き資源を永続性の対象としつつ、変更と過去状態の保存を想定する。アドレスの存続とローカル名集合の固定は別の統制である。

ここから割当て違反を導くことはできない。別の場所に適切な記録が存在する可能性がある。必要なのは、利用者が見る名前空間ページから方針へ到達できるようにすることだ。

過去の世代は凍結を明示的な転換として扱った

-09は2000年の接頭辞を“Frozen by W3C”とし、2001年、2007年、2021年の世代をそれぞれRFC 4051、RFC 6931、RFC 9231とともに凍結されたものとして記す。凍結は雰囲気ではなく、由来を持つ制度上の出来事である。

2026年世代では、RFC前に名前を追加できるか、誰が削除できるか、実装や文書ですでに引用された名前を予約するか、RFC承認が自動的な凍結か、W3Cの別判断が要るか、凍結後の追加には新しい日付が要るかが書かれていない。

外部の分析が答えを代行する必要はない。答えが既成実装によって事実上決まる前に、権限者が公表すればよい。

識別子は暗号方式の評価書ではない

XML Signature 1.1とXML Encryption 1.1は、XML構造で相互運用可能な識別子が必要な理由を示す。しかし将来そこに名を置かれる全アルゴリズムを承認するものではない。

RFC 8126はSpecification Requiredを、恒久的で公開された仕様と専門家審査を要する方針として説明する。これは登録の統制であり、安全性の包括的認証でも導入命令でもない。

本稿は各暗号方式を比較せず、安全・危険・完成・実装済み・普及済みとも判断しない。持続する語彙が更新中の文書に依存する限り、内容が暗号以外でも同じ管理問題が生じる。

必要なのは一ページの変更憲章である

最初にURI、日付形式の区分、割当て判断、判断主体、日付、公開pull requestまたはtransition記録を置く。割当て時に対象だった版とハッシュ、現在リンクされる版は別欄にする。

次に、追加、説明修正、改名、削除、非推奨化を分ける。それぞれについて提案者、決定者、既存参照や実装への互換措置を書く。

凍結イベント、決定者、時刻を明示する。凍結後の追加が同じ接頭辞、IANA専門家審査、erratum、後継RFC、新しい日付世代のどれを使うかも定める。

さらに、W3C側のページ管理者、IETF文書の種類・group・stream・採用状態・Area Director、IANAの登録状態・方針・専門家範囲を別々に表示する。識別子構文の根拠とアルゴリズム意味論の根拠も分け、訂正、差替え、失効、次回確認を記録する。

名前空間割当て、ドラフト公開、IETF採用またはstream割当て、RFC承認、IANA更新、プロトコルや運用者による導入という六つの行為は、一つのラベルにまとめてはならない。

非公開の審議や機微な実装報告まで公開する必要はない。版、権限、変更類型、転換時点が分かればよい。

問題は不正ではなく可読性である

公開issue、保存された全版、永続するW3C URI、現行RFCを正しく参照するIANA、暗黙の承認を否定するドラフトという構成要素は健全である。悪意、組織支配、無権限の登録、連携崩壊を示す事実はない。

構成要素が揃っているからこそ、修復は小さい。「latest」リンクは現在の発見に使い続け、版付きの変更記録を過去の許可と未来の境界に使えばよい。