]> Practical Identity LLC

george@practicalidentity.com

Defakto Security

pieter@defakto.security

CVS Health

sean.odell@cvshealth.com

Web Authorization Protocol oauth transaction tokens identity chaining cross-domain trust domain This specification defines a profile of the OAuth Identity and Authorization Chaining Across Domains mechanism that uses a Transaction Token (Txn-Token) as the subject token in a Token Exchange request to obtain a JWT Authorization Grant for crossing a trust boundary. A Txn-Token is scoped to a single trust domain and represents the full authorization context of an in-progress transaction, regardless of whether that transaction was initiated by a human user calling an external API, by an internal system event, or by an automated workload. This profile specifies how a service operating within that trust domain can present its Txn-Token to obtain a JWT Authorization Grant that carries the necessary context across a trust boundary, enabling an access token to be issued for a partner service, without exposing internal trust-domain credentials or token formats beyond the trust boundary. Note to Readers RFC EDITOR: please remove this section before publication Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/george-fletcher/draft-fletcher-transaction-token-chaining-profile.

Introduction Organizations routinely deploy services that, in fulfilling a transaction for a user or an automated process, must call one or more partner APIs that lie outside the organization's own trust boundary. The challenge is to carry the authorization context of the original transaction — including the identity and authorization of the Initiating Principal — across that boundary in a way that is trustworthy to the partner, without leaking internal credentials or internal token formats. Transaction Tokens (Txn-Tokens) address the first half of this problem. A Txn-Token is a short-lived, cryptographically signed JWT scoped to a single trust domain (for example, an enterprise or a cloud service provider's internal environment). It is minted by a Transaction Token Service (TTS) at the point where a transaction enters the trust domain and captures, in immutable form, the identity of the initiating principal, the purpose of the transaction, and relevant request parameters. Every workload within the trust domain that handles the transaction receives and validates this Txn-Token, ensuring a consistent and authoritative authorization context throughout the internal call chain. A Txn-Token may represent any of several originating contexts:

External User Request:

A human user or external client calls an API exposed at the trust domain's perimeter (e.g., a financial services API that adds a stock to a watch list on behalf of the user, authenticated via an OAuth 2.0 access token). The TTS mints a Txn-Token anchored to the user's identity and the authorized scope of that external access token.

Internal System Event:

An internal system triggers processing that has no direct external human caller (e.g., an SMTP server receiving an inbound message and initiating storage of that message in the recipient's mailbox). The TTS mints a Txn-Token representing the system's identity and the purpose of the transaction.

Automated Workload Request:

One workload within the trust domain invokes another as part of an automated pipeline (e.g., a scheduled job triggering a data aggregation service). The Txn-Token represents the workload identity and the pipeline's authorization scope.

In all three cases, the Txn-Token provides a uniform, internal representation of the authorization context. The problem this specification addresses is what happens when a service within the trust domain, in the course of executing such a transaction, needs to call a service in a different trust domain — a partner organization, a SaaS provider, or a third-party API — in order to complete the transaction. Consider a mail service within an enterprise trust domain. Upon receiving an inbound message via SMTP, the mail service is issued a Txn-Token representing the mail delivery transaction on behalf of the recipient user. Before storing the message, the mail service must call a partner spam-rating API in the spam service's trust domain. The mail service cannot present its internal Txn-Token to the spam service — the Txn-Token is scoped to the enterprise trust domain and carries internal context that must not be disclosed externally. Instead, the mail service must obtain a credential that is meaningful to the spam service's authorization server while preserving the relevant authorization context of the original transaction. The OAuth Identity and Authorization Chaining Across Domains specification defines a general mechanism by which a client in Trust Domain A can obtain a JWT Authorization Grant from the Authorization Server of Trust Domain A and present it to the Authorization Server of Trust Domain B to receive an access token. The base specification deliberately leaves the choice of subject token type open, allowing profiles to constrain and specialize the mechanism for specific deployment scenarios. This specification defines the additional details necessary to use a Txn-Token as the subject_token in the Token Exchange request described in Section 2.3 of . The Txn-Token is consumed by the Authorization Server of Trust Domain A, which validates it, applies claims transcription and minimization policy, and issues a JWT Authorization Grant targeted at the Authorization Server of Trust Domain B. The JWT Authorization Grant crosses the trust boundary carrying only the context that Trust Domain B is authorized to see. The Txn-Token itself never leaves Trust Domain A. This profile is complementary to the Identity Assertion JWT Authorization Grant profile , which targets deployments where the target authorization server already trusts a common IdP for SSO and subject resolution, using an OpenID Connect ID Token or SAML 2.0 assertion as the subject token. That profile is optimized for the human-user, single-sign-on scenario, where the trust relationship between AS-A and AS-B is mediated through a shared identity provider. This profile addresses scenarios where the trust relationship between AS-A and AS-B is established through a bilateral or federated Cross-Domain Trust Agreement, and where the input credential is a Txn-Token representing any authorized transaction within Trust Domain A. A detailed structural comparison of the two profiles appears in .

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

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.

Roles The following roles are used in this document. They extend the OAuth 2.0 roles defined in as used in .

Initiating Principal:

The entity whose authorization context is captured in the Txn-Token. The Initiating Principal may be a human user who made an external request to Trust Domain A, an internal system acting on its own behalf, or an automated workload operating within Trust Domain A. The Initiating Principal is not necessarily the same entity as the Requesting Workload that performs the cross-domain token exchange.

Requesting Workload:

A service operating inside Trust Domain A that, in the course of processing a transaction, needs to call a Protected Resource in Trust Domain B. The Requesting Workload holds a Txn-Token representing the current transaction context and acts as the OAuth 2.0 client in the Token Exchange flow with AS-A.

Transaction Token Service (TTS):

The service within Trust Domain A that mints and signs Txn-Tokens. The TTS is the authoritative source of transaction authorization context within Trust Domain A. In some deployments the TTS and AS-A MAY be co-located; in others they are separate services within the same Trust Domain.

Authorization Server of Trust Domain A (AS-A):

The OAuth 2.0 Authorization Server within Trust Domain A that receives the Token Exchange request from the Requesting Workload, validates the presented Txn-Token, applies claims transcription and minimization policy, and issues the JWT Authorization Grant targeted at AS-B.

Authorization Server of Trust Domain B (AS-B):

The OAuth 2.0 Authorization Server within Trust Domain B that receives the JWT Authorization Grant from the Requesting Workload and issues an access token for the Protected Resource.

Protected Resource:

The resource server in Trust Domain B that the Requesting Workload needs to call in order to complete the transaction in progress in Trust Domain A.

Terms

Transaction:

A unit of work initiated by an Initiating Principal that may span multiple workloads within Trust Domain A and that has a single, coherent authorization context. A transaction is identified by the txn claim in the Txn-Token.

Trust Domain:

A deployment-specific security and administrative boundary within which services, identifiers, credentials, and policy decisions are mutually trusted. This term is used in without a formal definition; this profile formalizes it. Txn-Tokens are scoped to a single Trust Domain. In this specification, Trust Domain A is the Trust Domain in which the transaction originates and in which the Requesting Workload operates. Trust Domain B is the Trust Domain in which the Protected Resource and AS-B operate.

Cross-Domain Trust Agreement:

A bilateral or federated configuration through which AS-A and AS-B establish mutual trust, permitting AS-A to issue JWT Authorization Grants that AS-B will accept, and defining the subject identifier mappings, permitted claims, and authorization policy that apply to cross-domain requests. The mechanism for establishing this trust is out of scope for this specification, but MUST be established prior to any cross-domain token exchange under this profile.

Overview

Transaction Token Context Within a Trust Domain A transaction enters Trust Domain A at its perimeter. The initiating event may be: (a) An inbound API call from an external client, in which case the external client presents an OAuth 2.0 access token or similar credential at the trust domain's API gateway; (b) An internal system event, such as an SMTP server receiving an inbound message, where the triggering input arrives from outside the enterprise boundary; or (c) An automated workload trigger, with no direct external caller, such as a scheduled job or an event-driven pipeline invocation. In all cases, the workload that first handles the transaction requests a Txn-Token from the TTS, presenting whatever inbound credential or context is available. The TTS validates the inbound context and mints a Txn-Token that captures the Initiating Principal's identity (which may be a user identity, a system identity, or a workload identity), the purpose of the transaction (scope), and relevant request parameters (rctx). The Txn-Token is propagated to all downstream workloads within Trust Domain A that participate in processing the transaction.

Cross-Domain Invocation When a Requesting Workload within Trust Domain A determines that it needs to call a Protected Resource in Trust Domain B in order to complete the transaction, it follows the flow defined in this profile. The complete end-to-end sequence is illustrated in .

Transaction Token Chaining Flow | | | | | | | | | | | | | (2) Request| | | | | | Txn-Token | | | | | |----------->| | | | | | | | | | | | (3) Txn-Token | | | | |< - - - - - | | | | | | | | | | | | (4) Discover AS-B | | | | | (RFC9728) | | | | | |......................................| | | | | | | | | | (5) Token Exchange | | | | | [RFC8693] | | | | | | subject_token=Txn-Token | | | | | audience=AS-B issuer URL| | | | |------------------------>| | | | | | | | | | | (6) JWT Authorization | | | | | Grant | | | | | |< - - - - - - - - - - - -| | | | | | | | | | | (7) Present JWT Grant | | | | | [RFC7523] | | | | | |------------------------------------->| | | | | | | | | | (8) Access Token | | | | |< - - - - - - - - - - - - - - - - - - | | | | | | | | | | (9) Call Protected Resource | | | |-------------------------------------------------->| | | | | | | ]]>

The steps are as follows:

1. An inbound request arrives at the Requesting Workload's perimeter.
2. The Requesting Workload (or the first workload within Trust Domain A that receives the transaction) requests a Txn-Token from the TTS.
3. The TTS issues a Txn-Token to the Requesting Workload. The Txn-Token is scoped to Trust Domain A and MUST NOT be presented to any entity outside Trust Domain A.
4. The Requesting Workload discovers AS-B using the mechanisms defined in Section 2.2 of .
5. The Requesting Workload presents the Txn-Token as the subject_token in an OAuth 2.0 Token Exchange request to AS-A, identifying AS-B in the audience parameter and optionally specifying the target Protected Resource in the resource parameter.
6. AS-A validates the Txn-Token, applies subject identifier mapping () and claims minimization (), and issues a signed JWT Authorization Grant. The Txn-Token is consumed entirely within Trust Domain A and is not forwarded.
7. The Requesting Workload presents the JWT Authorization Grant to AS-B using the JWT Profile for OAuth 2.0 Authorization Grants .
8. AS-B validates the JWT Authorization Grant and issues an access token for the Protected Resource.
9. The Requesting Workload calls the Protected Resource with the access token, completing the cross-domain portion of the transaction.

Chaining Across Multiple Trust Domains Trust Domain A and Trust Domain B are roles when crossing from one Trust Domain to another, not fixed positions in a deployment. The profile in this specification MAY be applied recursively, allowing a single transaction to traverse any number of Trust Domains. When the Requesting Workload calls the Protected Resource in Trust Domain B (Step 9 of Figure 1), that call is an ordinary inbound request at Trust Domain B's perimeter (). The receiving workload MAY exchange the inbound access token for a Txn-Token issued by Trust Domain B's own TTS, following . If a workload in Trust Domain B's Internal Call Chain subsequently needs to call a Protected Resource in Trust Domain C, it applies this profile unchanged, with Trust Domain B now in the role of Trust Domain A and Trust Domain C in the role of Trust Domain B. Each time a Trust Domain boundary is crossed, it is self-contained and is governed solely by the Cross-Domain Trust Agreement between the two Trust Domains directly involved. The originating Authorization Server applies its own claims transcription and minimization policy , and no Txn-Token leaves its Trust Domain. Whether Authorization Server B propagates the txn claim it receives () into the access token it issues, and whether Trust Domain B's TTS includes it in the Txn-Token it mints, are deployment decisions. Deployments requiring end-to-end correlation SHOULD specify in the applicable Cross-Domain Trust Agreements how the originating transaction identifier and any other context are carried forward at each crossing. Deployments seeking to limit cross-domain linkability SHOULD instead generate independent transaction identifiers in each Trust Domain (see ).

Transaction Token as Subject Token

Subject Token Requirements When this profile is used, the subject_token in the Token Exchange request (Step 5 of ) MUST be a Txn-Token as defined in . The subject_token_type parameter MUST be: This value is defined in . The Txn-Token presented as the subject_token MUST satisfy all of the validity requirements specified in , including:

• The Txn-Token MUST NOT be expired.
• The Txn-Token MUST be signed and verifiable by AS-A using keys published by the TTS.
• The Txn-Token's aud claim MUST identify AS-A (or a value that AS-A accepts as a valid audience for presented subject tokens).

A Txn-Token failing any of the above checks MUST be rejected per Section 2.2.2 of .

Txn-Token Initiating Principal Context The Txn-Token's sub claim identifies the Initiating Principal of the transaction. The Initiating Principal type is not constrained by this profile; a Txn-Token may represent any originating context defined by the Transaction Token specification . The following are common examples:

Human User Identity:

The sub claim identifies a human user whose identity was established when the transaction entered Trust Domain A via an OAuth 2.0-protected API call. In this case the sub value is typically derived from the user's identity in the external access token presented at the API gateway, and the Txn-Token's rctx claim captures relevant attributes of the external request (such as the OAuth client identifier and originating IP address).

System Identity:

The sub claim identifies an internal system component (such as an SMTP server or a messaging gateway) acting in its own right, with no external user as the Initiating Principal. The scope claim is particularly significant in this case, as it conveys the reason for the transaction in the absence of a user-facing authorization context.

Workload Identity:

The sub claim identifies an automated workload (such as a scheduled job or pipeline service). Workload identifiers MAY take the form of SPIFFE URIs when WIMSE-compatible infrastructure is in use within Trust Domain A.

The above examples are illustrative; other Initiating Principal types are possible. The claims transcription rules in and the subject identifier mapping rules in apply regardless of which Initiating Principal type the Txn-Token represents. AS-A MUST map the sub claim to an identifier appropriate for Trust Domain B, applying the mapping logic defined in the Cross-Domain Trust Agreement for the Initiating Principal type in question.

Token Exchange Request Parameters In addition to the subject token requirements in , the Token Exchange request ( Section 2.1) MUST include the following parameters when this profile is in use.

