Transaction Tokens

oauth                                                   A. Tulshibagwale
Internet-Draft                                                      SGNL
Intended status: Standards Track                             G. Fletcher
Expires: 28 July 2026                             Practical Identity LLC
                                                            P. Kasselman
                                                        Defakto Security
                                                         24 January 2026

draft-ietf-oauth-transaction-tokens-07

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-Draft は、Internet Engineering Task Force（IETF）の作業文書である。他のグループも Internet-Draft として作業文書を配布する場合がある点に注意すること。現在の Internet-Draft の一覧は、以下にある: https://datatracker.ietf.org/drafts/current/.

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

この Internet-Draft は 28 July 2026 に失効する。

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.

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

Table of Contents

• Transaction Tokens
  • Abstract
  • Status of This Memo
  • Copyright Notice
  • Table of Contents
  • 1. Introduction
  • 2. Overview
  • 3. Notational Conventions
  • 4. Terminology
  • 5. What are Transaction Tokens?
    • 5.1. Authorization Context
  • 6. Creating Txn-Tokens
    • 6.1. Creation
  • 7. Txn-Token Lifetime
  • 8. Benefits of Txn-Tokens
  • 9. Txn-Token Issuance and Usage Flows
    • 9.1. Basic Flow
    • 9.2. Internally Initiated Txn-Token Flow
  • 10. Txn-Token Format
    • 10.1. JWT Header
    • 10.2. JWT Body Claims
      • 10.2.1. Scope claim
      • 10.2.2. Requester Context
      • 10.2.3. Transaction Context
      • 10.2.4. Example
  • 11. Txn-Token Service (TTS)
  • 12. Requesting Txn-Tokens
    • 12.1. Txn-Token Request
    • 12.2. Subject Token Types
      • 12.2.1. Self-Signed Subject Token Type
      • 12.2.2. Unsigned JSON Object Subject Token Type
    • 12.3. Txn-Token Request Processing
    • 12.4. Txn-Token Response
    • 12.5. Mutual Authentication of the Txn-Token Request
  • 13. Using Txn-Tokens
    • 13.1. Txn-Token HTTP Header
    • 13.2. Txn-Token Validation
  • 14. Security Considerations
    • 14.1. Txn-Token Lifetime
    • 14.2. Access Tokens
    • 14.3. Subject Token Types
    • 14.4. Use of 'actor_token'
    • 14.5. Scope Processing
    • 14.6. Unique Transaction Identifier
    • 14.7. TTS Discovery
    • 14.8. Workload Configuration Protection
    • 14.9. TTS Authentication
    • 14.10. TTS Key Rotation
    • 14.11. Transaction Tokens Are Not Authentication Credentials
    • 14.12. Replacing Transaction Tokens
      • 14.12.1. TTS Responsibilities
  • 15. Privacy Considerations
    • 15.1. Obfuscation of Personal Information
    • 15.2. Logging
  • 16. IANA Considerations
    • 16.1. OAuth URI Subregistry Contents
    • 16.2. JWT Claims Registry Contents
    • 16.3. IANA Media Type Registration Contents
    • 16.4. HTTP Header
  • 17. References
    • 17.1. Normative References
    • 17.2. Informative References
  • Acknowledgements
  • Authors' Addresses

1. Introduction

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

• 明示的なトランザクション呼び出しが存在しないにもかかわらず、ネットワーク内のワークロードが呼び出される。
• 任意のユーザーになりすます。
• パラメータが改ざんされる、または付加される。
• token の窃取。たとえば、外部インタフェースを呼び出すために使用され、認可コンテキストを伝えるために内部ワークロードへ渡される OAuth access tokens など。

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

2. Overview

Transaction Tokens（Txn-Token）は、上記のような攻撃または不正な呼び出し（spurious invocations）によるリスクを低減する。有効な Txn-Token は、有効なトランザクション呼び出しを示す。多くのトランザクションが外部イベント（例: インターネットに公開された API の呼び出し）により開始される一方で、信頼できるドメイン内部から開始されるトランザクションもある点に注意すること。Txn-Token は、外部トリガーのトランザクションと内部呼び出しのトランザクションの両方に適用され、ユーザーの識別情報、またはリクエストを行ったワークロードの識別情報が、その後のワークロード呼び出し全体を通じて保持されることを保証する。また、以下のようなコンテキストを保持する:

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

暗号学的に保護された Txn-Token は、下流のワークロードがこの種の情報を不正に改ざんできないこと、また不正な呼び出し（spurious calls）を行えないことを保証する。

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: 特定の目的のために実行されているソフトウェアの稼働インスタンス。ワークロードの例としては、コンテナ化されたマイクロサービス、モノリシックなサービス、そしてマネージド・データベースのようなインフラサービスが挙げられる。

Trust Domain: 共通のセキュリティ制御およびポリシー集合を共有するシステムの論理的なグルーピング。実運用では、2 つ以上のワークロードを含む、仮想的または物理的に分離されたネットワークが含まれる場合がある。Trust Domain 内のワークロードは、公開されたインタフェースを通じてのみ呼び出され得る。

External Endpoint: Trust Domain に対する公開インタフェースであり、Trust Domain 内のワークロードの呼び出しを引き起こすもの。実運用では、外部 endpoint は WIMSE アーキテクチャ [I-D.ietf-wimse-arch] に記載されている gateway service を通じてアクセスされ得る。

Call Chain: 外部 endpoint の呼び出しから生じる一連の呼び出しのシーケンス。

Transaction Token (Txn-Token): 有効期間が短い署名付き JWT。ユーザーまたはワークロードに関する不変（immutable）な情報、呼び出しの特定パラメータ、そして呼び出しに関する特定の文脈属性を提供する。Txn-Token は、呼び出しチェーン内の後続呼び出しを認可するために使用される。

Transaction Token Service (TTS): Trust Domain 内の特別なサービスであり、要求するワークロードに Txn-Token を発行する。Txn-Token を使用する各 Trust Domain は、論理的にちょうど 1 つの TTS を持たなければならない。

