Hi Yuan Thanks for sharing this proposal.
A client presenting an authorisation grant to a resource server so that the resource server can forward it to an authorization service is not a supported OAuth flow and bypasses security controls. Forwarding it to a Transaction Token service and using the Transaction Token as an access token or confirmation of access to a resource server is also contrary to OAuth flows (transaction tokens are not access tokens). Resource servers accept Access Tokens, not authorization grants that need to be exchanged for access tokens. Introducing such a flow would normalise authorization grant/token replay, which is a known attack vector. Token theft and replay scenarios have been observed in the wild. Consequently, the authors consider the proposed approach unsafe. Other optimisations may be possible, but the proposed approach introduces too many security risks. Cheers Pieter On Sun, Sep 20, 2026 at 1:13 PM niyuan <[email protected]> wrote: > > 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]
