[OAUTH-WG] 回复: Re: [gffletch/tt_xdomain] Consider direct JAG-to-Txn-Token exchange as an optional flow (Issue #17)

[niyuan <[e-mail]>]

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 <[e-mail]> 
发送时间: 2026年9月14日 20:03
收件人: niyuan <niyuan1=[e-mail]>
抄送: oauth <[e-mail]>; Liuchunchi(Peter) <[e-mail]>
主题: [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
<niyuan1=[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]