Re: [OAUTH-WG] convert to credentialed client... ( was OAuth2.1 credentialed client )

[Ash Narayanan <[e-mail]>]

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.