Skip to content 
oauth                                                   A. Tulshibagwale
Internet-Draft                                                      SGNL
Intended status: Informational                               G. Fletcher
Expires: 29 January 2026                          Practical Identity LLC
                                                            P. Kasselman
                                                                   SPIRL
                                                            28 July 2025

Transaction Tokens

draft-ietf-oauth-transaction-tokens-06

Abstract

Transaction Tokens（Txn-Token）は、API 呼び出しなどの外部からのプログラム的なリクエストを処理する際に、信頼できるドメイン内のワークロード間でユーザーのアイデンティティおよび認可コンテキストを維持し、伝播させるために設計されている。Txn-Token は、新たなトランザクションが内部で開始される場合でも、このコンテキストが呼び出しチェーン全体で保持されることを保証し、複雑なマルチサービス・アーキテクチャにおけるセキュリティと一貫性を高める。

About This Document

この注記は、RFC として公開する前に削除される。

このドラフトの最新改訂版は以下で入手できる。\ https://drafts.oauth.net/oauth-transaction-tokens/draft-ietf-oauth-transaction-tokens.html

本書のステータス情報は以下に掲載されている。\ https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/

このドラフトのソースおよび Issue トラッカーは以下にある。\ https://github.com/oauth-wg/oauth-transaction-tokens

Status of This Memo

この Internet-Draft は、BCP 78 および BCP 79 の規定に完全に準拠して提出されている。

Internet-Drafts は、Internet Engineering Task Force（IETF）の作業文書である。なお、他のグループも作業文書を Internet-Drafts として配布することがある。現行の Internet-Drafts の一覧は以下にある。\ https://datatracker.ietf.org/drafts/current/

Internet-Drafts は最大 6 か月間有効なドラフト文書であり、いつでも他の文書により更新、置換、または廃止される可能性がある。Internet-Drafts を参考資料として扱ったり、「作業中（work in progress）」以外の形で引用したりすることは不適切である。

この Internet-Draft は 2026 年 1 月 29 日に失効する。

Copyright (c) 2025 IETF Trust および本書の著者として特定された者。All rights reserved.

本文書は、公開日に有効な IETF Trust の IETF 文書に関する法的規定（https://trustee.ietf.org/license-info）および BCP 78 の対象である。これらの文書には、本文書に関する権利および制限が記載されているため、注意深く確認すること。本文書から抽出された Code Components は、Trust Legal Provisions の Section 4.e に記載された Revised BSD License の本文を含めなければならず、また Revised BSD License に記載されているとおり、無保証で提供される。

Table of Contents

1. Introduction

現代のコンピューティング・アーキテクチャでは、ワークロードと呼ばれる、独立して動作する複数のコンポーネントがしばしば用いられる。多くの場合、API のような外部に公開されたインタフェースを通じた外部からの呼び出しは、その呼び出しを処理するために複数の内部ワークロードの起動を招く。これらのワークロードは、仮想的または物理的に分離されたネットワーク上で動作することが多い。これらのネットワーク、およびその境界内で動作するワークロードは、ソフトウェア・サプライチェーン攻撃、特権ユーザーの侵害、その他の攻撃を通じて攻撃者により侵害され得る。外部攻撃、悪意ある内部関係者、またはソフトウェアの誤りによって侵害されたワークロードは、次に挙げる権限のない行為の一部または全部を引き起こし得る。

  • 明示的なトランザクション呼び出し（外部または内部）が存在しないにもかかわらず、ネットワーク内のワークロードを呼び出す
  • 任意のユーザーになりすます
  • パラメータを改変する、または付加する

これらの行為の結果は、リソースへの不正アクセスである。

2. Overview