5. What are Transaction Tokens?

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

5.1. Authorization Context

認可コンテキストには、認可、会計（accounting）、監査（auditing）の目的で使用される情報が含まれ、しばしば実行されるリクエストに関する情報を含む。認可コンテキストの重要な側面は、トランザクションの意図（intent）または目的（purpose）であり、与えられたデプロイメントにおいて可能な限り狭く定義されるべきである。スコープが狭い transaction token は、捕捉され再送（replay）された transaction tokens の攻撃対象領域（attack surface）を低減する。

6. Creating Txn-Tokens

6.1. Creation

Txn-Token は通常、外部から可視な endpoint を用いてワークロードが呼び出され、かつ OAuth [RFC6749] access token のような別の仕組みにより認可されるときに作成される。外部から可視な endpoint は、ワークロードへ送る前に、外部の認可 token を transaction token と交換する。transaction token はローカルなインタフェースで取得してもよいし、リモートサーバーへリクエストしてもよい。

transaction token のリクエストが HTTP を介してリモートサーバーに対して行われる場合、本仕様で記載する [RFC8693] を使用しなければならない。これを行うために、特別な Token Service（Transaction Token Service（TTS））を呼び出し、Txn-Token を生成するのに十分なコンテキストを提供する。

TTS に提供されるコンテキスト情報には、以下を含めなければならない:

• 発行される Txn-Token が有効となる trust domain の識別
• Txn-Token の subject を識別する token（例: OAuth access token、self-issued JWT など）
• 発行される Txn-Token に望む authorisation scope

追加のコンテキスト情報として、以下を提供してもよい:

• この呼び出しの間、完全性（integrity）保護が要求されるパラメータ
• incoming IP アドレス、User Agent 情報、あるいは TTS が Txn-Token を発行する上で役立つその他のコンテキストなどの追加情報

TTS は、成功した呼び出しに対して Txn-Token を生成して応答する。呼び出し元のワークロードは、その後 Txn-Token を用いて後続ワークロードへの呼び出しを認可する。

リクエストするサービスが、TTS へのリクエストで使用できる inbound token を持たない場合、そのサービスは self-signed JWT を生成し、外部の認可 token の代わりにリクエストに含めて渡す。これは、外部の認証で access token を使用しない場合や、リクエストするサービスが、システム内のユーザーのため、またはシステム自身のためにスケジュールされた内部リクエストを開始している場合に起こり得る。

7. Txn-Token Lifetime

Txn-Token は短命（数分程度またはそれ以下）であることが想定されており、その結果、外部または内部呼び出しの想定される期間に限って使用しなければならない。Txn-Token を要求するときに TTS に提示する token または他の credential（例: self-signed JWT）に有効期限がある場合、期限が過ぎているときには TTS は Txn-Token を発行してはならない。Txn-Token 自体の有効期間は、提示された token の有効期限を超えてよい。Txn-Token は短命であり特定のトランザクションを認可するものであるため、提示された有効期限を超えることはセキュリティ上のリスクではない、という期待に基づく。バッチやオフラインタスクのような長時間実行プロセスが関与する場合でも、外部または内部呼び出しを行うための仕組みは、短命な Txn-Token を得るようにしなければならない。

8. Benefits of Txn-Tokens

Txn-Token は、ワークロードが、外部呼び出しを開始したユーザーまたはワークロードの識別情報、ならびにその呼び出しの処理に関連する任意のコンテキスト情報を独立に検証できるようにすることで、不正または意図しない呼び出しを防止する。

9. Txn-Token Issuance and Usage Flows

9.1. Basic Flow

Figure 1 は、複数ワークロード環境で Txn-Token がどのように使われるかの基本フローを示す。

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

              Figure 1: Basic Transaction Tokens Architecture

1. External endpoint は、OAuth 2.0 Access token のような従来の認可メカニズムを用いて呼び出される。

2. External endpoint は、コンテキストと incoming authorization（例: access token）を TTS に渡す。

3. TTS は、トランザクションの不変（immutable）なコンテキストを提供する Txn-Token を発行（mint）し、リクエスト元に返す。

4. External endpoint は内部ワークロードへの呼び出しを開始し、認可として Txn-Token を提供する。

5. 他の内部ワークロードへの後続呼び出しは、同じ Txn-Token を用いて呼び出しを認可する。

6. 呼び出されたワークロードで認可が成功したことに基づいて、呼び出し元のワークロードへレスポンスが返される。

7. 呼び出されたワークロードで認可が成功したことに基づいて、External endpoint へレスポンスが返される。

8. External client は外部呼び出しに対するレスポンスを受け取る。

9.2. Internally Initiated Txn-Token Flow

内部ワークロードは、現在の外部リクエストに基づかず、スケジュールされたタスクの一部として、または特定条件への反応としてトランザクションを開始する必要がある場合がある。そのトランザクションは、リクエストするワークロード自身の識別情報として、またはワークロードが参照可能な情報に基づいて選択された特定ユーザーになりすましたものとして要求され得る。

           1 ┌──────────────┐    2      ┌──────────────┐
             │              ├───────────▶              │
             │   Internal   │           │  Txn-Token   │
             │   Workload   │    3      │   Service    │
             ┤              ◀───────────│              │
             └────┬───▲─────┘           └──────────────┘
                  │   │
                4 │   │ 7
             ┌────▼───┴─────┐
             │              │
             │   Internal   │
             │   Workload   │
             │              │
             └────┬───▲─────┘
                  │   │
                  ▼   │
                    o
                5   o    6
                  │ o ▲
                  │   │
                  │   │
             ┌────▼───┴─────┐
             │              |
             │   Internal   │
             │   Workload   │
             │              |
             └──────────────┘

               Figure 2: Internally Initiated Txn-Token Flow

上図において、手順 5-6 は Section 9.1 と同一である。

1. マイクロサービスは、スケジュールされたタイマーまたはその他のトリガーに応じて、ユーザーのためにリクエストを開始する必要があると判断する。