Identifying the Target Authorization Server and Resource This profile uses the audience and resource parameters following the convention in Section 4.3. The two parameters serve distinct purposes and MUST NOT be conflated.

audience:

REQUIRED. The issuer identifier of AS-B ( Section 2). Becomes the aud claim of the JWT Authorization Grant. Implementations MUST use this parameter to identify AS-B and MUST NOT pass the AS-B issuer URL as resource.

resource:

OPTIONAL. A URI identifying the Protected Resource (resource server) in Trust Domain B, as defined in Section 2. When present, AS-A SHOULD propagate this value into the resource claim of the JWT Authorization Grant.

Remaining Parameters

grant_type:

REQUIRED. The value MUST be urn:ietf:params:oauth:grant-type:token-exchange.

subject_token:

REQUIRED. The Txn-Token as described in .

subject_token_type:

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

requested_token_type:

OPTIONAL. When present, the value MUST be urn:ietf:params:oauth:token-type:jwt. If absent, AS-A MUST still produce a JWT Authorization Grant conforming to this profile when the other parameters conform to this profile.

scope:

OPTIONAL. Space-separated list of scopes requested for the JWT Authorization Grant. AS-A MUST NOT issue a grant with scope exceeding the scope claim of the presented Txn-Token (see ).

The actor_token and actor_token_type parameters defined in are not used in this profile.

Example Token Exchange Request The following is a non-normative example conforming to this profile. A mail service workload in an enterprise (Trust Domain A) has received an SMTP message and holds a Txn-Token representing a mail-delivery transaction. The mail service needs to call a spam-rating API operated by a partner spam service whose Authorization Server is https://as.spamsvc.example and whose spam-rating API is https://api.spamsvc.example/spam-rating. grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange &subject_token= &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Atxn_token &audience=https%3A%2F%2Fas.spamsvc.example &resource=https%3A%2F%2Fapi.spamsvc.example%2Fspam-rating &scope=spam.rating.read ]]>

Token Exchange Response If the request is valid and the Requesting Workload is authorized to receive a JWT Authorization Grant for the indicated audience, AS-A returns a Token Exchange response as defined in Section 2.2 of .

access_token:

REQUIRED. The JWT Authorization Grant. (Token Exchange uses the access_token field for the returned token for historical compatibility reasons; this is not an OAuth access token.)

issued_token_type:

REQUIRED. The value MUST be urn:ietf:params:oauth:token-type:jwt.

token_type:

REQUIRED. The value MUST be N_A.

expires_in:

RECOMMENDED. The lifetime of the JWT Authorization Grant in seconds. This value SHOULD reflect the exp claim of the returned grant JWT and SHOULD be short (see ).

refresh_token:

This parameter SHOULD NOT be present.

On error, AS-A returns an error response as defined in Section 5.2 of and Section 2.2.2 of . ...", "issued_token_type": "urn:ietf:params:oauth:token-type:jwt", "token_type": "N_A", "expires_in": 60 } ]]>

Processing Rules

AS-A Processing Rules Upon receipt of a Token Exchange request conforming to this profile, AS-A MUST perform the following steps:

1. Authenticate the client (Requesting Workload) using the mechanisms specified in Section 5.1 of and Section 2.5 of .
2. Validate the Txn-Token signature using the public keys of the TTS that issued it. AS-A MUST be configured with the TTS's jwks_uri or equivalent key material.
3. Validate that the Txn-Token is not expired.
4. Validate that the aud claim of the Txn-Token identifies AS-A or a value AS-A is configured to accept as a valid audience for presented subject tokens.
5. Verify that the audience value identifies a known AS-B for which a Cross-Domain Trust Agreement has been established. AS-A MUST NOT accept a resource server URI in audience in place of an AS-B issuer identifier. If the audience is unknown or disallowed by policy, AS-A MUST return an error per Section 2.2.2 of .
6. If the resource parameter is present, validate that it identifies a Protected Resource within Trust Domain B consistent with the indicated AS-B. AS-A SHOULD propagate the resource value into the resource claim of the JWT Authorization Grant.
7. Validate that the requested scope, if present, does not exceed the scope claim of the Txn-Token. AS-A MUST NOT issue a JWT Authorization Grant with broader scope than the Txn-Token asserts.
8. Determine the Initiating Principal type from the Txn-Token and apply the appropriate subject identifier mapping as described in . If no mapping can be determined, AS-A MUST return an error.
9. Apply claims transcription and minimization policy as described in .
10. Construct and sign the JWT Authorization Grant as described in , setting the aud claim to the AS-B issuer identifier resolved in step 5.
11. Return the JWT Authorization Grant in the Token Exchange response as described in .

AS-B Processing Rules Upon receipt of a JWT Bearer grant request () conforming to this profile, AS-B MUST perform the following steps in addition to the processing rules specified in Section 2.4.2 of :

