Internet-Draft Cross-domain Transaction Tokens June 2026
Liu & Ni Expires 1 January 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-liu-cross-domain-txn-token-latest
Published:
Intended Status:
Informational
Expires:
Authors:
C. P. Liu
Huawei
Y. Ni
Huawei

Cross-domain Transaction Tokens

Abstract

This document describes a mechanism for Cross-Domain Transaction Tokens, which enables the safe maintenance and propagation of user identity, workload identities, and authorization context across multiple trust domains.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://NiYuan224.github.io/draft-liu-cross-domain-txn-token/draft-liu-cross-domain-txn-token.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-liu-cross-domain-txn-token/.

Source for this draft and an issue tracker can be found at https://github.com/NiYuan224/draft-liu-cross-domain-txn-token.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 1 January 2027.

▲

Table of Contents

1. Introduction

Due to the rise of collaborative service ecosystems and AI agents, services frequently interact across domain boundaries and involve multiple service operators (e.g., enterprises, cloud providers, SaaS platforms, etc.). As illustrated in [I-D.kiliram-agent-trust-auth-framework], workflows spanning multiple domains require workloads within each domain to perform subtasks and pass results to cooperatively accomplish an overall task. Moreover, to ensure end-to-end accountability, the entities and actions must remain auditable throughout the entire call chain.

This requires the secure preservation and propagation of user identity, workload identities and authorization context across different domains.

Transaction Token (Txn-Token) [I-D.ietf-oauth-transaction-tokens] defines a short-lived, signed JWT that preserves immutable user identity, workload identity, and authorization context within a single trust domain's call chain. While this mechanism effectively preserves context, its applicability is currently limited to single-domain call chains. Conversely, Identity Chaining [I-D.ietf-oauth-identity-chaining] provides a framework for cross-domain delegation but does not specify how to leverage the rich, structured context carried by Txn-Tokens (i.e., the claims of txn, tctx, rctx, and req_wl in [I-D.ietf-oauth-transaction-tokens]) .

This document bridges this gap by defining a mechanism to use a Txn-Token (from domain I) as the input of Identity Chaining, in order to create another Txn-Token at the other domain II. This approach enables the propagation of workflow-related claims, i.e., claims of txn, tctx, rctx, and req_wl, across multiple trust domains, ensuring the integrity and auditability of the entire call chain.

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This document uses the terms "Workload", "Trust Domain", "External Endpoint", "Call Chain", and "Transaction Token Service" (TTS) defined by [I-D.ietf-oauth-transaction-tokens], as well as "Authorization Server" (AS) defined by [RFC6749]. Moreover, the following terms are extended or defined in this document.

3. Workflows of Cross-Domain Transaction Token

By combining Identity Chaining [I-D.ietf-oauth-identity-chaining] and Transaction Token [I-D.ietf-oauth-transaction-tokens], this section describes two workflow modes to securely preserve and propagate workflow-related claims across different trust domains. Both modes utilize the newly defined Txn-JAG as the secure carrier between domains but differ in how the downstream domain processes it.

The following subsections focus on the logical orchestration and context propagation of these workflows. Definitions for the request and response formats are detailed in Section 4.

3.1. Mode A: Indirect Txn-Token Exchange

This mode follows the classic identity chaining workflow [I-D.ietf-oauth-identity-chaining]. The workflow is illustrated in Figure 1.

+----------+ +--------+ +---------+ +----------+ +---------+
|Workload A| |   AS   | |    AS   | |Endpoint B| |   TTS   |
|Domain I  | |Domain I| |Domain II| |Domain II | |Domain II|
+----------+ +--------+ +---------+ +----------+ +---------+
 |                 |          |      |                 |
 |(1)Token Exchange Request   |      |                 |
 |---------------->|          |      |                 |
 | <Txn-Token I>   |          |      |                 |
 |                 |          |      |                 |
 |(2)Token Exchange Response  |      |                 |
 |<----------------|          |      |                 |
 |     <Txn-JAG>   |          |      |                 |
 |                 |          |      |                 |
 |(3)Present Txn-JAG          |      |                 |
 |--------------------------->|      |                 |
 |                 |          |      |                 |
 |(4)<Access Token>           |      |                 |
 |<---------------------------|      |                 |
 |                 |          |      |                 |
 |(5)Invoke with Access Token |      |                 |
 |----------------------------|----->|                 |
 |                 |          |      |                 |
 |                 |          |      |(6)Txn-Token Request
 |                 |          |      |---------------->|
 |                 |          |      | <Access Token>  |
 |                 |          |      |                 |
 |                 |          |      |(7)Txn-Token Response
 |                 |          |      |<----------------|
 |                 |          |      | <Txn-Token II>  |