2. 内部マイクロサービスは token service に対して認証し、Txn-Token のリクエストを行う。リクエストには、トランザクションに関する情報と、任意の追加の認可 credential が含まれる。

3. TTS はリクエスト元を認可し、トランザクションの不変（immutable）なコンテキストを提供する Txn-Token を発行（mint）して、リクエスト元に返す。

4. 元のマイクロサービスは別の内部マイクロサービスへ連絡し、認可として Txn-Token を提供する。

10. Txn-Token Format

Txn-Token は JSON Web Token [RFC7519] であり、JSON Web Signature [RFC7515] によって保護される。以下は Txn-Token における必須値を説明する。

10.1. JWT Header

JWT Header において:

• typ Header Parameter は存在しなければならず、値は txntoken+jwt でなければならない。
• 署名鍵の key rotation は、kid Header Parameter を用いてサポートされるべきである。

Figure 3 は Txn-Token の JWT Header の非規範的（non-normative）な例である。

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

Figure 3: Example: Txn-Token Header

10.2. JWT Body Claims

transaction token の本文は JWT 形式に従い、既存の JWT claims を含むとともに新しい claims も定義する。これらの claims を以下に示す。

• iss: OPTIONAL。 [RFC7519] で定義された iss claim は、Txn-Token が aud claim によって定義される単一の Trust Domain に束縛され、かつ署名鍵が既知であることが多いため、必須ではない。ただし、署名鍵が事前に定まっていない場合には iss claim を使用しなければならない。

• iat: REQUIRED。 [RFC7519] で定義された Txn-Token の issued at time。

• aud: REQUIRED。 [RFC7519] で定義されたこの claim は、Txn-Token が有効となる Trust Domain を識別しなければならない。Txn-Token は、aud claim によって識別された Trust Domain の外部では受け入れられてはならない。

• exp: REQUIRED。 [RFC7519] で定義された Txn-Token の Expiry time。

• txn: REQUIRED。 [RFC8417] の Section 2.2 で定義された一意な transaction identifier。

• sub: REQUIRED。 この claim は [RFC7519] の Section 4.1.2 で定義されるトランザクションの principal を表す。値は、aud Trust Domain のコンテキスト内で一意でなければならない。注: OpenID Connect とは異なり、sub claim は iss claim と関連付けられない。

• scope: REQUIRED。 scope claim は [RFC8693] の Section 4.2 で定義される。なお、この claim の値は TTS により決定され、要求された scope や、供給された外部 token に含まれる scope と一致する必要はない。

• tctx: OPTIONAL。 呼び出しチェーン全体を通じて不変（immutable）である値を含む JSON object。

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

• req_wl: REQUIRED。 Txn-Token をリクエストした workload を識別する StringOrURI 値。

10.2.1. Scope claim

scope claim は、この特定のトランザクションの目的を、可能な限り狭く捉える。ここで使用される値は、Trust Domain が定義する認可モデルを代表するものとして TTS により定義される。この値は、外部 client に発行された scope 値とは、字義的にも意味的にも異なり得るし、外部 client に発行されたものより狭い意図を表すこともあり得る。特定のデプロイメントが、Trust Domain 内でどのように認可モデルを表現するかは、その裁量に委ねられており、本仕様では規定しない。

10.2.2. Requester Context

Txn-Token には rctx claim を含めるべきである。これには、元の requestor の IP アドレス情報に加え、Txn-Token をリクエストした計算主体（computational entity）に関する情報、ならびに元リクエスト自体の文脈属性が含まれ得る。

rctx claim の JSON 値には、Txn-Token に依存する下流サービスにとって有用だと TTS が判断する任意の値を含めてもよい。以下の claims は、含まれる場合に次の意味を持つように定義される:

• req_ip: リクエスト元の IP アドレス。これは end-user である場合も、Transaction を開始したプロセスである場合もある。
• authn: リクエスト元を識別するために使用された認証方法。その値は、使用された方法を一意に識別する string である。

以下は、外部呼び出しによって開始された rctx claim の非規範的な例である:

{
  "rctx": {
    "req_ip": "69.151.72.123",
    "authn": "urn:ietf:rfc:6749"
  }
}

10.2.3. Transaction Context

Txn-Token には tctx claim を含めるべきである。この claim の値は JSON object であり、名前/値のペア（値自体が object である場合もある）を含む。これらはまとめて、この Txn-Token が使用される呼び出しチェーンを通じて不変（immutable）である詳細を表明する。

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

rctx フィールドがリクエストに関連する環境値を含むのに対し、tctx フィールドは TTS により決定される実際の authorizaton details を含む。これらの値は、Txn-Token を用いるサービスが、自身の作業に必要な特定パラメータを確実に得るために使用される。tctx フィールドの内容は TTS により決定され、内部で計算される場合もあれば、Txn-Token を要求するサービスから受け取ったパラメータから計算される場合もある。

以下は、外部呼び出しによって開始された tctx claim の非規範的な例である:

"tctx": {
  "action": "BUY",
  "ticker": "MSFT",
  "quantity": "100",
  "customer_type": {
    "geo": "US",
    "level": "VIP"
  }
}

10.2.4. Example

Figure 4 の下の図は、外部呼び出しによって開始された Txn-Token の JWT body の非規範的な例である:

{
  "iat": 1686536226,
  "aud": "trust-domain.example",
  "exp": 1686536586,
  "txn": "97053963-771d-49cc-a4e3-20aad399c312",
  "sub": "d084sdrt234fsaw34tr23t",
  "req_wl": "apigateway.trust-domain.example",
  "rctx": {
    "req_ip": "69.151.72.123",
    "authn": "urn:ietf:rfc:6749"
  },
  "scope": "trade.stocks",
  "tctx": {
    "action": "BUY",
    "ticker": "MSFT",
    "quantity": "100",
    "customer_type": {
      "geo": "US",
      "level": "VIP"
    }
  }
}

