[OAUTH-WG] Re: New draft: OAuth Profile for Open Public Clients

[Neil Jenkins]

On Fri, 17 May 2024, at 15:04, Aaron Parecki wrote:
> I agree this is a useful profile for this ecosystem. I would be happy to help 
> with this document, as well as help prepare a presentation on this at the 
> next IETF meeting.

Thanks Aaron, that would be much appreciated.

On Sat, 18 May 2024, at 09:11, Lisa Dusseault wrote:
> […] is it the intent that the HTTP-based protocols MUST use DPoP or is that 
> really a RECOMMENDED for HTTP-based servers ?  Ie. did you intend "RECOMMEND 
> use DPop" to mean  "MUST if you can but not if you can't" ? 

My current intention was to leave it at RECOMMENDED, but it could be upgraded 
to a MUST. It's clearly a security/implementation difficulty trade-off. I'd 
want to talk to some more server implementers on their plans, and see the OAuth 
community's thoughts.

> I know your document says that a separate document will define the scopes, 
> but if you pull the scopes into this document ISTM it will really be a 
> complete solution to many use cases. Without the scopes this does not stand 
> alone and implementable and interoperable, whereas I think that just adding 
> scopes will make it so. 

Agreed. To be clear, we discussed the scopes problem at the mailbox-providers 
conference and came to a tentative conclusion of using the JMAP capabilities 
 as scopes 
