要約

  • draft-li-oauth-delegated-authorization-03 は、認可サーバーがルートを発行し、クライアントが別のクライアントへ、より狭い子トークンを署名できるチェーンを提案する。Standards Track を意図する個人 Internet-Draft であり、RFC、合意、実装実績ではない。
  • 子の署名が証明するのは、直前の親が束縛した鍵による次の委任である。それだけでは信頼されたルート、累積権限の包含、委任への同意、現在の資源認可を証明しない。
  • 葉クライアントは正確な順序の全チェーンと DPoP 証明を提示する。資源サーバーは全祖先、隣接鍵、意味的縮小、失効状態、ローカルポリシーを確認してから効果を許す。

トークン台帳を末端から読むと、最も重要な事実が消える。葉の JWT は正しく署名され、有効期限内で、DPoP 鍵も保持されている。それでも、親がその権限を持っていなかったなら、葉に行使権はない。

draft-li-oauth-delegated-authorization-03 は、この依存関係を順序付きチェーンにする。認可サーバーはルート Delegated Authorization Token を署名し、cnf.jkt で Client A の鍵に結び付ける。残りの深さが許せば A は B の鍵に結び付けた子を作る。B がさらに委任できるのは、ルートから届いた有効範囲の内側だけである。

認可サーバーが子の発行ごとにオンラインでなくてもよい点は、エージェントや分散サービスに有用だ。しかし不在が新しい権威を生むのではない。ルートが限定的な再委任能力を先に与え、各段階はそれを減らす。要求時に資源サーバーが全経路を再計算することで成立する。

03 版は 2026 年 7 月 24 日付、2027 年 1 月 25 日失効予定である。本文は Standards Track を掲げる一方、Datatracker API の stream と intended level は未設定だ。提案された登録値も現行の IANA 配置を意味しない。本稿は標準化、採用、相互運用、製品挙動を推定しない。

子の公開鍵は子自身を信頼させない

ルート署名鍵は、信頼済み設定または認証済みメタデータから得る。トークンが iss と任意の鍵を同時に示しただけでは、信頼の根にならない。最初の判断はチェーン外にある。

クライアント発行の子は、署名者の公開 JWK を保護ヘッダーに置く。検証者は RFC 7638 thumbprint を計算し、親の cnf.jkt と一致させ、その鍵で子署名を検証する。これにより「親が認めた鍵の保持者が、この子を署名した」ことが分かる。

その鍵が予定した組織、テナント、プロセスに属したことは分からない。A が B の公開鍵をどこから得て、どう B と対応付けたかは仕様外である。設定やエージェント runtime が別テナントの鍵を渡しても、その後の暗号は正しくなり得る。

したがって、鍵連続性の受領証と委任先関連付けの受領証を分ける。前者は thumbprint、署名、位置を記録する。後者は workload、tenant、運用者、交換チャネルを記録する。「verified delegate」という単一表示は仕様外の弱点を隠す。

最初の要素は必ず受け入れ可能な認可サーバーのルートでなければならない。検証者は後方を探して代替ルートを選べない。途中の有効署名は、欠けた始点を作れない。

縮小は文字列比較ではなく意味の計算である

子は親より広くなれない。scope は集合包含で扱える。authorization_details は型ごとの意味を必要とする。対象資源、操作、配列、wildcard、省略、default を理解しなければならない。

JSON が短いほど狭いとは限らない。口座 ID の省略が全口座を意味する場合もある。同じ type でも対象は異なる。生テキスト一致やフィールド数では権限拡張を検出できない。

包含規則を実装できない検証者はチェーンを拒否する。未知の claim を都合よく解釈しない点が重要だ。共同層は誰でもローカルに再計算できる決定的規則に限定し、将来の意味を常設サービスに推測させない。

省略の効果も claim ごとに違う。子が scope または authorization_details を省けば、その権限要素は消え、後代に復活できない。aud の省略は親の有効 audience を保つ。nbf の省略は新たな開始制限を加えない。拡張仕様は導入、再導入、継承、縮小、削除を定義する必要がある。

ゆえにルートから順に有効状態を更新する。各 JWT を単独検証して葉だけ読む方法では、省略の不可逆性や複合セマンティクスを失う。検証経路そのものが証拠である。

深さは一本の経路を制限するだけである

ルートは有限の max_delegation_depth を持つ。親の有効値が m なら、子は 0 から m-1、省略時は m-1。0 の葉は資源利用ができても再委任できない。

これは階層数を抑えるが、兄弟数や操作量を抑えない。深さ 2 でも多数の子を発行できる。短い寿命でも不可逆な操作には十分である。小さな scope 名でも高価値資源を制御し得る。

