Thanks @PieterKas，I understand your point about keeping the two roles clear: AS-B controls access to resources in Domain B, while TTS-B issues the local Txn-Token.
My concern is that introducing the intermediate Access Token adds one additional exchange and two additional cross-domain hops, which reduces efficiency. Moreover, It may introduce a reusable cross-domain token without the JAG’s explicit short-lifetime and single-use constraints. If that Access Token is only used to obtain a local Txn-Token, as illustrated in the “Chaining Across Multiple Trust Domains” section, could this unnecessarily increase the opportunity for reuse or broaden the exposure surface? A similar concern was previously raised in oauth-wg/oauth-transaction-tokens#62, where it was noted that “creating long-living Access Tokens just for the purpose of exchanging them for short-lived Txn-Tokens and then throwing them away can be considered wasteful (energy costs),” and that such a long-lived Access Token “could leak and another party could use them to create Txn-Tokens or access resources the Access Token was meant for.” With AS-B and TTS-B retaining their respective roles, could this profile define an optional domain-local interaction where AS-B makes the authorization decision and provides the approved authorization context to TTS-B for local Txn-Token issuance? This could avoid the intermediate Access Token while preserving the existing role separation, with AS-B still receiving the JAG and authorizing access in Domain B. Best Regards, Yuan -----邮件原件----- 发件人: Pieter Kasselman <[email protected]> 发送时间: 2026年9月14日 20:03 收件人: niyuan <[email protected]> 抄送: oauth <[email protected]>; Liuchunchi(Peter) <[email protected]> 主题: [OAUTH-WG] Re: [gffletch/tt_xdomain] Consider direct JAG-to-Txn-Token exchange as an optional flow (Issue #17) 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 discussi=n on the > direct JAG-to-Txn-Token flow in > draft-fletcher-oauth-txn-token-ch=ining-profile: > > > > https://github.com/gffletch/tt_xdomain/issues/17 > > > > As described in the "Chaining Across Multiple Trust Domains" section, thi= > profile MAY be applied recursively when a transaction spans multiple trus= > domains. In this case, each trust-domain transition repeats the > JAG-to-Ac=ess-Token and Access-Token-to-Txn-Token exchanges. The associated > round tr=ps and processing overhead therefore accumulate as the workflow > crosses mo=e domains. > > > > Identity Chaining already allows a JAG `aud` claim to identify multiple > t=usted authorization servers (in Section 2.3.3). To reduce the above > overhe=d, could the JAG `aud` claim be extended in this profile to also > include T=S-B, so the downstream domain could choose between the following > flows? > > > > AS-B receives the JAG and follows the existing Identity Chaining flow > to =ssue 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 > =haining parameter usage, such as `resource`. Similarly, the direct > JAG-to-=TS-B flow could be defined as a profile-level extension by allowing > the `a=dience` parameter and JAG `aud` claim to include TTS-B. > > > > I think this could be a useful optimization for multi-domain workflows. W=uld > 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 > exchang= 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 > o=timization more clearly now. > > The issue that blocks this sort of optimization is that > draft-ietf-oauth-=dentity-chaining (on which this profile depends) in section > 2.3.1 explicit=y requires the resource parameter of the token exchange > request to be the =RI of the authorization server in trust domain B. The same > is true of the =udience parameter in the token exchange call. This means the > JAG is explic=tly only valid at AS-B. > > Note also that section 2.3.3 also requires the issued JAG audience claim =o > 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-prof=le > > > > 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 workfl=w, > this issue explores whether the intermediate Access Token exchange can =e > avoided by allowing the downstream TTS to directly accept the JAG. In th=s > proposal, no Txn-Token crosses the trust-domain boundary. Txn-Tokens rem=in > local to their respective trust domains, while the JAG carries the > cros=-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 workf=ow, > so this proposes that it MAY be included in `txn_claims`, subject to > m=nimization 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]
