[OAUTH-WG] Re: Authorization without interface for API testing

[Warren Parad]

Stanislav,

How to do this effectively is going to be based on the IdP you are using.
Most likely you need to use the *client_credentials* grant. But again,
you'll want to review the documentation from your IdP.

- Warren

On Tue, May 28, 2024 at 12:12 PM Stanislav Venger 
wrote:

> Hello! Please advise if there is any way to authorize without using the
> interface. We are writing API tests for which we need to first obtain a
> token. We tried to replicate requests from the network tab but received an
> error {'status': 'error', 'error_message': 'nonce_expired'}.
>
> Thank you!
> ___
> 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

[Warren Parad]

RS.
>
>
>
> The use case starts with the RO customer requesting a service from the RO.
> Instead of getting all the data itself from the RS, the RO sends the
> authorization request to the AS requesting a delegated access for the TP,
> asking for only the minimum required access in terms of resources and
> scopes. The AS responds with the authorization grant (authorization code).
> The RO then makes a service request to TP and passes the authorization code
> along. The TP exchanges the authorization code for an access token and then
> uses that token to access all the required data from the RS, performs the
> required processing and return the result to the RO. RO then uses that
> result to provide service response to its own customer. Although, it is
> possible to have the ongoing long lived delegation through refresh token
> issued to the TP, most of the time the delegation will be “once-off”, i.e.
> per service request with only short lived access token being issued to the
> TP.  This can be controlled via scopes, for example if no “offline_access”
> scope is included in the authorization request, the TP will not be able to
> obtain refresh token from the AS.
>
>
>
> Depending on the nature of the request that RO’s customer is making to the
> RO, the RO may request delegation to different resources using different
> scopes – this will be a part of RO service configuration. RO can also
> engage multiple TPs doing different types of processing as part of a single
> service request from its customer by implementing an orchestration of calls
> to its partners (TPs).
>
>
>
> I hope the above answers your question.
>
>
>
> Now, going to the flow that you suggested below, that is definitely more
> in line with a “standard” OAuth flow where TP asks for authorization and
> then AS asks RO for authorization.
>
>
>
> You can obviously involve a human user in the authorization, as you
> already pointed out.  In fact I have seen this implemented in the “wild”
> where a human user with a role of an administrator is involved in approving
> the authorization requests for B2B flows using standard authorization_code
> grant type. Once the application obtains the refresh token it proceeds to
> make B2B calls using refresh token to refresh its access tokens until
> refresh token expires.  After that the authorization process starts again.
> The obvious advantage of this solution that it uses the standard OAuth
> flow, however, there are significant drawbacks. For example, B2B processing
> relying on human intervention are not ideal from the operational point of
> view.  Also, the “admin” person will have to be a nominal “resource owner”
> for all resources that the TP application needs to access, which typically
> means that system level credentials (and access) are given to a human end
> user…
>
>
>
> The other option that you suggested, with an RO endpoint for authorization
> approval, is actually quite interesting. One way to solve for which RO
> should AS engage to approve the TP request could be to incorporate a new
> metadata element in the TP client registration to specify the RO endpoint,
> or something like that. Maybe RAR extension can also be used with the
> client_credential grant type to add more details on the actual delegation
> required and then those details can be passed on to the RO for approval.
> The authentication between the AS and the RO for approval requests will
> also need some consideration…  The only potential drawback is that RO needs
> to implement the approval endpoint, and in my experience that could be a
> problem… it is much easier for ROs to make calls to other people’s
> endpoints J
>
>
>
> Regards,
>
> Igor
>
>
>
>
>
> *From:* Warren Parad [mailto:wpa...@rhosys.ch]
> *Sent:* Sunday, 19 May 2024 11:41 PM
> *To:* Igor Janicijevic 
> *Cc:* Aaron Parecki ;  
> *Subject:* Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B
> Authorization
>
>
>
> 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 o

