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> 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 > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
