]> Huawei

liuchunchi@huawei.com

Huawei

niyuan1@huawei.com

Identity Chaining Transaction Tokens Cross-Domain 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 The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

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 , 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) 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 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 ) . 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.

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 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 , as well as "Authorization Server" (AS) defined by . Moreover, the following terms are extended or defined in this document.

• Single-domain Transaction Token. A short-lived, signed JWT that provides immutable information about the user, workloads, and specific contextual attributes of the call within a trust domain, as defined in .
• Cross-domain Transaction Token. A Txn-Token that preserves and propagates workflow-related claims from an upstream trust domain to a downstream domain via identity chaining as defined in .
• Transaction JWT Authorization Grant (Txn-JAG). A newly defined, specialized JWT acting as an OAuth 2.0 authorization grant (as defined in ), which carries the workflow-related claims, ensuring the integrity and auditability of the cross-domain call chain.
• Workflow-related Claims: txn, tctx, rctx, and req_wl claims, as defined in .

Workflows of Cross-Domain Transaction Token By combining Identity Chaining and Transaction Token , 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.

• Mode A: Indirect Txn-Token Exchange via Intermediate Access Token. Workload A in Trust Domain I first exchanges its local Txn-Token with its own AS for a Txn-JAG that targets the AS in Trust Domain II. Then, Workload A presents that Txn-JAG to the AS in Trust Domain II to obtain an access token, and uses the access token to invoke Endpoint B in Trust Domain II. Finally, Endpoint B exchanges the access token with the local TTS to acquire a new Txn-Token in Trust Domain II.
• Mode B: Direct Txn-Token Exchange. Workload A in Trust Domain I exchanges its local Txn-Token with its own AS for a Txn-JAG that targets the TTS in Trust Domain II. Then, Workload A presents the Txn-JAG directly to Endpoint B, and Endpoint B exchanges the Txn-JAG with the local TTS to obtain a new Txn-Token in Trust Domain II, thereby eliminating the intermediate round trips for the access token.

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

Mode A: Indirect Txn-Token Exchange This mode follows the classic identity chaining workflow . The workflow is illustrated in Figure 1. | | | | | | | | | | | | | | |(2)Token Exchange Response | | | |<----------------| | | | | | | | | | | | | | |(3)Present Txn-JAG | | | |--------------------------->| | | | | | | | |(4) | | | |<---------------------------| | | | | | | | |(5)Invoke with Access Token | | | |----------------------------|----->| | | | | | | | | | |(6)Txn-Token Request | | | |---------------->| | | | | | | | | | | | | | |(7)Txn-Token Response | | | |<----------------| | | | | | ]]> 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 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 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 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 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 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 for the response format.

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, 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. | | | | | | | | | | | |(2)Token Exchange Response| | |<----------------| | | | | | | | | | | |(3)Present Txn-JAG | | |------------------------->| | | | | | | | |(4)Txn-Token Request | | |---------------->| | | | | | | |(5)Txn-Token Response | | |<----------------| | | | | ]]> 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 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.

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

Mode A: Indirect Txn-Token Exchange This section defines the requests and responses for Mode A as described in .

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.

Txn-JAG Request The parameters for the Txn-JAG request build upon the definitions in Section 2.3.1 of and . 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.

Txn-JAG Response The processing rules and response format defined in Sections 2.3.2 and 2.3.3 of 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 ().

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.

Access Token Request The parameters described in Section 2.4.1 of apply here with the following requirements: assertion
REQUIRED. The Txn-JAG returned by the AS in Trust Domain I.

Access Token Response The processing rules and response formats defined in Sections 2.4.2 and 2.4.3 of 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 ().

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.

Txn-Token Request The parameters for the Txn-Token request follow the definitions in Section 12.1 of , 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 . subject_token_type
REQUIRED. MUST be urn:ietf:params:oauth:token-type:access_token.

Txn-Token Response The processing rules and response formats defined in Sections 12.3 and 12.4 of 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 ().

Domain II will proceed to use the obtained Txn-Token II normally, as defined in .

Mode B: Direct Txn-Token Exchange This section defines the requests and responses for Mode B as described in .

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.

Txn-JAG Request The request follows the same format as defined in , 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.

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

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 . In and , 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.

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.

Txn-Token Request The parameters for the Txn-Token request follow the definitions in Section 12.1 of . 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.

Txn-Token Response The processing rules and response format are identical to those described in , 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 .

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 . 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.

Operational Considerations

• AS and TTS may be operated by the same service, or not. In the former case, some procedures listed in and could be merged.

Security and Privacy Considerations

• As Domain I and II may have public Internet in between, the correct and confidential passing of tctx and rctx may require encryption or masking techniques.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] Informative References Lancaster University BBC Huawei Technologies AI-based agent-to-agent communication increasingly occurs across trust domains (e.g., between enterprises, service providers, SaaS platforms, and application third parties). While many agent protocols and platforms can provide transport security and local permission models, deployments lack a coherent, interoperable baseline for verifiable agent identity, credentialing, cross-domain authorisation, delegation, revocation, and auditability. This document defines an architectural framework for a cross-domain trust substrate for AI-based agent ecosystems. The framework is intended to be agent protocol-agnostic and to provide a consistent trust baseline that existing and emerging AI agent protocols can build upon. CrowdStrike Practical Identity LLC Defakto Security Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the trust domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. Defakto Security Defakto Security MITRE NSA-CCSS Ping Identity Okta This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed.

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

Example Mode A: Indirect Txn-Token Exchange

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). 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. Figure 4: Txn-Token-I Payload The access_token parameter of the token exchange response contains the Txn-JAG requested by Workload A. Figure 5: Txn-JAG Response 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.

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. Figure 7: Access Token Request Figure 8: Access Token Response Figure 9: Access Token Payload

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. 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.

Example Mode B: Direct Txn-Token Exchange

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. 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. Figure 12: Txn-JAG Payload As defined in , 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.

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. 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. Figure 14: Txn-Token-II Payload

Acknowledgments TODO acknowledge.