Figure 4: Example: Txn-Token Body

内部リクエストからの Txn-Token もほぼ同様であるが、rctx および tctx のフィールド claims は、開始元 workload のリクエストに由来する情報で埋められる。

11. Txn-Token Service (TTS)

Txn-Token Service（TTS）が HTTP リクエストに応答して transaction tokens を発行する場合、本仕様で記載する [RFC8693] を使用する。Txn-Token のリクエストおよびレスポンスに固有の性質を以下に示す。TTS は任意で他の OAuth 2.0 endpoints や機能をサポートしてもよいが、TTS であるためにそれは要件ではない。

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

12. Requesting Txn-Tokens

workload は TTS から Txn-Token を要求する。transaction token のリクエストが HTTP を介してリモートサーバーに対して行われる場合、本仕様で記載する [RFC8693] を使用しなければならない。Txn-Token は、外部起点のリクエストと内部起点のリクエストの両方について要求され得る。このプロファイルは、Txn-Token を発行するために必要なコンテキストおよび任意のコンテキストを TTS にどのように提供できるかを記述する。この方法で Txn-Token を取得するリクエストは Txn-Token Request と呼ばれ、成功時のレスポンスは Txn-Token Response と呼ばれる。OAuth 2.0 Token Exchange [RFC8693] の Txn-Token プロファイルを以下に示す。

12.1. Txn-Token Request

Txn-Token を要求する workload は、自身の識別情報の証明（client authentication）、Txn-Token の目的、そして任意で実行されるトランザクションに関する追加コンテキストを TTS に提供する。これらの要素の多くは OAuth 2.0 Token Exchange 仕様で提供され、残りは新しい parameters として定義される。さらに、このプロファイルは新しい 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 を以下の parameters で呼び出す:

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

• subject_token REQUIRED。 値には、トランザクションの subject を表す token を含めなければならない。subject を subject_token でどのように表すかは subject_token_type に依存する。subject_token は以下であり得る:

  • external endpoint が受け取った inbound token（例: API Gateway）
  • トランザクションを開始する workload が構築した self-signed JWT
  • トランザクションを開始する workload が構築した unsigned JSON object
  • それ以外の、TTS が理解できる任意の形式

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

• subject_token_type REQUIRED。 値は subject_token parameter に存在する token または値の型を示さなければならない。

以下の追加 parameters は、Txn-Token Request に存在することが推奨される:

• request_context OPTIONAL。 この parameter は、このトランザクションのコンテキストを表す JSON object を含む。
• request_details OPTIONAL。 この parameter は、リクエストに関する追加詳細を含む JSON object を含む。これには API parameters、認可基準、またはリクエスト元が TTS に渡したいその他の詳細が含まれ得る。TTS はこのデータと、利用可能な他の情報を併用して txct JSON object（必要な場合）を構築する。

すべての parameters は、[RFC6749] の Appendix B に従って "application/x-www-form-urlencoded" 形式でエンコードされる。

Figure 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=%7B%0A%20%20%20%20%20%20%22req_ip%22%3A%20%2269.151.72.123%22%2C%20%2F
%2F%20env%20context%20of%20external%20call%0A%20%20%20%20%20%20%22authn%22%3A%20%22urn
%3Aietf%3Arfc%3A6749%22%2C%20%2F%2F%20env%20context%20of%20external%20call%0A%20%20%20
%20%20%20%22workload3.trust-domain.example%22%20%5D%0A%20%20%20%20%7D

Figure 5: Example: Txn-Token Request

12.2. Subject Token Types

subject_token_type parameter の値は URI [RFC3986] でなければならない。これは以下であり得る:

• OAuth 2.0 Token Exchange [RFC8693] の Section 3 に記載された subject token types のいずれか（ただし Refresh Token type、すなわち urn:ietf:params:oauth:token-type:refresh_token を除く）。

• subject token が self-signed JWT である場合の URN 型名（以下で説明する）。

• subject token が unsigned JSON object である場合の URN 型名（以下で説明する）。

• リクエスト元と TTS の間で合意されたカスタム URN。TTS は他の token 形式をサポートしてもよく、その場合は subject_token_type parameter により指定され得る。

12.2.1. Self-Signed Subject Token Type

リクエスト元は subject_token 値として self-signed JWT を使用してもよい。その場合、リクエスト元は subject_token_type 値を urn:ietf:params:oauth:token-type:self_signed に設定しなければならない。この self-signed JWT には以下の claims を含めなければならない:

• iss: リクエスト元 workload の一意な識別子。

• sub: Txn-Token が要求されている subject。TTS は、このリクエストへのレスポンスで発行される Txn-Token の sub 値を決定する際に、この値を使用する。

• aud: TTS の一意な識別子。TTS は、この値が自らの一意な識別子と一致することを検証しなければならない。

• iat: self-signed JWT が作成された時刻。TTS は、iat 値が過去または未来に不合理に離れている self-signed tokens を拒否する場合がある点に注意すること。

• exp: JWT の有効期限。Section 14.1 は Txn-Token の有効期限設定に関する指針を提供する。

この self-signed JWT には他の claims を含めてもよい。

12.2.2. Unsigned JSON Object Subject Token Type

リクエスト元は subject_token 値として unsigned JSON object を使用してもよい。その場合、リクエスト元は subject_token_type 値を urn:ietf:params:oauth:token-type:unsigned_json に設定しなければならない。subject token 内の JSON object には以下の fields を含めなければならない:

• sub: Txn-Token が要求されている subject。TTS は、このリクエストへのレスポンスで発行される Txn-Token の sub 値を決定する際に、この値を使用する。

unsigned JSON object には他の fields を含めてもよく、TTS は Txn-Token を生成する際にそれらを考慮してもよい。

12.3. Txn-Token Request Processing

TTS が Txn-Token Request を受け取ったとき、以下を行う:

• リクエスト元 workload の client authentication を検証し、その workload が要求された値の Txn-Token を取得する権限を持つかどうかを判断しなければならない。この発行可否を判断するための認可ポリシーは、本仕様のスコープ外である。