1. Validate the typ header of the JWT Authorization Grant. The value MUST be txn-chain+jwt as defined in .
2. Validate that the aud claim matches AS-B's own issuer identifier.
3. Validate that the iss claim identifies an AS-A with which a Cross-Domain Trust Agreement has been established, and validate the JWT signature using the public keys advertised by that AS-A.
4. Validate that the JWT is not expired and that the jti value has not been previously presented (single-use enforcement).
5. Resolve the subject from the sub claim according to the mapping rules defined in the Cross-Domain Trust Agreement. AS-B SHOULD evaluate the sub claim against its configured cross-domain access policy; supplementary identifiers in txn_claims (e.g., email) MAY also be used for subject resolution where the Cross-Domain Trust Agreement permits. If subject resolution fails and the Cross-Domain Trust Agreement does not permit Just-In-Time provisioning, AS-B MUST return an error.
6. If present, evaluate the txn_claims claim to apply context-aware authorization policy (see ), for example verifying that the scope value is consistent with the requested scope.
7. Issue an access token constrained by the scope and, if present, the resource claim in the JWT Authorization Grant. AS-B SHOULD NOT issue refresh tokens, consistent with Section 5.4 of .

JWT Authorization Grant

Grant Format The JWT Authorization Grant produced by AS-A in response to a Token Exchange request conforming to this profile is a JWT that MUST conform to the JWT Authorization Grant requirements specified in Section 2.3.3 of .

JWT Header

typ:

REQUIRED. The value MUST be txn-chain+jwt ().

alg:

REQUIRED. An asymmetric signing algorithm. Deployments SHOULD use PS256, PS384, PS512, ES256, ES384, or ES512 as defined in . The none algorithm and symmetric algorithms are prohibited.

kid:

RECOMMENDED. The key identifier corresponding to the signing key.

JWT Claims Requirements The following claims MUST be present:

iss:

REQUIRED. The Issuer identifier of AS-A ( Section 2).

sub:

REQUIRED. The Initiating Principal's identity as mapped by AS-A according to . The value MUST be meaningful to AS-B within the context of the Cross-Domain Trust Agreement.

aud:

REQUIRED. The Issuer URL of AS-B, derived from the audience parameter of the Token Exchange request. MUST be a single value.

iat:

REQUIRED. Issuance time ( Section 4.1.6).

exp:

REQUIRED. Expiration time ( Section 4.1.4). The lifetime SHOULD be short. Deployments SHOULD use a value no greater than 300 seconds and SHOULD prefer values of 60 seconds or less, consistent with the short-lived nature of Txn-Tokens.

jti:

REQUIRED. A unique identifier for this JWT ( Section 4.1.7). AS-B MUST enforce single-use semantics by tracking presented jti values within the grant's validity window.

scope:

RECOMMENDED. The authorized scope ( Section 3.3). MUST NOT be wider than the scope claim of the source Txn-Token.

The following claims SHOULD be present:

txn:

The unique transaction identifier from the originating Txn-Token (). AS-B SHOULD record this value in its audit logs.

The following claims MAY be present:

resource:

A URI or array of URIs identifying the Protected Resource(s) in Trust Domain B ( Section 2), derived from the resource parameter of the Token Exchange request. AS-B SHOULD use this to issue a resource-bound access token.

txn_claims:

A JSON object containing a curated subset of Txn-Token claims, selected and minimized per the policy in . AS-B MAY use these claims for context-aware authorization decisions.

cnf:

If sender-constraining is in use (see ), the confirmation method claim conveying the Requesting Workload's public key, as defined in .

