Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-1-04.txt

From: [email-masked]
Date: Tue, 05 Oct 2021 17:19:24 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : The OAuth 2.1 Authorization Framework
        Authors         : Dick Hardt
                          Aaron Parecki
                          Torsten Lodderstedt
	Filename        : draft-ietf-oauth-v2-1-04.txt
	Pages           : 85
	Date            : 2021-10-05

Abstract:
   The OAuth 2.1 authorization framework enables a third-party
   application to obtain limited access to an HTTP service, either on
   behalf of a resource owner by orchestrating an approval interaction
   between the resource owner and an authorization service, or by
   allowing the third-party application to obtain access on its own
   behalf.  This specification replaces and obsoletes the OAuth 2.0
   Authorization Framework described in RFC 6749.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-1-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 7 Oct 2021 10:57:18 -0700

Hello all, on Tuesday we published a new revision of the OAuth 2.1 draft in
advance of the interim meeting next week.

The main changes are documented in the changelog section but are summarized
below as well:

* Added explicit mention of not sending access tokens in URI query strings
* Clarifications on definition of client types
* Consolidated text around loopback vs localhost
* Editorial clarifications throughout the document

There are still a number of outstanding issues we are aware of, and have
highlighted a few of them for discussion during the session next week.

Aaron

On Tue, Oct 5, 2021 at 5:19 PM <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Ash Narayanan <[email-masked]>
Date: Sat, 9 Oct 2021 13:56:52 +1100

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

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Oct 2021 11:34:39 -0600

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-masked]>
wrote:

>> On the other hand, dynamically issued credentials such as access tokens
>> or refresh tokens can receive an acceptable level of protection.
>
>

-- 
_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._

---

From: Dick Hardt <[email-masked]>
Date: Mon, 11 Oct 2021 10:50:53 -0700

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=
[email-masked]> wrote:

> 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
> "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."
>
>
>> 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.
>>
>> 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.
>> 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
> *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-masked]

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Oct 2021 14:56:27 -0600

I understand that struggle and honestly really have no idea how to phrase
it better. Maybe using words more like what you just described as the
intent? And/or discuss this at the interim. Or... that particular bit of
text could maybe just be removed... maybe?

To me "identifying a client" evoked memories of the text in the last
paragraph of https://datatracker.ietf.org/doc/html/rfc6749?#section-3.2.1
which talks about a client using the client_id request parameter to
"identify itself"[***]. That text in 6749 has kinda formed a mental model
for me where client identification (just with id) is weaker than client
authentication (id + credential), which makes the "MUST NOT rely on
credentialed client authentication for the purpose of identifying the
client" text feel contradictory. Though when looking back at 6749 I notice
that https://datatracker.ietf.org/doc/html/rfc6749?#section-2.3 has very
similar text so maybe the contradiction is only in my mind. But I dunno -
what would establishing an authentication method with a public client even
entail? And what would that mean for the vast majority of public clients
(SPA & native on device) where there are many instances of the client that
share the same client id? What else other than identifying would a client
identifier with established credential be used for?

I suppose that, if I were to have a suggestion, it would be for those two
sentences to be removed from
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#section-2.4
and the intent as you describe it be more/better included in the client
types section
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#name-client-types

*** It looks like this bit of text from 6749,

   "A client MAY use the "client_id" request parameter to identify itself
   when sending requests to the token endpoint.  In the
   "authorization_code" "grant_type" request to the token endpoint, an
   unauthenticated client MUST send its "client_id" to prevent itself
   from inadvertently accepting a code intended for a client with a
   different "client_id".  This protects the client from substitution of
   the authentication authorization code.  (It provides no additional
security for the
   protected resource.)"

has been dropped from v2.1. But should probably be put back. It's implied
in the draft by the client_id text in
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#name-token-endpoint
that says ""client_id":  REQUIRED, if the client is not authenticating with
the authorization server ..." But that text came from
https://datatracker.ietf.org/doc/html/rfc6749?#section-4.1.3 which is
contextually specific to the code grant and shouldn't have been moved into
a general token endpoint requirement. There are grant types / token
endpoint requests that allow for an unauthenticated and unidentified client
and so can be made with no client auth and no client_id parameter. So, to
summarize, put the lost text back into
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#section-3.2.1
or maybe better into
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#section-4.1.3
and move the "client_id" bit from
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#section-3.2.2
to the authz code part
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html#section-4.1.3

On Mon, Oct 11, 2021 at 11:52 AM Dick Hardt <[email-masked]> wrote:

> 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
>>> 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".
>>> 2. Continuing with section 2.1 Client Types, for a native application,
>>> it says:
>>>

---

From: David Waite <[email-masked]>
Date: Mon, 11 Oct 2021 16:53:46 -0600

> On Oct 11, 2021, at 11:52 AM, Dick Hardt <[email-masked]> wrote:
> 
> 
> Thanks for the feedback Brian. We have struggled in how to concisely describe credentialed clients.
> 
> 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

---

From: Ash Narayanan <[email-masked]>
Date: Thu, 14 Oct 2021 20:00:56 +1100

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

===

---

From: Warren Parad <[email-masked]>
Date: Thu, 14 Oct 2021 11:17:11 +0200

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 <[email-masked]>
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
>
> ===
>

---

From: Ash Narayanan <[email-masked]>
Date: Fri, 15 Oct 2021 11:24:52 +1100

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 <[email-masked]> wrote:

> I'm not sure this is exactly the issue, but I also found the naming of *credentialed
> unregistered*. And let the aspect of whether they are credentialed or
> not, drive other behaviors.
>
> Warren Parad
>
> Founder, CTO

---

From: Brian Campbell <[email-masked]>
Date: Fri, 15 Oct 2021 12:33:58 -0600

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=
[email-masked]> wrote:

> 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
>

---

From: Domingos Creado <[email-masked]>
Date: Fri, 15 Oct 2021 18:01:16 -0300

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=
[email-masked]> wrote:

>> > 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.
>>

---

From: Ash Narayanan <[email-masked]>
Date: Sat, 16 Oct 2021 12:45:13 +1100

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:

> 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:

> or refresh, tokens can receive an acceptable level of protection.

On Sat, Oct 16, 2021 at 8:01 AM Domingos Creado <
[email-masked]> wrote:

>> 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
>>> A credentialed client is not more trusted than a confidential client -
>>> it is just more uniquely identifiable. A public client does not have a