[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 th

[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 a

[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 D

[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 

[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

[Warren Parad]

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: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Warren Parad]

Some more evidence for this is most of our customers. We provide something
a bit different from Hello, but the ask is the same. The branding
experience for the widget must be fully controlled by the app developers,
this is the only way they'll support it. We have our own unified managed
login experience but most customers have designed a custom experience to
host inside their app.

Unless FedCM supports a purely API based flow, there is no way this is
going to get off the ground. Here, the authors of FedCM are so worried
about not allowing tracking, but while a problem, is not one that users
actually care about. They care about delivering their ticket at the top of
their backlog. That ticket doesn't say "make sure IDPs can't track our
users", it says "the login button must be blue".

In the future, no doubt there will be adoption in the long tail innovators
that don't care, but if we want actual usage by the early and late
majority, by actual companies and therefore provide value to actual users,
the UI must be fully controllable app side. So a full browser API for
handling user input and events for handling responses.

- Warren

On Tue, May 14, 2024, 02:35 Dick Hardt  wrote:

>
>
> On Mon, May 13, 2024 at 5:15 PM Sam Goto  wrote:
>
>>
>>
>> On Mon, May 13, 2024 at 4:50 PM Dick Hardt  wrote:
>>
>>>
>>>
>>> On Mon, May 13, 2024 at 4:33 PM David Waite <
>>> da...@alkaline-solutions.com> wrote:
>>>
 

 > On May 13, 2024, at 4:10 PM, Dick Hardt  wrote:

 > This seems in conflict with the Account Chooser that Google presents,
 which users now understand as a way for them to select which Google account
 they want to use. As a Google user, I find this experience with the Google
 IdP to work well. It would be confusing to me as a user if my name,
 picture, and email were not shown when selecting which Google account.  The
 "popup" like UX is nice on sites where I can use my Google account and
 provides a more seamless experience without a redirect, but I don't know of
 any other IdP that has deployed a similar UX.
 >
 > The challenge is that the "account chooser" is not how other IdPs
 interact with the user. For example with Hellō we let users have high
 fidelity on which name, email, picture they release with each RP, as
 studies[1] have shown that users will often pick a different combination of
 name / email / picture across sites that are crisply not aligned along
 personas captured in an account.

 The name, picture, and email are used for the picker displayed by the
 browser, based on IDP data for individual accounts. I do not believe these
 values are released to the RP (by the API) - the result of a successful
 interaction with the IDP for a selected user account is a credential object
 holding an IDP-provided string token. That token can contain or reference
 RP-specific attributes, such as pseudonyms.

>>>
>>> Did you look at the referenced issue?
>>> While the name/picture/email may not be released to the RP, it may not
>>> be clear to the user what will be released, particularly one that is not
>>> familiar with the Google Account Chooser.
>>>
>>
>> After the account chooser, IdPs can choose to use the Continuation API (
>> https://github.com/fedidcg/FedCM/issues/555), which allows them to open
>> a pop-up window to tell the user - using their own words in html/css/js -,
>> what's going to be shared with the RP.
>>
>> Would that help?
>>
>
> For Hellō, the popup would be a confusing UX as Hellō is an IdP
> aggregator, and a full redirect is a better experience on desktop as it is
> not just a release page as the user may select other IdPs / Issuers to
> gather additional data.
>
> I still think that we will get into an IdP permissioning model of some
> kind if the browsers are going to want to block link decorating redirects.
> A number of federation protocol features depend on 3P cookies -- and this
> is the most straightforward way to allow 3P cookies where they are needed,
> and pave a path to start blocking decorated redirects.
>
> IMHO browsers should manage permissions, not provide application level UX,
> which I consider login / registration to be.
>
> ___
> 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: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Warren Parad]

If someone uses the auth code flow, how would the account chooser display
anything?

On Fri, May 10, 2024, 18:53 Neil Madden  wrote:

>
>
> On 10 May 2024, at 17:07, Sam Goto  wrote:
>
> On Fri, May 10, 2024 at 2:41 AM Neil Madden 
> wrote:
>
>> On 9 May 2024, at 21:58, Watson Ladd  wrote:
>> >
>> > On Thu, May 9, 2024 at 7:24 AM Neil Madden 
>> wrote:
>> >>
>> >> On 9 May 2024, at 00:06, Sam Goto  wrote:
>> >>
>> >> [...]
>> >>>
>> >>>
>> >>> I guess, flipping this around, we might ask what is the legitimate
>> purpose for which browsers need to access the user’s name, email address
>> (both requires) and other identifying information? I’d have thought an
>> identifier (possibly randomised) and some user-supplied account nickname
>> would be sufficient.
>> >>
>> >>
>> >> That's easier to answer: the browser needs name/email/picture to
>> construct an account chooser, which is the UX that tested best with users
>> by a far margin.
>> >>
>> >> Static/unpersonalized permission prompts - example in Safari, example
>> in Chrome - perform extremely poorly (in comparison to account choosers),
>> although have other benefits too (namely ergonomics and extensibility), so
>> Chrome (and others) expose that too in the form of the Storage Access API.
>> >>
>> >>
>> >>
>> >> Yeah, that's what I suspected. Did you do research that specifically
>> called out email addresses as a must-have?
>> >
>> > I'm sort of mystified here by the objection.
>> >
>> > What exactly is the alternative where the user agent doesn't have
>> > access to all of the data passing through it?
>>
>> With auth code flow the data doesn't pass through the user agent at all.
>> With encrypted ID tokens it does, but is not accessible to the UA.
>>
>
> Neil, just checking, but is it clear to you that the UA doesn't make an
> imposition on what's passed back to the RP (e.g. ID tokens vs access
> tokens)? An IdP can return whatever it wants back to RP in the id
> assertion endpoint
>  as a
> string   (e.g.
> a Base64 encoded JWT, an access token, a binary blob, a JPEG image, an mp3
> file, etc), which doesn't get introspected by the UA.
>
> The only data that does get instrospected by the UA is the result of the 
> accounts
> endpoint ,
> which is used to construct an account chooser.
>
> I was assuming we were having a discussion around the accounts endpoint,
> not the id assertion endpoint.
>
>
> Yes, that's correct. The accounts endpoint mandates that the IDP expose
> PII to the UA that otherwise needn't be. If you use the auth code flow,
> other than what the user provides to authenticate (under their control), no
> identity information at all is exposed to the user agent.
>
> (I appreciate such PII _often_ will be exposed by the IDP UI anyway, but
> it is a significant change to make it mandatory).
>
>
>> > In particular user
>> > emails are everywhere in the User Agent. It's in the autofill
>> > settings, the webmail interface, every signup form filled out etc,
>> > etc.
>>
>> Many OAuth flows are not OIDC. There's no guarantee that the AS even has
>> access to any identity information beyond a username.
>>
>> >
>> > To be absolutely clear today the information generally appears in big
>> > bold text to confirm the user wants to pass it to the RP, and those
>> > letters are made to appear on screen through a process the User Agent
>> > is very involved in. It also got typed in by the user (or autofilled
>> > by the user agent) when signing into the IdPs. Usually there are UI
>> > ways to confirm what account you are signed into that depend on
>> > similar APIs. And everything the user does is done through the User
>> > Agent. Is there some exotic setup that I'm ignoring here?
>> >
>> > I'm just very confused as to why this is a problem.
>>
>> There's a lot of background assumptions there -- do we want to bake those
>> into the web for all eternity? Yes, email addresses are passed around like
>> candy on the web currently, but I don't think that is a good thing.
>>
>>
> Yeah, I'm in agreement with that.
>
> I think the "MUST use email" emphasis on Neil's original point is the key
> one to me: I am convinced that it MUST NOT, i.e. FedCM must be able to
> operate in the absence of email addresses.
>
>
> Great.
>
>
>
>> As for how this could be an issue, imagine you are giving a
>> presentation/demo at work and you go to login to a website (not uncommon)
>> and up pops a box asking if you want to login with your xyz.example account
>> (pornhub, grindr, whatever) -- revealing some sensitive or embarassing
>> information about you, such as your sexual orientation. The idea that it is
>> a perfectly neutral and acceptable thing for the browser to make background
>> requests *prior to* consent that pull in personal info from all kinds of
>> sources is deeply suspect IMO.

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Warren Parad]

I think I'm still missing something, and I'm sure it was discussed
somewhere and I just didn't see it. How will this help avoid the NASCAR
problem, for sites when a user *signs up* or when the user *signs in on a
new browser?*

On Thu, May 9, 2024 at 1:07 AM Sam Goto 
wrote:

>
>
> On Wed, May 8, 2024 at 3:50 PM Neil Madden 
> wrote:
>
>> On 8 May 2024, at 22:01, Joseph Heenan  wrote:
>>
>>
>> On 8 May 2024, at 21:43, Sam Goto  wrote:
>>
>>
>>
>> On Wed, May 8, 2024 at 1:34 PM Joseph Heenan  wrote:
>>
>>> Hi Neil
>>>
>>>
>>> On 8 May 2024, at 18:45, Neil Madden  wrote:
>>>
>>>
>>> On 8 May 2024, at 17:52, Sam Goto  wrote:
>>>
>>> On Wed, May 8, 2024 at 7:23 AM Neil Madden 
>>> wrote:
>>>
>>>
>>>
>>>
 In particular, the call to the accounts endpoint assumes that the IdP
 is willing to provide PII about the user to the browser. That seems
 questionable.

>>>
>>> Aside from a privacy/security threat model perspective (meaning, the
>>> user agent already has visibility over every network request made available
>>> to the content area)
>>>
>>>
>>> Sure, but if I use the recommended auth code flow or encrypted ID
>>> tokens, then PII is not exposed to the browser. And it’s not just the
>>> browser itself in the current proposal, as the token is exposed to
>>> javascript, of course, so the usual XSS risks.
>>>
>>>
>>> Sam’s response here is fair, but also note that as far as I understand
>>> it you can still use the authorization code flow or encrypted id tokens
>>> with the FedCM API
>>>
>>
>> That's correct: the browser doesn't open the response from the IdP to the
>> RP, so it can, for example, be encrypted.
>>
>> I was assuming that Neil was referring to the fact that the
>> id_assertion_endpoint (which contains the user's IdP's PII accounts
>> )
>> become, suddenly, transparent to the browser.
>>
>>
>> Oh yes, that’s true - but (I think) the data from the
>> id_assertion_endpoint at least isn’t exposed to javascript and isn’t
>> vulnerable to XSS?
>>
>>
>> That depends on whether the IdP correctly enforces the presence of the
>> sec-fetch-dest header. If it doesn’t then yes, it would be vulnerable.
>> Presumably it’s also vulnerable on older/niche browsers that don’t block
>> sec-* headers: caniuse.com reckons > 8% of users globally are using
>> browsers that don’t understand any sec-fetch-* headers. I’m not sure when
>> sec-* was added to the forbidden list.
>>
>> I guess, flipping this around, we might ask what is the legitimate
>> purpose for which browsers need to access the user’s name, email address
>> (both requires) and other identifying information? I’d have thought an
>> identifier (possibly randomised) and some user-supplied account nickname
>> would be sufficient.
>>
>
> That's easier to answer: the browser needs name/email/picture to construct an
> account chooser
> ,
> which is the UX that tested best with users by a far margin.
>
> Static/unpersonalized permission prompts - example
>  in
> Safari, example
> 
> in Chrome - perform extremely poorly (in comparison to account choosers),
> although have other benefits too (namely ergonomics and extensibility), so
> Chrome (and others) expose that too in the form of the Storage Access API
> .
>
>
>>
>> — Neil
>>
>> ___
> 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

Re: [OAUTH-WG] OAuth Digest, Vol 187, Issue 6

[Warren Parad]

I just marked it as spam, so his domain can deal with that. If everyone
does it, the domain may be permanently denylisted.

On Sun, May 5, 2024 at 9:50 PM Brian Campbell  wrote:

> Итак, у нас есть еще девять дней этих сообщений?
>
> On Sun, May 5, 2024 at 1:02 PM Konstantin Korsakov 
> wrote:
>
>> Я в отпуске до 13 мая. По срочным вопросам - звоните или пишите в
>> Телеграм.
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*___
> 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

Re: [OAUTH-WG] draft-zhang-jose-json-fine-grained-access

[Warren Parad]

Some thoughts in no particular order, but mostly I'm with Justin:

   1. The exact data properties of the json probably don't belong in this
   RFC, but rather can be used as an example in the RFC rather than
   anything normative, as the structure defined herein is not sufficient in
   many cases. Depending exactly on how (#2) is done, needs to be more
   extensible or potentially completely ignored since any JSON or even string
   could be used to achieve #2.
   2. The mechanism of how to use the json to encrypt and decrypt the
   message feels like the only relevant/interesting detail here and it is the
   main detail left out.

I'd recommend cutting the context related to the structure of the request
(#1) and focus on how it will be used to encrypt/decrypt payloads (#2).

- Warren


On Sat, Mar 23, 2024 at 10:38 AM Justin Richer  wrote:

> Thank you for presenting your proposal to the group in Brisbane.
>
> Reading through the draft, it seemed that there are really two topics in
> here, and I'm wondering how they could be split:
>
> 1, a data structure for complex access rights
>
> 2, a cryptographic mechanism for selectively encrypting some of those
> rights to protect them from unintentional audiences.
>
> The data structure used to convey the access rights seems very similar to
> the object structure defined by RAR, RFC9396:
> https://www.rfc-editor.org/rfc/RFC9396
>
> I was unable to find something in this data structure that is required to
> provide the cryptographic hiding functionality, have I missed something? Or
> would it be possible to apply this to RAR objects?
>
> Does the key distribution happen or of band of the protocol? In the oauth
> world, would these keys become part of the RS configuration?
>
> Thank you,
>
> - Justin
> --
> *From:* OAuth  on behalf of jiangcheng <
> jiangcheng...@163.com>
> *Sent:* Tuesday, March 19, 2024 9:42 PM
> *To:* OAuth@ietf.org 
> *Cc:* zhangjl382 ; jill32 <
> jil...@chinaunicom.cn>
> *Subject:* [OAUTH-WG] draft-zhang-jose-json-fine-grained-access
>
>
> Dear oauth，
>
>
>
>   We have a draft and we are looking forward to soliciting comments on
> it.
>
>   
> https://datatracker.ietf.org/doc/draft-zhang-jose-json-fine-grained-access/
>
>
> Best regards
>
>
> ___
> 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

Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

[Warren Parad]

Sachin,

Can I ask what your goal is here, as in what would you like out of this
conversation, what concrete if anything would like this working group to
action? It seems that you have had a question, which has been answered
multiple times (in multiple different email threads, I might add). The
language in the RFC is pretty clear, although, in practice I can see that
the usage might be a bit complex.

- Warren

On Wed, Feb 21, 2024 at 10:37 AM Sachin Mamoru 
wrote:

> Hi Neil,
>
> Since Access tokens are bound to scopes. These scopes define the
> permissions granted for accessing resources. When an access token is
> requested, it's issued with specific scopes based on the authorization
> granted by the resource owner.
>
> On the other hand, Refresh tokens are used to obtain new access tokens
> when the current access token expires or becomes invalid. The critical
> aspect here is that the refresh token itself is not bound by scopes in the
> same way access tokens are. Instead, the refresh token carries the
> potential to issue new access tokens with scopes that are the same as or
> narrower than the original scopes granted during the initial authorization
> process.
>
> When you use a refresh token to obtain a new access token, you have the
> option to request a scope that is narrower than the original scope.
>
> This is quite contradicting to me as the spec says that "refresh token
> scopes should be identical to that of the refresh token included by the
> client in the request". - When a refresh token is used to obtain a new
> access token, and a new refresh token is also issued in this process, the
> new refresh token must have the same scope as the refresh token that was
> used in the request.
> On the other hand, it says "Refresh tokens are issued to the client by the
> authorization server and are used to obtain a new access token when the
> current access token becomes invalid or expires, or to obtain additional
> access tokens with identical or narrower scope". - There's a flexibility in
> scope when using a refresh token to request new access tokens, but this
> flexibility might seem counterintuitive at first. Specifically, the idea
> that the scope of the new access token can be adjusted (narrowed) without
> altering the permissions granted by the refresh token itself.
>
> Thanks & Regards,
> Sachin
>
> On Wed, 21 Feb 2024 at 13:57, Neil Madden  wrote:
>
>> That section quite clearly says "*access tokens* with identical or
>> narrower scope". Not refresh tokens.
>>
>> -- Neil
>>
>> On 21 Feb 2024, at 08:24, Sachin Mamoru  wrote:
>>
>> Hi Warren and Neil,
>>
>> My basis for asking this is due to the following definition [1],
>>
>> Refresh tokens are credentials used to obtain access tokens.  Refresh
>>tokens are issued to the client by the authorization server and are
>>used to obtain a new access token when the current access token
>>becomes invalid or expires, or to obtain additional access tokens
>>with identical or narrower scope (access tokens may have a shorter
>>lifetime and fewer permissions than authorized by the resource
>>owner).  Issuing a refresh token is optional at the discretion of the
>>authorization server.  If the authorization server issues a refresh
>>token, it is included when issuing an access token (i.e., step (D) in
>>Figure 1).
>>
>> [1] https://datatracker.ietf.org/doc/html/rfc6749#section-1.5
>>
>> Thanks & Regards,
>> Sachin
>>
>> On Wed, 21 Feb 2024 at 13:36, Sachin Mamoru 
>> wrote:
>>
>>> Hi Warren and Neil,
>>>
>>> Thanks for the valuable input and sorry for mentioning other products, I
>>> just wanted to provide an example.
>>> So Warren according to you following is the behaviour that spec
>>> suggested.
>>>
>>> When we request an access token using 3 scopes (scope1, scope2, scope3).
>>>
>>> Then will receive a refresh token (refresh_token1) with the access token.
>>>
>>> After that will request another access token with refresh_token1 and
>>> provide the scope list as scope1 and scope2 (Narrow down scopes).
>>>
>>> Similarly, get another refresh token (refresh_token2) with the access
>>> token.
>>>
>>> Now if we request another access token with refresh_token2, we should be
>>> able to request scope3 also.
>>> That means the refresh token will not be narrowed down instead only the
>>> access token will get narrowed down.
>>>
>>> So Warren and Neil, if possible can you pinpoint to me the exact place
>>> in the spec where it does explicitly say that the refresh token should not
>>> be narrowed down based on the given scopes?
>>>
>>> Thanks & Regards,
>>> Sachin
>>>
>>> On Wed, 21 Feb 2024 at 01:12, Neil Madden 
>>> wrote:
>>>
 It sounds like they are violating the spec then. On the other hand, the
 fact that the scope can be "increased back to the original scope" maybe
 suggests the effective scope of the refresh token is still the same? Either
 way, the spec is pretty clear, regardless of what some vendor does.

Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

[Warren Parad]

Sachin,

Why does it matter what Curity does here? Is the question about what should
happen according to the specification or whether or not Curity is compliant
with the spec when it comes to refresh tokens?

- Warren

On Tue, Feb 20, 2024 at 8:27 PM Sachin Mamoru 
wrote:

> Hi Neil,
>
> Thanks for the clarification.
> But Curity has a different approach and they implemented it according to
> the concept of narrowing down the refresh token scopes.
>
> "The scope was originally read openid profile and after refresh the
> access was reduced to read profile (i.e., the access_token now only has read
> profile scope and any new tokens obtained using the refresh token
> daa38700-ba96-4ef1-8b30-5cb3527aae19 will have the same, reduced scope).
> Note that *increasing* the scope of access cannot be done in this way
> unless first reduced and increased back to the original scope."
>
> [1]
> https://curity.io/resources/learn/refresh-tokens/#changing-scope-of-access-token-on-refresh
>
> Thanks & Regards,
> Sachin
>
> On Tue, 20 Feb 2024 at 21:59, Neil Madden  wrote:
>
>>
>>
>> On 20 Feb 2024, at 11:02, Sachin Mamoru  wrote:
>>
>> 
>> Hi Neil,
>>
>> Does that mean it should be identical to the narrowed scope request or
>> the original request scope?
>>
>>
>> It says it has to be identical to the scope of the existing refresh token
>> in the request, not the scope specified in the request. So effectively you
>> can never downscope a refresh token in this way. Whatever scope you
>> specify, any RT returned must always retain the original scope.
>>
>> (There are other ways to downscope a RT, eg ForgeRock’s macaroons allow
>> you to attenuate the scope if you wish).
>>
>> — Neil
>>
>>
>> On Tue, 20 Feb 2024 at 16:31, Sachin Mamoru 
>> wrote:
>>
>>>
>>>
>>> On Tue, 20 Feb 2024 at 12:23, Neil Madden 
>>> wrote:
>>>

 On 20 Feb 2024, at 06:44, Sachin Mamoru  wrote:

 
 Hi All,

 When we request an access token using 3 scopes (scope1, scope2, scope3).

 Then will receive a refresh token (refresh_token1) with the access
 token.

 After that will request another access token with refresh_token1 and
 provide the scope list as scope1 and scope2 (Narrow down scopes).

 Similarly, get another refresh token (refresh_token2) with the access
 token.

 Now if we request another access token with refresh_token2, we cannot
 request scope3, instead, we can either request both scope1 and scope2 or
 one of them.

 But in the specification, didn't able to find anything related to
 narrow-down scopes with refresh token.

 From Spec

 1.5.  Refresh Token - Refresh tokens are issued to the client by the
 authorization server and are used to obtain a new access token when
 the current access token becomes invalid or expires or to obtain
 additional access tokens with identical or narrower scope (access
 tokens may have a shorter lifetime and fewer permissions than
 authorized by the resource owner).

 6.  Refreshing an Access Token

 The scope of the access request as described by Section 3.3.  The
 requested scope MUST NOT include any scope not originally granted by
 the resource owner, and if omitted is treated as equal to the scope
 originally granted by the resource owner.

 https://datatracker.ietf.org/doc/html/rfc6749


 IMO, from a security aspect, the current behaviour is much more secure
 because it is designed to maintain the principle of least privilege, where
 it updates the refresh token authorised scopes based on the requested ones.


 What should be the correct behaviour?
 narrow-down scope refresh token should also be able to request access
 token with original scope list?


 Also from section 6:

 If a
new refresh token is issued, the refresh token scope MUST be
identical to that of the refresh token included by the client in the
request.





 — Neil


>>>
>>> --
>>>
>>> Sachin Mamoru
>>> Software Engineer, WSO2
>>> +94771292681
>>> | sachinmamoru.me  
>>> sachinmam...@gmail.com  
>>> 
>>> 
>>>
>>>
>>
>> --
>>
>> Sachin Mamoru
>> Software Engineer, WSO2
>> +94771292681
>> | sachinmamoru.me  
>> sachinmam...@gmail.com  
>> 
>> 
>>
>>
>
> --
>
> Sachin Mamoru
> Software Engineer, WSO2
> +94771292681
> | sachinmamoru.me  
> sachinmam...@gmail.com  
> 
> 
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing 

Re: [OAUTH-WG] [Technical Errata Reported] RFC7591 (7782)

[Warren Parad]

I feel like the source of the confusion might be, *what is the purpose of
the statement in the description of this property. e.g. *Why say anything
at all?

If the description was:
OAuth 2.0 client identifier string.  An
  authorization server MAY issue the same client identifier to
  multiple instances of a registered client at its discretion.

Or even:
OAuth 2.0 client identifier string.

What was the purpose of this statement in the first place. For context
3.2.1. is the *Client Information Response*

OAuth 2.0 client identifier string.  An authorization server MAY issue the
> same client identifier to multiple instances of a registered client at its
> discretion.

This version is great because it is consistent with the information
provided elsewhere in the RFC regarding instances, and reusing the
client_id, if the AS desires.

But this part: *It SHOULD NOT be currently valid for any other registered
client*, seems like it just exists to create confusion. Was there an actual
concern that this statement was created to help implementations avoid?

On Fri, Jan 26, 2024 at 10:15 PM Tom Jones 
wrote:

> The whole thing is pointless as the client owner (as opposed to the
> subject for which client status is requested) can just define the instances
> to be the same. There can be no way to attest to the validity of such an
> assertion.
>
> thx ..Tom (mobile)
>
> On Fri, Jan 26, 2024, 10:42 AM Justin Richer  wrote:
>
>> I believe this correction is valid, though I think that the changing of a
>> normative requirement is beyond an erratum.
>>
>> Ultimately, though, this comes down to the definition of what "a client"
>> is, which is pretty fuzzy in OAuth. The AS needs to be able to issue the
>> same identifier to what it feels is an instance of the same client
>> software, if it wants to do that. You can think of these instances as
>> different clients in a way, which is what the ’SHOULD NOT’ was for.
>> However, if you contend that these instances are "the same client" then the
>> 'MUST NOT' makes sense.
>>
>> In the end, I’m not sure how much difference this change would actually
>> make for implementations, because of the fuzziness around the definitions.
>> I’m hopeful that some of the new language in OAuth 2.1 around client types
>> and instances and registration will help settle this and we can call things
>> something consistent.
>>
>> As such, I’m on the fence whether we should accept or reject the erratum
>> —
>>
>>  - if we accept, that’s a normative change, but not likely to affect
>> other implementations (especially those that implement the OIDC version
>> already)
>>  - if we reject, we obviously don’t change implementations but we also
>> keep carrying this ambiguity forward
>>
>>  — Justin
>>
>> > On Jan 25, 2024, at 1:25 AM, RFC Errata System <
>> rfc-edi...@rfc-editor.org> wrote:
>> >
>> > The following errata report has been submitted for RFC7591,
>> > "OAuth 2.0 Dynamic Client Registration Protocol".
>> >
>> > --
>> > You may review the report below and at:
>> > https://www.rfc-editor.org/errata/eid7782
>> >
>> > --
>> > Type: Technical
>> > Reported by: Tim Würtele 
>> >
>> > Section: 3.2.1
>> >
>> > Original Text
>> > -
>> > client_id
>> >  REQUIRED.  OAuth 2.0 client identifier string.  It SHOULD NOT be
>> >  currently valid for any other registered client, though an
>> >  authorization server MAY issue the same client identifier to
>> >  multiple instances of a registered client at its discretion.
>> >
>> > Corrected Text
>> > --
>> > client_id
>> >  REQUIRED.  OAuth 2.0 client identifier string.  It MUST NOT be
>> >  currently valid for any other registered client, though an
>> >  authorization server MAY issue the same client identifier to
>> >  multiple instances of a registered client at its discretion.
>> >
>> > Notes
>> > -
>> > Allowing the same client_id for multiple clients is a contradiction to:
>> >
>> > 1. This document, Section 1.3, (D), 2nd bullet point: "a client
>> identifier that is unique at the server"
>> >
>> > 2. This document, Section 3.1: "The authorization server assigns this
>> client a unique client identifier"
>> >
>> > 3. (normative reference) RFC 6749, Section 2.2: "The authorization
>> server issues the registered client a client identifier -- a unique string
>> representing the registration information provided by the client. [...] The
>> client identifier is unique to the authorization server."
>> >
>> > 4. (non-normative reference) OpenID Connect Dynamic Client Registration
>> 1.0 incorporating errata set 2, Section 2: "Clients have metadata
>> associated with their unique Client Identifier at the Authorization
>> Server."; Section 3.1: "The Authorization Server assigns this Client a
>> unique Client Identifier"; Section 3.2: "client_id REQUIRED. Unique Client
>> Identifier. It MUST NOT be currently valid for any other 

Re: [OAUTH-WG] OAuth WG Slack Channel

[Warren Parad]

Thanks!

On Thu, Dec 7, 2023 at 10:09 PM Rifaat Shekh-Yusef 
wrote:

> Warren,
>
> Try the following link:
>
> https://join.slack.com/t/ietf/shared_invite/zt-28l39r2bo-GnzrcjNGiXdZDJhVEQfwkQ
>
> The link will expire in 30 days.
>
> Regards,
>  Rifaat
>
>
> On Thu, Dec 7, 2023 at 3:27 PM Warren Parad  wrote:
>
>> Hmmm, it doesn't seem to work by email. At least not for me.
>>
>> Is this the official process:
>> https://www.spinics.net/lists/ietf/msg101574.html
>>
>> On Thu, Dec 7, 2023 at 8:58 PM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> I think all you need is a datatracker account.
>>>
>>> Regards,
>>>  Rifaat
>>>
>>>
>>> On Thu, Dec 7, 2023 at 1:16 PM Warren Parad  wrote:
>>>
>>>> I didn't know there was a Slack Workspace for this. How does one get an
>>>> invite to the workspace?
>>>>
>>>> On Thu, Dec 7, 2023 at 7:04 PM Rifaat Shekh-Yusef <
>>>> rifaat.s.i...@gmail.com> wrote:
>>>>
>>>>> All,
>>>>>
>>>>> We now have an OAuth channel (#oauth) at the IETF Slack service.
>>>>> ietf.slack.com
>>>>>
>>>>> Feel free to join the channel if you use Slack.
>>>>>
>>>>> Regards,
>>>>>  Rifaat & Hannes
>>>>>
>>>>> ___
>>>>> 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

Re: [OAUTH-WG] OAuth WG Slack Channel

[Warren Parad]

Hmmm, it doesn't seem to work by email. At least not for me.

Is this the official process:
https://www.spinics.net/lists/ietf/msg101574.html

On Thu, Dec 7, 2023 at 8:58 PM Rifaat Shekh-Yusef 
wrote:

> I think all you need is a datatracker account.
>
> Regards,
>  Rifaat
>
>
> On Thu, Dec 7, 2023 at 1:16 PM Warren Parad  wrote:
>
>> I didn't know there was a Slack Workspace for this. How does one get an
>> invite to the workspace?
>>
>> On Thu, Dec 7, 2023 at 7:04 PM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> All,
>>>
>>> We now have an OAuth channel (#oauth) at the IETF Slack service.
>>> ietf.slack.com
>>>
>>> Feel free to join the channel if you use Slack.
>>>
>>> Regards,
>>>  Rifaat & Hannes
>>>
>>> ___
>>> 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

Re: [OAUTH-WG] OAuth WG Slack Channel

[Warren Parad]

I didn't know there was a Slack Workspace for this. How does one get an
invite to the workspace?

On Thu, Dec 7, 2023 at 7:04 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> We now have an OAuth channel (#oauth) at the IETF Slack service.
> ietf.slack.com
>
> Feel free to join the channel if you use Slack.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> 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

Re: [OAUTH-WG] [Technical Errata Reported] RFC7519 (7720)

[Warren Parad]

It goes both ways for me. I hate the fact that eventually there would need
to be an exhaustive list of all the things you shouldn't be doing. But I
also understand the value in BCPs and direct guidance on footguns and pits
of failure. I can totally imagine there is a story behind this errata,
which stemmed from an implementation that actually was doing this and
causing a problem, or an arbitrary package that wants to avoid adding
functionality that explicitly goes against the spec.

It's a timestamp, because it is a timestamp, people are tempted to do
something with it when they should not. I like the errata.

I would have preferred it to say something more to the effect of:

> This claim has no additional semantic meaning, and must not be used in the
> verification or rejection of JWTs. JWTs with an "iat" claim in the future
> have to impact on their validity.


But in spirit, I accept the errata.

On Tue, Dec 5, 2023 at 11:55 PM Brian Campbell  wrote:

> I agree that the change in text is too much for an errata. But I am
> sympathetic to the problem that the reporter has described. Perhaps it'd be
> appropriate as an errata that, in the interest of interoperability,
> mentions/reminds that 'iat' doesn't have defined semantics about rejection
> and suggests (non-normatively) not to implement/enforce any (in the absence
> of an application specific profile anyway)?
>
> On Sun, Dec 3, 2023 at 4:43 AM Justin Richer  wrote:
>
>> This errata should be rejected, as stated in the write up, the change in
>> text is too much for an errata. If the WG wants to revise JWT at this level
>> it should be a full bis document.
>>
>> It's worth noting that the two other time based claims, nbf and exp,
>> allow for clock skew in processing, but both of these claims have defined
>> semantics about rejection whereas iat does not. One could argue that the
>> libraries mentioned in the issue are doing things the spec doesn't say to
>> do, but this kind of processing is extremely common.
>>
>> - Justin
>>
>> --
>> *From:* OAuth  on behalf of RFC Errata System <
>> rfc-edi...@rfc-editor.org>
>> *Sent:* Friday, December 1, 2023 5:06 PM
>> *To:* m...@microsoft.com ; ve7...@ve7jtb.com <
>> ve7...@ve7jtb.com>; n-sakim...@nri.co.jp ;
>> r...@cert.org ; paul.wout...@aiven.io ;
>> hannes.tschofe...@arm.com ;
>> rifaat.s.i...@gmail.com 
>> *Cc:* verge...@gmail.com ; oauth@ietf.org <
>> oauth@ietf.org>; rfc-edi...@rfc-editor.org 
>> *Subject:* [OAUTH-WG] [Technical Errata Reported] RFC7519 (7720)
>>
>> The following errata report has been submitted for RFC7519,
>> "JSON Web Token (JWT)".
>>
>> --
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid7720
>>
>> --
>> Type: Technical
>> Reported by: Timothy Vergenz 
>>
>> Section: 4.1.6
>>
>> Original Text
>> -
>> 4.1.6.  "iat" (Issued At) Claim
>>
>> The "iat" (issued at) claim identifies the time at which the JWT was
>> issued.  This claim can be used to determine the age of the JWT.  Its
>> value MUST be a number containing a NumericDate value.  Use of this
>> claim is OPTIONAL.
>>
>> Corrected Text
>> --
>> 4.1.6.  "iat" (Issued At) Claim
>>
>> The "iat" (issued at) claim identifies the time at which the JWT was
>> issued.  This claim can be used to determine the age of the JWT.  Its
>> value MUST be a number containing a NumericDate value.  Use of this
>> claim is OPTIONAL. Implementors MUST NOT reject otherwise-valid JWTs
>> with "iat" claims that appear to be from the future; token issuers
>> desiring this behavior may require it by including an "nbf" claim.
>>
>> Notes
>> -
>> There is substantial confusion and disagreement among JWT library
>> implementors about whether to reject JWTs with `iat` claims that appear to
>> be from the future due to clock drift. This confusion has led to over half
>> a dozen Github issues & PRs over the years in libraries in many different
>> ecosystems, and lots of strong disagreement among library developers and
>> users.
>>
>> Based on a sample of the top Google search results for jwt client
>> libraries in 11 different language ecosystems, the majority (7) of the
>> libraries sampled do not reject future `iat` claims, while the remaining 4
>> *do* reject future `iat` claims by default. Of those 4 who do, *all* of
>> them have had Github issues filed (by different unique users) in which the
>> user was having a JWT unexpectedly rejected by a token validator using the
>> library whose clock had drifted from that of the token issuer enough to
>> trigger `iat`-based rejection.
>>
>> I propose we update the spec to explicitly prohibit rejection of
>> future-`iat` JWTs (especially since token issuers have always been able to
>> opt into this behavior using an `nbf` claim). Since this RFC has been
>> published and cannot be edited, a new superseding RFC will have to be
>> published and this one 

Re: [OAUTH-WG] A Discussion of Multiple Suffixes

[Warren Parad]



On Fri, Nov 17, 2023, 14:47 David Waite  wrote:

> wMy concern is higher level, that we may be promoting over-expression of
> types.
>
> My interpretation of historical decisions/retconning was that +xml made
> sense because XML documents form an object model that can be processable
> independently of the document.
>
> For the example of SVG data in an XHTML document, without a media type you
> could still understand that the document contained XHTML because of the
> namespaced root element. You could also understand the SVG data even
> without knowledge of XHTML. There is both an expectation that
> application/xml could be interpreted as XHTML by supporting tools, and that
> there was value in generic XML processing even without understanding the
> media type.
>
> Data expressed in the multiple RDF formats are similar to the XML case
> above - for a graph or subgraph, there are defined predicate relationships
> that could be understood outside the given context. An example would be W3C
> verifiable credentials - I can subject relationships in a credential
> without understanding what a verifiable credential is, because existing
> types and predicates may be in use.
>
> For JSON on the other hand, there is no expectation of universal
> consistency - there are only heuristics to attempt to interpret the data
> outside of context.
>
> We use suffixes for a second purpose - to group related media types
> together when they ‘only’ differ by format, e.g. application/calendar+xml
> and application/calendar+json
>
> For multiple suffixes, I might make a case that something like +rdf+xml
> provides value in that even without knowledge of RDF processing, RDF XML is
> still namespaced and there is the possibility of interpreting the contents
> of the document via XML tooling.
>
> I’m not sure +ld+json provides the same value, as there is no name spacing
> or other application/json rule that would provide an interpretation of the
> media as a generic type. The processor of that media would need still need
> context in order to process the data, and if they have the domain knowledge
> necessary to have that context they could just deal with the fully
> expressed media type.
>
> -DW
>
> On Nov 17, 2023, at 11:03 AM, Orie Steele 
> wrote:
>
> Alexey Melnikov and I had a chat about
> https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes
>
> I am sharing a summary of our discussion for the benefit of the list,
> obviously this was just a discussion, and the media types working group
> will need to decide if or how to address any of these topics.
>
> Regarding media type parameters, there should be no automatic inheritance.
>
> There can be parameters that come from the top level, the subtype, the
> first structured suffix, or the last structured suffix.
>
> An interesting parameter to consider would be "profile" which is common.
>
> There should be commentary on media type parameters, especially
> regarding cases where:
>
> application/ld+json and application/json might both have chosen to
> register a common parameter name, such as "charset" or "profile".
>
> +ld+json seems to be fine.
>
> +jwt is confusing, since it's ambiguous which part, the header, payload,
> or signature will be passed along.
>
> The validation rules here, are also problematic, in that they don't
> directly address this case:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-mediaman-suffixes-06#section-2.5.1
>
> We think the ambiguity here could be resolved, for JWT or CWT, the payload
> is the natural part that is relevant, and this aligns with the current
> intended use case within W3C.
>
> For example, W3C specs current request registration of:
>
> typ: application/vc+ld+json+sd-jwt
> cty: application/vc+ld+json
>
> Where decoding the payload produces application/vc+ld+json.
>
> We should comment on this explicitly and warn implementers planning to use
> multiple suffixes with:
>
> +jwt
> +cwt
> +sd-jwt
> +jose
> +cose
>
>  ... or future similar structured suffixes...
>
> To do their best to conform to this behavior, or explain why they deviated
> clearly, in their registration request.
>
> An alternative recommendation might be to flatten the suffixes, when
> pairing with envelope content types, for example:
>
> application/vc-ld-json+sd-jwt
>
> This would also reduce unnecessary registrations, and simplify the
> guidance to designated experts regarding subtypes
> with multiple structured suffixes that are each envelope formats (for
> example, +cwt  / +jwt)
>
> When flattening is not an option, we recommend registering all suffixes,
> to ensure consistency, safety checks, and to be explicit over implicit.
>
> For application/vc+ld+json+jwt and application/vc+ld+json+sd-jwt this
> would mean registering:
>
> for application/vc:
>
> - +ld
>
> - +ld+json
>
> - +ld+json+jwt
> - +json+jwt
>
> - +ld+json+sd-jwt
> - +json+sd-jwt
>
> Some of these registrations could be made with a warning, saying, do not
> use at this time.
>
> On the 

Re: [OAUTH-WG] [External Sender] Re: Questions on OAuth Protected Resource Metadata

[Warren Parad]

>
> the resulting consent dialog from Google is going to say "Apple is
> requesting super admin privileges to your Apple account".


And that's totally fine (also assuming you meant *to your google account*.
But the second provider MUST also have a prompt to the delegation of those
resources. That would be a prompt specifically connecting MyCrazyLottery to
Apple

For example:

MyCrazyLottery is requesting super admin privileges to your Apple account
which will give it access to all accounts and data delegated to Apple. For
instance if you have granted Apple access to your Google account, this
consent will give MyCrazyLottery access to your Google account.

If it isn't doing that, then this is just an incorrect or at least very lax
and poorly implemented consent flow for the app.

On Wed, Sep 27, 2023 at 9:37 PM David Waite  wrote:

>
>
> > On Sep 27, 2023, at 1:18 PM, Atul Tulshibagwale  wrote:
>
> 
>
> > Now if MyCrazyLottery's OPRM says it needs "super admin privileges to
> your Apple account", the resulting consent dialog from Google is going to
> say "Apple is requesting super admin privileges to your Apple account".
> This looks safe enough to the user, and now MyCrazyLottery has way too much
> privilege. Since the MyCrazyLottery app probably launched Safari in order
> to get authorized, the user may not even realize it's something to do with
> the "MyCrazyLottery" app that is open on their device. What's worse, any
> onboarding time checks (e.g. AppStore policies) won't detect this abuse,
> since MyCrazyLottery can change the OPRM at any time.
>
> I thought the guidance in this sort of dynamic case from the security
> topics BCP and OAuth 2.1 should be to sender-constrain and/or
> resource-constrain the access token, such that MyCrazyLottery is forced to
> be a protected resource - and cannot operate as a client to other protected
> resources.
>
> Resource constraints (such as requiring resource indicators) allow the AS
> to also institute their own protections, such as not allowing access tokens
> issued for MyCrazyLottery in the first place, or only allowing them with a
> subset of scopes.
>
> I would agree that dynamism without any sender/resource constraints is a
> bad idea.
>
> -DW
>
> ___
> 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

Re: [OAUTH-WG] Questions on OAuth Protected Resource Metadata

[Warren Parad]

For (1) arguably these are different resources, therefore, they of course
have different paths. The draft specifically outlines that each of them can
have their own metadata document:

https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-00.html#name-protected-resource-metadata-

If the resource identifier value contains a path component, any terminating
/ MUST be removed before appending /.well-known/ and the well-known URI
path suffix. The consumer of the metadata would make the following request
when the resource identifier is https://resource.example.com/resource1 and
the well-known URI path suffix is oauth-protected-resource to obtain the
metadata, since the resource identifier contains a path component:


  GET /resource1/.well-known/oauth-protected-resource HTTP/1.1
  Host: resource.example.com



Using path components enables supporting multiple resources per host. This
is required in some multi-tenant hosting configurations. This use of
.well-known is for supporting multiple resources per host; unlike its use
in [RFC5785

], it does not provide general information about the host.

For (2), this is already the case with OAuth, and has nothing to do with
this draft. The solution here is for resource servers to check the
*audience* claim in the incoming token if it is a JWT. If for some reason
they can't do that or it isn't a JWT, then DPoP exists to constrain
requests to prove that the client should be allowed to utilize that token.


On Thu, Sep 21, 2023 at 6:19 PM Atul Tulshibagwale  wrote:

> Hi all,
> I'm still looking for answers to these two questions
> 
> regarding the OPRM draft that was recently adopted by the WG:
>
>1. If I have a resource server that has multiple endpoints, each of
>which require different scopes, how should those be handled? For example,
>in the SSF spec, the SSF Transmitter has a Create Stream endpoint and a
>Polling endpoint. The scopes required for these are different. How would
>the client know which scope is to be used with which endpoint?
>2. Does the spec encourage insecure behavior in the caller by
>requesting tokens with scopes that they do not understand? I.e. If an
>authorization server is known to provide valuable tokens with certain
>scopes, can a malicious resource server trick the client into requesting a
>more powerful token, which it then uses to access some other service? Since
>the consent dialog is likely to show two trusted names (i.e. the requesting
>client and the authorization server), the user would be prone to providing
>consent, even if the scope looks unnecessarily permissive.
>
> Thanks,
> Atul
> ___
> 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

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7642)

[Warren Parad]

They are meant to be appositives, (not trying to be condescending, if you
are unfamiliar with the english grammar term), except instead of inlined
with commas, they use parentheses. Grammatically, the paragraph could have
been rewritten as

For example, an end-user, resource owner, can grant a printing
   service, client, access to her protected photos stored at a photo-
   sharing service, resource server, without sharing her username and
   password with the printing service. Instead, she authenticates
   directly with a server trusted by the photo-sharing service,
authorization
   server, which issues the printing service delegation-
   specific credentials, access token.

If it was written that way instead, would it have been clearer? Personally
I don't think it would be, but maybe I'm in the minority. *resource
server* follows
*photo-sharing service*, because *resource server* is the oauth 2
concept *resource
server* entity that is being exemplified by the concrete scenario
represented by the *photo-sharing service*. The photo-sharing service in
this example is* the resource service, *from an OAuth perspective. Just
like the server that the photo-sharing service trusts, is called *an
authorization server*. The example exists to explain using a real world
scenario these core entities in the OAuth paradigm.

On Sun, Sep 17, 2023 at 1:24 PM  wrote:

> I'm especially confused by why 'photo-sharing service' is followed by
> '(resource server)' in parentheses the first time and '(authorization
> server)' in parentheses the second time.
>
>
>
>
>
> --
>
> Wilhelm
>
>
>
> *Von:* Warren Parad 
> *Gesendet:* 17 September 2023 12:51
> *An:* Aaron Parecki 
> *Cc:* RFC Errata System ; w.fas...@gmail.com;
> oauth@ietf.org
> *Betreff:* Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7642)
>
>
>
> It does look confusing if we only look at that one sentence, but as soon
> as you pull in the whole paragraph, it seems pretty clear
>
>
>
> https://www.rfc-editor.org/rfc/rfc6749
>
> For example, an end-user (resource owner) can grant a printing
>service (client) access to her protected photos stored at a photo-
>sharing service (resource server), without sharing her username and
>password with the printing service.  Instead, she authenticates
>directly with a server trusted by the photo-sharing service
>(authorization server), which issues the printing service delegation-
>specific credentials (access token).
>
>
>
> Arguably the only improvement here would be to outline the full case, by
> adding something like:
>
> The printing service (client) uses the credentials (access token) to
> access the photo-sharing service (resource server), by sending the
> credentials to the server. When receiving the credentials (access token),
> the photo-sharing service (resource server) verifies the credentials using
> the trusted server (authorization server).
>
>
>
> But I think that's wholly unnecessary, since everything has been defined
> in this case. You can't mistake the resource server for the authorization
> server, because the resource server has already been defined to be the 
> *photo-sharing
> service.* That means the *(authorization server)* identification
> appositive can only apply to the trusted server. The errata breaks the
> pattern of the paragraph and introduces confusion because it fails to
> define the terms authorization server and access token, which arguably is
> the whole point of the example.
>
>
>
> On Sun, Sep 17, 2023 at 12:35 PM Aaron Parecki  40parecki@dmarc.ietf.org> wrote:
>
> I disagree with this errata. The original text is correctly representing
> that the "photo-sharing service" trusts the authorization server. The
> suggested text is ambiguous because it does not make clear which party is
> trusting which other party.
>
>
>
> Aaron
>
>
>
> On Sun, Sep 17, 2023 at 11:00 AM RFC Errata System <
> rfc-edi...@rfc-editor.org> wrote:
>
> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7642
>
> --
> Type: Editorial
> Reported by: Wilhelm Fast 
>
> Section: 1
>
> Original Text
> -
>  Instead, she authenticates directly with a server trusted by the
> photo-sharing service (authorization server), which issues the printing
> service delegation-
> specific credentials (access token).
>
> Corrected Text
> --
> Instead, she directly authenticates with a trusted server, the
> authorization server, which issues dele

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7642)

[Warren Parad]

It does look confusing if we only look at that one sentence, but as soon as
you pull in the whole paragraph, it seems pretty clear

https://www.rfc-editor.org/rfc/rfc6749

> For example, an end-user (resource owner) can grant a printing
>service (client) access to her protected photos stored at a photo-
>sharing service (resource server), without sharing her username and
>password with the printing service.  Instead, she authenticates
>directly with a server trusted by the photo-sharing service
>(authorization server), which issues the printing service delegation-
>specific credentials (access token).


Arguably the only improvement here would be to outline the full case, by
adding something like:

> The printing service (client) uses the credentials (access token) to
> access the photo-sharing service (resource server), by sending the
> credentials to the server. When receiving the credentials (access token),
> the photo-sharing service (resource server) verifies the credentials using
> the trusted server (authorization server).


But I think that's wholly unnecessary, since everything has been defined in
this case. You can't mistake the resource server for the authorization
server, because the resource server has already been defined to be the
*photo-sharing
service.* That means the *(authorization server)* identification appositive
can only apply to the trusted server. The errata breaks the pattern of the
paragraph and introduces confusion because it fails to define the terms
authorization server and access token, which arguably is the whole point of
the example.

On Sun, Sep 17, 2023 at 12:35 PM Aaron Parecki  wrote:

> I disagree with this errata. The original text is correctly representing
> that the "photo-sharing service" trusts the authorization server. The
> suggested text is ambiguous because it does not make clear which party is
> trusting which other party.
>
> Aaron
>
> On Sun, Sep 17, 2023 at 11:00 AM RFC Errata System <
> rfc-edi...@rfc-editor.org> wrote:
>
>> The following errata report has been submitted for RFC6749,
>> "The OAuth 2.0 Authorization Framework".
>>
>> --
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid7642
>>
>> --
>> Type: Editorial
>> Reported by: Wilhelm Fast 
>>
>> Section: 1
>>
>> Original Text
>> -
>>  Instead, she authenticates directly with a server trusted by the
>> photo-sharing service (authorization server), which issues the printing
>> service delegation-
>> specific credentials (access token).
>>
>> Corrected Text
>> --
>> Instead, she directly authenticates with a trusted server, the
>> authorization server, which issues delegation-specific credentials, known
>> as access tokens, to the printing service for controlled and secure access.
>>
>> Notes
>> -
>> The sentence is confusing, and the reader might confuse the Authorization
>> Server with the Resource Server.
>>
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>>
>> --
>> RFC6749 (draft-ietf-oauth-v2-31)
>> --
>> Title   : The OAuth 2.0 Authorization Framework
>> Publication Date: October 2012
>> Author(s)   : D. Hardt, Ed.
>> Category: PROPOSED STANDARD
>> Source  : Web Authorization Protocol
>> Area: Security
>> Stream  : IETF
>> Verifying Party : IESG
>>
>> ___
>> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Technical Errata Reported] RFC7662 (7607)

[Warren Parad]

Arguably the client can't revoke the token. It can request to revoke the
token and then the decision of whether it is revoked is only on the AS. A
client considering a token revoked has no merit on the value of the *active
*flag.

For full context, this is the section:
https://datatracker.ietf.org/doc/html/rfc7662#section-2.2

And the relevant text:

   The server responds with a JSON object [RFC7159
] in "application/
   json" format with the following top-level members.

   active
  REQUIRED.  Boolean indicator of whether or not the presented token
  is currently active.  The specifics of a token's "active" state
  will vary depending on the implementation of the authorization
  server and the information it keeps about its tokens, but a "true"
  value return for the "active" property will generally indicate
  that *a given token has been issued by this authorization server,
  has not been revoked by the resource owner, and is within its
  given time window of validity* (e.g., after its issuance time and
  before its expiration time).  See Section 4
 for
information on
  implementation of such checks.


On Mon, Aug 21, 2023 at 12:31 PM Justin Richer  wrote:

> I don’t think it’s necessary to enumerate all of the possible parties that
> could have had a hand in revoking the token — it have also been revoked by
> the AS through some backend process or through administrative action. If a
> token is revoked, it’s revoked — and the RS doesn’t generally care why or
> who did it, just that the token is no good. It doesn’t hurt to list the
> client here, but it’s not necessary. As such, I still say the errata should
> be rejected.
>
>  — Justin
>
> On Aug 19, 2023, at 6:32 PM, Fulong Sun  wrote:
>
> Hi Justin,
>
> Yes, the resource owner can revoke, but the client also can revoke the
> token, why do not write both of them?
>
> 孙福龙
> Fulong Sun
>
> 东软教育科技集团・IDC
> IDC of Neusoft Education Technology Group
>
> Office: +86 (411) 82379410 -9 / 6602
> Mobile: +86 13478953390
> E-mail: sunful...@neusoft.edu.cn
> Address: Room 305, Building A5, No. 8, Software Park Road, Dalian,
> Liaoning, China
>
> *From:* Justin Richer 
> *Sent:* 2023年8月18日 20:54
> *To:* RFC Errata System ;
> i...@justin.richer.org; r...@cert.org; paul.wout...@aiven.io;
> hannes.tschofe...@arm.com; rifaat.s.i...@gmail.com
> *Cc:* sunful...@neusoft.edu.cn; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] [Technical Errata Reported] RFC7662 (7607)
>
> The resource owner can revoke the token out of band, this errata should be
> rejected.
>
> - Justin
> --
> *From:* OAuth  on behalf of RFC Errata System <
> rfc-edi...@rfc-editor.org>
> *Sent:* Thursday, August 17, 2023 2:42 PM
> *To:* i...@justin.richer.org ; r...@cert.org <
> r...@cert.org>; paul.wout...@aiven.io;
> hannes.tschofe...@arm.com ;
> rifaat.s.i...@gmail.com
> *Cc:* sunful...@neusoft.edu.cn ; oauth@ietf.org
> ; rfc-edi...@rfc-editor.org
> *Subject:* [OAUTH-WG] [Technical Errata Reported] RFC7662 (7607)
>
> The following errata report has been submitted for RFC7662,
> "OAuth 2.0 Token Introspection".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7607
>
> --
> Type: Technical
> Reported by: Fulong Sun 
>
> Section: 2.2
>
> Original Text
> -
> a given token has been issued by this authorization server, has not been
> revoked by the resource owner, and is within its given time window of
> validity
>
> Corrected Text
> --
> a given token has been issued by this authorization server, has not been
> revoked by the resource owner or client, and is within its given time
> window of validity
>
> Notes
> -
> RFC 7009 defined a given token can be revoke by client, so should write
> client here.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC7662 (draft-ietf-oauth-introspection-11)
> --
> Title   : OAuth 2.0 Token Introspection
> Publication Date: October 2015
> Author(s)   : J. Richer, Ed.
> Category: PROPOSED STANDARD
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> 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
>

Re: [OAUTH-WG] OAuth Trust model

[Warren Parad]

Let me try that differently, I posit that it might be impossible to secure
this in a way that would prevent a different Relying Party from
impersonating the user if we only use details *about* the user. However, we
do know that using FIDO2 the user can secure communication with the AS, in
a way that prevents impersonation.

With that, would it make sense for us to standardize the communication with
the AS in a way that operationalizes FIDO2?

On Tue, Aug 15, 2023 at 8:28 PM Rodrigo Speller  wrote:

> It could be an internal implementation like any part of OAuth could be,
> but from the OAuth perspective, the intent was to create a new Grant Type,
> that is not mandatory, but part of the framework. So, this Grant Type
> standardizes the generic flow to the AS to obtain the authorization
> evidence token from the user and transmit it to the client application.
> Probably, the documentation will specify a new grant_type, query parameters
> and token response properties.
>
> And, a standard helps to concern a mature and interoperable approach to
> resolve this problem.
>
> I believe that the final document will be a Grant Type specification, but
> a BCP may be used to define practices to operate the keys on some cenarios,
> like browsers, native apps, soon.
>
> I predict some possibilities about the user providing some encrypted
> personal data embedded on the authorization evidence token directly to the
> client too. But it is out of scope for now.
>
> I don't have this ready. I'm only answering this group about this
> possibility, but I can work with the group about this.
>
>
> Em ter., 15 de ago. de 2023 às 14:59, Warren Parad  40rhosys...@dmarc.ietf.org> escreveu:
>
>> I think the problem here for me is that lack of clarity of how this
>> problem could be better constrained at the protocol level. As far as I can
>> see, albeit naively, the problem is purely an internal implementation
>> detail. Is that not the case? Is there really something missing in the
>> grants that would encourage AS to do the right thing? If so, can you share,
>> because I'm not seeing it.
>>
>> That being said, even if it is an implementation detail, that doesn't
>> mean there couldn't be some sort of BCP.
>>
>> On Tue, Aug 15, 2023 at 7:42 PM Rodrigo Speller > 40primosti.com...@dmarc.ietf.org> wrote:
>>
>>> I read all the comments carefully while flying through Brazil, and I
>>> confess that my reasoning from the beginning tended to say that the OAuth
>>> trust model is “as is” and that the main point of the trust relationship is
>>> between the AS and the RO (in this case, a user).
>>>
>>> At various times, while reading, I agreed that Matthias' question was
>>> about a problem that would not fit directly into the OAuth Framework, as I
>>> understood that the central point in question was authentication and not
>>> authorization. But I refused to accept that my point of view would be
>>> correct due to the avalanche of exposed reasoning that contributed to my
>>> understanding and that even so, Matthias insisted on making himself
>>> understood by different approaches, leading to believe that he understood
>>> the answers, but still did not was convinced that we had understood this
>>> problem in essence.
>>>
>>> So, during the flight, I reflected on Matthias' insistence: "What could
>>> we be missing?" Brilliantly, I think Matthias raised a very important and
>>> fixable point: “That the user MUST allow the connection on both sides on
>>> the client and on the provider.”
>>>
>>> As is known here, OAuth 2.0 is not a ready-to-use protocol, but a
>>> framework that is constantly evolving, it is specified by multiple RFCs and
>>> its main implementation is the OpenID Connect 1.0 layer, which is also
>>> under development. I say this because I believe the solution to this point
>>> raised by Matthias would result in a Zero-Trust Authorization Grant with
>>> great value to the protocol, as it would reinforce user authorization so
>>> that the AS could authorize client applications.
>>>
>>> In this grant type, the AS would ask the user to sign evidence tokens to
>>> authorize client application access in the authentication/consent phase. Of
>>> course, this flow would require some restrictions to maintain a high degree
>>> of security, such as: Generation and storage of user signature keys; Form
>>> of registration of the signature verification key with the AS; Transport of
>>> authorization evidence to the client application; Transporting the evidence
>>> t

Re: [OAUTH-WG] OAuth Trust model

[Warren Parad]

that into your analogy, anyone the school deems authorized to pick
>> up the kid is authorized to pick up the kid. If you don't like how the
>> school decides that, don't send your kid to that school, or work to change
>> the school's policy.
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Aug 10, 2023 at 4:41 PM Matthias Fulz  wrote:
>>
>> I'm running out of ideas to get the point explained...
>>
>> Ok let's try it from an abstract view:
>>
>> Think about a school where your kid is allowed to get picked up by a
>> legitimated list of persons -> ok
>>
>> Now think about the school saying I'm trusting a third party about
>> identifying any person on that list, without asking the person about that
>> this third party is allowed to identify this person.
>>
>> The problem is, that by design the person who's identity is to be
>> verified has no control about what AS is allowed by the site to verify the
>> identity.
>>
>>
>>
>> Sorry for that stupid example but I'm really not able to explain the
>> issue in another way anymore :(
>>
>> On 8/11/23 00:02, Dick Hardt wrote:
>>
>> This sentence does not make sense to me "which AS is AUTHORIZED at which
>> RS acting as the user"
>>
>>
>>
>> The RS server has delegated authorization decisions to the AS
>>
>>
>>
>> The client is acting as the user
>>
>>
>>
>> On Thu, Aug 10, 2023 at 2:59 PM Matthias Fulz  wrote:
>>
>> I can follow your point but please try to think from a different
>> perspective:
>>
>> As authorization protocol, how can it not let the user decide which AS is
>> AUTHORIZED at which RS acting as the user?
>>
>>
>>
>> On 8/10/23 23:28, Dick Hardt wrote:
>>
>> "auth providers" is an extremely confusing term.
>>
>>
>>
>> OAuth has no involvement in the content an RS provides the client -- the
>> AS only provides authorization to access the content at the RS.
>>
>>
>>
>> It is common that the AS and RS are the same entity, but the protocol is
>> designed to have a separation of concerns so that they are acting
>> independently.
>>
>>
>>
>> From what I can understand in your discussion, you are wanting OAuth to
>> do something it is not designed for.
>>
>>
>>
>>
>>
>> On Thu, Aug 10, 2023 at 2:03 PM Matthias Fulz  wrote:
>>
>>
>>
>> On 8/10/23 10:25, Warren Parad wrote:
>>
>> You've lost me at this:
>>
>>
>>
>> Some site, which I'm registered in is trusting some oauth provider I'm
>> not even knowing about. I'm not registered at this provider. If this
>> provider is (independent how or from whom) is used in a malicious way, they
>> can access my account, without my knowledge by sending a valid token
>> including my email.
>>
>>
>>
>> Nothing stops a site you are using, registered with your email address,
>> from just selling your data to a third party, or blanket publishing it
>> publicly. There is nothing we can do to stop this unless the data we care
>> about is encrypted on the client side. OAuth doesn't really have anything
>> to do with it.
>>
>> Yes but that's the point: The site itself has to do it. If they are not
>> willing to it's ok.
>>
>> But: With the actual concept using auth providers, even if the the site
>> is NOT willing to sell it, my account could be accessed by using the
>> trusted auth provider without the site itself needs to do anything. And the
>> problem is, that such sites wouldn't be technically forced to use such auth
>> providers by active permission granting from user side.
>>
>> That's the difference I'm trying to point at.
>>
>> Sorry I'm really struggling to explain it in another way (will think
>> about).
>>
>>
>>
>> Because it has nothing to do with OAuth, the suggested solution of course
>> must have a hole with it. And indeed it does. What if the site offers the
>> token strategy, but then decides to outsource the whole authentication
>> process to a different third party? We are back at the same problem again.
>> However it sounds like what you are saying is that there should be a
>> standardized mechanism for handling the site <=> user token verification.
>> If we use OAuth terminology that would be: We should allow *step-up
>> authentication* to occur solely between the *resource server (RS)* and
>> the *user agent* without involving the *aut

Re: [OAUTH-WG] OAuth Trust model

[Warren Parad]

You've lost me at this:

Some site, which I'm registered in is trusting some oauth provider I'm not
> even knowing about. I'm not registered at this provider. If this provider
> is (independent how or from whom) is used in a malicious way, they can
> access my account, without my knowledge by sending a valid token including
> my email.


Nothing stops a site you are using, registered with your email address,
from just selling your data to a third party, or blanket publishing it
publicly. There is nothing we can do to stop this unless the data we care
about is encrypted on the client side. OAuth doesn't really have anything
to do with it.

Because it has nothing to do with OAuth, the suggested solution of course
must have a hole with it. And indeed it does. What if the site offers the
token strategy, but then decides to outsource the whole authentication
process to a different third party? We are back at the same problem again.
However it sounds like what you are saying is that there should be a
standardized mechanism for handling the site <=> user token verification.
If we use OAuth terminology that would be: We should allow *step-up
authentication* to occur solely between the *resource server (RS)* and
the *user
agent* without involving the *authorization server (AS)*. But then who
generates the new JWTs? If the AS generates the new one then, we didn't
stop anything. And if the RS generates the new one then actually the AS
isn't needed to do anything.

And that latter case is actually the reality if we consider these tokens to
be a 2FA mechanism that is managed by the site/resource server. So I read
this as, we should standardize *WebAuthn *communication between a *user
agent* and the *resource server. *That already exists though, doesn't it?

On Thu, Aug 10, 2023 at 12:59 AM Matthias Fulz  wrote:

> I'm trying to explain my concern more deeply, please try to follow my
> thinking.
>
> First: Everything you've written is correct and I fully agree.
>
> But: The difference is: I'm deciding, that I'm using email from xy, I'm
> deciding, that I'm using this email to register at some site or anything.
>
> Anything of these services could be hacked of course, and then they can
> use my mail to reset password, use the accounts, etc.
>
> Now think from the other side:
>
> Some site, which I'm registered in is trusting some oauth provider I'm not
> even knowing about. I'm not registered at this provider. If this provider
> is (independent how or from whom) is used in a malicious way, they can
> access my account, without my knowledge by sending a valid token including
> my email.
>
>
> I'm not sure how to explain the main concern about this in more detail and
> of course I can avoid services providing these type of logins without my
> permission, but as said what about the future?
> On 8/10/23 00:40, Warren Parad wrote:
>
> Let me try that differently, is OAuth more vulnerable than email usage? If
> you hacked any email provider that's arguably a bigger goldmine than just
> ones protected by oauth. As long as sites are protected by email, oauth
> gives a more secure strategy. Most providers that accept email as
> authentication allow you to reset your password via email.
>
> Going further, "email is insecure" because providers that send email can
> impersonate you. How about telecom companies, they can pretend to send SMS
> from you. Or the government, they could issue a new password in your name
> and pretend to be you. The horror.
>
> In all seriousness, it's about your threat modal more than anything.
> Concerned about your email, then that's your weak point, concern about
> oauth, we'll first be concerned about your email, and then you can be
> concerned about oauth.
>
> If we assume that everything was on oauth, then there's the question of
> why don't providers just implement a FIDO2 compliant strategy. Wouldn't
> that solve everything?
>
> Don't get me wrong: I'm not telling everything is on oauth as far (I'm not
> so deep into the protocol) it's acting only as authorization not as
> authentication, than it is anyway the wrong point to address this issue.
>
> But if it would be possible to eliminate this specific issue inside the
> protocol directly, it would be the best solution to not even run into this
> situation at any later point of time.
>
>
> As total naive approach I could about something like:
>
> Client is trusting Provider for user authentication/authorization
>
> Client must set some random verification token (normally requested / set
> by the user)
>
> User is registering this token under the provider
>
> Only if this token is valid the token is accepted by the client
>
>
> If something like this would be included in the protocol itself, it would
> be working in 

Re: [OAUTH-WG] OAuth Trust model

[Warren Parad]

Let me try that differently, is OAuth more vulnerable than email usage? If
you hacked any email provider that's arguably a bigger goldmine than just
ones protected by oauth. As long as sites are protected by email, oauth
gives a more secure strategy. Most providers that accept email as
authentication allow you to reset your password via email.

Going further, "email is insecure" because providers that send email can
impersonate you. How about telecom companies, they can pretend to send SMS
from you. Or the government, they could issue a new password in your name
and pretend to be you. The horror.

In all seriousness, it's about your threat modal more than anything.
Concerned about your email, then that's your weak point, concern about
oauth, we'll first be concerned about your email, and then you can be
concerned about oauth.

If we assume that everything was on oauth, then there's the question of why
don't providers just implement a FIDO2 compliant strategy. Wouldn't that
solve everything?

On Thu, Aug 10, 2023 at 12:27 AM Matthias Fulz  wrote:

> Thank you for the responses so far.
> On 8/9/23 22:20, Warren Parad wrote:
>
> I can tell you I definitely read it. I actually read it multiple times.
> But I don't know what to tell you. The problem you've identified exists,
> but that doesn't necessarily mean it is a problem. In a way it is a bit
> like, You create a bank account at a bank and you give them all your money.
> They then decide to never give it back.
>
> Yep I know, but the difference is, that I've full control over my decision
> to give my money to this bank or not.
>
>
> While banks are regulated in most countries and things like GitHub are
> not, in essence this interaction is based on trust. Of course solutions
> like WebAuthn via FIDO2 used as a first party authentication can solve
> this, and arguably this is the remit of the entire web3.0 domain.
>
> I don't think anyone would suggest this isn't a problem, just that it
> isn't that big of a problem. I think realistically, in order for this
> problem to have a closed form solution, it would need to start with a
> suggestion on how to solve it, rather than a bunch of us agreeing that it
> is. Because right now there doesn't seem to be any fundamental solution
> available for this. And honestly, the bigger problem is the digital assets
> at risk at the third parties is not due to impersonation, but just general
> negligence. GitHub isn't trying to malicious log into my StackOverflow
> account, and Google isn't trying to log into my bank. That's because these
> organizations have supposedly bound themselves to not grant this ability to
> their internal engineers to abuse. And they are spending tons of resources
> attempting to stop external attackers.
>
> That being said, it's hard to know if this problem hasn't already
> transgressed in the wild. While it is certainly possible, it seems internal
> users are more likely to act maliciously on behalf of the user via their
> owned data in their own company, rather than attempt to impersonate their
> users at third party sites.
>
> These points are totally correct, but I think also about something like
> official Authorities (ae. Patriot Act, etc.) that would definitely be
> interested in such things (ok not on me personally), but this is another
> topic.
>
> For me to be more safe, I'm using now a unique mail for Github, etc.,
> which is sufficient for now, but if you think into the future and
> especially about oauth with more than a handful widely used trusted
> Providers and that they could be hacked, infiltrated forced to grant
> malicious access, etc. Than this could become to a huge problem in no time.
>
> As example: Think about one widely used trusted provider that's hacked, or
> similar. You could access so many accounts on multiple sites, even if the
> users are never used this oauth for these sites.
>
>
> Sorry to insist here, but just because it is not an issue now, I can't
> agree that this not a big deal in general.
>
> I mean in the above scenario even a unique mail wouldn't help because that
> could send any mail, they want to these sites. Think about such provider
> acting malicious and you would not even HAVE an account at any of them:
> every site, that trusts them could be accessed under your account just by
> knowing the user identifier, which is in 99% time the mail.
>
>
> - Matthias
>
>
> - Warren
>
> On Wed, Aug 9, 2023 at 10:06 PM mfulz  wrote:
>
>> Anyone read this topic or could tell if there is a better place to adress
>> this?
>>
>> Sent from Nine <http://www.9folders.com/>
>> --
>> *Von:* mfulz
>> *Gesendet:* Sonntag, 16. Juli 2023 03:38
>> *An:* oauth@ietf.org
&g

Re: [OAUTH-WG] OAuth Trust model

[Warren Parad]

I can tell you I definitely read it. I actually read it multiple times. But
I don't know what to tell you. The problem you've identified exists, but
that doesn't necessarily mean it is a problem. In a way it is a bit like,
You create a bank account at a bank and you give them all your money. They
then decide to never give it back.

While banks are regulated in most countries and things like GitHub are not,
in essence this interaction is based on trust. Of course solutions like
WebAuthn via FIDO2 used as a first party authentication can solve this, and
arguably this is the remit of the entire web3.0 domain.

I don't think anyone would suggest this isn't a problem, just that it isn't
that big of a problem. I think realistically, in order for this problem to
have a closed form solution, it would need to start with a suggestion on
how to solve it, rather than a bunch of us agreeing that it is. Because
right now there doesn't seem to be any fundamental solution available for
this. And honestly, the bigger problem is the digital assets at risk at the
third parties is not due to impersonation, but just general negligence.
GitHub isn't trying to malicious log into my StackOverflow account, and
Google isn't trying to log into my bank. That's because these organizations
have supposedly bound themselves to not grant this ability to their
internal engineers to abuse. And they are spending tons of resources
attempting to stop external attackers.

That being said, it's hard to know if this problem hasn't already
transgressed in the wild. While it is certainly possible, it seems internal
users are more likely to act maliciously on behalf of the user via their
owned data in their own company, rather than attempt to impersonate their
users at third party sites.

- Warren

On Wed, Aug 9, 2023 at 10:06 PM mfulz  wrote:

> Anyone read this topic or could tell if there is a better place to adress
> this?
>
> Sent from Nine 
> --
> *Von:* mfulz
> *Gesendet:* Sonntag, 16. Juli 2023 03:38
> *An:* oauth@ietf.org
> *Betreff:* [OAUTH-WG] OAuth Trust model
>
>
>
> Hi Together,
>
> I was thinking about some (at least I see it in that way) problem in the
> whole oauth/openid design:
>
> The problem is the following:
>
> The user has no control about what providers are accepted by the clients
> (websites, etc.) and this opens access to these providers without any way
> to protect against that.
>
> Example:
>
> I've created an account with email/password login at stackoverflow
>
> I've created an account with the same email at github
>
> -> logged out from stackoverflow
>
> -> logged in via github oauth -> working and connected to the email/pw
> account from stackoverflow
>
>
> Stackoverflow has the possibility to remove the github login now, but the
> main problem is, that I would be out of control, that some of these oauth
> providers
>
> (please don't go into the discussion WHY they or anyone should do it)
> could access my accounts, when such site would allow them as provider.
>
>
> In my opionion it would be good to avoid such issues, by including
> something in the standard, that the user MUST allow the connection on both
> sides on the client
>
> and on the provider.
>
>
> Yes for sso without any existing account that's some kind of an issue, but
> still it could be added some verification process like sending confirmation
> link
>
> That the user is accepting the oauth provider on the Client side.
>
> Then the oauth provider would also need access to my emails to access my
> account.
>
>
> Not sure if I'm wrong here but I think my description is correct.
>
>
> BR,
>
> Matthias
> ___
> 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

Re: [OAUTH-WG] Call for adoption - SD-JWT-based Verifiable Credentials

[Warren Parad]

+1

On Sat, Jul 29, 2023 at 9:26 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is an official call for adoption for the *SD-JWT-based Verifiable
> Credentials *draft discussed in SF.
> https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc/
>
> Please, reply on the mailing list and let us know if you are in favor of
> adopting this draft as WG document, by *August 11th*.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> 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

Re: [OAUTH-WG] BCP: Mix-Up Attacks, Implicit Grant Variant

[Warren Parad]

That doesn't make sense to me.

On Wed, Jun 14, 2023, 21:31 Daniel Fett 
wrote:

> Hi Alexander,
> Am 14.06.23 um 15:19 schrieb Alexander Rademann:
>
> *Hello, everyone! Section 4.4.1 of the BCP
> 
> draft lists several variants of mix-up attacks; the description of the
> Implicit grant variant reads as follows: "In the implicit grant, the
> attacker receives an access token instead of the code; the rest of the
> attack works as above." Given the attack description in that section, it is
> not clear to me why an attacker would receive the access token and which
> part the "rest of the attack" refers to. When the Implicit grant is used,
> H-AS sends the access token (via redirect) to the user agent, which
> extracts it and sends it to the client. However, the client does not send
> the access token to A-AS, does it? (I hope that I didn’t overlook anything
> in that section.)*
>
> * I also checked the referenced paper ;
> there, the authors assume that the access token is sent to the
> authorization server under the control of the attacker (or, using their
> terminology, identity provider) to access some resource. [Appendix B, p.
> 31ff] Perhaps this (or some similar) assumption should be added to the
> description of this variant?*
>
> The underlying assumption is that when then user selected to use A-AS in
> the beginning, the access token would also be used with a Resource Server
> under the attacker's control.
>
> -Daniel
>
>
> * I'm sorry if I missed anything or if this has already been addressed
> before, I'm new to this mailing list and did not find anything in the
> archives. Kind regardsAlex*
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> ___
> 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

Re: [OAUTH-WG] BCP: Mix-Up Attacks, Implicit Grant Variant

[Warren Parad]

Presumably, the attacker can get the token by having the Honest-AS redirect
the user to a site controlled by the Attacker. That site then would
redirect the user back to the original site with the Honest-AS token. This
is no different than an ordinary phishing based attack.

On Wed, Jun 14, 2023, 20:24 Alexander Rademann 
wrote:

>
>
> *Hello, everyone!Section 4.4.1 of the BCP
> 
> draft lists several variants of mix-up attacks; the description of the
> Implicit grant variant reads as follows: "In the implicit grant, the
> attacker receives an access token instead of the code; the rest of the
> attack works as above."Given the attack description in that section, it is
> not clear to me why an attacker would receive the access token and which
> part the "rest of the attack" refers to. When the Implicit grant is used,
> H-AS sends the access token (via redirect) to the user agent, which
> extracts it and sends it to the client. However, the client does not send
> the access token to A-AS, does it? (I hope that I didn’t overlook anything
> in that section.)*
>
>
>
> *I also checked the referenced paper ;
> there, the authors assume that the access token is sent to the
> authorization server under the control of the attacker (or, using their
> terminology, identity provider) to access some resource. [Appendix B, p.
> 31ff] Perhaps this (or some similar) assumption should be added to the
> description of this variant?I'm sorry if I missed anything or if this has
> already been addressed before, I'm new to this mailing list and did not
> find anything in the archives.Kind regardsAlex*
> ___
> 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

Re: [OAUTH-WG] OAuth 2.1 & B2E apps (Jaap Francke)

[Warren Parad]

Frankly I just don't understand.  You've even said in your original email,
that the oath spec is alive and well in enterprise deployments. And since
that is the case, it points to how successful the current state of the RFCs
are. So I can't fathom what would make sense to actually change.

If anything it may mean that some people's interpretations of specific
words in the documents have been taken to be more specific than intended,
however this can't be fixed by changing the words, someone will always
interpret them in an inconsistent manner.

So, at least from my perspective, there is nothing we need to do, nor
should do here as the language is already incredible open and has been
successful. That's more than anyone could hope for.

If you are interested in continuing down this path anyway, it would be most
helpful to focus on one single implementation where the exact wording
causes an actual problem in designing that system. And rather than
suggesting "we should change the words being used" which feels incredibly
arbitrary, please quote the actually source definition and share what is
problematic with it.

- Warren

On Mon, Apr 17, 2023, 16:14 Jaap Francke  wrote:

> Hi all,
>
>
>
> Early March I shared the suggestion to make the abstract OAuth protocol
> description a bit more generic so it would not only have a fit with B2C use
> cases but would suit B2E use cases as well.
> I haven’t seen any response from you – I find myself wondering why.
> As my suggestion still makes sense to me, I’d appreciate a response.
> Thanks in advance!
>
>
>
> Cheers, Jaap
>
>
>
> *From: *OAuth  on behalf of oauth-requ...@ietf.org
> 
> *Date: *Thursday, 2 March 2023 at 20:00
> *To: *oauth@ietf.org 
> *Subject: *OAuth Digest, Vol 173, Issue 7
>
> Send OAuth mailing list submissions to
> oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
> oauth-requ...@ietf.org
>
> You can reach the person managing the list at
> oauth-ow...@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>1. Artart last call review of
>   draft-ietf-oauth-step-up-authn-challenge-12
>   (Robert Sparks via Datatracker)
>2. OAuth 2.1 & B2E apps (Jaap Francke)
>
>
> --
>
> Message: 1
> Date: Thu, 02 Mar 2023 10:41:34 -0800
> From: Robert Sparks via Datatracker 
> To: 
> Cc: draft-ietf-oauth-step-up-authn-challenge@ietf.org,
> last-c...@ietf.org,  oauth@ietf.org
> Subject: [OAUTH-WG] Artart last call review of
> draft-ietf-oauth-step-up-authn-challenge-12
> Message-ID: <167778249416.23678.7058306125542432...@ietfa.amsl.com>
> Content-Type: text/plain; charset="utf-8"
>
> Reviewer: Robert Sparks
> Review result: Ready with Issues
>
> Summary: essentially ready but with issues to consider before being
> published
> as a proposed standard RFC.
>
> Issues:
>
> I expected to find some discussion of considerations of avoiding "step
> down"
> given the intuitive appeal to "step up". Can the client or Authorization
> server
> notice if the resource server has through whatever fault asserted that it
> will
> only accept the use of an authentication context class that is blatantly
> inferior to what has already been provided? And if they notice, what is
> expected to happen? Or is it expected that this is allowed, particularly
> when a
> short max_age is also supplied?
>
> The document also suggests that the client hold on to, and possibly re-use
> in
> the future, access tokens that have been challenged as having insufficient
> user
> authorization. Is this behavior something that follows a well-known and
> well-implemented pattern documented elsewhere? If so, a pointer would be
> useful. If not, this seems like something that deserves more discussion if
> not
> more definition.
>
> Nits:
> The reference to abr-twitter-reply will go away with the changelog when
> the RFC
> Editor removes it. It would be kind to acknowledge that in the note to the
> RFC
> Editor so that they know it's expected and don't have to ask.
>
>
>
>
>
> --
>
> Message: 2
> Date: Thu, 2 Mar 2023 18:59:26 +
> From: Jaap Francke 
> To: "oauth@ietf.org" 
> Subject: [OAUTH-WG] OAuth 2.1 & B2E apps
> Message-ID:
> <
> am0pr06mb418002174bf153ed05d93839e4...@am0pr06mb4180.eurprd06.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="windows-1252"
>
> Hi all,
>
> I?d like to pitch the idea of changing the abstract OAuth description to
> incorporate  how OAuth is used in many B2E applications.
> In my view, OAuth 2.1 is a great opportunity to do so, without the need to
> make any changes in the core protocol itself, so nothing gets ?broken?.
> The 2.1 RFC would be just acknowledging how OAuth is 

Re: [OAUTH-WG] A proposal for a new Internet Draft

[Warren Parad]

I think it would make sense if after CalDAV was updated to explicitly
include OAuth scopes relevant for it, that it could be considered to update
the official OAuth parameter scope list to include them. But I would like
to avoid doing this in reverse. I.e. Let's have the calendar experts decide
what OAuth scopes make sense, and then we can approve adding them to the
list. This makes sense rather than us trying to decide which scopes make
sense for calendar applications that we don't necessarily have expertise
in. I don't have any confidence in my ability (I'm not going to speak for
everyone) in knowing whether these are the right scopes, and getting this
wrong is very very hard to undo. While we can replace CalDAV specs, we
don't have any good strategy to remove official scopes. So before we add
them, we should be near 100% sure that they are the correct ones and will
never change.

On Sun, Apr 2, 2023 at 11:53 PM Clinton Bunch  wrote:

> On 4/2/2023 4:44 PM, Warren Parad wrote:
>
> If CalDAV is that spec, then wouldn't it make sense to request updates to
> that spec to additionally define OAuth scopes? I don't think it makes sense
> for the OAuth WG to define scopes for other specs, and I also don't think
> updating the CalDAV spec is in the purview of this working group. Instead
> the expectation is for specs using OAuth to define their own scopes. In
> that light, might it make sense to review the current working groups to
> find one that could take on the addendum to the existing CalDAV spec?
>
> I considered posting this to calext or emailcore, but neither would be
> appropriate for all these scopes and Oauth would need to approve the IANA
> registration using this URI namespace.  So I tried here first.
>
>
> On Sun, Apr 2, 2023 at 11:24 PM Clinton Bunch  wrote:
>
>> On 4/2/2023 4:06 PM, Warren Parad wrote:
>>
>> Why is this still hypothetical, is there a reason you don't want to share
>> a concrete use case?
>>
>> I run a small e-mail and calendar server for my own use.  Thunderbird
>> cannot provide Oauth authentication to my server without knowing what
>> scopes define email services or calendar services or contacts services.  It
>> is impractical to expect Thunderbird to map my specific scopes to those
>> services and do the same for thousands of other servers.  So having a
>> well-defined set of scopes with well-defined semantics allows Thunderbird
>> to use the discovery protocol to see that my AS supports some or all of
>> those scopes.
>>
>>
>> Sure, Thunderbird needs to understand the scopes mapped by email
>> providers, but having shared scope names, does not imply the implementation
>> of those scopes. So Thunderbird still has to maintain a map of "what it
>> wants" to "what scope provides that by that service in question". Having
>> standard scopes doesn't change that, it only hopefully convinces existing
>> email providers to actually change their scope names.
>>
>> Since most small providers don't currently have scopes defined because
>> the clients don't even try to support scopes except those defined by the
>> big players, this gives them a set of scopes that can be reasonably
>> supported by both the AS and the client without manual configuration.
>>
>>
>> Are existing email providers going to change their scope names? I can't
>> see Google Calendar doing that. The problem with defining arbitrary strings
>> that imply permissions, is that "what exactly those scopes means" is not
>> trivially obvious. That is, as David Waite put it, does *calendar:update
>> imply calendar:read*. Adding both to the oauth params still allows some
>> providers to say *yes* while others say *no*. Which means we aren't just
>> talking about adding scopes, we are talking about what those scopes imply.
>> Before we can add scopes, I think we would need to first point to a
>> globally accepted calendar service interface specification which we could
>> use to draw inspiration from. However if such spec already existed, then
>> the scopes would also exist.
>>
>> How is CalDAV  not that spec?
>>
>> Yes, there may be places where the semantics are not quite well-defined
>> enough, that would be the point of having a discussion.
>>
>>
>> That is to say, a spec needs to exist before creating scopes, and if the
>> spec did exist, the scopes would already be defined. For the that reason, I
>> don't believe this this the best working group for that.
>>
>>
>> On Sun, Apr 2, 2023 at 10:53 PM Clinton Bunch 
>> wrote:
>>
>>> On 4/2/2023 3:13 PM, Warren Parad wrote:
>>>
>>> I'm look

Re: [OAUTH-WG] A proposal for a new Internet Draft

[Warren Parad]

If CalDAV is that spec, then wouldn't it make sense to request updates to
that spec to additionally define OAuth scopes? I don't think it makes sense
for the OAuth WG to define scopes for other specs, and I also don't think
updating the CalDAV spec is in the purview of this working group. Instead
the expectation is for specs using OAuth to define their own scopes. In
that light, might it make sense to review the current working groups to
find one that could take on the addendum to the existing CalDAV spec?

On Sun, Apr 2, 2023 at 11:24 PM Clinton Bunch  wrote:

> On 4/2/2023 4:06 PM, Warren Parad wrote:
>
> Why is this still hypothetical, is there a reason you don't want to share
> a concrete use case?
>
> I run a small e-mail and calendar server for my own use.  Thunderbird
> cannot provide Oauth authentication to my server without knowing what
> scopes define email services or calendar services or contacts services.  It
> is impractical to expect Thunderbird to map my specific scopes to those
> services and do the same for thousands of other servers.  So having a
> well-defined set of scopes with well-defined semantics allows Thunderbird
> to use the discovery protocol to see that my AS supports some or all of
> those scopes.
>
>
> Sure, Thunderbird needs to understand the scopes mapped by email
> providers, but having shared scope names, does not imply the implementation
> of those scopes. So Thunderbird still has to maintain a map of "what it
> wants" to "what scope provides that by that service in question". Having
> standard scopes doesn't change that, it only hopefully convinces existing
> email providers to actually change their scope names.
>
> Since most small providers don't currently have scopes defined because the
> clients don't even try to support scopes except those defined by the big
> players, this gives them a set of scopes that can be reasonably supported
> by both the AS and the client without manual configuration.
>
>
> Are existing email providers going to change their scope names? I can't
> see Google Calendar doing that. The problem with defining arbitrary strings
> that imply permissions, is that "what exactly those scopes means" is not
> trivially obvious. That is, as David Waite put it, does *calendar:update
> imply calendar:read*. Adding both to the oauth params still allows some
> providers to say *yes* while others say *no*. Which means we aren't just
> talking about adding scopes, we are talking about what those scopes imply.
> Before we can add scopes, I think we would need to first point to a
> globally accepted calendar service interface specification which we could
> use to draw inspiration from. However if such spec already existed, then
> the scopes would also exist.
>
> How is CalDAV  not that spec?
>
> Yes, there may be places where the semantics are not quite well-defined
> enough, that would be the point of having a discussion.
>
>
> That is to say, a spec needs to exist before creating scopes, and if the
> spec did exist, the scopes would already be defined. For the that reason, I
> don't believe this this the best working group for that.
>
>
> On Sun, Apr 2, 2023 at 10:53 PM Clinton Bunch 
> wrote:
>
>> On 4/2/2023 3:13 PM, Warren Parad wrote:
>>
>> I'm looking for proof that anyone actually needs these. Introducing
>> unnecessary scopes into the spec is both a waste of time and needlessly
>> complicates the documentation. So we need there to be a real problem that
>> is attempting to be solved in which additional scopes is the right
>> solution.
>>
>> I'm going to start off the conversation by saying, I think this is a bad
>> idea. Most services in the world do not have any of these, and when they do
>> the relevant scopes are coupled to the relevant authorization server (AS).
>> In other words, you only define the scopes you want after reviewing the
>> documentation for the relevant AS. Defining new standard scopes helps for
>> interoperability, but there is zero interoperability with scopes (the AS
>> defines them, the Dev picks them, and the User reviews them. Scopes don't
>> carry additional meaning cross platforms). So this seems like just a really
>> bad idea to me.
>>
>> Scopes do help with permissions and visibility in the created id_token
>> (or access_token), for instance let's say a service wanted to link a user's
>> access to their ethereum wallet. In that case, a new scope like
>> eth_wallet_id might make sense, so that the wallet public key would show up
>> in the id_token to be directly used.
>>
>> But the scopes that have been proposed don't expose data in the tokens,
>> they define access. User co

Re: [OAUTH-WG] A proposal for a new Internet Draft

[Warren Parad]

Why is this still hypothetical, is there a reason you don't want to share a
concrete use case? Sure, Thunderbird needs to understand the scopes mapped
by email providers, but having shared scope names, does not imply the
implementation of those scopes. So Thunderbird still has to maintain a map
of "what it wants" to "what scope provides that by that service in
question". Having standard scopes doesn't change that, it only hopefully
convinces existing email providers to actually change their scope names.

Are existing email providers going to change their scope names? I can't see
Google Calendar doing that. The problem with defining arbitrary strings
that imply permissions, is that "what exactly those scopes means" is not
trivially obvious. That is, as David Waite put it, does *calendar:update
imply calendar:read*. Adding both to the oauth params still allows some
providers to say *yes* while others say *no*. Which means we aren't just
talking about adding scopes, we are talking about what those scopes imply.
Before we can add scopes, I think we would need to first point to a
globally accepted calendar service interface specification which we could
use to draw inspiration from. However if such spec already existed, then
the scopes would also exist.

That is to say, a spec needs to exist before creating scopes, and if the
spec did exist, the scopes would already be defined. For the that reason, I
don't believe this this the best working group for that.


On Sun, Apr 2, 2023 at 10:53 PM Clinton Bunch  wrote:

> On 4/2/2023 3:13 PM, Warren Parad wrote:
>
> I'm looking for proof that anyone actually needs these. Introducing
> unnecessary scopes into the spec is both a waste of time and needlessly
> complicates the documentation. So we need there to be a real problem that
> is attempting to be solved in which additional scopes is the right
> solution.
>
> I'm going to start off the conversation by saying, I think this is a bad
> idea. Most services in the world do not have any of these, and when they do
> the relevant scopes are coupled to the relevant authorization server (AS).
> In other words, you only define the scopes you want after reviewing the
> documentation for the relevant AS. Defining new standard scopes helps for
> interoperability, but there is zero interoperability with scopes (the AS
> defines them, the Dev picks them, and the User reviews them. Scopes don't
> carry additional meaning cross platforms). So this seems like just a really
> bad idea to me.
>
> Scopes do help with permissions and visibility in the created id_token (or
> access_token), for instance let's say a service wanted to link a user's
> access to their ethereum wallet. In that case, a new scope like
> eth_wallet_id might make sense, so that the wallet public key would show up
> in the id_token to be directly used.
>
> But the scopes that have been proposed don't expose data in the tokens,
> they define access. User contact information is already available via 
> *profile,
> email, address, and phone*. That means not only are we talking about
> creating additional scopes, we are also talking about expanding scopes in a
> way that currently isn't used. Which brings us back to, what problem are
> you trying to solve?
>
>
> Right now an email (or calendar or contact) client (such as Thunderbird)
> is in general written by an organization separate from the author of the
> resource server (such as Dovecot), which is different from the author of
> the authorization server.  The authorization server may have several scopes
> it supports, so even using the discovery protocol, the client doesn't know
> how to choose the scopes it needs to request without those scopes being
> hard-coded per authorization server, or entered by the user.  This would
> allow the client, AS, and resource server too use a common set of scopes to
> specify that this domain is offering groupware services and the scopes the
> client needs to request.  It requires cooperation from the AS
> administrator, true, but both client and server know what the appropriate
> scopes are without further configuration.
>
> These clients may be used across thousandds of AS domains and having to
> hard-code the scopes for each is going to deter adoption of Oauth2
> authentication, by limiting it to only a few domains.
>
> Another use case is connecting voice assistants to calendars hosted on
> servers of small organizations.  The voice assistant needs to know what
> scopes to request for the token to access the users calendar.  Right now
> that is limited to just the calendar services of a few large players which
> are hard-coded.
>
> Having the user enter the necessary scopes by hand, where the client has
> that capability, leads to a poor user experience.
>
> The point 

Re: [OAUTH-WG] A proposal for a new Internet Draft

[Warren Parad]

I'm looking for proof that anyone actually needs these. Introducing
unnecessary scopes into the spec is both a waste of time and needlessly
complicates the documentation. So we need there to be a real problem that
is attempting to be solved in which additional scopes is the right solution.

I'm going to start off the conversation by saying, I think this is a bad
idea. Most services in the world do not have any of these, and when they do
the relevant scopes are coupled to the relevant authorization server (AS).
In other words, you only define the scopes you want after reviewing the
documentation for the relevant AS. Defining new standard scopes helps for
interoperability, but there is zero interoperability with scopes (the AS
defines them, the Dev picks them, and the User reviews them. Scopes don't
carry additional meaning cross platforms). So this seems like just a really
bad idea to me.

Scopes do help with permissions and visibility in the created id_token (or
access_token), for instance let's say a service wanted to link a user's
access to their ethereum wallet. In that case, a new scope like
eth_wallet_id might make sense, so that the wallet public key would show up
in the id_token to be directly used.

But the scopes that have been proposed don't expose data in the tokens,
they define access. User contact information is already available via *profile,
email, address, and phone*. That means not only are we talking about
creating additional scopes, we are also talking about expanding scopes in a
way that currently isn't used. Which brings us back to, what problem are
you trying to solve?

On Sun, Apr 2, 2023 at 9:57 PM Clinton Bunch  wrote:

> On 4/2/2023 2:49 PM, Warren Parad wrote:
>
> But why these scopes?
>
> Separate read and write scopes for the three pieces of a groupware service
> seemed appropriate.  And separating the three pieces of groupware seemed
> appropriate as not all domains or users will use all of them.
>
> But since the most common use cases would include both read and write, I
> defined short-hand scopes that included both permissions.
>
> If that doesn't answer your question, then I'm not sure what you're
> looking for.
>
>
> On Sun, Apr 2, 2023 at 9:37 PM Clinton Bunch  wrote:
>
>>
>>
>> On 4/2/2023 2:26 PM, Warren Parad wrote:
>>
>> Sorry, I'm asking why these scopes at all? I personally have never seen
>> any of them used ever (and I'm not being hyperbolic), How did you come up
>> with these suggestions?
>>
>> The naming seemed logical given the IANA URI namespace.  I was looking
>> for something that would be a common set of scopes for this application
>> domain that wasn't tied to a single vendor.
>>
>> The purpose *could* be served by widespread adoption of Google's scopes
>> such as
>>
>> https://www.googleapis.com/auth/calendar
>>
>> but I believe that the reliance on a specific vendor name would hamper
>> wide-spread adoption, so a namespace defined by a neutral party such as
>> IETF seemed best.
>>
>> On Sun, Apr 2, 2023 at 8:46 PM Clinton Bunch 
>> wrote:
>>
>>> On 4/2/2023 1:34 PM, Warren Parad wrote:
>>>
>>> I propose a set of nine well-known scopes
>>>
>>>
>>> Can you elaborate on what you mean by "well-known"? Is there some
>>> canonical list, where these were pulled from?
>>>
>>> I was trying to avoid the use of standard, as that implies they must be
>>> used.  To encourage adoption, I didn't want to imply that the large
>>> providers would be required to change their software to accommodate these,
>>> though it would be nice if they did.  These scopes are not currently in use
>>> as far as I know.
>>>
>>> The sense of well-known is that once this was published they would be
>>> well-known scopes that could be implemented with well-defined semantics.
>>>
>>>
>>> - Warren
>>>
>>> On Sun, Apr 2, 2023 at 8:12 PM Clinton Bunch 
>>> wrote:
>>>
>>>> This seemed the most appropriate working group to post this suggestion.
>>>>
>>>> I would like to see a new Internet-Draft/RFC to add some well-known
>>>> scopes to the IANA registry to promote adoption of Oauth in Groupware
>>>> domains.  I will try to write it myself, but have no experience with
>>>> I-Ds or as a technical writer and could use some help.
>>>>
>>>> Since the publication of RFC 7628 there is a push to migrate groupware
>>>> servers to use Oauth2.  This is hampered by the fact that there are
>>>> several different server implementations and client implementations are
>>>>

Re: [OAUTH-WG] A proposal for a new Internet Draft

[Warren Parad]

But why these scopes?

On Sun, Apr 2, 2023 at 9:37 PM Clinton Bunch  wrote:

>
>
> On 4/2/2023 2:26 PM, Warren Parad wrote:
>
> Sorry, I'm asking why these scopes at all? I personally have never seen
> any of them used ever (and I'm not being hyperbolic), How did you come up
> with these suggestions?
>
> The naming seemed logical given the IANA URI namespace.  I was looking for
> something that would be a common set of scopes for this application domain
> that wasn't tied to a single vendor.
>
> The purpose *could* be served by widespread adoption of Google's scopes
> such as
>
> https://www.googleapis.com/auth/calendar
>
> but I believe that the reliance on a specific vendor name would hamper
> wide-spread adoption, so a namespace defined by a neutral party such as
> IETF seemed best.
>
> On Sun, Apr 2, 2023 at 8:46 PM Clinton Bunch  wrote:
>
>> On 4/2/2023 1:34 PM, Warren Parad wrote:
>>
>> I propose a set of nine well-known scopes
>>
>>
>> Can you elaborate on what you mean by "well-known"? Is there some
>> canonical list, where these were pulled from?
>>
>> I was trying to avoid the use of standard, as that implies they must be
>> used.  To encourage adoption, I didn't want to imply that the large
>> providers would be required to change their software to accommodate these,
>> though it would be nice if they did.  These scopes are not currently in use
>> as far as I know.
>>
>> The sense of well-known is that once this was published they would be
>> well-known scopes that could be implemented with well-defined semantics.
>>
>>
>> - Warren
>>
>> On Sun, Apr 2, 2023 at 8:12 PM Clinton Bunch 
>> wrote:
>>
>>> This seemed the most appropriate working group to post this suggestion.
>>>
>>> I would like to see a new Internet-Draft/RFC to add some well-known
>>> scopes to the IANA registry to promote adoption of Oauth in Groupware
>>> domains.  I will try to write it myself, but have no experience with
>>> I-Ds or as a technical writer and could use some help.
>>>
>>> Since the publication of RFC 7628 there is a push to migrate groupware
>>> servers to use Oauth2.  This is hampered by the fact that there are
>>> several different server implementations and client implementations are
>>> often written by different organizations with little overlap.  One of
>>> the barriers to widespread adoption is that each authorization server
>>> has a different set of scopes to cover the necessary user
>>> authorizations.  One groupware client I know has only a few Auth Servers
>>> available that are hardcoded and nearly every one has a different set of
>>> scopes.  Servers have to have appropriate scopes configured by the
>>> administrator in order for the server to know which scopes to check.  It
>>> also makes it hard for clients to know which scopes to request without
>>> some sort of configuration file provided by the domain or worse, having
>>> the user enter the appropriate scopes by hand.  The latter especially
>>> seems like a support headache for the admin of the groupware servers.
>>>
>>> I propose a set of nine well-known scopes be added to the Oauth URI IANA
>>> registry to address this.
>>>
>>> urn:ietf:params:oauth:scope:mail:read- Authorization to read
>>> email (IMAP,POP)
>>> urn:ietf:params:oauth:scope:mail:send- Authorization to send
>>> mail on the user's behalf (SMTP)
>>> urn:ietf:params:oauth:scope:mail- Combination of the
>>> previous two scopes
>>> urn:ietf:params:oauth:scope:calendar:read- Authorization to read
>>> calendar entries
>>> urn:ietf:params:oauth:scope:calendar:update- Authorization to
>>> update/create/delete calendar entries
>>> urn:ietf:params:oauth:scope:calendar- Combination of the
>>> previous two scopes
>>> urn:ietf:params:oauth:scope:contacts:read- Authorization to read
>>> contacts information
>>> urn:ietf:params:oauth:scope:contacts:update- Authorization to
>>> update/create/delete contact information.
>>> urn:ietf:params:oauth:scope:contacts- Combination of the
>>> previous two scopes
>>>
>>> ___
>>> 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

Re: [OAUTH-WG] A proposal for a new Internet Draft

[Warren Parad]

Sorry, I'm asking why these scopes at all? I personally have never seen any
of them used ever (and I'm not being hyperbolic), How did you come up with
these suggestions?

On Sun, Apr 2, 2023 at 8:46 PM Clinton Bunch  wrote:

> On 4/2/2023 1:34 PM, Warren Parad wrote:
>
> I propose a set of nine well-known scopes
>
>
> Can you elaborate on what you mean by "well-known"? Is there some
> canonical list, where these were pulled from?
>
> I was trying to avoid the use of standard, as that implies they must be
> used.  To encourage adoption, I didn't want to imply that the large
> providers would be required to change their software to accommodate these,
> though it would be nice if they did.  These scopes are not currently in use
> as far as I know.
>
> The sense of well-known is that once this was published they would be
> well-known scopes that could be implemented with well-defined semantics.
>
>
> - Warren
>
> On Sun, Apr 2, 2023 at 8:12 PM Clinton Bunch  wrote:
>
>> This seemed the most appropriate working group to post this suggestion.
>>
>> I would like to see a new Internet-Draft/RFC to add some well-known
>> scopes to the IANA registry to promote adoption of Oauth in Groupware
>> domains.  I will try to write it myself, but have no experience with
>> I-Ds or as a technical writer and could use some help.
>>
>> Since the publication of RFC 7628 there is a push to migrate groupware
>> servers to use Oauth2.  This is hampered by the fact that there are
>> several different server implementations and client implementations are
>> often written by different organizations with little overlap.  One of
>> the barriers to widespread adoption is that each authorization server
>> has a different set of scopes to cover the necessary user
>> authorizations.  One groupware client I know has only a few Auth Servers
>> available that are hardcoded and nearly every one has a different set of
>> scopes.  Servers have to have appropriate scopes configured by the
>> administrator in order for the server to know which scopes to check.  It
>> also makes it hard for clients to know which scopes to request without
>> some sort of configuration file provided by the domain or worse, having
>> the user enter the appropriate scopes by hand.  The latter especially
>> seems like a support headache for the admin of the groupware servers.
>>
>> I propose a set of nine well-known scopes be added to the Oauth URI IANA
>> registry to address this.
>>
>> urn:ietf:params:oauth:scope:mail:read- Authorization to read
>> email (IMAP,POP)
>> urn:ietf:params:oauth:scope:mail:send- Authorization to send
>> mail on the user's behalf (SMTP)
>> urn:ietf:params:oauth:scope:mail- Combination of the
>> previous two scopes
>> urn:ietf:params:oauth:scope:calendar:read- Authorization to read
>> calendar entries
>> urn:ietf:params:oauth:scope:calendar:update- Authorization to
>> update/create/delete calendar entries
>> urn:ietf:params:oauth:scope:calendar- Combination of the
>> previous two scopes
>> urn:ietf:params:oauth:scope:contacts:read- Authorization to read
>> contacts information
>> urn:ietf:params:oauth:scope:contacts:update- Authorization to
>> update/create/delete contact information.
>> urn:ietf:params:oauth:scope:contacts- Combination of the
>> previous two scopes
>>
>> ___
>> 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

Re: [OAUTH-WG] A proposal for a new Internet Draft

[Warren Parad]

>
> I propose a set of nine well-known scopes


Can you elaborate on what you mean by "well-known"? Is there some canonical
list, where these were pulled from?

- Warren

On Sun, Apr 2, 2023 at 8:12 PM Clinton Bunch  wrote:

> This seemed the most appropriate working group to post this suggestion.
>
> I would like to see a new Internet-Draft/RFC to add some well-known
> scopes to the IANA registry to promote adoption of Oauth in Groupware
> domains.  I will try to write it myself, but have no experience with
> I-Ds or as a technical writer and could use some help.
>
> Since the publication of RFC 7628 there is a push to migrate groupware
> servers to use Oauth2.  This is hampered by the fact that there are
> several different server implementations and client implementations are
> often written by different organizations with little overlap.  One of
> the barriers to widespread adoption is that each authorization server
> has a different set of scopes to cover the necessary user
> authorizations.  One groupware client I know has only a few Auth Servers
> available that are hardcoded and nearly every one has a different set of
> scopes.  Servers have to have appropriate scopes configured by the
> administrator in order for the server to know which scopes to check.  It
> also makes it hard for clients to know which scopes to request without
> some sort of configuration file provided by the domain or worse, having
> the user enter the appropriate scopes by hand.  The latter especially
> seems like a support headache for the admin of the groupware servers.
>
> I propose a set of nine well-known scopes be added to the Oauth URI IANA
> registry to address this.
>
> urn:ietf:params:oauth:scope:mail:read- Authorization to read
> email (IMAP,POP)
> urn:ietf:params:oauth:scope:mail:send- Authorization to send
> mail on the user's behalf (SMTP)
> urn:ietf:params:oauth:scope:mail- Combination of the
> previous two scopes
> urn:ietf:params:oauth:scope:calendar:read- Authorization to read
> calendar entries
> urn:ietf:params:oauth:scope:calendar:update- Authorization to
> update/create/delete calendar entries
> urn:ietf:params:oauth:scope:calendar- Combination of the
> previous two scopes
> urn:ietf:params:oauth:scope:contacts:read- Authorization to read
> contacts information
> urn:ietf:params:oauth:scope:contacts:update- Authorization to
> update/create/delete contact information.
> urn:ietf:params:oauth:scope:contacts- Combination of the
> previous two scopes
>
> ___
> 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

Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

[Warren Parad]

It requires third party cookies which most browsers block by default, and
doesn't this assume that the cookie is set to *SameSite=Loose *or
*SameSite=None*. Wouldn't that directly expose that cookie for malicious
sites to utilize it to steal connect2Id generate access tokens?

Also what I don't understand from the connect2id site is:

> Performing the redirection in a hidden iframe doesn't normally work for an
> SPA either.


Why does it say that? (I feel like it drops this little bomb in there and
then runs away. maybe there is a specific reason, but if there is it is
lost on me)

On Thu, Mar 9, 2023 at 12:13 PM Dmitry Telegin  wrote:

> Hi all,
>
> In regards to the use cases for CORS in the Authorization endpoint - what
> about a SPA requesting a step-up reauthentication? Especially if it is
> "silent", e.g. initiating out-of-band authentication without the need for
> user interaction. Currently, we don't have too many options; it's either a
> full redirect + app reload (not so good from the UX point of view) or a
> (hidden) iframe. Probably deserves a separate discussion?
>
> On a related note, Connect2ID seems to be the only IAM solution that
> offers limited support for CORS in the Authorization endpoint (prompt=none
> + response_mode=cors). The use case they're supporting is silent refresh in
> the absence of a long-lived refresh token. See link:
> https://connect2id.com/products/server/docs/guides/cors-response-mode
>
> Also, it has been mentioned that "CORS on the authorization endpoint is a
> security issue" - could we elaborate on that? What would be the
> ramifications of having it?
>
> Cheers,
> Dmitry
>
> On Thu, Mar 9, 2023 at 9:23 AM Filip Skokan  wrote:
>
>> Hello Christopher,
>>
>> The wmrm specification use does not require CORS at the authorization
>> endpoint.
>>
>> - Filip
>>
>> 9. 3. 2023 v 10:12, Christopher Burroughs > 40protonmail...@dmarc.ietf.org>:
>>
>> 
>> Greetings,
>>
>> I apologize in advance if this question (my first in this list!) is silly
>> :)
>>
>> Regarding CORS support for the authorization endpoint, what about "web
>> message" silent refresh flows? While it never became an RFC, I reckon it is
>> implemented in quite a few places. Is this pattern generally discouraged
>> now? Perhaps even more due to the unavailability of same site cookies?
>>
>> Thanks for the interesting discussions,
>>
>> Best regards,
>> Chris
>>
>>
>> Sent with Proton Mail  secure email.
>>
>> --- Original Message ---
>> On Thursday, March 9th, 2023 at 16:57, Vittorio Bertocci > 40auth0@dmarc.ietf.org> wrote:
>>
>> Ha, we chatted about this during yesterday's office hours meeting and I
>> was chartered to propose new language, but I am not sure how to incorporate
>> this new info. Let me try to summarize here and see your reactions, DW.
>> Apps implemented in SPAs style can either handle token acquisition and
>> renewal from the user agent code, via classic authorization code + PKCE, or
>> delegate that to a backend (BFF or "TMI BFF") while retaining "SPA style"
>> for every other app function (eg UX). CORS is required only for the former
>> approach, and one could argue that the latter offers better security.
>> We can either expand on that nuance, or more simply switch the SHOULD to
>> MAY so that we inform the reader of what it takes to support (a style of
>> SPA) but we don't appear to be advocating for the less secure option.
>>
>> On CORS for the authorization endpoint. I thought the MUST NOT was aimed
>> at preventing programmatic access to the authorization endpoint from user
>> agents. Flipping around: are there any *other* scenarios involving the
>> authorization endpoint for which CORS support enables valid use cases?
>>
>>
>>
>> On Wed, Mar 8, 2023 at 10:50 AM David Waite > 40alkaline-solutions@dmarc.ietf.org> wrote:
>>
>>> *This message originated outside your organization.*
>>>
>>> --
>>>
>>> I would suggest SHOULD guidance for CORS for OAuth token endpoints and
>>> authorization endpoints which are publicly accessible.
>>>
>>> There are a lot of misconceptions about the security properties of CORS,
>>> and in particular the security properties from disabling CORS for an
>>> otherwise safe resource. To my knowledge there is one benefit of disabling
>>> for solely internally-facing infrastructure.
>>>
>>> To detail, a public website interacting with a user agent bridging
>>> public and private networks can use IPs and DNS to attempt to scan internal
>>> web infrastructure. It may attempt to manipulate browser-accessible
>>> resources via GET/POST, and get some information on the shape of the
>>> network via error and timing-based analysis. Enabling or disabling CORS
>>> does not affect reachability for GET/form POST requests (which do not
>>> require CORS preflight), but does affect visibility of the response.
>>>
>>> In such an environment, having CORS enabled for a metadata resource
>>> might reveal additional 

Re: [OAUTH-WG] OAUTH for Web Proxy authentication

[Warren Parad]

Markus could you shed some light on how this would be different from the
normal OAuth flow between any resource server and the user agent? Proxies
today could already start accepting OAuth authorization following the OAuth
spec, right?

On Tue, Jan 31, 2023 at 12:48 AM Markus  wrote:

> Hi Rifaat,
>
> Right now a browser uses either basic , NTLM,  Kerberos or Negotiate
> authentication to a proxy which are all old methods and not anymore
> appropriate with Microsoft AD moving to Azure AD. Other methods like OAUTH
> might now be more appropriate assuming enterprises still require proxy
> based controls at their borders to the Internet.
>
> Regards
> Markus
>
> *From:* Rifaat Shekh-Yusef
> *Sent:* Monday, January 30, 2023 6:12 PM
> *To:* Markus
> *Cc:* oauth@ietf.org ; George Fletcher
> *Subject:* Re: [OAUTH-WG] OAUTH for Web Proxy authentication
>
> Hi Markus,
>
> As Goerge mentioned, there is no such document that covers this.
> What use case(s) do you have in mind for this?
>
> Regards,
> Rifaat
>
>
> On Sat, Jan 28, 2023 at 7:50 PM Markus  wrote:
>
>> Thank you.
>>
>> Regards
>> Markus
>> *From:* George Fletcher
>> *Sent:* Saturday, January 28, 2023 1:43 PM
>> *To:* Markus; oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] OAUTH for Web Proxy authentication
>>
>> To my knowledge that spec doesn't exist. I'll let others chime in if they
>> have seen a proposal in that regard.
>>
>> In regards to which working group, given the core topic is OAuth
>> authorization, I would present it here at a minimum.
>>
>> Thanks,
>> George
>>
>> On 1/22/23 7:06 AM, Markus PlusNet wrote:
>>
>> Dear WG,
>>
>> I am new to oauth and wonder which WG would be responsible for
>> reviewing a Spec for Proxy authentication
>> https://httpwg.org/specs/rfc9110.html#auth.client.proxy using oauth or
>> does that spec already exist ?
>>
>> Thank you
>> Markus
>>
>>
>> ___
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> ___
>> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proposal for new OAuth authorization grant

[Warren Parad]

I didn't think this all the way through, but my immediate thought is,
doesn't the JWT Bearer directly support this already:
https://www.rfc-editor.org/rfc/rfc7523

It's not an exact match but I believe most if not all of it follows pretty
well. If it doesn't, it might be interesting to improve the current JWT
Bearer with whatever is missing.

On the surface one of the things that is missing is the nonce that is
generated by the AS as part of the login or sign up request, as well as the
sign up flow to register. Although I'm thinking what is really missing is
"dynamic user registration", although I don't believe that is covered by
any of the other grants, so maybe we ignore that part for now.

This is an interesting thought though, I'd be happy to collaborate on this
if this is a direction you end up going.

- Warren

On Fri, Dec 23, 2022 at 7:45 PM Malla Simhachalam <
mallasimhacha...@gmail.com> wrote:

> Hello All,
>
>  Hope you are all doing great. We have been thinking of creating a
> proposal for a new OAuth2 authorization grant based on the FIDO
> credentials, please let us know your thoughts so that we can put together a
> draft proposal.
>
> /**
>
> Abstract: FIDO Profile for OAuth2.0 Authorization Grants
>
> Fast Identity Online (FIDO) and WebAuthn are open standards that define
> strong cryptographic credentials that are alternatives to passwords for
> accessing websites and apps with secure and faster login experiences for
> users. FIDO and WebAuthn protocols have been developed through FIDO
> Alliance and W3C standard bodies. The OAuth 2.0 Authorization Framework [
> RFC6749 ] provides a method for
> making authenticated HTTP requests to a resource using an access token.
> Access tokens are issued to third-party clients by an authorization server
> (AS) with the (sometimes implicit) approval of the resource owner.  In
> OAuth, an authorization grant is an abstract term used to describe
> intermediate credentials that represent the resource owner authorization.
> An authorization grant is used by the client to obtain an access token.
> Several authorization grant types are defined to support a wide range of
> client types and user experiences.  OAuth also allows for the definition of
> new extension grant types to support additional clients or to provide a
> bridge between OAuth and other trust frameworks.
>
> This proposal defines a new authorization grant and how FIDO credentials
> can be used to obtain an access token. FIDO credentials are resource owners
> credentials directly as an authorization grant to obtain an access token.
> The credentials should only be used when there is a high degree of trust
> between the resource owner and the client. Even though this grant type
> requires direct client access to the resource owner credentials, the
> resource owner credentials are used for a single request and are exchanged
> for an access token.
>
>
> Token endpoint sample:
>
> POST v1/oauth2/token HTTP/1.1
>
> Host: authz.example.net
>
> Content-Type: application/x-www-form-urlencoded
>
> grant_type=urn:ietf:params:oauth:grant-type:webauthn-assertion
>
>  _assertion=
>
> :
>
> HTTP/1.1 200 OK
>
> Content-Type:application/json
>
> {
>
> “access_token”  : “A23.xjHEJEH830JLD”,
>
> “expires_in” : 900
>
> }
> ***/
>
> Thanks,
> Malla
> ___
> 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

Re: [OAUTH-WG] Call for adoption: Cross-Device Flows

[Warren Parad]

I support the adoption of this document.

On Tue, Nov 15, 2022 at 3:43 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> During the IETF meeting last week, there was a strong support for
> the adoption of the following document as a WG document:
> https://datatracker.ietf.org/doc/draft-kasselman-cross-device-security/
>
> This is to start a call for adoption for this document.
> Please, provide your feedback on the mailing list on whether you support
> the adoption of this document as a WG or not, by *Nov 29th*.
>
> Regards,
>  Rifaat & Hannes
>
>
> ___
> 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

Re: [OAUTH-WG] [IANA #1261154] expert review for draft-ietf-oauth-rar (OAuth Parameters - OAuth Extensions Error)

[Warren Parad]

Hello Sabrina,

In the future I want to make sure that there is more than one owner for
this process. In the past it sometimes was quite a challenge to get timely
approvals.

Would you be able to point me to the right place to ensure we can extend
the ownership?

Thanks,
Warren

On Thu, Nov 17, 2022, 19:09 Sabrina Tanamal via RT <
drafts-expert-review-comm...@iana.org> wrote:

> Hi Hannes (cc: oauth wg),
>
> As the designated expert for the OAuth Parameters and OAuth Extensions
> Error registries, can you review the proposed registrations in
> draft-ietf-oauth-rar for us? Please see
>
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar
>
> The due date is December 1st.
>
> If this is OK, when the IESG approves the document for publication, we'll
> make the registrations at
>
> https://www.iana.org/assignments/oauth-parameters
>
> thanks,
>
> Sabrina Tanamal
> Lead IANA Services Specialist
>
> ___
> 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

Re: [OAUTH-WG] [EXT] Re: Fw: New Version Notification for draft-burgin-jenkins-identity-chaining-00.txt

[Warren Parad]

Does it? That's not what I read from the nested jwt draft. If you could
point out where it requires either of those to be true I think it would
help the draft authors consider your additional use case.

On Fri, Nov 11, 2022 at 11:01 AM Dr. Kelley W Burgin 
wrote:

> Thanks Atul.
>
>
>
> Warren,
>
>
>
> We see the following two benefits of our solution over embedded tokens:
>
>
>
> 1. Iterated calls (say PR1 needs to access PR2 needs to access … needs to
> access PR5, all in different trust domains) do not result in a large final
> token as they would with embedded tokens
>
> 2. Our solution puts the burden of adding additional logic in the AS
> instead of the PRs as embedded tokens would do.
>
>
>
> Kelley
>
>
>
> *From: *Atul Tulshibagwale 
> *Date: *Friday, November 11, 2022 at 9:54 AM
> *To: *Warren Parad , "Dr. Kelley W
> Burgin" 
> *Cc: *"mjje...@cyber.nsa.gov" , "
> oauth@ietf.org" 
> *Subject: *[EXT] Re: [OAUTH-WG] Fw: New Version Notification for
> draft-burgin-jenkins-identity-chaining-00.txt
>
>
>
> +Dr. Kelley W Burgin 
>
> Hi, Kelley would like to respond, so I'm copying him here (he only has the
> digest of the day)
>
>
>
> On Wed, Nov 9, 2022 at 11:08 AM Warren Parad  40rhosys...@dmarc.ietf.org> wrote:
>
> I think it would be confusing for implementers to have to figure out the
> difference between this implementation and
> https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt. This
> previous one looks to add the exact same information but seems to have a
> more robust encapsulation mechanism.
>
>
>
> On Wed, Nov 9, 2022 at 10:51 AM mjje...@cyber.nsa.gov  40cyber.nsa@dmarc.ietf.org> wrote:
>
> Kelley and I have posted a draft to describe what we are trying to
> accomplish within the Fine-Grained Authorization sub-group.
>
>
>
> Mike Jenkins
>
> NSA-CCSS
> --
>
> *From:* internet-dra...@ietf.org 
> *Sent:* Tuesday, November 8, 2022 7:13 AM
> *To:* Kelley Burgin ; Michael Jenkins (GOV) <
> mjje...@cyber.nsa.gov>; Michael Jenkins (GOV) 
> *Subject:* New Version Notification for
> draft-burgin-jenkins-identity-chaining-00.txt
>
>
>
>
> A new version of I-D, draft-burgin-jenkins-identity-chaining-00.txt
> has been successfully submitted by Mike Jenkins and posted to the
> IETF repository.
>
> Name:   draft-burgin-jenkins-identity-chaining
> Revision:   00
> Title:  OAuth Identity Chaining
> Document date:  2022-11-08
> Group:  Individual Submission
> Pages:  7
> URL:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-burgin-jenkins-identity-chaining-00.txtdata=05%7C01%7Cmjjenki%40cyber.nsa.gov%7Cda6b9b2940184949b7ad08dac182bfa2%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638035064561336774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=bhueo%2BvPkNBZmY5k7jAurvtu29btVjewGiNEsphI33Q%3Dreserved=0
> Status:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-burgin-jenkins-identity-chaining%2Fdata=05%7C01%7Cmjjenki%40cyber.nsa.gov%7Cda6b9b2940184949b7ad08dac182bfa2%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638035064561336774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=X%2BimOqs3Vwyw9ckZ64dBJ2fvVotkdT5o10IFZ6zjqhY%3Dreserved=0
> Html:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-burgin-jenkins-identity-chaining-00.htmldata=05%7C01%7Cmjjenki%40cyber.nsa.gov%7Cda6b9b2940184949b7ad08dac182bfa2%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638035064561336774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=tHYIgMY6dYUJp0%2FjD9Fyu7dMdWHZSIUMv9YYzdZOI0g%3Dreserved=0
> Htmlized:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-burgin-jenkins-identity-chainingdata=05%7C01%7Cmjjenki%40cyber.nsa.gov%7Cda6b9b2940184949b7ad08dac182bfa2%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638035064561336774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=nUdyXxQm1Q4K%2FKYF6ROhhU1vmCnCBa5RTSM7U6BMks0%3Dreserved=0
>
>
> Abstract:
>This specification defines a new OAuth claim that allows a proxying
>OAuth client to pass identity information for a different OAuth
>client to an OAuth authorization server during a token request.  The
>authorization server uses this additional identity information whe

Re: [OAUTH-WG] Fw: New Version Notification for draft-burgin-jenkins-identity-chaining-00.txt

[Warren Parad]

I think it would be confusing for implementers to have to figure out the
difference between this implementation and
https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt. This
previous one looks to add the exact same information but seems to have a
more robust encapsulation mechanism.

On Wed, Nov 9, 2022 at 10:51 AM mjje...@cyber.nsa.gov  wrote:

> Kelley and I have posted a draft to describe what we are trying to
> accomplish within the Fine-Grained Authorization sub-group.
>
> Mike Jenkins
> NSA-CCSS
> --
> *From:* internet-dra...@ietf.org 
> *Sent:* Tuesday, November 8, 2022 7:13 AM
> *To:* Kelley Burgin ; Michael Jenkins (GOV) <
> mjje...@cyber.nsa.gov>; Michael Jenkins (GOV) 
> *Subject:* New Version Notification for
> draft-burgin-jenkins-identity-chaining-00.txt
>
>
> A new version of I-D, draft-burgin-jenkins-identity-chaining-00.txt
> has been successfully submitted by Mike Jenkins and posted to the
> IETF repository.
>
> Name:   draft-burgin-jenkins-identity-chaining
> Revision:   00
> Title:  OAuth Identity Chaining
> Document date:  2022-11-08
> Group:  Individual Submission
> Pages:  7
> URL:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-burgin-jenkins-identity-chaining-00.txtdata=05%7C01%7Cmjjenki%40cyber.nsa.gov%7Cda6b9b2940184949b7ad08dac182bfa2%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638035064561336774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=bhueo%2BvPkNBZmY5k7jAurvtu29btVjewGiNEsphI33Q%3Dreserved=0
> Status:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-burgin-jenkins-identity-chaining%2Fdata=05%7C01%7Cmjjenki%40cyber.nsa.gov%7Cda6b9b2940184949b7ad08dac182bfa2%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638035064561336774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=X%2BimOqs3Vwyw9ckZ64dBJ2fvVotkdT5o10IFZ6zjqhY%3Dreserved=0
> Html:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-burgin-jenkins-identity-chaining-00.htmldata=05%7C01%7Cmjjenki%40cyber.nsa.gov%7Cda6b9b2940184949b7ad08dac182bfa2%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638035064561336774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=tHYIgMY6dYUJp0%2FjD9Fyu7dMdWHZSIUMv9YYzdZOI0g%3Dreserved=0
> Htmlized:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-burgin-jenkins-identity-chainingdata=05%7C01%7Cmjjenki%40cyber.nsa.gov%7Cda6b9b2940184949b7ad08dac182bfa2%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638035064561336774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=nUdyXxQm1Q4K%2FKYF6ROhhU1vmCnCBa5RTSM7U6BMks0%3Dreserved=0
>
>
> Abstract:
>This specification defines a new OAuth claim that allows a proxying
>OAuth client to pass identity information for a different OAuth
>client to an OAuth authorization server during a token request.  The
>authorization server uses this additional identity information when
>populating the "client_id" and "cnf" fields of the returned access
>token instead of the identity information about the proxying client
>requesting the token.
>
>
>
>
>
> The IETF Secretariat
>
>
> ___
> 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

Re: [OAUTH-WG] WGLC for Step-up Authentication

[Warren Parad]

t-3
>> <https://mailarchive.ietf.org/arch/msg/oauth/SsollGVV01oPmYYTef25-SYVYok/>
>> .
>>
>> *Item No 1*: Striking at the core of OAuth 2.0 idea by coupling end user
>> authentication with authorization.
>> *Follow-up Comments-v3*. My original concern was the introduction of
>> tight coupling between end user authentication and the OAuth 2.0. It was
>> explained by Brian that the draft RFC does not intend to introduce any
>> coupling and just provides a channel of signal/information flow between AS
>> and RS via client app. It is just that the signal as of now only contains
>> data on the end-user authentication. This seems to be a
>> reasonable explanation and the point is not pressed further. However, this
>> has raised two sub concerns. One is mentioned in Item No5, so I am not
>> taking it up here.
>>
>> The other remaining sub concern is the complexity introduced due to the
>> introduction of the new channel. If we look from the higher level of
>> abstraction, earlier the events concerned were handled at the
>> interface/entry level, now the information about the events is passed on to
>> the other components of the system . All the other components may handle
>> the events as per their policies and can be out of sync with each other.
>>
>> Coming back to OAuth 2.0, earlier the authentication complexities were
>> handled by AS as per OIDC specs. Now, with the introduction of this
>> channel, the authentication event information is being passed on to the RS.
>> The requirement/behaviour of RS may not be in sync with the requirements of
>> AS. I had given a hypothetical example of one such complexity in my email
>> part-3. Just to give another flavour of the complexity I am quoting from
>> Section 5 of the draft RFC which acknowledges the existence of loops being
>> handled by OIDC specs.
>>
>> The recommended behavior will help prevent clients getting stuck in a
>>> loop where the authorization server keeps returning tokens that the
>>> resource server already identified as not meeting its requirements hence
>>> known to be rejected as well.
>>
>>
>> If the esteemed members are of the view that the benefits accrued are
>> more than the complexity introduced we can close the concern and move
>> ahead. I would request the members to give their views.
>>
>>
>> On Mon, Oct 24, 2022 at 3:51 PM Warren Parad  wrote:
>>
>>> I get the sense we are diverging from a resolution to your questions
>>> rather that converging on one.  Given that some of the items reference each
>>> other, would it be possible for you to prioritize which item you are most
>>> concerned with? Then we could work through that one and then move on to the
>>> next point. By this email I'm now lost on the current issues with the spec
>>> from your perspective which makes it hard, at least for me, to continue
>>> this conversation.
>>>
>>> Is item 1 the primary concern you want to discuss or is it something
>>> else?
>>>
>>> On Mon, Oct 24, 2022, 07:52 Jaimandeep Singh <
>>> jaimandeep.phdc...@nfsu.ac.in> wrote:
>>>
>>>> Dear Brian, Warren and Vittorio,
>>>>
>>>> Thank You for taking out time and efforts in giving the detailed
>>>> explanation. After spending considerable time on the explanations provided,
>>>> my follow-up comments are given below for the considered view of the
>>>> esteemed members. The original comments are at part1
>>>> <https://mailarchive.ietf.org/arch/msg/oauth/rNqEACxVM1OtDfT5SIQDybSK6kk/>
>>>> and part2
>>>> <https://mailarchive.ietf.org/arch/msg/oauth/U8c9JfHCnmcbX238zXWTuRgx2BE/>
>>>> .
>>>>
>>>> *Item No 1*: Striking at the core of OAuth 2.0 idea by coupling end
>>>> user authentication with authorization.
>>>> *Follow-up Comments-v2*.
>>>>
>>>>> by allowing a resource server to signal to a client that the
>>>>> authentication event associated with the access token of the current
>>>>> request doesn't meet its requirements (however the RS determines that) and
>>>>> convey that to the AS in the authorization request (via the user's 
>>>>> browser)
>>>>> to remediate.
>>>>
>>>> In my view we are creating an information/signal channel between AS and
>>>> RS via client app. Both AS and RS may or may not act on this
>>>> information/signal depending upon their policies and is out of the scope of

Re: [OAUTH-WG] WGLC for Step-up Authentication

[Warren Parad]

 in the original RFC 6749 without the need of the term
> "Freshness".
>
> *Item No 5*: Why not include client app parameters in the signal flow?
> *Comments*. Vittorio's answer to Yusuf's email dated 13 Oct 2022.
>
>> During the discussion we did inquire on other parameters/aspects that
>> would have the same direct applicability but nothing was identified.
>
> We may consider including various parameters of the client app in the
> step-up as it is intrinsic to the OAuth 2.0 specs and plays a big role in
> how the permission is granted for restricted scopes.
>
> Let us see how Google handles the restricted scopes. Refer here
> <https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification>
> .
>
>> The Gmail and Fit APIs limit the apps that can seek permission to access
>> consumer data. These additional requirements for restricted scopes require
>> an app to demonstrate that they're a permitted application type and to
>> submit to additional reviews, which include a possible security assessment
>> by a third-party auditor.
>
> Here, the problem of restricted or sensitive scopes is handled through
> security assessment of the apps requesting these scopes.
>
> The signal related to the client app could therefore carry the following
> information:
> a. Type of client app
> b. How has it been identified i.e using basic authentication, mTLS or
> other such techniques.
> c. Security assessment of the client app
>
> Wishing everyone a Happy Diwali
>
>
>
> On Sat, Oct 22, 2022 at 12:49 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> Thanks Warren, it's a good reminder about REQUIRED/MUST/etc meaning in
>> the context of the given document.
>>
>> As far as references are concerned. IETF documents can reference non-IETF
>> documents. It's not at all uncommon. And a number of OAuth RFCs and
>> in-progress drafts do already reference OIDC; draft-ietf-oauth-v2-1,
>> draft-ietf-oauth-security-topics, rfc9068, rfc8725, rfc9101, rfc9126,
>> rfc9207 being just a partial list.
>>
>>
>> On Fri, Oct 21, 2022 at 6:39 AM Warren Parad > 40rhosys...@dmarc.ietf.org> wrote:
>>
>>> REQUIRED always means "in the context of the RFC".
>>>
>>> I fully agree to your statement that 'existing implementations aren't
>>>> expected to comply with the new specification'. However, the point I am
>>>> making is that we cannot be biased towards OIDC specifications and leave
>>>> others non-compliant. We have to make future specifications such that it
>>>> doesn't favour one over other.
>>>
>>>
>>> Regarding OAuth 2.0 references, we already have a AS metadata parameter
>>> and the AS doesn't have to return the acr values, which in itself is a
>>> signal. So switching the expectations to OPTIONAL, in my opinion would be a
>>> mistake. We aren't leaving others as "non-compliant". Sure they are
>>> "non-compliant" with this new RFC, but they aren't "non-compliant" with
>>> regards to OIDC nor OAuth2.0.
>>>
>>> On the flip side, I'm not sure how I feel about directly referencing the
>>> implementations found in OIDC. If there is a pattern we wish to adapt, it
>>> does follow for me that we explicitly document that pattern within the RFC
>>> and not link to the OIDC reference.
>>>
>>>
>>> On Fri, Oct 21, 2022 at 2:04 PM Jaimandeep Singh >> 40nfsu.ac...@dmarc.ietf.org> wrote:
>>>
>>>> Dear Vittorio,
>>>>
>>>> Thankyou for the detailed reply. My follow-on suggestions and
>>>> recommendations are given below for kind consideration please [The original
>>>> suggestions can be found here
>>>> <https://mailarchive.ietf.org/arch/msg/oauth/rNqEACxVM1OtDfT5SIQDybSK6kk/>
>>>> ]:
>>>>
>>>> *Item No 1*: Striking at the core of OAuth 2.0 idea by coupling end
>>>> user authentication with authorization.
>>>> *Follow-on Comment*: Thx for bringing out that RFC 9068 already has
>>>> "acr'' as a claim. However, it is an OPTIONAL claim, whereas section 5 of
>>>> the draft RFC recommends it to be a required parameter. Notwithstanding, in
>>>> my view, the proposed draft is challenging the very premises of OAuth 2.0
>>>> by strongly coupling the authorization layer with the end user
>>>> authentication. The OAuth 2.0 is supposed to be agnostic to the end user
>>>> authentication. Are we comfortabl

Re: [OAUTH-WG] WGLC for Step-up Authentication

[Warren Parad]

REQUIRED always means "in the context of the RFC".

I fully agree to your statement that 'existing implementations aren't
> expected to comply with the new specification'. However, the point I am
> making is that we cannot be biased towards OIDC specifications and leave
> others non-compliant. We have to make future specifications such that it
> doesn't favour one over other.


Regarding OAuth 2.0 references, we already have a AS metadata parameter and
the AS doesn't have to return the acr values, which in itself is a signal.
So switching the expectations to OPTIONAL, in my opinion would be a
mistake. We aren't leaving others as "non-compliant". Sure they are
"non-compliant" with this new RFC, but they aren't "non-compliant" with
regards to OIDC nor OAuth2.0.

On the flip side, I'm not sure how I feel about directly referencing the
implementations found in OIDC. If there is a pattern we wish to adapt, it
does follow for me that we explicitly document that pattern within the RFC
and not link to the OIDC reference.


On Fri, Oct 21, 2022 at 2:04 PM Jaimandeep Singh  wrote:

> Dear Vittorio,
>
> Thankyou for the detailed reply. My follow-on suggestions and
> recommendations are given below for kind consideration please [The original
> suggestions can be found here
> 
> ]:
>
> *Item No 1*: Striking at the core of OAuth 2.0 idea by coupling end user
> authentication with authorization.
> *Follow-on Comment*: Thx for bringing out that RFC 9068 already has
> "acr'' as a claim. However, it is an OPTIONAL claim, whereas section 5 of
> the draft RFC recommends it to be a required parameter. Notwithstanding, in
> my view, the proposed draft is challenging the very premises of OAuth 2.0
> by strongly coupling the authorization layer with the end user
> authentication. The OAuth 2.0 is supposed to be agnostic to the end user
> authentication. Are we comfortable with this coupling?
> *Recommendation*: The draft RFC should be made informational. If that is
> out of scope then all the proposed claims, parameters and headers should be
> made OPTIONAL.
>
> *Item No 2*: Punching a security hole by requiring AS to act on
> information provided by the client applications (Reverse Flow).
> *Follow-on Comment*: I would like to differ on this view. The client
> applications do require authentication in case of confidential clients
> (Refer Section 2.3 of RFC 6749). I would also like to point towards the
> Google OAuth 2.0 page which talks about 'creation of authorization
> credentials' by the client applications and can be accessed here
> .
>The point I am making is that the client application needs to
> authenticate itself with the OAuth 2.0 endpoint before starting the
> communication. Also, making AS act on information provided by
> client applications may lead to future vulnerabilities as client
> applications are not considered 'trusted' especially when we follow zero
> trust architecture.
> *Recommendation*.
>
> a. The example given in section 4 of draft RFC be updated to reflect the
> need of complete authentication of the client application before the
> "acr_values" or "max_age" values are accepted or acted upon by the OAuth
> 2.0 endpoint.
> b. Need for signing these values by the RS which can be verified by the
> AS. Therefore, we need to look at ways by which the RS returns a signed JWT
> token containing "acr_values" or other such claims which should also be
> opaque to the client applications.
>
>
> *Item No 3*: Forcing AS to implement OIDC specifications will render
> existing implementations non-compliant.
> *Follow-on Comment*: I fully agree to your statement that 'existing
> implementations aren't expected to comply with the new specification'.
> However, the point I am making is that we cannot be biased towards OIDC
> specifications and leave others non-compliant. We have to make future
> specifications such that it doesn't favour one over other.
> *Recommendations*: All the proposed claims, parameters and headers should
> be made OPTIONAL.
>
> *Item No 4*: How much “Freshness” is fresh?
> *Follow-on Comment*: The *term* "freshness" may have earlier precedent
> but the context is different.
> *Recommendation*. Let's not use a term which cannot be quantified and is
> open to different interpretations by readers/implementers.
>
> Kind Regards
> Jaimandeep Singh
>
> On Fri, Oct 21, 2022 at 2:53 AM Vittorio Bertocci  40auth0@dmarc.ietf.org> wrote:
>
>> Hi Jaimandeep,
>> I have a bit of cognitive whiplash - your first message professed strong
>> support for this work, further reinforced by a LinkedIn post where you
>> mentioned that your own paper supports the ideas expressed in this spec
>> (not linking it because it's gone, but I have a screenshot)- whereas in
>> your latest message you raise objections that question the very
>> existence of this document... anyway, 

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad]

So the executive summary is "JWP does solve this problem, but that work
isn't close to being able to provide a solution yet" Or is it something
else?

On Fri, Aug 5, 2022 at 5:22 PM David Waite  wrote:

> I can’t speak to what group or charter the JWP work would eventually be
> under, but the JWT specification is one of several examples of a
> specification that heavily leveraged the JOSE work but which was started
> here at OAUTH, outside of the (at the time active) JOSE WG.
>
> Without perusing old email archives across two groups, I speculate that
> this is because JWTs are at a different layer than JOSE - the JOSE
> specifications defined algorithms and serializations for cryptographic
> messages, while JWT defined (generalized) application-layer semantics. JWS
> and JWE allows for arbitrary binary payloads, while JWT mandates a specific
> document format - a JSON object of higher-layer security and subject
> claims.
>
> Likewise, other groups and individuals outside of OAUTH have further
> defined how to process JWTs for their own specific application space, just
> like OAUTH produced a specification recommending how to use JWTs for access
> tokens.
>
> To have SD-JWT under the JOSE group (or another JWP group) would mean that
> it was chartered to define such application-layer semantics, in addition to
> the lower layer work of specifying algorithms and serialization of
> cryptographic data.
>
> SD-JWT is an incremental addition on top of JWTs; while it does need a new
> compact representation to express additional information, the idea is that
> it can be implemented as incremental logic on top of existing JWT
> processing libraries. This is core to the current design, and why there are
> already multiple implementations of the draft.
>
> JWP does envision a different approach from SD-JWT, where you have the
> concept of multiple (potentially binary) payloads as part of the core data
> model and serializations. A JWT/SD-JWT equivalent (such as JPTs -
> https://www.ietf.org/id/draft-jmiller-jose-json-proof-token-00.html )
> would define how claims are mapped to particular payloads in a JWP.
>
> To avoid going too deeply into my own biases here, I think the approach
> defined by JWP has many benefits. However, that work is just beginning.
>
> Similar to how the work on TLS 1.3 didn’t stop people from specifying new
> capabilities for TLS 1.2, I don’t think the eventual goals of JWP+JPT
> should detract from specifying SD-JWT.
>
> -DW
>
> On Aug 5, 2022, at 3:28 AM, Warren Parad  40rhosys...@dmarc.ietf.org> wrote:
>
> Maybe they have a good reason for not wanting it, and then we shouldn't be
> the WG that backdoor's it in. Also: "other people have already implemented
> it" is a cognitive fallacy, so let's not use that as a justification we
> have to make the standard.
>
> We should get a concrete reason why a WG that seems like the appropriate
> one, thinks it wouldn't make sense. If it is just a matter of timing, then
> whatever. But if there are concrete recommendations from that group, I
> would love to hear them.
>
> On Fri, Aug 5, 2022 at 10:26 AM Daniel Fett  40danielfett...@dmarc.ietf.org> wrote:
>
>> Am 05.08.22 um 10:22 schrieb Warren Parad:
>>
>> > and nobody involved in the JWP effort thinks that SD-JWT should be in
>> that WG once created
>>
>> Why?
>>
>> For the reasons listed, I guess?
>>
>> Also, mind the "As far as I am aware" part, but I don't remember any
>> discussions in that direction at IETF114.
>>
>> -Daniel
>>
>> ___
>> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad]

Can you list them out succinctly, because I don't feel like they have been?
The reason I say that, is if all the entities are online, then the AS can
directly issue the restricted token. So the only argument I can see there
is "We want to reduce the load on AS by delegating some proportion of the
AS responsibilities to the user's client". Although in that case, should we
really stop at SD-JWT, or should we go for a solution that actually allows
user-clients issued tokens to do more than share user claim values?

On Fri, Aug 5, 2022 at 3:32 PM Kristina Yasuda  wrote:

> Yes, SD-JWT is not complete and that’s exactly why we are asking for a WG
> adoption. The questions you are asking are better answered in the WG,
> post-adoption.
>
> Thank you,
> Kristina
>
> PS. Offline claim transmission is not the only “feature” of SD-JWT for all
> of the reasons that have been previously outlined in this thread.
>
> ------
> *De :* OAuth  de la part de Warren Parad  40rhosys...@dmarc.ietf.org>
> *Envoyé :* vendredi, août 5, 2022 6:25 AM
> *À :* Daniel Fett
> *Cc :* oauth@ietf.org
> *Objet :* Re: [OAUTH-WG] Call for adoption - SD-JWT
>
> It's clear that good thought has been put into the core of it, more so
> than other drafts submitted, but not yet feature complete.
>
> For example there is no sense of how the private/public key exchange
> actually happens. In *holder binding *scenario, it isn't detailed how to
> actually include the public key in the sub_jwk claim, or what a "reference"
> to the public key actually means. Is the server an AS as in OAuth?, or are
> we building on top of another token creation standard? If it is OAuth, It
> isn't clear if we need a new indicator in the token response that tells us
> that the salt container is attached to the token and that it shouldn't
> blindly be passed along. It isn't clear from this discussion if we need
> token revocation.
>
> Assuming it is the OAuth token exchange that we are building on top of,
> there are lots of open questions of interoperability. I.e. Does the digest
> go in the access token? If it isn't OAuth, we don't have any guide on how
> to actually do the token generation, how to verify the signature of the
> token with the digest, and I'm sure there are more things.
>
> We don't need to have both in the same WG, that wasn't my point, the point
> is if there is a concrete reason that others aren't working on it, I wanted
> to know why. There are JWPs, I don't know anything about them, but it
> doesn't really matter if they have different approaches, different cryptos,
> etc... Let's look at the features, that's at the core of what matters. So
> far the only feature we've been able to nail down is *offline claim
> transmission*. Will JWPs support *offline claim transmission*?
>
> On Fri, Aug 5, 2022 at 11:55 AM Daniel Fett  40danielfett...@dmarc.ietf.org> wrote:
>
>> It's not that the people I have spoken to didn't like the idea of SD-JWT.
>> It's just on a different layer than JWPs, using a different approach,
>> different crypto, providing different features, and on a different
>> timeline. There's no compelling reason to have both in the same WG. There
>> are nonetheless good reasons to have SD-JWT. Having SD-JWT in OAuth WG is
>> not an attempt to "backdoor" anything in!
>>
>> I also didn't say that we should adopt SD-JWT because it has been
>> implemented. You took my statement out of context. I wanted to underline
>> that the spec is practically feature-complete and can be implemented today,
>> providing the features promised. Meanwhile, JWP is not there yet.
>>
>> But, SD-JWT is not in production yet. If the OAuth WG decides that
>> substantial changes are required, now is the best time for that.
>>
>> Also, I wanted to highlight with my statement that SD-JWT is easy to
>> implement due to its simplicity.
>>
>> -Daniel
>>
>> Am 5. August 2022 11:28:49 MESZ schrieb Warren Parad > 40rhosys...@dmarc.ietf.org>:
>>>
>>> Maybe they have a good reason for not wanting it, and then we shouldn't
>>> be the WG that backdoor's it in. Also: "other people have already
>>> implemented it" is a cognitive fallacy, so let's not use that as a
>>> justification we have to make the standard.
>>>
>>> We should get a concrete reason why a WG that seems like the appropriate
>>> one, thinks it wouldn't make sense. If it is just a matter of timing, then
>>> whatever. But if there are concrete recommendations from that group, I
>>> would love to hear them.
>>>
>>> On Fri, Aug 5, 2022 at 

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad]

It's clear that good thought has been put into the core of it, more so than
other drafts submitted, but not yet feature complete.

For example there is no sense of how the private/public key exchange
actually happens. In *holder binding *scenario, it isn't detailed how to
actually include the public key in the sub_jwk claim, or what a "reference"
to the public key actually means. Is the server an AS as in OAuth?, or are
we building on top of another token creation standard? If it is OAuth, It
isn't clear if we need a new indicator in the token response that tells us
that the salt container is attached to the token and that it shouldn't
blindly be passed along. It isn't clear from this discussion if we need
token revocation.

Assuming it is the OAuth token exchange that we are building on top of,
there are lots of open questions of interoperability. I.e. Does the digest
go in the access token? If it isn't OAuth, we don't have any guide on how
to actually do the token generation, how to verify the signature of the
token with the digest, and I'm sure there are more things.

We don't need to have both in the same WG, that wasn't my point, the point
is if there is a concrete reason that others aren't working on it, I wanted
to know why. There are JWPs, I don't know anything about them, but it
doesn't really matter if they have different approaches, different cryptos,
etc... Let's look at the features, that's at the core of what matters. So
far the only feature we've been able to nail down is *offline claim
transmission*. Will JWPs support *offline claim transmission*?

On Fri, Aug 5, 2022 at 11:55 AM Daniel Fett  wrote:

> It's not that the people I have spoken to didn't like the idea of SD-JWT.
> It's just on a different layer than JWPs, using a different approach,
> different crypto, providing different features, and on a different
> timeline. There's no compelling reason to have both in the same WG. There
> are nonetheless good reasons to have SD-JWT. Having SD-JWT in OAuth WG is
> not an attempt to "backdoor" anything in!
>
> I also didn't say that we should adopt SD-JWT because it has been
> implemented. You took my statement out of context. I wanted to underline
> that the spec is practically feature-complete and can be implemented today,
> providing the features promised. Meanwhile, JWP is not there yet.
>
> But, SD-JWT is not in production yet. If the OAuth WG decides that
> substantial changes are required, now is the best time for that.
>
> Also, I wanted to highlight with my statement that SD-JWT is easy to
> implement due to its simplicity.
>
> -Daniel
>
> Am 5. August 2022 11:28:49 MESZ schrieb Warren Parad  40rhosys...@dmarc.ietf.org>:
>>
>> Maybe they have a good reason for not wanting it, and then we shouldn't
>> be the WG that backdoor's it in. Also: "other people have already
>> implemented it" is a cognitive fallacy, so let's not use that as a
>> justification we have to make the standard.
>>
>> We should get a concrete reason why a WG that seems like the appropriate
>> one, thinks it wouldn't make sense. If it is just a matter of timing, then
>> whatever. But if there are concrete recommendations from that group, I
>> would love to hear them.
>>
>> On Fri, Aug 5, 2022 at 10:26 AM Daniel Fett > 40danielfett...@dmarc.ietf.org> wrote:
>>
>>> Am 05.08.22 um 10:22 schrieb Warren Parad:
>>>
>>> > and nobody involved in the JWP effort thinks that SD-JWT should be in
>>> that WG once created
>>>
>>> Why?
>>>
>>> For the reasons listed, I guess?
>>>
>>> Also, mind the "As far as I am aware" part, but I don't remember any
>>> discussions in that direction at IETF114.
>>>
>>> -Daniel
>>>
>>> ___
>>> 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

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad]

