> In regards to `code_challenge_method` parameter in authorization requests. > Wouldn't make more sense to have the default value as `S256` based on the > statement in Section `4.1.1.2. Client Creates the PKCE Code Challenge` that > says that `S256` is MTI on the server? > So you have `plain` as a special case for clients not able to support a more > strong code challenge?
One of the goals of this draft was to consolidate the information available in the related extensions and BCPs, not actually define anything new itself. This behavior described would be different from what is described in PKCE. If this is a good idea to change the default, then that should be included in the Security BCP and brought into 2.1 from there. ---- Aaron Parecki aaronparecki.com @aaronpk On Thu, Mar 12, 2020 at 12:22 PM Pedro Igor Craveiro e Silva <pigor.crave...@gmail.com> wrote: > > Hi Aaron, > > In regards to `code_challenge_method` parameter in authorization requests. > Wouldn't make more sense to have the default value as `S256` based on the > statement in Section `4.1.1.2. Client Creates the PKCE Code Challenge` that > says that `S256` is MTI on the server? > > So you have `plain` as a special case for clients not able to support a more > strong code challenge? > > Regards. > Pedro Igor > > On Wed, Mar 11, 2020 at 9:29 PM Aaron Parecki <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