Transaction Tokens（Txn-Token）は、そのような攻撃または無関係な呼び出しによる被害を軽減するための手段である。有効な Txn-Token は、有効なトランザクション呼び出しの存在を示す。多くのトランザクションは外部イベント（例：インターネットに公開された API の呼び出し）によって開始される一方で、他のトランザクションは信頼できるドメイン内部から開始される。Txn-Token は、外部からトリガーされたトランザクションと内部から呼び出されたトランザクションの双方に適用され、ユーザーのアイデンティティ、またはリクエストを行ったワークロードが、その後のワークロード呼び出し全体にわたって保持されることを保証する。Txn-Token は、次のようなコンテキストを保持する。

  • 元の呼び出しのパラメータ
  • 元の呼び出し元の IP アドレスなど、環境要因
  • 呼び出しチェーン内で保持される必要のある、あらゆる計算済みコンテキスト\ これには、外部 endpoint への元のリクエストには含まれていなかった情報も含まれる。

暗号学的に保護された Txn-Token により、下流のワークロードはそのような情報に対して権限のない改変を行えず、また意図的に呼び出されたトランザクションが存在しないまま無関係な呼び出しを行うこともできない。

2.1. What are Transaction Tokens?

Txn-Token は、署名付きで短命な JWT（[RFC7519]）であり、ユーザーまたはワークロードのアイデンティティを表明し、認可コンテキストを表明する。認可コンテキストは、複数のワークロードを通過して呼び出しチェーンが実行される間、一定に保たれると期待される情報を提供する。

2.2. Creating Txn-Tokens

2.2.1. Initial Creation

Txn-Token は通常、外部に可視な endpoint を介してワークロードが呼び出され、その呼び出しが OAuth 2.0 Access Token（[RFC6749]）などの別の仕組みによって認可されるときに作成される。そのワークロードは、OAuth 2.0 Token Exchange（[RFC8693]）を実行して Txn-Token を取得する。これを行うために、特別な Token Service（Txn-Token Service）を呼び出し、Txn-Token を生成するのに十分なコンテキストを提供する。Txn-Token Service に提供されるコンテキスト情報には、次が含まれてよい（MAY）。

  • 外部の認可トークン（例：OAuth の Access Token）
  • リクエストの主体を表す、内部で生成された JWT
  • この呼び出しの期間中に束縛される必要があるパラメータ
  • 着信 IP アドレス、User Agent 情報、その他 Txn-Token Service が Txn-Token を発行するのに役立つ追加コンテキスト

Txn-Token Service は、呼び出しが成功した場合に Txn-Token を生成して応答する。呼び出し元のワークロードは、その Txn-Token を用いて、後続のワークロードへの呼び出しを認可する。後続のワークロードは、自身で Txn-Token を取得してもよい。

要求元サービスが Txn-Token Service へのリクエストで利用できる受信トークンを持たない場合、自己署名 JWT を生成し、外部の認可トークンの代わりにリクエストでそれを渡す。

2.2.2. Replacement Txn-Tokens

呼び出しチェーン内のサービスは Txn-Token を置き換えることを選択できる。これは通常、そのサービスが現在の Txn-Token のコンテキストへ追加したい場合に起こり得る。

置換 Txn-Token を取得するために、サービスは Txn-Token Service へ新しい Txn-Token を要求し、現在の Txn-Token とその他のパラメータをリクエストに含める。Txn-Token Service は、Txn-Token の価値全体を損なわないよう、サポートする置換リクエストの種類に注意しなければならない。

2.3. Txn-Token Lifetime

Txn-Token は短命（分のオーダー、例：5 分）であることが期待され、その結果、外部呼び出しとして想定される期間のみに使用され得る（MAY）。自己署名 JWT を用いてリクエストが行われる場合を除き、Txn-Token の要求時に Txn-Token Service に提示されるトークンまたはその他のクレデンシャルに有効期限があるなら、期限が過ぎた後に Txn-Token Service は Txn-Token を発行してはならない（MUST NOT）。Txn-Token 自体の有効期間は、提示されたトークンの有効期限を超えてよい（MAY）。Txn-Token は短命で、特定のトランザクションを認可しているため、提示された有効期限を超えて延長されてもセキュリティ上のリスクではない、という想定である。バッチ処理やオフラインタスクのような長時間実行プロセスが関与する場合でも、外部呼び出しを行うための別の仕組みを使うことはできるが、その結果得られる Txn-Token は依然として短命である。