Figure 1: Indirect Txn-Token Exchange

(1) Workload A in Trust Domain I sends a token exchange request to the local AS to exchange the local Txn-Token for a cross-domain Txn-JAG. See Section 4.1.1 for the request format.

(2) The AS in Trust Domain I validates the request, generates and responds with the Txn-JAG, transcribing the workflow-related claims from the local Txn-Token into the Txn-JAG's claims. See Section 4.1.1 for the response format.

(3) Workload A in Trust Domain I presents the Txn-JAG to the AS of Trust Domain II to request an access token. See Section 4.1.2 for the request format.

(4) The AS of Trust Domain II validates the Txn-JAG and responds with an access token, transcribing the workflow-related claims from the Txn-JAG into the access token. See Section 4.1.2 for the response format.

(5) Workload A in Trust Domain I invokes Endpoint B of Trust Domain II with the received access token.

(6) Endpoint B presents the inbound access token to the TTS of Trust Domain II to request a Txn-Token. See Section 4.1.3 for the request format.

(7) The TTS of Trust Domain II mints a local Txn-Token, transcribing the workflow-related claims from the access token into the new Txn-Token. See Section 4.1.3 for the response format.

3.2. Mode B: Direct Txn-Token Exchange

While Mode A provides a straightforward integration of Identity Chaining procedures with Transaction Tokens procedures, which does not create protocol-level changes, it introduces multiple cross-domain round trips that can significantly increase latency. As illustrated in Figure 1, steps (3) through (5) require at least three cross-domain round-trips: presenting the Txn-JAG to the downstream AS to obtain an access token, invoking the target endpoint with that token, and subsequently exchanging it for a local Txn-Token. In distributed and high-throughput environments, this operational overhead can become prohibitive.

An opportunity for optimization arises from the flexibility defined in Section 5.1 of the Transaction Token[I-D.ietf-oauth-transaction-tokens], which allows the subject_token to be "any other format that is understood by the TTS". This enables a TTS to directly accept a Txn-JAG issued by the upstream AS as the subject token in a Txn-Token request.

Thus, Mode B reduces cross-domain round trips from three to one by allowing the TTS in Trust Domain II to accept the Txn-JAG directly as the subject token in a Txn-Token request. This requires a pre-established trust relationship between the AS in Trust Domain I and the TTS in Trust Domain II. The workflow is illustrated in Figure 2.

+----------+   +--------+ +----------+     +---------+
|Workload A|   |   AS   | |Endpoint B|     |   TTS   |
| Domain I |   |Domain I| |Domain II |     |Domain II|
+----------+   +--------+ +----------+     +---------+
     |                 |        |                 |
     |(1)Token Exchange Request |                 |
     |---------------->|        |                 |
     |<Txn-Token I>    |        |                 |
     |                 |        |                 |
     |(2)Token Exchange Response|                 |
     |<----------------|        |                 |
     |<Txn-JAG>        |        |                 |
     |                 |        |                 |
     |(3)Present Txn-JAG        |                 |
     |------------------------->|                 |
     |                 |        |                 |
     |                 |        |(4)Txn-Token Request
     |                 |        |---------------->|
     |                 |        | <Txn-JAG>       |
     |                 |        |(5)Txn-Token Response
     |                 |        |<----------------|
     |                 |        | <Txn-Token II>  |

Figure 2: Direct Txn-Token Exchange

Steps (1) and (2) are the same as those in Mode A.

