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 <[email protected]> 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 <[email protected]> > *Sent:* Sunday, March 15, 2020 6:50 PM > *To:* Mike Jones <[email protected]> > *Cc:* [email protected]; [email protected]; [email protected] > *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 <[email protected]> > 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
