Re: [Txauth] [EXTERNAL] Re: Call for charter consensus - TxAuth WG

Mike Jones <Michael.Jones@microsoft.com> Tue, 17 March 2020 17:12 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3E83A08CB for <txauth@ietfa.amsl.com>; Tue, 17 Mar 2020 10:12:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 BsZp8GTfQpO6 for <txauth@ietfa.amsl.com>; Tue, 17 Mar 2020 10:12:03 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650122.outbound.protection.outlook.com [40.107.65.122]) (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 7BCD73A0824 for <txauth@ietf.org>; Tue, 17 Mar 2020 10:12:03 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qf0jY3ZolmOYdXgY/GlhGcVM1xTnZIC5qqOK9l7ecvTr4WvYFwkr/ls0wts0UyKODFD9NQD0FpqGqbj6VGJOXZUytEZ8VwU9epN9xSdFaBbz3+qDqoWX7CM5riu2vZ64B0A8eO8COu+lErnPyZ5Z2X24rEk6MpqHqieS2HrAu6MgvOrhlcMRgUx/9jlPFaNBygS3U2fBT7xqmSttYKS0RT7+ckET7jcYqD4oJmBJRYVxU9ijLzNXDID3kmOfKpPW3jhy5IXlBL641rW75+SaC+UnYORUtOLo6SJdkg02NebC6R00RWXmbOGc2tsAXeKerTWN3kUM25Dn8OiNE/1IEw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=oOVJMSavrjj7F4Qp8NpQ82ASgiz9M+5j5/EHJBDImuc=; b=KyCcBLaGUhLpzzGhMAJPVcTx8dbIdFjv0eJebr0f5zATrxhxJWWZYY0atLCNp3AtbEJdW8ab6CbsWIsVLwPSmXnROnv6TIEUxFnuGnO8jximO6RTids0nUSloUBgqN63mHh7I5Xlajg8R54oUaymQHGPiLDkdSCAwVbF8uiNyfPy2kxJy9kYIv2wDd+1L7OzzgC3wqh9uaNnsII2K0K6tLxGCiW9aJgEuegVJ3KhoGFN/HyBWb58dHF+MRL8qig24+44hOwZ2q3/HO/TNpI2gf2uAowlpryFbg2ikXXBOX674tgoPpkm6Ym4bEVviNV5j3rp6Y9Wcw1bx9OezE3mwg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=oOVJMSavrjj7F4Qp8NpQ82ASgiz9M+5j5/EHJBDImuc=; b=XYQ1kCKUNTxW1H4RiJbaUb3FxiJKRNP4RY01/3NX/ZnlGyhWKB7Ct8CQJZHfXm9xpUyQX7sXAyR6X1a5ggx+HW/DpholPx15Qmau7pG9OGGLQrT+b3MSqOqr3UL1Kt1a34/PqBPrC2q7sjFMC6VXXfeC2HnwbnkjPoicXDebtJM=
Received: from CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) by CH2PR00MB0762.namprd00.prod.outlook.com (2603:10b6:610:61::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2873.0; Tue, 17 Mar 2020 17:12:01 +0000
Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::a56a:2989:f37f:7a7a]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::a56a:2989:f37f:7a7a%3]) with mapi id 15.20.2872.000; Tue, 17 Mar 2020 17:12:01 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
CC: "txauth@ietf.org" <txauth@ietf.org>
Thread-Topic: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth WG
Thread-Index: AQHV89abQy9HJ60g4UeTXV6BVVcAf6g9P3CAgA/VDtA=
Date: Tue, 17 Mar 2020 17:12:01 +0000
Message-ID: <CH2PR00MB0678D42011BFCA0FD404ED84F5F60@CH2PR00MB0678.namprd00.prod.outlook.com>
References: <A01F5301-54DF-41D4-8ABE-8B070180F6FE@gmail.com> <970D54F0-E407-4578-A93E-F0EE589667F9@lodderstedt.net>
In-Reply-To: <970D54F0-E407-4578-A93E-F0EE589667F9@lodderstedt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=8071f721-98ce-4dc0-8fbe-0000aa53de5a; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-03-17T17:04:14Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-originating-ip: [50.47.81.134]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 787d3b31-05de-4d9c-9408-08d7ca964ee7
x-ms-traffictypediagnostic: CH2PR00MB0762:
x-microsoft-antispam-prvs: <CH2PR00MB0762D7375181AB5CD66F58A4F5F60@CH2PR00MB0762.namprd00.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0345CFD558
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(4636009)(366004)(396003)(346002)(376002)(39860400002)(136003)(199004)(110136005)(2906002)(316002)(53546011)(6506007)(966005)(81156014)(8936002)(81166006)(7696005)(55016002)(66446008)(76116006)(64756008)(66476007)(66946007)(66556008)(33656002)(9686003)(478600001)(5660300002)(66574012)(4326008)(186003)(71200400001)(26005)(52536014)(8676002)(10290500003)(86362001)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0762; H:CH2PR00MB0678.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: aTky1PXS1jYe+TjCT8gUQme+H5XkIi0Eh9PSXb1HFNL5H9eiNBV4MlIL8+ThUpz2Hff0VpOw+Or0gzNrp4iSiGOl7WQMP1eUUYD+uUcbktgQ4tsnuhVp7hTQmAeybbVvaz5SlJnU1R6W+oVOc2wK7wwUCdZQyHE3w6HQDQw3CyreMGdETyPFu3RE00H5++kQ7KxrQau+JPeYYCs37avJKg0jNODqoYGzHG/KYE2gJA1uEALrkSKhuQK7fNy4nUY5+nSPMvc8CJU85zAkstIRI8wQY7aIlOQbsQ/kI6ulDx08G15Zsn33xjPnijOdFBc2iuDSpGaKAUyQMWhqREPa92MHZ7sk2UQamfk9bCiAjK0Ng0i/ewqHA7vMv3E70JUfOpCeCzBkMQZRhm41E0cynY3XSZySDfZK6joI5ec1e3r+YErLGjg9RVVmupJd/LIZJ1mrTsi8WNIKmZyvQxmUDwIbF53c2A4wVwAc0dSy28xXlJGFD8rIz2xpgqr6FBkdOsj4g45q/OuB6Yrjj5mnfg==
x-ms-exchange-antispam-messagedata: SE8kOsKPjnn2QROsgxUpupjmwsfXOjbo9loMiwQTXMV+kPlBhZyWiZJWMNPzcDTts225dV+uk/E7UMv//3svQILhI7IBJqABUMswTQsHdhiWi1iyPzadbF2tNKKS/QnuQVwL+j3N6uirM/XuIVDGAQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 787d3b31-05de-4d9c-9408-08d7ca964ee7
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2020 17:12:01.2843 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: +T231FJ+95ne+v7fnRh3tzehImMCJdRCAAvrMkq+qHt3HFXQAD6y1nS8s24J/0lRSqSQVdiRH+BtZ6cmOryUow==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0762
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/e329lD4JYfe8ufB8xstp2E6IBeU>
Subject: Re: [Txauth] [EXTERNAL] Re: Call for charter consensus - TxAuth WG
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Mar 2020 17:12:07 -0000