2.4. Benefits of Txn-Tokens

Txn-Token は、呼び出しを受け取るワークロードが、外部呼び出しが誰（ユーザーまたはワークロード）の代理で行われたか、そして呼び出し処理に関連するコンテキストを独立に検証できることを保証することで、無関係な呼び出しの防止に役立つ。

2.5. Txn-Token Issuance and Usage Flows

2.5.1. Basic Flow

図 1 は、複数ワークロード環境における Txn-Token の基本的な利用フローを示す。

        1    +--------------+    2      +--------------+
   --------->│              │---------->│              │
             │   External   │           │  Txn-Token   │
        7    │   Endpoint   │    3      │   Service    │
   <---------│              │<----------│              │
             +--------------+           +--------------+
                  │   ^
                4 v   │ 6
             +--------------+
             │              │
             │   Internal   │
             │ Microservice │
             │              │
             +--------------+
                  │   ^
                  v   │
                    o
                5   o    6
                    o
                  │   ^
                  v   │
             +--------------+
             │              │
             │   Internal   │
             │ Microservice │
             │              │
             +--------------+

              Figure 1: Basic Transaction Tokens Architecture
  1. External endpoint は、OAuth 2.0 Access Token のような従来の認可メカニズムを用いて呼び出される。
  2. External endpoint は、コンテキストおよび着信した認可情報（例：Access Token）を Txn-Token Service に提供する。
  3. Txn-Token Service は、トランザクションに対する不変のコンテキストを提供する Txn-Token を発行し、要求元へ返す。
  4. External endpoint は内部 microservice への呼び出しを開始し、認可として Txn-Token を提供する。
  5. 後続の他の内部 microservice への呼び出しでも、同じ Txn-Token を用いて呼び出しを認可する。
  6. 呼び出された microservice による認可が成功したことに基づき、呼び出し元へ応答が返される。
  7. External client には、外部呼び出しに対する応答が返される。

2.5.2. Replacement Txn-Token Flow

中間サービスは Txn-Token Service から置換 Txn-Token を取得することを決定する場合がある。そのフローを、図 2 に示す。

        1    +--------------+    2      +--------------+
   --------->│              │---------->│              │
             │   External   │           │              │
        10   │   Endpoint   │    3      │              │
   <---------│              │<----------│              │
             +--------------+           │              │
                  │   ^                 │              │
                4 v   │ 9               │              │
             +--------------+           │              │
             │              │           │              │
             │   Internal   │           │              │
             │ Microservice │           │              │
             │              │           │              │
             +--------------+           │  Txn-Token   │
                  │   ^                 │   Service    │
                  v   │                 │              │
                    o                   │              │
                5   o    9              │              │
                  │ o ^                 │              │
                  │   │                 │              │
                  v   │                 │              │
             +--------------+    6      │              │
             │              │---------->│              │
             │   Internal   │           │              │
             │ Microservice │    7      │              │
             │              │<----------│              │
             +--------------+           │              │
                  │   ^                 │              │
                  v   │                 +--------------+
                    o
                8   o    9
                    o
                  │   ^
                  v   │
             +--------------+
             │              │
             │   Internal   │
             │ Microservice │
             │              │
             +--------------+

                    Figure 2: Replacement Txn-Token Flow

上の図では、手順 1〜5 は Section 2.5.1 と同じである。

  1. 中間サービスは、置換 Txn-Token を取得する必要があると判断する。置換 Txn-Token を Txn-Token Service に要求する。リクエストには、着信した Txn-Token を含め、さらに Txn-Token Service に送信する必要がある追加コンテキストも含める。
  2. Txn-Token Service は置換 Txn-Token を返す。
  3. 置換 Txn-Token を要求したサービスは、その Txn-Token を下流の呼び出し認可に用いる。
  4. 呼び出された microservice による認可が成功したことに基づき、呼び出し元へ応答が返される。
  5. External client には、外部呼び出しに対する応答が返される。

