Return-Path: 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 E246B3A0FBB for ; Mon, 16 Mar 2020 12:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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=pingidentity.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 vvi5QQBZhFwx for ; Mon, 16 Mar 2020 12:44:36 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 763293A0FBE for ; Mon, 16 Mar 2020 12:44:35 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id f13so20118265ljp.0 for ; Mon, 16 Mar 2020 12:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EWt/iEEnJCddco+ImuQipYVCKdCwEjVpF+38GPrM8tQ=; b=SAZW36NFRA/MZP3a2kicswgivIpdXlX0R8qo1SiLnGSkGBzVt0X5DpRobMNuUPFpBD O+1Z4fX9C2F60lYngg+77N/YfXXxT2DuSROtECucVnDeLLiLFBcX4o3wF97y6t3J7TC+ fV8VN3GaeIo0pyw5Lyz5Mf1lhiDpCoag9EGyBsOw/0vYZFyVfYCju4w9MdeL6FlodxYS NsMISfunLU83K4vYO8Ig6LVSyAhpuPmFEqVb0coHBFoLSJZh1QVgAK0HtLN4MYYXSdd3 67CRnoUjcreIwWSmDLHK98TrS05bXNEsa5+9T0uIyEBeTFYvIn6u52k7HohctQF6Q9cU F1ow== 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=EWt/iEEnJCddco+ImuQipYVCKdCwEjVpF+38GPrM8tQ=; b=top/2Gj4Z8VGhRcXWD2eRHcMvAu5cQHgufXYulwgWMFHG5gN+xGDvdllA3Gb+GugY6 nnMn2/cIuGB2XqW3Jzz+vqIyf9XR83ppWl+hyL1ApuzcrVUJVxlJMJKplwlE9K4i5TmB wtLsrWjz+odq+yGmDV6Q43BR73mfjNfIL9TvAJpdtMNc8Y8zTrOOo3A0GC8QQi7QX+yC H0khxpx3Kj3Dt1NliS22d/z4HmPxjemvvlz96p1j77OJPtYKgDh3OfpW79JmvvYNUQgZ 2Ah9cnQsQCOwnizphpwK3tRGPQaY3Ozmgz1Bg9TlMWP48236V1w2cacWmCjoX2OxsDAm 7HFQ== X-Gm-Message-State: ANhLgQ2TWKYNaxrDHoBvX1xUmfEUjSuolgN1ZCE2PBMmZWIjZ2oMILuD QhBuqJt72QrH0rdnDmkDq3hOTS7VhunQfClJbhrvo01j0WEZVmwdwSbCvmEuPWb4tXMnv4lyTyU tPt+StXCdfy9aFon0 X-Google-Smtp-Source: =?utf-8?q?ADFU+vsd2XKs7fhCdzM20Z6Hxyjv5w5usV9TmbBao0jI?= =?utf-8?q?pXiSVrBnidhFATzu2fjxqkv3jXBakmnzgaQwGQoIrdUm6GQ=3D?= X-Received: by 2002:a2e:888a:: with SMTP id k10mr535932lji.216.1584387873282; Mon, 16 Mar 2020 12:44:33 -0700 (PDT) MIME-Version: 1.0 References: =?utf-8?q?=3CDM6PR00MB06845FEB6201E73E87CA30B9F5F90=40DM6PR00MB0?= =?utf-8?q?684=2Enamprd00=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3CCAD9ie-uZEjcnAF+N7ni6XMznaUWJxkFE7BTi+o2FLiQqhHA-Mg=40mail=2Eg?= =?utf-8?q?mail=2Ecom=3E_=3CDM6PR00MB0684F27F5A069BA3D9B1AD68F5F90=40DM6PR00?= =?utf-8?q?MB0684=2Enamprd00=2Eprod=2Eoutlook=2Ecom=3E?= In-Reply-To: =?utf-8?q?=3CDM6PR00MB0684F27F5A069BA3D9B1AD68F5F90=40DM6PR00MB?= =?utf-8?q?0684=2Enamprd00=2Eprod=2Eoutlook=2Ecom=3E?= From: Brian Campbell Date: Mon, 16 Mar 2020 13:44:07 -0600 Message-ID: To: Mike Jones Cc: Dick Hardt , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005fb36505a0fe0cbc" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 19:44:38 -0000 --0000000000005fb36505a0fe0cbc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 Without going into any of the specific wording, I do very much agree with the sentiment and direction here. On Mon, Mar 16, 2020 at 1:41 PM Mike Jones wrote: > Perfect =E2=80=93 thanks for listening. > > > > -- Mike > > > > *From:* Dick Hardt > *Sent:* Monday, March 16, 2020 12:32 PM > *To:* Mike Jones > *Cc:* aaron@parecki.com; torsten@lodderstedt.net; oauth@ietf.org > *Subject:* [EXTERNAL] Re: Clarifying the scope of the OAuth 2.1 spec > > > > Thanks for the suggested text Mike. A little wordy for me, but I agree > with the intention to minimize market place confusion. I'll discuss how t= o > incorporate with my co-authors. > > =E1=90=A7 > > > > On Mon, Mar 16, 2020 at 11:35 AM Mike Jones > wrote: > > Thanks for the clarifications, Dick. Here=E2=80=99s my resulting propose= d > changes. Part of my goal here is for people to understand the goals and > non-goals from reading the abstract. > > > > In the Abstract, change: > > This specification replaces and obsoletes the OAuth 2.0 Authorization > Framework described in RFC 6749 . > > to: > > This specification replaces and obsoletes these OAuth 2.0 specifications: > RFC 6749 and RFC 8252. It does so by removing portions of them that are = no > longer considered best security practices; the portions that remain are > compatible with the corresponding portions of the specs being replaced. = By > design, it does not introduce any new features to what already exists in > the OAuth 2.0 specifications being replaced. > > > > (If you want to list other non-RFCs that you believe that will be > obsoleted, you can do that too.) > > > > Add this text to the cited paragraph in Section 2.1: > > When this specification does not replace existing specifications produced > by the OAuth working group or other non-OAuth-working-group profiles of > OAuth that extend OAuth 2.0 via the IANA =E2=80=9COAuth Parameters=E2=80= =9D registry > [IANA.OAuth.Parameters], it is intended that those specifications will > continue to be used with OAuth 2.1 in the same manner that they are with > the OAuth 2.0 specifications being replaced. > > > > The reference for [IANA.OAuth.Parameters] is > https://www.iana.org/assignments/oauth-parameters/. > > > > The last sentence =E2=80=93 saying that stuff not explicitly obsoleted is= n=E2=80=99t being > changed =E2=80=93 is critical to reducing the marketplace anxiety that th= is effort > might otherwise create. Please make it a goal to remove uncertainty and > sources of speculation wherever possible. > > > > Thanks again for the useful discussion. > > > > -- Mike > > > > *From:* Dick Hardt > *Sent:* Monday, March 16, 2020 8:36 AM > *To:* Mike Jones > *Cc:* aaron@parecki.com; torsten@lodderstedt.net; oauth@ietf.org > *Subject:* Re: Clarifying the scope of the OAuth 2.1 spec > > > > Hi Mike > > > > I'm aligned on the overall messaging. Sorry I was not clear on my feedbac= k > -- 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 a= re > 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 > ]) in > October 2012, it has been updated by OAuth 2.0 for Native Apps ([RFC8252 > ]), > OAuth Security Best Current Practice ([I-D.ietf-oauth-security-topics > ]), > and OAuth 2.0 for Browser-Based Apps ([I-D.ietf-oauth-browser-based-apps > ]). > The OAuth 2.0 Authorization Framework: Bearer Token Usage ([RFC6750 > ]) > has also been updated with ([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 > > ]. > > > > What changes would you suggest to this? > > > > =E1=90=A7 > > > > On Sun, Mar 15, 2020 at 9:01 PM Mike Jones > wrote: > > I=E2=80=99m glad you like the direction of my comments. Sometimes saying= what > you=E2=80=99re **not** doing is as important as saying what you **are** d= oing, > and I think this is such a case. > > > > As an example of why this matters, a developer recently asked me =E2=80= =9CWould we > have to use a different set of endpoints for OAuth 2.1?=E2=80=9D We shou= ld clearly > scope this work so that the answer is =E2=80=9CNo, you would use the same > endpoints.=E2=80=9D > > > > Given that the abstract talks about obsoleting OAuth 2.0, I believe it=E2= =80=99s > important for the abstract to say what=E2=80=99s being obsoleted, what=E2= =80=99s not being > obsoleted, and what the relationship of the new spec is to the one(s) it= =E2=80=99s > obsoleting. As used in the vernacular by developers, I believe =E2=80=9C= OAuth 2.0=E2=80=9D > 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 > ]. > I=E2=80=99m 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=E2=80=99re not ess= ential, > 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 > *Sent:* Sunday, March 15, 2020 6:50 PM > *To:* Mike Jones > *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. > > =E1=90=A7 > > > > On Sun, Mar 15, 2020 at 2:34 PM Mike Jones > 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 . > > > > While accurate, I don=E2=80=99t believe that this text captures the full = intent of > the OAuth 2.1 effort =E2=80=93 specifically, to be a recommended subset o= f 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 no= t > 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 o= f > the TxAuth effort and not as part of OAuth 2.1. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000005fb36505a0fe0cbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

