This works for me: > 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.
I know the WG likely spent a bit of time coming up with the term 'credentialed', and it is a good concept, but the term appears to be creating confusion. Both confidential/credentialed are required to have credentials; the only distinction the way I see it is the manner in which these clients obtain their credentials. With confidential, it's static (with credential rotation if needed), and with credentialed, it's dynamic. This distinction can be part of the *subtleties* that can be talked about under 2.4, as Brian mentions. Now that just leaves the issue of what goes under sec 2.1. It could just contain the examples of different client types as it currently has (web-based, browser-based, native,...). Domingos wrote: > I guess it is fair to say that when we are talking about credentialed > clients, we are targeting native apps > I don't see why it doesn't also apply to browser-based apps such as SPAs. This goes back to my original point of why the following comment currently only exists for native apps under 2.1: > On the other hand, dynamically issued credentials such as access tokens > or refresh, tokens can receive an acceptable level of protection. On Sat, Oct 16, 2021 at 8:01 AM Domingos Creado < domingos.cre...@authlete.com> wrote: > I guess it is fair to say that when we are talking about credentialed > clients, we are targeting native apps that after getting installed use a > ceremony (probably using Dynamic client registration) to establish a > credential for that specific instance on AS. Do you foresee other use cases? > Back to David's point, the trust on that client depends upon the ceremony > for establishing the credential or actions the resource owner might take > after that. For instance: here in Brazil, some banks require you to go to > an ATM to "approve" the client, and after that, access restrictions are > lifted. > In my point of view, the credentialed concept does not bring enough > semantics to be used on the document, as there are too many moving parts > that build or not the trust on the client. > I think it makes more sense to shed some light on scope granting > considering the trust on the confidential client and/or the assurance of > the authentication. > > On Fri, Oct 15, 2021 at 3:34 PM Brian Campbell <bcampbell= > 40pingidentity....@dmarc.ietf.org> wrote: > >> 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 >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
