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 to incorporate with my co-authors. ᐧ
On Mon, Mar 16, 2020 at 11:35 AM Mike Jones <michael.jo...@microsoft.com> wrote: > Thanks for the clarifications, Dick. Here’s my resulting proposed > 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 <https://tools.ietf.org/html/rfc6749>. > > 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 “OAuth Parameters” 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 – saying that stuff not explicitly obsoleted isn’t being > changed – is critical to reducing the marketplace anxiety that this 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 <dick.ha...@gmail.com> > *Sent:* Monday, March 16, 2020 8:36 AM > *To:* Mike Jones <michael.jo...@microsoft.com> > *Cc:* aa...@parecki.com; tors...@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 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.jo...@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.ha...@gmail.com> > *Sent:* Sunday, March 15, 2020 6:50 PM > *To:* Mike Jones <michael.jo...@microsoft.com> > *Cc:* aa...@parecki.com; tors...@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.jo...@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. > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