Without going into a= ny of the specific wording, I do very much agree with the sentiment and dir= ection here.

On Mon, Mar 16, 2020 at 1:41 PM Mike Jones <Micha= el.Jones=3D40microsoft.co= m@dmarc.ietf.org> wrote:

Perfect =E2=80=93= thanks for listening.

=C2=A0<= /u>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike

=C2=A0<= /u>

From: Dick Hardt <dick.hardt@gmail.com>
Sent: Monday, March 16, 2020 12:32 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: aaron@par= ecki.com; = torsten@lodderstedt.net; oauth@ietf.org
Subject: [EXTERNAL] Re: Clarifying the scope of the OAuth 2.1 spec

=C2=A0

Thanks for the suggested text Mike. A little wordy f= or me, but I agree with the intention to minimize market place=C2=A0confusi= on. I'll discuss how to incorporate with my co-authors.

<= span style=3D"font-size:7.5pt;font-family:"Gadugi",sans-serif;col= or:white">=E1=90=A7

=C2=A0

On Mon, Mar 16, 2020 at 11:35 AM Mike Jones <Michael.Jones@= microsoft.com> wrote:

Thanks for the cl= arifications, Dick.=C2=A0 Here=E2=80=99s my resulting proposed changes.=C2= =A0 Part of my goal here is for people to understand the goals and non-goal= s from reading the abstract.

