Re: [OAUTH-WG] SUB and AUD configuration for web identity authentication

[Ash Narayanan]

Hm, interesting Warren.
AWS feels like both the AS and RS in this scenario; I don’t see any reason why 
these have to be separate entities.

> 
> On 20 Oct 2021, at 7:48 pm, Warren Parad  
> wrote:
> 
> 
> There is a pattern, where a user configures one credentialed entity for 
> access to a RS, but controls neither the credentialed entity nor the RS. I 
> might say technically the user is acting as the AS, but it isn't clear to me.
> 
> Concretely, CI/CD services such as GitHub and GitLab support runners that 
> come with a JWT, whom this JWT should be issued to is not exactly clear. 
> These tokens are intended to be used with third party RS such as AWS IAM to 
> authenticate and access resources in AWS. (AWS reference)
> 
> Currently, GitLab is prototyping support for this access and wants to know 
> what's a good meaningful value for the AUD to be. (GitLab context)
> 
> Personally, while I'm able to specify who is the client, RS, and AS, it 
> doesn't feel exactly like it's something directly supported by any RFC, but 
> it does seem like it should be. (AWS = RS, gitlab job = user, gitlab server = 
> AS)
> 
> Due to the nature of what's available for configuration on both sides, it's 
> likely they want to go with altering the AUD to point itself at the git 
> repository url where the token comes from rather than the RS which would like 
> be the AWS account. The closing thought I have is if we suspend for one 
> moment expectations about who is authorization by whom, it's possible to also 
> see that AWS is the AS, and the gitlab runner is a client using the 
> jwt-bearer credentials grant.
> 
> Is there anyone that wants to weigh in on this, it's a potentially great 
> opportunity to drive the right practice at the right time.
> 
> (I'm happy to relay any outcome back to the thread or feel free to post 
> directly on the Gitlab issue.
> 
> - Warren
> 
> 
> Warren Parad
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement Authress.
> ___
> 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] convert to credentialed client... ( was OAuth2.1 credentialed client )

[Ash Narayanan]

This works for me:

> As such, I'd suggest removing the credentialed concept entirely and using
> sec 2.4, as appropriate or needed, to discuss the subtleties of the various
> ways clients establish themselves with an AS and the implications to the
> amount of trust that can be placed therein.


I know the WG likely spent a bit of time coming up with the term
'credentialed', and it is a good concept, but the term appears to be
creating confusion. Both confidential/credentialed are required to have
credentials; the only distinction the way I see it is the manner in which
these clients obtain their credentials. With confidential, it's static
(with credential rotation if needed), and with credentialed, it's dynamic.
This distinction can be part of the *subtleties* that can be talked about
under 2.4, as Brian mentions.

Now that just leaves the issue of what goes under sec 2.1. It could just
contain the examples of different client types as it currently has
(web-based, browser-based, native,...).

Domingos wrote:

> I guess it is fair to say that when we are talking about credentialed
> clients, we are targeting native apps
>

I don't see why it doesn't also apply to browser-based apps such as SPAs.
This goes back to my original point of why the following comment currently
only exists for native apps under 2.1:

>  On the other hand, dynamically issued credentials such as access tokens
> or refresh, tokens can receive an acceptable level of protection.



On Sat, Oct 16, 2021 at 8:01 AM Domingos Creado <
domingos.cre...@authlete.com> wrote:

> I guess it is fair to say that when we are talking about credentialed
> clients, we are targeting native apps that after getting installed use a
> ceremony (probably using Dynamic client registration) to establish a
> credential for that specific instance on AS. Do you foresee other use cases?
> Back to David's point, the trust on that client depends upon the ceremony
> for establishing the credential or actions the resource owner might take
> after that. For instance: here in Brazil, some banks require you to go to
> an ATM to "approve" the client, and after that, access restrictions are
> lifted.
> In my point of view, the credentialed concept does not bring enough
> semantics to be used on the document, as there are too many moving parts
> that build or not the trust on the client.
> I think it makes more sense to shed some light on scope granting
> considering the trust on the confidential client and/or the assurance of
> the authentication.
>
> On Fri, Oct 15, 2021 at 3:34 PM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> Looking/searching through
>> https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html and all
>> the occurrences of "credentialed" outside of sec 2.4 and the text I was
>> complaining about previously are treating confidential and credentialed the
>> same. I.e. "If the client is confidential or credentialed", "Confidential
>> or credentialed clients MUST", "authentication for confidential and
>> credentialed clients", etc. So the distinction/definition isn't serving a
>> meaningful function in the rest of the document. As such, I'd suggest
>> removing the credentialed concept entirely and using sec 2.4, as
>> appropriate or needed, to discuss the subtleties of the various ways
>> clients establish themselves with an AS and the implications to the amount
>> of trust that can be placed therein.
>>
>> On Mon, Oct 11, 2021 at 4:53 PM David Waite > 40alkaline-solutions@dmarc.ietf.org> wrote:
>>
>>>
>>> > On Oct 11, 2021, at 11:52 AM, Dick Hardt  wrote:
>>> >
>>> > 
>>> > Thanks for the feedback Brian. We have struggled in how to concisely
>>> describe credentialed clients.
>>> >
>>> > "identifying a client" can be interpreted a number of ways.
>>> >
>>> > The intent is that the AS knows a credentialed client is the same
>>> client it previously interacted with, but that the AS can not assume any
>>> other attributes of the client, for example that it is a client from a
>>> given developer, or has a specific name.
>>>
>>> It sounds like the goal is to distinguish authenticating the client from
>>> trust of the client pedigree, e.g. the only authenticity of a public client
>>> might be that it can catch the redirect_uri, and the only authenticity of a
>>> dynamically registered client is what you required and verified up to that
>>> point.
>>>
>>> Some of that trust may be on confidentiality of data, prior reputation,
>>> safeguards to prevent token exfiltration or unauthorized token use locally,
>>> etc.
>>>
>>> A credentialed client is not more trusted than a confidential client -
>>> it is just more uniquely identifiable. A public client does not have a
>>> mechanism (within OAuth today) to prove its trustworthiness on request
>>> because it is not authenticated as the party with that trust.  You instead
>>> would need to e.g. do client registration with a software statement.
>>>
>>> It may help to know what actions are MUST 

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

[Ash Narayanan]

>
>
>
>
>
>
>
> On Oct 15, 2021, at 8:27 AM, Mike Jones <
> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> I agree with Daniel.
>
>
>
> Also, while we’ve talked about server requirements, I think it’s equally
> important that we retain this client requirement:
>
>
>
> The client MUST NOT use the authorization code more than once.
>
>
>
>   -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Daniel Fett
> *Sent:* Friday, October 15, 2021 8:13 AM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Re: Authorization code reuse and OAuth 2.1
>
>
>
> I don't think that a MAY is appropriate here.
>
>
>
> I wasn't in the call yesterday, so I hope I don't miss anything here,
> but...
>
>
>
> Even with PKCE, the one-time use requirement of the code is still
> important. First and foremost, if we allow unlimited re-use of the same
> code, even just as an option, we change the semantics of this artifact. I
> guess there are many examples where this causes issues, but one would be
> DPoP. It assumes that there is only one (successful) token request and in
> that request, the token is bound to a specific key. If there can be more
> than one successful token request, all it takes is code_challenge and the
> code sitting around somewhere in accessible memory and an XSS attacker can
> exfiltrate them and use them on his own device, binding the resulting token
> to an attacker-controlled key. This is the attack outcome against which we
> introduced the nonce in DPoP. (Probably we should add this thought as a
> security consideration to DPoP, but that is a different topic.) I guess we
> can come up with many other mechanisms and mitigations that depend on code
> being one-time use.
>
>
>
> The attack described also shows nicely that code replay protection and
> PKCE serve similar purposes, but are not the same thing.
>
>
>
> The Security BCP introduces a second layer of defense at pretty much all
> the critical places in the protocol, because practice shows that a single
> defense can break too easily. For example, an attacker with read-only
> access to the token request would be pretty bad without code replay
> protections in place. Such attackers are considered in FAPI. (Somebody
> capable of reading system logs at the client or server, proxy logs at the
> client or server, browser logs, etc.)
>
>
>
> Therefore, in my opinion, the code MUST be short-lived and at least
> SHOULD, better MUST be one-time use.
>
>
>
> And ideally, the code SHOULD also be invalidated if the PKCE verifier does
> not match, not sure if that is in the current text or not.
>
>
>
> -Daniel
>
>
>
>
>
>
>
> Am 15.10.21 um 11:04 schrieb Pieter Kasselman:
>
> SHOULD is more likely to cause the right conversations to take place for
> implementors as they weigh the risks. Reducing it to MAY risks diluting it
> too much.
>
>
>
> *From:* OAuth   *On
> Behalf Of *Warren Parad
> *Sent:* Friday 15 October 2021 09:25
> *To:* Pieter Kasselman 
> 
> *Cc:* IETF oauth WG  
> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and
> OAuth 2.1
>
>
>
> I wouldn't be against lowering it to MAY but only if we stipulate a SHOULD
> on an expected lifetime of an authorization code. I think sending the
> message that these should be one time use except in exceptional
> circumstances.
>
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data with IAM authorization as a service. Implement
> Authress
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154740432%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=6rSI2UvnakrWNh3qtBEgIMbRO8L9oXu8zGj4Fd128B8%3D=0>
> .
>
>
>
>
>
> On Fri, Oct 15, 2021 at 10:17 AM Pieter Kasselman  40microsoft@dmarc.ietf.org> wrote:
>
> Any weakening of the requirement should include a clear outline of the
> risks to help implementors make informed decisions.
>
>
>
> *From:* OAuth  *On Behalf Of *Ash Narayanan
> *Sent:* Friday 15 October 2021 01:51
> *To:* Aaron Parecki 
> *Cc:* IETF oauth WG 
> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and
> OAuth 2.1
>
>
>
> You don't often get e

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