(3) Workload A in Trust Domain I presents the Txn-JAG to Endpoint B of Trust Domain II. See Section 4.2.1.3 for the transmission method.

(4) Endpoint B uses Txn-JAG as the subject token to exchange for a local Txn-Token at its local TTS.

(5) The TTS of Trust Domain II mints a local Txn-Token, transcribing the workflow-related context from the Txn-JAG into the local Txn-Token's claims.

4. Requests and Responses

The formats of requests and responses included in Section 3 are detailed in this section. To avoid redundancy, all illustrative examples are provided in Appendix A.

4.1. Mode A: Indirect Txn-Token Exchange

This section defines the requests and responses for Mode A as described in Section 3.1.

4.1.1. Token Exchange for Txn-JAG

Workload A in Trust Domain I performs token exchange with the AS in Trust Domain I to obtain a Txn-JAG that can be used at the AS in Trust Domain II.

4.1.1.1. Txn-JAG Request

The parameters for the Txn-JAG request build upon the definitions in Section 2.3.1 of [I-D.ietf-oauth-identity-chaining] and [RFC8693]. While parameter types remain consistent with these specifications, the values of certain parameters are required as follows:

resource
REQUIRED if audience is not set. It MUST be the URI of the AS in Trust Domain II.

audience
REQUIRED if resource is not set. It MUST be the well-known/logical name of the AS in Trust Domain II.

subject_token
REQUIRED. MUST be a valid local Txn-Token issued within Trust Domain I.

subject_token_type
REQUIRED. MUST be urn:ietf:params:oauth:token-type:txn_token.

4.1.1.2. Txn-JAG Response

The processing rules and response format defined in Sections 2.3.2 and 2.3.3 of [I-D.ietf-oauth-identity-chaining] apply, with the following modifications:

  • The AS in Trust Domain I SHOULD transcribe the workflow-related claims from the Txn-Token to the Txn-JAG's claims. During this transcription, The AS in Trust Domain I MAY add, remove, or change the claims. See Claims Transcription (Section 4.3).

4.1.2. Cross-Domain Assertion

Workload A in Trust Domain I uses the Txn-JAG obtained from the AS in Trust Domain I as an assertion to request an access token from the AS in Trust Domain II.

4.1.2.1. Access Token Request

The parameters described in Section 2.4.1 of [I-D.ietf-oauth-identity-chaining] apply here with the following requirements:

assertion
REQUIRED. The Txn-JAG returned by the AS in Trust Domain I.

4.1.2.2. Access Token Response

The processing rules and response formats defined in Sections 2.4.2 and 2.4.3 of [I-D.ietf-oauth-identity-chaining] apply, with the following modifications:

  • The AS in trust domain II SHOULD transcribe the workflow-related claims from the Txn-JAG to the access token's claims. See Claims Transcription (Section 4.3).

4.1.3. Token Exchange for Txn-Token

Workload A in Trust Domain I performs a token exchange with the TTS in Trust Domain II to obtain a local Txn-Token in Trust Domain II.

4.1.3.1. Txn-Token Request

The parameters for the Txn-Token request follow the definitions in Section 12.1 of [I-D.ietf-oauth-transaction-tokens], the following requirements apply to the subject_token and subject_token_type:

subject_token
REQUIRED. MUST be the access token issued by the AS in Trust Domain II, as obtained Section 4.1.3.

subject_token_type
REQUIRED. MUST be urn:ietf:params:oauth:token-type:access_token.

4.1.3.2. Txn-Token Response

The processing rules and response formats defined in Sections 12.3 and 12.4 of [I-D.ietf-oauth-transaction-tokens] apply, with the following modifications:

  • For subject token validation, the TTS in Trust Domain II MUST validate the access token issued by its local AS.

  • The TTS in trust domain II SHOULD transcribe the workflow-related claims from the subject token to the claims of the issued Txn-Token. See Claims Transcription (Section 4.3).

Domain II will proceed to use the obtained Txn-Token II normally, as defined in [I-D.ietf-oauth-transaction-tokens].

4.2. Mode B: Direct Txn-Token Exchange

This section defines the requests and responses for Mode B as described in Section 3.2.