3. Notational Conventions

本文書中のキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」は、ここに示すように全て大文字で記載される場合に限り、BCP 14（[RFC2119] [RFC8174]）で説明されるとおりに解釈される。

4. Terminology

Workload: 自律的に呼び出しを受け取り処理でき、さらに他の Workload への呼び出しを生成できる独立した計算単位。Workload の例には、コンテナ化された microservice、モノリシックなサービス、マネージド・データベースのようなインフラサービスが含まれる。

Trust Domain: 共通のセキュリティポリシーを共有するシステム、アプリケーション、または Workload の集合。実務上は、2 つ以上の Workload を含む、仮想的または物理的に分離されたネットワークを含むことがある。Trust Domain 内の Workload は、公開されたインタフェースを通じてのみ呼び出され得る。

External Endpoint: Trust Domain に対する公開インタフェースであり、Trust Domain 内の Workload の呼び出しを引き起こすもの。

Call Chain: External endpoint の呼び出しに起因して生じる、呼び出しの連鎖（シーケンス）。

Transaction Token（Txn-Token）: 短い有効期間を持つ署名付き JWT であり、ユーザーまたは Workload に関する不変の情報、呼び出しの特定パラメータ、呼び出しの特定の文脈属性を提供する。Txn-Token は、呼び出しチェーンにおける後続の呼び出しを認可するために使用される。

Authorization Context: 呼び出しチェーンの不変コンテキストを表す一連のクレームを含む JSON オブジェクト。

Transaction Token Service（Txn-Token Service）: Trust Domain 内の特別なサービスであり、要求元 Workload に Txn-Token を発行する。Txn-Token を使用する各 Trust Domain には、論理的にちょうど 1 つの Txn-Token Service が存在しなければならない（MUST）。

5. Txn-Token Format

Txn-Token は、JSON Web Signature（[RFC7515]）により保護された JSON Web Token（[RFC7519]）である。以下では Txn-Token に必要な値を説明する。

5.1. JWT Header

JWT Header では、次が適用される。

  • typ Header Parameter は存在しなければならず（MUST）、値は txntoken+jwt でなければならない（MUST）。
  • 署名鍵のキーローテーションは、kid Header Parameter を用いてサポートされるべきである（SHOULD）。

図 3 は、Txn-Token の JWT Header の非規範的な例である。

{
  "typ": "txntoken+jwt",
  "alg": "RS256",
  "kid": "identifier-to-key"
}

Figure 3: Example: Txn-Token Header

5.2. JWT Body Claims

トランザクション・トークンのボディは JWT 形式に従い、既存の JWT クレームに加えて新たなクレームを定義する。これらのクレームを以下に示す。

iss: OPTIONAL\ [RFC7519] で定義された iss クレームは必須ではない。Txn-Token は aud クレームにより定義される単一の Trust Domain に束縛され、署名鍵も既知であることが多いためである。署名鍵が事前に決まっていない場合、または Txn-Token Service が固有の鍵で署名することが望ましい場合には、iss クレームを使用しなければならない（MUST）。

iat: REQUIRED\ [RFC7519] で定義された、Txn-Token の発行時刻。

aud: REQUIRED\ [RFC7519] で定義されたこのクレームは、Txn-Token が有効となる Trust Domain を識別する。この識別子は、Txn-Token が現在の Trust Domain の外で受け入れられることを防ぐために、Trust Domain を一意に識別しなければならない（MUST）。

exp: REQUIRED\ [RFC7519] で定義された、Txn-Token の有効期限。

txn: REQUIRED\ [RFC8417] の Section 2.2 で定義された、一意のトランザクション識別子。

sub: REQUIRED\ aud Trust Domain の文脈における主体の一意な識別子。OpenID Connect とは異なり、sub クレームは iss クレームと関連付けられない（NOT）。

purp: REQUIRED\ このトランザクションの目的または意図を定義する文字列。