[Ash Narayanan]

>
> Yes, as I said before, authorization servers are free to enforce one-time
> use of the authorization code even if there isn't a requirement to. The
> proposal is just to remove the *requirement* of authorization servers
> enforcing it.
>

I agree, and therefore I think what it really ought to be is "MAY".

Annabelle said:

> There are legitimate use cases for a client to replay an authorization
> code. Connection failures happen. Servers fall over before completing
> requests. Users hit browser refresh buttons. Permitting replay of
> authorization codes (assuming valid PKCE, client creds, etc.) allows
> clients to handle these failure modes simply and gracefully via retries.


Couldn't agree more. Having experienced these exact use-cases, I can
honestly say that denying users a smooth experience just to be compliant
with the spec, which offers no additional security if PKCE is also being
used, makes no sense.
It is also more effort (from a repository layer perspective) to implement
one-time use than do PKCE verification.

What is the practical reason for allowing "plain" PKCE in OAuth 2.1? Are
> there really use cases out there where SHA-256 is a deal breaker?
>

I'd be interested in these use-cases as well (I can't think of any).

On Thu, Oct 14, 2021 at 8:36 AM Aaron Parecki  wrote:

> Yes, as I said before, authorization servers are free to enforce one-time
> use of the authorization code even if there isn't a requirement to. The
> proposal is just to remove the *requirement* of authorization servers
> enforcing it.
>
> I am okay with Mike's suggestion of changing the language to "SHOULD" to
> continue to point out the possibility of enforcing one-time authorization
> codes if desired.
>
>
>
> On Wed, Oct 13, 2021 at 2:15 PM Pieter Kasselman <
> pieter.kassel...@microsoft.com> wrote:
>
>> Log files can exist in lots of place (clients, servers, data lakes). The
>> question is whether it is a valid assumption that an attacker cannot obtain
>> an Authorization Code and a Code Verifier and present it a second time
>> round. Limiting the validity period is one layer of defence, PKCE is
>> another layer, one time use enforcement is another. Assuming breach and
>> designing from a defence in depth perspective is a good practice, so why
>> not give implementors options (and guidance) to add additional layers of
>> defence to match their risk profiles?
>>
>>
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *Sascha Preibisch
>> *Sent:* Wednesday 13 October 2021 22:06
>> *To:* Aaron Parecki 
>> *Cc:* IETF oauth WG 
>> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and
>> OAuth 2.1
>>
>>
>>
>> Ok, if the goal is to avoid unnecessary requirements I am suggesting to
>> point out why MUST was changed to SHOULD. Otherwise developers will start
>> to mix and match OAuth 2.0 and OAuth 2.1 requirements as they see them fit
>> their needs.
>>
>> In regards to encrypted values in PKCE, Aaron, I can also not confirm
>> that as the general implementation.
>>
>>
>>
>> On Wed, 13 Oct 2021 at 13:56, Aaron Parecki  wrote:
>>
>> The PKCE spec actually says "Typically, the "code_challenge" and
>> "code_challenge_method" values are stored in encrypted form in the "code"
>> itself" which I feel like might be a stretch to say that's typical, but
>> this scenario was clearly thought of ahead of time. Doing that would enable
>> an AS to avoid storing server-side state.
>>
>>
>>
>> On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch <
>> saschapreibi...@gmail.com> wrote:
>>
>> If the challenge is based on distributed authorization server
>> configurations, how would they handle PKCE? I imagine that managing the
>> state for PKCE is not less challenging than managing authorization codes on
>> the server side, preventing reuse of them.
>>
>> With that in mind I am not sure if I follow the given argument. I would
>> prefer to keep MUST as it is today.
>>
>>
>>
>>
>>
>> On Wed, 13 Oct 2021 at 13:37, Aaron Parecki  wrote:
>>
>> HTTPS, because if that's broken then the rest of OAuth falls apart too.
>>
>>
>>
>> On Wed, Oct 13, 2021 at 1:36 PM Warren Parad  wrote:
>>
>> I feel like I'm missing something, what stops just plain old network
>> sniffing and replying the whole encrypted payload to the AS and getting
>> back a valid token?
>>
>>
>> *Warren Parad*
>>
>> Founder, CTO
>>
>> Secure your user data with IAM authorization as a service. Implement
>> Authress
>> 
>> .
>>
>>
>>
>>
>>
>> On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki  wrote:
>>
>> Aside from the "plain" method, the PKCE code verifier never leaves the
>> client until it's sent along with the 

