Re: [OAUTH-WG] First Draft of OAuth 2.1

["Peck, Michael A" <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> 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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/oauth