=C2=A0<= /u>

In the Abstract, = change:

This specification replaces and obsoletes the OAuth 2.0 Aut= horization Framework described in RFC = 6749.

to:=

This specification replaces and obsolete= s these OAuth 2.0 specifications:=C2=A0 RFC 6749 and RFC 8252.=C2=A0 It doe= s so by removing portions of them that are no longer considered best securi= ty practices; the portions that remain are compatible with the corresponding portions of the specs being replaced.=C2=A0 By desi= gn, it does not introduce any new features to what already exists in the OA= uth 2.0 specifications being replaced.

=C2=A0<= /u>

(If you want to l= ist other non-RFCs that you believe that will be obsoleted, you can do that= too.)

=C2=A0<= /u>

Add this text to = the cited paragraph in Section 2.1:

When this specification does not replace= existing specifications produced by the OAuth working group or other non-O= Auth-working-group profiles of OAuth that extend OAuth 2.0 via the IANA =E2= =80=9COAuth Parameters=E2=80=9D registry [IANA.OAuth.Parameters], it is intended that those specifications will continue to be used with OAu= th 2.1 in the same manner that they are with the OAuth 2.0 specifications b= eing replaced.

=C2=A0<= /u>

The reference for= [IANA.OAuth.Parameters] is https://www.iana.org/assignments/oauth-parameters/.=

=C2=A0<= /u>

The last sentence= =E2=80=93 saying that stuff not explicitly obsoleted isn=E2=80=99t being c= hanged =E2=80=93 is critical to reducing the marketplace anxiety that this = effort might otherwise create.=C2=A0 Please make it a goal to remove uncertainty = and sources of speculation wherever possible.

=C2=A0<= /u>

Thanks again for = the useful discussion.

=C2=A0<= /u>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike

=C2=A0<= /u>

From: Dick Hardt <dick.hardt@gmail.com>
Sent: Monday, March 16, 2020 8:36 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: aaron@par= ecki.com; torsten@lodder= stedt.net; oauth@ietf.org
Subject: Re: Clarifying the scope of the OAuth 2.1 spec

=C2=A0

Hi Mike

=C2=A0

I'm aligned on the overall messaging. Sorry I wa= s not clear on my feedback -- it was directed at your suggested text, speci= fically=C2=A0the terms "OAuth 2.0" and "OAuth 2.0 set of pro= tocols"

