It may not be exactly the same issue Warren but it's definitely related. "whether an AS knows about the client" is related to what Brian pointed out about the AS identifying the client, which comes back to what I said originally about how credentialed is currently defined in two parts: a) Clients that have credentials b) Clients that have no prior relationship with the AS
Your enums for known/unknown and the issue of identification relates to part (b), which as I've mentioned, comes down to what "prior relationship" means. If it means that the AS has previously generated credentials for this client then that would explain why part (b) exists. However, if it means that the AS has no prior *arrangement* with the client, such as verifying the redirect_uri in the registration request to be from a list of allowed ones, then I would argue that (b) does not hold. In either case, "prior relationship" is sure to cause confusion, and as you're said, being credentialed is independent of this anyway. So my recommendation would be to drop (b) altogether. The problem then is (again) what I originally mentioned; (a) by itself does not differentiate the definition from that of a confidential client. Hence why I suggested a better (and complete) definition for credentialed could just be: *Clients that dynamically obtain their credentials* Done; no more confusion about prior relationship or identification. On Thu, Oct 14, 2021 at 8:17 PM Warren Parad <wpa...@rhosys.ch> wrote: > I'm not sure this is exactly the issue, but I also found the naming of > *credentialed > client* to be confusing. It would seem to me we have an enum whose values > do not form an orthonormal basis. In other words, whether or not a client > is credentialed is independent from whether an AS knows about the client. > Does having credentials make this client different in some way, not really. > It would seem to me better to assign the labels of: > * public / confidential > * known / unknown (or anonymous) client. > > Given the fact that an AS doesn't know about the client, does it really > matter if it is credentialed? I would suggest instead of calling unknown > credentialed client as such, that we use *anonymous, unknown, or > unregistered*. And let the aspect of whether they are credentialed or > not, drive other behaviors. > > Warren Parad > > Founder, CTO > Secure your user data with IAM authorization as a service. Implement > Authress <https://authress.io/>. > > > On Thu, Oct 14, 2021 at 11:01 AM Ash Narayanan <ashvinnaraya...@gmail.com> > wrote: > >> Hi Brian, >> >> I'm all for pivoting, as long as the original concerns raised are >> addressed or even acknowledged, but since they weren't, here is the >> original message again in its entirety. >> >> Cheers, >> Ash >> >> === >> >> 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. >> >> _______________________________________________ >> 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
