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

[Dick Hardt <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> *Sent:* Monday, March 16, 2020 8:36 AM
> *To:* Mike Jones <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; [e-mail]
> *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 <[e-mail]>
> 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 <[e-mail]>
> *Sent:* Sunday, March 15, 2020 6:50 PM
> *To:* Mike Jones <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; [e-mail]
> *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 <[e-mail]>
> 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.
>
>
>
>