Re: [OAUTH-WG] Clarifying the scope of the OAuth 2.1 spec (Mike Jones)

Lee McGovern <Lee_McGovern@swissre.com> Mon, 16 March 2020 08:46 UTC

Return-Path: <Lee_McGovern@swissre.com>
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 DB8EE3A2139 for <oauth@ietfa.amsl.com>; Mon, 16 Mar 2020 01:46:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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=swissre.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 mlodHuzT2j72 for <oauth@ietfa.amsl.com>; Mon, 16 Mar 2020 01:46:14 -0700 (PDT)
Received: from esa3.hc1106-67.c3s2.iphmx.com (esa3.hc1106-67.c3s2.iphmx.com [139.138.62.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3D03A2136 for <oauth@ietf.org>; Mon, 16 Mar 2020 01:46:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=swissre.com; i=@swissre.com; q=dns/txt; s=srprod19; t=1584348374; x=1615884374; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=CoevNfiZ42U0LstWr8gak3KlpjB2XFd8eV2Y/aZW4nQ=; b=ZFaUhckLF0r/g6BLTOF7iqHnvstIn5Cwo1zT33jZug8pqkiH8jJz6Uf/ gLiJ6kU2R/gPgpm6l5f3AImxvTdryfSW6+uMwhw1IM1ISS4/POZiNbDg8 A1nKCNX4uekaxC0zR2bMroL0rOkltKngMLyIQao8jSbTzxUWJillSeUYP xuldalIUGV/fHyypRZz2jwFoLMZcV7p2toiiFAjQrVv0Sqj8P+rLz/MPf LQvDMCHWu7M2q+c1A3RMlv4ddL5eqjWFrwr3HpEaaEtyVYSGLFhYJeBc7 hqUHt+cMxhE9P0wZFsMYMxhQ3ciURBxc9UswFJuwjvZQ86ICfKhpkszxr A==;
IronPort-SDR: 8nVPIpC2pgvL4B0DjBWogZkZc3RO2a2ujemxlO8UQvP9UIF8qyNDIOKLj9vluMLXMA5xJ0PRyx 8nbjQiEWy84fadsiwYNirqW2m4sBujyRUVJvzmJl647IBhPQMOluUJrtV69NdmHQ2H3NAAuGAu ovWiPIJknATDyeEpvwS7ixOuktrxFDVW+XFC7vbnRWV8CHspE6kxrz+bI9IkbXbg1D2mopIzlr wgg8D/2/WjeQYluQWEN3JhpugDQle2qUUt+u23k/bnYq1fP5eRfcKNWnPGRnoaxGbxbFECJaSq wO4=
X-Amp-Result: SKIPPED(no attachment in message)
Received: from edge.swissre.com ([193.246.239.101]) by esa3.hc1106-67.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 16 Mar 2020 08:45:54 +0000
Received: from CHRP5015.corp.gwpnet.com (10.53.1.47) by edge.swissre.com (193.246.239.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 16 Mar 2020 09:45:50 +0100
Received: from CHRP5009.corp.gwpnet.com (10.53.1.44) by CHRP5015.corp.gwpnet.com (10.53.1.47) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 16 Mar 2020 09:45:50 +0100
Received: from CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6]) by CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6%15]) with mapi id 15.00.1497.000; Mon, 16 Mar 2020 09:45:50 +0100
From: Lee McGovern <Lee_McGovern@swissre.com>
To: "oauth@ietf.org" <oauth@ietf.org>, "Michael.Jones@microsoft.com" <Michael.Jones@microsoft.com>
Thread-Topic: Clarifying the scope of the OAuth 2.1 spec (Mike Jones)
Thread-Index: AdX7bwhOsl5sek/0R2qXY9S8RBoGMA==
Date: Mon, 16 Mar 2020 08:45:50 +0000
Message-ID: <e80f55cb511d4a12bcd109df105b09bf@CHRP5009.corp.gwpnet.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Enabled=True; =?utf-8?q?MSIP=5FLabel=5F90c2fedb-0da6-4717-8531-d16a1b9930f4=5FSiteId=3D45?= =?utf-8?q?597f60-6e37-4be7-acfb-4c9e23b261ea=3B_MSIP=5FLabel=5F90c2fedb-0da?= =?utf-8?q?6-4717-8531-d16a1b9930f4=5FOwner=3DLee=5FMcGovern=40swissre=2Ecom?= =?utf-8?q?=3B_MSIP=5FLabel=5F90c2fedb-0da6-4717-8531-d16a1b9930f4=5FSetDate?= =?utf-8?q?=3D2020-03-16T08=3A45=3A48=2E6181217Z=3B?= MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Name=Internal; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Application=Microsoft Azure =?utf-8?q?Information_Protection=3B_MSIP=5FLabel=5F90c2fedb-0da6-4717-8531-?= =?utf-8?q?d16a1b9930f4=5FExtended=5FMSFT=5FMethod=3DAutomatic=3B?= Sensitivity=Internal
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.62.28.10]
x-rcom-deduphash: 7b28d6cb-c207-4410-a70d-f46f338725bc
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-GBS-PROC: 2hq/bq6V77WAjFgw5xSV5ENI29WK7/gjyFVLBCHDMpI=
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/kP-WEcvF-w8DIcfKmzK0nLkGvAo>
Subject: Re: [OAUTH-WG] Clarifying the scope of the OAuth 2.1 spec (Mike Jones)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Mar 2020 08:46:16 -0000

The statement "removing features that are not currently considered to be best practices" is ambiguous and implies that the best practise could be reinterpreted to include the flows that are now being deprecated. Perhaps "removing features that are no longer considered to be best practices" is much clearer


----------------------------------------------------------------------

Message: 1
Date: Sun, 15 Mar 2020 21:34:56 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: "dick.hardt@gmail.com" <dick.hardt@gmail.com>om>, "aaron@parecki.com"
	<aaron@parecki.com>om>, "torsten@lodderstedt.net"
	<torsten@lodderstedt.net>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: [OAUTH-WG] Clarifying the scope of the OAuth 2.1 spec
Message-ID:
	<DM6PR00MB0684B029182673EADC9E0288F5F80@DM6PR00MB0684.namprd00.prod.outlook.com>
	
Content-Type: text/plain; charset="us-ascii"

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

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200315/87ef5f5d/attachment.html>




This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information.

Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender.
All incoming and outgoing e-mail messages are stored in the Swiss Re Electronic Message Repository.
If you do not wish the retention of potentially private e-mails by Swiss Re, we strongly advise you not to use the Swiss Re e-mail account for any private, non-business related communications.