tctx: OPTIONAL\ 呼び出しチェーン全体を通じて不変のままである値を含む JSON オブジェクト。

rctx: OPTIONAL\ 要求されたトランザクションの環境コンテキストを記述する JSON オブジェクト。

5.2.1. Purpose claim

purp クレームは、この特定のトランザクションの正確な目的を捉える。これは、外部クライアントに発行される scope 値よりも、しばしばはるかに狭い。これは、ほとんどの場合、Trust Domain 内の認可モデルが、Trust Domain 外部のクライアントに対して使われる認可モデルとは大きく異なるためである。したがって、外部クライアントに対して用いられる（多くは比較的粗粒度な）scope の概念と、Trust Domain 内で用いられるトランザクションの目的の概念を分離することは意図的である。特定のデプロイメントが Trust Domain 内の認可モデルをどのように表現するかは、本仕様のスコープ外である。

5.2.2. Requester Context

Txn-Token は rctx クレームを含めるべきである（SHOULD）。これには、発信元ユーザーの IP アドレス情報に加え、Txn-Token を要求した計算主体に関する情報、そして発信元リクエストそのものの文脈属性が含まれ得る（MAY）。

rctx クレームの JSON 値には、Txn-Token Service が Txn-Token に依存する下流サービスにとって重要だと判断する任意の値を含めてよい（MAY）。以下のクレームは、含められる場合には次の意味を持つよう定義される。

  • req_ip: 要求者の IP アドレス。これは End-User、またはトランザクションを要求したロボットプロセスであり得る（MAY）。
  • authn: 要求者を識別するために用いられた認証方式。値は、使用された方式を一意に識別する StringOrURI である。
  • req_wl: 要求元 Workload。Txn-Token を要求した計算主体を一意に識別する StringOrURI。この主体は Txn-Token の Trust Domain 内に存在しなければならない（MUST）。置換 Txn-Token が要求された場合、このクレームは、トランザクション処理の一部として Txn-Token を要求した各 Workload を表す StringOrURI の配列となる。

5.2.3. Transaction Context

Txn-Token は tctx クレームを含めるべきである（SHOULD）。このクレームの値は、名前／値の組（値自体がオブジェクトであってもよい）を含む JSON オブジェクトであり、それらが一体となって、この Txn-Token が使用される呼び出しチェーン全体で不変のままである詳細を表明する。

Txn-Token は主としてトランザクションのアイデンティティとコンテキストを保証するために使用され、このフィールドの内容はそのコンテキストの重要な部分である。

rctx フィールドがリクエストに関連する環境値を含むのに対し、tctx フィールドは TTS によって決定される実際の認可詳細を含む。これらの値は、Txn-Token を使用するサービスが作業を行うために必要な特定パラメータを信頼できる形で取得するために用いられる。tctx フィールドの内容は Txn-Token Service によって決定され、内部で計算されたもの、または Txn-Token を要求するサービスから受け取ったパラメータに基づくものであり得る。

以下は、tctx クレームの非規範的な例である。

"tctx": {
  "action": "BUY", // 外部呼び出しのパラメータ
  "ticker": "MSFT", // 外部呼び出しのパラメータ
  "quantity": "100", // 外部呼び出しのパラメータ
  "customer_type": { // 外部呼び出しには存在しない計算済み値
    "geo": "US",
    "level": "VIP"
  }
}
5.2.3.1. Requesting Workload Identifier

Txn-Token を要求した Workload の集合を追跡できることは有用である。req_wl クレームにより、置換 Txn-Token の要求を経た後であっても、この情報を追跡できる。既定では、req_wl は Txn-Token を要求した元の Workload 主体を表す StringOrURI である。しかし、トランザクションを処理する経路上の Workload が置換 Txn-Token を要求した場合、Transaction Token Service は req_wl クレームにおいて、新たな要求元 Workload を配列の後続要素として追加する。これにより、どのサービスが置換 Txn-Token を要求したかを追跡するための「経路」メカニズムが提供される。req_wl の値が 1 つだけの場合、req_wl は StringOrURI となる。値が複数ある場合、req_wl は StringOrURI の配列として表現される。

