W3CのDID再憲章には標準状態の引継票が要る

要約

2024年の現行チャーターはDID ResolutionをRecommendation Trackの成果物として採用し、2026年10月28日まで延長されている。8月の作業には有効な権限の出所がある。
8月6日のCandidate Recommendation SnapshotはPatent Review Draftであり、10月5日までの除外機会を開始した。機能ごとの実装条件を示すが、W3C RecommendationでもW3Cの承認でもない。
W3C Teamは8月10日に継続的な再憲章のrefinementを開始した。しかし8月27日にマージされたリポジトリheadを含む草案は、DID ResolutionをWorking Draft、最新刊を7月10日、Exclusion Draftを2024年の版としている。
公式履歴には8月28日のCandidate Recommendation Draftが加わった。これは最新の統合テキストだが、日付が新しいだけで8月6日Snapshotの特許参照機能を引き継ぐわけではない。
Advisory Committee reviewの前に、現行チャーター、最新CR Draft、基準Snapshot、除外期間、at-risk機能、日付付き実装証拠を結ぶ状態票が必要だ。新しい承認段階ではなく、既存の境界を保存する記録である。

「現在」は一つの欄では足りない

DID Resolutionの現在地を一語で答えようとすると、少なくとも四つの答えが衝突する。

技術文書として最も新しいのは8月28日のCandidate Recommendation Draftである。W3Cの出版履歴は、8月6日のSnapshotの後にこのDraftを置いている。

特許手続の基準は8月6日のCandidate Recommendation Snapshotである。この公開がPatent Review DraftとしてCall for Exclusionsを開始し、期限を10月5日に設定した。

実装証拠の公開画面は、テスト実行を3月27日14時16分UTCと表示する。実装者の列と詳細な結果はあるが、この時刻は8月の出版日ではない。

グループの制度上の権限は2024年チャーターに由来する。期間は10月28日まで延長済みで、次のチャーターはまだ草案である。

四つの画面は、それぞれ別の問いに正しく答えている。誤りは、それらを「最新状態」という一欄に押し込むときに生じる。最新の文章と、特許比較の本文と、最新のテストと、現在の権限は同じ対象を指しても同じ属性ではない。

共通記録の役割は、一つを王座に据えることではない。四つの時計の対応表を残すことだ。

現行チャーターが8月の作業を支えている

2024年4月のチャーターは、DID Resolutionを新しいRecommendation-track deliverableとして正式に取り込んだ。当初の終了は2026年4月だったが、W3Cは10月28日まで延長した。グループページも現在その期限を表示している。

したがって、Candidate Recommendationへの移行が無権限で行われたという話ではない。将来のチャーターが過去を遡って正当化する必要もない。逆に、公開草案がGitHubにあるというだけで、現行チャーターを置き換えたと考えることもできない。

Strategy issue 562は、提案の性格を簡潔に説明している。既存Working Groupのrecharterであり、実質的変更はなく、DID Resolutionのコンセンサス形成に想定以上の時間がかかったため、時間が必要だという。

この「同じ仕事を続ける」という説明こそ、精密な引継ぎを必要とする。範囲を変えるなら差分が目立つ。範囲を変えない場合は、成果物の名前だけが渡り、どのSnapshotが特許基準か、どの機能が未確定か、どのテストがどのテキストを対象としたかが忘れられやすい。

提案チャーターはまだ権限ではない。その境界を守ったうえで、権限になり得る日までに受け取る状態を明確にする必要がある。

Snapshotは写真、Draftは作業台

比喩を使うなら、8月6日のSnapshotは制度上の写真であり、8月28日のDraftは更新中の作業台である。写真の後も作業は続くが、作業台の現在像が自動的に過去の写真の役割を奪うわけではない。

W3C Processでは、Candidate Recommendation SnapshotはPatent Review Draftに相当する。安定した参照点を公開し、除外機会を発生させる。DID Working GroupのIPRページは、開始日を8月6日、期限を10月5日としている。

Candidate Recommendation Draftは、前のCandidate Recommendationからの変更を統合し、Working Groupが後のSnapshotに含めようとする内容を見せる。文書自身がwork in progressであり、更新・置換・廃止され得ると告げる。CR Draftはそれ自体では新しい除外機会を提供しない。

したがって状態票は、「最新」を二つに分けるべきだ。

最新の統合作業文書：8月28日CR Draft
現在のPatent Review Draft：8月6日CR Snapshot
現行の除外機会：8月6日から10月5日
次の安定参照：新しいSnapshotが実際に公開された場合のみ記録

この区別がなければ、技術者は最新の変更を見失うか、特許担当者は誤った本文を比較するかのどちらかになる。両方を残せばよい。

IPRの専用記録はすでに追いついている

草案チャーターのDID Resolution欄は、2024年11月28日のWorking DraftをExclusion Draftとし、2025年4月27日に終わった期間を記載する。この欄だけを読めば、2026年8月の状態から遅れている。

しかしW3CのIPRページは遅れていない。現在の機会として8月6日から10月5日までを掲げ、2024—2025年の機会を過去の履歴として保存する。Call for Exclusionsは、新しい機会の対象が、前の参照本文に存在せず、または明らかでなかった事項に限られると説明している。