Re: [OAUTH-WG] convert to credentialed client... ( was OAuth2.1 credentialed client )

[Ash Narayanan]

It may not be exactly the same issue Warren but it's definitely related.
"whether an AS knows about the client" is related to what Brian pointed out
about the AS identifying the client, which comes back to what I said
originally about how credentialed is currently defined in two parts:
a) Clients that have credentials
b) Clients that have no prior relationship with the AS

Your enums for known/unknown and the issue of identification relates to
part (b), which as I've mentioned, comes down to what "prior relationship"
means. If it means that the AS has previously generated credentials for
this client then that would explain why part (b) exists. However, if it
means that the AS has no prior *arrangement* with the client, such as
verifying the redirect_uri in the registration request to be from a list of
allowed ones, then I would argue that (b) does not hold.

In either case, "prior relationship" is sure to cause confusion, and as
you're said, being credentialed is independent of this anyway.

So my recommendation would be to drop (b) altogether. The problem then is
(again) what I originally mentioned; (a) by itself does not differentiate
the definition from that of a confidential client. Hence why I suggested a
better (and complete) definition for credentialed could just be:
*Clients that dynamically obtain their credentials*

Done; no more confusion about prior relationship or identification.

On Thu, Oct 14, 2021 at 8:17 PM Warren Parad  wrote:

> I'm not sure this is exactly the issue, but I also found the naming of 
> *credentialed
> client* to be confusing. It would seem to me we have an enum whose values
> do not form an orthonormal basis. In other words, whether or not a client
> is credentialed is independent from whether an AS knows about the client.
> Does having credentials make this client different in some way, not really.
> It would seem to me better to assign the labels of:
> * public / confidential
> * known / unknown (or anonymous) client.
>
> Given the fact that an AS doesn't know about the client, does it really
> matter if it is credentialed? I would suggest instead of calling unknown
> credentialed client as such, that we use *anonymous, unknown, or
> unregistered*. And let the aspect of whether they are credentialed or
> not, drive other behaviors.
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress <https://authress.io/>.
>
>
> On Thu, Oct 14, 2021 at 11:01 AM Ash Narayanan 
> wrote:
>
>> Hi Brian,
>>
>> I'm all for pivoting, as long as the original concerns raised are
>> addressed or even acknowledged, but since they weren't, here is the
>> original message again in its entirety.
>>
>> Cheers,
>> Ash
>>
>> ===
>>
>> Referring to the latest draft (
>> https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html) ...
>>
>> 1. The definition given under section 2.1 Client Types is:
>>
>>> Clients that have credentials but no prior relationship with the AS are
>>> designated as "credentialed clients"
>>
>>
>> This does not seem like the best or even the right definition to me. The
>> definition as it stands, is in two parts:
>> a) "Clients that have credentials"
>> b) Clients that have "no prior relationship with the AS"
>>
>> With (a), the typical use-case is an app that runs on the end-user device
>> and dynamically registers itself with the AS. Such a client does not "have"
>> credentials to begin with, or at least the use of the word "have" here, if
>> it's intended to mean "at some point will have", does not differentiate it
>> from confidential clients, which are also defined to be clients "that have
>> credentials".
>> Instead, a better choice of words for credentialed clients may be
>> "Clients that dynamically obtain credentials".
>>
>> (b) is not necessarily true, because the credentialed client may very
>> well be a known client and therefore have a prior relationship with the AS.
>> Think of (common) scenarios where the AS and client are both part of the
>> same organisation or a peer organisation, and therefore the client metadata
>> an AS receives in a dynamic registration request is already known to the
>> AS. An AS may only decide to accept dynamic registrations from such known
>> clients.
>>
>> Of course I may not be interpreting "prior relationship" as it may be
>> intended, in which case that needs to be clarified somewhere.
>>
>>
>> 2. Continuing with section 

Re: [OAUTH-WG] convert to credentialed client... ( was OAuth2.1 credentialed client )

[Ash Narayanan]

Hi Brian,

I'm all for pivoting, as long as the original concerns raised are addressed
or even acknowledged, but since they weren't, here is the original message
again in its entirety.

Cheers,
Ash

===

Referring to the latest draft (
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html) ...

1. The definition given under section 2.1 Client Types is:

> Clients that have credentials but no prior relationship with the AS are
> designated as "credentialed clients"