Maybe they have a good reason for not wanting it, and then we shouldn't be
the WG that backdoor's it in. Also: "other people have already implemented
it" is a cognitive fallacy, so let's not use that as a justification we
have to make the standard.

We should get a concrete reason why a WG that seems like the appropriate
one, thinks it wouldn't make sense. If it is just a matter of timing, then
whatever. But if there are concrete recommendations from that group, I
would love to hear them.

On Fri, Aug 5, 2022 at 10:26 AM Daniel Fett  wrote:

> Am 05.08.22 um 10:22 schrieb Warren Parad:
>
> > and nobody involved in the JWP effort thinks that SD-JWT should be in
> that WG once created
>
> Why?
>
> For the reasons listed, I guess?
>
> Also, mind the "As far as I am aware" part, but I don't remember any
> discussions in that direction at IETF114.
>
> -Daniel
>
> ___
> 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

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad]

o that problem. I don’t see how the
>> issuer could learn where a credential is being used with revocation lists
>> as the verifier will just download the whole list for evaluation and
>> revocation lists typically do not authenticate the verifier. Which leaves
>> the IP address of the verifier as metadata without any further context.
>>
>> True, a well designed revocation scheme leaks less information to the IDP.
>>
>>
>> I think the issuer part of it is more complex than people currently
>> believe since issuers need to maintain a list of the credentials they
>> issued (not needed in OIDC). Updates to credential data need to be
>> published and last but not least, there needs to be away to let credentials
>> be revoked. E.g. an user or a wallet provider might need to ask an issuer
>> to revoke a certain credential because of abuse.
>>
>> Does this not imply that the IDP has to always on for the user to report
>> a problem??? Which was something you wanted to escape from.
>>
>>
>> That’s gone be though.
>>
>> Seems like the above was a typo.
>>
>>
>>
>> That might be the reason why ISO mDL uses expiration (I guess weeks to
>> month) instead of revocation. And the wheel starts to turn again …
>>
>>
>> Exactly. Because there is no perfect solution, but only one that
>> compromises one feature for another. So in the end if the users decide
>> which is preferrable, it will mean that usability wins and trumps security
>> and privacy concerns!! If service providers decide they may opt for hard
>> fails with security and privacy trumping usability.
>>
>> Which brings me to the conclusion that long lived one-time use VCs with
>> soft revocation (i.e. continue as if everything is OK if revocation info is
>> not available) with blinded property names and values is the best
>> compromise from a usability perspective i.e. one time use privacy enhanced
>> SD-JWTs. I wonder how many wallets can currently handle this? I guess zero
>> at the moment, but its an objective worth aiming for. Alternatively short
>> lived one-time use VCs with no revocation, that are issued periodically or
>> on demand (dependent upon the validity period) is the best option from a
>> security and privacy perspective. If the IDP is not available the user will
>> not be able to do any work once his stock of short lived credentials are
>> exhausted.
>>
>> Do you agree?
>>
>> Kind regards
>>
>> David
>>
>> Kind regards
>>
>> David
>> On 02/08/2022 10:47, Torsten Lodderstedt wrote:
>>
>>
>> Am 02.08.2022 um 11:06 schrieb Warren Parad :
>>
>> I was following your train of thought, let me paste that here for
>> transparency, you specifically said:
>>
>>> In an OAuth scenario, the user‘s wallet would act as AS and issue access
>>> tokens (those could be short lived) that effectively are verifiable
>>> presentations (based on a verifiable credential) audience restricted for a
>>> certain RS. The client wouldn’t even know it’s a verifiable presentation
>>> since the access token is opaque to the client.
>>
>>
>> Which I replied:
>>
>>> If the user's wallet acts as the AS issuing tokens, then there is zero
>>> need for this draft because we could pass the *scopes* that relate to
>>> the claims directly to the AS, and have the AS return a limited JWT, and we
>>> would actually do that every time because:
>>>
>>>1. we can
>>>2. because the tokens have short lifetime
>>>
>>> So that isn't a valid argument, unless there's a reason why the AS
>>> wouldn't be able to do this.
>>
>>
>> In this conversation, I'm still not able to parse what you are saying.
>> Yes, of course the user having a physical device (as the AS) to issue
>> tokens is privacy enhancing, but then we don't need this draft as I just
>> proved. Or are you talking about a different point?
>>
>>
>> In the model I envision, OAuth clients are able to obtain access tokens
>> for the user’s services through the user’s wallet. Since the wallet is not
>> the AS the RS trusts, I would like to utilize verifiable credentials as
>> basis for issuing access tokens from the wallet. That means the credential
>> is issued by the AS and the wallet can mint access tokens containing a
>> presentation of such a credential. From a RSs standpoint this retains the
>> standard trust model since the RS only accepts access tokens containing a
>> credential from an AS it trusts.
>>
>

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad]

