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

[Brian Campbell <[e-mail]>]

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 <david=
[e-mail]> wrote:

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