Re: [OAUTH-WG] [EXT] Re: MITRE Updated Token Chaining Profile for Multi ICAM Ecosystems

I think it wouldn't be complicated, and the complicated part is the
choreography that you have between the individual AS that isn't OAuth
standard anyway. But we are in a world now where we have lots of
implementations of distributed consensus solutions. Potentially taking
inspiration from one of those could solve that part of the problem.

On Tue, Jul 26, 2022 at 6:16 PM Dr. Kelley W Burgin <kburgin@mitre.org>
wrote:

> 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 <wparad@rhosys.ch>
> *Date: *Sunday, July 3, 2022 at 11:54 AM
> *To: *Dr. Kelley W Burgin <kburgin@mitre.org>
> *Cc: *oauth@ietf.org <oauth@ietf.org>, Beth S Abramowitz <beth@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 <kburgin@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
>
>