Example JWT Authorization Grant The following is a non-normative example corresponding to the mail service scenario in . The Initiating Principal is the mail service's system identity (mail-gateway@enterprise.example) and the Txn-Token's rctx carries the SMTP envelope sender. The scope and a minimized rctx are transcribed into txn_claims. Header: Claims: The aud claim (https://as.spamsvc.example) identifies the authorization server of Trust Domain B. The resource claim (https://api.spamsvc.example/spam-rating) identifies the specific API endpoint. These are distinct values serving distinct purposes.

Claims Transcription This profile constrains and extends the claims transcription rules of Section 2.5 of as follows.

Mandatory Transcriptions AS-A MUST derive the sub claim of the JWT Authorization Grant from the sub claim of the Txn-Token, applying the subject identifier mapping defined in . AS-A MUST include the txn claim from the Txn-Token as the txn claim in the JWT Authorization Grant, preserving the transaction correlation identifier across the domain boundary.

Constrained Scope Transcription The scope in the JWT Authorization Grant MUST be the intersection of the Txn-Token's scope claim and the scope parameter of the Token Exchange request (if present). AS-A MUST NOT expand scope beyond the Txn-Token's scope under any circumstances.

Subject Identifier Mapping The sub claim of the Txn-Token identifies the Initiating Principal within Trust Domain A's namespace. AS-A MUST translate this identifier to a form that is both meaningful and authorized for use in Trust Domain B, according to the mapping rules defined in the Cross-Domain Trust Agreement. The Cross-Domain Trust Agreement MUST define mapping rules for every Initiating Principal type that may appear in Txn-Tokens exchanged under this profile. If no mapping can be determined for the Initiating Principal presented, AS-A MUST deny the Token Exchange request.

Claims Minimization Txn-Tokens MUST NOT be forwarded across trust boundaries. The JWT Authorization Grant is the only artifact that crosses the boundary, and AS-A MUST apply strict claims minimization. The optional txn_claims object in the JWT Authorization Grant MAY carry a curated subset of Txn-Token claims that are relevant to AS-B's authorization policy. AS-A MUST apply the following minimization rules:

Scope Claim (scope):

SHOULD be included when it is meaningful to AS-B's authorization policy (e.g., to enable the Protected Resource to apply different handling based on transaction type).

Requester Context (rctx):

MAY be included in a minimized form. Information relevant to the cross-domain request (e.g., the originating client IP address for a user-initiated transaction, or the SMTP envelope sender address for a mail delivery transaction) MAY be included. Internal network addresses, intermediate workload identifiers, and internal infrastructure topology details MUST be omitted.

Internal Call Chain:

Claims that record intermediate workloads or the internal call chain within Trust Domain A MUST NOT be included in txn_claims.

Supplementary Identity Claims:

For human user Initiating Principals, claims such as email MAY be included in txn_claims if the Cross-Domain Trust Agreement explicitly permits their disclosure and AS-B requires them for subject resolution.

The Cross-Domain Trust Agreement SHOULD define the set of claims permitted to appear in txn_claims and their expected semantics.

Authorization Server Metadata This profile adds to the Authorization Server Metadata framework defined in and Section 3 of . An Authorization Server that supports this profile MUST include the value urn:ietf:params:oauth:token-type:txn_token in its identity_chaining_requested_token_types_supported metadata parameter.

Security Considerations

Client Authentication The Requesting Workload MUST authenticate to AS-A when performing the Token Exchange request. The use of asymmetric key-based client authentication (e.g., a JWT client assertion per ) is RECOMMENDED. Static shared secrets SHOULD NOT be used. AS-A SHOULD follow the client authentication guidance in Section 2.5 of .

Sender Constraining Tokens AS-B SHOULD issue sender-constrained access tokens. Both DPoP (OAuth 2.0 Demonstrating Proof of Possession) and Mutual-TLS ( Section 2.3) are RECOMMENDED mechanisms. When AS-A acts as the client toward AS-B (the authorization-server- as-client topology described in Appendix B.2 of ), the delegated key binding mechanism described in Appendix B.3 of that document SHOULD be used. AS-A MUST verify proof of possession of the Requesting Workload's key and convey it to AS-B using the cnf claim in the JWT Authorization Grant.

Txn-Token Confidentiality A Txn-Token MUST NOT be forwarded to any entity outside Trust Domain A. All communication between the Requesting Workload and AS-A MUST be encrypted and the Requesting Workload MUST be authenticated (e.g., via mutual TLS; see also ). Txn-Token lifetimes SHOULD be short.

JWT Authorization Grant Replay Prevention The JWT Authorization Grant is a bearer token. AS-B MUST enforce single-use semantics on the jti claim. AS-A SHOULD set a short validity lifetime (see ). Additional guidance is provided in Section 5.5 of .

Scope Boundary Enforcement AS-A MUST enforce that the JWT Authorization Grant scope does not exceed the Txn-Token's scope. AS-B MUST independently enforce that the access token it issues does not convey scope exceeding the JWT Authorization Grant. These controls together prevent the chaining mechanism from being used to escalate privileges beyond the originating transaction's authorized scope.

Cross-Domain Trust Agreement Integrity Operators MUST ensure that:

• AS-A issues JWT Authorization Grants only for AS-B instances with which a bilateral Cross-Domain Trust Agreement has been explicitly established and is actively maintained.
• AS-B accepts JWT Authorization Grants only from AS-A instances listed in its trusted issuers configuration.
• The Cross-Domain Trust Agreement, including subject identifier mappings and permitted txn_claims, is reviewed whenever the participating services or their authorization policies change.

Refresh Tokens AS-B SHOULD NOT issue refresh tokens. Because Txn-Tokens are short-lived and transaction-specific, re-obtaining a new Txn-Token and repeating the chaining flow is the correct renewal mechanism. Issuing a refresh token would decouple the access lifetime from the originating transaction's authorization context and create a persistent credential outside the control of Trust Domain A.

Trust Across Multiple Trust Domains When this profile is applied recursively (), trust remains strictly pairwise. An Authorization Server accepts a JWT Authorization Grant because it trusts the issuing Authorization Server under their Cross-Domain Trust Agreement, not because it has any relationship with Trust Domains further upstream. Because context propagation each time a Trust Domain boundary is crossed is a deployment decision (), claims in a JWT Authorization Grant may be derived from context that the issuing Trust Domain itself received from an upstream Trust Domain.

Privacy Considerations Txn-Tokens may contain claims that relate to the Initiating Principal, including personal identity information for human-user-initiated transactions (e.g., user identifier, email address, IP address) that may be subject to applicable privacy regulations. AS-A MUST apply claims minimization () before issuing a JWT Authorization Grant. Specifically:

• Only identity claims necessary for AS-B to resolve the subject and apply authorization policy SHOULD be included in txn_claims.
• Claims that could be used to reconstruct internal activity patterns within Trust Domain A MUST NOT be included.
• The Cross-Domain Trust Agreement MUST specify which identity claims AS-A is permitted to disclose to AS-B, consistent with the data handling and privacy policies of both organizations.

The txn claim enables end-to-end transaction correlation across the domain boundary. Operators SHOULD evaluate whether the auditability benefits outweigh the privacy implications for their specific deployment, particularly for human-user-initiated transactions.

IANA Considerations

JWT Typ Registration This specification requests registration of the following value in the "JSON Web Signature and Encryption Header Parameters" registry (maintained by IANA):

• Header Parameter Name: txn-chain+jwt
• Header Parameter Description: JWT type for a Transaction Token Chaining Authorization Grant as defined in this document
• Change Controller: IETF
• Specification Document(s): of this document

JWT Claims Registry This specification requests registration of the following claim name in the "JSON Web Token Claims" registry (maintained by IANA):

• Claim Name: txn_claims
• Claim Description: Transcribed claims from a Transaction Token, included in a JWT Authorization Grant to convey cross-domain authorization context
• Change Controller: IETF
• Specification Document(s): of this document

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] JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. 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 describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. 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 document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure. This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. Defakto Security Defakto Security MITRE NSA-CCSS Ping Identity Okta SGNL Practical Identity LLC Defakto Security Informative References This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. CyberArk Zscaler Ping Identity CyberArk Defakto Security Intuit Zscaler Okta Independent Ping Identity

