> On Oct 11, 2021, at 11:52 AM, Dick Hardt <dick.ha...@gmail.com> 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
