Identity Deep Dive

Identity and Authorization Chaining

トラストドメイン A のクライアントが、手元のトークンを A の認可サーバーで JWT グラントに交換し、そのグラントをドメイン B の認可サーバーに提示して access token を得る。ユーザーのアイデンティティと認可がドメイン境界を越えて残る。

現在地
承認済み、RFC Editor 待ち
公式本文
draft-ietf-oauth-identity-chaining-17
2026-08-21
公式に文書化された対応
0
動き
4 件の動き (90 日)

解説の元ファイル (GitHub)

どういうときに使うか

  • ユーザーのリクエストがオンプレとクラウドの別ドメインのワークロードにまたがる: 境界でユーザーの文脈を失わず、各ワークロードが同じ文脈に自分のポリシーを適用できる (Appendix A.1)。
  • 別の認可サーバー配下の外部リソースを使う CI システム: commit hash やリポジトリといったビルドのアイデンティティが、グラントの中でドメインを越えて運ばれる (Appendix A.2)。
  • 家庭用カメラの映像を要求するパートナーのダッシュボード: デバイス会社は「パートナーが呼んだ」だけでなく、「許可されたユーザーが認可した」ことを自分で検証できる (Appendix A.3)。
  • 企業 SSO を API アクセスにまで広げる: クライアントが IdP の identity assertion を、その IdP を信頼する SaaS の認可サーバーが受け付けるグラントに交換する。追加のユーザー操作はない (Appendix A.4, Appendix A.5)。
図
flowchart LR
    A["ドメイン A のクライアントが AS A 発行のトークンを持っている"] -->|"そのままドメイン B に転送"| B["AS B は検証できず、ユーザーも許可された scope も分からない"]
    A -->|"chaining"| C["AS A の JWT グラントを AS B で access token に交換、ユーザーの文脈付き"]

解決する問題

1 つのリクエストが、それぞれ独自の認可サーバーを持つ複数のトラストドメインのリソースサーバーを通ることがある。途中の各保護リソースは、誰のためのリクエストか、どんな認可が与えられたか、任意でどのリソースサーバーを経由してきたかを知る必要がある。ドメイン A のトークンはドメイン B にとって意味を持たない。このドラフトは、ドメイン A 内の RFC 8693 Token Exchange と、ドメイン B での RFC 7523 JWT グラントを組み合わせ、検証可能なグラントが 1 つ以上のドメイン境界を越えて文脈を運ぶようにする (Section 1, Section 2.1)。

仕組み

図
sequenceDiagram
    participant C as クライアント (ドメイン A)
    participant ASA as 認可サーバー A
    participant ASB as 認可サーバー B
    participant RS as リソースサーバー (ドメイン B)
    C->>C: AS B を発見、たとえば protected resource metadata の authorization_servers
    C->>ASA: POST /token grant_type=token-exchange, subject_token, subject_token_type, resource か audience = AS B, scope
    ASA-->>C: JWT 認可グラント, aud = AS B, issued_token_type jwt, expires_in
    C->>ASB: POST /token grant_type=jwt-bearer, assertion=グラント, scope か resource
    ASB->>ASB: RFC 7523 Section 3 で検証、aud が自分か、subject を特定、ポリシー適用
    ASB-->>C: access_token
    C->>RS: access token でリクエスト
    RS-->>C: 応答

クライアントはまずドメイン B の認可サーバーを見つける。たとえば RFC 9728 の protected resource metadata にある authorization_servers から (Section 2.2)。次に自分の認可サーバーに token exchange を要求し、resource か audience でドメイン B のサーバーを指定する。返ってくるグラントは aud がドメイン B のサーバーである JWT で、ドメイン A は途中で claim を足したり、削ったり、書き換えたりしてよい。subject 識別子の対応付けや、B に不要な claim の削除がその例 (Section 2.3, Section 2.5)。クライアントはこのグラントを grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer の assertion として提示し、ドメイン B は RFC 7523 のグラントとして検証して通常の access token を返す (Section 2.4)。

仕様が求めること

  • token exchange リクエストでは、resource (ドメイン B の認可サーバーの URI) か audience (その論理名) のどちらかが REQUIRED。scope は、必要ならグラントに含める scope を指定する (Section 2.3.1)。
  • ドメイン A の認可サーバーは、リクエストが不正なとき、または resource や audience が未知かポリシー上受け入れられないときは拒否しなければならない (Section 2.3.2)。
  • 発行するグラントの aud はドメイン B の認可サーバーを示さなければならない。複数も許されるが、1 つに絞ることが RECOMMENDED (Section 2.3.3)。
  • ドメイン B の認可サーバーは RFC 7523 の Section 3 と 3.1 に従ってグラントを検証しなければならず、aud はトークンエンドポイントか issuer 識別子でそのサーバーを示さなければならない。subject を特定できなければ拒否しなければならない (Section 2.4.2)。
  • access token の応答は RFC 6749 Section 5.1 の標準的な応答 (Section 2.4.3)。
  • OPTIONAL なメタデータ identity_chaining_requested_token_types_supported は、requested_token_type として要求できるトークン種別を列挙する。載っていないからといって未対応とは限らない (Section 3)。