This does not seem like the best or even the right definition to me. The
definition as it stands, is in two parts:
a) "Clients that have credentials"
b) Clients that have "no prior relationship with the AS"

With (a), the typical use-case is an app that runs on the end-user device
and dynamically registers itself with the AS. Such a client does not "have"
credentials to begin with, or at least the use of the word "have" here, if
it's intended to mean "at some point will have", does not differentiate it
from confidential clients, which are also defined to be clients "that have
credentials".
Instead, a better choice of words for credentialed clients may be "Clients
that dynamically obtain credentials".

(b) is not necessarily true, because the credentialed client may very well
be a known client and therefore have a prior relationship with the AS.
Think of (common) scenarios where the AS and client are both part of the
same organisation or a peer organisation, and therefore the client metadata
an AS receives in a dynamic registration request is already known to the
AS. An AS may only decide to accept dynamic registrations from such known
clients.

Of course I may not be interpreting "prior relationship" as it may be
intended, in which case that needs to be clarified somewhere.


2. Continuing with section 2.1 Client Types, for a native application, it
says:

> On the other hand, dynamically issued credentials such as access tokens or
> refresh tokens can receive an acceptable level of protection.


Why is this also not mentioned for a browser-based application? Unless I'm
 mistaken, in terms of accessibility for an intruder, in-memory for a
native app is equivalent to in-memory for an SPA and local storage for a
native app is equivalent to local storage for an SPA.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth2.1 credentialed client

[Ash Narayanan]

I'm not sure if these items have been brought up previously or are already
on the agenda to be discussed at the interim meeting.

Referring to the latest draft (
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html) ...

1. The definition given under section 2.1 Client Types is:

> Clients that have credentials but no prior relationship with the AS are
> designated as "credentialed clients"


This does not seem like the best or even the right definition to me. The
definition as it stands, is in two parts:
a) "Clients that have credentials"
b) Clients that have "no prior relationship with the AS"

With (a), the typical use-case is an app that runs on the end-user device
and dynamically registers itself with the AS. Such a client does not "have"
credentials to begin with, or at least the use of the word "have" here, if
it's intended to mean "at some point will have", does not differentiate it
from confidential clients, which are also defined to be clients "that have
credentials".
Instead, a better choice of words for credentialed clients may be "Clients
that dynamically obtain credentials".

(b) is not necessarily true, because the credentialed client may very well
be a known client and therefore have a prior relationship with the AS.
Think of (common) scenarios where the AS and client are both part of the
same organisation or a peer organisation, and therefore the client metadata
an AS receives in a dynamic registration request is already known to the
AS. An AS may only decide to accept dynamic registrations from such known
clients.

Of course I may not be interpreting "prior relationship" as it may be
intended, in which case that needs to be clarified somewhere.


2. Continuing with section 2.1 Client Types, for a native application, it
says:

> On the other hand, dynamically issued credentials such as access tokens or
> refresh tokens can receive an acceptable level of protection.


Why is this also not mentioned for a browser-based application? Unless I'm
 mistaken, in terms of accessibility for an intruder, in-memory for a
native app is equivalent to in-memory for an SPA and local storage for a
native app is equivalent to local storage for an SPA.


Cheers,
Ash
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Ash Narayanan]

Oh geez, yesterday was my day off but ended up down a deep rabbit hole
after reading this draft and the ones that came before it.

I do not support adoption and was going to list my reasons but Warren Parad
beat me to it.

In addition to the list he has provided, I'd also like to see the draft
make a mention of public clients; obviously we can't use any sensitive keys
with these.


Regards,
Ash

On Thu, Oct 7, 2021 at 11:02 PM Neil Madden 
wrote:

> Canonicalised signature schemes inevitably lead to cryptographic doom, and
> should die with SAML (ha!). For that reason I do not support adoption of
> this draft.
>
> I also think the arguments for canonicalisation vanish as soon as you want
> end-to-end confidentiality too.
>
> — Neil
>
> On 6 Oct 2021, at 22:02, Rifaat Shekh-Yusef 
> wrote:
>
> 
> All,
>
> As a followup on the interim meeting today, this is a *call for adoption *for
> the *OAuth Proof of Possession Tokens with HTTP Message Signature* draft
> as a WG document:
> https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/
>
> Please, provide your feedback on the mailing list by* October 20th*.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> Manage My Preferences , Unsubscribe
> 
>
> ___
> 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] RFC7009 (6663)

[Ash Narayanan]

>
> According to this specification, a client's request must contain a
>valid client_id, in the case of a public client, or valid client
>credentials, in the case of a confidential client.
>
>

On Thu, Sep 2, 2021 at 6:22 PM Warren Parad  wrote:

> Can you point out where it says that, I think I must of missed it.
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress <https://authress.io/>.
>
>
> On Thu, Sep 2, 2021 at 10:21 AM Ash Narayanan 
> wrote:
>
>> Hey Warren,
>>
>> 7009 states that you need to pass just the client_id for public clients,
>> so if:
>>
>>> The client_id isn't necessary.
>>>
>>
>> Then obviously something about 7009 needs to change.
>>
>> Whichever angle you look at, 7009 needs to change.
>>
>> On Thu, Sep 2, 2021 at 5:16 PM Warren Parad  wrote:
>>
>>> Great, then let's fix 6749 not this one. The client_id isn't necessary.
>>>
>>> And then wouldn't 7009 not need to be changed because it already says
>>> you don't need to pass any authorization for public clients?
>>>
>>> For credentialled client issued grants, refresh tokens, and access
>>> tokens, these must not be able to be revoked without client credentials, so
>>> using the refresh token or access token only for all other client types
>>> must not be supported.
>>>
>>> On Thu, Sep 2, 2021, 08:52 Ash Narayanan 
>>> wrote:
>>>
>>>> Hi Warren,
>>>>
>>>> If you are referring to the client_id as arbitrary information, then
>>>> the same would also be true for refresh requests to the token endpoint from
>>>> public clients.  As per 6749, you need to pass the client_id along with the
>>>> refresh token. The client_id adds no additional security.
>>>>
>>>> But really, the whole point I've been trying to make from the start is
>>>> that the token itself should be the only form of 'security' needed...as
>>>> that's the point of OAuth.
>>>>
>>>> Regardless, 7009 needs to be made obsolete by a newer RFC.
>>>>
>>>> Ash
>>>>
>>>> On Thu, Sep 2, 2021 at 4:41 PM Warren Parad  wrote:
>>>>
>>>>> What's the point in passing arbitrary other information that is
>>>>> already known by the AS and does not provide the level of security
>>>>> necessary to prevent abuse of the revocation endpoint?
>>>>>
>>>>> On Thu, Sep 2, 2021, 01:12 Ash Narayanan 
>>>>> wrote:
>>>>>
>>>>>> Hi Thomas,
>>>>>>
>>>>>> The approach you've suggested sounds good. Passing just the client_id
>>>>>> along with the token and type (regardless of client type) would be
>>>>>> consistent with how refresh_token requests are structured. As long as the
>>>>>> new RFC obsoletes this one.
>>>>>>
>>>>>> Ash
>>>>>> ___
>>>>>> 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] RFC7009 (6663)

[Ash Narayanan]

Hey Warren,

7009 states that you need to pass just the client_id for public clients, so
if:

> The client_id isn't necessary.
>

Then obviously something about 7009 needs to change.

Whichever angle you look at, 7009 needs to change.

On Thu, Sep 2, 2021 at 5:16 PM Warren Parad  wrote:

> Great, then let's fix 6749 not this one. The client_id isn't necessary.
>
> And then wouldn't 7009 not need to be changed because it already says you
> don't need to pass any authorization for public clients?
>
> For credentialled client issued grants, refresh tokens, and access tokens,
> these must not be able to be revoked without client credentials, so using
> the refresh token or access token only for all other client types must not
> be supported.
>
> On Thu, Sep 2, 2021, 08:52 Ash Narayanan 
> wrote:
>
>> Hi Warren,
>>
>> If you are referring to the client_id as arbitrary information, then the
>> same would also be true for refresh requests to the token endpoint from
>> public clients.  As per 6749, you need to pass the client_id along with the
>> refresh token. The client_id adds no additional security.
>>
>> But really, the whole point I've been trying to make from the start is
>> that the token itself should be the only form of 'security' needed...as
>> that's the point of OAuth.
>>
>> Regardless, 7009 needs to be made obsolete by a newer RFC.
>>
>> Ash
>>
>> On Thu, Sep 2, 2021 at 4:41 PM Warren Parad  wrote:
>>
>>> What's the point in passing arbitrary other information that is already
>>> known by the AS and does not provide the level of security necessary to
>>> prevent abuse of the revocation endpoint?
>>>
>>> On Thu, Sep 2, 2021, 01:12 Ash Narayanan 
>>> wrote:
>>>
>>>> Hi Thomas,
>>>>
>>>> The approach you've suggested sounds good. Passing just the client_id
>>>> along with the token and type (regardless of client type) would be
>>>> consistent with how refresh_token requests are structured. As long as the
>>>> new RFC obsoletes this one.
>>>>
>>>> Ash
>>>> ___
>>>> 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] RFC7009 (6663)

[Ash Narayanan]

Hi Warren,

