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 EE8113A0FA2 for ; Mon, 16 Mar 2020 12:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, 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=gmail.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 NVlRjITh4WIp for ; Mon, 16 Mar 2020 12:32:36 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 F07B93A0F9D for ; Mon, 16 Mar 2020 12:32:35 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id o10so20047499ljc.8 for ; Mon, 16 Mar 2020 12:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v/0VbBXOPfpHYdsBjG8qUplC8H/a8xYk+W1gfnjP7qI=; b=OnLs54T5Lt2Coo4VE2aBQAZ/Hua44ONgqDO1e5Sh1AnZhL8TgK/EeQb7veqPWpBusT e5exwkm4k+GXQJYJmeA8vBKi4WNbyxTikx/+9577vHrBcKnlq21NQaOrZ0THvDqkl3dn DOluLgY2SWZSTFt3XnX5uynOQ/yPq0weYWc4g3+CsBBPTxV71leBzV4bzh2UF8o7WqL+ zpDbFdqNvlNGfaT5306yoPeCI0i4TY/lYsPPVlRPu1dk1cDnBq07jDDzHFLXKRA0Q+24 Yn1XJ2Y6/nj3bQEvNks2i0nbXuJoUTifGW5mJuZNaACyvmfKMkipcg1Q1BCo2s9WJmLK k+fw== 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=v/0VbBXOPfpHYdsBjG8qUplC8H/a8xYk+W1gfnjP7qI=; b=GT/ir05iiG5XkSek6X1/y2r8EGzZU2q3abeqWAE/6nyhqF+HCBimiQb6Q4zJdI2t++ 8Z6wxG9RMRyuAhX7vJfA/xLmxhG4WmmcWB0AL9mfxbguhHNvINKysx3Ek7EP/55fWBhk THVR8CP0r6PeaPeq/3xN3EHlGKISdXBs9RMdeNgjtfUPRjhOsN/iJK+OjOjC/lhOEdig 23isvml3fBo8VxwY1+RYy64riP5SaOuNd5vRRMw0dCZ7yxF6A/I22RvPi5BSwct4BsIn juZMZt+ePlEMVJVlntrvFv5z0OIa0nvJCnoqUNzuCwnm7dwziPCuiSnkaka6dfMOKCs7 kotg== X-Gm-Message-State: ANhLgQ3w8SHkH3MD1SOF0TvcxnE6OCHESdsZadEkQ1oE0HBP5z0UsspW DvIZg9i1WjNEN5vpBDH6M/CfF6GWucgLXptji5o= X-Google-Smtp-Source: =?utf-8?q?ADFU+vvl7gpCsq1D7FSHnu/SdIPiiiohb2wh3ohnXScE?= =?utf-8?q?flfOzZWmSmeCNBfW3QbTkvzd1eu43LdD7ghEei2XyzCedDo=3D?= X-Received: by 2002:a2e:9d84:: with SMTP id c4mr520913ljj.51.1584387153902; Mon, 16 Mar 2020 12:32:33 -0700 (PDT) MIME-Version: 1.0 References: =?utf-8?q?=3CDM6PR00MB06845FEB6201E73E87CA30B9F5F90=40DM6PR00MB0?= =?utf-8?q?684=2Enamprd00=2Eprod=2Eoutlook=2Ecom=3E?= In-Reply-To: =?utf-8?q?=3CDM6PR00MB06845FEB6201E73E87CA30B9F5F90=40DM6PR00MB?= =?utf-8?q?0684=2Enamprd00=2Eprod=2Eoutlook=2Ecom=3E?= From: Dick Hardt Date: Mon, 16 Mar 2020 12:32:07 -0700 Message-ID: To: Mike Jones Cc: "aaron@parecki.com" , "torsten@lodderstedt.net" , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007ec33b05a0fde125" Archived-At: Subject: Re: [OAUTH-WG] 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:32:40 -0000 --0000000000007ec33b05a0fde125 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. =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. > > > > --0000000000007ec33b05a0fde125 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the suggested text Mike. A little wordy for me,= but I agree with the intention to minimize market place=C2=A0confusion. I&= #39;ll discuss how to incorporate with my co-authors.
3D""=E1=90= =A7

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 o= bsoletes the OAuth 2.0 Authorization Framework described in RFC = 6749.

to:=

This specification replaces and obsoletes these OAuth 2.0 specif= ications:=C2=A0 RFC 6749 and RFC 8252.=C2=A0 It does so by removing portion= s 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.=C2=A0 By design, it does not introduc= e any new features to what already exists in the OAuth 2.0 specifications b= eing 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-OAuth-working-group profi= les 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 r= eplaced.

=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 uncert= ainty 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@lodderstedt.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 ([= 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-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-oau= th-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 much 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 replaces and obsoletes the OA= uth 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

--0000000000007ec33b05a0fde125--