要約

  • 2026年9月28日付の個人Internet-Draft draft-schrock-ep-authorization-evidence-chain-07 は、前版で一つだった結果を VERIFIED と ACCEPTED に分けた。IETFが採用・承認した標準ではない。
  • 鍵の参照先が解決できなければ検証は NOT_EVALUATED であり、署名が失敗したとはいえない。鍵を特定できても、その用途で信頼するかは別に決める。
  • 証拠が要求を SATISFIED しても、保護された操作を AUTHORIZED するのは実行側の判断で、結果が生じたことまで示さない。

同じ署名付き資料を持ったエージェントが、二つの事業者に設定変更を求めたとする。資料の内容は同じで、両者が暗号学的な検査に成功する場合もある。それでも、一方は署名者をこの種類の変更に適した発行者として登録し、もう一方は登録していないかもしれない。「有効な署名」という一行だけを保存すれば、後者が拒んだ理由は見えなくなる。逆に一方の採用判断を他方へ持ち込めば、他組織の信頼設定を知らぬ間に借用することになる。

Ian Schrockによる Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence の改訂版は、まさにその境界を書き直した。公式アーカイブにある -07 の日付は9月28日。作者がInformationalを意図した個人提出のInternet-Draftであり、作業部会への採択、RFC化、実装や運用の報告を意味しない。異種の証拠を組み合わせる着想自体は -06 にあった。改訂履歴が明記する新しい点は、前版の VERIFIED が暗号・構造の確認と依拠する側の信頼条件を混ぜていたため、後者を ACCEPTED として切り出したことだ。

原生の検証器は、証拠の形式に従い暗号学的整合性と構造を調べ、初めて VERIFIED を報告する。受け入れの判定はその後で、当該組織があらかじめ定めた鍵の所在と登録状態、認める発行者や鍵の種類、役割・対象、形式の版、検証時点などに照らす。証拠を差し出した側が「信頼済み」という印を付けても、運用者の設定にはならない。ある鍵参照が解決できない場合、数学的な検査そのものを実施できず NOT_EVALUATED と記録する。これは検査して失敗した FAILED とは異なる。鍵が見つかっても、その鍵がこの役割で採用されるとは決まらない。

鍵参照の扱いによっては、まったく同じバイト列でも、参照先を別の鍵に結び付ける二組織の VERIFIED 判定が違い得る。したがって「この証拠はどこでも検証済み」とだけ語るのも危うい。草案は、提示者が送ってきた真偽値、正規化済みの事実、鍵や信頼アンカーを原生検証の代わりにすることを禁じる。同一の保護された境界内で先行検査を流用するなら、結果を正確な証拠のダイジェスト、検証器のプロファイル、信頼状態のスナップショット、検査時刻に結び付けなければならない。外部から届く「検証済み」の記録は、それ自体が確認すべき新たな資料である。

さらに、VERIFIED と ACCEPTED を通った証拠だけが、実行者の用意した具体的行為との照合へ進む。信頼できる発行者の真正な資料でも、別の操作を記したものなら MATCH ではない。その不一致を署名の失敗や発行者の不採用と混同すべきではない。鮮度、認証された状態、各資料の役割、資料同士の正確な結び付きまで評価した上で、依拠する側が指定した証拠要件が満たされたかを SATISFIED で表す。この語はアプリケーションが操作を許可したという AUTHORIZED ではない。呼び出しが行われ、狙った結果が出たかも、さらに別の記録が要る。

-07 の再現用記録には評価アルゴリズムの版、対象行為や要件のダイジェスト、検証時刻、信頼状態のダイジェスト、資料ごとの native_verification と acceptance、照合結果と理由が残る。理由は暗号検査の失敗、検査不能、信頼上の拒否、行為の不一致を区別するよう求められる。これは議論の焦点を「緑の表示が出たか」から「どの入力と規則で、どの段階まで進んだか」に移す。提案された評価出力は万能の許可証ではない。草案にIANAの登録作業もない。

出典