In the case we do that, this spec doesn't add value, right?

On Tue, Aug 2, 2022, 13:39 David Chadwick <
d.w.chadw...@verifiablecredentials.info> wrote:

> Hi Warren
>
> I am speaking about the verifiable credential issuing process where the
> user/wallet is the client and the credential issuing system is the
> authoriser and operates the AS and RS. (This is the model describes in the
> OIDC4VCI spec.)
>
> So the AS issues the access token to the user/wallet. This is then sent to
> the RS to obtain the verifiable credential. So I was asserting that if the
> user/wallet has an access token for a complete verifiable credential, then
> it should be able to ask for a set of subset credentials either
> concurrently or sequentially, dependent upon the policy of the RS.
>
> Does this make sense to you now?
>
> Kind regards
>
> David
> On 01/08/2022 18:24, Warren Parad wrote:
>
> Hey David, would you be able to go back and reread what you wrote? I'm
> trying to parse it and it seems what you are calling different things don't
> align to the common understanding of what AS/RS/client mean.
>
> For instance:
>
>- the user, not the AS, authorizes a client to attain credentials
>- the client doesn't ask the RS for anything other than the managed
>resources using the credentials
>- the client in this case is likely a hardware device that runs the
>user-agent so in practice it will have and know 100% of the user's data
>- AS issues credentials, that is its job, saying "it shouldn't be
>involved" is the same as saying "I don't want to use OAuth for this" (which
>is fine, but likely that's the important part)
>- RS doesn't decide HOW it decides IF, the HOW is decided by the RS'
>api documentation and published expectations
>
> To avoid potential miscommunication, about what these are and how they
> work, can I suggest first outlining a concrete situation, and then
> identifying how you would expect the agents would interact with each other.
> We can do the messy part of assigning "which is the AS" and "which is the
> RS or the client" afterwards. But having the hypothetical model would go a
> long way.
>
> On Mon, Aug 1, 2022 at 6:56 PM David Chadwick <
> d.w.chadw...@verifiablecredentials.info> wrote:
>
>> Hi Aaron
>>
>> I think we have different mental models for this. In my opinion, if the
>> AS authorises the client to obtain a complete credential with all the
>> properties, then the client should be able to ask the RS for a set of
>> subsets of the credential, since the client is not obtaining more than what
>> has been authorised. I do not think that the AS should be involved in the
>> credential issuing process. It is for the RS to decide how to honour the
>> client's request.
>>
>> Kind regards
>>
>> David
>> On 01/08/2022 17:34, Aaron Parecki wrote:
>>
>> David,
>>
>> Creating "A conventional JWT with a subset of claims" is exactly the
>> thing this draft sets out to prevent needing to do. The problem with that
>> approach is the AS would have to create a new JWT with only the claims
>> needed for the particular presentation, so the AS would need to be both
>> accessible (online) by the client as well as aware of the request. These
>> are both properties avoided by the SD-JWT draft, perhaps these can be
>> clarified in the introduction.
>>
>> Aaron Parecki
>>
>>
>>
>>
>> On Mon, Aug 1, 2022 at 9:22 AM David Chadwick <
>> d.w.chadw...@verifiablecredentials.info> wrote:
>>
>>> thanks Guiseppe. Glad to hear that blinding claim names is now on the
>>> cards.
>>>
>>> This does not answer the question about why conventional JWTs with a
>>> subset of the claims cannot also be used
>>>
>>> Kind regards
>>>
>>> David
>>> On 01/08/2022 17:04, Giuseppe De Marco wrote:
>>>
>>> Hi David,
>>>
>>> This issue was already raised.
>>> Below the proposal for both draft and python code
>>>
>>> https://github.com/oauthstuff/draft-selective-disclosure-jwt/pull/124
>>>
>>> Regarding the privacy I'd like to have a combined presentation format
>>> that makes the PID/QEAA (VC) untraceable (jwe, with variable iat claim
>>> value). You find some open issues for joining in the discussion
>>>
>>> Best
>>>
>>> Il lun 1 ago 2022, 14:50 David Chadwick <
>>> d.w.chadw...@verifiablecredentials.info> ha scritto:
>>>
>>>> I would like to add a few furth

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad]