• 次に、TTS は subject_token を検証しなければならない。subject_token が署名されている場合には署名の検証を含む。

• TTS は Txn-Token の sub として指定する値を決定しなければならず、その sub 値が aud claim によって定義される Trust Domain 内で一意であることを保証しなければならない。

• TTS は iat claim を Txn-Token の発行時刻に設定しなければならない。

• TTS は aud claim を、TTS の Trust Domain を表す識別子に設定しなければならない。TTS が複数の Trust Domain をサポートする場合、TTS はこのリクエストに対する正しい aud 値を決定しなければならない。

• TTS は exp claim を Txn-Token の有効期限に設定しなければならない。TTS は、exp 値を決定する際に、Txn-Token Request の subject_token parameter に存在する任意の exp 値を考慮してもよい。

• TTS は txn claim を、このトランザクション固有の一意な ID に設定しなければならない。

• TTS は、Txn-Token の iss claim を、Txn-Token に署名した主体を定義する値に設定してもよい。この claim を設定しない場合、iss claim は省略しなければならない。

• TTS は、リクエストの scope parameter に指定された値を評価して、発行する Txn-Token の scope claim を決定しなければならない。

• Txn-Token Request に request_context parameter が存在する場合、そのデータは Txn-Token の rctx object に追加されるべきである。

• Txn-Token Request に request_details parameter が存在する場合、TTS は request_details object のデータを、リクエスト元 client に対する TTS の認可ポリシーにより許可される範囲で、tctx object 内の claims に伝播させるべきである。

TTS は、本仕様のスコープ外である追加の処理や検証を行ってもよい。

12.4. Txn-Token Response

TTS による Txn-Token Request への成功レスポンスは Txn-Token Response と呼ばれる。 [RFC8693] で定義された以下の値は、Txn-Token Response に含めなければならない:

• token_type 値は、OAuth 2.0 Token Exchange [RFC8693] の指針に従い N_A に設定されなければならない。

• access_token 値は Txn-Token JWT でなければならない。

• issued_token_type 値は urn:ietf:params:oauth:token-type:txn_token に設定されなければならない。

Txn-Token Response には refresh_token 値を含めてはならない。

TTS がエラーを返す場合、エラーレスポンスは [RFC6749] の Section 5.2 に記載されるとおりである。

Figure 6 は Txn-Token Response の非規範的な例を示す。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "token_type": "N_A",
  "issued_token_type": "urn:ietf:params:oauth:token-type:txn_token",
  "access_token": "eyJCI6IjllciJ9...Qedw6rx"
}

Figure 6: Example: Txn-Token Response

12.5. Mutual Authentication of the Txn-Token Request

TTS とリクエスト元 workload は、互いに認証しなければならない（mutual authentication）。workload は、OAuth Access Token などの機微情報を不正な TTS に開示しないよう、TTS を認証しなければならない。TTS は、workload が transaction token を要求する権限を持つことを保証するために、workload を認証しなければならない。

workload は、通信チャネルを保護して TTS を認証するために https scheme を使用するべきである。https を使用する場合、TLS 証明書は [RFC9110] の Section 4.3.4 に従って検証されなければならない。本書執筆時点では、TLS version 1.3 [RFC8446] が最新バージョンである。

workload は、[RFC7523] に従い、非対称（公開鍵ベース）の方法、または署名付き client authentication JWT を用いて Transaction Token Server に認証するべきである。

公開鍵ベースの認証の例としては、OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens [RFC8705]、Workload Authentication Using Mutual TLS [I-D.ietf-wimse-mutual-tls]、WIMSE Workload-to-Workload Authentication with HTTP Signatures [I-D.ietf-wimse-http-signature]、および WIMSE Workload Proof Token [I-D.ietf-wimse-wpt] で定義されたものが挙げられる。

13. Using Txn-Tokens

Txn-Token は、リクエストを認可するために Txn-Token に依存するワークロード間で伝達される必要がある。そうしたワークロードは、他のワークロードから呼び出されるために HTTP [RFC9110] インタフェースを提供することが多い。本セクションは、呼び出されるワークロードが HTTP インタフェースを提示する場合に、呼び出すワークロードが Txn-Token を伝えるために使用しなければならない HTTP header を規定する。標準の HTTP Authorization header は使用してはならない。なぜなら、ワークロードが他目的でそれを使用している可能性があるためである。

13.1. Txn-Token HTTP Header

HTTP を用いて別のワークロードを呼び出し、呼び出されるワークロードに Txn-Token を提示する必要がある workload は、HTTP Request において Txn-Token を伝達するために HTTP Header Txn-Token を使用しなければならない。この header の値は、ちょうど 1 つの Txn-Token でなければならない。

13.2. Txn-Token Validation

Txn-Token を受け取った workload は、サポートする活動に対して認可する前に、token の妥当性を評価しなければならない。Txn-Token を検証するために、workload は以下を行わなければならない:

• Txn-Token の JWS 署名を検証する。
• aud claim がその workload の trust domain を識別していることを検証する。
• Txn-Token が期限切れではないことを検証する。

さらに、この workload が行う任意の outbound calls には、受け取った Txn-Token をそのまま含めなければならない。これにより、下流のワークロードへ、Txn-Token が改変されずに渡される。

Txn-Token が有効であると判断された後、workload は Txn-Token に含まれる任意のデータを用いて、Txn-Token が要求された活動を認可するかどうかを判断してもよい。workload がこの認可をどのように判断するかは、本仕様のスコープ外である。

14. Security Considerations

14.1. Txn-Token Lifetime

Txn-Token は replay attacks に耐性がない。そのため、長命な Txn-Token は、ファイルに保存され、攻撃者に発見され、再送（replay）された場合にリスクとなる。この理由から、Txn-Token の有効期間は短く保たれなければならず、call-chain の有効期間を超えてはならない。長時間実行の "batch" job であっても、より長命な Access Token を用いてバッチ endpoint へのリクエストを開始すべきである。その後、call-chain 内の下流サービスへの呼び出しを認可するために使用できる短命な Txn-Token を取得する。

