]> CrowdStrike

atul.tulshibagwale@crowdstrike.com

Security Web Authorization Protocol OAuth access token transaction token AI agents OAuth 2.0 access tokens are typically scoped to a session rather than to a transaction. They carry no transaction identifier and no context beyond scope. This document defines Transactional Access Tokens: a profile of JSON Web Token (JWT) access tokens that carries a transaction identifier and authorization server-asserted transaction context, has a very short lifetime, and is audienced to a single resource server. Transactional Access Tokens align with the claims and semantics of OAuth Transaction Tokens, so that transaction context can flow from the authorization server to a resource server and onward into that resource server's trust domain. A primary use case is task-scoped authorization of AI agents, where the authorization server makes a fresh policy decision for each transaction. About This Document Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at .

Introduction OAuth 2.0 access tokens represent an authorization grant for a session. Access token lifetimes are often short, but the authority behind them is durable: a client holding a refresh token or client credential can obtain new access tokens without any per-transaction decision by the authorization server (AS). Access tokens convey what the client may do (typically via scope), but they do not convey why, in what transaction, or under what context. OAuth Transaction Tokens (Txn-Tokens) address a related problem inside a trust domain. A Txn-Token is short-lived, carries a transaction identifier (txn) and transaction context, and is audienced to the trust domain rather than to any single workload. Txn-Tokens are not intended for use across trust domain boundaries, and a resource server outside the trust domain that issued a Txn-Token receives none of that context. This document defines Transactional Access Tokens (Txn-ATs). A Txn-AT is an OAuth access token, based on the JWT access token profile , that also carries the transaction identifier and context semantics of a Txn-Token. Unlike a Txn-Token, a Txn-AT is audienced to a single resource server. Txn-ATs provide the following benefits:

1. Resource servers receive AS-asserted transaction context, not only scope.
2. A client, such as an AI agent authorized for a specific task, can be issued a token bounded to that task, with no more durable permission than the task requires. The AS evaluates policy for every transaction and can deny any individual transaction, placing the AS in control of each authorization decision.
3. The transaction identifier and context can be carried from the resource server into its own trust domain via Txn-Tokens ().

In the model defined here, consent and client authority are durable, while tokens are per-transaction.

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.

Terminology This document uses the terms "access token", "authorization server", "client", "refresh token", and "resource server" defined in , and the terms "Transaction Token", "Txn-Token", "Transaction Token Service", "trust domain", and "workload" defined in .

Transactional Access Token (Txn-AT):

An access token conforming to this specification.

Transaction:

A unit of work, such as an AI agent task, for which the AS makes an authorization decision and which may span requests to one or more resource servers.

Internal Transaction Identifier (ITID):

A value generated by the AS that uniquely identifies a transaction. The ITID is known only to the AS and is never disclosed to clients or resource servers.

Transaction Handle:

An opaque value issued by the AS to a client, which the client uses to request additional Txn-ATs for the same transaction.

Transaction Context:

Context about a transaction that the AS asserts in a Txn-AT, after evaluating policy and the request context.

Overview

Transactional Access Token Flow | | | | (2) Txn-AT (aud=RS1, txn=T1) | Authorization | | | + txn_handle | Server | | |<-------------------------------| (policy on | | Client | (3) Token Request | every request)| | | (resource=RS2, txn_handle) | | | |------------------------------->| | | | (4) Txn-AT (aud=RS2, txn=T2) | | | |<-------------------------------| | | | +---------------+ | | (5) Txn-AT (aud=RS1) +-----+ (7) Txn-Token | |---------------------->| RS1 |---> (txn=T1) ---> internal | | (6) Txn-AT (aud=RS2) +-----+ workloads | |---------------------->| RS2 | +--------+ +-----+ ]]>

1. The client requests a Txn-AT for resource server RS1 using a supported grant ().
2. The AS evaluates policy and issues a Txn-AT audienced to RS1. The Txn-AT carries a txn value derived for RS1. The AS also returns a transaction handle.
3. For the same transaction, the client requests a Txn-AT for RS2 and presents the transaction handle.
4. The AS evaluates policy again and issues a Txn-AT audienced to RS2, with a different txn value that cannot be correlated with the value for RS1.
5. and 6. The client presents each Txn-AT to its resource server.
6. A resource server MAY exchange the Txn-AT for a Txn-Token within its own trust domain ().

Token Format A Txn-AT is a JWT that conforms to , except as modified by this section.

