Yes, technically you can use token exchange to federate access but you have to 
manage AS policy for each combination of clients that need to exchange tokens. 
Also, the resource owner client cannot easily revoke tokens issued to third 
party clients that it federates access with.
This draft tries to address those issues by giving resource owner client 
ability to delegate as much or as little access as they need to as well as the 
ability to revoke that delegation at any point in time. This also means that AS 
does not need to maintain policy that governs the federation (or delegation) of 
access between the clients.

Regards,
Igor


From: Warren Parad [mailto:wpa...@rhosys.ch]
Sent: Sunday, 19 May 2024 1:36 AM
To: Thomas Broyer <t.bro...@gmail.com>
Cc: Igor Janicijevic <i...@ivagor.com>; <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B 
Authorization

That was my first thought, but since we only have one AS, isn't just this just 
OAuth but switching up which is the RS and which is the user agent?

Why wouldn't the third party just request a client_credentials grant for the RS 
using the appropriate audience?

On Sat, May 18, 2024, 16:52 Thomas Broyer 
<t.bro...@gmail.com<mailto:t.bro...@gmail.com>> wrote:
Isn't that covered by Token Exchange already?
https://datatracker.ietf.org/doc/html/rfc8693

Le sam. 18 mai 2024, 16:29, Igor Janicijevic 
<i...@ivagor.com<mailto:i...@ivagor.com>> a écrit :
Dear All,

I have published an Internet Draft document that I would like to introduce to 
the OAuth working group for consideration. Here is the link for your reference: 
https://www.ietf.org/archive/id/draft-janicijevic-oauth-b2b-authorization-00.html


Abstract

Delegated B2B Authorization enables a third-party OAuth client to obtain a 
limited access to an HTTP service on behalf of another OAuth client which is 
acting as a resource owner. This specification extends the OAuth 2.0 
Authorization Framework with two new endpoints which allow a resource owner 
OAuth client to manage access for a third-party OAuth client.



Motivation

I work for a large financial services organization, and we are using OAuth 2.0 
extensively to secure API based B2B integrations with various third parties by 
utilizing OAuth client_credentials grant type. Some of those third parties are 
our customers, while others are either our partners or partners of our 
customers. One of the challenges that we have encountered is that there is no 
standard way to delegate access to resources in B2B integrations, so that one 
party can obtain access to protected resources on behalf of another party. The 
above internet draft describes a possible extension to OAuth 2.0 that may be 
able to address this issue.

I am looking forward to receiving your feedback.

Regards,
Igor
_______________________________________________
OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org>
To unsubscribe send an email to 
oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________
OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org>
To unsubscribe send an email to 
oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Reply via email to