That sounds either like an abuse of SD-JWT done suboptimally when a flow
like the 509 CSR exchange would be much better or just the wrong
techonolgy. Especially since there is no reason to care if the the claims
are signed.

Second, nothing about that is offline, so the solution again is just have
multiple tokens generated at time of use.

I would really like for us to stop talking about theoretical benefits and
focus on concrete hypotheticals. Davids examples are fantastic and also
speak to the negligible value. It's nearly impossible to discuss the value
of something or whether it's the best solution using oauth, or if oauth
should be extended.

Some of us are saying "we have a situation that could use this" but upon
reviewing it, we find there are better existing alternatives. That isn't to
say there aren't good examples, just that we need to do better enumerating
these user stories.


On Tue, Aug 2, 2022, 11:47 Torsten Lodderstedt 
wrote:

>
> Am 02.08.2022 um 11:06 schrieb Warren Parad :
>
> I was following your train of thought, let me paste that here for
> transparency, you specifically said:
>
>> In an OAuth scenario, the user‘s wallet would act as AS and issue access
>> tokens (those could be short lived) that effectively are verifiable
>> presentations (based on a verifiable credential) audience restricted for a
>> certain RS. The client wouldn’t even know it’s a verifiable presentation
>> since the access token is opaque to the client.
>
>
> Which I replied:
>
>> If the user's wallet acts as the AS issuing tokens, then there is zero
>> need for this draft because we could pass the *scopes* that relate to
>> the claims directly to the AS, and have the AS return a limited JWT, and we
>> would actually do that every time because:
>>
>>1. we can
>>2. because the tokens have short lifetime
>>
>> So that isn't a valid argument, unless there's a reason why the AS
>> wouldn't be able to do this.
>
>
> In this conversation, I'm still not able to parse what you are saying.
> Yes, of course the user having a physical device (as the AS) to issue
> tokens is privacy enhancing, but then we don't need this draft as I just
> proved. Or are you talking about a different point?
>
>
> In the model I envision, OAuth clients are able to obtain access tokens
> for the user’s services through the user’s wallet. Since the wallet is not
> the AS the RS trusts, I would like to utilize verifiable credentials as
> basis for issuing access tokens from the wallet. That means the credential
> is issued by the AS and the wallet can mint access tokens containing a
> presentation of such a credential. From a RSs standpoint this retains the
> standard trust model since the RS only accepts access tokens containing a
> credential from an AS it trusts.
>
> I also assume that a single AS is managing access to several RSs as that
> was the case in almost all deployments I was involved with.
>
> I think the most efficient and flexible way to implement this scenario is
> to issue a single SD-JWT based credential and to mint RS-specific access
> token as needed by using SD-JWT’s selective disclosure capabilities. So an
> access token for the user’s contacts API would only include the claims
> needed for this service (e.g. the privilege to use the service) whereas an
> access token for the streaming API would include the data needed there
> (e.g. authorised channel lists and so on).
>
>
> On Tue, Aug 2, 2022 at 10:54 AM Torsten Lodderstedt  40lodderstedt@dmarc.ietf.org> wrote:
>
>>
>>
>> Am 02.08.2022 um 10:48 schrieb Warren Parad > 40rhosys...@dmarc.ietf.org>:
>>
>> 
>> Can you please reread what you wrote and rephrase it differently? Telling
>> us to look at the OAuth JWT RFC isn't helpful here.
>>
>>
>> You say the AS can issue an access token every time and I say the wallet
>> can issue access tokens on its own without the need to go back to the AS
>> every time again. That’s privacy enhancing and helps scalability.
>>
>> Also it isn't clear which part of your statement you are trying to
>> clarify. What does "original AS" mean? Are you suggesting a "multi AS"
>> configuration? What does that look like?
>>
>> On Tue, Aug 2, 2022 at 10:44 AM Torsten Lodderstedt > 40lodderstedt@dmarc.ietf.org> wrote:
>>
>>>
>>>
>>> Am 02.08.2022 um 10:35 schrieb Warren Parad >> 40rhosys...@dmarc.ietf.org>:
>>>
>>> 
>>> Why would we not include those seemingly critical details in the draft
>>> then?
>>>
>>>1. Let's define what a *verifiable presentation *is (is that already
>

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad]

I was following your train of thought, let me paste that here for
transparency, you specifically said:

> In an OAuth scenario, the user‘s wallet would act as AS and issue access
> tokens (those could be short lived) that effectively are verifiable
> presentations (based on a verifiable credential) audience restricted for a
> certain RS. The client wouldn’t even know it’s a verifiable presentation
> since the access token is opaque to the client.


Which I replied:

> If the user's wallet acts as the AS issuing tokens, then there is zero
> need for this draft because we could pass the *scopes* that relate to the
> claims directly to the AS, and have the AS return a limited JWT, and we
> would actually do that every time because:
>
>1. we can
>2. because the tokens have short lifetime
>
> So that isn't a valid argument, unless there's a reason why the AS
> wouldn't be able to do this.


In this conversation, I'm still not able to parse what you are saying. Yes,
of course the user having a physical device (as the AS) to issue tokens is
privacy enhancing, but then we don't need this draft as I just proved. Or
are you talking about a different point?

On Tue, Aug 2, 2022 at 10:54 AM Torsten Lodderstedt  wrote:

>
>
> Am 02.08.2022 um 10:48 schrieb Warren Parad  40rhosys...@dmarc.ietf.org>:
>
> 
> Can you please reread what you wrote and rephrase it differently? Telling
> us to look at the OAuth JWT RFC isn't helpful here.
>
>
> You say the AS can issue an access token every time and I say the wallet
> can issue access tokens on its own without the need to go back to the AS
> every time again. That’s privacy enhancing and helps scalability.
>
> Also it isn't clear which part of your statement you are trying to
> clarify. What does "original AS" mean? Are you suggesting a "multi AS"
> configuration? What does that look like?
>
> On Tue, Aug 2, 2022 at 10:44 AM Torsten Lodderstedt  40lodderstedt@dmarc.ietf.org> wrote:
>
>>
>>
>> Am 02.08.2022 um 10:35 schrieb Warren Parad > 40rhosys...@dmarc.ietf.org>:
>>
>> 
>> Why would we not include those seemingly critical details in the draft
>> then?
>>
>>1. Let's define what a *verifiable presentation *is (is that already
>>defined somewhere? I didn't see it in the draft)
>>2. Require the JWTs to be signed with a private key from a
>>certificate chain, and include the whole certificate chain in the body. (I
>>don't think there is already a RFC for this, but I could be wrong)
>>
>> Let's also talk about this comment:
>>
>>> In an OAuth scenario, the user‘s wallet would act as AS and issue access
>>> tokens (those could be short lived) that effectively are verifiable
>>> presentations (based on a verifiable credential) audience restricted for a
>>> certain RS. The client wouldn’t even know it’s a verifiable presentation
>>> since the access token is opaque to the client.
>>
>>
>> If the user's wallet acts as the AS issuing tokens, then there is zero
>> need for this draft because we could pass the *scopes* that relate to
>> the claims directly to the AS, and have the AS return a limited JWT, and we
>> would actually do that every time because:
>>
>>1. we can
>>2. because the tokens have short lifetime
>>
>> So that isn't a valid argument, unless there's a reason why the AS
>> wouldn't be able to do this.
>>
>>
>> Well, how many access tokens have you seen in the wild that only contain
>> an access token? I haven’t, any of the carriers some for of user claims,
>> e.g. a sub, in most cases some privileges/roles. Please take a look at
>> https://www.rfc-editor.org/rfc/rfc9068.html for best current practice.
>>
>> Using a VC in the way I described means the original AS doesn’t need to
>> be involved in the
>>
>>
>> On Tue, Aug 2, 2022 at 10:14 AM Torsten Lodderstedt > 40lodderstedt@dmarc.ietf.org> wrote:
>>
>>>
>>>
>>> Am 02.08.2022 um 09:53 schrieb Warren Parad >> 40rhosys...@dmarc.ietf.org>:
>>>
>>> 
>>> If we are in a offline scenario how does the verifier got ahold of the
>>> public key associated with the id token?
>>>
>>>
>>> Why id token? I would assume we are talking about verifiable
>>> presentations, right?
>>>
>>> There are a couple of ways to provide the verifier with the public key
>>> needed to verify. The (raw) key could be contained in the credential or the
>>> presentation. If a trust chain is required, a x.509 certificate could serve
>>> th

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad]

Can you please reread what you wrote and rephrase it differently? Telling
us to look at the OAuth JWT RFC isn't helpful here. Also it isn't clear
which part of your statement you are trying to clarify. What does "original
AS" mean? Are you suggesting a "multi AS" configuration? What does that
look like?

On Tue, Aug 2, 2022 at 10:44 AM Torsten Lodderstedt  wrote:

>
>
> Am 02.08.2022 um 10:35 schrieb Warren Parad  40rhosys...@dmarc.ietf.org>:
>
> 
> Why would we not include those seemingly critical details in the draft
> then?
>
>1. Let's define what a *verifiable presentation *is (is that already
>defined somewhere? I didn't see it in the draft)
>2. Require the JWTs to be signed with a private key from a certificate
>chain, and include the whole certificate chain in the body. (I don't think
>there is already a RFC for this, but I could be wrong)
>
> Let's also talk about this comment:
>
>> In an OAuth scenario, the user‘s wallet would act as AS and issue access
>> tokens (those could be short lived) that effectively are verifiable
>> presentations (based on a verifiable credential) audience restricted for a
>> certain RS. The client wouldn’t even know it’s a verifiable presentation
>> since the access token is opaque to the client.
>
>
> If the user's wallet acts as the AS issuing tokens, then there is zero
> need for this draft because we could pass the *scopes* that relate to the
> claims directly to the AS, and have the AS return a limited JWT, and we
> would actually do that every time because:
>
>1. we can
>2. because the tokens have short lifetime
>
> So that isn't a valid argument, unless there's a reason why the AS
> wouldn't be able to do this.
>
>
> Well, how many access tokens have you seen in the wild that only contain
> an access token? I haven’t, any of the carriers some for of user claims,
> e.g. a sub, in most cases some privileges/roles. Please take a look at
> https://www.rfc-editor.org/rfc/rfc9068.html for best current practice.
>
> Using a VC in the way I described means the original AS doesn’t need to be
> involved in the
>
>
> On Tue, Aug 2, 2022 at 10:14 AM Torsten Lodderstedt  40lodderstedt@dmarc.ietf.org> wrote:
>
>>
>>
>> Am 02.08.2022 um 09:53 schrieb Warren Parad > 40rhosys...@dmarc.ietf.org>:
>>
>> 
>> If we are in a offline scenario how does the verifier got ahold of the
>> public key associated with the id token?
>>
>>
>> Why id token? I would assume we are talking about verifiable
>> presentations, right?
>>
>> There are a couple of ways to provide the verifier with the public key
>> needed to verify. The (raw) key could be contained in the credential or the
>> presentation. If a trust chain is required, a x.509 certificate could serve
>> the same purpose.
>>
>> Beside that offline has different facets. In a Point of Sales scenario,
>> even though the wallet would be offline the checkout counter would most
>> likely have connectivity. That would also allow to resolve the public key
>> on demand.
>>
>>
>> They would need to be online, that defeats any benefit this could provide.
>>
>> Or what if the token you have expires. Many providers issue tokens only
>> good for 1 hour. If that expires, the user has to go through the online
>> flow again.
>>
>> Unless we can add some provisions to ensure long lived token validity, I
>> think in practice we're cripling the usefulness.
>>
>>
>> Absolutely. That’s the reason a verifiable credential has a much longer
>> lifetime simply because the user should be able to use it in a sensible
>> way. As this makes replay more likely, all verifiable credentials formats
>> utilize holder binding for reply detection. The public key mentioned above
>> is part of the cryptographic holder binding that only the legitimate user
>> is able to execute.
>>
>> In an OAuth scenario, the user‘s wallet would act as AS and issue access
>> tokens (those could be short lived) that effectively are verifiable
>> presentations (based on a verifiable credential) audience restricted for a
>> certain RS. The client wouldn’t even know it’s a verifiable presentation
>> since the access token is opaque to the client.
>>
>>
>>
>> On Tue, Aug 2, 2022, 04:21 Kristina Yasuda > 40microsoft@dmarc.ietf.org> wrote:
>>
>>> I support adoption.
>>>
>>>
>>>
>>> To add some color.
>>>
>>>
>>>
>>> One of the use-cases is a flow where issuance of a user credential
>>> (col

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad]

Why would we not include those seemingly critical details in the draft then?

   1. Let's define what a *verifiable presentation *is (is that already
   defined somewhere? I didn't see it in the draft)
   2. Require the JWTs to be signed with a private key from a certificate
   chain, and include the whole certificate chain in the body. (I don't think
   there is already a RFC for this, but I could be wrong)

Let's also talk about this comment:

> In an OAuth scenario, the user‘s wallet would act as AS and issue access
> tokens (those could be short lived) that effectively are verifiable
> presentations (based on a verifiable credential) audience restricted for a
> certain RS. The client wouldn’t even know it’s a verifiable presentation
> since the access token is opaque to the client.


If the user's wallet acts as the AS issuing tokens, then there is zero need
for this draft because we could pass the *scopes* that relate to the claims
directly to the AS, and have the AS return a limited JWT, and we would
actually do that every time because:

   1. we can
   2. because the tokens have short lifetime

So that isn't a valid argument, unless there's a reason why the AS wouldn't
be able to do this.

On Tue, Aug 2, 2022 at 10:14 AM Torsten Lodderstedt  wrote:

>
>
> Am 02.08.2022 um 09:53 schrieb Warren Parad  40rhosys...@dmarc.ietf.org>:
>
> 
> If we are in a offline scenario how does the verifier got ahold of the
> public key associated with the id token?
>
>
> Why id token? I would assume we are talking about verifiable
> presentations, right?
>
> There are a couple of ways to provide the verifier with the public key
> needed to verify. The (raw) key could be contained in the credential or the
> presentation. If a trust chain is required, a x.509 certificate could serve
> the same purpose.
>
> Beside that offline has different facets. In a Point of Sales scenario,
> even though the wallet would be offline the checkout counter would most
> likely have connectivity. That would also allow to resolve the public key
> on demand.
>
>
> They would need to be online, that defeats any benefit this could provide.
>
> Or what if the token you have expires. Many providers issue tokens only
> good for 1 hour. If that expires, the user has to go through the online
> flow again.
>
> Unless we can add some provisions to ensure long lived token validity, I
> think in practice we're cripling the usefulness.
>
>
> Absolutely. That’s the reason a verifiable credential has a much longer
> lifetime simply because the user should be able to use it in a sensible
> way. As this makes replay more likely, all verifiable credentials formats
> utilize holder binding for reply detection. The public key mentioned above
> is part of the cryptographic holder binding that only the legitimate user
> is able to execute.
>
> In an OAuth scenario, the user‘s wallet would act as AS and issue access
> tokens (those could be short lived) that effectively are verifiable
> presentations (based on a verifiable credential) audience restricted for a
> certain RS. The client wouldn’t even know it’s a verifiable presentation
> since the access token is opaque to the client.
>
>
>
> On Tue, Aug 2, 2022, 04:21 Kristina Yasuda  40microsoft@dmarc.ietf.org> wrote:
>
>> I support adoption.
>>
>>
>>
>> To add some color.
>>
>>
>>
>> One of the use-cases is a flow where issuance of a user credential
>> (collection of user claims) is decoupled from presentation (where both
>> issuance and presentation of a user credential are done using extensions of
>> OAuth flows). The goal of this decoupling is to avoid “issuer call home”,
>> where the user can send a user credential directly to the RP, without RP
>> needing to contact the Issuer directly. So the motivations are not limited
>> to offline scenarios, but are applicable to the scenarios that want to
>> recreate in the online environment, the user experience of presenting
>> credentials in-person.
>>
>>
>>
>> Driver’s Licence just happens to be an example familiar to many, and
>> there is no reason it cannot be a diploma, or an employee card, or a
>> training certificate, etc. But it is worth highlighting that SD-JWT work
>> becomes critical if we are to enable ISO-compliant mobile Driver Licences
>> expressed in JSON to enable online scenarios and make life of the Web
>> developers easier (as opposed processing data encoded as CBOR and signed as
>> a COSE message). Selective disclosure is a requirement in many government
>> issued credentials, while the usage of advanced cryptography is not always
>> encouraged by the national cybersecurity agencies.
>>
>>

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad]