to represent the data types being accessed, regardless of protocol (so you 
would use the `urn:ietf:params:jmap:mail` scope for access to mail whether via 
JMAP or IMAP — it's the same data and same security capability).

Where this should be documented I'm not sure, which is why I omitted it from 
this document for now. The 3 pieces of the puzzle are autodiscovery (there's 
still a lot of discussion to be had there about the best approach), the OAuth 
profile, and the set of scopes. It might be nice if all of this were in one 
document, or they could be separate with perhaps a brief extra document that 
says to use all of them together for interoperability. I don't know.

On Sun, 19 May 2024, at 20:55, Vladimir Dzhuvinov wrote:
> The dynamic client registration (DCR) will probably need implementers to 
> consider measures against DoS attacks. One such measure could be the 
> automatic expiration of client registrations that remain unused or where the 
> client doesn't receive a token within a certain time.

Yes. I have discussed this with a number of people and that's certainly one of 
the mitigations we should recommend in the security considerations.

Cheers,
Neil.___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: [lamps] Revocation and OAuth

[Christian Bormann]

Hi and thanks for the feedback!

 

Here are my thoughts on the comments:

 

Should at least one of ttl and exp be required?  Why is ttl not listed for 
CBOR? Are both mechanisms needed?

- I would say no - right now we require “iat” which allows a relying party to 
make an informed decision on whether the status list is fresh enough or not; 
the issuer can add additional policy / information by providing “exp” which is 
a freshness requirement from the issuer side and an optional signal with “ttl” 
that allows more optimal fetching/caching  mechanism (a signal how fast/often 
updates can be expected – even if the information is not yet considered expired)

- This was an oversight on our part (2 PRs in parallel – one introducing ttl, 
the other one the CBOR encoding) and is fixed in the latest editor’s copy 
(https://github.com/oauth-wg/draft-ietf-oauth-status-list) 

- Perhaps ttl isn’t the best name, but as mentioned before I do believe every 
claim serves its purpose

 

It may be worth including some words on using the uri field to partition status 
lists based on token lifetime so status lists don't linger. The uri field is 
similar to partitioning using the IDP/CDP mechanism in CRLs, so any 
partitioning scheme could work, but mentioning the concept may be helpful.

- That is a very valid point and should be part of implementation 
considerations.

 

Should there be a POST option for requesting a status list that provides for 
freshness via a nonce? If so, does this cause a need for delegation so a token 
signing key need not be online (i.e., maybe some identifier in the status claim 
in the referenced token)? This would make GET requests analogous to partitioned 
CRLs and POST requests analogous to OCSP with a nonce, with the extra benefit 
that both use the same format.

- That sounds like an interesting concept to combine with a more OCSP-like 
approach (and there has been some demand in that direction - e.g., Giuseppe’s 
draft 
https://peppelinux.github.io/draft-demarco-oauth-status-attestations/draft-demarco-oauth-status-attestations.html)
 but needs more thought on my side for a proper answer. We provide the 
freshness currently with iat/exp, so I am not sure the nonce would be necessary 
or add additional value?

 

The mechanism is simple, which is good, but the lack of a time value 
corresponding to revocation time may limit applicability. If JWTs/CWTs replace 
certificates where signature validation is well after generation, is a 
revocation mechanism needed that supports similar support for grace periods, 
verification relative to times in the past, etc? It may be worth noting cases 
where this mechanism may not be a good fit for such use cases even if not 
addressing. A POST request that accepted a time value may serve this purpose 
with no change to the status list definition, i.e., just return the response 
relative to the requested time instead of current.

- We’ve gotten this feedback a few times and are considering to add an optional 
mechanism to provide time similar to what you are describing. Related issue: 
https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/138

- That being said, we reached a point where we realized that the different 
use-cases differ in terms of privacy considerations and overall requirements 
where it  seems hard to create one approach that is a good fit for everything. 
The draft introduces “status” as an extension point for other status mechanisms 
that are better suited for other use-cases that e.g., require more metadata 
(like timestamps / more events) and we are considering adding an additional 
draft that works similar to a CRL (with an UUID and attached metadata) but in 
json/cbor form re-using parts of the statuslists draft. I do believe the 
statuslist is a good approach for “simple” use-cases where the main thing you 
are interested in is a current status.

 

Especially the last point is something where more feedback/discussion would be 
quite helpful imho.

 

Regards,

Christian

 

From: Rifaat Shekh-Yusef  
Sent: Wednesday, May 15, 2024 2:14 PM
To: Carl Wallace 
Cc: Tschofenig, Hannes ; 
sp...@ietf.org; oauth 
Subject: [OAUTH-WG] Re: [lamps] Revocation and OAuth

 

Adding the OAuth WG to this thread.

 

Regards,

 Rifaat

 

 

On Wed, May 15, 2024 at 7:52 AM Carl Wallace mailto:c...@redhoundsoftware.com> > wrote:

Here're a few questions/comments from a first read of 
draft-ietf-oauth-status-list. Overall, the approach looks good to me.

 

Should at least one of ttl and exp be required? Why is ttl not listed for CBOR? 
Are both mechanisms needed?

 

It mahy be worth including some words on using the uri field to partition 
status lists based on token lifetime so status lists don't linger. The uri 
field is similar to partitioning using the IDP/CDP mechanism in CRLs, so any 
partitioning scheme could work, but mentioning the concept may be helpful.

 

Should there be a POST option for requesting a status list that provides 

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

[Warren Parad]

Thanks for 1 and 2, but 3 is still the question that I feel is unanswered.
Can you walk through a concrete implementation use case that highlights how
exactly the RO would delegate this access?

It isn't clear for me how the RO would actually dynamically determine what
to do here without:

   - There only ever being one answer
   - OR a human in a loop

Since the policies are needed somewhere, I could say a more powerful
extension to OAuth would be an interface that would let the RO configure
the policies in the AS. And then the TP would request the
client_credentials grant as it does today. Since in OAuth, control over
this is facilitated by the AS, this would avoid the necessity of the RO
being called on every TP client_credentials request, and also avoid an
extra call which doesn't exist in the client_credentials grant today.

That is something I would definitely support. It would have a secondary
benefit to also help codify the interface for which human approved user
agent scopes could be changed.

Additionally, I find the directionality of the requests in the Draft to be
contradictory to the expected flow. A more consistent approach would be for
the TP to request client_credentials and have the AS call the RO to verify.
This is exactly the same flow that happens with the authorization_code
grant except that instead of the RO being a machine client, it is a human
in an AS provided UI. Which means it would definitely make sense to flip
this and instead define in the draft:

   - Endpoint configuration for the RO to accept AS driven
   client_credentials delegation requests
   - Request/Response configuration for that endpoint


This is much cleaner:
[image: image.png]

And we can see that because it is the exact same flow that OAuth does
today, where the RO is a human's user agent in the browser, and (B) and (C)
are actually the display of the /authorize endpoint and the "sign in"
button that exists in the UI.

This means that if the DRAFT would instead define exactly the nature of how
the UI (or any user agent) communicates with the AS, this would be a huge
win.

On Sun, May 19, 2024 at 2:41 PM Igor Janicijevic  wrote:

> Yes, it can be managed through some client specific policies at AS,
> however, as already stated in the 6749 the method of arranging this policy
> is not specified.  The proposed draft describes how resource owner can
> dynamically manage delegation for third party client(s) so that no
> additional policies are needed at AS.
>
>
>
> *From:* Aaron Parecki [mailto:aa...@parecki.com]
> *Sent:* Sunday, 19 May 2024 10:23 PM
> *To:* Igor Janicijevic 
> *Cc:* Warren Parad ;  
> *Subject:* Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B
> Authorization
>
>
>
> Yeah this just sounds like the client credentials grant with some policy
> at the AS. There's no limitation that the client credentials grant is only
> used to access resources owned by the client. From 6749:
>
>The client can request an access token using only its client
>
>credentials (or other supported means of authentication) when the
>
>client is requesting access to the protected resources under its
>
>control, or those of another resource owner that have been previously
>
>arranged with the authorization server (the method of which is beyond
>
>the scope of this specification).
>
>
>
>
>
> On Sun, May 19, 2024 at 5:16 AM Igor Janicijevic  wrote:
>
> The idea is that the resource owner client can delegate some or all of its
> own scopes. For example, if the resource owner client can obtain “read” and
> “write” scopes on its own resource, it can decide to delegate “read” scope
> for that resource to the third party client, but not the “write” scope.
> This means that the third party client will only be able to obtain read
> only access to that resource and will not be able to update the resource.
>
>
>
> *From:* Warren Parad [mailto:wpa...@rhosys.ch]
> *Sent:* Sunday, 19 May 2024 9:57 PM
> *To:* Igor Janicijevic 
> *Cc:* Thomas Broyer ;   >
> *Subject:* Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B
> Authorization
>
>
>
> Hmmm, interesting. How does the first-party client decide which scopes to
> grant to the third party service?
>
>
>
> On Sun, May 19, 2024 at 1:52 PM Igor Janicijevic  wrote:
>
> Maybe I failed to set the context here, as you rightly pointed out. This
> new proposed flow is for B2B or system to system interactions only, i.e. no
> user agents (browsers) and no humans (end users) are involved, so there are
> no user agent redirects…
>
>
>
> In standard OAuth, for system to system access tokens are obtained using
> client_credentials grant type, where resource owner client authenticates to
> AS and obtains a token which it then uses to access its own resources held
> at resource server. No third party client is involved in this flow because
> this is direct access by resource owner to its own resources – there is no
> delegation and no “on behalf of access”…
>

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

[Igor Janicijevic]

Yes, it can be managed through some client specific policies at AS, however, as 
already stated in the 6749 the method of arranging this policy is not 
specified.  The proposed draft describes how resource owner can dynamically 
manage delegation for third party client(s) so that no additional policies are 
needed at AS.

From: Aaron Parecki [mailto:aa...@parecki.com]
Sent: Sunday, 19 May 2024 10:23 PM
To: Igor Janicijevic 
Cc: Warren Parad ;  
Subject: Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B 
Authorization

Yeah this just sounds like the client credentials grant with some policy at the 
AS. There's no limitation that the client credentials grant is only used to 
access resources owned by the client. From 6749:

   The client can request an access token using only its client

   credentials (or other supported means of authentication) when the

   client is requesting access to the protected resources under its

   control, or those of another resource owner that have been previously

   arranged with the authorization server (the method of which is beyond

   the scope of this specification).



On Sun, May 19, 2024 at 5:16 AM Igor Janicijevic 
mailto:i...@ivagor.com>> wrote:
The idea is that the resource owner client can delegate some or all of its own 
scopes. For example, if the resource owner client can obtain “read” and “write” 
scopes on its own resource, it can decide to delegate “read” scope for that 
resource to the third party client, but not the “write” scope.  This means that 
the third party client will only be able to obtain read only access to that 
resource and will not be able to update the resource.

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

Hmmm, interesting. How does the first-party client decide which scopes to grant 
to the third party service?

On Sun, May 19, 2024 at 1:52 PM Igor Janicijevic 
mailto:i...@ivagor.com>> wrote:
Maybe I failed to set the context here, as you rightly pointed out. This new 
proposed flow is for B2B or system to system interactions only, i.e. no user 
agents (browsers) and no humans (end users) are involved, so there are no user 
agent redirects…

In standard OAuth, for system to system access tokens are obtained using 
client_credentials grant type, where resource owner client authenticates to AS 
and obtains a token which it then uses to access its own resources held at 
resource server. No third party client is involved in this flow because this is 
direct access by resource owner to its own resources – there is no delegation 
and no “on behalf of access”…

There is no delegated flow for system to system access in the standard OAuth, 
as far as I know…


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

Maybe let's separate those two things for a second:

  1.   Third party acquiring token to access RS
  2.   RO revoking token generated for the Third Party client

For #1. I'd be interested to know how this is any different from an OAuth 
Client that wants to access RS on behalf of the RO. In this case the "Client" 
would be the Third Party (TP). TP redirects user agent to AS to authorize token 
generation, then AS redirects user agent back to TP with auth_code/refresh 
token/etc.

The token issued by AS to third party client is not presented to the resource 
owner client

Correct, and isn't that the same as the standard OAuth flow? If not I think 
additional context there would be appreciated.

- Warren

On Sun, May 19, 2024 at 1:01 PM Igor Janicijevic 
mailto:i...@ivagor.com>> wrote:
Hi Warren,

There are four parties in this flow: the resource owner client, the third party 
client, the resource server and the AS. The token issued by AS to third party 
client is not presented to the resource owner client – it is only presented to 
the resource server when third party client is accessing the resources. This 
means that the resource owner client cannot revoke that token because it will 
have to have a possession of it to present it to the revocation endpoint… Maybe 
I am completely missing your point, so can you, please, clarify.

Cheers,
Igor


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

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

[Igor Janicijevic]

Let me try to answer those questions:


1.   The RO can still access its own resources by requesting token using 
client_credentials grant as per standard OAuth;

2.   Typically the scopes will be specified during RO client registration;

3.   This will depend on what type of access the RO wants to delegate to 
the third party.

From: Warren Parad [mailto:wpa...@rhosys.ch]
Sent: Sunday, 19 May 2024 10:21 PM
To: Igor Janicijevic 
Cc: Thomas Broyer ;  
Subject: Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B 
Authorization

Okay but that just creates more unanswered questions. Now we are at three for 
this part:

  1.  What does an RO obtaining scopes to its own resource mean
  2.  How does it obtain scopes to its own resource
  3.  How does the RO decide which scopes to delegate to the TP client?



On Sun, May 19, 2024 at 2:15 PM Igor Janicijevic 
mailto:i...@ivagor.com>> wrote:
The idea is that the resource owner client can delegate some or all of its own 
scopes. For example, if the resource owner client can obtain “read” and “write” 
scopes on its own resource, it can decide to delegate “read” scope for that 
resource to the third party client, but not the “write” scope.  This means that 
the third party client will only be able to obtain read only access to that 
resource and will not be able to update the resource.

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

Hmmm, interesting. How does the first-party client decide which scopes to grant 
to the third party service?

On Sun, May 19, 2024 at 1:52 PM Igor Janicijevic 
mailto:i...@ivagor.com>> wrote:
Maybe I failed to set the context here, as you rightly pointed out. This new 
proposed flow is for B2B or system to system interactions only, i.e. no user 
agents (browsers) and no humans (end users) are involved, so there are no user 
agent redirects…

In standard OAuth, for system to system access tokens are obtained using 
client_credentials grant type, where resource owner client authenticates to AS 
and obtains a token which it then uses to access its own resources held at 
resource server. No third party client is involved in this flow because this is 
direct access by resource owner to its own resources – there is no delegation 
and no “on behalf of access”…

There is no delegated flow for system to system access in the standard OAuth, 
as far as I know…


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

Maybe let's separate those two things for a second:

  1.   Third party acquiring token to access RS
  2.   RO revoking token generated for the Third Party client

For #1. I'd be interested to know how this is any different from an OAuth 
Client that wants to access RS on behalf of the RO. In this case the "Client" 
would be the Third Party (TP). TP redirects user agent to AS to authorize token 
generation, then AS redirects user agent back to TP with auth_code/refresh 
token/etc.

The token issued by AS to third party client is not presented to the resource 
owner client

Correct, and isn't that the same as the standard OAuth flow? If not I think 
additional context there would be appreciated.

- Warren

On Sun, May 19, 2024 at 1:01 PM Igor Janicijevic 
mailto:i...@ivagor.com>> wrote:
Hi Warren,

There are four parties in this flow: the resource owner client, the third party 
client, the resource server and the AS. The token issued by AS to third party 
client is not presented to the resource owner client – it is only presented to 
the resource server when third party client is accessing the resources. This 
means that the resource owner client cannot revoke that token because it will 
have to have a possession of it to present it to the revocation endpoint… Maybe 
I am completely missing your point, so can you, please, clarify.

Cheers,
Igor


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

But the AS is already governing the access between clients, so at the surface 
at least I'm not able to wrap my head around your counterargument.

Also this:
Also, the resource owner client cannot easily revoke tokens issued to third 
party clients that it federates access with.

Why not? It 

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

[Aaron Parecki]

Yeah this just sounds like the client credentials grant with some policy at
the AS. There's no limitation that the client credentials grant is only
used to access resources owned by the client. From 6749:

   The client can request an access token using only its client
   credentials (or other supported means of authentication) when the
   client is requesting access to the protected resources under its
   control, or those of another resource owner that have been previously
   arranged with the authorization server (the method of which is beyond
   the scope of this specification).



On Sun, May 19, 2024 at 5:16 AM Igor Janicijevic  wrote:

> The idea is that the resource owner client can delegate some or all of its
> own scopes. For example, if the resource owner client can obtain “read” and
> “write” scopes on its own resource, it can decide to delegate “read” scope
> for that resource to the third party client, but not the “write” scope.
> This means that the third party client will only be able to obtain read
> only access to that resource and will not be able to update the resource.
>
>
>
> *From:* Warren Parad [mailto:wpa...@rhosys.ch]
> *Sent:* Sunday, 19 May 2024 9:57 PM
> *To:* Igor Janicijevic 
> *Cc:* Thomas Broyer ;   >
> *Subject:* Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B
> Authorization
>
>
>
> Hmmm, interesting. How does the first-party client decide which scopes to
> grant to the third party service?
>
>
>
> On Sun, May 19, 2024 at 1:52 PM Igor Janicijevic  wrote:
>
> Maybe I failed to set the context here, as you rightly pointed out. This
> new proposed flow is for B2B or system to system interactions only, i.e. no
> user agents (browsers) and no humans (end users) are involved, so there are
> no user agent redirects…
>
>
>
> In standard OAuth, for system to system access tokens are obtained using
> client_credentials grant type, where resource owner client authenticates to
> AS and obtains a token which it then uses to access its own resources held
> at resource server. No third party client is involved in this flow because
> this is direct access by resource owner to its own resources – there is no
> delegation and no “on behalf of access”…
>
>
>
> There is no delegated flow for system to system access in the standard
> OAuth, as far as I know…
>
>
>
>
>
> *From:* Warren Parad [mailto:wpa...@rhosys.ch]
> *Sent:* Sunday, 19 May 2024 9:18 PM
> *To:* Igor Janicijevic 
> *Cc:* Thomas Broyer ;   >
> *Subject:* Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B
> Authorization
>
>
>
> Maybe let's separate those two things for a second:
>
>1.  Third party acquiring token to access RS
>2.  RO revoking token generated for the Third Party client
>
>
>
> For #1. I'd be interested to know how this is any different from an OAuth
> Client that wants to access RS on behalf of the RO. In this case the
> "Client" would be the Third Party (TP). TP redirects user agent to AS to
> authorize token generation, then AS redirects user agent back to TP with
> auth_code/refresh token/etc.
>
>
>
> The token issued by AS to third party client is not presented to the
> resource owner client
>
>
>
> Correct, and isn't that the same as the standard OAuth flow? If not I
> think additional context there would be appreciated.
>
>
>
> - Warren
>
>
>
> On Sun, May 19, 2024 at 1:01 PM Igor Janicijevic  wrote:
>
> Hi Warren,
>
>
>
> There are four parties in this flow: the resource owner client, the third
> party client, the resource server and the AS. The token issued by AS to
> third party client is not presented to the resource owner client – it is
> only presented to the resource server when third party client is accessing
> the resources. This means that the resource owner client cannot revoke that
> token because it will have to have a possession of it to present it to the
> revocation endpoint… Maybe I am completely missing your point, so can you,
> please, clarify.
>
>
>
> Cheers,
>
> Igor
>
>
>
>
>
> *From:* Warren Parad [mailto:wpa...@rhosys.ch]
> *Sent:* Sunday, 19 May 2024 7:14 PM
> *To:* Igor Janicijevic 
> *Cc:* Thomas Broyer ;   >
> *Subject:* Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B
> Authorization
>
>
>
> But the AS is already governing the access between clients, so at the
> surface at least I'm not able to wrap my head around your counterargument.
>
>
>
> Also this:
>
> Also, the resource owner client cannot easily revoke tokens issued to
> third party clients that it federates access with.
>
>
>
> Why not? It is just as easy to revoke a token issued to third party
> clients as it is to do in any OAuth compatible RS. What makes this case
> special for you, that the "Resource Owner" (your service client) in this
> case would not be able to revoke the tokens issued to the "Client" (the
> Third party application).
>
>
>
> Isn't this all doable with OAuth in spec without any magic?
>
>
>
> On Sun, May 19, 2024 at 10:28 AM Igor Janicijevic  

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

[Warren Parad]

Okay but that just creates more unanswered questions. Now we are at three
for this part:

   1. What does an RO obtaining scopes to its own resource mean
   2. How does it obtain scopes to its own resource
   3. How does the RO decide which scopes to delegate to the TP client?




On Sun, May 19, 2024 at 2:15 PM Igor Janicijevic  wrote:

> The idea is that the resource owner client can delegate some or all of its
> own scopes. For example, if the resource owner client can obtain “read” and
> “write” scopes on its own resource, it can decide to delegate “read” scope
> for that resource to the third party client, but not the “write” scope.
> This means that the third party client will only be able to obtain read
> only access to that resource and will not be able to update the resource.
>
>
>
> *From:* Warren Parad [mailto:wpa...@rhosys.ch]
> *Sent:* Sunday, 19 May 2024 9:57 PM
> *To:* Igor Janicijevic 
> *Cc:* Thomas Broyer ;   >
> *Subject:* Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B
> Authorization
>
>
>
> Hmmm, interesting. How does the first-party client decide which scopes to
> grant to the third party service?
>
>
>
> On Sun, May 19, 2024 at 1:52 PM Igor Janicijevic  wrote:
>
> Maybe I failed to set the context here, as you rightly pointed out. This
> new proposed flow is for B2B or system to system interactions only, i.e. no
> user agents (browsers) and no humans (end users) are involved, so there are
> no user agent redirects…
>
>
>
> In standard OAuth, for system to system access tokens are obtained using
> client_credentials grant type, where resource owner client authenticates to
> AS and obtains a token which it then uses to access its own resources held
> at resource server. No third party client is involved in this flow because
> this is direct access by resource owner to its own resources – there is no
> delegation and no “on behalf of access”…
>
>
>
> There is no delegated flow for system to system access in the standard
> OAuth, as far as I know…
>
>
>
>
>
> *From:* Warren Parad [mailto:wpa...@rhosys.ch]
> *Sent:* Sunday, 19 May 2024 9:18 PM
> *To:* Igor Janicijevic 
> *Cc:* Thomas Broyer ;   >
> *Subject:* Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B
> Authorization
>
>
>
> Maybe let's separate those two things for a second:
>
>1.  Third party acquiring token to access RS
>2.  RO revoking token generated for the Third Party client
>
>
>
> For #1. I'd be interested to know how this is any different from an OAuth
> Client that wants to access RS on behalf of the RO. In this case the
> "Client" would be the Third Party (TP). TP redirects user agent to AS to
> authorize token generation, then AS redirects user agent back to TP with
> auth_code/refresh token/etc.
>
>
>
> The token issued by AS to third party client is not presented to the
> resource owner client
>
>
>
> Correct, and isn't that the same as the standard OAuth flow? If not I
> think additional context there would be appreciated.
>
>
>
> - Warren
>
>
>
> On Sun, May 19, 2024 at 1:01 PM Igor Janicijevic  wrote:
>
> Hi Warren,
>
>
>
> There are four parties in this flow: the resource owner client, the third
> party client, the resource server and the AS. The token issued by AS to
> third party client is not presented to the resource owner client – it is
> only presented to the resource server when third party client is accessing
> the resources. This means that the resource owner client cannot revoke that
> token because it will have to have a possession of it to present it to the
> revocation endpoint… Maybe I am completely missing your point, so can you,
> please, clarify.
>
>
>
> Cheers,
>
> Igor
>
>
>
>
>
> *From:* Warren Parad [mailto:wpa...@rhosys.ch]
> *Sent:* Sunday, 19 May 2024 7:14 PM
> *To:* Igor Janicijevic 
> *Cc:* Thomas Broyer ;   >
> *Subject:* Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B
> Authorization
>
>
>
> But the AS is already governing the access between clients, so at the
> surface at least I'm not able to wrap my head around your counterargument.
>
>
>
> Also this:
>
> Also, the resource owner client cannot easily revoke tokens issued to
> third party clients that it federates access with.
>
>
>
> Why not? It is just as easy to revoke a token issued to third party
> clients as it is to do in any OAuth compatible RS. What makes this case
> special for you, that the "Resource Owner" (your service client) in this
> case would not be able to revoke the tokens issued to the "Client" (the
> Third party application).
>
>
>
> Isn't this all doable with OAuth in spec without any magic?
>
>
>
> On Sun, May 19, 2024 at 10:28 AM Igor Janicijevic  wrote:
>
> 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 

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

[Igor Janicijevic]

The idea is that the resource owner client can delegate some or all of its own 
scopes. For example, if the resource owner client can obtain “read” and “write” 
scopes on its own resource, it can decide to delegate “read” scope for that 
resource to the third party client, but not the “write” scope.  This means that 
the third party client will only be able to obtain read only access to that 
resource and will not be able to update the resource.

From: Warren Parad [mailto:wpa...@rhosys.ch]
Sent: Sunday, 19 May 2024 9:57 PM
To: Igor Janicijevic 
Cc: Thomas Broyer ;  
Subject: Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B 
Authorization

Hmmm, interesting. How does the first-party client decide which scopes to grant 
to the third party service?

On Sun, May 19, 2024 at 1:52 PM Igor Janicijevic 
mailto:i...@ivagor.com>> wrote:
Maybe I failed to set the context here, as you rightly pointed out. This new 
proposed flow is for B2B or system to system interactions only, i.e. no user 
agents (browsers) and no humans (end users) are involved, so there are no user 
agent redirects…

In standard OAuth, for system to system access tokens are obtained using 
client_credentials grant type, where resource owner client authenticates to AS 
and obtains a token which it then uses to access its own resources held at 
resource server. No third party client is involved in this flow because this is 
direct access by resource owner to its own resources – there is no delegation 
and no “on behalf of access”…

There is no delegated flow for system to system access in the standard OAuth, 
as far as I know…


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

Maybe let's separate those two things for a second:

  1.   Third party acquiring token to access RS
  2.   RO revoking token generated for the Third Party client

For #1. I'd be interested to know how this is any different from an OAuth 
Client that wants to access RS on behalf of the RO. In this case the "Client" 
would be the Third Party (TP). TP redirects user agent to AS to authorize token 
generation, then AS redirects user agent back to TP with auth_code/refresh 
token/etc.

The token issued by AS to third party client is not presented to the resource 
owner client

Correct, and isn't that the same as the standard OAuth flow? If not I think 
additional context there would be appreciated.

- Warren

On Sun, May 19, 2024 at 1:01 PM Igor Janicijevic 
mailto:i...@ivagor.com>> wrote:
Hi Warren,

There are four parties in this flow: the resource owner client, the third party 
client, the resource server and the AS. The token issued by AS to third party 
client is not presented to the resource owner client – it is only presented to 
the resource server when third party client is accessing the resources. This 
means that the resource owner client cannot revoke that token because it will 
have to have a possession of it to present it to the revocation endpoint… Maybe 
I am completely missing your point, so can you, please, clarify.

Cheers,
Igor


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

But the AS is already governing the access between clients, so at the surface 
at least I'm not able to wrap my head around your counterargument.

Also this:
Also, the resource owner client cannot easily revoke tokens issued to third 
party clients that it federates access with.

Why not? It is just as easy to revoke a token issued to third party clients as 
it is to do in any OAuth compatible RS. What makes this case special for you, 
that the "Resource Owner" (your service client) in this case would not be able 
to revoke the tokens issued to the "Client" (the Third party application).

Isn't this all doable with OAuth in spec without any magic?

On Sun, May 19, 2024 at 10:28 AM Igor Janicijevic 
mailto:i...@ivagor.com>> wrote:
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) 

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

[Warren Parad]

Hmmm, interesting. How does the first-party client decide which scopes to
grant to the third party service?

On Sun, May 19, 2024 at 1:52 PM Igor Janicijevic  wrote:

> Maybe I failed to set the context here, as you rightly pointed out. This
> new proposed flow is for B2B or system to system interactions only, i.e. no
> user agents (browsers) and no humans (end users) are involved, so there are
> no user agent redirects…
>
>
>
> In standard OAuth, for system to system access tokens are obtained using
> client_credentials grant type, where resource owner client authenticates to
> AS and obtains a token which it then uses to access its own resources held
> at resource server. No third party client is involved in this flow because
> this is direct access by resource owner to its own resources – there is no
> delegation and no “on behalf of access”…
>
>
>
> There is no delegated flow for system to system access in the standard
> OAuth, as far as I know…
>
>
>
>
>
> *From:* Warren Parad [mailto:wpa...@rhosys.ch]
> *Sent:* Sunday, 19 May 2024 9:18 PM
> *To:* Igor Janicijevic 
> *Cc:* Thomas Broyer ;   >
> *Subject:* Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B
> Authorization
>
>
>
> Maybe let's separate those two things for a second:
>
>1.  Third party acquiring token to access RS
>2.  RO revoking token generated for the Third Party client
>
>
>
> For #1. I'd be interested to know how this is any different from an OAuth
> Client that wants to access RS on behalf of the RO. In this case the
> "Client" would be the Third Party (TP). TP redirects user agent to AS to
> authorize token generation, then AS redirects user agent back to TP with
> auth_code/refresh token/etc.
>
>
>
> The token issued by AS to third party client is not presented to the
> resource owner client
>
>
>
> Correct, and isn't that the same as the standard OAuth flow? If not I
> think additional context there would be appreciated.
>
>
>
> - Warren
>
>
>
> On Sun, May 19, 2024 at 1:01 PM Igor Janicijevic  wrote:
>
> Hi Warren,
>
>
>
> There are four parties in this flow: the resource owner client, the third
> party client, the resource server and the AS. The token issued by AS to
> third party client is not presented to the resource owner client – it is
> only presented to the resource server when third party client is accessing
> the resources. This means that the resource owner client cannot revoke that
> token because it will have to have a possession of it to present it to the
> revocation endpoint… Maybe I am completely missing your point, so can you,
> please, clarify.
>
>
>
> Cheers,
>
> Igor
>
>
>
>
>
> *From:* Warren Parad [mailto:wpa...@rhosys.ch]
> *Sent:* Sunday, 19 May 2024 7:14 PM
> *To:* Igor Janicijevic 
> *Cc:* Thomas Broyer ;   >
> *Subject:* Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B
> Authorization
>
>
>
> But the AS is already governing the access between clients, so at the
> surface at least I'm not able to wrap my head around your counterargument.
>
>
>
> Also this:
>
> Also, the resource owner client cannot easily revoke tokens issued to
> third party clients that it federates access with.
>
>
>
> Why not? It is just as easy to revoke a token issued to third party
> clients as it is to do in any OAuth compatible RS. What makes this case
> special for you, that the "Resource Owner" (your service client) in this
> case would not be able to revoke the tokens issued to the "Client" (the
> Third party application).
>
>
>
> Isn't this all doable with OAuth in spec without any magic?
>
>
>
> On Sun, May 19, 2024 at 10:28 AM Igor Janicijevic  wrote:
>
> 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 
> *Cc:* Igor Janicijevic ;   >
> *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  wrote:
>
> Isn't that covered by Token Exchange already?
>
> https://datatracker.ietf.org/doc/html/rfc8693
>
>
>
> Le 

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

[Igor Janicijevic]

Maybe I failed to set the context here, as you rightly pointed out. This new 
proposed flow is for B2B or system to system interactions only, i.e. no user 
agents (browsers) and no humans (end users) are involved, so there are no user 
agent redirects…

In standard OAuth, for system to system access tokens are obtained using 
client_credentials grant type, where resource owner client authenticates to AS 
and obtains a token which it then uses to access its own resources held at 
resource server. No third party client is involved in this flow because this is 
direct access by resource owner to its own resources – there is no delegation 
and no “on behalf of access”…

There is no delegated flow for system to system access in the standard OAuth, 
as far as I know…


From: Warren Parad [mailto:wpa...@rhosys.ch]
Sent: Sunday, 19 May 2024 9:18 PM
To: Igor Janicijevic 
Cc: Thomas Broyer ;  
Subject: Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B 
Authorization

Maybe let's separate those two things for a second:

  1.   Third party acquiring token to access RS
  2.   RO revoking token generated for the Third Party client

For #1. I'd be interested to know how this is any different from an OAuth 
Client that wants to access RS on behalf of the RO. In this case the "Client" 
would be the Third Party (TP). TP redirects user agent to AS to authorize token 
generation, then AS redirects user agent back to TP with auth_code/refresh 
token/etc.

The token issued by AS to third party client is not presented to the resource 
owner client

Correct, and isn't that the same as the standard OAuth flow? If not I think 
additional context there would be appreciated.

- Warren

On Sun, May 19, 2024 at 1:01 PM Igor Janicijevic 
mailto:i...@ivagor.com>> wrote:
Hi Warren,

There are four parties in this flow: the resource owner client, the third party 
client, the resource server and the AS. The token issued by AS to third party 
client is not presented to the resource owner client – it is only presented to 
the resource server when third party client is accessing the resources. This 
means that the resource owner client cannot revoke that token because it will 
have to have a possession of it to present it to the revocation endpoint… Maybe 
I am completely missing your point, so can you, please, clarify.

Cheers,
Igor


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

But the AS is already governing the access between clients, so at the surface 
at least I'm not able to wrap my head around your counterargument.

Also this:
Also, the resource owner client cannot easily revoke tokens issued to third 
party clients that it federates access with.

Why not? It is just as easy to revoke a token issued to third party clients as 
it is to do in any OAuth compatible RS. What makes this case special for you, 
that the "Resource Owner" (your service client) in this case would not be able 
to revoke the tokens issued to the "Client" (the Third party application).

Isn't this all doable with OAuth in spec without any magic?

On Sun, May 19, 2024 at 10:28 AM Igor Janicijevic 
mailto:i...@ivagor.com>> wrote:
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 mailto:t.bro...@gmail.com>>
Cc: Igor Janicijevic mailto:i...@ivagor.com>>; 
mailto:oauth@ietf.org>> mailto: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 
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 
mailto:i...@ivagor.com>> a écrit :
Dear All,

I have published an Internet Draft document that I would like to 

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

[Warren Parad]

Maybe let's separate those two things for a second:

   1.  Third party acquiring token to access RS
   2.  RO revoking token generated for the Third Party client


For #1. I'd be interested to know how this is any different from an OAuth
Client that wants to access RS on behalf of the RO. In this case the
"Client" would be the Third Party (TP). TP redirects user agent to AS to
authorize token generation, then AS redirects user agent back to TP with
auth_code/refresh token/etc.

The token issued by AS to third party client is not presented to the
> resource owner client


Correct, and isn't that the same as the standard OAuth flow? If not I think
additional context there would be appreciated.

- Warren

On Sun, May 19, 2024 at 1:01 PM Igor Janicijevic  wrote:

> Hi Warren,
>
>
>
> There are four parties in this flow: the resource owner client, the third
> party client, the resource server and the AS. The token issued by AS to
> third party client is not presented to the resource owner client – it is
> only presented to the resource server when third party client is accessing
> the resources. This means that the resource owner client cannot revoke that
> token because it will have to have a possession of it to present it to the
> revocation endpoint… Maybe I am completely missing your point, so can you,
> please, clarify.
>
>
>
> Cheers,
>
> Igor
>
>
>
>
>
> *From:* Warren Parad [mailto:wpa...@rhosys.ch]
> *Sent:* Sunday, 19 May 2024 7:14 PM
> *To:* Igor Janicijevic 
> *Cc:* Thomas Broyer ;   >
> *Subject:* Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B
> Authorization
>
>
>
> But the AS is already governing the access between clients, so at the
> surface at least I'm not able to wrap my head around your counterargument.
>
>
>
> Also this:
>
> Also, the resource owner client cannot easily revoke tokens issued to
> third party clients that it federates access with.
>
>
>
> Why not? It is just as easy to revoke a token issued to third party
> clients as it is to do in any OAuth compatible RS. What makes this case
> special for you, that the "Resource Owner" (your service client) in this
> case would not be able to revoke the tokens issued to the "Client" (the
> Third party application).
>
>
>
> Isn't this all doable with OAuth in spec without any magic?
>
>
>
> On Sun, May 19, 2024 at 10:28 AM Igor Janicijevic  wrote:
>
> 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 
> *Cc:* Igor Janicijevic ;   >
> *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  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  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 

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

[Igor Janicijevic]

Hi Warren,

There are four parties in this flow: the resource owner client, the third party 
client, the resource server and the AS. The token issued by AS to third party 
client is not presented to the resource owner client – it is only presented to 
the resource server when third party client is accessing the resources. This 
means that the resource owner client cannot revoke that token because it will 
have to have a possession of it to present it to the revocation endpoint… Maybe 
I am completely missing your point, so can you, please, clarify.

Cheers,
Igor


From: Warren Parad [mailto:wpa...@rhosys.ch]
Sent: Sunday, 19 May 2024 7:14 PM
To: Igor Janicijevic 
Cc: Thomas Broyer ;  
Subject: Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B 
Authorization

But the AS is already governing the access between clients, so at the surface 
at least I'm not able to wrap my head around your counterargument.

Also this:
Also, the resource owner client cannot easily revoke tokens issued to third 
party clients that it federates access with.

Why not? It is just as easy to revoke a token issued to third party clients as 
it is to do in any OAuth compatible RS. What makes this case special for you, 
that the "Resource Owner" (your service client) in this case would not be able 
to revoke the tokens issued to the "Client" (the Third party application).

Isn't this all doable with OAuth in spec without any magic?

On Sun, May 19, 2024 at 10:28 AM Igor Janicijevic 
mailto:i...@ivagor.com>> wrote:
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 mailto:t.bro...@gmail.com>>
Cc: Igor Janicijevic mailto:i...@ivagor.com>>; 
mailto:oauth@ietf.org>> mailto: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 
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 
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
To unsubscribe send an email to 
oauth-le...@ietf.org
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to 
oauth-le...@ietf.org
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: New draft: OAuth Profile for Open Public Clients

[Vladimir Dzhuvinov]

Interesting draft. Having standard defined scopes for the most common operations of the underlying protocols is crucial, as Lisa points out. In OpenID Connect this was indispensable in making the whole thing complete, useful and interoperable. But where should these scopes get defined, if this is a spec for a general open public profile, and not email specific? ( as implied by the title )The dynamic client registration (DCR) will probably need implementers to consider measures against DoS attacks. One such measure could be the automatic expiration of client registrations that remain unused or where the client doesn't receive a token within a certain time.On 18 May 2024, at 1:12, Lisa Dusseault  wrote:Hi Neil,Thanks for publishing this, it's really great and will be most helpful.  The explanation of when the server uses DPoP and therefore when the client uses DPoP is pretty clear, but is it the intent that the HTTP-based protocols MUST use DPoP or is that really a RECOMMENDED for HTTP-based servers ?  Ie. did you intend "RECOMMEND use DPop" to mean  "MUST if you can but not if you can't" ? I know your document says that a separate document will define the scopes, but if you pull the scopes into this document ISTM it will really be a complete solution to many use cases. Without the scopes this does not stand alone and implementable and interoperable, whereas I think that just adding scopes will make it so.  (Also, I don't think the autodiscovery document will need to be a dependency but I may be wrong. ). You've clearly already thought about whether the scopes should be in this document or not,  can you expand on that?  I would love it if this went to the Standards Track.  Lisa DusseaultOn Thu, May 16, 2024 at 8:56 PM Neil Jenkins 40fastmailteam@dmarc.ietf.org> wrote:Hello all,I have published a draft document I'd like to introduce to the working group to consider: OAuth Profile for Open Public Clients.BackgroundI work for Fastmail, and we organised a conference at the end of last year with a bunch of the other major mailbox providers to work on interoperability and improving the open ecosystem. The topic most on everyone's minds was authentication.Unlike all the walled garden messaging systems, email remains to a large extent open. There are standard protocols (IMAP [RFC9051], SMTP [RFC5321], and more recently JMAP [RFC8620][RFC8621]) so you can have clients and servers built by different vendors, with no pre-existing relationship. Indeed, there are probably thousands of clients, and hundreds of thousands of servers out there. The situation is similar with contacts and calendars.Most server providers (and indeed many client authors) would like to move to a more secure authentication system, but at the moment basic auth is the only interoperable mechanism. Many clients have hardcoded Gmail/Microsoft OAuth flows (as those companies are big enough to force them to do so!), but this does not scale. At the conference we worked on building an OAuth profile that we believe can significantly increase security compared to the current status quo, to allow native Email/Contacts/Calendar clients to authenticate with an arbitrary server.I have talked to a few of you individually at the last couple of IETF meetings, and have finally had time to write up our proposal.Next stepsFirst of all, hopefully the working group can agree that this is a problem space that is significant, and worth addressing. If so, I hope it chooses to adopt this document as  a good starting point. I am not sure whether this should be a BCP rather than Standards Track — it deliberately does not introduce anything new, just combines a lot of existing standards in a specific way suitable for this use case.I will not be in Vancouver in person, but will join remotely. I do plan to be in Dublin. My current understanding is there are vendors such as Apple looking to start implementing something in this space in the nearish future, and obviously we would all like an agreed profile to ensure interoperability! They may be able to send someone to Vancouver.I would be very happy to bring on a co-author (or indeed largely pass it over to them, as I am very busy with other work at the moment, hence the delay in getting this draft together). I will certainly remain involved in any discussions around this area of course.I look forward to your feedback.Cheers,Neil.___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

___OAuth mailing list -- oauth@ietf.orgTo unsubscribe send an email to oauth-le...@ietf.org

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

[Warren Parad]

But the AS is already governing the access between clients, so at the
surface at least I'm not able to wrap my head around your counterargument.

Also this:

> Also, the resource owner client cannot easily revoke tokens issued to
> third party clients that it federates access with.


Why not? It is just as easy to revoke a token issued to third party clients
as it is to do in any OAuth compatible RS. What makes this case special
for you, that the "Resource Owner" (your service client) in this case would
not be able to revoke the tokens issued to the "Client" (the Third party
application).

Isn't this all doable with OAuth in spec without any magic?

On Sun, May 19, 2024 at 10:28 AM Igor Janicijevic  wrote:

> 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 
> *Cc:* Igor Janicijevic ;   >
> *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  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  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
> To unsubscribe send an email to oauth-le...@ietf.org
>
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

[Igor Janicijevic]

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 
Cc: Igor Janicijevic ;  
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 
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 
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
To unsubscribe send an email to 
oauth-le...@ietf.org
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to 
oauth-le...@ietf.org
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Weekly github digest (OAuth Activity Summary)

[Repository Activity Summary Bot]

Events without label "editorial"

Issues
--
* oauth-wg/oauth-transaction-tokens (+2/-1/1)
 2 issues created:
 - Deployment models for the Transaction Token Service (by gffletch)
   https://github.com/oauth-wg/oauth-transaction-tokens/issues/96 
 - Define discovery metadata for support of the Transaction Token functionality (by gffletch)
   https://github.com/oauth-wg/oauth-transaction-tokens/issues/95 


 1 issues received 1 new comments:
 - #96 Deployment models for the Transaction Token Service (1 by gffletch)
   https://github.com/oauth-wg/oauth-transaction-tokens/issues/96 


 1 issues closed:
 - Replacement token `sub` and `aud` modification language https://github.com/oauth-wg/oauth-transaction-tokens/issues/82 


* oauth-wg/oauth-sd-jwt-vc (+2/-0/13)
 2 issues created:
 - Fix esolving type metadata from URL and limit to HTTPS URLs (by awoie)
   https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/233 
 - Constraints on using JWT VC Isser metadata and x5c (by paulbastian)
   https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/232 


 4 issues received 13 new comments:
 - #232 Constraints on using JWT VC Isser metadata and x5c (10 by awoie, 
peppelinux)
   https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/232 
 - #222 Add JWS JSON serialization example (1 by awoie)
   https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/222 [NEEDS PR] 
 - #221 Security considerations on integrity of Type Metadata (1 by bc-pi)
   https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/221 [NEEDS PR] [wg-04] [metadata] [PRIO] 
 - #205 defining how DID can be used as user's indetifier (1 by TimoGlastra)
   https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/205 [discuss] 


* oauth-wg/oauth-cross-device-security (+0/-1/0)
 1 issues closed:
 - Editorial update: Remove etc. https://github.com/oauth-wg/oauth-cross-device-security/issues/131 


* oauth-wg/oauth-selective-disclosure-jwt (+0/-4/5)
 4 issues received 5 new comments:
 - #419 why isn't cnf the only way to bind to a holder public key? (1 by bc-pi)
   https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/419 
 - #416 Add Test suite for SD-JWT (2 by bc-pi, lukasjhan)
   https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/416 [ready-for-PR] [pending-close] 
 - #403 Redesign JWS JSON Serialization (1 by bc-pi)
   https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/403 [has-PR] 
 - #372 Clarify algorithms to accommodate recursive redaction (1 by danielfett)
   https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/372 


 4 issues closed:
 - Add Test suite for SD-JWT https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/416 [has-PR] 
 - More figures in Section 3 (Flow Diagram) https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/385 [pending-close] 
 - Redesign JWS JSON Serialization https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/403 [has-PR] 
 - JSON serialization doesn't cover key binding https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/392 [has-PR] 


* oauth-wg/oauth-v2-1 (+2/-3/14)
 2 issues created:
 - Typo: resource server instead of resource (by mrcaidev)
   https://github.com/oauth-wg/oauth-v2-1/issues/177 
 - Allow public clients to use the `client_credentials` grant type (by bellebaum)
   https://github.com/oauth-wg/oauth-v2-1/issues/176 


 7 issues received 14 new comments:
 - #176 Allow public clients to use the `client_credentials` grant type (8 by 
aaronpk, archer-321, bellebaum, dickhardt)
   https://github.com/oauth-wg/oauth-v2-1/issues/176 
 - #166 case sensitivity of Bearer http authentication scheme (1 by aaronpk)
   https://github.com/oauth-wg/oauth-v2-1/issues/166 [interim] 
 - #163 Scope in relation to OIDC (1 by aaronpk)
   https://github.com/oauth-wg/oauth-v2-1/issues/163 [interim] 
 - #162 the invalid_client error and HTTP authentication schemas (1 by jogu)
   https://github.com/oauth-wg/oauth-v2-1/issues/162 [interim] 
 - #142 Native apps differences between mobile and desktop apps (1 by aaronpk)
   https://github.com/oauth-wg/oauth-v2-1/issues/142 [draft-00-feedback] 
 - #141 Claimed https scheme as app identity proof (1 by jogu)
   https://github.com/oauth-wg/oauth-v2-1/issues/141 [draft-00-feedback] [interim] 
 - #128 Describe OAuth's use of application/x-www-form-urlencoded encoding (1 by aaronpk)
   https://github.com/oauth-wg/oauth-v2-1/issues/128 [help wanted] [interim] [ietf-117] 


 3 issues closed:
 - Describe OAuth's use of application/x-www-form-urlencoded encoding https://github.com/oauth-wg/oauth-v2-1/issues/128 [help wanted] [interim] [ietf-117] 
 - Scope in relation to OIDC https://github.com/oauth-wg/oauth-v2-1/issues/163 [interim] 
 - case sensitivity of Bearer http authentication scheme https://github.com/oauth-wg/oauth-v2-1/issues/166 




Pull requests
-
* oauth-wg/oauth-transaction-tokens (+0/-2/0)
 2 pull requests merged:
 - Update draft-ietf-oauth-transaction-tokens.md