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

[Dick Hardt <[e-mail]>]

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
>