Txn-Token は短命であるため、TTS からの Txn-Token response には refresh_token フィールドが含まれない。Txn-Token は refresh_token を提示して発行されることはない。

14.2. Access Tokens

Txn-Token を作成する際、Txn-Token には external endpoint に提示された Access Token を含めてはならない。Txn-Token に Access Token が含まれていると、攻撃者が Txn-Token から Access Token を抽出し、その Access Token を受け入れることができる任意の Resource Server に対して replay できてしまう。Txn-Token の有効期限はこの攻撃を防がない。なぜなら Txn-Token が失効した後でも Access Token が有効であり続ける可能性があるためである。

14.3. Subject Token Types

Txn-Token を要求するサービスは、呼び出し元を自身が認可するために使用した incoming token を持っており、かつ Txn-Token が必要な下流 call chain と直接相関する場合、その incoming token を提供するべきである。適切な incoming token がない場合、要求するサービスは self-signed JWT、unsigned JSON object、またはその他任意の形式を用いて、リクエスト元の詳細を TTS に表現してもよい。

14.4. Use of 'actor_token'

OAuth 2.0 Token Exchange 仕様 [RFC8693] の actor_token および actor_token_type parameters を使用する場合、両方の parameters はリクエストに存在しなければならない。actor_token は、リクエスト元 workload の識別情報を認証できる。

14.5. Scope Processing

Trust Domain 境界内の認可モデルは、Trust Domain 外の client に対して使用される認可モデル（例: OAuth scopes）とは大きく異なる可能性がある。これにより、意図しない scope の増加を管理することが、TTS の重要な側面となる。TTS は、Txn-Token の requested scope が、subject_token によって識別される scope(s) 以下であることを保証しなければならない。

14.6. Unique Transaction Identifier

transaction token は、call chain にわたってユーザーの識別情報と認可コンテキストを伝達する。txn claim は一意な識別子であり、TTS およびワークロードによってログに記録されることで、成功および失敗したトランザクションの発見と監査（auditing）を可能にする。txn 値は Trust Domain 内で一意であるべきである。

14.7. TTS Discovery

workload は、相互作用する TTS のインスタンスを特定するために、さまざまな仕組みを使用し得る。workload は、脅威主体が悪意ある設定データを提供し、自身の制御下にある TTS のインスタンスを指し示すことで生じるリスクを最小化するために、信頼できるソースから設定情報を取得しなければならない。このようなサービスは、Transaction Token Request メッセージの一部として送信される Access Token を収集するために使用され得る。

このリスクを軽減するために、workload は設定情報を提供するサービスを認証し、設定情報の完全性を検証するべきである。これにより、無権限の主体が設定データを挿入または改変できないことが保証される。workload は、endpoint を認証し通信チャネルを保護するために Transport Layer Security（TLS）を使用するべきである。さらに、application-layer の署名や message authentication codes を用いて、設定情報への改ざんを検知してもよい。

14.8. Workload Configuration Protection

デプロイメントには、回復性（resiliency）の向上、遅延（latency）の低減、スケーラビリティの強化のために、複数の TTS インスタンスが含まれ得る。workload は、信頼性の確保や transaction token リクエストの遅延低減のために、複数の TTS インスタンスへアクセスするよう設定され得る。workload の設定は、無権限による TTS インスタンスの追加や削除から保護されるべきである。攻撃者は、workload 設定から TTS のインスタンスを除去することで、サービス拒否攻撃を行ったり、システム性能を低下させたりできる。

14.9. TTS Authentication

workload は誤って TTS ではないサービスへ transaction token リクエストを送ってしまう可能性がある。また攻撃者は、Access Token のような機微情報を含む transaction token リクエストへのアクセスを得るために、TTS になりすますことを試みる可能性がある。transaction token リクエストに含まれる Access Token のような機微情報の漏えいリスクを最小化するために、workload は TTS を認証し、transaction tokens を発行する権限を持つ TTS のインスタンスのみに連絡することを保証しなければならない。

14.10. TTS Key Rotation

TTS は署名鍵をローテーションする必要がある場合がある。その際、[OpenIdConnect] の Section 10.1.1 にある key rotation の実践を採用してもよい。

14.11. Transaction Tokens Are Not Authentication Credentials

workload は transaction token を用いて、別の workload、サービス、または TTS に対して自身を認証してはならない。transaction token は認可判断に関連する情報を表し、workload の識別情報 credential ではない。workload と TTS 間の認証は Section 12.5 で記述される。workload が他の workload、サービス、またはシステムコンポーネントに認証するための仕組みは、本仕様のスコープ外である。

14.12. Replacing Transaction Tokens

call chain 内のサービスは、Txn-Token を置き換えることを選択し得る。これは通常、サービスが現在の Txn-Token のコンテキストを変更（追加、削除、改変）したい場合に起こり得る。

置き換え Txn-Token を取得するために、サービスは TTS から新しい Txn-Token を要求し、リクエストに現在の Txn-Token と他の parameters を提供する。

14.12.1. TTS Responsibilities

TTS は、任意の値で Txn-Token を置き換えることが Txn-Token の主目的を損なうため、置き換え Txn-Token を発行する際には注意を払わなければならない。置き換え Txn-Token を発行する際、TTS は以下のとおりである:

• 許可される行為の scope を縮小する方向の、表明値の改変を許可してもよい。
• 追加の表明値を許可してもよい。
• 許可される行為の scope を拡大する表明値の改変を許可してはならない。
• リクエスト内の Txn-Token の txn、sub、および aud 値を改変してはならない。
• req_wl claim から、既存のリクエスト元 workload 識別子のいずれも削除してはならない。
• 元に提示された token の有効期間を超える有効期間を持つ置き換え Txn-token を発行しないべきである。
• 個々の workload 識別子の区切り文字として , を用いて、置き換えを要求した workload の識別子を req_wl claim に追加しなければならない。