If you are referring to the client_id as arbitrary information, then the
same would also be true for refresh requests to the token endpoint from
public clients.  As per 6749, you need to pass the client_id along with the
refresh token. The client_id adds no additional security.

But really, the whole point I've been trying to make from the start is that
the token itself should be the only form of 'security' needed...as that's
the point of OAuth.

Regardless, 7009 needs to be made obsolete by a newer RFC.

Ash

On Thu, Sep 2, 2021 at 4:41 PM Warren Parad  wrote:

> What's the point in passing arbitrary other information that is already
> known by the AS and does not provide the level of security necessary to
> prevent abuse of the revocation endpoint?
>
> On Thu, Sep 2, 2021, 01:12 Ash Narayanan 
> wrote:
>
>> Hi Thomas,
>>
>> The approach you've suggested sounds good. Passing just the client_id
>> along with the token and type (regardless of client type) would be
>> consistent with how refresh_token requests are structured. As long as the
>> new RFC obsoletes this one.
>>
>> Ash
>> ___
>> 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] RFC7009 (6663)

[Ash Narayanan]

Hi Thomas,

The approach you've suggested sounds good. Passing just the client_id along
with the token and type (regardless of client type) would be consistent
with how refresh_token requests are structured. As long as the new RFC
obsoletes this one.

Ash
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663)

[Ash Narayanan]

Hi Torsten,

Thanks for clarifying. The errata system allows for two types of errata,
editorial and technical. I selected technical when I submitted this
particular one. Things like typos and ambiguities sound like editorial to
me, unless I'm mistaken.

I'd be fine with submitting a new RFC so as to not change the security
assumptions of this spec, though I'm not sure what then would be the
purpose of a technical errata?

Cheers,
Ash

On Tue, Aug 31, 2021 at 5:29 PM Torsten Lodderstedt 
wrote:

> Hi Ash,
>
> Am 31.08.2021 um 02:42 schrieb Ash Narayanan :
>
> Hi Dick,
>
> >The access token represents the authorization to access the resource(s) --
> >it does not represent the authorization to manipulate tokens.
>
> Anything for which the client must have an access token to access is a
> protected resource. In order to revoke a token, the client must have the
> associated access token to begin with, hence a protected resource. If not a
> protected resource, it is implied anyone can access it, and the OAuth spec
> makes no assertions about where a protected resource must be located so
> there's no reason it can't be on the AS as well.
>
> Emond describes it quite neatly:
> >> I see it like returning a key when you no longer need access to a
> building.
> >> The fact that you hold the key should be enough for you to be able to
> return it.
>
> So you shouldn't be returning a key you never had.
>
> Anything for which you *may* use a client_secret if you have one or not
> if you don't is generally a red flag. In RFC 7009 as I've pointed out, the
> client_id is being used as a security measure as it's part of the
> authentication header. Furthermore, it also mentions an attacker
> *guessing* it (in addition to the token). The client_id is by no means a
> secure item on a non-confidential client such as an SPA.
>
> Also you say:
> > Changing the spec would change the security assumptions that existing
> deployments have made.
>
> Isn't that the nature of the business? Or are you implying that no
> deployment should ever change even if improvements are found?
>
>
> Certainly not. However, an errata is not supposed to change the security
> assumptions of a spec. It is supposed to fix typos and clarify ambiguities.
> Changing the security assumptions or applying other normative changes is
> subject to new RFCs replacing the older ones.
>
> So from my perspective, your inquiry exceeds the scope of an errata.
>
> best regards,
> Torsten.
>
>
> Ash
>
>
> >Hey Emond
> >
> >The access token represents the authorization to access the resource(s) --
> >it does not represent the authorization to manipulate tokens. The client
> >credentials are used for token management. While your implementation may
> be
> >ok with using the access token to revoke itself, it is not the security
> >model represented by the specification. Changing the spec would change the
> >security assumptions that existing deployments have made.
> >
> >As noted in your response, the CLI has access to the client credentials to
> >revoke. Besides convenience, it is not clear to me why you would not want
> >to require the client credentials -- but it is your implementation -- you
> >can make your own decisions where and if you want to be compliant.
> >
> >Warren: an interesting idea to provide more context on this in OAuth 2.1.
> >
> >/Dick
> >ᐧ
> >
> >On Tue, Aug 24, 2021 at 8:10 AM Emond Papegaaij <
> emond.papega...@gmail.com>
> >wrote:
> >
> >> On Tue, Aug 24, 2021 at 12:14 PM Warren Parad  wrote:
> >>
> >>> I think it is worth pointing out, if we were to agree with the errata,
> >>> that this particular use case probably isn't relevant:
> >>>
> >>> Our client in this case was a command line tool, which only requests
> the
> >>>> client credentials on login. It then fetches an access token and
> stores
> >>>> this locally. The client credentials are not stored by default.
> >>>
> >>>
> >>> Unless I misunderstand, I'll take "client credentials" to mean client
> Id
> >>> and client credentials via a client credentials grant. And therefore,
> is
> >>> not the correct flow to be used in a command line tool. Client
> credentials
> >>> are used in private when there are many user agents that could connect
> >>> through it, I would not recommend this as the solution here, and even
> if it
> >>> were, you would indeed have access to the client id and secret, so it
> would
> >>> not be a problem to use them 

Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663)