If we are in a offline scenario how does the verifier got ahold of the
public key associated with the id token?

They would need to be online, that defeats any benefit this could provide.

Or what if the token you have expires. Many providers issue tokens only
good for 1 hour. If that expires, the user has to go through the online
flow again.

Unless we can add some provisions to ensure long lived token validity, I
think in practice we're cripling the usefulness.


On Tue, Aug 2, 2022, 04:21 Kristina Yasuda  wrote:

> I support adoption.
>
>
>
> To add some color.
>
>
>
> One of the use-cases is a flow where issuance of a user credential
> (collection of user claims) is decoupled from presentation (where both
> issuance and presentation of a user credential are done using extensions of
> OAuth flows). The goal of this decoupling is to avoid “issuer call home”,
> where the user can send a user credential directly to the RP, without RP
> needing to contact the Issuer directly. So the motivations are not limited
> to offline scenarios, but are applicable to the scenarios that want to
> recreate in the online environment, the user experience of presenting
> credentials in-person.
>
>
>
> Driver’s Licence just happens to be an example familiar to many, and there
> is no reason it cannot be a diploma, or an employee card, or a training
> certificate, etc. But it is worth highlighting that SD-JWT work becomes
> critical if we are to enable ISO-compliant mobile Driver Licences expressed
> in JSON to enable online scenarios and make life of the Web developers
> easier (as opposed processing data encoded as CBOR and signed as a COSE
> message). Selective disclosure is a requirement in many government issued
> credentials, while the usage of advanced cryptography is not always
> encouraged by the national cybersecurity agencies.
>
>
>
>
>
> Regarding an approach where issuer issues multiple JWTs of a same type but
> with different subset of claims, it is not an ideal way to do selective
> disclosure with JWTs (type as a way to differentiate credential with one
> data structure/syntax from another). It complicates implementations that
> try to provide RP-U unlinkability (RPs cannot collude to track the user).
> The simplest way to achieve unlinkability with JWTs without using advanced
> cryptography is to issue multiple credentials of the same type but with
> varying use identifiers and enable pairwise identifiers per RP. Now there
> are multiple copies of each JWT with subset of claims of the same type.
> This greatly complicates presentation of these credentials too – since
> credentials are of the same type, now wallet needs to manage the
> combination of a subset of claims + pairwise identifier…
>
>
>
> What if the implementation also wants predicates property, where
> age_over_XX boolean is sent instead of a birthdate string? The simplest way
> to do predicates with JWTs without using advanced cryptography is to have
> issuers to issue multiple age_over_xx booleans so that an appropriate one
> can be selectively disclosed to the RP. How many “JWTs with subset of
> claims” does the issuer needs to issue to account for all possible age
> requirements? Note that it’s not just age_over_21 to start gambling, it’s
> also age_over_65 to get pension benefits.
>
>
>
> Managing the combinatorial explosion of sets of claims in speculatively
> issued JWTs, many of which will never be used, seems unwieldy, to say the
> least. "A conventional JWT with a subset of claims" approach could be taken
> in some implementations, but it should not prevent a simpler, extensible
> alternative of SD-JWT.
>
>
>
>
>
> Finally, as Giuseppe pointed out, an option to blind claim names is on the
> table. As discussed on this list previously, we should analyze privacy
> properties of the mechanism and decide if we want to mandate it – which can
> be discussed after the adoption.
>
>
>
> Best,
>
> Kristina
>
>
>
>
>
> *From:* OAuth  *On Behalf Of * Rifaat Shekh-Yusef
> *Sent:* Thursday, July 28, 2022 8:17 PM
> *To:* oauth 
> *Subject:* [OAUTH-WG] Call for adoption - SD-JWT
>
>
>
> All,
>
>
>
> This is a call for adoption for the *SD-JWT* document
>
> https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/
> 
>
>
>
> Please, provide your feedback on the mailing list by *August 12th*.
>
>
>
> Regards,
>
>  Rifaat & Hannes
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad]

And in the situation they did, we would just use the existing scopes and
let the user approve the selected list. RS requests, AS redirects the user,
the user approves. (RS => AS => User)

The draft isn't trying to prevent needing to do that, it's trying to change
the order of the flow, first the AS, then the user, then the RS (AS => User
=> RS).

The only reason I can see doing this is if there are going to be guaranteed
offline interactions, either the AS is offline or the user is offline.

   - The AS offline is an interesting side journey. What if your country is
   taken over and the AS is really forever offline. This draft isn't going to
   fix that because the tokens expire. So unless the goal is to create never
   expiring tokens, it isn't a solution. And worse since we know attributes
   about a user do change over time, they'll have to be updatable. With the
   current draft we just update the AS and generate a new token, we can't do
   that if the AS is offline.


So the question is how many offline interactions are there, and what do
those look like? We know we are incorrectly over-engineering here if there
are only a small set of them. If there are many of these, then it makes
sense to continue down the path of "this is how we solve for the User
offline".

On Mon, Aug 1, 2022 at 7:26 PM Neil Madden 
wrote:

>
> On 1 Aug 2022, at 17:34, Aaron Parecki 
> wrote:
>
> David,
>
> Creating "A conventional JWT with a subset of claims" is exactly the thing
> this draft sets out to prevent needing to do. The problem with that
> approach is the AS would have to create a new JWT with only the claims
> needed for the particular presentation, so the AS would need to be both
> accessible (online) by the client as well as aware of the request. These
> are both properties avoided by the SD-JWT draft, perhaps these can be
> clarified in the introduction.
>
>
> But this isn’t true. As I said on the other thread on the JOSE list, the
> client doesn’t need to go back to the AS to get a new token with JWTs
> anymore than they do with SD-JWT. In the limit the AS could issue a
> separate JWT for each claim and then the client can choose which ones to
> send to the RS.
>
> Now of course if the AS actually issued a JWT for each claim that would be
> very inefficient. But in reality the client is not going to want a totally
> unique combination of claims for each presentation. There are likely just a
> small handful of sets of claims that actually make sense to disclose
> together in any scenario, so the AS could issue a small number of JWTs that
> cover those scenarios. Indeed, if the client is producing unique
> combinations of claims for a presentation then that provides a way to
> fingerprint that client/user!
>
> So far I’ve failed to see any convincing scenario where a client would
> really need such fine-grained control over selective disclosure.
>
> — Neil
>
>
> On Mon, Aug 1, 2022 at 9:22 AM David Chadwick <
> d.w.chadw...@verifiablecredentials.info> wrote:
>
>> thanks Guiseppe. Glad to hear that blinding claim names is now on the
>> cards.
>>
>> This does not answer the question about why conventional JWTs with a
>> subset of the claims cannot also be used
>>
>> Kind regards
>>
>> David
>> On 01/08/2022 17:04, Giuseppe De Marco wrote:
>>
>> Hi David,
>>
>> This issue was already raised.
>> Below the proposal for both draft and python code
>>
>> https://github.com/oauthstuff/draft-selective-disclosure-jwt/pull/124
>>
>> Regarding the privacy I'd like to have a combined presentation format
>> that makes the PID/QEAA (VC) untraceable (jwe, with variable iat claim
>> value). You find some open issues for joining in the discussion
>>
>> Best
>>
>> Il lun 1 ago 2022, 14:50 David Chadwick <
>> d.w.chadw...@verifiablecredentials.info> ha scritto:
>>
>>> I would like to add a few further points.
>>>
>>> The age-over property is more complex than your example, because a
>>> driving license only contains the date of birth. The issuing authority
>>> decides which age-over properties to statically provide in the mDL and the
>>> ISO standard provides an algorithm of how the wallet should respond if the
>>> age-over being requested is not present in the mDL. So different mDLs may
>>> contain different age-over properties and respond differently to requests
>>> for age-over from two people of the same age.
>>>
>>> The ISO mDL selective disclosure is more privacy protecting than the
>>> proposed SD-JWT because it also blinds the property names as well as the
>>> values.
>>>
>>&

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad]

Hey David, would you be able to go back and reread what you wrote? I'm
trying to parse it and it seems what you are calling different things don't
align to the common understanding of what AS/RS/client mean.

For instance:

   - the user, not the AS, authorizes a client to attain credentials
   - the client doesn't ask the RS for anything other than the managed
   resources using the credentials
   - the client in this case is likely a hardware device that runs the
   user-agent so in practice it will have and know 100% of the user's data
   - AS issues credentials, that is its job, saying "it shouldn't be
   involved" is the same as saying "I don't want to use OAuth for this" (which
   is fine, but likely that's the important part)
   - RS doesn't decide HOW it decides IF, the HOW is decided by the RS' api
   documentation and published expectations

To avoid potential miscommunication, about what these are and how they
work, can I suggest first outlining a concrete situation, and then
identifying how you would expect the agents would interact with each other.
We can do the messy part of assigning "which is the AS" and "which is the
RS or the client" afterwards. But having the hypothetical model would go a
long way.

On Mon, Aug 1, 2022 at 6:56 PM David Chadwick <
d.w.chadw...@verifiablecredentials.info> wrote:

> Hi Aaron
>
> I think we have different mental models for this. In my opinion, if the AS
> authorises the client to obtain a complete credential with all the
> properties, then the client should be able to ask the RS for a set of
> subsets of the credential, since the client is not obtaining more than what
> has been authorised. I do not think that the AS should be involved in the
> credential issuing process. It is for the RS to decide how to honour the
> client's request.
>
> Kind regards
>
> David
> On 01/08/2022 17:34, Aaron Parecki wrote:
>
> David,
>
> Creating "A conventional JWT with a subset of claims" is exactly the thing
> this draft sets out to prevent needing to do. The problem with that
> approach is the AS would have to create a new JWT with only the claims
> needed for the particular presentation, so the AS would need to be both
> accessible (online) by the client as well as aware of the request. These
> are both properties avoided by the SD-JWT draft, perhaps these can be
> clarified in the introduction.
>
> Aaron Parecki
>
>
>
>
> On Mon, Aug 1, 2022 at 9:22 AM David Chadwick <
> d.w.chadw...@verifiablecredentials.info> wrote:
>
>> thanks Guiseppe. Glad to hear that blinding claim names is now on the
>> cards.
>>
>> This does not answer the question about why conventional JWTs with a
>> subset of the claims cannot also be used
>>
>> Kind regards
>>
>> David
>> On 01/08/2022 17:04, Giuseppe De Marco wrote:
>>
>> Hi David,
>>
>> This issue was already raised.
>> Below the proposal for both draft and python code
>>
>> https://github.com/oauthstuff/draft-selective-disclosure-jwt/pull/124
>>
>> Regarding the privacy I'd like to have a combined presentation format
>> that makes the PID/QEAA (VC) untraceable (jwe, with variable iat claim
>> value). You find some open issues for joining in the discussion
>>
>> Best
>>
>> Il lun 1 ago 2022, 14:50 David Chadwick <
>> d.w.chadw...@verifiablecredentials.info> ha scritto:
>>
>>> I would like to add a few further points.
>>>
>>> The age-over property is more complex than your example, because a
>>> driving license only contains the date of birth. The issuing authority
>>> decides which age-over properties to statically provide in the mDL and the
>>> ISO standard provides an algorithm of how the wallet should respond if the
>>> age-over being requested is not present in the mDL. So different mDLs may
>>> contain different age-over properties and respond differently to requests
>>> for age-over from two people of the same age.
>>>
>>> The ISO mDL selective disclosure is more privacy protecting than the
>>> proposed SD-JWT because it also blinds the property names as well as the
>>> values.
>>>
>>> The examples below do not say why the use cases cannot work if the
>>> wallet has a set of conventional JWTs containing different commonly
>>> requested subsets of claims, such as age or address or classes of vehicle
>>> one can drive.
>>>
>>> Kind regards
>>>
>>> David
>>> On 01/08/2022 13:24, Warren Parad wrote:
>>>
>>> This is done because network availability and privacy concerns may
>>>>

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad]

>
> This is done because network availability and privacy concerns may
> separate the act of acquiring the SD-JWT of a license from the issuing
> authority, and presenting it (such as days later during a traffic stop on a
> mountain road).


I think we keep pointing to "offline drivers license" as the only reason we
have this draft. But we still haven't made clear why the "offline drivers
license" actually needs this. I spent some real time thinking about and
came up with two hypotheticals that helped me.

*Hypothetical 1:*
You are on a mountain road and a police officer pulls you over, it's late
at night, you have no internet, and your driver license is 100% digital.

The officer wants to know if you live in the area, or if you are from out
of state. You don't want to tell the police officer your name, you click
some magic buttons on your device, and a QR code pops up. This QR code
contains only:

   - "id_token" with salted fields
   - selective disclosure for: *address city + state*


The police officer's magic new special SD-JWT device tells them you have a
valid driver's license and that you live in the area. The officer is either:

   - Okay with that
   - Asks for further disclosure, which you can agree to or risk being
   arrested and brought in for questioning.


*Hypothetical 2:*
You live in the US and going out to a bar. Bars in the US are infamous for
carding people. You want to tell them that you are over 21, but don't want
to tell them anything else. So you take out your digital wallet and show
them a QR code that only contains:

   - "id_token" with salted fields
   - selective disclosure for: *over 21*

The bouncer uses their magic new SD-JWT device to verify that information,
and can either say:

   - That's sufficient, come on in
   - I don't believe that is yours, I need to see your picture (including
   details), your name as well as another form of identification.


*Problem from 2:*
The bouncer says, I need to know you have been vaccinated against covid in
the last 6 months. Here's where things start to get challenging, did the
issuer have this information available to create a claim that could be
selectively disclosed?

Do we need to maintain a registry of all the allowed claims, or are
countries some how going to be on top of this?

What happens when different countries have different "standard claims"?


On Mon, Aug 1, 2022 at 1:29 PM David Chadwick <
d.w.chadw...@verifiablecredentials.info> wrote:

>
> On 01/08/2022 11:55, Neil Madden wrote:
>
> I agree with many of these points that Jaimandeep Singh raises.
>
> It would be good to know exactly what the intended use-cases within OAuth
> are. In particular, in OAuth it’s normally the case that the client is
> relatively untrusted and a privacy goal is to avoid revealing
> information/PII to the client unnecessarily. In SD-JWT it seems that this
> is turned on its head somewhat and we trust the client (holder) with
> everything and instead want to keep some information private from the
> resource servers?
>
> I think there are also some questions about exactly which claims can be
> selectively disclosed - e.g., it would be a very bad idea to allow security
> constraints like “exp”, “aud” or “cnf” to be selectively (not) disclosed.
> But the problem is that the set of security constraints is not fixed in any
> way, and new ones may be added by future specs or application-specific
> ones. So the issuer will need to be careful not to allow such constraints
> to be selectively disclosed.
>
> Ultimately, I just don’t find this idea of fine-grained pick ’n’ mix
> selective disclosure of individual claims to be very compelling compared to
> the much simpler solution of just issuing multiple JWTs in the first place
> (with appropriate subsets of claims in them).
>
> +1. This is exactly what we do
>
> David
>
>
> — Neil
>
> On 29 Jul 2022, at 03:15, Jaimandeep Singh <
> jaimandeep.phdcs21=40nfsu.ac...@dmarc.ietf.org> wrote:
>
> Dear All,
> 1. At the outset I must compliment  Daniel Fett and Kristina Yasudafor and
> all the contributors for the wonderful work done on SD-JWT.
> 2. However, in my opinion there is no clear motivation for using SD-JWT in
> the present oAuth 2.0/2.1 ecosystem. We already have JWS and JWE which more
> or less satisfy the requirements.
> 3. The focus and time of the WG-OAUTH should be more aligned to the work
> directly impacting the improvements or BCP in the oAuth 2.0/2.1 specs.
> 4. WG-JWP (JSON Web Proofs) may be a more suitable place for the adoption
> of SD-JWT as they are working on a similar set of problems. They are
> actively seeking participation in the area of SD-JWT.
> 5. In view of above I am presently not in favour of its adoption in
> WG-OAUTH.
>
> Regards
> Jaimandeep Singh
>
> On Fri, Jul 29, 2022 at 6:43 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> I support adoption.
>>
>> On Thu, Jul 28, 2022, 8:17 PM Rifaat Shekh-Yusef 
>> wrote:
>>
>>> All,
>>>
>>> This is a call for 

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad]

I too do not support adoption.

Something is "off" for me, I don't quite get the expectation on the secure
flow, in this draft, doesn't the issuer have to know the claims that could
be requested up front? If the goal is to not have the issuer contain any of
this data, but let the holder "add in their claims in a verifiable way",
the simple solution is just sharto share the access token with the actual
data. I think I would really want to see a concrete expectation about how
this would be used.

The other part is I want to challenge that it will actually have the
benefit that we want it to have (above and beyond JWEs).

For example, let's take the cornerstone argument from the draft:

> However, when a signed JWT is
>intended to be multi-use, it needs to contain the superset of all
>claims the user might want to release to verifiers at some point.
>The ability to selectively disclose a subset of these claims
>depending on the verifier becomes crucial to ensure minimum
>disclosure and prevent verifiers from obtaining claims irrelevant for
>the transaction at hand.
>
>
We already have a parallel today with *scopes*. Normally, we expect that
there can be progressive scope increases, via new interactions with the
user agent and the AS. However, in practice, Resource Servers ask User
Agents to approve all scopes up front, and worse still AS don't allow the
user agent to select which scopes they want to grant. In practice, theory
and practice are not the same.

Selective disclosure is only a small subset of the problem posed by scopes,
because scopes actually convey permissions. If we are going to improve
anything, it should be restricting any and all data in not just the
id_token but also the access_token. And the solution could be this draft's
implementation, or maybe it is something similar to macaroons
. I don't think
this draft get's us closer to that unfortunately.

Second, I challenge the perspective of multi-use. While I completely agree
tokens are multi-use, they tend to be multi-use inside of an opaque
"platform", the user-agent interacts with RSs in the platform in an
indistinguishable way, so meaningfully, RS will request all the scopes they
know about all the time, even if they don't need them. The platform will
still request everything, and the user-agent will be forced to share the
SD-JWT-R for all the claims.

If there are multiple RS or clients involved, then the process would be to
generate multiple tokens, one for each client interaction, as we do today.
The only way out of this I can see, is like macaroons you can selectively
restrict further information for the next hop. But that's based on
delegation and legal trust, not security.

If we can have a macaroon like solution for any relevant claim in a JWT,
then I would definitely support adoption.

Alternatively, I think a much stronger solution would be to have the
encrypted claims data in the JWT, and be individually decryptable (I
haven't looked at JWEs in a while, but I didn't think that was possible)

- Warren

On Fri, Jul 29, 2022 at 2:17 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is a call for adoption for the *SD-JWT* document
> https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/
>
> Please, provide your feedback on the mailing list by *August 12th*.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> 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

Re: [OAUTH-WG] How can we define a parameter to be both OPTIONAL and REQUIRED at the same time

[Warren Parad]

Can you explain why you think:
>
> But definitely cannot be both (as in the present definition).


>From a theoretical perspective, of course it can be. But perhaps there is a
concrete reason you think otherwise, I think it would be prudent to share
that context explicitly with an explanation here. That way we aren't
opening old conversations in the middle of the meeting, and also it lets us
be prepared to understand the perspective without having to dive in on the
spot.

On Wed, Jul 27, 2022 at 2:42 PM Jaimandeep Singh  wrote:

> Dear Aaron,
>
> 1. Yesterday you brought up an important issue of choosing "redirect_uri"
> to be REQUIRED vs OPTIONAL parameter at the authorization code endpoint.
> The esteemed members had their considered opinion that the definition
> should remain as it is.
>
> 2. However, I am of the opinion that an important parameter like
> "redirect_uri" needs to be more clearly defined. It can either be OPTIONAL
> or REQUIRED, but definitely cannot be both (as in the present
> definition). Maybe Aaron can bring up the topic again for discussion in the
> side meeting for further deliberations.
>
> Regards
> Jaimandeep Singh
> ___
> 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

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

[Warren Parad]

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

Re: [OAUTH-WG] DPoP with token exchange where the subject_token and / or actor_token is also DPoP bound

[Warren Parad]

I agree this is a problem, but as I see it as a problem for Token Exchange,
and the lack of flexibility in that standard, it does not make sense to add
to the DPoP spec.

On Mon, Jul 18, 2022 at 3:33 PM Vladimir Dzhuvinov 
wrote:

> I would like to resurrect this thread and propose a new section to the
> current DPoP draft which changes nothing in regard to DPoP itself, only
> adds new parameters to enable DPoP with OAuth 2.0 token exchange (RFC 8693):
>
> https://datatracker.ietf.org/doc/html/rfc8693
>
> Why?
>
> Token exchange lets a client submit a subject_token (and potentially
> actor_token) to obtain a new token from the AS.
>
> If the submitted token(s) and the minted token are DPoP bound there is a
> need to submit a DPoP proof for each one:
>
>- A DPoP proof for the subject_token
>- Potentially a DPoP proof for the actor_token (if there is one)
>- A DPoP proof for the token that is going to be minted by the AS
>
> At present the DPoP spec defines the DPoP header in such a way that only
> one DPoP proof may be submitted.
>
>
> The proposal:
>
> A new section "DPoP with Token Exchange":
>
> Specifies the following new optional form request parameters for use in
> the token exchange grant, so that any DPoP proofs can be submitted together
> with the subject_token / actor_token as form parameters:
>
> subject_token_dpop - To pass the DPoP proof for a subject_token that is
> DPoP bound
>
> actor_token_dpop - To pass the DPoP proof for an actor_token that is DPoP
> bound
>
>
> (the existing std token exchange params can be seen here
> https://datatracker.ietf.org/doc/html/rfc8693#section-2.1 )
>
>
> Registration of a new token type identifier to indicate the token is a
> DPoP access token:
>
> https://datatracker.ietf.org/doc/html/rfc8693#section-3
>
>urn:ietf:params:oauth:token-type:dpop_access_token
>   Indicates that the token is an OAuth 2.0 DPoP bound access token issued 
> by the given authorization server.
>
>
> I hope it's not too late to include this addition to the DPoP spec. The
> token exchange grant is standard and is seeing use. With the introduction
> of DPoP it is likely such tokens will become involved in token exchanges.
> We tried a work around where the client uses a single DPoP proof for the
> submitted tokens and the one to be minted, but this has issues, including
> potential security issues. So I've come to the conclusion that a spec
> change of some sort is the proper way to solve this. The proposed solution
> has no effect on DPoP core and it preserves the existing token exchange
> semantics.
>
>
> Vladimir
>
> Vladimir Dzhuvinov
>
> On 25/06/2022 15:23, Vladimir Dzhuvinov wrote:
>
> Hi Warren,
>
> The case looks like this:
>
>- An OAuth client registered with AS1 for code flow, with AS2 for
>token exchange
>- API1 secured by AS1, API2 secured by AS2
>- For API1 the client obtains DPoP tokens from AS1
>- For API2 the client presents DPoP token from AS1 as grant at AS2 to
>obtain its own DPoP token (AS2 trusts selected AS1 token scopes for this)
>
> So we have a case where the token endpoint at AS2 needs once a DPoP proof
> for the submitted access token (in the subject_token form parameter), and a
> second time to bind the token that is going to be issued. I.e. a situation
> where the token endpoint is also "addressed" as a DPoP aware protected
> resource.
>
> If only one DPoP HTTP header is permitted one work around I see is to
> insist on a single DPoP proof for both jobs, by including the "ath" claim
> in the proof to the AS2 token endpoint and requiring the client to use the
> same JWK with both ASes. Another possibility is to include the DPoP proof
> in the form parameters alongside the subject_token, but this will require a
> spec change.
>
> Vladimir Dzhuvinov
>
> On 25/06/2022 13:33, Warren Parad wrote:
>
> What's the flow here? Assuming we are talking about RFC 8693, what's the
> situation where you would need to do a token exchange, and you actually
> have access to the subject's DPoP key? If you have access to the subject's
> key, then you are the subject and can request a new token. Or am I missing
> something fundamental here?
>
> Also, according to the RFC, the request must be made with client
> authentication, you don't need DPoP, because if the client's credentials
> are compromised, you have a different problem. Unless the goal is to DPoP
> instead of client credentials, in which case, I think I'm back to the
> previous question.
>
> On Sat, Jun 25, 2022 at 12:19 PM Vladimir Dzhuvinov <
> vladi...@connect2id.com> wrote:
>
>> I hav

Re: [OAUTH-WG] Clarifications regarding aud claim in JWT AT profile

[Warren Parad]

no?

On Mon, Jul 18, 2022 at 10:36 AM Janak Amarasena 
wrote:

> Hi Warren,
>
> Thanks for the input. By client what I meant was the application. If the
> application can be considered as a valid aud then since the AT is almost
> alway received to the application shouldn't the application be added as a
> mandatory aud for the AT (similar to the id_token)?
>
> Best Regards,
> Janak Amarasena
>
> On Fri, Jul 15, 2022 at 2:54 PM Warren Parad  wrote:
>
>> The aud claim should be the "application" or "resource server" that the
>> token would be used with, neither the authorization server nor the client
>> that receives the token should be the value.
>>
>> On Fri, Jul 15, 2022 at 7:27 AM Janak Amarasena 
>> wrote:
>>
>>> Hi,
>>>
>>> I am sending this email to clarify something I read in the JSON Web
>>> Token (JWT) Profile for OAuth 2.0 Access Tokens specification(rfc9068).
>>>
>>> Regarding the “aud” claim in the access token the specification mentions
>>> that:
>>> (https://datatracker.ietf.org/doc/html/rfc9068#section-3)
>>>
>>> "If the request does not include a "resource" parameter, the
>>> authorization server MUST use a default resource indicator in the "aud"
>>> claim. If a "scope" parameter is present in the request, the authorization
>>> server SHOULD use it to infer the value of the default resource indicator
>>> to be used in the "aud" claim."
>>>
>>> It's not quite clear what the default resource indicator should usually
>>> be. My initial thoughts were that it should either be the authorization
>>> server or the client application. However, adding the client application as
>>> the default audience feels a bit counter intuitive as the client
>>> application would not generally consume the access token itself, but rather
>>> use it to access a resource.
>>>
>>> Best Regards,
>>> Janak Amarasena
>>> ___
>>> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Clarifications regarding aud claim in JWT AT profile

[Warren Parad]

The aud claim should be the "application" or "resource server" that the
token would be used with, neither the authorization server nor the client
that receives the token should be the value.

On Fri, Jul 15, 2022 at 7:27 AM Janak Amarasena 
wrote:

> Hi,
>
> I am sending this email to clarify something I read in the JSON Web Token
> (JWT) Profile for OAuth 2.0 Access Tokens specification(rfc9068).
>
> Regarding the “aud” claim in the access token the specification mentions
> that:
> (https://datatracker.ietf.org/doc/html/rfc9068#section-3)
>
> "If the request does not include a "resource" parameter, the authorization
> server MUST use a default resource indicator in the "aud" claim. If a
> "scope" parameter is present in the request, the authorization server
> SHOULD use it to infer the value of the default resource indicator to be
> used in the "aud" claim."
>
> It's not quite clear what the default resource indicator should usually
> be. My initial thoughts were that it should either be the authorization
> server or the client application. However, adding the client application as
> the default audience feels a bit counter intuitive as the client
> application would not generally consume the access token itself, but rather
> use it to access a resource.
>
> Best Regards,
> Janak Amarasena
> ___
> 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

Re: [OAUTH-WG] .well-known/jwks.json and constrained-voucher and RFC7517

[Warren Parad]

I don't know if this is relevant, but jwks.json isn't registered, because
it doesn't have to be at that location. The
/.well-known/openid-configuration discovery document, which is registered,
uses the jwks_uri property to specify the location of the jwks. For
instance, our product doesn't have the jwks at /.well-known/jwks.json for a
lot of different reasons. Having a discovery document that points to your
jwks makes sense, ideally you would be able to use the known discovery
document at /openid-configuration, but I don't know if that is viable or
makes sense for your context.

On Tue, Jul 12, 2022 at 9:26 PM Michael Richardson 
wrote:

>
> EXEC-SUM: /.well-known/jwks.json seems in use, but not registered
>   with IANA.   I don't know if it's appropriate for my use.
>   Seems to contain RFC7517 content.
>
>
> Hi, in draft-ietf-anima-constrained-voucher we are creating a CoAP/CBOR
> version of RFC8995 (BRSKI).  One thing that we want to avoid is any extra
> keys or certificates in the constrained voucher.  If we have certificate
> chains that *do* need to be transmitted we will use x5bag.
> As BRSKI has three parties:
>MASA (signer), Registrar (audit/owner), Pledge(relying party/verifier)
>
> In general, the Pledge is built by the same entity as runs the MASA, and so
> the in the simplest form, the Pledge can be built with appropriate trust
> anchors.  (There could be PKI trust roots built-in, or self-signed EE)
> In the constrained situation, we can sign with a raw public key using CWT.
>
> The Registrar would ideally like to verify the signatures.
> The Registrar would in many cases get the right anchors to verify the
> signature via a supply chain integration.   There are other situations
> where
> a TOFU is appropriate.
>
> In either case, we'd like to automate the transfer of the keys from MASA
> to Registrar.
> In a supply chain integration, then an operator might validate the keys
> before they are activated, but online transfer makes a lot of sense to
> reduce
> errors, particularly as keys get bigger in a PQ world.
>
> It was suggested that if we just knew the manufacturer's URL, that
> /.well-known/jwks.json would work for us.  I think it would.  I see
> "documentation" at:
>https://www.baeldung.com/spring-security-openid-connect (section 6)
>https://www.baeldung.com/spring-security-oauth2-jws-jwk
>
> which seem to refer to keys in RFC7517 format.
>
> Note: We have three anchors that we might like to deploy.
>
> 1) the key that signs the RFC8366/constrained-voucher objects.
>Could be a RPK.
>
> 2) the key that signs the IDevID certificates in the devices.
>Most likely a RFC5280 self-signed certificate, but of course, it's a
> trust
>anchor, so likely only the public key matters.
>
> 3) the manufacturer could have a CA trust anchor, and #1 and #2 might be
>provided via subordinate CAs, and only #3 needs to be transfered.
>(#1 is an EE certificate)
>
> draft-richardson-anima-masa-considerations actually discusses some of the
> options here.
>
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> ___
> 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

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

[Warren Parad]

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 
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

Re: [OAUTH-WG] DPoP with token exchange where the subject_token and / or actor_token is also DPoP bound

[Warren Parad]

What's the flow here? Assuming we are talking about RFC 8693, what's the
situation where you would need to do a token exchange, and you actually
have access to the subject's DPoP key? If you have access to the subject's
key, then you are the subject and can request a new token. Or am I missing
something fundamental here?

Also, according to the RFC, the request must be made with client
authentication, you don't need DPoP, because if the client's credentials
are compromised, you have a different problem. Unless the goal is to DPoP
instead of client credentials, in which case, I think I'm back to the
previous question.

On Sat, Jun 25, 2022 at 12:19 PM Vladimir Dzhuvinov 
wrote:

> I have a question to the DPoP spec authors - do you have a suggestion how
> to approach a token exchange case where the client requests a DPoP token
> and the submitted subject(actor)_token is / are also DPoP bound?
>
> My first thought was to simply let the client send two DPoP JWTs, one for
> the submitted token and another for the requested token, and then find a
> way in the AS to figure out which is which, but then I found this in
> section 4.3.1:
>
> To validate a DPoP proof, the receiving server MUST ensure that that there
> is not more than one DPoP HTTP request header field,
>
>
> Thanks,
>
> Vladimir
>
> --
> Vladimir Dzhuvinov
>
> ___
> 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

Re: [OAUTH-WG] DPoP JWT claims

[Warren Parad]

I think the registration really helps with discovery, especially as an
implementer. When you see or observe these claims in a JWT, you can google
them potentially returning no results. If you know about the IANA registry
you can find them, even if you don't know that the tokens have anything to
do with DPoP.

On Thu, Jun 16, 2022 at 6:21 PM Neil Madden 
wrote:

> The DPoP spec registers the “htm”, “htu”, and “ath” claims [1]. But do
> these claims actually make sense outside of a DPoP proof? Presumably the
> risk of naming collision within a DPoP proof is pretty small, so is there
> any benefit to registering them rather than just using them as private
> claims?
>
> (I guess I could ask the same question about lots of other entries in the
> current registry at IANA, many of which look completely app-specific to me).
>
> [1]:
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop#section-12.7
>
> — Neil
> ___
> 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

Re: [OAUTH-WG] Multi-Subject JWT draft

[Warren Parad]

Okay, so I'm definitely missing the value. We want to make sure *user A is
authorized to access user B's data* in a *resource server RS*. Either:

   1. The *resource server RS* needs to have a priori knowledge *that user
   A is allowed to access user B's data*
   2. Or user A needs to a have a token that contains user B as the subject

In (1) we don't need to add any additional handling, this is the current
path where authorization is being handled directly by the resource server.
So let's take a look at (2). Is the AS required to ensure that the subject
of the authorization is actually allowed to access user B's data?

   - In the case that the AS allows any user X to nest user B, then the
   resource server RS needs to *check that user A is allowed to access user
   B's data*. But this is already (1). So this solution doesn't offer any
   value. And further we would be opening up a pit failure creating tokens
   with any subject and only restricting them based on a new claim which not
   everyone will understand/process correctly.
   - So let's assume that the AS already knows and validates whether *user
   A is allowed to access user B's data* (suspect, since the AS likely
   doesn't include such granular RS access control understanding, but let's
   gloss over this) The nested claim in the token doesn't have any value to
   the resource server RS, because it doesn't know whether user A is allowed
   to access that data or not, it knows that the subject is B and B is allowed
   to access that data, and that's all it should care about. Since it
   delegated the decision to the AS and the AS knows, *then a token with
   subject B must be allowed to access user B's data, irrespective of the data
   in the nested claim*. Therefore, it doesn't provide any concrete value
   for authorization, and using that nested subject assuming it has meaning
   would contradict what the AS means. And further not every AS will follow
   this, opening another pit of failure.