15. Privacy Considerations

15.1. Obfuscation of Personal Information

一部の法域では、rctx および tctx claims の一部が個人情報と見なされ得る。その場合、それらの値は難読化される必要がある。たとえば、発信元 IP アドレス（req_ip）はしばしば個人情報と見なされ、その場合は何らかの難読化手法（例: salted SHA256）により保護しなければならない。

15.2. Logging

完全な Txn-Token をそのまま（verbatim）ログに記録してはならない。これは、ログファイルを通じた token の再送（replay）や、PII などの機微情報の漏えいを防ぐためである。Txn-Token のハッシュをログに記録して、発行された tokens を記録する TTS のログファイルとの相関（correlation）に利用してもよい。代替として、署名を除去した後の Txn-Token の JWS payload をログに記録してもよい。Txn-Token に PII が含まれる場合、PII がログに記録されないよう、Txn-Token の内容をログに残す際には注意を払うべきである。

16. IANA Considerations

本仕様は、「OAuth Parameters」[IANA.OAuth.Parameters] レジストリの「OAuth URI」サブレジストリに、以下の token type identifiers を登録する。また、[RFC7519] で定義される IANA JSON Web Token Claims Registry に、Section 10.2 で定義された以下の claims を登録する。さらに、Section 10.1 で定義される Media Type [IANA.MediaTypes] "txntoken+jwt" を登録する。

16.1. OAuth URI Subregistry Contents

• URN: urn:ietf:params:oauth:token-type:txn_token
  • Common Name: Transaction Token
  • Change Controller: IETF
  • Specification Document Section: 本仕様の Section 12.1

• URN: urn:ietf:params:oauth:token-type:self_signed
  • Common Name: Token type for Self-signed JWT
  • Change Controller: IETF
  • Specification Document: 本仕様の Section 12.2.1

• URN: urn:ietf:params:oauth:token-type:unsigned_json
  • Common Name: Token type for Unsigned JSON Object
  • Change Controller: IETF
  • Specification Document: 本仕様の Section 12.2.2

16.2. JWT Claims Registry Contents

• Claim Name: tctx
  • Claim Description: トランザクションの認可詳細
  • Change Controller: IETF
  • Specification Document: 本仕様の Section 10.2

• Claim Name: rctx
  • Claim Description: リクエスト元コンテキスト
  • Change Controller: IETF
  • Specification Document: 本仕様の Section 10.2

16.3. IANA Media Type Registration Contents

以下のエントリが、IANA Media Type registration [IANA.MediaTypes] フォームを用いて提案される。

• Type Name: application
• Subtype Name: txntoken+jwt
• Change Controller: IETF
• Required Parameters: N/A.
• Optional Parameters: N/A.
• Encoding Considerations: 7-bit text
• Security Considerations:
  1. media type は、Transaction Tokens として使用され得る JWTs を識別するために用いられる。これはデータであり、実行可能な内容を含んではならない。
  2. Transaction Tokens は信頼できる環境内で使用される短命な tokens であるため、プライバシー上の考慮事項はない。Transaction Tokens は改変不能な tokens であり、完全性（integrity）保護が必要である。
  3. Transaction Tokens を表す JWTs は署名されており、したがって完全性（integrity）保護されている。Transaction Token の受領者は、使用前に Transaction Token の署名を検証しなければならない。
  4. JWTs を Transaction Tokens として使用することに固有の追加のセキュリティ考慮事項はない。
  5. Transaction Tokens の形式は token 内リンクの使用を要求しない。特定の Transaction Tokens のインスタンスでリンクが使用される場合、その解釈は用途固有である。
• Interoperability Considerations: Transaction Tokens は、JWTs のすべての相互運用性特性を継承する。
• Published Specification: 本文書（公開時）
• Application Usage: JWTs の使用をサポートする任意の application
• Fragment Identifier Consideration: N/A.
• Restrictions on Usage: JWTs の使用をサポートする任意の application
• Intended Usage: Common
• Contact Person: Atul Tulshibagwale

16.4. HTTP Header

header 名 Txn-Token は、構造化されていない Header Field（unstructured Header Field）として、HTTP Field Name Registry [IANA.HTTP.FieldNames] に追加することが提案される。この header は Section 13.1 で定義される。以下のエントリが HTTP Field Name Registry に提案される。これは unstructured field であるため、以下に示すとおり Type フィールドの値は空のままとする。

• Field Name: Txn-Token
• Type:
• Status: permanent
• Specification Document: 本文書の Section 13.1
• Comment: Authorization header は Txn-token に使用できない。なぜなら、それは service-to-service の認可に使用される可能性があり、またサービスは同時に Txn-token を用いて、ユーザーの識別情報や、Txn-token に含まれるきめ細かな認可の詳細などの不変（immutable）な詳細情報を伝達する必要があり得るためである。

17. References

