This looks like a great initial draft, and I hope to see it move forward.
Some comments so far:
Section 1.6:
“At the time of this writing” is duplicated.
Section 3.1.2.1 (and possibly other sections such as 1.6 / 2.3.1 / 3.1 / 3.2
that mandate TLS):
Section 3.1.2.1 currently retains this language from RFC 6749: “The redirection
endpoint SHOULD require the use of TLS… This specification does not mandate the
use of TLS because at the time of this writing, requiring clients to deploy TLS
is a significant hurdle…”
I suggest updating this text to mandate TLS, and/or a blanket statement should
be made that TLS is required for all protocol interactions (rather than or in
addition to the statements throughout the draft). I don't think "requiring
clients to deploy TLS is a significant hurdle" is an accurate statement at the
present time.
Section 1.7:
Consider incorporating new guidance on HTTP redirects as specified in
draft-ietf-oauth-security-topics section 4.10.
Section 1.8 / 2 / 3.1 / 3.2:
Consider including informative references to RFC 7591 (Dynamic Client
Registration) and RFC 8414 (OAuth 2.0 Authorization Server Metadata) as
optional methods that may be useful for client registration, determining AS
capabilities, and endpoint discovery.
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.”
The client credentials example possibly conflicts with the section 4.2
statement “The client credentials grant MUST only be used by confidential
clients” and the statement earlier in section 2.1 “Clients requiring a higher
level of confidence…use credentials to authenticate with the authorization
server.”
Section 2.3.1:
(This text is in RFC 6749 too)
client_secret – “REQUIRED…The client MAY omit the parameter if the client
secret is an empty string.”
Since this section describes authentication using a password by confidential
clients, it doesn’t make sense that the client secret would be an empty string?
(Certainly there may be situations where a client_id but not a client_secret
would be sent – e.g. public clients, or if the client authenticates another way
-- but that’d be out of scope of what section 2.3.1 is describing?)
Section 2.3.2:
“MAY support any suitable HTTP authentication scheme” – should the word “HTTP”
be removed as being too specific? I don’t think methods such as mTLS and
private_key_jwt are HTTP authentication schemes?
Section 3.1.2.2:
“The authorization server SHOULD require the client to provide the complete
redirection URI” -
Given the section 3.1.2 requirement to compare redirect URIs using “simple
string comparison”, should that instead be a MUST?
Section 3.1.2.3:
Consider removing the second paragraph, it looks redundant given the new
section 3.1.2 requirement for “simple string comparison”.
Section 3.2.1:
“an unauthenticated client MUST sent its “client_id”…[t]his protects the client
from substitution of the authentication code.”:
“authentication code” should be “authorization code” (typo also present in RFC
6749), also I don’t think this is true anymore with the requirement to use
PKCE? However it’s probably still a good requirement, since explicitly
identifying the client may make it easier for the AS to look up whether the
authorization code is valid?
Section 4.1:
“The client includes its … requested scope, local state …” Consider indicating
that requested scope and local state are optional?
Section 4.1.1.1:
(I guess this is more of an RFC 7636 question since the text comes from there.)
Why is the entropy requirement for the PKCE code verifier only SHOULD /
RECOMMENDED rather than MUST?
Section 9.7:
(Already pointed out by Pieter this morning.)
Typo: RFC8418 should be RFC8414.
Thanks,
Mike
On 3/11/20, 8:29 PM, "OAuth on behalf of Aaron Parecki"
<oauth-boun...@ietf.org on behalf of aa...@parecki.com> wrote:
I'm happy to share that Dick and Torsten and I have published a first
draft of OAuth 2.1. We've taken the feedback from the discussions on
the list and incorporated that into the draft.
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01
A summary of the differences between this draft and OAuth 2.0 can be
found in section 12, and I've copied them here below.
> This draft consolidates the functionality in OAuth 2.0 (RFC6749),
> OAuth 2.0 for Native Apps (RFC8252), Proof Key for Code Exchange
> (RFC7636), OAuth 2.0 for Browser-Based Apps
> (I-D.ietf-oauth-browser-based-apps), OAuth Security Best Current
> Practice (I-D.ietf-oauth-security-topics), and Bearer Token Usage
> (RFC6750).
>
> Where a later draft updates or obsoletes functionality found in the
> original [RFC6749], that functionality in this draft is updated with
> the normative changes described in a later draft, or removed
> entirely.
>
> A non-normative list of changes from OAuth 2.0 is listed below:
>
> * The authorization code grant is extended with the functionality
> from PKCE ([RFC7636]) such that the only method of using the
> authorization code grant according to this specification requires
> the addition of the PKCE mechanism
>
> * Redirect URIs must be compared using exact string matching as per
> Section 4.1.3 of [I-D.ietf-oauth-security-topics]
>
> * The Implicit grant ("response_type=token") is omitted from this
> specification as per Section 2.1.2 of
> [I-D.ietf-oauth-security-topics]
>
> * The Resource Owner Password Credentials grant is omitted from this
> specification as per Section 2.4 of
> [I-D.ietf-oauth-security-topics]
>
> * Bearer token usage omits the use of bearer tokens in the query
> string of URIs as per Section 4.3.2 of
> [I-D.ietf-oauth-security-topics]
>
> * Refresh tokens must either be sender-constrained or one-time use
> as per Section 4.12.2 of [I-D.ietf-oauth-security-topics]
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12
I'm excited for the direction this is taking, and it has been a
pleasure working with Dick and Torsten on this so far. My hope is that
this first draft can serve as a good starting point for our future
discussions!
----
Aaron Parecki
aaronparecki.com
@aaronpk
P.S. This notice was also posted at
https://aaronparecki.com/2020/03/11/14/oauth-2-1
_______________________________________________
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
