From nobody Mon Sep 2 02:40:33 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09889120073; Mon, 2 Sep 2019 02:40:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-oauth-resource-indicators@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <156741723195.13041.3519982606374763447.idtracker@ietfa.amsl.com> Date: Mon, 02 Sep 2019 02:40:31 -0700 Archived-At: Subject: [OAUTH-WG] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-oauth-resource-indicators-05=3A_=28with_COMMENT=29?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 09:40:32 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-oauth-resource-indicators-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the hard work put into this easy to read document. Regards, -éric == COMMENTS == -- Section 1 -- "has uncovered a need, in some circumstances" (and similar sentences in section 1), it is rather vague for a standard track document... Please add some facts and data, this could be a companion document about requirements/use cases. -- Section 2 -- It is rather a question of mine, why does the resource need to be a URI (which usually bears some visible semantics) rather than an opaque string known only by the resource owner/server ? This is similar to Mirja's comment about privacy. From nobody Mon Sep 2 03:22:59 2019 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 7F725120073; Mon, 2 Sep 2019 03:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 DRxsrMFNDv0q; Mon, 2 Sep 2019 03:22:54 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-oln040092004078.outbound.protection.outlook.com [40.92.4.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8140312006B; Mon, 2 Sep 2019 03:22:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UeERqfmRFSiAcXAO5LDN6FVAbNZhYQHFnWfkWXh+VLVx0EtycLPZaDl+SmQ47+QL9Lv1dRIS55D8GRLRBSNp+NwDuWi232n79/2s5Lz2D3tqx3k/sQTNarz3Zt/FIvIC7eDMOAs+RWkPFHlzIDL6336p1FQnf9cRNYI0wNQ6AFuKnpGhl7NhcY/jCBTfUq/4QyLhpO/44f+J9djnUmKMhY1nbWRuxNhSyQVImxHUg9KwFl/yRe79OA9tNvdiRUT2Q3rpRPyinckUvdpkpxDjZX8vLi0RPCvbWMYJGByDYE79U1va5lUZzDDkpwul4vRnR4GzC0rrunPwAvVpk+v2Fw== 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=lSOTZA+kQnW96wl5nDaPtbq6oRNVPlrnDMqPGs0Skts=; b=l+jfxOrah19Q8zgcFy+pJydraBFAZHvbjL5YbvdquTKfwmcUQWiyttatGHtpom8H+bbF14arYbQG/Y30H+8GaG3epNIrXhKS9h0cjX6BhUwUYQ2VHKz0oRT8H0jQhq9xwDi6I8moiLOb7ZeomAn43uHV4P5vSiv5fEgd73vsRBJUlpHflQzj+He46lgUKLhY2preuDvgeWd9uZj1KitDuHQ5xLxGLglW06z7hekov+m9f4N5Zn6IvpCQhYeP8TtF7gJYEavlf7CMGMU4QKAFr4AneO6XpFLoe72TPRZUvJLx4H+WKtbuOMz+qlS0jLYKer1Ucj9svnOI5aKP3l1OUw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lSOTZA+kQnW96wl5nDaPtbq6oRNVPlrnDMqPGs0Skts=; b=dVjTeyOQPcXt5P89qHdxPcRyyeQx3MhcnGH6ULqAR1zuRIVMyzb3h5NoSy7AgT3Vhcda98gtJp2HsooYb3RIdWv+6V0rhePmLzL6VoD2F1FngNHtPmLb3w8rToNq1bUrBybB3PxWXDQaRGRagIQSlSdZBBusD/AHW2abIdQs+a+Jx/mM/CtqSA5+/1lSebjL0HVc7uiuJEnTtl4RUv9u3DTMJxmySllmM0UwnPK3F7KSk5D/0nkBERGhlq/5W+qGy4YPDUQid7ZFKcLfNj0j6TUgE9DwG6jJAPQ0uYqknGJyeTaDLm+vp2yoPaFJdO/eInHEv5jrRqq8EHrUPV7hKg== Received: from BL2NAM02FT017.eop-nam02.prod.protection.outlook.com (10.152.76.56) by BL2NAM02HT141.eop-nam02.prod.protection.outlook.com (10.152.77.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2220.16; Mon, 2 Sep 2019 10:22:53 +0000 Received: from CH2PR15MB3606.namprd15.prod.outlook.com (10.152.76.54) by BL2NAM02FT017.mail.protection.outlook.com (10.152.77.174) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.16 via Frontend Transport; Mon, 2 Sep 2019 10:22:53 +0000 Received: from CH2PR15MB3606.namprd15.prod.outlook.com ([fe80::b4f0:4640:f5e5:2198]) by CH2PR15MB3606.namprd15.prod.outlook.com ([fe80::b4f0:4640:f5e5:2198%7]) with mapi id 15.20.2178.023; Mon, 2 Sep 2019 10:22:53 +0000 From: ki de To: =?utf-8?B?w4lyaWMgVnluY2tl?= CC: The IESG , "draft-ietf-oauth-resource-indicators@ietf.org" , "oauth@ietf.org" , "oauth-chairs@ietf.org" Thread-Topic: =?utf-8?B?W09BVVRILVdHXSDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJh?= =?utf-8?B?ZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTA1OiAod2l0aCBD?= =?utf-8?Q?OMMENT)?= Thread-Index: AQHVYXJ/EgVnTbPAnUGAk6PVgaIWsKcYLdqA Date: Mon, 2 Sep 2019 10:22:53 +0000 Message-ID: References: <156741723195.13041.3519982606374763447.idtracker@ietfa.amsl.com> In-Reply-To: <156741723195.13041.3519982606374763447.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: MN2PR01CA0019.prod.exchangelabs.com (2603:10b6:208:10c::32) To CH2PR15MB3606.namprd15.prod.outlook.com (2603:10b6:610:2::31) x-incomingtopheadermarker: OriginalChecksum:1EF542C2CCF42C88D3AEEAB2A73246C10DA2B9AF00A51885FC80D88F07FE6BC9; UpperCasedChecksum:8D34EDC766A4B6BD99090F473E4C55847E378AD98CAFED41DE605398A3705883; SizeAsReceived:7888; Count:49 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [yRGt8x/3pXUqhI8w2srsZ5hVR2i/7hA4v1GSDxcbsUCSxLdnvII+ATh3lDQ7lbiOKpqgL0WOMIU=] x-microsoft-original-message-id: x-ms-publictraffictype: Email x-incomingheadercount: 49 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119158)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045); SRVR:BL2NAM02HT141; x-ms-traffictypediagnostic: BL2NAM02HT141: x-microsoft-antispam-message-info: OKe5rlT+3VOObBprMxTK7YiNqT377GmazEzQk4WjYv6fnUCZUihsJz43Dwtq5vt16sRYBt4WX8FBfzfsVx9W2RL55ItHqTUtNIE9IeFeBNZAovuG/ClwpKavPTX2z4wX7OKB5r5UJSf6c/oPscwIce1IPgF9ojQZnvGTn4FqbDGHzgwivT9JOkI8yWd7sEWg x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR15MB3606603D750B0001DEDEAE16D7BE0CH2PR15MB3606namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 2d8e0ee4-2004-4246-3dab-08d72f8f837c X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2019 10:22:53.0539 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT141 Archived-At: Subject: Re: [OAUTH-WG] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-oauth-resource-indicators-05=3A_=28with_COMMENT=29?= 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, 02 Sep 2019 10:22:57 -0000 --_000_CH2PR15MB3606603D750B0001DEDEAE16D7BE0CH2PR15MB3606namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIE1vbiwgU2VwIDIsIDIwMTkgYXQgNTo0MCBBTSA/cmljIFZ5bmNrZSB2aWEgRGF0YXRy YWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KP3JpYyBWeW5ja2UgaGFzIGVudGVyZWQg dGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLW9hdXRoLXJlc291 cmNlLWluZGljYXRvcnMtMDU6IE5vIE9iamVjdGlvbg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFz ZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCmVtYWlsIGFk ZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1 dCB0aGlzDQppbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KUGxlYXNlIHJlZmVy IHRvIGh0dHBzOi8vbmFtMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRmllc2clMkZzdGF0ZW1lbnQlMkZkaXNjdXNzLWNy aXRlcmlhLmh0bWwmYW1wO2RhdGE9MDIlN0MwMSU3QyU3Q2RhMDUwOGJjN2I5YTQ1OThhZTZmMDhk NzJmODlhMTA0JTdDODRkZjllN2ZlOWY2NDBhZmI0MzVhYWFhYWFhYWFhYWElN0MxJTdDMCU3QzYz NzAzMDE0MDQ2MTkxNTk0OCZhbXA7c2RhdGE9c0s1Nmo5YndWeUxsTnVwZ0VkeEV4ZGFCVFRPTG5J MjglMkZZU1RKVmdMcEc0JTNEJmFtcDtyZXNlcnZlZD0wDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQpUaGUgZG9jdW1lbnQs IGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpo dHRwczovL25hbTAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LWlldGYtb2F1dGgtcmVz b3VyY2UtaW5kaWNhdG9ycyUyRiZhbXA7ZGF0YT0wMiU3QzAxJTdDJTdDZGEwNTA4YmM3YjlhNDU5 OGFlNmYwOGQ3MmY4OWExMDQlN0M4NGRmOWU3ZmU5ZjY0MGFmYjQzNWFhYWFhYWFhYWFhYSU3QzEl N0MwJTdDNjM3MDMwMTQwNDYxOTI1OTU5JmFtcDtzZGF0YT15R3owY3lSYjdGZ1l4SHRIT01MVFNj WmVJcFRTUUdiN3B1Nk5PaFFGMkljJTNEJmFtcDtyZXNlcnZlZD0wDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRoYW5rIHlvdSBmb3IgdGhlIGhhcmQgd29yayBw dXQgaW50byB0aGlzIGVhc3kgdG8gcmVhZCBkb2N1bWVudC4NCg0KUmVnYXJkcywNCg0KLT9yaWMN Cg0KPT0gQ09NTUVOVFMgPT0NCg0KLS0gU2VjdGlvbiAxIC0tDQoiaGFzIHVuY292ZXJlZCBhIG5l ZWQsIGluIHNvbWUgY2lyY3Vtc3RhbmNlcyIgKGFuZCBzaW1pbGFyIHNlbnRlbmNlcyBpbiBzZWN0 aW9uDQoxKSwgaXQgaXMgcmF0aGVyIHZhZ3VlIGZvciBhIHN0YW5kYXJkIHRyYWNrIGRvY3VtZW50 Li4uIFBsZWFzZSBhZGQgc29tZSBmYWN0cw0KYW5kIGRhdGEsIHRoaXMgY291bGQgYmUgYSBjb21w YW5pb24gZG9jdW1lbnQgYWJvdXQgcmVxdWlyZW1lbnRzL3VzZSBjYXNlcy4NCg0KLS0gU2VjdGlv biAyIC0tDQpJdCBpcyByYXRoZXIgYSBxdWVzdGlvbiBvZiBtaW5lLCB3aHkgZG9lcyB0aGUgcmVz b3VyY2UgbmVlZCB0byBiZSBhIFVSSSAod2hpY2gNCnVzdWFsbHkgYmVhcnMgc29tZSB2aXNpYmxl IHNlbWFudGljcykgcmF0aGVyIHRoYW4gYW4gb3BhcXVlIHN0cmluZyBrbm93biBvbmx5DQpieSB0 aGUgcmVzb3VyY2Ugb3duZXIvc2VydmVyID8gVGhpcyBpcyBzaW1pbGFyIHRvIE1pcmphJ3MgY29t bWVudCBhYm91dCBwcml2YWN5Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6 Ly9uYW0wMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgmYW1wO2RhdGE9MDIl N0MwMSU3QyU3Q2RhMDUwOGJjN2I5YTQ1OThhZTZmMDhkNzJmODlhMTA0JTdDODRkZjllN2ZlOWY2 NDBhZmI0MzVhYWFhYWFhYWFhYWElN0MxJTdDMCU3QzYzNzAzMDE0MDQ2MTkyNTk1OSZhbXA7c2Rh dGE9UWZjYkRxcUo5WjZnJTJCTHE4ZE5BQWl6UWNMZnBMeFI1NDNHQmFxWndpQXN3JTNEJmFtcDty ZXNlcnZlZD0wDQo= --_000_CH2PR15MB3606603D750B0001DEDEAE16D7BE0CH2PR15MB3606namp_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0 ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIE1vbiwgU2VwIDIsIDIwMTkgYXQgNTo0MCBBTSA/cmlj IFZ5bmNrZSB2aWEgRGF0YXRyYWNrZXIgJmx0O25vcmVwbHlAaWV0Zi5vcmcmZ3Q7IHdyb3RlOjxi cj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleDsi Pg0KP3JpYyBWeW5ja2UgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24g Zm9yPGJyPg0KZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTx3YnI+MDU6IE5v IE9iamVjdGlvbg0KPHA+V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBs aW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsPGJyPg0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVk IGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXM8YnI+DQppbnRy b2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLik8L3A+DQo8cD48YnI+DQpQbGVhc2UgcmVmZXIg dG8gaHR0cHM6Ly9uYW0wMy5zYWZlbGlua3MucHJvdGVjdGlvbi48d2JyPm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZ3d3cuPHdicj5pZXRmLm9yZyUyRmllc2clMkZzdGF0ZW1lbnQlMkZk aXNjdXNzLTx3YnI+Y3JpdGVyaWEuaHRtbCZhbXA7YW1wO2RhdGE9MDIlN0MwMSU3QyU3Q2RhMDUw OGJjN2I5YTQ1OThhZTZmMDhkNzJmODlhMTA0JTdDODRkZjllN2ZlOWY2NDBhZmI0MzVhYWFhYWFh YWFhYWElN0MxJTdDMCU3QzYzNzAzMDE0MDQ2MTkxNTk0OCZhbXA7PHdicj5hbXA7c2RhdGE9c0s1 Nmo5YndWeUxsTnVwZ0VkeEV4ZGFCVFRPTG5JMjglMkZZU1RKVmdMcEc0JTNEJmFtcDs8d2JyPmFt cDtyZXNlcnZlZD0wPGJyPg0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNT IGFuZCBDT01NRU5UIHBvc2l0aW9ucy48L3A+DQo8cD48YnI+DQpUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6PGJyPg0KaHR0 cHM6Ly9uYW0wMy5zYWZlbGlua3MucHJvdGVjdGlvbi48d2JyPm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZkYXRhdHJhY2tlci48d2JyPmlldGYub3JnJTJGZG9jJTJGZHJhZnQtaWV0Zi1v YXV0aC08d2JyPnJlc291cmNlLWluZGljYXRvcnMlMkYmYW1wO2FtcDtkYXRhPTx3YnI+MDIlN0Mw MSU3QyU3Q2RhMDUwOGJjN2I5YTQ1OThhZTZmMDhkNzJmODlhMTA0JTdDODRkZjllN2ZlOWY2NDBh ZmI0MzVhYWFhYWFhYWFhYWElN0MxJTdDMCU3QzYzNzAzMDE0MDQ2MTkyNTk1OSZhbXA7PHdicj5h bXA7c2RhdGE9eUd6MGN5UmI3RmdZeEh0SE9NTFRTY1plSXBUU1FHYjdwdTZOT2hRRjJJYyUzRCZh bXA7PHdicj5hbXA7cmVzZXJ2ZWQ9MDwvcD4NCjxwPjwvcD4NCjxwPi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPHdicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+ LS0tLS0tPGJyPg0KQ09NTUVOVDo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTx3YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLTwvcD4NCjxw PlRoYW5rIHlvdSBmb3IgdGhlIGhhcmQgd29yayBwdXQgaW50byB0aGlzIGVhc3kgdG8gcmVhZCBk b2N1bWVudC48L3A+DQo8cD5SZWdhcmRzLDwvcD4NCjxwPi0/cmljPC9wPg0KPHA+PT0gQ09NTUVO VFMgPT08L3A+DQo8cD4tLSBTZWN0aW9uIDEgLS08YnI+DQomcXVvdDtoYXMgdW5jb3ZlcmVkIGEg bmVlZCwgaW4gc29tZSBjaXJjdW1zdGFuY2VzJnF1b3Q7IChhbmQgc2ltaWxhciBzZW50ZW5jZXMg aW4gc2VjdGlvbjxicj4NCjEpLCBpdCBpcyByYXRoZXIgdmFndWUgZm9yIGEgc3RhbmRhcmQgdHJh Y2sgZG9jdW1lbnQuLi4gUGxlYXNlIGFkZCBzb21lIGZhY3RzPGJyPg0KYW5kIGRhdGEsIHRoaXMg Y291bGQgYmUgYSBjb21wYW5pb24gZG9jdW1lbnQgYWJvdXQgcmVxdWlyZW1lbnRzL3VzZSBjYXNl cy48L3A+DQo8cD4tLSBTZWN0aW9uIDIgLS08YnI+DQpJdCBpcyByYXRoZXIgYSBxdWVzdGlvbiBv ZiBtaW5lLCB3aHkgZG9lcyB0aGUgcmVzb3VyY2UgbmVlZCB0byBiZSBhIFVSSSAod2hpY2g8YnI+ DQp1c3VhbGx5IGJlYXJzIHNvbWUgdmlzaWJsZSBzZW1hbnRpY3MpIHJhdGhlciB0aGFuIGFuIG9w YXF1ZSBzdHJpbmcga25vd24gb25seTxicj4NCmJ5IHRoZSByZXNvdXJjZSBvd25lci9zZXJ2ZXIg PyBUaGlzIGlzIHNpbWlsYXIgdG8gTWlyamEncyBjb21tZW50IGFib3V0IHByaXZhY3kuPC9wPg0K PHA+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188d2JyPl9fX19fX19fX19f X19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCk9BdXRoQGlldGYub3JnPGJyPg0KaHR0 cHM6Ly9uYW0wMy5zYWZlbGlua3MucHJvdGVjdGlvbi48d2JyPm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ3d3cuPHdicj5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm9hdXRo JmFtcDs8d2JyPmFtcDtkYXRhPTAyJTdDMDElN0MlN0NkYTA1MDhiYzdiOWE0NTk4YWU2ZjA4ZDcy Zjg5YTEwNCU3Qzg0ZGY5ZTdmZTlmNjQwYWZiNDM1YWFhYWFhYWFhYWFhJTdDMSU3QzAlN0M2Mzcw MzAxNDA0NjE5MjU5NTkmYW1wOzx3YnI+YW1wO3NkYXRhPVFmY2JEcXFKOVo2ZyUyQkxxOGROQUFp elFjTGZwTHhSNTQzR0JhcVp3aUFzdyUzRCZhbXA7PHdicj5hbXA7cmVzZXJ2ZWQ9MDxicj4NCjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CH2PR15MB3606603D750B0001DEDEAE16D7BE0CH2PR15MB3606namp_-- From nobody Mon Sep 2 08:03:43 2019 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 A75C712025D for ; Mon, 2 Sep 2019 08:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Wwy0nQGrktIf for ; Mon, 2 Sep 2019 08:03:31 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 966DF120110 for ; Mon, 2 Sep 2019 08:03:31 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id u185so25857371iod.10 for ; Mon, 02 Sep 2019 08:03:31 -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; bh=JV36cjD6h7KkDBx1piQzuZ9EbxJf141yK7DsOoLWzBA=; b=A9ZdhC8f9XPoGnWPVpPOAHTmVTykOB42vuSrEdXIMe/YgUcI4bgjYIM72LNoG2LKI2 QTFylWIMZYKtVI83dpllO6m7WuQhbSYEvIVe/CIXQmeyld3EyqA+tJRxiV+6fI+xIEFE OTyKzKK+x3DMNxFbDHgNgrr73WoHsx07MUm1ACIq0QFD8yxsPm0s70KDEp45OhR9qcG9 Vt5/VA3nwBiPrZPvIwMERBMZOgPOA+t9o25i1o+68Ko7PIEpn2J0mOm98VFIScB1AyZT Zhn6HcGjUKoyecoiOimG7DJ5hRViw7EbiTBvxz4WTKGuJNByUeFsyYTUUbYirtbr6LQz VBQw== 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; bh=JV36cjD6h7KkDBx1piQzuZ9EbxJf141yK7DsOoLWzBA=; b=V79yhOt4g9b5BUXMHpKYbWqWiULA2hON2q9NzORolwm2katmbAsbmRgK3cl3etkktX s6qOL3i1ssKQ7k9Y/uOJKUABX6b39bDYgE1lxY4apx9HlnLw6e4QATw2SMXCtwXZ723G vJm2Xe3D65U6Tg3vSKgD/xm+Upab8KhjxA4lbGTBVs1p5rJoS7nTSD/2KHMkSYP9XGgu 1yWO5svlquEDzeLy61IXW21jx1IxA1gsC8BUoydqvZmr5C3TcakHV95A8/5qB3Rl7qX1 JEV1qDMdSxoxLXRvTCb+6XjzOv1YKYtFW+uit8o3cCA4+RwbUI900hYcrM7InEn0egf2 pGfg== X-Gm-Message-State: APjAAAXZYcjIl3P61lKBghBLp+qW3lDwk2JhFOyQ8Rkxy3/ervku6Rdw gpqgBXZlpjv0GhkB8jlgy9xjBGOlhUNJ4kU4oe7h4w== X-Google-Smtp-Source: APXvYqxFaNrAZ+vli08LFb+SWCaxvB9NfNjw6g0ExATFFCsh8p5YjONm0sNmBfMiIsA3mqdRTobAZLhBepcbvFawmiI= X-Received: by 2002:a5d:848d:: with SMTP id t13mr11397752iom.73.1567436610726; Mon, 02 Sep 2019 08:03:30 -0700 (PDT) MIME-Version: 1.0 References: <156743638187.13041.6265191308417450527.idtracker@ietfa.amsl.com> In-Reply-To: <156743638187.13041.6265191308417450527.idtracker@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Mon, 2 Sep 2019 11:03:20 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000063f3760591934646" Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-yusef-oauth-nested-jwt-02.txt 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, 02 Sep 2019 15:03:39 -0000 --00000000000063f3760591934646 Content-Type: text/plain; charset="UTF-8" All, I have submitted a new version of the Nested JWT draft and added the STIR use case. Please, take a look and let me know if you have any comments. Regards, Rifaat ---------- Forwarded message --------- From: Date: Mon, Sep 2, 2019 at 10:59 AM Subject: New Version Notification for draft-yusef-oauth-nested-jwt-02.txt To: Rifaat Shekh-Yusef A new version of I-D, draft-yusef-oauth-nested-jwt-02.txt has been successfully submitted by Rifaat Shekh-Yusef and posted to the IETF repository. Name: draft-yusef-oauth-nested-jwt Revision: 02 Title: Nested JSON Web Token (JWT) Document date: 2019-09-02 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-yusef-oauth-nested-jwt-02.txt Status: https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/ Htmlized: https://tools.ietf.org/html/draft-yusef-oauth-nested-jwt-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt Diff: https://www.ietf.org/rfcdiff?url2=draft-yusef-oauth-nested-jwt-02 Abstract: This specification extends the scope of the Nested JSON Web Token (JWT) to allow the enclosing JWT to contain its own Claims Set in addition to the enclosed JWT. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --00000000000063f3760591934646 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

I have submitted a new version of = the Nested JWT draft and added the STIR use case.
Please, take a = look and let me know if you have=C2=A0any comments.

Regards,
=C2=A0Rifaat


---------- Forwarded message ----= -----
From: <internet-drafts@ietf.org>
Date: Mon, Sep 2, 2019 at= 10:59 AM
Subject: New Version Notification for draft-yusef-oauth-nested= -jwt-02.txt
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>



A new version of I-D, draft-yusef-oauth-nested-jwt-02.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-yusef-oauth-nested-jwt<= br> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Nested JSON Web Token (JWT)
Document date:=C2=A0 2019-09-02
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-yusef-oauth-ne= sted-jwt-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://tools.ietf.org/html/draft-yusef-oauth-nested-jwt-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-yusef-oauth-nested-j= wt-02

Abstract:
=C2=A0 =C2=A0This specification extends the scope of the Nested JSON Web To= ken
=C2=A0 =C2=A0(JWT) to allow the enclosing JWT to contain its own Claims Set= in
=C2=A0 =C2=A0addition to the enclosed JWT.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--00000000000063f3760591934646-- From nobody Mon Sep 2 13:21:03 2019 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 741BF120058 for ; Mon, 2 Sep 2019 13:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01] 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 rwnHxxJgToPH for ; Mon, 2 Sep 2019 13:20:58 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 BD8DC12004A for ; Mon, 2 Sep 2019 13:20:58 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id z3so31246386iog.0 for ; Mon, 02 Sep 2019 13:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:date:subject:importance:from:to:mime-version; bh=8qnZR49QfFeLsK7HKCH+2JlZ15mfT88UXBOxPlAGmek=; b=Y9JCLDSvwYRrg+hErg4el8wlu2VM6vY0woJjFfwYuLl5FVdRvqjCT71y4xcqvn9ede Mi54fyg3rQfD2bdBJ+IqCgKW7pUpjR50rE3vVdCH9HG4Z3s/q0jw5zvtOFeJ4WjAh+c4 NA7XhLp1MJWBHpG/tGtPPNeJFVTIfm5ZrTkLJzFuVy9SE23Fdg6adQbpsvwOvAaYYT5V BSWvZA+UgEINiQAroHeAxCmbfOEmh9g6O1A2OjUTaiRwJfrDR77ZjUs2AIJzvculAwrA HBcYiXOVaSfjOI7n4nu9hVBT8lJaqO4F/hL2cp3QsahlHFQ3WbyoM9iE5zUzIw6oGk9R WAxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:subject:importance:from:to :mime-version; bh=8qnZR49QfFeLsK7HKCH+2JlZ15mfT88UXBOxPlAGmek=; b=q8vxUzmRZ7NMqWRnB4VA8jqhT6MalBRx5Pv0y2BYF67jA1rMl31B74rLnX2V67p9+E GxXNPrzBJ68lx2E8j2fJuWm58LWZOIFKkWiwIuVe/AkTRipS5OyAVl7EInw6xY93pXOe jIaxqAih1Eau7sW6pq8kda6BeESdJWiLxbpHrqDe4Bi+C/QC5+z+cYZpFXxkb3eRCWlX yGdZGETW6VPpdKzS7T82DQNOpLNJElBYBsG05Qg2HcN5l2ShWqqm7aMXri/gPevI8wfx rzPB8ZB4HTgRF/CsTYrkZuEOzV0C2TK3w4FXqZ9K6QtlIpraQAiHwJzhrBRSaPHdVgdf U43g== X-Gm-Message-State: APjAAAXnA4C63WnjFtcyllVdiw1mkgiYfkjSolxYc/3ccXXQEGStgyeN xjXsrr6cAIXcj3OTIQxp3u4EnYBj4Ow= X-Google-Smtp-Source: APXvYqwN29LmavBkqjzp5ulEFdJMltT/0/mhLX69uKyd1YsH/C3TJwY9k2sSfmDv015zC7981oQV7g== X-Received: by 2002:a6b:f307:: with SMTP id m7mr7177782ioh.84.1567455657639; Mon, 02 Sep 2019 13:20:57 -0700 (PDT) Received: from ?IPv6:2607:fb90:99bd:4a14:0:15:c60e:6e01? ([2607:fb90:99bd:4a14:0:15:c60e:6e01]) by smtp.gmail.com with ESMTPSA id q17sm2901920ioh.75.2019.09.02.13.20.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Sep 2019 13:20:57 -0700 (PDT) Message-ID: <5d6d79a9.1c69fb81.d0309.d0cc@mx.google.com> Date: Mon, 02 Sep 2019 15:20:54 -0500 Importance: normal From: nessandorae To: oauth@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_94151092334180" Archived-At: Subject: [OAUTH-WG] =?iso-8859-1?q?=2E_=3Fric_Vyncke=27s_No_Objection_on?= =?iso-8859-1?q?=A0=A0=A0=A0=A0_draft-ietf-oauth-resource-indicators-05=3A?= 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, 02 Sep 2019 20:21:02 -0000 ----_com.samsung.android.email_94151092334180 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Z29vZ2xlLmNvbVNlbnQgZnJvbSBteSBNZXRyb1BDUyA0RyBMVEUgQW5kcm9pZCBEZXZpY2UKLS0t LS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206IG9hdXRoLXJlcXVlc3RAaWV0Zi5v cmcgRGF0ZTogOS8yLzE5ICAyOjAwIFBNICAoR01ULTA2OjAwKSBUbzogb2F1dGhAaWV0Zi5vcmcg U3ViamVjdDogT0F1dGggRGlnZXN0LCBWb2wgMTMxLCBJc3N1ZSAyIFNlbmQgT0F1dGggbWFpbGlu ZyBsaXN0IHN1Ym1pc3Npb25zIHRvCW9hdXRoQGlldGYub3JnVG8gc3Vic2NyaWJlIG9yIHVuc3Vi c2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0CWh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGhvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRo IHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG8Jb2F1dGgtcmVxdWVzdEBpZXRmLm9yZ1lvdSBjYW4g cmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdAlvYXV0aC1vd25lckBpZXRmLm9y Z1doZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1v cmUgc3BlY2lmaWN0aGFuICJSZTogQ29udGVudHMgb2YgT0F1dGggZGlnZXN0Li4uIlRvZGF5J3Mg VG9waWNzOsKgwqAgMS4gP3JpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb27CoMKgwqDCoMKgIGRy YWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wNTogKHdpdGggQ09NTUVOVCnCoMKg wqDCoMKgICg/cmljIFZ5bmNrZSB2aWEgRGF0YXRyYWNrZXIpwqDCoCAyLiBSZTrCoCA/cmljIFZ5 bmNrZSdzIE5vIE9iamVjdGlvbiBvbsKgwqDCoMKgwqAgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJj ZS1pbmRpY2F0b3JzLTA1OiAod2l0aCBDT01NRU5UKSAoa2kgZGUpwqDCoCAzLiBGd2Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3LCoMKgwqDCoMKgIGRyYWZ0LXl1c2VmLW9hdXRoLW5lc3Rl ZC1qd3QtMDIudHh0IChSaWZhYXQgU2hla2gtWXVzZWYpLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLU1lc3NhZ2U6IDFE YXRlOiBNb24sIDAyIFNlcCAyMDE5IDAyOjQwOjMxIC0wNzAwRnJvbTogP3JpYyBWeW5ja2Ugdmlh IERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPlRvOiAiVGhlIElFU0ciIDxpZXNnQGlldGYu b3JnPkNjOiBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnNAaWV0Zi5vcmcsIFJp ZmFhdCBTaGVraC1ZdXNlZgk8cmlmYWF0LmlldGZAZ21haWwuY29tPiwgb2F1dGgtY2hhaXJzQGll dGYub3JnLCByaWZhYXQuaWV0ZkBnbWFpbC5jb20sCW9hdXRoQGlldGYub3JnU3ViamVjdDogW09B VVRILVdHXSA/cmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbglkcmFmdC1pZXRmLW9hdXRoLXJl c291cmNlLWluZGljYXRvcnMtMDU6ICh3aXRoIENPTU1FTlQpTWVzc2FnZS1JRDoJPDE1Njc0MTcy MzE5NS4xMzA0MS4zNTE5OTgyNjA2Mzc0NzYzNDQ3LmlkdHJhY2tlckBpZXRmYS5hbXNsLmNvbT5D b250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InV0Zi04Ij9yaWMgVnluY2tlIGhhcyBl bnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcmRyYWZ0LWlldGYtb2F1dGgt cmVzb3VyY2UtaW5kaWNhdG9ycy0wNTogTm8gT2JqZWN0aW9uV2hlbiByZXNwb25kaW5nLCBwbGVh c2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsZW1haWwgYWRk cmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0 IHRoaXNpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLilQbGVhc2UgcmVmZXIgdG8gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sZm9y IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9u cy5UaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJl IGZvdW5kIGhlcmU6aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1v YXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1DT01NRU5UOi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS1UaGFuayB5b3UgZm9yIHRoZSBoYXJkIHdvcmsgcHV0IGludG8gdGhpcyBlYXN5IHRvIHJlYWQg ZG9jdW1lbnQuUmVnYXJkcywtP3JpYz09IENPTU1FTlRTID09LS0gU2VjdGlvbiAxIC0tImhhcyB1 bmNvdmVyZWQgYSBuZWVkLCBpbiBzb21lIGNpcmN1bXN0YW5jZXMiIChhbmQgc2ltaWxhciBzZW50 ZW5jZXMgaW4gc2VjdGlvbjEpLCBpdCBpcyByYXRoZXIgdmFndWUgZm9yIGEgc3RhbmRhcmQgdHJh Y2sgZG9jdW1lbnQuLi4gUGxlYXNlIGFkZCBzb21lIGZhY3RzYW5kIGRhdGEsIHRoaXMgY291bGQg YmUgYSBjb21wYW5pb24gZG9jdW1lbnQgYWJvdXQgcmVxdWlyZW1lbnRzL3VzZSBjYXNlcy4tLSBT ZWN0aW9uIDIgLS1JdCBpcyByYXRoZXIgYSBxdWVzdGlvbiBvZiBtaW5lLCB3aHkgZG9lcyB0aGUg cmVzb3VyY2UgbmVlZCB0byBiZSBhIFVSSSAod2hpY2h1c3VhbGx5IGJlYXJzIHNvbWUgdmlzaWJs ZSBzZW1hbnRpY3MpIHJhdGhlciB0aGFuIGFuIG9wYXF1ZSBzdHJpbmcga25vd24gb25seWJ5IHRo ZSByZXNvdXJjZSBvd25lci9zZXJ2ZXIgPyBUaGlzIGlzIHNpbWlsYXIgdG8gTWlyamEncyBjb21t ZW50IGFib3V0IHByaXZhY3kuLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tTWVzc2FnZTog MkRhdGU6IE1vbiwgMiBTZXAgMjAxOSAxMDoyMjo1MyArMDAwMEZyb206IGtpIGRlIDxrYXljb2lu c0BvdXRsb29rLmNvbT5UbzogP3JpYyBWeW5ja2UgPGV2eW5ja2VAY2lzY28uY29tPkNjOiBUaGUg SUVTRyA8aWVzZ0BpZXRmLm9yZz4sCSJkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRv cnNAaWV0Zi5vcmciCTxkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnNAaWV0Zi5v cmc+LCAib2F1dGhAaWV0Zi5vcmciCTxvYXV0aEBpZXRmLm9yZz4sICJvYXV0aC1jaGFpcnNAaWV0 Zi5vcmciIDxvYXV0aC1jaGFpcnNAaWV0Zi5vcmc+U3ViamVjdDogUmU6IFtPQVVUSC1XR13CoCA/ cmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbglkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWlu ZGljYXRvcnMtMDU6ICh3aXRoIENPTU1FTlQpTWVzc2FnZS1JRDoJPENIMlBSMTVNQjM2MDY2MDNE NzUwQjAwMDFERURFQUUxNkQ3QkUwQENIMlBSMTVNQjM2MDYubmFtcHJkMTUucHJvZC5vdXRsb29r LmNvbT4JQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1dGYtOCJPbiBNb24sIFNl cCAyLCAyMDE5IGF0IDU6NDAgQU0gP3JpYyBWeW5ja2UgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5 QGlldGYub3JnPiB3cm90ZTo/cmljIFZ5bmNrZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJh bGxvdCBwb3NpdGlvbiBmb3JkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDU6 IE5vIE9iamVjdGlvbldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGlu ZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUg VG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzaW50cm9kdWN0b3J5IHBhcmFn cmFwaCwgaG93ZXZlci4pUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vbmFtMDMuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRmll c2clMkZzdGF0ZW1lbnQlMkZkaXNjdXNzLWNyaXRlcmlhLmh0bWwmYW1wO2RhdGE9MDIlN0MwMSU3 QyU3Q2RhMDUwOGJjN2I5YTQ1OThhZTZmMDhkNzJmODlhMTA0JTdDODRkZjllN2ZlOWY2NDBhZmI0 MzVhYWFhYWFhYWFhYWElN0MxJTdDMCU3QzYzNzAzMDE0MDQ2MTkxNTk0OCZhbXA7c2RhdGE9c0s1 Nmo5YndWeUxsTnVwZ0VkeEV4ZGFCVFRPTG5JMjglMkZZU1RKVmdMcEc0JTNEJmFtcDtyZXNlcnZl ZD0wZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBv c2l0aW9ucy5UaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywg Y2FuIGJlIGZvdW5kIGhlcmU6aHR0cHM6Ly9uYW0wMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZk cmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMlMkYmYW1wO2RhdGE9MDIlN0MwMSU3 QyU3Q2RhMDUwOGJjN2I5YTQ1OThhZTZmMDhkNzJmODlhMTA0JTdDODRkZjllN2ZlOWY2NDBhZmI0 MzVhYWFhYWFhYWFhYWElN0MxJTdDMCU3QzYzNzAzMDE0MDQ2MTkyNTk1OSZhbXA7c2RhdGE9eUd6 MGN5UmI3RmdZeEh0SE9NTFRTY1plSXBUU1FHYjdwdTZOT2hRRjJJYyUzRCZhbXA7cmVzZXJ2ZWQ9 MC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS1DT01NRU5UOi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1UaGFuayB5b3UgZm9yIHRoZSBoYXJk IHdvcmsgcHV0IGludG8gdGhpcyBlYXN5IHRvIHJlYWQgZG9jdW1lbnQuUmVnYXJkcywtP3JpYz09 IENPTU1FTlRTID09LS0gU2VjdGlvbiAxIC0tImhhcyB1bmNvdmVyZWQgYSBuZWVkLCBpbiBzb21l IGNpcmN1bXN0YW5jZXMiIChhbmQgc2ltaWxhciBzZW50ZW5jZXMgaW4gc2VjdGlvbjEpLCBpdCBp cyByYXRoZXIgdmFndWUgZm9yIGEgc3RhbmRhcmQgdHJhY2sgZG9jdW1lbnQuLi4gUGxlYXNlIGFk ZCBzb21lIGZhY3RzYW5kIGRhdGEsIHRoaXMgY291bGQgYmUgYSBjb21wYW5pb24gZG9jdW1lbnQg YWJvdXQgcmVxdWlyZW1lbnRzL3VzZSBjYXNlcy4tLSBTZWN0aW9uIDIgLS1JdCBpcyByYXRoZXIg YSBxdWVzdGlvbiBvZiBtaW5lLCB3aHkgZG9lcyB0aGUgcmVzb3VyY2UgbmVlZCB0byBiZSBhIFVS SSAod2hpY2h1c3VhbGx5IGJlYXJzIHNvbWUgdmlzaWJsZSBzZW1hbnRpY3MpIHJhdGhlciB0aGFu IGFuIG9wYXF1ZSBzdHJpbmcga25vd24gb25seWJ5IHRoZSByZXNvdXJjZSBvd25lci9zZXJ2ZXIg PyBUaGlzIGlzIHNpbWlsYXIgdG8gTWlyamEncyBjb21tZW50IGFib3V0IHByaXZhY3kuX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19PQXV0aCBtYWlsaW5nIGxp c3RPQXV0aEBpZXRmLm9yZ2h0dHBzOi8vbmFtMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5m byUyRm9hdXRoJmFtcDtkYXRhPTAyJTdDMDElN0MlN0NkYTA1MDhiYzdiOWE0NTk4YWU2ZjA4ZDcy Zjg5YTEwNCU3Qzg0ZGY5ZTdmZTlmNjQwYWZiNDM1YWFhYWFhYWFhYWFhJTdDMSU3QzAlN0M2Mzcw MzAxNDA0NjE5MjU5NTkmYW1wO3NkYXRhPVFmY2JEcXFKOVo2ZyUyQkxxOGROQUFpelFjTGZwTHhS NTQzR0JhcVp3aUFzdyUzRCZhbXA7cmVzZXJ2ZWQ9MC0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAt LS0tLS0tLS0tLS0tLUFuIEhUTUwgYXR0YWNobWVudCB3YXMgc2NydWJiZWQuLi5VUkw6IDxodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL29hdXRoL2F0dGFjaG1lbnRzLzIw MTkwOTAyLzNmMWEyOThhL2F0dGFjaG1lbnQuaHRtbD4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS1NZXNzYWdlOiAzRGF0ZTogTW9uLCAyIFNlcCAyMDE5IDExOjAzOjIwIC0wNDAwRnJvbTog UmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb20+VG86IG9hdXRoIDxvYXV0 aEBpZXRmLm9yZz5TdWJqZWN0OiBbT0FVVEgtV0ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvcglkcmFmdC15dXNlZi1vYXV0aC1uZXN0ZWQtand0LTAyLnR4dE1lc3NhZ2UtSUQ6CTxD QUdMNmVwTEdZM2RrRHhnX3g5bTBPSkMwNUF6dTh5d1MwZnJEYWhqc3NYU25Bb09kUUFAbWFpbC5n bWFpbC5jb20+Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1dGYtOCJBbGwsSSBo YXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBOZXN0ZWQgSldUIGRyYWZ0IGFuZCBh ZGRlZCB0aGUgU1RJUnVzZSBjYXNlLlBsZWFzZSwgdGFrZSBhIGxvb2sgYW5kIGxldCBtZSBrbm93 IGlmIHlvdSBoYXZlIGFueSBjb21tZW50cy5SZWdhcmRzLCBSaWZhYXQtLS0tLS0tLS0tIEZvcndh cmRlZCBtZXNzYWdlIC0tLS0tLS0tLUZyb206IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+RGF0 ZTogTW9uLCBTZXAgMiwgMjAxOSBhdCAxMDo1OSBBTVN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQteXVzZWYtb2F1dGgtbmVzdGVkLWp3dC0wMi50eHRUbzogUmlmYWF0 IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb20+QSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LXl1c2VmLW9hdXRoLW5lc3RlZC1qd3QtMDIudHh0aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBSaWZhYXQgU2hla2gtWXVzZWYgYW5kIHBvc3RlZCB0byB0aGVJRVRGIHJl cG9zaXRvcnkuTmFtZTrCoMKgwqDCoMKgwqDCoMKgwqDCoCBkcmFmdC15dXNlZi1vYXV0aC1uZXN0 ZWQtand0UmV2aXNpb246wqDCoMKgwqDCoMKgIDAyVGl0bGU6wqDCoMKgwqDCoMKgwqDCoMKgIE5l c3RlZCBKU09OIFdlYiBUb2tlbiAoSldUKURvY3VtZW50IGRhdGU6wqAgMjAxOS0wOS0wMkdyb3Vw OsKgwqDCoMKgwqDCoMKgwqDCoCBJbmRpdmlkdWFsIFN1Ym1pc3Npb25QYWdlczrCoMKgwqDCoMKg wqDCoMKgwqAgNVVSTDpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt eXVzZWYtb2F1dGgtbmVzdGVkLWp3dC0wMi50eHRTdGF0dXM6aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQteXVzZWYtb2F1dGgtbmVzdGVkLWp3dC9IdG1saXplZDrCoMKgwqDC oMKgwqAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXl1c2VmLW9hdXRoLW5lc3Rl ZC1qd3QtMDJIdG1saXplZDpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LXl1c2VmLW9hdXRoLW5lc3RlZC1qd3REaWZmOmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC15dXNlZi1vYXV0aC1uZXN0ZWQtand0LTAyQWJzdHJhY3Q6wqDCoCBUaGlz IHNwZWNpZmljYXRpb24gZXh0ZW5kcyB0aGUgc2NvcGUgb2YgdGhlIE5lc3RlZCBKU09OIFdlYiBU b2tlbsKgwqAgKEpXVCkgdG8gYWxsb3cgdGhlIGVuY2xvc2luZyBKV1QgdG8gY29udGFpbiBpdHMg b3duIENsYWltcyBTZXQgaW7CoMKgIGFkZGl0aW9uIHRvIHRoZSBlbmNsb3NlZCBKV1QuUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuVGhlIElFVEYgU2VjcmV0YXJpYXQtLS0tLS0tLS0tLS0t LSBuZXh0IHBhcnQgLS0tLS0tLS0tLS0tLS1BbiBIVE1MIGF0dGFjaG1lbnQgd2FzIHNjcnViYmVk Li4uVVJMOiA8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9vYXV0aC9h dHRhY2htZW50cy8yMDE5MDkwMi8xYzcwYTZkZi9hdHRhY2htZW50Lmh0bWw+LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tU3ViamVjdDogRGlnZXN0IEZvb3Rlcl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fT0F1dGggbWFpbGluZyBsaXN0T0F1dGhAaWV0 Zi5vcmdodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tRW5kIG9mIE9BdXRoIERpZ2VzdCwgVm9sIDEzMSwgSXNzdWUg MioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio= ----_com.samsung.android.email_94151092334180 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2Pjxicj48L2Rpdj48ZGl2Pmdv b2dsZS5jb208L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGlkPSJjb21w b3Nlcl9zaWduYXR1cmUiPjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo4NSU7Y29sb3I6IzU3NTc1NyIg ZGlyPSJhdXRvIj5TZW50IGZyb20gbXkgTWV0cm9QQ1MgNEcgTFRFIEFuZHJvaWQgRGV2aWNlPC9k aXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEwMCU7Y29sb3I6 IzAwMDAwMCI+PCEtLSBvcmlnaW5hbE1lc3NhZ2UgLS0+PGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBt ZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBvYXV0aC1yZXF1ZXN0QGlldGYub3JnIDwv ZGl2PjxkaXY+RGF0ZTogOS8yLzE5ICAyOjAwIFBNICAoR01ULTA2OjAwKSA8L2Rpdj48ZGl2PlRv OiBvYXV0aEBpZXRmLm9yZyA8L2Rpdj48ZGl2PlN1YmplY3Q6IE9BdXRoIERpZ2VzdCwgVm9sIDEz MSwgSXNzdWUgMiA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj5TZW5kIE9BdXRoIG1haWxpbmcg bGlzdCBzdWJtaXNzaW9ucyB0bzxicj4Jb2F1dGhAaWV0Zi5vcmc8YnI+PGJyPlRvIHN1YnNjcmli ZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdDxicj4JaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj5vciwgdmlhIGVtYWlsLCBz ZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG88YnI+CW9hdXRoLXJl cXVlc3RAaWV0Zi5vcmc8YnI+PGJyPllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0 aGUgbGlzdCBhdDxicj4Jb2F1dGgtb3duZXJAaWV0Zi5vcmc8YnI+PGJyPldoZW4gcmVwbHlpbmcs IHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWM8YnI+ dGhhbiAiUmU6IENvbnRlbnRzIG9mIE9BdXRoIGRpZ2VzdC4uLiI8YnI+PGJyPjxicj5Ub2RheSdz IFRvcGljczo8YnI+PGJyPiZuYnNwOyZuYnNwOyAxLiA/cmljIFZ5bmNrZSdzIE5vIE9iamVjdGlv biBvbjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtaWV0Zi1vYXV0aC1y ZXNvdXJjZS1pbmRpY2F0b3JzLTA1OiAod2l0aCBDT01NRU5UKTxicj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgKD9yaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlcik8YnI+Jm5ic3A7Jm5i c3A7IDIuIFJlOiZuYnNwOyA/cmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbjxicj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0 b3JzLTA1OiAod2l0aCBDT01NRU5UKSAoa2kgZGUpPGJyPiZuYnNwOyZuYnNwOyAzLiBGd2Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3I8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGRyYWZ0LXl1c2VmLW9hdXRoLW5lc3RlZC1qd3QtMDIudHh0IChSaWZhYXQgU2hla2gtWXVz ZWYpPGJyPjxicj48YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj48YnI+TWVzc2FnZTogMTxicj5EYXRlOiBN b24sIDAyIFNlcCAyMDE5IDAyOjQwOjMxIC0wNzAwPGJyPkZyb206ID9yaWMgVnluY2tlIHZpYSBE YXRhdHJhY2tlciAmbHQ7bm9yZXBseUBpZXRmLm9yZyZndDs8YnI+VG86ICJUaGUgSUVTRyIgJmx0 O2llc2dAaWV0Zi5vcmcmZ3Q7PGJyPkNjOiBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGlj YXRvcnNAaWV0Zi5vcmcsIFJpZmFhdCBTaGVraC1ZdXNlZjxicj4JJmx0O3JpZmFhdC5pZXRmQGdt YWlsLmNvbSZndDssIG9hdXRoLWNoYWlyc0BpZXRmLm9yZywgcmlmYWF0LmlldGZAZ21haWwuY29t LDxicj4Jb2F1dGhAaWV0Zi5vcmc8YnI+U3ViamVjdDogW09BVVRILVdHXSA/cmljIFZ5bmNrZSdz IE5vIE9iamVjdGlvbiBvbjxicj4JZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3Jz LTA1OiAod2l0aCBDT01NRU5UKTxicj5NZXNzYWdlLUlEOjxicj4JJmx0OzE1Njc0MTcyMzE5NS4x MzA0MS4zNTE5OTgyNjA2Mzc0NzYzNDQ3LmlkdHJhY2tlckBpZXRmYS5hbXNsLmNvbSZndDs8YnI+ Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1dGYtOCI8YnI+PGJyPj9yaWMgVnlu Y2tlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcjxicj5kcmFm dC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDU6IE5vIE9iamVjdGlvbjxicj48YnI+ V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQg cmVwbHkgdG8gYWxsPGJyPmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIEND IGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzPGJyPmludHJvZHVjdG9yeSBwYXJhZ3JhcGgs IGhvd2V2ZXIuKTxicj48YnI+PGJyPlBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9y Zy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWw8YnI+Zm9yIG1vcmUgaW5mb3Jt YXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48YnI+PGJyPjxi cj5UaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJl IGZvdW5kIGhlcmU6PGJyPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy88YnI+PGJyPjxicj48YnI+LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj5DT01NRU5UOjxicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPjxicj5UaGFuayB5b3UgZm9yIHRoZSBo YXJkIHdvcmsgcHV0IGludG8gdGhpcyBlYXN5IHRvIHJlYWQgZG9jdW1lbnQuPGJyPjxicj5SZWdh cmRzLDxicj48YnI+LT9yaWM8YnI+PGJyPj09IENPTU1FTlRTID09PGJyPjxicj4tLSBTZWN0aW9u IDEgLS08YnI+ImhhcyB1bmNvdmVyZWQgYSBuZWVkLCBpbiBzb21lIGNpcmN1bXN0YW5jZXMiIChh bmQgc2ltaWxhciBzZW50ZW5jZXMgaW4gc2VjdGlvbjxicj4xKSwgaXQgaXMgcmF0aGVyIHZhZ3Vl IGZvciBhIHN0YW5kYXJkIHRyYWNrIGRvY3VtZW50Li4uIFBsZWFzZSBhZGQgc29tZSBmYWN0czxi cj5hbmQgZGF0YSwgdGhpcyBjb3VsZCBiZSBhIGNvbXBhbmlvbiBkb2N1bWVudCBhYm91dCByZXF1 aXJlbWVudHMvdXNlIGNhc2VzLjxicj48YnI+LS0gU2VjdGlvbiAyIC0tPGJyPkl0IGlzIHJhdGhl ciBhIHF1ZXN0aW9uIG9mIG1pbmUsIHdoeSBkb2VzIHRoZSByZXNvdXJjZSBuZWVkIHRvIGJlIGEg VVJJICh3aGljaDxicj51c3VhbGx5IGJlYXJzIHNvbWUgdmlzaWJsZSBzZW1hbnRpY3MpIHJhdGhl ciB0aGFuIGFuIG9wYXF1ZSBzdHJpbmcga25vd24gb25seTxicj5ieSB0aGUgcmVzb3VyY2Ugb3du ZXIvc2VydmVyID8gVGhpcyBpcyBzaW1pbGFyIHRvIE1pcmphJ3MgY29tbWVudCBhYm91dCBwcml2 YWN5Ljxicj48YnI+PGJyPjxicj48YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJy Pjxicj5NZXNzYWdlOiAyPGJyPkRhdGU6IE1vbiwgMiBTZXAgMjAxOSAxMDoyMjo1MyArMDAwMDxi cj5Gcm9tOiBraSBkZSAmbHQ7a2F5Y29pbnNAb3V0bG9vay5jb20mZ3Q7PGJyPlRvOiA/cmljIFZ5 bmNrZSAmbHQ7ZXZ5bmNrZUBjaXNjby5jb20mZ3Q7PGJyPkNjOiBUaGUgSUVTRyAmbHQ7aWVzZ0Bp ZXRmLm9yZyZndDssPGJyPgkiZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzQGll dGYub3JnIjxicj4JJmx0O2RyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9yc0BpZXRm Lm9yZyZndDssICJvYXV0aEBpZXRmLm9yZyI8YnI+CSZsdDtvYXV0aEBpZXRmLm9yZyZndDssICJv YXV0aC1jaGFpcnNAaWV0Zi5vcmciICZsdDtvYXV0aC1jaGFpcnNAaWV0Zi5vcmcmZ3Q7PGJyPlN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddJm5ic3A7ID9yaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9u PGJyPglkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDU6ICh3aXRoIENPTU1F TlQpPGJyPk1lc3NhZ2UtSUQ6PGJyPgkmbHQ7Q0gyUFIxNU1CMzYwNjYwM0Q3NTBCMDAwMURFREVB RTE2RDdCRTBAQ0gyUFIxNU1CMzYwNi5uYW1wcmQxNS5wcm9kLm91dGxvb2suY29tJmd0Ozxicj4J PGJyPkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXRmLTgiPGJyPjxicj48YnI+ PGJyPk9uIE1vbiwgU2VwIDIsIDIwMTkgYXQgNTo0MCBBTSA/cmljIFZ5bmNrZSB2aWEgRGF0YXRy YWNrZXIgJmx0O25vcmVwbHlAaWV0Zi5vcmcmZ3Q7IHdyb3RlOjxicj4/cmljIFZ5bmNrZSBoYXMg ZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3I8YnI+ZHJhZnQtaWV0Zi1v YXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTA1OiBObyBPYmplY3Rpb248YnI+PGJyPldoZW4gcmVz cG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRv IGFsbDxicj5lbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4g KEZlZWwgZnJlZSB0byBjdXQgdGhpczxicj5pbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVy Lik8YnI+PGJyPlBsZWFzZSByZWZlciB0byBodHRwczovL25hbTAzLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZpZXNnJTJG c3RhdGVtZW50JTJGZGlzY3Vzcy1jcml0ZXJpYS5odG1sJmFtcDthbXA7ZGF0YT0wMiU3QzAxJTdD JTdDZGEwNTA4YmM3YjlhNDU5OGFlNmYwOGQ3MmY4OWExMDQlN0M4NGRmOWU3ZmU5ZjY0MGFmYjQz NWFhYWFhYWFhYWFhYSU3QzElN0MwJTdDNjM3MDMwMTQwNDYxOTE1OTQ4JmFtcDthbXA7c2RhdGE9 c0s1Nmo5YndWeUxsTnVwZ0VkeEV4ZGFCVFRPTG5JMjglMkZZU1RKVmdMcEc0JTNEJmFtcDthbXA7 cmVzZXJ2ZWQ9MDxicj5mb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5k IENPTU1FTlQgcG9zaXRpb25zLjxicj48YnI+VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVy IGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxicj5odHRwczovL25hbTAzLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJh Y2tlci5pZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9y cyUyRiZhbXA7YW1wO2RhdGE9MDIlN0MwMSU3QyU3Q2RhMDUwOGJjN2I5YTQ1OThhZTZmMDhkNzJm ODlhMTA0JTdDODRkZjllN2ZlOWY2NDBhZmI0MzVhYWFhYWFhYWFhYWElN0MxJTdDMCU3QzYzNzAz MDE0MDQ2MTkyNTk1OSZhbXA7YW1wO3NkYXRhPXlHejBjeVJiN0ZnWXhIdEhPTUxUU2NaZUlwVFNR R2I3cHU2Tk9oUUYySWMlM0QmYW1wO2FtcDtyZXNlcnZlZD0wPGJyPjxicj4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPkNPTU1FTlQ6PGJyPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+PGJyPlRoYW5rIHlvdSBmb3IgdGhlIGhh cmQgd29yayBwdXQgaW50byB0aGlzIGVhc3kgdG8gcmVhZCBkb2N1bWVudC48YnI+PGJyPlJlZ2Fy ZHMsPGJyPjxicj4tP3JpYzxicj48YnI+PT0gQ09NTUVOVFMgPT08YnI+PGJyPi0tIFNlY3Rpb24g MSAtLTxicj4iaGFzIHVuY292ZXJlZCBhIG5lZWQsIGluIHNvbWUgY2lyY3Vtc3RhbmNlcyIgKGFu ZCBzaW1pbGFyIHNlbnRlbmNlcyBpbiBzZWN0aW9uPGJyPjEpLCBpdCBpcyByYXRoZXIgdmFndWUg Zm9yIGEgc3RhbmRhcmQgdHJhY2sgZG9jdW1lbnQuLi4gUGxlYXNlIGFkZCBzb21lIGZhY3RzPGJy PmFuZCBkYXRhLCB0aGlzIGNvdWxkIGJlIGEgY29tcGFuaW9uIGRvY3VtZW50IGFib3V0IHJlcXVp cmVtZW50cy91c2UgY2FzZXMuPGJyPjxicj4tLSBTZWN0aW9uIDIgLS08YnI+SXQgaXMgcmF0aGVy IGEgcXVlc3Rpb24gb2YgbWluZSwgd2h5IGRvZXMgdGhlIHJlc291cmNlIG5lZWQgdG8gYmUgYSBV UkkgKHdoaWNoPGJyPnVzdWFsbHkgYmVhcnMgc29tZSB2aXNpYmxlIHNlbWFudGljcykgcmF0aGVy IHRoYW4gYW4gb3BhcXVlIHN0cmluZyBrbm93biBvbmx5PGJyPmJ5IHRoZSByZXNvdXJjZSBvd25l ci9zZXJ2ZXIgPyBUaGlzIGlzIHNpbWlsYXIgdG8gTWlyamEncyBjb21tZW50IGFib3V0IHByaXZh Y3kuPGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+T0F1dGhAaWV0Zi5vcmc8YnI+aHR0cHM6Ly9uYW0w My5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3 LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgmYW1wO2FtcDtkYXRhPTAyJTdD MDElN0MlN0NkYTA1MDhiYzdiOWE0NTk4YWU2ZjA4ZDcyZjg5YTEwNCU3Qzg0ZGY5ZTdmZTlmNjQw YWZiNDM1YWFhYWFhYWFhYWFhJTdDMSU3QzAlN0M2MzcwMzAxNDA0NjE5MjU5NTkmYW1wO2FtcDtz ZGF0YT1RZmNiRHFxSjlaNmclMkJMcThkTkFBaXpRY0xmcEx4UjU0M0dCYXFad2lBc3clM0QmYW1w O2FtcDtyZXNlcnZlZD0wPGJyPi0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAtLS0tLS0tLS0tLS0t LTxicj5BbiBIVE1MIGF0dGFjaG1lbnQgd2FzIHNjcnViYmVkLi4uPGJyPlVSTDogJmx0O2h0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93c2Uvb2F1dGgvYXR0YWNobWVudHMvMjAx OTA5MDIvM2YxYTI5OGEvYXR0YWNobWVudC5odG1sJmd0Ozxicj48YnI+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPjxicj5NZXNzYWdlOiAzPGJyPkRhdGU6IE1vbiwgMiBTZXAgMjAx OSAxMTowMzoyMCAtMDQwMDxicj5Gcm9tOiBSaWZhYXQgU2hla2gtWXVzZWYgJmx0O3JpZmFhdC5p ZXRmQGdtYWlsLmNvbSZndDs8YnI+VG86IG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+ U3ViamVjdDogW09BVVRILVdHXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3I8YnI+ CWRyYWZ0LXl1c2VmLW9hdXRoLW5lc3RlZC1qd3QtMDIudHh0PGJyPk1lc3NhZ2UtSUQ6PGJyPgkm bHQ7Q0FHTDZlcExHWTNka0R4Z194OW0wT0pDMDVBenU4eXdTMGZyRGFoanNzWFNuQW9PZFFBQG1h aWwuZ21haWwuY29tJmd0Ozxicj5Db250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InV0 Zi04Ijxicj48YnI+QWxsLDxicj48YnI+SSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9m IHRoZSBOZXN0ZWQgSldUIGRyYWZ0IGFuZCBhZGRlZCB0aGUgU1RJUjxicj51c2UgY2FzZS48YnI+ UGxlYXNlLCB0YWtlIGEgbG9vayBhbmQgbGV0IG1lIGtub3cgaWYgeW91IGhhdmUgYW55IGNvbW1l bnRzLjxicj48YnI+UmVnYXJkcyw8YnI+IFJpZmFhdDxicj48YnI+PGJyPi0tLS0tLS0tLS0gRm9y d2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tPGJyPkZyb206ICZsdDtpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcmZ3Q7PGJyPkRhdGU6IE1vbiwgU2VwIDIsIDIwMTkgYXQgMTA6NTkgQU08YnI+U3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC15dXNlZi1vYXV0aC1uZXN0ZWQt and0LTAyLnR4dDxicj5UbzogUmlmYWF0IFNoZWtoLVl1c2VmICZsdDtyaWZhYXQuaWV0ZkBnbWFp bC5jb20mZ3Q7PGJyPjxicj48YnI+PGJyPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC15dXNl Zi1vYXV0aC1uZXN0ZWQtand0LTAyLnR4dDxicj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFJpZmFhdCBTaGVraC1ZdXNlZiBhbmQgcG9zdGVkIHRvIHRoZTxicj5JRVRGIHJlcG9z aXRvcnkuPGJyPjxicj5OYW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmFmdC15dXNlZi1vYXV0aC1uZXN0ZWQtand0PGJyPlJl dmlzaW9uOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwMjxicj5UaXRsZTom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTmVz dGVkIEpTT04gV2ViIFRva2VuIChKV1QpPGJyPkRvY3VtZW50IGRhdGU6Jm5ic3A7IDIwMTktMDkt MDI8YnI+R3JvdXA6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxicj5QYWdlczombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNTxicj5VUkw6PGJyPmh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC15dXNlZi1vYXV0aC1uZXN0ZWQt and0LTAyLnR4dDxicj5TdGF0dXM6PGJyPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXl1c2VmLW9hdXRoLW5lc3RlZC1qd3QvPGJyPkh0bWxpemVkOiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt eXVzZWYtb2F1dGgtbmVzdGVkLWp3dC0wMjxicj5IdG1saXplZDo8YnI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC15dXNlZi1vYXV0aC1uZXN0ZWQtand0PGJyPkRp ZmY6PGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC15dXNlZi1vYXV0 aC1uZXN0ZWQtand0LTAyPGJyPjxicj5BYnN0cmFjdDo8YnI+Jm5ic3A7Jm5ic3A7IFRoaXMgc3Bl Y2lmaWNhdGlvbiBleHRlbmRzIHRoZSBzY29wZSBvZiB0aGUgTmVzdGVkIEpTT04gV2ViIFRva2Vu PGJyPiZuYnNwOyZuYnNwOyAoSldUKSB0byBhbGxvdyB0aGUgZW5jbG9zaW5nIEpXVCB0byBjb250 YWluIGl0cyBvd24gQ2xhaW1zIFNldCBpbjxicj4mbmJzcDsmbmJzcDsgYWRkaXRpb24gdG8gdGhl IGVuY2xvc2VkIEpXVC48YnI+PGJyPjxicj48YnI+PGJyPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+ dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy48YnI+PGJyPlRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPi0tLS0tLS0tLS0tLS0t IG5leHQgcGFydCAtLS0tLS0tLS0tLS0tLTxicj5BbiBIVE1MIGF0dGFjaG1lbnQgd2FzIHNjcnVi YmVkLi4uPGJyPlVSTDogJmx0O2h0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93 c2Uvb2F1dGgvYXR0YWNobWVudHMvMjAxOTA5MDIvMWM3MGE2ZGYvYXR0YWNobWVudC5odG1sJmd0 Ozxicj48YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPjxicj5TdWJqZWN0OiBE aWdlc3QgRm9vdGVyPGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+T0F1dGhAaWV0Zi5vcmc8YnI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj48YnI+PGJyPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj48YnI+RW5kIG9mIE9BdXRoIERpZ2VzdCwgVm9s IDEzMSwgSXNzdWUgMjxicj4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJy PjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_94151092334180-- From nobody Mon Sep 2 15:44:29 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 751C912007C; Mon, 2 Sep 2019 15:44:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwt-introspection-response@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156746426740.13074.1850379334333790613.idtracker@ietfa.amsl.com> Date: Mon, 02 Sep 2019 15:44:27 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 22:44:28 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Per the ongoing discussion on the WG list, it's unclear that we can retain the behaviors we describe and still comply with the requirements of RFC 7519 requirements for being a JWT (e.g., regarding "jti", "iat", etc.). That is, in the present formulation, there are two "token"s involved -- the input that is being introspected, and the "token" that is the introspection response. We are claiming that certain fields are describing the input token, when they are defined to be statements about the current (response) token. Relaxing our statements to say that we merely use JWS as opposed to JWT may be a workaround, though I have thought about it hard enough to have an opinion on whether it is the best workaround. I also think we need more clarity about the use of dynamic client registration by a resource server as outlined in Section 4 (where it's mentioned as "with a resource server posing as the client", without reference to RFC 7591. As far as I can tell this document/section is introducing this use of dynamic client registration by an RS for the first time, so we cannot easily just refer to some other document. Specifically, are there any fields that MUST NOT be supplied? Is a human-readable client_name useful? How does the supplied client_uri need to relate to any existing AS representation of a resource in audience, scope, etc. (e.g., for the "resource" request parameter from draft-ietf-oauth-resource-indicators)? Is this usage considered to be a "new use of JWTs"? If so, it seems that we should follow the recommendation of draft-ietf-oauth-jwt-bcp and use explicit typing. I think there are some missing links in the document between a RS registring client policy and the resulting AS enforcement of encryption of introspection reponses. I think the intent is roughly that the policy will be applied based on the audience of the token being presented for introspection (as opposed to the identity of the RS-as-client making the introspection request), but we don't seem to explicitly say that. Also, we'd need to say something about the interaction of multiple RSs' policy when a given token has multiple valid audiences. There is a very brief discussion in Section 6.5, but it seems to be more of a description of what is possible than mandating particular forms of enforcement. I think we should discuss whether we want some statement from the OpenID Foundation or related bodies before we register claims that point to their documents with the IESG listed as change controller. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- idnits notes that RFC 5646 is mentioned but not present in the references section. Section 1 We probably need to move the 7519 reference up here to where JWT is first used. OAuth 2.0 Token Introspection [RFC7662] specifies a method for a protected resource to query an OAuth 2.0 authorization server to determine the state of an access token and obtain data associated with the access token. This allows deployments to implement identifier-based access tokens in an interoperable way. Does "identifier-based access tokens" mean "tokens that are opaque keys to a (central) database lookup" or "access tokens that convey user identity information" (or something else)? We may want to tweak the wording. Section 3 Can we double-check the base64 form of the response in this example? I am seeing output that backslash-escapes the '/' characters in URLs, which I did not think was needed in this context. I also see an "extension_field" claim in the base64 but not the decoded form of the example, and "given_name"/"family_name"/"birthdate" in the decoded example vs. "username" in the base64 version. Note: If the resource server policy requires a signed and encrypted response and the authorization server receives an unauthenticated request containing an Accept header with content type other than "application/jwt", it MUST refuse to serve the request and return an HTTP status code 400. This is done to prevent downgrading attacks to obtain token data intended for release to legitimate recipients only (see Section 6.2). I'd suggest a forward-reference to section 4 for how the AS will know the RS's policy. Although, given that "unauthenticated request" is included in the preconditions, perhaps we do not need the conditional on "resource server policy" at all? Section 4 The authorization server determines what algorithm to employ to secure the JWT for a particular introspection response. This decision can be based on registered metadata parameters for the resource server, supplied via dynamic client registration with the resource server posing as the client, as defined by this draft. nit: I suggest s/posing as the/acting as a/, and s/by this draft/below/, since it's right here in this section. introspection_encrypted_response_alg OPTIONAL. JWE [RFC7516] algorithm ("alg" value) as defined in JWA [RFC7518] for encrypting introspection responses. If this is specified, the response will be encrypted using JWE and the configured algorithm. The default, if omitted, is that no encryption is This text is slightly confusing with respect to the interaction between the introspection_encrypted_response_alg "alg" value and the introspection_encrypted_response_enc "enc" value. My understanding is that the "enc" is a symmetric bulk encryption scheme that directly protects the payload, whereas the "alg" is a key-wrap or key-agreement mechanism used to establish the key used as input for the "enc" method. So, while "algorithm ("alg value") for encrypting introspection responses" and "the response will be encrypted using the confugred ["algo"] algorithm" are technically true, they're also a bit misleading, since this is not what encrypts the "bulk" of the response. Using the term from RFC 7158, "key management algorithm", would probably alleviate this confusion. Resource servers may register their public encryption keys using the "jwks_uri" or "jwks" metadata parameters. Should we cite 7591 for these (or, really, the whole section)? We don't currently mention it until the IANA considerations. Section 5 Is it worth a note that resource servers will fetch these metadata and use them as input to their dynamic registrations in the previous section (i.e., picking from the list of supported algorithms)? introspection_encryption_alg_values_supported OPTIONAL. JSON array containing a list of the JWE [RFC7516] encryption algorithms ("alg" values) as defined in JWA [RFC7518] supported by the introspection endpoint to encrypt the response. Similarly to the above, some refined text about "key management algorithm" used to encrypt the response, would probably be helpful. Section 6 There seem to be notable privacy considerations about quite a few of the claims registered in Section 8.3. Section 6.1 I'm surprised to not see discussion of explicit typing (and, IIUC, how it's not a reliable mitigation) here. JWT introspection responses and OpenID Connect ID Tokens are syntactically similar. An attacker could therefore attempt to impersonate an end-user at a OpenID Connect relying party by passing the JWT as an ID token. nit: "response JWT" or "JWT response" Such an attack can be prevented like any other token substitution attack. The authorization server MUST include the claims "iss" and "aud" in each JWT introspection response, with the "iss" value set to the authorization server's issuer URL and the "aud" value set to the resource server's identifier. [...] Related to the Discuss point, how does this relate to the dynamic client registration parameters? [OpenID.Core]. Relying parties SHOULD also use and check the "nonce" parameter and claim to prevent token and code replay. Is this SHOULD just referring to the behavior already described in OpenID.Core (and only applicable to OIDC implementations as opposed to JWT-instrospection consumers)? If so, maybe descriptive language is more appropriate, like "Relying parties are also expected to use and check [...]". Resource servers utilizing JWTs to represent self-contained access tokens could be susceptible to replay attacks. Resource servers should therefore apply proper counter measures against replay as described in [I-D.ietf-oauth-security-topics], section 2.2. I'm not sure what part of this is specific to the introspection case. Is it supposed to be tied to the risk that JWT-instrospection produces a new route for the generation of JWT objects that could be confused for self-contained access tokens? nit: "countermeasures" is valid as a single word. nit: it looks like it's section 3.2, now. Section 6.2 Please cite RFC 7525 as BCP 195 as well as RFC 7525 (e.g., "per BCP 195 [RFC7525]"). To prevent introspection of leaked tokens and to present an additional security layer against token guessing attacks the authorization server may require all requests to the token introspection endpoint to be authenticated. As an alternative or as an addition to the authentication, the intended recipients may be set up for encrypted responses. Do we want to make either of these "may"s into normative recommendations (or make a recommendation for prevention of introspection data leakage even in the face of token leakage, which can be satisfied by either mechanism)? Also, we could say more about how configuring encryption for intended recipients protects against unencrypted replies to unintended recipients... In the latter case, confidentiality is ensured by the fact that only the legitimate recipient is able to decrypt the response. An attacker could try to circumvent this measure by requesting a plain JSON response, using an Accept header with the content type set to, for example, "application/json" instead of "application/jwt". To prevent this attack the authorization server MUST NOT serve requests with content type other than "application/jwt" if the resource server is set up to receive encrypted responses (see also Section 3). ...such as by saying that the introspection response will only be made available to RSes that are intended recipients of (in the audience of?) the access token being introspected. Section 6.3 Authorization servers with a policy that requires token data to be kept confidential from OAuth clients must require all requests to the token introspection endpoint to be authenticated. As an alternative or as an addition to the authentication, the intended recipients may be set up for encrypted responses. [this also seems to be assuming a link not stated between RS policy and AS enforcement, but it seems unlikely that a fix would need to touch this text] Section 8.1.1 nit: using nested lists might make this more readable. o Client Metadata Description: String value specifying the desired introspection response encryption algorithm (alg value). [same bit about "key management algorithm"] Section 8.2.1 o Metadata Description: JSON array containing a list of algorithms supported by the authorization server for introspection response encryption (alg value). [and here] Section 8.3 I think we should make some mention earlier in the document (Introduction?) that we also register some common claim values that are in use in the wild (or whatever text you feel is appropriate to describe the claims in question). The nested lists would be great here as well. Is there any expectation that some combination of "given_name", "middle_name", and "family_name" will produce identical content to the full "name" claim? o Name: "preferred_username" o Description: Shorthand name by which the End-User wishes to be referred to at the RP, such as janedoe or j.doe. This value MAY be any valid JSON string including special characters such as @, /, or whitespace. It seems like there may be some security considerations about sanitziing this field before using it in an application's logic. o Name: "profile" o Description:URL of the End-User's profile page. The contents of this Web page SHOULD be about the End-User. It's slightly surpising to see this claimed for the end-user's profile when it might equally apply to a protocol profile or variant in use. But I assume this is already deployed, so there's no real point in objecting to its registration... o Name: "birthdate" o Description:Time the End-User's information was last updated. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. This seems potentially confusable with the user's day/year of birth. (Also, are leap seconds excluded?) o Name: "zoneinfo" o Description: String from zoneinfo [zoneinfo] time zone database representing the End-User's time zone. For example, Europe/Paris or America/Los_Angeles. We seem to be missing the actual reference entry for [zoneinfo]. From nobody Tue Sep 3 03:38:25 2019 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 1EAB0120122 for ; Tue, 3 Sep 2019 03:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 SAz_8hBgbuPO for ; Tue, 3 Sep 2019 03:38:19 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 732DD12022A for ; Tue, 3 Sep 2019 03:38:18 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id p12so34765765iog.5 for ; Tue, 03 Sep 2019 03:38:18 -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; bh=T6rVWhuGHhZFoPJQXiQCtWwmSqFQEgjyGtv+1i3qFsQ=; b=JVhaMXZp7K4Qq6JCEsYAYtdnJQahBY2YbDI0aMA8bXMp12/fJpdNPtyYzemZiLyX3M ghpqFnIIbVHOrPg58VMOcTS9waEPm+t3wcsdG5rQacLOjxoyQTPg4dOf0JoEG6Fg3cFZ pTmcpFZaEZ42DICHYNdl0cDT+VEo0UbBd0FL8z41KqmrqBnNkOYdpgw7/PqLF9ssNrb9 O3409y/bIuH2NRD8pyZaVj61DhVzHfV4JhCqfSwUENscU/r/RIqQCp6QCyfpkjEebg26 5YqCDBIN9ZkQIsuOFLI+TTaLkiN8cvtxJyC+PB71NnD+Btluh5+dBeJE9TqAffYHg3VW ic8Q== 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; bh=T6rVWhuGHhZFoPJQXiQCtWwmSqFQEgjyGtv+1i3qFsQ=; b=QzPHR76rsr23He/JyZ4JpoS78XgJ9hKfcLA0Ymi83dGVi4Kid1Che0PGD49xGqbiZt K+KLyu1i+Ld0m71WcduQESCM2MBuApOPUHGLLG9M33RUTlslP+FvXcJyh7kAhxru9wqz 5NlSH5JFQoppXT8kavet2Ctvl1ZG1KRjDPNBKpYD6bCVs/yn6y6ZgRKNn+wTwevooxPW hm6rzuHmmNqSjGdCARctoU052owUuLpj0TY7rScWC4LGEkwT17CO4A6Ot9aAfr+Fx1Ev P4gn3KPHE/uRzMUfui8kUzAuK+bRigW9+Gf6TBXlqsdkpg8Zv9S2OWTtGnDylTMBSLWi VQWQ== X-Gm-Message-State: APjAAAWnEuFPSk7hwMrDvxyyp2AgAylCsvgjEhqGLIR0Ty1uBWb5MsDM ocq4bIV16ejBs4yAMWho5gtKtRxJ+A7MAsOk3n5y4nS9 X-Google-Smtp-Source: APXvYqxyeMPYNNne07DxAMjje3Ifi4kPXYujKiueOJPxJUbX+F20rdWQoqCXZf0fbWMcL89uXJYCPRJu1MZTG3R2+9M= X-Received: by 2002:a5e:de0a:: with SMTP id e10mr21742399iok.46.1567507097095; Tue, 03 Sep 2019 03:38:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vanessa Andor Date: Tue, 3 Sep 2019 05:38:03 -0500 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000b495600591a3afa3" Archived-At: Subject: [OAUTH-WG] Help 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: Tue, 03 Sep 2019 10:38:23 -0000 --000000000000b495600591a3afa3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 2, 2019, 5:45 PM wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. . ?ric Vyncke's No Objection on????? > draft-ietf-oauth-resource-indicators-05: (nessandorae) > 2. Benjamin Kaduk's Discuss on > draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and > COMMENT) (Benjamin Kaduk via Datatracker) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 02 Sep 2019 15:20:54 -0500 > From: nessandorae > To: oauth@ietf.org > Subject: [OAUTH-WG] . ?ric Vyncke's No Objection on????? > draft-ietf-oauth-resource-indicators-05: > Message-ID: <5d6d79a9.1c69fb81.d0309.d0cc@mx.google.com> > Content-Type: text/plain; charset=3D"utf-8" > > google.comSent from my MetroPCS 4G LTE Android Device > -------- Original message --------From: oauth-request@ietf.org Date: > 9/2/19 2:00 PM (GMT-06:00) To: oauth@ietf.org Subject: OAuth Digest, > Vol 131, Issue 2 Send OAuth mailing list submissions to oauth@ietf.or= gTo > subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauthor, via email, send a message > with subject or body 'help' to oauth-request@ietf.orgYou can reach the > person managing the list at oauth-owner@ietf.orgWhen replying, please > edit your Subject line so it is more specificthan "Re: Contents of OAuth > digest..."Today's Topics:?? 1. ?ric Vyncke's No Objection on????? > draft-ietf-oauth-resource-indicators-05: (with COMMENT)????? (?ric Vyncke > via Datatracker)?? 2. Re:? ?ric Vyncke's No Objection on????? > draft-ietf-oauth-resource-indicators-05: (with COMMENT) (ki de)?? 3. Fwd: > New Version Notification for????? draft-yusef-oauth-nested-jwt-02.txt > (Rifaat > Shekh-Yusef)-------------------------------------------------------------= ---------Message > : 1Date: Mon, 02 Sep 2019 02:40:31 -0700From: ?ric Vyncke via Datatracke= r > To: "The IESG" Cc: > draft-ietf-oauth-resource-indicators@ietf.org, Rifaat Shekh-Yusef = < > rifaat.ietf@gmail.com>, oauth-chairs@ietf.org, rifaat.ietf@gmail.com, > oauth@ietf.orgSubject: [OAUTH-WG] ?ric Vyncke's No Objection on > draft-ietf-oauth-resource-indicators-05: (with COMMENT)Message-ID: < > 156741723195.13041.3519982606374763447.idtracker@ietfa.amsl.com>Content-T= ype: > text/plain; charset=3D"utf-8"?ric Vyncke has entered the following ballot > position fordraft-ietf-oauth-resource-indicators-05: No ObjectionWhen > responding, please keep the subject line intact and reply to allemail > addresses included in the To and CC lines. (Feel free to cut > thisintroductory paragraph, however.)Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more > information about IESG DISCUSS and COMMENT positions.The document, along > with other ballot positions, can be found here:https://data > > tracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/---------------= -------------------------------------------------------COMMENT:------------= ----------------------------------------------------------Thank > you for the hard work put into this easy to read document.Regards,-?ric= =3D=3D > COMMENTS =3D=3D-- Section 1 --"has uncovered a need, in some circumstance= s" > (and similar sentences in section1), it is rather vague for a standard > track document... Please add some factsand data, this could be a companio= n > document about requirements/use cases.-- Section 2 --It is rather a > question of mine, why does the resource need to be a URI (whichusually > bears some visible semantics) rather than an opaque string known onlyby t= he > resource owner/server ? This is similar to Mirja's comment about > privacy.------------------------------Message: 2Date: Mon, 2 Sep 2019 > 10:22:53 +0000From: ki de To: ?ric Vyncke < > evyncke@cisco.com>Cc: The IESG , > "draft-ietf-oauth-resource-ind > icators@ietf.org" , = " > oauth@ietf.org" , "oauth-chairs@ietf.org" < > oauth-chairs@ietf.org>Subject: Re: [OAUTH-WG]? ?ric Vyncke's No Objection > on draft-ietf-oauth-resource-indicators-05: (with COMMENT)Message-ID: = < > CH2PR15MB3606603D750B0001DEDEAE16D7BE0@CH2PR15MB3606.namprd15.prod.outloo= k.com> > Content-Type: text/plain; charset=3D"utf-8"On Mon, Sep 2, 2019 at 5= :40 > AM ?ric Vyncke via Datatracker wrote:?ric Vyncke has > entered the following ballot position > fordraft-ietf-oauth-resource-indicators-05: No ObjectionWhen responding, > please keep the subject line intact and reply to allemail addresses > included in the To and CC lines. (Feel free to cut thisintroductory > paragraph, however.)Please refer to > https://nam03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=3D02%7C01%7C%7C= da0508bc7b9a4598ae6f08d72f89a104%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0= %7 > C637030140461915948&sdata=3DsK56j9bwVyLlNupgEdxExdaBTTOLnI28%2FYSTJV= gLpG4%3D&reserved=3D0for > more information about IESG DISCUSS and COMMENT positions.The document, > along with other ballot positions, can be found here: > https://nam03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-resource-indicators%2F&data=3D= 02%7C01%7C%7Cda0508bc7b9a4598ae6f08d72f89a104%7C84df9e7fe9f640afb435aaaaaaa= aaaaa%7C1%7C0%7C637030140461925959&sdata=3DyGz0cyRb7FgYxHtHOMLTScZeIpTS= QGb7pu6NOhQF2Ic%3D&reserved=3D0----------------------------------------= ------------------------------COMMENT:-------------------------------------= ---------------------------------Thank > you for the hard work put into this easy to read document.Regards,-?ric= =3D=3D > COMMENTS =3D=3D-- Section 1 --"has uncovered a need, in some circumstance= s" > (and similar sentences in section1), it is rather vague for a standard > track document... Please add some factsand data, this could be a companio= n > docu > ment about requirements/use cases.-- Section 2 --It is rather a question > of mine, why does the resource need to be a URI (whichusually bears some > visible semantics) rather than an opaque string known onlyby the resource > owner/server ? This is similar to Mirja's comment about > privacy._______________________________________________OAuth mailing > listOAuth@ietf.orghttps:// > nam03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%= 2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7C%7Cda0508bc7b9a4598ae6f08= d72f89a104%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637030140461925959&= amp;sdata=3DQfcbDqqJ9Z6g%2BLq8dNAAizQcLfpLxR543GBaqZwiAsw%3D&reserved= =3D0-------------- > next part --------------An HTML attachment was scrubbed...URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190902/3f1a2= 98a/attachment.html>------------------------------Message: > 3Date: Mon, 2 Sep 2019 11:03:20 -0400From: Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com>To: oauth Subject: [OA > UTH-WG] Fwd: New Version Notification for > draft-yusef-oauth-nested-jwt-02.txtMessage-ID: < > CAGL6epLGY3dkDxg_x9m0OJC05Azu8ywS0frDahjssXSnAoOdQA@mail.gmail.com>Conten= t-Type: > text/plain; charset=3D"utf-8"All,I have submitted a new version of the Ne= sted > JWT draft and added the STIRuse case.Please, take a look and let me know = if > you have any comments.Regards, Rifaat---------- Forwarded message > ---------From: Date: Mon, Sep 2, 2019 at 10:59 > AMSubject: New Version Notification for > draft-yusef-oauth-nested-jwt-02.txtTo: Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com>A new version of I-D, > draft-yusef-oauth-nested-jwt-02.txthas been successfully submitted by > Rifaat Shekh-Yusef and posted to theIETF repository.Name:?????????? > draft-yusef-oauth-nested-jwtRevision:?????? 02Title:????????? Nested JSON > Web Token (JWT)Document date:? 2019-09-02Group:????????? Individual > SubmissionPages:????????? 5URL: > https://www.ietf.org/internet-drafts/draft-yusef-oauth-nested-jwt-02.txtS= tatus:ht > tps://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/Htmlized:???= ??? > > https://tools.ietf.org/html/draft-yusef-oauth-nested-jwt-02Htmlized:https= ://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwtDiff:https://w= ww.ietf.org/rfcdiff?url2=3Ddraft-yusef-oauth-nested-jwt-02Abstract:?? > This specification extends the scope of the Nested JSON Web Token?? (JWT) > to allow the enclosing JWT to contain its own Claims Set in?? addition to > the enclosed JWT.Please note that it may take a couple of minutes from th= e > time of submissionuntil the htmlized version and diff are available at > tools.ietf.org.The IETF Secretariat-------------- next part > --------------An HTML attachment was scrubbed...URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190902/1c70a= 6df/attachment.html>------------------------------Subject: > Digest Footer_______________________________________________OAuth mailing > listOAuth@ietf.orghttps:// > www.ietf.org/mailman/listinfo/oauth------------------------------ > End of OAuth Digest, Vol 131, Issue 2***********************************= ** > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190902/91be4= 7b2/attachment.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 02 Sep 2019 15:44:27 -0700 > From: Benjamin Kaduk via Datatracker > To: "The IESG" > Cc: draft-ietf-oauth-jwt-introspection-response@ietf.org, Rifaat > Shekh-Yusef , oauth-chairs@ietf.org, > rifaat.ietf@gmail.com, oauth@ietf.org > Subject: [OAUTH-WG] Benjamin Kaduk's Discuss on > draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and > COMMENT) > Message-ID: > <156746426740.13074.1850379334333790613.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset=3D"utf-8" > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-oauth-jwt-introspection-response-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respo= nse/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Per the ongoing discussion on the WG list, it's unclear that we can > retain the behaviors we describe and still comply with the requirements > of RFC 7519 requirements for being a JWT (e.g., regarding "jti", "iat", > etc.). That is, in the present formulation, there are two "token"s > involved -- the input that is being introspected, and the "token" that > is the introspection response. We are claiming that certain fields are > describing the input token, when they are defined to be statements about > the current (response) token. > Relaxing our statements to say that we merely use JWS as opposed to JWT > may be a workaround, though I have thought about it hard enough to have > an opinion on whether it is the best workaround. > > I also think we need more clarity about the use of dynamic client > registration by a resource server as outlined in Section 4 (where it's > mentioned as "with a resource server posing as the client", without > reference to RFC 7591. As far as I can tell this document/section is > introducing this use of dynamic client registration by an RS for the > first time, so we cannot easily just refer to some other document. > Specifically, are there any fields that MUST NOT be supplied? Is a > human-readable client_name useful? How does the supplied client_uri > need to relate to any existing AS representation of a resource in > audience, scope, etc. (e.g., for the "resource" request parameter from > draft-ietf-oauth-resource-indicators)? > > Is this usage considered to be a "new use of JWTs"? If so, it seems > that we should follow the recommendation of draft-ietf-oauth-jwt-bcp and > use explicit typing. > > I think there are some missing links in the document between a RS > registring client policy and the resulting AS enforcement of encryption > of introspection reponses. I think the intent is roughly that the > policy will be applied based on the audience of the token being > presented for introspection (as opposed to the identity of the > RS-as-client making the introspection request), but we don't seem to > explicitly say that. Also, we'd need to say something about the > interaction of multiple RSs' policy when a given token has multiple > valid audiences. There is a very brief discussion in Section 6.5, but > it seems to be more of a description of what is possible than mandating > particular forms of enforcement. > > I think we should discuss whether we want some statement from the OpenID > Foundation or related bodies before we register claims that point to > their documents with the IESG listed as change controller. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > idnits notes that RFC 5646 is mentioned but not present in the > references section. > > Section 1 > > We probably need to move the 7519 reference up here to where JWT is > first used. > > OAuth 2.0 Token Introspection [RFC7662] specifies a method for a > protected resource to query an OAuth 2.0 authorization server to > determine the state of an access token and obtain data associated > with the access token. This allows deployments to implement > identifier-based access tokens in an interoperable way. > > Does "identifier-based access tokens" mean "tokens that are opaque keys > to a (central) database lookup" or "access tokens that convey user > identity information" (or something else)? We may want to tweak the > wording. > > Section 3 > > Can we double-check the base64 form of the response in this example? I > am seeing output that backslash-escapes the '/' characters in URLs, > which I did not think was needed in this context. > I also see an "extension_field" claim in the base64 but not the decoded > form of the example, and "given_name"/"family_name"/"birthdate" in the > decoded example vs. "username" in the base64 version. > > Note: If the resource server policy requires a signed and encrypted > response and the authorization server receives an unauthenticated > request containing an Accept header with content type other than > "application/jwt", it MUST refuse to serve the request and return an > HTTP status code 400. This is done to prevent downgrading attacks to > obtain token data intended for release to legitimate recipients only > (see Section 6.2). > > I'd suggest a forward-reference to section 4 for how the AS will know > the RS's policy. Although, given that "unauthenticated request" is > included in the preconditions, perhaps we do not need the conditional on > "resource server policy" at all? > > Section 4 > > The authorization server determines what algorithm to employ to > secure the JWT for a particular introspection response. This > decision can be based on registered metadata parameters for the > resource server, supplied via dynamic client registration with the > resource server posing as the client, as defined by this draft. > > nit: I suggest s/posing as the/acting as a/, and s/by this draft/below/, > since it's right here in this section. > > introspection_encrypted_response_alg OPTIONAL. JWE [RFC7516] > algorithm ("alg" value) as defined in JWA [RFC7518] for > encrypting introspection responses. If this is specified, > the response will be encrypted using JWE and the configured > algorithm. The default, if omitted, is that no encryption is > > This text is slightly confusing with respect to the interaction between > the introspection_encrypted_response_alg "alg" value and the > introspection_encrypted_response_enc "enc" value. My understanding is > that the "enc" is a symmetric bulk encryption scheme that directly > protects the payload, whereas the "alg" is a key-wrap or key-agreement > mechanism used to establish the key used as input for the "enc" method. > So, while "algorithm ("alg value") for encrypting introspection > responses" and "the response will be encrypted using the confugred > ["algo"] algorithm" are technically true, they're also a bit misleading, > since this is not what encrypts the "bulk" of the response. Using the > term from RFC 7158, "key management algorithm", would probably alleviate > this confusion. > > Resource servers may register their public encryption keys using the > "jwks_uri" or "jwks" metadata parameters. > > Should we cite 7591 for these (or, really, the whole section)? We don't > currently mention it until the IANA considerations. > > Section 5 > > Is it worth a note that resource servers will fetch these metadata and > use them as input to their dynamic registrations in the previous section > (i.e., picking from the list of supported algorithms)? > > introspection_encryption_alg_values_supported OPTIONAL. JSON array > containing a list of the JWE [RFC7516] encryption algorithms > ("alg" values) as defined in JWA [RFC7518] supported by the > introspection endpoint to encrypt the response. > > Similarly to the above, some refined text about "key management > algorithm" used to encrypt the response, would probably be helpful. > > Section 6 > > There seem to be notable privacy considerations about quite a few of the > claims registered in Section 8.3. > > Section 6.1 > > I'm surprised to not see discussion of explicit typing (and, IIUC, how > it's not a reliable mitigation) here. > > JWT introspection responses and OpenID Connect ID Tokens are > syntactically similar. An attacker could therefore attempt to > impersonate an end-user at a OpenID Connect relying party by passing > the JWT as an ID token. > > nit: "response JWT" or "JWT response" > > Such an attack can be prevented like any other token substitution > attack. The authorization server MUST include the claims "iss" and > "aud" in each JWT introspection response, with the "iss" value set to > the authorization server's issuer URL and the "aud" value set to the > resource server's identifier. [...] > > Related to the Discuss point, how does this relate to the dynamic client > registration parameters? > > [OpenID.Core]. Relying parties SHOULD also use and check the "nonce" > parameter and claim to prevent token and code replay. > > Is this SHOULD just referring to the behavior already described in > OpenID.Core (and only applicable to OIDC implementations as opposed to > JWT-instrospection consumers)? If so, maybe descriptive language is > more appropriate, like "Relying parties are also expected to use and > check [...]". > > Resource servers utilizing JWTs to represent self-contained access > tokens could be susceptible to replay attacks. Resource servers > should therefore apply proper counter measures against replay as > described in [I-D.ietf-oauth-security-topics], section 2.2. > > I'm not sure what part of this is specific to the introspection case. > Is it supposed to be tied to the risk that JWT-instrospection produces a > new route for the generation of JWT objects that could be confused for > self-contained access tokens? > nit: "countermeasures" is valid as a single word. > nit: it looks like it's section 3.2, now. > > Section 6.2 > > Please cite RFC 7525 as BCP 195 as well as RFC 7525 (e.g., "per BCP 195 > [RFC7525]"). > > To prevent introspection of leaked tokens and to present an > additional security layer against token guessing attacks the > authorization server may require all requests to the token > introspection endpoint to be authenticated. As an alternative or as > an addition to the authentication, the intended recipients may be set > up for encrypted responses. > > Do we want to make either of these "may"s into normative recommendations > (or make a recommendation for prevention of introspection data leakage > even in the face of token leakage, which can be satisfied by either > mechanism)? > > Also, we could say more about how configuring encryption for intended > recipients protects against unencrypted replies to unintended > recipients... > > In the latter case, confidentiality is ensured by the fact that only > the legitimate recipient is able to decrypt the response. An > attacker could try to circumvent this measure by requesting a plain > JSON response, using an Accept header with the content type set to, > for example, "application/json" instead of "application/jwt". To > prevent this attack the authorization server MUST NOT serve requests > with content type other than "application/jwt" if the resource server > is set up to receive encrypted responses (see also Section 3). > > ....such as by saying that the introspection response will only be made > available to RSes that are intended recipients of (in the audience of?) > the access token being introspected. > > Section 6.3 > > Authorization servers with a policy that requires token data to be > kept confidential from OAuth clients must require all requests to the > token introspection endpoint to be authenticated. As an alternative > or as an addition to the authentication, the intended recipients may > be set up for encrypted responses. > > [this also seems to be assuming a link not stated between RS policy and > AS enforcement, but it seems unlikely that a fix would need to touch > this text] > > Section 8.1.1 > > nit: using nested lists might make this more readable. > > o Client Metadata Description: String value specifying the desired > introspection response encryption algorithm (alg value). > > [same bit about "key management algorithm"] > > Section 8.2.1 > > o Metadata Description: JSON array containing a list of algorithms > supported by the authorization server for introspection response > encryption (alg value). > > [and here] > > Section 8.3 > > I think we should make some mention earlier in the document > (Introduction?) that we also register some common claim values that are > in use in the wild (or whatever text you feel is appropriate to describe > the claims in question). > > The nested lists would be great here as well. > > Is there any expectation that some combination of "given_name", > "middle_name", and "family_name" will produce identical content to the > full "name" claim? > > o Name: "preferred_username" > > o Description: Shorthand name by which the End-User wishes to be > referred to at the RP, such as janedoe or j.doe. This value MAY > be any valid JSON string including special characters such as @, > /, or whitespace. > > It seems like there may be some security considerations about sanitziing > this field before using it in an application's logic. > > o Name: "profile" > > o Description:URL of the End-User's profile page. The contents of > this Web page SHOULD be about the End-User. > > It's slightly surpising to see this claimed for the end-user's profile > when it might equally apply to a protocol profile or variant in use. > But I assume this is already deployed, so there's no real point in > objecting to its registration... > > o Name: "birthdate" > > o Description:Time the End-User's information was last updated. Its > value is a JSON number representing the number of seconds from > 1970-01-01T0:0:0Z as measured in UTC until the date/time. > > This seems potentially confusable with the user's day/year of birth. > (Also, are leap seconds excluded?) > > o Name: "zoneinfo" > > o Description: String from zoneinfo [zoneinfo] time zone database > representing the End-User's time zone. For example, Europe/Paris > or America/Los_Angeles. > > We seem to be missing the actual reference entry for [zoneinfo]. > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 131, Issue 3 > ************************************* > --000000000000b495600591a3afa3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On = Mon, Sep 2, 2019, 5:45 PM <oa= uth-request@ietf.org> wrote:
Send OAuth mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.o= rg/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

=C2=A0 =C2=A01. . ?ric Vyncke's No Objection on?????
=C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-resource-indicators-05: (nessandorae)=
=C2=A0 =C2=A02. Benjamin Kaduk's Discuss on
=C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-jwt-introspection-response-07: (with = DISCUSS and
=C2=A0 =C2=A0 =C2=A0 COMMENT) (Benjamin Kaduk via Datatracker)


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

Message: 1
Date: Mon, 02 Sep 2019 15:20:54 -0500
From: nessandorae <nessandorae@gmail.com>
To: = oauth@ietf.org
Subject: [OAUTH-WG] . ?ric Vyncke's No Objection on?????
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-resource-indicators-05:
Message-ID: <5d6d79a9.1c69fb81.d0309.d0cc@mx.goo= gle.com>
Content-Type: text/plain; charset=3D"utf-8"

google.comSent from my MetroPCS 4G LTE Android Device
-------- Original message --------From: oauth-request@ietf.org Date= : 9/2/19=C2=A0 2:00 PM=C2=A0 (GMT-06:00) To: oauth@ietf.org Subject: OAuth = Digest, Vol 131, Issue 2 Send OAuth mailing list submissions to=C2=A0 =C2= =A0 =C2=A0oauth@ietf.orgTo subscribe or unsubscribe via the World Wide Web,= visit https://www.ietf.org/mailman/listinfo= /oauthor, via email, send a message with subject or body 'help'= to oauth-request@ietf.orgYou can reach the person managing the list at=C2= =A0 =C2=A0 =C2=A0oauth-owner@ietf.orgWhen replying, please edit your Subjec= t line so it is more specificthan "Re: Contents of OAuth digest...&quo= t;Today's Topics:?? 1. ?ric Vyncke's No Objection on????? draft-iet= f-oauth-resource-indicators-05: (with COMMENT)????? (?ric Vyncke via Datatr= acker)?? 2. Re:? ?ric Vyncke's No Objection on????? draft-ietf-oauth-re= source-indicators-05: (with COMMENT) (ki de)?? 3. Fwd: New Version Notifica= tion for????? draft-yusef-oauth-nested-jwt-02.txt (Rifaat Shekh-Yusef)-----= -----------------------------------------------------------------Message =C2=A0: 1Date: Mon, 02 Sep 2019 02:40:31 -0700From: ?ric Vyncke via Datatra= cker <noreply@ietf.org>To: "The IESG" <iesg@ietf.org>= ;Cc: draft-ietf-oauth-resource-indicators@ietf.o= rg, Rifaat Shekh-Yusef=C2=A0 =C2=A0 =C2=A0 =C2=A0 <rifaat.ietf@gm= ail.com>, oauth-chairs@ietf.org, rifaat.ietf@gmail.com= ,=C2=A0 oauth@ietf.orgSubject: [OAUTH-WG] ?ric Vyncke's No Objection on= draft-ietf-oauth-resource-indicators-05: (with COMMENT)Message-ID:=C2=A0 = =C2=A0 =C2=A0 <156741723195= .13041.3519982606374763447.idtracker@ietfa.amsl.com>Content-Type: te= xt/plain; charset=3D"utf-8"?ric Vyncke has entered the following = ballot position fordraft-ietf-oauth-resource-indicators-05: No ObjectionWhe= n responding, please keep the subject line intact and reply to allemail add= resses included in the To and CC lines. (Feel free to cut thisintroductory = paragraph, however.)Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor mor= e information about IESG DISCUSS and COMMENT positions.The document, along = with other ballot positions, can be found here:https://data
=C2=A0tracker.ietf.or= g/doc/draft-ietf-oauth-resource-indicators/--------------------------------= --------------------------------------COMMENT:-----------------------------= -----------------------------------------Thank you for the hard work pu= t into this easy to read document.Regards,-?ric=3D=3D COMMENTS =3D=3D-- Sec= tion 1 --"has uncovered a need, in some circumstances" (and simil= ar sentences in section1), it is rather vague for a standard track document= ... Please add some factsand data, this could be a companion document about= requirements/use cases.-- Section 2 --It is rather a question of mine, why= does the resource need to be a URI (whichusually bears some visible semant= ics) rather than an opaque string known onlyby the resource owner/server ? = This is similar to Mirja's comment about privacy.----------------------= --------Message: 2Date: Mon, 2 Sep 2019 10:22:53 +0000From: ki de <kay= coins@outlook.com>To: ?ric Vyncke <evyncke@cisco.com>Cc: Th= e IESG <iesg@ietf.org>, "draft-ietf-oauth-resource-ind
=C2=A0icators@ietf.org"=C2=A0 =C2=A0 =C2=A0 <draft-ietf-oauth-resource-indicators@ietf.org>, "oauth@ietf.= org"=C2=A0 =C2=A0 =C2=A0 =C2=A0<oauth@ietf.org>, "oa= uth-chairs@ietf.org" <oauth-chairs@ietf.org>Subject: = Re: [OAUTH-WG]? ?ric Vyncke's No Objection on draft-ietf-oauth-resource= -indicators-05: (with COMMENT)Message-ID:=C2=A0 =C2=A0 =C2=A0 <CH2PR15MB3606603D750B0= 001DEDEAE16D7BE0@CH2PR15MB3606.namprd15.prod.outlook.com>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Content-Type: text/plain; charset=3D"utf-8"On M= on, Sep 2, 2019 at 5:40 AM ?ric Vyncke via Datatracker <noreply@ietf.org> wrote:?ric Vyncke has entered the following ballot position fordraft= -ietf-oauth-resource-indicators-05: No ObjectionWhen responding, please kee= p the subject line intact and reply to allemail addresses included in the T= o and CC lines. (Feel free to cut thisintroductory paragraph, however.)Plea= se refer to https://nam03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=3D02%7C01%= 7C%7Cda0508bc7b9a4598ae6f08d72f89a104%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C= 1%7C0%7
=C2=A0C637030140461915948&amp;sdata=3DsK56j9bwVyLlNupgEdxExdaBTTOLnI28%= 2FYSTJVgLpG4%3D&amp;reserved=3D0for more information about IESG DISCUSS= and COMMENT positions.The document, along with other ballot positions, can= be found here:https://nam03.safelinks.pr= otection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraf= t-ietf-oauth-resource-indicators%2F&amp;data=3D02%7C01%7C%7Cda0508bc7b9= a4598ae6f08d72f89a104%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63703014= 0461925959&amp;sdata=3DyGz0cyRb7FgYxHtHOMLTScZeIpTSQGb7pu6NOhQF2Ic%3D&a= mp;amp;reserved=3D0--------------------------------------------------------= --------------COMMENT:-----------------------------------------------------= -----------------Thank you for the hard work put into this easy to read= document.Regards,-?ric=3D=3D COMMENTS =3D=3D-- Section 1 --"has uncov= ered a need, in some circumstances" (and similar sentences in section1= ), it is rather vague for a standard track document... Please add some fact= sand data, this could be a companion docu
=C2=A0ment about requirements/use cases.-- Section 2 --It is rather a quest= ion of mine, why does the resource need to be a URI (whichusually bears som= e visible semantics) rather than an opaque string known onlyby the resource= owner/server ? This is similar to Mirja's comment about privacy.______= _________________________________________OAuth mailing listOAuth@ietf.orght= tps://nam03.safelinks.protection.outlook.com/?url=3Dhttp= s%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=3D02%7C01%= 7C%7Cda0508bc7b9a4598ae6f08d72f89a104%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C= 1%7C0%7C637030140461925959&amp;sdata=3DQfcbDqqJ9Z6g%2BLq8dNAAizQcLfpLxR= 543GBaqZwiAsw%3D&amp;reserved=3D0-------------- next part ---------= -----An HTML attachment was scrubbed...URL: <https://mailarchive.ietf= .org/arch/browse/oauth/attachments/20190902/3f1a298a/attachment.html>= ;------------------------------Message: 3Date: Mon, 2 Sep 2019 11:03:20 -04= 00From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>To: oauth &l= t;oa= uth@ietf.org>Subject: [OA
=C2=A0UTH-WG] Fwd: New Version Notification for=C2=A0 =C2=A0 =C2=A0 draft-y= usef-oauth-nested-jwt-02.txtMessage-ID:=C2=A0 <CAGL6epLGY3dkDxg_x9m0OJC05Azu8ywS0frDahjssXSnAoOdQA@= mail.gmail.com>Content-Type: text/plain; charset=3D"utf-8"= All,I have submitted a new version of the Nested JWT draft and added the ST= IRuse case.Please, take a look and let me know if you have any comments.Reg= ards, Rifaat---------- Forwarded message ---------From: <internet-= drafts@ietf.org>Date: Mon, Sep 2, 2019 at 10:59 AMSubject: New Versi= on Notification for draft-yusef-oauth-nested-jwt-02.txtTo: Rifaat Shekh-Yus= ef <rifaat.ietf@gmail.com>A new version of I-D, draft-yusef-oa= uth-nested-jwt-02.txthas been successfully submitted by Rifaat Shekh-Yusef = and posted to theIETF repository.Name:?????????? draft-yusef-oauth-nested-j= wtRevision:?????? 02Title:????????? Nested JSON Web Token (JWT)Document dat= e:? 2019-09-02Group:????????? Individual SubmissionPages:????????? 5URL:https://www= .ietf.org/internet-drafts/draft-yusef-oauth-nested-jwt-02.txtStatus:ht<= br> =C2=A0tps://dat= atracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/Htmlized:?????? https://tools.ietf.org/html/= draft-yusef-oauth-nested-jwt-02Htmlized:https://datatracker.ietf.org/doc/ht= ml/draft-yusef-oauth-nested-jwtDiff:https://www.ietf.org/rfcdiff?url2=3Ddra= ft-yusef-oauth-nested-jwt-02Abstract:?? This specification extends the = scope of the Nested JSON Web Token?? (JWT) to allow the enclosing JWT to co= ntain its own Claims Set in?? addition to the enclosed JWT.Please note that= it may take a couple of minutes from the time of submissionuntil the htmli= zed version and diff are available at tools.ietf.org.The IETF Secretariat--= ------------ next part --------------An HTML attachment was scrubbed...URL:= <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190902= /1c70a6df/attachment.html>------------------------------Subject: Dig= est Footer_______________________________________________OAuth mailing list= OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth------------------------------<= br> =C2=A0End of OAuth Digest, Vol 131, Issue 2********************************= *****
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/2019= 0902/91be47b2/attachment.html>

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

Message: 2
Date: Mon, 02 Sep 2019 15:44:27 -0700
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-oauth-jwt-introspection-re= sponse@ietf.org, Rifaat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Shekh-Yusef <rifaat.ietf@gmail.com>= ;, oauth-chairs@ietf.org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 rifaat.ietf@gmail.com, oauth@ietf.org Subject: [OAUTH-WG] Benjamin Kaduk's Discuss on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-jwt-introspection-response-07:= (with DISCUSS and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 COMMENT)
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <156746426740.13074.1850379334333790613.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=3D"utf-8"

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwt-introspection-response-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf= .org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://data= tracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Per the ongoing discussion on the WG list, it's unclear that we can
retain the behaviors we describe and still comply with the requirements
of RFC 7519 requirements for being a JWT (e.g., regarding "jti", = "iat",
etc.).=C2=A0 That is, in the present formulation, there are two "token= "s
involved -- the input that is being introspected, and the "token"= that
is the introspection response.=C2=A0 We are claiming that certain fields ar= e
describing the input token, when they are defined to be statements about the current (response) token.
Relaxing our statements to say that we merely use JWS as opposed to JWT
may be a workaround, though I have thought about it hard enough to have
an opinion on whether it is the best workaround.

I also think we need more clarity about the use of dynamic client
registration by a resource server as outlined in Section 4 (where it's<= br> mentioned as "with a resource server posing as the client", witho= ut
reference to RFC 7591.=C2=A0 As far as I can tell this document/section is<= br> introducing this use of dynamic client registration by an RS for the
first time, so we cannot easily just refer to some other document.
Specifically, are there any fields that MUST NOT be supplied?=C2=A0 Is a human-readable client_name useful?=C2=A0 How does the supplied client_uri need to relate to any existing AS representation of a resource in
audience, scope, etc. (e.g., for the "resource" request parameter= from
draft-ietf-oauth-resource-indicators)?

Is this usage considered to be a "new use of JWTs"?=C2=A0 If so, = it seems
that we should follow the recommendation of draft-ietf-oauth-jwt-bcp and use explicit typing.

I think there are some missing links in the document between a RS
registring client policy and the resulting AS enforcement of encryption
of introspection reponses.=C2=A0 I think the intent is roughly that the
policy will be applied based on the audience of the token being
presented for introspection (as opposed to the identity of the
RS-as-client making the introspection request), but we don't seem to explicitly say that.=C2=A0 Also, we'd need to say something about the interaction of multiple RSs' policy when a given token has multiple
valid audiences.=C2=A0 There is a very brief discussion in Section 6.5, but=
it seems to be more of a description of what is possible than mandating
particular forms of enforcement.

I think we should discuss whether we want some statement from the OpenID Foundation or related bodies before we register claims that point to
their documents with the IESG listed as change controller.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

idnits notes that RFC 5646 is mentioned but not present in the
references section.

Section 1

We probably need to move the 7519 reference up here to where JWT is
first used.

=C2=A0 =C2=A0OAuth 2.0 Token Introspection [RFC7662] specifies a method for= a
=C2=A0 =C2=A0protected resource to query an OAuth 2.0 authorization server = to
=C2=A0 =C2=A0determine the state of an access token and obtain data associa= ted
=C2=A0 =C2=A0with the access token.=C2=A0 This allows deployments to implem= ent
=C2=A0 =C2=A0identifier-based access tokens in an interoperable way.

Does "identifier-based access tokens" mean "tokens that are = opaque keys
to a (central) database lookup" or "access tokens that convey use= r
identity information" (or something else)?=C2=A0 We may want to tweak = the
wording.

Section 3

Can we double-check the base64 form of the response in this example?=C2=A0 = I
am seeing output that backslash-escapes the '/' characters in URLs,=
which I did not think was needed in this context.
I also see an "extension_field" claim in the base64 but not the d= ecoded
form of the example, and "given_name"/"family_name"/&qu= ot;birthdate" in the
decoded example vs. "username" in the base64 version.

=C2=A0 =C2=A0Note: If the resource server policy requires a signed and encr= ypted
=C2=A0 =C2=A0response and the authorization server receives an unauthentica= ted
=C2=A0 =C2=A0request containing an Accept header with content type other th= an
=C2=A0 =C2=A0"application/jwt", it MUST refuse to serve the reque= st and return an
=C2=A0 =C2=A0HTTP status code 400.=C2=A0 This is done to prevent downgradin= g attacks to
=C2=A0 =C2=A0obtain token data intended for release to legitimate recipient= s only
=C2=A0 =C2=A0(see Section 6.2).

I'd suggest a forward-reference to section 4 for how the AS will know the RS's policy.=C2=A0 Although, given that "unauthenticated reque= st" is
included in the preconditions, perhaps we do not need the conditional on "resource server policy" at all?

Section 4

=C2=A0 =C2=A0The authorization server determines what algorithm to employ t= o
=C2=A0 =C2=A0secure the JWT for a particular introspection response.=C2=A0 = This
=C2=A0 =C2=A0decision can be based on registered metadata parameters for th= e
=C2=A0 =C2=A0resource server, supplied via dynamic client registration with= the
=C2=A0 =C2=A0resource server posing as the client, as defined by this draft= .

nit: I suggest s/posing as the/acting as a/, and s/by this draft/below/, since it's right here in this section.

=C2=A0 =C2=A0introspection_encrypted_response_alg=C2=A0 OPTIONAL.=C2=A0 JWE= [RFC7516]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm ("alg" value) = as defined in JWA [RFC7518] for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0encrypting introspection responses= .=C2=A0 If this is specified,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the response will be encrypted usi= ng JWE and the configured
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm.=C2=A0 The default, if o= mitted, is that no encryption is

This text is slightly confusing with respect to the interaction between
the introspection_encrypted_response_alg "alg" value and the
introspection_encrypted_response_enc "enc" value.=C2=A0 My unders= tanding is
that the "enc" is a symmetric bulk encryption scheme that directl= y
protects the payload, whereas the "alg" is a key-wrap or key-agre= ement
mechanism used to establish the key used as input for the "enc" m= ethod.
So, while "algorithm ("alg value") for encrypting introspect= ion
responses" and "the response will be encrypted using the confugre= d
["algo"] algorithm" are technically true, they're also a= bit misleading,
since this is not what encrypts the "bulk" of the response.=C2=A0= Using the
term from RFC 7158, "key management algorithm", would probably al= leviate
this confusion.

=C2=A0 =C2=A0Resource servers may register their public encryption keys usi= ng the
=C2=A0 =C2=A0"jwks_uri" or "jwks" metadata parameters.<= br>
Should we cite 7591 for these (or, really, the whole section)?=C2=A0 We don= 't
currently mention it until the IANA considerations.

Section 5

Is it worth a note that resource servers will fetch these metadata and
use them as input to their dynamic registrations in the previous section (i.e., picking from the list of supported algorithms)?

=C2=A0 =C2=A0introspection_encryption_alg_values_supported=C2=A0 OPTIONAL.= =C2=A0 JSON array
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0containing a list of the JWE [RFC7= 516] encryption algorithms
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0("alg" values) as define= d in JWA [RFC7518] supported by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0introspection endpoint to encrypt = the response.

Similarly to the above, some refined text about "key management
algorithm" used to encrypt the response, would probably be helpful.
Section 6

There seem to be notable privacy considerations about quite a few of the claims registered in Section 8.3.

Section 6.1

I'm surprised to not see discussion of explicit typing (and, IIUC, how<= br> it's not a reliable mitigation) here.

=C2=A0 =C2=A0JWT introspection responses and OpenID Connect ID Tokens are =C2=A0 =C2=A0syntactically similar.=C2=A0 An attacker could therefore attem= pt to
=C2=A0 =C2=A0impersonate an end-user at a OpenID Connect relying party by p= assing
=C2=A0 =C2=A0the JWT as an ID token.

nit: "response JWT" or "JWT response"

=C2=A0 =C2=A0Such an attack can be prevented like any other token substitut= ion
=C2=A0 =C2=A0attack.=C2=A0 The authorization server MUST include the claims= "iss" and
=C2=A0 =C2=A0"aud" in each JWT introspection response, with the &= quot;iss" value set to
=C2=A0 =C2=A0the authorization server's issuer URL and the "aud&qu= ot; value set to the
=C2=A0 =C2=A0resource server's identifier.=C2=A0 [...]

Related to the Discuss point, how does this relate to the dynamic client registration parameters?

=C2=A0 =C2=A0[OpenID.Core].=C2=A0 Relying parties SHOULD also use and check= the "nonce"
=C2=A0 =C2=A0parameter and claim to prevent token and code replay.

Is this SHOULD just referring to the behavior already described in
OpenID.Core (and only applicable to OIDC implementations as opposed to
JWT-instrospection consumers)?=C2=A0 If so, maybe descriptive language is more appropriate, like "Relying parties are also expected to use and check [...]".

=C2=A0 =C2=A0Resource servers utilizing JWTs to represent self-contained ac= cess
=C2=A0 =C2=A0tokens could be susceptible to replay attacks.=C2=A0 Resource = servers
=C2=A0 =C2=A0should therefore apply proper counter measures against replay = as
=C2=A0 =C2=A0described in [I-D.ietf-oauth-security-topics], section 2.2.
I'm not sure what part of this is specific to the introspection case. Is it supposed to be tied to the risk that JWT-instrospection produces a new route for the generation of JWT objects that could be confused for
self-contained access tokens?
nit: "countermeasures" is valid as a single word.
nit: it looks like it's section 3.2, now.

Section 6.2

Please cite RFC 7525 as BCP 195 as well as RFC 7525 (e.g., "per BCP 19= 5
[RFC7525]").

=C2=A0 =C2=A0To prevent introspection of leaked tokens and to present an =C2=A0 =C2=A0additional security layer against token guessing attacks the =C2=A0 =C2=A0authorization server may require all requests to the token
=C2=A0 =C2=A0introspection endpoint to be authenticated.=C2=A0 As an altern= ative or as
=C2=A0 =C2=A0an addition to the authentication, the intended recipients may= be set
=C2=A0 =C2=A0up for encrypted responses.

Do we want to make either of these "may"s into normative recommen= dations
(or make a recommendation for prevention of introspection data leakage
even in the face of token leakage, which can be satisfied by either
mechanism)?

Also, we could say more about how configuring encryption for intended
recipients protects against unencrypted replies to unintended
recipients...

=C2=A0 =C2=A0In the latter case, confidentiality is ensured by the fact tha= t only
=C2=A0 =C2=A0the legitimate recipient is able to decrypt the response.=C2= =A0 An
=C2=A0 =C2=A0attacker could try to circumvent this measure by requesting a = plain
=C2=A0 =C2=A0JSON response, using an Accept header with the content type se= t to,
=C2=A0 =C2=A0for example, "application/json" instead of "app= lication/jwt".=C2=A0 To
=C2=A0 =C2=A0prevent this attack the authorization server MUST NOT serve re= quests
=C2=A0 =C2=A0with content type other than "application/jwt" if th= e resource server
=C2=A0 =C2=A0is set up to receive encrypted responses (see also Section 3).=

....such as by saying that the introspection response will only be made
available to RSes that are intended recipients of (in the audience of?)
the access token being introspected.

Section 6.3

=C2=A0 =C2=A0Authorization servers with a policy that requires token data t= o be
=C2=A0 =C2=A0kept confidential from OAuth clients must require all requests= to the
=C2=A0 =C2=A0token introspection endpoint to be authenticated.=C2=A0 As an = alternative
=C2=A0 =C2=A0or as an addition to the authentication, the intended recipien= ts may
=C2=A0 =C2=A0be set up for encrypted responses.

[this also seems to be assuming a link not stated between RS policy and
AS enforcement, but it seems unlikely that a fix would need to touch
this text]

Section 8.1.1

nit: using nested lists might make this more readable.

=C2=A0 =C2=A0o=C2=A0 Client Metadata Description: String value specifying t= he desired
=C2=A0 =C2=A0 =C2=A0 introspection response encryption algorithm (alg value= ).

[same bit about "key management algorithm"]

Section 8.2.1

=C2=A0 =C2=A0o=C2=A0 Metadata Description: JSON array containing a list of = algorithms
=C2=A0 =C2=A0 =C2=A0 supported by the authorization server for introspectio= n response
=C2=A0 =C2=A0 =C2=A0 encryption (alg value).

[and here]

Section 8.3

I think we should make some mention earlier in the document
(Introduction?) that we also register some common claim values that are
in use in the wild (or whatever text you feel is appropriate to describe the claims in question).

The nested lists would be great here as well.

Is there any expectation that some combination of "given_name", "middle_name", and "family_name" will produce identical= content to the
full "name" claim?

=C2=A0 =C2=A0o=C2=A0 Name: "preferred_username"

=C2=A0 =C2=A0o=C2=A0 Description: Shorthand name by which the End-User wish= es to be
=C2=A0 =C2=A0 =C2=A0 referred to at the RP, such as janedoe or j.doe.=C2=A0= This value MAY
=C2=A0 =C2=A0 =C2=A0 be any valid JSON string including special characters = such as @,
=C2=A0 =C2=A0 =C2=A0 /, or whitespace.

It seems like there may be some security considerations about sanitziing this field before using it in an application's logic.

=C2=A0 =C2=A0o=C2=A0 Name: "profile"

=C2=A0 =C2=A0o=C2=A0 Description:URL of the End-User's profile page.=C2= =A0 The contents of
=C2=A0 =C2=A0 =C2=A0 this Web page SHOULD be about the End-User.

It's slightly surpising to see this claimed for the end-user's prof= ile
when it might equally apply to a protocol profile or variant in use.
But I assume this is already deployed, so there's no real point in
objecting to its registration...

=C2=A0 =C2=A0o=C2=A0 Name: "birthdate"

=C2=A0 =C2=A0o=C2=A0 Description:Time the End-User's information was la= st updated.=C2=A0 Its
=C2=A0 =C2=A0 =C2=A0 value is a JSON number representing the number of seco= nds from
=C2=A0 =C2=A0 =C2=A0 1970-01-01T0:0:0Z as measured in UTC until the date/ti= me.

This seems potentially confusable with the user's day/year of birth. (Also, are leap seconds excluded?)

=C2=A0 =C2=A0o=C2=A0 Name: "zoneinfo"

=C2=A0 =C2=A0o=C2=A0 Description: String from zoneinfo [zoneinfo] time zone= database
=C2=A0 =C2=A0 =C2=A0 representing the End-User's time zone.=C2=A0 For e= xample, Europe/Paris
=C2=A0 =C2=A0 =C2=A0 or America/Los_Angeles.

We seem to be missing the actual reference entry for [zoneinfo].




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

Subject: Digest Footer

_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


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

End of OAuth Digest, Vol 131, Issue 3
*************************************
--000000000000b495600591a3afa3-- From nobody Tue Sep 3 12:29:27 2019 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 08F1212018B for ; Tue, 3 Sep 2019 12:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 ltDt1Pxe2gaf for ; Tue, 3 Sep 2019 12:29:03 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 E81EA120825 for ; Tue, 3 Sep 2019 12:29:02 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id n197so36665317iod.9 for ; Tue, 03 Sep 2019 12:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ax2Tm7THMNCiLbjX2AzxfXEu7vje3sGHhMfSTWHv4f0=; b=fnPrvl+aiBBidODfB/rQED1q2WeaZHmxH7C2zi+pMdBtTqRui4cnwaiwpPQAhKdlt7 2IOCyP97rE7b/m2WEShZ+OpyEKhdfHOlClnUcJZLlwdH1cp0PLk19hn5iwF4PPaByJw0 Tiz2hbWyGAQ98t8+uHLMzichnNPCuclEVNrDk= 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=Ax2Tm7THMNCiLbjX2AzxfXEu7vje3sGHhMfSTWHv4f0=; b=qCrlDXd7cFo/QLqIe3jUeghcewOSeviBcwn9kFlXepVzG5q8EbqzCKXv6U+PxvYS43 hb7wSGKsKhGN7mLMjdKeSSFtXn6j21kDgXNCQbcEgRVku2+QcJI2F1FQFZ2evxOvYRtx 5t2TOU2aFi4yrx5b9aTEr2hCzkoJcQQewYLfEakjr5/rT1PyLyhChEjU815lYY9e8rX/ wn+uNzKlHtboaVDLaVI0mJ/aX7Y8d7bAggD8O1UjNgNqzGXkm6bNIi/Zll0v7XAP3MGU n4yZvxnhPwtGy0JDTJsL0tr0ebIwhFlHFdgtFJx43cK5uXwlkebxFVgZbwRTCrc/u9sN WXVQ== X-Gm-Message-State: APjAAAU3uIQWqR36bpLY1vA6/himGbsERjRA0kQS5mJeXigrscb3uyhJ 7hhBWvjQ7mIWkmokioc29pb3/4lWgOW3mdEb7529qOO9lbLpzD1BxkmOZUvAZai1jeE6MtN/tYg qp53zCeRhv8hIxw== X-Google-Smtp-Source: APXvYqz6G1Zgh+EKiHXYUeYZ+Fam1k+E04O7B1SX7wXssKsHB/SrvoaWqAjwRF4PJw274J2S2HmVYKkLy7jKC9ggb4U= X-Received: by 2002:a6b:b494:: with SMTP id d142mr238122iof.156.1567538942169; Tue, 03 Sep 2019 12:29:02 -0700 (PDT) MIME-Version: 1.0 References: <156741723195.13041.3519982606374763447.idtracker@ietfa.amsl.com> In-Reply-To: <156741723195.13041.3519982606374763447.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Tue, 3 Sep 2019 13:28:35 -0600 Message-ID: To: =?UTF-8?B?w4lyaWMgVnluY2tl?= Cc: The IESG , draft-ietf-oauth-resource-indicators@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000d1f3fa0591ab1998" Archived-At: Subject: Re: [OAUTH-WG] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-oauth-resource-indicators-05=3A_=28with_COMMENT=29?= 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: Tue, 03 Sep 2019 19:29:19 -0000 --000000000000d1f3fa0591ab1998 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you, =C3=89ric, for the review and ballot position. On Mon, Sep 2, 2019 at 3:40 AM =C3=89ric Vyncke via Datatracker wrote: > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-oauth-resource-indicators-05: No Objection ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the hard work put into this easy to read document. > Thanks, I'm happy to hear that you found it readable. > =3D=3D COMMENTS =3D=3D > > -- Section 1 -- > "has uncovered a need, in some circumstances" (and similar sentences in > section > 1), it is rather vague for a standard track document... Please add some > facts > and data, this could be a companion document about requirements/use cases= . > Sec 1 is intended to be a general (though not vague) introduction with some explanation about what an authorization server might be able to accomplish with an understanding of the location/identity of the protected resource for which the client is requesting an access token. Which effectively boils down to being able to produce the token appropriate for the indicated resource (including the type of token, if and how it's encrypted, what information is contained or referenced, to whom it is audience restricted). I've no doubt that the writing could stand to be improved (which is always the case with content I've written) but those are the use cases and I don't have more specific facts or data. > > -- Section 2 -- > It is rather a question of mine, why does the resource need to be a URI > (which > usually bears some visible semantics) rather than an opaque string known > only > by the resource owner/server ? This is similar to Mirja's comment about > privacy. > The motivation behind the draft is largely to facilitate this explicit signal to the authorization server (AS) about the location or identity of the protected resource for which the client is requesting an access token. For the reasons previously mentioned. Something that's opaque to the AS would negate the ability of the AS to do most of that stuff (admittedly not all but most). --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000d1f3fa0591ab1998 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you, =C3=89ric, for the review= and ballot position.


On Mon, Sep 2, 2019 at 3:40 = AM =C3=89ric Vyncke via Datatracker <noreply@ietf.org> wrote:
=C3=89ric Vyncke has entered the followi= ng ballot position for
draft-ietf-oauth-resource-indicators-05: No Objection=C2=A0
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the hard work put into this easy to read document.

Thanks, I'm happy to hear that you found it r= eadable.
=C2=A0
=C2=A0
=3D=3D COMMENTS =3D=3D

-- Section 1 --
"has uncovered a need, in some circumstances" (and similar senten= ces in section
1), it is rather vague for a standard track document... Please add some fac= ts
and data, this could be a companion document about requirements/use cases.<= br>

Sec 1 is intended to be a general (thou= gh not vague) introduction with some explanation about what an authorizatio= n server might be able to accomplish with an understanding of the location/= identity of the protected resource for which the client is requesting an ac= cess token. Which effectively boils down to being able to produce the token= appropriate for the indicated resource (including the type of token, if an= d how it's encrypted, what information is contained or referenced, to w= hom it is audience restricted). I've no doubt that the writing could st= and to be improved (which is always the case with content I've written)= but those are the use cases and I don't have more specific facts or da= ta.

=C2=A0

-- Section 2 --
It is rather a question of mine, why does the resource need to be a URI (wh= ich
usually bears some visible semantics) rather than an opaque string known on= ly
by the resource owner/server ? This is similar to Mirja's comment about= privacy.

The motivation behind the dra= ft is largely to facilitate this explicit signal to the authorization serve= r (AS) about the location or identity of the protected resource for which t= he client is requesting an access token. For the reasons previously mention= ed. Something that's opaque to the AS would negate the ability of the A= S to do most of that stuff (admittedly not all but most).


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000d1f3fa0591ab1998-- From nobody Tue Sep 3 12:34:13 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E268A120025; Tue, 3 Sep 2019 12:34:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-oauth-resource-indicators@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <156753925185.20703.13187186658332421594.idtracker@ietfa.amsl.com> Date: Tue, 03 Sep 2019 12:34:11 -0700 Archived-At: Subject: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 19:34:12 -0000 Barry Leiba has entered the following ballot position for draft-ietf-oauth-resource-indicators-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 2 -- invalid_target The requested resource is invalid, unknown, or malformed. For clarity, I suggest adding "missing" to the list, as specified in Section 2.1, '...and MAY fail requests that omit the parameter with an "invalid_target" error.' The authorization server SHOULD audience restrict issued access tokens to the resource(s) indicated by the "resource" parameter. I can't parse this sentence. I see "audience" as a verb, and don't understand. AH. I read later in the document and figured out my problem: I think it would help if you hyphenate "audience-restrict" (and "audience-restricted" later). No? From nobody Tue Sep 3 12:48:13 2019 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 280DB120047 for ; Tue, 3 Sep 2019 12:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 CSX40OqWwbSQ for ; Tue, 3 Sep 2019 12:48:01 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 EB9E812008B for ; Tue, 3 Sep 2019 12:48:00 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id u185so34936305iod.10 for ; Tue, 03 Sep 2019 12:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rkvNuMt4Gg2XQ5HbQ9Wv7AJfdnMVufz/V/EBW1/tmHc=; b=OhbQvnn04t7bvQ+jjoLgSc3LypoTiNQh1VRZbuLrFEFFm5+DpT+QmBay1ojeZ2F90y ozaa88GHEKomimJhzhQftugRzbTk3kpc7XJhvjr0TNGNRO4nAAx3cVpIBJLZeJodR2Tf pTIsARVKOllyoUlMMeLg4mjSlEKEoRFFYcPFE= 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=rkvNuMt4Gg2XQ5HbQ9Wv7AJfdnMVufz/V/EBW1/tmHc=; b=E/L/J95WrdpODilbJhwxRvv5e9gK+JF3xw1Xiwod6yJ8ndgI9va6hjODj3gu7/Flsz c0PIf/mohcNf3kpgxJWSWsF1M1PYnL5JteYHFPZYXIz7RpGsiHJcWQpgT3IpIX/r137i ZA0zVTrVLUk1KCB9Qhfx28ycOTKgYYyWQ3hljV4p5LYzS4hgcODHouwrwHm7mZOy/POg PYsbdZnPiQPeOAYglI43H40uFLpZWhI8DM9oASiK+GLLWVGrdBcHVT2Gmj3MTX3oXwle WIcZWEavpwWwLS2bVs3QHVcqhAf5JNGhm/mA3HHMKQU+1xdWRAvt37srZvPZ5vxHxGyk egXA== X-Gm-Message-State: APjAAAUUDa3bAbmIkBB4cBD7EipnWIhOAqfoA4+aYEqQyoUwdyjlBehs eQaBwdBaPFUmR4EVfOM01aRdrgeo2s8IeGDUbh3U2ctNVFcrUrbUHy90B6OyUM3i5NKeUmgwCuU mibIMfaFS7pzxCUBOxpk= X-Google-Smtp-Source: APXvYqz5//iuWS30vVVGgVAuJ/BqrGp0AD5+mhVRdz2K5LF9CDjIe6/z5lpMqnw3jkRWb/9J8mXL8VAKuTixpPz+wEY= X-Received: by 2002:a05:6638:6b2:: with SMTP id d18mr852198jad.61.1567540080100; Tue, 03 Sep 2019 12:48:00 -0700 (PDT) MIME-Version: 1.0 References: <156753925185.20703.13187186658332421594.idtracker@ietfa.amsl.com> In-Reply-To: <156753925185.20703.13187186658332421594.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Tue, 3 Sep 2019 13:47:34 -0600 Message-ID: To: Barry Leiba Cc: The IESG , draft-ietf-oauth-resource-indicators@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000a5604d0591ab5d35" Archived-At: Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) 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: Tue, 03 Sep 2019 19:48:04 -0000 --000000000000a5604d0591ab5d35 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Barry, thanks for the review and ballot position. On Tue, Sep 3, 2019 at 1:34 PM Barry Leiba via Datatracker wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-oauth-resource-indicators-05: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > -- Section 2 -- > > invalid_target > The requested resource is invalid, unknown, or malformed. > > For clarity, I suggest adding "missing" to the list, as specified in > Section > 2.1, '...and MAY fail requests that omit the parameter with an > "invalid_target" > error.' > > The authorization server SHOULD audience restrict issued access > tokens to the resource(s) indicated by the "resource" parameter. > Makes sense, will do. > I can't parse this sentence. I see "audience" as a verb, and don't > understand. > AH. I read later in the document and figured out my problem: I think it > would > help if you hyphenate "audience-restrict" (and "audience-restricted" > later). > No? > Yes? Short of Adam Roach stepping in here to teach me more about proper use of hyphens [1], I think that would be helpful and will make the changes. [1] https://mailarchive.ietf.org/arch/msg/oauth/IsoOa0jvabolUSzjzWHjk8b0aVY --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000a5604d0591ab5d35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Barry, thanks for the review and ballot p= osition.

On Tue, Sep 3, 2019 at 1:34 PM Barry Leiba via Datatracker <= ;noreply@ietf.org> wrote:
Barry Leiba has entere= d the following ballot position for
draft-ietf-oauth-resource-indicators-05: No Objection

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-- Section 2 --

=C2=A0 =C2=A0invalid_target
=C2=A0 =C2=A0 =C2=A0 The requested resource is invalid, unknown, or malform= ed.

For clarity, I suggest adding "missing" to the list, as specified= in Section
2.1, '...and MAY fail requests that omit the parameter with an "in= valid_target"
error.'

=C2=A0 =C2=A0The authorization server SHOULD audience restrict issued acces= s
=C2=A0 =C2=A0tokens to the resource(s) indicated by the "resource"= ; parameter.

Makes sense, will do.
=

=C2=A0
I can't parse this sentence.=C2=A0 I see "audience" as a verb= , and don't understand.
AH.=C2=A0 I read later in the document and figured out my problem: I think = it would
help if you hyphenate "audience-restrict" (and "audience-res= tricted" later).
No?

Yes? Short of Adam Roach stepping i= n here to teach me more about proper use of hyphens [1], I think that would= be helpful and will make the changes.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000a5604d0591ab5d35-- From nobody Tue Sep 3 12:51:50 2019 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 18D25120047; Tue, 3 Sep 2019 12:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 ryMLar30tC5O; Tue, 3 Sep 2019 12:51:40 -0700 (PDT) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (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 E72E5120043; Tue, 3 Sep 2019 12:51:39 -0700 (PDT) Received: by mail-io1-f47.google.com with SMTP id p12so38814079iog.5; Tue, 03 Sep 2019 12:51:39 -0700 (PDT) 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=vs/M/cZKA7WjJmdJy3aYwVp0cFEdd74rZHS/0nl7qUM=; b=Mmc3ZCbXlI1vItfLnDcKBc79yYbQkOZ4GrjmJ9qFsonvtmfYCSU96P67GlWIWqhHPW ChzA1gpU6lyJUSp2cKFR+iZJE2Aw1vueMlMVZH2tBFNuL9+eKf5eXer5gVxqxIInn+I4 w+PIJ3Vx/StYAyhZCyEEThDx0MBAJKpq6AI/MvGJ8rQZNlD3Q1W4AEyMYRvoviVeFEb0 27S691GlqIQzMTQz+VuJ6mXJWbB/pdMe0hdU3zi9bcxxirn9b52YOnOEU4ksO3hmpJTw rIDw/8nyzJ+PObJGvg5mXGX8WBx9tmJ2eFzhtqUeoT7vQU1UKS+2tmq/AOdtZoo9DNbQ U2Eg== X-Gm-Message-State: APjAAAWoT5nMRG/jWjpSXiUPafTcaoBEa+ObGWTLF2VbPGHkT/zJZoTA Hu1LMGjfC/Binh6MFWWYbnD+rZbT7r6QIkSEj78= X-Google-Smtp-Source: APXvYqwfiEbPmWAcJ4u2buA/b+I4DAwkWCoL+yaqPZxFIzqZDTwNoC0xogVJAyE4sKmZFtGyEyC69th2yIb+1oSsf3k= X-Received: by 2002:a02:c546:: with SMTP id g6mr24022515jaj.59.1567540298954; Tue, 03 Sep 2019 12:51:38 -0700 (PDT) MIME-Version: 1.0 References: <156753925185.20703.13187186658332421594.idtracker@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Tue, 3 Sep 2019 15:51:27 -0400 Message-ID: To: Brian Campbell Cc: The IESG , draft-ietf-oauth-resource-indicators@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) 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: Tue, 03 Sep 2019 19:51:42 -0000 >> AH. I read later in the document and figured out my problem: I think it would >> help if you hyphenate "audience-restrict" (and "audience-restricted" later). >> No? > > Yes? Short of Adam Roach stepping in here to teach me more about proper use of hyphens [1], I > think that would be helpful and will make the changes. :-) This is a really tricky one, hyphenwise, and I'm not sure. What I *am* sure about is that if it were hyphenated I would not have had a problem reading it. Thanks for the quick response! Barry From nobody Tue Sep 3 23:06:45 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E2D12003E; Tue, 3 Sep 2019 23:06:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-oauth-resource-indicators@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <156757720342.20663.3055037033818226992.idtracker@ietfa.amsl.com> Date: Tue, 03 Sep 2019 23:06:43 -0700 Archived-At: Subject: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2019 06:06:44 -0000 Adam Roach has entered the following ballot position for draft-ietf-oauth-resource-indicators-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Many thanks to everyone who worked on this refinement to OAuth. It seems like it will be a significant improvement over today's ad-hoc system. I agree with Barry and Alexey about the need for some language discussing the privacy implications of explicitly signaling audience resources to OAuth servers. --------------------------------------------------------------------------- §2: > The client SHOULD use the base URI of the API > as the "resource" parameter value unless specific knowledge of the > resource dictates otherwise. For example, the value > "https://api.example.com/" would be used for a resource that is the > exclusive application on that host, however, if the resource is one > of many applications on that host, something like > "https://api.example.com/app/" would be used as a more specific > value. Another example, for an API like SCIM [RFC7644] that has > multiple endpoints such as "https://apps.example.com/scim/Users", > "https://apps.example.com/scim/Groups", and > "https://apps.example.com/scim/Schemas" The client would use > "https://apps.example.com/scim/" as the resource so that the issued > access token is valid for all the endpoints of the SCIM API. This seems pretty intuitive in the examples given. It may be a little less clear when applications are indicated by query parameter instead of path prefixes. For example, if an endpoint is running two applications distinguished thus: https://example.com/apps/?app=app1 https://example.com/apps/?app=app2 ...and in a form that allows for additional parameters: https://example.com/apps/?darkmode=true&version=1.2&app=app2 ...then the notion of the "most specific API" isn't quite as clear. Intuitively, I think the idea would be that the resource for app2 would be . It may be useful to include an example along these lines as an illustration. --------------------------------------------------------------------------- §2.2: > &resource=https%3A%2F%2Fcontacts.example.com%2Fapp%2F ... > "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi > JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI > iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwic2NvcGUiOiJjb250YWN0cyIs > ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIn0.5f4yhqazc > OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3nQXnBMw5wREY5O1YbZED-GfH > UowfmtNaA5EikYAw", The "aud" value here is "https://contacts.example.com/" rather than the "https://contacts.example.com/app/" that I would expect -- that is, I would expect them to match. Am I misunderstanding the intended relationship between "resouce" and "aud"? --------------------------------------------------------------------------- §3: > Some servers may host user content or be multi-tenant. In order to > avoid attacks that might confuse a client into sending an access > token to a resource that is user controlled or is owned by a > different tenant, it is important to use a specific resource URI > including a path component. Related to my comment about §2 above, "path component" isn't quite sufficient. What you want is "including any portion of the URI that identifies the resource, such as a path component." From nobody Wed Sep 4 00:44:38 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BB31200CE; Wed, 4 Sep 2019 00:44:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwt-introspection-response@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <156758306119.22796.7625113709709674898.idtracker@ietfa.amsl.com> Date: Wed, 04 Sep 2019 00:44:21 -0700 Archived-At: Subject: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2019 07:44:22 -0000 Adam Roach has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the work the authors and other contributors have put into creating this document. I have a privacy concern that I think warrants text in the document. Section 8.3.1 introduces a significant amount of personally-identifiable information. While I understand that this is needed for the use case cited in the introduction (issuing certificated for electronic signatures), I think the document needs some treatment of the sensitivity of this information, the basis that the server uses to decide whether to include it, and how consent to disclose it might be obtained from the user. I'm putting this in as a DISCUSS, because I really do think this is a showstopper for publication. I am quite aware, however, that I might simply be missing some important aspect of the solution that makes my concerns moot. Please point me in the right direction if this is the case, and I'll be happy to clear. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- §3: > The example response contains the following JSON document: > > { > "sub": "Z5O3upPC88QrAjx00dis", > "aud": "https://protected.example.net/resource", > "scope": "read write dolphin", > "iss": "https://server.example.com/", > "active": true, > "exp": 1419356238, > "iat": 1419350238, > "client_id": "l238j323ds-23ij4", > "given_name": "John", > "family_name":"Doe", > "birthdate":"1982-02-01" > } The example response actually contains the following JSON document: { "sub":"Z5O3upPC88QrAjx00dis", "aud":"https:\/\/protected.example.net\/resource", "extension_field":"twenty-seven", "scope":"read write dolphin", "iss":"https:\/\/server.example.com\/", "active":true, "exp":1419356238, "iat":1419350238, "client_id":"l238j323ds-23ij4", "username":"jdoe" } Note the presence of "extension_field" and "username" fields, and the absence of "given_name", "family_name", and "birthdate" fields. There's also a bunch of unnecessarily escaped "/" characters in the document in the JWT, but not the expanded example; and while these are semantically insignificant, the discrepancy seems gratuitous. It is probably worthwhile updating either the JWT or the expanded example so that they match. From nobody Wed Sep 4 01:00:05 2019 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 AFCAD1200CE; Wed, 4 Sep 2019 01:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Fih2Si8N; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=B9i4xWW2 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 CyDmn7EoZdmd; Wed, 4 Sep 2019 00:59:58 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915221200DB; Wed, 4 Sep 2019 00:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16403; q=dns/txt; s=iport; t=1567583998; x=1568793598; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fWUWfuAu2uZgpHAfO6X+8clNtXCFg5Lh54CVJjgDxaw=; b=Fih2Si8NBSR97IUAHCUnFMmOBNIqMEsnSuWTtaO+xrK87D6ilr5Hs4P9 ub/86t/hNobXChbPYjBZHsSG/DpaDNxDcv/yCqFe3thLZGVAZP4STfXOf /Nl1nWokeCI7ve7iRXpLoprzRjp6f55/9iyq+X5yjE5b8t2O0Vp9vn5u3 Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AowrGYBMoPxzNXTJUmcsl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj2Mu/sZC83NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAgAXbm9d/4cNJK1cCRsBAQEBAwE?= =?us-ascii?q?BAQcDAQEBgWeBFi8kBScDbVYgBAsqhCGDRwOKe4I3JZMQhFyBQoEQA1QJAQE?= =?us-ascii?q?BDAEBLQIBAYQ/AheCZSM4EwIDCAEBBAEBAQIBBgRthS4MhUoBAQEBAxIRHQE?= =?us-ascii?q?BNwEPAgEIDgMDAQIkBAMCAgIwFAYDCAIEDgUigwABgR1NAx0BAp5AAoE4iGF?= =?us-ascii?q?zgTKCfAEBBYUMGIIWCYE0ilqBAR0YgUA/JmsnDBOBfFA+hAgJAQgKAQk2FoJ?= =?us-ascii?q?VMoImjDYcgl6FHpdXCoIfkA1Xg3gbgjQvhwcFhBmKYoM4owsCBAIEBQIOAQE?= =?us-ascii?q?FgWchZ3FwFTEPJQFVHYEmKYJCOG8BAoJIilNzgSmMGYJFAQE?= X-IronPort-AV: E=Sophos;i="5.64,465,1559520000"; d="scan'208,217";a="538253943" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Sep 2019 07:59:57 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x847xvIo031472 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Sep 2019 07:59:57 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 4 Sep 2019 02:59:56 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 4 Sep 2019 02:59:56 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 4 Sep 2019 02:59:56 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aL39eV5tVN3FEhyIV9IzOvVvVu3aZnhIpuMy5icdEuuzShRrq3yzcoiOBxFGVISY45kVpjxLLv8DPjV4FGsfKMH/5icLx9zFH6ou7ao/3dNw43RhBNcljYdepkLkAJ8SwOWuQkqtMQDgoyYxH/CUjfs3Mj1zfxEOkzQ1sMlrIJZrC3xdz8ZvAKbNR6fefr9UEpwGP85/proiT/iKbuajYzs5P6JSa8j2a99AuJT1uoiGmusc28tOYeWY+B+JvY4KPAABJ9VSuMEht05ggGV49hTFrV3AqX4hEaxJaFzOg4w88apdRz8nST5XQvJABZRcnMWtF58Xw1UvX+MYLVjgYA== 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=fWUWfuAu2uZgpHAfO6X+8clNtXCFg5Lh54CVJjgDxaw=; b=Rl+TK2dAvX9+oq8yAItASL9P1/clK62cQiThQfy90EBwZCA7KXSUAx3EL/kJmOieShcUnuRSz6nuQPirANFJDjIN7WFELQi8yvJhwxSxlu9OFy0OhqJizdDVZThtG4hOtv8EWMetc2PsscOJE4Z6PZTzviC/f5oAOOdMwBCVCMzp86XM7YUzXG/tPseaIOoZpwKZbesK3WSRcWGkn0pH1ByLFc6XTyxTZ+nZbMtFUxxshYaxc57qOIZcwuADvlVBMtNccYUHgeIrowsRgog764SkxHxvpWb3Lbwn3GnGpZb8rg0I/tv9kJyBVLUI30ekh/Uv7DVevtWw0Ru7ka57ug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fWUWfuAu2uZgpHAfO6X+8clNtXCFg5Lh54CVJjgDxaw=; b=B9i4xWW2uw/DVZLzE/XcGAFyDaIshUv/PF+8g3W4sjZt4GN8+oYDdpEoZhMk4M32eyncYsR3nsh01Cw5oPyqWt+qnrn0a5ALmhQfGw7eko988n7Zctyt0SY3DcsifAoaulex0J67646Ulwlv8+NzexQ6iDGZxrRxbHL3ovkdUcs= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB3728.namprd11.prod.outlook.com (20.178.253.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.20; Wed, 4 Sep 2019 07:59:55 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::d5c4:be39:66cb:449b]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::d5c4:be39:66cb:449b%6]) with mapi id 15.20.2220.020; Wed, 4 Sep 2019 07:59:55 +0000 From: "Eric Vyncke (evyncke)" To: Brian Campbell CC: The IESG , "draft-ietf-oauth-resource-indicators@ietf.org" , oauth , "oauth-chairs@ietf.org" Thread-Topic: =?utf-8?B?W09BVVRILVdHXSDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJh?= =?utf-8?B?ZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTA1OiAod2l0aCBD?= =?utf-8?Q?OMMENT)?= Thread-Index: AQHVYo3HnIoMp3iLFEG4o8ReFMdTgKcbSeOA Date: Wed, 4 Sep 2019 07:59:54 +0000 Message-ID: References: <156741723195.13041.3519982606374763447.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:dddd:960:a05c:9f22] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2df76331-927f-4d5d-db61-08d7310ddfa6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3728; x-ms-traffictypediagnostic: MN2PR11MB3728: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0150F3F97D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(366004)(39860400002)(346002)(376002)(199004)(189003)(476003)(76116006)(6486002)(91956017)(14454004)(5660300002)(478600001)(11346002)(2906002)(58126008)(53936002)(54906003)(66946007)(186003)(7736002)(66476007)(2616005)(6916009)(86362001)(66556008)(64756008)(66446008)(229853002)(224303003)(8936002)(256004)(236005)(446003)(46003)(66574012)(4326008)(6246003)(316002)(102836004)(76176011)(81166006)(53546011)(6512007)(71200400001)(6116002)(33656002)(5024004)(14444005)(36756003)(6436002)(486006)(71190400001)(6506007)(99286004)(54896002)(6306002)(81156014)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3728; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: xn571MCzNe3J9+iDIEEQYIAMBA4wEGtXzXCQ743vHt3d02f5+e2Tv/IcshARW6gg0iJhFBTq5qoXaoRIGEFRpUzf9+XthqjqYZYWNEg3MEYVbNW5kr4Xiskv2Wi7XuDlou90SYduc0q689D+xeYOyDb/2tUYsmgdioKdLCYf0GmakRmMXmm9q4Q2u8tqTYFikrgl6+LLCds6M+4tmj1GPO90l12S5SfApYx7o/zrMjLACxLoAvHLRSZO4Lh18G3I4D/Qb1a7HDH9q+hXdzpmcmNuf4po5DzPy9chEK7H3a3xOkRphDuCEL741P2Tl6kq9fuzGYyEKq+yXimef+y+eF7Il47sTXfqORG96Jjyi/nPq0m0p/E5B87RPU6L2L5bCBNvoI7a+YxtO0BB4/3f/ASNBb0MnZ77TqgIEQOc7Qg= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_F9495E2053864F128479391A36502C89ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2df76331-927f-4d5d-db61-08d7310ddfa6 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2019 07:59:55.0565 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nx2G9NrRqvrN2RcBHQF/xzKAVz+4kbA62/ckohAIGn/Ta+yL7ydb/tWXC/98PDPUWs3qvxiAQGHaB0cCFCIInA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3728 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [OAUTH-WG] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-oauth-resource-indicators-05=3A_=28with_COMMENT=29?= 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: Wed, 04 Sep 2019 08:00:03 -0000 --_000_F9495E2053864F128479391A36502C89ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnJpYW4sDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXBseSBhbmQgdGhlIGV4cGxhbmF0aW9uIGFi b3V0IHRoZSBVUkkgdnMuIGFuIG9wYXF1ZSB2YWx1ZSAoc3RpbGwgd29uZGVyaW5nIHRob3VnaCBh Ym91dCB0aGUgcHJpdmFjeSBsZWFrcyBidXQgcGVyaGFwcyBsZXNzIGltcG9ydGFudCBpbiB0aGUg d29ybGQgb2YgT0F1dGgpLg0KDQpJIGJlbGlldmUgdGhhdCB0aGUgZG9jdW1lbnQgd291bGQgYmVu ZWZpdCBpZiB5b3UgY291bGQgYWRkIHNvbWUgbW9yZSBleGFtcGxlcy91c2UgY2FzZXMgaW4gc2Vj dGlvbiAxLiBVcCB0byB0aGUgYXV0aG9ycy4NCg0KUmVnYXJkcw0KDQotw6lyaWMNCg0KRnJvbTog QnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPg0KRGF0ZTogVHVlc2Rh eSwgMyBTZXB0ZW1iZXIgMjAxOSBhdCAyMToyOQ0KVG86IEVyaWMgVnluY2tlIDxldnluY2tlQGNp c2NvLmNvbT4NCkNjOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4sICJkcmFmdC1pZXRmLW9hdXRo LXJlc291cmNlLWluZGljYXRvcnNAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNl LWluZGljYXRvcnNAaWV0Zi5vcmc+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+LCAib2F1dGgtY2hh aXJzQGlldGYub3JnIiA8b2F1dGgtY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gw4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtb2F1dGgtcmVz b3VyY2UtaW5kaWNhdG9ycy0wNTogKHdpdGggQ09NTUVOVCkNCg0KVGhhbmsgeW91LCDDiXJpYywg Zm9yIHRoZSByZXZpZXcgYW5kIGJhbGxvdCBwb3NpdGlvbi4NCg0KDQpPbiBNb24sIFNlcCAyLCAy MDE5IGF0IDM6NDAgQU0gw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRm Lm9yZzxtYWlsdG86bm9yZXBseUBpZXRmLm9yZz4+IHdyb3RlOg0Kw4lyaWMgVnluY2tlIGhhcyBl bnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1vYXV0 aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTA1OiBObyBPYmplY3Rpb24NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNP TU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRoYW5rIHlvdSBmb3IgdGhlIGhhcmQgd29yayBwdXQg aW50byB0aGlzIGVhc3kgdG8gcmVhZCBkb2N1bWVudC4NCg0KVGhhbmtzLCBJJ20gaGFwcHkgdG8g aGVhciB0aGF0IHlvdSBmb3VuZCBpdCByZWFkYWJsZS4NCg0KDQo9PSBDT01NRU5UUyA9PQ0KDQot LSBTZWN0aW9uIDEgLS0NCiJoYXMgdW5jb3ZlcmVkIGEgbmVlZCwgaW4gc29tZSBjaXJjdW1zdGFu Y2VzIiAoYW5kIHNpbWlsYXIgc2VudGVuY2VzIGluIHNlY3Rpb24NCjEpLCBpdCBpcyByYXRoZXIg dmFndWUgZm9yIGEgc3RhbmRhcmQgdHJhY2sgZG9jdW1lbnQuLi4gUGxlYXNlIGFkZCBzb21lIGZh Y3RzDQphbmQgZGF0YSwgdGhpcyBjb3VsZCBiZSBhIGNvbXBhbmlvbiBkb2N1bWVudCBhYm91dCBy ZXF1aXJlbWVudHMvdXNlIGNhc2VzLg0KDQpTZWMgMSBpcyBpbnRlbmRlZCB0byBiZSBhIGdlbmVy YWwgKHRob3VnaCBub3QgdmFndWUpIGludHJvZHVjdGlvbiB3aXRoIHNvbWUgZXhwbGFuYXRpb24g YWJvdXQgd2hhdCBhbiBhdXRob3JpemF0aW9uIHNlcnZlciBtaWdodCBiZSBhYmxlIHRvIGFjY29t cGxpc2ggd2l0aCBhbiB1bmRlcnN0YW5kaW5nIG9mIHRoZSBsb2NhdGlvbi9pZGVudGl0eSBvZiB0 aGUgcHJvdGVjdGVkIHJlc291cmNlIGZvciB3aGljaCB0aGUgY2xpZW50IGlzIHJlcXVlc3Rpbmcg YW4gYWNjZXNzIHRva2VuLiBXaGljaCBlZmZlY3RpdmVseSBib2lscyBkb3duIHRvIGJlaW5nIGFi bGUgdG8gcHJvZHVjZSB0aGUgdG9rZW4gYXBwcm9wcmlhdGUgZm9yIHRoZSBpbmRpY2F0ZWQgcmVz b3VyY2UgKGluY2x1ZGluZyB0aGUgdHlwZSBvZiB0b2tlbiwgaWYgYW5kIGhvdyBpdCdzIGVuY3J5 cHRlZCwgd2hhdCBpbmZvcm1hdGlvbiBpcyBjb250YWluZWQgb3IgcmVmZXJlbmNlZCwgdG8gd2hv bSBpdCBpcyBhdWRpZW5jZSByZXN0cmljdGVkKS4gSSd2ZSBubyBkb3VidCB0aGF0IHRoZSB3cml0 aW5nIGNvdWxkIHN0YW5kIHRvIGJlIGltcHJvdmVkICh3aGljaCBpcyBhbHdheXMgdGhlIGNhc2Ug d2l0aCBjb250ZW50IEkndmUgd3JpdHRlbikgYnV0IHRob3NlIGFyZSB0aGUgdXNlIGNhc2VzIGFu ZCBJIGRvbid0IGhhdmUgbW9yZSBzcGVjaWZpYyBmYWN0cyBvciBkYXRhLg0KDQoNCg0KLS0gU2Vj dGlvbiAyIC0tDQpJdCBpcyByYXRoZXIgYSBxdWVzdGlvbiBvZiBtaW5lLCB3aHkgZG9lcyB0aGUg cmVzb3VyY2UgbmVlZCB0byBiZSBhIFVSSSAod2hpY2gNCnVzdWFsbHkgYmVhcnMgc29tZSB2aXNp YmxlIHNlbWFudGljcykgcmF0aGVyIHRoYW4gYW4gb3BhcXVlIHN0cmluZyBrbm93biBvbmx5DQpi eSB0aGUgcmVzb3VyY2Ugb3duZXIvc2VydmVyID8gVGhpcyBpcyBzaW1pbGFyIHRvIE1pcmphJ3Mg Y29tbWVudCBhYm91dCBwcml2YWN5Lg0KDQpUaGUgbW90aXZhdGlvbiBiZWhpbmQgdGhlIGRyYWZ0 IGlzIGxhcmdlbHkgdG8gZmFjaWxpdGF0ZSB0aGlzIGV4cGxpY2l0IHNpZ25hbCB0byB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgKEFTKSBhYm91dCB0aGUgbG9jYXRpb24gb3IgaWRlbnRpdHkgb2Yg dGhlIHByb3RlY3RlZCByZXNvdXJjZSBmb3Igd2hpY2ggdGhlIGNsaWVudCBpcyByZXF1ZXN0aW5n IGFuIGFjY2VzcyB0b2tlbi4gRm9yIHRoZSByZWFzb25zIHByZXZpb3VzbHkgbWVudGlvbmVkLiBT b21ldGhpbmcgdGhhdCdzIG9wYXF1ZSB0byB0aGUgQVMgd291bGQgbmVnYXRlIHRoZSBhYmlsaXR5 IG9mIHRoZSBBUyB0byBkbyBtb3N0IG9mIHRoYXQgc3R1ZmYgKGFkbWl0dGVkbHkgbm90IGFsbCBi dXQgbW9zdCkuDQoNCg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUg dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJp YnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVz c2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5 b3UuDQo= --_000_F9495E2053864F128479391A36502C89ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <969CCC742B1C8D4291D27B55D735C7EC@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBV SSI7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJpYW4sPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rIHlvdSBmb3IgeW91ciByZXBseSBhbmQgdGhlIGV4cGxhbmF0aW9uIGFib3V0 IHRoZSBVUkkgdnMuIGFuIG9wYXF1ZSB2YWx1ZSAoc3RpbGwgd29uZGVyaW5nIHRob3VnaCBhYm91 dCB0aGUgcHJpdmFjeSBsZWFrcyBidXQgcGVyaGFwcyBsZXNzIGltcG9ydGFudCBpbiB0aGUgd29y bGQgb2YgT0F1dGgpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgdGhhdCB0aGUg ZG9jdW1lbnQgd291bGQgYmVuZWZpdCBpZiB5b3UgY291bGQgYWRkIHNvbWUgbW9yZSBleGFtcGxl cy91c2UgY2FzZXMgaW4gc2VjdGlvbiAxLiBVcCB0byB0aGUgYXV0aG9ycy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tw6lyaWM8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5CcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20mZ3Q7 PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIDMgU2VwdGVtYmVyIDIwMTkgYXQgMjE6Mjk8YnI+ DQo8Yj5UbzogPC9iPkVyaWMgVnluY2tlICZsdDtldnluY2tlQGNpc2NvLmNvbSZndDs8YnI+DQo8 Yj5DYzogPC9iPlRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OywgJnF1b3Q7ZHJhZnQtaWV0 Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzQGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1pZXRm LW9hdXRoLXJlc291cmNlLWluZGljYXRvcnNAaWV0Zi5vcmcmZ3Q7LCBvYXV0aCAmbHQ7b2F1dGhA aWV0Zi5vcmcmZ3Q7LCAmcXVvdDtvYXV0aC1jaGFpcnNAaWV0Zi5vcmcmcXVvdDsgJmx0O29hdXRo LWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10g w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2Ut aW5kaWNhdG9ycy0wNTogKHdpdGggQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhhbmsgeW91LCDD iXJpYywgZm9yIHRoZSByZXZpZXcgYW5kIGJhbGxvdCBwb3NpdGlvbi4NCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPk9uIE1vbiwgU2VwIDIsIDIwMTkgYXQgMzo0MCBBTSDDiXJpYyBWeW5ja2Ugdmlh IERhdGF0cmFja2VyICZsdDs8YSBocmVmPSJtYWlsdG86bm9yZXBseUBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm5vcmVwbHlAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPsOJcmljIFZ5bmNrZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxv dCBwb3NpdGlvbiBmb3I8YnI+DQpkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMt MDU6IE5vIE9iamVjdGlvbiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+DQpDT01NRU5UOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+ DQpUaGFuayB5b3UgZm9yIHRoZSBoYXJkIHdvcmsgcHV0IGludG8gdGhpcyBlYXN5IHRvIHJlYWQg ZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5UaGFua3MsIEknbSBoYXBweSB0byBoZWFyIHRoYXQgeW91IGZvdW5kIGl0IHJl YWRhYmxlLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PT0gQ09NTUVOVFMgPT08YnI+ DQo8YnI+DQotLSBTZWN0aW9uIDEgLS08YnI+DQomcXVvdDtoYXMgdW5jb3ZlcmVkIGEgbmVlZCwg aW4gc29tZSBjaXJjdW1zdGFuY2VzJnF1b3Q7IChhbmQgc2ltaWxhciBzZW50ZW5jZXMgaW4gc2Vj dGlvbjxicj4NCjEpLCBpdCBpcyByYXRoZXIgdmFndWUgZm9yIGEgc3RhbmRhcmQgdHJhY2sgZG9j dW1lbnQuLi4gUGxlYXNlIGFkZCBzb21lIGZhY3RzPGJyPg0KYW5kIGRhdGEsIHRoaXMgY291bGQg YmUgYSBjb21wYW5pb24gZG9jdW1lbnQgYWJvdXQgcmVxdWlyZW1lbnRzL3VzZSBjYXNlcy48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlNl YyAxIGlzIGludGVuZGVkIHRvIGJlIGEgZ2VuZXJhbCAodGhvdWdoIG5vdCB2YWd1ZSkgaW50cm9k dWN0aW9uIHdpdGggc29tZSBleHBsYW5hdGlvbiBhYm91dCB3aGF0IGFuIGF1dGhvcml6YXRpb24g c2VydmVyIG1pZ2h0IGJlIGFibGUgdG8gYWNjb21wbGlzaCB3aXRoIGFuIHVuZGVyc3RhbmRpbmcg b2YgdGhlIGxvY2F0aW9uL2lkZW50aXR5IG9mIHRoZSBwcm90ZWN0ZWQNCiByZXNvdXJjZSBmb3Ig d2hpY2ggdGhlIGNsaWVudCBpcyByZXF1ZXN0aW5nIGFuIGFjY2VzcyB0b2tlbi4gV2hpY2ggZWZm ZWN0aXZlbHkgYm9pbHMgZG93biB0byBiZWluZyBhYmxlIHRvIHByb2R1Y2UgdGhlIHRva2VuIGFw cHJvcHJpYXRlIGZvciB0aGUgaW5kaWNhdGVkIHJlc291cmNlIChpbmNsdWRpbmcgdGhlIHR5cGUg b2YgdG9rZW4sIGlmIGFuZCBob3cgaXQncyBlbmNyeXB0ZWQsIHdoYXQgaW5mb3JtYXRpb24gaXMg Y29udGFpbmVkIG9yIHJlZmVyZW5jZWQsDQogdG8gd2hvbSBpdCBpcyBhdWRpZW5jZSByZXN0cmlj dGVkKS4gSSd2ZSBubyBkb3VidCB0aGF0IHRoZSB3cml0aW5nIGNvdWxkIHN0YW5kIHRvIGJlIGlt cHJvdmVkICh3aGljaCBpcyBhbHdheXMgdGhlIGNhc2Ugd2l0aCBjb250ZW50IEkndmUgd3JpdHRl bikgYnV0IHRob3NlIGFyZSB0aGUgdXNlIGNhc2VzIGFuZCBJIGRvbid0IGhhdmUgbW9yZSBzcGVj aWZpYyBmYWN0cyBvciBkYXRhLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGJyPg0K LS0gU2VjdGlvbiAyIC0tPGJyPg0KSXQgaXMgcmF0aGVyIGEgcXVlc3Rpb24gb2YgbWluZSwgd2h5 IGRvZXMgdGhlIHJlc291cmNlIG5lZWQgdG8gYmUgYSBVUkkgKHdoaWNoPGJyPg0KdXN1YWxseSBi ZWFycyBzb21lIHZpc2libGUgc2VtYW50aWNzKSByYXRoZXIgdGhhbiBhbiBvcGFxdWUgc3RyaW5n IGtub3duIG9ubHk8YnI+DQpieSB0aGUgcmVzb3VyY2Ugb3duZXIvc2VydmVyID8gVGhpcyBpcyBz aW1pbGFyIHRvIE1pcmphJ3MgY29tbWVudCBhYm91dCBwcml2YWN5LjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhlIG1vdGl2YXRpb24g YmVoaW5kIHRoZSBkcmFmdCBpcyBsYXJnZWx5IHRvIGZhY2lsaXRhdGUgdGhpcyBleHBsaWNpdCBz aWduYWwgdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIChBUykgYWJvdXQgdGhlIGxvY2F0aW9u IG9yIGlkZW50aXR5IG9mIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UgZm9yIHdoaWNoIHRoZSBjbGll bnQgaXMgcmVxdWVzdGluZyBhbiBhY2Nlc3MNCiB0b2tlbi4gRm9yIHRoZSByZWFzb25zIHByZXZp b3VzbHkgbWVudGlvbmVkLiBTb21ldGhpbmcgdGhhdCdzIG9wYXF1ZSB0byB0aGUgQVMgd291bGQg bmVnYXRlIHRoZSBhYmlsaXR5IG9mIHRoZSBBUyB0byBkbyBtb3N0IG9mIHRoYXQgc3R1ZmYgKGFk bWl0dGVkbHkgbm90IGFsbCBidXQgbW9zdCkuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQo8Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBV SSZxdW90OyxzZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7 cGFkZGluZzowY20iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ug b2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywNCiB1c2UsIGRpc3RyaWJ1 dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiZuYnNw OyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUg bWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFu ayB5b3UuPC9zcGFuPjwvaT48L2I+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_F9495E2053864F128479391A36502C89ciscocom_-- From nobody Wed Sep 4 02:22:03 2019 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 9FC621200CE for ; Wed, 4 Sep 2019 02:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 zeIkoYk4Te0p for ; Wed, 4 Sep 2019 02:21:58 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) (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 7ECBF1200C1 for ; Wed, 4 Sep 2019 02:21:58 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i5RUB-0004ek-9O; Wed, 04 Sep 2019 11:21:55 +0200 From: Torsten Lodderstedt Message-Id: <9468283E-8B97-4DAF-8493-895B475F6BC9@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_0848268D-9965-4BC7-8670-C20BCF71B03B"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 4 Sep 2019 11:21:54 +0200 In-Reply-To: <040dcf9971fd4c618e94b957461d14f2@SV1601507.frd.shsdir.nl> Cc: "oauth@ietf.org" To: "Schaar, R.M. (Remco) - Logius" References: <38503cd44d9e455bad4432d9ba5e82e8@SV1601507.frd.shsdir.nl> <308A4847-6390-4D17-BE52-B604E2428391@lodderstedt.net> <10f13f75c100454aa8092961673541b2@SV1601499.frd.shsdir.nl> <040dcf9971fd4c618e94b957461d14f2@SV1601507.frd.shsdir.nl> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 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: Wed, 04 Sep 2019 09:22:02 -0000 --Apple-Mail=_0848268D-9965-4BC7-8670-C20BCF71B03B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Remco, > On 31. Aug 2019, at 21:27, Schaar, R.M. (Remco) - Logius = wrote: >=20 > Hello Torsten, >=20 > (my apologies for making a typo previously) Thanks :-) >=20 > Time of introspection is critical if you want to use the signed = introspection > response for later accountability or audit purposes. For example, a = Client > obtains an access token A at time t. Now a resource server receives A = at time > t+1, calls introspection and receives a response containing = active=3Dtrue. At > t+2 the acccess token is revoked. At time t+3 the resource server = makes a new > introspection request, now receives a response containing = active=3Dfalse. The > only difference would be the value of the active parameter. Without = the time > of introspection nor a unique id covered by the signature, one cannot = make a > conclusive distinction between subsequent responses if revocation may = be in > play. That=E2=80=99s a good point. =20 >=20 > The draft specifies=20 > [...] to return responses as JWTs. > This could either mean "the response is returned in JWT format" or = "the > response contains a JWT representation of the inspected token=E2=80=9D. I'm meanwhile leaning towards "the response is returned in JWT = format=E2=80=9D. > Not having > clear, separate parameters to distinguish between the time and id of = the > token and the time and id of the response results in double meaning. = As a > consequence, it is either having the risk of replay of an access token = or > replay of an introspection response instead of neither. I=E2=80=99m not sure how an attacker could replay an introspection = response given it is tighted to a certain endpoint via the iss claim.=20 I agree the RS lacks a way to proof when it was provided with the access = token data by the AS.=20 The problem in my opinion is the overlay between the original access = token data (e.g. when was it issued by the AS) and the data belonging to = the representation in the introspection response (when was the response = created). Conceptually, this means we require two separat =E2=80=9Ciat" = (alike) claims to distinguish both aspects.=20 I could image two ways to handle this: - add another iat claim, e.g. =E2=80=9Ctir_iat", to the JWT - add another =E2=80=9Ciat" claim to the JWS header containing the = instant when the token introspection response was created What do you think? best regards, Torsten.=20 >=20 > Kind regards, > Remco schaar >=20 > -----Oorspronkelijk bericht----- > Van: Torsten Lodderstedt =20 > Verzonden: woensdag 28 augustus 2019 11:14 > Aan: Schaar, R.M. (Remco) - Logius > CC: oauth@ietf.org > Onderwerp: Re: [OAUTH-WG] Question regarding = draft-ietf-oauth-jwt-introspection-response-05 >=20 > Hi Rhemco, >=20 >> On 26. Aug 2019, at 09:42, Schaar, R.M. (Remco) - Logius = wrote: >>=20 >> Hello Thorsten, >>=20 >> Thank you for your response. I have a few more questions/comments as >> follow-up... >>=20 >> You state that RFC7519 and RFC7662 "just" define different = representations >> for token data. If the draft RFC would refer to RFC 7515 (JWS), I = would >> agree. However, RFC7519 (JWT) explicitly adds semantics to some = specific >> parameters (e.g. aud, jti and iat). RFC7662 has different semantics = for >> the several of the same parameters. >> For instance the 'iat', is the moment of issuance of the JWT in = RFC7519. In >> RFC7662 that is the "when this token was originally issued". This = time will >> vary in use cases without immediate introspection of an access token. >=20 > I read the text differently. In my interpretation =E2=80=9Cwhen the = token was originally issued=E2=80=9D stated from the perspective of the = introspection endpoint refers exactly to the same instant as =E2=80=9Cthe = time at which the JWT was > issued=E2=80=9D. >=20 >>=20 >> For the use case of the resource server relying on verifiable data, = as >> described in the introduction of the draft RFC, the time of the = introspection >> is critical. >=20 > Why is this time critical? >=20 >> In particular when combined with revocation, the time of >> introspection and the 'active' status can differ between two = subsequent calls >> for introspection. >=20 > The status at token introspection request time is indeed critical. RFC = 7662 gives a good indication how this value should be calculated. >=20 > =E2=80=9C=E2=80=A6 a "true" > value return for the "active" property will generally indicate > that a given token has been issued by this authorization server, > has not been revoked by the resource owner, and is within its > given time window of validity (e.g., after its issuance time and > before its expiration time)."=20 >=20 > So it represents the results of the issuer check, the revocation check = and the validity check in one boolean value.=20 >=20 >>=20 >> If the draft RFC just produces a JWT representation of the access = token, >> including 'active' would not make sense as the JWT will expire = without >> updating it to false. Leaving 'active' out would make it incompatible = with >> RFC7662 introspection responses. >=20 > =E2=80=9Cactive=E2=80=9D is not part of the JWT representation I = referred to. The AS needs to determine the active value for every token = introspection request.=20 >=20 > If the RS would consume JWTs, it would determine the =E2=80=9Cactive=E2=80= =9D value itself by inspecting the iss claim and check against its AS = whitelist, check the signature and the iat & exp values. Determining the = revocation status would require an information exchange with the AS of = some sort.=20 >=20 >> Similar, not including a unique 'jti' per introspection response = would make >> the resource server vulnerable to replay attacks. >=20 > To the contrary, including a different =E2=80=9Cjit" with every token = introspection response would make the RS vulnerable to replay of one = time access token since it remove the possibility for the RS to identity = a certain access token.=20 >=20 >> Or the resource server >> would mistakenly refer to non-unique tokens, making the responses = unsuitable >> for accountability and audit purposes. >>=20 >>=20 >> As to why someone would want to distinguish a JWT access token from = an >> introspection response: several use cases come to mind. >>=20 >> First of all, even if one is using standalone interpretable JWT = access tokens, >> one may want to combine that with revocation checking using = introspection. The >> interpretation and meaning of the JWT and the introspection response = than do >> differ and matter. >=20 > As I described above, I don=E2=80=99t see any difference.=20 >=20 >>=20 >> Another use case would be a mixed ecosystem with resource servers = relying on >> introspection while others do parse JWT access tokens. A single, = uniform >> implementation for the AS would than mix both as well. >=20 > See above - I don=E2=80=99t see any issue.=20 >=20 >>=20 >> A last use case could be exchanging access tokens with a subset of = the full >> set of applicable parameters, to reduce the size of access tokens. = Additional >> information can be exchanged via introspection, resulting in mixed = JWT access >> tokens and introspection as well. >=20 > That=E2=80=99s all possible within the current text.=20 >=20 > kind regards, > Torsten=20 >=20 >>=20 >> Kind regards, >> Remco Schaar >>=20 >> -----Oorspronkelijk bericht----- >> Van: Torsten Lodderstedt =20 >> Verzonden: zaterdag 17 augustus 2019 14:00 >> Aan: Schaar, R.M. (Remco) - Logius >> CC: oauth@ietf.org >> Onderwerp: Re: [OAUTH-WG] Question regarding = draft-ietf-oauth-jwt-introspection-response-05 >>=20 >> Hi Remco, >>=20 >>> On 6. Aug 2019, at 16:01, Schaar, R.M. (Remco) - Logius = wrote: >>>=20 >>> Hello, >>=20 >> [...] >> RFC 7519 and RFC 7662 =E2=80=9Cjust=E2=80=9D define different = representations for token data. In RFC 7519 the data is carried in the = token itself (which also means the format of the token is well-defined = and know to the RS) whereas RFC 7662 defines a way to inspect tokens via = an API provided by the AS. The latter is typically used in conjunction = with opaque tokens, i.e. the RS does not have a clue how to parse and = interpret the token. The token might just be a handle to a database = entry at the AS in this case.=20 >>=20 >> This also means a JWT (RFC 7662) and the Introspection Response are = conceptually the same from a RSs perspective. >>=20 >> [...] >>=20 >>> The =E2=80=98jti=E2=80=99 parameter however will always be = ambiguous. As it is an identifier, it should differ for the introspected = token and the introspection response by definition. Hence the semantics = of =E2=80=98jti=E2=80=99 in a JWT introspection response is unclear. The = same can apply to the =E2=80=98iat=E2=80=99, =E2=80=98nbf=E2=80=99 and = =E2=80=98exp=E2=80=99 claims in a JWT introspection response. >>=20 >> I don=E2=80=99t understand the difference you are making. All before = mentioned claims are related to the (abstract) access token. You may = think of the Introspection Response as _the_ JWT representation of the = access token produced by the AS for the RS. >>=20 >>>=20 >>> Can someone clarify the semantics of claims in an introspection = response JWT that are defined in both RFC7662 and RFC7519? >>>=20 >>> Furthermore, the introspection response should use the =E2=80=98iss=E2= =80=99 and =E2=80=98aud=E2=80=99 claims to avoid cross-JWT confusion = (section 6.1). The =E2=80=98iss=E2=80=99 and =E2=80=98aud=E2=80=99 of an = introspected token will typically be the same as those of the = introspection response. Hence a JWT access token cannot be distinguished = from an introspection response using =E2=80=98iss=E2=80=99 and =E2=80=98au= d=E2=80=99 as suggested in the draft.. >>>=20 >>> Introspection refers to JWT best-current-practice. The draft BCP = recommends using explicit typing of JWTs, however the draft JWT response = for introspection does not apply this recommendation and uses the = generic =E2=80=98application/jwt=E2=80=99 instead... The BCP has other = recommendations in section 3.12, but these may be insufficient to = distinguish a JWT access token from a JWT introspection response. >>=20 >> Good point. The reason why the BCP recommends explicit typing is to = prevent replay in other contexts. In the end typing is a compelling = concept unfortunately not broadly used in the wild. >>=20 >> So the JWT Introspection Response draft copes with that attack angle = by making iss and aud mandatory.=20 >>=20 >>=20 >>>=20 >>> How would people suggest to best distinguish a JWT (access) token = from a JWT introspection response? >>=20 >> Why should you? One reason why we extended the Introspection Response = was to eliminate the difference between JWTs directly used as access = tokens and Introspection Responses. >>=20 >> best regards, >> Torsten.=20 >>=20 >>=20 >> Dit bericht kan informatie bevatten die niet voor u is bestemd. = Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is = toegezonden, wordt u verzocht dat aan de afzender te melden en het = bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor = schade, van welke aard ook, die verband houdt met risico's verbonden aan = het elektronisch verzenden van berichten. >> This message may contain information that is not intended for you. If = you are not the addressee or if this message was sent to you by mistake, = you are requested to inform the sender and delete the message. The State = accepts no liability for damage of any kind resulting from the risks = inherent in the electronic transmission of messages. >=20 --Apple-Mail=_0848268D-9965-4BC7-8670-C20BCF71B03B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA5MDQwOTIxNTRaMC8GCSqGSIb3DQEJBDEiBCArBFi7fcggqeUZa5MFwz/vi+8mNR3KVQyn sTcCD/DjizCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAAbtvx8xVWYqK9vnpn407HdEK0UVblFqvR3YdXHamVYPLQEOpbNQx0gro8Sm sEqvzxuNUvWx9UT0DxAfRkeU35+5TSytGmUTD90FfAtITsK77o5+YOWVmPt68Ia1CYnd5G+sNt7D xzJajk+AeEBW/+aY/dSQOOHZuX0ZaHskXJZyFCM7ud24BrnDWKBmnZcUX10paD+jDmW4g/T81agv biaKBiipTiF6xbWWxtLmNAbgskIfxfWr4YpID5dRo+4HAmBXiYQjhgJPUUqCIEz8/U1FJUVg4aqL eOHh4Ez5ZcW0T/TvgqPgUwGWklqShNurFqwlHm+hoakCm3BERnKXPd0AAAAAAAA= --Apple-Mail=_0848268D-9965-4BC7-8670-C20BCF71B03B-- From nobody Wed Sep 4 07:36:18 2019 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 9A2E112000F; Wed, 4 Sep 2019 07:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=JpHarL9U; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zUEcJZzL 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 0z-Aa9y5rMUd; Wed, 4 Sep 2019 07:36:04 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E651120046; Wed, 4 Sep 2019 07:36:04 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D4C5A21EB2; Wed, 4 Sep 2019 10:36:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 04 Sep 2019 10:36:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=UW8MukcU95oajC0iZoFn2uy snAydOQgCAN6OAuiKVTg=; b=JpHarL9UVJCRU6B87EJkeR0X1/T1xagzNLQWZzp 07iQ1JNmBIDxI2srlX0Ticg/yhT7J2YBOojwYlQWSB6VHOKRtuJLJrs6i4mLxA/u pjOJRg5nQ5JAoihZOfVpVDhvqj4n0aoZAU+a2LDIjMMoDQ4a9oqV7N7RLGu7lKMx TddLtOLzpLh81BcMYYF8hpe6IgiruXYnevcFMM8PYi3eOrfP4Gwd2GnVS+ZoFFtx uVNZIMBhFKLzeNmqGu4qIRjP4k/Ss4Fv+VNz2D6mGWZ1pV6Md/Fp06bntxjo/8Xr Ky9LFAGQV3TxGtCNaSLFRreRDY5LdRj7nJOi9sW70LaLLGQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=UW8Muk cU95oajC0iZoFn2uysnAydOQgCAN6OAuiKVTg=; b=zUEcJZzLVvBoZuDZsBnofS hGdrhD5oFhAQhww7gXwcA/tpOlmEVXmpCDMXy7YaPTJOIDs+6spMLu8R6krd07zA LaneEcDnlRGqzfyNbCnvV+XVRcGdldsYhsFEUuM3uP1x5CXrPgrcKHFqGJPzmxuv JwJ0NewG0uXDd0Vtn3cw8dxKU6KOU4ovpPrTw8PCsfBHHplRAdnXbmWw0101WcRv QCxLUXn1SfkmikkmpDNlwLcAtpeWflb7ai1mwKqxgpu1TivaaTkY3qECrcjYbUtn VB2IMRCga+xpwyJ6yYDcFwy7xiAR5EONLxWnKgOewg1FXDGGO6ukwjUPni0BFcLw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudejhedgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdejgeenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.74]) by mail.messagingengine.com (Postfix) with ESMTPA id E652280064; Wed, 4 Sep 2019 10:36:02 -0400 (EDT) From: Alissa Cooper Message-Id: <555297A0-FED2-48DF-9191-10B3EF654B53@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_DEC0DC29-D496-4663-9AD5-A348000326B8" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 4 Sep 2019 10:36:01 -0400 In-Reply-To: Cc: draft-ietf-oauth-resource-indicators.all@ietf.org, gen-art , IETF discussion list , oauth To: Brian Campbell , Stewart Bryant References: <156450808245.14321.11139106487161414680@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [OAUTH-WG] [Gen-art] Genart last call review of draft-ietf-oauth-resource-indicators-05 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: Wed, 04 Sep 2019 14:36:08 -0000 --Apple-Mail=_DEC0DC29-D496-4663-9AD5-A348000326B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Stewart, thanks for your review. Brian, thanks for the fix. I=E2=80=99ve = entered a No Objection ballot. Regards, Alissa > On Aug 13, 2019, at 2:43 PM, Brian Campbell = wrote: >=20 > Thanks for the review Stewart and my apologies for the slow response - = I left on a longish summer family vacation the day before the review = email hit my inbox. >=20 > I've fixed the nit by using "JSON Web Token (JWT)" on that first use = in the source controlled editor's xml version and it'll show up in the = next draft revision. > =20 >=20 > On Tue, Jul 30, 2019 at 11:35 AM Stewart Bryant via Datatracker = > wrote: > Reviewer: Stewart Bryant > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > >. >=20 > Document: draft-ietf-oauth-resource-indicators-05 > Reviewer: Stewart Bryant > Review Date: 2019-07-30 > IETF LC End Date: 2019-08-05 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: A well written document ready for publication. It has one = very minor > nit that needs to be addressed at some point. >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: JWT is not in the well known list and does = not seem > to be expanded on first use, >=20 >=20 >=20 > 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._______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_DEC0DC29-D496-4663-9AD5-A348000326B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Stewart, thanks for your review. Brian, thanks for the fix. = I=E2=80=99ve entered a No Objection ballot.

Regards,
Alissa

On Aug 13, 2019, at 2:43 PM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

Thanks for the review Stewart and = my apologies for the slow response - I left on a longish summer family = vacation the day before the review email hit my inbox.

I've fixed the nit by = using "JSON Web Token (JWT)" on that first use in the source controlled = editor's xml version and it'll show up in the next draft = revision.
 

On Tue, Jul 30, 2019 at 11:35 AM Stewart Bryant via = Datatracker <noreply@ietf.org> wrote:
Reviewer: Stewart Bryant
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments = just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-oauth-resource-indicators-05
Reviewer: Stewart Bryant
Review Date: 2019-07-30
IETF LC End Date: 2019-08-05
IESG Telechat date: Not scheduled for a telechat

Summary: A well written document ready for publication.  It has one = very minor
nit that needs to be addressed at some point.

Major issues: None

Minor issues: None

Nits/editorial comments:  JWT is not in the well known list and = does not seem
to be expanded on first use,



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._______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_DEC0DC29-D496-4663-9AD5-A348000326B8-- From nobody Wed Sep 4 07:50:54 2019 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 316401201EA for ; Wed, 4 Sep 2019 07:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 vOZDaAfmCKiV for ; Wed, 4 Sep 2019 07:50:29 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 44C3212021D for ; Wed, 4 Sep 2019 07:50:17 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id f12so27293656iog.12 for ; Wed, 04 Sep 2019 07:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FSZMbxSKjqpAaFUgZUwuV139PKS+aMz733G8zIQL41M=; b=lMX9tn1xcIIW6fYZkKuFhRO2KY+bwy6XZzh1vvJrDQeSMu+OI1Unefbbit1+/IMdmz xfeHkGJ5UWZNxTYHe0stN2ICZklwHhKJ+28dK7+wdJ0X3EbviFzFTabWtra34GyZC/rb 4WyQp6zW3TP+RXCPxBs7moaU7t6z2TWMMvj+0= 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=FSZMbxSKjqpAaFUgZUwuV139PKS+aMz733G8zIQL41M=; b=P08Gr8WDrt9AzxUn0cpsq/YjuukQGTECSnYMveycgwiZTzrPY3Yt8A5O9Phdbs30Rb CoPTpygkEujl80y8+6So/3bCirH5nATMPzYnxwK8Y5/BLONYgD5baMbwn0bBBBBdN2qW 57jBkahf1pzUvZCcSQCfqOVHJyyJYLc9UqqO+dQtksqUCOFABFmuLmu34G61xPNog4xs FOCdPlLqs/AJBWei6/Y3g6wW140tUDRl2LrIwS4RPrMw9td4bV+R1L+4ZxOebTZ2luwv wW3D2MkX/wHl3yOIuRj5cgIeSVQD7LvnXgTiifJ0bdNzbQEtzCNkCtgJO9edEtR5Nz13 ttoQ== X-Gm-Message-State: APjAAAV0/00Z1zA3bNLRlN+vaX36ZruVsK36mEU0Jr9MiViwAnjK7hcg uZFM2uU3pHF5OrMhTouPKzpn8AYtf/5AkE81L2vg/fR3L59WjDdg7iUU8da6Q/AyEGEalTNQfFf taNfkhmh8Y0NqrA== X-Google-Smtp-Source: APXvYqx7gVCOpBycjvaZq6dY61SfoYLilQYWAVuSLdRlVD10rBzLOIgqf5fK1qYKQhv799Ley9sf06CmrsolAzvP+xw= X-Received: by 2002:a02:781c:: with SMTP id p28mr25920435jac.91.1567608616405; Wed, 04 Sep 2019 07:50:16 -0700 (PDT) MIME-Version: 1.0 References: <156450808245.14321.11139106487161414680@ietfa.amsl.com> <555297A0-FED2-48DF-9191-10B3EF654B53@cooperw.in> In-Reply-To: <555297A0-FED2-48DF-9191-10B3EF654B53@cooperw.in> From: Brian Campbell Date: Wed, 4 Sep 2019 08:49:49 -0600 Message-ID: To: Alissa Cooper Cc: Stewart Bryant , draft-ietf-oauth-resource-indicators.all@ietf.org, gen-art , IETF discussion list , oauth Content-Type: multipart/alternative; boundary="000000000000ba77a80591bb524a" Archived-At: Subject: Re: [OAUTH-WG] [Gen-art] Genart last call review of draft-ietf-oauth-resource-indicators-05 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: Wed, 04 Sep 2019 14:50:41 -0000 --000000000000ba77a80591bb524a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Alissa! On Wed, Sep 4, 2019 at 8:36 AM Alissa Cooper wrote: > Stewart, thanks for your review. Brian, thanks for the fix. I=E2=80=99ve = entered a > No Objection ballot. > > Regards, > Alissa > > On Aug 13, 2019, at 2:43 PM, Brian Campbell < > bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote: > > Thanks for the review Stewart and my apologies for the slow response - I > left on a longish summer family vacation the day before the review email > hit my inbox. > > I've fixed the nit by using "JSON Web Token (JWT)" on that first use in > the source controlled editor's xml version and it'll show up in the next > draft revision. > > > On Tue, Jul 30, 2019 at 11:35 AM Stewart Bryant via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Stewart Bryant >> Review result: Ready >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-oauth-resource-indicators-05 >> Reviewer: Stewart Bryant >> Review Date: 2019-07-30 >> IETF LC End Date: 2019-08-05 >> IESG Telechat date: Not scheduled for a telechat >> >> Summary: A well written document ready for publication. It has one very >> minor >> nit that needs to be addressed at some point. >> >> Major issues: None >> >> Minor issues: None >> >> Nits/editorial comments: JWT is not in the well known list and does not >> seem >> to be expanded on first use, >> >> >> > *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 sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000ba77a80591bb524a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Alissa!

On Wed, Sep 4, 2019 at 8:36 AM Alissa Co= oper <alissa@cooperw.in> wro= te:
Stewart, thanks for your review. Brian, tha= nks for the fix. I=E2=80=99ve entered a No Objection ballot.

=
Regards,
Alissa

O= n Aug 13, 2019, at 2:43 PM, Brian Campbell <bcampbell=3D40pingi= dentity.com@dmarc.ietf.org> wrote:

Thanks fo= r the review Stewart and my apologies for the slow response - I left on a l= ongish summer family vacation the day before the review email hit my inbox.=

I've fixed the nit by using "JSON Web To= ken (JWT)" on that first use in the source controlled editor's xml= version and it'll show up in the next draft revision.
=C2=A0=

On Tue, Jul 30, 2019 at 11:35 AM Stewart Bryant via Datatracker <noreply@ietf.org>= ; wrote:
Reviewe= r: Stewart Bryant
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq&g= t;.

Document: draft-ietf-oauth-resource-indicators-05
Reviewer: Stewart Bryant
Review Date: 2019-07-30
IETF LC End Date: 2019-08-05
IESG Telechat date: Not scheduled for a telechat

Summary: A well written document ready for publication.=C2=A0 It has one ve= ry minor
nit that needs to be addressed at some point.

Major issues: None

Minor issues: None

Nits/editorial comments:=C2=A0 JWT is not in the well known list and does n= ot seem
to be expanded on first use,



CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited..=C2=A0 If you have received this communication in er= ror, please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank you.__= _____________________________________________
Gen-art mailing list
Gen-art@ietf.orghttps://www.ietf.org/mailman/listinfo/gen-art
<= /div>

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000ba77a80591bb524a-- From nobody Wed Sep 4 08:49:50 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5AD12087D; Wed, 4 Sep 2019 08:49:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwt-introspection-response@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <156761217998.22726.10487913212091468494.idtracker@ietfa.amsl.com> Date: Wed, 04 Sep 2019 08:49:39 -0700 Archived-At: Subject: [OAUTH-WG] Alissa Cooper's No Objection on draft-ietf-oauth-jwt-introspection-response-07: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2019 15:49:40 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Benjamin's DISCUSS point about the IESG being listed as the change controller for the registry entries. Overall I'd like to understand better the relationship between these registry entries and future updates to OpenID Connect (i.e., if the claims in the OpenID spec change, will this registry automatically need to change as well?). I also support Adam's DISCUSS. How are claims like preferred_username currently used for the described use case of verifying person data to create certificates? If the linkage with the OpenID Connect 1.0 claims remains in the document, I think it would be good to add a note in Section 1.1 or a new Section 1.2 to indicate that the document uses terminology as defined in that spec (e.g., "End-User," "Relying Party," etc.). From nobody Wed Sep 4 08:51:10 2019 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 AFB58120898; Wed, 4 Sep 2019 08:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=MnfRHbXP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PlHh/mKs 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 EIS_s_BuGfrL; Wed, 4 Sep 2019 08:50:51 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1731208B1; Wed, 4 Sep 2019 08:50:51 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B70C521E92; Wed, 4 Sep 2019 11:50:50 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 04 Sep 2019 11:50:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=z WTsOtfnj+WOzBS5V1chp5vNvWjgrG++K+DvsFq/I+Q=; b=MnfRHbXPjmSOcPOYK UwHSQKa0a40y1UYQvKx3Ai8tX9u2wP17eKbJH571NRRZZyqlB6VkMqbezxaZFMst 26uzz3A8ve2VHewaGTKDL0/emUM4VFo5dup8LLZRuMi/71PMV/LciPFE4VVc26XD vY3NSOEgXB3iIIm1XpUix760xeFcLRQALVVTLfAHfyUzp2rkk7Zj2wYtESv4NA6r uoBVL+uQsek3X6ZtexorYQShQork7l3kELdmAmtWZ4572BDcQUFwGj1JYnjTe+tt ikUoQz+k4qPMOjDdkYyb6v/4jOQ0ZBFML7l8CmnGoRMj6jcsSWz2g0S1AUfZsIhI U+VjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=zWTsOtfnj+WOzBS5V1chp5vNvWjgrG++K+DvsFq/I +Q=; b=PlHh/mKs7nBx4u7bVDJX6V7z8BxCrMQaLRxyFZM943Jr2vI4FTAmuG32n QJKFryZVreO8rZ7Fh6IeUtS4yf4+r6RjyPVzF85sRnLKbwhrbniWVlZqSTEQrDa3 Z8eOhO8gSZtjvq1YJX5Pq7K8x/TR80fl+Pt4+Nrh4il5RmvChQzF7nCVK8l2/4f1 YU0g10Clx/cJHEQ+Gf5xhCOAxU1Tdb2TQaTK/rn7ITqP3PA5Mx3eluy5X2ZUWgkR 2oo/W24mWHc5/5bDiFXYWbf2PqsybtUcJIKytROwOygTAcGC2JAKrMULkCd+N/QX 6+Y+6JgZHbTUnh6dGNqDbzJrdNkaw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudejhedgleduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrjeegnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.74]) by mail.messagingengine.com (Postfix) with ESMTPA id B8C23D60062; Wed, 4 Sep 2019 11:50:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <156504017769.2046.13239300457018910370@ietfa.amsl.com> Date: Wed, 4 Sep 2019 11:50:48 -0400 Cc: gen-art , draft-ietf-oauth-jwt-introspection-response.all@ietf.org, ietf@ietf.org, oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156504017769.2046.13239300457018910370@ietfa.amsl.com> To: Linda Dunbar X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [OAUTH-WG] [Gen-art] Genart last call review of draft-ietf-oauth-jwt-introspection-response-05 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: Wed, 04 Sep 2019 15:51:01 -0000 Linda, thank you for your review. I have entered a No Objection ballot. Alissa > On Aug 5, 2019, at 5:22 PM, Linda Dunbar via Datatracker = wrote: >=20 > Reviewer: Linda Dunbar > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-oauth-jwt-introspection-response-05 > Reviewer: Linda Dunbar > Review Date: 2019-08-05 > IETF LC End Date: 2019-08-07 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: > This draft specifies an additional JSON Web Token (JWT) based response = for > OAuth 2.0 Token Introspection, specify the signed JWT and signed & = encrypted > JWT response. The document has very thorough analysis from many = aspects in the > security consideration section. >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Sep 4 12:49:23 2019 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 030A9120D0B for ; Wed, 4 Sep 2019 12:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 aN41tXlVm0hM for ; Wed, 4 Sep 2019 12:49:18 -0700 (PDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (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 9A1A0120CA2 for ; Wed, 4 Sep 2019 12:49:17 -0700 (PDT) Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id x84JnCCb029635; Wed, 4 Sep 2019 15:49:16 -0400 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 4 Sep 2019 15:49:15 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 4 Sep 2019 15:49:06 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Wed, 4 Sep 2019 15:49:06 -0400 From: Justin Richer To: Torsten Lodderstedt CC: "Schaar, R.M. (Remco) - Logius" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 Thread-Index: AdVMX0zd8VJvxu//SVaPc8ibBp8OiQItX6sAAbumHoAAZ8QBgACsTdKAALQDLwAAFeebAA== Date: Wed, 4 Sep 2019 19:49:06 +0000 Message-ID: <9F5DA44D-BD3C-43B2-A88C-66394BD7BE85@mit.edu> References: <38503cd44d9e455bad4432d9ba5e82e8@SV1601507.frd.shsdir.nl> <308A4847-6390-4D17-BE52-B604E2428391@lodderstedt.net> <10f13f75c100454aa8092961673541b2@SV1601499.frd.shsdir.nl> <040dcf9971fd4c618e94b957461d14f2@SV1601507.frd.shsdir.nl> <9468283E-8B97-4DAF-8493-895B475F6BC9@lodderstedt.net> In-Reply-To: <9468283E-8B97-4DAF-8493-895B475F6BC9@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_9F5DA44DBD3C43B2A88C66394BD7BE85mitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 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: Wed, 04 Sep 2019 19:49:22 -0000 --_000_9F5DA44DBD3C43B2A88C66394BD7BE85mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgSeKAmXZlIHNhaWQgaW4gdGhlIHBhc3QsIEkgdGhpbmsgdGhlcmUgaXMgYW5kIHNob3VsZCBi ZSBhIGNsZWFyIGRpZmZlcmVuY2UgYmV0d2VlbiBhIEpXVCBhY2Nlc3MgdG9rZW4gYW5kIGEgSldU LWZvcm1hdHRlZCByZXNwb25zZSBmcm9tIGFueSBlbmRwb2ludC4gSXQgZ2V0cyBleHRyYSBmdXp6 eSBoZXJlIGJlY2F1c2UgdGhlIHJlc3BvbnNlIGZyb20gdGhlIGVuZHBvaW50IHJlcHJlc2VudHMg dGhlIHRva2VuIGJlaW5nIGludHJvc3BlY3RlZC4NCg0KSG93ZXZlciwgSSB0aGluayB0aGV5IGFy ZSBzdGlsbCB0d28gdmVyeSBkaWZmZXJlbnQgdGhpbmdzIGJlY2F1c2UgdGhlIGludHJvc3BlY3Rp b24gcmVzcG9uc2UgYnkgZGVmaW5pdGlvbiByZXByZXNlbnRzIHdoYXQgdGhlIHRva2VuIHdhcyBh dCB0aGUgdGltZSBvZiBpbnRyb3NwZWN0aW9uLiBUaGF04oCZcyB3aHkgdGhlIOKAnGFjdGl2ZeKA nSBjbGFpbSBpcyBpbXBvcnRhbnQgaGVyZSwgYWxvbmcgd2l0aCB0aGUgdGltZXN0YW1wIGluZm9y bWF0aW9uIGluIHRoZSBKV1QgY29udGFpbmVyIOKAlCB5b3UgY2FuIHNheSB0aGF0IHRoZSB0b2tl biAqd2FzKiBhY3RpdmUgYXQgdGhlIHRpbWUgb2YgaW50cm9zcGVjdGlvbiwgYnV0IHlvdSBjYW7i gJl0IHNheSBpdOKAmXMgc3RpbGwgYWN0aXZlIHdpdGhvdXQgaW50cm9zcGVjdGluZyB0aGUgdG9r ZW4gYWdhaW4gdG8gY2hlY2suIFRoaXMgbGVhZHMgdG8gZXhhY3RseSB0aGUga2luZCBvZiBjb2xs aXNpb24gdGhhdOKAmXMgYmVpbmcgZGlzY3Vzc2VkIGhlcmUuIEl04oCZcyBjb25mdXNpbmcgZm9y IGRldmVsb3BlcnMgb2YgYm90aCB0aGUgQVMgYW5kIHRoZSBSUywgYW5kIEkgZmVhciBpdOKAmXMg Z29pbmcgdG8gbGVhZCB0byBhbiBBUyBjaG9vc2luZyBvbmUgaW50ZXJwcmV0YXRpb24gYW5kIGFu IFJTIGNob29zaW5nIGFub3RoZXIsIGFuZCB0aGVyZWZvcmUgbGVhdmluZyBvcGVuIGEgZG9vciB0 byBzZWN1cml0eSBpc3N1ZXMgZG93biB0aGUgcm9hZC4NCg0KQWxzbywgcmVtZW1iZXIgb25lIG9m IHRoZSBtYWluIHJlYXNvbnMgdGhhdCB3ZSByZXF1aXJlIHNvbWUgZm9ybSBvZiBSUyBhdXRoZW50 aWNhdGlvbiB0byB0aGUgdG9rZW4gZW5kcG9pbnQgaXMgdGhhdCBkaWZmZXJlbnQgUlPigJlzIGNh biBnZXQgZGlmZmVyZW50IGFuc3dlcnMgZm9yIHRoZSBzYW1lIHRva2VuLiBUaGUgQVMgY2FuIHRh aWxvciBpdHMgcmVzcG9uc2UgYmFzZWQgb24gd2hhdCBzY29wZXMgdGhlIFJTIGlzIHN1cHBvc2Vk IHRvIGtub3cgYWJvdXQsIG9yIHdoaWNoIFJT4oCZcyBjYW4ga25vdyBhIHVzZXLigJlzIGlkZW50 aWZpZXIgKG9yIGV2ZW4gdXNlIHBhaXJ3aXNlIGlkZW50aWZpZXJzKSwgb3IgZXZlbiB3aGljaCBS UyBpcyBzdXBwb3NlZCB0byBrbm93IGFib3V0IGEgZ2l2ZW4gdG9rZW4gYXQgYWxsLiBJbiBlYWNo IG9mIHRoZXNlIGNhc2VzLCB1c2luZyB0aGlzIGRyYWZ0LCB5b3XigJlsbCBnZXQgYSBkaWZmZXJl bnQgSldUIG91dCBmb3IgdGhlIHNhbWUgdG9rZW4gb24gdGhlIHdheSBpbi4gWW914oCZcmUgbm90 IHNpbXBseSB0cmFuc2xhdGluZyBhbiBhY2Nlc3MgdG9rZW4gdG8gYW5vdGhlciBhY2Nlc3MgdG9r ZW4gaGVyZSDigJQgaWYgeW91IHdhbnQgdG8gZG8gdGhhdCwgdXNlIHRva2VuIGV4Y2hhbmdlIGFu ZCBkbyBpdCBwcm9wZXJseSB3aXRoIGFuIE9BdXRoIGdyYW50LiBJbnN0ZWFkLCB5b3XigJlyZSBn ZXR0aW5nIGluZm9ybWF0aW9uIGFib3V0IHRoZSB0b2tlbiBpdHNlbGYgYXQgdGhlIHRpbWUgb2Yg dGhlIHJlcXVlc3QgYW5kIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSByZXF1ZXN0b3IsIGFu ZCB5b3UgaGFwcGVuIHRvIGJlIHdyYXBwaW5nIHRoZSByZXNwb25zZSBpbiBhIGNvbnRhaW5lciB0 aGF0IGlzIGFsc28gd2lkZWx5IHVzZWQgdG8gZm9ybWF0IGFjY2VzcyB0b2tlbnMuDQoNClRoZSBz ZXBhcmF0aW9uIHRoYXQgVG9yc3RlbiBwb2ludHMgb3V0IGJlbG93IGJyaW5ncyB1cCBvbmUgb2Yg dGhlIGJpZ2dlc3QgcHJvYmxlbXMgd2l0aCBKV1RzIGFzIGEgZGF0YSBjb250YWluZXIgZm9ybWF0 IOKAlCBhbGwgdGhlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBKV1QgaXRzZWxmIGlzIG1peGVkIGlu IHdpdGggdGhlIHRoaW5nIGl04oCZcyBjYXJyeWluZyBpbmZvcm1hdGlvbiBhYm91dC4gV2Ugc2Vl IHRoaXMgaXNzdWUgd2l0aCBKQVIsIHdoZXJlIHRoZSDigJxhdWTigJ0gcGFyYW1ldGVyIGNhbiBt ZWFuIHRoZSBhdWRpZW5jZSBvZiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGFuZCB0aGUgYXVk aWVuY2Ugb2YgdGhlIEpXVCB1c2VkIHRvIGNhcnJ5IHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3Qu IFdlIGFsc28gc2VlIHRoaXMgYSBsaXR0bGUgYml0IGluIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJh dGlvbuKAmXMgc29mdHdhcmUgc3RhdGVtZW50LiBSb290LWxldmVsIEpXVCBjbGFpbXMgYXJlIGEg cG9vciBtZWNoYW5pc20gZm9yIHRoaXMuDQoNCkluIHJldHJvc3BlY3QsIHdoYXQgSSB3aXNoIHdl 4oCZZCBkb25lIHdpdGggYWxsIG9mIHRoZW0gdXNpbmcgYSBuYW1lZCBwYXlsb2FkIGxpa2Ugd2l0 aCBTRVTigJlzIOKAnGV2ZW504oCdIGNsYWltLiBFdmVuIHRoZXJlLCB3ZSBoYWQgYSBsb3Qgb2Yg YXJndW1lbnQgYWJvdXQgYSDigJxzdWLigJ0gY2xhaW0gaW5zaWRlIHRoZSDigJxldmVudOKAnSBv YmplY3QgdnMuIG9uZSBhdCB0aGUgcm9vdCBvZiB0aGUgSldUIGNvbnRhaW5lciwgYnV0IGF0IGxl YXN0IGluIHRoZXNlIGNhc2VzICB3ZSBub3cgaGFkIGFuIG9wcG9ydHVuaXR5IHRvIHdyaXRlIGNs ZWFyIGxhbmd1YWdlIGFib3V0IHdoYXQgZWFjaCBtZWFudCBpbiBlYWNoIGNpcmN1bXN0YW5jZS4g SSByZWFsaXplIHRoaXMgZHJhZnQgaXMgYWxyZWFkeSB3ZWxsIGFsb25nIGluIGl0cyBwcm9jZXNz LCBhbmQgSSBoYXZlbuKAmXQgcHV0IGluIHRoZSByZXZpZXcgdGltZSBvciBjb21tZW50cyB0byBk YXRlIG15c2VsZiwgYnV0IEkgdGhpbmsgaXTigJlzIHVuZm9ydHVuYXRlIHRoYXQgdGhlIGRyYWZ0 IGRvZXNu4oCZdCBkZWZpbmUgYSBzdWItY2xhaW0gbGlrZSDigJxhY2Nlc3NfdG9rZW7igJ0gb3Ig 4oCcdG9rZW5faW5mb3JtYXRpb27igJ0gdG8gY2FycnkgaW5zaWRlIHRoZSBKV1QgcGF5bG9hZC4g VGhpcyB3b3VsZCBzb2x2ZSB0aGUgcHJvYmxlbSBvZiBkaWZmZXJlbnRpYXRpbmcgdGhlIOKAnGlh dOKAnSBmb3IgdGhlIHRva2VuIGl0c2VsZiB2cy4gdGhlIEpXVCBjb250YWluZXIgb2YgdGhlIHJl c3BvbnNlLg0KDQpUaGUgZ3JvdXAgbWF5IGFsc28gcmVjYWxsIHRoYXQgSSBvcmlnaW5hbGx5IHNh aWQgdGhhdCB0aGlzIGRyYWZ0IHNob3VsZCBub3QgYmUgZG9uZSBpbiBsaWdodCBvZiBvbmx5IGlu dHJvc3BlY3Rpb24sIGFuZCBpbnN0ZWFkIHNob3VsZCBiZSBhIGdlbmVyaWMgbWVjaGFuaXNtIGFj cm9zcyBPQXV0aOKAmXMgdmFyaW91cyBlbmRwb2ludHMuIFdlaXJkIGNvbWJpbmF0aW9ucyBsaWtl IHRoZSDigJxpYXTigJ0gY2xhaW0gaGVyZSBhcmUgYSBkcml2ZXIgZm9yIGhhdmluZyBhIHNvbGlk IGdlbmVyaWMgbWVjaGFuaXNtIGluc3RlYWQgb2YgYSBoYW5kZnVsIG9mIHNsaWdodGx5IGRpZmZl cmVudCBkZWZpbml0aW9ucy4NCg0KU28gd2hhdCBzaG91bGQgd2UgZG8gaGVyZT8gSWYgd2UgYXJl IHRvIGtlZXAgdGhlIGN1cnJlbnQgcHJhY3RpY2Ugb2YgcHV0dGluZyBldmVyeXRoaW5nIGluIHRo ZSByb290IG9mIHRoZSBKV1QsIHdlIHNob3VsZCBoYXZlIGRpZmZlcmVudCBjbGFpbSBuYW1lcyB0 byBkaWZmZXJlbnRpYXRlIHRoZSBlbnZlbG9wZSBhbmQgdGhlIHRva2VuLiBUaGUgcHJvYmxlbSBo ZXJlIGlzIHRoYXQg4oCcaWF04oCdIGlzIGFscmVhZHkgZGVmaW5lZCBpbiBSRkM3NjYyIGFzIHJl ZmVycmluZyB0byB0aGUgdG9rZW4gYW5kIGluIFJGQzc1MTkgYXMgcmVmZXJyaW5nIHRvIHRoZSBK V1QgKHdoaWNoIGlzIG5vdCBhIHRva2VuLCBidXQgdGhlIGNvbnRhaW5lciBmb3IgdGhlIHRva2Vu IGluZm9ybWF0aW9uKS4gSeKAmW0gbm90IHN1cmUgd2hpY2ggaXMgd29yc2UsIGRlZmluaW5nIGFu IOKAnGlhdOKAnSBmb3IgdGhlIGludHJvc3BlY3Rpb24gcmVzcG9uc2Ugb3Igb25lIGZvciB0aGUg SldUIGJ1dCBvbmx5IGluIHRoaXMgaW5zdGFuY2UuIEJvdGggZmVlbCByZWFsbHkgbWVzc3ksIGFu ZCBpbiBjYXNlcyBsaWtlIFRvcnN0ZW7igJlzIHRoZXkgY29sbGFwc2UgdG8gdGhlIHNhbWUgdmFs dWUuDQoNCklmIGhvd2V2ZXIgd2UgcHV0IHRoZSBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlIGluIGl0 cyBvd24gc3ViLXNlY3Rpb24gb2YgdGhlIEpXVCBwYXlsb2FkLCB0aGVuIHdlIGNvdWxkIGF2b2lk IHRoZSBuYW1lc3BhY2UgY29sbGlzaW9uIGVudGlyZWx5LiBXZSB3b3VsZCBuZWVkIG5vcm1hdGl2 ZSBydWxlcyBsaWtlIGluIFNFVCB0byBkZWZpbmUgaG93IHRoZXNlIGZpZWxkcyByZWxhdGUgdG8g ZWFjaCBvdGhlciwgYnV0IEkgc2VlIHRoYXQgYXMgYSB0cmFjdGFibGUgcHJvYmxlbSB3aXRoIGEg cmVhc29uYWJsZSAoaWYgaW1wZXJmZWN0KSBwcmVjZWRlbnQuDQoNCkVpdGhlciBwYXRoIG1lYW5z IHJlZG9pbmcgV0dMQyBhbmQgdGhlIGFzc29jaWF0ZWQgcmV2aWV3cywgSeKAmW0gYWZyYWlkLiBM ZWF2aW5nIGl0IGFzLWlzIHdvcmtzIGZvciB0aGUgZHJpdmluZyB1c2UgY2FzZSB3aGVyZSB0aGUg aW5mb3JtYXRpb24gaXMgYWxsIHRoZSBzYW1lLCBidXQgSSBkb27igJl0IGZpbmQgaXQgdG8gYmUg YSBwYXJ0aWN1bGFybHkgY2xlYW4gcmVwcmVzZW50YXRpb24gb2YgdGhlIGluZm9ybWF0aW9uIGlu IHF1ZXN0aW9uLg0KDQrigJQgSnVzdGluDQoNCk9uIFNlcCA0LCAyMDE5LCBhdCA1OjIxIEFNLCBU b3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3Rl bkBsb2RkZXJzdGVkdC5uZXQ+PiB3cm90ZToNCg0KSGkgUmVtY28sDQoNCk9uIDMxLiBBdWcgMjAx OSwgYXQgMjE6MjcsIFNjaGFhciwgUi5NLiAoUmVtY28pIC0gTG9naXVzIDxyZW1jby5zY2hhYXJA bG9naXVzLm5sPG1haWx0bzpyZW1jby5zY2hhYXJAbG9naXVzLm5sPj4gd3JvdGU6DQoNCkhlbGxv IFRvcnN0ZW4sDQoNCihteSBhcG9sb2dpZXMgZm9yIG1ha2luZyBhIHR5cG8gcHJldmlvdXNseSkN Cg0KVGhhbmtzIDotKQ0KDQoNClRpbWUgb2YgaW50cm9zcGVjdGlvbiBpcyBjcml0aWNhbCBpZiB5 b3Ugd2FudCB0byB1c2UgdGhlIHNpZ25lZCBpbnRyb3NwZWN0aW9uDQpyZXNwb25zZSBmb3IgbGF0 ZXIgYWNjb3VudGFiaWxpdHkgb3IgYXVkaXQgcHVycG9zZXMuIEZvciBleGFtcGxlLCBhIENsaWVu dA0Kb2J0YWlucyBhbiBhY2Nlc3MgdG9rZW4gQSBhdCB0aW1lIHQuIE5vdyBhIHJlc291cmNlIHNl cnZlciByZWNlaXZlcyBBIGF0IHRpbWUNCnQrMSwgY2FsbHMgaW50cm9zcGVjdGlvbiBhbmQgcmVj ZWl2ZXMgYSByZXNwb25zZSBjb250YWluaW5nIGFjdGl2ZT10cnVlLiBBdA0KdCsyIHRoZSBhY2Nj ZXNzIHRva2VuIGlzIHJldm9rZWQuIEF0IHRpbWUgdCszIHRoZSByZXNvdXJjZSBzZXJ2ZXIgbWFr ZXMgYSBuZXcNCmludHJvc3BlY3Rpb24gcmVxdWVzdCwgbm93IHJlY2VpdmVzIGEgcmVzcG9uc2Ug Y29udGFpbmluZyBhY3RpdmU9ZmFsc2UuIFRoZQ0Kb25seSBkaWZmZXJlbmNlIHdvdWxkIGJlIHRo ZSB2YWx1ZSBvZiB0aGUgYWN0aXZlIHBhcmFtZXRlci4gV2l0aG91dCB0aGUgdGltZQ0Kb2YgaW50 cm9zcGVjdGlvbiBub3IgYSB1bmlxdWUgaWQgY292ZXJlZCBieSB0aGUgc2lnbmF0dXJlLCBvbmUg Y2Fubm90IG1ha2UgYQ0KY29uY2x1c2l2ZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHN1YnNlcXVlbnQg cmVzcG9uc2VzIGlmIHJldm9jYXRpb24gbWF5IGJlIGluDQpwbGF5Lg0KDQpUaGF04oCZcyBhIGdv b2QgcG9pbnQuDQoNCg0KVGhlIGRyYWZ0IHNwZWNpZmllcw0KICAgICBbLi4uXSB0byByZXR1cm4g cmVzcG9uc2VzIGFzIEpXVHMuDQpUaGlzIGNvdWxkIGVpdGhlciBtZWFuICJ0aGUgcmVzcG9uc2Ug aXMgcmV0dXJuZWQgaW4gSldUIGZvcm1hdCIgb3IgInRoZQ0KcmVzcG9uc2UgY29udGFpbnMgYSBK V1QgcmVwcmVzZW50YXRpb24gb2YgdGhlIGluc3BlY3RlZCB0b2tlbuKAnS4NCg0KSSdtIG1lYW53 aGlsZSBsZWFuaW5nIHRvd2FyZHMgInRoZSByZXNwb25zZSBpcyByZXR1cm5lZCBpbiBKV1QgZm9y bWF04oCdLg0KDQpOb3QgaGF2aW5nDQpjbGVhciwgc2VwYXJhdGUgcGFyYW1ldGVycyB0byBkaXN0 aW5ndWlzaCBiZXR3ZWVuIHRoZSB0aW1lIGFuZCBpZCBvZiB0aGUNCnRva2VuIGFuZCB0aGUgdGlt ZSBhbmQgaWQgb2YgdGhlIHJlc3BvbnNlIHJlc3VsdHMgaW4gZG91YmxlIG1lYW5pbmcuIEFzIGEN CmNvbnNlcXVlbmNlLCBpdCBpcyBlaXRoZXIgaGF2aW5nIHRoZSByaXNrIG9mIHJlcGxheSBvZiBh biBhY2Nlc3MgdG9rZW4gb3INCnJlcGxheSBvZiBhbiBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlIGlu c3RlYWQgb2YgbmVpdGhlci4NCg0KSeKAmW0gbm90IHN1cmUgaG93IGFuIGF0dGFja2VyIGNvdWxk IHJlcGxheSBhbiBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlIGdpdmVuIGl0IGlzIHRpZ2h0ZWQgdG8g YSBjZXJ0YWluIGVuZHBvaW50IHZpYSB0aGUgaXNzIGNsYWltLg0KDQpJIGFncmVlIHRoZSBSUyBs YWNrcyBhIHdheSB0byBwcm9vZiB3aGVuIGl0IHdhcyBwcm92aWRlZCB3aXRoIHRoZSBhY2Nlc3Mg dG9rZW4gZGF0YSBieSB0aGUgQVMuDQoNClRoZSBwcm9ibGVtIGluIG15IG9waW5pb24gaXMgdGhl IG92ZXJsYXkgYmV0d2VlbiB0aGUgb3JpZ2luYWwgYWNjZXNzIHRva2VuIGRhdGEgKGUuZy4gd2hl biB3YXMgaXQgaXNzdWVkIGJ5IHRoZSBBUykgYW5kIHRoZSBkYXRhIGJlbG9uZ2luZyB0byB0aGUg cmVwcmVzZW50YXRpb24gaW4gdGhlIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgKHdoZW4gd2FzIHRo ZSByZXNwb25zZSBjcmVhdGVkKS4gQ29uY2VwdHVhbGx5LCB0aGlzIG1lYW5zIHdlIHJlcXVpcmUg dHdvIHNlcGFyYXQg4oCcaWF0IiAoYWxpa2UpIGNsYWltcyB0byBkaXN0aW5ndWlzaCBib3RoIGFz cGVjdHMuDQoNCkkgY291bGQgaW1hZ2UgdHdvIHdheXMgdG8gaGFuZGxlIHRoaXM6DQotIGFkZCBh bm90aGVyIGlhdCBjbGFpbSwgZS5nLiDigJx0aXJfaWF0IiwgdG8gdGhlIEpXVA0KLSBhZGQgYW5v dGhlciDigJxpYXQiIGNsYWltIHRvIHRoZSBKV1MgaGVhZGVyIGNvbnRhaW5pbmcgdGhlIGluc3Rh bnQgd2hlbiB0aGUgdG9rZW4gaW50cm9zcGVjdGlvbiByZXNwb25zZSB3YXMgY3JlYXRlZA0KDQpX aGF0IGRvIHlvdSB0aGluaz8NCg0KYmVzdCByZWdhcmRzLA0KVG9yc3Rlbi4NCg0KDQpLaW5kIHJl Z2FyZHMsDQpSZW1jbyBzY2hhYXINCg0KLS0tLS1Pb3JzcHJvbmtlbGlqayBiZXJpY2h0LS0tLS0N ClZhbjogVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRv OnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj4NClZlcnpvbmRlbjogd29lbnNkYWcgMjggYXVndXN0 dXMgMjAxOSAxMToxNA0KQWFuOiBTY2hhYXIsIFIuTS4gKFJlbWNvKSAtIExvZ2l1cyA8cmVtY28u c2NoYWFyQGxvZ2l1cy5ubDxtYWlsdG86cmVtY28uc2NoYWFyQGxvZ2l1cy5ubD4+DQpDQzogb2F1 dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KT25kZXJ3ZXJwOiBSZTogW09BVVRI LVdHXSBRdWVzdGlvbiByZWdhcmRpbmcgZHJhZnQtaWV0Zi1vYXV0aC1qd3QtaW50cm9zcGVjdGlv bi1yZXNwb25zZS0wNQ0KDQpIaSBSaGVtY28sDQoNCk9uIDI2LiBBdWcgMjAxOSwgYXQgMDk6NDIs IFNjaGFhciwgUi5NLiAoUmVtY28pIC0gTG9naXVzIDxyZW1jby5zY2hhYXJAbG9naXVzLm5sPG1h aWx0bzpyZW1jby5zY2hhYXJAbG9naXVzLm5sPj4gd3JvdGU6DQoNCkhlbGxvIFRob3JzdGVuLA0K DQpUaGFuayB5b3UgZm9yIHlvdXIgcmVzcG9uc2UuIEkgaGF2ZSBhIGZldyBtb3JlIHF1ZXN0aW9u cy9jb21tZW50cyBhcw0KZm9sbG93LXVwLi4uDQoNCllvdSBzdGF0ZSB0aGF0IFJGQzc1MTkgYW5k IFJGQzc2NjIgImp1c3QiIGRlZmluZSBkaWZmZXJlbnQgcmVwcmVzZW50YXRpb25zDQpmb3IgdG9r ZW4gZGF0YS4gSWYgdGhlIGRyYWZ0IFJGQyB3b3VsZCByZWZlciB0byBSRkMgNzUxNSAoSldTKSwg SSB3b3VsZA0KYWdyZWUuIEhvd2V2ZXIsIFJGQzc1MTkgKEpXVCkgZXhwbGljaXRseSBhZGRzIHNl bWFudGljcyB0byBzb21lIHNwZWNpZmljDQpwYXJhbWV0ZXJzIChlLmcuIGF1ZCwganRpIGFuZCBp YXQpLiBSRkM3NjYyIGhhcyBkaWZmZXJlbnQgc2VtYW50aWNzIGZvcg0KdGhlIHNldmVyYWwgb2Yg dGhlIHNhbWUgcGFyYW1ldGVycy4NCkZvciBpbnN0YW5jZSB0aGUgJ2lhdCcsIGlzIHRoZSBtb21l bnQgb2YgaXNzdWFuY2Ugb2YgdGhlIEpXVCBpbiBSRkM3NTE5LiBJbg0KUkZDNzY2MiB0aGF0IGlz IHRoZSAid2hlbiB0aGlzIHRva2VuIHdhcyBvcmlnaW5hbGx5IGlzc3VlZCIuIFRoaXMgdGltZSB3 aWxsDQp2YXJ5IGluIHVzZSBjYXNlcyB3aXRob3V0IGltbWVkaWF0ZSBpbnRyb3NwZWN0aW9uIG9m IGFuIGFjY2VzcyB0b2tlbi4NCg0KSSByZWFkIHRoZSB0ZXh0IGRpZmZlcmVudGx5LiBJbiBteSBp bnRlcnByZXRhdGlvbiDigJx3aGVuIHRoZSB0b2tlbiB3YXMgb3JpZ2luYWxseSBpc3N1ZWTigJ0g c3RhdGVkIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBvaW50 IHJlZmVycyBleGFjdGx5IHRvIHRoZSBzYW1lIGluc3RhbnQgYXMg4oCcdGhlIHRpbWUgYXQgd2hp Y2ggdGhlIEpXVCB3YXMNCiBpc3N1ZWTigJ0uDQoNCg0KRm9yIHRoZSB1c2UgY2FzZSBvZiB0aGUg cmVzb3VyY2Ugc2VydmVyIHJlbHlpbmcgb24gdmVyaWZpYWJsZSBkYXRhLCBhcw0KZGVzY3JpYmVk IGluIHRoZSBpbnRyb2R1Y3Rpb24gb2YgdGhlIGRyYWZ0IFJGQywgdGhlIHRpbWUgb2YgdGhlIGlu dHJvc3BlY3Rpb24NCmlzIGNyaXRpY2FsLg0KDQpXaHkgaXMgdGhpcyB0aW1lIGNyaXRpY2FsPw0K DQpJbiBwYXJ0aWN1bGFyIHdoZW4gY29tYmluZWQgd2l0aCByZXZvY2F0aW9uLCB0aGUgdGltZSBv Zg0KaW50cm9zcGVjdGlvbiBhbmQgdGhlICdhY3RpdmUnIHN0YXR1cyBjYW4gZGlmZmVyIGJldHdl ZW4gdHdvIHN1YnNlcXVlbnQgY2FsbHMNCmZvciBpbnRyb3NwZWN0aW9uLg0KDQpUaGUgc3RhdHVz IGF0IHRva2VuIGludHJvc3BlY3Rpb24gcmVxdWVzdCB0aW1lIGlzIGluZGVlZCBjcml0aWNhbC4g UkZDIDc2NjIgZ2l2ZXMgYSBnb29kIGluZGljYXRpb24gaG93IHRoaXMgdmFsdWUgc2hvdWxkIGJl IGNhbGN1bGF0ZWQuDQoNCuKAnOKApiBhICJ0cnVlIg0KICAgIHZhbHVlIHJldHVybiBmb3IgdGhl ICJhY3RpdmUiIHByb3BlcnR5IHdpbGwgZ2VuZXJhbGx5IGluZGljYXRlDQogICAgdGhhdCBhIGdp dmVuIHRva2VuIGhhcyBiZWVuIGlzc3VlZCBieSB0aGlzIGF1dGhvcml6YXRpb24gc2VydmVyLA0K ICAgIGhhcyBub3QgYmVlbiByZXZva2VkIGJ5IHRoZSByZXNvdXJjZSBvd25lciwgYW5kIGlzIHdp dGhpbiBpdHMNCiAgICBnaXZlbiB0aW1lIHdpbmRvdyBvZiB2YWxpZGl0eSAoZS5nLiwgYWZ0ZXIg aXRzIGlzc3VhbmNlIHRpbWUgYW5kDQogICAgYmVmb3JlIGl0cyBleHBpcmF0aW9uIHRpbWUpLiIN Cg0KU28gaXQgcmVwcmVzZW50cyB0aGUgcmVzdWx0cyBvZiB0aGUgaXNzdWVyIGNoZWNrLCB0aGUg cmV2b2NhdGlvbiBjaGVjayBhbmQgdGhlIHZhbGlkaXR5IGNoZWNrIGluIG9uZSBib29sZWFuIHZh bHVlLg0KDQoNCklmIHRoZSBkcmFmdCBSRkMganVzdCBwcm9kdWNlcyBhIEpXVCByZXByZXNlbnRh dGlvbiBvZiB0aGUgYWNjZXNzIHRva2VuLA0KaW5jbHVkaW5nICdhY3RpdmUnIHdvdWxkIG5vdCBt YWtlIHNlbnNlIGFzIHRoZSBKV1Qgd2lsbCBleHBpcmUgd2l0aG91dA0KdXBkYXRpbmcgaXQgdG8g ZmFsc2UuIExlYXZpbmcgJ2FjdGl2ZScgb3V0IHdvdWxkIG1ha2UgaXQgaW5jb21wYXRpYmxlIHdp dGgNClJGQzc2NjIgaW50cm9zcGVjdGlvbiByZXNwb25zZXMuDQoNCuKAnGFjdGl2ZeKAnSBpcyBu b3QgcGFydCBvZiB0aGUgSldUIHJlcHJlc2VudGF0aW9uIEkgcmVmZXJyZWQgdG8uIFRoZSBBUyBu ZWVkcyB0byBkZXRlcm1pbmUgdGhlIGFjdGl2ZSB2YWx1ZSBmb3IgZXZlcnkgdG9rZW4gaW50cm9z cGVjdGlvbiByZXF1ZXN0Lg0KDQpJZiB0aGUgUlMgd291bGQgY29uc3VtZSBKV1RzLCBpdCB3b3Vs ZCBkZXRlcm1pbmUgdGhlIOKAnGFjdGl2ZeKAnSB2YWx1ZSBpdHNlbGYgYnkgaW5zcGVjdGluZyB0 aGUgaXNzIGNsYWltIGFuZCBjaGVjayBhZ2FpbnN0IGl0cyBBUyB3aGl0ZWxpc3QsIGNoZWNrIHRo ZSBzaWduYXR1cmUgYW5kIHRoZSBpYXQgJiBleHAgdmFsdWVzLiBEZXRlcm1pbmluZyB0aGUgcmV2 b2NhdGlvbiBzdGF0dXMgd291bGQgcmVxdWlyZSBhbiBpbmZvcm1hdGlvbiBleGNoYW5nZSB3aXRo IHRoZSBBUyBvZiBzb21lIHNvcnQuDQoNClNpbWlsYXIsIG5vdCBpbmNsdWRpbmcgYSB1bmlxdWUg J2p0aScgcGVyIGludHJvc3BlY3Rpb24gcmVzcG9uc2Ugd291bGQgbWFrZQ0KdGhlIHJlc291cmNl IHNlcnZlciB2dWxuZXJhYmxlIHRvIHJlcGxheSBhdHRhY2tzLg0KDQpUbyB0aGUgY29udHJhcnks IGluY2x1ZGluZyBhIGRpZmZlcmVudCDigJxqaXQiIHdpdGggZXZlcnkgdG9rZW4gaW50cm9zcGVj dGlvbiByZXNwb25zZSB3b3VsZCBtYWtlIHRoZSBSUyB2dWxuZXJhYmxlIHRvIHJlcGxheSBvZiBv bmUgdGltZSBhY2Nlc3MgdG9rZW4gc2luY2UgaXQgcmVtb3ZlIHRoZSBwb3NzaWJpbGl0eSBmb3Ig dGhlIFJTIHRvIGlkZW50aXR5IGEgY2VydGFpbiBhY2Nlc3MgdG9rZW4uDQoNCk9yIHRoZSByZXNv dXJjZSBzZXJ2ZXINCndvdWxkIG1pc3Rha2VubHkgcmVmZXIgdG8gbm9uLXVuaXF1ZSB0b2tlbnMs IG1ha2luZyB0aGUgcmVzcG9uc2VzIHVuc3VpdGFibGUNCmZvciBhY2NvdW50YWJpbGl0eSBhbmQg YXVkaXQgcHVycG9zZXMuDQoNCg0KQXMgdG8gd2h5IHNvbWVvbmUgd291bGQgd2FudCB0byBkaXN0 aW5ndWlzaCBhIEpXVCBhY2Nlc3MgdG9rZW4gZnJvbSBhbg0KaW50cm9zcGVjdGlvbiByZXNwb25z ZTogc2V2ZXJhbCB1c2UgY2FzZXMgY29tZSB0byBtaW5kLg0KDQpGaXJzdCBvZiBhbGwsIGV2ZW4g aWYgb25lIGlzIHVzaW5nIHN0YW5kYWxvbmUgaW50ZXJwcmV0YWJsZSBKV1QgYWNjZXNzIHRva2Vu cywNCm9uZSBtYXkgd2FudCB0byBjb21iaW5lIHRoYXQgd2l0aCByZXZvY2F0aW9uIGNoZWNraW5n IHVzaW5nIGludHJvc3BlY3Rpb24uIFRoZQ0KaW50ZXJwcmV0YXRpb24gYW5kIG1lYW5pbmcgb2Yg dGhlIEpXVCBhbmQgdGhlIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgdGhhbiBkbw0KZGlmZmVyIGFu ZCBtYXR0ZXIuDQoNCkFzIEkgZGVzY3JpYmVkIGFib3ZlLCBJIGRvbuKAmXQgc2VlIGFueSBkaWZm ZXJlbmNlLg0KDQoNCkFub3RoZXIgdXNlIGNhc2Ugd291bGQgYmUgYSBtaXhlZCBlY29zeXN0ZW0g d2l0aCByZXNvdXJjZSBzZXJ2ZXJzIHJlbHlpbmcgb24NCmludHJvc3BlY3Rpb24gd2hpbGUgb3Ro ZXJzIGRvIHBhcnNlIEpXVCBhY2Nlc3MgdG9rZW5zLiBBIHNpbmdsZSwgdW5pZm9ybQ0KaW1wbGVt ZW50YXRpb24gZm9yIHRoZSBBUyB3b3VsZCB0aGFuIG1peCBib3RoIGFzIHdlbGwuDQoNClNlZSBh Ym92ZSAtIEkgZG9u4oCZdCBzZWUgYW55IGlzc3VlLg0KDQoNCkEgbGFzdCB1c2UgY2FzZSBjb3Vs ZCBiZSBleGNoYW5naW5nIGFjY2VzcyB0b2tlbnMgd2l0aCBhIHN1YnNldCBvZiB0aGUgZnVsbA0K c2V0IG9mIGFwcGxpY2FibGUgcGFyYW1ldGVycywgdG8gcmVkdWNlIHRoZSBzaXplIG9mIGFjY2Vz cyB0b2tlbnMuIEFkZGl0aW9uYWwNCmluZm9ybWF0aW9uIGNhbiBiZSBleGNoYW5nZWQgdmlhIGlu dHJvc3BlY3Rpb24sIHJlc3VsdGluZyBpbiBtaXhlZCBKV1QgYWNjZXNzDQp0b2tlbnMgYW5kIGlu dHJvc3BlY3Rpb24gYXMgd2VsbC4NCg0KVGhhdOKAmXMgYWxsIHBvc3NpYmxlIHdpdGhpbiB0aGUg Y3VycmVudCB0ZXh0Lg0KDQpraW5kIHJlZ2FyZHMsDQpUb3JzdGVuDQoNCg0KS2luZCByZWdhcmRz LA0KUmVtY28gU2NoYWFyDQoNCi0tLS0tT29yc3Byb25rZWxpamsgYmVyaWNodC0tLS0tDQpWYW46 IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldD4+DQpWZXJ6b25kZW46IHphdGVyZGFnIDE3IGF1Z3VzdHVzIDIw MTkgMTQ6MDANCkFhbjogU2NoYWFyLCBSLk0uIChSZW1jbykgLSBMb2dpdXMgPHJlbWNvLnNjaGFh ckBsb2dpdXMubmw8bWFpbHRvOnJlbWNvLnNjaGFhckBsb2dpdXMubmw+Pg0KQ0M6IG9hdXRoQGll dGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCk9uZGVyd2VycDogUmU6IFtPQVVUSC1XR10g UXVlc3Rpb24gcmVnYXJkaW5nIGRyYWZ0LWlldGYtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVz cG9uc2UtMDUNCg0KSGkgUmVtY28sDQoNCk9uIDYuIEF1ZyAyMDE5LCBhdCAxNjowMSwgU2NoYWFy LCBSLk0uIChSZW1jbykgLSBMb2dpdXMgPHJlbWNvLnNjaGFhckBsb2dpdXMubmw8bWFpbHRvOnJl bWNvLnNjaGFhckBsb2dpdXMubmw+PiB3cm90ZToNCg0KSGVsbG8sDQoNClsuLi5dDQpSRkMgNzUx OSBhbmQgUkZDIDc2NjIg4oCcanVzdOKAnSBkZWZpbmUgZGlmZmVyZW50IHJlcHJlc2VudGF0aW9u cyBmb3IgdG9rZW4gZGF0YS4gSW4gUkZDIDc1MTkgdGhlIGRhdGEgaXMgY2FycmllZCBpbiB0aGUg dG9rZW4gaXRzZWxmICh3aGljaCBhbHNvIG1lYW5zIHRoZSBmb3JtYXQgb2YgdGhlIHRva2VuIGlz IHdlbGwtZGVmaW5lZCBhbmQga25vdyB0byB0aGUgUlMpIHdoZXJlYXMgUkZDIDc2NjIgZGVmaW5l cyBhIHdheSB0byBpbnNwZWN0IHRva2VucyB2aWEgYW4gQVBJIHByb3ZpZGVkIGJ5IHRoZSBBUy4g VGhlIGxhdHRlciBpcyB0eXBpY2FsbHkgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIG9wYXF1ZSB0 b2tlbnMsIGkuZS4gdGhlIFJTIGRvZXMgbm90IGhhdmUgYSBjbHVlIGhvdyB0byBwYXJzZSBhbmQg aW50ZXJwcmV0IHRoZSB0b2tlbi4gVGhlIHRva2VuIG1pZ2h0IGp1c3QgYmUgYSBoYW5kbGUgdG8g YSBkYXRhYmFzZSBlbnRyeSBhdCB0aGUgQVMgaW4gdGhpcyBjYXNlLg0KDQpUaGlzIGFsc28gbWVh bnMgYSBKV1QgKFJGQyA3NjYyKSBhbmQgdGhlIEludHJvc3BlY3Rpb24gUmVzcG9uc2UgYXJlIGNv bmNlcHR1YWxseSB0aGUgc2FtZSBmcm9tIGEgUlNzIHBlcnNwZWN0aXZlLg0KDQpbLi4uXQ0KDQpU aGUg4oCYanRp4oCZIHBhcmFtZXRlciBob3dldmVyIHdpbGwgYWx3YXlzIGJlIGFtYmlndW91cy4g QXMgaXQgaXMgYW4gaWRlbnRpZmllciwgaXQgc2hvdWxkIGRpZmZlciBmb3IgdGhlIGludHJvc3Bl Y3RlZCB0b2tlbiBhbmQgdGhlIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgYnkgZGVmaW5pdGlvbi4g SGVuY2UgdGhlIHNlbWFudGljcyBvZiDigJhqdGnigJkgaW4gYSBKV1QgaW50cm9zcGVjdGlvbiBy ZXNwb25zZSBpcyB1bmNsZWFyLiBUaGUgc2FtZSBjYW4gYXBwbHkgdG8gdGhlIOKAmGlhdOKAmSwg 4oCYbmJm4oCZIGFuZCDigJhleHDigJkgY2xhaW1zIGluIGEgSldUIGludHJvc3BlY3Rpb24gcmVz cG9uc2UuDQoNCkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIHlvdSBhcmUgbWFr aW5nLiBBbGwgYmVmb3JlIG1lbnRpb25lZCBjbGFpbXMgYXJlIHJlbGF0ZWQgdG8gdGhlIChhYnN0 cmFjdCkgYWNjZXNzIHRva2VuLiBZb3UgbWF5IHRoaW5rIG9mIHRoZSBJbnRyb3NwZWN0aW9uIFJl c3BvbnNlIGFzIF90aGVfIEpXVCByZXByZXNlbnRhdGlvbiBvZiB0aGUgYWNjZXNzIHRva2VuIHBy b2R1Y2VkIGJ5IHRoZSBBUyBmb3IgdGhlIFJTLg0KDQoNCkNhbiBzb21lb25lIGNsYXJpZnkgdGhl IHNlbWFudGljcyBvZiBjbGFpbXMgaW4gYW4gaW50cm9zcGVjdGlvbiByZXNwb25zZSBKV1QgdGhh dCBhcmUgZGVmaW5lZCBpbiBib3RoIFJGQzc2NjIgYW5kIFJGQzc1MTk/DQoNCkZ1cnRoZXJtb3Jl LCB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZSBzaG91bGQgdXNlIHRoZSDigJhpc3PigJkgYW5k IOKAmGF1ZOKAmSBjbGFpbXMgdG8gYXZvaWQgY3Jvc3MtSldUIGNvbmZ1c2lvbiAoc2VjdGlvbiA2 LjEpLiBUaGUg4oCYaXNz4oCZIGFuZCDigJhhdWTigJkgb2YgYW4gaW50cm9zcGVjdGVkIHRva2Vu IHdpbGwgdHlwaWNhbGx5IGJlIHRoZSBzYW1lIGFzIHRob3NlIG9mIHRoZSBpbnRyb3NwZWN0aW9u IHJlc3BvbnNlLiBIZW5jZSBhIEpXVCBhY2Nlc3MgdG9rZW4gY2Fubm90IGJlIGRpc3Rpbmd1aXNo ZWQgZnJvbSBhbiBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlIHVzaW5nIOKAmGlzc+KAmSBhbmQg4oCY YXVk4oCZIGFzIHN1Z2dlc3RlZCBpbiB0aGUgZHJhZnQuLg0KDQpJbnRyb3NwZWN0aW9uIHJlZmVy cyB0byBKV1QgYmVzdC1jdXJyZW50LXByYWN0aWNlLiBUaGUgZHJhZnQgQkNQIHJlY29tbWVuZHMg dXNpbmcgZXhwbGljaXQgdHlwaW5nIG9mIEpXVHMsIGhvd2V2ZXIgdGhlIGRyYWZ0IEpXVCByZXNw b25zZSBmb3IgaW50cm9zcGVjdGlvbiBkb2VzIG5vdCBhcHBseSB0aGlzIHJlY29tbWVuZGF0aW9u IGFuZCB1c2VzIHRoZSBnZW5lcmljIOKAmGFwcGxpY2F0aW9uL2p3dOKAmSBpbnN0ZWFkLi4uIFRo ZSBCQ1AgaGFzIG90aGVyIHJlY29tbWVuZGF0aW9ucyBpbiBzZWN0aW9uIDMuMTIsIGJ1dCB0aGVz ZSBtYXkgYmUgaW5zdWZmaWNpZW50IHRvIGRpc3Rpbmd1aXNoIGEgSldUIGFjY2VzcyB0b2tlbiBm cm9tIGEgSldUIGludHJvc3BlY3Rpb24gcmVzcG9uc2UuDQoNCkdvb2QgcG9pbnQuIFRoZSByZWFz b24gd2h5IHRoZSBCQ1AgcmVjb21tZW5kcyBleHBsaWNpdCB0eXBpbmcgaXMgdG8gcHJldmVudCBy ZXBsYXkgaW4gb3RoZXIgY29udGV4dHMuIEluIHRoZSBlbmQgdHlwaW5nIGlzIGEgY29tcGVsbGlu ZyBjb25jZXB0IHVuZm9ydHVuYXRlbHkgbm90IGJyb2FkbHkgdXNlZCBpbiB0aGUgd2lsZC4NCg0K U28gdGhlIEpXVCBJbnRyb3NwZWN0aW9uIFJlc3BvbnNlIGRyYWZ0IGNvcGVzIHdpdGggdGhhdCBh dHRhY2sgYW5nbGUgYnkgbWFraW5nIGlzcyBhbmQgYXVkIG1hbmRhdG9yeS4NCg0KDQoNCkhvdyB3 b3VsZCBwZW9wbGUgc3VnZ2VzdCB0byBiZXN0IGRpc3Rpbmd1aXNoIGEgSldUIChhY2Nlc3MpIHRv a2VuIGZyb20gYSBKV1QgaW50cm9zcGVjdGlvbiByZXNwb25zZT8NCg0KV2h5IHNob3VsZCB5b3U/ IE9uZSByZWFzb24gd2h5IHdlIGV4dGVuZGVkIHRoZSBJbnRyb3NwZWN0aW9uIFJlc3BvbnNlIHdh cyB0byBlbGltaW5hdGUgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBKV1RzIGRpcmVjdGx5IHVzZWQg YXMgYWNjZXNzIHRva2VucyBhbmQgSW50cm9zcGVjdGlvbiBSZXNwb25zZXMuDQoNCmJlc3QgcmVn YXJkcywNClRvcnN0ZW4uDQoNCg0KRGl0IGJlcmljaHQga2FuIGluZm9ybWF0aWUgYmV2YXR0ZW4g ZGllIG5pZXQgdm9vciB1IGlzIGJlc3RlbWQuIEluZGllbiB1IG5pZXQgZGUgZ2VhZHJlc3NlZXJk ZSBiZW50IG9mIGRpdCBiZXJpY2h0IGFidXNpZXZlbGlqayBhYW4gdSBpcyB0b2VnZXpvbmRlbiwg d29yZHQgdSB2ZXJ6b2NodCBkYXQgYWFuIGRlIGFmemVuZGVyIHRlIG1lbGRlbiBlbiBoZXQgYmVy aWNodCB0ZSB2ZXJ3aWpkZXJlbi4gRGUgU3RhYXQgYWFudmFhcmR0IGdlZW4gYWFuc3ByYWtlbGlq a2hlaWQgdm9vciBzY2hhZGUsIHZhbiB3ZWxrZSBhYXJkIG9vaywgZGllIHZlcmJhbmQgaG91ZHQg bWV0IHJpc2ljbydzIHZlcmJvbmRlbiBhYW4gaGV0IGVsZWt0cm9uaXNjaCB2ZXJ6ZW5kZW4gdmFu IGJlcmljaHRlbi4NClRoaXMgbWVzc2FnZSBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlz IG5vdCBpbnRlbmRlZCBmb3IgeW91LiBJZiB5b3UgYXJlIG5vdCB0aGUgYWRkcmVzc2VlIG9yIGlm IHRoaXMgbWVzc2FnZSB3YXMgc2VudCB0byB5b3UgYnkgbWlzdGFrZSwgeW91IGFyZSByZXF1ZXN0 ZWQgdG8gaW5mb3JtIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZS4gVGhlIFN0YXRl IGFjY2VwdHMgbm8gbGlhYmlsaXR5IGZvciBkYW1hZ2Ugb2YgYW55IGtpbmQgcmVzdWx0aW5nIGZy b20gdGhlIHJpc2tzIGluaGVyZW50IGluIHRoZSBlbGVjdHJvbmljIHRyYW5zbWlzc2lvbiBvZiBt ZXNzYWdlcy4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_9F5DA44DBD3C43B2A88C66394BD7BE85mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <781D8520940F754AB8F2A09C5B026B9F@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+QXMgSeKAmXZlIHNhaWQg aW4gdGhlIHBhc3QsIEkgdGhpbmsgdGhlcmUgaXMgYW5kIHNob3VsZCBiZSBhIGNsZWFyIGRpZmZl cmVuY2UgYmV0d2VlbiBhIEpXVCBhY2Nlc3MgdG9rZW4gYW5kIGEgSldULWZvcm1hdHRlZCByZXNw b25zZSBmcm9tIGFueSBlbmRwb2ludC4gSXQgZ2V0cyBleHRyYSBmdXp6eSBoZXJlIGJlY2F1c2Ug dGhlIHJlc3BvbnNlIGZyb20gdGhlIGVuZHBvaW50IHJlcHJlc2VudHMgdGhlIHRva2VuIGJlaW5n IGludHJvc3BlY3RlZC4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkhvd2V2ZXIsIEkgdGhpbmsgdGhleSBhcmUgc3RpbGwgdHdv IHZlcnkgZGlmZmVyZW50IHRoaW5ncyBiZWNhdXNlIHRoZSBpbnRyb3NwZWN0aW9uIHJlc3BvbnNl IGJ5IGRlZmluaXRpb24gcmVwcmVzZW50cyB3aGF0IHRoZSB0b2tlbiB3YXMgYXQgdGhlIHRpbWUg b2YgaW50cm9zcGVjdGlvbi4gVGhhdOKAmXMgd2h5IHRoZSDigJxhY3RpdmXigJ0gY2xhaW0gaXMg aW1wb3J0YW50IGhlcmUsIGFsb25nIHdpdGggdGhlIHRpbWVzdGFtcCBpbmZvcm1hdGlvbg0KIGlu IHRoZSBKV1QgY29udGFpbmVyIOKAlCB5b3UgY2FuIHNheSB0aGF0IHRoZSB0b2tlbiAqd2FzKiBh Y3RpdmUgYXQgdGhlIHRpbWUgb2YgaW50cm9zcGVjdGlvbiwgYnV0IHlvdSBjYW7igJl0IHNheSBp dOKAmXMgc3RpbGwgYWN0aXZlIHdpdGhvdXQgaW50cm9zcGVjdGluZyB0aGUgdG9rZW4gYWdhaW4g dG8gY2hlY2suIFRoaXMgbGVhZHMgdG8gZXhhY3RseSB0aGUga2luZCBvZiBjb2xsaXNpb24gdGhh dOKAmXMgYmVpbmcgZGlzY3Vzc2VkIGhlcmUuIEl04oCZcyBjb25mdXNpbmcNCiBmb3IgZGV2ZWxv cGVycyBvZiBib3RoIHRoZSBBUyBhbmQgdGhlIFJTLCBhbmQgSSBmZWFyIGl04oCZcyBnb2luZyB0 byBsZWFkIHRvIGFuIEFTIGNob29zaW5nIG9uZSBpbnRlcnByZXRhdGlvbiBhbmQgYW4gUlMgY2hv b3NpbmcgYW5vdGhlciwgYW5kIHRoZXJlZm9yZSBsZWF2aW5nIG9wZW4gYSBkb29yIHRvIHNlY3Vy aXR5IGlzc3VlcyBkb3duIHRoZSByb2FkLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QWxzbywgcmVtZW1iZXIgb25lIG9mIHRoZSBtYWlu IHJlYXNvbnMgdGhhdCB3ZSByZXF1aXJlIHNvbWUgZm9ybSBvZiBSUyBhdXRoZW50aWNhdGlvbiB0 byB0aGUgdG9rZW4gZW5kcG9pbnQgaXMgdGhhdCBkaWZmZXJlbnQgUlPigJlzIGNhbiBnZXQgZGlm ZmVyZW50IGFuc3dlcnMgZm9yIHRoZSBzYW1lIHRva2VuLiBUaGUgQVMgY2FuIHRhaWxvciBpdHMg cmVzcG9uc2UgYmFzZWQgb24gd2hhdCBzY29wZXMgdGhlIFJTIGlzIHN1cHBvc2VkDQogdG8ga25v dyBhYm91dCwgb3Igd2hpY2ggUlPigJlzIGNhbiBrbm93IGEgdXNlcuKAmXMgaWRlbnRpZmllciAo b3IgZXZlbiB1c2UgcGFpcndpc2UgaWRlbnRpZmllcnMpLCBvciBldmVuIHdoaWNoIFJTIGlzIHN1 cHBvc2VkIHRvIGtub3cgYWJvdXQgYSBnaXZlbiB0b2tlbiBhdCBhbGwuIEluIGVhY2ggb2YgdGhl c2UgY2FzZXMsIHVzaW5nIHRoaXMgZHJhZnQsIHlvdeKAmWxsIGdldCBhIGRpZmZlcmVudCBKV1Qg b3V0IGZvciB0aGUgc2FtZSB0b2tlbiBvbiB0aGUNCiB3YXkgaW4uIFlvdeKAmXJlIG5vdCBzaW1w bHkgdHJhbnNsYXRpbmcgYW4gYWNjZXNzIHRva2VuIHRvIGFub3RoZXIgYWNjZXNzIHRva2VuIGhl cmUg4oCUIGlmIHlvdSB3YW50IHRvIGRvIHRoYXQsIHVzZSB0b2tlbiBleGNoYW5nZSBhbmQgZG8g aXQgcHJvcGVybHkgd2l0aCBhbiBPQXV0aCBncmFudC4gSW5zdGVhZCwgeW914oCZcmUgZ2V0dGlu ZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgdG9rZW4gaXRzZWxmIGF0IHRoZSB0aW1lIG9mIHRoZSBy ZXF1ZXN0IGFuZA0KIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSByZXF1ZXN0b3IsIGFuZCB5 b3UgaGFwcGVuIHRvIGJlIHdyYXBwaW5nIHRoZSByZXNwb25zZSBpbiBhIGNvbnRhaW5lciB0aGF0 IGlzIGFsc28gd2lkZWx5IHVzZWQgdG8gZm9ybWF0IGFjY2VzcyB0b2tlbnMuJm5ic3A7PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KVGhlIHNlcGFyYXRpb24gdGhh dCBUb3JzdGVuIHBvaW50cyBvdXQgYmVsb3cgYnJpbmdzIHVwIG9uZSBvZiB0aGUgYmlnZ2VzdCBw cm9ibGVtcyB3aXRoIEpXVHMgYXMgYSBkYXRhIGNvbnRhaW5lciBmb3JtYXQg4oCUIGFsbCB0aGUg aW5mb3JtYXRpb24gYWJvdXQgdGhlIEpXVCBpdHNlbGYgaXMgbWl4ZWQgaW4gd2l0aCB0aGUgdGhp bmcgaXTigJlzIGNhcnJ5aW5nIGluZm9ybWF0aW9uIGFib3V0LiBXZSBzZWUgdGhpcyBpc3N1ZSB3 aXRoIEpBUiwgd2hlcmUNCiB0aGUg4oCcYXVk4oCdIHBhcmFtZXRlciBjYW4gbWVhbiB0aGUgYXVk aWVuY2Ugb2YgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBhbmQgdGhlIGF1ZGllbmNlIG9mIHRo ZSBKV1QgdXNlZCB0byBjYXJyeSB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0LiBXZSBhbHNvIHNl ZSB0aGlzIGEgbGl0dGxlIGJpdCBpbiBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb27igJlzIHNv ZnR3YXJlIHN0YXRlbWVudC4gUm9vdC1sZXZlbCBKV1QgY2xhaW1zIGFyZSBhIHBvb3INCiBtZWNo YW5pc20gZm9yIHRoaXMuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5JbiByZXRyb3NwZWN0LCB3aGF0IEkgd2lzaCB3ZeKAmWQgZG9uZSB3aXRoIGFs bCBvZiB0aGVtIHVzaW5nIGEgbmFtZWQgcGF5bG9hZCBsaWtlIHdpdGggU0VU4oCZcyDigJxldmVu dOKAnSBjbGFpbS4gRXZlbiB0aGVyZSwgd2UgaGFkIGEgbG90IG9mIGFyZ3VtZW50IGFib3V0IGEg 4oCcc3Vi4oCdIGNsYWltIGluc2lkZSB0aGUg4oCcZXZlbnTigJ0gb2JqZWN0IHZzLiBvbmUgYXQg dGhlIHJvb3Qgb2YgdGhlIEpXVCBjb250YWluZXIsIGJ1dCBhdCBsZWFzdA0KIGluIHRoZXNlIGNh c2VzICZuYnNwO3dlIG5vdyBoYWQgYW4gb3Bwb3J0dW5pdHkgdG8gd3JpdGUgY2xlYXIgbGFuZ3Vh Z2UgYWJvdXQgd2hhdCBlYWNoIG1lYW50IGluIGVhY2ggY2lyY3Vtc3RhbmNlLiBJIHJlYWxpemUg dGhpcyBkcmFmdCBpcyBhbHJlYWR5IHdlbGwgYWxvbmcgaW4gaXRzIHByb2Nlc3MsIGFuZCBJIGhh dmVu4oCZdCBwdXQgaW4gdGhlIHJldmlldyB0aW1lIG9yIGNvbW1lbnRzIHRvIGRhdGUgbXlzZWxm LCBidXQgSSB0aGluayBpdOKAmXMgdW5mb3J0dW5hdGUNCiB0aGF0IHRoZSBkcmFmdCBkb2VzbuKA mXQgZGVmaW5lIGEgc3ViLWNsYWltIGxpa2Ug4oCcYWNjZXNzX3Rva2Vu4oCdIG9yIOKAnHRva2Vu X2luZm9ybWF0aW9u4oCdIHRvIGNhcnJ5IGluc2lkZSB0aGUgSldUIHBheWxvYWQuIFRoaXMgd291 bGQgc29sdmUgdGhlIHByb2JsZW0gb2YgZGlmZmVyZW50aWF0aW5nIHRoZSDigJxpYXTigJ0gZm9y IHRoZSB0b2tlbiBpdHNlbGYgdnMuIHRoZSBKV1QgY29udGFpbmVyIG9mIHRoZSByZXNwb25zZS48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PlRoZSBncm91cCBtYXkgYWxzbyByZWNhbGwgdGhhdCBJIG9yaWdpbmFsbHkgc2FpZCB0aGF0IHRo aXMgZHJhZnQgc2hvdWxkIG5vdCBiZSBkb25lIGluIGxpZ2h0IG9mIG9ubHkgaW50cm9zcGVjdGlv biwgYW5kIGluc3RlYWQgc2hvdWxkIGJlIGEgZ2VuZXJpYyBtZWNoYW5pc20gYWNyb3NzIE9BdXRo 4oCZcyB2YXJpb3VzIGVuZHBvaW50cy4gV2VpcmQgY29tYmluYXRpb25zIGxpa2UgdGhlIOKAnGlh dOKAnSBjbGFpbSBoZXJlIGFyZSBhDQogZHJpdmVyIGZvciBoYXZpbmcgYSBzb2xpZCBnZW5lcmlj IG1lY2hhbmlzbSBpbnN0ZWFkIG9mIGEgaGFuZGZ1bCBvZiBzbGlnaHRseSBkaWZmZXJlbnQgZGVm aW5pdGlvbnMuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5TbyB3aGF0IHNob3VsZCB3ZSBkbyBoZXJlPyBJZiB3ZSBhcmUgdG8g a2VlcCB0aGUgY3VycmVudCBwcmFjdGljZSBvZiBwdXR0aW5nIGV2ZXJ5dGhpbmcgaW4gdGhlIHJv b3Qgb2YgdGhlIEpXVCwgd2Ugc2hvdWxkIGhhdmUgZGlmZmVyZW50IGNsYWltIG5hbWVzIHRvIGRp ZmZlcmVudGlhdGUgdGhlIGVudmVsb3BlIGFuZCB0aGUgdG9rZW4uIFRoZSBwcm9ibGVtIGhlcmUg aXMgdGhhdCDigJxpYXTigJ0gaXMgYWxyZWFkeSBkZWZpbmVkDQogaW4gUkZDNzY2MiBhcyByZWZl cnJpbmcgdG8gdGhlIHRva2VuIGFuZCBpbiBSRkM3NTE5IGFzIHJlZmVycmluZyB0byB0aGUgSldU ICh3aGljaCBpcyBub3QgYSB0b2tlbiwgYnV0IHRoZSBjb250YWluZXIgZm9yIHRoZSB0b2tlbiBp bmZvcm1hdGlvbikuIEnigJltIG5vdCBzdXJlIHdoaWNoIGlzIHdvcnNlLCBkZWZpbmluZyBhbiDi gJxpYXTigJ0gZm9yIHRoZSBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlIG9yIG9uZSBmb3IgdGhlIEpX VCBidXQgb25seSBpbiB0aGlzDQogaW5zdGFuY2UuIEJvdGggZmVlbCByZWFsbHkgbWVzc3ksIGFu ZCBpbiBjYXNlcyBsaWtlIFRvcnN0ZW7igJlzIHRoZXkgY29sbGFwc2UgdG8gdGhlIHNhbWUgdmFs dWUuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5JZiBob3dldmVyIHdlIHB1dCB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZSBpbiBpdHMg b3duIHN1Yi1zZWN0aW9uIG9mIHRoZSBKV1QgcGF5bG9hZCwgdGhlbiB3ZSBjb3VsZCBhdm9pZCB0 aGUgbmFtZXNwYWNlIGNvbGxpc2lvbiBlbnRpcmVseS4gV2Ugd291bGQgbmVlZCBub3JtYXRpdmUg cnVsZXMgbGlrZSBpbiBTRVQgdG8gZGVmaW5lIGhvdyB0aGVzZSBmaWVsZHMgcmVsYXRlIHRvIGVh Y2ggb3RoZXIsIGJ1dCBJIHNlZQ0KIHRoYXQgYXMgYSB0cmFjdGFibGUgcHJvYmxlbSB3aXRoIGEg cmVhc29uYWJsZSAoaWYgaW1wZXJmZWN0KSBwcmVjZWRlbnQuJm5ic3A7PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5FaXRoZXIgcGF0aCBt ZWFucyByZWRvaW5nIFdHTEMgYW5kIHRoZSBhc3NvY2lhdGVkIHJldmlld3MsIEnigJltIGFmcmFp ZC4gTGVhdmluZyBpdCBhcy1pcyB3b3JrcyBmb3IgdGhlIGRyaXZpbmcgdXNlIGNhc2Ugd2hlcmUg dGhlIGluZm9ybWF0aW9uIGlzIGFsbCB0aGUgc2FtZSwgYnV0IEkgZG9u4oCZdCBmaW5kIGl0IHRv IGJlIGEgcGFydGljdWxhcmx5IGNsZWFuIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBpbmZvcm1hdGlv biBpbiBxdWVzdGlvbi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+T24gU2VwIDQsIDIwMTksIGF0IDU6MjEgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0Ozxh IGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgY2xhc3M9IiI+dG9yc3RlbkBs b2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50 ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSBSZW1j byw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj5PbiAzMS4gQXVnIDIwMTksIGF0IDIxOjI3LCBTY2hhYXIsIFIuTS4gKFJlbWNvKSAt IExvZ2l1cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJlbWNvLnNjaGFhckBsb2dpdXMubmwiIGNsYXNz PSIiPnJlbWNvLnNjaGFhckBsb2dpdXMubmw8L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpIZWxsbyBUb3JzdGVuLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CihteSBhcG9sb2dpZXMgZm9yIG1ha2luZyBhIHR5cG8gcHJldmlvdXNseSk8YnIgY2xhc3M9IiI+ DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpUaGFua3MgOi0pPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KVGltZSBvZiBpbnRyb3NwZWN0aW9uIGlzIGNyaXRpY2FsIGlmIHlvdSB3YW50IHRvIHVz ZSB0aGUgc2lnbmVkIGludHJvc3BlY3Rpb248YnIgY2xhc3M9IiI+DQpyZXNwb25zZSBmb3IgbGF0 ZXIgYWNjb3VudGFiaWxpdHkgb3IgYXVkaXQgcHVycG9zZXMuIEZvciBleGFtcGxlLCBhIENsaWVu dDxiciBjbGFzcz0iIj4NCm9idGFpbnMgYW4gYWNjZXNzIHRva2VuIEEgYXQgdGltZSB0LiBOb3cg YSByZXNvdXJjZSBzZXJ2ZXIgcmVjZWl2ZXMgQSBhdCB0aW1lPGJyIGNsYXNzPSIiPg0KdCYjNDM7 MSwgY2FsbHMgaW50cm9zcGVjdGlvbiBhbmQgcmVjZWl2ZXMgYSByZXNwb25zZSBjb250YWluaW5n IGFjdGl2ZT10cnVlLiBBdDxiciBjbGFzcz0iIj4NCnQmIzQzOzIgdGhlIGFjY2Nlc3MgdG9rZW4g aXMgcmV2b2tlZC4gQXQgdGltZSB0JiM0MzszIHRoZSByZXNvdXJjZSBzZXJ2ZXIgbWFrZXMgYSBu ZXc8YnIgY2xhc3M9IiI+DQppbnRyb3NwZWN0aW9uIHJlcXVlc3QsIG5vdyByZWNlaXZlcyBhIHJl c3BvbnNlIGNvbnRhaW5pbmcgYWN0aXZlPWZhbHNlLiBUaGU8YnIgY2xhc3M9IiI+DQpvbmx5IGRp ZmZlcmVuY2Ugd291bGQgYmUgdGhlIHZhbHVlIG9mIHRoZSBhY3RpdmUgcGFyYW1ldGVyLiBXaXRo b3V0IHRoZSB0aW1lPGJyIGNsYXNzPSIiPg0Kb2YgaW50cm9zcGVjdGlvbiBub3IgYSB1bmlxdWUg aWQgY292ZXJlZCBieSB0aGUgc2lnbmF0dXJlLCBvbmUgY2Fubm90IG1ha2UgYTxiciBjbGFzcz0i Ij4NCmNvbmNsdXNpdmUgZGlzdGluY3Rpb24gYmV0d2VlbiBzdWJzZXF1ZW50IHJlc3BvbnNlcyBp ZiByZXZvY2F0aW9uIG1heSBiZSBpbjxiciBjbGFzcz0iIj4NCnBsYXkuPGJyIGNsYXNzPSIiPg0K PC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KVGhhdOKAmXMgYSBnb29kIHBvaW50LiAmbmJz cDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQpUaGUgZHJhZnQgc3BlY2lmaWVzIDxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1suLi5dIHRvIHJldHVybiByZXNwb25zZXMg YXMgSldUcy48YnIgY2xhc3M9IiI+DQpUaGlzIGNvdWxkIGVpdGhlciBtZWFuICZxdW90O3RoZSBy ZXNwb25zZSBpcyByZXR1cm5lZCBpbiBKV1QgZm9ybWF0JnF1b3Q7IG9yICZxdW90O3RoZTxiciBj bGFzcz0iIj4NCnJlc3BvbnNlIGNvbnRhaW5zIGEgSldUIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBp bnNwZWN0ZWQgdG9rZW7igJ0uPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNz PSIiPg0KSSdtIG1lYW53aGlsZSBsZWFuaW5nIHRvd2FyZHMgJnF1b3Q7dGhlIHJlc3BvbnNlIGlz IHJldHVybmVkIGluIEpXVCBmb3JtYXTigJ0uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+Tm90IGhhdmluZzxiciBjbGFzcz0iIj4N CmNsZWFyLCBzZXBhcmF0ZSBwYXJhbWV0ZXJzIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gdGhlIHRp bWUgYW5kIGlkIG9mIHRoZTxiciBjbGFzcz0iIj4NCnRva2VuIGFuZCB0aGUgdGltZSBhbmQgaWQg b2YgdGhlIHJlc3BvbnNlIHJlc3VsdHMgaW4gZG91YmxlIG1lYW5pbmcuIEFzIGE8YnIgY2xhc3M9 IiI+DQpjb25zZXF1ZW5jZSwgaXQgaXMgZWl0aGVyIGhhdmluZyB0aGUgcmlzayBvZiByZXBsYXkg b2YgYW4gYWNjZXNzIHRva2VuIG9yPGJyIGNsYXNzPSIiPg0KcmVwbGF5IG9mIGFuIGludHJvc3Bl Y3Rpb24gcmVzcG9uc2UgaW5zdGVhZCBvZiBuZWl0aGVyLjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxiciBjbGFzcz0iIj4NCknigJltIG5vdCBzdXJlIGhvdyBhbiBhdHRhY2tlciBjb3Vs ZCByZXBsYXkgYW4gaW50cm9zcGVjdGlvbiByZXNwb25zZSBnaXZlbiBpdCBpcyB0aWdodGVkIHRv IGEgY2VydGFpbiBlbmRwb2ludCB2aWEgdGhlIGlzcyBjbGFpbS4NCjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCkkgYWdyZWUgdGhlIFJTIGxhY2tzIGEgd2F5IHRvIHByb29mIHdoZW4gaXQg d2FzIHByb3ZpZGVkIHdpdGggdGhlIGFjY2VzcyB0b2tlbiBkYXRhIGJ5IHRoZSBBUy4NCjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBwcm9ibGVtIGluIG15IG9waW5pb24gaXMgdGhl IG92ZXJsYXkgYmV0d2VlbiB0aGUgb3JpZ2luYWwgYWNjZXNzIHRva2VuIGRhdGEgKGUuZy4gd2hl biB3YXMgaXQgaXNzdWVkIGJ5IHRoZSBBUykgYW5kIHRoZSBkYXRhIGJlbG9uZ2luZyB0byB0aGUg cmVwcmVzZW50YXRpb24gaW4gdGhlIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgKHdoZW4gd2FzIHRo ZSByZXNwb25zZSBjcmVhdGVkKS4gQ29uY2VwdHVhbGx5LCB0aGlzIG1lYW5zIHdlIHJlcXVpcmUN CiB0d28gc2VwYXJhdCDigJxpYXQmcXVvdDsgKGFsaWtlKSBjbGFpbXMgdG8gZGlzdGluZ3Vpc2gg Ym90aCBhc3BlY3RzLiA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGNvdWxkIGltYWdl IHR3byB3YXlzIHRvIGhhbmRsZSB0aGlzOjxiciBjbGFzcz0iIj4NCi0gYWRkIGFub3RoZXIgaWF0 IGNsYWltLCBlLmcuIOKAnHRpcl9pYXQmcXVvdDssIHRvIHRoZSBKV1Q8YnIgY2xhc3M9IiI+DQot IGFkZCBhbm90aGVyIOKAnGlhdCZxdW90OyBjbGFpbSB0byB0aGUgSldTIGhlYWRlciBjb250YWlu aW5nIHRoZSBpbnN0YW50IHdoZW4gdGhlIHRva2VuIGludHJvc3BlY3Rpb24gcmVzcG9uc2Ugd2Fz IGNyZWF0ZWQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpXaGF0IGRvIHlvdSB0aGluaz88 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpiZXN0IHJlZ2FyZHMsPGJyIGNsYXNzPSIiPg0K VG9yc3Rlbi4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KS2luZCByZWdhcmRzLDxiciBjbGFzcz0iIj4N ClJlbWNvIHNjaGFhcjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tLS0tT29yc3Byb25r ZWxpamsgYmVyaWNodC0tLS0tPGJyIGNsYXNzPSIiPg0KVmFuOiBUb3JzdGVuIExvZGRlcnN0ZWR0 ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIGNsYXNzPSIiPnRv cnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiZndDsNCjxiciBjbGFzcz0iIj4NClZlcnpvbmRlbjog d29lbnNkYWcgMjggYXVndXN0dXMgMjAxOSAxMToxNDxiciBjbGFzcz0iIj4NCkFhbjogU2NoYWFy LCBSLk0uIChSZW1jbykgLSBMb2dpdXMgJmx0OzxhIGhyZWY9Im1haWx0bzpyZW1jby5zY2hhYXJA bG9naXVzLm5sIiBjbGFzcz0iIj5yZW1jby5zY2hhYXJAbG9naXVzLm5sPC9hPiZndDs8YnIgY2xh c3M9IiI+DQpDQzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiBjbGFzcz0iIj5vYXV0 aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpPbmRlcndlcnA6IFJlOiBbT0FVVEgtV0ddIFF1 ZXN0aW9uIHJlZ2FyZGluZyBkcmFmdC1pZXRmLW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3Bv bnNlLTA1PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSGkgUmhlbWNvLDxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPk9uIDI2 LiBBdWcgMjAxOSwgYXQgMDk6NDIsIFNjaGFhciwgUi5NLiAoUmVtY28pIC0gTG9naXVzICZsdDs8 YSBocmVmPSJtYWlsdG86cmVtY28uc2NoYWFyQGxvZ2l1cy5ubCIgY2xhc3M9IiI+cmVtY28uc2No YWFyQGxvZ2l1cy5ubDwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CkhlbGxvIFRob3JzdGVuLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoYW5rIHlvdSBm b3IgeW91ciByZXNwb25zZS4gSSBoYXZlIGEgZmV3IG1vcmUgcXVlc3Rpb25zL2NvbW1lbnRzIGFz PGJyIGNsYXNzPSIiPg0KZm9sbG93LXVwLi4uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K WW91IHN0YXRlIHRoYXQgUkZDNzUxOSBhbmQgUkZDNzY2MiAmcXVvdDtqdXN0JnF1b3Q7IGRlZmlu ZSBkaWZmZXJlbnQgcmVwcmVzZW50YXRpb25zPGJyIGNsYXNzPSIiPg0KZm9yIHRva2VuIGRhdGEu IElmIHRoZSBkcmFmdCBSRkMgd291bGQgcmVmZXIgdG8gUkZDIDc1MTUgKEpXUyksIEkgd291bGQ8 YnIgY2xhc3M9IiI+DQphZ3JlZS4gSG93ZXZlciwgUkZDNzUxOSAoSldUKSBleHBsaWNpdGx5IGFk ZHMgc2VtYW50aWNzIHRvIHNvbWUgc3BlY2lmaWM8YnIgY2xhc3M9IiI+DQpwYXJhbWV0ZXJzIChl LmcuIGF1ZCwganRpIGFuZCBpYXQpLiBSRkM3NjYyIGhhcyBkaWZmZXJlbnQgc2VtYW50aWNzIGZv cjxiciBjbGFzcz0iIj4NCnRoZSBzZXZlcmFsIG9mIHRoZSBzYW1lIHBhcmFtZXRlcnMuPGJyIGNs YXNzPSIiPg0KRm9yIGluc3RhbmNlIHRoZSAnaWF0JywgaXMgdGhlIG1vbWVudCBvZiBpc3N1YW5j ZSBvZiB0aGUgSldUIGluIFJGQzc1MTkuIEluPGJyIGNsYXNzPSIiPg0KUkZDNzY2MiB0aGF0IGlz IHRoZSAmcXVvdDt3aGVuIHRoaXMgdG9rZW4gd2FzIG9yaWdpbmFsbHkgaXNzdWVkJnF1b3Q7LiBU aGlzIHRpbWUgd2lsbDxiciBjbGFzcz0iIj4NCnZhcnkgaW4gdXNlIGNhc2VzIHdpdGhvdXQgaW1t ZWRpYXRlIGludHJvc3BlY3Rpb24gb2YgYW4gYWNjZXNzIHRva2VuLjxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkkgcmVhZCB0aGUgdGV4dCBkaWZmZXJlbnRseS4g SW4gbXkgaW50ZXJwcmV0YXRpb24g4oCcd2hlbiB0aGUgdG9rZW4gd2FzIG9yaWdpbmFsbHkgaXNz dWVk4oCdIHN0YXRlZCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgaW50cm9zcGVjdGlvbiBl bmRwb2ludCByZWZlcnMgZXhhY3RseSB0byB0aGUgc2FtZSBpbnN0YW50IGFzIOKAnHRoZSB0aW1l IGF0IHdoaWNoIHRoZSBKV1Qgd2FzPGJyIGNsYXNzPSIiPg0KJm5ic3A7aXNzdWVk4oCdLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCkZvciB0aGUgdXNlIGNhc2Ugb2YgdGhlIHJlc291cmNlIHNlcnZlciBy ZWx5aW5nIG9uIHZlcmlmaWFibGUgZGF0YSwgYXM8YnIgY2xhc3M9IiI+DQpkZXNjcmliZWQgaW4g dGhlIGludHJvZHVjdGlvbiBvZiB0aGUgZHJhZnQgUkZDLCB0aGUgdGltZSBvZiB0aGUgaW50cm9z cGVjdGlvbjxiciBjbGFzcz0iIj4NCmlzIGNyaXRpY2FsLjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxiciBjbGFzcz0iIj4NCldoeSBpcyB0aGlzIHRpbWUgY3JpdGljYWw/PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SW4g cGFydGljdWxhciB3aGVuIGNvbWJpbmVkIHdpdGggcmV2b2NhdGlvbiwgdGhlIHRpbWUgb2Y8YnIg Y2xhc3M9IiI+DQppbnRyb3NwZWN0aW9uIGFuZCB0aGUgJ2FjdGl2ZScgc3RhdHVzIGNhbiBkaWZm ZXIgYmV0d2VlbiB0d28gc3Vic2VxdWVudCBjYWxsczxiciBjbGFzcz0iIj4NCmZvciBpbnRyb3Nw ZWN0aW9uLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClRoZSBz dGF0dXMgYXQgdG9rZW4gaW50cm9zcGVjdGlvbiByZXF1ZXN0IHRpbWUgaXMgaW5kZWVkIGNyaXRp Y2FsLiBSRkMgNzY2MiBnaXZlcyBhIGdvb2QgaW5kaWNhdGlvbiBob3cgdGhpcyB2YWx1ZSBzaG91 bGQgYmUgY2FsY3VsYXRlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQrigJzigKYgYSAm cXVvdDt0cnVlJnF1b3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dmFs dWUgcmV0dXJuIGZvciB0aGUgJnF1b3Q7YWN0aXZlJnF1b3Q7IHByb3BlcnR5IHdpbGwgZ2VuZXJh bGx5IGluZGljYXRlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhhdCBh IGdpdmVuIHRva2VuIGhhcyBiZWVuIGlzc3VlZCBieSB0aGlzIGF1dGhvcml6YXRpb24gc2VydmVy LDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2hhcyBub3QgYmVlbiByZXZv a2VkIGJ5IHRoZSByZXNvdXJjZSBvd25lciwgYW5kIGlzIHdpdGhpbiBpdHM8YnIgY2xhc3M9IiI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtnaXZlbiB0aW1lIHdpbmRvdyBvZiB2YWxpZGl0eSAo ZS5nLiwgYWZ0ZXIgaXRzIGlzc3VhbmNlIHRpbWUgYW5kPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7YmVmb3JlIGl0cyBleHBpcmF0aW9uIHRpbWUpLiZxdW90OyA8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTbyBpdCByZXByZXNlbnRzIHRoZSByZXN1bHRzIG9mIHRo ZSBpc3N1ZXIgY2hlY2ssIHRoZSByZXZvY2F0aW9uIGNoZWNrIGFuZCB0aGUgdmFsaWRpdHkgY2hl Y2sgaW4gb25lIGJvb2xlYW4gdmFsdWUuDQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpJZiB0aGUgZHJh ZnQgUkZDIGp1c3QgcHJvZHVjZXMgYSBKV1QgcmVwcmVzZW50YXRpb24gb2YgdGhlIGFjY2VzcyB0 b2tlbiw8YnIgY2xhc3M9IiI+DQppbmNsdWRpbmcgJ2FjdGl2ZScgd291bGQgbm90IG1ha2Ugc2Vu c2UgYXMgdGhlIEpXVCB3aWxsIGV4cGlyZSB3aXRob3V0PGJyIGNsYXNzPSIiPg0KdXBkYXRpbmcg aXQgdG8gZmFsc2UuIExlYXZpbmcgJ2FjdGl2ZScgb3V0IHdvdWxkIG1ha2UgaXQgaW5jb21wYXRp YmxlIHdpdGg8YnIgY2xhc3M9IiI+DQpSRkM3NjYyIGludHJvc3BlY3Rpb24gcmVzcG9uc2VzLjxi ciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCuKAnGFjdGl2ZeKAnSBp cyBub3QgcGFydCBvZiB0aGUgSldUIHJlcHJlc2VudGF0aW9uIEkgcmVmZXJyZWQgdG8uIFRoZSBB UyBuZWVkcyB0byBkZXRlcm1pbmUgdGhlIGFjdGl2ZSB2YWx1ZSBmb3IgZXZlcnkgdG9rZW4gaW50 cm9zcGVjdGlvbiByZXF1ZXN0Lg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSWYgdGhl IFJTIHdvdWxkIGNvbnN1bWUgSldUcywgaXQgd291bGQgZGV0ZXJtaW5lIHRoZSDigJxhY3RpdmXi gJ0gdmFsdWUgaXRzZWxmIGJ5IGluc3BlY3RpbmcgdGhlIGlzcyBjbGFpbSBhbmQgY2hlY2sgYWdh aW5zdCBpdHMgQVMgd2hpdGVsaXN0LCBjaGVjayB0aGUgc2lnbmF0dXJlIGFuZCB0aGUgaWF0ICZh bXA7IGV4cCB2YWx1ZXMuIERldGVybWluaW5nIHRoZSByZXZvY2F0aW9uIHN0YXR1cyB3b3VsZCBy ZXF1aXJlIGFuIGluZm9ybWF0aW9uIGV4Y2hhbmdlDQogd2l0aCB0aGUgQVMgb2Ygc29tZSBzb3J0 LiA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj5TaW1pbGFyLCBub3QgaW5jbHVkaW5nIGEgdW5pcXVlICdqdGknIHBlciBpbnRyb3Nw ZWN0aW9uIHJlc3BvbnNlIHdvdWxkIG1ha2U8YnIgY2xhc3M9IiI+DQp0aGUgcmVzb3VyY2Ugc2Vy dmVyIHZ1bG5lcmFibGUgdG8gcmVwbGF5IGF0dGFja3MuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1 b3RlPg0KPGJyIGNsYXNzPSIiPg0KVG8gdGhlIGNvbnRyYXJ5LCBpbmNsdWRpbmcgYSBkaWZmZXJl bnQg4oCcaml0JnF1b3Q7IHdpdGggZXZlcnkgdG9rZW4gaW50cm9zcGVjdGlvbiByZXNwb25zZSB3 b3VsZCBtYWtlIHRoZSBSUyB2dWxuZXJhYmxlIHRvIHJlcGxheSBvZiBvbmUgdGltZSBhY2Nlc3Mg dG9rZW4gc2luY2UgaXQgcmVtb3ZlIHRoZSBwb3NzaWJpbGl0eSBmb3IgdGhlIFJTIHRvIGlkZW50 aXR5IGEgY2VydGFpbiBhY2Nlc3MgdG9rZW4uDQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PciB0aGUgcmVzb3VyY2Ugc2VydmVy PGJyIGNsYXNzPSIiPg0Kd291bGQgbWlzdGFrZW5seSByZWZlciB0byBub24tdW5pcXVlIHRva2Vu cywgbWFraW5nIHRoZSByZXNwb25zZXMgdW5zdWl0YWJsZTxiciBjbGFzcz0iIj4NCmZvciBhY2Nv dW50YWJpbGl0eSBhbmQgYXVkaXQgcHVycG9zZXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KQXMgdG8gd2h5IHNvbWVvbmUgd291bGQgd2FudCB0byBkaXN0aW5n dWlzaCBhIEpXVCBhY2Nlc3MgdG9rZW4gZnJvbSBhbjxiciBjbGFzcz0iIj4NCmludHJvc3BlY3Rp b24gcmVzcG9uc2U6IHNldmVyYWwgdXNlIGNhc2VzIGNvbWUgdG8gbWluZC48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpGaXJzdCBvZiBhbGwsIGV2ZW4gaWYgb25lIGlzIHVzaW5nIHN0YW5k YWxvbmUgaW50ZXJwcmV0YWJsZSBKV1QgYWNjZXNzIHRva2Vucyw8YnIgY2xhc3M9IiI+DQpvbmUg bWF5IHdhbnQgdG8gY29tYmluZSB0aGF0IHdpdGggcmV2b2NhdGlvbiBjaGVja2luZyB1c2luZyBp bnRyb3NwZWN0aW9uLiBUaGU8YnIgY2xhc3M9IiI+DQppbnRlcnByZXRhdGlvbiBhbmQgbWVhbmlu ZyBvZiB0aGUgSldUIGFuZCB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZSB0aGFuIGRvPGJyIGNs YXNzPSIiPg0KZGlmZmVyIGFuZCBtYXR0ZXIuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0K PGJyIGNsYXNzPSIiPg0KQXMgSSBkZXNjcmliZWQgYWJvdmUsIEkgZG9u4oCZdCBzZWUgYW55IGRp ZmZlcmVuY2UuIDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkFub3RoZXIgdXNlIGNhc2Ugd291bGQgYmUg YSBtaXhlZCBlY29zeXN0ZW0gd2l0aCByZXNvdXJjZSBzZXJ2ZXJzIHJlbHlpbmcgb248YnIgY2xh c3M9IiI+DQppbnRyb3NwZWN0aW9uIHdoaWxlIG90aGVycyBkbyBwYXJzZSBKV1QgYWNjZXNzIHRv a2Vucy4gQSBzaW5nbGUsIHVuaWZvcm08YnIgY2xhc3M9IiI+DQppbXBsZW1lbnRhdGlvbiBmb3Ig dGhlIEFTIHdvdWxkIHRoYW4gbWl4IGJvdGggYXMgd2VsbC48YnIgY2xhc3M9IiI+DQo8L2Jsb2Nr cXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpTZWUgYWJvdmUgLSBJIGRvbuKAmXQgc2VlIGFueSBpc3N1 ZS4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KQSBsYXN0IHVzZSBjYXNlIGNvdWxkIGJlIGV4Y2hhbmdp bmcgYWNjZXNzIHRva2VucyB3aXRoIGEgc3Vic2V0IG9mIHRoZSBmdWxsPGJyIGNsYXNzPSIiPg0K c2V0IG9mIGFwcGxpY2FibGUgcGFyYW1ldGVycywgdG8gcmVkdWNlIHRoZSBzaXplIG9mIGFjY2Vz cyB0b2tlbnMuIEFkZGl0aW9uYWw8YnIgY2xhc3M9IiI+DQppbmZvcm1hdGlvbiBjYW4gYmUgZXhj aGFuZ2VkIHZpYSBpbnRyb3NwZWN0aW9uLCByZXN1bHRpbmcgaW4gbWl4ZWQgSldUIGFjY2Vzczxi ciBjbGFzcz0iIj4NCnRva2VucyBhbmQgaW50cm9zcGVjdGlvbiBhcyB3ZWxsLjxiciBjbGFzcz0i Ij4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClRoYXTigJlzIGFsbCBwb3NzaWJsZSB3 aXRoaW4gdGhlIGN1cnJlbnQgdGV4dC4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0Ka2lu ZCByZWdhcmRzLDxiciBjbGFzcz0iIj4NClRvcnN0ZW4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KS2lu ZCByZWdhcmRzLDxiciBjbGFzcz0iIj4NClJlbWNvIFNjaGFhcjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCi0tLS0tT29yc3Byb25rZWxpamsgYmVyaWNodC0tLS0tPGJyIGNsYXNzPSIiPg0K VmFuOiBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2Rk ZXJzdGVkdC5uZXQiIGNsYXNzPSIiPnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiZndDsNCjxi ciBjbGFzcz0iIj4NClZlcnpvbmRlbjogemF0ZXJkYWcgMTcgYXVndXN0dXMgMjAxOSAxNDowMDxi ciBjbGFzcz0iIj4NCkFhbjogU2NoYWFyLCBSLk0uIChSZW1jbykgLSBMb2dpdXMgJmx0OzxhIGhy ZWY9Im1haWx0bzpyZW1jby5zY2hhYXJAbG9naXVzLm5sIiBjbGFzcz0iIj5yZW1jby5zY2hhYXJA bG9naXVzLm5sPC9hPiZndDs8YnIgY2xhc3M9IiI+DQpDQzogPGEgaHJlZj0ibWFpbHRvOm9hdXRo QGlldGYub3JnIiBjbGFzcz0iIj5vYXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpPbmRl cndlcnA6IFJlOiBbT0FVVEgtV0ddIFF1ZXN0aW9uIHJlZ2FyZGluZyBkcmFmdC1pZXRmLW9hdXRo LWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNlLTA1PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KSGkgUmVtY28sPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+T24gNi4gQXVnIDIwMTksIGF0IDE2OjAxLCBTY2hhYXIsIFIuTS4g KFJlbWNvKSAtIExvZ2l1cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJlbWNvLnNjaGFhckBsb2dpdXMu bmwiIGNsYXNzPSIiPnJlbWNvLnNjaGFhckBsb2dpdXMubmw8L2E+Jmd0OyB3cm90ZTo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpIZWxsbyw8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQo8YnIgY2xhc3M9IiI+DQpbLi4uXTxiciBjbGFzcz0iIj4NClJGQyA3NTE5IGFuZCBSRkMgNzY2 MiDigJxqdXN04oCdIGRlZmluZSBkaWZmZXJlbnQgcmVwcmVzZW50YXRpb25zIGZvciB0b2tlbiBk YXRhLiBJbiBSRkMgNzUxOSB0aGUgZGF0YSBpcyBjYXJyaWVkIGluIHRoZSB0b2tlbiBpdHNlbGYg KHdoaWNoIGFsc28gbWVhbnMgdGhlIGZvcm1hdCBvZiB0aGUgdG9rZW4gaXMgd2VsbC1kZWZpbmVk IGFuZCBrbm93IHRvIHRoZSBSUykgd2hlcmVhcyBSRkMgNzY2MiBkZWZpbmVzIGEgd2F5IHRvIGlu c3BlY3QgdG9rZW5zDQogdmlhIGFuIEFQSSBwcm92aWRlZCBieSB0aGUgQVMuIFRoZSBsYXR0ZXIg aXMgdHlwaWNhbGx5IHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aCBvcGFxdWUgdG9rZW5zLCBpLmUu IHRoZSBSUyBkb2VzIG5vdCBoYXZlIGEgY2x1ZSBob3cgdG8gcGFyc2UgYW5kIGludGVycHJldCB0 aGUgdG9rZW4uIFRoZSB0b2tlbiBtaWdodCBqdXN0IGJlIGEgaGFuZGxlIHRvIGEgZGF0YWJhc2Ug ZW50cnkgYXQgdGhlIEFTIGluIHRoaXMgY2FzZS4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NClRoaXMgYWxzbyBtZWFucyBhIEpXVCAoUkZDIDc2NjIpIGFuZCB0aGUgSW50cm9zcGVjdGlv biBSZXNwb25zZSBhcmUgY29uY2VwdHVhbGx5IHRoZSBzYW1lIGZyb20gYSBSU3MgcGVyc3BlY3Rp dmUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KWy4uLl08YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5UaGUg4oCYanRp4oCZ IHBhcmFtZXRlciBob3dldmVyIHdpbGwgYWx3YXlzIGJlIGFtYmlndW91cy4gQXMgaXQgaXMgYW4g aWRlbnRpZmllciwgaXQgc2hvdWxkIGRpZmZlciBmb3IgdGhlIGludHJvc3BlY3RlZCB0b2tlbiBh bmQgdGhlIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgYnkgZGVmaW5pdGlvbi4gSGVuY2UgdGhlIHNl bWFudGljcyBvZiDigJhqdGnigJkgaW4gYSBKV1QgaW50cm9zcGVjdGlvbiByZXNwb25zZQ0KIGlz IHVuY2xlYXIuIFRoZSBzYW1lIGNhbiBhcHBseSB0byB0aGUg4oCYaWF04oCZLCDigJhuYmbigJkg YW5kIOKAmGV4cOKAmSBjbGFpbXMgaW4gYSBKV1QgaW50cm9zcGVjdGlvbiByZXNwb25zZS48YnIg Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpJIGRvbuKAmXQgdW5kZXJz dGFuZCB0aGUgZGlmZmVyZW5jZSB5b3UgYXJlIG1ha2luZy4gQWxsIGJlZm9yZSBtZW50aW9uZWQg Y2xhaW1zIGFyZSByZWxhdGVkIHRvIHRoZSAoYWJzdHJhY3QpIGFjY2VzcyB0b2tlbi4gWW91IG1h eSB0aGluayBvZiB0aGUgSW50cm9zcGVjdGlvbiBSZXNwb25zZSBhcyBfdGhlXyBKV1QgcmVwcmVz ZW50YXRpb24gb2YgdGhlIGFjY2VzcyB0b2tlbiBwcm9kdWNlZCBieSB0aGUgQVMgZm9yIHRoZSBS Uy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQpDYW4gc29tZW9uZSBjbGFyaWZ5IHRoZSBzZW1hbnRpY3Mg b2YgY2xhaW1zIGluIGFuIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgSldUIHRoYXQgYXJlIGRlZmlu ZWQgaW4gYm90aCBSRkM3NjYyIGFuZCBSRkM3NTE5PzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCkZ1cnRoZXJtb3JlLCB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZSBzaG91bGQgdXNlIHRo ZSDigJhpc3PigJkgYW5kIOKAmGF1ZOKAmSBjbGFpbXMgdG8gYXZvaWQgY3Jvc3MtSldUIGNvbmZ1 c2lvbiAoc2VjdGlvbiA2LjEpLiBUaGUg4oCYaXNz4oCZIGFuZCDigJhhdWTigJkgb2YgYW4gaW50 cm9zcGVjdGVkIHRva2VuIHdpbGwgdHlwaWNhbGx5IGJlIHRoZSBzYW1lIGFzIHRob3NlIG9mIHRo ZSBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlLiBIZW5jZSBhIEpXVCBhY2Nlc3MgdG9rZW4NCiBjYW5u b3QgYmUgZGlzdGluZ3Vpc2hlZCBmcm9tIGFuIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgdXNpbmcg 4oCYaXNz4oCZIGFuZCDigJhhdWTigJkgYXMgc3VnZ2VzdGVkIGluIHRoZSBkcmFmdC4uPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSW50cm9zcGVjdGlvbiByZWZlcnMgdG8gSldUIGJlc3Qt Y3VycmVudC1wcmFjdGljZS4gVGhlIGRyYWZ0IEJDUCByZWNvbW1lbmRzIHVzaW5nIGV4cGxpY2l0 IHR5cGluZyBvZiBKV1RzLCBob3dldmVyIHRoZSBkcmFmdCBKV1QgcmVzcG9uc2UgZm9yIGludHJv c3BlY3Rpb24gZG9lcyBub3QgYXBwbHkgdGhpcyByZWNvbW1lbmRhdGlvbiBhbmQgdXNlcyB0aGUg Z2VuZXJpYyDigJhhcHBsaWNhdGlvbi9qd3TigJkgaW5zdGVhZC4uLiBUaGUgQkNQIGhhcyBvdGhl cg0KIHJlY29tbWVuZGF0aW9ucyBpbiBzZWN0aW9uIDMuMTIsIGJ1dCB0aGVzZSBtYXkgYmUgaW5z dWZmaWNpZW50IHRvIGRpc3Rpbmd1aXNoIGEgSldUIGFjY2VzcyB0b2tlbiBmcm9tIGEgSldUIGlu dHJvc3BlY3Rpb24gcmVzcG9uc2UuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNs YXNzPSIiPg0KR29vZCBwb2ludC4gVGhlIHJlYXNvbiB3aHkgdGhlIEJDUCByZWNvbW1lbmRzIGV4 cGxpY2l0IHR5cGluZyBpcyB0byBwcmV2ZW50IHJlcGxheSBpbiBvdGhlciBjb250ZXh0cy4gSW4g dGhlIGVuZCB0eXBpbmcgaXMgYSBjb21wZWxsaW5nIGNvbmNlcHQgdW5mb3J0dW5hdGVseSBub3Qg YnJvYWRseSB1c2VkIGluIHRoZSB3aWxkLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNv IHRoZSBKV1QgSW50cm9zcGVjdGlvbiBSZXNwb25zZSBkcmFmdCBjb3BlcyB3aXRoIHRoYXQgYXR0 YWNrIGFuZ2xlIGJ5IG1ha2luZyBpc3MgYW5kIGF1ZCBtYW5kYXRvcnkuDQo8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQpIb3cgd291bGQgcGVvcGxlIHN1Z2dlc3QgdG8gYmVzdCBk aXN0aW5ndWlzaCBhIEpXVCAoYWNjZXNzKSB0b2tlbiBmcm9tIGEgSldUIGludHJvc3BlY3Rpb24g cmVzcG9uc2U/PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KV2h5 IHNob3VsZCB5b3U/IE9uZSByZWFzb24gd2h5IHdlIGV4dGVuZGVkIHRoZSBJbnRyb3NwZWN0aW9u IFJlc3BvbnNlIHdhcyB0byBlbGltaW5hdGUgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBKV1RzIGRp cmVjdGx5IHVzZWQgYXMgYWNjZXNzIHRva2VucyBhbmQgSW50cm9zcGVjdGlvbiBSZXNwb25zZXMu PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KYmVzdCByZWdhcmRzLDxiciBjbGFzcz0iIj4N ClRvcnN0ZW4uIDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkRp dCBiZXJpY2h0IGthbiBpbmZvcm1hdGllIGJldmF0dGVuIGRpZSBuaWV0IHZvb3IgdSBpcyBiZXN0 ZW1kLiBJbmRpZW4gdSBuaWV0IGRlIGdlYWRyZXNzZWVyZGUgYmVudCBvZiBkaXQgYmVyaWNodCBh YnVzaWV2ZWxpamsgYWFuIHUgaXMgdG9lZ2V6b25kZW4sIHdvcmR0IHUgdmVyem9jaHQgZGF0IGFh biBkZSBhZnplbmRlciB0ZSBtZWxkZW4gZW4gaGV0IGJlcmljaHQgdGUgdmVyd2lqZGVyZW4uIERl IFN0YWF0IGFhbnZhYXJkdCBnZWVuIGFhbnNwcmFrZWxpamtoZWlkDQogdm9vciBzY2hhZGUsIHZh biB3ZWxrZSBhYXJkIG9vaywgZGllIHZlcmJhbmQgaG91ZHQgbWV0IHJpc2ljbydzIHZlcmJvbmRl biBhYW4gaGV0IGVsZWt0cm9uaXNjaCB2ZXJ6ZW5kZW4gdmFuIGJlcmljaHRlbi48YnIgY2xhc3M9 IiI+DQpUaGlzIG1lc3NhZ2UgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpcyBub3QgaW50 ZW5kZWQgZm9yIHlvdS4gSWYgeW91IGFyZSBub3QgdGhlIGFkZHJlc3NlZSBvciBpZiB0aGlzIG1l c3NhZ2Ugd2FzIHNlbnQgdG8geW91IGJ5IG1pc3Rha2UsIHlvdSBhcmUgcmVxdWVzdGVkIHRvIGlu Zm9ybSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UuIFRoZSBTdGF0ZSBhY2NlcHRz IG5vIGxpYWJpbGl0eSBmb3IgZGFtYWdlIG9mIGFueSBraW5kDQogcmVzdWx0aW5nIGZyb20gdGhl IHJpc2tzIGluaGVyZW50IGluIHRoZSBlbGVjdHJvbmljIHRyYW5zbWlzc2lvbiBvZiBtZXNzYWdl cy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVv dGU+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4N CjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8 L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9F5DA44DBD3C43B2A88C66394BD7BE85mitedu_-- From nobody Wed Sep 4 13:00:10 2019 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 40A16120CA6; Wed, 4 Sep 2019 13:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 KBbg-TtHkkV7; Wed, 4 Sep 2019 12:59:56 -0700 (PDT) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (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 DA491120B56; Wed, 4 Sep 2019 12:59:55 -0700 (PDT) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id x84JxZpX021128; Wed, 4 Sep 2019 15:59:42 -0400 Received: from oc11expo8.exchange.mit.edu (18.9.4.13) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 4 Sep 2019 15:58:38 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo8.exchange.mit.edu (18.9.4.13) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 4 Sep 2019 15:59:32 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Wed, 4 Sep 2019 15:59:32 -0400 From: Justin Richer To: Benjamin J Kaduk CC: The IESG , "oauth@ietf.org" , "draft-ietf-oauth-jwt-introspection-response@ietf.org" , "oauth-chairs@ietf.org" Thread-Topic: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and COMMENT) Thread-Index: AQHVYd/+guOgpm1lFkSXlmUoiSGPGqccNdcA Date: Wed, 4 Sep 2019 19:59:32 +0000 Message-ID: <47A41441-F1A9-4401-BBF3-74CA1F178A0B@mit.edu> References: <156746426740.13074.1850379334333790613.idtracker@ietfa.amsl.com> In-Reply-To: <156746426740.13074.1850379334333790613.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_47A41441F1A94401BBF374CA1F178A0Bmitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and COMMENT) 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: Wed, 04 Sep 2019 20:00:01 -0000 --_000_47A41441F1A94401BBF374CA1F178A0Bmitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIG9mIHRoZSBpc3N1ZXMgSSBoYXZlIHdpdGggdGhlIGN1cnJlbnQgc3RydWN0dXJlIGFsaWdu cyB3aXRoIEJlbuKAmXMgY29tbWVudHMgYmVsb3cg4oCUIHdlIGhhdmUgdHdvIHRoaW5ncyB0aGF0 IGZlZWwgdG9rZW4taXNoLCB0aGUgaW5wdXQgdG9rZW4gYW5kIHRoZSByZXN1bHRpbmcgSldUIHJl c3BvbnNlLiBIb3dldmVyLCB0aGUgSldUIGluIHRoZSByZXNwb25zZSBpcyBub3QgYWN0dWFsbHkg YSA6dG9rZW46IGluIHRoZSBPQXV0aCBzZW5zZS4gSW5zdGVhZCwgaXTigJlzIGFuIGFzc2VydGlv biB0aGF0IGNhcnJpZXMgcGF5bG9hZCBpbmZvcm1hdGlvbiA6YWJvdXQ6IGEgdG9rZW4uIFRoZSBy ZXNwb25zZSBpdHNlbGYgaXNu4oCZdCBhIHRva2VuIGFuZCBzaG91bGRu4oCZdCBiZSB0cmVhdGVk IGFzIGEgdG9rZW4gdW50byBpdHNlbGYuDQoNCuKAlCBKdXN0aW4NCg0KT24gU2VwIDIsIDIwMTks IGF0IDY6NDQgUE0sIEJlbmphbWluIEthZHVrIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRm Lm9yZzxtYWlsdG86bm9yZXBseUBpZXRmLm9yZz4+IHdyb3RlOg0KDQpCZW5qYW1pbiBLYWR1ayBo YXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYt b2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVzcG9uc2UtMDc6IERpc2N1c3MNCg0KV2hlbiByZXNw b25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8g YWxsDQplbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZl ZWwgZnJlZSB0byBjdXQgdGhpcw0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoN Cg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rp c2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVND VVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGgg b3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJl c3BvbnNlLw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRElTQ1VTUzoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K UGVyIHRoZSBvbmdvaW5nIGRpc2N1c3Npb24gb24gdGhlIFdHIGxpc3QsIGl0J3MgdW5jbGVhciB0 aGF0IHdlIGNhbg0KcmV0YWluIHRoZSBiZWhhdmlvcnMgd2UgZGVzY3JpYmUgYW5kIHN0aWxsIGNv bXBseSB3aXRoIHRoZSByZXF1aXJlbWVudHMNCm9mIFJGQyA3NTE5IHJlcXVpcmVtZW50cyBmb3Ig YmVpbmcgYSBKV1QgKGUuZy4sIHJlZ2FyZGluZyAianRpIiwgImlhdCIsDQpldGMuKS4gIFRoYXQg aXMsIGluIHRoZSBwcmVzZW50IGZvcm11bGF0aW9uLCB0aGVyZSBhcmUgdHdvICJ0b2tlbiJzDQpp bnZvbHZlZCAtLSB0aGUgaW5wdXQgdGhhdCBpcyBiZWluZyBpbnRyb3NwZWN0ZWQsIGFuZCB0aGUg InRva2VuIiB0aGF0DQppcyB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZS4gIFdlIGFyZSBjbGFp bWluZyB0aGF0IGNlcnRhaW4gZmllbGRzIGFyZQ0KZGVzY3JpYmluZyB0aGUgaW5wdXQgdG9rZW4s IHdoZW4gdGhleSBhcmUgZGVmaW5lZCB0byBiZSBzdGF0ZW1lbnRzIGFib3V0DQp0aGUgY3VycmVu dCAocmVzcG9uc2UpIHRva2VuLg0KUmVsYXhpbmcgb3VyIHN0YXRlbWVudHMgdG8gc2F5IHRoYXQg d2UgbWVyZWx5IHVzZSBKV1MgYXMgb3Bwb3NlZCB0byBKV1QNCm1heSBiZSBhIHdvcmthcm91bmQs IHRob3VnaCBJIGhhdmUgdGhvdWdodCBhYm91dCBpdCBoYXJkIGVub3VnaCB0byBoYXZlDQphbiBv cGluaW9uIG9uIHdoZXRoZXIgaXQgaXMgdGhlIGJlc3Qgd29ya2Fyb3VuZC4NCg0KSSBhbHNvIHRo aW5rIHdlIG5lZWQgbW9yZSBjbGFyaXR5IGFib3V0IHRoZSB1c2Ugb2YgZHluYW1pYyBjbGllbnQN CnJlZ2lzdHJhdGlvbiBieSBhIHJlc291cmNlIHNlcnZlciBhcyBvdXRsaW5lZCBpbiBTZWN0aW9u IDQgKHdoZXJlIGl0J3MNCm1lbnRpb25lZCBhcyAid2l0aCBhIHJlc291cmNlIHNlcnZlciBwb3Np bmcgYXMgdGhlIGNsaWVudCIsIHdpdGhvdXQNCnJlZmVyZW5jZSB0byBSRkMgNzU5MS4gIEFzIGZh ciBhcyBJIGNhbiB0ZWxsIHRoaXMgZG9jdW1lbnQvc2VjdGlvbiBpcw0KaW50cm9kdWNpbmcgdGhp cyB1c2Ugb2YgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIGJ5IGFuIFJTIGZvciB0aGUNCmZp cnN0IHRpbWUsIHNvIHdlIGNhbm5vdCBlYXNpbHkganVzdCByZWZlciB0byBzb21lIG90aGVyIGRv Y3VtZW50Lg0KU3BlY2lmaWNhbGx5LCBhcmUgdGhlcmUgYW55IGZpZWxkcyB0aGF0IE1VU1QgTk9U IGJlIHN1cHBsaWVkPyAgSXMgYQ0KaHVtYW4tcmVhZGFibGUgY2xpZW50X25hbWUgdXNlZnVsPyAg SG93IGRvZXMgdGhlIHN1cHBsaWVkIGNsaWVudF91cmkNCm5lZWQgdG8gcmVsYXRlIHRvIGFueSBl eGlzdGluZyBBUyByZXByZXNlbnRhdGlvbiBvZiBhIHJlc291cmNlIGluDQphdWRpZW5jZSwgc2Nv cGUsIGV0Yy4gKGUuZy4sIGZvciB0aGUgInJlc291cmNlIiByZXF1ZXN0IHBhcmFtZXRlciBmcm9t DQpkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMpPw0KDQpJcyB0aGlzIHVzYWdl IGNvbnNpZGVyZWQgdG8gYmUgYSAibmV3IHVzZSBvZiBKV1RzIj8gIElmIHNvLCBpdCBzZWVtcw0K dGhhdCB3ZSBzaG91bGQgZm9sbG93IHRoZSByZWNvbW1lbmRhdGlvbiBvZiBkcmFmdC1pZXRmLW9h dXRoLWp3dC1iY3AgYW5kDQp1c2UgZXhwbGljaXQgdHlwaW5nLg0KDQpJIHRoaW5rIHRoZXJlIGFy ZSBzb21lIG1pc3NpbmcgbGlua3MgaW4gdGhlIGRvY3VtZW50IGJldHdlZW4gYSBSUw0KcmVnaXN0 cmluZyBjbGllbnQgcG9saWN5IGFuZCB0aGUgcmVzdWx0aW5nIEFTIGVuZm9yY2VtZW50IG9mIGVu Y3J5cHRpb24NCm9mIGludHJvc3BlY3Rpb24gcmVwb25zZXMuICBJIHRoaW5rIHRoZSBpbnRlbnQg aXMgcm91Z2hseSB0aGF0IHRoZQ0KcG9saWN5IHdpbGwgYmUgYXBwbGllZCBiYXNlZCBvbiB0aGUg YXVkaWVuY2Ugb2YgdGhlIHRva2VuIGJlaW5nDQpwcmVzZW50ZWQgZm9yIGludHJvc3BlY3Rpb24g KGFzIG9wcG9zZWQgdG8gdGhlIGlkZW50aXR5IG9mIHRoZQ0KUlMtYXMtY2xpZW50IG1ha2luZyB0 aGUgaW50cm9zcGVjdGlvbiByZXF1ZXN0KSwgYnV0IHdlIGRvbid0IHNlZW0gdG8NCmV4cGxpY2l0 bHkgc2F5IHRoYXQuICBBbHNvLCB3ZSdkIG5lZWQgdG8gc2F5IHNvbWV0aGluZyBhYm91dCB0aGUN CmludGVyYWN0aW9uIG9mIG11bHRpcGxlIFJTcycgcG9saWN5IHdoZW4gYSBnaXZlbiB0b2tlbiBo YXMgbXVsdGlwbGUNCnZhbGlkIGF1ZGllbmNlcy4gIFRoZXJlIGlzIGEgdmVyeSBicmllZiBkaXNj dXNzaW9uIGluIFNlY3Rpb24gNi41LCBidXQNCml0IHNlZW1zIHRvIGJlIG1vcmUgb2YgYSBkZXNj cmlwdGlvbiBvZiB3aGF0IGlzIHBvc3NpYmxlIHRoYW4gbWFuZGF0aW5nDQpwYXJ0aWN1bGFyIGZv cm1zIG9mIGVuZm9yY2VtZW50Lg0KDQpJIHRoaW5rIHdlIHNob3VsZCBkaXNjdXNzIHdoZXRoZXIg d2Ugd2FudCBzb21lIHN0YXRlbWVudCBmcm9tIHRoZSBPcGVuSUQNCkZvdW5kYXRpb24gb3IgcmVs YXRlZCBib2RpZXMgYmVmb3JlIHdlIHJlZ2lzdGVyIGNsYWltcyB0aGF0IHBvaW50IHRvDQp0aGVp ciBkb2N1bWVudHMgd2l0aCB0aGUgSUVTRyBsaXN0ZWQgYXMgY2hhbmdlIGNvbnRyb2xsZXIuDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KaWRuaXRzIG5vdGVz IHRoYXQgUkZDIDU2NDYgaXMgbWVudGlvbmVkIGJ1dCBub3QgcHJlc2VudCBpbiB0aGUNCnJlZmVy ZW5jZXMgc2VjdGlvbi4NCg0KU2VjdGlvbiAxDQoNCldlIHByb2JhYmx5IG5lZWQgdG8gbW92ZSB0 aGUgNzUxOSByZWZlcmVuY2UgdXAgaGVyZSB0byB3aGVyZSBKV1QgaXMNCmZpcnN0IHVzZWQuDQoN CiAgT0F1dGggMi4wIFRva2VuIEludHJvc3BlY3Rpb24gW1JGQzc2NjJdIHNwZWNpZmllcyBhIG1l dGhvZCBmb3IgYQ0KICBwcm90ZWN0ZWQgcmVzb3VyY2UgdG8gcXVlcnkgYW4gT0F1dGggMi4wIGF1 dGhvcml6YXRpb24gc2VydmVyIHRvDQogIGRldGVybWluZSB0aGUgc3RhdGUgb2YgYW4gYWNjZXNz IHRva2VuIGFuZCBvYnRhaW4gZGF0YSBhc3NvY2lhdGVkDQogIHdpdGggdGhlIGFjY2VzcyB0b2tl bi4gIFRoaXMgYWxsb3dzIGRlcGxveW1lbnRzIHRvIGltcGxlbWVudA0KICBpZGVudGlmaWVyLWJh c2VkIGFjY2VzcyB0b2tlbnMgaW4gYW4gaW50ZXJvcGVyYWJsZSB3YXkuDQoNCkRvZXMgImlkZW50 aWZpZXItYmFzZWQgYWNjZXNzIHRva2VucyIgbWVhbiAidG9rZW5zIHRoYXQgYXJlIG9wYXF1ZSBr ZXlzDQp0byBhIChjZW50cmFsKSBkYXRhYmFzZSBsb29rdXAiIG9yICJhY2Nlc3MgdG9rZW5zIHRo YXQgY29udmV5IHVzZXINCmlkZW50aXR5IGluZm9ybWF0aW9uIiAob3Igc29tZXRoaW5nIGVsc2Up PyAgV2UgbWF5IHdhbnQgdG8gdHdlYWsgdGhlDQp3b3JkaW5nLg0KDQpTZWN0aW9uIDMNCg0KQ2Fu IHdlIGRvdWJsZS1jaGVjayB0aGUgYmFzZTY0IGZvcm0gb2YgdGhlIHJlc3BvbnNlIGluIHRoaXMg ZXhhbXBsZT8gIEkNCmFtIHNlZWluZyBvdXRwdXQgdGhhdCBiYWNrc2xhc2gtZXNjYXBlcyB0aGUg Jy8nIGNoYXJhY3RlcnMgaW4gVVJMcywNCndoaWNoIEkgZGlkIG5vdCB0aGluayB3YXMgbmVlZGVk IGluIHRoaXMgY29udGV4dC4NCkkgYWxzbyBzZWUgYW4gImV4dGVuc2lvbl9maWVsZCIgY2xhaW0g aW4gdGhlIGJhc2U2NCBidXQgbm90IHRoZSBkZWNvZGVkDQpmb3JtIG9mIHRoZSBleGFtcGxlLCBh bmQgImdpdmVuX25hbWUiLyJmYW1pbHlfbmFtZSIvImJpcnRoZGF0ZSIgaW4gdGhlDQpkZWNvZGVk IGV4YW1wbGUgdnMuICJ1c2VybmFtZSIgaW4gdGhlIGJhc2U2NCB2ZXJzaW9uLg0KDQogIE5vdGU6 IElmIHRoZSByZXNvdXJjZSBzZXJ2ZXIgcG9saWN5IHJlcXVpcmVzIGEgc2lnbmVkIGFuZCBlbmNy eXB0ZWQNCiAgcmVzcG9uc2UgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZWNlaXZlcyBh biB1bmF1dGhlbnRpY2F0ZWQNCiAgcmVxdWVzdCBjb250YWluaW5nIGFuIEFjY2VwdCBoZWFkZXIg d2l0aCBjb250ZW50IHR5cGUgb3RoZXIgdGhhbg0KICAiYXBwbGljYXRpb24vand0IiwgaXQgTVVT VCByZWZ1c2UgdG8gc2VydmUgdGhlIHJlcXVlc3QgYW5kIHJldHVybiBhbg0KICBIVFRQIHN0YXR1 cyBjb2RlIDQwMC4gIFRoaXMgaXMgZG9uZSB0byBwcmV2ZW50IGRvd25ncmFkaW5nIGF0dGFja3Mg dG8NCiAgb2J0YWluIHRva2VuIGRhdGEgaW50ZW5kZWQgZm9yIHJlbGVhc2UgdG8gbGVnaXRpbWF0 ZSByZWNpcGllbnRzIG9ubHkNCiAgKHNlZSBTZWN0aW9uIDYuMikuDQoNCkknZCBzdWdnZXN0IGEg Zm9yd2FyZC1yZWZlcmVuY2UgdG8gc2VjdGlvbiA0IGZvciBob3cgdGhlIEFTIHdpbGwga25vdw0K dGhlIFJTJ3MgcG9saWN5LiAgQWx0aG91Z2gsIGdpdmVuIHRoYXQgInVuYXV0aGVudGljYXRlZCBy ZXF1ZXN0IiBpcw0KaW5jbHVkZWQgaW4gdGhlIHByZWNvbmRpdGlvbnMsIHBlcmhhcHMgd2UgZG8g bm90IG5lZWQgdGhlIGNvbmRpdGlvbmFsIG9uDQoicmVzb3VyY2Ugc2VydmVyIHBvbGljeSIgYXQg YWxsPw0KDQpTZWN0aW9uIDQNCg0KICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGV0ZXJtaW5l cyB3aGF0IGFsZ29yaXRobSB0byBlbXBsb3kgdG8NCiAgc2VjdXJlIHRoZSBKV1QgZm9yIGEgcGFy dGljdWxhciBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlLiAgVGhpcw0KICBkZWNpc2lvbiBjYW4gYmUg YmFzZWQgb24gcmVnaXN0ZXJlZCBtZXRhZGF0YSBwYXJhbWV0ZXJzIGZvciB0aGUNCiAgcmVzb3Vy Y2Ugc2VydmVyLCBzdXBwbGllZCB2aWEgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIHdpdGgg dGhlDQogIHJlc291cmNlIHNlcnZlciBwb3NpbmcgYXMgdGhlIGNsaWVudCwgYXMgZGVmaW5lZCBi eSB0aGlzIGRyYWZ0Lg0KDQpuaXQ6IEkgc3VnZ2VzdCBzL3Bvc2luZyBhcyB0aGUvYWN0aW5nIGFz IGEvLCBhbmQgcy9ieSB0aGlzIGRyYWZ0L2JlbG93LywNCnNpbmNlIGl0J3MgcmlnaHQgaGVyZSBp biB0aGlzIHNlY3Rpb24uDQoNCiAgaW50cm9zcGVjdGlvbl9lbmNyeXB0ZWRfcmVzcG9uc2VfYWxn ICBPUFRJT05BTC4gIEpXRSBbUkZDNzUxNl0NCiAgICAgICAgICBhbGdvcml0aG0gKCJhbGciIHZh bHVlKSBhcyBkZWZpbmVkIGluIEpXQSBbUkZDNzUxOF0gZm9yDQogICAgICAgICAgZW5jcnlwdGlu ZyBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlcy4gIElmIHRoaXMgaXMgc3BlY2lmaWVkLA0KICAgICAg ICAgIHRoZSByZXNwb25zZSB3aWxsIGJlIGVuY3J5cHRlZCB1c2luZyBKV0UgYW5kIHRoZSBjb25m aWd1cmVkDQogICAgICAgICAgYWxnb3JpdGhtLiAgVGhlIGRlZmF1bHQsIGlmIG9taXR0ZWQsIGlz IHRoYXQgbm8gZW5jcnlwdGlvbiBpcw0KDQpUaGlzIHRleHQgaXMgc2xpZ2h0bHkgY29uZnVzaW5n IHdpdGggcmVzcGVjdCB0byB0aGUgaW50ZXJhY3Rpb24gYmV0d2Vlbg0KdGhlIGludHJvc3BlY3Rp b25fZW5jcnlwdGVkX3Jlc3BvbnNlX2FsZyAiYWxnIiB2YWx1ZSBhbmQgdGhlDQppbnRyb3NwZWN0 aW9uX2VuY3J5cHRlZF9yZXNwb25zZV9lbmMgImVuYyIgdmFsdWUuICBNeSB1bmRlcnN0YW5kaW5n IGlzDQp0aGF0IHRoZSAiZW5jIiBpcyBhIHN5bW1ldHJpYyBidWxrIGVuY3J5cHRpb24gc2NoZW1l IHRoYXQgZGlyZWN0bHkNCnByb3RlY3RzIHRoZSBwYXlsb2FkLCB3aGVyZWFzIHRoZSAiYWxnIiBp cyBhIGtleS13cmFwIG9yIGtleS1hZ3JlZW1lbnQNCm1lY2hhbmlzbSB1c2VkIHRvIGVzdGFibGlz aCB0aGUga2V5IHVzZWQgYXMgaW5wdXQgZm9yIHRoZSAiZW5jIiBtZXRob2QuDQpTbywgd2hpbGUg ImFsZ29yaXRobSAoImFsZyB2YWx1ZSIpIGZvciBlbmNyeXB0aW5nIGludHJvc3BlY3Rpb24NCnJl c3BvbnNlcyIgYW5kICJ0aGUgcmVzcG9uc2Ugd2lsbCBiZSBlbmNyeXB0ZWQgdXNpbmcgdGhlIGNv bmZ1Z3JlZA0KWyJhbGdvIl0gYWxnb3JpdGhtIiBhcmUgdGVjaG5pY2FsbHkgdHJ1ZSwgdGhleSdy ZSBhbHNvIGEgYml0IG1pc2xlYWRpbmcsDQpzaW5jZSB0aGlzIGlzIG5vdCB3aGF0IGVuY3J5cHRz IHRoZSAiYnVsayIgb2YgdGhlIHJlc3BvbnNlLiAgVXNpbmcgdGhlDQp0ZXJtIGZyb20gUkZDIDcx NTgsICJrZXkgbWFuYWdlbWVudCBhbGdvcml0aG0iLCB3b3VsZCBwcm9iYWJseSBhbGxldmlhdGUN CnRoaXMgY29uZnVzaW9uLg0KDQogIFJlc291cmNlIHNlcnZlcnMgbWF5IHJlZ2lzdGVyIHRoZWly IHB1YmxpYyBlbmNyeXB0aW9uIGtleXMgdXNpbmcgdGhlDQogICJqd2tzX3VyaSIgb3IgImp3a3Mi IG1ldGFkYXRhIHBhcmFtZXRlcnMuDQoNClNob3VsZCB3ZSBjaXRlIDc1OTEgZm9yIHRoZXNlIChv ciwgcmVhbGx5LCB0aGUgd2hvbGUgc2VjdGlvbik/ICBXZSBkb24ndA0KY3VycmVudGx5IG1lbnRp b24gaXQgdW50aWwgdGhlIElBTkEgY29uc2lkZXJhdGlvbnMuDQoNClNlY3Rpb24gNQ0KDQpJcyBp dCB3b3J0aCBhIG5vdGUgdGhhdCByZXNvdXJjZSBzZXJ2ZXJzIHdpbGwgZmV0Y2ggdGhlc2UgbWV0 YWRhdGEgYW5kDQp1c2UgdGhlbSBhcyBpbnB1dCB0byB0aGVpciBkeW5hbWljIHJlZ2lzdHJhdGlv bnMgaW4gdGhlIHByZXZpb3VzIHNlY3Rpb24NCihpLmUuLCBwaWNraW5nIGZyb20gdGhlIGxpc3Qg b2Ygc3VwcG9ydGVkIGFsZ29yaXRobXMpPw0KDQogIGludHJvc3BlY3Rpb25fZW5jcnlwdGlvbl9h bGdfdmFsdWVzX3N1cHBvcnRlZCAgT1BUSU9OQUwuICBKU09OIGFycmF5DQogICAgICAgICAgY29u dGFpbmluZyBhIGxpc3Qgb2YgdGhlIEpXRSBbUkZDNzUxNl0gZW5jcnlwdGlvbiBhbGdvcml0aG1z DQogICAgICAgICAgKCJhbGciIHZhbHVlcykgYXMgZGVmaW5lZCBpbiBKV0EgW1JGQzc1MThdIHN1 cHBvcnRlZCBieSB0aGUNCiAgICAgICAgICBpbnRyb3NwZWN0aW9uIGVuZHBvaW50IHRvIGVuY3J5 cHQgdGhlIHJlc3BvbnNlLg0KDQpTaW1pbGFybHkgdG8gdGhlIGFib3ZlLCBzb21lIHJlZmluZWQg dGV4dCBhYm91dCAia2V5IG1hbmFnZW1lbnQNCmFsZ29yaXRobSIgdXNlZCB0byBlbmNyeXB0IHRo ZSByZXNwb25zZSwgd291bGQgcHJvYmFibHkgYmUgaGVscGZ1bC4NCg0KU2VjdGlvbiA2DQoNClRo ZXJlIHNlZW0gdG8gYmUgbm90YWJsZSBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGFib3V0IHF1aXRl IGEgZmV3IG9mIHRoZQ0KY2xhaW1zIHJlZ2lzdGVyZWQgaW4gU2VjdGlvbiA4LjMuDQoNClNlY3Rp b24gNi4xDQoNCkknbSBzdXJwcmlzZWQgdG8gbm90IHNlZSBkaXNjdXNzaW9uIG9mIGV4cGxpY2l0 IHR5cGluZyAoYW5kLCBJSVVDLCBob3cNCml0J3Mgbm90IGEgcmVsaWFibGUgbWl0aWdhdGlvbikg aGVyZS4NCg0KICBKV1QgaW50cm9zcGVjdGlvbiByZXNwb25zZXMgYW5kIE9wZW5JRCBDb25uZWN0 IElEIFRva2VucyBhcmUNCiAgc3ludGFjdGljYWxseSBzaW1pbGFyLiAgQW4gYXR0YWNrZXIgY291 bGQgdGhlcmVmb3JlIGF0dGVtcHQgdG8NCiAgaW1wZXJzb25hdGUgYW4gZW5kLXVzZXIgYXQgYSBP cGVuSUQgQ29ubmVjdCByZWx5aW5nIHBhcnR5IGJ5IHBhc3NpbmcNCiAgdGhlIEpXVCBhcyBhbiBJ RCB0b2tlbi4NCg0Kbml0OiAicmVzcG9uc2UgSldUIiBvciAiSldUIHJlc3BvbnNlIg0KDQogIFN1 Y2ggYW4gYXR0YWNrIGNhbiBiZSBwcmV2ZW50ZWQgbGlrZSBhbnkgb3RoZXIgdG9rZW4gc3Vic3Rp dHV0aW9uDQogIGF0dGFjay4gIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGluY2x1ZGUg dGhlIGNsYWltcyAiaXNzIiBhbmQNCiAgImF1ZCIgaW4gZWFjaCBKV1QgaW50cm9zcGVjdGlvbiBy ZXNwb25zZSwgd2l0aCB0aGUgImlzcyIgdmFsdWUgc2V0IHRvDQogIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlcidzIGlzc3VlciBVUkwgYW5kIHRoZSAiYXVkIiB2YWx1ZSBzZXQgdG8gdGhlDQogIHJl c291cmNlIHNlcnZlcidzIGlkZW50aWZpZXIuICBbLi4uXQ0KDQpSZWxhdGVkIHRvIHRoZSBEaXNj dXNzIHBvaW50LCBob3cgZG9lcyB0aGlzIHJlbGF0ZSB0byB0aGUgZHluYW1pYyBjbGllbnQNCnJl Z2lzdHJhdGlvbiBwYXJhbWV0ZXJzPw0KDQogIFtPcGVuSUQuQ29yZV0uICBSZWx5aW5nIHBhcnRp ZXMgU0hPVUxEIGFsc28gdXNlIGFuZCBjaGVjayB0aGUgIm5vbmNlIg0KICBwYXJhbWV0ZXIgYW5k IGNsYWltIHRvIHByZXZlbnQgdG9rZW4gYW5kIGNvZGUgcmVwbGF5Lg0KDQpJcyB0aGlzIFNIT1VM RCBqdXN0IHJlZmVycmluZyB0byB0aGUgYmVoYXZpb3IgYWxyZWFkeSBkZXNjcmliZWQgaW4NCk9w ZW5JRC5Db3JlIChhbmQgb25seSBhcHBsaWNhYmxlIHRvIE9JREMgaW1wbGVtZW50YXRpb25zIGFz IG9wcG9zZWQgdG8NCkpXVC1pbnN0cm9zcGVjdGlvbiBjb25zdW1lcnMpPyAgSWYgc28sIG1heWJl IGRlc2NyaXB0aXZlIGxhbmd1YWdlIGlzDQptb3JlIGFwcHJvcHJpYXRlLCBsaWtlICJSZWx5aW5n IHBhcnRpZXMgYXJlIGFsc28gZXhwZWN0ZWQgdG8gdXNlIGFuZA0KY2hlY2sgWy4uLl0iLg0KDQog IFJlc291cmNlIHNlcnZlcnMgdXRpbGl6aW5nIEpXVHMgdG8gcmVwcmVzZW50IHNlbGYtY29udGFp bmVkIGFjY2Vzcw0KICB0b2tlbnMgY291bGQgYmUgc3VzY2VwdGlibGUgdG8gcmVwbGF5IGF0dGFj a3MuICBSZXNvdXJjZSBzZXJ2ZXJzDQogIHNob3VsZCB0aGVyZWZvcmUgYXBwbHkgcHJvcGVyIGNv dW50ZXIgbWVhc3VyZXMgYWdhaW5zdCByZXBsYXkgYXMNCiAgZGVzY3JpYmVkIGluIFtJLUQuaWV0 Zi1vYXV0aC1zZWN1cml0eS10b3BpY3NdLCBzZWN0aW9uIDIuMi4NCg0KSSdtIG5vdCBzdXJlIHdo YXQgcGFydCBvZiB0aGlzIGlzIHNwZWNpZmljIHRvIHRoZSBpbnRyb3NwZWN0aW9uIGNhc2UuDQpJ cyBpdCBzdXBwb3NlZCB0byBiZSB0aWVkIHRvIHRoZSByaXNrIHRoYXQgSldULWluc3Ryb3NwZWN0 aW9uIHByb2R1Y2VzIGENCm5ldyByb3V0ZSBmb3IgdGhlIGdlbmVyYXRpb24gb2YgSldUIG9iamVj dHMgdGhhdCBjb3VsZCBiZSBjb25mdXNlZCBmb3INCnNlbGYtY29udGFpbmVkIGFjY2VzcyB0b2tl bnM/DQpuaXQ6ICJjb3VudGVybWVhc3VyZXMiIGlzIHZhbGlkIGFzIGEgc2luZ2xlIHdvcmQuDQpu aXQ6IGl0IGxvb2tzIGxpa2UgaXQncyBzZWN0aW9uIDMuMiwgbm93Lg0KDQpTZWN0aW9uIDYuMg0K DQpQbGVhc2UgY2l0ZSBSRkMgNzUyNSBhcyBCQ1AgMTk1IGFzIHdlbGwgYXMgUkZDIDc1MjUgKGUu Zy4sICJwZXIgQkNQIDE5NQ0KW1JGQzc1MjVdIikuDQoNCiAgVG8gcHJldmVudCBpbnRyb3NwZWN0 aW9uIG9mIGxlYWtlZCB0b2tlbnMgYW5kIHRvIHByZXNlbnQgYW4NCiAgYWRkaXRpb25hbCBzZWN1 cml0eSBsYXllciBhZ2FpbnN0IHRva2VuIGd1ZXNzaW5nIGF0dGFja3MgdGhlDQogIGF1dGhvcml6 YXRpb24gc2VydmVyIG1heSByZXF1aXJlIGFsbCByZXF1ZXN0cyB0byB0aGUgdG9rZW4NCiAgaW50 cm9zcGVjdGlvbiBlbmRwb2ludCB0byBiZSBhdXRoZW50aWNhdGVkLiAgQXMgYW4gYWx0ZXJuYXRp dmUgb3IgYXMNCiAgYW4gYWRkaXRpb24gdG8gdGhlIGF1dGhlbnRpY2F0aW9uLCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50cyBtYXkgYmUgc2V0DQogIHVwIGZvciBlbmNyeXB0ZWQgcmVzcG9uc2VzLg0K DQpEbyB3ZSB3YW50IHRvIG1ha2UgZWl0aGVyIG9mIHRoZXNlICJtYXkicyBpbnRvIG5vcm1hdGl2 ZSByZWNvbW1lbmRhdGlvbnMNCihvciBtYWtlIGEgcmVjb21tZW5kYXRpb24gZm9yIHByZXZlbnRp b24gb2YgaW50cm9zcGVjdGlvbiBkYXRhIGxlYWthZ2UNCmV2ZW4gaW4gdGhlIGZhY2Ugb2YgdG9r ZW4gbGVha2FnZSwgd2hpY2ggY2FuIGJlIHNhdGlzZmllZCBieSBlaXRoZXINCm1lY2hhbmlzbSk/ DQoNCkFsc28sIHdlIGNvdWxkIHNheSBtb3JlIGFib3V0IGhvdyBjb25maWd1cmluZyBlbmNyeXB0 aW9uIGZvciBpbnRlbmRlZA0KcmVjaXBpZW50cyBwcm90ZWN0cyBhZ2FpbnN0IHVuZW5jcnlwdGVk IHJlcGxpZXMgdG8gdW5pbnRlbmRlZA0KcmVjaXBpZW50cy4uLg0KDQogIEluIHRoZSBsYXR0ZXIg Y2FzZSwgY29uZmlkZW50aWFsaXR5IGlzIGVuc3VyZWQgYnkgdGhlIGZhY3QgdGhhdCBvbmx5DQog IHRoZSBsZWdpdGltYXRlIHJlY2lwaWVudCBpcyBhYmxlIHRvIGRlY3J5cHQgdGhlIHJlc3BvbnNl LiAgQW4NCiAgYXR0YWNrZXIgY291bGQgdHJ5IHRvIGNpcmN1bXZlbnQgdGhpcyBtZWFzdXJlIGJ5 IHJlcXVlc3RpbmcgYSBwbGFpbg0KICBKU09OIHJlc3BvbnNlLCB1c2luZyBhbiBBY2NlcHQgaGVh ZGVyIHdpdGggdGhlIGNvbnRlbnQgdHlwZSBzZXQgdG8sDQogIGZvciBleGFtcGxlLCAiYXBwbGlj YXRpb24vanNvbiIgaW5zdGVhZCBvZiAiYXBwbGljYXRpb24vand0Ii4gIFRvDQogIHByZXZlbnQg dGhpcyBhdHRhY2sgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgTk9UIHNlcnZlIHJlcXVl c3RzDQogIHdpdGggY29udGVudCB0eXBlIG90aGVyIHRoYW4gImFwcGxpY2F0aW9uL2p3dCIgaWYg dGhlIHJlc291cmNlIHNlcnZlcg0KICBpcyBzZXQgdXAgdG8gcmVjZWl2ZSBlbmNyeXB0ZWQgcmVz cG9uc2VzIChzZWUgYWxzbyBTZWN0aW9uIDMpLg0KDQouLi4uc3VjaCBhcyBieSBzYXlpbmcgdGhh dCB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZSB3aWxsIG9ubHkgYmUgbWFkZQ0KYXZhaWxhYmxl IHRvIFJTZXMgdGhhdCBhcmUgaW50ZW5kZWQgcmVjaXBpZW50cyBvZiAoaW4gdGhlIGF1ZGllbmNl IG9mPykNCnRoZSBhY2Nlc3MgdG9rZW4gYmVpbmcgaW50cm9zcGVjdGVkLg0KDQpTZWN0aW9uIDYu Mw0KDQogIEF1dGhvcml6YXRpb24gc2VydmVycyB3aXRoIGEgcG9saWN5IHRoYXQgcmVxdWlyZXMg dG9rZW4gZGF0YSB0byBiZQ0KICBrZXB0IGNvbmZpZGVudGlhbCBmcm9tIE9BdXRoIGNsaWVudHMg bXVzdCByZXF1aXJlIGFsbCByZXF1ZXN0cyB0byB0aGUNCiAgdG9rZW4gaW50cm9zcGVjdGlvbiBl bmRwb2ludCB0byBiZSBhdXRoZW50aWNhdGVkLiAgQXMgYW4gYWx0ZXJuYXRpdmUNCiAgb3IgYXMg YW4gYWRkaXRpb24gdG8gdGhlIGF1dGhlbnRpY2F0aW9uLCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 cyBtYXkNCiAgYmUgc2V0IHVwIGZvciBlbmNyeXB0ZWQgcmVzcG9uc2VzLg0KDQpbdGhpcyBhbHNv IHNlZW1zIHRvIGJlIGFzc3VtaW5nIGEgbGluayBub3Qgc3RhdGVkIGJldHdlZW4gUlMgcG9saWN5 IGFuZA0KQVMgZW5mb3JjZW1lbnQsIGJ1dCBpdCBzZWVtcyB1bmxpa2VseSB0aGF0IGEgZml4IHdv dWxkIG5lZWQgdG8gdG91Y2gNCnRoaXMgdGV4dF0NCg0KU2VjdGlvbiA4LjEuMQ0KDQpuaXQ6IHVz aW5nIG5lc3RlZCBsaXN0cyBtaWdodCBtYWtlIHRoaXMgbW9yZSByZWFkYWJsZS4NCg0KICBvICBD bGllbnQgTWV0YWRhdGEgRGVzY3JpcHRpb246IFN0cmluZyB2YWx1ZSBzcGVjaWZ5aW5nIHRoZSBk ZXNpcmVkDQogICAgIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgZW5jcnlwdGlvbiBhbGdvcml0aG0g KGFsZyB2YWx1ZSkuDQoNCltzYW1lIGJpdCBhYm91dCAia2V5IG1hbmFnZW1lbnQgYWxnb3JpdGht Il0NCg0KU2VjdGlvbiA4LjIuMQ0KDQogIG8gIE1ldGFkYXRhIERlc2NyaXB0aW9uOiBKU09OIGFy cmF5IGNvbnRhaW5pbmcgYSBsaXN0IG9mIGFsZ29yaXRobXMNCiAgICAgc3VwcG9ydGVkIGJ5IHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBmb3IgaW50cm9zcGVjdGlvbiByZXNwb25zZQ0KICAgICBl bmNyeXB0aW9uIChhbGcgdmFsdWUpLg0KDQpbYW5kIGhlcmVdDQoNClNlY3Rpb24gOC4zDQoNCkkg dGhpbmsgd2Ugc2hvdWxkIG1ha2Ugc29tZSBtZW50aW9uIGVhcmxpZXIgaW4gdGhlIGRvY3VtZW50 DQooSW50cm9kdWN0aW9uPykgdGhhdCB3ZSBhbHNvIHJlZ2lzdGVyIHNvbWUgY29tbW9uIGNsYWlt IHZhbHVlcyB0aGF0IGFyZQ0KaW4gdXNlIGluIHRoZSB3aWxkIChvciB3aGF0ZXZlciB0ZXh0IHlv dSBmZWVsIGlzIGFwcHJvcHJpYXRlIHRvIGRlc2NyaWJlDQp0aGUgY2xhaW1zIGluIHF1ZXN0aW9u KS4NCg0KVGhlIG5lc3RlZCBsaXN0cyB3b3VsZCBiZSBncmVhdCBoZXJlIGFzIHdlbGwuDQoNCklz IHRoZXJlIGFueSBleHBlY3RhdGlvbiB0aGF0IHNvbWUgY29tYmluYXRpb24gb2YgImdpdmVuX25h bWUiLA0KIm1pZGRsZV9uYW1lIiwgYW5kICJmYW1pbHlfbmFtZSIgd2lsbCBwcm9kdWNlIGlkZW50 aWNhbCBjb250ZW50IHRvIHRoZQ0KZnVsbCAibmFtZSIgY2xhaW0/DQoNCiAgbyAgTmFtZTogInBy ZWZlcnJlZF91c2VybmFtZSINCg0KICBvICBEZXNjcmlwdGlvbjogU2hvcnRoYW5kIG5hbWUgYnkg d2hpY2ggdGhlIEVuZC1Vc2VyIHdpc2hlcyB0byBiZQ0KICAgICByZWZlcnJlZCB0byBhdCB0aGUg UlAsIHN1Y2ggYXMgamFuZWRvZSBvciBqLmRvZS4gIFRoaXMgdmFsdWUgTUFZDQogICAgIGJlIGFu eSB2YWxpZCBKU09OIHN0cmluZyBpbmNsdWRpbmcgc3BlY2lhbCBjaGFyYWN0ZXJzIHN1Y2ggYXMg QCwNCiAgICAgLywgb3Igd2hpdGVzcGFjZS4NCg0KSXQgc2VlbXMgbGlrZSB0aGVyZSBtYXkgYmUg c29tZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhYm91dCBzYW5pdHppaW5nDQp0aGlzIGZpZWxk IGJlZm9yZSB1c2luZyBpdCBpbiBhbiBhcHBsaWNhdGlvbidzIGxvZ2ljLg0KDQogIG8gIE5hbWU6 ICJwcm9maWxlIg0KDQogIG8gIERlc2NyaXB0aW9uOlVSTCBvZiB0aGUgRW5kLVVzZXIncyBwcm9m aWxlIHBhZ2UuICBUaGUgY29udGVudHMgb2YNCiAgICAgdGhpcyBXZWIgcGFnZSBTSE9VTEQgYmUg YWJvdXQgdGhlIEVuZC1Vc2VyLg0KDQpJdCdzIHNsaWdodGx5IHN1cnBpc2luZyB0byBzZWUgdGhp cyBjbGFpbWVkIGZvciB0aGUgZW5kLXVzZXIncyBwcm9maWxlDQp3aGVuIGl0IG1pZ2h0IGVxdWFs bHkgYXBwbHkgdG8gYSBwcm90b2NvbCBwcm9maWxlIG9yIHZhcmlhbnQgaW4gdXNlLg0KQnV0IEkg YXNzdW1lIHRoaXMgaXMgYWxyZWFkeSBkZXBsb3llZCwgc28gdGhlcmUncyBubyByZWFsIHBvaW50 IGluDQpvYmplY3RpbmcgdG8gaXRzIHJlZ2lzdHJhdGlvbi4uLg0KDQogIG8gIE5hbWU6ICJiaXJ0 aGRhdGUiDQoNCiAgbyAgRGVzY3JpcHRpb246VGltZSB0aGUgRW5kLVVzZXIncyBpbmZvcm1hdGlv biB3YXMgbGFzdCB1cGRhdGVkLiAgSXRzDQogICAgIHZhbHVlIGlzIGEgSlNPTiBudW1iZXIgcmVw cmVzZW50aW5nIHRoZSBudW1iZXIgb2Ygc2Vjb25kcyBmcm9tDQogICAgIDE5NzAtMDEtMDFUMDow OjBaIGFzIG1lYXN1cmVkIGluIFVUQyB1bnRpbCB0aGUgZGF0ZS90aW1lLg0KDQpUaGlzIHNlZW1z IHBvdGVudGlhbGx5IGNvbmZ1c2FibGUgd2l0aCB0aGUgdXNlcidzIGRheS95ZWFyIG9mIGJpcnRo Lg0KKEFsc28sIGFyZSBsZWFwIHNlY29uZHMgZXhjbHVkZWQ/KQ0KDQogIG8gIE5hbWU6ICJ6b25l aW5mbyINCg0KICBvICBEZXNjcmlwdGlvbjogU3RyaW5nIGZyb20gem9uZWluZm8gW3pvbmVpbmZv XSB0aW1lIHpvbmUgZGF0YWJhc2UNCiAgICAgcmVwcmVzZW50aW5nIHRoZSBFbmQtVXNlcidzIHRp bWUgem9uZS4gIEZvciBleGFtcGxlLCBFdXJvcGUvUGFyaXMNCiAgICAgb3IgQW1lcmljYS9Mb3Nf QW5nZWxlcy4NCg0KV2Ugc2VlbSB0byBiZSBtaXNzaW5nIHRoZSBhY3R1YWwgcmVmZXJlbmNlIGVu dHJ5IGZvciBbem9uZWluZm9dLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_47A41441F1A94401BBF374CA1F178A0Bmitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <518A017E7E5B5F4295C4DC2C39A8D0DF@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCk9uZSBvZiB0aGUgaXNzdWVzIEkgaGF2ZSB3aXRo IHRoZSBjdXJyZW50IHN0cnVjdHVyZSBhbGlnbnMgd2l0aCBCZW7igJlzIGNvbW1lbnRzIGJlbG93 IOKAlCB3ZSBoYXZlIHR3byB0aGluZ3MgdGhhdCBmZWVsIHRva2VuLWlzaCwgdGhlIGlucHV0IHRv a2VuIGFuZCB0aGUgcmVzdWx0aW5nIEpXVCByZXNwb25zZS4gSG93ZXZlciwgdGhlIEpXVCBpbiB0 aGUgcmVzcG9uc2UgaXMgbm90IGFjdHVhbGx5IGEgOnRva2VuOiBpbiB0aGUgT0F1dGggc2Vuc2Uu IEluc3RlYWQsDQogaXTigJlzIGFuIGFzc2VydGlvbiB0aGF0IGNhcnJpZXMgcGF5bG9hZCBpbmZv cm1hdGlvbiA6YWJvdXQ6IGEgdG9rZW4uIFRoZSByZXNwb25zZSBpdHNlbGYgaXNu4oCZdCBhIHRv a2VuIGFuZCBzaG91bGRu4oCZdCBiZSB0cmVhdGVkIGFzIGEgdG9rZW4gdW50byBpdHNlbGYuDQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJj YXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQri gJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIFNlcCAyLCAyMDE5LCBhdCA2 OjQ0IFBNLCBCZW5qYW1pbiBLYWR1ayB2aWEgRGF0YXRyYWNrZXIgJmx0OzxhIGhyZWY9Im1haWx0 bzpub3JlcGx5QGlldGYub3JnIiBjbGFzcz0iIj5ub3JlcGx5QGlldGYub3JnPC9hPiZndDsgd3Jv dGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+QmVuamFtaW4gS2FkdWsgaGFzIGVudGVyZWQgdGhlIGZv bGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yPGJyIGNsYXNzPSIiPg0KZHJhZnQtaWV0Zi1vYXV0 aC1qd3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS0wNzogRGlzY3VzczxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGlu ZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbDxiciBjbGFzcz0iIj4NCmVtYWlsIGFkZHJlc3NlcyBp bmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzPGJy IGNsYXNzPSIiPg0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUGxlYXNlIHJlZmVyIHRvIDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRt bCIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNz LWNyaXRlcmlhLmh0bWw8L2E+PGJyIGNsYXNzPSIiPg0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv dXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIg YmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6PGJyIGNsYXNzPSIiPg0KPGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1qd3Qt aW50cm9zcGVjdGlvbi1yZXNwb25zZS8iIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVzcG9uc2UvPC9h PjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQpESVNDVVNTOjxiciBjbGFzcz0iIj4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQZXIgdGhlIG9uZ29pbmcg ZGlzY3Vzc2lvbiBvbiB0aGUgV0cgbGlzdCwgaXQncyB1bmNsZWFyIHRoYXQgd2UgY2FuPGJyIGNs YXNzPSIiPg0KcmV0YWluIHRoZSBiZWhhdmlvcnMgd2UgZGVzY3JpYmUgYW5kIHN0aWxsIGNvbXBs eSB3aXRoIHRoZSByZXF1aXJlbWVudHM8YnIgY2xhc3M9IiI+DQpvZiBSRkMgNzUxOSByZXF1aXJl bWVudHMgZm9yIGJlaW5nIGEgSldUIChlLmcuLCByZWdhcmRpbmcgJnF1b3Q7anRpJnF1b3Q7LCAm cXVvdDtpYXQmcXVvdDssPGJyIGNsYXNzPSIiPg0KZXRjLikuICZuYnNwO1RoYXQgaXMsIGluIHRo ZSBwcmVzZW50IGZvcm11bGF0aW9uLCB0aGVyZSBhcmUgdHdvICZxdW90O3Rva2VuJnF1b3Q7czxi ciBjbGFzcz0iIj4NCmludm9sdmVkIC0tIHRoZSBpbnB1dCB0aGF0IGlzIGJlaW5nIGludHJvc3Bl Y3RlZCwgYW5kIHRoZSAmcXVvdDt0b2tlbiZxdW90OyB0aGF0PGJyIGNsYXNzPSIiPg0KaXMgdGhl IGludHJvc3BlY3Rpb24gcmVzcG9uc2UuICZuYnNwO1dlIGFyZSBjbGFpbWluZyB0aGF0IGNlcnRh aW4gZmllbGRzIGFyZTxiciBjbGFzcz0iIj4NCmRlc2NyaWJpbmcgdGhlIGlucHV0IHRva2VuLCB3 aGVuIHRoZXkgYXJlIGRlZmluZWQgdG8gYmUgc3RhdGVtZW50cyBhYm91dDxiciBjbGFzcz0iIj4N CnRoZSBjdXJyZW50IChyZXNwb25zZSkgdG9rZW4uPGJyIGNsYXNzPSIiPg0KUmVsYXhpbmcgb3Vy IHN0YXRlbWVudHMgdG8gc2F5IHRoYXQgd2UgbWVyZWx5IHVzZSBKV1MgYXMgb3Bwb3NlZCB0byBK V1Q8YnIgY2xhc3M9IiI+DQptYXkgYmUgYSB3b3JrYXJvdW5kLCB0aG91Z2ggSSBoYXZlIHRob3Vn aHQgYWJvdXQgaXQgaGFyZCBlbm91Z2ggdG8gaGF2ZTxiciBjbGFzcz0iIj4NCmFuIG9waW5pb24g b24gd2hldGhlciBpdCBpcyB0aGUgYmVzdCB3b3JrYXJvdW5kLjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkkgYWxzbyB0aGluayB3ZSBuZWVkIG1vcmUgY2xhcml0eSBhYm91dCB0aGUgdXNl IG9mIGR5bmFtaWMgY2xpZW50PGJyIGNsYXNzPSIiPg0KcmVnaXN0cmF0aW9uIGJ5IGEgcmVzb3Vy Y2Ugc2VydmVyIGFzIG91dGxpbmVkIGluIFNlY3Rpb24gNCAod2hlcmUgaXQnczxiciBjbGFzcz0i Ij4NCm1lbnRpb25lZCBhcyAmcXVvdDt3aXRoIGEgcmVzb3VyY2Ugc2VydmVyIHBvc2luZyBhcyB0 aGUgY2xpZW50JnF1b3Q7LCB3aXRob3V0PGJyIGNsYXNzPSIiPg0KcmVmZXJlbmNlIHRvIFJGQyA3 NTkxLiAmbmJzcDtBcyBmYXIgYXMgSSBjYW4gdGVsbCB0aGlzIGRvY3VtZW50L3NlY3Rpb24gaXM8 YnIgY2xhc3M9IiI+DQppbnRyb2R1Y2luZyB0aGlzIHVzZSBvZiBkeW5hbWljIGNsaWVudCByZWdp c3RyYXRpb24gYnkgYW4gUlMgZm9yIHRoZTxiciBjbGFzcz0iIj4NCmZpcnN0IHRpbWUsIHNvIHdl IGNhbm5vdCBlYXNpbHkganVzdCByZWZlciB0byBzb21lIG90aGVyIGRvY3VtZW50LjxiciBjbGFz cz0iIj4NClNwZWNpZmljYWxseSwgYXJlIHRoZXJlIGFueSBmaWVsZHMgdGhhdCBNVVNUIE5PVCBi ZSBzdXBwbGllZD8gJm5ic3A7SXMgYTxiciBjbGFzcz0iIj4NCmh1bWFuLXJlYWRhYmxlIGNsaWVu dF9uYW1lIHVzZWZ1bD8gJm5ic3A7SG93IGRvZXMgdGhlIHN1cHBsaWVkIGNsaWVudF91cmk8YnIg Y2xhc3M9IiI+DQpuZWVkIHRvIHJlbGF0ZSB0byBhbnkgZXhpc3RpbmcgQVMgcmVwcmVzZW50YXRp b24gb2YgYSByZXNvdXJjZSBpbjxiciBjbGFzcz0iIj4NCmF1ZGllbmNlLCBzY29wZSwgZXRjLiAo ZS5nLiwgZm9yIHRoZSAmcXVvdDtyZXNvdXJjZSZxdW90OyByZXF1ZXN0IHBhcmFtZXRlciBmcm9t PGJyIGNsYXNzPSIiPg0KZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzKT88YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJcyB0aGlzIHVzYWdlIGNvbnNpZGVyZWQgdG8gYmUg YSAmcXVvdDtuZXcgdXNlIG9mIEpXVHMmcXVvdDs/ICZuYnNwO0lmIHNvLCBpdCBzZWVtczxiciBj bGFzcz0iIj4NCnRoYXQgd2Ugc2hvdWxkIGZvbGxvdyB0aGUgcmVjb21tZW5kYXRpb24gb2YgZHJh ZnQtaWV0Zi1vYXV0aC1qd3QtYmNwIGFuZDxiciBjbGFzcz0iIj4NCnVzZSBleHBsaWNpdCB0eXBp bmcuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSB0aGluayB0aGVyZSBhcmUgc29tZSBt aXNzaW5nIGxpbmtzIGluIHRoZSBkb2N1bWVudCBiZXR3ZWVuIGEgUlM8YnIgY2xhc3M9IiI+DQpy ZWdpc3RyaW5nIGNsaWVudCBwb2xpY3kgYW5kIHRoZSByZXN1bHRpbmcgQVMgZW5mb3JjZW1lbnQg b2YgZW5jcnlwdGlvbjxiciBjbGFzcz0iIj4NCm9mIGludHJvc3BlY3Rpb24gcmVwb25zZXMuICZu YnNwO0kgdGhpbmsgdGhlIGludGVudCBpcyByb3VnaGx5IHRoYXQgdGhlPGJyIGNsYXNzPSIiPg0K cG9saWN5IHdpbGwgYmUgYXBwbGllZCBiYXNlZCBvbiB0aGUgYXVkaWVuY2Ugb2YgdGhlIHRva2Vu IGJlaW5nPGJyIGNsYXNzPSIiPg0KcHJlc2VudGVkIGZvciBpbnRyb3NwZWN0aW9uIChhcyBvcHBv c2VkIHRvIHRoZSBpZGVudGl0eSBvZiB0aGU8YnIgY2xhc3M9IiI+DQpSUy1hcy1jbGllbnQgbWFr aW5nIHRoZSBpbnRyb3NwZWN0aW9uIHJlcXVlc3QpLCBidXQgd2UgZG9uJ3Qgc2VlbSB0bzxiciBj bGFzcz0iIj4NCmV4cGxpY2l0bHkgc2F5IHRoYXQuICZuYnNwO0Fsc28sIHdlJ2QgbmVlZCB0byBz YXkgc29tZXRoaW5nIGFib3V0IHRoZTxiciBjbGFzcz0iIj4NCmludGVyYWN0aW9uIG9mIG11bHRp cGxlIFJTcycgcG9saWN5IHdoZW4gYSBnaXZlbiB0b2tlbiBoYXMgbXVsdGlwbGU8YnIgY2xhc3M9 IiI+DQp2YWxpZCBhdWRpZW5jZXMuICZuYnNwO1RoZXJlIGlzIGEgdmVyeSBicmllZiBkaXNjdXNz aW9uIGluIFNlY3Rpb24gNi41LCBidXQ8YnIgY2xhc3M9IiI+DQppdCBzZWVtcyB0byBiZSBtb3Jl IG9mIGEgZGVzY3JpcHRpb24gb2Ygd2hhdCBpcyBwb3NzaWJsZSB0aGFuIG1hbmRhdGluZzxiciBj bGFzcz0iIj4NCnBhcnRpY3VsYXIgZm9ybXMgb2YgZW5mb3JjZW1lbnQuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KSSB0aGluayB3ZSBzaG91bGQgZGlzY3VzcyB3aGV0aGVyIHdlIHdhbnQg c29tZSBzdGF0ZW1lbnQgZnJvbSB0aGUgT3BlbklEPGJyIGNsYXNzPSIiPg0KRm91bmRhdGlvbiBv ciByZWxhdGVkIGJvZGllcyBiZWZvcmUgd2UgcmVnaXN0ZXIgY2xhaW1zIHRoYXQgcG9pbnQgdG88 YnIgY2xhc3M9IiI+DQp0aGVpciBkb2N1bWVudHMgd2l0aCB0aGUgSUVTRyBsaXN0ZWQgYXMgY2hh bmdlIGNvbnRyb2xsZXIuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCkNPTU1FTlQ6PGJyIGNsYXNzPSIiPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCmlkbml0cyBub3RlcyB0aGF0 IFJGQyA1NjQ2IGlzIG1lbnRpb25lZCBidXQgbm90IHByZXNlbnQgaW4gdGhlPGJyIGNsYXNzPSIi Pg0KcmVmZXJlbmNlcyBzZWN0aW9uLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNlY3Rp b24gMTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldlIHByb2JhYmx5IG5lZWQgdG8gbW92 ZSB0aGUgNzUxOSByZWZlcmVuY2UgdXAgaGVyZSB0byB3aGVyZSBKV1QgaXM8YnIgY2xhc3M9IiI+ DQpmaXJzdCB1c2VkLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO09B dXRoIDIuMCBUb2tlbiBJbnRyb3NwZWN0aW9uIFtSRkM3NjYyXSBzcGVjaWZpZXMgYSBtZXRob2Qg Zm9yIGE8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtwcm90ZWN0ZWQgcmVzb3VyY2UgdG8gcXVl cnkgYW4gT0F1dGggMi4wIGF1dGhvcml6YXRpb24gc2VydmVyIHRvPGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7ZGV0ZXJtaW5lIHRoZSBzdGF0ZSBvZiBhbiBhY2Nlc3MgdG9rZW4gYW5kIG9idGFp biBkYXRhIGFzc29jaWF0ZWQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDt3aXRoIHRoZSBhY2Nl c3MgdG9rZW4uICZuYnNwO1RoaXMgYWxsb3dzIGRlcGxveW1lbnRzIHRvIGltcGxlbWVudDxiciBj bGFzcz0iIj4NCiZuYnNwOyZuYnNwO2lkZW50aWZpZXItYmFzZWQgYWNjZXNzIHRva2VucyBpbiBh biBpbnRlcm9wZXJhYmxlIHdheS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpEb2VzICZx dW90O2lkZW50aWZpZXItYmFzZWQgYWNjZXNzIHRva2VucyZxdW90OyBtZWFuICZxdW90O3Rva2Vu cyB0aGF0IGFyZSBvcGFxdWUga2V5czxiciBjbGFzcz0iIj4NCnRvIGEgKGNlbnRyYWwpIGRhdGFi YXNlIGxvb2t1cCZxdW90OyBvciAmcXVvdDthY2Nlc3MgdG9rZW5zIHRoYXQgY29udmV5IHVzZXI8 YnIgY2xhc3M9IiI+DQppZGVudGl0eSBpbmZvcm1hdGlvbiZxdW90OyAob3Igc29tZXRoaW5nIGVs c2UpPyAmbmJzcDtXZSBtYXkgd2FudCB0byB0d2VhayB0aGU8YnIgY2xhc3M9IiI+DQp3b3JkaW5n LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNlY3Rpb24gMzxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCkNhbiB3ZSBkb3VibGUtY2hlY2sgdGhlIGJhc2U2NCBmb3JtIG9mIHRoZSBy ZXNwb25zZSBpbiB0aGlzIGV4YW1wbGU/ICZuYnNwO0k8YnIgY2xhc3M9IiI+DQphbSBzZWVpbmcg b3V0cHV0IHRoYXQgYmFja3NsYXNoLWVzY2FwZXMgdGhlICcvJyBjaGFyYWN0ZXJzIGluIFVSTHMs PGJyIGNsYXNzPSIiPg0Kd2hpY2ggSSBkaWQgbm90IHRoaW5rIHdhcyBuZWVkZWQgaW4gdGhpcyBj b250ZXh0LjxiciBjbGFzcz0iIj4NCkkgYWxzbyBzZWUgYW4gJnF1b3Q7ZXh0ZW5zaW9uX2ZpZWxk JnF1b3Q7IGNsYWltIGluIHRoZSBiYXNlNjQgYnV0IG5vdCB0aGUgZGVjb2RlZDxiciBjbGFzcz0i Ij4NCmZvcm0gb2YgdGhlIGV4YW1wbGUsIGFuZCAmcXVvdDtnaXZlbl9uYW1lJnF1b3Q7LyZxdW90 O2ZhbWlseV9uYW1lJnF1b3Q7LyZxdW90O2JpcnRoZGF0ZSZxdW90OyBpbiB0aGU8YnIgY2xhc3M9 IiI+DQpkZWNvZGVkIGV4YW1wbGUgdnMuICZxdW90O3VzZXJuYW1lJnF1b3Q7IGluIHRoZSBiYXNl NjQgdmVyc2lvbi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtOb3Rl OiBJZiB0aGUgcmVzb3VyY2Ugc2VydmVyIHBvbGljeSByZXF1aXJlcyBhIHNpZ25lZCBhbmQgZW5j cnlwdGVkPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7cmVzcG9uc2UgYW5kIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciByZWNlaXZlcyBhbiB1bmF1dGhlbnRpY2F0ZWQ8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDtyZXF1ZXN0IGNvbnRhaW5pbmcgYW4gQWNjZXB0IGhlYWRlciB3aXRoIGNvbnRl bnQgdHlwZSBvdGhlciB0aGFuPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7JnF1b3Q7YXBwbGlj YXRpb24vand0JnF1b3Q7LCBpdCBNVVNUIHJlZnVzZSB0byBzZXJ2ZSB0aGUgcmVxdWVzdCBhbmQg cmV0dXJuIGFuPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7SFRUUCBzdGF0dXMgY29kZSA0MDAu ICZuYnNwO1RoaXMgaXMgZG9uZSB0byBwcmV2ZW50IGRvd25ncmFkaW5nIGF0dGFja3MgdG88YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDtvYnRhaW4gdG9rZW4gZGF0YSBpbnRlbmRlZCBmb3IgcmVs ZWFzZSB0byBsZWdpdGltYXRlIHJlY2lwaWVudHMgb25seTxiciBjbGFzcz0iIj4NCiZuYnNwOyZu YnNwOyhzZWUgU2VjdGlvbiA2LjIpLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkknZCBz dWdnZXN0IGEgZm9yd2FyZC1yZWZlcmVuY2UgdG8gc2VjdGlvbiA0IGZvciBob3cgdGhlIEFTIHdp bGwga25vdzxiciBjbGFzcz0iIj4NCnRoZSBSUydzIHBvbGljeS4gJm5ic3A7QWx0aG91Z2gsIGdp dmVuIHRoYXQgJnF1b3Q7dW5hdXRoZW50aWNhdGVkIHJlcXVlc3QmcXVvdDsgaXM8YnIgY2xhc3M9 IiI+DQppbmNsdWRlZCBpbiB0aGUgcHJlY29uZGl0aW9ucywgcGVyaGFwcyB3ZSBkbyBub3QgbmVl ZCB0aGUgY29uZGl0aW9uYWwgb248YnIgY2xhc3M9IiI+DQomcXVvdDtyZXNvdXJjZSBzZXJ2ZXIg cG9saWN5JnF1b3Q7IGF0IGFsbD88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTZWN0aW9u IDQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgZGV0ZXJtaW5lcyB3aGF0IGFsZ29yaXRobSB0byBlbXBsb3kgdG88YnIgY2xh c3M9IiI+DQombmJzcDsmbmJzcDtzZWN1cmUgdGhlIEpXVCBmb3IgYSBwYXJ0aWN1bGFyIGludHJv c3BlY3Rpb24gcmVzcG9uc2UuICZuYnNwO1RoaXM8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtk ZWNpc2lvbiBjYW4gYmUgYmFzZWQgb24gcmVnaXN0ZXJlZCBtZXRhZGF0YSBwYXJhbWV0ZXJzIGZv ciB0aGU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtyZXNvdXJjZSBzZXJ2ZXIsIHN1cHBsaWVk IHZpYSBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24gd2l0aCB0aGU8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDtyZXNvdXJjZSBzZXJ2ZXIgcG9zaW5nIGFzIHRoZSBjbGllbnQsIGFzIGRlZmlu ZWQgYnkgdGhpcyBkcmFmdC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpuaXQ6IEkgc3Vn Z2VzdCBzL3Bvc2luZyBhcyB0aGUvYWN0aW5nIGFzIGEvLCBhbmQgcy9ieSB0aGlzIGRyYWZ0L2Jl bG93Lyw8YnIgY2xhc3M9IiI+DQpzaW5jZSBpdCdzIHJpZ2h0IGhlcmUgaW4gdGhpcyBzZWN0aW9u LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2ludHJvc3BlY3Rpb25f ZW5jcnlwdGVkX3Jlc3BvbnNlX2FsZyAmbmJzcDtPUFRJT05BTC4gJm5ic3A7SldFIFtSRkM3NTE2 XTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO2FsZ29yaXRobSAoJnF1b3Q7YWxnJnF1b3Q7IHZhbHVlKSBhcyBk ZWZpbmVkIGluIEpXQSBbUkZDNzUxOF0gZm9yPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZW5jcnlwdGluZyBp bnRyb3NwZWN0aW9uIHJlc3BvbnNlcy4gJm5ic3A7SWYgdGhpcyBpcyBzcGVjaWZpZWQsPGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7dGhlIHJlc3BvbnNlIHdpbGwgYmUgZW5jcnlwdGVkIHVzaW5nIEpXRSBhbmQg dGhlIGNvbmZpZ3VyZWQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthbGdvcml0aG0uICZuYnNwO1RoZSBkZWZh dWx0LCBpZiBvbWl0dGVkLCBpcyB0aGF0IG5vIGVuY3J5cHRpb24gaXM8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpUaGlzIHRleHQgaXMgc2xpZ2h0bHkgY29uZnVzaW5nIHdpdGggcmVzcGVj dCB0byB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbjxiciBjbGFzcz0iIj4NCnRoZSBpbnRyb3NwZWN0 aW9uX2VuY3J5cHRlZF9yZXNwb25zZV9hbGcgJnF1b3Q7YWxnJnF1b3Q7IHZhbHVlIGFuZCB0aGU8 YnIgY2xhc3M9IiI+DQppbnRyb3NwZWN0aW9uX2VuY3J5cHRlZF9yZXNwb25zZV9lbmMgJnF1b3Q7 ZW5jJnF1b3Q7IHZhbHVlLiAmbmJzcDtNeSB1bmRlcnN0YW5kaW5nIGlzPGJyIGNsYXNzPSIiPg0K dGhhdCB0aGUgJnF1b3Q7ZW5jJnF1b3Q7IGlzIGEgc3ltbWV0cmljIGJ1bGsgZW5jcnlwdGlvbiBz Y2hlbWUgdGhhdCBkaXJlY3RseTxiciBjbGFzcz0iIj4NCnByb3RlY3RzIHRoZSBwYXlsb2FkLCB3 aGVyZWFzIHRoZSAmcXVvdDthbGcmcXVvdDsgaXMgYSBrZXktd3JhcCBvciBrZXktYWdyZWVtZW50 PGJyIGNsYXNzPSIiPg0KbWVjaGFuaXNtIHVzZWQgdG8gZXN0YWJsaXNoIHRoZSBrZXkgdXNlZCBh cyBpbnB1dCBmb3IgdGhlICZxdW90O2VuYyZxdW90OyBtZXRob2QuPGJyIGNsYXNzPSIiPg0KU28s IHdoaWxlICZxdW90O2FsZ29yaXRobSAoJnF1b3Q7YWxnIHZhbHVlJnF1b3Q7KSBmb3IgZW5jcnlw dGluZyBpbnRyb3NwZWN0aW9uPGJyIGNsYXNzPSIiPg0KcmVzcG9uc2VzJnF1b3Q7IGFuZCAmcXVv dDt0aGUgcmVzcG9uc2Ugd2lsbCBiZSBlbmNyeXB0ZWQgdXNpbmcgdGhlIGNvbmZ1Z3JlZDxiciBj bGFzcz0iIj4NClsmcXVvdDthbGdvJnF1b3Q7XSBhbGdvcml0aG0mcXVvdDsgYXJlIHRlY2huaWNh bGx5IHRydWUsIHRoZXkncmUgYWxzbyBhIGJpdCBtaXNsZWFkaW5nLDxiciBjbGFzcz0iIj4NCnNp bmNlIHRoaXMgaXMgbm90IHdoYXQgZW5jcnlwdHMgdGhlICZxdW90O2J1bGsmcXVvdDsgb2YgdGhl IHJlc3BvbnNlLiAmbmJzcDtVc2luZyB0aGU8YnIgY2xhc3M9IiI+DQp0ZXJtIGZyb20gUkZDIDcx NTgsICZxdW90O2tleSBtYW5hZ2VtZW50IGFsZ29yaXRobSZxdW90Oywgd291bGQgcHJvYmFibHkg YWxsZXZpYXRlPGJyIGNsYXNzPSIiPg0KdGhpcyBjb25mdXNpb24uPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7UmVzb3VyY2Ugc2VydmVycyBtYXkgcmVnaXN0ZXIgdGhl aXIgcHVibGljIGVuY3J5cHRpb24ga2V5cyB1c2luZyB0aGU8YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDsmcXVvdDtqd2tzX3VyaSZxdW90OyBvciAmcXVvdDtqd2tzJnF1b3Q7IG1ldGFkYXRhIHBh cmFtZXRlcnMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2hvdWxkIHdlIGNpdGUgNzU5 MSBmb3IgdGhlc2UgKG9yLCByZWFsbHksIHRoZSB3aG9sZSBzZWN0aW9uKT8gJm5ic3A7V2UgZG9u J3Q8YnIgY2xhc3M9IiI+DQpjdXJyZW50bHkgbWVudGlvbiBpdCB1bnRpbCB0aGUgSUFOQSBjb25z aWRlcmF0aW9ucy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTZWN0aW9uIDU8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJcyBpdCB3b3J0aCBhIG5vdGUgdGhhdCByZXNvdXJjZSBz ZXJ2ZXJzIHdpbGwgZmV0Y2ggdGhlc2UgbWV0YWRhdGEgYW5kPGJyIGNsYXNzPSIiPg0KdXNlIHRo ZW0gYXMgaW5wdXQgdG8gdGhlaXIgZHluYW1pYyByZWdpc3RyYXRpb25zIGluIHRoZSBwcmV2aW91 cyBzZWN0aW9uPGJyIGNsYXNzPSIiPg0KKGkuZS4sIHBpY2tpbmcgZnJvbSB0aGUgbGlzdCBvZiBz dXBwb3J0ZWQgYWxnb3JpdGhtcyk/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7aW50cm9zcGVjdGlvbl9lbmNyeXB0aW9uX2FsZ192YWx1ZXNfc3VwcG9ydGVkICZuYnNw O09QVElPTkFMLiAmbmJzcDtKU09OIGFycmF5PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y29udGFpbmluZyBh IGxpc3Qgb2YgdGhlIEpXRSBbUkZDNzUxNl0gZW5jcnlwdGlvbiBhbGdvcml0aG1zPGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7KCZxdW90O2FsZyZxdW90OyB2YWx1ZXMpIGFzIGRlZmluZWQgaW4gSldBIFtSRkM3 NTE4XSBzdXBwb3J0ZWQgYnkgdGhlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aW50cm9zcGVjdGlvbiBlbmRw b2ludCB0byBlbmNyeXB0IHRoZSByZXNwb25zZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpTaW1pbGFybHkgdG8gdGhlIGFib3ZlLCBzb21lIHJlZmluZWQgdGV4dCBhYm91dCAmcXVvdDtr ZXkgbWFuYWdlbWVudDxiciBjbGFzcz0iIj4NCmFsZ29yaXRobSZxdW90OyB1c2VkIHRvIGVuY3J5 cHQgdGhlIHJlc3BvbnNlLCB3b3VsZCBwcm9iYWJseSBiZSBoZWxwZnVsLjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NClNlY3Rpb24gNjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRo ZXJlIHNlZW0gdG8gYmUgbm90YWJsZSBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGFib3V0IHF1aXRl IGEgZmV3IG9mIHRoZTxiciBjbGFzcz0iIj4NCmNsYWltcyByZWdpc3RlcmVkIGluIFNlY3Rpb24g OC4zLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNlY3Rpb24gNi4xPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KSSdtIHN1cnByaXNlZCB0byBub3Qgc2VlIGRpc2N1c3Npb24gb2Yg ZXhwbGljaXQgdHlwaW5nIChhbmQsIElJVUMsIGhvdzxiciBjbGFzcz0iIj4NCml0J3Mgbm90IGEg cmVsaWFibGUgbWl0aWdhdGlvbikgaGVyZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDtKV1QgaW50cm9zcGVjdGlvbiByZXNwb25zZXMgYW5kIE9wZW5JRCBDb25uZWN0 IElEIFRva2VucyBhcmU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtzeW50YWN0aWNhbGx5IHNp bWlsYXIuICZuYnNwO0FuIGF0dGFja2VyIGNvdWxkIHRoZXJlZm9yZSBhdHRlbXB0IHRvPGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7aW1wZXJzb25hdGUgYW4gZW5kLXVzZXIgYXQgYSBPcGVuSUQg Q29ubmVjdCByZWx5aW5nIHBhcnR5IGJ5IHBhc3Npbmc8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDt0aGUgSldUIGFzIGFuIElEIHRva2VuLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCm5p dDogJnF1b3Q7cmVzcG9uc2UgSldUJnF1b3Q7IG9yICZxdW90O0pXVCByZXNwb25zZSZxdW90Ozxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO1N1Y2ggYW4gYXR0YWNrIGNh biBiZSBwcmV2ZW50ZWQgbGlrZSBhbnkgb3RoZXIgdG9rZW4gc3Vic3RpdHV0aW9uPGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7YXR0YWNrLiAmbmJzcDtUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg TVVTVCBpbmNsdWRlIHRoZSBjbGFpbXMgJnF1b3Q7aXNzJnF1b3Q7IGFuZDxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyZxdW90O2F1ZCZxdW90OyBpbiBlYWNoIEpXVCBpbnRyb3NwZWN0aW9uIHJl c3BvbnNlLCB3aXRoIHRoZSAmcXVvdDtpc3MmcXVvdDsgdmFsdWUgc2V0IHRvPGJyIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7dGhlIGF1dGhvcml6YXRpb24gc2VydmVyJ3MgaXNzdWVyIFVSTCBhbmQg dGhlICZxdW90O2F1ZCZxdW90OyB2YWx1ZSBzZXQgdG8gdGhlPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7cmVzb3VyY2Ugc2VydmVyJ3MgaWRlbnRpZmllci4gJm5ic3A7Wy4uLl08YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpSZWxhdGVkIHRvIHRoZSBEaXNjdXNzIHBvaW50LCBob3cgZG9l cyB0aGlzIHJlbGF0ZSB0byB0aGUgZHluYW1pYyBjbGllbnQ8YnIgY2xhc3M9IiI+DQpyZWdpc3Ry YXRpb24gcGFyYW1ldGVycz88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDtbT3BlbklELkNvcmVdLiAmbmJzcDtSZWx5aW5nIHBhcnRpZXMgU0hPVUxEIGFsc28gdXNlIGFu ZCBjaGVjayB0aGUgJnF1b3Q7bm9uY2UmcXVvdDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtw YXJhbWV0ZXIgYW5kIGNsYWltIHRvIHByZXZlbnQgdG9rZW4gYW5kIGNvZGUgcmVwbGF5LjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCklzIHRoaXMgU0hPVUxEIGp1c3QgcmVmZXJyaW5nIHRv IHRoZSBiZWhhdmlvciBhbHJlYWR5IGRlc2NyaWJlZCBpbjxiciBjbGFzcz0iIj4NCk9wZW5JRC5D b3JlIChhbmQgb25seSBhcHBsaWNhYmxlIHRvIE9JREMgaW1wbGVtZW50YXRpb25zIGFzIG9wcG9z ZWQgdG88YnIgY2xhc3M9IiI+DQpKV1QtaW5zdHJvc3BlY3Rpb24gY29uc3VtZXJzKT8gJm5ic3A7 SWYgc28sIG1heWJlIGRlc2NyaXB0aXZlIGxhbmd1YWdlIGlzPGJyIGNsYXNzPSIiPg0KbW9yZSBh cHByb3ByaWF0ZSwgbGlrZSAmcXVvdDtSZWx5aW5nIHBhcnRpZXMgYXJlIGFsc28gZXhwZWN0ZWQg dG8gdXNlIGFuZDxiciBjbGFzcz0iIj4NCmNoZWNrIFsuLi5dJnF1b3Q7LjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO1Jlc291cmNlIHNlcnZlcnMgdXRpbGl6aW5nIEpX VHMgdG8gcmVwcmVzZW50IHNlbGYtY29udGFpbmVkIGFjY2VzczxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwO3Rva2VucyBjb3VsZCBiZSBzdXNjZXB0aWJsZSB0byByZXBsYXkgYXR0YWNrcy4gJm5i c3A7UmVzb3VyY2Ugc2VydmVyczxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3Nob3VsZCB0aGVy ZWZvcmUgYXBwbHkgcHJvcGVyIGNvdW50ZXIgbWVhc3VyZXMgYWdhaW5zdCByZXBsYXkgYXM8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDtkZXNjcmliZWQgaW4gW0ktRC5pZXRmLW9hdXRoLXNlY3Vy aXR5LXRvcGljc10sIHNlY3Rpb24gMi4yLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkn bSBub3Qgc3VyZSB3aGF0IHBhcnQgb2YgdGhpcyBpcyBzcGVjaWZpYyB0byB0aGUgaW50cm9zcGVj dGlvbiBjYXNlLjxiciBjbGFzcz0iIj4NCklzIGl0IHN1cHBvc2VkIHRvIGJlIHRpZWQgdG8gdGhl IHJpc2sgdGhhdCBKV1QtaW5zdHJvc3BlY3Rpb24gcHJvZHVjZXMgYTxiciBjbGFzcz0iIj4NCm5l dyByb3V0ZSBmb3IgdGhlIGdlbmVyYXRpb24gb2YgSldUIG9iamVjdHMgdGhhdCBjb3VsZCBiZSBj b25mdXNlZCBmb3I8YnIgY2xhc3M9IiI+DQpzZWxmLWNvbnRhaW5lZCBhY2Nlc3MgdG9rZW5zPzxi ciBjbGFzcz0iIj4NCm5pdDogJnF1b3Q7Y291bnRlcm1lYXN1cmVzJnF1b3Q7IGlzIHZhbGlkIGFz IGEgc2luZ2xlIHdvcmQuPGJyIGNsYXNzPSIiPg0Kbml0OiBpdCBsb29rcyBsaWtlIGl0J3Mgc2Vj dGlvbiAzLjIsIG5vdy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTZWN0aW9uIDYuMjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClBsZWFzZSBjaXRlIFJGQyA3NTI1IGFzIEJDUCAx OTUgYXMgd2VsbCBhcyBSRkMgNzUyNSAoZS5nLiwgJnF1b3Q7cGVyIEJDUCAxOTU8YnIgY2xhc3M9 IiI+DQpbUkZDNzUyNV0mcXVvdDspLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwO1RvIHByZXZlbnQgaW50cm9zcGVjdGlvbiBvZiBsZWFrZWQgdG9rZW5zIGFuZCB0byBw cmVzZW50IGFuPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7YWRkaXRpb25hbCBzZWN1cml0eSBs YXllciBhZ2FpbnN0IHRva2VuIGd1ZXNzaW5nIGF0dGFja3MgdGhlPGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7YXV0aG9yaXphdGlvbiBzZXJ2ZXIgbWF5IHJlcXVpcmUgYWxsIHJlcXVlc3RzIHRv IHRoZSB0b2tlbjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2ludHJvc3BlY3Rpb24gZW5kcG9p bnQgdG8gYmUgYXV0aGVudGljYXRlZC4gJm5ic3A7QXMgYW4gYWx0ZXJuYXRpdmUgb3IgYXM8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDthbiBhZGRpdGlvbiB0byB0aGUgYXV0aGVudGljYXRpb24s IHRoZSBpbnRlbmRlZCByZWNpcGllbnRzIG1heSBiZSBzZXQ8YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDt1cCBmb3IgZW5jcnlwdGVkIHJlc3BvbnNlcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpEbyB3ZSB3YW50IHRvIG1ha2UgZWl0aGVyIG9mIHRoZXNlICZxdW90O21heSZxdW90O3Mg aW50byBub3JtYXRpdmUgcmVjb21tZW5kYXRpb25zPGJyIGNsYXNzPSIiPg0KKG9yIG1ha2UgYSBy ZWNvbW1lbmRhdGlvbiBmb3IgcHJldmVudGlvbiBvZiBpbnRyb3NwZWN0aW9uIGRhdGEgbGVha2Fn ZTxiciBjbGFzcz0iIj4NCmV2ZW4gaW4gdGhlIGZhY2Ugb2YgdG9rZW4gbGVha2FnZSwgd2hpY2gg Y2FuIGJlIHNhdGlzZmllZCBieSBlaXRoZXI8YnIgY2xhc3M9IiI+DQptZWNoYW5pc20pPzxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFsc28sIHdlIGNvdWxkIHNheSBtb3JlIGFib3V0IGhv dyBjb25maWd1cmluZyBlbmNyeXB0aW9uIGZvciBpbnRlbmRlZDxiciBjbGFzcz0iIj4NCnJlY2lw aWVudHMgcHJvdGVjdHMgYWdhaW5zdCB1bmVuY3J5cHRlZCByZXBsaWVzIHRvIHVuaW50ZW5kZWQ8 YnIgY2xhc3M9IiI+DQpyZWNpcGllbnRzLi4uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7SW4gdGhlIGxhdHRlciBjYXNlLCBjb25maWRlbnRpYWxpdHkgaXMgZW5zdXJl ZCBieSB0aGUgZmFjdCB0aGF0IG9ubHk8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDt0aGUgbGVn aXRpbWF0ZSByZWNpcGllbnQgaXMgYWJsZSB0byBkZWNyeXB0IHRoZSByZXNwb25zZS4gJm5ic3A7 QW48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDthdHRhY2tlciBjb3VsZCB0cnkgdG8gY2lyY3Vt dmVudCB0aGlzIG1lYXN1cmUgYnkgcmVxdWVzdGluZyBhIHBsYWluPGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7SlNPTiByZXNwb25zZSwgdXNpbmcgYW4gQWNjZXB0IGhlYWRlciB3aXRoIHRoZSBj b250ZW50IHR5cGUgc2V0IHRvLDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2ZvciBleGFtcGxl LCAmcXVvdDthcHBsaWNhdGlvbi9qc29uJnF1b3Q7IGluc3RlYWQgb2YgJnF1b3Q7YXBwbGljYXRp b24vand0JnF1b3Q7LiAmbmJzcDtUbzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3ByZXZlbnQg dGhpcyBhdHRhY2sgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgTk9UIHNlcnZlIHJlcXVl c3RzPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7d2l0aCBjb250ZW50IHR5cGUgb3RoZXIgdGhh biAmcXVvdDthcHBsaWNhdGlvbi9qd3QmcXVvdDsgaWYgdGhlIHJlc291cmNlIHNlcnZlcjxiciBj bGFzcz0iIj4NCiZuYnNwOyZuYnNwO2lzIHNldCB1cCB0byByZWNlaXZlIGVuY3J5cHRlZCByZXNw b25zZXMgKHNlZSBhbHNvIFNlY3Rpb24gMykuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K Li4uLnN1Y2ggYXMgYnkgc2F5aW5nIHRoYXQgdGhlIGludHJvc3BlY3Rpb24gcmVzcG9uc2Ugd2ls bCBvbmx5IGJlIG1hZGU8YnIgY2xhc3M9IiI+DQphdmFpbGFibGUgdG8gUlNlcyB0aGF0IGFyZSBp bnRlbmRlZCByZWNpcGllbnRzIG9mIChpbiB0aGUgYXVkaWVuY2Ugb2Y/KTxiciBjbGFzcz0iIj4N CnRoZSBhY2Nlc3MgdG9rZW4gYmVpbmcgaW50cm9zcGVjdGVkLjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NClNlY3Rpb24gNi4zPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7QXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHdpdGggYSBwb2xpY3kgdGhhdCByZXF1aXJlcyB0 b2tlbiBkYXRhIHRvIGJlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7a2VwdCBjb25maWRlbnRp YWwgZnJvbSBPQXV0aCBjbGllbnRzIG11c3QgcmVxdWlyZSBhbGwgcmVxdWVzdHMgdG8gdGhlPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7dG9rZW4gaW50cm9zcGVjdGlvbiBlbmRwb2ludCB0byBi ZSBhdXRoZW50aWNhdGVkLiAmbmJzcDtBcyBhbiBhbHRlcm5hdGl2ZTxiciBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwO29yIGFzIGFuIGFkZGl0aW9uIHRvIHRoZSBhdXRoZW50aWNhdGlvbiwgdGhlIGlu dGVuZGVkIHJlY2lwaWVudHMgbWF5PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7YmUgc2V0IHVw IGZvciBlbmNyeXB0ZWQgcmVzcG9uc2VzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClt0 aGlzIGFsc28gc2VlbXMgdG8gYmUgYXNzdW1pbmcgYSBsaW5rIG5vdCBzdGF0ZWQgYmV0d2VlbiBS UyBwb2xpY3kgYW5kPGJyIGNsYXNzPSIiPg0KQVMgZW5mb3JjZW1lbnQsIGJ1dCBpdCBzZWVtcyB1 bmxpa2VseSB0aGF0IGEgZml4IHdvdWxkIG5lZWQgdG8gdG91Y2g8YnIgY2xhc3M9IiI+DQp0aGlz IHRleHRdPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2VjdGlvbiA4LjEuMTxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCm5pdDogdXNpbmcgbmVzdGVkIGxpc3RzIG1pZ2h0IG1ha2Ug dGhpcyBtb3JlIHJlYWRhYmxlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZu YnNwO28gJm5ic3A7Q2xpZW50IE1ldGFkYXRhIERlc2NyaXB0aW9uOiBTdHJpbmcgdmFsdWUgc3Bl Y2lmeWluZyB0aGUgZGVzaXJlZDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO2ludHJvc3BlY3Rpb24gcmVzcG9uc2UgZW5jcnlwdGlvbiBhbGdvcml0aG0gKGFsZyB2 YWx1ZSkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KW3NhbWUgYml0IGFib3V0ICZxdW90 O2tleSBtYW5hZ2VtZW50IGFsZ29yaXRobSZxdW90O108YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpTZWN0aW9uIDguMi4xPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7byAmbmJzcDtNZXRhZGF0YSBEZXNjcmlwdGlvbjogSlNPTiBhcnJheSBjb250YWluaW5nIGEg bGlzdCBvZiBhbGdvcml0aG1zPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7c3VwcG9ydGVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBmb3IgaW50cm9zcGVj dGlvbiByZXNwb25zZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O2VuY3J5cHRpb24gKGFsZyB2YWx1ZSkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KW2Fu ZCBoZXJlXTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNlY3Rpb24gOC4zPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KSSB0aGluayB3ZSBzaG91bGQgbWFrZSBzb21lIG1lbnRpb24g ZWFybGllciBpbiB0aGUgZG9jdW1lbnQ8YnIgY2xhc3M9IiI+DQooSW50cm9kdWN0aW9uPykgdGhh dCB3ZSBhbHNvIHJlZ2lzdGVyIHNvbWUgY29tbW9uIGNsYWltIHZhbHVlcyB0aGF0IGFyZTxiciBj bGFzcz0iIj4NCmluIHVzZSBpbiB0aGUgd2lsZCAob3Igd2hhdGV2ZXIgdGV4dCB5b3UgZmVlbCBp cyBhcHByb3ByaWF0ZSB0byBkZXNjcmliZTxiciBjbGFzcz0iIj4NCnRoZSBjbGFpbXMgaW4gcXVl c3Rpb24pLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBuZXN0ZWQgbGlzdHMgd291 bGQgYmUgZ3JlYXQgaGVyZSBhcyB3ZWxsLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCklz IHRoZXJlIGFueSBleHBlY3RhdGlvbiB0aGF0IHNvbWUgY29tYmluYXRpb24gb2YgJnF1b3Q7Z2l2 ZW5fbmFtZSZxdW90Oyw8YnIgY2xhc3M9IiI+DQomcXVvdDttaWRkbGVfbmFtZSZxdW90OywgYW5k ICZxdW90O2ZhbWlseV9uYW1lJnF1b3Q7IHdpbGwgcHJvZHVjZSBpZGVudGljYWwgY29udGVudCB0 byB0aGU8YnIgY2xhc3M9IiI+DQpmdWxsICZxdW90O25hbWUmcXVvdDsgY2xhaW0/PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7byAmbmJzcDtOYW1lOiAmcXVvdDtwcmVm ZXJyZWRfdXNlcm5hbWUmcXVvdDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDtvICZuYnNwO0Rlc2NyaXB0aW9uOiBTaG9ydGhhbmQgbmFtZSBieSB3aGljaCB0aGUgRW5k LVVzZXIgd2lzaGVzIHRvIGJlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7cmVmZXJyZWQgdG8gYXQgdGhlIFJQLCBzdWNoIGFzIGphbmVkb2Ugb3Igai5kb2UuICZu YnNwO1RoaXMgdmFsdWUgTUFZPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7YmUgYW55IHZhbGlkIEpTT04gc3RyaW5nIGluY2x1ZGluZyBzcGVjaWFsIGNoYXJhY3Rl cnMgc3VjaCBhcyBALDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Oy8sIG9yIHdoaXRlc3BhY2UuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSXQgc2VlbXMg bGlrZSB0aGVyZSBtYXkgYmUgc29tZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhYm91dCBzYW5p dHppaW5nPGJyIGNsYXNzPSIiPg0KdGhpcyBmaWVsZCBiZWZvcmUgdXNpbmcgaXQgaW4gYW4gYXBw bGljYXRpb24ncyBsb2dpYy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDtvICZuYnNwO05hbWU6ICZxdW90O3Byb2ZpbGUmcXVvdDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQombmJzcDsmbmJzcDtvICZuYnNwO0Rlc2NyaXB0aW9uOlVSTCBvZiB0aGUgRW5kLVVz ZXIncyBwcm9maWxlIHBhZ2UuICZuYnNwO1RoZSBjb250ZW50cyBvZjxiciBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoaXMgV2ViIHBhZ2UgU0hPVUxEIGJlIGFib3V0 IHRoZSBFbmQtVXNlci48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJdCdzIHNsaWdodGx5 IHN1cnBpc2luZyB0byBzZWUgdGhpcyBjbGFpbWVkIGZvciB0aGUgZW5kLXVzZXIncyBwcm9maWxl PGJyIGNsYXNzPSIiPg0Kd2hlbiBpdCBtaWdodCBlcXVhbGx5IGFwcGx5IHRvIGEgcHJvdG9jb2wg cHJvZmlsZSBvciB2YXJpYW50IGluIHVzZS48YnIgY2xhc3M9IiI+DQpCdXQgSSBhc3N1bWUgdGhp cyBpcyBhbHJlYWR5IGRlcGxveWVkLCBzbyB0aGVyZSdzIG5vIHJlYWwgcG9pbnQgaW48YnIgY2xh c3M9IiI+DQpvYmplY3RpbmcgdG8gaXRzIHJlZ2lzdHJhdGlvbi4uLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO28gJm5ic3A7TmFtZTogJnF1b3Q7YmlydGhkYXRlJnF1 b3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7byAmbmJzcDtEZXNj cmlwdGlvbjpUaW1lIHRoZSBFbmQtVXNlcidzIGluZm9ybWF0aW9uIHdhcyBsYXN0IHVwZGF0ZWQu ICZuYnNwO0l0czxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Zh bHVlIGlzIGEgSlNPTiBudW1iZXIgcmVwcmVzZW50aW5nIHRoZSBudW1iZXIgb2Ygc2Vjb25kcyBm cm9tPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7MTk3MC0wMS0w MVQwOjA6MFogYXMgbWVhc3VyZWQgaW4gVVRDIHVudGlsIHRoZSBkYXRlL3RpbWUuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhpcyBzZWVtcyBwb3RlbnRpYWxseSBjb25mdXNhYmxlIHdp dGggdGhlIHVzZXIncyBkYXkveWVhciBvZiBiaXJ0aC48YnIgY2xhc3M9IiI+DQooQWxzbywgYXJl IGxlYXAgc2Vjb25kcyBleGNsdWRlZD8pPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7byAmbmJzcDtOYW1lOiAmcXVvdDt6b25laW5mbyZxdW90OzxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO28gJm5ic3A7RGVzY3JpcHRpb246IFN0cmluZyBm cm9tIHpvbmVpbmZvIFt6b25laW5mb10gdGltZSB6b25lIGRhdGFiYXNlPGJyIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVwcmVzZW50aW5nIHRoZSBFbmQtVXNlcidz IHRpbWUgem9uZS4gJm5ic3A7Rm9yIGV4YW1wbGUsIEV1cm9wZS9QYXJpczxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO29yIEFtZXJpY2EvTG9zX0FuZ2VsZXMuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV2Ugc2VlbSB0byBiZSBtaXNzaW5nIHRoZSBhY3R1 YWwgcmVmZXJlbmNlIGVudHJ5IGZvciBbem9uZWluZm9dLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIi Pg0KT0F1dGhAaWV0Zi5vcmc8YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_47A41441F1A94401BBF374CA1F178A0Bmitedu_-- From nobody Wed Sep 4 13:09:24 2019 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 60BF3120CCB for ; Wed, 4 Sep 2019 13:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=oracle.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 ucMe4WieoMG6 for ; Wed, 4 Sep 2019 13:09:16 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 0D5E7120B56 for ; Wed, 4 Sep 2019 13:09:15 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x84K8tvP124767; Wed, 4 Sep 2019 20:09:15 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2019-08-05; bh=BCKM10qTLdMFslEI8FSeEg8cwTRww+3UlhGxFDtZMtA=; b=o9JkdmsMWBAV/h0SgGR/iyNb0hdYkZCLeoWDeuKK/suM9ciuscsc+jBPE4BNvEsFqR/f G1ZaQX13+WKuBBan79k5XIGqshUMwbEmq6u39s4xgAT+Kfb8XDbor0HIjUaO+KJbtFP3 IPT4eY+DBIAJMdBIw8E62No3iGRqHwvaNdkcEGEr/p7VGFWCtxNzMzueE1Q1tysHg+TF 59W6BQ/iyKkYICsQ4HL/6eZP/Z8h3uOSfgKFNh3raY6l8iiRteOiyLKqwjCkltJ1jw6/ 5BoyqkPgL2xsVR9Ml3Gxe/LGlM81yQpWglwBKJxJTVXM/XgySysDzgbNU5D9L3Y2tQzZ qw== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 2utkgqr6m6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 04 Sep 2019 20:09:14 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x84K95f7128088; Wed, 4 Sep 2019 20:09:14 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 2ut1hp2751-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 04 Sep 2019 20:09:13 +0000 Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x84K9CRo018283; Wed, 4 Sep 2019 20:09:12 GMT Received: from [10.230.42.19] (/24.244.23.36) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Sep 2019 13:09:11 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-C158CD25-22E6-4729-BB59-684D2BC3639F Mime-Version: 1.0 (1.0) From: Phil Idm Hunt X-Mailer: iPhone Mail (16G77) In-Reply-To: <9F5DA44D-BD3C-43B2-A88C-66394BD7BE85@mit.edu> Date: Wed, 4 Sep 2019 13:09:10 -0700 Cc: Torsten Lodderstedt , "Schaar, R.M. (Remco) - Logius" , "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <38503cd44d9e455bad4432d9ba5e82e8@SV1601507.frd.shsdir.nl> <308A4847-6390-4D17-BE52-B604E2428391@lodderstedt.net> <10f13f75c100454aa8092961673541b2@SV1601499.frd.shsdir.nl> <040dcf9971fd4c618e94b957461d14f2@SV1601507.frd.shsdir.nl> <9468283E-8B97-4DAF-8493-895B475F6BC9@lodderstedt.net> <9F5DA44D-BD3C-43B2-A88C-66394BD7BE85@mit.edu> To: Justin Richer X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9370 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1909040202 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9370 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1909040202 Archived-At: Subject: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 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: Wed, 04 Sep 2019 20:09:21 -0000 --Apple-Mail-C158CD25-22E6-4729-BB59-684D2BC3639F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1=20 This feels like it has similar requirements and concerns as for SET and may b= e should leverage it to avoid confusion and inconsistencies down the road.=20= Phil > On Sep 4, 2019, at 12:49 PM, Justin Richer wrote: >=20 > As I=E2=80=99ve said in the past, I think there is and should be a clear d= ifference between a JWT access token and a JWT-formatted response from any e= ndpoint. It gets extra fuzzy here because the response from the endpoint rep= resents the token being introspected.=20 >=20 > However, I think they are still two very different things because the intr= ospection response by definition represents what the token was at the time o= f introspection. That=E2=80=99s why the =E2=80=9Cactive=E2=80=9D claim is im= portant here, along with the timestamp information in the JWT container =E2=80= =94 you can say that the token *was* active at the time of introspection, bu= t you can=E2=80=99t say it=E2=80=99s still active without introspecting the t= oken again to check. This leads to exactly the kind of collision that=E2=80=99= s being discussed here. It=E2=80=99s confusing for developers of both the AS= and the RS, and I fear it=E2=80=99s going to lead to an AS choosing one int= erpretation and an RS choosing another, and therefore leaving open a door to= security issues down the road. >=20 > Also, remember one of the main reasons that we require some form of RS aut= hentication to the token endpoint is that different RS=E2=80=99s can get dif= ferent answers for the same token. The AS can tailor its response based on w= hat scopes the RS is supposed to know about, or which RS=E2=80=99s can know a= user=E2=80=99s identifier (or even use pairwise identifiers), or even which= RS is supposed to know about a given token at all. In each of these cases, u= sing this draft, you=E2=80=99ll get a different JWT out for the same token o= n the way in. You=E2=80=99re not simply translating an access token to anoth= er access token here =E2=80=94 if you want to do that, use token exchange an= d do it properly with an OAuth grant. Instead, you=E2=80=99re getting inform= ation about the token itself at the time of the request and from the perspec= tive of the requestor, and you happen to be wrapping the response in a conta= iner that is also widely used to format access tokens.=20 >=20 > The separation that Torsten points out below brings up one of the biggest p= roblems with JWTs as a data container format =E2=80=94 all the information a= bout the JWT itself is mixed in with the thing it=E2=80=99s carrying informa= tion about. We see this issue with JAR, where the =E2=80=9Caud=E2=80=9D para= meter can mean the audience of the authorization request and the audience of= the JWT used to carry the authorization request. We also see this a little b= it in dynamic client registration=E2=80=99s software statement. Root-level J= WT claims are a poor mechanism for this. >=20 > In retrospect, what I wish we=E2=80=99d done with all of them using a name= d payload like with SET=E2=80=99s =E2=80=9Cevent=E2=80=9D claim. Even there,= we had a lot of argument about a =E2=80=9Csub=E2=80=9D claim inside the =E2= =80=9Cevent=E2=80=9D object vs. one at the root of the JWT container, but at= least in these cases we now had an opportunity to write clear language abo= ut what each meant in each circumstance. I realize this draft is already wel= l along in its process, and I haven=E2=80=99t put in the review time or comm= ents to date myself, but I think it=E2=80=99s unfortunate that the draft doe= sn=E2=80=99t define a sub-claim like =E2=80=9Caccess_token=E2=80=9D or =E2=80= =9Ctoken_information=E2=80=9D to carry inside the JWT payload. This would so= lve the problem of differentiating the =E2=80=9Ciat=E2=80=9D for the token i= tself vs. the JWT container of the response. >=20 > The group may also recall that I originally said that this draft should no= t be done in light of only introspection, and instead should be a generic me= chanism across OAuth=E2=80=99s various endpoints. Weird combinations like th= e =E2=80=9Ciat=E2=80=9D claim here are a driver for having a solid generic m= echanism instead of a handful of slightly different definitions.=20 >=20 > So what should we do here? If we are to keep the current practice of putti= ng everything in the root of the JWT, we should have different claim names t= o differentiate the envelope and the token. The problem here is that =E2=80=9C= iat=E2=80=9D is already defined in RFC7662 as referring to the token and in R= FC7519 as referring to the JWT (which is not a token, but the container for t= he token information). I=E2=80=99m not sure which is worse, defining an =E2=80= =9Ciat=E2=80=9D for the introspection response or one for the JWT but only i= n this instance. Both feel really messy, and in cases like Torsten=E2=80=99s= they collapse to the same value. >=20 > If however we put the introspection response in its own sub-section of the= JWT payload, then we could avoid the namespace collision entirely. We would= need normative rules like in SET to define how these fields relate to each o= ther, but I see that as a tractable problem with a reasonable (if imperfect)= precedent.=20 >=20 > Either path means redoing WGLC and the associated reviews, I=E2=80=99m afr= aid. Leaving it as-is works for the driving use case where the information i= s all the same, but I don=E2=80=99t find it to be a particularly clean repre= sentation of the information in question. >=20 > =E2=80=94 Justin >=20 >> On Sep 4, 2019, at 5:21 AM, Torsten Lodderstedt = wrote: >>=20 >> Hi Remco, >>=20 >>> On 31. Aug 2019, at 21:27, Schaar, R.M. (Remco) - Logius wrote: >>>=20 >>> Hello Torsten, >>>=20 >>> (my apologies for making a typo previously) >>=20 >> Thanks :-) >>=20 >>>=20 >>> Time of introspection is critical if you want to use the signed introspe= ction >>> response for later accountability or audit purposes. For example, a Clie= nt >>> obtains an access token A at time t. Now a resource server receives A at= time >>> t+1, calls introspection and receives a response containing active=3Dtru= e. At >>> t+2 the acccess token is revoked. At time t+3 the resource server makes a= new >>> introspection request, now receives a response containing active=3Dfalse= . The >>> only difference would be the value of the active parameter. Without the t= ime >>> of introspection nor a unique id covered by the signature, one cannot ma= ke a >>> conclusive distinction between subsequent responses if revocation may be= in >>> play. >>=20 >> That=E2=80=99s a good point. =20 >>=20 >>>=20 >>> The draft specifies=20 >>> [...] to return responses as JWTs. >>> This could either mean "the response is returned in JWT format" or "the >>> response contains a JWT representation of the inspected token=E2=80=9D. >>=20 >> I'm meanwhile leaning towards "the response is returned in JWT format=E2=80= =9D. >>=20 >>> Not having >>> clear, separate parameters to distinguish between the time and id of the= >>> token and the time and id of the response results in double meaning. As a= >>> consequence, it is either having the risk of replay of an access token o= r >>> replay of an introspection response instead of neither. >>=20 >> I=E2=80=99m not sure how an attacker could replay an introspection respon= se given it is tighted to a certain endpoint via the iss claim.=20 >>=20 >> I agree the RS lacks a way to proof when it was provided with the access t= oken data by the AS.=20 >>=20 >> The problem in my opinion is the overlay between the original access toke= n data (e.g. when was it issued by the AS) and the data belonging to the rep= resentation in the introspection response (when was the response created). C= onceptually, this means we require two separat =E2=80=9Ciat" (alike) claims t= o distinguish both aspects.=20 >>=20 >> I could image two ways to handle this: >> - add another iat claim, e.g. =E2=80=9Ctir_iat", to the JWT >> - add another =E2=80=9Ciat" claim to the JWS header containing the instan= t when the token introspection response was created >>=20 >> What do you think? >>=20 >> best regards, >> Torsten.=20 >>=20 >>>=20 >>> Kind regards, >>> Remco schaar >>>=20 >>> -----Oorspronkelijk bericht----- >>> Van: Torsten Lodderstedt =20 >>> Verzonden: woensdag 28 augustus 2019 11:14 >>> Aan: Schaar, R.M. (Remco) - Logius >>> CC: oauth@ietf.org >>> Onderwerp: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-intros= pection-response-05 >>>=20 >>> Hi Rhemco, >>>=20 >>>> On 26. Aug 2019, at 09:42, Schaar, R.M. (Remco) - Logius wrote: >>>>=20 >>>> Hello Thorsten, >>>>=20 >>>> Thank you for your response. I have a few more questions/comments as >>>> follow-up... >>>>=20 >>>> You state that RFC7519 and RFC7662 "just" define different representati= ons >>>> for token data. If the draft RFC would refer to RFC 7515 (JWS), I would= >>>> agree. However, RFC7519 (JWT) explicitly adds semantics to some specifi= c >>>> parameters (e.g. aud, jti and iat). RFC7662 has different semantics for= >>>> the several of the same parameters. >>>> For instance the 'iat', is the moment of issuance of the JWT in RFC7519= . In >>>> RFC7662 that is the "when this token was originally issued". This time w= ill >>>> vary in use cases without immediate introspection of an access token. >>>=20 >>> I read the text differently. In my interpretation =E2=80=9Cwhen the toke= n was originally issued=E2=80=9D stated from the perspective of the introspe= ction endpoint refers exactly to the same instant as =E2=80=9Cthe time at wh= ich the JWT was >>> issued=E2=80=9D. >>>=20 >>>>=20 >>>> For the use case of the resource server relying on verifiable data, as >>>> described in the introduction of the draft RFC, the time of the introsp= ection >>>> is critical. >>>=20 >>> Why is this time critical? >>>=20 >>>> In particular when combined with revocation, the time of >>>> introspection and the 'active' status can differ between two subsequent= calls >>>> for introspection. >>>=20 >>> The status at token introspection request time is indeed critical. RFC 7= 662 gives a good indication how this value should be calculated. >>>=20 >>> =E2=80=9C=E2=80=A6 a "true" >>> value return for the "active" property will generally indicate >>> that a given token has been issued by this authorization server, >>> has not been revoked by the resource owner, and is within its >>> given time window of validity (e.g., after its issuance time and >>> before its expiration time)."=20 >>>=20 >>> So it represents the results of the issuer check, the revocation check a= nd the validity check in one boolean value.=20 >>>=20 >>>>=20 >>>> If the draft RFC just produces a JWT representation of the access token= , >>>> including 'active' would not make sense as the JWT will expire without >>>> updating it to false. Leaving 'active' out would make it incompatible w= ith >>>> RFC7662 introspection responses. >>>=20 >>> =E2=80=9Cactive=E2=80=9D is not part of the JWT representation I referre= d to. The AS needs to determine the active value for every token introspecti= on request.=20 >>>=20 >>> If the RS would consume JWTs, it would determine the =E2=80=9Cactive=E2=80= =9D value itself by inspecting the iss claim and check against its AS whitel= ist, check the signature and the iat & exp values. Determining the revocatio= n status would require an information exchange with the AS of some sort.=20 >>>=20 >>>> Similar, not including a unique 'jti' per introspection response would m= ake >>>> the resource server vulnerable to replay attacks. >>>=20 >>> To the contrary, including a different =E2=80=9Cjit" with every token in= trospection response would make the RS vulnerable to replay of one time acce= ss token since it remove the possibility for the RS to identity a certain ac= cess token.=20 >>>=20 >>>> Or the resource server >>>> would mistakenly refer to non-unique tokens, making the responses unsui= table >>>> for accountability and audit purposes. >>>>=20 >>>>=20 >>>> As to why someone would want to distinguish a JWT access token from an >>>> introspection response: several use cases come to mind. >>>>=20 >>>> First of all, even if one is using standalone interpretable JWT access t= okens, >>>> one may want to combine that with revocation checking using introspecti= on. The >>>> interpretation and meaning of the JWT and the introspection response th= an do >>>> differ and matter. >>>=20 >>> As I described above, I don=E2=80=99t see any difference.=20 >>>=20 >>>>=20 >>>> Another use case would be a mixed ecosystem with resource servers relyi= ng on >>>> introspection while others do parse JWT access tokens. A single, unifor= m >>>> implementation for the AS would than mix both as well. >>>=20 >>> See above - I don=E2=80=99t see any issue.=20 >>>=20 >>>>=20 >>>> A last use case could be exchanging access tokens with a subset of the f= ull >>>> set of applicable parameters, to reduce the size of access tokens. Addi= tional >>>> information can be exchanged via introspection, resulting in mixed JWT a= ccess >>>> tokens and introspection as well. >>>=20 >>> That=E2=80=99s all possible within the current text.=20 >>>=20 >>> kind regards, >>> Torsten=20 >>>=20 >>>>=20 >>>> Kind regards, >>>> Remco Schaar >>>>=20 >>>> -----Oorspronkelijk bericht----- >>>> Van: Torsten Lodderstedt =20 >>>> Verzonden: zaterdag 17 augustus 2019 14:00 >>>> Aan: Schaar, R.M. (Remco) - Logius >>>> CC: oauth@ietf.org >>>> Onderwerp: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-intro= spection-response-05 >>>>=20 >>>> Hi Remco, >>>>=20 >>>>> On 6. Aug 2019, at 16:01, Schaar, R.M. (Remco) - Logius wrote: >>>>>=20 >>>>> Hello, >>>>=20 >>>> [...] >>>> RFC 7519 and RFC 7662 =E2=80=9Cjust=E2=80=9D define different represent= ations for token data. In RFC 7519 the data is carried in the token itself (= which also means the format of the token is well-defined and know to the RS)= whereas RFC 7662 defines a way to inspect tokens via an API provided by the= AS. The latter is typically used in conjunction with opaque tokens, i.e. th= e RS does not have a clue how to parse and interpret the token. The token mi= ght just be a handle to a database entry at the AS in this case.=20 >>>>=20 >>>> This also means a JWT (RFC 7662) and the Introspection Response are con= ceptually the same from a RSs perspective. >>>>=20 >>>> [...] >>>>=20 >>>>> The =E2=80=98jti=E2=80=99 parameter however will always be ambiguous. A= s it is an identifier, it should differ for the introspected token and the i= ntrospection response by definition. Hence the semantics of =E2=80=98jti=E2=80= =99 in a JWT introspection response is unclear. The same can apply to the =E2= =80=98iat=E2=80=99, =E2=80=98nbf=E2=80=99 and =E2=80=98exp=E2=80=99 claims i= n a JWT introspection response. >>>>=20 >>>> I don=E2=80=99t understand the difference you are making. All before me= ntioned claims are related to the (abstract) access token. You may think of t= he Introspection Response as _the_ JWT representation of the access token pr= oduced by the AS for the RS. >>>>=20 >>>>>=20 >>>>> Can someone clarify the semantics of claims in an introspection respon= se JWT that are defined in both RFC7662 and RFC7519? >>>>>=20 >>>>> Furthermore, the introspection response should use the =E2=80=98iss=E2= =80=99 and =E2=80=98aud=E2=80=99 claims to avoid cross-JWT confusion (sectio= n 6.1). The =E2=80=98iss=E2=80=99 and =E2=80=98aud=E2=80=99 of an introspect= ed token will typically be the same as those of the introspection response. H= ence a JWT access token cannot be distinguished from an introspection respon= se using =E2=80=98iss=E2=80=99 and =E2=80=98aud=E2=80=99 as suggested in the= draft.. >>>>>=20 >>>>> Introspection refers to JWT best-current-practice. The draft BCP recom= mends using explicit typing of JWTs, however the draft JWT response for intr= ospection does not apply this recommendation and uses the generic =E2=80=98a= pplication/jwt=E2=80=99 instead... The BCP has other recommendations in sect= ion 3.12, but these may be insufficient to distinguish a JWT access token fr= om a JWT introspection response. >>>>=20 >>>> Good point. The reason why the BCP recommends explicit typing is to pre= vent replay in other contexts. In the end typing is a compelling concept unf= ortunately not broadly used in the wild. >>>>=20 >>>> So the JWT Introspection Response draft copes with that attack angle by= making iss and aud mandatory.=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> How would people suggest to best distinguish a JWT (access) token from= a JWT introspection response? >>>>=20 >>>> Why should you? One reason why we extended the Introspection Response w= as to eliminate the difference between JWTs directly used as access tokens a= nd Introspection Responses. >>>>=20 >>>> best regards, >>>> Torsten.=20 >>>>=20 >>>>=20 >>>> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u= niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden= , wordt u verzocht dat aan de afzender te melden en het bericht te verwijder= en. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard oo= k, die verband houdt met risico's verbonden aan het elektronisch verzenden v= an berichten. >>>> This message may contain information that is not intended for you. If y= ou are not the addressee or if this message was sent to you by mistake, you a= re requested to inform the sender and delete the message. The State accepts n= o liability for damage of any kind resulting from the risks inherent in the e= lectronic transmission of messages. >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&= r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D0_FcucFstqzt0Hyr3ivbMX8i= 4a2La24tYRek5n-Xgvs&s=3DLTwDtpeHVz9jDIok9JOtN6dd1TS4i-3VoZLPdt6L2Ns&e=3D=20 --Apple-Mail-C158CD25-22E6-4729-BB59-684D2BC3639F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 

This feels like= it has similar requirements and concerns as for SET and may be should lever= age it to avoid confusion and inconsistencies down the road. 

<= div id=3D"AppleMailSignature" dir=3D"ltr">Phil

On S= ep 4, 2019, at 12:49 PM, Justin Richer <jricher@mit.edu> wrote:

As I=E2=80=99ve said in the past, I think there is and shoul= d be a clear difference between a JWT access token and a JWT-formatted respo= nse from any endpoint. It gets extra fuzzy here because the response from th= e endpoint represents the token being introspected. 

However, I think they are still two very different things be= cause the introspection response by definition represents what the token was= at the time of introspection. That=E2=80=99s why the =E2=80=9Cactive=E2=80=9D= claim is important here, along with the timestamp information in the JWT container =E2=80=94 you can say that the token *was* active at t= he time of introspection, but you can=E2=80=99t say it=E2=80=99s still activ= e without introspecting the token again to check. This leads to exactly the k= ind of collision that=E2=80=99s being discussed here. It=E2=80=99s confusing= for developers of both the AS and the RS, and I fear it=E2=80=99s going to l= ead to an AS choosing one interpretation and an RS choosing another, and the= refore leaving open a door to security issues down the road.

Also, remember one of the main reasons that we require some f= orm of RS authentication to the token endpoint is that different RS=E2=80=99= s can get different answers for the same token. The AS can tailor its respon= se based on what scopes the RS is supposed to know about, or which RS=E2=80=99s can know a user=E2=80=99s identifier (= or even use pairwise identifiers), or even which RS is supposed to know abou= t a given token at all. In each of these cases, using this draft, you=E2=80=99= ll get a different JWT out for the same token on the way in. You=E2=80=99re not simply translating an access token to another ac= cess token here =E2=80=94 if you want to do that, use token exchange and do i= t properly with an OAuth grant. Instead, you=E2=80=99re getting information a= bout the token itself at the time of the request and from the perspective of the requestor, and you happen to be wrapping the re= sponse in a container that is also widely used to format access tokens. = ;

The separation that Torsten points out below brings up one of the biggest pr= oblems with JWTs as a data container format =E2=80=94 all the information ab= out the JWT itself is mixed in with the thing it=E2=80=99s carrying informat= ion about. We see this issue with JAR, where the =E2=80=9Caud=E2=80=9D parameter can mean the audience of the authorizat= ion request and the audience of the JWT used to carry the authorization requ= est. We also see this a little bit in dynamic client registration=E2=80=99s s= oftware statement. Root-level JWT claims are a poor mechanism for this.

In retrospect, what I wish we=E2=80=99d done with all of the= m using a named payload like with SET=E2=80=99s =E2=80=9Cevent=E2=80=9D clai= m. Even there, we had a lot of argument about a =E2=80=9Csub=E2=80=9D claim i= nside the =E2=80=9Cevent=E2=80=9D object vs. one at the root of the JWT cont= ainer, but at least in these cases  we now had an opportunity to write clear language abou= t what each meant in each circumstance. I realize this draft is already well= along in its process, and I haven=E2=80=99t put in the review time or comme= nts to date myself, but I think it=E2=80=99s unfortunate that the draft doesn=E2=80=99t define a sub-claim like =E2=80=9Caccess_toke= n=E2=80=9D or =E2=80=9Ctoken_information=E2=80=9D to carry inside the JWT pa= yload. This would solve the problem of differentiating the =E2=80=9Ciat=E2=80= =9D for the token itself vs. the JWT container of the response.

The group may also recall that I originally said that this d= raft should not be done in light of only introspection, and instead should b= e a generic mechanism across OAuth=E2=80=99s various endpoints. Weird combin= ations like the =E2=80=9Ciat=E2=80=9D claim here are a driver for having a solid generic mechanism instead of a handful of slightl= y different definitions. 

So what should we do here? If we are to keep the current pra= ctice of putting everything in the root of the JWT, we should have different= claim names to differentiate the envelope and the token. The problem here i= s that =E2=80=9Ciat=E2=80=9D is already defined in RFC7662 as referring to the token and in RFC7519 as referring to the JWT= (which is not a token, but the container for the token information). I=E2=80= =99m not sure which is worse, defining an =E2=80=9Ciat=E2=80=9D for the intr= ospection response or one for the JWT but only in this instance. Both feel really messy, and in cases like Torsten=E2=80=99s they c= ollapse to the same value.

If however we put the introspection response in its own sub-= section of the JWT payload, then we could avoid the namespace collision enti= rely. We would need normative rules like in SET to define how these fields r= elate to each other, but I see that as a tractable problem with a reasonable (if imperfect) precedent.&nbs= p;

Either path means redoing WGLC and the associated reviews, I= =E2=80=99m afraid. Leaving it as-is works for the driving use case where the= information is all the same, but I don=E2=80=99t find it to be a particular= ly clean representation of the information in question.

=E2=80=94 Justin

On Sep 4, 2019, at 5:21 AM, Torsten Lodderstedt <torsten@lodderstedt.net> w= rote:

Hi Remco,

On 31. Aug 2019, at 21:27, Schaar, R.M.= (Remco) - Logius <r= emco.schaar@logius.nl> wrote:

Hello Torsten,

(my apologies for making a typo previously)

Thanks :-)


Time of introspection is critical if you want to use the signed introspectio= n
response for later accountability or audit purposes. For example, a Client obtains an access token A at time t. Now a resource server receives A at tim= e
t+1, calls introspection and receives a response containing active=3Dtrue. A= t
t+2 the acccess token is revoked. At time t+3 the resource server makes a ne= w
introspection request, now receives a response containing active=3Dfalse. Th= e
only difference would be the value of the active parameter. Without the time=
of introspection nor a unique id covered by the signature, one cannot make a=
conclusive distinction between subsequent responses if revocation may be in<= br class=3D""> play.

That=E2=80=99s a good point.  


The draft specifies
     [...] to return responses as JWTs.
This could either mean "the response is returned in JWT format" or "the
response contains a JWT representation of the inspected token=E2=80=9D.

I'm meanwhile leaning towards "the response is returned in JWT format=E2=80=9D= .

Not having
clear, separate parameters to distinguish between the time and id of the
token and the time and id of the response results in double meaning. As a consequence, it is either having the risk of replay of an access token or replay of an introspection response instead of neither.

I=E2=80=99m not sure how an attacker could replay an introspection response g= iven it is tighted to a certain endpoint via the iss claim.

I agree the RS lacks a way to proof when it was provided with the access tok= en data by the AS.

The problem in my opinion is the overlay between the original access token d= ata (e.g. when was it issued by the AS) and the data belonging to the repres= entation in the introspection response (when was the response created). Conc= eptually, this means we require two separat =E2=80=9Ciat" (alike) claims to distinguish both aspects.

I could image two ways to handle this:
- add another iat claim, e.g. =E2=80=9Ctir_iat", to the JWT
- add another =E2=80=9Ciat" claim to the JWS header containing the instant w= hen the token introspection response was created

What do you think?

best regards,
Torsten.


Kind regards,
Remco schaar

-----Oorspronkelijk bericht-----
Van: Torsten Lodderstedt <torsten@lodderstedt.net>
Verzonden: woensdag 28 augustus 2019 11:14
Aan: Schaar, R.M. (Remco) - Logius <remco.schaar@logius.nl>
CC: oauth@ietf.org
Onderwerp: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspect= ion-response-05

Hi Rhemco,

On 26. Aug 2019, at 09:42, Schaar, R.M.= (Remco) - Logius <r= emco.schaar@logius.nl> wrote:

Hello Thorsten,

Thank you for your response. I have a few more questions/comments as
follow-up...

You state that RFC7519 and RFC7662 "just" define different representations for token data. If the draft RFC would refer to RFC 7515 (JWS), I would
agree. However, RFC7519 (JWT) explicitly adds semantics to some specific
parameters (e.g. aud, jti and iat). RFC7662 has different semantics for
the several of the same parameters.
For instance the 'iat', is the moment of issuance of the JWT in RFC7519. In<= br class=3D""> RFC7662 that is the "when this token was originally issued". This time will<= br class=3D""> vary in use cases without immediate introspection of an access token.

I read the text differently. In my interpretation =E2=80=9Cwhen the token wa= s originally issued=E2=80=9D stated from the perspective of the introspectio= n endpoint refers exactly to the same instant as =E2=80=9Cthe time at which t= he JWT was
 issued=E2=80=9D.


For the use case of the resource server relying on verifiable data, as
described in the introduction of the draft RFC, the time of the introspectio= n
is critical.

Why is this time critical?

In particular when combined with revoca= tion, the time of
introspection and the 'active' status can differ between two subsequent call= s
for introspection.

The status at token introspection request time is indeed critical. RFC 7662 g= ives a good indication how this value should be calculated.

=E2=80=9C=E2=80=A6 a "true"
    value return for the "active" property will generall= y indicate
    that a given token has been issued by this authoriza= tion server,
    has not been revoked by the resource owner, and is w= ithin its
    given time window of validity (e.g., after its issua= nce time and
    before its expiration time)."

So it represents the results of the issuer check, the revocation check and t= he validity check in one boolean value.


If the draft RFC just produces a JWT representation of the access token,
including 'active' would not make sense as the JWT will expire without
updating it to false. Leaving 'active' out would make it incompatible with RFC7662 introspection responses.

=E2=80=9Cactive=E2=80=9D is not part of the JWT representation I referred to= . The AS needs to determine the active value for every token introspection r= equest.

If the RS would consume JWTs, it would determine the =E2=80=9Cactive=E2=80=9D= value itself by inspecting the iss claim and check against its AS whitelist= , check the signature and the iat & exp values. Determining the revocati= on status would require an information exchange with the AS of some sort.

Similar, not including a unique 'jti' p= er introspection response would make
the resource server vulnerable to replay attacks.

To the contrary, including a different =E2=80=9Cjit" with every token intros= pection response would make the RS vulnerable to replay of one time access t= oken since it remove the possibility for the RS to identity a certain access= token.

Or the resource server
would mistakenly refer to non-unique tokens, making the responses unsuitable=
for accountability and audit purposes.


As to why someone would want to distinguish a JWT access token from an
introspection response: several use cases come to mind.

First of all, even if one is using standalone interpretable JWT access token= s,
one may want to combine that with revocation checking using introspection. T= he
interpretation and meaning of the JWT and the introspection response than do=
differ and matter.

As I described above, I don=E2=80=99t see any difference.


Another use case would be a mixed ecosystem with resource servers relying on=
introspection while others do parse JWT access tokens. A single, uniform
implementation for the AS would than mix both as well.

See above - I don=E2=80=99t see any issue.


A last use case could be exchanging access tokens with a subset of the full<= br class=3D""> set of applicable parameters, to reduce the size of access tokens. Additiona= l
information can be exchanged via introspection, resulting in mixed JWT acces= s
tokens and introspection as well.

That=E2=80=99s all possible within the current text.

kind regards,
Torsten


Kind regards,
Remco Schaar

-----Oorspronkelijk bericht-----
Van: Torsten Lodderstedt <torsten@lodderstedt.net>
Verzonden: zaterdag 17 augustus 2019 14:00
Aan: Schaar, R.M. (Remco) - Logius <remco.schaar@logius.nl>
CC: oauth@ietf.org
Onderwerp: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspect= ion-response-05

Hi Remco,

On 6. Aug 2019, at 16:01, Schaar, R.M. (= Remco) - Logius <rem= co.schaar@logius.nl> wrote:

Hello,

[...]
RFC 7519 and RFC 7662 =E2=80=9Cjust=E2=80=9D define different representation= s for token data. In RFC 7519 the data is carried in the token itself (which= also means the format of the token is well-defined and know to the RS) wher= eas RFC 7662 defines a way to inspect tokens via an API provided by the AS. The latter is typically used in conjunction w= ith opaque tokens, i.e. the RS does not have a clue how to parse and interpr= et the token. The token might just be a handle to a database entry at the AS= in this case.

This also means a JWT (RFC 7662) and the Introspection Response are conceptu= ally the same from a RSs perspective.

[...]

The =E2=80=98jti=E2=80=99 parameter how= ever will always be ambiguous. As it is an identifier, it should differ for t= he introspected token and the introspection response by definition. Hence th= e semantics of =E2=80=98jti=E2=80=99 in a JWT introspection response is unclear. The same can apply to the =E2=80=98iat=E2=80=99, =E2=80=98nbf=E2= =80=99 and =E2=80=98exp=E2=80=99 claims in a JWT introspection response.

I don=E2=80=99t understand the difference you are making. All before mention= ed claims are related to the (abstract) access token. You may think of the I= ntrospection Response as _the_ JWT representation of the access token produc= ed by the AS for the RS.


Can someone clarify the semantics of claims in an introspection response JWT= that are defined in both RFC7662 and RFC7519?

Furthermore, the introspection response should use the =E2=80=98iss=E2=80=99= and =E2=80=98aud=E2=80=99 claims to avoid cross-JWT confusion (section 6.1)= . The =E2=80=98iss=E2=80=99 and =E2=80=98aud=E2=80=99 of an introspected tok= en will typically be the same as those of the introspection response. Hence a= JWT access token cannot be distinguished from an introspection response using =E2=80=98iss=E2= =80=99 and =E2=80=98aud=E2=80=99 as suggested in the draft..

Introspection refers to JWT best-current-practice. The draft BCP recommends u= sing explicit typing of JWTs, however the draft JWT response for introspecti= on does not apply this recommendation and uses the generic =E2=80=98applicat= ion/jwt=E2=80=99 instead... The BCP has other recommendations in section 3.12, but these may be insufficient to distingui= sh a JWT access token from a JWT introspection response.

Good point. The reason why the BCP recommends explicit typing is to prevent r= eplay in other contexts. In the end typing is a compelling concept unfortuna= tely not broadly used in the wild.

So the JWT Introspection Response draft copes with that attack angle by maki= ng iss and aud mandatory.



How would people suggest to best distinguish a JWT (access) token from a JWT= introspection response?

Why should you? One reason why we extended the Introspection Response was to= eliminate the difference between JWTs directly used as access tokens and In= trospection Responses.

best regards,
Torsten.


Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u nie= t de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wo= rdt u verzocht dat aan de afzender te melden en het bericht te verwijderen. D= e Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden a= an het elektronisch verzenden van berichten.
This message may contain information that is not intended for you. If you ar= e not the addressee or if this message was sent to you by mistake, you are r= equested to inform the sender and delete the message. The State accepts no l= iability for damage of any kind resulting from the risks inherent in the electronic transmission of message= s.


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail-C158CD25-22E6-4729-BB59-684D2BC3639F-- From nobody Wed Sep 4 13:47:23 2019 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 9621C120047 for ; Wed, 4 Sep 2019 13:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 udo6AmpZ8wFQ for ; Wed, 4 Sep 2019 13:47:19 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 DFFBD12008B for ; Wed, 4 Sep 2019 13:47:18 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id x4so47347211iog.13 for ; Wed, 04 Sep 2019 13:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gZ/qzeiys7SbIeaHZu8NRkNUqoHUhKlgQmVtRUSNMfM=; b=AGlPdInfiWKt/r8k8eY2VCd5JpFQLSyGqgMhP0zKyQCPhPZ1/cazOwwWp2TS4aXarF L+1jNqVCV4URohpV+/CxMNmTkiqHr559dxbI0xtlag3PX35FaB6MMq/DUNGWJlGJD89c 6R4L9p71OFZdIjTzQzMcZheypqKAI3aFpu9iQ= 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=gZ/qzeiys7SbIeaHZu8NRkNUqoHUhKlgQmVtRUSNMfM=; b=SC89HgoAX5cweTCAWyubkQO1lHMEm/JKcifrWO5raEXKf6/z3QtD3UtPOAlsu80bjY 4N5BZcnIm9p9fDJt/t/d9rvtBN+H6pxlFyc+MQdEyIlhcz0oiVRuoMe6kf3tm08WQCT4 sunHHkD5jAh8g2V+68dxdCj86Se1nmu4NIK3OVWLITlXuwIXVaS1aYT5d1WSlSuLxbvq zXSpkwmF3JeLZblI7ZWLn8h6Gz0TCuib7eQew3v4t/+zGCxV9wiaazawryXUKEiF5WC4 97xmV83ecCdfnPtMugXulIP02MeCl4Q574f3Fv851zoCxu4P1VAt7xylOKCxhhfGOZmZ nzkw== X-Gm-Message-State: APjAAAUp3KB0887WgZ4lAwhKfVdNiveuW1TClmeMTzmVoH5XGUWnrFRL N/MKp7q+/lKBXXCiYfhoDb5vpJJIsIIcTt8BTelWz+FVevKLr3EtopiZQOX1CB/k0kDkIaCiWyR AqT+JCE8woePViT6QVlY= X-Google-Smtp-Source: APXvYqxrwxnyqwI/ey6IeD8cDvEFU4csIaihg4qy8brUmxMyY9mXR3pkfMqGkSy1MAQWXzoNqEfjgc3xryIb+qfKukI= X-Received: by 2002:a6b:b494:: with SMTP id d142mr1782181iof.156.1567630038027; Wed, 04 Sep 2019 13:47:18 -0700 (PDT) MIME-Version: 1.0 References: <156757720342.20663.3055037033818226992.idtracker@ietfa.amsl.com> In-Reply-To: <156757720342.20663.3055037033818226992.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Wed, 4 Sep 2019 14:46:26 -0600 Message-ID: To: Adam Roach Cc: The IESG , draft-ietf-oauth-resource-indicators@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000008e73660591c04f7a" Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) 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: Wed, 04 Sep 2019 20:47:22 -0000 --0000000000008e73660591c04f7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Adam, for the review and No Objection ballot. On Wed, Sep 4, 2019 at 12:07 AM Adam Roach via Datatracker wrote: > Adam Roach has entered the following ballot position for > draft-ietf-oauth-resource-indicators-05: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Many thanks to everyone who worked on this refinement to OAuth. > It seems like it will be a significant improvement over today's > ad-hoc system. > > I agree with Barry and Alexey about the need for some language discussing > the privacy implications of explicitly signaling audience resources to > OAuth servers. > Barry had other nits and was looking for some clarifying hyphenation. While it was Alexey, Mirja, Alissa and Eric who have expressed the desire to see some discussion of the privacy implications added. But I digress and the who doesn't much matter as the need for something seems to have been clearly established via comment by a few folks. I've been working on some text towards that end. Honestly, I'm not too thrilled with it - it amounts to saying that there's already not much privacy in OAuth and explicitly signaling resources might make the situation only marginally worse - not sure what else to say but I do plan to put some text along those lines discussing the privacy implications in for the next revision. =C2=A72: > > > The client SHOULD use the base URI of the API > > as the "resource" parameter value unless specific knowledge of the > > resource dictates otherwise. For example, the value > > "https://api.example.com/" would be used for a resource that is the > > exclusive application on that host, however, if the resource is one > > of many applications on that host, something like > > "https://api.example.com/app/" would be used as a more specific > > value. Another example, for an API like SCIM [RFC7644] that has > > multiple endpoints such as "https://apps.example.com/scim/Users", > > "https://apps.example.com/scim/Groups", and > > "https://apps.example.com/scim/Schemas" The client would use > > "https://apps.example.com/scim/" as the resource so that the issued > > access token is valid for all the endpoints of the SCIM API. > > This seems pretty intuitive in the examples given. It may be a little > less clear when applications are indicated by query parameter instead > of path prefixes. For example, if an endpoint is running two applications > distinguished thus: > > https://example.com/apps/?app=3Dapp1 > https://example.com/apps/?app=3Dapp2 > > ...and in a form that allows for additional parameters: > > https://example.com/apps/?darkmode=3Dtrue&version=3D1.2&app=3Dapp2 > > ...then the notion of the "most specific API" isn't quite as clear. > Intuitively, I think the idea would be that the resource for app2 > would be . It may be useful > to include an example along these lines as an illustration. > Yeah, with query parameters lacking the hierarchical semantics that the path component has, it is much less clear. In fact, an earlier revision of the draft forbid the query part as I was trying to avoid the ambiguity that it brings. But there were enough folks with some use case for it that it made its way back in. While I am sympathetic to the point you're making here, I'd prefer to not codify the practice any further by way of example in the document. =C2=A72.2: > > > &resource=3Dhttps%3A%2F%2Fcontacts.example.com%2Fapp%2F > ... > > "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi > > JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI > > iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwic2NvcGUiOiJjb250YWN0cyIs > > ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIn0.5f4yhqazc > > OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3nQXnBMw5wREY5O1YbZED-GfH > > UowfmtNaA5EikYAw", > > The "aud" value here is "https://contacts.example.com/" rather than the > "https://contacts.example.com/app/" that I would expect -- that is, I > would > expect them to match. Am I misunderstanding the intended relationship > between > "resouce" and "aud"? > The relationship doesn't necessarily have to be 1-1 (text about that at the very end of the main sec 2) but I think here I've just messed up the example a bit. Looking again at series of examples that kinda build on one another as well as the explanatory text leading up to figures 5 & 6, it seems that the value of the resource in the request in figure 5 probably should have also been just "https://contacts.example.com/" without the extraneous path part. And that would then match up to your expectations of the aud claim in figure 6. I'll change figure 5 accordingly to fix that. =C2=A73: > > > Some servers may host user content or be multi-tenant. In order to > > avoid attacks that might confuse a client into sending an access > > token to a resource that is user controlled or is owned by a > > different tenant, it is important to use a specific resource URI > > including a path component. > > Related to my comment about =C2=A72 above, "path component" isn't quite > sufficient. > What you want is "including any portion of the URI that identifies the > resource, such as a path component." > Fair point. Will change. --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000008e73660591c04f7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Adam, for the review and No Objection ballot.= =C2=A0

On Wed, Sep 4, 2019 at 12:07 AM Adam Roach via Datatracker <noreply@ietf.org> wr= ote:
Adam Roach = has entered the following ballot position for
draft-ietf-oauth-resource-indicators-05: No Objection

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Many thanks to everyone who worked on this refinement to OAuth.
It seems like it will be a significant improvement over today's
ad-hoc system.

I agree with Barry and Alexey about the need for some language discussing the privacy implications of explicitly signaling audience resources to
OAuth servers.

Barry had other nits and= was looking for some clarifying hyphenation. While it was Alexey, Mirja, A= lissa and Eric who have expressed the desire to see some discussion of the = privacy implications added. But I digress and the who doesn't much matt= er as the need for something seems to have been clearly established via com= ment by a few folks. I've been working on some text towards that end. H= onestly, I'm not too thrilled with it - it amounts to saying that there= 's already not much privacy in OAuth and explicitly signaling resources= might make the situation only marginally worse - not sure what else to say= but I do plan to put some text along those lines discussing the privacy im= plications in for the next revision.


=C2=A72:

>=C2=A0 The client SHOULD use the base URI of the API
>=C2=A0 as the "resource" parameter value unless specific know= ledge of the
>=C2=A0 resource dictates otherwise.=C2=A0 For example, the value
>=C2=A0 "https://api.example.com/" would be used for a reso= urce that is the
>=C2=A0 exclusive application on that host, however, if the resource is = one
>=C2=A0 of many applications on that host, something like
>=C2=A0 "https://api.example.com/app/" would be used as= a more specific
>=C2=A0 value.=C2=A0 Another example, for an API like SCIM [RFC7644] tha= t has
>=C2=A0 multiple endpoints such as "https://apps.example.= com/scim/Users",
>=C2=A0 "https://apps.example.com/scim/Groups",= and
>=C2=A0 "https://apps.example.com/scim/Schemas"= ; The client would use
>=C2=A0 "https://apps.example.com/scim/" as the resou= rce so that the issued
>=C2=A0 access token is valid for all the endpoints of the SCIM API.

This seems pretty intuitive in the examples given. It may be a little
less clear when applications are indicated by query parameter instead
of path prefixes. For example, if an endpoint is running two applications distinguished thus:

https://example.com/apps/?app=3Dapp1
https://example.com/apps/?app=3Dapp2

...and in a form that allows for additional parameters:

https://example.com/apps/?= darkmode=3Dtrue&version=3D1.2&app=3Dapp2

...then the notion of the "most specific API" isn't quite as = clear.
Intuitively, I think the idea would be that the resource for app2
would be <https://example.com/apps/?app=3Dapp2>. It ma= y be useful
to include an example along these lines as an illustration.

Yeah, with query parameters lacking the hierarchical s= emantics that the path component has, it is much less clear. In fact, an ea= rlier revision of the draft forbid the query part as I was trying to avoid = the ambiguity that it brings. But there were enough folks with some use cas= e for it that it made its way back in. While I am sympathetic to the point = you're making here, I'd prefer to not codify the practice any furth= er by way of example in the document.



=C2=A72.2:

>=C2=A0 =C2=A0 &resource=3Dhttps%3A%2F%2Fcontacts.example.com%2Fapp%2F
...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "access_token":"eyJhbGciOiJF= UzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXI= uZXhhbXBsZS5jb20iLCJzdWI
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwi= c2NvcGUiOiJjb250YWN0cyIs
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhb= XBsZS5jb20vIn0.5f4yhqazc
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3= nQXnBMw5wREY5O1YbZED-GfH
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0UowfmtNaA5EikYAw",

The "aud" value here is "https://contacts.example.com/" rather than the
"https://contacts.example.com/app/" that I would expe= ct -- that is, I would
expect them to match. Am I misunderstanding the intended relationship betwe= en
"resouce" and "aud"?

The relationship doesn't necessarily have to be 1-1 (text about that = at the very end of the main sec 2) but I think here I've just messed up= the example a bit. Looking again at series of examples that kinda build on= one another as well as the explanatory text leading up to figures 5 & = 6, it seems that the value of the resource in the request in figure 5 proba= bly should have also been just "https://contacts.example.com/&= quot; without the extraneous path part. And that would then match up to you= r expectations of the aud claim in figure 6. I'll change figure 5 accor= dingly to fix that.


=C2=A73:

>=C2=A0 Some servers may host user content or be multi-tenant.=C2=A0 In = order to
>=C2=A0 avoid attacks that might confuse a client into sending an access=
>=C2=A0 token to a resource that is user controlled or is owned by a
>=C2=A0 different tenant, it is important to use a specific resource URI=
>=C2=A0 including a path component.

Related to my comment about =C2=A72 above, "path component" isn&#= 39;t quite sufficient.
What you want is "including any portion of the URI that identifies the=
resource, such as a path component."

Fair point. Will change.
=C2=A0

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000008e73660591c04f7a-- From nobody Wed Sep 4 13:54:07 2019 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 24471120A9B; Wed, 4 Sep 2019 13:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 7hjkFp048fe1; Wed, 4 Sep 2019 13:54:04 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 F17FE120E09; Wed, 4 Sep 2019 13:54:03 -0700 (PDT) Received: by mail-io1-f50.google.com with SMTP id n197so45567220iod.9; Wed, 04 Sep 2019 13:54:03 -0700 (PDT) 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:content-transfer-encoding; bh=3S0q7N2+oy8iv3p98Fw+LPRtDCs5I3aQV0YgYFqnjVc=; b=lONsiqKnAYlAIWkF58Ig+DgXsbzmr1HgL7eF8tcwdyewwBTkj1ZZVN1mSpKFmtrQcM duhwdVZWcdk9N6YuiZjsM3OEYrq+sCJ49WRl/b5lvTWoyQhMjuRGZvHytn4ynCXELSv1 dy3zC/pBlt2qN04krqJck0alTfEPAfk6KgB/HB3AaEwSMemfLccES+7Mvya5eEuJkSrz cPjC3+k9BG7473YDQ5rgaFQmTido46XzshHmZaetyckxHwU4BeKF7D3a/Uawk5LULL29 B+W+BJLC5Ju8/gOe3JehzEym38ljBss7ZZFYvX9tIqVvR6TOQNbG6i9SB7k8t5vxZdKH uNJg== X-Gm-Message-State: APjAAAUQdbWzbHGgr3XJVRTDq08PInhEyMUtqtLIF+1E8eEKeR6GpZ+r wHYU4g5W9gaetaOr9PZRhYXRTN1p6nD8QLQf7zc= X-Google-Smtp-Source: APXvYqxfsY5BWncZ1EWhpxK6UCC6Cm6FMeV8PBXFuBq/YKeJAKMXpbN9k26X6yhLadfqlK+swNCo1j6sf27xK/cQWeM= X-Received: by 2002:a5d:9b96:: with SMTP id r22mr4928948iom.17.1567630443048; Wed, 04 Sep 2019 13:54:03 -0700 (PDT) MIME-Version: 1.0 References: <156757720342.20663.3055037033818226992.idtracker@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Wed, 4 Sep 2019 16:53:52 -0400 Message-ID: To: Brian Campbell Cc: Adam Roach , draft-ietf-oauth-resource-indicators@ietf.org, oauth-chairs@ietf.org, The IESG , oauth Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) 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: Wed, 04 Sep 2019 20:54:05 -0000 > Yeah, with query parameters lacking the hierarchical semantics that the p= ath component has, it is much less clear. In fact, an earlier revision of t= he draft forbid the query part as I was trying to avoid the ambiguity that = it brings. But there were enough folks with some use case for it that it ma= de its way back in. While I am sympathetic to the point you're making here,= I'd prefer to not codify the practice any further by way of example in the= document. Is it perhaps reasonable to discourage the use of a query component while still allowing it? Maybe a "SHOULD NOT", such as this?: OLD Its value MUST be an absolute URI, as specified by Section 4.3 of [RFC3986], which MAY include a query component but MUST NOT include a fragment component. NEW Its value MUST be an absolute URI, as specified by Section 4.3 of [RFC3986]. The URI MUST NOT include a fragment component. It SHOULD NOT include a query component, but it is recognized that there are cases that make a query component useful. END What do you think? Barry From nobody Wed Sep 4 14:02:46 2019 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 C6FEF120E11 for ; Wed, 4 Sep 2019 14:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 arx3SSwdeTR8 for ; Wed, 4 Sep 2019 14:02:30 -0700 (PDT) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 36718120DAD for ; Wed, 4 Sep 2019 14:02:29 -0700 (PDT) Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x84L2RdY017340; Wed, 4 Sep 2019 17:02:43 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 4 Sep 2019 17:02:20 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 4 Sep 2019 17:02:11 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Wed, 4 Sep 2019 17:02:11 -0400 From: Justin Richer To: Phil Idm Hunt CC: Torsten Lodderstedt , "Schaar, R.M. (Remco) - Logius" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 Thread-Index: AdVMX0zd8VJvxu//SVaPc8ibBp8OiQItX6sAAbumHoAAZ8QBgACsTdKAALQDLwAAFeebAAAAs2kAAAHaAYA= Date: Wed, 4 Sep 2019 21:02:11 +0000 Message-ID: References: <38503cd44d9e455bad4432d9ba5e82e8@SV1601507.frd.shsdir.nl> <308A4847-6390-4D17-BE52-B604E2428391@lodderstedt.net> <10f13f75c100454aa8092961673541b2@SV1601499.frd.shsdir.nl> <040dcf9971fd4c618e94b957461d14f2@SV1601507.frd.shsdir.nl> <9468283E-8B97-4DAF-8493-895B475F6BC9@lodderstedt.net> <9F5DA44D-BD3C-43B2-A88C-66394BD7BE85@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_BD763C91B8224985B95497B81FFD14E5mitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 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: Wed, 04 Sep 2019 21:02:45 -0000 --_000_BD763C91B8224985B95497B81FFD14E5mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG8gYmUgY2xlYXIsIEkgYW0gaW4gbm8gd2F5IHN1Z2dlc3Rpbmcgd2Ugc2hvdWxkIGxldmVyYWdl IFNFVCBmb3IgdGhpcyBkcmFmdC4gVGhhdCB3b3VsZCBiZSBhIHRlcnJpYmxlIGlkZWEuIEkgYW0g c2F5aW5nIHRoYXQgdGhlIHNvbHV0aW9uIG1pZ2h0IGJlIGEgc2ltaWxhciBwYXR0ZXJuIHRoYXQg U0VUIHVzZWQgZm9yIGdyb3VwaW5nIHRoZSBjbGFpbXMgdW5kZXIgYSB0b3AgbGV2ZWwgY2xhaW0u IEl04oCZcyBhIHBhdHRlcm4gSSB3aXNoIG1vcmUgYXBwbGljYXRpb25zIG9mIEpXVCB3b3VsZCB1 c2UsIGJ1dCBKV1Qgc3VmZmVycyBmcm9tIGhhdmluZyBiZWVuIGludmVudGVkIGZvciBhIHZlcnkg c3BlY2lmaWMgcHVycG9zZSBhbmQgdGhlbiBiZWluZyBtYWRlIGdlbmVyaWMuIEhvcGVmdWxseSB3 ZSBjYW4gbGVhcm4gZnJvbSBzb21lIG9mIHRoZSBtaXN0YWtlcyBpbiBTRVQgYXMgd2VsbCwgYW5k IG5vdCBqdXN0IGRlZmluZSBhIHRvcC1sZXZlbCBjbGFpbSBhbmQgc3RheSBvdXQgb2YgaXQuDQoN CuKAlCBKdXN0aW4NCg0KT24gU2VwIDQsIDIwMTksIGF0IDQ6MDkgUE0sIFBoaWwgSWRtIEh1bnQg PFBISUwuSFVOVEBPUkFDTEUuQ09NPG1haWx0bzpQSElMLkhVTlRAT1JBQ0xFLkNPTT4+IHdyb3Rl Og0KDQorMQ0KDQpUaGlzIGZlZWxzIGxpa2UgaXQgaGFzIHNpbWlsYXIgcmVxdWlyZW1lbnRzIGFu ZCBjb25jZXJucyBhcyBmb3IgU0VUIGFuZCBtYXkgYmUgc2hvdWxkIGxldmVyYWdlIGl0IHRvIGF2 b2lkIGNvbmZ1c2lvbiBhbmQgaW5jb25zaXN0ZW5jaWVzIGRvd24gdGhlIHJvYWQuDQoNClBoaWwN Cg0KT24gU2VwIDQsIDIwMTksIGF0IDEyOjQ5IFBNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1p dC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KDQpBcyBJ4oCZdmUgc2FpZCBp biB0aGUgcGFzdCwgSSB0aGluayB0aGVyZSBpcyBhbmQgc2hvdWxkIGJlIGEgY2xlYXIgZGlmZmVy ZW5jZSBiZXR3ZWVuIGEgSldUIGFjY2VzcyB0b2tlbiBhbmQgYSBKV1QtZm9ybWF0dGVkIHJlc3Bv bnNlIGZyb20gYW55IGVuZHBvaW50LiBJdCBnZXRzIGV4dHJhIGZ1enp5IGhlcmUgYmVjYXVzZSB0 aGUgcmVzcG9uc2UgZnJvbSB0aGUgZW5kcG9pbnQgcmVwcmVzZW50cyB0aGUgdG9rZW4gYmVpbmcg aW50cm9zcGVjdGVkLg0KDQpIb3dldmVyLCBJIHRoaW5rIHRoZXkgYXJlIHN0aWxsIHR3byB2ZXJ5 IGRpZmZlcmVudCB0aGluZ3MgYmVjYXVzZSB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZSBieSBk ZWZpbml0aW9uIHJlcHJlc2VudHMgd2hhdCB0aGUgdG9rZW4gd2FzIGF0IHRoZSB0aW1lIG9mIGlu dHJvc3BlY3Rpb24uIFRoYXTigJlzIHdoeSB0aGUg4oCcYWN0aXZl4oCdIGNsYWltIGlzIGltcG9y dGFudCBoZXJlLCBhbG9uZyB3aXRoIHRoZSB0aW1lc3RhbXAgaW5mb3JtYXRpb24gaW4gdGhlIEpX VCBjb250YWluZXIg4oCUIHlvdSBjYW4gc2F5IHRoYXQgdGhlIHRva2VuICp3YXMqIGFjdGl2ZSBh dCB0aGUgdGltZSBvZiBpbnRyb3NwZWN0aW9uLCBidXQgeW91IGNhbuKAmXQgc2F5IGl04oCZcyBz dGlsbCBhY3RpdmUgd2l0aG91dCBpbnRyb3NwZWN0aW5nIHRoZSB0b2tlbiBhZ2FpbiB0byBjaGVj ay4gVGhpcyBsZWFkcyB0byBleGFjdGx5IHRoZSBraW5kIG9mIGNvbGxpc2lvbiB0aGF04oCZcyBi ZWluZyBkaXNjdXNzZWQgaGVyZS4gSXTigJlzIGNvbmZ1c2luZyBmb3IgZGV2ZWxvcGVycyBvZiBi b3RoIHRoZSBBUyBhbmQgdGhlIFJTLCBhbmQgSSBmZWFyIGl04oCZcyBnb2luZyB0byBsZWFkIHRv IGFuIEFTIGNob29zaW5nIG9uZSBpbnRlcnByZXRhdGlvbiBhbmQgYW4gUlMgY2hvb3NpbmcgYW5v dGhlciwgYW5kIHRoZXJlZm9yZSBsZWF2aW5nIG9wZW4gYSBkb29yIHRvIHNlY3VyaXR5IGlzc3Vl cyBkb3duIHRoZSByb2FkLg0KDQpBbHNvLCByZW1lbWJlciBvbmUgb2YgdGhlIG1haW4gcmVhc29u cyB0aGF0IHdlIHJlcXVpcmUgc29tZSBmb3JtIG9mIFJTIGF1dGhlbnRpY2F0aW9uIHRvIHRoZSB0 b2tlbiBlbmRwb2ludCBpcyB0aGF0IGRpZmZlcmVudCBSU+KAmXMgY2FuIGdldCBkaWZmZXJlbnQg YW5zd2VycyBmb3IgdGhlIHNhbWUgdG9rZW4uIFRoZSBBUyBjYW4gdGFpbG9yIGl0cyByZXNwb25z ZSBiYXNlZCBvbiB3aGF0IHNjb3BlcyB0aGUgUlMgaXMgc3VwcG9zZWQgdG8ga25vdyBhYm91dCwg b3Igd2hpY2ggUlPigJlzIGNhbiBrbm93IGEgdXNlcuKAmXMgaWRlbnRpZmllciAob3IgZXZlbiB1 c2UgcGFpcndpc2UgaWRlbnRpZmllcnMpLCBvciBldmVuIHdoaWNoIFJTIGlzIHN1cHBvc2VkIHRv IGtub3cgYWJvdXQgYSBnaXZlbiB0b2tlbiBhdCBhbGwuIEluIGVhY2ggb2YgdGhlc2UgY2FzZXMs IHVzaW5nIHRoaXMgZHJhZnQsIHlvdeKAmWxsIGdldCBhIGRpZmZlcmVudCBKV1Qgb3V0IGZvciB0 aGUgc2FtZSB0b2tlbiBvbiB0aGUgd2F5IGluLiBZb3XigJlyZSBub3Qgc2ltcGx5IHRyYW5zbGF0 aW5nIGFuIGFjY2VzcyB0b2tlbiB0byBhbm90aGVyIGFjY2VzcyB0b2tlbiBoZXJlIOKAlCBpZiB5 b3Ugd2FudCB0byBkbyB0aGF0LCB1c2UgdG9rZW4gZXhjaGFuZ2UgYW5kIGRvIGl0IHByb3Blcmx5 IHdpdGggYW4gT0F1dGggZ3JhbnQuIEluc3RlYWQsIHlvdeKAmXJlIGdldHRpbmcgaW5mb3JtYXRp b24gYWJvdXQgdGhlIHRva2VuIGl0c2VsZiBhdCB0aGUgdGltZSBvZiB0aGUgcmVxdWVzdCBhbmQg ZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIHJlcXVlc3RvciwgYW5kIHlvdSBoYXBwZW4gdG8g YmUgd3JhcHBpbmcgdGhlIHJlc3BvbnNlIGluIGEgY29udGFpbmVyIHRoYXQgaXMgYWxzbyB3aWRl bHkgdXNlZCB0byBmb3JtYXQgYWNjZXNzIHRva2Vucy4NCg0KVGhlIHNlcGFyYXRpb24gdGhhdCBU b3JzdGVuIHBvaW50cyBvdXQgYmVsb3cgYnJpbmdzIHVwIG9uZSBvZiB0aGUgYmlnZ2VzdCBwcm9i bGVtcyB3aXRoIEpXVHMgYXMgYSBkYXRhIGNvbnRhaW5lciBmb3JtYXQg4oCUIGFsbCB0aGUgaW5m b3JtYXRpb24gYWJvdXQgdGhlIEpXVCBpdHNlbGYgaXMgbWl4ZWQgaW4gd2l0aCB0aGUgdGhpbmcg aXTigJlzIGNhcnJ5aW5nIGluZm9ybWF0aW9uIGFib3V0LiBXZSBzZWUgdGhpcyBpc3N1ZSB3aXRo IEpBUiwgd2hlcmUgdGhlIOKAnGF1ZOKAnSBwYXJhbWV0ZXIgY2FuIG1lYW4gdGhlIGF1ZGllbmNl IG9mIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgYW5kIHRoZSBhdWRpZW5jZSBvZiB0aGUgSldU IHVzZWQgdG8gY2FycnkgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdC4gV2UgYWxzbyBzZWUgdGhp cyBhIGxpdHRsZSBiaXQgaW4gZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9u4oCZcyBzb2Z0d2Fy ZSBzdGF0ZW1lbnQuIFJvb3QtbGV2ZWwgSldUIGNsYWltcyBhcmUgYSBwb29yIG1lY2hhbmlzbSBm b3IgdGhpcy4NCg0KSW4gcmV0cm9zcGVjdCwgd2hhdCBJIHdpc2ggd2XigJlkIGRvbmUgd2l0aCBh bGwgb2YgdGhlbSB1c2luZyBhIG5hbWVkIHBheWxvYWQgbGlrZSB3aXRoIFNFVOKAmXMg4oCcZXZl bnTigJ0gY2xhaW0uIEV2ZW4gdGhlcmUsIHdlIGhhZCBhIGxvdCBvZiBhcmd1bWVudCBhYm91dCBh IOKAnHN1YuKAnSBjbGFpbSBpbnNpZGUgdGhlIOKAnGV2ZW504oCdIG9iamVjdCB2cy4gb25lIGF0 IHRoZSByb290IG9mIHRoZSBKV1QgY29udGFpbmVyLCBidXQgYXQgbGVhc3QgaW4gdGhlc2UgY2Fz ZXMgIHdlIG5vdyBoYWQgYW4gb3Bwb3J0dW5pdHkgdG8gd3JpdGUgY2xlYXIgbGFuZ3VhZ2UgYWJv dXQgd2hhdCBlYWNoIG1lYW50IGluIGVhY2ggY2lyY3Vtc3RhbmNlLiBJIHJlYWxpemUgdGhpcyBk cmFmdCBpcyBhbHJlYWR5IHdlbGwgYWxvbmcgaW4gaXRzIHByb2Nlc3MsIGFuZCBJIGhhdmVu4oCZ dCBwdXQgaW4gdGhlIHJldmlldyB0aW1lIG9yIGNvbW1lbnRzIHRvIGRhdGUgbXlzZWxmLCBidXQg SSB0aGluayBpdOKAmXMgdW5mb3J0dW5hdGUgdGhhdCB0aGUgZHJhZnQgZG9lc27igJl0IGRlZmlu ZSBhIHN1Yi1jbGFpbSBsaWtlIOKAnGFjY2Vzc190b2tlbuKAnSBvciDigJx0b2tlbl9pbmZvcm1h dGlvbuKAnSB0byBjYXJyeSBpbnNpZGUgdGhlIEpXVCBwYXlsb2FkLiBUaGlzIHdvdWxkIHNvbHZl IHRoZSBwcm9ibGVtIG9mIGRpZmZlcmVudGlhdGluZyB0aGUg4oCcaWF04oCdIGZvciB0aGUgdG9r ZW4gaXRzZWxmIHZzLiB0aGUgSldUIGNvbnRhaW5lciBvZiB0aGUgcmVzcG9uc2UuDQoNClRoZSBn cm91cCBtYXkgYWxzbyByZWNhbGwgdGhhdCBJIG9yaWdpbmFsbHkgc2FpZCB0aGF0IHRoaXMgZHJh ZnQgc2hvdWxkIG5vdCBiZSBkb25lIGluIGxpZ2h0IG9mIG9ubHkgaW50cm9zcGVjdGlvbiwgYW5k IGluc3RlYWQgc2hvdWxkIGJlIGEgZ2VuZXJpYyBtZWNoYW5pc20gYWNyb3NzIE9BdXRo4oCZcyB2 YXJpb3VzIGVuZHBvaW50cy4gV2VpcmQgY29tYmluYXRpb25zIGxpa2UgdGhlIOKAnGlhdOKAnSBj bGFpbSBoZXJlIGFyZSBhIGRyaXZlciBmb3IgaGF2aW5nIGEgc29saWQgZ2VuZXJpYyBtZWNoYW5p c20gaW5zdGVhZCBvZiBhIGhhbmRmdWwgb2Ygc2xpZ2h0bHkgZGlmZmVyZW50IGRlZmluaXRpb25z Lg0KDQpTbyB3aGF0IHNob3VsZCB3ZSBkbyBoZXJlPyBJZiB3ZSBhcmUgdG8ga2VlcCB0aGUgY3Vy cmVudCBwcmFjdGljZSBvZiBwdXR0aW5nIGV2ZXJ5dGhpbmcgaW4gdGhlIHJvb3Qgb2YgdGhlIEpX VCwgd2Ugc2hvdWxkIGhhdmUgZGlmZmVyZW50IGNsYWltIG5hbWVzIHRvIGRpZmZlcmVudGlhdGUg dGhlIGVudmVsb3BlIGFuZCB0aGUgdG9rZW4uIFRoZSBwcm9ibGVtIGhlcmUgaXMgdGhhdCDigJxp YXTigJ0gaXMgYWxyZWFkeSBkZWZpbmVkIGluIFJGQzc2NjIgYXMgcmVmZXJyaW5nIHRvIHRoZSB0 b2tlbiBhbmQgaW4gUkZDNzUxOSBhcyByZWZlcnJpbmcgdG8gdGhlIEpXVCAod2hpY2ggaXMgbm90 IGEgdG9rZW4sIGJ1dCB0aGUgY29udGFpbmVyIGZvciB0aGUgdG9rZW4gaW5mb3JtYXRpb24pLiBJ 4oCZbSBub3Qgc3VyZSB3aGljaCBpcyB3b3JzZSwgZGVmaW5pbmcgYW4g4oCcaWF04oCdIGZvciB0 aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZSBvciBvbmUgZm9yIHRoZSBKV1QgYnV0IG9ubHkgaW4g dGhpcyBpbnN0YW5jZS4gQm90aCBmZWVsIHJlYWxseSBtZXNzeSwgYW5kIGluIGNhc2VzIGxpa2Ug VG9yc3RlbuKAmXMgdGhleSBjb2xsYXBzZSB0byB0aGUgc2FtZSB2YWx1ZS4NCg0KSWYgaG93ZXZl ciB3ZSBwdXQgdGhlIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgaW4gaXRzIG93biBzdWItc2VjdGlv biBvZiB0aGUgSldUIHBheWxvYWQsIHRoZW4gd2UgY291bGQgYXZvaWQgdGhlIG5hbWVzcGFjZSBj b2xsaXNpb24gZW50aXJlbHkuIFdlIHdvdWxkIG5lZWQgbm9ybWF0aXZlIHJ1bGVzIGxpa2UgaW4g U0VUIHRvIGRlZmluZSBob3cgdGhlc2UgZmllbGRzIHJlbGF0ZSB0byBlYWNoIG90aGVyLCBidXQg SSBzZWUgdGhhdCBhcyBhIHRyYWN0YWJsZSBwcm9ibGVtIHdpdGggYSByZWFzb25hYmxlIChpZiBp bXBlcmZlY3QpIHByZWNlZGVudC4NCg0KRWl0aGVyIHBhdGggbWVhbnMgcmVkb2luZyBXR0xDIGFu ZCB0aGUgYXNzb2NpYXRlZCByZXZpZXdzLCBJ4oCZbSBhZnJhaWQuIExlYXZpbmcgaXQgYXMtaXMg d29ya3MgZm9yIHRoZSBkcml2aW5nIHVzZSBjYXNlIHdoZXJlIHRoZSBpbmZvcm1hdGlvbiBpcyBh bGwgdGhlIHNhbWUsIGJ1dCBJIGRvbuKAmXQgZmluZCBpdCB0byBiZSBhIHBhcnRpY3VsYXJseSBj bGVhbiByZXByZXNlbnRhdGlvbiBvZiB0aGUgaW5mb3JtYXRpb24gaW4gcXVlc3Rpb24uDQoNCuKA lCBKdXN0aW4NCg0KT24gU2VwIDQsIDIwMTksIGF0IDU6MjEgQU0sIFRvcnN0ZW4gTG9kZGVyc3Rl ZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5l dD4+IHdyb3RlOg0KDQpIaSBSZW1jbywNCg0KT24gMzEuIEF1ZyAyMDE5LCBhdCAyMToyNywgU2No YWFyLCBSLk0uIChSZW1jbykgLSBMb2dpdXMgPHJlbWNvLnNjaGFhckBsb2dpdXMubmw8bWFpbHRv OnJlbWNvLnNjaGFhckBsb2dpdXMubmw+PiB3cm90ZToNCg0KSGVsbG8gVG9yc3RlbiwNCg0KKG15 IGFwb2xvZ2llcyBmb3IgbWFraW5nIGEgdHlwbyBwcmV2aW91c2x5KQ0KDQpUaGFua3MgOi0pDQoN Cg0KVGltZSBvZiBpbnRyb3NwZWN0aW9uIGlzIGNyaXRpY2FsIGlmIHlvdSB3YW50IHRvIHVzZSB0 aGUgc2lnbmVkIGludHJvc3BlY3Rpb24NCnJlc3BvbnNlIGZvciBsYXRlciBhY2NvdW50YWJpbGl0 eSBvciBhdWRpdCBwdXJwb3Nlcy4gRm9yIGV4YW1wbGUsIGEgQ2xpZW50DQpvYnRhaW5zIGFuIGFj Y2VzcyB0b2tlbiBBIGF0IHRpbWUgdC4gTm93IGEgcmVzb3VyY2Ugc2VydmVyIHJlY2VpdmVzIEEg YXQgdGltZQ0KdCsxLCBjYWxscyBpbnRyb3NwZWN0aW9uIGFuZCByZWNlaXZlcyBhIHJlc3BvbnNl IGNvbnRhaW5pbmcgYWN0aXZlPXRydWUuIEF0DQp0KzIgdGhlIGFjY2Nlc3MgdG9rZW4gaXMgcmV2 b2tlZC4gQXQgdGltZSB0KzMgdGhlIHJlc291cmNlIHNlcnZlciBtYWtlcyBhIG5ldw0KaW50cm9z cGVjdGlvbiByZXF1ZXN0LCBub3cgcmVjZWl2ZXMgYSByZXNwb25zZSBjb250YWluaW5nIGFjdGl2 ZT1mYWxzZS4gVGhlDQpvbmx5IGRpZmZlcmVuY2Ugd291bGQgYmUgdGhlIHZhbHVlIG9mIHRoZSBh Y3RpdmUgcGFyYW1ldGVyLiBXaXRob3V0IHRoZSB0aW1lDQpvZiBpbnRyb3NwZWN0aW9uIG5vciBh IHVuaXF1ZSBpZCBjb3ZlcmVkIGJ5IHRoZSBzaWduYXR1cmUsIG9uZSBjYW5ub3QgbWFrZSBhDQpj b25jbHVzaXZlIGRpc3RpbmN0aW9uIGJldHdlZW4gc3Vic2VxdWVudCByZXNwb25zZXMgaWYgcmV2 b2NhdGlvbiBtYXkgYmUgaW4NCnBsYXkuDQoNClRoYXTigJlzIGEgZ29vZCBwb2ludC4NCg0KDQpU aGUgZHJhZnQgc3BlY2lmaWVzDQogICAgIFsuLi5dIHRvIHJldHVybiByZXNwb25zZXMgYXMgSldU cy4NClRoaXMgY291bGQgZWl0aGVyIG1lYW4gInRoZSByZXNwb25zZSBpcyByZXR1cm5lZCBpbiBK V1QgZm9ybWF0IiBvciAidGhlDQpyZXNwb25zZSBjb250YWlucyBhIEpXVCByZXByZXNlbnRhdGlv biBvZiB0aGUgaW5zcGVjdGVkIHRva2Vu4oCdLg0KDQpJJ20gbWVhbndoaWxlIGxlYW5pbmcgdG93 YXJkcyAidGhlIHJlc3BvbnNlIGlzIHJldHVybmVkIGluIEpXVCBmb3JtYXTigJ0uDQoNCk5vdCBo YXZpbmcNCmNsZWFyLCBzZXBhcmF0ZSBwYXJhbWV0ZXJzIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4g dGhlIHRpbWUgYW5kIGlkIG9mIHRoZQ0KdG9rZW4gYW5kIHRoZSB0aW1lIGFuZCBpZCBvZiB0aGUg cmVzcG9uc2UgcmVzdWx0cyBpbiBkb3VibGUgbWVhbmluZy4gQXMgYQ0KY29uc2VxdWVuY2UsIGl0 IGlzIGVpdGhlciBoYXZpbmcgdGhlIHJpc2sgb2YgcmVwbGF5IG9mIGFuIGFjY2VzcyB0b2tlbiBv cg0KcmVwbGF5IG9mIGFuIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgaW5zdGVhZCBvZiBuZWl0aGVy Lg0KDQpJ4oCZbSBub3Qgc3VyZSBob3cgYW4gYXR0YWNrZXIgY291bGQgcmVwbGF5IGFuIGludHJv c3BlY3Rpb24gcmVzcG9uc2UgZ2l2ZW4gaXQgaXMgdGlnaHRlZCB0byBhIGNlcnRhaW4gZW5kcG9p bnQgdmlhIHRoZSBpc3MgY2xhaW0uDQoNCkkgYWdyZWUgdGhlIFJTIGxhY2tzIGEgd2F5IHRvIHBy b29mIHdoZW4gaXQgd2FzIHByb3ZpZGVkIHdpdGggdGhlIGFjY2VzcyB0b2tlbiBkYXRhIGJ5IHRo ZSBBUy4NCg0KVGhlIHByb2JsZW0gaW4gbXkgb3BpbmlvbiBpcyB0aGUgb3ZlcmxheSBiZXR3ZWVu IHRoZSBvcmlnaW5hbCBhY2Nlc3MgdG9rZW4gZGF0YSAoZS5nLiB3aGVuIHdhcyBpdCBpc3N1ZWQg YnkgdGhlIEFTKSBhbmQgdGhlIGRhdGEgYmVsb25naW5nIHRvIHRoZSByZXByZXNlbnRhdGlvbiBp biB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZSAod2hlbiB3YXMgdGhlIHJlc3BvbnNlIGNyZWF0 ZWQpLiBDb25jZXB0dWFsbHksIHRoaXMgbWVhbnMgd2UgcmVxdWlyZSB0d28gc2VwYXJhdCDigJxp YXQiIChhbGlrZSkgY2xhaW1zIHRvIGRpc3Rpbmd1aXNoIGJvdGggYXNwZWN0cy4NCg0KSSBjb3Vs ZCBpbWFnZSB0d28gd2F5cyB0byBoYW5kbGUgdGhpczoNCi0gYWRkIGFub3RoZXIgaWF0IGNsYWlt LCBlLmcuIOKAnHRpcl9pYXQiLCB0byB0aGUgSldUDQotIGFkZCBhbm90aGVyIOKAnGlhdCIgY2xh aW0gdG8gdGhlIEpXUyBoZWFkZXIgY29udGFpbmluZyB0aGUgaW5zdGFudCB3aGVuIHRoZSB0b2tl biBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlIHdhcyBjcmVhdGVkDQoNCldoYXQgZG8geW91IHRoaW5r Pw0KDQpiZXN0IHJlZ2FyZHMsDQpUb3JzdGVuLg0KDQoNCktpbmQgcmVnYXJkcywNClJlbWNvIHNj aGFhcg0KDQotLS0tLU9vcnNwcm9ua2VsaWprIGJlcmljaHQtLS0tLQ0KVmFuOiBUb3JzdGVuIExv ZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJz dGVkdC5uZXQ+Pg0KVmVyem9uZGVuOiB3b2Vuc2RhZyAyOCBhdWd1c3R1cyAyMDE5IDExOjE0DQpB YW46IFNjaGFhciwgUi5NLiAoUmVtY28pIC0gTG9naXVzIDxyZW1jby5zY2hhYXJAbG9naXVzLm5s PG1haWx0bzpyZW1jby5zY2hhYXJAbG9naXVzLm5sPj4NCkNDOiBvYXV0aEBpZXRmLm9yZzxtYWls dG86b2F1dGhAaWV0Zi5vcmc+DQpPbmRlcndlcnA6IFJlOiBbT0FVVEgtV0ddIFF1ZXN0aW9uIHJl Z2FyZGluZyBkcmFmdC1pZXRmLW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNlLTA1DQoN CkhpIFJoZW1jbywNCg0KT24gMjYuIEF1ZyAyMDE5LCBhdCAwOTo0MiwgU2NoYWFyLCBSLk0uIChS ZW1jbykgLSBMb2dpdXMgPHJlbWNvLnNjaGFhckBsb2dpdXMubmw8bWFpbHRvOnJlbWNvLnNjaGFh ckBsb2dpdXMubmw+PiB3cm90ZToNCg0KSGVsbG8gVGhvcnN0ZW4sDQoNClRoYW5rIHlvdSBmb3Ig eW91ciByZXNwb25zZS4gSSBoYXZlIGEgZmV3IG1vcmUgcXVlc3Rpb25zL2NvbW1lbnRzIGFzDQpm b2xsb3ctdXAuLi4NCg0KWW91IHN0YXRlIHRoYXQgUkZDNzUxOSBhbmQgUkZDNzY2MiAianVzdCIg ZGVmaW5lIGRpZmZlcmVudCByZXByZXNlbnRhdGlvbnMNCmZvciB0b2tlbiBkYXRhLiBJZiB0aGUg ZHJhZnQgUkZDIHdvdWxkIHJlZmVyIHRvIFJGQyA3NTE1IChKV1MpLCBJIHdvdWxkDQphZ3JlZS4g SG93ZXZlciwgUkZDNzUxOSAoSldUKSBleHBsaWNpdGx5IGFkZHMgc2VtYW50aWNzIHRvIHNvbWUg c3BlY2lmaWMNCnBhcmFtZXRlcnMgKGUuZy4gYXVkLCBqdGkgYW5kIGlhdCkuIFJGQzc2NjIgaGFz IGRpZmZlcmVudCBzZW1hbnRpY3MgZm9yDQp0aGUgc2V2ZXJhbCBvZiB0aGUgc2FtZSBwYXJhbWV0 ZXJzLg0KRm9yIGluc3RhbmNlIHRoZSAnaWF0JywgaXMgdGhlIG1vbWVudCBvZiBpc3N1YW5jZSBv ZiB0aGUgSldUIGluIFJGQzc1MTkuIEluDQpSRkM3NjYyIHRoYXQgaXMgdGhlICJ3aGVuIHRoaXMg dG9rZW4gd2FzIG9yaWdpbmFsbHkgaXNzdWVkIi4gVGhpcyB0aW1lIHdpbGwNCnZhcnkgaW4gdXNl IGNhc2VzIHdpdGhvdXQgaW1tZWRpYXRlIGludHJvc3BlY3Rpb24gb2YgYW4gYWNjZXNzIHRva2Vu Lg0KDQpJIHJlYWQgdGhlIHRleHQgZGlmZmVyZW50bHkuIEluIG15IGludGVycHJldGF0aW9uIOKA nHdoZW4gdGhlIHRva2VuIHdhcyBvcmlnaW5hbGx5IGlzc3VlZOKAnSBzdGF0ZWQgZnJvbSB0aGUg cGVyc3BlY3RpdmUgb2YgdGhlIGludHJvc3BlY3Rpb24gZW5kcG9pbnQgcmVmZXJzIGV4YWN0bHkg dG8gdGhlIHNhbWUgaW5zdGFudCBhcyDigJx0aGUgdGltZSBhdCB3aGljaCB0aGUgSldUIHdhcw0K IGlzc3VlZOKAnS4NCg0KDQpGb3IgdGhlIHVzZSBjYXNlIG9mIHRoZSByZXNvdXJjZSBzZXJ2ZXIg cmVseWluZyBvbiB2ZXJpZmlhYmxlIGRhdGEsIGFzDQpkZXNjcmliZWQgaW4gdGhlIGludHJvZHVj dGlvbiBvZiB0aGUgZHJhZnQgUkZDLCB0aGUgdGltZSBvZiB0aGUgaW50cm9zcGVjdGlvbg0KaXMg Y3JpdGljYWwuDQoNCldoeSBpcyB0aGlzIHRpbWUgY3JpdGljYWw/DQoNCkluIHBhcnRpY3VsYXIg d2hlbiBjb21iaW5lZCB3aXRoIHJldm9jYXRpb24sIHRoZSB0aW1lIG9mDQppbnRyb3NwZWN0aW9u IGFuZCB0aGUgJ2FjdGl2ZScgc3RhdHVzIGNhbiBkaWZmZXIgYmV0d2VlbiB0d28gc3Vic2VxdWVu dCBjYWxscw0KZm9yIGludHJvc3BlY3Rpb24uDQoNClRoZSBzdGF0dXMgYXQgdG9rZW4gaW50cm9z cGVjdGlvbiByZXF1ZXN0IHRpbWUgaXMgaW5kZWVkIGNyaXRpY2FsLiBSRkMgNzY2MiBnaXZlcyBh IGdvb2QgaW5kaWNhdGlvbiBob3cgdGhpcyB2YWx1ZSBzaG91bGQgYmUgY2FsY3VsYXRlZC4NCg0K 4oCc4oCmIGEgInRydWUiDQogICAgdmFsdWUgcmV0dXJuIGZvciB0aGUgImFjdGl2ZSIgcHJvcGVy dHkgd2lsbCBnZW5lcmFsbHkgaW5kaWNhdGUNCiAgICB0aGF0IGEgZ2l2ZW4gdG9rZW4gaGFzIGJl ZW4gaXNzdWVkIGJ5IHRoaXMgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsDQogICAgaGFzIG5vdCBiZWVu IHJldm9rZWQgYnkgdGhlIHJlc291cmNlIG93bmVyLCBhbmQgaXMgd2l0aGluIGl0cw0KICAgIGdp dmVuIHRpbWUgd2luZG93IG9mIHZhbGlkaXR5IChlLmcuLCBhZnRlciBpdHMgaXNzdWFuY2UgdGlt ZSBhbmQNCiAgICBiZWZvcmUgaXRzIGV4cGlyYXRpb24gdGltZSkuIg0KDQpTbyBpdCByZXByZXNl bnRzIHRoZSByZXN1bHRzIG9mIHRoZSBpc3N1ZXIgY2hlY2ssIHRoZSByZXZvY2F0aW9uIGNoZWNr IGFuZCB0aGUgdmFsaWRpdHkgY2hlY2sgaW4gb25lIGJvb2xlYW4gdmFsdWUuDQoNCg0KSWYgdGhl IGRyYWZ0IFJGQyBqdXN0IHByb2R1Y2VzIGEgSldUIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBhY2Nl c3MgdG9rZW4sDQppbmNsdWRpbmcgJ2FjdGl2ZScgd291bGQgbm90IG1ha2Ugc2Vuc2UgYXMgdGhl IEpXVCB3aWxsIGV4cGlyZSB3aXRob3V0DQp1cGRhdGluZyBpdCB0byBmYWxzZS4gTGVhdmluZyAn YWN0aXZlJyBvdXQgd291bGQgbWFrZSBpdCBpbmNvbXBhdGlibGUgd2l0aA0KUkZDNzY2MiBpbnRy b3NwZWN0aW9uIHJlc3BvbnNlcy4NCg0K4oCcYWN0aXZl4oCdIGlzIG5vdCBwYXJ0IG9mIHRoZSBK V1QgcmVwcmVzZW50YXRpb24gSSByZWZlcnJlZCB0by4gVGhlIEFTIG5lZWRzIHRvIGRldGVybWlu ZSB0aGUgYWN0aXZlIHZhbHVlIGZvciBldmVyeSB0b2tlbiBpbnRyb3NwZWN0aW9uIHJlcXVlc3Qu DQoNCklmIHRoZSBSUyB3b3VsZCBjb25zdW1lIEpXVHMsIGl0IHdvdWxkIGRldGVybWluZSB0aGUg 4oCcYWN0aXZl4oCdIHZhbHVlIGl0c2VsZiBieSBpbnNwZWN0aW5nIHRoZSBpc3MgY2xhaW0gYW5k IGNoZWNrIGFnYWluc3QgaXRzIEFTIHdoaXRlbGlzdCwgY2hlY2sgdGhlIHNpZ25hdHVyZSBhbmQg dGhlIGlhdCAmIGV4cCB2YWx1ZXMuIERldGVybWluaW5nIHRoZSByZXZvY2F0aW9uIHN0YXR1cyB3 b3VsZCByZXF1aXJlIGFuIGluZm9ybWF0aW9uIGV4Y2hhbmdlIHdpdGggdGhlIEFTIG9mIHNvbWUg c29ydC4NCg0KU2ltaWxhciwgbm90IGluY2x1ZGluZyBhIHVuaXF1ZSAnanRpJyBwZXIgaW50cm9z cGVjdGlvbiByZXNwb25zZSB3b3VsZCBtYWtlDQp0aGUgcmVzb3VyY2Ugc2VydmVyIHZ1bG5lcmFi bGUgdG8gcmVwbGF5IGF0dGFja3MuDQoNClRvIHRoZSBjb250cmFyeSwgaW5jbHVkaW5nIGEgZGlm ZmVyZW50IOKAnGppdCIgd2l0aCBldmVyeSB0b2tlbiBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlIHdv dWxkIG1ha2UgdGhlIFJTIHZ1bG5lcmFibGUgdG8gcmVwbGF5IG9mIG9uZSB0aW1lIGFjY2VzcyB0 b2tlbiBzaW5jZSBpdCByZW1vdmUgdGhlIHBvc3NpYmlsaXR5IGZvciB0aGUgUlMgdG8gaWRlbnRp dHkgYSBjZXJ0YWluIGFjY2VzcyB0b2tlbi4NCg0KT3IgdGhlIHJlc291cmNlIHNlcnZlcg0Kd291 bGQgbWlzdGFrZW5seSByZWZlciB0byBub24tdW5pcXVlIHRva2VucywgbWFraW5nIHRoZSByZXNw b25zZXMgdW5zdWl0YWJsZQ0KZm9yIGFjY291bnRhYmlsaXR5IGFuZCBhdWRpdCBwdXJwb3Nlcy4N Cg0KDQpBcyB0byB3aHkgc29tZW9uZSB3b3VsZCB3YW50IHRvIGRpc3Rpbmd1aXNoIGEgSldUIGFj Y2VzcyB0b2tlbiBmcm9tIGFuDQppbnRyb3NwZWN0aW9uIHJlc3BvbnNlOiBzZXZlcmFsIHVzZSBj YXNlcyBjb21lIHRvIG1pbmQuDQoNCkZpcnN0IG9mIGFsbCwgZXZlbiBpZiBvbmUgaXMgdXNpbmcg c3RhbmRhbG9uZSBpbnRlcnByZXRhYmxlIEpXVCBhY2Nlc3MgdG9rZW5zLA0Kb25lIG1heSB3YW50 IHRvIGNvbWJpbmUgdGhhdCB3aXRoIHJldm9jYXRpb24gY2hlY2tpbmcgdXNpbmcgaW50cm9zcGVj dGlvbi4gVGhlDQppbnRlcnByZXRhdGlvbiBhbmQgbWVhbmluZyBvZiB0aGUgSldUIGFuZCB0aGUg aW50cm9zcGVjdGlvbiByZXNwb25zZSB0aGFuIGRvDQpkaWZmZXIgYW5kIG1hdHRlci4NCg0KQXMg SSBkZXNjcmliZWQgYWJvdmUsIEkgZG9u4oCZdCBzZWUgYW55IGRpZmZlcmVuY2UuDQoNCg0KQW5v dGhlciB1c2UgY2FzZSB3b3VsZCBiZSBhIG1peGVkIGVjb3N5c3RlbSB3aXRoIHJlc291cmNlIHNl cnZlcnMgcmVseWluZyBvbg0KaW50cm9zcGVjdGlvbiB3aGlsZSBvdGhlcnMgZG8gcGFyc2UgSldU IGFjY2VzcyB0b2tlbnMuIEEgc2luZ2xlLCB1bmlmb3JtDQppbXBsZW1lbnRhdGlvbiBmb3IgdGhl IEFTIHdvdWxkIHRoYW4gbWl4IGJvdGggYXMgd2VsbC4NCg0KU2VlIGFib3ZlIC0gSSBkb27igJl0 IHNlZSBhbnkgaXNzdWUuDQoNCg0KQSBsYXN0IHVzZSBjYXNlIGNvdWxkIGJlIGV4Y2hhbmdpbmcg YWNjZXNzIHRva2VucyB3aXRoIGEgc3Vic2V0IG9mIHRoZSBmdWxsDQpzZXQgb2YgYXBwbGljYWJs ZSBwYXJhbWV0ZXJzLCB0byByZWR1Y2UgdGhlIHNpemUgb2YgYWNjZXNzIHRva2Vucy4gQWRkaXRp b25hbA0KaW5mb3JtYXRpb24gY2FuIGJlIGV4Y2hhbmdlZCB2aWEgaW50cm9zcGVjdGlvbiwgcmVz dWx0aW5nIGluIG1peGVkIEpXVCBhY2Nlc3MNCnRva2VucyBhbmQgaW50cm9zcGVjdGlvbiBhcyB3 ZWxsLg0KDQpUaGF04oCZcyBhbGwgcG9zc2libGUgd2l0aGluIHRoZSBjdXJyZW50IHRleHQuDQoN CmtpbmQgcmVnYXJkcywNClRvcnN0ZW4NCg0KDQpLaW5kIHJlZ2FyZHMsDQpSZW1jbyBTY2hhYXIN Cg0KLS0tLS1Pb3JzcHJvbmtlbGlqayBiZXJpY2h0LS0tLS0NClZhbjogVG9yc3RlbiBMb2RkZXJz dGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQu bmV0Pj4NClZlcnpvbmRlbjogemF0ZXJkYWcgMTcgYXVndXN0dXMgMjAxOSAxNDowMA0KQWFuOiBT Y2hhYXIsIFIuTS4gKFJlbWNvKSAtIExvZ2l1cyA8cmVtY28uc2NoYWFyQGxvZ2l1cy5ubDxtYWls dG86cmVtY28uc2NoYWFyQGxvZ2l1cy5ubD4+DQpDQzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9h dXRoQGlldGYub3JnPg0KT25kZXJ3ZXJwOiBSZTogW09BVVRILVdHXSBRdWVzdGlvbiByZWdhcmRp bmcgZHJhZnQtaWV0Zi1vYXV0aC1qd3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS0wNQ0KDQpIaSBS ZW1jbywNCg0KT24gNi4gQXVnIDIwMTksIGF0IDE2OjAxLCBTY2hhYXIsIFIuTS4gKFJlbWNvKSAt IExvZ2l1cyA8cmVtY28uc2NoYWFyQGxvZ2l1cy5ubDxtYWlsdG86cmVtY28uc2NoYWFyQGxvZ2l1 cy5ubD4+IHdyb3RlOg0KDQpIZWxsbywNCg0KWy4uLl0NClJGQyA3NTE5IGFuZCBSRkMgNzY2MiDi gJxqdXN04oCdIGRlZmluZSBkaWZmZXJlbnQgcmVwcmVzZW50YXRpb25zIGZvciB0b2tlbiBkYXRh LiBJbiBSRkMgNzUxOSB0aGUgZGF0YSBpcyBjYXJyaWVkIGluIHRoZSB0b2tlbiBpdHNlbGYgKHdo aWNoIGFsc28gbWVhbnMgdGhlIGZvcm1hdCBvZiB0aGUgdG9rZW4gaXMgd2VsbC1kZWZpbmVkIGFu ZCBrbm93IHRvIHRoZSBSUykgd2hlcmVhcyBSRkMgNzY2MiBkZWZpbmVzIGEgd2F5IHRvIGluc3Bl Y3QgdG9rZW5zIHZpYSBhbiBBUEkgcHJvdmlkZWQgYnkgdGhlIEFTLiBUaGUgbGF0dGVyIGlzIHR5 cGljYWxseSB1c2VkIGluIGNvbmp1bmN0aW9uIHdpdGggb3BhcXVlIHRva2VucywgaS5lLiB0aGUg UlMgZG9lcyBub3QgaGF2ZSBhIGNsdWUgaG93IHRvIHBhcnNlIGFuZCBpbnRlcnByZXQgdGhlIHRv a2VuLiBUaGUgdG9rZW4gbWlnaHQganVzdCBiZSBhIGhhbmRsZSB0byBhIGRhdGFiYXNlIGVudHJ5 IGF0IHRoZSBBUyBpbiB0aGlzIGNhc2UuDQoNClRoaXMgYWxzbyBtZWFucyBhIEpXVCAoUkZDIDc2 NjIpIGFuZCB0aGUgSW50cm9zcGVjdGlvbiBSZXNwb25zZSBhcmUgY29uY2VwdHVhbGx5IHRoZSBz YW1lIGZyb20gYSBSU3MgcGVyc3BlY3RpdmUuDQoNClsuLi5dDQoNClRoZSDigJhqdGnigJkgcGFy YW1ldGVyIGhvd2V2ZXIgd2lsbCBhbHdheXMgYmUgYW1iaWd1b3VzLiBBcyBpdCBpcyBhbiBpZGVu dGlmaWVyLCBpdCBzaG91bGQgZGlmZmVyIGZvciB0aGUgaW50cm9zcGVjdGVkIHRva2VuIGFuZCB0 aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZSBieSBkZWZpbml0aW9uLiBIZW5jZSB0aGUgc2VtYW50 aWNzIG9mIOKAmGp0aeKAmSBpbiBhIEpXVCBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlIGlzIHVuY2xl YXIuIFRoZSBzYW1lIGNhbiBhcHBseSB0byB0aGUg4oCYaWF04oCZLCDigJhuYmbigJkgYW5kIOKA mGV4cOKAmSBjbGFpbXMgaW4gYSBKV1QgaW50cm9zcGVjdGlvbiByZXNwb25zZS4NCg0KSSBkb27i gJl0IHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2UgeW91IGFyZSBtYWtpbmcuIEFsbCBiZWZvcmUg bWVudGlvbmVkIGNsYWltcyBhcmUgcmVsYXRlZCB0byB0aGUgKGFic3RyYWN0KSBhY2Nlc3MgdG9r ZW4uIFlvdSBtYXkgdGhpbmsgb2YgdGhlIEludHJvc3BlY3Rpb24gUmVzcG9uc2UgYXMgX3RoZV8g SldUIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBhY2Nlc3MgdG9rZW4gcHJvZHVjZWQgYnkgdGhlIEFT IGZvciB0aGUgUlMuDQoNCg0KQ2FuIHNvbWVvbmUgY2xhcmlmeSB0aGUgc2VtYW50aWNzIG9mIGNs YWltcyBpbiBhbiBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlIEpXVCB0aGF0IGFyZSBkZWZpbmVkIGlu IGJvdGggUkZDNzY2MiBhbmQgUkZDNzUxOT8NCg0KRnVydGhlcm1vcmUsIHRoZSBpbnRyb3NwZWN0 aW9uIHJlc3BvbnNlIHNob3VsZCB1c2UgdGhlIOKAmGlzc+KAmSBhbmQg4oCYYXVk4oCZIGNsYWlt cyB0byBhdm9pZCBjcm9zcy1KV1QgY29uZnVzaW9uIChzZWN0aW9uIDYuMSkuIFRoZSDigJhpc3Pi gJkgYW5kIOKAmGF1ZOKAmSBvZiBhbiBpbnRyb3NwZWN0ZWQgdG9rZW4gd2lsbCB0eXBpY2FsbHkg YmUgdGhlIHNhbWUgYXMgdGhvc2Ugb2YgdGhlIGludHJvc3BlY3Rpb24gcmVzcG9uc2UuIEhlbmNl IGEgSldUIGFjY2VzcyB0b2tlbiBjYW5ub3QgYmUgZGlzdGluZ3Vpc2hlZCBmcm9tIGFuIGludHJv c3BlY3Rpb24gcmVzcG9uc2UgdXNpbmcg4oCYaXNz4oCZIGFuZCDigJhhdWTigJkgYXMgc3VnZ2Vz dGVkIGluIHRoZSBkcmFmdC4uDQoNCkludHJvc3BlY3Rpb24gcmVmZXJzIHRvIEpXVCBiZXN0LWN1 cnJlbnQtcHJhY3RpY2UuIFRoZSBkcmFmdCBCQ1AgcmVjb21tZW5kcyB1c2luZyBleHBsaWNpdCB0 eXBpbmcgb2YgSldUcywgaG93ZXZlciB0aGUgZHJhZnQgSldUIHJlc3BvbnNlIGZvciBpbnRyb3Nw ZWN0aW9uIGRvZXMgbm90IGFwcGx5IHRoaXMgcmVjb21tZW5kYXRpb24gYW5kIHVzZXMgdGhlIGdl bmVyaWMg4oCYYXBwbGljYXRpb24vand04oCZIGluc3RlYWQuLi4gVGhlIEJDUCBoYXMgb3RoZXIg cmVjb21tZW5kYXRpb25zIGluIHNlY3Rpb24gMy4xMiwgYnV0IHRoZXNlIG1heSBiZSBpbnN1ZmZp Y2llbnQgdG8gZGlzdGluZ3Vpc2ggYSBKV1QgYWNjZXNzIHRva2VuIGZyb20gYSBKV1QgaW50cm9z cGVjdGlvbiByZXNwb25zZS4NCg0KR29vZCBwb2ludC4gVGhlIHJlYXNvbiB3aHkgdGhlIEJDUCBy ZWNvbW1lbmRzIGV4cGxpY2l0IHR5cGluZyBpcyB0byBwcmV2ZW50IHJlcGxheSBpbiBvdGhlciBj b250ZXh0cy4gSW4gdGhlIGVuZCB0eXBpbmcgaXMgYSBjb21wZWxsaW5nIGNvbmNlcHQgdW5mb3J0 dW5hdGVseSBub3QgYnJvYWRseSB1c2VkIGluIHRoZSB3aWxkLg0KDQpTbyB0aGUgSldUIEludHJv c3BlY3Rpb24gUmVzcG9uc2UgZHJhZnQgY29wZXMgd2l0aCB0aGF0IGF0dGFjayBhbmdsZSBieSBt YWtpbmcgaXNzIGFuZCBhdWQgbWFuZGF0b3J5Lg0KDQoNCg0KSG93IHdvdWxkIHBlb3BsZSBzdWdn ZXN0IHRvIGJlc3QgZGlzdGluZ3Vpc2ggYSBKV1QgKGFjY2VzcykgdG9rZW4gZnJvbSBhIEpXVCBp bnRyb3NwZWN0aW9uIHJlc3BvbnNlPw0KDQpXaHkgc2hvdWxkIHlvdT8gT25lIHJlYXNvbiB3aHkg d2UgZXh0ZW5kZWQgdGhlIEludHJvc3BlY3Rpb24gUmVzcG9uc2Ugd2FzIHRvIGVsaW1pbmF0ZSB0 aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIEpXVHMgZGlyZWN0bHkgdXNlZCBhcyBhY2Nlc3MgdG9rZW5z IGFuZCBJbnRyb3NwZWN0aW9uIFJlc3BvbnNlcy4NCg0KYmVzdCByZWdhcmRzLA0KVG9yc3Rlbi4N Cg0KDQpEaXQgYmVyaWNodCBrYW4gaW5mb3JtYXRpZSBiZXZhdHRlbiBkaWUgbmlldCB2b29yIHUg aXMgYmVzdGVtZC4gSW5kaWVuIHUgbmlldCBkZSBnZWFkcmVzc2VlcmRlIGJlbnQgb2YgZGl0IGJl cmljaHQgYWJ1c2lldmVsaWprIGFhbiB1IGlzIHRvZWdlem9uZGVuLCB3b3JkdCB1IHZlcnpvY2h0 IGRhdCBhYW4gZGUgYWZ6ZW5kZXIgdGUgbWVsZGVuIGVuIGhldCBiZXJpY2h0IHRlIHZlcndpamRl cmVuLiBEZSBTdGFhdCBhYW52YWFyZHQgZ2VlbiBhYW5zcHJha2VsaWpraGVpZCB2b29yIHNjaGFk ZSwgdmFuIHdlbGtlIGFhcmQgb29rLCBkaWUgdmVyYmFuZCBob3VkdCBtZXQgcmlzaWNvJ3MgdmVy Ym9uZGVuIGFhbiBoZXQgZWxla3Ryb25pc2NoIHZlcnplbmRlbiB2YW4gYmVyaWNodGVuLg0KVGhp cyBtZXNzYWdlIG1heSBjb250YWluIGluZm9ybWF0aW9uIHRoYXQgaXMgbm90IGludGVuZGVkIGZv ciB5b3UuIElmIHlvdSBhcmUgbm90IHRoZSBhZGRyZXNzZWUgb3IgaWYgdGhpcyBtZXNzYWdlIHdh cyBzZW50IHRvIHlvdSBieSBtaXN0YWtlLCB5b3UgYXJlIHJlcXVlc3RlZCB0byBpbmZvcm0gdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlLiBUaGUgU3RhdGUgYWNjZXB0cyBubyBsaWFi aWxpdHkgZm9yIGRhbWFnZSBvZiBhbnkga2luZCByZXN1bHRpbmcgZnJvbSB0aGUgcmlza3MgaW5o ZXJlbnQgaW4gdGhlIGVsZWN0cm9uaWMgdHJhbnNtaXNzaW9uIG9mIG1lc3NhZ2VzLg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19vYXV0aCZkPUR3UUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1 ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09 MF9GY3VjRnN0cXp0MEh5cjNpdmJNWDhpNGEyTGEyNHRZUmVrNW4tWGd2cyZzPUxUd0R0cGVIVno5 akRJb2s5Sk90TjZkZDFUUzRpLTNWb1pMUGR0NkwyTnMmZT0+DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRo QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9fb2F1dGgmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVh cElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPTBf RmN1Y0ZzdHF6dDBIeXIzaXZiTVg4aTRhMkxhMjR0WVJlazVuLVhndnMmcz1MVHdEdHBlSFZ6OWpE SW9rOUpPdE42ZGQxVFM0aS0zVm9aTFBkdDZMMk5zJmU9DQoNCg== --_000_BD763C91B8224985B95497B81FFD14E5mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <516612F69400684B9321B4318CB02ACC@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRvIGJlIGNsZWFyLCBJIGFtIGluIG5vIHdheSBz dWdnZXN0aW5nIHdlIHNob3VsZCBsZXZlcmFnZSBTRVQgZm9yIHRoaXMgZHJhZnQuIFRoYXQgd291 bGQgYmUgYSB0ZXJyaWJsZSBpZGVhLiBJIGFtIHNheWluZyB0aGF0IHRoZSBzb2x1dGlvbiBtaWdo dCBiZSBhIHNpbWlsYXIgcGF0dGVybiB0aGF0IFNFVCB1c2VkIGZvciBncm91cGluZyB0aGUgY2xh aW1zIHVuZGVyIGEgdG9wIGxldmVsIGNsYWltLiBJdOKAmXMgYSBwYXR0ZXJuIEkgd2lzaCBtb3Jl IGFwcGxpY2F0aW9ucw0KIG9mIEpXVCB3b3VsZCB1c2UsIGJ1dCBKV1Qgc3VmZmVycyBmcm9tIGhh dmluZyBiZWVuIGludmVudGVkIGZvciBhIHZlcnkgc3BlY2lmaWMgcHVycG9zZSBhbmQgdGhlbiBi ZWluZyBtYWRlIGdlbmVyaWMuIEhvcGVmdWxseSB3ZSBjYW4gbGVhcm4gZnJvbSBzb21lIG9mIHRo ZSBtaXN0YWtlcyBpbiBTRVQgYXMgd2VsbCwgYW5kIG5vdCBqdXN0IGRlZmluZSBhIHRvcC1sZXZl bCBjbGFpbSBhbmQgc3RheSBvdXQgb2YgaXQuJm5ic3A7DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rp dj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPk9uIFNlcCA0LCAyMDE5LCBhdCA0OjA5IFBNLCBQaGlsIElkbSBIdW50 ICZsdDs8YSBocmVmPSJtYWlsdG86UEhJTC5IVU5UQE9SQUNMRS5DT00iIGNsYXNzPSIiPlBISUwu SFVOVEBPUkFDTEUuQ09NPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWlu dGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBjbGFz cz0iIj4mIzQzOzEmbmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPlRoaXMgZmVlbHMgbGlrZSBpdCBoYXMgc2ltaWxhciByZXF1aXJlbWVudHMg YW5kIGNvbmNlcm5zIGFzIGZvciBTRVQgYW5kIG1heSBiZSBzaG91bGQgbGV2ZXJhZ2UgaXQgdG8g YXZvaWQgY29uZnVzaW9uIGFuZCBpbmNvbnNpc3RlbmNpZXMgZG93biB0aGUgcm9hZC4mbmJzcDsN CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+UGhp bDwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KT24gU2VwIDQs IDIwMTksIGF0IDEyOjQ5IFBNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJp Y2hlckBtaXQuZWR1IiBjbGFzcz0iIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkFzIEni gJl2ZSBzYWlkIGluIHRoZSBwYXN0LCBJIHRoaW5rIHRoZXJlIGlzIGFuZCBzaG91bGQgYmUgYSBj bGVhciBkaWZmZXJlbmNlIGJldHdlZW4gYSBKV1QgYWNjZXNzIHRva2VuIGFuZCBhIEpXVC1mb3Jt YXR0ZWQgcmVzcG9uc2UgZnJvbSBhbnkgZW5kcG9pbnQuIEl0IGdldHMgZXh0cmEgZnV6enkgaGVy ZSBiZWNhdXNlIHRoZSByZXNwb25zZSBmcm9tIHRoZSBlbmRwb2ludCByZXByZXNlbnRzIHRoZSB0 b2tlbiBiZWluZyBpbnRyb3NwZWN0ZWQuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Ib3dldmVyLCBJIHRoaW5rIHRoZXkgYXJl IHN0aWxsIHR3byB2ZXJ5IGRpZmZlcmVudCB0aGluZ3MgYmVjYXVzZSB0aGUgaW50cm9zcGVjdGlv biByZXNwb25zZSBieSBkZWZpbml0aW9uIHJlcHJlc2VudHMgd2hhdCB0aGUgdG9rZW4gd2FzIGF0 IHRoZSB0aW1lIG9mIGludHJvc3BlY3Rpb24uIFRoYXTigJlzIHdoeSB0aGUg4oCcYWN0aXZl4oCd IGNsYWltIGlzIGltcG9ydGFudCBoZXJlLCBhbG9uZyB3aXRoIHRoZSB0aW1lc3RhbXAgaW5mb3Jt YXRpb24NCiBpbiB0aGUgSldUIGNvbnRhaW5lciDigJQgeW91IGNhbiBzYXkgdGhhdCB0aGUgdG9r ZW4gKndhcyogYWN0aXZlIGF0IHRoZSB0aW1lIG9mIGludHJvc3BlY3Rpb24sIGJ1dCB5b3UgY2Fu 4oCZdCBzYXkgaXTigJlzIHN0aWxsIGFjdGl2ZSB3aXRob3V0IGludHJvc3BlY3RpbmcgdGhlIHRv a2VuIGFnYWluIHRvIGNoZWNrLiBUaGlzIGxlYWRzIHRvIGV4YWN0bHkgdGhlIGtpbmQgb2YgY29s bGlzaW9uIHRoYXTigJlzIGJlaW5nIGRpc2N1c3NlZCBoZXJlLiBJdOKAmXMgY29uZnVzaW5nDQog Zm9yIGRldmVsb3BlcnMgb2YgYm90aCB0aGUgQVMgYW5kIHRoZSBSUywgYW5kIEkgZmVhciBpdOKA mXMgZ29pbmcgdG8gbGVhZCB0byBhbiBBUyBjaG9vc2luZyBvbmUgaW50ZXJwcmV0YXRpb24gYW5k IGFuIFJTIGNob29zaW5nIGFub3RoZXIsIGFuZCB0aGVyZWZvcmUgbGVhdmluZyBvcGVuIGEgZG9v ciB0byBzZWN1cml0eSBpc3N1ZXMgZG93biB0aGUgcm9hZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFsc28sIHJlbWVtYmVyIG9uZSBv ZiB0aGUgbWFpbiByZWFzb25zIHRoYXQgd2UgcmVxdWlyZSBzb21lIGZvcm0gb2YgUlMgYXV0aGVu dGljYXRpb24gdG8gdGhlIHRva2VuIGVuZHBvaW50IGlzIHRoYXQgZGlmZmVyZW50IFJT4oCZcyBj YW4gZ2V0IGRpZmZlcmVudCBhbnN3ZXJzIGZvciB0aGUgc2FtZSB0b2tlbi4gVGhlIEFTIGNhbiB0 YWlsb3IgaXRzIHJlc3BvbnNlIGJhc2VkIG9uIHdoYXQgc2NvcGVzIHRoZSBSUyBpcyBzdXBwb3Nl ZA0KIHRvIGtub3cgYWJvdXQsIG9yIHdoaWNoIFJT4oCZcyBjYW4ga25vdyBhIHVzZXLigJlzIGlk ZW50aWZpZXIgKG9yIGV2ZW4gdXNlIHBhaXJ3aXNlIGlkZW50aWZpZXJzKSwgb3IgZXZlbiB3aGlj aCBSUyBpcyBzdXBwb3NlZCB0byBrbm93IGFib3V0IGEgZ2l2ZW4gdG9rZW4gYXQgYWxsLiBJbiBl YWNoIG9mIHRoZXNlIGNhc2VzLCB1c2luZyB0aGlzIGRyYWZ0LCB5b3XigJlsbCBnZXQgYSBkaWZm ZXJlbnQgSldUIG91dCBmb3IgdGhlIHNhbWUgdG9rZW4gb24gdGhlDQogd2F5IGluLiBZb3XigJly ZSBub3Qgc2ltcGx5IHRyYW5zbGF0aW5nIGFuIGFjY2VzcyB0b2tlbiB0byBhbm90aGVyIGFjY2Vz cyB0b2tlbiBoZXJlIOKAlCBpZiB5b3Ugd2FudCB0byBkbyB0aGF0LCB1c2UgdG9rZW4gZXhjaGFu Z2UgYW5kIGRvIGl0IHByb3Blcmx5IHdpdGggYW4gT0F1dGggZ3JhbnQuIEluc3RlYWQsIHlvdeKA mXJlIGdldHRpbmcgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHRva2VuIGl0c2VsZiBhdCB0aGUgdGlt ZSBvZiB0aGUgcmVxdWVzdCBhbmQNCiBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgcmVxdWVz dG9yLCBhbmQgeW91IGhhcHBlbiB0byBiZSB3cmFwcGluZyB0aGUgcmVzcG9uc2UgaW4gYSBjb250 YWluZXIgdGhhdCBpcyBhbHNvIHdpZGVseSB1c2VkIHRvIGZvcm1hdCBhY2Nlc3MgdG9rZW5zLiZu YnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClRoZSBzZXBh cmF0aW9uIHRoYXQgVG9yc3RlbiBwb2ludHMgb3V0IGJlbG93IGJyaW5ncyB1cCBvbmUgb2YgdGhl IGJpZ2dlc3QgcHJvYmxlbXMgd2l0aCBKV1RzIGFzIGEgZGF0YSBjb250YWluZXIgZm9ybWF0IOKA lCBhbGwgdGhlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBKV1QgaXRzZWxmIGlzIG1peGVkIGluIHdp dGggdGhlIHRoaW5nIGl04oCZcyBjYXJyeWluZyBpbmZvcm1hdGlvbiBhYm91dC4gV2Ugc2VlIHRo aXMgaXNzdWUgd2l0aCBKQVIsIHdoZXJlDQogdGhlIOKAnGF1ZOKAnSBwYXJhbWV0ZXIgY2FuIG1l YW4gdGhlIGF1ZGllbmNlIG9mIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgYW5kIHRoZSBhdWRp ZW5jZSBvZiB0aGUgSldUIHVzZWQgdG8gY2FycnkgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdC4g V2UgYWxzbyBzZWUgdGhpcyBhIGxpdHRsZSBiaXQgaW4gZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0 aW9u4oCZcyBzb2Z0d2FyZSBzdGF0ZW1lbnQuIFJvb3QtbGV2ZWwgSldUIGNsYWltcyBhcmUgYSBw b29yDQogbWVjaGFuaXNtIGZvciB0aGlzLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW4gcmV0cm9zcGVjdCwgd2hhdCBJIHdpc2ggd2XigJlkIGRv bmUgd2l0aCBhbGwgb2YgdGhlbSB1c2luZyBhIG5hbWVkIHBheWxvYWQgbGlrZSB3aXRoIFNFVOKA mXMg4oCcZXZlbnTigJ0gY2xhaW0uIEV2ZW4gdGhlcmUsIHdlIGhhZCBhIGxvdCBvZiBhcmd1bWVu dCBhYm91dCBhIOKAnHN1YuKAnSBjbGFpbSBpbnNpZGUgdGhlIOKAnGV2ZW504oCdIG9iamVjdCB2 cy4gb25lIGF0IHRoZSByb290IG9mIHRoZSBKV1QgY29udGFpbmVyLCBidXQgYXQgbGVhc3QNCiBp biB0aGVzZSBjYXNlcyAmbmJzcDt3ZSBub3cgaGFkIGFuIG9wcG9ydHVuaXR5IHRvIHdyaXRlIGNs ZWFyIGxhbmd1YWdlIGFib3V0IHdoYXQgZWFjaCBtZWFudCBpbiBlYWNoIGNpcmN1bXN0YW5jZS4g SSByZWFsaXplIHRoaXMgZHJhZnQgaXMgYWxyZWFkeSB3ZWxsIGFsb25nIGluIGl0cyBwcm9jZXNz LCBhbmQgSSBoYXZlbuKAmXQgcHV0IGluIHRoZSByZXZpZXcgdGltZSBvciBjb21tZW50cyB0byBk YXRlIG15c2VsZiwgYnV0IEkgdGhpbmsgaXTigJlzIHVuZm9ydHVuYXRlDQogdGhhdCB0aGUgZHJh ZnQgZG9lc27igJl0IGRlZmluZSBhIHN1Yi1jbGFpbSBsaWtlIOKAnGFjY2Vzc190b2tlbuKAnSBv ciDigJx0b2tlbl9pbmZvcm1hdGlvbuKAnSB0byBjYXJyeSBpbnNpZGUgdGhlIEpXVCBwYXlsb2Fk LiBUaGlzIHdvdWxkIHNvbHZlIHRoZSBwcm9ibGVtIG9mIGRpZmZlcmVudGlhdGluZyB0aGUg4oCc aWF04oCdIGZvciB0aGUgdG9rZW4gaXRzZWxmIHZzLiB0aGUgSldUIGNvbnRhaW5lciBvZiB0aGUg cmVzcG9uc2UuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5UaGUgZ3JvdXAgbWF5IGFsc28gcmVjYWxsIHRoYXQgSSBvcmlnaW5hbGx5IHNh aWQgdGhhdCB0aGlzIGRyYWZ0IHNob3VsZCBub3QgYmUgZG9uZSBpbiBsaWdodCBvZiBvbmx5IGlu dHJvc3BlY3Rpb24sIGFuZCBpbnN0ZWFkIHNob3VsZCBiZSBhIGdlbmVyaWMgbWVjaGFuaXNtIGFj cm9zcyBPQXV0aOKAmXMgdmFyaW91cyBlbmRwb2ludHMuIFdlaXJkIGNvbWJpbmF0aW9ucyBsaWtl IHRoZSDigJxpYXTigJ0gY2xhaW0gaGVyZSBhcmUgYQ0KIGRyaXZlciBmb3IgaGF2aW5nIGEgc29s aWQgZ2VuZXJpYyBtZWNoYW5pc20gaW5zdGVhZCBvZiBhIGhhbmRmdWwgb2Ygc2xpZ2h0bHkgZGlm ZmVyZW50IGRlZmluaXRpb25zLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U28gd2hhdCBzaG91bGQgd2UgZG8gaGVyZT8gSWYg d2UgYXJlIHRvIGtlZXAgdGhlIGN1cnJlbnQgcHJhY3RpY2Ugb2YgcHV0dGluZyBldmVyeXRoaW5n IGluIHRoZSByb290IG9mIHRoZSBKV1QsIHdlIHNob3VsZCBoYXZlIGRpZmZlcmVudCBjbGFpbSBu YW1lcyB0byBkaWZmZXJlbnRpYXRlIHRoZSBlbnZlbG9wZSBhbmQgdGhlIHRva2VuLiBUaGUgcHJv YmxlbSBoZXJlIGlzIHRoYXQg4oCcaWF04oCdIGlzIGFscmVhZHkgZGVmaW5lZA0KIGluIFJGQzc2 NjIgYXMgcmVmZXJyaW5nIHRvIHRoZSB0b2tlbiBhbmQgaW4gUkZDNzUxOSBhcyByZWZlcnJpbmcg dG8gdGhlIEpXVCAod2hpY2ggaXMgbm90IGEgdG9rZW4sIGJ1dCB0aGUgY29udGFpbmVyIGZvciB0 aGUgdG9rZW4gaW5mb3JtYXRpb24pLiBJ4oCZbSBub3Qgc3VyZSB3aGljaCBpcyB3b3JzZSwgZGVm aW5pbmcgYW4g4oCcaWF04oCdIGZvciB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZSBvciBvbmUg Zm9yIHRoZSBKV1QgYnV0IG9ubHkgaW4gdGhpcw0KIGluc3RhbmNlLiBCb3RoIGZlZWwgcmVhbGx5 IG1lc3N5LCBhbmQgaW4gY2FzZXMgbGlrZSBUb3JzdGVu4oCZcyB0aGV5IGNvbGxhcHNlIHRvIHRo ZSBzYW1lIHZhbHVlLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+SWYgaG93ZXZlciB3ZSBwdXQgdGhlIGludHJvc3BlY3Rpb24gcmVzcG9u c2UgaW4gaXRzIG93biBzdWItc2VjdGlvbiBvZiB0aGUgSldUIHBheWxvYWQsIHRoZW4gd2UgY291 bGQgYXZvaWQgdGhlIG5hbWVzcGFjZSBjb2xsaXNpb24gZW50aXJlbHkuIFdlIHdvdWxkIG5lZWQg bm9ybWF0aXZlIHJ1bGVzIGxpa2UgaW4gU0VUIHRvIGRlZmluZSBob3cgdGhlc2UgZmllbGRzIHJl bGF0ZSB0byBlYWNoIG90aGVyLCBidXQgSSBzZWUNCiB0aGF0IGFzIGEgdHJhY3RhYmxlIHByb2Js ZW0gd2l0aCBhIHJlYXNvbmFibGUgKGlmIGltcGVyZmVjdCkgcHJlY2VkZW50LiZuYnNwOzwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RWl0 aGVyIHBhdGggbWVhbnMgcmVkb2luZyBXR0xDIGFuZCB0aGUgYXNzb2NpYXRlZCByZXZpZXdzLCBJ 4oCZbSBhZnJhaWQuIExlYXZpbmcgaXQgYXMtaXMgd29ya3MgZm9yIHRoZSBkcml2aW5nIHVzZSBj YXNlIHdoZXJlIHRoZSBpbmZvcm1hdGlvbiBpcyBhbGwgdGhlIHNhbWUsIGJ1dCBJIGRvbuKAmXQg ZmluZCBpdCB0byBiZSBhIHBhcnRpY3VsYXJseSBjbGVhbiByZXByZXNlbnRhdGlvbiBvZiB0aGUg aW5mb3JtYXRpb24gaW4gcXVlc3Rpb24uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IiBjbGFzcz0iIj4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+T24gU2VwIDQsIDIwMTksIGF0IDU6MjEgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0 OzxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgY2xhc3M9IiI+dG9yc3Rl bkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSBS ZW1jbyw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj5PbiAzMS4gQXVnIDIwMTksIGF0IDIxOjI3LCBTY2hhYXIsIFIuTS4gKFJlbWNv KSAtIExvZ2l1cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJlbWNvLnNjaGFhckBsb2dpdXMubmwiIGNs YXNzPSIiPnJlbWNvLnNjaGFhckBsb2dpdXMubmw8L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpIZWxsbyBUb3JzdGVuLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCihteSBhcG9sb2dpZXMgZm9yIG1ha2luZyBhIHR5cG8gcHJldmlvdXNseSk8YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpUaGFua3MgOi0pPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KVGltZSBvZiBpbnRyb3NwZWN0aW9uIGlzIGNyaXRpY2FsIGlmIHlvdSB3YW50IHRv IHVzZSB0aGUgc2lnbmVkIGludHJvc3BlY3Rpb248YnIgY2xhc3M9IiI+DQpyZXNwb25zZSBmb3Ig bGF0ZXIgYWNjb3VudGFiaWxpdHkgb3IgYXVkaXQgcHVycG9zZXMuIEZvciBleGFtcGxlLCBhIENs aWVudDxiciBjbGFzcz0iIj4NCm9idGFpbnMgYW4gYWNjZXNzIHRva2VuIEEgYXQgdGltZSB0LiBO b3cgYSByZXNvdXJjZSBzZXJ2ZXIgcmVjZWl2ZXMgQSBhdCB0aW1lPGJyIGNsYXNzPSIiPg0KdCYj NDM7MSwgY2FsbHMgaW50cm9zcGVjdGlvbiBhbmQgcmVjZWl2ZXMgYSByZXNwb25zZSBjb250YWlu aW5nIGFjdGl2ZT10cnVlLiBBdDxiciBjbGFzcz0iIj4NCnQmIzQzOzIgdGhlIGFjY2Nlc3MgdG9r ZW4gaXMgcmV2b2tlZC4gQXQgdGltZSB0JiM0MzszIHRoZSByZXNvdXJjZSBzZXJ2ZXIgbWFrZXMg YSBuZXc8YnIgY2xhc3M9IiI+DQppbnRyb3NwZWN0aW9uIHJlcXVlc3QsIG5vdyByZWNlaXZlcyBh IHJlc3BvbnNlIGNvbnRhaW5pbmcgYWN0aXZlPWZhbHNlLiBUaGU8YnIgY2xhc3M9IiI+DQpvbmx5 IGRpZmZlcmVuY2Ugd291bGQgYmUgdGhlIHZhbHVlIG9mIHRoZSBhY3RpdmUgcGFyYW1ldGVyLiBX aXRob3V0IHRoZSB0aW1lPGJyIGNsYXNzPSIiPg0Kb2YgaW50cm9zcGVjdGlvbiBub3IgYSB1bmlx dWUgaWQgY292ZXJlZCBieSB0aGUgc2lnbmF0dXJlLCBvbmUgY2Fubm90IG1ha2UgYTxiciBjbGFz cz0iIj4NCmNvbmNsdXNpdmUgZGlzdGluY3Rpb24gYmV0d2VlbiBzdWJzZXF1ZW50IHJlc3BvbnNl cyBpZiByZXZvY2F0aW9uIG1heSBiZSBpbjxiciBjbGFzcz0iIj4NCnBsYXkuPGJyIGNsYXNzPSIi Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KVGhhdOKAmXMgYSBnb29kIHBvaW50LiAm bmJzcDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpUaGUgZHJhZnQgc3BlY2lmaWVzIDxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1suLi5dIHRvIHJldHVybiByZXNwb25z ZXMgYXMgSldUcy48YnIgY2xhc3M9IiI+DQpUaGlzIGNvdWxkIGVpdGhlciBtZWFuICZxdW90O3Ro ZSByZXNwb25zZSBpcyByZXR1cm5lZCBpbiBKV1QgZm9ybWF0JnF1b3Q7IG9yICZxdW90O3RoZTxi ciBjbGFzcz0iIj4NCnJlc3BvbnNlIGNvbnRhaW5zIGEgSldUIHJlcHJlc2VudGF0aW9uIG9mIHRo ZSBpbnNwZWN0ZWQgdG9rZW7igJ0uPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNs YXNzPSIiPg0KSSdtIG1lYW53aGlsZSBsZWFuaW5nIHRvd2FyZHMgJnF1b3Q7dGhlIHJlc3BvbnNl IGlzIHJldHVybmVkIGluIEpXVCBmb3JtYXTigJ0uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+Tm90IGhhdmluZzxiciBjbGFzcz0i Ij4NCmNsZWFyLCBzZXBhcmF0ZSBwYXJhbWV0ZXJzIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gdGhl IHRpbWUgYW5kIGlkIG9mIHRoZTxiciBjbGFzcz0iIj4NCnRva2VuIGFuZCB0aGUgdGltZSBhbmQg aWQgb2YgdGhlIHJlc3BvbnNlIHJlc3VsdHMgaW4gZG91YmxlIG1lYW5pbmcuIEFzIGE8YnIgY2xh c3M9IiI+DQpjb25zZXF1ZW5jZSwgaXQgaXMgZWl0aGVyIGhhdmluZyB0aGUgcmlzayBvZiByZXBs YXkgb2YgYW4gYWNjZXNzIHRva2VuIG9yPGJyIGNsYXNzPSIiPg0KcmVwbGF5IG9mIGFuIGludHJv c3BlY3Rpb24gcmVzcG9uc2UgaW5zdGVhZCBvZiBuZWl0aGVyLjxiciBjbGFzcz0iIj4NCjwvYmxv Y2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCknigJltIG5vdCBzdXJlIGhvdyBhbiBhdHRhY2tlciBj b3VsZCByZXBsYXkgYW4gaW50cm9zcGVjdGlvbiByZXNwb25zZSBnaXZlbiBpdCBpcyB0aWdodGVk IHRvIGEgY2VydGFpbiBlbmRwb2ludCB2aWEgdGhlIGlzcyBjbGFpbS4NCjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCkkgYWdyZWUgdGhlIFJTIGxhY2tzIGEgd2F5IHRvIHByb29mIHdoZW4g aXQgd2FzIHByb3ZpZGVkIHdpdGggdGhlIGFjY2VzcyB0b2tlbiBkYXRhIGJ5IHRoZSBBUy4NCjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBwcm9ibGVtIGluIG15IG9waW5pb24gaXMg dGhlIG92ZXJsYXkgYmV0d2VlbiB0aGUgb3JpZ2luYWwgYWNjZXNzIHRva2VuIGRhdGEgKGUuZy4g d2hlbiB3YXMgaXQgaXNzdWVkIGJ5IHRoZSBBUykgYW5kIHRoZSBkYXRhIGJlbG9uZ2luZyB0byB0 aGUgcmVwcmVzZW50YXRpb24gaW4gdGhlIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgKHdoZW4gd2Fz IHRoZSByZXNwb25zZSBjcmVhdGVkKS4gQ29uY2VwdHVhbGx5LCB0aGlzIG1lYW5zIHdlIHJlcXVp cmUNCiB0d28gc2VwYXJhdCDigJxpYXQmcXVvdDsgKGFsaWtlKSBjbGFpbXMgdG8gZGlzdGluZ3Vp c2ggYm90aCBhc3BlY3RzLiA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGNvdWxkIGlt YWdlIHR3byB3YXlzIHRvIGhhbmRsZSB0aGlzOjxiciBjbGFzcz0iIj4NCi0gYWRkIGFub3RoZXIg aWF0IGNsYWltLCBlLmcuIOKAnHRpcl9pYXQmcXVvdDssIHRvIHRoZSBKV1Q8YnIgY2xhc3M9IiI+ DQotIGFkZCBhbm90aGVyIOKAnGlhdCZxdW90OyBjbGFpbSB0byB0aGUgSldTIGhlYWRlciBjb250 YWluaW5nIHRoZSBpbnN0YW50IHdoZW4gdGhlIHRva2VuIGludHJvc3BlY3Rpb24gcmVzcG9uc2Ug d2FzIGNyZWF0ZWQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpXaGF0IGRvIHlvdSB0aGlu az88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpiZXN0IHJlZ2FyZHMsPGJyIGNsYXNzPSIi Pg0KVG9yc3Rlbi4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KS2luZCByZWdhcmRzLDxiciBjbGFzcz0i Ij4NClJlbWNvIHNjaGFhcjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tLS0tT29yc3By b25rZWxpamsgYmVyaWNodC0tLS0tPGJyIGNsYXNzPSIiPg0KVmFuOiBUb3JzdGVuIExvZGRlcnN0 ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIGNsYXNzPSIi PnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiZndDsNCjxiciBjbGFzcz0iIj4NClZlcnpvbmRl bjogd29lbnNkYWcgMjggYXVndXN0dXMgMjAxOSAxMToxNDxiciBjbGFzcz0iIj4NCkFhbjogU2No YWFyLCBSLk0uIChSZW1jbykgLSBMb2dpdXMgJmx0OzxhIGhyZWY9Im1haWx0bzpyZW1jby5zY2hh YXJAbG9naXVzLm5sIiBjbGFzcz0iIj5yZW1jby5zY2hhYXJAbG9naXVzLm5sPC9hPiZndDs8YnIg Y2xhc3M9IiI+DQpDQzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiBjbGFzcz0iIj5v YXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpPbmRlcndlcnA6IFJlOiBbT0FVVEgtV0dd IFF1ZXN0aW9uIHJlZ2FyZGluZyBkcmFmdC1pZXRmLW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJl c3BvbnNlLTA1PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSGkgUmhlbWNvLDxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPk9u IDI2LiBBdWcgMjAxOSwgYXQgMDk6NDIsIFNjaGFhciwgUi5NLiAoUmVtY28pIC0gTG9naXVzICZs dDs8YSBocmVmPSJtYWlsdG86cmVtY28uc2NoYWFyQGxvZ2l1cy5ubCIgY2xhc3M9IiI+cmVtY28u c2NoYWFyQGxvZ2l1cy5ubDwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCkhlbGxvIFRob3JzdGVuLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoYW5rIHlv dSBmb3IgeW91ciByZXNwb25zZS4gSSBoYXZlIGEgZmV3IG1vcmUgcXVlc3Rpb25zL2NvbW1lbnRz IGFzPGJyIGNsYXNzPSIiPg0KZm9sbG93LXVwLi4uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KWW91IHN0YXRlIHRoYXQgUkZDNzUxOSBhbmQgUkZDNzY2MiAmcXVvdDtqdXN0JnF1b3Q7IGRl ZmluZSBkaWZmZXJlbnQgcmVwcmVzZW50YXRpb25zPGJyIGNsYXNzPSIiPg0KZm9yIHRva2VuIGRh dGEuIElmIHRoZSBkcmFmdCBSRkMgd291bGQgcmVmZXIgdG8gUkZDIDc1MTUgKEpXUyksIEkgd291 bGQ8YnIgY2xhc3M9IiI+DQphZ3JlZS4gSG93ZXZlciwgUkZDNzUxOSAoSldUKSBleHBsaWNpdGx5 IGFkZHMgc2VtYW50aWNzIHRvIHNvbWUgc3BlY2lmaWM8YnIgY2xhc3M9IiI+DQpwYXJhbWV0ZXJz IChlLmcuIGF1ZCwganRpIGFuZCBpYXQpLiBSRkM3NjYyIGhhcyBkaWZmZXJlbnQgc2VtYW50aWNz IGZvcjxiciBjbGFzcz0iIj4NCnRoZSBzZXZlcmFsIG9mIHRoZSBzYW1lIHBhcmFtZXRlcnMuPGJy IGNsYXNzPSIiPg0KRm9yIGluc3RhbmNlIHRoZSAnaWF0JywgaXMgdGhlIG1vbWVudCBvZiBpc3N1 YW5jZSBvZiB0aGUgSldUIGluIFJGQzc1MTkuIEluPGJyIGNsYXNzPSIiPg0KUkZDNzY2MiB0aGF0 IGlzIHRoZSAmcXVvdDt3aGVuIHRoaXMgdG9rZW4gd2FzIG9yaWdpbmFsbHkgaXNzdWVkJnF1b3Q7 LiBUaGlzIHRpbWUgd2lsbDxiciBjbGFzcz0iIj4NCnZhcnkgaW4gdXNlIGNhc2VzIHdpdGhvdXQg aW1tZWRpYXRlIGludHJvc3BlY3Rpb24gb2YgYW4gYWNjZXNzIHRva2VuLjxiciBjbGFzcz0iIj4N CjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkkgcmVhZCB0aGUgdGV4dCBkaWZmZXJlbnRs eS4gSW4gbXkgaW50ZXJwcmV0YXRpb24g4oCcd2hlbiB0aGUgdG9rZW4gd2FzIG9yaWdpbmFsbHkg aXNzdWVk4oCdIHN0YXRlZCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgaW50cm9zcGVjdGlv biBlbmRwb2ludCByZWZlcnMgZXhhY3RseSB0byB0aGUgc2FtZSBpbnN0YW50IGFzIOKAnHRoZSB0 aW1lIGF0IHdoaWNoIHRoZSBKV1Qgd2FzPGJyIGNsYXNzPSIiPg0KJm5ic3A7aXNzdWVk4oCdLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCkZvciB0aGUgdXNlIGNhc2Ugb2YgdGhlIHJlc291cmNlIHNlcnZl ciByZWx5aW5nIG9uIHZlcmlmaWFibGUgZGF0YSwgYXM8YnIgY2xhc3M9IiI+DQpkZXNjcmliZWQg aW4gdGhlIGludHJvZHVjdGlvbiBvZiB0aGUgZHJhZnQgUkZDLCB0aGUgdGltZSBvZiB0aGUgaW50 cm9zcGVjdGlvbjxiciBjbGFzcz0iIj4NCmlzIGNyaXRpY2FsLjxiciBjbGFzcz0iIj4NCjwvYmxv Y2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCldoeSBpcyB0aGlzIHRpbWUgY3JpdGljYWw/PGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ SW4gcGFydGljdWxhciB3aGVuIGNvbWJpbmVkIHdpdGggcmV2b2NhdGlvbiwgdGhlIHRpbWUgb2Y8 YnIgY2xhc3M9IiI+DQppbnRyb3NwZWN0aW9uIGFuZCB0aGUgJ2FjdGl2ZScgc3RhdHVzIGNhbiBk aWZmZXIgYmV0d2VlbiB0d28gc3Vic2VxdWVudCBjYWxsczxiciBjbGFzcz0iIj4NCmZvciBpbnRy b3NwZWN0aW9uLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClRo ZSBzdGF0dXMgYXQgdG9rZW4gaW50cm9zcGVjdGlvbiByZXF1ZXN0IHRpbWUgaXMgaW5kZWVkIGNy aXRpY2FsLiBSRkMgNzY2MiBnaXZlcyBhIGdvb2QgaW5kaWNhdGlvbiBob3cgdGhpcyB2YWx1ZSBz aG91bGQgYmUgY2FsY3VsYXRlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQrigJzigKYg YSAmcXVvdDt0cnVlJnF1b3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 dmFsdWUgcmV0dXJuIGZvciB0aGUgJnF1b3Q7YWN0aXZlJnF1b3Q7IHByb3BlcnR5IHdpbGwgZ2Vu ZXJhbGx5IGluZGljYXRlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhh dCBhIGdpdmVuIHRva2VuIGhhcyBiZWVuIGlzc3VlZCBieSB0aGlzIGF1dGhvcml6YXRpb24gc2Vy dmVyLDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2hhcyBub3QgYmVlbiBy ZXZva2VkIGJ5IHRoZSByZXNvdXJjZSBvd25lciwgYW5kIGlzIHdpdGhpbiBpdHM8YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtnaXZlbiB0aW1lIHdpbmRvdyBvZiB2YWxpZGl0 eSAoZS5nLiwgYWZ0ZXIgaXRzIGlzc3VhbmNlIHRpbWUgYW5kPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7YmVmb3JlIGl0cyBleHBpcmF0aW9uIHRpbWUpLiZxdW90OyA8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTbyBpdCByZXByZXNlbnRzIHRoZSByZXN1bHRzIG9m IHRoZSBpc3N1ZXIgY2hlY2ssIHRoZSByZXZvY2F0aW9uIGNoZWNrIGFuZCB0aGUgdmFsaWRpdHkg Y2hlY2sgaW4gb25lIGJvb2xlYW4gdmFsdWUuDQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpJZiB0aGUg ZHJhZnQgUkZDIGp1c3QgcHJvZHVjZXMgYSBKV1QgcmVwcmVzZW50YXRpb24gb2YgdGhlIGFjY2Vz cyB0b2tlbiw8YnIgY2xhc3M9IiI+DQppbmNsdWRpbmcgJ2FjdGl2ZScgd291bGQgbm90IG1ha2Ug c2Vuc2UgYXMgdGhlIEpXVCB3aWxsIGV4cGlyZSB3aXRob3V0PGJyIGNsYXNzPSIiPg0KdXBkYXRp bmcgaXQgdG8gZmFsc2UuIExlYXZpbmcgJ2FjdGl2ZScgb3V0IHdvdWxkIG1ha2UgaXQgaW5jb21w YXRpYmxlIHdpdGg8YnIgY2xhc3M9IiI+DQpSRkM3NjYyIGludHJvc3BlY3Rpb24gcmVzcG9uc2Vz LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCuKAnGFjdGl2ZeKA nSBpcyBub3QgcGFydCBvZiB0aGUgSldUIHJlcHJlc2VudGF0aW9uIEkgcmVmZXJyZWQgdG8uIFRo ZSBBUyBuZWVkcyB0byBkZXRlcm1pbmUgdGhlIGFjdGl2ZSB2YWx1ZSBmb3IgZXZlcnkgdG9rZW4g aW50cm9zcGVjdGlvbiByZXF1ZXN0Lg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSWYg dGhlIFJTIHdvdWxkIGNvbnN1bWUgSldUcywgaXQgd291bGQgZGV0ZXJtaW5lIHRoZSDigJxhY3Rp dmXigJ0gdmFsdWUgaXRzZWxmIGJ5IGluc3BlY3RpbmcgdGhlIGlzcyBjbGFpbSBhbmQgY2hlY2sg YWdhaW5zdCBpdHMgQVMgd2hpdGVsaXN0LCBjaGVjayB0aGUgc2lnbmF0dXJlIGFuZCB0aGUgaWF0 ICZhbXA7IGV4cCB2YWx1ZXMuIERldGVybWluaW5nIHRoZSByZXZvY2F0aW9uIHN0YXR1cyB3b3Vs ZCByZXF1aXJlIGFuIGluZm9ybWF0aW9uIGV4Y2hhbmdlDQogd2l0aCB0aGUgQVMgb2Ygc29tZSBz b3J0LiA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj5TaW1pbGFyLCBub3QgaW5jbHVkaW5nIGEgdW5pcXVlICdqdGknIHBlciBpbnRy b3NwZWN0aW9uIHJlc3BvbnNlIHdvdWxkIG1ha2U8YnIgY2xhc3M9IiI+DQp0aGUgcmVzb3VyY2Ug c2VydmVyIHZ1bG5lcmFibGUgdG8gcmVwbGF5IGF0dGFja3MuPGJyIGNsYXNzPSIiPg0KPC9ibG9j a3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KVG8gdGhlIGNvbnRyYXJ5LCBpbmNsdWRpbmcgYSBkaWZm ZXJlbnQg4oCcaml0JnF1b3Q7IHdpdGggZXZlcnkgdG9rZW4gaW50cm9zcGVjdGlvbiByZXNwb25z ZSB3b3VsZCBtYWtlIHRoZSBSUyB2dWxuZXJhYmxlIHRvIHJlcGxheSBvZiBvbmUgdGltZSBhY2Nl c3MgdG9rZW4gc2luY2UgaXQgcmVtb3ZlIHRoZSBwb3NzaWJpbGl0eSBmb3IgdGhlIFJTIHRvIGlk ZW50aXR5IGEgY2VydGFpbiBhY2Nlc3MgdG9rZW4uDQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PciB0aGUgcmVzb3VyY2Ugc2Vy dmVyPGJyIGNsYXNzPSIiPg0Kd291bGQgbWlzdGFrZW5seSByZWZlciB0byBub24tdW5pcXVlIHRv a2VucywgbWFraW5nIHRoZSByZXNwb25zZXMgdW5zdWl0YWJsZTxiciBjbGFzcz0iIj4NCmZvciBh Y2NvdW50YWJpbGl0eSBhbmQgYXVkaXQgcHVycG9zZXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KQXMgdG8gd2h5IHNvbWVvbmUgd291bGQgd2FudCB0byBkaXN0 aW5ndWlzaCBhIEpXVCBhY2Nlc3MgdG9rZW4gZnJvbSBhbjxiciBjbGFzcz0iIj4NCmludHJvc3Bl Y3Rpb24gcmVzcG9uc2U6IHNldmVyYWwgdXNlIGNhc2VzIGNvbWUgdG8gbWluZC48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpGaXJzdCBvZiBhbGwsIGV2ZW4gaWYgb25lIGlzIHVzaW5nIHN0 YW5kYWxvbmUgaW50ZXJwcmV0YWJsZSBKV1QgYWNjZXNzIHRva2Vucyw8YnIgY2xhc3M9IiI+DQpv bmUgbWF5IHdhbnQgdG8gY29tYmluZSB0aGF0IHdpdGggcmV2b2NhdGlvbiBjaGVja2luZyB1c2lu ZyBpbnRyb3NwZWN0aW9uLiBUaGU8YnIgY2xhc3M9IiI+DQppbnRlcnByZXRhdGlvbiBhbmQgbWVh bmluZyBvZiB0aGUgSldUIGFuZCB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZSB0aGFuIGRvPGJy IGNsYXNzPSIiPg0KZGlmZmVyIGFuZCBtYXR0ZXIuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3Rl Pg0KPGJyIGNsYXNzPSIiPg0KQXMgSSBkZXNjcmliZWQgYWJvdmUsIEkgZG9u4oCZdCBzZWUgYW55 IGRpZmZlcmVuY2UuIDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkFub3RoZXIgdXNlIGNhc2Ugd291bGQg YmUgYSBtaXhlZCBlY29zeXN0ZW0gd2l0aCByZXNvdXJjZSBzZXJ2ZXJzIHJlbHlpbmcgb248YnIg Y2xhc3M9IiI+DQppbnRyb3NwZWN0aW9uIHdoaWxlIG90aGVycyBkbyBwYXJzZSBKV1QgYWNjZXNz IHRva2Vucy4gQSBzaW5nbGUsIHVuaWZvcm08YnIgY2xhc3M9IiI+DQppbXBsZW1lbnRhdGlvbiBm b3IgdGhlIEFTIHdvdWxkIHRoYW4gbWl4IGJvdGggYXMgd2VsbC48YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpTZWUgYWJvdmUgLSBJIGRvbuKAmXQgc2VlIGFueSBp c3N1ZS4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KQSBsYXN0IHVzZSBjYXNlIGNvdWxkIGJlIGV4Y2hh bmdpbmcgYWNjZXNzIHRva2VucyB3aXRoIGEgc3Vic2V0IG9mIHRoZSBmdWxsPGJyIGNsYXNzPSIi Pg0Kc2V0IG9mIGFwcGxpY2FibGUgcGFyYW1ldGVycywgdG8gcmVkdWNlIHRoZSBzaXplIG9mIGFj Y2VzcyB0b2tlbnMuIEFkZGl0aW9uYWw8YnIgY2xhc3M9IiI+DQppbmZvcm1hdGlvbiBjYW4gYmUg ZXhjaGFuZ2VkIHZpYSBpbnRyb3NwZWN0aW9uLCByZXN1bHRpbmcgaW4gbWl4ZWQgSldUIGFjY2Vz czxiciBjbGFzcz0iIj4NCnRva2VucyBhbmQgaW50cm9zcGVjdGlvbiBhcyB3ZWxsLjxiciBjbGFz cz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClRoYXTigJlzIGFsbCBwb3NzaWJs ZSB3aXRoaW4gdGhlIGN1cnJlbnQgdGV4dC4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K a2luZCByZWdhcmRzLDxiciBjbGFzcz0iIj4NClRvcnN0ZW4gPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K S2luZCByZWdhcmRzLDxiciBjbGFzcz0iIj4NClJlbWNvIFNjaGFhcjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCi0tLS0tT29yc3Byb25rZWxpamsgYmVyaWNodC0tLS0tPGJyIGNsYXNzPSIi Pg0KVmFuOiBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBs b2RkZXJzdGVkdC5uZXQiIGNsYXNzPSIiPnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiZndDsN CjxiciBjbGFzcz0iIj4NClZlcnpvbmRlbjogemF0ZXJkYWcgMTcgYXVndXN0dXMgMjAxOSAxNDow MDxiciBjbGFzcz0iIj4NCkFhbjogU2NoYWFyLCBSLk0uIChSZW1jbykgLSBMb2dpdXMgJmx0Ozxh IGhyZWY9Im1haWx0bzpyZW1jby5zY2hhYXJAbG9naXVzLm5sIiBjbGFzcz0iIj5yZW1jby5zY2hh YXJAbG9naXVzLm5sPC9hPiZndDs8YnIgY2xhc3M9IiI+DQpDQzogPGEgaHJlZj0ibWFpbHRvOm9h dXRoQGlldGYub3JnIiBjbGFzcz0iIj5vYXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpP bmRlcndlcnA6IFJlOiBbT0FVVEgtV0ddIFF1ZXN0aW9uIHJlZ2FyZGluZyBkcmFmdC1pZXRmLW9h dXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNlLTA1PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KSGkgUmVtY28sPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gNi4gQXVnIDIwMTksIGF0IDE2OjAxLCBTY2hhYXIsIFIu TS4gKFJlbWNvKSAtIExvZ2l1cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJlbWNvLnNjaGFhckBsb2dp dXMubmwiIGNsYXNzPSIiPnJlbWNvLnNjaGFhckBsb2dpdXMubmw8L2E+Jmd0OyB3cm90ZTo8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpIZWxsbyw8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVv dGU+DQo8YnIgY2xhc3M9IiI+DQpbLi4uXTxiciBjbGFzcz0iIj4NClJGQyA3NTE5IGFuZCBSRkMg NzY2MiDigJxqdXN04oCdIGRlZmluZSBkaWZmZXJlbnQgcmVwcmVzZW50YXRpb25zIGZvciB0b2tl biBkYXRhLiBJbiBSRkMgNzUxOSB0aGUgZGF0YSBpcyBjYXJyaWVkIGluIHRoZSB0b2tlbiBpdHNl bGYgKHdoaWNoIGFsc28gbWVhbnMgdGhlIGZvcm1hdCBvZiB0aGUgdG9rZW4gaXMgd2VsbC1kZWZp bmVkIGFuZCBrbm93IHRvIHRoZSBSUykgd2hlcmVhcyBSRkMgNzY2MiBkZWZpbmVzIGEgd2F5IHRv IGluc3BlY3QgdG9rZW5zDQogdmlhIGFuIEFQSSBwcm92aWRlZCBieSB0aGUgQVMuIFRoZSBsYXR0 ZXIgaXMgdHlwaWNhbGx5IHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aCBvcGFxdWUgdG9rZW5zLCBp LmUuIHRoZSBSUyBkb2VzIG5vdCBoYXZlIGEgY2x1ZSBob3cgdG8gcGFyc2UgYW5kIGludGVycHJl dCB0aGUgdG9rZW4uIFRoZSB0b2tlbiBtaWdodCBqdXN0IGJlIGEgaGFuZGxlIHRvIGEgZGF0YWJh c2UgZW50cnkgYXQgdGhlIEFTIGluIHRoaXMgY2FzZS4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NClRoaXMgYWxzbyBtZWFucyBhIEpXVCAoUkZDIDc2NjIpIGFuZCB0aGUgSW50cm9zcGVj dGlvbiBSZXNwb25zZSBhcmUgY29uY2VwdHVhbGx5IHRoZSBzYW1lIGZyb20gYSBSU3MgcGVyc3Bl Y3RpdmUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KWy4uLl08YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5UaGUg4oCYanRp 4oCZIHBhcmFtZXRlciBob3dldmVyIHdpbGwgYWx3YXlzIGJlIGFtYmlndW91cy4gQXMgaXQgaXMg YW4gaWRlbnRpZmllciwgaXQgc2hvdWxkIGRpZmZlciBmb3IgdGhlIGludHJvc3BlY3RlZCB0b2tl biBhbmQgdGhlIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgYnkgZGVmaW5pdGlvbi4gSGVuY2UgdGhl IHNlbWFudGljcyBvZiDigJhqdGnigJkgaW4gYSBKV1QgaW50cm9zcGVjdGlvbiByZXNwb25zZQ0K IGlzIHVuY2xlYXIuIFRoZSBzYW1lIGNhbiBhcHBseSB0byB0aGUg4oCYaWF04oCZLCDigJhuYmbi gJkgYW5kIOKAmGV4cOKAmSBjbGFpbXMgaW4gYSBKV1QgaW50cm9zcGVjdGlvbiByZXNwb25zZS48 YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpJIGRvbuKAmXQgdW5k ZXJzdGFuZCB0aGUgZGlmZmVyZW5jZSB5b3UgYXJlIG1ha2luZy4gQWxsIGJlZm9yZSBtZW50aW9u ZWQgY2xhaW1zIGFyZSByZWxhdGVkIHRvIHRoZSAoYWJzdHJhY3QpIGFjY2VzcyB0b2tlbi4gWW91 IG1heSB0aGluayBvZiB0aGUgSW50cm9zcGVjdGlvbiBSZXNwb25zZSBhcyBfdGhlXyBKV1QgcmVw cmVzZW50YXRpb24gb2YgdGhlIGFjY2VzcyB0b2tlbiBwcm9kdWNlZCBieSB0aGUgQVMgZm9yIHRo ZSBSUy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpDYW4gc29tZW9uZSBjbGFyaWZ5IHRoZSBzZW1hbnRp Y3Mgb2YgY2xhaW1zIGluIGFuIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgSldUIHRoYXQgYXJlIGRl ZmluZWQgaW4gYm90aCBSRkM3NjYyIGFuZCBSRkM3NTE5PzxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCkZ1cnRoZXJtb3JlLCB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZSBzaG91bGQgdXNl IHRoZSDigJhpc3PigJkgYW5kIOKAmGF1ZOKAmSBjbGFpbXMgdG8gYXZvaWQgY3Jvc3MtSldUIGNv bmZ1c2lvbiAoc2VjdGlvbiA2LjEpLiBUaGUg4oCYaXNz4oCZIGFuZCDigJhhdWTigJkgb2YgYW4g aW50cm9zcGVjdGVkIHRva2VuIHdpbGwgdHlwaWNhbGx5IGJlIHRoZSBzYW1lIGFzIHRob3NlIG9m IHRoZSBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlLiBIZW5jZSBhIEpXVCBhY2Nlc3MgdG9rZW4NCiBj YW5ub3QgYmUgZGlzdGluZ3Vpc2hlZCBmcm9tIGFuIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgdXNp bmcg4oCYaXNz4oCZIGFuZCDigJhhdWTigJkgYXMgc3VnZ2VzdGVkIGluIHRoZSBkcmFmdC4uPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSW50cm9zcGVjdGlvbiByZWZlcnMgdG8gSldUIGJl c3QtY3VycmVudC1wcmFjdGljZS4gVGhlIGRyYWZ0IEJDUCByZWNvbW1lbmRzIHVzaW5nIGV4cGxp Y2l0IHR5cGluZyBvZiBKV1RzLCBob3dldmVyIHRoZSBkcmFmdCBKV1QgcmVzcG9uc2UgZm9yIGlu dHJvc3BlY3Rpb24gZG9lcyBub3QgYXBwbHkgdGhpcyByZWNvbW1lbmRhdGlvbiBhbmQgdXNlcyB0 aGUgZ2VuZXJpYyDigJhhcHBsaWNhdGlvbi9qd3TigJkgaW5zdGVhZC4uLiBUaGUgQkNQIGhhcyBv dGhlcg0KIHJlY29tbWVuZGF0aW9ucyBpbiBzZWN0aW9uIDMuMTIsIGJ1dCB0aGVzZSBtYXkgYmUg aW5zdWZmaWNpZW50IHRvIGRpc3Rpbmd1aXNoIGEgSldUIGFjY2VzcyB0b2tlbiBmcm9tIGEgSldU IGludHJvc3BlY3Rpb24gcmVzcG9uc2UuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJy IGNsYXNzPSIiPg0KR29vZCBwb2ludC4gVGhlIHJlYXNvbiB3aHkgdGhlIEJDUCByZWNvbW1lbmRz IGV4cGxpY2l0IHR5cGluZyBpcyB0byBwcmV2ZW50IHJlcGxheSBpbiBvdGhlciBjb250ZXh0cy4g SW4gdGhlIGVuZCB0eXBpbmcgaXMgYSBjb21wZWxsaW5nIGNvbmNlcHQgdW5mb3J0dW5hdGVseSBu b3QgYnJvYWRseSB1c2VkIGluIHRoZSB3aWxkLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N ClNvIHRoZSBKV1QgSW50cm9zcGVjdGlvbiBSZXNwb25zZSBkcmFmdCBjb3BlcyB3aXRoIHRoYXQg YXR0YWNrIGFuZ2xlIGJ5IG1ha2luZyBpc3MgYW5kIGF1ZCBtYW5kYXRvcnkuDQo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpIb3cgd291bGQgcGVvcGxlIHN1Z2dlc3QgdG8gYmVz dCBkaXN0aW5ndWlzaCBhIEpXVCAoYWNjZXNzKSB0b2tlbiBmcm9tIGEgSldUIGludHJvc3BlY3Rp b24gcmVzcG9uc2U/PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0K V2h5IHNob3VsZCB5b3U/IE9uZSByZWFzb24gd2h5IHdlIGV4dGVuZGVkIHRoZSBJbnRyb3NwZWN0 aW9uIFJlc3BvbnNlIHdhcyB0byBlbGltaW5hdGUgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBKV1Rz IGRpcmVjdGx5IHVzZWQgYXMgYWNjZXNzIHRva2VucyBhbmQgSW50cm9zcGVjdGlvbiBSZXNwb25z ZXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KYmVzdCByZWdhcmRzLDxiciBjbGFzcz0i Ij4NClRvcnN0ZW4uIDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CkRpdCBiZXJpY2h0IGthbiBpbmZvcm1hdGllIGJldmF0dGVuIGRpZSBuaWV0IHZvb3IgdSBpcyBi ZXN0ZW1kLiBJbmRpZW4gdSBuaWV0IGRlIGdlYWRyZXNzZWVyZGUgYmVudCBvZiBkaXQgYmVyaWNo dCBhYnVzaWV2ZWxpamsgYWFuIHUgaXMgdG9lZ2V6b25kZW4sIHdvcmR0IHUgdmVyem9jaHQgZGF0 IGFhbiBkZSBhZnplbmRlciB0ZSBtZWxkZW4gZW4gaGV0IGJlcmljaHQgdGUgdmVyd2lqZGVyZW4u IERlIFN0YWF0IGFhbnZhYXJkdCBnZWVuIGFhbnNwcmFrZWxpamtoZWlkDQogdm9vciBzY2hhZGUs IHZhbiB3ZWxrZSBhYXJkIG9vaywgZGllIHZlcmJhbmQgaG91ZHQgbWV0IHJpc2ljbydzIHZlcmJv bmRlbiBhYW4gaGV0IGVsZWt0cm9uaXNjaCB2ZXJ6ZW5kZW4gdmFuIGJlcmljaHRlbi48YnIgY2xh c3M9IiI+DQpUaGlzIG1lc3NhZ2UgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpcyBub3Qg aW50ZW5kZWQgZm9yIHlvdS4gSWYgeW91IGFyZSBub3QgdGhlIGFkZHJlc3NlZSBvciBpZiB0aGlz IG1lc3NhZ2Ugd2FzIHNlbnQgdG8geW91IGJ5IG1pc3Rha2UsIHlvdSBhcmUgcmVxdWVzdGVkIHRv IGluZm9ybSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UuIFRoZSBTdGF0ZSBhY2Nl cHRzIG5vIGxpYWJpbGl0eSBmb3IgZGFtYWdlIG9mIGFueSBraW5kDQogcmVzdWx0aW5nIGZyb20g dGhlIHJpc2tzIGluaGVyZW50IGluIHRoZSBlbGVjdHJvbmljIHRyYW5zbWlzc2lvbiBvZiBtZXNz YWdlcy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2Nr cXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0i Ij4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5v cmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19v YXV0aCZhbXA7ZD1Ed1FHYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVC NjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRL Wk5BJmFtcDttPTBfRmN1Y0ZzdHF6dDBIeXIzaXZiTVg4aTRhMkxhMjR0WVJlazVuLVhndnMmYW1w O3M9TFR3RHRwZUhWejlqRElvazlKT3RONmRkMVRTNGktM1ZvWkxQZHQ2TDJOcyZhbXA7ZT0iIGNs YXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJy IGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+T0F1dGggbWFpbGluZyBsaXN0PC9zcGFuPjxiciBj bGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIg Y2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNs YXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fb2F1dGgmYW1wO2Q9RHdJ Q0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1w O3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT0wX0Zj dWNGc3RxenQwSHlyM2l2Yk1YOGk0YTJMYTI0dFlSZWs1bi1YZ3ZzJmFtcDtzPUxUd0R0cGVIVno5 akRJb2s5Sk90TjZkZDFUUzRpLTNWb1pMUGR0NkwyTnMmYW1wO2U9IiBjbGFzcz0iIj5odHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y Z19tYWlsbWFuX2xpc3RpbmZvX29hdXRoJmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FX SHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBj dHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209MF9GY3VjRnN0cXp0MEh5cjNpdmJNWDhpNGEy TGEyNHRZUmVrNW4tWGd2cyZhbXA7cz1MVHdEdHBlSFZ6OWpESW9rOUpPdE42ZGQxVFM0aS0zVm9a TFBkdDZMMk5zJmFtcDtlPTwvYT4NCjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BD763C91B8224985B95497B81FFD14E5mitedu_-- From nobody Wed Sep 4 14:08:02 2019 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 A62FD120147 for ; Wed, 4 Sep 2019 14:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=pingidentity.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 AG_hQn_rU53l for ; Wed, 4 Sep 2019 14:07:59 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 8F2D51200A3 for ; Wed, 4 Sep 2019 14:07:59 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id b136so23472418iof.3 for ; Wed, 04 Sep 2019 14:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vxf27wCwEpLSSCTlxhRuUuq+7KewHXD47Uq70JoLFJY=; b=NA9++FgvIZBDsVlEU7AelRIupY0IcVCAPW6gWNMP/RBE3UlAwHhov37FUYzsODE5Y1 GbLKAQj70k3a1HkL6p4xSWU5dGAh7J1ItZq7Oymfql5DrXEIcn0okFin2HA+V3BfaNj3 tZITNNDCr6VmLQpGGbxgXfFQCXNAXky7kmQi8= 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=Vxf27wCwEpLSSCTlxhRuUuq+7KewHXD47Uq70JoLFJY=; b=FnnCEprhUe6YY0EY1yirMQOMolyUWXKoBWtrmrBqkWAszMDnuOI9A8EmO7TG3FAkHR jnFVdEVglChoxQf7HmimpPH5ahwF5fI5Z+DCeNmOmY7Wg3RbX1pKCWTYyuIF6TH2FZ65 Tap5MrA135Ikp4/GIe3KTobckuDMV/InaBP8Pv3Xcfzu7zFgvBMbwwxuJRJA6fo2eCJP lhpSIl2wXbjkNbmriDKBM3LLKp5PpR8iOdqXO+xV9tGrIXXG4PY9FKU5yZs3UStb+eMe S/Y7KdLorB2xTL04al87AKOP3akvR708+lPR1tsVFVjiJzEpTzCk+l5fOXkIiCRAjrYQ rzSQ== X-Gm-Message-State: APjAAAV8wcbmlivBCAUIICtEHFnPp7/+UNlxkioqHlHgYtoADUi2myJt teY66Q85QTT/+KiZWNPlpH8YVwoAFUX9KoM+2SjbzUb4xnVpSI+4uqMKZNlXDORHXkTS4AO8YOC ncDod5bsGwON0Kg== X-Google-Smtp-Source: APXvYqyG50a4GDZ64b/1Pc1hlTm0EYW20HXLs0d4D48cOjn4GOL7P5icqLgdjjnGh5T8NWKvnJ70bHqfOA/wBC8saCE= X-Received: by 2002:a05:6638:6b2:: with SMTP id d18mr202377jad.61.1567631278795; Wed, 04 Sep 2019 14:07:58 -0700 (PDT) MIME-Version: 1.0 References: <156757720342.20663.3055037033818226992.idtracker@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Wed, 4 Sep 2019 15:07:31 -0600 Message-ID: To: Barry Leiba Cc: Adam Roach , draft-ietf-oauth-resource-indicators@ietf.org, oauth-chairs@ietf.org, The IESG , oauth Content-Type: multipart/alternative; boundary="000000000000830ef20591c0990e" Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) 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: Wed, 04 Sep 2019 21:08:02 -0000 --000000000000830ef20591c0990e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Barry, I kinda like it. Although I'm a bit hesitant to make a change like that at this stage. I guess I'd be looking for a little more buy-in from folks first. Though it's not actually a functional breaking change. So maybe okay to just go with. On Wed, Sep 4, 2019 at 2:54 PM Barry Leiba wrote: > > Yeah, with query parameters lacking the hierarchical semantics that the > path component has, it is much less clear. In fact, an earlier revision o= f > the draft forbid the query part as I was trying to avoid the ambiguity th= at > it brings. But there were enough folks with some use case for it that it > made its way back in. While I am sympathetic to the point you're making > here, I'd prefer to not codify the practice any further by way of example > in the document. > > Is it perhaps reasonable to discourage the use of a query component > while still allowing it? Maybe a "SHOULD NOT", such as this?: > > OLD > Its value MUST be an absolute URI, as specified by > Section 4.3 of [RFC3986], which MAY include a query component but > MUST NOT include a fragment component. > NEW > Its value MUST be an absolute URI, as specified by > Section 4.3 of [RFC3986]. The URI MUST NOT include > a fragment component. It SHOULD NOT include a query > component, but it is recognized that there are cases that > make a query component useful. > END > > What do you think? > > Barry > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000830ef20591c0990e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Barry, I kinda like it. Although I'm a bit hesi= tant to make a change like that at this stage. I guess I'd be looking f= or a little more buy-in from folks first. Though it's not actually a fu= nctional breaking change. So maybe okay to just go with.

On Wed, Sep 4,= 2019 at 2:54 PM Barry Leiba <barryleiba@computer.org> wrote:
> Yeah, with query parameters lacking the hierar= chical semantics that the path component has, it is much less clear. In fac= t, an earlier revision of the draft forbid the query part as I was trying t= o avoid the ambiguity that it brings. But there were enough folks with some= use case for it that it made its way back in. While I am sympathetic to th= e point you're making here, I'd prefer to not codify the practice a= ny further by way of example in the document.

Is it perhaps reasonable to discourage the use of a query component
while still allowing it?=C2=A0 Maybe a "SHOULD NOT", such as this= ?:

OLD
=C2=A0 =C2=A0 =C2=A0 Its value MUST be an absolute URI, as specified by
=C2=A0 =C2=A0 =C2=A0 Section 4.3 of [RFC3986], which MAY include a query co= mponent but
=C2=A0 =C2=A0 =C2=A0 MUST NOT include a fragment component.
NEW
=C2=A0 =C2=A0 =C2=A0 Its value MUST be an absolute URI, as specified by
=C2=A0 =C2=A0 =C2=A0 Section 4.3 of [RFC3986].=C2=A0 The URI MUST NOT inclu= de
=C2=A0 =C2=A0 =C2=A0 a fragment component.=C2=A0 It SHOULD NOT include a qu= ery
=C2=A0 =C2=A0 =C2=A0 component, but it is recognized that there are cases t= hat
=C2=A0 =C2=A0 =C2=A0 make a query component useful.
END

What do you think?

Barry

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000830ef20591c0990e-- From nobody Wed Sep 4 14:13:18 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A481200A3; Wed, 4 Sep 2019 14:13:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-oauth-resource-indicators@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156763159047.22689.9306520600745069059.idtracker@ietfa.amsl.com> Date: Wed, 04 Sep 2019 14:13:10 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2019 21:13:11 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-resource-indicators-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this easy-to-read-document -- reducing the risk of using bearer tokens seems worthwhile, since they are not going away very quickly. Abstract This seems to be a sentence fragment (maybe preface with "This document specifies"?). Section 1 When the authorization server is informed of the resource that will process the access token, it can restrict the intended audience of that token to the given resource such that the token cannot be used successfully at other resources. (This mechanism is only effective if the other resources are checking in some fashion, whether by direct inspection of a structured token or by a backchannel to the AS or otherwise, but I hope that checking 'aud' is standard practice by now!) Section 2.1 For authorization requests sent as a JWTs, such as when using JWT Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single "resource" parameter value is represented as a JSON string while multiple values are represented as an array of strings. jwsreq includes an example with "aud" in the request, yet this new "resource" request parameter is also intended to influence the audience of the resulting token. I'm not sure whether we need to say anything specifically about this in the document, but I'd like to have a better understanding of how "aud" and "resource" would interact when both present in the reqeust. (This is presumably related to why the request parameter is called "resource" and not "aud" or "audience", but unfortunately I seem to have zoned out for that part of the WG discussion.) If the client omits the "resource" parameter when requesting authorization, the authorization server MAY process the request with no specific resource or by using a pre-defined default resource value. [...] Would/could this default value be global or on a per-scope basis or some other finer granularity than global? The authorization server might use this data to inform the user about the resources the client is going to access on her behalf, to meet policy decision (e.g. refuse the request due to unknown resources), and determine the set of resources that can be used in subsequent access token requests. nits: comma after "e.g.", and maybe s/meet policy decision/apply policy/ (or similar), and "to" before "determine" for parallelism. In Figure 1 we URL-encode the '.'s in "client.example.org" but not in "api.example.com" in the request URL; should we be consistent? (This seems to be recurring throughout the examples.) Section 2.2 needs to know. This further improves privacy as scope values give an indication of what services the resource owner uses and downscoping a token to only that which is needed for a particular service can limit the extent to which such information is revealed across different services. As specified in Section 5.1 of [RFC6749], the (nit?) I suggest to s/scope values give an indication of what services the resource owner uses and/a list of scope values is an indication that the resource owner uses the multiple various services listed;/ since I misparsed it the first time as-is. Section 3 An access token that is audience restricted to a protected resource that obtains that token legitimately cannot be used to access resources on behalf of the resource owner at other protected resources. The "resource" parameter enables a client to indicate the nit: This sentence has a pretty strange construction. I think the intent is to say that that a token, legitimately presented to a resource, cannot then be taken by that resource server and illegitimately present it somewhere else for access to other resources. But with the current wording we seem to be missing part of the part where some entity obtains the token with intent for illegitimate access. Some servers may host user content or be multi-tenant. In order to avoid attacks that might confuse a client into sending an access token to a resource that is user controlled or is owned by a different tenant, it is important to use a specific resource URI including a path component. This will cause any access token issued for accessing the user controlled resource to have an invalid audience if replayed against the legitimate resource API. I'm not entirely sure what this is trying to say. What is the "legitimate resource API"? Why would a token be issued for accessing a user-controlled resource if that's something we're trying to avoid having confused clients access? Although multiple occurrences of the "resource" parameter may be included in a request, using only a single "resource" parameter is encouraged. A bearer token that has multiple intended recipients (audiences) indicating that the token is valid at more than one protected resource can be used by any one of those protected resources to access any of the other protected resources. Thus, a high degree of trust between the involved parties is needed when using access tokens with multiple audiences. Furthermore an authorization server may be unwilling or unable to fulfill a token request with multiple resources. Do we want to contrast this with an authorization code/refresh token, which may be more likely to be issued with a multiple-resource/audience property? From nobody Wed Sep 4 16:20:01 2019 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 E2CDE120805 for ; Wed, 4 Sep 2019 16:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 qOt9vPQYon9x for ; Wed, 4 Sep 2019 16:19:55 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 E6570120147 for ; Wed, 4 Sep 2019 16:19:54 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id m11so445087ioo.0 for ; Wed, 04 Sep 2019 16:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P8OGF7ZndeeGEYduWVQOHf9y6ZSyGA9EKKexNs5rq2k=; b=etXg+FhFKfYakqULyMz9h4JX1149oET4CtrFT4+MjQf9g+NKDRk53MDrBA5flaWxSw doUVfQgf9KsRrrmI+B7YWRAip70voEXr448dH6xnDLv9ADxe1APKDlV0fCuVXDStEBgg Bbu9Eh1s4BO6mez0XwqHeVShT5ZGo7dMMW+n4= 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=P8OGF7ZndeeGEYduWVQOHf9y6ZSyGA9EKKexNs5rq2k=; b=AJCbnJgtCgrqqs/vrtMvmo6hHi1/Bd6aD4OAB/lVU8MxVpTmbjPXoUB36ms4/dgXJw ObvxMqSKw1tgVb9r3Lw8arNAFrUiVH8olCyEQvtdIz/Lv0o+spaQmKJPV0IVPCU+ht13 dtsVdICu+loDwRhNPLzKcTphwXekM3JZc6PNnFfghNKgRUXIxTDvqN6iwugymdvKJgnY mEzvi6eASl7dG5CQ41CTGJeGesYHVNsnCNZVcp7wqsHatCNhRK7k3P5buTi34hB/UtaL UIprBL69k1WY5wDyHucP0hqEshidiKClt/WSt3iaYKnlb1BNXeBn6+ynMLrmTpjh5Cor hExA== X-Gm-Message-State: APjAAAX9RiCTsJdeLkPGjcgm67xltmfSVpBNYRxz/mW0TQ86B5cnFpFT RPA3MQt+AAkhO+UyzqPTPdOioSt4QlW7S/dQ0n1PhYyzMnYZynKUlVnseQlrnW8bnF0Judne6ql mkAAH3c7uYaQKHA== X-Google-Smtp-Source: APXvYqwfy/wTi6PW8Z6DaGWM3bMwZb9PwMizG8+o9r8dWrEPrbvGzis7xtvDKLqqulwPa4RsZfGV6Ly3JUIu60cZcOY= X-Received: by 2002:a6b:b494:: with SMTP id d142mr631984iof.156.1567639194068; Wed, 04 Sep 2019 16:19:54 -0700 (PDT) MIME-Version: 1.0 References: <156763159047.22689.9306520600745069059.idtracker@ietfa.amsl.com> In-Reply-To: <156763159047.22689.9306520600745069059.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Wed, 4 Sep 2019 17:19:27 -0600 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-oauth-resource-indicators@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000004cab790591c27182" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) 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: Wed, 04 Sep 2019 23:19:59 -0000 --0000000000004cab790591c27182 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ben, for the review and non-objectional ballot. On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-oauth-resource-indicators-05: No Objection ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Abstract > > This seems to be a sentence fragment (maybe preface with "This document > specifies"?). > Hrm. Yeah, I suppose so. I guess I was trying to be efficient with the words but to the point of not having a complete sentence. I'll add that preface. > Section 2.1 > > For authorization requests sent as a JWTs, such as when using JWT > Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single > "resource" parameter value is represented as a JSON string while > multiple values are represented as an array of strings. > > jwsreq includes an example with "aud" in the request, yet this new > "resource" request parameter is also intended to influence the audience > of the resulting token. I'm not sure whether we need to say anything > specifically about this in the document, but I'd like to have a better > understanding of how "aud" and "resource" would interact when both > present in the reqeust. > (This is presumably related to why the request parameter is called > "resource" and not "aud" or "audience", but unfortunately I seem to have > zoned out for that part of the WG discussion.) > In the context of a jwsreq request the "aud" indicates the intended recipient/audience of the singed authorization request itself, which will be the authorization server to whom the request is being made. This prevents a singed request meant for AS1 from being used successfully at AS2, for example. That "aud" does not do anything to influence the audience of the resulting token - it's really just metadata of the signed request that will be discarded once the singed request is validated. The "resource" parameter of this document indicates where the client intends to use the token its requesting, which can and will influence the audience of the resulting token. So "aud" and "resource" do not interact when both present in a signed authorization request. And yes, this is related to why the request parameter is called "resource" and not "aud" and also I think related to the outstanding discuss you have on jwsreq. If this parameter were to have been called "aud" then there would be a name collision when used in conjunction with jwsreq where "aud" would have had two distinct and irreconcilable meanings at the same time. There are a few other reasons the WG landed on "resource" as the name but what you've alluded to up here was a big part of it. If the client omits the "resource" parameter when requesting > authorization, the authorization server MAY process the request with > no specific resource or by using a pre-defined default resource > value. [...] > > Would/could this default value be global or on a per-scope basis or some > other finer granularity than global? > Yes, it could be any of those. Though I think most likely it'd be global or influenced by scope. Really, it'd be whatever that AS was doing in the absence of such a parameter before this document came along. > The > authorization server might use this data to inform the user about the > resources the client is going to access on her behalf, to meet policy > decision (e.g. refuse the request due to unknown resources), and > determine the set of resources that can be used in subsequent access > token requests. > > nits: comma after "e.g.", and maybe s/meet policy decision/apply policy/ > (or similar), and "to" before "determine" for parallelism. > Okay, will do. > In Figure 1 we URL-encode the '.'s in "client.example.org" but not in > "api.example.com" in the request URL; should we be consistent? (This > seems to be recurring throughout the examples.) > Shoot. I really do aim to be tighter with that kind of thing well before getting to the IESG evaluation phase. I suspect some copy/paste/change work along with not looking closely enough got the better of me here. I'll fix to use not-encoded '.'s throughout. > Section 2.2 > > needs to know. This further improves privacy as scope values give an > indication of what services the resource owner uses and downscoping a > token to only that which is needed for a particular service can limit > the extent to which such information is revealed across different > services. As specified in Section 5.1 of [RFC6749], the > > (nit?) I suggest to s/scope values give an indication of what services > the resource owner uses and/a list of scope values is an indication that > the > resource owner uses the multiple various services listed;/ since I > misparsed it the first time as-is. > Sure. Striving to avoid the ol' misparse is always good. > Section 3 > > An access token that is audience restricted to a protected resource > that obtains that token legitimately cannot be used to access > resources on behalf of the resource owner at other protected > resources. The "resource" parameter enables a client to indicate the > > nit: This sentence has a pretty strange construction. I think the > intent is to say that that a token, legitimately presented to a > resource, cannot then be taken by that resource server and > illegitimately present it somewhere else for access to other resources. > But with the current wording we seem to be missing part of the part > where some entity obtains the token with intent for illegitimate access. > Yes, despite the pretty strange construction, you have the correct intent. I'll work on improving that sentence (borrowing heavily from your words there). > Some servers may host user content or be multi-tenant. In order to > avoid attacks that might confuse a client into sending an access > token to a resource that is user controlled or is owned by a > different tenant, it is important to use a specific resource URI > including a path component. This will cause any access token issued > for accessing the user controlled resource to have an invalid > audience if replayed against the legitimate resource API. > > I'm not entirely sure what this is trying to say. What is the > "legitimate resource API"? Why would a token be issued for accessing a > user-controlled resource if that's something we're trying to avoid > having confused clients access? > Um... so on rereading that I might say that it's also "pretty strange". What it was trying to somehow say is similar to the previous nit about audience-restricted not being usable at the resource for whom the weren't intended. But saying so in the context of a multi-tenant environment. Basically it's trying to say that, in a multi-tenant environment, the resource URI and subsequent token audience need to have something that identifies the tenant so as to prevent the token from being used by one tenant to illegitimately access resources at a different tenant. I'll work on trying to improve that text to better explain all that. Although multiple occurrences of the "resource" parameter may be > included in a request, using only a single "resource" parameter is > encouraged. A bearer token that has multiple intended recipients > (audiences) indicating that the token is valid at more than one > protected resource can be used by any one of those protected > resources to access any of the other protected resources. Thus, a > high degree of trust between the involved parties is needed when > using access tokens with multiple audiences. Furthermore an > authorization server may be unwilling or unable to fulfill a token > request with multiple resources. > > Do we want to contrast this with an authorization code/refresh token, > which may be more likely to be issued with a multiple-resource/audience > property? > Yeah, it's perhaps worth making the distinction. Though I don't know that it needs to be explicitly contrasted per se. I think just qualifying the text above to more specifically say "... parameter may be included in a token request" (as apposed to authorization request) would be enough to indicate that the suggestion is only applicable to the access token and not authorization code/refresh token. --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000004cab790591c27182 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ben, for the review and non-objectional ballot= .

On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker <noreply@ietf.org> wro= te:
Benjamin Kad= uk has entered the following ballot position for
draft-ietf-oauth-resource-indicators-05: No Objection=C2=A0
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Abstract

This seems to be a sentence fragment (maybe preface with "This documen= t
specifies"?).

Hrm. Yeah, I suppose= so. I guess I was trying to be efficient with the words but to the point o= f not having a complete sentence. I'll add that preface.
=C2= =A0
=C2=A0
Section 2.1

=C2=A0 =C2=A0For authorization requests sent as a JWTs, such as when using = JWT
=C2=A0 =C2=A0Secured Authorization Request [I-D.ietf-oauth-jwsreq], a singl= e
=C2=A0 =C2=A0"resource" parameter value is represented as a JSON = string while
=C2=A0 =C2=A0multiple values are represented as an array of strings.

jwsreq includes an example with "aud" in the request, yet this ne= w
"resource" request parameter is also intended to influence the au= dience
of the resulting token.=C2=A0 I'm not sure whether we need to say anyth= ing
specifically about this in the document, but I'd like to have a better<= br> understanding of how "aud" and "resource" would interac= t when both
present in the reqeust.
(This is presumably related to why the request parameter is called
"resource" and not "aud" or "audience", but u= nfortunately I seem to have
zoned out for that part of the WG discussion.)

In the context of a jwsreq request the "aud" indicates th= e intended recipient/audience of the singed authorization request itself, w= hich will be the authorization server to whom the request is being made. Th= is prevents a singed request meant for AS1 from being used successfully at = AS2, for example. That "aud" does not do anything to influence th= e audience of the resulting token - it's really just metadata of the si= gned request that will be discarded once the singed request is validated. T= he "resource" parameter of this document indicates where the clie= nt intends to use the token its requesting, which can and will influence th= e audience of the resulting token. So "aud" and "resource&q= uot; do not interact when both present in a signed authorization request.

And yes, this is related to why the request paramet= er is called "resource" and not "aud" and also I think = related to the outstanding discuss you have on jwsreq. If this parameter we= re to have been called "aud" then there would be a name collision= when used in conjunction with jwsreq where "aud" would have had = two distinct and irreconcilable meanings at the same time. There are a few = other reasons the WG landed on "resource" as the name but what yo= u've alluded to up here was a big part of it.

=

=C2=A0=C2=A0 If the client omits the "resource" parameter when re= questing
=C2=A0 =C2=A0authorization, the authorization server MAY process the reques= t with
=C2=A0 =C2=A0no specific resource or by using a pre-defined default resourc= e
=C2=A0 =C2=A0value.=C2=A0 [...]

Would/could this default value be global or on a per-scope basis or some other finer granularity than global?

Ye= s, it could be any of those. Though I think most likely it'd be global = or influenced by scope. Really, it'd be whatever that AS was doing in t= he absence of such a parameter before this document came along.
<= div>
=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 The
=C2=A0 =C2=A0authorization server might use this data to inform the user ab= out the
=C2=A0 =C2=A0resources the client is going to access on her behalf, to meet= policy
=C2=A0 =C2=A0decision (e.g. refuse the request due to unknown resources), a= nd
=C2=A0 =C2=A0determine the set of resources that can be used in subsequent = access
=C2=A0 =C2=A0token requests.

nits: comma after "e.g.", and maybe s/meet policy decision/apply = policy/
(or similar), and "to" before "determine" for paralleli= sm.

Okay, will do.
=C2=A0=
=C2=A0
client.example.org&= quot; but not in
"api.example.com" in the request URL; should we be consistent?= =C2=A0 (This
seems to be recurring throughout the examples.)

Shoot. I really do aim to be tighter with that kind of thing well = before getting to the IESG evaluation phase. I suspect some copy/paste/chan= ge work along with not looking closely enough got the better of me here. I&= #39;ll fix to use not-encoded '.'s throughout.
=C2=A0=
=C2=A0
Section 3

=C2=A0 =C2=A0An access token that is audience restricted to a protected res= ource
=C2=A0 =C2=A0that obtains that token legitimately cannot be used to access<= br> =C2=A0 =C2=A0resources on behalf of the resource owner at other protected =C2=A0 =C2=A0resources.=C2=A0 The "resource" parameter enables a = client to indicate the

nit: This sentence has a pretty strange construction.=C2=A0 I think the
intent is to say that that a token, legitimately presented to a
resource, cannot then be taken by that resource server and
illegitimately present it somewhere else for access to other resources.
But with the current wording we seem to be missing part of the part
where some entity obtains the token with intent for illegitimate access.

Yes, despite the pretty strange construct= ion, you have the correct intent. I'll work on improving that sentence = (borrowing heavily from your words there).

= =C2=A0
=C2=A0 =C2=A0Some servers may host user content or be multi-tenant.=C2=A0 I= n order to
=C2=A0 =C2=A0avoid attacks that might confuse a client into sending an acce= ss
=C2=A0 =C2=A0token to a resource that is user controlled or is owned by a =C2=A0 =C2=A0different tenant, it is important to use a specific resource U= RI
=C2=A0 =C2=A0including a path component.=C2=A0 This will cause any access t= oken issued
=C2=A0 =C2=A0for accessing the user controlled resource to have an invalid<= br> =C2=A0 =C2=A0audience if replayed against the legitimate resource API.

I'm not entirely sure what this is trying to say.=C2=A0 What is the
"legitimate resource API"?=C2=A0 Why would a token be issued for = accessing a
user-controlled resource if that's something we're trying to avoid<= br> having confused clients access?

Um... s= o on rereading that I might say that it's also "pretty strange&quo= t;.

What it was trying to somehow say is simi= lar to the previous nit about audience-restricted not being usable at the r= esource for whom the weren't intended. But saying so in the context of = a multi-tenant environment. Basically it's trying to say that, in a mul= ti-tenant environment, the resource URI and subsequent token audience need = to have something that identifies the tenant so as to prevent the token fro= m being used by one tenant to illegitimately access resources at a differen= t tenant. I'll work on trying to improve that text to better explain al= l that.
=C2=A0

=C2=A0=C2=A0 Although multiple occurrences of the "resource" para= meter may be
=C2=A0 =C2=A0included in a request, using only a single "resource"= ; parameter is
=C2=A0 =C2=A0encouraged.=C2=A0 A bearer token that has multiple intended re= cipients
=C2=A0 =C2=A0(audiences) indicating that the token is valid at more than on= e
=C2=A0 =C2=A0protected resource can be used by any one of those protected =C2=A0 =C2=A0resources to access any of the other protected resources.=C2= =A0 Thus, a
=C2=A0 =C2=A0high degree of trust between the involved parties is needed wh= en
=C2=A0 =C2=A0using access tokens with multiple audiences.=C2=A0 Furthermore= an
=C2=A0 =C2=A0authorization server may be unwilling or unable to fulfill a t= oken
=C2=A0 =C2=A0request with multiple resources.

Do we want to contrast this with an authorization code/refresh token,
which may be more likely to be issued with a multiple-resource/audience
property?

Yeah, it's perhaps worth = making the distinction. Though I don't know that it needs to be explici= tly contrasted per se. I think just qualifying the text above to more speci= fically say "... parameter may be included in a token request" (a= s apposed to authorization request) would be enough to indicate that the su= ggestion is only applicable to the access token and not authorization code/= refresh token.
=C2=A0

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000004cab790591c27182-- From nobody Wed Sep 4 16:55:51 2019 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 503B7120815; Wed, 4 Sep 2019 16:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Gy6OB1LF0K0D; Wed, 4 Sep 2019 16:55:38 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 477BC12007A; Wed, 4 Sep 2019 16:55:38 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x84NtXbW019089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 4 Sep 2019 19:55:35 -0400 Date: Wed, 4 Sep 2019 18:55:32 -0500 From: Benjamin Kaduk To: Brian Campbell Cc: The IESG , draft-ietf-oauth-resource-indicators@ietf.org, oauth , oauth-chairs@ietf.org Message-ID: <20190904235531.GE78802@kduck.mit.edu> References: <156763159047.22689.9306520600745069059.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) 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: Wed, 04 Sep 2019 23:55:41 -0000 On Wed, Sep 04, 2019 at 05:19:27PM -0600, Brian Campbell wrote: > Thanks Ben, for the review and non-objectional ballot. > > On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-oauth-resource-indicators-05: No Objection > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Abstract > > > > This seems to be a sentence fragment (maybe preface with "This document > > specifies"?). > > > > Hrm. Yeah, I suppose so. I guess I was trying to be efficient with the > words but to the point of not having a complete sentence. I'll add that > preface. > > > > > Section 2.1 > > > > For authorization requests sent as a JWTs, such as when using JWT > > Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single > > "resource" parameter value is represented as a JSON string while > > multiple values are represented as an array of strings. > > > > jwsreq includes an example with "aud" in the request, yet this new > > "resource" request parameter is also intended to influence the audience > > of the resulting token. I'm not sure whether we need to say anything > > specifically about this in the document, but I'd like to have a better > > understanding of how "aud" and "resource" would interact when both > > present in the reqeust. > > (This is presumably related to why the request parameter is called > > "resource" and not "aud" or "audience", but unfortunately I seem to have > > zoned out for that part of the WG discussion.) > > > > In the context of a jwsreq request the "aud" indicates the intended > recipient/audience of the singed authorization request itself, which will > be the authorization server to whom the request is being made. This > prevents a singed request meant for AS1 from being used successfully at > AS2, for example. That "aud" does not do anything to influence the audience > of the resulting token - it's really just metadata of the signed request > that will be discarded once the singed request is validated. The "resource" > parameter of this document indicates where the client intends to use the > token its requesting, which can and will influence the audience of the > resulting token. So "aud" and "resource" do not interact when both present > in a signed authorization request. Ah, of course; thanks for the refresher, and that makes perfect sense. > And yes, this is related to why the request parameter is called "resource" > and not "aud" and also I think related to the outstanding discuss you have > on jwsreq. If this parameter were to have been called "aud" then there > would be a name collision when used in conjunction with jwsreq where "aud" > would have had two distinct and irreconcilable meanings at the same time. > There are a few other reasons the WG landed on "resource" as the name but > what you've alluded to up here was a big part of it. Agreed. > > > If the client omits the "resource" parameter when requesting > > authorization, the authorization server MAY process the request with > > no specific resource or by using a pre-defined default resource > > value. [...] > > > > Would/could this default value be global or on a per-scope basis or some > > other finer granularity than global? > > > > Yes, it could be any of those. Though I think most likely it'd be global or > influenced by scope. Really, it'd be whatever that AS was doing in the > absence of such a parameter before this document came along. Very true :) > > > > The > > authorization server might use this data to inform the user about the > > resources the client is going to access on her behalf, to meet policy > > decision (e.g. refuse the request due to unknown resources), and > > determine the set of resources that can be used in subsequent access > > token requests. > > > > nits: comma after "e.g.", and maybe s/meet policy decision/apply policy/ > > (or similar), and "to" before "determine" for parallelism. > > > > Okay, will do. > > > > > In Figure 1 we URL-encode the '.'s in "client.example.org" but not in > > "api.example.com" in the request URL; should we be consistent? (This > > seems to be recurring throughout the examples.) > > > > Shoot. I really do aim to be tighter with that kind of thing well before > getting to the IESG evaluation phase. I suspect some copy/paste/change work > along with not looking closely enough got the better of me here. I'll fix > to use not-encoded '.'s throughout. > > > > > Section 2.2 > > > > needs to know. This further improves privacy as scope values give an > > indication of what services the resource owner uses and downscoping a > > token to only that which is needed for a particular service can limit > > the extent to which such information is revealed across different > > services. As specified in Section 5.1 of [RFC6749], the > > > > (nit?) I suggest to s/scope values give an indication of what services > > the resource owner uses and/a list of scope values is an indication that > > the > > resource owner uses the multiple various services listed;/ since I > > misparsed it the first time as-is. > > > > Sure. Striving to avoid the ol' misparse is always good. > > > > > Section 3 > > > > An access token that is audience restricted to a protected resource > > that obtains that token legitimately cannot be used to access > > resources on behalf of the resource owner at other protected > > resources. The "resource" parameter enables a client to indicate the > > > > nit: This sentence has a pretty strange construction. I think the > > intent is to say that that a token, legitimately presented to a > > resource, cannot then be taken by that resource server and > > illegitimately present it somewhere else for access to other resources. > > But with the current wording we seem to be missing part of the part > > where some entity obtains the token with intent for illegitimate access. > > > > Yes, despite the pretty strange construction, you have the correct intent. > I'll work on improving that sentence (borrowing heavily from your words > there). > > > > > Some servers may host user content or be multi-tenant. In order to > > avoid attacks that might confuse a client into sending an access > > token to a resource that is user controlled or is owned by a > > different tenant, it is important to use a specific resource URI > > including a path component. This will cause any access token issued > > for accessing the user controlled resource to have an invalid > > audience if replayed against the legitimate resource API. > > > > I'm not entirely sure what this is trying to say. What is the > > "legitimate resource API"? Why would a token be issued for accessing a > > user-controlled resource if that's something we're trying to avoid > > having confused clients access? > > > > Um... so on rereading that I might say that it's also "pretty strange". > > What it was trying to somehow say is similar to the previous nit about > audience-restricted not being usable at the resource for whom the weren't > intended. But saying so in the context of a multi-tenant environment. > Basically it's trying to say that, in a multi-tenant environment, the > resource URI and subsequent token audience need to have something that > identifies the tenant so as to prevent the token from being used by one > tenant to illegitimately access resources at a different tenant. I'll work > on trying to improve that text to better explain all that. Ah, yes, that's a very good point to make. I'm happy to look at some draft text if you want. > > Although multiple occurrences of the "resource" parameter may be > > included in a request, using only a single "resource" parameter is > > encouraged. A bearer token that has multiple intended recipients > > (audiences) indicating that the token is valid at more than one > > protected resource can be used by any one of those protected > > resources to access any of the other protected resources. Thus, a > > high degree of trust between the involved parties is needed when > > using access tokens with multiple audiences. Furthermore an > > authorization server may be unwilling or unable to fulfill a token > > request with multiple resources. > > > > Do we want to contrast this with an authorization code/refresh token, > > which may be more likely to be issued with a multiple-resource/audience > > property? > > > > Yeah, it's perhaps worth making the distinction. Though I don't know that > it needs to be explicitly contrasted per se. I think just qualifying the > text above to more specifically say "... parameter may be included in a > token request" (as apposed to authorization request) would be enough to > indicate that the suggestion is only applicable to the access token and not > authorization code/refresh token. Sure; we don't need to overemphasize it. Thanks, Ben From nobody Wed Sep 4 17:18:11 2019 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 93AFE120147 for ; Wed, 4 Sep 2019 17:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 Sv9h3eYK_RTW for ; Wed, 4 Sep 2019 17:18:00 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 1400A120850 for ; Wed, 4 Sep 2019 17:18:00 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id j4so581093iog.11 for ; Wed, 04 Sep 2019 17:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ELOZNKJ3nw5nbgaB3TZNMDJUkqja2jzdHhnsSDj3S5o=; b=VHmMf2cKipV111emwOMXG8SqzbTJznw+VMZD28cl02Tb+eqBcqjNTK+h56ROV3xloS EkaQDs3o3Dp4a3HWthvmxpsR1Eu1SFmKaBEPUhgmbxLhYlvp0QXIp9MQkO/7ZMjgIePQ t3QoM+EJgQg44LhCAIulsR9JiTn4hsL9Yij8E= 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=ELOZNKJ3nw5nbgaB3TZNMDJUkqja2jzdHhnsSDj3S5o=; b=H5whSVJit3P+hsCrLd9R1VPQ7+wd+U3LYXDcSnB2mWf+nZBM6rtxd5L3VKwyV/kJQy FSWs2SRijORnWvP7EtI8dbIhJ5YszT8l1sAVY2FlpT2ho8GRuowAs3pquHAtMZ/zxuDE Qpz/gDaGlVwf5BkPD9omTODf5e2rwO3yMsHhNFcndOW65LphdMJV4aqnpABkbm77S4Fs Hyy9b0aPi/tF1yMNQXuuM+UgKjnJ8HVp6zHrxvS3co7SfHnbJvixY9mVRGufxY+Lhf1k gOfM3eoRV1XT8dKqWI9pPI9GFDt6IalpNA2bWRuJPS87GzLRcbWYAWVPoEls442KBg8N U9wA== X-Gm-Message-State: APjAAAUfhr4k/T4M/xGZEt3VvTg89ui3k8dcoGc4GqKNZWqzTspUXOk4 54uwlaQcCZTTrbyifXW/11cR/MAVnHYEsMyZQEkMKg0zvjpcZZopiyoplsHx9gbIPIJXncHiL6e rltAlNLrsD09uqQ== X-Google-Smtp-Source: APXvYqz7NAM8Bx3iCBcYrH8vESRzS12J7Yj4LGVOdH0U/+yOCWBgaNMwhi2p5oxyoe35osdB+apklwH9v2i8EMy/Uqc= X-Received: by 2002:a6b:7215:: with SMTP id n21mr938966ioc.238.1567642679219; Wed, 04 Sep 2019 17:17:59 -0700 (PDT) MIME-Version: 1.0 References: <156763159047.22689.9306520600745069059.idtracker@ietfa.amsl.com> <20190904235531.GE78802@kduck.mit.edu> In-Reply-To: <20190904235531.GE78802@kduck.mit.edu> From: Brian Campbell Date: Wed, 4 Sep 2019 18:17:32 -0600 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-oauth-resource-indicators@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000007b6fc0591c341ec" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) 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: Thu, 05 Sep 2019 00:18:03 -0000 --00000000000007b6fc0591c341ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 4, 2019 at 5:55 PM Benjamin Kaduk wrote: > On Wed, Sep 04, 2019 at 05:19:27PM -0600, Brian Campbell wrote: > > Thanks Ben, for the review and non-objectional ballot. > > > > On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker < > > noreply@ietf.org> wrote: > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-oauth-resource-indicators-05: No Objection > > > > > > Section 3 > > > > > > An access token that is audience restricted to a protected resourc= e > > > that obtains that token legitimately cannot be used to access > > > resources on behalf of the resource owner at other protected > > > resources. The "resource" parameter enables a client to indicate > the > > > > > > nit: This sentence has a pretty strange construction. I think the > > > intent is to say that that a token, legitimately presented to a > > > resource, cannot then be taken by that resource server and > > > illegitimately present it somewhere else for access to other resource= s. > > > But with the current wording we seem to be missing part of the part > > > where some entity obtains the token with intent for illegitimate > access. > > > > > > > Yes, despite the pretty strange construction, you have the correct > intent. > > I'll work on improving that sentence (borrowing heavily from your words > > there). > > > > > > > > > Some servers may host user content or be multi-tenant. In order t= o > > > avoid attacks that might confuse a client into sending an access > > > token to a resource that is user controlled or is owned by a > > > different tenant, it is important to use a specific resource URI > > > including a path component. This will cause any access token issu= ed > > > for accessing the user controlled resource to have an invalid > > > audience if replayed against the legitimate resource API. > > > > > > I'm not entirely sure what this is trying to say. What is the > > > "legitimate resource API"? Why would a token be issued for accessing= a > > > user-controlled resource if that's something we're trying to avoid > > > having confused clients access? > > > > > > > Um... so on rereading that I might say that it's also "pretty strange". > > > > What it was trying to somehow say is similar to the previous nit about > > audience-restricted not being usable at the resource for whom the weren= 't > > intended. But saying so in the context of a multi-tenant environment. > > Basically it's trying to say that, in a multi-tenant environment, the > > resource URI and subsequent token audience need to have something that > > identifies the tenant so as to prevent the token from being used by one > > tenant to illegitimately access resources at a different tenant. I'll > work > > on trying to improve that text to better explain all that. > > Ah, yes, that's a very good point to make. I'm happy to look at some dra= ft > text if you want. > Thanks, here's what I've got now for this and the previous item in sec 3. Suggestions welcome. 3. Security Considerations An audience-restricted access token, legitimately presented to a resource, cannot then be taken by that resource to present it elsewhere for illegitimate access to other resources. The "resource" parameter enables a client to indicate the protected resources where the requested access token will be used, which in turn enables the authorization server to apply the appropriate audience restrictions to the token. Some servers may host user content or be multi-tenant. In order to avoid attacks where one tenant uses an access token to illegitimately access resources owned by a different tenant, it is important to use a specific resource URI including any portion of the URI that identifies the tenant, such as a path component. This will allow access tokens to be audience-restricted in a way that identifies the tenant and prevent their use, due to an invalid audience, at resources owned by a different tenant. --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000007b6fc0591c341ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 4, 2019 at 5:55 PM Benjam= in Kaduk <kaduk@mit.edu> wrote:<= br>
On Wed, Sep 04, = 2019 at 05:19:27PM -0600, Brian Campbell wrote:
> Thanks Ben, for the review and non-objectional ballot.
>
> On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker <
> noreply@ietf.org= > wrote:
>
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-resource-indicators-05: No Objection
> >= ;
> > Section 3
> >
> >=C2=A0 =C2=A0 An access token that is audience restricted to a pro= tected resource
> >=C2=A0 =C2=A0 that obtains that token legitimately cannot be used = to access
> >=C2=A0 =C2=A0 resources on behalf of the resource owner at other p= rotected
> >=C2=A0 =C2=A0 resources.=C2=A0 The "resource" parameter = enables a client to indicate the
> >
> > nit: This sentence has a pretty strange construction.=C2=A0 I thi= nk the
> > intent is to say that that a token, legitimately presented to a > > resource, cannot then be taken by that resource server and
> > illegitimately present it somewhere else for access to other reso= urces.
> > But with the current wording we seem to be missing part of the pa= rt
> > where some entity obtains the token with intent for illegitimate = access.
> >
>
> Yes, despite the pretty strange construction, you have the correct int= ent.
> I'll work on improving that sentence (borrowing heavily from your = words
> there).
>
>
>
> >=C2=A0 =C2=A0 Some servers may host user content or be multi-tenan= t.=C2=A0 In order to
> >=C2=A0 =C2=A0 avoid attacks that might confuse a client into sendi= ng an access
> >=C2=A0 =C2=A0 token to a resource that is user controlled or is ow= ned by a
> >=C2=A0 =C2=A0 different tenant, it is important to use a specific = resource URI
> >=C2=A0 =C2=A0 including a path component.=C2=A0 This will cause an= y access token issued
> >=C2=A0 =C2=A0 for accessing the user controlled resource to have a= n invalid
> >=C2=A0 =C2=A0 audience if replayed against the legitimate resource= API.
> >
> > I'm not entirely sure what this is trying to say.=C2=A0 What = is the
> > "legitimate resource API"?=C2=A0 Why would a token be i= ssued for accessing a
> > user-controlled resource if that's something we're trying= to avoid
> > having confused clients access?
> >
>
> Um... so on rereading that I might say that it's also "pretty= strange".
>
> What it was trying to somehow say is similar to the previous nit about=
> audience-restricted not being usable at the resource for whom the were= n't
> intended. But saying so in the context of a multi-tenant environment.<= br> > Basically it's trying to say that, in a multi-tenant environment, = the
> resource URI and subsequent token audience need to have something that=
> identifies the tenant so as to prevent the token from being used by on= e
> tenant to illegitimately access resources at a different tenant. I'= ;ll work
> on trying to improve that text to better explain all that.

Ah, yes, that's a very good point to make.=C2=A0 I'm happy to look = at some draft
text if you want.

Thanks, here's wh= at I've got now for this and the previous item in sec 3. Suggestions we= lcome.

3.=C2=A0 Security Considerations

=C2=A0 =C2=A0An aud= ience-restricted access token, legitimately presented to a
=C2=A0 =C2=A0= resource, cannot then be taken by that resource to present it
=C2=A0 =C2= =A0elsewhere for illegitimate access to other resources.=C2=A0 The "re= source"
=C2=A0 =C2=A0parameter enables a client to indicate the pro= tected resources where
=C2=A0 =C2=A0the requested access token will be u= sed, which in turn enables the
=C2=A0 =C2=A0authorization server to appl= y the appropriate audience restrictions
=C2=A0 =C2=A0to the token.
=C2=A0 =C2=A0Some servers may host user content or be multi-tenant.=C2=A0= In order to
=C2=A0 =C2=A0avoid attacks where one tenant uses an access = token to illegitimately
=C2=A0 =C2=A0access resources owned by a differe= nt tenant, it is important to use
=C2=A0 =C2=A0a specific resource URI i= ncluding any portion of the URI that
=C2=A0 =C2=A0identifies the tenant,= such as a path component.=C2=A0 This will allow
=C2=A0 =C2=A0access tok= ens to be audience-restricted in a way that identifies the
=C2=A0 =C2=A0= tenant and prevent their use, due to an invalid audience, at
=C2=A0 =C2= =A0resources owned by a different tenant.

=C2=A0

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000007b6fc0591c341ec-- From nobody Thu Sep 5 08:03:34 2019 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 32FA2120105 for ; Thu, 5 Sep 2019 08:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 y4erTkSxxY_M for ; Thu, 5 Sep 2019 08:03:28 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 8BF2D120288 for ; Thu, 5 Sep 2019 08:03:17 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id x4so5489395iog.13 for ; Thu, 05 Sep 2019 08:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JbgxKY8sUtz/J2mjxjzzkWmJhZFFclCeVKMYEx1hElg=; b=OzxgMuKae1mqLJz9G/PvGYnR20RM8zefLcSGT2Kx3fXYpU7WDFzDhZWVA0bfC68mSo upOyvauOJ+PlM/cXmu470Ka9RqtjqH5uxjQV/vxQNCsFX9weUC5M/uI4blas+9b5LulP +d6ORJSuoYx+GQn9gidNfYyQBXXrHHPsbKbHBd2ExCVpJbjyo/iQkmcGfRH6Tyw7q2Lh hug1t+ZBtNApFTjIK2l7Y1iBz7D5niqaft3jmXRW043ewYdB5kWFTEOPqdwr832eANHi KMHVANJqPUIECxiHShH39FggRSFkRRgko6TdsoppI+GfhXYeZJ0Zy/sc37af5Q/JR2u7 M9ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JbgxKY8sUtz/J2mjxjzzkWmJhZFFclCeVKMYEx1hElg=; b=F9Nmp3Nakw5UPRg9cy9QLiG8RTNSMOEakWifB3duSwhZQ30c2/NulluVS0fayods70 YH8kklTsIjuF47adI0l6cEehFzhw3Uu4Y0TlYrYkEvIQDH2WuBc16rmQwaqkCQOtxtbi ec9fiQoGLgK2JboUnOR3Z+bb4Ft2OT9b8KX/39nKny6Z+EEfVGtJr5aOpD+3FHzFRTGF tkBg6dDr8wqcMC82FXNZXIMjtDD+7N91+I23iAKSx80zJXosnWsGiefvv4+4INEOl38F 4HIHqBNfthKqZuTcd6GJ6DiuvwP7kge0auP8Z1zOBjWl6YnwspitvQklJ+jDM9SIOIh5 sDBg== X-Gm-Message-State: APjAAAVdwiFoUD9Tq6UY/K1NndbUSsLhK6u4HE9/+JEejKOnTzRvSL+b eROood8dOGyKkbx77mW7Q+UGMOXzYyERuKz2mspsEvCG X-Google-Smtp-Source: APXvYqy0CzNjcl9LXzTKmX4Tl0IjenFD3+MAqARhYaCeZWr/VdlXbq1AA4c17gagvCcQjMeDw44kqEKCQ5vTRUhIu0Q= X-Received: by 2002:a02:c645:: with SMTP id k5mr4818264jan.116.1567695796423; Thu, 05 Sep 2019 08:03:16 -0700 (PDT) MIME-Version: 1.0 From: Vanessa Andor Date: Thu, 5 Sep 2019 10:03:04 -0500 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000000fd4840591cf9f4b" Archived-At: Subject: [OAUTH-WG] (no subject) 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: Thu, 05 Sep 2019 15:03:32 -0000 --0000000000000fd4840591cf9f4b Content-Type: text/plain; charset="UTF-8" "Help" --0000000000000fd4840591cf9f4b Content-Type: text/html; charset="UTF-8"
"Help"
--0000000000000fd4840591cf9f4b-- From nobody Thu Sep 5 08:18:07 2019 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 16CC01208A9 for ; Thu, 5 Sep 2019 08:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 1vuoDtG5oA5z for ; Thu, 5 Sep 2019 08:17:50 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 8BA4F1208B5 for ; Thu, 5 Sep 2019 08:17:50 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id f4so4950309ion.2 for ; Thu, 05 Sep 2019 08:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OWil0E6E66YMcstWDtwiV2JUXq+rMC+PY2R42ZZX/E0=; b=vPS05UpnKhSWZw+pUcI5HV9CV8NbiL+JhKrPu1iaDkHZBvWjLNXEg7n3y+f97VBSuK 1QYzvln5rNws78gqhllDXHu71L9RKV9t5tdAY9w0cLMct3Qn9K79tvULphHa6QNZXs2K mFEexkSOJfu+ls776S5U9VpxWDTi0detMWv7+/07JH6h4qq2Tc3XMg8wVWno9CJfqr8a HjfJV5WaFuI8DhOtlN5T7AEZAZMxSel0VYPms7+VHgVXd80j3QiL1xq04q8FzKUIzde+ p8R78vJag6RbXcGcwuMoVN0p2KuzhU+BRbeUMfVp5SFmZnpAHVtjsEKF4xK0Ew0mAs+Q hv5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OWil0E6E66YMcstWDtwiV2JUXq+rMC+PY2R42ZZX/E0=; b=eoFBeu3m7jTODCzeBYnK91b0uIpvLewqvTAMjCYvpI2/lsN0Tg75g7uV0OOuYFVl/Q rCHQqlaVYIJDhRzTIbfov1q2yKeRbAN3TY4+0cJVXZgb0L2QqlJDkTe0O9eHCeVmSHxD YLNNvfC9Uvq74T9hZbJoGVet4i0jUYP1/kbaCvaqfxdhl34CL2qL5IFidn+gPSTsXbzt ubOntouBCa3RJ5kdQ6YTxIg7mgnbqbh9zgpGHX6Ddjp4t31/g2qMuU57mVPKYFcwzi1S AfTb6mV31DVsB1iMblCNekEp7X1VBAMOxLZQY2ihNdagaj42ww1YjOPVG9fYaSVkl4Qa Gtuw== X-Gm-Message-State: APjAAAXw1aDfbyPYWVBnhlBc57PcJAAPyXPAg4Dj4uDM/z9v5QRHAxsc ZrfQTWMzKfx9aM8n1Xtw73ZdiAiXG+vQCow7CgfOIy6H X-Google-Smtp-Source: APXvYqy7nTZx3bFlrLg3CD4bRbAz1fmNkUDikB9ZDhUOmykghncj9cbyhe+sm14qQUjAozUHEfXCew5xDem1t2zoPv4= X-Received: by 2002:a5e:c311:: with SMTP id a17mr4683387iok.140.1567696669501; Thu, 05 Sep 2019 08:17:49 -0700 (PDT) MIME-Version: 1.0 From: Vanessa Andor Date: Thu, 5 Sep 2019 10:17:37 -0500 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000019f1640591cfd334" Archived-At: Subject: [OAUTH-WG] Help 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: Thu, 05 Sep 2019 15:17:59 -0000 --00000000000019f1640591cfd334 Content-Type: text/plain; charset="UTF-8" 1. Re: Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) (Benjamin Kaduk) 2. Re: Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) (Brian Campbell) 3. (no subject) (Vanessa Andor) --00000000000019f1640591cfd334 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=C2=A0 =C2=A01. Re: Be= njamin Kaduk's No Objection on
=C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-resource-indicators-05: (with COMMENT)=C2=A0 =C2=A0 =C2=A0 (Benjamin Kaduk)
=C2=A0 =C2=A02. Re: Benjamin Kaduk'= s No Objection on
=C2=A0 =C2=A0 = =C2=A0 draft-ietf-oauth-resource-indicators-05: (with COMMENT)
=C2=A0 =C2=A0 =C2=A0 (Brian Campbell)
=C2=A0 =C2=A03. (no subject) (Vanessa Andor) --00000000000019f1640591cfd334-- From nobody Thu Sep 5 08:28:14 2019 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 67075120828 for ; Thu, 5 Sep 2019 08:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 w9PI8gG_-cNH for ; Thu, 5 Sep 2019 08:28:06 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 3D05012021C for ; Thu, 5 Sep 2019 08:28:06 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id y19so3310438wrd.3 for ; Thu, 05 Sep 2019 08:28:06 -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; bh=mEtXr0a00N3w2QQrCO1uAb4KkX9dKSP9UTND1jyxZ1k=; b=f4ApjG30KxaXZJRASY3mGpL0BQz/ODlEXv+4PzqzXy1E1iIJfFtfu7bKxxArx/kWY3 iga4XQXGmoz1CR5Z5FQWiLf5PonUB2RghWCnOPXofQIdKVZ+PyzFOnQu6W12J/DEM4kA eIrDp07mRupXEhkTtiDM82MfUTRb/gi7jGx7KwB3Gaa9S9hGJIl2K/6UI/vvoGP5b2eV CAD5XtVwPPQP3JKJSPo4rAIO2f5c9eFI+jrFEh52rPGUCpGw29HYBuo8WAxKEVTDzbPW yewBZ2E43sOy3xDZ9Y9oVfH/D58zVKI1GfgjPNPte960TBmnkOe6ddaFYzV4zRXBXQIl lxtQ== 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; bh=mEtXr0a00N3w2QQrCO1uAb4KkX9dKSP9UTND1jyxZ1k=; b=cDvg/W880szD4VZOu20jzSnRJysB9Rka7kmmu4+aPfeaQAzEosrX7zN18Xqt4v1WrM ehJC+UXgohMhkTJk9FlvKNvnDoQ/fL4mcR4aJRFJEMXac+eKTDYfrkdUswuWrKUAQ5np qMFSBczO86M4Ks9hEh4xOkaWJvXbsebMvkQKJ0q2TFITxNcw6Wfi9YBfrEarXSqYu0pS lKl8sV+D/EdWXpgQO7eQAWvixJfl2Y0jbH7HfxVoSp0eVzUGQrqzLv8iY9uFzZp0wOpE Y5pAAad3sT1EYVZKoC2dFHn+MZFXoz6VR48AMjCbJYbiS5yCfQsP7LRtAsdUD5HWOApj qOFw== X-Gm-Message-State: APjAAAXsi8vBsdl/pD936wk5bSCVV3o6XWIhiqXb+0Jg+EziM3NNpsGC x8pXyAhwCWlcwsT+9GxRR3R+k2G+BtmFoPq8kuHGJDC7 X-Google-Smtp-Source: APXvYqxmrIwMUMSRjz+58jv1DsuqQjhQxvtYQaNr1kLtCvCRblYu/SPE+GqX0qZxqyL7T+hCTS6Rbyub4ZUn4n07d8s= X-Received: by 2002:a5d:4402:: with SMTP id z2mr2763884wrq.183.1567697284584; Thu, 05 Sep 2019 08:28:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Thu, 5 Sep 2019 11:27:53 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000c35a5d0591cff755" Archived-At: Subject: Re: [OAUTH-WG] Help 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: Thu, 05 Sep 2019 15:28:08 -0000 --000000000000c35a5d0591cff755 Content-Type: text/plain; charset="UTF-8" I have unsubscribed and banned this person from the list. Regards, Rifaat On Thu, Sep 5, 2019 at 11:18 AM Vanessa Andor wrote: > > 1. Re: Benjamin Kaduk's No Objection on > draft-ietf-oauth-resource-indicators-05: (with COMMENT) > (Benjamin Kaduk) > 2. Re: Benjamin Kaduk's No Objection on > draft-ietf-oauth-resource-indicators-05: (with COMMENT) > (Brian Campbell) > 3. (no subject) (Vanessa Andor) > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000c35a5d0591cff755 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have unsubscribed and banned this person from the list.<= div>
Regards,
=C2=A0Rifaat


On T= hu, Sep 5, 2019 at 11:18 AM Vanessa Andor <nessandorae@gmail.com> wrote:

=C2=A0 =C2=A01. Re: Benjamin Kaduk's No Objection on<= br style=3D"font-family:sans-serif;font-size:12.8px">=C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-res= ource-indica= tors-05: (with COMMENT)
=C2=A0 =C2= =A0 =C2=A0 (Benjamin Kaduk)
=C2=A0= =C2=A02. Re: Benjamin Kaduk's No Objection on
=C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-resource-indi= cators-05: (with CO= MMENT)
=C2=A0 =C2=A0 =C2=A0 (Brian= Campbell)
=C2=A0 =C2=A03. (no sub= ject) (Vanessa Andor)
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000c35a5d0591cff755-- From nobody Thu Sep 5 10:53:39 2019 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 DD2BA1200D6; Thu, 5 Sep 2019 10:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 MncAWKjN5kPO; Thu, 5 Sep 2019 10:53:27 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 6FC35120048; Thu, 5 Sep 2019 10:53:27 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x85HrLEi019517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Sep 2019 13:53:23 -0400 Date: Thu, 5 Sep 2019 12:53:20 -0500 From: Benjamin Kaduk To: Brian Campbell Cc: The IESG , draft-ietf-oauth-resource-indicators@ietf.org, oauth , oauth-chairs@ietf.org Message-ID: <20190905175320.GL78802@kduck.mit.edu> References: <156763159047.22689.9306520600745069059.idtracker@ietfa.amsl.com> <20190904235531.GE78802@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) 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: Thu, 05 Sep 2019 17:53:30 -0000 On Wed, Sep 04, 2019 at 06:17:32PM -0600, Brian Campbell wrote: > On Wed, Sep 4, 2019 at 5:55 PM Benjamin Kaduk wrote: > > > On Wed, Sep 04, 2019 at 05:19:27PM -0600, Brian Campbell wrote: > > > Thanks Ben, for the review and non-objectional ballot. > > > > > > On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker < > > > noreply@ietf.org> wrote: > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-oauth-resource-indicators-05: No Objection > > > > > > > > Section 3 > > > > > > > > An access token that is audience restricted to a protected resource > > > > that obtains that token legitimately cannot be used to access > > > > resources on behalf of the resource owner at other protected > > > > resources. The "resource" parameter enables a client to indicate > > the > > > > > > > > nit: This sentence has a pretty strange construction. I think the > > > > intent is to say that that a token, legitimately presented to a > > > > resource, cannot then be taken by that resource server and > > > > illegitimately present it somewhere else for access to other resources. > > > > But with the current wording we seem to be missing part of the part > > > > where some entity obtains the token with intent for illegitimate > > access. > > > > > > > > > > Yes, despite the pretty strange construction, you have the correct > > intent. > > > I'll work on improving that sentence (borrowing heavily from your words > > > there). > > > > > > > > > > > > > Some servers may host user content or be multi-tenant. In order to > > > > avoid attacks that might confuse a client into sending an access > > > > token to a resource that is user controlled or is owned by a > > > > different tenant, it is important to use a specific resource URI > > > > including a path component. This will cause any access token issued > > > > for accessing the user controlled resource to have an invalid > > > > audience if replayed against the legitimate resource API. > > > > > > > > I'm not entirely sure what this is trying to say. What is the > > > > "legitimate resource API"? Why would a token be issued for accessing a > > > > user-controlled resource if that's something we're trying to avoid > > > > having confused clients access? > > > > > > > > > > Um... so on rereading that I might say that it's also "pretty strange". > > > > > > What it was trying to somehow say is similar to the previous nit about > > > audience-restricted not being usable at the resource for whom the weren't > > > intended. But saying so in the context of a multi-tenant environment. > > > Basically it's trying to say that, in a multi-tenant environment, the > > > resource URI and subsequent token audience need to have something that > > > identifies the tenant so as to prevent the token from being used by one > > > tenant to illegitimately access resources at a different tenant. I'll > > work > > > on trying to improve that text to better explain all that. > > > > Ah, yes, that's a very good point to make. I'm happy to look at some draft > > text if you want. > > > > Thanks, here's what I've got now for this and the previous item in sec 3. > Suggestions welcome. > > 3. Security Considerations > > An audience-restricted access token, legitimately presented to a > resource, cannot then be taken by that resource to present it > elsewhere for illegitimate access to other resources. The "resource" I think "by that resource and presented elsewhere" probbaly has a more parallel flow. > parameter enables a client to indicate the protected resources where > the requested access token will be used, which in turn enables the > authorization server to apply the appropriate audience restrictions > to the token. > > Some servers may host user content or be multi-tenant. In order to > avoid attacks where one tenant uses an access token to illegitimately > access resources owned by a different tenant, it is important to use > a specific resource URI including any portion of the URI that > identifies the tenant, such as a path component. This will allow > access tokens to be audience-restricted in a way that identifies the > tenant and prevent their use, due to an invalid audience, at > resources owned by a different tenant. But other than the above nit, this all looks really good; thank you! -Ben From nobody Thu Sep 5 11:43:50 2019 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 606A412090D for ; Thu, 5 Sep 2019 11:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=pingidentity.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 8Jfjfyru_JPU for ; Thu, 5 Sep 2019 11:43:47 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 D601612011A for ; Thu, 5 Sep 2019 11:43:46 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id b136so7113508iof.3 for ; Thu, 05 Sep 2019 11:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pHkxI+GwqpYT2PzbsB2qjqESFZCNiX8wprIHxUUXNPU=; b=IAc/OxT5unckV0PNQETcggECohje2MpQpNYITwxfLvKVHvFc0NaTa2zXGzePqckALn Qugx0YTw+p2nfX9kMGGBTLIdtyc63MKKjAzKRVMYaJ/w6jAP7Ui3tIPDCGneMc2QouAF i6NlOnraIlun3wwWeVCyL5zuNyLNKh/eZPOZo= 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=pHkxI+GwqpYT2PzbsB2qjqESFZCNiX8wprIHxUUXNPU=; b=UflTiZEDS0kXh8k6ESv5RbI5fRPOe+ILGxov2ecW0yWfkSRId3FpATbegNLZqYYcti XlsmLpN9VgfrO46zczACGUuQqofdg3ycljhOx9MfgGRUkGYTPkfw/Bp+uo9UUD80Bon0 H2FELtoeXfM6r9aiHMv38qmsOFjp7ZDBuiXZ8+6L+ChrKrhBQxbC/hOUGMfnIbFKOE6H z/jVo/9cLl9qcOzIoL4bRhmScIy0jaJd4p9oxmm/OsHuPL9SfowWuQYWda8Kyxkofja5 ero+xiLl4ddNprKBLGIbuDGigfNmC14hFJENYAoQ5L4huacXj0nyuRZ2wCvcjyYp9Fqk LsrA== X-Gm-Message-State: APjAAAUm8HzQt4zxzLc0EmIxEaQW9EqI5PwlX+Q1Zkf4gx+GNbKcyBG1 cW7BOaMADsRwxsjusjhpuM+eAVNwBd4LGQjBjxyygsobeCLkcflECafRhQtoeAhQWIQOqa+HFmF UBzj4yGSaDBNNlA== X-Google-Smtp-Source: APXvYqycpXHT9N7eCaM76zxKH4g3vbGGaXtQNJsMppp+bwe/QtGK8OJ9N693jBK9Tv7RQfpjnuObpXUpwyq2uCwFA40= X-Received: by 2002:a6b:b494:: with SMTP id d142mr2139293iof.156.1567709026089; Thu, 05 Sep 2019 11:43:46 -0700 (PDT) MIME-Version: 1.0 References: <156763159047.22689.9306520600745069059.idtracker@ietfa.amsl.com> <20190904235531.GE78802@kduck.mit.edu> <20190905175320.GL78802@kduck.mit.edu> In-Reply-To: <20190905175320.GL78802@kduck.mit.edu> From: Brian Campbell Date: Thu, 5 Sep 2019 12:43:19 -0600 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-oauth-resource-indicators@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000009c989a0591d2b38c" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) 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: Thu, 05 Sep 2019 18:43:49 -0000 --0000000000009c989a0591d2b38c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable thanks and done On Thu, Sep 5, 2019 at 11:53 AM Benjamin Kaduk wrote: > On Wed, Sep 04, 2019 at 06:17:32PM -0600, Brian Campbell wrote: > > On Wed, Sep 4, 2019 at 5:55 PM Benjamin Kaduk wrote: > > > > > On Wed, Sep 04, 2019 at 05:19:27PM -0600, Brian Campbell wrote: > > > > Thanks Ben, for the review and non-objectional ballot. > > > > > > > > On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker < > > > > noreply@ietf.org> wrote: > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > draft-ietf-oauth-resource-indicators-05: No Objection > > > > > > > > > > Section 3 > > > > > > > > > > An access token that is audience restricted to a protected > resource > > > > > that obtains that token legitimately cannot be used to access > > > > > resources on behalf of the resource owner at other protected > > > > > resources. The "resource" parameter enables a client to > indicate > > > the > > > > > > > > > > nit: This sentence has a pretty strange construction. I think th= e > > > > > intent is to say that that a token, legitimately presented to a > > > > > resource, cannot then be taken by that resource server and > > > > > illegitimately present it somewhere else for access to other > resources. > > > > > But with the current wording we seem to be missing part of the pa= rt > > > > > where some entity obtains the token with intent for illegitimate > > > access. > > > > > > > > > > > > > Yes, despite the pretty strange construction, you have the correct > > > intent. > > > > I'll work on improving that sentence (borrowing heavily from your > words > > > > there). > > > > > > > > > > > > > > > > > Some servers may host user content or be multi-tenant. In > order to > > > > > avoid attacks that might confuse a client into sending an acce= ss > > > > > token to a resource that is user controlled or is owned by a > > > > > different tenant, it is important to use a specific resource U= RI > > > > > including a path component. This will cause any access token > issued > > > > > for accessing the user controlled resource to have an invalid > > > > > audience if replayed against the legitimate resource API. > > > > > > > > > > I'm not entirely sure what this is trying to say. What is the > > > > > "legitimate resource API"? Why would a token be issued for > accessing a > > > > > user-controlled resource if that's something we're trying to avoi= d > > > > > having confused clients access? > > > > > > > > > > > > > Um... so on rereading that I might say that it's also "pretty > strange". > > > > > > > > What it was trying to somehow say is similar to the previous nit > about > > > > audience-restricted not being usable at the resource for whom the > weren't > > > > intended. But saying so in the context of a multi-tenant environmen= t. > > > > Basically it's trying to say that, in a multi-tenant environment, t= he > > > > resource URI and subsequent token audience need to have something > that > > > > identifies the tenant so as to prevent the token from being used by > one > > > > tenant to illegitimately access resources at a different tenant. I'= ll > > > work > > > > on trying to improve that text to better explain all that. > > > > > > Ah, yes, that's a very good point to make. I'm happy to look at some > draft > > > text if you want. > > > > > > > Thanks, here's what I've got now for this and the previous item in sec = 3. > > Suggestions welcome. > > > > 3. Security Considerations > > > > An audience-restricted access token, legitimately presented to a > > resource, cannot then be taken by that resource to present it > > elsewhere for illegitimate access to other resources. The "resource= " > > I think "by that resource and presented elsewhere" probbaly has a more > parallel flow. > > > parameter enables a client to indicate the protected resources where > > the requested access token will be used, which in turn enables the > > authorization server to apply the appropriate audience restrictions > > to the token. > > > > Some servers may host user content or be multi-tenant. In order to > > avoid attacks where one tenant uses an access token to illegitimatel= y > > access resources owned by a different tenant, it is important to use > > a specific resource URI including any portion of the URI that > > identifies the tenant, such as a path component. This will allow > > access tokens to be audience-restricted in a way that identifies the > > tenant and prevent their use, due to an invalid audience, at > > resources owned by a different tenant. > > But other than the above nit, this all looks really good; thank you! > > -Ben > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000009c989a0591d2b38c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
thanks and done

<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 5, 2019 at 11:53 AM Benjam= in Kaduk <kaduk@mit.edu> wrote:<= br>
On Wed, Sep 04, = 2019 at 06:17:32PM -0600, Brian Campbell wrote:
> On Wed, Sep 4, 2019 at 5:55 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> > On Wed, Sep 04, 2019 at 05:19:27PM -0600, Brian Campbell wrote: > > > Thanks Ben, for the review and non-objectional ballot.
> > >
> > > On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracke= r <
> > > norepl= y@ietf.org> wrote:
> > >
> > > > Benjamin Kaduk has entered the following ballot positio= n for
> > > > draft-ietf-oauth-resource-indicators-05: No Objection > > > >
> > > > Section 3
> > > >
> > > >=C2=A0 =C2=A0 An access token that is audience restricte= d to a protected resource
> > > >=C2=A0 =C2=A0 that obtains that token legitimately canno= t be used to access
> > > >=C2=A0 =C2=A0 resources on behalf of the resource owner = at other protected
> > > >=C2=A0 =C2=A0 resources.=C2=A0 The "resource" = parameter enables a client to indicate
> > the
> > > >
> > > > nit: This sentence has a pretty strange construction.= =C2=A0 I think the
> > > > intent is to say that that a token, legitimately presen= ted to a
> > > > resource, cannot then be taken by that resource server = and
> > > > illegitimately present it somewhere else for access to = other resources.
> > > > But with the current wording we seem to be missing part= of the part
> > > > where some entity obtains the token with intent for ill= egitimate
> > access.
> > > >
> > >
> > > Yes, despite the pretty strange construction, you have the c= orrect
> > intent.
> > > I'll work on improving that sentence (borrowing heavily = from your words
> > > there).
> > >
> > >
> > >
> > > >=C2=A0 =C2=A0 Some servers may host user content or be m= ulti-tenant.=C2=A0 In order to
> > > >=C2=A0 =C2=A0 avoid attacks that might confuse a client = into sending an access
> > > >=C2=A0 =C2=A0 token to a resource that is user controlle= d or is owned by a
> > > >=C2=A0 =C2=A0 different tenant, it is important to use a= specific resource URI
> > > >=C2=A0 =C2=A0 including a path component.=C2=A0 This wil= l cause any access token issued
> > > >=C2=A0 =C2=A0 for accessing the user controlled resource= to have an invalid
> > > >=C2=A0 =C2=A0 audience if replayed against the legitimat= e resource API.
> > > >
> > > > I'm not entirely sure what this is trying to say.= =C2=A0 What is the
> > > > "legitimate resource API"?=C2=A0 Why would a = token be issued for accessing a
> > > > user-controlled resource if that's something we'= ;re trying to avoid
> > > > having confused clients access?
> > > >
> > >
> > > Um... so on rereading that I might say that it's also &q= uot;pretty strange".
> > >
> > > What it was trying to somehow say is similar to the previous= nit about
> > > audience-restricted not being usable at the resource for who= m the weren't
> > > intended. But saying so in the context of a multi-tenant env= ironment.
> > > Basically it's trying to say that, in a multi-tenant env= ironment, the
> > > resource URI and subsequent token audience need to have some= thing that
> > > identifies the tenant so as to prevent the token from being = used by one
> > > tenant to illegitimately access resources at a different ten= ant. I'll
> > work
> > > on trying to improve that text to better explain all that. > >
> > Ah, yes, that's a very good point to make.=C2=A0 I'm happ= y to look at some draft
> > text if you want.
> >
>
> Thanks, here's what I've got now for this and the previous ite= m in sec 3.
> Suggestions welcome.
>
> 3.=C2=A0 Security Considerations
>
>=C2=A0 =C2=A0 An audience-restricted access token, legitimately present= ed to a
>=C2=A0 =C2=A0 resource, cannot then be taken by that resource to presen= t it
>=C2=A0 =C2=A0 elsewhere for illegitimate access to other resources.=C2= =A0 The "resource"

I think "by that resource and presented elsewhere" probbaly has a= more
parallel flow.

>=C2=A0 =C2=A0 parameter enables a client to indicate the protected reso= urces where
>=C2=A0 =C2=A0 the requested access token will be used, which in turn en= ables the
>=C2=A0 =C2=A0 authorization server to apply the appropriate audience re= strictions
>=C2=A0 =C2=A0 to the token.
>
>=C2=A0 =C2=A0 Some servers may host user content or be multi-tenant.=C2= =A0 In order to
>=C2=A0 =C2=A0 avoid attacks where one tenant uses an access token to il= legitimately
>=C2=A0 =C2=A0 access resources owned by a different tenant, it is impor= tant to use
>=C2=A0 =C2=A0 a specific resource URI including any portion of the URI = that
>=C2=A0 =C2=A0 identifies the tenant, such as a path component.=C2=A0 Th= is will allow
>=C2=A0 =C2=A0 access tokens to be audience-restricted in a way that ide= ntifies the
>=C2=A0 =C2=A0 tenant and prevent their use, due to an invalid audience,= at
>=C2=A0 =C2=A0 resources owned by a different tenant.

But other than the above nit, this all looks really good; thank you!

-Ben

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000009c989a0591d2b38c-- From nobody Thu Sep 5 11:45:26 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CA71200F3; Thu, 5 Sep 2019 11:45:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156770912413.505.12375768155797891488@ietfa.amsl.com> Date: Thu, 05 Sep 2019 11:45:24 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2019 18:45:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Resource Indicators for OAuth 2.0 Authors : Brian Campbell John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-resource-indicators-06.txt Pages : 14 Date : 2019-09-05 Abstract: This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-06 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-resource-indicators-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 5 11:54:16 2019 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 6489D120B1A for ; Thu, 5 Sep 2019 11:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 lwb7bwrtkZ_v for ; Thu, 5 Sep 2019 11:53:22 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 4578F120B17 for ; Thu, 5 Sep 2019 11:53:22 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id p12so7154214iog.5 for ; Thu, 05 Sep 2019 11:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oWxODQulfvcd/LI9gmeffSkcW1iT+HdB/BMXxko9JDU=; b=TKFJ71mu23CRvRZZg5V5AoBgt3v+Wrv0S4eWHlRrLlEBLgkhY3VGQ7AH6efgOqVvW5 DE/qdKGoYDqz3zkhaWFOBe40zA1mRUXVtN8gfAdQ/HOa8D5F4oGXJqPBwa0H2ef3IPeJ rA4Eq8N8eFl14HRtEAKpQYYWlBCciaePEU2Ro= 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; bh=oWxODQulfvcd/LI9gmeffSkcW1iT+HdB/BMXxko9JDU=; b=ozLnKmqt7ug8NfeydZiokcnud9ar0svrzqY5T3wixn4x4+omaOz6kJ9n1dZUg5FDSM OTlEU5z8zuvxxF+JtU/4B/pciDdfluRLV2+7/gDVn/SW7rkvXAia2c2B1SyLKkdloWOw JEnmZdyz0z4o6cos8wDKeF2lnN3WXtCwqlEF1ZmwnX7n0OOTpZKTt2aKbrY2oaS1WwO1 7baYj7hcZMXkyXY2WsNwMGl0/VlSFO6InvABaVY47Lq1vGIzeFlPFcWHXO5+8zAJANNC FNhMN19ROImX9Tfde4CjEDZnIj6ATcN5ijEH5Ykx9cp7aDNlPBqPik16oix8StV+V3dF 1/Fw== X-Gm-Message-State: APjAAAVqEBcKHf3fGVp8jPMu9vyOJH2xbth+FSW2SiLGKaLHgxuQ0fTW u6a7qw7uWmBEf4kX0QrFGGSFbeddmfoHsEe3NAz6foY6VTATQNj+XH26Y40gkMwprFgwANez7pO n3HxCkYkKyYAxAbZ0 X-Google-Smtp-Source: APXvYqx4gZF8LAtfvzkQ0IY5Sqmvqtv7PpPqQ/8VnZ4eUGnM2BukLcWQDl0cKqRuirMQFI5L7smUdhQTlZjqmrdP8Eo= X-Received: by 2002:a02:3f5c:: with SMTP id c28mr5554058jaf.103.1567709601273; Thu, 05 Sep 2019 11:53:21 -0700 (PDT) MIME-Version: 1.0 References: <156770912413.505.12375768155797891488@ietfa.amsl.com> In-Reply-To: <156770912413.505.12375768155797891488@ietfa.amsl.com> From: Brian Campbell Date: Thu, 5 Sep 2019 12:52:55 -0600 Message-ID: To: The IESG , oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000e55cee0591d2d51c" Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-resource-indicators-06.txt 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: Thu, 05 Sep 2019 18:53:27 -0000 --000000000000e55cee0591d2d51c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable -06 should address comments from IESG evaluation ---------- Forwarded message --------- From: Date: Thu, Sep 5, 2019 at 12:45 PM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-06.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Resource Indicators for OAuth 2.0 Authors : Brian Campbell John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-resource-indicators-06.txt Pages : 14 Date : 2019-09-05 Abstract: This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-06 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-= 06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-resource-indicators-06 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000e55cee0591d2d51c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
-06 should address comments from IESG evaluation
=
------= ---- Forwarded message ---------
From: <internet-drafts@ietf.or= g>
Date: Thu, Sep 5, 2019 at 12:45 PM
Subject: [OAUTH-W= G] I-D Action: draft-ietf-oauth-resource-indicators-06.txt
To: <i-d-announce@ietf.or= g>
Cc: <o= auth@ietf.org>



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Resource Indicators for OAuth 2.0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria= n Campbell
=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 John Bradley
=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 Hannes Tschofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-resource-indicators-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-09-05

Abstract:
=C2=A0 =C2=A0This document specifies an extension to the OAuth 2.0 Authoriz= ation
=C2=A0 =C2=A0Framework defining request parameters that enable a client to<= br> =C2=A0 =C2=A0explicitly signal to an authorization server about the identit= y of
=C2=A0 =C2=A0the protected resource(s) to which it is requesting access.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/d= oc/draft-ietf-oauth-resource-indicators/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft= -ietf-oauth-resource-indicators-06
https://datatracker.iet= f.org/doc/html/draft-ietf-oauth-resource-indicators-06

A diff from the previous version is available at:
https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-oauth-resource-indicators-06


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000e55cee0591d2d51c-- From nobody Thu Sep 5 12:00:40 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D26F120B87; Thu, 5 Sep 2019 12:00:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156771002229.550.3907319525349182806@ietfa.amsl.com> Date: Thu, 05 Sep 2019 12:00:22 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2019 19:00:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Resource Indicators for OAuth 2.0 Authors : Brian Campbell John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-resource-indicators-07.txt Pages : 14 Date : 2019-09-05 Abstract: This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-07 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-resource-indicators-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 5 12:01:55 2019 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 5A856120B6D for ; Thu, 5 Sep 2019 12:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 jur7fi5tSMbF for ; Thu, 5 Sep 2019 12:01:27 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 6A05B120B75 for ; Thu, 5 Sep 2019 12:01:27 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id n197so7166050iod.9 for ; Thu, 05 Sep 2019 12:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HJ0GZ9Dgt31UKGS67CXE9kUbN/fJx/pclMfTW1ieTt8=; b=XuFj3DnzQdwbkHiMtJyO2Oymcpj0AU2AXXcICRqJVWspJH932DRP/+a8JmAQsekXkw rWctWwGQFukKWO92KUkNsjE6611jbRLNF3yk3W62kzdPltBb4hQb7s0j0UhPTdeo0Kn9 rDWXqm5XtADOdbUJS/9EzwGOdKWveYsuC/sZ8= 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=HJ0GZ9Dgt31UKGS67CXE9kUbN/fJx/pclMfTW1ieTt8=; b=Ef50h4B6hqgG9JNQ3FOSiaPkeBG/8M5DlMnatg2wGJUWhd+TtHga7EOhugwIWCjlz8 22J2pGGONw4joIxpZpY+WoCndutrSijJuddIBj/4NAcVv3NzFXKEXpV8uPDQf2hMfNok CmBsI2vGJuw8GvjRg7gUIlLb70BDmW1z9Nofb1jYgbKXvdKi8qbJhxfBO595XXgKSaSG hWP6XO7LWHN5OnuO/hmGbJPyQ/hE+IsRb0mVQ9++wSRayw/UfV8GccfiZqAMMXPBTVnt 0FknW2mGq5a40serhluauSxImvurzx7BOVwdudz4WTDz6I+VAMNpU9kzTKrNF2Av2HID BFzg== X-Gm-Message-State: APjAAAU5t0FvH0t4HYCvDne/dHX7zo5DIquqwEzCloy4P+xP7DFSpKLW wyQ9B1URZ9QoVjr3citsmLDJjAeI53werlzOFfPebJVyd9bNavCMO/xBtGq3whwEfEW5Vdrvtew v1GnJKT0EQ0Rizg== X-Google-Smtp-Source: APXvYqzD3BmIM9kYRevVA4urQYslx+kTJIVB797UznnfIoutyYBm9Z6BX+ybik86i8pAGqynSp9OjA3T3jqUacVe/lY= X-Received: by 2002:a02:3902:: with SMTP id l2mr5578906jaa.45.1567710086646; Thu, 05 Sep 2019 12:01:26 -0700 (PDT) MIME-Version: 1.0 References: <156757720342.20663.3055037033818226992.idtracker@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Thu, 5 Sep 2019 13:01:00 -0600 Message-ID: To: Barry Leiba Cc: Adam Roach , draft-ietf-oauth-resource-indicators@ietf.org, oauth-chairs@ietf.org, The IESG , oauth Content-Type: multipart/alternative; boundary="000000000000d374460591d2f22c" Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) 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: Thu, 05 Sep 2019 19:01:38 -0000 --000000000000d374460591d2f22c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I went ahead with this in -07. On Wed, Sep 4, 2019 at 3:07 PM Brian Campbell wrote: > Thanks Barry, I kinda like it. Although I'm a bit hesitant to make a > change like that at this stage. I guess I'd be looking for a little more > buy-in from folks first. Though it's not actually a functional breaking > change. So maybe okay to just go with. > > On Wed, Sep 4, 2019 at 2:54 PM Barry Leiba > wrote: > >> > Yeah, with query parameters lacking the hierarchical semantics that th= e >> path component has, it is much less clear. In fact, an earlier revision = of >> the draft forbid the query part as I was trying to avoid the ambiguity t= hat >> it brings. But there were enough folks with some use case for it that it >> made its way back in. While I am sympathetic to the point you're making >> here, I'd prefer to not codify the practice any further by way of exampl= e >> in the document. >> >> Is it perhaps reasonable to discourage the use of a query component >> while still allowing it? Maybe a "SHOULD NOT", such as this?: >> >> OLD >> Its value MUST be an absolute URI, as specified by >> Section 4.3 of [RFC3986], which MAY include a query component but >> MUST NOT include a fragment component. >> NEW >> Its value MUST be an absolute URI, as specified by >> Section 4.3 of [RFC3986]. The URI MUST NOT include >> a fragment component. It SHOULD NOT include a query >> component, but it is recognized that there are cases that >> make a query component useful. >> END >> >> What do you think? >> >> Barry >> > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000d374460591d2f22c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I went ahead with this in -07.

On Wed, Sep 4, 2019 at = 3:07 PM Brian Campbell <bc= ampbell@pingidentity.com> wrote:
Thanks Barry, I kinda like it. Alt= hough I'm a bit hesitant to make a change like that at this stage. I gu= ess I'd be looking for a little more buy-in from folks first. Though it= 's not actually a functional breaking change. So maybe okay to just go = with.

On Wed, Sep 4, 2019 at 2:54 PM Barry Leiba <barryleiba@computer.org> = wrote:
> Yeah= , with query parameters lacking the hierarchical semantics that the path co= mponent has, it is much less clear. In fact, an earlier revision of the dra= ft forbid the query part as I was trying to avoid the ambiguity that it bri= ngs. But there were enough folks with some use case for it that it made its= way back in. While I am sympathetic to the point you're making here, I= 'd prefer to not codify the practice any further by way of example in t= he document.

Is it perhaps reasonable to discourage the use of a query component
while still allowing it?=C2=A0 Maybe a "SHOULD NOT", such as this= ?:

OLD
=C2=A0 =C2=A0 =C2=A0 Its value MUST be an absolute URI, as specified by
=C2=A0 =C2=A0 =C2=A0 Section 4.3 of [RFC3986], which MAY include a query co= mponent but
=C2=A0 =C2=A0 =C2=A0 MUST NOT include a fragment component.
NEW
=C2=A0 =C2=A0 =C2=A0 Its value MUST be an absolute URI, as specified by
=C2=A0 =C2=A0 =C2=A0 Section 4.3 of [RFC3986].=C2=A0 The URI MUST NOT inclu= de
=C2=A0 =C2=A0 =C2=A0 a fragment component.=C2=A0 It SHOULD NOT include a qu= ery
=C2=A0 =C2=A0 =C2=A0 component, but it is recognized that there are cases t= hat
=C2=A0 =C2=A0 =C2=A0 make a query component useful.
END

What do you think?

Barry

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000d374460591d2f22c-- From nobody Thu Sep 5 12:03:32 2019 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 E4F54120B64 for ; Thu, 5 Sep 2019 12:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=pingidentity.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 K7P31C7Rcm-g for ; Thu, 5 Sep 2019 12:03:20 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 1DE30120B67 for ; Thu, 5 Sep 2019 12:03:20 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id u185so7143129iod.10 for ; Thu, 05 Sep 2019 12:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ALi7dBzT3TQn8dEH2NSqjY4eQ+6pQFZ05A8o9aCunEA=; b=DEfhpH+0L/FB2Wnp/gx7Kehs6Do3gojDFQSOjubg5fp4jgZcOp7ODw/Mx2aE4TgTdJ sgYy6UCfLUk5STtdVjrtyHPhzjxlesLC/q221ntWKj77zl9cg3qxpioRP5NCvIskI9Bu z9f3RInQlsZHvTZd31uB/bJtvOOK2DJpst+Vw= 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; bh=ALi7dBzT3TQn8dEH2NSqjY4eQ+6pQFZ05A8o9aCunEA=; b=fZUvD0OwiErbiPTrP5wN68GxDp/5zjRhkOPdcjyuoFwlCFD3btlJu5V1hayd/zZkak Cuid+6Otp12WaE6RtdvuR50kAd6TEq0X7yVT7BM9+N2wOoE7y6I+C1w50nvGvD/8ZJuB 2A8llO8eNc5HDauApkihZEjpmUhcn5yIcd0cySityyCzdeSTJRUlW5oFp/aXicju0qlf 69RrW3e3A7e+3ehGotPd7C/mLUIt7lNTZCPoTKWt6QaYt5sScyXhCOle8L3ry2rx/ZXx 88loPeGGzQmf4rx0/ZMyywzfRrKiUSR/M3sePb8YGazbG/wfhiSAJCstLdH60jusNeHB EtlQ== X-Gm-Message-State: APjAAAXGsi94BcJHp275lA8SGDWZ0ayx0eCVSO4Y78Uiuato+wS5NZ7C gswrfmGzkK2sW5RgmHHMSRKrkYbfNDE38mWTgUtJzgAbeXPeX919NRSAIY8OSgtBbj4fMsjEfBj JZIPEeRnl07g+2A== X-Google-Smtp-Source: APXvYqwrCI8PaMi5lAWQ34bybri0H6B3i4DKc2Nmng4g84lSAs7iTBtElDAHZ1kJ7LhiQ+bDf0cZ06VERGJUprDLneE= X-Received: by 2002:a02:781c:: with SMTP id p28mr5859209jac.91.1567710199400; Thu, 05 Sep 2019 12:03:19 -0700 (PDT) MIME-Version: 1.0 References: <156770912413.505.12375768155797891488@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Thu, 5 Sep 2019 13:02:53 -0600 Message-ID: To: The IESG , oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000008c1e080591d2f9df" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-06.txt 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: Thu, 05 Sep 2019 19:03:30 -0000 --0000000000008c1e080591d2f9df Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable er... and also -07 On Thu, Sep 5, 2019 at 12:52 PM Brian Campbell wrote: > -06 should address comments from IESG evaluation > > ---------- Forwarded message --------- > From: > Date: Thu, Sep 5, 2019 at 12:45 PM > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-06.t= xt > To: > Cc: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IET= F. > > Title : Resource Indicators for OAuth 2.0 > Authors : Brian Campbell > John Bradley > Hannes Tschofenig > Filename : draft-ietf-oauth-resource-indicators-06.txt > Pages : 14 > Date : 2019-09-05 > > Abstract: > This document specifies an extension to the OAuth 2.0 Authorization > Framework defining request parameters that enable a client to > explicitly signal to an authorization server about the identity of > the protected resource(s) to which it is requesting access. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-06 > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicator= s-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-resource-indicators-= 06 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000008c1e080591d2f9df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
er... and also -07

On Thu, Sep 5, 2019 at 12:52 PM Bri= an Campbell <bcampbell@pin= gidentity.com> wrote:
-06 should address comments from IESG evaluat= ion

---------- Forwarded message ---------
From: &= lt;internet-d= rafts@ietf.org>
Date: Thu, Sep 5, 2019 at 12:45 PM
Subj= ect: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-06.txt
= To: <i-d-ann= ounce@ietf.org>
Cc: <oauth@ietf.org>



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Resource Indicators for OAuth 2.0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria= n Campbell
=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 John Bradley
=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 Hannes Tschofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-resource-indicators-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-09-05

Abstract:
=C2=A0 =C2=A0This document specifies an extension to the OAuth 2.0 Authoriz= ation
=C2=A0 =C2=A0Framework defining request parameters that enable a client to<= br> =C2=A0 =C2=A0explicitly signal to an authorization server about the identit= y of
=C2=A0 =C2=A0the protected resource(s) to which it is requesting access.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/d= oc/draft-ietf-oauth-resource-indicators/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft= -ietf-oauth-resource-indicators-06
https://datatracker.iet= f.org/doc/html/draft-ietf-oauth-resource-indicators-06

A diff from the previous version is available at:
https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-oauth-resource-indicators-06


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000008c1e080591d2f9df-- From nobody Thu Sep 5 14:01:52 2019 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 7CC68120B2B; Thu, 5 Sep 2019 14:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 HQDukBN-vAa7; Thu, 5 Sep 2019 14:01:49 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 7156D120900; Thu, 5 Sep 2019 14:01:49 -0700 (PDT) Received: by mail-io1-f50.google.com with SMTP id j4so7933665iog.11; Thu, 05 Sep 2019 14:01:49 -0700 (PDT) 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:content-transfer-encoding; bh=3dXAqN7nY+oK8cMWiHe9AJ+jyiVc6/lnIYiDfwy2Vzc=; b=ZGRF3ypxsfN6a0tHZPg09HplHdNgCQ0NclUKXATQsYG9jocB5uMkXiE6FMS3A2uEnq xhFiqvI0L67ayWpyo5Q9gb7vbTRZu6pdJHYLA1+XAMAo1JaXthqHxvdjbiLqb4G2UBtY e3KHG37+FYfu9F0lMa1d2YvEIJScxL8EwE2LD+MbkliO5F11DH5Q7vpKO6xF4PVV7IDB wOoyNElDUkEjyFrXTS1XWA4E+Fm3hpv7YNRkEjVCl8tGSPK91ccZHQhLtQ9cpO6xJrvq ujH8PIaRb4MI9nGQILCJuYuad86TF0orb7Gt+nPREVlqsodfibfmxxwrGgsPT9L8wzdR kFzA== X-Gm-Message-State: APjAAAVggucfQ3ooia/J3BhgGGf0ef1887meWBZkvqJt82Lhq1zIMorQ HQoARoopKm8YE8vST9G0WmVFsOLo2ONAyUJ1v8g= X-Google-Smtp-Source: APXvYqxpH28KTcOJ2ZYIF3LFOEFf+SG8kBpE0s75X1Go9L0+Bt7O5vsxH6fpfpo8Cs5LHf7V649UwhFWdZrg3KRg9NQ= X-Received: by 2002:a6b:7709:: with SMTP id n9mr947838iom.187.1567717308381; Thu, 05 Sep 2019 14:01:48 -0700 (PDT) MIME-Version: 1.0 References: <156757720342.20663.3055037033818226992.idtracker@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Thu, 5 Sep 2019 17:01:36 -0400 Message-ID: To: Brian Campbell Cc: Adam Roach , draft-ietf-oauth-resource-indicators@ietf.org, oauth-chairs@ietf.org, The IESG , oauth Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) 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: Thu, 05 Sep 2019 21:01:51 -0000 Thanks, Brian. I hope Adam is happy with that as well. Barry On Thu, Sep 5, 2019 at 3:01 PM Brian Campbell wrote: > > I went ahead with this in -07. > > On Wed, Sep 4, 2019 at 3:07 PM Brian Campbell wrote: >> >> Thanks Barry, I kinda like it. Although I'm a bit hesitant to make a cha= nge like that at this stage. I guess I'd be looking for a little more buy-i= n from folks first. Though it's not actually a functional breaking change. = So maybe okay to just go with. >> >> On Wed, Sep 4, 2019 at 2:54 PM Barry Leiba wro= te: >>> >>> > Yeah, with query parameters lacking the hierarchical semantics that t= he path component has, it is much less clear. In fact, an earlier revision = of the draft forbid the query part as I was trying to avoid the ambiguity t= hat it brings. But there were enough folks with some use case for it that i= t made its way back in. While I am sympathetic to the point you're making h= ere, I'd prefer to not codify the practice any further by way of example in= the document. >>> >>> Is it perhaps reasonable to discourage the use of a query component >>> while still allowing it? Maybe a "SHOULD NOT", such as this?: >>> >>> OLD >>> Its value MUST be an absolute URI, as specified by >>> Section 4.3 of [RFC3986], which MAY include a query component but >>> MUST NOT include a fragment component. >>> NEW >>> Its value MUST be an absolute URI, as specified by >>> Section 4.3 of [RFC3986]. The URI MUST NOT include >>> a fragment component. It SHOULD NOT include a query >>> component, but it is recognized that there are cases that >>> make a query component useful. >>> END >>> >>> What do you think? >>> >>> Barry > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, = distribution or disclosure by others is strictly prohibited. If you have r= eceived this communication in error, please notify the sender immediately b= y e-mail and delete the message and any file attachments from your computer= . Thank you. From nobody Thu Sep 5 17:41:41 2019 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 5E866120043; Thu, 5 Sep 2019 17:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 T9SGv5OO9kPY; Thu, 5 Sep 2019 17:41:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0EBC1120071; Thu, 5 Sep 2019 17:41:31 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x860fM2R082855 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 5 Sep 2019 19:41:24 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1567730486; bh=xsK5R6ywfbBSYjrqddIZLE+0aujhv6Ksv9jEYNSfMIY=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=DyNWvmr3Aml6tSRYpz32w3h43WwTHkcE1YAYgnyGMpRjx28oyhPUYOetn9tdgErXr QrAcJGrfHAFCRAblDpmCKuQk3lE2sahIaRUauYZBYcWvDI7GddiGa114s2cHbn8QSH ok8+wS0+UXeonIj7JSiOhTHRWsVCd89oBQ9DvfOk= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Barry Leiba , Brian Campbell Cc: draft-ietf-oauth-resource-indicators@ietf.org, oauth-chairs@ietf.org, The IESG , oauth References: <156757720342.20663.3055037033818226992.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <354c9b93-271e-9ff2-86a5-9a9e76ab77e7@nostrum.com> Date: Thu, 5 Sep 2019 19:41:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) 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: Fri, 06 Sep 2019 00:41:33 -0000 I don't have a strong objection to it. I still think that, if this is allowed (even as a SHOULD NOT), we need clarity that any query parameters that are used to scope queries to an application necessarily form part of the resource parameter. It's significantly less important, though, now that the practice is discouraged, and I won't mind if you go ahead without adding such text. /a On 9/5/19 4:01 PM, Barry Leiba wrote: > Thanks, Brian. I hope Adam is happy with that as well. > > Barry > > On Thu, Sep 5, 2019 at 3:01 PM Brian Campbell > wrote: >> I went ahead with this in -07. >> >> On Wed, Sep 4, 2019 at 3:07 PM Brian Campbell wrote: >>> Thanks Barry, I kinda like it. Although I'm a bit hesitant to make a change like that at this stage. I guess I'd be looking for a little more buy-in from folks first. Though it's not actually a functional breaking change. So maybe okay to just go with. >>> >>> On Wed, Sep 4, 2019 at 2:54 PM Barry Leiba wrote: >>>>> Yeah, with query parameters lacking the hierarchical semantics that the path component has, it is much less clear. In fact, an earlier revision of the draft forbid the query part as I was trying to avoid the ambiguity that it brings. But there were enough folks with some use case for it that it made its way back in. While I am sympathetic to the point you're making here, I'd prefer to not codify the practice any further by way of example in the document. >>>> Is it perhaps reasonable to discourage the use of a query component >>>> while still allowing it? Maybe a "SHOULD NOT", such as this?: >>>> >>>> OLD >>>> Its value MUST be an absolute URI, as specified by >>>> Section 4.3 of [RFC3986], which MAY include a query component but >>>> MUST NOT include a fragment component. >>>> NEW >>>> Its value MUST be an absolute URI, as specified by >>>> Section 4.3 of [RFC3986]. The URI MUST NOT include >>>> a fragment component. It SHOULD NOT include a query >>>> component, but it is recognized that there are cases that >>>> make a query component useful. >>>> END >>>> >>>> What do you think? >>>> >>>> Barry >> >> 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 nobody Fri Sep 6 11:17:59 2019 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 DADEE120809 for ; Fri, 6 Sep 2019 11:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 YzEWtNdWg_h1 for ; Fri, 6 Sep 2019 11:17:55 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 8042B120073 for ; Fri, 6 Sep 2019 11:17:55 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id f12so14741627iog.12 for ; Fri, 06 Sep 2019 11:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OT9ZeNjpqzIebMDY5BNFoFPUKXqfa4ukkDak5crpbAE=; b=Qj7dvlFIogFxzYXgaQJ2J7GNTqk4UOuAdWlKHX+vflnjQTdByQagoPkZsfwucnF218 xtFA8Ikh2bYlMsEXFGzZBTHEDrcN7+FfL4FN3LXc1Mze/LP/XopOMug2ieW5bWJFMumK 9ArRcA9Whc6kJsOhGgehiLWZ/DnfSRrEhyeiQ= 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=OT9ZeNjpqzIebMDY5BNFoFPUKXqfa4ukkDak5crpbAE=; b=A38iPdqDIah6Ujgv2p5/bISwOe+onbhqCjHOLpMioJj+6C4Qu0yvw/0/QP5xI9aF/J bAfBBKudVHocydDv5wqV6zf9zYyHadZ7JGSl2PNhrghaoOoFLe94D948S2rhXnLrJ5Ou zU0HM+RCzEURi5rWmr8i2Wdn/KZbDhj0oXZ6Pn/X0XYb9fedb15A9YC/nmYbIPZhqq3V kq43P+ImMBtJoLudmoJZcJ0cjUBbp/xtmrk4FyPZEMAHPqC75vIKuGv5U8d6N6sqdqTa nNTygvsFvcahQHfv7jBGlXpkXRh7KLuaGFrMerVedmIG/Fh/PSudkthinvs9TsX3CcOG rLYQ== X-Gm-Message-State: APjAAAU3IfoKevkUd2UHcPb6EuhGWndyFDsJdd5xriQI/cHlfUtwguVv sZdFZLHWUnFIu+9bV6JDnw49Ttr59J3YBq5sCeGeme9J7pFC8xQcfvwL+O5XyZPGRVPwo3j3yu2 fPIcWCeSrj8Dxog== X-Google-Smtp-Source: APXvYqw851hCJp+V4GBP3LZEMU/QlQkhYMg2G/iYsDS3OD0Ndv9lPvjn4ToKtHQD/5NLm2PBpwRBVlc2L1l5YHLgK8k= X-Received: by 2002:a6b:ed18:: with SMTP id n24mr7168604iog.115.1567793874655; Fri, 06 Sep 2019 11:17:54 -0700 (PDT) MIME-Version: 1.0 References: <156757720342.20663.3055037033818226992.idtracker@ietfa.amsl.com> <354c9b93-271e-9ff2-86a5-9a9e76ab77e7@nostrum.com> In-Reply-To: <354c9b93-271e-9ff2-86a5-9a9e76ab77e7@nostrum.com> From: Brian Campbell Date: Fri, 6 Sep 2019 12:17:28 -0600 Message-ID: To: Adam Roach Cc: Barry Leiba , draft-ietf-oauth-resource-indicators@ietf.org, oauth-chairs@ietf.org, The IESG , oauth Content-Type: multipart/alternative; boundary="000000000000fb107b0591e674a6" Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) 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: Fri, 06 Sep 2019 18:17:58 -0000 --000000000000fb107b0591e674a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't have any aversion to adding something but I've been at a bit of a loss as to what exactly to say or how to say it. But here's a stab at something. How about the following sentence, which kind of layers your words onto the text that Barry previously suggested: "It SHOULD NOT include a query component, but it is recognized that there are cases that make a query component a useful and necessary part of the resource parameter, such as when query parameter(s) are used to scope requests to an application." On Thu, Sep 5, 2019 at 6:41 PM Adam Roach wrote: > I don't have a strong objection to it. I still think that, if this is > allowed (even as a SHOULD NOT), we need clarity that any query > parameters that are used to scope queries to an application necessarily > form part of the resource parameter. It's significantly less important, > though, now that the practice is discouraged, and I won't mind if you go > ahead without adding such text. > > /a > > On 9/5/19 4:01 PM, Barry Leiba wrote: > > Thanks, Brian. I hope Adam is happy with that as well. > > > > Barry > > > > On Thu, Sep 5, 2019 at 3:01 PM Brian Campbell > > wrote: > >> I went ahead with this in -07. > >> > >> On Wed, Sep 4, 2019 at 3:07 PM Brian Campbell < > bcampbell@pingidentity.com> wrote: > >>> Thanks Barry, I kinda like it. Although I'm a bit hesitant to make a > change like that at this stage. I guess I'd be looking for a little more > buy-in from folks first. Though it's not actually a functional breaking > change. So maybe okay to just go with. > >>> > >>> On Wed, Sep 4, 2019 at 2:54 PM Barry Leiba > wrote: > >>>>> Yeah, with query parameters lacking the hierarchical semantics that > the path component has, it is much less clear. In fact, an earlier revisi= on > of the draft forbid the query part as I was trying to avoid the ambiguity > that it brings. But there were enough folks with some use case for it tha= t > it made its way back in. While I am sympathetic to the point you're makin= g > here, I'd prefer to not codify the practice any further by way of example > in the document. > >>>> Is it perhaps reasonable to discourage the use of a query component > >>>> while still allowing it? Maybe a "SHOULD NOT", such as this?: > >>>> > >>>> OLD > >>>> Its value MUST be an absolute URI, as specified by > >>>> Section 4.3 of [RFC3986], which MAY include a query component > but > >>>> MUST NOT include a fragment component. > >>>> NEW > >>>> Its value MUST be an absolute URI, as specified by > >>>> Section 4.3 of [RFC3986]. The URI MUST NOT include > >>>> a fragment component. It SHOULD NOT include a query > >>>> component, but it is recognized that there are cases that > >>>> make a query component useful. > >>>> END > >>>> > >>>> What do you think? > >>>> > >>>> Barry > >> > >> 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 sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you. > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000fb107b0591e674a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't have any aversion to adding something but= I've been at a bit of a loss as to what exactly to say or how to say i= t. But here's a stab at something. How about the following sentence, wh= ich kind of layers your words onto the text that Barry previously suggested= :

"It SHOULD NOT include a query componen= t, but it is recognized that there are cases that make a query component a = useful and necessary part of the resource parameter, such as when query par= ameter(s) are used to scope requests to an application."=C2=A0

On Thu, Sep 5, 2019 at 6:41 PM Adam Roach <adam@nostrum.com> wrote:
=
I don't have a strong= objection to it. I still think that, if this is
allowed (even as a SHOULD NOT), we need clarity that any query
parameters that are used to scope queries to an application necessarily form part of the resource parameter. It's significantly less important,=
though, now that the practice is discouraged, and I won't mind if you g= o
ahead without adding such text.

/a

On 9/5/19 4:01 PM, Barry Leiba wrote:
> Thanks, Brian.=C2=A0 I hope Adam is happy with that as well.
>
> Barry
>
> On Thu, Sep 5, 2019 at 3:01 PM Brian Campbell
> <bc= ampbell@pingidentity.com> wrote:
>> I went ahead with this in -07.
>>
>> On Wed, Sep 4, 2019 at 3:07 PM Brian Campbell <bcampbell@pingidentity.com<= /a>> wrote:
>>> Thanks Barry, I kinda like it. Although I'm a bit hesitant= to make a change like that at this stage. I guess I'd be looking for a= little more buy-in from folks first. Though it's not actually a functi= onal breaking change. So maybe okay to just go with.
>>>
>>> On Wed, Sep 4, 2019 at 2:54 PM Barry Leiba <barryleiba@computer.org&g= t; wrote:
>>>>> Yeah, with query parameters lacking the hierarchical s= emantics that the path component has, it is much less clear. In fact, an ea= rlier revision of the draft forbid the query part as I was trying to avoid = the ambiguity that it brings. But there were enough folks with some use cas= e for it that it made its way back in. While I am sympathetic to the point = you're making here, I'd prefer to not codify the practice any furth= er by way of example in the document.
>>>> Is it perhaps reasonable to discourage the use of a query = component
>>>> while still allowing it?=C2=A0 Maybe a "SHOULD NOT&qu= ot;, such as this?:
>>>>
>>>> OLD
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Its value MUST be an absolute U= RI, as specified by
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Section 4.3 of [RFC3986], which= MAY include a query component but
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST NOT include a fragment com= ponent.
>>>> NEW
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Its value MUST be an absolute U= RI, as specified by
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Section 4.3 of [RFC3986].=C2=A0= The URI MUST NOT include
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 a fragment component.=C2=A0 It = SHOULD NOT include a query
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 component, but it is recognized= that there are cases that
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 make a query component useful.<= br> >>>> END
>>>>
>>>> What do you think?
>>>>
>>>> Barry
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review= , use, distribution or disclosure by others is strictly prohibited.=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000fb107b0591e674a6-- From nobody Fri Sep 6 11:42:07 2019 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 538F41208B5 for ; Fri, 6 Sep 2019 11:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 oNy4aADahS3d for ; Fri, 6 Sep 2019 11:42:04 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 AD627120115 for ; Fri, 6 Sep 2019 11:42:04 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id d25so14963441iob.6 for ; Fri, 06 Sep 2019 11:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=CM+PpabJ/ib3Hh2OJGk1n6CYmZurbL+I3WXg74/5A+0=; b=tEFTUdHwUSSSbCBPcGtgxJt89W3EnJ7/4IG9Xr8ikg/G98JYt1kejQsDayyXxZ/hZ2 PWf0fz7ELdJLSBCfkXZXskI9Ioy+AQKnaN7V8KH72GG9RiLV2PnRr3yWj+2UR9D97ptO BYjhwWzPsqsnmaxwiVlc286CDWc4OfhTzLrDJd/6VuIWdJ40Hzy2y2MKUCSFI0ZunQ7A aC2R0cISsSDQFzgXm4aZXoGjb7amRsl4f3kd0+0FLyB4wIxoTZ2e6jcGFg2dxzqzZUR+ vpPHdJ+Gq6VpKwJqh84Rh90PQNTwjj6UJ3AbAt5hAMBxZQoBqnddSCUCMU6UvbVQ391O rKOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CM+PpabJ/ib3Hh2OJGk1n6CYmZurbL+I3WXg74/5A+0=; b=IzQtgSsi389ZztNn7e579UW7tnTbyZKgUwOSfL3xxBvw47yK1+CH9y/jMSGVJzozHA mq9YaUQOCyArt522T/AGLWzMeMHHRnb3Nh812F+wyue0abwhtqOMXcDkXOitU9uu2xMV Gwyj6S8xaGxXJeyFP154XEhKnvxB8NzVSWjxMRXAIkcvqqWkEGNFntl1sxJ+bObSJ5b5 JVA15+llrTzrN8UARo/DxwlQ/ITtG6Klrxsmhw8j0Te+0NAEORyjEuqktnsD3zvq/cN3 1Cfd/j4ehXa8RFJs3esC8RCTzkzJ9n2gzrSYMf4olEvyBRVDezWqYm+kJ12SkOU/4ACW k+cA== X-Gm-Message-State: APjAAAVgykebP8D/9ICu6pxC/zb4rR2udoFWg3Mff3kw7zZjidtR558r AnfJKCsAbNQu8VCprVhzMVfDez3idypeWbOzKj5RSMhulMw= X-Google-Smtp-Source: APXvYqyIfIvi6AFyD3EWM/QKWmhCGPjXB3lLijXVsmvRkNAPSK4itlQIvPyLUEvH++MwrTswgU5HfdvY/ktlEysIzg4= X-Received: by 2002:a5d:951a:: with SMTP id d26mr11999873iom.31.1567795323780; Fri, 06 Sep 2019 11:42:03 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Fri, 6 Sep 2019 14:41:53 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000005ac4120591e6cb07" Archived-At: Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-reciprocal-04 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: Fri, 06 Sep 2019 18:42:06 -0000 --0000000000005ac4120591e6cb07 Content-Type: text/plain; charset="UTF-8" All, We are starting a WGLC on the Reciprocal OAuth document: https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ Please, review the document and provide feedback on any issues you see with the document. The WGLC will end 20-September-2019. Regards, Rifaat and Hannes --0000000000005ac4120591e6cb07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --0000000000005ac4120591e6cb07-- From o.masakazu@gmail.com Tue Sep 10 08:13:30 2019 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 DEEAC1208E2 for ; Tue, 10 Sep 2019 08:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ZIeSPd3yMtZo for ; Tue, 10 Sep 2019 08:13:29 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 30CE4120289 for ; Tue, 10 Sep 2019 08:13:29 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id n197so38323838iod.9 for ; Tue, 10 Sep 2019 08:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/FGyJsFMcIY1qkFvLu8zxXh9KND6zDpvGRSmm01F3n8=; b=PDyLT6kdRVPTkTDU51T16BZKASe6Xf7zwBEU4CmLX8qSAgnQVOE2fT6820ZUfDE6BI a4wWiWjaX2DKcLdFgrqbq3oO0QECPfecNenbd/+9Fa0DL8BGdsvzvSlhvfZwfqQ3QJz1 88VNxRRqfByAsXAx/FEW6Hon+EbbiuojbjJ8zBvkRpGObAIcpnMa7TVCCAnKzJXX96OI /Bnm6U/dMcTjyZGZctEFgfW1EPbK9gwFBIi8/IFl0sWZjlHhn3Q4UGkjUGvlKUYaPwtI D4FsBtLG+iOXC9M9FgniCGEqKDjmkHZ5skkMIljTUXy2UdrFp90TVbeOWUcs0hqRnSUW 4VGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/FGyJsFMcIY1qkFvLu8zxXh9KND6zDpvGRSmm01F3n8=; b=Vz7Do0qLV9oaroR0ctLapTYtBXtAHhz1Il4Kz1P45jqxD6W92+2J3UfcuyQfbDh6Yy 6RdmeK5sZR0bKYR7pe79N96D3OlqTBMjgBteY7y+mNlG8IZ/AJckjYrpGiG6Mdqki2DE PuBCJM7uuzIrfPvitixWuvWChdioY/xmI9demBTpt1rH0O1dEhPo29M5Bsh1bV8GcIq3 TPG2CR9hqyTBcYlrsX77eK0dnN5+a7BDeU4TWpDH4GKJMrX1cU2xScPczYYBLPQbsHW9 sjCVqjbi2EGn51dNAVQoCTJvKwVqdu0ZTQDVks4tkCjyz8zKjcaesMB+0Wk19gJ2m2Fn Rmxw== X-Gm-Message-State: APjAAAWip1nGFC3nw+/cvjVN1+7DaCJ0c6dZBNXJuvYsoBZovKMhJDud lBfdYN/7gqUan7cyd9mJ20c36+kVq/5HOJSbV2FmvPXO9fs= X-Google-Smtp-Source: APXvYqz1EcvU681OFlBzGaGJt15hrGTLbR3j+QM3yQa3kyLaVupOiqPe7c8wsEKIyvJMja83ZUEvSbQ6p91gx7Do8m0= X-Received: by 2002:a02:94e5:: with SMTP id x92mr30987916jah.11.1568128407785; Tue, 10 Sep 2019 08:13:27 -0700 (PDT) MIME-Version: 1.0 From: Masakazu OHTSUKA Date: Tue, 10 Sep 2019 18:13:15 +0300 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000b55a0a0592345869" Archived-At: Subject: [OAUTH-WG] Public client cloning 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: Tue, 10 Sep 2019 16:58:14 -0000 --000000000000b55a0a0592345869 Content-Type: text/plain; charset="UTF-8" Hi, I've read rfc8252 and have questions about native apps, that I couldn't find answers on Internet. Imagine an attacker doing: 1. original app and authorization server conforms to rfc8252 4.1. Authorization Flow for Native Apps Using the Browser 2. clone the original app, name it malicious app and install on the target phone 3. remove the original app from the target phone 4. use the malicious app and authorize, OS will invoke malicious app using custom URL scheme 5. now malicious app has access to the access token How should we think about this? What am I missing? --000000000000b55a0a0592345869 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I've read rfc8252 and have ques= tions about native apps, that I couldn't find answers on Internet.

Imagine an attacker doing:
1. original a= pp and authorization server conforms to rfc8252 4.1.=C2=A0 Authorization Fl= ow for Native Apps Using the Browser
2. clone the original app, n= ame it malicious app and install on the target phone
3. remove th= e original app from the target phone
4. use the malicious app and= authorize, OS will invoke malicious app using custom URL scheme
= 5. now malicious=C2=A0app has access to the access token

How should we think about this?
What am I missing?

--000000000000b55a0a0592345869-- From nobody Tue Sep 10 10:23:07 2019 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 41C741201CE for ; Tue, 10 Sep 2019 10:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=coinbase.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 lRLljVK_dhNj for ; Tue, 10 Sep 2019 10:23:04 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 37932120041 for ; Tue, 10 Sep 2019 10:23:04 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id r12so11955651pfh.1 for ; Tue, 10 Sep 2019 10:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coinbase.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2hPP6UpyxeHefaM4RmSlZGEhstx+ZtHzrPskPyvatQk=; b=VIPllPMJl78T+wARYEAj0XplB+1l435Pvfre7gplXs2byJhNKjq+Uv/4+71JznHCsf ERTYeqeGCP03bCSbVAtEWZIhqu9rMoyDpCFLw8/0IAtfS//oLRZoQpQ76dhyxavdx2fx RWLOEO6DvNr9/5b4ZMu0cHaYkqqTwkuDYms7M= 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=2hPP6UpyxeHefaM4RmSlZGEhstx+ZtHzrPskPyvatQk=; b=aeMN0Nrta2kYu3Qj4MdCxbrDAZNUCA06oR8u81nbdV3YPPM6AuX+hvPEZu8Yrd6HTW NeXJnzi4rydxMSeke3U3AjKStjvZJwSosF/U1vbNyznvp+zxmtDwQ0cTRoiHDqd02DHT 1WCs3ndNOuAHq6yIOOX/s1S1u2f+wF1ILIUXOfqt8Df4DOeMpPeXAk+oV87NV1dtBIiE QjXWB0Tp734EJb0wuMhicZ9MS2Z+kc2KXzc0jbosIqVA2l1O2B16I+4dMv+IxkhDdLrY g2wmRzGK6F/51Ug6d1s/0B0YJk/vDVfdE8tYpfWWsUMoxMi6XdCqY+Tzgcx3Dhg9NZeB e78A== X-Gm-Message-State: APjAAAVyOqIYVo/yOGvljCunFnEbHDWVF0tnBr5fqAR6wAWV/VD1OfdH X5jM7ZAf6C4VH4STYLM5P3dr4jfTG6+5MKjrB8KH2g== X-Google-Smtp-Source: APXvYqycBSbvhHhNdBfhjyhB3bgtlL4Qat7voS0fYIG/gMKZo4O3DQoVMl2cUnkJp8joyooI2adEp7brkcq+D20qEmU= X-Received: by 2002:a63:784c:: with SMTP id t73mr29735109pgc.268.1568136183472; Tue, 10 Sep 2019 10:23:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Marius Scurtescu Date: Tue, 10 Sep 2019 10:22:52 -0700 Message-ID: To: Masakazu OHTSUKA Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000002d1fcd0592362866" Archived-At: Subject: Re: [OAUTH-WG] Public client cloning 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: Tue, 10 Sep 2019 17:23:06 -0000 --0000000000002d1fcd0592362866 Content-Type: text/plain; charset="UTF-8" If the phone is compromised, original app replaced by malicious app, then RFC8252 will not help. The assumption is that the phone is not compromised. On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA wrote: > Hi, > > I've read rfc8252 and have questions about native apps, that I couldn't > find answers on Internet. > > Imagine an attacker doing: > 1. original app and authorization server conforms to rfc8252 4.1. > Authorization Flow for Native Apps Using the Browser > 2. clone the original app, name it malicious app and install on the target > phone > 3. remove the original app from the target phone > 4. use the malicious app and authorize, OS will invoke malicious app using > custom URL scheme > 5. now malicious app has access to the access token > > How should we think about this? > What am I missing? > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000002d1fcd0592362866 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the phone is compromised, original app replaced by mali= cious app, then RFC8252 will not help. The assumption is that the phone is = not compromised.

On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA <o.masakazu@gmail.com> wrote:
Hi,<= div>
I've read rfc8252 and have questions about native ap= ps, that I couldn't find answers on Internet.

= Imagine an attacker doing:
1. original app and authorization = server conforms to rfc8252 4.1.=C2=A0 Authorization Flow for Native Apps Us= ing the Browser
2. clone the original app, name it malicious app = and install on the target phone
3. remove the original app from t= he target phone
4. use the malicious app and authorize, OS will i= nvoke malicious app using custom URL scheme
5. now malicious=C2= =A0app has access to the access token

How should w= e think about this?
What am I missing?

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000002d1fcd0592362866-- From nobody Tue Sep 10 10:37:59 2019 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 1955D120074 for ; Tue, 10 Sep 2019 10:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 EA2YCU0JrCT9 for ; Tue, 10 Sep 2019 10:37:55 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 70053120041 for ; Tue, 10 Sep 2019 10:37:55 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id h7so20529676wrw.8 for ; Tue, 10 Sep 2019 10:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fOlMjvpB3OTG5PRMdSbtZuB7V+kJIOSoZxuAFQfO7fA=; b=fXCu8gDFn2V+mdiRvoeaDL6zxqsFITmtOusxA97PAETn84VMGhCpxvHO1BXX4hTQsS nbPGuxflnUcGXxMiOo9R4tG5SbRGeRh3KqKb3IQd23Thy/9aWK/ErOOHpw/V0qKsiOOv 40V9mUjFVVPj2Yzx6FDSIkanw5RR6wgkaqAEG8I2UstAm0zyIis9tRGufrjRepLzUwph RLgKmL2NO6viOa8qpp3poscuGeu/QGr+DXkiiGGmur5WjeauloQhAdx2kYFPLyotvDOA SGhtyst6FcwhlZD+oAV84hFrz81dHZfe3RVjHCiO8Qiu4CJPHzyfATi+iYftSfLlHXkE DbfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fOlMjvpB3OTG5PRMdSbtZuB7V+kJIOSoZxuAFQfO7fA=; b=oH10TyLi2PJ9EPFykfljobeacy3rh0+rRBNDvFZP+5ewBqh4JcbTVDZ6gXWBkoYQiR +0bvgwxoa5Wh2sMxabgos/qKfn3uxQLkSF4efj79DZfQCDhvYqliz6pvoV1SdbjJMDnz 2Z8UpMzM9TCEG4bElHchTijAD5WeilIekCrgkLAUSEIWBKMEoZQvEKziCk4P3Oi7HhPp yUgg1J5FXkwjYSS6Wl9BBkVXRLkFXkGTK+0uiDGr4oPaNdtwsrepaMAtaX2Qyj02oAkf zipnVhe62FMiSpnE8hPIbn2t08wmMWg2F10zIT5NgYZ2Jp16uyj3MRr7hjJ+jjybAHDh sCZA== X-Gm-Message-State: APjAAAXD7wSW3ebJanu0wjfejhNGf80ondT+vYdaJjAPldmmBYQi06Kx R3qG7BHJQ6vFRU/LkrVsMw== X-Google-Smtp-Source: APXvYqzgI+tEzXmQePHvXvwnviMzwAlySEh/kDpjxluyR7Kc0aikxW40IPsg5RjMkPIWAAiX8A1mFg== X-Received: by 2002:adf:dd02:: with SMTP id a2mr27952541wrm.15.1568137073908; Tue, 10 Sep 2019 10:37:53 -0700 (PDT) Received: from [192.168.0.178] (ip-78-45-222-80.net.upcbroadband.cz. [78.45.222.80]) by smtp.gmail.com with ESMTPSA id e30sm34414214wra.48.2019.09.10.10.37.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Sep 2019 10:37:53 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-7D5A729F-2FA7-4B8B-92A8-2458067E3774 Mime-Version: 1.0 (1.0) From: Filip Skokan X-Mailer: iPhone Mail (16G77) In-Reply-To: Date: Tue, 10 Sep 2019 19:37:50 +0200 Cc: Masakazu OHTSUKA , oauth@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <0D47C91A-8D03-463C-9750-419797E4C53E@gmail.com> References: To: Marius Scurtescu Archived-At: Subject: Re: [OAUTH-WG] Public client cloning 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: Tue, 10 Sep 2019 17:37:57 -0000 --Apple-Mail-7D5A729F-2FA7-4B8B-92A8-2458067E3774 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable A claimed HTTPS URI would tho, right? Odesl=C3=A1no z iPhonu 10. 9. 2019 v 19:22, Marius Scurtescu : > If the phone is compromised, original app replaced by malicious app, then R= FC8252 will not help. The assumption is that the phone is not compromised. >=20 >> On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA w= rote: >> Hi, >>=20 >> I've read rfc8252 and have questions about native apps, that I couldn't f= ind answers on Internet. >>=20 >> Imagine an attacker doing: >> 1. original app and authorization server conforms to rfc8252 4.1. Author= ization Flow for Native Apps Using the Browser >> 2. clone the original app, name it malicious app and install on the targe= t phone >> 3. remove the original app from the target phone >> 4. use the malicious app and authorize, OS will invoke malicious app usin= g custom URL scheme >> 5. now malicious app has access to the access token >>=20 >> How should we think about this? >> What am I missing? >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-7D5A729F-2FA7-4B8B-92A8-2458067E3774 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable A claimed HTTPS URI would tho, right?
________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-7D5A729F-2FA7-4B8B-92A8-2458067E3774-- From nobody Tue Sep 10 12:27:23 2019 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 8FB50120273 for ; Tue, 10 Sep 2019 12:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 QKmqgvzUk0rn for ; Tue, 10 Sep 2019 12:27:19 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 97830120096 for ; Tue, 10 Sep 2019 12:27:19 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id r4so40221665iop.4 for ; Tue, 10 Sep 2019 12:27:19 -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=fDZa/fi9dccpzvBRpW/BOUi+ZkmYUv+cwUZDVsTM10g=; b=AXtTNDX0gyjQLj9/l5tBTA0IS2uOPXcKTWb1gHIZCMn4fShy9ny9NpFvPrj+A28Hs9 gFnGfbNytOEIGMHv1SVTpdUAaRDTIdukhESxeSMv0wjN2NF7Pe4eKlAgFxODmhLgd6Hy IARB2qP3P0I08IzKmyjP9pr55coaRsT2mZbjI6pkO1VGVIHgnxc4s0YgiAr3PI9TGmC1 ob+8BLMrilODoh7HA1H37VwkzdAMqXwASEBsqJadbg6/4VhncHTGibZ4SQOfaZ8+w5i/ DcQMx5+Jpj8YeRxkcxx1GmQOvZZ9vwvPgp2HwRCuVkDAUFPtHGPKeYtyMXtovSycqUGe yJNA== 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=fDZa/fi9dccpzvBRpW/BOUi+ZkmYUv+cwUZDVsTM10g=; b=OMTiP3PTyOo3UpV8MGXX6XPWK1Kh/wScWj/hrw8YNoiG8fcwBz+78a9Etngt9oU6nV u0iOqsmq07Th4LEnBi71NKyNPx4OtU6IVC235uUCmc19wra8gPfQ9vrxuwX7TmI9/fpp S4jkOEFTbt0p7xWUWx2fW+yCslA/UE1zmIKU64+cxkLgrV4GgiuJeXnjFzc2zsg+AsKU SY6wLLr7Si+a/A1kpTYAUrNzD/lmmEnqS9RdcpWBF9BG3Ewvt9+/eJKePTjqtsiQ3tZ4 wz8dvNHdhysHlMbXPn2DyjRDfL+1HqPN3YxWrRldlWjFcfeBoSL96/JLbQrV9oLoFia0 Rs3g== X-Gm-Message-State: APjAAAVOVYvGjLp4ck1FM2kzeAJBsHAk2pPly88/hkgWFyCNmguIGyit qwrzSOBTJfehNKSoLc6IP7040KIdEAnRtGmuZhIDy73n X-Google-Smtp-Source: APXvYqzmZHrGI5FWFjmhAdT8NNsAkhTXBb/abDMoQzDvDIBIc5HdaSkCL73HalbhywCkLPjEFcYJHC0EwHig0uQWNM8= X-Received: by 2002:a5d:9153:: with SMTP id y19mr13899209ioq.109.1568143638832; Tue, 10 Sep 2019 12:27:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Masakazu OHTSUKA Date: Tue, 10 Sep 2019 22:27:07 +0300 Message-ID: To: Marius Scurtescu Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000008ca8d3059237e496" Archived-At: Subject: Re: [OAUTH-WG] Public client cloning 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: Tue, 10 Sep 2019 19:27:22 -0000 --0000000000008ca8d3059237e496 Content-Type: text/plain; charset="UTF-8" I see. Then is this understandable to think from the Authorization Server's point of view ... If phone being compromised is a threat that the Client cares, AS might be interested in NOT supporting public Clients, and forcing the Client to have a server side, do client authentication, and have some way to hold a session between the native app and it's server side. Because if phone is compromised, when AS supports public Clients and access_token leaks, it's kind of AS's fault (well depending on the terms...), but if whatever the means that the phone app and it's server side keeps a session leaks, it's NOT the AS's fault. On Tue, Sep 10, 2019 at 8:23 PM Marius Scurtescu < marius.scurtescu@coinbase.com> wrote: > If the phone is compromised, original app replaced by malicious app, then > RFC8252 will not help. The assumption is that the phone is not compromised. > > On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA > wrote: > >> Hi, >> >> I've read rfc8252 and have questions about native apps, that I couldn't >> find answers on Internet. >> >> Imagine an attacker doing: >> 1. original app and authorization server conforms to rfc8252 4.1. >> Authorization Flow for Native Apps Using the Browser >> 2. clone the original app, name it malicious app and install on the >> target phone >> 3. remove the original app from the target phone >> 4. use the malicious app and authorize, OS will invoke malicious app >> using custom URL scheme >> 5. now malicious app has access to the access token >> >> How should we think about this? >> What am I missing? >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --0000000000008ca8d3059237e496 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I see.

Then is this understandable to t= hink from the Authorization Server's point of view ...

If phone being compromised is a threat that the Client cares,
AS might be interested in NOT supporting public Clients,
an= d forcing the Client to have a server side, do client authentication, and h= ave some way to hold a session between the native app and it's server s= ide.

Because if phone is compromised, when AS supp= orts public Clients and access_token leaks, it's kind of AS's fault= (well depending on the terms...),
but if whatever the means that= the phone app and it's server side keeps a session leaks, it's NOT= the AS's fault.


On Tue, Sep 10, 2019 at 8:23 PM Ma= rius Scurtescu <marius.= scurtescu@coinbase.com> wrote:
If the phone is compromised, origina= l app replaced by malicious app, then RFC8252 will not help. The assumption= is that the phone is not compromised.

=
On Tue, Sep 10, 2019 at 9:58 AM Masak= azu OHTSUKA <o= .masakazu@gmail.com> wrote:
Hi,

I've read rf= c8252 and have questions about native apps, that I couldn't find answer= s on Internet.

Imagine an attacker doing:
1. original app and authorization server conforms to rfc8252 4.1.=C2= =A0 Authorization Flow for Native Apps Using the Browser
2. clone= the original app, name it malicious app and install on the target phone
3. remove the original app from the target phone
4. use t= he malicious app and authorize, OS will invoke malicious app using custom U= RL scheme
5. now malicious=C2=A0app has access to the access toke= n

How should we think about this?
What a= m I missing?

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000008ca8d3059237e496-- From nobody Tue Sep 10 17:42:29 2019 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 7050412012D for ; Tue, 10 Sep 2019 17:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Gx2OUf5qUXbu for ; Tue, 10 Sep 2019 17:42:26 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 3FA9612022A for ; Tue, 10 Sep 2019 17:42:26 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id f12so41809331iog.12 for ; Tue, 10 Sep 2019 17:42:26 -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; bh=6HihxJ1/K60zWHpzMro5+QB7e41Ke/ZhBoAy9JtYsiw=; b=lspjuBnCx2zd39y/DR0nZgNgIbgLftg5pHEECtGf2Q2JKD8P/lPLvv5D1DCMIuKHx4 ppgDt4o5DOK11QaLfZf3U/HEYEQsL0aeSXW38hxDp8+d3MxSlVS6yJVHXYzwoaZdagst EWEREl31aOm50MbQYv1A6kD4BSRVhe9VuuJZHSUE3AS9nGUu7y0BOexAx3jVJwK8CP0/ SmmArdjktfGRtxcyuW4/jCPjhPJ2yasPfhHBVT4bby5vRKO1//JmfexGFPx061FPlp1v isRRG1XKeFrWvI1aOb8Ze66pBiLUlIRkP+kB7YYGUn/DpGDMOGaATIOesAngwlmsAvWH LbxA== 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; bh=6HihxJ1/K60zWHpzMro5+QB7e41Ke/ZhBoAy9JtYsiw=; b=VzsYxsyNOXBrtJsBGEajoUd1ghrFDXSLQxvXB91dztYg0wDdu5nKMf13jGkEbm2kys ioSXyXMTPiSdVBPoqZdj3YChyzIAo9rE/nSG3E2Wq820LjaYB4NVe6/kwUiRZmpbg2JD oUOmc5hfUpSrnMFupDmzuKcNwMrtHQ92oOhht/xQsedxGZTxyAMnVmcJ/p3YlJ0KG4Y8 0/R/SuSGJQ/r2gP3qOmepDziWk8rGfv7wsZjm1LAW+vruJ2gD7HGXboyuiYRDoHCyJIe TC8eHUYTwfZo2/Vym5+o7eyUcEQvgx6I0T5rRsYriMIVQJHEi+RUYbIDuJQIIy83v/jE e38w== X-Gm-Message-State: APjAAAXawGVKxVL3q3a/He428S5CfMDeVoZ+SmEaA3ai3Dh3KYkfbXQI sW3V7QTamf8eq1+aMWKsYNYEnp6H7gNIEpi7jNzJADX4CLY= X-Google-Smtp-Source: APXvYqw65pifOvjhhH7z74uTMgiKL2vyTqtkqLlz8yXvk3V9yrL7fPya7pMHPO+nJKKHp5HrWAeejvSqXJZaExujeKU= X-Received: by 2002:a02:683:: with SMTP id 125mr35802344jav.132.1568162545237; Tue, 10 Sep 2019 17:42:25 -0700 (PDT) MIME-Version: 1.0 References: <156816228460.22517.5277193592349076537.idtracker@ietfa.amsl.com> In-Reply-To: <156816228460.22517.5277193592349076537.idtracker@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Tue, 10 Sep 2019 20:42:15 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000075844605923c4b66" Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-yusef-oauth-nested-jwt-03.txt 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: Wed, 11 Sep 2019 00:42:28 -0000 --00000000000075844605923c4b66 Content-Type: text/plain; charset="UTF-8" All, I have submitted a new version of the draft that includes a 3rd use case used by the *Network Service Mesh* project. https://networkservicemesh.io/ Regards, Rifaat ---------- Forwarded message --------- From: Date: Tue, Sep 10, 2019 at 8:38 PM Subject: New Version Notification for draft-yusef-oauth-nested-jwt-03.txt To: Rifaat Shekh-Yusef A new version of I-D, draft-yusef-oauth-nested-jwt-03.txt has been successfully submitted by Rifaat Shekh-Yusef and posted to the IETF repository. Name: draft-yusef-oauth-nested-jwt Revision: 03 Title: Nested JSON Web Token (JWT) Document date: 2019-09-10 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-yusef-oauth-nested-jwt-03.txt Status: https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/ Htmlized: https://tools.ietf.org/html/draft-yusef-oauth-nested-jwt-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt Diff: https://www.ietf.org/rfcdiff?url2=draft-yusef-oauth-nested-jwt-03 Abstract: This specification extends the scope of the Nested JSON Web Token (JWT) to allow the enclosing JWT to contain its own Claims Set in addition to the enclosed JWT. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --00000000000075844605923c4b66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

I have submitted=C2=A0a new versio= n of the draft that includes a 3rd use case used by the Network Service = Mesh project.

Regards,
<= /div>
=C2=A0Rifaat

=C2=A0

---------- Forwarded me= ssage ---------
From: <internet-drafts@ietf.org>
Date: Tue, Sep = 10, 2019 at 8:38 PM
Subject: New Version Notification for draft-yusef-oa= uth-nested-jwt-03.txt
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>



A new version of I-D, draft-yusef-oauth-nested-jwt-03.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-yusef-oauth-nested-jwt<= br> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Nested JSON Web Token (JWT)
Document date:=C2=A0 2019-09-10
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-yusef-oauth-ne= sted-jwt-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://tools.ietf.org/html/draft-yusef-oauth-nested-jwt-03
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-yusef-oauth-nested-j= wt-03

Abstract:
=C2=A0 =C2=A0This specification extends the scope of the Nested JSON Web To= ken
=C2=A0 =C2=A0(JWT) to allow the enclosing JWT to contain its own Claims Set= in
=C2=A0 =C2=A0addition to the enclosed JWT.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--00000000000075844605923c4b66-- From nobody Tue Sep 10 17:51:48 2019 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 9039612000F for ; Tue, 10 Sep 2019 17:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cEgPqrXVGtqF for ; Tue, 10 Sep 2019 17:51:42 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 79C4912007A for ; Tue, 10 Sep 2019 17:51:42 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id y5so9809194pfo.4 for ; Tue, 10 Sep 2019 17:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=/8o5YkoRtwtGSeQdibqqODdPidptNTHfT0dZ1/XaUlc=; b=BQE4vyuZvfVwaTNl/zR/8mSOv8V/6GZNWMW7UnGktAxXbV9ekrozhPUhn8rFr0XzCo BODk5RJiVT5Xee6WJd1emwkgcblroMAeATrYB1ze2PrfafnWGVqChhkfRARtBGJ5wNHe kEYWi8ZJ5eQOEnRwLParVjmScg5zTa5KWZyhwMXhsKaPUs7ZHsGrfvxZU0BIbGvy88Vt dZ79neGUKdCLy4zKP32REGAy2SekcfUMcl98/eA3tYcQ08lTp9h/pMSGYqxad95Xi0N9 ASDnT3rntFQGK4+cW6sIBLgwmofIMUenrUnubELefkNKANq4fqOIgJtX1Wtv/pTPuBsW eHpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=/8o5YkoRtwtGSeQdibqqODdPidptNTHfT0dZ1/XaUlc=; b=aeKABzyaEsgwl65Rzs1UJkz36WW0zWicqfUwQQR85UxDJxyC9jK1J6bjZJcD4xNc59 ER8NzBOABNUARuZCc6GydxzeuUX6BDWQS47TN8pJOMYeGOyy1qutMrzfYRuuuRO4wV59 AuQDUDOE7lJaU0iWpCLyVmYuglVeH1AYcVvysRi+NouUHZ3QH2kIBKijALhAsQRv9B90 GdJ85FMuQ/tcTK5nJsFcSrK7mg5s97lFSGLHuLOp/EH23xpMh7Q/i/sePiLPTI1HXpez yzvttpI+XJQdl0tfBIjO5aVR9d/CwP/oQAoJsFLRqRq43p+LxItZraJcOVWnpl/QgbhB eVow== X-Gm-Message-State: APjAAAVy3D61wurb3Rhi/0DJlyz1o5dDB1VqsumZb8h//cKD0FHGv7M2 6aouYQGkdyKEH5f40A3f5Hs= X-Google-Smtp-Source: APXvYqxmZwexPb2BX4rBcZ7LD29frdtjXFq+NUmYWoWGz2AmScc3CN1tO6KSGISPwFDViE1paXphIw== X-Received: by 2002:a65:65c5:: with SMTP id y5mr30146170pgv.342.1568163101167; Tue, 10 Sep 2019 17:51:41 -0700 (PDT) Received: from localhost ([2001:240:2405:add8:4808:75d4:5911:fd84]) by smtp.gmail.com with ESMTPSA id m19sm760365pjv.9.2019.09.10.17.51.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Sep 2019 17:51:40 -0700 (PDT) Date: Wed, 11 Sep 2019 09:51:24 +0900 From: Nat Sakimura To: Marius Scurtescu , Masakazu OHTSUKA Cc: oauth mailing list , Filip Skokan Message-ID: <9e3c2bee-6d15-4073-9d50-ef5454405cd9@Spark> In-Reply-To: References: X-Readdle-Message-ID: 9e3c2bee-6d15-4073-9d50-ef5454405cd9@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5d784515_5c03170e_4c31" Archived-At: Subject: Re: [OAUTH-WG] Public client cloning 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: Wed, 11 Sep 2019 00:51:45 -0000 --5d784515_5c03170e_4c31 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline As =46ilip mentioned, I feel that claimed HTTPS URI would help. =46urther= , if that is used within the dynamic client registration, it could be mor= e secure. The security assumptions are 1. Phone is not rooted; 2. App Store's vetting of claimed URI is not compromised; etc. Nat Sakimura Chairman, OpenID =46oundation https://nat.sakimura.org 2019=E5=B9=B49=E6=9C=8811=E6=97=A5 4:27 +0900=E3=80=81Masakazu OHTSUKA =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: > I see. > > Then is this understandable to think from the Authorization Server's po= int of view ... > > If phone being compromised is a threat that the Client cares, > AS might be interested in NOT supporting public Clients, > and forcing the Client to have a server side, do client authentication,= and have some way to hold a session between the native app and it's serv= er side. > > Because if phone is compromised, when AS supports public Clients and ac= cess=5Ftoken leaks, it's kind of AS's fault (well depending on the terms.= ..), > but if whatever the means that the phone app and it's server side keeps= a session leaks, it's NOT the AS's fault. > > > > On Tue, Sep 10, 2019 at 8:23 PM Marius Scurtescu wrote: > > > If the phone is compromised, original app replaced by malicious app= , then R=46C8252 will not help. The assumption is that the phone is not c= ompromised. > > > > > > > On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA wrote: > > > > > Hi, > > > > > > > > > > I've read rfc8252 and have questions about native apps, that I = couldn't find answers on Internet. > > > > > > > > > > Imagine an attacker doing: > > > > > 1. original app and authorization server conforms to rfc8252 4.= 1.=C2=A0 Authorization =46low for Native Apps Using the Browser > > > > > 2. clone the original app, name it malicious app and install on= the target phone > > > > > 3. remove the original app from the target phone > > > > > 4. use the malicious app and authorize, OS will invoke maliciou= s app using custom URL scheme > > > > > 5. now malicious=C2=A0app has access to the access token > > > > > > > > > > How should we think about this=3F > > > > > What am I missing=3F > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > > > > OAuth mailing list > > > > > OAuth=40ietf.org > > > > > https://www.ietf.org/mailman/listinfo/oauth > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > OAuth mailing list > OAuth=40ietf.org > https://www.ietf.org/mailman/listinfo/oauth --5d784515_5c03170e_4c31 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
As =46ilip mentioned, I feel that claimed HTTPS URI would help. =46u= rther, if that is used within the dynamic client registration, it could b= e more secure.

The security assumptions are

1. Phone is not rooted;
2. App Store's vetting of claimed URI is not compromised; etc.

Nat Sakimura
Chairman, OpenID =46oundation
https://nat.sakimura.org
2019=E5=B9=B49=E6=9C=8811=E6=97=A5 = 4:27 +0900=E3=80=81Masakazu OHTSUKA <o.masakazu=40gmail.com>=E3=81=AE= =E3=83=A1=E3=83=BC=E3=83=AB:
I see.

Then is this understandable to think from the Authorization Server's= point of view ...

If phone being compromised is a threat that the Client cares,
AS might be interested in NOT supporting public Clients,
and forcing the Client to have a server side, do client authenticati= on, and have some way to hold a session between the native app and it's s= erver side.

Because if phone is compromised, when AS supports public Clients and= access=5Ftoken leaks, it's kind of AS's fault (well depending on the ter= ms...),
but if whatever the means that the phone app and it's server side ke= eps a session leaks, it's NOT the AS's fault.


On Tue, Sep 10, 2019 at 8= :23 PM Marius Scurtescu <marius.scurtescu=40coinbase.com> wrote:
If the phone is compromised, original app replaced b= y malicious app, then R=46C8252 will not help. The assumption is that the= phone is not compromised.

On Tue, Sep 10, 2019 at 9= :58 AM Masakazu OHTSUKA <o..masakazu=40gmail.com> wrote:
Hi,

I've read rfc8252 and have questions about native apps, that I could= n't find answers on Internet.

Imagine an attacker doing:
1. original app and authorization server conforms to rfc8252 4.1.&=23= 160; Authorization =46low for Native Apps Using the Browser
2. clone the original app, name it malicious app and install on the = target phone
3. remove the original app from the target phone
4. use the malicious app and authorize, OS will invoke malicious app= using custom URL scheme
5. now malicious&=23160;app has access to the access token

How should we think about this=3F
What am I missing=3F

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mailing list
OAuth=40i= etf.org
https://www.ietf.org/mailman/listinfo/o= auth
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mailing list
OAuth=40ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--5d784515_5c03170e_4c31-- From nobody Wed Sep 11 00:26:22 2019 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 29CCE120810 for ; Wed, 11 Sep 2019 00:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 y_-ysY6alfFM for ; Wed, 11 Sep 2019 00:26:18 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 1CDB212009C for ; Wed, 11 Sep 2019 00:26:18 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id h144so43499081iof.7 for ; Wed, 11 Sep 2019 00:26:18 -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=M2qK6RPTRLNkKuT89TPL+ybUUIlfXr/YDGerj8C7UDk=; b=peTSnAlrDgNRk58Swx2zWoEwaiIhnsBIU0AoxYv/lDIB4l9lvtLylS/ySMvKd8os6+ nTam2W/OfYsiEDEJ008hojO2trDUsH/kmg9KCNJcBDgjZ+hXe8nqBvHZ58wY9BSqxwzp +qgZjquEqRecqVbasPNP/WDX1SIpADquV5x/GT7j2pAvnUOaPJLKQMBrmm8+1TUv6cC4 w8eBhNJ2R1Mrt3rExWsrie5YkZl2PrI06w1Ma001D2miOi0uko1JFdIGLWaL3KH61LNy Mqr90AfVQDYmXkS9V+WaOPpUfCnuOHauXXIaU5Yes/lvhQ4ErAB0h6iQKQOORV9Zdren dpfQ== 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=M2qK6RPTRLNkKuT89TPL+ybUUIlfXr/YDGerj8C7UDk=; b=AL2A8WzqcprfCb+ENsQWkyBqI8JAhDWFVGwC+9E3ZwsTp2SS0Pn4xnxf+ucai8df9w FqTh07nYrxr8T1c7LucCjz28Fsw8OlQ8dq5Knzvj6vLd6qIS18gS3TYSefQz+KJlv1Iq xV8xexhgAxZaxKWyCIvYXNoHjaWJkYouiAzk7zeOvT7FXQZd4DWGP7UkU/26XO/3BlMk d84IXDXoL93cej3UbiOnkco0jV4kzyr8hKwSAZDE+lMy5UmWiAVI/q2uiwTuCEm/0lUU CIw0sfuTEfGoWwi4vqDgwtgMZe9Xiq2fzUowynLg9TikwYAH4D0+IlDF+oEj+80lSI/H ZJEw== X-Gm-Message-State: APjAAAXHQiQZosEmVgh5pdI1hQMd4HGwTDtSdqlyzu4pb5mNHXbYEFqS Ua6GxiGdwZ1nMp5C2xCPa+MNKLUuSm+UtPyE5uc= X-Google-Smtp-Source: APXvYqycjyp3c8gmvq9Lk8sJIlTeZ3k/GqlJtT5vnrWiU19ZqBu/QAXnvpNJTWLCi8yT2/F4X9FKdEQqLIoZK0UcGpM= X-Received: by 2002:a5d:9153:: with SMTP id y19mr17619872ioq.109.1568186777229; Wed, 11 Sep 2019 00:26:17 -0700 (PDT) MIME-Version: 1.0 References: <9e3c2bee-6d15-4073-9d50-ef5454405cd9@Spark> In-Reply-To: <9e3c2bee-6d15-4073-9d50-ef5454405cd9@Spark> From: Masakazu OHTSUKA Date: Wed, 11 Sep 2019 10:26:06 +0300 Message-ID: To: Nat Sakimura Cc: Marius Scurtescu , oauth mailing list , Filip Skokan Content-Type: multipart/alternative; boundary="000000000000cc66f9059241ef59" Archived-At: Subject: Re: [OAUTH-WG] Public client cloning 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: Wed, 11 Sep 2019 07:26:20 -0000 --000000000000cc66f9059241ef59 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Okay, Marius, Filip and Nat, thank you for your answers. :) On Wed, Sep 11, 2019 at 3:51 AM Nat Sakimura wrote: > As Filip mentioned, I feel that claimed HTTPS URI would help. Further, if > that is used within the dynamic client registration, it could be more > secure. > > The security assumptions are > > 1. Phone is not rooted; > 2. App Store's vetting of claimed URI is not compromised; etc. > > Nat Sakimura > Chairman, OpenID Foundation > https://nat.sakimura.org > 2019=E5=B9=B49=E6=9C=8811=E6=97=A5 4:27 +0900=E3=80=81Masakazu OHTSUKA =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: > > I see. > > Then is this understandable to think from the Authorization Server's poin= t > of view ... > > If phone being compromised is a threat that the Client cares, > AS might be interested in NOT supporting public Clients, > and forcing the Client to have a server side, do client authentication, > and have some way to hold a session between the native app and it's serve= r > side. > > Because if phone is compromised, when AS supports public Clients and > access_token leaks, it's kind of AS's fault (well depending on the > terms...), > but if whatever the means that the phone app and it's server side keeps a > session leaks, it's NOT the AS's fault. > > > On Tue, Sep 10, 2019 at 8:23 PM Marius Scurtescu < > marius.scurtescu@coinbase.com> wrote: > >> If the phone is compromised, original app replaced by malicious app, the= n >> RFC8252 will not help. The assumption is that the phone is not compromis= ed. >> >> On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA > > wrote: >> >>> Hi, >>> >>> I've read rfc8252 and have questions about native apps, that I couldn't >>> find answers on Internet. >>> >>> Imagine an attacker doing: >>> 1. original app and authorization server conforms to rfc8252 4.1. >>> Authorization Flow for Native Apps Using the Browser >>> 2. clone the original app, name it malicious app and install on the >>> target phone >>> 3. remove the original app from the target phone >>> 4. use the malicious app and authorize, OS will invoke malicious app >>> using custom URL scheme >>> 5. now malicious app has access to the access token >>> >>> How should we think about this? >>> What am I missing? >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000000000000cc66f9059241ef59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Okay,
Marius, Filip and Nat, thank you for your answer= s. :)

On Wed, Sep 11, 2019 at 3:51 AM Nat Sakimura <sakimura@gmail.com> wrote:
As Filip mentioned, I feel that claimed HTTPS URI would help. Further,= if that is used within the dynamic client registration, it could be more s= ecure.

The security assumptions are

1. Phone is not rooted;
2. App Store's vetting of claimed URI is not compromised; etc.

Nat Sakimura
Chairman, OpenID Foundation
https://nat.sakimura= .org
2019=E5=B9=B49=E6=9C=8811=E6=97=A5 4:27 += 0900=E3=80=81Masakazu OHTSUKA <o.masakazu@gmail.com>=E3=81=AE=E3=83=A1=E3=83=BC=E3= =83=AB:
I see.

Then is this understandable to think from the Authorization Server'= ;s point of view ...

If phone being compromised is a threat that the Client cares,
AS might be interested in NOT supporting public Clients,
and forcing the Client to have a server side, do client authentication= , and have some way to hold a session between the native app and it's s= erver side.

Because if phone is compromised, when AS supports public Clients and a= ccess_token leaks, it's kind of AS's fault (well depending on the t= erms...),
but if whatever the means that the phone app and it's server side = keeps a session leaks, it's NOT the AS's fault.


On Tue, Sep 10, 2019 at 8:23 PM Mariu= s Scurtescu <marius.scurtescu@coinbase.com> wrote:
If the phone is compromised, original app replaced by mali= cious app, then RFC8252 will not help. The assumption is that the phone is = not compromised.

On Tue, Sep 10, 2019 at 9:58 AM Masak= azu OHTSUKA <o= ..masakazu@gmail.com> wrote:
Hi,

I've read rfc8252 and have questions about native apps, that I cou= ldn't find answers on Internet.

Imagine an attacker doing:
1. original app and authorization server conforms to rfc8252 4.1.=C2= =A0 Authorization Flow for Native Apps Using the Browser
2. clone the original app, name it malicious app and install on the ta= rget phone
3. remove the original app from the target phone
4. use the malicious app and authorize, OS will invoke malicious app u= sing custom URL scheme
5. now malicious=C2=A0app has access to the access token

How should we think about this?
What am I missing?

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--000000000000cc66f9059241ef59-- From nobody Wed Sep 11 02:22:44 2019 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 65D6E12083A for ; Wed, 11 Sep 2019 02:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=armh.onmicrosoft.com header.b=YgzVHoZ6; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=M3WCWqjr 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 7HGmWcJySOcm for ; Wed, 11 Sep 2019 02:22:41 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10083.outbound.protection.outlook.com [40.107.1.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09E3120837 for ; Wed, 11 Sep 2019 02:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OniaOdH6ImqQ8pIbw8xtMLHhISDLSb6vXrddvuMf1gY=; b=YgzVHoZ6w6YmTW0ekR8FOSEqVxdNt2B2h0pOpcfYw/ja6g2DnfNWgVbgMf6+PcsYRCOtTfSTEcOX7iF11RdiU+nrLL0j4onjcTzIKZrC8zvmtxzULnUlMQW3CdWKDpRTQqcIwlG75Cv3ZIuoM6Fl4xKu5MaJW3/UgtEZkM88zvc= Received: from DB7PR08CA0043.eurprd08.prod.outlook.com (2603:10a6:10:26::20) by AM0PR08MB4500.eurprd08.prod.outlook.com (2603:10a6:208:147::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.15; Wed, 11 Sep 2019 09:22:36 +0000 Received: from VE1EUR03FT052.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::209) by DB7PR08CA0043.outlook.office365.com (2603:10a6:10:26::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.15 via Frontend Transport; Wed, 11 Sep 2019 09:22:35 +0000 Authentication-Results: spf=temperror (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=none action=none header.from=arm.com; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of arm.com: DNS Timeout) Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT052.mail.protection.outlook.com (10.152.19.173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.14 via Frontend Transport; Wed, 11 Sep 2019 09:22:33 +0000 Received: ("Tessian outbound 46f6b453ea6b:v29"); Wed, 11 Sep 2019 09:22:33 +0000 X-CR-MTA-TID: 64aa7808 Received: from e66c7e1a58e0.1 (ip-172-16-0-2.eu-west-1.compute.internal [104.47.2.58]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id DDAFD4AC-0A38-4DB5-8FCF-7BCF1756B88C.1; Wed, 11 Sep 2019 09:22:28 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp2058.outbound.protection.outlook.com [104.47.2.58]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e66c7e1a58e0.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384); Wed, 11 Sep 2019 09:22:28 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EeL8ERSbpt03dKjCdYJCjlszDmh8UKKrg2yT1C1ZslvGBLsCDw43u3JN+P9YswE5WqzCG2RqQlS2ml1akmOwo7pGtP91zDEibN6hAE8Ph/uGyrrHk6BfcxcmgaYyJsFFNUpXZojmhy+BN9xCai3eCs3a0jYW9nlnVzM9j8+0nLstAIxm87NhfjPZEY0mUErAiGesZC7sgzV86jXfy7CBuHfELK6mLlSPLVPZFo9XomIQKtjeZfs4eZtO6os54wx3D/3GELmeuIZgdbRPgaLgN3y58Atgt5KuRoLBBJl0pCn1ELjCtqAAqHsnmGKqp4UCMD9Yn3sX7s3YgQzlNqCngg== 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=UBmFVzgnjW79U351bH8Gux/THXI6Org9EwdGDImBoYk=; b=W9NSBIFsL5L6yYtDF5PhgpfxACkTrAmxVYvYEeGWSotBhI7q0K31BBkFKW0fnKMSlk0bFN6y8s1f/wZF5PbIJRWDMG/0F7gpNSfed+8bt3UW/F1STAxdL102fq0DjCrCXjVJFBsEjzXiGgVf8hdEvp7DanNurr3uI8kS9gWX8b8G+DYvtFzRiNK17FmSuj9VIlc2r9zN5+uJiRxWSG20AM3QMgB3yDSCpYN0/FIMxhjO+ZsDPhqOcm5p1HyQZzUyWujIthQzYlHnHpOKb2PmAPmxtBtAeCworWRSd/bFD8pT2Jco8bboNQcA/MnGcgT6S454U42DU/M89wCbTVbwtw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UBmFVzgnjW79U351bH8Gux/THXI6Org9EwdGDImBoYk=; b=M3WCWqjrmGpQQMDVQ+tjM3ElY0agurTI5cooH+pPn/8XwaVbBau9BP3xZ9Cd4RV0dCI9J3swHyUZCBYE4OlxEHnRDrOeMMKbFNM07VDXT7sBxts0sWQqBrBGoQ96bAZt4s84vLQNgWyDw3MW4auvFvFnm50ntE18UdQ7tzdaEoE= Received: from VI1PR08MB5360.eurprd08.prod.outlook.com (52.133.245.74) by VI1PR08MB3629.eurprd08.prod.outlook.com (20.177.61.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.15; Wed, 11 Sep 2019 09:22:27 +0000 Received: from VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::75c6:eb5c:b4d5:8bed]) by VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::75c6:eb5c:b4d5:8bed%3]) with mapi id 15.20.2241.022; Wed, 11 Sep 2019 09:22:27 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: WGLC on draft-ietf-oauth-incremental-authz-01 Thread-Index: AdVogknoAnP654JhQ3S9QtbLhNiL0g== Date: Wed, 11 Sep 2019 09:22:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: f11bfd6f-2f2d-4b21-a910-efdf8f725670.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.116.176] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 1175485a-5c19-4bff-d7e8-08d73699944b X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam-Untrusted: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:VI1PR08MB3629; X-MS-TrafficTypeDiagnostic: VI1PR08MB3629:|AM0PR08MB4500: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:5236;OLM:5236; x-forefront-prvs: 0157DEB61B X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(366004)(396003)(346002)(39860400002)(53754006)(189003)(199004)(7696005)(6306002)(256004)(316002)(66946007)(54896002)(6916009)(2906002)(66476007)(76116006)(66446008)(9686003)(8936002)(486006)(55016002)(81166006)(81156014)(186003)(25786009)(53936002)(476003)(99286004)(6506007)(102836004)(558084003)(86362001)(6436002)(8676002)(26005)(74316002)(7736002)(52536014)(478600001)(64756008)(66556008)(71200400001)(71190400001)(3846002)(33656002)(5660300002)(790700001)(6116002)(66066001)(14454004)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR08MB3629; H:VI1PR08MB5360.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info-Original: l7ZZc0RYdsp9Q/OTUaDcJE8mBWzwc4d9b4p5BDYve2aSK951DJhqZEeOqytgdD6UWR1HLnIjhyqWeSFdXNsgRtF3wB1t7vtECd/g8TzBq/xJvYU6PbZORT4V3Ety5B/8Wak2PO0dhonJMmNy4csfK9pn7Ka9Pd8ueXGzIeyNKAx5V3eX2Zy6uYPaTQ7l928Ntvs6ktCxlh62wgIRNctpJg9+nIl705C2yPPKFdoU+cKftaQiKyh4WHGssco8L1ZmojECgT8QAolCwzX55rjqKnDB/5PMos8yxqyMx5213O4j+WGmXIcjfx7LLwcWDfo9oU2ftzJm2+1DeyXg/blCUuqFJn2J79DEs5Qr5CrAFJFChfAZM99IEPl7NAaK4GofvvrF5w66OnQoMBuiiuvLnZZJHKRjxgpV4z2KAb7w3Zo= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_VI1PR08MB5360BBDDDF8362B40C97AF18FAB10VI1PR08MB5360eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3629 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT052.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(376002)(136003)(39860400002)(53754006)(199004)(189003)(40434004)(8936002)(186003)(336012)(102836004)(70206006)(5660300002)(22756006)(54896002)(6306002)(9686003)(33656002)(26005)(25786009)(55016002)(476003)(486006)(7696005)(7736002)(99286004)(76130400001)(74316002)(126002)(52536014)(5024004)(14444005)(70586007)(6116002)(316002)(790700001)(3846002)(36906005)(86362001)(71190400001)(16586007)(478600001)(66066001)(26826003)(14454004)(8676002)(63350400001)(6506007)(81166006)(81156014)(6916009)(2906002)(966005)(356004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB4500; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:TempError; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: 2ba76c24-03a7-44de-a80f-08d73699908a X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(710020)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR08MB4500; X-MS-Exchange-PUrlCount: 1 X-Forefront-PRVS: 0157DEB61B X-Microsoft-Antispam-Message-Info: W7OlNCb8YmLSy5k0V0OwD2cnC/QB4h+Uf7B3dQ3u9byUR+CLhlKd6FY2NSbZugegDq8KA/hBQl26ETwoefoCTvf1Y++Xs3pm701L9+f9KU8e4iG4P9aCnZt1ZhyY5MnCzOKc6VjeCbJDfi6oo1siySIudiKrbZvf9GwfKYngJxgt+q6Qc0pt/f5MSDGTSIJQZqxkw5q/A8MLr1mqYYy1j9F7T4ya1nG7WkOKugE4fq7AKkMEE9V8RKrBlh1G6NXuw0lvJsGJU3w27oMKUQizrkAnKoi7jleEAhJiiic/vYYX8xogGijvWaEVvexj7L29Sn1d3eOJw8cWsiUUtCekX+KcmagWTyXivgYmf/NeNaaFSENvTz2RIKhX9E6fj0xsbM6Kl47N4mQKwHi2Y/ASDiaYToANKrZKYwVSe94NWFo= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2019 09:22:33.9176 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1175485a-5c19-4bff-d7e8-08d73699944b X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4500 Archived-At: Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01 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: Wed, 11 Sep 2019 09:22:43 -0000 --_000_VI1PR08MB5360BBDDDF8362B40C97AF18FAB10VI1PR08MB5360eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We are starting a WGLC on the "OAuth 2.0 Incremental Authorization" draft. = You can find the document here: https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-01 Please review the document and provide feedback. The WGLC will end September 25th, 2019. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR08MB5360BBDDDF8362B40C97AF18FAB10VI1PR08MB5360eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We are starting a WGLC on the "OAuth 2.0 Increm= ental Authorization" draft. You can find the document here:=

https://tools.ietf.org/html/draft-ietf-oauth-increme= ntal-authz-01

 

Please review the document and provide feedback.

 

The WGLC will end September 25th, 2019.

 

Ciao

Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR08MB5360BBDDDF8362B40C97AF18FAB10VI1PR08MB5360eurp_-- From glen.mazza@gmail.com Wed Sep 11 05:33:30 2019 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 9345F1208AC for ; Wed, 11 Sep 2019 05:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 sS9QGj2LXB2b for ; Wed, 11 Sep 2019 05:33:28 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 72EFC1208A7 for ; Wed, 11 Sep 2019 05:33:28 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id p13so3333806wmh.1 for ; Wed, 11 Sep 2019 05:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=x6oUCxHqqUgCpNkMuQL30MF9JL7Iypw0Zp4pyOaa7EI=; b=ahuPs107AizGK0P55LeMoQ+FJqqwU+xJwGzLD98injeboqH60yAq7l1Zq+SNMCNCY/ rLLoChWR0DPh94g9YDKi8Y/9ChRD+o76DlujNejEboTB7JpXwIHmK4gK1aytW6UqFIvx BwJP+58MlZis2j6p80/zsCaz2BpyFZ6mJFBqTPT9bGjDYSPwZV3TQEIApa/YtPgffo/A 0Il3vmDMLi7+Ls5Sn2MXTV24Zng2+1TmAbgmxm3xo5Epz3fAOZSPAszhT8Gf6yqVNJ1T w1UGjedFQlAzfTJrHZLf4r5ti43LyH5B7KxxFGpghcAD2Z6xpO5oCV/LrdlEssAvPDd8 xFHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=x6oUCxHqqUgCpNkMuQL30MF9JL7Iypw0Zp4pyOaa7EI=; b=nLdP2TS6LdSDceVzUd474WrNzfhxyyLbH4BcuKezwxcjstzn5Cj2e62g1fQadKL+hF W1p+wlwdkCFYyXXHQtCMTnE748ARHEVgGkih5P8ys4OLZeJVhYuqhFz0rZWTnb+mm3jA B/OAXg/ewRr8MpAdkN10IPIcY8i4J+T2krHecGEGBih9tkwHMIIIrGq5JJttNd52Cfaa IVfqxQFMJpD7VUzUxmDWhc0inIl5qQn4NmhjVq0brilWByohRaTxgVfGZe44HAgYvDz5 H/wgRyNdH+fwxSyrnWWmjcOi7iNGH2YIKCBnC5h6sGf1gP8dwYh+fZmF+3XFmXW4Qsd1 suIA== X-Gm-Message-State: APjAAAUie6m9WKY5d7AGMldcxu9O1Lkji+dHH6sO1rrBlEgku27r6EZI 6XcS7GvVWkiAAozhmigWtMrAIj/tqUe7wKmiuBCe00Zwew0= X-Google-Smtp-Source: APXvYqykERCF21xByhtNh/z4BY4vSf4tRF3baHc6M/BBXIBuuvUSJwslJweDDMnJLhvWHxrqVO5g7JmYJY7rfMU5dIc= X-Received: by 2002:a1c:7407:: with SMTP id p7mr4041720wmc.31.1568205206517; Wed, 11 Sep 2019 05:33:26 -0700 (PDT) MIME-Version: 1.0 From: Glen Mazza Date: Wed, 11 Sep 2019 08:33:15 -0400 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000044fbaf0592463a11" Archived-At: Subject: [OAUTH-WG] Comments on draft-ietf-oauth-incremental-authz-01 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: Wed, 11 Sep 2019 12:34:56 -0000 --00000000000044fbaf0592463a11 Content-Type: text/plain; charset="UTF-8" In Section 6.1, Handling Denials of incremental authorization requests, I wonder if the resource owner should be provided the ability by the Authorization Server to reject not just the additional scope(s) but also all previously granted ones. This would be to guard against the client withholding dubious permission requests at the outset that might indicate to the resource owner that the client isn't particularly reliable, scopes that if they were provided all at once at the beginning would have resulted in the user never approving any of them. In the user is inclined to deny an additional permission request due to a newfound lack of trust, he may also want to immediately decline previously granted permissions as well. In Section 7.2, it seems odd for the Authorization Server to rely on the client to tell it what scopes has already been approved for it. I would think there would need to be a mechanism for the Auth Server to verify that information, but given that, why not rely on that information directly instead of what the client would be informing it? Regards, Glen --00000000000044fbaf0592463a11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In Section 6.1, Handling Denials of incremental authorizat= ion requests, I wonder if the resource owner should be provided the ability= by the Authorization Server to reject not just the additional scope(s) but= also all previously granted ones.=C2=A0 This would be to guard against the= client withholding dubious permission requests at the outset that might in= dicate to the resource owner that the client isn't particularly reliabl= e, scopes that if they were provided all at once at the beginning would hav= e resulted in the user never approving any of them.=C2=A0 In the user is in= clined to deny an additional permission request due to a newfound lack of t= rust, he may also want to immediately decline previously granted permission= s as well.

In Section 7.2, it seems odd for the Authorization Serve= r to rely on the client to tell it what scopes has already been approved fo= r it.=C2=A0 I would think there would need to be a mechanism for the Auth S= erver to verify that information, but given that, why not rely on that info= rmation directly instead of what the client would be informing it?

R= egards,
Glen
--00000000000044fbaf0592463a11-- From nobody Wed Sep 11 10:06:41 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E715B1201E4; Wed, 11 Sep 2019 10:06:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Cc: rdd@cert.org, The IESG , Rifaat Shekh-Yusef , rifaat.ietf@gmail.com, oauth@ietf.org, draft-ietf-oauth-resource-indicators@ietf.org, oauth-chairs@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156822159987.13427.2378166334301574021.idtracker@ietfa.amsl.com> Date: Wed, 11 Sep 2019 10:06:39 -0700 Archived-At: Subject: [OAUTH-WG] Protocol Action: 'Resource Indicators for OAuth 2.0' to Proposed Standard (draft-ietf-oauth-resource-indicators-07.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 17:06:40 -0000 The IESG has approved the following document: - 'Resource Indicators for OAuth 2.0' (draft-ietf-oauth-resource-indicators-07.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ Technical Summary An extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. Working Group Summary The document adds new parameter for requests sent by a Client to an Authorization Server. The document received many reviews and feedback from multiple WG members on the mailing list and during the WG meetings. The document was updated to reflect a late review to make sure that the document makes it clear that the parameter might carry a location or an abstract identifier. Document Quality The document has been implemented by the following: * Ping has an implementation but with a different parameter name ("aud"): https://documentation.pingidentity.com/pingfederate/pf92/index.shtml#adminGuide/tokenEndpoint.html * Microsoft https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-oauth-code * Auth0 has an implementation but with a different parameter name ("audience"): https://auth0.com/docs/api/authentication#authorize-application * Node.JS Open Source oidc-provider implements the draft in full https://github.com/panva/node-oidc-provider/blob/master/docs/configuration.md#featuresresourceindicators * ARM has an implementation as part of the Pelion Secure Device Access (SDA) product: https://cloud.mbed.com/docs/v1.2/device-management/secure-device-access.html Personnel The document shepherd is Rifaat Shekh-Yusef. The responsible Area Director is Roman Danyliw. From nobody Wed Sep 11 10:27:53 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 829DA120B48; Wed, 11 Sep 2019 10:27:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Cc: rdd@cert.org, draft-ietf-oauth-mtls@ietf.org, Rifaat Shekh-Yusef , The IESG , rifaat.ietf@gmail.com, oauth@ietf.org, oauth-chairs@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156822285946.13296.12014085900062306101.idtracker@ietfa.amsl.com> Date: Wed, 11 Sep 2019 10:27:39 -0700 Archived-At: Subject: [OAUTH-WG] Protocol Action: 'OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens' to Proposed Standard (draft-ietf-oauth-mtls-17.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 17:27:40 -0000 The IESG has approved the following document: - 'OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens' (draft-ietf-oauth-mtls-17.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ Technical Summary This document describes OAuth client authentication and certificate bound access tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization sever using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. Working Group Summary There is consensus on the contents of this document. This work was motivated by a request from OpenBanking UK to allow the OAuth Client and OAuth Authorization Server establish a mutually authenticated channel. Document Quality A number of people reviewed the document over several rounds of reviews and provided feedback during meetings and on the mailing list, with no blocking comments. Implementations: Ping Identity has implemented one of the two methods, PKI-based method. Ping Identity also supports the certificate bound access token. Authlete has an implementation of this document. https://www.authlete.com/ ConnectId has an implementation. https://connect2id.com/blog/connect2id-server-6.13 oidc-provider: https://github.com/panva/node-oidc-provider References: OpenBanking UK reference this document https://openbanking.atlassian.net/wiki/spaces/DZ/pages/83919096/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.2 OpenID WG reference https://bitbucket.org/openid/mobile/src/default/draft-mobile-client-initiated-backchannel-authentication.xml?fileviewer=file-view-default OpenID Foundation FAPI WG ref to MTLS https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md?fileviewer=file-view-default Berlin Group‘s Nextgen PSD2 Spec: https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95bb.pdf Personnel The document shepherd is Rifaat Shekh-Yusef. The responsible Area Director is Roman Danyliw. From nobody Wed Sep 11 10:36:33 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B10D1120B61; Wed, 11 Sep 2019 10:36:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156822338468.13389.9013350629766933154@ietfa.amsl.com> Date: Wed, 11 Sep 2019 10:36:24 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 17:36:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Resource Indicators for OAuth 2.0 Authors : Brian Campbell John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-resource-indicators-08.txt Pages : 14 Date : 2019-09-11 Abstract: This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-08 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-resource-indicators-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 12 07:40:15 2019 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 A1FCE120851 for ; Thu, 12 Sep 2019 07:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=armh.onmicrosoft.com header.b=gNymBC4S; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=+HYZkw2g 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 1t3h5bHlAKLe for ; Thu, 12 Sep 2019 07:40:08 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40043.outbound.protection.outlook.com [40.107.4.43]) (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 D5435120119 for ; Thu, 12 Sep 2019 07:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vy703y6pU8xC0QUDftCkQryE7NoZEuL071dzo8rQ6Ps=; b=gNymBC4S+NcZL1zVzT+G+xToBDeKnoFu0Kx7KY3RP5E+EhjDrwjDMkkJQLxivyxeoPw9y0QDi+F+jky/CoScpwVsy3jGaq114xbhYQ2p9EplTRBHsHHU12VKK8wiUERJvQQYlGgQ8bbINR1fDKRkYTpOFndgMREBoxAMV6+6foA= Received: from VI1PR08CA0164.eurprd08.prod.outlook.com (2603:10a6:800:d1::18) by AM6PR08MB3687.eurprd08.prod.outlook.com (2603:10a6:20b:90::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.17; Thu, 12 Sep 2019 14:40:04 +0000 Received: from AM5EUR03FT031.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::201) by VI1PR08CA0164.outlook.office365.com (2603:10a6:800:d1::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2263.14 via Frontend Transport; Thu, 12 Sep 2019 14:40:04 +0000 Authentication-Results: spf=temperror (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=none action=none header.from=arm.com; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of arm.com: DNS Timeout) Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT031.mail.protection.outlook.com (10.152.16.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2263.14 via Frontend Transport; Thu, 12 Sep 2019 14:40:03 +0000 Received: ("Tessian outbound d5a1f2820a4f:v31"); Thu, 12 Sep 2019 14:40:03 +0000 X-CR-MTA-TID: 64aa7808 Received: from e6466d49f10f.1 (ip-172-16-0-2.eu-west-1.compute.internal [104.47.2.56]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id 1055D38D-74E8-43EB-B7BF-58719EC5E6F6.1; Thu, 12 Sep 2019 14:39:58 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp2056.outbound.protection.outlook.com [104.47.2.56]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e6466d49f10f.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 12 Sep 2019 14:39:58 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=odMraAtWJZtvpC9PCVPFY0e/kHYWAgfiuWmmF7A0oEuZ7k6quY+7GZMalwClzn2lNeHRu37p/4oJsBQi4zy/2iXevlWHv7q0oLhNGkFCIv+phb5CW9RT5lvRe6iI7M0IQEU3FWhtHrcVZRsUsjnFx4WhdDf9T7xEfd0PyJ3PKg2Euhz4rHJQGuinulW+/sbSE8LZZoD1Gf7C1nY9Up+SVzX0BNO/s4L/3q13BOphJh9sN8v5yKd53qtywNEXwO91yTshI4pK0Yd1YvLkeNVLVw08ya/e7QKcKZGdd2upVPVq5e5UUhSzaMy96fGlN72JDUX0tMvjNBPb2ypUKpnTvA== 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=7qbCgLN+A+SP6ZqxZnkrXj8jXU2bOktSZEleHdVRWqI=; b=E96mVzfQgVl5b/a19ldkpwfUqUAu8NuH0Y+97mSpowb0D0Go1bPjjmmxRIckjl4tjfw+DtANINi23piXgZYjMfofM+7OB6Lp9gTu2t7vzCTT9idqN0vZI9/xpGaiAoAg7vtwnfIDPR+tBCjj2YJI2uTMZ9BrOae0+rBB1JxNuMMbF6R34P32xPitX+kd/Fzt3HENMtaxkvsFc2WYXuhD4iMc2PWbXXDqtqFrbJyGLwlvM0vOXox8JfDA5SSs7o0E/PZvaWWdDN0UPr1fY5R+L7eRTMbXgALcJb7TGabQa1sjkzQ8ZcHkp5MjZ9mYt18UhQBmbApK8h029PTs4FO5kg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7qbCgLN+A+SP6ZqxZnkrXj8jXU2bOktSZEleHdVRWqI=; b=+HYZkw2gD6ruwpGyqQM/cWpXtxD1lLhypsyeUguB5V/1xZCEsxSI36XjFUfSUuO1Vvnxc9L3YObv+Tq+I2IDDgcyjAw7bWafYmfs2rSJlNokDTH7W7ewIgUIcZ2L8Vot51lfHNC9S+N/pJ7lWyeI1mUwowTk/mAV02M43dnBWUw= Received: from AM0PR08MB5345.eurprd08.prod.outlook.com (52.132.212.135) by AM0PR08MB5186.eurprd08.prod.outlook.com (20.179.39.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.13; Thu, 12 Sep 2019 14:39:57 +0000 Received: from AM0PR08MB5345.eurprd08.prod.outlook.com ([fe80::a820:853d:e981:a76c]) by AM0PR08MB5345.eurprd08.prod.outlook.com ([fe80::a820:853d:e981:a76c%2]) with mapi id 15.20.2263.016; Thu, 12 Sep 2019 14:39:57 +0000 From: Hannes Tschofenig To: Eve Maler CC: oauth Thread-Topic: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01 Thread-Index: AdVogknoAnP654JhQ3S9QtbLhNiL0gA8kmmAAADNjSA= Date: Thu, 12 Sep 2019 14:39:57 +0000 Message-ID: References: <736340BF-B33D-4407-81AF-532C947F1243@xmlgrrl.com> In-Reply-To: <736340BF-B33D-4407-81AF-532C947F1243@xmlgrrl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: fbf5721a-5305-46dc-8de3-1f2677ac7e56.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.158] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: fc9f46e5-2424-4354-142e-08d7378f190e X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam-Untrusted: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR08MB5186; X-MS-TrafficTypeDiagnostic: AM0PR08MB5186:|AM6PR08MB3687: X-MS-Exchange-PUrlCount: 3 X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:8882; x-forefront-prvs: 01583E185C X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(346002)(136003)(396003)(366004)(53754006)(51914003)(199004)(40434004)(189003)(53546011)(8676002)(6506007)(71190400001)(71200400001)(186003)(5660300002)(6246003)(52536014)(86362001)(66066001)(26005)(54896002)(316002)(76116006)(7736002)(74316002)(102836004)(33656002)(8936002)(81166006)(81156014)(4326008)(6916009)(11346002)(229853002)(446003)(486006)(476003)(966005)(66946007)(55016002)(66556008)(6116002)(3846002)(64756008)(66476007)(99286004)(236005)(508600001)(6306002)(14444005)(5024004)(256004)(606006)(25786009)(9686003)(790700001)(7696005)(6436002)(66446008)(2906002)(14454004)(76176011)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB5186; H:AM0PR08MB5345.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info-Original: 7GkQdWdypFJS4c2fd5CoO14jdY/NQDZhqTsYWFpsb0pSWO/aWkwEMG0lyVPBd8UQoGeHb9xPL7OoHU47z4lvzfuh/5pIbjk0AI5420CFhGSwqOWoP0GYZi+LWllXCqZWzF6uIg+WxWw83saRXmLmAZYZMbMlo1KS+3pbjcmk3I5+dBGRo73zHemu/HE8tdgc1B9Wo2HBC35CHENLnt2lpY5slrUxivMynrnocBPiGrBoS07YNOjmmNGxZPWwdczKtEY2xQx8J2u8jtIEuTq80OECW5KaXCZV17oPkERgQL6mT7pmMmdTQkJy/3uskkZJCPNWiDUtKcr5Nw47SqOl6UQaCtw9Gv3VPbeTv1s7gr1FLFEyHgjv39lb7r5XmCRAfBfcf9jvdTKWzV7FgilzI/Y7KGfZ91Ab4Tv65cV9qUc= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB5345B19B0AF2304AE8E110CAFAB00AM0PR08MB5345eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5186 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT031.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(346002)(136003)(396003)(51914003)(199004)(189003)(40434004)(53754006)(606006)(446003)(14454004)(70206006)(63350400001)(26826003)(336012)(6506007)(70586007)(36906005)(11346002)(6246003)(52536014)(53546011)(26005)(33964004)(33656002)(76176011)(8936002)(76130400001)(508600001)(6862004)(966005)(186003)(102836004)(2906002)(7696005)(9686003)(5024004)(6306002)(54896002)(55016002)(486006)(356004)(14444005)(8676002)(66066001)(5660300002)(99286004)(25786009)(4326008)(236005)(81156014)(81166006)(74316002)(476003)(229853002)(22756006)(316002)(86362001)(16586007)(126002)(6116002)(790700001)(3846002)(71190400001)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3687; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:TempError; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: e63cb615-e926-4961-6c5c-08d7378f1531 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(710020)(711020)(4605104)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM6PR08MB3687; X-Forefront-PRVS: 01583E185C X-Microsoft-Antispam-Message-Info: okSig6iPJtps9LWk7SqlDhWRXuKYtCnXj8pXLrxjJRkX+zEfpU/nJrpw+IX2GLHg+WGm1wvh4T4LF55odXjp3UTmgSvY0c2uz0Lju1DzqAEw/gBffzZUtmMgbxQKh9SZnkvWAIwRzMbslQgfVqnKd1+ooKnfimgjTnRATJHNJnoziSpEtRuRFNlEDoMIl/pMYr4YALOZkqS8BIPbaYMJJj4gga4A7gRQpv3oIPoYsY92kzyAy2qb97p1br731BB7ET2CxDgLjjbJ4XgJ7wzrTnIsYXej7B8yUOvfFCetrFeLcRR4XCimGjZH88DyK/y7nfPZP+VdEw7sgPeDuEBm6PznmmwDvAvDLdIDDZ3b9LBV+sZ7fdmefsbOLH2LHcSsS5BLqWiqyXBs7/7dlL12PHHILW6TX0u1SftAOQDrxl4= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2019 14:40:03.5678 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fc9f46e5-2424-4354-142e-08d7378f190e X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3687 Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01 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: Thu, 12 Sep 2019 14:40:12 -0000 --_000_AM0PR08MB5345B19B0AF2304AE8E110CAFAB00AM0PR08MB5345eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgY29ycmVjdGlvbjsgeWVzIOKAkyB0aGUgbW9zdCByZWNlbnQgdmVyc2lv biBpcyAtMDIgYW5kIEkgcG9zdGVkIGFuIG9sZCBsaW5rLg0KDQoNCkZyb206IEV2ZSBNYWxlciA8 ZXZlQHhtbGdycmwuY29tPg0KU2VudDogRG9ubmVyc3RhZywgMTIuIFNlcHRlbWJlciAyMDE5IDE2 OjE2DQpUbzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+DQpT dWJqZWN0OiBSZTogW09BVVRILVdHXSBXR0xDIG9uIGRyYWZ0LWlldGYtb2F1dGgtaW5jcmVtZW50 YWwtYXV0aHotMDENCg0KSSB0aGluayB5b3UgbWVhbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1vYXV0aC1pbmNyZW1lbnRhbC1hdXRoei0wMj8NCkV2ZSBNYWxlciAoc2Vu dCBmcm9tIG15IGlQYWQpIHwgY2VsbCArMSA0MjUgMzQ1IDY3NTYNCg0KT24gU2VwIDExLCAyMDE5 LCBhdCA0OjIyIEFNLCBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNv bTxtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4+IHdyb3RlOg0KSGkgYWxsLA0KDQpX ZSBhcmUgc3RhcnRpbmcgYSBXR0xDIG9uIHRoZSAiT0F1dGggMi4wIEluY3JlbWVudGFsIEF1dGhv cml6YXRpb24iIGRyYWZ0LiBZb3UgY2FuIGZpbmQgdGhlIGRvY3VtZW50IGhlcmU6DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1pbmNyZW1lbnRhbC1hdXRoei0w MQ0KDQpQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCBhbmQgcHJvdmlkZSBmZWVkYmFjay4NCg0K VGhlIFdHTEMgd2lsbCBlbmQgU2VwdGVtYmVyIDI1dGgsIDIwMTkuDQoNCkNpYW8NCkhhbm5lcyAm IFJpZmFhdA0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxl Z2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMg dG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3Ig Y29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlz dA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRl bnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFu ZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBk aXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkg cHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4g VGhhbmsgeW91Lg0K --_000_AM0PR08MB5345B19B0AF2304AE8E110CAFAB00AM0PR08MB5345eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIj MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB0aGUgY29ycmVjdGlvbjsgeWVzIOKAkyB0aGUg bW9zdCByZWNlbnQgdmVyc2lvbiBpcyAtMDIgYW5kIEkgcG9zdGVkIGFuIG9sZCBsaW5rLg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBFdmUgTWFsZXIgJmx0 O2V2ZUB4bWxncnJsLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBEb25uZXJzdGFnLCAxMi4g U2VwdGVtYmVyIDIwMTkgMTY6MTY8YnI+DQo8Yj5Ubzo8L2I+IEhhbm5lcyBUc2Nob2ZlbmlnICZs dDtIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W09BVVRILVdHXSBXR0xDIG9uIGRyYWZ0LWlldGYtb2F1dGgtaW5jcmVtZW50YWwtYXV0aHotMDE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPkkgdGhpbmsgeW91IG1lYW4mbmJzcDs8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1pbmNyZW1lbnRhbC1hdXRoei0w MiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtaW5jcmVtZW50 YWwtYXV0aHotMDI8L2E+PzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0 dXJlIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEzLjBwdCI+RXZlIE1hbGVyIChzZW50IGZyb20gbXkgaVBhZCkgfCZuYnNwO2NlbGwgJiM0Mzsx IDQyNSAzNDUgNjc1Njwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpPbiBTZXAgMTEsIDIwMTksIGF0IDQ6MjIgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBo cmVmPSJtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbSI+SGFubmVzLlRzY2hvZmVuaWdA YXJtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFy ZSBzdGFydGluZyBhIFdHTEMgb24gdGhlICZxdW90O09BdXRoIDIuMCBJbmNyZW1lbnRhbCBBdXRo b3JpemF0aW9uJnF1b3Q7IGRyYWZ0LiBZb3UgY2FuIGZpbmQgdGhlIGRvY3VtZW50IGhlcmU6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1pbmNyZW1lbnRhbC1hdXRoei0wMSI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtaW5jcmVtZW50YWwtYXV0 aHotMDE8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSByZXZpZXcgdGhlIGRvY3Vt ZW50IGFuZCBwcm92aWRlIGZlZWRiYWNrLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgV0dM QyB3aWxsIGVuZCBTZXB0ZW1iZXIgMjV0aCwgMjAxOS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q2lhbzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFubmVzICZhbXA7IFJp ZmFhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1QT1JUQU5UIE5PVElD RTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29u ZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwNCiB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBp biBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KSU1QT1JUQU5UIE5PVElDRTogVGhl IGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50 aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRv IG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZv ciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkg bWVkaXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM0PR08MB5345B19B0AF2304AE8E110CAFAB00AM0PR08MB5345eurp_-- From nobody Thu Sep 12 22:37:13 2019 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 4B2D7120024 for ; Thu, 12 Sep 2019 22:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 tLQWF8XTHf9k for ; Thu, 12 Sep 2019 22:37:08 -0700 (PDT) Received: from mx.stet.eu (mx.stet.eu [85.233.205.208]) (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 72CB5120019 for ; Thu, 12 Sep 2019 22:37:08 -0700 (PDT) Received: from mail.stet.eu ([10.17.2.21]) by mx.stet.eu with ESMTP id x8D5b659009678-x8D5b65B009678 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=CAFAIL) for ; Fri, 13 Sep 2019 07:37:06 +0200 Received: from STEMES002.steteu.corp (10.17.2.22) by STEMES001.steteu.corp (10.17.2.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 13 Sep 2019 07:37:05 +0200 Received: from STEMES002.steteu.corp ([::1]) by STEMES002.steteu.corp ([fe80::1c47:3ef0:f04e:a256%14]) with mapi id 15.00.1473.003; Fri, 13 Sep 2019 07:37:04 +0200 From: =?windows-1256?Q?Robache_Herv=E9?= To: "oauth@ietf.org" Thread-Topic: Question regarding RFC 7592 Thread-Index: AdVpeCBmbn8uFGEHRDSH6fb8upwECQ== Date: Fri, 13 Sep 2019 05:37:04 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.17.2.170] x-tm-as-product-ver: SMEX-12.5.0.1684-8.5.1010-24908.004 x-tm-as-result: No-17.277400-8.000000-10 x-tmase-matchedrid: ng/CxAXAtvueGXFpAoGIoRuurbgYp+HQqr0Np6cKdO5fQRiqw0gT4DcI a9gjeLdiWRv4gMq+CegHdptXFFME7wRytbWF0BphCgHQMFomsrRv+B0owAW3BpcDGDiTFmuGs03 PiUbxvvhR1tTDNqr8dVjZYFGVYSCavqDeDn7UX95DO9NSmfde1K6IBbSnfz+3CwWRLqiC/UqTvZ kBseIwt+1GNG8gfAYq1EsO4+XMhUs8Ph3xmtQMM36Y5s54+e3KwcNYF/8uAnyzwBK4JFe6pTFka fDzy4gr/3WCZWNVrmICWVEw1sp8bdrwCJH+dHmDwpU1WSBl38geIblhH0Sn6V0FI4GADitFjnjU +/TmD7yOh6y49NQ3X1DQ43dkW3a5LDC3FGTHI3eL6bUMM+bbIv98fIf4wIXlWI7R646mvA/xF9R reBogiPrhVD5vr96h7UqtKpOkry4xwF5W/E17aACSHRN4FLBrekMgTOQbVFtJXsGavJ3GY4k1O1 J7nQ+BmVk3Pw0560bi6XnuEMCN3k9dUJt57/ZSXrumkbea2MkatKaG3iywB2+fXVEQ/fGeZnl38 LxqzrOFcLjGz7g+vlbmKN2foe3AZgDC2cgBym9cunHFpy8xPzVvI0Ic6AC1vDa284z78yfclayG Yv+Tv8T0PwqwYdskXmrWGDhQBSDq3WC5KhDhQxB7F1lBAQWzJAXNnJnb/3myWTa+Xx1zJGagz3q Kgyk3g5QM5pUhFdLvH7TvVGN01ITtJG6+oDM7Em2V43Zg96UglKSMtU/FsQ== x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No x-tmase-result: 10--17.277400-8.000000 x-tmase-version: SMEX-12.5.0.1684-8.5.1010-24908.004 x-tm-snts-smtp: 4DA8F07342BA5D61490F7F04F9E2A7A551C677EA7F4E7E5613E8871304C7B1012000:9 Content-Type: multipart/related; boundary="_005_ae35a0f3b9f74618add918d9339be753STEMES002steteucorp_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] Question regarding RFC 7592 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: Fri, 13 Sep 2019 05:37:11 -0000 --_005_ae35a0f3b9f74618add918d9339be753STEMES002steteucorp_ Content-Type: multipart/alternative; boundary="_000_ae35a0f3b9f74618add918d9339be753STEMES002steteucorp_" --_000_ae35a0f3b9f74618add918d9339be753STEMES002steteucorp_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi RFC 7592 introduces a =AB Registration Access Token =BB. Are this token and= the way to get it similar to what is specified as =93Initial Access Token= =94 in RFC 7591/Appendix A ? If so, can the Open Dynamic Client Registration (RFC7591/A.1.1) be extrapol= ated to RFC7592 as the same way? Thanks in advance for your clarification. Herv=E9 ROBACHE Direction Marketing et D=E9veloppement LIGNE DIRECTE T. +33(0)1 55 23 55 45 herve.robache@stet.eu [cid:image003.png@01D14327.707582F0] STET (SIEGE SOCIAL) 100, Esplanade du G=E9n=E9ral de Gaulle C=9Cur D=E9fense =96 Tour B 92932 La D=E9fense cedex www.stet.eu Ce message et toutes les pi=E8ces jointes sont =E9tablis =E0 l'intention ex= clusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur ou s'il ne vous est pas destin=E9, me= rci de le d=E9truire ainsi que toute copie de votre syst=E8me et d'en avert= ir imm=E9diatement l'exp=E9diteur. Toute lecture non autoris=E9e, toute utilisation de ce message qui n'est pa= s conforme =E0 sa destination, toute diffusion ou toute publication, totale= ou partielle, est interdite. L'Internet ne permettant pas d'assurer l'int=E9grit=E9 de ce message =E9lec= tronique susceptible d'alt=E9ration, STET d=E9cline toute responsabilit=E9 = au titre de ce message dans l'hypoth=E8se o=F9 il aurait =E9t=E9 modifi=E9,= d=E9form=E9 ou falsifi=E9. N'imprimez ce message que si n=E9cessaire, pensez =E0 l'environnement. This message and any attachments is intended solely for the intended addres= sees and is confidential. If you receive this message in error, or are not the intended recipient(s),= please delete it and any copies from your systems and immediately notify t= he sender. Any unauthorized view, use that does not comply with its purpose, dissemina= tion or disclosure, either whole or partial, is prohibited. Since the internet cannot guarantee the integrity of this message which may= not be reliable, STET shall not be liable for the message if modified, cha= nged or falsified. Do not print this message unless it is necessary, please consider the envir= onment. --_000_ae35a0f3b9f74618add918d9339be753STEMES002steteucorp_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable

Hi

 

RFC 7592 introduces a =AB = Registration Access Token =BB. Are this token and the way to get it si= milar to what is specified as =93Initial Access Token=94 in RFC 7591/Append= ix A ?

 

If so, can the Open Dynamic Cli= ent Registration (RFC7591/A.1.1) be extrapolated to RFC7592 as the same way= ?

 

Thanks in advance for your clar= ification.

 

Herv=E9 ROBACHE=

Direction Marketing et D= =E9veloppement

 

LIGNE DIRECTE

T. +33(0)1 55 23 55 45

<= span style=3D"color:blue">herve.robache@stet.eu

 
 

 


3D"cid:image003.png@01D14327.707582F0"<= /p>

 

STET (SIEGE SOCIAL)

100, Esplanade du G=E9n=E9ral de Gaulle

C=9Cur D=E9fense =96 Tour B

92932 La D=E9fense cedex=

 

www.stet.eu

 



Ce message et toutes les pi=E8ces jointes sont =E9tablis =E0 l'intention ex= clusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destin=E9, me= rci de le d=E9truire ainsi que toute copie de votre syst=E8me et d'en avert= ir imm=E9diatement l'exp=E9diteur.
Toute lecture non autoris=E9e, toute utilisation de ce message qui n'est pa= s conforme =E0 sa destination, toute diffusion ou toute publication, totale= ou partielle, est interdite.
L'Internet ne permettant pas d'assurer l'int=E9grit=E9 de ce message =E9lec= tronique susceptible d'alt=E9ration, STET d=E9cline toute responsabilit=E9 = au titre de ce message dans l'hypoth=E8se o=F9 il aurait =E9t=E9 modifi=E9,= d=E9form=E9 ou falsifi=E9.
N'imprimez ce message que si n=E9cessaire, pensez =E0 l'environnement.

This message and any attachments is intended solely for the intended addres= sees and is confidential.
If you receive this message in error, or are not the intended recipient(s),= please delete it and any copies from your systems and immediately notify t= he sender.
Any unauthorized view, use that does not comply with its purpose, dissemina= tion or disclosure, either whole or partial, is prohibited.
Since the internet cannot guarantee the integrity of this message which may= not be reliable, STET shall not be liable for the message if modified, cha= nged or falsified.
Do not print this message unless it is necessary, please consider the envir= onment.
 --_000_ae35a0f3b9f74618add918d9339be753STEMES002steteucorp_-- --_005_ae35a0f3b9f74618add918d9339be753STEMES002steteucorp_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=134; creation-date="Fri, 13 Sep 2019 05:37:04 GMT"; modification-date="Fri, 13 Sep 2019 05:37:04 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAASoAAAABCAYAAABpJuNuAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAbSURBVDhPYygwWLAfiP+P4lE8ikfx4MQL9gMA lmac9TWs31MAAAAASUVORK5CYII= --_005_ae35a0f3b9f74618add918d9339be753STEMES002steteucorp_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=6542; creation-date="Fri, 13 Sep 2019 05:37:04 GMT"; modification-date="Fri, 13 Sep 2019 05:37:04 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAL0AAAA7CAYAAAAuPov1AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABkOSURBVHja 7Z15WJvHncfTNpttkl6bwwfmkATYmBtJxlziEIcAYcDmNmAuIQ6DOIQkQIAkwCAkARYgY0EINiEK 0SY4CZuwLtuFrmnLs6V9gvuQJmlIt9uGHFtrW3sbQmtnduYFbGxLgC5QUv3xfeARr953Zt7PzPx+ v/nN8IhIJHrEKqv+nmRtBKus0FtllRV6M+uzz245MYSTzKiCy2OkJOUV4qkLV0hJuyfvxAtXQnNG ruQ1vCUbn1ogW6GwQm9WccRXyyhZwzedYgfBwdBeYBO2N0LPtou4CIjJQ1+IB2dqrWBYoTeLChpe E7smDoOn/KRgf2AHOEiR7KkOBHWAf4JlCci8DFST1hHfCr2J1SifPu1xchg87b/3sD8ou4h+kFf3 aq8VDiv0JhMA4NHgrOc+fCawy+KARzoUfgH4nOq/YIXDCr3JpBiZDT4SewHsC7Q84LGRHkKfxBpT WuoLk8snHyNEML9DIOhQBO/JRx4B3/i6AMpkir+9VX0jIsRPWDz0+fzxaseYAcyGtjTg98MyOcYo QVnzm0xLhUAoUdV6BrM/IfgUfuJIYt4ngk/RJ8Swql8rlVPf+7pAn5LXoTx8nPVQXZHwPsWfxKQJ pi0eenrRC6MoWmKJo/z+ICk4HNv3uVAxe8Rioe94SewVWgscycXA6VjJfXIklwKfsMpbEPrvf42g f/WIf9VDdUUikM+CmFThuxYNPbTnH/NNufjL/cHdFgn9s4EyQEru/wMs57ctF3pVq2dwDSAQCwEc 7e4TgVgEiGGVf/yaQT8GR/qH6oqEJxZD6AXXLRp69ezSPs/4vs/3BUotEvqDIb0gJGvoLQi9xdrE Vui/YtAzBBNUp5j+2weCLNOJtQ1XgKSKsXZLhsAK/VcM+ty68XP2kf3ggCXa84EdwOXEAOBJplKt 0FuhN5U9/43wvOE3LNWJfTZQAjwTFH8bn1p0tkJvhd50Tmzqxf9GzqJFRm6gc01M6r8Oy/kPpqz3 /PySk1I17ZZRKnMTilVuswvvucFnPGGF/u8AevHQjPNRuuIvKCxoidAfCOkBNMbll42t58rKyrO8 5tHyuNNtL/nReG8HRHP/6kfjAg8KC5Co1SAkng9IYdUf0tOb3z5d1N0nkKjTl5Y+O7zT+5/rflm4 NfRV/2PO6BMaFIRitReTrWScPNMhCY3nj+aV972dVdT5SzKV3ZNZ1CUp5Q0nTE0tOpjieekF0he3 gj42XbhgsdBz+n96+nDcMNhP6QIHQ4xR99rPYNPNGGihjBCtBNkcNdcIGH7AYPUKqYlNN9wp1cDp WBkgkEqAgzcDE57IBDifQmDvWQA/L4a/F4MjfhXAK6QGhJzgf5GcK5mpax5lq8dn7nYAjUbzeESc cD/BlbmfQFpTJX+w24PC1gm9d0iFJi5D6LxxvW6x9jN5ymf0mLEOMCsVQnrGuQ88gyuAa2AVOBpQ BRzJZ4G9FxPWsQg4QzjRZx6w/r6RnP+jp7X+q1A8dga2zbd28oypqaUnSRGC++obn9n62uHj5Tqh jzzV+M5O6nr4sPwxo6CfUcweHRdMnL3EHK0Y3oHUZa9UMPIu/OTA8XpgQ+YAm2NGiFwDf3LBwYBm k8GPnFiUGiFQTIcb0h6q8WmXtELZ+y4BlRCAQq1A6hIedQQv1ClKgGtQDcgs7rq72MITDKcTqbxb 8Jpb8FpMzseKVh1JRVvd80snEvP/Nq7XpSN+rFspOW28HXTmb1c3DTcHxNR+ikB38EZlZm5ZR/Q3 1MHR4pFXaA2ISWtZUAxNZm73rAyGrAk+45Yjkbm5vn/bqv2cyEV3tqurs+/ZW4d9GBEGQT+rmgvq jFJcaSZ13G71koEWD+mO1OHZDcIcM8Gz9v7AziHENMKHg0PuuRDaDqPBfyZAAnxTlZ8vLWvs9AV+ YnLONTJZ9AccsRQDeKewa32Bx8pBUm772Ma9k/PE0iN+lfDFFt8VYSf32XS9NqEZwYfKBWW8wfgt 11UmZlwzCrsX3Ck1GOz6dOZ7nZqBzWq+UbWghHOxZyufKS69ZdqRXHZfWbe7P2EH9UUzBcGHEaM3 9GN14znS0B7AJ7QCtkMDYOP4gI3fXjX4BuynO44ODuIgrDiqaeQQCuzs/IGtayaEvtMo6PdRugEl c/A/DTBpnoBgLhLgi9oOCAKRue3fXQMrQSZDlr8R7aIm8n+IzCRjOpI24SDAxyNrVtQT87a66sbi KdyD4xo+RhAicI19JjLrvEJ5IKu4+y1tPgf87Dv+NO7v8MQik9cXjvTAicSg6QX9pHgquCPwPGDb QogJDXqJR2gCJQQOwOEiwCFcmOmgxxSGjfo2x/lGgW8XcQFEM0f69IW+WTLW6BnChSMZQ6fpguxO Z99yzAZG5g+a8gnk0nUzofC+a0nhNbdl8nG/dXv+uwE07ic4H6bpofcpAmEJ/F9D0B7XVi+ZfMLD P7p2GU8q3bIz4zBfBY7GxyBUUOi+6DPd1xeAI/6VgFHV9+ZDgQ7F+FHk6OOMnC1NAj1smCflCRff 49oJ9AYeqZ4gBKfxZ8EBU47ym2VPAYd8ytccXIOcWAnA0y4ApmCiQM9R/tGwhPpFNHVra2gH70Lo pFYB6Pj9PP50a29UirCeEsurR+ZLdKroWmAMT0Ok1mDOLOoAth4MQKHXapY0GixDcmhkKtA3incH Z4JR9mEzqgykFUhf1Vav5WWNTUJWO+xsJTqBRzOFi38FOE7j3vGP5i0GRHOvkcOrr/nTOB8hMwbd Xxf86HO3oGpQxR+s3/zc/NKuTPegqm1nxF2Bflw4GdRClIJqB75B0PMJIhCDzwH7cBQzQR8MDhFZ BkP/bEAH8DypvKNQzfnqA32rXH2MGF6jFUoH6MzS01s/l/SOJ20R2tzXKn+FVsS+qKBntH5AjqwH cRktb6POhP6eyZSwDvtVATuvQiw6siE7T8Y2ZlIh5kxv/s793y+EMw4bMKt6tUaqzhR3vebsy9IK PDJzkMNNoddrcsvPS1TqOdeN8m5EsLqUbyYkZre/Qo7kYR1fq6kDHfeQ+AYwop6+G6lKyusYwxHL HyqvgzdjG1ONobOuG8IRzwIH99zYHUOvzB6uE7qIDQIeqZYgAMfxSWA/LtgM0Idhtr2Nb/1aJMcQ ex7LrFR+hGY0faA/mdN6BtngD8KBw8wUzu2h0R9l6jFr/KN88M24wUtTGXdNJ9lY+5lSxftp+ZL3 U/I7MGUwpe/T05tvELaIBLkGnr2dktfxQVrBve9tFrpfdsn5d1vl454PLXy1qaJ9wmq0mhionihe nlIgXZiYmMNvV6fGVlWWP423gkwerbMNNPmg4zqycX1Vw3MvZhTJYfnulfU0U/Z+8Im6m7pMHgT8 sUj2FxmF0vva6cH6ZhbL4e+tlB1D35cy+GY9vtkg4LmERlBFqAcuuBhggws1PfTImSVEg4OBbYZH cEJ7gX/6wL/oa88XVysG0BSvbRSLSRX9EYFsbNqGNvUo3zinK06Ph4CRw6vQs3+g6/sb0rbolMbo +A2Kt2vtUKQSkJwrWYDX7d/xbChTRx6P4v5VG7RoBPeP4d2ZnJx136q+uaXnx5BPpMs3ic9sub5d XR+s77bRibbgzt9wHQQGj/KFhGoMUFuTO7Frpo3tkeR1J9awlV5bqgKcLFPpnVkJR6HntUGPpnTo JN4wFnpdEnS81LxdGoJYrP6OvveFphgV+RjaIjWoTpQ4/q3JyXlHfe/Lbhxqcoc2PP6B8qLyu8LP y3kXO7f6fnKu+KUt0xDSBKZdkZ1TzRGEvu2Abc832IlNwReZybRZd2I98g2257FFqbgBUNb25il9 G66Md/E8ckK1hR4P+579sq7lhee/KglnaCQsqOh51UnLiIqe4xZYDbKZMp6BM9a3YtNFS9rMHOQf ZDBlP7ao3BsVayxJ5N7xJRvfYDD04fhMs0JvQ6oyGHq0Od09/sKqamJe78xKjuBSApHK0xquRFM3 OYIHClh9r6nUM6SvAPRPUBMaPkZRJG1OOSWu/ubS0rLBuTQ5pV0lKGKzucxocDgaUAmS89rbLAr6 rjiFQHCk3SDgOesxeiIu0UzhyjVzycavyeAY/TPQiQ3Jeu73aGFE34ZbXlx+Oohe+5GDDkfNwasA i8/7RnHuBNF5107lii+W8YZOT08vHLE06OcWltyP03i3tYUZUSTnRGbLC0b6J48ei2DfwBPvd7p9 wjhAKBnLsBjoYUG/2RXTO11nhBNbTqgFTjgaOGQWJxZ2JEc6OBgkNsqJjcgdVhv6MplsRYVnKFdn TBrLQYH2MIFUCg5DUwgloh2ncVcTstp/3Ng2xjQkG9IU0EekCJ92CSwrJJAYmDyDys67+GlfVUYx 7oAY3hUcicnYuF5fuQSWFvrROH/E+9wf5SKHV6+qxmdxFgO9RqP5XluITFNjZ5hpUwed2FxCBQa8 rZlMG9uj6QaHKlFmJZ6mBCdZY9VGjGDfSiuQvuIWVAPs4ci+bZ7IeidAK52eITUgKln0rqBNlb/b 0OeUylleYfXYKI6AQqupulde0apyEXadoUIz3oOOLAI2mF77znb7kXcV+in5tK/Ip+OvbJzh9nwC vsC8TqxXEYT+vIHHfUiAc3QfqJNcpRo5dT+eXtg54BfdiIXQdpp0hq5Dq7ko8Su75PyrO432mAL6 jELpOEodMPXKp76rwvSMFpVFbSJR5lzKaXaXrCWNGQg9BZ8G9pkLepRzg1KMDXRiUWYlKal/ZXFp +ZApHMy2rleY1MSmRa9QDpZjjsJ8COztltWRaYTOdaGebPzh/Pz84+aGHsXjwxMb3sFyZvYIeNQm KCJUzOnnWRT0ipSB5xqdzxnoxDZiP93xcabNrNzsxOIj13LqDbTn9wV1g+DsoQVTHveBbHR+62h+ XGbb6xR63Z+8Q9lYhAK9HJy37hkATf1O0NRIY0intttKaCz0U1PzDn60mjvbLe+bUzgsusUFzV1q qsVAj0Doiut7h2vfZBD0KGpTSuACPC7SDJmVa6O8rXPC+oKUYYtSNmEKkFd/5UVz7RRbWtbYCGXq mOyzPSJaimieHM7G7FsHL92JWMSIesBpHOKYE/oq/hDdnVK5PgttaHehR7NgSDz/1vKyxtZioNcs aWxajkv/t8ah0WDozZdOvO7EumUZbNo87ScGPsnPg9GJhXBzQf/QzKmcIhZW9Y/4R/O+RMfvaYMW JUeFxTd8vLSk+a65oE8tkHSQowTAncIGHsFrcvFnYdsZ1zZtFGHOqyORsfYT3ZtcBG3wUhOKhVat f76Tdts16McbJ6gos5JtYGblXfMGF2eeGD2WTlxmkBP7bIAYEGKHAIP/+nO7Bfx9m3Fenw2LSBIt OsKXfxeqTc6tdxgH8FsvZZgL+uHRH+WIOl9ta2pXtTVAiaQvt1XVKf7ZyS0GHHCAg4lTJLB3iQc4 9zRA8M4Bzr5lgJrQcJVAYgZBBZtCroGsYM8QFt6ioB/MvcQTGJFZeS8FoRhLKTatXb+WWXnQtw4c CO7E8uG3Vsf66msHdF5lAP2rn4LGN94w5hgOYzU1s+ATEt/0F22pty7+lSA6VdC2uyuyK8+QAlL/ cujIKQh67npnLMKEwKJCx3ev2mrXoJeEn3+hwanVKOg3Es5O4WED4mjYiG8SOQSBgwQaIET1AUL0 AHaKwXayj7gAXOKUICxv9PelzZOle/UCN4uWIngRbcV7yN71KQZ55T0/2U3okcISG6cdodmBTJkH nWzPEDbgCIaSLBH62DSR8dCjCISY2r1kaGblg6kIaMRnEWpBFr4MpOFLQLqRSrUtAiVhglu1Xf8m 4cqmtlVTz39I8vnjXLZ4OgTW7SlLAB4JvqyL2qBHWwnpGc0vGQq9VzDrMwi93rNYXetIk0dwjdZ1 BrT+EJvW/KEh6RrGKilXN/ToiBVqAv+XRkM/N75wuNlfAqoNzKzUlZJQB+GvN4GEhHagjB94fS+B nZl7j4By1o25BzRhPtCWeegaWA2o8fwGnd+Vjkm8Qjg6oGcCr9DqFbF8XO8EutnFpX0BMbwb2pLO 0LOO+FfAGah3zNi2m5ya85ErJxg7vf50oUytC3q0bTEolocOt/quUdCPccZThO5i7BQDU0FvMsEy oV1cl0tVe3qycEahTBGT3vZf2cXy6pnZhaP6fr+U1892D6rUmmOOoil1zSOFur7LbhwqRTu2dC36 oOMuClh9Q4bUK6u0U+gWpH2DCgqpeodyQX6FQqUvZFinmlt0ZwsuD9JS2+6k5Il3/D+9mJV9l3Rt IkGzEjpYqq1LLTAK+p7kgRbMibVA6NGxIy0+UjAunIjbS+gjTwl+ZudVgp1wEBDDvZ2Yde5aGW+w fkQ9E7yysvK0jrWPp5QjM5QzpedVXiHad/2jYzLQsX/T0ws6j/lLyRf7o+/rSndwwLbQ1QLYMUfF 8glfjUZjs9N6obJHp4o+0rXZHVs99mNB57H5nWLO4MntZrv5xWXb5i51Xnph50RAbO0q2n9wFLYZ XziSstMyhcbz810DKnXmBqF1D0pcAyis6O0aUs94wTI9s97etlPTi25MtjI4n9XfyG994fmNhciH HiKNkl+tJ7RY3iiPhGsEomPiPy9OLO7fK+CXlzWHQuLqVtC2QPQi1o7sK8Hi3r5RPHAsvPoT+Pfr ELrrWcVd1zOLOq/HpIquU+i1H/tGcrHkK117PtHxIPGZrRNbPV89MWtPDmff2upoEAfvAiy3hRxe A/xotX+C17+x0/rJesdjYD1u69qAvnZ6GfQdoHNLSxYtx6aLRriiUUl2cVc2o0pRwhW9IPGP5kgj k5rmoLl0k0jl3k3LQEl5fjQOgHVw2nGCnURFJ1I5W+Y0ofuizuhH4wHfSPan8LPrQfTamxR6PXAL ZAGP0HoUgbqidaRHm6OFvu2/4+IEFgk9cq47qN2/Qicg7xX0kt7xUGIY+6GXsJZBycAyEtfOsCy6 KywNwYe55Zkw2J7R6HrAb1VteyrDiczWX+BgR9v+fBsImncJiE4VzupTR6FYJQqIbQK2HvlbJsyh DSaoc7lDk8gFQncU2v1oswga0dFAgFvPP9rsEEclCX6rzyb8paWl7wVEcz7V5mtoa0O0T9j52L1O trZZpQLks3prtEI/MzR7vIUs/dLQRSlzq8HpHLiQNvDSXpo2sPGqPHRETwxflmdgoOSc7e7eIZSp PmFcsJP8GWSC5ZTJ2/Stp0xxReEX3bDtkSMbHV7b79oyK6OSBXpvSMkp6+K7UzgGnbSGnZgQwQVC mSpcK/SXmKMFLZ4yzHa2OHsezwciNwkYKVVV7iX09PTm19C5lSYDHppJHsEcUM4b+BnauLPTchRU 9KhRHv9W4GMrvKE1gCccPmVIXXnCSzkh8Q2fI7PL2JPHsONJYHlzS+V1+pYDtsv3Mwo73yGQyvQ+ LxTNNgExtX9eXFw6oBX63uSBAUMzK3cjctPk1X5bxZ/w2UvoUwskr/hG1WMhvI1j7PQd9e+e6ks6 i2UblnCUF/QNgaIISklN/1vecMRHOTt4HcdsUOh1X8zMLboaWl/V+KxbSr70KnKe147lLtD7VGbU Ti4ofTqx8VOeYMTNoFXs2XmbtILOn6OjwPU5TBY9+8Tp5sXNB8dubsRvtlKkP6nDiywTeodG0Ozf cWNleWVPF5jQphGxfDwIjjydkUmCX/tGcbFtgGihCW0LRI1s51mwZs8SmWvn0iP7EpkJKNEMXoNM DmJY9d+yS+XXlMNTscaUh982WhZ3uu13aETHDnsll2L+A5pB7KE/ERrPf1efGUTn4pXwUgT0JSaR c+gezMbqgXwVVNe1o7vX6rp27HgRdk4Oiq+jow3DEhs/yC2TC6emFg8Y2faPneUMtIScaLhxr81L HmpvrO5QaEfYYT82SM4TP681ZLm8tHyoLUh2s8beAoFH2w/xzUAa3TO7l8BreQmPKoYmfVj8wfK8 8p6XaSmiawExvN9GnGpa9aNxVr0orFVPqOPwd2piwyo5vPoX6YWyH2UWd7Fb5eMuJizHDwRt6pN5 ZX2XoDlyLSCa+yklrn6VHFm7mpjdatLEusmpBZ8y3mBNaoH0jdCEhuuorqTw6lWPINaqd0jFKnz+ ql9UzYfx2e3XGFUKOV84Gm7qM4CWljQHitmDmdkl59Wh8Q3zEacasfZGbe0dUrkaRK9dDY2vv+kV XDGbUdg1w2QriFqhnxRfjTl3rNPgMyvNrUanNqA883yvJUGvA8AnNSvAfkQ9a8/iKTGh3zUajf0u luGp+flle6FYba9Wzz5lxud8YwXWVSxX2zNZcnueUGm/uKSx3+1kPlQGFMplwrbmCUfsZ2cXURkO brs41ZXUT0crsWwLXJSqtqsHbb5dYEI4GWjp0Ftl+brnKChmAlrIUpPm3JgEeFw9aHJqB8/lXr66 +YRcq6wyGnrkJPScuvgrvkOLRYQs2Qh42AEFzmIwePryu5odbC2zyiq9oF+z66cdZeG9751z7wS1 OBGoxe+R4LOFLh3gnG8nGMi4PLSysrLf+rKsMgv0WBRnefnpEYa6+mLa0L930xU/7Yrp21WhZ55P 6P+xMn24eW5kLsD6kqwyO/RWWfV11/8DWg8dgPgaldcAAAAASUVORK5CYII= --_005_ae35a0f3b9f74618add918d9339be753STEMES002steteucorp_-- From nobody Fri Sep 13 04:30:10 2019 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 5F138120077 for ; Fri, 13 Sep 2019 04:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=curity-io.20150623.gappssmtp.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 42jrkwICgP8G for ; Fri, 13 Sep 2019 04:30:05 -0700 (PDT) Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 86010120046 for ; Fri, 13 Sep 2019 04:30:05 -0700 (PDT) Received: by mail-yw1-xc35.google.com with SMTP id d19so8378420ywa.0 for ; Fri, 13 Sep 2019 04:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BK+YSm/Qx+dStNYTDuEqvahjkfhA0pUUWKjjsSW9ADM=; b=gcUrcjGo9M24jENAKu3VFiT4jdZmcjWWuIzhBFRvLb/pUL36pknYTtu6QhGmlakens eEkcNGxtNNtYDTFav9/qCWbNoKpOw7WW37xSfiK7QoJlPFl9L0GZE2DacL36NvPfrgAQ K3M7bvpKCwbCsesGOHwHXIkwkLMKr8M+HBp4rB+QJq8FA27mD4d6hzQKmS9X9pZAZa0w neUf1CyXeWDM+dcX10mNzS0EiUTasBcoq7tRvEscNTcw+N+vVNoQPY9MJGQ7mPsJrzT7 dtPy/Ep1aRGdkn1ILh+HPTu5++0P45jKYpz7BaD5RMBlkPU4isTYf92NDoLWCoUy3z1t /qhg== 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=BK+YSm/Qx+dStNYTDuEqvahjkfhA0pUUWKjjsSW9ADM=; b=L/LZACgSWxM76Cs3E5Hf5FX5gg4e+tWt5A9y3Pz0GvPNUVDYjRofTiCVOnikX/FGHB I8/V3C645PNWDcQRekI4ZKXDs3DHrclwBq4NSF8CuN+5ETTLJSGcosGQNUaktHwSgtHP fDuTCenWWJ/l09m+qOSigcbd6BG1b6fWMCHRzTpW07mV7C7QSucSfezXBoBPZPijy+dU sL5jZAXMYklqXdFChnuR9G3cUwjk82RCfO1ciBhjqizjTrfGpFpPnFhccd910XoXC6FF Fzdjz2g9PhC/SQigMkKuvWdkTCQAv1hjTkKOng/RmxQ9XZFMJVsCmODEmoxG+hw89U53 GKOQ== X-Gm-Message-State: APjAAAX7/mq7Cl2dADF79GnGuaZ9QzA7+cEPrNiwnuN8So1y5/8qDmfB akgcbzubJmY/dRu+IkvGagV4q40Tu8epHIAwy68KKw== X-Google-Smtp-Source: APXvYqyZwGnNXLKq0FQTu1dsGX9h6M5pgngfeldqHxl8FAYa+7qYc+nQ7EqjwjSWv5MXBbLDMDP0msIYubd+YLpiv+c= X-Received: by 2002:a81:7dc5:: with SMTP id y188mr2380937ywc.69.1568374204368; Fri, 13 Sep 2019 04:30:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Travis Spencer Date: Fri, 13 Sep 2019 13:29:53 +0200 Message-ID: To: =?UTF-8?Q?Robache_Herv=C3=A9?= Cc: "oauth@ietf.org" Content-Type: multipart/related; boundary="00000000000053bd7705926d93dc" Archived-At: Subject: Re: [OAUTH-WG] Question regarding RFC 7592 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: Fri, 13 Sep 2019 11:30:08 -0000 --00000000000053bd7705926d93dc Content-Type: multipart/alternative; boundary="00000000000053bd7605926d93db" --00000000000053bd7605926d93db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No. The initial access token is issued by the AS when registration is protected (appendix 1.2 in RFC 7591). As stated in section 1.2, the method and means by which this is obtained can vary. The registration access token in RFC 7592 is used to protect the registration management API and allow updates to the client after it is registered. You might have one (the registration access token) but not the other (initial access token) when open registration is allowed (appendix 1.1 in RFC 7591). HTH! On Fri, Sep 13, 2019 at 7:37 AM Robache Herv=C3=A9 = wrote: > Hi > > > > RFC 7592 introduces a =C2=AB Registration Access Token =C2=BB. Are this t= oken and > the way to get it similar to what is specified as =E2=80=9CInitial Access= Token=E2=80=9D in > RFC 7591/Appendix A ? > > > > If so, can the Open Dynamic Client Registration (RFC7591/A.1.1) be > extrapolated to RFC7592 as the same way? > > > > Thanks in advance for your clarification. > > > > Herv=C3=A9 ROBACHE > > Direction Marketing et D=C3=A9veloppement > > > > LIGNE DIRECTE > > T. +33(0)1 55 23 55 45 > > herve.robache@stet.eu > > > > > > > > [image: cid:image003.png@01D14327.707582F0] > > > > STET (SIEGE SOCIAL) > > 100, Esplanade du G=C3=A9n=C3=A9ral de Gaulle > > C=C5=93ur D=C3=A9fense =E2=80=93 Tour B > > 92932 La D=C3=A9fense cedex > > > > www.stet.eu > > > > > Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'i= ntention > exclusive de ses destinataires et sont confidentiels. > Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, > merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me et = d'en avertir > imm=C3=A9diatement l'exp=C3=A9diteur. > Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'e= st pas > conforme =C3=A0 sa destination, toute diffusion ou toute publication, tot= ale ou > partielle, est interdite. > L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de ce messag= e > =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3=A9cline toute = responsabilit=C3=A9 au > titre de ce message dans l'hypoth=C3=A8se o=C3=B9 il aurait =C3=A9t=C3=A9= modifi=C3=A9, d=C3=A9form=C3=A9 ou > falsifi=C3=A9. > N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'environneme= nt. > > This message and any attachments is intended solely for the intended > addressees and is confidential. > If you receive this message in error, or are not the intended > recipient(s), please delete it and any copies from your systems and > immediately notify the sender. > Any unauthorized view, use that does not comply with its purpose, > dissemination or disclosure, either whole or partial, is prohibited. > Since the internet cannot guarantee the integrity of this message which > may not be reliable, STET shall not be liable for the message if modified= , > changed or falsified. > Do not print this message unless it is necessary, please consider the > environment. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000053bd7605926d93db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No. The initial access token is issued by the AS when= registration is protected (appendix 1.2 in RFC 7591). As stated in section= 1.2, the method and means by which this is obtained can vary. The registra= tion access token in RFC 7592 is used to protect the registration managemen= t API and allow updates to the client after it is registered. You might hav= e one (the registration access token) but not the other (initial access tok= en) when open registration is allowed (appendix 1.1 in RFC 7591).

HTH!

On Fri, Sep 13, 2019 at 7:37 AM Robache Herv= =C3=A9 <herve.robache@stet.eu> wrote:

Hi

=C2=A0

RFC 7592 introduces a =C2=AB=C2= =A0Registration Access Token=C2=A0=C2=BB. Are this token and the way to get= it similar to what is specified as =E2=80=9CInitial Access Token=E2=80=9D = in RFC 7591/Appendix A ?

=C2=A0

If so, can the Open Dynamic Cli= ent Registration (RFC7591/A.1.1) be extrapolated to RFC7592 as the same way= ?

=C2=A0

Thanks in advance for your clar= ification.

=C2=A0

Herv=C3=A9 ROBACHE=

Direction Marketing et D=C3= =A9veloppement

=C2=A0<= /p>

LIGNE DIRECTE

T. +33(0)1 55 23 55 45<= /p>

herve.robache@stet.eu

=C2=A0
=C2=A0

<= /p>

=C2=A0


=3D"cid:image003.png@01D14327.707582F0"

=C2=A0

STET (SIEGE SOCIAL)

100, Esplanade du G=C3=A9n=C3=A9ral de Gaull= e

C=C5=93ur D=C3=A9fense =E2=80=93 Tour B

92932 La D=C3=A9fense cedex

=C2=A0

www.stet.eu

=C2=A0



Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'= ;intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me = et d'en avertir imm=C3=A9diatement l'exp=C3=A9diteur.
Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'= ;est pas conforme =C3=A0 sa destination, toute diffusion ou toute publicati= on, totale ou partielle, est interdite.
L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de= ce message =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3= =A9cline toute responsabilit=C3=A9 au titre de ce message dans l'hypoth= =C3=A8se o=C3=B9 il aurait =C3=A9t=C3=A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou= falsifi=C3=A9.
N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'envir= onnement.

This message and any attachments is intended solely for the intended addres= sees and is confidential.
If you receive this message in error, or are not the intended recipient(s),= please delete it and any copies from your systems and immediately notify t= he sender.
Any unauthorized view, use that does not comply with its purpose, dissemina= tion or disclosure, either whole or partial, is prohibited.
Since the internet cannot guarantee the integrity of this message which may= not be reliable, STET shall not be liable for the message if modified, cha= nged or falsified.
Do not print this message unless it is necessary, please consider the envir= onment.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000053bd7605926d93db-- --00000000000053bd7705926d93dc Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: <16d2a6019144cff311> X-Attachment-Id: 16d2a6019144cff311 iVBORw0KGgoAAAANSUhEUgAAASoAAAABCAYAAABpJuNuAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAbSURBVDhPYygwWLAfiP+P4lE8ikfx4MQL9gMA lmac9TWs31MAAAAASUVORK5CYII= --00000000000053bd7705926d93dc Content-Type: image/png; name="image002.png" Content-Disposition: inline; filename="image002.png" Content-Transfer-Encoding: base64 Content-ID: <16d2a6019155b16b22> X-Attachment-Id: 16d2a6019155b16b22 iVBORw0KGgoAAAANSUhEUgAAAL0AAAA7CAYAAAAuPov1AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABkOSURBVHja 7Z15WJvHncfTNpttkl6bwwfmkATYmBtJxlziEIcAYcDmNmAuIQ6DOIQkQIAkwCAkARYgY0EINiEK 0SY4CZuwLtuFrmnLs6V9gvuQJmlIt9uGHFtrW3sbQmtnduYFbGxLgC5QUv3xfeARr953Zt7PzPx+ v/nN8IhIJHrEKqv+nmRtBKus0FtllRV6M+uzz245MYSTzKiCy2OkJOUV4qkLV0hJuyfvxAtXQnNG ruQ1vCUbn1ogW6GwQm9WccRXyyhZwzedYgfBwdBeYBO2N0LPtou4CIjJQ1+IB2dqrWBYoTeLChpe E7smDoOn/KRgf2AHOEiR7KkOBHWAf4JlCci8DFST1hHfCr2J1SifPu1xchg87b/3sD8ou4h+kFf3 aq8VDiv0JhMA4NHgrOc+fCawy+KARzoUfgH4nOq/YIXDCr3JpBiZDT4SewHsC7Q84LGRHkKfxBpT WuoLk8snHyNEML9DIOhQBO/JRx4B3/i6AMpkir+9VX0jIsRPWDz0+fzxaseYAcyGtjTg98MyOcYo QVnzm0xLhUAoUdV6BrM/IfgUfuJIYt4ngk/RJ8Swql8rlVPf+7pAn5LXoTx8nPVQXZHwPsWfxKQJ pi0eenrRC6MoWmKJo/z+ICk4HNv3uVAxe8Rioe94SewVWgscycXA6VjJfXIklwKfsMpbEPrvf42g f/WIf9VDdUUikM+CmFThuxYNPbTnH/NNufjL/cHdFgn9s4EyQEru/wMs57ctF3pVq2dwDSAQCwEc 7e4TgVgEiGGVf/yaQT8GR/qH6oqEJxZD6AXXLRp69ezSPs/4vs/3BUotEvqDIb0gJGvoLQi9xdrE Vui/YtAzBBNUp5j+2weCLNOJtQ1XgKSKsXZLhsAK/VcM+ty68XP2kf3ggCXa84EdwOXEAOBJplKt 0FuhN5U9/43wvOE3LNWJfTZQAjwTFH8bn1p0tkJvhd50Tmzqxf9GzqJFRm6gc01M6r8Oy/kPpqz3 /PySk1I17ZZRKnMTilVuswvvucFnPGGF/u8AevHQjPNRuuIvKCxoidAfCOkBNMbll42t58rKyrO8 5tHyuNNtL/nReG8HRHP/6kfjAg8KC5Co1SAkng9IYdUf0tOb3z5d1N0nkKjTl5Y+O7zT+5/rflm4 NfRV/2PO6BMaFIRitReTrWScPNMhCY3nj+aV972dVdT5SzKV3ZNZ1CUp5Q0nTE0tOpjieekF0he3 gj42XbhgsdBz+n96+nDcMNhP6QIHQ4xR99rPYNPNGGihjBCtBNkcNdcIGH7AYPUKqYlNN9wp1cDp WBkgkEqAgzcDE57IBDifQmDvWQA/L4a/F4MjfhXAK6QGhJzgf5GcK5mpax5lq8dn7nYAjUbzeESc cD/BlbmfQFpTJX+w24PC1gm9d0iFJi5D6LxxvW6x9jN5ymf0mLEOMCsVQnrGuQ88gyuAa2AVOBpQ BRzJZ4G9FxPWsQg4QzjRZx6w/r6RnP+jp7X+q1A8dga2zbd28oypqaUnSRGC++obn9n62uHj5Tqh jzzV+M5O6nr4sPwxo6CfUcweHRdMnL3EHK0Y3oHUZa9UMPIu/OTA8XpgQ+YAm2NGiFwDf3LBwYBm k8GPnFiUGiFQTIcb0h6q8WmXtELZ+y4BlRCAQq1A6hIedQQv1ClKgGtQDcgs7rq72MITDKcTqbxb 8Jpb8FpMzseKVh1JRVvd80snEvP/Nq7XpSN+rFspOW28HXTmb1c3DTcHxNR+ikB38EZlZm5ZR/Q3 1MHR4pFXaA2ISWtZUAxNZm73rAyGrAk+45Yjkbm5vn/bqv2cyEV3tqurs+/ZW4d9GBEGQT+rmgvq jFJcaSZ13G71koEWD+mO1OHZDcIcM8Gz9v7AziHENMKHg0PuuRDaDqPBfyZAAnxTlZ8vLWvs9AV+ YnLONTJZ9AccsRQDeKewa32Bx8pBUm772Ma9k/PE0iN+lfDFFt8VYSf32XS9NqEZwYfKBWW8wfgt 11UmZlwzCrsX3Ck1GOz6dOZ7nZqBzWq+UbWghHOxZyufKS69ZdqRXHZfWbe7P2EH9UUzBcGHEaM3 9GN14znS0B7AJ7QCtkMDYOP4gI3fXjX4BuynO44ODuIgrDiqaeQQCuzs/IGtayaEvtMo6PdRugEl c/A/DTBpnoBgLhLgi9oOCAKRue3fXQMrQSZDlr8R7aIm8n+IzCRjOpI24SDAxyNrVtQT87a66sbi KdyD4xo+RhAicI19JjLrvEJ5IKu4+y1tPgf87Dv+NO7v8MQik9cXjvTAicSg6QX9pHgquCPwPGDb QogJDXqJR2gCJQQOwOEiwCFcmOmgxxSGjfo2x/lGgW8XcQFEM0f69IW+WTLW6BnChSMZQ6fpguxO Z99yzAZG5g+a8gnk0nUzofC+a0nhNbdl8nG/dXv+uwE07ic4H6bpofcpAmEJ/F9D0B7XVi+ZfMLD P7p2GU8q3bIz4zBfBY7GxyBUUOi+6DPd1xeAI/6VgFHV9+ZDgQ7F+FHk6OOMnC1NAj1smCflCRff 49oJ9AYeqZ4gBKfxZ8EBU47ym2VPAYd8ytccXIOcWAnA0y4ApmCiQM9R/tGwhPpFNHVra2gH70Lo pFYB6Pj9PP50a29UirCeEsurR+ZLdKroWmAMT0Ok1mDOLOoAth4MQKHXapY0GixDcmhkKtA3incH Z4JR9mEzqgykFUhf1Vav5WWNTUJWO+xsJTqBRzOFi38FOE7j3vGP5i0GRHOvkcOrr/nTOB8hMwbd Xxf86HO3oGpQxR+s3/zc/NKuTPegqm1nxF2Bflw4GdRClIJqB75B0PMJIhCDzwH7cBQzQR8MDhFZ BkP/bEAH8DypvKNQzfnqA32rXH2MGF6jFUoH6MzS01s/l/SOJ20R2tzXKn+FVsS+qKBntH5AjqwH cRktb6POhP6eyZSwDvtVATuvQiw6siE7T8Y2ZlIh5kxv/s793y+EMw4bMKt6tUaqzhR3vebsy9IK PDJzkMNNoddrcsvPS1TqOdeN8m5EsLqUbyYkZre/Qo7kYR1fq6kDHfeQ+AYwop6+G6lKyusYwxHL HyqvgzdjG1ONobOuG8IRzwIH99zYHUOvzB6uE7qIDQIeqZYgAMfxSWA/LtgM0Idhtr2Nb/1aJMcQ ex7LrFR+hGY0faA/mdN6BtngD8KBw8wUzu2h0R9l6jFr/KN88M24wUtTGXdNJ9lY+5lSxftp+ZL3 U/I7MGUwpe/T05tvELaIBLkGnr2dktfxQVrBve9tFrpfdsn5d1vl454PLXy1qaJ9wmq0mhionihe nlIgXZiYmMNvV6fGVlWWP423gkwerbMNNPmg4zqycX1Vw3MvZhTJYfnulfU0U/Z+8Im6m7pMHgT8 sUj2FxmF0vva6cH6ZhbL4e+tlB1D35cy+GY9vtkg4LmERlBFqAcuuBhggws1PfTImSVEg4OBbYZH cEJ7gX/6wL/oa88XVysG0BSvbRSLSRX9EYFsbNqGNvUo3zinK06Ph4CRw6vQs3+g6/sb0rbolMbo +A2Kt2vtUKQSkJwrWYDX7d/xbChTRx6P4v5VG7RoBPeP4d2ZnJx136q+uaXnx5BPpMs3ic9sub5d XR+s77bRibbgzt9wHQQGj/KFhGoMUFuTO7Frpo3tkeR1J9awlV5bqgKcLFPpnVkJR6HntUGPpnTo JN4wFnpdEnS81LxdGoJYrP6OvveFphgV+RjaIjWoTpQ4/q3JyXlHfe/Lbhxqcoc2PP6B8qLyu8LP y3kXO7f6fnKu+KUt0xDSBKZdkZ1TzRGEvu2Abc832IlNwReZybRZd2I98g2257FFqbgBUNb25il9 G66Md/E8ckK1hR4P+579sq7lhee/KglnaCQsqOh51UnLiIqe4xZYDbKZMp6BM9a3YtNFS9rMHOQf ZDBlP7ao3BsVayxJ5N7xJRvfYDD04fhMs0JvQ6oyGHq0Od09/sKqamJe78xKjuBSApHK0xquRFM3 OYIHClh9r6nUM6SvAPRPUBMaPkZRJG1OOSWu/ubS0rLBuTQ5pV0lKGKzucxocDgaUAmS89rbLAr6 rjiFQHCk3SDgOesxeiIu0UzhyjVzycavyeAY/TPQiQ3Jeu73aGFE34ZbXlx+Oohe+5GDDkfNwasA i8/7RnHuBNF5107lii+W8YZOT08vHLE06OcWltyP03i3tYUZUSTnRGbLC0b6J48ei2DfwBPvd7p9 wjhAKBnLsBjoYUG/2RXTO11nhBNbTqgFTjgaOGQWJxZ2JEc6OBgkNsqJjcgdVhv6MplsRYVnKFdn TBrLQYH2MIFUCg5DUwgloh2ncVcTstp/3Ng2xjQkG9IU0EekCJ92CSwrJJAYmDyDys67+GlfVUYx 7oAY3hUcicnYuF5fuQSWFvrROH/E+9wf5SKHV6+qxmdxFgO9RqP5XluITFNjZ5hpUwed2FxCBQa8 rZlMG9uj6QaHKlFmJZ6mBCdZY9VGjGDfSiuQvuIWVAPs4ci+bZ7IeidAK52eITUgKln0rqBNlb/b 0OeUylleYfXYKI6AQqupulde0apyEXadoUIz3oOOLAI2mF77znb7kXcV+in5tK/Ip+OvbJzh9nwC vsC8TqxXEYT+vIHHfUiAc3QfqJNcpRo5dT+eXtg54BfdiIXQdpp0hq5Dq7ko8Su75PyrO432mAL6 jELpOEodMPXKp76rwvSMFpVFbSJR5lzKaXaXrCWNGQg9BZ8G9pkLepRzg1KMDXRiUWYlKal/ZXFp +ZApHMy2rleY1MSmRa9QDpZjjsJ8COztltWRaYTOdaGebPzh/Pz84+aGHsXjwxMb3sFyZvYIeNQm KCJUzOnnWRT0ipSB5xqdzxnoxDZiP93xcabNrNzsxOIj13LqDbTn9wV1g+DsoQVTHveBbHR+62h+ XGbb6xR63Z+8Q9lYhAK9HJy37hkATf1O0NRIY0intttKaCz0U1PzDn60mjvbLe+bUzgsusUFzV1q qsVAj0Doiut7h2vfZBD0KGpTSuACPC7SDJmVa6O8rXPC+oKUYYtSNmEKkFd/5UVz7RRbWtbYCGXq mOyzPSJaimieHM7G7FsHL92JWMSIesBpHOKYE/oq/hDdnVK5PgttaHehR7NgSDz/1vKyxtZioNcs aWxajkv/t8ah0WDozZdOvO7EumUZbNo87ScGPsnPg9GJhXBzQf/QzKmcIhZW9Y/4R/O+RMfvaYMW JUeFxTd8vLSk+a65oE8tkHSQowTAncIGHsFrcvFnYdsZ1zZtFGHOqyORsfYT3ZtcBG3wUhOKhVat f76Tdts16McbJ6gos5JtYGblXfMGF2eeGD2WTlxmkBP7bIAYEGKHAIP/+nO7Bfx9m3Fenw2LSBIt OsKXfxeqTc6tdxgH8FsvZZgL+uHRH+WIOl9ta2pXtTVAiaQvt1XVKf7ZyS0GHHCAg4lTJLB3iQc4 9zRA8M4Bzr5lgJrQcJVAYgZBBZtCroGsYM8QFt6ioB/MvcQTGJFZeS8FoRhLKTatXb+WWXnQtw4c CO7E8uG3Vsf66msHdF5lAP2rn4LGN94w5hgOYzU1s+ATEt/0F22pty7+lSA6VdC2uyuyK8+QAlL/ cujIKQh67npnLMKEwKJCx3ev2mrXoJeEn3+hwanVKOg3Es5O4WED4mjYiG8SOQSBgwQaIET1AUL0 AHaKwXayj7gAXOKUICxv9PelzZOle/UCN4uWIngRbcV7yN71KQZ55T0/2U3okcISG6cdodmBTJkH nWzPEDbgCIaSLBH62DSR8dCjCISY2r1kaGblg6kIaMRnEWpBFr4MpOFLQLqRSrUtAiVhglu1Xf8m 4cqmtlVTz39I8vnjXLZ4OgTW7SlLAB4JvqyL2qBHWwnpGc0vGQq9VzDrMwi93rNYXetIk0dwjdZ1 BrT+EJvW/KEh6RrGKilXN/ToiBVqAv+XRkM/N75wuNlfAqoNzKzUlZJQB+GvN4GEhHagjB94fS+B nZl7j4By1o25BzRhPtCWeegaWA2o8fwGnd+Vjkm8Qjg6oGcCr9DqFbF8XO8EutnFpX0BMbwb2pLO 0LOO+FfAGah3zNi2m5ya85ErJxg7vf50oUytC3q0bTEolocOt/quUdCPccZThO5i7BQDU0FvMsEy oV1cl0tVe3qycEahTBGT3vZf2cXy6pnZhaP6fr+U1892D6rUmmOOoil1zSOFur7LbhwqRTu2dC36 oOMuClh9Q4bUK6u0U+gWpH2DCgqpeodyQX6FQqUvZFinmlt0ZwsuD9JS2+6k5Il3/D+9mJV9l3Rt IkGzEjpYqq1LLTAK+p7kgRbMibVA6NGxIy0+UjAunIjbS+gjTwl+ZudVgp1wEBDDvZ2Yde5aGW+w fkQ9E7yysvK0jrWPp5QjM5QzpedVXiHad/2jYzLQsX/T0ws6j/lLyRf7o+/rSndwwLbQ1QLYMUfF 8glfjUZjs9N6obJHp4o+0rXZHVs99mNB57H5nWLO4MntZrv5xWXb5i51Xnph50RAbO0q2n9wFLYZ XziSstMyhcbz810DKnXmBqF1D0pcAyis6O0aUs94wTI9s97etlPTi25MtjI4n9XfyG994fmNhciH HiKNkl+tJ7RY3iiPhGsEomPiPy9OLO7fK+CXlzWHQuLqVtC2QPQi1o7sK8Hi3r5RPHAsvPoT+Pfr ELrrWcVd1zOLOq/HpIquU+i1H/tGcrHkK117PtHxIPGZrRNbPV89MWtPDmff2upoEAfvAiy3hRxe A/xotX+C17+x0/rJesdjYD1u69qAvnZ6GfQdoHNLSxYtx6aLRriiUUl2cVc2o0pRwhW9IPGP5kgj k5rmoLl0k0jl3k3LQEl5fjQOgHVw2nGCnURFJ1I5W+Y0ofuizuhH4wHfSPan8LPrQfTamxR6PXAL ZAGP0HoUgbqidaRHm6OFvu2/4+IEFgk9cq47qN2/Qicg7xX0kt7xUGIY+6GXsJZBycAyEtfOsCy6 KywNwYe55Zkw2J7R6HrAb1VteyrDiczWX+BgR9v+fBsImncJiE4VzupTR6FYJQqIbQK2HvlbJsyh DSaoc7lDk8gFQncU2v1oswga0dFAgFvPP9rsEEclCX6rzyb8paWl7wVEcz7V5mtoa0O0T9j52L1O trZZpQLks3prtEI/MzR7vIUs/dLQRSlzq8HpHLiQNvDSXpo2sPGqPHRETwxflmdgoOSc7e7eIZSp PmFcsJP8GWSC5ZTJ2/Stp0xxReEX3bDtkSMbHV7b79oyK6OSBXpvSMkp6+K7UzgGnbSGnZgQwQVC mSpcK/SXmKMFLZ4yzHa2OHsezwciNwkYKVVV7iX09PTm19C5lSYDHppJHsEcUM4b+BnauLPTchRU 9KhRHv9W4GMrvKE1gCccPmVIXXnCSzkh8Q2fI7PL2JPHsONJYHlzS+V1+pYDtsv3Mwo73yGQyvQ+ LxTNNgExtX9eXFw6oBX63uSBAUMzK3cjctPk1X5bxZ/w2UvoUwskr/hG1WMhvI1j7PQd9e+e6ks6 i2UblnCUF/QNgaIISklN/1vecMRHOTt4HcdsUOh1X8zMLboaWl/V+KxbSr70KnKe147lLtD7VGbU Ti4ofTqx8VOeYMTNoFXs2XmbtILOn6OjwPU5TBY9+8Tp5sXNB8dubsRvtlKkP6nDiywTeodG0Ozf cWNleWVPF5jQphGxfDwIjjydkUmCX/tGcbFtgGihCW0LRI1s51mwZs8SmWvn0iP7EpkJKNEMXoNM DmJY9d+yS+XXlMNTscaUh982WhZ3uu13aETHDnsll2L+A5pB7KE/ERrPf1efGUTn4pXwUgT0JSaR c+gezMbqgXwVVNe1o7vX6rp27HgRdk4Oiq+jow3DEhs/yC2TC6emFg8Y2faPneUMtIScaLhxr81L HmpvrO5QaEfYYT82SM4TP681ZLm8tHyoLUh2s8beAoFH2w/xzUAa3TO7l8BreQmPKoYmfVj8wfK8 8p6XaSmiawExvN9GnGpa9aNxVr0orFVPqOPwd2piwyo5vPoX6YWyH2UWd7Fb5eMuJizHDwRt6pN5 ZX2XoDlyLSCa+yklrn6VHFm7mpjdatLEusmpBZ8y3mBNaoH0jdCEhuuorqTw6lWPINaqd0jFKnz+ ql9UzYfx2e3XGFUKOV84Gm7qM4CWljQHitmDmdkl59Wh8Q3zEacasfZGbe0dUrkaRK9dDY2vv+kV XDGbUdg1w2QriFqhnxRfjTl3rNPgMyvNrUanNqA883yvJUGvA8AnNSvAfkQ9a8/iKTGh3zUajf0u luGp+flle6FYba9Wzz5lxud8YwXWVSxX2zNZcnueUGm/uKSx3+1kPlQGFMplwrbmCUfsZ2cXURkO brs41ZXUT0crsWwLXJSqtqsHbb5dYEI4GWjp0Ftl+brnKChmAlrIUpPm3JgEeFw9aHJqB8/lXr66 +YRcq6wyGnrkJPScuvgrvkOLRYQs2Qh42AEFzmIwePryu5odbC2zyiq9oF+z66cdZeG9751z7wS1 OBGoxe+R4LOFLh3gnG8nGMi4PLSysrLf+rKsMgv0WBRnefnpEYa6+mLa0L930xU/7Yrp21WhZ55P 6P+xMn24eW5kLsD6kqwyO/RWWfV11/8DWg8dgPgaldcAAAAASUVORK5CYII= --00000000000053bd7705926d93dc-- From nobody Fri Sep 13 05:23:38 2019 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 EA8A5120227 for ; Fri, 13 Sep 2019 05:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 XtcJX5onbega for ; Fri, 13 Sep 2019 05:23:33 -0700 (PDT) Received: from mx.stet.eu (mx.stet.eu [85.233.205.208]) (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 315231201E0 for ; Fri, 13 Sep 2019 05:23:32 -0700 (PDT) Received: from mail.stet.eu ([10.17.2.21]) by mx.stet.eu with ESMTP id x8DCNUjQ026149-x8DCNUjS026149 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=CAFAIL); Fri, 13 Sep 2019 14:23:30 +0200 Received: from STEMES002.steteu.corp (10.17.2.22) by STEMES001.steteu.corp (10.17.2.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 13 Sep 2019 14:23:30 +0200 Received: from STEMES002.steteu.corp ([::1]) by STEMES002.steteu.corp ([fe80::1c47:3ef0:f04e:a256%14]) with mapi id 15.00.1473.003; Fri, 13 Sep 2019 14:23:30 +0200 From: =?utf-8?B?Um9iYWNoZSBIZXJ2w6k=?= To: Travis Spencer CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Question regarding RFC 7592 Thread-Index: AdVpeCBmbn8uFGEHRDSH6fb8upwECQAnavOAAAX3ktA= Date: Fri, 13 Sep 2019 12:23:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.17.2.170] x-tm-as-product-ver: SMEX-12.5.0.1684-8.5.1010-24908.006 x-tm-as-result: No-18.057000-8.000000-10 x-tmase-matchedrid: 6jmP1Ht9qSueGXFpAoGIoe5i6weAmSDK31asM/gsp2kYDu7Ahk0dDVxf z10OsXj5iZmfBZYgGr+/LUPnfvvbV2H39wOZ1o5GM71h0SMVl8J3G1bsm5zfjLxgMf9QE2eb/0V sNN/sXcWmzeV8Z6u3l1MmJ7W/Vm9GNtF2eLsHxvlZwLSBgxghaPngX/aL8PCNI9L0l0rdbj/3h2 jybQkTkuVLYGUlXRjSV+4hGDe9WkYUpJC1g+xv1yQ7ls378/zHqAn+yHbzwCdq5aiUaVUyIFHXx CnNdK1O+QfFxsleWTfPh+3gPJS8wZcyOP01seuBRTO9mhIXG43DS5Rk8L0emgWybPnS4qkG4wLL vleCnmqkZsniU9dGsGUXmft12LONQR5uKLmqZofuvXp0/rQbmQZyESFXAljfIwfkkTESbiRpjch uPJNZ5OBifUQeQaAn1nhswVyu6E1QBGTXhXVuctqCJFwujpdAAgvM6h73Btr2Nx9aMA5QDiJkpI MWHcbCxOHla5AZ+eCm3B7lRhakqcOOIO9jIpLFcheA8ngAb/upSpNJXHTi8U+86maMM3aS9fGw1 nQ95T+EftyE+H2HLo4mltXV0alofMalxiFMN0ptJYfOb0q5O0NWaKIdBIV4XLYnX4ycMY1wDpvb PoLQyRLpDXY8SPPMucE3Ngmwru6FZ5NatKgouPPYC6FQ+VZVcuFRT+prg4aGe/6YURuOGR7BnNe uthFjWq+w3wy0CCoKbobZSJqYSgQgef9UKVkZipkOZV/lcG+ciUWAJovS34eCLAQuXygwK+I+zs OW7NlgzkVDlD8BHgdCKWAkI/y0hwW3qeYFZHyrm7DrUlmNkIlfAW57f8Kpb7DHElGeXjlzFh5Wt +L9QiVckhPCOd69MtUllpYxkKViba/5DlHIMfRJByhI7YZeftwZ3X11IV0= x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No x-tmase-result: 10--18.057000-8.000000 x-tmase-version: SMEX-12.5.0.1684-8.5.1010-24908.006 x-tm-snts-smtp: F83B3E27B00F08EE0B278AE48F20344192423A44ACC4892C09060C81049733812000:9 Content-Type: multipart/related; boundary="_005_db205bcad6ac495bb558e2b6181ba546STEMES002steteucorp_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Question regarding RFC 7592 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: Fri, 13 Sep 2019 12:23:36 -0000 --_005_db205bcad6ac495bb558e2b6181ba546STEMES002steteucorp_ Content-Type: multipart/alternative; boundary="_000_db205bcad6ac495bb558e2b6181ba546STEMES002steteucorp_" --_000_db205bcad6ac495bb558e2b6181ba546STEMES002steteucorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFRyYXZpcw0KDQpJIHVuZGVyc3RhbmQgdGhhdCwgb25jZSB0aGUgY2xpZW50IGhhcyBy ZXRyaWV2ZWQgaXRzIFtjbGllbnRfaWRdIHRocm91Z2ggUkZDNzU5MSBpbml0aWFsIHJlZ2lzdHJh dGlvbiwgaXQgaXMgdGhlbiBhYmxlIHRvIGFzayBmb3IgYW4gYWNjZXNzIHRva2VuIHRoYXQgd2ls bCBiZSB1c2VkIGZvciBhY2Nlc3NpbmcgdGhlIFJGQzc1OTIgZW50cnktcG9pbnRzLiBBbSBJIHJp Z2h0Pw0KDQpCZXN0IHJlZ2FyZHMNCg0KSGVydsOpDQoNCkRlIDogVHJhdmlzIFNwZW5jZXIgW21h aWx0bzp0cmF2aXMuc3BlbmNlckBjdXJpdHkuaW9dDQpFbnZvecOpIDogdmVuLiAxMyAxMzozMA0K w4AgOiBSb2JhY2hlIEhlcnbDqQ0KQ2MgOiBvYXV0aEBpZXRmLm9yZw0KT2JqZXQgOiBSZTogW09B VVRILVdHXSBRdWVzdGlvbiByZWdhcmRpbmcgUkZDIDc1OTINCg0KTm8uIFRoZSBpbml0aWFsIGFj Y2VzcyB0b2tlbiBpcyBpc3N1ZWQgYnkgdGhlIEFTIHdoZW4gcmVnaXN0cmF0aW9uIGlzIHByb3Rl Y3RlZCAoYXBwZW5kaXggMS4yIGluIFJGQyA3NTkxKS4gQXMgc3RhdGVkIGluIHNlY3Rpb24gMS4y LCB0aGUgbWV0aG9kIGFuZCBtZWFucyBieSB3aGljaCB0aGlzIGlzIG9idGFpbmVkIGNhbiB2YXJ5 LiBUaGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiBpbiBSRkMgNzU5MiBpcyB1c2VkIHRvIHBy b3RlY3QgdGhlIHJlZ2lzdHJhdGlvbiBtYW5hZ2VtZW50IEFQSSBhbmQgYWxsb3cgdXBkYXRlcyB0 byB0aGUgY2xpZW50IGFmdGVyIGl0IGlzIHJlZ2lzdGVyZWQuIFlvdSBtaWdodCBoYXZlIG9uZSAo dGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4pIGJ1dCBub3QgdGhlIG90aGVyIChpbml0aWFs IGFjY2VzcyB0b2tlbikgd2hlbiBvcGVuIHJlZ2lzdHJhdGlvbiBpcyBhbGxvd2VkIChhcHBlbmRp eCAxLjEgaW4gUkZDIDc1OTEpLg0KDQpIVEghDQoNCk9uIEZyaSwgU2VwIDEzLCAyMDE5IGF0IDc6 MzcgQU0gUm9iYWNoZSBIZXJ2w6kgPGhlcnZlLnJvYmFjaGVAc3RldC5ldTxtYWlsdG86aGVydmUu cm9iYWNoZUBzdGV0LmV1Pj4gd3JvdGU6DQpIaQ0KDQpSRkMgNzU5MiBpbnRyb2R1Y2VzIGEgwqsg UmVnaXN0cmF0aW9uIEFjY2VzcyBUb2tlbiDCuy4gQXJlIHRoaXMgdG9rZW4gYW5kIHRoZSB3YXkg dG8gZ2V0IGl0IHNpbWlsYXIgdG8gd2hhdCBpcyBzcGVjaWZpZWQgYXMg4oCcSW5pdGlhbCBBY2Nl c3MgVG9rZW7igJ0gaW4gUkZDIDc1OTEvQXBwZW5kaXggQSA/DQoNCklmIHNvLCBjYW4gdGhlIE9w ZW4gRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIChSRkM3NTkxL0EuMS4xKSBiZSBleHRyYXBv bGF0ZWQgdG8gUkZDNzU5MiBhcyB0aGUgc2FtZSB3YXk/DQoNClRoYW5rcyBpbiBhZHZhbmNlIGZv ciB5b3VyIGNsYXJpZmljYXRpb24uDQoNCkhlcnbDqSBST0JBQ0hFDQpEaXJlY3Rpb24gTWFya2V0 aW5nIGV0IETDqXZlbG9wcGVtZW50DQoNCkxJR05FIERJUkVDVEUNClQuICszMygwKTEgNTUgMjMg NTUgNDUNCmhlcnZlLnJvYmFjaGVAc3RldC5ldTxtYWlsdG86aGVydmUucm9iYWNoZUBzdGV0LmV1 Pg0KDQoNCg0KDQoNCg0KDQoNCltjaWQ6aW1hZ2UwMDMucG5nQDAxRDE0MzI3LjcwNzU4MkYwXQ0K DQpTVEVUIChTSUVHRSBTT0NJQUwpDQoxMDAsIEVzcGxhbmFkZSBkdSBHw6luw6lyYWwgZGUgR2F1 bGxlDQpDxZN1ciBEw6lmZW5zZSDigJMgVG91ciBCDQo5MjkzMiBMYSBEw6lmZW5zZSBjZWRleA0K DQp3d3cuc3RldC5ldTxodHRwOi8vd3d3LnN0ZXQuZXUvPg0KDQoNCg0KQ2UgbWVzc2FnZSBldCB0 b3V0ZXMgbGVzIHBpw6hjZXMgam9pbnRlcyBzb250IMOpdGFibGlzIMOgIGwnaW50ZW50aW9uIGV4 Y2x1c2l2ZSBkZSBzZXMgZGVzdGluYXRhaXJlcyBldCBzb250IGNvbmZpZGVudGllbHMuDQpTaSB2 b3VzIHJlY2V2ZXogY2UgbWVzc2FnZSBwYXIgZXJyZXVyIG91IHMnaWwgbmUgdm91cyBlc3QgcGFz IGRlc3RpbsOpLCBtZXJjaSBkZSBsZSBkw6l0cnVpcmUgYWluc2kgcXVlIHRvdXRlIGNvcGllIGRl IHZvdHJlIHN5c3TDqG1lIGV0IGQnZW4gYXZlcnRpciBpbW3DqWRpYXRlbWVudCBsJ2V4cMOpZGl0 ZXVyLg0KVG91dGUgbGVjdHVyZSBub24gYXV0b3Jpc8OpZSwgdG91dGUgdXRpbGlzYXRpb24gZGUg Y2UgbWVzc2FnZSBxdWkgbidlc3QgcGFzIGNvbmZvcm1lIMOgIHNhIGRlc3RpbmF0aW9uLCB0b3V0 ZSBkaWZmdXNpb24gb3UgdG91dGUgcHVibGljYXRpb24sIHRvdGFsZSBvdSBwYXJ0aWVsbGUsIGVz dCBpbnRlcmRpdGUuDQpMJ0ludGVybmV0IG5lIHBlcm1ldHRhbnQgcGFzIGQnYXNzdXJlciBsJ2lu dMOpZ3JpdMOpIGRlIGNlIG1lc3NhZ2Ugw6lsZWN0cm9uaXF1ZSBzdXNjZXB0aWJsZSBkJ2FsdMOp cmF0aW9uLCBTVEVUIGTDqWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXTDqSBhdSB0aXRyZSBkZSBj ZSBtZXNzYWdlIGRhbnMgbCdoeXBvdGjDqHNlIG/DuSBpbCBhdXJhaXQgw6l0w6kgbW9kaWZpw6ks IGTDqWZvcm3DqSBvdSBmYWxzaWZpw6kuDQpOJ2ltcHJpbWV6IGNlIG1lc3NhZ2UgcXVlIHNpIG7D qWNlc3NhaXJlLCBwZW5zZXogw6AgbCdlbnZpcm9ubmVtZW50Lg0KDQpUaGlzIG1lc3NhZ2UgYW5k IGFueSBhdHRhY2htZW50cyBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBpbnRlbmRlZCBhZGRy ZXNzZWVzIGFuZCBpcyBjb25maWRlbnRpYWwuDQpJZiB5b3UgcmVjZWl2ZSB0aGlzIG1lc3NhZ2Ug aW4gZXJyb3IsIG9yIGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKSwgcGxlYXNlIGRl bGV0ZSBpdCBhbmQgYW55IGNvcGllcyBmcm9tIHlvdXIgc3lzdGVtcyBhbmQgaW1tZWRpYXRlbHkg bm90aWZ5IHRoZSBzZW5kZXIuDQpBbnkgdW5hdXRob3JpemVkIHZpZXcsIHVzZSB0aGF0IGRvZXMg bm90IGNvbXBseSB3aXRoIGl0cyBwdXJwb3NlLCBkaXNzZW1pbmF0aW9uIG9yIGRpc2Nsb3N1cmUs IGVpdGhlciB3aG9sZSBvciBwYXJ0aWFsLCBpcyBwcm9oaWJpdGVkLg0KU2luY2UgdGhlIGludGVy bmV0IGNhbm5vdCBndWFyYW50ZWUgdGhlIGludGVncml0eSBvZiB0aGlzIG1lc3NhZ2Ugd2hpY2gg bWF5IG5vdCBiZSByZWxpYWJsZSwgU1RFVCBzaGFsbCBub3QgYmUgbGlhYmxlIGZvciB0aGUgbWVz c2FnZSBpZiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpEbyBub3QgcHJpbnQgdGhp cyBtZXNzYWdlIHVubGVzcyBpdCBpcyBuZWNlc3NhcnksIHBsZWFzZSBjb25zaWRlciB0aGUgZW52 aXJvbm1lbnQuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KQ2Ug bWVzc2FnZSBldCB0b3V0ZXMgbGVzIHBpw6hjZXMgam9pbnRlcyBzb250IMOpdGFibGlzIMOgIGwn aW50ZW50aW9uIGV4Y2x1c2l2ZSBkZSBzZXMgZGVzdGluYXRhaXJlcyBldCBzb250IGNvbmZpZGVu dGllbHMuDQpTaSB2b3VzIHJlY2V2ZXogY2UgbWVzc2FnZSBwYXIgZXJyZXVyIG91IHMnaWwgbmUg dm91cyBlc3QgcGFzIGRlc3RpbsOpLCBtZXJjaSBkZSBsZSBkw6l0cnVpcmUgYWluc2kgcXVlIHRv dXRlIGNvcGllIGRlIHZvdHJlIHN5c3TDqG1lIGV0IGQnZW4gYXZlcnRpciBpbW3DqWRpYXRlbWVu dCBsJ2V4cMOpZGl0ZXVyLg0KVG91dGUgbGVjdHVyZSBub24gYXV0b3Jpc8OpZSwgdG91dGUgdXRp bGlzYXRpb24gZGUgY2UgbWVzc2FnZSBxdWkgbidlc3QgcGFzIGNvbmZvcm1lIMOgIHNhIGRlc3Rp bmF0aW9uLCB0b3V0ZSBkaWZmdXNpb24gb3UgdG91dGUgcHVibGljYXRpb24sIHRvdGFsZSBvdSBw YXJ0aWVsbGUsIGVzdCBpbnRlcmRpdGUuDQpMJ0ludGVybmV0IG5lIHBlcm1ldHRhbnQgcGFzIGQn YXNzdXJlciBsJ2ludMOpZ3JpdMOpIGRlIGNlIG1lc3NhZ2Ugw6lsZWN0cm9uaXF1ZSBzdXNjZXB0 aWJsZSBkJ2FsdMOpcmF0aW9uLCBTVEVUIGTDqWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXTDqSBh dSB0aXRyZSBkZSBjZSBtZXNzYWdlIGRhbnMgbCdoeXBvdGjDqHNlIG/DuSBpbCBhdXJhaXQgw6l0 w6kgbW9kaWZpw6ksIGTDqWZvcm3DqSBvdSBmYWxzaWZpw6kuDQpOJ2ltcHJpbWV6IGNlIG1lc3Nh Z2UgcXVlIHNpIG7DqWNlc3NhaXJlLCBwZW5zZXogw6AgbCdlbnZpcm9ubmVtZW50Lg0KDQpUaGlz IG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBp bnRlbmRlZCBhZGRyZXNzZWVzIGFuZCBpcyBjb25maWRlbnRpYWwuDQpJZiB5b3UgcmVjZWl2ZSB0 aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIG9yIGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudChz KSwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgYW55IGNvcGllcyBmcm9tIHlvdXIgc3lzdGVtcyBhbmQg aW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIuDQpBbnkgdW5hdXRob3JpemVkIHZpZXcsIHVz ZSB0aGF0IGRvZXMgbm90IGNvbXBseSB3aXRoIGl0cyBwdXJwb3NlLCBkaXNzZW1pbmF0aW9uIG9y IGRpc2Nsb3N1cmUsIGVpdGhlciB3aG9sZSBvciBwYXJ0aWFsLCBpcyBwcm9oaWJpdGVkLg0KU2lu Y2UgdGhlIGludGVybmV0IGNhbm5vdCBndWFyYW50ZWUgdGhlIGludGVncml0eSBvZiB0aGlzIG1l c3NhZ2Ugd2hpY2ggbWF5IG5vdCBiZSByZWxpYWJsZSwgU1RFVCBzaGFsbCBub3QgYmUgbGlhYmxl IGZvciB0aGUgbWVzc2FnZSBpZiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpEbyBu b3QgcHJpbnQgdGhpcyBtZXNzYWdlIHVubGVzcyBpdCBpcyBuZWNlc3NhcnksIHBsZWFzZSBjb25z aWRlciB0aGUgZW52aXJvbm1lbnQuDQo= --_000_db205bcad6ac495bb558e2b6181ba546STEMES002steteucorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToy IDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJBcmlhbCBSb3VuZGVkIE1UIEJvbGQiOw0KCXBhbm9zZS0xOjIgMTUg NyA0IDMgNSA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hv IjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0 IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGhhbmtzIFRyYXZpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHVu ZGVyc3RhbmQgdGhhdCwgb25jZSB0aGUgY2xpZW50IGhhcyByZXRyaWV2ZWQgaXRzIFtjbGllbnRf aWRdIHRocm91Z2ggUkZDNzU5MSBpbml0aWFsIHJlZ2lzdHJhdGlvbiwgaXQgaXMgdGhlbiBhYmxl IHRvIGFzayBmb3IgYW4gYWNjZXNzIHRva2VuDQogdGhhdCB3aWxsIGJlIHVzZWQgZm9yIGFjY2Vz c2luZyB0aGUgUkZDNzU5MiBlbnRyeS1wb2ludHMuIEFtIEkgcmlnaHQ/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5IZXJ2w6k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVHJhdmlzIFNwZW5jZXIgW21haWx0bzp0cmF2aXMuc3Bl bmNlckBjdXJpdHkuaW9dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gdmVuLiAxMyAxMzoz MDxicj4NCjxiPsOAJm5ic3A7OjwvYj4gUm9iYWNoZSBIZXJ2w6k8YnI+DQo8Yj5DYyZuYnNwOzo8 L2I+IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW09BVVRILVdH XSBRdWVzdGlvbiByZWdhcmRpbmcgUkZDIDc1OTI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Tm8uIFRoZSBpbml0aWFsIGFjY2VzcyB0b2tlbiBpcyBpc3N1ZWQg YnkgdGhlIEFTIHdoZW4gcmVnaXN0cmF0aW9uIGlzIHByb3RlY3RlZCAoYXBwZW5kaXggMS4yIGlu IFJGQyA3NTkxKS4gQXMgc3RhdGVkIGluIHNlY3Rpb24gMS4yLCB0aGUgbWV0aG9kIGFuZCBtZWFu cyBieSB3aGljaCB0aGlzIGlzIG9idGFpbmVkIGNhbiB2YXJ5LiBUaGUgcmVnaXN0cmF0aW9uIGFj Y2VzcyB0b2tlbiBpbiBSRkMgNzU5MiBpcw0KIHVzZWQgdG8gcHJvdGVjdCB0aGUgcmVnaXN0cmF0 aW9uIG1hbmFnZW1lbnQgQVBJIGFuZCBhbGxvdyB1cGRhdGVzIHRvIHRoZSBjbGllbnQgYWZ0ZXIg aXQgaXMgcmVnaXN0ZXJlZC4gWW91IG1pZ2h0IGhhdmUgb25lICh0aGUgcmVnaXN0cmF0aW9uIGFj Y2VzcyB0b2tlbikgYnV0IG5vdCB0aGUgb3RoZXIgKGluaXRpYWwgYWNjZXNzIHRva2VuKSB3aGVu IG9wZW4gcmVnaXN0cmF0aW9uIGlzIGFsbG93ZWQgKGFwcGVuZGl4IDEuMSBpbiBSRkMgNzU5MSku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhU SCE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gRnJpLCBTZXAgMTMsIDIwMTkgYXQgNzozNyBBTSBSb2JhY2hlIEhlcnbDqSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmhlcnZlLnJvYmFjaGVAc3RldC5ldSI+aGVydmUucm9iYWNoZUBzdGV0LmV1PC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5SRkMgNzU5MiBpbnRyb2R1Y2VzIGEgwqsmbmJzcDtSZWdp c3RyYXRpb24gQWNjZXNzIFRva2VuJm5ic3A7wrsuIEFyZSB0aGlzIHRva2VuIGFuZCB0aGUgd2F5 IHRvIGdldCBpdCBzaW1pbGFyIHRvIHdoYXQgaXMgc3BlY2lmaWVkIGFzIOKAnEluaXRpYWwgQWNj ZXNzIFRva2Vu4oCdIGluIFJGQyA3NTkxL0FwcGVuZGl4DQogQSA/PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+SWYgc28sIGNhbiB0aGUgT3BlbiBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gKFJG Qzc1OTEvQS4xLjEpIGJlIGV4dHJhcG9sYXRlZCB0byBSRkM3NTkyIGFzIHRoZSBzYW1lIHdheT88 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MgaW4gYWR2YW5jZSBmb3IgeW91ciBjbGFyaWZp Y2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCBSb3VuZGVkIE1UIEJvbGQmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGVy dsOpIFJPQkFDSEU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwgUm91 bmRlZCBNVCBCb2xkJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRpcmVjdGlvbiBNYXJr ZXRpbmcgZXQgRMOpdmVsb3BwZW1lbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwgUm91bmRlZCBNVCBCb2xkJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5MSUdORSBESVJFQ1RFDQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VC4gJiM0 MzszMygwKTEgNTUgMjMgNTUgNDU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOmhlcnZl LnJvYmFjaGVAc3RldC5ldSIgdGFyZ2V0PSJfYmxhbmsiPmhlcnZlLnJvYmFjaGVAc3RldC5ldTwv YT4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxw YWRkaW5nPSIwIiBhbGlnbj0ibGVmdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDo2LjBw dCI+DQo8dGQgd2lkdGg9IjEiIHN0eWxlPSJ3aWR0aDouNzVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDBjbTtoZWlnaHQ6Ni4wcHQiPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1l bGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVs ZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpv bnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPGltZyBib3JkZXI9IjAiIHdp ZHRoPSIyOTgiIGhlaWdodD0iMSIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJjaWQ6aW1hZ2UwMDEu cG5nQDAxRDU2QTNFLkQwNDVBNzQwIj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90 Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjE4OSIgaGVpZ2h0PSI1OSIgaWQ9ImdtYWlsLW1fLTc1NTUx Nzk1NDkxMDgzMzk4NDdJbWFnZV94MDAyMF8xIiBzcmM9ImNpZDppbWFnZTAwMi5wbmdAMDFENTZB M0UuRDA0NUE3NDAiIGFsdD0iY2lkOmltYWdlMDAzLnBuZ0AwMUQxNDMyNy43MDc1ODJGMCI+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNURVQgKFNJRUdFIFNPQ0lBTCkN Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4xMDAsIEVzcGxhbmFkZSBkdSBHw6luw6lyYWwgZGUgR2F1bGxlDQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Q8WTdXIgRMOpZmVuc2Ug4oCTIFRvdXIgQg0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjkyOTMyIExhIETDqWZlbnNlIGNlZGV4PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48YSBocmVmPSJodHRwOi8vd3d3LnN0ZXQuZXUvIiB0YXJnZXQ9Il9ibGFuayI+d3d3LnN0 ZXQuZXU8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmdyYXkiPjxicj4NCkNlIG1lc3NhZ2UgZXQg dG91dGVzIGxlcyBwacOoY2VzIGpvaW50ZXMgc29udCDDqXRhYmxpcyDDoCBsJ2ludGVudGlvbiBl eGNsdXNpdmUgZGUgc2VzIGRlc3RpbmF0YWlyZXMgZXQgc29udCBjb25maWRlbnRpZWxzLjxicj4N ClNpIHZvdXMgcmVjZXZleiBjZSBtZXNzYWdlIHBhciBlcnJldXIgb3UgcydpbCBuZSB2b3VzIGVz dCBwYXMgZGVzdGluw6ksIG1lcmNpIGRlIGxlIGTDqXRydWlyZSBhaW5zaSBxdWUgdG91dGUgY29w aWUgZGUgdm90cmUgc3lzdMOobWUgZXQgZCdlbiBhdmVydGlyIGltbcOpZGlhdGVtZW50IGwnZXhw w6lkaXRldXIuPGJyPg0KVG91dGUgbGVjdHVyZSBub24gYXV0b3Jpc8OpZSwgdG91dGUgdXRpbGlz YXRpb24gZGUgY2UgbWVzc2FnZSBxdWkgbidlc3QgcGFzIGNvbmZvcm1lIMOgIHNhIGRlc3RpbmF0 aW9uLCB0b3V0ZSBkaWZmdXNpb24gb3UgdG91dGUgcHVibGljYXRpb24sIHRvdGFsZSBvdSBwYXJ0 aWVsbGUsIGVzdCBpbnRlcmRpdGUuPGJyPg0KTCdJbnRlcm5ldCBuZSBwZXJtZXR0YW50IHBhcyBk J2Fzc3VyZXIgbCdpbnTDqWdyaXTDqSBkZSBjZSBtZXNzYWdlIMOpbGVjdHJvbmlxdWUgc3VzY2Vw dGlibGUgZCdhbHTDqXJhdGlvbiwgU1RFVCBkw6ljbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0w6kg YXUgdGl0cmUgZGUgY2UgbWVzc2FnZSBkYW5zIGwnaHlwb3Row6hzZSBvw7kgaWwgYXVyYWl0IMOp dMOpIG1vZGlmacOpLCBkw6lmb3Jtw6kgb3UgZmFsc2lmacOpLjxicj4NCk4naW1wcmltZXogY2Ug bWVzc2FnZSBxdWUgc2kgbsOpY2Vzc2FpcmUsIHBlbnNleiDDoCBsJ2Vudmlyb25uZW1lbnQuPGJy Pg0KPGJyPg0KVGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgaW50ZW5kZWQgYWRkcmVzc2VlcyBhbmQgaXMgY29uZmlkZW50aWFsLjxicj4N CklmIHlvdSByZWNlaXZlIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgb3IgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50KHMpLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBhbnkgY29waWVzIGZyb20g eW91ciBzeXN0ZW1zIGFuZCBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlci48YnI+DQpBbnkg dW5hdXRob3JpemVkIHZpZXcsIHVzZSB0aGF0IGRvZXMgbm90IGNvbXBseSB3aXRoIGl0cyBwdXJw b3NlLCBkaXNzZW1pbmF0aW9uIG9yIGRpc2Nsb3N1cmUsIGVpdGhlciB3aG9sZSBvciBwYXJ0aWFs LCBpcyBwcm9oaWJpdGVkLjxicj4NClNpbmNlIHRoZSBpbnRlcm5ldCBjYW5ub3QgZ3VhcmFudGVl IHRoZSBpbnRlZ3JpdHkgb2YgdGhpcyBtZXNzYWdlIHdoaWNoIG1heSBub3QgYmUgcmVsaWFibGUs IFNURVQgc2hhbGwgbm90IGJlIGxpYWJsZSBmb3IgdGhlIG1lc3NhZ2UgaWYgbW9kaWZpZWQsIGNo YW5nZWQgb3IgZmFsc2lmaWVkLjxicj4NCkRvIG5vdCBwcmludCB0aGlzIG1lc3NhZ2UgdW5sZXNz IGl0IGlzIG5lY2Vzc2FyeSwgcGxlYXNlIGNvbnNpZGVyIHRoZSBlbnZpcm9ubWVudC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBz aXplPSIxIj48YnI+DQpDZSBtZXNzYWdlIGV0IHRvdXRlcyBsZXMgcGnDqGNlcyBqb2ludGVzIHNv bnQgw6l0YWJsaXMgw6AgbCdpbnRlbnRpb24gZXhjbHVzaXZlIGRlIHNlcyBkZXN0aW5hdGFpcmVz IGV0IHNvbnQgY29uZmlkZW50aWVscy48YnI+DQpTaSB2b3VzIHJlY2V2ZXogY2UgbWVzc2FnZSBw YXIgZXJyZXVyIG91IHMnaWwgbmUgdm91cyBlc3QgcGFzIGRlc3RpbsOpLCBtZXJjaSBkZSBsZSBk w6l0cnVpcmUgYWluc2kgcXVlIHRvdXRlIGNvcGllIGRlIHZvdHJlIHN5c3TDqG1lIGV0IGQnZW4g YXZlcnRpciBpbW3DqWRpYXRlbWVudCBsJ2V4cMOpZGl0ZXVyLjxicj4NClRvdXRlIGxlY3R1cmUg bm9uIGF1dG9yaXPDqWUsIHRvdXRlIHV0aWxpc2F0aW9uIGRlIGNlIG1lc3NhZ2UgcXVpIG4nZXN0 IHBhcyBjb25mb3JtZSDDoCBzYSBkZXN0aW5hdGlvbiwgdG91dGUgZGlmZnVzaW9uIG91IHRvdXRl IHB1YmxpY2F0aW9uLCB0b3RhbGUgb3UgcGFydGllbGxlLCBlc3QgaW50ZXJkaXRlLjxicj4NCkwn SW50ZXJuZXQgbmUgcGVybWV0dGFudCBwYXMgZCdhc3N1cmVyIGwnaW50w6lncml0w6kgZGUgY2Ug bWVzc2FnZSDDqWxlY3Ryb25pcXVlIHN1c2NlcHRpYmxlIGQnYWx0w6lyYXRpb24sIFNURVQgZMOp Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdMOpIGF1IHRpdHJlIGRlIGNlIG1lc3NhZ2UgZGFucyBs J2h5cG90aMOoc2Ugb8O5IGlsIGF1cmFpdCDDqXTDqSBtb2RpZmnDqSwgZMOpZm9ybcOpIG91IGZh bHNpZmnDqS48YnI+DQpOJ2ltcHJpbWV6IGNlIG1lc3NhZ2UgcXVlIHNpIG7DqWNlc3NhaXJlLCBw ZW5zZXogw6AgbCdlbnZpcm9ubmVtZW50Ljxicj4NCjxicj4NClRoaXMgbWVzc2FnZSBhbmQgYW55 IGF0dGFjaG1lbnRzIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGludGVuZGVkIGFkZHJlc3Nl ZXMgYW5kIGlzIGNvbmZpZGVudGlhbC48YnI+DQpJZiB5b3UgcmVjZWl2ZSB0aGlzIG1lc3NhZ2Ug aW4gZXJyb3IsIG9yIGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKSwgcGxlYXNlIGRl bGV0ZSBpdCBhbmQgYW55IGNvcGllcyBmcm9tIHlvdXIgc3lzdGVtcyBhbmQgaW1tZWRpYXRlbHkg bm90aWZ5IHRoZSBzZW5kZXIuPGJyPg0KQW55IHVuYXV0aG9yaXplZCB2aWV3LCB1c2UgdGhhdCBk b2VzIG5vdCBjb21wbHkgd2l0aCBpdHMgcHVycG9zZSwgZGlzc2VtaW5hdGlvbiBvciBkaXNjbG9z dXJlLCBlaXRoZXIgd2hvbGUgb3IgcGFydGlhbCwgaXMgcHJvaGliaXRlZC48YnI+DQpTaW5jZSB0 aGUgaW50ZXJuZXQgY2Fubm90IGd1YXJhbnRlZSB0aGUgaW50ZWdyaXR5IG9mIHRoaXMgbWVzc2Fn ZSB3aGljaCBtYXkgbm90IGJlIHJlbGlhYmxlLCBTVEVUIHNoYWxsIG5vdCBiZSBsaWFibGUgZm9y IHRoZSBtZXNzYWdlIGlmIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48YnI+DQpEbyBu b3QgcHJpbnQgdGhpcyBtZXNzYWdlIHVubGVzcyBpdCBpcyBuZWNlc3NhcnksIHBsZWFzZSBjb25z aWRlciB0aGUgZW52aXJvbm1lbnQuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_db205bcad6ac495bb558e2b6181ba546STEMES002steteucorp_-- --_005_db205bcad6ac495bb558e2b6181ba546STEMES002steteucorp_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=134; creation-date="Fri, 13 Sep 2019 12:23:29 GMT"; modification-date="Fri, 13 Sep 2019 12:23:29 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAASoAAAABCAYAAABpJuNuAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAbSURBVDhPYygwWLAfiP+P4lE8ikfx4MQL9gMA lmac9TWs31MAAAAASUVORK5CYII= --_005_db205bcad6ac495bb558e2b6181ba546STEMES002steteucorp_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=6542; creation-date="Fri, 13 Sep 2019 12:23:30 GMT"; modification-date="Fri, 13 Sep 2019 12:23:30 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAL0AAAA7CAYAAAAuPov1AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABkOSURBVHja 7Z15WJvHncfTNpttkl6bwwfmkATYmBtJxlziEIcAYcDmNmAuIQ6DOIQkQIAkwCAkARYgY0EINiEK 0SY4CZuwLtuFrmnLs6V9gvuQJmlIt9uGHFtrW3sbQmtnduYFbGxLgC5QUv3xfeARr953Zt7PzPx+ v/nN8IhIJHrEKqv+nmRtBKus0FtllRV6M+uzz245MYSTzKiCy2OkJOUV4qkLV0hJuyfvxAtXQnNG ruQ1vCUbn1ogW6GwQm9WccRXyyhZwzedYgfBwdBeYBO2N0LPtou4CIjJQ1+IB2dqrWBYoTeLChpe E7smDoOn/KRgf2AHOEiR7KkOBHWAf4JlCci8DFST1hHfCr2J1SifPu1xchg87b/3sD8ou4h+kFf3 aq8VDiv0JhMA4NHgrOc+fCawy+KARzoUfgH4nOq/YIXDCr3JpBiZDT4SewHsC7Q84LGRHkKfxBpT WuoLk8snHyNEML9DIOhQBO/JRx4B3/i6AMpkir+9VX0jIsRPWDz0+fzxaseYAcyGtjTg98MyOcYo QVnzm0xLhUAoUdV6BrM/IfgUfuJIYt4ngk/RJ8Swql8rlVPf+7pAn5LXoTx8nPVQXZHwPsWfxKQJ pi0eenrRC6MoWmKJo/z+ICk4HNv3uVAxe8Rioe94SewVWgscycXA6VjJfXIklwKfsMpbEPrvf42g f/WIf9VDdUUikM+CmFThuxYNPbTnH/NNufjL/cHdFgn9s4EyQEru/wMs57ctF3pVq2dwDSAQCwEc 7e4TgVgEiGGVf/yaQT8GR/qH6oqEJxZD6AXXLRp69ezSPs/4vs/3BUotEvqDIb0gJGvoLQi9xdrE Vui/YtAzBBNUp5j+2weCLNOJtQ1XgKSKsXZLhsAK/VcM+ty68XP2kf3ggCXa84EdwOXEAOBJplKt 0FuhN5U9/43wvOE3LNWJfTZQAjwTFH8bn1p0tkJvhd50Tmzqxf9GzqJFRm6gc01M6r8Oy/kPpqz3 /PySk1I17ZZRKnMTilVuswvvucFnPGGF/u8AevHQjPNRuuIvKCxoidAfCOkBNMbll42t58rKyrO8 5tHyuNNtL/nReG8HRHP/6kfjAg8KC5Co1SAkng9IYdUf0tOb3z5d1N0nkKjTl5Y+O7zT+5/rflm4 NfRV/2PO6BMaFIRitReTrWScPNMhCY3nj+aV972dVdT5SzKV3ZNZ1CUp5Q0nTE0tOpjieekF0he3 gj42XbhgsdBz+n96+nDcMNhP6QIHQ4xR99rPYNPNGGihjBCtBNkcNdcIGH7AYPUKqYlNN9wp1cDp WBkgkEqAgzcDE57IBDifQmDvWQA/L4a/F4MjfhXAK6QGhJzgf5GcK5mpax5lq8dn7nYAjUbzeESc cD/BlbmfQFpTJX+w24PC1gm9d0iFJi5D6LxxvW6x9jN5ymf0mLEOMCsVQnrGuQ88gyuAa2AVOBpQ BRzJZ4G9FxPWsQg4QzjRZx6w/r6RnP+jp7X+q1A8dga2zbd28oypqaUnSRGC++obn9n62uHj5Tqh jzzV+M5O6nr4sPwxo6CfUcweHRdMnL3EHK0Y3oHUZa9UMPIu/OTA8XpgQ+YAm2NGiFwDf3LBwYBm k8GPnFiUGiFQTIcb0h6q8WmXtELZ+y4BlRCAQq1A6hIedQQv1ClKgGtQDcgs7rq72MITDKcTqbxb 8Jpb8FpMzseKVh1JRVvd80snEvP/Nq7XpSN+rFspOW28HXTmb1c3DTcHxNR+ikB38EZlZm5ZR/Q3 1MHR4pFXaA2ISWtZUAxNZm73rAyGrAk+45Yjkbm5vn/bqv2cyEV3tqurs+/ZW4d9GBEGQT+rmgvq jFJcaSZ13G71koEWD+mO1OHZDcIcM8Gz9v7AziHENMKHg0PuuRDaDqPBfyZAAnxTlZ8vLWvs9AV+ YnLONTJZ9AccsRQDeKewa32Bx8pBUm772Ma9k/PE0iN+lfDFFt8VYSf32XS9NqEZwYfKBWW8wfgt 11UmZlwzCrsX3Ck1GOz6dOZ7nZqBzWq+UbWghHOxZyufKS69ZdqRXHZfWbe7P2EH9UUzBcGHEaM3 9GN14znS0B7AJ7QCtkMDYOP4gI3fXjX4BuynO44ODuIgrDiqaeQQCuzs/IGtayaEvtMo6PdRugEl c/A/DTBpnoBgLhLgi9oOCAKRue3fXQMrQSZDlr8R7aIm8n+IzCRjOpI24SDAxyNrVtQT87a66sbi KdyD4xo+RhAicI19JjLrvEJ5IKu4+y1tPgf87Dv+NO7v8MQik9cXjvTAicSg6QX9pHgquCPwPGDb QogJDXqJR2gCJQQOwOEiwCFcmOmgxxSGjfo2x/lGgW8XcQFEM0f69IW+WTLW6BnChSMZQ6fpguxO Z99yzAZG5g+a8gnk0nUzofC+a0nhNbdl8nG/dXv+uwE07ic4H6bpofcpAmEJ/F9D0B7XVi+ZfMLD P7p2GU8q3bIz4zBfBY7GxyBUUOi+6DPd1xeAI/6VgFHV9+ZDgQ7F+FHk6OOMnC1NAj1smCflCRff 49oJ9AYeqZ4gBKfxZ8EBU47ym2VPAYd8ytccXIOcWAnA0y4ApmCiQM9R/tGwhPpFNHVra2gH70Lo pFYB6Pj9PP50a29UirCeEsurR+ZLdKroWmAMT0Ok1mDOLOoAth4MQKHXapY0GixDcmhkKtA3incH Z4JR9mEzqgykFUhf1Vav5WWNTUJWO+xsJTqBRzOFi38FOE7j3vGP5i0GRHOvkcOrr/nTOB8hMwbd Xxf86HO3oGpQxR+s3/zc/NKuTPegqm1nxF2Bflw4GdRClIJqB75B0PMJIhCDzwH7cBQzQR8MDhFZ BkP/bEAH8DypvKNQzfnqA32rXH2MGF6jFUoH6MzS01s/l/SOJ20R2tzXKn+FVsS+qKBntH5AjqwH cRktb6POhP6eyZSwDvtVATuvQiw6siE7T8Y2ZlIh5kxv/s793y+EMw4bMKt6tUaqzhR3vebsy9IK PDJzkMNNoddrcsvPS1TqOdeN8m5EsLqUbyYkZre/Qo7kYR1fq6kDHfeQ+AYwop6+G6lKyusYwxHL HyqvgzdjG1ONobOuG8IRzwIH99zYHUOvzB6uE7qIDQIeqZYgAMfxSWA/LtgM0Idhtr2Nb/1aJMcQ ex7LrFR+hGY0faA/mdN6BtngD8KBw8wUzu2h0R9l6jFr/KN88M24wUtTGXdNJ9lY+5lSxftp+ZL3 U/I7MGUwpe/T05tvELaIBLkGnr2dktfxQVrBve9tFrpfdsn5d1vl454PLXy1qaJ9wmq0mhionihe nlIgXZiYmMNvV6fGVlWWP423gkwerbMNNPmg4zqycX1Vw3MvZhTJYfnulfU0U/Z+8Im6m7pMHgT8 sUj2FxmF0vva6cH6ZhbL4e+tlB1D35cy+GY9vtkg4LmERlBFqAcuuBhggws1PfTImSVEg4OBbYZH cEJ7gX/6wL/oa88XVysG0BSvbRSLSRX9EYFsbNqGNvUo3zinK06Ph4CRw6vQs3+g6/sb0rbolMbo +A2Kt2vtUKQSkJwrWYDX7d/xbChTRx6P4v5VG7RoBPeP4d2ZnJx136q+uaXnx5BPpMs3ic9sub5d XR+s77bRibbgzt9wHQQGj/KFhGoMUFuTO7Frpo3tkeR1J9awlV5bqgKcLFPpnVkJR6HntUGPpnTo JN4wFnpdEnS81LxdGoJYrP6OvveFphgV+RjaIjWoTpQ4/q3JyXlHfe/Lbhxqcoc2PP6B8qLyu8LP y3kXO7f6fnKu+KUt0xDSBKZdkZ1TzRGEvu2Abc832IlNwReZybRZd2I98g2257FFqbgBUNb25il9 G66Md/E8ckK1hR4P+579sq7lhee/KglnaCQsqOh51UnLiIqe4xZYDbKZMp6BM9a3YtNFS9rMHOQf ZDBlP7ao3BsVayxJ5N7xJRvfYDD04fhMs0JvQ6oyGHq0Od09/sKqamJe78xKjuBSApHK0xquRFM3 OYIHClh9r6nUM6SvAPRPUBMaPkZRJG1OOSWu/ubS0rLBuTQ5pV0lKGKzucxocDgaUAmS89rbLAr6 rjiFQHCk3SDgOesxeiIu0UzhyjVzycavyeAY/TPQiQ3Jeu73aGFE34ZbXlx+Oohe+5GDDkfNwasA i8/7RnHuBNF5107lii+W8YZOT08vHLE06OcWltyP03i3tYUZUSTnRGbLC0b6J48ei2DfwBPvd7p9 wjhAKBnLsBjoYUG/2RXTO11nhBNbTqgFTjgaOGQWJxZ2JEc6OBgkNsqJjcgdVhv6MplsRYVnKFdn TBrLQYH2MIFUCg5DUwgloh2ncVcTstp/3Ng2xjQkG9IU0EekCJ92CSwrJJAYmDyDys67+GlfVUYx 7oAY3hUcicnYuF5fuQSWFvrROH/E+9wf5SKHV6+qxmdxFgO9RqP5XluITFNjZ5hpUwed2FxCBQa8 rZlMG9uj6QaHKlFmJZ6mBCdZY9VGjGDfSiuQvuIWVAPs4ci+bZ7IeidAK52eITUgKln0rqBNlb/b 0OeUylleYfXYKI6AQqupulde0apyEXadoUIz3oOOLAI2mF77znb7kXcV+in5tK/Ip+OvbJzh9nwC vsC8TqxXEYT+vIHHfUiAc3QfqJNcpRo5dT+eXtg54BfdiIXQdpp0hq5Dq7ko8Su75PyrO432mAL6 jELpOEodMPXKp76rwvSMFpVFbSJR5lzKaXaXrCWNGQg9BZ8G9pkLepRzg1KMDXRiUWYlKal/ZXFp +ZApHMy2rleY1MSmRa9QDpZjjsJ8COztltWRaYTOdaGebPzh/Pz84+aGHsXjwxMb3sFyZvYIeNQm KCJUzOnnWRT0ipSB5xqdzxnoxDZiP93xcabNrNzsxOIj13LqDbTn9wV1g+DsoQVTHveBbHR+62h+ XGbb6xR63Z+8Q9lYhAK9HJy37hkATf1O0NRIY0intttKaCz0U1PzDn60mjvbLe+bUzgsusUFzV1q qsVAj0Doiut7h2vfZBD0KGpTSuACPC7SDJmVa6O8rXPC+oKUYYtSNmEKkFd/5UVz7RRbWtbYCGXq mOyzPSJaimieHM7G7FsHL92JWMSIesBpHOKYE/oq/hDdnVK5PgttaHehR7NgSDz/1vKyxtZioNcs aWxajkv/t8ah0WDozZdOvO7EumUZbNo87ScGPsnPg9GJhXBzQf/QzKmcIhZW9Y/4R/O+RMfvaYMW JUeFxTd8vLSk+a65oE8tkHSQowTAncIGHsFrcvFnYdsZ1zZtFGHOqyORsfYT3ZtcBG3wUhOKhVat f76Tdts16McbJ6gos5JtYGblXfMGF2eeGD2WTlxmkBP7bIAYEGKHAIP/+nO7Bfx9m3Fenw2LSBIt OsKXfxeqTc6tdxgH8FsvZZgL+uHRH+WIOl9ta2pXtTVAiaQvt1XVKf7ZyS0GHHCAg4lTJLB3iQc4 9zRA8M4Bzr5lgJrQcJVAYgZBBZtCroGsYM8QFt6ioB/MvcQTGJFZeS8FoRhLKTatXb+WWXnQtw4c CO7E8uG3Vsf66msHdF5lAP2rn4LGN94w5hgOYzU1s+ATEt/0F22pty7+lSA6VdC2uyuyK8+QAlL/ cujIKQh67npnLMKEwKJCx3ev2mrXoJeEn3+hwanVKOg3Es5O4WED4mjYiG8SOQSBgwQaIET1AUL0 AHaKwXayj7gAXOKUICxv9PelzZOle/UCN4uWIngRbcV7yN71KQZ55T0/2U3okcISG6cdodmBTJkH nWzPEDbgCIaSLBH62DSR8dCjCISY2r1kaGblg6kIaMRnEWpBFr4MpOFLQLqRSrUtAiVhglu1Xf8m 4cqmtlVTz39I8vnjXLZ4OgTW7SlLAB4JvqyL2qBHWwnpGc0vGQq9VzDrMwi93rNYXetIk0dwjdZ1 BrT+EJvW/KEh6RrGKilXN/ToiBVqAv+XRkM/N75wuNlfAqoNzKzUlZJQB+GvN4GEhHagjB94fS+B nZl7j4By1o25BzRhPtCWeegaWA2o8fwGnd+Vjkm8Qjg6oGcCr9DqFbF8XO8EutnFpX0BMbwb2pLO 0LOO+FfAGah3zNi2m5ya85ErJxg7vf50oUytC3q0bTEolocOt/quUdCPccZThO5i7BQDU0FvMsEy oV1cl0tVe3qycEahTBGT3vZf2cXy6pnZhaP6fr+U1892D6rUmmOOoil1zSOFur7LbhwqRTu2dC36 oOMuClh9Q4bUK6u0U+gWpH2DCgqpeodyQX6FQqUvZFinmlt0ZwsuD9JS2+6k5Il3/D+9mJV9l3Rt IkGzEjpYqq1LLTAK+p7kgRbMibVA6NGxIy0+UjAunIjbS+gjTwl+ZudVgp1wEBDDvZ2Yde5aGW+w fkQ9E7yysvK0jrWPp5QjM5QzpedVXiHad/2jYzLQsX/T0ws6j/lLyRf7o+/rSndwwLbQ1QLYMUfF 8glfjUZjs9N6obJHp4o+0rXZHVs99mNB57H5nWLO4MntZrv5xWXb5i51Xnph50RAbO0q2n9wFLYZ XziSstMyhcbz810DKnXmBqF1D0pcAyis6O0aUs94wTI9s97etlPTi25MtjI4n9XfyG994fmNhciH HiKNkl+tJ7RY3iiPhGsEomPiPy9OLO7fK+CXlzWHQuLqVtC2QPQi1o7sK8Hi3r5RPHAsvPoT+Pfr ELrrWcVd1zOLOq/HpIquU+i1H/tGcrHkK117PtHxIPGZrRNbPV89MWtPDmff2upoEAfvAiy3hRxe A/xotX+C17+x0/rJesdjYD1u69qAvnZ6GfQdoHNLSxYtx6aLRriiUUl2cVc2o0pRwhW9IPGP5kgj k5rmoLl0k0jl3k3LQEl5fjQOgHVw2nGCnURFJ1I5W+Y0ofuizuhH4wHfSPan8LPrQfTamxR6PXAL ZAGP0HoUgbqidaRHm6OFvu2/4+IEFgk9cq47qN2/Qicg7xX0kt7xUGIY+6GXsJZBycAyEtfOsCy6 KywNwYe55Zkw2J7R6HrAb1VteyrDiczWX+BgR9v+fBsImncJiE4VzupTR6FYJQqIbQK2HvlbJsyh DSaoc7lDk8gFQncU2v1oswga0dFAgFvPP9rsEEclCX6rzyb8paWl7wVEcz7V5mtoa0O0T9j52L1O trZZpQLks3prtEI/MzR7vIUs/dLQRSlzq8HpHLiQNvDSXpo2sPGqPHRETwxflmdgoOSc7e7eIZSp PmFcsJP8GWSC5ZTJ2/Stp0xxReEX3bDtkSMbHV7b79oyK6OSBXpvSMkp6+K7UzgGnbSGnZgQwQVC mSpcK/SXmKMFLZ4yzHa2OHsezwciNwkYKVVV7iX09PTm19C5lSYDHppJHsEcUM4b+BnauLPTchRU 9KhRHv9W4GMrvKE1gCccPmVIXXnCSzkh8Q2fI7PL2JPHsONJYHlzS+V1+pYDtsv3Mwo73yGQyvQ+ LxTNNgExtX9eXFw6oBX63uSBAUMzK3cjctPk1X5bxZ/w2UvoUwskr/hG1WMhvI1j7PQd9e+e6ks6 i2UblnCUF/QNgaIISklN/1vecMRHOTt4HcdsUOh1X8zMLboaWl/V+KxbSr70KnKe147lLtD7VGbU Ti4ofTqx8VOeYMTNoFXs2XmbtILOn6OjwPU5TBY9+8Tp5sXNB8dubsRvtlKkP6nDiywTeodG0Ozf cWNleWVPF5jQphGxfDwIjjydkUmCX/tGcbFtgGihCW0LRI1s51mwZs8SmWvn0iP7EpkJKNEMXoNM DmJY9d+yS+XXlMNTscaUh982WhZ3uu13aETHDnsll2L+A5pB7KE/ERrPf1efGUTn4pXwUgT0JSaR c+gezMbqgXwVVNe1o7vX6rp27HgRdk4Oiq+jow3DEhs/yC2TC6emFg8Y2faPneUMtIScaLhxr81L HmpvrO5QaEfYYT82SM4TP681ZLm8tHyoLUh2s8beAoFH2w/xzUAa3TO7l8BreQmPKoYmfVj8wfK8 8p6XaSmiawExvN9GnGpa9aNxVr0orFVPqOPwd2piwyo5vPoX6YWyH2UWd7Fb5eMuJizHDwRt6pN5 ZX2XoDlyLSCa+yklrn6VHFm7mpjdatLEusmpBZ8y3mBNaoH0jdCEhuuorqTw6lWPINaqd0jFKnz+ ql9UzYfx2e3XGFUKOV84Gm7qM4CWljQHitmDmdkl59Wh8Q3zEacasfZGbe0dUrkaRK9dDY2vv+kV XDGbUdg1w2QriFqhnxRfjTl3rNPgMyvNrUanNqA883yvJUGvA8AnNSvAfkQ9a8/iKTGh3zUajf0u luGp+flle6FYba9Wzz5lxud8YwXWVSxX2zNZcnueUGm/uKSx3+1kPlQGFMplwrbmCUfsZ2cXURkO brs41ZXUT0crsWwLXJSqtqsHbb5dYEI4GWjp0Ftl+brnKChmAlrIUpPm3JgEeFw9aHJqB8/lXr66 +YRcq6wyGnrkJPScuvgrvkOLRYQs2Qh42AEFzmIwePryu5odbC2zyiq9oF+z66cdZeG9751z7wS1 OBGoxe+R4LOFLh3gnG8nGMi4PLSysrLf+rKsMgv0WBRnefnpEYa6+mLa0L930xU/7Yrp21WhZ55P 6P+xMn24eW5kLsD6kqwyO/RWWfV11/8DWg8dgPgaldcAAAAASUVORK5CYII= --_005_db205bcad6ac495bb558e2b6181ba546STEMES002steteucorp_-- From nobody Fri Sep 13 06:18:30 2019 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 2A347120801 for ; Fri, 13 Sep 2019 06:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=curity-io.20150623.gappssmtp.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 CJuDgye03iLu for ; Fri, 13 Sep 2019 06:18:26 -0700 (PDT) Received: from mail-yw1-xc43.google.com (mail-yw1-xc43.google.com [IPv6:2607:f8b0:4864:20::c43]) (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 1C336120052 for ; Fri, 13 Sep 2019 06:18:26 -0700 (PDT) Received: by mail-yw1-xc43.google.com with SMTP id u187so10393995ywa.11 for ; Fri, 13 Sep 2019 06:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OLgau+GUafaWNhx0lrJNSXNzg0R5paIrutm1moa4OEk=; b=bljf6d9YnMWeOXFWeqqbqUawkzg+3e/DdN3Ye46vRbBac2Ph9CP9nWLtJNdt5i0BXs 8lkVnJgKGmEjLgcqBkc3fdFq5M4u7R8pAeCo+y2h0V7g3zhkskdLRTPP5v8gu5oqKj6N DUjrwCY4X4+ZE+dLl8kLVy2of3nFQWNpLHnn/JytJ/MR4010BoA1qLzBQrRvZsNMj80u uK4d7sQ3BvimLlvDX1BKjnlQAXgnKmMH6jod5wZzlme9YnJN41IgjSZXwydRc67ORvWV UVrAQ2Qj9wrQSFpYgGubcN30O+d/Snv0dqisNYl8mot4nKXKVWbWXtZDJrrK+SY9zIx5 bMzQ== 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=OLgau+GUafaWNhx0lrJNSXNzg0R5paIrutm1moa4OEk=; b=lW8t72fG8cueVYD8QiLnA/zMg0VmTTR2nR006Q7U6l02szb8vRZtoOnE10DP6L6mu0 Kgo6oBeChfDOKzsw3ijY3oxr5xHepuTxmlc8cng4tQdXfmB4qeXDWYTdpQIbgL+4dyTc VuVlNNymVkGTwuoLi2roF8oXEawhRY3V5YSJAuVOZYlZFDo2AXLLhPQOgr0EN2dbeONH fjG4RC5yyUEpMqlmCc5DVzyW+V4MFFJuciFDLZpJptPbKl6vABfl1H6GIWtV5HQFGIR4 eWYjjXv31dx1vQs6jBgggoSWOC1NRdtiBoUhlzdin4FR1puUmwO5NOmpya6+M+tD5kNW hMkA== X-Gm-Message-State: APjAAAUJwQdxNILPlVu/BXumAgOrQCDFJUWt7xG321TzPxAyIvjmrb1g nd+Hbfpc9Xo4pzxi2WmBGyo9R91lythw9rbrLEzm3w== X-Google-Smtp-Source: APXvYqyPnTSe7GCies/jBQW9+UqpErv1QuKmbUVqCwZxLCiC3XNicSdI3op3YAPTxvaIaalofLgqyDBZFY+yZ3lNUhw= X-Received: by 2002:a81:7811:: with SMTP id t17mr33629641ywc.273.1568380704269; Fri, 13 Sep 2019 06:18:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Travis Spencer Date: Fri, 13 Sep 2019 15:18:12 +0200 Message-ID: To: =?UTF-8?Q?Robache_Herv=C3=A9?= Cc: "oauth@ietf.org" Content-Type: multipart/related; boundary="000000000000c0734205926f166b" Archived-At: Subject: Re: [OAUTH-WG] Question regarding RFC 7592 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: Fri, 13 Sep 2019 13:18:29 -0000 --000000000000c0734205926f166b Content-Type: multipart/alternative; boundary="000000000000c0733f05926f166a" --000000000000c0733f05926f166a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ya, this part is confusing. I didn't get it at first either. The response to registration using RFC 7591 (authenticated with an initial token or not) typically includes a registration access token; this metadata isn't defined in RFC 7591 but discussed in section 1.3; that spec leaves the metadata out of scope. It is, however, profiled in section 3.2 of OIDC DCR (see registration_access_token in section 3.2 available at https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationR= esponse). With this, the client can update its registration according to RFC 7592 (DCRM). When it does so, the AS will typically return a new registration token with each reply. This update process is described in section 5 of DCRM. On Fri, Sep 13, 2019 at 2:23 PM Robache Herv=C3=A9 = wrote: > Thanks Travis > > > > I understand that, once the client has retrieved its [client_id] through > RFC7591 initial registration, it is then able to ask for an access token > that will be used for accessing the RFC7592 entry-points. Am I right? > > > > Best regards > > > > Herv=C3=A9 > > > > *De :* Travis Spencer [mailto:travis.spencer@curity.io] > *Envoy=C3=A9 :* ven. 13 13:30 > *=C3=80 :* Robache Herv=C3=A9 > *Cc :* oauth@ietf.org > *Objet :* Re: [OAUTH-WG] Question regarding RFC 7592 > > > > No. The initial access token is issued by the AS when registration is > protected (appendix 1.2 in RFC 7591). As stated in section 1.2, the metho= d > and means by which this is obtained can vary. The registration access tok= en > in RFC 7592 is used to protect the registration management API and allow > updates to the client after it is registered. You might have one (the > registration access token) but not the other (initial access token) when > open registration is allowed (appendix 1.1 in RFC 7591). > > > > HTH! > > > > On Fri, Sep 13, 2019 at 7:37 AM Robache Herv=C3=A9 > wrote: > > Hi > > > > RFC 7592 introduces a =C2=AB Registration Access Token =C2=BB. Are this t= oken and > the way to get it similar to what is specified as =E2=80=9CInitial Access= Token=E2=80=9D in > RFC 7591/Appendix A ? > > > > If so, can the Open Dynamic Client Registration (RFC7591/A.1.1) be > extrapolated to RFC7592 as the same way? > > > > Thanks in advance for your clarification. > > > > Herv=C3=A9 ROBACHE > > Direction Marketing et D=C3=A9veloppement > > > > LIGNE DIRECTE > > T. +33(0)1 55 23 55 45 > > herve.robache@stet.eu > > > > > > > > > [image: cid:image003.png@01D14327.707582F0] > > > > STET (SIEGE SOCIAL) > > 100, Esplanade du G=C3=A9n=C3=A9ral de Gaulle > > C=C5=93ur D=C3=A9fense =E2=80=93 Tour B > > 92932 La D=C3=A9fense cedex > > > > www.stet.eu > > > > > > Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'i= ntention > exclusive de ses destinataires et sont confidentiels. > Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, > merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me et = d'en avertir > imm=C3=A9diatement l'exp=C3=A9diteur. > Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'e= st pas > conforme =C3=A0 sa destination, toute diffusion ou toute publication, tot= ale ou > partielle, est interdite. > L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de ce messag= e > =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3=A9cline toute = responsabilit=C3=A9 au > titre de ce message dans l'hypoth=C3=A8se o=C3=B9 il aurait =C3=A9t=C3=A9= modifi=C3=A9, d=C3=A9form=C3=A9 ou > falsifi=C3=A9. > N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'environneme= nt. > > This message and any attachments is intended solely for the intended > addressees and is confidential. > If you receive this message in error, or are not the intended > recipient(s), please delete it and any copies from your systems and > immediately notify the sender. > Any unauthorized view, use that does not comply with its purpose, > dissemination or disclosure, either whole or partial, is prohibited. > Since the internet cannot guarantee the integrity of this message which > may not be reliable, STET shall not be liable for the message if modified= , > changed or falsified. > Do not print this message unless it is necessary, please consider the > environment. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'i= ntention > exclusive de ses destinataires et sont confidentiels. > Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, > merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me et = d'en avertir > imm=C3=A9diatement l'exp=C3=A9diteur. > Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'e= st pas > conforme =C3=A0 sa destination, toute diffusion ou toute publication, tot= ale ou > partielle, est interdite. > L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de ce messag= e > =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3=A9cline toute = responsabilit=C3=A9 au > titre de ce message dans l'hypoth=C3=A8se o=C3=B9 il aurait =C3=A9t=C3=A9= modifi=C3=A9, d=C3=A9form=C3=A9 ou > falsifi=C3=A9. > N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'environneme= nt. > > This message and any attachments is intended solely for the intended > addressees and is confidential. > If you receive this message in error, or are not the intended > recipient(s), please delete it and any copies from your systems and > immediately notify the sender. > Any unauthorized view, use that does not comply with its purpose, > dissemination or disclosure, either whole or partial, is prohibited. > Since the internet cannot guarantee the integrity of this message which > may not be reliable, STET shall not be liable for the message if modified= , > changed or falsified. > Do not print this message unless it is necessary, please consider the > environment. > --000000000000c0733f05926f166a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ya, this part is confusing. I didn't get it at fi= rst either.

The response to registration using RFC= 7591 (authenticated with an initial token or not) typically includes a reg= istration access token; this metadata isn't defined in RFC 7591 but dis= cussed in section 1.3; that spec leaves the metadata out of scope. It is, h= owever, profiled in section 3.2 of OIDC DCR (see registration_access_token = in section 3.2 available at https://openid.net/specs/op= enid-connect-registration-1_0.html#RegistrationResponse). With this, th= e client can update its registration according to RFC 7592 (DCRM). When it = does so, the AS will typically return a new registration token with each re= ply. This update process is described in section 5 of DCRM.
=
On Fri= , Sep 13, 2019 at 2:23 PM Robache Herv=C3=A9 <herve.robache@stet.eu> wrote:

Thank= s Travis

=C2=A0

I und= erstand that, once the client has retrieved its [client_id] through RFC7591= initial registration, it is then able to ask for an access token that will be used for accessing the RFC7592 entry-points. Am I right?

=C2=A0

Best = regards

=C2=A0

Herv= =C3=A9

=C2=A0

De=C2=A0: Travis S= pencer [mailto:travis.spencer@curity.io]
Envoy=C3=A9=C2=A0: ven. 13 13:30
=C3=80=C2=A0: Robache Herv=C3=A9
Cc=C2=A0: oauth@= ietf.org
Objet=C2=A0: Re: [OAUTH-WG] Question regarding RFC 7592

=C2=A0

No. The initial access token is issued by the AS whe= n registration is protected (appendix 1.2 in RFC 7591). As stated in sectio= n 1.2, the method and means by which this is obtained can vary. The registr= ation access token in RFC 7592 is used to protect the registration management API and allow updates to the c= lient after it is registered. You might have one (the registration access t= oken) but not the other (initial access token) when open registration is al= lowed (appendix 1.1 in RFC 7591).

=C2=A0

HTH!

=C2=A0

On Fri, Sep 13, 2019 at 7:37 AM Robache Herv=C3=A9 &= lt;herve.robache= @stet.eu> wrote:

Hi

=C2=A0

RFC 7592 introduces a =C2=AB=C2= =A0Registration Access Token=C2=A0=C2=BB. Are this token and the way to get= it similar to what is specified as =E2=80=9CInitial Access Token=E2=80=9D = in RFC 7591/Appendix A ?

=C2=A0

If so, can the Open Dynamic Cli= ent Registration (RFC7591/A.1.1) be extrapolated to RFC7592 as the same way= ?

=C2=A0

Thanks in advance for your clar= ification.

=C2=A0

Herv=C3=A9 ROBACHE=

Direction Marketing et D=C3= =A9veloppement

=C2=A0<= /p>

LIGNE DIRECTE

T. +33(0)1 55 23 55 45<= /p>

herve.robache@stet.eu

=C2=A0

=C2=A0

=C2=A0


3D"cid:image003.png@01D14327.707582F0"

=C2=A0

STET (SIEGE SOCIAL)

100, Esplanade du G=C3=A9n=C3=A9ral de Gaull= e

C=C5=93ur D=C3=A9fense =E2=80=93 Tour B

92932 La D=C3=A9fense cedex=

=C2=A0

www.stet.eu

=C2=A0



Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'= ;intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me = et d'en avertir imm=C3=A9diatement l'exp=C3=A9diteur.
Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'= ;est pas conforme =C3=A0 sa destination, toute diffusion ou toute publicati= on, totale ou partielle, est interdite.
L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de= ce message =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3= =A9cline toute responsabilit=C3=A9 au titre de ce message dans l'hypoth= =C3=A8se o=C3=B9 il aurait =C3=A9t=C3=A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou= falsifi=C3=A9.
N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'envir= onnement.

This message and any attachments is intended solely for the intended addres= sees and is confidential.
If you receive this message in error, or are not the intended recipient(s),= please delete it and any copies from your systems and immediately notify t= he sender.
Any unauthorized view, use that does not comply with its purpose, dissemina= tion or disclosure, either whole or partial, is prohibited.
Since the internet cannot guarantee the integrity of this message which may= not be reliable, STET shall not be liable for the message if modified, cha= nged or falsified.
Do not print this message unless it is necessary, please consider the envir= onment.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'= ;intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me = et d'en avertir imm=C3=A9diatement l'exp=C3=A9diteur.
Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'= ;est pas conforme =C3=A0 sa destination, toute diffusion ou toute publicati= on, totale ou partielle, est interdite.
L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de= ce message =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3= =A9cline toute responsabilit=C3=A9 au titre de ce message dans l'hypoth= =C3=A8se o=C3=B9 il aurait =C3=A9t=C3=A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou= falsifi=C3=A9.
N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'envir= onnement.

This message and any attachments is intended solely for the intended addres= sees and is confidential.
If you receive this message in error, or are not the intended recipient(s),= please delete it and any copies from your systems and immediately notify t= he sender.
Any unauthorized view, use that does not comply with its purpose, dissemina= tion or disclosure, either whole or partial, is prohibited.
Since the internet cannot guarantee the integrity of this message which may= not be reliable, STET shall not be liable for the message if modified, cha= nged or falsified.
Do not print this message unless it is necessary, please consider the envir= onment.
--000000000000c0733f05926f166a-- --000000000000c0734205926f166b Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: <16d2abbe3b44cff311> X-Attachment-Id: 16d2abbe3b44cff311 iVBORw0KGgoAAAANSUhEUgAAASoAAAABCAYAAABpJuNuAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAbSURBVDhPYygwWLAfiP+P4lE8ikfx4MQL9gMA lmac9TWs31MAAAAASUVORK5CYII= --000000000000c0734205926f166b Content-Type: image/png; name="image002.png" Content-Disposition: inline; filename="image002.png" Content-Transfer-Encoding: base64 Content-ID: <16d2abbe3b45b16b22> X-Attachment-Id: 16d2abbe3b45b16b22 iVBORw0KGgoAAAANSUhEUgAAAL0AAAA7CAYAAAAuPov1AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABkOSURBVHja 7Z15WJvHncfTNpttkl6bwwfmkATYmBtJxlziEIcAYcDmNmAuIQ6DOIQkQIAkwCAkARYgY0EINiEK 0SY4CZuwLtuFrmnLs6V9gvuQJmlIt9uGHFtrW3sbQmtnduYFbGxLgC5QUv3xfeARr953Zt7PzPx+ v/nN8IhIJHrEKqv+nmRtBKus0FtllRV6M+uzz245MYSTzKiCy2OkJOUV4qkLV0hJuyfvxAtXQnNG ruQ1vCUbn1ogW6GwQm9WccRXyyhZwzedYgfBwdBeYBO2N0LPtou4CIjJQ1+IB2dqrWBYoTeLChpe E7smDoOn/KRgf2AHOEiR7KkOBHWAf4JlCci8DFST1hHfCr2J1SifPu1xchg87b/3sD8ou4h+kFf3 aq8VDiv0JhMA4NHgrOc+fCawy+KARzoUfgH4nOq/YIXDCr3JpBiZDT4SewHsC7Q84LGRHkKfxBpT WuoLk8snHyNEML9DIOhQBO/JRx4B3/i6AMpkir+9VX0jIsRPWDz0+fzxaseYAcyGtjTg98MyOcYo QVnzm0xLhUAoUdV6BrM/IfgUfuJIYt4ngk/RJ8Swql8rlVPf+7pAn5LXoTx8nPVQXZHwPsWfxKQJ pi0eenrRC6MoWmKJo/z+ICk4HNv3uVAxe8Rioe94SewVWgscycXA6VjJfXIklwKfsMpbEPrvf42g f/WIf9VDdUUikM+CmFThuxYNPbTnH/NNufjL/cHdFgn9s4EyQEru/wMs57ctF3pVq2dwDSAQCwEc 7e4TgVgEiGGVf/yaQT8GR/qH6oqEJxZD6AXXLRp69ezSPs/4vs/3BUotEvqDIb0gJGvoLQi9xdrE Vui/YtAzBBNUp5j+2weCLNOJtQ1XgKSKsXZLhsAK/VcM+ty68XP2kf3ggCXa84EdwOXEAOBJplKt 0FuhN5U9/43wvOE3LNWJfTZQAjwTFH8bn1p0tkJvhd50Tmzqxf9GzqJFRm6gc01M6r8Oy/kPpqz3 /PySk1I17ZZRKnMTilVuswvvucFnPGGF/u8AevHQjPNRuuIvKCxoidAfCOkBNMbll42t58rKyrO8 5tHyuNNtL/nReG8HRHP/6kfjAg8KC5Co1SAkng9IYdUf0tOb3z5d1N0nkKjTl5Y+O7zT+5/rflm4 NfRV/2PO6BMaFIRitReTrWScPNMhCY3nj+aV972dVdT5SzKV3ZNZ1CUp5Q0nTE0tOpjieekF0he3 gj42XbhgsdBz+n96+nDcMNhP6QIHQ4xR99rPYNPNGGihjBCtBNkcNdcIGH7AYPUKqYlNN9wp1cDp WBkgkEqAgzcDE57IBDifQmDvWQA/L4a/F4MjfhXAK6QGhJzgf5GcK5mpax5lq8dn7nYAjUbzeESc cD/BlbmfQFpTJX+w24PC1gm9d0iFJi5D6LxxvW6x9jN5ymf0mLEOMCsVQnrGuQ88gyuAa2AVOBpQ BRzJZ4G9FxPWsQg4QzjRZx6w/r6RnP+jp7X+q1A8dga2zbd28oypqaUnSRGC++obn9n62uHj5Tqh jzzV+M5O6nr4sPwxo6CfUcweHRdMnL3EHK0Y3oHUZa9UMPIu/OTA8XpgQ+YAm2NGiFwDf3LBwYBm k8GPnFiUGiFQTIcb0h6q8WmXtELZ+y4BlRCAQq1A6hIedQQv1ClKgGtQDcgs7rq72MITDKcTqbxb 8Jpb8FpMzseKVh1JRVvd80snEvP/Nq7XpSN+rFspOW28HXTmb1c3DTcHxNR+ikB38EZlZm5ZR/Q3 1MHR4pFXaA2ISWtZUAxNZm73rAyGrAk+45Yjkbm5vn/bqv2cyEV3tqurs+/ZW4d9GBEGQT+rmgvq jFJcaSZ13G71koEWD+mO1OHZDcIcM8Gz9v7AziHENMKHg0PuuRDaDqPBfyZAAnxTlZ8vLWvs9AV+ YnLONTJZ9AccsRQDeKewa32Bx8pBUm772Ma9k/PE0iN+lfDFFt8VYSf32XS9NqEZwYfKBWW8wfgt 11UmZlwzCrsX3Ck1GOz6dOZ7nZqBzWq+UbWghHOxZyufKS69ZdqRXHZfWbe7P2EH9UUzBcGHEaM3 9GN14znS0B7AJ7QCtkMDYOP4gI3fXjX4BuynO44ODuIgrDiqaeQQCuzs/IGtayaEvtMo6PdRugEl c/A/DTBpnoBgLhLgi9oOCAKRue3fXQMrQSZDlr8R7aIm8n+IzCRjOpI24SDAxyNrVtQT87a66sbi KdyD4xo+RhAicI19JjLrvEJ5IKu4+y1tPgf87Dv+NO7v8MQik9cXjvTAicSg6QX9pHgquCPwPGDb QogJDXqJR2gCJQQOwOEiwCFcmOmgxxSGjfo2x/lGgW8XcQFEM0f69IW+WTLW6BnChSMZQ6fpguxO Z99yzAZG5g+a8gnk0nUzofC+a0nhNbdl8nG/dXv+uwE07ic4H6bpofcpAmEJ/F9D0B7XVi+ZfMLD P7p2GU8q3bIz4zBfBY7GxyBUUOi+6DPd1xeAI/6VgFHV9+ZDgQ7F+FHk6OOMnC1NAj1smCflCRff 49oJ9AYeqZ4gBKfxZ8EBU47ym2VPAYd8ytccXIOcWAnA0y4ApmCiQM9R/tGwhPpFNHVra2gH70Lo pFYB6Pj9PP50a29UirCeEsurR+ZLdKroWmAMT0Ok1mDOLOoAth4MQKHXapY0GixDcmhkKtA3incH Z4JR9mEzqgykFUhf1Vav5WWNTUJWO+xsJTqBRzOFi38FOE7j3vGP5i0GRHOvkcOrr/nTOB8hMwbd Xxf86HO3oGpQxR+s3/zc/NKuTPegqm1nxF2Bflw4GdRClIJqB75B0PMJIhCDzwH7cBQzQR8MDhFZ BkP/bEAH8DypvKNQzfnqA32rXH2MGF6jFUoH6MzS01s/l/SOJ20R2tzXKn+FVsS+qKBntH5AjqwH cRktb6POhP6eyZSwDvtVATuvQiw6siE7T8Y2ZlIh5kxv/s793y+EMw4bMKt6tUaqzhR3vebsy9IK PDJzkMNNoddrcsvPS1TqOdeN8m5EsLqUbyYkZre/Qo7kYR1fq6kDHfeQ+AYwop6+G6lKyusYwxHL HyqvgzdjG1ONobOuG8IRzwIH99zYHUOvzB6uE7qIDQIeqZYgAMfxSWA/LtgM0Idhtr2Nb/1aJMcQ ex7LrFR+hGY0faA/mdN6BtngD8KBw8wUzu2h0R9l6jFr/KN88M24wUtTGXdNJ9lY+5lSxftp+ZL3 U/I7MGUwpe/T05tvELaIBLkGnr2dktfxQVrBve9tFrpfdsn5d1vl454PLXy1qaJ9wmq0mhionihe nlIgXZiYmMNvV6fGVlWWP423gkwerbMNNPmg4zqycX1Vw3MvZhTJYfnulfU0U/Z+8Im6m7pMHgT8 sUj2FxmF0vva6cH6ZhbL4e+tlB1D35cy+GY9vtkg4LmERlBFqAcuuBhggws1PfTImSVEg4OBbYZH cEJ7gX/6wL/oa88XVysG0BSvbRSLSRX9EYFsbNqGNvUo3zinK06Ph4CRw6vQs3+g6/sb0rbolMbo +A2Kt2vtUKQSkJwrWYDX7d/xbChTRx6P4v5VG7RoBPeP4d2ZnJx136q+uaXnx5BPpMs3ic9sub5d XR+s77bRibbgzt9wHQQGj/KFhGoMUFuTO7Frpo3tkeR1J9awlV5bqgKcLFPpnVkJR6HntUGPpnTo JN4wFnpdEnS81LxdGoJYrP6OvveFphgV+RjaIjWoTpQ4/q3JyXlHfe/Lbhxqcoc2PP6B8qLyu8LP y3kXO7f6fnKu+KUt0xDSBKZdkZ1TzRGEvu2Abc832IlNwReZybRZd2I98g2257FFqbgBUNb25il9 G66Md/E8ckK1hR4P+579sq7lhee/KglnaCQsqOh51UnLiIqe4xZYDbKZMp6BM9a3YtNFS9rMHOQf ZDBlP7ao3BsVayxJ5N7xJRvfYDD04fhMs0JvQ6oyGHq0Od09/sKqamJe78xKjuBSApHK0xquRFM3 OYIHClh9r6nUM6SvAPRPUBMaPkZRJG1OOSWu/ubS0rLBuTQ5pV0lKGKzucxocDgaUAmS89rbLAr6 rjiFQHCk3SDgOesxeiIu0UzhyjVzycavyeAY/TPQiQ3Jeu73aGFE34ZbXlx+Oohe+5GDDkfNwasA i8/7RnHuBNF5107lii+W8YZOT08vHLE06OcWltyP03i3tYUZUSTnRGbLC0b6J48ei2DfwBPvd7p9 wjhAKBnLsBjoYUG/2RXTO11nhBNbTqgFTjgaOGQWJxZ2JEc6OBgkNsqJjcgdVhv6MplsRYVnKFdn TBrLQYH2MIFUCg5DUwgloh2ncVcTstp/3Ng2xjQkG9IU0EekCJ92CSwrJJAYmDyDys67+GlfVUYx 7oAY3hUcicnYuF5fuQSWFvrROH/E+9wf5SKHV6+qxmdxFgO9RqP5XluITFNjZ5hpUwed2FxCBQa8 rZlMG9uj6QaHKlFmJZ6mBCdZY9VGjGDfSiuQvuIWVAPs4ci+bZ7IeidAK52eITUgKln0rqBNlb/b 0OeUylleYfXYKI6AQqupulde0apyEXadoUIz3oOOLAI2mF77znb7kXcV+in5tK/Ip+OvbJzh9nwC vsC8TqxXEYT+vIHHfUiAc3QfqJNcpRo5dT+eXtg54BfdiIXQdpp0hq5Dq7ko8Su75PyrO432mAL6 jELpOEodMPXKp76rwvSMFpVFbSJR5lzKaXaXrCWNGQg9BZ8G9pkLepRzg1KMDXRiUWYlKal/ZXFp +ZApHMy2rleY1MSmRa9QDpZjjsJ8COztltWRaYTOdaGebPzh/Pz84+aGHsXjwxMb3sFyZvYIeNQm KCJUzOnnWRT0ipSB5xqdzxnoxDZiP93xcabNrNzsxOIj13LqDbTn9wV1g+DsoQVTHveBbHR+62h+ XGbb6xR63Z+8Q9lYhAK9HJy37hkATf1O0NRIY0intttKaCz0U1PzDn60mjvbLe+bUzgsusUFzV1q qsVAj0Doiut7h2vfZBD0KGpTSuACPC7SDJmVa6O8rXPC+oKUYYtSNmEKkFd/5UVz7RRbWtbYCGXq mOyzPSJaimieHM7G7FsHL92JWMSIesBpHOKYE/oq/hDdnVK5PgttaHehR7NgSDz/1vKyxtZioNcs aWxajkv/t8ah0WDozZdOvO7EumUZbNo87ScGPsnPg9GJhXBzQf/QzKmcIhZW9Y/4R/O+RMfvaYMW JUeFxTd8vLSk+a65oE8tkHSQowTAncIGHsFrcvFnYdsZ1zZtFGHOqyORsfYT3ZtcBG3wUhOKhVat f76Tdts16McbJ6gos5JtYGblXfMGF2eeGD2WTlxmkBP7bIAYEGKHAIP/+nO7Bfx9m3Fenw2LSBIt OsKXfxeqTc6tdxgH8FsvZZgL+uHRH+WIOl9ta2pXtTVAiaQvt1XVKf7ZyS0GHHCAg4lTJLB3iQc4 9zRA8M4Bzr5lgJrQcJVAYgZBBZtCroGsYM8QFt6ioB/MvcQTGJFZeS8FoRhLKTatXb+WWXnQtw4c CO7E8uG3Vsf66msHdF5lAP2rn4LGN94w5hgOYzU1s+ATEt/0F22pty7+lSA6VdC2uyuyK8+QAlL/ cujIKQh67npnLMKEwKJCx3ev2mrXoJeEn3+hwanVKOg3Es5O4WED4mjYiG8SOQSBgwQaIET1AUL0 AHaKwXayj7gAXOKUICxv9PelzZOle/UCN4uWIngRbcV7yN71KQZ55T0/2U3okcISG6cdodmBTJkH nWzPEDbgCIaSLBH62DSR8dCjCISY2r1kaGblg6kIaMRnEWpBFr4MpOFLQLqRSrUtAiVhglu1Xf8m 4cqmtlVTz39I8vnjXLZ4OgTW7SlLAB4JvqyL2qBHWwnpGc0vGQq9VzDrMwi93rNYXetIk0dwjdZ1 BrT+EJvW/KEh6RrGKilXN/ToiBVqAv+XRkM/N75wuNlfAqoNzKzUlZJQB+GvN4GEhHagjB94fS+B nZl7j4By1o25BzRhPtCWeegaWA2o8fwGnd+Vjkm8Qjg6oGcCr9DqFbF8XO8EutnFpX0BMbwb2pLO 0LOO+FfAGah3zNi2m5ya85ErJxg7vf50oUytC3q0bTEolocOt/quUdCPccZThO5i7BQDU0FvMsEy oV1cl0tVe3qycEahTBGT3vZf2cXy6pnZhaP6fr+U1892D6rUmmOOoil1zSOFur7LbhwqRTu2dC36 oOMuClh9Q4bUK6u0U+gWpH2DCgqpeodyQX6FQqUvZFinmlt0ZwsuD9JS2+6k5Il3/D+9mJV9l3Rt IkGzEjpYqq1LLTAK+p7kgRbMibVA6NGxIy0+UjAunIjbS+gjTwl+ZudVgp1wEBDDvZ2Yde5aGW+w fkQ9E7yysvK0jrWPp5QjM5QzpedVXiHad/2jYzLQsX/T0ws6j/lLyRf7o+/rSndwwLbQ1QLYMUfF 8glfjUZjs9N6obJHp4o+0rXZHVs99mNB57H5nWLO4MntZrv5xWXb5i51Xnph50RAbO0q2n9wFLYZ XziSstMyhcbz810DKnXmBqF1D0pcAyis6O0aUs94wTI9s97etlPTi25MtjI4n9XfyG994fmNhciH HiKNkl+tJ7RY3iiPhGsEomPiPy9OLO7fK+CXlzWHQuLqVtC2QPQi1o7sK8Hi3r5RPHAsvPoT+Pfr ELrrWcVd1zOLOq/HpIquU+i1H/tGcrHkK117PtHxIPGZrRNbPV89MWtPDmff2upoEAfvAiy3hRxe A/xotX+C17+x0/rJesdjYD1u69qAvnZ6GfQdoHNLSxYtx6aLRriiUUl2cVc2o0pRwhW9IPGP5kgj k5rmoLl0k0jl3k3LQEl5fjQOgHVw2nGCnURFJ1I5W+Y0ofuizuhH4wHfSPan8LPrQfTamxR6PXAL ZAGP0HoUgbqidaRHm6OFvu2/4+IEFgk9cq47qN2/Qicg7xX0kt7xUGIY+6GXsJZBycAyEtfOsCy6 KywNwYe55Zkw2J7R6HrAb1VteyrDiczWX+BgR9v+fBsImncJiE4VzupTR6FYJQqIbQK2HvlbJsyh DSaoc7lDk8gFQncU2v1oswga0dFAgFvPP9rsEEclCX6rzyb8paWl7wVEcz7V5mtoa0O0T9j52L1O trZZpQLks3prtEI/MzR7vIUs/dLQRSlzq8HpHLiQNvDSXpo2sPGqPHRETwxflmdgoOSc7e7eIZSp PmFcsJP8GWSC5ZTJ2/Stp0xxReEX3bDtkSMbHV7b79oyK6OSBXpvSMkp6+K7UzgGnbSGnZgQwQVC mSpcK/SXmKMFLZ4yzHa2OHsezwciNwkYKVVV7iX09PTm19C5lSYDHppJHsEcUM4b+BnauLPTchRU 9KhRHv9W4GMrvKE1gCccPmVIXXnCSzkh8Q2fI7PL2JPHsONJYHlzS+V1+pYDtsv3Mwo73yGQyvQ+ LxTNNgExtX9eXFw6oBX63uSBAUMzK3cjctPk1X5bxZ/w2UvoUwskr/hG1WMhvI1j7PQd9e+e6ks6 i2UblnCUF/QNgaIISklN/1vecMRHOTt4HcdsUOh1X8zMLboaWl/V+KxbSr70KnKe147lLtD7VGbU Ti4ofTqx8VOeYMTNoFXs2XmbtILOn6OjwPU5TBY9+8Tp5sXNB8dubsRvtlKkP6nDiywTeodG0Ozf cWNleWVPF5jQphGxfDwIjjydkUmCX/tGcbFtgGihCW0LRI1s51mwZs8SmWvn0iP7EpkJKNEMXoNM DmJY9d+yS+XXlMNTscaUh982WhZ3uu13aETHDnsll2L+A5pB7KE/ERrPf1efGUTn4pXwUgT0JSaR c+gezMbqgXwVVNe1o7vX6rp27HgRdk4Oiq+jow3DEhs/yC2TC6emFg8Y2faPneUMtIScaLhxr81L HmpvrO5QaEfYYT82SM4TP681ZLm8tHyoLUh2s8beAoFH2w/xzUAa3TO7l8BreQmPKoYmfVj8wfK8 8p6XaSmiawExvN9GnGpa9aNxVr0orFVPqOPwd2piwyo5vPoX6YWyH2UWd7Fb5eMuJizHDwRt6pN5 ZX2XoDlyLSCa+yklrn6VHFm7mpjdatLEusmpBZ8y3mBNaoH0jdCEhuuorqTw6lWPINaqd0jFKnz+ ql9UzYfx2e3XGFUKOV84Gm7qM4CWljQHitmDmdkl59Wh8Q3zEacasfZGbe0dUrkaRK9dDY2vv+kV XDGbUdg1w2QriFqhnxRfjTl3rNPgMyvNrUanNqA883yvJUGvA8AnNSvAfkQ9a8/iKTGh3zUajf0u luGp+flle6FYba9Wzz5lxud8YwXWVSxX2zNZcnueUGm/uKSx3+1kPlQGFMplwrbmCUfsZ2cXURkO brs41ZXUT0crsWwLXJSqtqsHbb5dYEI4GWjp0Ftl+brnKChmAlrIUpPm3JgEeFw9aHJqB8/lXr66 +YRcq6wyGnrkJPScuvgrvkOLRYQs2Qh42AEFzmIwePryu5odbC2zyiq9oF+z66cdZeG9751z7wS1 OBGoxe+R4LOFLh3gnG8nGMi4PLSysrLf+rKsMgv0WBRnefnpEYa6+mLa0L930xU/7Yrp21WhZ55P 6P+xMn24eW5kLsD6kqwyO/RWWfV11/8DWg8dgPgaldcAAAAASUVORK5CYII= --000000000000c0734205926f166b-- From nobody Fri Sep 13 12:08:39 2019 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 36C38120111 for ; Fri, 13 Sep 2019 12:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 h72yGvSNej7L for ; Fri, 13 Sep 2019 12:08:34 -0700 (PDT) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 6C1DB1200FA for ; Fri, 13 Sep 2019 12:08:34 -0700 (PDT) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x8DJ8oNm010703; Fri, 13 Sep 2019 15:08:53 -0400 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 13 Sep 2019 15:08:04 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 13 Sep 2019 15:08:10 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Fri, 13 Sep 2019 15:08:10 -0400 From: Justin Richer To: =?utf-8?B?Um9iYWNoZSBIZXJ2w6k=?= CC: Travis Spencer , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Question regarding RFC 7592 Thread-Index: AdVpeCBmbn8uFGEHRDSH6fb8upwECQAz/ZmAAAHfXwAADiIAAA== Date: Fri, 13 Sep 2019 19:08:10 +0000 Message-ID: <827BB5C3-2143-450A-BC3D-72F98CD0B475@mit.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_827BB5C32143450ABC3D72F98CD0B475mitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Question regarding RFC 7592 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: Fri, 13 Sep 2019 19:08:37 -0000 --_000_827BB5C32143450ABC3D72F98CD0B475mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VHJhdmlzIGhhcyB0aGlzIGNvcnJlY3Qg4oCUIHRoZSDigJxyZWdpc3RyYXRpb24gYWNjZXNzIHRv a2Vu4oCdIGlzIHBhc3NlZCB0byB0aGUgY2xpZW50IGZvciB0aGUgZXhwcmVzcyBwdXJwb3NlIG9m IGFjY2Vzc2luZyB0aGUgY2xpZW50IG1hbmFnZW1lbnQgQVBJLCBhbmQgaXMgbm90IHRoZSBzYW1l IGFzLCBvciBlbnRhbmdsZWQgd2l0aCwgYW55IGFjY2VzcyB0b2tlbnMgdGhhdCB0aGUgY2xpZW50 IHJlcXVlc3RzIHRocm91Z2ggdGhlIE9BdXRoIHByb2Nlc3MgYWZ0ZXIgdGhlIHJlZ2lzdHJhdGlv biBoYXMgb2NjdXJyZWQuIFRoZSByZWFzb25zIGZvciB0aGlzIHNlcGFyYXRpb24gYXJlIG1hbnks IGJ1dCBhdCB0aGUgY29yZSBpdCBjb21lcyBkb3duIHRvIHRoZSBjbGllbnQgYWx3YXlzIGFjdGlu ZyBvbiBpdHMgb3duIGJlaGFsZiB3aGVuIGl0IGRvZXMgcmVnaXN0cmF0aW9uLCBhbmQgYWN0aW5n IG9uIGJlaGFsZiBvZiBzb21lIG90aGVyIHBhcnR5ICh1c3VhbGx5IGEgdXNlcikgd2hlbiBpdOKA mXMgZG9pbmcgT0F1dGguIEFkZGl0aW9uYWxseSwgcmVnaXN0cmF0aW9uIG1hbmFnZW1lbnQgaXMg YSBmdW5jdGlvbiBvZiB0aGUgQVMsIHdoZXJlYXMgdGhlIHByb3RlY3RlZCBBUElzIGFyZSBhIGZ1 bmN0aW9uIG9mIHRoZSBSUyDigJQgbm90ZSB0aGlzIGlzIGEgbG9naWNhbCBzZXBhcmF0aW9uIGFu ZCB0aGVyZeKAmXMgbm90aGluZyBzdG9wcGluZyBBUyBhbmQgUlMgZnVuY3Rpb25zIGZyb20gYmVp bmcgZGVwbG95ZWQgaW4gYW55IG51bWJlciBvZiBwYXR0ZXJucy4NCg0KQSBmZXcgY29tbW9uIHF1 ZXN0aW9ucyB3ZSBnb3QgYXNrZWQgd2hlbiB3cml0aW5nIHRoaXMgZnVuY3Rpb25hbGl0eSBpbnRv IHRoZSBzcGVjOg0KDQpXaHkgdXNlIGFuIGFjY2VzcyB0b2tlbiBhdCBhbGw/IEJlY2F1c2UgaXTi gJlzIGEgY3JlZGVudGlhbCBmb3IgYSBzcGVjaWZpYyBBUEkgaXNzdWVkIGJ5IHRoZSBBUyBhbmQg aGFuZGVkIHRvIHRoZSBjbGllbnQgaW4gYSBwcm9ncmFtbWF0aWMgbWFubmVyLiBUaGlzIGlzIGV4 YWN0bHkgd2hhdCBPQXV0aCB0b2tlbnMgd2VyZSBtYWRlIGZvci4NCg0KV2h5IG5vdCB1c2UgdGhl IGNsaWVudOKAmXMgY3JlZGVudGlhbHM/IEJlY2F1c2Ugbm90IGFsbCBjbGllbnRzIGFyZSBzZXQg dXAgdG8gaGF2ZSBjcmVkZW50aWFscywgcGx1cyB3ZeKAmWQgYmUgc3ByZWFkaW5nIHRoZSByZXF1 aXJlbWVudCB0byBzdXBwb3J0IGRpZmZlcmVudCBraW5kcyBvZiBjbGllbnQgY3JlZGVudGlhbHMg dG8gYW5vdGhlciBlbmRwb2ludC4NCg0KV2h5IG5vdCBpc3N1ZSBhbiBhdXRob3JpemF0aW9uIGNv ZGU/IEJlY2F1c2UgdGhlbiB0aGUgY2xpZW50IHdvdWxkIG5lZWQgdG8gbWFrZSB5ZXQgYW5vdGhl ciByb3VuZCB0cmlwLCBhbmQgbm90IGFsbCBjbGllbnRzIGFyZSBhdXRob3JpemF0aW9uLWNvZGUt Z3JhbnQgY2xpZW50cyB0byBiZWdpbiB3aXRoLg0KDQpXaHkgbm90IG1ha2UgYSBuZXcgZ3JhbnQg dHlwZT8gQmVjYXVzZSB0aGVuIHRoZSBjbGllbnQgd291bGQgbmVlZCB0byBtYWtlIHlldCBhbm90 aGVyIHJvdW5kIHRyaXAsIGFuZCB3ZeKAmWQgaGF2ZSB0byBpbnZlbnQgYSB3aG9sZSBuZXcgZ3Jh bnQgdHlwZSB3aXRoIGEgbmV3IHRlbXBvcmFyeSBjcmVkZW50aWFsIHdoZW4gd2UgY291bGQganVz dCB1c2UgdGhhdCB0ZW1wb3JhcnkgY3JlZGVudGlhbCBkaXJlY3RseSBpbnN0ZWFkLg0KDQrigJQg SnVzdGluDQoNCk9uIFNlcCAxMywgMjAxOSwgYXQgODoyMyBBTSwgUm9iYWNoZSBIZXJ2w6kgPGhl cnZlLnJvYmFjaGVAc3RldC5ldTxtYWlsdG86aGVydmUucm9iYWNoZUBzdGV0LmV1Pj4gd3JvdGU6 DQoNClRoYW5rcyBUcmF2aXMNCg0KSSB1bmRlcnN0YW5kIHRoYXQsIG9uY2UgdGhlIGNsaWVudCBo YXMgcmV0cmlldmVkIGl0cyBbY2xpZW50X2lkXSB0aHJvdWdoIFJGQzc1OTEgaW5pdGlhbCByZWdp c3RyYXRpb24sIGl0IGlzIHRoZW4gYWJsZSB0byBhc2sgZm9yIGFuIGFjY2VzcyB0b2tlbiB0aGF0 IHdpbGwgYmUgdXNlZCBmb3IgYWNjZXNzaW5nIHRoZSBSRkM3NTkyIGVudHJ5LXBvaW50cy4gQW0g SSByaWdodD8NCg0KQmVzdCByZWdhcmRzDQoNCkhlcnbDqQ0KDQpEZSA6IFRyYXZpcyBTcGVuY2Vy IFttYWlsdG86dHJhdmlzLnNwZW5jZXJAY3VyaXR5LmlvXQ0KRW52b3nDqSA6IHZlbi4gMTMgMTM6 MzANCsOAIDogUm9iYWNoZSBIZXJ2w6kNCkNjIDogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRo QGlldGYub3JnPg0KT2JqZXQgOiBSZTogW09BVVRILVdHXSBRdWVzdGlvbiByZWdhcmRpbmcgUkZD IDc1OTINCg0KTm8uIFRoZSBpbml0aWFsIGFjY2VzcyB0b2tlbiBpcyBpc3N1ZWQgYnkgdGhlIEFT IHdoZW4gcmVnaXN0cmF0aW9uIGlzIHByb3RlY3RlZCAoYXBwZW5kaXggMS4yIGluIFJGQyA3NTkx KS4gQXMgc3RhdGVkIGluIHNlY3Rpb24gMS4yLCB0aGUgbWV0aG9kIGFuZCBtZWFucyBieSB3aGlj aCB0aGlzIGlzIG9idGFpbmVkIGNhbiB2YXJ5LiBUaGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tl biBpbiBSRkMgNzU5MiBpcyB1c2VkIHRvIHByb3RlY3QgdGhlIHJlZ2lzdHJhdGlvbiBtYW5hZ2Vt ZW50IEFQSSBhbmQgYWxsb3cgdXBkYXRlcyB0byB0aGUgY2xpZW50IGFmdGVyIGl0IGlzIHJlZ2lz dGVyZWQuIFlvdSBtaWdodCBoYXZlIG9uZSAodGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4p IGJ1dCBub3QgdGhlIG90aGVyIChpbml0aWFsIGFjY2VzcyB0b2tlbikgd2hlbiBvcGVuIHJlZ2lz dHJhdGlvbiBpcyBhbGxvd2VkIChhcHBlbmRpeCAxLjEgaW4gUkZDIDc1OTEpLg0KDQpIVEghDQoN Ck9uIEZyaSwgU2VwIDEzLCAyMDE5IGF0IDc6MzcgQU0gUm9iYWNoZSBIZXJ2w6kgPGhlcnZlLnJv YmFjaGVAc3RldC5ldTxtYWlsdG86aGVydmUucm9iYWNoZUBzdGV0LmV1Pj4gd3JvdGU6DQpIaQ0K DQpSRkMgNzU5MiBpbnRyb2R1Y2VzIGEgwqsgUmVnaXN0cmF0aW9uIEFjY2VzcyBUb2tlbiDCuy4g QXJlIHRoaXMgdG9rZW4gYW5kIHRoZSB3YXkgdG8gZ2V0IGl0IHNpbWlsYXIgdG8gd2hhdCBpcyBz cGVjaWZpZWQgYXMg4oCcSW5pdGlhbCBBY2Nlc3MgVG9rZW7igJ0gaW4gUkZDIDc1OTEvQXBwZW5k aXggQSA/DQoNCklmIHNvLCBjYW4gdGhlIE9wZW4gRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9u IChSRkM3NTkxL0EuMS4xKSBiZSBleHRyYXBvbGF0ZWQgdG8gUkZDNzU5MiBhcyB0aGUgc2FtZSB3 YXk/DQoNClRoYW5rcyBpbiBhZHZhbmNlIGZvciB5b3VyIGNsYXJpZmljYXRpb24uDQoNCkhlcnbD qSBST0JBQ0hFDQpEaXJlY3Rpb24gTWFya2V0aW5nIGV0IETDqXZlbG9wcGVtZW50DQoNCkxJR05F IERJUkVDVEUNClQuICszMygwKTEgNTUgMjMgNTUgNDUNCmhlcnZlLnJvYmFjaGVAc3RldC5ldTxt YWlsdG86aGVydmUucm9iYWNoZUBzdGV0LmV1Pg0KDQoNCg0KPGltYWdlMDAxLnBuZz4NCg0KDQoN Cg0KPGltYWdlMDAyLnBuZz4NCg0KU1RFVCAoU0lFR0UgU09DSUFMKQ0KMTAwLCBFc3BsYW5hZGUg ZHUgR8OpbsOpcmFsIGRlIEdhdWxsZQ0KQ8WTdXIgRMOpZmVuc2Ug4oCTIFRvdXIgQg0KOTI5MzIg TGEgRMOpZmVuc2UgY2VkZXgNCg0Kd3d3LnN0ZXQuZXU8aHR0cDovL3d3dy5zdGV0LmV1Lz4NCg0K DQoNCkNlIG1lc3NhZ2UgZXQgdG91dGVzIGxlcyBwacOoY2VzIGpvaW50ZXMgc29udCDDqXRhYmxp cyDDoCBsJ2ludGVudGlvbiBleGNsdXNpdmUgZGUgc2VzIGRlc3RpbmF0YWlyZXMgZXQgc29udCBj b25maWRlbnRpZWxzLg0KU2kgdm91cyByZWNldmV6IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciBvdSBz J2lsIG5lIHZvdXMgZXN0IHBhcyBkZXN0aW7DqSwgbWVyY2kgZGUgbGUgZMOpdHJ1aXJlIGFpbnNp IHF1ZSB0b3V0ZSBjb3BpZSBkZSB2b3RyZSBzeXN0w6htZSBldCBkJ2VuIGF2ZXJ0aXIgaW1tw6lk aWF0ZW1lbnQgbCdleHDDqWRpdGV1ci4NClRvdXRlIGxlY3R1cmUgbm9uIGF1dG9yaXPDqWUsIHRv dXRlIHV0aWxpc2F0aW9uIGRlIGNlIG1lc3NhZ2UgcXVpIG4nZXN0IHBhcyBjb25mb3JtZSDDoCBz YSBkZXN0aW5hdGlvbiwgdG91dGUgZGlmZnVzaW9uIG91IHRvdXRlIHB1YmxpY2F0aW9uLCB0b3Rh bGUgb3UgcGFydGllbGxlLCBlc3QgaW50ZXJkaXRlLg0KTCdJbnRlcm5ldCBuZSBwZXJtZXR0YW50 IHBhcyBkJ2Fzc3VyZXIgbCdpbnTDqWdyaXTDqSBkZSBjZSBtZXNzYWdlIMOpbGVjdHJvbmlxdWUg c3VzY2VwdGlibGUgZCdhbHTDqXJhdGlvbiwgU1RFVCBkw6ljbGluZSB0b3V0ZSByZXNwb25zYWJp bGl0w6kgYXUgdGl0cmUgZGUgY2UgbWVzc2FnZSBkYW5zIGwnaHlwb3Row6hzZSBvw7kgaWwgYXVy YWl0IMOpdMOpIG1vZGlmacOpLCBkw6lmb3Jtw6kgb3UgZmFsc2lmacOpLg0KTidpbXByaW1leiBj ZSBtZXNzYWdlIHF1ZSBzaSBuw6ljZXNzYWlyZSwgcGVuc2V6IMOgIGwnZW52aXJvbm5lbWVudC4N Cg0KVGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgaW50ZW5kZWQgYWRkcmVzc2VlcyBhbmQgaXMgY29uZmlkZW50aWFsLg0KSWYgeW91IHJl Y2VpdmUgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBvciBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQocyksIHBsZWFzZSBkZWxldGUgaXQgYW5kIGFueSBjb3BpZXMgZnJvbSB5b3VyIHN5c3Rl bXMgYW5kIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyLg0KQW55IHVuYXV0aG9yaXplZCB2 aWV3LCB1c2UgdGhhdCBkb2VzIG5vdCBjb21wbHkgd2l0aCBpdHMgcHVycG9zZSwgZGlzc2VtaW5h dGlvbiBvciBkaXNjbG9zdXJlLCBlaXRoZXIgd2hvbGUgb3IgcGFydGlhbCwgaXMgcHJvaGliaXRl ZC4NClNpbmNlIHRoZSBpbnRlcm5ldCBjYW5ub3QgZ3VhcmFudGVlIHRoZSBpbnRlZ3JpdHkgb2Yg dGhpcyBtZXNzYWdlIHdoaWNoIG1heSBub3QgYmUgcmVsaWFibGUsIFNURVQgc2hhbGwgbm90IGJl IGxpYWJsZSBmb3IgdGhlIG1lc3NhZ2UgaWYgbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KRG8gbm90IHByaW50IHRoaXMgbWVzc2FnZSB1bmxlc3MgaXQgaXMgbmVjZXNzYXJ5LCBwbGVh c2UgY29uc2lkZXIgdGhlIGVudmlyb25tZW50Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8 bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aA0KDQoNCkNlIG1lc3NhZ2UgZXQgdG91dGVzIGxlcyBwacOoY2VzIGpvaW50ZXMg c29udCDDqXRhYmxpcyDDoCBsJ2ludGVudGlvbiBleGNsdXNpdmUgZGUgc2VzIGRlc3RpbmF0YWly ZXMgZXQgc29udCBjb25maWRlbnRpZWxzLg0KU2kgdm91cyByZWNldmV6IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciBvdSBzJ2lsIG5lIHZvdXMgZXN0IHBhcyBkZXN0aW7DqSwgbWVyY2kgZGUgbGUgZMOp dHJ1aXJlIGFpbnNpIHF1ZSB0b3V0ZSBjb3BpZSBkZSB2b3RyZSBzeXN0w6htZSBldCBkJ2VuIGF2 ZXJ0aXIgaW1tw6lkaWF0ZW1lbnQgbCdleHDDqWRpdGV1ci4NClRvdXRlIGxlY3R1cmUgbm9uIGF1 dG9yaXPDqWUsIHRvdXRlIHV0aWxpc2F0aW9uIGRlIGNlIG1lc3NhZ2UgcXVpIG4nZXN0IHBhcyBj b25mb3JtZSDDoCBzYSBkZXN0aW5hdGlvbiwgdG91dGUgZGlmZnVzaW9uIG91IHRvdXRlIHB1Ymxp Y2F0aW9uLCB0b3RhbGUgb3UgcGFydGllbGxlLCBlc3QgaW50ZXJkaXRlLg0KTCdJbnRlcm5ldCBu ZSBwZXJtZXR0YW50IHBhcyBkJ2Fzc3VyZXIgbCdpbnTDqWdyaXTDqSBkZSBjZSBtZXNzYWdlIMOp bGVjdHJvbmlxdWUgc3VzY2VwdGlibGUgZCdhbHTDqXJhdGlvbiwgU1RFVCBkw6ljbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0w6kgYXUgdGl0cmUgZGUgY2UgbWVzc2FnZSBkYW5zIGwnaHlwb3Row6hz ZSBvw7kgaWwgYXVyYWl0IMOpdMOpIG1vZGlmacOpLCBkw6lmb3Jtw6kgb3UgZmFsc2lmacOpLg0K TidpbXByaW1leiBjZSBtZXNzYWdlIHF1ZSBzaSBuw6ljZXNzYWlyZSwgcGVuc2V6IMOgIGwnZW52 aXJvbm5lbWVudC4NCg0KVGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgaW50ZW5kZWQgYWRkcmVzc2VlcyBhbmQgaXMgY29uZmlkZW50aWFs Lg0KSWYgeW91IHJlY2VpdmUgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBvciBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQocyksIHBsZWFzZSBkZWxldGUgaXQgYW5kIGFueSBjb3BpZXMgZnJv bSB5b3VyIHN5c3RlbXMgYW5kIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyLg0KQW55IHVu YXV0aG9yaXplZCB2aWV3LCB1c2UgdGhhdCBkb2VzIG5vdCBjb21wbHkgd2l0aCBpdHMgcHVycG9z ZSwgZGlzc2VtaW5hdGlvbiBvciBkaXNjbG9zdXJlLCBlaXRoZXIgd2hvbGUgb3IgcGFydGlhbCwg aXMgcHJvaGliaXRlZC4NClNpbmNlIHRoZSBpbnRlcm5ldCBjYW5ub3QgZ3VhcmFudGVlIHRoZSBp bnRlZ3JpdHkgb2YgdGhpcyBtZXNzYWdlIHdoaWNoIG1heSBub3QgYmUgcmVsaWFibGUsIFNURVQg c2hhbGwgbm90IGJlIGxpYWJsZSBmb3IgdGhlIG1lc3NhZ2UgaWYgbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLg0KRG8gbm90IHByaW50IHRoaXMgbWVzc2FnZSB1bmxlc3MgaXQgaXMgbmVj ZXNzYXJ5LCBwbGVhc2UgY29uc2lkZXIgdGhlIGVudmlyb25tZW50Lg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1 dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_827BB5C32143450ABC3D72F98CD0B475mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRyYXZpcyBoYXMgdGhpcyBjb3JyZWN0IOKAlCB0 aGUg4oCccmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbuKAnSBpcyBwYXNzZWQgdG8gdGhlIGNsaWVu dCBmb3IgdGhlIGV4cHJlc3MgcHVycG9zZSBvZiBhY2Nlc3NpbmcgdGhlIGNsaWVudCBtYW5hZ2Vt ZW50IEFQSSwgYW5kIGlzIG5vdCB0aGUgc2FtZSBhcywgb3IgZW50YW5nbGVkIHdpdGgsIGFueSBh Y2Nlc3MgdG9rZW5zIHRoYXQgdGhlIGNsaWVudCByZXF1ZXN0cyB0aHJvdWdoIHRoZSBPQXV0aCBw cm9jZXNzDQogYWZ0ZXIgdGhlIHJlZ2lzdHJhdGlvbiBoYXMgb2NjdXJyZWQuIFRoZSByZWFzb25z IGZvciB0aGlzIHNlcGFyYXRpb24gYXJlIG1hbnksIGJ1dCBhdCB0aGUgY29yZSBpdCBjb21lcyBk b3duIHRvIHRoZSBjbGllbnQgYWx3YXlzIGFjdGluZyBvbiBpdHMgb3duIGJlaGFsZiB3aGVuIGl0 IGRvZXMgcmVnaXN0cmF0aW9uLCBhbmQgYWN0aW5nIG9uIGJlaGFsZiBvZiBzb21lIG90aGVyIHBh cnR5ICh1c3VhbGx5IGEgdXNlcikgd2hlbiBpdOKAmXMgZG9pbmcNCiBPQXV0aC4gQWRkaXRpb25h bGx5LCByZWdpc3RyYXRpb24gbWFuYWdlbWVudCBpcyBhIGZ1bmN0aW9uIG9mIHRoZSBBUywgd2hl cmVhcyB0aGUgcHJvdGVjdGVkIEFQSXMgYXJlIGEgZnVuY3Rpb24gb2YgdGhlIFJTIOKAlCBub3Rl IHRoaXMgaXMgYSBsb2dpY2FsIHNlcGFyYXRpb24gYW5kIHRoZXJl4oCZcyBub3RoaW5nIHN0b3Bw aW5nIEFTIGFuZCBSUyBmdW5jdGlvbnMgZnJvbSBiZWluZyBkZXBsb3llZCBpbiBhbnkgbnVtYmVy IG9mIHBhdHRlcm5zLiZuYnNwOw0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+QSBmZXcgY29tbW9uIHF1ZXN0aW9ucyB3ZSBnb3QgYXNrZWQgd2hlbiB3 cml0aW5nIHRoaXMgZnVuY3Rpb25hbGl0eSBpbnRvIHRoZSBzcGVjOjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+V2h5 IHVzZSBhbiBhY2Nlc3MgdG9rZW4gYXQgYWxsPC9iPj8gQmVjYXVzZSBpdOKAmXMgYSBjcmVkZW50 aWFsIGZvciBhIHNwZWNpZmljIEFQSSBpc3N1ZWQgYnkgdGhlIEFTIGFuZCBoYW5kZWQgdG8gdGhl IGNsaWVudCBpbiBhIHByb2dyYW1tYXRpYyBtYW5uZXIuIFRoaXMgaXMgZXhhY3RseSB3aGF0IE9B dXRoIHRva2VucyB3ZXJlIG1hZGUgZm9yLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+V2h5IG5vdCB1c2Ug dGhlIGNsaWVudOKAmXMgY3JlZGVudGlhbHM8L2I+PyBCZWNhdXNlIG5vdCBhbGwgY2xpZW50cyBh cmUgc2V0IHVwIHRvIGhhdmUgY3JlZGVudGlhbHMsIHBsdXMgd2XigJlkIGJlIHNwcmVhZGluZyB0 aGUgcmVxdWlyZW1lbnQgdG8gc3VwcG9ydCBkaWZmZXJlbnQga2luZHMgb2YgY2xpZW50IGNyZWRl bnRpYWxzIHRvIGFub3RoZXIgZW5kcG9pbnQuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YiBjbGFzcz0iIj5XaHkgbm90IGlz c3VlIGFuIGF1dGhvcml6YXRpb24gY29kZTwvYj4/IEJlY2F1c2UgdGhlbiB0aGUgY2xpZW50IHdv dWxkIG5lZWQgdG8gbWFrZSB5ZXQgYW5vdGhlciByb3VuZCB0cmlwLCBhbmQgbm90IGFsbCBjbGll bnRzIGFyZSBhdXRob3JpemF0aW9uLWNvZGUtZ3JhbnQgY2xpZW50cyB0byBiZWdpbiB3aXRoLiZu YnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGIgY2xhc3M9IiI+V2h5IG5vdCBtYWtlIGEgbmV3IGdyYW50IHR5cGU8L2I+PyBCZWNh dXNlIHRoZW4gdGhlIGNsaWVudCB3b3VsZCBuZWVkIHRvIG1ha2UgeWV0IGFub3RoZXIgcm91bmQg dHJpcCwgYW5kIHdl4oCZZCBoYXZlIHRvIGludmVudCBhIHdob2xlIG5ldyBncmFudCB0eXBlIHdp dGggYSBuZXcgdGVtcG9yYXJ5IGNyZWRlbnRpYWwgd2hlbiB3ZSBjb3VsZCBqdXN0IHVzZSB0aGF0 IHRlbXBvcmFyeSBjcmVkZW50aWFsIGRpcmVjdGx5DQogaW5zdGVhZC4mbmJzcDs8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNh cmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCuKA lCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gU2VwIDEzLCAyMDE5LCBhdCA4 OjIzIEFNLCBSb2JhY2hlIEhlcnbDqSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhlcnZlLnJvYmFjaGVA c3RldC5ldSIgY2xhc3M9IiI+aGVydmUucm9iYWNoZUBzdGV0LmV1PC9hPiZndDsgd3JvdGU6PC9k aXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsg Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5UaGFua3MgVHJhdmlzPG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNs YXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNs YXNzPSIiPkkgdW5kZXJzdGFuZCB0aGF0LCBvbmNlIHRoZSBjbGllbnQgaGFzIHJldHJpZXZlZCBp dHMgW2NsaWVudF9pZF0gdGhyb3VnaCBSRkM3NTkxIGluaXRpYWwgcmVnaXN0cmF0aW9uLCBpdCBp cyB0aGVuIGFibGUgdG8gYXNrIGZvciBhbiBhY2Nlc3MgdG9rZW4NCiB0aGF0IHdpbGwgYmUgdXNl ZCBmb3IgYWNjZXNzaW5nIHRoZSBSRkM3NTkyIGVudHJ5LXBvaW50cy4gQW0gSSByaWdodD88bzpw IGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyIgY2xhc3M9IiI+QmVzdCByZWdhcmRzPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFz cz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFz cz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPkhlcnbDqTxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2Vy aWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5EZSZuYnNwOzo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEs IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+VHJhdmlzIFNwZW5jZXIgWzxhIGhyZWY9Im1haWx0bzp0cmF2aXMuc3Bl bmNlckBjdXJpdHkuaW8iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVu ZGVybGluZTsiIGNsYXNzPSIiPm1haWx0bzp0cmF2aXMuc3BlbmNlckBjdXJpdHkuaW88L2E+XTxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9 IiI+DQo8YiBjbGFzcz0iIj5FbnZvecOpJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+dmVuLiAxMyAxMzozMDxiciBjbGFzcz0iIj4NCjxi IGNsYXNzPSIiPsOAJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+Um9iYWNoZSBIZXJ2w6k8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5D YyZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7 IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+b2F1dGhAaWV0Zi5vcmc8L2E+ PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+T2JqZXQmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW09BVVRILVdHXSBRdWVzdGlv biByZWdhcmRpbmcgUkZDIDc1OTI8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0K PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIg Y2xhc3M9IiI+DQpOby4gVGhlIGluaXRpYWwgYWNjZXNzIHRva2VuIGlzIGlzc3VlZCBieSB0aGUg QVMgd2hlbiByZWdpc3RyYXRpb24gaXMgcHJvdGVjdGVkIChhcHBlbmRpeCAxLjIgaW4gUkZDIDc1 OTEpLiBBcyBzdGF0ZWQgaW4gc2VjdGlvbiAxLjIsIHRoZSBtZXRob2QgYW5kIG1lYW5zIGJ5IHdo aWNoIHRoaXMgaXMgb2J0YWluZWQgY2FuIHZhcnkuIFRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRv a2VuIGluIFJGQyA3NTkyIGlzIHVzZWQgdG8gcHJvdGVjdCB0aGUgcmVnaXN0cmF0aW9uDQogbWFu YWdlbWVudCBBUEkgYW5kIGFsbG93IHVwZGF0ZXMgdG8gdGhlIGNsaWVudCBhZnRlciBpdCBpcyBy ZWdpc3RlcmVkLiBZb3UgbWlnaHQgaGF2ZSBvbmUgKHRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRv a2VuKSBidXQgbm90IHRoZSBvdGhlciAoaW5pdGlhbCBhY2Nlc3MgdG9rZW4pIHdoZW4gb3BlbiBy ZWdpc3RyYXRpb24gaXMgYWxsb3dlZCAoYXBwZW5kaXggMS4xIGluIFJGQyA3NTkxKS48bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNz PSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQpIVEghPG86 cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+ Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KT24g RnJpLCBTZXAgMTMsIDIwMTkgYXQgNzozNyBBTSBSb2JhY2hlIEhlcnbDqSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmhlcnZlLnJvYmFjaGVAc3RldC5ldSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aGVydmUucm9iYWNoZUBzdGV0LmV1PC9h PiZndDsgd3JvdGU6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0 LXdpZHRoOiAxcHQ7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRp bmc6IDBjbSAwY20gMGNtIDZwdDsgbWFyZ2luLWxlZnQ6IDQuOHB0OyBtYXJnaW4tcmlnaHQ6IDBj bTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCkhpPG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPlJGQyA3NTkyIGludHJvZHVjZXMgYSDCqyZu YnNwO1JlZ2lzdHJhdGlvbiBBY2Nlc3MgVG9rZW4mbmJzcDvCuy4gQXJlIHRoaXMgdG9rZW4gYW5k IHRoZSB3YXkgdG8gZ2V0IGl0IHNpbWlsYXIgdG8gd2hhdCBpcyBzcGVjaWZpZWQgYXMg4oCcSW5p dGlhbCBBY2Nlc3MgVG9rZW7igJ0gaW4gUkZDIDc1OTEvQXBwZW5kaXggQSA/PC9zcGFuPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj4mbmJz cDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IGNsYXNzPSIiPklmIHNvLCBjYW4gdGhlIE9wZW4gRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9u IChSRkM3NTkxL0EuMS4xKSBiZSBleHRyYXBvbGF0ZWQgdG8gUkZDNzU5MiBhcyB0aGUgc2FtZSB3 YXk/PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPlRoYW5rcyBpbiBhZHZhbmNlIGZvciB5b3VyIGNsYXJp ZmljYXRpb24uPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJnF1b3Q7QXJpYWwg Um91bmRlZCBNVCBCb2xkJnF1b3Q7LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+SGVydsOpIFJPQkFD SEU8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogOXB0OyBmb250LWZhbWlseTogJnF1b3Q7QXJpYWwgUm91bmRlZCBNVCBCb2xkJnF1b3Q7 LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+RGlyZWN0aW9uIE1hcmtldGluZyBldCBEw6l2ZWxvcHBl bWVudDwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtBcmlhbCBSb3VuZGVkIE1UIEJvbGQmcXVv dDssIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogQXJp YWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5MSUdORSBESVJFQ1RFPC9zcGFuPjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywg c2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1p bHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+VC4gJiM0MzszMygwKTEgNTUgMjMgNTUg NDU8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogOXB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48YSBo cmVmPSJtYWlsdG86aGVydmUucm9iYWNoZUBzdGV0LmV1IiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9 ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aGVy dmUucm9iYWNoZUBzdGV0LmV1PC9hPjwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8 L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFs VGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBhbGlnbj0i bGVmdCI+DQo8dGJvZHkgY2xhc3M9IiI+DQo8dHIgc3R5bGU9ImhlaWdodDogNnB0OyIgY2xhc3M9 IiI+DQo8dGQgd2lkdGg9IjEiIHN0eWxlPSJ3aWR0aDogMC43NXB0OyBwYWRkaW5nOiAwY207IGhl aWdodDogNnB0OyIgY2xhc3M9IiI+PC90ZD4NCjwvdHI+DQo8dHIgY2xhc3M9IiI+DQo8dGQgc3R5 bGU9InBhZGRpbmc6IDBjbTsiIGNsYXNzPSIiPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6IDBj bTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBpZD0iY2lkOmltYWdlMDAxLnBuZ0AwMUQ1NkEzRS5EMDQ1 QTc0MCI+Jmx0O2ltYWdlMDAxLnBuZyZndDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rp dj4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBj bGFzcz0iIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPGJyIGNs ZWFyPSJhbGwiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PHNwYW4gaWQ9ImNpZDpp bWFnZTAwMi5wbmdAMDFENTZBM0UuRDA0NUE3NDAiPiZsdDtpbWFnZTAwMi5wbmcmZ3Q7PC9zcGFu Pjwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTog QXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5TVEVUIChTSUVHRSBTT0NJQUwpPC9zcGFuPjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsg Zm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+MTAwLCBFc3BsYW5hZGUg ZHUgR8OpbsOpcmFsIGRlIEdhdWxsZTwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPkPFk3VyIETDqWZlbnNlIOKAkyBUb3VyIEI8L3NwYW4+PG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZh bWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj45MjkzMiBMYSBEw6lmZW5zZSBjZWRl eDwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNw Ozwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxhIGhy ZWY9Imh0dHA6Ly93d3cuc3RldC5ldS8iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1 cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj53d3cuc3RldC5ldTwv YT48L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOiA3LjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogZ3Jh eTsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkNlIG1lc3NhZ2UgZXQgdG91dGVzIGxlcyBwacOo Y2VzIGpvaW50ZXMgc29udCDDqXRhYmxpcyDDoCBsJ2ludGVudGlvbiBleGNsdXNpdmUgZGUgc2Vz IGRlc3RpbmF0YWlyZXMgZXQgc29udCBjb25maWRlbnRpZWxzLjxiciBjbGFzcz0iIj4NClNpIHZv dXMgcmVjZXZleiBjZSBtZXNzYWdlIHBhciBlcnJldXIgb3UgcydpbCBuZSB2b3VzIGVzdCBwYXMg ZGVzdGluw6ksIG1lcmNpIGRlIGxlIGTDqXRydWlyZSBhaW5zaSBxdWUgdG91dGUgY29waWUgZGUg dm90cmUgc3lzdMOobWUgZXQgZCdlbiBhdmVydGlyIGltbcOpZGlhdGVtZW50IGwnZXhww6lkaXRl dXIuPGJyIGNsYXNzPSIiPg0KVG91dGUgbGVjdHVyZSBub24gYXV0b3Jpc8OpZSwgdG91dGUgdXRp bGlzYXRpb24gZGUgY2UgbWVzc2FnZSBxdWkgbidlc3QgcGFzIGNvbmZvcm1lIMOgIHNhIGRlc3Rp bmF0aW9uLCB0b3V0ZSBkaWZmdXNpb24gb3UgdG91dGUgcHVibGljYXRpb24sIHRvdGFsZSBvdSBw YXJ0aWVsbGUsIGVzdCBpbnRlcmRpdGUuPGJyIGNsYXNzPSIiPg0KTCdJbnRlcm5ldCBuZSBwZXJt ZXR0YW50IHBhcyBkJ2Fzc3VyZXIgbCdpbnTDqWdyaXTDqSBkZSBjZSBtZXNzYWdlIMOpbGVjdHJv bmlxdWUgc3VzY2VwdGlibGUgZCdhbHTDqXJhdGlvbiwgU1RFVCBkw6ljbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0w6kgYXUgdGl0cmUgZGUgY2UgbWVzc2FnZSBkYW5zIGwnaHlwb3Row6hzZSBvw7kg aWwgYXVyYWl0IMOpdMOpIG1vZGlmacOpLCBkw6lmb3Jtw6kgb3UgZmFsc2lmacOpLjxiciBjbGFz cz0iIj4NCk4naW1wcmltZXogY2UgbWVzc2FnZSBxdWUgc2kgbsOpY2Vzc2FpcmUsIHBlbnNleiDD oCBsJ2Vudmlyb25uZW1lbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhpcyBtZXNz YWdlIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgaW50ZW5k ZWQgYWRkcmVzc2VlcyBhbmQgaXMgY29uZmlkZW50aWFsLjxiciBjbGFzcz0iIj4NCklmIHlvdSBy ZWNlaXZlIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgb3IgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50KHMpLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBhbnkgY29waWVzIGZyb20geW91ciBzeXN0 ZW1zIGFuZCBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlci48YnIgY2xhc3M9IiI+DQpBbnkg dW5hdXRob3JpemVkIHZpZXcsIHVzZSB0aGF0IGRvZXMgbm90IGNvbXBseSB3aXRoIGl0cyBwdXJw b3NlLCBkaXNzZW1pbmF0aW9uIG9yIGRpc2Nsb3N1cmUsIGVpdGhlciB3aG9sZSBvciBwYXJ0aWFs LCBpcyBwcm9oaWJpdGVkLjxiciBjbGFzcz0iIj4NClNpbmNlIHRoZSBpbnRlcm5ldCBjYW5ub3Qg Z3VhcmFudGVlIHRoZSBpbnRlZ3JpdHkgb2YgdGhpcyBtZXNzYWdlIHdoaWNoIG1heSBub3QgYmUg cmVsaWFibGUsIFNURVQgc2hhbGwgbm90IGJlIGxpYWJsZSBmb3IgdGhlIG1lc3NhZ2UgaWYgbW9k aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxiciBjbGFzcz0iIj4NCkRvIG5vdCBwcmludCB0 aGlzIG1lc3NhZ2UgdW5sZXNzIGl0IGlzIG5lY2Vzc2FyeSwgcGxlYXNlIGNvbnNpZGVyIHRoZSBl bnZpcm9ubWVudC48L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0i Ij4NCk9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9hPjxiciBjbGFz cz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9u OiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBj bGFzcz0iIj4NCjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6ZT0iMSIgc3R5bGU9 ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg dGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KQ2UgbWVzc2Fn ZSBldCB0b3V0ZXMgbGVzIHBpw6hjZXMgam9pbnRlcyBzb250IMOpdGFibGlzIMOgIGwnaW50ZW50 aW9uIGV4Y2x1c2l2ZSBkZSBzZXMgZGVzdGluYXRhaXJlcyBldCBzb250IGNvbmZpZGVudGllbHMu PGJyIGNsYXNzPSIiPg0KU2kgdm91cyByZWNldmV6IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciBvdSBz J2lsIG5lIHZvdXMgZXN0IHBhcyBkZXN0aW7DqSwgbWVyY2kgZGUgbGUgZMOpdHJ1aXJlIGFpbnNp IHF1ZSB0b3V0ZSBjb3BpZSBkZSB2b3RyZSBzeXN0w6htZSBldCBkJ2VuIGF2ZXJ0aXIgaW1tw6lk aWF0ZW1lbnQgbCdleHDDqWRpdGV1ci48YnIgY2xhc3M9IiI+DQpUb3V0ZSBsZWN0dXJlIG5vbiBh dXRvcmlzw6llLCB0b3V0ZSB1dGlsaXNhdGlvbiBkZSBjZSBtZXNzYWdlIHF1aSBuJ2VzdCBwYXMg Y29uZm9ybWUgw6Agc2EgZGVzdGluYXRpb24sIHRvdXRlIGRpZmZ1c2lvbiBvdSB0b3V0ZSBwdWJs aWNhdGlvbiwgdG90YWxlIG91IHBhcnRpZWxsZSwgZXN0IGludGVyZGl0ZS48YnIgY2xhc3M9IiI+ DQpMJ0ludGVybmV0IG5lIHBlcm1ldHRhbnQgcGFzIGQnYXNzdXJlciBsJ2ludMOpZ3JpdMOpIGRl IGNlIG1lc3NhZ2Ugw6lsZWN0cm9uaXF1ZSBzdXNjZXB0aWJsZSBkJ2FsdMOpcmF0aW9uLCBTVEVU IGTDqWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXTDqSBhdSB0aXRyZSBkZSBjZSBtZXNzYWdlIGRh bnMgbCdoeXBvdGjDqHNlIG/DuSBpbCBhdXJhaXQgw6l0w6kgbW9kaWZpw6ksIGTDqWZvcm3DqSBv dSBmYWxzaWZpw6kuPGJyIGNsYXNzPSIiPg0KTidpbXByaW1leiBjZSBtZXNzYWdlIHF1ZSBzaSBu w6ljZXNzYWlyZSwgcGVuc2V6IMOgIGwnZW52aXJvbm5lbWVudC48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpUaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBpcyBpbnRlbmRlZCBz b2xlbHkgZm9yIHRoZSBpbnRlbmRlZCBhZGRyZXNzZWVzIGFuZCBpcyBjb25maWRlbnRpYWwuPGJy IGNsYXNzPSIiPg0KSWYgeW91IHJlY2VpdmUgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBvciBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocyksIHBsZWFzZSBkZWxldGUgaXQgYW5kIGFueSBj b3BpZXMgZnJvbSB5b3VyIHN5c3RlbXMgYW5kIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVy LjxiciBjbGFzcz0iIj4NCkFueSB1bmF1dGhvcml6ZWQgdmlldywgdXNlIHRoYXQgZG9lcyBub3Qg Y29tcGx5IHdpdGggaXRzIHB1cnBvc2UsIGRpc3NlbWluYXRpb24gb3IgZGlzY2xvc3VyZSwgZWl0 aGVyIHdob2xlIG9yIHBhcnRpYWwsIGlzIHByb2hpYml0ZWQuPGJyIGNsYXNzPSIiPg0KU2luY2Ug dGhlIGludGVybmV0IGNhbm5vdCBndWFyYW50ZWUgdGhlIGludGVncml0eSBvZiB0aGlzIG1lc3Nh Z2Ugd2hpY2ggbWF5IG5vdCBiZSByZWxpYWJsZSwgU1RFVCBzaGFsbCBub3QgYmUgbGlhYmxlIGZv ciB0aGUgbWVzc2FnZSBpZiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPGJyIGNsYXNz PSIiPg0KRG8gbm90IHByaW50IHRoaXMgbWVzc2FnZSB1bmxlc3MgaXQgaXMgbmVjZXNzYXJ5LCBw bGVhc2UgY29uc2lkZXIgdGhlIGVudmlyb25tZW50LjxiciBjbGFzcz0iIj4NCjwvZm9udD48c3Bh biBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxh eTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj48L3NwYW4+PHNwYW4gc3R5bGU9ImNhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w b3J0YW50OyIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0 OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPk9BdXRoDQogbWFp bGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIg Y2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjog cHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9y cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgc3R5bGU9ImNvbG9yOiBwdXJw bGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8L2E+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_827BB5C32143450ABC3D72F98CD0B475mitedu_-- From nobody Fri Sep 13 12:13:07 2019 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 D25DB120111 for ; Fri, 13 Sep 2019 12:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 dTmrNu0fiqRQ for ; Fri, 13 Sep 2019 12:13:05 -0700 (PDT) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 DF72B1200FA for ; Fri, 13 Sep 2019 12:13:04 -0700 (PDT) Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x8DJDD9b011013; Fri, 13 Sep 2019 15:13:24 -0400 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 13 Sep 2019 15:12:41 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 13 Sep 2019 15:12:48 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Fri, 13 Sep 2019 15:12:48 -0400 From: Justin Richer To: Masakazu OHTSUKA CC: Marius Scurtescu , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Public client cloning Thread-Index: AQHVZ/j4JiICU9vqDEmbu/R19TzDAKcla9wAgAAit4CABLL9gA== Date: Fri, 13 Sep 2019 19:12:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_CC052670A4A04AD69D7FDDB7096E7128mitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Public client cloning 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: Fri, 13 Sep 2019 19:13:07 -0000 --_000_CC052670A4A04AD69D7FDDB7096E7128mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgdGhlIHBob25lIGlzIGNvbXByb21pc2VkLCBpdCBkb2VzbuKAmXQgbWF0dGVyIGlmIHRoZSBj bGllbnQgaXMgcHVibGljIG9yIGNvbmZpZGVudGlhbC4gSW4gdGhlIGxhdHRlciBjYXNlLCBhbiBh dHRhY2tlciBjb3VsZCBleGZpbHRyYXRlIG9yIGNhcHR1cmUgdGhlIGNsaWVudOKAmXMgb3duIGNy ZWRlbnRpYWxzIGFuZCB1c2UgdGhlbSBtYWxpY2lvdXNseS4NCg0K4oCUIEp1c3Rpbg0KDQpPbiBT ZXAgMTAsIDIwMTksIGF0IDM6MjcgUE0sIE1hc2FrYXp1IE9IVFNVS0EgPG8ubWFzYWthenVAZ21h aWwuY29tPG1haWx0bzpvLm1hc2FrYXp1QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpJIHNlZS4NCg0K VGhlbiBpcyB0aGlzIHVuZGVyc3RhbmRhYmxlIHRvIHRoaW5rIGZyb20gdGhlIEF1dGhvcml6YXRp b24gU2VydmVyJ3MgcG9pbnQgb2YgdmlldyAuLi4NCg0KSWYgcGhvbmUgYmVpbmcgY29tcHJvbWlz ZWQgaXMgYSB0aHJlYXQgdGhhdCB0aGUgQ2xpZW50IGNhcmVzLA0KQVMgbWlnaHQgYmUgaW50ZXJl c3RlZCBpbiBOT1Qgc3VwcG9ydGluZyBwdWJsaWMgQ2xpZW50cywNCmFuZCBmb3JjaW5nIHRoZSBD bGllbnQgdG8gaGF2ZSBhIHNlcnZlciBzaWRlLCBkbyBjbGllbnQgYXV0aGVudGljYXRpb24sIGFu ZCBoYXZlIHNvbWUgd2F5IHRvIGhvbGQgYSBzZXNzaW9uIGJldHdlZW4gdGhlIG5hdGl2ZSBhcHAg YW5kIGl0J3Mgc2VydmVyIHNpZGUuDQoNCkJlY2F1c2UgaWYgcGhvbmUgaXMgY29tcHJvbWlzZWQs IHdoZW4gQVMgc3VwcG9ydHMgcHVibGljIENsaWVudHMgYW5kIGFjY2Vzc190b2tlbiBsZWFrcywg aXQncyBraW5kIG9mIEFTJ3MgZmF1bHQgKHdlbGwgZGVwZW5kaW5nIG9uIHRoZSB0ZXJtcy4uLiks DQpidXQgaWYgd2hhdGV2ZXIgdGhlIG1lYW5zIHRoYXQgdGhlIHBob25lIGFwcCBhbmQgaXQncyBz ZXJ2ZXIgc2lkZSBrZWVwcyBhIHNlc3Npb24gbGVha3MsIGl0J3MgTk9UIHRoZSBBUydzIGZhdWx0 Lg0KDQoNCk9uIFR1ZSwgU2VwIDEwLCAyMDE5IGF0IDg6MjMgUE0gTWFyaXVzIFNjdXJ0ZXNjdSA8 bWFyaXVzLnNjdXJ0ZXNjdUBjb2luYmFzZS5jb208bWFpbHRvOm1hcml1cy5zY3VydGVzY3VAY29p bmJhc2UuY29tPj4gd3JvdGU6DQpJZiB0aGUgcGhvbmUgaXMgY29tcHJvbWlzZWQsIG9yaWdpbmFs IGFwcCByZXBsYWNlZCBieSBtYWxpY2lvdXMgYXBwLCB0aGVuIFJGQzgyNTIgd2lsbCBub3QgaGVs cC4gVGhlIGFzc3VtcHRpb24gaXMgdGhhdCB0aGUgcGhvbmUgaXMgbm90IGNvbXByb21pc2VkLg0K DQpPbiBUdWUsIFNlcCAxMCwgMjAxOSBhdCA5OjU4IEFNIE1hc2FrYXp1IE9IVFNVS0EgPG8uLm1h c2FrYXp1QGdtYWlsLmNvbTxtYWlsdG86by5tYXNha2F6dUBnbWFpbC5jb20+PiB3cm90ZToNCkhp LA0KDQpJJ3ZlIHJlYWQgcmZjODI1MiBhbmQgaGF2ZSBxdWVzdGlvbnMgYWJvdXQgbmF0aXZlIGFw cHMsIHRoYXQgSSBjb3VsZG4ndCBmaW5kIGFuc3dlcnMgb24gSW50ZXJuZXQuDQoNCkltYWdpbmUg YW4gYXR0YWNrZXIgZG9pbmc6DQoxLiBvcmlnaW5hbCBhcHAgYW5kIGF1dGhvcml6YXRpb24gc2Vy dmVyIGNvbmZvcm1zIHRvIHJmYzgyNTIgNC4xLiAgQXV0aG9yaXphdGlvbiBGbG93IGZvciBOYXRp dmUgQXBwcyBVc2luZyB0aGUgQnJvd3Nlcg0KMi4gY2xvbmUgdGhlIG9yaWdpbmFsIGFwcCwgbmFt ZSBpdCBtYWxpY2lvdXMgYXBwIGFuZCBpbnN0YWxsIG9uIHRoZSB0YXJnZXQgcGhvbmUNCjMuIHJl bW92ZSB0aGUgb3JpZ2luYWwgYXBwIGZyb20gdGhlIHRhcmdldCBwaG9uZQ0KNC4gdXNlIHRoZSBt YWxpY2lvdXMgYXBwIGFuZCBhdXRob3JpemUsIE9TIHdpbGwgaW52b2tlIG1hbGljaW91cyBhcHAg dXNpbmcgY3VzdG9tIFVSTCBzY2hlbWUNCjUuIG5vdyBtYWxpY2lvdXMgYXBwIGhhcyBhY2Nlc3Mg dG8gdGhlIGFjY2VzcyB0b2tlbg0KDQpIb3cgc2hvdWxkIHdlIHRoaW5rIGFib3V0IHRoaXM/DQpX aGF0IGFtIEkgbWlzc2luZz8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRo IG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_CC052670A4A04AD69D7FDDB7096E7128mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCklmIHRoZSBwaG9uZSBpcyBjb21wcm9taXNlZCwg aXQgZG9lc27igJl0IG1hdHRlciBpZiB0aGUgY2xpZW50IGlzIHB1YmxpYyBvciBjb25maWRlbnRp YWwuIEluIHRoZSBsYXR0ZXIgY2FzZSwgYW4gYXR0YWNrZXIgY291bGQgZXhmaWx0cmF0ZSBvciBj YXB0dXJlIHRoZSBjbGllbnTigJlzIG93biBjcmVkZW50aWFscyBhbmQgdXNlIHRoZW0gbWFsaWNp b3VzbHkuJm5ic3A7DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1h ZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0 aW9uOiBub25lOyI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIFNl cCAxMCwgMjAxOSwgYXQgMzoyNyBQTSwgTWFzYWthenUgT0hUU1VLQSAmbHQ7PGEgaHJlZj0ibWFp bHRvOm8ubWFzYWthenVAZ21haWwuY29tIiBjbGFzcz0iIj5vLm1hc2FrYXp1QGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5JIHNlZS4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZW4gaXMgdGhp cyB1bmRlcnN0YW5kYWJsZSB0byB0aGluayBmcm9tIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlcidz IHBvaW50IG9mIHZpZXcgLi4uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5JZiBwaG9uZSBiZWluZyBjb21wcm9taXNlZCBpcyBhIHRocmVh dCB0aGF0IHRoZSBDbGllbnQgY2FyZXMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFTIG1pZ2h0IGJl IGludGVyZXN0ZWQgaW4gTk9UIHN1cHBvcnRpbmcgcHVibGljIENsaWVudHMsPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPmFuZCBmb3JjaW5nIHRoZSBDbGllbnQgdG8gaGF2ZSBhIHNlcnZlciBzaWRlLCBk byBjbGllbnQgYXV0aGVudGljYXRpb24sIGFuZCBoYXZlIHNvbWUgd2F5IHRvIGhvbGQgYSBzZXNz aW9uIGJldHdlZW4gdGhlIG5hdGl2ZSBhcHAgYW5kIGl0J3Mgc2VydmVyIHNpZGUuPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CZWNhdXNl IGlmIHBob25lIGlzIGNvbXByb21pc2VkLCB3aGVuIEFTIHN1cHBvcnRzIHB1YmxpYyBDbGllbnRz IGFuZCBhY2Nlc3NfdG9rZW4gbGVha3MsIGl0J3Mga2luZCBvZiBBUydzIGZhdWx0ICh3ZWxsIGRl cGVuZGluZyBvbiB0aGUgdGVybXMuLi4pLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5idXQgaWYgd2hh dGV2ZXIgdGhlIG1lYW5zIHRoYXQgdGhlIHBob25lIGFwcCBhbmQgaXQncyBzZXJ2ZXIgc2lkZSBr ZWVwcyBhIHNlc3Npb24gbGVha3MsIGl0J3MgTk9UIHRoZSBBUydzIGZhdWx0LjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0 dHIiPk9uIFR1ZSwgU2VwIDEwLCAyMDE5IGF0IDg6MjMgUE0gTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1hcml1cy5zY3VydGVzY3VAY29pbmJhc2UuY29tIiBjbGFzcz0iIj5t YXJpdXMuc2N1cnRlc2N1QGNvaW5iYXNlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBw eCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3Bh ZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SWYgdGhlIHBob25lIGlz IGNvbXByb21pc2VkLCBvcmlnaW5hbCBhcHAgcmVwbGFjZWQgYnkgbWFsaWNpb3VzIGFwcCwgdGhl biBSRkM4MjUyIHdpbGwgbm90IGhlbHAuIFRoZSBhc3N1bXB0aW9uIGlzIHRoYXQgdGhlIHBob25l IGlzIG5vdCBjb21wcm9taXNlZC48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBUdWUsIFNl cCAxMCwgMjAxOSBhdCA5OjU4IEFNIE1hc2FrYXp1IE9IVFNVS0EgJmx0OzxhIGhyZWY9Im1haWx0 bzpvLm1hc2FrYXp1QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPm8uLm1hc2Fr YXp1QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4 O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgi Pg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SGksDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JJ3ZlIHJlYWQgcmZjODI1MiBhbmQgaGF2ZSBxdWVz dGlvbnMgYWJvdXQgbmF0aXZlIGFwcHMsIHRoYXQgSSBjb3VsZG4ndCBmaW5kIGFuc3dlcnMgb24g SW50ZXJuZXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5JbWFnaW5lIGFuIGF0dGFja2VyIGRvaW5nOjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4xLiBvcmlnaW5hbCBhcHAgYW5kIGF1dGhvcml6YXRpb24gc2VydmVy IGNvbmZvcm1zIHRvIHJmYzgyNTIgNC4xLiZuYnNwOyBBdXRob3JpemF0aW9uIEZsb3cgZm9yIE5h dGl2ZSBBcHBzIFVzaW5nIHRoZSBCcm93c2VyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjIuIGNsb25l IHRoZSBvcmlnaW5hbCBhcHAsIG5hbWUgaXQgbWFsaWNpb3VzIGFwcCBhbmQgaW5zdGFsbCBvbiB0 aGUgdGFyZ2V0IHBob25lPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjMuIHJlbW92ZSB0aGUgb3JpZ2lu YWwgYXBwIGZyb20gdGhlIHRhcmdldCBwaG9uZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj40LiB1c2Ug dGhlIG1hbGljaW91cyBhcHAgYW5kIGF1dGhvcml6ZSwgT1Mgd2lsbCBpbnZva2UgbWFsaWNpb3Vz IGFwcCB1c2luZyBjdXN0b20gVVJMIHNjaGVtZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj41LiBub3cg bWFsaWNpb3VzJm5ic3A7YXBwIGhhcyBhY2Nlc3MgdG8gdGhlIGFjY2VzcyB0b2tlbjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SG93IHNo b3VsZCB3ZSB0aGluayBhYm91dCB0aGlzPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XaGF0IGFtIEkg bWlzc2luZz88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rp dj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNs YXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8 L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpP QXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciIGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_CC052670A4A04AD69D7FDDB7096E7128mitedu_-- From nobody Sat Sep 14 22:05:35 2019 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 CFE581200EC for ; Sat, 14 Sep 2019 22:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 OvYBLJQcDfd0 for ; Sat, 14 Sep 2019 22:05:29 -0700 (PDT) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (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 4F9AB1200B8 for ; Sat, 14 Sep 2019 22:05:29 -0700 (PDT) Received: by mail-lf1-x143.google.com with SMTP id y127so1696452lfc.0 for ; Sat, 14 Sep 2019 22:05:29 -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=07GAVW7q+BJyddEdsfqylk0bxQXJzvTPXGFpu1DP7fw=; b=hE3FHPpMwvbE2HrnP1PwcAU7bzWsjeGuwH0eftj5ohjfQptNzc2Vojcupv9c9aFDrn vwkhcYlL8+g43h4gD6vA9XGevtvZYuCzvW3MW2UWqHZ9Kd+XueunOSwLqfY7Nr8EcOIU /xB6BgTllUFQFnPKIKzv/ItvK+sJDkwe0oZi9l2YmZM/iGzzKSyPi7Q6fEzbnSuSxC06 kbZPJv0GUV1wXOH2q4bjEaAYT48w2qfWEqD62nUScR4PZHYS1z9e8QS+kmF0P8qYpR72 aimYp80Q22hG/epfMVcE/Y9qUhAbslXfVZctgJ06G5fyZXDuanrilk1/9sjb/GzlMqMS CnaQ== 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=07GAVW7q+BJyddEdsfqylk0bxQXJzvTPXGFpu1DP7fw=; b=FQtbipNG+03FtFs9/ZL2511o09UFyMfgpaVEeNTi+6/xEgFGOvQiifRbduTEwMjvaC dAjrKl2ENrUh/SP9wgtHqKLAwmB0XksxkW/atRbm/hoOJ1dn3TemvnI1wEu1TM9wx+oh Xx9L16DJmxwh3bwp9zv0rvox+SO+tzfVw4s2TPxHjNn4J15dEDpao+4anPbFYsPPlmI3 2j2Tg1O36oHvlkB9s7HyUvunlIJwDOfvNIzD9JW1uteKDmLC4K8LXf7ypPJBSmCMk2Ll g3/GetrRd5XpCSmOvpcrHR/U3QWCt2b/Qoz/vfpV8pE2PSYH2qnaQv5mFNBZjR4AlQNS Mw+g== X-Gm-Message-State: APjAAAULIwfq0e6mOIMN+afR99paQfq/qgYBgkimnEaYkjqf082lvSE1 sohPVoBINFC4zOC7uxhXWGP7uisizeMiOlJOKOM= X-Google-Smtp-Source: APXvYqxvnTCja1kTa+tVWYM9QR412E5dNHkpZgiPg583pXQ6uT8CiM/BYS9yYzit3Q4QkD1WP508BNh5+fCKa5Cn7ZA= X-Received: by 2002:a19:f247:: with SMTP id d7mr27578160lfk.191.1568523927304; Sat, 14 Sep 2019 22:05:27 -0700 (PDT) MIME-Version: 1.0 References: <827BB5C3-2143-450A-BC3D-72F98CD0B475@mit.edu> In-Reply-To: <827BB5C3-2143-450A-BC3D-72F98CD0B475@mit.edu> From: Dick Hardt Date: Sat, 14 Sep 2019 22:05:16 -0700 Message-ID: To: Justin Richer Cc: =?UTF-8?Q?Robache_Herv=C3=A9?= , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008240580592906fa9" Archived-At: Subject: Re: [OAUTH-WG] Question regarding RFC 7592 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: Sun, 15 Sep 2019 05:05:33 -0000 --0000000000008240580592906fa9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Curious why the client management API uses bearer tokens rather than JWTs per RFC 7523 for the client to authenticate. The client management API seems more similar to a token endpoint than a resource. =E1=90=A7 On Fri, Sep 13, 2019 at 12:08 PM Justin Richer wrote: > Travis has this correct =E2=80=94 the =E2=80=9Cregistration access token= =E2=80=9D is passed to the > client for the express purpose of accessing the client management API, an= d > is not the same as, or entangled with, any access tokens that the client > requests through the OAuth process after the registration has occurred. T= he > reasons for this separation are many, but at the core it comes down to th= e > client always acting on its own behalf when it does registration, and > acting on behalf of some other party (usually a user) when it=E2=80=99s d= oing > OAuth. Additionally, registration management is a function of the AS, > whereas the protected APIs are a function of the RS =E2=80=94 note this i= s a > logical separation and there=E2=80=99s nothing stopping AS and RS functio= ns from > being deployed in any number of patterns. > > A few common questions we got asked when writing this functionality into > the spec: > > *Why use an access token at all*? Because it=E2=80=99s a credential for a > specific API issued by the AS and handed to the client in a programmatic > manner. This is exactly what OAuth tokens were made for. > > *Why not use the client=E2=80=99s credentials*? Because not all clients a= re set > up to have credentials, plus we=E2=80=99d be spreading the requirement to= support > different kinds of client credentials to another endpoint. > > *Why not issue an authorization code*? Because then the client would need > to make yet another round trip, and not all clients are > authorization-code-grant clients to begin with. > > *Why not make a new grant type*? Because then the client would need to > make yet another round trip, and we=E2=80=99d have to invent a whole new = grant type > with a new temporary credential when we could just use that temporary > credential directly instead. > > =E2=80=94 Justin > > On Sep 13, 2019, at 8:23 AM, Robache Herv=C3=A9 w= rote: > > Thanks Travis > > I understand that, once the client has retrieved its [client_id] through > RFC7591 initial registration, it is then able to ask for an access token > that will be used for accessing the RFC7592 entry-points. Am I right? > > Best regards > > Herv=C3=A9 > > *De :* Travis Spencer [mailto:travis.spencer@curity.io > ] > *Envoy=C3=A9 :* ven. 13 13:30 > *=C3=80 :* Robache Herv=C3=A9 > *Cc :* oauth@ietf.org > *Objet :* Re: [OAUTH-WG] Question regarding RFC 7592 > > No. The initial access token is issued by the AS when registration is > protected (appendix 1.2 in RFC 7591). As stated in section 1.2, the metho= d > and means by which this is obtained can vary. The registration access tok= en > in RFC 7592 is used to protect the registration management API and allow > updates to the client after it is registered. You might have one (the > registration access token) but not the other (initial access token) when > open registration is allowed (appendix 1.1 in RFC 7591). > > HTH! > > On Fri, Sep 13, 2019 at 7:37 AM Robache Herv=C3=A9 > wrote: > > Hi > > RFC 7592 introduces a =C2=AB Registration Access Token =C2=BB. Are this t= oken and > the way to get it similar to what is specified as =E2=80=9CInitial Access= Token=E2=80=9D in > RFC 7591/Appendix A ? > > If so, can the Open Dynamic Client Registration (RFC7591/A.1.1) be > extrapolated to RFC7592 as the same way? > > Thanks in advance for your clarification. > > Herv=C3=A9 ROBACHE > Direction Marketing et D=C3=A9veloppement > > LIGNE DIRECTE > T. +33(0)1 55 23 55 45 > herve.robache@stet.eu > > > > > > > > STET (SIEGE SOCIAL) > 100, Esplanade du G=C3=A9n=C3=A9ral de Gaulle > C=C5=93ur D=C3=A9fense =E2=80=93 Tour B > 92932 La D=C3=A9fense cedex > > www.stet.eu > > > > Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'i= ntention > exclusive de ses destinataires et sont confidentiels. > Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, > merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me et = d'en avertir > imm=C3=A9diatement l'exp=C3=A9diteur. > Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'e= st pas > conforme =C3=A0 sa destination, toute diffusion ou toute publication, tot= ale ou > partielle, est interdite. > L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de ce messag= e > =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3=A9cline toute = responsabilit=C3=A9 au > titre de ce message dans l'hypoth=C3=A8se o=C3=B9 il aurait =C3=A9t=C3=A9= modifi=C3=A9, d=C3=A9form=C3=A9 ou > falsifi=C3=A9. > N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'environneme= nt. > > This message and any attachments is intended solely for the intended > addressees and is confidential. > If you receive this message in error, or are not the intended > recipient(s), please delete it and any copies from your systems and > immediately notify the sender. > Any unauthorized view, use that does not comply with its purpose, > dissemination or disclosure, either whole or partial, is prohibited. > Since the internet cannot guarantee the integrity of this message which > may not be reliable, STET shall not be liable for the message if modified= , > changed or falsified. > Do not print this message unless it is necessary, please consider the > environment. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'i= ntention > exclusive de ses destinataires et sont confidentiels. > Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, > merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me et = d'en avertir > imm=C3=A9diatement l'exp=C3=A9diteur. > Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'e= st pas > conforme =C3=A0 sa destination, toute diffusion ou toute publication, tot= ale ou > partielle, est interdite. > L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de ce messag= e > =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3=A9cline toute = responsabilit=C3=A9 au > titre de ce message dans l'hypoth=C3=A8se o=C3=B9 il aurait =C3=A9t=C3=A9= modifi=C3=A9, d=C3=A9form=C3=A9 ou > falsifi=C3=A9. > N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'environneme= nt. > > This message and any attachments is intended solely for the intended > addressees and is confidential. > If you receive this message in error, or are not the intended > recipient(s), please delete it and any copies from your systems and > immediately notify the sender. > Any unauthorized view, use that does not comply with its purpose, > dissemination or disclosure, either whole or partial, is prohibited. > Since the internet cannot guarantee the integrity of this message which > may not be reliable, STET shall not be liable for the message if modified= , > changed or falsified. > Do not print this message unless it is necessary, please consider the > environment. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000008240580592906fa9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Curious why=C2=A0the client management API uses bearer tok= ens rather than JWTs per RFC 7523 for the client to authenticate. The clien= t management API seems more similar to a token endpoint than a resource.
3D""=E1=90=A7

On Fri, Sep 13, 2019 at 12:08 PM Justin Riche= r <jricher@mit.edu> wrote:
=
Travis has this correct =E2=80=94 the =E2=80=9Cregistration access token=E2= =80=9D is passed to the client for the express purpose of accessing the cli= ent management API, and is not the same as, or entangled with, any access t= okens that the client requests through the OAuth process after the registration has occurred. The reasons for this separation are m= any, but at the core it comes down to the client always acting on its own b= ehalf when it does registration, and acting on behalf of some other party (= usually a user) when it=E2=80=99s doing OAuth. Additionally, registration management is a function of the AS, wher= eas the protected APIs are a function of the RS =E2=80=94 note this is a lo= gical separation and there=E2=80=99s nothing stopping AS and RS functions f= rom being deployed in any number of patterns.=C2=A0

A few common questions we got asked when writing this functionality in= to the spec:

Why use an access token at all? Because it=E2=80=99s a credenti= al for a specific API issued by the AS and handed to the client in a progra= mmatic manner. This is exactly what OAuth tokens were made for.=C2=A0

Why not use the client=E2=80=99s credentials? Because not all c= lients are set up to have credentials, plus we=E2=80=99d be spreading the r= equirement to support different kinds of client credentials to another endp= oint.=C2=A0

Why not issue an authorization code? Because then the client wo= uld need to make yet another round trip, and not all clients are authorizat= ion-code-grant clients to begin with.=C2=A0

Why not make a new grant type? Because then the client would ne= ed to make yet another round trip, and we=E2=80=99d have to invent a whole = new grant type with a new temporary credential when we could just use that = temporary credential directly instead.=C2=A0

=E2=80=94 Justin

On Sep 13, 2019, at 8:23 AM, Robache Herv=C3=A9 <herve.robache@stet.eu> wrot= e:

Thanks Travis
=C2=A0
I understand that, once the client has retrieved its= [client_id] through RFC7591 initial registration, it is then able to ask f= or an access token that will be used for accessing the RFC7592 entry-points. Am I right?
=C2=A0
Best regards
=C2=A0
Herv=C3=A9
=C2=A0
De=C2=A0:=C2=A0T= ravis Spencer [mailto:travis.spencer@cu= rity.io]=C2=A0
Envoy=C3=A9=C2=A0:=C2=A0ven. 13 13:30
=C3=80=C2=A0:=C2=A0Robache Herv=C3=A9
Cc=C2=A0:=C2=A0oauth@ietf.org
Objet=C2=A0:=C2=A0Re: [OAUTH-WG] Question regarding RFC 7592=
=C2=A0
No. The initial access token is issued by the AS when registration is prote= cted (appendix 1.2 in RFC 7591). As stated in section 1.2, the method and m= eans by which this is obtained can vary. The registration access token in R= FC 7592 is used to protect the registration management API and allow updates to the client after it is registered. You= might have one (the registration access token) but not the other (initial = access token) when open registration is allowed (appendix 1.1 in RFC 7591).=
=C2=A0
HTH!
=C2=A0
On Fri, Sep 13, 2019 at 7:37 AM Robache Herv=C3=A9 <herve.robache@stet.eu> wrote:
Hi
=C2=A0
RFC 7592 introduces a =C2=AB=C2=A0Registration Access = Token=C2=A0=C2=BB. Are this token and the way to get it similar to what is = specified as =E2=80=9CInitial Access Token=E2=80=9D in RFC 7591/Appendix A = ?
=C2=A0
If so, can the Open Dynamic Client Registration (RFC75= 91/A.1.1) be extrapolated to RFC7592 as the same way?<= /div>
=C2=A0
Thanks in advance for your clarification.
=C2=A0
Herv=C3=A9 ROBACHE
Direction Marketing et D=C3=A9veloppement<= /div>
=C2=A0
LIGNE DIRECTE
T. +33(0)1 55 23= 55 45
=C2=A0
<image001.png>
=C2=A0
=C2=A0

<image002.png>=
=C2=A0
STET (SIEGE SOCI= AL)
100, Esplanade d= u G=C3=A9n=C3=A9ral de Gaulle
C=C5=93ur D=C3= =A9fense =E2=80=93 Tour B
92932 La D=C3=A9= fense cedex
=C2=A0=
=C2=A0

Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'= ;intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me = et d'en avertir imm=C3=A9diatement l'exp=C3=A9diteur.
Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'= ;est pas conforme =C3=A0 sa destination, toute diffusion ou toute publicati= on, totale ou partielle, est interdite.
L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de= ce message =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3= =A9cline toute responsabilit=C3=A9 au titre de ce message dans l'hypoth= =C3=A8se o=C3=B9 il aurait =C3=A9t=C3=A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou= falsifi=C3=A9.
N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'envir= onnement.

This message and any attachments is intended solely for the intended addres= sees and is confidential.
If you receive this message in error, or are not the intended recipient(s),= please delete it and any copies from your systems and immediately notify t= he sender.
Any unauthorized view, use that does not comply with its purpose, dissemina= tion or disclosure, either whole or partial, is prohibited.
Since the internet cannot guarantee the integrity of this message which may= not be reliable, STET shall not be liable for the message if modified, cha= nged or falsified.
Do not print this message unless it is necessary, please consider the envir= onment.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailma= n/listinfo/oauth


Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'= ;intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me = et d'en avertir imm=C3=A9diatement l'exp=C3=A9diteur.
Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'= ;est pas conforme =C3=A0 sa destination, toute diffusion ou toute publicati= on, totale ou partielle, est interdite.
L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de= ce message =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3= =A9cline toute responsabilit=C3=A9 au titre de ce message dans l'hypoth= =C3=A8se o=C3=B9 il aurait =C3=A9t=C3=A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou= falsifi=C3=A9.
N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'envir= onnement.

This message and any attachments is intended solely for the intended addres= sees and is confidential.
If you receive this message in error, or are not the intended recipient(s),= please delete it and any copies from your systems and immediately notify t= he sender.
Any unauthorized view, use that does not comply with its purpose, dissemina= tion or disclosure, either whole or partial, is prohibited.
Since the internet cannot guarantee the integrity of this message which may= not be reliable, STET shall not be liable for the message if modified, cha= nged or falsified.
Do not print this message unless it is necessary, please consider the envir= onment.
______________________________________= _________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000008240580592906fa9-- From nobody Mon Sep 16 01:26:42 2019 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 BF11112081C for ; Mon, 16 Sep 2019 01:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_HEX=0.1, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" 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 10BGOgnUS8mD for ; Mon, 16 Sep 2019 01:26:35 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650136.outbound.protection.outlook.com [40.107.65.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C4912003F for ; Mon, 16 Sep 2019 01:26:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CZm90atxaMqXfhBVHdbCUYukZxKTks/HnvkewP+RzkeOSqRLeBcLHQZhvqHaa04HJfk5Dn9fiqwoAsvcjKTOuM9gEUSji4zBWklHI+FM4tbtG655rP0Hc1LC/GxFhGu02qOojXwEF3J2HkC2G/9e3cvA+wZ2B7u6SJKMn0P/uSSA423pkJyy6IddGAM+eFMmBRwI9b/31JSrM11iZpPStrnW94XJu0cJ4tpVQzv+B2SbWYydDuO9kjhV5SmdoONNhZdP7ZmBmeACwVNUzeLglb4N4VG/Dzl1/HjyjiieZdQXOvm8IGlyfOmmugfyR8/ESpKkjOv/FK9zZWwsNA+wJQ== 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=RtBsGJN59PDMpql244Rs9tQS8ZEBlsQDb9Kfp0J+IV4=; b=kKLe1IPnr1D7wLE5or73YIxuhZXZbB9o5NzWmZWvdvs0zYRl82o9H8XBK08d6fD1O9Y3BgX9RfTKVv8v+Cm5tgX00gRuuV6ex2sTvstFJf2zL/J6WIcniszjWEGaKZtZN5hMaZRBMu/X0d3hhnXYCIEZx3xSIl0b97jd5CggklE+hk6Te8Ou9WkTL1EGI+1F7Mb9xI6TT4k6ZLhb9dxXsKIFAI3+0TcZxmIhB+Wsrchjop/tjPUXxccsXbITEVewVJR5RBoZj0dnHqds4MTe+enYpSFBietTqCaxWyb6I49lWKzLMcYBeDy5JCJWFvi4AlIvPFczHlfsB85noqOs7Q== 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=RtBsGJN59PDMpql244Rs9tQS8ZEBlsQDb9Kfp0J+IV4=; b=EBFyZutowaj3puZBMvtIRAJftx7I3n4duo/0+FKtvYYBvMoSInBci2Hpdn8216nWrzS/8yAQC/qgk+QwhXUIuHDQasJSeAobWhMuc5v+rQhc7V1/Y5sJa82AXY5kXd40DIb19tkqSJXYfxh7L/XcUnyaQzByrEUf4RMOKg6QmTc= Received: from BN8PR00MB0563.namprd00.prod.outlook.com (20.179.72.150) by BN8PR00MB0596.namprd00.prod.outlook.com (20.179.73.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2318.0; Mon, 16 Sep 2019 08:26:17 +0000 Received: from BN8PR00MB0563.namprd00.prod.outlook.com ([fe80::1cd4:f80c:1b74:ac73]) by BN8PR00MB0563.namprd00.prod.outlook.com ([fe80::1cd4:f80c:1b74:ac73%6]) with mapi id 15.20.2317.000; Mon, 16 Sep 2019 08:26:17 +0000 From: Mike Jones To: Steinar Noem CC: OAuth WG Thread-Topic: [OAUTH-WG] Location and dates for next OAuth Security Workshop Thread-Index: AQHVQxqshJj3poXQ7kyrl2GRFBbzo6bbummAgAAIf4CAAAGnMIAArHQAgBN92ICAAPVUgIAAYv8AgAACFYCAAuJgAIAAmjgAgAMl0wCANl41kA== Date: Mon, 16 Sep 2019 08:26:17 +0000 Message-ID: References: <34add299-ae88-4c6f-a33c-82c147549516@yes.com> <119995fd-caad-c29d-7a8c-7eafe38054a0@yes.com> In-Reply-To: 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=eb358003-fdaf-4447-a218-0000fb706430; 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=2019-09-16T08:23:42Z; 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: [202.178.111.233] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8b7c8c52-f774-41ba-16cf-08d73a7f8ba6 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: BN8PR00MB0596: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2043; x-forefront-prvs: 0162ACCC24 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(39860400002)(376002)(396003)(136003)(366004)(13464003)(53754006)(189003)(199004)(236005)(66446008)(54896002)(81156014)(6306002)(81166006)(9686003)(8676002)(52536014)(7110500001)(66574012)(8936002)(55016002)(229853002)(71200400001)(71190400001)(66946007)(76116006)(66476007)(66556008)(64756008)(6246003)(22452003)(53936002)(6436002)(15650500001)(316002)(2420400007)(478600001)(186003)(66066001)(966005)(790700001)(10290500003)(6116002)(25786009)(476003)(446003)(486006)(3846002)(11346002)(606006)(99286004)(6916009)(10090500001)(5070765005)(7696005)(8990500004)(26005)(102836004)(14454004)(76176011)(6506007)(53546011)(86362001)(7736002)(33656002)(5660300002)(2906002)(4326008)(74316002)(256004)(14444005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN8PR00MB0596; H:BN8PR00MB0563.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; 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: eD8y5tZm606mwJEGlRR860O/bpnjebXnlBKz4eQnjTlWBJyLPUl43liY5iibYpPorCc01Gba1c3Cb8obNqJeg+NRHNiXXlkRZfYmOB+IuFbna6I/8ERwz6d+ulh29XNzh23WmVKOWERHKopxMk8gWLEuiWsLieYO1IPsObLd4ikK+VobAP0CYGFEZpRcD+YEqg6XhH5SPM6GBYoKLkabSTEH1CpnK8xcz0/whT1LqHRFQa5VAWFYP1x2+STIlWrRUVEasVh6u9IY6g2GyVKGrKVh/wvr8WqDDKxMIjbS3ZFULSdgS0pwwVkzE5NGOpmwbtCepXSfMowJtxvvVMa5ZeL44ckBCI0fkhw+Ty/pHn4LhB/fp3KPqY6JtkxRDyf92GN11W70aUkY0lXMO50aoYKBT5fjH24padH3UqPz4NA= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN8PR00MB0563A1FF7033191EC614AA3AF58C0BN8PR00MB0563namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8b7c8c52-f774-41ba-16cf-08d73a7f8ba6 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2019 08:26:17.3420 (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: nLs4yLoPPOWMhP57fXZraludpEARIHDBgdK6NhbAyEmoCmhVcYK+V+8x8ubVgALhTLc4axbUggRQMTeIJqw6og== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR00MB0596 Archived-At: Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop 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 Sep 2019 08:26:39 -0000 --_000_BN8PR00MB0563A1FF7033191EC614AA3AF58C0BN8PR00MB0563namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Have we chosen a date and location? I'd like to put it in my calendar to h= elp other conferences being scheduled to avoid those dates. Thanks, -- Mike From: Anthony Nadalin Sent: Monday, August 12, 2019 11:09 AM To: Steinar Noem ; Nat Sakimura Cc: Mike Jones ; OAuth WG Subject: RE: [OAUTH-WG] Location and dates for next OAuth Security Workshop I know you were too polite ! From: Steinar Noem > Sent: Saturday, August 10, 2019 11:04 AM To: Nat Sakimura > Cc: Anthony Nadalin >; = Mike Jones = >; OAuth WG > Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop That is good to hear, Nat. I tried to be as polite as possible in my response. l=F8r. 10. aug. 2019 kl. 10:52 skrev Nat Sakimura >: I think Tony was just joking as it was quite a hassle for both of us to get= to Gj=F8vik for an ISO meeting. On Thu, Aug 8, 2019 at 9:50 PM Steinar Noem > wrote: Hey Anthony. Gj=F8vik is part of NTNU, we are waiting for feedback from the= m :) I think Trondheim is more accessible (travel time) and has more to offer. tor. 8. aug. 2019 kl. 14:42 skrev Anthony Nadalin >: How about the University in Gjovik ? Get Outlook for Android ________________________________ From: OAuth > on beha= lf of Daniel Fett > Sent: Wednesday, August 7, 2019 11:47:51 PM To: Dick Hardt >; dbaier@= leastprivilege.com > Cc: Mike Jones >; OAuth WG > Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop Not yet, we are talking to potential venues. It's vacation time in Norway r= ight now, so that will take a week or two more. -Daniel Am 07.08.19 um 18:09 schrieb Dick Hardt: Are we ready to pick a date? On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier > wrote: August will conflict with holiday time for most Europeans... Just been to Trondheim last week - it was lovely weather. --- Dominick On 25. July 2019 at 22:14:28, Mike Jones (michael.jones=3D40microsoft.com@d= marc.ietf.org) wrote= : I'm not aware of any conflicts for any of the three sets of dates. -- Mike -----Original Message----- From: OAuth > On Beha= lf Of Aaron Parecki Sent: Thursday, July 25, 2019 4:07 PM To: Dick Hardt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop We'll be so productive with only 4 hours of darkness every day! All of the dates work for me, but I would prefer the July dates since it'll= be easier/cheaper to bundle the two trips into one. (Hopefully we could ge= t the OAuth meeting dates early in the week at IETF then) On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt > wrote: > > +1 to July / August. Nicer weather in the north then. =3D) > > On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett > wrote: >> >> Hi all, >> >> it seems like there is a rough consensus on having the next OAuth Securi= ty Workshop in Trondheim, Norway. We will therefore start with the planning= . >> >> After checking various event calendars it seems like the following dates= are suitable: >> >> May 7-9 >> >> July 22-24 >> >> August 3-5 >> >> First date is before EIC '20 which is May 12-15 in Munich/Germany. The l= atter two dates are before/after IETF 108 which is July 25-31, Madrid/Spain= . >> >> Unless somebody raises objections because of conflicting identity/securi= ty events we will pick one of these dates in the next two weeks or so.... >> >> -Daniel >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www >> .ietf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%= 7CMichael.Jon >> es%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be7= 7f%7C72f988bf86f14 >> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGW >> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=3D0 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www. > ietf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7CMi= chael.Jones > %40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C= 72f988bf86f141af > 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGWSRXy > rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=3D0 _______________________________________________ OAuth mailing list OAuth@ietf.org https://nam06...safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jones%40m= icrosoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd= 011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGWSRXyrzs4V%2BWMXc= MD482nhyARt28me4xbE%3D&reserved=3D0 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en -- Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | --_000_BN8PR00MB0563A1FF7033191EC614AA3AF58C0BN8PR00MB0563namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Have we chosen a date = and location?  I’d like to put it in my calendar to help other c= onferences being scheduled to avoid those dates.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; Thanks,

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

From: Anthony Nadalin <tonynad@microsoft.c= om>
Sent: Monday, August 12, 2019 11:09 AM
To: Steinar Noem <steinar@udelt.no>; Nat Sakimura <sakimura= @gmail.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; OAuth WG <oau= th@ietf.org>
Subject: RE: [OAUTH-WG] Location and dates for next OAuth Security W= orkshop

 

I know you were too polite !

 

From: Steinar Noem <steinar@udelt.no>
Sent: Saturday, August 10, 2019 11:04 AM
To: Nat Sakimura <sakimura@= gmail.com>
Cc: Anthony Nadalin <ton= ynad@microsoft.com>; Mike Jones <Michael.Jones@microsoft.com>; OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security W= orkshop

 

That is good to hear, Nat.

I tried to be as polite as possible in my response.<= o:p>

 

l=F8r. 10. aug. 2019 kl. 10:52 skrev Nat Sakimura &l= t;sakimura@gmail.com>:

I think Tony was just joking as it was quite a hassl= e for both of us to get to Gj=F8vik for an ISO meeting. 

 

On Thu, Aug 8, 2019 at 9:50 PM Steinar Noem <steinar@udelt.no> = wrote:

Hey Anthony. Gj=F8vik is part of NTNU, we are waitin= g for feedback from them :)

 

I think Trondheim is more accessible (travel time) a= nd has more to offer.

 

tor. 8. aug. 2019 kl. 14:42 skrev Anthony Nadalin &l= t;tonynad=3D40microsoft.com@dmarc.ietf.org>:

How about the University in= Gjovik ?

From: OAuth <oauth-bounces@ietf.org> on behalf of Daniel Fett = <danielf= 3;oauth@yes.com>
Sent: Wednesday, August 7, 2019 11:47:51 PM
To: Dick Hardt <dick.hardt@gmail.com>; dbaier@least= privilege.com <dbaier@leastprivilege.com>
Cc: Mike Jones <michael.jones=3D40microsoft.com@dmarc.ietf.org>; = OAuth WG <oauth@ietf= ...org>


Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security W= orkshop

 

Not yet, we are talking to potential venues. It's va= cation time in Norway right now, so that will take a week or two more.=

 

-Daniel

 

Am 07.08.19 um 18:09 schrieb Dick Hardt:<= /p>

Are we ready to pick a date?

 

On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier <= dbaier@least= privilege.com> wrote:

August will conflict with holiday time for most E= uropeans…

 

Just been to Trondheim last week - it was lovely = weather.

 

———

Dominick

 

On 25. July 2019 at 22:14:28, Mike Jones (michael.jones=3D40micr= osoft.com@dmarc.ietf.org) wrote:

I'm not aware of any conflicts for any of the three = sets of dates.

-- Mike

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki
Sent: Thursday, July 25, 2019 4:07 PM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: OAuth WG <oauth@= ietf.org>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop=

We'll be so productive with only 4 hours of darkness every day!

All of the dates work for me, but I would prefer the July dates since it'll= be easier/cheaper to bundle the two trips into one. (Hopefully we could ge= t the OAuth meeting dates early in the week at IETF then)

On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>
> +1 to July / August. Nicer weather in the north then. =3D)
>
> On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett <danielf+oauth@yes.com> w= rote:
>>
>> Hi all,
>>
>> it seems like there is a rough consensus on having the next OAuth = Security Workshop in Trondheim, Norway. We will therefore start with the pl= anning.
>>
>> After checking various event calendars it seems like the following= dates are suitable:
>>
>> May 7-9
>>
>> July 22-24
>>
>> August 3-5
>>
>> First date is before EIC ‘20 which is May 12-15 in Munich/Ge= rmany. The latter two dates are before/after IETF 108 which is July 25-31, = Madrid/Spain.
>>

>> Unless somebody raises objections because o= f conflicting identity/security events we will pick one of these dates in t= he next two weeks or so....

>>
>> -Daniel
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www
>> .ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=3D02%7C01%7CMichael.Jon
>> es%40= microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=3Dd= AokWYxwGW
>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.
> ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=3D02%7C01%7CMichael.= Jones
> %40microso= ft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=3DdAokWYxw= GWSRXy
> rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://nam06...safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=3D02%7C01%7= CMichael.Jones%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988b= f86f141af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=3DdAok= WYxwGWSRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--

Vennlig hilsen<= span style=3D"color:#500050">

 

Steinar Noem

Partner Udelt AS<= /o:p>

Systemutvikler

 

| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |&n= bsp;

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /p>


 

--

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://= nat.sakimura.org/
@_nat_en

--

Vennlig hilsen<= span style=3D"color:#500050">

 

Steinar Noem

Partner Udelt AS<= /o:p>

Systemutvikler

 

| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |&nb= sp;

--_000_BN8PR00MB0563A1FF7033191EC614AA3AF58C0BN8PR00MB0563namp_-- From nobody Mon Sep 16 01:35:07 2019 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 E0861120827 for ; Mon, 16 Sep 2019 01:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URI_HEX=0.1, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yes.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 3FmBhisSBO3b for ; Mon, 16 Sep 2019 01:35:02 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 B3D9B120825 for ; Mon, 16 Sep 2019 01:35:01 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id c20so23291643eds.1 for ; Mon, 16 Sep 2019 01:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=bTGk3P4nqPrIATQORURI3BZ+JVpzRzU1p61/b0ln2to=; b=wgryiEy4brYq+tXFLiSsg5HeI0/esTKR+vlFItZciVx9dRbfFT5l4HoZsd79odO3/X Bva6PgXu26ODA1JYmZ3N+g3+IOLjy1DgE8lhJ73xcjQKbLtf0QPY4SuFxsH9PW46Rinw 0efawJc57QmxZ3z2Mg99QstDaKOu20cK1SO2h0h/40bVsd69FQrcYKUyRELghUZe9NP4 kSQbvc9UgsoydaKvbJfbR9SeB542sq3OwakdM5enuvQf0yYBKRrqenuRAfOrGVkKgee7 224Jgkj3YpD2VYvmQzA8OiXpJ9ZqsNtlrJwhBT6iXFr8ngkrIY+25QftJXMcXPsKogDb 0D4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=bTGk3P4nqPrIATQORURI3BZ+JVpzRzU1p61/b0ln2to=; b=snXYNDkPIrsPbUvTWAR7zh+T/FnvDTn+w8zjVIHxjsglhd/Tm9Jce83tVcybP6G2/H TXWuoUJwvDwlQQlJL0zOtmu+l772Kyhl2kGRinSsusngS7Slp8lukjE2u+2VdTb2fHhv qTGaq52VIY2Wn8xUfOLMf2GLohqAUUGjs7vxS3Wna2ceOOkq5o5/Xb2R6oNm45Ez9Gii NJw3euxhC2o83zaToOAGUE+vfmoMs+K8QZmhbWDzPCRm5OUVP5gpO1EXLdDw4lAVXRKc MKfsLg7qFOthBWNWbtuwn81gEGwerhEUciSou1iYF+SWnMtJtfsnx7Xs1jdKJZ6GXdkq rDdQ== X-Gm-Message-State: APjAAAV4qZ8Ei6TruHuMcpDyVJDsOSJBjDOVhNYK5TTdt039yjzO8Rn2 oI8qv2NR1zwlcjKNUL/TkhcXDbiqm5Q= X-Google-Smtp-Source: APXvYqwUwzznhFUsQN9XA4UY5z2imFay+y+uiv0g9uya86L6tM+qvb1vuWoT5xDqjcEHQ4FNZCj3eg== X-Received: by 2002:a50:981b:: with SMTP id g27mr60594014edb.105.1568622899749; Mon, 16 Sep 2019 01:34:59 -0700 (PDT) Received: from ?IPv6:2001:16b8:1c80:3000:e09c:f4e2:f1a7:d5c2? ([2001:16b8:1c80:3000:e09c:f4e2:f1a7:d5c2]) by smtp.gmail.com with ESMTPSA id c1sm6891119edd.21.2019.09.16.01.34.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Sep 2019 01:34:58 -0700 (PDT) To: oauth@ietf.org References: <34add299-ae88-4c6f-a33c-82c147549516@yes.com> <119995fd-caad-c29d-7a8c-7eafe38054a0@yes.com> From: Daniel Fett Message-ID: Date: Mon, 16 Sep 2019 10:34:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BFC8B6E12D9E699E11E4DDC5" Content-Language: de-DE Archived-At: Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop 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 Sep 2019 08:35:06 -0000 This is a multi-part message in MIME format. --------------BFC8B6E12D9E699E11E4DDC5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Yes, see my mail from about a month ago. It's July 22-24, 2020 in Trondheim, Norway. -Daniel Am 16.09.19 um 10:26 schrieb Mike Jones: > > Have we chosen a date and location?  I’d like to put it in my calendar > to help other conferences being scheduled to avoid those dates. > >   > >                                                        Thanks, > >                                                        -- Mike > >   > > *From:* Anthony Nadalin > *Sent:* Monday, August 12, 2019 11:09 AM > *To:* Steinar Noem ; Nat Sakimura > *Cc:* Mike Jones ; OAuth WG > *Subject:* RE: [OAUTH-WG] Location and dates for next OAuth Security > Workshop > >   > > I know you were too polite ! > >   > > *From:* Steinar Noem > > *Sent:* Saturday, August 10, 2019 11:04 AM > *To:* Nat Sakimura > > *Cc:* Anthony Nadalin >; Mike Jones > >; > OAuth WG > > *Subject:* Re: [OAUTH-WG] Location and dates for next OAuth Security > Workshop > >   > > That is good to hear, Nat. > > I tried to be as polite as possible in my response. > >   > > lør. 10. aug. 2019 kl. 10:52 skrev Nat Sakimura >: > > I think Tony was just joking as it was quite a hassle for both of > us to get to Gjøvik for an ISO meeting.  > >   > > On Thu, Aug 8, 2019 at 9:50 PM Steinar Noem > wrote: > > Hey Anthony. Gjøvik is part of NTNU, we are waiting for > feedback from them :) > >   > > I think Trondheim is more accessible (travel time) and has > more to offer. > >   > > tor. 8. aug. 2019 kl. 14:42 skrev Anthony Nadalin > >: > > How about the University in Gjovik ? > > Get Outlook for Android > >   > > ------------------------------------------------------------------------ > > *From:*OAuth > on behalf of Daniel Fett > > > *Sent:* Wednesday, August 7, 2019 11:47:51 PM > *To:* Dick Hardt >; dbaier@leastprivilege.com > > > > *Cc:* Mike Jones > >; OAuth WG > > > > > *Subject:* Re: [OAUTH-WG] Location and dates for next > OAuth Security Workshop > >   > > Not yet, we are talking to potential venues. It's vacation > time in Norway right now, so that will take a week or two > more. > >   > > -Daniel > >   > > Am 07.08.19 um 18:09 schrieb Dick Hardt: > > Are we ready to pick a date? > >   > > On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier > > wrote: > > August will conflict with holiday time for most > Europeans… > >   > > Just been to Trondheim last week - it was lovely > weather. > >   > > ——— > > Dominick > >   > > On 25. July 2019 at 22:14:28, Mike Jones > (michael.jones=40microsoft.com@dmarc.ietf.org > ) > wrote: > > I'm not aware of any conflicts for any of the > three sets of dates. > > -- Mike > > -----Original Message----- > From: OAuth > On Behalf Of > Aaron Parecki > Sent: Thursday, July 25, 2019 4:07 PM > To: Dick Hardt > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] Location and dates for > next OAuth Security Workshop > > We'll be so productive with only 4 hours of > darkness every day! > > All of the dates work for me, but I would > prefer the July dates since it'll be > easier/cheaper to bundle the two trips into > one. (Hopefully we could get the OAuth meeting > dates early in the week at IETF then) > > On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt > > wrote: > > > > +1 to July / August. Nicer weather in the > north then. =) > > > > On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett > > wrote: > >> > >> Hi all, > >> > >> it seems like there is a rough consensus on > having the next OAuth Security Workshop in > Trondheim, Norway. We will therefore start > with the planning. > >> > >> After checking various event calendars it > seems like the following dates are suitable: > >> > >> May 7-9 > >> > >> July 22-24 > >> > >> August 3-5 > >> > >> First date is before EIC ‘20 which is May > 12-15 in Munich/Germany. The latter two dates > are before/after IETF 108 which is July 25-31, > Madrid/Spain. > >> > > >> Unless somebody raises objections because > of conflicting identity/security events we > will pick one of these dates in the next two > weeks or so.... > > >> > >> -Daniel > >> > >> > _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www > >> .ietf.org > %2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jon > > >> es%40microsoft.com > %7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14 > > >> > 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGW > >> > SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0 > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www. > > ietf.org > %2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones > > > %40microsoft.com > %7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af > > > > 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGWSRXy > > > rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://nam06...safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGWSRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0 > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > >   > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > -- > > Vennlig hilsen > >   > > Steinar Noem > > Partner Udelt AS > > Systemutvikler > >   > > | steinar@udelt.no  | hei@udelt.no >   | +47 955 21 620 | www.udelt.no >  |  > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > >   > > -- > > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > > @_nat_en > > -- > > Vennlig hilsen > >   > > Steinar Noem > > Partner Udelt AS > > Systemutvikler > >   > > | steinar@udelt.no  | hei@udelt.no >   | +47 955 21 620 | www.udelt.no >  |  > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------BFC8B6E12D9E699E11E4DDC5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Yes, see my mail from about a month ago. It's July 22-24, 2020 in Trondheim, Norway.

-Daniel

Am 16.09.19 um 10:26 schrieb Mike Jones:

Have we chosen a date and location?  I’d like to put it in my calendar to help other conferences being scheduled to avoid those dates.

 

                                                       Thanks,

                                                       -- Mike

 

From: Anthony Nadalin <tonynad@microsoft.com>
Sent: Monday, August 12, 2019 11:09 AM
To: Steinar Noem <steinar@udelt.no>; Nat Sakimura <sakimura@gmail.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; OAuth WG <oauth@ietf.org>
Subject: RE: [OAUTH-WG] Location and dates for next OAuth Security Workshop

 

I know you were too polite !

 

From: Steinar Noem <steinar@udelt.no>
Sent: Saturday, August 10, 2019 11:04 AM
To: Nat Sakimura <sakimura@gmail.com>
Cc: Anthony Nadalin <tonynad@microsoft.com>; Mike Jones <Michael.Jones@microsoft.com>; OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

 

That is good to hear, Nat.

I tried to be as polite as possible in my response.

 

lør. 10. aug. 2019 kl. 10:52 skrev Nat Sakimura <sakimura@gmail.com>:

I think Tony was just joking as it was quite a hassle for both of us to get to Gjøvik for an ISO meeting. 

 

On Thu, Aug 8, 2019 at 9:50 PM Steinar Noem <steinar@udelt.no> wrote:

Hey Anthony. Gjøvik is part of NTNU, we are waiting for feedback from them :)

 

I think Trondheim is more accessible (travel time) and has more to offer.

 

tor. 8. aug. 2019 kl. 14:42 skrev Anthony Nadalin <tonynad=40microsoft.com@dmarc.ietf.org>:

How about the University in Gjovik ?

From: OAuth <oauth-bounces@ietf.org> on behalf of Daniel Fett <danielf+oauth@yes.com>
Sent: Wednesday, August 7, 2019 11:47:51 PM
To: Dick Hardt <dick.hardt@gmail.com>; dbaier@leastprivilege.com <dbaier@leastprivilege.com>
Cc: Mike Jones <michael.jones=40microsoft.com@dmarc.ietf.org>; OAuth WG <oauth@ietf....org>


Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

 

Not yet, we are talking to potential venues. It's vacation time in Norway right now, so that will take a week or two more.

 

-Daniel

 

Am 07.08.19 um 18:09 schrieb Dick Hardt:

Are we ready to pick a date?

 

On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier <dbaier@leastprivilege.com> wrote:

August will conflict with holiday time for most Europeans…

 

Just been to Trondheim last week - it was lovely weather.

 

———

Dominick

 

On 25. July 2019 at 22:14:28, Mike Jones (michael.jones=40microsoft.com@dmarc.ietf.org) wrote:

I'm not aware of any conflicts for any of the three sets of dates.

-- Mike

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki
Sent: Thursday, July 25, 2019 4:07 PM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

We'll be so productive with only 4 hours of darkness every day!

All of the dates work for me, but I would prefer the July dates since it'll be easier/cheaper to bundle the two trips into one. (Hopefully we could get the OAuth meeting dates early in the week at IETF then)

On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>
> +1 to July / August. Nicer weather in the north then. =)
>
> On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett <danielf+oauth@yes.com> wrote:
>>
>> Hi all,
>>
>> it seems like there is a rough consensus on having the next OAuth Security Workshop in Trondheim, Norway. We will therefore start with the planning.
>>
>> After checking various event calendars it seems like the following dates are suitable:
>>
>> May 7-9
>>
>> July 22-24
>>
>> August 3-5
>>
>> First date is before EIC ‘20 which is May 12-15 in Munich/Germany. The latter two dates are before/after IETF 108 which is July 25-31, Madrid/Spain.
>>

>> Unless somebody raises objections because of conflicting identity/security events we will pick one of these dates in the next two weeks or so....

>>
>> -Daniel
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www
>> .ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=02%7C01%7CMichael.Jon
>> es%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=dAokWYxwGW
>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=0
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.
> ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=02%7C01%7CMichael.Jones
> %40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=dAokWYxwGWSRXy
> rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://nam06...safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=dAokWYxwGWSRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--

Vennlig hilsen

 

Steinar Noem

Partner Udelt AS

Systemutvikler

 

| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no | 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


 

--

Nat Sakimura (=nat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--

Vennlig hilsen

 

Steinar Noem

Partner Udelt AS

Systemutvikler

 

| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no | 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--------------BFC8B6E12D9E699E11E4DDC5-- From nobody Mon Sep 16 19:36:45 2019 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 62E5E1200F3 for ; Mon, 16 Sep 2019 19:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 AwLbm3wbVidY for ; Mon, 16 Sep 2019 19:36:39 -0700 (PDT) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (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 30962120154 for ; Mon, 16 Sep 2019 19:36:38 -0700 (PDT) Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id x8H2aLbe025056; Mon, 16 Sep 2019 22:36:37 -0400 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 16 Sep 2019 22:36:12 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 16 Sep 2019 22:36:28 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Mon, 16 Sep 2019 22:36:28 -0400 From: Justin Richer To: Dick Hardt CC: =?utf-8?B?Um9iYWNoZSBIZXJ2w6k=?= , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Question regarding RFC 7592 Thread-Index: AdVpeCBmbn8uFGEHRDSH6fb8upwECQAz/ZmAAAHfXwAADiIAAABHJRgAAF9ir4A= Date: Tue, 17 Sep 2019 02:36:28 +0000 Message-ID: <1BEA1464-9B31-4FBF-8619-16096F13BBDD@mit.edu> References: <827BB5C3-2143-450A-BC3D-72F98CD0B475@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_1BEA14649B314FBF861916096F13BBDDmitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Question regarding RFC 7592 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: Tue, 17 Sep 2019 02:36:43 -0000 --_000_1BEA14649B314FBF861916096F13BBDDmitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHNlZSBhIHJlYXNvbiB0byB1c2UgYW4gYXNzZXJ0aW9uIGhlcmUuIEpXVCBhdXRo ZW50aWNhdGlvbiB3b3VsZCByZXF1aXJlIGF0IGxlYXN0IGEgc2VjcmV0IGlmIG5vdCBhIGtleSBv ZiBzb21lIHR5cGUgZm9yIGF1dGhlbnRpY2F0aW9uIGZvciBhbGwgY2xpZW50cywgYW5kIGl0IHdh cyBkZXRlcm1pbmVkIHRoYXQgZHluYW1pYyByZWdpc3RyYXRpb24gc2hvdWxkbuKAmXQgcmVxdWly ZSB0aGUgY2xpZW50cyAoZXZlbiBwdWJsaWMgY2xpZW50cykgdG8gc3VwcG9ydCB0aGluZ3MgdGhl eSB3ZXJlbuKAmXQgYWxyZWFkeSBjYXBhYmxlIG9mIGRvaW5nLiBCZXNpZGVzLCB0aGUgbWFuYWdl bWVudCBlbmRwb2ludCBpc27igJl0IGEgdG9rZW4gZW5kcG9pbnQgKHRob3VnaCBJ4oCZbSBjdXJp b3VzIHRvIGhlYXIgd2h5IHlvdeKAmWQgc2F5IHRoYXQpIOKAlCBpdOKAmXMgYW4gQVBJIHlvdSBj YW4gY2FsbCB0byBtYW5hZ2UgYSBjbGllbnTigJlzIHJlZ2lzdHJhdGlvbiBkYXRhIG92ZXIgdGlt ZS4gU291bmRzIGxpa2UgYW4gUlMsIGlmIHlvdSBhc2sgbWUuDQoNCuKAlCBKdXN0aW4NCg0KT24g U2VwIDE1LCAyMDE5LCBhdCAxOjA1IEFNLCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNv bTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCg0KQ3VyaW91cyB3aHkgdGhl IGNsaWVudCBtYW5hZ2VtZW50IEFQSSB1c2VzIGJlYXJlciB0b2tlbnMgcmF0aGVyIHRoYW4gSldU cyBwZXIgUkZDIDc1MjMgZm9yIHRoZSBjbGllbnQgdG8gYXV0aGVudGljYXRlLiBUaGUgY2xpZW50 IG1hbmFnZW1lbnQgQVBJIHNlZW1zIG1vcmUgc2ltaWxhciB0byBhIHRva2VuIGVuZHBvaW50IHRo YW4gYSByZXNvdXJjZS4NCltodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9 YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZ0eXBlPXplcm9jb250ZW50Jmd1aWQ9NWM0 YmJjODAtMWYwMC00MzUxLTlhOWItOTU0ODA1ZTNkNTYwXeGQpw0KDQpPbiBGcmksIFNlcCAxMywg MjAxOSBhdCAxMjowOCBQTSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpy aWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KVHJhdmlzIGhhcyB0aGlzIGNvcnJlY3Qg4oCUIHRoZSDi gJxyZWdpc3RyYXRpb24gYWNjZXNzIHRva2Vu4oCdIGlzIHBhc3NlZCB0byB0aGUgY2xpZW50IGZv ciB0aGUgZXhwcmVzcyBwdXJwb3NlIG9mIGFjY2Vzc2luZyB0aGUgY2xpZW50IG1hbmFnZW1lbnQg QVBJLCBhbmQgaXMgbm90IHRoZSBzYW1lIGFzLCBvciBlbnRhbmdsZWQgd2l0aCwgYW55IGFjY2Vz cyB0b2tlbnMgdGhhdCB0aGUgY2xpZW50IHJlcXVlc3RzIHRocm91Z2ggdGhlIE9BdXRoIHByb2Nl c3MgYWZ0ZXIgdGhlIHJlZ2lzdHJhdGlvbiBoYXMgb2NjdXJyZWQuIFRoZSByZWFzb25zIGZvciB0 aGlzIHNlcGFyYXRpb24gYXJlIG1hbnksIGJ1dCBhdCB0aGUgY29yZSBpdCBjb21lcyBkb3duIHRv IHRoZSBjbGllbnQgYWx3YXlzIGFjdGluZyBvbiBpdHMgb3duIGJlaGFsZiB3aGVuIGl0IGRvZXMg cmVnaXN0cmF0aW9uLCBhbmQgYWN0aW5nIG9uIGJlaGFsZiBvZiBzb21lIG90aGVyIHBhcnR5ICh1 c3VhbGx5IGEgdXNlcikgd2hlbiBpdOKAmXMgZG9pbmcgT0F1dGguIEFkZGl0aW9uYWxseSwgcmVn aXN0cmF0aW9uIG1hbmFnZW1lbnQgaXMgYSBmdW5jdGlvbiBvZiB0aGUgQVMsIHdoZXJlYXMgdGhl IHByb3RlY3RlZCBBUElzIGFyZSBhIGZ1bmN0aW9uIG9mIHRoZSBSUyDigJQgbm90ZSB0aGlzIGlz IGEgbG9naWNhbCBzZXBhcmF0aW9uIGFuZCB0aGVyZeKAmXMgbm90aGluZyBzdG9wcGluZyBBUyBh bmQgUlMgZnVuY3Rpb25zIGZyb20gYmVpbmcgZGVwbG95ZWQgaW4gYW55IG51bWJlciBvZiBwYXR0 ZXJucy4NCg0KQSBmZXcgY29tbW9uIHF1ZXN0aW9ucyB3ZSBnb3QgYXNrZWQgd2hlbiB3cml0aW5n IHRoaXMgZnVuY3Rpb25hbGl0eSBpbnRvIHRoZSBzcGVjOg0KDQpXaHkgdXNlIGFuIGFjY2VzcyB0 b2tlbiBhdCBhbGw/IEJlY2F1c2UgaXTigJlzIGEgY3JlZGVudGlhbCBmb3IgYSBzcGVjaWZpYyBB UEkgaXNzdWVkIGJ5IHRoZSBBUyBhbmQgaGFuZGVkIHRvIHRoZSBjbGllbnQgaW4gYSBwcm9ncmFt bWF0aWMgbWFubmVyLiBUaGlzIGlzIGV4YWN0bHkgd2hhdCBPQXV0aCB0b2tlbnMgd2VyZSBtYWRl IGZvci4NCg0KV2h5IG5vdCB1c2UgdGhlIGNsaWVudOKAmXMgY3JlZGVudGlhbHM/IEJlY2F1c2Ug bm90IGFsbCBjbGllbnRzIGFyZSBzZXQgdXAgdG8gaGF2ZSBjcmVkZW50aWFscywgcGx1cyB3ZeKA mWQgYmUgc3ByZWFkaW5nIHRoZSByZXF1aXJlbWVudCB0byBzdXBwb3J0IGRpZmZlcmVudCBraW5k cyBvZiBjbGllbnQgY3JlZGVudGlhbHMgdG8gYW5vdGhlciBlbmRwb2ludC4NCg0KV2h5IG5vdCBp c3N1ZSBhbiBhdXRob3JpemF0aW9uIGNvZGU/IEJlY2F1c2UgdGhlbiB0aGUgY2xpZW50IHdvdWxk IG5lZWQgdG8gbWFrZSB5ZXQgYW5vdGhlciByb3VuZCB0cmlwLCBhbmQgbm90IGFsbCBjbGllbnRz IGFyZSBhdXRob3JpemF0aW9uLWNvZGUtZ3JhbnQgY2xpZW50cyB0byBiZWdpbiB3aXRoLg0KDQpX aHkgbm90IG1ha2UgYSBuZXcgZ3JhbnQgdHlwZT8gQmVjYXVzZSB0aGVuIHRoZSBjbGllbnQgd291 bGQgbmVlZCB0byBtYWtlIHlldCBhbm90aGVyIHJvdW5kIHRyaXAsIGFuZCB3ZeKAmWQgaGF2ZSB0 byBpbnZlbnQgYSB3aG9sZSBuZXcgZ3JhbnQgdHlwZSB3aXRoIGEgbmV3IHRlbXBvcmFyeSBjcmVk ZW50aWFsIHdoZW4gd2UgY291bGQganVzdCB1c2UgdGhhdCB0ZW1wb3JhcnkgY3JlZGVudGlhbCBk aXJlY3RseSBpbnN0ZWFkLg0KDQrigJQgSnVzdGluDQoNCk9uIFNlcCAxMywgMjAxOSwgYXQgODoy MyBBTSwgUm9iYWNoZSBIZXJ2w6kgPGhlcnZlLnJvYmFjaGVAc3RldC5ldTxtYWlsdG86aGVydmUu cm9iYWNoZUBzdGV0LmV1Pj4gd3JvdGU6DQoNClRoYW5rcyBUcmF2aXMNCg0KSSB1bmRlcnN0YW5k IHRoYXQsIG9uY2UgdGhlIGNsaWVudCBoYXMgcmV0cmlldmVkIGl0cyBbY2xpZW50X2lkXSB0aHJv dWdoIFJGQzc1OTEgaW5pdGlhbCByZWdpc3RyYXRpb24sIGl0IGlzIHRoZW4gYWJsZSB0byBhc2sg Zm9yIGFuIGFjY2VzcyB0b2tlbiB0aGF0IHdpbGwgYmUgdXNlZCBmb3IgYWNjZXNzaW5nIHRoZSBS RkM3NTkyIGVudHJ5LXBvaW50cy4gQW0gSSByaWdodD8NCg0KQmVzdCByZWdhcmRzDQoNCkhlcnbD qQ0KDQpEZSA6IFRyYXZpcyBTcGVuY2VyIFttYWlsdG86dHJhdmlzLnNwZW5jZXJAY3VyaXR5Lmlv XQ0KRW52b3nDqSA6IHZlbi4gMTMgMTM6MzANCsOAIDogUm9iYWNoZSBIZXJ2w6kNCkNjIDogb2F1 dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KT2JqZXQgOiBSZTogW09BVVRILVdH XSBRdWVzdGlvbiByZWdhcmRpbmcgUkZDIDc1OTINCg0KTm8uIFRoZSBpbml0aWFsIGFjY2VzcyB0 b2tlbiBpcyBpc3N1ZWQgYnkgdGhlIEFTIHdoZW4gcmVnaXN0cmF0aW9uIGlzIHByb3RlY3RlZCAo YXBwZW5kaXggMS4yIGluIFJGQyA3NTkxKS4gQXMgc3RhdGVkIGluIHNlY3Rpb24gMS4yLCB0aGUg bWV0aG9kIGFuZCBtZWFucyBieSB3aGljaCB0aGlzIGlzIG9idGFpbmVkIGNhbiB2YXJ5LiBUaGUg cmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiBpbiBSRkMgNzU5MiBpcyB1c2VkIHRvIHByb3RlY3Qg dGhlIHJlZ2lzdHJhdGlvbiBtYW5hZ2VtZW50IEFQSSBhbmQgYWxsb3cgdXBkYXRlcyB0byB0aGUg Y2xpZW50IGFmdGVyIGl0IGlzIHJlZ2lzdGVyZWQuIFlvdSBtaWdodCBoYXZlIG9uZSAodGhlIHJl Z2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4pIGJ1dCBub3QgdGhlIG90aGVyIChpbml0aWFsIGFjY2Vz cyB0b2tlbikgd2hlbiBvcGVuIHJlZ2lzdHJhdGlvbiBpcyBhbGxvd2VkIChhcHBlbmRpeCAxLjEg aW4gUkZDIDc1OTEpLg0KDQpIVEghDQoNCk9uIEZyaSwgU2VwIDEzLCAyMDE5IGF0IDc6MzcgQU0g Um9iYWNoZSBIZXJ2w6kgPGhlcnZlLnJvYmFjaGVAc3RldC5ldTxtYWlsdG86aGVydmUucm9iYWNo ZUBzdGV0LmV1Pj4gd3JvdGU6DQpIaQ0KDQpSRkMgNzU5MiBpbnRyb2R1Y2VzIGEgwqsgUmVnaXN0 cmF0aW9uIEFjY2VzcyBUb2tlbiDCuy4gQXJlIHRoaXMgdG9rZW4gYW5kIHRoZSB3YXkgdG8gZ2V0 IGl0IHNpbWlsYXIgdG8gd2hhdCBpcyBzcGVjaWZpZWQgYXMg4oCcSW5pdGlhbCBBY2Nlc3MgVG9r ZW7igJ0gaW4gUkZDIDc1OTEvQXBwZW5kaXggQSA/DQoNCklmIHNvLCBjYW4gdGhlIE9wZW4gRHlu YW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIChSRkM3NTkxL0EuMS4xKSBiZSBleHRyYXBvbGF0ZWQg dG8gUkZDNzU5MiBhcyB0aGUgc2FtZSB3YXk/DQoNClRoYW5rcyBpbiBhZHZhbmNlIGZvciB5b3Vy IGNsYXJpZmljYXRpb24uDQoNCkhlcnbDqSBST0JBQ0hFDQpEaXJlY3Rpb24gTWFya2V0aW5nIGV0 IETDqXZlbG9wcGVtZW50DQoNCkxJR05FIERJUkVDVEUNClQuICszMygwKTEgNTUgMjMgNTUgNDUN CmhlcnZlLnJvYmFjaGVAc3RldC5ldTxtYWlsdG86aGVydmUucm9iYWNoZUBzdGV0LmV1Pg0KDQoN Cg0KPGltYWdlMDAxLnBuZz4NCg0KDQoNCg0KPGltYWdlMDAyLnBuZz4NCg0KU1RFVCAoU0lFR0Ug U09DSUFMKQ0KMTAwLCBFc3BsYW5hZGUgZHUgR8OpbsOpcmFsIGRlIEdhdWxsZQ0KQ8WTdXIgRMOp ZmVuc2Ug4oCTIFRvdXIgQg0KOTI5MzIgTGEgRMOpZmVuc2UgY2VkZXgNCg0Kd3d3LnN0ZXQuZXU8 aHR0cDovL3d3dy5zdGV0LmV1Lz4NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgdG91dGVzIGxlcyBwacOo Y2VzIGpvaW50ZXMgc29udCDDqXRhYmxpcyDDoCBsJ2ludGVudGlvbiBleGNsdXNpdmUgZGUgc2Vz IGRlc3RpbmF0YWlyZXMgZXQgc29udCBjb25maWRlbnRpZWxzLg0KU2kgdm91cyByZWNldmV6IGNl IG1lc3NhZ2UgcGFyIGVycmV1ciBvdSBzJ2lsIG5lIHZvdXMgZXN0IHBhcyBkZXN0aW7DqSwgbWVy Y2kgZGUgbGUgZMOpdHJ1aXJlIGFpbnNpIHF1ZSB0b3V0ZSBjb3BpZSBkZSB2b3RyZSBzeXN0w6ht ZSBldCBkJ2VuIGF2ZXJ0aXIgaW1tw6lkaWF0ZW1lbnQgbCdleHDDqWRpdGV1ci4NClRvdXRlIGxl Y3R1cmUgbm9uIGF1dG9yaXPDqWUsIHRvdXRlIHV0aWxpc2F0aW9uIGRlIGNlIG1lc3NhZ2UgcXVp IG4nZXN0IHBhcyBjb25mb3JtZSDDoCBzYSBkZXN0aW5hdGlvbiwgdG91dGUgZGlmZnVzaW9uIG91 IHRvdXRlIHB1YmxpY2F0aW9uLCB0b3RhbGUgb3UgcGFydGllbGxlLCBlc3QgaW50ZXJkaXRlLg0K TCdJbnRlcm5ldCBuZSBwZXJtZXR0YW50IHBhcyBkJ2Fzc3VyZXIgbCdpbnTDqWdyaXTDqSBkZSBj ZSBtZXNzYWdlIMOpbGVjdHJvbmlxdWUgc3VzY2VwdGlibGUgZCdhbHTDqXJhdGlvbiwgU1RFVCBk w6ljbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0w6kgYXUgdGl0cmUgZGUgY2UgbWVzc2FnZSBkYW5z IGwnaHlwb3Row6hzZSBvw7kgaWwgYXVyYWl0IMOpdMOpIG1vZGlmacOpLCBkw6lmb3Jtw6kgb3Ug ZmFsc2lmacOpLg0KTidpbXByaW1leiBjZSBtZXNzYWdlIHF1ZSBzaSBuw6ljZXNzYWlyZSwgcGVu c2V6IMOgIGwnZW52aXJvbm5lbWVudC4NCg0KVGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVu dHMgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgaW50ZW5kZWQgYWRkcmVzc2VlcyBhbmQgaXMg Y29uZmlkZW50aWFsLg0KSWYgeW91IHJlY2VpdmUgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBvciBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocyksIHBsZWFzZSBkZWxldGUgaXQgYW5kIGFu eSBjb3BpZXMgZnJvbSB5b3VyIHN5c3RlbXMgYW5kIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2Vu ZGVyLg0KQW55IHVuYXV0aG9yaXplZCB2aWV3LCB1c2UgdGhhdCBkb2VzIG5vdCBjb21wbHkgd2l0 aCBpdHMgcHVycG9zZSwgZGlzc2VtaW5hdGlvbiBvciBkaXNjbG9zdXJlLCBlaXRoZXIgd2hvbGUg b3IgcGFydGlhbCwgaXMgcHJvaGliaXRlZC4NClNpbmNlIHRoZSBpbnRlcm5ldCBjYW5ub3QgZ3Vh cmFudGVlIHRoZSBpbnRlZ3JpdHkgb2YgdGhpcyBtZXNzYWdlIHdoaWNoIG1heSBub3QgYmUgcmVs aWFibGUsIFNURVQgc2hhbGwgbm90IGJlIGxpYWJsZSBmb3IgdGhlIG1lc3NhZ2UgaWYgbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KRG8gbm90IHByaW50IHRoaXMgbWVzc2FnZSB1bmxl c3MgaXQgaXMgbmVjZXNzYXJ5LCBwbGVhc2UgY29uc2lkZXIgdGhlIGVudmlyb25tZW50Lg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCkNlIG1lc3NhZ2UgZXQgdG91 dGVzIGxlcyBwacOoY2VzIGpvaW50ZXMgc29udCDDqXRhYmxpcyDDoCBsJ2ludGVudGlvbiBleGNs dXNpdmUgZGUgc2VzIGRlc3RpbmF0YWlyZXMgZXQgc29udCBjb25maWRlbnRpZWxzLg0KU2kgdm91 cyByZWNldmV6IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciBvdSBzJ2lsIG5lIHZvdXMgZXN0IHBhcyBk ZXN0aW7DqSwgbWVyY2kgZGUgbGUgZMOpdHJ1aXJlIGFpbnNpIHF1ZSB0b3V0ZSBjb3BpZSBkZSB2 b3RyZSBzeXN0w6htZSBldCBkJ2VuIGF2ZXJ0aXIgaW1tw6lkaWF0ZW1lbnQgbCdleHDDqWRpdGV1 ci4NClRvdXRlIGxlY3R1cmUgbm9uIGF1dG9yaXPDqWUsIHRvdXRlIHV0aWxpc2F0aW9uIGRlIGNl IG1lc3NhZ2UgcXVpIG4nZXN0IHBhcyBjb25mb3JtZSDDoCBzYSBkZXN0aW5hdGlvbiwgdG91dGUg ZGlmZnVzaW9uIG91IHRvdXRlIHB1YmxpY2F0aW9uLCB0b3RhbGUgb3UgcGFydGllbGxlLCBlc3Qg aW50ZXJkaXRlLg0KTCdJbnRlcm5ldCBuZSBwZXJtZXR0YW50IHBhcyBkJ2Fzc3VyZXIgbCdpbnTD qWdyaXTDqSBkZSBjZSBtZXNzYWdlIMOpbGVjdHJvbmlxdWUgc3VzY2VwdGlibGUgZCdhbHTDqXJh dGlvbiwgU1RFVCBkw6ljbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0w6kgYXUgdGl0cmUgZGUgY2Ug bWVzc2FnZSBkYW5zIGwnaHlwb3Row6hzZSBvw7kgaWwgYXVyYWl0IMOpdMOpIG1vZGlmacOpLCBk w6lmb3Jtw6kgb3UgZmFsc2lmacOpLg0KTidpbXByaW1leiBjZSBtZXNzYWdlIHF1ZSBzaSBuw6lj ZXNzYWlyZSwgcGVuc2V6IMOgIGwnZW52aXJvbm5lbWVudC4NCg0KVGhpcyBtZXNzYWdlIGFuZCBh bnkgYXR0YWNobWVudHMgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgaW50ZW5kZWQgYWRkcmVz c2VlcyBhbmQgaXMgY29uZmlkZW50aWFsLg0KSWYgeW91IHJlY2VpdmUgdGhpcyBtZXNzYWdlIGlu IGVycm9yLCBvciBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocyksIHBsZWFzZSBkZWxl dGUgaXQgYW5kIGFueSBjb3BpZXMgZnJvbSB5b3VyIHN5c3RlbXMgYW5kIGltbWVkaWF0ZWx5IG5v dGlmeSB0aGUgc2VuZGVyLg0KQW55IHVuYXV0aG9yaXplZCB2aWV3LCB1c2UgdGhhdCBkb2VzIG5v dCBjb21wbHkgd2l0aCBpdHMgcHVycG9zZSwgZGlzc2VtaW5hdGlvbiBvciBkaXNjbG9zdXJlLCBl aXRoZXIgd2hvbGUgb3IgcGFydGlhbCwgaXMgcHJvaGliaXRlZC4NClNpbmNlIHRoZSBpbnRlcm5l dCBjYW5ub3QgZ3VhcmFudGVlIHRoZSBpbnRlZ3JpdHkgb2YgdGhpcyBtZXNzYWdlIHdoaWNoIG1h eSBub3QgYmUgcmVsaWFibGUsIFNURVQgc2hhbGwgbm90IGJlIGxpYWJsZSBmb3IgdGhlIG1lc3Nh Z2UgaWYgbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KRG8gbm90IHByaW50IHRoaXMg bWVzc2FnZSB1bmxlc3MgaXQgaXMgbmVjZXNzYXJ5LCBwbGVhc2UgY29uc2lkZXIgdGhlIGVudmly b25tZW50Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Ck9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBs aXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_1BEA14649B314FBF861916096F13BBDDmitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <1E92F0A5935CC848BE9B30FB07FF631F@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgZG9u4oCZdCBzZWUgYSByZWFzb24gdG8gdXNl IGFuIGFzc2VydGlvbiBoZXJlLiBKV1QgYXV0aGVudGljYXRpb24gd291bGQgcmVxdWlyZSBhdCBs ZWFzdCBhIHNlY3JldCBpZiBub3QgYSBrZXkgb2Ygc29tZSB0eXBlIGZvciBhdXRoZW50aWNhdGlv biBmb3IgYWxsIGNsaWVudHMsIGFuZCBpdCB3YXMgZGV0ZXJtaW5lZCB0aGF0IGR5bmFtaWMgcmVn aXN0cmF0aW9uIHNob3VsZG7igJl0IHJlcXVpcmUgdGhlIGNsaWVudHMgKGV2ZW4gcHVibGljIGNs aWVudHMpDQogdG8gc3VwcG9ydCB0aGluZ3MgdGhleSB3ZXJlbuKAmXQgYWxyZWFkeSBjYXBhYmxl IG9mIGRvaW5nLiBCZXNpZGVzLCB0aGUgbWFuYWdlbWVudCBlbmRwb2ludCBpc27igJl0IGEgdG9r ZW4gZW5kcG9pbnQgKHRob3VnaCBJ4oCZbSBjdXJpb3VzIHRvIGhlYXIgd2h5IHlvdeKAmWQgc2F5 IHRoYXQpIOKAlCBpdOKAmXMgYW4gQVBJIHlvdSBjYW4gY2FsbCB0byBtYW5hZ2UgYSBjbGllbnTi gJlzIHJlZ2lzdHJhdGlvbiBkYXRhIG92ZXIgdGltZS4gU291bmRzIGxpa2UgYW4gUlMsDQogaWYg eW91IGFzayBtZS4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFk anVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRp b246IG5vbmU7Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gU2Vw IDE1LCAyMDE5LCBhdCAxOjA1IEFNLCBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGlj ay5oYXJkdEBnbWFpbC5jb20iIGNsYXNzPSIiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsg d3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPkN1cmlvdXMgd2h5Jm5ic3A7dGhl IGNsaWVudCBtYW5hZ2VtZW50IEFQSSB1c2VzIGJlYXJlciB0b2tlbnMgcmF0aGVyIHRoYW4gSldU cyBwZXIgUkZDIDc1MjMgZm9yIHRoZSBjbGllbnQgdG8gYXV0aGVudGljYXRlLiBUaGUgY2xpZW50 IG1hbmFnZW1lbnQgQVBJIHNlZW1zIG1vcmUgc2ltaWxhciB0byBhIHRva2VuIGVuZHBvaW50IHRo YW4gYSByZXNvdXJjZS48L2Rpdj4NCjxkaXYgaHNwYWNlPSJzdHJlYWstcHQtbWFyayIgc3R5bGU9 Im1heC1oZWlnaHQ6MXB4IiBjbGFzcz0iIj48aW1nIGFsdD0iIiBzdHlsZT0id2lkdGg6MHB4O21h eC1oZWlnaHQ6MHB4O292ZXJmbG93OmhpZGRlbiIgc3JjPSJodHRwczovL21haWxmb29nYWUuYXBw c3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlw ZT16ZXJvY29udGVudCZhbXA7Z3VpZD01YzRiYmM4MC0xZjAwLTQzNTEtOWE5Yi05NTQ4MDVlM2Q1 NjAiIGNsYXNzPSIiPjxmb250IGNvbG9yPSIjZmZmZmZmIiBzaXplPSIxIiBjbGFzcz0iIj7hkKc8 L2ZvbnQ+PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8 ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gRnJpLCBTZXAgMTMsIDIwMTkgYXQg MTI6MDggUE0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVk dSIgY2xhc3M9IiI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4 IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFk ZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJvdmVyZmxvdy13cmFwOiBicmVhay13b3JkOyIg Y2xhc3M9IiI+VHJhdmlzIGhhcyB0aGlzIGNvcnJlY3Qg4oCUIHRoZSDigJxyZWdpc3RyYXRpb24g YWNjZXNzIHRva2Vu4oCdIGlzIHBhc3NlZCB0byB0aGUgY2xpZW50IGZvciB0aGUgZXhwcmVzcyBw dXJwb3NlIG9mIGFjY2Vzc2luZyB0aGUgY2xpZW50IG1hbmFnZW1lbnQgQVBJLCBhbmQgaXMgbm90 IHRoZSBzYW1lIGFzLCBvciBlbnRhbmdsZWQgd2l0aCwgYW55IGFjY2VzcyB0b2tlbnMgdGhhdA0K IHRoZSBjbGllbnQgcmVxdWVzdHMgdGhyb3VnaCB0aGUgT0F1dGggcHJvY2VzcyBhZnRlciB0aGUg cmVnaXN0cmF0aW9uIGhhcyBvY2N1cnJlZC4gVGhlIHJlYXNvbnMgZm9yIHRoaXMgc2VwYXJhdGlv biBhcmUgbWFueSwgYnV0IGF0IHRoZSBjb3JlIGl0IGNvbWVzIGRvd24gdG8gdGhlIGNsaWVudCBh bHdheXMgYWN0aW5nIG9uIGl0cyBvd24gYmVoYWxmIHdoZW4gaXQgZG9lcyByZWdpc3RyYXRpb24s IGFuZCBhY3Rpbmcgb24gYmVoYWxmIG9mIHNvbWUNCiBvdGhlciBwYXJ0eSAodXN1YWxseSBhIHVz ZXIpIHdoZW4gaXTigJlzIGRvaW5nIE9BdXRoLiBBZGRpdGlvbmFsbHksIHJlZ2lzdHJhdGlvbiBt YW5hZ2VtZW50IGlzIGEgZnVuY3Rpb24gb2YgdGhlIEFTLCB3aGVyZWFzIHRoZSBwcm90ZWN0ZWQg QVBJcyBhcmUgYSBmdW5jdGlvbiBvZiB0aGUgUlMg4oCUIG5vdGUgdGhpcyBpcyBhIGxvZ2ljYWwg c2VwYXJhdGlvbiBhbmQgdGhlcmXigJlzIG5vdGhpbmcgc3RvcHBpbmcgQVMgYW5kIFJTIGZ1bmN0 aW9ucyBmcm9tDQogYmVpbmcgZGVwbG95ZWQgaW4gYW55IG51bWJlciBvZiBwYXR0ZXJucy4mbmJz cDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkEg ZmV3IGNvbW1vbiBxdWVzdGlvbnMgd2UgZ290IGFza2VkIHdoZW4gd3JpdGluZyB0aGlzIGZ1bmN0 aW9uYWxpdHkgaW50byB0aGUgc3BlYzo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIiPldoeSB1c2UgYW4gYWNjZXNzIHRv a2VuIGF0IGFsbDwvYj4/IEJlY2F1c2UgaXTigJlzIGEgY3JlZGVudGlhbCBmb3IgYSBzcGVjaWZp YyBBUEkgaXNzdWVkIGJ5IHRoZSBBUyBhbmQgaGFuZGVkIHRvIHRoZSBjbGllbnQgaW4gYSBwcm9n cmFtbWF0aWMgbWFubmVyLiBUaGlzIGlzIGV4YWN0bHkgd2hhdCBPQXV0aCB0b2tlbnMgd2VyZSBt YWRlIGZvci4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIiPldoeSBub3QgdXNlIHRoZSBjbGllbnTigJlzIGNy ZWRlbnRpYWxzPC9iPj8gQmVjYXVzZSBub3QgYWxsIGNsaWVudHMgYXJlIHNldCB1cCB0byBoYXZl IGNyZWRlbnRpYWxzLCBwbHVzIHdl4oCZZCBiZSBzcHJlYWRpbmcgdGhlIHJlcXVpcmVtZW50IHRv IHN1cHBvcnQgZGlmZmVyZW50IGtpbmRzIG9mIGNsaWVudCBjcmVkZW50aWFscyB0byBhbm90aGVy IGVuZHBvaW50LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+V2h5IG5vdCBpc3N1ZSBhbiBhdXRob3JpemF0 aW9uIGNvZGU8L2I+PyBCZWNhdXNlIHRoZW4gdGhlIGNsaWVudCB3b3VsZCBuZWVkIHRvIG1ha2Ug eWV0IGFub3RoZXIgcm91bmQgdHJpcCwgYW5kIG5vdCBhbGwgY2xpZW50cyBhcmUgYXV0aG9yaXph dGlvbi1jb2RlLWdyYW50IGNsaWVudHMgdG8gYmVnaW4gd2l0aC4mbmJzcDs8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIi PldoeSBub3QgbWFrZSBhIG5ldyBncmFudCB0eXBlPC9iPj8gQmVjYXVzZSB0aGVuIHRoZSBjbGll bnQgd291bGQgbmVlZCB0byBtYWtlIHlldCBhbm90aGVyIHJvdW5kIHRyaXAsIGFuZCB3ZeKAmWQg aGF2ZSB0byBpbnZlbnQgYSB3aG9sZSBuZXcgZ3JhbnQgdHlwZSB3aXRoIGEgbmV3IHRlbXBvcmFy eSBjcmVkZW50aWFsIHdoZW4gd2UgY291bGQganVzdCB1c2UgdGhhdCB0ZW1wb3JhcnkgY3JlZGVu dGlhbCBkaXJlY3RseQ0KIGluc3RlYWQuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyIgY2xhc3M9IiI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPk9uIFNlcCAxMywgMjAxOSwgYXQgODoyMyBBTSwgUm9iYWNoZSBIZXJ2w6kgJmx0 OzxhIGhyZWY9Im1haWx0bzpoZXJ2ZS5yb2JhY2hlQHN0ZXQuZXUiIHRhcmdldD0iX2JsYW5rIiBj bGFzcz0iIj5oZXJ2ZS5yb2JhY2hlQHN0ZXQuZXU8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBj bGFzcz0iZ21haWwtbV8tMjkxODY2NDQ1Mjg0MDM0NjkyN0FwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsLW1fLTI5MTg2NjQ0NTI4NDAz NDY5MjdXb3JkU2VjdGlvbjEiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXpl OjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2Vp Z2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWlu ZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFj aW5nOjBweDt0ZXh0LWRlY29yYXRpb246bm9uZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBj bSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTFwdDtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Y29sb3I6cmdiKDMxLDcz LDEyNSkiIGNsYXNzPSIiPlRoYW5rcyBUcmF2aXM8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+ PC91Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0O2Zv bnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZiIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0O2Zv bnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtjb2xvcjpyZ2IoMzEsNzMsMTI1KSIgY2xhc3M9 IiI+PHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTFwdDtmb250LWZhbWlseTpDYWxpYnJpLHNh bnMtc2VyaWY7Y29sb3I6cmdiKDMxLDczLDEyNSkiIGNsYXNzPSIiPkkgdW5kZXJzdGFuZCB0aGF0 LCBvbmNlIHRoZSBjbGllbnQgaGFzIHJldHJpZXZlZCBpdHMgW2NsaWVudF9pZF0gdGhyb3VnaCBS RkM3NTkxIGluaXRpYWwgcmVnaXN0cmF0aW9uLCBpdCBpcyB0aGVuIGFibGUgdG8gYXNrIGZvciBh biBhY2Nlc3MgdG9rZW4gdGhhdCB3aWxsDQogYmUgdXNlZCBmb3IgYWNjZXNzaW5nIHRoZSBSRkM3 NTkyIGVudHJ5LXBvaW50cy4gQW0gSSByaWdodD88dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+ PC91Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0O2Zv bnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZiIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0O2Zv bnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtjb2xvcjpyZ2IoMzEsNzMsMTI1KSIgY2xhc3M9 IiI+PHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTFwdDtmb250LWZhbWlseTpDYWxpYnJpLHNh bnMtc2VyaWY7Y29sb3I6cmdiKDMxLDczLDEyNSkiIGNsYXNzPSIiPkJlc3QgcmVnYXJkczx1IGNs YXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2NvbG9y OnJnYigzMSw3MywxMjUpIiBjbGFzcz0iIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9 IiI+PC91Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0 O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0 O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtjb2xvcjpyZ2IoMzEsNzMsMTI1KSIgY2xh c3M9IiI+SGVydsOpPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTFwdDtmb250LWZhbWlseTpDYWxpYnJp LHNhbnMtc2VyaWY7Y29sb3I6cmdiKDMxLDczLDEyNSkiIGNsYXNzPSIiPjx1IGNsYXNzPSIiPjwv dT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTBwdDtmb250LWZhbWlseTpUYWhvbWEsc2Fucy1zZXJpZiIgY2xhc3M9IiI+ RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1p bHk6VGFob21hLHNhbnMtc2VyaWYiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJnbWFpbC1tXy0yOTE4 NjY0NDUyODQwMzQ2OTI3QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHJhdmlz IFNwZW5jZXIgWzxhIGhyZWY9Im1haWx0bzp0cmF2aXMuc3BlbmNlckBjdXJpdHkuaW8iIHN0eWxl PSJjb2xvcjpwdXJwbGU7dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPm1haWx0bzp0cmF2aXMuc3BlbmNlckBjdXJpdHkuaW88L2E+XTxzcGFuIGNsYXNz PSJnbWFpbC1tXy0yOTE4NjY0NDUyODQwMzQ2OTI3QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+RW52b3nDqSZuYnNwOzo8L2I+PHNw YW4gY2xhc3M9ImdtYWlsLW1fLTI5MTg2NjQ0NTI4NDAzNDY5MjdBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj52ZW4uIDEzIDEzOjMwPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+ w4AmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJnbWFpbC1tXy0yOTE4NjY0NDUyODQwMzQ2OTI3QXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Um9iYWNoZSBIZXJ2w6k8YnIgY2xhc3M9 IiI+DQo8YiBjbGFzcz0iIj5DYyZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImdtYWlsLW1fLTI5MTg2 NjQ0NTI4NDAzNDY5MjdBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVm PSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjpwdXJwbGU7dGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPm9hdXRoQGlldGYub3JnPC9h PjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPk9iamV0Jm5ic3A7OjwvYj48c3BhbiBjbGFzcz0i Z21haWwtbV8tMjkxODY2NDQ1Mjg0MDM0NjkyN0FwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPlJlOiBbT0FVVEgtV0ddIFF1ZXN0aW9uIHJlZ2FyZGluZyBSRkMgNzU5Mjx1IGNsYXNz PSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFzcz0iIj4NCjx1IGNsYXNzPSIiPjwvdT4mbmJzcDs8 dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+DQpOby4gVGhl IGluaXRpYWwgYWNjZXNzIHRva2VuIGlzIGlzc3VlZCBieSB0aGUgQVMgd2hlbiByZWdpc3RyYXRp b24gaXMgcHJvdGVjdGVkIChhcHBlbmRpeCAxLjIgaW4gUkZDIDc1OTEpLiBBcyBzdGF0ZWQgaW4g c2VjdGlvbiAxLjIsIHRoZSBtZXRob2QgYW5kIG1lYW5zIGJ5IHdoaWNoIHRoaXMgaXMgb2J0YWlu ZWQgY2FuIHZhcnkuIFRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIGluIFJGQyA3NTkyIGlz IHVzZWQgdG8gcHJvdGVjdCB0aGUgcmVnaXN0cmF0aW9uDQogbWFuYWdlbWVudCBBUEkgYW5kIGFs bG93IHVwZGF0ZXMgdG8gdGhlIGNsaWVudCBhZnRlciBpdCBpcyByZWdpc3RlcmVkLiBZb3UgbWln aHQgaGF2ZSBvbmUgKHRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuKSBidXQgbm90IHRoZSBv dGhlciAoaW5pdGlhbCBhY2Nlc3MgdG9rZW4pIHdoZW4gb3BlbiByZWdpc3RyYXRpb24gaXMgYWxs b3dlZCAoYXBwZW5kaXggMS4xIGluIFJGQyA3NTkxKS48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9 IiI+PC91PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFzcz0iIj4NCjx1IGNsYXNzPSIiPjwvdT4mbmJzcDs8 dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KSFRIITx1IGNsYXNzPSIi PjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFzcz0iIj4NCjx1IGNsYXNzPSIiPjwvdT4m bmJzcDs8dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+DQpP biBGcmksIFNlcCAxMywgMjAxOSBhdCA3OjM3IEFNIFJvYmFjaGUgSGVydsOpICZsdDs8YSBocmVm PSJtYWlsdG86aGVydmUucm9iYWNoZUBzdGV0LmV1IiBzdHlsZT0iY29sb3I6cHVycGxlO3RleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmUiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5oZXJ2ZS5yb2Jh Y2hlQHN0ZXQuZXU8L2E+Jmd0OyB3cm90ZTo8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91 PjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLXN0eWxlOm5vbmUgbm9u ZSBub25lIHNvbGlkO2JvcmRlci1sZWZ0LXdpZHRoOjFwdDtib3JkZXItbGVmdC1jb2xvcjpyZ2Io MjA0LDIwNCwyMDQpO3BhZGRpbmc6MGNtIDBjbSAwY20gNnB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KSGk8 dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFzcz0iIj4NCiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48 dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFw dDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss c2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPlJGQyA3NTkyIGlu dHJvZHVjZXMgYSDCqyZuYnNwO1JlZ2lzdHJhdGlvbiBBY2Nlc3MgVG9rZW4mbmJzcDvCuy4gQXJl IHRoaXMgdG9rZW4gYW5kIHRoZSB3YXkgdG8gZ2V0IGl0IHNpbWlsYXIgdG8gd2hhdCBpcyBzcGVj aWZpZWQgYXMg4oCcSW5pdGlhbCBBY2Nlc3MgVG9rZW7igJ0gaW4gUkZDIDc1OTEvQXBwZW5kaXgg QSA/PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0i RU4tVVMiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+ PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1zaXpl OjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFz cz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj5JZiBzbywgY2FuIHRoZSBPcGVuIER5 bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiAoUkZDNzU5MS9BLjEuMSkgYmUgZXh0cmFwb2xhdGVk IHRvIFJGQzc1OTIgYXMgdGhlIHNhbWUgd2F5Pzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xh c3M9IiI+PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9u dC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHUg Y2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjow Y20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9 IiI+VGhhbmtzIGluIGFkdmFuY2UgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbi48L3NwYW4+PHUgY2xh c3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20g MGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+ Jm5ic3A7PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwgUm91bmRlZCBNVCBCb2xk JnF1b3Q7LHNhbnMtc2VyaWYiIGNsYXNzPSIiPkhlcnbDqSBST0JBQ0hFPC9zcGFuPjx1IGNsYXNz PSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBj bSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwgUm91bmRlZCBNVCBCb2xkJnF1b3Q7LHNhbnMtc2VyaWYiIGNs YXNzPSIiPkRpcmVjdGlvbiBNYXJrZXRpbmcgZXQgRMOpdmVsb3BwZW1lbnQ8L3NwYW4+PHUgY2xh c3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20g MGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjlwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCBSb3VuZGVkIE1UIEJvbGQmcXVvdDssc2Fucy1zZXJpZiIg Y2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Zm9udC1mYW1pbHk6QXJpYWwsc2Fucy1zZXJpZiIg Y2xhc3M9IiI+TElHTkUgRElSRUNURTwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+ PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1zaXpl OjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OXB0O2ZvbnQtZmFtaWx5OkFyaWFsLHNhbnMt c2VyaWYiIGNsYXNzPSIiPlQuICYjNDM7MzMoMCkxIDU1IDIzIDU1IDQ1PC9zcGFuPjx1IGNsYXNz PSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBj bSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Zm9u dC1mYW1pbHk6QXJpYWwsc2Fucy1zZXJpZiIgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOmhlcnZl LnJvYmFjaGVAc3RldC5ldSIgc3R5bGU9ImNvbG9yOnB1cnBsZTt0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aGVydmUucm9iYWNoZUBzdGV0LmV1PC9h Pjwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJj b2xvcjpyZ2IoMzEsNzMsMTI1KSIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjx1IGNsYXNzPSIiPjwv dT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8dGFibGUgY2xhc3M9ImdtYWlsLW1fLTI5MTg2NjQ0 NTI4NDAzNDY5MjdNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2Vs bHBhZGRpbmc9IjAiIGFsaWduPSJsZWZ0Ij4NCjx0Ym9keSBjbGFzcz0iIj4NCjx0ciBzdHlsZT0i aGVpZ2h0OjZwdCIgY2xhc3M9IiI+DQo8dGQgd2lkdGg9IjEiIHN0eWxlPSJ3aWR0aDowLjc1cHQ7 cGFkZGluZzowY207aGVpZ2h0OjZwdCIgY2xhc3M9IiI+PC90ZD4NCjwvdHI+DQo8dHIgY2xhc3M9 IiI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIiBjbGFzcz0iIj48L3RkPg0KPHRkIHN0eWxlPSJw YWRkaW5nOjBjbSIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFw dDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss c2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gaWQ9ImdtYWlsLW1fLTI5MTg2NjQ0NTI4NDAzNDY5Mjdj aWQ6aW1hZ2UwMDEucG5nQDAxRDU2QTNFLkQwNDVBNzQwIiBjbGFzcz0iIj4mbHQ7aW1hZ2UwMDEu cG5nJmd0Ozwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvZGl2Pg0KPC90 ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNt IDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6cmdiKDMxLDczLDEy NSkiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91 PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1zaXplOjEy cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMzEsNzMsMTI1KSIgY2xhc3M9IiI+Jm5ic3A7PC9z cGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPGJyIGNsZWFyPSJhbGwiIGNs YXNzPSIiPg0KPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6cmdiKDMxLDczLDEyNSkiIGNsYXNzPSIiPjxzcGFuIGlkPSJnbWFpbC1tXy0yOTE4NjY0 NDUyODQwMzQ2OTI3Y2lkOmltYWdlMDAyLnBuZ0AwMUQ1NkEzRS5EMDQ1QTc0MCIgY2xhc3M9IiI+ Jmx0O2ltYWdlMDAyLnBuZyZndDs8L3NwYW4+PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFz cz0iIj48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250 LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOnJnYigzMSw3MywxMjUpIiBjbGFzcz0iIj4m bmJzcDs8L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjlwdDtmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmIiBjbGFzcz0iIj5T VEVUIChTSUVHRSBTT0NJQUwpPC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Zm9udC1mYW1pbHk6QXJpYWwsc2Fucy1zZXJp ZiIgY2xhc3M9IiI+MTAwLCBFc3BsYW5hZGUgZHUgR8OpbsOpcmFsIGRlIEdhdWxsZTwvc3Bhbj48 dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OXB0O2ZvbnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWYiIGNsYXNzPSIiPkPFk3VyIETDqWZlbnNl IOKAkyBUb3VyIEI8L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjlwdDtmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmIiBjbGFz cz0iIj45MjkzMiBMYSBEw6lmZW5zZSBjZWRleDwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xh c3M9IiI+PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9u dC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OXB0O2ZvbnQtZmFtaWx5OkFyaWFs LHNhbnMtc2VyaWYiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xh c3M9IiI+PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9u dC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OXB0O2ZvbnQtZmFtaWx5OkFyaWFs LHNhbnMtc2VyaWYiIGNsYXNzPSIiPjxhIGhyZWY9Imh0dHA6Ly93d3cuc3RldC5ldS8iIHN0eWxl PSJjb2xvcjpwdXJwbGU7dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPnd3dy5zdGV0LmV1PC9hPjwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9 IiI+PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1z aXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBj bGFzcz0iIj4NCiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5 OkFyaWFsLHNhbnMtc2VyaWY7Y29sb3I6Z3JheSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KQ2Ug bWVzc2FnZSBldCB0b3V0ZXMgbGVzIHBpw6hjZXMgam9pbnRlcyBzb250IMOpdGFibGlzIMOgIGwn aW50ZW50aW9uIGV4Y2x1c2l2ZSBkZSBzZXMgZGVzdGluYXRhaXJlcyBldCBzb250IGNvbmZpZGVu dGllbHMuPGJyIGNsYXNzPSIiPg0KU2kgdm91cyByZWNldmV6IGNlIG1lc3NhZ2UgcGFyIGVycmV1 ciBvdSBzJ2lsIG5lIHZvdXMgZXN0IHBhcyBkZXN0aW7DqSwgbWVyY2kgZGUgbGUgZMOpdHJ1aXJl IGFpbnNpIHF1ZSB0b3V0ZSBjb3BpZSBkZSB2b3RyZSBzeXN0w6htZSBldCBkJ2VuIGF2ZXJ0aXIg aW1tw6lkaWF0ZW1lbnQgbCdleHDDqWRpdGV1ci48YnIgY2xhc3M9IiI+DQpUb3V0ZSBsZWN0dXJl IG5vbiBhdXRvcmlzw6llLCB0b3V0ZSB1dGlsaXNhdGlvbiBkZSBjZSBtZXNzYWdlIHF1aSBuJ2Vz dCBwYXMgY29uZm9ybWUgw6Agc2EgZGVzdGluYXRpb24sIHRvdXRlIGRpZmZ1c2lvbiBvdSB0b3V0 ZSBwdWJsaWNhdGlvbiwgdG90YWxlIG91IHBhcnRpZWxsZSwgZXN0IGludGVyZGl0ZS48YnIgY2xh c3M9IiI+DQpMJ0ludGVybmV0IG5lIHBlcm1ldHRhbnQgcGFzIGQnYXNzdXJlciBsJ2ludMOpZ3Jp dMOpIGRlIGNlIG1lc3NhZ2Ugw6lsZWN0cm9uaXF1ZSBzdXNjZXB0aWJsZSBkJ2FsdMOpcmF0aW9u LCBTVEVUIGTDqWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXTDqSBhdSB0aXRyZSBkZSBjZSBtZXNz YWdlIGRhbnMgbCdoeXBvdGjDqHNlIG/DuSBpbCBhdXJhaXQgw6l0w6kgbW9kaWZpw6ksIGTDqWZv cm3DqSBvdSBmYWxzaWZpw6kuPGJyIGNsYXNzPSIiPg0KTidpbXByaW1leiBjZSBtZXNzYWdlIHF1 ZSBzaSBuw6ljZXNzYWlyZSwgcGVuc2V6IMOgIGwnZW52aXJvbm5lbWVudC48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpUaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBpcyBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSBpbnRlbmRlZCBhZGRyZXNzZWVzIGFuZCBpcyBjb25maWRlbnRp YWwuPGJyIGNsYXNzPSIiPg0KSWYgeW91IHJlY2VpdmUgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBv ciBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocyksIHBsZWFzZSBkZWxldGUgaXQgYW5k IGFueSBjb3BpZXMgZnJvbSB5b3VyIHN5c3RlbXMgYW5kIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUg c2VuZGVyLjxiciBjbGFzcz0iIj4NCkFueSB1bmF1dGhvcml6ZWQgdmlldywgdXNlIHRoYXQgZG9l cyBub3QgY29tcGx5IHdpdGggaXRzIHB1cnBvc2UsIGRpc3NlbWluYXRpb24gb3IgZGlzY2xvc3Vy ZSwgZWl0aGVyIHdob2xlIG9yIHBhcnRpYWwsIGlzIHByb2hpYml0ZWQuPGJyIGNsYXNzPSIiPg0K U2luY2UgdGhlIGludGVybmV0IGNhbm5vdCBndWFyYW50ZWUgdGhlIGludGVncml0eSBvZiB0aGlz IG1lc3NhZ2Ugd2hpY2ggbWF5IG5vdCBiZSByZWxpYWJsZSwgU1RFVCBzaGFsbCBub3QgYmUgbGlh YmxlIGZvciB0aGUgbWVzc2FnZSBpZiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPGJy IGNsYXNzPSIiPg0KRG8gbm90IHByaW50IHRoaXMgbWVzc2FnZSB1bmxlc3MgaXQgaXMgbmVjZXNz YXJ5LCBwbGVhc2UgY29uc2lkZXIgdGhlIGVudmlyb25tZW50Ljwvc3Bhbj48dSBjbGFzcz0iIj48 L3U+PHUgY2xhc3M9IiI+PC91PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNt IDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnIg Y2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjpw dXJwbGU7dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIi Pk9BdXRoQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHN0eWxlPSJjb2xvcjpwdXJwbGU7dGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PHUgY2xhc3M9IiI+PC91Pjx1IGNs YXNzPSIiPjwvdT48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgc3R5 bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1h bDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFj aW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9y bTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O3RleHQtZGVjb3JhdGlv bjpub25lIiBjbGFzcz0iIj4NCjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6ZT0i MSIgc3R5bGU9ImZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250 LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4 dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQt c3BhY2luZzowcHg7dGV4dC1kZWNvcmF0aW9uOm5vbmUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CkNlIG1lc3NhZ2UgZXQgdG91dGVzIGxlcyBwacOoY2VzIGpvaW50ZXMgc29udCDDqXRhYmxpcyDD oCBsJ2ludGVudGlvbiBleGNsdXNpdmUgZGUgc2VzIGRlc3RpbmF0YWlyZXMgZXQgc29udCBjb25m aWRlbnRpZWxzLjxiciBjbGFzcz0iIj4NClNpIHZvdXMgcmVjZXZleiBjZSBtZXNzYWdlIHBhciBl cnJldXIgb3UgcydpbCBuZSB2b3VzIGVzdCBwYXMgZGVzdGluw6ksIG1lcmNpIGRlIGxlIGTDqXRy dWlyZSBhaW5zaSBxdWUgdG91dGUgY29waWUgZGUgdm90cmUgc3lzdMOobWUgZXQgZCdlbiBhdmVy dGlyIGltbcOpZGlhdGVtZW50IGwnZXhww6lkaXRldXIuPGJyIGNsYXNzPSIiPg0KVG91dGUgbGVj dHVyZSBub24gYXV0b3Jpc8OpZSwgdG91dGUgdXRpbGlzYXRpb24gZGUgY2UgbWVzc2FnZSBxdWkg bidlc3QgcGFzIGNvbmZvcm1lIMOgIHNhIGRlc3RpbmF0aW9uLCB0b3V0ZSBkaWZmdXNpb24gb3Ug dG91dGUgcHVibGljYXRpb24sIHRvdGFsZSBvdSBwYXJ0aWVsbGUsIGVzdCBpbnRlcmRpdGUuPGJy IGNsYXNzPSIiPg0KTCdJbnRlcm5ldCBuZSBwZXJtZXR0YW50IHBhcyBkJ2Fzc3VyZXIgbCdpbnTD qWdyaXTDqSBkZSBjZSBtZXNzYWdlIMOpbGVjdHJvbmlxdWUgc3VzY2VwdGlibGUgZCdhbHTDqXJh dGlvbiwgU1RFVCBkw6ljbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0w6kgYXUgdGl0cmUgZGUgY2Ug bWVzc2FnZSBkYW5zIGwnaHlwb3Row6hzZSBvw7kgaWwgYXVyYWl0IMOpdMOpIG1vZGlmacOpLCBk w6lmb3Jtw6kgb3UgZmFsc2lmacOpLjxiciBjbGFzcz0iIj4NCk4naW1wcmltZXogY2UgbWVzc2Fn ZSBxdWUgc2kgbsOpY2Vzc2FpcmUsIHBlbnNleiDDoCBsJ2Vudmlyb25uZW1lbnQuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgaXMg aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgaW50ZW5kZWQgYWRkcmVzc2VlcyBhbmQgaXMgY29uZmlk ZW50aWFsLjxiciBjbGFzcz0iIj4NCklmIHlvdSByZWNlaXZlIHRoaXMgbWVzc2FnZSBpbiBlcnJv ciwgb3IgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLCBwbGVhc2UgZGVsZXRlIGl0 IGFuZCBhbnkgY29waWVzIGZyb20geW91ciBzeXN0ZW1zIGFuZCBpbW1lZGlhdGVseSBub3RpZnkg dGhlIHNlbmRlci48YnIgY2xhc3M9IiI+DQpBbnkgdW5hdXRob3JpemVkIHZpZXcsIHVzZSB0aGF0 IGRvZXMgbm90IGNvbXBseSB3aXRoIGl0cyBwdXJwb3NlLCBkaXNzZW1pbmF0aW9uIG9yIGRpc2Ns b3N1cmUsIGVpdGhlciB3aG9sZSBvciBwYXJ0aWFsLCBpcyBwcm9oaWJpdGVkLjxiciBjbGFzcz0i Ij4NClNpbmNlIHRoZSBpbnRlcm5ldCBjYW5ub3QgZ3VhcmFudGVlIHRoZSBpbnRlZ3JpdHkgb2Yg dGhpcyBtZXNzYWdlIHdoaWNoIG1heSBub3QgYmUgcmVsaWFibGUsIFNURVQgc2hhbGwgbm90IGJl IGxpYWJsZSBmb3IgdGhlIG1lc3NhZ2UgaWYgbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk LjxiciBjbGFzcz0iIj4NCkRvIG5vdCBwcmludCB0aGlzIG1lc3NhZ2UgdW5sZXNzIGl0IGlzIG5l Y2Vzc2FyeSwgcGxlYXNlIGNvbnNpZGVyIHRoZSBlbnZpcm9ubWVudC48YnIgY2xhc3M9IiI+DQo8 L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJweDtm b250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9y bWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBw eDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4 O3RleHQtZGVjb3JhdGlvbjpub25lO2Zsb2F0Om5vbmU7ZGlzcGxheTppbmxpbmUiIGNsYXNzPSIi Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4 O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpu b3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6 MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzow cHg7dGV4dC1kZWNvcmF0aW9uOm5vbmU7ZmxvYXQ6bm9uZTtkaXNwbGF5OmlubGluZSIgY2xhc3M9 IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+ PGJyIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHls ZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0 ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10 cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRl Y29yYXRpb246bm9uZSIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0 aWNhO2ZvbnQtc2l6ZToxMnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9y bWFsO3dvcmQtc3BhY2luZzowcHg7dGV4dC1kZWNvcmF0aW9uOm5vbmU7ZmxvYXQ6bm9uZTtkaXNw bGF5OmlubGluZSIgY2xhc3M9IiI+T0F1dGgNCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxl PSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2lu Zzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06 bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRlY29yYXRpb246 bm9uZSIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHN0eWxlPSJj b2xvcjpwdXJwbGU7dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTtmb250LWZhbWlseTpIZWx2ZXRp Y2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9y bWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpz dGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3Jt YWw7d29yZC1zcGFjaW5nOjBweCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPk9BdXRoQGlldGYu b3JnPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4O2Zv bnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpub3Jt YWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4 O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgc3R5bGU9ImNvbG9yOnB1cnBsZTt0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO2ZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJweDtm b250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9y bWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBw eDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4 IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aDwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNp emU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13 ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQt aW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNw YWNpbmc6MHB4O3RleHQtZGVjb3JhdGlvbjpub25lIiBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0 aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9 IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1BEA14649B314FBF861916096F13BBDDmitedu_-- From nobody Mon Sep 16 21:40:26 2019 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 581601200F6 for ; Mon, 16 Sep 2019 21:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 b7iYsImeoUoX for ; Mon, 16 Sep 2019 21:40:19 -0700 (PDT) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (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 3B0721200E5 for ; Mon, 16 Sep 2019 21:40:18 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id r2so1695507lfn.8 for ; Mon, 16 Sep 2019 21:40:18 -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=z3w19/LF2tQgL3cWNRIf/CjzGBEgl21paJSimN6rQd4=; b=ZXWU0Rf/b65BZtdM+LAuiR1PDb34wfq2hSa6IOjbA/kDmh2LE0pRjMykw7NmlFt5aD 5ZvDUcq9/ioVYcSmvH+9isg6Xh5hLqqPrmi7CHrwvBTPLRETMc2L1jUq+aXUbrwMogvv dDc1wnUdCCrT63IPLGX1vSviHLV8OicU+68Da2awjd/sdcS9eu/gLRujTaEH/x8kv4A9 uGJTRXEpd7QnpVvhS2sU5n/ufgAIHQZ+tTNjCGb3Mha998hl3VbLNHVdClnb0EYrlUzK /v7g/cPJOQHC9IkW5KD46TZr60UfSmJlmdHdcZdfQRIZl8mI0MxWvGgG/a1c6YztUhGn 0T9g== 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=z3w19/LF2tQgL3cWNRIf/CjzGBEgl21paJSimN6rQd4=; b=Vc8giuxvwHTeln7ecQTfZN5Z0boTdMVkKS4CMVl/+kJky0Nc8cQ012HMPmIplO1qaq ZfGaBY5rRTFCzRLZYyyz+Otcz4bNAdcTncZ6IJi2UXYHVBJrY8Gq5djPsn5tBkArkfVD aLyCsly4+x87HQd1fXn3vks4GeuOg4b6BaVHtA5RMNGjLKA9HD+CNfjMV5aJF20E6A0V wm1wnTnQ7gf8eDtcB29rEmCLLGN3h3Fd42z1WNm1Uij5Tn5yjPHG3kYbUtm6IM9mvjZV ly+O8WUIw+flTGZVsNvVdS5m1j6qHt8LrmR3yTJqsDTaRbBPS9n+FfrsH4sgs4N/wAY7 nbkg== X-Gm-Message-State: APjAAAUQ6znt2pxbmO78wLSV2/GpAhafbSiowC7ftmEdkmvLffomLuH7 UaGfSFa3KSzbor4rlK9wtqq3opzRVEGXSOvjKug= X-Google-Smtp-Source: APXvYqy0V0z0fUPp+YFLcCCQwGjcDzbZSpK21Bm08rHzUgsy90LIvXr6rbt7Zzo3GeuincJdbVm5/emHW/XsFw20DAc= X-Received: by 2002:a19:ef05:: with SMTP id n5mr845536lfh.192.1568695216116; Mon, 16 Sep 2019 21:40:16 -0700 (PDT) MIME-Version: 1.0 References: <827BB5C3-2143-450A-BC3D-72F98CD0B475@mit.edu> <1BEA1464-9B31-4FBF-8619-16096F13BBDD@mit.edu> In-Reply-To: <1BEA1464-9B31-4FBF-8619-16096F13BBDD@mit.edu> From: Dick Hardt Date: Mon, 16 Sep 2019 21:40:04 -0700 Message-ID: To: Justin Richer Cc: =?UTF-8?Q?Robache_Herv=C3=A9?= , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001e19460592b85130" Archived-At: Subject: Re: [OAUTH-WG] Question regarding RFC 7592 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: Tue, 17 Sep 2019 04:40:23 -0000 --0000000000001e19460592b85130 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The registration supports the client having a jwks, so if the client provides jwks, then using them to sign an authentication request seems easier than trying to manage an access token. The token endpoint is an API as well. We would agree that it is not a resource, but a management API. Similarly, I see the client's management of its registration to not be a resource operation, but a management API. =E1=90=A7 On Mon, Sep 16, 2019 at 7:36 PM Justin Richer wrote: > I don=E2=80=99t see a reason to use an assertion here. JWT authentication= would > require at least a secret if not a key of some type for authentication fo= r > all clients, and it was determined that dynamic registration shouldn=E2= =80=99t > require the clients (even public clients) to support things they weren=E2= =80=99t > already capable of doing. Besides, the management endpoint isn=E2=80=99t = a token > endpoint (though I=E2=80=99m curious to hear why you=E2=80=99d say that) = =E2=80=94 it=E2=80=99s an API you > can call to manage a client=E2=80=99s registration data over time. Sounds= like an > RS, if you ask me. > > =E2=80=94 Justin > > On Sep 15, 2019, at 1:05 AM, Dick Hardt wrote: > > Curious why the client management API uses bearer tokens rather than JWTs > per RFC 7523 for the client to authenticate. The client management API > seems more similar to a token endpoint than a resource. > =E1=90=A7 > > On Fri, Sep 13, 2019 at 12:08 PM Justin Richer wrote: > >> Travis has this correct =E2=80=94 the =E2=80=9Cregistration access token= =E2=80=9D is passed to >> the client for the express purpose of accessing the client management AP= I, >> and is not the same as, or entangled with, any access tokens that the >> client requests through the OAuth process after the registration has >> occurred. The reasons for this separation are many, but at the core it >> comes down to the client always acting on its own behalf when it does >> registration, and acting on behalf of some other party (usually a user) >> when it=E2=80=99s doing OAuth. Additionally, registration management is = a function >> of the AS, whereas the protected APIs are a function of the RS =E2=80=94= note this >> is a logical separation and there=E2=80=99s nothing stopping AS and RS f= unctions >> from being deployed in any number of patterns. >> >> A few common questions we got asked when writing this functionality into >> the spec: >> >> *Why use an access token at all*? Because it=E2=80=99s a credential for = a >> specific API issued by the AS and handed to the client in a programmatic >> manner. This is exactly what OAuth tokens were made for. >> >> *Why not use the client=E2=80=99s credentials*? Because not all clients = are set >> up to have credentials, plus we=E2=80=99d be spreading the requirement t= o support >> different kinds of client credentials to another endpoint. >> >> *Why not issue an authorization code*? Because then the client would >> need to make yet another round trip, and not all clients are >> authorization-code-grant clients to begin with. >> >> *Why not make a new grant type*? Because then the client would need to >> make yet another round trip, and we=E2=80=99d have to invent a whole new= grant type >> with a new temporary credential when we could just use that temporary >> credential directly instead. >> >> =E2=80=94 Justin >> >> On Sep 13, 2019, at 8:23 AM, Robache Herv=C3=A9 = wrote: >> >> Thanks Travis >> >> I understand that, once the client has retrieved its [client_id] through >> RFC7591 initial registration, it is then able to ask for an access token >> that will be used for accessing the RFC7592 entry-points. Am I right? >> >> Best regards >> >> Herv=C3=A9 >> >> *De :* Travis Spencer [mailto:travis.spencer@curity.io >> ] >> *Envoy=C3=A9 :* ven. 13 13:30 >> *=C3=80 :* Robache Herv=C3=A9 >> *Cc :* oauth@ietf.org >> *Objet :* Re: [OAUTH-WG] Question regarding RFC 7592 >> >> No. The initial access token is issued by the AS when registration is >> protected (appendix 1.2 in RFC 7591). As stated in section 1.2, the meth= od >> and means by which this is obtained can vary. The registration access to= ken >> in RFC 7592 is used to protect the registration management API and allow >> updates to the client after it is registered. You might have one (the >> registration access token) but not the other (initial access token) when >> open registration is allowed (appendix 1.1 in RFC 7591). >> >> HTH! >> >> On Fri, Sep 13, 2019 at 7:37 AM Robache Herv=C3=A9 >> wrote: >> >> Hi >> >> RFC 7592 introduces a =C2=AB Registration Access Token =C2=BB. Are this = token and >> the way to get it similar to what is specified as =E2=80=9CInitial Acces= s Token=E2=80=9D in >> RFC 7591/Appendix A ? >> >> If so, can the Open Dynamic Client Registration (RFC7591/A.1.1) be >> extrapolated to RFC7592 as the same way? >> >> Thanks in advance for your clarification. >> >> Herv=C3=A9 ROBACHE >> Direction Marketing et D=C3=A9veloppement >> >> LIGNE DIRECTE >> T. +33(0)1 55 23 55 45 >> herve.robache@stet.eu >> >> >> >> >> >> >> >> STET (SIEGE SOCIAL) >> 100, Esplanade du G=C3=A9n=C3=A9ral de Gaulle >> C=C5=93ur D=C3=A9fense =E2=80=93 Tour B >> 92932 La D=C3=A9fense cedex >> >> www.stet.eu >> >> >> >> Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'= intention >> exclusive de ses destinataires et sont confidentiels. >> Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, >> merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me et= d'en avertir >> imm=C3=A9diatement l'exp=C3=A9diteur. >> Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'= est >> pas conforme =C3=A0 sa destination, toute diffusion ou toute publication= , totale >> ou partielle, est interdite. >> L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de ce messa= ge >> =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3=A9cline toute= responsabilit=C3=A9 au >> titre de ce message dans l'hypoth=C3=A8se o=C3=B9 il aurait =C3=A9t=C3= =A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou >> falsifi=C3=A9. >> N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'environnem= ent. >> >> This message and any attachments is intended solely for the intended >> addressees and is confidential. >> If you receive this message in error, or are not the intended >> recipient(s), please delete it and any copies from your systems and >> immediately notify the sender. >> Any unauthorized view, use that does not comply with its purpose, >> dissemination or disclosure, either whole or partial, is prohibited. >> Since the internet cannot guarantee the integrity of this message which >> may not be reliable, STET shall not be liable for the message if modifie= d, >> changed or falsified. >> Do not print this message unless it is necessary, please consider the >> environment. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'= intention >> exclusive de ses destinataires et sont confidentiels. >> Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, >> merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me et= d'en avertir >> imm=C3=A9diatement l'exp=C3=A9diteur. >> Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'= est >> pas conforme =C3=A0 sa destination, toute diffusion ou toute publication= , totale >> ou partielle, est interdite. >> L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de ce messa= ge >> =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3=A9cline toute= responsabilit=C3=A9 au >> titre de ce message dans l'hypoth=C3=A8se o=C3=B9 il aurait =C3=A9t=C3= =A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou >> falsifi=C3=A9. >> N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'environnem= ent. >> >> This message and any attachments is intended solely for the intended >> addressees and is confidential. >> If you receive this message in error, or are not the intended >> recipient(s), please delete it and any copies from your systems and >> immediately notify the sender. >> Any unauthorized view, use that does not comply with its purpose, >> dissemination or disclosure, either whole or partial, is prohibited. >> Since the internet cannot guarantee the integrity of this message which >> may not be reliable, STET shall not be liable for the message if modifie= d, >> changed or falsified. >> Do not print this message unless it is necessary, please consider the >> environment. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > --0000000000001e19460592b85130 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The registration supports the client having a jwks, so if = the client provides jwks, then using them to sign an authentication request= seems easier than trying to manage an access token.=C2=A0

The token endpoint is an API as well. We would agree that it is not a re= source, but a management API. Similarly, I see the client's management = of its registration to not be a resource operation, but a management API.
=3D""=E1=90=A7

On Mon, Sep 16, 2019 at 7:36 PM Justin = Richer <jricher@mit.edu> wrote= :
I don=E2=80=99t see a reason to use an assertion here. JWT authentication w= ould require at least a secret if not a key of some type for authentication= for all clients, and it was determined that dynamic registration shouldn= =E2=80=99t require the clients (even public clients) to support things they weren=E2=80=99t already capable of doing. Besides, = the management endpoint isn=E2=80=99t a token endpoint (though I=E2=80=99m = curious to hear why you=E2=80=99d say that) =E2=80=94 it=E2=80=99s an API y= ou can call to manage a client=E2=80=99s registration data over time. Sound= s like an RS, if you ask me.

=E2=80=94 Justin

On Sep 15, 2019, at 1:05 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

Curious why=C2=A0the client management API uses bearer tok= ens rather than JWTs per RFC 7523 for the client to authenticate. The clien= t management API seems more similar to a token endpoint than a resource.
3D""=E1=90=A7

On Fri, Sep 13, 2019 at 12:08 PM Just= in Richer <jricher@= mit.edu> wrote:
Travis has this correct =E2=80=94 the =E2=80=9Cregistration access tok= en=E2=80=9D is passed to the client for the express purpose of accessing th= e client management API, and is not the same as, or entangled with, any acc= ess tokens that the client requests through the OAuth process after the registration has o= ccurred. The reasons for this separation are many, but at the core it comes= down to the client always acting on its own behalf when it does registrati= on, and acting on behalf of some other party (usually a user) when it=E2=80=99s doing OAuth. Additionally, = registration management is a function of the AS, whereas the protected APIs= are a function of the RS =E2=80=94 note this is a logical separation and t= here=E2=80=99s nothing stopping AS and RS functions from being deployed in any number of patterns.=C2=A0

A few common questions we got asked when writing this functionality in= to the spec:

Why use an access token at all? Because it=E2=80=99s a credenti= al for a specific API issued by the AS and handed to the client in a progra= mmatic manner. This is exactly what OAuth tokens were made for.=C2=A0

Why not use the client=E2=80=99s credentials? Because not all c= lients are set up to have credentials, plus we=E2=80=99d be spreading the r= equirement to support different kinds of client credentials to another endp= oint.=C2=A0

Why not issue an authorization code? Because then the client wo= uld need to make yet another round trip, and not all clients are authorizat= ion-code-grant clients to begin with.=C2=A0

Why not make a new grant type? Because then the client would ne= ed to make yet another round trip, and we=E2=80=99d have to invent a whole = new grant type with a new temporary credential when we could just use that = temporary credential directly instead.=C2=A0

=E2=80=94 Justin

On Sep 13, 2019, at 8:23 AM, Robache Herv=C3=A9 <herve.robache@stet.eu> wrot= e:

Thanks Travis
=C2=A0
I understand that, once the client has retrieved its= [client_id] through RFC7591 initial registration, it is then able to ask f= or an access token that will be used for accessing the RFC7592 entry-points. Am I right?<= /span>
=C2=A0
Best regards
=C2=A0
Herv=C3=A9
=C2=A0
De=C2=A0:=C2=A0Travis Spencer [mailto:travis.spencer@curity.io]=C2=A0
Envoy=C3=A9=C2=A0:=C2=A0ven. 13 13:30
=C3=80=C2=A0:=C2=A0Robache Herv=C3=A9
Cc=C2=A0:=C2=A0oa= uth@ietf.org
Objet=C2=A0:=C2=A0Re: [OAUTH-WG] Question r= egarding RFC 7592
=C2=A0
No. The initial access token is issued by the AS when registration is prote= cted (appendix 1.2 in RFC 7591). As stated in section 1.2, the method and m= eans by which this is obtained can vary. The registration access token in R= FC 7592 is used to protect the registration management API and allow updates to the client after it is registered. You= might have one (the registration access token) but not the other (initial = access token) when open registration is allowed (appendix 1.1 in RFC 7591).=
=C2=A0
HTH!
=C2=A0
On Fri, Sep 13, 2019 at 7:37 AM Robache Herv=C3=A9 <herve.robache@stet.eu> wrote:
Hi
=C2=A0
RFC 7592 introduces a =C2=AB=C2=A0Registration Access = Token=C2=A0=C2=BB. Are this token and the way to get it similar to what is = specified as =E2=80=9CInitial Access Token=E2=80=9D in RFC 7591/Appendix A = ?
=C2=A0
If so, can the Open Dynamic Client Registration (RFC75= 91/A.1.1) be extrapolated to RFC7592 as the same way?<= /div>
=C2=A0
Thanks in advance for your clarification.
=C2=A0
Herv=C3=A9 ROBACHE
Direction Marketing et D=C3=A9veloppement<= /div>
=C2=A0
LIGNE DIRECTE
T. +33(0)1 55 23= 55 45
=C2=A0
<image001.png>
=C2=A0
=C2=A0

<image0= 02.png>
=C2=A0
STET (SIEGE SOCI= AL)
100, Esplanade d= u G=C3=A9n=C3=A9ral de Gaulle
C=C5=93ur D=C3= =A9fense =E2=80=93 Tour B
92932 La D=C3=A9= fense cedex
=C2=A0=
=C2=A0

Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'= ;intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me = et d'en avertir imm=C3=A9diatement l'exp=C3=A9diteur.
Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'= ;est pas conforme =C3=A0 sa destination, toute diffusion ou toute publicati= on, totale ou partielle, est interdite.
L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de= ce message =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3= =A9cline toute responsabilit=C3=A9 au titre de ce message dans l'hypoth= =C3=A8se o=C3=B9 il aurait =C3=A9t=C3=A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou= falsifi=C3=A9.
N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'envir= onnement.

This message and any attachments is intended solely for the intended addres= sees and is confidential.
If you receive this message in error, or are not the intended recipient(s),= please delete it and any copies from your systems and immediately notify t= he sender.
Any unauthorized view, use that does not comply with its purpose, dissemina= tion or disclosure, either whole or partial, is prohibited.
Since the internet cannot guarantee the integrity of this message which may= not be reliable, STET shall not be liable for the message if modified, cha= nged or falsified.
Do not print this message unless it is necessary, please consider the envir= onment.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailma= n/listinfo/oauth


Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'= ;intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me = et d'en avertir imm=C3=A9diatement l'exp=C3=A9diteur.
Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'= ;est pas conforme =C3=A0 sa destination, toute diffusion ou toute publicati= on, totale ou partielle, est interdite.
L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de= ce message =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3= =A9cline toute responsabilit=C3=A9 au titre de ce message dans l'hypoth= =C3=A8se o=C3=B9 il aurait =C3=A9t=C3=A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou= falsifi=C3=A9.
N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'envir= onnement.

This message and any attachments is intended solely for the intended addres= sees and is confidential.
If you receive this message in error, or are not the intended recipient(s),= please delete it and any copies from your systems and immediately notify t= he sender.
Any unauthorized view, use that does not comply with its purpose, dissemina= tion or disclosure, either whole or partial, is prohibited.
Since the internet cannot guarantee the integrity of this message which may= not be reliable, STET shall not be liable for the message if modified, cha= nged or falsified.
Do not print this message unless it is necessary, please consider the envir= onment.
______________________________________= _________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--0000000000001e19460592b85130-- From nobody Mon Sep 16 23:11:15 2019 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 E1722120145 for ; Mon, 16 Sep 2019 23:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=forgerock.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 T-uux9gLgIJy for ; Mon, 16 Sep 2019 23:11:09 -0700 (PDT) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (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 308FF1200E9 for ; Mon, 16 Sep 2019 23:11:09 -0700 (PDT) Received: by mail-wr1-x441.google.com with SMTP id l11so1721247wrx.5 for ; Mon, 16 Sep 2019 23:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zizmLPcHFX9eV5scP+CViSNflmSHnnpUDTQI0y+/JXg=; b=EsBIemlT3AJJHICP4qK0KIioTvTzxj8yaQYh7i9mKgJBcahq/IImZ8FMRX7642zdcY Q992fptzd8O8qrv9PhJ7S/a0t1HrtTSOWnKYrkUHCLxFfr+Ia3i6Z56NTIdCNGyLEZEd 9Pef52xFk7kr72sbYoNiqOx9EEhoIkVmm2F18= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zizmLPcHFX9eV5scP+CViSNflmSHnnpUDTQI0y+/JXg=; b=JJc98SYDEHAVdFYA1ZNqW4ZVrzfJZJtPBCAr8Kv++9cl1X9EhJ4FD3JOaMWdQ9kn2G 5Gb8ZUIHRHHGHreUOgEY3q7orkEtyXtIm3CpTD4eNhRwvOsMc2GXhtrm3btS2Rnr5EXJ 9V4JD1R9BoTcXCtGMc0P+qaLILxWs2UsLJsNV/ZEmYFMIOe7UjCCS7fJjnfQpLSGBl5k EsNRP08qVLZvr076Yb3Rulnt/P0GbwKZp1QtQntxxIHw1J/W51G3cvpgjalRnTT+YLIA Gf6ev7PfZ0h+wLcgt0WJ5G2eIBQLUTQN3DDT9rTGi1JLbebNrYPPIAw2mTrc+PUSLcgB 0uSg== X-Gm-Message-State: APjAAAWlB71B939EERCHXnhxunzOBoO3wodZoP4wWDoRXNRHBrdmFNU+ RU67+C231O5ipU4JgBCVbJ3xww== X-Google-Smtp-Source: APXvYqyb3+bm803lh41m+/7HbhIFy0e4aL5xTpsoFELgxiUi/dwkRuNN5Bdrzcn2C1BAuCBfUmjtKg== X-Received: by 2002:a5d:67c3:: with SMTP id n3mr1509631wrw.294.1568700667350; Mon, 16 Sep 2019 23:11:07 -0700 (PDT) Received: from [192.168.1.65] (253.58.93.209.dyn.plus.net. [209.93.58.253]) by smtp.gmail.com with ESMTPSA id j22sm2636569wre.45.2019.09.16.23.11.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Sep 2019 23:11:06 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-6B9192D6-4059-4331-BA4A-E0F251CFB4D4 Mime-Version: 1.0 (1.0) From: Neil Madden X-Mailer: iPhone Mail (16G102) In-Reply-To: <1BEA1464-9B31-4FBF-8619-16096F13BBDD@mit.edu> Date: Tue, 17 Sep 2019 07:11:05 +0100 Cc: Dick Hardt , =?utf-8?Q?Robache_Herv=C3=A9?= , "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <827BB5C3-2143-450A-BC3D-72F98CD0B475@mit.edu> <1BEA1464-9B31-4FBF-8619-16096F13BBDD@mit.edu> To: Justin Richer Archived-At: Subject: Re: [OAUTH-WG] Question regarding RFC 7592 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: Tue, 17 Sep 2019 06:11:13 -0000 --Apple-Mail-6B9192D6-4059-4331-BA4A-E0F251CFB4D4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The choice of using an access token here did provoke quite a lot of question= s from developers. Does the token have a scope? Who is the resource owner - t= he client itself? Can the token be introspected? Revoked? Exchanged? Can it h= ave PoP/sender-constrained restrictions? That said, I think it makes sense to use an access token here, especially if= there is a different party doing registration and management on behalf of t= he client. That party can retain the RAT without needing to impersonate the c= lient.=20 =E2=80=94 Neil > On 17 Sep 2019, at 03:36, Justin Richer wrote: >=20 > I don=E2=80=99t see a reason to use an assertion here. JWT authentication w= ould require at least a secret if not a key of some type for authentication f= or all clients, and it was determined that dynamic registration shouldn=E2=80= =99t require the clients (even public clients) to support things they weren=E2= =80=99t already capable of doing. Besides, the management endpoint isn=E2=80= =99t a token endpoint (though I=E2=80=99m curious to hear why you=E2=80=99d s= ay that) =E2=80=94 it=E2=80=99s an API you can call to manage a client=E2=80= =99s registration data over time. Sounds like an RS, if you ask me. >=20 > =E2=80=94 Justin >=20 >> On Sep 15, 2019, at 1:05 AM, Dick Hardt wrote: >>=20 >> Curious why the client management API uses bearer tokens rather than JWTs= per RFC 7523 for the client to authenticate. The client management API seem= s more similar to a token endpoint than a resource. >> =E1=90=A7 >>=20 >>> On Fri, Sep 13, 2019 at 12:08 PM Justin Richer wrote: >>> Travis has this correct =E2=80=94 the =E2=80=9Cregistration access token= =E2=80=9D is passed to the client for the express purpose of accessing the c= lient management API, and is not the same as, or entangled with, any access t= okens that the client requests through the OAuth process after the registrat= ion has occurred. The reasons for this separation are many, but at the core i= t comes down to the client always acting on its own behalf when it does regi= stration, and acting on behalf of some other party (usually a user) when it=E2= =80=99s doing OAuth. Additionally, registration management is a function of t= he AS, whereas the protected APIs are a function of the RS =E2=80=94 note th= is is a logical separation and there=E2=80=99s nothing stopping AS and RS fu= nctions from being deployed in any number of patterns.=20 >>>=20 >>> A few common questions we got asked when writing this functionality into= the spec: >>>=20 >>> Why use an access token at all? Because it=E2=80=99s a credential for a s= pecific API issued by the AS and handed to the client in a programmatic mann= er. This is exactly what OAuth tokens were made for.=20 >>>=20 >>> Why not use the client=E2=80=99s credentials? Because not all clients ar= e set up to have credentials, plus we=E2=80=99d be spreading the requirement= to support different kinds of client credentials to another endpoint.=20 >>>=20 >>> Why not issue an authorization code? Because then the client would need t= o make yet another round trip, and not all clients are authorization-code-gr= ant clients to begin with.=20 >>>=20 >>> Why not make a new grant type? Because then the client would need to mak= e yet another round trip, and we=E2=80=99d have to invent a whole new grant t= ype with a new temporary credential when we could just use that temporary cr= edential directly instead.=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Sep 13, 2019, at 8:23 AM, Robache Herv=C3=A9 = wrote: >>>>=20 >>>> Thanks Travis >>>> =20 >>>> I understand that, once the client has retrieved its [client_id] throug= h RFC7591 initial registration, it is then able to ask for an access token t= hat will be used for accessing the RFC7592 entry-points. Am I right? >>>> =20 >>>> Best regards >>>> =20 >>>> Herv=C3=A9 >>>> =20 >>>> De : Travis Spencer [mailto:travis.spencer@curity.io]=20 >>>> Envoy=C3=A9 : ven. 13 13:30 >>>> =C3=80 : Robache Herv=C3=A9 >>>> Cc : oauth@ietf.org >>>> Objet : Re: [OAUTH-WG] Question regarding RFC 7592 >>>> =20 >>>> No. The initial access token is issued by the AS when registration is p= rotected (appendix 1.2 in RFC 7591). As stated in section 1.2, the method an= d means by which this is obtained can vary. The registration access token in= RFC 7592 is used to protect the registration management API and allow updat= es to the client after it is registered. You might have one (the registratio= n access token) but not the other (initial access token) when open registrat= ion is allowed (appendix 1.1 in RFC 7591). >>>> =20 >>>> HTH! >>>> =20 >>>> On Fri, Sep 13, 2019 at 7:37 AM Robache Herv=C3=A9 wrote: >>>> Hi >>>> =20 >>>> RFC 7592 introduces a =C2=AB Registration Access Token =C2=BB. Are this= token and the way to get it similar to what is specified as =E2=80=9CInitia= l Access Token=E2=80=9D in RFC 7591/Appendix A ? >>>> =20 >>>> If so, can the Open Dynamic Client Registration (RFC7591/A.1.1) be extr= apolated to RFC7592 as the same way? >>>> =20 >>>> Thanks in advance for your clarification. >>>> =20 >>>> Herv=C3=A9 ROBACHE >>>> Direction Marketing et D=C3=A9veloppement >>>> =20 >>>> LIGNE DIRECTE >>>> T. +33(0)1 55 23 55 45 >>>> herve.robache@stet.eu >>>> =20 >>>> >>>> =20 >>>> =20 >>>>=20 >>>> >>>> =20 >>>> STET (SIEGE SOCIAL) >>>> 100, Esplanade du G=C3=A9n=C3=A9ral de Gaulle >>>> C=C5=93ur D=C3=A9fense =E2=80=93 Tour B >>>> 92932 La D=C3=A9fense cedex >>>> =20 >>>> www.stet.eu >>>> =20 >>>>=20 >>>>=20 >>>> Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l= 'intention exclusive de ses destinataires et sont confidentiels. >>>> Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me e= t d'en avertir imm=C3=A9diatement l'exp=C3=A9diteur. >>>> Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n= 'est pas conforme =C3=A0 sa destination, toute diffusion ou toute publicatio= n, totale ou partielle, est interdite. >>>> L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de ce mess= age =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3=A9cline toute= responsabilit=C3=A9 au titre de ce message dans l'hypoth=C3=A8se o=C3=B9 il= aurait =C3=A9t=C3=A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou falsifi=C3=A9. >>>> N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'environne= ment. >>>>=20 >>>> This message and any attachments is intended solely for the intended ad= dressees and is confidential. >>>> If you receive this message in error, or are not the intended recipient= (s), please delete it and any copies from your systems and immediately notif= y the sender. >>>> Any unauthorized view, use that does not comply with its purpose, disse= mination or disclosure, either whole or partial, is prohibited. >>>> Since the internet cannot guarantee the integrity of this message which= may not be reliable, STET shall not be liable for the message if modified, c= hanged or falsified. >>>> Do not print this message unless it is necessary, please consider the e= nvironment. >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l= 'intention exclusive de ses destinataires et sont confidentiels. >>>> Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me e= t d'en avertir imm=C3=A9diatement l'exp=C3=A9diteur. >>>> Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n= 'est pas conforme =C3=A0 sa destination, toute diffusion ou toute publicatio= n, totale ou partielle, est interdite. >>>> L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de ce mess= age =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3=A9cline toute= responsabilit=C3=A9 au titre de ce message dans l'hypoth=C3=A8se o=C3=B9 il= aurait =C3=A9t=C3=A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou falsifi=C3=A9. >>>> N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'environne= ment. >>>>=20 >>>> This message and any attachments is intended solely for the intended ad= dressees and is confidential. >>>> If you receive this message in error, or are not the intended recipient= (s), please delete it and any copies from your systems and immediately notif= y the sender. >>>> Any unauthorized view, use that does not comply with its purpose, disse= mination or disclosure, either whole or partial, is prohibited. >>>> Since the internet cannot guarantee the integrity of this message which= may not be reliable, STET shall not be liable for the message if modified, c= hanged or falsified. >>>> Do not print this message unless it is necessary, please consider the e= nvironment. >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-6B9192D6-4059-4331-BA4A-E0F251CFB4D4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The= choice of using an access token here did provoke quite a lot of questions f= rom developers. Does the token have a scope? Who is the resource owner - the= client itself? Can the token be introspected? Revoked? Exchanged? Can it ha= ve PoP/sender-constrained restrictions?

That said, I think it makes sense to use an access token here, e= specially if there is a different party doing registration and management on= behalf of the client. That party can retain the RAT without needing to impe= rsonate the client. 

=E2= =80=94 Neil

On 17 Sep 2019, at 03:36, Justin Riche= r <jricher@mit.edu> wrote:
<= br>
I don=E2=80=99t see a reason to use an assertion here. JWT authentication wo= uld require at least a secret if not a key of some type for authentication f= or all clients, and it was determined that dynamic registration shouldn=E2=80= =99t require the clients (even public clients) to support things they weren=E2=80=99t already capable of doing. Besides, t= he management endpoint isn=E2=80=99t a token endpoint (though I=E2=80=99m cu= rious to hear why you=E2=80=99d say that) =E2=80=94 it=E2=80=99s an API you c= an call to manage a client=E2=80=99s registration data over time. Sounds lik= e an RS, if you ask me.

=E2=80=94 Justin

On Sep 15, 2019, at 1:05 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
=
Curious why the client management API uses b= earer tokens rather than JWTs per RFC 7523 for the client to authenticate. T= he client management API seems more similar to a token endpoint than a resou= rce.
3D==E1=90=A7

On Fri, Sep 13, 2019 at 12:08 PM Justi= n Richer <jricher@mit.edu> wrote:
Travis has this correct= =E2=80=94 the =E2=80=9Cregistration access token=E2=80=9D is passed to the c= lient for the express purpose of accessing the client management API, and is= not the same as, or entangled with, any access tokens that the client requests through the OAuth process after the registration has oc= curred. The reasons for this separation are many, but at the core it comes d= own to the client always acting on its own behalf when it does registration,= and acting on behalf of some other party (usually a user) when it=E2=80=99s doing OAuth. Additionally, r= egistration management is a function of the AS, whereas the protected APIs a= re a function of the RS =E2=80=94 note this is a logical separation and ther= e=E2=80=99s nothing stopping AS and RS functions from being deployed in any number of patterns. 

A few common questions we got asked when writing this functi= onality into the spec:

Why use an access token at all? Because it= =E2=80=99s a credential for a specific API issued by the AS and handed to th= e client in a programmatic manner. This is exactly what OAuth tokens were ma= de for. 

Why not use the client=E2=80=99s credentials? Because not all clients are set up to have credentials, plus we=E2=80=99= d be spreading the requirement to support different kinds of client credenti= als to another endpoint. 

Why not issue an authorization code? Becau= se then the client would need to make yet another round trip, and not all cl= ients are authorization-code-grant clients to begin with. 

Why not make a new grant type? Because the= n the client would need to make yet another round trip, and we=E2=80=99d hav= e to invent a whole new grant type with a new temporary credential when we c= ould just use that temporary credential directly instead. 

=E2=80=94 Justin

On Sep 13, 2019, at 8:23 AM, Robache Herv=C3=A9 <herve.robache@st= et.eu> wrote:

Thanks Travis
 <= /span>
I understand that, once the client has retr= ieved its [client_id] through RFC7591 initial registration, it is then able t= o ask for an access token that will be used for accessing the RFC7592 entry-points. Am I right?
 <= /span>
Best regards
 <= /span>
Herv=C3=A9<= /u>
 <= /span>
De : Travis Spencer [mailto:travis.spencer@curity.io] 
Envoy=C3=A9 : ven. 13 13:30
=C3=80 : Robache Herv=C3=A9
Cc : oauth@ietf= .org
Objet : Re: [OAUTH-WG] Question regarding RFC 7592<= u class=3D"">
 
No. The initial access token is issued by the AS when registration is protec= ted (appendix 1.2 in RFC 7591). As stated in section 1.2, the method and mea= ns by which this is obtained can vary. The registration access token in RFC 7= 592 is used to protect the registration management API and allow updates to the client after it is registered. You m= ight have one (the registration access token) but not the other (initial acc= ess token) when open registration is allowed (appendix 1.1 in RFC 7591).
 
HTH!
 
On Fri, Sep 13, 2019 at 7:37 AM Robache Herv=C3=A9 <herve.robache@stet.eu> wrote:
Hi
 
RFC 7592 introduces a =C2=AB Registrati= on Access Token =C2=BB. Are this token and the way to get it similar to= what is specified as =E2=80=9CInitial Access Token=E2=80=9D in RFC 7591/App= endix A ?
 
If so, can the Open Dynamic Client Registrat= ion (RFC7591/A.1.1) be extrapolated to RFC7592 as the same way?
 
Thanks in advance for your clarification.
 
Herv=C3=A9 ROBACHE
Direction Marketing et D=C3=A9veloppement
 
LIGNE D= IRECTE
T. +33= (0)1 55 23 55 45
herve.robache@stet.eu
 <= /u>
<image001.png>
 <= /u>
 <= /u>

<image002.png&= gt;
 <= /u>
STET (= SIEGE SOCIAL)
100, E= splanade du G=C3=A9n=C3=A9ral de Gaulle
C=C5=93= ur D=C3=A9fense =E2=80=93 Tour B<= /div>
92932 L= a D=C3=A9fense cedex
 =
www.stet.eu
 


Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'inte= ntion exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3=A9, m= erci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me et d'en= avertir imm=C3=A9diatement l'exp=C3=A9diteur.
Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'est p= as conforme =C3=A0 sa destination, toute diffusion ou toute publication, tot= ale ou partielle, est interdite.
L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de ce message =C3= =A9lectronique susceptible d'alt=C3=A9ration, STET d=C3=A9cline toute respon= sabilit=C3=A9 au titre de ce message dans l'hypoth=C3=A8se o=C3=B9 il aurait= =C3=A9t=C3=A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou falsifi=C3=A9.
N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'environnement.=

This message and any attachments is intended solely for the intended address= ees and is confidential.
If you receive this message in error, or are not the intended recipient(s), p= lease delete it and any copies from your systems and immediately notify the s= ender.
Any unauthorized view, use that does not comply with its purpose, disseminat= ion or disclosure, either whole or partial, is prohibited.
Since the internet cannot guarantee the integrity of this message which may n= ot be reliable, STET shall not be liable for the message if modified, change= d or falsified.
Do not print this message unless it is necessary, please consider the enviro= nment.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.o= rg/mailman/listinfo/oauth


Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'inte= ntion exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3=A9, m= erci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me et d'en= avertir imm=C3=A9diatement l'exp=C3=A9diteur.
Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'est p= as conforme =C3=A0 sa destination, toute diffusion ou toute publication, tot= ale ou partielle, est interdite.
L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de ce message =C3= =A9lectronique susceptible d'alt=C3=A9ration, STET d=C3=A9cline toute respon= sabilit=C3=A9 au titre de ce message dans l'hypoth=C3=A8se o=C3=B9 il aurait= =C3=A9t=C3=A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou falsifi=C3=A9.
N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'environnement.=

This message and any attachments is intended solely for the intended address= ees and is confidential.
If you receive this message in error, or are not the intended recipient(s), p= lease delete it and any copies from your systems and immediately notify the s= ender.
Any unauthorized view, use that does not comply with its purpose, disseminat= ion or disclosure, either whole or partial, is prohibited.
Since the internet cannot guarantee the integrity of this message which may n= ot be reliable, STET shall not be liable for the message if modified, change= d or falsified.
Do not print this message unless it is necessary, please consider the enviro= nment.
___________________________= ____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinf= o/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth<= br class=3D"">

________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-6B9192D6-4059-4331-BA4A-E0F251CFB4D4-- From nobody Tue Sep 17 06:20:47 2019 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 801FB12006B for ; Tue, 17 Sep 2019 06:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=iwelcome.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 RE0314JY_3_o for ; Tue, 17 Sep 2019 06:20:43 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0621.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::621]) (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 364061200BA for ; Tue, 17 Sep 2019 06:20:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FMpIUlgmw0JzsYQTPum3Fr/0zSOZIbbqLuVh4dUWG6Jl2H5AYfeMIkEUOgHH82U2Mh1iFeVOLej9jUqu9yZs1ZaUX2blAv5/zEuSZtOaYChui6dQ1zArCesP3lZa+JwcTxUMXc7tt1EBZKWJJvKCFgI6WIKWBIJGUZguhBYf366nw7gtC4L0ubcZC0V2K8OhlHy2xkN4u0RD2vNcjK6FHSGCzMEgDRCRHN5pj0puQEcgf/FmH9WuyCUPbckV2i2t51I0CeA6das8KEuekTpHtXpr+7+M5o8JrCekcnvsmg0XaiSqssAXc5N4j1aPwFkQEnnAyogkw1XkvtqeuxaVuw== 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=KHT83jszM5Jy8nllBpY6bsnN3sr4IJhKaRmPRhD5H90=; b=cEodSpXo1GGrgQJNy4KUbBzlxg1OaDvR2k9ooMCpyAlcRJhmbUG4VPNRpOVBU850kkyulHHMrQYYDnS6MU2N43jdlovxikU0jLgp2NlVJgZhOybHqA2XkAB6ODKCVvGTB01fX49RQpjJ8urTkwIy1EQ8QNarZ7zAoLLYGU9YXLoFqKSVOsA89/2QCM7Vln6rOFP8QTOdFlMEbCLK2X9z0jrhLLa956fUJsZojOJRIWFFfZS1jwx9Vts6WYtwzI7p21uhUHqFEjBD+L20QOhu5g4uBAsG91+WVPxNXXyZYrS4/8GAlBtLhC01N05kQRiTPpE/H2OEQSjCmMFZDGj9iw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iwelcome.com; dmarc=pass action=none header.from=iwelcome.com; dkim=pass header.d=iwelcome.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iwelcome.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KHT83jszM5Jy8nllBpY6bsnN3sr4IJhKaRmPRhD5H90=; b=KXCZy4p42C9Mrcb5yhkgDektW+eWcndStUjOleW8pYZuv3Vj1FRUn8DaCPsA8rIEuqG7YCCw+PIFQMF7Xm4+Y2mkdGQlEi/pGcA1ffuHtvP8iNmIGEQCT+EdA1osO0FGtU7QgUEUnwlUazEGTwnJ+wpscCb0m+pKt3KegNpGJuY= Received: from VI1P190MB0317.EURP190.PROD.OUTLOOK.COM (10.165.197.26) by VI1P190MB0559.EURP190.PROD.OUTLOOK.COM (10.165.191.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.21; Tue, 17 Sep 2019 13:20:39 +0000 Received: from VI1P190MB0317.EURP190.PROD.OUTLOOK.COM ([fe80::38b1:d48d:fc49:384f]) by VI1P190MB0317.EURP190.PROD.OUTLOOK.COM ([fe80::38b1:d48d:fc49:384f%4]) with mapi id 15.20.2263.023; Tue, 17 Sep 2019 13:20:39 +0000 From: Jaap Francke To: "oauth@ietf.org" Thread-Topic: client authentication Thread-Index: AQHVbVqyFCnAe6TcNUCWhiz8H2uvBQ== Date: Tue, 17 Sep 2019 13:20:39 +0000 Message-ID: <2425F057-E2D8-46C3-A859-060245C309BB@iWelcome.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jaap.francke@iwelcome.com; x-originating-ip: [86.84.216.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c2c988a1-a44a-451c-2471-08d73b71d589 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7193020); SRVR:VI1P190MB0559; x-ms-traffictypediagnostic: VI1P190MB0559: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(376002)(396003)(39830400003)(366004)(53754006)(189003)(199004)(51874003)(256004)(54896002)(6486002)(6306002)(5660300002)(71190400001)(6436002)(6512007)(25786009)(236005)(66476007)(64756008)(26005)(66446008)(102836004)(2351001)(66556008)(5640700003)(316002)(186003)(476003)(8936002)(81166006)(81156014)(2616005)(3846002)(2906002)(86362001)(6506007)(2501003)(91956017)(6916009)(6116002)(76116006)(221733001)(99286004)(7116003)(36756003)(7736002)(33656002)(8676002)(66066001)(1730700003)(66946007)(606006)(966005)(486006)(508600001)(14454004)(44832011)(14444005)(3480700005)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P190MB0559; H:VI1P190MB0317.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: iwelcome.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: nr7pHQqvCOgitrpDCKy0oSgQe8k/Gw/7pwbfFVKRGB8ctoopG+pb+WB8W3n6zxMofKjbQULdlC6LHTJYU+WwO6KkAwVOQ602rpA5NX4zWj9p+Eg1pLWOLCksT9QrAUKiRDYV+CtenHx/wRyXS99OB+hTDseECy9I0qC3nsXVHyBBu1ft5uYGEDqz5VroW3M86GFcqOR/MO8it+kX6RUzeXtzpwsAnkpwGK2yVI44Z5Dy8HoTsCDPuqa73ZELcCMEiIZidiDsHBy6j45BVayB5OzSGNbZlA7H1neT6b3yXzUNMJfCm7XMRtwhYxjY1DtzY3hRqTZ96U/qQXjcX4550ypjcyszgT3hNcWFiqxtykGFv13+XVMX7ZaWGbhI5w/n6MX4fiBSPfntbYMDMlpnNCQCPfDrSAJHNirnDKNYHAY= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_2425F057E2D846C3A859060245C309BBiWelcomecom_" MIME-Version: 1.0 X-OriginatorOrg: iwelcome.com X-MS-Exchange-CrossTenant-Network-Message-Id: c2c988a1-a44a-451c-2471-08d73b71d589 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2019 13:20:39.3447 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d5d41fea-d7e6-42be-b3bb-05610e101f27 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: er7iye4Mkpp988kw5HMg59Uz0Nhe1W4N6oNPno2PcZzH74yVhlUAapK4jrhynasYoYieU5ixj4r+2AULcpIOpGmM/10t+CAJE6/GdKYetmM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P190MB0559 Archived-At: Subject: [OAUTH-WG] client authentication 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: Tue, 17 Sep 2019 13:20:47 -0000 --_000_2425F057E2D846C3A859060245C309BBiWelcomecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIHdhcyBleHBsb3JpbmcgdGhlIHRvcGljIG9mIGNsaWVudCBhdXRoZW50aWNh dGlvbiBpbiB2YXJpb3VzIFJGQ3MuDQpBIGZldyB0aGluZ3MgYXJlIG5vdCAxMDAlIGNsZWFyIHRv IG1lLCBJIHdvdWxkIGJlIGludGVyZXN0ZWQgdG8gZ2V0IHlvdXIgZmVlZGJhY2suDQoNClJGQzc1 OTEgc2V0cyB1cCB0aGUgcmVnaXN0cnkgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2Rz IG9uIHRoZSB0b2tlbiBlbmRwb2ludCBhbmQgYWRkczoNCi0gbm9uZQ0KLSBjbGllbnRfc2VjcmV0 X2Jhc2ljIChSRkMyNjE3KQ0KLSBjbGllbnRfc2VjcmV0X3Bvc3QgKFJGQzY3NDkpDQoNCkkgZG9u 4oCZdCB1bmRlcnN0YW5kIHdoeSB0aGF0IHJlZ2lzdHJ5IHNlZW1zIGxpbWl0ZWQgdG8gdGhlIHRv a2VuLWVuZHBvaW50LiBDbGllbnQgYXV0aGVudGljYXRpb24gYWxzbyBhcHBsaWVzIHRvIG90aGVy IHByb3RlY3RlZCAoT0F1dGgpIGVuZHBvaW50cyBzdWNoIGFzIHRva2VuIGludHJvc3BlY3QsIHNv IGl0IG1ha2VzIHNlbnNlIHRvIGhhdmUgYSBnZW5lcmljIChPQXV0aCkgY2xpZW50IGF1dGhlbnRp Y2F0aW9uIG1ldGhvZCByZWdpc3RyeS4NCg0KT0lEQyBzcGVjcyBpbmRpY2F0ZSBhIGZldyBtb3Jl Og0KLSBjbGllbnRfc2VjcmV0X2p3dA0KLSBwcml2YXRlX2tleV9qd3QNCklzIG15IHVuZGVyc3Rh bmRpbmcgY29ycmVjdCB0aGF0IGNsaWVudF9zZWNyZXRfand0IHJlZmVycyB0byB0aGUgc2FtZSBj bGllbnQgYXV0aGVudGljYXRpb24gbWV0aG9kIGFzIGRlc2NyaWJlZCBpbiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNzUyMyNzZWN0aW9uLTIuMiA/DQoNCkZ1cnRoZXJtb3JlIHRoZXJl IGlzIFJGQzY3NTAgd2hpY2ggc3VnZ2VzdCAzIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZWNoYW5p c21zIHdoaWNoIGFyZSBub3QgaW5jbHVkZWQgaW4gdGhlIHJlZ2lzdHJ5Og0KLSBCZWFyZXIgLyBh dXRob3Jpc2F0aW9uIHJlcXVlc3QgaGVhZGVyDQotIGJlYXJlciAvIFVSSSBxdWVyeSBwYXJhbWV0 ZXINCi0gYmVhcmVyIC8gZm9ybSBlbmNvZGVkIGJvZHkgcGFyYW1ldGVyDQpGb3IgZXhhbXBsZSwg dGhlIFJGQzc2NjIgc3VnZ2VzdHMgdG8gdXNlIHRoZSDigJxiZWFyZXIgLyBhdXRob3Jpc2F0aW9u IHJlcXVlc3QgaGVhZGVy4oCdIG1lY2hhbmlzbSBhcyBjbGllbnQgYXV0aGVudGljYXRpb24vYXV0 aG9yaXNhdGlvbiBtZWNoYW5pc20uDQpBbnkgcmVhc29uIHdoeSB0aGlzIHdhcyBub3QgZG9uZT8N Cg0KVGhhbmtzIGluIGFkdmFuY2UgZm9yIGFueSByZWxhdGVkIGZlZWRiYWNrLCByZWdhcmRzLA0K DQpKYWFwIEZyYW5ja2UNCg== --_000_2425F057E2D846C3A859060245C309BBiWelcomecom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIGFsbCwNCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgd2FzIGV4cGxvcmluZyB0aGUgdG9waWMg b2YgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGluIHZhcmlvdXMgUkZDcy48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+QSBmZXcgdGhpbmdzIGFyZSBub3QgMTAwJSBjbGVhciB0byBtZSwgSSB3b3VsZCBiZSBp bnRlcmVzdGVkIHRvIGdldCB5b3VyIGZlZWRiYWNrLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UkZDNzU5MSBzZXRzIHVwIHRoZSByZWdp c3RyeSBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgb24gdGhlIHRva2VuIGVuZHBv aW50IGFuZCBhZGRzOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tIG5vbmU8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+LSBjbGllbnRfc2VjcmV0X2Jhc2ljIChSRkMyNjE3KTwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4tIGNsaWVudF9zZWNyZXRfcG9zdCAoUkZDNjc0OSk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgZG9u4oCZdCB1bmRlcnN0YW5kIHdo eSB0aGF0IHJlZ2lzdHJ5IHNlZW1zIGxpbWl0ZWQgdG8gdGhlIHRva2VuLWVuZHBvaW50LiBDbGll bnQgYXV0aGVudGljYXRpb24gYWxzbyBhcHBsaWVzIHRvIG90aGVyIHByb3RlY3RlZCAoT0F1dGgp IGVuZHBvaW50cyBzdWNoIGFzIHRva2VuIGludHJvc3BlY3QsIHNvIGl0IG1ha2VzIHNlbnNlIHRv IGhhdmUgYSBnZW5lcmljIChPQXV0aCkgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZA0KIHJl Z2lzdHJ5LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+T0lEQyBzcGVjcyBpbmRpY2F0ZSBhIGZldyBtb3JlOjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4tJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiB2ZXJkYW5hLCBjaGFyY29hbCwg aGVsdmV0aWNhLCBhcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiBzbWFsbDsgb3JwaGFuczog Mjsgd2lkb3dzOiAyOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFz cz0iIj5jbGllbnRfc2VjcmV0X2p3dDwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiB2ZXJkYW5hLCBjaGFyY29hbCwgaGVsdmV0aWNhLCBhcmlhbCwg c2Fucy1zZXJpZjsgZm9udC1zaXplOiBzbWFsbDsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyBiYWNr Z3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0iIj4tJm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogdmVyZGFuYSwgY2hhcmNvYWwsIGhlbHZldGljYSwg YXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogc21hbGw7IG9ycGhhbnM6IDI7IHdpZG93czog MjsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+cHJpdmF0 ZV9rZXlfand0PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ib3JwaGFuczogMjsgd2lkb3dzOiAy OyIgY2xhc3M9IiI+PGZvbnQgZmFjZT0idmVyZGFuYSwgY2hhcmNvYWwsIGhlbHZldGljYSwgYXJp YWwsIHNhbnMtc2VyaWYiIHNpemU9IjIiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k LWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0iIj5JcyBteSB1bmRlcnN0YW5kaW5n IGNvcnJlY3QgdGhhdCBjbGllbnRfc2VjcmV0X2p3dCByZWZlcnMgdG8gdGhlIHNhbWUgY2xpZW50 DQogYXV0aGVudGljYXRpb24gbWV0aG9kIGFzIGRlc2NyaWJlZCBpbiZuYnNwOzwvc3Bhbj48L2Zv bnQ+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MjMjc2VjdGlvbi0y LjIiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTIzI3NlY3Rpb24t Mi4yPC9hPiZuYnNwOz8mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9Im9ycGhhbnM6IDI7IHdpZG93 czogMjsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ib3JwaGFu czogMjsgd2lkb3dzOiAyOyIgY2xhc3M9IiI+RnVydGhlcm1vcmUgdGhlcmUgaXMgUkZDNjc1MCB3 aGljaCBzdWdnZXN0IDMgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMgd2hpY2ggYXJl IG5vdCBpbmNsdWRlZCBpbiB0aGUgcmVnaXN0cnk6PC9kaXY+DQo8ZGl2IHN0eWxlPSJvcnBoYW5z OiAyOyB3aWRvd3M6IDI7IiBjbGFzcz0iIj4tIEJlYXJlciAvIGF1dGhvcmlzYXRpb24gcmVxdWVz dCBoZWFkZXI8L2Rpdj4NCjxkaXYgc3R5bGU9Im9ycGhhbnM6IDI7IHdpZG93czogMjsiIGNsYXNz PSIiPi0gYmVhcmVyIC8gVVJJIHF1ZXJ5IHBhcmFtZXRlcjwvZGl2Pg0KPGRpdiBzdHlsZT0ib3Jw aGFuczogMjsgd2lkb3dzOiAyOyIgY2xhc3M9IiI+LSBiZWFyZXIgLyBmb3JtIGVuY29kZWQgYm9k eSBwYXJhbWV0ZXI8L2Rpdj4NCjxkaXYgc3R5bGU9Im9ycGhhbnM6IDI7IHdpZG93czogMjsiIGNs YXNzPSIiPkZvciBleGFtcGxlLCB0aGUgUkZDNzY2MiBzdWdnZXN0cyB0byB1c2UgdGhlIOKAnGJl YXJlciAvIGF1dGhvcmlzYXRpb24gcmVxdWVzdCBoZWFkZXLigJ0gbWVjaGFuaXNtIGFzIGNsaWVu dCBhdXRoZW50aWNhdGlvbi9hdXRob3Jpc2F0aW9uIG1lY2hhbmlzbS48L2Rpdj4NCjxkaXYgc3R5 bGU9Im9ycGhhbnM6IDI7IHdpZG93czogMjsiIGNsYXNzPSIiPkFueSByZWFzb24gd2h5IHRoaXMg d2FzIG5vdCBkb25lPzwvZGl2Pg0KPGRpdiBzdHlsZT0ib3JwaGFuczogMjsgd2lkb3dzOiAyOyIg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJvcnBoYW5zOiAyOyB3 aWRvd3M6IDI7IiBjbGFzcz0iIj5UaGFua3MgaW4gYWR2YW5jZSBmb3IgYW55IHJlbGF0ZWQgZmVl ZGJhY2ssIHJlZ2FyZHMsPC9kaXY+DQo8ZGl2IHN0eWxlPSJvcnBoYW5zOiAyOyB3aWRvd3M6IDI7 IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im9ycGhhbnM6IDI7 IHdpZG93czogMjsiIGNsYXNzPSIiPkphYXAgRnJhbmNrZTwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_2425F057E2D846C3A859060245C309BBiWelcomecom_-- From nobody Tue Sep 17 06:52:57 2019 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 CF28312084F for ; Tue, 17 Sep 2019 06:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 K4226QjvpLRw for ; Tue, 17 Sep 2019 06:52:53 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 35D82120801 for ; Tue, 17 Sep 2019 06:52:53 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id y39so3097025ota.7 for ; Tue, 17 Sep 2019 06:52:53 -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=ZE7yKvjeU6gWYxNFD+ESMHHe4TdF6x6dmOx1aWTugyI=; b=heTAuv5tifYX3/nD6GE7xgNP++LfKr0FRAq6Oz0W1uXe7a+a/JcC+p+tv8NVYU2A9b QbdM1N4n6hltntTsrv6chn4iVRJ4NZ2Bfq8nEZh3t6mhO9Z3CX30+5mjZEsVGknSPfJ6 veePBCXUko3I10SwG1yzUwFCQzmCnH0XMMfcSTMr1IYvsLIdjPqcyXvoC91nUmQykATy hFJsrObPNQk2QL5YXm8pivI5NRZHhVHSIh3JnnYTtV5Ex0IsWLkSkdk5tDYdamratHXx nTA/G0PMMgx2qUFi9gX1add2nTf4lKLBV7wZkxA1Ot/K2BcoS8gLCLpQFtDCE4EQjlQY QtIA== 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=ZE7yKvjeU6gWYxNFD+ESMHHe4TdF6x6dmOx1aWTugyI=; b=e5hdehyG5+/SAdWrorjLt5RFIqbw9st9D/l2mZQHLYKrMdAWHSi4yT6FdL7LvwTB40 OifGC7CpmivI0f+qr7j77uLjb329EbRj40ikyUpYIVtAIotlRoykIu+kCqv0IFHRMxj2 5qa5EoTUtUNqnvpjZORYorbeIA87xZI93eV9NEZzVlCh7OH+puJt5z2DSiQYGgz81bzk IXf4z0oA3qQXu7D24nHjiwWiA10FNfw327nTm4xFUbZLF7RW+Kt5KC/9KlqVRtjLx8tE H9NgfyoSjZR0rDAhy3AaagUDo/PMMoU9klPC37TveLwoDdYoPzIo6+1GTEo5++y34CeY uGBA== X-Gm-Message-State: APjAAAWJtsnKF64ktFwcxEfYg9pkT89Axokkq0iOkmY1XwcVc3KtN19d VFpQKfPCl2aXoQV22oUptz6E4uCTcfcqahatlIiwyG2+hw== X-Google-Smtp-Source: APXvYqz6J3w2GZS/dlSZl2KRZT/mPT6J5NZ6cEhSWbkU+ecJGDu8eLlJ+QTKi1ZOw/PxFTEtMwNE3rAwq+93HWl6uRM= X-Received: by 2002:a05:6830:10cf:: with SMTP id z15mr2643158oto.257.1568728372368; Tue, 17 Sep 2019 06:52:52 -0700 (PDT) MIME-Version: 1.0 References: <2425F057-E2D8-46C3-A859-060245C309BB@iWelcome.com> In-Reply-To: <2425F057-E2D8-46C3-A859-060245C309BB@iWelcome.com> From: Filip Skokan Date: Tue, 17 Sep 2019 15:52:41 +0200 Message-ID: To: Jaap Francke Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006258f70592c00936" Archived-At: Subject: Re: [OAUTH-WG] client authentication 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: Tue, 17 Sep 2019 13:52:56 -0000 --0000000000006258f70592c00936 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Jaap, There are currently 7 registered client authentication methods that are defined by various RFC's. There are the three from RFC6749 which got their names registered in RFC7591 - none, client_secret_basic and client_secret_post. (Please note that RFC2617 IS NOT EQUAL to client_secret_basic - there are additional requirements when it comes to encoding the username:password tokens defined RFC 6749 Appendix B) Then the two _jwt ones from RFC7523 that got their names registered as part of OIDC Core 1.0 (yes, they're the same). The two remaining are from draft-ietf-oauth-mtls and use mutual-TLS client certificates for authentication. RFC6750 does not define client authentication method. It defines different means of using a Bearer Token obtained through any of the available flows to access a protected resource. Ad RFC7662) its at the discretion of the AS to require either a Bearer Token or Client Authentication to access the introspection response, it may or may not support both in which case the claims it returns may be limited and also the means of obtaining that Bearer Token is out of scope of the document. Hope this helps, Best, *Filip* On Tue, 17 Sep 2019 at 15:21, Jaap Francke wrote: > Hi all, > > I was exploring the topic of client authentication in various RFCs. > A few things are not 100% clear to me, I would be interested to get your > feedback. > > RFC7591 sets up the registry for client authentication methods on the > token endpoint and adds: > - none > - client_secret_basic (RFC2617) > - client_secret_post (RFC6749) > > I don=E2=80=99t understand why that registry seems limited to the token-e= ndpoint. > Client authentication also applies to other protected (OAuth) endpoints > such as token introspect, so it makes sense to have a generic (OAuth) > client authentication method registry. > > OIDC specs indicate a few more: > - client_secret_jwt > - private_key_jwt > Is my understanding correct that client_secret_jwt refers to the same > client authentication method as described in > https://tools.ietf.org/html/rfc7523#section-2.2 ? > > Furthermore there is RFC6750 which suggest 3 client authentication > mechanisms which are not included in the registry: > - Bearer / authorisation request header > - bearer / URI query parameter > - bearer / form encoded body parameter > For example, the RFC7662 suggests to use the =E2=80=9Cbearer / authorisat= ion > request header=E2=80=9D mechanism as client authentication/authorisation = mechanism. > Any reason why this was not done? > > Thanks in advance for any related feedback, regards, > > Jaap Francke > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000006258f70592c00936 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jaap,

There are curren= tly 7 registered client authentica= tion methods that are defined by various RFC's.

There are the three from RFC6749 which got their names registered in RFC7= 591 - none, client_secret_basic and client_secret_post. (Please note that R= FC2617 IS NOT EQUAL to client_secret_basic - there are additional requireme= nts when it comes to encoding the username:password tokens defined RFC 6749= Appendix B)

Then the two _jwt ones from RFC7523 t= hat got their names registered as part of OIDC Core 1.0 (yes, they're t= he same).

The two remaining are from draft-ietf-oa= uth-mtls and use mutual-TLS client certificates for authentication.

RFC6750 does not define client authentication method. It = defines different means of using a Bearer Token obtained through any of the= available flows to access a protected resource.

A= d=C2=A0RFC7662) its at the discretion of the AS to require either a Bearer = Token or Client Authentication to access the introspection response, it may= or may not support both in which case the claims it returns may be limited= and also the means of obtaining that Bearer Token is out of scope of the d= ocument.

Hope this helps,

<= div>
Best,
Filip


On Tue, 17 Sep 2019 at 15:21, J= aap Francke <jaap.francke@i= welcome.com> wrote:
Hi all,

I was exploring the topic of client authentication in various RFCs.
A few things are not 100% clear to me, I would be interested to get yo= ur feedback.

RFC7591 sets up the registry for client authentication methods on the = token endpoint and adds:
- none
- client_secret_basic (RFC2617)
- client_secret_post (RFC6749)

I don=E2=80=99t understand why that registry seems limited to the toke= n-endpoint. Client authentication also applies to other protected (OAuth) e= ndpoints such as token introspect, so it makes sense to have a generic (OAu= th) client authentication method registry.

OIDC specs indicate a few more:
-=C2=A0client_secret_jw= t
-=C2=A0private_key_jwt
Is my understanding c= orrect that client_secret_jwt refers to the same client authentication method as described in=C2=A0https://tools.= ietf.org/html/rfc7523#section-2.2=C2=A0?=C2=A0

Furthermore there is RFC6750 which suggest 3 client authentication mec= hanisms which are not included in the registry:
- Bearer / authorisation request header
- bearer / URI query parameter
- bearer / form encoded body parameter
For example, the RFC7662 suggests to use the =E2=80=9Cbearer / authori= sation request header=E2=80=9D mechanism as client authentication/authorisa= tion mechanism.
Any reason why this was not done?

Thanks in advance for any related feedback, regards,

Jaap Francke
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000006258f70592c00936-- From nobody Tue Sep 17 08:10:18 2019 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 757C212087F for ; Tue, 17 Sep 2019 08:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PNXjaCvGrXnV for ; Tue, 17 Sep 2019 08:10:07 -0700 (PDT) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 3E4981208DB for ; Tue, 17 Sep 2019 08:10:06 -0700 (PDT) Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x8HFAARX021706; Tue, 17 Sep 2019 11:10:26 -0400 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 17 Sep 2019 11:09:32 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 17 Sep 2019 11:09:48 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Tue, 17 Sep 2019 11:09:48 -0400 From: Justin Richer To: Dick Hardt CC: =?utf-8?B?Um9iYWNoZSBIZXJ2w6k=?= , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Question regarding RFC 7592 Thread-Index: AdVpeCBmbn8uFGEHRDSH6fb8upwECQAz/ZmAAAHfXwAADiIAAABHJRgAAF9ir4AABFE4AAAV/kEA Date: Tue, 17 Sep 2019 15:09:48 +0000 Message-ID: References: <827BB5C3-2143-450A-BC3D-72F98CD0B475@mit.edu> <1BEA1464-9B31-4FBF-8619-16096F13BBDD@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_ACE2CFA30D174EB1BF3101BEBBB7222Cmitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Question regarding RFC 7592 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: Tue, 17 Sep 2019 15:10:16 -0000 --_000_ACE2CFA30D174EB1BF3101BEBBB7222Cmitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGlzIGlzIHdoZXJlIHdlIGRpc2FncmVlIGFib3V0IHRoZSBuYXR1cmUgb2Yg4oCc cmVzb3VyY2XigJ0sIGFzIEkgd291bGQgY2xhc3NpZnkgYSBtYW5hZ2VtZW50IEFQSSBhcyBhIHJl c291cmNlLiBTcGVjaWZpY2FsbHksIHRoZSBjbGllbnTigJlzIG93biByZWNvcmRzIGF0IHRoZSBB Uy4NCg0KVGhlIOKAnElG4oCdIGluIHlvdXIgc3RhdGVtZW50IGlzIGEgYmlnIGlmLCBhbmQgb25l IHRoYXQgaXMgdW5jb21tb24gZXZlbiB0b2RheS4gQWxzbywgSSB3YW50IHRvIG5vdGUgdGhhdCBp ZiB0aGUgY2xpZW50IGNhbuKAmXQgIm1hbmFnZSBhbiBhY2Nlc3MgdG9rZW7igJ0gdmVyeSB3ZWxs LCB0aGVuIGl04oCZcyBnb2luZyB0byBoYXZlIGEgdmVyeSBoYXJkIHRpbWUgYmVpbmcgYW4gT0F1 dGggY2xpZW50IG9uY2UgaXTigJlzIGRvbmUgcmVnaXN0ZXJpbmcuIEluIG90aGVyIHdvcmRzLCB0 aGUgZ29hbCB3YXMgdG8gdGFrZSBhIHBpZWNlIG9mIHVuaXZlcnNhbCBmdW5jdGlvbmFsaXR5IHRo YXQgYWxsIE9BdXRoIGNsaWVudHMgd291bGQgYmUgZ3VhcmFudGVlZCB0byBoYXZlLg0KDQpJ4oCZ bGwgYWdyZWUgdGhhdCBpdOKAmXMgYSBiaXQgd2VpcmQgaGF2aW5nIGFuIGFjY2VzcyB0b2tlbiBp c3N1ZWQgYXMgcGFydCBvZiBhIHJlc3BvbnNlLCBidXQgdGhlIGFsdGVybmF0aXZlIHdhcyB0byBp bnZlbnQgYSBuZXcgZmxvdyB0byBmb3JjZSBhIGNsaWVudCB0byBnbyB0aHJvdWdoIGFub3RoZXIg cm91bmQgdHJpcCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgdG8gZ2V0IGl0cyBtYW5hZ2VtZW50IHRv a2VuLiBJZiB5b3XigJlyZSBhbHJlYWR5IGRpcmVjdGx5IGdpdmluZyB0aGUgY2xpZW50IGEgdGVt cG9yYXJ5IGNyZWRlbnRpYWwgdGhhdCBpdCBjYW4gdXNlIGF0IHRoZSBBUywgdGhlbiBqdXN0IGdp dmUgdGhlIGNsaWVudCB0aGUgZmluYWwgdG9rZW4gdG8gZG8gdGhlIGpvYiBkaXJlY3RseSBpbnN0 ZWFkLiBBdCBsZWFzdCwgdGhhdCB3YXMgdGhlIHRoaW5raW5nLCBhbmQgSSBzdGlsbCBhZ3JlZSB3 aXRoIHRoYXQgbGluZSBvZiB0aG91Z2h0IHRvZGF5IGV2ZW4gd2l0aCBpdHMgcXVpcmtzLg0KDQri gJQgSnVzdGluDQoNCk9uIFNlcCAxNywgMjAxOSwgYXQgMTI6NDAgQU0sIERpY2sgSGFyZHQgPGRp Y2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0K DQpUaGUgcmVnaXN0cmF0aW9uIHN1cHBvcnRzIHRoZSBjbGllbnQgaGF2aW5nIGEgandrcywgc28g aWYgdGhlIGNsaWVudCBwcm92aWRlcyBqd2tzLCB0aGVuIHVzaW5nIHRoZW0gdG8gc2lnbiBhbiBh dXRoZW50aWNhdGlvbiByZXF1ZXN0IHNlZW1zIGVhc2llciB0aGFuIHRyeWluZyB0byBtYW5hZ2Ug YW4gYWNjZXNzIHRva2VuLg0KDQpUaGUgdG9rZW4gZW5kcG9pbnQgaXMgYW4gQVBJIGFzIHdlbGwu IFdlIHdvdWxkIGFncmVlIHRoYXQgaXQgaXMgbm90IGEgcmVzb3VyY2UsIGJ1dCBhIG1hbmFnZW1l bnQgQVBJLiBTaW1pbGFybHksIEkgc2VlIHRoZSBjbGllbnQncyBtYW5hZ2VtZW50IG9mIGl0cyBy ZWdpc3RyYXRpb24gdG8gbm90IGJlIGEgcmVzb3VyY2Ugb3BlcmF0aW9uLCBidXQgYSBtYW5hZ2Vt ZW50IEFQSS4NCltodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGph eTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZ0eXBlPXplcm9jb250ZW50Jmd1aWQ9MmYxNTMyMjYt MTZjOC00N2NmLTkxN2QtYTA0NzE0ZTlhNDc0XeGQpw0KDQpPbiBNb24sIFNlcCAxNiwgMjAxOSBh dCA3OjM2IFBNIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBt aXQuZWR1Pj4gd3JvdGU6DQpJIGRvbuKAmXQgc2VlIGEgcmVhc29uIHRvIHVzZSBhbiBhc3NlcnRp b24gaGVyZS4gSldUIGF1dGhlbnRpY2F0aW9uIHdvdWxkIHJlcXVpcmUgYXQgbGVhc3QgYSBzZWNy ZXQgaWYgbm90IGEga2V5IG9mIHNvbWUgdHlwZSBmb3IgYXV0aGVudGljYXRpb24gZm9yIGFsbCBj bGllbnRzLCBhbmQgaXQgd2FzIGRldGVybWluZWQgdGhhdCBkeW5hbWljIHJlZ2lzdHJhdGlvbiBz aG91bGRu4oCZdCByZXF1aXJlIHRoZSBjbGllbnRzIChldmVuIHB1YmxpYyBjbGllbnRzKSB0byBz dXBwb3J0IHRoaW5ncyB0aGV5IHdlcmVu4oCZdCBhbHJlYWR5IGNhcGFibGUgb2YgZG9pbmcuIEJl c2lkZXMsIHRoZSBtYW5hZ2VtZW50IGVuZHBvaW50IGlzbuKAmXQgYSB0b2tlbiBlbmRwb2ludCAo dGhvdWdoIEnigJltIGN1cmlvdXMgdG8gaGVhciB3aHkgeW914oCZZCBzYXkgdGhhdCkg4oCUIGl0 4oCZcyBhbiBBUEkgeW91IGNhbiBjYWxsIHRvIG1hbmFnZSBhIGNsaWVudOKAmXMgcmVnaXN0cmF0 aW9uIGRhdGEgb3ZlciB0aW1lLiBTb3VuZHMgbGlrZSBhbiBSUywgaWYgeW91IGFzayBtZS4NCg0K 4oCUIEp1c3Rpbg0KDQpPbiBTZXAgMTUsIDIwMTksIGF0IDE6MDUgQU0sIERpY2sgSGFyZHQgPGRp Y2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0K DQpDdXJpb3VzIHdoeSB0aGUgY2xpZW50IG1hbmFnZW1lbnQgQVBJIHVzZXMgYmVhcmVyIHRva2Vu cyByYXRoZXIgdGhhbiBKV1RzIHBlciBSRkMgNzUyMyBmb3IgdGhlIGNsaWVudCB0byBhdXRoZW50 aWNhdGUuIFRoZSBjbGllbnQgbWFuYWdlbWVudCBBUEkgc2VlbXMgbW9yZSBzaW1pbGFyIHRvIGEg dG9rZW4gZW5kcG9pbnQgdGhhbiBhIHJlc291cmNlLg0KW2h0dHBzOi8vbWFpbGZvb2dhZS5hcHBz cG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJnR5cGU9emVy b2NvbnRlbnQmZ3VpZD01YzRiYmM4MC0xZjAwLTQzNTEtOWE5Yi05NTQ4MDVlM2Q1NjBd4ZCnDQoN Ck9uIEZyaSwgU2VwIDEzLCAyMDE5IGF0IDEyOjA4IFBNIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJA bWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQpUcmF2aXMgaGFzIHRoaXMg Y29ycmVjdCDigJQgdGhlIOKAnHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW7igJ0gaXMgcGFzc2Vk IHRvIHRoZSBjbGllbnQgZm9yIHRoZSBleHByZXNzIHB1cnBvc2Ugb2YgYWNjZXNzaW5nIHRoZSBj bGllbnQgbWFuYWdlbWVudCBBUEksIGFuZCBpcyBub3QgdGhlIHNhbWUgYXMsIG9yIGVudGFuZ2xl ZCB3aXRoLCBhbnkgYWNjZXNzIHRva2VucyB0aGF0IHRoZSBjbGllbnQgcmVxdWVzdHMgdGhyb3Vn aCB0aGUgT0F1dGggcHJvY2VzcyBhZnRlciB0aGUgcmVnaXN0cmF0aW9uIGhhcyBvY2N1cnJlZC4g VGhlIHJlYXNvbnMgZm9yIHRoaXMgc2VwYXJhdGlvbiBhcmUgbWFueSwgYnV0IGF0IHRoZSBjb3Jl IGl0IGNvbWVzIGRvd24gdG8gdGhlIGNsaWVudCBhbHdheXMgYWN0aW5nIG9uIGl0cyBvd24gYmVo YWxmIHdoZW4gaXQgZG9lcyByZWdpc3RyYXRpb24sIGFuZCBhY3Rpbmcgb24gYmVoYWxmIG9mIHNv bWUgb3RoZXIgcGFydHkgKHVzdWFsbHkgYSB1c2VyKSB3aGVuIGl04oCZcyBkb2luZyBPQXV0aC4g QWRkaXRpb25hbGx5LCByZWdpc3RyYXRpb24gbWFuYWdlbWVudCBpcyBhIGZ1bmN0aW9uIG9mIHRo ZSBBUywgd2hlcmVhcyB0aGUgcHJvdGVjdGVkIEFQSXMgYXJlIGEgZnVuY3Rpb24gb2YgdGhlIFJT IOKAlCBub3RlIHRoaXMgaXMgYSBsb2dpY2FsIHNlcGFyYXRpb24gYW5kIHRoZXJl4oCZcyBub3Ro aW5nIHN0b3BwaW5nIEFTIGFuZCBSUyBmdW5jdGlvbnMgZnJvbSBiZWluZyBkZXBsb3llZCBpbiBh bnkgbnVtYmVyIG9mIHBhdHRlcm5zLg0KDQpBIGZldyBjb21tb24gcXVlc3Rpb25zIHdlIGdvdCBh c2tlZCB3aGVuIHdyaXRpbmcgdGhpcyBmdW5jdGlvbmFsaXR5IGludG8gdGhlIHNwZWM6DQoNCldo eSB1c2UgYW4gYWNjZXNzIHRva2VuIGF0IGFsbD8gQmVjYXVzZSBpdOKAmXMgYSBjcmVkZW50aWFs IGZvciBhIHNwZWNpZmljIEFQSSBpc3N1ZWQgYnkgdGhlIEFTIGFuZCBoYW5kZWQgdG8gdGhlIGNs aWVudCBpbiBhIHByb2dyYW1tYXRpYyBtYW5uZXIuIFRoaXMgaXMgZXhhY3RseSB3aGF0IE9BdXRo IHRva2VucyB3ZXJlIG1hZGUgZm9yLg0KDQpXaHkgbm90IHVzZSB0aGUgY2xpZW504oCZcyBjcmVk ZW50aWFscz8gQmVjYXVzZSBub3QgYWxsIGNsaWVudHMgYXJlIHNldCB1cCB0byBoYXZlIGNyZWRl bnRpYWxzLCBwbHVzIHdl4oCZZCBiZSBzcHJlYWRpbmcgdGhlIHJlcXVpcmVtZW50IHRvIHN1cHBv cnQgZGlmZmVyZW50IGtpbmRzIG9mIGNsaWVudCBjcmVkZW50aWFscyB0byBhbm90aGVyIGVuZHBv aW50Lg0KDQpXaHkgbm90IGlzc3VlIGFuIGF1dGhvcml6YXRpb24gY29kZT8gQmVjYXVzZSB0aGVu IHRoZSBjbGllbnQgd291bGQgbmVlZCB0byBtYWtlIHlldCBhbm90aGVyIHJvdW5kIHRyaXAsIGFu ZCBub3QgYWxsIGNsaWVudHMgYXJlIGF1dGhvcml6YXRpb24tY29kZS1ncmFudCBjbGllbnRzIHRv IGJlZ2luIHdpdGguDQoNCldoeSBub3QgbWFrZSBhIG5ldyBncmFudCB0eXBlPyBCZWNhdXNlIHRo ZW4gdGhlIGNsaWVudCB3b3VsZCBuZWVkIHRvIG1ha2UgeWV0IGFub3RoZXIgcm91bmQgdHJpcCwg YW5kIHdl4oCZZCBoYXZlIHRvIGludmVudCBhIHdob2xlIG5ldyBncmFudCB0eXBlIHdpdGggYSBu ZXcgdGVtcG9yYXJ5IGNyZWRlbnRpYWwgd2hlbiB3ZSBjb3VsZCBqdXN0IHVzZSB0aGF0IHRlbXBv cmFyeSBjcmVkZW50aWFsIGRpcmVjdGx5IGluc3RlYWQuDQoNCuKAlCBKdXN0aW4NCg0KT24gU2Vw IDEzLCAyMDE5LCBhdCA4OjIzIEFNLCBSb2JhY2hlIEhlcnbDqSA8aGVydmUucm9iYWNoZUBzdGV0 LmV1PG1haWx0bzpoZXJ2ZS5yb2JhY2hlQHN0ZXQuZXU+PiB3cm90ZToNCg0KVGhhbmtzIFRyYXZp cw0KDQpJIHVuZGVyc3RhbmQgdGhhdCwgb25jZSB0aGUgY2xpZW50IGhhcyByZXRyaWV2ZWQgaXRz IFtjbGllbnRfaWRdIHRocm91Z2ggUkZDNzU5MSBpbml0aWFsIHJlZ2lzdHJhdGlvbiwgaXQgaXMg dGhlbiBhYmxlIHRvIGFzayBmb3IgYW4gYWNjZXNzIHRva2VuIHRoYXQgd2lsbCBiZSB1c2VkIGZv ciBhY2Nlc3NpbmcgdGhlIFJGQzc1OTIgZW50cnktcG9pbnRzLiBBbSBJIHJpZ2h0Pw0KDQpCZXN0 IHJlZ2FyZHMNCg0KSGVydsOpDQoNCkRlIDogVHJhdmlzIFNwZW5jZXIgW21haWx0bzp0cmF2aXMu c3BlbmNlckBjdXJpdHkuaW9dDQpFbnZvecOpIDogdmVuLiAxMyAxMzozMA0Kw4AgOiBSb2JhY2hl IEhlcnbDqQ0KQ2MgOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpPYmpl dCA6IFJlOiBbT0FVVEgtV0ddIFF1ZXN0aW9uIHJlZ2FyZGluZyBSRkMgNzU5Mg0KDQpOby4gVGhl IGluaXRpYWwgYWNjZXNzIHRva2VuIGlzIGlzc3VlZCBieSB0aGUgQVMgd2hlbiByZWdpc3RyYXRp b24gaXMgcHJvdGVjdGVkIChhcHBlbmRpeCAxLjIgaW4gUkZDIDc1OTEpLiBBcyBzdGF0ZWQgaW4g c2VjdGlvbiAxLjIsIHRoZSBtZXRob2QgYW5kIG1lYW5zIGJ5IHdoaWNoIHRoaXMgaXMgb2J0YWlu ZWQgY2FuIHZhcnkuIFRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIGluIFJGQyA3NTkyIGlz IHVzZWQgdG8gcHJvdGVjdCB0aGUgcmVnaXN0cmF0aW9uIG1hbmFnZW1lbnQgQVBJIGFuZCBhbGxv dyB1cGRhdGVzIHRvIHRoZSBjbGllbnQgYWZ0ZXIgaXQgaXMgcmVnaXN0ZXJlZC4gWW91IG1pZ2h0 IGhhdmUgb25lICh0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbikgYnV0IG5vdCB0aGUgb3Ro ZXIgKGluaXRpYWwgYWNjZXNzIHRva2VuKSB3aGVuIG9wZW4gcmVnaXN0cmF0aW9uIGlzIGFsbG93 ZWQgKGFwcGVuZGl4IDEuMSBpbiBSRkMgNzU5MSkuDQoNCkhUSCENCg0KT24gRnJpLCBTZXAgMTMs IDIwMTkgYXQgNzozNyBBTSBSb2JhY2hlIEhlcnbDqSA8aGVydmUucm9iYWNoZUBzdGV0LmV1PG1h aWx0bzpoZXJ2ZS5yb2JhY2hlQHN0ZXQuZXU+PiB3cm90ZToNCkhpDQoNClJGQyA3NTkyIGludHJv ZHVjZXMgYSDCqyBSZWdpc3RyYXRpb24gQWNjZXNzIFRva2VuIMK7LiBBcmUgdGhpcyB0b2tlbiBh bmQgdGhlIHdheSB0byBnZXQgaXQgc2ltaWxhciB0byB3aGF0IGlzIHNwZWNpZmllZCBhcyDigJxJ bml0aWFsIEFjY2VzcyBUb2tlbuKAnSBpbiBSRkMgNzU5MS9BcHBlbmRpeCBBID8NCg0KSWYgc28s IGNhbiB0aGUgT3BlbiBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gKFJGQzc1OTEvQS4xLjEp IGJlIGV4dHJhcG9sYXRlZCB0byBSRkM3NTkyIGFzIHRoZSBzYW1lIHdheT8NCg0KVGhhbmtzIGlu IGFkdmFuY2UgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbi4NCg0KSGVydsOpIFJPQkFDSEUNCkRpcmVj dGlvbiBNYXJrZXRpbmcgZXQgRMOpdmVsb3BwZW1lbnQNCg0KTElHTkUgRElSRUNURQ0KVC4gKzMz KDApMSA1NSAyMyA1NSA0NQ0KaGVydmUucm9iYWNoZUBzdGV0LmV1PG1haWx0bzpoZXJ2ZS5yb2Jh Y2hlQHN0ZXQuZXU+DQoNCg0KDQo8aW1hZ2UwMDEucG5nPg0KDQoNCg0KDQo8aW1hZ2UwMDIucG5n Pg0KDQpTVEVUIChTSUVHRSBTT0NJQUwpDQoxMDAsIEVzcGxhbmFkZSBkdSBHw6luw6lyYWwgZGUg R2F1bGxlDQpDxZN1ciBEw6lmZW5zZSDigJMgVG91ciBCDQo5MjkzMiBMYSBEw6lmZW5zZSBjZWRl eA0KDQp3d3cuc3RldC5ldTxodHRwOi8vd3d3LnN0ZXQuZXUvPg0KDQoNCg0KQ2UgbWVzc2FnZSBl dCB0b3V0ZXMgbGVzIHBpw6hjZXMgam9pbnRlcyBzb250IMOpdGFibGlzIMOgIGwnaW50ZW50aW9u IGV4Y2x1c2l2ZSBkZSBzZXMgZGVzdGluYXRhaXJlcyBldCBzb250IGNvbmZpZGVudGllbHMuDQpT aSB2b3VzIHJlY2V2ZXogY2UgbWVzc2FnZSBwYXIgZXJyZXVyIG91IHMnaWwgbmUgdm91cyBlc3Qg cGFzIGRlc3RpbsOpLCBtZXJjaSBkZSBsZSBkw6l0cnVpcmUgYWluc2kgcXVlIHRvdXRlIGNvcGll IGRlIHZvdHJlIHN5c3TDqG1lIGV0IGQnZW4gYXZlcnRpciBpbW3DqWRpYXRlbWVudCBsJ2V4cMOp ZGl0ZXVyLg0KVG91dGUgbGVjdHVyZSBub24gYXV0b3Jpc8OpZSwgdG91dGUgdXRpbGlzYXRpb24g ZGUgY2UgbWVzc2FnZSBxdWkgbidlc3QgcGFzIGNvbmZvcm1lIMOgIHNhIGRlc3RpbmF0aW9uLCB0 b3V0ZSBkaWZmdXNpb24gb3UgdG91dGUgcHVibGljYXRpb24sIHRvdGFsZSBvdSBwYXJ0aWVsbGUs IGVzdCBpbnRlcmRpdGUuDQpMJ0ludGVybmV0IG5lIHBlcm1ldHRhbnQgcGFzIGQnYXNzdXJlciBs J2ludMOpZ3JpdMOpIGRlIGNlIG1lc3NhZ2Ugw6lsZWN0cm9uaXF1ZSBzdXNjZXB0aWJsZSBkJ2Fs dMOpcmF0aW9uLCBTVEVUIGTDqWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXTDqSBhdSB0aXRyZSBk ZSBjZSBtZXNzYWdlIGRhbnMgbCdoeXBvdGjDqHNlIG/DuSBpbCBhdXJhaXQgw6l0w6kgbW9kaWZp w6ksIGTDqWZvcm3DqSBvdSBmYWxzaWZpw6kuDQpOJ2ltcHJpbWV6IGNlIG1lc3NhZ2UgcXVlIHNp IG7DqWNlc3NhaXJlLCBwZW5zZXogw6AgbCdlbnZpcm9ubmVtZW50Lg0KDQpUaGlzIG1lc3NhZ2Ug YW5kIGFueSBhdHRhY2htZW50cyBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBpbnRlbmRlZCBh ZGRyZXNzZWVzIGFuZCBpcyBjb25maWRlbnRpYWwuDQpJZiB5b3UgcmVjZWl2ZSB0aGlzIG1lc3Nh Z2UgaW4gZXJyb3IsIG9yIGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKSwgcGxlYXNl IGRlbGV0ZSBpdCBhbmQgYW55IGNvcGllcyBmcm9tIHlvdXIgc3lzdGVtcyBhbmQgaW1tZWRpYXRl bHkgbm90aWZ5IHRoZSBzZW5kZXIuDQpBbnkgdW5hdXRob3JpemVkIHZpZXcsIHVzZSB0aGF0IGRv ZXMgbm90IGNvbXBseSB3aXRoIGl0cyBwdXJwb3NlLCBkaXNzZW1pbmF0aW9uIG9yIGRpc2Nsb3N1 cmUsIGVpdGhlciB3aG9sZSBvciBwYXJ0aWFsLCBpcyBwcm9oaWJpdGVkLg0KU2luY2UgdGhlIGlu dGVybmV0IGNhbm5vdCBndWFyYW50ZWUgdGhlIGludGVncml0eSBvZiB0aGlzIG1lc3NhZ2Ugd2hp Y2ggbWF5IG5vdCBiZSByZWxpYWJsZSwgU1RFVCBzaGFsbCBub3QgYmUgbGlhYmxlIGZvciB0aGUg bWVzc2FnZSBpZiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpEbyBub3QgcHJpbnQg dGhpcyBtZXNzYWdlIHVubGVzcyBpdCBpcyBuZWNlc3NhcnksIHBsZWFzZSBjb25zaWRlciB0aGUg ZW52aXJvbm1lbnQuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0K Q2UgbWVzc2FnZSBldCB0b3V0ZXMgbGVzIHBpw6hjZXMgam9pbnRlcyBzb250IMOpdGFibGlzIMOg IGwnaW50ZW50aW9uIGV4Y2x1c2l2ZSBkZSBzZXMgZGVzdGluYXRhaXJlcyBldCBzb250IGNvbmZp ZGVudGllbHMuDQpTaSB2b3VzIHJlY2V2ZXogY2UgbWVzc2FnZSBwYXIgZXJyZXVyIG91IHMnaWwg bmUgdm91cyBlc3QgcGFzIGRlc3RpbsOpLCBtZXJjaSBkZSBsZSBkw6l0cnVpcmUgYWluc2kgcXVl IHRvdXRlIGNvcGllIGRlIHZvdHJlIHN5c3TDqG1lIGV0IGQnZW4gYXZlcnRpciBpbW3DqWRpYXRl bWVudCBsJ2V4cMOpZGl0ZXVyLg0KVG91dGUgbGVjdHVyZSBub24gYXV0b3Jpc8OpZSwgdG91dGUg dXRpbGlzYXRpb24gZGUgY2UgbWVzc2FnZSBxdWkgbidlc3QgcGFzIGNvbmZvcm1lIMOgIHNhIGRl c3RpbmF0aW9uLCB0b3V0ZSBkaWZmdXNpb24gb3UgdG91dGUgcHVibGljYXRpb24sIHRvdGFsZSBv dSBwYXJ0aWVsbGUsIGVzdCBpbnRlcmRpdGUuDQpMJ0ludGVybmV0IG5lIHBlcm1ldHRhbnQgcGFz IGQnYXNzdXJlciBsJ2ludMOpZ3JpdMOpIGRlIGNlIG1lc3NhZ2Ugw6lsZWN0cm9uaXF1ZSBzdXNj ZXB0aWJsZSBkJ2FsdMOpcmF0aW9uLCBTVEVUIGTDqWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXTD qSBhdSB0aXRyZSBkZSBjZSBtZXNzYWdlIGRhbnMgbCdoeXBvdGjDqHNlIG/DuSBpbCBhdXJhaXQg w6l0w6kgbW9kaWZpw6ksIGTDqWZvcm3DqSBvdSBmYWxzaWZpw6kuDQpOJ2ltcHJpbWV6IGNlIG1l c3NhZ2UgcXVlIHNpIG7DqWNlc3NhaXJlLCBwZW5zZXogw6AgbCdlbnZpcm9ubmVtZW50Lg0KDQpU aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSBpbnRlbmRlZCBhZGRyZXNzZWVzIGFuZCBpcyBjb25maWRlbnRpYWwuDQpJZiB5b3UgcmVjZWl2 ZSB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIG9yIGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dChzKSwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgYW55IGNvcGllcyBmcm9tIHlvdXIgc3lzdGVtcyBh bmQgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIuDQpBbnkgdW5hdXRob3JpemVkIHZpZXcs IHVzZSB0aGF0IGRvZXMgbm90IGNvbXBseSB3aXRoIGl0cyBwdXJwb3NlLCBkaXNzZW1pbmF0aW9u IG9yIGRpc2Nsb3N1cmUsIGVpdGhlciB3aG9sZSBvciBwYXJ0aWFsLCBpcyBwcm9oaWJpdGVkLg0K U2luY2UgdGhlIGludGVybmV0IGNhbm5vdCBndWFyYW50ZWUgdGhlIGludGVncml0eSBvZiB0aGlz IG1lc3NhZ2Ugd2hpY2ggbWF5IG5vdCBiZSByZWxpYWJsZSwgU1RFVCBzaGFsbCBub3QgYmUgbGlh YmxlIGZvciB0aGUgbWVzc2FnZSBpZiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpE byBub3QgcHJpbnQgdGhpcyBtZXNzYWdlIHVubGVzcyBpdCBpcyBuZWNlc3NhcnksIHBsZWFzZSBj b25zaWRlciB0aGUgZW52aXJvbm1lbnQuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQo= --_000_ACE2CFA30D174EB1BF3101BEBBB7222Cmitedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgdGhpbmsgdGhpcyBpcyB3aGVyZSB3ZSBkaXNh Z3JlZSBhYm91dCB0aGUgbmF0dXJlIG9mIOKAnHJlc291cmNl4oCdLCBhcyBJIHdvdWxkIGNsYXNz aWZ5IGEgbWFuYWdlbWVudCBBUEkgYXMgYSByZXNvdXJjZS4gU3BlY2lmaWNhbGx5LCB0aGUgY2xp ZW504oCZcyBvd24gcmVjb3JkcyBhdCB0aGUgQVMuJm5ic3A7DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUg4oCcSUbigJ0gaW4geW91ciBzdGF0 ZW1lbnQgaXMgYSBiaWcgaWYsIGFuZCBvbmUgdGhhdCBpcyB1bmNvbW1vbiBldmVuIHRvZGF5LiBB bHNvLCBJIHdhbnQgdG8gbm90ZSB0aGF0IGlmIHRoZSBjbGllbnQgY2Fu4oCZdCAmcXVvdDttYW5h Z2UgYW4gYWNjZXNzIHRva2Vu4oCdIHZlcnkgd2VsbCwgdGhlbiBpdOKAmXMgZ29pbmcgdG8gaGF2 ZSBhIHZlcnkgaGFyZCB0aW1lIGJlaW5nIGFuIE9BdXRoIGNsaWVudCBvbmNlIGl04oCZcyBkb25l IHJlZ2lzdGVyaW5nLg0KIEluIG90aGVyIHdvcmRzLCB0aGUgZ29hbCB3YXMgdG8gdGFrZSBhIHBp ZWNlIG9mIHVuaXZlcnNhbCBmdW5jdGlvbmFsaXR5IHRoYXQgYWxsIE9BdXRoIGNsaWVudHMgd291 bGQgYmUgZ3VhcmFudGVlZCB0byBoYXZlLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SeKAmWxsIGFncmVlIHRoYXQgaXTigJlz IGEgYml0IHdlaXJkIGhhdmluZyBhbiBhY2Nlc3MgdG9rZW4gaXNzdWVkIGFzIHBhcnQgb2YgYSBy ZXNwb25zZSwgYnV0IHRoZSBhbHRlcm5hdGl2ZSB3YXMgdG8gaW52ZW50IGEgbmV3IGZsb3cgdG8g Zm9yY2UgYSBjbGllbnQgdG8gZ28gdGhyb3VnaCBhbm90aGVyIHJvdW5kIHRyaXAgdG8gdGhlIHRv a2VuIGVuZHBvaW50IHRvIGdldCBpdHMgbWFuYWdlbWVudCB0b2tlbi4gSWYgeW914oCZcmUNCiBh bHJlYWR5IGRpcmVjdGx5IGdpdmluZyB0aGUgY2xpZW50IGEgdGVtcG9yYXJ5IGNyZWRlbnRpYWwg dGhhdCBpdCBjYW4gdXNlIGF0IHRoZSBBUywgdGhlbiBqdXN0IGdpdmUgdGhlIGNsaWVudCB0aGUg ZmluYWwgdG9rZW4gdG8gZG8gdGhlIGpvYiBkaXJlY3RseSBpbnN0ZWFkLiBBdCBsZWFzdCwgdGhh dCB3YXMgdGhlIHRoaW5raW5nLCBhbmQgSSBzdGlsbCBhZ3JlZSB3aXRoIHRoYXQgbGluZSBvZiB0 aG91Z2h0IHRvZGF5IGV2ZW4gd2l0aCBpdHMNCiBxdWlya3MuJm5ic3A7PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQrigJQgSnVz dGluPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIFNlcCAxNywgMjAxOSwgYXQgMTI6NDAg QU0sIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIg Y2xhc3M9IiI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBj bGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBk aXI9Imx0ciIgY2xhc3M9IiI+VGhlIHJlZ2lzdHJhdGlvbiBzdXBwb3J0cyB0aGUgY2xpZW50IGhh dmluZyBhIGp3a3MsIHNvIGlmIHRoZSBjbGllbnQgcHJvdmlkZXMgandrcywgdGhlbiB1c2luZyB0 aGVtIHRvIHNpZ24gYW4gYXV0aGVudGljYXRpb24gcmVxdWVzdCBzZWVtcyBlYXNpZXIgdGhhbiB0 cnlpbmcgdG8gbWFuYWdlIGFuIGFjY2VzcyB0b2tlbi4mbmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSB0b2tlbiBlbmRwb2ludCBpcyBh biBBUEkgYXMgd2VsbC4gV2Ugd291bGQgYWdyZWUgdGhhdCBpdCBpcyBub3QgYSByZXNvdXJjZSwg YnV0IGEgbWFuYWdlbWVudCBBUEkuIFNpbWlsYXJseSwgSSBzZWUgdGhlIGNsaWVudCdzIG1hbmFn ZW1lbnQgb2YgaXRzIHJlZ2lzdHJhdGlvbiB0byBub3QgYmUgYSByZXNvdXJjZSBvcGVyYXRpb24s IGJ1dCBhIG1hbmFnZW1lbnQgQVBJLjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGhzcGFjZT0ic3RyZWFr LXB0LW1hcmsiIHN0eWxlPSJtYXgtaGVpZ2h0OjFweCIgY2xhc3M9IiI+PGltZyBhbHQ9IiIgc3R5 bGU9IndpZHRoOjBweDttYXgtaGVpZ2h0OjBweDtvdmVyZmxvdzpoaWRkZW4iIHNyYz0iaHR0cHM6 Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJD NWpiMjAlM0QmYW1wO3R5cGU9emVyb2NvbnRlbnQmYW1wO2d1aWQ9MmYxNTMyMjYtMTZjOC00N2Nm LTkxN2QtYTA0NzE0ZTlhNDc0IiBjbGFzcz0iIj48Zm9udCBjb2xvcj0iI2ZmZmZmZiIgc2l6ZT0i MSIgY2xhc3M9IiI+4ZCnPC9mb250PjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIE1vbiwg U2VwIDE2LCAyMDE5IGF0IDc6MzYgUE0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmpyaWNoZXJAbWl0LmVkdSIgY2xhc3M9IiI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6 PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigy MDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJvdmVyZmxvdy13cmFw OiBicmVhay13b3JkOyIgY2xhc3M9IiI+SSBkb27igJl0IHNlZSBhIHJlYXNvbiB0byB1c2UgYW4g YXNzZXJ0aW9uIGhlcmUuIEpXVCBhdXRoZW50aWNhdGlvbiB3b3VsZCByZXF1aXJlIGF0IGxlYXN0 IGEgc2VjcmV0IGlmIG5vdCBhIGtleSBvZiBzb21lIHR5cGUgZm9yIGF1dGhlbnRpY2F0aW9uIGZv ciBhbGwgY2xpZW50cywgYW5kIGl0IHdhcyBkZXRlcm1pbmVkIHRoYXQgZHluYW1pYyByZWdpc3Ry YXRpb24NCiBzaG91bGRu4oCZdCByZXF1aXJlIHRoZSBjbGllbnRzIChldmVuIHB1YmxpYyBjbGll bnRzKSB0byBzdXBwb3J0IHRoaW5ncyB0aGV5IHdlcmVu4oCZdCBhbHJlYWR5IGNhcGFibGUgb2Yg ZG9pbmcuIEJlc2lkZXMsIHRoZSBtYW5hZ2VtZW50IGVuZHBvaW50IGlzbuKAmXQgYSB0b2tlbiBl bmRwb2ludCAodGhvdWdoIEnigJltIGN1cmlvdXMgdG8gaGVhciB3aHkgeW914oCZZCBzYXkgdGhh dCkg4oCUIGl04oCZcyBhbiBBUEkgeW91IGNhbiBjYWxsIHRvIG1hbmFnZSBhIGNsaWVudOKAmXMN CiByZWdpc3RyYXRpb24gZGF0YSBvdmVyIHRpbWUuIFNvdW5kcyBsaWtlIGFuIFJTLCBpZiB5b3Ug YXNrIG1lLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0K4oCUIEp1c3Rp bjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBTZXAgMTUsIDIwMTksIGF0 IDE6MDUgQU0sIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9ImdtYWlsLW1fNTM1MjYyMDAwMTUyNDg1NjI2MkFw cGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIi IGNsYXNzPSIiPkN1cmlvdXMgd2h5Jm5ic3A7dGhlIGNsaWVudCBtYW5hZ2VtZW50IEFQSSB1c2Vz IGJlYXJlciB0b2tlbnMgcmF0aGVyIHRoYW4gSldUcyBwZXIgUkZDIDc1MjMgZm9yIHRoZSBjbGll bnQgdG8gYXV0aGVudGljYXRlLiBUaGUgY2xpZW50IG1hbmFnZW1lbnQgQVBJIHNlZW1zIG1vcmUg c2ltaWxhciB0byBhIHRva2VuIGVuZHBvaW50IHRoYW4gYSByZXNvdXJjZS48L2Rpdj4NCjxkaXYg aHNwYWNlPSJzdHJlYWstcHQtbWFyayIgc3R5bGU9Im1heC1oZWlnaHQ6MXB4IiBjbGFzcz0iIj48 aW1nIGFsdD0iIiBzdHlsZT0id2lkdGg6IDBweDsgbWF4LWhlaWdodDogMHB4OyBvdmVyZmxvdzog aGlkZGVuOyIgc3JjPSJodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpH bGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3Vp ZD01YzRiYmM4MC0xZjAwLTQzNTEtOWE5Yi05NTQ4MDVlM2Q1NjAiIGNsYXNzPSIiPjxmb250IGNv bG9yPSIjZmZmZmZmIiBzaXplPSIxIiBjbGFzcz0iIj7hkKc8L2ZvbnQ+PC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0i Z21haWxfYXR0ciI+T24gRnJpLCBTZXAgMTMsIDIwMTkgYXQgMTI6MDggUE0gSnVzdGluIFJpY2hl ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiIGNs YXNzPSIiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgg MHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmct bGVmdDoxZXgiPg0KPGRpdiBjbGFzcz0iIj5UcmF2aXMgaGFzIHRoaXMgY29ycmVjdCDigJQgdGhl IOKAnHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW7igJ0gaXMgcGFzc2VkIHRvIHRoZSBjbGllbnQg Zm9yIHRoZSBleHByZXNzIHB1cnBvc2Ugb2YgYWNjZXNzaW5nIHRoZSBjbGllbnQgbWFuYWdlbWVu dCBBUEksIGFuZCBpcyBub3QgdGhlIHNhbWUgYXMsIG9yIGVudGFuZ2xlZCB3aXRoLCBhbnkgYWNj ZXNzIHRva2VucyB0aGF0IHRoZSBjbGllbnQgcmVxdWVzdHMgdGhyb3VnaCB0aGUNCiBPQXV0aCBw cm9jZXNzIGFmdGVyIHRoZSByZWdpc3RyYXRpb24gaGFzIG9jY3VycmVkLiBUaGUgcmVhc29ucyBm b3IgdGhpcyBzZXBhcmF0aW9uIGFyZSBtYW55LCBidXQgYXQgdGhlIGNvcmUgaXQgY29tZXMgZG93 biB0byB0aGUgY2xpZW50IGFsd2F5cyBhY3Rpbmcgb24gaXRzIG93biBiZWhhbGYgd2hlbiBpdCBk b2VzIHJlZ2lzdHJhdGlvbiwgYW5kIGFjdGluZyBvbiBiZWhhbGYgb2Ygc29tZSBvdGhlciBwYXJ0 eSAodXN1YWxseSBhIHVzZXIpIHdoZW4NCiBpdOKAmXMgZG9pbmcgT0F1dGguIEFkZGl0aW9uYWxs eSwgcmVnaXN0cmF0aW9uIG1hbmFnZW1lbnQgaXMgYSBmdW5jdGlvbiBvZiB0aGUgQVMsIHdoZXJl YXMgdGhlIHByb3RlY3RlZCBBUElzIGFyZSBhIGZ1bmN0aW9uIG9mIHRoZSBSUyDigJQgbm90ZSB0 aGlzIGlzIGEgbG9naWNhbCBzZXBhcmF0aW9uIGFuZCB0aGVyZeKAmXMgbm90aGluZyBzdG9wcGlu ZyBBUyBhbmQgUlMgZnVuY3Rpb25zIGZyb20gYmVpbmcgZGVwbG95ZWQgaW4gYW55IG51bWJlciBv ZiBwYXR0ZXJucy4mbmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkEgZmV3IGNvbW1vbiBxdWVzdGlvbnMgd2UgZ290IGFza2VkIHdoZW4gd3Jp dGluZyB0aGlzIGZ1bmN0aW9uYWxpdHkgaW50byB0aGUgc3BlYzo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIiPldoeSB1 c2UgYW4gYWNjZXNzIHRva2VuIGF0IGFsbDwvYj4/IEJlY2F1c2UgaXTigJlzIGEgY3JlZGVudGlh bCBmb3IgYSBzcGVjaWZpYyBBUEkgaXNzdWVkIGJ5IHRoZSBBUyBhbmQgaGFuZGVkIHRvIHRoZSBj bGllbnQgaW4gYSBwcm9ncmFtbWF0aWMgbWFubmVyLiBUaGlzIGlzIGV4YWN0bHkgd2hhdCBPQXV0 aCB0b2tlbnMgd2VyZSBtYWRlIGZvci4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIiPldoeSBub3QgdXNlIHRo ZSBjbGllbnTigJlzIGNyZWRlbnRpYWxzPC9iPj8gQmVjYXVzZSBub3QgYWxsIGNsaWVudHMgYXJl IHNldCB1cCB0byBoYXZlIGNyZWRlbnRpYWxzLCBwbHVzIHdl4oCZZCBiZSBzcHJlYWRpbmcgdGhl IHJlcXVpcmVtZW50IHRvIHN1cHBvcnQgZGlmZmVyZW50IGtpbmRzIG9mIGNsaWVudCBjcmVkZW50 aWFscyB0byBhbm90aGVyIGVuZHBvaW50LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+V2h5IG5vdCBpc3N1 ZSBhbiBhdXRob3JpemF0aW9uIGNvZGU8L2I+PyBCZWNhdXNlIHRoZW4gdGhlIGNsaWVudCB3b3Vs ZCBuZWVkIHRvIG1ha2UgeWV0IGFub3RoZXIgcm91bmQgdHJpcCwgYW5kIG5vdCBhbGwgY2xpZW50 cyBhcmUgYXV0aG9yaXphdGlvbi1jb2RlLWdyYW50IGNsaWVudHMgdG8gYmVnaW4gd2l0aC4mbmJz cDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiIGNsYXNzPSIiPldoeSBub3QgbWFrZSBhIG5ldyBncmFudCB0eXBlPC9iPj8gQmVjYXVz ZSB0aGVuIHRoZSBjbGllbnQgd291bGQgbmVlZCB0byBtYWtlIHlldCBhbm90aGVyIHJvdW5kIHRy aXAsIGFuZCB3ZeKAmWQgaGF2ZSB0byBpbnZlbnQgYSB3aG9sZSBuZXcgZ3JhbnQgdHlwZSB3aXRo IGEgbmV3IHRlbXBvcmFyeSBjcmVkZW50aWFsIHdoZW4gd2UgY291bGQganVzdCB1c2UgdGhhdCB0 ZW1wb3JhcnkgY3JlZGVudGlhbCBkaXJlY3RseQ0KIGluc3RlYWQuJm5ic3A7PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12 YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3 aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRlY29yYXRpb246bm9uZSIg Y2xhc3M9IiI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pk9uIFNlcCAxMywgMjAxOSwgYXQgODoyMyBBTSwgUm9iYWNoZSBIZXJ2w6kgJmx0OzxhIGhyZWY9 Im1haWx0bzpoZXJ2ZS5yb2JhY2hlQHN0ZXQuZXUiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5o ZXJ2ZS5yb2JhY2hlQHN0ZXQuZXU8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iZ21h aWwtbV81MzUyNjIwMDAxNTI0ODU2MjYyZ21haWwtbV8tMjkxODY2NDQ1Mjg0MDM0NjkyN0FwcGxl LWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWls LW1fNTM1MjYyMDAwMTUyNDg1NjI2MmdtYWlsLW1fLTI5MTg2NjQ0NTI4NDAzNDY5MjdXb3JkU2Vj dGlvbjEiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1z dHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDts ZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4 dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0 LWRlY29yYXRpb246bm9uZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtm b250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTFwdDtm b250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Y29sb3I6cmdiKDMxLDczLDEyNSkiIGNsYXNz PSIiPlRoYW5rcyBUcmF2aXM8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0O2ZvbnQtZmFtaWx5OkNh bGlicmksc2Fucy1zZXJpZjtjb2xvcjpyZ2IoMzEsNzMsMTI1KSIgY2xhc3M9IiI+PHUgY2xhc3M9 IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTFwdDtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Y29s b3I6cmdiKDMxLDczLDEyNSkiIGNsYXNzPSIiPkkgdW5kZXJzdGFuZCB0aGF0LCBvbmNlIHRoZSBj bGllbnQgaGFzIHJldHJpZXZlZCBpdHMgW2NsaWVudF9pZF0gdGhyb3VnaCBSRkM3NTkxIGluaXRp YWwgcmVnaXN0cmF0aW9uLCBpdCBpcyB0aGVuIGFibGUgdG8gYXNrIGZvciBhbiBhY2Nlc3MgdG9r ZW4gdGhhdCB3aWxsDQogYmUgdXNlZCBmb3IgYWNjZXNzaW5nIHRoZSBSRkM3NTkyIGVudHJ5LXBv aW50cy4gQW0gSSByaWdodD88dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0O2ZvbnQtZmFtaWx5OkNh bGlicmksc2Fucy1zZXJpZjtjb2xvcjpyZ2IoMzEsNzMsMTI1KSIgY2xhc3M9IiI+PHUgY2xhc3M9 IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTFwdDtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Y29s b3I6cmdiKDMxLDczLDEyNSkiIGNsYXNzPSIiPkJlc3QgcmVnYXJkczx1IGNsYXNzPSIiPjwvdT48 dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20g MC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2NvbG9yOnJnYigzMSw3Mywx MjUpIiBjbGFzcz0iIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+PC91Pjwvc3Bh bj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZTox MnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xhc3M9 IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0O2ZvbnQtZmFtaWx5 OkNhbGlicmksc2Fucy1zZXJpZjtjb2xvcjpyZ2IoMzEsNzMsMTI1KSIgY2xhc3M9IiI+SGVydsOp PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTFwdDtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7 Y29sb3I6cmdiKDMxLDczLDEyNSkiIGNsYXNzPSIiPjx1IGNsYXNzPSIiPjwvdT4mbmJzcDs8dSBj bGFzcz0iIj48L3U+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20gMC4w MDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTBwdDtmb250LWZhbWlseTpUYWhvbWEsc2Fucy1zZXJpZiIgY2xhc3M9IiI+RGUmbmJzcDs6PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk6VGFob21hLHNh bnMtc2VyaWYiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJnbWFpbC1tXzUzNTI2MjAwMDE1MjQ4NTYy NjJnbWFpbC1tXy0yOTE4NjY0NDUyODQwMzQ2OTI3QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+VHJhdmlzDQogU3BlbmNlciBbPGEgaHJlZj0ibWFpbHRvOnRyYXZpcy5zcGVuY2Vy QGN1cml0eS5pbyIgc3R5bGU9ImNvbG9yOnB1cnBsZTt0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+bWFpbHRvOnRyYXZpcy5zcGVuY2VyQGN1cml0eS5p bzwvYT5dPHNwYW4gY2xhc3M9ImdtYWlsLW1fNTM1MjYyMDAwMTUyNDg1NjI2MmdtYWlsLW1fLTI5 MTg2NjQ0NTI4NDAzNDY5MjdBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIg Y2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5FbnZvecOpJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iZ21h aWwtbV81MzUyNjIwMDAxNTI0ODU2MjYyZ21haWwtbV8tMjkxODY2NDQ1Mjg0MDM0NjkyN0FwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnZlbi4gMTMgMTM6MzA8YnIgY2xhc3M9IiI+ DQo8YiBjbGFzcz0iIj7DgCZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImdtYWlsLW1fNTM1MjYyMDAw MTUyNDg1NjI2MmdtYWlsLW1fLTI5MTg2NjQ0NTI4NDAzNDY5MjdBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5Sb2JhY2hlIEhlcnbDqTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIi PkNjJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iZ21haWwtbV81MzUyNjIwMDAxNTI0ODU2MjYyZ21h aWwtbV8tMjkxODY2NDQ1Mjg0MDM0NjkyN0FwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOnB1cnBsZTt0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+b2F1dGhA aWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+T2JqZXQmbmJzcDs6PC9iPjxz cGFuIGNsYXNzPSJnbWFpbC1tXzUzNTI2MjAwMDE1MjQ4NTYyNjJnbWFpbC1tXy0yOTE4NjY0NDUy ODQwMzQ2OTI3QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtPQVVUSC1X R10gUXVlc3Rpb24gcmVnYXJkaW5nIFJGQyA3NTkyPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIi PjwvdT48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtm b250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiIGNsYXNzPSIiPg0KPHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBj bSAwY20gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFzcz0iIj4NCk5vLiBUaGUgaW5pdGlhbCBhY2Nlc3MgdG9r ZW4gaXMgaXNzdWVkIGJ5IHRoZSBBUyB3aGVuIHJlZ2lzdHJhdGlvbiBpcyBwcm90ZWN0ZWQgKGFw cGVuZGl4IDEuMiBpbiBSRkMgNzU5MSkuIEFzIHN0YXRlZCBpbiBzZWN0aW9uIDEuMiwgdGhlIG1l dGhvZCBhbmQgbWVhbnMgYnkgd2hpY2ggdGhpcyBpcyBvYnRhaW5lZCBjYW4gdmFyeS4gVGhlIHJl Z2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4gaW4gUkZDIDc1OTIgaXMgdXNlZCB0byBwcm90ZWN0IHRo ZSByZWdpc3RyYXRpb24NCiBtYW5hZ2VtZW50IEFQSSBhbmQgYWxsb3cgdXBkYXRlcyB0byB0aGUg Y2xpZW50IGFmdGVyIGl0IGlzIHJlZ2lzdGVyZWQuIFlvdSBtaWdodCBoYXZlIG9uZSAodGhlIHJl Z2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4pIGJ1dCBub3QgdGhlIG90aGVyIChpbml0aWFsIGFjY2Vz cyB0b2tlbikgd2hlbiBvcGVuIHJlZ2lzdHJhdGlvbiBpcyBhbGxvd2VkIChhcHBlbmRpeCAxLjEg aW4gUkZDIDc1OTEpLjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtm b250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiIGNsYXNzPSIiPg0KPHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAu MDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiIgY2xhc3M9IiI+DQpIVEghPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwv dT48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAw MDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiIGNsYXNzPSIiPg0KPHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwv dT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFzcz0iIj4NCk9uIEZyaSwgU2VwIDEzLCAyMDE5 IGF0IDc6MzcgQU0gUm9iYWNoZSBIZXJ2w6kgJmx0OzxhIGhyZWY9Im1haWx0bzpoZXJ2ZS5yb2Jh Y2hlQHN0ZXQuZXUiIHN0eWxlPSJjb2xvcjpwdXJwbGU7dGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmhlcnZlLnJvYmFjaGVAc3RldC5ldTwvYT4mZ3Q7 IHdyb3RlOjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXItc3R5bGU6bm9uZSBub25lIG5vbmUgc29saWQ7Ym9yZGVy LWxlZnQtd2lkdGg6MXB0O2JvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7cGFkZGlu ZzowY20gMGNtIDBjbSA2cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjowY20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+DQpIaTx1IGNsYXNzPSIiPjwvdT48dSBj bGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtm b250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiIGNsYXNzPSIiPg0KJm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+UkZDIDc1OTIgaW50cm9kdWNlcyBhIMKrJm5ic3A7 UmVnaXN0cmF0aW9uIEFjY2VzcyBUb2tlbiZuYnNwO8K7LiBBcmUgdGhpcyB0b2tlbiBhbmQgdGhl IHdheSB0byBnZXQgaXQgc2ltaWxhciB0byB3aGF0IGlzIHNwZWNpZmllZCBhcyDigJxJbml0aWFs IEFjY2VzcyBUb2tlbuKAnSBpbiBSRkMgNzU5MS9BcHBlbmRpeCBBID88L3NwYW4+PHUgY2xhc3M9 IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNt IDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+Jm5i c3A7PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0i RU4tVVMiIGNsYXNzPSIiPklmIHNvLCBjYW4gdGhlIE9wZW4gRHluYW1pYyBDbGllbnQgUmVnaXN0 cmF0aW9uIChSRkM3NTkxL0EuMS4xKSBiZSBleHRyYXBvbGF0ZWQgdG8gUkZDNzU5MiBhcyB0aGUg c2FtZSB3YXk/PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xh c3M9IiI+PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9u dC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj5UaGFua3MgaW4gYWR2YW5j ZSBmb3IgeW91ciBjbGFyaWZpY2F0aW9uLjwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9 IiI+PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1z aXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBj bGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHUgY2xh c3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20g MGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjlwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCBSb3VuZGVkIE1UIEJvbGQmcXVvdDssc2Fucy1zZXJpZiIg Y2xhc3M9IiI+SGVydsOpIFJPQkFDSEU8L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIi PjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6 ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjlwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCBSb3VuZGVkIE1UIEJvbGQmcXVvdDssc2Fucy1zZXJpZiIgY2xhc3M9IiI+RGlyZWN0aW9uIE1h cmtldGluZyBldCBEw6l2ZWxvcHBlbWVudDwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9 IiI+PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1z aXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsIFJvdW5kZWQgTVQgQm9sZCZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj4mbmJzcDs8L3Nw YW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjowY20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjlwdDtmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmIiBjbGFzcz0iIj5MSUdORSBESVJF Q1RFPC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5cHQ7Zm9udC1mYW1pbHk6QXJpYWwsc2Fucy1zZXJpZiIgY2xhc3M9IiI+VC4g JiM0MzszMygwKTEgNTUgMjMgNTUgNDU8L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIi PjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6 ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjlwdDtmb250LWZhbWlseTpBcmlhbCxzYW5z LXNlcmlmIiBjbGFzcz0iIj48YSBocmVmPSJtYWlsdG86aGVydmUucm9iYWNoZUBzdGV0LmV1IiBz dHlsZT0iY29sb3I6cHVycGxlO3RleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiIHRhcmdldD0iX2Js YW5rIiBjbGFzcz0iIj5oZXJ2ZS5yb2JhY2hlQHN0ZXQuZXU8L2E+PC9zcGFuPjx1IGNsYXNzPSIi PjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAw LjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOnJnYigzMSw3MywxMjUp IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48 L2Rpdj4NCjx0YWJsZSBjbGFzcz0iZ21haWwtbV81MzUyNjIwMDAxNTI0ODU2MjYyZ21haWwtbV8t MjkxODY2NDQ1Mjg0MDM0NjkyN01zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5n PSIwIiBjZWxscGFkZGluZz0iMCIgYWxpZ249ImxlZnQiPg0KPHRib2R5IGNsYXNzPSIiPg0KPHRy IHN0eWxlPSJoZWlnaHQ6NnB0IiBjbGFzcz0iIj4NCjx0ZCB3aWR0aD0iMSIgc3R5bGU9IndpZHRo OjAuNzVwdDtwYWRkaW5nOjBjbTtoZWlnaHQ6NnB0IiBjbGFzcz0iIj48L3RkPg0KPC90cj4NCjx0 ciBjbGFzcz0iIj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20iIGNsYXNzPSIiPjwvdGQ+DQo8dGQg c3R5bGU9InBhZGRpbmc6MGNtIiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNt IDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiIgY2xhc3M9IiI+DQo8c3BhbiBpZD0iZ21haWwtbV81MzUyNjIwMDAxNTI0 ODU2MjYyZ21haWwtbV8tMjkxODY2NDQ1Mjg0MDM0NjkyN2NpZDppbWFnZTAwMS5wbmdAMDFENTZB M0UuRDA0NUE3NDAiIGNsYXNzPSIiPiZsdDtpbWFnZTAwMS5wbmcmZ3Q7PC9zcGFuPjx1IGNsYXNz PSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8 L3RhYmxlPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1zaXplOjEy cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMzEsNzMsMTI1KSIgY2xhc3M9IiI+Jm5ic3A7PC9z cGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OnJnYigzMSw3MywxMjUpIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1 IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0 O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiIgY2xhc3M9IiI+DQo8YnIgY2xlYXI9ImFsbCIgY2xhc3M9IiI+DQo8dSBjbGFzcz0iIj48 L3U+PHUgY2xhc3M9IiI+PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20gMC4w MDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMzEsNzMsMTI1KSIg Y2xhc3M9IiI+PHNwYW4gaWQ9ImdtYWlsLW1fNTM1MjYyMDAwMTUyNDg1NjI2MmdtYWlsLW1fLTI5 MTg2NjQ0NTI4NDAzNDY5MjdjaWQ6aW1hZ2UwMDIucG5nQDAxRDU2QTNFLkQwNDVBNzQwIiBjbGFz cz0iIj4mbHQ7aW1hZ2UwMDIucG5nJmd0Ozwvc3Bhbj48L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1 IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0 O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6cmdiKDMxLDczLDEyNSkiIGNsYXNz PSIiPiZuYnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6OXB0O2ZvbnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWYiIGNsYXNz PSIiPlNURVQgKFNJRUdFIFNPQ0lBTCk8L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIi PjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowY20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6 ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjlwdDtmb250LWZhbWlseTpBcmlhbCxzYW5z LXNlcmlmIiBjbGFzcz0iIj4xMDAsIEVzcGxhbmFkZSBkdSBHw6luw6lyYWwgZGUgR2F1bGxlPC9z cGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46MGNtIDBjbSAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5cHQ7Zm9udC1mYW1pbHk6QXJpYWwsc2Fucy1zZXJpZiIgY2xhc3M9IiI+Q8WTdXIgRMOp ZmVuc2Ug4oCTIFRvdXIgQjwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6OXB0O2ZvbnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWYi IGNsYXNzPSIiPjkyOTMyIExhIETDqWZlbnNlIGNlZGV4PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48 dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFw dDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss c2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Zm9udC1mYW1pbHk6 QXJpYWwsc2Fucy1zZXJpZiIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48 dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFw dDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss c2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Zm9udC1mYW1pbHk6 QXJpYWwsc2Fucy1zZXJpZiIgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cDovL3d3dy5zdGV0LmV1LyIg c3R5bGU9ImNvbG9yOnB1cnBsZTt0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+d3d3LnN0ZXQuZXU8L2E+PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBj bGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGNtIDBjbSAwLjAwMDFwdDtm b250LXNpemU6MTJwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiIGNsYXNzPSIiPg0KJm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L2Rp dj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBjbSAwY20gMC4wMDAxcHQ7Zm9udC1zaXpl OjEycHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIiBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6QXJpYWwsc2Fucy1zZXJpZjtjb2xvcjpncmF5IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQpDZSBtZXNzYWdlIGV0IHRvdXRlcyBsZXMgcGnDqGNlcyBqb2ludGVzIHNvbnQgw6l0YWJsaXMg w6AgbCdpbnRlbnRpb24gZXhjbHVzaXZlIGRlIHNlcyBkZXN0aW5hdGFpcmVzIGV0IHNvbnQgY29u ZmlkZW50aWVscy48YnIgY2xhc3M9IiI+DQpTaSB2b3VzIHJlY2V2ZXogY2UgbWVzc2FnZSBwYXIg ZXJyZXVyIG91IHMnaWwgbmUgdm91cyBlc3QgcGFzIGRlc3RpbsOpLCBtZXJjaSBkZSBsZSBkw6l0 cnVpcmUgYWluc2kgcXVlIHRvdXRlIGNvcGllIGRlIHZvdHJlIHN5c3TDqG1lIGV0IGQnZW4gYXZl cnRpciBpbW3DqWRpYXRlbWVudCBsJ2V4cMOpZGl0ZXVyLjxiciBjbGFzcz0iIj4NClRvdXRlIGxl Y3R1cmUgbm9uIGF1dG9yaXPDqWUsIHRvdXRlIHV0aWxpc2F0aW9uIGRlIGNlIG1lc3NhZ2UgcXVp IG4nZXN0IHBhcyBjb25mb3JtZSDDoCBzYSBkZXN0aW5hdGlvbiwgdG91dGUgZGlmZnVzaW9uIG91 IHRvdXRlIHB1YmxpY2F0aW9uLCB0b3RhbGUgb3UgcGFydGllbGxlLCBlc3QgaW50ZXJkaXRlLjxi ciBjbGFzcz0iIj4NCkwnSW50ZXJuZXQgbmUgcGVybWV0dGFudCBwYXMgZCdhc3N1cmVyIGwnaW50 w6lncml0w6kgZGUgY2UgbWVzc2FnZSDDqWxlY3Ryb25pcXVlIHN1c2NlcHRpYmxlIGQnYWx0w6ly YXRpb24sIFNURVQgZMOpY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdMOpIGF1IHRpdHJlIGRlIGNl IG1lc3NhZ2UgZGFucyBsJ2h5cG90aMOoc2Ugb8O5IGlsIGF1cmFpdCDDqXTDqSBtb2RpZmnDqSwg ZMOpZm9ybcOpIG91IGZhbHNpZmnDqS48YnIgY2xhc3M9IiI+DQpOJ2ltcHJpbWV6IGNlIG1lc3Nh Z2UgcXVlIHNpIG7DqWNlc3NhaXJlLCBwZW5zZXogw6AgbCdlbnZpcm9ubmVtZW50LjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NClRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGlz IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGludGVuZGVkIGFkZHJlc3NlZXMgYW5kIGlzIGNvbmZp ZGVudGlhbC48YnIgY2xhc3M9IiI+DQpJZiB5b3UgcmVjZWl2ZSB0aGlzIG1lc3NhZ2UgaW4gZXJy b3IsIG9yIGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKSwgcGxlYXNlIGRlbGV0ZSBp dCBhbmQgYW55IGNvcGllcyBmcm9tIHlvdXIgc3lzdGVtcyBhbmQgaW1tZWRpYXRlbHkgbm90aWZ5 IHRoZSBzZW5kZXIuPGJyIGNsYXNzPSIiPg0KQW55IHVuYXV0aG9yaXplZCB2aWV3LCB1c2UgdGhh dCBkb2VzIG5vdCBjb21wbHkgd2l0aCBpdHMgcHVycG9zZSwgZGlzc2VtaW5hdGlvbiBvciBkaXNj bG9zdXJlLCBlaXRoZXIgd2hvbGUgb3IgcGFydGlhbCwgaXMgcHJvaGliaXRlZC48YnIgY2xhc3M9 IiI+DQpTaW5jZSB0aGUgaW50ZXJuZXQgY2Fubm90IGd1YXJhbnRlZSB0aGUgaW50ZWdyaXR5IG9m IHRoaXMgbWVzc2FnZSB3aGljaCBtYXkgbm90IGJlIHJlbGlhYmxlLCBTVEVUIHNoYWxsIG5vdCBi ZSBsaWFibGUgZm9yIHRoZSBtZXNzYWdlIGlmIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC48YnIgY2xhc3M9IiI+DQpEbyBub3QgcHJpbnQgdGhpcyBtZXNzYWdlIHVubGVzcyBpdCBpcyBu ZWNlc3NhcnksIHBsZWFzZSBjb25zaWRlciB0aGUgZW52aXJvbm1lbnQuPC9zcGFuPjx1IGNsYXNz PSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjowY20gMGNtIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRoIG1haWxpbmcgbGlz dDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgc3R5bGU9ImNv bG9yOnB1cnBsZTt0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIiB0YXJnZXQ9Il9ibGFuayIgY2xh c3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgc3R5bGU9ImNvbG9yOnB1cnBsZTt0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48dSBjbGFzcz0iIj48L3U+ PHUgY2xhc3M9IiI+PC91PjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxi ciBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4O2ZvbnQtc3R5bGU6 bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVy LXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJh bnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7dGV4dC1kZWNv cmF0aW9uOm5vbmUiIGNsYXNzPSIiPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBz aXplPSIxIiBzdHlsZT0iZm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFs O2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFy dDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7 d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRlY29yYXRpb246bm9uZSIgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KQ2UgbWVzc2FnZSBldCB0b3V0ZXMgbGVzIHBpw6hjZXMgam9pbnRlcyBzb250IMOpdGFi bGlzIMOgIGwnaW50ZW50aW9uIGV4Y2x1c2l2ZSBkZSBzZXMgZGVzdGluYXRhaXJlcyBldCBzb250 IGNvbmZpZGVudGllbHMuPGJyIGNsYXNzPSIiPg0KU2kgdm91cyByZWNldmV6IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciBvdSBzJ2lsIG5lIHZvdXMgZXN0IHBhcyBkZXN0aW7DqSwgbWVyY2kgZGUgbGUg ZMOpdHJ1aXJlIGFpbnNpIHF1ZSB0b3V0ZSBjb3BpZSBkZSB2b3RyZSBzeXN0w6htZSBldCBkJ2Vu IGF2ZXJ0aXIgaW1tw6lkaWF0ZW1lbnQgbCdleHDDqWRpdGV1ci48YnIgY2xhc3M9IiI+DQpUb3V0 ZSBsZWN0dXJlIG5vbiBhdXRvcmlzw6llLCB0b3V0ZSB1dGlsaXNhdGlvbiBkZSBjZSBtZXNzYWdl IHF1aSBuJ2VzdCBwYXMgY29uZm9ybWUgw6Agc2EgZGVzdGluYXRpb24sIHRvdXRlIGRpZmZ1c2lv biBvdSB0b3V0ZSBwdWJsaWNhdGlvbiwgdG90YWxlIG91IHBhcnRpZWxsZSwgZXN0IGludGVyZGl0 ZS48YnIgY2xhc3M9IiI+DQpMJ0ludGVybmV0IG5lIHBlcm1ldHRhbnQgcGFzIGQnYXNzdXJlciBs J2ludMOpZ3JpdMOpIGRlIGNlIG1lc3NhZ2Ugw6lsZWN0cm9uaXF1ZSBzdXNjZXB0aWJsZSBkJ2Fs dMOpcmF0aW9uLCBTVEVUIGTDqWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXTDqSBhdSB0aXRyZSBk ZSBjZSBtZXNzYWdlIGRhbnMgbCdoeXBvdGjDqHNlIG/DuSBpbCBhdXJhaXQgw6l0w6kgbW9kaWZp w6ksIGTDqWZvcm3DqSBvdSBmYWxzaWZpw6kuPGJyIGNsYXNzPSIiPg0KTidpbXByaW1leiBjZSBt ZXNzYWdlIHF1ZSBzaSBuw6ljZXNzYWlyZSwgcGVuc2V6IMOgIGwnZW52aXJvbm5lbWVudC48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50 cyBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBpbnRlbmRlZCBhZGRyZXNzZWVzIGFuZCBpcyBj b25maWRlbnRpYWwuPGJyIGNsYXNzPSIiPg0KSWYgeW91IHJlY2VpdmUgdGhpcyBtZXNzYWdlIGlu IGVycm9yLCBvciBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocyksIHBsZWFzZSBkZWxl dGUgaXQgYW5kIGFueSBjb3BpZXMgZnJvbSB5b3VyIHN5c3RlbXMgYW5kIGltbWVkaWF0ZWx5IG5v dGlmeSB0aGUgc2VuZGVyLjxiciBjbGFzcz0iIj4NCkFueSB1bmF1dGhvcml6ZWQgdmlldywgdXNl IHRoYXQgZG9lcyBub3QgY29tcGx5IHdpdGggaXRzIHB1cnBvc2UsIGRpc3NlbWluYXRpb24gb3Ig ZGlzY2xvc3VyZSwgZWl0aGVyIHdob2xlIG9yIHBhcnRpYWwsIGlzIHByb2hpYml0ZWQuPGJyIGNs YXNzPSIiPg0KU2luY2UgdGhlIGludGVybmV0IGNhbm5vdCBndWFyYW50ZWUgdGhlIGludGVncml0 eSBvZiB0aGlzIG1lc3NhZ2Ugd2hpY2ggbWF5IG5vdCBiZSByZWxpYWJsZSwgU1RFVCBzaGFsbCBu b3QgYmUgbGlhYmxlIGZvciB0aGUgbWVzc2FnZSBpZiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuPGJyIGNsYXNzPSIiPg0KRG8gbm90IHByaW50IHRoaXMgbWVzc2FnZSB1bmxlc3MgaXQg aXMgbmVjZXNzYXJ5LCBwbGVhc2UgY29uc2lkZXIgdGhlIGVudmlyb25tZW50LjxiciBjbGFzcz0i Ij4NCjwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZTox MnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdo dDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRl bnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2lu ZzowcHg7dGV4dC1kZWNvcmF0aW9uOm5vbmU7ZmxvYXQ6bm9uZTtkaXNwbGF5OmlubGluZSIgY2xh c3M9IiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXpl OjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2Vp Z2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWlu ZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFj aW5nOjBweDt0ZXh0LWRlY29yYXRpb246bm9uZTtmbG9hdDpub25lO2Rpc3BsYXk6aW5saW5lIiBj bGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwv c3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJweDtmb250 LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFs O2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0 ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O3Rl eHQtZGVjb3JhdGlvbjpub25lIiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpI ZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNh cHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1h bGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFj ZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRlY29yYXRpb246bm9uZTtmbG9hdDpub25l O2Rpc3BsYXk6aW5saW5lIiBjbGFzcz0iIj5PQXV0aA0KIG1haWxpbmcgbGlzdDwvc3Bhbj48YnIg c3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5v cm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1z cGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5z Zm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O3RleHQtZGVjb3Jh dGlvbjpub25lIiBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgc3R5 bGU9ImNvbG9yOnB1cnBsZTt0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO2ZvbnQtZmFtaWx5Okhl bHZldGljYTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNl Om5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+T0F1dGhA aWV0Zi5vcmc8L2E+PGJyIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEy cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0 Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVu dDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5n OjBweDt0ZXh0LWRlY29yYXRpb246bm9uZSIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiBzdHlsZT0iY29sb3I6cHVycGxlO3Rl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZTox MnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdo dDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRl bnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2lu ZzowcHgiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhO2Zv bnQtc2l6ZToxMnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtm b250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7 dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dv cmQtc3BhY2luZzowcHg7dGV4dC1kZWNvcmF0aW9uOm5vbmUiIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4N Ck9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9hPjxiciBj bGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyIGNsYXNzPSIiPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_ACE2CFA30D174EB1BF3101BEBBB7222Cmitedu_-- From nobody Wed Sep 18 01:56:37 2019 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 8FAEB12008D for ; Wed, 18 Sep 2019 01:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=curity-io.20150623.gappssmtp.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 irEvnMjBi1p3 for ; Wed, 18 Sep 2019 01:56:33 -0700 (PDT) Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (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 9B3C31200F7 for ; Wed, 18 Sep 2019 01:56:33 -0700 (PDT) Received: by mail-yw1-xc2d.google.com with SMTP id 201so2168668ywn.13 for ; Wed, 18 Sep 2019 01:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jIRY+X5R78ay1YxAcQhAgXfwkLIX25JJYGhNG/Botpg=; b=Vyj0AUUTbDYy/dMTWZOjnJVkUoFRPleUCu3HBEbQLkWMz5pskncM8sbiRO4NLZmPM5 O1pobymEOHgpFNl/2lqoM6KV7ZASP6KKQm3YMZaul2z3ES/tVmzTiYtka7RuxPlLlHMs q+aL6zcW5LH1yymEjSIRiN5Xqo55N/DlcDzMON5nGxTdwUwqsX7ac5b1oGTByykhQ2OX 9k9Yg3ARlg+tNi3etrg4JIGGpixz5wI5S/2mwh5OmHN65Sj8y7B4DdykgDmMpvDb70zr pKNOMOFsyIZqMYU25NWlcDO4ErYmYqfDSYjiAMJQdPgK36/yVUTjcCAryHEQCkH3C90P wixg== 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=jIRY+X5R78ay1YxAcQhAgXfwkLIX25JJYGhNG/Botpg=; b=oD867bSpbOVzo3opLf0r34Jtk7yrWwd2Wwi3J4QqX1TN4mvOoDziMnFhmgTl1hcUnA ObaznkTD5NDIynwIzCvkWe2w0Jc6NiagKgi4M/LHbgH26J+NVBfKO1LWSL4cWSOEObyC NZzkCX06JONqLjGnSTDCap/3voqqN6cCaOcVJLvZGrzQss+79xZta6P6b29tkTz8Z5IC ffEdvuBHrIrF5EzpqomHg1F6njWYwbMhk6SRiSfRiNVSWLIGCspdOhDNeb2RYUlC21F7 RS/wX0p1eHKvgkqtOIKR5zjreviPtWDD9wMeVGJOsvCGGaCe2L4OLkhtEPaDWSGjDtKh OEmA== X-Gm-Message-State: APjAAAV718ocTcfs6C1l/8k13svKmN9PZe8dO3SaEtZsPUsvOX7EXRxB nCDghYycVizVg/dQj024KMvRGXe7YI7yEO1t4i6i7w== X-Google-Smtp-Source: APXvYqxRTEW6ENZVbQ1o3f/FreYN2B56OC1HK7ZlMEx1B0gwy+0bSTendwPurtdi7URQXk5BK2Pw0V/VWe1RsxoiQoA= X-Received: by 2002:a81:990e:: with SMTP id q14mr2426021ywg.47.1568796992789; Wed, 18 Sep 2019 01:56:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Travis Spencer Date: Wed, 18 Sep 2019 10:56:21 +0200 Message-ID: To: =?UTF-8?Q?Robache_Herv=C3=A9?= Cc: "oauth@ietf.org" , Mark Dobrinic Content-Type: multipart/related; boundary="0000000000007b4e890592d00312" Archived-At: Subject: Re: [OAUTH-WG] Question regarding RFC 7592 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: Wed, 18 Sep 2019 08:56:36 -0000 --0000000000007b4e890592d00312 Content-Type: multipart/alternative; boundary="0000000000007b4e870592d00311" --0000000000007b4e870592d00311 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 13, 2019 at 3:18 PM Travis Spencer wrote: > Ya, this part is confusing. I didn't get it at first either. > Seems I'm still a bit confused ;-) this metadata isn't defined in RFC 7591 but discussed in section 1.3; that > spec leaves the metadata out of scope. It is, however, profiled in section > 3.2 of OIDC DCR (see registration_access_token in section 3.2 > Mark Dobrinic pointed out to me this morning that RFC 7591 (DCR) is updated by 7592 (DCRM) in section 3 to include the same registration_access_token response metadata that OIDC defines. --0000000000007b4e870592d00311 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Sep 13, 2019 at 3:18 PM Travis Spencer <travis.spencer@curity.io> wrote= :
Ya, this part is confusing. I didn't get i= t at first either.

Seems I'= m still a bit confused ;-)

this metadata isn't d= efined in RFC 7591 but discussed in section 1.3; that spec leaves the metad= ata out of scope. It is, however, profiled in section 3.2 of OIDC DCR (see = registration_access_token in section 3.2

=
Mark Dobrinic pointed out to me this morning that RFC 7591 (DCR)= is updated by 7592 (DCRM) in section 3 to include the same registration_ac= cess_token response metadata that OIDC defines.=C2=A0
--0000000000007b4e870592d00311-- --0000000000007b4e890592d00312 Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: <16d2abbe3b44cff311> X-Attachment-Id: 16d2abbe3b44cff311 iVBORw0KGgoAAAANSUhEUgAAASoAAAABCAYAAABpJuNuAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAbSURBVDhPYygwWLAfiP+P4lE8ikfx4MQL9gMA lmac9TWs31MAAAAASUVORK5CYII= --0000000000007b4e890592d00312 Content-Type: image/png; name="image002.png" Content-Disposition: inline; filename="image002.png" Content-Transfer-Encoding: base64 Content-ID: <16d2abbe3b45b16b22> X-Attachment-Id: 16d2abbe3b45b16b22 iVBORw0KGgoAAAANSUhEUgAAAL0AAAA7CAYAAAAuPov1AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABkOSURBVHja 7Z15WJvHncfTNpttkl6bwwfmkATYmBtJxlziEIcAYcDmNmAuIQ6DOIQkQIAkwCAkARYgY0EINiEK 0SY4CZuwLtuFrmnLs6V9gvuQJmlIt9uGHFtrW3sbQmtnduYFbGxLgC5QUv3xfeARr953Zt7PzPx+ v/nN8IhIJHrEKqv+nmRtBKus0FtllRV6M+uzz245MYSTzKiCy2OkJOUV4qkLV0hJuyfvxAtXQnNG ruQ1vCUbn1ogW6GwQm9WccRXyyhZwzedYgfBwdBeYBO2N0LPtou4CIjJQ1+IB2dqrWBYoTeLChpe E7smDoOn/KRgf2AHOEiR7KkOBHWAf4JlCci8DFST1hHfCr2J1SifPu1xchg87b/3sD8ou4h+kFf3 aq8VDiv0JhMA4NHgrOc+fCawy+KARzoUfgH4nOq/YIXDCr3JpBiZDT4SewHsC7Q84LGRHkKfxBpT WuoLk8snHyNEML9DIOhQBO/JRx4B3/i6AMpkir+9VX0jIsRPWDz0+fzxaseYAcyGtjTg98MyOcYo QVnzm0xLhUAoUdV6BrM/IfgUfuJIYt4ngk/RJ8Swql8rlVPf+7pAn5LXoTx8nPVQXZHwPsWfxKQJ pi0eenrRC6MoWmKJo/z+ICk4HNv3uVAxe8Rioe94SewVWgscycXA6VjJfXIklwKfsMpbEPrvf42g f/WIf9VDdUUikM+CmFThuxYNPbTnH/NNufjL/cHdFgn9s4EyQEru/wMs57ctF3pVq2dwDSAQCwEc 7e4TgVgEiGGVf/yaQT8GR/qH6oqEJxZD6AXXLRp69ezSPs/4vs/3BUotEvqDIb0gJGvoLQi9xdrE Vui/YtAzBBNUp5j+2weCLNOJtQ1XgKSKsXZLhsAK/VcM+ty68XP2kf3ggCXa84EdwOXEAOBJplKt 0FuhN5U9/43wvOE3LNWJfTZQAjwTFH8bn1p0tkJvhd50Tmzqxf9GzqJFRm6gc01M6r8Oy/kPpqz3 /PySk1I17ZZRKnMTilVuswvvucFnPGGF/u8AevHQjPNRuuIvKCxoidAfCOkBNMbll42t58rKyrO8 5tHyuNNtL/nReG8HRHP/6kfjAg8KC5Co1SAkng9IYdUf0tOb3z5d1N0nkKjTl5Y+O7zT+5/rflm4 NfRV/2PO6BMaFIRitReTrWScPNMhCY3nj+aV972dVdT5SzKV3ZNZ1CUp5Q0nTE0tOpjieekF0he3 gj42XbhgsdBz+n96+nDcMNhP6QIHQ4xR99rPYNPNGGihjBCtBNkcNdcIGH7AYPUKqYlNN9wp1cDp WBkgkEqAgzcDE57IBDifQmDvWQA/L4a/F4MjfhXAK6QGhJzgf5GcK5mpax5lq8dn7nYAjUbzeESc cD/BlbmfQFpTJX+w24PC1gm9d0iFJi5D6LxxvW6x9jN5ymf0mLEOMCsVQnrGuQ88gyuAa2AVOBpQ BRzJZ4G9FxPWsQg4QzjRZx6w/r6RnP+jp7X+q1A8dga2zbd28oypqaUnSRGC++obn9n62uHj5Tqh jzzV+M5O6nr4sPwxo6CfUcweHRdMnL3EHK0Y3oHUZa9UMPIu/OTA8XpgQ+YAm2NGiFwDf3LBwYBm k8GPnFiUGiFQTIcb0h6q8WmXtELZ+y4BlRCAQq1A6hIedQQv1ClKgGtQDcgs7rq72MITDKcTqbxb 8Jpb8FpMzseKVh1JRVvd80snEvP/Nq7XpSN+rFspOW28HXTmb1c3DTcHxNR+ikB38EZlZm5ZR/Q3 1MHR4pFXaA2ISWtZUAxNZm73rAyGrAk+45Yjkbm5vn/bqv2cyEV3tqurs+/ZW4d9GBEGQT+rmgvq jFJcaSZ13G71koEWD+mO1OHZDcIcM8Gz9v7AziHENMKHg0PuuRDaDqPBfyZAAnxTlZ8vLWvs9AV+ YnLONTJZ9AccsRQDeKewa32Bx8pBUm772Ma9k/PE0iN+lfDFFt8VYSf32XS9NqEZwYfKBWW8wfgt 11UmZlwzCrsX3Ck1GOz6dOZ7nZqBzWq+UbWghHOxZyufKS69ZdqRXHZfWbe7P2EH9UUzBcGHEaM3 9GN14znS0B7AJ7QCtkMDYOP4gI3fXjX4BuynO44ODuIgrDiqaeQQCuzs/IGtayaEvtMo6PdRugEl c/A/DTBpnoBgLhLgi9oOCAKRue3fXQMrQSZDlr8R7aIm8n+IzCRjOpI24SDAxyNrVtQT87a66sbi KdyD4xo+RhAicI19JjLrvEJ5IKu4+y1tPgf87Dv+NO7v8MQik9cXjvTAicSg6QX9pHgquCPwPGDb QogJDXqJR2gCJQQOwOEiwCFcmOmgxxSGjfo2x/lGgW8XcQFEM0f69IW+WTLW6BnChSMZQ6fpguxO Z99yzAZG5g+a8gnk0nUzofC+a0nhNbdl8nG/dXv+uwE07ic4H6bpofcpAmEJ/F9D0B7XVi+ZfMLD P7p2GU8q3bIz4zBfBY7GxyBUUOi+6DPd1xeAI/6VgFHV9+ZDgQ7F+FHk6OOMnC1NAj1smCflCRff 49oJ9AYeqZ4gBKfxZ8EBU47ym2VPAYd8ytccXIOcWAnA0y4ApmCiQM9R/tGwhPpFNHVra2gH70Lo pFYB6Pj9PP50a29UirCeEsurR+ZLdKroWmAMT0Ok1mDOLOoAth4MQKHXapY0GixDcmhkKtA3incH Z4JR9mEzqgykFUhf1Vav5WWNTUJWO+xsJTqBRzOFi38FOE7j3vGP5i0GRHOvkcOrr/nTOB8hMwbd Xxf86HO3oGpQxR+s3/zc/NKuTPegqm1nxF2Bflw4GdRClIJqB75B0PMJIhCDzwH7cBQzQR8MDhFZ BkP/bEAH8DypvKNQzfnqA32rXH2MGF6jFUoH6MzS01s/l/SOJ20R2tzXKn+FVsS+qKBntH5AjqwH cRktb6POhP6eyZSwDvtVATuvQiw6siE7T8Y2ZlIh5kxv/s793y+EMw4bMKt6tUaqzhR3vebsy9IK PDJzkMNNoddrcsvPS1TqOdeN8m5EsLqUbyYkZre/Qo7kYR1fq6kDHfeQ+AYwop6+G6lKyusYwxHL HyqvgzdjG1ONobOuG8IRzwIH99zYHUOvzB6uE7qIDQIeqZYgAMfxSWA/LtgM0Idhtr2Nb/1aJMcQ ex7LrFR+hGY0faA/mdN6BtngD8KBw8wUzu2h0R9l6jFr/KN88M24wUtTGXdNJ9lY+5lSxftp+ZL3 U/I7MGUwpe/T05tvELaIBLkGnr2dktfxQVrBve9tFrpfdsn5d1vl454PLXy1qaJ9wmq0mhionihe nlIgXZiYmMNvV6fGVlWWP423gkwerbMNNPmg4zqycX1Vw3MvZhTJYfnulfU0U/Z+8Im6m7pMHgT8 sUj2FxmF0vva6cH6ZhbL4e+tlB1D35cy+GY9vtkg4LmERlBFqAcuuBhggws1PfTImSVEg4OBbYZH cEJ7gX/6wL/oa88XVysG0BSvbRSLSRX9EYFsbNqGNvUo3zinK06Ph4CRw6vQs3+g6/sb0rbolMbo +A2Kt2vtUKQSkJwrWYDX7d/xbChTRx6P4v5VG7RoBPeP4d2ZnJx136q+uaXnx5BPpMs3ic9sub5d XR+s77bRibbgzt9wHQQGj/KFhGoMUFuTO7Frpo3tkeR1J9awlV5bqgKcLFPpnVkJR6HntUGPpnTo JN4wFnpdEnS81LxdGoJYrP6OvveFphgV+RjaIjWoTpQ4/q3JyXlHfe/Lbhxqcoc2PP6B8qLyu8LP y3kXO7f6fnKu+KUt0xDSBKZdkZ1TzRGEvu2Abc832IlNwReZybRZd2I98g2257FFqbgBUNb25il9 G66Md/E8ckK1hR4P+579sq7lhee/KglnaCQsqOh51UnLiIqe4xZYDbKZMp6BM9a3YtNFS9rMHOQf ZDBlP7ao3BsVayxJ5N7xJRvfYDD04fhMs0JvQ6oyGHq0Od09/sKqamJe78xKjuBSApHK0xquRFM3 OYIHClh9r6nUM6SvAPRPUBMaPkZRJG1OOSWu/ubS0rLBuTQ5pV0lKGKzucxocDgaUAmS89rbLAr6 rjiFQHCk3SDgOesxeiIu0UzhyjVzycavyeAY/TPQiQ3Jeu73aGFE34ZbXlx+Oohe+5GDDkfNwasA i8/7RnHuBNF5107lii+W8YZOT08vHLE06OcWltyP03i3tYUZUSTnRGbLC0b6J48ei2DfwBPvd7p9 wjhAKBnLsBjoYUG/2RXTO11nhBNbTqgFTjgaOGQWJxZ2JEc6OBgkNsqJjcgdVhv6MplsRYVnKFdn TBrLQYH2MIFUCg5DUwgloh2ncVcTstp/3Ng2xjQkG9IU0EekCJ92CSwrJJAYmDyDys67+GlfVUYx 7oAY3hUcicnYuF5fuQSWFvrROH/E+9wf5SKHV6+qxmdxFgO9RqP5XluITFNjZ5hpUwed2FxCBQa8 rZlMG9uj6QaHKlFmJZ6mBCdZY9VGjGDfSiuQvuIWVAPs4ci+bZ7IeidAK52eITUgKln0rqBNlb/b 0OeUylleYfXYKI6AQqupulde0apyEXadoUIz3oOOLAI2mF77znb7kXcV+in5tK/Ip+OvbJzh9nwC vsC8TqxXEYT+vIHHfUiAc3QfqJNcpRo5dT+eXtg54BfdiIXQdpp0hq5Dq7ko8Su75PyrO432mAL6 jELpOEodMPXKp76rwvSMFpVFbSJR5lzKaXaXrCWNGQg9BZ8G9pkLepRzg1KMDXRiUWYlKal/ZXFp +ZApHMy2rleY1MSmRa9QDpZjjsJ8COztltWRaYTOdaGebPzh/Pz84+aGHsXjwxMb3sFyZvYIeNQm KCJUzOnnWRT0ipSB5xqdzxnoxDZiP93xcabNrNzsxOIj13LqDbTn9wV1g+DsoQVTHveBbHR+62h+ XGbb6xR63Z+8Q9lYhAK9HJy37hkATf1O0NRIY0intttKaCz0U1PzDn60mjvbLe+bUzgsusUFzV1q qsVAj0Doiut7h2vfZBD0KGpTSuACPC7SDJmVa6O8rXPC+oKUYYtSNmEKkFd/5UVz7RRbWtbYCGXq mOyzPSJaimieHM7G7FsHL92JWMSIesBpHOKYE/oq/hDdnVK5PgttaHehR7NgSDz/1vKyxtZioNcs aWxajkv/t8ah0WDozZdOvO7EumUZbNo87ScGPsnPg9GJhXBzQf/QzKmcIhZW9Y/4R/O+RMfvaYMW JUeFxTd8vLSk+a65oE8tkHSQowTAncIGHsFrcvFnYdsZ1zZtFGHOqyORsfYT3ZtcBG3wUhOKhVat f76Tdts16McbJ6gos5JtYGblXfMGF2eeGD2WTlxmkBP7bIAYEGKHAIP/+nO7Bfx9m3Fenw2LSBIt OsKXfxeqTc6tdxgH8FsvZZgL+uHRH+WIOl9ta2pXtTVAiaQvt1XVKf7ZyS0GHHCAg4lTJLB3iQc4 9zRA8M4Bzr5lgJrQcJVAYgZBBZtCroGsYM8QFt6ioB/MvcQTGJFZeS8FoRhLKTatXb+WWXnQtw4c CO7E8uG3Vsf66msHdF5lAP2rn4LGN94w5hgOYzU1s+ATEt/0F22pty7+lSA6VdC2uyuyK8+QAlL/ cujIKQh67npnLMKEwKJCx3ev2mrXoJeEn3+hwanVKOg3Es5O4WED4mjYiG8SOQSBgwQaIET1AUL0 AHaKwXayj7gAXOKUICxv9PelzZOle/UCN4uWIngRbcV7yN71KQZ55T0/2U3okcISG6cdodmBTJkH nWzPEDbgCIaSLBH62DSR8dCjCISY2r1kaGblg6kIaMRnEWpBFr4MpOFLQLqRSrUtAiVhglu1Xf8m 4cqmtlVTz39I8vnjXLZ4OgTW7SlLAB4JvqyL2qBHWwnpGc0vGQq9VzDrMwi93rNYXetIk0dwjdZ1 BrT+EJvW/KEh6RrGKilXN/ToiBVqAv+XRkM/N75wuNlfAqoNzKzUlZJQB+GvN4GEhHagjB94fS+B nZl7j4By1o25BzRhPtCWeegaWA2o8fwGnd+Vjkm8Qjg6oGcCr9DqFbF8XO8EutnFpX0BMbwb2pLO 0LOO+FfAGah3zNi2m5ya85ErJxg7vf50oUytC3q0bTEolocOt/quUdCPccZThO5i7BQDU0FvMsEy oV1cl0tVe3qycEahTBGT3vZf2cXy6pnZhaP6fr+U1892D6rUmmOOoil1zSOFur7LbhwqRTu2dC36 oOMuClh9Q4bUK6u0U+gWpH2DCgqpeodyQX6FQqUvZFinmlt0ZwsuD9JS2+6k5Il3/D+9mJV9l3Rt IkGzEjpYqq1LLTAK+p7kgRbMibVA6NGxIy0+UjAunIjbS+gjTwl+ZudVgp1wEBDDvZ2Yde5aGW+w fkQ9E7yysvK0jrWPp5QjM5QzpedVXiHad/2jYzLQsX/T0ws6j/lLyRf7o+/rSndwwLbQ1QLYMUfF 8glfjUZjs9N6obJHp4o+0rXZHVs99mNB57H5nWLO4MntZrv5xWXb5i51Xnph50RAbO0q2n9wFLYZ XziSstMyhcbz810DKnXmBqF1D0pcAyis6O0aUs94wTI9s97etlPTi25MtjI4n9XfyG994fmNhciH HiKNkl+tJ7RY3iiPhGsEomPiPy9OLO7fK+CXlzWHQuLqVtC2QPQi1o7sK8Hi3r5RPHAsvPoT+Pfr ELrrWcVd1zOLOq/HpIquU+i1H/tGcrHkK117PtHxIPGZrRNbPV89MWtPDmff2upoEAfvAiy3hRxe A/xotX+C17+x0/rJesdjYD1u69qAvnZ6GfQdoHNLSxYtx6aLRriiUUl2cVc2o0pRwhW9IPGP5kgj k5rmoLl0k0jl3k3LQEl5fjQOgHVw2nGCnURFJ1I5W+Y0ofuizuhH4wHfSPan8LPrQfTamxR6PXAL ZAGP0HoUgbqidaRHm6OFvu2/4+IEFgk9cq47qN2/Qicg7xX0kt7xUGIY+6GXsJZBycAyEtfOsCy6 KywNwYe55Zkw2J7R6HrAb1VteyrDiczWX+BgR9v+fBsImncJiE4VzupTR6FYJQqIbQK2HvlbJsyh DSaoc7lDk8gFQncU2v1oswga0dFAgFvPP9rsEEclCX6rzyb8paWl7wVEcz7V5mtoa0O0T9j52L1O trZZpQLks3prtEI/MzR7vIUs/dLQRSlzq8HpHLiQNvDSXpo2sPGqPHRETwxflmdgoOSc7e7eIZSp PmFcsJP8GWSC5ZTJ2/Stp0xxReEX3bDtkSMbHV7b79oyK6OSBXpvSMkp6+K7UzgGnbSGnZgQwQVC mSpcK/SXmKMFLZ4yzHa2OHsezwciNwkYKVVV7iX09PTm19C5lSYDHppJHsEcUM4b+BnauLPTchRU 9KhRHv9W4GMrvKE1gCccPmVIXXnCSzkh8Q2fI7PL2JPHsONJYHlzS+V1+pYDtsv3Mwo73yGQyvQ+ LxTNNgExtX9eXFw6oBX63uSBAUMzK3cjctPk1X5bxZ/w2UvoUwskr/hG1WMhvI1j7PQd9e+e6ks6 i2UblnCUF/QNgaIISklN/1vecMRHOTt4HcdsUOh1X8zMLboaWl/V+KxbSr70KnKe147lLtD7VGbU Ti4ofTqx8VOeYMTNoFXs2XmbtILOn6OjwPU5TBY9+8Tp5sXNB8dubsRvtlKkP6nDiywTeodG0Ozf cWNleWVPF5jQphGxfDwIjjydkUmCX/tGcbFtgGihCW0LRI1s51mwZs8SmWvn0iP7EpkJKNEMXoNM DmJY9d+yS+XXlMNTscaUh982WhZ3uu13aETHDnsll2L+A5pB7KE/ERrPf1efGUTn4pXwUgT0JSaR c+gezMbqgXwVVNe1o7vX6rp27HgRdk4Oiq+jow3DEhs/yC2TC6emFg8Y2faPneUMtIScaLhxr81L HmpvrO5QaEfYYT82SM4TP681ZLm8tHyoLUh2s8beAoFH2w/xzUAa3TO7l8BreQmPKoYmfVj8wfK8 8p6XaSmiawExvN9GnGpa9aNxVr0orFVPqOPwd2piwyo5vPoX6YWyH2UWd7Fb5eMuJizHDwRt6pN5 ZX2XoDlyLSCa+yklrn6VHFm7mpjdatLEusmpBZ8y3mBNaoH0jdCEhuuorqTw6lWPINaqd0jFKnz+ ql9UzYfx2e3XGFUKOV84Gm7qM4CWljQHitmDmdkl59Wh8Q3zEacasfZGbe0dUrkaRK9dDY2vv+kV XDGbUdg1w2QriFqhnxRfjTl3rNPgMyvNrUanNqA883yvJUGvA8AnNSvAfkQ9a8/iKTGh3zUajf0u luGp+flle6FYba9Wzz5lxud8YwXWVSxX2zNZcnueUGm/uKSx3+1kPlQGFMplwrbmCUfsZ2cXURkO brs41ZXUT0crsWwLXJSqtqsHbb5dYEI4GWjp0Ftl+brnKChmAlrIUpPm3JgEeFw9aHJqB8/lXr66 +YRcq6wyGnrkJPScuvgrvkOLRYQs2Qh42AEFzmIwePryu5odbC2zyiq9oF+z66cdZeG9751z7wS1 OBGoxe+R4LOFLh3gnG8nGMi4PLSysrLf+rKsMgv0WBRnefnpEYa6+mLa0L930xU/7Yrp21WhZ55P 6P+xMn24eW5kLsD6kqwyO/RWWfV11/8DWg8dgPgaldcAAAAASUVORK5CYII= --0000000000007b4e890592d00312-- From nobody Wed Sep 18 07:24:33 2019 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 6D38F120099 for ; Wed, 18 Sep 2019 07:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bnH-K4ec7Oq2 for ; Wed, 18 Sep 2019 07:24:29 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 AB1DB12006B for ; Wed, 18 Sep 2019 07:24:28 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id a22so156434ljd.0 for ; Wed, 18 Sep 2019 07:24:28 -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=2xcxIyzPiNYDytanYAoB2F5OmkSofGsF7wp//54DnvM=; b=qJpGuZ2tL8OFoSi6XTr1fHVrfzCAYPReXbfBRYmYcaFd79LIzopbzk4y1Wzr8e5+6S 5aUhaLwM9xJBrlrRnRMKWGD28VT377twF4oDn5v9DTNmW1XT9bVK+UyQHpKvfOX8X/8N BPkcu//HIQaysx4WrN3VAvhkOzn/m9sXdUvypC22Bg9cX6h7HOLkVSo762HhST4IIabX RjscJoRJc19RSbA9BqSVcV5LuPj4ZABTvu89tZ2TPmSyueToSkVvFsex0y1g2av1DMOb dj5fIXPyS0nyo/XOqMqaf5sICSnkE3DjmSC6FQljRg584TFaOOwWugpVMOUrjaBrWR8K 0ekg== 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=2xcxIyzPiNYDytanYAoB2F5OmkSofGsF7wp//54DnvM=; b=HAXJtyDZTyI7aKsXBWqxAxjCv3OG9T00xqaUhoL9/GrZps4nwNTEuKOolf0512vbd8 kU9qO09UGXAbklHQ54xLZjF+EjwgbpyXMMIyQJ2shCvKxHxqOr8rCggn2gHCn3YPn8j/ CMMdzSRMhaO7qFOPAJ15IPO0vxd383FTwjmk5Hz9B2qFbyoh/sQXkrBvW0uTPHtxNJGv 7HMftLbKZSQPSiJN8CmVBykTVOiV/dk2mFgaGrt/6+rnin4qIIprKE9cy9+6TAn8ZBHF dagmO6U7th56VLS026S86+ezb+PWGr/jh2HeagM1qRBVWERxaiqN4AXHLtPM9dUsARwB xs2g== X-Gm-Message-State: APjAAAVHYXKwU+RlejU/4RV1D7YKbsk7a+NNkaDA9QxG4XvM7zxCO+Ph jiXUIjAXOP98q3wlYIqkaf1q+RqvqPX2GDnYDc4= X-Google-Smtp-Source: APXvYqz3TMNBm8AP2TYTIUhei/BXuBSozyUxLmqtogAsS33UBj3ZXwZA4wbpeNg6n2uPb8UO1PvhfNtqcJ/jgpzk8tk= X-Received: by 2002:a2e:3618:: with SMTP id d24mr2378257lja.179.1568816666699; Wed, 18 Sep 2019 07:24:26 -0700 (PDT) MIME-Version: 1.0 References: <827BB5C3-2143-450A-BC3D-72F98CD0B475@mit.edu> <1BEA1464-9B31-4FBF-8619-16096F13BBDD@mit.edu> In-Reply-To: From: Dick Hardt Date: Wed, 18 Sep 2019 07:24:15 -0700 Message-ID: To: Justin Richer Cc: =?UTF-8?Q?Robache_Herv=C3=A9?= , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000022ef870592d498fd" Archived-At: Subject: Re: [OAUTH-WG] Question regarding RFC 7592 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: Wed, 18 Sep 2019 14:24:32 -0000 --00000000000022ef870592d498fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think of cloud infrastructure having control plane, and data plane. Control plane APIs are for managing the things that use the data plane. The data plane is the resource. Not trying to change your mind, just sharing my thinking. On related efforts, in FastFed, we are looking at using a JWT to access other control plane APIs. I agree on first take, that storing an access token is easier than working with a key pair. I should have more context, which is managing the credential life cycle. What happens if the access token is lost or compromised? Does the app need to be completely re-registered? With a jwks-uri, the client can rotate their keys and continue to make API calls if the private key is lost or compromised. =E1=90=A7 On Tue, Sep 17, 2019 at 8:10 AM Justin Richer wrote: > I think this is where we disagree about the nature of =E2=80=9Cresource= =E2=80=9D, as I > would classify a management API as a resource. Specifically, the client= =E2=80=99s > own records at the AS. > > The =E2=80=9CIF=E2=80=9D in your statement is a big if, and one that is u= ncommon even > today. Also, I want to note that if the client can=E2=80=99t "manage an a= ccess > token=E2=80=9D very well, then it=E2=80=99s going to have a very hard tim= e being an OAuth > client once it=E2=80=99s done registering. In other words, the goal was t= o take a > piece of universal functionality that all OAuth clients would be guarante= ed > to have. > > I=E2=80=99ll agree that it=E2=80=99s a bit weird having an access token i= ssued as part of > a response, but the alternative was to invent a new flow to force a clien= t > to go through another round trip to the token endpoint to get its > management token. If you=E2=80=99re already directly giving the client a = temporary > credential that it can use at the AS, then just give the client the final > token to do the job directly instead. At least, that was the thinking, an= d > I still agree with that line of thought today even with its quirks. > > =E2=80=94 Justin > > On Sep 17, 2019, at 12:40 AM, Dick Hardt wrote: > > The registration supports the client having a jwks, so if the client > provides jwks, then using them to sign an authentication request seems > easier than trying to manage an access token. > > The token endpoint is an API as well. We would agree that it is not a > resource, but a management API. Similarly, I see the client's management = of > its registration to not be a resource operation, but a management API. > =E1=90=A7 > > On Mon, Sep 16, 2019 at 7:36 PM Justin Richer wrote: > >> I don=E2=80=99t see a reason to use an assertion here. JWT authenticatio= n would >> require at least a secret if not a key of some type for authentication f= or >> all clients, and it was determined that dynamic registration shouldn=E2= =80=99t >> require the clients (even public clients) to support things they weren= =E2=80=99t >> already capable of doing. Besides, the management endpoint isn=E2=80=99t= a token >> endpoint (though I=E2=80=99m curious to hear why you=E2=80=99d say that)= =E2=80=94 it=E2=80=99s an API you >> can call to manage a client=E2=80=99s registration data over time. Sound= s like an >> RS, if you ask me. >> >> =E2=80=94 Justin >> >> On Sep 15, 2019, at 1:05 AM, Dick Hardt wrote: >> >> Curious why the client management API uses bearer tokens rather than JWT= s >> per RFC 7523 for the client to authenticate. The client management API >> seems more similar to a token endpoint than a resource. >> =E1=90=A7 >> >> On Fri, Sep 13, 2019 at 12:08 PM Justin Richer wrote: >> >>> Travis has this correct =E2=80=94 the =E2=80=9Cregistration access toke= n=E2=80=9D is passed to >>> the client for the express purpose of accessing the client management A= PI, >>> and is not the same as, or entangled with, any access tokens that the >>> client requests through the OAuth process after the registration has >>> occurred. The reasons for this separation are many, but at the core it >>> comes down to the client always acting on its own behalf when it does >>> registration, and acting on behalf of some other party (usually a user) >>> when it=E2=80=99s doing OAuth. Additionally, registration management is= a function >>> of the AS, whereas the protected APIs are a function of the RS =E2=80= =94 note this >>> is a logical separation and there=E2=80=99s nothing stopping AS and RS = functions >>> from being deployed in any number of patterns. >>> >>> A few common questions we got asked when writing this functionality int= o >>> the spec: >>> >>> *Why use an access token at all*? Because it=E2=80=99s a credential for= a >>> specific API issued by the AS and handed to the client in a programmati= c >>> manner. This is exactly what OAuth tokens were made for. >>> >>> *Why not use the client=E2=80=99s credentials*? Because not all clients= are set >>> up to have credentials, plus we=E2=80=99d be spreading the requirement = to support >>> different kinds of client credentials to another endpoint. >>> >>> *Why not issue an authorization code*? Because then the client would >>> need to make yet another round trip, and not all clients are >>> authorization-code-grant clients to begin with. >>> >>> *Why not make a new grant type*? Because then the client would need to >>> make yet another round trip, and we=E2=80=99d have to invent a whole ne= w grant type >>> with a new temporary credential when we could just use that temporary >>> credential directly instead. >>> >>> =E2=80=94 Justin >>> >>> On Sep 13, 2019, at 8:23 AM, Robache Herv=C3=A9 >>> wrote: >>> >>> Thanks Travis >>> >>> I understand that, once the client has retrieved its [client_id] throug= h >>> RFC7591 initial registration, it is then able to ask for an access toke= n >>> that will be used for accessing the RFC7592 entry-points. Am I right? >>> >>> Best regards >>> >>> Herv=C3=A9 >>> >>> *De :* Travis Spencer [mailto:travis.spencer@curity.io >>> ] >>> *Envoy=C3=A9 :* ven. 13 13:30 >>> *=C3=80 :* Robache Herv=C3=A9 >>> *Cc :* oauth@ietf.org >>> *Objet :* Re: [OAUTH-WG] Question regarding RFC 7592 >>> >>> No. The initial access token is issued by the AS when registration is >>> protected (appendix 1.2 in RFC 7591). As stated in section 1.2, the met= hod >>> and means by which this is obtained can vary. The registration access t= oken >>> in RFC 7592 is used to protect the registration management API and allo= w >>> updates to the client after it is registered. You might have one (the >>> registration access token) but not the other (initial access token) whe= n >>> open registration is allowed (appendix 1.1 in RFC 7591). >>> >>> HTH! >>> >>> On Fri, Sep 13, 2019 at 7:37 AM Robache Herv=C3=A9 >>> wrote: >>> >>> Hi >>> >>> RFC 7592 introduces a =C2=AB Registration Access Token =C2=BB. Are this= token and >>> the way to get it similar to what is specified as =E2=80=9CInitial Acce= ss Token=E2=80=9D in >>> RFC 7591/Appendix A ? >>> >>> If so, can the Open Dynamic Client Registration (RFC7591/A.1.1) be >>> extrapolated to RFC7592 as the same way? >>> >>> Thanks in advance for your clarification. >>> >>> Herv=C3=A9 ROBACHE >>> Direction Marketing et D=C3=A9veloppement >>> >>> LIGNE DIRECTE >>> T. +33(0)1 55 23 55 45 >>> herve.robache@stet.eu >>> >>> >>> >>> >>> >>> >>> >>> STET (SIEGE SOCIAL) >>> 100, Esplanade du G=C3=A9n=C3=A9ral de Gaulle >>> C=C5=93ur D=C3=A9fense =E2=80=93 Tour B >>> 92932 La D=C3=A9fense cedex >>> >>> www.stet.eu >>> >>> >>> >>> Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l= 'intention >>> exclusive de ses destinataires et sont confidentiels. >>> Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, >>> merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me e= t d'en avertir >>> imm=C3=A9diatement l'exp=C3=A9diteur. >>> Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n= 'est >>> pas conforme =C3=A0 sa destination, toute diffusion ou toute publicatio= n, totale >>> ou partielle, est interdite. >>> L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de ce mess= age >>> =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3=A9cline tout= e responsabilit=C3=A9 au >>> titre de ce message dans l'hypoth=C3=A8se o=C3=B9 il aurait =C3=A9t=C3= =A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou >>> falsifi=C3=A9. >>> N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'environne= ment. >>> >>> This message and any attachments is intended solely for the intended >>> addressees and is confidential. >>> If you receive this message in error, or are not the intended >>> recipient(s), please delete it and any copies from your systems and >>> immediately notify the sender. >>> Any unauthorized view, use that does not comply with its purpose, >>> dissemination or disclosure, either whole or partial, is prohibited. >>> Since the internet cannot guarantee the integrity of this message which >>> may not be reliable, STET shall not be liable for the message if modifi= ed, >>> changed or falsified. >>> Do not print this message unless it is necessary, please consider the >>> environment. >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l= 'intention >>> exclusive de ses destinataires et sont confidentiels. >>> Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, >>> merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me e= t d'en avertir >>> imm=C3=A9diatement l'exp=C3=A9diteur. >>> Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n= 'est >>> pas conforme =C3=A0 sa destination, toute diffusion ou toute publicatio= n, totale >>> ou partielle, est interdite. >>> L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de ce mess= age >>> =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3=A9cline tout= e responsabilit=C3=A9 au >>> titre de ce message dans l'hypoth=C3=A8se o=C3=B9 il aurait =C3=A9t=C3= =A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou >>> falsifi=C3=A9. >>> N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'environne= ment. >>> >>> This message and any attachments is intended solely for the intended >>> addressees and is confidential. >>> If you receive this message in error, or are not the intended >>> recipient(s), please delete it and any copies from your systems and >>> immediately notify the sender. >>> Any unauthorized view, use that does not comply with its purpose, >>> dissemination or disclosure, either whole or partial, is prohibited. >>> Since the internet cannot guarantee the integrity of this message which >>> may not be reliable, STET shall not be liable for the message if modifi= ed, >>> changed or falsified. >>> Do not print this message unless it is necessary, please consider the >>> environment. >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> > --00000000000022ef870592d498fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think of cloud infrastructure having control plane, and = data plane. Control plane APIs are for managing the things that use the dat= a plane. The data plane is the resource. Not trying to change your mind, ju= st sharing my thinking.

On related efforts, in FastFed, = we are looking at using a JWT to access other control plane APIs.=C2=A0

I agree on first take, that storing an access to= ken is easier than working=C2=A0with a key pair. I should have more context= , which is managing the credential life cycle. What happens if the access t= oken is lost or compromised? Does the app need to be completely re-register= ed? With a jwks-uri, the client can rotate their keys and continue to make = API calls if the private key is lost or compromised.

3D""= =E1=90=A7

On Tue, Sep 17, 2019 at = 8:10 AM Justin Richer <jricher@mit.ed= u> wrote:
I think this is where we disagree about the nature of =E2=80=9Cresource=E2= =80=9D, as I would classify a management API as a resource. Specifically, t= he client=E2=80=99s own records at the AS.=C2=A0

The =E2=80=9CIF=E2=80=9D in your statement is a big if, and one that i= s uncommon even today. Also, I want to note that if the client can=E2=80=99= t "manage an access token=E2=80=9D very well, then it=E2=80=99s going = to have a very hard time being an OAuth client once it=E2=80=99s done regis= tering. In other words, the goal was to take a piece of universal functionality th= at all OAuth clients would be guaranteed to have.=C2=A0

I=E2=80=99ll agree that it=E2=80=99s a bit weird having an access toke= n issued as part of a response, but the alternative was to invent a new flo= w to force a client to go through another round trip to the token endpoint = to get its management token. If you=E2=80=99re already directly giving the client a temporary credential that it can use = at the AS, then just give the client the final token to do the job directly= instead. At least, that was the thinking, and I still agree with that line= of thought today even with its quirks.=C2=A0

=E2=80=94 Justin

On Sep 17, 2019, at 12:40 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

The registration supports the client having a jwks, so if = the client provides jwks, then using them to sign an authentication request= seems easier than trying to manage an access token.=C2=A0

The token endpoint is an API as well. We would agree that it is not a = resource, but a management API. Similarly, I see the client's managemen= t of its registration to not be a resource operation, but a management API.=
3D""=E1=90=A7

On Mon, Sep 16, 2019 at 7:36 PM Justi= n Richer <jricher@m= it.edu> wrote:
I don=E2=80=99t see a reason to use an assertion here. JWT authenticat= ion would require at least a secret if not a key of some type for authentic= ation for all clients, and it was determined that dynamic registration shouldn=E2=80=99t require the clients (even public clients) to support thi= ngs they weren=E2=80=99t already capable of doing. Besides, the management = endpoint isn=E2=80=99t a token endpoint (though I=E2=80=99m curious to hear= why you=E2=80=99d say that) =E2=80=94 it=E2=80=99s an API you can call to = manage a client=E2=80=99s registration data over time. Sounds like an RS, if you ask me.

=E2=80=94 Justin

On Sep 15, 2019, at 1:05 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

Curious why=C2=A0the client management API uses bearer tok= ens rather than JWTs per RFC 7523 for the client to authenticate. The clien= t management API seems more similar to a token endpoint than a resource.
3D""=E1=90=A7

On Fri, Sep 13, 2019 at 12:08 PM Just= in Richer <jricher@= mit.edu> wrote:
Travis has this correct =E2=80=94 the =E2=80=9Cregistration access tok= en=E2=80=9D is passed to the client for the express purpose of accessing th= e client management API, and is not the same as, or entangled with, any acc= ess tokens that the client requests through the OAuth process after the registration has occurred. The reasons for this se= paration are many, but at the core it comes down to the client always actin= g on its own behalf when it does registration, and acting on behalf of some= other party (usually a user) when it=E2=80=99s doing OAuth. Additionally, registration management is a funct= ion of the AS, whereas the protected APIs are a function of the RS =E2=80= =94 note this is a logical separation and there=E2=80=99s nothing stopping = AS and RS functions from being deployed in any number of patterns.=C2=A0

A few common questions we got asked when writing this functionality in= to the spec:

Why use an access token at all? Because it=E2=80=99s a credenti= al for a specific API issued by the AS and handed to the client in a progra= mmatic manner. This is exactly what OAuth tokens were made for.=C2=A0

Why not use the client=E2=80=99s credentials? Because not all c= lients are set up to have credentials, plus we=E2=80=99d be spreading the r= equirement to support different kinds of client credentials to another endp= oint.=C2=A0

Why not issue an authorization code? Because then the client wo= uld need to make yet another round trip, and not all clients are authorizat= ion-code-grant clients to begin with.=C2=A0

Why not make a new grant type? Because then the client would ne= ed to make yet another round trip, and we=E2=80=99d have to invent a whole = new grant type with a new temporary credential when we could just use that = temporary credential directly instead.=C2=A0

=E2=80=94 Justin

On Sep 13, 2019, at 8:23 AM, Robache Herv=C3=A9 <herve.robache@stet.eu> wrot= e:

Thanks Travis
=C2=A0
I understand that, once the client has retrieved its= [client_id] through RFC7591 initial registration, it is then able to ask f= or an access token that will be used for accessing the RFC7592 entry-points. Am I right?<= /span>
=C2=A0
Best regards
=C2=A0
Herv=C3=A9
=C2=A0
De=C2=A0:=C2=A0Travis Spencer [mailto:travis.spencer@curity.= io]=C2=A0
Envoy=C3=A9=C2=A0:=C2= =A0ven. 13 13:30
=C3=80=C2=A0:=C2=A0Robache Herv=C3=A9
Cc=C2=A0:=C2=A0= oauth@ietf.org
Objet=C2=A0:=C2=A0Re: [OAUTH-WG] Question regarding RFC 7592
=C2=A0
No. The initial access token is issued by the AS when registration is prote= cted (appendix 1.2 in RFC 7591). As stated in section 1.2, the method and m= eans by which this is obtained can vary. The registration access token in R= FC 7592 is used to protect the registration management API and allow updates to the client after it is registered. You= might have one (the registration access token) but not the other (initial = access token) when open registration is allowed (appendix 1.1 in RFC 7591).=
=C2=A0
HTH!
=C2=A0
On Fri, Sep 13, 2019 at 7:37 AM Robache Herv=C3=A9 <herve.robache@stet.eu> wrote:
Hi
=C2=A0
RFC 7592 introduces a =C2=AB=C2=A0Registration Access = Token=C2=A0=C2=BB. Are this token and the way to get it similar to what is = specified as =E2=80=9CInitial Access Token=E2=80=9D in RFC 7591/Appendix A = ?
=C2=A0
If so, can the Open Dynamic Client Registration (RFC75= 91/A.1.1) be extrapolated to RFC7592 as the same way?<= /div>
=C2=A0
Thanks in advance for your clarification.
=C2=A0
Herv=C3=A9 ROBACHE
Direction Marketing et D=C3=A9veloppement<= /div>
=C2=A0
LIGNE DIRECTE
T. +33(0)1 55 23= 55 45
=C2=A0
<image001.png>= ;
=C2=A0
=C2=A0

<image002.png>
=C2=A0
STET (SIEGE SOCI= AL)
100, Esplanade d= u G=C3=A9n=C3=A9ral de Gaulle
C=C5=93ur D=C3= =A9fense =E2=80=93 Tour B
92932 La D=C3=A9= fense cedex
=C2=A0=
=C2=A0

Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'= ;intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me = et d'en avertir imm=C3=A9diatement l'exp=C3=A9diteur.
Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'= ;est pas conforme =C3=A0 sa destination, toute diffusion ou toute publicati= on, totale ou partielle, est interdite.
L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de= ce message =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3= =A9cline toute responsabilit=C3=A9 au titre de ce message dans l'hypoth= =C3=A8se o=C3=B9 il aurait =C3=A9t=C3=A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou= falsifi=C3=A9.
N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'envir= onnement.

This message and any attachments is intended solely for the intended addres= sees and is confidential.
If you receive this message in error, or are not the intended recipient(s),= please delete it and any copies from your systems and immediately notify t= he sender.
Any unauthorized view, use that does not comply with its purpose, dissemina= tion or disclosure, either whole or partial, is prohibited.
Since the internet cannot guarantee the integrity of this message which may= not be reliable, STET shall not be liable for the message if modified, cha= nged or falsified.
Do not print this message unless it is necessary, please consider the envir= onment.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailma= n/listinfo/oauth


Ce message et toutes les pi=C3=A8ces jointes sont =C3=A9tablis =C3=A0 l'= ;intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destin=C3= =A9, merci de le d=C3=A9truire ainsi que toute copie de votre syst=C3=A8me = et d'en avertir imm=C3=A9diatement l'exp=C3=A9diteur.
Toute lecture non autoris=C3=A9e, toute utilisation de ce message qui n'= ;est pas conforme =C3=A0 sa destination, toute diffusion ou toute publicati= on, totale ou partielle, est interdite.
L'Internet ne permettant pas d'assurer l'int=C3=A9grit=C3=A9 de= ce message =C3=A9lectronique susceptible d'alt=C3=A9ration, STET d=C3= =A9cline toute responsabilit=C3=A9 au titre de ce message dans l'hypoth= =C3=A8se o=C3=B9 il aurait =C3=A9t=C3=A9 modifi=C3=A9, d=C3=A9form=C3=A9 ou= falsifi=C3=A9.
N'imprimez ce message que si n=C3=A9cessaire, pensez =C3=A0 l'envir= onnement.

This message and any attachments is intended solely for the intended addres= sees and is confidential.
If you receive this message in error, or are not the intended recipient(s),= please delete it and any copies from your systems and immediately notify t= he sender.
Any unauthorized view, use that does not comply with its purpose, dissemina= tion or disclosure, either whole or partial, is prohibited.
Since the internet cannot guarantee the integrity of this message which may= not be reliable, STET shall not be liable for the message if modified, cha= nged or falsified.
Do not print this message unless it is necessary, please consider the envir= onment.
______________________________________= _________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--00000000000022ef870592d498fd-- From nobody Fri Sep 20 05:28:27 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCB5120169; Fri, 20 Sep 2019 05:28:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156898250596.30287.14524104153595179086@ietfa.amsl.com> Date: Fri, 20 Sep 2019 05:28:26 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2019 12:28:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : JWT Response for OAuth Token Introspection Authors : Torsten Lodderstedt Vladimir Dzhuvinov Filename : draft-ietf-oauth-jwt-introspection-response-08.txt Pages : 18 Date : 2019-09-20 Abstract: This specification proposes an additional JSON Web Token (JWT) secured response for OAuth 2.0 Token Introspection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 20 06:01:24 2019 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 DAD151201AA; Fri, 20 Sep 2019 06:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 T1QhP6gXmjfv; Fri, 20 Sep 2019 06:01:18 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) (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 1CCB712003F; Fri, 20 Sep 2019 06:01:17 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from ) id 1iBIXC-0002iC-IP; Fri, 20 Sep 2019 15:01:14 +0200 From: Torsten Lodderstedt Message-Id: <75A2B3D1-6091-436B-85ED-71A6BC8266CD@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_806FA562-9592-4592-94D1-B74B12769C91"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 20 Sep 2019 15:01:13 +0200 In-Reply-To: <156746426740.13074.1850379334333790613.idtracker@ietfa.amsl.com> Cc: The IESG , oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org, oauth-chairs@ietf.org, Vladimir Dzhuvinov To: Benjamin Kaduk References: <156746426740.13074.1850379334333790613.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and COMMENT) 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: Fri, 20 Sep 2019 13:01:23 -0000 --Apple-Mail=_806FA562-9592-4592-94D1-B74B12769C91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ben,=20 thanks a lot for your review comments. =20 We just published a new revision that is intended to resolve all your = DISCUSS and COMMENT. = https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08= > On 3. Sep 2019, at 00:44, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-oauth-jwt-introspection-response-07: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respon= se/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Per the ongoing discussion on the WG list, it's unclear that we can > retain the behaviors we describe and still comply with the = requirements > of RFC 7519 requirements for being a JWT (e.g., regarding "jti", = "iat", > etc.). That is, in the present formulation, there are two "token"s > involved -- the input that is being introspected, and the "token" that > is the introspection response. We are claiming that certain fields = are > describing the input token, when they are defined to be statements = about > the current (response) token. > Relaxing our statements to say that we merely use JWS as opposed to = JWT > may be a workaround, though I have thought about it hard enough to = have > an opinion on whether it is the best workaround. I thought about this as well but I think it wouldn=E2=80=99t solve the = problem entirely. As you said, there are two token involved and we need = to make the difference clear.=20 We enhanced the wording of the draft to make the difference between the = introspected token (that could be a JWT) and the introspection response = in JWT format. I hope that helps. Re the concrete issue: In my opinion, the use case brought up requires = the AS to attest the time when the introspection endpoint response was = created. It=E2=80=99s about non-repudiation for attesting that the = access token was active at that time.=20 We extended the text in section 5 accordingly.=20 =20 >=20 > I also think we need more clarity about the use of dynamic client > registration by a resource server as outlined in Section 4 (where it's > mentioned as "with a resource server posing as the client", without > reference to RFC 7591. As far as I can tell this document/section is > introducing this use of dynamic client registration by an RS for the > first time, so we cannot easily just refer to some other document. I understand. It=E2=80=99s being used in the wild but has never been = mentioned in an OAuth draft.=20 We added a section on trust management between AS and RS including = references to dynamic client registration.=20 = https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08= #section-3 > Specifically, are there any fields that MUST NOT be supplied? Is a > human-readable client_name useful? How does the supplied client_uri > need to relate to any existing AS representation of a resource in > audience, scope, etc. (e.g., for the "resource" request parameter from > draft-ietf-oauth-resource-indicators)? = https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08= #section-3 lists all fields we consider reasonable.=20 >=20 > Is this usage considered to be a "new use of JWTs"? If so, it seems > that we should follow the recommendation of draft-ietf-oauth-jwt-bcp = and > use explicit typing. We added a media type "application/token-introspection+jwt=E2=80=9D and = language describing it's use. >=20 > I think there are some missing links in the document between a RS > registring client policy and the resulting AS enforcement of = encryption > of introspection reponses. =20 > I think the intent is roughly that the > policy will be applied based on the audience of the token being > presented for introspection (as opposed to the identity of the > RS-as-client making the introspection request), but we don't seem to > explicitly say that. =20 We added text about this to Sections 3 & 5. > Also, we'd need to say something about the > interaction of multiple RSs' policy when a given token has multiple > valid audiences. There is a very brief discussion in Section 6.5, but > it seems to be more of a description of what is possible than = mandating > particular forms of enforcement. Section 3 now states The authorization server MUST be able to determine whether an RS is the audience for a particular access token and what data it is entitled to receive, otherwise the RS is not authorized to obtain data for the access token. The AS has the discretion how to fulfil this requirement. The AS could, for example, maintain a mapping between scopes values and resource servers. Section 5 now states If the access token is =E2=80=9C..." is not intended to be consumed by the calling resource server (audience), the authorization server MUST set the value of the response claim "active" to "false". Otherwise, this claim is set to "true=E2=80=9D. If possible, the AS MUST narrow down the "scope" value to the scopes relevant to the particular RS. Does this work for you? >=20 > I think we should discuss whether we want some statement from the = OpenID > Foundation or related bodies before we register claims that point to > their documents with the IESG listed as change controller. After a discussion with the designated expert (Just Richer), we decided = to remove the registration since the claims we want to include are = already registered in the JWT Claims Registry. That=E2=80=99s sufficient = for the use cases of this draft.=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > idnits notes that RFC 5646 is mentioned but not present in the > references section. Gone since we removed the OIDC claims registration.=20 >=20 > Section 1 >=20 > We probably need to move the 7519 reference up here to where JWT is > first used. >=20 > OAuth 2.0 Token Introspection [RFC7662] specifies a method for a > protected resource to query an OAuth 2.0 authorization server to > determine the state of an access token and obtain data associated > with the access token. This allows deployments to implement > identifier-based access tokens in an interoperable way. Done >=20 > Does "identifier-based access tokens" mean "tokens that are opaque = keys > to a (central) database lookup" or "access tokens that convey user > identity information" (or something else)? We may want to tweak the > wording. Changed to "opaque tokens" >=20 > Section 3 >=20 > Can we double-check the base64 form of the response in this example? = I > am seeing output that backslash-escapes the '/' characters in URLs, > which I did not think was needed in this context. > I also see an "extension_field" claim in the base64 but not the = decoded > form of the example, and "given_name"/"family_name"/"birthdate" in the > decoded example vs. "username" in the base64 version. Re-worked the example >=20 > Note: If the resource server policy requires a signed and encrypted > response and the authorization server receives an unauthenticated > request containing an Accept header with content type other than > "application/jwt", it MUST refuse to serve the request and return an > HTTP status code 400. This is done to prevent downgrading attacks = to > obtain token data intended for release to legitimate recipients only > (see Section 6.2). >=20 > I'd suggest a forward-reference to section 4 for how the AS will know > the RS's policy. Although, given that "unauthenticated request" is > included in the preconditions, perhaps we do not need the conditional = on > "resource server policy" at all? Since we added section 3, the prerequisites should be clearer now.=20 >=20 > Section 4 >=20 > The authorization server determines what algorithm to employ to > secure the JWT for a particular introspection response. This > decision can be based on registered metadata parameters for the > resource server, supplied via dynamic client registration with the > resource server posing as the client, as defined by this draft. >=20 > nit: I suggest s/posing as the/acting as a/, and s/by this = draft/below/, > since it's right here in this section. Done >=20 > introspection_encrypted_response_alg OPTIONAL. JWE [RFC7516] > algorithm ("alg" value) as defined in JWA [RFC7518] for > encrypting introspection responses. If this is specified, > the response will be encrypted using JWE and the configured > algorithm. The default, if omitted, is that no encryption = is >=20 > This text is slightly confusing with respect to the interaction = between > the introspection_encrypted_response_alg "alg" value and the > introspection_encrypted_response_enc "enc" value. My understanding is > that the "enc" is a symmetric bulk encryption scheme that directly > protects the payload, whereas the "alg" is a key-wrap or key-agreement > mechanism used to establish the key used as input for the "enc" = method. > So, while "algorithm ("alg value") for encrypting introspection > responses" and "the response will be encrypted using the confugred > ["algo"] algorithm" are technically true, they're also a bit = misleading, > since this is not what encrypts the "bulk" of the response. Using the > term from RFC 7158, "key management algorithm", would probably = alleviate > this confusion. Changed the text to consistently use =E2=80=9Ccontent key encryption" = and "content encryption=E2=80=9D=20 >=20 > Resource servers may register their public encryption keys using the > "jwks_uri" or "jwks" metadata parameters. >=20 > Should we cite 7591 for these (or, really, the whole section)? We = don't > currently mention it until the IANA considerations. It=E2=80=99s mentioned in Section 3 now. >=20 > Section 5 >=20 > Is it worth a note that resource servers will fetch these metadata and > use them as input to their dynamic registrations in the previous = section > (i.e., picking from the list of supported algorithms)? >=20 > introspection_encryption_alg_values_supported OPTIONAL. JSON array > containing a list of the JWE [RFC7516] encryption algorithms > ("alg" values) as defined in JWA [RFC7518] supported by the > introspection endpoint to encrypt the response. >=20 > Similarly to the above, some refined text about "key management > algorithm" used to encrypt the response, would probably be helpful. Changed the text to consistently use =E2=80=9Ccontent key encryption" = and "content encryption=E2=80=9D=20 >=20 > Section 6 >=20 > There seem to be notable privacy considerations about quite a few of = the > claims registered in Section 8.3. >=20 > Section 6.1 >=20 > I'm surprised to not see discussion of explicit typing (and, IIUC, how > it's not a reliable mitigation) here. Added this discussion to (now) Section 8.1 Any relying party processing the "typ" JWT header element should detect the attack since token introspection responses in JWT format set this header to the value "token-introspection+jwt". Unfortunately, this is not a well established practice yet. >=20 > JWT introspection responses and OpenID Connect ID Tokens are > syntactically similar. An attacker could therefore attempt to > impersonate an end-user at a OpenID Connect relying party by passing > the JWT as an ID token. >=20 > nit: "response JWT" or "JWT response" >=20 > Such an attack can be prevented like any other token substitution > attack. The authorization server MUST include the claims "iss" and > "aud" in each JWT introspection response, with the "iss" value set = to > the authorization server's issuer URL and the "aud" value set to the > resource server's identifier. [...] >=20 > Related to the Discuss point, how does this relate to the dynamic = client > registration parameters? The =E2=80=9Caud" value depends on the way the AS identifies RSs (see = section 3). Dynamic client registration is just one option for client = management, I assume the AS would use the client_id in that case.=20 >=20 > [OpenID.Core]. Relying parties SHOULD also use and check the = "nonce" > parameter and claim to prevent token and code replay. >=20 > Is this SHOULD just referring to the behavior already described in > OpenID.Core (and only applicable to OIDC implementations as opposed to > JWT-instrospection consumers)? If so, maybe descriptive language is > more appropriate, like "Relying parties are also expected to use and > check [...]=E2=80=9D. Modified the text according to your suggestion. =20 >=20 > Resource servers utilizing JWTs to represent self-contained access > tokens could be susceptible to replay attacks. Resource servers > should therefore apply proper counter measures against replay as > described in [I-D.ietf-oauth-security-topics], section 2.2. >=20 > I'm not sure what part of this is specific to the introspection case. > Is it supposed to be tied to the risk that JWT-instrospection produces = a > new route for the generation of JWT objects that could be confused for > self-contained access tokens? yes. > nit: "countermeasures" is valid as a single word. > nit: it looks like it's section 3.2, now. >=20 > Section 6.2 >=20 > Please cite RFC 7525 as BCP 195 as well as RFC 7525 (e.g., "per BCP = 195 > [RFC7525]=E2=80=9D). done=20 >=20 > To prevent introspection of leaked tokens and to present an > additional security layer against token guessing attacks the > authorization server may require all requests to the token > introspection endpoint to be authenticated. As an alternative or as > an addition to the authentication, the intended recipients may be = set > up for encrypted responses. >=20 > Do we want to make either of these "may"s into normative = recommendations > (or make a recommendation for prevention of introspection data leakage > even in the face of token leakage, which can be satisfied by either > mechanism)? Changed it to MAY(s) >=20 > Also, we could say more about how configuring encryption for intended > recipients protects against unencrypted replies to unintended > recipients... >=20 > In the latter case, confidentiality is ensured by the fact that only > the legitimate recipient is able to decrypt the response. An > attacker could try to circumvent this measure by requesting a plain > JSON response, using an Accept header with the content type set to, > for example, "application/json" instead of "application/jwt". To > prevent this attack the authorization server MUST NOT serve requests > with content type other than "application/jwt" if the resource = server > is set up to receive encrypted responses (see also Section 3). >=20 > ....such as by saying that the introspection response will only be = made > available to RSes that are intended recipients of (in the audience = of?) > the access token being introspected. We now state this in Sections 3 & 5. >=20 > Section 6.3 >=20 > Authorization servers with a policy that requires token data to be > kept confidential from OAuth clients must require all requests to = the > token introspection endpoint to be authenticated. As an alternative > or as an addition to the authentication, the intended recipients may > be set up for encrypted responses. >=20 > [this also seems to be assuming a link not stated between RS policy = and > AS enforcement, but it seems unlikely that a fix would need to touch > this text] It=E2=80=99s now in Section 3. >=20 > Section 8.1.1 >=20 > nit: using nested lists might make this more readable. >=20 > o Client Metadata Description: String value specifying the desired > introspection response encryption algorithm (alg value). >=20 > [same bit about "key management algorithm=E2=80=9D] Same changes as above >=20 > Section 8.2.1 >=20 > o Metadata Description: JSON array containing a list of algorithms > supported by the authorization server for introspection response > encryption (alg value). >=20 > [and here] >=20 > Section 8.3 >=20 > I think we should make some mention earlier in the document > (Introduction?) that we also register some common claim values that = are > in use in the wild (or whatever text you feel is appropriate to = describe > the claims in question). We added a paragraph in Section 5 about use of OpenID Connect claims in = introspection responses.=20 >=20 > The nested lists would be great here as well. >=20 > Is there any expectation that some combination of "given_name", > "middle_name", and "family_name" will produce identical content to the > full "name" claim? >=20 > o Name: "preferred_username" >=20 > o Description: Shorthand name by which the End-User wishes to be > referred to at the RP, such as janedoe or j.doe. This value MAY > be any valid JSON string including special characters such as @, > /, or whitespace. >=20 > It seems like there may be some security considerations about = sanitziing > this field before using it in an application's logic. >=20 > o Name: "profile" >=20 > o Description:URL of the End-User's profile page. The contents of > this Web page SHOULD be about the End-User. >=20 > It's slightly surpising to see this claimed for the end-user's profile > when it might equally apply to a protocol profile or variant in use. > But I assume this is already deployed, so there's no real point in > objecting to its registration... >=20 > o Name: "birthdate" >=20 > o Description:Time the End-User's information was last updated. = Its > value is a JSON number representing the number of seconds from > 1970-01-01T0:0:0Z as measured in UTC until the date/time. >=20 > This seems potentially confusable with the user's day/year of birth. > (Also, are leap seconds excluded?) >=20 > o Name: "zoneinfo" >=20 > o Description: String from zoneinfo [zoneinfo] time zone database > representing the End-User's time zone. For example, Europe/Paris > or America/Los_Angeles. >=20 > We seem to be missing the actual reference entry for [zoneinfo]. Thanks a lot again for your review and I hope we have resolved all of = your DISCUSS and COMMENT with the new revision.=20 best regards, Torsten.=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_806FA562-9592-4592-94D1-B74B12769C91 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA5MjAxMzAxMTRaMC8GCSqGSIb3DQEJBDEiBCBZONBT0K2hXA/nV4CUx2iMSa6VI1vT6MPc fWnqEXx40jCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBALUqJEbGRJ2+rHiUM0WLj+SNSszez2t/CM2TQwdFZ87TgErAaAv/AcHo3+XX 6kVTw1unuB7H4u0iOCK84LMNUqQ78OMP4kdC47MsxxWVcJGXr22aUJQttNrosraepQkVImpk1pdU y62rKHSdishXCP34hqCn5jvTC2DWCEgYxhxGAELhVCMusINJpNYvPZlcJ8AEuBkZp47zTcNC2VON 5BNG9rjtJX8Meqvy9uMumzcy89ZrAFIFQaU0QxtC9M83L0gzpK4Dc34AY077zgjTwUDSS3Q2byEa LlIcFT/SBG9QnzzZE8lun7ac0o10Wy4Dzugjeqzvght6j4nm6cdZt90AAAAAAAA= --Apple-Mail=_806FA562-9592-4592-94D1-B74B12769C91-- From nobody Fri Sep 20 06:03:50 2019 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 4575A1201A3; Fri, 20 Sep 2019 06:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 yVtu-z3-dU8b; Fri, 20 Sep 2019 06:03:40 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) (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 04E1812003F; Fri, 20 Sep 2019 06:03:40 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from ) id 1iBIZU-00048M-LJ; Fri, 20 Sep 2019 15:03:36 +0200 From: Torsten Lodderstedt Message-Id: <1B033736-D3F9-48DC-8973-B2069F6749F2@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_5085F3FF-7005-45D5-B1F8-24FAEB03E73A"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 20 Sep 2019 15:03:35 +0200 In-Reply-To: <156761217998.22726.10487913212091468494.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-oauth-jwt-introspection-response@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, oauth@ietf.org To: Alissa Cooper References: <156761217998.22726.10487913212091468494.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Alissa Cooper's No Objection on draft-ietf-oauth-jwt-introspection-response-07: (with COMMENT) 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: Fri, 20 Sep 2019 13:03:43 -0000 --Apple-Mail=_5085F3FF-7005-45D5-B1F8-24FAEB03E73A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alissa, Thanks for your review.=20 We decided to remove the registration requests for OpenID Connect claims = from the draft in the latest revision.=20 = https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08= Those claims are already registered in the JWT Claims registry, which is = sufficient for the use cases in our draft.=20 best regards,=20 Torsten.=20 > On 4. Sep 2019, at 17:49, Alissa Cooper via Datatracker = wrote: >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-oauth-jwt-introspection-response-07: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respon= se/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I support Benjamin's DISCUSS point about the IESG being listed as the = change > controller for the registry entries. Overall I'd like to understand = better the > relationship between these registry entries and future updates to = OpenID > Connect (i.e., if the claims in the OpenID spec change, will this = registry > automatically need to change as well?). >=20 > I also support Adam's DISCUSS. How are claims like preferred_username = currently > used for the described use case of verifying person data to create = certificates? >=20 > If the linkage with the OpenID Connect 1.0 claims remains in the = document, I > think it would be good to add a note in Section 1.1 or a new Section = 1.2 to > indicate that the document uses terminology as defined in that spec = (e.g., > "End-User," "Relying Party," etc.). >=20 >=20 --Apple-Mail=_5085F3FF-7005-45D5-B1F8-24FAEB03E73A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA5MjAxMzAzMzZaMC8GCSqGSIb3DQEJBDEiBCD98Vr6NgAjuLphZTnxk8RJF6YsKyvVLauS dIUG5tpTezCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAIRW646dxXcERi0DXmZgOEHmR6MiJa/+uy1a8vf6IWHmNUjNxMfZSy2X2vND 8QmQqa5c38wX5hIvtLMByCT3us7GmnuYAytEsUOmXUD/J3DYAlrrBsj7w6briVh5Zj4UbzcDVEtP bAfOF0trHcYUf+tPY9OPtbYmHipozc41Q+UQAMSWW5RgUVkm9Luoaxm0IBH/sM4vkeCF74VnGrD1 umHefceD/EmMlwsX1bqxWjR8cx5HWcguan+6svTWEVb1umR2X/IBT3h6yUJ8VsU4JEnx8iQy+pTK ZJrCXLFgSQCGvUugj4O8LsV5mgghLHYdcHZ2FbYd6FBijps+Ctc81g4AAAAAAAA= --Apple-Mail=_5085F3FF-7005-45D5-B1F8-24FAEB03E73A-- From nobody Fri Sep 20 06:12:16 2019 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 DE83D1200DB; Fri, 20 Sep 2019 06:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 M44A4C8rNyqu; Fri, 20 Sep 2019 06:12:12 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) (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 DF1B612003F; Fri, 20 Sep 2019 06:12:11 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from ) id 1iBIhl-0007ED-01; Fri, 20 Sep 2019 15:12:09 +0200 From: Torsten Lodderstedt Message-Id: <85F5FCA2-A540-468E-B8E6-3080172C2B55@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_60FE12CF-53B9-4757-9C2B-E9F81C81A29A"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 20 Sep 2019 15:12:08 +0200 In-Reply-To: <156758306119.22796.7625113709709674898.idtracker@ietfa.amsl.com> Cc: The IESG , oauth@ietf.org, draft-ietf-oauth-jwt-introspection-response@ietf.org, oauth-chairs@ietf.org To: Adam Roach References: <156758306119.22796.7625113709709674898.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and COMMENT) 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: Fri, 20 Sep 2019 13:12:14 -0000 --Apple-Mail=_60FE12CF-53B9-4757-9C2B-E9F81C81A29A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Adam,=20 thank your for your review.=20 We just published = https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08= that hopefully resolves your DISCUSS and COMMENT. > On 4. Sep 2019, at 09:44, Adam Roach via Datatracker = wrote: >=20 > Adam Roach has entered the following ballot position for > draft-ietf-oauth-jwt-introspection-response-07: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respon= se/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks for the work the authors and other contributors have > put into creating this document. >=20 > I have a privacy concern that I think warrants text in the document. >=20 > Section 8.3.1 introduces a significant amount of = personally-identifiable > information. While I understand that this is needed for the use case > cited in the introduction (issuing certificated for electronic = signatures), > I think the document needs some treatment of the sensitivity of this > information, the basis that the server uses to decide whether to = include > it, and how consent to disclose it might be obtained from the user. We added text about the trust management between AS and RS and how an AS = determines what data a RS is allowed to receive (Sections 3 and 5).=20 We also re-reworked the Privacy Considerations section and added text = about prerequisites for personal data transfer between AS and RS and = security requirements in this context.=20 >=20 > I'm putting this in as a DISCUSS, because I really do think this is > a showstopper for publication. I am quite aware, however, that I might > simply be missing some important aspect of the solution that makes my > concerns moot. Please point me in the right direction if this is the > case, and I'll be happy to clear. We had some assumptions (just) in mind that we now added to the = document. I hope this clears your DISCUSS. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > =C2=A73: >=20 >> The example response contains the following JSON document: >>=20 >> { >> "sub": "Z5O3upPC88QrAjx00dis", >> "aud": "https://protected.example.net/resource", >> "scope": "read write dolphin", >> "iss": "https://server.example.com/", >> "active": true, >> "exp": 1419356238, >> "iat": 1419350238, >> "client_id": "l238j323ds-23ij4", >> "given_name": "John", >> "family_name":"Doe", >> "birthdate":"1982-02-01" >> } >=20 > The example response actually contains the following JSON document: >=20 > { > "sub":"Z5O3upPC88QrAjx00dis", > "aud":"https:\/\/protected.example.net\/resource", > "extension_field":"twenty-seven", > "scope":"read write dolphin", > "iss":"https:\/\/server.example.com\/", > "active":true, > "exp":1419356238, > "iat":1419350238, > "client_id":"l238j323ds-23ij4", > "username":"jdoe" > } >=20 > Note the presence of "extension_field" and "username" fields, and the > absence of "given_name", "family_name", and "birthdate" fields. = There's > also a bunch of unnecessarily escaped "/" characters in the document > in the JWT, but not the expanded example; and while these are = semantically > insignificant, the discrepancy seems gratuitous. >=20 > It is probably worthwhile updating either the JWT or the expanded > example so that they match. We re-did the whole example.=20 best regards. Torsten.=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_60FE12CF-53B9-4757-9C2B-E9F81C81A29A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA5MjAxMzEyMDhaMC8GCSqGSIb3DQEJBDEiBCCCaD+eOoLvAzZd3QM9MxSXR9i4RqaPl1Dh dLy3R5VXsDCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBALzwuujzQhko4tn2QQM2Fsyuusxqqy6+mUU59GYPEt/hhaZza7C7lNA8QKBu DU7zRaa1QQJXqq/5LsBRYweKueEnSFtEYxqzZg+134oKJXJ9UqCzmwLNFXF4KiQr9GxKrjuwLdcU u8VfUsAo/OLQyAQZrgTNSqsA4kqluUzfrpZLPhn7ooI7aWN4fITLqFRKoZceBlaGfKuUr3ySjBm2 PyW5G0kbAtjgJYXyg4J+DW2izC3e0NgqqCSgAE3ZdaZcuuO9uzyy6CbztGQjydkvuy7985YIg6ZX VfUKcL16F8Zn1w6yv2jirbK14p8WNzgaznZPULaaTGVUyp+eboMlACAAAAAAAAA= --Apple-Mail=_60FE12CF-53B9-4757-9C2B-E9F81C81A29A-- From nobody Fri Sep 20 06:19:08 2019 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 3B090120024 for ; Fri, 20 Sep 2019 06:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 hF5wpz3f8HTA for ; Fri, 20 Sep 2019 06:19:03 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.98]) (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 D1CF51200DB for ; Fri, 20 Sep 2019 06:19:02 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from ) id 1iBIoN-0006lj-Cy; Fri, 20 Sep 2019 15:18:59 +0200 From: Torsten Lodderstedt Message-Id: <59657B9C-0B7F-4A33-AE5B-FF522E754E21@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_2FD6032A-9815-48B2-822E-B38547662C1C"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 20 Sep 2019 15:18:58 +0200 In-Reply-To: <9468283E-8B97-4DAF-8493-895B475F6BC9@lodderstedt.net> Cc: "oauth@ietf.org" To: "Schaar, R.M. (Remco) - Logius" References: <38503cd44d9e455bad4432d9ba5e82e8@SV1601507.frd.shsdir.nl> <308A4847-6390-4D17-BE52-B604E2428391@lodderstedt.net> <10f13f75c100454aa8092961673541b2@SV1601499.frd.shsdir.nl> <040dcf9971fd4c618e94b957461d14f2@SV1601507.frd.shsdir.nl> <9468283E-8B97-4DAF-8493-895B475F6BC9@lodderstedt.net> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 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: Fri, 20 Sep 2019 13:19:06 -0000 --Apple-Mail=_2FD6032A-9815-48B2-822E-B38547662C1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Remco,=20 we just published = https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08= .=20 We added text to make the difference between the introspected access = token and the token introspection response in JWT format clear.=20 Wed didn=E2=80=99t find a compelling reason for having two =E2=80=9Ciat" = claims (for the introspected access token as well as the token = introspection response) since in our experience (and the experience of = other experts we talked to) =E2=80=9Ciat" is almost exclusively used for = logging/auditing & non-repudiation whereas =E2=80=9Cexp=E2=80=9D is used = for lifetime control.=20 We therefore added text stating that the =E2=80=9Ciat=E2=80=9D in a = token introspection response in JWT format always indicates the time = when the introspection response was created by the AS.=20 --- If the AS adds the following claims to the token introspection response their meaning is defined as follows: iat The "iat" claim indicates when the introspection response was issued by the AS. exp The "exp" claim indicates when the access token passed in the introspection request will expire. jti The "jti" claim is a unique identifier for the access token passed in the introspection request. This identifier MUST be stable for all introspection calls for a given access token. --- I hope this resolves your issue regarding non-repudiation.=20 best regards, Torsten.=20 > On 4. Sep 2019, at 11:21, Torsten Lodderstedt = wrote: >=20 > Hi Remco, >=20 >> On 31. Aug 2019, at 21:27, Schaar, R.M. (Remco) - Logius = wrote: >>=20 >> Hello Torsten, >>=20 >> (my apologies for making a typo previously) >=20 > Thanks :-) >=20 >>=20 >> Time of introspection is critical if you want to use the signed = introspection >> response for later accountability or audit purposes. For example, a = Client >> obtains an access token A at time t. Now a resource server receives A = at time >> t+1, calls introspection and receives a response containing = active=3Dtrue. At >> t+2 the acccess token is revoked. At time t+3 the resource server = makes a new >> introspection request, now receives a response containing = active=3Dfalse. The >> only difference would be the value of the active parameter. Without = the time >> of introspection nor a unique id covered by the signature, one cannot = make a >> conclusive distinction between subsequent responses if revocation may = be in >> play. >=20 > That=E2=80=99s a good point. =20 >=20 >>=20 >> The draft specifies=20 >> [...] to return responses as JWTs. >> This could either mean "the response is returned in JWT format" or = "the >> response contains a JWT representation of the inspected token=E2=80=9D.= >=20 > I'm meanwhile leaning towards "the response is returned in JWT = format=E2=80=9D. >=20 >> Not having >> clear, separate parameters to distinguish between the time and id of = the >> token and the time and id of the response results in double meaning. = As a >> consequence, it is either having the risk of replay of an access = token or >> replay of an introspection response instead of neither. >=20 > I=E2=80=99m not sure how an attacker could replay an introspection = response given it is tighted to a certain endpoint via the iss claim.=20 >=20 > I agree the RS lacks a way to proof when it was provided with the = access token data by the AS.=20 >=20 > The problem in my opinion is the overlay between the original access = token data (e.g. when was it issued by the AS) and the data belonging to = the representation in the introspection response (when was the response = created). Conceptually, this means we require two separat =E2=80=9Ciat" = (alike) claims to distinguish both aspects.=20 >=20 > I could image two ways to handle this: > - add another iat claim, e.g. =E2=80=9Ctir_iat", to the JWT > - add another =E2=80=9Ciat" claim to the JWS header containing the = instant when the token introspection response was created >=20 > What do you think? >=20 > best regards, > Torsten.=20 >=20 >>=20 >> Kind regards, >> Remco schaar >>=20 >> -----Oorspronkelijk bericht----- >> Van: Torsten Lodderstedt =20 >> Verzonden: woensdag 28 augustus 2019 11:14 >> Aan: Schaar, R.M. (Remco) - Logius >> CC: oauth@ietf.org >> Onderwerp: Re: [OAUTH-WG] Question regarding = draft-ietf-oauth-jwt-introspection-response-05 >>=20 >> Hi Rhemco, >>=20 >>> On 26. Aug 2019, at 09:42, Schaar, R.M. (Remco) - Logius = wrote: >>>=20 >>> Hello Thorsten, >>>=20 >>> Thank you for your response. I have a few more questions/comments as >>> follow-up... >>>=20 >>> You state that RFC7519 and RFC7662 "just" define different = representations >>> for token data. If the draft RFC would refer to RFC 7515 (JWS), I = would >>> agree. However, RFC7519 (JWT) explicitly adds semantics to some = specific >>> parameters (e.g. aud, jti and iat). RFC7662 has different semantics = for >>> the several of the same parameters. >>> For instance the 'iat', is the moment of issuance of the JWT in = RFC7519. In >>> RFC7662 that is the "when this token was originally issued". This = time will >>> vary in use cases without immediate introspection of an access = token. >>=20 >> I read the text differently. In my interpretation =E2=80=9Cwhen the = token was originally issued=E2=80=9D stated from the perspective of the = introspection endpoint refers exactly to the same instant as =E2=80=9Cthe = time at which the JWT was >> issued=E2=80=9D. >>=20 >>>=20 >>> For the use case of the resource server relying on verifiable data, = as >>> described in the introduction of the draft RFC, the time of the = introspection >>> is critical. >>=20 >> Why is this time critical? >>=20 >>> In particular when combined with revocation, the time of >>> introspection and the 'active' status can differ between two = subsequent calls >>> for introspection. >>=20 >> The status at token introspection request time is indeed critical. = RFC 7662 gives a good indication how this value should be calculated. >>=20 >> =E2=80=9C=E2=80=A6 a "true" >> value return for the "active" property will generally indicate >> that a given token has been issued by this authorization server, >> has not been revoked by the resource owner, and is within its >> given time window of validity (e.g., after its issuance time and >> before its expiration time)."=20 >>=20 >> So it represents the results of the issuer check, the revocation = check and the validity check in one boolean value.=20 >>=20 >>>=20 >>> If the draft RFC just produces a JWT representation of the access = token, >>> including 'active' would not make sense as the JWT will expire = without >>> updating it to false. Leaving 'active' out would make it = incompatible with >>> RFC7662 introspection responses. >>=20 >> =E2=80=9Cactive=E2=80=9D is not part of the JWT representation I = referred to. The AS needs to determine the active value for every token = introspection request.=20 >>=20 >> If the RS would consume JWTs, it would determine the =E2=80=9Cactive=E2= =80=9D value itself by inspecting the iss claim and check against its AS = whitelist, check the signature and the iat & exp values. Determining the = revocation status would require an information exchange with the AS of = some sort.=20 >>=20 >>> Similar, not including a unique 'jti' per introspection response = would make >>> the resource server vulnerable to replay attacks. >>=20 >> To the contrary, including a different =E2=80=9Cjit" with every token = introspection response would make the RS vulnerable to replay of one = time access token since it remove the possibility for the RS to identity = a certain access token.=20 >>=20 >>> Or the resource server >>> would mistakenly refer to non-unique tokens, making the responses = unsuitable >>> for accountability and audit purposes. >>>=20 >>>=20 >>> As to why someone would want to distinguish a JWT access token from = an >>> introspection response: several use cases come to mind. >>>=20 >>> First of all, even if one is using standalone interpretable JWT = access tokens, >>> one may want to combine that with revocation checking using = introspection. The >>> interpretation and meaning of the JWT and the introspection response = than do >>> differ and matter. >>=20 >> As I described above, I don=E2=80=99t see any difference.=20 >>=20 >>>=20 >>> Another use case would be a mixed ecosystem with resource servers = relying on >>> introspection while others do parse JWT access tokens. A single, = uniform >>> implementation for the AS would than mix both as well. >>=20 >> See above - I don=E2=80=99t see any issue.=20 >>=20 >>>=20 >>> A last use case could be exchanging access tokens with a subset of = the full >>> set of applicable parameters, to reduce the size of access tokens. = Additional >>> information can be exchanged via introspection, resulting in mixed = JWT access >>> tokens and introspection as well. >>=20 >> That=E2=80=99s all possible within the current text.=20 >>=20 >> kind regards, >> Torsten=20 >>=20 >>>=20 >>> Kind regards, >>> Remco Schaar >>>=20 >>> -----Oorspronkelijk bericht----- >>> Van: Torsten Lodderstedt =20 >>> Verzonden: zaterdag 17 augustus 2019 14:00 >>> Aan: Schaar, R.M. (Remco) - Logius >>> CC: oauth@ietf.org >>> Onderwerp: Re: [OAUTH-WG] Question regarding = draft-ietf-oauth-jwt-introspection-response-05 >>>=20 >>> Hi Remco, >>>=20 >>>> On 6. Aug 2019, at 16:01, Schaar, R.M. (Remco) - Logius = wrote: >>>>=20 >>>> Hello, >>>=20 >>> [...] >>> RFC 7519 and RFC 7662 =E2=80=9Cjust=E2=80=9D define different = representations for token data. In RFC 7519 the data is carried in the = token itself (which also means the format of the token is well-defined = and know to the RS) whereas RFC 7662 defines a way to inspect tokens via = an API provided by the AS. The latter is typically used in conjunction = with opaque tokens, i.e. the RS does not have a clue how to parse and = interpret the token. The token might just be a handle to a database = entry at the AS in this case.=20 >>>=20 >>> This also means a JWT (RFC 7662) and the Introspection Response are = conceptually the same from a RSs perspective. >>>=20 >>> [...] >>>=20 >>>> The =E2=80=98jti=E2=80=99 parameter however will always be = ambiguous. As it is an identifier, it should differ for the introspected = token and the introspection response by definition. Hence the semantics = of =E2=80=98jti=E2=80=99 in a JWT introspection response is unclear. The = same can apply to the =E2=80=98iat=E2=80=99, =E2=80=98nbf=E2=80=99 and = =E2=80=98exp=E2=80=99 claims in a JWT introspection response. >>>=20 >>> I don=E2=80=99t understand the difference you are making. All before = mentioned claims are related to the (abstract) access token. You may = think of the Introspection Response as _the_ JWT representation of the = access token produced by the AS for the RS. >>>=20 >>>>=20 >>>> Can someone clarify the semantics of claims in an introspection = response JWT that are defined in both RFC7662 and RFC7519? >>>>=20 >>>> Furthermore, the introspection response should use the =E2=80=98iss=E2= =80=99 and =E2=80=98aud=E2=80=99 claims to avoid cross-JWT confusion = (section 6.1). The =E2=80=98iss=E2=80=99 and =E2=80=98aud=E2=80=99 of an = introspected token will typically be the same as those of the = introspection response. Hence a JWT access token cannot be distinguished = from an introspection response using =E2=80=98iss=E2=80=99 and =E2=80=98au= d=E2=80=99 as suggested in the draft.. >>>>=20 >>>> Introspection refers to JWT best-current-practice. The draft BCP = recommends using explicit typing of JWTs, however the draft JWT response = for introspection does not apply this recommendation and uses the = generic =E2=80=98application/jwt=E2=80=99 instead... The BCP has other = recommendations in section 3.12, but these may be insufficient to = distinguish a JWT access token from a JWT introspection response. >>>=20 >>> Good point. The reason why the BCP recommends explicit typing is to = prevent replay in other contexts. In the end typing is a compelling = concept unfortunately not broadly used in the wild. >>>=20 >>> So the JWT Introspection Response draft copes with that attack angle = by making iss and aud mandatory.=20 >>>=20 >>>=20 >>>>=20 >>>> How would people suggest to best distinguish a JWT (access) token = from a JWT introspection response? >>>=20 >>> Why should you? One reason why we extended the Introspection = Response was to eliminate the difference between JWTs directly used as = access tokens and Introspection Responses. >>>=20 >>> best regards, >>> Torsten.=20 >>>=20 >>>=20 >>> Dit bericht kan informatie bevatten die niet voor u is bestemd. = Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is = toegezonden, wordt u verzocht dat aan de afzender te melden en het = bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor = schade, van welke aard ook, die verband houdt met risico's verbonden aan = het elektronisch verzenden van berichten. >>> This message may contain information that is not intended for you. = If you are not the addressee or if this message was sent to you by = mistake, you are requested to inform the sender and delete the message. = The State accepts no liability for damage of any kind resulting from the = risks inherent in the electronic transmission of messages. >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2FD6032A-9815-48B2-822E-B38547662C1C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA5MjAxMzE4NTlaMC8GCSqGSIb3DQEJBDEiBCAeQZ1P9EPbTNwNCddPN47HIq1V5pH91X0q THvBs9NZJjCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBALfcRV8do8iUM0pxKg5hxCK27Msy3NrV9oeTvk3I0HHObZtm4oAJPHkUu+ns Z4qDp70K9eRx7LbysG+fg5O2X/EK29O76VxiLTUE0u5ViceToM6Zn4KAEDF/8Vjjuv6knvYlZN2C O+xbS4qLUza/NHNdUb+rn/DsCVufzn0hK0HEaD6chbpo9ykNEhuYE1Cz79+v9lpwUseaJTr8mVwr NLmlCoKBQe2vPUYDA2d1qbMxxUjh8y6+tGtwlZSdGuCEtt85azrh8E+rIAD7eF6rx1E3LskOUKgD l/TR/qinNyNks4HkOsg+dvxAxRAUePxmjF+ITBp3/HjFRwZ8YzRwGakAAAAAAAA= --Apple-Mail=_2FD6032A-9815-48B2-822E-B38547662C1C-- From nobody Fri Sep 20 08:15:56 2019 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 7C514120844 for ; Fri, 20 Sep 2019 08:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=aol.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 MBriSb_kuAj9 for ; Fri, 20 Sep 2019 08:15:49 -0700 (PDT) Received: from sonic304-9.consmr.mail.bf2.yahoo.com (sonic304-9.consmr.mail.bf2.yahoo.com [74.6.128.32]) (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 A342112083D for ; Fri, 20 Sep 2019 08:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1568992544; bh=JoiT8YtNSH/XLf2HOHJCb7GgtkjYxfkP5PLzyh+huIk=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=A4ZxmxsglKxjnf08cM2HdGVzK3bIRQu60T9Zm46Qg+k0BiMW00ZGeyVaMuXxaIKtfwVQKvfIbKCl3i2p8vOUjSVMQkadxE7ZD5rysIGzSxRVqkRKpFoLM8CiM42mIJef3OoZAWgcAN/MssYBQOYKu+FVjh/9NNF/WEdckPfmqLNEMHpjx15EVt4g8oW4LD/XKhvygNs3fgAwuh0HGumRQ3481rxeLfUCFovALo009Xo7OBKWrKPcASnR0fYeFtKZBzkbKIsOQ3r+G6Bh8O/r8Knto/xM41QRmhmjTIVpigO0q/GAzo5JgMzq6QPSr6a+39hZVSlS8OQMVWf3KbHlOg== X-YMail-OSG: twYuw24VM1mhkJbmwAgwe.DTfoNvSHru8bioL4p378B5sguyM5Cqz9ONEQuwh1s iP6N6rYIomMmUoo1qrgXppzsP0_cER_09.JA7oJNNPbO236yR.V3FbBC3sO5W2a4B9WKFXoad85D homxNDHvJ30.2ph0.wNey.8jbBpZJNwWFjNnAdZfJpjoTHzVE19bw7P.frohLgLIobTMptfNuOpi zy8DxSvJAdSS0SW36NWBGux4NIGls9u87sWuP1EYl1Uf5K4qqDMTWGzn8Qi7NJrtnYlBJqFESs.J oJyVU_aG9fn5qNd3hAQmNduFbpK1C11wW5ayhOLGF8StkPF4KRaO79f6smfvDcfW1vFhm2Y0ipBi zYYOy0mSvefbZZTxmW0q_6OxqooO_uvIfvEsgwaNuvr5UH718JHYa8vI2zftPXWvbkhWpV8mBQey 1U30XRYDHwgeJpM8LMfTDJsZg0AyHnI_VhGK_SuvJNe_sumHEIwmZ8vZMxsSusR6N3QK3jgpIEZK VO7rX8MAjCcNSpD8Ws8PRs5nWsuQ2RJPEb3WKqHvy0d3VIRqSEFCii0Nwz7Tg_sI4IlqkedvCrGY 9OSL4H9Cs7_vHP4R7IR_HlwHJYP6RPdDeFkhGAwFhhfQIEteZFJHqyUZdBn3kD1Bm4dJbY4nonD3 b3ISQjjo62Y9KkE_TDXMPyzc0MZ1NhOG1zqrSx__tor4am1_U_53B6lYaZRgUAOQYXDPw4OQKjzD 8rEZDAUEUMx3OK56ThlcJHT1iZjuLELK3IYIkqxEPIlwRhpuAbCyqkidzNeyoEMqV.Al3b_wdek6 clOCiHNJpILJJ8aGD5e0VtNzTJhOoexplfXvNKSD8T.WDUF1pZfHBUh0NOAWQ3fw7Y.Dgebbz3mZ hgXSJlKpNt0V_OspmM4fKmnDmwIIfFdPYQbwMGDgD7cf2UIIN6D9k6x_MAbEFQdWdIhj19d2PECX Khr9xNxJNYsFtOplJ7n3BxazReytJuwwTfj7fxedfxKAeXMy0J4Akvo.SzadY3ivjd_Ny_OEnkv. tdRPoBg86JUZsdz_xWi4Hybe.mcXBQUMfT_nsOlRfnn0TAi5b1xgdNNf2EFQIUSCABK8Qaz_N.Se 8vpOgnSFPUObKkuI1VpnZETV2Q7ESSJ8e84UJL6NBTxvpwFDYrgnZZntaBLMwr_IHVnNDwfT7aDN L6GpkYSQSaH.DrtK4MHHK9cqFiJCe28a0xvqNiq9wfsu6stpaNxegFc9CrBphV3ZnJSrQVVqC25Q IUswpLLmi3HPeC4fj.XSi9jhDYHZKEhgMiqyd1btu1rGCYASpAHeDY72tMFhNbCw9ZA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Fri, 20 Sep 2019 15:15:44 +0000 Received: by smtp432.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 4e9bc8842aecb49f9962ce1571b4fa59; Fri, 20 Sep 2019 15:15:41 +0000 (UTC) To: Rifaat Shekh-Yusef , oauth References: From: George Fletcher Organization: AOL LLC Message-ID: Date: Fri, 20 Sep 2019 11:15:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7C74860EAD37F8CDF825521B" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-reciprocal-04 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: Fri, 20 Sep 2019 15:15:54 -0000 This is a multi-part message in MIME format. --------------7C74860EAD37F8CDF825521B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Reciprocal OAuth - draft 04 Feedback 2.1 Reciprocal Scope Request -- The spec assumes the reader has an strong understanding of RFC 6749 and just references sections. More prose should be added to get the reader a better understanding of what is happening and then reference the normative text in RFC 6749. -- How does Party B know that it should return the "reciprocal" claim in the access token response? More non-normative text should be added to describe how the flow is even established (or maybe that how "reciprocal oauth" is in play is out of scope for the specification) "party B MAY include an additional query ???? component in the redirection URI to indicate the scope requested in ???? the reciprocal grant:" ???? -- This isn't an "additional query component" but rather an additional claim in the access token response. "reciprocal OPTIONAL" ???? -- I'd re-phrase the description for "reciprocal OPTIONAL" to be "The set of scopes Party B requires the resource owner to authorize for Party A to access Party B's resource" "???? If an authorization code grant access token response per [RFC6749] ???? 4.2.2, an example successful response (with extra line breaks for ???? display purposes only):" ???? -- An example successful reciprocal oauth access token response for the authorization_code grant flow per [RFC6749] 4.2.2 (extra line breaks for display purposes only) ???? -- 4.2.2 is the Implicit flow and yet the text references the authorization_code flow "???? When party B is providing an authorization response per [RFC6749] ???? 4.1.2, party B MAY include an additional query component in the ???? redirection URI to indicate the scope requested in the reciprocal ???? grant." ???? -- I would explicitly call out that this is for the "implicit" flow. Given that in many cases the implicit flow is NOT recommended as a best practice, I would recommend text to describe in what circumstances it is safe to use the implicit flow with reciprocal OAuth. ???? -- RFC 6749 4.1.1 is the authorization_code flow so I'm confused as to what the additional "query" component is. In fact 4.1.2 is the callback URL with the code and state parameters. Is the spec suggesting that the reciprocal claim be added as a query parameter to that flow rather than the access token response? 2.2 Reciprocal Authorization flow ???? -- This section only references the authorization code flow. Does that mean that reciprocal OAuth only works with the authorization code flow and not with implicit? The first part of the flow can use implicit but not the second since it is all back channel? Some text addressing this would be helpful. 2.2.2 Reciprocal Authorization code ???? -- What is the expectation if the resource owner does not approve all the scopes requested by Party B? Does this follow the OAuth2 model that Party B obtains the list of scopes granted from the access token response after presenting the code provided by Party A? "token endpoint authenticating" ???? -- are all forms of client authentication allowed? or just those specified in RFC6749? "access_token REQUIRED" ???? -- formatting is incorrect "???? Party B MUST respond with either an HTTP 200 (OK) response if the ???? request is valid, or an HTTP 400 "Bad Request" if it is not." ???? -- what form do the errors take? Should all applicable errors of RFC 6749 section 5.2 be allowed? ???? -- I'm assuming the error response should be JSON compliant with section 5.2 3 Authorization Update flow -- How scopes are managed and communicated in both the update and section 2.2.2 is unclear and should be specified No Security Considerations section -- this definitely needs to be added On 9/6/19 2:41 PM, Rifaat Shekh-Yusef wrote: > All, > > We are starting a WGLC on the Reciprocal OAuth document: > https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ > > Please, review the document and provide feedback on any issues you see > with the document. > > The WGLC will end 20-September-2019. > > Regards, > ??Rifaat and Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------7C74860EAD37F8CDF825521B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Reciprocal OAuth - draft 04 Feedback

2.1 Reciprocal Scope Request
-- The spec assumes the reader has an strong understanding of RFC 6749 and just references sections. More prose should be added to get the reader a better understanding of what is happening and then reference the normative text in RFC 6749.
-- How does Party B know that it should return the "reciprocal" claim in the access token response? More non-normative text should be added to describe how the flow is even established (or maybe that how "reciprocal oauth" is in play is out of scope for the specification)

"party B MAY include an additional query
???? component in the redirection URI to indicate the scope requested in
???? the reciprocal grant:"
???? -- This isn't an "additional query component" but rather an additional claim in the access token response.

"reciprocal OPTIONAL"
???? -- I'd re-phrase the description for "reciprocal OPTIONAL" to be "The set of scopes Party B requires the resource owner to authorize for Party A to access Party B's resource"

"???? If an authorization code grant access token response per [RFC6749]
???? 4.2.2, an example successful response (with extra line breaks for
???? display purposes only):"
???? -- An example successful reciprocal oauth access token response for the authorization_code grant flow per [RFC6749] 4.2.2 (extra line breaks for display purposes only)
???? -- 4.2.2 is the Implicit flow and yet the text references the authorization_code flow

"???? When party B is providing an authorization response per [RFC6749]
???? 4.1.2, party B MAY include an additional query component in the
???? redirection URI to indicate the scope requested in the reciprocal
???? grant."
???? -- I would explicitly call out that this is for the "implicit" flow. Given that in many cases the implicit flow is NOT recommended as a best practice, I would recommend text to describe in what circumstances it is safe to use the implicit flow with reciprocal OAuth.
???? -- RFC 6749 4.1.1 is the authorization_code flow so I'm confused as to what the additional "query" component is. In fact 4.1.2 is the callback URL with the code and state parameters. Is the spec suggesting that the reciprocal claim be added as a query parameter to that flow rather than the access token response?

2.2 Reciprocal Authorization flow
???? -- This section only references the authorization code flow. Does that mean that reciprocal OAuth only works with the authorization code flow and not with implicit? The first part of the flow can use implicit but not the second since it is all back channel? Some text addressing this would be helpful.

2.2.2 Reciprocal Authorization code
???? -- What is the expectation if the resource owner does not approve all the scopes requested by Party B? Does this follow the OAuth2 model that Party B obtains the list of scopes granted from the access token response after presenting the code provided by Party A?

"token endpoint authenticating"
???? -- are all forms of client authentication allowed? or just those specified in RFC6749?

"access_token REQUIRED"
???? -- formatting is incorrect

"???? Party B MUST respond with either an HTTP 200 (OK) response if the
???? request is valid, or an HTTP 400 "Bad Request" if it is not."
???? -- what form do the errors take? Should all applicable errors of RFC 6749 section 5.2 be allowed?
???? -- I'm assuming the error response should be JSON compliant with section 5.2

3 Authorization Update flow
-- How scopes are managed and communicated in both the update and section 2.2.2 is unclear and should be specified

No Security Considerations section
-- this definitely needs to be added


On 9/6/19 2:41 PM, Rifaat Shekh-Yusef wrote:
All,

We are starting a WGLC on the Reciprocal OAuth document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/

Please, review the document and provide feedback on any issues you see with the document.

The WGLC will end 20-September-2019.

Regards,
??Rifaat and Hannes
??

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------7C74860EAD37F8CDF825521B-- From nobody Fri Sep 20 11:50:45 2019 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 8F83612081A for ; Fri, 20 Sep 2019 11:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 UfmoTN5Yc9Pf for ; Fri, 20 Sep 2019 11:50:40 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 52A7F12011F for ; Fri, 20 Sep 2019 11:50:40 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id q1so18559814ion.1 for ; Fri, 20 Sep 2019 11:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=gfLOQeb5u8O2pDN08nv0TBUevApQWyBdBiDJynQq/hQ=; b=BXJ3iEqj5ufOmziAGojnxmJzRe4Z5nDibKUmhHh8WU43o5bIfQaXHWeNEc7OIykMxc rVTD29CbrLOHF4fpjZV6LCQFnNVNIRZSv7dLp9yiDtxlg36GBuTIAmCSCvkqkbtTHISu JuvXzh946L7Pz9JSDrviixZ7s5CErDQzNIaLE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gfLOQeb5u8O2pDN08nv0TBUevApQWyBdBiDJynQq/hQ=; b=jSWW+syCfpm9RFg/Fo/NJWF6judY6ZN0HJrmM4RoTqMW6JW+JpHmmF/xE/AOxWNIaC qiXm/L4GprwhaUJzMvMZO//YjdSiZs4d2PZxHHPg56P7SCP1j0IwYeGowaFKhCbuIrZz b42Nzmcr566jRK7VTWnIfWQm8fB685LYdqlOuBO1TwMU0IgU6jkwJAVtXrKs3uy1E44I W/P0vceQi+yQyj9pq3cCR+Lx7qe5DMK+PgEUbfqNUSpIhh1O3uXdmwTvaOZ4lz1QS/PY XR62F4oIK5CYK9d0NNnj0qM3eaWMHltBIjlVQ7toauu3d8/xG9dtUd79w3ydAu2v5MUT fzKg== X-Gm-Message-State: APjAAAUsHQyW0KbkxykAjmaqDjKzVSJLgOjfXfiyrvJ78geoxqF26WQJ sDrc1mK2kF/TI4r1HaQAIQx8ZlUahvCzH3jh00AR/2N3jL1itNW24MLpTEwgbJpIfunzuso79MU FxRXOonnNTEO5JchH5qU= X-Google-Smtp-Source: APXvYqwzQ9D9mwkX5NLG6/Wcc0DXjMb5zJITf3czBbAuuvSjkfSeIsf7ElhoY2rPyqz4r0ZuDpnzs61sMFbK41FPuck= X-Received: by 2002:a02:3f5c:: with SMTP id c28mr20605483jaf.103.1569005438879; Fri, 20 Sep 2019 11:50:38 -0700 (PDT) MIME-Version: 1.0 From: Brian Campbell Date: Fri, 20 Sep 2019 12:49:55 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000d5e7270593008b1e" Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-reciprocal-04 WGLC feedback 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: Fri, 20 Sep 2019 18:50:44 -0000 --000000000000d5e7270593008b1e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I reviewed draft-ietf-oauth-reciprocal-04 and I do not believe that the document is yet sufficiently mature to send to the IESG. A (not necessarily complete) set of comments and feedback follow. Sections 1 & 2: I realize this isn't particularly actionable but have to admit that I had a hard time reading and really understanding the introduction in section 1 and flow in section 2. And that's coming from someone who came to this document with some general familiarity with OAuth and a rough idea of what the draft was aiming to accomplish. Section 2.1: "When party B is providing an access token response per [RFC6749] 4.1.4, 4.2.1, 4.3.3 or 4.4.3, party B MAY include an additional query component in the redirection URI to indicate the scope requested in the reciprocal grant:" 4.1.4, 4.3.3 and 4.4.3 of RFC6749 are access token responses to Authorization Code Grant , Resource Owner Password Credentials Grant, and Client Credentials Grant requests respectively (I did have to look those up). Which are HTTP responses with JSON in the body. So an "additional query component in the redirection URI" doesn't make any sense in that context. Perhaps it's supposed to be an additional JSON member/parameter/element (whatever the right term is is with JSON)? But, that said, does this Reciprocal thing even make sense in response to Resource Owner Password Credentials Grant, and Client Credentials Grant requests? But if they do, then what about Extension grants (i.e. SAML, JWT, device, etc) in sec 4.5? 4.2.1 of RFC6749 is the Authorization Request of the Implicit Grant, which seems out of place here. " If an authorization code grant access token response per [RFC6749] 4.1.4, an example successful response (with extra line breaks for display purposes only):" I don't think that's a complete sentence. " Content-Type: application/json;charset=3DUTF-8" I don't believe charset is needed or used application/json. " "token_type":"example"," Really? I guess it's not wrong but using a 'real' value for token type might be easier on readers. " "example_parameter":"example_value"" Seems out of place and unnecessary for an example in this draft. " If an authorization code grant access token response per [RFC6749] 4.2.2, an example successful response (with extra line breaks for display purposes only): HTTP/1.1 302 Found Location: http://example.com/cb# access_token=3D2YotnFZFEjr1zCsicMWpAA& state=3Dxyz& token_type=3Dexample& expires_in=3D3600& reciprocal=3D"example_scope" " RFC6749's 4.2.2 is implicit and the example that follows is implicit but the text there says authorization code. That text leading up to the example also doesn't seem to form a complete sentence. A token type of example seems odd and potentially confusing here too. I don't think "example_scope" should be quoted in the example but if it really is supposed to be, then the quotes need to be form-urlencoded (%22). Should this reciprocal stuff even be defined for the implicit grant? Does it really make sense? Does the WG want to keep building on implicit? " When party B is providing an authorization response per [RFC6749] 4.1.2, party B MAY include an additional query component in the redirection URI to indicate the scope requested in the reciprocal grant." 4.1.2 of RFC6749 is the Authorization Response of the Authorization Request for the Authorization Code Grant flow. Earlier in the same section, I think the reciprocal parameter is defined for access token responses to Authorization Code Grant request. So does there need to be two different ways to send the reciprocal parameter during the same flow? Or maybe I'm misunderstanding? It's certainly possible as I'm having a hard time following this section. Section 2.2: According to RFC6749, "The token endpoint is used by the client to obtain an access token by presenting its authorization grant or refresh token." And in RFC6749 there are defined constructs and semantics for success and error responses from the token endpoint. However the grant type in section 2.2 of this draft is kind of the opposite of that where the reciprocal authorization code is being pushed/sent to the token endpoint and nothing is being obtained/returned in the response to that request. It's also means the reciprocal authorization code is being delivered to the AS even though it is intended for the client. This is arguably an illegitimate use of the given extension points in OAuth and shouldn't be done or allowed. Off hand, it would seem more appropriate to have/define a new client endpoint to receive these pushed reciprocal authorization codes. At best it's a major abuse of those extension points and the document, if it persists in doing things this way (even though I don't think it should), it needs to have some pretty good explanation for how and why this one particular grant type completely diverges from what is defined in RFC6749. On a slightly more meta level - the client and AS of the respective parties seem pretty deeply intertwined throughout this draft and I'm having trouble envisioning how those pieces would actually exist and communicate in a real deployment. Some more information or guidance or fleshing out around how this would or could actually work in practice is needed, I think. --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000d5e7270593008b1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I reviewed draft-ietf-oauth-reciprocal-04 and I do not bel= ieve that the document is yet sufficiently mature to send to the IESG.=C2= =A0 A (not necessarily complete) set of comments and feedback follow.
<= br>Sections 1 & 2:
I realize this isn't particularly actionable= but have to admit that I had a hard time reading and really understanding = the introduction in section 1 and flow in section 2. And that's coming = from someone who came to this document with some general familiarity with O= Auth and a rough idea of what the draft was aiming to accomplish.

S= ection 2.1:
=C2=A0 "When party B is providing an access token respo= nse per [RFC6749]
=C2=A0 =C2=A04.1.4, 4.2.1, 4.3.3 or 4.4.3, party B MAY= include an additional query
=C2=A0 =C2=A0component in the redirection U= RI to indicate the scope requested in
=C2=A0 =C2=A0the reciprocal grant:= "

4.1.4, 4.3.3 and 4.4.3 of RFC6749 are access token responses = to Authorization Code Grant , Resource Owner Password Credentials Grant, an= d Client Credentials Grant requests respectively (I did have to look those = up). Which are HTTP responses with JSON in the body. So an "additional= query=C2=A0 component in the redirection URI" doesn't make any se= nse in that context. Perhaps it's supposed to be an additional JSON mem= ber/parameter/element (whatever the right term is is with JSON)? But, that = said, does this Reciprocal thing even make sense in response to Resource Ow= ner Password Credentials Grant, and Client Credentials Grant requests? But = if they do, then what about Extension grants (i.e. SAML, JWT, device, etc) = in sec 4.5?

4.2.1 of RFC6749 is the Authorization Request of the Im= plicit Grant, which seems out of place here.

"=C2=A0 If an aut= horization code grant access token response per [RFC6749]
=C2=A0 =C2=A04= .1.4, an example successful response (with extra line breaks for
=C2=A0 = =C2=A0display purposes only):"

I don't think that's a c= omplete sentence.

"=C2=A0=C2=A0 Content-Type: application/json;= charset=3DUTF-8"

I don't believe charset is needed or used= application/json.

"=C2=A0 =C2=A0=C2=A0 "token_type":= "example","

Really? I guess it's not wrong but us= ing a 'real' value for token type might be easier on readers.
"=C2=A0 =C2=A0=C2=A0 "example_parameter":"example_val= ue""

Seems out of place and unnecessary for an example in = this draft.

"=C2=A0=C2=A0 If an authorization code grant acces= s token response per [RFC6749]
=C2=A0 =C2=A04.2.2, an example successful= response (with extra line breaks for
=C2=A0 =C2=A0display purposes only= ):

=C2=A0 =C2=A0HTTP/1.1 302 Found
=C2=A0 =C2=A0Location: http://example.com/cb#
=C2=A0 =C2=A0 =C2= =A0 =C2=A0access_token=3D2YotnFZFEjr1zCsicMWpAA&
=C2=A0 =C2=A0 =C2= =A0 =C2=A0state=3Dxyz&
=C2=A0 =C2=A0 =C2=A0 =C2=A0token_type=3Dexamp= le&
=C2=A0 =C2=A0 =C2=A0 =C2=A0expires_in=3D3600&
=C2=A0 =C2= =A0 =C2=A0 =C2=A0reciprocal=3D"example_scope" "

RFC67= 49's 4.2.2 is implicit and the example that follows is implicit but the= text there says authorization code. That text leading up to the example al= so doesn't seem to form a complete sentence. A token type of example se= ems odd and potentially confusing here too. I don't think "example= _scope" should be quoted in the example but if it really is supposed t= o be, then the quotes need to be form-urlencoded (%22).

Should this = reciprocal stuff even be defined for the implicit grant? Does it really mak= e sense? Does the WG want to keep building on implicit?

"=C2= =A0=C2=A0 When party B is providing an authorization response per [RFC6749]=
=C2=A0 =C2=A04.1.2, party B MAY include an additional query component i= n the
=C2=A0 =C2=A0redirection URI to indicate the scope requested in th= e reciprocal
=C2=A0 =C2=A0grant."

4.1.2 of RFC6749 is the Au= thorization Response of the Authorization Request for the Authorization Cod= e Grant flow. Earlier in the same section, I think the reciprocal parameter= is defined for access token responses to Authorization Code Grant request.= So does there need to be two different ways to send the reciprocal paramet= er during the same flow? Or maybe I'm misunderstanding? It's certai= nly possible as I'm having a hard time following this section.

S= ection 2.2:
According to RFC6749, "The token endpoint is used by th= e client to obtain an access token by presenting its authorization grant or= refresh token." And in RFC6749 there are defined constructs and seman= tics for success and error responses from the token endpoint. However the g= rant type in section 2.2 of this draft is kind of the opposite of that wher= e the reciprocal authorization code is being pushed/sent to the token endpo= int and nothing is being obtained/returned in the response to that request.= It's also means the reciprocal authorization code is being delivered t= o the AS even though it is intended for the client.=C2=A0

This is a= rguably an illegitimate use of the given extension points in OAuth and shou= ldn't be done or allowed. Off hand, it would seem more appropriate to h= ave/define a new client endpoint=C2=A0 to receive these pushed reciprocal a= uthorization codes.=C2=A0 At best it's a major abuse of those extension= points and=C2=A0the document, if it persists in doing things this way (eve= n though I don't think it should), it needs to have some pretty good ex= planation for how and why this one particular grant type completely diverge= s from what is defined in RFC6749.

On a slightly more meta level - t= he client and AS of the respective parties seem pretty deeply intertwined t= hroughout this draft and I'm having trouble envisioning how those piece= s would actually exist and communicate in a real deployment. Some more info= rmation or guidance or fleshing out around how this would or could actually= work in practice is needed, I think.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000d5e7270593008b1e-- From nobody Fri Sep 20 12:03:46 2019 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 019881208BC for ; Fri, 20 Sep 2019 12:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 96BuKrx-3pk0 for ; Fri, 20 Sep 2019 12:03:43 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 30C791208AA for ; Fri, 20 Sep 2019 12:03:43 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id e17so8035459ljf.13 for ; Fri, 20 Sep 2019 12:03:43 -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=9hs6S3OPVo+s16ZQOHC6CBoJ7XpRZRvBr/KRwsMR7co=; b=tM1Ayg76kmEjDlbMTvTATTsN18pUG461oKmez3DVfEYm+JEl0UfjCHHA8z9F/XJZbZ Bziq2sSqQvjMHGd8b+CsnL5gNgjFLhY9F2nOffrF6yGaObkM9W2H89TCuBlsE+LArftY zQbVWCue1d2IG67bEer8iq7EPYcxt91a8qf/Q0aFGPt+KbkfN8nD4wf78H7AbSSecUdZ Q0E6apJcnv2RhUNIeiYXBRNLsgfmg5nVwSRgpb005oDDQvqTaWiPtpnwqS1fTIkTJEOU 1tTUt+HF3S/MGtCi4pPSun5kVLpLcxx1tjaAMrkVcdxYPQ97OHd31Y4jYrkxOTTdTYVS KhQA== 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=9hs6S3OPVo+s16ZQOHC6CBoJ7XpRZRvBr/KRwsMR7co=; b=bk+SZksIWz3rJyjbExswiQ69vdtzz5tnyEe1SLp6hMX+d5RxEAuN60vOmT2YGlD390 WmRFdcSkmnEWERsK6OFPkfhCf4V8glhsv0nidp7PPasFNqAkuluECQ1+u9OqfJRxNh01 kjn791nLWQURoqehsT4rZxwirzYfccHnC9EaVUJfsG7jXOuNfCwHjoUbISUHA/FLkmEt FdqtgoMUoFC4BxwUQQJ821zHjeN/SbhqOcEHUUT62gCi896T+j6K1l3il7xiMZF2bPZA uMZFvAzLKIcEgxORSZp3S/gHUqmDATXUHBEiCcLxWynDvBrW75lm5XSAXGMpJ5yWf+ma pfcg== X-Gm-Message-State: APjAAAV46WqAx32JBVerytKNhFpOwhkC6ynrtPC/TF7w0IgmL94sDCHI BwMypdDEYdBw8GBsZixtFiXflVJLY6RebnkHI7jU5g0E X-Google-Smtp-Source: APXvYqyPP7jQNDuiWk4I+lc82pCzxyDtx1orRGEu7GpCuUvlMNDyti1rTC/TABwRwZ80JkJdORPS+YpFlNKtgn+q2cc= X-Received: by 2002:a2e:7212:: with SMTP id n18mr9838043ljc.91.1569006220892; Fri, 20 Sep 2019 12:03:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 20 Sep 2019 12:03:29 -0700 Message-ID: To: oauth , George Fletcher , Brian Campbell Content-Type: multipart/alternative; boundary="000000000000725c74059300ba01" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-reciprocal-04 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: Fri, 20 Sep 2019 19:03:45 -0000 --000000000000725c74059300ba01 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brian / George: thanks for the detailed critique of the draft -- much appreciated. Given all the feedback, it is clear the draft needs more work before submitting to the IESG. Unfortunately, it will be a few weeks before I have time to review and respond to your comments. =E1=90=A7 On Fri, Sep 6, 2019 at 11:42 AM Rifaat Shekh-Yusef wrote: > All, > > We are starting a WGLC on the Reciprocal OAuth document: > https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ > > Please, review the document and provide feedback on any issues you see > with the document. > > The WGLC will end 20-September-2019. > > Regards, > Rifaat and Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000725c74059300ba01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian / George: thanks for the detailed critique of the dr= aft -- much appreciated.=C2=A0

Given all the feedback, i= t is clear the draft needs more work before submitting to the IESG.
Unfortunately, it will be a few weeks before I have time to rev= iew and respond to your comments.

3D""=E1=90=A7



On F= ri, Sep 6, 2019 at 11:42 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000725c74059300ba01-- From nobody Sat Sep 21 04:02:17 2019 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 AB8EB120100 for ; Sat, 21 Sep 2019 04:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 B5DMbi3_rq9c for ; Sat, 21 Sep 2019 04:02:05 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) (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 AAC59120935 for ; Sat, 21 Sep 2019 04:02:04 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from ) id 1iBd9N-0004yX-Vh for oauth@ietf.org; Sat, 21 Sep 2019 13:02:02 +0200 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_DD801DFE-1038-44E7-BCA9-E58EAFD8B99D"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> To: oauth Date: Sat, 21 Sep 2019 13:02:01 +0200 X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-par-00.txt 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: Sat, 21 Sep 2019 11:02:16 -0000 --Apple-Mail=_DD801DFE-1038-44E7-BCA9-E58EAFD8B99D Content-Type: multipart/alternative; boundary="Apple-Mail=_0547B8DC-66E5-4476-B543-DE1482D2F6EB" --Apple-Mail=_0547B8DC-66E5-4476-B543-DE1482D2F6EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all,=20 I just published a new draft that Brian Campbell, Dave Tonge, Filip = Skokan, Nat Sakimura and I wrote.=20 https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 It proposes a new endpoint, called "pushed authorization request = endpoint=E2=80=9D, that allows the client to push the Authorization = Request payload with the AS on a backchannel connection instead of a = front channel interaction. The AS provides the client with a request URI = (according to draft-ietf-oauth-jwsreq) that the client uses in a = subsequent authorization requests to refer to the pushed request data.=20= We believe this simple mechanism will significantly increase OAuth = security and robustness since any application can use it by just sending = the parameters in the same encoding as used at the authorisation = endpoint over a HTTPS-protected and (for confidential clients) mutually = authenticated connection to the AS. It can also be used to push signed = and encrypted request objects to the AS, i.e. it provides an = interoperable way to use request objects managed at the AS for use cases = requiring an even higher security level. We look forward to getting your feedback.=20 kind regards, Torsten.=20 > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-lodderstedt-oauth-par-00.txt > Date: 21. September 2019 at 12:47:28 CEST > To: "Nat Sakimura" , "Brian Campbell" = , "Torsten Lodderstedt" = , "Dave Tonge" , "Filip Skokan" = >=20 >=20 > A new version of I-D, draft-lodderstedt-oauth-par-00.txt > has been successfully submitted by Torsten Lodderstedt and posted to = the > IETF repository. >=20 > Name: draft-lodderstedt-oauth-par > Revision: 00 > Title: OAuth 2.0 Pushed Authorization Requests > Document date: 2019-09-21 > Group: Individual Submission > Pages: 12 > URL: = https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-par-00.txt > Status: = https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ > Htmlized: = https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par >=20 >=20 > Abstract: > This document defines the pushed authorization request endpoint, > which allows clients to push the payload of an OAuth 2.0 > authorization request to the authorization server via a direct > request and provides them with a request URI that is used as > reference to the data in a subsequent authorization request. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_0547B8DC-66E5-4476-B543-DE1482D2F6EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all, 

I just = published a new draft that Brian Campbell, Dave Tonge, Filip Skokan, Nat = Sakimura and I wrote. 

https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00<= /div>

It proposes a = new endpoint, called "pushed authorization request = endpoint=E2=80=9D, that allows the client to push the Authorization = Request payload with the AS on a backchannel connection instead of a = front channel interaction. The AS provides the client with a request URI = (according to draft-ietf-oauth-jwsreq) that the client uses in a = subsequent authorization requests to refer to the pushed request = data. 

We believe this = simple mechanism will significantly increase OAuth security = and robustness since any application can use it by just = sending the parameters in the same encoding as used = at the authorisation endpoint over a HTTPS-protected and = (for confidential clients) mutually authenticated connection = to the AS. It can also be used to push signed and encrypted request = objects to the AS, i.e. it provides an interoperable way to use request = objects managed at the AS for use cases requiring an even higher = security level.

We look forward to getting your = feedback. 

kind regards,
Torsten. 

Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-lodderstedt-oauth-par-00.txt
Date: = 21. September 2019 at 12:47:28 = CEST
To: = "Nat Sakimura" <nat@sakimura.org>, = "Brian Campbell" <bcampbell@pingidentity.com>, "Torsten Lodderstedt" = <torsten@lodderstedt.net>, "Dave Tonge" <dave@tonge.org>, "Filip = Skokan" <panva.ip@gmail.com>


A new version = of I-D, draft-lodderstedt-oauth-par-00.txt
has been = successfully submitted by Torsten Lodderstedt and posted to the
IETF repository.

Name: = draft-lodderstedt-oauth-par
Revision: 00
Title:= = OAuth 2.0 Pushed Authorization Requests
Document = date: = 2019-09-21
Group: Individual Submission
Pages:= = 12
URL: =            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-pa= r-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/
Htmlized:       https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00<= br class=3D"">Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-p= ar


Abstract:
  This document defines the pushed authorization = request endpoint,
  which allows clients to = push the payload of an OAuth 2.0
=   authorization request to the authorization server via a = direct
  request and provides them with a = request URI that is used as
  reference to the = data in a subsequent authorization request.




Please note that = it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


= --Apple-Mail=_0547B8DC-66E5-4476-B543-DE1482D2F6EB-- --Apple-Mail=_DD801DFE-1038-44E7-BCA9-E58EAFD8B99D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA5MjExMTAyMDFaMC8GCSqGSIb3DQEJBDEiBCD6Gst9JykJ2nmRVSNFOZUueig9zij3Yvzj EX5VH52EkTCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAG3e0g+nNA/DN4C4aAIzgo4/15OrguLWso4H0e+ie0D64Fw0Pv8xt8Rgthuj Q3uxsoHv+FRfMPgapgjqaLgodRXtP59zDGC8RwIE5NS8DtKgxDmddbS8NG8MQtRP0I9aBan78JOO TAWK4k9K0EIx/UarkL/T18J/XGlOdzPtD1NbcdDruyjZHlTKDpGcs+qnVKxd2Ahhkp2H7Nq+6i8C wyl2BLSRGzNiZFZzP1bZHDXHd+BsAA9LJ0tRRThKuTfuMGi40p+PddVAbn/EqGvgboj2+ueBiSa8 82C52maT/b+32RkQ6ieN+wfRUz84gt+Mqt3a1/lMK6ej2MWc2Jw+pO8AAAAAAAA= --Apple-Mail=_DD801DFE-1038-44E7-BCA9-E58EAFD8B99D-- From nobody Sat Sep 21 10:51:36 2019 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 9830712004C for ; Sat, 21 Sep 2019 10:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 eFxRog14WjCg for ; Sat, 21 Sep 2019 10:51:31 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) (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 4299712001E for ; Sat, 21 Sep 2019 10:51:31 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from ) id 1iBjXa-0002q8-Rp; Sat, 21 Sep 2019 19:51:26 +0200 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_B0728D26-D9AD-4B50-ADEE-669E37B31B81"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 21 Sep 2019 19:51:25 +0200 References: <156907504831.22964.1710780113673136607.idtracker@ietfa.amsl.com> Cc: Justin Richer , Brian Campbell To: oauth Message-Id: X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt 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: Sat, 21 Sep 2019 17:51:35 -0000 --Apple-Mail=_B0728D26-D9AD-4B50-ADEE-669E37B31B81 Content-Type: multipart/alternative; boundary="Apple-Mail=_6659FA33-37DA-40B8-B702-261158E904FB" --Apple-Mail=_6659FA33-37DA-40B8-B702-261158E904FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all,=20 I just published a draft about =E2=80=9COAuth 2.0 Rich Authorization = Requests=E2=80=9D (formerly known as =E2=80=9Cstructured scopes=E2=80=9D).= =20 https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 = It specifies a new parameter =E2=80=9Cauthorization_details" that is = used to carry fine grained authorization data in the OAuth authorization = request. This mechanisms was designed based on experiences gathered in = the field of open banking, e.g. PSD2, and is intended to make the = implementation of rich and transaction oriented authorization requests = much easier than with current OAuth 2.0. I=E2=80=99m happy that Justin Richer and Brian Campbell joined me as = authors of this draft. We would would like to thank Daniel Fett, = Sebastian Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for = their valuable feedback during the preparation of this draft. We look forward to getting your feedback.=20 kind regards, Torsten.=20 > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-lodderstedt-oauth-rar-02.txt > Date: 21. September 2019 at 16:10:48 CEST > To: "Justin Richer" , "Torsten Lodderstedt" = , "Brian Campbell" >=20 >=20 > A new version of I-D, draft-lodderstedt-oauth-rar-02.txt > has been successfully submitted by Torsten Lodderstedt and posted to = the > IETF repository. >=20 > Name: draft-lodderstedt-oauth-rar > Revision: 02 > Title: OAuth 2.0 Rich Authorization Requests > Document date: 2019-09-20 > Group: Individual Submission > Pages: 16 > URL: = https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt > Status: = https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ > Htmlized: = https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-lodderstedt-oauth-rar-02 >=20 > Abstract: > This document specifies a new parameter "authorization_details" that > is used to carry fine grained authorization data in the OAuth > authorization request. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_6659FA33-37DA-40B8-B702-261158E904FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all, 

I just = published a draft about =E2=80=9COAuth 2.0 Rich Authorization = Requests=E2=80=9D (formerly known as =E2=80=9Cstructured = scopes=E2=80=9D). 

https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02<= /div>

It specifies a = new parameter =E2=80=9Cauthorization_details" that is used to = carry fine grained authorization data in the OAuth authorization = request. This mechanisms was designed based on experiences gathered in = the field of open banking, e.g. PSD2, and is intended to make the = implementation of rich and transaction oriented authorization requests = much easier than with current OAuth 2.0.

I=E2=80=99m happy that Justin Richer = and Brian Campbell joined me as authors of this draft. We would would = like to thank Daniel Fett, Sebastian Ebling, Dave Tonge, Mike Jones, Nat = Sakimura, and Rob Otto for their valuable feedback during the = preparation of this draft.

We look forward to getting your feedback. 

kind regards,
Torsten. 

Begin forwarded = message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-lodderstedt-oauth-rar-02.txt
Date: = 21. September 2019 at 16:10:48 = CEST
To: = "Justin Richer" <ietf@justin.richer.org>, "Torsten Lodderstedt" <torsten@lodderstedt.net>, "Brian Campbell" <bcampbell@pingidentity.com>

A new version of I-D, draft-lodderstedt-oauth-rar-02.txt
has been successfully submitted by Torsten Lodderstedt and = posted to the
IETF repository.

Name: = = draft-lodderstedt-oauth-rar
Revision: 02
Title:= = OAuth 2.0 Rich Authorization Requests
Document = date: = 2019-09-20
Group: Individual Submission
Pages:= = 16
URL: =            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-ra= r-02.txt
Status: =         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
Htmlized:       https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02<= br class=3D"">Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-r= ar
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-lodderstedt-oauth-rar= -02

Abstract:
=   This document specifies a new parameter = "authorization_details" that
  is used to carry = fine grained authorization data in the OAuth
=   authorization request.




Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


= --Apple-Mail=_6659FA33-37DA-40B8-B702-261158E904FB-- --Apple-Mail=_B0728D26-D9AD-4B50-ADEE-669E37B31B81 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA5MjExNzUxMjZaMC8GCSqGSIb3DQEJBDEiBCDXJi+nE5vKXautU7DCnRbqGeBhqEfZuEZI bcNkmey2BzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBALi0BwD/28ikAkfd1LENQ99HoJlDWxzovj3DdpAY+NHYlWsDRv1wyCqfAw2x tg36ul+FvuYrH0dL8+zWWC0AtFdYHyBSip+o77Z0iqSN6nY4kgapd33cMvzFaX3MGChhtgUDjw/6 I7GN+NAfcT1sIpnqEJa+VT9cPU7Xf6XHKYjMkRUv+uS0ZqLB+xt5cHlTpyfGn2/avwEYZo3ZOgLF dJgweZojejAubBaHXUeDOtYYm0gl3hpZnYWwl/rw+7MYcrSgmpJmoNcGkrzxAi+jL4qWYvTUQ91C LMDnIjRYu/r0q1rq5l/Qa/bXjWbmgCbfDqgTaBx0INEk3ofYsKkEs8sAAAAAAAA= --Apple-Mail=_B0728D26-D9AD-4B50-ADEE-669E37B31B81-- From nobody Sat Sep 21 23:39:40 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A379512002F; Sat, 21 Sep 2019 23:39:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.102.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156913437351.1261.15011938435851803280@ietfa.amsl.com> Date: Sat, 21 Sep 2019 23:39:33 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2019 06:39:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 for Browser-Based Apps Authors : Aaron Parecki David Waite Filename : draft-ietf-oauth-browser-based-apps-04.txt Pages : 20 Date : 2019-09-21 Abstract: This specification details the security considerations and best practices that must be taken into account when developing browser- based applications that use OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-browser-based-apps-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Sep 22 00:45:58 2019 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 7F31F12003E for ; Sun, 22 Sep 2019 00:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 y0YIp_UyixrS for ; Sun, 22 Sep 2019 00:45:55 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 9C0E712002F for ; Sun, 22 Sep 2019 00:45:54 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id y135so12587105wmc.1 for ; Sun, 22 Sep 2019 00:45:54 -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=GblSD8+BT1lXwo5vJlcXxBd/VKDixyROnGvtMKdd7nE=; b=m268xB2JyiCc/qnhqEgQNs1fnCZe1krrNQtMN9xR+DR+npYGVgbUYJe3HPlChSyAPG Y9dX1hXCcieome23zRMjKyfSGOrulhtLZ9gZ47BbpkGi5TkvYzdyj3laAcU2V6gNZ9UU KX7vuHTeWVfj0+QtD6MBsnHZAWzJ9T1SIMpU5u/yuhbJ1efEbPvv/F5YIgV3JwdwxCq4 u2PXRWULhOhgNOVhvDRReYb14QYF8/c0cR4T6oMnHzSBlVwuDt4vQ5CSxbATMCE7LXjf D5bpu7JMY81hFx8mRi5nGFibF2vwesimhq8U0K+7zM6ZAFLjJvLMHSJhkZNWpN1XCj9m 8Qag== 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=GblSD8+BT1lXwo5vJlcXxBd/VKDixyROnGvtMKdd7nE=; b=iSaSzJbWyAQN/lW5ujyuLrvidGSh8nXRwU5cra5u5RKcESrwFurjzKnQIPOmMW3fCx GeGRZ8PQska5/xL26m+rZdKS42RAnAwo64rLwYkksBCqU/9/Oo0XY/FGZEVkwOdYHS8M mhxZ2I5v7JAh+AD6dwiPc4JelJu4d7qmctnnRnRZDb6ydHhyBXAIs6xI7QK41gtaxEQI 5J+65MQ2TxhLn188ZZaTwO0G/muLBBiq6HUeQ5JLjpHeiLV0NbHec+j+sCZOL2HzHvLE 0eVoGPV06lpS3WvSrNFhyEJQp6xbF99CIj4H53Olr7oWEUQBVKBV/xwStBHZI86X6P+O whPw== X-Gm-Message-State: APjAAAUv7rwVN/uUw949d/K7fT4zcy2P9m+auyyQq/BXytdEw4/0+bEG gcy3ylRJvJdqxOZiY7rhbjSiyGlVT11TLWY8ctO8W0Be X-Google-Smtp-Source: APXvYqyfxJNM5SVGRqXtcS+wnUDur0wBHZz2GP4nm8DoerxBmblLm8a4bWbWzfMVnQH/NFE8PYcjiEnlFg/ZiwcGWTg= X-Received: by 2002:a05:600c:24d1:: with SMTP id 17mr9457645wmu.104.1569138353088; Sun, 22 Sep 2019 00:45:53 -0700 (PDT) MIME-Version: 1.0 References: <156907504831.22964.1710780113673136607.idtracker@ietfa.amsl.com> In-Reply-To: From: Janak Amarasena Date: Sun, 22 Sep 2019 13:15:44 +0530 Message-ID: To: Torsten Lodderstedt Cc: oauth , Justin Richer Content-Type: multipart/alternative; boundary="00000000000023ae8a05931f7ee9" Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt 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: Sun, 22 Sep 2019 07:45:56 -0000 --00000000000023ae8a05931f7ee9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Since the "authorization_details" parameter is newly introduced I feel it would be better to show how this is used with the existing authorization request at the beginning of the specification. Maybe a small sample of the complete authorization request in the "introduction" section. Also, in the "Security Considerations" section it says Authorization details are sent through the user agent in case of an OAuth authorization request, which makes them vulnerable to modifications by the *user*. Do we really need to worry that the "authorization_details" could be manipulated by the user(Resource Owner) as the client is trying to access the users' resources which the user is giving consent to? Also, the resulting token will contain the given permissions as well. Best Regards, Janak Amarasena On Sat, Sep 21, 2019 at 11:21 PM Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi all, > > I just published a draft about =E2=80=9COAuth 2.0 Rich Authorization Requ= ests=E2=80=9D > (formerly known as =E2=80=9Cstructured scopes=E2=80=9D). > > https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 > > It specifies a new parameter =E2=80=9Cauthorization_details" that is used= to carry > fine grained authorization data in the OAuth authorization request. This > mechanisms was designed based on experiences gathered in the field of ope= n > banking, e.g. PSD2, and is intended to make the implementation of rich an= d > transaction oriented authorization requests much easier than with current > OAuth 2.0. > > I=E2=80=99m happy that Justin Richer and Brian Campbell joined me as auth= ors of > this draft. We would would like to thank Daniel Fett, Sebastian Ebling, > Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable > feedback during the preparation of this draft. > > We look forward to getting your feedback. > > kind regards, > Torsten. > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for > draft-lodderstedt-oauth-rar-02.txt* > *Date: *21. September 2019 at 16:10:48 CEST > *To: *"Justin Richer" , "Torsten Lodderstedt" < > torsten@lodderstedt.net>, "Brian Campbell" > > > A new version of I-D, draft-lodderstedt-oauth-rar-02.txt > has been successfully submitted by Torsten Lodderstedt and posted to the > IETF repository. > > Name: draft-lodderstedt-oauth-rar > Revision: 02 > Title: OAuth 2.0 Rich Authorization Requests > Document date: 2019-09-20 > Group: Individual Submission > Pages: 16 > URL: > https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt > Status: > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ > Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-0= 2 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-lodderstedt-oauth-rar-02 > > Abstract: > This document specifies a new parameter "authorization_details" that > is used to carry fine grained authorization data in the OAuth > authorization request. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000023ae8a05931f7ee9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Since the=C2=A0"authorization_details" paramete= r is newly introduced I feel it would be better to show how this is used wi= th the existing authorization request at the beginning=C2=A0of the specific= ation. Maybe a small sample of the complete authorization request in the &q= uot;introduction" section.

Also, in the "Security Considerations"= section it says=C2=A0
Authorization details are sent through the user agent in case of an
OAuth =
authorization request, which makes them vulnerable to
modifications by the user=
.

Do we really need to worry that the "authorization_de= tails" could be manipulated=C2=A0by the user(Resource Owner) as the cl= ient is trying to access the users' resources which the user is giving= =C2=A0consent to? Also, the resulting token will contain the given permissi= ons as well.=C2=A0

Best Regards,
Janak Amarasena

On Sat, Sep 21, 2019 at 11:21= PM Torsten Lodderstedt <tors= ten@lodderstedt.net> wrote:
Hi all,=C2=A0<= div>
I just published a draft about =E2=80=9COAuth 2.0 Rich A= uthorization Requests=E2=80=9D (formerly known as =E2=80=9Cstructured scope= s=E2=80=9D).=C2=A0


It s= pecifies a new parameter=C2=A0=E2=80=9Cauthorization_details"=C2=A0tha= t is used to carry fine grained authorization data in the OAuth authorizati= on request. This mechanisms was designed based on experiences gathered in t= he field of open banking, e.g. PSD2, and is intended to make the implementa= tion of rich and transaction oriented authorization requests much easier th= an with current OAuth 2.0.

I=E2=80=99m happy that = Justin Richer and Brian Campbell joined me as authors of this draft. We wou= ld would like to thank Daniel Fett, Sebastian Ebling, Dave Tonge, Mike Jone= s, Nat Sakimura, and Rob Otto for their valuable feedback during the prepar= ation of this draft.

We look forward to getting yo= ur feedback.=C2=A0

kind regards,
Torsten= .=C2=A0

Begin forwarded message:=

From: = internet-drafts@ietf.org
Subject: New Version Notification for draft-lodderstedt-oauth-r= ar-02.txt
Date: 21. September 2= 019 at 16:10:48 CEST
To: "Jus= tin Richer" <ietf@justin.richer.org>, "Torsten Lodderstedt" <<= a href=3D"mailto:torsten@lodderstedt.net" target=3D"_blank">torsten@lodders= tedt.net>, "Brian Campbell" <bcampbell@pingidentity.com>


A new version of I-D, draft-lodderstedt-oau= th-rar-02.txt
has been successfully submitted by Torsten Lodderstedt and= posted to the
IETF repository.

Name: draft-lodderstedt-oauth-rar
Revision: 02
Title: OAuth 2.0 Rich A= uthorization Requests
Document date: 2019-09-20
= Group: Individual Submission
= Pages: 16
URL: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.t= xt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://t= ools.ietf.org/html/draft-lodderstedt-oauth-rar-02
Htmlized: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf= .org/doc/html/draft-lodderstedt-oauth-rar
Diff: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www= .ietf.org/rfcdiff?url2=3Ddraft-lodderstedt-oauth-rar-02

Abstract= :
=C2=A0=C2=A0This document specifies a new parameter "authorizati= on_details" that
=C2=A0=C2=A0is used to carry fine grained authori= zation data in the OAuth
=C2=A0=C2=A0authorization request.


=

Please note that it may take a couple of minutes from the time of s= ubmission
until the htmlized version and diff are available at tools.ietf.org.

The= IETF Secretariat


___= ____________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000023ae8a05931f7ee9-- From nobody Sun Sep 22 07:55:31 2019 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 5C24B120142 for ; Sun, 22 Sep 2019 07:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=forgerock.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 Mi9YTVIkOHKv for ; Sun, 22 Sep 2019 07:55:27 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 363B2120113 for ; Sun, 22 Sep 2019 07:55:26 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id a11so11286702wrx.1 for ; Sun, 22 Sep 2019 07:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=hVOEMC3PptczFu12uQjtoMEDOfIWpzHKCarT7eKPGxU=; b=b6jSfHl/WDea29bkibLqk4KwkWSGilf+cEqABGVpry1WcFlooSC4YvzGRjnPmcwqA5 69s3umBdbZeuUB6z5ETmbCzk1fnf4o9m7SRJGA8QWDSdGgeX7FSsrKrri4Yofwn1xYqC VNWYqz2QYCwMN93x6SWfZ3p/xOnKJP0w39AsQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=hVOEMC3PptczFu12uQjtoMEDOfIWpzHKCarT7eKPGxU=; b=DZ8Kr0hzHPhrf/N2++6BR7E8eTnkh9Z6ad4cCzI0UJTME4dRKQxAUjZ4pkAv2yR+RZ GfNiU78CXMcU8dNWwfqP36F/y6RjXkDx+1V2dLfKolWi7QxYzGpD6q/vnEVp8DMEIv0y yCP57EJhroDqCZ2HL4F2UWA9hq8r4hywTsAtf8eg1n0vJi3VXQDAu0YKmxfBDVij129n S6C6v1bjkY8P6j/fhJCpPnJPOoYylZN2P/ZJsEhxSttXC+SkA2AWJmhbpf1X4hN79VKu lYhPLG4Vch9jRzTVQW5SRSTwDKhA5GZ3Y3NipIjG/ll0LDhfEWph+7T12G6Ok5Yhd6f5 z40A== X-Gm-Message-State: APjAAAUAsQQGg1/A5wsDZmgL09fDVcWKsMoWig6bs5HWf+LPorNL4DuO UiNfVRS2LdgrsNs2NbPFmSS3twITsFdDZHkZexuq4eR0Z8Ij4Nu8ogJyj0SJ4h/Jn8O059RScj/ PZwv+kEtcXpCdSQGxMWkQ+gM1f3jhA+yzP+81a6TCqEOrZqbNz/l/QOiHsOWDoKA= X-Google-Smtp-Source: APXvYqyZUz5hJgwAAMIQWCED80sAuGrnMO1F9VDThWwneRPkEbOpS4YAMC5ED7Vr4m3r5YpJR9NwqQ== X-Received: by 2002:a05:6000:12:: with SMTP id h18mr17948688wrx.156.1569164124558; Sun, 22 Sep 2019 07:55:24 -0700 (PDT) Received: from ?IPv6:2a01:4c8:1a:e3ff:450f:2d4f:bbf6:492? ([2a01:4c8:1a:e3ff:450f:2d4f:bbf6:492]) by smtp.gmail.com with ESMTPSA id o9sm15193906wrh.46.2019.09.22.07.55.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Sep 2019 07:55:22 -0700 (PDT) From: Neil Madden Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Sun, 22 Sep 2019 15:55:21 +0100 Message-Id: To: oauth@ietf.org X-Mailer: iPhone Mail (16G102) Archived-At: Subject: [OAUTH-WG] Minor issue in https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08 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: Sun, 22 Sep 2019 14:55:30 -0000 Just noticed that the iat/exp claims in the example JWT response in section 5= appear to be in milliseconds rather than the standard seconds.=20 =E2=80=94 Neil= From nobody Sun Sep 22 12:52:38 2019 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 1137D120090 for ; Sun, 22 Sep 2019 12:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 AFPC17u8ual7 for ; Sun, 22 Sep 2019 12:52:34 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 50D0512002E for ; Sun, 22 Sep 2019 12:52:34 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id i1so11657829wro.4 for ; Sun, 22 Sep 2019 12:52:34 -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=Ze/qqS8jQr4bzHcL9IWY1Vmm7/QXOlHswtJ+VSlfXLk=; b=MbHG2bjPhetitdZOnTrYdnxUylnRXPDkUfDcBNEVmAFzeUSPwMwgk6LHBj544LDLrH z++u1ceqAvFEbk2YgeCiXCopTm2TM4Evn4F2P4Ee0w0TMvEICohslkVl4TRyk6TndFvA ys7HExJtPvLl8Whnyl9Ke+hT4II2hMBsM7vvghiYCXb6ONdv1EidahOJ6jqC56s/B/6A uman8H0l0ptuoZKXfK3awBQFOGRC1HHhwOQWKN6yP9zEoE1SkmQV6ba/puIYxeSbxS+I 5PJHESQ6oRNHLQ1gWBpLdSa8kzPYdUHAKQFOfdsN+ytoWX313ECWP49+De8NGQqVPTcl Ap3g== 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=Ze/qqS8jQr4bzHcL9IWY1Vmm7/QXOlHswtJ+VSlfXLk=; b=GmcO+zekknzXrG2GlaMuNO1qM65nbalrtN3W5nXDXo3kAyBKf61E+FDGKVXwUEkvxY znnlt0DbJDZRcBUQHdHwU9FeUCtyGGnYiZR/B0LnBlaIncn5AHA0A9dNsbLFAS1v+7Bw rvqJI8RNy2DWLcHaITnWNMr5ImzvTe9gvaoJnQzrdvezaYVz3xe0iuFX7kS4cy3AM30d GGWzgzdx6/0B5ms1Mn+MRRu8MpUqlPNpGITOJefvsVmim40jzcZse1aiHOv4JwQqC2bh hNUZ/nubWnF01Uo0Ag87UchbLFjo/mgBXdn8N+p1rSvFiRwlhctKRBlW+w3y3HH07erG 8/IQ== X-Gm-Message-State: APjAAAUAcJUl8L19t9oiHEjpnKY56f8CHPmUSQZAwPK4vwTWObrXpHgw j+cN5mxVTbgsIgfOXtpTD8YMe1a0nt1QIWBuO/Q= X-Google-Smtp-Source: APXvYqzbVKxWhi4DUAEm7GzDWPUYiYAKSeKiFKFKZIBJDqj/5g3sKkunEgU5FEHCDs126DH13JpJkImCt6sKI7WFHtk= X-Received: by 2002:adf:ff91:: with SMTP id j17mr18167810wrr.5.1569181952784; Sun, 22 Sep 2019 12:52:32 -0700 (PDT) MIME-Version: 1.0 References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> In-Reply-To: <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> From: Janak Amarasena Date: Mon, 23 Sep 2019 01:21:58 +0530 Message-ID: To: Torsten Lodderstedt Cc: oauth Content-Type: multipart/alternative; boundary="000000000000e2407d059329a4ea" Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-par-00.txt 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: Sun, 22 Sep 2019 19:52:37 -0000 --000000000000e2407d059329a4ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Since the */as/par* endpoint is intended to be used to store the actual authorization request I feel that validating the authorization request as mentioned in *point 2 *section 2.1(Request) should not be a responsibility of the /as/par endpoint and that it should not validate the authorization request. Also, the majority case could be the endpoint receiving valid requests and the validation process will be duplicated at the authorization endpoint. Also since section 2.2 (Successful Response) states; The "request URI" MUST be bound to the "client_id" of the client that posted the authorization request. Wouldn't it be good to enforce the use of the clientId in section 4 (Authorization Request) when the authorization request is made with the " request_uri" parameter? GET /authorize?request_uri=3Durn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2*&c= lient_id=3Ds6BhdRkqt3* HTTP/1.1 Best Regards, Janak Amarasena On Sat, Sep 21, 2019 at 4:32 PM Torsten Lodderstedt wrote: > Hi all, > > I just published a new draft that Brian Campbell, Dave Tonge, Filip > Skokan, Nat Sakimura and I wrote. > > https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 > > It proposes a new endpoint, called "pushed authorization request > endpoint=E2=80=9D, that allows the client to push the Authorization Reque= st payload > with the AS on a backchannel connection instead of a front channel > interaction. The AS provides the client with a request URI (according to > draft-ietf-oauth-jwsreq) that the client uses in a subsequent authorizati= on > requests to refer to the pushed request data. > > We believe this simple mechanism will significantly increase > OAuth security and robustness since any application can use it by just > sending the parameters in the same encoding as used > at the authorisation endpoint over a HTTPS-protected and > (for confidential clients) mutually authenticated connection to the AS. I= t > can also be used to push signed and encrypted request objects to the AS, > i.e. it provides an interoperable way to use request objects managed at t= he > AS for use cases requiring an even higher security level. > > We look forward to getting your feedback. > > kind regards, > Torsten. > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for > draft-lodderstedt-oauth-par-00.txt* > *Date: *21. September 2019 at 12:47:28 CEST > *To: *"Nat Sakimura" , "Brian Campbell" < > bcampbell@pingidentity.com>, "Torsten Lodderstedt" < > torsten@lodderstedt.net>, "Dave Tonge" , "Filip Skokan" < > panva.ip@gmail.com> > > > A new version of I-D, draft-lodderstedt-oauth-par-00.txt > has been successfully submitted by Torsten Lodderstedt and posted to the > IETF repository. > > Name: draft-lodderstedt-oauth-par > Revision: 00 > Title: OAuth 2.0 Pushed Authorization Requests > Document date: 2019-09-21 > Group: Individual Submission > Pages: 12 > URL: > https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-par-00.txt > Status: > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ > Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-par-0= 0 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par > > > Abstract: > This document defines the pushed authorization request endpoint, > which allows clients to push the payload of an OAuth 2.0 > authorization request to the authorization server via a direct > request and provides them with a request URI that is used as > reference to the data in a subsequent authorization request. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000e2407d059329a4ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Since the /as/par endpoint i= s intended=C2=A0to be used to store the actual authorization request I feel= that validating the authorization request as mentioned in point 2 s= ection=C2=A02.1(Request) should not be a responsibility=C2=A0of the /as/par= endpoint and that it should=C2=A0not validate the=C2=A0authorization reque= st. Also, the majority case could be the endpoint receiving=C2=A0valid requ= ests and the validation process will be duplicated at the authorization end= point.

Also since section 2.2 (Successful Response= ) states;
The "requ=
est URI" MUST be bound to the "client_id" of the client that=
 posted the authorization request.
Wouldn't it = be good to enforce the use of the clientId in section 4 (Authorization Requ= est) when the authorization request is made with the "request_uri" parameter?
GET /authorize?request_uri=3Durn=
%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2&client_id=3Ds6BhdRkqt3 =
HTTP/1.1


Best Reg= ards,
Janak Amarasena

On Sat, Sep 21, 2019 at 4:= 32 PM Torsten Lodderstedt <to= rsten@lodderstedt.net> wrote:
Hi all,=C2= =A0

I just published a new draft that Brian Campbell, Da= ve Tonge, Filip Skokan, Nat Sakimura and I wrote.=C2=A0


It proposes a new endpoint, called "<= span style=3D"font-family:verdana,helvetica,arial,sans-serif;font-size:13.3= 333px;font-variant-ligatures:normal">pushed authorization request endpoint= =E2=80=9D, that allows the client to push the Authorization Request payload= with the AS on a backchannel connection instead of a front channel interac= tion. The AS provides the client with a request URI (according to draft-iet= f-oauth-jwsreq) that the client uses in a subsequent authorization requests= to refer to the pushed request data.=C2=A0

We believ= e this simple mechanism will=C2=A0significantly increase OAuth=C2=A0securit= y and robustness=C2=A0since any=C2=A0application can use it by just sending= the=C2=A0parameters in the same encoding as used at=C2=A0the=C2=A0authoris= ation=C2=A0endpoint over a HTTPS-protected and (for=C2=A0confidential=C2=A0= clients) mutually authenticated connection to the AS. It can also be used t= o push signed and=C2=A0encrypted request objects to the AS, i.e. it provide= s an interoperable way to use request objects managed at the AS for use cas= es requiring an even=C2=A0higher security level.

We look f= orward to getting your feedback.=C2=A0

kind regards,
Torsten.=C2=A0

B= egin forwarded message:

= Subject: New Version Notification for dr= aft-lodderstedt-oauth-par-00.txt
Date: 21. September 2019 at 12:47:28 CEST
To: "Nat Sakimura" <nat@sakimura.org>, "Brian Campbell"= <bcampb= ell@pingidentity.com>, "Torsten Lodderstedt" <torsten@lodderstedt.n= et>, "Dave Tonge" <dave@tonge.org>, "Filip Skokan" <panva.ip@gmail.com>= ;


A new version of I-D, draft-lodderstedt= -oauth-par-00.txt
has been successfully submitted by Torsten Lodderstedt= and posted to the
IETF repository.

Name: draft-lodderstedt-oauth-par
Revision: = 00
Title: OAuth 2.0 Pu= shed Authorization Requests
Document date: 2019-09-= 21
Group: Individual Submissi= on
Pages: 12
URL: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-pa= r-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/=
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https:/= /tools.ietf.org/html/draft-lodderstedt-oauth-par-00
Htmlized: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf= .org/doc/html/draft-lodderstedt-oauth-par


Abstract:
=C2= =A0=C2=A0This document defines the pushed authorization request endpoint, =C2=A0=C2=A0which allows clients to push the payload of an OAuth 2.0
= =C2=A0=C2=A0authorization request to the authorization server via a direct=
=C2=A0=C2=A0request and provides them with a request URI that is used = as
=C2=A0=C2=A0reference to the data in a subsequent authorization requ= est.




Please note that it may take a couple of minutes fr= om the time of submission
until the htmlized version and diff are availa= ble at tools.ietf.org.

The IETF Secretariat


<= /div>_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000e2407d059329a4ea-- From nobody Mon Sep 23 03:25:06 2019 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 0FA2B1202DD for ; Mon, 23 Sep 2019 03:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 dmnblufYX1ky for ; Mon, 23 Sep 2019 03:25:04 -0700 (PDT) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (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 4694F120105 for ; Mon, 23 Sep 2019 03:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1569234303; bh=gwNtEq873UwqSJkRXewl9+wpTlwAAPenuGEHs2S9GoM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=ePK4TQVLTZz1W2lPdVa1GLmKPGDsoUu4rj2CxIGZgB/zwFw6/QxoBGKtozF6chkXfFID1lqA3abBa/ty02TIVu904kLIU513UYVoIMEfHiCvxXi0Wj+VysX5krKLEGL/ZL9mkT5usHk/PqZhiiC1HY3oPY0NwoZWJIoemKXUx766gt9jA9j4ZeyHvkKzSd2/8A5I4xoAf0Ad+zOh8fi3zv38vtPZX075xHizHr20/b8afWsLY0/tPy1VUOgAYYfCsPMFI/6oZrpN6R4ptGUIKYavj6m3/WnkL/lPUDbFHVo1IC3BZghhMEgfczLVG126OFjgzKbk+onODCXSdFMf4A== X-YMail-OSG: tNOd4tcVM1majJMCWwwag8Dx6Vq7qXJhiOgKlPMSsdvWLeSYPOoCWF25MSnDXDA taG6BJt.UWv5oRCPr_b3nZVZ6SRt59AQ_2mRPc7nfN0xhKakgZbQiK5oz9RrRba03vt5Dvr4xn8B 7YP6SjywUlwuQaTO1HguJEVPEIGDjuKF6HBq2KiYLsSLDyJPBTnWYkIaKLoD1KcYEoIMxaUYiDcY To8Ro1aAlCcslbX8rkOUTXQg2KEd4tR.Kldwsz9iiVLtWYocGup1g6DqIUHSbYsXyWrvwHxR1Cdk pguy7jR116HgbK9AnAHwvipD2uh2CBonzPWScv3dSiQYFoDmMkGxqJgJPNv3yRMEpsePeq_gdd1j YzoU1.o6VEv4MMA9KxYg1rPOLtlJw4reaywbJIS114V1_jQTaBvGdpBoYGKsS3s9CF_BHVR9Hmdw fZH6HYvrqDwzhREGP0Gift9tVRnRRUJrp3a4AjZiCtTqg4sIli6AR4LhN5N1DsodXzPhG2eTI6tg JMXX9gXji1BVlY2Sv407owwkKymTSFXgeUuctM735OJN.a8Y2sB9zcFaIn2DO2eYoQ3bixSfsVuY XMh0m99VKjicQITn8gnUeTXsQyuIQj2qrelDdhYaA5WIRjNvIsahW2SJbvI1eogfQVGMZ3P1xFmF jk.hvH0sl7rjI2.UB6BfKNh.0_iPgMtPfiSwwG4PIEC46nNU9I.NcNNWeG6VHsj9ozkjJxsxV.nJ muFVfK6SOzjoBcMgb2rndmCheHbbTDj.L6m8lhAGar2XmKWpH0v_vRqB6m0Txfu.2AVmVvDOGAyM COIfYY3EpZf1vraS5R5voOIcXipGRSO5Udkej4v2wT1zEkcP6At6TA8H8S6xSTOSpdVt0p3zxaOz J.M5dKZ20xga3evxZpo5eDzrfdO2SOPIjbw01VKvT0RbW81PejvmcZgmi_JfwPbC924vC05k9OMZ HGjGu3edHBdmZO2MD9Mdk_lMyAIkiStQ2KhgI3VnZdKEACq168Pi9VFrqEqm7lWatlSaml_1XbnR ZDu_iAnX0Gj5PDn67up_d1IqMYMnf9.uW4TrwvpOxx5WGByYdhp7NqdzAtxdc42iFc5eWPwbhJJE etDYpm244cj8oRGNeHUJ4AhJXxamWTW7y2hOD7ldUfG4aphYjk_xTZcqT36GctquxMaadF70.kSS RvLYwGm7oYAQtvh3GRaunsDkbLx8g6.6B8iW0bAFoecDeUB4rp6rHGqX9dABHnD1xezpdMwKd2zn G2Ge8xAFu11wiM52xIxfz_3YmB9k4.fVMI2AxAOMn5BesuSQnFcDXlb9IIWIRhKZkOVbdWYnak0w jdtuh73jRtL_CU2tOjoHGBLLAP.utDoOIC6TnXJqGMT.1Zt_j2nC1J0NL6Vs2WsWmq2bn2jMaXnH EAAgTXr85CQSyWoU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Mon, 23 Sep 2019 10:25:03 +0000 Received: by smtp427.mail.sg3.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID b0e9ad229b56177bbea42ced159b4e40; Mon, 23 Sep 2019 10:24:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kim Oun X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Mon, 23 Sep 2019 17:24:34 +0700 Cc: oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <05A403FB-F58E-4C8E-9D5E-30571F59106C@yahoo.com> References: To: oauth-bounces@ietf.org Archived-At: Subject: Re: [OAUTH-WG] Mailman privacy alert 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, 23 Sep 2019 10:25:05 -0000 On Sep 23, 2019, at 5:16 PM, oauth-bounces@ietf.org wrote: An attempt was made to subscribe your address to the mailing list oauth@ietf.org. You are already subscribed to this mailing list. Note that the list membership is not public, so it is possible that a bad person was trying to probe the list for its membership. This would be a privacy violation if we let them do this, but we didn't. If you submitted the subscription request and forgot that you were already subscribed to the list, then you can ignore this message. If you suspect th= at an attempt is being made to covertly discover whether you are a member of th= is list, and you are worried about your privacy, then feel free to send a messa= ge to the list administrator at oauth-owner@ietf.org. From nobody Mon Sep 23 03:25:14 2019 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 2D130120105 for ; Mon, 23 Sep 2019 03:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 r6ZEKURGOgYp for ; Mon, 23 Sep 2019 03:25:04 -0700 (PDT) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (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 49495120288 for ; Mon, 23 Sep 2019 03:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1569234303; bh=gwNtEq873UwqSJkRXewl9+wpTlwAAPenuGEHs2S9GoM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=ePK4TQVLTZz1W2lPdVa1GLmKPGDsoUu4rj2CxIGZgB/zwFw6/QxoBGKtozF6chkXfFID1lqA3abBa/ty02TIVu904kLIU513UYVoIMEfHiCvxXi0Wj+VysX5krKLEGL/ZL9mkT5usHk/PqZhiiC1HY3oPY0NwoZWJIoemKXUx766gt9jA9j4ZeyHvkKzSd2/8A5I4xoAf0Ad+zOh8fi3zv38vtPZX075xHizHr20/b8afWsLY0/tPy1VUOgAYYfCsPMFI/6oZrpN6R4ptGUIKYavj6m3/WnkL/lPUDbFHVo1IC3BZghhMEgfczLVG126OFjgzKbk+onODCXSdFMf4A== X-YMail-OSG: tNOd4tcVM1majJMCWwwag8Dx6Vq7qXJhiOgKlPMSsdvWLeSYPOoCWF25MSnDXDA taG6BJt.UWv5oRCPr_b3nZVZ6SRt59AQ_2mRPc7nfN0xhKakgZbQiK5oz9RrRba03vt5Dvr4xn8B 7YP6SjywUlwuQaTO1HguJEVPEIGDjuKF6HBq2KiYLsSLDyJPBTnWYkIaKLoD1KcYEoIMxaUYiDcY To8Ro1aAlCcslbX8rkOUTXQg2KEd4tR.Kldwsz9iiVLtWYocGup1g6DqIUHSbYsXyWrvwHxR1Cdk pguy7jR116HgbK9AnAHwvipD2uh2CBonzPWScv3dSiQYFoDmMkGxqJgJPNv3yRMEpsePeq_gdd1j YzoU1.o6VEv4MMA9KxYg1rPOLtlJw4reaywbJIS114V1_jQTaBvGdpBoYGKsS3s9CF_BHVR9Hmdw fZH6HYvrqDwzhREGP0Gift9tVRnRRUJrp3a4AjZiCtTqg4sIli6AR4LhN5N1DsodXzPhG2eTI6tg JMXX9gXji1BVlY2Sv407owwkKymTSFXgeUuctM735OJN.a8Y2sB9zcFaIn2DO2eYoQ3bixSfsVuY XMh0m99VKjicQITn8gnUeTXsQyuIQj2qrelDdhYaA5WIRjNvIsahW2SJbvI1eogfQVGMZ3P1xFmF jk.hvH0sl7rjI2.UB6BfKNh.0_iPgMtPfiSwwG4PIEC46nNU9I.NcNNWeG6VHsj9ozkjJxsxV.nJ muFVfK6SOzjoBcMgb2rndmCheHbbTDj.L6m8lhAGar2XmKWpH0v_vRqB6m0Txfu.2AVmVvDOGAyM COIfYY3EpZf1vraS5R5voOIcXipGRSO5Udkej4v2wT1zEkcP6At6TA8H8S6xSTOSpdVt0p3zxaOz J.M5dKZ20xga3evxZpo5eDzrfdO2SOPIjbw01VKvT0RbW81PejvmcZgmi_JfwPbC924vC05k9OMZ HGjGu3edHBdmZO2MD9Mdk_lMyAIkiStQ2KhgI3VnZdKEACq168Pi9VFrqEqm7lWatlSaml_1XbnR ZDu_iAnX0Gj5PDn67up_d1IqMYMnf9.uW4TrwvpOxx5WGByYdhp7NqdzAtxdc42iFc5eWPwbhJJE etDYpm244cj8oRGNeHUJ4AhJXxamWTW7y2hOD7ldUfG4aphYjk_xTZcqT36GctquxMaadF70.kSS RvLYwGm7oYAQtvh3GRaunsDkbLx8g6.6B8iW0bAFoecDeUB4rp6rHGqX9dABHnD1xezpdMwKd2zn G2Ge8xAFu11wiM52xIxfz_3YmB9k4.fVMI2AxAOMn5BesuSQnFcDXlb9IIWIRhKZkOVbdWYnak0w jdtuh73jRtL_CU2tOjoHGBLLAP.utDoOIC6TnXJqGMT.1Zt_j2nC1J0NL6Vs2WsWmq2bn2jMaXnH EAAgTXr85CQSyWoU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Mon, 23 Sep 2019 10:25:03 +0000 Received: by smtp427.mail.sg3.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID b0e9ad229b56177bbea42ced159b4e40; Mon, 23 Sep 2019 10:24:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kim Oun X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Mon, 23 Sep 2019 17:24:34 +0700 Cc: oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <05A403FB-F58E-4C8E-9D5E-30571F59106C@yahoo.com> References: To: oauth-bounces@ietf.org Archived-At: Subject: Re: [OAUTH-WG] Mailman privacy alert 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, 23 Sep 2019 10:25:05 -0000 On Sep 23, 2019, at 5:16 PM, oauth-bounces@ietf.org wrote: An attempt was made to subscribe your address to the mailing list oauth@ietf.org. You are already subscribed to this mailing list. Note that the list membership is not public, so it is possible that a bad person was trying to probe the list for its membership. This would be a privacy violation if we let them do this, but we didn't. If you submitted the subscription request and forgot that you were already subscribed to the list, then you can ignore this message. If you suspect th= at an attempt is being made to covertly discover whether you are a member of th= is list, and you are worried about your privacy, then feel free to send a messa= ge to the list administrator at oauth-owner@ietf.org. From nobody Mon Sep 23 11:08:55 2019 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 78882120939 for ; Mon, 23 Sep 2019 11:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 soWpQmK5iObf for ; Mon, 23 Sep 2019 11:08:38 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.96]) (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 418171208DE for ; Mon, 23 Sep 2019 11:08:38 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from ) id 1iCSlH-0005vY-1w; Mon, 23 Sep 2019 20:08:35 +0200 From: Torsten Lodderstedt Message-Id: <1B3E385A-93B4-4C45-8926-A6822CDDB122@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_5A6B4976-3D17-4B64-9383-1933623E2DEB"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 23 Sep 2019 20:08:33 +0200 In-Reply-To: Cc: oauth , Justin Richer To: Janak Amarasena References: <156907504831.22964.1710780113673136607.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-rar-02.txt 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, 23 Sep 2019 18:08:54 -0000 --Apple-Mail=_5A6B4976-3D17-4B64-9383-1933623E2DEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Janak,=20 thanks for your feedback.=20 > On 22. Sep 2019, at 09:45, Janak Amarasena = wrote: >=20 > Hi, >=20 > Since the "authorization_details" parameter is newly introduced I feel = it would be better to show how this is used with the existing = authorization request at the beginning of the specification. Maybe a = small sample of the complete authorization request in the "introduction" = section. Sounds reasonable, I put it on the list for the next revision.=20 >=20 > Also, in the "Security Considerations" section it says=20 > Authorization details are sent through the user agent in case of an > OAuth authorization request, which makes them vulnerable to > modifications by the user. >=20 > Do we really need to worry that the "authorization_details" could be = manipulated by the user(Resource Owner) as the client is trying to = access the users' resources which the user is giving consent to? Also, = the resulting token will contain the given permissions as well.=20 I understand. I think the more general case of modifying the = Authorization Request content, e.g. PKCE challenge, and swapping such = parameters between different devices is the important attack vector. I = will improve the text. best regards, Torsten.=20 >=20 > Best Regards, > Janak Amarasena >=20 > On Sat, Sep 21, 2019 at 11:21 PM Torsten Lodderstedt = wrote: > Hi all,=20 >=20 > I just published a draft about =E2=80=9COAuth 2.0 Rich Authorization = Requests=E2=80=9D (formerly known as =E2=80=9Cstructured scopes=E2=80=9D).= =20 >=20 > https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 >=20 > It specifies a new parameter =E2=80=9Cauthorization_details" that is = used to carry fine grained authorization data in the OAuth authorization = request. This mechanisms was designed based on experiences gathered in = the field of open banking, e.g. PSD2, and is intended to make the = implementation of rich and transaction oriented authorization requests = much easier than with current OAuth 2.0. >=20 > I=E2=80=99m happy that Justin Richer and Brian Campbell joined me as = authors of this draft. We would would like to thank Daniel Fett, = Sebastian Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for = their valuable feedback during the preparation of this draft. >=20 > We look forward to getting your feedback.=20 >=20 > kind regards, > Torsten.=20 >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-lodderstedt-oauth-rar-02.txt >> Date: 21. September 2019 at 16:10:48 CEST >> To: "Justin Richer" , "Torsten Lodderstedt" = , "Brian Campbell" >>=20 >>=20 >> A new version of I-D, draft-lodderstedt-oauth-rar-02.txt >> has been successfully submitted by Torsten Lodderstedt and posted to = the >> IETF repository. >>=20 >> Name: draft-lodderstedt-oauth-rar >> Revision: 02 >> Title: OAuth 2.0 Rich Authorization Requests >> Document date: 2019-09-20 >> Group: Individual Submission >> Pages: 16 >> URL: = https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt >> Status: = https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ >> Htmlized: = https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-lodderstedt-oauth-rar-02 >>=20 >> Abstract: >> This document specifies a new parameter "authorization_details" = that >> is used to carry fine grained authorization data in the OAuth >> authorization request. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_5A6B4976-3D17-4B64-9383-1933623E2DEB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA5MjMxODA4MzRaMC8GCSqGSIb3DQEJBDEiBCB16k3aftfy33SwmFdKuA7wVoe7sJzRe2d4 n+ETW7GgWjCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAAjemjS5Pnf829yP7qJIUaaufRzfKqWikAmw6G88A7kIRB0zSi7v0ypELmPP E1L/hIRTShitPLMHeJAKQjtHOsbCuRq7V12tk3OIZj+ljK3WH80Xsp5lulGjekZgTrHny4TAMedC vwxd0kPy5gb9Y74JfOaXaQ+w5ARaQzv/00Rs0RtSsKJkeFKohgO4ihQIrtuVE8dgbmxYYrBTAW1N WJ95Rp1zvRcN3wAT5Qke7AQnojtNaLDLR8V3gqOz+M702pD3xn/R4wmNTVoVW1UlOIZ02dHCZWnu ESYvx4y5G5ugXdJtR77+O1eo6tB29SQRqeCg7TUJNdb3Fs0ssahAK40AAAAAAAA= --Apple-Mail=_5A6B4976-3D17-4B64-9383-1933623E2DEB-- From nobody Mon Sep 23 11:17:11 2019 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 3327A120088 for ; Mon, 23 Sep 2019 11:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.026, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 HasKpXjvdvQJ for ; Mon, 23 Sep 2019 11:17:06 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) (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 68DB012004D for ; Mon, 23 Sep 2019 11:17:06 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from ) id 1iCStT-000680-HM; Mon, 23 Sep 2019 20:17:03 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7E0DB8C1-AF81-489A-9B0C-EF0F24F86AFE"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 23 Sep 2019 20:17:02 +0200 In-Reply-To: Cc: oauth , Filip Skokan To: Janak Amarasena References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt 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, 23 Sep 2019 18:17:09 -0000 --Apple-Mail=_7E0DB8C1-AF81-489A-9B0C-EF0F24F86AFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Janak, thanks for your feedback to PAR as well.=20 > On 22. Sep 2019, at 21:51, Janak Amarasena = wrote: >=20 > Hi, >=20 > Since the /as/par endpoint is intended to be used to store the actual = authorization request I feel that validating the authorization request = as mentioned in point 2 section 2.1(Request) should not be a = responsibility of the /as/par endpoint and that it should not validate = the authorization request. Why do you think so? Validating the request data at the pushed authorisation request endpoint = has the advantage that the AS can refuse the process early. It also = means the authorisation endpoint of the AS can safely assume all request = URIs sent in Authorization Request that are minted by the same AS (which = is detected based on its structure), are pre-checked and can be trusted = (regarding the input validation). =20 > Also, the majority case could be the endpoint receiving valid requests = and the validation process will be duplicated at the authorization = endpoint. I would assume the same core service is used to check the payload, so no = code duplication required. >=20 > Also since section 2.2 (Successful Response) states; > The "request URI" MUST be bound to the "client_id" of the client that = posted the authorization request. > Wouldn't it be good to enforce the use of the clientId in section 4 = (Authorization Request) when the authorization request is made with the = "request_uri" parameter? > GET = /authorize?request_uri=3Durn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2&clien= t_id=3Ds6BhdRkqt3 HTTP/1.1 There is no need for an additional client id since the request URI is = already bound to the client_id passed to and, in case of a confidential = client, authenticated in the pushed authorization request. best regards, Torsten. =20 >=20 >=20 > Best Regards, > Janak Amarasena >=20 > On Sat, Sep 21, 2019 at 4:32 PM Torsten Lodderstedt = wrote: > Hi all,=20 >=20 > I just published a new draft that Brian Campbell, Dave Tonge, Filip = Skokan, Nat Sakimura and I wrote.=20 >=20 > https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 >=20 > It proposes a new endpoint, called "pushed authorization request = endpoint=E2=80=9D, that allows the client to push the Authorization = Request payload with the AS on a backchannel connection instead of a = front channel interaction. The AS provides the client with a request URI = (according to draft-ietf-oauth-jwsreq) that the client uses in a = subsequent authorization requests to refer to the pushed request data.=20= >=20 > We believe this simple mechanism will significantly increase OAuth = security and robustness since any application can use it by just sending = the parameters in the same encoding as used at the authorisation = endpoint over a HTTPS-protected and (for confidential clients) mutually = authenticated connection to the AS. It can also be used to push signed = and encrypted request objects to the AS, i.e. it provides an = interoperable way to use request objects managed at the AS for use cases = requiring an even higher security level. >=20 > We look forward to getting your feedback.=20 >=20 > kind regards, > Torsten.=20 >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-lodderstedt-oauth-par-00.txt >> Date: 21. September 2019 at 12:47:28 CEST >> To: "Nat Sakimura" , "Brian Campbell" = , "Torsten Lodderstedt" = , "Dave Tonge" , "Filip Skokan" = >>=20 >>=20 >> A new version of I-D, draft-lodderstedt-oauth-par-00.txt >> has been successfully submitted by Torsten Lodderstedt and posted to = the >> IETF repository. >>=20 >> Name: draft-lodderstedt-oauth-par >> Revision: 00 >> Title: OAuth 2.0 Pushed Authorization Requests >> Document date: 2019-09-21 >> Group: Individual Submission >> Pages: 12 >> URL: = https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-par-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ >> Htmlized: = https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par >>=20 >>=20 >> Abstract: >> This document defines the pushed authorization request endpoint, >> which allows clients to push the payload of an OAuth 2.0 >> authorization request to the authorization server via a direct >> request and provides them with a request URI that is used as >> reference to the data in a subsequent authorization request. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7E0DB8C1-AF81-489A-9B0C-EF0F24F86AFE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA5MjMxODE3MDNaMC8GCSqGSIb3DQEJBDEiBCCl7qyIWMwzIv433JxDFULxyBIx2gbMHiPX dJ0lnL7ABTCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBADMdDVcI9En4a0aj7RkdlY7lIyZs0EGzXZB2R/p2D6M3EqcqTQVbile7Pbmy LJ4UW8DZd+Ym/5ldZpWCXAepGjmBjqomPj5zQgaxvR00K+Oj80aVANHokN1NQyh9xNapd+MxnIck yEckDGKIcVWAnY6oKMw2yY1rdH/j3WBMEwGN/ue2suP/6OAlb+MbP5fCr4Kk607mEjs5xsUkhIoF gSOejgKNmpPo3LANqM6pnkPG3MQC2CUeuztHRxkigZu4LI8EXkL4dsUjYRdFdfESd24GlytVK6XH +v20n0DvE5pGEk6M5/06M9FH1aj1CvadE443FE3abrZUSe8TeX3sKqQAAAAAAAA= --Apple-Mail=_7E0DB8C1-AF81-489A-9B0C-EF0F24F86AFE-- From nobody Mon Sep 23 11:22:30 2019 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 6BB8512095E for ; Mon, 23 Sep 2019 11:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 LGefjF418b13 for ; Mon, 23 Sep 2019 11:22:27 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 00D44120973 for ; Mon, 23 Sep 2019 11:22:26 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id z19so13675878ior.0 for ; Mon, 23 Sep 2019 11:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OfTmmJ20XFcX1x+tBm1esRzlzjBK89PGFn5m3Nr9iKg=; b=XFEf02pKArPbk4ky6E8MYbtyXpvTu8htIR9jQAlV68AsQUiwtMNX2hwqThpNNUNrc4 YsHxBCRFyuRDyCD272GSLgdvUmnbGMI86ccAa9PgIombNZpKEJbXZErOn2LIQUZknckk oPp69zssjPHJcbeN/SoRBQQdOwR8fh6aclxPs= 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=OfTmmJ20XFcX1x+tBm1esRzlzjBK89PGFn5m3Nr9iKg=; b=NV1lNCPWRULJ9Tc+7VxmQm3UAPFqIBrYHJJcjlp0LtnDzQ8qxe6KUXlpOVRdXxVGH8 VeDv3rKjEnhRPxTsMe0qg2gBji4aPF/JDzrV6xWKLKRrWwbaVsS1cRIQl251nGw9HwbP tI2JsYux0Fqd80gMYK62IeUOb/7cnLMF1rg9D1whFMRYnq4TqtBbQKGB+sbVET5zl2Iy wrI3m04zr3HLu7gIpSLqh/lwrXwlA9XA3IUdYObXbLwSlCFzJ5GT0CxPnXp8YdiIgEHd oLbDx+5ms6n4RL9CFmj6nAT2gZ6vpjUI2/IlQpstFpKX6gXBkVUAuXq5Jo99apOhvdJw eVeQ== X-Gm-Message-State: APjAAAXNn9SNapknknJAIwVBkc+gqFq/aSXpZ1RYS/ii33SnqZzM4v+v KTU0gRuHk047F6BGORcWWF9ky5+H3RFD/QPQLJlQSlQnb6U0VoRfAjCU6lo+8bZYQ3rsbckHKHV hBL6NGGzvXsIEoA== X-Google-Smtp-Source: APXvYqxpTsUkNB2oOjDfMOf+xmc7gj7mNtvjJM/1MAdumkMIEt+RoGF4KVAK3+1zPvOrSSZOAt+rgP5a4DppevxuefU= X-Received: by 2002:a6b:dc0b:: with SMTP id s11mr658571ioc.127.1569262946150; Mon, 23 Sep 2019 11:22:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Mon, 23 Sep 2019 12:22:00 -0600 Message-ID: To: Neil Madden Cc: oauth Content-Type: multipart/alternative; boundary="0000000000007707ea05933c8036" Archived-At: Subject: Re: [OAUTH-WG] Minor issue in https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08 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, 23 Sep 2019 18:22:30 -0000 --0000000000007707ea05933c8036 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That should probably be fixed unless the example was intended to be set nearly 48,000 years* in the future. * assuming my math is correct and you know the old saying about assuming On Sun, Sep 22, 2019 at 8:55 AM Neil Madden wrote: > Just noticed that the iat/exp claims in the example JWT response in > section 5 appear to be in milliseconds rather than the standard seconds. > > =E2=80=94 Neil > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000007707ea05933c8036 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That should probably be fixed unless the example was = intended to be set nearly 48,000 years* in the future.


* assuming my math is correct and you know the old = saying about assuming

On Sun, Sep 22, 2019 at 8:55 AM Neil Madden= <neil.madden@forgerock.com= > wrote:
= Just noticed that the iat/exp claims in the example JWT response in section= 5 appear to be in milliseconds rather than the standard seconds.

=E2=80=94 Neil
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000007707ea05933c8036-- From nobody Mon Sep 23 11:27:52 2019 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 397EE120020 for ; Mon, 23 Sep 2019 11:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 puES9dAaS37C for ; Mon, 23 Sep 2019 11:27:48 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) (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 D936B1200FA for ; Mon, 23 Sep 2019 11:27:47 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from ) id 1iCT3p-0005Wk-4G; Mon, 23 Sep 2019 20:27:45 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D2F461FB-C493-45E2-A925-A16D20CD219E"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 23 Sep 2019 20:27:44 +0200 In-Reply-To: Cc: Neil Madden , oauth To: Brian Campbell References: X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Minor issue in https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08 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, 23 Sep 2019 18:27:50 -0000 --Apple-Mail=_D2F461FB-C493-45E2-A925-A16D20CD219E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23. Sep 2019, at 20:22, Brian Campbell = wrote: >=20 > That should probably be fixed unless the example was intended to be = set nearly 48,000 years* in the future. >=20 >=20 > * assuming my math is correct and you know the old saying about = assuming=20 Haha. You both seem to have a bias towards examples, right? :-) I fixed the bug, but will be waiting for more feedback before I publish = the next revision. =20 Thanks! >=20 > On Sun, Sep 22, 2019 at 8:55 AM Neil Madden = wrote: > Just noticed that the iat/exp claims in the example JWT response in = section 5 appear to be in milliseconds rather than the standard seconds.=20= >=20 > =E2=80=94 Neil > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_D2F461FB-C493-45E2-A925-A16D20CD219E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA5MjMxODI3NDRaMC8GCSqGSIb3DQEJBDEiBCDZQ9FTuW1Ki/qEvH+imtVRAa2wjFeHVBk8 G21fBSJHfTCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBANVXS1h2ZxwXyi7mkTnp+znLZOiW1cIh4ovM1PCvE467Y16OOWyaMjULXMJ9 zBywiVKTYNDOfAE0Ux1XDYkfHWOsSJyBiFz5eJgBXPDc8zm6YFk+p1tCm7WvzC5H0/Xylt/0qc6P 8oiljIAJXvgZrb6GP6/PVSuvODYN27JAZSWLuJc6/LDuZj1MDDIniVUEEHE6dc+qY+aAljBGu4sx KscLKKlrNjJe1wrGwiMT056+7CagIOezEg5R+/nOkaU32uzgFWFjZfSxVGXE94//kJpJLGsmB+GG A7JnX2W+eOCxiBBQro65sNQf0vPpNIXoLKc3RmW9lGTVchKOS7iSKEYAAAAAAAA= --Apple-Mail=_D2F461FB-C493-45E2-A925-A16D20CD219E-- From nobody Mon Sep 23 11:46:10 2019 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 8E84F12085E for ; Mon, 23 Sep 2019 11:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 UPIEggye0fO8 for ; Mon, 23 Sep 2019 11:46:06 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 0019312082B for ; Mon, 23 Sep 2019 11:46:05 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id p7so11150580wmp.4 for ; Mon, 23 Sep 2019 11:46:05 -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=3i6YRLdXdNxnwg/zaM2tfVIAR5OIWwgubAqzpM34w0w=; b=dcN7HjhDP7Qazm68z3m/0HOUwTSUIjn7CGuq0HGYWdZoQDbUECETJa0nzte1Z++Vsu C4+538xqvCYScKAIETps7OTqHH9zj5k+U148mZoIgGq2ECLXDTLtFyyxXxvM7LxlnRjK nXEcVTDjS1xL6zrdk5VeMDAs8WtGFEf5tClSbsIXBsHEDCEREdc781v8umfyMFOmTxsq h9MXBKoNnk928zgUiQ1l2Y+cgtmQ4q4tgNTw3VxUUlkLqqWTJ5a+eNg6D6doOgRHS1jT 9qotEOkk9heqQNJq+gwz2Tm3W7MCQsW8UmC+bd/UJYpgs9krgFdP2KD5ND7V945RgGe6 PiKQ== 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=3i6YRLdXdNxnwg/zaM2tfVIAR5OIWwgubAqzpM34w0w=; b=F4rbj5EZ9qBKechWp1tGRVYcfc0m22kT/fbCNizq/eQtpxRw8UfVUE6DPtsh48byVT ylE86zvOlBr/JOHBD5mU5uV7QpmAf/hlFn7tyPofwCjBAU7hY2/ZZKGc5e6B9PjcE8FX BGMH0F4b0FvGCzR5DSe340mBnqBfBfVgtG0cMB0qDH/N5SDMiK9MCpjp1O1pDqON+2JM kxXMfDAnx5U2qjGIx5vAq0940oiqL22bzGQKXxrNDt0pqogYrxnB//La/U5MapGaUdEq RTSvCJzjjdIbbVsx7Hw9QwQ3fnEjMBGRaRBTSo1EVzKRQHUA7ntAMUbu/m8fk7Q6NWNV NXow== X-Gm-Message-State: APjAAAX9NvioeRouGnFu0KI8PX7obYvb0KPRWAkvx/LM541EQq2kM5Df 8RUNDeI5PXene57X8TXttbEhg4Z3RgMFBXO15EyrNQ== X-Google-Smtp-Source: APXvYqyIgtlkP66m7yKODIZxAS+wythWt+k057fHV7/YSk4oyOly9gW+PYQUnD0KTOVfh5wLOGqtQY9hfeAnwam2GZI= X-Received: by 2002:a05:600c:2252:: with SMTP id a18mr790533wmm.141.1569264364293; Mon, 23 Sep 2019 11:46:04 -0700 (PDT) MIME-Version: 1.0 References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> In-Reply-To: From: Janak Amarasena Date: Tue, 24 Sep 2019 00:15:31 +0530 Message-ID: To: Torsten Lodderstedt Cc: oauth , Filip Skokan Content-Type: multipart/alternative; boundary="000000000000fe2a7905933cd48f" Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt 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, 23 Sep 2019 18:46:09 -0000 --000000000000fe2a7905933cd48f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Why do you think so? This is because I feel that validating the authorization request is part of the authorization process and doing the validation is the responsibility of the authorization endpoint. I would assume the same core service is used to check the payload, so no > code duplication required. At the time what I meant was that the authorization request validation will be done twice. Once at the /as/par endpoint and again at the authorization endpoint. It also means the authorisation endpoint of the AS can safely assume all > request URIs sent in Authorization Request that are minted by the same AS > (which is detected based on its structure), are pre-checked and can be > trusted (regarding the input validation). I see, so if the authorization request is validated at the /as/par endpoint the validation can be omitted at the authorization endpoint if the request contains a "request_uri" (given that it belongs to the AS). If this is the case I think it might be good to mention this in the spec with something like "The authorization server MAY decided to omit the validation of the authorization request if the uri sent in the request_uri parameter belongs to the authorization server." WDYT? Best Regards, Janak Amarasena On Mon, Sep 23, 2019 at 11:47 PM Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Janak, > > thanks for your feedback to PAR as well. > > > On 22. Sep 2019, at 21:51, Janak Amarasena > wrote: > > > > Hi, > > > > Since the /as/par endpoint is intended to be used to store the actual > authorization request I feel that validating the authorization request as > mentioned in point 2 section 2.1(Request) should not be a responsibility = of > the /as/par endpoint and that it should not validate the authorization > request. > > Why do you think so? > > Validating the request data at the pushed authorisation request endpoint > has the advantage that the AS can refuse the process early. It also means > the authorisation endpoint of the AS can safely assume all request URIs > sent in Authorization Request that are minted by the same AS (which is > detected based on its structure), are pre-checked and can be trusted > (regarding the input validation). > > > Also, the majority case could be the endpoint receiving valid requests > and the validation process will be duplicated at the authorization endpoi= nt. > > I would assume the same core service is used to check the payload, so no > code duplication required. > > > > > Also since section 2.2 (Successful Response) states; > > The "request URI" MUST be bound to the "client_id" of the client that > posted the authorization request. > > Wouldn't it be good to enforce the use of the clientId in section 4 > (Authorization Request) when the authorization request is made with the > "request_uri" parameter? > > GET > /authorize?request_uri=3Durn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2&clie= nt_id=3Ds6BhdRkqt3 > HTTP/1.1 > > There is no need for an additional client id since the request URI is > already bound to the client_id passed to and, in case of a confidential > client, authenticated in the pushed authorization request. > > best regards, > Torsten. > > > > > > > Best Regards, > > Janak Amarasena > > > > On Sat, Sep 21, 2019 at 4:32 PM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Hi all, > > > > I just published a new draft that Brian Campbell, Dave Tonge, Filip > Skokan, Nat Sakimura and I wrote. > > > > https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 > > > > It proposes a new endpoint, called "pushed authorization request > endpoint=E2=80=9D, that allows the client to push the Authorization Reque= st payload > with the AS on a backchannel connection instead of a front channel > interaction. The AS provides the client with a request URI (according to > draft-ietf-oauth-jwsreq) that the client uses in a subsequent authorizati= on > requests to refer to the pushed request data. > > > > We believe this simple mechanism will significantly increase OAuth > security and robustness since any application can use it by just sending > the parameters in the same encoding as used at the authorisation endpoint > over a HTTPS-protected and (for confidential clients) mutually > authenticated connection to the AS. It can also be used to push signed an= d > encrypted request objects to the AS, i.e. it provides an interoperable wa= y > to use request objects managed at the AS for use cases requiring an even > higher security level. > > > > We look forward to getting your feedback. > > > > kind regards, > > Torsten. > > > >> Begin forwarded message: > >> > >> From: internet-drafts@ietf.org > >> Subject: New Version Notification for draft-lodderstedt-oauth-par-00.t= xt > >> Date: 21. September 2019 at 12:47:28 CEST > >> To: "Nat Sakimura" , "Brian Campbell" < > bcampbell@pingidentity.com>, "Torsten Lodderstedt" < > torsten@lodderstedt.net>, "Dave Tonge" , "Filip Skokan" < > panva.ip@gmail.com> > >> > >> > >> A new version of I-D, draft-lodderstedt-oauth-par-00.txt > >> has been successfully submitted by Torsten Lodderstedt and posted to t= he > >> IETF repository. > >> > >> Name: draft-lodderstedt-oauth-par > >> Revision: 00 > >> Title: OAuth 2.0 Pushed Authorization Requests > >> Document date: 2019-09-21 > >> Group: Individual Submission > >> Pages: 12 > >> URL: > https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-par-00.txt > >> Status: > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ > >> Htmlized: > https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 > >> Htmlized: > https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par > >> > >> > >> Abstract: > >> This document defines the pushed authorization request endpoint, > >> which allows clients to push the payload of an OAuth 2.0 > >> authorization request to the authorization server via a direct > >> request and provides them with a request URI that is used as > >> reference to the data in a subsequent authorization request. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> The IETF Secretariat > >> > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > --000000000000fe2a7905933cd48f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Why do you think so?=C2=A0=C2=A0

This is because I feel that validating the authorization request is part o= f the authorization process and doing the validation is the responsibility= =C2=A0of the authorization endpoint.
=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">I would assume the same co= re service is used to check the payload, so no code duplication required.

At the time what I meant was that the author= ization request validation will be done twice. Once at the /as/par endpoint= and again at the authorization endpoint.=C2=A0


It also = means the authorisation endpoint of the AS can safely assume all request UR= Is sent in Authorization Request that are minted by the same AS (which is d= etected based on its structure), are pre-checked and can be trusted (regard= ing the input validation).=C2=A0=C2=A0=C2=A0

I see, so if the authorization request is validated at the /as/par endpoi= nt the validation can be omitted at the authorization endpoint=C2=A0if the = request contains a=C2=A0"request_uri" (gi= ven that it belongs to the AS). If this=C2=A0is the case I think it might be good to men= tion this in the spec with something like "The authorization server MA= Y decided to omit the validation of the authorization request if the uri se= nt in the=C2=A0request_uri parameter belongs to the authorization se= rver." WDYT?
= =C2=A0

Best Regards,
Janak Amarasena

On Mon, Sep 23, 2019 at 11:47 PM Torsten Lodderstedt <torsten@lodderstedt.net>= ; wrote:
Hi Jana= k,

thanks for your feedback to PAR as well.

> On 22. Sep 2019, at 21:51, Janak Amarasena <janakama360@gmail.com> wrote: >
> Hi,
>
> Since the /as/par endpoint is intended to be used to store the actual = authorization request I feel that validating the authorization request as m= entioned in point 2 section 2.1(Request) should not be a responsibility of = the /as/par endpoint and that it should not validate the authorization requ= est.

Why do you think so?

Validating the request data at the pushed authorisation request endpoint ha= s the advantage that the AS can refuse the process early. It also means the= authorisation endpoint of the AS can safely assume all request URIs sent i= n Authorization Request that are minted by the same AS (which is detected b= ased on its structure), are pre-checked and can be trusted (regarding the i= nput validation).=C2=A0

> Also, the majority case could be the endpoint receiving valid requests= and the validation process will be duplicated at the authorization endpoin= t.

I would assume the same core service is used to check the payload, so no co= de duplication required.

>
> Also since section 2.2 (Successful Response) states;
> The "request URI" MUST be bound to the "client_id"= of the client that posted the authorization request.
> Wouldn't it be good to enforce the use of the clientId in section = 4 (Authorization Request) when the authorization request is made with the &= quot;request_uri" parameter?
> GET /authorize?request_uri=3Durn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LT= C2&client_id=3Ds6BhdRkqt3 HTTP/1.1

There is no need for an additional client id since the request URI is alrea= dy bound to the client_id passed to and, in case of a confidential client, = authenticated in the pushed authorization request.

best regards,
Torsten.

>
>
> Best Regards,
> Janak Amarasena
>
> On Sat, Sep 21, 2019 at 4:32 PM Torsten Lodderstedt <torsten@lodderstedt.net&= gt; wrote:
> Hi all,
>
> I just published a new draft that Brian Campbell, Dave Tonge, Filip Sk= okan, Nat Sakimura and I wrote.
>
> https://tools.ietf.org/html/draft-lod= derstedt-oauth-par-00
>
> It proposes a new endpoint, called "pushed authorization request = endpoint=E2=80=9D, that allows the client to push the Authorization Request= payload with the AS on a backchannel connection instead of a front channel= interaction. The AS provides the client with a request URI (according to d= raft-ietf-oauth-jwsreq) that the client uses in a subsequent authorization = requests to refer to the pushed request data.
>
> We believe this simple mechanism will significantly increase OAuth sec= urity and robustness since any application can use it by just sending the p= arameters in the same encoding as used at the authorisation endpoint over a= HTTPS-protected and (for confidential clients) mutually authenticated conn= ection to the AS. It can also be used to push signed and encrypted request = objects to the AS, i.e. it provides an interoperable way to use request obj= ects managed at the AS for use cases requiring an even higher security leve= l.
>
> We look forward to getting your feedback.
>
> kind regards,
> Torsten.
>
>> Begin forwarded message:
>>
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for draft-lodderstedt-oauth-par-= 00.txt
>> Date: 21. September 2019 at 12:47:28 CEST
>> To: "Nat Sakimura" <nat@sakimura.org>, "Brian Campbell" &= lt;bcampbel= l@pingidentity.com>, "Torsten Lodderstedt" <torsten@lodderstedt.net>, "Dave Tonge" <dave@tonge.org>, "Filip Skokan" <panva.ip@gmail.com> >>
>>
>> A new version of I-D, draft-lodderstedt-oauth-par-00.txt
>> has been successfully submitted by Torsten Lodderstedt and posted = to the
>> IETF repository.
>>
>> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft= -lodderstedt-oauth-par
>> Revision:=C2=A0 =C2=A0 00
>> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth= 2.0 Pushed Authorization Requests
>> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A02019-09-21
>> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Indiv= idual Submission
>> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A012 >> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-lodder= stedt-oauth-par-00.txt
>> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/
>> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00
>> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-p= ar
>>
>>
>> Abstract:
>>=C2=A0 =C2=A0This document defines the pushed authorization request= endpoint,
>>=C2=A0 =C2=A0which allows clients to push the payload of an OAuth 2= .0
>>=C2=A0 =C2=A0authorization request to the authorization server via = a direct
>>=C2=A0 =C2=A0request and provides them with a request URI that is u= sed as
>>=C2=A0 =C2=A0reference to the data in a subsequent authorization re= quest.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of = submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

--000000000000fe2a7905933cd48f-- From nobody Mon Sep 23 12:40:45 2019 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 8C49E1200DB for ; Mon, 23 Sep 2019 12:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.026, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 MKRLib21WK-U for ; Mon, 23 Sep 2019 12:40:37 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) (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 7CDAF120020 for ; Mon, 23 Sep 2019 12:40:37 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.102]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from ) id 1iCUCH-0002M1-Ji; Mon, 23 Sep 2019 21:40:33 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-4916AC0A-98DB-46C3-9DD3-66F46B61435F; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Mon, 23 Sep 2019 21:40:32 +0200 Message-Id: References: Cc: oauth , Filip Skokan In-Reply-To: To: Janak Amarasena X-Mailer: iPhone Mail (17A577) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt 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, 23 Sep 2019 19:40:43 -0000 --Apple-Mail-4916AC0A-98DB-46C3-9DD3-66F46B61435F Content-Type: multipart/alternative; boundary=Apple-Mail-06B72945-8AAC-4B7D-90B8-D4FA8F185608 Content-Transfer-Encoding: 7bit --Apple-Mail-06B72945-8AAC-4B7D-90B8-D4FA8F185608 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 23.09.2019 um 20:46 schrieb Janak Amarasena : >=20 > =EF=BB=BF > Hi, >=20 >> Why do you think so? =20 >=20 > This is because I feel that validating the authorization request is part o= f the authorization process and doing the validation is the responsibility o= f the authorization endpoint. > =20 >=20 >> I would assume the same core service is used to check the payload, so no c= ode duplication required. >=20 > At the time what I meant was that the authorization request validation wil= l be done twice. Once at the /as/par endpoint and again at the authorization= endpoint.=20 >=20 >=20 >> It also means the authorisation endpoint of the AS can safely assume all r= equest URIs sent in Authorization Request that are minted by the same AS (wh= ich is detected based on its structure), are pre-checked and can be trusted (= regarding the input validation). =20 >=20 > I see, so if the authorization request is validated at the /as/par endpoin= t the validation can be omitted at the authorization endpoint if the request= contains a "request_uri" (given that it belongs to the AS). If this is the c= ase I think it might be good to mention this in the spec with something like= "The authorization server MAY decided to omit the validation of the authori= zation request if the uri sent in the request_uri parameter belongs to the a= uthorization server." WDYT? WFM > =20 >=20 > Best Regards, > Janak Amarasena >=20 >> On Mon, Sep 23, 2019 at 11:47 PM Torsten Lodderstedt wrote: >> Hi Janak, >>=20 >> thanks for your feedback to PAR as well.=20 >>=20 >> > On 22. Sep 2019, at 21:51, Janak Amarasena wrot= e: >> >=20 >> > Hi, >> >=20 >> > Since the /as/par endpoint is intended to be used to store the actual a= uthorization request I feel that validating the authorization request as men= tioned in point 2 section 2.1(Request) should not be a responsibility of the= /as/par endpoint and that it should not validate the authorization request.= >>=20 >> Why do you think so? >>=20 >> Validating the request data at the pushed authorisation request endpoint h= as the advantage that the AS can refuse the process early. It also means the= authorisation endpoint of the AS can safely assume all request URIs sent in= Authorization Request that are minted by the same AS (which is detected bas= ed on its structure), are pre-checked and can be trusted (regarding the inpu= t validation). =20 >>=20 >> > Also, the majority case could be the endpoint receiving valid requests a= nd the validation process will be duplicated at the authorization endpoint. >>=20 >> I would assume the same core service is used to check the payload, so no c= ode duplication required. >>=20 >> >=20 >> > Also since section 2.2 (Successful Response) states; >> > The "request URI" MUST be bound to the "client_id" of the client that p= osted the authorization request. >> > Wouldn't it be good to enforce the use of the clientId in section 4 (Au= thorization Request) when the authorization request is made with the "reques= t_uri" parameter? >> > GET /authorize?request_uri=3Durn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC= 2&client_id=3Ds6BhdRkqt3 HTTP/1.1 >>=20 >> There is no need for an additional client id since the request URI is alr= eady bound to the client_id passed to and, in case of a confidential client,= authenticated in the pushed authorization request. >>=20 >> best regards, >> Torsten. >>=20 >> >=20 >> >=20 >> > Best Regards, >> > Janak Amarasena >> >=20 >> > On Sat, Sep 21, 2019 at 4:32 PM Torsten Lodderstedt wrote: >> > Hi all,=20 >> >=20 >> > I just published a new draft that Brian Campbell, Dave Tonge, Filip Sko= kan, Nat Sakimura and I wrote.=20 >> >=20 >> > https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 >> >=20 >> > It proposes a new endpoint, called "pushed authorization request endpoi= nt=E2=80=9D, that allows the client to push the Authorization Request payloa= d with the AS on a backchannel connection instead of a front channel interac= tion. The AS provides the client with a request URI (according to draft-ietf= -oauth-jwsreq) that the client uses in a subsequent authorization requests t= o refer to the pushed request data.=20 >> >=20 >> > We believe this simple mechanism will significantly increase OAuth secu= rity and robustness since any application can use it by just sending the par= ameters in the same encoding as used at the authorisation endpoint over a HT= TPS-protected and (for confidential clients) mutually authenticated connecti= on to the AS. It can also be used to push signed and encrypted request objec= ts to the AS, i.e. it provides an interoperable way to use request objects m= anaged at the AS for use cases requiring an even higher security level. >> >=20 >> > We look forward to getting your feedback.=20 >> >=20 >> > kind regards, >> > Torsten.=20 >> >=20 >> >> Begin forwarded message: >> >>=20 >> >> From: internet-drafts@ietf.org >> >> Subject: New Version Notification for draft-lodderstedt-oauth-par-00.t= xt >> >> Date: 21. September 2019 at 12:47:28 CEST >> >> To: "Nat Sakimura" , "Brian Campbell" , "Torsten Lodderstedt" , "Dave Tonge= " , "Filip Skokan" >> >>=20 >> >>=20 >> >> A new version of I-D, draft-lodderstedt-oauth-par-00.txt >> >> has been successfully submitted by Torsten Lodderstedt and posted to t= he >> >> IETF repository. >> >>=20 >> >> Name: draft-lodderstedt-oauth-par >> >> Revision: 00 >> >> Title: OAuth 2.0 Pushed Authorization Requests >> >> Document date: 2019-09-21 >> >> Group: Individual Submission >> >> Pages: 12 >> >> URL: https://www.ietf.org/internet-drafts/draft-lodderstedt= -oauth-par-00.txt >> >> Status: https://datatracker.ietf.org/doc/draft-lodderstedt-oau= th-par/ >> >> Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-pa= r-00 >> >> Htmlized: https://datatracker.ietf.org/doc/html/draft-loddersted= t-oauth-par >> >>=20 >> >>=20 >> >> Abstract: >> >> This document defines the pushed authorization request endpoint, >> >> which allows clients to push the payload of an OAuth 2.0 >> >> authorization request to the authorization server via a direct >> >> request and provides them with a request URI that is used as >> >> reference to the data in a subsequent authorization request. >> >>=20 >> >>=20 >> >>=20 >> >>=20 >> >> Please note that it may take a couple of minutes from the time of subm= ission >> >> until the htmlized version and diff are available at tools.ietf.org. >> >>=20 >> >> The IETF Secretariat >> >>=20 >> >=20 >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >>=20 --Apple-Mail-06B72945-8AAC-4B7D-90B8-D4FA8F185608 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Am 23.09.2019 um 20:46 schrieb Janak Amarasen= a <janakama360@gmail.com>:

=EF=BB=BF
Hi,

Why do you think so?  

This is because I feel that validating the auth= orization request is part of the authorization process and doing the validat= ion is the responsibility of the authorization endpoint.
&nbs= p;

I wo= uld assume the same core service is used to check the payload, so no code du= plication required.

At the time what I meant= was that the authorization request validation will be done twice. Once at t= he /as/par endpoint and again at the authorization endpoint. 
=


It also means the authorisation endpoint of the AS can safely assume a= ll request URIs sent in Authorization Request that are minted by the same AS= (which is detected based on its structure), are pre-checked and can be trus= ted (regarding the input validation).   
I see, so if the authorization request is validated at the /as/p= ar endpoint the validation can be omitted at the authorization endpoint = ;if the request contains a "request_uri" (given= that it belongs to the AS). If this is the case I think it might be good to mention t= his in the spec with something like "The authorization server MAY decided to= omit the validation of the authorization request if the uri sent in the&nbs= p;request_uri parameter belongs to the authorization server." WDYT?
<= div>
WFM

 

Best Regards,
Janak= Amarasena

On Mon, Sep 23, 2019 at 11:47 PM Torsten Lodderstedt <torsten@lodderstedt.n= et> wrote:
= Hi Janak,

thanks for your feedback to PAR as well.

> On 22. Sep 2019, at 21:51, Janak Amarasena <janakama360@gmail.com> wrote:
>
> Hi,
>
> Since the /as/par endpoint is intended to be used to store the actual a= uthorization request I feel that validating the authorization request as men= tioned in point 2 section 2.1(Request) should not be a responsibility of the= /as/par endpoint and that it should not validate the authorization request.=

Why do you think so?

Validating the request data at the pushed authorisation request endpoint has= the advantage that the AS can refuse the process early. It also means the a= uthorisation endpoint of the AS can safely assume all request URIs sent in A= uthorization Request that are minted by the same AS (which is detected based= on its structure), are pre-checked and can be trusted (regarding the input v= alidation). 

> Also, the majority case could be the endpoint receiving valid requests a= nd the validation process will be duplicated at the authorization endpoint.<= br>
I would assume the same core service is used to check the payload, so no cod= e duplication required.

>
> Also since section 2.2 (Successful Response) states;
> The "request URI" MUST be bound to the "client_id" of the client that p= osted the authorization request.
> Wouldn't it be good to enforce the use of the clientId in section 4 (Au= thorization Request) when the authorization request is made with the "reques= t_uri" parameter?
> GET /authorize?request_uri=3Durn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC= 2&client_id=3Ds6BhdRkqt3 HTTP/1.1

There is no need for an additional client id since the request URI is alread= y bound to the client_id passed to and, in case of a confidential client, au= thenticated in the pushed authorization request.

best regards,
Torsten.

>
>
> Best Regards,
> Janak Amarasena
>
> On Sat, Sep 21, 2019 at 4:32 PM Torsten Lodderstedt <torsten@lodderstedt.net>= ; wrote:
> Hi all,
>
> I just published a new draft that Brian Campbell, Dave Tonge, Filip Sko= kan, Nat Sakimura and I wrote.
>
> https://tools.ietf.org/html/draft-lodder= stedt-oauth-par-00
>
> It proposes a new endpoint, called "pushed authorization request endpoi= nt=E2=80=9D, that allows the client to push the Authorization Request payloa= d with the AS on a backchannel connection instead of a front channel interac= tion. The AS provides the client with a request URI (according to draft-ietf= -oauth-jwsreq) that the client uses in a subsequent authorization requests t= o refer to the pushed request data.
>
> We believe this simple mechanism will significantly increase OAuth secu= rity and robustness since any application can use it by just sending the par= ameters in the same encoding as used at the authorisation endpoint over a HT= TPS-protected and (for confidential clients) mutually authenticated connecti= on to the AS. It can also be used to push signed and encrypted request objec= ts to the AS, i.e. it provides an interoperable way to use request objects m= anaged at the AS for use cases requiring an even higher security level.
>
> We look forward to getting your feedback.
>
> kind regards,
> Torsten.
>
>> Begin forwarded message:
>>
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for draft-lodderstedt-oauth-par-0= 0.txt
>> Date: 21. September 2019 at 12:47:28 CEST
>> To: "Nat Sakimura" <nat@sakimura.org>, "Brian Campbell" <bcampbell@pingidentity.com&g= t;, "Torsten Lodderstedt" <torsten@lodderstedt.net>, "Dave Tonge" <dave@tonge.org>, "Filip Skok= an" <panva.ip@gma= il.com>
>>
>>
>> A new version of I-D, draft-lodderstedt-oauth-par-00.txt
>> has been successfully submitted by Torsten Lodderstedt and posted t= o the
>> IETF repository.
>>
>> Name:                draft-= lodderstedt-oauth-par
>> Revision:    00
>> Title:               OAuth 2= .0 Pushed Authorization Requests
>> Document date:       2019-09-21
>> Group:               Indivi= dual Submission
>> Pages:               12
= >> URL:            https://www.ietf.org/internet-drafts/draft-lodderste= dt-oauth-par-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ >> Htmlized:       https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par
>>
>>
>> Abstract:
>>   This document defines the pushed authorization request e= ndpoint,
>>   which allows clients to push the payload of an OAuth 2.= 0
>>   authorization request to the authorization server via a= direct
>>   request and provides them with a request URI that is us= ed as
>>   reference to the data in a subsequent authorization req= uest.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of s= ubmission
>> until the htmlized version and diff are available at tools.ietf.org.=
>>
>> The IETF Secretariat
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org<= br> > https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail-06B72945-8AAC-4B7D-90B8-D4FA8F185608-- --Apple-Mail-4916AC0A-98DB-46C3-9DD3-66F46B61435F Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCn8w ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJ KoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAe Fw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5A bG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9 SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHB qVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8v tTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHc kVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZ eYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7Gfx wqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAM BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhC AQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21v ZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2Eu Y29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVu QGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcv jCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7IS YQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy 4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxv T5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4 ImVnZ6WvgzGCA88wggPLAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8 BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwOTIzMTk0MDMyWjAvBgkqhkiG9w0BCQQxIgQg 0D/0DRwbvLg26Lsh06gyyw9CHrP+c5p24RERaYoSig4wgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0 MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAG6QDQReDPP8w4lC NNN3fYfmj9e9HhMG992s2eEmrt9a1g35s9ysHElzwq6RgDdzbPRbft5tqY8PqHQDlsOW3zdkhqlU BVnYOSaTl/2+PEEUlyiJ/qljpTqmZCIP5Qz6P8sPirtLG6sd54lfjJKR4yn7yGF/KwLoxbGIBXak G8jK58DEk0v4VRKNMXjLZWwfXMSknNS1faeVqOyAcmk1ci9PVDA9s+hkpEzqFsCO6AsGQDItZs70 2MAhm1lo8YfCvsXTVWmISGzvaLmJ4xtSli+PW9AgrGCYosrDsr9vwE1FyDgUgq3Xn9ZTWhaQZM3D YQvucr6nHiLU5jwRewZMCG4AAAAAAAA= --Apple-Mail-4916AC0A-98DB-46C3-9DD3-66F46B61435F-- From nobody Mon Sep 23 12:52:31 2019 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 C0E321208B9 for ; Mon, 23 Sep 2019 12:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Q-lMuZoQJ75J for ; Mon, 23 Sep 2019 12:52:27 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 B2D521208DE for ; Mon, 23 Sep 2019 12:52:25 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id a6so11307384wma.5 for ; Mon, 23 Sep 2019 12:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:date:subject:message-id :cc:to; bh=QIPU+Vwl7GtV6SgoZpEazk95VYV4ex2yYxaX0fVrPT4=; b=jdbfpmoW9k6uEqHoZp3AKsFbcBrYYEPnNTX+OLEo0sclXaTynAthXSyB/epvLseq61 AdtlhiGRozvicYAlZS+0wJBSKR+DCWM8qSJRgty5p7q7pJE0cJKG3umBjuC5uCoES5wL or3BU8nRgLeMM191XQNlydwpHz9ZHYYxIogxdP5YbFUxBaZMTIt5FnCi16WIFfIOEk9T k0zD1jhQOx5iC50HVhX5lttr5N0bSyXz0YPrbqFBg4oKBxRYCTyOFHZc9z/DIIHkj+sq CQbtuhA9o/eavmwvW1478elXkIL3dqQy7lB6JlGtHi7SCnrrxKVORmNJ2kHdkxa5+3fX Kmpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:cc:to; bh=QIPU+Vwl7GtV6SgoZpEazk95VYV4ex2yYxaX0fVrPT4=; b=WgqJg+NN6j2A5qbuzWvExjBXSa/tW+52RtjMgMH+UlX28GZtXIrcZawc4mVPwC0/C+ RyunBUJk4YHssjFvL1o+a6hEYTdWf/Jr43kRO1rf46otQ0FHjecPZQoENtPtV9QfcB6o bbkjWFCYjLpVwlcgMc3gHV3I3gi+eJ4sKpPKC4U8EeTx+w2og+vd+fDBzX5HWQFJf1P0 d0quZEEPoeRIS5QjebC7NSrpnOcY+Sta2JrCYZqNj0miGgwJLkgIGQflrINCBIlOV5pC 257V8TT7Ea1bS4kUmq9X8yIydmElWgmTjcz/Ayb3YIbGgbJeGNSPS6wCPPeD3X1/rVUR vsSA== X-Gm-Message-State: APjAAAXVtB82yPbArUx0Ink8SYnNSUUnf6ifvvNUYH3J8gpwfnKUX+c7 8vhbqUWCQqHU7WLGMYhY7g== X-Google-Smtp-Source: APXvYqx90xS34zTK/nHoGbrqX9HHGhy8B4H7BQPBGIT5kjExzCVc4CON7xu0K+FIg1DA5XuIx8iiOw== X-Received: by 2002:a1c:7c10:: with SMTP id x16mr888244wmc.175.1569268344191; Mon, 23 Sep 2019 12:52:24 -0700 (PDT) Received: from [192.168.0.178] (ip-78-45-222-80.net.upcbroadband.cz. [78.45.222.80]) by smtp.gmail.com with ESMTPSA id m18sm17214045wrg.97.2019.09.23.12.52.23 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 23 Sep 2019 12:52:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Filip Skokan Mime-Version: 1.0 (1.0) Date: Mon, 23 Sep 2019 21:52:22 +0200 Message-Id: Cc: Torsten Lodderstedt , oauth To: Janak Amarasena X-Mailer: iPhone Mail (17A577) Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt 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, 23 Sep 2019 19:52:29 -0000 I find this to be an implementation detail, an optimization. As a matter of f= act depending on the Request Object flavor the AS implements a second round o= f validation may be required. Odesl=C3=A1no z iPhonu > 23. 9. 2019 v 20:46, Janak Amarasena : >=20 From nobody Mon Sep 23 23:03:30 2019 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 9B240120144 for ; Mon, 23 Sep 2019 23:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 xcgXSNvb7tiB for ; Mon, 23 Sep 2019 23:03:26 -0700 (PDT) Received: from p3plsmtpa12-04.prod.phx3.secureserver.net (p3plsmtpa12-04.prod.phx3.secureserver.net [68.178.252.233]) (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 56C8E120113 for ; Mon, 23 Sep 2019 23:03:26 -0700 (PDT) Received: from [192.168.0.103] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id Cdv1iwWEv450OCdv2i53XL; Mon, 23 Sep 2019 23:03:24 -0700 To: oauth@ietf.org References: <156898250596.30287.14524104153595179086@ietfa.amsl.com> From: Vladimir Dzhuvinov Openpgp: preference=signencrypt Organization: Connect2id Ltd. Message-ID: Date: Tue, 24 Sep 2019 09:03:22 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <156898250596.30287.14524104153595179086@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-CMAE-Envelope: MS4wfJ6eXrSBP1LXOjzBUTfJZ/cV6uKVwxiqOQUMkXdsJ3vhZeD+lhsi4DrWRv/swdUrD71+FHLqD8oOuQgAfZv9HQe6rcTdI0wL9jqs9lAoEwdB1cpRJYIM Ft7gbPSYip6tJLM408Q3fQhxRN3VKywECUA+g4puY6A83tL7zBpOHh3p Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt 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: Tue, 24 Sep 2019 06:03:28 -0000 When implementing 08 a question came up: * The token has multiple audiences (aud), e.g ["rs1", "rs2", "rs3"]. * The RS "rs1" is in the expected audience. Are there any considerations (privacy, etc) about returning the full audience list ["rs1", "rs2", "rs3"] in the introspection response? Theoretically, the RS shouldn't be interested which other RSs may legally consume the token, so those may be excluded from the list, returning only ["rs1"]? Vladimir From nobody Tue Sep 24 02:49:04 2019 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 9DE26120825 for ; Tue, 24 Sep 2019 02:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GhlQOHpFRmsz for ; Tue, 24 Sep 2019 02:48:55 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) (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 00449120043 for ; Tue, 24 Sep 2019 02:48:54 -0700 (PDT) Received: from [80.155.34.3] (helo=[10.3.21.206]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from ) id 1iChRD-0004nP-Q2; Tue, 24 Sep 2019 11:48:51 +0200 From: Torsten Lodderstedt Message-Id: <83C409C4-3B36-466C-9C49-28A6C9C8A722@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_90EE9B8F-BFBF-4540-8FA1-84E469539D41"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 24 Sep 2019 11:48:51 +0200 In-Reply-To: Cc: oauth@ietf.org To: Vladimir Dzhuvinov References: <156898250596.30287.14524104153595179086@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt 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: Tue, 24 Sep 2019 09:48:58 -0000 --Apple-Mail=_90EE9B8F-BFBF-4540-8FA1-84E469539D41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Vladimir, > On 24. Sep 2019, at 08:03, Vladimir Dzhuvinov = wrote: >=20 > When implementing 08 a question came up: >=20 > * The token has multiple audiences (aud), e.g ["rs1", "rs2", "rs3"]. >=20 > * The RS "rs1" is in the expected audience. >=20 > Are there any considerations (privacy, etc) about returning the full > audience list ["rs1", "rs2", "rs3"] in the introspection response? > Theoretically, the RS shouldn't be interested which other RSs may > legally consume the token, so those may be excluded from the list, > returning only ["rs1=E2=80=9D] =46rom a privacy perspective, I would expect the AS to reduce the data = to the minimum required for the particular RS. In your case, the AS = should narrow down the audience to ["rs1=E2=80=9D]. =46rom a security perspective, this also reduces the risk for replay at = other RSs. = https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08= #section-8.1 best regards, Torsten.=20 > ? >=20 > Vladimir >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_90EE9B8F-BFBF-4540-8FA1-84E469539D41 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA5MjQwOTQ4NTFaMC8GCSqGSIb3DQEJBDEiBCCMAe6UgVWtX1q/ANhi3bYQaXkZ1F9lIVnC oBJZCFBWmzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBANJ9Y9J0sgklsrI0D45UfZ9nQr3OCzrw3rJhVsmWjq4g738EmnPmXAkMRoZP CMiWHV2m5uQznIm3jLv7RUHtmGcS5MShafJi+dXh9MSmLPA5gqcysP41QcGbvvTPVSRHrTPF2J5g RQY7TWvI8WU7uprrF/iMiJmFN/y0kAayXu/ENpuZbUFowh8aZom3npZp+m/FcPUmh7Ls0x56wZVF qW36m0B+iGWQkdTdQyQfPUp3MuSdCE30Ee3oL2A0TijbfTdBVF/zHyYE2RPGcMcBVD7OOwN5HFfp wBhF43HFBFvtyS3kNKUALk9CK+yFK0Cg/XN0lPXvknD+Bo+Ux9tS3EYAAAAAAAA= --Apple-Mail=_90EE9B8F-BFBF-4540-8FA1-84E469539D41-- From nobody Tue Sep 24 13:45:52 2019 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 D72A412004E for ; Tue, 24 Sep 2019 13:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=aol.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 reTsKRTgxeGk for ; Tue, 24 Sep 2019 13:45:47 -0700 (PDT) Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (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 9FB38120058 for ; Tue, 24 Sep 2019 13:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1569357946; bh=W11yn813CCvWx8luLxsxoPTxLop6St02vKyqRoNRK6w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=Ili7xtdDPdh44JZGHVH1ZcSTcpE0uOyv/Mw2uYTVWs+g2lqmKL1GsLnqXSHQSGnXvLX5F/A8PY28b7DEpSf203r66ofZv0VKkKC7u/wRVS64BMCYsoRsGnxKt+IkRWyjlTC568msYGRHhpqKfyIgnzYy1s/yaKU+sKgd1XSthMHitaZ8Q0paHlOauN7MNCfJ9y6KiyTE+QsFcT4A/qVMLz3Q8/F20kfMAP7MyC0IxyiSPp1IMEm7XPqNunDPz4sl5SbjjX0E3MOBPfrjt/hQsHk+dcwtX80RjRYk9X4pRK8jJtW0Q/ff1iyWOLRgDQjhNy7ejmCI3rT0/XeEMkqAAw== X-YMail-OSG: xwATUbUVM1nQnBtim2DAt6rVYxD7ckRYj.fPx.c_3LX827ooZ_9vSzvsj6IhoUZ Ei2jIFe2gBT38XUckzaj_elCz8J48UtubPBgvVPs98xn355LWU2fS4AwhVwE_ps2bK1DJhUwBiPM v8IKir2AdN6k02BAwaMYqvB3ny1UMYU16k7xGO5QWmbn0mHEpi6.A6DO2TXJLmGYUYXjKpbd0SGm 2Gyzq7xmYwMHlA9IjFcN8d6nkpyXoMIiUN.Cspy5KIXWCz8cRwMl6MNCaIyWmPCxxSjIuGnhxXpa P2ESmaD6ix6dwfLRMUgjvT4IPIK7lKrR.NLVs3Uoh4Gg6a8X3VjtL0267Lwb_KCdsT8VsEFmUixG C5cB.afAmMOYXym9ywmEoxgSJIdro2HbW09EN.chUBUKAnSAbHCiGZAH3dUh3hJ6jNGpHEohFGbN JOMEeuHh6V8KBvzrVkwEVQghDd_FpDAUhxRREaKnEIG83OuhoPvepFfr3UZshKcKqSpwmbLOaWvQ NPpuxKV13W34Q6kwIU88UVkpu.2Xhmw85dbqngOV5zJ6dxMALxcZgOBqsUYadlBHizzIrJn.NJ6P M_WEL9sx5pV95WUDF3i3tFQPi2xna5WbV5uk36r66jXz6fOg0bhG0omolN_CAeZi29ThsOR2QJmd MhZyao_laQXDUo_dcKYgtGbC2vFBZswsRfictmTaHTTaLHmqooGpN0wRp7VrbGIRPOGfjQVqH4AS 38eyg6CAGLdO.M2bPU3vYMnOqI0xYRW93oeP_T4FbP0X_s4AmZICkdN.SPch5MSCDoBmtLPnTRHf waCh1gfCZJyuNO_wOQSTpf.QeBiutX_6GS658LcrzKM0rKwGFBU9zP1Y5am8ISSamY.6Nt61Blfi uefO0vtj.YpYW6xnwndN_I3YpBEnw91oBfxzVW7Zza.Ou1pIAQtvhK0ZrameXfAEp4OmVMJ_J0XC cD6J15qmQC7mGIPP_vfpaeejbD1JEIAPqC0sA0hpRseBgVfehITdSBWLA8grh5EgME79d7rSGgyg Bf5JE_owzryDWmUWtRtiQjiZTM8s_6avu05.WAKGffKCX4zz_adgAxWa1WA2taUtchWHORRpzl2L kZrMhX4i8obpi4hz0XdcSClGUoh8L0oprKDiWjVCRHfwQGBYzGm4_eR2Ipvg2IT9lyriKrZK1ihf t714Ei7253GjCu_vlDsVckAlbTiUeqZCMrCWrD7CIZWUree_r6xVcGqEMZ.5Z8IG8L1n.bATlnM9 AMGvJLn5Dla7CGN9Easkgrtz0fqMeJlreWPg2qfZy2RU02TYmWFyBDY56L4R_Dde0C_X32J3W6w- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Tue, 24 Sep 2019 20:45:46 +0000 Received: by smtp431.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2575ff7eaafd71349a1cd318e2efd91f; Tue, 24 Sep 2019 20:45:41 +0000 (UTC) To: Torsten Lodderstedt , oauth Cc: Justin Richer References: <156907504831.22964.1710780113673136607.idtracker@ietfa.amsl.com> From: George Fletcher Organization: AOL LLC Message-ID: Date: Tue, 24 Sep 2019 16:45:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------728EF9EE06198DFC9CEADCDE" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt 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: Tue, 24 Sep 2019 20:45:50 -0000 This is a multi-part message in MIME format. --------------728EF9EE06198DFC9CEADCDE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Just two questions... 1. What is the rationale that 'data' is really an array of arbitrary top-level claims? I find looking at the spec and not finding a 'data' section a little confusing. 2. What is the rationale for sending the JSON object as a urlencoded JSON string rather than a base64url encoded JSON string? The later would likely be smaller and easier to read:) Thanks, George On 9/21/19 1:51 PM, Torsten Lodderstedt wrote: > Hi all, > > I just published a draft about ???OAuth 2.0 Rich Authorization Requests??? > (formerly known as ???structured scopes???). > > https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 > > It specifies a new parameter?????authorization_details"??that is used to > carry fine grained authorization data in the OAuth authorization > request. This mechanisms was designed based on experiences gathered in > the field of open banking, e.g. PSD2, and is intended to make the > implementation of rich and transaction oriented authorization requests > much easier than with current OAuth 2.0. > > I???m happy that Justin Richer and Brian Campbell joined me as authors > of this draft. We would would like to thank Daniel Fett, Sebastian > Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their > valuable feedback during the preparation of this draft. > > We look forward to getting your feedback. > > kind regards, > Torsten. > >> Begin forwarded message: >> >> *From: *internet-drafts@ietf.org >> *Subject: **New Version Notification for >> draft-lodderstedt-oauth-rar-02.txt* >> *Date: *21. September 2019 at 16:10:48 CEST >> *To: *"Justin Richer" > >, "Torsten Lodderstedt" >> >, "Brian >> Campbell" > > >> >> >> A new version of I-D, draft-lodderstedt-oauth-rar-02.txt >> has been successfully submitted by Torsten Lodderstedt and posted to the >> IETF repository. >> >> Name:draft-lodderstedt-oauth-rar >> Revision:02 >> Title:OAuth 2.0 Rich Authorization Requests >> Document date:2019-09-20 >> Group:Individual Submission >> Pages:16 >> URL: >> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt >> Status: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ >> Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar >> Diff: https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-02 >> >> Abstract: >> ????This document specifies a new parameter "authorization_details" that >> ????is used to carry fine grained authorization data in the OAuth >> ????authorization request. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org >> . >> >> The IETF Secretariat >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------728EF9EE06198DFC9CEADCDE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Just two questions...

1. What is the rationale that 'data' is really an array of arbitrary top-level claims? I find looking at the spec and not finding a 'data' section a little confusing.

2. What is the rationale for sending the JSON object as a urlencoded JSON string rather than a base64url encoded JSON string? The later would likely be smaller and easier to read:)

Thanks,
George

On 9/21/19 1:51 PM, Torsten Lodderstedt wrote:
Hi all,??

I just published a draft about ???OAuth 2.0 Rich Authorization Requests??? (formerly known as ???structured scopes???).??


It specifies a new parameter?????authorization_details"??that is used to carry fine grained authorization data in the OAuth authorization request. This mechanisms was designed based on experiences gathered in the field of open banking, e.g. PSD2, and is intended to make the implementation of rich and transaction oriented authorization requests much easier than with current OAuth 2.0.

I???m happy that Justin Richer and Brian Campbell joined me as authors of this draft. We would would like to thank Daniel Fett, Sebastian Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable feedback during the preparation of this draft.

We look forward to getting your feedback.??

kind regards,
Torsten.??

Begin forwarded message:

Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt
Date: 21. September 2019 at 16:10:48 CEST
To: "Justin Richer" <ietf@justin.richer.org>, "Torsten Lodderstedt" <torsten@lodderstedt.net>, "Brian Campbell" <bcampbell@pingidentity.com>


A new version of I-D, draft-lodderstedt-oauth-rar-02.txt
has been successfully submitted by Torsten Lodderstedt and posted to the
IETF repository.

Name: draft-lodderstedt-oauth-rar
Revision: 02
Title: OAuth 2.0 Rich Authorization Requests
Document date: 2019-09-20
Group: Individual Submission
Pages: 16
URL: ??????????????????????https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt
Status: ????????????????https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
Htmlized: ????????????https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02
Htmlized: ????????????https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar
Diff: ????????????????????https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-02

Abstract:
????This document specifies a new parameter "authorization_details" that
????is used to carry fine grained authorization data in the OAuth
????authorization request.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------728EF9EE06198DFC9CEADCDE-- From nobody Tue Sep 24 16:33:51 2019 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 07876120033 for ; Tue, 24 Sep 2019 16:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 pjaHt9O9v9s7 for ; Tue, 24 Sep 2019 16:33:45 -0700 (PDT) Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [208.79.240.5]) (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 4A70B1201AA for ; Tue, 24 Sep 2019 16:33:45 -0700 (PDT) Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id D9C0B2800049; Tue, 24 Sep 2019 16:33:37 -0700 (PDT) Received: from [172.16.2.17] (50-206-22-50-static.hfc.comcastbusiness.net [50.206.22.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtpauth.rollernet.us (Postfix) with ESMTPSA; Tue, 24 Sep 2019 16:33:37 -0700 (PDT) From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B1C0559B-3FB9-4C45-8D56-DAEA7CC404A2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 24 Sep 2019 16:33:37 -0700 In-Reply-To: Cc: Torsten Lodderstedt , oauth To: George Fletcher References: <156907504831.22964.1710780113673136607.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-Rollernet-Abuse: Processed by Roller Network Mail Services. Contact abuse@rollernet.us to report violations. Abuse policy: http://www.rollernet.us/policy X-Rollernet-Submit: Submit ID 95b.5d8aa7d1.bb9e3.0 Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt 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: Tue, 24 Sep 2019 23:33:48 -0000 --Apple-Mail=_B1C0559B-3FB9-4C45-8D56-DAEA7CC404A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The idea behind the =E2=80=9Clocations=E2=80=9D, =E2=80=9Cactions=E2=80=9D= , =E2=80=9Cdata=E2=80=9D, and =E2=80=9Cidentifier=E2=80=9D data element = types mirrors what I=E2=80=99ve seen =E2=80=9Cscope=E2=80=9D used for in = the wild. They roughly equate to =E2=80=9Cwhere something is=E2=80=9D, = =E2=80=9Cwhat I want to do with it=E2=80=9D, =E2=80=9Cwhat kind of thing = I want=E2=80=9D, and =E2=80=9Cthe exact thing I want=E2=80=9D, = respectively. I=E2=80=99m completely open for better names, and have = even been thinking =E2=80=9Cdatatype=E2=80=9D might be better than just = =E2=80=9Cdata=E2=80=9D for the third one. As for encoding, I think that form encoding makes sense because it=E2=80=99= s the simplest possible encoding that will work. I personally don=E2=80=99= t see a need to armor this part of the request with base64, as it is in = JOSE, and doing so would make it one more step removed from easy = developer understanding.=20 -- Justin Richer Bespoke Engineering +1 (617) 564-3801 https://bspk.io/ > On Sep 24, 2019, at 1:45 PM, George Fletcher wrote: >=20 > Just two questions... >=20 > 1. What is the rationale that 'data' is really an array of arbitrary = top-level claims? I find looking at the spec and not finding a 'data' = section a little confusing. >=20 > 2. What is the rationale for sending the JSON object as a urlencoded = JSON string rather than a base64url encoded JSON string? The later would = likely be smaller and easier to read:) >=20 > Thanks, > George >=20 > On 9/21/19 1:51 PM, Torsten Lodderstedt wrote: >> Hi all,?? >>=20 >> I just published a draft about ???OAuth 2.0 Rich Authorization = Requests??? (formerly known as ???structured scopes???).?? >>=20 >> https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 = >>=20 >> It specifies a new parameter?????authorization_details"??that is used = to carry fine grained authorization data in the OAuth authorization = request. This mechanisms was designed based on experiences gathered in = the field of open banking, e.g. PSD2, and is intended to make the = implementation of rich and transaction oriented authorization requests = much easier than with current OAuth 2.0. >>=20 >> I???m happy that Justin Richer and Brian Campbell joined me as = authors of this draft. We would would like to thank Daniel Fett, = Sebastian Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for = their valuable feedback during the preparation of this draft. >>=20 >> We look forward to getting your feedback.?? >>=20 >> kind regards, >> Torsten.?? >>=20 >>> Begin forwarded message: >>>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for = draft-lodderstedt-oauth-rar-02.txt >>> Date: 21. September 2019 at 16:10:48 CEST >>> To: "Justin Richer" >, "Torsten Lodderstedt" = >, "Brian = Campbell" > >>>=20 >>>=20 >>> A new version of I-D, draft-lodderstedt-oauth-rar-02.txt >>> has been successfully submitted by Torsten Lodderstedt and posted to = the >>> IETF repository. >>>=20 >>> Name: draft-lodderstedt-oauth-rar >>> Revision: 02 >>> Title: OAuth 2.0 Rich Authorization Requests >>> Document date: 2019-09-20 >>> Group: Individual Submission >>> Pages: 16 >>> URL: = ??????????????????????https://www.ietf.org/internet-drafts/draft-lodderste= dt-oauth-rar-02.txt = >>> Status: = ????????????????https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-r= ar/ >>> Htmlized: = ????????????https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 = >>> Htmlized: = ????????????https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-= rar >>> Diff: = ????????????????????https://www.ietf.org/rfcdiff?url2=3Ddraft-lodderstedt-= oauth-rar-02 = >>>=20 >>> Abstract: >>> ????This document specifies a new parameter "authorization_details" = that >>> ????is used to carry fine grained authorization data in the OAuth >>> ????authorization request. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org = . >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 --Apple-Mail=_B1C0559B-3FB9-4C45-8D56-DAEA7CC404A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = idea behind the =E2=80=9Clocations=E2=80=9D, =E2=80=9Cactions=E2=80=9D, = =E2=80=9Cdata=E2=80=9D, and =E2=80=9Cidentifier=E2=80=9D data element = types mirrors what I=E2=80=99ve seen =E2=80=9Cscope=E2=80=9D used for in = the wild. They roughly equate to =E2=80=9Cwhere something is=E2=80=9D, = =E2=80=9Cwhat I want to do with it=E2=80=9D, =E2=80=9Cwhat kind of thing = I want=E2=80=9D, and =E2=80=9Cthe exact thing I want=E2=80=9D, = respectively. I=E2=80=99m completely open for better names, and have = even been thinking =E2=80=9Cdatatype=E2=80=9D might be better than just = =E2=80=9Cdata=E2=80=9D for the third one.

As for encoding, I think that form = encoding makes sense because it=E2=80=99s the simplest possible encoding = that will work. I personally don=E2=80=99t see a need to armor this part = of the request with base64, as it is in JOSE, and doing so would make it = one more step removed from easy developer understanding. 

-- Justin Richer

Bespoke Engineering
+1 (617) = 564-3801



On Sep 24, 2019, at 1:45 PM, George Fletcher <gffletch@aol.com> = wrote:

=20 =20
Just two = questions...

1. What is the rationale that 'data' is really an array of arbitrary top-level claims? I find looking at the spec and not finding a 'data' section a little confusing.

2. What is the rationale for sending the JSON object as a urlencoded JSON string rather than a base64url encoded JSON string? The later would likely be smaller and easier to read:)

Thanks,
George

On 9/21/19 1:51 PM, Torsten = Lodderstedt wrote:
Hi all,??

I just published a draft about ???OAuth 2.0 Rich Authorization Requests??? (formerly known as ???structured scopes???).??

https://tools.ietf.org/html/draft-lodderstedt-oau= th-rar-02

It specifies a new parameter?????authorization_details"??that is used to carry fine grained authorization data in the OAuth authorization request. This mechanisms was designed based on experiences gathered in the field of open banking, e.g. PSD2, and is intended to make the implementation of rich and transaction oriented authorization requests much easier than with current OAuth = 2.0.

I???m happy that Justin Richer and Brian Campbell joined me as authors of this draft. We would would like to thank Daniel Fett, Sebastian Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable feedback during the preparation of this draft.

We look forward to getting your feedback.??

kind regards,
Torsten.??

Begin forwarded message:

From: internet-drafts@ietf.org
Subject: = New = Version Notification for = draft-lodderstedt-oauth-rar-02.txt
Date: 21. September 2019 at 16:10:48 CEST
To: "Justin Richer" = <ietf@justin.richer.org>, "Torsten Lodderstedt" <torsten@lodderstedt.net>, "Brian Campbell" <bcampbell@pingidentity.com>
=


A new version of I-D, = draft-lodderstedt-oauth-rar-02.txt
has been successfully submitted by Torsten Lodderstedt and posted to the
IETF repository.

Name: draft-lodderstedt-oauth-rar
Revision: 02
Title: OAuth 2.0 Rich Authorization Requests
Document date: 2019-09-20
Group: Individual Submission
Pages: 16
URL: ??????????????????????https://www.ietf.org/internet-drafts/draft-lodder= stedt-oauth-rar-02.txt
Status: ????????????????https://datatracker.ietf.org/doc/draft-loddersted= t-oauth-rar/
Htmlized: ????????????https://tools.ietf.org/html/draft-lodderstedt-oau= th-rar-02
Htmlized: ????????????https://datatracker.ietf.org/doc/html/draft-lodde= rstedt-oauth-rar
Diff: ????????????????????https://www.ietf.org/rfcdiff?url2=3Ddraft-lodders= tedt-oauth-rar-02

Abstract:
????This document specifies a new parameter "authorization_details" that
????is used to carry fine grained authorization data in the OAuth
????authorization request.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth


= --Apple-Mail=_B1C0559B-3FB9-4C45-8D56-DAEA7CC404A2-- From nobody Wed Sep 25 15:54:19 2019 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 4329A12008A for ; Wed, 25 Sep 2019 15:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 DzpP7dxVX6qw for ; Wed, 25 Sep 2019 15:54:14 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 21CBA12002E for ; Wed, 25 Sep 2019 15:54:14 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id c25so1184324iot.12 for ; Wed, 25 Sep 2019 15:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=epdu+9twXrWE48kA2xTiIiTrcioo0iQqT6rAbiJ0qD0=; b=Z1AznQPtBhVuOMYKvhVq/a5KryJo78TLcZP4F8c7jh7U9jyvqTpYRKhAUZ+IR6DNEd /YsM8lcSZyoJ+4SQ+PkbXd6j3Z3DRC7J8mDo/KqPiDw/8nyw+D6JAxJU+awVdtv9H5M+ t2w/OHIzZ8uJJGzhnanhkkn3Kv/eq8tjs31pI= 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=epdu+9twXrWE48kA2xTiIiTrcioo0iQqT6rAbiJ0qD0=; b=SMXhhYJRh9JZ7ObF0f+JPPvrhIc9rMIeWGq5PR7XQDfMSfY2LMogGbs4IbY0tyQBll x4c5i3+YGA5EosYPQ+wUSZkvNB/2nicKWCWIcbdYHwekqIgDJ0hV6HKEgiHq4Uqa/h/z 8WEzha45jwpj1anfk5ZlizQTR9745dnvEncAOl788jgEvTccmubLFs+CkYadeu3MJxqw vVtvN0fTSRzHWq0ULlZJV1VnjpA1OWrKIRCGP0aiaek+Rzbh9ZjBWaO2+AZc0dvyrpjl 4vDeqe4s5KsShdLENvoiLeXG1qBZi68RT0pkmYLIXp3z3gvbbnb6kHBV/RkT/fMB3SDm ruRg== X-Gm-Message-State: APjAAAXPmGvkXrr+hiU/3Yy2v5aQEYPh5yrMCI/l0qPgFUv72LBfWKef Xe4MlVkkJXkp9jfuF1j+fTS6B9KGqwjMoSsr9kXea1l5Mxg7ubfkyMXPW7w0mCCLV7L8NUDKirr o9BHcouk3SrmVcw== X-Google-Smtp-Source: APXvYqxw8Cue/pNpnHQIegCT4sxJ6GtBeSbimIOo8+yjRf8l4dKHfXiB8vpvVm0Uc0RlkAjMYRdPk6/y9kKHMN6aa2E= X-Received: by 2002:a02:170a:: with SMTP id 10mr775023jah.65.1569452053247; Wed, 25 Sep 2019 15:54:13 -0700 (PDT) MIME-Version: 1.0 References: <736340BF-B33D-4407-81AF-532C947F1243@xmlgrrl.com> In-Reply-To: From: Brian Campbell Date: Wed, 25 Sep 2019 16:53:46 -0600 Message-ID: To: Hannes Tschofenig Cc: Eve Maler , oauth Content-Type: multipart/alternative; boundary="000000000000205c6f059368881d" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01 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: Wed, 25 Sep 2019 22:54:17 -0000 --000000000000205c6f059368881d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just noticed that something is missing in https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02#section-5 where it has just, "(Section 4.1.4 of )" On Thu, Sep 12, 2019 at 8:40 AM Hannes Tschofenig wrote: > Thanks for the correction; yes =E2=80=93 the most recent version is -02 a= nd I > posted an old link. > > > > > > *From:* Eve Maler > *Sent:* Donnerstag, 12. September 2019 16:16 > *To:* Hannes Tschofenig > *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01 > > > > I think you mean > https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02? > > Eve Maler (sent from my iPad) | cell +1 425 345 6756 > > > On Sep 11, 2019, at 4:22 AM, Hannes Tschofenig > wrote: > > Hi all, > > > > We are starting a WGLC on the "OAuth 2.0 Incremental Authorization" draft= . > You can find the document here: > > https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-01 > > > > Please review the document and provide feedback. > > > > The WGLC will end September 25th, 2019. > > > > Ciao > > Hannes & Rifaat > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000205c6f059368881d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 12, 2= 019 at 8:40 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Thanks for the correction; yes =E2=80=93 the most re= cent version is -02 and I posted an old link.

=C2=A0

=C2=A0

From: Eve Maler <eve@xmlgrrl.com>
Sent: Donnerstag, 12. September 2019 16:16
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-0= 1

=C2=A0

I think you mean=C2=A0<= a href=3D"https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02= " target=3D"_blank">https://tools.ietf.org/html/draft-ietf-oauth-incrementa= l-authz-02?

Eve Maler (sent from = my iPad) |=C2=A0cell +1 425 345 6756


On Sep 11, 2019, at 4:22 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wr= ote:

Hi all,

=C2=A0

We are starting a WGLC on the "OAuth 2.0 Increm= ental Authorization" draft. You can find the document here:<= /u>

https://tools.ietf.org/html/dra= ft-ietf-oauth-incremental-authz-01

=C2=A0

Please review the document and provide feedback.<= /u>

=C2=A0

The WGLC will end September 25th, 2019.

=C2=A0

Ciao

Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000205c6f059368881d-- From nobody Thu Sep 26 02:26:47 2019 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 1D030120859 for ; Thu, 26 Sep 2019 02:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=curity-io.20150623.gappssmtp.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 hQ7PNVhuHYuz for ; Thu, 26 Sep 2019 02:26:44 -0700 (PDT) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 1A9BF12012C for ; Thu, 26 Sep 2019 02:26:44 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id 206so76262ybc.8 for ; Thu, 26 Sep 2019 02:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=4muyA02jbXlFL8XCNjRLfDUB6TrQcHWfVyTfpCouAeQ=; b=DMpPnM3mADRCreQWy153E0RG6wJBkg7s9sMdni+DvZ1h3jAlAwATBUw95v/Tvm/fB+ ENie4WM3oNm7+rrLrxQ0bTpUoS4lf0vmMQFkyzq82ytYxdTO5hxuQQ82+wb1DUt6Rp+1 bfjKzVnsKsYDLJQc7Np4+/ibcrTWTqE4l8nsfW0kyfWtfhvQgSIDESIYGVYybxUdj7/a Q6s2objI7uR8ng1SUo8zjcJgMoucNvETHjG4aKjqJVj5/UdvcpTwewE5qmI6A+cX1VRS FQSQ4b7PWJdDWjvPf/x7ZHIXpuOHz9g2OEFlnpIUkpW/lbxnM/ZiSfjBStoH4vVAZKHn 3iEg== 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; bh=4muyA02jbXlFL8XCNjRLfDUB6TrQcHWfVyTfpCouAeQ=; b=cwMaznNd3vBw9BsC9ccosDHVhPzndfVTJ5qSpXukNphb/7by77hizkYuO7IxTR2+HK iJ0RVO1QctLbdAM6z9wDSm0tIU08X6Zlqv+r28MeloRFUKIKnq+gx2QA8v7p9UU4pcav rKlfRqmOjNmJ79IZPg0N5SMKpdJTeMPNk8eP1dxXFhxbEyBhFg6WZgXf9mfQVnQDK81w w5ZgK0nRBYxLssOFZrzB9W0AdCixwEFY0GPVN/qnnsHbjYqDwGWfX3aIZKODG6WxhNr3 xKTr/ZrYJdt9iKNJR19G0Bz0rWLj5bc/ZAXilajxdxZBxie4Qh9N0d9aANtqtGmUo1ES xhLQ== X-Gm-Message-State: APjAAAV0l/sV+cjZRzaCrctTGkPZNBSHolGtVCTiEN2KDr9ha23bjIFG mxyQcHOYP90C5TI5mZ5BErcw04x/40r5kLSSz3BknJ0j05gZbw== X-Google-Smtp-Source: APXvYqzAd0+/AXIQSiLrb3cy1u409whIoMKa1nTILY3ZSAsXiA3m6kNB/eXB8ee4kkwUiDnBQSAB3vI8GihAHj/vbT0= X-Received: by 2002:a25:6b44:: with SMTP id o4mr1172979ybm.369.1569490002940; Thu, 26 Sep 2019 02:26:42 -0700 (PDT) MIME-Version: 1.0 References: <156898250596.30287.14524104153595179086@ietfa.amsl.com> In-Reply-To: <156898250596.30287.14524104153595179086@ietfa.amsl.com> From: Travis Spencer Date: Thu, 26 Sep 2019 11:26:31 +0200 Message-ID: To: oauth Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt 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: Thu, 26 Sep 2019 09:26:46 -0000 Some feedback on this draft compared to the last one that I read: * The acronym RS and the term "resource server" are used inconsistently. It would read better IMO if the acronym was always used after being defined or if resource server was always spelled out. Same for AS, but less so. Maybe this is just me, so take it as you will. * In section 3, is it saying that JWE is MTI? From the end of section 5, it seems not. If so, this statement should be clarified IMO: > To support encrypted token introspection response JWTs, the authorization server MUST also be provided with the respective resource server encryption keys and algorithms. Maybe just change it to "If the AS supports encrypted token introspection response JWTs..." * Instead of issuing an expired JWT (or in addition) I think it should be valid for the AS to reply with a 201, no content. For this reason, I think that section 5 should be updated thusly: > If the access token is invalid, expired, has been revoked, or is not intended to be consumed by the calling resource server (audience), the authorization server MUST set the value of the response claim "active" to "false" if it chooses to issue a JWT. Otherwise, this claim is set to "true". If it does not issue a JWT, the AS MUST reply with an HTTP 204, no content, status code. If it does include a JWT with an "active" claim of "false", the AS MAY reply with an HTTP 204, no content, status code. The rational is that the AS may not want to exert effort to make a signed/encrypted JWT that is expired. Not having the token is usually as good or better than having an expired one. * This statement makes the audience sound too narrow IMO: > The value of the "aud" claims MUST identify the resource server receiving the token introspection response. Because the AS's policy may stipulate that the audience could be others in addition to the RS some wording should be added like "the 'aud' claim MUST identify the resource server receiving the token introspection response and MAY contain other values based on its policy." * The "M" in email in section 5 should not be capitalized IINM. * In section 5, this is very broad. > The AS determines based on the RS-specific policy what claims about the resource owner to return in the token introspection response. The AS MUST ensure that the release of any privacy-sensitive data is legally based. So, an AS must follow the law? Is that all that it's saying? Section 9 seems to restate this point. Is conformance to the law really up to this doc to stipulate? If the AS breaks the law, it don't conform to the protocol. This seems very meta. * 1st in section 9 should be spelled out as "first" and IINM it should be "first-party" since it's being used as an adjective. * Last but certainly not least is the restriction that the current version places on disallowing of the introspection JWT response as an access token. This is done in numerous places (the note in section 5, 8.1, etc.). I understand that there are some objection to this usage, but we have had this protocol deployed for years, and it's running in dozens of customer's facilities. This will break real applications of this specification without a clear alternative. As we discussed in London last year at the IETF meeting, token exchange isn't a viable alternative (even still in its current draft form to the best of my knowledge). Without a workable alternative to move to, I emphatically but humbly request that this specification remove this restriction. On Fri, Sep 20, 2019 at 2:28 PM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : JWT Response for OAuth Token Introspection > Authors : Torsten Lodderstedt > Vladimir Dzhuvinov > Filename : draft-ietf-oauth-jwt-introspection-response-08.txt > Pages : 18 > Date : 2019-09-20 > > Abstract: > This specification proposes an additional JSON Web Token (JWT) > secured response for OAuth 2.0 Token Introspection. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Sep 26 06:46:10 2019 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 5A0D7120077 for ; Thu, 26 Sep 2019 06:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=parecki-com.20150623.gappssmtp.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 qL91r9XSb8h9 for ; Thu, 26 Sep 2019 06:46:07 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 57071120041 for ; Thu, 26 Sep 2019 06:46:07 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id c6so6539562ioo.13 for ; Thu, 26 Sep 2019 06:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=GZ/BGfQtKe2nzpSLVza6HZz5QLlDt35EHSsGGRYqDPU=; b=PhsXB9xyFq3m+C0IK0wp0qviVx5wgIDPGiMRa7rkiLIjsjmkS+qklvWXbtugA0jDPS sSWdX0YbUZBP3h78RiHguje1XlTwx5n/3O5wcfyisuPHOJGM0q4NNhnCxHYH0ArE+G5p +8Bnxrpt6NzuIBppWGYpyneG6ESKVakL1ifjKOUbxxKKzXh1bFppzi7Ij9bzNkUAFtOS 7Ib9nX89xunct5EXMBP71FGaLahunPLtYUOPdEDbw0P9TtZpzI5TK3/QGhydwjxk4CuU mIbnC9muB0tBJ9RClaveRTiO6LimUWoN8iyJuKsHz0B1uqffQVGpCdQK0VWQ9AhkTlB+ so2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GZ/BGfQtKe2nzpSLVza6HZz5QLlDt35EHSsGGRYqDPU=; b=f4S49yoyTq/jRoU/qFkTMKLcmSPllLinho3CUo8dpzTCLf9Ev0g9FU3Hkq+ZecRm8J ZGZENjocA0wtibg4FHEZp5MNkTk8kvM1a7YizHqgZmzG8OHrXdtBFhvfZhVVK5c3BgXn HlAn1UL45UztZ6e3E8iG0ILCnDNkEP9Pmf9fGsLtaVDIjc6vZltklny+QgCF2t316UyV YPynJoHgmYUgrROPJyLG65fU5t4Vji1NCDH8AvyWOqRdLMTfs+zPs9GIjZU2W3htGRFU lf+G4GWbkxusiAtCNu009d8MXqK9SQ4D+5F5uIRYGoXi7FSW8RewRGkG8ST66Lr6Yh0x x5JQ== X-Gm-Message-State: APjAAAWXClVQhvJLfn8QWgrmbA8/5Zj/u9B/N2EltjZfAPYtHs4JyFNo 4KX1fsICM3+0vzPPO0BHFr6IJjuxv7Y= X-Google-Smtp-Source: APXvYqxQrJpDs2BzUi6uENEx0L+vcvMiX762djtMO0Tl0uOTZmqy1BisPpf8eTYXlybSddvSHsVYbQ== X-Received: by 2002:a92:5f09:: with SMTP id t9mr2380148ilb.217.1569505566330; Thu, 26 Sep 2019 06:46:06 -0700 (PDT) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com. [209.85.166.46]) by smtp.gmail.com with ESMTPSA id c19sm668958ila.19.2019.09.26.06.46.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Sep 2019 06:46:05 -0700 (PDT) Received: by mail-io1-f46.google.com with SMTP id z19so6763263ior.0 for ; Thu, 26 Sep 2019 06:46:05 -0700 (PDT) X-Received: by 2002:a6b:b494:: with SMTP id d142mr3186203iof.156.1569505565537; Thu, 26 Sep 2019 06:46:05 -0700 (PDT) MIME-Version: 1.0 From: Aaron Parecki Date: Thu, 26 Sep 2019 15:45:53 +0200 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OAUTH-WG] New OAuth for Browser-Based Apps draft -04 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: Thu, 26 Sep 2019 13:46:09 -0000 Hi all, I've revised the browser-based apps draft to take into account everything discussed at the previous IETF meeting in Montreal. https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04 Here's a summary of the changes: * Disallow the password grant to bring it inline with the Security BCP * Rewrote the section about refresh tokens to allow refresh tokens if they are time-limited or rotated on each use * Updated the same-domain JS architecture section to focus more on the design pattern than the domain aspect * Added a few more references to the Security BCP This addresses all of the feedback from the session except for the one open item we had, which was to somehow describe that in some cases an access token will be sent down to the browser, and what to keep in mind when that is the case. This still needs some discussion on the list here. Please give it a read and let me know what you think! I think this is shaping up quite nicely now. ---- Aaron Parecki aaronparecki.com From nobody Thu Sep 26 08:02:33 2019 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 76CCD120974 for ; Thu, 26 Sep 2019 08:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=parecki-com.20150623.gappssmtp.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 or3Y-yNrhiYI for ; Thu, 26 Sep 2019 08:02:17 -0700 (PDT) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 A7A4A120903 for ; Thu, 26 Sep 2019 08:02:17 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id n197so7317467iod.9 for ; Thu, 26 Sep 2019 08:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dZ4yxrqzHGJ0IHU3qN/yTQ8HhwKXJw7Uxw32jxx1Xlo=; b=Hz6Oz+KOmJjyTjVcJvWRjeajEf48T4cZr72E0PWIL56vRVr/Un0fj2FnC7GTqfM1Yl SrPTBZTPv/LwYn0Y/xlcjekbo3YNN6oua1Rqvbbgu8cAD3B5IV6nLTvdw4kTkRUWQLRs hR6YwHcvH+AiiXM7xuN5G6x837oyIz6TpHbWFz3W6BbNBOSR8RfLevkCiMgZRXijSIOL OhgIXQvWFu+iTqGQi1pVK/kCy3dQIrK2uAGcpiqiiGPT9FYEBmvXCC9P8yI4WRdDJvK1 6jPED5qgCOJ10pxEzoR95ifCtJGUf0S1OHlzYKI0HPa5QXrIbFzH0DvPNmKrAMQIJwO0 r2zA== 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:content-transfer-encoding; bh=dZ4yxrqzHGJ0IHU3qN/yTQ8HhwKXJw7Uxw32jxx1Xlo=; b=a/IN16EWYbinrD1dAdjwqeQ/xANGdBeTYOFrfRmmkCfIzuRRNDSOTt/MWNHDVLIF5a gw/2aP2yJ+Eyxc9VgDaLX93GKzF1O48oTHyxlxL3VgAtdcZ8/RNEmOv/32se5XhG8ED0 VAOWQCVTfvn4lc7CcAhTXhoV+/xuyXWM24j9IDCJkJcOHNPZAff3HCD1IKfsW0SxxOm+ tHkeeoYhAFsJatNTx/b419fhZK8SZkcKrZy8gbYr0oNk5aBCaCV3z/lZT0zD6oej/GXr R2jhS1ohMyCLsM57XYatp6amPg0OFHbZONynprAWklyES/S2qc077e7CCFGQ+NyVZ9gI ZU6g== X-Gm-Message-State: APjAAAU+QNrvM8vBU7O95mg+gu7kTv6H/wO4l7kCwLuRSeXj4VmqQhlB pCPpyT3v73JGhfzUZ9Mm86Zr7FrTGX4= X-Google-Smtp-Source: APXvYqwzrcgCYit5CxsAgtTJ3QXelHK9A8FBLGLyuaHFh51uQfazaGtOqxUsDnTAjKnAb9+sgG+zcA== X-Received: by 2002:a92:9e86:: with SMTP id s6mr2982255ilk.83.1569510136368; Thu, 26 Sep 2019 08:02:16 -0700 (PDT) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com. [209.85.166.46]) by smtp.gmail.com with ESMTPSA id s19sm1067452iob.81.2019.09.26.08.02.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Sep 2019 08:02:15 -0700 (PDT) Received: by mail-io1-f46.google.com with SMTP id h144so7360552iof.7 for ; Thu, 26 Sep 2019 08:02:15 -0700 (PDT) X-Received: by 2002:a5e:8c17:: with SMTP id n23mr3838095ioj.46.1569510135298; Thu, 26 Sep 2019 08:02:15 -0700 (PDT) MIME-Version: 1.0 References: <156907504831.22964.1710780113673136607.idtracker@ietfa.amsl.com> In-Reply-To: From: Aaron Parecki Date: Thu, 26 Sep 2019 17:02:02 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Torsten Lodderstedt Cc: oauth , Justin Richer Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt 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: Thu, 26 Sep 2019 15:02:31 -0000 Hi Torsten, Overall I am a fan of a way to provide more structure in authorization requests, and I'm excited to see this draft, so thanks for that. I do have some concerns about one aspect of this. Given its clear intended use as a way to create authorization requests to do things like transfer money between bank accounts, I don't think it's appropriate for that kind of data to be sent in the front channel at all. By encoding a rich authorization request with bank account numbers and account names in a query string, that opens up several new opportunities for an attacker to steal private/sensitive information (browser extensions, proxy servers, etc). This differs from the plain OAuth authorization request because traditionally the request does not include any identifying information about any user or even about the particular transaction. At most, the request identifies the client and combination of coarse-grained scopes the client is requesting, none of which can identify a user. However with the examples provided in this document, as well as many additional uses of this mechanism, it includes potentially a lot of identifying information about users including their name, bank account numbers, and even relationships to other parties (e.g. creditorName). When the authorization request is sent to the AS in a URL, regardless of whether it's in plaintext like the simple example here, or signed as a JWT request, that data is visible to anything that can access the URL between the user's device and the AS. This seems like a huge potential for a privacy leak. I realize this draft currently points to JWT Secured Authorization Requests (JAR) in several places where these concerns come up. The problem is that JAR doesn't actually *require* an encrypted JWT, so the privacy implications aren't accounted for here. I would much rather see this document require your other recent submission, Pushed Authorization Requests. Given the privacy implications, it makes sense to limit the use of rich authorization requests to pushed authorization requests, so that this rich data is never made available to intermediaries in the front channel. If there is a good reason to continue allowing authorization requests as a GET without the new pushed request step, then at least I would want to see RAR require encrypted JWTs as described by JAR. Thanks for considering this! ---- Aaron Parecki aaronparecki.com On Sat, Sep 21, 2019 at 7:51 PM Torsten Lodderstedt wrote: > > Hi all, > > I just published a draft about =E2=80=9COAuth 2.0 Rich Authorization Requ= ests=E2=80=9D (formerly known as =E2=80=9Cstructured scopes=E2=80=9D). > > https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 > > It specifies a new parameter =E2=80=9Cauthorization_details" that is used= to carry fine grained authorization data in the OAuth authorization reques= t. This mechanisms was designed based on experiences gathered in the field = of open banking, e.g. PSD2, and is intended to make the implementation of r= ich and transaction oriented authorization requests much easier than with c= urrent OAuth 2.0. > > I=E2=80=99m happy that Justin Richer and Brian Campbell joined me as auth= ors of this draft. We would would like to thank Daniel Fett, Sebastian Ebli= ng, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable f= eedback during the preparation of this draft. > > We look forward to getting your feedback. > > kind regards, > Torsten. > > Begin forwarded message: > > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt > Date: 21. September 2019 at 16:10:48 CEST > To: "Justin Richer" , "Torsten Lodderstedt" , "Brian Campbell" > > > A new version of I-D, draft-lodderstedt-oauth-rar-02.txt > has been successfully submitted by Torsten Lodderstedt and posted to the > IETF repository. > > Name: draft-lodderstedt-oauth-rar > Revision: 02 > Title: OAuth 2.0 Rich Authorization Requests > Document date: 2019-09-20 > Group: Individual Submission > Pages: 16 > URL: https://www.ietf.org/internet-drafts/draft-lodderstedt-oa= uth-rar-02.txt > Status: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-= rar/ > Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-0= 2 > Htmlized: https://datatracker.ietf.org/doc/html/draft-lodderstedt-o= auth-rar > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-lodderstedt-oau= th-rar-02 > > Abstract: > This document specifies a new parameter "authorization_details" that > is used to carry fine grained authorization data in the OAuth > authorization request. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Sep 26 08:30:36 2019 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 75E7E120958 for ; Thu, 26 Sep 2019 08:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=parecki-com.20150623.gappssmtp.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 DqdxY1ZBNHQi for ; Thu, 26 Sep 2019 08:30:29 -0700 (PDT) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 89C3B12088D for ; Thu, 26 Sep 2019 08:30:29 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id c25so7549127iot.12 for ; Thu, 26 Sep 2019 08:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=z8Z8JAyH7YGhj8Zt8ZP9JlE5YFE4q/nM8RJpW3zSaJg=; b=vCvYSYTCESTMczjrQAv6RNoB0/PdzgP9svT0Z0E1YKOfw2cjuZQC2mB9aHt9Xk/9N3 iZkUuD1QQTtBPvXl1F3AXNl2ikcsl2LYn249gfu3nidAXfm8xCZhGtBzP2mlaetgEXjB TTkHOc3NC0SxD9JtJvrnJQSTcI+8Fi22uM9E02skvBaQXvtVc+lXYYmynSyYkVlOnac/ JYFQSQyQxLpxC8TTRGfvIJ+SGp8mBGg9X30nKhqBJlf7IOVr1uHU/C3DaNZ5kmP5NH1z apx+xgytVvAUZBWRlEqWrardX5IlnmGe8iFHp+xctJshQdGv2wFsIYbakMbxoI2q6HK1 5V+w== 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:content-transfer-encoding; bh=z8Z8JAyH7YGhj8Zt8ZP9JlE5YFE4q/nM8RJpW3zSaJg=; b=PtIXERkjhAaVHcRoHzWxkQaABHlSDZVTwO2DM3lqg05goxWvd3wUUFyQQNxOgY8cIA WsFLKdzaXUrY0E1vLdt1sWMvdvuRrzRvMkr+PVvjUETlDvJ020HEneeLtFOzR/LV6pfP cKvNRAD0fUvCs4AAP0UeffHRj06cKtZrab+/uFUe3t3OlDtmzs8JSxPeFA+ia0zKOjbQ AZt+W+zW7rE89+m2NOZVPaAJFLIM9EEIYbN6OEe5P7rPhXzlYgvUkCH6zfx0xpyTNjwf Cmb9Qe101xJvUctZDEiwTDsUce1e/cz38f6wwFOfVfGnCs7uaD77F9/mvdst63OQCCZs QXow== X-Gm-Message-State: APjAAAVmcRBdjgE7QQO3QjkYU71DpkRRMqTo+NeunNBjkGMYAPdVAyar dfAOdoSI8v84JNODx9NdsB0+SALJlFA= X-Google-Smtp-Source: APXvYqw5ocWygdDMCidz2Dxj5U7xTUekqhYZaNGRCYb9jjYPi+Y2fcJdMpjzws/AUD/zJZ5MWcNc6Q== X-Received: by 2002:a92:1bcb:: with SMTP id f72mr2948950ill.129.1569511828407; Thu, 26 Sep 2019 08:30:28 -0700 (PDT) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com. [209.85.166.48]) by smtp.gmail.com with ESMTPSA id k66sm1555830iof.25.2019.09.26.08.30.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Sep 2019 08:30:28 -0700 (PDT) Received: by mail-io1-f48.google.com with SMTP id b19so7666753iob.4 for ; Thu, 26 Sep 2019 08:30:27 -0700 (PDT) X-Received: by 2002:a6b:b494:: with SMTP id d142mr3611629iof.156.1569511827355; Thu, 26 Sep 2019 08:30:27 -0700 (PDT) MIME-Version: 1.0 References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> In-Reply-To: <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> From: Aaron Parecki Date: Thu, 26 Sep 2019 17:30:15 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Torsten Lodderstedt Cc: oauth Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-par-00.txt 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: Thu, 26 Sep 2019 15:30:34 -0000 Hi Torsten, I'm very glad to see this draft, I think it's definitely needed in this space. Here are some of my thoughts on the draft. > "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" Is it acceptable for the AS to return just an opaque string, rather than something prefixed with "uri:*"? I don't think anyone would be confused about copypasting the exact string from the "request_uri" response into the "request_uri" parameter even if it didn't start with "urn:". If, for whatever reason, it is required that this value is actually a URI, is there some expected namespace to use other than "example"? I worry that if all the examples in the spec are just "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up using the text "example" because they don't understand why it's there, and then it serves no purpose really. > The pushed authorization request endpoint shall be a RESTful API I would drop the term RESTful and just say "HTTP API", as this description is arguably RESTful at best. > Depending on client type and authentication method, the request might > also include the "client_id" parameter. I assume this is hinting at the difference between public clients sending only the "client_id" parameter and confidential clients sending only the HTTP Basic Authorization header which includes both the client ID and secret? It would probably be helpful to call out these two common examples if I am understanding this correctly, otherwise it seems pretty vague. > The "request_uri" value MUST be generated using a cryptographically > strong pseudorandom algorithm I assume this includes the use of a random number inside of a JWT, in case the AS wants to use JWTs as the "request_uri" parameter"? If so, it's probably worth spelling that out as it kind of reads like it has to be literally a random string at first glance. That's all for now, thanks! ---- Aaron Parecki aaronparecki.com @aaronpk On Sat, Sep 21, 2019 at 1:02 PM Torsten Lodderstedt wrote: > > Hi all, > > I just published a new draft that Brian Campbell, Dave Tonge, Filip Skoka= n, Nat Sakimura and I wrote. > > https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 > > It proposes a new endpoint, called "pushed authorization request endpoint= =E2=80=9D, that allows the client to push the Authorization Request payload= with the AS on a backchannel connection instead of a front channel interac= tion. The AS provides the client with a request URI (according to draft-iet= f-oauth-jwsreq) that the client uses in a subsequent authorization requests= to refer to the pushed request data. > > We believe this simple mechanism will significantly increase OAuth securi= ty and robustness since any application can use it by just sending the para= meters in the same encoding as used at the authorisation endpoint over a HT= TPS-protected and (for confidential clients) mutually authenticated connect= ion to the AS. It can also be used to push signed and encrypted request obj= ects to the AS, i.e. it provides an interoperable way to use request object= s managed at the AS for use cases requiring an even higher security level. > > We look forward to getting your feedback. > > kind regards, > Torsten. > > Begin forwarded message: > > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-lodderstedt-oauth-par-00.txt > Date: 21. September 2019 at 12:47:28 CEST > To: "Nat Sakimura" , "Brian Campbell" , "Torsten Lodderstedt" , "Dave Tonge" = , "Filip Skokan" > > > A new version of I-D, draft-lodderstedt-oauth-par-00.txt > has been successfully submitted by Torsten Lodderstedt and posted to the > IETF repository. > > Name: draft-lodderstedt-oauth-par > Revision: 00 > Title: OAuth 2.0 Pushed Authorization Requests > Document date: 2019-09-21 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/internet-drafts/draft-lodderstedt-oa= uth-par-00.txt > Status: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-= par/ > Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-par-0= 0 > Htmlized: https://datatracker.ietf.org/doc/html/draft-lodderstedt-o= auth-par > > > Abstract: > This document defines the pushed authorization request endpoint, > which allows clients to push the payload of an OAuth 2.0 > authorization request to the authorization server via a direct > request and provides them with a request URI that is used as > reference to the data in a subsequent authorization request. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Sep 26 09:19:08 2019 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 1A3B6120A2C for ; Thu, 26 Sep 2019 09:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=aol.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 OkhT1FM_ngaO for ; Thu, 26 Sep 2019 09:19:03 -0700 (PDT) Received: from sonic302-2.consmr.mail.bf2.yahoo.com (sonic302-2.consmr.mail.bf2.yahoo.com [74.6.135.41]) (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 1FFB812083E for ; Thu, 26 Sep 2019 09:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1569514742; bh=ioRquIdSLClSLe8vgQB8CMYa7DhTCcchIf2r+5fx1Ho=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=qfKu3hBaLlevQAEvk8NIK5ziNRX8RixR+N3c4jmbmUbNIoUWhw18Tl71yRK/jUQUfiEvGMhjn8l1eWGBfuY1kOovou7uHVszFvfUQvi6skMTcO1EeoyfSTCIgKaLaoe2MCwTVn7bIHIxTLxsP/tur+N4vPr+fy1nLjVB2y6bdsNWHmm/ojw8EK/+o8LZoeTX6ifRHj7/up5UyRLoktocFW3MOJdBN994R3D66iGp2kT7aP5EIZDJcTZMwYFfDJvnLd1e8b7p+o2uxpdlckfecarnnr4lZIjlbPL3mDZpHXMDlR3nncg1u/Ur8uW526JHSXwkxQq2VRro1BCRBrsk1g== X-YMail-OSG: 6dcLwRYVM1nv0rIR4k.l_FwufkBPSm6zDhKimGvtSlWxX0wXPxdg00.3RHFm2W5 UvHcb6EU5TkrpMVBc_ZJWOtxYp3GbDJsoLUhkgnJI8NZNlLNzBBicdVXpY5fPoN5573nyIppYDgz UcA6V7urFgcRE9J52kMErdYDmIyVkfVi9J_blJIgp5hl5FUHpFAJMwInFpSa8yIYLZmgVVDjBZF8 qnQ3gcWMqGT4hk.3IuSqdOtA.bF9G588jFfXhMx465LB_PMlZ3U_R20_CaRewoxZ3CMHZ9pRzhIr owoRNWXMFT79Yd1uXs8A2UxxyrTKCtsCjl9TLsiYDPYB21M16Cu8yE6bWDSEwv7BZWn1Px2dTvds UZgWJ.hktripal9KflWCWLMJ_VnoC2UFdjll_pTauhGPmpRhlW.9r3BU8I2MXNKYGQTbGOnLeBJU bT5uVFsj4bgblAoa4.GHkRo7l_JwZTyQDfJM3NA3o3H90BPY.ZFmcEsGAZ8AoT6nTQEaFmTqsuOL 52y7jMUic9G9Z_e5.wg1eIbklIfHBvLFsU_FhJVX9FUpKDX8RvXpAZmbDGuGWqEIhpACA4vQeMTX JYoiBmj79UeiL5kkF2nbSPsVMjWxozjHVhyoP44tGEf86VEhaTUvQqGY2OgEsftOxM8EI_yx9FPj EmenZNT4xZBwJ8Rw2K0X4KGFwj1z0FC5KPgzSQcGYaeTpZdL687U52GKE0TSwS8mr8PCN9gVSNTW OgqBkCK4B7wO21Ede9Pdb1WGWc7wXSJImpLYWw0F9T14vDF63Cq0OBBeuCX1DxAyqSa3pbszzfbq HKVZg6oWtXY6639Usy27sTr.EWE6gWKLpVFWYII4Gqdt1XgQqkCCGs1cSWbogPrXHeSAVo6CY6pR fYjxMyL1D6mCHnyGOGEkYicJENeoQARBN8kAvpX_Z_TSZyMepXZjoqpZrAUfl1Lg0nrm1pK5L30B d_se_W773Udq0yYpSazF5Pl6Ff37x5lhu.sdPbBxwPMJTLmEafSPCFJWo0VSkQJSGtsTY927VVJR JinSY0JL95Jf.Kz8TmcILqIFz8gI.DYQ8CiWqOGN_Rsvfr2th.dsmRAEFuU4SNv3P0f6lBTpUi.w MRN0Ju.MfKwZ7DB9UXnBs9hJAFc1tedI8Wrcvwx839Erp4vAUxSsxvP0q.rK6y3x1FAMlq5rXsgC sjMFcrGzknjaWzoJBEBfaoLfoHL4mg7h3LCDLe0oGdj0_bEDRDqh1ZN8IiKg.irZDpDlFFWKZ6P5 H7cPXr_EkGkSidwfGhXgTyBUaYHf0PTYpOkxGwkFRemDEqenPZqtgHOFobQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Thu, 26 Sep 2019 16:19:02 +0000 Received: by smtp401.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 4cd978bafde5d7087f4049772c8e7a5b; Thu, 26 Sep 2019 16:19:00 +0000 (UTC) To: Aaron Parecki , Torsten Lodderstedt Cc: oauth , Justin Richer References: <156907504831.22964.1710780113673136607.idtracker@ietfa.amsl.com> From: George Fletcher Organization: AOL LLC Message-ID: Date: Thu, 26 Sep 2019 12:18:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------834D9D435E657A67DA6BD84A" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt 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: Thu, 26 Sep 2019 16:19:07 -0000 This is a multi-part message in MIME format. --------------834D9D435E657A67DA6BD84A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This is a great point about personal information. However, there are uses for authorization_details that don't specifically relate to personal information. Think an enhancement that has language preference, maybe a device identifier. Maybe we can add more text in the security considerations section stating that it's best practice to use PAR for any authorization_details that are considered personal information (PI) or personally identifying information (PII) ? On 9/26/19 11:02 AM, Aaron Parecki wrote: > Hi Torsten, > > Overall I am a fan of a way to provide more structure in authorization > requests, and I'm excited to see this draft, so thanks for that. > > I do have some concerns about one aspect of this. Given its clear > intended use as a way to create authorization requests to do things > like transfer money between bank accounts, I don't think it's > appropriate for that kind of data to be sent in the front channel at > all. By encoding a rich authorization request with bank account > numbers and account names in a query string, that opens up several new > opportunities for an attacker to steal private/sensitive information > (browser extensions, proxy servers, etc). > > This differs from the plain OAuth authorization request because > traditionally the request does not include any identifying information > about any user or even about the particular transaction. At most, the > request identifies the client and combination of coarse-grained scopes > the client is requesting, none of which can identify a user. However > with the examples provided in this document, as well as many > additional uses of this mechanism, it includes potentially a lot of > identifying information about users including their name, bank account > numbers, and even relationships to other parties (e.g. creditorName). > When the authorization request is sent to the AS in a URL, regardless > of whether it's in plaintext like the simple example here, or signed > as a JWT request, that data is visible to anything that can access the > URL between the user's device and the AS. This seems like a huge > potential for a privacy leak. > > I realize this draft currently points to JWT Secured Authorization > Requests (JAR) in several places where these concerns come up. The > problem is that JAR doesn't actually *require* an encrypted JWT, so > the privacy implications aren't accounted for here. > > I would much rather see this document require your other recent > submission, Pushed Authorization Requests. Given the privacy > implications, it makes sense to limit the use of rich authorization > requests to pushed authorization requests, so that this rich data is > never made available to intermediaries in the front channel. > > If there is a good reason to continue allowing authorization requests > as a GET without the new pushed request step, then at least I would > want to see RAR require encrypted JWTs as described by JAR. > > Thanks for considering this! > > ---- > Aaron Parecki > aaronparecki.com > > > > On Sat, Sep 21, 2019 at 7:51 PM Torsten Lodderstedt > wrote: >> Hi all, >> >> I just published a draft about ???OAuth 2.0 Rich Authorization Requests??? (formerly known as ???structured scopes???). >> >> https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 >> >> It specifies a new parameter ???authorization_details" that is used to carry fine grained authorization data in the OAuth authorization request. This mechanisms was designed based on experiences gathered in the field of open banking, e.g. PSD2, and is intended to make the implementation of rich and transaction oriented authorization requests much easier than with current OAuth 2.0. >> >> I???m happy that Justin Richer and Brian Campbell joined me as authors of this draft. We would would like to thank Daniel Fett, Sebastian Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable feedback during the preparation of this draft. >> >> We look forward to getting your feedback. >> >> kind regards, >> Torsten. >> >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt >> Date: 21. September 2019 at 16:10:48 CEST >> To: "Justin Richer" , "Torsten Lodderstedt" , "Brian Campbell" >> >> >> A new version of I-D, draft-lodderstedt-oauth-rar-02.txt >> has been successfully submitted by Torsten Lodderstedt and posted to the >> IETF repository. >> >> Name: draft-lodderstedt-oauth-rar >> Revision: 02 >> Title: OAuth 2.0 Rich Authorization Requests >> Document date: 2019-09-20 >> Group: Individual Submission >> Pages: 16 >> URL: https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt >> Status: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ >> Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar >> Diff: https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-02 >> >> Abstract: >> This document specifies a new parameter "authorization_details" that >> is used to carry fine grained authorization data in the OAuth >> authorization request. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------834D9D435E657A67DA6BD84A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit This is a great point about personal information. However, there are uses for authorization_details that don't specifically relate to personal information. Think an enhancement that has language preference, maybe a device identifier. Maybe we can add more text in the security considerations section stating that it's best practice to use PAR for any authorization_details that are considered personal information (PI) or personally identifying information (PII) ?

On 9/26/19 11:02 AM, Aaron Parecki wrote:
Hi Torsten,

Overall I am a fan of a way to provide more structure in authorization
requests, and I'm excited to see this draft, so thanks for that.

I do have some concerns about one aspect of this. Given its clear
intended use as a way to create authorization requests to do things
like transfer money between bank accounts, I don't think it's
appropriate for that kind of data to be sent in the front channel at
all. By encoding a rich authorization request with bank account
numbers and account names in a query string, that opens up several new
opportunities for an attacker to steal private/sensitive information
(browser extensions, proxy servers, etc).

This differs from the plain OAuth authorization request because
traditionally the request does not include any identifying information
about any user or even about the particular transaction. At most, the
request identifies the client and combination of coarse-grained scopes
the client is requesting, none of which can identify a user. However
with the examples provided in this document, as well as many
additional uses of this mechanism, it includes potentially a lot of
identifying information about users including their name, bank account
numbers, and even relationships to other parties (e.g. creditorName).
When the authorization request is sent to the AS in a URL, regardless
of whether it's in plaintext like the simple example here, or signed
as a JWT request, that data is visible to anything that can access the
URL between the user's device and the AS. This seems like a huge
potential for a privacy leak.

I realize this draft currently points to JWT Secured Authorization
Requests (JAR) in several places where these concerns come up. The
problem is that JAR doesn't actually *require* an encrypted JWT, so
the privacy implications aren't accounted for here.

I would much rather see this document require your other recent
submission, Pushed Authorization Requests. Given the privacy
implications, it makes sense to limit the use of rich authorization
requests to pushed authorization requests, so that this rich data is
never made available to intermediaries in the front channel.

If there is a good reason to continue allowing authorization requests
as a GET without the new pushed request step, then at least I would
want to see RAR require encrypted JWTs as described by JAR.

Thanks for considering this!

----
Aaron Parecki
aaronparecki.com



On Sat, Sep 21, 2019 at 7:51 PM Torsten Lodderstedt
<torsten@lodderstedt.net> wrote:

Hi all,

I just published a draft about ???OAuth 2.0 Rich Authorization Requests??? (formerly known as ???structured scopes???).

https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02

It specifies a new parameter ???authorization_details" that is used to carry fine grained authorization data in the OAuth authorization request. This mechanisms was designed based on experiences gathered in the field of open banking, e.g. PSD2, and is intended to make the implementation of rich and transaction oriented authorization requests much easier than with current OAuth 2.0.

I???m happy that Justin Richer and Brian Campbell joined me as authors of this draft. We would would like to thank Daniel Fett, Sebastian Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable feedback during the preparation of this draft.

We look forward to getting your feedback.

kind regards,
Torsten.

Begin forwarded message:

From: internet-drafts@ietf.org
Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt
Date: 21. September 2019 at 16:10:48 CEST
To: "Justin Richer" <ietf@justin.richer.org>, "Torsten Lodderstedt" <torsten@lodderstedt.net>, "Brian Campbell" <bcampbell@pingidentity.com>


A new version of I-D, draft-lodderstedt-oauth-rar-02.txt
has been successfully submitted by Torsten Lodderstedt and posted to the
IETF repository.

Name: draft-lodderstedt-oauth-rar
Revision: 02
Title: OAuth 2.0 Rich Authorization Requests
Document date: 2019-09-20
Group: Individual Submission
Pages: 16
URL:            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt
Status:         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
Htmlized:       https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar
Diff:           https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-02

Abstract:
  This document specifies a new parameter "authorization_details" that
  is used to carry fine grained authorization data in the OAuth
  authorization request.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------834D9D435E657A67DA6BD84A-- From nobody Thu Sep 26 09:42:12 2019 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 1FE55120AA6 for ; Thu, 26 Sep 2019 09:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 dmeuEoibLLfD for ; Thu, 26 Sep 2019 09:41:57 -0700 (PDT) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (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 24E5A120A8C for ; Thu, 26 Sep 2019 09:41:57 -0700 (PDT) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id x8QGf3A6028560; Thu, 26 Sep 2019 12:41:24 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 26 Sep 2019 12:40:48 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 26 Sep 2019 12:41:27 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Thu, 26 Sep 2019 12:41:27 -0400 From: Justin Richer To: George Fletcher CC: Aaron Parecki , Torsten Lodderstedt , oauth Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt Thread-Index: AQHVcKU6/cOWNFcZ00SKku8vFjwfHqc+WHgAgAAVfgCAAAZHAA== Date: Thu, 26 Sep 2019 16:41:27 +0000 Message-ID: <6C8DC22C-2FA8-4582-B3F7-25075370D19D@mit.edu> References: <156907504831.22964.1710780113673136607.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [50.206.22.50] Content-Type: multipart/alternative; boundary="_000_6C8DC22C2FA84582B3F725075370D19Dmitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt 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: Thu, 26 Sep 2019 16:42:11 -0000 --_000_6C8DC22C2FA84582B3F725075370D19Dmitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEdlb3JnZSB0aGF0IHRoaXMgaXMgYSBnb29kIGZpdCBmb3IgYSBzZWN1cml0 eSBjb25zaWRlcmF0aW9uLCBub3QgYSBub3JtYXRpdmUgcmVxdWlyZW1lbnQuIFdoaWxlIGl04oCZ cyBiZXN0IHRvIGFsd2F5cyBwcm90ZWN0IHRoZSByZXF1ZXN0IGRhdGEsIHRoaXMgaXNu4oCZdCBh bGwgdGhhdCBtdWNoIGRpZmZlcmVudCBmcm9tIGhhdmluZyBzY29wZXMgdGhhdCBtaWdodCBsZWFr IHBlcnNvbmFsIGluZm9ybWF0aW9uLiBMaWtlIGZvciBleGFtcGxlLCBhc2tpbmcgZm9yIGFjY2Vz cyB0byBISVYgaW5mb3JtYXRpb24gZm9yIGEgaGVhbHRoIHJlY29yZC4gSXTigJlzIG1hZGUgbW9y ZSBleHBsaWNpdCBhbmQgcG90ZW50aWFsbHkgd29yc2UgYnkgUkFSLCBidXQgaXTigJlzIGZhciBm cm9tIHVuaXF1ZS4NCg0KVGhpcyBjb21iaW5hdGlvbiBvZiBpc3N1ZXMgaXMgcGFydCBvZiB3aHkg WFlaIGVmZmVjdGl2ZWx5IHJlcXVpcmVzIGEgY29tYmluYXRpb24gb2YgUEFSIGFuZCBSQVIgZm9y IGFsbCByZXF1ZXN0cy4NCg0K4oCUIEp1c3Rpbg0KDQpPbiBTZXAgMjYsIDIwMTksIGF0IDk6MTgg QU0sIEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hAYW9sLmNvbTxtYWlsdG86Z2ZmbGV0Y2hAYW9s LmNvbT4+IHdyb3RlOg0KDQpUaGlzIGlzIGEgZ3JlYXQgcG9pbnQgYWJvdXQgcGVyc29uYWwgaW5m b3JtYXRpb24uIEhvd2V2ZXIsIHRoZXJlIGFyZSB1c2VzIGZvciBhdXRob3JpemF0aW9uX2RldGFp bHMgdGhhdCBkb24ndCBzcGVjaWZpY2FsbHkgcmVsYXRlIHRvIHBlcnNvbmFsIGluZm9ybWF0aW9u LiBUaGluayBhbiBlbmhhbmNlbWVudCB0aGF0IGhhcyBsYW5ndWFnZSBwcmVmZXJlbmNlLCBtYXli ZSBhIGRldmljZSBpZGVudGlmaWVyLiBNYXliZSB3ZSBjYW4gYWRkIG1vcmUgdGV4dCBpbiB0aGUg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBzdGF0aW5nIHRoYXQgaXQncyBiZXN0IHBy YWN0aWNlIHRvIHVzZSBQQVIgZm9yIGFueSBhdXRob3JpemF0aW9uX2RldGFpbHMgdGhhdCBhcmUg Y29uc2lkZXJlZCBwZXJzb25hbCBpbmZvcm1hdGlvbiAoUEkpIG9yIHBlcnNvbmFsbHkgaWRlbnRp ZnlpbmcgaW5mb3JtYXRpb24gKFBJSSkgPw0KDQpPbiA5LzI2LzE5IDExOjAyIEFNLCBBYXJvbiBQ YXJlY2tpIHdyb3RlOg0KDQpIaSBUb3JzdGVuLA0KDQpPdmVyYWxsIEkgYW0gYSBmYW4gb2YgYSB3 YXkgdG8gcHJvdmlkZSBtb3JlIHN0cnVjdHVyZSBpbiBhdXRob3JpemF0aW9uDQpyZXF1ZXN0cywg YW5kIEknbSBleGNpdGVkIHRvIHNlZSB0aGlzIGRyYWZ0LCBzbyB0aGFua3MgZm9yIHRoYXQuDQoN CkkgZG8gaGF2ZSBzb21lIGNvbmNlcm5zIGFib3V0IG9uZSBhc3BlY3Qgb2YgdGhpcy4gR2l2ZW4g aXRzIGNsZWFyDQppbnRlbmRlZCB1c2UgYXMgYSB3YXkgdG8gY3JlYXRlIGF1dGhvcml6YXRpb24g cmVxdWVzdHMgdG8gZG8gdGhpbmdzDQpsaWtlIHRyYW5zZmVyIG1vbmV5IGJldHdlZW4gYmFuayBh Y2NvdW50cywgSSBkb24ndCB0aGluayBpdCdzDQphcHByb3ByaWF0ZSBmb3IgdGhhdCBraW5kIG9m IGRhdGEgdG8gYmUgc2VudCBpbiB0aGUgZnJvbnQgY2hhbm5lbCBhdA0KYWxsLiBCeSBlbmNvZGlu ZyBhIHJpY2ggYXV0aG9yaXphdGlvbiByZXF1ZXN0IHdpdGggYmFuayBhY2NvdW50DQpudW1iZXJz IGFuZCBhY2NvdW50IG5hbWVzIGluIGEgcXVlcnkgc3RyaW5nLCB0aGF0IG9wZW5zIHVwIHNldmVy YWwgbmV3DQpvcHBvcnR1bml0aWVzIGZvciBhbiBhdHRhY2tlciB0byBzdGVhbCBwcml2YXRlL3Nl bnNpdGl2ZSBpbmZvcm1hdGlvbg0KKGJyb3dzZXIgZXh0ZW5zaW9ucywgcHJveHkgc2VydmVycywg ZXRjKS4NCg0KVGhpcyBkaWZmZXJzIGZyb20gdGhlIHBsYWluIE9BdXRoIGF1dGhvcml6YXRpb24g cmVxdWVzdCBiZWNhdXNlDQp0cmFkaXRpb25hbGx5IHRoZSByZXF1ZXN0IGRvZXMgbm90IGluY2x1 ZGUgYW55IGlkZW50aWZ5aW5nIGluZm9ybWF0aW9uDQphYm91dCBhbnkgdXNlciBvciBldmVuIGFi b3V0IHRoZSBwYXJ0aWN1bGFyIHRyYW5zYWN0aW9uLiBBdCBtb3N0LCB0aGUNCnJlcXVlc3QgaWRl bnRpZmllcyB0aGUgY2xpZW50IGFuZCBjb21iaW5hdGlvbiBvZiBjb2Fyc2UtZ3JhaW5lZCBzY29w ZXMNCnRoZSBjbGllbnQgaXMgcmVxdWVzdGluZywgbm9uZSBvZiB3aGljaCBjYW4gaWRlbnRpZnkg YSB1c2VyLiBIb3dldmVyDQp3aXRoIHRoZSBleGFtcGxlcyBwcm92aWRlZCBpbiB0aGlzIGRvY3Vt ZW50LCBhcyB3ZWxsIGFzIG1hbnkNCmFkZGl0aW9uYWwgdXNlcyBvZiB0aGlzIG1lY2hhbmlzbSwg aXQgaW5jbHVkZXMgcG90ZW50aWFsbHkgYSBsb3Qgb2YNCmlkZW50aWZ5aW5nIGluZm9ybWF0aW9u IGFib3V0IHVzZXJzIGluY2x1ZGluZyB0aGVpciBuYW1lLCBiYW5rIGFjY291bnQNCm51bWJlcnMs IGFuZCBldmVuIHJlbGF0aW9uc2hpcHMgdG8gb3RoZXIgcGFydGllcyAoZS5nLiBjcmVkaXRvck5h bWUpLg0KV2hlbiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGlzIHNlbnQgdG8gdGhlIEFTIGlu IGEgVVJMLCByZWdhcmRsZXNzDQpvZiB3aGV0aGVyIGl0J3MgaW4gcGxhaW50ZXh0IGxpa2UgdGhl IHNpbXBsZSBleGFtcGxlIGhlcmUsIG9yIHNpZ25lZA0KYXMgYSBKV1QgcmVxdWVzdCwgdGhhdCBk YXRhIGlzIHZpc2libGUgdG8gYW55dGhpbmcgdGhhdCBjYW4gYWNjZXNzIHRoZQ0KVVJMIGJldHdl ZW4gdGhlIHVzZXIncyBkZXZpY2UgYW5kIHRoZSBBUy4gVGhpcyBzZWVtcyBsaWtlIGEgaHVnZQ0K cG90ZW50aWFsIGZvciBhIHByaXZhY3kgbGVhay4NCg0KSSByZWFsaXplIHRoaXMgZHJhZnQgY3Vy cmVudGx5IHBvaW50cyB0byBKV1QgU2VjdXJlZCBBdXRob3JpemF0aW9uDQpSZXF1ZXN0cyAoSkFS KSBpbiBzZXZlcmFsIHBsYWNlcyB3aGVyZSB0aGVzZSBjb25jZXJucyBjb21lIHVwLiBUaGUNCnBy b2JsZW0gaXMgdGhhdCBKQVIgZG9lc24ndCBhY3R1YWxseSAqcmVxdWlyZSogYW4gZW5jcnlwdGVk IEpXVCwgc28NCnRoZSBwcml2YWN5IGltcGxpY2F0aW9ucyBhcmVuJ3QgYWNjb3VudGVkIGZvciBo ZXJlLg0KDQpJIHdvdWxkIG11Y2ggcmF0aGVyIHNlZSB0aGlzIGRvY3VtZW50IHJlcXVpcmUgeW91 ciBvdGhlciByZWNlbnQNCnN1Ym1pc3Npb24sIFB1c2hlZCBBdXRob3JpemF0aW9uIFJlcXVlc3Rz LiBHaXZlbiB0aGUgcHJpdmFjeQ0KaW1wbGljYXRpb25zLCBpdCBtYWtlcyBzZW5zZSB0byBsaW1p dCB0aGUgdXNlIG9mIHJpY2ggYXV0aG9yaXphdGlvbg0KcmVxdWVzdHMgdG8gcHVzaGVkIGF1dGhv cml6YXRpb24gcmVxdWVzdHMsIHNvIHRoYXQgdGhpcyByaWNoIGRhdGEgaXMNCm5ldmVyIG1hZGUg YXZhaWxhYmxlIHRvIGludGVybWVkaWFyaWVzIGluIHRoZSBmcm9udCBjaGFubmVsLg0KDQpJZiB0 aGVyZSBpcyBhIGdvb2QgcmVhc29uIHRvIGNvbnRpbnVlIGFsbG93aW5nIGF1dGhvcml6YXRpb24g cmVxdWVzdHMNCmFzIGEgR0VUIHdpdGhvdXQgdGhlIG5ldyBwdXNoZWQgcmVxdWVzdCBzdGVwLCB0 aGVuIGF0IGxlYXN0IEkgd291bGQNCndhbnQgdG8gc2VlIFJBUiByZXF1aXJlIGVuY3J5cHRlZCBK V1RzIGFzIGRlc2NyaWJlZCBieSBKQVIuDQoNClRoYW5rcyBmb3IgY29uc2lkZXJpbmcgdGhpcyEN Cg0KLS0tLQ0KQWFyb24gUGFyZWNraQ0KYWFyb25wYXJlY2tpLmNvbTxodHRwOi8vYWFyb25wYXJl Y2tpLmNvbT4NCg0KDQoNCk9uIFNhdCwgU2VwIDIxLCAyMDE5IGF0IDc6NTEgUE0gVG9yc3RlbiBM b2RkZXJzdGVkdA0KPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PjxtYWlsdG86dG9yc3RlbkBsb2Rk ZXJzdGVkdC5uZXQ+IHdyb3RlOg0KDQoNCkhpIGFsbCwNCg0KSSBqdXN0IHB1Ymxpc2hlZCBhIGRy YWZ0IGFib3V0ID8/P09BdXRoIDIuMCBSaWNoIEF1dGhvcml6YXRpb24gUmVxdWVzdHM/Pz8gKGZv cm1lcmx5IGtub3duIGFzID8/P3N0cnVjdHVyZWQgc2NvcGVzPz8/KS4NCg0KaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJhci0wMg0KDQpJdCBzcGVj aWZpZXMgYSBuZXcgcGFyYW1ldGVyID8/P2F1dGhvcml6YXRpb25fZGV0YWlscyIgdGhhdCBpcyB1 c2VkIHRvIGNhcnJ5IGZpbmUgZ3JhaW5lZCBhdXRob3JpemF0aW9uIGRhdGEgaW4gdGhlIE9BdXRo IGF1dGhvcml6YXRpb24gcmVxdWVzdC4gVGhpcyBtZWNoYW5pc21zIHdhcyBkZXNpZ25lZCBiYXNl ZCBvbiBleHBlcmllbmNlcyBnYXRoZXJlZCBpbiB0aGUgZmllbGQgb2Ygb3BlbiBiYW5raW5nLCBl LmcuIFBTRDIsIGFuZCBpcyBpbnRlbmRlZCB0byBtYWtlIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBy aWNoIGFuZCB0cmFuc2FjdGlvbiBvcmllbnRlZCBhdXRob3JpemF0aW9uIHJlcXVlc3RzIG11Y2gg ZWFzaWVyIHRoYW4gd2l0aCBjdXJyZW50IE9BdXRoIDIuMC4NCg0KST8/P20gaGFwcHkgdGhhdCBK dXN0aW4gUmljaGVyIGFuZCBCcmlhbiBDYW1wYmVsbCBqb2luZWQgbWUgYXMgYXV0aG9ycyBvZiB0 aGlzIGRyYWZ0LiBXZSB3b3VsZCB3b3VsZCBsaWtlIHRvIHRoYW5rIERhbmllbCBGZXR0LCBTZWJh c3RpYW4gRWJsaW5nLCBEYXZlIFRvbmdlLCBNaWtlIEpvbmVzLCBOYXQgU2FraW11cmEsIGFuZCBS b2IgT3R0byBmb3IgdGhlaXIgdmFsdWFibGUgZmVlZGJhY2sgZHVyaW5nIHRoZSBwcmVwYXJhdGlv biBvZiB0aGlzIGRyYWZ0Lg0KDQpXZSBsb29rIGZvcndhcmQgdG8gZ2V0dGluZyB5b3VyIGZlZWRi YWNrLg0KDQpraW5kIHJlZ2FyZHMsDQpUb3JzdGVuLg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2Fn ZToNCg0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWxvZGRlcnN0ZWR0LW9hdXRoLXJhci0wMi50eHQNCkRhdGU6IDIxLiBTZXB0ZW1iZXIgMjAxOSBh dCAxNjoxMDo0OCBDRVNUDQpUbzogIkp1c3RpbiBSaWNoZXIiIDxpZXRmQGp1c3Rpbi5yaWNoZXIu b3JnPjxtYWlsdG86aWV0ZkBqdXN0aW4ucmljaGVyLm9yZz4sICJUb3JzdGVuIExvZGRlcnN0ZWR0 IiA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5l dD4sICJCcmlhbiBDYW1wYmVsbCIgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPjxtYWlsdG86 YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJhci0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgVG9yc3RlbiBMb2RkZXJzdGVkdCBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiBy ZXBvc2l0b3J5Lg0KDQpOYW1lOiBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXINClJldmlzaW9u OiAwMg0KVGl0bGU6IE9BdXRoIDIuMCBSaWNoIEF1dGhvcml6YXRpb24gUmVxdWVzdHMNCkRvY3Vt ZW50IGRhdGU6IDIwMTktMDktMjANCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2Vz OiAxNg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXItMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFy Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sb2Rk ZXJzdGVkdC1vYXV0aC1yYXItMDINCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJhcg0KRGlmZjogICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1sb2RkZXJzdGVk dC1vYXV0aC1yYXItMDINCg0KQWJzdHJhY3Q6DQogIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEg bmV3IHBhcmFtZXRlciAiYXV0aG9yaXphdGlvbl9kZXRhaWxzIiB0aGF0DQogIGlzIHVzZWQgdG8g Y2FycnkgZmluZSBncmFpbmVkIGF1dGhvcml6YXRpb24gZGF0YSBpbiB0aGUgT0F1dGgNCiAgYXV0 aG9yaXphdGlvbiByZXF1ZXN0Lg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCg== --_000_6C8DC22C2FA84582B3F725075370D19Dmitedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgYWdyZWUgd2l0aCBHZW9yZ2UgdGhhdCB0aGlz IGlzIGEgZ29vZCBmaXQgZm9yIGEgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiwgbm90IGEgbm9ybWF0 aXZlIHJlcXVpcmVtZW50LiBXaGlsZSBpdOKAmXMgYmVzdCB0byBhbHdheXMgcHJvdGVjdCB0aGUg cmVxdWVzdCBkYXRhLCB0aGlzIGlzbuKAmXQgYWxsIHRoYXQgbXVjaCBkaWZmZXJlbnQgZnJvbSBo YXZpbmcgc2NvcGVzIHRoYXQgbWlnaHQgbGVhayBwZXJzb25hbCBpbmZvcm1hdGlvbi4gTGlrZSBm b3IgZXhhbXBsZSwNCiBhc2tpbmcgZm9yIGFjY2VzcyB0byBISVYgaW5mb3JtYXRpb24gZm9yIGEg aGVhbHRoIHJlY29yZC4gSXTigJlzIG1hZGUgbW9yZSBleHBsaWNpdCBhbmQgcG90ZW50aWFsbHkg d29yc2UgYnkgUkFSLCBidXQgaXTigJlzIGZhciBmcm9tIHVuaXF1ZS4mbmJzcDsNCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoaXMgY29tYmluYXRp b24gb2YgaXNzdWVzIGlzIHBhcnQgb2Ygd2h5IFhZWiBlZmZlY3RpdmVseSByZXF1aXJlcyBhIGNv bWJpbmF0aW9uIG9mIFBBUiBhbmQgUkFSIGZvciBhbGwgcmVxdWVzdHMuJm5ic3A7PGJyIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBh dXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9u ZTsiPg0K4oCUIEp1c3RpbjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBTZXAgMjYsIDIw MTksIGF0IDk6MTggQU0sIEdlb3JnZSBGbGV0Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdmZmxl dGNoQGFvbC5jb20iIGNsYXNzPSIiPmdmZmxldGNoQGFvbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rp dj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0iIj48Zm9udCBm YWNlPSJIZWx2ZXRpY2EsIEFyaWFsLCBzYW5zLXNlcmlmIiBjbGFzcz0iIj5UaGlzIGlzIGEgZ3Jl YXQgcG9pbnQgYWJvdXQgcGVyc29uYWwgaW5mb3JtYXRpb24uIEhvd2V2ZXIsIHRoZXJlIGFyZSB1 c2VzIGZvciBhdXRob3JpemF0aW9uX2RldGFpbHMgdGhhdCBkb24ndCBzcGVjaWZpY2FsbHkgcmVs YXRlIHRvIHBlcnNvbmFsIGluZm9ybWF0aW9uLiBUaGluaw0KIGFuIGVuaGFuY2VtZW50IHRoYXQg aGFzIGxhbmd1YWdlIHByZWZlcmVuY2UsIG1heWJlIGEgZGV2aWNlIGlkZW50aWZpZXIuIE1heWJl IHdlIGNhbiBhZGQgbW9yZSB0ZXh0IGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0 aW9uIHN0YXRpbmcgdGhhdCBpdCdzIGJlc3QgcHJhY3RpY2UgdG8gdXNlIFBBUiBmb3IgYW55IGF1 dGhvcml6YXRpb25fZGV0YWlscyB0aGF0IGFyZSBjb25zaWRlcmVkIHBlcnNvbmFsIGluZm9ybWF0 aW9uIChQSSkNCiBvciBwZXJzb25hbGx5IGlkZW50aWZ5aW5nIGluZm9ybWF0aW9uIChQSUkpID88 L2ZvbnQ+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUt cHJlZml4Ij5PbiA5LzI2LzE5IDExOjAyIEFNLCBBYXJvbiBQYXJlY2tpIHdyb3RlOjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOkNBR0JTR2py VWU4LUpnTWNtOUpOQ2tpRTdMNWl1UERId3ptMGJoLUNEVmdUakhlcnVBd0BtYWlsLmdtYWlsLmNv bSIgY2xhc3M9IiI+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPkhpIFRvcnN0 ZW4sDQoNCk92ZXJhbGwgSSBhbSBhIGZhbiBvZiBhIHdheSB0byBwcm92aWRlIG1vcmUgc3RydWN0 dXJlIGluIGF1dGhvcml6YXRpb24NCnJlcXVlc3RzLCBhbmQgSSdtIGV4Y2l0ZWQgdG8gc2VlIHRo aXMgZHJhZnQsIHNvIHRoYW5rcyBmb3IgdGhhdC4NCg0KSSBkbyBoYXZlIHNvbWUgY29uY2VybnMg YWJvdXQgb25lIGFzcGVjdCBvZiB0aGlzLiBHaXZlbiBpdHMgY2xlYXINCmludGVuZGVkIHVzZSBh cyBhIHdheSB0byBjcmVhdGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0cyB0byBkbyB0aGluZ3MNCmxp a2UgdHJhbnNmZXIgbW9uZXkgYmV0d2VlbiBiYW5rIGFjY291bnRzLCBJIGRvbid0IHRoaW5rIGl0 J3MNCmFwcHJvcHJpYXRlIGZvciB0aGF0IGtpbmQgb2YgZGF0YSB0byBiZSBzZW50IGluIHRoZSBm cm9udCBjaGFubmVsIGF0DQphbGwuIEJ5IGVuY29kaW5nIGEgcmljaCBhdXRob3JpemF0aW9uIHJl cXVlc3Qgd2l0aCBiYW5rIGFjY291bnQNCm51bWJlcnMgYW5kIGFjY291bnQgbmFtZXMgaW4gYSBx dWVyeSBzdHJpbmcsIHRoYXQgb3BlbnMgdXAgc2V2ZXJhbCBuZXcNCm9wcG9ydHVuaXRpZXMgZm9y IGFuIGF0dGFja2VyIHRvIHN0ZWFsIHByaXZhdGUvc2Vuc2l0aXZlIGluZm9ybWF0aW9uDQooYnJv d3NlciBleHRlbnNpb25zLCBwcm94eSBzZXJ2ZXJzLCBldGMpLg0KDQpUaGlzIGRpZmZlcnMgZnJv bSB0aGUgcGxhaW4gT0F1dGggYXV0aG9yaXphdGlvbiByZXF1ZXN0IGJlY2F1c2UNCnRyYWRpdGlv bmFsbHkgdGhlIHJlcXVlc3QgZG9lcyBub3QgaW5jbHVkZSBhbnkgaWRlbnRpZnlpbmcgaW5mb3Jt YXRpb24NCmFib3V0IGFueSB1c2VyIG9yIGV2ZW4gYWJvdXQgdGhlIHBhcnRpY3VsYXIgdHJhbnNh Y3Rpb24uIEF0IG1vc3QsIHRoZQ0KcmVxdWVzdCBpZGVudGlmaWVzIHRoZSBjbGllbnQgYW5kIGNv bWJpbmF0aW9uIG9mIGNvYXJzZS1ncmFpbmVkIHNjb3Blcw0KdGhlIGNsaWVudCBpcyByZXF1ZXN0 aW5nLCBub25lIG9mIHdoaWNoIGNhbiBpZGVudGlmeSBhIHVzZXIuIEhvd2V2ZXINCndpdGggdGhl IGV4YW1wbGVzIHByb3ZpZGVkIGluIHRoaXMgZG9jdW1lbnQsIGFzIHdlbGwgYXMgbWFueQ0KYWRk aXRpb25hbCB1c2VzIG9mIHRoaXMgbWVjaGFuaXNtLCBpdCBpbmNsdWRlcyBwb3RlbnRpYWxseSBh IGxvdCBvZg0KaWRlbnRpZnlpbmcgaW5mb3JtYXRpb24gYWJvdXQgdXNlcnMgaW5jbHVkaW5nIHRo ZWlyIG5hbWUsIGJhbmsgYWNjb3VudA0KbnVtYmVycywgYW5kIGV2ZW4gcmVsYXRpb25zaGlwcyB0 byBvdGhlciBwYXJ0aWVzIChlLmcuIGNyZWRpdG9yTmFtZSkuDQpXaGVuIHRoZSBhdXRob3JpemF0 aW9uIHJlcXVlc3QgaXMgc2VudCB0byB0aGUgQVMgaW4gYSBVUkwsIHJlZ2FyZGxlc3MNCm9mIHdo ZXRoZXIgaXQncyBpbiBwbGFpbnRleHQgbGlrZSB0aGUgc2ltcGxlIGV4YW1wbGUgaGVyZSwgb3Ig c2lnbmVkDQphcyBhIEpXVCByZXF1ZXN0LCB0aGF0IGRhdGEgaXMgdmlzaWJsZSB0byBhbnl0aGlu ZyB0aGF0IGNhbiBhY2Nlc3MgdGhlDQpVUkwgYmV0d2VlbiB0aGUgdXNlcidzIGRldmljZSBhbmQg dGhlIEFTLiBUaGlzIHNlZW1zIGxpa2UgYSBodWdlDQpwb3RlbnRpYWwgZm9yIGEgcHJpdmFjeSBs ZWFrLg0KDQpJIHJlYWxpemUgdGhpcyBkcmFmdCBjdXJyZW50bHkgcG9pbnRzIHRvIEpXVCBTZWN1 cmVkIEF1dGhvcml6YXRpb24NClJlcXVlc3RzIChKQVIpIGluIHNldmVyYWwgcGxhY2VzIHdoZXJl IHRoZXNlIGNvbmNlcm5zIGNvbWUgdXAuIFRoZQ0KcHJvYmxlbSBpcyB0aGF0IEpBUiBkb2Vzbid0 IGFjdHVhbGx5ICpyZXF1aXJlKiBhbiBlbmNyeXB0ZWQgSldULCBzbw0KdGhlIHByaXZhY3kgaW1w bGljYXRpb25zIGFyZW4ndCBhY2NvdW50ZWQgZm9yIGhlcmUuDQoNCkkgd291bGQgbXVjaCByYXRo ZXIgc2VlIHRoaXMgZG9jdW1lbnQgcmVxdWlyZSB5b3VyIG90aGVyIHJlY2VudA0Kc3VibWlzc2lv biwgUHVzaGVkIEF1dGhvcml6YXRpb24gUmVxdWVzdHMuIEdpdmVuIHRoZSBwcml2YWN5DQppbXBs aWNhdGlvbnMsIGl0IG1ha2VzIHNlbnNlIHRvIGxpbWl0IHRoZSB1c2Ugb2YgcmljaCBhdXRob3Jp emF0aW9uDQpyZXF1ZXN0cyB0byBwdXNoZWQgYXV0aG9yaXphdGlvbiByZXF1ZXN0cywgc28gdGhh dCB0aGlzIHJpY2ggZGF0YSBpcw0KbmV2ZXIgbWFkZSBhdmFpbGFibGUgdG8gaW50ZXJtZWRpYXJp ZXMgaW4gdGhlIGZyb250IGNoYW5uZWwuDQoNCklmIHRoZXJlIGlzIGEgZ29vZCByZWFzb24gdG8g Y29udGludWUgYWxsb3dpbmcgYXV0aG9yaXphdGlvbiByZXF1ZXN0cw0KYXMgYSBHRVQgd2l0aG91 dCB0aGUgbmV3IHB1c2hlZCByZXF1ZXN0IHN0ZXAsIHRoZW4gYXQgbGVhc3QgSSB3b3VsZA0Kd2Fu dCB0byBzZWUgUkFSIHJlcXVpcmUgZW5jcnlwdGVkIEpXVHMgYXMgZGVzY3JpYmVkIGJ5IEpBUi4N Cg0KVGhhbmtzIGZvciBjb25zaWRlcmluZyB0aGlzIQ0KDQotLS0tDQpBYXJvbiBQYXJlY2tpDQo8 YSBocmVmPSJodHRwOi8vYWFyb25wYXJlY2tpLmNvbSIgY2xhc3M9IiI+YWFyb25wYXJlY2tpLmNv bTwvYT4NCg0KDQoNCk9uIFNhdCwgU2VwIDIxLCAyMDE5IGF0IDc6NTEgUE0gVG9yc3RlbiBMb2Rk ZXJzdGVkdA0KPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOnRv cnN0ZW5AbG9kZGVyc3RlZHQubmV0Ij4mbHQ7dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQmZ3Q7PC9h PiB3cm90ZToNCjwvcHJlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8cHJl IGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPkhpIGFsbCwNCg0KSSBqdXN0IHB1Ymxpc2hl ZCBhIGRyYWZ0IGFib3V0ID8/P09BdXRoIDIuMCBSaWNoIEF1dGhvcml6YXRpb24gUmVxdWVzdHM/ Pz8gKGZvcm1lcmx5IGtub3duIGFzID8/P3N0cnVjdHVyZWQgc2NvcGVzPz8/KS4NCg0KPGEgY2xh c3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJhci0wMiI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJhci0wMjwvYT4NCg0KSXQgc3BlY2lmaWVz IGEgbmV3IHBhcmFtZXRlciA/Pz9hdXRob3JpemF0aW9uX2RldGFpbHMmcXVvdDsgdGhhdCBpcyB1 c2VkIHRvIGNhcnJ5IGZpbmUgZ3JhaW5lZCBhdXRob3JpemF0aW9uIGRhdGEgaW4gdGhlIE9BdXRo IGF1dGhvcml6YXRpb24gcmVxdWVzdC4gVGhpcyBtZWNoYW5pc21zIHdhcyBkZXNpZ25lZCBiYXNl ZCBvbiBleHBlcmllbmNlcyBnYXRoZXJlZCBpbiB0aGUgZmllbGQgb2Ygb3BlbiBiYW5raW5nLCBl LmcuIFBTRDIsIGFuZCBpcyBpbnRlbmRlZCB0byBtYWtlIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBy aWNoIGFuZCB0cmFuc2FjdGlvbiBvcmllbnRlZCBhdXRob3JpemF0aW9uIHJlcXVlc3RzIG11Y2gg ZWFzaWVyIHRoYW4gd2l0aCBjdXJyZW50IE9BdXRoIDIuMC4NCg0KST8/P20gaGFwcHkgdGhhdCBK dXN0aW4gUmljaGVyIGFuZCBCcmlhbiBDYW1wYmVsbCBqb2luZWQgbWUgYXMgYXV0aG9ycyBvZiB0 aGlzIGRyYWZ0LiBXZSB3b3VsZCB3b3VsZCBsaWtlIHRvIHRoYW5rIERhbmllbCBGZXR0LCBTZWJh c3RpYW4gRWJsaW5nLCBEYXZlIFRvbmdlLCBNaWtlIEpvbmVzLCBOYXQgU2FraW11cmEsIGFuZCBS b2IgT3R0byBmb3IgdGhlaXIgdmFsdWFibGUgZmVlZGJhY2sgZHVyaW5nIHRoZSBwcmVwYXJhdGlv biBvZiB0aGlzIGRyYWZ0Lg0KDQpXZSBsb29rIGZvcndhcmQgdG8gZ2V0dGluZyB5b3VyIGZlZWRi YWNrLg0KDQpraW5kIHJlZ2FyZHMsDQpUb3JzdGVuLg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2Fn ZToNCg0KRnJvbTogPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9h Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1sb2RkZXJzdGVk dC1vYXV0aC1yYXItMDIudHh0DQpEYXRlOiAyMS4gU2VwdGVtYmVyIDIwMTkgYXQgMTY6MTA6NDgg Q0VTVA0KVG86ICZxdW90O0p1c3RpbiBSaWNoZXImcXVvdDsgPGEgY2xhc3M9Im1vei10eHQtbGlu ay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmlldGZAanVzdGluLnJpY2hlci5vcmciPiZsdDtpZXRm QGp1c3Rpbi5yaWNoZXIub3JnJmd0OzwvYT4sICZxdW90O1RvcnN0ZW4gTG9kZGVyc3RlZHQmcXVv dDsgPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOnRvcnN0ZW5A bG9kZGVyc3RlZHQubmV0Ij4mbHQ7dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQmZ3Q7PC9hPiwgJnF1 b3Q7QnJpYW4gQ2FtcGJlbGwmcXVvdDsgPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIg aHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj4mbHQ7YmNhbXBiZWxsQHBp bmdpZGVudGl0eS5jb20mZ3Q7PC9hPg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1s b2RkZXJzdGVkdC1vYXV0aC1yYXItMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFRvcnN0ZW4gTG9kZGVyc3RlZHQgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3Np dG9yeS4NCg0KTmFtZTogZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyDQpSZXZpc2lvbjogMDIN ClRpdGxlOiBPQXV0aCAyLjAgUmljaCBBdXRob3JpemF0aW9uIFJlcXVlc3RzDQpEb2N1bWVudCBk YXRlOiAyMDE5LTA5LTIwDQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogMTYN ClVSTDogICAgICAgICAgICA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbG9kZGVyc3RlZHQtb2F1 dGgtcmFyLTAyLnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWxvZGRlcnN0ZWR0LW9hdXRoLXJhci0wMi50eHQ8L2E+DQpTdGF0dXM6ICAgICAgICAgPGEgY2xh c3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLyI+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLzwvYT4NCkh0bWxpemVk OiAgICAgICA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLTAyIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLTAyPC9hPg0K SHRtbGl6ZWQ6ICAgICAgIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQtb2F1 dGgtcmFyIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxvZGRl cnN0ZWR0LW9hdXRoLXJhcjwvYT4NCkRpZmY6ICAgICAgICAgICA8YSBjbGFzcz0ibW96LXR4dC1s aW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLTAyIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLTAyPC9hPg0KDQpBYnN0cmFjdDoNCiAg VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBuZXcgcGFyYW1ldGVyICZxdW90O2F1dGhvcml6YXRp b25fZGV0YWlscyZxdW90OyB0aGF0DQogIGlzIHVzZWQgdG8gY2FycnkgZmluZSBncmFpbmVkIGF1 dGhvcml6YXRpb24gZGF0YSBpbiB0aGUgT0F1dGgNCiAgYXV0aG9yaXphdGlvbiByZXF1ZXN0Lg0K DQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIg Y2xhc3M9IiI+dG9vbHMuaWV0Zi5vcmc8L2E+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBt YWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1h aWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+DQo8YSBjbGFzcz0ibW96LXR4 dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9h Pg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFw PSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9 Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+DQo8YSBjbGFzcz0ibW96 LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo PC9hPg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_6C8DC22C2FA84582B3F725075370D19Dmitedu_-- From nobody Thu Sep 26 09:49:57 2019 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 53C9012009E for ; Thu, 26 Sep 2019 09:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 J8-fYRux9DdY for ; Thu, 26 Sep 2019 09:49:52 -0700 (PDT) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (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 A4968120019 for ; Thu, 26 Sep 2019 09:49:51 -0700 (PDT) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id x8QGnKi8029064; Thu, 26 Sep 2019 12:49:21 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 26 Sep 2019 12:48:43 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 26 Sep 2019 12:49:22 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Thu, 26 Sep 2019 12:49:22 -0400 From: Justin Richer To: Aaron Parecki CC: Torsten Lodderstedt , oauth Thread-Topic: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt Thread-Index: AQHVdIpY21j3hq2VmkCWElppvnoDQQ== Date: Thu, 26 Sep 2019 16:49:22 +0000 Message-ID: References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [50.206.22.50] Content-Type: multipart/alternative; boundary="_000_BB0AE29D5CD04441B3B6FEB6D3F749EEmitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt 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: Thu, 26 Sep 2019 16:49:55 -0000 --_000_BB0AE29D5CD04441B3B6FEB6D3F749EEmitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWFyb24sIHNvbWUgY29tbWVudHMgaW5saW5lLg0KDQrigJQgSnVzdGluDQoNCk9uIFNlcCAyNiwg MjAxOSwgYXQgODozMCBBTSwgQWFyb24gUGFyZWNraSA8YWFyb25AcGFyZWNraS5jb208bWFpbHRv OmFhcm9uQHBhcmVja2kuY29tPj4gd3JvdGU6DQoNCkhpIFRvcnN0ZW4sDQoNCkknbSB2ZXJ5IGds YWQgdG8gc2VlIHRoaXMgZHJhZnQsIEkgdGhpbmsgaXQncyBkZWZpbml0ZWx5IG5lZWRlZCBpbg0K dGhpcyBzcGFjZS4gSGVyZSBhcmUgc29tZSBvZiBteSB0aG91Z2h0cyBvbiB0aGUgZHJhZnQuDQoN CiJyZXF1ZXN0X3VyaSI6ICJ1cm46ZXhhbXBsZTpid2M0SkstRVNDMHc4YWNjMTkxZS1ZMUxUQzIi DQoNCklzIGl0IGFjY2VwdGFibGUgZm9yIHRoZSBBUyB0byByZXR1cm4ganVzdCBhbiBvcGFxdWUg c3RyaW5nLCByYXRoZXINCnRoYW4gc29tZXRoaW5nIHByZWZpeGVkIHdpdGggInVyaToqIj8gSSBk b24ndCB0aGluayBhbnlvbmUgd291bGQgYmUNCmNvbmZ1c2VkIGFib3V0IGNvcHlwYXN0aW5nIHRo ZSBleGFjdCBzdHJpbmcgZnJvbSB0aGUgInJlcXVlc3RfdXJpIg0KcmVzcG9uc2UgaW50byB0aGUg InJlcXVlc3RfdXJpIiBwYXJhbWV0ZXIgZXZlbiBpZiBpdCBkaWRuJ3Qgc3RhcnQgd2l0aA0KInVy bjoiLiBJZiwgZm9yIHdoYXRldmVyIHJlYXNvbiwgaXQgaXMgcmVxdWlyZWQgdGhhdCB0aGlzIHZh bHVlIGlzDQphY3R1YWxseSBhIFVSSSwgaXMgdGhlcmUgc29tZSBleHBlY3RlZCBuYW1lc3BhY2Ug dG8gdXNlIG90aGVyIHRoYW4NCiJleGFtcGxlIj8gSSB3b3JyeSB0aGF0IGlmIGFsbCB0aGUgZXhh bXBsZXMgaW4gdGhlIHNwZWMgYXJlIGp1c3QNCiJ1cm46ZXhhbXBsZTpid2M0SkstRVNDMHc4YWNj MTkxZS1ZMUxUQzIiIHRoZW4gZGV2ZWxvcGVycyB3aWxsIGVuZCB1cA0KdXNpbmcgdGhlIHRleHQg ImV4YW1wbGUiIGJlY2F1c2UgdGhleSBkb24ndCB1bmRlcnN0YW5kIHdoeSBpdCdzIHRoZXJlLA0K YW5kIHRoZW4gaXQgc2VydmVzIG5vIHB1cnBvc2UgcmVhbGx5LuKAmQ0KDQpUaGlzIGZpZWxkIG11 c3QgYmUgYSBVUkksIGFzIHBlciBKQVI6DQoNCg0KICAgcmVxdWVzdF91cmkgIFRoZSBhYnNvbHV0 ZSBVUkkgYXMgZGVmaW5lZCBieSBSRkMzOTg2PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmMzOTg2PiBbUkZDMzk4NjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzk4Nj5dIHRo YXQNCiAgICAgIHBvaW50cyB0byB0aGUgUmVxdWVzdCBPYmplY3QgKFNlY3Rpb24gMi4xPGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0xOSNzZWN0aW9u LTIuMT4pIHRoYXQgaG9sZHMNCiAgICAgIGF1dGhvcml6YXRpb24gcmVxdWVzdCBwYXJhbWV0ZXJz IHN0YXRlZCBpbiBzZWN0aW9uIDQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtb2F1dGgtandzcmVxLTE5I3NlY3Rpb24tND4gb2YgT0F1dGggMi4wDQogICAgICBbUkZDNjc0 OTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OT5dLg0KDQoNClNvbWV3aGF0IGF3 a3dhcmRseSwgdGhlIEpBUiBzcGVjIGN1cnJlbnRseSBzdGF0ZXMgdGhhdCB0aGUgQVMgaGFzIHRv IGRvIGFuIEhUVFAgR0VUIG9uIHRoZSByZXF1ZXN0IFVSSSwgc28gdGhhdCB3aWxsIG5lZWQgdG8g YmUgZml4ZWQgaW4gSkFSIGJlZm9yZSBpdCBnb2VzIGZvcndhcmQuIEkgZG9u4oCZdCB0aGluayB0 aGF0IHdhcyBhbHdheXMgdGhlIGNhc2UgdGhvdWdoLCBhbmQgSeKAmW0gbm90IHN1cmUgaG93IHRo YXQgY2hhbmdlZC4NCg0KQXMgZm9yIHRoZSBuYW1lc3BhY2UsIOKAnGV4YW1wbGXigJ0gaXMgb2sg Zm9yIGFuIGV4YW1wbGUgVVJOLiBUaGUgcHJvYmxlbSB3aXRoIFVSTnMgaXMgdGhhdCBub2JvZHkg cmVhbGx5IHVuZGVyc3RhbmRzIGhvdyB0byBkbyBkb21haW4tc2FmZSBmdWxseSBjb21wbGlhbnQg VVJOcy4gU28gcGVyaGFwcyB3ZSBzaG91bGQgaW5zdGVhZCB1c2Ug4oCcdXJuOmZkYzpleGFtcGxl LmNvbTxodHRwOi8vZXhhbXBsZS5jb20+OuKApi7igJ0gSW5zdGVhZCAoYXMgcGVyIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MTk4KS4NCg0KDQpUaGUgcHVzaGVkIGF1dGhvcml6YXRp b24gcmVxdWVzdCBlbmRwb2ludCBzaGFsbCBiZSBhIFJFU1RmdWwgQVBJDQoNCkkgd291bGQgZHJv cCB0aGUgdGVybSBSRVNUZnVsIGFuZCBqdXN0IHNheSAiSFRUUCBBUEkiLCBhcyB0aGlzDQpkZXNj cmlwdGlvbiBpcyBhcmd1YWJseSBSRVNUZnVsIGF0IGJlc3QuDQoNCkRlcGVuZGluZyBvbiBjbGll bnQgdHlwZSBhbmQgYXV0aGVudGljYXRpb24gbWV0aG9kLCB0aGUgcmVxdWVzdCBtaWdodA0KIGFs c28gaW5jbHVkZSB0aGUgImNsaWVudF9pZCIgcGFyYW1ldGVyLg0KDQpJIGFzc3VtZSB0aGlzIGlz IGhpbnRpbmcgYXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBwdWJsaWMgY2xpZW50cw0Kc2VuZGlu ZyBvbmx5IHRoZSAiY2xpZW50X2lkIiBwYXJhbWV0ZXIgYW5kIGNvbmZpZGVudGlhbCBjbGllbnRz DQpzZW5kaW5nIG9ubHkgdGhlIEhUVFAgQmFzaWMgQXV0aG9yaXphdGlvbiBoZWFkZXIgd2hpY2gg aW5jbHVkZXMgYm90aA0KdGhlIGNsaWVudCBJRCBhbmQgc2VjcmV0PyBJdCB3b3VsZCBwcm9iYWJs eSBiZSBoZWxwZnVsIHRvIGNhbGwgb3V0DQp0aGVzZSB0d28gY29tbW9uIGV4YW1wbGVzIGlmIEkg YW0gdW5kZXJzdGFuZGluZyB0aGlzIGNvcnJlY3RseSwNCm90aGVyd2lzZSBpdCBzZWVtcyBwcmV0 dHkgdmFndWUuDQoNCk5vdCBxdWl0ZSwgdGhvc2UgZGlmZmVyZW5jZXMgYXJlIGZvciB0aGUgdG9r ZW4gZW5kcG9pbnQsIGFuZCB0aGlzIGlzIGNhcHR1cmluZyB0aGluZ3MgZnJvbSB0aGUgYXV0aG9y aXphdGlvbiBlbmRwb2ludC4gSSBkb27igJl0IHF1aXRlIHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVu dGlhdGlvbiBsaXN0ZWQgaGVyZSBlaXRoZXIsIHRob3VnaC4NCg0KDQpUaGUgInJlcXVlc3RfdXJp IiB2YWx1ZSBNVVNUIGJlIGdlbmVyYXRlZCB1c2luZyBhIGNyeXB0b2dyYXBoaWNhbGx5DQogc3Ry b25nIHBzZXVkb3JhbmRvbSBhbGdvcml0aG0NCg0KSSBhc3N1bWUgdGhpcyBpbmNsdWRlcyB0aGUg dXNlIG9mIGEgcmFuZG9tIG51bWJlciBpbnNpZGUgb2YgYSBKV1QsIGluDQpjYXNlIHRoZSBBUyB3 YW50cyB0byB1c2UgSldUcyBhcyB0aGUgInJlcXVlc3RfdXJpIiBwYXJhbWV0ZXIiPyBJZiBzbywN Cml0J3MgcHJvYmFibHkgd29ydGggc3BlbGxpbmcgdGhhdCBvdXQgYXMgaXQga2luZCBvZiByZWFk cyBsaWtlIGl0IGhhcw0KdG8gYmUgbGl0ZXJhbGx5IGEgcmFuZG9tIHN0cmluZyBhdCBmaXJzdCBn bGFuY2UuDQoNClRoZSBVUkkgaXMgaW50ZW5kZWQgdG8gYmUgYSByZWZlcmVuY2Ugbm90IGEgdmFs dWUuIElmIHRoZSBjbGllbnQgY291bGQgc2VuZCBhIEpXVCBpdCB3b3VsZCBqdXN0IHNlbmQgYSBy ZXF1ZXN0IG9iamVjdCBpbnN0ZWFkIG9mIGEgcmVxdWVzdCBVUkkgaW4gdGhlIGZpcnN0IHBsYWNl LiBTbyB0aGUgaW50ZW50IGlzIHRoYXQgaXTigJlzIHJhbmRvbSwgYW5kIG1heWJlIHdlIHNob3Vs ZCBqdXN0IHNheSB0aGF0IGV4cGxpY2l0bHkuDQoNCg0KVGhhdCdzIGFsbCBmb3Igbm93LCB0aGFu a3MhDQoNCi0tLS0NCkFhcm9uIFBhcmVja2kNCmFhcm9ucGFyZWNraS5jb208aHR0cDovL2Fhcm9u cGFyZWNraS5jb20+DQpAYWFyb25waw0KDQpPbiBTYXQsIFNlcCAyMSwgMjAxOSBhdCAxOjAyIFBN IFRvcnN0ZW4gTG9kZGVyc3RlZHQNCjx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6DQoN CkhpIGFsbCwNCg0KSSBqdXN0IHB1Ymxpc2hlZCBhIG5ldyBkcmFmdCB0aGF0IEJyaWFuIENhbXBi ZWxsLCBEYXZlIFRvbmdlLCBGaWxpcCBTa29rYW4sIE5hdCBTYWtpbXVyYSBhbmQgSSB3cm90ZS4N Cg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXBh ci0wMA0KDQpJdCBwcm9wb3NlcyBhIG5ldyBlbmRwb2ludCwgY2FsbGVkICJwdXNoZWQgYXV0aG9y aXphdGlvbiByZXF1ZXN0IGVuZHBvaW504oCdLCB0aGF0IGFsbG93cyB0aGUgY2xpZW50IHRvIHB1 c2ggdGhlIEF1dGhvcml6YXRpb24gUmVxdWVzdCBwYXlsb2FkIHdpdGggdGhlIEFTIG9uIGEgYmFj a2NoYW5uZWwgY29ubmVjdGlvbiBpbnN0ZWFkIG9mIGEgZnJvbnQgY2hhbm5lbCBpbnRlcmFjdGlv bi4gVGhlIEFTIHByb3ZpZGVzIHRoZSBjbGllbnQgd2l0aCBhIHJlcXVlc3QgVVJJIChhY2NvcmRp bmcgdG8gZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEpIHRoYXQgdGhlIGNsaWVudCB1c2VzIGluIGEg c3Vic2VxdWVudCBhdXRob3JpemF0aW9uIHJlcXVlc3RzIHRvIHJlZmVyIHRvIHRoZSBwdXNoZWQg cmVxdWVzdCBkYXRhLg0KDQpXZSBiZWxpZXZlIHRoaXMgc2ltcGxlIG1lY2hhbmlzbSB3aWxsIHNp Z25pZmljYW50bHkgaW5jcmVhc2UgT0F1dGggc2VjdXJpdHkgYW5kIHJvYnVzdG5lc3Mgc2luY2Ug YW55IGFwcGxpY2F0aW9uIGNhbiB1c2UgaXQgYnkganVzdCBzZW5kaW5nIHRoZSBwYXJhbWV0ZXJz IGluIHRoZSBzYW1lIGVuY29kaW5nIGFzIHVzZWQgYXQgdGhlIGF1dGhvcmlzYXRpb24gZW5kcG9p bnQgb3ZlciBhIEhUVFBTLXByb3RlY3RlZCBhbmQgKGZvciBjb25maWRlbnRpYWwgY2xpZW50cykg bXV0dWFsbHkgYXV0aGVudGljYXRlZCBjb25uZWN0aW9uIHRvIHRoZSBBUy4gSXQgY2FuIGFsc28g YmUgdXNlZCB0byBwdXNoIHNpZ25lZCBhbmQgZW5jcnlwdGVkIHJlcXVlc3Qgb2JqZWN0cyB0byB0 aGUgQVMsIGkuZS4gaXQgcHJvdmlkZXMgYW4gaW50ZXJvcGVyYWJsZSB3YXkgdG8gdXNlIHJlcXVl c3Qgb2JqZWN0cyBtYW5hZ2VkIGF0IHRoZSBBUyBmb3IgdXNlIGNhc2VzIHJlcXVpcmluZyBhbiBl dmVuIGhpZ2hlciBzZWN1cml0eSBsZXZlbC4NCg0KV2UgbG9vayBmb3J3YXJkIHRvIGdldHRpbmcg eW91ciBmZWVkYmFjay4NCg0Ka2luZCByZWdhcmRzLA0KVG9yc3Rlbi4NCg0KQmVnaW4gZm9yd2Fy ZGVkIG1lc3NhZ2U6DQoNCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1wYXIt MDAudHh0DQpEYXRlOiAyMS4gU2VwdGVtYmVyIDIwMTkgYXQgMTI6NDc6MjggQ0VTVA0KVG86ICJO YXQgU2FraW11cmEiIDxuYXRAc2FraW11cmEub3JnPiwgIkJyaWFuIENhbXBiZWxsIiA8YmNhbXBi ZWxsQHBpbmdpZGVudGl0eS5jb20+LCAiVG9yc3RlbiBMb2RkZXJzdGVkdCIgPHRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0PiwgIkRhdmUgVG9uZ2UiIDxkYXZlQHRvbmdlLm9yZz4sICJGaWxpcCBTa29r YW4iIDxwYW52YS5pcEBnbWFpbC5jb20+DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LWxvZGRlcnN0ZWR0LW9hdXRoLXBhci0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgVG9yc3RlbiBMb2RkZXJzdGVkdCBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBv c2l0b3J5Lg0KDQpOYW1lOiBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1wYXINClJldmlzaW9uOiAw MA0KVGl0bGU6IE9BdXRoIDIuMCBQdXNoZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0cw0KRG9jdW1l bnQgZGF0ZTogMjAxOS0wOS0yMQ0KR3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6 IDEyDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXBhci0wMC50eHQNClN0YXR1czogICAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1wYXIv DQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvZGRl cnN0ZWR0LW9hdXRoLXBhci0wMA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcGFyDQoNCg0KQWJzdHJh Y3Q6DQogVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBwdXNoZWQgYXV0aG9yaXphdGlvbiByZXF1 ZXN0IGVuZHBvaW50LA0KIHdoaWNoIGFsbG93cyBjbGllbnRzIHRvIHB1c2ggdGhlIHBheWxvYWQg b2YgYW4gT0F1dGggMi4wDQogYXV0aG9yaXphdGlvbiByZXF1ZXN0IHRvIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciB2aWEgYSBkaXJlY3QNCiByZXF1ZXN0IGFuZCBwcm92aWRlcyB0aGVtIHdpdGgg YSByZXF1ZXN0IFVSSSB0aGF0IGlzIHVzZWQgYXMNCiByZWZlcmVuY2UgdG8gdGhlIGRhdGEgaW4g YSBzdWJzZXF1ZW50IGF1dGhvcml6YXRpb24gcmVxdWVzdC4NCg0KDQoNCg0KUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBs aXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_BB0AE29D5CD04441B3B6FEB6D3F749EEmitedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkFhcm9uLCBzb21lIGNvbW1lbnRzIGlubGluZS4m bmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog YXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v bmU7Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gU2VwIDI2LCAy MDE5LCBhdCA4OjMwIEFNLCBBYXJvbiBQYXJlY2tpICZsdDs8YSBocmVmPSJtYWlsdG86YWFyb25A cGFyZWNraS5jb20iIGNsYXNzPSIiPmFhcm9uQHBhcmVja2kuY29tPC9hPiZndDsgd3JvdGU6PC9k aXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+SGkgVG9yc3Rlbiw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpJJ20gdmVyeSBnbGFkIHRvIHNlZSB0aGlzIGRyYWZ0LCBJIHRoaW5rIGl0J3MgZGVmaW5pdGVs eSBuZWVkZWQgaW48YnIgY2xhc3M9IiI+DQp0aGlzIHNwYWNlLiBIZXJlIGFyZSBzb21lIG9mIG15 IHRob3VnaHRzIG9uIHRoZSBkcmFmdC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4mcXVvdDtyZXF1ZXN0X3VyaSZxdW90OzogJnF1 b3Q7dXJuOmV4YW1wbGU6YndjNEpLLUVTQzB3OGFjYzE5MWUtWTFMVEMyJnF1b3Q7PGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSXMgaXQgYWNjZXB0YWJsZSBmb3Ig dGhlIEFTIHRvIHJldHVybiBqdXN0IGFuIG9wYXF1ZSBzdHJpbmcsIHJhdGhlcjxiciBjbGFzcz0i Ij4NCnRoYW4gc29tZXRoaW5nIHByZWZpeGVkIHdpdGggJnF1b3Q7dXJpOiomcXVvdDs/IEkgZG9u J3QgdGhpbmsgYW55b25lIHdvdWxkIGJlPGJyIGNsYXNzPSIiPg0KY29uZnVzZWQgYWJvdXQgY29w eXBhc3RpbmcgdGhlIGV4YWN0IHN0cmluZyBmcm9tIHRoZSAmcXVvdDtyZXF1ZXN0X3VyaSZxdW90 OzxiciBjbGFzcz0iIj4NCnJlc3BvbnNlIGludG8gdGhlICZxdW90O3JlcXVlc3RfdXJpJnF1b3Q7 IHBhcmFtZXRlciBldmVuIGlmIGl0IGRpZG4ndCBzdGFydCB3aXRoPGJyIGNsYXNzPSIiPg0KJnF1 b3Q7dXJuOiZxdW90Oy4gSWYsIGZvciB3aGF0ZXZlciByZWFzb24sIGl0IGlzIHJlcXVpcmVkIHRo YXQgdGhpcyB2YWx1ZSBpczxiciBjbGFzcz0iIj4NCmFjdHVhbGx5IGEgVVJJLCBpcyB0aGVyZSBz b21lIGV4cGVjdGVkIG5hbWVzcGFjZSB0byB1c2Ugb3RoZXIgdGhhbjxiciBjbGFzcz0iIj4NCiZx dW90O2V4YW1wbGUmcXVvdDs/IEkgd29ycnkgdGhhdCBpZiBhbGwgdGhlIGV4YW1wbGVzIGluIHRo ZSBzcGVjIGFyZSBqdXN0PGJyIGNsYXNzPSIiPg0KJnF1b3Q7dXJuOmV4YW1wbGU6YndjNEpLLUVT QzB3OGFjYzE5MWUtWTFMVEMyJnF1b3Q7IHRoZW4gZGV2ZWxvcGVycyB3aWxsIGVuZCB1cDxiciBj bGFzcz0iIj4NCnVzaW5nIHRoZSB0ZXh0ICZxdW90O2V4YW1wbGUmcXVvdDsgYmVjYXVzZSB0aGV5 IGRvbid0IHVuZGVyc3RhbmQgd2h5IGl0J3MgdGhlcmUsPGJyIGNsYXNzPSIiPg0KYW5kIHRoZW4g aXQgc2VydmVzIG5vIHB1cnBvc2UgcmVhbGx5LuKAmTwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGlzIGZpZWxkIG11c3QgYmUg YSBVUkksIGFzIHBlciBKQVI6PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp dj48L2Rpdj4NCjxkaXY+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIj4gICByZXF1ZXN0X3VyaSAgVGhl IGFic29sdXRlIFVSSSBhcyBkZWZpbmVkIGJ5IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmMzOTg2IiBjbGFzcz0iIj5SRkMzOTg2PC9hPiBbPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzM5ODYiIHRpdGxlPSImcXVvdDtVbmlmb3JtIFJlc291cmNl IElkZW50aWZpZXIgKFVSSSk6IEdlbmVyaWMgU3ludGF4JnF1b3Q7IiBjbGFzcz0iIj5SRkMzOTg2 PC9hPl0gdGhhdA0KICAgICAgcG9pbnRzIHRvIHRoZSBSZXF1ZXN0IE9iamVjdCAoPGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTE5I3Nl Y3Rpb24tMi4xIiBjbGFzcz0iIj5TZWN0aW9uIDIuMTwvYT4pIHRoYXQgaG9sZHMNCiAgICAgIGF1 dGhvcml6YXRpb24gcmVxdWVzdCBwYXJhbWV0ZXJzIHN0YXRlZCBpbiA8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMTkjc2VjdGlvbi00 IiBjbGFzcz0iIj5zZWN0aW9uIDQ8L2E+IG9mIE9BdXRoIDIuMA0KICAgICAgWzxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5IiB0aXRsZT0iJnF1b3Q7VGhlIE9BdXRo IDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29yayZxdW90OyIgY2xhc3M9IiI+UkZDNjc0OTwvYT5d Lg0KPC9wcmU+DQo8ZGl2IGNsYXNzPSIiPlNvbWV3aGF0IGF3a3dhcmRseSwgdGhlIEpBUiBzcGVj IGN1cnJlbnRseSBzdGF0ZXMgdGhhdCB0aGUgQVMgaGFzIHRvIGRvIGFuIEhUVFAgR0VUIG9uIHRo ZSByZXF1ZXN0IFVSSSwgc28gdGhhdCB3aWxsIG5lZWQgdG8gYmUgZml4ZWQgaW4gSkFSIGJlZm9y ZSBpdCBnb2VzIGZvcndhcmQuIEkgZG9u4oCZdCB0aGluayB0aGF0IHdhcyBhbHdheXMgdGhlIGNh c2UgdGhvdWdoLCBhbmQgSeKAmW0gbm90IHN1cmUgaG93IHRoYXQgY2hhbmdlZC4mbmJzcDs8L2Rp dj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+QXMgZm9yIHRoZSBu YW1lc3BhY2UsIOKAnGV4YW1wbGXigJ0gaXMgb2sgZm9yIGFuIGV4YW1wbGUgVVJOLiBUaGUgcHJv YmxlbSB3aXRoIFVSTnMgaXMgdGhhdCBub2JvZHkgcmVhbGx5IHVuZGVyc3RhbmRzIGhvdyB0byBk byBkb21haW4tc2FmZSBmdWxseSBjb21wbGlhbnQgVVJOcy4gU28gcGVyaGFwcyB3ZSBzaG91bGQg aW5zdGVhZCB1c2Ug4oCcdXJuOmZkYzo8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20iIGNsYXNz PSIiPmV4YW1wbGUuY29tPC9hPjrigKYu4oCdDQogSW5zdGVhZCAoYXMgcGVyJm5ic3A7PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQxOTgiIGNsYXNzPSIiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MTk4PC9hPikuJm5ic3A7PC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPlRoZSBwdXNoZWQgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGVuZHBvaW50IHNoYWxsIGJlIGEg UkVTVGZ1bCBBUEk8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpJ IHdvdWxkIGRyb3AgdGhlIHRlcm0gUkVTVGZ1bCBhbmQganVzdCBzYXkgJnF1b3Q7SFRUUCBBUEkm cXVvdDssIGFzIHRoaXM8YnIgY2xhc3M9IiI+DQpkZXNjcmlwdGlvbiBpcyBhcmd1YWJseSBSRVNU ZnVsIGF0IGJlc3QuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+RGVwZW5kaW5nIG9uIGNsaWVudCB0eXBlIGFuZCBhdXRoZW50aWNh dGlvbiBtZXRob2QsIHRoZSByZXF1ZXN0IG1pZ2h0PGJyIGNsYXNzPSIiPg0KJm5ic3A7YWxzbyBp bmNsdWRlIHRoZSAmcXVvdDtjbGllbnRfaWQmcXVvdDsgcGFyYW1ldGVyLjxiciBjbGFzcz0iIj4N CjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkkgYXNzdW1lIHRoaXMgaXMgaGludGluZyBh dCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHB1YmxpYyBjbGllbnRzPGJyIGNsYXNzPSIiPg0Kc2Vu ZGluZyBvbmx5IHRoZSAmcXVvdDtjbGllbnRfaWQmcXVvdDsgcGFyYW1ldGVyIGFuZCBjb25maWRl bnRpYWwgY2xpZW50czxiciBjbGFzcz0iIj4NCnNlbmRpbmcgb25seSB0aGUgSFRUUCBCYXNpYyBB dXRob3JpemF0aW9uIGhlYWRlciB3aGljaCBpbmNsdWRlcyBib3RoPGJyIGNsYXNzPSIiPg0KdGhl IGNsaWVudCBJRCBhbmQgc2VjcmV0PyBJdCB3b3VsZCBwcm9iYWJseSBiZSBoZWxwZnVsIHRvIGNh bGwgb3V0PGJyIGNsYXNzPSIiPg0KdGhlc2UgdHdvIGNvbW1vbiBleGFtcGxlcyBpZiBJIGFtIHVu ZGVyc3RhbmRpbmcgdGhpcyBjb3JyZWN0bHksPGJyIGNsYXNzPSIiPg0Kb3RoZXJ3aXNlIGl0IHNl ZW1zIHByZXR0eSB2YWd1ZS48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+Tm90IHF1aXRlLCB0aG9zZSBk aWZmZXJlbmNlcyBhcmUgZm9yIHRoZSB0b2tlbiBlbmRwb2ludCwgYW5kIHRoaXMgaXMgY2FwdHVy aW5nIHRoaW5ncyBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBJIGRvbuKAmXQgcXVp dGUgdW5kZXJzdGFuZCB0aGUgZGlmZmVyZW50aWF0aW9uIGxpc3RlZCBoZXJlIGVpdGhlciwgdGhv dWdoLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5UaGUgJnF1b3Q7cmVxdWVzdF91cmkmcXVvdDsgdmFs dWUgTVVTVCBiZSBnZW5lcmF0ZWQgdXNpbmcgYSBjcnlwdG9ncmFwaGljYWxseTxiciBjbGFzcz0i Ij4NCiZuYnNwO3N0cm9uZyBwc2V1ZG9yYW5kb20gYWxnb3JpdGhtPGJyIGNsYXNzPSIiPg0KPC9i bG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSSBhc3N1bWUgdGhpcyBpbmNsdWRlcyB0aGUgdXNl IG9mIGEgcmFuZG9tIG51bWJlciBpbnNpZGUgb2YgYSBKV1QsIGluPGJyIGNsYXNzPSIiPg0KY2Fz ZSB0aGUgQVMgd2FudHMgdG8gdXNlIEpXVHMgYXMgdGhlICZxdW90O3JlcXVlc3RfdXJpJnF1b3Q7 IHBhcmFtZXRlciZxdW90Oz8gSWYgc28sPGJyIGNsYXNzPSIiPg0KaXQncyBwcm9iYWJseSB3b3J0 aCBzcGVsbGluZyB0aGF0IG91dCBhcyBpdCBraW5kIG9mIHJlYWRzIGxpa2UgaXQgaGFzPGJyIGNs YXNzPSIiPg0KdG8gYmUgbGl0ZXJhbGx5IGEgcmFuZG9tIHN0cmluZyBhdCBmaXJzdCBnbGFuY2Uu PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoZSBVUkkgaXMgaW50ZW5kZWQgdG8gYmUgYSByZWZlcmVu Y2Ugbm90IGEgdmFsdWUuIElmIHRoZSBjbGllbnQgY291bGQgc2VuZCBhIEpXVCBpdCB3b3VsZCBq dXN0IHNlbmQgYSByZXF1ZXN0IG9iamVjdCBpbnN0ZWFkIG9mIGEgcmVxdWVzdCBVUkkgaW4gdGhl IGZpcnN0IHBsYWNlLiBTbyB0aGUgaW50ZW50IGlzIHRoYXQgaXTigJlzIHJhbmRvbSwgYW5kIG1h eWJlIHdlIHNob3VsZCBqdXN0IHNheSB0aGF0IGV4cGxpY2l0bHkuJm5ic3A7PC9kaXY+DQo8YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NClRoYXQncyBhbGwgZm9yIG5vdywgdGhh bmtzITxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tLS08YnIgY2xhc3M9IiI+DQpBYXJv biBQYXJlY2tpPGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cDovL2Fhcm9ucGFyZWNraS5jb20i IGNsYXNzPSIiPmFhcm9ucGFyZWNraS5jb208L2E+PGJyIGNsYXNzPSIiPg0KQGFhcm9ucGs8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiBTYXQsIFNlcCAyMSwgMjAxOSBhdCAxOjAyIFBN IFRvcnN0ZW4gTG9kZGVyc3RlZHQ8YnIgY2xhc3M9IiI+DQombHQ7dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQmZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCkhpIGFsbCw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpJIGp1c3QgcHVibGlzaGVkIGEgbmV3IGRyYWZ0IHRoYXQgQnJpYW4gQ2FtcGJlbGwsIERhdmUg VG9uZ2UsIEZpbGlwIFNrb2thbiwgTmF0IFNha2ltdXJhIGFuZCBJIHdyb3RlLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sb2Rk ZXJzdGVkdC1vYXV0aC1wYXItMDA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJdCBwcm9w b3NlcyBhIG5ldyBlbmRwb2ludCwgY2FsbGVkICZxdW90O3B1c2hlZCBhdXRob3JpemF0aW9uIHJl cXVlc3QgZW5kcG9pbnTigJ0sIHRoYXQgYWxsb3dzIHRoZSBjbGllbnQgdG8gcHVzaCB0aGUgQXV0 aG9yaXphdGlvbiBSZXF1ZXN0IHBheWxvYWQgd2l0aCB0aGUgQVMgb24gYSBiYWNrY2hhbm5lbCBj b25uZWN0aW9uIGluc3RlYWQgb2YgYSBmcm9udCBjaGFubmVsIGludGVyYWN0aW9uLiBUaGUgQVMg cHJvdmlkZXMgdGhlIGNsaWVudCB3aXRoIGEgcmVxdWVzdA0KIFVSSSAoYWNjb3JkaW5nIHRvIGRy YWZ0LWlldGYtb2F1dGgtandzcmVxKSB0aGF0IHRoZSBjbGllbnQgdXNlcyBpbiBhIHN1YnNlcXVl bnQgYXV0aG9yaXphdGlvbiByZXF1ZXN0cyB0byByZWZlciB0byB0aGUgcHVzaGVkIHJlcXVlc3Qg ZGF0YS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpXZSBiZWxpZXZlIHRoaXMgc2ltcGxl IG1lY2hhbmlzbSB3aWxsIHNpZ25pZmljYW50bHkgaW5jcmVhc2UgT0F1dGggc2VjdXJpdHkgYW5k IHJvYnVzdG5lc3Mgc2luY2UgYW55IGFwcGxpY2F0aW9uIGNhbiB1c2UgaXQgYnkganVzdCBzZW5k aW5nIHRoZSBwYXJhbWV0ZXJzIGluIHRoZSBzYW1lIGVuY29kaW5nIGFzIHVzZWQgYXQgdGhlIGF1 dGhvcmlzYXRpb24gZW5kcG9pbnQgb3ZlciBhIEhUVFBTLXByb3RlY3RlZCBhbmQgKGZvciBjb25m aWRlbnRpYWwNCiBjbGllbnRzKSBtdXR1YWxseSBhdXRoZW50aWNhdGVkIGNvbm5lY3Rpb24gdG8g dGhlIEFTLiBJdCBjYW4gYWxzbyBiZSB1c2VkIHRvIHB1c2ggc2lnbmVkIGFuZCBlbmNyeXB0ZWQg cmVxdWVzdCBvYmplY3RzIHRvIHRoZSBBUywgaS5lLiBpdCBwcm92aWRlcyBhbiBpbnRlcm9wZXJh YmxlIHdheSB0byB1c2UgcmVxdWVzdCBvYmplY3RzIG1hbmFnZWQgYXQgdGhlIEFTIGZvciB1c2Ug Y2FzZXMgcmVxdWlyaW5nIGFuIGV2ZW4gaGlnaGVyIHNlY3VyaXR5DQogbGV2ZWwuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KV2UgbG9vayBmb3J3YXJkIHRvIGdldHRpbmcgeW91ciBmZWVk YmFjay48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpraW5kIHJlZ2FyZHMsPGJyIGNsYXNz PSIiPg0KVG9yc3Rlbi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCZWdpbiBmb3J3YXJk ZWQgbWVzc2FnZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpGcm9tOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc8YnIgY2xhc3M9IiI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXBhci0wMC50eHQ8YnIgY2xhc3M9IiI+ DQpEYXRlOiAyMS4gU2VwdGVtYmVyIDIwMTkgYXQgMTI6NDc6MjggQ0VTVDxiciBjbGFzcz0iIj4N ClRvOiAmcXVvdDtOYXQgU2FraW11cmEmcXVvdDsgJmx0O25hdEBzYWtpbXVyYS5vcmcmZ3Q7LCAm cXVvdDtCcmlhbiBDYW1wYmVsbCZxdW90OyAmbHQ7YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20m Z3Q7LCAmcXVvdDtUb3JzdGVuIExvZGRlcnN0ZWR0JnF1b3Q7ICZsdDt0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldCZndDssICZxdW90O0RhdmUgVG9uZ2UmcXVvdDsgJmx0O2RhdmVAdG9uZ2Uub3JnJmd0 OywgJnF1b3Q7RmlsaXAgU2tva2FuJnF1b3Q7ICZsdDtwYW52YS5pcEBnbWFpbC5jb20mZ3Q7PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXBhci0wMC50eHQ8YnIgY2xhc3M9IiI+DQpo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRvcnN0ZW4gTG9kZGVyc3RlZHQgYW5k IHBvc3RlZCB0byB0aGU8YnIgY2xhc3M9IiI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KTmFtZTogZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcGFyPGJyIGNs YXNzPSIiPg0KUmV2aXNpb246IDAwPGJyIGNsYXNzPSIiPg0KVGl0bGU6IE9BdXRoIDIuMCBQdXNo ZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0czxiciBjbGFzcz0iIj4NCkRvY3VtZW50IGRhdGU6IDIw MTktMDktMjE8YnIgY2xhc3M9IiI+DQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyIGNs YXNzPSIiPg0KUGFnZXM6IDEyPGJyIGNsYXNzPSIiPg0KVVJMOiAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtodHRwczovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcGFyLTAw LnR4dDxiciBjbGFzcz0iIj4NClN0YXR1czogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt bG9kZGVyc3RlZHQtb2F1dGgtcGFyLzxiciBjbGFzcz0iIj4NCkh0bWxpemVkOiAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtbG9kZGVyc3RlZHQtb2F1dGgtcGFyLTAwPGJyIGNsYXNzPSIiPg0KSHRtbGl6ZWQ6ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcGFyPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQWJzdHJhY3Q6PGJyIGNsYXNzPSIiPg0KJm5ic3A7 VGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBwdXNoZWQgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGVu ZHBvaW50LDxiciBjbGFzcz0iIj4NCiZuYnNwO3doaWNoIGFsbG93cyBjbGllbnRzIHRvIHB1c2gg dGhlIHBheWxvYWQgb2YgYW4gT0F1dGggMi4wPGJyIGNsYXNzPSIiPg0KJm5ic3A7YXV0aG9yaXph dGlvbiByZXF1ZXN0IHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB2aWEgYSBkaXJlY3Q8YnIg Y2xhc3M9IiI+DQombmJzcDtyZXF1ZXN0IGFuZCBwcm92aWRlcyB0aGVtIHdpdGggYSByZXF1ZXN0 IFVSSSB0aGF0IGlzIHVzZWQgYXM8YnIgY2xhc3M9IiI+DQombmJzcDtyZWZlcmVuY2UgdG8gdGhl IGRhdGEgaW4gYSBzdWJzZXF1ZW50IGF1dGhvcml6YXRpb24gcmVxdWVzdC48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyIGNsYXNzPSIiPg0KdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0PGJy IGNsYXNzPSIiPg0KT0F1dGhAaWV0Zi5vcmc8YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0K PGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQpPQXV0 aEBpZXRmLm9yZzxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BB0AE29D5CD04441B3B6FEB6D3F749EEmitedu_-- From nobody Thu Sep 26 09:57:15 2019 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 A8E991200B3 for ; Thu, 26 Sep 2019 09:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=parecki-com.20150623.gappssmtp.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 OX2VM3juuA7A for ; Thu, 26 Sep 2019 09:57:10 -0700 (PDT) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 42B92120019 for ; Thu, 26 Sep 2019 09:57:10 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id r26so8357394ioh.8 for ; Thu, 26 Sep 2019 09:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=crqXFNAGokfpim5g6mD2Y5YPJW2lvVV8N8/M+wq2oss=; b=icJZopPnPGNWEivodvoR5bkT5kxuH2DY6NGEVE4SRa7MaHrvugxErI3gkrCNbVNNHt QYJczSGQQEzk95U1TFDzAzBJSzDi6pf660cFxe0eVujpK1q/Yon3o8zHRjRF6PC0nrYE C/SVANQ94XHHGv+64EDPteXc1FAvGqoHR0a8KLxo71iTnDZTCg1vPnowK0m1l5JeSMq4 fowsWlWCSyhi2g2Izq1LjFLD7oPYqy+Rgwy5hkNu67b4OGny0z2Z+/6QnX0DE+ZFt33T n44yVu3+f1qiFKRSUp308XL0l71cTF+pozNFyOZogoCz6zWYXJ9AMEpt02zV598Hccqi v8AQ== 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:content-transfer-encoding; bh=crqXFNAGokfpim5g6mD2Y5YPJW2lvVV8N8/M+wq2oss=; b=mc3MN+zBqcdHSFQgT8LWgU7ROUevOeYg+BGVCmHbQVYZgVbdlpStJeaXW6JeNIQd0O wcOK530X3gaJjAeycz/ZX8erWOA3uUMBgTrjFiHqUeVD5h55ivvrBx2YxLwAuhEiljse nteFOoi4o6B0925Ssvb4jOzh7DqxU6lceZZLK2LJeryyPRCcr/uOm8ArrV033DJdeEwK 6elI+Ct5dCoRHwBoTMJXg08b/KuK9iXi6JRYYOELXpqHs6B25lb0+DicOZd0J6xlHB4s 7eYv05WetrOMHL9BU29ZFuhvfdBtJZ+QAZeglRC7eKNVSywb/137W2c3/yKc23mJRtgx bWBg== X-Gm-Message-State: APjAAAVTdo4H6zhj+9ZV9rvHEOC89EmFcVmV3CpEyv6X8bxrX+lg+Rv6 jJ62vzwWTSQE1Kq4PX7mXlD1QbjvhTw= X-Google-Smtp-Source: APXvYqwzx7INgJTddAkd+Tz5hhZ6s1x9vzFEGSVsf1ueJJOxfvaHZRzslCLaLoWBw7JFM/E7qDU8Hg== X-Received: by 2002:a92:1718:: with SMTP id u24mr3569712ill.32.1569517029160; Thu, 26 Sep 2019 09:57:09 -0700 (PDT) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com. [209.85.166.41]) by smtp.gmail.com with ESMTPSA id v4sm828334ilm.24.2019.09.26.09.57.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Sep 2019 09:57:08 -0700 (PDT) Received: by mail-io1-f41.google.com with SMTP id b19so8419794iob.4 for ; Thu, 26 Sep 2019 09:57:08 -0700 (PDT) X-Received: by 2002:a92:98d3:: with SMTP id a80mr3606632ill.167.1569517028182; Thu, 26 Sep 2019 09:57:08 -0700 (PDT) MIME-Version: 1.0 References: <156907504831.22964.1710780113673136607.idtracker@ietfa.amsl.com> <6C8DC22C-2FA8-4582-B3F7-25075370D19D@mit.edu> In-Reply-To: <6C8DC22C-2FA8-4582-B3F7-25075370D19D@mit.edu> From: Aaron Parecki Date: Thu, 26 Sep 2019 18:56:56 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Justin Richer Cc: George Fletcher , Torsten Lodderstedt , oauth Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt 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: Thu, 26 Sep 2019 16:57:14 -0000 This is absolutely something that needs to be mentioned in the security & privacy considerations. My worry is that by leading with an example of account numbers in the request URL, we're sending the wrong message. I do see the value in rich authorization requests with no PII like George described, so I would be happy if: * the example in this draft of the GET request was an example with no PII * there was an additional example using PAR that includes the full bank account transfer in the current draft ---- Aaron Parecki aaronparecki.com On Thu, Sep 26, 2019 at 6:42 PM Justin Richer wrote: > > I agree with George that this is a good fit for a security consideration,= not a normative requirement. While it=E2=80=99s best to always protect the= request data, this isn=E2=80=99t all that much different from having scope= s that might leak personal information. Like for example, asking for access= to HIV information for a health record. It=E2=80=99s made more explicit an= d potentially worse by RAR, but it=E2=80=99s far from unique. > > This combination of issues is part of why XYZ effectively requires a comb= ination of PAR and RAR for all requests. > > =E2=80=94 Justin > > On Sep 26, 2019, at 9:18 AM, George Fletcher wrote: > > This is a great point about personal information. However, there are uses= for authorization_details that don't specifically relate to personal infor= mation. Think an enhancement that has language preference, maybe a device i= dentifier. Maybe we can add more text in the security considerations sectio= n stating that it's best practice to use PAR for any authorization_details = that are considered personal information (PI) or personally identifying inf= ormation (PII) ? > > On 9/26/19 11:02 AM, Aaron Parecki wrote: > > Hi Torsten, > > Overall I am a fan of a way to provide more structure in authorization > requests, and I'm excited to see this draft, so thanks for that. > > I do have some concerns about one aspect of this. Given its clear > intended use as a way to create authorization requests to do things > like transfer money between bank accounts, I don't think it's > appropriate for that kind of data to be sent in the front channel at > all. By encoding a rich authorization request with bank account > numbers and account names in a query string, that opens up several new > opportunities for an attacker to steal private/sensitive information > (browser extensions, proxy servers, etc). > > This differs from the plain OAuth authorization request because > traditionally the request does not include any identifying information > about any user or even about the particular transaction. At most, the > request identifies the client and combination of coarse-grained scopes > the client is requesting, none of which can identify a user. However > with the examples provided in this document, as well as many > additional uses of this mechanism, it includes potentially a lot of > identifying information about users including their name, bank account > numbers, and even relationships to other parties (e.g. creditorName). > When the authorization request is sent to the AS in a URL, regardless > of whether it's in plaintext like the simple example here, or signed > as a JWT request, that data is visible to anything that can access the > URL between the user's device and the AS. This seems like a huge > potential for a privacy leak. > > I realize this draft currently points to JWT Secured Authorization > Requests (JAR) in several places where these concerns come up. The > problem is that JAR doesn't actually *require* an encrypted JWT, so > the privacy implications aren't accounted for here. > > I would much rather see this document require your other recent > submission, Pushed Authorization Requests. Given the privacy > implications, it makes sense to limit the use of rich authorization > requests to pushed authorization requests, so that this rich data is > never made available to intermediaries in the front channel. > > If there is a good reason to continue allowing authorization requests > as a GET without the new pushed request step, then at least I would > want to see RAR require encrypted JWTs as described by JAR. > > Thanks for considering this! > > ---- > Aaron Parecki > aaronparecki.com > > > > On Sat, Sep 21, 2019 at 7:51 PM Torsten Lodderstedt > wrote: > > Hi all, > > I just published a draft about ???OAuth 2.0 Rich Authorization Requests??= ? (formerly known as ???structured scopes???). > > https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 > > It specifies a new parameter ???authorization_details" that is used to ca= rry fine grained authorization data in the OAuth authorization request. Thi= s mechanisms was designed based on experiences gathered in the field of ope= n banking, e.g. PSD2, and is intended to make the implementation of rich an= d transaction oriented authorization requests much easier than with current= OAuth 2.0. > > I???m happy that Justin Richer and Brian Campbell joined me as authors of= this draft. We would would like to thank Daniel Fett, Sebastian Ebling, Da= ve Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable feedbac= k during the preparation of this draft. > > We look forward to getting your feedback. > > kind regards, > Torsten. > > Begin forwarded message: > > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt > Date: 21. September 2019 at 16:10:48 CEST > To: "Justin Richer" , "Torsten Lodderstedt" , "Brian Campbell" > > > A new version of I-D, draft-lodderstedt-oauth-rar-02.txt > has been successfully submitted by Torsten Lodderstedt and posted to the > IETF repository. > > Name: draft-lodderstedt-oauth-rar > Revision: 02 > Title: OAuth 2.0 Rich Authorization Requests > Document date: 2019-09-20 > Group: Individual Submission > Pages: 16 > URL: https://www.ietf.org/internet-drafts/draft-lodderstedt-oa= uth-rar-02.txt > Status: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-= rar/ > Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-0= 2 > Htmlized: https://datatracker.ietf.org/doc/html/draft-lodderstedt-o= auth-rar > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-lodderstedt-oau= th-rar-02 > > Abstract: > This document specifies a new parameter "authorization_details" that > is used to carry fine grained authorization data in the OAuth > authorization request. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > From nobody Thu Sep 26 10:03:57 2019 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 55B7A120846 for ; Thu, 26 Sep 2019 10:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=parecki-com.20150623.gappssmtp.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 bWOTlFV31mFo for ; Thu, 26 Sep 2019 10:03:54 -0700 (PDT) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 E3849120104 for ; Thu, 26 Sep 2019 10:03:53 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id b19so8478094iob.4 for ; Thu, 26 Sep 2019 10:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Qs9G2eaA6ump/WClPbHIXA25o6g9Le7eh4TUUEao6lc=; b=kj08HfTdZwbwg7dQz2bXkbzsdrUzZEUfJeZqk6lb++tCrd0Eb/wkcAhFPzhTXfJCay RuFoiZ/DztITwv6+A33y3TQUdUwuJnlF58UOxo+fYgrSZgLORtva6hnsrChZ7VKZmxv1 tQjvv+E+FF0kW5wisyC26WxNlxD8V1PC2bPVlk4u83Nso7PLW3xDcvH6n8pOhBi/VVmK A0f2yOPJTS3Ju0AFzzakO5F5XdGlPRPo65StzhHV+0lGxWCyXmT9QjSNbI/iibxzE2YJ yIXWyzjeRqtYToYor2gngmrkVgjIG9g3J86Grz7jigWI8Lpe8C9gXTmExrZs5HzpIsQT lDrw== 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:content-transfer-encoding; bh=Qs9G2eaA6ump/WClPbHIXA25o6g9Le7eh4TUUEao6lc=; b=EImdgwfzqRKcDCXhA82uPshJ4L1JIByHT6GEY7ud8gKSOYh2tYBr6CgM344UEF+3hs ApXRD/gMkzw07YZmf1e6+mEB2AP+F8JWmkbJRj+UJKhtaOwAU1l7od7XM2RXtOX8zjuv dQqj/PSvBGQsOJHGPzKfu/Cj7N5V7d8BPQmuzukCj6+8FlKd2FO1j2ZK62ZitP9tPi6x V/vIb3SIc1D30BfAJQkgFfGxAyg4KgsCaXKYZULWzt7wURH+gQaih8Zww5Un/OVFhFP9 qg7SYTzNDgld2/mM4Df3YgYAI0zLt6oZWEA4+Czb5xMBNjIZvR61X5yXe22JcBTJg5DR CaCg== X-Gm-Message-State: APjAAAWtklYNCM+TLJu2b7EJV4AL/XuzNvkwTVBmYX6rIy1XhTAFyJXT +8aJRvRvpPjgg3iBfrs48KOy8u13Qmk= X-Google-Smtp-Source: APXvYqwXbJE/jpwNbElxZXLL9iByu9l0Eyn43TJndSs9RAj9aOUMqSGttpDdjVCFc1OSX0iS0q5whA== X-Received: by 2002:a6b:dc0b:: with SMTP id s11mr2176249ioc.127.1569517432889; Thu, 26 Sep 2019 10:03:52 -0700 (PDT) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com. [209.85.166.46]) by smtp.gmail.com with ESMTPSA id q11sm833004ilm.28.2019.09.26.10.03.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Sep 2019 10:03:51 -0700 (PDT) Received: by mail-io1-f46.google.com with SMTP id c25so8361941iot.12 for ; Thu, 26 Sep 2019 10:03:51 -0700 (PDT) X-Received: by 2002:a6b:3906:: with SMTP id g6mr4321088ioa.48.1569517431725; Thu, 26 Sep 2019 10:03:51 -0700 (PDT) MIME-Version: 1.0 References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> In-Reply-To: From: Aaron Parecki Date: Thu, 26 Sep 2019 19:03:40 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Justin Richer Cc: Torsten Lodderstedt , oauth Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt 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: Thu, 26 Sep 2019 17:03:56 -0000 > The URI is intended to be a reference not a value. If the client could se= nd a JWT it would just send a request object instead of a request URI in th= e first place. So the intent is that it=E2=80=99s random, and maybe we shou= ld just say that explicitly. I thought this language was explicitly to allow the use of structured values for the request_uri? From the introduction: > but it also allows clients requiring an even > higher security level, especially cryptographically confirmed non- > repudiation, to explicitly adopt JWT-based request objects. ---- Aaron Parecki aaronparecki.com On Thu, Sep 26, 2019 at 6:49 PM Justin Richer wrote: > > Aaron, some comments inline. > > =E2=80=94 Justin > > On Sep 26, 2019, at 8:30 AM, Aaron Parecki wrote: > > Hi Torsten, > > I'm very glad to see this draft, I think it's definitely needed in > this space. Here are some of my thoughts on the draft. > > "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" > > > Is it acceptable for the AS to return just an opaque string, rather > than something prefixed with "uri:*"? I don't think anyone would be > confused about copypasting the exact string from the "request_uri" > response into the "request_uri" parameter even if it didn't start with > "urn:". If, for whatever reason, it is required that this value is > actually a URI, is there some expected namespace to use other than > "example"? I worry that if all the examples in the spec are just > "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up > using the text "example" because they don't understand why it's there, > and then it serves no purpose really.=E2=80=99 > > > This field must be a URI, as per JAR: > > request_uri The absolute URI as defined by RFC3986 [RFC3986] that > points to the Request Object (Section 2.1) that holds > authorization request parameters stated in section 4 of OAuth 2.0 > [RFC6749]. > > Somewhat awkwardly, the JAR spec currently states that the AS has to do a= n HTTP GET on the request URI, so that will need to be fixed in JAR before = it goes forward. I don=E2=80=99t think that was always the case though, and= I=E2=80=99m not sure how that changed. > > As for the namespace, =E2=80=9Cexample=E2=80=9D is ok for an example URN.= The problem with URNs is that nobody really understands how to do domain-s= afe fully compliant URNs. So perhaps we should instead use =E2=80=9Curn:fdc= :example.com:=E2=80=A6.=E2=80=9D Instead (as per https://tools.ietf.org/htm= l/rfc4198). > > > The pushed authorization request endpoint shall be a RESTful API > > > I would drop the term RESTful and just say "HTTP API", as this > description is arguably RESTful at best. > > Depending on client type and authentication method, the request might > also include the "client_id" parameter. > > > I assume this is hinting at the difference between public clients > sending only the "client_id" parameter and confidential clients > sending only the HTTP Basic Authorization header which includes both > the client ID and secret? It would probably be helpful to call out > these two common examples if I am understanding this correctly, > otherwise it seems pretty vague. > > > Not quite, those differences are for the token endpoint, and this is capt= uring things from the authorization endpoint. I don=E2=80=99t quite underst= and the differentiation listed here either, though. > > > The "request_uri" value MUST be generated using a cryptographically > strong pseudorandom algorithm > > > I assume this includes the use of a random number inside of a JWT, in > case the AS wants to use JWTs as the "request_uri" parameter"? If so, > it's probably worth spelling that out as it kind of reads like it has > to be literally a random string at first glance. > > > The URI is intended to be a reference not a value. If the client could se= nd a JWT it would just send a request object instead of a request URI in th= e first place. So the intent is that it=E2=80=99s random, and maybe we shou= ld just say that explicitly. > > > That's all for now, thanks! > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > On Sat, Sep 21, 2019 at 1:02 PM Torsten Lodderstedt > wrote: > > > Hi all, > > I just published a new draft that Brian Campbell, Dave Tonge, Filip Skoka= n, Nat Sakimura and I wrote. > > https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 > > It proposes a new endpoint, called "pushed authorization request endpoint= =E2=80=9D, that allows the client to push the Authorization Request payload= with the AS on a backchannel connection instead of a front channel interac= tion. The AS provides the client with a request URI (according to draft-iet= f-oauth-jwsreq) that the client uses in a subsequent authorization requests= to refer to the pushed request data. > > We believe this simple mechanism will significantly increase OAuth securi= ty and robustness since any application can use it by just sending the para= meters in the same encoding as used at the authorisation endpoint over a HT= TPS-protected and (for confidential clients) mutually authenticated connect= ion to the AS. It can also be used to push signed and encrypted request obj= ects to the AS, i.e. it provides an interoperable way to use request object= s managed at the AS for use cases requiring an even higher security level. > > We look forward to getting your feedback. > > kind regards, > Torsten. > > Begin forwarded message: > > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-lodderstedt-oauth-par-00.txt > Date: 21. September 2019 at 12:47:28 CEST > To: "Nat Sakimura" , "Brian Campbell" , "Torsten Lodderstedt" , "Dave Tonge" = , "Filip Skokan" > > > A new version of I-D, draft-lodderstedt-oauth-par-00.txt > has been successfully submitted by Torsten Lodderstedt and posted to the > IETF repository. > > Name: draft-lodderstedt-oauth-par > Revision: 00 > Title: OAuth 2.0 Pushed Authorization Requests > Document date: 2019-09-21 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/internet-drafts/draft-lodderstedt-oa= uth-par-00.txt > Status: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-= par/ > Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-par-0= 0 > Htmlized: https://datatracker.ietf.org/doc/html/draft-lodderstedt-o= auth-par > > > Abstract: > This document defines the pushed authorization request endpoint, > which allows clients to push the payload of an OAuth 2.0 > authorization request to the authorization server via a direct > request and provides them with a request URI that is used as > reference to the data in a subsequent authorization request. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From nobody Thu Sep 26 14:22:09 2019 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 9620E120178 for ; Thu, 26 Sep 2019 14:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 HOWIb7Eirpsr for ; Thu, 26 Sep 2019 14:22:05 -0700 (PDT) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (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 4E5741200CD for ; Thu, 26 Sep 2019 14:22:05 -0700 (PDT) Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id x8QLL2ea016108 for ; Thu, 26 Sep 2019 17:21:34 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 26 Sep 2019 17:20:58 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 26 Sep 2019 17:21:40 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Thu, 26 Sep 2019 17:21:40 -0400 From: Justin Richer To: oauth Thread-Topic: Transactional Authorization: TXAuth Mailing List and BoF Thread-Index: AQHVdLBiU3zC4A9flUOANy/+ycP6SQ== Date: Thu, 26 Sep 2019 21:21:40 +0000 Message-ID: <38043DF4-6BB2-4B3B-8EC0-B085B19D52CB@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [50.206.22.50] Content-Type: multipart/alternative; boundary="_000_38043DF46BB24B3B8EC0B085B19D52CBmitedu_" MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] Transactional Authorization: TXAuth Mailing List and BoF 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: Thu, 26 Sep 2019 21:22:08 -0000 --_000_38043DF46BB24B3B8EC0B085B19D52CBmitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sbG93aW5nIHVwIGZyb20gdGhlIGRpc2N1c3Npb24gaW4gTW9udHJlYWwsIHdl4oCZdmUgY3Jl YXRlZCB0aGUgbm9uLXdvcmtpbmctZ3JvdXAgbWFpbGluZyBsaXN0IFRYQXV0aCB0byBzdGFydCBk aXNjdXNzaW9uIG9mIHRyYW5zYWN0aW9uYWwgYXV0aG9yaXphdGlvbiB3b3JrLiBQbGVhc2Ugam9p biB0aGUgbGlzdCBoZXJlOg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3R4YXV0aA0KDQpXZeKAmXZlIGFsc28gcHJvcG9zZWQgYSBCb0YgZm9yIFNpbmdhcG9yZS4gVGhl IGRldGFpbHMgb2YgdGhlIGFnZW5kYSBhcmUgc3RpbGwgYmVpbmcgZGlzY3Vzc2VkLCBhbmQgdGhl IGRlc2NyaXB0aW9uIGZvbGxvd3M6DQoNClRoZSBPQXV0aCBwcm90b2NvbCBhbmQgaXRzIGV4dGVu c2lvbnMgaGF2ZSBwcm92aWRlZCBhIHBvd2VyZnVsIHNldCBvZiBzZWN1cml0eSBjYXBhYmlsaXRp ZXMgZm9yIHRoZSBpbnRlcm5ldCBvdmVyIHRoZSBsYXN0IGRlY2FkZS4gQSB0cmFuc2FjdGlvbmFs IG1vZGVsIGZvciBjb2xsZWN0aW5nIHVzZXIgY29uc2VudCwgZGVzY3JpYmluZyBhdXRob3JpemF0 aW9uIHJlcXVlc3RzLCBhbmQgZGVsZWdhdGluZyBhdXRob3JpdHkgdG8gYW5vdGhlciBwYXJ0eSBj b3VsZCBwcm92aWRlIGFkZGl0aW9uYWwgZmxleGliaWxpdHkgYW5kIHBvd2VyIGluIHdheXMgdGhh dCBleHRlbmRpbmcgdGhlIGV4aXN0aW5nIE9BdXRoIDIuMCBmcmFtZXdvcmsgZG9lcyBub3QgYWxs b3cuIEFkZGl0aW9uYWxseSwgT0F1dGggMuKAmXMgbWFueSBleHRlbnNpb25zIHByb3ZpZGUgcG9p bnQgc29sdXRpb25zIHRvIHNpbWlsYXIgcHJvYmxlbXMgdGhhdCBjb3VsZCBiZSBiZXR0ZXIgYWRk cmVzc2VkIGJ5IGEgdW5pZmllZCB1bmRlcmx5aW5nIGRlc2lnbi4gVGhlIGdvYWwgb2YgdGhpcyBC b0YgaXMgdG8gZGlzY3VzcyB0aGUgYWRkaXRpb25hbCBuZWVkcyBpbiBkZWxlZ2F0ZWQgYXV0aG9y aXphdGlvbiBwcm90b2NvbHMsIGdhdWdlIHRoZSBjdXJyZW50IHRoaW5raW5nIG9uIGhvdyB0byBh ZGRyZXNzIHRoZW0sIGFuZCB0byBleGFtaW5lIGhvdyBzb21lIGN1cnJlbnQgYW5kIHByb3Bvc2Vk IGVmZm9ydHMgYXBwcm9hY2ggc3VjaCBwcm9ibGVtcy4gVGhlIGdvYWwgb2YgdGhpcyBCb0YgaXMg bm90IHRvIGRpc2N1c3MgaG93IHRvIGV4dGVuZCB0aGUgT0F1dGggMiBwcm90b2NvbCBpdHNlbGYu DQoNCldl4oCZbGwgYmUgdGFsa2luZyBhYm91dCB1c2UgY2FzZXMgdGhhdCBhcmUgZHJpdmluZyBl eHRlbnNpb25zIGFuZCBPQXV0aC1hZGphY2VudCB3b3JrLCBhbmQgaG93IHRoaXMgdHJhbnNhY3Rp b25hbCBtb2RlbCBkaWZmZXJzIGZyb20gdGhlIE9BdXRoIG1vZGVsIHdl4oCZdmUgYWxsIGdvdHRl biB1c2VkIHRvLiBJ4oCZbGwgYmUgcHJlc2VudGluZyB0aGUgY3VycmVudCBzdGF0ZSBvZiBYWVos IGJ1dCB0aGlzIGlzbuKAmXQganVzdCBhIG1lZXRpbmcgdG8gYWRvcHQgWFlaIGFzIGEgc29sdXRp b24sIGFuZCBJIGludml0ZSBvdGhlcnMgdG8gcHJlc2VudCB0aGVpciByZWxhdGVkIHdvcmsuIEZy b20gdGhpcyBtZWV0aW5nIHdlIHNob3VsZCBoYXZlIGEgZ29vZCBzZW5zZSBvZiB3aGVyZSB3ZSB3 YW50IHRvIGdvIHdpdGggdGhpcyBraW5kIG9mIHdvcmsgaW4gdGhlIGZ1dHVyZSwgaW5jbHVkaW5n IHdoZXRoZXIgdGhpcyBpcyBuZXcgd29yayBpbiB0aGUgT0F1dGggV0cgb3IgaWYgd2Ugc2hvdWxk IGJlIHN0YXJ0aW5nIGEgbmV3IFdHLiBJIGhvcGUgdG8gc2VlIHlvdSBhbGwgb24gdGhlIG5ldyBs aXN0IGFuZCBpbiB0aGUgcm9vbSBmb3IgdGhlIEJvRiENCg0K4oCUIEp1c3Rpbg0KDQo= --_000_38043DF46BB24B3B8EC0B085B19D52CBmitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <5A190BE04C37F4469200C92B9877068A@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkZvbGxvd2luZyB1cCBmcm9tIHRoZSBkaXNjdXNz aW9uIGluIE1vbnRyZWFsLCB3ZeKAmXZlIGNyZWF0ZWQgdGhlIG5vbi13b3JraW5nLWdyb3VwIG1h aWxpbmcgbGlzdCBUWEF1dGggdG8gc3RhcnQgZGlzY3Vzc2lvbiBvZiB0cmFuc2FjdGlvbmFsIGF1 dGhvcml6YXRpb24gd29yay4gUGxlYXNlIGpvaW4gdGhlIGxpc3QgaGVyZToNCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOiAwIDAg MCA0MHB4OyBib3JkZXI6IG5vbmU7IHBhZGRpbmc6IDBweDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0 aCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8 L2E+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZeKAmXZlIGFsc28gcHJvcG9zZWQgYSBCb0YgZm9yIFNpbmdh cG9yZS4gVGhlIGRldGFpbHMgb2YgdGhlIGFnZW5kYSBhcmUgc3RpbGwgYmVpbmcgZGlzY3Vzc2Vk LCBhbmQgdGhlIGRlc2NyaXB0aW9uIGZvbGxvd3M6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBweDsg Ym9yZGVyOiBub25lOyBwYWRkaW5nOiAwcHg7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+VGhl IE9BdXRoIHByb3RvY29sIGFuZCBpdHMgZXh0ZW5zaW9ucyBoYXZlIHByb3ZpZGVkIGEgcG93ZXJm dWwgc2V0IG9mIHNlY3VyaXR5IGNhcGFiaWxpdGllcyBmb3IgdGhlIGludGVybmV0IG92ZXIgdGhl IGxhc3QgZGVjYWRlLiBBIHRyYW5zYWN0aW9uYWwgbW9kZWwgZm9yIGNvbGxlY3RpbmcgdXNlciBj b25zZW50LCBkZXNjcmliaW5nIGF1dGhvcml6YXRpb24gcmVxdWVzdHMsIGFuZCBkZWxlZ2F0aW5n IGF1dGhvcml0eSB0bw0KIGFub3RoZXIgcGFydHkgY291bGQgcHJvdmlkZSBhZGRpdGlvbmFsIGZs ZXhpYmlsaXR5IGFuZCBwb3dlciBpbiB3YXlzIHRoYXQgZXh0ZW5kaW5nIHRoZSBleGlzdGluZyBP QXV0aCAyLjAgZnJhbWV3b3JrIGRvZXMgbm90IGFsbG93LiBBZGRpdGlvbmFsbHksIE9BdXRoIDLi gJlzIG1hbnkgZXh0ZW5zaW9ucyBwcm92aWRlIHBvaW50IHNvbHV0aW9ucyB0byBzaW1pbGFyIHBy b2JsZW1zIHRoYXQgY291bGQgYmUgYmV0dGVyIGFkZHJlc3NlZCBieSBhIHVuaWZpZWQNCiB1bmRl cmx5aW5nIGRlc2lnbi4gVGhlIGdvYWwgb2YgdGhpcyBCb0YgaXMgdG8gZGlzY3VzcyB0aGUgYWRk aXRpb25hbCBuZWVkcyBpbiBkZWxlZ2F0ZWQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMsIGdhdWdl IHRoZSBjdXJyZW50IHRoaW5raW5nIG9uIGhvdyB0byBhZGRyZXNzIHRoZW0sIGFuZCB0byBleGFt aW5lIGhvdyBzb21lIGN1cnJlbnQgYW5kIHByb3Bvc2VkIGVmZm9ydHMgYXBwcm9hY2ggc3VjaCBw cm9ibGVtcy4gVGhlIGdvYWwgb2YgdGhpcw0KIEJvRiBpcyBub3QgdG8gZGlzY3VzcyBob3cgdG8g ZXh0ZW5kIHRoZSBPQXV0aCAyIHByb3RvY29sIGl0c2VsZi48L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldl4oCZ bGwgYmUgdGFsa2luZyBhYm91dCB1c2UgY2FzZXMgdGhhdCBhcmUgZHJpdmluZyBleHRlbnNpb25z IGFuZCBPQXV0aC1hZGphY2VudCB3b3JrLCBhbmQgaG93IHRoaXMgdHJhbnNhY3Rpb25hbCBtb2Rl bCBkaWZmZXJzIGZyb20gdGhlIE9BdXRoIG1vZGVsIHdl4oCZdmUgYWxsIGdvdHRlbiB1c2VkIHRv LiBJ4oCZbGwgYmUgcHJlc2VudGluZyB0aGUgY3VycmVudCBzdGF0ZSBvZiBYWVosIGJ1dCB0aGlz IGlzbuKAmXQganVzdCBhIG1lZXRpbmcNCiB0byBhZG9wdCBYWVogYXMgYSBzb2x1dGlvbiwgYW5k IEkgaW52aXRlIG90aGVycyB0byBwcmVzZW50IHRoZWlyIHJlbGF0ZWQgd29yay4gRnJvbSB0aGlz IG1lZXRpbmcgd2Ugc2hvdWxkIGhhdmUgYSBnb29kIHNlbnNlIG9mIHdoZXJlIHdlIHdhbnQgdG8g Z28gd2l0aCB0aGlzIGtpbmQgb2Ygd29yayBpbiB0aGUgZnV0dXJlLCBpbmNsdWRpbmcgd2hldGhl ciB0aGlzIGlzIG5ldyB3b3JrIGluIHRoZSBPQXV0aCBXRyBvciBpZiB3ZSBzaG91bGQgYmUNCiBz dGFydGluZyBhIG5ldyBXRy4gSSBob3BlIHRvIHNlZSB5b3UgYWxsIG9uIHRoZSBuZXcgbGlzdCBh bmQgaW4gdGhlIHJvb20gZm9yIHRoZSBCb0YhPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rp dj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_38043DF46BB24B3B8EC0B085B19D52CBmitedu_-- From nobody Thu Sep 26 14:24:04 2019 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 3502B12022A for ; Thu, 26 Sep 2019 14:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.224 X-Spam-Level: X-Spam-Status: No, score=-4.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4j8qB7gXsk8i for ; Thu, 26 Sep 2019 14:23:58 -0700 (PDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (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 540351200CD for ; Thu, 26 Sep 2019 14:23:58 -0700 (PDT) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id x8QLNuX2032152; Thu, 26 Sep 2019 17:23:56 -0400 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 26 Sep 2019 17:22:59 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 26 Sep 2019 17:23:39 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Thu, 26 Sep 2019 17:23:39 -0400 From: Justin Richer To: Aaron Parecki CC: Torsten Lodderstedt , oauth Thread-Topic: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt Thread-Index: AQHVdIpZnL295fl8/UWM1oDH5BpdI6c+cqkAgABIogA= Date: Thu, 26 Sep 2019 21:23:39 +0000 Message-ID: References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [50.206.22.50] Content-Type: multipart/alternative; boundary="_000_C72FC21832E0481B92B36B3747261295mitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt 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: Thu, 26 Sep 2019 21:24:02 -0000 --_000_C72FC21832E0481B92B36B3747261295mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB0aGUgcmVxdWVzdCBvYmplY3QgaXMgSldULWJhc2VkLCBidXQgdGhlIHJlcXVlc3QgVVJJ IGlzIG5vdC4gSW4gb3RoZXIgd29yZHMsIHlvdSBjYW4gcG9zdCBhIEpXVCBidXQgd2hhdCB5b3Ug Z2V0IGJhY2sgaXMgYSBVUkksIG5vdCB0aGUgSldUIGl0c2VsZi4gIFRoZSByZXF1ZXN0IFVSSSB3 YXMgYWx3YXlzIG1lYW50IHRvIGJlIGEgcmVmZXJlbmNlLCBhbmQgb3JpZ2luYWxseSBpdCB3YXMg ZXhwbGljaXRseSBhIHJlZmVyZW5jZSB0byBhIHNpZ25lZCByZXF1ZXN0IG9iamVjdC4NCg0K4oCU IEp1c3Rpbg0KDQpPbiBTZXAgMjYsIDIwMTksIGF0IDEwOjAzIEFNLCBBYXJvbiBQYXJlY2tpIDxh YXJvbkBwYXJlY2tpLmNvbTxtYWlsdG86YWFyb25AcGFyZWNraS5jb20+PiB3cm90ZToNCg0KVGhl IFVSSSBpcyBpbnRlbmRlZCB0byBiZSBhIHJlZmVyZW5jZSBub3QgYSB2YWx1ZS4gSWYgdGhlIGNs aWVudCBjb3VsZCBzZW5kIGEgSldUIGl0IHdvdWxkIGp1c3Qgc2VuZCBhIHJlcXVlc3Qgb2JqZWN0 IGluc3RlYWQgb2YgYSByZXF1ZXN0IFVSSSBpbiB0aGUgZmlyc3QgcGxhY2UuIFNvIHRoZSBpbnRl bnQgaXMgdGhhdCBpdOKAmXMgcmFuZG9tLCBhbmQgbWF5YmUgd2Ugc2hvdWxkIGp1c3Qgc2F5IHRo YXQgZXhwbGljaXRseS4NCg0KSSB0aG91Z2h0IHRoaXMgbGFuZ3VhZ2Ugd2FzIGV4cGxpY2l0bHkg dG8gYWxsb3cgdGhlIHVzZSBvZiBzdHJ1Y3R1cmVkDQp2YWx1ZXMgZm9yIHRoZSByZXF1ZXN0X3Vy aT8gRnJvbSB0aGUgaW50cm9kdWN0aW9uOg0KDQpidXQgaXQgYWxzbyBhbGxvd3MgY2xpZW50cyBy ZXF1aXJpbmcgYW4gZXZlbg0KaGlnaGVyIHNlY3VyaXR5IGxldmVsLCBlc3BlY2lhbGx5IGNyeXB0 b2dyYXBoaWNhbGx5IGNvbmZpcm1lZCBub24tDQpyZXB1ZGlhdGlvbiwgdG8gZXhwbGljaXRseSBh ZG9wdCBKV1QtYmFzZWQgcmVxdWVzdCBvYmplY3RzLg0KDQotLS0tDQpBYXJvbiBQYXJlY2tpDQph YXJvbnBhcmVja2kuY29tPGh0dHA6Ly9hYXJvbnBhcmVja2kuY29tPg0KDQpPbiBUaHUsIFNlcCAy NiwgMjAxOSBhdCA2OjQ5IFBNIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4gd3JvdGU6 DQoNCkFhcm9uLCBzb21lIGNvbW1lbnRzIGlubGluZS4NCg0K4oCUIEp1c3Rpbg0KDQpPbiBTZXAg MjYsIDIwMTksIGF0IDg6MzAgQU0sIEFhcm9uIFBhcmVja2kgPGFhcm9uQHBhcmVja2kuY29tPiB3 cm90ZToNCg0KSGkgVG9yc3RlbiwNCg0KSSdtIHZlcnkgZ2xhZCB0byBzZWUgdGhpcyBkcmFmdCwg SSB0aGluayBpdCdzIGRlZmluaXRlbHkgbmVlZGVkIGluDQp0aGlzIHNwYWNlLiBIZXJlIGFyZSBz b21lIG9mIG15IHRob3VnaHRzIG9uIHRoZSBkcmFmdC4NCg0KInJlcXVlc3RfdXJpIjogInVybjpl eGFtcGxlOmJ3YzRKSy1FU0MwdzhhY2MxOTFlLVkxTFRDMiINCg0KDQpJcyBpdCBhY2NlcHRhYmxl IGZvciB0aGUgQVMgdG8gcmV0dXJuIGp1c3QgYW4gb3BhcXVlIHN0cmluZywgcmF0aGVyDQp0aGFu IHNvbWV0aGluZyBwcmVmaXhlZCB3aXRoICJ1cmk6KiI/IEkgZG9uJ3QgdGhpbmsgYW55b25lIHdv dWxkIGJlDQpjb25mdXNlZCBhYm91dCBjb3B5cGFzdGluZyB0aGUgZXhhY3Qgc3RyaW5nIGZyb20g dGhlICJyZXF1ZXN0X3VyaSINCnJlc3BvbnNlIGludG8gdGhlICJyZXF1ZXN0X3VyaSIgcGFyYW1l dGVyIGV2ZW4gaWYgaXQgZGlkbid0IHN0YXJ0IHdpdGgNCiJ1cm46Ii4gSWYsIGZvciB3aGF0ZXZl ciByZWFzb24sIGl0IGlzIHJlcXVpcmVkIHRoYXQgdGhpcyB2YWx1ZSBpcw0KYWN0dWFsbHkgYSBV UkksIGlzIHRoZXJlIHNvbWUgZXhwZWN0ZWQgbmFtZXNwYWNlIHRvIHVzZSBvdGhlciB0aGFuDQoi ZXhhbXBsZSI/IEkgd29ycnkgdGhhdCBpZiBhbGwgdGhlIGV4YW1wbGVzIGluIHRoZSBzcGVjIGFy ZSBqdXN0DQoidXJuOmV4YW1wbGU6YndjNEpLLUVTQzB3OGFjYzE5MWUtWTFMVEMyIiB0aGVuIGRl dmVsb3BlcnMgd2lsbCBlbmQgdXANCnVzaW5nIHRoZSB0ZXh0ICJleGFtcGxlIiBiZWNhdXNlIHRo ZXkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgaXQncyB0aGVyZSwNCmFuZCB0aGVuIGl0IHNlcnZlcyBu byBwdXJwb3NlIHJlYWxseS7igJkNCg0KDQpUaGlzIGZpZWxkIG11c3QgYmUgYSBVUkksIGFzIHBl ciBKQVI6DQoNCiAgcmVxdWVzdF91cmkgIFRoZSBhYnNvbHV0ZSBVUkkgYXMgZGVmaW5lZCBieSBS RkMzOTg2IFtSRkMzOTg2XSB0aGF0DQogICAgIHBvaW50cyB0byB0aGUgUmVxdWVzdCBPYmplY3Qg KFNlY3Rpb24gMi4xKSB0aGF0IGhvbGRzDQogICAgIGF1dGhvcml6YXRpb24gcmVxdWVzdCBwYXJh bWV0ZXJzIHN0YXRlZCBpbiBzZWN0aW9uIDQgb2YgT0F1dGggMi4wDQogICAgIFtSRkM2NzQ5XS4N Cg0KU29tZXdoYXQgYXdrd2FyZGx5LCB0aGUgSkFSIHNwZWMgY3VycmVudGx5IHN0YXRlcyB0aGF0 IHRoZSBBUyBoYXMgdG8gZG8gYW4gSFRUUCBHRVQgb24gdGhlIHJlcXVlc3QgVVJJLCBzbyB0aGF0 IHdpbGwgbmVlZCB0byBiZSBmaXhlZCBpbiBKQVIgYmVmb3JlIGl0IGdvZXMgZm9yd2FyZC4gSSBk b27igJl0IHRoaW5rIHRoYXQgd2FzIGFsd2F5cyB0aGUgY2FzZSB0aG91Z2gsIGFuZCBJ4oCZbSBu b3Qgc3VyZSBob3cgdGhhdCBjaGFuZ2VkLg0KDQpBcyBmb3IgdGhlIG5hbWVzcGFjZSwg4oCcZXhh bXBsZeKAnSBpcyBvayBmb3IgYW4gZXhhbXBsZSBVUk4uIFRoZSBwcm9ibGVtIHdpdGggVVJOcyBp cyB0aGF0IG5vYm9keSByZWFsbHkgdW5kZXJzdGFuZHMgaG93IHRvIGRvIGRvbWFpbi1zYWZlIGZ1 bGx5IGNvbXBsaWFudCBVUk5zLiBTbyBwZXJoYXBzIHdlIHNob3VsZCBpbnN0ZWFkIHVzZSDigJx1 cm46ZmRjOmV4YW1wbGUuY29tOuKApi7igJ0gSW5zdGVhZCAoYXMgcGVyIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM0MTk4KS4NCg0KDQpUaGUgcHVzaGVkIGF1dGhvcml6YXRpb24gcmVx dWVzdCBlbmRwb2ludCBzaGFsbCBiZSBhIFJFU1RmdWwgQVBJDQoNCg0KSSB3b3VsZCBkcm9wIHRo ZSB0ZXJtIFJFU1RmdWwgYW5kIGp1c3Qgc2F5ICJIVFRQIEFQSSIsIGFzIHRoaXMNCmRlc2NyaXB0 aW9uIGlzIGFyZ3VhYmx5IFJFU1RmdWwgYXQgYmVzdC4NCg0KRGVwZW5kaW5nIG9uIGNsaWVudCB0 eXBlIGFuZCBhdXRoZW50aWNhdGlvbiBtZXRob2QsIHRoZSByZXF1ZXN0IG1pZ2h0DQphbHNvIGlu Y2x1ZGUgdGhlICJjbGllbnRfaWQiIHBhcmFtZXRlci4NCg0KDQpJIGFzc3VtZSB0aGlzIGlzIGhp bnRpbmcgYXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBwdWJsaWMgY2xpZW50cw0Kc2VuZGluZyBv bmx5IHRoZSAiY2xpZW50X2lkIiBwYXJhbWV0ZXIgYW5kIGNvbmZpZGVudGlhbCBjbGllbnRzDQpz ZW5kaW5nIG9ubHkgdGhlIEhUVFAgQmFzaWMgQXV0aG9yaXphdGlvbiBoZWFkZXIgd2hpY2ggaW5j bHVkZXMgYm90aA0KdGhlIGNsaWVudCBJRCBhbmQgc2VjcmV0PyBJdCB3b3VsZCBwcm9iYWJseSBi ZSBoZWxwZnVsIHRvIGNhbGwgb3V0DQp0aGVzZSB0d28gY29tbW9uIGV4YW1wbGVzIGlmIEkgYW0g dW5kZXJzdGFuZGluZyB0aGlzIGNvcnJlY3RseSwNCm90aGVyd2lzZSBpdCBzZWVtcyBwcmV0dHkg dmFndWUuDQoNCg0KTm90IHF1aXRlLCB0aG9zZSBkaWZmZXJlbmNlcyBhcmUgZm9yIHRoZSB0b2tl biBlbmRwb2ludCwgYW5kIHRoaXMgaXMgY2FwdHVyaW5nIHRoaW5ncyBmcm9tIHRoZSBhdXRob3Jp emF0aW9uIGVuZHBvaW50LiBJIGRvbuKAmXQgcXVpdGUgdW5kZXJzdGFuZCB0aGUgZGlmZmVyZW50 aWF0aW9uIGxpc3RlZCBoZXJlIGVpdGhlciwgdGhvdWdoLg0KDQoNClRoZSAicmVxdWVzdF91cmki IHZhbHVlIE1VU1QgYmUgZ2VuZXJhdGVkIHVzaW5nIGEgY3J5cHRvZ3JhcGhpY2FsbHkNCnN0cm9u ZyBwc2V1ZG9yYW5kb20gYWxnb3JpdGhtDQoNCg0KSSBhc3N1bWUgdGhpcyBpbmNsdWRlcyB0aGUg dXNlIG9mIGEgcmFuZG9tIG51bWJlciBpbnNpZGUgb2YgYSBKV1QsIGluDQpjYXNlIHRoZSBBUyB3 YW50cyB0byB1c2UgSldUcyBhcyB0aGUgInJlcXVlc3RfdXJpIiBwYXJhbWV0ZXIiPyBJZiBzbywN Cml0J3MgcHJvYmFibHkgd29ydGggc3BlbGxpbmcgdGhhdCBvdXQgYXMgaXQga2luZCBvZiByZWFk cyBsaWtlIGl0IGhhcw0KdG8gYmUgbGl0ZXJhbGx5IGEgcmFuZG9tIHN0cmluZyBhdCBmaXJzdCBn bGFuY2UuDQoNCg0KVGhlIFVSSSBpcyBpbnRlbmRlZCB0byBiZSBhIHJlZmVyZW5jZSBub3QgYSB2 YWx1ZS4gSWYgdGhlIGNsaWVudCBjb3VsZCBzZW5kIGEgSldUIGl0IHdvdWxkIGp1c3Qgc2VuZCBh IHJlcXVlc3Qgb2JqZWN0IGluc3RlYWQgb2YgYSByZXF1ZXN0IFVSSSBpbiB0aGUgZmlyc3QgcGxh Y2UuIFNvIHRoZSBpbnRlbnQgaXMgdGhhdCBpdOKAmXMgcmFuZG9tLCBhbmQgbWF5YmUgd2Ugc2hv dWxkIGp1c3Qgc2F5IHRoYXQgZXhwbGljaXRseS4NCg0KDQpUaGF0J3MgYWxsIGZvciBub3csIHRo YW5rcyENCg0KLS0tLQ0KQWFyb24gUGFyZWNraQ0KYWFyb25wYXJlY2tpLmNvbQ0KQGFhcm9ucGsN Cg0KT24gU2F0LCBTZXAgMjEsIDIwMTkgYXQgMTowMiBQTSBUb3JzdGVuIExvZGRlcnN0ZWR0DQo8 dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOg0KDQoNCkhpIGFsbCwNCg0KSSBqdXN0IHB1 Ymxpc2hlZCBhIG5ldyBkcmFmdCB0aGF0IEJyaWFuIENhbXBiZWxsLCBEYXZlIFRvbmdlLCBGaWxp cCBTa29rYW4sIE5hdCBTYWtpbXVyYSBhbmQgSSB3cm90ZS4NCg0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXBhci0wMA0KDQpJdCBwcm9wb3NlcyBh IG5ldyBlbmRwb2ludCwgY2FsbGVkICJwdXNoZWQgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGVuZHBv aW504oCdLCB0aGF0IGFsbG93cyB0aGUgY2xpZW50IHRvIHB1c2ggdGhlIEF1dGhvcml6YXRpb24g UmVxdWVzdCBwYXlsb2FkIHdpdGggdGhlIEFTIG9uIGEgYmFja2NoYW5uZWwgY29ubmVjdGlvbiBp bnN0ZWFkIG9mIGEgZnJvbnQgY2hhbm5lbCBpbnRlcmFjdGlvbi4gVGhlIEFTIHByb3ZpZGVzIHRo ZSBjbGllbnQgd2l0aCBhIHJlcXVlc3QgVVJJIChhY2NvcmRpbmcgdG8gZHJhZnQtaWV0Zi1vYXV0 aC1qd3NyZXEpIHRoYXQgdGhlIGNsaWVudCB1c2VzIGluIGEgc3Vic2VxdWVudCBhdXRob3JpemF0 aW9uIHJlcXVlc3RzIHRvIHJlZmVyIHRvIHRoZSBwdXNoZWQgcmVxdWVzdCBkYXRhLg0KDQpXZSBi ZWxpZXZlIHRoaXMgc2ltcGxlIG1lY2hhbmlzbSB3aWxsIHNpZ25pZmljYW50bHkgaW5jcmVhc2Ug T0F1dGggc2VjdXJpdHkgYW5kIHJvYnVzdG5lc3Mgc2luY2UgYW55IGFwcGxpY2F0aW9uIGNhbiB1 c2UgaXQgYnkganVzdCBzZW5kaW5nIHRoZSBwYXJhbWV0ZXJzIGluIHRoZSBzYW1lIGVuY29kaW5n IGFzIHVzZWQgYXQgdGhlIGF1dGhvcmlzYXRpb24gZW5kcG9pbnQgb3ZlciBhIEhUVFBTLXByb3Rl Y3RlZCBhbmQgKGZvciBjb25maWRlbnRpYWwgY2xpZW50cykgbXV0dWFsbHkgYXV0aGVudGljYXRl ZCBjb25uZWN0aW9uIHRvIHRoZSBBUy4gSXQgY2FuIGFsc28gYmUgdXNlZCB0byBwdXNoIHNpZ25l ZCBhbmQgZW5jcnlwdGVkIHJlcXVlc3Qgb2JqZWN0cyB0byB0aGUgQVMsIGkuZS4gaXQgcHJvdmlk ZXMgYW4gaW50ZXJvcGVyYWJsZSB3YXkgdG8gdXNlIHJlcXVlc3Qgb2JqZWN0cyBtYW5hZ2VkIGF0 IHRoZSBBUyBmb3IgdXNlIGNhc2VzIHJlcXVpcmluZyBhbiBldmVuIGhpZ2hlciBzZWN1cml0eSBs ZXZlbC4NCg0KV2UgbG9vayBmb3J3YXJkIHRvIGdldHRpbmcgeW91ciBmZWVkYmFjay4NCg0Ka2lu ZCByZWdhcmRzLA0KVG9yc3Rlbi4NCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNCkZyb206 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1wYXItMDAudHh0DQpEYXRlOiAyMS4gU2Vw dGVtYmVyIDIwMTkgYXQgMTI6NDc6MjggQ0VTVA0KVG86ICJOYXQgU2FraW11cmEiIDxuYXRAc2Fr aW11cmEub3JnPiwgIkJyaWFuIENhbXBiZWxsIiA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+ LCAiVG9yc3RlbiBMb2RkZXJzdGVkdCIgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PiwgIkRhdmUg VG9uZ2UiIDxkYXZlQHRvbmdlLm9yZz4sICJGaWxpcCBTa29rYW4iIDxwYW52YS5pcEBnbWFpbC5j b20+DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXBh ci0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVG9yc3RlbiBMb2Rk ZXJzdGVkdCBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiBkcmFm dC1sb2RkZXJzdGVkdC1vYXV0aC1wYXINClJldmlzaW9uOiAwMA0KVGl0bGU6IE9BdXRoIDIuMCBQ dXNoZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0cw0KRG9jdW1lbnQgZGF0ZTogMjAxOS0wOS0yMQ0K R3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6IDEyDQpVUkw6ICAgICAgICAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxvZGRlcnN0ZWR0LW9h dXRoLXBhci0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1wYXIvDQpIdG1saXplZDogICAgICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXBhci0wMA0K SHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtbG9kZGVyc3RlZHQtb2F1dGgtcGFyDQoNCg0KQWJzdHJhY3Q6DQpUaGlzIGRvY3VtZW50IGRl ZmluZXMgdGhlIHB1c2hlZCBhdXRob3JpemF0aW9uIHJlcXVlc3QgZW5kcG9pbnQsDQp3aGljaCBh bGxvd3MgY2xpZW50cyB0byBwdXNoIHRoZSBwYXlsb2FkIG9mIGFuIE9BdXRoIDIuMA0KYXV0aG9y aXphdGlvbiByZXF1ZXN0IHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB2aWEgYSBkaXJlY3QN CnJlcXVlc3QgYW5kIHByb3ZpZGVzIHRoZW0gd2l0aCBhIHJlcXVlc3QgVVJJIHRoYXQgaXMgdXNl ZCBhcw0KcmVmZXJlbmNlIHRvIHRoZSBkYXRhIGluIGEgc3Vic2VxdWVudCBhdXRob3JpemF0aW9u IHJlcXVlc3QuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpP QXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0KDQoNCg0K --_000_C72FC21832E0481B92B36B3747261295mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClllcywgdGhlIHJlcXVlc3Qgb2JqZWN0IGlzIEpX VC1iYXNlZCwgYnV0IHRoZSByZXF1ZXN0IFVSSSBpcyBub3QuIEluIG90aGVyIHdvcmRzLCB5b3Ug Y2FuIHBvc3QgYSBKV1QgYnV0IHdoYXQgeW91IGdldCBiYWNrIGlzIGEgVVJJLCBub3QgdGhlIEpX VCBpdHNlbGYuICZuYnNwO1RoZSByZXF1ZXN0IFVSSSB3YXMgYWx3YXlzIG1lYW50IHRvIGJlIGEg cmVmZXJlbmNlLCBhbmQgb3JpZ2luYWxseSBpdCB3YXMgZXhwbGljaXRseSBhIHJlZmVyZW5jZSB0 byBhIHNpZ25lZA0KIHJlcXVlc3Qgb2JqZWN0LiZuYnNwOw0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPg0K4oCUIEp1c3RpbjwvZGl2Pg0KPC9k aXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj5PbiBTZXAgMjYsIDIwMTksIGF0IDEwOjAzIEFNLCBBYXJvbiBQYXJl Y2tpICZsdDs8YSBocmVmPSJtYWlsdG86YWFyb25AcGFyZWNraS5jb20iIGNsYXNzPSIiPmFhcm9u QHBhcmVja2kuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVy Y2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5UaGUgVVJJIGlzIGludGVuZGVkIHRvIGJlIGEgcmVm ZXJlbmNlIG5vdCBhIHZhbHVlLiBJZiB0aGUgY2xpZW50IGNvdWxkIHNlbmQgYSBKV1QgaXQgd291 bGQganVzdCBzZW5kIGEgcmVxdWVzdCBvYmplY3QgaW5zdGVhZCBvZiBhIHJlcXVlc3QgVVJJIGlu IHRoZSBmaXJzdCBwbGFjZS4gU28gdGhlIGludGVudCBpcyB0aGF0IGl04oCZcyByYW5kb20sIGFu ZCBtYXliZSB3ZSBzaG91bGQganVzdCBzYXkNCiB0aGF0IGV4cGxpY2l0bHkuPGJyIGNsYXNzPSIi Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSSB0aG91Z2h0IHRoaXMgbGFuZ3VhZ2Ug d2FzIGV4cGxpY2l0bHkgdG8gYWxsb3cgdGhlIHVzZSBvZiBzdHJ1Y3R1cmVkPGJyIGNsYXNzPSIi Pg0KdmFsdWVzIGZvciB0aGUgcmVxdWVzdF91cmk/IEZyb20gdGhlIGludHJvZHVjdGlvbjo8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij5idXQgaXQgYWxzbyBhbGxvd3MgY2xpZW50cyByZXF1aXJpbmcgYW4gZXZlbjxiciBjbGFzcz0i Ij4NCmhpZ2hlciBzZWN1cml0eSBsZXZlbCwgZXNwZWNpYWxseSBjcnlwdG9ncmFwaGljYWxseSBj b25maXJtZWQgbm9uLTxiciBjbGFzcz0iIj4NCnJlcHVkaWF0aW9uLCB0byBleHBsaWNpdGx5IGFk b3B0IEpXVC1iYXNlZCByZXF1ZXN0IG9iamVjdHMuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3Rl Pg0KPGJyIGNsYXNzPSIiPg0KLS0tLTxiciBjbGFzcz0iIj4NCkFhcm9uIFBhcmVja2k8YnIgY2xh c3M9IiI+DQo8YSBocmVmPSJodHRwOi8vYWFyb25wYXJlY2tpLmNvbSIgY2xhc3M9IiI+YWFyb25w YXJlY2tpLmNvbTwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiBUaHUsIFNlcCAy NiwgMjAxOSBhdCA2OjQ5IFBNIEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVkdSZndDsg d3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KQWFyb24sIHNvbWUgY29tbWVudHMgaW5saW5lLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCuKAlCBKdXN0aW48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiBT ZXAgMjYsIDIwMTksIGF0IDg6MzAgQU0sIEFhcm9uIFBhcmVja2kgJmx0O2Fhcm9uQHBhcmVja2ku Y29tJmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpIaSBUb3JzdGVuLDxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkknbSB2ZXJ5IGdsYWQgdG8gc2VlIHRoaXMgZHJh ZnQsIEkgdGhpbmsgaXQncyBkZWZpbml0ZWx5IG5lZWRlZCBpbjxiciBjbGFzcz0iIj4NCnRoaXMg c3BhY2UuIEhlcmUgYXJlIHNvbWUgb2YgbXkgdGhvdWdodHMgb24gdGhlIGRyYWZ0LjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCiZxdW90O3JlcXVlc3RfdXJpJnF1b3Q7OiAmcXVvdDt1cm46 ZXhhbXBsZTpid2M0SkstRVNDMHc4YWNjMTkxZS1ZMUxUQzImcXVvdDs8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJcyBpdCBhY2NlcHRhYmxlIGZvciB0aGUgQVMg dG8gcmV0dXJuIGp1c3QgYW4gb3BhcXVlIHN0cmluZywgcmF0aGVyPGJyIGNsYXNzPSIiPg0KdGhh biBzb21ldGhpbmcgcHJlZml4ZWQgd2l0aCAmcXVvdDt1cmk6KiZxdW90Oz8gSSBkb24ndCB0aGlu ayBhbnlvbmUgd291bGQgYmU8YnIgY2xhc3M9IiI+DQpjb25mdXNlZCBhYm91dCBjb3B5cGFzdGlu ZyB0aGUgZXhhY3Qgc3RyaW5nIGZyb20gdGhlICZxdW90O3JlcXVlc3RfdXJpJnF1b3Q7PGJyIGNs YXNzPSIiPg0KcmVzcG9uc2UgaW50byB0aGUgJnF1b3Q7cmVxdWVzdF91cmkmcXVvdDsgcGFyYW1l dGVyIGV2ZW4gaWYgaXQgZGlkbid0IHN0YXJ0IHdpdGg8YnIgY2xhc3M9IiI+DQomcXVvdDt1cm46 JnF1b3Q7LiBJZiwgZm9yIHdoYXRldmVyIHJlYXNvbiwgaXQgaXMgcmVxdWlyZWQgdGhhdCB0aGlz IHZhbHVlIGlzPGJyIGNsYXNzPSIiPg0KYWN0dWFsbHkgYSBVUkksIGlzIHRoZXJlIHNvbWUgZXhw ZWN0ZWQgbmFtZXNwYWNlIHRvIHVzZSBvdGhlciB0aGFuPGJyIGNsYXNzPSIiPg0KJnF1b3Q7ZXhh bXBsZSZxdW90Oz8gSSB3b3JyeSB0aGF0IGlmIGFsbCB0aGUgZXhhbXBsZXMgaW4gdGhlIHNwZWMg YXJlIGp1c3Q8YnIgY2xhc3M9IiI+DQomcXVvdDt1cm46ZXhhbXBsZTpid2M0SkstRVNDMHc4YWNj MTkxZS1ZMUxUQzImcXVvdDsgdGhlbiBkZXZlbG9wZXJzIHdpbGwgZW5kIHVwPGJyIGNsYXNzPSIi Pg0KdXNpbmcgdGhlIHRleHQgJnF1b3Q7ZXhhbXBsZSZxdW90OyBiZWNhdXNlIHRoZXkgZG9uJ3Qg dW5kZXJzdGFuZCB3aHkgaXQncyB0aGVyZSw8YnIgY2xhc3M9IiI+DQphbmQgdGhlbiBpdCBzZXJ2 ZXMgbm8gcHVycG9zZSByZWFsbHku4oCZPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KVGhpcyBmaWVsZCBtdXN0IGJlIGEgVVJJLCBhcyBwZXIgSkFSOjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3JlcXVlc3RfdXJpICZuYnNwO1RoZSBh YnNvbHV0ZSBVUkkgYXMgZGVmaW5lZCBieSBSRkMzOTg2IFtSRkMzOTg2XSB0aGF0PGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cG9pbnRzIHRvIHRoZSBSZXF1ZXN0 IE9iamVjdCAoU2VjdGlvbiAyLjEpIHRoYXQgaG9sZHM8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDthdXRob3JpemF0aW9uIHJlcXVlc3QgcGFyYW1ldGVycyBzdGF0 ZWQgaW4gc2VjdGlvbiA0IG9mIE9BdXRoIDIuMDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO1tSRkM2NzQ5XS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpT b21ld2hhdCBhd2t3YXJkbHksIHRoZSBKQVIgc3BlYyBjdXJyZW50bHkgc3RhdGVzIHRoYXQgdGhl IEFTIGhhcyB0byBkbyBhbiBIVFRQIEdFVCBvbiB0aGUgcmVxdWVzdCBVUkksIHNvIHRoYXQgd2ls bCBuZWVkIHRvIGJlIGZpeGVkIGluIEpBUiBiZWZvcmUgaXQgZ29lcyBmb3J3YXJkLiBJIGRvbuKA mXQgdGhpbmsgdGhhdCB3YXMgYWx3YXlzIHRoZSBjYXNlIHRob3VnaCwgYW5kIEnigJltIG5vdCBz dXJlIGhvdyB0aGF0IGNoYW5nZWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQXMgZm9y IHRoZSBuYW1lc3BhY2UsIOKAnGV4YW1wbGXigJ0gaXMgb2sgZm9yIGFuIGV4YW1wbGUgVVJOLiBU aGUgcHJvYmxlbSB3aXRoIFVSTnMgaXMgdGhhdCBub2JvZHkgcmVhbGx5IHVuZGVyc3RhbmRzIGhv dyB0byBkbyBkb21haW4tc2FmZSBmdWxseSBjb21wbGlhbnQgVVJOcy4gU28gcGVyaGFwcyB3ZSBz aG91bGQgaW5zdGVhZCB1c2Ug4oCcdXJuOmZkYzpleGFtcGxlLmNvbTrigKYu4oCdIEluc3RlYWQg KGFzIHBlciBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDE5OCkuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIHB1c2hlZCBhdXRob3JpemF0aW9u IHJlcXVlc3QgZW5kcG9pbnQgc2hhbGwgYmUgYSBSRVNUZnVsIEFQSTxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgd291bGQgZHJvcCB0aGUgdGVybSBSRVNUZnVs IGFuZCBqdXN0IHNheSAmcXVvdDtIVFRQIEFQSSZxdW90OywgYXMgdGhpczxiciBjbGFzcz0iIj4N CmRlc2NyaXB0aW9uIGlzIGFyZ3VhYmx5IFJFU1RmdWwgYXQgYmVzdC48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpEZXBlbmRpbmcgb24gY2xpZW50IHR5cGUgYW5kIGF1dGhlbnRpY2F0aW9u IG1ldGhvZCwgdGhlIHJlcXVlc3QgbWlnaHQ8YnIgY2xhc3M9IiI+DQphbHNvIGluY2x1ZGUgdGhl ICZxdW90O2NsaWVudF9pZCZxdW90OyBwYXJhbWV0ZXIuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBhc3N1bWUgdGhpcyBpcyBoaW50aW5nIGF0IHRoZSBkaWZm ZXJlbmNlIGJldHdlZW4gcHVibGljIGNsaWVudHM8YnIgY2xhc3M9IiI+DQpzZW5kaW5nIG9ubHkg dGhlICZxdW90O2NsaWVudF9pZCZxdW90OyBwYXJhbWV0ZXIgYW5kIGNvbmZpZGVudGlhbCBjbGll bnRzPGJyIGNsYXNzPSIiPg0Kc2VuZGluZyBvbmx5IHRoZSBIVFRQIEJhc2ljIEF1dGhvcml6YXRp b24gaGVhZGVyIHdoaWNoIGluY2x1ZGVzIGJvdGg8YnIgY2xhc3M9IiI+DQp0aGUgY2xpZW50IElE IGFuZCBzZWNyZXQ/IEl0IHdvdWxkIHByb2JhYmx5IGJlIGhlbHBmdWwgdG8gY2FsbCBvdXQ8YnIg Y2xhc3M9IiI+DQp0aGVzZSB0d28gY29tbW9uIGV4YW1wbGVzIGlmIEkgYW0gdW5kZXJzdGFuZGlu ZyB0aGlzIGNvcnJlY3RseSw8YnIgY2xhc3M9IiI+DQpvdGhlcndpc2UgaXQgc2VlbXMgcHJldHR5 IHZhZ3VlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5vdCBx dWl0ZSwgdGhvc2UgZGlmZmVyZW5jZXMgYXJlIGZvciB0aGUgdG9rZW4gZW5kcG9pbnQsIGFuZCB0 aGlzIGlzIGNhcHR1cmluZyB0aGluZ3MgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4g SSBkb27igJl0IHF1aXRlIHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVudGlhdGlvbiBsaXN0ZWQgaGVy ZSBlaXRoZXIsIHRob3VnaC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpUaGUgJnF1b3Q7cmVxdWVzdF91cmkmcXVvdDsgdmFsdWUgTVVTVCBiZSBnZW5lcmF0ZWQg dXNpbmcgYSBjcnlwdG9ncmFwaGljYWxseTxiciBjbGFzcz0iIj4NCnN0cm9uZyBwc2V1ZG9yYW5k b20gYWxnb3JpdGhtPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K SSBhc3N1bWUgdGhpcyBpbmNsdWRlcyB0aGUgdXNlIG9mIGEgcmFuZG9tIG51bWJlciBpbnNpZGUg b2YgYSBKV1QsIGluPGJyIGNsYXNzPSIiPg0KY2FzZSB0aGUgQVMgd2FudHMgdG8gdXNlIEpXVHMg YXMgdGhlICZxdW90O3JlcXVlc3RfdXJpJnF1b3Q7IHBhcmFtZXRlciZxdW90Oz8gSWYgc28sPGJy IGNsYXNzPSIiPg0KaXQncyBwcm9iYWJseSB3b3J0aCBzcGVsbGluZyB0aGF0IG91dCBhcyBpdCBr aW5kIG9mIHJlYWRzIGxpa2UgaXQgaGFzPGJyIGNsYXNzPSIiPg0KdG8gYmUgbGl0ZXJhbGx5IGEg cmFuZG9tIHN0cmluZyBhdCBmaXJzdCBnbGFuY2UuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KVGhlIFVSSSBpcyBpbnRlbmRlZCB0byBiZSBhIHJlZmVyZW5jZSBu b3QgYSB2YWx1ZS4gSWYgdGhlIGNsaWVudCBjb3VsZCBzZW5kIGEgSldUIGl0IHdvdWxkIGp1c3Qg c2VuZCBhIHJlcXVlc3Qgb2JqZWN0IGluc3RlYWQgb2YgYSByZXF1ZXN0IFVSSSBpbiB0aGUgZmly c3QgcGxhY2UuIFNvIHRoZSBpbnRlbnQgaXMgdGhhdCBpdOKAmXMgcmFuZG9tLCBhbmQgbWF5YmUg d2Ugc2hvdWxkIGp1c3Qgc2F5IHRoYXQgZXhwbGljaXRseS48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGF0J3MgYWxsIGZvciBub3csIHRoYW5rcyE8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLS0tPGJyIGNsYXNzPSIiPg0KQWFyb24gUGFyZWNraTxi ciBjbGFzcz0iIj4NCmFhcm9ucGFyZWNraS5jb208YnIgY2xhc3M9IiI+DQpAYWFyb25wazxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIFNhdCwgU2VwIDIxLCAyMDE5IGF0IDE6MDIgUE0g VG9yc3RlbiBMb2RkZXJzdGVkdDxiciBjbGFzcz0iIj4NCiZsdDt0b3JzdGVuQGxvZGRlcnN0ZWR0 Lm5ldCZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KSGkgYWxsLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkganVzdCBwdWJsaXNoZWQg YSBuZXcgZHJhZnQgdGhhdCBCcmlhbiBDYW1wYmVsbCwgRGF2ZSBUb25nZSwgRmlsaXAgU2tva2Fu LCBOYXQgU2FraW11cmEgYW5kIEkgd3JvdGUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXBhci0w MDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkl0IHByb3Bvc2VzIGEgbmV3IGVuZHBvaW50 LCBjYWxsZWQgJnF1b3Q7cHVzaGVkIGF1dGhvcml6YXRpb24gcmVxdWVzdCBlbmRwb2ludOKAnSwg dGhhdCBhbGxvd3MgdGhlIGNsaWVudCB0byBwdXNoIHRoZSBBdXRob3JpemF0aW9uIFJlcXVlc3Qg cGF5bG9hZCB3aXRoIHRoZSBBUyBvbiBhIGJhY2tjaGFubmVsIGNvbm5lY3Rpb24gaW5zdGVhZCBv ZiBhIGZyb250IGNoYW5uZWwgaW50ZXJhY3Rpb24uIFRoZSBBUyBwcm92aWRlcyB0aGUgY2xpZW50 IHdpdGggYSByZXF1ZXN0DQogVVJJIChhY2NvcmRpbmcgdG8gZHJhZnQtaWV0Zi1vYXV0aC1qd3Ny ZXEpIHRoYXQgdGhlIGNsaWVudCB1c2VzIGluIGEgc3Vic2VxdWVudCBhdXRob3JpemF0aW9uIHJl cXVlc3RzIHRvIHJlZmVyIHRvIHRoZSBwdXNoZWQgcmVxdWVzdCBkYXRhLjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCldlIGJlbGlldmUgdGhpcyBzaW1wbGUgbWVjaGFuaXNtIHdpbGwgc2ln bmlmaWNhbnRseSBpbmNyZWFzZSBPQXV0aCBzZWN1cml0eSBhbmQgcm9idXN0bmVzcyBzaW5jZSBh bnkgYXBwbGljYXRpb24gY2FuIHVzZSBpdCBieSBqdXN0IHNlbmRpbmcgdGhlIHBhcmFtZXRlcnMg aW4gdGhlIHNhbWUgZW5jb2RpbmcgYXMgdXNlZCBhdCB0aGUgYXV0aG9yaXNhdGlvbiBlbmRwb2lu dCBvdmVyIGEgSFRUUFMtcHJvdGVjdGVkIGFuZCAoZm9yIGNvbmZpZGVudGlhbA0KIGNsaWVudHMp IG11dHVhbGx5IGF1dGhlbnRpY2F0ZWQgY29ubmVjdGlvbiB0byB0aGUgQVMuIEl0IGNhbiBhbHNv IGJlIHVzZWQgdG8gcHVzaCBzaWduZWQgYW5kIGVuY3J5cHRlZCByZXF1ZXN0IG9iamVjdHMgdG8g dGhlIEFTLCBpLmUuIGl0IHByb3ZpZGVzIGFuIGludGVyb3BlcmFibGUgd2F5IHRvIHVzZSByZXF1 ZXN0IG9iamVjdHMgbWFuYWdlZCBhdCB0aGUgQVMgZm9yIHVzZSBjYXNlcyByZXF1aXJpbmcgYW4g ZXZlbiBoaWdoZXIgc2VjdXJpdHkNCiBsZXZlbC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpXZSBsb29rIGZvcndhcmQgdG8gZ2V0dGluZyB5b3VyIGZlZWRiYWNrLjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCmtpbmQgcmVnYXJkcyw8YnIgY2xhc3M9IiI+DQpUb3JzdGVuLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxiciBj bGFzcz0iIj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbG9k ZGVyc3RlZHQtb2F1dGgtcGFyLTAwLnR4dDxiciBjbGFzcz0iIj4NCkRhdGU6IDIxLiBTZXB0ZW1i ZXIgMjAxOSBhdCAxMjo0NzoyOCBDRVNUPGJyIGNsYXNzPSIiPg0KVG86ICZxdW90O05hdCBTYWtp bXVyYSZxdW90OyAmbHQ7bmF0QHNha2ltdXJhLm9yZyZndDssICZxdW90O0JyaWFuIENhbXBiZWxs JnF1b3Q7ICZsdDtiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSZndDssICZxdW90O1RvcnN0ZW4g TG9kZGVyc3RlZHQmcXVvdDsgJmx0O3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0OywgJnF1b3Q7 RGF2ZSBUb25nZSZxdW90OyAmbHQ7ZGF2ZUB0b25nZS5vcmcmZ3Q7LCAmcXVvdDtGaWxpcCBTa29r YW4mcXVvdDsgJmx0O3BhbnZhLmlwQGdtYWlsLmNvbSZndDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbG9kZGVy c3RlZHQtb2F1dGgtcGFyLTAwLnR4dDxiciBjbGFzcz0iIj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgVG9yc3RlbiBMb2RkZXJzdGVkdCBhbmQgcG9zdGVkIHRvIHRoZTxiciBj bGFzcz0iIj4NCklFVEYgcmVwb3NpdG9yeS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpO YW1lOiBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1wYXI8YnIgY2xhc3M9IiI+DQpSZXZpc2lvbjog MDA8YnIgY2xhc3M9IiI+DQpUaXRsZTogT0F1dGggMi4wIFB1c2hlZCBBdXRob3JpemF0aW9uIFJl cXVlc3RzPGJyIGNsYXNzPSIiPg0KRG9jdW1lbnQgZGF0ZTogMjAxOS0wOS0yMTxiciBjbGFzcz0i Ij4NCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnIgY2xhc3M9IiI+DQpQYWdlczogMTI8 YnIgY2xhc3M9IiI+DQpVUkw6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1wYXItMDAudHh0PGJyIGNsYXNzPSIiPg0K U3RhdHVzOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDto dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1w YXIvPGJyIGNsYXNzPSIiPg0KSHRtbGl6ZWQ6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0 aC1wYXItMDA8YnIgY2xhc3M9IiI+DQpIdG1saXplZDogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1s b2RkZXJzdGVkdC1vYXV0aC1wYXI8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpBYnN0cmFjdDo8YnIgY2xhc3M9IiI+DQpUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhl IHB1c2hlZCBhdXRob3JpemF0aW9uIHJlcXVlc3QgZW5kcG9pbnQsPGJyIGNsYXNzPSIiPg0Kd2hp Y2ggYWxsb3dzIGNsaWVudHMgdG8gcHVzaCB0aGUgcGF5bG9hZCBvZiBhbiBPQXV0aCAyLjA8YnIg Y2xhc3M9IiI+DQphdXRob3JpemF0aW9uIHJlcXVlc3QgdG8gdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIHZpYSBhIGRpcmVjdDxiciBjbGFzcz0iIj4NCnJlcXVlc3QgYW5kIHByb3ZpZGVzIHRoZW0g d2l0aCBhIHJlcXVlc3QgVVJJIHRoYXQgaXMgdXNlZCBhczxiciBjbGFzcz0iIj4NCnJlZmVyZW5j ZSB0byB0aGUgZGF0YSBpbiBhIHN1YnNlcXVlbnQgYXV0aG9yaXphdGlvbiByZXF1ZXN0LjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnIgY2xhc3M9IiI+DQp1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5n IGxpc3Q8YnIgY2xhc3M9IiI+DQpPQXV0aEBpZXRmLm9yZzxiciBjbGFzcz0iIj4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0i Ij4NCk9BdXRoQGlldGYub3JnPGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C72FC21832E0481B92B36B3747261295mitedu_-- From nobody Fri Sep 27 10:22:21 2019 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 1C00E1209FD for ; Fri, 27 Sep 2019 10:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 u-4mfBxsAG22 for ; Fri, 27 Sep 2019 10:22:16 -0700 (PDT) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 0977D120019 for ; Fri, 27 Sep 2019 10:22:16 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id 7so3253066ljw.7 for ; Fri, 27 Sep 2019 10:22:15 -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=a+Gfqlro4NJqzoZ8NZASq7wD81B6+gyOrM7ip9+DDL0=; b=I8rLLHVyaw4CT0g7Qkmk9FEKO+WyJC9MIKUSNWmJBivACq02DyGy2udNxIwOJS2c6k NNldsG7e9PKNyaP7kn+DmulVtn985wUSupZn68FmAaszt8xR0adEhIX/3noGCwhsjIgG zOX1SILhmw5ZCmzo0iSOAA5lHZISter6B14qUYUqUnCFk57OWo3KvmgyWPbCEsB1urc+ 9ZsfkpsyAbKzZP+8dy0vu7c1DK4QsWwBVSpqmfvKayqrCet/np6S2ZR4AbGpqgr0ZpI0 BQlBlnrLymtRTsdAepcckaXMfyPg9bXcBckiF/VslfSFplVlHe8mM6Bf8dD83W14cLBg wXzw== 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=a+Gfqlro4NJqzoZ8NZASq7wD81B6+gyOrM7ip9+DDL0=; b=YT3AqgtZWi5xExcQ8dxs2rT9cyPE+sMdBrRhR6i3Q3IcrZfa9I5UMVCwsORfg9pU5/ QJ1gYltIFnH1kHTO1wyAgDX7lDWetKTC52wZ1RkbZm/quTrhaPuBMOODZogkIcoODShb jz2OakG0m4ffPEA7mqx5Z7IQLlsK0JdlwzeMyPdVPpPvWZvVsemLa1BfTUxfgEO9Alyl p4CQABcwUIy/i/QRQc/atiO6hEU0XE8dR+ky5Z9yqqOCfbzkkcaGYpKol/mC41p9dr6K VO69+QMkSJieEMPf8J3XYbWXRPXxBO5fVLab5skkxTTmTTvFLElae12icpTs/ShR8rEZ 51Pg== X-Gm-Message-State: APjAAAXw2azqmyrB3T0Vq7p67tV1p4WlaQcJosEitnONw9rbgp3cqGG5 QSnNdSQq6pUra3C6bgrDTVldY7+HjZBrYrFa50g= X-Google-Smtp-Source: APXvYqzM5MwSjikWbBl/0hv2HWSA6DvSCzYoRtZQ8uyuDsRIdm1btyc7iMvnKYfqCPsiZqpiE2Ex6JxINlwmxOCe/U0= X-Received: by 2002:a2e:7212:: with SMTP id n18mr3645914ljc.91.1569604934110; Fri, 27 Sep 2019 10:22:14 -0700 (PDT) MIME-Version: 1.0 References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> In-Reply-To: From: Dick Hardt Date: Fri, 27 Sep 2019 10:22:02 -0700 Message-ID: To: Justin Richer Cc: Aaron Parecki , oauth Content-Type: multipart/alternative; boundary="00000000000089130105938c2034" Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt 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: Fri, 27 Sep 2019 17:22:20 -0000 --00000000000089130105938c2034 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If I understand the proposal correctly, the request URI is opaque to the client. Correct? If so, why not just treat it as an opaque string? If I were implementing the protocol, I would have the blob be a signed token so that I could verify the integrity before making a database call. It much easier to throw compute at a DDOS attack to verify a signature, than DB capacity. =E1=90=A7 On Thu, Sep 26, 2019 at 2:24 PM Justin Richer wrote: > Yes, the request object is JWT-based, but the request URI is not. In othe= r > words, you can post a JWT but what you get back is a URI, not the JWT > itself. The request URI was always meant to be a reference, and original= ly > it was explicitly a reference to a signed request object. > > =E2=80=94 Justin > > On Sep 26, 2019, at 10:03 AM, Aaron Parecki wrote: > > The URI is intended to be a reference not a value. If the client could > send a JWT it would just send a request object instead of a request URI i= n > the first place. So the intent is that it=E2=80=99s random, and maybe we = should > just say that explicitly. > > > I thought this language was explicitly to allow the use of structured > values for the request_uri? From the introduction: > > but it also allows clients requiring an even > higher security level, especially cryptographically confirmed non- > repudiation, to explicitly adopt JWT-based request objects. > > > ---- > Aaron Parecki > aaronparecki.com > > On Thu, Sep 26, 2019 at 6:49 PM Justin Richer wrote: > > > Aaron, some comments inline. > > =E2=80=94 Justin > > On Sep 26, 2019, at 8:30 AM, Aaron Parecki wrote: > > Hi Torsten, > > I'm very glad to see this draft, I think it's definitely needed in > this space. Here are some of my thoughts on the draft. > > "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" > > > Is it acceptable for the AS to return just an opaque string, rather > than something prefixed with "uri:*"? I don't think anyone would be > confused about copypasting the exact string from the "request_uri" > response into the "request_uri" parameter even if it didn't start with > "urn:". If, for whatever reason, it is required that this value is > actually a URI, is there some expected namespace to use other than > "example"? I worry that if all the examples in the spec are just > "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up > using the text "example" because they don't understand why it's there, > and then it serves no purpose really.=E2=80=99 > > > This field must be a URI, as per JAR: > > request_uri The absolute URI as defined by RFC3986 [RFC3986] that > points to the Request Object (Section 2.1) that holds > authorization request parameters stated in section 4 of OAuth 2.0 > [RFC6749]. > > Somewhat awkwardly, the JAR spec currently states that the AS has to do a= n > HTTP GET on the request URI, so that will need to be fixed in JAR before = it > goes forward. I don=E2=80=99t think that was always the case though, and = I=E2=80=99m not > sure how that changed. > > As for the namespace, =E2=80=9Cexample=E2=80=9D is ok for an example URN.= The problem with > URNs is that nobody really understands how to do domain-safe fully > compliant URNs. So perhaps we should instead use =E2=80=9Curn:fdc:example= .com:=E2=80=A6.=E2=80=9D > Instead (as per https://tools.ietf.org/html/rfc4198). > > > The pushed authorization request endpoint shall be a RESTful API > > > I would drop the term RESTful and just say "HTTP API", as this > description is arguably RESTful at best. > > Depending on client type and authentication method, the request might > also include the "client_id" parameter. > > > I assume this is hinting at the difference between public clients > sending only the "client_id" parameter and confidential clients > sending only the HTTP Basic Authorization header which includes both > the client ID and secret? It would probably be helpful to call out > these two common examples if I am understanding this correctly, > otherwise it seems pretty vague. > > > Not quite, those differences are for the token endpoint, and this is > capturing things from the authorization endpoint. I don=E2=80=99t quite u= nderstand > the differentiation listed here either, though. > > > The "request_uri" value MUST be generated using a cryptographically > strong pseudorandom algorithm > > > I assume this includes the use of a random number inside of a JWT, in > case the AS wants to use JWTs as the "request_uri" parameter"? If so, > it's probably worth spelling that out as it kind of reads like it has > to be literally a random string at first glance. > > > The URI is intended to be a reference not a value. If the client could > send a JWT it would just send a request object instead of a request URI i= n > the first place. So the intent is that it=E2=80=99s random, and maybe we = should > just say that explicitly. > > > That's all for now, thanks! > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > On Sat, Sep 21, 2019 at 1:02 PM Torsten Lodderstedt > wrote: > > > Hi all, > > I just published a new draft that Brian Campbell, Dave Tonge, Filip > Skokan, Nat Sakimura and I wrote. > > https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 > > It proposes a new endpoint, called "pushed authorization request > endpoint=E2=80=9D, that allows the client to push the Authorization Reque= st payload > with the AS on a backchannel connection instead of a front channel > interaction. The AS provides the client with a request URI (according to > draft-ietf-oauth-jwsreq) that the client uses in a subsequent authorizati= on > requests to refer to the pushed request data. > > We believe this simple mechanism will significantly increase OAuth > security and robustness since any application can use it by just sending > the parameters in the same encoding as used at the authorisation endpoint > over a HTTPS-protected and (for confidential clients) mutually > authenticated connection to the AS. It can also be used to push signed an= d > encrypted request objects to the AS, i.e. it provides an interoperable wa= y > to use request objects managed at the AS for use cases requiring an even > higher security level. > > We look forward to getting your feedback. > > kind regards, > Torsten. > > Begin forwarded message: > > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-lodderstedt-oauth-par-00.txt > Date: 21. September 2019 at 12:47:28 CEST > To: "Nat Sakimura" , "Brian Campbell" < > bcampbell@pingidentity.com>, "Torsten Lodderstedt" < > torsten@lodderstedt.net>, "Dave Tonge" , "Filip Skokan" < > panva.ip@gmail.com> > > > A new version of I-D, draft-lodderstedt-oauth-par-00.txt > has been successfully submitted by Torsten Lodderstedt and posted to the > IETF repository. > > Name: draft-lodderstedt-oauth-par > Revision: 00 > Title: OAuth 2.0 Pushed Authorization Requests > Document date: 2019-09-21 > Group: Individual Submission > Pages: 12 > URL: > https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-par-00.txt > Status: > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ > Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-par-0= 0 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par > > > Abstract: > This document defines the pushed authorization request endpoint, > which allows clients to push the payload of an OAuth 2.0 > authorization request to the authorization server via a direct > request and provides them with a request URI that is used as > reference to the data in a subsequent authorization request. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000089130105938c2034 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If I understand the proposal correctly, the request URI is= opaque to the client. Correct?

If so, why not just trea= t it as an opaque string?

If I were implementing t= he protocol, I would have the blob be a signed token so that I could verify= the integrity before making a database call. It much easier to throw compu= te at a DDOS attack to verify a signature, than DB capacity.

=
=E1=90=A7

<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 26, 2019 at 2:24 PM Justin= Richer <jricher@mit.edu> wrot= e:
Yes, the request object is JWT-based, but the request URI is not. In other = words, you can post a JWT but what you get back is a URI, not the JWT itsel= f.=C2=A0 The request URI was always meant to be a reference, and originally= it was explicitly a reference to a signed request object.=C2=A0

=E2=80=94 Justin

On Sep 26, 2019, at 10:03 AM, Aaron Parecki <aaron@parecki.com> wrote:

The URI is intended to be a reference not a value= . If the client could send a JWT it would just send a request object instea= d of a request URI in the first place. So the intent is that it=E2=80=99s r= andom, and maybe we should just say that explicitly.

I thought this language was explicitly to allow the use of structured
values for the request_uri? From the introduction:

but it also allows clients requiring an even
higher security level, especially cryptographically confirmed non-
repudiation, to explicitly adopt JWT-based request objects.

----
Aaron Parecki
aaronparecki.com<= br>
On Thu, Sep 26, 2019 at 6:49 PM Justin Richer <jricher@mit.edu> wrote:

Aaron, some comments inline.

=E2=80=94 Justin

On Sep 26, 2019, at 8:30 AM, Aaron Parecki <aaron@parecki.com> wrote:

Hi Torsten,

I'm very glad to see this draft, I think it's definitely needed in<= br> this space. Here are some of my thoughts on the draft.

"request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2"= ;


Is it acceptable for the AS to return just an opaque string, rather
than something prefixed with "uri:*"? I don't think anyone wo= uld be
confused about copypasting the exact string from the "request_uri"= ;
response into the "request_uri" parameter even if it didn't s= tart with
"urn:". If, for whatever reason, it is required that this value i= s
actually a URI, is there some expected namespace to use other than
"example"? I worry that if all the examples in the spec are just<= br> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will en= d up
using the text "example" because they don't understand why it= 's there,
and then it serves no purpose really.=E2=80=99


This field must be a URI, as per JAR:

=C2=A0=C2=A0request_uri =C2=A0The absolute URI as defined by RFC3986 [RFC39= 86] that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0points to the Request Object (Section 2.1) th= at holds
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0authorization request parameters stated in se= ction 4 of OAuth 2.0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[RFC6749].

Somewhat awkwardly, the JAR spec currently states that the AS has to do an = HTTP GET on the request URI, so that will need to be fixed in JAR before it= goes forward. I don=E2=80=99t think that was always the case though, and I= =E2=80=99m not sure how that changed.

As for the namespace, =E2=80=9Cexample=E2=80=9D is ok for an example URN. T= he problem with URNs is that nobody really understands how to do domain-saf= e fully compliant URNs. So perhaps we should instead use =E2=80=9Curn:fdc:e= xample.com:=E2=80=A6.=E2=80=9D Instead (as per https://tools.ietf.org/html/rfc4198).


The pushed authorization request endpoint shall be a RESTful API


I would drop the term RESTful and just say "HTTP API", as this description is arguably RESTful at best.

Depending on client type and authentication method, the request might
also include the "client_id" parameter.


I assume this is hinting at the difference between public clients
sending only the "client_id" parameter and confidential clients sending only the HTTP Basic Authorization header which includes both
the client ID and secret? It would probably be helpful to call out
these two common examples if I am understanding this correctly,
otherwise it seems pretty vague.


Not quite, those differences are for the token endpoint, and this is captur= ing things from the authorization endpoint. I don=E2=80=99t quite understan= d the differentiation listed here either, though.


The "request_uri" value MUST be generated using a cryptographical= ly
strong pseudorandom algorithm


I assume this includes the use of a random number inside of a JWT, in
case the AS wants to use JWTs as the "request_uri" parameter"= ;? If so,
it's probably worth spelling that out as it kind of reads like it has to be literally a random string at first glance.


The URI is intended to be a reference not a value. If the client could send= a JWT it would just send a request object instead of a request URI in the = first place. So the intent is that it=E2=80=99s random, and maybe we should= just say that explicitly.


That's all for now, thanks!

----
Aaron Parecki
aaronparecki.com<= br> @aaronpk

On Sat, Sep 21, 2019 at 1:02 PM Torsten Lodderstedt
<torsten@lo= dderstedt.net> wrote:


Hi all,

I just published a new draft that Brian Campbell, Dave Tonge, Filip Skokan,= Nat Sakimura and I wrote.

https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00

It proposes a new endpoint, called "pushed authorization request endpo= int=E2=80=9D, that allows the client to push the Authorization Request payl= oad with the AS on a backchannel connection instead of a front channel inte= raction. The AS provides the client with a request URI (according to draft-ietf-oauth-jwsreq) that the client uses in a subse= quent authorization requests to refer to the pushed request data.

We believe this simple mechanism will significantly increase OAuth security= and robustness since any application can use it by just sending the parame= ters in the same encoding as used at the authorisation endpoint over a HTTP= S-protected and (for confidential clients) mutually authenticated connection to the AS. It can also be used = to push signed and encrypted request objects to the AS, i.e. it provides an= interoperable way to use request objects managed at the AS for use cases r= equiring an even higher security level.

We look forward to getting your feedback.

kind regards,
Torsten.

Begin forwarded message:

From: interne= t-drafts@ietf.org
Subject: New Version Notification for draft-lodderstedt-oauth-par-00.txt Date: 21. September 2019 at 12:47:28 CEST
To: "Nat Sakimura" <nat@sakimura.org>, "Brian Campbell" <bcampbell@pingide= ntity.com>, "Torsten Lodderstedt" <torsten@lodderstedt.net>, &= quot;Dave Tonge" <dave@tonge.org>, "Filip Skokan" <panva.ip@gmail.com>


A new version of I-D, draft-lodderstedt-oauth-par-00.txt
has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository.

Name: draft-lodderstedt-oauth-par
Revision: 00
Title: OAuth 2.0 Pushed Authorization Requests
Document date: 2019-09-21
Group: Individual Submission
Pages: 12
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-lodderste= dt-oauth-par-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht= tps://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.i= etf.org/html/draft-lodderstedt-oauth-par-00
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://= datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par


Abstract:
This document defines the pushed authorization request endpoint,
which allows clients to push the payload of an OAuth 2.0
authorization request to the authorization server via a direct
request and provides them with a request URI that is used as
reference to the data in a subsequent authorization request.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000089130105938c2034-- From nobody Fri Sep 27 15:51:14 2019 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 9F7C212021C for ; Fri, 27 Sep 2019 15:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 EEf_LgeJVWOB for ; Fri, 27 Sep 2019 15:51:12 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 C2E20120071 for ; Fri, 27 Sep 2019 15:51:11 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x8RMp7LU003169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Sep 2019 18:51:09 -0400 Date: Fri, 27 Sep 2019 15:51:06 -0700 From: Benjamin Kaduk To: Travis Spencer Cc: oauth Message-ID: <20190927225106.GE6424@kduck.mit.edu> References: <156898250596.30287.14524104153595179086@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt 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: Fri, 27 Sep 2019 22:51:14 -0000 On Thu, Sep 26, 2019 at 11:26:31AM +0200, Travis Spencer wrote: > * Last but certainly not least is the restriction that the current > version places on disallowing of the introspection JWT response as an > access token. This is done in numerous places (the note in section 5, > 8.1, etc.). I understand that there are some objection to this usage, > but we have had this protocol deployed for years, and it's running in > dozens of customer's facilities. This will break real applications of > this specification without a clear alternative. As we discussed in > London last year at the IETF meeting, token exchange isn't a viable > alternative (even still in its current draft form to the best of my > knowledge). Without a workable alternative to move to, I emphatically > but humbly request that this specification remove this restriction. I don't think I was in the London session, so would you mind saying a bit more about why token exchange isn't viable for your scenario? As an AD, I support the efforts to be explicit about what token flow/usage is being defined, which in effect means keeping introspection just introspection and not "producing new tokens". Thanks, Ben From nobody Sat Sep 28 06:36:19 2019 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 07358120115 for ; Sat, 28 Sep 2019 06:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=curity-io.20150623.gappssmtp.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 FmeUPwHiPs2P for ; Sat, 28 Sep 2019 06:36:16 -0700 (PDT) Received: from mail-yw1-xc43.google.com (mail-yw1-xc43.google.com [IPv6:2607:f8b0:4864:20::c43]) (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 1B2FD12001E for ; Sat, 28 Sep 2019 06:36:16 -0700 (PDT) Received: by mail-yw1-xc43.google.com with SMTP id x64so1897741ywg.3 for ; Sat, 28 Sep 2019 06:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xfz8dOd+jyDYg7DccPcDuFUiFv1WQIay87GBtC6N2Fg=; b=h9AqCAE8cZvxaaqtj7uRoXFUUJXuu0NMQtXSeu1JpGIpIKBgiCm9oQD0pKCRCoavPz KWNlz6WLcLJyg3w6sQp+JymCAZTwyjEqXorpvU3RqiESIh7hntFaId0XwAlsuH7X8vGM YOFZ2RKSd57VxQWnRbdrUlS7bIiGkO7bTmB9IVdAlDvhfioMbzQm3CWUzCM8V1UI2Mxb nAAvaCrPshQiICWWQP5BPYAf0FFVq1dd4BkQVvKnvQB1yNnxCbgpj3+LxSl/Z1aawm9i jMzRpt7DnVSjB/U2hVy86RrMo9HECRt5oTf52nzD92OzyNh00o/m8PjKow2bpQJaGj3a pBjA== 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=xfz8dOd+jyDYg7DccPcDuFUiFv1WQIay87GBtC6N2Fg=; b=G4s+QoqZor+mxBflSkbL4cyFJggkrqMtSFOymoF7/agv7VMA5KBGdAwwimfNY38AJT EN6bQCNnySADf2QHR4U6mASYCoch1RuZLM8+03UsCU2NRrKTKjqm5OFtgLPdccZe3028 i2RGctwzXQNOie9wa39yC2lZSmMZprSEtjWyNetR+RDbO00YLCZK06XPJGC4mi/Caxdq oO+9TXSUw1U5U7yQGKwwyXguFvOikY17mkD++UPY7N2XVRBfyz+5H/AjSS00E/NNMB0G DZsQCJC1APCp0qucDlecn4ZLNopLKZ9dIukOX+pbsC5NHXxnU9M+6ClvgtxmCOtCl+SF FKog== X-Gm-Message-State: APjAAAVybqpw/5LTuksa29vXZXS854N3KEHZCjoVhYIcDvAmtlSRfU58 V3fOFtzM3Fv7Lhb0hD5YzefYpwNBUpfgFYzBKndFDinwSSM= X-Google-Smtp-Source: APXvYqySa6r0fqsRhjMYXxWpP8ZavrU1opSSIMSZScGwu6JEX8fGjOh0/isCEG0mip4UQVZyOKz0v+4RLoJ1qYHOEOA= X-Received: by 2002:a81:c202:: with SMTP id z2mr6241712ywc.47.1569677774158; Sat, 28 Sep 2019 06:36:14 -0700 (PDT) MIME-Version: 1.0 References: <156898250596.30287.14524104153595179086@ietfa.amsl.com> <20190927225106.GE6424@kduck.mit.edu> In-Reply-To: <20190927225106.GE6424@kduck.mit.edu> From: Travis Spencer Date: Sat, 28 Sep 2019 15:36:02 +0200 Message-ID: To: Benjamin Kaduk Cc: oauth Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt 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: Sat, 28 Sep 2019 13:36:18 -0000 On Sat, Sep 28, 2019 at 12:51 AM Benjamin Kaduk wrote: > On Thu, Sep 26, 2019 at 11:26:31AM +0200, Travis Spencer wrote: > > * Last but certainly not least is the restriction that the current > > version places on disallowing of the introspection JWT response as an > > access token. This is done in numerous places (the note in section 5, > > 8.1, etc.). I understand that there are some objection to this usage, > > but we have had this protocol deployed for years, and it's running in > > dozens of customer's facilities. This will break real applications of > > this specification without a clear alternative. As we discussed in > > London last year at the IETF meeting, token exchange isn't a viable > > alternative (even still in its current draft form to the best of my > > knowledge). Without a workable alternative to move to, I emphatically > > but humbly request that this specification remove this restriction. > > I don't think I was in the London session, so would you mind saying a bit > more about why token exchange isn't viable for your scenario? A few reasons: 1. There is no way to do content negotiation in token exchange as there is in this protocol. For some clients, this is preferable and easier. 2. The desired response body is not a simple stream that can be processed quickly and efficiently (like the one defined by this protocol). The exchanged token must be parsed out of the token exchange response. 3. Creating the payload of the request is slightly more involved, and the client is often limited in its capabilities[1] 4. HTTP cache controls that are tied to the input token validity period can't be applied as easily to the token endpoint response because the client has to parse the token exchange response (slower) or cache the entire reply (more memory) 5. The HTTP status code I mentioned in my last mail isn't defined as a way of communicating to the client that the input token is expired. This provides a client with the fastest way of knowing that a token is expired (that I can determine at least). 6. Migration of the clients and deployments using JWT introspection response will be costly and time consuming with little gain (in my judgement at least) > As an AD, I support the efforts to be explicit about what token flow/usage > is being defined, which in effect means keeping introspection just > introspection and not "producing new tokens". I can appreciate this, but I don't see what I'm proposing as producing new tokens. Instead, I see it as re-encoding the same token in a different form. The subject is the same, the audience(s) is/are the same, the expiration time is the same, the claims are the same. They're just signed and have a new issuance time. In our implementation, the original token and the JWT version both stem from the same "delegation", so both are traceable back to the same end-user authorization, implying that both are invalidated when that delegation is expired or is revoked (which the end user can do or the client can do if it revokes a refresh token if it was given one). The use case we're using this protocol for is about re-encoding an access token in another form that is also used as an access token. [1] This argument is admittedly weak, as discussed at the IETF meeting. From nobody Mon Sep 30 02:30:31 2019 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 7074C120180 for ; Mon, 30 Sep 2019 02:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=logius.nl 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 Qi3uVgHKjqIU for ; Mon, 30 Sep 2019 02:30:26 -0700 (PDT) Received: from mail.ssonet.nl (mail.ssonet.nl [144.43.249.200]) (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 0B3B7120147 for ; Mon, 30 Sep 2019 02:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=logius.nl; i=@logius.nl; q=dns/txt; s=Selector2; t=1569835826; x=1601371826; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fluA7eOdn3hVvhn59tNT7jry+JFPErZtpAmSiIPTowI=; b=FeOgYvIrtarSXhL4lEaHrXwrk6bCjbDSQ0FBlElZCoUg0Es6ONnhBaYZ 2N+55mfDL4yCyiyHuk+b1K5nj2RZYkNmJPXTIsUDWZcAGyNxXDtYEoGug eS1LtrXbC4ysdxE2gP9J4NtxEZiRVkbrKSXe2c2LqV+kLKNmfLeuYu7rc EUckP2fya7tBD8EbIAnVhSd0C8TeXBsjmtyO6WtVi2E+XhELu5cmEK7K1 G6zQOYIs/d6xr6DZA9W9TyrpuUbqeAyLpl9vNVdWY/sJsYpTSDOKh3es7 ieo2li5Adndf/Tj35gMwqzsKNtJHQkdhNpuC07PLVpYv4wcGbCgQtKm/H Q==; IronPort-SDR: sDWdmQGQLfLhi3ba8rNwW/uvAKKOKq3S2gZIiwF785pLCnsveIkoCW0ityHrA1DSs8Bewh8LWo ABa+ArmmvIUg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FTAACCypFd/8HfK5BdCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEMAQEBAQEBgWcCgUkkBSqBYBIqCoQYkH6ZO4FkCQEBAQ4tAgEBhEA?= =?us-ascii?q?CF4MqIzgSAQIDCQEBAQEDAQEBAQEFAwEBAQJphGtOQgEQAYFmKQGDPAEBAQE?= =?us-ascii?q?CASMRMxIFCwIBBgINCwICJgICAjAVEAIEDgUIhRYPAZAxmnx1gTIaiiKBDCg?= =?us-ascii?q?BhRWEByiCOoFoPoQjPoQaFIMhglgEjFAgE4JWnFBuBwOCIohPg36INiOCN4t?= =?us-ascii?q?lAxCLB6UGgmKBaSJEgRR8Og97HYEmKVAQghpvAQGNHEMxgSmBRos9KIEJAYE?= =?us-ascii?q?iAQE?= X-IPAS-Result: =?us-ascii?q?A2FTAACCypFd/8HfK5BdCRkBAQEBAQEBAQEBAQEMAQEBA?= =?us-ascii?q?QEBgWcCgUkkBSqBYBIqCoQYkH6ZO4FkCQEBAQ4tAgEBhEACF4MqIzgSAQIDC?= =?us-ascii?q?QEBAQEDAQEBAQEFAwEBAQJphGtOQgEQAYFmKQGDPAEBAQECASMRMxIFCwIBB?= =?us-ascii?q?gINCwICJgICAjAVEAIEDgUIhRYPAZAxmnx1gTIaiiKBDCgBhRWEByiCOoFoP?= =?us-ascii?q?oQjPoQaFIMhglgEjFAgE4JWnFBuBwOCIohPg36INiOCN4tlAxCLB6UGgmKBa?= =?us-ascii?q?SJEgRR8Og97HYEmKVAQghpvAQGNHEMxgSmBRos9KIEJAYEiAQE?= X-IronPort-AV: E=McAfee;i="6000,8403,9395"; a="40025364" X-IronPort-AV: E=Sophos;i="5.64,565,1559512800"; d="scan'208";a="40025364" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False From: "Schaar, R.M. (Remco) - Logius" To: 'Torsten Lodderstedt' CC: "'oauth@ietf.org'" Thread-Topic: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 Thread-Index: AQHVVPNIj99CrYifUEuqB+4o77upAKcQWBzEgAsCaAmAKNdpoA== Date: Mon, 30 Sep 2019 09:30:21 +0000 Message-ID: <5033059d916243e5ac20dc0f8f12f73d@SV1601499.frd.shsdir.nl> References: <38503cd44d9e455bad4432d9ba5e82e8@SV1601507.frd.shsdir.nl> <308A4847-6390-4D17-BE52-B604E2428391@lodderstedt.net> <10f13f75c100454aa8092961673541b2@SV1601499.frd.shsdir.nl> <040dcf9971fd4c618e94b957461d14f2@SV1601507.frd.shsdir.nl> <9468283E-8B97-4DAF-8493-895B475F6BC9@lodderstedt.net> In-Reply-To: <9468283E-8B97-4DAF-8493-895B475F6BC9@lodderstedt.net> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [144.43.223.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 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, 30 Sep 2019 09:30:29 -0000 SGVsbG8gVG9yc3RlbiwNCg0KVGhhbmtzIGZvciBjbGFyaWZ5aW5nIHRoZSB0ZXh0IGluIGRyYWZ0 IC0wOC4gSSB0aGluayB0aGVyZSBpcyBubyBhbWJpZ3VpdHkgbGVmdCwNCmFzIHRoZSBzZWN0aW9u ICJKV1QgcmVzcG9uc2UiIG5vdyBjbGVhcmx5IGRlc2NyaWJlcyB0aGUgY29udGVudHMuDQoNCkFz IGZvciBhIHJlcGxheSBhdHRhY2ssIGl0IHdpbGwgcmVxdWlyZSBhbm90aGVyIGF0dGFjayB0byBi dWlsZCB1cG9uLiBBIGJyb2tlbg0KaW1wbGVtZW50YXRpb24gZm9yIFRMUyAoZS5nLiAiaGVhcnRi bGVlZCIpIG9yIGFuIGluc2lkZXIgYXQgYW4gUlMNCm1hbmlwdWxhdGluZyBzdG9yZWQgZXZpZGVu Y2UgY29tZSB0byBtaW5kLiBNYXliZSBhIGJpdCBmYXJmZXRjaGVkLCBidXQNCmhhdmluZyBzaWdu ZWQgcmVzcG9uc2VzIHdpbGwgaGVscCB3aXRoIGEgZGVmZW5zZS1pbi1kZXB0aCBkZXNpZ24uDQoN Ckkgc2VlIHRoZSAnaWF0JyBvcHRpb24gd2FzIHNlbGVjdGVkLiBXb3JrcyBmb3IgbWUsIGFzIHRo ZSByZXN1bHQgaXMNCnVuZXF1aXZvY2FsbHkgZGVzY3JpYmVkLiBPbmx5IGRvd25zaWRlIEkgY2Fu IHRoaW5rIG9mLCBpcyB0aGF0IGludGVycHJldGF0aW9uDQpvZiBzaWduZWQgdmVyc3VzIG5vbi1z aWduZWQgaW50cm9zcGVjdGlvbiByZXNwb25zZXMgd2lsbCBkaWZmZXIuIFRoYXQgaXMNCmFjY2Vw dGFibGUgYXMgZmFyIGFzIEkgYW0gY29uY2VybmVkLg0KDQpLaW5kIHJlZ2FyZHMsDQpSZW1jbyBT Y2hhYXINCg0KLS0tLS1Pb3JzcHJvbmtlbGlqayBiZXJpY2h0LS0tLS0NClZhbjogVG9yc3RlbiBM b2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IA0KVmVyem9uZGVuOiB3b2Vuc2Rh ZyA0IHNlcHRlbWJlciAyMDE5IDExOjIyDQpBYW46IFNjaGFhciwgUi5NLiAoUmVtY28pIC0gTG9n aXVzIDxyZW1jby5zY2hhYXJAbG9naXVzLm5sPg0KQ0M6IG9hdXRoQGlldGYub3JnDQpPbmRlcndl cnA6IFJlOiBbT0FVVEgtV0ddIFF1ZXN0aW9uIHJlZ2FyZGluZyBkcmFmdC1pZXRmLW9hdXRoLWp3 dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNlLTA1DQoNCkhpIFJlbWNvLA0KDQo+IE9uIDMxLiBBdWcg MjAxOSwgYXQgMjE6MjcsIFNjaGFhciwgUi5NLiAoUmVtY28pIC0gTG9naXVzIDxyZW1jby5zY2hh YXJAbG9naXVzLm5sPiB3cm90ZToNCj4gDQo+IEhlbGxvIFRvcnN0ZW4sDQo+IA0KPiAobXkgYXBv bG9naWVzIGZvciBtYWtpbmcgYSB0eXBvIHByZXZpb3VzbHkpDQoNClRoYW5rcyA6LSkNCg0KPiAN Cj4gVGltZSBvZiBpbnRyb3NwZWN0aW9uIGlzIGNyaXRpY2FsIGlmIHlvdSB3YW50IHRvIHVzZSB0 aGUgc2lnbmVkIGludHJvc3BlY3Rpb24NCj4gcmVzcG9uc2UgZm9yIGxhdGVyIGFjY291bnRhYmls aXR5IG9yIGF1ZGl0IHB1cnBvc2VzLiBGb3IgZXhhbXBsZSwgYSBDbGllbnQNCj4gb2J0YWlucyBh biBhY2Nlc3MgdG9rZW4gQSBhdCB0aW1lIHQuIE5vdyBhIHJlc291cmNlIHNlcnZlciByZWNlaXZl cyBBIGF0IHRpbWUNCj4gdCsxLCBjYWxscyBpbnRyb3NwZWN0aW9uIGFuZCByZWNlaXZlcyBhIHJl c3BvbnNlIGNvbnRhaW5pbmcgYWN0aXZlPXRydWUuIEF0DQo+IHQrMiB0aGUgYWNjY2VzcyB0b2tl biBpcyByZXZva2VkLiBBdCB0aW1lIHQrMyB0aGUgcmVzb3VyY2Ugc2VydmVyIG1ha2VzIGEgbmV3 DQo+IGludHJvc3BlY3Rpb24gcmVxdWVzdCwgbm93IHJlY2VpdmVzIGEgcmVzcG9uc2UgY29udGFp bmluZyBhY3RpdmU9ZmFsc2UuIFRoZQ0KPiBvbmx5IGRpZmZlcmVuY2Ugd291bGQgYmUgdGhlIHZh bHVlIG9mIHRoZSBhY3RpdmUgcGFyYW1ldGVyLiBXaXRob3V0IHRoZSB0aW1lDQo+IG9mIGludHJv c3BlY3Rpb24gbm9yIGEgdW5pcXVlIGlkIGNvdmVyZWQgYnkgdGhlIHNpZ25hdHVyZSwgb25lIGNh bm5vdCBtYWtlIGENCj4gY29uY2x1c2l2ZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHN1YnNlcXVlbnQg cmVzcG9uc2VzIGlmIHJldm9jYXRpb24gbWF5IGJlIGluDQo+IHBsYXkuDQoNClRoYXTigJlzIGEg Z29vZCBwb2ludC4gIA0KDQo+IA0KPiBUaGUgZHJhZnQgc3BlY2lmaWVzIA0KPiAgICAgICBbLi4u XSB0byByZXR1cm4gcmVzcG9uc2VzIGFzIEpXVHMuDQo+IFRoaXMgY291bGQgZWl0aGVyIG1lYW4g InRoZSByZXNwb25zZSBpcyByZXR1cm5lZCBpbiBKV1QgZm9ybWF0IiBvciAidGhlDQo+IHJlc3Bv bnNlIGNvbnRhaW5zIGEgSldUIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBpbnNwZWN0ZWQgdG9rZW7i gJ0uDQoNCkknbSBtZWFud2hpbGUgbGVhbmluZyB0b3dhcmRzICJ0aGUgcmVzcG9uc2UgaXMgcmV0 dXJuZWQgaW4gSldUIGZvcm1hdOKAnS4NCg0KPiBOb3QgaGF2aW5nDQo+IGNsZWFyLCBzZXBhcmF0 ZSBwYXJhbWV0ZXJzIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gdGhlIHRpbWUgYW5kIGlkIG9mIHRo ZQ0KPiB0b2tlbiBhbmQgdGhlIHRpbWUgYW5kIGlkIG9mIHRoZSByZXNwb25zZSByZXN1bHRzIGlu IGRvdWJsZSBtZWFuaW5nLiBBcyBhDQo+IGNvbnNlcXVlbmNlLCBpdCBpcyBlaXRoZXIgaGF2aW5n IHRoZSByaXNrIG9mIHJlcGxheSBvZiBhbiBhY2Nlc3MgdG9rZW4gb3INCj4gcmVwbGF5IG9mIGFu IGludHJvc3BlY3Rpb24gcmVzcG9uc2UgaW5zdGVhZCBvZiBuZWl0aGVyLg0KDQpJ4oCZbSBub3Qg c3VyZSBob3cgYW4gYXR0YWNrZXIgY291bGQgcmVwbGF5IGFuIGludHJvc3BlY3Rpb24gcmVzcG9u c2UgZ2l2ZW4gaXQgaXMgdGlnaHRlZCB0byBhIGNlcnRhaW4gZW5kcG9pbnQgdmlhIHRoZSBpc3Mg Y2xhaW0uIA0KDQpJIGFncmVlIHRoZSBSUyBsYWNrcyBhIHdheSB0byBwcm9vZiB3aGVuIGl0IHdh cyBwcm92aWRlZCB3aXRoIHRoZSBhY2Nlc3MgdG9rZW4gZGF0YSBieSB0aGUgQVMuIA0KDQpUaGUg cHJvYmxlbSBpbiBteSBvcGluaW9uIGlzIHRoZSBvdmVybGF5IGJldHdlZW4gdGhlIG9yaWdpbmFs IGFjY2VzcyB0b2tlbiBkYXRhIChlLmcuIHdoZW4gd2FzIGl0IGlzc3VlZCBieSB0aGUgQVMpIGFu ZCB0aGUgZGF0YSBiZWxvbmdpbmcgdG8gdGhlIHJlcHJlc2VudGF0aW9uIGluIHRoZSBpbnRyb3Nw ZWN0aW9uIHJlc3BvbnNlICh3aGVuIHdhcyB0aGUgcmVzcG9uc2UgY3JlYXRlZCkuIENvbmNlcHR1 YWxseSwgdGhpcyBtZWFucyB3ZSByZXF1aXJlIHR3byBzZXBhcmF0IOKAnGlhdCIgKGFsaWtlKSBj bGFpbXMgdG8gZGlzdGluZ3Vpc2ggYm90aCBhc3BlY3RzLiANCg0KSSBjb3VsZCBpbWFnZSB0d28g d2F5cyB0byBoYW5kbGUgdGhpczoNCi0gYWRkIGFub3RoZXIgaWF0IGNsYWltLCBlLmcuIOKAnHRp cl9pYXQiLCB0byB0aGUgSldUDQotIGFkZCBhbm90aGVyIOKAnGlhdCIgY2xhaW0gdG8gdGhlIEpX UyBoZWFkZXIgY29udGFpbmluZyB0aGUgaW5zdGFudCB3aGVuIHRoZSB0b2tlbiBpbnRyb3NwZWN0 aW9uIHJlc3BvbnNlIHdhcyBjcmVhdGVkDQoNCldoYXQgZG8geW91IHRoaW5rPw0KDQpiZXN0IHJl Z2FyZHMsDQpUb3JzdGVuLiANCg0KPiANCj4gS2luZCByZWdhcmRzLA0KPiBSZW1jbyBzY2hhYXIN Cj4gDQo+IC0tLS0tT29yc3Byb25rZWxpamsgYmVyaWNodC0tLS0tDQo+IFZhbjogVG9yc3RlbiBM b2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IA0KPiBWZXJ6b25kZW46IHdvZW5z ZGFnIDI4IGF1Z3VzdHVzIDIwMTkgMTE6MTQNCj4gQWFuOiBTY2hhYXIsIFIuTS4gKFJlbWNvKSAt IExvZ2l1cyA8cmVtY28uc2NoYWFyQGxvZ2l1cy5ubD4NCj4gQ0M6IG9hdXRoQGlldGYub3JnDQo+ IE9uZGVyd2VycDogUmU6IFtPQVVUSC1XR10gUXVlc3Rpb24gcmVnYXJkaW5nIGRyYWZ0LWlldGYt b2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVzcG9uc2UtMDUNCj4gDQo+IEhpIFJoZW1jbywNCj4g DQo+PiBPbiAyNi4gQXVnIDIwMTksIGF0IDA5OjQyLCBTY2hhYXIsIFIuTS4gKFJlbWNvKSAtIExv Z2l1cyA8cmVtY28uc2NoYWFyQGxvZ2l1cy5ubD4gd3JvdGU6DQo+PiANCj4+IEhlbGxvIFRob3Jz dGVuLA0KPj4gDQo+PiBUaGFuayB5b3UgZm9yIHlvdXIgcmVzcG9uc2UuIEkgaGF2ZSBhIGZldyBt b3JlIHF1ZXN0aW9ucy9jb21tZW50cyBhcw0KPj4gZm9sbG93LXVwLi4uDQo+PiANCj4+IFlvdSBz dGF0ZSB0aGF0IFJGQzc1MTkgYW5kIFJGQzc2NjIgImp1c3QiIGRlZmluZSBkaWZmZXJlbnQgcmVw cmVzZW50YXRpb25zDQo+PiBmb3IgdG9rZW4gZGF0YS4gSWYgdGhlIGRyYWZ0IFJGQyB3b3VsZCBy ZWZlciB0byBSRkMgNzUxNSAoSldTKSwgSSB3b3VsZA0KPj4gYWdyZWUuIEhvd2V2ZXIsIFJGQzc1 MTkgKEpXVCkgZXhwbGljaXRseSBhZGRzIHNlbWFudGljcyB0byBzb21lIHNwZWNpZmljDQo+PiBw YXJhbWV0ZXJzIChlLmcuIGF1ZCwganRpIGFuZCBpYXQpLiBSRkM3NjYyIGhhcyBkaWZmZXJlbnQg c2VtYW50aWNzIGZvcg0KPj4gdGhlIHNldmVyYWwgb2YgdGhlIHNhbWUgcGFyYW1ldGVycy4NCj4+ IEZvciBpbnN0YW5jZSB0aGUgJ2lhdCcsIGlzIHRoZSBtb21lbnQgb2YgaXNzdWFuY2Ugb2YgdGhl IEpXVCBpbiBSRkM3NTE5LiBJbg0KPj4gUkZDNzY2MiB0aGF0IGlzIHRoZSAid2hlbiB0aGlzIHRv a2VuIHdhcyBvcmlnaW5hbGx5IGlzc3VlZCIuIFRoaXMgdGltZSB3aWxsDQo+PiB2YXJ5IGluIHVz ZSBjYXNlcyB3aXRob3V0IGltbWVkaWF0ZSBpbnRyb3NwZWN0aW9uIG9mIGFuIGFjY2VzcyB0b2tl bi4NCj4gDQo+IEkgcmVhZCB0aGUgdGV4dCBkaWZmZXJlbnRseS4gSW4gbXkgaW50ZXJwcmV0YXRp b24g4oCcd2hlbiB0aGUgdG9rZW4gd2FzIG9yaWdpbmFsbHkgaXNzdWVk4oCdIHN0YXRlZCBmcm9t IHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgaW50cm9zcGVjdGlvbiBlbmRwb2ludCByZWZlcnMgZXhh Y3RseSB0byB0aGUgc2FtZSBpbnN0YW50IGFzIOKAnHRoZSB0aW1lIGF0IHdoaWNoIHRoZSBKV1Qg d2FzDQo+ICAgaXNzdWVk4oCdLg0KPiANCj4+IA0KPj4gRm9yIHRoZSB1c2UgY2FzZSBvZiB0aGUg cmVzb3VyY2Ugc2VydmVyIHJlbHlpbmcgb24gdmVyaWZpYWJsZSBkYXRhLCBhcw0KPj4gZGVzY3Jp YmVkIGluIHRoZSBpbnRyb2R1Y3Rpb24gb2YgdGhlIGRyYWZ0IFJGQywgdGhlIHRpbWUgb2YgdGhl IGludHJvc3BlY3Rpb24NCj4+IGlzIGNyaXRpY2FsLg0KPiANCj4gV2h5IGlzIHRoaXMgdGltZSBj cml0aWNhbD8NCj4gDQo+PiBJbiBwYXJ0aWN1bGFyIHdoZW4gY29tYmluZWQgd2l0aCByZXZvY2F0 aW9uLCB0aGUgdGltZSBvZg0KPj4gaW50cm9zcGVjdGlvbiBhbmQgdGhlICdhY3RpdmUnIHN0YXR1 cyBjYW4gZGlmZmVyIGJldHdlZW4gdHdvIHN1YnNlcXVlbnQgY2FsbHMNCj4+IGZvciBpbnRyb3Nw ZWN0aW9uLg0KPiANCj4gVGhlIHN0YXR1cyBhdCB0b2tlbiBpbnRyb3NwZWN0aW9uIHJlcXVlc3Qg dGltZSBpcyBpbmRlZWQgY3JpdGljYWwuIFJGQyA3NjYyIGdpdmVzIGEgZ29vZCBpbmRpY2F0aW9u IGhvdyB0aGlzIHZhbHVlIHNob3VsZCBiZSBjYWxjdWxhdGVkLg0KPiANCj4g4oCc4oCmIGEgInRy dWUiDQo+ICAgICAgdmFsdWUgcmV0dXJuIGZvciB0aGUgImFjdGl2ZSIgcHJvcGVydHkgd2lsbCBn ZW5lcmFsbHkgaW5kaWNhdGUNCj4gICAgICB0aGF0IGEgZ2l2ZW4gdG9rZW4gaGFzIGJlZW4gaXNz dWVkIGJ5IHRoaXMgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsDQo+ICAgICAgaGFzIG5vdCBiZWVuIHJl dm9rZWQgYnkgdGhlIHJlc291cmNlIG93bmVyLCBhbmQgaXMgd2l0aGluIGl0cw0KPiAgICAgIGdp dmVuIHRpbWUgd2luZG93IG9mIHZhbGlkaXR5IChlLmcuLCBhZnRlciBpdHMgaXNzdWFuY2UgdGlt ZSBhbmQNCj4gICAgICBiZWZvcmUgaXRzIGV4cGlyYXRpb24gdGltZSkuIiANCj4gDQo+IFNvIGl0 IHJlcHJlc2VudHMgdGhlIHJlc3VsdHMgb2YgdGhlIGlzc3VlciBjaGVjaywgdGhlIHJldm9jYXRp b24gY2hlY2sgYW5kIHRoZSB2YWxpZGl0eSBjaGVjayBpbiBvbmUgYm9vbGVhbiB2YWx1ZS4gDQo+ IA0KPj4gDQo+PiBJZiB0aGUgZHJhZnQgUkZDIGp1c3QgcHJvZHVjZXMgYSBKV1QgcmVwcmVzZW50 YXRpb24gb2YgdGhlIGFjY2VzcyB0b2tlbiwNCj4+IGluY2x1ZGluZyAnYWN0aXZlJyB3b3VsZCBu b3QgbWFrZSBzZW5zZSBhcyB0aGUgSldUIHdpbGwgZXhwaXJlIHdpdGhvdXQNCj4+IHVwZGF0aW5n IGl0IHRvIGZhbHNlLiBMZWF2aW5nICdhY3RpdmUnIG91dCB3b3VsZCBtYWtlIGl0IGluY29tcGF0 aWJsZSB3aXRoDQo+PiBSRkM3NjYyIGludHJvc3BlY3Rpb24gcmVzcG9uc2VzLg0KPiANCj4g4oCc YWN0aXZl4oCdIGlzIG5vdCBwYXJ0IG9mIHRoZSBKV1QgcmVwcmVzZW50YXRpb24gSSByZWZlcnJl ZCB0by4gVGhlIEFTIG5lZWRzIHRvIGRldGVybWluZSB0aGUgYWN0aXZlIHZhbHVlIGZvciBldmVy eSB0b2tlbiBpbnRyb3NwZWN0aW9uIHJlcXVlc3QuIA0KPiANCj4gSWYgdGhlIFJTIHdvdWxkIGNv bnN1bWUgSldUcywgaXQgd291bGQgZGV0ZXJtaW5lIHRoZSDigJxhY3RpdmXigJ0gdmFsdWUgaXRz ZWxmIGJ5IGluc3BlY3RpbmcgdGhlIGlzcyBjbGFpbSBhbmQgY2hlY2sgYWdhaW5zdCBpdHMgQVMg d2hpdGVsaXN0LCBjaGVjayB0aGUgc2lnbmF0dXJlIGFuZCB0aGUgaWF0ICYgZXhwIHZhbHVlcy4g RGV0ZXJtaW5pbmcgdGhlIHJldm9jYXRpb24gc3RhdHVzIHdvdWxkIHJlcXVpcmUgYW4gaW5mb3Jt YXRpb24gZXhjaGFuZ2Ugd2l0aCB0aGUgQVMgb2Ygc29tZSBzb3J0LiANCj4gDQo+PiBTaW1pbGFy LCBub3QgaW5jbHVkaW5nIGEgdW5pcXVlICdqdGknIHBlciBpbnRyb3NwZWN0aW9uIHJlc3BvbnNl IHdvdWxkIG1ha2UNCj4+IHRoZSByZXNvdXJjZSBzZXJ2ZXIgdnVsbmVyYWJsZSB0byByZXBsYXkg YXR0YWNrcy4NCj4gDQo+IFRvIHRoZSBjb250cmFyeSwgaW5jbHVkaW5nIGEgZGlmZmVyZW50IOKA nGppdCIgd2l0aCBldmVyeSB0b2tlbiBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlIHdvdWxkIG1ha2Ug dGhlIFJTIHZ1bG5lcmFibGUgdG8gcmVwbGF5IG9mIG9uZSB0aW1lIGFjY2VzcyB0b2tlbiBzaW5j ZSBpdCByZW1vdmUgdGhlIHBvc3NpYmlsaXR5IGZvciB0aGUgUlMgdG8gaWRlbnRpdHkgYSBjZXJ0 YWluIGFjY2VzcyB0b2tlbi4gDQo+IA0KPj4gT3IgdGhlIHJlc291cmNlIHNlcnZlcg0KPj4gd291 bGQgbWlzdGFrZW5seSByZWZlciB0byBub24tdW5pcXVlIHRva2VucywgbWFraW5nIHRoZSByZXNw b25zZXMgdW5zdWl0YWJsZQ0KPj4gZm9yIGFjY291bnRhYmlsaXR5IGFuZCBhdWRpdCBwdXJwb3Nl cy4NCj4+IA0KPj4gDQo+PiBBcyB0byB3aHkgc29tZW9uZSB3b3VsZCB3YW50IHRvIGRpc3Rpbmd1 aXNoIGEgSldUIGFjY2VzcyB0b2tlbiBmcm9tIGFuDQo+PiBpbnRyb3NwZWN0aW9uIHJlc3BvbnNl OiBzZXZlcmFsIHVzZSBjYXNlcyBjb21lIHRvIG1pbmQuDQo+PiANCj4+IEZpcnN0IG9mIGFsbCwg ZXZlbiBpZiBvbmUgaXMgdXNpbmcgc3RhbmRhbG9uZSBpbnRlcnByZXRhYmxlIEpXVCBhY2Nlc3Mg dG9rZW5zLA0KPj4gb25lIG1heSB3YW50IHRvIGNvbWJpbmUgdGhhdCB3aXRoIHJldm9jYXRpb24g Y2hlY2tpbmcgdXNpbmcgaW50cm9zcGVjdGlvbi4gVGhlDQo+PiBpbnRlcnByZXRhdGlvbiBhbmQg bWVhbmluZyBvZiB0aGUgSldUIGFuZCB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZSB0aGFuIGRv DQo+PiBkaWZmZXIgYW5kIG1hdHRlci4NCj4gDQo+IEFzIEkgZGVzY3JpYmVkIGFib3ZlLCBJIGRv buKAmXQgc2VlIGFueSBkaWZmZXJlbmNlLiANCj4gDQo+PiANCj4+IEFub3RoZXIgdXNlIGNhc2Ug d291bGQgYmUgYSBtaXhlZCBlY29zeXN0ZW0gd2l0aCByZXNvdXJjZSBzZXJ2ZXJzIHJlbHlpbmcg b24NCj4+IGludHJvc3BlY3Rpb24gd2hpbGUgb3RoZXJzIGRvIHBhcnNlIEpXVCBhY2Nlc3MgdG9r ZW5zLiBBIHNpbmdsZSwgdW5pZm9ybQ0KPj4gaW1wbGVtZW50YXRpb24gZm9yIHRoZSBBUyB3b3Vs ZCB0aGFuIG1peCBib3RoIGFzIHdlbGwuDQo+IA0KPiBTZWUgYWJvdmUgLSBJIGRvbuKAmXQgc2Vl IGFueSBpc3N1ZS4gDQo+IA0KPj4gDQo+PiBBIGxhc3QgdXNlIGNhc2UgY291bGQgYmUgZXhjaGFu Z2luZyBhY2Nlc3MgdG9rZW5zIHdpdGggYSBzdWJzZXQgb2YgdGhlIGZ1bGwNCj4+IHNldCBvZiBh cHBsaWNhYmxlIHBhcmFtZXRlcnMsIHRvIHJlZHVjZSB0aGUgc2l6ZSBvZiBhY2Nlc3MgdG9rZW5z LiBBZGRpdGlvbmFsDQo+PiBpbmZvcm1hdGlvbiBjYW4gYmUgZXhjaGFuZ2VkIHZpYSBpbnRyb3Nw ZWN0aW9uLCByZXN1bHRpbmcgaW4gbWl4ZWQgSldUIGFjY2Vzcw0KPj4gdG9rZW5zIGFuZCBpbnRy b3NwZWN0aW9uIGFzIHdlbGwuDQo+IA0KPiBUaGF04oCZcyBhbGwgcG9zc2libGUgd2l0aGluIHRo ZSBjdXJyZW50IHRleHQuIA0KPiANCj4ga2luZCByZWdhcmRzLA0KPiBUb3JzdGVuIA0KPiANCj4+ IA0KPj4gS2luZCByZWdhcmRzLA0KPj4gUmVtY28gU2NoYWFyDQo+PiANCj4+IC0tLS0tT29yc3By b25rZWxpamsgYmVyaWNodC0tLS0tDQo+PiBWYW46IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0 ZW5AbG9kZGVyc3RlZHQubmV0PiANCj4+IFZlcnpvbmRlbjogemF0ZXJkYWcgMTcgYXVndXN0dXMg MjAxOSAxNDowMA0KPj4gQWFuOiBTY2hhYXIsIFIuTS4gKFJlbWNvKSAtIExvZ2l1cyA8cmVtY28u c2NoYWFyQGxvZ2l1cy5ubD4NCj4+IENDOiBvYXV0aEBpZXRmLm9yZw0KPj4gT25kZXJ3ZXJwOiBS ZTogW09BVVRILVdHXSBRdWVzdGlvbiByZWdhcmRpbmcgZHJhZnQtaWV0Zi1vYXV0aC1qd3QtaW50 cm9zcGVjdGlvbi1yZXNwb25zZS0wNQ0KPj4gDQo+PiBIaSBSZW1jbywNCj4+IA0KPj4+IE9uIDYu IEF1ZyAyMDE5LCBhdCAxNjowMSwgU2NoYWFyLCBSLk0uIChSZW1jbykgLSBMb2dpdXMgPHJlbWNv LnNjaGFhckBsb2dpdXMubmw+IHdyb3RlOg0KPj4+IA0KPj4+IEhlbGxvLA0KPj4gDQo+PiBbLi4u XQ0KPj4gUkZDIDc1MTkgYW5kIFJGQyA3NjYyIOKAnGp1c3TigJ0gZGVmaW5lIGRpZmZlcmVudCBy ZXByZXNlbnRhdGlvbnMgZm9yIHRva2VuIGRhdGEuIEluIFJGQyA3NTE5IHRoZSBkYXRhIGlzIGNh cnJpZWQgaW4gdGhlIHRva2VuIGl0c2VsZiAod2hpY2ggYWxzbyBtZWFucyB0aGUgZm9ybWF0IG9m IHRoZSB0b2tlbiBpcyB3ZWxsLWRlZmluZWQgYW5kIGtub3cgdG8gdGhlIFJTKSB3aGVyZWFzIFJG QyA3NjYyIGRlZmluZXMgYSB3YXkgdG8gaW5zcGVjdCB0b2tlbnMgdmlhIGFuIEFQSSBwcm92aWRl ZCBieSB0aGUgQVMuIFRoZSBsYXR0ZXIgaXMgdHlwaWNhbGx5IHVzZWQgaW4gY29uanVuY3Rpb24g d2l0aCBvcGFxdWUgdG9rZW5zLCBpLmUuIHRoZSBSUyBkb2VzIG5vdCBoYXZlIGEgY2x1ZSBob3cg dG8gcGFyc2UgYW5kIGludGVycHJldCB0aGUgdG9rZW4uIFRoZSB0b2tlbiBtaWdodCBqdXN0IGJl IGEgaGFuZGxlIHRvIGEgZGF0YWJhc2UgZW50cnkgYXQgdGhlIEFTIGluIHRoaXMgY2FzZS4gDQo+ PiANCj4+IFRoaXMgYWxzbyBtZWFucyBhIEpXVCAoUkZDIDc2NjIpIGFuZCB0aGUgSW50cm9zcGVj dGlvbiBSZXNwb25zZSBhcmUgY29uY2VwdHVhbGx5IHRoZSBzYW1lIGZyb20gYSBSU3MgcGVyc3Bl Y3RpdmUuDQo+PiANCj4+IFsuLi5dDQo+PiANCj4+PiBUaGUg4oCYanRp4oCZIHBhcmFtZXRlciBo b3dldmVyIHdpbGwgYWx3YXlzIGJlIGFtYmlndW91cy4gQXMgaXQgaXMgYW4gaWRlbnRpZmllciwg aXQgc2hvdWxkIGRpZmZlciBmb3IgdGhlIGludHJvc3BlY3RlZCB0b2tlbiBhbmQgdGhlIGludHJv c3BlY3Rpb24gcmVzcG9uc2UgYnkgZGVmaW5pdGlvbi4gSGVuY2UgdGhlIHNlbWFudGljcyBvZiDi gJhqdGnigJkgaW4gYSBKV1QgaW50cm9zcGVjdGlvbiByZXNwb25zZSBpcyB1bmNsZWFyLiBUaGUg c2FtZSBjYW4gYXBwbHkgdG8gdGhlIOKAmGlhdOKAmSwg4oCYbmJm4oCZIGFuZCDigJhleHDigJkg Y2xhaW1zIGluIGEgSldUIGludHJvc3BlY3Rpb24gcmVzcG9uc2UuDQo+PiANCj4+IEkgZG9u4oCZ dCB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIHlvdSBhcmUgbWFraW5nLiBBbGwgYmVmb3JlIG1l bnRpb25lZCBjbGFpbXMgYXJlIHJlbGF0ZWQgdG8gdGhlIChhYnN0cmFjdCkgYWNjZXNzIHRva2Vu LiBZb3UgbWF5IHRoaW5rIG9mIHRoZSBJbnRyb3NwZWN0aW9uIFJlc3BvbnNlIGFzIF90aGVfIEpX VCByZXByZXNlbnRhdGlvbiBvZiB0aGUgYWNjZXNzIHRva2VuIHByb2R1Y2VkIGJ5IHRoZSBBUyBm b3IgdGhlIFJTLg0KPj4gDQo+Pj4gDQo+Pj4gQ2FuIHNvbWVvbmUgY2xhcmlmeSB0aGUgc2VtYW50 aWNzIG9mIGNsYWltcyBpbiBhbiBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlIEpXVCB0aGF0IGFyZSBk ZWZpbmVkIGluIGJvdGggUkZDNzY2MiBhbmQgUkZDNzUxOT8NCj4+PiANCj4+PiBGdXJ0aGVybW9y ZSwgdGhlIGludHJvc3BlY3Rpb24gcmVzcG9uc2Ugc2hvdWxkIHVzZSB0aGUg4oCYaXNz4oCZIGFu ZCDigJhhdWTigJkgY2xhaW1zIHRvIGF2b2lkIGNyb3NzLUpXVCBjb25mdXNpb24gKHNlY3Rpb24g Ni4xKS4gVGhlIOKAmGlzc+KAmSBhbmQg4oCYYXVk4oCZIG9mIGFuIGludHJvc3BlY3RlZCB0b2tl biB3aWxsIHR5cGljYWxseSBiZSB0aGUgc2FtZSBhcyB0aG9zZSBvZiB0aGUgaW50cm9zcGVjdGlv biByZXNwb25zZS4gSGVuY2UgYSBKV1QgYWNjZXNzIHRva2VuIGNhbm5vdCBiZSBkaXN0aW5ndWlz aGVkIGZyb20gYW4gaW50cm9zcGVjdGlvbiByZXNwb25zZSB1c2luZyDigJhpc3PigJkgYW5kIOKA mGF1ZOKAmSBhcyBzdWdnZXN0ZWQgaW4gdGhlIGRyYWZ0Li4NCj4+PiANCj4+PiBJbnRyb3NwZWN0 aW9uIHJlZmVycyB0byBKV1QgYmVzdC1jdXJyZW50LXByYWN0aWNlLiBUaGUgZHJhZnQgQkNQIHJl Y29tbWVuZHMgdXNpbmcgZXhwbGljaXQgdHlwaW5nIG9mIEpXVHMsIGhvd2V2ZXIgdGhlIGRyYWZ0 IEpXVCByZXNwb25zZSBmb3IgaW50cm9zcGVjdGlvbiBkb2VzIG5vdCBhcHBseSB0aGlzIHJlY29t bWVuZGF0aW9uIGFuZCB1c2VzIHRoZSBnZW5lcmljIOKAmGFwcGxpY2F0aW9uL2p3dOKAmSBpbnN0 ZWFkLi4uIFRoZSBCQ1AgaGFzIG90aGVyIHJlY29tbWVuZGF0aW9ucyBpbiBzZWN0aW9uIDMuMTIs IGJ1dCB0aGVzZSBtYXkgYmUgaW5zdWZmaWNpZW50IHRvIGRpc3Rpbmd1aXNoIGEgSldUIGFjY2Vz cyB0b2tlbiBmcm9tIGEgSldUIGludHJvc3BlY3Rpb24gcmVzcG9uc2UuDQo+PiANCj4+IEdvb2Qg cG9pbnQuIFRoZSByZWFzb24gd2h5IHRoZSBCQ1AgcmVjb21tZW5kcyBleHBsaWNpdCB0eXBpbmcg aXMgdG8gcHJldmVudCByZXBsYXkgaW4gb3RoZXIgY29udGV4dHMuIEluIHRoZSBlbmQgdHlwaW5n IGlzIGEgY29tcGVsbGluZyBjb25jZXB0IHVuZm9ydHVuYXRlbHkgbm90IGJyb2FkbHkgdXNlZCBp biB0aGUgd2lsZC4NCj4+IA0KPj4gU28gdGhlIEpXVCBJbnRyb3NwZWN0aW9uIFJlc3BvbnNlIGRy YWZ0IGNvcGVzIHdpdGggdGhhdCBhdHRhY2sgYW5nbGUgYnkgbWFraW5nIGlzcyBhbmQgYXVkIG1h bmRhdG9yeS4gDQo+PiANCj4+IA0KPj4+IA0KPj4+IEhvdyB3b3VsZCBwZW9wbGUgc3VnZ2VzdCB0 byBiZXN0IGRpc3Rpbmd1aXNoIGEgSldUIChhY2Nlc3MpIHRva2VuIGZyb20gYSBKV1QgaW50cm9z cGVjdGlvbiByZXNwb25zZT8NCj4+IA0KPj4gV2h5IHNob3VsZCB5b3U/IE9uZSByZWFzb24gd2h5 IHdlIGV4dGVuZGVkIHRoZSBJbnRyb3NwZWN0aW9uIFJlc3BvbnNlIHdhcyB0byBlbGltaW5hdGUg dGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBKV1RzIGRpcmVjdGx5IHVzZWQgYXMgYWNjZXNzIHRva2Vu cyBhbmQgSW50cm9zcGVjdGlvbiBSZXNwb25zZXMuDQo+PiANCj4+IGJlc3QgcmVnYXJkcywNCj4+ IFRvcnN0ZW4uIA0KPj4gDQo+PiANCj4+IERpdCBiZXJpY2h0IGthbiBpbmZvcm1hdGllIGJldmF0 dGVuIGRpZSBuaWV0IHZvb3IgdSBpcyBiZXN0ZW1kLiBJbmRpZW4gdSBuaWV0IGRlIGdlYWRyZXNz ZWVyZGUgYmVudCBvZiBkaXQgYmVyaWNodCBhYnVzaWV2ZWxpamsgYWFuIHUgaXMgdG9lZ2V6b25k ZW4sIHdvcmR0IHUgdmVyem9jaHQgZGF0IGFhbiBkZSBhZnplbmRlciB0ZSBtZWxkZW4gZW4gaGV0 IGJlcmljaHQgdGUgdmVyd2lqZGVyZW4uIERlIFN0YWF0IGFhbnZhYXJkdCBnZWVuIGFhbnNwcmFr ZWxpamtoZWlkIHZvb3Igc2NoYWRlLCB2YW4gd2Vsa2UgYWFyZCBvb2ssIGRpZSB2ZXJiYW5kIGhv dWR0IG1ldCByaXNpY28ncyB2ZXJib25kZW4gYWFuIGhldCBlbGVrdHJvbmlzY2ggdmVyemVuZGVu IHZhbiBiZXJpY2h0ZW4uDQo+PiBUaGlzIG1lc3NhZ2UgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24g dGhhdCBpcyBub3QgaW50ZW5kZWQgZm9yIHlvdS4gSWYgeW91IGFyZSBub3QgdGhlIGFkZHJlc3Nl ZSBvciBpZiB0aGlzIG1lc3NhZ2Ugd2FzIHNlbnQgdG8geW91IGJ5IG1pc3Rha2UsIHlvdSBhcmUg cmVxdWVzdGVkIHRvIGluZm9ybSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UuIFRo ZSBTdGF0ZSBhY2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgZGFtYWdlIG9mIGFueSBraW5kIHJlc3Vs dGluZyBmcm9tIHRoZSByaXNrcyBpbmhlcmVudCBpbiB0aGUgZWxlY3Ryb25pYyB0cmFuc21pc3Np b24gb2YgbWVzc2FnZXMuDQo+IA0KDQo= From nobody Mon Sep 30 02:53:21 2019 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 6B7A112013F for ; Mon, 30 Sep 2019 02:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk 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 HMGylUVu3ywC for ; Mon, 30 Sep 2019 02:53:09 -0700 (PDT) Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (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 E50B6120802 for ; Mon, 30 Sep 2019 02:53:08 -0700 (PDT) Received: by mail-oi1-x242.google.com with SMTP id m16so10562223oic.5 for ; Mon, 30 Sep 2019 02:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xrQKOKfJWjSrkdl9iQsZ/CMSpjk5YpqEK02cW12tJxQ=; b=UufTubWgudMWNd5W7fmj7y8VJJEBkZsltLlsVhvOhaurWzAkoLZszML/NumKTKzUPE Lxxcim7+JYhZBH/dY3KPkCVrr22tgzGTHFG2pf0va8IXpDhbXwtfenIYu5LD4G3AxDiJ 5aZX3O90LEGYrRzBYID/Q8mjmR1Cwc1ae8B+U= 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=xrQKOKfJWjSrkdl9iQsZ/CMSpjk5YpqEK02cW12tJxQ=; b=kG0dVS9BcTKif9OmL4GxVtN+gnkWkwgOCb3ce3fnTDhPXIm7a10UQacgmTGsAk4aOd qa2TYUS/D6N+KC42M2ugy9GlPE5H/MM2IE6gUxS9kJsKCMc1Uly88W4I/gs8ZFR760P5 UZY78Gm+siHE27cEKRFKa08/bv+UoOqC7ycg3Nd1c0Er6r0j4ZFm+Afe9lURDvy42+1d 5fhTiunFgCFxvtYQMixvmGEx6yRFeIzX7TaOzj5lrsNz0OifN9moK3ce7iXkr+bcIBu+ O7mFAioq+jooCSbQWbHn3DL8k5k+B0+NWFRO/OY7B9dW/oC2zPJaYjNw2H8zgRiv/YZ5 ar/w== X-Gm-Message-State: APjAAAU4TzNd2vQh52feCGIDLf01nqHJyhHvo4PbXMWJd9ZAgXnIBPmB Chj+mzjJTsX6xaI2BQW0GH/CKVUFCEj9jy99G1QhAw== X-Google-Smtp-Source: APXvYqw2n9+CwmCHg417LrsCHOf7oOlsRyIlN4oJq6qQ1YqrAiYgMez5EHEgdq4uRRKzZKKsgSClIGTbdS+l6xnR4oI= X-Received: by 2002:aca:c7d8:: with SMTP id x207mr17830799oif.99.1569837188179; Mon, 30 Sep 2019 02:53:08 -0700 (PDT) MIME-Version: 1.0 References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> In-Reply-To: From: Dave Tonge Date: Mon, 30 Sep 2019 11:52:56 +0200 Message-ID: To: Dick Hardt Cc: Justin Richer , oauth Content-Type: multipart/alternative; boundary="000000000000f510040593c233d6" Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt 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, 30 Sep 2019 09:53:11 -0000 --000000000000f510040593c233d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So although for this spec, request_uri is just an opaque string, it is defined more generally in https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.2 as an: * Absolute URI from which the Request Object (Section 2.1) can be obtained* And in section 5.2 as: > *The "request_uri" value MUST be either URN as defined in* > * RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230* > * [RFC7230] . The "request_uri" value MUST be reachable by the** > Authorization Server.* So this is why in the spec we have example of a URN and we have an ongoing discussion as to whether we should have a standard urn namespace that we recommend implementers use. In the interest of keeping the specs in sync I think it makes sense to keep it a URN for this spec, but with more of an explanation as to why? Dave On Fri, 27 Sep 2019 at 19:22, Dick Hardt wrote: > If I understand the proposal correctly, the request URI is opaque to the > client. Correct? > > If so, why not just treat it as an opaque string? > > If I were implementing the protocol, I would have the blob be a signed > token so that I could verify the integrity before making a database call. > It much easier to throw compute at a DDOS attack to verify a signature, > than DB capacity. > > =E1=90=A7 > > On Thu, Sep 26, 2019 at 2:24 PM Justin Richer wrote: > >> Yes, the request object is JWT-based, but the request URI is not. In >> other words, you can post a JWT but what you get back is a URI, not the = JWT >> itself. The request URI was always meant to be a reference, and origina= lly >> it was explicitly a reference to a signed request object. >> >> =E2=80=94 Justin >> >> On Sep 26, 2019, at 10:03 AM, Aaron Parecki wrote: >> >> The URI is intended to be a reference not a value.. If the client could >> send a JWT it would just send a request object instead of a request URI = in >> the first place. So the intent is that it=E2=80=99s random, and maybe we= should >> just say that explicitly. >> >> >> I thought this language was explicitly to allow the use of structured >> values for the request_uri? From the introduction: >> >> but it also allows clients requiring an even >> higher security level, especially cryptographically confirmed non- >> repudiation, to explicitly adopt JWT-based request objects. >> >> >> ---- >> Aaron Parecki >> aaronparecki.com >> >> On Thu, Sep 26, 2019 at 6:49 PM Justin Richer wrote: >> >> >> Aaron, some comments inline. >> >> =E2=80=94 Justin >> >> On Sep 26, 2019, at 8:30 AM, Aaron Parecki wrote: >> >> Hi Torsten, >> >> I'm very glad to see this draft, I think it's definitely needed in >> this space. Here are some of my thoughts on the draft. >> >> "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" >> >> >> Is it acceptable for the AS to return just an opaque string, rather >> than something prefixed with "uri:*"? I don't think anyone would be >> confused about copypasting the exact string from the "request_uri" >> response into the "request_uri" parameter even if it didn't start with >> "urn:". If, for whatever reason, it is required that this value is >> actually a URI, is there some expected namespace to use other than >> "example"? I worry that if all the examples in the spec are just >> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up >> using the text "example" because they don't understand why it's there, >> and then it serves no purpose really.=E2=80=99 >> >> >> This field must be a URI, as per JAR: >> >> request_uri The absolute URI as defined by RFC3986 [RFC3986] that >> points to the Request Object (Section 2.1) that holds >> authorization request parameters stated in section 4 of OAuth 2.0 >> [RFC6749]. >> >> Somewhat awkwardly, the JAR spec currently states that the AS has to do >> an HTTP GET on the request URI, so that will need to be fixed in JAR bef= ore >> it goes forward. I don=E2=80=99t think that was always the case though, = and I=E2=80=99m not >> sure how that changed. >> >> As for the namespace, =E2=80=9Cexample=E2=80=9D is ok for an example URN= . The problem >> with URNs is that nobody really understands how to do domain-safe fully >> compliant URNs. So perhaps we should instead use =E2=80=9Curn:fdc:exampl= e.com:=E2=80=A6.=E2=80=9D >> Instead (as per https://tools.ietf.org/html/rfc4198). >> >> >> The pushed authorization request endpoint shall be a RESTful API >> >> >> I would drop the term RESTful and just say "HTTP API", as this >> description is arguably RESTful at best. >> >> Depending on client type and authentication method, the request might >> also include the "client_id" parameter. >> >> >> I assume this is hinting at the difference between public clients >> sending only the "client_id" parameter and confidential clients >> sending only the HTTP Basic Authorization header which includes both >> the client ID and secret? It would probably be helpful to call out >> these two common examples if I am understanding this correctly, >> otherwise it seems pretty vague. >> >> >> Not quite, those differences are for the token endpoint, and this is >> capturing things from the authorization endpoint. I don=E2=80=99t quite = understand >> the differentiation listed here either, though. >> >> >> The "request_uri" value MUST be generated using a cryptographically >> strong pseudorandom algorithm >> >> >> I assume this includes the use of a random number inside of a JWT, in >> case the AS wants to use JWTs as the "request_uri" parameter"? If so, >> it's probably worth spelling that out as it kind of reads like it has >> to be literally a random string at first glance. >> >> >> The URI is intended to be a reference not a value. If the client could >> send a JWT it would just send a request object instead of a request URI = in >> the first place. So the intent is that it=E2=80=99s random, and maybe we= should >> just say that explicitly. >> >> >> That's all for now, thanks! >> >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> On Sat, Sep 21, 2019 at 1:02 PM Torsten Lodderstedt >> wrote: >> >> >> Hi all, >> >> I just published a new draft that Brian Campbell, Dave Tonge, Filip >> Skokan, Nat Sakimura and I wrote. >> >> https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 >> >> It proposes a new endpoint, called "pushed authorization request >> endpoint=E2=80=9D, that allows the client to push the Authorization Requ= est payload >> with the AS on a backchannel connection instead of a front channel >> interaction. The AS provides the client with a request URI (according to >> draft-ietf-oauth-jwsreq) that the client uses in a subsequent authorizat= ion >> requests to refer to the pushed request data. >> >> We believe this simple mechanism will significantly increase OAuth >> security and robustness since any application can use it by just sending >> the parameters in the same encoding as used at the authorisation endpoin= t >> over a HTTPS-protected and (for confidential clients) mutually >> authenticated connection to the AS. It can also be used to push signed a= nd >> encrypted request objects to the AS, i.e. it provides an interoperable w= ay >> to use request objects managed at the AS for use cases requiring an even >> higher security level. >> >> We look forward to getting your feedback. >> >> kind regards, >> Torsten. >> >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-lodderstedt-oauth-par-00.txt >> Date: 21. September 2019 at 12:47:28 CEST >> To: "Nat Sakimura" , "Brian Campbell" < >> bcampbell@pingidentity.com>, "Torsten Lodderstedt" < >> torsten@lodderstedt.net>, "Dave Tonge" , "Filip Skokan" = < >> panva.ip@gmail.com> >> >> >> A new version of I-D, draft-lodderstedt-oauth-par-00.txt >> has been successfully submitted by Torsten Lodderstedt and posted to the >> IETF repository. >> >> Name: draft-lodderstedt-oauth-par >> Revision: 00 >> Title: OAuth 2.0 Pushed Authorization Requests >> Document date: 2019-09-21 >> Group: Individual Submission >> Pages: 12 >> URL: >> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-par-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ >> Htmlized: >> https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 >> >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par >> >> >> Abstract: >> This document defines the pushed authorization request endpoint, >> which allows clients to push the payload of an OAuth 2.0 >> authorization request to the authorization server via a direct >> request and provides them with a request URI that is used as >> reference to the data in a subsequent authorization request. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- --000000000000f510040593c233d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So although for this spec, request_uri is= just an opaque string, it is defined more generally in=C2=A0https://to= ols.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.2 as an:
=C2=A0Absolute= URI from which the Request Object (Section 2.1) can be obtained

And in section 5.2 as:

The "request_uri" value MUST be e= ither URN as defined in
=C2=A0 =C2=A0RFC8141 [RFC8141] or "h= ttps" URI, as defined in 2.7.2 of RFC7230
=C2=A0 =C2=A0[RFC7= 230] .=C2=A0 The "request_uri" value MUST be reachable by the
= =C2=A0 =C2=A0Authorization Server.

So this= is why in the spec we have example of a URN and we have an ongoing discuss= ion as to whether we should have a standard urn namespace that we recommend= implementers use.

In the interest of keeping the specs in s= ync I think it makes sense to keep it a URN for this spec, but with more of= an explanation as to why?

Dave

On Fri, 27 Sep 2019 at = 19:22, Dick Hardt <dick.hardt@gm= ail.com> wrote:
If I understand the proposal correctly, the request= URI is opaque to the client. Correct?

If so, why not ju= st treat it as an opaque string?

If I were impleme= nting the protocol, I would have the blob be a signed token so that I could= verify the integrity before making a database call. It much easier to thro= w compute at a DDOS attack to verify a signature, than DB capacity.

= 3D""= =E1=90=A7

On Thu, Sep 26, 2019 at = 2:24 PM Justin Richer <jricher@mit.edu> wrote:
Yes, the request object is JWT-based, but the request URI is not. In other = words, you can post a JWT but what you get back is a URI, not the JWT itsel= f.=C2=A0 The request URI was always meant to be a reference, and originally= it was explicitly a reference to a signed request object.=C2=A0

=E2=80=94 Justin

On Sep 26, 2019, at 10:03 AM, Aaron Parecki <aaron@parecki.com> wrote:

The URI is intended to be a reference not a value= .. If the client could send a JWT it would just send a request object inste= ad of a request URI in the first place. So the intent is that it=E2=80=99s = random, and maybe we should just say that explicitly.

I thought this language was explicitly to allow the use of structured
values for the request_uri? From the introduction:

but it also allows clients requiring an even
higher security level, especially cryptographically confirmed non-
repudiation, to explicitly adopt JWT-based request objects.

----
Aaron Parecki
aaronparecki.com<= br>
On Thu, Sep 26, 2019 at 6:49 PM Justin Richer <jricher@mit.edu> wrote:

Aaron, some comments inline.

=E2=80=94 Justin

On Sep 26, 2019, at 8:30 AM, Aaron Parecki <aaron@parecki.com> wrote:

Hi Torsten,

I'm very glad to see this draft, I think it's definitely needed in<= br> this space. Here are some of my thoughts on the draft.

"request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2"= ;


Is it acceptable for the AS to return just an opaque string, rather
than something prefixed with "uri:*"? I don't think anyone wo= uld be
confused about copypasting the exact string from the "request_uri"= ;
response into the "request_uri" parameter even if it didn't s= tart with
"urn:". If, for whatever reason, it is required that this value i= s
actually a URI, is there some expected namespace to use other than
"example"? I worry that if all the examples in the spec are just<= br> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will en= d up
using the text "example" because they don't understand why it= 's there,
and then it serves no purpose really.=E2=80=99


This field must be a URI, as per JAR:

=C2=A0=C2=A0request_uri =C2=A0The absolute URI as defined by RFC3986 [RFC39= 86] that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0points to the Request Object (Section 2.1) th= at holds
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0authorization request parameters stated in se= ction 4 of OAuth 2.0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[RFC6749].

Somewhat awkwardly, the JAR spec currently states that the AS has to do an = HTTP GET on the request URI, so that will need to be fixed in JAR before it= goes forward. I don=E2=80=99t think that was always the case though, and I= =E2=80=99m not sure how that changed.

As for the namespace, =E2=80=9Cexample=E2=80=9D is ok for an example URN. T= he problem with URNs is that nobody really understands how to do domain-saf= e fully compliant URNs. So perhaps we should instead use =E2=80=9Curn:fdc:e= xample.com:=E2=80=A6.=E2=80=9D Instead (as per https://tools.ietf.org/html/rfc4198).


The pushed authorization request endpoint shall be a RESTful API


I would drop the term RESTful and just say "HTTP API", as this description is arguably RESTful at best.

Depending on client type and authentication method, the request might
also include the "client_id" parameter.


I assume this is hinting at the difference between public clients
sending only the "client_id" parameter and confidential clients sending only the HTTP Basic Authorization header which includes both
the client ID and secret? It would probably be helpful to call out
these two common examples if I am understanding this correctly,
otherwise it seems pretty vague.


Not quite, those differences are for the token endpoint, and this is captur= ing things from the authorization endpoint. I don=E2=80=99t quite understan= d the differentiation listed here either, though.


The "request_uri" value MUST be generated using a cryptographical= ly
strong pseudorandom algorithm


I assume this includes the use of a random number inside of a JWT, in
case the AS wants to use JWTs as the "request_uri" parameter"= ;? If so,
it's probably worth spelling that out as it kind of reads like it has to be literally a random string at first glance.


The URI is intended to be a reference not a value. If the client could send= a JWT it would just send a request object instead of a request URI in the = first place. So the intent is that it=E2=80=99s random, and maybe we should= just say that explicitly.


That's all for now, thanks!

----
Aaron Parecki
aaronparecki.com<= br> @aaronpk

On Sat, Sep 21, 2019 at 1:02 PM Torsten Lodderstedt
<torsten@lo= dderstedt.net> wrote:


Hi all,

I just published a new draft that Brian Campbell, Dave Tonge, Filip Skokan,= Nat Sakimura and I wrote.

https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00

It proposes a new endpoint, called "pushed authorization request endpo= int=E2=80=9D, that allows the client to push the Authorization Request payl= oad with the AS on a backchannel connection instead of a front channel inte= raction. The AS provides the client with a request URI (according to draft-ietf-oauth-jwsreq) that the client uses in a subse= quent authorization requests to refer to the pushed request data.

We believe this simple mechanism will significantly increase OAuth security= and robustness since any application can use it by just sending the parame= ters in the same encoding as used at the authorisation endpoint over a HTTP= S-protected and (for confidential clients) mutually authenticated connection to the AS. It can also be used = to push signed and encrypted request objects to the AS, i.e. it provides an= interoperable way to use request objects managed at the AS for use cases r= equiring an even higher security level.

We look forward to getting your feedback.

kind regards,
Torsten.

Begin forwarded message:

From: interne= t-drafts@ietf.org
Subject: New Version Notification for draft-lodderstedt-oauth-par-00.txt Date: 21. September 2019 at 12:47:28 CEST
To: "Nat Sakimura" <nat@sakimura.org>, "Brian Campbell" <bcampbell@pingide= ntity.com>, "Torsten Lodderstedt" <torsten@lodderstedt.net>, &= quot;Dave Tonge" <dave@tonge.org>, "Filip Skokan" <panva.ip@gmail.com>


A new version of I-D, draft-lodderstedt-oauth-par-00.txt
has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository.

Name: draft-lodderstedt-oauth-par
Revision: 00
Title: OAuth 2.0 Pushed Authorization Requests
Document date: 2019-09-21
Group: Individual Submission
Pages: 12
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-lodderste= dt-oauth-par-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht= tps://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.= ietf.org/html/draft-lodderstedt-oauth-par-00
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://= datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par


Abstract:
This document defines the pushed authorization request endpoint,
which allows clients to push the payload of an OAuth 2.0
authorization request to the authorization server via a direct
request and provides them with a request URI that is used as
reference to the data in a subsequent authorization request.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--

=
--000000000000f510040593c233d6-- From nobody Mon Sep 30 07:52:34 2019 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 9A6E712008B for ; Mon, 30 Sep 2019 07:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 S3Hz6OvrmkcK for ; Mon, 30 Sep 2019 07:52:29 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 D4A94120817 for ; Mon, 30 Sep 2019 07:52:29 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id v2so38943239iob.10 for ; Mon, 30 Sep 2019 07:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2M8Y595LWiyDahuRr27uOhnCfELV7fqWFTwu6CCt7vI=; b=SRSnHo+y5rC1ZALQLGkv1Cb8OcrfcSYl7puICgxHSL+/9Cb4fU5kvHHvn4umG/Uld9 BTHZdSzq3LT2Mca4rBlab9gh/57haYYal2ISknuK+BV+5ivWeL7rxztgOwvKmru26kYA 1yj/RO8aCXEYMX+wG0JY+WAWIue2de/FkNGV4= 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=2M8Y595LWiyDahuRr27uOhnCfELV7fqWFTwu6CCt7vI=; b=tY2ltjP9s3YeBZa+kqSyRQa7wLuvK+IWUlmdaUUMWrYEuVCxz/kyQJDXAKpJrIT5Tk YeQkP4XXTo5Ip1HUaNmwg0Ns84R9sERk3XIHFH3oJPaB41XHSn9mHumXA298luUSo+sk DoJXoDzlrA5FXUdjlrxLQOQOQr8nx3W9PaEGM5jteoomGj5d1fkzfXR7ptFFWLRkq+QT /kIGcZd1q5HbZNq4LxrzGV3A7JZsRVdcghSP56G1n5a5MVGJKaZHOJkEOFMKDz4Y6H9g xOjgHG5v5a3Z3kmnrkSmJDtRz3IJXtMRfnCJ02YD8pNa+ZtphQemfvbnKOxBAqOGOtIA Fhow== X-Gm-Message-State: APjAAAVlovqr43E8Sgha3/+5Ipy1nCzCavLgQYACBL0fH/0SeYHpoe5N lgBXZrpaCTB8v3OjCTBh6eNfhcX4dhjNvE8914EhVMwkwAu6p64qFAhBBiEUl/t+JjIhbwcSbQV czSqPMScLZQEk+g== X-Google-Smtp-Source: APXvYqzjwfq6C39PofQM1M624tnM0lYaxJSVCGZYQHdOFb8L+VJfrAdNAZBAgjqOIIdXCj+UG3kuVyvh3/C1wYUqmJY= X-Received: by 2002:a92:d1c5:: with SMTP id u5mr20821118ilg.201.1569855149018; Mon, 30 Sep 2019 07:52:29 -0700 (PDT) MIME-Version: 1.0 References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> In-Reply-To: From: Brian Campbell Date: Mon, 30 Sep 2019 08:52:02 -0600 Message-ID: To: Aaron Parecki Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="00000000000081a71b0593c6621e" Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-par-00.txt 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, 30 Sep 2019 14:52:32 -0000 --00000000000081a71b0593c6621e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki wrote: > > The pushed authorization request endpoint shall be a RESTful API > > I would drop the term RESTful and just say "HTTP API", as this > description is arguably RESTful at best. > +1 --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000081a71b0593c6621e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 26, 2019 at 9:30 AM Aaron= Parecki <aaron@parecki.com>= wrote:
> The pushed authorization request endpoint shall be a RESTful API

I would drop the term RESTful and just say "HTTP API", as this description is arguably RESTful at best.

+1


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000081a71b0593c6621e-- From nobody Mon Sep 30 08:22:04 2019 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 25985120816 for ; Mon, 30 Sep 2019 08:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 bLs0jmJr664q for ; Mon, 30 Sep 2019 08:21:59 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 9973F120110 for ; Mon, 30 Sep 2019 08:21:59 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id q10so39419516iop.2 for ; Mon, 30 Sep 2019 08:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AmcCPuCOMlILISQtm6GagePq3NzmUX3Ey8Zm9g/jgzw=; b=HIoZaBKQENKyLgUdq0KADnhYSAqsn2lWrDV3XJsjsfvTfz5h2nuVh4eO5U1FJ9hwLg WvReAWpiW2e/bj43k8Rf32znhU/vYiHKw4MSj78rE5MKc3OXqy/OUCiC2EcSqzey63WN Ql/TbyHfWL5tWGeznAWbAhbkn00FBHsJ5v//U= 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=AmcCPuCOMlILISQtm6GagePq3NzmUX3Ey8Zm9g/jgzw=; b=trdvW4mJYn9ciERwUsoC49a7cUASwVAUeu64P4hcHiLlQ7v87NYs+Nn65nzMHMs+PG kTKnIrra+Pq4j+YOj4wemrOI3bGTlidyLu5Jfw9vxEe1+n0XOD7BURPyFhaRO23/Eg9z Vmqrv6GC9/OMcs0q/sJsoSCC+AXxMNj+qXXq5wIK0OwKyBXotjHKGaJ4lVnMdOTwTs35 zNM5uc0zVYcagjFBh3dud5I6RkFH4lz1bdrNC7H4DGROJ0lkSnLPhT9GylGK4heqsEVb NCl9arPvsJxCONXHF9e09A/6Hq/Owz8kLzHDn1RF38rarhdhwDOtdn79m6ysMNUiuetO nYKA== X-Gm-Message-State: APjAAAXQJ4idaYeyXJpiwhG9KFXE37PpWVpGcSLKR3e1mIvnT71iDbyR GLypHBpqTUwqMOsJLyyDP0oOw42vxunjl5LQR4nktQzINwCTTCcikmcl9lm4N3tBFR01b12RpYx cndGsrvwEPrXKHw== X-Google-Smtp-Source: APXvYqzWNiQKTw7gJhF2yts2228AFgYJ90KkJbvCNqKbYVN10ZDqqzKRqZTgBvUOiFOZcSmwYiB2Hh2RtOWzGvMUekE= X-Received: by 2002:a92:9912:: with SMTP id p18mr22059262ili.78.1569856918607; Mon, 30 Sep 2019 08:21:58 -0700 (PDT) MIME-Version: 1.0 References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> In-Reply-To: From: Brian Campbell Date: Mon, 30 Sep 2019 09:21:32 -0600 Message-ID: To: Aaron Parecki Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="000000000000fb72e60593c6cbf4" Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-par-00.txt 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, 30 Sep 2019 15:22:02 -0000 --000000000000fb72e60593c6cbf4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki wrote: > > Depending on client type and authentication method, the request might > > also include the "client_id" parameter. > > I assume this is hinting at the difference between public clients > sending only the "client_id" parameter and confidential clients > sending only the HTTP Basic Authorization header which includes both > the client ID and secret? It would probably be helpful to call out > these two common examples if I am understanding this correctly, > otherwise it seems pretty vague. > What this is trying to convey is that because client authentication at this Pushed Authorization Request Endpoint happens the same way as at the token endpoint (and other endpoints called directly by the client) the client_id parameter will sometimes be present but not necessarily as some types of client auth use the client_id parameter (none, client_secret_post, tls_client_auth, self_signed_tls_client_auth) and some don't (client_secret_basic, client_secret_jwt, private_key_jwt). Although the draft does later say "The AS MUST validate the request the same way as at the authorization endpoint" which I think could reasonably be interpreted as requiring client_id. e.g., https://tools.ietf.org/html/rfc6749?#section-4.1.1 & https://tools.ietf.org/html/rfc6749?#section-4.2.1 So perhaps the sentence in question should be removed and have client_id be a required parameter at the PAR endpoint. --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000fb72e60593c6cbf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 26, 2019 at 9:30 AM Aaron= Parecki <aaron@parecki.com>= wrote:
> Depending on client type and authentication method, the request might<= br> >=C2=A0 =C2=A0also include the "client_id" parameter.

I assume this is hinting at the difference between public clients
sending only the "client_id" parameter and confidential clients sending only the HTTP Basic Authorization header which includes both
the client ID and secret? It would probably be helpful to call out
these two common examples if I am understanding this correctly,
otherwise it seems pretty vague.

What t= his is trying to convey is that because client authentication at this Pushe= d Authorization Request Endpoint happens the same way as at the token endpo= int (and other endpoints called directly by the client) the client_id param= eter will sometimes be present but not necessarily as some types of client = auth use the client_id parameter (none, client_secret_post, tls_client_auth= , self_signed_tls_client_auth) and some don't (client_secret_basic, cli= ent_secret_jwt, private_key_jwt).

Although the dra= ft does later say "The AS MUST validate the request the same way as at= the authorization endpoint" which I think could reasonably be interpr= eted as requiring client_id.=C2=A0 e.g., https://tools.ietf.org/html/rfc6749?#section-4= .1.1 & https://tools.ietf.org/html/rfc6749?#section-4.2.1
So perhaps the sentence in question should be removed and have= client_id be a required parameter at the PAR endpoint.

=

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000fb72e60593c6cbf4-- From nobody Mon Sep 30 08:33:45 2019 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 9E2D0120110 for ; Mon, 30 Sep 2019 08:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 l4EhUw1knlKU for ; Mon, 30 Sep 2019 08:33:40 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 777B71200CD for ; Mon, 30 Sep 2019 08:33:39 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id b20so9974681ljj.5 for ; Mon, 30 Sep 2019 08:33:39 -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=EYHUbroTuW8sd60OKeeHCDRtsKkc5+iaUCWE778YEVM=; b=sHR97k1FVCtpt7d4mdw1qzt2qYGwUHZE/xgyIk+o4v1+4a/MJT9hHSbaIyMay7VWiL XUJb74yhwSt66lHadZo0TxxPrIa32ysNg5C/MNCLDxlX8SHQDzkdM/YRhG8dcUIoaVs6 zOAQHo+Qy8JhPNIZiETy4P38WsGjdLmY0J1M+1G1Ll6H7XgeN5t+vqwf0uE5EW9+7599 MkDDJAcnbX1/MU4DrRfb9Kmsiq4SgK44t8Iujs4dkWO/6I2WZJBTFrLo4c4p+yay0gQ4 4YvtTEbyeuBXbgyp3AxTf9F+OgpY1NKJBCOCQBUWBEJWJp9GM20uU3RG5QV0r8H0Ke3g Y6wA== 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=EYHUbroTuW8sd60OKeeHCDRtsKkc5+iaUCWE778YEVM=; b=G4CEbxl+E+gdoAcQOwNZGK9b3Fp31DbplqAhsjUgNCKcuqPSxGe/w7/xsOaUWjegvt ZdXdwlJpe7aUwszNztcOJGln6pzCebKlKAduDkK30GsC5Zkm7E8tqmEk7Ww5Uu4Kx0RM DVtq3aSFDoUiGfkqvpTSvwH6VF4KQ+9jav46Fq5wx49PWrZT8IEB3pMP4UL9HS9tRFBh QkhZjW1C+eiT72dfp3DW/KPGkIHeoR2aHxQl8i7Gm2aD5WxJqHzChkjkkwlKfNkV/Amn 6FR0FqM0LKXYldy9ItNM0Q1gPCLreUkYigySAq2VwVS5mOtp2xFuaXGg6MbRKMOIuC7L eFNw== X-Gm-Message-State: APjAAAUCV2Zt069hk7/L70pf1RtImef/3HHqFmlkXQCltsHtMJ324ozt RutoIJBaYgR63B/xSWL6UU4OmM0UDNjmbsRfdAM= X-Google-Smtp-Source: APXvYqy1VkhVnqLIROLhtp+a9avfsrYpztMR+C3zj02u3Pv4gInuUcQiAxN8M1I/I0ASg24EVvwa4OjrRfBjns/PusM= X-Received: by 2002:a2e:1614:: with SMTP id w20mr12551762ljd.159.1569857617383; Mon, 30 Sep 2019 08:33:37 -0700 (PDT) MIME-Version: 1.0 References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> In-Reply-To: From: Dick Hardt Date: Mon, 30 Sep 2019 08:33:25 -0700 Message-ID: To: Dave Tonge Cc: Justin Richer , oauth Content-Type: multipart/alternative; boundary="000000000000a1d5890593c6f582" Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt 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, 30 Sep 2019 15:33:44 -0000 --000000000000a1d5890593c6f582 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I can understand the request URI being a URI that the client is providing the AS, but why would the client's request URI be at the AS? As Justin has explained it in the past, the AS is returning a handle to the transaction. The only party that understands that handle as far as I know is the AS. It is meaningless to the client. Perhaps I am missing something else? =E1=90=A7 On Mon, Sep 30, 2019 at 2:53 AM Dave Tonge wrote: > So although for this spec, request_uri is just an opaque string, it is > defined more generally in > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.2 as an: > > * Absolute URI from which the Request Object (Section 2.1) can be obtaine= d* > > > And in section 5.2 as: > > >> *The "request_uri" value MUST be either URN as defined in* >> * RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230* >> * [RFC7230] . The "request_uri" value MUST be reachable by the** >> Authorization Server.* > > > So this is why in the spec we have example of a URN and we have an ongoin= g > discussion as to whether we should have a standard urn namespace that we > recommend implementers use. > > In the interest of keeping the specs in sync I think it makes sense to > keep it a URN for this spec, but with more of an explanation as to why? > > Dave > > On Fri, 27 Sep 2019 at 19:22, Dick Hardt wrote: > >> If I understand the proposal correctly, the request URI is opaque to the >> client. Correct? >> >> If so, why not just treat it as an opaque string? >> >> If I were implementing the protocol, I would have the blob be a signed >> token so that I could verify the integrity before making a database call= . >> It much easier to throw compute at a DDOS attack to verify a signature, >> than DB capacity. >> >> =E1=90=A7 >> >> On Thu, Sep 26, 2019 at 2:24 PM Justin Richer wrote: >> >>> Yes, the request object is JWT-based, but the request URI is not. In >>> other words, you can post a JWT but what you get back is a URI, not the= JWT >>> itself. The request URI was always meant to be a reference, and origin= ally >>> it was explicitly a reference to a signed request object. >>> >>> =E2=80=94 Justin >>> >>> On Sep 26, 2019, at 10:03 AM, Aaron Parecki wrote: >>> >>> The URI is intended to be a reference not a value.. If the client could >>> send a JWT it would just send a request object instead of a request URI= in >>> the first place. So the intent is that it=E2=80=99s random, and maybe w= e should >>> just say that explicitly. >>> >>> >>> I thought this language was explicitly to allow the use of structured >>> values for the request_uri? From the introduction: >>> >>> but it also allows clients requiring an even >>> higher security level, especially cryptographically confirmed non- >>> repudiation, to explicitly adopt JWT-based request objects. >>> >>> >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> >>> On Thu, Sep 26, 2019 at 6:49 PM Justin Richer wrote: >>> >>> >>> Aaron, some comments inline. >>> >>> =E2=80=94 Justin >>> >>> On Sep 26, 2019, at 8:30 AM, Aaron Parecki wrote: >>> >>> Hi Torsten, >>> >>> I'm very glad to see this draft, I think it's definitely needed in >>> this space. Here are some of my thoughts on the draft. >>> >>> "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" >>> >>> >>> Is it acceptable for the AS to return just an opaque string, rather >>> than something prefixed with "uri:*"? I don't think anyone would be >>> confused about copypasting the exact string from the "request_uri" >>> response into the "request_uri" parameter even if it didn't start with >>> "urn:". If, for whatever reason, it is required that this value is >>> actually a URI, is there some expected namespace to use other than >>> "example"? I worry that if all the examples in the spec are just >>> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up >>> using the text "example" because they don't understand why it's there, >>> and then it serves no purpose really.=E2=80=99 >>> >>> >>> This field must be a URI, as per JAR: >>> >>> request_uri The absolute URI as defined by RFC3986 [RFC3986] that >>> points to the Request Object (Section 2.1) that holds >>> authorization request parameters stated in section 4 of OAuth 2.0 >>> [RFC6749]. >>> >>> Somewhat awkwardly, the JAR spec currently states that the AS has to do >>> an HTTP GET on the request URI, so that will need to be fixed in JAR be= fore >>> it goes forward. I don=E2=80=99t think that was always the case though,= and I=E2=80=99m not >>> sure how that changed. >>> >>> As for the namespace, =E2=80=9Cexample=E2=80=9D is ok for an example UR= N. The problem >>> with URNs is that nobody really understands how to do domain-safe fully >>> compliant URNs. So perhaps we should instead use =E2=80=9Curn:fdc:examp= le.com:=E2=80=A6.=E2=80=9D >>> Instead (as per https://tools.ietf.org/html/rfc4198). >>> >>> >>> The pushed authorization request endpoint shall be a RESTful API >>> >>> >>> I would drop the term RESTful and just say "HTTP API", as this >>> description is arguably RESTful at best. >>> >>> Depending on client type and authentication method, the request might >>> also include the "client_id" parameter. >>> >>> >>> I assume this is hinting at the difference between public clients >>> sending only the "client_id" parameter and confidential clients >>> sending only the HTTP Basic Authorization header which includes both >>> the client ID and secret? It would probably be helpful to call out >>> these two common examples if I am understanding this correctly, >>> otherwise it seems pretty vague. >>> >>> >>> Not quite, those differences are for the token endpoint, and this is >>> capturing things from the authorization endpoint. I don=E2=80=99t quite= understand >>> the differentiation listed here either, though. >>> >>> >>> The "request_uri" value MUST be generated using a cryptographically >>> strong pseudorandom algorithm >>> >>> >>> I assume this includes the use of a random number inside of a JWT, in >>> case the AS wants to use JWTs as the "request_uri" parameter"? If so, >>> it's probably worth spelling that out as it kind of reads like it has >>> to be literally a random string at first glance. >>> >>> >>> The URI is intended to be a reference not a value. If the client could >>> send a JWT it would just send a request object instead of a request URI= in >>> the first place. So the intent is that it=E2=80=99s random, and maybe w= e should >>> just say that explicitly. >>> >>> >>> That's all for now, thanks! >>> >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>> >>> On Sat, Sep 21, 2019 at 1:02 PM Torsten Lodderstedt >>> wrote: >>> >>> >>> Hi all, >>> >>> I just published a new draft that Brian Campbell, Dave Tonge, Filip >>> Skokan, Nat Sakimura and I wrote. >>> >>> https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 >>> >>> It proposes a new endpoint, called "pushed authorization request >>> endpoint=E2=80=9D, that allows the client to push the Authorization Req= uest payload >>> with the AS on a backchannel connection instead of a front channel >>> interaction. The AS provides the client with a request URI (according t= o >>> draft-ietf-oauth-jwsreq) that the client uses in a subsequent authoriza= tion >>> requests to refer to the pushed request data. >>> >>> We believe this simple mechanism will significantly increase OAuth >>> security and robustness since any application can use it by just sendin= g >>> the parameters in the same encoding as used at the authorisation endpoi= nt >>> over a HTTPS-protected and (for confidential clients) mutually >>> authenticated connection to the AS. It can also be used to push signed = and >>> encrypted request objects to the AS, i.e. it provides an interoperable = way >>> to use request objects managed at the AS for use cases requiring an eve= n >>> higher security level. >>> >>> We look forward to getting your feedback. >>> >>> kind regards, >>> Torsten. >>> >>> Begin forwarded message: >>> >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for draft-lodderstedt-oauth-par-00.tx= t >>> Date: 21. September 2019 at 12:47:28 CEST >>> To: "Nat Sakimura" , "Brian Campbell" < >>> bcampbell@pingidentity.com>, "Torsten Lodderstedt" < >>> torsten@lodderstedt.net>, "Dave Tonge" , "Filip Skokan" >>> >>> >>> >>> A new version of I-D, draft-lodderstedt-oauth-par-00.txt >>> has been successfully submitted by Torsten Lodderstedt and posted to th= e >>> IETF repository. >>> >>> Name: draft-lodderstedt-oauth-par >>> Revision: 00 >>> Title: OAuth 2.0 Pushed Authorization Requests >>> Document date: 2019-09-21 >>> Group: Individual Submission >>> Pages: 12 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-par-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 >>> >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par >>> >>> >>> Abstract: >>> This document defines the pushed authorization request endpoint, >>> which allows clients to push the payload of an OAuth 2.0 >>> authorization request to the authorization server via a direct >>> request and provides them with a request URI that is used as >>> reference to the data in a subsequent authorization request. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > > --000000000000a1d5890593c6f582 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I can understand the request URI being a URI that the clie= nt is providing the AS, but why would the client's request URI be at th= e AS?

As Justin has explained it in the past, the AS is = returning=C2=A0a handle to the transaction. The only party that understands= that handle as far as I know is the AS. It is meaningless to the client. P= erhaps I am missing something else?
3D""=E1=90=A7
On = Mon, Sep 30, 2019 at 2:53 AM Dave Tonge <dave.tonge@momentumft.co.uk> wrote:
So although for this spec, request_uri is just an opaque stri= ng, it is defined more generally in=C2=A0https://tool= s.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.2 as an:

=C2= =A0Absolute URI from which the Request Object (Section 2.1) can be obtained=

And in section 5.2 as:=

The "request_uri" value MUST be either URN as defined in=C2=A0 =C2=A0RFC8141 [RFC8141] or "https" URI, as defined= in 2.7.2 of RFC7230
=C2=A0 =C2=A0[RFC7230] .=C2=A0 The "req= uest_uri" value MUST be reachable by the
=C2=A0 =C2=A0Author= ization Server.

So this i= s why in the spec we have example of a URN and we have an ongoing discussio= n as to whether we should have a standard urn namespace that we recommend i= mplementers use.

In the interest of = keeping the specs in sync I think it makes sense to keep it a URN for this = spec, but with more of an explanation as to why?

Dave

On Fri, 27 Sep 2019 at 19:22, Dick Hardt <dick.hardt@gmail.com= > wrote:
If I understand the proposal correctly, the request URI is opa= que to the client. Correct?

If so, why not just treat it= as an opaque string?

If I were implementing the p= rotocol, I would have the blob be a signed token so that I could verify the= integrity before making a database call. It much easier to throw compute a= t a DDOS attack to verify a signature, than DB capacity.

3D==E1=90=A7

On Thu, Sep 26, 2019 at 2:24 PM Jus= tin Richer <jricher= @mit.edu> wrote:
Yes, the request object is JWT-based, but the request URI is not. In other = words, you can post a JWT but what you get back is a URI, not the JWT itsel= f.=C2=A0 The request URI was always meant to be a reference, and originally= it was explicitly a reference to a signed request object.=C2=A0

=E2=80=94 Justin

On Sep 26, 2019, at 10:03 AM, Aaron Parecki <aaron@parecki.com> wrote:

The URI is intended to be a reference not a value= .. If the client could send a JWT it would just send a request object inste= ad of a request URI in the first place. So the intent is that it=E2=80=99s = random, and maybe we should just say that explicitly.

I thought this language was explicitly to allow the use of structured
values for the request_uri? From the introduction:

but it also allows clients requiring an even
higher security level, especially cryptographically confirmed non-
repudiation, to explicitly adopt JWT-based request objects.

----
Aaron Parecki
aaronparecki.com<= br>
On Thu, Sep 26, 2019 at 6:49 PM Justin Richer <jricher@mit.edu> wrote:

Aaron, some comments inline.

=E2=80=94 Justin

On Sep 26, 2019, at 8:30 AM, Aaron Parecki <aaron@parecki.com> wrote:

Hi Torsten,

I'm very glad to see this draft, I think it's definitely needed in<= br> this space. Here are some of my thoughts on the draft.

"request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2"= ;


Is it acceptable for the AS to return just an opaque string, rather
than something prefixed with "uri:*"? I don't think anyone wo= uld be
confused about copypasting the exact string from the "request_uri"= ;
response into the "request_uri" parameter even if it didn't s= tart with
"urn:". If, for whatever reason, it is required that this value i= s
actually a URI, is there some expected namespace to use other than
"example"? I worry that if all the examples in the spec are just<= br> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will en= d up
using the text "example" because they don't understand why it= 's there,
and then it serves no purpose really.=E2=80=99


This field must be a URI, as per JAR:

=C2=A0=C2=A0request_uri =C2=A0The absolute URI as defined by RFC3986 [RFC39= 86] that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0points to the Request Object (Section 2.1) th= at holds
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0authorization request parameters stated in se= ction 4 of OAuth 2.0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[RFC6749].

Somewhat awkwardly, the JAR spec currently states that the AS has to do an = HTTP GET on the request URI, so that will need to be fixed in JAR before it= goes forward. I don=E2=80=99t think that was always the case though, and I= =E2=80=99m not sure how that changed.

As for the namespace, =E2=80=9Cexample=E2=80=9D is ok for an example URN. T= he problem with URNs is that nobody really understands how to do domain-saf= e fully compliant URNs. So perhaps we should instead use =E2=80=9Curn:fdc:e= xample.com:=E2=80=A6.=E2=80=9D Instead (as per https://tools.ietf.org/html/rfc4198).


The pushed authorization request endpoint shall be a RESTful API


I would drop the term RESTful and just say "HTTP API", as this description is arguably RESTful at best.

Depending on client type and authentication method, the request might
also include the "client_id" parameter.


I assume this is hinting at the difference between public clients
sending only the "client_id" parameter and confidential clients sending only the HTTP Basic Authorization header which includes both
the client ID and secret? It would probably be helpful to call out
these two common examples if I am understanding this correctly,
otherwise it seems pretty vague.


Not quite, those differences are for the token endpoint, and this is captur= ing things from the authorization endpoint. I don=E2=80=99t quite understan= d the differentiation listed here either, though.


The "request_uri" value MUST be generated using a cryptographical= ly
strong pseudorandom algorithm


I assume this includes the use of a random number inside of a JWT, in
case the AS wants to use JWTs as the "request_uri" parameter"= ;? If so,
it's probably worth spelling that out as it kind of reads like it has to be literally a random string at first glance.


The URI is intended to be a reference not a value. If the client could send= a JWT it would just send a request object instead of a request URI in the = first place. So the intent is that it=E2=80=99s random, and maybe we should= just say that explicitly.


That's all for now, thanks!

----
Aaron Parecki
aaronparecki.com<= br> @aaronpk

On Sat, Sep 21, 2019 at 1:02 PM Torsten Lodderstedt
<torsten@lo= dderstedt.net> wrote:


Hi all,

I just published a new draft that Brian Campbell, Dave Tonge, Filip Skokan,= Nat Sakimura and I wrote.

https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00

It proposes a new endpoint, called "pushed authorization request endpo= int=E2=80=9D, that allows the client to push the Authorization Request payl= oad with the AS on a backchannel connection instead of a front channel inte= raction. The AS provides the client with a request URI (according to draft-ietf-oauth-jwsreq) that the client uses in a subse= quent authorization requests to refer to the pushed request data.

We believe this simple mechanism will significantly increase OAuth security= and robustness since any application can use it by just sending the parame= ters in the same encoding as used at the authorisation endpoint over a HTTP= S-protected and (for confidential clients) mutually authenticated connection to the AS. It can also be used = to push signed and encrypted request objects to the AS, i.e. it provides an= interoperable way to use request objects managed at the AS for use cases r= equiring an even higher security level.

We look forward to getting your feedback.

kind regards,
Torsten.

Begin forwarded message:

From: interne= t-drafts@ietf.org
Subject: New Version Notification for draft-lodderstedt-oauth-par-00.txt Date: 21. September 2019 at 12:47:28 CEST
To: "Nat Sakimura" <nat@sakimura.org>, "Brian Campbell" <bcampbell@pingide= ntity.com>, "Torsten Lodderstedt" <torsten@lodderstedt.net>, &= quot;Dave Tonge" <dave@tonge.org>, "Filip Skokan" <panva.ip@gmail.com>


A new version of I-D, draft-lodderstedt-oauth-par-00.txt
has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository.

Name: draft-lodderstedt-oauth-par
Revision: 00
Title: OAuth 2.0 Pushed Authorization Requests
Document date: 2019-09-21
Group: Individual Submission
Pages: 12
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-lodderste= dt-oauth-par-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht= tps://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.= ietf.org/html/draft-lodderstedt-oauth-par-00
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://= datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par


Abstract:
This document defines the pushed authorization request endpoint,
which allows clients to push the payload of an OAuth 2.0
authorization request to the authorization server via a direct
request and provides them with a request URI that is used as
reference to the data in a subsequent authorization request.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--

=
--000000000000a1d5890593c6f582-- From nobody Mon Sep 30 08:46:13 2019 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 BA526120813 for ; Mon, 30 Sep 2019 08:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 OPpHduWSBfNb for ; Mon, 30 Sep 2019 08:46:09 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 368471200CD for ; Mon, 30 Sep 2019 08:46:09 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id a1so39568427ioc.6 for ; Mon, 30 Sep 2019 08:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/yBOLR7uWzSeU6AUiuJ6dHysGNUWvySDCJZkAVlEOTA=; b=mJ6Ek+hyB5oHLadAwyJyo9eTs1aMPszhMqAX2Fz9IVmeXP9Lj7V5CUwxhTNXnjYy13 A6eG1rx0fTLmZ5KvZsjYZKB3fHuckTNqcctmKrZ5w/HpE2GPhuCmfPVmLT8c5bEsysD2 NWQRYF+Lhl2DbjCZkuh01yZhVYZ/0gdAKvFJs= 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=/yBOLR7uWzSeU6AUiuJ6dHysGNUWvySDCJZkAVlEOTA=; b=VaFfNCkskNP9UFp6taAKWznLvVcwEAY2nNrlpTJr1+dARftdOivIQW9T1wzDO2iupY 6B1VXRO1Wq68xHwB9e7bDTKq3IsVQcAukchwaeZGg28r8qnl95yQzrZlpuqYXkKUbntQ yHiWThLprM/rWSWsuNylnMsu4r+nhcxOTYacqJ6+HoOWC4ChZS27sYtl1cLcKobMISDQ YyIQSIJmbSNS2wUpWl3Ut2ug3nMPUZ3D0nP1D36Fc+oZPxmg2pL5DqEzYQr0vHMcX0jb EVxpZ8cgjptWB3C7EAs0XAGvz4jL0rX7zDuBYpt3R+9thMGCAp8Y0UJpKhOJ1Hd345Zq GNiw== X-Gm-Message-State: APjAAAUCIDkrtqA3ESeHRsDvI5JkqwPMB4CiyijCr02LvubJPKFWEpol wbni9ckWLdJoKUo+PY0lkaTjig7BR+8w9cdz/OmTHya7keODzUws8mu1Z3qw7W+H7aoEoAvgz4z fzF2W6/jMcTsDEg== X-Google-Smtp-Source: APXvYqz2PXSwGhOFA4Wxseju/AlQKTgx8SERwZfs4//+ufDiTPiu5ToE4s/rjsqljRw515fDCX4mPfJpRbfEJ9nHsjM= X-Received: by 2002:a92:d1c5:: with SMTP id u5mr21103663ilg.201.1569858368355; Mon, 30 Sep 2019 08:46:08 -0700 (PDT) MIME-Version: 1.0 References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> In-Reply-To: From: Brian Campbell Date: Mon, 30 Sep 2019 09:45:40 -0600 Message-ID: To: Justin Richer Cc: Aaron Parecki , oauth Content-Type: multipart/alternative; boundary="00000000000064e66c0593c722cc" Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt 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, 30 Sep 2019 15:46:12 -0000 --00000000000064e66c0593c722cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 26, 2019 at 10:50 AM Justin Richer wrote: > If, for whatever reason, it is required that this value is > actually a URI, is there some expected namespace to use other than > "example"? I worry that if all the examples in the spec are just > "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up > using the text "example" because they don't understand why it's there, > and then it serves no purpose really.=E2=80=99 > > > This field must be a URI, as per JAR: > > request_uri The absolute URI as defined by RFC3986 [RFC3986 ] that > points to the Request Object (Section 2.1 ) that holds > authorization request parameters stated in section 4 of OAuth 2.0 > [RFC6749 ]. > > Somewhat awkwardly, the JAR spec currently states that the AS has to do a= n > HTTP GET on the request URI, so that will need to be fixed in JAR before = it > goes forward. I don=E2=80=99t think that was always the case though, and = I=E2=80=99m not > sure how that changed. > JAR does have a somewhat awkward allowance for not doing a GET in https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.3 saying an AS "MUST send an HTTP "GET" request to the request_uri to retrieve the referenced Request Object, unless it is stored in a way so that it can retrieve it through other mechanism securely." So I'm guessing maybe nothing actually changed but it's just hard to find in the document. > As for the namespace, =E2=80=9Cexample=E2=80=9D is ok for an example URN.= The problem with > URNs is that nobody really understands how to do domain-safe fully > compliant URNs. So perhaps we should instead use =E2=80=9Curn:fdc:example= .com:=E2=80=A6.=E2=80=9D > Instead (as per https://tools.ietf.org/html/rfc4198). > Something else to consider additionally or alternately is that the document could provide some suggestions/guidance or even requirements on the structure of the URN for this self referential case. It could, for example, use the RFC6755 subnamespace and registry and be of the form urn:ietf:params:oauth:request_uri: or urn:ietf:params:oauth:request_uri; or urn:ietf:params:oauth:request_uri?value=3D or urn:ietf:params:oauth:request_uri# or however the proper way to do that would be. --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000064e66c0593c722cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 26, 2019 at 10:50 AM Just= in Richer <jricher@mit.edu> wr= ote:
=C2=A0If, for whatever reason, it is required that this value is
actually a URI, is there some expected namespace to use other than
"example"? I worry that if all the examples in the spec are just<= br> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will en= d up
using the text "example" because they don't understand why it= 's there,
and then it serves no purpose really.=E2=80=99

This field must be a URI, as per JAR:

   request_uri  The absolute URI as defined by RFC3986 [RFC3986] that
      points to the Request Object (Section 2.1) =
that holds
      authorization request parameters stated in sectio=
n 4 of OAuth 2.0
      [RFC6749].
Somewhat awkwardly, the JAR spec currently states that the AS has to d= o an HTTP GET on the request URI, so that will need to be fixed in JAR befo= re it goes forward. I don=E2=80=99t think that was always the case though, = and I=E2=80=99m not sure how that changed.=C2=A0

JAR does have a somewhat= awkward allowance for not doing a GET in https://tools.ietf.org/html= /draft-ietf-oauth-jwsreq-19#section-5.2.3 saying an AS "MUST send = an HTTP "GET" request to the request_uri to retrieve the referenc= ed Request Object, unless it is stored in a way so that it can retrieve it = through other mechanism securely."

So I&= #39;m guessing maybe nothing actually changed but it's just hard to fi= nd in the document.

=C2=A0
As for the namespace, =E2=80=9Cexample=E2=80=9D is ok for an example U= RN. The problem with URNs is that nobody really understands how to do domai= n-safe fully compliant URNs. So perhaps we should instead use =E2=80=9Curn:= fdc:example.com:=E2=80= =A6.=E2=80=9D Instead (as per=C2=A0https://tools.ietf.org/html/rfc4198).

Something else to consid= er additionally or alternately is that the document could provide some sugg= estions/guidance or even requirements on the structure of the URN for this = self referential case. It could, for example, use the RFC6755 subnamespace = and registry and be of the form urn:ietf:params:oauth:request_uri:<handl= e> or urn:ietf:params:oauth:request_uri;<handle> or urn:ietf:param= s:oauth:request_uri?value=3D<handle> or urn:ietf:params:oauth:request= _uri#<handle> or however the proper way to do that would be.

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000064e66c0593c722cc-- From nobody Mon Sep 30 08:57:24 2019 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 C1082120813 for ; Mon, 30 Sep 2019 08:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 VQds7tSnQ59w for ; Mon, 30 Sep 2019 08:57:20 -0700 (PDT) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.103]) (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 28D4C12004F for ; Mon, 30 Sep 2019 08:57:20 -0700 (PDT) Received: from [73.202.53.104] (helo=[10.0.0.153]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iEy33-0008DI-1o; Mon, 30 Sep 2019 17:57:17 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4B182FB4-30B6-4032-A2D4-E9CC1D13975B"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 30 Sep 2019 08:57:12 -0700 In-Reply-To: Cc: Aaron Parecki , oauth To: Brian Campbell References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt 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, 30 Sep 2019 15:57:23 -0000 --Apple-Mail=_4B182FB4-30B6-4032-A2D4-E9CC1D13975B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I wouldn't call it an API. What about just calling it an "HTTP = endpoint"? > On 30. Sep 2019, at 07:52, Brian Campbell = wrote: >=20 >=20 >=20 > On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki = wrote: > > The pushed authorization request endpoint shall be a RESTful API >=20 > I would drop the term RESTful and just say "HTTP API", as this > description is arguably RESTful at best. >=20 > +1=20 >=20 >=20 > 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. --Apple-Mail=_4B182FB4-30B6-4032-A2D4-E9CC1D13975B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA5MzAxNTU3MTNaMC8GCSqGSIb3DQEJBDEiBCCOu1ohYEe3Uc0i6t0DU/0a8Qtq9FavUVhp IbFQBcTmEDCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAKRrd6gbhbfjncK0mOAzUYGZ0+YxxQ7yvzMGybJt6fVmN0cA3/3gayZoy4ZU VQ4QSBfkZjfW4YSTmuFA6/AUEviX480t2bGcx0d1v07Mg0ml2b7Mb9ZETfrMY5XtZ6CeSYRKk+zB 2G8ezsuriwtkMoc8Fw1vbIjXNWYmOqTp7jv3IonH5GRTrBBoiPjDKw/38Yp93AxpKpuh0rtEr8iA 4ko/PbjSDawCifqwtBRQ0iunVJtEYKY7rnM36xolxd5Dh0RCZuBX9Yg8G5cWBVeBZVqkDmAzQp11 7a8l8cTUT6bgNnNCCP5p4FarWQCAYbvnCL7IaipesuHB6PHjND/fGugAAAAAAAA= --Apple-Mail=_4B182FB4-30B6-4032-A2D4-E9CC1D13975B-- From nobody Mon Sep 30 08:59:51 2019 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 5630B120813 for ; Mon, 30 Sep 2019 08:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 my-E12KerWCH for ; Mon, 30 Sep 2019 08:59:46 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) (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 E0F6F1200DB for ; Mon, 30 Sep 2019 08:59:45 -0700 (PDT) Received: from [73.202.53.104] (helo=[10.0.0.153]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iEy5O-0000pr-EK; Mon, 30 Sep 2019 17:59:42 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4BFFEDE1-9B53-4236-9D71-24042BA7EA29"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 30 Sep 2019 08:59:39 -0700 In-Reply-To: Cc: Justin Richer , oauth To: Brian Campbell References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt 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, 30 Sep 2019 15:59:49 -0000 --Apple-Mail=_4BFFEDE1-9B53-4236-9D71-24042BA7EA29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 What if PAR would use another parameter? It could even return the actual = authorization URL. > On 30. Sep 2019, at 08:45, Brian Campbell = wrote: >=20 >=20 >=20 > On Thu, Sep 26, 2019 at 10:50 AM Justin Richer = wrote: >> If, for whatever reason, it is required that this value is >> actually a URI, is there some expected namespace to use other than >> "example"? I worry that if all the examples in the spec are just >> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up >> using the text "example" because they don't understand why it's = there, >> and then it serves no purpose really.=E2=80=99 >=20 > This field must be a URI, as per JAR: >=20 > request_uri The absolute URI as defined by RFC3986 [RFC3986 > ] that > points to the Request Object ( > Section 2.1 > ) that holds > authorization request parameters stated in=20 > section 4 > of OAuth 2.0 > [ > RFC6749 > ]. >=20 > Somewhat awkwardly, the JAR spec currently states that the AS has to = do an HTTP GET on the request URI, so that will need to be fixed in JAR = before it goes forward. I don=E2=80=99t think that was always the case = though, and I=E2=80=99m not sure how that changed.=20 >=20 > JAR does have a somewhat awkward allowance for not doing a GET in = https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.3 = saying an AS "MUST send an HTTP "GET" request to the request_uri to = retrieve the referenced Request Object, unless it is stored in a way so = that it can retrieve it through other mechanism securely."=20 >=20 > So I'm guessing maybe nothing actually changed but it's just hard to = find in the document. >=20 > =20 > As for the namespace, =E2=80=9Cexample=E2=80=9D is ok for an example = URN. The problem with URNs is that nobody really understands how to do = domain-safe fully compliant URNs. So perhaps we should instead use = =E2=80=9Curn:fdc:example.com:=E2=80=A6.=E2=80=9D Instead (as per = https://tools.ietf.org/html/rfc4198).=20 >=20 > Something else to consider additionally or alternately is that the = document could provide some suggestions/guidance or even requirements on = the structure of the URN for this self referential case. It could, for = example, use the RFC6755 subnamespace and registry and be of the form = urn:ietf:params:oauth:request_uri: or = urn:ietf:params:oauth:request_uri; or = urn:ietf:params:oauth:request_uri?value=3D or = urn:ietf:params:oauth:request_uri# or however the proper way to = do that would be. >=20 > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_4BFFEDE1-9B53-4236-9D71-24042BA7EA29 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA5MzAxNTU5NDBaMC8GCSqGSIb3DQEJBDEiBCDu4BgKQcK0SBK64tAcZF7dk6bXaRYntfCc 86gL49u6QjCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAJquhyUZigyz44hagLKvhnJpYoI/uqWDgTSbeyIe/pciNNxqvGQSK+LjXzJy 48oEj4/WtJNV8KWO4mra4tmEMBNTVAVhHpWOAUzK2pb9L0tfDZoyLnuL2oyXpmz+CiEC1vjzETsL 2B4If7meGbBf1nT3AUbc1FgbbkHpA9MTJoMz1wUsRyq1Yk1PBQzBIyxpRR8f8mJYRVKd7OTIOT4h 1sIi1gqnD4oi1ZuA7M4hhLEeQmjDSCQekhNOao5W52biGr7XGfkuOI+0SJtyqjLczGvdHUWouxrf HOGf/EYyvdrqCaqMRTluv9sX89NVrAJ3z64VmpcPCubT0Sr5NpJwYpoAAAAAAAA= --Apple-Mail=_4BFFEDE1-9B53-4236-9D71-24042BA7EA29-- From nobody Mon Sep 30 09:00:53 2019 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 729FA12081B for ; Mon, 30 Sep 2019 09:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 DyRGUqJ9bf3G for ; Mon, 30 Sep 2019 09:00:50 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 77779120829 for ; Mon, 30 Sep 2019 09:00:41 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id q1so39735043ion.1 for ; Mon, 30 Sep 2019 09:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yDkORtf3EZormKfnYpXsL1oAdCPiBcN+GXSRdfnmu6Y=; b=oCIZoRtMxhcbfy+wA04UEhJLFJM6lJ3iPqGrS2/R1oj2ICteCnYTazhbaEBlN1WfT4 X5a9k4+CAgaKoGXbFZZaWL3tHnuWWsqYJOdPXHTH0fctNt6CIPIkkXue7k13TGq/9wN+ HYLRfgRbBUlqocI3ivoB/V8cBhoqFRGhifKJE= 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=yDkORtf3EZormKfnYpXsL1oAdCPiBcN+GXSRdfnmu6Y=; b=g7iwVBBY8vhmSLOnxIBim3W6y2b31UIFxa0AbSGUGbEb6VIlgHbMvwkhU+hCvYhunJ UTC+5abwx/C1Cjiha1rba3yffilNohvc6L+zV4lUzzVrugOa55n3FB8YZ5hbDigIaE+B sKqjgcxa3B8yThQyHmahXyn6UnsZgmMgQ57wZMi0alYKLbw020Tz5oyNMPUj2Xr/AZHv qROgidwtA2aFgztvJV9TmXEqIZ2fu1XlVyNzU6wj+PQpoVrO9vYUebsMjIvtepOCR9Io 69r3zC+h4/5aT0tuK1Xp8KpwpmRwSfQ7zzzkKB5yd+0sFBAsbiKXp2luA/0m4l6HioMf WClw== X-Gm-Message-State: APjAAAXmAvowobOceKvaV5QhB4VRDyQpmr40Lke8/LyuiNohe9j9i/Mt 7KXd08dGX85MPr5zvFDjTes7lA7JNeH4HDFCoBheP+pF1pSlppQNVPCT1kX45c1y/yZXTQ6CEPI gCfV2w2Jc+LC+Ww== X-Google-Smtp-Source: APXvYqzypxeBn5sfgrcZIGAmZil9Vu2R1Er0s4Vt6sOdFnNnLB9ziEQAMzowj7idVpatlIhEhf5cTgytzKU2d0m5Y40= X-Received: by 2002:a6b:b494:: with SMTP id d142mr19701466iof.156.1569859240730; Mon, 30 Sep 2019 09:00:40 -0700 (PDT) MIME-Version: 1.0 References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> In-Reply-To: From: Brian Campbell Date: Mon, 30 Sep 2019 10:00:14 -0600 Message-ID: To: Torsten Lodderstedt Cc: Aaron Parecki , oauth Content-Type: multipart/alternative; boundary="0000000000006440d30593c756d8" Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt 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, 30 Sep 2019 16:00:53 -0000 --0000000000006440d30593c756d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think you did call it an API in the first place? :) endpoint is fine too though I believe Aaron's main point was that calling this REST is a bit of a stretch On Mon, Sep 30, 2019 at 9:57 AM Torsten Lodderstedt wrote: > I wouldn't call it an API. What about just calling it an "HTTP endpoint"? > > > On 30. Sep 2019, at 07:52, Brian Campbell > wrote: > > > > > > > > On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki wrote= : > > > The pushed authorization request endpoint shall be a RESTful API > > > > I would drop the term RESTful and just say "HTTP API", as this > > description is arguably RESTful at best. > > > > +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 sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you. > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000006440d30593c756d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think you did call it an API in the first place? :)=

endpoint is fine too though

I believe Aaron's main point was that calling this REST is a b= it of a stretch

On Mon, Sep 30, 2019 at 9:57 AM Torsten Lodderste= dt <torsten@lodderstedt.net> wrote:
I = wouldn't call it an API. What about just calling it an "HTTP endpo= int"?

> On 30. Sep 2019, at 07:52, Brian Campbell <bcampbell@pingidentity.com> = wrote:
>
>
>
> On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki <aaron@parecki.com> wrote:
> > The pushed authorization request endpoint shall be a RESTful API<= br> >
> I would drop the term RESTful and just say "HTTP API", as th= is
> description is arguably RESTful at best.
>
> +1
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.=C2=A0 If yo= u have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your = computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000006440d30593c756d8-- From nobody Mon Sep 30 09:15:15 2019 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 79BA9120820 for ; Mon, 30 Sep 2019 09:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 fZC9C6cZPvjo for ; Mon, 30 Sep 2019 09:15:08 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 81EF5120837 for ; Mon, 30 Sep 2019 09:14:59 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id v2so39704949iob.10 for ; Mon, 30 Sep 2019 09:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uLN6g8rcykkbdOzD4a39oWB7aaZ26i/5GbI89AANUiw=; b=kYnPVtnvyv/DTDj1XRuzEkB0U3ggb738rIOEA9QsYywKY0kYmx8E7KKJd+1w3hYT0n +6+9Z1pNNgQI/7lXA3g03W9k298AnqPZIVn3OylE3c6Nv7F2MRYjtciZM2k4EygViEct e7w2nJA5GYgq88UWHoz///loRFS44q/W11MLU= 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=uLN6g8rcykkbdOzD4a39oWB7aaZ26i/5GbI89AANUiw=; b=pCDKLsT6SyBJnG/oxuDAyUCDbyP/+ydLiiOqZNlK98AYTH2zag+TGrj/ePRmBSBtoO abELE3knzhImMbSEv+ha70TEY4bYhCqXHUXYgzbZfllOEimDBVLAUrW8TvhgE2uXHdHW BOmaTUeuMopuS9UI3NEK+XPnRhHX0nh549WyeS3IYjHlVq8vdM6Rork5VtGcWw2/7LEv bHHSrZw8K+AJLjQri4wHDh58gQBozDEWnSotcvxLqEuPEmu9GqkHJNm0KvgPVz86BqPD AgucTJ3MbW3G8sKXE0CWsqwHfJ/5PCHSn2xBLtojQFUtn+rmrLNiQA79p1/H0GRGo8tJ VqVQ== X-Gm-Message-State: APjAAAXq8cGh20YVdDWMhb9lDCY8F3kWsBDQFxZSAxM0KaHQFIcAEUg8 H53bRNM5hYyJ6KK35LFv5ocnWIC8QocUPq5t8r9L8nGcXrog2eTg2EVeKkH25ChAnAx85XIVmsu 6Q/94f3bsEDrb+JLa X-Google-Smtp-Source: APXvYqzUfKo9n6J3r7jnJj0KE5TVKSu5FFKCTeivgZaBR0b0YUCQM/MNA6tvOGpVMyDgn4YNrnN4Ad7J9nmyEMl7Ykk= X-Received: by 2002:a6b:b494:: with SMTP id d142mr19767367iof.156.1569860098783; Mon, 30 Sep 2019 09:14:58 -0700 (PDT) MIME-Version: 1.0 References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> In-Reply-To: From: Brian Campbell Date: Mon, 30 Sep 2019 10:14:45 -0600 Message-ID: To: Torsten Lodderstedt Cc: Justin Richer , oauth Content-Type: multipart/alternative; boundary="0000000000008911ec0593c78966" Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt 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, 30 Sep 2019 16:15:11 -0000 --0000000000008911ec0593c78966 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's certainly an option that could be considered. Trying to reuse some of JAR with request_uri makes a certain amount of sense. But maybe it's more baggage than it's worth. On Mon, Sep 30, 2019, 9:59 AM Torsten Lodderstedt wrote: > What if PAR would use another parameter? It could even return the actual > authorization URL. > > > On 30. Sep 2019, at 08:45, Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > > > > > > > > On Thu, Sep 26, 2019 at 10:50 AM Justin Richer wrote: > >> If, for whatever reason, it is required that this value is > >> actually a URI, is there some expected namespace to use other than > >> "example"? I worry that if all the examples in the spec are just > >> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up > >> using the text "example" because they don't understand why it's there, > >> and then it serves no purpose really.=E2=80=99 > > > > This field must be a URI, as per JAR: > > > > request_uri The absolute URI as defined by RFC3986 [RFC3986 > > ] that > > points to the Request Object ( > > Section 2.1 > > ) that holds > > authorization request parameters stated in > > section 4 > > of OAuth 2.0 > > [ > > RFC6749 > > ]. > > > > Somewhat awkwardly, the JAR spec currently states that the AS has to do > an HTTP GET on the request URI, so that will need to be fixed in JAR befo= re > it goes forward. I don=E2=80=99t think that was always the case though, a= nd I=E2=80=99m not > sure how that changed. > > > > JAR does have a somewhat awkward allowance for not doing a GET in > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.3 > saying an AS "MUST send an HTTP "GET" request to the request_uri to > retrieve the referenced Request Object, unless it is stored in a way so > that it can retrieve it through other mechanism securely." > > > > So I'm guessing maybe nothing actually changed but it's just hard to > find in the document. > > > > > > As for the namespace, =E2=80=9Cexample=E2=80=9D is ok for an example UR= N. The problem > with URNs is that nobody really understands how to do domain-safe fully > compliant URNs. So perhaps we should instead use =E2=80=9Curn:fdc:example= .com:=E2=80=A6.=E2=80=9D > Instead (as per https://tools.ietf.org/html/rfc4198). > > > > Something else to consider additionally or alternately is that the > document could provide some suggestions/guidance or even requirements on > the structure of the URN for this self referential case. It could, for > example, use the RFC6755 subnamespace and registry and be of the form > urn:ietf:params:oauth:request_uri: or > urn:ietf:params:oauth:request_uri; or > urn:ietf:params:oauth:request_uri?value=3D or > urn:ietf:params:oauth:request_uri# or however the proper way to d= o > that would be. > > > > 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 sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you._______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000008911ec0593c78966 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's certainly an option that could be conside= red. Trying to reuse some of JAR with request_uri makes a certain amount of= sense. But maybe it's more baggage than it's worth.

On Mon, Sep 30, 2= 019, 9:59 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
What if PAR would use another parameter? It could even return the = actual authorization URL.

> On 30. Sep 2019, at 08:45, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
>
>
>
> On Thu, Sep 26, 2019 at 10:50 AM Justin Richer <jricher@mit.edu>= ; wrote:
>>=C2=A0 If, for whatever reason, it is required that this value is >> actually a URI, is there some expected namespace to use other than=
>> "example"? I worry that if all the examples in the spec = are just
>> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developer= s will end up
>> using the text "example" because they don't understa= nd why it's there,
>> and then it serves no purpose really.=E2=80=99
>
> This field must be a URI, as per JAR:
>
>=C2=A0 =C2=A0 request_uri=C2=A0 The absolute URI as defined by RFC3986 = [RFC3986
> ] that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0points to the Request Object (
> Section 2.1
> ) that holds
>=C2=A0 =C2=A0 =C2=A0 =C2=A0authorization request parameters stated in <= br> > section 4
>=C2=A0 of OAuth 2.0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[
> RFC6749
> ].
>
> Somewhat awkwardly, the JAR spec currently states that the AS has to d= o an HTTP GET on the request URI, so that will need to be fixed in JAR befo= re it goes forward. I don=E2=80=99t think that was always the case though, = and I=E2=80=99m not sure how that changed.
>
> JAR does have a somewhat awkward allowance for not doing a GET in https://tools.ietf.org/ht= ml/draft-ietf-oauth-jwsreq-19#section-5.2.3 saying an AS "MUST sen= d an HTTP "GET" request to the request_uri to retrieve the refere= nced Request Object, unless it is stored in a way so that it can retrieve i= t through other mechanism securely."
>
> So I'm guessing maybe nothing actually changed but it's just h= ard to find in the document.
>
>=C2=A0
> As for the namespace, =E2=80=9Cexample=E2=80=9D is ok for an example U= RN. The problem with URNs is that nobody really understands how to do domai= n-safe fully compliant URNs. So perhaps we should instead use =E2=80=9Curn:= fdc:example.com:=E2=80=A6.=E2=80=9D Instead (as per ht= tps://tools.ietf.org/html/rfc4198).
>
> Something else to consider additionally or alternately is that the doc= ument could provide some suggestions/guidance or even requirements on the s= tructure of the URN for this self referential case. It could, for example, = use the RFC6755 subnamespace and registry and be of the form urn:ietf:param= s:oauth:request_uri:<handle> or urn:ietf:params:oauth:request_uri;<= ;handle> or urn:ietf:params:oauth:request_uri?value=3D<handle> or = urn:ietf:params:oauth:request_uri#<handle> or however the proper way = to do that would be.
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited..=C2=A0 If y= ou have received this communication in error, please notify the sender imme= diately by e-mail and delete the message and any file attachments from your= computer. Thank you._______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oau= th


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000008911ec0593c78966--