Use Cases The following use cases illustrate the three Initiating Principal types described in , each demonstrating a scenario where a workload within a Trust Domain must call a partner service in a separate Trust Domain to complete the transaction.

User-Initiated External API Call Requiring a Partner Service A financial services enterprise exposes a portfolio management API to its customers. A customer uses a mobile application to add a stock to their watch list, calling POST /watchlist at the enterprise's API gateway with an OAuth 2.0 access token. The API gateway workload requests a Txn-Token from the TTS, presenting the user's access token as the inbound credential. The TTS mints a Txn-Token with sub set to the user's enterprise identifier, scope set to watchlist-update, and rctx capturing the mobile client's OAuth client identifier and IP address. This Txn-Token propagates through the internal portfolio service call chain. To enrich the watch list entry with current market data, the portfolio service must call a market-data API operated by a partner financial data provider in Trust Domain B. The portfolio service exchanges the Txn-Token for a JWT Authorization Grant using this profile. AS-A maps the user's enterprise identifier to a cross-domain user identifier agreed with the partner (e.g., the user's email address or a pairwise identifier), and includes a minimized txn_claims carrying scope: watchlist-update. The partner's authorization server issues an access token that identifies the user (enabling per-user rate limiting and audit logging at the partner) without receiving the enterprise's internal Txn-Token, internal access token, or internal user database identifiers.

