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? 1. AS-B receives the JAG and follows the existing Identity Chaining flow to issue an Access Token; 2. 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)<https://github.com/gffletch/tt_xdomain/issues/17#issuecomment-5607978459> 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<https://datatracker.ietf.org/doc/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]
