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= 40alkaline-solutions....@dmarc.ietf.org> wrote: > > > 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 > -- _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
