OAuth Transaction Tokens (Txn-Tokens)

What it is

Transaction Tokens (Txn-Tokens) are short-lived, signed JWTs that "maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain", in the words of the IETF draft. A Transaction Token Service (TTS) mints one when a request enters the domain, typically at an API gateway, and every internal service that handles the request verifies it rather than receiving the caller's original access token.

The problem is the internal call chain. An external request arrives with an OAuth access token and then touches five, ten or fifty microservices. Most architectures either forward the external token downstream (any service that logs or leaks it hands an attacker a replayable credential with the full external scope) or drop it and rely on network location (no service past the gateway knows which user the work is for). Txn-Tokens replace both with a token scoped to one transaction, lasting minutes. The glossary entry has the one-paragraph version.

Status (November 2026)

The latest revision is draft-11, dated 30 July 2026, read from the IETF datatracker on 5 November 2026. Its working-group state is WG Consensus: Waiting for Write-Up: the OAuth Working Group agrees on the text and the shepherd write-up is pending before it goes to the IESG. The OAuth WG milestones list "Submit Transaction Tokens to the IESG" for December 2026. It is Standards Track, not an RFC. The authors are Atul Tulshibagwale (CrowdStrike), George Fletcher (Practical Identity LLC) and Pieter Kasselman (Defakto Security).

Consensus means the design is unlikely to change shape, but claim details can still move during IESG review. Pin the revision.

How it works

A concrete flow for an order placed through a public API:

1. External call. A client calls POST /orders at the gateway with an OAuth access token for the user.
2. Token request. The gateway calls the TTS using token exchange (RFC 8693): grant_type=urn:ietf:params:oauth:grant-type:token-exchange, requested_token_type=urn:ietf:params:oauth:token-type:txn_token, audience set to the trust domain name, scope set to the narrow purpose (for example orders.create), and the external access token as subject_token. The gateway authenticates to the TTS as a workload, for example with mutual TLS or a SPIFFE credential.
3. Mint. The TTS checks the subject token is unexpired and its own issuance policy, then returns a Txn-Token.
4. Propagate. The gateway calls the orders service with the Txn-Token in the Txn-Token HTTP header. The orders service calls inventory and payments with the same Txn-Token. The draft forbids carrying it in the Authorization header, because that header may already hold the caller's workload credential.
5. Verify at each hop. Each service checks the signature, that aud is its own trust domain, that exp has not passed, and that scope and the context permit the action it is about to take.

The JWT header must carry typ txntoken+jwt. Body claims:

Two rules in the draft are worth memorizing. A Txn-Token is not an authentication credential: a workload must not use it to prove its own identity. And it is not an access token: it records the context of one transaction, not a grant to a client. Services still authenticate each other with workload identity (WIMSE, mTLS or SPIFFE) and use the Txn-Token for the authorization decision.

For scheduled or internally started work with no inbound token, the requesting service may present a self-signed JWT as the subject token. That path deserves the strictest TTS policy, since it is where a compromised internal service could mint context for any user.

What it solves for AI agents and SaaS

For SaaS platforms built from many services, Txn-Tokens give least privilege inside the perimeter. A stolen Txn-Token is valid in one trust domain, for one purpose, for minutes. Signed tctx means a downstream service can trust that the order amount it sees is the amount the user submitted, not a value changed by a compromised hop. Every service logs the same txn, so incident responders can follow one request end to end.

For AI agents, the internal call chain is the tool chain. An agent platform that receives a user request and calls retrieval, code execution, ticketing and email tools can mint a Txn-Token that names the user, the agent workload in req_wl and a narrow purpose, and require every internal tool service to check it. The IETF WIMSE working group's AIMS draft (revision -01, 2 November 2026) lists Transaction Tokens among the existing standards it maps agents onto, and SWI's Agent Identity Standards Map 2026 places them under chained delegation and audit.

Limits: one trust domain only, and the draft does not define how an agent's natural-language task becomes a scope. That translation step, where prompt injection becomes over-broad access, is still undefined by any standard.

Adoption signals (verified)

We found no vendor documentation, as of 5 November 2026, that announces general availability of a Transaction Token Service built to this draft. The verifiable signals are standards-track: working-group consensus, the December 2026 IESG milestone, and citation in the AIMS draft. Authors from CrowdStrike, Practical Identity and Defakto Security indicate where implementations are likely to appear first, but that is a signal, not a deployment.

How to implement or evaluate

• Start at the gateway. Run the TTS as a small internal service next to your API gateway or service mesh ingress. Only the gateway, and a short allowlist of internal schedulers, should be able to request tokens.
• Design purposes, not scopes. Define scope values per business transaction (orders.create, refund.issue), not per API. The draft lets the TTS choose a value narrower than the external scope.
• Keep lifetimes in minutes. Long-running jobs should request new tokens per step rather than one long-lived token.
• Verify everywhere. A service that does not check the Txn-Token turns the whole design back into network trust. Build verification into a shared middleware.
• Separate authentication. Pair Txn-Tokens with workload identity for service-to-service authentication; see workload identity 101.
• Log txn, sub and req_wl on every call. That gives you the audit trail agent deployments otherwise lack.

Pitfalls

• Treating it as a bearer access token and accepting it at external APIs. The draft forbids both.
• A TTS that mints for anyone. If any workload can request a token for any subject, the TTS becomes a privilege escalation service. Restrict requesters and log issuance.
• Copying the whole external scope. That keeps replay value high and defeats the design.

Related

ID-JAG and Cross App Access, MCP authorization, Shared Signals Framework, the securing AI agent identities guide, and the Agent Identity Standards Map 2026. Glossary: workload identity, delegation chain, identity chaining, access token, token theft.

Who wrote it

The draft is by Atul Tulshibagwale, George Fletcher and Pieter Kasselman. More in the experts directory.