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

Aaron Parecki <aaron@parecki.com> Thu, 12 March 2020 20:59 UTC

Return-Path: <aaron@parecki.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE46A3A094C for <oauth@ietfa.amsl.com>; Thu, 12 Mar 2020 13:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NC3j0yjCp43J for <oauth@ietfa.amsl.com>; Thu, 12 Mar 2020 13:59:10 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C1E3A0948 for <oauth@ietf.org>; Thu, 12 Mar 2020 13:59:09 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id p1so6837214ils.12 for <oauth@ietf.org>; Thu, 12 Mar 2020 13:59:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hSwNawUQt1WYk742keX3Dj98sA4oz+4FBZKKsRu288E=; b=mW8d8FMT0uvRYsujgnnvUbH9Ol36y+1FU/KjyNYlMbDa4/ziVeFnaDi3ui6UEE06DK OqppijPLM1zOyoof8Y93iWUQ1vp+etIq+6cXx3teEKFSOoxoOKuz2NPntrYGxaCTYgH+ WDCCo3XFUpwhbZ0Grm/alyCMx6KhkAV3juK93m09M7E9GcX0d2v6yP0A2+EdDL46ACWr 0VPV7Orex/dyex0ZW98zdvFQW+4hIOcR+pFM97mv98207pVQgcGSXOBNlkusFPFVCde8 rhnwvCE1HC3ueZQVL4JSJPEiMcC7J2SXdfS/dwqgzWNuck3vAU3LRuYPiT7w/oyZhNdW yKSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hSwNawUQt1WYk742keX3Dj98sA4oz+4FBZKKsRu288E=; b=umjPINaSO2q17JqiiwP2tziDLnPKlb9jSW8iOf2QjKZ7Cj/zJoBfVTLY/PY1ZQkgfn CZ3aGswrVnmd84qBH/utZ4PyJ47DdX3eA2Oxv3zALj0WmSJ/y4rmAL3b4J90lhC1iSVT 9VJXg4uYhSh6qMALGVsghaczp1OR99GOC0XKXPJnjbLnjGaaR3G56Mm1bgn8buVsCI0d cKLO1h/H4Gc2Ak6XxvSP3Jzr+IHG3bIOc/CJ5ftQt2YNvzho6SoEKxxhQd/kHM3A3V8P EYCdae5B3PuNEtZCuuEMI3t9d3Gom8SRkiNlQMt/C1nfLIW1rscZZWYBFh99JYF7703X zQQw==
X-Gm-Message-State: ANhLgQ3WpBvl/CAfrJ5vCFkF4nuVtt3ftbIXKMFaSiOVsSI+KLCEXswn WSyDDpBGZ/lplMfv9tXVyQGDuI02nnU=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vsu/n+ruyb1vUs0KzqPYepefsmZ5dOaGCYpg7ua?= =?utf-8?q?u0zUK4whruZRHLD0ZiS/DKzP81DHMRDsuA=3D=3D?=
X-Received: by 2002:a92:798c:: with SMTP id u134mr8665561ilc.28.1584046748874; Thu, 12 Mar 2020 13:59:08 -0700 (PDT)
Received: from mail-il1-f177.google.com (mail-il1-f177.google.com. [209.85.166.177]) by smtp.gmail.com with ESMTPSA id z14sm11629277iln.17.2020.03.12.13.59.08 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2020 13:59:08 -0700 (PDT)
Received: by mail-il1-f177.google.com with SMTP id h3so6892598ils.3 for <oauth@ietf.org>; Thu, 12 Mar 2020 13:59:08 -0700 (PDT)
X-Received: by 2002:a92:2904:: with SMTP id l4mr10698216ilg.166.1584046748039; Thu, 12 Mar 2020 13:59:08 -0700 (PDT)
MIME-Version: 1.0
References: <CAGBSGjp6xRL21fdY+dosAhwS3Db6z1hxHU5uPGGprC-c_Ec-Cg@mail.gmail.com> <CA+3s2iTq2F7dimuFs9rnAt87YhVscdrvMoa0ChbagtC5w=G5cA@mail.gmail.com>
In-Reply-To: <CA+3s2iTq2F7dimuFs9rnAt87YhVscdrvMoa0ChbagtC5w=G5cA@mail.gmail.com>
From: Aaron Parecki <aaron@parecki.com>
Date: Thu, 12 Mar 2020 13:58:57 -0700
X-Gmail-Original-Message-ID: <CAGBSGjr5L5sNoexzOgipkVVewNL+DypSo5S8bkai8PuJ61GB+Q@mail.gmail.com>
Message-ID: <CAGBSGjr5L5sNoexzOgipkVVewNL+DypSo5S8bkai8PuJ61GB+Q@mail.gmail.com>
To: Pedro Igor Craveiro e Silva <pigor.craveiro@gmail.com>
Cc: OAuth WG <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/pUPT8O83XRrqyhipuL9L1fZI2iM>
Subject: Re: [OAUTH-WG] First Draft of OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2020 20:59:12 -0000

> 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.craveiro@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 <aaron@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