1.  Do you support the charter text provided at the end of this email?  Or do you have major objections, blocking concerns or feedback (if so please elaborate)?

I share the concerns about including identity in the charter that were expressed by Torsten and agreed with by David Skaife.  I'll note that Kim Cameron previously expressed concerns about including identity in his earlier charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/.

I'm fine with refactoring the authorization protocol.  But identity should be decoupled from the TxAuth work to focus its scope on areas where innovation is being proposed.  Digital identity can always be added as a layer if needed, just as OpenID Connect layered identity onto OAuth 2.0.

Please revise the charter to remove digital identity from the scope of the work.
 
2.  Are you willing to author or participate in the development of the drafts of this WG?
 
Yes

3.  Are you willing to help review the drafts of this WG?
 
Yes

4.  Are you interested in implementing drafts of this WG?

Not at this time.

				-- Mike

-----Original Message-----
From: Txauth <txauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt
Sent: Saturday, March 7, 2020 7:18 AM
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: txauth@ietf.org
Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth WG

Hi,

> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>:
> 
> Hi Everyone,
>  
> It appears that momentum is forming around the proposed formation of a TxAuth working group.  We’d like to more formally gauge interest in proceeding with this work.  Please do so by responding to the following questions:
>  
> 1.  Do you support the charter text provided at the end of this email?  Or do you have major objections, blocking concerns or feedback (if so please elaborate)?