{
  "rctx": {
    "req_ip": "69.151.72.123", // 外部呼び出しの環境コンテキスト
    "authn": "urn:ietf:rfc:6749", // 外部呼び出しの環境コンテキスト
    "req_wl": [
      "apigateway.trust-domain.example",
      "workload3.trust-domain.example"
    ]
  }
}

5.2.4. Example

下の図 4 は、Txn-Token の JWT ボディの非規範的な例である。

{
  "iat": 1686536226,
  "aud": "trust-domain.example",
  "exp": 1686536586,
  "txn": "97053963-771d-49cc-a4e3-20aad399c312",
  "sub": "d084sdrt234fsaw34tr23t",
  "rctx": {
    "req_ip": "69.151.72.123", // 外部呼び出しの環境コンテキスト
    "authn": "urn:ietf:rfc:6749", // 外部呼び出しの環境コンテキスト
    "req_wl": "apigateway.trust-domain.example" // Txn-Token を要求した内部主体
  },
  "purp": "trade.stocks",
  "tctx": {
    "action": "BUY", // 外部呼び出しのパラメータ
    "ticker": "MSFT", // 外部呼び出しのパラメータ
    "quantity": "100", // 外部呼び出しのパラメータ
    "customer_type": { // 外部呼び出しには存在しない計算済み値
      "geo": "US",
      "level": "VIP"
    }
  }
}

Figure 4: Example: Txn-Token Body

6. Txn-Token Service

Txn-Token Service は、Txn-Token 発行要求に応答できる OAuth 2.0 Token Exchange（[RFC8693]）endpoint のプロファイルを実装する。Txn-Token を取得するには、OAuth 2.0 Token Exchange（[RFC8693]）仕様のこのプロファイルを使用しなければならない（MUST）。Txn-Token のリクエストとレスポンスが持つ固有の性質について、以下で説明する。Txn-Token Service は、他の OAuth 2.0 endpoint や機能を任意でサポートしてもよい（MAY）が、それは Txn-Token Service であるための要件ではない。

Txn-Token を使用する各 Trust Domain は、論理的にちょうど 1 つの Txn-Token Service を持たなければならない（MUST）。

7. Requesting Txn-Tokens

Workload は、OAuth 2.0 Token Exchange（[RFC8693]）のプロファイルを用いて Transaction Token Service へ Txn-Token を要求する。Txn-Token は、外部から発生するリクエストと、内部から発生するリクエストの双方に対して要求され得る。このプロファイルは、Txn-Token を発行するために必要な（required）および任意（optional）のコンテキストを Transaction Token Service に提供する方法を説明する。この方法を用いて Txn-Token を取得するリクエストは Txn-Token Request と呼ばれ、成功応答は Txn-Token Response と呼ばれる。OAuth 2.0 Token Exchange（[RFC8693]）の Txn-Token プロファイルを以下に示す。

7.1. Txn-Token Request

Txn-Token を要求する Workload は、Transaction Token Service に対して、自身のアイデンティティの証明（クライアント認証）、Txn-Token の目的、そして任意で実行中のトランザクションに関連する追加コンテキストを提供しなければならない（must）。これらの要素の大部分は OAuth 2.0 Token Exchange 仕様で提供され、残りは新たなパラメータとして定義される。さらに、このプロファイルは新しい token type URN urn:ietf:params:oauth:token-type:txn_token を定義し、要求元 Workload が Txn-Token Response に Txn-Token を含めるよう要求していることを識別するために用いる。

