Summary

  • 個人提出のInternet-Draftである改訂01は、証拠のidと、表示内容・利用者の操作・時刻を含むuser_confirmationだけをas_signatureの入力にする。
  • 意図を認可済み操作へどう展開したかを説明するaudit_trailは明示的に除外される。ローカル再現では異なる展開記録が同じ署名入力になった。
  • 署名付きJWTを完全なまま検証すれば外側の署名が全体を守る。不透明トークンから抽出した場合、TLSは取得経路を守るが、監査記録の独立署名にはならない。

抽出後に残る証明

draft-liu-oauth-authorization-evidence-01は、代理的な処理における同意の記録を具体化する。中核には証拠識別子、user_confirmation、分離JWSであるas_signatureがある。確認には利用者に正確に表示した文、確認方法、NumericDate形式の時刻が入る。

第3.6節の手順は限定的で明快だ。idとuser_confirmationだけを持つ新しいJSONオブジェクトを作り、RFC 8785のJCSで正規化し、そのバイト列に署名する。id、user_confirmation、as_signature以外の拡張フィールドは含めてはならない。監査記録が外にあるのは実装上の偶然ではない。

この署名は、認可サーバーが当該確認記録を署名したことを示す。ただし草案は、利用者が実際に同意したことの独立証明ではないとも述べる。認可サーバーは画面と鍵を支配する。より強い否認防止には利用者側署名か独立監査が要る。

さらに、確認は実行結果ではない。リソースサーバーは証拠ID、確認時刻、表示内容の要約と、実行した操作、その成否を別々に記録する。署名が有効でも、要求が拒否されたり、実行が失敗したり、外部効果が生じなかったりし得る。

意味を説明するフィールドが署名の隣にある

第4節はaudit_trailを、利用者の意図がどう解釈され認可済み操作へ翻訳されたかを分析するための意味的追跡情報とする。任意項目にはevidence_ref、展開レベル、proposal_refがある。

展開レベルはnoneからhighまでだが、機械で再実行できる差分ではない。mediumというラベルだけでは、「安い」が50ドルを意味した理由、選択した商品分類、参照したポリシー版は分からない。

proposal_refは、ポリシー評価、スコープ縮小、同意変更より前の提案を指す認可サーバー割当ての不透明URIである。改訂01は取得手順、内容ハッシュ、保存期間、アクセス条件を定めない。参照文字列を保持していても、後日の監査者が同一内容を取得できるとは限らない。

これは攻撃の主張ではない。導入側は不変ストア、より広い署名包、署名付き応答を追加できる。ここで見えているのは、その性質が草案自身の可搬契約にはまだ入っていないという境界である。

異なる履歴でも署名投影は同じだった

ローカル再現では、同じid、表示文、操作、時刻を持つ二つの完全オブジェクトを作った。一方はmediumと50ドル側の提案参照、もう一方はhighと500ドル側の参照を持つ。完全な正規化オブジェクトとハッシュは異なったが、第3.6節の投影は一致し、SHA-256は両方ともaec26fa5351ab57f144fd6b387b297969f73e34ec3ea5a557592a0b2d3a7b512だった。

この再現は署名入力の範囲だけを確認する。省略されたJWSの検証、暗号破り、製品の欠陥、悪意あるサーバー、実取引、損失を示すものではない。

JWTと不透明トークンでは保存すべき単位が違う

RFC 9068の署名付きJWTアクセストークンに証拠が埋め込まれている場合、外側の署名は監査記録を含むトークン全体を守る。完全なJWTを保持し検証する限り、その内部で監査記録を変更すれば外側の署名が壊れる。内側の署名範囲だけを見て、JWT全体に保護がないと結論してはならない。

不透明トークンでは、RFC 7662のイントロスペクションまたは専用エンドポイントから証拠を取得する。草案はこの場合のas_signatureを証拠記録の唯一の完全性保護と呼び、TLSを要求する。TLSは取得時の相手と通信を保護する。しかし抽出、保存、転送された後、TLSセッションは監査記録を第三者が検証できる署名へ変えない。

イントロスペクションのactiveは認可サーバー依存で、応答はリソースサーバーごとに変わり得る。キャッシュには鮮度との交換もある。現在の認可状態を返す仕組みが、そのまま長期的な解釈証明になるわけではない。

「なぜ」と「何を」は別の権限面である

Regoポリシーの関連草案は、証拠が操作を認可した理由を、rego_policyが代理に許されることと実行時評価を表す、と分ける。完全例では両者が兄弟オブジェクトだ。確認の内側署名は、ポリシーURI、エントリーポイント、評価入力を結び付けない。

完全な外側JWTは組合せを守れる。不透明トークンの系では、取得と保存を別途設計する必要がある。表示、確認、意味展開、ポリシー、リソース判断、ディスパッチ、実行、外部結果を一つの「認可済み」に畳むと、後段の部品が説明なしに権限を拡張する。

解釈パスポートで経路を再現する

高影響の操作では、証拠と確認セッション、表示内容のハッシュと言語、元提案または不変ハッシュ、解決済み操作と制約、意味差分と生成部品、ポリシー識別子・ハッシュ・入口・入力、発行者・対象・主体・代理・クライアント、リソース判断、実際の要求ハッシュ、実行受領、独立観測した結果を結ぶ解釈パスポートが必要になる。

これはDaniel Kadeの分析上の提案であり、改訂01の要件ではない。機密内容はアクセス制御された保管先に置き、ハッシュで結べばよい。最小仕様の目的は全情報の集中ではなく、権限を持つ検証者が判断経路を再現するための不変点を残すことにある。

Sources and limits

観察は2026年9月30日、Asia/Shanghaiで固定した。改訂01は有効な個人Internet-Draftであり、RFC、OAuth作業部会の合意、採用実績ではない。ローカル再現は規定された投影だけを示し、JWS/JCSの破綻、TLS中の改変、実装不具合、悪意、実損、操作完了を示さない。文書は変更、置換、失効し得る。