AuthZEN, CAEP and Transaction Tokens: the layer above authentication

The three questions that follow authentication

Given an attested workload credential and a delegation token, you know what is calling and on whose authority. Three questions remain, and conventional OAuth deployments answer all three badly.

1. May this specific action proceed, right now? Scopes baked into a token at issuance answer a question asked minutes ago, under conditions that may no longer hold.
2. Has anything changed since issuance? A credential compromised two minutes into a fifteen-minute lifetime remains valid for thirteen more unless something tells the enforcement points otherwise.
3. How does the answer travel? When a request crosses five services, does the authorization context survive, or does each service re-derive it from its own assumptions?

For human-paced systems the gaps are tolerable. For agents acting thousands of times per minute under delegated authority, they are the governance problem. See kill paths and delegation chains.

AuthZEN: the decision interface

AuthZEN, from the OpenID Foundation, standardises the interface between a Policy Enforcement Point: the component that intercepts an action, and a Policy Decision Point: the component that answers whether it is permitted.

The scope discipline is the point. AuthZEN is not a policy language and does not dictate how the decision point sources its information. It defines how the question is asked and how the answer comes back. That restraint is what makes it substitutable: you can change policy engines without rewriting every enforcement point, which is the lock-in that has historically made externalised authorization unattractive.

For agents this matters because the alternative, permissions encoded in issued tokens, cannot express context that changes between one tool call and the next. An externalised decision can take account of what the agent has already done in this session, what the delegating user consented to, and what the current risk signals say.

Shared Signals Framework and CAEP: the signal layer

SSF defines how security events are transmitted between cooperating parties. CAEP, the Continuous Access Evaluation Profile, defines the event types that matter for access: session revoked, credential compromised, assurance level changed, device compliance changed.

The problem it solves is stated most clearly as arithmetic. Without push-based signalling, your revocation latency equals your token lifetime, regardless of how quickly the decision to revoke was made. Shortening lifetimes reduces the exposure but never eliminates it, and shortening them far enough to substitute for revocation creates its own reliability problems.

With CAEP, a revocation decision propagates to enforcement points as an event, and in-flight authority can be withdrawn rather than merely allowed to expire. This is the second layer of the four-layer kill path, and it is the one most often missing.

Transaction Tokens: propagation

Transaction Tokens (TraTs), an IETF OAuth working-group draft, address what happens to authorization context when a request crosses many internal services.

The common pattern today is that an external request arrives with a token, an edge service validates it, and everything behind the edge trusts the network. Each internal hop either re-derives authorization from its own assumptions or does not check at all. The original context, who the principal was, what they consented to, what the request was for, degrades or vanishes.

TraTs preserve and cryptographically carry that context through the chain. For multi-agent systems, where one human request may fan out into hundreds of calls across several agents and tools, this is the mechanism that makes end-to-end attribution possible rather than aspirational. See multi-agent authorization.

How they compose

None of the three requires the others, and each is more useful with them. The composition is also the argument against waiting: the identity and delegation layers are ratified today, and these three can be added to a working deployment incrementally. See the standards tracker for status detail and the OAuth building blocks for the ratified layer beneath.

What to do now

1. Externalise one authorization decision. Pick the highest-consequence action in one agent's tool set and move the permission check to a decision point behind an AuthZEN-shaped interface. Even a crude PDP is more substitutable than scopes hard-coded into issuance.
2. Make enforcement points event-driven. They should react to a pushed revocation, not only re-check at token refresh. If they cannot, that is the finding.
3. Measure the propagation gap. Take a request that crosses three services and check whether the third can name the original principal. Usually it cannot.
4. Do not wait for ratification. Transaction Tokens is a draft and AuthZEN is evolving. Build against an interface, not a wire format, and the substitution cost stays low.

Frequently asked questions

What is AuthZEN?

AuthZEN is an OpenID Foundation specification standardising the interface between a Policy Enforcement Point, which intercepts an action, and a Policy Decision Point, which decides whether it is permitted. It is deliberately not a policy language and does not dictate how the decision point sources information. That scope discipline is what makes it valuable: you can change policy engines without rewriting every enforcement point.

What is CAEP and why does it matter for agents?

The Continuous Access Evaluation Profile defines security event types relevant to access, such as session revoked, credential compromised and assurance level changed, carried over the Shared Signals Framework. It matters because without push-based signalling your revocation latency equals your token lifetime regardless of how fast the decision was made. For agents acting thousands of times per minute, the difference between expiry and pushed revocation is the difference between bounded and unbounded exposure.

What problem do Transaction Tokens solve?

The loss of authorization context across an internal call chain. The common pattern is that an edge service validates a token and everything behind it trusts the network, so each internal hop re-derives authorisation from its own assumptions or does not check at all. Transaction Tokens preserve and cryptographically carry the original context through the chain, which is what makes end-to-end attribution possible in multi-agent systems where one request fans out into many calls.

Are AuthZEN, CAEP and Transaction Tokens ratified standards?

Not uniformly. AuthZEN is a published OpenID Foundation specification with an active working group. The Shared Signals Framework and CAEP are published. Transaction Tokens is an IETF OAuth working-group draft and is not an RFC. None is in the same tier as OAuth token exchange or DPoP, both of which are ratified RFCs. Build against interfaces rather than wire formats so substitution stays cheap.

What is the highest-leverage change in this layer?

Externalising the authorization decision. When permission is evaluated per call against a policy decision point rather than baked into an issued credential, revocation becomes a policy change effective at the next call rather than a credential lifecycle event with propagation delay. It also lets the decision take account of context that changes between one agent tool call and the next, which scopes fixed at issuance cannot express.