An IETF OAuth working group Standards Track draft defining short-lived, signed JWTs that carry user identity, workload identity and authorization context through an internal call chain inside a single trust domain. A Transaction Token is minted at the edge from the incoming access token and passed service-to-service, so each downstream hop can make an authorization decision against the original requester and intent rather than trusting whoever called it. Uses the JWT typ value txntoken+jwt and defines the txn, tctx, rctx, req_wl and scope claims.
Transaction Tokens
Transaction Tokens fix the thing that goes wrong three services deep. A request arrives at the edge with an OAuth 2.0 access token, the edge validates it, and then the call fans out across a dozen internal services — most of which end up trusting each other because the original token either does not travel or is too broad to be useful when it does. Txn-Tokens replace that with an explicit, short-lived, signed artifact minted at the edge and passed along: every hop can independently answer who asked for this, and for what.
txntoken+jwt- Thetypheader value, so a Transaction Token can never be confused with an access token or an ID token by a naive validator.txn- A transaction identifier that stays constant across the whole call chain. This is what makes an audit log reconstructable end to end rather than per-service.tctx- Transaction context: the authorization details of what was actually requested, which is how a downstream service scopes to the intent rather than to the caller’s ambient privilege.rctx- Requester context, andreq_wlthe identifier of the requesting workload.- Trust-domain scoped, deliberately - These are not cross-domain credentials. Leaving the domain is Token Exchange or identity chaining, not this.
Atul Tulshibagwale (CrowdStrike), George Fletcher (Practical Identity) and Pieter Kasselman (Defakto Security) have carried it to revision 11. The agent angle is why it belongs here: the IETF agent authentication and authorization framework reaches for Transaction Tokens as its risk-reduction mechanism, because an agent is exactly the caller you do not want holding a broad long-lived grant while it works through a multi-step task. A Transaction Token attenuates that grant down to one transaction’s worth of authority, and a WIMSE Workload Proof Token can carry a hash of it so the authentication and the authorization are bound to the same request.
For most API providers this is internal plumbing, not something a consumer sees — which is precisely why it will not show up in a scan of anybody’s public surface. It is worth tracking anyway, because the shape of the answer to “what did the agent actually do, on whose behalf, and with what permission” is being settled here, and the audit requirements the agent-auth draft makes a MUST are unsatisfiable without something in this role.
