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] convert to credentialed client... ( was OAuth2.1 credentialed client )

[Domingos Creado]

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  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 NOT or SHOULD NOT for
>> credentialed clients vs confidential clients. Without that, the distinction
>> seems it should be self contained in 2.1 like the client profiles, and
>> maybe the term confidential client be explained to be a misnomer and more
>> broadly explained that confidential vs public client is _not_ to meant to
>> be a described as a trust distinction.
>>
>> -DW
>>
>
> *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] convert to credentialed client... ( was OAuth2.1 credentialed client )

[Brian Campbell]

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  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 NOT or SHOULD NOT for
> credentialed clients vs confidential clients. Without that, the distinction
> seems it should be self contained in 2.1 like the client profiles, and
> maybe the term confidential client be explained to be a misnomer and more
> broadly explained that confidential vs public client is _not_ to meant to
> be a described as a trust distinction.
>
> -DW
>

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

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

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

[David Waite]

> 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 NOT or SHOULD NOT for credentialed 
clients vs confidential clients. Without that, the distinction seems it should 
be self contained in 2.1 like the client profiles, and maybe the term 
confidential client be explained to be a misnomer and more broadly explained 
that confidential vs public client is _not_ to meant to be a described as a 
trust distinction.

-DW
___
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 )

[Brian Campbell]

I understand that struggle and honestly really have no idea how to phrase
it better. Maybe using words more like what you just described as the
intent? And/or discuss this at the interim. Or... that particular bit of
text could maybe just be removed... maybe?

To me "identifying a client" evoked memories of the text in the last
paragraph of https://datatracker.ietf.org/doc/html/rfc6749?#section-3.2.1
which talks about a client using the client_id request parameter to
"identify itself"[***]. That text in 6749 has kinda formed a mental model
for me where client identification (just with id) is weaker than client
authentication (id + credential), which makes the "MUST NOT rely on
credentialed client authentication for the purpose of identifying the
client" text feel contradictory. Though when looking back at 6749 I notice
that https://datatracker.ietf.org/doc/html/rfc6749?#section-2.3 has very
similar text so maybe the contradiction is only in my mind. But I dunno -
what would establishing an authentication method with a public client even
entail? And what would that mean for the vast majority of public clients
(SPA & native on device) where there are many instances of the client that
share the same client id? What else other than identifying would a client
identifier with established credential be used for?

I suppose that, if I were to have a suggestion, it would be for those two
sentences to be removed from
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#section-2.4
and the intent as you describe it be more/better included in the client
types section
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#name-client-types



*** It looks like this bit of text from 6749,

   "A client MAY use the "client_id" request parameter to identify itself
   when sending requests to the token endpoint.  In the
   "authorization_code" "grant_type" request to the token endpoint, an
   unauthenticated client MUST send its "client_id" to prevent itself
   from inadvertently accepting a code intended for a client with a
   different "client_id".  This protects the client from substitution of
   the authentication authorization code.  (It provides no additional
security for the
   protected resource.)"

has been dropped from v2.1. But should probably be put back. It's implied
in the draft by the client_id text in
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#name-token-endpoint
that says ""client_id":  REQUIRED, if the client is not authenticating with
the authorization server ..." But that text came from
https://datatracker.ietf.org/doc/html/rfc6749?#section-4.1.3 which is
contextually specific to the code grant and shouldn't have been moved into
a general token endpoint requirement. There are grant types / token
endpoint requests that allow for an unauthenticated and unidentified client
and so can be made with no client auth and no client_id parameter. So, to
summarize, put the lost text back into
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#section-3.2.1
or maybe better into
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#section-4.1.3
and move the "client_id" bit from
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#section-3.2.2
to the authz code part
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#section-4.1.3



On Mon, 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.
>
> How to phrase and describe this would be welcome!
>
>
> ᐧ
>
> On Mon, Oct 11, 2021 at 10:35 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> Credentialed clients might be worthwhile item for the interim. I think I
>> sorta get what the credentialed clients distinction is trying to do but the
>> way it manifests in the draft is somewhat bewildering. One example I've
>> struggled to make sense of is the following text from
>> https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#section-2.4
>> - I honestly don't understand what it really means and what actual
>> ramifications would be to implementations/deployments:
>>
>> "The authorization server MAY establish a client authentication method
>> with public clients, which converts them to credentialed clients. However,
>> the authorization server MUST NOT rely on credentialed client
>> authentication for the purpose of identifying the client."
>>
>>
>> On Fri, Oct 8, 2021 at 8:57 PM Ash Narayanan 
>> wrote:
>>
>>> 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 

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

[Dick Hardt]

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.

How to phrase and describe this would be welcome!


ᐧ

On Mon, Oct 11, 2021 at 10:35 AM Brian Campbell  wrote:

> Credentialed clients might be worthwhile item for the interim. I think I
> sorta get what the credentialed clients distinction is trying to do but the
> way it manifests in the draft is somewhat bewildering. One example I've
> struggled to make sense of is the following text from
> https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#section-2.4
> - I honestly don't understand what it really means and what actual
> ramifications would be to implementations/deployments:
>
> "The authorization server MAY establish a client authentication method
> with public clients, which converts them to credentialed clients. However,
> the authorization server MUST NOT rely on credentialed client
> authentication for the purpose of identifying the client."
>
>
> On Fri, Oct 8, 2021 at 8:57 PM Ash Narayanan 
> wrote:
>
>> 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
>>
>
> *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

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

[Brian Campbell]

Credentialed clients might be worthwhile item for the interim. I think I
sorta get what the credentialed clients distinction is trying to do but the
way it manifests in the draft is somewhat bewildering. One example I've
struggled to make sense of is the following text from
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#section-2.4 -
I honestly don't understand what it really means and what actual
ramifications would be to implementations/deployments:

"The authorization server MAY establish a client authentication method with
public clients, which converts them to credentialed clients. However, the
authorization server MUST NOT rely on credentialed client authentication
for the purpose of identifying the client."


On Fri, Oct 8, 2021 at 8:57 PM Ash Narayanan 
wrote:

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

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