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 <[email protected]> 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 > [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
