Subject: [OAUTH-WG] OAuth 2.1-03 - WG adoption?

From: Dick Hardt <[email-masked]>
Date: Mon, 6 Jul 2020 09:43:50 -0700

Aaron, Torsten, and I -- with some help from Daniel -- have created a new
version of draft-pareck-oauth-v2-1. I think we are ready for a WG adoption
call (assuming the updated charter).

Here is the doc:

https://tools.ietf.org/html/draft-parecki-oauth-v2-1-03

Here is a link to the diff from -02:

https://tools.ietf.org/rfcdiff?url2=draft-parecki-oauth-v2-1-03.txt

This version incorporates feedback from the WG, as well as editorial
changes to improve readability. Highlights:

- Appendix of current known extensions, and references to the Appendix so
that readers become aware of related work.

- defined new client type - credentialed clients - a client that has
credentials, but the AS has not confirmed the identity of the client.
Confidential clients have had their identity confirmed by the AS. We talked
about changing the names of confidential and public, but thought that would
be confusing. This new definition cleans up the text substantially.

- consistent use of redirect URI rather than mixing in redirect endpoint
URI and redirect endpoint.

- adopted new language on when PKCE is required.

- removed IANA section (nothing new is in 2.1)

/ Dick

---

From: Sascha Preibisch <[email-masked]>
Date: Mon, 6 Jul 2020 14:44:48 -0700

Hi all!

I am reading through this document for the first time. I am mainly
looking at it in comparison to OAuth 2.0 (RFC 6749) and with the eyes
of a developer. I am trying to understand where phrases have changed
and, of course, where features are changing.

What is the best way to provide feedback? In this mailing list?

Thanks,
Sascha

On Mon, 6 Jul 2020 at 09:44, Dick Hardt <[email-masked]> wrote:
>
> Aaron, Torsten, and I -- with some help from Daniel -- have created a new version of draft-pareck-oauth-v2-1. I think we are ready for a WG adoption call (assuming the updated charter).
>
> Here is the doc:
>
> This version incorporates feedback from the WG, as well as editorial changes to improve readability. Highlights:
>
> - Appendix of current known extensions, and references to the Appendix so that readers become aware of related work.
>
> - defined new client type - credentialed clients - a client that has credentials, but the AS has not confirmed the identity of the client. Confidential clients have had their identity confirmed by the AS. We talked about changing the names of confidential and public, but thought that would be confusing. This new definition cleans up the text substantially.
>
> - consistent use of redirect URI rather than mixing in redirect endpoint URI and redirect endpoint.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Mon, 6 Jul 2020 15:19:20 -0700

Hey Sascha

This slide below from one of Aaron's presentations may help guide you what
OAuth 2.1 is about.

There are no "new" features -- everything already exists.
There are no changed definitions. We added "credentialed" client.

Yes, this list is the right place to discuss the OAuth 2.1 doc ... :)

/Dick

ᐧ

On Mon, Jul 6, 2020 at 2:46 PM Sascha Preibisch <[email-masked]>
wrote:

> > Aaron, Torsten, and I -- with some help from Daniel -- have created a
> new version of draft-pareck-oauth-v2-1. I think we are ready for a WG
> adoption call (assuming the updated charter).
> >
> > Here is the doc:
> >
> > - Appendix of current known extensions, and references to the Appendix
> so that readers become aware of related work.
> >

---

From: Sascha Preibisch <[email-masked]>
Date: Mon, 6 Jul 2020 16:00:00 -0700

Thanks, Dick!

That slide compares easier than the documents next to each other, for sure!

I will continue with my comparison and provide feedback as soon as I feel
it's worth talking about it.

Regards,
Sascha

---

From: Sascha Preibisch <[email-masked]>
Date: Tue, 7 Jul 2020 11:45:21 -0700

Hi Dick and all others!

I have started to write my feedback. This is the first part, please let me
know if it works like this.

I have compared these documents:

- https://tools.ietf.org/html/draft-parecki-oauth-v2-1-03 (draft)
- https://tools.ietf.org/html/rfc6749v (current)