JOSE Header Txn-ATs MUST include the typ header parameter with the value txnat+jwt. This deviates from , which requires at+jwt. The distinct type is intentional: it causes resource servers that do not implement this specification to reject Txn-ATs, rather than accept them as ordinary access tokens and ignore their transactional semantics. It also prevents confusion between Txn-ATs, ordinary JWT access tokens, and Txn-Tokens ().

Claims The following claims are used in Txn-ATs. Claims not listed here MAY be included as permitted by , subject to . Txn-AT Claims

Claim	Requirement	Description
iss	REQUIRED	As defined in .
aud	REQUIRED	Identifier of exactly one resource server. MUST be a single string value.
sub	REQUIRED	As defined in . See regarding pairwise identifiers.
client_id	REQUIRED	As defined in .
iat	REQUIRED	As defined in .
exp	REQUIRED	See .
jti	REQUIRED	Unique per token. MUST NOT be derived from the ITID.
txn	REQUIRED	Transaction identifier, as defined in and generated per .
tctx	RECOMMENDED	Transaction context asserted by the AS, with semantics as defined in . See .
rctx	OPTIONAL	Requester context asserted by the AS, with semantics as defined in . See .
scope	OPTIONAL	Scope granted for this transaction.
authorization_details	OPTIONAL	Granted authorization details, as defined in .
act	CONDITIONAL	REQUIRED when the Txn-AT is issued via token exchange with an actor token, as defined in .
cnf	CONDITIONAL	REQUIRED when the Txn-AT is sender-constrained.

Transaction Identifier Generation When the AS begins a new transaction, it MUST generate an ITID with at least 128 bits of entropy. The txn value in each Txn-AT MUST satisfy the following requirements:

• It MUST be the same for all Txn-ATs issued for the same transaction and the same audience.
• It MUST be different for different audiences in the same transaction.
• It MUST NOT allow any party other than the AS to determine whether two txn values with different audiences belong to the same transaction.
• It MUST NOT disclose the ITID.

Any method satisfying the requirements above is acceptable, such as a random value per audience with a mapping table stored at the AS. For one possible construction using keyed derivation, see .

Transaction Context The AS alone determines the values of tctx and rctx, based on policy and the request context. The AS MUST NOT copy client-supplied values into tctx or rctx without first evaluating them against policy. If the AS supports , it MAY use authorization_details from the request as an input to policy. The AS MUST NOT copy authorization_details into tctx unless it has evaluated them against policy. If both authorization_details and tctx appear in a Txn-AT:

• authorization_details represents what was granted; and
• tctx represents the context the AS asserts about the transaction.

Inputs the AS MAY use when determining transaction context include:

• the authenticated subject and the properties of that authentication, such as authentication time, method, and assurance level;
• the client's registration metadata and authentication method, and any client or workload attestation;
• claims in a subject token or actor token, in token exchange flows;
• the resource indicator (), scope, and authorization_details in the request;
• the Txn-Token request context parameters defined in ;
• properties of the request environment that the AS observes, such as the source network address; and
• the results of policy evaluation for the transaction.

The AS SHOULD include in tctx and rctx only the context that the audience resource server needs ().

Token Lifetime Txn-ATs are intended to be valid for about as long as a single transaction.

• The difference between exp and iat SHOULD NOT exceed 300 seconds.
• The AS SHOULD choose the shortest lifetime compatible with the expected duration of the transaction.
• The AS MUST NOT issue a Txn-AT whose exp is later than the expiry of the associated transaction handle, if one exists.

Token Request

Supported Grants Txn-ATs MUST be issued only at the token endpoint, using one of the following grants:

• Token Exchange ;
• the refresh token grant (); or
• the client credentials grant ().

The AS MUST NOT issue Txn-ATs directly from the authorization code grant. Requiring user interaction such as consent or credential entry for every transaction is unrealistic and would disrupt the user experience. Instead, the authorization code grant MAY be used once to obtain user consent and a refresh token, which the client then uses to request Txn-ATs without further user involvement. The token exchange grant is used when the client holds a source token, for example a token representing the user as the subject and the client (such as an AI agent) as the actor. In this case the request resembles a Txn-Token request as defined in .

Requesting a Txn-AT To request a Txn-AT, the client includes the requested_token_type parameter with the value urn:ietf:params:oauth:token-type:txn_access_token.

• With the token exchange grant, this parameter is used as defined in .
• This document also permits this parameter with the refresh token and client credentials grants, where it has the same meaning.

