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

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

[Warren Parad]

I'm glad you brought this up, since Signatures can already be used with
OAuth, the question is exactly that. What are the ways using these together
without an explicit RFC would cause a problem? I'm not totally sure that
makes sense, so let me give an example. If the draft says "we need to
exchange keys, but it isn't part of the draft" and we have that for every
section, what's the benefit of the RFC in the first place. Sure PoP needs a
solution, is it solved without an RFC for anyone using OAuth and the
Signature draft as is, or is there something meaningful that needs to be
documented?

Without providing author recommendations in the form of filling in at least
part of the draft, instead of the question being *is this the right way to
solve this part of the problem* it becomes *should we even have a draft.*

The one part of the draft that does exist is "Introduction of a new token
type", which if we say:

> The RS can get that through introspection, through something in the token
> itself (like the JWT “cnf” claim)


Then the obvious conclusion should be: we don't need a new token type. So
if we remove that from that draft, it brings me back to the original point,
what problem does this particular draft solve as part of PoP, other than
saying we should have PoP via message signatures because message signatures
can provide PoP.

We could say things like "Key exchange needs to be defined so that..." or
"a new claim needs to be added so that...", but I fear we haven't done that
with the draft so far.

Obviously this is only my perspective, which isn't saying let's not do
this, it is "sure let's do this as long as we can answer these questions".
Right now I'm not convinced of this actually solving the PoP situation for
me, while it is a valid argument, it isn't a sound one, due to its
implementation relying on Signatures and how Signatures is constructed at
this moment.

So rather than "this is PoP", let's focus on the problems needed to solve
for PoP Signatures to work.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Thu, Oct 14, 2021 at 4:51 PM Justin Richer  wrote:

> I wanted to jump back to the top of the thread to point out something that
> seems to be getting missed:
>
>
> This is not a call for adoption of HTTP Message Signatures. That document
> already exists in the HTTP WG and will be published as an RFC from that
> group. If you want to have discussions  about  how the HTTP Message
> Signatures specification works, come  to the HTTP working group for those
>  discussions.
>
> This is a call for adoption of an OAuth application of the HTTP Message
> Signatures spec. Signatures will exist with or without the OAuth WG’s use
> of it, and I would argue that people are going to attach OAuth access
>  tokens to requests  using HTTP Message Signatures whether or not  the
> OAuth WG picks up the work. The question is whether those  applications are
> going to be isolated profiles and silos, like they are today, or whether
> there can be one way to use them together across different systems.
>
> My recommendation is that  the OAuth WG define how exactly HTTP Message
> Signatures should be  used  with OAuth, which is what  this proposal is
>  for.
>
>  — Justin
>
>
> On Oct 6, 2021, at 5:01 PM, 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
>
>
> ___
> 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 - OAuth Proof of Possession Tokens with HTTP Message Signature

[Justin Richer]

I wanted to jump back to the top of the thread to point out something that 
seems to be getting missed:


This is not a call for adoption of HTTP Message Signatures. That document 
already exists in the HTTP WG and will be published as an RFC from that group. 
If you want to have discussions  about  how the HTTP Message Signatures 
specification works, come  to the HTTP working group for those  discussions.

This is a call for adoption of an OAuth application of the HTTP Message 
Signatures spec. Signatures will exist with or without the OAuth WG’s use of 
it, and I would argue that people are going to attach OAuth access  tokens to 
requests  using HTTP Message Signatures whether or not  the OAuth WG picks up 
the work. The question is whether those  applications are going to be isolated 
profiles and silos, like they are today, or whether there can be one way to use 
them together across different systems.

My recommendation is that  the OAuth WG define how exactly HTTP Message 
Signatures should be  used  with OAuth, which is what  this proposal is  for.

 — Justin


> On Oct 6, 2021, at 5:01 PM, 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

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

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

[Justin Richer]

> On Oct 14, 2021, at 8:47 AM, Warren Parad  
> wrote:
> 
> I feel like there are a bunch of pieces of the implementation fundamentally 
> missing here, so we are back to, as it is right now, the draft isn't 
> sufficient.