I am addressing changes in the format of the document and the content.
In general, I am a fan of required changes only. If wordings change,
it may cause more confusion than it helps, especially if the message
is still the same as before.

Thanks,
Sascha

===

General:
- keep the format of the current document. It makes it easier to find
actual differences
- for example: in diagrams keep (A), (B), ... instead of (1), (2), ....
- in the section 'OAuth defines four roles' keep 'resource owner\n'
instead of "resource owner": . The same for all other roles. I do not
see any value content wise or in regards to the readability of the
document
- Lists in current use 'o' whereas draft uses '*'. If it stays the
same, comparisons show less differences

Section: 1.1 Roles
-------------------------

"OAuth defines four roles"
- for 'resource owner' and 'authorization server' add the abbreviation
to the name, i.e.: resource owner (RO)
- I believe resource owner and authorization server are not sometimes
abbreviated as RO or AS but always

Section 2. Client Registration
-------------------------

Draft and current document:
"When registering a client, the client developer SHALL"
- It would be good to change SHALL to MUST
- As far as I understand they are semantically equal but SHALL often
causes discussions in dev teams as it is interpreted as 'MAYBE OR
MAYBE NOT'
- This is also the only location where SHALL is used

Section 2.1. Client Types
-------------------------

Draft:
"OAuth 2.1 defines three client types:"

Current:
"OAuth defines two client types, based on their ability to
authenticate securely with the authorization server (i.e., ability to
maintain the confidentiality of their client credentials):"

I would like to see this text in the draft. It emphasizes the main
difference between client types:
"... based on their ability to authenticate securely with the
authorization server (i.e., ability to maintain the confidentiality of
their client credentials)"

===

Draft:

"Confidential"
- the description has changed. Are existing confidential clients still
of type confidential?

"Credentialed"
- Is this a 'to be' confidential client?
- If the credentials have been registered at the AS, how are they not
also confirmed at the same time?
- If this is meant as a client that can act as a public and
confidential client, depending on the flow, maybe that could be
expressed here. If that is the case, it should be listed as the third
option. That way, its description could reference confidential and
public
- Suggestion: "Clients that have credentials and are able to act as
public and confidential client"

"Public"
- the description now states these are clients without credentials. Do
they still have a client_id?
- Suggestion: Clients incapable of maintaining a client secret

===

Draft:
- "browser-based application"

Current:
- user-agent-based application

- Were these terms changed due to a general change in the language the
developers use?
- Otherwise, if there is no urgent reason, I am suggesting to keep the
current definition

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 8 Jul 2020 01:21:06 +0300

I find 03 well structured, well written and it shows that a lot of
thought and work has gone into it.

If this is a formal call for adoption - I support it.

> Confidential clients have had their identity confirmed by the AS. We
> talked about changing the names of confidential and public, but
> thought that would be confusing. This new definition cleans up the
> text substantially.

I understand why this new client type was introduced. For the reader who
is not familiar with the recent OAuth RFCs and drafts - I suspect this
can still be confusing. There will likely be questions -- Why does this
difference between confidential and credentialed matter? What is a
concrete example of a credentialed client?

Also, people will likely ask themselves - what does the confirmation of
a (credentialed) client's identity by the AS actually mean and do?
(section 2.1)

>    Authorization servers SHOULD consider the level of confidence in a
>    client's identity when deciding whether they allow such a client
>    access to more critical functions, such as the Client Credentials
>    grant type.

Again, normative text that relies on the implementer being able to
assign levels of confidence in the client's identity, but is not
immediately obvious how to go about this.

There is mention in 9.1 about "enlisting the resource owner to confirm
identity" and "if there is a web application whose developer's identity
was verified...". But this talk about client identity is secondary and
happens in the context of client authentication.

Perhaps it will make sense to promote the discussion about identity to a
new 9.x section "Client identity" or "Client Identification", before
"Client Authentication". Addressing the topics what client identity is,
why does it matter (especially for security), and the "confirmation by
the AS". Then proceed with "Client Authentication" which now is freed to
focus on the credentials / auth methods aspects.