仕様はトークン数、バイト数、検証費用も制限させる。運用はさらに fan-out、鍵再利用、タスク寿命、後代の棚卸しを管理する。各子発行を認可サーバーに戻さない以上、同サーバーが完全な委任グラフを持つとは期待できない。

中央往復を減らす利益と、観測点を失う費用は対である。障害時に侵害親から派生した全子を特定したいなら、別の発行受領証がいる。ログは可観測性であり、無効な権限拡張を正当化するものではない。

資源利用への同意と再任命への同意は別である

資源所有者が関わる grant では、認可サーバーは通常アクセスとクライアント発行委任を区別しなければならない。A に報告書を読ませる承認は、A が別の読者を選べる承認ではない。

同意画面は権限、audience、寿命、最大深さを示し、各子を認可サーバーが観察・承認するわけではないと伝えるべきだ。所有者は一回の利用だけでなく、限定された任命能力を渡している。

同じ秘密鍵が現在の DPoP 証明と子トークン署名に使われる。侵害時は利用と再委任の両面が開く。署名 API は用途を狭く分離し、HTTP proof 用 oracle が子発行に転用されないようにする必要がある。

根の所持は、所有者が特定の B を見て承認した証明ではない。所有者は範囲と深さを承認し、A が相手を選ぶ。その選択の責任と記録は A 側に残る。

正確なバイト列と順序が葉まで届く

提案された DA は compact JWT を根から葉へ ~ で連結する。葉 DPoP の ath は提示された正確な列をハッシュする。先に decode、normalize、reserialize してはならない。

これにより盗聴者は葉鍵なしで要素を削除・追加・並べ替えできない。しかし DPoP は祖先を検証しない。ルート署名、各子署名、cnf.jkt 連続性、深さ、包含、audience、時間は別途すべて確認する。

葉 proof が言うのは「この鍵の保持者が、この exact chain で、この method/URI の要求を行った」である。各祖先に権限があったとは言わない。RFC 9449 の一般 DPoP は既存記事の領域であり、本稿はその前にある累積権限を扱う。

子には parent ID がない。同じ親鍵を束縛し、累積制限が子を包む別チェーンでも有効になり得る。トークンごとに別鍵を使うと再利用範囲を狭められる。特定親だけに結び付ける要件には、別の application binding が必要である。

失効の記録と配布は同じ出来事ではない

草案は RFC 7009 を拡張し、exact chain の最後を対象として失効要求する。対象に束縛された鍵の保持者、または直接の委任者が適切な鍵で失効権を証明する。通常の OAuth client authentication だけでは足りない。

ルート失効は全分岐を無効にする。子の失効はそれを含むチェーンと後代を無効にするが、親、兄弟、同じ鍵の別トークンまで自動失効させない。

endpoint の HTTP 200 は全資源サーバーへの到達を示さない。成功は認可サーバーに状態を記録するだけで、仕様は offline verifier への配布を定義しない。更新か期限切れまで古い状態を受け入れる可能性がある。

「失効登録時刻」と「各効果点が失効を観測した時刻」を分離して測る。短寿命、introspection、外部 status feed などを別途設計する。鍵を破棄しても派生 session の終了や過去効果の取消しは証明されない。

最後の認可は資源サーバーに残る

全暗号チェック後も、資源サーバーは所有者ポリシー、tenant、資源状態、失効、application rule を適用する。有効チェーンでも拒否できる。これはローカルな将来判断を守る境界である。

ルートは許容上限であって遠隔命令ではない。子は上限を下げる。資源サーバーは凍結口座、法的保全、リスク変化など現在の事実でさらに拒否できる。

実行効果は別の受領証だ。認可成功後に DB conflict、queue timeout、部分的外部操作が起こる。DPoP replay 制御は exactly-once 取引を保証しない。idempotency key、commit、reconciliation が必要である。

受領証 最小証拠 証明しないもの
ルート同意 access と委任の分離、深さ 将来の特定子承認
ルート発行 issuer、hash、権限、audience、時刻、鍵 現在の利用
委任先関連付け instance、tenant、指紋、channel 子が狭いこと
子発行 親辺、子 hash、制限、残深さ 根信頼や現状
chain 検証 署名、連続性、包含、時間 葉鍵の所持
葉 DPoP method、URI、ath、nonce、replay 祖先の正当性
status 祖先失効観測と鮮度 全 verifier への配布
local 認可 policy、operation、decision commit
effect transaction と永続状態 望む外部結果
reconciliation 観測と例外 次の行動権限

子トークンが本物でも、権限は全チェーンの単調性と効果点の現在判断にしか存在しない。