ここから「手続がなかった」とは言えない。むしろ専門画面が正しく働いているから、草案の接続不足を限定して指摘できる。

除外期間が開いていることを特許紛争の兆候と読むのも誤りである。IPRページはグループ仕様について既知の特許開示がないと報告する。機会は手続上の状態であり、請求項の存在や将来の除外を予告するものではない。

引継票にはSnapshot、前の参照本文、開始日、期限、IPRページだけを置けばよい。個別の特許判断をチャーターに持ち込む必要はない。

実装者が四者いても、全機能に二つの証拠があるとは限らない

Snapshotの終了条件は企業数を数える方式ではない。仕様の各機能について、少なくとも二つの独立した相互運用実装が必要で、公開テストスイートによって検証される。機械試験可能な規範文は機能ごとに二つの適合実装、機械試験できないものは二つの実装デモを求める。さらに、少なくとも二つの公開仕様DID methodを、複数の独立実装が相互運用的に扱う必要がある。

公開レポートには複数の実装者が並ぶ。だが列見出しは合格証ではない。ある機能は二者が通り、別の機能は一者だけ、さらに別の項目は未実装ということがあり得る。判断単位はロゴや社名ではなく、機能と規範文である。

3月27日という表示も、断定ではなく照合を要求する。3月に試した機能が8月まで変わっていなければ結果は有効かもしれない。逆に、表中のfailやnot implementedを一つ拾っても、最終的な終了条件の不成立は証明できない。仕様版、テスト版、機能区分、独立性をそろえて初めて判断できる。

実装状態票には、被試験仕様、test-suite commit、実行時刻、機能を構成する規範文、二つの証拠、独立性の根拠、利用したDID method、未解決項目、更新責任者を含めるべきだ。

この順序なら、制度の成熟ラベルをrunning codeが規律する。チャーターは実装証拠を要求できるが、文章だけで実装済みという現実を作ることはできない。

at riskは、失敗ではなく未決事項の住所である

8月6日SnapshotはDID URL dereferencingをfeature at riskとし、変更または削除される可能性が高いと述べる。Working Groupは、定義された機能に価値があるかを実装者に尋ねている。class 1、2、3のopen issueが仕様を変え得るという注意もある。

Candidate Recommendationは実装経験を集める段階なのだから、これは正常な管理である。at riskという印は「完成していないのに完成したふりをしない」という境界だ。

再憲章で失ってはならないのは、その未決事項の住所である。「DID Resolutionをmaintainする」という一文だけでは、何を維持し、何を再検討し、何が削除可能だったかが分からない。

状態票は、機能ID、issue、必要な証拠、決定主体、後の処置を結べばよい。残す、変える、削るという技術判断そのものはWorking Groupに残る。

草案を草案として扱うからこそ、今直す

公開チャーターはDRAFTであり、開始日と終了日は未記入である。開始日は承認後のCall for Participationに依存するため、これだけで手続違反とは言えない。W3Cはrefinementを9月15日ごろまでと見積もった。

Process上、この期間はwide review、issueの正式処理、AC Reviewへ進むか延長するかを決めるためにある。したがって古い欄を見つけて「チャーターは無効だ」と結論づければ、refinementの存在を無視することになる。

一方、草案自身はDraft stateをチャーター承認時の成果物状態だと定義し、動的な情報には出版状況ページを案内する。毎日の同期を約束してはいないが、承認時の正確さは約束している。

調査時点のheadは8月27日にマージされた後もWorking Draft、7月10日、2024年Exclusion Draftを保持していた。その時点で8月6日Snapshotはすでに存在し、翌28日にはCR Draftも出た。

これはrefinementで直せる差である。差を罪にする必要はない。差を消さずに承認へ送る理由もない。

引継票は薄くてよい

W3Cには出版、IPR、グループ、テストの専門ページがある。新チャーターを第二のデータベースにする必要はない。共通層は次の六点に絞れる。

権限：現行チャーター、期間、後継草案commit、refinement状態、後の採用決定。
本文：最新の統合文書と基準Snapshotを別々に記録。
特許：Patent Review Draft、開始・終了、前参照、IPRリンク。
実装：試験対象、suite、実行、機能別の証拠、独立性。
レビュー：at-risk、issue、horizontal review、wide review、コメント処理。
保管：各表示の責任者、訂正方法、状態を置き換えるイベント。

過去を上書きせず、遷移を追加する。人が読む小さな表と機械可読記録は同じIDを使える。

関連分野としてidentity and access managementへ案内する場合も、権限を広げてはならない。草案は認証・認可プロトコル、ブラウザーAPI、Web上の「Identityを解決する」ことを対象外とする。DID Resolutionがidentity分野に重要でも、W3Cが全IAM製品、全DID method、法的身分制度を承認するわけではない。

薄い記録は、正確さと抑制を同時に実現する。

W3CのDID再憲章には、引き継ぐ標準の状態票が要る

なぜ重要か

要約

「現在」は一つの欄では足りない

現行チャーターが8月の作業を支えている

Snapshotは写真、Draftは作業台

IPRの専用記録はすでに追いついている

実装者が四者いても、全機能に二つの証拠があるとは限らない

at riskは、失敗ではなく未決事項の住所である

草案を草案として扱うからこそ、今直す

引継票は薄くてよい

情報源

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説