>    Such credentials are either issued by the
>    authorization server or registered by the developer of the client
>    with the authorization server.

Credentials (public key) can also be registered by a client performing
dynamic registration (section 2.1)

Vladimir

---

From: Sascha Preibisch <[email-masked]>
Date: Tue, 7 Jul 2020 16:02:46 -0700

Hi all!

Here is the rest of my feedback. At the end I also included a list of
typos and the summary of changes that I have found between RFC 6739
and the current draft.

Regards,
Sascha

Section 2.3. Client Authentication
-------------------------

Draft and current:
- both documents contain this description: "... the authorization
server (e.g., password, public/private key pair)"
- since the client usually uses a 'client secret', maybe this could be
worded as such:
- suggestion: "... the authorization server (e.g., client secret,
public/private key pair)"

Draft:

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

- Does this mean that credentialed clients are as trustworthy/ not
trustworthy as public clients?

Draft:

"Clients in possession of a client password, also known as a client secret, ..."

- Maybe this could simply be changed to:
"Clients in possession of a client secret ..."

Section 3.1.2.2 Registration Requirements
-------------------------

Draft:

"Lack of requiring registration of redirect URIs enables an attacker
to use the authorization endpoint as an open redirector as described
in <a href="#section-9.18">Section 9.18</a>."

- is that still required since redirect_uris have to be pre-registered now?

Section 4.1. Authorization Code Grant
-------------------------

Draft:
- Figure 3, step (1), does not include 'code_challenge_method' Is that
intentionally?
- I am suggesting to include it to avoid potential questions and
confusion. It could listed as 'optional' as 'scope' is
- In addition, when referencing parameters, they should be spelled as
used in the protocol, i.e.: 'code_challenge' instead of
'code_challenge'

Section 4.1.1 Authorization Request
-------------------------

Draft:

"Clients use a unique secret per authorization request to protect .... "

- It would be less confusing if this section would start of with "PKCE
is required"
- Introducing a '... unique secret per ...' sounds like something very
new although this is referencing PKCE
- Suggestion (along the lines of):
"Clients MUST leverage PKCE per authorization request to protect ..."

Section 4.1.2.1 Error Response
-------------------------

Draft:

"An AS MUST reject requests without a "code_challenge" from public
clients, and MUST reject such requests from other clients  unless
there is reasonable assurance that ..."

- These statements are the ones that cause discussions between
developers and/ or third parties
- ' ... unless ...' is very difficult to grasp, even when looking into
section 9.8
- I would suggest to make it required

Section 5.1 Successful Response
-------------------------

Draft and current:

- both documents describe the refresh_token response parameter and
describe it as such:
"OPTIONAL.  The refresh token, which can be used to obtain new access
tokens using the same authorization grant as described in <a
href="#section-6">Section 6</a>"

- As an enhancement, I suggest this update:
"OPTIONAL.  The refresh token, which can be used to obtain new access
tokens using the grant type "refresh_token" as described in <a
href="#section-6">Section 6</a>"

Section 6. Refreshing an Access Token
-------------------------

Draft:

Authorization servers SHOULD determine, based on a risk assessment,
whether to issue refresh tokens to a certain client.  If the
authorization server decides not to issue refresh tokens, the client
MAY refresh access tokens by utilizing other grant types, such as the
authorization code grant type.  In such a case, the authorization
server may utilize cookies and persistent grants to optimize the user
experience.

- That paragraph sounds like a general advice for web developers and
should appear in an appendix for my taste
- ' ... based on risk assessment ... ' may exclude any implementation
that does not have such capabilities

===

Draft:

- this section includes this statement:
"Confidential or credentialed clients MUST authenticate with the
authorization server ..."

- section 2.3 includes this statement and makes me wonder how
confident an authorization server can be when working with
'credentialed' clients':
"However, the authorization server MUST NOT rely on credentialed
client authentication for the purpose of identifying the client."

- Any clarification, I would say about the client type 'credentialed'
in general, would be helpful

Typos:

Draft:

"credentialed":  Clients that have credentials and their identity has
been not been confirmed by the AS are designated as "credentialed
clients"

