Identity Deep Dive

Transaction Tokens

外部エンドポイントがリクエストを受けたとき、呼び出し元の credential を短命な署名付き JWT に交換し、call chain の内部ワークロードがそれを改変せず転送して検証する。ユーザーとリクエストの文脈が途中で失われたり書き換えられたりしなくなる。

現在地
WG ラストコール・取りまとめ
公式本文
draft-ietf-oauth-transaction-tokens-11
2026-08-21
公式に文書化された対応
1
動き
5 件の動き (90 日)

解説の元ファイル (GitHub)

どういうときに使うか

  • 有効な外部トランザクションなしで呼び出せてしまう内部ワークロード: 1 つのトランザクションに結び付いた txn id と短い exp を持つ Txn-Token が、実際の外部リクエストが call chain を始めたことを証明する (Section 1, Section 7)。
  • マイクロサービス間での impersonation やパラメータ改竄: subject と認可の詳細は、Txn-Token Service が発行時に固定した署名付きの sub、scope、tctx claim に入るので、途中のホップが書き換えられない (Section 1, Section 9.2)。
  • 盗まれた OAuth access token がメッシュ内に広がる: 外部の access token はエッジに留まる。Txn-Token にそれを含めてはならず、Txn-Token を access token として使ってもならない (Section 13.4, Section 13.13)。
  • スケジュールジョブのような、受信トークンのない内部起点の処理: ワークロードは自己署名 JWT を subject_token として提示し、chain 用の Txn-Token を得る (Section 5.1, Section 8.2, Section 11.2.1)。
図
flowchart LR
    A["API ゲートウェイが access token 付きのリクエストを受ける"] -->|"access token を転送するか、何も渡さない"| B["内部サービスは誰が何を認可されたか検証できず、漏れたトークンはどこでも使える"]
    A -->|"Txn-Token"| C["sub, scope, txn, tctx を持つ短命な署名付き JWT 1 つが call chain 全体を流れる"]

解決する問題

API への外部リクエストは、内部ワークロード呼び出しの連鎖に広がる。トラストドメインの中で各ワークロードは動いてよいか判断しなければならないが、ふつう見えるのは直前のホップだけ。そこから、有効なトランザクションなしのワークロード呼び出し、ユーザーやワークロードの impersonation、chain 途中でのパラメータ改変、認可の文脈を運ぶ access token の窃取が起きうる。Txn-Token は、ユーザーかワークロードのアイデンティティ、認可の文脈、リクエストの文脈を、トランザクションに結び付いた短命な署名付き JWT に固定し、call chain を通して運ぶ。下流の各ワークロードは同じ不変の事実に対して自分の認可判断を下せる (Section 1, Section 4)。

仕組み

図
sequenceDiagram
    participant X as 外部クライアント
    participant G as 外部エンドポイント (ゲートウェイ)
    participant T as Txn-Token Service
    participant A as ワークロード A
    participant B as ワークロード B
    X->>G: OAuth access token 付きリクエスト
    G->>T: POST /token grant_type=token-exchange, requested_token_type=txn_token, audience=トラストドメイン, scope, subject_token, subject_token_type, request_context, request_details
    T->>T: 要求元を認証、subject_token を検証、iat aud exp txn sub scope req_wl tctx rctx を設定
    T-->>G: access_token=Txn-Token, token_type=N_A, issued_token_type=txn_token
    G->>A: Txn-Token ヘッダ付きで呼び出し
    A->>A: 署名検証、aud が自分のトラストドメインか、未失効か
    A->>B: 同じ Txn-Token ヘッダを改変せず付けて呼び出し
    B-->>A: 応答
    A-->>G: 応答
    G-->>X: 応答

外部エンドポイントは Txn-Token Service に RFC 8693 の token exchange を要求する。requested_token_type=urn:ietf:params:oauth:token-type:txn_token、audience にトラストドメイン名、scope に目的、subject_token に受信した credential、そして RECOMMENDED の request_context と request_details のオブジェクトを付ける。サービスは typ が txntoken+jwt の JWT を発行し、claim として iat、aud、exp、txn、sub、scope、req_wl に加え、不変の認可詳細を tctx、リクエスト環境を rctx に入れる。各ワークロードはトークンを Txn-Token HTTP ヘッダに載せ、受信時に検証し、受け取ったままの形で次へ渡す (Section 9.1, Section 9.2, Section 11.1, Section 12)。