4.2.1. Token Exchange for Txn-JAG

Workload A in Trust Domain I performs token exchange with the AS in Trust Domain I to obtain a Txn-JAG that can be used with the TTS in Trust Domain II.

4.2.1.1. Txn-JAG Request

The request follows the same format as defined in Section 4.1.1, except for the resource or audience parameter:

resource
REQUIRED. if audience is not set. It MUST be the URI of the TTS in Trust Domain II.

audience
REQUIRED. if resource is not set. It MUST be the well-known/logical name of the TTS in Trust Domain II.

4.2.1.2. Txn-JAG Response

The processing rules and response format are identical to those described in Section 4.1.1, with the exception that the aud claim in the issued Txn-JAG MUST identify the TTS of Trust Domain II.

4.2.1.3. Txn-JAG Transmission Methods

When a Txn-JAG is presented directly to an endpoint, the workload MUST include the Txn-JAG parameter in HTTP named Txn-JAG. This dedicated parameter avoids ambiguity with the Authorization header, which is conventionally associated with access tokens per [RFC6750].

In [RFC7523] and [I-D.ietf-oauth-identity-chaining], the JAG is carried by the assertion field in HTTP, but it is used to request an access token. These drafts have not listed the usage of assertion field to request a Txn-Token, as described in this document. As a result, this document has designed a new HTTP parameter Txn-JAG. But alternatively, it could also be transmitted as a HTTP header field. The most appropriate design should subject to Working Group's discretion.

4.2.2. Token Exchange for Txn-Token

Endpoint B performs a token exchange with the TTS in Trust Domain II to obtain a local Txn-Token in Trust Domain II, using the Txn-JAG as the subject_token.

4.2.2.1. Txn-Token Request

The parameters for the Txn-Token request follow the definitions in Section 12.1 of [I-D.ietf-oauth-transaction-tokens]. The following requirements apply:

subject_token
REQUIRED. MUST be the Txn-JAG issued by the AS in Trust Domain I, as obtained in Section 4.2.1 and presented to Endpoint B via the method in Section 4.2.1.3.

subject_token_type
REQUIRED. MUST be urn:ietf:params:oauth:token-type:jwt-bearer.

4.2.2.2. Txn-Token Response

The processing rules and response format are identical to those described in Section 4.1.3, with the following modification for subject token validation:

For subject token validation, the TTS in Trust Domain II MUST validate the Txn-JAG issued by the AS in Trust Domain I. This requires a pre-established trust relationship between the AS in Trust Domain I and the TTS in Trust Domain II. Such a trust relationship typically manifests as the exchange of key material.

The transcription of workflow-related claims from the subject token (the Txn-JAG) to the issued Txn-Token follows the same rules defined in Section 4.3.

4.3. Claims Transcription

Claims transcription across trust domains SHOULD ensure that the workflow-related claims are preserved for auditability and accountability. This builds upon the principles defined in Section 2.5 of [I-D.ietf-oauth-identity-chaining]. Specific transcription rules for workflow-related claims are defined as follows:

  • Preserving the txn claim. The txn claim serves as the immutable unique identifier for the cross-domain transaction. Both the AS and TTS SHOULD NOT modify or regenerate the txn value during transcription. It SHOULD be copied from the subject_token to the issued token to ensure auditability and accountability across different domains. To avoid collisions without a centralized namespace, the txn value can be generated as a high-entropy string or prefixed with a domain identifier.

  • Evolving the req_wl claim. The req_wl SHOULD identify all the workloads that requested or exchanged tokens throughout the cross-domain transaction. Specifically, the AS in Trust Domain I SHOULD add the identifier of Workload A to the req_wl in the issued Txn-JAG. The TTS in Trust Domain II SHOULD add the identifier of Endpoint B to req_wl in the issued Txn-Token in Trust Domain II. This ensures that every point where claims may change is recorded, providing a trail of how the claims reached its current state.

  • Data Minimization. The processing or req_wl may exist privacy concerns that exposing topology of Domain I. The AS in Trust Domain I MAY apply security and privacy strategies to workflow-related claims when issuing the Txn-JAG. Such measures include but not limited to Removal.

    • Removal. Claims related to completed tasks or not required by downstream trust domains COULD be removed or redacted. If certain claims are required for end-to-end auditing, Domain I MAY take proper logs before removal.