[Ash Narayanan]

Hi Dick,

>The access token represents the authorization to access the resource(s) --
>it does not represent the authorization to manipulate tokens.

Anything for which the client must have an access token to access is a
protected resource. In order to revoke a token, the client must have the
associated access token to begin with, hence a protected resource. If not a
protected resource, it is implied anyone can access it, and the OAuth spec
makes no assertions about where a protected resource must be located so
there's no reason it can't be on the AS as well.

Emond describes it quite neatly:
>> I see it like returning a key when you no longer need access to a
building.
>> The fact that you hold the key should be enough for you to be able to
return it.

So you shouldn't be returning a key you never had.

Anything for which you *may* use a client_secret if you have one or not if
you don't is generally a red flag. In RFC 7009 as I've pointed out, the
client_id is being used as a security measure as it's part of the
authentication header. Furthermore, it also mentions an attacker *guessing*
it (in addition to the token). The client_id is by no means a secure item
on a non-confidential client such as an SPA.

Also you say:
> Changing the spec would change the security assumptions that existing
deployments have made.

Isn't that the nature of the business? Or are you implying that no
deployment should ever change even if improvements are found?

Ash


>Hey Emond
>
>The access token represents the authorization to access the resource(s) --
>it does not represent the authorization to manipulate tokens. The client
>credentials are used for token management. While your implementation may be
>ok with using the access token to revoke itself, it is not the security
>model represented by the specification. Changing the spec would change the
>security assumptions that existing deployments have made.
>
>As noted in your response, the CLI has access to the client credentials to
>revoke. Besides convenience, it is not clear to me why you would not want
>to require the client credentials -- but it is your implementation -- you
>can make your own decisions where and if you want to be compliant.
>
>Warren: an interesting idea to provide more context on this in OAuth 2.1.
>
>/Dick
>ᐧ
>
>On Tue, Aug 24, 2021 at 8:10 AM Emond Papegaaij 
>wrote:
>
>> On Tue, Aug 24, 2021 at 12:14 PM Warren Parad  wrote:
>>
>>> I think it is worth pointing out, if we were to agree with the errata,
>>> that this particular use case probably isn't relevant:
>>>
>>> Our client in this case was a command line tool, which only requests the
 client credentials on login. It then fetches an access token and stores
 this locally. The client credentials are not stored by default.
>>>
>>>
>>> Unless I misunderstand, I'll take "client credentials" to mean client Id
>>> and client credentials via a client credentials grant. And therefore, is
>>> not the correct flow to be used in a command line tool. Client
credentials
>>> are used in private when there are many user agents that could connect
>>> through it, I would not recommend this as the solution here, and even
if it
>>> were, you would indeed have access to the client id and secret, so it
would
>>> not be a problem to use them to revoke the token.
>>>
>>
>> The CLI-tool actually supports both a 3-legged (via the device
>> authorization grant) and a 2-legged flow (via the client credentials
>> grant). It depends on the use case which one is appropriate. In the case
of
>> a user logging in to access the application via the CLI, it clearly is
the
>> 3-legged flow, however when the CLI is used in a script that runs without
>> user interaction, it's the 2-legged flow. In this later case, the script
>> often fetches the credentials from some store, uses them to acquire an
>> access token, does it job, and revokes the token. Naturally, it can fetch
>> the credentials a second time to revoke the token, but I really don't see
>> the point in this case. The client merely indicates it is done with the
>> token and it can now be revoked. It is good practice to discard any
>> credentials when you are done with them to minimize the chance of abuse.
>> However, requiring the client authentication to revoke the token, really
>> complicates this case and will probably lead to scripts not revoking the
>> token.
>>
>>
>>> However, I believe there is something fundamentally broke here, because
>>> there are two use cases which are in conflict with each other:
>>>
>>>- I as a user, at any time want to revoke one of, access token,
>>>refresh token, or granted scopes associated with my identity by
directly
>>>communicating with an AS. I never want to make this request through a
>>>client, and more specifically, I never want a client to determine
whether
>>>or not I'm allowed to revoke these.
>>>- I as a user, at no time want to allow a client, for whom I did not
>>>give permission to revoke