要約

  • Wes Jacksonの個人Internet-Draft第02版は、検証器が理解できないauthorization_detailsの項目を黙って捨て、残りだけを認めることを避け、提示されたトークン全体を拒否するよう提案する。
  • 呼び出し側には同一トークンの再送が成功しないと分かる程度の結果を示す一方、失敗した項目や委任経路、上位の権限状態は知らせない。正確な理由は検証側の監査記録に残す、という区別だ。

トークンの拒否理由は、親切に書けばよいとは限らない。例えば外部のエージェントが委任の連鎖を示し、受け手の検証器がその一部を評価できなかったとする。相手に「上位の許可が失効した」と返せば、相手が別の方法では知り得ない権限の状態を教えることになる。反対に一時的な障害と区別できない応答だけを返せば、相手は同じトークンを何度も送るかもしれない。どちらも拒否そのものは正しいのに、応答の設計が別の問題を生む。

この二面性を明確にしたのが、2026年9月29日付のVerifier-Side Evaluation Semantics for Delegated Authority Chains第02版だ。IETF Datatrackerでは、Wes Jacksonによる個人提出のInternet-Draftで、状態はI-D Exists。標準化ストリームは設定されていない。WIMSE作業部会に採用された文書でもRFCでもなく、実装済みのサービスに義務を課すものでもない。文中の「MUST」や「SHOULD」は、この著者が提案する仕様の言葉として扱う必要がある。

第01版との比較では、単なる語句の変更に見える箇所に意味がある。最初の規則は旧版の「Process Every Entry or Reject」から新版の「Process Every Entry or Refuse」へ変わった。新版は検証器がトークンや記録を拒むことと、承認者が保留中の呼び出しを最終的に却下することを分離する。前者は提示された権限を検証できるかという問題、後者は人が行為を認めるかという問題だ。両方を一つの「拒否」に丸めると、判断主体と回復の余地が曖昧になる。

第4.1節で著者は、提示されたauthorization_detailsをすべて処理できなければトークンを拒むべきだとする。未知の型だけを捨てて成功を返すと、検証していない権限まで検証済みのように見える。新版はさらに、この場合の拒否を提示済みの同じトークンについて恒久的だと説明する。再送しても検証器が未知の型を突然理解するわけではない。この限定を外し、将来の別のトークンまで一律に拒まれると読むのは誤りだ。

では呼び出し側に何を知らせるか。第5節は、同一トークンの無益な再試行を止められる程度に、拒否の性質を判別可能にすることを勧める。その一方で、検証器が既に公開している対応型などを超えて、どの項目、どの委任経路、どのgrantが失敗したかを漏らしてはならないとする。細かな応答を繰り返し照会できれば、外部の相手は委任グラフを逆算できる。詳細は検証器の運用者が読める監査記録に置く。対外応答を粗く、内部診断を細かくするという運用上の整理はDaniel Kadeの分析であり、草案が新しい二層のメッセージ書式を定めたわけではない。

既存のOAuthの例も使い分けが必要だ。RFC 9396のinvalid_authorization_detailsは、未知または不正な認可詳細を扱う認可サーバー側の文脈で、認可エンドポイントとトークンエンドポイントに登録されている。RFC 6750のinvalid_tokenはbearer tokenを受けるリソースサーバー側の文脈であり、クライアントが新しいアクセストークンを取り直して再試行することを認める。Jacksonの草案は両者を例示するが、新しいエラーコードも共通応答形式も作らない。実際のプロトコル上で何を安全に伝えられるかは未確定だ。

この文書から、現に委任経路の漏えい事件が起きたとか、再試行による負荷が測定されたとは言えない。草案自身、参照実装はauthorization_details項目を処理していないと断っている。重要なのは、正しく拒否するだけでは制御が終わらないと示した点だ。返答の情報量も、信頼境界をまたぐ設計事項なのである。

出典