But does it provide any value? *Definitely*. Services can log and record
the use of these authorization tokens in a resource first-class auditing
approach. When asked "who accessed this data" The answer should be
*user A* even
though the subject of the token is *user B. *

Which means, while not outlined in the draft, the conclusion is we are
adding this functionality to *improve audit trails and NOT for
authorization*. If we agree on that, then we can focus on improving how we
expose this data. In that case, we might call this *Chained JWTs,* *Rescoping
JWTs, *or even potentially *JWT delegation audit trail*. And as long as we
make it clear that this should never be used for authorization, we avoid
the pit of failures I've mentioned above.

And here's the third pitfall, it's frequently brought up about privacy,
potentially the last thing that resource owners want is that more details
about them are included into the access token being passed to resource
servers which aren't necessary for the authorization itself. For instance
adding the audit trail, may encourage AS to introduce personal
information into this object based on where the user originated from
enabling clients to abuse this information. I subscribe to the Resource
Owner RO only wanting to expose the relevant information for an AS to tell
a resource server if it should grant access and nothing more. (This of
course is from the AS' perspective only, nothing here limits further
decisions the RS can/should take based on its own context).

Limiting the scope to *audit trails *would be a great option in general,
except that we don't solve multi-party authorization. For instance, it is
common, especially in the crypto space, to need multiple signatories before
enabling access. And perhaps we are taking some inspiration from that, the
trouble is here, we would need the JWT to contain both (all) signatures not
just the audit trail to be of value.

So I would recommend we scope the draft to either solve *multi-party*
problems (which is what is actually hinted to me by *multi-subject*) OR to
add an *audit trail* to JWTs.

On Tue, Jun 14, 2022 at 9:47 PM Rifaat Shekh-Yusef 
wrote:

> Yes to both questions.
>
> On Tue, Jun 14, 2022 at 2:22 PM Warren Parad  wrote:
>
>> Is it helpful to challenge this implementation? (and is this email thread
>> the right place to do it?)
>>
>> On Tue, Jun 14, 2022 at 5:27 PM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> It is a Nested JWT with at least *two related subjects*, one in the
>>> enclosed JWT and another in the enclosing JWT.
>>> Having said that, I do not have a strong opinion on the name and we
>>> could potentially change it to a name that more accurately reflects the
>>> scope of the document, if needed.
>>>
>>> The justification for this is that in a number of use cases there is a
>>> nee

Re: [OAUTH-WG] Multi-Subject JWT draft

[Warren Parad]

Is it helpful to challenge this implementation? (and is this email thread
the right place to do it?)

On Tue, Jun 14, 2022 at 5:27 PM Rifaat Shekh-Yusef 
wrote:

> It is a Nested JWT with at least *two related subjects*, one in the
> enclosed JWT and another in the enclosing JWT.
> Having said that, I do not have a strong opinion on the name and we could
> potentially change it to a name that more accurately reflects the scope of
> the document, if needed.
>
> The justification for this is that in a number of use cases there is a
> need for both JWTs to be present, to allow the resource server to apply
> authorization based on who requested the access to the resource and on
> behalf of who is the request. For example, a parent ordering medication for
> their child. There are other use cases described in the document.
>
> Regards,
>  Rifaat
>
>
>
>
> On Tue, Jun 14, 2022 at 11:09 AM Warren Parad  wrote:
>
>> After reading the draft I also have some concerns. This still isn't
>> multi-subject, right? As there is only one subject, there just happens to
>> be a new claim with additional information in it. I'm still behind on the
>> justification for creating this, as at first glance, either the user got an
>> access token on behalf of the other user to access their resources or they
>> are impersonating the other user. So I'm not totally sure I understand the
>> immediate value/problem statement, but that could be discussed separately.
>>
>> There's still only one subject, right? I would recommend that
>> `multi-subject` be removed from the draft name. For instance, why not:
>>
>>- Nested Subject JWT Claims
>>
>> Or maybe we want to talk about the value:
>>
>>- Delegating Authorization using Nested Subject Claims in JWTs
>>
>>
>>
>> On Tue, Jun 14, 2022 at 5:05 PM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> Hi Dick,
>>>
>>> The initial scope of the document was very limited to extending the
>>> existing Nested JWT to allow the enclosing JWT to have its own claims.
>>> Since then, it was clear that there are many use cases that need such a
>>> mechanism that requires more than just a simple nesting of JWTs. That's the
>>> reason I changed the name, to reflect the larger scope of this document.
>>>
>>> I do not mind changing the name, if it makes sense.
>>> Would changing the name to Multi-Subject Nested JWT help address your
>>> concern?
>>>
>>> Regards,
>>>  Rifaat
>>>
>>>
>>>
>>>
>>> On Tue, Jun 14, 2022 at 10:46 AM Dick Hardt 
>>> wrote:
>>>
>>>> Hi Rifaat
>>>>
>>>> I'm suspecting there was a conversation on changing the name to
>>>> multi-subject JWT. Would you provide a pointer or short summary?
>>>>
>>>> I find the name concerning as I am looking at a very different concept
>>>> that would also be considered a multi-subject JWT.
>>>>
>>>>
>>>> My use case is where user accounts have been merged, and the issuer has
>>>> multiple "sub" claims for the same user and would like to include all the
>>>> values in the JWT to signal to the RP that the accounts have been merged.
>>>>
>>>> I was considering calling it "aka" and it would be an array of
>>>> identifiers. "aka" => Also Known As
>>>>
>>>> /Dick
>>>>
>>>> On Tue, Jun 14, 2022 at 5:25 AM Rifaat Shekh-Yusef <
>>>> rifaat.s.i...@gmail.com> wrote:
>>>>
>>>>> I have just submitted an updated version of the *Multi-Subject JWT*
>>>>> draft (formerly known as Nested JWT) with more details.
>>>>> I would appreciate any reviews and feedback on this version.
>>>>> https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt
>>>>>
>>>>> Regards,
>>>>>  Rifaat
>>>>>
>>>>> ___
>>>>> 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
>>>
>>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Multi-Subject JWT draft

[Warren Parad]

After reading the draft I also have some concerns. This still isn't
multi-subject, right? As there is only one subject, there just happens to
be a new claim with additional information in it. I'm still behind on the
justification for creating this, as at first glance, either the user got an
access token on behalf of the other user to access their resources or they
are impersonating the other user. So I'm not totally sure I understand the
immediate value/problem statement, but that could be discussed separately.

There's still only one subject, right? I would recommend that
`multi-subject` be removed from the draft name. For instance, why not:

   - Nested Subject JWT Claims

Or maybe we want to talk about the value:

   - Delegating Authorization using Nested Subject Claims in JWTs



On Tue, Jun 14, 2022 at 5:05 PM Rifaat Shekh-Yusef 
wrote:

> Hi Dick,
>
> The initial scope of the document was very limited to extending the
> existing Nested JWT to allow the enclosing JWT to have its own claims.
> Since then, it was clear that there are many use cases that need such a
> mechanism that requires more than just a simple nesting of JWTs. That's the
> reason I changed the name, to reflect the larger scope of this document.
>
> I do not mind changing the name, if it makes sense.
> Would changing the name to Multi-Subject Nested JWT help address your
> concern?
>
> Regards,
>  Rifaat
>
>
>
>
> On Tue, Jun 14, 2022 at 10:46 AM Dick Hardt  wrote:
>
>> Hi Rifaat
>>
>> I'm suspecting there was a conversation on changing the name to
>> multi-subject JWT. Would you provide a pointer or short summary?
>>
>> I find the name concerning as I am looking at a very different concept
>> that would also be considered a multi-subject JWT.
>>
>>
>> My use case is where user accounts have been merged, and the issuer has
>> multiple "sub" claims for the same user and would like to include all the
>> values in the JWT to signal to the RP that the accounts have been merged.
>>
>> I was considering calling it "aka" and it would be an array of
>> identifiers. "aka" => Also Known As
>>
>> /Dick
>>
>> On Tue, Jun 14, 2022 at 5:25 AM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> I have just submitted an updated version of the *Multi-Subject JWT*
>>> draft (formerly known as Nested JWT) with more details.
>>> I would appreciate any reviews and feedback on this version.
>>> https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt
>>>
>>> Regards,
>>>  Rifaat
>>>
>>> ___
>>> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Listing OAuth Access Token Metadata

[Warren Parad]

For the listing of all the user's toke, there isn't a standard for that.
Additionally these should still be OAuth flow generated tokens via that
third party. OAuth tokens are for clients on behalf of users, your use case
directly matches with the expectation of OAuth.

Lastly, if you want to add an alias or anything else to these, you can
definitely add some additional methods no your AS, but I would recommend
instead labeling these tokens as what they will be used for, i.e. the name
and Id of the relevant third party client, and not a custom alias.

I think if the best way to get advice in this area would be to stipulate
why your business use cases are the way they are. There's pretty straight
forward ways to solve what you seem to want using OAuth without anything
off spec, if there's a real use case missing that should be improved by
rev-ing the spec, it's best to talk about the core problems rather than
trying to introduce a new flow which con be rife with issues.

- Warren

On Wed, Apr 6, 2022, 05:49 Dhaura Pathirana 
wrote:

> Thank you all for the quick replies and I really appreciate the
> suggestions.
>
> One thing that I want to clarify is that, in this use case, the
> requirement is to list all the access tokens (metadata) (that belong to a
> single owner) issued for the custom grant but in the introspection
> specification only metadata can be listed for a given access token.
>
> Here, we need PATs rather than a standard OAuth grant type because the
> token should be issued to a user (not a client) and the user will use this
> token to access certain APIs through another third-party application (which
> could be a simple automation script). And also, there are some attributes
> like alias and description that should be stored with the PAT as they are
> required for token identification purposes (Those attributes are not common
> with other standard OAuth grant types).  Furthermore, the user should be
> able to revoke any of his PATs at any time.
>
> In the ID token suggestion, it is mentioned to look into OIDC ID token
> specification. Does it imply that an ID token should be used as a Personal
> Access Token, instead of an OAuth2 access token, or is it proposed to
> extract user information?
>
> Thank You.
> Kind Regards,
>
> Dhaura Pathirana
>
> On Mon, 4 Apr 2022 at 00:13, Warren Parad  wrote:
>
>> I'm tempted to say user created PATs are incompatible with OAuth, and
>> OAuth already has a solution which avoids the user having to manually
>> create these sorts of tokens. Is there a reason OAuth wouldn't be able to
>> handle the specific use case.
>>
>> Warren Parad
>>
>> Founder, CTO
>> Secure your user data with IAM authorization as a service. Implement
>> Authress <https://authress.io/>.
>>
>>
>> On Sun, Apr 3, 2022 at 7:56 PM Takahiko Kawasaki 
>> wrote:
>>
>>> Dear Dhaura,
>>>
>>> My recommendation to you (undergraduate? LinkedIn says so) is to
>>> investigate the following as the first step.
>>>
>>>
>>>- ID Token (OpenID Connect Core 1.0, Section 2)
>>>- UserInfo Endpoint (OpenID Connect Core 1.0, Section 5.3)
>>>
>>>
>>> In general, inventing a new grant type should be the last resort.
>>>
>>> Best Regards,
>>> Takahiko Kawasaki
>>>
>>>
>>> On Sun, Apr 3, 2022 at 3:35 PM David Waite >> 40alkaline-solutions@dmarc.ietf.org> wrote:
>>>
>>>>
>>>> On Apr 1, 2022, at 3:24 AM, Dhaura Pathirana 
>>>> wrote:
>>>>
>>>> I would like to know if anyone has seen this (listing token metadata)
>>>> as a common use case in OAuth2 and a standard way of doing it had been
>>>> proposed before?
>>>>
>>>>
>>>> OAuth Token Introspection (RFC 7662) defines a way to query for active
>>>> state and meta-info.
>>>>
>>>> However, its use is defined only for protected resources, and not the
>>>> resource owner or the client the token was issued to.
>>>>
>>>> -DW
>>>> ___
>>>> 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
>>>
>>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Listing OAuth Access Token Metadata

[Warren Parad]

I'm tempted to say user created PATs are incompatible with OAuth, and OAuth
already has a solution which avoids the user having to manually create
these sorts of tokens. Is there a reason OAuth wouldn't be able to handle
the specific use case.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Sun, Apr 3, 2022 at 7:56 PM Takahiko Kawasaki  wrote:

> Dear Dhaura,
>
> My recommendation to you (undergraduate? LinkedIn says so) is to
> investigate the following as the first step.
>
>
>- ID Token (OpenID Connect Core 1.0, Section 2)
>- UserInfo Endpoint (OpenID Connect Core 1.0, Section 5.3)
>
>
> In general, inventing a new grant type should be the last resort.
>
> Best Regards,
> Takahiko Kawasaki
>
>
> On Sun, Apr 3, 2022 at 3:35 PM David Waite  40alkaline-solutions@dmarc.ietf.org> wrote:
>
>>
>> On Apr 1, 2022, at 3:24 AM, Dhaura Pathirana 
>> wrote:
>>
>> I would like to know if anyone has seen this (listing token metadata) as
>> a common use case in OAuth2 and a standard way of doing it had been
>> proposed before?
>>
>>
>> OAuth Token Introspection (RFC 7662) defines a way to query for active
>> state and meta-info.
>>
>> However, its use is defined only for protected resources, and not the
>> resource owner or the client the token was issued to.
>>
>> -DW
>> ___
>> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC for DPoP Document

[Warren Parad]

I support publication.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Wed, Mar 30, 2022 at 2:08 PM Torsten Lodderstedt  wrote:

> I support publication of this specification.
>
> Am 30.03.2022 um 09:18 schrieb Steinar Noem :
>
> I support publication of the specification
>
> ons. 30. mar. 2022 kl. 08:56 skrev Dave Tonge  >:
>
>> I support publication of the specification
>>
>> On Wed, 30 Mar 2022 at 08:55, Daniel Fett  wrote:
>>
>>> I also support publication.
>>>
>>> -Daniel
>>> Am 29.03.22 um 23:20 schrieb David Waite:
>>>
>>> I also support publication of this specification
>>>
>>> -DW
>>>
>>> On Mar 29, 2022, at 3:12 PM, Mike Jones <
>>> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>>>
>>> I support publication of the specification.
>>>
>>>-- Mike
>>>
>>> *From:* OAuth  *On Behalf Of *Rifaat Shekh-Yusef
>>> *Sent:* Monday, March 28, 2022 5:01 AM
>>> *To:* oauth 
>>> *Subject:* [OAUTH-WG] WGLC for DPoP Document
>>>
>>> All,
>>>
>>> As discussed during the IETF meeting in *Vienna* last week, this is a *WG
>>> Last Call *for the *DPoP* document:
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
>>>
>>> Please, provide your feedback on the mailing list by April 11th.
>>>
>>> Regards,
>>>  Rifaat & Hannes
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> ___
>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>>
>>> -- https://danielfett.de
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>> --
>> Dave Tonge
>> CTO
>> [image: Moneyhub Enterprise]
>> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F=D=1=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>> t: +44 (0)117 280 5120
>>
>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
>> Limited which is authorised and regulated by the Financial Conduct
>> Authority ("FCA"). Moneyhub Financial Technology is entered on the
>> Financial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub 
>> Financial
>> Technology is registered in England & Wales, company registration number
>>  06909772 .
>> Moneyhub Financial Technology Limited 2018 ©
>>
>> DISCLAIMER: This email (including any attachments) is subject to
>> copyright, and the information in it is confidential. Use of this email or
>> of any information in it other than by the addressee is unauthorised and
>> unlawful. Whilst reasonable efforts are made to ensure that any attachments
>> are virus-free, it is the recipient's sole responsibility to scan all
>> attachments for viruses. All calls and emails to and from this company may
>> be monitored and recorded for legitimate purposes relating to this
>> company's business. Any opinions expressed in this email (or in any
>> attachments) are those of the author and do not necessarily represent the
>> opinions of Moneyhub Financial Technology Limited or of any other group
>> company.
>>
>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
>> Limited which is authorised and regulated by the Financial Conduct
>> Authority ("FCA"). Moneyhub Financial Technology is entered on the
>> Financial Services Register (FRN 809360) at https://register.fca.org.uk/.
>> Moneyhub Financial Technology is registered in England & Wales, company
>> registration number 06909772. Moneyhub Financial Technology Limited 2022 ©
>> Moneyhub Enterprise,
>>
>> DISCLAIMER: This email (including any attachments) is subject to
>> copyright, and the information in it is confidential. Use of this email or
>> of any information in it other than by the addressee is unauthorised and
>> unlawful. Whilst reasonable efforts are made to ensure that any attachments
>> are virus-free, it is the recipient's sole responsibility to scan all
>> attachments for viruses. All calls and emails to and from this com

Re: [OAUTH-WG] OAuth: The frustrating lack of good libraries

[Warren Parad]

>
> I like the idea of a machine-readable feature support document...
> discovering those documents might still be a problem, though.


Yay! I don't think it is hard to build a bot to iterate github/github and
pull these. It gives us a starting point for how to attack this problem.

The key components would be:

   - OAuth WG defines what the existing features are - is this even
   possible?
   - We would have to keep track of those and make sure that list is up to
   date (we already do this for existing discovery documents), is this a
   burden for us?
   - 
   - Profit

I think tools like openapi.tools would start to pop up, and places like
oauth.net could choose to host this.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Wed, Mar 2, 2022 at 6:11 PM Daniel Fett  wrote:

> Hi Warren,
> Am 02.03.22 um 17:05 schrieb Warren Parad:
>
> I don't think flooding this thread with random libraries is going to
> benefit anyone, so let's not do that.
>
> I agree, and that was not the aim of my question.
>
>
>
> Back to the question, and it is an interesting one. It makes sense to
> dissect it a bit first. Who is struggling with "OAuth libraries" and what
> is even the responsibility of one of them.
>
> *I'll start with my recommendation:*
>
>- 0) We shouldn't build anything, and we shouldn't curate lists of
>libraries and packages.
>
> I'm not suggesting that we build any libraries, that would be a bad idea.
> I'm not so sure on curated lists, however.
>
>
>
>- 1) We should make this information about libraries discoverable and
>trackable. For instance with AS discovery docs we can enable adding
>properties that link to SDKs in languages that the AS decides to support.
>
> I think that this goes into a completely wrong direction. Authorization
> servers should never be built towards certain libraries, in an ideal world
> at least. Also, why would I as an API provider even have to know about the
> SDKs? If my API follows the rules, any client library that follows the same
> rules should work.
>
>
>
>- 2) We can document a "discovery doc" for libraries to self publish
>detailing their features (in case they aren't associated with an AS). Then
>anyone who wants to build lists of libraries with supporting features, can
>easily compile these documents. All we have to do is define "OAuth SDK
>features", and this will enable everyone else to create SDK
>listings/feature comparisons. It can even be automated.
>
> I like the idea of a machine-readable feature support document...
> discovering those documents might still be a problem, though.
>
>
> *My concerns:*
> I think we have to break it down first into some key areas:
>
>- There are OAuth user-agent clients
>   - Mobile app clients for each of the app os, and further for each
>   of the app development frameworks
>   - Web apps
>   - Desktop apps
>- There are OAuth machine clients
>- BFF oauth code exchange clients
>   - client credentials clients
>   - third party machine clients
>   - leaf clients that need to validate authorization tokens
>   - [One caveat to this is that these can and will be written in
>   every possible language available]
>- There are OAuth Authorization servers
>- Open source ones
>   - SaaS models
>   - AS in a container
>   - embedded cloud native solutions
>   - potentially user controlled
>
> Obviously this isn't a full list, but looking at each of these,
> specialization in the world of software libraries tells us that likely
> every one of these could and will be its own library. Just looking at this
> shortlist, and the story of "which library" should you use becomes
> incredibly complicated. If we have libraries that purport to solve all
> these problems, then it becomes a gratuitous burden on developers to pick
> the right library, which isn't interchangeable with others. They aren't
> pluggable.
>
> I don't think that a library which supports only selected scenarios (e.g.,
> a mobile app on Android) is a problem, as long as that is well documented.
>
> Also, I wouldn't expect the same library API for each library to make them
> exchangeable. They don't need to be interchangeable, because that would
> mean that somebody is doing the same work as someone else.
>
>
>
> Additionally, for the purposes of branding and documentation, most of
> these will be wrapped by brand specific implementations so that careful
> validation and control over key features can be communicated. Further,
> since the landscape mov

Re: [OAUTH-WG] proof of access token possession using client secret

[Warren Parad]

Is there a reason you wouldn't want to use the access token to access these
resources? That seems like it would be the optimal strategy.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Wed, Mar 2, 2022 at 4:58 PM Nikos Fotiou  wrote:

> Hi all,
>
> I am working on a use case where the Authorization Server and the Resource
> Server are the same entity. I would like to prevent clients from sharing
> their access tokens. I am wondering if requiring clients to include the
> "client secret" in the resource access request (in addition to the access
> token) is a valid strategy. This way clients would have to share their
> "client secret" in addition to the access token. Would that work?
>
> Best,
> Nikos
> --
> Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
> Researcher - Mobile Multimedia Laboratory
> Athens University of Economics and Business
> https://mm.aueb.gr
>
> ___
> 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

Re: [OAUTH-WG] OAuth: The frustrating lack of good libraries

[Warren Parad]

right place. A library isn't
going to fix that, and even if it did, it isn't OAuth that is the issue
here, it is a lack of good browser apis to support easy navigation.

Which leaves us with, are we talking about mobile apps or desktop clients?
Because we are talking about one of these other categories, there isn't
enough value in there to list them any more than there is value in listing
OIDC providers that support OAuth. Being met with a list of hundreds of
libraries and packages doesn't make for a good experience, and do those
same developers know if they need PKCE, EdDSA signatures, a library that
supports mTLS, probably not.

- Warren

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Wed, Mar 2, 2022 at 4:33 PM Sascha Preibisch 
wrote:

> Hello Daniel!
>
> Some time ago I started an open source project: Loginbuddy.
> Loginbuddy is a tool that mainly supports OpenID Connect based logins.
>
> It can be deployed as a standalone service or be used as a side-car next
> to other docker containers in the same network.
>
> Although it is not necessarily a library, it may be worth looking into it.
> I could imagine that Loginbuddy would also be a good starting point for
> extensions that serve more flows and more general features of OAuth/ OpenID
> Connect. With more contributors I see a chance for Loginbuddy to be more
> widely used and help address your concerns.
>
> Please have a look here:
> https://loginbuddy.net
>
> I just updated the web site. Or visit the GitHub project:
> https://github.com/SaschaZeGerman/loginbuddy
>
> In any case, that is my current contribution to the developer community.
>
> Thanks,
> Sascha
>
> On Tue, Mar 1, 2022 at 9:18 AM Daniel Fett  wrote:
>
>> *Hi all,*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> * While helping clients to onboard into the yes ecosystem, in my
>> consulting work, and in discussions with developers implementing OAuth 2.0,
>> one topic comes up increasingly often: The (somewhat frustrating) lack of
>> good, modern, and universal OAuth libraries.  Many of the libraries out
>> there have one or more of the following drawbacks:  * They are not
>> maintained any longer  * They are not well documented (e.g., it is often
>> unclear which specifications are supported)  * They support only a subset
>> of the OAuth 2.0 specification  * They work only with selected providers
>> (e.g., Google, Facebook, etc.)  * It is unclear whether they follow recent
>> security recommendations  * They do not support modern features, such as
>> PKCE, AS Metadata, MTLS, etc. Exceptions exist, of course, like Filip's
>> Node.js implementation and the nimbus library for Java. But apart from
>> those rare cases, when a developer asks me what library to use, my answer
>> is often: "I don't think there's a good one in your language". It is a
>> telltale sign that many providers of OAuth protected APIs also provide a
>> custom OAuth implementation in their SDKs, which they then often have to
>> maintain for a number of languages. This creates unnecessary costs and
>> friction, e.g., when introducing new security features. At the same time,
>> practically every language/framework comes with a TLS stack and making
>> HTTPS requests is often just a few lines of code. Why aren't we there yet
>> with OAuth? I'm well aware that OAuth 2.0 is a framework, not a single
>> protocol like TLS, but the mentioned libraries show that this does not
>> preclude a comprehensive library support. If I had to speculate about the
>> reasons for this mess, I'd say that there are three:  * The core of OAuth
>> is easy to implement. The need to create or use a library might not be
>> obvious to developers. Of course, if you want a proper implementation with
>> correct error handling, observing all the security recommendations, etc.,
>> the effort is huge. But just getting OAuth to work for one specific use
>> case is relatively easy.  * OAuth is traditionally hard to configure:
>> authorization and token endpoint URLs, client id and secret, supported
>> scopes (and claims for OIDC), supported response types and modes, and
>> required security features are just some of the things a developer has to
>> figure out - often from the API's documentation - to get everything up and
>> running. Even though configuration is not the same as implementation, I
>> imagine that this complexity can lead to the perception that there are
>> barely any commonalities between different OAuth flows. There might be no
>> value, after

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Warren Parad]

This is a great improvement.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Tue, Feb 15, 2022 at 2:37 PM Neil Madden 
wrote:

> Thanks, these changes address my comments. I am happy with the new draft
> text.
>
> Cheers,
>
> Neil
>
> On 15 Feb 2022, at 00:33, Kristina Yasuda <
> Kristina.Yasuda=40microsoft@dmarc.ietf.org> wrote:
>
> Hi All,
>
> Thank you very much for the constructive feedback.
> We have tried to address the WGLC comments received to date with the
> latest draft published at
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwk-thumbprint-uri-01
> .
>
> Following are updates made to the document:
> - Added security considerations about multiple public keys coresponding to
> the same private key.
> - Added hash algorithm identifier after the JWK thumbprint URI prefix to
> make it explicit in a URI which hash algorithm is used.
> - Added reference to a registry for hash algorithm identifiers.
> - Added SHA-256 as a mandatory to implement hash algorithm to promote
> interoperability.
>
> Kindest Regards,
> Kristina
>
> *From:* OAuth  *On Behalf Of *Rifaat Shekh-Yusef
> *Sent:* Wednesday, February 2, 2022 4:19 AM
> *To:* oauth 
> *Subject:* [OAUTH-WG] WGLC for JWK Thumbprint URI document
>
> All,
>
> The *JWK Thumbprint URI *document is a simple and
> straightforward specification.
>
> This is a WG Last Call for this document:
> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html=04%7C01%7CKristina.Yasuda%40microsoft.com%7C798aea1808b74133e90308d9e64643b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637794012195931100%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=UDG%2F77OaaA%2BaTPiBiDzKYbyXUvJ2YY5m%2F7wO7OhW%2FNI%3D=0>
>
> Please, provide your feedback on the mailing list by *Feb 16th*.
>
> Regards,
>  Rifaat & Hannes
>
>
> ___
> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP + Token Revocation

[Warren Parad]

I'm a big fan of not arbitrarily adding security to paths that don't
require it. The more complicated it is to do what you want without a
concrete reason, the more likely there will be an introduced vulnerability.

Consistency on adding requirements to endpoints that don't need it also
makes them harder to use. In this case, I challenge that if the attacker
could intercept login to get both a valid token and steal the DPoP key,
that preventing refresh token revocation is meaningless. Being able to
revoke the refresh token doesn't decrease the vulnerable surface, so adding
protections there is unwise.

I'm not saying it is defined on all the necessary endpoints already, but
let's be deliberate on which ones get it.

On Thu, Feb 10, 2022, 01:19 Dmitry Telegin  wrote:

> Could we perhaps be a little bit more specific on the relationship between
> DPoP and OAuth 2.0 Token Revocation (RFC 7009)?
>
> I believe that if we constrain *some* token lifecycle events (issuance,
> refresh), we should constrain *all*, revocation included (please correct
> me if I'm wrong).
>
> There seem to be no direct attack vectors here, but indirect ones might be
> possible. For example, by revoking an exfiltrated refresh token, thus
> killing the session, the attacker could force the user to reauthenticate at
> the moment the attacker would be ready to steal credentials.
>
> Dmitry
> Backbase / Keycloak
> ___
> 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

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Warren Parad]

Then perhaps what is in order is to replace 7638, before moving forward
with this one, that way we don't end up in state where implementations are
based on unnecessary complexity which isn't backwards compatible.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Sat, Feb 5, 2022 at 6:47 PM Mike Jones  wrote:

> David, I believe your objections below are actually about the JWK
> Thumbprint [RFC 7638 <https://www.rfc-editor.org/rfc/rfc7638.html>]
> computation used by this specification, and not the operation defined by
> this specification.  JWK Thumbprint became an RFC in 2015.
>
>
>
> This specification
> <https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html>
> defines how to create a JWK Thumbprint URI by concatenating the URI prefix “
> urn:ietf:params:oauth:jwk-thumbprint” to an RFC 7638 JWK Thumbprint.
> That’s all it does.  That’s why Rifaat’s statement “*The JWK Thumbprint
> URI document is a simple and straightforward specification*” is indeed
> correct.
>
>
>
>Best wishes,
>
>-- Mike
>
>
>
> *From:* OAuth  *On Behalf Of * David Chadwick
> *Sent:* Friday, February 4, 2022 9:55 AM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
>
>
>
> On 02/02/2022 12:18, Rifaat Shekh-Yusef wrote:
>
> All,
>
>
>
> The *JWK Thumbprint URI *document is a simple and
> straightforward specification.
>
> Actually this is a complex and inefficient specification compared to other
> possibilities.
>
> I have written an Internet-Draft outlining an alternative scheme, the JWK
> URI, which provides OIDC SIOPv2 with all the requirements that it needs
> with much less effort than implementing JWK Thumbprint URIs. I am currently
> formatting this I-D correctly to submit to the IETF. The rationale for this
> new Internet Draft is as follows.
>
> To produce or validate a JWK Thumbprint, both the sender and the receiver
> have to have the JWK available to them. Then they have to canonicalise the
> JWK as described in [RFC7638], and finally hash the octets of the UTF-8
> representation of this JSON object with a pre-agreed algorithm in order to
> both obtain the same hash value. The way that the JWK Thumbprint URI is
> used in SIOPv2 [SIOPv2] is as follows:
>
>1. the SIOP creates an asymmetric key pair and encodes the public key
>as a JWK
>2. the SIOP creates the JWK Thumbprint as described in [RFC7638] and
>converts it to a URI as described in [JONES],
>3. the SIOP passes both the JWK and JWK Thumbprint URI to the RP in
>the JWT,
>4. the RP extracts the JWK and JWK Thumbprint from the JWT
>5. the RP re-computes the JWK Thumbprint from the JWK
>6. the RP compares the computed JWK Thumbprint with the received JWK
>Thumbprint to confirm that they are equal.
>
> One can see that the use of JWK Thumbprint URIs is both inefficient (in
> all cases) and a significant disadvantage (in some cases). If the JWK URI
> is transferred instead of the JWK and JWK Thumbprint URI then:
>
> a) The SIOP will never need to create the JWK Thumbprint URI. The RP may
> only need to create the JWK Thumbprint if it needs this, for example, as a
> unique subject identifier. Even in this case, there is still an advantage
> to the RP in receiving the JWK URI instead of the JWK Thumprint URI, in
> that the RP no longer needs to pre-agree a hashing algorithm with the SIOP.
> Thus the RP can independently determine which hashing algorithm to use when
> creating its own JWK Thumbprint. (Note. If the SIOP were able to
> canonicalise the same public key in a JWK in different ways and produce
> different thumbprints from the same public key, then the canonicalisation
> algorithm is broken, and the RP would never to able to deterministically
> produce the same thumbprints each time.)
>
> b) In those cases where the SIOP uses ephemeral key pairs and a different
> public key each time it communicates with an RP, then neither party needs
> to produce the JWK Thumbprint as it will never be seen again. It is a
> significant disadvantage to have to use JWK Thumbprints in this case.
>
> I therefore kindly request that the JWK Thumbprint URI document does not
> progress until the WG has had chance to compare and contrast the two
> methods.
>
> Kind regards
>
> David
>
>
>
>
>
> This is a WG Last Call for this document:
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html
>
>
>
> Please, provide your feedback on the mailin

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Warren Parad]

I also agree that there hasn't been sufficient review of this document to
warrant progressing it.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Fri, Feb 4, 2022 at 6:56 PM David Chadwick <
d.w.chadw...@verifiablecredentials.info> wrote:

> On 02/02/2022 12:18, Rifaat Shekh-Yusef wrote:
>
> All,
>
> The *JWK Thumbprint URI *document is a simple and
> straightforward specification.
>
> Actually this is a complex and inefficient specification compared to other
> possibilities.
>
> I have written an Internet-Draft outlining an alternative scheme, the JWK
> URI, which provides OIDC SIOPv2 with all the requirements that it needs
> with much less effort than implementing JWK Thumbprint URIs. I am currently
> formatting this I-D correctly to submit to the IETF. The rationale for this
> new Internet Draft is as follows.
>
> To produce or validate a JWK Thumbprint, both the sender and the receiver
> have to have the JWK available to them. Then they have to canonicalise the
> JWK as described in [RFC7638], and finally hash the octets of the UTF-8
> representation of this JSON object with a pre-agreed algorithm in order to
> both obtain the same hash value. The way that the JWK Thumbprint URI is
> used in SIOPv2 [SIOPv2] is as follows:
>
>1. the SIOP creates an asymmetric key pair and encodes the public key
>as a JWK
>2. the SIOP creates the JWK Thumbprint as described in [RFC7638] and
>converts it to a URI as described in [JONES],
>3. the SIOP passes both the JWK and JWK Thumbprint URI to the RP in
>the JWT,
>4. the RP extracts the JWK and JWK Thumbprint from the JWT
>5. the RP re-computes the JWK Thumbprint from the JWK
>6. the RP compares the computed JWK Thumbprint with the received JWK
>Thumbprint to confirm that they are equal.
>
> One can see that the use of JWK Thumbprint URIs is both inefficient (in
> all cases) and a significant disadvantage (in some cases). If the JWK URI
> is transferred instead of the JWK and JWK Thumbprint URI then:
>
> a) The SIOP will never need to create the JWK Thumbprint URI. The RP may
> only need to create the JWK Thumbprint if it needs this, for example, as a
> unique subject identifier. Even in this case, there is still an advantage
> to the RP in receiving the JWK URI instead of the JWK Thumprint URI, in
> that the RP no longer needs to pre-agree a hashing algorithm with the SIOP.
> Thus the RP can independently determine which hashing algorithm to use when
> creating its own JWK Thumbprint. (Note. If the SIOP were able to
> canonicalise the same public key in a JWK in different ways and produce
> different thumbprints from the same public key, then the canonicalisation
> algorithm is broken, and the RP would never to able to deterministically
> produce the same thumbprints each time.)
>
> b) In those cases where the SIOP uses ephemeral key pairs and a different
> public key each time it communicates with an RP, then neither party needs
> to produce the JWK Thumbprint as it will never be seen again. It is a
> significant disadvantage to have to use JWK Thumbprints in this case.
>
> I therefore kindly request that the JWK Thumbprint URI document does not
> progress until the WG has had chance to compare and contrast the two
> methods.
>
> Kind regards
>
> David
>
>
>
> This is a WG Last Call for this document:
> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html
>
> Please, provide your feedback on the mailing list by *Feb 16th*.
>
> Regards,
>  Rifaat & Hannes
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> 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

