Warren, My initial thought was that this would be too complicated, but now I’m thinking that we could get what we want from profiling OAuth 2.0 Token Exchange for our use cases while adding in new requirements from OAuth 2.1.
For those of you who have seen my “Token and Identity Chaining Between PRs” documents and/or presentation, do you think this is a viable option? Regards, Kelley From: Warren Parad <wpa...@rhosys.ch> Date: Sunday, July 3, 2022 at 11:54 AM To: Dr. Kelley W Burgin <kbur...@mitre.org> Cc: oauth@ietf.org <oauth@ietf.org>, Beth S Abramowitz <b...@mitre.org> Subject: [EXT] Re: [OAUTH-WG] MITRE Updated Token Chaining Profile for Multi ICAM Ecosystems It might be interesting to point out that there is actually an OAuth token exchange paradigm that already exists. It could be valuable, if for some reason it doesn't support what you are trying to do, to either piecemeal add RFCs for additional claims or update the RFC to include additional use cases. I'll leave this here: https://datatracker.ietf.org/doc/html/rfc8693 On Fri, Jul 1, 2022 at 9:37 PM Dr. Kelley W Burgin <kbur...@mitre.org<mailto:kbur...@mitre.org>> wrote: Hi all, MITRE has an updated version of the “Token and Identity Chaining Between OAuth Protected Resources in a Multiple ICAM Ecosystem Using OAuth Token Exchange”. It is attached since we will not have time to go through the process of publishing it to our website in time for the meetings at the end of this month. We are seeking feedback from subject matter experts throughout the community. Summary: This profile describes how to handle the situation where, in a multiple ICAM ecosystem, a protected resource (PR1) may need to call a second protected resource (PR2) in a different organization in order to satisfy a query received from a client. PR1 cannot simply relay Token1 to PR2 since PR2 trusts a different authorization server and the Enterprise Mission Tailored OAuth 2.0 Profile (https://www.mitre.org/publications/technical-papers/enterprise-mission-tailored-oauth-20-and-openid-connect-profiles) requires that the tokens be sender and/or audience constrained, so PR1 must request a new access token, Token2, from an authorization server AS2 that is trusted by PR2. This process of exchanging Token1 (which grants access to PR1) to obtain a new access token, Token2 (which grants access to PR2) is called token chaining. This profile additionally enables identity chaining by ensuring that the identities of the user, client, and protected resources are propagated in the exchanged tokens, so that each protected resource can, as necessary, use the set of identities to make appropriate access decisions. Note: To address issues in one of the two scenarios presented in the document, we define a new OAuth claim “chained_id” (see Section 3.2.1.2) that allows AS1 to communicate necessary information to AS2 so that AS2 can populate the appropriate fields in Token2. Regards, Kelley _________________________ Kelley Burgin, Ph.D. Cybersecurity Engineer The MITRE Corporation (865) 255 - 6699 _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
