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. How to phrase and describe this would be welcome! ᐧ On Mon, Oct 11, 2021 at 10:35 AM Brian Campbell <bcampbell= 40pingidentity....@dmarc.ietf.org> wrote: > Credentialed clients might be worthwhile item for the interim. I think I > sorta get what the credentialed clients distinction is trying to do but the > way it manifests in the draft is somewhat bewildering. One example I've > struggled to make sense of is the following text from > https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#section-2.4 > - I honestly don't understand what it really means and what actual > ramifications would be to implementations/deployments: > > "The authorization server MAY establish a client authentication method > with public clients, which converts them to credentialed clients. However, > the authorization server MUST NOT rely on credentialed client > authentication for the purpose of identifying the client." > > > On Fri, Oct 8, 2021 at 8:57 PM Ash Narayanan <ashvinnaraya...@gmail.com> > wrote: > >> I'm not sure if these items have been brought up previously or are >> already on the agenda to be discussed at the interim meeting. >> >> 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. >> >> >> Cheers, >> Ash >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *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