注意点

  • グラントは bearer credential。実装はリプレイのリスクを評価する必要がある。対策は短い寿命、ワンタイム利用、ドメイン B でのクライアント認証 (Section 5.5)。
  • ドメイン B はこのフローで refresh token を発行すべきでない。クライアントはグラントを再提示するか、ドメイン A から新しいものを得る (Section 5.4)。
  • 認可サーバーはクライアント認証 (RFC 9700 の Section 2.5) と sender-constrained token について RFC 9700 に従うのがよい。bearer token が依然として最も普及した access token の形 (Section 5.1, Section 5.2)。
  • downscoping では、要求された scope が subject_token の scope より高い権限でないことを認可サーバーが検証する必要がある (Section 2.5)。
  • グラントには最小限のデータだけ入れ、両ドメインのプライバシーポリシーを揃える (Section 6)。

出典

他の仕様との関係

関係図
flowchart LR
  s_identity_chaining["Identity and Authorization Chaining"]
  s_token_exchange["Token Exchange"]
  s_jwt_bearer["JWT Bearer Grant and Client Authentication"]
  s_id_jag["Identity Assertion JWT Authorization Grant"]
  style s_identity_chaining stroke-width:3px
  s_identity_chaining -->|土台とする仕様| s_token_exchange
  s_identity_chaining -->|土台とする仕様| s_jwt_bearer
  s_id_jag -->|プロファイル対象| s_identity_chaining

公式に文書化された対応

利用状況には、公式のドキュメント（ベンダーやプロジェクト自身のもの、または標準化団体がその名前を挙げているページ）に対応が明記されているものだけを載せている。引用した文言がそのページにまだあるかは毎週確認している。実験的・アルファ・ベータの対応は「プレビュー」として別に数える。

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

動き

Datatracker の revision 履歴、このサイトの日次 run が書いた解説、draft 名を挙げた ML の件名。

