Hi Yuan Apart from @gffletch concerns, I believe there is a more fundamental issue with your proposal.
In an OAuth ecosystem, resources in Domain B are protected by the Authorization Server in Domain B and require a valid OAuth Access Token for access, not a JAG. Using a JAG as you propose above is inappropriate and consequently unsafe since the JAG is issued by the Authorization Server in Domain A. The Authorization Server in Domain A is not responsible for controlling access to resources in Domain B. Because the flows you propose remove the OAuth Authorisation Server in Trust Domain B from the access decision for Resources in Domain B your proposal is unsafe (a JAG is not an OAuth Access Token). Cheers Pieter On Mon, Sep 14, 2026 at 5:18 AM niyuan <[email protected]> wrote: > > Hi George and all, > > > > For list visibility, I’d like to share the recent GitHub discussion on the > direct JAG-to-Txn-Token flow in > draft-fletcher-oauth-txn-token-chaining-profile: > > > > https://github.com/gffletch/tt_xdomain/issues/17 > > > > As described in the "Chaining Across Multiple Trust Domains" section, this > profile MAY be applied recursively when a transaction spans multiple trust > domains. In this case, each trust-domain transition repeats the > JAG-to-Access-Token and Access-Token-to-Txn-Token exchanges. The associated > round trips and processing overhead therefore accumulate as the workflow > crosses more domains. > > > > Identity Chaining already allows a JAG `aud` claim to identify multiple > trusted authorization servers (in Section 2.3.3). To reduce the above > overhead, could the JAG `aud` claim be extended in this profile to also > include TTS-B, so the downstream domain could choose between the following > flows? > > > > AS-B receives the JAG and follows the existing Identity Chaining flow to > issue an Access Token; > TTS-B accepts the JAG and issues a local Txn-Token. > > > > This profile already makes profile-specific changes to the base Identity > Chaining parameter usage, such as `resource`. Similarly, the direct > JAG-to-TTS-B flow could be defined as a profile-level extension by allowing > the `audience` parameter and JAG `aud` claim to include TTS-B. > > > > I think this could be a useful optimization for multi-domain workflows. Would > you consider it a reasonable extension? > > > > > > Best regards, > > Yuan > > > > > > For reference, the earlier GitHub discussions are included below. > > > > --- Earlier GitHub discussion --- > > > > Topic: Re: [gffletch/tt_xdomain] Consider direct JAG-to-Txn-Token exchange as > an optional flow (Issue #17) > > > > gffletch left a comment (gffletch/tt_xdomain#17) > > Thanks for the explanation and sequence flows. I understand the desired > optimization more clearly now. > > The issue that blocks this sort of optimization is that > draft-ietf-oauth-identity-chaining (on which this profile depends) in section > 2.3.1 explicitly requires the resource parameter of the token exchange > request to be the URI of the authorization server in trust domain B. The same > is true of the audience parameter in the token exchange call. This means the > JAG is explicitly only valid at AS-B. > > Note also that section 2.3.3 also requires the issued JAG audience claim to > explicitly be the Authorization Server in trust domain B. > > Therefore, at this point, I don't see a path to implement this flow. > > > Topic: Two suggestions for draft-fletcher-transaction-token-chaining-profile > > > > Hi George, Pieter, and Sean, > > > > I would like to share two GitHub issues I opened with two suggestions for > draft-fletcher-transaction-token-chaining-profile: > > > > 1. Direct JAG-to-Txn-Token exchange as an optional flow > > When the downstream domain needs a local Txn-Token to continue the workflow, > this issue explores whether the intermediate Access Token exchange can be > avoided by allowing the downstream TTS to directly accept the JAG. In this > proposal, no Txn-Token crosses the trust-domain boundary. Txn-Tokens remain > local to their respective trust domains, while the JAG carries the > cross-domain authorization information. > > https://github.com/gffletch/tt_xdomain/issues/17 > > > > 2. Support `tctx` in `txn_claims` > > `tctx` may be useful for the downstream domain to continue the same workflow, > so this proposes that it MAY be included in `txn_claims`, subject to > minimization and privacy policy. > > https://github.com/gffletch/tt_xdomain/issues/18 > > > > I would appreciate your thoughts on these suggestions. > > > > Best regards, > > Yuan > > > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