Of course the draft isn’t sufficient for  publication — that’s what the call 
for adoption is all about! It’s not meant to say “this is done, let’s ship it”, 
it’s meant  to say “this is an idea, let’s finish it in the WG”.

> What prevents the signature from being used without this RFC?

I’m not sure what you’re asking here. HTTP Message Signatures  can be  used 
without the OAuth-specific RFC. Someone could also use HTTP Signatures with 
OAuth tokens without following anything from the OAuth WG. There are people 
doing that today in the wild, using the  predecessors  of the  HTTP Message 
Signatures draft and their own grafting.

> How do you do expect the symmetric key exchange to be oauth compliant?

I can think of a number of approaches that would work: Pre-registration of 
keys, key derivation functions, cloud key escrow systems — these are things 
that the OAuth profile of HTTP Signatures would have to answer, as I laid out 
in my presentation.

> How does the RS know that there is supposed to be a signature, if the client 
> doesn't provide it?

The same way that it knows there’s supposed to be a particular MTLS certificate 
or DPoP Proof today — the token metadata. The RS can get that through 
introspection, through something in the token itself (like the JWT “cnf” 
claim), or some other internal system. 

 — Justin

> 
>   
> Warren Parad
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement Authress 
> .
> 
> 
> On Wed, Oct 13, 2021 at 11:55 PM Richard Backman, Annabelle 
> mailto:richa...@amazon.com>> wrote:
>> If keeping DPoP simple means we have to have come up with 10 different 
>> variants to handle all the different cases that it doesn't support, then it 
>> isn't keeping it simple, it is just pushing the problem forward to the 
>> implementers to figure out which set of RFCs to implement.
> 
> I'm hoping we can stop at 3: mTLS, DPoP, and Justin's draft. If someone has 
> use cases that aren't covered by one or more of those, they should bring 
> those up so we can discuss them and decide what changes are warranted. 
> (Either here, or in HTTPbis if changes should be made to Message Signatures) 
> My preference would've been to stop at 2, but the consensus has not been in 
> favor of expanding the scope of use cases served by DPoP.
> 
> 
>> If there are really so many cases, then I think we need to focus on 
>> recreating PoP in an extensible way that allows the DPoP to sit on top, and 
>> other RFCs to be layered in without a bunch of RFCs to all have competing 
>> semantics.
> 
> This is what we are doing with Message Signatures. We're providing a general 
> purpose signature mechanism, which higher-level protocols can build on.
> 
> 
>> Here's a great example. I think having an additional header is unjustified, 
>> DPoP, Signature, or whatever you want to call it. But the only thing more 
>> unjustified than that is having different headers for different 
>> implementations of PoP. We can start with a new Draft that just says, PoP 
>> header is X, end of story, might as well call it Authorization-Extra-Info, 
>> and then layer in what you want in there.
> 
> I can see the argument for DPoP including the proof in the `Authorization` 
> header field, since the proof is intrinsically related to the access token 
> and request authorization – not making a judgement on that, as this is the 
> wrong thread and I don't have a horse in that race. Packing everything into a 
> single header field doesn't make sense for Message Signatures, since they may 
> or may not have anything to do with request authorization, access tokens, or 
> anything of the sort. Additionally, the use of separate `Signature-Input` and 
> `Signature` header fields allows us to have a very simple field syntax using 
> Structured Field Values for HTTP 
> , and makes it easy for 
> intermediaries to chain signatures. (E.g., a reverse proxy might add an 
> `X-Forwarded-For` header field, and add a Message Signature covering that 
> header field plus the PoP signature included by the client.) …and I'll stop 
> there lest we dive into topics for the HTTPbis WG.
> 
> —
> Annabelle Backman (she/her)
> richa...@amazon.com 
> 
> 
> 
> 
>> On Oct 13, 2021, at 12:01 PM, Warren Parad > > 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.
>> 
>> 
>> If keeping DPoP simple means we have to have come up with 10 different 
>> variants to handle all the different cases that it doesn't support, then it 
>> isn't keeping it 

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