I‘m in although I have to admit I‘m slightly concerned the scope of the charter is too broad, e.g. identify alone is a huge topic.

We need to keep an eye on this aspect in order to make sure, the group is able to work effectively and the specs we will be producing are as simple as possible and foster interoperability.

>  
> 2.  Are you willing to author or participate in the development of the drafts of this WG?

yes

>  
> 3.  Are you willing to help review the drafts of this WG?

yes

>  
> 4.  Are you interested in implementing drafts of this WG?

yes

best regards,
Torsten.

>  
> The call will run for two weeks, until March 21. If you think that the charter should be amended In a significant way, please reply on a separate thread.
>  
> The feedback provided here will help the IESG come to a decision on the formation of a new WG. Given the constraints of the chartering process, regardless of the outcome of this consensus call, we will be meeting in Vancouver as a BoF.
>  
> Thanks,
> Yaron and Dick
>  
> --- Charter Text Follows ---
> 
> This group is chartered to develop a fine-grained delegation protocol for authorization, identity, and API access. This protocol will allow an authorizing party to delegate access to client software through an authorization server. It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove unnecessary dependence on a browser or user-agent for coordinating interactions. 
> 
> The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the interaction channels, such as the end user’s browser, from the delegation channel, which happens directly between the client and the authorization server (in contrast with OAuth 2.0 which is initiated by the client redirecting the user’s browser). The client and AS will involve a user to make an authorization decision as necessary through interaction mechanisms indicated by the protocol. This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types of clients and interaction channels.
> 
> Additionally, the delegation process will allow for:
> 
> - Fine-grained specification of access
> - Approval of AS attestation to identity claims
> - Approval of access to multiple resources and APIs in a single interaction
> - Separation between the party authorizing access and the party operating the client requesting access
> - A variety of client applications, including Web, mobile, single-page, and interaction-constrained applications
> 
> The group will define extension points for this protocol to allow for flexibility in areas including:
> 
> - Cryptographic agility for keys, message signatures, and proof of possession 
> - User interaction mechanisms including web and non-web methods
> - Mechanisms for conveying user, software, organization, and other pieces of information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys
> - Optimized inclusion of additional information through the delegation process (including identity)
> 
> Additionally, the group will provide mechanisms for management of the protocol lifecycle including:
> 
> - Discovery of the authorization server
> - Revocation of active tokens
> - Query of token rights by resource servers
> 
> Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible.
> 
> This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions not necessarily compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be developed in the OAuth Working Group, including functionality back-ported from the protocol developed here to OAuth 2.0.
> 
> The group is chartered to develop mechanisms for applying cryptographic methods, such as JOSE and COSE, to the delegation process. This group is not chartered to develop new cryptographic methods. 
> 
> The initial work will focus on using HTTP for communication between the client and the authorization server, taking advantage of optimization features of HTTP2 and HTTP3 where possible, and will strive to enable simple mapping to other protocols such as COAP when doing so does not conflict with the primary focus.
> 
> Milestones to include:
> - Core delegation protocol
> - Key presentation mechanism bindings to the core protocol for TLS, detached HTTP signature, and embedded HTTP signatures
> - Identity and authentication conveyance mechanisms
> - Guidelines for use of protocol extension points
> 
> 
> -- 
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth