要約

  • 2026年10月2日の Identity Verification Methods Values 02版は、ivm値が示す方法は成功したと説明する。同時に、このclaimは証拠も、方法がどう使われたかという詳細も提供しない。
  • 短い語彙は相互運用に役立つが、事業者の質、情報源の権威、手順の同等性、鮮度、保証レベル、法的十分性、後続の業務結果までは証明しない。

短いコードが危険になるのは、コードが間違っているときだけではない。正しい結果が、捨てた情報まで持っているように扱われるときにも権限の錯覚が生まれる。

draft-skyfire-oauth-id-verification-02 は、大小文字を区別する文字列のJSON配列ivmを提案する。初期値はデータベース照合、一つまたは複数の情報源、デジタル・物理・補助文書、対面、ライブ動画を表す。

02版の重要な追加は範囲の宣言だ。値があることは、その方法が成功したことを示す。しかし証拠や実施方法の詳細は含まない。必要ならOpenID Identity AssuranceやVectors of Trustを併用できる。

これは語彙の弱点ではなく役割である。共通名はログ検索、ルール、連携を容易にする。問題は、受信側が短縮後のラベルから、発行者が送っていない保証を復元したつもりになることだ。

dbv1とdbvmは一つと複数の消費者報告データ源を区別する。しかし情報源の名称、独立性、記録日、照合属性、矛盾処理、閾値は分からない。数は権威や多様性の証明ではない。

phyも、文書種別、版、発行地域、撮影装置、真正性確認、生体照合を示さない。digは信頼フレームワークを運ばない。vidはliveness、担当者、手順、例外を説明しない。inpは場所や監督設備を特定しない。

「成功」は発行者の手続と閾値に属する。JWT署名は、誰が主張したかと改変されていないことを確認できるが、主張にない事実や現実の本人性を追加しない。

提案されたIANA登録も名称を管理する制度である。Expert Review、三週間の審査、重複、一般性、実利用、明確さという基準は名前空間を改善するが、事業者認定や普遍的な保証点数ではない。現行IANAレジストリへ載るまでは提案である。

凍結したDatatracker情報にはstreamも標準レベルもない。OAuthの議論文脈にあっても、個人提出はWG採択、IETF合意、RFCにはならない。

RFC 8176のamrは、特定方法へ直接結び付いた判断が、攻撃や実装の変化で脆くなると警告する。方法名は何を使ったかを伝える。受け入れ可能な政策クラスは別の文脈で表すべきだ。

OpenID Identity Assuranceは、信頼フレームワーク、保証レベルと過程、検証時刻、案件参照、証拠、個別チェックを分ける。RFC 8485も値を特定の信頼フレームワーク内で解釈するよう求める。NIST SP 800-63A-4はidentity resolution、証拠強度、validation、verificationを別工程にする。

したがってivmの横に別receiptを残す。語彙版、発行者とフレームワーク、主体・取引binding、方法、事業者とpolicy、変更不能な証拠参照、情報源と地域、各チェック、livenessや人手審査、時刻、保証分類、例外、ローカル判断、最終結果である。これはBTWの運用提案で、草案要件ではない。

Heng Luの最小初期仕様は共有語彙を小さく保ち、結果責任をローカルに残す。Running-Code Primacyは実行されたチェックを見る。Reality Layersは登録語、主張、証拠、判断、結果を一つにしない。

ラベルは方法を名付ける。証拠は案件を示す。結果を受け入れる責任は依存側に残る。

情報源