このサイトの解説

  • 議論IETF WIMSE

    IETF 127 ハッカソンの WIMSE エージェント呼び出しチェーン相互運用計画に対し、失効とフェイルクローズを中心とした異常系シナリオが提案された。

    IETF 127 Hackathon: WIMSE interop scenarios for agent call chains (5 new messages)

    解説を読む

    Alexander Pelov は、独立した複数の実装（実験的な WIT-SVID 対応の SPIRE、go-spiffe、Cofide の PoC、Python 実装）を用いた相互運用シナリオを実施する予定である。シナリオは workload-creds-03、wpt-02、http-signature-08、identifier-04、Txn-Token、アイデンティティチェーニングを二つの信頼ドメインにまたがって使い、ログには共通のトランザクション ID を記録する。正常系では Txn-Token を各ホップの証明に束縛し、Txn-Token 自体はドメイン外に出さない。Ben Le（draft-le-agent-passport）と Iman は、到達不能なステータスリスト、委任後の失効、権限が拡大する委任、二つのサービスにまたがる累積上限、プロキシによるリクエスト書き換え、ツール定義のダイジェスト変化といったケースを追加した。Iman は、確定した失効、期限切れのステータスキャッシュ、利用不能なステータスサービスをログ上で区別すること、また失効した認可では効果が生じる前に操作が阻止されることを求めている。

    sequenceDiagram
 participant A as Agent A (domain A)
 participant B as Agent B
 participant R as Receiving hop
 A->>B: delegate
 B->>R: first call
 R-->>B: accepted
 Note over A: A is revoked
 B->>R: next call
 R-->>B: rejected (fail closed)
    • 他実装と比較できる共通の異常系テストケースを求める WIT/WPT や Txn-Token の実装者。
    • ステータスリストに到達できない場合や、チェーン途中で委任元エージェントが失効した場合のフェイルクローズ方針を定める運用者。
    • 関連: OAuth WG: draft-ietf-oauth-transaction-tokens. シナリオでは Txn-Token を各ホップの証明に束縛し、ドメイン内にとどめている。
    • 関連: OAuth WG: draft-ietf-oauth-identity-chaining. 信頼ドメイン B への移行にアイデンティティチェーニングを用いる。
  • 議論IETF WIMSE

    AIMS の委任スレッド：信頼ドメインをまたぐ場合、対応関係が署名された記録にあれば委任対象の識別子は異なってよい

    Subject: AIMS-00: multi-hop delegation context across agent, tool and resource boundaries (2 new messages)

    解説を読む

    Kieran Sweeney は、「sub の保持」は同じバイト列ではなく同じプリンシパルを指すと明確化した。同一信頼ドメイン内では全ホップで値が同一（sub は固定、行為者は client_id と act）。信頼ドメインをまたぐ場合は、identity chaining による書き換えは、書き換えた当事者が旧値・新値・自身の識別子を署名対象に記録するなら許容される。AS が対応関係を保持するだけでは AIMS Section 11 には不十分である。Marc は PR #176 に同趣旨の二つの修正を提案する。また、鮮度の境界を「期限以降は拒否」に改めることでも合意し、21 件の境界ベクターと 10 月 23 日の文言が変わり、ちょうど S+L で受理されていたケースは拒否になる。

    sequenceDiagram
 participant A as Domain A AS
 participant B as Domain B AS
 participant L as Signed audit record
 A->>B: token with sub value X
 B->>B: transcribe X to Y
 B->>L: record old X, new Y, own identity
 B->>B: issue token with sub Y
    • identity chaining で信頼ドメインをまたぐエージェントチェーンで、監査者が記録だけから元のユーザーを復元する必要がある場合。
    • S+L の失効受理境界を実装する検証者が、ちょうど期限の入力を受理するか判断する場合。
    • 関連: OAuth WG: draft-ietf-oauth-identity-chaining. 信頼ドメイン間で書き換えられる識別子は OAUTH-ID-CHAIN の Section 2.5 として議論されている。
  • 議論IETF WIMSE

    Cred 委任 -02 のレビュー：-03 に向けた論点はユーザー発行ルート、集計モード、失効ステータス

    draft-sweeney-wimse-credential-delegation-02 (2 new messages)

    解説を読む

    Kieran の -02 告知は、ユーザーが預けた資格情報を保持する Delegation Server（DS）を置き、エージェントが委任トークンのもとで代理実行する構成を説明している。追加点は、サブ委任の交換（5.4.1）、トークン内の順位、DS のみが書き込む max_lifetime と max_subtree を持つ delegation_constraints、Asor の agent_delegation 形式をそのまま採用するチェーン検証プロファイル（5.5）、revoked_count は無効化であって完結ではないとする失効の記述、ML-DSA の許可である。Caleb Dayton は、ユーザー発行トークンの claim 再マッピング、jti をルートレシートとする案、単一書き込み元と委任先保持の集計を区別するモード指示、DS がない場合の状態確認手段など六点を指摘した。Kieran は鍵ごとのモード指示に同意しつつ、検証者ごとの集計では検証者をまたいだ総量は抑えられないと注意し、DS が発行していないトークンのステータス機構は -02 に定めがないと述べた。Rob Zagarella は、ルートの発行者と人間の承認の証拠を分けること、および Section 7 で一時停止と復元を扱うことを提案した。

    sequenceDiagram
 participant U as User
 participant DS as Delegation Server
 participant AG as Agent
 participant UP as Upstream resource
 U->>DS: deposit credential
 DS->>AG: delegation token
 AG->>DS: exercise under token
 DS->>UP: call with deposited credential
 DS->>AG: result and receipt
    • ユーザーが OAuth 資格情報をプロキシに預け、エージェントが上流トークンを保持しないエージェント基盤。
    • DS から離れた検証者が、累積上限を超えたか判断する場合。
    • 関連: OAuth WG: draft-ietf-oauth-identity-chaining. 資料中では言及されていない。
  • 議論IETF WIMSE

    Marc は、sub が各ホップで保存されるとは、トラストドメインをまたいでも同じ値という意味かを問うている。

    Subject: AIMS-00: multi-hop delegation context across agent, tool and resource boundaries

    解説を読む

    Marc は、sub は各ホップで Principal であり元の委任対象のままである、という Kieran の発言を引用している。そのうえで、保存とは、ホップがトラストドメインをまたいで転記された識別子（OAUTH-ID-CHAIN の 2.5 節）を受け取る場合も含め、すべての当事者で同じ sub の値を意味するのかを問う。もう一つの解釈は、各値が同じ User を指し、発行した認可サーバーが 11 節のためにその対応を保持していれば足りるというものである。Nik が AIMS の issue #88 と #90 について、値が当事者間で異なりうる 10.10 節の文案を提案しており、それが Kieran の性質と食い違わないようにするための質問だという。このメッセージには回答は含まれていない。

    • 下流の認可サーバーが同じユーザーに対して別の識別子を発行する、複数ドメインにまたがるエージェント配備。
    • 関連: OAuth WG: draft-ietf-oauth-identity-chaining. このメッセージは、トラストドメイン間で転記される識別子について OAUTH-ID-CHAIN の 2.5 節を引用している。