=C2=A0

FYI: the "new" features, are not new to &q= uot;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.=C2=A0

=C2=A0

This paragraph in the 2.1 doc attempts to describe w= hat OAuth 2.1 is and is not:

=C2=A0

Since the publication of the OAuth 2.0 Authorization = Framework ([RFC6= 749]) in October 2012, it has been updated by OAuth 2.0 for Native Apps ([RFC8252]), = OAuth Security Best Current Practice ([I-D.ietf-oauth-security-topic= s]), and OAuth 2.0 for Browser-Based Apps ([I-D.ietf-oauth-browser-ba= sed-apps]). The OAuth 2.0 Authorization Framework: Bearer Token Usage ([RFC6750]) has also been updated with ([= 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= =C2=A0[I-D.ietf-oauth-security-topics].<= /u>

=C2=A0

What changes would you suggest to this?=

=C2=A0

=E1=90=A7

=C2=A0

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

I=E2=80=99m glad = you like the direction of my comments.=C2=A0 Sometimes saying what you=E2= =80=99re *not* doing is as important as saying what you *are*= doing, and I think this is such a case.

=C2=A0<= /u>

As an example of = why this matters, a developer recently asked me =E2=80=9CWould we have to u= se a different set of endpoints for OAuth 2.1?=E2=80=9D=C2=A0 We should cle= arly scope this work so that the answer is =E2=80=9CNo, you would use the same = endpoints.=E2=80=9D

=C2=A0<= /u>

Given that the ab= stract talks about obsoleting OAuth 2.0, I believe it=E2=80=99s important f= or the abstract to say what=E2=80=99s being obsoleted, what=E2=80=99s not b= eing obsoleted, and what the relationship of the new spec is to the one(s) it=E2=80=99s ob= soleting.=C2=A0 As used in the vernacular by developers, I believe =E2=80= =9COAuth 2.0=E2=80=9D 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 regi= stries at https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml, particularly [OAuth 2.0 Multiple Response Type Encoding Practices].=C2=A0 I=E2=80=99m pretty sure you intend that OAuth 2.1 keep using m= uch of that widely deployed work and not replace it.=C2=A0 You should be clear about t= hat.

=C2=A0<= /u>

Since you say tha= t there are new features in OAuth 2.1, what are they and are they essential= to the OAuth 2.1 goals?=C2=A0 Or if they=E2=80=99re not essential, could they more profitably be factored into another specification so that the ne= w features can be used either with OAuth 2.0 and OAuth 2.1?=C2=A0 That migh= t make the resulting messaging to developers much clearer.=

=C2=A0<= /u>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Thanks,

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike

=C2=A0<= /u>

From: Dick Hardt <dick.hardt@gmail.com>
Sent: Sunday, March 15, 2020 6:50 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: aaron@par= ecki.com; torsten@lodder= stedt.net; oauth@ietf.org
Subject: [EXTERNAL] Re: Clarifying the scope of the OAuth 2.1 spec

=C2=A0

Hi Mike

=C2=A0

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 p= rotocols?

=C2=A0

OAuth 2.1 includes features that are not in RFC 6749= , so it is not a subset of that specification.=C2=A0

=E1=90=A7

=C2=A0

On Sun, Mar 15, 2020 at 2:34 PM Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

The abstract of draft-parecki-oauth-v2-1 concludes w= ith this text:

=C2=A0=C2=A0 This specification repl= aces and obsoletes the OAuth 2.0 Authorization Framework described in RFC = 6749.

=C2=A0

While accurate, I don=E2=80=99t believe that this te= xt captures the full intent of the OAuth 2.1 effort =E2=80=93 specifically,= to be a recommended subset of OAuth 2.0, rather than to introduce incompatible changes to it.=C2=A0 Therefore, I request that these sentence= s be added to the abstract, to eliminate confusion in the marketplace that = might otherwise arise:

=C2=A0

=C2=A0=C2=A0=C2=A0 OAuth 2.1 is a compatible subset = of OAuth 2.0, removing features that are not currently considered to be bes= t practices.=C2=A0 By design, it does not introduce any new features to what already exists in the OAuth 2.0 set of protocols.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

P.S.=C2=A0 I assert that any incompatible changes sh= ould be proposed as part of the TxAuth effort and not as part of OAuth 2.1.=

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000005fb36505a0fe0cbc--