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

From: Mike Jones <[email-masked]>
Date: Mon, 16 Mar 2020 18:35:14 +0000

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

---

From: Dick Hardt <[email-masked]>
Date: Mon, 16 Mar 2020 12:32:07 -0700

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 <[email-masked]>
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.
>
>
>
> 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.
>
>
>
> *From:* Dick Hardt <[email-masked]>
> *Sent:* Monday, March 16, 2020 8:36 AM
> *To:* Mike Jones <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *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.
>
>
>
> 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>
> ].
>
>
>
> On Sun, Mar 15, 2020 at 9:01 PM Mike Jones <[email-masked]>
> 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-masked]>
> *Sent:* Sunday, March 15, 2020 6:50 PM
> *To:* Mike Jones <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *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?
>
>
>
> On Sun, Mar 15, 2020 at 2:34 PM Mike Jones <[email-masked]>
> wrote:
>
>    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.
>
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 16 Mar 2020 19:40:49 +0000

Perfect – thanks for listening.

                                                       -- Mike

Sent: Monday, March 16, 2020 12:32 PM

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 <[email-masked]<mailto:[email-masked]>> 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:

                                                       -- Mike

Hi Mike

ᐧ

                                                       Thanks,
                                                       -- Mike

Hi Mike

                                                       Thanks,
                                                       -- Mike

---

From: Brian Campbell <[email-masked]>
Date: Mon, 16 Mar 2020 13:44:07 -0600

+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 <Michael.Jones=
[email-masked]> wrote:

> *Sent:* Monday, March 16, 2020 12:32 PM
> 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
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: William Denniss <[email-masked]>
Date: Mon, 16 Mar 2020 12:53:05 -0700

> 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.

Does this text "It does so by removing portions of them that are no longer
considered best security practices" relate to 8252 or just 6749? If both,
then what is the portion of 8252 no longer considered best practice?

On Mon, Mar 16, 2020 at 12:44 PM Brian Campbell <bcampbell=
[email-masked]> wrote:

>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> 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"
>>
>>
>>
>> <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
>> 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.”
>>
>>
>>
>> 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
>> 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.
>>
>>
>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]