要約

  • draft-zehavi-oauth-authz-req-del-chain-01は2026年9月10日に告知された個人Internet-Draftであり、OAuthワーキンググループの採択文書でもRFCでもない。
  • 分離JWS、前ノードのハッシュ、連番、audienceの連続性は、上流の認可サーバーに見える仲介経路の改変を検出するための仕組みだ。
  • 末尾や中間を削れば検証に痕跡が残る。しかしブローカーは自分をchain[0]にして、新しい有効なチェーンを作ることができる。
  • その再起点化を認めるかは、クライアント、資源、配備状況ごとのローカル方針が決める。

連番ゼロは歴史のゼロではない

受信側が目にするチェーンは美しく整っている。最後のノードは受信する認可サーバーを宛先にし、署名鍵も見つかる。p_hashは一つ前の署名済みイベントに一致し、番号も途切れない。隣り合う発行者とaudienceの関係にも矛盾がない。

それでも、最初のノードが現実の最初とは限らない。

OAuth Authorization Request Delegation Chain 第01版が扱うのは、下流クライアントからのリダイレクト認可要求が複数のブローカーを経て、同意とトークン発行を担う上流サーバーへ届く構成だ。各仲介者は下流に対して認可サーバー、上流に対してOAuthクライアントとして振る舞う。終端サーバーが直接知る相手は、直前のブローカーだけかもしれない。

提案されたRARのauthorization_detailsには、順序付きのJSONノードが入る。各ノードは証言者、宛先、位置、証言対象のクライアントを示し、決定的に組み立てた内容へ分離JWSを付ける。p_hashは直前の署名イベントを結ぶ。

検証は末尾から先頭へ戻る。最後のaudが受信サーバーを指すか、そのissが実際に認証された直前クライアントと結び付くかを確かめる。その後、署名、鍵、番号、名前空間、ハッシュ、隣接するaudienceと発行者の連続性を検査する。

ここで保証されるのは、あくまで「見えている」チェーンの構造である。

消した位置によって証拠が変わる

第01版は切り詰めを三つに分ける。末尾を落とせば、最終ノードの宛先が受信サーバーと合わない。中間ノードを抜けば、後続ノードのp_hashと隣接関係が壊れる。どちらもチェーン内部の検査で見つけられる。

先頭の削除は別だ。ブローカーは以前の文脈を捨て、自分を番号ゼロ、前ハッシュをnullとする新しいチェーンを作れる。それ以後の署名とリンクはすべて正しくなり得る。草案はこれをre-originationと呼び、暗号検証ではchain[0]より前に何もなかったとは証明できないと明記した。

これは報告された侵害ではない。提案自身が示す証明範囲だ。ハッシュチェーンは宣言された始点からの一貫性を守れるが、その宣言より前の歴史を証言する外部主体にはならない。

そこで認可サーバーは、最初に見える発行者が、そのクライアント、資源、配備文脈で始点になってよいかをローカル方針で判断する。署名が有効でも、発行者に委任仲介の権限があるとは限らない。新設のclient_rolesでoauth_brokerを示せても、自己申告だけを信頼や権限の証明にしてはならない。

後段の省略許可は始点証明ではない

第01版は上流サーバーの対応能力をRFC 8414のメタデータから発見する処理も追加した。次のサーバーがこのチェーン形式を扱えない場合、既存チェーンを黙って捨てることは禁じられる。

ブローカーは取引を拒否するか、別の信頼できる仕組みで文脈を保つか、署名済みチェーンとローカル方針の双方が許す場合だけチェーンなしで転送する。任意のomit_chainはallowedまたはforbiddenで、未記載時は後者になる。すべての検証済みノードが許可しなければ省略できない。

これは目の前の証拠を後段で失う判断を明示する優れた区別だ。しかし、新しいchain[0]を作る前に何が捨てられたかは説明しない。後段のダウングレードと始点の完全性は別の統制である。

この版はclient_rolesのIANA登録も提案する。現段階では個人草案の要求であり、登録完了、標準化、実装、導入、攻撃の証拠ではない。

情報源