If the client's registration metadata includes transactional_access_tokens_required with the value true (), the AS MUST issue only Txn-ATs to that client, whether or not requested_token_type is present.

Request Parameters The following parameters apply to Txn-AT requests:

resource:

REQUIRED. Exactly one resource indicator, as defined in , identifying the resource server the Txn-AT is for. If the request contains zero or more than one resource value, the AS MUST reject it with the invalid_target error. In token exchange requests, the client SHOULD NOT use the audience parameter. If it does use it, the resulting audience MUST resolve to a single resource server.

txn_handle:

OPTIONAL. A transaction handle previously issued to this client (). If present, the request is for an additional Txn-AT in the existing transaction. If absent, the AS begins a new transaction.

scope, authorization_details:

OPTIONAL. As defined in and . These are inputs to policy only ().

Txn-Token request context parameters:

OPTIONAL. Clients MAY include the request context and request details parameters defined in . These are inputs to policy only. The AS MUST NOT copy them into tctx or rctx without evaluation.

Extension parameters:

The AS MAY accept additional parameters as policy inputs, subject to the same rule.

Policy Evaluation The AS MUST evaluate policy for every Txn-AT request. The AS MAY deny a request even when the presented grant, credential, refresh token, or transaction handle is valid. When the request includes a transaction handle, the AS MAY enforce transaction-level policy, for example:

• limiting the set of resource servers the transaction may access;
• limiting the number of Txn-ATs issued for the transaction; or
• limiting the transaction's total duration.

If the AS denies a request on policy grounds, it MUST return the transaction_denied error ().

Transaction Handle When the AS begins a new transaction, it MUST include a transaction handle in the token response (). The transaction handle:

• MUST be opaque to the client and MUST contain at least 128 bits of entropy;
• MUST be bound to the client to which it was issued. The AS MUST reject a handle presented by a different client;
• MUST be bound to the transaction's subject. In token exchange requests, the AS MUST reject a handle if the subject of the presented subject token differs from the transaction's subject;
• SHOULD be bound to the same key as the Txn-ATs, when Txn-ATs are sender-constrained;
• MUST have an expiry set by the AS; and
• MUST NOT be included in any Txn-AT or otherwise disclosed to resource servers.

If the handle is unknown, expired, or fails any of the binding checks above, the AS MUST return the invalid_txn_handle error.

Token Response A successful response follows and, for token exchange, , with these additions:

• The issued_token_type parameter, if present, MUST be urn:ietf:params:oauth:token-type:txn_access_token.
• The txn_handle parameter MUST be present when a new transaction was started. It MAY be present in responses for an existing transaction.
• In token exchange responses, the AS MUST NOT include a refresh token.
• In refresh token grant responses, the AS MAY rotate the refresh token as described in .

Errors In addition to the errors defined in , , and , this document defines the following token endpoint errors:

invalid_txn_handle:

The transaction handle is unknown, expired, or not bound to this client or subject.

transaction_denied:

The AS denied the transaction based on policy.

Resource Server Processing A resource server that accepts Txn-ATs MUST validate them as specified in , with the following modifications:

1. The resource server MUST verify that the typ header is txnat+jwt.
2. The resource server MUST verify that aud is a single value that identifies itself.
3. The resource server MUST verify that txn is present.
4. If the Txn-AT contains a cnf claim, the resource server MUST verify proof of possession, for example as specified in or .
5. The resource server MUST NOT accept a Txn-Token (typ value txntoken+jwt) as a Txn-AT.

A resource server MAY use tctx and rctx in its own authorization decisions, and SHOULD record txn in audit logs. A resource server that requires Txn-ATs for a resource MUST reject ordinary access tokens (typ value at+jwt) for that resource.

Interoperability with Transaction Tokens A resource server may call workloads within its own trust domain. In that case, it SHOULD obtain a Txn-Token from its Transaction Token Service (TTS), rather than forwarding the Txn-AT, as follows:

• The resource server presents the Txn-AT as the subject_token, with a subject_token_type of urn:ietf:params:oauth:token-type:txn_access_token.
• The TTS MUST validate the Txn-AT as specified in , including verifying that aud identifies the resource server presenting it.
• The TTS SHOULD set the Txn-Token's txn to the txn value from the Txn-AT. This preserves correlation within the resource server's trust domain without enabling correlation with other resource servers.
• The TTS MAY use the Txn-AT's tctx and rctx as inputs when determining the Txn-Token's context, subject to the TTS's own policy.

