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

[Brian Campbell <[e-mail]>]

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 <[e-mail]> 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 <bcampbell=
> [e-mail]> 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 <[e-mail]>
>> 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
>>> [e-mail]
>>> 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
>> [e-mail]
>> 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._