[TECH-3] Token exchange circularity in Section 9.5

[PieterKas]

Source: email from Yaron Sheffer to the WIMSE mailing list, Review of draft-klrc-aiagent-auth (editor's copy). Quoted verbatim below.

Section 9.5 describes exchanging access tokens for transaction tokens and then using transaction tokens to obtain access tokens (for downstream calls). This is architecturally circular and raises unresolved questions about how authorization scope is preserved or narrowed across this chain. Transaction tokens (draft-ietf-oauth-transaction-tokens) do not carry a standard scope claim, so it is unclear how scope semantics are maintained when re-obtaining an access token from a transaction token. This should be resolved or at least explicitly flagged as an open issue.

[PieterKas]

cc @yaronf

[Mayur021]

Yaron's circularity flag is sharper if separated from scope preservation. Section 9.5 chains access token to transaction token to access token.
The exchange is circular as a token-format pattern; the question is whether scope continuity is also lost or only the format identifier changes.

The chain-level audit schema work surfaced jointly with Mallikarjunarao Sunke during CSA NHI v1.0 peer review attempts to bind continuity across format transitions. Two of the six properties carry directly here:

1. Chain id linking composed steps. A stable identifier issued at chain start that survives every token type change downstream. The token-exchange replaces the carrier; the chain id remains. Verification reconstructs the chain by joining on chain id, not on token identity.

2. Declared worst-case action class at chain start. The chain's scope floor, bound at the chain-id issuance moment, propagates across exchanges as an immutable claim. Any token re-obtained downstream inherits the worst-case class. OWASP AISVS C9.2.7 (proposed for v1.01, merged in C09 research chapter) names this as the worst-case action class chain rule for composed multi-step sequences.

Both fields are token-format-agnostic, so they survive the circular exchange pattern Yaron identifies. The token format changes; the chain-level commitments do not.

This composes with @rsharath's RFC 9396 RAR proposal on #131. RAR carries per-transaction authorization_details: what is being authorized at this hop. Chain id plus worst-case class carry cross-exchange continuity: what the chain as a whole is committed to. Together they answer both "what is approved at this exchange" and "what scope semantics are preserved across the chain."

Suggested resolution for Section 9.5: explicitly bind a chain-level identifier and a worst-case action class declaration at chain start,
propagated as immutable claims through the token-exchange chain. The circularity in token format becomes acceptable when continuity is carried at the chain layer rather than per-token.

This pairs with the framing on Issue #114 (filed 2026-05-23) on the trigger side: chain id + worst-case class answer "what scope is preserved" across token exchange; reversibility-graded action class answers "when does the human-in-the-loop fire" within the chain.

Happy to contribute cross-walk language for Section 9.5 alongside the issue resolution.

[PieterKas]

This is architecturally circular and raises unresolved questions about how authorization scope is preserved or narrowed across this chain.

@yaronf - I don't believe there is a circularity here. Perhaps wording can be added to provide more clarity, but the pattern we seek to describe is that an Access Token is exchanged for a Transaction Token, which is used to communicate authorization context within a trust domain. At some point the workload(s) may need to interact with another service that requires and access token (e.g. in a different domain, or a legacy system that only knows about access tokens, not transaction tokens). At this point the workload needs to obtain the necessary access token, and can do so by presenting the transaction token it has to obtain a new access token (which may be for another trust domain - hence the new draft https://datatracker.ietf.org/doc/draft-fletcher-transaction-token-chaining-profile/

Transaction tokens (draft-ietf-oauth-transaction-tokens) do not carry a standard scope claim, so it is unclear how scope semantics are maintained when re-obtaining an access token from a transaction token. This should be resolved or at least explicitly flagged as an open issue.

Transaction tokens do carry a Scope claim (see https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-08.html#name-scope-claim). In addition, a transaction token may contain any additional information that is useful to complete the trasnaction and make authorization deisions - including those claims becomes a matter of implementation.

[identitymonk]

We should raise this to the Transaction Token Draft.

[1] The spirit of the draft clearly intends Txn-Tokens as terminal authorization artifacts within a trust domain, not as credentials that can be presented to an Authorization Server to obtain new access tokens. While the draft doesn't contain an explicit normative statement like "A Txn-Token MUST NOT be used as a subject_token to obtain an Access Token.", the limitation is implicit by design.

https://datatracker.ietf.org/doc/draft-fletcher-transaction-token-chaining-profile/ does not violate [1] as it focuses on cross domain and establishes that a TxnT can be exchanged for a ID-JAG which can in turn be exchanged for an Access Token.

Overall, we should precise in AIMS that the AS has the ultimate authority as part of its access control logic to decide what can be done or not, whatever the explicitness or implicitness of the valid possibility of an "exchange".

[PieterKas]

The inside/outside trust domain is a good delineation. In a greenfield deployment that is a very good way to.

How do you think about brownfield environments where there are a great many legacy systems with their own, existing, interfaces that may rely on any number of credential formats (including access tokens)? Perhaps the more narrow way to view this is that if you need an access token, you always treat it as "other domain" and just follow the ID chaining draft.

[identitymonk]

My views will be more stringent. If brownfield environments where there are a great many legacy systems then there is a very low chance for TxnT, ID-JAG, and chaining support. Therefore fall back to Access Token exchange through Token Exchange.

We could recognize brownfield, but the idea was to provide the map of "what it should be" not necessarily "how to allow to interoperate with your non modern architecture". I fear doing the latter will open the "and what about inter operating with static credentials brownfields?" as a follow-up.

[PieterKas]

Pieters law of Agentic Utiltiy: The value of an Agentic system increases exposnentially with the number of systems it connects to. Most of those systems are in brownfiled environments.

The goal is to provide guidance that works for both "greenfield" and "brownfield". The biggest need is in brownfield, since that is where the most interesting data lives.

We want new systems to use the standards we have. We want existing systems to use the standards we have. Those may have to be different standards.

[Mayur021]

Pieter's law lands. The brownfield need is where the real authorization-decision pain lives. One reframe that may help bridge the views above: separate the carrier (token format) from the declaration (chain-level commitments + action class).

Greenfield carries the declaration as a token claim (TxnT, ID-JAG, Access Token chain). Brownfield carries it as a sidecar the gate reads, the legacy app never sees. Chain id + worst-case action class survive either path.

The 6-property chain audit schema (joint with Mallikarjunarao Sunke during CSA NHI peer review, under IAM WG review for v1.0) is carrier-agnostic for this reason. Properties bind at chain start and propagate independent of which token type carries them downstream. Different carriers, same chain-level commitments.

This means Section 9.5's resolution can stay format-flexible without losing scope continuity, and the brownfield/greenfield split becomes a carrier choice rather than a different-standards split.