Re: [OAUTH-WG] [EXTERNAL] Re: Clarifying the scope of the OAuth 2.1 spec

Dick Hardt <dick.hardt@gmail.com> Mon, 16 March 2020 15:36 UTC

Return-Path: <dick.hardt@gmail.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 235883A0A9E for <oauth@ietfa.amsl.com>; Mon, 16 Mar 2020 08:36:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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=gmail.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 1cnOwgnb_Sin for <oauth@ietfa.amsl.com>; Mon, 16 Mar 2020 08:36:35 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 4FE373A0B54 for <oauth@ietf.org>; Mon, 16 Mar 2020 08:36:35 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id g12so19197757ljj.3 for <oauth@ietf.org>; Mon, 16 Mar 2020 08:36:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hBv3QITE+nutCQfT+T8B9x/mhAmFaSN0QbZ878h/YOU=; b=q4bMwNOyh5QtzYLhRfo4EPEdO7yQWKunwUx3uoNDtfoVfywpJPTfN5EY5pm11EWcGy dj8UizYANjwB3dITZ0ocg5mVcpPyhN+H5PvmjZbaxOwhtajJWlKhVYG46Hs+vX2vtZuV hqDJmcqlz17kx4UfWwdsqGMI1MR0mpeqfmWKumiFpC99XeLQFOGpUDrEdFBJXNsdgLrD XsaLkxT0CV/kc91dhOe9cDwKXOEoMQBnvBl1uDOjCw0KLUrZIlB46qL7GIZBkcK+6+Ka gfDtvb1Vvk2kHEexzw2cqPuc2cEs907HzhORlb90rWqRTfDN8RXnrBSCjSs7IHodExos UC3w==
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; bh=hBv3QITE+nutCQfT+T8B9x/mhAmFaSN0QbZ878h/YOU=; b=guWpkQT9TTi3JvDvWIgo8hZYV//E2/F6L61QqyqtCUg7AxoQzNd0HMw8v3eZi2mrCU LGzVdt14248BkZVj0Ph9/gmfaDzx9mz4BgcVqlPmEH8BvTH0DUI0W2fbtqJZYHp0M2LE VwEs1uPvu5YLr1bw3Ggfs/djn3vW+ON+lvLXwVQugsUbYaMDpBTneTTRoPOGtGvm6gZH 3gl8y6oCJgHyLAm2KnEDowYvtZfbH944TCVKRTZ72YkEYWiMGZsXMYWrqyJmkJxUoS00 ATOdWuFlSRQRmc66WGRgG+4ojM5F35gDNpEuWBdEFrc7Ve8SNCkdum7zWfOmw0zG2FGZ w6zA==
X-Gm-Message-State: ANhLgQ2FIAfiQgEjeug+5itCqSUTrBGLpZWAFqwfJrf3gOGGQapvWLAP X8P4yQ2Dz7aMRTogpqnIwhZ2AwzEXjM/XHeESL4=
X-Google-Smtp-Source: ADFU+vsIWhyW7oGFB4lDkWLy1xdCtaJf7ymC1jeR48abfxVKyEBmsPMCygWPcSdUgooyKojP6hW53Wr337XiYe9ZWe8=
X-Received: by 2002:a2e:9dc8:: with SMTP id x8mr1687040ljj.212.1584372993219; Mon, 16 Mar 2020 08:36:33 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR00MB0684B029182673EADC9E0288F5F80@DM6PR00MB0684.namprd00.prod.outlook.com><CAD9ie-s6BYhFUH0qg=gggRqbEK+RRKNEOm0VTgwS0hduTK5yDw@mail.gmail.com> <MN2PR00MB0688B318D58DF71142285E7EF5F90@MN2PR00MB0688.namprd00.prod.outlook.com>
In-Reply-To: <MN2PR00MB0688B318D58DF71142285E7EF5F90@MN2PR00MB0688.namprd00.prod.outlook.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 16 Mar 2020 08:36:07 -0700
Message-ID: <CAD9ie-v9j20rubHbGL_OY4yJc8wE-0UAkQW_DMHk_YCG2=3fxA@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: "aaron@parecki.com" <aaron@parecki.com>, "torsten@lodderstedt.net" <torsten@lodderstedt.net>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000073e06d05a0fa9537"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/peEMkjAquIr_7Eut2jZyng-FQUs>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Clarifying the scope of the OAuth 2.1 spec
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: Mon, 16 Mar 2020 15:36:48 -0000

Hi Mike

I'm aligned on the overall messaging. Sorry I was not clear on my feedback
-- it was directed at your suggested text, specifically the terms "OAuth
2.0" and "OAuth 2.0 set of protocols"

FYI: the "new" features, are not new to "OAuth 2.0" per se as they are
existing specifications -- my point was that they are not features that are
in RFC 6749. OAuth 2.1 is also NOT a superset of all 22 specifications.

This paragraph in the 2.1 doc attempts to describe what OAuth 2.1 is and is
not:

Since the publication of the OAuth 2.0 Authorization Framework ([RFC6749
<https://tools.ietf.org/id/draft-parecki-oauth-v2-1-00.html#RFC6749>]) in
October 2012, it has been updated by OAuth 2.0 for Native Apps ([RFC8252
<https://tools.ietf.org/id/draft-parecki-oauth-v2-1-00.html#RFC8252>]),
OAuth Security Best Current Practice ([I-D.ietf-oauth-security-topics
<https://tools.ietf.org/id/draft-parecki-oauth-v2-1-00.html#I-D.ietf-oauth-security-topics>
]), and OAuth 2.0 for Browser-Based Apps ([I-D.ietf-oauth-browser-based-apps
<https://tools.ietf.org/id/draft-parecki-oauth-v2-1-00.html#I-D.ietf-oauth-browser-based-apps>
]). The OAuth 2.0 Authorization Framework: Bearer Token Usage ([RFC6750
<https://tools.ietf.org/id/draft-parecki-oauth-v2-1-00.html#RFC6750>]) has
also been updated with ([I-D.ietf-oauth-security-topics
<https://tools.ietf.org/id/draft-parecki-oauth-v2-1-00.html#I-D.ietf-oauth-security-topics>
]). This Standards Track specification consolidates the information in all
of these documents and removes features that have been found to be insecure
in [I-D.ietf-oauth-security-topics
<https://tools.ietf.org/id/draft-parecki-oauth-v2-1-00.html#I-D.ietf-oauth-security-topics>
].

What changes would you suggest to this?

ᐧ

On Sun, Mar 15, 2020 at 9:01 PM Mike Jones <Michael.Jones@microsoft.com>
wrote:

> I’m glad you like the direction of my comments.  Sometimes saying what
> you’re **not** doing is as important as saying what you **are** doing,
> and I think this is such a case.
>
>
>
> As an example of why this matters, a developer recently asked me “Would we
> have to use a different set of endpoints for OAuth 2.1?”  We should clearly
> scope this work so that the answer is “No, you would use the same
> endpoints.”
>
>
>
> Given that the abstract talks about obsoleting OAuth 2.0, I believe it’s
> important for the abstract to say what’s being obsoleted, what’s not being
> obsoleted, and what the relationship of the new spec is to the one(s) it’s
> obsoleting.  As used in the vernacular by developers, I believe “OAuth 2.0”
> commonly refers to the set of OAuth 2.0 RFCs approved by this working
> group, which are the set of (currently 22) RFCs listed at
> https://datatracker.ietf.org/wg/oauth/documents/ - as well as at least
> some of the non-RFC specifications that extend OAuth 2.0 via the OAuth
> registries at
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml,
> particularly [OAuth 2.0 Multiple Response Type Encoding Practices
> <https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html>].
> I’m pretty sure you intend that OAuth 2.1 keep using much of that widely
> deployed work and not replace it.  You should be clear about that.
>
>
>
> Since you say that there are new features in OAuth 2.1, what are they and
> are they essential to the OAuth 2.1 goals?  Or if they’re not essential,
> could they more profitably be factored into another specification so that
> the new features can be used either with OAuth 2.0 and OAuth 2.1?  That
> might make the resulting messaging to developers much clearer.
>
>
>
>                                                        Thanks,
>
>                                                        -- Mike
>
>
>
> *From:* Dick Hardt <dick.hardt@gmail.com>
> *Sent:* Sunday, March 15, 2020 6:50 PM
> *To:* Mike Jones <Michael.Jones@microsoft.com>
> *Cc:* aaron@parecki.com; torsten@lodderstedt.net; oauth@ietf.org
> *Subject:* [EXTERNAL] Re: Clarifying the scope of the OAuth 2.1 spec
>
>
>
> Hi Mike
>
>
>
> I like where you are going with this, but what do we mean when we say
> OAuth 2.0? Is it RFC 6749? What is the OAuth 2.0 set of protocols?
>
>
>
> OAuth 2.1 includes features that are not in RFC 6749, so it is not a
> subset of that specification.
>
> ᐧ
>
>
>
> On Sun, Mar 15, 2020 at 2:34 PM Mike Jones <Michael.Jones@microsoft.com>
> wrote:
>
> The abstract of draft-parecki-oauth-v2-1 concludes with this text:
>
>    This specification replaces and obsoletes the OAuth 2.0 Authorization
> Framework described in RFC 6749 <https://tools.ietf.org/html/rfc6749>.
>
>
>
> While accurate, I don’t believe that this text captures the full intent of
> the OAuth 2.1 effort – specifically, to be a recommended subset of OAuth
> 2.0, rather than to introduce incompatible changes to it.  Therefore, I
> request that these sentences be added to the abstract, to eliminate
> confusion in the marketplace that might otherwise arise:
>
>
>
>     OAuth 2.1 is a compatible subset of OAuth 2.0, removing features that
> are not currently considered to be best practices.  By design, it does not
> introduce any new features to what already exists in the OAuth 2.0 set of
> protocols.
>
>
>
>                                                        Thanks,
>
>                                                        -- Mike
>
>
>
> P.S.  I assert that any incompatible changes should be proposed as part of
> the TxAuth effort and not as part of OAuth 2.1.
>
>
>
>