- I believe it should be:

"credentialed":  Clients that have credentials and their identity has
not been confirmed by the AS are designated as "credentialed clients"

Section 3.2.1 Client Authentication
-------------------------

Draft:

"Confidential or credentialed clients client MUST authenticate with..."

- I believe it should be:
"Confidential or credentialed clients MUST authenticate with..."

-------------------------
Summary of changes between draft and current:
-------------------------

- no more implicit
- no more response_type=token
- no more ropc
- no more redirect code 307
- no more open redirect_uri
- new client type 'credentialed'
- must use PKCE (with few exceptions)
- AS must provide a way to show their support for 'code_challenge_method'

- refresh token should expire
- description for client type 'confidential' got updated
- clients should not be able to choose their client_id
- no reference to 'mac' token profile anymore
- section 7.2 details on Bearer token
- resource server must include 'WWW-Authenticate: Bearer
realm="example"' header for failing authorization
- extended list of security threats
- discussion on native apps removed
- recommended bindings between access_token and resource_server
- recommended refresh_token rotation or sender-constraints
- recommended to use '127.0.0.1' instead of 'localhost'

On Tue, 7 Jul 2020 at 15:21, Vladimir Dzhuvinov <[email-masked]> wrote:
>
> I find 03 well structured, well written and it shows that a lot of thought and work has gone into it.
>
> I understand why this new client type was introduced. For the reader who is not familiar with the recent OAuth RFCs and drafts - I suspect this can still be confusing. There will likely be questions -- Why does this difference between confidential and credentialed matter? What is a concrete example of a credentialed client?
>
> Also, people will likely ask themselves - what does the confirmation of a (credentialed) client's identity by the AS actually mean and do? (section 2.1)
>
>
> Again, normative text that relies on the implementer being able to assign levels of confidence in the client's identity, but is not immediately obvious how to go about this.
>
>
> There is mention in 9.1 about "enlisting the resource owner to confirm identity" and "if there is a web application whose developer's identity was verified...". But this talk about client identity is secondary and happens in the context of client authentication.
>
> Perhaps it will make sense to promote the discussion about identity to a new 9.x section "Client identity" or "Client Identification", before "Client Authentication". Addressing the topics what client identity is, why does it matter (especially for security), and the "confirmation by the AS". Then proceed with "Client Authentication" which now is freed to focus on the credentials / auth methods aspects.
>
> Credentials (public key) can also be registered by a client performing dynamic registration (section 2.1)
>
>
> Vladimir
>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 7 Jul 2020 16:35:49 -0700

Thanks Sascha and Vladimir for the feedback!

Sascha: did you have a concern with the document being adopted by the WG?

ᐧ

On Tue, Jul 7, 2020 at 4:04 PM Sascha Preibisch <[email-masked]>
wrote:

> is not familiar with the recent OAuth RFCs and drafts - I suspect this can
> still be confusing. There will likely be questions -- Why does this
> difference between confidential and credentialed matter? What is a concrete
> example of a credentialed client?
> >
> a (credentialed) client's identity by the AS actually mean and do? (section
> 2.1)
> >
> >
> identity" and "if there is a web application whose developer's identity was
> verified...". But this talk about client identity is secondary and happens
> in the context of client authentication.
> >
> "Client Authentication". Addressing the topics what client identity is, why
> does it matter (especially for security), and the "confirmation by the AS".
> Then proceed with "Client Authentication" which now is freed to focus on
> the credentials / auth methods aspects.
> >

---

From: Sascha Preibisch <[email-masked]>
Date: Tue, 7 Jul 2020 16:55:33 -0700

Hello Dick!

Unless the two typos that I have mentioned should be updated beforehand ,
no, I do not.

Thank you,
Sascha

On Tue, 7 Jul 2020 at 16:36, Dick Hardt <[email-masked]> wrote:

>> > I understand why this new client type was introduced. For the reader
>> who is not familiar with the recent OAuth RFCs and drafts - I suspect this
>> > Perhaps it will make sense to promote the discussion about identity to
>> a new 9.x section "Client identity" or "Client Identification", before