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