Summary

  • A 29 September individual Internet-Draft proposes Transactional Access Tokens: short-lived OAuth access tokens with a transaction identifier, one resource-server audience and an authorization-server policy decision on every request. It is work in progress, not an adopted standard or a deployment report.
  • For a task spanning two resource servers, the authorization server would issue different txn values while keeping the internal join. The draft itself warns that a common client_id, other claims and issuance timing can still correlate activity. Identifier separation is narrower than transaction anonymity.

A client acting for a user may need to call two services to finish one task. Ordinary access-token scopes say something about what it may access, but not necessarily which piece of work prompted this particular call. The proposed draft-tulshi-oauth-transactional-access-tokens-00 tries to make the authorization server decide anew for each transaction and pass bounded context to each resource server. Its opening example includes an AI agent, but the mechanism is not an AI-only credential. The document is an individual Standards Track Internet-Draft in the I-D Exists state, not an RFC or a report that anyone has installed it.

The privacy design is unusually concrete. The authorization server creates an internal transaction identifier, then issues a txnat+jwt token for exactly one resource server. If the client requests another token for the same task using an opaque transaction handle, the second server receives a different txn value. The specification says recipients must not be able to infer from those two values that the transaction is shared. The authorization server, which keeps the internal identifier, can still join the records for an audit. That allocation—local identifiers outside, central correlation inside—is a choice about who can see the whole trail.

It is not a promise that the trail is invisible. Section 8 says client_id remains the same across resource servers, making some correlation inherent. It recommends pairwise subject identifiers and restraint in transaction context, while acknowledging that timestamps close together can aid colluding servers. A different txn claim removes one obvious join key, not every join key. Even the server that is authorized to correlate the values becomes a concentration point for retention and access decisions.

This distinction also matters to operators reading the proposal as a security upgrade. The token lifetime is intended to be brief—the draft says the difference between exp and iat should not exceed 300 seconds—but the refresh token or client credential used to ask for it can remain durable. The security benefit depends on the authorization server actually evaluating policy on every request and denying some requests despite a valid underlying grant. A bearer token may still be replayed during its lifetime; sender constraint is recommended, not required. The profile does not turn a short expiry into proof of single use or of a legitimate task.

The earlier OAuth Transaction Tokens proposal concerns propagation of context inside one trust domain. This new proposal places a transaction-aware OAuth access token at the boundary to a particular resource server and allows that server to obtain its own internal transaction token. A prior BTW analysis asked which source stood behind claims inside the signed internal token. The question here is different: after identifiers are separated across external services, who can reconstruct the same task and on what evidence? A local log's txn is useful, but it does not by itself supply the cross-server join the draft reserves for the authorization server.

Sources