[Warren Parad]

I feel like there are a bunch of pieces of the implementation fundamentally
missing here, so we are back to, as it is right now, the draft isn't
sufficient. What prevents the signature from being used without this RFC?
How do you do expect the symmetric key exchange to be oauth compliant? How
does the RS know that there is supposed to be a signature, if the client
doesn't provide it?

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Oct 13, 2021 at 11:55 PM Richard Backman, Annabelle <
richa...@amazon.com> wrote:

> If keeping DPoP simple means we have to have come up with 10 different
> variants to handle all the different cases that it doesn't support, then it
> isn't keeping it simple, it is just pushing the problem forward to the
> implementers to figure out which set of RFCs to implement.
>
>
> I'm hoping we can stop at 3: mTLS, DPoP, and Justin's draft. If someone
> has use cases that aren't covered by one or more of those, they should
> bring those up so we can discuss them and decide what changes are
> warranted. (Either here, or in HTTPbis if changes should be made to Message
> Signatures) My preference would've been to stop at 2, but the consensus has
> not been in favor of expanding the scope of use cases served by DPoP.
>
>
> If there are really so many cases, then I think we need to focus on
> recreating PoP in an extensible way that allows the DPoP to sit on top, and
> other RFCs to be layered in without a bunch of RFCs to all have competing
> semantics.
>
>
> This is what we are doing with Message Signatures. We're providing a
> general purpose signature mechanism, which higher-level protocols can build
> on.
>
>
> Here's a great example. I think having an additional header is
> unjustified, DPoP, Signature, or whatever you want to call it. But the only
> thing more unjustified than that is having different headers for different
> implementations of PoP. We can start with a new Draft that just says, PoP
> header is X, end of story, might as well call it
> *Authorization-Extra-Info*, and then layer in what you want in there.
>
>
> I can see the argument for DPoP including the proof in the `Authorization`
> header field, since the proof is intrinsically related to the access token
> and request authorization – not making a judgement on that, as this is the
> wrong thread and I don't have a horse in that race. Packing everything into
> a single header field doesn't make sense for Message Signatures, since they
> may or may not have anything to do with request authorization, access
> tokens, or anything of the sort. Additionally, the use of separate
> `Signature-Input` and `Signature` header fields allows us to have a very
> simple field syntax using Structured Field Values for HTTP
> , and makes it easy for
> intermediaries to chain signatures. (E.g., a reverse proxy might add an
> `X-Forwarded-For` header field, and add a Message Signature covering that
> header field plus the PoP signature included by the client.) …and I'll stop
> there lest we dive into topics for the HTTPbis WG.
>
> —
> Annabelle Backman (she/her)
> richa...@amazon.com
>
>
>
>
> On Oct 13, 2021, at 12:01 PM, Warren Parad  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.
>
> If keeping DPoP simple means we have to have come up with 10 different
> variants to handle all the different cases that it doesn't support, then it
> isn't keeping it simple, it is just pushing the problem forward to the
> implementers to figure out which set of RFCs to implement.
>
> I would agree with keeping DPoP simple if it meant that 99% of problems
> were solved, in which case the question would be why do we need this RFC,
> and if what is here is so common, then what good is the DPoP one? Simple is
> useless if it is never used.
>
> If there are really so many cases, then I think we need to focus on
> recreating PoP in an extensible way that allows the DPoP to sit on top, and
> other RFCs to be layered in without a bunch of RFCs to all have competing
> semantics.
>
> Here's a great example. I think having an additional header is
> unjustified, DPoP, Signature, or whatever you want to call it. But the only
> thing more unjustified than that is having different headers for different
> implementations of PoP. We can start with a new Draft that just says, PoP
> header is X, end of story, might as well call it
> *Authorization-Extra-Info*, and then layer in what you want in there.
> Then the number of differences through these refactoring between these two
> drafts becomes smaller. Surely we can agree to a draft that contains only
> the semantics that are the same between the existing two, and then reuse
> the same terminology and the same implementation, header name, etc...
>
> We 

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

[Warren Parad]

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 .


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

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