仕様が求めること

  • トラストドメインごとに論理的な Txn-Token Service はちょうど 1 つでなければならず、RFC 8693 の token exchange エンドポイントをプロファイルする (Section 3, Section 10)。
  • JWT ヘッダの typ は txntoken+jwt でなければならない。iat、aud、exp、txn、sub、scope、req_wl は REQUIRED、tctx と rctx は RECOMMENDED、iss は OPTIONAL。受信者は理解できない claim を無視しなければならない (Section 9.1, Section 9.2)。
  • リクエストの grant_type は urn:ietf:params:oauth:grant-type:token-exchange、audience はトラストドメイン名、requested_token_type は urn:ietf:params:oauth:token-type:txn_token でなければならず、scope は REQUIRED (Section 11.1)。
  • 応答の token_type は N_A、access_token は Txn-Token、issued_token_type は txn_token の URN でなければならず、refresh token を含めてはならない (Section 11.4)。
  • 要求元ワークロードと Txn-Token Service は相互に認証しなければならない (Section 11.5)。
  • HTTP で別のワークロードを呼ぶときは Txn-Token ヘッダにちょうど 1 つの Txn-Token を送らなければならず、Authorization ヘッダを使ってはならない。受信側は署名、aud が自分のトラストドメインであること、未失効であることを検証し、改変せず転送しなければならない (Section 12, Section 12.1, Section 12.2)。

注意点

  • Txn-Token はリプレイ耐性がない。寿命は分かそれ以下の短さに保たなければならず、提示された credential がすでに失効していれば発行してはならない (Section 6, Section 13.1)。
  • refresh token で Txn-Token を要求してはならず、提示された access token を Txn-Token に埋め込んではならない (Section 13.3, Section 13.4)。
  • 要求された scope は subject token の scope と同じかそれより狭くなければならない。scope を判定できないときは、無制限とみなさず拒否しなければならない (Section 13.6, Section 13.14)。
  • Txn-Token をワークロードの認証に使ってはならず、OAuth access token として使ってもならない (Section 13.12, Section 13.13)。
  • Txn-Token から発行する置き換えトークンは、許可範囲を広げてはならず、txn、sub、aud を変えてはならず、失効したトークンから発行してもならない (Section 13.15)。
  • Txn-Token 全体をそのままログに書いてはならない。ハッシュか、署名を除いたペイロードを記録する (Section 15.2)。

出典

他の仕様との関係

関係図
flowchart LR
  s_txn_tokens["Transaction Tokens"]
  s_token_exchange["Token Exchange"]
  style s_txn_tokens stroke-width:3px
  s_txn_tokens -->|土台とする仕様| s_token_exchange

公式に文書化された対応

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

製品・IdP・サービス

  • IBM Verify (IdP): draft-ietf-oauth-transaction-tokens に基づくトランザクショントークンを発行する 出典 (確認 2026-11-11)

動き

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

