要約

  • W3CのVerifiable Credentials作業部会は9月24日、データモデルv2.1の脅威を詳述する独立したGroup Noteの初稿を公開した。9月20日のデータモデル草案には既に概要が載っていた。
  • 25件は仕様の対象、実装、導入運用、外部要因、依存技術の五つに分けられる。分類は危険度の順位でも、対策の完了証明でもない。
  • 本人確認の失敗や危険な表示、目的外の採用は、暗号学的検証が成功しても残り得る。Noteは未承認の草案であり、勧告ではない。

資格情報を受け取る側の画面には、署名の検証成功が大きく表示されるかもしれない。しかし、その前に発行機関が別人を本人だと取り違えていたらどうなるか。発行された文書は本物で、失効もしていない。後段の検証は正しく動いているのに、当初の人物同定だけが誤っている。W3Cの新しい脅威分析でT25と呼ばれる事態である。発行者がどの程度の本人確認を行うかはデータモデルだけでは強制できず、検証者も利用目的に照らして保証水準を評価しなければならない。

24日に出た独立文書の役割を、発見の独占と混同してはならない。20日付の Verifiable Credentials Data Model v2.1 Working Draftは、非規範的な付録Aで同じ脅威群を短く紹介していた。新たなGroup Note Draftは、それぞれの経路、対応策、影響を受ける構成要素を掘り下げた。ニュースはリスクの初登場ではなく、役割をまたぐ管理点が読み取りやすくなったことにある。

対象となる脅威が二件、実装上の脅威が七件、導入・運用が十一件、外部が四件、依存技術が一件。合計二十五件という構成は、どの層を調べるべきか示すが、実害の件数や確率を表すものではない。「仕様が対象にする」ことも「仕様だけで解消する」ことではない。先のT25は対象側に置かれながら、詳細では本人確認の厳格さは発行者の選択だと明記される。文書の辞書項目も、今後見直す出発点と記されている。

別の境界がT1にある。保護された主張を書き換えれば、適切に証明を調べる検証者は改変を発見できる。一方、証明そのものが取り去られると、暗号で確かめる対象がなくなる。発行者の真正な主張を要する場面では、検証者の受入方針が必要な証明を要求しなければならない。証明のない資格情報にも自己申告や中間処理としての用途は認められるが、それを発行者が認証した内容として扱うのは別の話だ。

実装側では、T2が表示処理に注意を向ける。署名で完全性が守られた内容に実行可能なマークアップが含まれていても、財布アプリや検証サービスにとって安全な入力になるわけではない。表示時の隔離や適切な符号化はソフトウェア側の仕事である。利用判断ではT24がさらに問う。真正で失効していない資格情報であっても、その出所と主張の性質が、目の前の目的に適しているとは限らない。最終的に採用する側の方針が必要になる。

実務では、関連する脅威ごとに責任者、判断する時点、選んだ対策と稼働の証拠を結び付ける記録が考えられる。これはDaniel Kadeによる運用上の提案であって、W3Cが要求する書式ではない。Noteには失効状態の照会から生じるプライバシー問題もあるが、本稿の焦点は別のBitstring Status List v1.1における短い参照やstatusPurposeの選択ではない。発行から受入れまでの責任の所在である。

文書の段階も分けて読む必要がある。データモデルv2.0は2025年5月にW3C Recommendationとなったが、2026年のv2.1はWorking Draftで、今回の脅威モデルは未承認のGroup Note Draftだ。特定の製品が安全だと認定した資料でも、実際の事故を報告した資料でもない。署名の成功から責任までを一足飛びに結ばないための、公開された検討図なのである。

出典