5. Operational Considerations

6. Security and Privacy Considerations

7. IANA Considerations

This document has no IANA actions.

8. References

8.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6749]
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <https://www.rfc-editor.org/rfc/rfc6749>.
[RFC6750]
Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, , <https://www.rfc-editor.org/rfc/rfc6750>.
[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, , <https://www.rfc-editor.org/rfc/rfc7523>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8693]
Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, , <https://www.rfc-editor.org/rfc/rfc8693>.

8.2. Informative References

[I-D.ietf-oauth-identity-chaining]
Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-16, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-chaining-16>.
[I-D.ietf-oauth-transaction-tokens]
Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-08, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-08>.
[I-D.kiliram-agent-trust-auth-framework]
King, D., Ramdhany, R., and P. C. Liu, "A Trust and Authentication Framework for Cross-Domain Agent-to-Agent Communications", Work in Progress, Internet-Draft, draft-kiliram-agent-trust-auth-framework-00, , <https://datatracker.ietf.org/doc/html/draft-kiliram-agent-trust-auth-framework-00>.

Appendix A. Examples

Two examples are provided in Appendix A, including the protocol framing and decoded JSON payloads.

A.1. Example Mode A: Indirect Txn-Token Exchange

A.1.1. Txn-JAG Request and Response

Workload A in Trust Domain I performs token exchange with the AS in Trust Domain I (https://as.domain1.example/auth) to receive a Txn-JAG targeted at the AS in trust domain II (https://as.domain2.example/auth).

   POST /auth HTTP/1.1
   Host: as.domain1.example
   Content-Type: application/x-www-form-urlencoded

   grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
   &resource=https%3A%2F%2Fas.domain2.example%2Fauth
   &subject_token=<Encoded Txn-Token-I>
   &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Atxn_token

Figure 3: Txn-JAG Request

The subject_token in the prior request is the Txn-Token issued by the TTS in Trust Domain I, and the decoded JWT payload is shown here.

{
    "iat": 1777724800,
    "exp": 1777724860,
    "aud": "https://domain1.example",
    "iss": "https://tts.domain1.example",
    "txn": "97053963-771d-49cc-a4e3-20aad399c312",
    "sub": "john_doe@a.org",
    "req_wl": "apigateway.domain1.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: Txn-Token-I Payload

The access_token parameter of the token exchange response contains the Txn-JAG requested by Workload A.

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

   {
     "access_token":<Encoded Txn-JAG>,
     "token_type":"N_A",
     "issued_token_type":"urn:ietf:params:oauth:token-type:jwt",
     "expires_in":60
   }

Figure 5: Txn-JAG Response

{
  "iat": 1777724830,
  "exp": 1777728430,
  "aud": "https://as.domain2.example/auth",
  "iss": "https://as.domain1.example",
  "sub": "john_doe@a.org",
  "txn": "97053963-771d-49cc-a4e3-20aad399c312",
  "req_wl": "apigateway.domain1.example,workload_a",
  "rctx": {
    "authn": "urn:ietf:rfc:6749"
    <Encrypted_Information>
  },
  "scope": "trade.stocks",
  "tctx": {
    "action": "BUY",
    "ticker": "MSFT",
    "quantity": "100"
    <Encrypted_Information>
  }
}

Figure 6: Txn-JAG Payload

As shown in Figure 4 and Figure 6, the AS in Trust Domain I protects and evolves the claims during Txn-JAG issuance: for immutability, the txn claim is copied verbatim; for evolution, workload_a is appended to req_wl to record the exchange point; and for security, sensitive information like req_ip and customer_type are encrypted.

A.1.2. Access Token Request and Response

Workload A presents the Txn-JAG as an assertion to the AS of Trust Domain II to request an access token.

    POST /auth HTTP/1.1
    Host: as.domain2.example
    Content-Type: application/x-www-form-urlencoded

    grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
    &assertion=<Encoded Txn-JAG>

Figure 7: Access Token Request

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

   {
     "access_token":"ey...",
     "token_type":"N_A",
     "issued_token_type":"urn:ietf:params:oauth:token-type:jwt",
     "expires_in":60
   }

Figure 8: Access Token Response

{
  "iat": 1777724890,
  "exp": 1777728490,
  "aud": "https://endpointb.domain2.example",
  "iss": "https://as.domain2.example",
  "sub": "john.doe.123",
  "txn": "97053963-771d-49cc-a4e3-20aad399c312",
  "req_wl": "apigateway.domain1.example,workload_a",
  "rctx": {
    "authn": "urn:ietf:rfc:6749"
    <Encrypted_Information>
  },
  "scope": "trade.stocks",
  "tctx": {
    "action": "BUY",
    "ticker": "MSFT",
    "quantity": "100"
    <Encrypted_Information>
  }
}

Figure 9: Access Token Payload

A.1.3. Txn-Token Request and Response

Upon receiving the access token, Workload A in Trust Domain II exchanges it for a local Txn-Token from its TTS. The payload of the Txn-Token in Trust Domain II is shown below.

{
    "iat": 1777724900,
    "exp": 1777724960,
    "iss": "https://tts.domain2.example",
    "aud": "https://domain2.example",
    "txn": "97053963-771d-49cc-a4e3-20aad399c312",
    "sub": "john_doe@a.org",
    "req_wl": "apigateway.domain1.example,workload_a,endpoint_b",
    "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 10: Txn-Token-II Payload

As can be seen from Figure 10, the TTS preserves the txn claim verbatim and evolves the req_wl claim, appending the identifier of Endpoint B.

A.2. Example Mode B: Direct Txn-Token Exchange

A.2.1. Txn-JAG Request and Response

Workload A in Trust Domain I exchanges its local Txn-Token for a Txn-JAG, where the resource is set to the TTS of Domain II.

POST /auth HTTP/1.1
Host: as.domain1.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&resource=https://tts.domain2.example
&subject_token=<Encoded Txn-Token-I the same in Figure 4>
&subject_token_type=urn:ietf:params:oauth:token-type:txn_token

Figure 11: Txn-JAG Request

The AS in Domain I transcribes the claims. In the issued Txn-JAG, the aud is set to the Domain II TTS.

{
  "iat": 1777724830,
  "exp": 1777728430,
  "aud": "https://tts.domain2.example",
  "iss": "https://as.domain1.example",
  "sub": "john_doe@a.org",
  "txn": "97053963-771d-49cc-a4e3-20aad399c312",
  "req_wl": "workload_a",
  "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 12: Txn-JAG Payload

As defined in Section 4.3, the AS in Trust Domain I applies an removal strategy to the req_wl claim. The internal path preceding workload_a is removed to protect the internal topology of Domain I.

A.2.2. Txn-Token Request and Response

Workload A presents the Txn-JAG directly to Endpoint B. Endpoint B then uses this Txn-JAG as the subject_token to request a local Txn-Token from the TTS in Trust Domain II.

POST /token HTTP/1.1
Host: tts.domain2.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Atxn-token
&subject_token=<Encoded Txn-JAG>
&scope=trade.stocks
&subject_token_type=urn:ietf:params:oauth:token-type:jwt-bearer

Figure 13: Txn-Token Request

The TTS validates the cross-domain Txn-JAG based on the pre-established trust relationship with AS in Trust Domain I. It transcribes the claims and evolves the req_wl to include Endpoint B.

{
  "iat": 1777724900,
  "exp": 1777724960,
  "iss": "https://tts.domain2.example",
  "aud": "https://domain2.example",
  "txn": "97053963-771d-49cc-a4e3-20aad399c312",
  "sub": "john_doe@a.org",
  "req_wl": "workload_a,endpoint_b",
  "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 14: Txn-Token-II Payload

Acknowledgments

TODO acknowledge.

Authors' Addresses

Chunchi Peter Liu
Huawei
Yuan Ni
Huawei