このサイトの解説

  • 議論IETF WIMSE

    evidence-binding の著者らは、停止された先行アクターに関する記述を RFC 8693 第4.1節と矛盾しないよう限定することにした。

    New I-D: draft-thaha-wimse-agent-evidence-binding-00 (evidence binding for AIMS audit)

    解説を読む

    Shameer は Mikhail の二点の指摘を受け入れた。Serving Party が先行アクターの停止を理由に呼び出しを拒否できないという記述は広すぎた。RFC 8693 第4.1節が排除しているのは入れ子の act クレームをその判断に用いることであり、別途検証された委任トークンの利用ではない。文言は「先行アクターがその後停止されたことを、入れ子の act クレームに基づいて理由に呼び出しを拒否することはできない」に改められる。「完全でも証拠でもない」という履歴に関する表現は、「それ自体では完全であること、あるいはいずれかのホップが権限を保持または縮小したことを立証しない」に置き換えられる。どちらの修正も SCITT ドラフトと Evidence Binding ドラフトの次版に反映される。このメッセージ自体にドラフト本文は含まれていない。

    • 入れ子の act クレームではなく検証済み委任トークンを用いて、停止された先行アクターを理由に呼び出しを拒否できるか判断する Serving Party。
    • 関連: OAuth WG: draft-ietf-oauth-transaction-tokens. 弱い関連のみ。いずれもホップ間の委任コンテキストを扱うが、資料に直接の言及はない。
  • 議論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

    AAT、Asor、Cred -02 の著者が、子トークンのより小さい del_max_depth を尊重すべきことで一致し、IETF 127 前に制約を比較する

    AAT -02 announcement (2 new messages)

    解説を読む

    Kieran は、各ホップでの有効な最大深度は経路上で最小の del_max_depth であること、およびこの上限は「最大深度にある末端」の扱い（AAT J.10.f は del_depth がルートの最大値に等しい末端を受理し、Asor -03 は拒否する）とは別に決めるべきだと述べた。Rob Zagarella は三つのドラフトの比較表に、末端を単一リクエストのダイジェストに束縛できるかを記録するよう求め、Kieran は Cred -02 では現状トークンで表現できないと答えた。Cred -02 の Section 5.5 はチェーン形式を参照で取り込むため、DS 外で検証する場合の記載は暫定である。Rob は AAT Section 9.8 の失効鮮度の上限を Cred -02 Section 7 と同じ表現で示すことも求めた。Niki は 11 月 16 日にサンフランシスコでサイドミーティングを開く。

    • 減衰する委任トークンの実装者が、最大深度にある末端を受理すべきか知る必要がある場合。
    • 受取人と金額のように、承認を一つの具体的な操作に束縛する必要がある人間承認のフロー。
    • 関連: OAuth WG: draft-ietf-oauth-transaction-tokens. 資料中では参照されていない。
  • 軽微・詳細不明IETF WIMSE

    競合するクロスドメイン・トランザクショントークン提案は、IETF 127 合同セッションで質問できるが共同発表はできないとされた

    OAuth IETF 127 Call for Agenda Items

    解説を読む

    Sean から Yuan への短い返信であり、過去のやり取りを引用している。Yuan は、合同セッションで既にアジェンダにある Cross-Domain Transaction Tokens と同じユースケースを対象とする draft-liu-oauth-cross-domain-txn-token を発表するため、5分の枠を求めていた。Sean は、Pieter と George と相談した結果、Yuan が質問することは歓迎するが、共同発表は現時点では認められないと述べている。引用されたアジェンダ募集の文面によれば、OAuth チェアは2時間枠を2つと、WIMSE/OAuth の合同セッションを要請している。複数の関係者の関心が示された案件を優先すること、およびドラフト提出の締切が2026年11月2日であることも書かれている。プロトコル本文の変更はない。

    • 関連: OAuth WG: draft-ietf-oauth-transaction-tokens. 合同セッションの議題はドメインをまたぐトランザクショントークンであり、競合ドラフトも同じユースケースを対象としている。
  • 議論IETF WIMSE

    Rob Zagarella が draft-sweeney-wimse-credential-delegation-02 にコメントし、ユーザー発行ルートでの人間承認の証跡の分離と、停止・復元時の挙動の明確化を提案した。

    draft-sweeney-wimse-credential-delegation-02

    解説を読む

    このスレッドには Kieran Sweeney による -02 の告知が含まれる。このドラフトは、Delegation Server がユーザーの預けた資格情報を保持し、エージェントが委任トークンの下でそれを代理で行使するプロファイルである。主な変更は、サブ委任の交換、トークン内の順位、DS を単一の書き込み元とする累積上限（max_lifetime、max_subtree）、draft-asor-wimse-agent-delegation-chain の agent_delegation 形式を採用したチェーン検証プロファイル、および失効を「閉鎖ではなく無効化」とする整理である。新しい返信で Zagarella は、-03 でルートの発行者と、自然人の承認の証跡（方法と保証レベルのみ）を分けることを提案した。また Section 7 に、停止中の操作が検証側にどう見えるか、復元された委任が同一の許可か新規かを明記し、1時間の上限は露出の上限として示すよう求めた。

    • ユーザーが上流の資格情報を預け、それを露出させずにエージェントへ委任させるエージェント基盤。
    • Delegation Server から離れた検証側が、ユーザー発行ルートに対する人間承認の証跡を確認する場所が必要となる場合。
    • 関連: OAuth WG: draft-ietf-oauth-transaction-tokens. どちらも呼び出しチェーン上で委任された権限を扱うが、資料に明示的な関連は無く、関連は弱い。