17.1. Normative References

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
• [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.
• [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018.
• [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012.
• [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015.
• [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015.
• [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015.
• [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
• [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020.
• [RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, "Security Event Token (SET)", RFC 8417, DOI 10.17487/RFC8417, July 2018.
• [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020.
• [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021.
• [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022.
• [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022.
• [RFC9651] Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024.
• [IANA.HTTP.FieldNames] "HTTP Authentication Schemes", n.d.
• [IANA.OAuth.Parameters] IANA, "OAuth Parameters", n.d.
• [IANA.MediaTypes] IANA, "Media Types", n.d.
• [OpenIdConnect] Sakimura, N., Bradley, J., Jones, M., Medeiros, B. de., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 2", November 2014.

17.2. Informative References

• [SPIFFE] Cloud Native Computing Foundation, "Secure Production Identity Framework for Everyone", n.d.
• [I-D.ietf-wimse-arch] Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft-ietf-wimse-arch-06, 30 September 2025.
• [I-D.ietf-wimse-mutual-tls] Salowey, J. A. and Y. Rosomakho, "Workload Authentication Using Mutual TLS", Work in Progress, Internet-Draft, draft-ietf-wimse-mutual-tls-00, 2 November 2025.
• [I-D.ietf-wimse-http-signature] Salowey, J. A. and Y. Sheffer, "WIMSE Workload-to-Workload Authentication with HTTP Signatures", Work in Progress, Internet-Draft, draft-ietf-wimse-http-signature-01, 8 January 2026.
• [I-D.ietf-wimse-wpt] Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof Token", Work in Progress, Internet-Draft, draft-ietf-wimse-wpt-00, 3 November 2025.

Acknowledgements

著者らは、本仕様を支援し、コメントし、貢献し、フィードバックを提供してくれた John Bradley、Kelley Burgin、Brian Campbell、Naveen CM、Andrii Deinega、Apoorva Deshpande、Daniel Fett、Evan Gilman、Joseph Heenan、Watson Ladd、Kai Lehmann、Jeff Lombardo、Dan Moore、Steinar Noem、Ashay Raut、Justin Richer、Joe Salowey、Dean Saxe、Arndt Schwenkschuster、Dag Sneeggen、Yaron Scheffer、Orie Steele、Dmitry Telegin、そして Hannes Tschofenig に感謝する。

Document History

[[ To be removed from final specification ]]

• "request_details" の説明における矛盾を除去し、規範的言語（normative language）を簡素化する。claim の使用方法を明確化する（https://github.com/oauth-wg/oauth-transaction-tokens/issues/228）。

Since Draft 06

• 入力 token に関する期待の用語整合性（https://github.com/oauth-wg/oauth-transaction-tokens/issues/224）

• StringOrURI を string に置き換える。StringOrURI を String に置き換える（https://github.com/oauth-wg/oauth-transaction-tokens/issues/195）

• 緩和すべき脅威として token 窃取を含める。benefit として情報漏えいを考慮する（https://github.com/oauth-wg/oauth-transaction-tokens/issues/207）

• Authorization Context の定義を削除する。Authorization Context をより具体的にする（https://github.com/oauth-wg/oauth-transaction-tokens/issues/192）

• 空の parameter の使用に関する文言を明確化する: https://github.com/oauth-wg/oauth-transaction-tokens/issues/235

• workload は、正当な transaction token service のインスタンスと通信していることを確保すべきである点を明確化する（https://github.com/oauth-wg/oauth-transaction-tokens/issues/233）

• subject_token が署名されている場合に署名を検証する必要を明確化する。

• call chain における transaction tokens の役割を明確化する（https://github.com/oauth-wg/oauth-transaction-tokens/issues/203）

• token 期限切れの強制に関する規範的言語（normative language）を改訂する（https://github.com/oauth-wg/oauth-transaction-tokens/issues/210）

• unsigend token から exp フィールドを削除する（https://github.com/oauth-wg/oauth-transaction-tokens/issues/201）

• 文書カテゴリを informational から standards track に変更する（https://github.com/oauth-wg/oauth-transaction-tokens/issues/169）

• 置き換え transaction token に含まれる場合でも txn should remain unchanged であることを明確化する。

• 編集上の更新（https://github.com/oauth-wg/oauth-transaction-tokens/issues/204）

• parameters を based64url 形式でエンコードする要件を削除した。

• purpose claim を scope に改名した。

• issue #225 に対応して sub claim の記述を強化した。

• transaction tokens の置き換えに関する参照を削除し、置き換えに関する懸念を明確にする注記を Security Considerations に追加した。

• Dan Moore により特定された編集上の更新（https://github.com/oauth-wg/oauth-transaction-tokens/issues/236）

• Joe Saloway からの編集上コメント（https://github.com/oauth-wg/oauth-transaction-tokens/issues/219）

• request_details を明確化する（https://github.com/oauth-wg/oauth-transaction-tokens/issues/197）

• Txn-Token の処理に関する規範的言語（normative language）を追加する（https://github.com/oauth-wg/oauth-transaction-tokens/issues/270）

• Txn-Token Requests に関する規範的言語（normative language）を強化する（https://github.com/oauth-wg/oauth-transaction-tokens/issues/209）

• WIMSE 用語と整合させる（https://github.com/oauth-wg/oauth-transaction-tokens/issues/213）

• Acknpwledgement セクションを更新する（https://github.com/oauth-wg/oauth-transaction-tokens/issues/260）

Since Draft 05

• TraT scope の拡大禁止を強化した（https://github.com/oauth-wg/oauth-transaction-tokens/pull/173）

• TraT は request token の有効期間を超え得るが、リクエストで期限切れ token を使用できない点を明確化した（https://github.com/oauth-wg/oauth-transaction-tokens/pull/170）

• 明確さのため abstract を改善した（https://github.com/oauth-wg/oauth-transaction-tokens/pull/160）

• HTTP header Txn-Token が unstructured であることを明確化した（https://github.com/oauth-wg/oauth-transaction-tokens/pull/176）

Since Draft 04

• Transaction Token Service discovery を明確化した（https://github.com/oauth-wg/oauth-transaction-tokens/pull/153）

• 文言を改善した（https://github.com/oauth-wg/oauth-transaction-tokens/pull/148）

• azd claim を tctx claim に改名した（https://github.com/oauth-wg/oauth-transaction-tokens/pull/150）

• 用語の大文字小文字（captialization）を修正した（https://github.com/oauth-wg/oauth-transaction-tokens/pull/151）

• key rotation に関する指針を追加した（https://github.com/oauth-wg/oauth-transaction-tokens/pull/156）

• 外部呼び出しと内部呼び出しの違いに関する文言を明確化した（https://github.com/oauth-wg/oauth-transaction-tokens/pull/157）

Authors' Addresses

• Atul Tulshibagwale
  SGNL
  Email: atul@sgnl.ai

• George Fletcher
  Practical Identity LLC
  Email: george@practicalidentity.com

• Pieter Kasselman
  Defakto Security
  Email: pieter@defakto.security