Txn-Token を要求するために、Workload は OAuth 2.0（[RFC6749]）token endpoint を次のパラメータで呼び出す。

  • grant_type REQUIRED. 値は urn:ietf:params:oauth:grant-type:token-exchange に設定されなければならない（MUST）。
  • audience REQUIRED. 値は Trust Domain 名に設定されなければならない（MUST）。
  • scope REQUIRED. 大文字小文字を区別する文字列の、スペース区切りのリストであり、値はトランザクションの具体的な目的または意図を表さなければならない（MUST）。
  • requested_token_type REQUIRED. 値は urn:ietf:params:oauth:token-type:txn_token でなければならない（MUST）。

  • subject_token REQUIRED. 値はトランザクションの主体を表さなければならない（MUST）。これは次のいずれかでよい（MAY）。

    • API Gateway が受け取った受信トークン
    • トランザクションを開始する Workload が構築した自己署名 JWT
    • トランザクションを開始する Workload が構築した署名なし JSON オブジェクト
    • Txn-Token Service が理解できるその他の形式

    subject_token フィールドの型は subject_token_type により識別される。

  • subject_token_type REQUIRED. 値は、subject_token パラメータに存在するトークンまたは値の型を示さなければならない（MUST）。

以下の追加パラメータは、Txn-Token Request に存在してもよい（MAY）。

  • request_context OPTIONAL. このパラメータは、トランザクションのコンテキストを表す base64url エンコードされた JSON オブジェクトを含む。このパラメータは存在するべきであり（SHOULD）、Transaction Token Service がこのパラメータをどのように使用するかは本仕様のスコープ外である。
  • request_details OPTIONAL. このパラメータは、複数 Workload によるトランザクション処理の全期間を通じて不変でなければならない（MUST）トランザクションの追加詳細を表す base64url エンコードされた JSON オブジェクトを含む。Transaction Token Service はこの情報を用いて tctx クレームを構築する。

要求元 Workload は、Transaction Token Service に対して自身のアイデンティティを認証しなければならない（MUST）。使用されるクライアント認証メカニズムの正確な内容は、本仕様のスコープ外である。

下の図 5 は、Txn-Token Request の非規範的な例を示す。

POST /txn-token-service/token_endpoint HTTP 1.1
Host: txn-token-service.trust-domain.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Atxn-token
&audience=http%3A%2F%2Ftrust-domain.example
&scope=finance.watchlist.add
&subject_token=eyJhbGciOiJFUzI1NiIsImtpZC...kdXjwhw
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
&request_context=eyAiaXBfYWRkcmVzcyI6ICIxMjcuMC4wLjEiLCAiY2xpZW50IjogIm1vYmlsZS1hcHAiLCAiY2xpZW50X3ZlcnNpb24iOiAidjExIiB9

Figure 5: Example: Txn-Token Request

7.2. Subject Token Types

subject_token_type パラメータの値は URI（[RFC3986]）でなければならない（MUST）。これは次のいずれかでよい（MAY）。

  • OAuth 2.0 Token Exchange（[RFC8693]）の Section 3 で説明される subject token type のうち、Refresh Token タイプ（すなわち urn:ietf:params:oauth:token-type:refresh_token）を除くもののいずれか。
  • subject token が自己署名 JWT である場合に用いられる URN 型名（後述）。
  • subject token が署名なし JSON オブジェクトである場合に用いられる URN 型名（後述）。
  • 要求者と Txn-Token Service の間で合意されたカスタム URN。Txn-Token Service は、他のトークン形式もサポートしてよく（MAY）、それらは subject_token_type パラメータで指定され得る（MAY）。

7.2.1. Self-Signed Subject Token Type

要求者は、subject_token の値として自己署名 JWT を使用してよい（MAY）。その場合、要求者は subject_token_type の値を urn:ietf:params:oauth:token-type:self_signed に設定しなければならない（MUST）。この自己署名 JWT は、次のクレームを含まなければならない（MUST）。

  • iss: 要求元 Workload の一意な識別子。Txn-Token Service は、この値を用いて、このリクエストへの応答として発行される Txn-Token の req_wl 値を決定する（SHALL）。
  • sub: Txn-Token を要求している主体。Txn-Token Service は、この値を用いて、このリクエストへの応答として発行される Txn-Token の sub 値を決定する（SHALL）。
  • aud: Txn-Token Service の一意な識別子。Txn-Token Service は、この値が自身の一意な識別子と一致することを検証する（SHALL）。
  • iat: 自己署名 JWT が作成された時刻。Txn-Token Service は、iat 値が不合理に過去または未来である自己署名トークンを拒否する場合がある。
  • exp: JWT の有効期限。この期間は、JWT の悪用を防ぐために非常に短く（秒のオーダー）すべきである。