Workloads MUST NOT accept a Txn-AT in place of a Txn-Token.

Security Considerations The security considerations of , , , , and apply.

Token Confusion Txn-ATs share claims with both JWT access tokens and Txn-Tokens, which creates a risk of token confusion. The distinct typ value and a single-valued aud claim mitigate this risk:

• resource servers reject Txn-Tokens, whose aud identifies a trust domain and whose typ is txntoken+jwt;
• workloads reject Txn-ATs, whose typ is txnat+jwt; and
• resource servers that do not implement this specification reject Txn-ATs because of their typ value.

Implementations MUST validate both typ and aud.

Replay A bearer Txn-AT can be replayed within its lifetime. This document accepts that risk in exchange for keeping resource servers stateless, and bounds it with a short lifetime (). Txn-ATs SHOULD be sender-constrained using DPoP or mutual TLS . Sender-constraining is especially important for AI agents, where tokens may be exfiltrated through prompt injection or tool misuse. Resource servers that need single-use semantics can track jti values, but this document does not require it.

Durable Credentials The refresh tokens and client credentials used to obtain Txn-ATs remain durable. The security benefit of Txn-ATs depends on the AS evaluating policy for every request and being able to deny individual transactions. An attacker who obtains such a credential can request Txn-ATs, but remains subject to per-transaction policy. Refresh tokens used to obtain Txn-ATs SHOULD be sender-constrained or rotated as described in .

Transaction Handle Theft A stolen transaction handle alone does not allow an attacker to obtain Txn-ATs, because the handle is bound to the client, and to the subject and sender-constraining key where applicable ().

Context Integrity Resource servers rely on tctx and rctx being asserted by the AS. Because the AS never echoes unevaluated client input into these claims (), a client cannot inject context into a Txn-AT. An AS that fails to follow this rule would turn Txn-ATs into signed but unverified assertions.

Generating Transaction Identifiers One way to generate txn values satisfying the requirements in is keyed derivation: where:

• K_txn is a secret key of at least 256 bits, known only to the AS and used only for this purpose;
• ITID is the internal transaction identifier, which MUST be of fixed length for a given K_txn;
• aud is the value of the Txn-AT's aud claim;
• || denotes concatenation;
• HMAC is as defined in ; and
• BASE64URL is base64url encoding without padding.

The output MAY be truncated to no fewer than 128 bits. Keyed derivation lets the AS recompute the txn value for any transaction and audience without storing a mapping. The AS can therefore correlate a transaction across resource servers for audit, while no other party can. An AS that rotates K_txn needs to retain retired keys, or record which key each transaction used, for as long as it requires this audit capability.

Compromise of K_txn Disclosure of K_txn allows the holder, together with knowledge of ITIDs, to correlate txn values across resource servers. It does not allow forging Txn-ATs. Because ITIDs are never disclosed outside the AS, correlating txn values additionally requires access to AS internal state. The AS SHOULD protect K_txn with the same rigor as its token signing keys.

Clock Skew Short lifetimes increase sensitivity to clock skew. Resource servers SHOULD allow no more than a small leeway, such as 30 seconds, when validating exp and iat.

Privacy Considerations

Transaction Correlation Per-audience txn values () prevent resource servers from using txn to correlate a transaction across resource servers. Only the AS can link a transaction across resource servers. Cross-resource-server forensic analysis therefore requires the AS's cooperation. This is an intentional trade-off.

Other Correlating Claims Other claims can still enable correlation, even when txn values differ:

• sub: The AS SHOULD use pairwise subject identifiers per resource server, similar to the pairwise identifiers defined in .
• client_id: This claim is the same across resource servers. Correlation of the client's activity is therefore inherent.
• jti: This claim MUST NOT be derived from the ITID or from txn.
• tctx and rctx: The AS SHOULD include only the context the audience resource server needs, and SHOULD avoid stable identifiers that would enable correlation.
• Timing: Tokens for the same transaction are issued close together in time. Resource servers that collude may be able to correlate transactions by timing. This residual risk is not addressed by this document.

AS as Observer The AS observes every transaction. AS operators SHOULD apply retention limits and access controls to transaction records.

Operational Considerations Issuing a token for every transaction places the AS on the critical path of each transaction:

• Token issuance latency adds directly to transaction latency.
• AS availability becomes critical to the resource servers that require Txn-ATs.
• Issuance volume scales with the number of transactions rather than the number of sessions.

Deployments should plan for:

• low-latency policy evaluation
• low-latency signing
• regional or distributed AS deployment
• capacity planning based on transaction rates, and
• If applicable, management of K_txn, including rotation and retention of retired keys.

IANA Considerations

Media Type Registration IANA is requested to register the following media type in the "Media Types" registry:

• Type name: application
• Subtype name: txnat+jwt
• Required parameters: N/A
• Optional parameters: N/A
• Encoding considerations: binary. A Txn-AT is a JWT; JWT values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') characters.
• Security considerations: See the Security Considerations section of RFC XXXX.
• Interoperability considerations: N/A
• Published specification: RFC XXXX
• Applications that use this media type: Applications that issue or consume Transactional Access Tokens.
• Fragment identifier considerations: N/A
• Additional information: N/A
• Person & email address to contact for further information: IETF OAuth WG, oauth@ietf.org
• Intended usage: COMMON
• Restrictions on usage: none
• Author: IETF OAuth WG
• Change controller: IETF

OAuth URI Registration IANA is requested to register the following value in the "OAuth URI" registry established by :

• URN: urn:ietf:params:oauth:token-type:txn_access_token
• Common Name: Transactional Access Token
• Change Controller: IETF
• Specification Document: RFC XXXX

OAuth Parameters Registration IANA is requested to register the following parameter in the "OAuth Parameters" registry established by :

• Parameter name: txn_handle
• Parameter usage location: token request, token response
• Change controller: IETF
• Specification document(s): RFC XXXX

OAuth Extensions Error Registration IANA is requested to register the following values in the "OAuth Extensions Error Registry" established by :

• Name: invalid_txn_handle
• Usage Location: token error response
• Protocol Extension: Transactional Access Tokens
• Change controller: IETF
• Specification document(s): RFC XXXX
• Name: transaction_denied
• Usage Location: token error response
• Protocol Extension: Transactional Access Tokens
• Change controller: IETF
• Specification document(s): RFC XXXX

OAuth Authorization Server Metadata Registration IANA is requested to register the following value in the "OAuth Authorization Server Metadata" registry established by :

• Metadata Name: transactional_access_tokens_supported
• Metadata Description: Boolean value indicating whether the AS supports issuing Transactional Access Tokens.
• Change Controller: IETF
• Specification Document(s): RFC XXXX

OAuth Dynamic Client Registration Metadata Registration IANA is requested to register the following value in the "OAuth Dynamic Client Registration Metadata" registry established by :

• Client Metadata Name: transactional_access_tokens_required
• Client Metadata Description: Boolean value indicating that the AS issues only Transactional Access Tokens to this client.
• Change Controller: IETF
• Specification Document(s): RFC XXXX

References Normative References This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind 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. 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. 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 the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP. 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. 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. 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. 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. Informative References This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. 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.

Comparison with Related Tokens Token Comparison

Property	JWT Access Token	Txn-Token	Txn-AT
typ	at+jwt	txntoken+jwt	txnat+jwt
Issuer	AS	TTS	AS
Audience	Resource server	Trust domain	Single resource server
Lifetime	Minutes to hours	Very short	Very short
txn	No	Yes	Yes, per audience
Context	Scope (and RAR)	tctx, rctx	tctx, rctx (AS-asserted)
Crosses trust domains	Yes	No	Yes, to one RS

Examples Line breaks within values are for display purposes only.

Token Exchange Request (New Transaction)

Token Response

Decoded Txn-AT Header: Payload:

Additional Txn-AT for the Same Transaction (Refresh Token Grant) The resulting Txn-AT has aud set to https://billing.example.org and a txn value that cannot be correlated with k3JdQ9vX2mPz7LwR5tYb8A.

Open Issues

• Should the AS return the transaction handle's expiry, for example in a txn_handle_expires_in parameter?
• Should a resource server error code be defined, for use in the WWW-Authenticate response header, that signals a Txn-AT is required?
• Should the AS be able to end a transaction explicitly before its handle expires, for example through a revocation-style endpoint for handles?
• Should a common vocabulary for tctx be defined for AI agent tasks, or left to deployments?
• How should this draft align with the WIMSE WG and with AI agent authorization work?
• Name: "Transactional Access Tokens" is close to "Transaction Tokens". Should an alternative, such as "Transaction-Scoped Access Tokens", be considered?

Acknowledgments The authors thank the authors of , whose work this document builds on.

Document History -00

• Initial version.

Contributors Defakto Security

pieter@defakto.security