System-Initiated Event Requiring a Partner Service An enterprise mail service receives an inbound email message via SMTP. The SMTP server is an internal system component operating under its own system credential; no external OAuth client is involved. The SMTP server requests a Txn-Token from the TTS with sub set to its system identity (system:mail-gateway@enterprise.example), scope set to mail-delivery, and rctx carrying the SMTP envelope sender address and the recipient user's internal identifier. This Txn-Token propagates to the mail storage service workload. Before storing the message in the recipient's mailbox, the mail storage service must call a spam-rating API operated by a partner spam service in Trust Domain B (whose Authorization Server is https://as.spamsvc.example and whose spam-rating API is https://api.spamsvc.example/spam-rating). The mail storage service exchanges the Txn-Token for a JWT Authorization Grant using this profile. AS-A maps the system identity to the cross-domain service identifier agreed with the spam service, and includes a minimized txn_claims carrying scope: mail-delivery and rctx.smtp_from (the envelope sender address, stripped of internal routing metadata). The spam service's authorization server issues an access token for the spam-rating API. The spam service can apply per-sender and per-recipient policy based on txn_claims, enabling personalized spam filtering without requiring the enterprise to expose internal user tokens or the Txn-Token outside its trust boundary.

Automated Workload Requiring a Partner Service An enterprise data platform runs a nightly telemetry aggregation job. The job is an automated workload with no direct external caller, triggered by an internal scheduler. The scheduler requests a Txn-Token from the TTS with sub set to the job's SPIFFE workload URI (spiffe://enterprise.example/telemetry/nightly-agg), scope set to telemetry-aggregation, and no user context in rctx. To complete the aggregation, the job must query a third-party analytics API in Trust Domain B. The job exchanges the Txn-Token for a JWT Authorization Grant using this profile. AS-A maps the SPIFFE workload URI to a cross-domain workload identifier agreed with the analytics provider, and includes scope: telemetry-aggregation in txn_claims. The analytics provider's authorization server issues a scoped access token. The txn claim in the JWT Authorization Grant allows the analytics provider to correlate API calls to the originating job run for billing and audit purposes, without receiving the internal SPIFFE URI or other Trust Domain A infrastructure details.

Relationship to Related Specifications This specification is one of a family of profiles of .

Identity Assertion JWT Authorization Grant (the "ID-JAG" specification, adopted by the OAuth Working Group as of April 2026) targets deployments where AS-B already trusts AS-A (acting as an IdP) for Single Sign-On (SSO) and subject resolution, using an OpenID Connect ID Token or SAML 2.0 assertion as the subject token. The key structural differences between the two profiles are:

Subject Token Type:

The ID-JAG profile uses an OpenID Connect ID Token or SAML 2.0 assertion as the subject_token. This profile uses a Txn-Token (urn:ietf:params:oauth:token-type:txn_token).

Initiating Principal Scope:

The ID-JAG profile is exclusively centered on a human End-User whose authenticated session at the IdP drives the cross-domain access. This profile supports all three Initiating Principal types — human user, internal system, and automated workload — uniformly, because Txn-Tokens capture all three.

Trust Relationship Basis:

The ID-JAG profile relies on a pre-existing SSO trust relationship between AS-A (the IdP) and AS-B (the Resource AS) for the same user population. This profile relies on a bilateral Cross-Domain Trust Agreement between AS-A and AS-B, which may exist independently of any shared identity provider.

audience and resource Parameters:

Both profiles use audience to identify AS-B (the target authorization server) and resource () optionally to identify the target Protected Resource. These parameters serve the same distinct purposes in both profiles: audience → AS-B issuer URL → aud in the grant; resource → resource server URI → resource claim in the grant.

client_id Requirement:

The ID-JAG includes a REQUIRED client_id claim identifying the OAuth 2.0 client at AS-B acting on behalf of the resource owner. This is appropriate where the application has a pre-registered client relationship with AS-B. This profile does not require a pre-registered client_id at AS-B; the Requesting Workload's identity is conveyed through client authentication to AS-A and the subject mapping in the JWT Authorization Grant.

Multi-Tenancy:

The ID-JAG profile defines tenant, aud_tenant, and aud_sub claims for multi-tenant SaaS deployments. This profile does not define equivalent tenant-scoping claims, as Trust Domain boundaries are typically organizational or service-provider boundaries rather than tenant partitions within a shared platform.

Rich Authorization Requests (RAR):

The ID-JAG profile supports the optional authorization_details claim () in the grant. This profile does not currently define RAR integration; a future revision MAY define how authorization_details from a Txn-Token are transcribed into the JWT Authorization Grant.

SAML 2.0 Interoperability:

The ID-JAG profile includes SAML 2.0 identity assertion interoperability. This profile addresses only JWT-based Txn-Tokens.

Sender Constraining:

Both profiles use the cnf claim to convey a sender-constraining key to AS-B. The ID-JAG profile embeds cnf in the ID-JAG itself; this profile includes cnf in the JWT Authorization Grant, derived from the Requesting Workload's client credential presented to AS-A (see ).

The two profiles are complementary. A deployment MAY support both: the ID-JAG profile for human-user cross-domain access coordinated through a shared identity provider, and this profile for any transaction-driven cross-domain access (user-initiated, system-initiated, or workload-initiated) where the trust relationship is established through a bilateral Cross-Domain Trust Agreement. An Authorization Server implementing both MUST distinguish between them by inspecting the JWT typ header: oauth-id-jag+jwt for the ID-JAG profile and txn-chain+jwt for this profile.

Acknowledgements The author would like to thank Atul Tulshibagwale, Pieter Kasselman, Aaron Parecki, Brian Campbell, Arndt Schwenkschuster, Kelley Burgin, Karl McGuinness, and the members of the IETF OAuth Working Group for their foundational work on the specifications that this profile depends on. The Transaction Tokens concept was originally developed by Atul Tulshibagwale, George Fletcher, and Pieter Kasselman. The OAuth Identity and Authorization Chaining Across Domains specification was authored by Arndt Schwenkschuster, Pieter Kasselman, Kelley Burgin, Michael Jenkins, Brian Campbell, and Aaron Parecki.

Document History [[ To be removed from final specification ]]

Since Draft 01

• Added Pieter Kasselman and Sean O'Dell as authors
• Fixed the sequence diagram in section 3.2
• Streamlined the text descriptions for the sequence in section 3.2
• Cleaned up language that used purpose instead of scope