自己署名 JWT は、他のクレームを含んでもよい（MAY）。

7.2.2. Unsigned JSON Object Subject Token Type

要求者は、subject_token の値として署名なし JSON オブジェクトを使用してよい（MAY）。その場合、要求者は subject_token_type の値を urn:ietf:params:oauth:token-type:unsigned_json に設定しなければならない（MUST）。subject_token フィールドの値は、[RFC6848] の Section 5 に記載された JSON オブジェクトの BASE64URL エンコード値でなければならない（MUST）。subject token 内の JSON オブジェクトは、次のフィールドを含まなければならない（MUST）。

  • sub: Txn-Token を要求している主体。Txn-Token Service は、この値を用いて、このリクエストへの応答として発行される Txn-Token の sub 値を決定する（SHALL）。
  • exp: 署名なし JSON オブジェクトの有効期限。TTS は、Txn-token の有効期間を決定するための入力としてこの値を使用してよい（MAY）。

署名なし JSON オブジェクトは他のフィールドを含んでもよく（MAY）、Txn-Token Service は Txn-Token を生成する際にそれらを考慮してもよい（MAY）。

7.3. Txn-Token Request Processing

Transaction Token Service が Txn-Token Request を受け取った場合、要求元 Workload のクライアント認証を検証しなければならず（MUST）、その Workload が要求された値を持つ Txn-Token を取得する権限を持つかどうかを判断しなければならない（MUST）。そのような発行可否を判断するための認可ポリシーは、本仕様のスコープ外である。

次に、Transaction Token Service は subject_token を検証し（MUST）、発行される Txn-Token の sub として指定する値を決定しなければならない（MUST）。Txn-Token Service は、sub 値が aud クレームで定義される Trust Domain 内で一意であることを保証しなければならない（MUST）。

Transaction Token Service は、iat クレームを Txn-Token の発行時刻に設定しなければならない（MUST）。

Transaction Token Service は、aud クレームを Transaction Token Service の Trust Domain を表す識別子に設定しなければならない（MUST）。Transaction Token Service が複数の Trust Domain をサポートする場合、このリクエストに対する正しい aud 値を決定しなければならない（MUST）。

Transaction Token Service は、exp クレームを Txn-Token の有効期限に設定しなければならない（MUST）。Txn-Token Service は、結果の Txn-Token の exp 値を決定する際に、Txn-Token Request の subject_token パラメータに存在する exp 値を考慮してよい（MAY）。

Transaction Token Service は、txn クレームをこのトランザクション固有の一意な ID に設定しなければならない（MUST）。

Transaction Token Service は、Txn-Token の iss クレームを、Txn-Token に署名した主体を定義する値に設定してよい（MAY）。このクレームは、設定しない場合は省略しなければならない（MUST）。

Transaction Token Service は、リクエストの scope パラメータに指定された値を評価し（MUST）、発行される Txn-Token の purp クレームを決定しなければならない（MUST）。

Txn-Token Request に request_context パラメータが存在する場合、そのデータは Txn-Token の rctx オブジェクトに追加されるべきである（SHOULD）。加えて、Transaction Token Service は、認証済みの要求元 Workload 識別子を rctx オブジェクト内の req_wl クレームとして追加するべきである（SHOULD）。

Txn-Token Request に request_details パラメータが存在する場合、Transaction Token Service は、要求元クライアントに対する Transaction Token Service の認可ポリシーにより認可される範囲で、request_details オブジェクトのデータを tctx オブジェクト内のクレームへ伝播させるべきである（SHOULD）。

Transaction Token Service は、本仕様のスコープ外となる追加の処理および検証を提供してよい（MAY）。