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

Reply via email to