Cross-domain Transaction Tokens
draft-liu-oauth-cross-domain-txn-token-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Peter Chunchi Liu , Ni Yuan | ||
| Last updated | 2026-07-03 | ||
| Replaces | draft-liu-cross-domain-txn-token | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-oauth-cross-domain-txn-token-00
Network Working Group C. P. Liu
Internet-Draft Y. Ni
Intended status: Informational Huawei
Expires: 4 January 2027 3 July 2026
Cross-domain Transaction Tokens
draft-liu-oauth-cross-domain-txn-token-00
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-oauth-cross-domain-txn-token/
draft-liu-oauth-cross-domain-txn-token.html. Status information for
this document may be found at https://datatracker.ietf.org/doc/draft-
liu-oauth-cross-domain-txn-token/.
Source for this draft and an issue tracker can be found at
https://github.com/NiYuan224/draft-liu-oauth-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 4 January 2027.
Liu & Ni Expires 4 January 2027 [Page 1]
Internet-Draft Cross-domain Transaction Tokens July 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Workflows of Cross-Domain Transaction Token . . . . . . . . . 4
3.1. Mode A: Indirect Txn-Token Exchange . . . . . . . . . . . 5
3.2. Mode B: Direct Txn-Token Exchange . . . . . . . . . . . . 6
4. Requests and Responses . . . . . . . . . . . . . . . . . . . 7
4.1. Mode A: Indirect Txn-Token Exchange . . . . . . . . . . . 7
4.1.1. Token Exchange for Txn-JAG . . . . . . . . . . . . . 8
4.1.2. Cross-Domain Assertion . . . . . . . . . . . . . . . 8
4.1.3. Token Exchange for Txn-Token . . . . . . . . . . . . 9
4.2. Mode B: Direct Txn-Token Exchange . . . . . . . . . . . . 10
4.2.1. Token Exchange for Txn-JAG . . . . . . . . . . . . . 10
4.2.2. Token Exchange for Txn-Token . . . . . . . . . . . . 11
4.3. Claims Transcription . . . . . . . . . . . . . . . . . . 12
5. Operational Considerations . . . . . . . . . . . . . . . . . 12
6. Security and Privacy Considerations . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14
A.1. Example Mode A: Indirect Txn-Token Exchange . . . . . . . 14
A.1.1. Txn-JAG Request and Response . . . . . . . . . . . . 14
A.1.2. Access Token Request and Response . . . . . . . . . . 16
A.1.3. Txn-Token Request and Response . . . . . . . . . . . 17
A.2. Example Mode B: Direct Txn-Token Exchange . . . . . . . . 18
A.2.1. Txn-JAG Request and Response . . . . . . . . . . . . 18
A.2.2. Txn-Token Request and Response . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Liu & Ni Expires 4 January 2027 [Page 2]
Internet-Draft Cross-domain Transaction Tokens July 2026
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.
Liu & Ni Expires 4 January 2027 [Page 3]
Internet-Draft Cross-domain Transaction Tokens July 2026
* 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 [I-D.ietf-oauth-transaction-tokens].
* 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
[I-D.ietf-oauth-identity-chaining].
* Transaction JWT Authorization Grant (Txn-JAG). A newly defined,
specialized JWT acting as an OAuth 2.0 authorization grant (as
defined in [RFC7523]), 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 [I-D.ietf-oauth-transaction-tokens].
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.
* 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 Section 4.
Liu & Ni Expires 4 January 2027 [Page 4]
Internet-Draft Cross-domain Transaction Tokens July 2026
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.
Liu & Ni Expires 4 January 2027 [Page 5]
Internet-Draft Cross-domain Transaction Tokens July 2026
(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.
Liu & Ni Expires 4 January 2027 [Page 6]
Internet-Draft Cross-domain Transaction Tokens July 2026
+----------+ +--------+ +----------+ +---------+
|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.
Liu & Ni Expires 4 January 2027 [Page 7]
Internet-Draft Cross-domain Transaction Tokens July 2026
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.
Liu & Ni Expires 4 January 2027 [Page 8]
Internet-Draft Cross-domain Transaction Tokens July 2026
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.
Liu & Ni Expires 4 January 2027 [Page 9]
Internet-Draft Cross-domain Transaction Tokens July 2026
* 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
Liu & Ni Expires 4 January 2027 [Page 10]
Internet-Draft Cross-domain Transaction Tokens July 2026
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.
Liu & Ni Expires 4 January 2027 [Page 11]
Internet-Draft Cross-domain Transaction Tokens July 2026
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
* AS and TTS may be operated by the same service, or not. In the
former case, some procedures listed in Section 3 and Section 4
could be merged.
Liu & Ni Expires 4 January 2027 [Page 12]
Internet-Draft Cross-domain Transaction Tokens July 2026
6. 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.
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, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<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, October 2012,
<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, May
2015, <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,
May 2017, <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, January 2020,
<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,
Liu & Ni Expires 4 January 2027 [Page 13]
Internet-Draft Cross-domain Transaction Tokens July 2026
Internet-Draft, draft-ietf-oauth-identity-chaining-16, 26
June 2026, <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, 2 March 2026,
<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, 15 March 2026,
<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.
Liu & Ni Expires 4 January 2027 [Page 14]
Internet-Draft Cross-domain Transaction Tokens July 2026
{
"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_
Liu & Ni Expires 4 January 2027 [Page 15]
Internet-Draft Cross-domain Transaction Tokens July 2026
{
"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_
Liu & Ni Expires 4 January 2027 [Page 16]
Internet-Draft Cross-domain Transaction Tokens July 2026
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.
Liu & Ni Expires 4 January 2027 [Page 17]
Internet-Draft Cross-domain Transaction Tokens July 2026
{
"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_
Liu & Ni Expires 4 January 2027 [Page 18]
Internet-Draft Cross-domain Transaction Tokens July 2026
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
Liu & Ni Expires 4 January 2027 [Page 19]
Internet-Draft Cross-domain Transaction Tokens July 2026
_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
Email: liuchunchi@huawei.com
Yuan Ni
Huawei
Email: niyuan1@huawei.com
Liu & Ni Expires 4 January 2027 [Page 20]