Re: [OAUTH-WG] OAuth 2.1: Missing token?

[Warren Parad]

It may help to specifically clarify which interaction with the AS are we
talking about here.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Fri, Feb 4, 2022 at 10:16 AM Johannes Koch  wrote:

> Hi there,
>
> a question about
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04
>
> 5.2.3.  Error Codes
>
>"invalid_request":  The request is missing a required parameter,
>   includes an unsupported parameter or parameter value, repeats the
>   same parameter, uses more than one method for including an access
>   token, or is otherwise malformed.  The resource server SHOULD
>   respond with the HTTP 400 (Bad Request) status code.
>
>"invalid_token":  The access token provided is expired, revoked,
>   malformed, or invalid for other reasons.  The resource SHOULD
>   respond with the HTTP 401 (Unauthorized) status code.  The client
>   MAY request a new access token and retry the protected resource
>   request.
>
> Now, what is the intended error code for the situation where no access
> token is provided? The description for invalid_token seems to imply that
> one token was provided.
> As the token may be seen as a required parameter, invalid_request may be
> appropriate. However, a missing token smells more like HTTP 401
> (Unauthorized).
>
> Should this be an additional error code (missing_token)? Or should this
> case be added to invalid_token?
>
> --
> Johannes Koch
> ___
> 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

Re: [OAUTH-WG] Independent Stream publication of draft-santesson-svt and draft-santesson-svt-jws

[Warren Parad]

Can you link them here?

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Sun, Jan 30, 2022 at 9:47 PM RFC ISE (Adrian Farrel) <
rfc-...@rfc-editor.org> wrote:

> Hi OAuth,
>
> The authors of draft-santesson-svt and draft-santesson-svt-jws have
> approached me as the Independent Submissions Editor requesting publication
> of these two drafts as Informational RFCs in the Independent Stream.
>
> This email is to:
>
> - ask OAuth whether the WG thinks the work is in scope for the WG and
>   should be advanced within the WG
>
> - solicit reviews of the drafts (which should be send direct to me)
>
> Many thanks,
> Adrian
>
> --
> Adrian Farrel (ISE),
> rfc-...@rfc-editor.org
>
> ___
> 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

Re: [OAUTH-WG] Token Revocation error codes

[Warren Parad]

According to RFC7009, I don't see anywhere which says you have to return a
200 for token=null. I interpret it as you return a 200, if the token passed
would never have been accepted as a valid token. *Null* isn't an invalid
token, it is an invalid value for the *token* parameter which is required.

   token   REQUIRED.  The token that the client wants to get revoked.


So the correct response is either an error immediately (returning a 4XX),
or feel free to return the 200 and then the AS should redirect the user to
a verified location with the *error *and *error_description* query
parameters.

I do see some gray area for what to do with real invalid tokens, i.e. the
token signature is invalid. So some clarity on the definition of
*invalid. *Since
the spec talks about invalidation lots of times we should interpret it to
mean *a token that has already been invalidated.* And I would interpret all
other tokens as justifications for returning a 4XX status code.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Wed, Jan 26, 2022 at 6:44 PM Sergey Ponomarev  wrote:

> Hi and sorry for raising the four years old topic.
>
> As a recup I reported a SECURITY VULNERABILITY on OAuth 2
> specification level. It's minor (I hope) but still seen in the real
> world AS implementation.
> In short, to logout a user the revocation endpoint is called with the
> user's token. And by a the RFC7009 the AS must always return 200 Ok
> status code even if the token is invalid:
>
> > The authorization server responds with HTTP status code 200 if the token
> has been revoked successfully or if the client submitted an invalid token.
> > Note: invalid tokens do not cause an error response since the client
> cannot handle such an error in a reasonable way.  Moreover, the purpose of
> the revocation request, invalidating the particular token, is already
> achieved.
>
> So if a client just made an incorrect call e.g. token=null then it
> will anyway receive a 200 OK and the user will think that logout was
> successful and a session closed. But internally the token may be
> stored in many places and even shared  between microservices/UI and
> other parties and it will remain still working.
>
> Can anybody take some actions and at least make some errata to the spec?
>
> P.S. adding to CC authors of the spec
>
> On Tue, 22 May 2018 at 20:29, Sergey Ponomarev  wrote:
> >
> > What is also should be discussed and specified is revoking of expired
> token. For example in Keycloak you can invalidate a session by expired
> token:
> >>
> >> It should be possible to logout a session with a token that is expired.
> This is to make sure that a user can invalidate a session if there's a
> suspicion that the refresh/offline token has been leaked. In such a case it
> could be that the real user has an expired refresh token while an attacker
> has been able to refresh the token and obtain a new not expired refresh
> token.
> >
> >
> > KEYCLOAK-3302
> >
> > Think this is doubtful but makes sense.
> >
> > To summarize: we have to create some threat model with description of
> possible use cases.
> >
> >
> > On Tue, 22 May 2018 at 18:18, Sergey Ponomarev 
> wrote:
> >>
> >> From OAuth perspective we can't say that the token should have some
> structure: they can be any random value in case of reference (opaque)
> tokens. But the Google's OAuth Server responds in this case with 400 error
> "invalid_token".
> >> The same can be used for JWTs with invalid sign or issuer.
> >> So it would be better if specification allow OAuth servers to respond
> with this error code if it clearly know that token was invalid by format.
> >>
> >> On Tue, 22 May 2018 at 17:51, Thomas Broyer  wrote:
> >>>
> >>> IFF the server processes it!
> >>> RFC 7009 says “An authorization server MAY ignore this parameter,
> particularly if it is able to detect the token type automatically.” which
> BTW is exactly my case.
> >>>
> >>> For months, my AS received requests with token=Array, and now receives
> requests with token=null. Those are clearly bugs in the client code, and
> because I return a 200 OK, the developers aren't aware of it.
> >>>
> >>> If tokens have an expected "structure", I think AS should probably
> return an error when the token value clearly is not a token (at one point I
> may change my implementation to do just that). As soon as it looks like a
> potential token though, then 200 OK sounds good to me.
> >>>
> >>> On Tue, May 22, 2018 at 4:34 PM Justin Richer  wro

Re: [OAUTH-WG] [IANA #1216704] Expert Review for draft-ietf-oauth-iss-auth-resp (oauth-parameters) (2)

[Warren Parad]

Maybe we should come up with an alternative process that doesn't involve a
single person sign-off. Is there a reason we need a "designated expert"?

Since no one on this thread has objected, I think it is fair to say, we
don't need Hannes to sign-off. We should get this added.

Amanda, please complete the registration.

- Warren

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Mon, Jan 24, 2022 at 11:09 PM Amanda Baber via RT <
drafts-expert-review-comm...@iana.org> wrote:

> Hi Hannes,
>
> As the designated expert for OAuth Parameters, can you sign off on this
> registration?
>
> thanks,
> Amanda
>
> On Thu Jan 13 21:29:54 2022, bcampb...@pingidentity.com wrote:
> > Indeed, I believe that is exactly what the registration request in the
> > draft asks to do
> > https://www.ietf.org/archive/id/draft-ietf-oauth-iss-auth-resp-
> > 05.html#name-oauth-parameters-registrati
> >
> > 5.2.  OAuth Parameters Registration
> >
> > This specification updates the "iss" entry in the IANA "OAuth
> > Parameters" registry of [IANA.OAuth.Parameters] established by
> > [RFC6749].
> >
> > Parameter name:  "iss"
> > Parameter usage location:  authorization request, authorization
> >response
> > Change Controller:  IETF
> > Specification Document(s):  Section 2 of [[ this document ]],
> >[RFC9101], and Section 4.1.1 of [RFC7519].
> >
> > On Wed, Jan 12, 2022 at 7:29 PM Mike Jones  > 40microsoft@dmarc.ietf.org> wrote:
> >
> > > Note that the requested OAuth parameter to be registered "iss" has
> > > already
> > > been registered by RFC 9101 (The OAuth 2.0 Authorization Framework:
> > > JWT-Secured Authorization Request (JAR)) for Parameter Usage Location
> > > "authorization request".  Fortunately, this use is compatible with
> > > that in
> > > draft-ietf-oauth-iss-auth-resp.
> > >
> > > I would be OK with draft-ietf-oauth-iss-auth-resp also registering it
> > > for
> > > usage "authorization response", as proposed in the draft, but the
> > > original
> > > registration for use "authorization request" by RFC 9191 should
> > > remain.
> > >
> > > -- Mike
> > >
> > > P.S.  No, I'm not a designated expert for this registry.  Hannes is
> > > the
> > > only DE currently appointed by the IESG.
> > >
> > > -Original Message-
> > > From: oauth-ext-review  On Behalf
> > > Of
> > > Amanda Baber via RT
> > > Sent: Thursday, January 6, 2022 4:50 PM
> > > Cc: oauth-ext-rev...@ietf.org; Hannes Tschofenig <
> > > hannes.tschofe...@arm.com>; oauth@ietf.org
> > > Subject: [oauth-ext-review] [IANA #1216704] Expert Review for
> > > draft-ietf-oauth-iss-auth-resp (oauth-parameters) (2)
> > >
> > > Hi Hannes,
> > >
> > > Although the IESG has approved the document, we need expert approval
> > > in
> > > order to move forward with the registration, unless the ADs
> > > specifically
> > > tell us to move ahead without it. Can you approve the OAuth Parameter
> > > registration in this document?
> > >
> > > https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
> > >
> > > thanks,
> > > Amanda
> > >
> > > On Tue Jan 04 13:21:14 2022, rifaat.s.i...@gmail.com wrote:
> > > > Hannes,
> > > >
> > > > Can you please take a look at this request to allow us to make
> > > > progress with this document?
> > > >
> > > > Thanks,
> > > >  Rifaat
> > > >
> > > >
> > > > On Mon, Jan 3, 2022 at 8:58 PM Amanda Baber via RT <
> > > > drafts-expert-review-comm...@iana.org> wrote:
> > > >
> > > > > Hi Hannes,
> > > > >
> > > > > Have you had a chance to review the OAuth Parameters request in
> > > > > this
> > > > > document?
> > > > >
> > > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
> > > > >
> > > > > thanks,
> > > > >
> > > > > Amanda Baber
> > > > > IANA Operations Manager
> > > > >
> > > > > On Wed Nov 24 21:28:18 2021, amanda.baber wrote:
> > > > > > Attn: Hannes (OAuth Parameters registry exp

Re: [OAUTH-WG] Implicit Grant Flow for authentication on both Client UI and Back End by OIDC id_token verification

[Warren Parad]

Sergey, you probably want to look into using *auth code + PKCE* flow. There
is a standardized formal flow for this, and it will resolve your
concerns as well as remove some of the pitfalls with your current approach.
What you have implemented is very similar, but misses on some key
optimizations such as not needing a backend service, requiring the
utilization of the nonce, incorrect usage of the *id_token* to name a few.

- Warren

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Wed, Jan 19, 2022 at 1:38 AM David Waite  wrote:

>
>
> Sent from my iPhone
>
> > On Jan 18, 2022, at 3:54 PM, Sergey Ponomarev  wrote:
> 
> >
> > The Implicit grant flow was intended for authorising clients which
> > can't store the `client_secret` like SPA.
>
> It is orthogonal to that, you can do code flow without client secrets as
> well. OAuth was released at a time of much simpler JavaScript development,
> and before standardization of CORS. Implicit was more of an implementation
> simplicity trade off for JavaScript clients.
>
> > OIDC added `id_token` which is a signed JWT (JWS) that contains user
> info.
>
> The id_token is a message from the OP/AS to the client about the end user
> - their subject identifier and other authentication information. other user
> claims are sometimes bundled in by implementations, such as when the client
> is not asking for an access token and thus will not be able to hit the user
> info endpoint.
>
> > If we just need for authentication it's now possible to request the
> > only `response_type=id_token` i.e. we aren't interested in getting the
> > `access_token`.
>
> Yes.
>
> > Anybody can verify that the token was issued by the Auth Server and it
> > wasn't changed.
>
> If the client has a confidential cryptographic key the id_token may be
> encrypted. But 99.9% of the time, yes.
>
> > We may also ask to include our own `nonce` into the `id_token` and
> > thus we may protect from reusing the `id_token` twice.
>
> The nonce claim is required for implicit, and really should be mandatory
> for all cases where the id_token is in a front channel. The reuse
> restriction is really one of having the authentication protocol be
> interactive.
>
> > This gives us an ability to use the `id_token` for server validation.
>
> The goal is for server validation of id_tokens. A JavaScript client has
> limited power in making security decisions, e.g. restricting user access to
> data in the local browser IndexedDB isn’t really possible.
>
> Browser consumption of id_tokens is really a demo-level construct. You
> could potentially use it to pull values out and personalize the page AKA
> “Welcome, ” or attempt to lock down the presentation layer to prevent
> casual drive-by information leaking, but there’s no reason for the server
> to trust an assertion from a JavaScript client about the user.
>
> > To explain the flow let's take for example a Google:
> 
>
> These are correct. For implicit, the state parameter is used to prevent
> some cross browser issues such as XSRF attacks. Guidance for code flow is
> to use PKCE, so state can actually be used “just” for application state,
> such as what the user was trying to do before authentication was required.
>
> > The key advantage of the flow is that the Client Server doesn't have
> > to perform a side channel request to the Auth Server as it needs in
> > the Authorization Code flow.
> > This not only improves performance but also allows to decouple Client
> > Server from Auth Service.
>
> There are ramifications of this approach, such as losing access to other
> OAuth extensions which are only defined for code flow, and potentially
> having PII flow through the browser. You also lose the ability to
> potentially get new id_tokens (extending the session) through refresh,
> since there’s no chance for a refresh token. Finally, it propagates
> implicit flow, which has an interoperability impact.
>
> Generally my advice is “use code unless you can’t.”
>
> > For example the Client Server can't connect to the Auth Service
> > because of connectivity problems.
> > Or if the AS is blocked in the Client Server country (e.g. Yandex and
> > VK.com in Ukraine, Google in China, Twitter in Nigeria etc.).
>
> Generally these sorts of connectivity issues and clocks will impact the
> implicit channel as well - they won’t block Google’s auth endpoint, they’ll
> block Google.
>
> > Another reason if the Client Server wants to hide its IP from the Auth
> > Service e.g. this a Tor Hidden Service with .onion domain.
>
> The call for the code grant

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

[Warren Parad]

The PKCE downgrade attack is the converse, here we are adding in PKCE where
there was none.

An attacker can thus send the victim the authorization response, after the
> victim clicks the link, the client application sends a Token Request with
> the code_verifier present with the client to Keycloak.

That isn't the whole flow though, right? You are missing what the
authorization request the attacker sent to the AS is, as well what happens
after the user agent gets back the access token, how is a token generated
this way a vulnerability.

I think I see the suggested problem:

if an AS-client interaction supports both PKCE and not PKCE, and the client
assumes that PKCE is sufficient for CSRF, when the auth code request
doesn't include the PKCE but the client didn't send state/nonce. With OAuth
2.1 it is clear that the nonce/state must be sent in this situation:

   - State is required in OAuth authorization code requests if PKCE isn't
   specified: OAuth 2.1 section 7.7
   <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04#section-7.7>
   - State is required in OAuth token exchange requests if present: Section
   4.1.2
   
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04#section-4.1.2>

Since the user agent won't contain the valid state/nonce generated by the
attacker, it isn't possible for it to send the attacker's state to the AS.
Therefore the AS will reject the token exchange due to the state mismatch.
It doesn't matter if the request isn't protected against CSRF, because no
valid token is going to be returned anyway.

So I don't think there is an issue here, did I get that correct?

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Wed, Jan 5, 2022 at 3:56 PM Christopher Burroughs <
chris.burrou...@protonmail.ch> wrote:

> Greetings,
>
>
> Is this scenario any different from a PKCE downgrade attack, as described
> in OAuth 2.0 Security Best Current Practice section 4.8.2 ?
>
>
> Warm regards and happy new year!
>
>
> Christopher Burroughs
>
>
>
>
>
>  Original Message 
> On Jan 5, 2022, 21:29, Benjamin Häublein < benjamin.haeubl...@cirosec.de>
> wrote:
>
>
> The following example shows this behavior in keycloak:
>
> Authorization Request:
>
>
> http://identity-provider:8080/auth/realms/XXX/protocol/openid-connect/auth?client_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_mode=fragment_type=code=openid
>
> Authorization Response:
>
>
> http://127.0.0.1/#session_state=46556363-c53f-489f-871c-58d376a8f9c1=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945
>
> Token Request:
>
> POST /auth/realms/XXX/protocol/openid-connect/token HTTP/1.1
> Host: identity-provider:8080
> Content-type: application/x-www-form-urlencoded
>
>
> code=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945_type=authorization_code_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_verifier=IqiCQGM06JEyW73AB3f3oblCQKHOorapyqHUcYRujuSikDJx8cvBQ0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX
>
>
>
> As a result, an access token was issued although the code_verifier
> provided in the token request did not match the code_challenge and
> code_challenge_method in the authorization request as they were absent.
>
>
>
> An attacker can thus send the victim the authorization response, after the
> victim clicks the link, the client application sends a Token Request with
> the code_verifier present with the client to Keycloak.
>
> As a result, a token is issued for the application, although the
> code_verifier does not match the inexistent
> code_challenge/code_challenge_method in the malicious authorization
> response.
>
>
>
> For this to work, the client must either generate a code_verifier on the
> fly or have one already present. This obviously depends on the precise
> implementation of the respective client.
>
> To reach such a state, an attacker could trick the user into starting the
> authorization grant but clicking the malicious link before the
> authorization response is sent.
>
>
>
> Best Regards,
>
> Benjamin Häublein
> Senior Consultant
>
> cirosec GmbH
> Ferdinand-Braun-Strasse 4
> 74074 Heilbronn
> Germany
> Phone: +49 (7131) 59455-74
> Fax: +49 (7131) 59455-99
> Mobile: +49 (151) 122414-74
> www.cirosec.de
>
> HRB Stuttgart 107883
> CEO Stefan Strobel, CFO Peter Lips
>
>
>
> *Von:* Warren Parad 
> *Gesendet:* Mittwoch, 5. Januar 2022 13:44
> *An:* Benjamin Häublein 
> *Cc:* George Fletcher ; oauth@ietf.org
> *Betreff:* Re: [OAUTH-WG] Edge case in RFC 7636,

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

[Warren Parad]

I'm not following to be honest. Could you detail concretely what the flow
would be that would result in vulnerability?

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Wed, Jan 5, 2022 at 1:41 PM Benjamin Häublein <
benjamin.haeubl...@cirosec.de> wrote:

> Finally, I'm not sure a client that doesn't send the 'code_challenge' and
> 'code_challenge_method' on the authorization request but does send the
> 'code_verifier' on the token request should consider that the client has
> implemented PKCE correctly and hence can rely on it for CSRF.
>
> My point is not, that a client behaves that way. The problem is that an
> attacker could get a user (through social engineering) to start the
> authorization process and then click a link with an authorization response
> that the attacker provides.
>
> Then the client has send the 'code_challenge' and 'code_challenge_method'
> in the authorization request, but the authorization response belongs to an
> authorization request that does not have these parameters.
>
> When the client sends the token request based on the malicious
> authorization request but with the ‘code_verifier’ for the original
> authorization request.
>
> When the AS behaves as described the client has no way to know that an
> attacker has interfered.
>
>
>
> Best Regards,
>
> Benjamin Häublein
>
> *Von:* George Fletcher 
> *Gesendet:* Dienstag, 4. Januar 2022 14:51
> *An:* Benjamin Häublein ; oauth@ietf.org
> *Betreff:* Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies
> code_verifier facilitates Login-CSRF
>
>
>
> My guess is that for an Authorization Server that doesn't receive a
> 'code_challenge' and 'code_challenge_method' as part of the authorization
> request, they treat the request as a non-PKCE authorization request. Therefore
> when the 'code_verifier' is presented at the /token endpoint, the AS
> ignores the parameter because it doesn't consider the request to be a PKCE
> request. I can also see the AS returning an error regarding an "unexpected
> parameter" or "invalid request" error in this case.
>
> I agree with your recommendation for the AS to require specific clients to
> use PKCE and consider an authorization request without PKCE to be an error.
>
> Finally, I'm not sure a client that doesn't send the 'code_challenge' and
> 'code_challenge_method' on the authorization request but does send the
> 'code_verifier' on the token request should consider that the client has
> implemented PKCE correctly and hence can rely on it for CSRF.
>
> Thanks,
> George
>
> On 1/4/22 5:45 AM, Benjamin Häublein wrote:
>
> Hello everyone,
>
> I think RFC 7636 “Proof Key for Code Exchange by OAuth Public Clients”,
> section 4.6. “Server Verifies code_verifier before Returning the Tokens”
> leaves a tiny gap regarding the handling of verification when no code
> challenge was present in the authorization request:
>
>Upon receipt of the request at the token endpoint, the server
>
>verifies it by calculating the code challenge from the received
>
>"code_verifier" and comparing it with the previously associated
>
>"code_challenge", after first transforming it according to the
>
>"code_challenge_method" method specified by the client.
>
> It is unspecified how the server should behave when “code_verifier” is
> present, but “code_challenge” and “code_challenge_method” were not set in
> the initial authorization request.
>
> The following example worked for three well-known authorization servers
> where the client was configured in a way that PKCE could be used, but was
> not enforced:
>
> Authorization Request:
>
>
> https:///auth?client_id=_type=code=openid+profile_uri=https://localhost
>
> Subsequent Token Request:
>
> POST /token HTTP/1.1
> Host: 
> Content-Length: 256
>
>
> code=_type=authorization_code_id=_uri=https%3A%2F%2Flocalhost_verifier=IqiCQGM06JEyW73AB3f3oblCQKHOorapyqHUcYRujuSikDJx8cvBQ0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX
>
> As a result, an access token was issued although the code_verifier
> provided in the token request did not match the code_challenge and
> code_challenge_method in the authorization request.
>
>
>
> Many applications consider the usage of PKCE as enough protection from
> Login-CSRF and do not use state or nonce (for example this blog entry by
> Daniel Fett
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/
> suggests, that neither state nor nonce are necessary when PKCE is used).
> However, when the authorization server is not configured to require

Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks

[Warren Parad]

I also 100% with the recommendation for phishing detectors treat all
perceived OAuth links as malicious in emails. It actually isn't hard to
know that there is a link embedded in a url query parameter. So I would
just take the next step of treating all urls with urls as query parameters
as malicious.

There are exactly zero reasons why a site can't use it's own javascript
redirection unless it's domain has been marked as malicious. The only
conceivable reason is a third party is providing tracking as a service, and
then that's even a better reason to potentially block these.

Phishing can still use PKCE and PAR, nor does WebAuthN provide protection
from this problem.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Sat, Dec 18, 2021 at 4:11 PM George Fletcher  wrote:

> Given the attack is based on a successfully registered callback URL that
> is malicious, we can also look to the Authorization Server to run more
> checks on the registered callback URLs (e.g. check against the "unsafe"
> URL list). Not a 100% solution by any means but could help with reduce
> the impact. Additionally, making sure the AS can easily revoke any
> client_id and have that take effect quickly.
>
> Another potential option would be to not allow prompt=none (or automatic
> redirects) from contexts where the user hasn't first gone through a full
> authentication flow or at least allow the AS to display UI at it's
> discretion. Though this will definitely break some flows :(
>
> This at least illuminates one of the dangers of allowing a wide open
> dynamic client registration model :)
>
> Thanks,
> George
>
> On 12/18/21 1:11 AM, David Waite wrote:
> >
> >> On Dec 17, 2021, at 2:44 PM, Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> >>
> >> Relax how aggressively OAuth demands that the AS automatically redirect
> in error conditions. And either respond with a 400 directly (which just
> stops things at that point) or provide a meaningful interstitial page to
> the user before redirecting them (which at least helps users see something
> is amiss). I do think OAuth is a bit overzealous in automatically returning
> the user's browser context to the client in error conditions. There are
> some situations (like prompt=none) that rely on the behavior but in most
> cases it isn't necessary or helpful and can be problematic.
> > The problem is that if prompt=none still requires redirection without
> prompt or interstitial, someone wishing to treat dynamic registrations of
> malicious sites as clients will just start using prompt=none. Likewise, a
> site could still attempt to manipulate the user to release information by
> imitating an extension to the authentication process, such as an "expired
> password change" prompt.
> >
> > I agree with Nov Matake's comment - phishing link email filters should
> treat all OAuth URLs as suspect, as OAuth has several security-recommended
> features like state and PKCE which do not work as expected/reliably with
> email. Filters integrated into the browser (such as based on the unsafe
> site list in Chrome) should not need changes, as they will warn on redirect
> to the known malicious site.
> >
> > We should also continue to push as an industry for authentication
> technologies like WebAuthn (as well as mutual TLS and Kerberos) which are
> phishing resistant. We are really talking about failure of a single
> phishing mitigation for _known_ malicious sites - the opportunity to use
> any unknown malicious site or a compromised legitimate site remains open
> even if we do suggest changes to error behavior.
> >
> > -DW
> >
> > ___
> > 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks

[Warren Parad]

You want to redirect on some errors because the last thing an AS wants is
to leave the user in the AS because the user can't do anything there and
the AS can't do anything either. It's just bad UX. But if the redirect url
isn't valid, this is absolutely the time that the AS should keep the user
there for user's protection.  Any AS redirecting the user to an invalid
redirect url, isn't doing the right thing.

But that only solves the illegitimate phishing urls, it doesn't solve the
class of problem where a phishing application is legitimately registered.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Fri, Dec 17, 2021 at 9:23 PM Pieter Kasselman  wrote:

> Agreed that the attackers goal is to bypass phishing filters and they
> found a way to achieve this by using an IdP that adheres to the standards.
> I don’t have the context for the design choice to redirect on an error
> condition, but am curious why the IdP should not be allowed to handle the
> error condition, rather than redirect (or at least have the option to do
> so)?
>
>
>
> *From:* OAuth  *On Behalf Of *Vittorio Bertocci
> *Sent:* Friday 17 December 2021 19:55
> *To:* Warren Parad 
> *Cc:* oauth 
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth Redirection Attacks
>
>
>
> The attack doesn't rely on redirecting to unregistered URLs, that's the
> problem.
>
> The goal of the attack is to circumvent phishing filters, by presenting a
> URL from a legitimate domain (the AS) that eventually redirects to the
> actual phishing URL. The actual phishing page doesn't need to target the
> same authorization server, or an authorization server at all for that
> matter.
>
> An attacker can register a legitimate app on any authorization server as a
> service, on their own tenant. The goal is just to have a starting URL that
> phishing filters won't block, and the attacker is in full control of the
> redirect URIs they register in their own tenant.
>
>
>
> My take: it might be tricky to change the redirect on error behavior at
> this point, but we should at least note the issue in the security
> considerations/BCPs and possibly give some advice. For example, on top of
> my head: AS should expose their endpoints on a domain dedicated to
> OAuth/OIDC operations, and avoid using its top level domains (different
> area/service, but think herokuapp.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fherokuapp.com%2F=04%7C01%7Cpieter.kasselman%40microsoft.com%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744175760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=UKsLcroZJVlu8HPo2lG9oFGeAT5RZsTUcEbhD0pZP8M%3D=0>
> vs heroku.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fheroku.com%2F=04%7C01%7Cpieter.kasselman%40microsoft.com%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744175760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=9hsxq2ZxK%2FwBJTe5RGIFZSTJ0icXcvEiLsBDXhdn8Rk%3D=0>)
> so that if a phishing filter decides to block direct links to the issuing
> endpoints will only impact things like IdP initiated flows (solvable by
> adding jumpstart endpoints on the RP anyway, just like IdP initiated sign
> in works in OIDC). I am sure there are lots of other things we can come up
> with that can make the problem better.
>
>
>
> On Fri, Dec 17, 2021 at 5:00 AM Warren Parad  40rhosys...@dmarc.ietf.org> wrote:
>
> I think this just falls into the category of never redirect the user to a
> url that doesn't match one of the preregistered redirect urls (or logout
> urls for that matter). Any application that has redirects anywhere provides
> an opportunity for this attack vector, OAuth isn't unique in that way, it
> just is consistent and documented. And the 2.1 draft is pretty clear on
> this front:
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04#section-4.1.2.1
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-oauth-v2-1-04%23section-4.1.2.1=04%7C01%7Cpieter.kasselman%40microsoft.com%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744226186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=3EUcWa6IS4l67nLHRSP13J0Q0SAgNXCDiO%2B22GSoNLM%3D=0>
>
>If the request fails due to a missing, invalid, or mismatching
>redirect URI, or if the client identifier is missing or invalid, the
>authorization server SHOULD inform the resource owner of the error

Re: [OAUTH-WG] OAuth Redirection Attacks

[Warren Parad]

I think this just falls into the category of never redirect the user to a
url that doesn't match one of the preregistered redirect urls (or logout
urls for that matter). Any application that has redirects anywhere provides
an opportunity for this attack vector, OAuth isn't unique in that way, it
just is consistent and documented. And the 2.1 draft is pretty clear on
this front:

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04#section-4.1.2.1

>If the request fails due to a missing, invalid, or mismatching
>redirect URI, or if the client identifier is missing or invalid, the
>authorization server SHOULD inform the resource owner of the error
>and
> *MUST NOT automatically redirect the user agent to the invalid   redirect
> URI*.


I want to call this attack vector "*illegitimate* phishing applications"
which is easily blocked by preregistration and/or PARs. And is only a very
small subset of phishing attacks with OAuth, of which the larger group is "
*legitimate* phishing applications". An app can be registered correctly,
and still issue a phishing attack as phishing attacks through OAuth are
actually indistinguishable from standard user delegation. There is no way
to prevent these without an application review before registration is
completed, here's an example that cloned Google apps y creating a fake app
called *google defender*:
https://www.trendmicro.com/en_us/research/17/d/pawn-storm-abuses-open-authentication-advanced-social-engineering-attacks.html

If we can't protect against these latter ones, I hardly think protecting
against the former is useful/interesting/valuable.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Thu, Dec 16, 2021 at 9:05 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
>
> An article was recently published discussing some OAuth Redirection
> Attacks to try to bypass phishing detection solutions. See the details of
> these attacks in the following link:
>
>
>
> https://www.proofpoint.com/us/blog/cloud-security/microsoft-and-github-oauth-implementation-vulnerabilities-lead-redirection
>
>
> The article discusses attacks on Microsoft and GitHub, but these attacks
> are not unique to these companies.
>
> The attacks take advantage of how OAuth handles error responses, which
> sends responses to the application’s redirect URL.
>
> I would like to get the thoughts of the working group on these types of
> attacks.
>
> What is the best way to mitigate these attacks?
>
> Do we need a new approach for handling errors with OAuth?
>
> Regards,
>
>  Rifaat
>
> ___
> 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

Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

[Warren Parad]

Now it seems we have two different conversations:
(1) Is it possible to prevent malicious extensions without preregistration
(or manual intervention)
(2) Is it possible to actually prevent auth code reused in a distributed
system

For (1), it seems like the suggestion is that the *request (uri)* parameter
helps to evade MITM attacks on DPoP, if anything it just delegates the
exact same problem to another vulnerable location, and hopes that it gets
solved. If I'm missing something, I would appreciate a concrete explanation
here, I want to understand that we aren't just pushing the issue somewhere
else. Furthermore, I think we have to assume preregistration is not
possible, not because it isn't doable, but because it would undermine a
core amount of value provided by allowing unregistered jwks, and we should
seek to ensure that AS always work with unregistered jwks, which means
likely never encouraging way to register them out of band.

(2) Is really interesting, when you put it like that, instead of "it is
difficult", but really "it is impossible", then that is the first time we
actually open up the discussion in a productive way. So I want to really
thank you for suggesting the challenge here in a transparent way. Having
thought about it for the last four days, I'm starting to agree with that
sentiment, *there is no way to build a reliable single-use auth code in a
distributed system*. (without of course requiring the auth code to be
returned the AS shard that created it, if the client calls the same shard,
then we have a solution, but I'll grant that ensuring repeat communication
with the same AS shard to be challenging enough to warrant avoiding the
architecture.)

I also really like the idea of binding cryptographic material to every
possible step of the authorization pipeline. But the key word here is
possible. Passing the dpop_jwk isn't possible in every scenario. I want to
point out that scenarios involving only a SPA does this work. For scenarios
involving more than one entity in the exchange, e.g. those with
confidential clients, we must not require passing the dpop_jwk as the
user-agent will not by default nor should not know about the dpop keys that
are associated with the confidential client. Requiring this, circumvents
PARs originating from these clients, and should instead be part of the PAR
and NOT part of the authorization url.

For this reason, dpop security is at the decision of the client not the AS,
and as such (assuming dpop_jwk is the correct parameter) dpop_jwk should be
optional by decision of the client, and the AS must handle situations both
where it is provided and where it isn't. For me the language here is *the
dpop_jwk MUST NOT be required by AS...*, and must handle dpop scenarios
where the DPOP signature is provided during a later code exchange step or
earlier in the PAR. Which means the AS must accept the jwk as optional at
every step, PAR, authorization url, and during the auth code exchange. We
can encourage earlier usage, but we should not require it, let this be a
security consideration for clients. For confidential clients, since the
client secret is already required there should be no vulnerability in the
client sending the dpop_jwk during code exchange.

On to the parameter, I really dislike *dpop_jwk* as an authorization
parameter additionally for the following reasons:
* it's coupled to DPoP
* it's a single string property
* it has coupled semantics about how it must be used (i.e. this is a jwk)
That means it does not support the following:
* need for multiple jwks
* other cryptographic material based signatures that have cnf needs
* consistency with the rest of how DPoP is used, in this case we use a
fingerprint of the JWK rather than the DPoP signature, but every other step
in all of DPoP requires a signature.

At the very least we should call this *cnf_list* allowing for a list of JWK
thumbprints, or any other kind of thumbprint as necessary. I'm not saying
this is a good solution, but it is certainly better than a single property
called *dpop_jwk*.

Here's something: Moving the introduction of the jwk to the authorization
or PAR actually enables us to ignore needing the DPOP signature at any
stage for interactions with the AS. This is awesome. I'll repeat. The AS
never needs to care about DPoP because the tokens generated are bound to
the client's DPoP key jwk thumbprint and so even if you give the access
token to a malicious actor, they can't do anything with it. Removing the
need for the AS to care about DPoP in any way is a huge win.

I'm sure I missed a critical part of this somewhere, so I would appreciate
any insight others have.

- Warren

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Sat, Dec 11, 2021 at 2:51 AM Will Bartlett  wrote:

> Hi folks,
>
> I'm a colleague of Pieter and Mike, working directly on the service code.
> I