From nobody Sat Dec 1 01:06:35 2018 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 75BE3126C7E for ; Sat, 1 Dec 2018 01:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=armh.onmicrosoft.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 M7IrqW_W2cXD for ; Sat, 1 Dec 2018 01:06:29 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20065.outbound.protection.outlook.com [40.107.2.65]) (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 C7C8312426E for ; Sat, 1 Dec 2018 01:06:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V3x5DILb6rObP5mxRIPhiRqvCFo8Pgpfj6v4mf+XWe4=; b=UC6500VxcNp6lDF7zgiIg92ZKbUNZfAXFuhmPte9Z6gib3gt/nq2HpZRiLEDb8qWDFhKQbmCEtoEofzUoQiW4Xz8fO5cysKFCo5PCq/B82FyR56MvoazdDjWAT7pvHFHAwvLu8ebpzuHB1vWknIcOjrGsH3JFHOEW8lkK8Yhc7Y= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1357.eurprd08.prod.outlook.com (10.167.198.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.19; Sat, 1 Dec 2018 09:06:24 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::2056:1db1:e01:4670]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::2056:1db1:e01:4670%3]) with mapi id 15.20.1361.022; Sat, 1 Dec 2018 09:06:24 +0000 From: Hannes Tschofenig To: Aaron Parecki , Torsten Lodderstedt CC: Daniel Fett , IETF oauth WG Thread-Topic: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit Thread-Index: AdR/8wsdlCSgLoNZTem+1MxrAorhbwHYZjwAAABEwfcABVOygAAAbOyYAAB2LIAAH9tBAAAIC/AAAEN4+4AADeWWQA== Date: Sat, 1 Dec 2018 09:06:24 +0000 Message-ID: References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.19] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1357; 6:OhOyx8ebqvmPiorKJS8eQcSIMTpZ4Fz07tLZPkewmf7LTiShtAvX0mn1aaWXnBeitYf4wLo2q6oibIEX7Fj99OiJDbbbaGvVdutG5hCOzUltiPgnty0p12Qai/vO38f3+iWQ/TuMvob6roocrggXjlWhFtVxkrZGH1UL+qXMj9N3mApQFnIr99edrkwq4EKcQfgslq2dqzeFpNVORt/eFlsa7G0wTJo4nYPtuGxhpEBK6k9PpUnrqBXXsbaH92zLaDeJJMWtW7ToZwwsERgVo1zI6+5Pidb/UqlSRhQ8X78JLRoNql7sO1AKTZAb7FDBG+1+JGyf/FlSZ1LkwY/+Odh3jtZx3gSqZqMsEuPdtPnmgHvYIFaWSv6NfgnFH84bKKMX5+5l3SL1NFO7kPWzcuRM4zXlk3oFY3GS3uWecF7bW13lNDQulEzUUsyuc3UKSaAEEYbU7zEWgayncOoRnA==; 5:blcBfOtsLuyYNA6jg2gYnLBFw6bOwxdnfsOS36ca98qT6eyZ6O9gIqsBUtKXNBldtayrX4UFhNgAo2fSypzPEEMYMCtbfQg876xU5W0abGTa/lCDmIGkxrBgxwByKY4zq8WGZoChvCiEI2IFCUFSVkLUDq9aQRGB1okUrmTAhM4=; 7:b4j7jW672G6mBiaPn1OYPnH0hgQTIfjLmn7wmUvseU6fIWXQ0P1ywacBxB3zIbnX6RpLLYW7m9+0jhdXPqJ5v3T7QtgbjZgVT5DRFJOi1CqPGx+GeiChfrUowIlxYyZ7Xx0cVBV9sL2PT8LYTW+mlg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: fdfe9307-68a0-4054-6746-08d6576c4528 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1357; x-ms-traffictypediagnostic: VI1PR0801MB1357: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231454)(999002)(944501474)(52105112)(10201501046)(93006095)(93001095)(3002001)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1357; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1357; x-forefront-prvs: 087396016C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(346002)(376002)(39860400002)(40434004)(189003)(199004)(365934003)(53754006)(5024004)(3846002)(790700001)(6436002)(66066001)(81166006)(6116002)(8936002)(8676002)(81156014)(53936002)(186003)(102836004)(53546011)(55016002)(6506007)(236005)(14454004)(54896002)(6306002)(9686003)(14444005)(26005)(66574009)(7110500001)(86362001)(15650500001)(97736004)(33656002)(561944003)(256004)(606006)(71200400001)(71190400001)(2420400007)(68736007)(106356001)(105586002)(110136005)(316002)(25786009)(5660300001)(54906003)(4326008)(11346002)(76176011)(99286004)(446003)(476003)(486006)(229853002)(7736002)(93886005)(6246003)(2906002)(53386004)(53376002)(7696005)(74316002)(966005)(72206003)(45080400002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1357; H:VI1PR0801MB2112.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-microsoft-antispam-message-info: E7I5WzVJv79YDBn+jrlN1fgVUNVzvGyNEud89b06cs28l3AXDeAaemVPiPErmAuz1HnayI4Uc1ClzWHtQ8ducOxcZmq4jM4QTHlVJXh46nwMBFnmgjurb+NOtcKHJpiYdIdmmH3D5FpGKY0FTYLhpmcnMlNOY/8H5MaWbC7XSd5d0miB/TCtxeEXmEzfNEn87oLmrWlxPZwTRrkITIqNGIbU6WR2LaWwNcWFdeizdK4JaeZPOazsxdIFm+8li0fLjESBOLUDd/v4je8jO6whLX53piQ+I4ywxMinkhrT02IPsfjaJSXBaJwJt4kVwHtbgfB5bd2oj+noIyawzHZvVjYTy2YtkZfeFObmTM4R5Mc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21120AA6CC9437E237F481A2FAAC0VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: fdfe9307-68a0-4054-6746-08d6576c4528 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2018 09:06:24.6082 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1357 Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 01 Dec 2018 09:06:33 -0000 --_000_VI1PR0801MB21120AA6CC9437E237F481A2FAAC0VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEFhcm9uIGhlcmUgYW5kIEkgdGhpbmsgU2VjdGlvbiAzLjguMS4yPGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0x MCNzZWN0aW9uLTMuOC4xLjI+IG9mIGRyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTEw ICBhbHJlYWR5IGRvZXMgYSBwcmV0dHkgZ29vZCBqb2IuDQpJIHdhcywgaG93ZXZlciwgd29uZGVy aW5nIGFib3V0IHRoZSBzdWJ0bGUgaW1wbGljYXRpb24gb2YgdGhlIHJlcXVpcmVtZW50IGZvciBz ZW5kZXIgY29uc3RyYWluZWQgdG9rZW5zLiBNeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSB0b2tlbiBi aW5kaW5nIGRpc2N1c3Npb24sIHdoaWNoIGlzIG9uZSBvZiB0aGUgd2F5cyB0byBwcm92aWRlIHNl bmRlci1jb25zdHJhaW5lZCB0b2tlbnMsIGlzIHRoYXQgd2UgZG9u4oCZdCBoYXZlIGdvb2QgZmFp dGggaW4gc2VlaW5nIGRlcGxveW1lbnQgYW55dGltZSBzb29uLiBIZW5jZSwgd2UgYXJlIGVzc2Vu dGlhbGx5IChyZWFkaW5nIGluIGJldHdlZW4gdGhlIGxpbmVzIG9mIFNlY3Rpb24gMy44LjEuMikg c2F5aW5nIHRoYXQgeW91IGNhbm5vdCB1c2UgaW1wbGljaXQgZ3JhbnQgaW4gYSBwcmFjdGljYWwg c2V0dXAgZm9yIHRoZSB3ZWIqLg0KDQpBbSBJIG1pc3VuZGVyc3RhbmRpbmcgaXQ/DQoNCkNpYW8N Ckhhbm5lcw0KDQpQUzogVGhlIElvVCBjYXNlIGlzIGxpa2VseSBkaWZmZXJlbnQuDQoNCkZyb206 IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQWFyb24gUGFyZWNr aQ0KU2VudDogU2F0dXJkYXksIERlY2VtYmVyIDEsIDIwMTggMzoxOCBBTQ0KVG86IFRvcnN0ZW4g TG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pg0KQ2M6IERhbmllbCBGZXR0IDxm ZXR0QGRhbmllbGZldHQuZGU+OyBJRVRGIG9hdXRoIFdHIDxvYXV0aEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIFNlY3VyaXR5IFRvcGljcyAtLSBSZWNvbW1lbmQgYXV0 aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2YgaW1wbGljaXQNCg0KKzENCg0KSSB3b3VsZCBhbHNv IGxpa2UgdG8gZW5zdXJlIHRoZXJlIGlzIGEgY2xlYXIgZGVmaW5pdGlvbiBvZiAic2VuZGVyIGNv bnN0cmFpbmVkIiB0b2tlbnMgaW4gdGhpcyBCQ1AuDQoNCkFhcm9uDQoNCg0KT24gVGh1LCBOb3Yg MjksIDIwMTggYXQgMTA6MDYgQU0gVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJz dGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj4gd3JvdGU6DQpIaSBhbGws DQoNCmJhc2VkIG9uIHlvdXIgZmVlZGJhY2sgb24gdGhlIGxpc3QgYW5kIG9mZiBsaXN0LCBEYW5p ZWwgYW5kIEkgcG9saXNoZWQgdGhlIHRleHQuIFRoYXTigJlzIG91ciBwcm9wb3NhbDoNCg0K4oCU DQpJbiBvcmRlciB0byBhdm9pZCB0aGVzZSBpc3N1ZXMsIGNsaWVudHMgTVVTVCBOT1QgdXNlIHRo ZSBpbXBsaWNpdA0KZ3JhbnQgKHJlc3BvbnNlIHR5cGUgInRva2VuIikgb3IgYW55IG90aGVyIHJl c3BvbnNlIHR5cGUgaXNzdWluZyBhY2Nlc3MNCnRva2VucyBpbiB0aGUgYXV0aG9yaXphdGlvbiBy ZXNwb25zZSwgc3VjaCBhcyAidG9rZW4gaWRfdG9rZW4iIGFuZCAiY29kZSB0b2tlbiBpZF90b2tl buKAnCwNCnVubGVzcyB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbnMgYXJlIHNlbmRlci1jb25zdHJh aW5lZCBhbmQgYWNjZXNzIHRva2VuIGluamVjdGlvbiBpbg0KdGhlIGF1dGhvcml6YXRpb24gcmVz cG9uc2UgaXMgcHJldmVudGVkLg0K4oCUDQoNCkV4cGxhbnRhdGlvbjoNCi0gd2Ugd2FudGVkIHRv IGhhdmUgdGhlIHJpZ2h0IGJhbGFuY2UgYmV0d2VlbiBhIGdlbmVyaWMgZGVmaW5pdGlvbiBvZiB0 aGUgcmVzcG9uc2UgdHlwZXMgd2UgZG8gbm90IHJlY29tbWVuZC9hbGxvdyB0byBiZSB1c2VkIGFu ZCBhIGNvbmNyZXRlL2FjdGlvbmFibGUgbGlzdCBvZiB0aGUgYWZmZWN0ZWQgcmVzcG9uc2UgdHlw ZXMuDQotIHdlIGNoYW5nZWQgZnJvbSBTSE9VTEQgTk9UIHRvIE1VU1QgTk9UIGFzIHN1Z2dlc3Rl ZCBieSBOYXQgYW5kIHN1cHBvcnRlZCBieSBXaWxsaWFtDQoNCldlIGxvb2sgZm9yd2FyZCB0byBz ZWVpbmcgeW91ciBmZWVkYmFjay4NCg0Ka2luZCByZWdhcmRzLA0KVG9yc3Rlbi4NCg0KPiBBbSAy OS4xMS4yMDE4IHVtIDE1OjE1IHNjaHJpZWIgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNv bTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PjoNCj4NCj4gSSBhbSBvayB3aXRoIHRoYXQuDQo+ DQo+IE9uIFdlZCwgTm92IDI4LCAyMDE4LCA4OjAzIFBNIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRv cnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3Jv dGU6DQo+DQo+ID4gQW0gMjguMTEuMjAxOCB1bSAyMzo1MCBzY2hyaWViIG4tc2FraW11cmEgPG4t c2FraW11cmFAbnJpLmNvLmpwPG1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5qcD4+Og0KPiA+DQo+ ID4gVGhhdCB3b3Jrcy4NCj4NCj4gR29vZCENCj4NCj4gSSBqdXN0IHJlYWxpemVkIHRoaXMgdGV4 dCBoYXMgYW4gaXNzdWUgd2l0aCDigJ50b2tlbuKAnCAob25seSkuIEl0IHdvdWxkIGFsbG93IOKA nnRva2Vu4oCcIHRvIGJlIHVzZWQgaWYgdGhlIHRva2VuIHdvdWxkIHNlbmRlciBjb25zdHJhaW5l ZC4gVGhpcyBjb21wbGV0ZWx5IGlnbm9yZXMgdGhlIGZhY3QgaW1wbGljaXQgYWxzbyBzaGFsbCBi ZSBhYmFuZG9uZWQgYmVjYXVzZSBvZiBpdHMgdnVsbmVyYWJpbGl0eSBmb3IgYWNjZXNzIHRva2Vu IGluamVjdGlvbi4NCj4NCj4gSSB0aGVyZWZvcmUgcHJvcG9zZSBhIG1vZGlmaWVkIHRleHQ6DQo+ DQo+ICAgIEluIG9yZGVyIHRvIGF2b2lkIHRoZXNlIGlzc3VlcywgQ2xpZW50cyBTSE9VTEQgTk9U IHVzZSB0aGUgaW1wbGljaXQNCj4gICAgZ3JhbnQuIEZ1cnRoZXJtb3JlLCBjbGllbnRzIFNIT1VM RCBvbmx5IHVzZSBvdGhlciByZXNwb25zZSB0eXBlcyBjYXVzaW5nIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciB0bw0KPiAgICBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gaW4gdGhlIGF1dGhvcml6YXRp b24gcmVzcG9uc2UsIGlmIHRoZSBwYXJ0aWN1bGFyIHJlc3BvbnNlIHR5cGUgZGV0ZWN0cyBhY2Nl c3MgdG9rZW4NCj4gICAgaW5qZWN0aW9uIGFuZCB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbnMgYXJl IHNlbmRlci1jb25zdHJhaW5lZC4NCj4NCj4gT3Igd2UganVzdCBzdGF0ZToNCj4NCj4gICBJbiBv cmRlciB0byBhdm9pZCB0aGVzZSBpc3N1ZXMsIENsaWVudHMgU0hPVUxEIE5PVCB1c2UgdGhlIHJl c3BvbnNlIHR5cGUg4oCedG9rZW4iLiBUaGUgcmVzcG9uc2UgdHlwZXMNCj4g4oCedG9rZW4gaWRf dG9rZW7igJwgYW5kIOKAnmNvZGUgdG9rZW4gaWRfdG9rZW7igJwgU09VTEQgTk9UIGJlIHVzZWQs IGlmIHRoZSBpc3N1ZWQgYWNjZXNzIHRva2VucyBhcmUgbm90DQo+IHNlbmRlci1jb25zdHJhaW5l ZC4NCj4NCj4gPg0KPiA+IEluIGZhY3QsIEkgd291bGQgZnVydGhlciBnbyBhbmQgc2F5IE1VU1Qg Tk9UIGJ1dCB0aGF0IHByb2JhYmx5IGlzIHRvbyBtdWNoIGZvciBhIHNlY3VyaXR5IGNvbnNpZGVy YXRpb24uDQo+ID4NCj4NCj4gTWlrZSBzdWdnZXN0ZWQgdG8gZ28gd2l0aCBhIFNIT1VMRCBOT1Qg dG8gZ2V0IHRoZSBtZXNzYWdlIG91dCBidXQgZ2l2ZSBpbXBsZW1lbnRvcnMgdGltZSB0byBtb3Zl L2NoYW5nZS4NCj4NCj4gPiBCZXN0LA0KPiA+DQo+ID4gTmF0DQo+ID4NCj4gPiBOYXQgU2FraW11 cmEgLyBuLXNha2ltdXJhQG5yaS5jby5qcDxtYWlsdG86bi1zYWtpbXVyYUBucmkuY28uanA+IC8g KzgxLTkwLTYwMTMtNjI3Ng0KPiA+DQo+ID4g44GT44Gu44Oh44O844Or44Gr44Gv44CB5pys5p2l 44Gu5a6b5YWI44Gu5pa544Gu44G/44Gr6ZmQ5a6a44GV44KM44Gf5qmf5a+G5oOF5aCx44GM5ZCr 44G+44KM44Gm44GE44KL5aC05ZCI44GM44GU44GW44GE44G+44GZ44CC44GK5b+D44GC44Gf44KK 44Gu44Gq44GE5aC05ZCI44Gv44CB6Kqg44Gr55Sz44GX6Kiz44GU44GW44GE44G+44Gb44KT44GM 44CB6YCB5L+h6ICF44G+44Gn44GK55+l44KJ44Gb6aCC44GN44CB44G+44Gf5Y+X5L+h44GV44KM 44Gf44Oh44O844Or44Gv5YmK6Zmk44GX44Gm44GP44Gg44GV44GE44G+44GZ44KI44GG44GK6aGY 44GE55Sz44GX5LiK44GS44G+44GZ44CCDQo+ID4NCj4gPiBQTEVBU0UgUkVBRCA6VGhpcyBlLW1h aWwgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudCBv bmx5Lg0KPiA+IElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBlLW1haWwuDQo+ID4NCj4gPiDlt67lh7rk uro6IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4+DQo+ID4g6YCB5L+h5pel5pmCOiDmsLTmm5zml6UsIDEx 5pyIIDI4LCAyMDE4IDExOjM4IOWNiOW+jA0KPiA+IOWum+WFiDogbi1zYWtpbXVyYQ0KPiA+IENj OiBEaWNrIEhhcmR0OyBIYW5uZXMgVHNjaG9mZW5pZzsgb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9h dXRoQGlldGYub3JnPg0KPiA+IOS7tuWQjTogUmU6IFtPQVVUSC1XR10gT0F1dGggU2VjdXJpdHkg VG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNp dA0KPiA+DQo+ID4gSGkgTmF0LA0KPiA+DQo+ID4+IEFtIDI4LjExLjIwMTggdW0gMjE6MTAgc2No cmllYiBuLXNha2ltdXJhIDxuLXNha2ltdXJhQG5yaS5jby5qcDxtYWlsdG86bi1zYWtpbXVyYUBu cmkuY28uanA+PjoNCj4gPj4NCj4gPj4gSSB3b3VsZCBzdXBwb3J0DQo+ID4+DQo+ID4+IDEpIGNs ZWFybHkgZGVmaW5pbmcgSW1wbGljaXQgYXMgdGhlIGZsb3cgdGhhdCByZXR1cm5zIGFjY2VzcyB0 b2tlbiBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50ICggc29tZSBwZW9wbGUgY29uZnVz ZXMgaW1wbGljaXQgYXMgdGhlIGZsb3cgdGhhdCByZXR1cm5zIElEIFRva2VuIGluIHRoZSBmcm9u dCBjaGFubmVsKQ0KPiA+DQo+ID4gVGhhdOKAmXMgdGhlIGN1cnJlbnQgdGV4dDoNCj4gPg0KPiA+ IEluIG9yZGVyIHRvIGF2b2lkIHRoZXNlIGlzc3VlcywgQ2xpZW50cyBTSE9VTEQgTk9UIHVzZSB0 aGUgaW1wbGljaXQNCj4gPiAgICBncmFudCBvciBhbnkgb3RoZXIgcmVzcG9uc2UgdHlwZSBjYXVz aW5nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0bw0KPiA+ICAgIGlzc3VlIGFuIGFjY2VzcyB0 b2tlbiBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZS4NCj4gPg0KPiA+IFdoYXQgd291bGQg eW91IGxpa2UgdG8gbW9kaWZ5Pw0KPiA+DQo+ID4+DQo+ID4+IDIpIEJhbm5pbmcgdGhlIHJldHVy bmluZyBvZiB0aGUgYWNjZXNzIHRva2VuIHRoYXQgYXJlIG5vdCBzZW5kZXIgY29uc3RyYWluZWQg ZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludA0KPiA+DQo+ID4gSW4gb3JkZXIgdG8gYXZv aWQgdGhlc2UgaXNzdWVzLCBDbGllbnRzIFNIT1VMRCBOT1QgdXNlIHRoZSBpbXBsaWNpdA0KPiA+ ICAgIGdyYW50IG9yIGFueSBvdGhlciByZXNwb25zZSB0eXBlIGNhdXNpbmcgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIHRvDQo+ID4gICAgaXNzdWUgYW4gYWNjZXNzIHRva2VuIGluIHRoZSBhdXRo b3JpemF0aW9uIHJlc3BvbnNlLCBpZiB0aGlzIGFjY2VzcyB0b2tlbnMgaXMgbm90IHNlbmRlci1j b25zdHJhaW50Lg0KPiA+DQo+ID4gV2hhdCBhYm91dCB0aGlzPw0KPiA+DQo+ID4ga2luZCByZWdh cmRzLA0KPiA+IFRvcnN0ZW4uDQo+ID4NCj4gPj4NCj4gPj4gQmVzdCwNCj4gPj4NCj4gPj4gTmF0 DQo+ID4+DQo+ID4+DQo+ID4+IE91dGxvb2sgZm9yIGlPUyDjgpLlhaXmiYsNCj4gPj4NCj4gPj4g 5beu5Ye65Lq6OiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZz4+IChEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86 ZGljay5oYXJkdEBnbWFpbC5jb20+PiDjga7ku6PnkIYpDQo+ID4+IOmAgeS/oeaXpeaZgjog5rC0 5puc5pelLCAxMeaciCAyOCwgMjAxOCA4OjU4IOWNiOW+jA0KPiA+PiDlrpvlhYg6IEhhbm5lcyBU c2Nob2ZlbmlnDQo+ID4+IENjOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+ DQo+ID4+IOS7tuWQjTogUmU6IFtPQVVUSC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNzIC0tIFJl Y29tbWVuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNpdA0KPiA+Pg0KPiA+ PiArMQ0KPiA+Pg0KPiA+PiBXaGlsZSB0aGVyZSBhcmUgdmFyaW91cyBtZWNoYW5pc21zIHRvIGFs bGV2aWF0ZSBzb21lIG9mIHRoZSBpc3N1ZXMgb2YgaW1wbGljaXQsIEkgZG9uJ3QgdGhpbmsgd2Ug Y2FuIHJlY29tbWVuZCBzcGVjaWZpY3MsIGFuZCB0aGVyZSBtYXkgYmUgZnV0dXJlIG9uZXMgaW4g dGhlIGZ1dHVyZS4gSSB0aGluayB3ZSBhbGwgYWdyZWUgdGhhdCBpbXBsaWNpdCB3aXRob3V0IGFu eSBtaXRpZ2F0aW9uIGlzIHByb2JsZW1hdGljLg0KPiA+Pg0KPiA+PiBIb3cgYWJvdXQgd2UgcmVj b21tZW5kIGFnYWluc3QgdXNpbmcgaW1wbGljaXQgYWxvbmU/DQo+ID4+DQo+ID4+DQo+ID4+IE9u IE1vbiwgTm92IDE5LCAyMDE4IGF0IDI6MzQgQU0gSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5U c2Nob2ZlbmlnQGFybS5jb208bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+PiB3cm90 ZToNCj4gPj4gSGkgYWxsLA0KPiA+Pg0KPiA+PiBUaGUgYXV0aG9ycyBvZiB0aGUgT0F1dGggU2Vj dXJpdHkgVG9waWNzIGRyYWZ0IGNhbWUgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCBpdCBpcyBub3Qg cG9zc2libGUgdG8gYWRlcXVhdGVseSBzZWN1cmUgdGhlIGltcGxpY2l0IGZsb3cgYWdhaW5zdCB0 b2tlbiBpbmplY3Rpb24gc2luY2UgcG90ZW50aWFsIHNvbHV0aW9ucyBsaWtlIHRva2VuIGJpbmRp bmcgb3IgSkFSTSBhcmUgaW4gYW4gZWFybHkgc3RhZ2Ugb2YgYWRvcHRpb24uIEZvciB0aGlzIHJl YXNvbiwgYW5kIHNpbmNlIENPUlMgYWxsb3dzIGJyb3dzZXItYmFzZWQgYXBwcyB0byBzZW5kIHJl cXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludCwgVG9yc3RlbiBzdWdnZXN0ZWQgdG8gdXNlIHRo ZSBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiB0aGUgaW1wbGljaXQgZ3JhbnQgaW4gY2Fs bCBjYXNlcyBpbiBoaXMgcHJlc2VudGF0aW9uIChzZWUgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEwMy1vYXV0aC1zZXNzYi1kcmFmdC1p ZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0wMSkuDQo+ID4+DQo+ID4+IEEgaHVtIGluIHRoZSBy b29tIGF0IElFVEYjMTAzIGNvbmNsdWRlZCBzdHJvbmcgc3VwcG9ydCBmb3IgaGlzIHJlY29tbWVu ZGF0aW9ucy4gV2Ugd291bGQgbGlrZSB0byBjb25maXJtIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBs aXN0Lg0KPiA+Pg0KPiA+PiBQbGVhc2UgcHJvdmlkZSBhIHJlc3BvbnNlIGJ5IERlY2VtYmVyIDNy ZC4NCj4gPj4NCj4gPj4gQ2lhbw0KPiA+Pg0KPiA+PiBIYW5uZXMgJiBSaWZhYXQNCj4gPj4NCj4g Pj4NCj4gPj4NCj4gPj4gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBw cml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29u dGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3Rv cmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPiA+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBP QXV0aCBtYWlsaW5nIGxpc3QNCj4gPj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu b3JnPg0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0 Zi5vcmc+DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN Cj4gPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll dGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBt YWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCi0tDQotLS0tDQpBYXJvbiBQ YXJlY2tpDQphYXJvbnBhcmVja2kuY29tPGh0dHA6Ly9hYXJvbnBhcmVja2kuY29tPg0KQGFhcm9u cGs8aHR0cDovL3R3aXR0ZXIuY29tL2Fhcm9ucGs+DQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBj b250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlh bCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBu b3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3Ig YW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRp dW0uIFRoYW5rIHlvdS4NCg== --_000_VI1PR0801MB21120AA6CC9437E237F481A2FAAC0VI1PR0801MB2112_ 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 Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpoNQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsN Cgltc28tc3R5bGUtbGluazoiSGVhZGluZyA1IENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhlYWRpbmc1Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiSGVhZGluZyA1IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1z dHlsZS1saW5rOiJIZWFkaW5nIDUiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8aDUgc3R5bGU9Im1zby1saW5lLWhlaWdodC1h bHQ6MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LXdlaWdodDpub3JtYWwi PkkgYWdyZWUgd2l0aCBBYXJvbiBoZXJlIGFuZCBJIHRoaW5rDQo8YSBuYW1lPSJzZWN0aW9uLTMu OC4xLjIiPlNlY3Rpb24gPC9hPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xMCNzZWN0aW9uLTMuOC4xLjIiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6JnF1b3Q7c2VjdGlvbi0zXC44XC4xXC4yJnF1b3Q7Ij48c3Bh biBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjMuOC4xLjI8L3NwYW4+PC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOiZxdW90O3NlY3Rpb24tM1wuOFwuMVwuMiZxdW90OyI+ PC9zcGFuPg0KIG9mIGRyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTEwICZuYnNwO2Fs cmVhZHkgZG9lcyBhIHByZXR0eSBnb29kIGpvYi4gPG86cD48L286cD48L3NwYW4+PC9oNT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgd2FzLCBob3dldmVyLCB3b25kZXJpbmcgYWJvdXQgdGhlIHN1 YnRsZSBpbXBsaWNhdGlvbiBvZiB0aGUgcmVxdWlyZW1lbnQgZm9yIHNlbmRlciBjb25zdHJhaW5l ZCB0b2tlbnMuIE15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHRva2VuIGJpbmRpbmcgZGlzY3Vzc2lv biwgd2hpY2ggaXMgb25lIG9mIHRoZSB3YXlzIHRvIHByb3ZpZGUgc2VuZGVyLWNvbnN0cmFpbmVk IHRva2VucywgaXMgdGhhdCB3ZSBkb27igJl0IGhhdmUNCiBnb29kIGZhaXRoIGluIHNlZWluZyBk ZXBsb3ltZW50IGFueXRpbWUgc29vbi4gSGVuY2UsIHdlIGFyZSBlc3NlbnRpYWxseSAocmVhZGlu ZyBpbiBiZXR3ZWVuIHRoZSBsaW5lcyBvZiBTZWN0aW9uIDMuOC4xLjIpIHNheWluZyB0aGF0IHlv dSBjYW5ub3QgdXNlIGltcGxpY2l0IGdyYW50IGluIGEgcHJhY3RpY2FsIHNldHVwIGZvciB0aGUg d2ViKi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW0gSSBtaXN1bmRlcnN0YW5kaW5nIGl0Pzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaWFvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IYW5uZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UFM6IFRoZSBJb1QgY2FzZSBp cyBsaWtlbHkgZGlmZmVyZW50LiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IE9BdXRoICZsdDtv YXV0aC1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5BYXJvbiBQYXJl Y2tpPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBEZWNlbWJlciAxLCAyMDE4IDM6MTggQU08 YnI+DQo8Yj5Ubzo8L2I+IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gRGFuaWVsIEZldHQgJmx0O2ZldHRAZGFuaWVsZmV0 dC5kZSZndDs7IElFVEYgb2F1dGggV0cgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCBTZWN1cml0eSBUb3BpY3MgLS0gUmVjb21t ZW5kIGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIGltcGxpY2l0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgYWxzbyBs aWtlIHRvIGVuc3VyZSB0aGVyZSBpcyBhIGNsZWFyIGRlZmluaXRpb24gb2YgJnF1b3Q7c2VuZGVy IGNvbnN0cmFpbmVkJnF1b3Q7IHRva2VucyBpbiB0aGlzIEJDUC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWFyb248bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgTm92IDI5LCAy MDE4IGF0IDEwOjA2IEFNIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIGFsbCwgPGJyPg0KPGJyPg0KYmFzZWQgb24geW91ciBmZWVkYmFjayBvbiB0aGUg bGlzdCBhbmQgb2ZmIGxpc3QsIERhbmllbCBhbmQgSSBwb2xpc2hlZCB0aGUgdGV4dC4gVGhhdOKA mXMgb3VyIHByb3Bvc2FsOjxicj4NCjxicj4NCuKAlDxicj4NCkluIG9yZGVyIHRvIGF2b2lkIHRo ZXNlIGlzc3VlcywgY2xpZW50cyBNVVNUIE5PVCB1c2UgdGhlIGltcGxpY2l0PGJyPg0KZ3JhbnQg KHJlc3BvbnNlIHR5cGUgJnF1b3Q7dG9rZW4mcXVvdDspIG9yIGFueSBvdGhlciByZXNwb25zZSB0 eXBlIGlzc3VpbmcgYWNjZXNzIDxicj4NCnRva2VucyBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNw b25zZSwgc3VjaCBhcyAmcXVvdDt0b2tlbiBpZF90b2tlbiZxdW90OyBhbmQgJnF1b3Q7Y29kZSB0 b2tlbiBpZF90b2tlbuKAnCwNCjxicj4NCnVubGVzcyB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbnMg YXJlIHNlbmRlci1jb25zdHJhaW5lZCBhbmQgYWNjZXNzIHRva2VuIGluamVjdGlvbiBpbg0KPGJy Pg0KdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UgaXMgcHJldmVudGVkLiA8YnI+DQrigJQ8YnI+ DQo8YnI+DQpFeHBsYW50YXRpb246IDxicj4NCi0gd2Ugd2FudGVkIHRvIGhhdmUgdGhlIHJpZ2h0 IGJhbGFuY2UgYmV0d2VlbiBhIGdlbmVyaWMgZGVmaW5pdGlvbiBvZiB0aGUgcmVzcG9uc2UgdHlw ZXMgd2UgZG8gbm90IHJlY29tbWVuZC9hbGxvdyB0byBiZSB1c2VkIGFuZCBhIGNvbmNyZXRlL2Fj dGlvbmFibGUgbGlzdCBvZiB0aGUgYWZmZWN0ZWQgcmVzcG9uc2UgdHlwZXMuDQo8YnI+DQotIHdl IGNoYW5nZWQgZnJvbSBTSE9VTEQgTk9UIHRvIE1VU1QgTk9UIGFzIHN1Z2dlc3RlZCBieSBOYXQg YW5kIHN1cHBvcnRlZCBieSBXaWxsaWFtPGJyPg0KPGJyPg0KV2UgbG9vayBmb3J3YXJkIHRvIHNl ZWluZyB5b3VyIGZlZWRiYWNrLjxicj4NCjxicj4NCmtpbmQgcmVnYXJkcyw8YnI+DQpUb3JzdGVu LiZuYnNwOyA8YnI+DQo8YnI+DQomZ3Q7IEFtIDI5LjExLjIwMTggdW0gMTU6MTUgc2NocmllYiBK b2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEkgYW0gb2sgd2l0aCB0aGF0LiZuYnNwOyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gV2VkLCBO b3YgMjgsIDIwMTgsIDg6MDMgUE0gVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0ibWFp bHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9yc3RlbkBsb2Rk ZXJzdGVkdC5uZXQ8L2E+IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEFtIDI4LjEx LjIwMTggdW0gMjM6NTAgc2NocmllYiBuLXNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86bi1z YWtpbXVyYUBucmkuY28uanAiIHRhcmdldD0iX2JsYW5rIj5uLXNha2ltdXJhQG5yaS5jby5qcDwv YT4mZ3Q7Ojxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhhdCB3b3Jrcy48YnI+DQom Z3Q7IDxicj4NCiZndDsgR29vZCE8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBqdXN0IHJlYWxpemVk IHRoaXMgdGV4dCBoYXMgYW4gaXNzdWUgd2l0aCDigJ50b2tlbuKAnCAob25seSkuIEl0IHdvdWxk IGFsbG93IOKAnnRva2Vu4oCcIHRvIGJlIHVzZWQgaWYgdGhlIHRva2VuIHdvdWxkIHNlbmRlciBj b25zdHJhaW5lZC4gVGhpcyBjb21wbGV0ZWx5IGlnbm9yZXMgdGhlIGZhY3QgaW1wbGljaXQgYWxz byBzaGFsbCBiZSBhYmFuZG9uZWQgYmVjYXVzZSBvZiBpdHMgdnVsbmVyYWJpbGl0eSBmb3IgYWNj ZXNzIHRva2VuIGluamVjdGlvbi4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHRoZXJlZm9yZSBw cm9wb3NlIGEgbW9kaWZpZWQgdGV4dDogPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyBJbiBvcmRlciB0byBhdm9pZCB0aGVzZSBpc3N1ZXMsIENsaWVudHMgU0hPVUxEIE5PVCB1c2Ug dGhlIGltcGxpY2l0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgZ3JhbnQuIEZ1cnRoZXJtb3JlLCBj bGllbnRzIFNIT1VMRCBvbmx5IHVzZSBvdGhlciByZXNwb25zZSB0eXBlcyBjYXVzaW5nIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciB0bzxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGlzc3VlIGFuIGFj Y2VzcyB0b2tlbiBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSwgaWYgdGhlIHBhcnRpY3Vs YXIgcmVzcG9uc2UgdHlwZSBkZXRlY3RzIGFjY2VzcyB0b2tlbg0KPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgaW5qZWN0aW9uIGFuZCB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbnMgYXJlIHNlbmRlci1j b25zdHJhaW5lZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgT3Igd2UganVzdCBzdGF0ZTo8YnI+DQom Z3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7SW4gb3JkZXIgdG8gYXZvaWQgdGhlc2UgaXNzdWVz LCBDbGllbnRzIFNIT1VMRCBOT1QgdXNlIHRoZSByZXNwb25zZSB0eXBlIOKAnnRva2VuJnF1b3Q7 LiBUaGUgcmVzcG9uc2UgdHlwZXM8YnI+DQomZ3Q7IOKAnnRva2VuIGlkX3Rva2Vu4oCcIGFuZCDi gJ5jb2RlIHRva2VuIGlkX3Rva2Vu4oCcIFNPVUxEIE5PVCBiZSB1c2VkLCBpZiB0aGUgaXNzdWVk IGFjY2VzcyB0b2tlbnMgYXJlIG5vdA0KPGJyPg0KJmd0OyBzZW5kZXItY29uc3RyYWluZWQuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEluIGZhY3QsIEkgd291bGQg ZnVydGhlciBnbyBhbmQgc2F5IE1VU1QgTk9UIGJ1dCB0aGF0IHByb2JhYmx5IGlzIHRvbyBtdWNo IGZvciBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24uPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyBNaWtlIHN1Z2dlc3RlZCB0byBnbyB3aXRoIGEgU0hPVUxEIE5PVCB0byBnZXQg dGhlIG1lc3NhZ2Ugb3V0IGJ1dCBnaXZlIGltcGxlbWVudG9ycyB0aW1lIHRvIG1vdmUvY2hhbmdl Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEJlc3QsPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyBOYXQ8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE5hdCBTYWtpbXVyYSAv IDxhIGhyZWY9Im1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5qcCIgdGFyZ2V0PSJfYmxhbmsiPm4t c2FraW11cmFAbnJpLmNvLmpwPC9hPiAvICYjNDM7ODEtOTAtNjAxMy02Mjc2PGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyA8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5 OkRlbmdYaWFuIj7jgZPjga7jg6Hjg7zjg6vjgavjga/jgIHmnKzmnaXjga7lrpvlhYjjga7mlrnj ga7jgb/jgavpmZDlrprjgZXjgozjgZ/mqZ/lr4bmg4XloLHjgYzlkKvjgb7jgozjgabjgYTjgovl oLTlkIjjgYzjgZTjgZbjgYTjgb7jgZnjgILjgYrlv4PjgYLjgZ/jgorjga7jgarjgYTloLTlkIjj ga/jgIHoqqDjgavnlLPjgZfoqLPjgZTjgZbjgYTjgb7jgZvjgpPjgYzjgIHpgIHkv6HogIXjgb7j gafjgYrnn6XjgonjgZvpoILjgY3jgIHjgb7jgZ/lj5fkv6HjgZXjgozjgZ/jg6Hjg7zjg6vjga/l iYrpmaTjgZfjgabjgY/jgaDjgZXjgYTjgb7jgZnjgojjgYbjgYrpoZjjgYTnlLPjgZfkuIrjgZLj gb7jgZnjgII8L3NwYW4+PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBQTEVBU0UgUkVB RCA6VGhpcyBlLW1haWwgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhlIG5hbWVk IHJlY2lwaWVudCBvbmx5Ljxicj4NCiZndDsgJmd0OyBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgZS1t YWlsLjxicj4NCiZndDsgJmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgPHNwYW4gbGFuZz0iWkgt Q04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+5beu5Ye65Lq6PC9zcGFuPjogVG9yc3Rl biBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0 IiB0YXJnZXQ9Il9ibGFuayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0Ozxicj4NCiZn dDsgJmd0OyA8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OkRlbmdYaWFuIj7p gIHkv6Hml6XmmYI8L3NwYW4+OiA8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5 OkRlbmdYaWFuIj4NCuawtOabnOaXpTwvc3Bhbj4sIDExPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxl PSJmb250LWZhbWlseTpEZW5nWGlhbiI+5pyIPC9zcGFuPiAyOCwgMjAxOCAxMTozOA0KPHNwYW4g bGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+5Y2I5b6MPC9zcGFuPjxi cj4NCiZndDsgJmd0OyA8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OkRlbmdY aWFuIj7lrpvlhYg8L3NwYW4+OiBuLXNha2ltdXJhPGJyPg0KJmd0OyAmZ3Q7IENjOiBEaWNrIEhh cmR0OyBIYW5uZXMgVHNjaG9mZW5pZzsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+DQpvYXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgPHNwYW4g bGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+5Lu25ZCNPC9zcGFuPjog UmU6IFtPQVVUSC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3Jp emF0aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNpdDxicj4NCiZndDsgJmd0OyZuYnNwOyA8YnI+ DQomZ3Q7ICZndDsgSGkgTmF0LCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBB bSAyOC4xMS4yMDE4IHVtIDIxOjEwIHNjaHJpZWIgbi1zYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFp bHRvOm4tc2FraW11cmFAbnJpLmNvLmpwIiB0YXJnZXQ9Il9ibGFuayI+bi1zYWtpbXVyYUBucmku Y28uanA8L2E+Jmd0Ozo8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgSSB3 b3VsZCBzdXBwb3J0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDEpIGNs ZWFybHkgZGVmaW5pbmcgSW1wbGljaXQgYXMgdGhlIGZsb3cgdGhhdCByZXR1cm5zIGFjY2VzcyB0 b2tlbiBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50ICggc29tZSBwZW9wbGUgY29uZnVz ZXMgaW1wbGljaXQgYXMgdGhlIGZsb3cgdGhhdCByZXR1cm5zIElEIFRva2VuIGluIHRoZSBmcm9u dCBjaGFubmVsKTxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhhdOKAmXMgdGhlIGN1 cnJlbnQgdGV4dDogPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJbiBvcmRlciB0byBh dm9pZCB0aGVzZSBpc3N1ZXMsIENsaWVudHMgU0hPVUxEIE5PVCB1c2UgdGhlIGltcGxpY2l0PGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBncmFudCBvciBhbnkgb3RoZXIgcmVzcG9uc2UgdHlw ZSBjYXVzaW5nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0bzxicj4NCiZndDsgJmd0OyZuYnNw OyAmbmJzcDsgaXNzdWUgYW4gYWNjZXNzIHRva2VuIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3Bv bnNlLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgV2hhdCB3b3VsZCB5b3UgbGlrZSB0 byBtb2RpZnk/IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsg Jmd0OyZndDsgMikgQmFubmluZyB0aGUgcmV0dXJuaW5nIG9mIHRoZSBhY2Nlc3MgdG9rZW4gdGhh dCBhcmUgbm90IHNlbmRlciBjb25zdHJhaW5lZCBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGVuZHBv aW50PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJbiBvcmRlciB0byBhdm9pZCB0aGVz ZSBpc3N1ZXMsIENsaWVudHMgU0hPVUxEIE5PVCB1c2UgdGhlIGltcGxpY2l0PGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyBncmFudCBvciBhbnkgb3RoZXIgcmVzcG9uc2UgdHlwZSBjYXVzaW5n IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0bzxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsg aXNzdWUgYW4gYWNjZXNzIHRva2VuIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlLCBpZiB0 aGlzIGFjY2VzcyB0b2tlbnMgaXMgbm90IHNlbmRlci1jb25zdHJhaW50Ljxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgV2hhdCBhYm91dCB0aGlzPzxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsga2luZCByZWdhcmRzLDxicj4NCiZndDsgJmd0OyBUb3JzdGVuLjxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgQmVzdCw8YnI+DQom Z3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgTmF0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgT3V0bG9vayBmb3IgaU9TIDxz cGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6RGVuZ1hpYW4iPuOCkuWFpeaJizwv c3Bhbj48YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0OyZndDsgPHNwYW4g bGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+5beu5Ye65Lq6PC9zcGFu PjogT0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IChEaWNrIEhhcmR0ICZs dDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5k aWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7DQo8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZv bnQtZmFtaWx5OkRlbmdYaWFuIj7jga7ku6PnkIY8L3NwYW4+KTxicj4NCiZndDsgJmd0OyZndDsg PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+6YCB5L+h5pel 5pmCPC9zcGFuPjogPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlh biI+DQrmsLTmm5zml6U8L3NwYW4+LCAxMTxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1m YW1pbHk6RGVuZ1hpYW4iPuaciDwvc3Bhbj4gMjgsIDIwMTggODo1OA0KPHNwYW4gbGFuZz0iWkgt Q04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+5Y2I5b6MPC9zcGFuPjxicj4NCiZndDsg Jmd0OyZndDsgPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+ 5a6b5YWIPC9zcGFuPjogSGFubmVzIFRzY2hvZmVuaWc8YnI+DQomZ3Q7ICZndDsmZ3Q7IENjOiA8 YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7IDxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9u dC1mYW1pbHk6RGVuZ1hpYW4iPuS7tuWQjTwvc3Bhbj46IFJlOiBbT0FVVEgtV0ddIE9BdXRoIFNl Y3VyaXR5IFRvcGljcyAtLSBSZWNvbW1lbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2Yg aW1wbGljaXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0OyZndDsgJiM0 MzsxPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IFdoaWxlIHRoZXJlIGFy ZSB2YXJpb3VzIG1lY2hhbmlzbXMgdG8gYWxsZXZpYXRlIHNvbWUgb2YgdGhlIGlzc3VlcyBvZiBp bXBsaWNpdCwgSSBkb24ndCB0aGluayB3ZSBjYW4gcmVjb21tZW5kIHNwZWNpZmljcywgYW5kIHRo ZXJlIG1heSBiZSBmdXR1cmUgb25lcyBpbiB0aGUgZnV0dXJlLiBJIHRoaW5rIHdlIGFsbCBhZ3Jl ZSB0aGF0IGltcGxpY2l0IHdpdGhvdXQgYW55IG1pdGlnYXRpb24gaXMgcHJvYmxlbWF0aWMuDQo8 YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgSG93IGFib3V0IHdlIHJlY29t bWVuZCBhZ2FpbnN0IHVzaW5nIGltcGxpY2l0IGFsb25lPyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxi cj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBPbiBNb24sIE5vdiAxOSwgMjAx OCBhdCAyOjM0IEFNIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86SGFubmVz LlRzY2hvZmVuaWdAYXJtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkhhbm5lcy5Uc2Nob2ZlbmlnQGFy bS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7 ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgVGhlIGF1dGhvcnMgb2YgdGhlIE9BdXRoIFNl Y3VyaXR5IFRvcGljcyBkcmFmdCBjYW1lIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgaXQgaXMgbm90 IHBvc3NpYmxlIHRvIGFkZXF1YXRlbHkgc2VjdXJlIHRoZSBpbXBsaWNpdCBmbG93IGFnYWluc3Qg dG9rZW4gaW5qZWN0aW9uIHNpbmNlIHBvdGVudGlhbCBzb2x1dGlvbnMgbGlrZSB0b2tlbiBiaW5k aW5nIG9yIEpBUk0gYXJlIGluIGFuIGVhcmx5IHN0YWdlIG9mIGFkb3B0aW9uLiBGb3IgdGhpcw0K IHJlYXNvbiwgYW5kIHNpbmNlIENPUlMgYWxsb3dzIGJyb3dzZXItYmFzZWQgYXBwcyB0byBzZW5k IHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludCwgVG9yc3RlbiBzdWdnZXN0ZWQgdG8gdXNl IHRoZSBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiB0aGUgaW1wbGljaXQgZ3JhbnQgaW4g Y2FsbCBjYXNlcyBpbiBoaXMgcHJlc2VudGF0aW9uIChzZWUNCjxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDMvbWF0ZXJpYWxzL3NsaWRlcy0xMDMtb2F1dGgt c2Vzc2ItZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMDEiIHRhcmdldD0iX2JsYW5r Ij4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDMvbWF0ZXJpYWxzL3Ns aWRlcy0xMDMtb2F1dGgtc2Vzc2ItZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMDE8 L2E+KS48YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgQSBodW0gaW4gdGhl IHJvb20gYXQgSUVURiMxMDMgY29uY2x1ZGVkIHN0cm9uZyBzdXBwb3J0IGZvciBoaXMgcmVjb21t ZW5kYXRpb25zLiBXZSB3b3VsZCBsaWtlIHRvIGNvbmZpcm0gdGhlIGRpc2N1c3Npb24gb24gdGhl IGxpc3QuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IFBsZWFzZSBwcm92 aWRlIGEgcmVzcG9uc2UgYnkgRGVjZW1iZXIgM3JkLjxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBDaWFvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7 IEhhbm5lcyAmYW1wOyBSaWZhYXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZn dDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IElNUE9SVEFO VCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg YXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJz b24sIHVzZSBpdCBmb3IgYW55DQogcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3Jt YXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Ljxicj4NCiZndDsgJmd0OyZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsm Z3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyZndDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgT0F1dGggbWFpbGluZyBs aXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS08bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFhcm9uIFBhcmVja2k8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9 Imh0dHA6Ly9hYXJvbnBhcmVja2kuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWFyb25wYXJlY2tpLmNv bTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIGhyZWY9Imh0dHA6Ly90d2l0dGVyLmNvbS9hYXJvbnBrIiB0YXJnZXQ9Il9ibGFuayI+QGFh cm9ucGs8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCklNUE9S VEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBw ZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5m b3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_VI1PR0801MB21120AA6CC9437E237F481A2FAAC0VI1PR0801MB2112_-- From nobody Sat Dec 1 01:16:28 2018 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 4E0B8128A6E for ; Sat, 1 Dec 2018 01:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=armh.onmicrosoft.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 5V4DefE7w0t2 for ; Sat, 1 Dec 2018 01:16:26 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80084.outbound.protection.outlook.com [40.107.8.84]) (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 D6D6D128DFD for ; Sat, 1 Dec 2018 01:16:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gVVoWcGlFTrDsb+OgwdGBKfGSIo3zGMG3LC+8XcIMQI=; b=q6tnHWXSqraNHfGJCxkndmLC9urQbBMOf+nlKEV0Y3F37z1CWnC8Dem5Ll1tZBUzH3s7PtN6gCkq6dOH12R4e2SIrEgxz1jh0lvYhADsdXu0hi1m+41QzVlQ3uk48NwvcAXxvJhxcYhgHGyXLhnG2SS4CM68MOLxefcGqhfpzn0= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1375.eurprd08.prod.outlook.com (10.167.198.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.22; Sat, 1 Dec 2018 09:15:55 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::2056:1db1:e01:4670]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::2056:1db1:e01:4670%3]) with mapi id 15.20.1361.022; Sat, 1 Dec 2018 09:15:55 +0000 From: Hannes Tschofenig To: Brian Campbell , Torsten Lodderstedt CC: oauth Thread-Topic: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 Thread-Index: AdR1tZqXsuKHZhdYRhq5sgoVL0Z8egAA8cqAAKwg0oAAxpLdAABZ4LyAAAtfsIAABWFQAABNvIAAAqYaNYAAFg8eMA== Date: Sat, 1 Dec 2018 09:15:55 +0000 Message-ID: References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.19] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1375; 6:/CG3Twi4D4q+tL1U72SxBa8OofIGivFq8JkToU6vJnENQnFRdYnKOZBseuBQ2nspOGLDU4TPs41UX57V8MHms51BwYQYcpVxK7P+OIiuykHe0ds+Qsz+BGJIps4UuSxk/inGIssR5+fPmrPiFACsG9ZG2IM8C9r61NKXakGkUlbtWuWXw3yAO9/bRZ3JyUv9J93pFKwU4UJXtJdMAGS2FXeYwe0Jldr9GwamqTHFQHG5F7oamGBMUSPRH4c1e5COjDALhXxlrpdGW2/yg7Po+1yY7KMGpD7mJMsodjSpiuc0CXxaQ3b7uz930fDHnIlIRleqTkihQcOINceMdbEbCL4DKRyIb6ctURJKzMokUKo/Sv6BGUSdwAFpuy2iaABEVXYb+5kljHND3gKsWrJRQazbNgjRlxu6/re7UvWEUDhEMFrL+0SiJ1rfhahoirvP8swwlpjdM1WJ3jbEy0IM0g==; 5:KH6LirJSwCstAbyeHp2VlUhjnW7Ug394DbogGcTi9vt6RqdaSb/Pwpqj+iSUhf4q9XVfkoJEbOXwuD0Zz71gDp9YtrglXW4FMyk7GVF10qcX2s7B2vI7mISc49pdhLeNct3MOhyyxAAm3s4zqN0ATcKPNMQ1AOra+oQNug/YEAM=; 7:+9KQAeFYF/l+fWCYrD24dHISzxs4G0nyDCYWkEr9rO2yCsql9RtF3aFQGo2WNxHMLZQPQ9oZ3y5CUeOhU7b7WdFXxGr1Ltxv58Lk+3h1ILZYJCHqBrUC8fLCuP7jD1d0BvTM5pyT6w9UcIqZ7JesMg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ef60d3f8-c377-4f7a-26cc-08d6576d9969 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1375; x-ms-traffictypediagnostic: VI1PR0801MB1375: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231454)(999002)(944501475)(4982022)(52105112)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1375; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1375; x-forefront-prvs: 087396016C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(366004)(396003)(136003)(199004)(189003)(40434004)(11346002)(446003)(72206003)(68736007)(486006)(93886005)(99286004)(7696005)(4326008)(25786009)(478600001)(6246003)(6506007)(53546011)(5660300001)(26005)(476003)(102836004)(186003)(256004)(5024004)(14444005)(71200400001)(76176011)(71190400001)(86362001)(66574009)(8936002)(81166006)(8676002)(229853002)(81156014)(6436002)(74316002)(7736002)(2906002)(110136005)(316002)(66066001)(3846002)(790700001)(6116002)(606006)(33656002)(105586002)(106356001)(14454004)(236005)(9686003)(54896002)(6306002)(97736004)(53936002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1375; H:VI1PR0801MB2112.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-microsoft-antispam-message-info: WxxmU05JqIJ/SGFiiX4EDkTCkyPsFARpwLX5y144rhN2QigY3lrHN2pBrCAGKQMKGZP8squpvH1fOiEFQDcIElYRWUbWT2kc780wp4ngbAVJDjGFjGG3HPV4pnRB0m8qNgVBqSE3ucxovHwJUddZLzkYjyAgb4215AgUZ4tbhN0vreYXSrFJQ+oWminTf9U1yb6EMm6THKrxvd+7ByDAxwJS4ik3+6uYQqVM1P4JEczckOZkgQnY0vju+/7DqZjiRvjl494IsRTom9Eep1qdaBYm0tc6yY1P48lfNjzpZi5roTeWEixZvqDH2z8xNbEN/6Yk926ei2tQRj8+JgMM+5fWmEAMHD3DobCxgf/+/2c= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21121BCD21DE8ABAF055E603FAAC0VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ef60d3f8-c377-4f7a-26cc-08d6576d9969 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2018 09:15:55.4849 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1375 Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 01 Dec 2018 09:16:28 -0000 --_000_VI1PR0801MB21121BCD21DE8ABAF055E603FAAC0VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzaGFyZSB0aGUgY29uY2VybiBCcmlhbiBoYXMsIHdoaWNoIGlzIGFsc28gdGhlIGNvbmNsdXNp b24gSSBjYW1lIHVwIHdpdGggaW4gbXkgb3RoZXIgZW1haWwgc2VudCBhIGZldyBtaW51dGVzIGFn by4NCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBC cmlhbiBDYW1wYmVsbA0KU2VudDogRnJpZGF5LCBOb3ZlbWJlciAzMCwgMjAxOCAxMTo0MyBQTQ0K VG86IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pg0KQ2M6IG9h dXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIGRyYWZ0LXBhcmVj a2ktb2F1dGgtYnJvd3Nlci1iYXNlZC1hcHBzLTAwDQoNCg0KT24gU2F0LCBOb3YgMTcsIDIwMTgg YXQgNDowNyBBTSBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxt YWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PiB3cm90ZToNCj4gQW0gMTUuMTEuMjAxOCB1 bSAyMzowMSBzY2hyaWViIEJyb2NrIEFsbGVuIDxicm9ja2FsbGVuQGdtYWlsLmNvbTxtYWlsdG86 YnJvY2thbGxlbkBnbWFpbC5jb20+PjoNCj4NCj4gU28geW91IG1lYW4gYXQgdGhlIHJlc291cmNl IHNlcnZlciBlbnN1cmluZyB0aGUgdG9rZW4gd2FzIHJlYWxseSBpc3N1ZWQgdG8gdGhlIGNsaWVu dD8gSXNuJ3QgdGhhdCBhbiBpbmhlcmVudCBsaW1pdGF0aW9uIG9mIGFsbCBiZWFyZXIgdG9rZW5z IChtb2R1bG8gSFRUUCB0b2tlbiBiaW5kaW5nLCB3aGljaCBpcyBzdGlsbCBzb21lIHRpbWUgb2Zm KT8NCg0KU3VyZS4gVGhhdOKAmXMgd2h5IHRoZSBTZWN1cml0eSBCQ1AgcmVjb21tZW5kcyB1c2Ug b2YgVExTLWJhc2VkIG1ldGhvZHMgZm9yIHNlbmRlciBjb25zdHJhaW5pbmcgYWNjZXNzIHRva2Vu cyAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHkt dG9waWNzLTA5I3NlY3Rpb24tMi4uMikuIFRva2VuIEJpbmRpbmcgZm9yIE9BdXRoIChodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1iaW5kaW5nLTA4PGh0 dHBzOi8vdG9vbHMuLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1iaW5kaW5n LTA4PikgYXMgd2VsbCBhcyBNdXR1YWwgVExTIGZvciBPQXV0aCAoaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtbXRscy0xMikgYXJlIHRoZSBvcHRpb25zIGF2YWls YWJsZS4NCg0KVW5mb3J0dW5hdGVseSBldmVuIHdoZW4gdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50 LCBmb3IgU1BBIC8gaW4tYnJvd3NlciBjbGllbnQgYXBwbGljYXRpb25zLCB0aGUgcG90ZW50aWFs IG1lY2hhbmlzbXMgZm9yIHNlbmRlci9rZXktY29uc3RyYWluaW5nIGFjY2VzcyB0b2tlbnMgZG9u J3Qgd29yayB2ZXJ5IHdlbGwgb3IgbWF5YmUgZG9uJ3Qgd29yayBhdCBhbGwuIFNvIEkgZG9uJ3Qg a25vdyB0aGF0IHRoZSByZWNvbW1lbmRhdGlvbiBpcyB2ZXJ5IHJlYWxpc3RpYy4NCg0KDQpDT05G SURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBh bmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUg Ynkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0 dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KSU1QT1JUQU5UIE5PVElD RTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29u ZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNl IGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4g YW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K --_000_VI1PR0801MB21121BCD21DE8ABAF055E603FAAC0VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t R0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc2hhcmUgdGhlIGNvbmNlcm4gQnJpYW4gaGFzLCB3 aGljaCBpcyBhbHNvIHRoZSBjb25jbHVzaW9uIEkgY2FtZSB1cCB3aXRoIGluIG15IG90aGVyIGVt YWlsIHNlbnQgYSBmZXcgbWludXRlcyBhZ28uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBPQXV0 aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+QnJp YW4gQ2FtcGJlbGw8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBOb3ZlbWJlciAzMCwgMjAxOCAx MTo0MyBQTTxicj4NCjxiPlRvOjwvYj4gVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7dG9yc3RlbkBs b2RkZXJzdGVkdC5uZXQmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIGRyYWZ0LXBhcmVja2kt b2F1dGgtYnJvd3Nlci1iYXNlZC1hcHBzLTAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBOb3YgMTcsIDIw MTggYXQgNDowNyBBTSBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVuQGxvZGRlcnN0ZWR0 Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBBbSAxNS4xMS4yMDE4IHVtIDIzOjAxIHNjaHJpZWIg QnJvY2sgQWxsZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpicm9ja2FsbGVuQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmJyb2NrYWxsZW5AZ21haWwuY29tPC9hPiZndDs6PGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFNvIHlvdSBtZWFuIGF0IHRoZSByZXNvdXJjZSBzZXJ2ZXIgZW5zdXJpbmcgdGhlIHRv a2VuIHdhcyByZWFsbHkgaXNzdWVkIHRvIHRoZSBjbGllbnQ/IElzbid0IHRoYXQgYW4gaW5oZXJl bnQgbGltaXRhdGlvbiBvZiBhbGwgYmVhcmVyIHRva2VucyAobW9kdWxvIEhUVFAgdG9rZW4gYmlu ZGluZywgd2hpY2ggaXMgc3RpbGwgc29tZSB0aW1lIG9mZik/PGJyPg0KPGJyPg0KU3VyZS4gVGhh dOKAmXMgd2h5IHRoZSBTZWN1cml0eSBCQ1AgcmVjb21tZW5kcyB1c2Ugb2YgVExTLWJhc2VkIG1l dGhvZHMgZm9yIHNlbmRlciBjb25zdHJhaW5pbmcgYWNjZXNzIHRva2VucyAoPGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNz LTA5I3NlY3Rpb24tMi4uMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0wOSNzZWN0aW9uLTIuLjI8L2E+ KS4NCiBUb2tlbiBCaW5kaW5nIGZvciBPQXV0aCAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy4uaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWJpbmRpbmctMDgiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1i aW5kaW5nLTA4PC9hPikgYXMgd2VsbCBhcyBNdXR1YWwgVExTIGZvciBPQXV0aCAoPGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtbXRscy0xMiIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRo LW10bHMtMTI8L2E+KQ0KIGFyZSB0aGUgb3B0aW9ucyBhdmFpbGFibGUuIDxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VW5mb3J0dW5h dGVseSBldmVuIHdoZW4gdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50LCBmb3IgU1BBIC8gaW4tYnJv d3NlciBjbGllbnQgYXBwbGljYXRpb25zLCB0aGUgcG90ZW50aWFsIG1lY2hhbmlzbXMgZm9yIHNl bmRlci9rZXktY29uc3RyYWluaW5nIGFjY2VzcyB0b2tlbnMgZG9uJ3Qgd29yayB2ZXJ5IHdlbGwg b3IgbWF5YmUgZG9uJ3Qgd29yayBhdCBhbGwuIFNvIEkgZG9uJ3Qga25vdyB0aGF0IHRoZSByZWNv bW1lbmRhdGlvbg0KIGlzIHZlcnkgcmVhbGlzdGljLiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFk ZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2Yg dGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4NCiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlv biBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsg SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1l c3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsg eW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQpJTVBPUlRBTlQgTk9U SUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBj b25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9u IGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_VI1PR0801MB21121BCD21DE8ABAF055E603FAAC0VI1PR0801MB2112_-- From nobody Sat Dec 1 01:43:54 2018 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 8D140128A6E for ; Sat, 1 Dec 2018 01:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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] 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=nri365.onmicrosoft.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 NS3XBi4Ep_WN for ; Sat, 1 Dec 2018 01:43:49 -0800 (PST) Received: from nrifs01.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876ED12008A for ; Sat, 1 Dec 2018 01:43:48 -0800 (PST) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs01.index.or.jp (Postfix) with ESMTP id CDACC77EDF; Sat, 1 Dec 2018 18:43:47 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 2697C4E0046; Sat, 1 Dec 2018 18:43:47 +0900 (JST) Received: from nriea03.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id wB19hlYU016287; Sat, 1 Dec 2018 18:43:47 +0900 Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea03.index.or.jp with ESMTP id wB19hk8h016285; Sat, 01 Dec 2018 18:43:46 +0900 Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wB19hnUA037124; Sat, 1 Dec 2018 18:43:49 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id wB19hngX037123; Sat, 1 Dec 2018 18:43:49 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf12.index.or.jp ([172.100.25.21]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wB19hnas037120; Sat, 1 Dec 2018 18:43:49 +0900 Received: from CUEXE01PA.cu.nri.co.jp (192.51.23.31) by CUEXM02SA.cu.nri.co.jp (172.59.253.44) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 1 Dec 2018 18:43:43 +0900 Received: from APC01-SG2-obe.outbound.protection.outlook.com (65.55.88.248) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 1 Dec 2018 18:43:43 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+vTK7aU3kuynN8ZjGDgQi78gZbaFL32xutprhnRuQnE=; b=HFl4PR5PiaZm4LelUdBBVcXj5csC0FwMTcpSaV9unrby5rtL1yfSzuhSc/GtojynwPQDpSwoxTETSEsq0dH9MNBIyWZ8WrCQ2A+xO+XspyLrarS/LzCPAjAju3g7aOtBJ00i/RgvKKeVoO5wDi3+bfzwFyHzWbE4PlxF8Yc5UuE= Received: from TY2PR01MB2876.jpnprd01.prod.outlook.com (20.177.97.210) by TY2PR01MB3899.jpnprd01.prod.outlook.com (20.178.142.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.22; Sat, 1 Dec 2018 09:43:41 +0000 Received: from TY2PR01MB2876.jpnprd01.prod.outlook.com ([fe80::5cc7:df48:2275:8e66]) by TY2PR01MB2876.jpnprd01.prod.outlook.com ([fe80::5cc7:df48:2275:8e66%3]) with mapi id 15.20.1382.019; Sat, 1 Dec 2018 09:43:41 +0000 From: n-sakimura To: Hannes Tschofenig , Aaron Parecki , Torsten Lodderstedt CC: Daniel Fett , IETF oauth WG Thread-Topic: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit Thread-Index: AdR/8wsdlCSgLoNZTem+1MxrAorhbwHYZjwAAABEwfcABVOygAAAbOyYAAB2LIAAH9tBAAAIC/AAAEN4+4AADeWWQAABjqXm Date: Sat, 1 Dec 2018 09:43:41 +0000 Message-ID: References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> , In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; x-originating-ip: [13.86.37.77] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; TY2PR01MB3899; 6:ejY2AUz1IOVqd/VSvVnsKTsSZaAv2/rOoPIFlz9+5L/Q1LpReR7Yy+jadypEMit8GWveU3MCb+FqANG+pLpgB5Wre7lbdBjc2849sX+VcTBE/EoGFlSpck838XfsUB16x6iKcQ0K21xwhNZaR2rX6m8fwpM05ev/C3Bi3pCUuT+noC9EwvehD/VwEsSVWajjN634Kqi7jy04uJu2K4VoDOdoGqIFy6acCrtwIgWciWgnjCl0+LS9zHinZloroLcKTOYuAfMj3ipNcHDfwZeNL1xy6N42M8ldWi5SpV/uhslqJ7N6OQkA+3zadIWm1Yn56h9tNUdVVRgzjBxntaurrA2ZhEQ9FLQ+f4W20KMDxqo6eUscSUr9EINGGtAxRrxy7chZItZT4/7RtWnfpO/HdAxzWgMpXA7ktXgNzVeIlQY53xMo+Wespx3Bu46CSJ9ySVTSVSne4QKRv8W3UOLj1Q==; 5:kT2RrCIWxNV+hThvrvG8pbh4uy+GvhmSLBHeBAS7nI0VHZVxpxhdfOfE257D13nlYI/brcZW3h3vDmE0XZofUTM2ALWB1mgjHTZbeYjv/Oar+GdzdxK0emHW/CMTwRt/sGaru/VXyzg6pCSndm4yhiqE6qMDzM3LYuxS2dXHCcg=; 7:TKENTWHYDXnrfM02MqlsSa8nBj3A7ro56QZ+BgFpcWpTc9IRaPkmIXFAmVw+U+Rf+zy7ouN65KkB7TBICm0Rcq9519B3gneQgoeNUnj2XGJPO1672I4d2lvmD9ey6Ip5c/2cIMKXb9KGL5L6zoV5fw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7c4c7b4a-437d-4f59-901e-08d657717a22 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:TY2PR01MB3899; x-ms-traffictypediagnostic: TY2PR01MB3899: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231454)(999002)(944501475)(52105112)(2017080701022)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123558120)(2016111802025)(20161123560045)(6043046)(201708071742011)(7699051)(76991095); SRVR:TY2PR01MB3899; BCL:0; PCL:0; RULEID:; SRVR:TY2PR01MB3899; x-forefront-prvs: 087396016C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(376002)(366004)(39840400004)(396003)(199004)(189003)(40434004)(53754006)(365934003)(53386004)(508600001)(15650500001)(53546011)(6506007)(66574009)(2420400007)(6436002)(45080400002)(966005)(11346002)(66066001)(102836004)(53376002)(71200400001)(74316002)(2906002)(71190400001)(7110500001)(53936002)(186003)(486006)(4326008)(26005)(476003)(33656002)(86362001)(14454004)(105586002)(7696005)(25786009)(76176011)(561944003)(5660300001)(8936002)(7736002)(8676002)(6306002)(99286004)(14444005)(97736004)(256004)(236005)(106356001)(81166006)(54896002)(55016002)(81156014)(93886005)(446003)(606006)(68736007)(74482002)(229853002)(6246003)(110136005)(9686003)(54906003)(5024004)(316002)(3846002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:TY2PR01MB3899; H:TY2PR01MB2876.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts) x-microsoft-antispam-message-info: vrZlpSGaXDF8AvNG3XZiSHrhhKYMc8kVpo8IfWS5TsjkSD/JgHfv6z2izz+2eWnPVIBhTmtH5HwH4ambCIcOaTbmgQy6YnY2yGcbpg+/7qEmxOlfxHvVXyDYxSK74ckNjgbyPOOF5Rc6XHiPOM7UT9vn4JL/7pyKo1jtZ6e3SZ/5I+6iCRIw/ksiy/bW9Q9gxFH2ZquTgPAbx70gZYZpuCp+YoWZqjjtMHqgkH9DGEl5nCb199FP9MqiyLR/0Gdod2EBpvXO/tdXFZVctelh+Nj8pZfAbby2DhHYOMi2TqKLPII0xp4wjJrkSPGZDU9ssu0FvgTFCb7tgsMsh6ZQZxuqgvUPnRi2iNo42I2ln1o= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_TY2PR01MB2876FAC5642380820BCD4BCCF9AC0TY2PR01MB2876jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7c4c7b4a-437d-4f59-901e-08d657717a22 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2018 09:43:41.1041 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB3899 X-OrganizationHeadersPreserved: TY2PR01MB3899.jpnprd01.prod.outlook.com X-CrossPremisesHeadersPromoted: CUEXE01PA.cu.nri.co.jp X-CrossPremisesHeadersFiltered: CUEXE01PA.cu.nri.co.jp X-OriginatorOrg: cu.nri.co.jp Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 01 Dec 2018 09:43:52 -0000 --_000_TY2PR01MB2876FAC5642380820BCD4BCCF9AC0TY2PR01MB2876jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T0F1dGggTVRMUyBoYXMgYmVlbiBpbXBsZW1lbnRlZCBpbiBCYW5raW5nIGluZHVzdHJ5IHNvIHdl IGhhdmUgYXQgbGVhc3QgYW4gYWx0ZXJuYXRpdmUuDQoNClNlbmRlciBDb25zdHJhaW5lZCBpbmNs dWRlcyBjYXNlcyB3aGVyZSBpdCBpcyBub3Qga2V5IGJvdW5kIGJ1dCBuYW1lIGJvdW5kIGFzIEkg dW5kZXJzdGFuZCBhbmQgaXQgbWF5IGhhdmUgc29tZSB1dGlsaXR5IHNvIHdlIGYgdGhlcmUgYXJl IGRvdWJ0cywgbWVudGlvbmluZyB0aGUgYm90aCBtYXkgYmUgZ29vZC4NCg0KT3V0bG9vayBmb3Ig aU9TPGh0dHBzOi8vYWthLm1zL28wdWtlZj4g44KS5YWl5omLDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQrlt67lh7rkuro6IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3Jn PiAoSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGFybS5jb20+IOOBruS7o+eQ hikNCumAgeS/oeaXpeaZgjog5Zyf5puc5pelLCAxMuaciCAxLCAyMDE4IDY6MDcg5Y2I5b6MDQrl rpvlhYg6IEFhcm9uIFBhcmVja2k7IFRvcnN0ZW4gTG9kZGVyc3RlZHQNCkNjOiBEYW5pZWwgRmV0 dDsgSUVURiBvYXV0aCBXRw0K5Lu25ZCNOiBSZTogW09BVVRILVdHXSBPQXV0aCBTZWN1cml0eSBU b3BpY3MgLS0gUmVjb21tZW5kIGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIGltcGxpY2l0 DQoNCkkgYWdyZWUgd2l0aCBBYXJvbiBoZXJlIGFuZCBJIHRoaW5rIFNlY3Rpb24gMy44LjEuMjxo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3Bp Y3MtMTAjc2VjdGlvbi0zLjguMS4yPiBvZiBkcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGlj cy0xMCAgYWxyZWFkeSBkb2VzIGEgcHJldHR5IGdvb2Qgam9iLg0KSSB3YXMsIGhvd2V2ZXIsIHdv bmRlcmluZyBhYm91dCB0aGUgc3VidGxlIGltcGxpY2F0aW9uIG9mIHRoZSByZXF1aXJlbWVudCBm b3Igc2VuZGVyIGNvbnN0cmFpbmVkIHRva2Vucy4gTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgdG9r ZW4gYmluZGluZyBkaXNjdXNzaW9uLCB3aGljaCBpcyBvbmUgb2YgdGhlIHdheXMgdG8gcHJvdmlk ZSBzZW5kZXItY29uc3RyYWluZWQgdG9rZW5zLCBpcyB0aGF0IHdlIGRvbuKAmXQgaGF2ZSBnb29k IGZhaXRoIGluIHNlZWluZyBkZXBsb3ltZW50IGFueXRpbWUgc29vbi4gSGVuY2UsIHdlIGFyZSBl c3NlbnRpYWxseSAocmVhZGluZyBpbiBiZXR3ZWVuIHRoZSBsaW5lcyBvZiBTZWN0aW9uIDMuOC4x LjIpIHNheWluZyB0aGF0IHlvdSBjYW5ub3QgdXNlIGltcGxpY2l0IGdyYW50IGluIGEgcHJhY3Rp Y2FsIHNldHVwIGZvciB0aGUgd2ViKi4NCg0KQW0gSSBtaXN1bmRlcnN0YW5kaW5nIGl0Pw0KDQpD aWFvDQpIYW5uZXMNCg0KUFM6IFRoZSBJb1QgY2FzZSBpcyBsaWtlbHkgZGlmZmVyZW50Lg0KDQpG cm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEFhcm9uIFBh cmVja2kNClNlbnQ6IFNhdHVyZGF5LCBEZWNlbWJlciAxLCAyMDE4IDM6MTggQU0NClRvOiBUb3Jz dGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4NCkNjOiBEYW5pZWwgRmV0 dCA8ZmV0dEBkYW5pZWxmZXR0LmRlPjsgSUVURiBvYXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCBTZWN1cml0eSBUb3BpY3MgLS0gUmVjb21tZW5k IGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIGltcGxpY2l0DQoNCisxDQoNCkkgd291bGQg YWxzbyBsaWtlIHRvIGVuc3VyZSB0aGVyZSBpcyBhIGNsZWFyIGRlZmluaXRpb24gb2YgInNlbmRl ciBjb25zdHJhaW5lZCIgdG9rZW5zIGluIHRoaXMgQkNQLg0KDQpBYXJvbg0KDQoNCk9uIFRodSwg Tm92IDI5LCAyMDE4IGF0IDEwOjA2IEFNIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4+IHdyb3RlOg0KSGkg YWxsLA0KDQpiYXNlZCBvbiB5b3VyIGZlZWRiYWNrIG9uIHRoZSBsaXN0IGFuZCBvZmYgbGlzdCwg RGFuaWVsIGFuZCBJIHBvbGlzaGVkIHRoZSB0ZXh0LiBUaGF04oCZcyBvdXIgcHJvcG9zYWw6DQoN CuKAlA0KSW4gb3JkZXIgdG8gYXZvaWQgdGhlc2UgaXNzdWVzLCBjbGllbnRzIE1VU1QgTk9UIHVz ZSB0aGUgaW1wbGljaXQNCmdyYW50IChyZXNwb25zZSB0eXBlICJ0b2tlbiIpIG9yIGFueSBvdGhl ciByZXNwb25zZSB0eXBlIGlzc3VpbmcgYWNjZXNzDQp0b2tlbnMgaW4gdGhlIGF1dGhvcml6YXRp b24gcmVzcG9uc2UsIHN1Y2ggYXMgInRva2VuIGlkX3Rva2VuIiBhbmQgImNvZGUgdG9rZW4gaWRf dG9rZW7igJwsDQp1bmxlc3MgdGhlIGlzc3VlZCBhY2Nlc3MgdG9rZW5zIGFyZSBzZW5kZXItY29u c3RyYWluZWQgYW5kIGFjY2VzcyB0b2tlbiBpbmplY3Rpb24gaW4NCnRoZSBhdXRob3JpemF0aW9u IHJlc3BvbnNlIGlzIHByZXZlbnRlZC4NCuKAlA0KDQpFeHBsYW50YXRpb246DQotIHdlIHdhbnRl ZCB0byBoYXZlIHRoZSByaWdodCBiYWxhbmNlIGJldHdlZW4gYSBnZW5lcmljIGRlZmluaXRpb24g b2YgdGhlIHJlc3BvbnNlIHR5cGVzIHdlIGRvIG5vdCByZWNvbW1lbmQvYWxsb3cgdG8gYmUgdXNl ZCBhbmQgYSBjb25jcmV0ZS9hY3Rpb25hYmxlIGxpc3Qgb2YgdGhlIGFmZmVjdGVkIHJlc3BvbnNl IHR5cGVzLg0KLSB3ZSBjaGFuZ2VkIGZyb20gU0hPVUxEIE5PVCB0byBNVVNUIE5PVCBhcyBzdWdn ZXN0ZWQgYnkgTmF0IGFuZCBzdXBwb3J0ZWQgYnkgV2lsbGlhbQ0KDQpXZSBsb29rIGZvcndhcmQg dG8gc2VlaW5nIHlvdXIgZmVlZGJhY2suDQoNCmtpbmQgcmVnYXJkcywNClRvcnN0ZW4uDQoNCj4g QW0gMjkuMTEuMjAxOCB1bSAxNToxNSBzY2hyaWViIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0 Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj46DQo+DQo+IEkgYW0gb2sgd2l0aCB0aGF0 Lg0KPg0KPiBPbiBXZWQsIE5vdiAyOCwgMjAxOCwgODowMyBQTSBUb3JzdGVuIExvZGRlcnN0ZWR0 IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+ IHdyb3RlOg0KPg0KPiA+IEFtIDI4LjExLjIwMTggdW0gMjM6NTAgc2NocmllYiBuLXNha2ltdXJh IDxuLXNha2ltdXJhQG5yaS5jby5qcDxtYWlsdG86bi1zYWtpbXVyYUBucmkuY28uanA+PjoNCj4g Pg0KPiA+IFRoYXQgd29ya3MuDQo+DQo+IEdvb2QhDQo+DQo+IEkganVzdCByZWFsaXplZCB0aGlz IHRleHQgaGFzIGFuIGlzc3VlIHdpdGgg4oCedG9rZW7igJwgKG9ubHkpLiBJdCB3b3VsZCBhbGxv dyDigJ50b2tlbuKAnCB0byBiZSB1c2VkIGlmIHRoZSB0b2tlbiB3b3VsZCBzZW5kZXIgY29uc3Ry YWluZWQuIFRoaXMgY29tcGxldGVseSBpZ25vcmVzIHRoZSBmYWN0IGltcGxpY2l0IGFsc28gc2hh bGwgYmUgYWJhbmRvbmVkIGJlY2F1c2Ugb2YgaXRzIHZ1bG5lcmFiaWxpdHkgZm9yIGFjY2VzcyB0 b2tlbiBpbmplY3Rpb24uDQo+DQo+IEkgdGhlcmVmb3JlIHByb3Bvc2UgYSBtb2RpZmllZCB0ZXh0 Og0KPg0KPiAgICBJbiBvcmRlciB0byBhdm9pZCB0aGVzZSBpc3N1ZXMsIENsaWVudHMgU0hPVUxE IE5PVCB1c2UgdGhlIGltcGxpY2l0DQo+ICAgIGdyYW50LiBGdXJ0aGVybW9yZSwgY2xpZW50cyBT SE9VTEQgb25seSB1c2Ugb3RoZXIgcmVzcG9uc2UgdHlwZXMgY2F1c2luZyB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgdG8NCj4gICAgaXNzdWUgYW4gYWNjZXNzIHRva2VuIGluIHRoZSBhdXRob3Jp emF0aW9uIHJlc3BvbnNlLCBpZiB0aGUgcGFydGljdWxhciByZXNwb25zZSB0eXBlIGRldGVjdHMg YWNjZXNzIHRva2VuDQo+ICAgIGluamVjdGlvbiBhbmQgdGhlIGlzc3VlZCBhY2Nlc3MgdG9rZW5z IGFyZSBzZW5kZXItY29uc3RyYWluZWQuDQo+DQo+IE9yIHdlIGp1c3Qgc3RhdGU6DQo+DQo+ICAg SW4gb3JkZXIgdG8gYXZvaWQgdGhlc2UgaXNzdWVzLCBDbGllbnRzIFNIT1VMRCBOT1QgdXNlIHRo ZSByZXNwb25zZSB0eXBlIOKAnnRva2VuIi4gVGhlIHJlc3BvbnNlIHR5cGVzDQo+IOKAnnRva2Vu IGlkX3Rva2Vu4oCcIGFuZCDigJ5jb2RlIHRva2VuIGlkX3Rva2Vu4oCcIFNPVUxEIE5PVCBiZSB1 c2VkLCBpZiB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbnMgYXJlIG5vdA0KPiBzZW5kZXItY29uc3Ry YWluZWQuDQo+DQo+ID4NCj4gPiBJbiBmYWN0LCBJIHdvdWxkIGZ1cnRoZXIgZ28gYW5kIHNheSBN VVNUIE5PVCBidXQgdGhhdCBwcm9iYWJseSBpcyB0b28gbXVjaCBmb3IgYSBzZWN1cml0eSBjb25z aWRlcmF0aW9uLg0KPiA+DQo+DQo+IE1pa2Ugc3VnZ2VzdGVkIHRvIGdvIHdpdGggYSBTSE9VTEQg Tk9UIHRvIGdldCB0aGUgbWVzc2FnZSBvdXQgYnV0IGdpdmUgaW1wbGVtZW50b3JzIHRpbWUgdG8g bW92ZS9jaGFuZ2UuDQo+DQo+ID4gQmVzdCwNCj4gPg0KPiA+IE5hdA0KPiA+DQo+ID4gTmF0IFNh a2ltdXJhIC8gbi1zYWtpbXVyYUBucmkuY28uanA8bWFpbHRvOm4tc2FraW11cmFAbnJpLmNvLmpw PiAvICs4MS05MC02MDEzLTYyNzYNCj4gPg0KPiA+IOOBk+OBruODoeODvOODq+OBq+OBr+OAgeac rOadpeOBruWum+WFiOOBruaWueOBruOBv+OBq+mZkOWumuOBleOCjOOBn+apn+WvhuaDheWgseOB jOWQq+OBvuOCjOOBpuOBhOOCi+WgtOWQiOOBjOOBlOOBluOBhOOBvuOBmeOAguOBiuW/g+OBguOB n+OCiuOBruOBquOBhOWgtOWQiOOBr+OAgeiqoOOBq+eUs+OBl+ios+OBlOOBluOBhOOBvuOBm+OC k+OBjOOAgemAgeS/oeiAheOBvuOBp+OBiuefpeOCieOBm+mgguOBjeOAgeOBvuOBn+WPl+S/oeOB leOCjOOBn+ODoeODvOODq+OBr+WJiumZpOOBl+OBpuOBj+OBoOOBleOBhOOBvuOBmeOCiOOBhuOB iumhmOOBhOeUs+OBl+S4iuOBkuOBvuOBmeOAgg0KPiA+DQo+ID4gUExFQVNFIFJFQUQgOlRoaXMg ZS1tYWlsIGlzIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgZm9yIHRoZSBuYW1lZCByZWNpcGll bnQgb25seS4NCj4gPiBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgZS1tYWlsLg0KPiA+DQo+ID4g5beu 5Ye65Lq6OiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWls dG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+Pg0KPiA+IOmAgeS/oeaXpeaZgjog5rC05puc5pel LCAxMeaciCAyOCwgMjAxOCAxMTozOCDljYjlvowNCj4gPiDlrpvlhYg6IG4tc2FraW11cmENCj4g PiBDYzogRGljayBIYXJkdDsgSGFubmVzIFRzY2hvZmVuaWc7IG9hdXRoQGlldGYub3JnPG1haWx0 bzpvYXV0aEBpZXRmLm9yZz4NCj4gPiDku7blkI06IFJlOiBbT0FVVEgtV0ddIE9BdXRoIFNlY3Vy aXR5IFRvcGljcyAtLSBSZWNvbW1lbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2YgaW1w bGljaXQNCj4gPg0KPiA+IEhpIE5hdCwNCj4gPg0KPiA+PiBBbSAyOC4xMS4yMDE4IHVtIDIxOjEw IHNjaHJpZWIgbi1zYWtpbXVyYSA8bi1zYWtpbXVyYUBucmkuY28uanA8bWFpbHRvOm4tc2FraW11 cmFAbnJpLmNvLmpwPj46DQo+ID4+DQo+ID4+IEkgd291bGQgc3VwcG9ydA0KPiA+Pg0KPiA+PiAx KSBjbGVhcmx5IGRlZmluaW5nIEltcGxpY2l0IGFzIHRoZSBmbG93IHRoYXQgcmV0dXJucyBhY2Nl c3MgdG9rZW4gZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCAoIHNvbWUgcGVvcGxlIGNv bmZ1c2VzIGltcGxpY2l0IGFzIHRoZSBmbG93IHRoYXQgcmV0dXJucyBJRCBUb2tlbiBpbiB0aGUg ZnJvbnQgY2hhbm5lbCkNCj4gPg0KPiA+IFRoYXTigJlzIHRoZSBjdXJyZW50IHRleHQ6DQo+ID4N Cj4gPiBJbiBvcmRlciB0byBhdm9pZCB0aGVzZSBpc3N1ZXMsIENsaWVudHMgU0hPVUxEIE5PVCB1 c2UgdGhlIGltcGxpY2l0DQo+ID4gICAgZ3JhbnQgb3IgYW55IG90aGVyIHJlc3BvbnNlIHR5cGUg Y2F1c2luZyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8NCj4gPiAgICBpc3N1ZSBhbiBhY2Nl c3MgdG9rZW4gaW4gdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UuDQo+ID4NCj4gPiBXaGF0IHdv dWxkIHlvdSBsaWtlIHRvIG1vZGlmeT8NCj4gPg0KPiA+Pg0KPiA+PiAyKSBCYW5uaW5nIHRoZSBy ZXR1cm5pbmcgb2YgdGhlIGFjY2VzcyB0b2tlbiB0aGF0IGFyZSBub3Qgc2VuZGVyIGNvbnN0cmFp bmVkIGZyb20gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQNCj4gPg0KPiA+IEluIG9yZGVyIHRv IGF2b2lkIHRoZXNlIGlzc3VlcywgQ2xpZW50cyBTSE9VTEQgTk9UIHVzZSB0aGUgaW1wbGljaXQN Cj4gPiAgICBncmFudCBvciBhbnkgb3RoZXIgcmVzcG9uc2UgdHlwZSBjYXVzaW5nIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciB0bw0KPiA+ICAgIGlzc3VlIGFuIGFjY2VzcyB0b2tlbiBpbiB0aGUg YXV0aG9yaXphdGlvbiByZXNwb25zZSwgaWYgdGhpcyBhY2Nlc3MgdG9rZW5zIGlzIG5vdCBzZW5k ZXItY29uc3RyYWludC4NCj4gPg0KPiA+IFdoYXQgYWJvdXQgdGhpcz8NCj4gPg0KPiA+IGtpbmQg cmVnYXJkcywNCj4gPiBUb3JzdGVuLg0KPiA+DQo+ID4+DQo+ID4+IEJlc3QsDQo+ID4+DQo+ID4+ IE5hdA0KPiA+Pg0KPiA+Pg0KPiA+PiBPdXRsb29rIGZvciBpT1Mg44KS5YWl5omLDQo+ID4+DQo+ ID4+IOW3ruWHuuS6ujogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmc+PiAoRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFp bHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4g44Gu5Luj55CGKQ0KPiA+PiDpgIHkv6Hml6XmmYI6 IOawtOabnOaXpSwgMTHmnIggMjgsIDIwMTggODo1OCDljYjlvowNCj4gPj4g5a6b5YWIOiBIYW5u ZXMgVHNjaG9mZW5pZw0KPiA+PiBDYzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYu b3JnPg0KPiA+PiDku7blkI06IFJlOiBbT0FVVEgtV0ddIE9BdXRoIFNlY3VyaXR5IFRvcGljcyAt LSBSZWNvbW1lbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2YgaW1wbGljaXQNCj4gPj4N Cj4gPj4gKzENCj4gPj4NCj4gPj4gV2hpbGUgdGhlcmUgYXJlIHZhcmlvdXMgbWVjaGFuaXNtcyB0 byBhbGxldmlhdGUgc29tZSBvZiB0aGUgaXNzdWVzIG9mIGltcGxpY2l0LCBJIGRvbid0IHRoaW5r IHdlIGNhbiByZWNvbW1lbmQgc3BlY2lmaWNzLCBhbmQgdGhlcmUgbWF5IGJlIGZ1dHVyZSBvbmVz IGluIHRoZSBmdXR1cmUuIEkgdGhpbmsgd2UgYWxsIGFncmVlIHRoYXQgaW1wbGljaXQgd2l0aG91 dCBhbnkgbWl0aWdhdGlvbiBpcyBwcm9ibGVtYXRpYy4NCj4gPj4NCj4gPj4gSG93IGFib3V0IHdl IHJlY29tbWVuZCBhZ2FpbnN0IHVzaW5nIGltcGxpY2l0IGFsb25lPw0KPiA+Pg0KPiA+Pg0KPiA+ PiBPbiBNb24sIE5vdiAxOSwgMjAxOCBhdCAyOjM0IEFNIEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5u ZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPj4g d3JvdGU6DQo+ID4+IEhpIGFsbCwNCj4gPj4NCj4gPj4gVGhlIGF1dGhvcnMgb2YgdGhlIE9BdXRo IFNlY3VyaXR5IFRvcGljcyBkcmFmdCBjYW1lIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgaXQgaXMg bm90IHBvc3NpYmxlIHRvIGFkZXF1YXRlbHkgc2VjdXJlIHRoZSBpbXBsaWNpdCBmbG93IGFnYWlu c3QgdG9rZW4gaW5qZWN0aW9uIHNpbmNlIHBvdGVudGlhbCBzb2x1dGlvbnMgbGlrZSB0b2tlbiBi aW5kaW5nIG9yIEpBUk0gYXJlIGluIGFuIGVhcmx5IHN0YWdlIG9mIGFkb3B0aW9uLiBGb3IgdGhp cyByZWFzb24sIGFuZCBzaW5jZSBDT1JTIGFsbG93cyBicm93c2VyLWJhc2VkIGFwcHMgdG8gc2Vu ZCByZXF1ZXN0cyB0byB0aGUgdG9rZW4gZW5kcG9pbnQsIFRvcnN0ZW4gc3VnZ2VzdGVkIHRvIHVz ZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2YgdGhlIGltcGxpY2l0IGdyYW50IGlu IGNhbGwgY2FzZXMgaW4gaGlzIHByZXNlbnRhdGlvbiAoc2VlIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbWVldGluZy8xMDMvbWF0ZXJpYWxzL3NsaWRlcy0xMDMtb2F1dGgtc2Vzc2ItZHJh ZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMDEpLg0KPiA+Pg0KPiA+PiBBIGh1bSBpbiB0 aGUgcm9vbSBhdCBJRVRGIzEwMyBjb25jbHVkZWQgc3Ryb25nIHN1cHBvcnQgZm9yIGhpcyByZWNv bW1lbmRhdGlvbnMuIFdlIHdvdWxkIGxpa2UgdG8gY29uZmlybSB0aGUgZGlzY3Vzc2lvbiBvbiB0 aGUgbGlzdC4NCj4gPj4NCj4gPj4gUGxlYXNlIHByb3ZpZGUgYSByZXNwb25zZSBieSBEZWNlbWJl ciAzcmQuDQo+ID4+DQo+ID4+IENpYW8NCj4gPj4NCj4gPj4gSGFubmVzICYgUmlmYWF0DQo+ID4+ DQo+ID4+DQo+ID4+DQo+ID4+IElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlz IGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28g YmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhl IGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9y IHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4N Cj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4NCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoDQo+ID4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0 aEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1 dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQotLQ0KLS0tLQ0KQWFy b24gUGFyZWNraQ0KYWFyb25wYXJlY2tpLmNvbTxodHRwOi8vYWFyb25wYXJlY2tpLmNvbT4NCkBh YXJvbnBrPGh0dHA6Ly90d2l0dGVyLmNvbS9hYXJvbnBrPg0KDQpJTVBPUlRBTlQgTk9USUNFOiBU aGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRl bnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQg ZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQg Zm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkg bWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_TY2PR01MB2876FAC5642380820BCD4BCCF9AC0TY2PR01MB2876jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj48IS0tIFRo aXMgZmlsZSBoYXMgYmVlbiBhdXRvbWF0aWNhbGx5IGdlbmVyYXRlZC4gU2VlIHdlYi9SRUFETUUu bWQgLS0+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImRpcmVjdGlvbjogbHRyOyI+T0F1dGgg TVRMUyBoYXMgYmVlbiBpbXBsZW1lbnRlZCBpbiBCYW5raW5nIGluZHVzdHJ5IHNvIHdlIGhhdmUg YXQgbGVhc3QgYW4gYWx0ZXJuYXRpdmUuDQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJkaXJlY3Rpb246IGx0cjsiPlNlbmRlciBDb25zdHJhaW5lZCBpbmNsdWRlcyBjYXNl cyB3aGVyZSBpdCBpcyBub3Qga2V5IGJvdW5kIGJ1dCBuYW1lIGJvdW5kIGFzIEkgdW5kZXJzdGFu ZCBhbmQgaXQgbWF5IGhhdmUgc29tZSB1dGlsaXR5IHNvIHdlIGYgdGhlcmUgYXJlIGRvdWJ0cywg bWVudGlvbmluZyB0aGUgYm90aCBtYXkgYmUgZ29vZC4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibXMtb3V0bG9vay1pb3Mtc2lnbmF0dXJlIj48YSBocmVm PSJodHRwczovL2FrYS5tcy9vMHVrZWYiPk91dGxvb2sgZm9yIGlPUzwvYT4g44KS5YWl5omLPC9k aXY+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8aHIgc3R5bGU9ImRpc3BsYXk6aW5saW5l LWJsb2NrO3dpZHRoOjk4JSIgdGFiaW5kZXg9Ii0xIj4NCjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ci IGRpcj0iZGlyPSZxdW90O2x0ciZxdW90OyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJp ZiIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0IiBjb2xvcj0iIzAwMDAwMCI+PGI+5beu5Ye65Lq6Ojwv Yj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IChIYW5uZXMgVHNjaG9mZW5p ZyAmbHQ7aGFubmVzLnRzY2hvZmVuaWdAYXJtLmNvbSZndDsg44Gu5Luj55CGKTxicj4NCjxiPumA geS/oeaXpeaZgjo8L2I+IOWcn+abnOaXpSwgMTLmnIggMSwgMjAxOCA2OjA3IOWNiOW+jDxicj4N CjxiPuWum+WFiDo8L2I+IEFhcm9uIFBhcmVja2k7IFRvcnN0ZW4gTG9kZGVyc3RlZHQ8YnI+DQo8 Yj5DYzo8L2I+IERhbmllbCBGZXR0OyBJRVRGIG9hdXRoIFdHPGJyPg0KPGI+5Lu25ZCNOjwvYj4g UmU6IFtPQVVUSC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3Jp emF0aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNpdA0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZm9u dD48L2Rpdj4NCjxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0 YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBt ZWRpdW0pIj4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJy aWEgTWF0aCJ9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFufQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpfQ0KQGZvbnQtZmFjZQ0KCXt9DQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWZ9DQpoNQ0KCXttYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmfQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmV9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmV9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWZ9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZn0NCnNwYW4uSGVhZGluZzVDaGFyDQoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWZvbnQtd2VpZ2h0OmJvbGR9DQouTXNvQ2hwRGVmYXVsdA0KCXtmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZn0NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXttYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW59DQpkaXYuV29yZFNlY3Rpb24xDQoJe30NCi0tPg0KPC9zdHlsZT4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8aDUgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7IGZvbnQtd2VpZ2h0Om5vcm1hbCI+SSBhZ3JlZSB3aXRoIEFhcm9uIGhl cmUgYW5kIEkgdGhpbmsNCjxhIG5hbWU9InNlY3Rpb24tMy44LjEuMiI+U2VjdGlvbiA8L2E+PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJp dHktdG9waWNzLTEwI3NlY3Rpb24tMy44LjEuMiI+PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9 InRleHQtZGVjb3JhdGlvbjpub25lIj4zLjguMS4yPC9zcGFuPjwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9IiI+PC9zcGFuPiBvZiBkcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xMA0KICZu YnNwO2FscmVhZHkgZG9lcyBhIHByZXR0eSBnb29kIGpvYi4gPC9zcGFuPjwvaDU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHdhcywgaG93ZXZlciwgd29uZGVyaW5nIGFib3V0IHRoZSBzdWJ0bGUg aW1wbGljYXRpb24gb2YgdGhlIHJlcXVpcmVtZW50IGZvciBzZW5kZXIgY29uc3RyYWluZWQgdG9r ZW5zLiBNeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSB0b2tlbiBiaW5kaW5nIGRpc2N1c3Npb24sIHdo aWNoIGlzIG9uZSBvZiB0aGUgd2F5cyB0byBwcm92aWRlIHNlbmRlci1jb25zdHJhaW5lZCB0b2tl bnMsIGlzIHRoYXQgd2UgZG9u4oCZdCBoYXZlDQogZ29vZCBmYWl0aCBpbiBzZWVpbmcgZGVwbG95 bWVudCBhbnl0aW1lIHNvb24uIEhlbmNlLCB3ZSBhcmUgZXNzZW50aWFsbHkgKHJlYWRpbmcgaW4g YmV0d2VlbiB0aGUgbGluZXMgb2YgU2VjdGlvbiAzLjguMS4yKSBzYXlpbmcgdGhhdCB5b3UgY2Fu bm90IHVzZSBpbXBsaWNpdCBncmFudCBpbiBhIHByYWN0aWNhbCBzZXR1cCBmb3IgdGhlIHdlYiou PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QW0gSSBtaXN1bmRlcnN0YW5kaW5nIGl0PzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNpYW88L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IYW5uZXM8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5QUzogVGhlIElvVCBjYXNlIGlzIGxpa2VseSBkaWZmZXJlbnQuIDwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBP QXV0aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+ QWFyb24gUGFyZWNraTxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgRGVjZW1iZXIgMSwgMjAx OCAzOjE4IEFNPGJyPg0KPGI+VG86PC9iPiBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDt0b3JzdGVu QGxvZGRlcnN0ZWR0Lm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IERhbmllbCBGZXR0ICZsdDtmZXR0 QGRhbmllbGZldHQuZGUmZ3Q7OyBJRVRGIG9hdXRoIFdHICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNz IC0tIFJlY29tbWVuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNpdDwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MTwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSB3b3VsZCBhbHNvIGxpa2UgdG8gZW5zdXJlIHRoZXJlIGlzIGEgY2xlYXIgZGVm aW5pdGlvbiBvZiAmcXVvdDtzZW5kZXIgY29uc3RyYWluZWQmcXVvdDsgdG9rZW5zIGluIHRoaXMg QkNQLjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFhcm9uPC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBUaHUsIE5vdiAyOSwgMjAxOCBhdCAxMDowNiBBTSBUb3JzdGVuIExvZGRlcnN0 ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiPnRvcnN0ZW5A bG9kZGVyc3RlZHQubmV0PC9hPiZndDsgd3JvdGU6PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7IHBhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7IG1hcmdpbi1sZWZ0OjQuOHB0OyBtYXJnaW4tcmlnaHQ6MGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCwgPGJyPg0KPGJyPg0KYmFzZWQgb24geW91 ciBmZWVkYmFjayBvbiB0aGUgbGlzdCBhbmQgb2ZmIGxpc3QsIERhbmllbCBhbmQgSSBwb2xpc2hl ZCB0aGUgdGV4dC4gVGhhdOKAmXMgb3VyIHByb3Bvc2FsOjxicj4NCjxicj4NCuKAlDxicj4NCklu IG9yZGVyIHRvIGF2b2lkIHRoZXNlIGlzc3VlcywgY2xpZW50cyBNVVNUIE5PVCB1c2UgdGhlIGlt cGxpY2l0PGJyPg0KZ3JhbnQgKHJlc3BvbnNlIHR5cGUgJnF1b3Q7dG9rZW4mcXVvdDspIG9yIGFu eSBvdGhlciByZXNwb25zZSB0eXBlIGlzc3VpbmcgYWNjZXNzIDxicj4NCnRva2VucyBpbiB0aGUg YXV0aG9yaXphdGlvbiByZXNwb25zZSwgc3VjaCBhcyAmcXVvdDt0b2tlbiBpZF90b2tlbiZxdW90 OyBhbmQgJnF1b3Q7Y29kZSB0b2tlbiBpZF90b2tlbuKAnCwNCjxicj4NCnVubGVzcyB0aGUgaXNz dWVkIGFjY2VzcyB0b2tlbnMgYXJlIHNlbmRlci1jb25zdHJhaW5lZCBhbmQgYWNjZXNzIHRva2Vu IGluamVjdGlvbiBpbg0KPGJyPg0KdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UgaXMgcHJldmVu dGVkLiA8YnI+DQrigJQ8YnI+DQo8YnI+DQpFeHBsYW50YXRpb246IDxicj4NCi0gd2Ugd2FudGVk IHRvIGhhdmUgdGhlIHJpZ2h0IGJhbGFuY2UgYmV0d2VlbiBhIGdlbmVyaWMgZGVmaW5pdGlvbiBv ZiB0aGUgcmVzcG9uc2UgdHlwZXMgd2UgZG8gbm90IHJlY29tbWVuZC9hbGxvdyB0byBiZSB1c2Vk IGFuZCBhIGNvbmNyZXRlL2FjdGlvbmFibGUgbGlzdCBvZiB0aGUgYWZmZWN0ZWQgcmVzcG9uc2Ug dHlwZXMuDQo8YnI+DQotIHdlIGNoYW5nZWQgZnJvbSBTSE9VTEQgTk9UIHRvIE1VU1QgTk9UIGFz IHN1Z2dlc3RlZCBieSBOYXQgYW5kIHN1cHBvcnRlZCBieSBXaWxsaWFtPGJyPg0KPGJyPg0KV2Ug bG9vayBmb3J3YXJkIHRvIHNlZWluZyB5b3VyIGZlZWRiYWNrLjxicj4NCjxicj4NCmtpbmQgcmVn YXJkcyw8YnI+DQpUb3JzdGVuLiZuYnNwOyA8YnI+DQo8YnI+DQomZ3Q7IEFtIDI5LjExLjIwMTgg dW0gMTU6MTUgc2NocmllYiBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJA dmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs6PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEkgYW0gb2sgd2l0aCB0aGF0LiZuYnNwOyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgT24gV2VkLCBOb3YgMjgsIDIwMTgsIDg6MDMgUE0gVG9yc3RlbiBMb2RkZXJzdGVk dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9i bGFuayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+IHdyb3RlOjxicj4NCiZndDsgPGJyPg0K Jmd0OyAmZ3Q7IEFtIDI4LjExLjIwMTggdW0gMjM6NTAgc2NocmllYiBuLXNha2ltdXJhICZsdDs8 YSBocmVmPSJtYWlsdG86bi1zYWtpbXVyYUBucmkuY28uanAiIHRhcmdldD0iX2JsYW5rIj5uLXNh a2ltdXJhQG5yaS5jby5qcDwvYT4mZ3Q7Ojxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg VGhhdCB3b3Jrcy48YnI+DQomZ3Q7IDxicj4NCiZndDsgR29vZCE8YnI+DQomZ3Q7IDxicj4NCiZn dDsgSSBqdXN0IHJlYWxpemVkIHRoaXMgdGV4dCBoYXMgYW4gaXNzdWUgd2l0aCDigJ50b2tlbuKA nCAob25seSkuIEl0IHdvdWxkIGFsbG93IOKAnnRva2Vu4oCcIHRvIGJlIHVzZWQgaWYgdGhlIHRv a2VuIHdvdWxkIHNlbmRlciBjb25zdHJhaW5lZC4gVGhpcyBjb21wbGV0ZWx5IGlnbm9yZXMgdGhl IGZhY3QgaW1wbGljaXQgYWxzbyBzaGFsbCBiZSBhYmFuZG9uZWQgYmVjYXVzZSBvZiBpdHMgdnVs bmVyYWJpbGl0eSBmb3IgYWNjZXNzIHRva2VuIGluamVjdGlvbi4NCjxicj4NCiZndDsgPGJyPg0K Jmd0OyBJIHRoZXJlZm9yZSBwcm9wb3NlIGEgbW9kaWZpZWQgdGV4dDogPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyBJbiBvcmRlciB0byBhdm9pZCB0aGVzZSBpc3N1ZXMsIENsaWVu dHMgU0hPVUxEIE5PVCB1c2UgdGhlIGltcGxpY2l0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgZ3Jh bnQuIEZ1cnRoZXJtb3JlLCBjbGllbnRzIFNIT1VMRCBvbmx5IHVzZSBvdGhlciByZXNwb25zZSB0 eXBlcyBjYXVzaW5nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0bzxicj4NCiZndDsmbmJzcDsg Jm5ic3A7IGlzc3VlIGFuIGFjY2VzcyB0b2tlbiBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25z ZSwgaWYgdGhlIHBhcnRpY3VsYXIgcmVzcG9uc2UgdHlwZSBkZXRlY3RzIGFjY2VzcyB0b2tlbg0K PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgaW5qZWN0aW9uIGFuZCB0aGUgaXNzdWVkIGFjY2VzcyB0 b2tlbnMgYXJlIHNlbmRlci1jb25zdHJhaW5lZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgT3Igd2Ug anVzdCBzdGF0ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7SW4gb3JkZXIgdG8g YXZvaWQgdGhlc2UgaXNzdWVzLCBDbGllbnRzIFNIT1VMRCBOT1QgdXNlIHRoZSByZXNwb25zZSB0 eXBlIOKAnnRva2VuJnF1b3Q7LiBUaGUgcmVzcG9uc2UgdHlwZXM8YnI+DQomZ3Q7IOKAnnRva2Vu IGlkX3Rva2Vu4oCcIGFuZCDigJ5jb2RlIHRva2VuIGlkX3Rva2Vu4oCcIFNPVUxEIE5PVCBiZSB1 c2VkLCBpZiB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbnMgYXJlIG5vdA0KPGJyPg0KJmd0OyBzZW5k ZXItY29uc3RyYWluZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 IEluIGZhY3QsIEkgd291bGQgZnVydGhlciBnbyBhbmQgc2F5IE1VU1QgTk9UIGJ1dCB0aGF0IHBy b2JhYmx5IGlzIHRvbyBtdWNoIGZvciBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24uPGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBNaWtlIHN1Z2dlc3RlZCB0byBnbyB3aXRoIGEg U0hPVUxEIE5PVCB0byBnZXQgdGhlIG1lc3NhZ2Ugb3V0IGJ1dCBnaXZlIGltcGxlbWVudG9ycyB0 aW1lIHRvIG1vdmUvY2hhbmdlLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEJlc3QsPGJyPg0K Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBOYXQ8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IE5hdCBTYWtpbXVyYSAvIDxhIGhyZWY9Im1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5qcCIg dGFyZ2V0PSJfYmxhbmsiPm4tc2FraW11cmFAbnJpLmNvLmpwPC9hPiAvICYjNDM7ODEtOTAtNjAx My02Mjc2PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8c3BhbiBsYW5nPSJaSC1DTiIg c3R5bGU9ImZvbnQtZmFtaWx5OkRlbmdYaWFuIj7jgZPjga7jg6Hjg7zjg6vjgavjga/jgIHmnKzm naXjga7lrpvlhYjjga7mlrnjga7jgb/jgavpmZDlrprjgZXjgozjgZ/mqZ/lr4bmg4XloLHjgYzl kKvjgb7jgozjgabjgYTjgovloLTlkIjjgYzjgZTjgZbjgYTjgb7jgZnjgILjgYrlv4PjgYLjgZ/j gorjga7jgarjgYTloLTlkIjjga/jgIHoqqDjgavnlLPjgZfoqLPjgZTjgZbjgYTjgb7jgZvjgpPj gYzjgIHpgIHkv6HogIXjgb7jgafjgYrnn6XjgonjgZvpoILjgY3jgIHjgb7jgZ/lj5fkv6HjgZXj gozjgZ/jg6Hjg7zjg6vjga/liYrpmaTjgZfjgabjgY/jgaDjgZXjgYTjgb7jgZnjgojjgYbjgYrp oZjjgYTnlLPjgZfkuIrjgZLjgb7jgZnjgII8L3NwYW4+PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyBQTEVBU0UgUkVBRCA6VGhpcyBlLW1haWwgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRl bmRlZCBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudCBvbmx5Ljxicj4NCiZndDsgJmd0OyBJZiB5b3Ug YXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgZS1tYWlsLjxicj4NCiZndDsgJmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZn dDsgPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+5beu5Ye6 5Lq6PC9zcGFuPjogVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0 ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5u ZXQ8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyA8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OkRlbmdYaWFuIj7pgIHkv6Hml6XmmYI8L3NwYW4+OiA8c3BhbiBsYW5nPSJaSC1DTiIg c3R5bGU9ImZvbnQtZmFtaWx5OkRlbmdYaWFuIj4NCuawtOabnOaXpTwvc3Bhbj4sIDExPHNwYW4g bGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+5pyIPC9zcGFuPiAyOCwg MjAxOCAxMTozOA0KPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlh biI+5Y2I5b6MPC9zcGFuPjxicj4NCiZndDsgJmd0OyA8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9 ImZvbnQtZmFtaWx5OkRlbmdYaWFuIj7lrpvlhYg8L3NwYW4+OiBuLXNha2ltdXJhPGJyPg0KJmd0 OyAmZ3Q7IENjOiBEaWNrIEhhcmR0OyBIYW5uZXMgVHNjaG9mZW5pZzsgPGEgaHJlZj0ibWFpbHRv Om9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpvYXV0aEBpZXRmLm9yZzwvYT48YnI+ DQomZ3Q7ICZndDsgPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlh biI+5Lu25ZCNPC9zcGFuPjogUmU6IFtPQVVUSC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNzIC0t IFJlY29tbWVuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNpdDxicj4NCiZn dDsgJmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgSGkgTmF0LCA8YnI+DQomZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBBbSAyOC4xMS4yMDE4IHVtIDIxOjEwIHNjaHJpZWIgbi1zYWtpbXVy YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm4tc2FraW11cmFAbnJpLmNvLmpwIiB0YXJnZXQ9Il9ibGFu ayI+bi1zYWtpbXVyYUBucmkuY28uanA8L2E+Jmd0Ozo8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4N CiZndDsgJmd0OyZndDsgSSB3b3VsZCBzdXBwb3J0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQom Z3Q7ICZndDsmZ3Q7IDEpIGNsZWFybHkgZGVmaW5pbmcgSW1wbGljaXQgYXMgdGhlIGZsb3cgdGhh dCByZXR1cm5zIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50ICgg c29tZSBwZW9wbGUgY29uZnVzZXMgaW1wbGljaXQgYXMgdGhlIGZsb3cgdGhhdCByZXR1cm5zIElE IFRva2VuIGluIHRoZSBmcm9udCBjaGFubmVsKTxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgVGhhdOKAmXMgdGhlIGN1cnJlbnQgdGV4dDogPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyBJbiBvcmRlciB0byBhdm9pZCB0aGVzZSBpc3N1ZXMsIENsaWVudHMgU0hPVUxEIE5PVCB1 c2UgdGhlIGltcGxpY2l0PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBncmFudCBvciBhbnkg b3RoZXIgcmVzcG9uc2UgdHlwZSBjYXVzaW5nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0bzxi cj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgaXNzdWUgYW4gYWNjZXNzIHRva2VuIGluIHRoZSBh dXRob3JpemF0aW9uIHJlc3BvbnNlLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgV2hh dCB3b3VsZCB5b3UgbGlrZSB0byBtb2RpZnk/IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgMikgQmFubmluZyB0aGUgcmV0dXJuaW5nIG9mIHRo ZSBhY2Nlc3MgdG9rZW4gdGhhdCBhcmUgbm90IHNlbmRlciBjb25zdHJhaW5lZCBmcm9tIHRoZSBh dXRob3JpemF0aW9uIGVuZHBvaW50PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJbiBv cmRlciB0byBhdm9pZCB0aGVzZSBpc3N1ZXMsIENsaWVudHMgU0hPVUxEIE5PVCB1c2UgdGhlIGlt cGxpY2l0PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBncmFudCBvciBhbnkgb3RoZXIgcmVz cG9uc2UgdHlwZSBjYXVzaW5nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0bzxicj4NCiZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgaXNzdWUgYW4gYWNjZXNzIHRva2VuIGluIHRoZSBhdXRob3JpemF0 aW9uIHJlc3BvbnNlLCBpZiB0aGlzIGFjY2VzcyB0b2tlbnMgaXMgbm90IHNlbmRlci1jb25zdHJh aW50Ljxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgV2hhdCBhYm91dCB0aGlzPzxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsga2luZCByZWdhcmRzLDxicj4NCiZndDsgJmd0OyBU b3JzdGVuLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0 OyZndDsgQmVzdCw8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgTmF0PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsg T3V0bG9vayBmb3IgaU9TIDxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6RGVu Z1hpYW4iPuOCkuWFpeaJizwvc3Bhbj48YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7IDxicj4NCiZn dDsgJmd0OyZndDsgPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlh biI+5beu5Ye65Lq6PC9zcGFuPjogT0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4m Z3Q7IChEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7DQo8c3BhbiBsYW5n PSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OkRlbmdYaWFuIj7jga7ku6PnkIY8L3NwYW4+KTxi cj4NCiZndDsgJmd0OyZndDsgPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpE ZW5nWGlhbiI+6YCB5L+h5pel5pmCPC9zcGFuPjogPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJm b250LWZhbWlseTpEZW5nWGlhbiI+DQrmsLTmm5zml6U8L3NwYW4+LCAxMTxzcGFuIGxhbmc9IlpI LUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6RGVuZ1hpYW4iPuaciDwvc3Bhbj4gMjgsIDIwMTggODo1 OA0KPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+5Y2I5b6M PC9zcGFuPjxicj4NCiZndDsgJmd0OyZndDsgPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250 LWZhbWlseTpEZW5nWGlhbiI+5a6b5YWIPC9zcGFuPjogSGFubmVzIFRzY2hvZmVuaWc8YnI+DQom Z3Q7ICZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7IDxzcGFuIGxhbmc9 IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6RGVuZ1hpYW4iPuS7tuWQjTwvc3Bhbj46IFJlOiBb T0FVVEgtV0ddIE9BdXRoIFNlY3VyaXR5IFRvcGljcyAtLSBSZWNvbW1lbmQgYXV0aG9yaXphdGlv biBjb2RlIGluc3RlYWQgb2YgaW1wbGljaXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7IDxicj4N CiZndDsgJmd0OyZndDsgJiM0MzsxPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsm Z3Q7IFdoaWxlIHRoZXJlIGFyZSB2YXJpb3VzIG1lY2hhbmlzbXMgdG8gYWxsZXZpYXRlIHNvbWUg b2YgdGhlIGlzc3VlcyBvZiBpbXBsaWNpdCwgSSBkb24ndCB0aGluayB3ZSBjYW4gcmVjb21tZW5k IHNwZWNpZmljcywgYW5kIHRoZXJlIG1heSBiZSBmdXR1cmUgb25lcyBpbiB0aGUgZnV0dXJlLiBJ IHRoaW5rIHdlIGFsbCBhZ3JlZSB0aGF0IGltcGxpY2l0IHdpdGhvdXQgYW55IG1pdGlnYXRpb24g aXMgcHJvYmxlbWF0aWMuDQo8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsg SG93IGFib3V0IHdlIHJlY29tbWVuZCBhZ2FpbnN0IHVzaW5nIGltcGxpY2l0IGFsb25lPyA8YnI+ DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBP biBNb24sIE5vdiAxOSwgMjAxOCBhdCAyOjM0IEFNIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBo cmVmPSJtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkhh bm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7 IEhpIGFsbCw8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgVGhlIGF1dGhv cnMgb2YgdGhlIE9BdXRoIFNlY3VyaXR5IFRvcGljcyBkcmFmdCBjYW1lIHRvIHRoZSBjb25jbHVz aW9uIHRoYXQgaXQgaXMgbm90IHBvc3NpYmxlIHRvIGFkZXF1YXRlbHkgc2VjdXJlIHRoZSBpbXBs aWNpdCBmbG93IGFnYWluc3QgdG9rZW4gaW5qZWN0aW9uIHNpbmNlIHBvdGVudGlhbCBzb2x1dGlv bnMgbGlrZSB0b2tlbiBiaW5kaW5nIG9yIEpBUk0gYXJlIGluIGFuIGVhcmx5IHN0YWdlIG9mIGFk b3B0aW9uLiBGb3IgdGhpcw0KIHJlYXNvbiwgYW5kIHNpbmNlIENPUlMgYWxsb3dzIGJyb3dzZXIt YmFzZWQgYXBwcyB0byBzZW5kIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludCwgVG9yc3Rl biBzdWdnZXN0ZWQgdG8gdXNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiB0aGUg aW1wbGljaXQgZ3JhbnQgaW4gY2FsbCBjYXNlcyBpbiBoaXMgcHJlc2VudGF0aW9uIChzZWUNCjxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDMvbWF0ZXJpYWxz L3NsaWRlcy0xMDMtb2F1dGgtc2Vzc2ItZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3Mt MDEiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGlu Zy8xMDMvbWF0ZXJpYWxzL3NsaWRlcy0xMDMtb2F1dGgtc2Vzc2ItZHJhZnQtaWV0Zi1vYXV0aC1z ZWN1cml0eS10b3BpY3MtMDE8L2E+KS48YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0 OyZndDsgQSBodW0gaW4gdGhlIHJvb20gYXQgSUVURiMxMDMgY29uY2x1ZGVkIHN0cm9uZyBzdXBw b3J0IGZvciBoaXMgcmVjb21tZW5kYXRpb25zLiBXZSB3b3VsZCBsaWtlIHRvIGNvbmZpcm0gdGhl IGRpc2N1c3Npb24gb24gdGhlIGxpc3QuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZn dDsmZ3Q7IFBsZWFzZSBwcm92aWRlIGEgcmVzcG9uc2UgYnkgRGVjZW1iZXIgM3JkLjxicj4NCiZn dDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBDaWFvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7ICZndDsmZ3Q7IEhhbm5lcyAmYW1wOyBSaWZhYXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7 IDxicj4NCiZndDsgJmd0OyZndDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7 ICZndDsmZ3Q7IElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmls ZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRz IHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55DQogcHVycG9zZSwgb3Igc3RvcmUg b3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Ljxicj4NCiZn dDsgJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7ICZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyZn dDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhA aWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAm Z3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Im1h aWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxi cj4NCiZndDsgJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxi cj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLTwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFhcm9uIFBhcmVja2k8L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vYWFyb25wYXJlY2tpLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmFhcm9ucGFyZWNraS5jb208L2E+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3R3aXR0ZXIuY29tL2Fhcm9ucGsi IHRhcmdldD0iX2JsYW5rIj5AYWFyb25wazwvYT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQpJTVBPUlRB TlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVy c29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9y bWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4gPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_TY2PR01MB2876FAC5642380820BCD4BCCF9AC0TY2PR01MB2876jpnp_-- From nobody Sat Dec 1 04:01:22 2018 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 E6BBD12D4F2 for ; Sat, 1 Dec 2018 04:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 L8Neq_tBnsbG for ; Sat, 1 Dec 2018 04:01:17 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) (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 A8CFD12F1A5 for ; Sat, 1 Dec 2018 04:01:16 -0800 (PST) Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gT3xR-0000Kg-30; Sat, 01 Dec 2018 13:01:13 +0100 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7A3D167A-D273-42E4-942B-D3D962DF4036"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Sat, 1 Dec 2018 13:01:11 +0100 In-Reply-To: Cc: Aaron Parecki , Daniel Fett , IETF oauth WG To: Hannes Tschofenig References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 01 Dec 2018 12:01:21 -0000 --Apple-Mail=_7A3D167A-D273-42E4-942B-D3D962DF4036 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Hannes, > Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig = : >=20 > I agree with Aaron here and I think Section 3.8.1.2 of = draft-ietf-oauth-security-topics-10 already does a pretty good job.=20 my proposal is to add the following definition (based on 3.8.1.2) to a = new =E2=80=9ETerminology" section or to section 2.1.2: A sender constrained access token scopes the applicability of an access = token to a certain sender. This sender is obliged to demonstrate knowledge of a certain secret as prerequisite for = the acceptance of that token at the recipient (e.g. a resource server). >=20 > I was, however, wondering about the subtle implication of the = requirement for sender constrained tokens. My understanding of the token = binding discussion, which is one of the ways to provide = sender-constrained tokens, is that we don=E2=80=99t have good faith in = seeing deployment anytime soon. Hence, we are essentially (reading in = between the lines of Section 3.8.1.2) saying that you cannot use = implicit grant in a practical setup for the web*. The text shall convey that implicit must not be used at all. The main = reason being it is unprotected against token injection and additionally = also cannot sender constrain tokens.=20 The second part of the statement relates to other response types and = conditionally opens the MUST NOT in case they are protected against = injection (which is true for the listed response types) and can issue = sender constrained tokens (which does not work today but might work in = the future).=20 kind regards, Torsten.=20 > =20 > Am I misunderstanding it? > =20 > Ciao > Hannes > =20 > PS: The IoT case is likely different.=20 > =20 > From: OAuth On Behalf Of Aaron Parecki > Sent: Saturday, December 1, 2018 3:18 AM > To: Torsten Lodderstedt > Cc: Daniel Fett ; IETF oauth WG > Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend = authorization code instead of implicit > =20 > +1 > =20 > I would also like to ensure there is a clear definition of "sender = constrained" tokens in this BCP. > =20 > Aaron > =20 > =20 > On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt = wrote: > Hi all,=20 >=20 > based on your feedback on the list and off list, Daniel and I polished = the text. That=E2=80=99s our proposal: >=20 > =E2=80=94 > In order to avoid these issues, clients MUST NOT use the implicit > grant (response type "token") or any other response type issuing = access=20 > tokens in the authorization response, such as "token id_token" and = "code token id_token=E2=80=9C,=20 > unless the issued access tokens are sender-constrained and access = token injection in=20 > the authorization response is prevented.=20 > =E2=80=94 >=20 > Explantation:=20 > - we wanted to have the right balance between a generic definition of = the response types we do not recommend/allow to be used and a = concrete/actionable list of the affected response types.=20 > - we changed from SHOULD NOT to MUST NOT as suggested by Nat and = supported by William >=20 > We look forward to seeing your feedback. >=20 > kind regards, > Torsten. =20 >=20 > > Am 29.11.2018 um 15:15 schrieb John Bradley : > >=20 > > I am ok with that. =20 > >=20 > > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt = >=20 > > > Am 28.11.2018 um 23:50 schrieb n-sakimura : > > >=20 > > > That works. > >=20 > > Good! > >=20 > > I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C = (only). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token = would sender constrained. This completely ignores the fact implicit also = shall be abandoned because of its vulnerability for access token = injection.=20 > >=20 > > I therefore propose a modified text:=20 > >=20 > > In order to avoid these issues, Clients SHOULD NOT use the = implicit > > grant. Furthermore, clients SHOULD only use other response types = causing the authorization server to > > issue an access token in the authorization response, if the = particular response type detects access token=20 > > injection and the issued access tokens are sender-constrained. > >=20 > > Or we just state: > >=20 > > In order to avoid these issues, Clients SHOULD NOT use the = response type =E2=80=9Etoken". The response types > > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=80= =9C SOULD NOT be used, if the issued access tokens are not=20 > > sender-constrained. > >=20 > > >=20 > > > In fact, I would further go and say MUST NOT but that probably is = too much for a security consideration. > > >=20 > >=20 > > Mike suggested to go with a SHOULD NOT to get the message out but = give implementors time to move/change. > >=20 > > > Best, > > >=20 > > > Nat > > >=20 > > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276 > > >=20 > > > = =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=E6= =9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=81= =BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=86= =E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=E3= =82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81= =99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=AA= =E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=E3= =81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=81= =8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=A5= =E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=E4= =BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=89= =8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=BE= =E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=E4= =B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 > > >=20 > > > PLEASE READ :This e-mail is confidential and intended for the = named recipient only. > > > If you are not an intended recipient, please notify the sender and = delete this e-mail. > > > =20 > > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt = > > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, = 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C > > > =E5=AE=9B=E5=85=88: n-sakimura > > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org > > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- = Recommend authorization code instead of implicit > > > =20 > > > Hi Nat,=20 > > >=20 > > >> Am 28.11.2018 um 21:10 schrieb n-sakimura : > > >>=20 > > >> I would support > > >>=20 > > >> 1) clearly defining Implicit as the flow that returns access = token from the authorization endpoint ( some people confuses implicit as = the flow that returns ID Token in the front channel) > > >=20 > > > That=E2=80=99s the current text:=20 > > >=20 > > > In order to avoid these issues, Clients SHOULD NOT use the = implicit > > > grant or any other response type causing the authorization = server to > > > issue an access token in the authorization response. > > >=20 > > > What would you like to modify?=20 > > >=20 > > >>=20 > > >> 2) Banning the returning of the access token that are not sender = constrained from the authorization endpoint > > >=20 > > > In order to avoid these issues, Clients SHOULD NOT use the = implicit > > > grant or any other response type causing the authorization = server to > > > issue an access token in the authorization response, if this = access tokens is not sender-constraint. > > >=20 > > > What about this? > > >=20 > > > kind regards, > > > Torsten. > > >=20 > > >>=20 > > >> Best, > > >>=20 > > >> Nat > > >>=20 > > >>=20 > > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B > > >> =20 > > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth (Dick = Hardt =E3=81=AE=E4=BB=A3=E7=90=86) > > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, = 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C > > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig > > >> Cc: oauth@ietf.org > > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- = Recommend authorization code instead of implicit > > >> =20 > > >> +1 > > >>=20 > > >> While there are various mechanisms to alleviate some of the = issues of implicit, I don't think we can recommend specifics, and there = may be future ones in the future. I think we all agree that implicit = without any mitigation is problematic.=20 > > >>=20 > > >> How about we recommend against using implicit alone?=20 > > >>=20 > > >>=20 > > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig = wrote: > > >> Hi all, > > >>=20 > > >> The authors of the OAuth Security Topics draft came to the = conclusion that it is not possible to adequately secure the implicit = flow against token injection since potential solutions like token = binding or JARM are in an early stage of adoption. For this reason, and = since CORS allows browser-based apps to send requests to the token = endpoint, Torsten suggested to use the authorization code instead of the = implicit grant in call cases in his presentation (see = https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-= draft-ietf-oauth-security-topics-01). > > >>=20 > > >> A hum in the room at IETF#103 concluded strong support for his = recommendations. We would like to confirm the discussion on the list. > > >>=20 > > >> Please provide a response by December 3rd. > > >>=20 > > >> Ciao > > >>=20 > > >> Hannes & Rifaat > > >>=20 > > >> =20 > > >>=20 > > >> 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 = the information in any medium. Thank you. > > >> _______________________________________________ > > >> 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 > > >=20 > >=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 > --=20 > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > =20 > 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 = the information in any medium. Thank you. --Apple-Mail=_7A3D167A-D273-42E4-942B-D3D962DF4036 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODEyMDExMjAxMTJaMC8GCSqGSIb3DQEJBDEiBCCb 0uYzyKhA/0Mv1fbbU9+RrQd4xg8TSk53RLkMbo9nTTCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAP1v9Uq7o9G7TEf/yVGY6lPoZ PsjQMt3blNHXi30WqpWHZsLNfIBFp5NgxqPgzUMpi+elT85aIeXd59/vLu3xRqU5Ryzj+DFIyoLr eLlaDZgRqDU6stYKktN/ySAwIxU88g4q6HcbknVumr7gg2ipGOrMTjXBl6REgQvIG5Jvyh5XljPO tdfUqLevieH5mOTMTT4DZiSIZB8AQyZ2A+lXmnuWloJbZpp7P+OLQ6iLs/Y04O1AMpPpUuOEFZzW NXJiXIOtZXzBz8vReG+f3v7A0Xu5JOBnOOEeJ4+dkRMp0twff2y7dJ6AaFm6Bv6HSEHmGT+ykgya mDuJda/EJ9VNXQAAAAAAAA== --Apple-Mail=_7A3D167A-D273-42E4-942B-D3D962DF4036-- From nobody Sat Dec 1 06:34:21 2018 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 380A9127B92 for ; Sat, 1 Dec 2018 06:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 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_H3=0.001, RCVD_IN_MSPIKE_WL=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 mHzQerU0SXnf for ; Sat, 1 Dec 2018 06:34:16 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.28]) (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 2827C128BCC for ; Sat, 1 Dec 2018 06:34:15 -0800 (PST) Received: from [80.187.81.0] (helo=[10.120.12.75]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gT6LT-00008l-OC; Sat, 01 Dec 2018 15:34:11 +0100 Content-Type: multipart/signed; boundary=Apple-Mail-94040A08-79C2-4EC7-998C-66EF6E22EFFD; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Sat, 1 Dec 2018 15:34:10 +0100 Cc: Brian Campbell , oauth Content-Transfer-Encoding: 7bit Message-Id: References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> To: Hannes Tschofenig X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 01 Dec 2018 14:34:20 -0000 --Apple-Mail-94040A08-79C2-4EC7-998C-66EF6E22EFFD Content-Type: multipart/alternative; boundary=Apple-Mail-144372C9-817D-4850-8EFD-2FCD46F2BF2F Content-Transfer-Encoding: 7bit --Apple-Mail-144372C9-817D-4850-8EFD-2FCD46F2BF2F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable IMHO the best mechanism at hand currently to cope with token leakage/replay i= n SPAs is to use refresh tokens (rotating w/ replay detection) and issue sho= rt living and privilege restricted access tokens. Sender constrained access tokens in SPAs need adoption of token binding or a= lternative mechanism. mtls could potentially work in deployments with automa= ted cert rollout but browser UX and interplay with fetch needs some work. We= potentially must consider to warm up application level PoP mechanisms in co= njunction with web crypto. Another path to be evaluated could be web auth. > Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig : >=20 > I share the concern Brian has, which is also the conclusion I came up with= in my other email sent a few minutes ago. > =20 > From: OAuth On Behalf Of Brian Campbell > Sent: Friday, November 30, 2018 11:43 PM > To: Torsten Lodderstedt > Cc: oauth > Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 > =20 > =20 >=20 > On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt wrote: > > Am 15.11.2018 um 23:01 schrieb Brock Allen : > >=20 > > So you mean at the resource server ensuring the token was really issued t= o the client? Isn't that an inherent limitation of all bearer tokens (modulo= HTTP token binding, which is still some time off)? >=20 > Sure. That=E2=80=99s why the Security BCP recommends use of TLS-based meth= ods for sender constraining access tokens (https://tools.ietf.org/html/draft= -ietf-oauth-security-topics-09#section-2..2). Token Binding for OAuth (https= ://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mutual T= LS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the o= ptions available. > =20 > Unfortunately even when using the token endpoint, for SPA / in-browser cli= ent applications, the potential mechanisms for sender/key-constraining acces= s tokens don't work very well or maybe don't work at all. So I don't know th= at the recommendation is very realistic. > =20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. > IMPORTANT NOTICE: The contents of this email and any attachments are confi= dential 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 o= ther person, use it for any purpose, or store or copy the information in any= medium. Thank you. --Apple-Mail-144372C9-817D-4850-8EFD-2FCD46F2BF2F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
IMH= O the best mechanism at hand currently to cope with token leakage/replay in S= PAs is to use refresh tokens (rotating w/ replay detection) and issue short l= iving and privilege restricted access tokens.

Sender constrained access tokens in SPAs need adoption of= token binding or alternative mechanism. mtls could potentially work in depl= oyments with automated cert rollout but browser UX and interplay with fetch n= eeds some work. We potentially must consider to warm up application level Po= P mechanisms in conjunction with web crypto. Another path to be evaluated co= uld be web auth.

Am 01.12.2018 um 10:15 schrieb Ha= nnes Tschofenig <Hannes.Tsch= ofenig@arm.com>:

I share the concern Brian has, which is also the conc= lusion I came up with in my other email sent a few minutes ago.

 

From: OAuth <oauth-bounces@i= etf.org> On Behalf Of Brian Campbell
Sent: Friday, November 30, 2018 11:43 PM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>= ;
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

 

 

On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt &= lt;torsten@lodd= erstedt.net> wrote:

> Am 15.11.2018 um 23:01 schrieb Brock Allen <<= a href=3D"mailto:brockallen@gmail.com" target=3D"_blank">brockallen@gmail.co= m>:
>
> So you mean at the resource server ensuring the token was really issued= to the client? Isn't that an inherent limitation of all bearer tokens (modu= lo HTTP token binding, which is still some time off)?

Sure. That=E2=80=99s why the Security BCP recommends use of TLS-based method= s for sender constraining access tokens (http= s://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2= ). Token Binding for OAuth (https://tools.ietf.org/html/draft= -ietf-oauth-token-binding-08) as well as Mutual TLS for OAuth (htt= ps://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options available.

 

Unfortunately even when using the token endpoint, for= SPA / in-browser client applications, the potential mechanisms for sender/k= ey-constraining access tokens don't work very well or maybe don't work at al= l. So I don't know that the recommendation is very realistic.

 


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

IMPORTANT NOTICE: The contents of this email and any attachments are confide= ntial and may also be privileged. If you are not the intended recipient, ple= ase notify the sender immediately and do not disclose the contents to any ot= her person, use it for any purpose, or store or copy the information in any medium. Thank you.
= --Apple-Mail-144372C9-817D-4850-8EFD-2FCD46F2BF2F-- --Apple-Mail-94040A08-79C2-4EC7-998C-66EF6E22EFFD Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCocw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIFRTCCBC2gAwIBAgIQM9uaxqrCN5lrc/ED e5nwtDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE3MDEwOTAwMDAwMFoXDTE4MDEwOTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYX dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCu wZLNnLP0ur1JFb1K97kryfmVaGmU4ITocfeAzJ7XYOM6mQUVm3Rvve3bsbXteynpZTEeE169/tyT QBSm9hQ8IcGpUYlIhYX2FYChIUKBAAI6iH9wMVvPPU+wxjwSXs6Yi6zgle1jj9V2hIiEU/eHMBNs 0CDfYqn43y+1O4pPBuCeLMlLLNlNiuy22fcubBjXsdT5T29eWgy6zlT+WfgANnHTPLINKwDqC0/F dgmluBJOcdyRVnnN9HzSC4hnnfxjaqqyq3lVpJFJHahDMT8cROQpz+h09WGoGtcvK+dIWQI+sBdX Tuty/CQ+8dl5hW7hB1VbI7YchDiLbH2vmbtLAgMBAAGjggH1MIIB8TAfBgNVHSMEGDAWgBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU+eAeBXE5nsZKOL8hbhgkwGPTY8cwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy ZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCIGA1UdEQQbMBmB F3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IBAQACa57IeOLIvWpiB976 FVKwa4qWBy+MIB8bwlqrjy0LQiM/ykf+0aLi4v0IdV8udXeksOeODoza6+kQGntytllydI8t5Wyz 62SHC/4XshJhDJPh+U2SpVRvyd97BsI9wg3Xc5t+lTuuVeghqsQSmVCjhK7KZhWW5DFMs4UqblA4 wXgkEzD+uPLi33knsx2n00VTNCso8kNonYmv9NxNcVyMu81WYwGMrT3n1r2/X/WaJEd3UMGxOHUq 8GKAQ5Q0zG9Pm5S0Hr+2KgNmoEMOTwa92ej/GbJ7diJqxLsmAxESrlZxeqlYa7mQwVkwY8S/I8d4 Fl6rHHdqZ/giZWdnpa+DMYID0DCCA8wCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMjAxMTQzNDEwWjAvBgkqhkiG 9w0BCQQxIgQgh5fqmxsdYgvsKz1jdwC7cDeT18bqbW5zNL12WGN5NOEwgcEGCSsGAQQBgjcQBDGB szCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3 mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAECx AFRyUyflH+dCfigxAAAtnSfz5baO79d/viO0yOW4XfUb8opai50KJ2t0dnibYM0xpH8Zo4i21Gz/ t/wSG+3xQhUHUYOy6CObIEgOfBTEYmqvz+xbsjHlkm+uNj0Mx4AFmZ4nGrEqnbXZNzdkAnB4xzIr Wwa1sQRaythxmHkTbmIBCPBRb5foo4QybPK6Zx1mB9d/c44ar82h9I/HvG4RO97aEj5V3DWIeCHk VRF+5Fbg+MZFGlEPKLW1NF25I637GBd5obIZM2qEby532UpHNT4Vd8+fLG+G5b9CHJeuMF7aflqZ 9cFXu98VaZKXZ6SXD6akF4k1b5O4I195LQ8AAAAAAAA= --Apple-Mail-94040A08-79C2-4EC7-998C-66EF6E22EFFD-- From nobody Sat Dec 1 07:25:17 2018 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 845AE128BCC for ; Sat, 1 Dec 2018 07:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_SORBS_WEB=1.5, 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 unIVk7FMOD7x for ; Sat, 1 Dec 2018 07:25:14 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) (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 3B1E2128B14 for ; Sat, 1 Dec 2018 07:25:14 -0800 (PST) Received: from [80.187.102.166] (helo=[10.43.255.149]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gT78o-0002Vv-CQ; Sat, 01 Dec 2018 16:25:10 +0100 Content-Type: multipart/signed; boundary=Apple-Mail-64E40163-6160-4956-B1FB-9F153C94754D; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (16B92) In-Reply-To: Date: Sat, 1 Dec 2018 16:25:09 +0100 Cc: Brian Campbell , oauth Content-Transfer-Encoding: 7bit Message-Id: <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> To: Hannes Tschofenig X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 01 Dec 2018 15:25:16 -0000 --Apple-Mail-64E40163-6160-4956-B1FB-9F153C94754D Content-Type: multipart/alternative; boundary=Apple-Mail-1D1F9F59-EC42-4E83-B068-B9D95E320B8E Content-Transfer-Encoding: 7bit --Apple-Mail-1D1F9F59-EC42-4E83-B068-B9D95E320B8E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I forgot to mention another (architectural) option: split an application int= o frontend provided by JS in the browser and a backend, which takes care of t= he business logic and handles tokens and API access. Replay detection at the= interface between SPA and backend can utilize standard web techniques (see O= WASP). The backend in turn can use mTLS for sender constraining. > Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt : >=20 > IMHO the best mechanism at hand currently to cope with token leakage/repla= y in SPAs is to use refresh tokens (rotating w/ replay detection) and issue s= hort living and privilege restricted access tokens. >=20 > Sender constrained access tokens in SPAs need adoption of token binding or= alternative mechanism. mtls could potentially work in deployments with auto= mated cert rollout but browser UX and interplay with fetch needs some work. W= e potentially must consider to warm up application level PoP mechanisms in c= onjunction with web crypto. Another path to be evaluated could be web auth. >=20 >> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig : >>=20 >> I share the concern Brian has, which is also the conclusion I came up wit= h in my other email sent a few minutes ago. >> =20 >> From: OAuth On Behalf Of Brian Campbell >> Sent: Friday, November 30, 2018 11:43 PM >> To: Torsten Lodderstedt >> Cc: oauth >> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 >> =20 >> =20 >>=20 >> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt wrote: >> > Am 15.11.2018 um 23:01 schrieb Brock Allen : >> >=20 >> > So you mean at the resource server ensuring the token was really issued= to the client? Isn't that an inherent limitation of all bearer tokens (modu= lo HTTP token binding, which is still some time off)? >>=20 >> Sure. That=E2=80=99s why the Security BCP recommends use of TLS-based met= hods for sender constraining access tokens (https://tools.ietf.org/html/draf= t-ietf-oauth-security-topics-09#section-2..2). Token Binding for OAuth (http= s://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mutual= TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are th= e options available. >> =20 >> Unfortunately even when using the token endpoint, for SPA / in-browser cl= ient applications, the potential mechanisms for sender/key-constraining acce= ss tokens don't work very well or maybe don't work at all. So I don't know t= hat the recommendation is very realistic. >> =20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >> IMPORTANT NOTICE: The contents of this email and any attachments are conf= idential 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 o= ther 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 --Apple-Mail-1D1F9F59-EC42-4E83-B068-B9D95E320B8E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I f= orgot to mention another (architectural) option: split an application into f= rontend provided by JS in the browser and a backend, which takes care of the= business logic and handles tokens and API access. Replay detection at the i= nterface between SPA and backend can utilize standard web techniques (see OW= ASP). The backend in turn can use mTLS for sender constraining.

Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <torsten@lodderstedt.net>:

=
IMHO the best mechanism at hand currently to cope with token leaka= ge/replay in SPAs is to use refresh tokens (rotating w/ replay detection) an= d issue short living and privilege restricted access tokens.

Sender constrained access tokens in SPAs ne= ed adoption of token binding or alternative mechanism. mtls could potentiall= y work in deployments with automated cert rollout but browser UX and interpl= ay with fetch needs some work. We potentially must consider to warm up appli= cation level PoP mechanisms in conjunction with web crypto. Another path to b= e evaluated could be web auth.

Am 01.12.2018 um 10= :15 schrieb Hannes Tschofenig <Hannes.Tschofenig@arm.com>:

I share the concern Brian has, which is also the conc= lusion I came up with in my other email sent a few minutes ago.

 

From: OAuth <oauth-bounces@i= etf.org> On Behalf Of Brian Campbell
Sent: Friday, November 30, 2018 11:43 PM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>= ;
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

 

 

On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt &= lt;torsten@lodd= erstedt.net> wrote:

> Am 15.11.2018 um 23:01 schrieb Brock Allen <<= a href=3D"mailto:brockallen@gmail.com" target=3D"_blank">brockallen@gmail.co= m>:
>
> So you mean at the resource server ensuring the token was really issued= to the client? Isn't that an inherent limitation of all bearer tokens (modu= lo HTTP token binding, which is still some time off)?

Sure. That=E2=80=99s why the Security BCP recommends use of TLS-based method= s for sender constraining access tokens (http= s://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2= ). Token Binding for OAuth (https://tools.ietf.org/html/draft= -ietf-oauth-token-binding-08) as well as Mutual TLS for OAuth (htt= ps://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options available.

 

Unfortunately even when using the token endpoint, for= SPA / in-browser client applications, the potential mechanisms for sender/k= ey-constraining access tokens don't work very well or maybe don't work at al= l. So I don't know that the recommendation is very realistic.

 


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

IMPORTANT NOTICE: The contents of this email and any attachments are confide= ntial and may also be privileged. If you are not the intended recipient, ple= ase notify the sender immediately and do not disclose the contents to any ot= her person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
O= Auth mailing list
OAuth@ie= tf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-1D1F9F59-EC42-4E83-B068-B9D95E320B8E-- --Apple-Mail-64E40163-6160-4956-B1FB-9F153C94754D Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBT4w ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MYIDyjCCA8YCAQEwga0wgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQME AgEFAKCCAe0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMjAx MTUyNTA5WjAvBgkqhkiG9w0BCQQxIgQgozHbtIlbBbLE1EReCy0VTmDlQuSOQnsMuhn4RhC/MKQw gb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCBlzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEB AQUABIIBAIWyFIdvpwkjgFsMLskhuOQLZ6DhwwCwUn8qXFbqkQ3f3xpwi4DDN4mTxlA6ylW8uIf1 BLpnE08Vk/HciBiHffd2oNr7jZVPvtyzuA2GUbpyGjpzmFWcO9RiYU6exJ3JmYolTKCWl4WANDcU kYK5Ye0XEfbTFXsahhoQyHBaH48GUM8tBRRXe9qWhkjl9bgdbm7BR0OzYi/3t5SERr/JxcQqezfg RDOOm8oPvomzHi7GzOXfvIQMYiha/v6aex6/+agmvOSi3gKy2L46y8l4JORVKoBHvXQg6J8PzXmi uU5kslbJk7n5NWF/ZFY9w92pwXzBYZtfJcg4ZlZHB7olky4AAAAAAAA= --Apple-Mail-64E40163-6160-4956-B1FB-9F153C94754D-- From nobody Sat Dec 1 15:44:46 2018 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 197FB130E67 for ; Sat, 1 Dec 2018 15:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=ve7jtb-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 vp0Tf7imq60W for ; Sat, 1 Dec 2018 15:44:40 -0800 (PST) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 7ED2E130E66 for ; Sat, 1 Dec 2018 15:44:40 -0800 (PST) Received: by mail-ed1-x532.google.com with SMTP id z28so7765184edi.8 for ; Sat, 01 Dec 2018 15:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=mTlYtw7t7ep0X+FgTUDWxRe/U6VDkJQ8z5XZkGApnHc=; b=MBPT6MwHObADz1kzohFAqt3mmQIaKsYu0vOdkXA7uRtBUP9ezIiohb13//7qrkfxzq dVE9rMNLNfudLrluMXGitqhwhR4LwUtkRm+KNdusHmztsE0igFAgYPtBBWxV3b/97NBS h4d85tHZ3yXE8NYFXMJovAtcwHQiwJ2X2NyhcjsItBxTZBZt5HXIG0eLCKqg9boyW5ey KsNRXe3PoKYq3AHb8F90YYd3IeBMbxNuJPlGggy1nTC52+pI9Hs9zF4r3vpufx5mFZGw i6yVYoTHl/Fyd7tt2Zm8wKt2s6dWOFHz6vgveapq/GvxEXIhr46tbmYmbrgv6IgQG42G d+Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=mTlYtw7t7ep0X+FgTUDWxRe/U6VDkJQ8z5XZkGApnHc=; b=UnrOuvB1SIrVD03bOAFRukt6PsarPrc+YCm/JPbAUU+7sO4bLCysjas3g3ncWLlPDz 8jomplG71j+ss+gTbOn0PUDit+Bjx3+j9c+63V4oD72DJ/gMIpXLOGRdC73w9oGje+OG ZIOZ9xkpdeMuD3Mw/Nu8wYxaHRFH9P+wsYWsoZgrq7oEkHxbiwMfTnRg11Wr4D+q8TwR 2m4wPLZW04078bUue6QbKiPRtpY7RivJBPe7YChqaxE8cm4Z+BQzL19b2xFP7/TNVXFb 4JTNVfVly1uKUT9rqRIydcEekpgZMFg3txiLjM1yiMKZdsNXcrEsfhLYOpwcyp3G8Fly JODQ== X-Gm-Message-State: AA+aEWaG8eYIRF5GUSY/YhMIozSXAqx2wIlzFwa2FQtBxAK3ShSD3SG8 gneInCVeVDZHXm0Z1Kcj7GMYOEksnkmEag== X-Google-Smtp-Source: AFSGD/Wm3BA3FHT1vobLQwq6lOB4kRZmP+FepXIVP9PTg2V9N+svqLUMuv5NhMVEuiT6zJc2ZUuCAg== X-Received: by 2002:a17:906:138d:: with SMTP id f13-v6mr8571420ejc.176.1543707878001; Sat, 01 Dec 2018 15:44:38 -0800 (PST) Received: from [10.38.11.6] ([212.92.123.75]) by smtp.gmail.com with ESMTPSA id c12sm2487578edi.52.2018.12.01.15.44.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Dec 2018 15:44:37 -0800 (PST) From: John Bradley X-Google-Original-From: John Bradley To: oauth@ietf.org References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> Message-ID: Date: Sat, 1 Dec 2018 20:44:37 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Thunderbird/64.0 MIME-Version: 1.0 In-Reply-To: <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> Content-Type: multipart/alternative; boundary="------------A81C86C0D638F27B4338D15C" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 01 Dec 2018 23:44:44 -0000 This is a multi-part message in MIME format. --------------A81C86C0D638F27B4338D15C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit How is that different from a regular server client with a web interface if the backed is doing the API calls to the RS? On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: > I forgot to mention another (architectural) option: split an > application into frontend provided by JS in the browser and a backend, > which takes care of the business logic and handles tokens and API > access. Replay detection at the interface between SPA and backend can > utilize standard web techniques (see OWASP). The backend in turn can > use mTLS for sender constraining. > > Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt > >: > >> IMHO the best mechanism at hand currently to cope with token >> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay >> detection) and issue short living and privilege restricted access tokens. >> >> Sender constrained access tokens in SPAs need adoption of token >> binding or alternative mechanism. mtls could potentially work in >> deployments with automated cert rollout but browser UX and interplay >> with fetch needs some work. We potentially must consider to warm up >> application level PoP mechanisms in conjunction with web crypto. >> Another path to be evaluated could be web auth. >> >> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig >> >: >> >>> I share the concern Brian has, which is also the conclusion I came >>> up with in my other email sent a few minutes ago. >>> >>> *From:*OAuth >> > *On Behalf Of *Brian Campbell >>> *Sent:* Friday, November 30, 2018 11:43 PM >>> *To:* Torsten Lodderstedt >> > >>> *Cc:* oauth > >>> *Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 >>> >>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt >>> > wrote: >>> >>> > Am 15.11.2018 um 23:01 schrieb Brock Allen >>> >: >>> > >>> > So you mean at the resource server ensuring the token was >>> really issued to the client? Isn't that an inherent limitation >>> of all bearer tokens (modulo HTTP token binding, which is still >>> some time off)? >>> >>> Sure. That’s why the Security BCP recommends use of TLS-based >>> methods for sender constraining access tokens >>> (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2). >>> Token Binding for OAuth >>> (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08 >>> ) >>> as well as Mutual TLS for OAuth >>> (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the >>> options available. >>> >>> Unfortunately even when using the token endpoint, for SPA / >>> in-browser client applications, the potential mechanisms for >>> sender/key-constraining access tokens don't work very well or maybe >>> don't work at all. So I don't know that the recommendation is very >>> realistic. >>> >>> >>> */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./* >>> >>> 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 the information in any medium. Thank you. >> _______________________________________________ >> 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 --------------A81C86C0D638F27B4338D15C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

How is that different from a regular server client with a web interface if the backed is doing the API calls to the RS?


On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
I forgot to mention another (architectural) option: split an application into frontend provided by JS in the browser and a backend, which takes care of the business logic and handles tokens and API access. Replay detection at the interface between SPA and backend can utilize standard web techniques (see OWASP). The backend in turn can use mTLS for sender constraining.

Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <torsten@lodderstedt.net>:

IMHO the best mechanism at hand currently to cope with token leakage/replay in SPAs is to use refresh tokens (rotating w/ replay detection) and issue short living and privilege restricted access tokens.

Sender constrained access tokens in SPAs need adoption of token binding or alternative mechanism. mtls could potentially work in deployments with automated cert rollout but browser UX and interplay with fetch needs some work. We potentially must consider to warm up application level PoP mechanisms in conjunction with web crypto. Another path to be evaluated could be web auth.

Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <Hannes.Tschofenig@arm.com>:

I share the concern Brian has, which is also the conclusion I came up with in my other email sent a few minutes ago.

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
Sent: Friday, November 30, 2018 11:43 PM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

 

 

On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

> Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.com>:
>
> So you mean at the resource server ensuring the token was really issued to the client? Isn't that an inherent limitation of all bearer tokens (modulo HTTP token binding, which is still some time off)?

Sure. That’s why the Security BCP recommends use of TLS-based methods for sender constraining access tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2). Token Binding for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options available.

 

Unfortunately even when using the token endpoint, for SPA / in-browser client applications, the potential mechanisms for sender/key-constraining access tokens don't work very well or maybe don't work at all. So I don't know that the recommendation is very realistic.

 


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.

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 the information in any medium. Thank you.
_______________________________________________
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
--------------A81C86C0D638F27B4338D15C-- From nobody Sat Dec 1 23:31:21 2018 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 0FD9F130E7D for ; Sat, 1 Dec 2018 23:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, 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 JHGwwhZonZZI for ; Sat, 1 Dec 2018 23:31:15 -0800 (PST) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.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 294EF130E7E for ; Sat, 1 Dec 2018 23:31:14 -0800 (PST) Received: from [91.13.153.47] (helo=[192.168.71.112]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gTMDe-0002a5-FZ; Sun, 02 Dec 2018 08:31:10 +0100 Content-Type: multipart/signed; boundary=Apple-Mail-91BF73BE-726F-4AC5-8936-BD54897E63DC; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Sun, 2 Dec 2018 08:31:09 +0100 Cc: oauth@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> To: John Bradley X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 02 Dec 2018 07:31:19 -0000 --Apple-Mail-91BF73BE-726F-4AC5-8936-BD54897E63DC Content-Type: multipart/alternative; boundary=Apple-Mail-9100E2DD-3670-4BF9-B307-BC7DA5DEA9C8 Content-Transfer-Encoding: 7bit --Apple-Mail-9100E2DD-3670-4BF9-B307-BC7DA5DEA9C8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable the UI is rendered in the frontend, UI control flow is in the frontend. just= a different cut through the web app=E2=80=99s layering=20 All Angular apps I have seen so far work that way. And it makes a lot of sen= se to me. The backend can aggregate and optimize access to the underlying se= rvices without the need to fully expose them. > Am 02.12.2018 um 00:44 schrieb John Bradley : >=20 > How is that different from a regular server client with a web interface if= the backed is doing the API calls to the RS? >=20 >=20 >=20 >> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: >> I forgot to mention another (architectural) option: split an application i= nto frontend provided by JS in the browser and a backend, which takes care o= f the business logic and handles tokens and API access. Replay detection at t= he interface between SPA and backend can utilize standard web techniques (se= e OWASP). The backend in turn can use mTLS for sender constraining. >>=20 >> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt : >>=20 >>> IMHO the best mechanism at hand currently to cope with token leakage/rep= lay in SPAs is to use refresh tokens (rotating w/ replay detection) and issu= e short living and privilege restricted access tokens. >>>=20 >>> Sender constrained access tokens in SPAs need adoption of token binding o= r alternative mechanism. mtls could potentially work in deployments with aut= omated cert rollout but browser UX and interplay with fetch needs some work.= We potentially must consider to warm up application level PoP mechanisms in= conjunction with web crypto. Another path to be evaluated could be web auth= . >>>=20 >>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig : >>>=20 >>>> I share the concern Brian has, which is also the conclusion I came up w= ith in my other email sent a few minutes ago. >>>> =20 >>>> From: OAuth On Behalf Of Brian Campbell >>>> Sent: Friday, November 30, 2018 11:43 PM >>>> To: Torsten Lodderstedt >>>> Cc: oauth >>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 >>>> =20 >>>> =20 >>>>=20 >>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt wrote: >>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen : >>>> >=20 >>>> > So you mean at the resource server ensuring the token was really issu= ed to the client? Isn't that an inherent limitation of all bearer tokens (mo= dulo HTTP token binding, which is still some time off)? >>>>=20 >>>> Sure. That=E2=80=99s why the Security BCP recommends use of TLS-based m= ethods for sender constraining access tokens (https://tools.ietf.org/html/dr= aft-ietf-oauth-security-topics-09#section-2..2). Token Binding for OAuth (ht= tps://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mutu= al TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are t= he options available. >>>> =20 >>>> Unfortunately even when using the token endpoint, for SPA / in-browser c= lient applications, the potential mechanisms for sender/key-constraining acc= ess tokens don't work very well or maybe don't work at all. So I don't know t= hat the recommendation is very realistic. >>>> =20 >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged 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 by= e-mail and delete the message and any file attachments from your computer. T= hank you. >>>> IMPORTANT NOTICE: The contents of this email and any attachments are co= nfidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to a= ny 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 >>=20 >>=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-9100E2DD-3670-4BF9-B307-BC7DA5DEA9C8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
the= UI is rendered in the frontend, UI control flow is in the frontend. just a d= ifferent cut through the web app=E2=80=99s layering 

All Angular apps I have seen so far work that= way. And it makes a lot of sense to me. The backend can aggregate and optim= ize access to the underlying services without the need to fully expose them.=

Am 02.12.2018 um 00:44 schrieb John Bradley <<= a href=3D"mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com>:

=
=20 =20 =20

How is that different from a regular server client with a web interface if the backed is doing the API calls to the RS?


On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
I forgot to mention another (architectural) option: split an application into frontend provided by JS in the browser and a backend, which takes care of the business logic and handles tokens and API access. Replay detection at the interface between SPA and backend can utilize standard web techniques (see OWASP). The backend in turn can use mTLS for sender constraining.

Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <torsten@lodderstedt.n= et>:

IMHO the best mechanism at hand currently to cope with token leakage/replay in SPAs is to use refresh tokens (rotating w/ replay detection) and issue short living and privilege restricted access tokens.

Sender constrained access tokens in SPAs need adoption of token binding or alternative mechanism. mtls could potentially work in deployments with automated cert rollout but browser UX and interplay with fetch needs some work. We potentially must consider to warm up application level PoP mechanisms in conjunction with web crypto. Another path to be evaluated could be web auth.

Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <Hannes.Tschofenig= @arm.com>:

I share the concern Brian has, which is also the conclusion I came up with in my other email sent a few minutes ago.

 

From:<= /b> OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
Sent: Friday, November 30, 2018 11:43 PM
To: Torsten Lodderstedt <torsten@lodderstedt.net&g= t;
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

 

 

On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <torsten@lodders= tedt.net> wrote:

> Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.com<= /a>>:
>
> So you mean at the resource server ensuring the token was really issued to the client? Isn't that an inherent limitation of all bearer tokens (modulo HTTP token binding, which is still some time off)?

Sure. That=E2=80=99s why the Security BCP recommends= use of TLS-based methods for sender constraining access tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-top= ics-09#section-2..2). Token Binding for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08= ) as well as Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options available.

 

Unfortunately even when using the token endpoint, for SPA / in-browser client applications, the potential mechanisms for sender/key-constraining access tokens don't work very well or maybe don't work at all. So I don't know that the recommendation is very realistic.

 


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.

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 the information in any medium. Thank you.
_____________________________________________= __
OAuth mailing list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= br> 

_______________________________=
________________
OAuth mailing list
OAuth@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth
=20
________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-9100E2DD-3670-4BF9-B307-BC7DA5DEA9C8-- --Apple-Mail-91BF73BE-726F-4AC5-8936-BD54897E63DC Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCocw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIFRTCCBC2gAwIBAgIQM9uaxqrCN5lrc/ED e5nwtDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE3MDEwOTAwMDAwMFoXDTE4MDEwOTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYX dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCu wZLNnLP0ur1JFb1K97kryfmVaGmU4ITocfeAzJ7XYOM6mQUVm3Rvve3bsbXteynpZTEeE169/tyT QBSm9hQ8IcGpUYlIhYX2FYChIUKBAAI6iH9wMVvPPU+wxjwSXs6Yi6zgle1jj9V2hIiEU/eHMBNs 0CDfYqn43y+1O4pPBuCeLMlLLNlNiuy22fcubBjXsdT5T29eWgy6zlT+WfgANnHTPLINKwDqC0/F dgmluBJOcdyRVnnN9HzSC4hnnfxjaqqyq3lVpJFJHahDMT8cROQpz+h09WGoGtcvK+dIWQI+sBdX Tuty/CQ+8dl5hW7hB1VbI7YchDiLbH2vmbtLAgMBAAGjggH1MIIB8TAfBgNVHSMEGDAWgBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU+eAeBXE5nsZKOL8hbhgkwGPTY8cwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy ZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCIGA1UdEQQbMBmB F3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IBAQACa57IeOLIvWpiB976 FVKwa4qWBy+MIB8bwlqrjy0LQiM/ykf+0aLi4v0IdV8udXeksOeODoza6+kQGntytllydI8t5Wyz 62SHC/4XshJhDJPh+U2SpVRvyd97BsI9wg3Xc5t+lTuuVeghqsQSmVCjhK7KZhWW5DFMs4UqblA4 wXgkEzD+uPLi33knsx2n00VTNCso8kNonYmv9NxNcVyMu81WYwGMrT3n1r2/X/WaJEd3UMGxOHUq 8GKAQ5Q0zG9Pm5S0Hr+2KgNmoEMOTwa92ej/GbJ7diJqxLsmAxESrlZxeqlYa7mQwVkwY8S/I8d4 Fl6rHHdqZ/giZWdnpa+DMYID0DCCA8wCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMjAyMDczMTA5WjAvBgkqhkiG 9w0BCQQxIgQgJkRIOdeA/SZu9Vn2ofSxPMGUkKycx6SWogeFQQRR4y0wgcEGCSsGAQQBgjcQBDGB szCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3 mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAEGw rA8rP2n5mXjE10yJn/zEV3CDBDIDQ7ZqJHWyxyGTc1LNJuEbQWs5kyK1lzUBjy/4G3Vx34zDcUa3 B563UYeYxERuTRD2PO6S4vR17kkr89YMc5U3Y0zXAndqSooUN9LsIAE01Eat62bzYKIZaf6pFgmM Uj9LihKn4dy9uuwyP9kUn8Op3Ul+NUShhUjDon66NiV8jwH6wLP8OjuuLp1p8gexAeWCat4U1Krz A7Ex5wrv+7iMDZ1YRQaGTyJJZWVzKKp/10tFtkWcRT8Pb/aa+wdcpvrA/OTqRA16ghX+ssx6wq/4 eDXzbbI12RZnhJXsy2nHLLE1tuPEJEW2KogAAAAAAAA= --Apple-Mail-91BF73BE-726F-4AC5-8936-BD54897E63DC-- From nobody Sun Dec 2 03:55:10 2018 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 8951B130EBD for ; Sun, 2 Dec 2018 03:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 wSrWrzGBfPAb for ; Sun, 2 Dec 2018 03:55:05 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 306C812D7EA for ; Sun, 2 Dec 2018 03:55:05 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id d72so4450583pga.9 for ; Sun, 02 Dec 2018 03:55:05 -0800 (PST) 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=pMhE232W+oO4Ae4zVh7j2t5Y0kl6jCJ2JNuBisUBoeQ=; b=MDjr6MNvPNiDcVCpLDrg13ladzqhgb3uSWwR7KGdacW5wcys+sfH5vofHIJa+TGtpJ LoJxcdJysC9ybD8J0YV/TaNmseld/Zn+OKnaNv9RyzLEuPofGCJ7WlLpaTG2vPjG2QMX TADXADfVDbzRBY1MQR6iFIghtJzoIThKturxY= 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=pMhE232W+oO4Ae4zVh7j2t5Y0kl6jCJ2JNuBisUBoeQ=; b=fg2rpbzo+FU0Fyga1T5imMZtSeg3dXWgMe5t/DMwFKrUSpklgsPksi5lItMAr7Kdgo JylybUSWHIlXCBF4E3YHoNrRmDmpK7amMDxeXb8koypqzyI3eUADDKOgc+pzqU60x42V wVIme7K5fCND4JHn4xizUtbffMulk+c8SbPzabldo7Vx1cfAfCTH7F3XGLDQTztd1Yqw 7ldTGGPGURTR+9FE94Mp/fChX7q7Q4XLkFPTvXmDBKr2hHq5Uf1uqxrqJUmgr4du5dgC CLYBMu1bXGpm4L/p3MNUvoqKW8ZdhC1Zj2RiSBSt4F7BmuDFvOqL/4MAh1OChGhHlmUr ybfw== X-Gm-Message-State: AA+aEWacLO7DtkLBQf24+PpcQ0GatCzPJepe8OVCNdr7/EOUfYtT5LvX o70VLJ8JpsbZydvAi2b52Clt4Icq43J1hOs7eC0XC7QOHDnwnH/iFKgwrPWwVw4xLkrftAWkpOJ 4EsE3lQmIWWMHguyb X-Google-Smtp-Source: AFSGD/USaureM1Krp+B7pQ0qj+4CNMnJVXe3TA/DLhQMmmzdPHHpC1p0eiqc4Z7+klAWjqsu5NUTfbYiUYa1KOATgRo= X-Received: by 2002:a63:5122:: with SMTP id f34mr9720271pgb.218.1543751704316; Sun, 02 Dec 2018 03:55:04 -0800 (PST) MIME-Version: 1.0 References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> In-Reply-To: From: Rob Otto Date: Sun, 2 Dec 2018 11:54:52 +0000 Message-ID: To: torsten@lodderstedt.net Cc: John Bradley , oauth Content-Type: multipart/alternative; boundary="000000000000f52bae057c08b37a" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 02 Dec 2018 11:55:08 -0000 --000000000000f52bae057c08b37a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Apologies if I'm being dim (it wouldn't be the first time!) but how, in this scenario, do we identify the browser client and authenticate it to the backend, to associate it with the correct token(s)? Cheers (and really interesting discussion so far) Rob On Sun, 2 Dec 2018 at 07:31, Torsten Lodderstedt wrote: > the UI is rendered in the frontend, UI control flow is in the frontend. > just a different cut through the web app=E2=80=99s layering > > All Angular apps I have seen so far work that way. And it makes a lot of > sense to me. The backend can aggregate and optimize access to the > underlying services without the need to fully expose them. > > Am 02.12.2018 um 00:44 schrieb John Bradley : > > How is that different from a regular server client with a web interface i= f > the backed is doing the API calls to the RS? > > > On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: > > I forgot to mention another (architectural) option: split an application > into frontend provided by JS in the browser and a backend, which takes ca= re > of the business logic and handles tokens and API access. Replay detection > at the interface between SPA and backend can utilize standard web > techniques (see OWASP). The backend in turn can use mTLS for sender > constraining. > > Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt < > torsten@lodderstedt.net>: > > IMHO the best mechanism at hand currently to cope with token > leakage/replay in SPAs is to use refresh tokens (rotating w/ replay > detection) and issue short living and privilege restricted access tokens. > > Sender constrained access tokens in SPAs need adoption of token binding o= r > alternative mechanism. mtls could potentially work in deployments with > automated cert rollout but browser UX and interplay with fetch needs some > work. We potentially must consider to warm up application level PoP > mechanisms in conjunction with web crypto. Another path to be evaluated > could be web auth. > > Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig < > Hannes.Tschofenig@arm.com>: > > I share the concern Brian has, which is also the conclusion I came up wit= h > in my other email sent a few minutes ago. > > > > *From:* OAuth *On Behalf Of *Brian Campbell > *Sent:* Friday, November 30, 2018 11:43 PM > *To:* Torsten Lodderstedt > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 > > > > > > On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > > Am 15.11.2018 um 23:01 schrieb Brock Allen : > > > > So you mean at the resource server ensuring the token was really issued > to the client? Isn't that an inherent limitation of all bearer tokens > (modulo HTTP token binding, which is still some time off)? > > Sure. That=E2=80=99s why the Security BCP recommends use of TLS-based met= hods for > sender constraining access tokens ( > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2= ..2). > Token Binding for OAuth ( > https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08 > ) as well > as Mutual TLS for OAuth ( > https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options > available. > > > > Unfortunately even when using the token endpoint, for SPA / in-browser > client applications, the potential mechanisms for sender/key-constraining > access tokens don't work very well or maybe don't work at all. So I don't > know that the recommendation is very realistic. > > > > > *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.* > 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 > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > _______________________________________________ > 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 > --=20 [image: Ping Identity] Rob Otto EMEA Field CTO/Solutions Architect robotto@pingidentity.com c: +44 (0) 777 135 6092 Connect with us: [image: Glassdoor logo] [image: LinkedIn logo] [image: twitter logo] [image: facebook logo] [image: youtube logo] [image: Google+ logo] [image: Blog logo] --=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._ --000000000000f52bae057c08b37a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies if I'm being dim (it wouldn't be= the first time!) but how, in this scenario, do we identify the browser cli= ent and authenticate it to the backend, to associate it with the correct to= ken(s)?=C2=A0

Cheers (and really interesting= discussion so far)

Rob=C2=A0
On Sun, 2 Dec 2018 at 07:31, T= orsten Lodderstedt <torsten@l= odderstedt.net> wrote:
the UI is rendered in = the frontend, UI control flow is in the frontend. just a different cut thro= ugh the web app=E2=80=99s layering=C2=A0

All Angular apps I have seen so far work that way. And it ma= kes a lot of sense to me. The backend can aggregate and optimize access to = the underlying services without the need to fully expose them.

Am 02.12.2018 um 00:44 schrieb John Bradley <ve7jtb@ve7jtb.com>:
=20 =20 =20 =20

How is that different from a regular server client with a web interface if the backed is doing the API calls to the RS?


On 12/1/2018 12:25= PM, Torsten Lodderstedt wrote:
=20
I forgot to mention another (architectural) option: split an application into frontend provided by JS in the browser and a backend, which takes care of the business logic and handles tokens and API access. Replay detection at the interface between SPA and backend can utilize standard web techniques (see OWASP). The backend in turn can use mTLS for sender constraining.

Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <torsten@lodderstedt.net>:

=20
IMHO the best mechanism at hand currently to cope with token leakage/replay in SPAs is to use refresh tokens (rotating w/ replay detection) and issue short living and privilege restricted access tokens.

Sender constrained access tokens in SPAs need adoption of token binding or alternative mechanism. mtls could potentially work in deployments with automated cert rollout but browser UX and interplay with fetch needs some work. We potentially must consider to warm up application level PoP mechanisms in conjunction with web crypto. Another path to be evaluated could be web auth.
=20 =20 =20

I share the concern Brian has, which is also the conclusion I came up with in my other email sent a few minutes ago.

=C2=A0

From:= OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
Sent: Friday, November 30, 2018 11:43 PM
To: Torsten Lodderstedt <torsten@lodderstedt.net> Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00=

=C2=A0

= =C2=A0

On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

> Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.com>:
>
> So you mean at the resource server ensuring the token was really issued to the client? Isn'= t that an inherent limitation of all bearer tokens (modulo HTTP token binding, which is still some time off)?

Sure. That=E2=80=99s why the Security BCP recommend= s use of TLS-based methods for sender constraining access tokens (http= s://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2). Token Binding for OAuth (https://= tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mutual TLS for OAuth (https://to= ols.ietf.org/html/draft-ietf-oauth-mtls-12) are the options available.

=C2=A0

Unfortunately even when using the token endpoint, for SPA / in-browser client applications, the potential mechanisms for sender/key-constraining access tokens don't wor= k very well or maybe don't work at all. So I don&= #39;t know that the recommendation is very realistic.

=C2=A0


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..=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 attachments from your computer. Thank you.

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 the information in any medium. Thank you.
____________________________________________= ___
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oauth

__________________=
_____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/m=
ailman/listinfo/oauth
=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


--
= =
<= /a>3D"P=
Rob Otto
EMEA Field CTO/Solutions Architect
= robotto@pingidentity.com
= =
c: +44 (0) 777 135 6092 <= /td>
Connect with us: 3D"Glassdoor 3D"LinkedIn = =3D"twitter 3D"facebook 3D"youtube = 3D"Goo= 3D"Blog =

<= 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. --000000000000f52bae057c08b37a-- From nobody Sun Dec 2 05:10:58 2018 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 7787212D4EC for ; Sun, 2 Dec 2018 05:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 M1n8Y7Aocg-K for ; Sun, 2 Dec 2018 05:10:52 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.104]) (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 8B11D130EDA for ; Sun, 2 Dec 2018 05:10:52 -0800 (PST) Received: from [80.187.81.0] (helo=[10.120.12.75]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gTRWK-0006yp-VA; Sun, 02 Dec 2018 14:10:49 +0100 Content-Type: multipart/signed; boundary=Apple-Mail-3BF4E619-BAB3-4912-A609-B175426A2519; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Sun, 2 Dec 2018 14:10:47 +0100 Cc: John Bradley , oauth Content-Transfer-Encoding: 7bit Message-Id: References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> To: Rob Otto X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 02 Dec 2018 13:10:57 -0000 --Apple-Mail-3BF4E619-BAB3-4912-A609-B175426A2519 Content-Type: multipart/alternative; boundary=Apple-Mail-C77E5389-D42D-48C9-8BE6-BBDFEE8065EA Content-Transfer-Encoding: 7bit --Apple-Mail-C77E5389-D42D-48C9-8BE6-BBDFEE8065EA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I assume via the session context, carried=20 as cookie, token or part of the URL. > Am 02.12.2018 um 12:54 schrieb Rob Otto : >=20 > Apologies if I'm being dim (it wouldn't be the first time!) but how, in th= is scenario, do we identify the browser client and authenticate it to the ba= ckend, to associate it with the correct token(s)?=20 >=20 > Cheers (and really interesting discussion so far) >=20 > Rob=20 >=20 >> On Sun, 2 Dec 2018 at 07:31, Torsten Lodderstedt wrote: >> the UI is rendered in the frontend, UI control flow is in the frontend. j= ust a different cut through the web app=E2=80=99s layering=20 >>=20 >> All Angular apps I have seen so far work that way. And it makes a lot of s= ense to me. The backend can aggregate and optimize access to the underlying s= ervices without the need to fully expose them. >>=20 >>> Am 02.12.2018 um 00:44 schrieb John Bradley : >>>=20 >>> How is that different from a regular server client with a web interface i= f the backed is doing the API calls to the RS? >>>=20 >>>=20 >>>=20 >>>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: >>>> I forgot to mention another (architectural) option: split an applicatio= n into frontend provided by JS in the browser and a backend, which takes car= e of the business logic and handles tokens and API access. Replay detection a= t the interface between SPA and backend can utilize standard web techniques (= see OWASP). The backend in turn can use mTLS for sender constraining. >>>>=20 >>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt : >>>>=20 >>>>> IMHO the best mechanism at hand currently to cope with token leakage/r= eplay in SPAs is to use refresh tokens (rotating w/ replay detection) and is= sue short living and privilege restricted access tokens. >>>>>=20 >>>>> Sender constrained access tokens in SPAs need adoption of token bindin= g or alternative mechanism. mtls could potentially work in deployments with a= utomated cert rollout but browser UX and interplay with fetch needs some wor= k. We potentially must consider to warm up application level PoP mechanisms i= n conjunction with web crypto. Another path to be evaluated coul= d be web auth. >>>>>=20 >>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig : >>>>>=20 >>>>>> I share the concern Brian has, which is also the conclusion I came up= with in my other email sent a few minutes ago. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> From: OAuth On Behalf Of Brian Campbell >>>>>> Sent: Friday, November 30, 2018 11:43 PM >>>>>> To: Torsten Lodderstedt >>>>>> Cc: oauth >>>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt wrote: >>>>>>=20 >>>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen : >>>>>> >=20 >>>>>> > So you mean at the resource server ensuring the token was really is= sued to the client? Isn't that an inherent limitation of all bearer tokens (= modulo HTTP token binding, which is still some time off)? >>>>>>=20 >>>>>> Sure. That=E2=80=99s why the Security BCP recommends use of TLS-based= methods for sender constraining access tokens (https://tools.ietf.org/html/= draft-ietf-oauth-security-topics-09#section-2..2). Token Binding for OAuth (= https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mu= tual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) ar= e the options available. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Unfortunately even when using the token endpoint, for SPA / in-browse= r client applications, the potential mechanisms for sender/key-constraining a= ccess tokens don't work very well or maybe don't work at all. So I don't kno= w that the recommendation is very realistic. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.. If you hav= e received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your compute= r. Thank you. >>>>>>=20 >>>>>> IMPORTANT NOTICE: The contents of this email and any attachments are c= onfidential and may also be privileged. If you are not the intended recipien= t, please notify the sender immediately and do not disclose the contents to a= ny 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 >>>>=20 >>>>=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 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > --=20 > =09 > Rob Otto=09 > EMEA Field CTO/Solutions Architect=09 > robotto@pingidentity.com=09 > =09 > c: +44 (0) 777 135 6092 > Connect with us: = = =09 >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited. If you have rece= ived this communication in error, please notify the sender immediately by e-= mail and delete the message and any file attachments from your computer. Tha= nk you. --Apple-Mail-C77E5389-D42D-48C9-8BE6-BBDFEE8065EA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I a= ssume via the session context, carried 
as cookie= , token or part of the URL.

Am 02.12.2018 um 12:54= schrieb Rob Otto <robotto@pi= ngidentity.com>:

Apologies if I'm being dim (it wouldn't be the f= irst time!) but how, in this scenario, do we identify the browser client and= authenticate it to the backend, to associate it with the correct token(s)?&= nbsp;

Cheers (and really interesting discussion= so far)

Rob 

On Sun, 2 Dec 2018 at 07:31, Torsten Lodderst= edt <torsten@lodderstedt.net> wrote:

=20 =20 =20 =20

How is that different from a regular server client with a web interface if the backed is doing the API calls to the RS?


On 12/1/2018 12:25 P= M, Torsten Lodderstedt wrote:
=20
I forgot to mention another (architectural) option: split an application into frontend provided by JS in the browser and a backend, which takes care of the business logic and handles tokens and API access. Replay detection at the interface between SPA and backend can utilize standard web techniques (see OWASP). The backend in turn can use mTLS for sender constraining.

Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <torsten@lodderstedt.net&= gt;:

=20
IMHO the best mechanism at hand currently to cope with token leakage/replay in SPAs is to use refresh tokens (rotating w/ replay detection) and issue short living and privilege restricted access tokens.

Sender constrained access tokens in SPAs need adoption of token binding or alternative mechanism. mtls could potentially work in deployments with automated cert rollout but browser UX and interplay with fetch needs some work. We potentially must consider to warm up application level PoP mechanisms in conjunction with web crypto. Another path to be evaluated could be web auth.

Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <Hannes.Tschofenig@arm.co= m>:

=20 =20 =20

I share the concern Brian has, which is also the conclusion I came up with in my other email sent a few minutes ago.

 

From:<= /b> OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
Sent: Friday, November 30, 2018 11:43 PM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00<= /span>

 

<= /u> 

On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

> Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.com>:
>
> So you mean at the resource server ensuring the token was really issued to the client? Isn't that an inherent limitation of all bearer tokens (modulo HTTP token binding, which is still some time off)?

Sure. That=E2=80=99s why the Security BCP recommends= use of TLS-based methods for sender constraining access tokens (https:= //tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).= Token Binding for OAuth (https://to= ols.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mutual TLS for OAuth (https://tool= s.ietf.org/html/draft-ietf-oauth-mtls-12) are the options available.

 

Unfortunately even when using the token endpoint, for SPA / in-browser client applications, the potential mechanisms for sender/key-constraining access tokens don't work very well or maybe don't work at all. So I don't know that the recommendation is very realistic.

 


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.

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 the information in any medium. Thank you.
_____________________________________________= __
OAuth mailing list
OAuth@ie= tf.org
https://www.ietf.org/mailman/listinfo/oauth

___________________=
____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai=
lman/listinfo/oauth
=20
________= _______________________________________
OAuth mailing list
OAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/oauth
_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
=
= 3D"Ping
= = =
= Rob Otto =
= EMEA Fi= eld CTO/Solutions Architect =
= robotto@pingidentity.com =
=
= = c: +44 (0) 777 135 6092 =
= =
Connect with us: 3D"Glassdoor = 3D"LinkedIn 3D"twitter = 3D"facebook = 3D"youtube = = 3D"Google= 3D"Blog = =
=

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.  If y= ou 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 c= omputer. Thank you.
= --Apple-Mail-C77E5389-D42D-48C9-8BE6-BBDFEE8065EA-- --Apple-Mail-3BF4E619-BAB3-4912-A609-B175426A2519 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCocw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIFRTCCBC2gAwIBAgIQM9uaxqrCN5lrc/ED e5nwtDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE3MDEwOTAwMDAwMFoXDTE4MDEwOTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYX dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCu wZLNnLP0ur1JFb1K97kryfmVaGmU4ITocfeAzJ7XYOM6mQUVm3Rvve3bsbXteynpZTEeE169/tyT QBSm9hQ8IcGpUYlIhYX2FYChIUKBAAI6iH9wMVvPPU+wxjwSXs6Yi6zgle1jj9V2hIiEU/eHMBNs 0CDfYqn43y+1O4pPBuCeLMlLLNlNiuy22fcubBjXsdT5T29eWgy6zlT+WfgANnHTPLINKwDqC0/F dgmluBJOcdyRVnnN9HzSC4hnnfxjaqqyq3lVpJFJHahDMT8cROQpz+h09WGoGtcvK+dIWQI+sBdX Tuty/CQ+8dl5hW7hB1VbI7YchDiLbH2vmbtLAgMBAAGjggH1MIIB8TAfBgNVHSMEGDAWgBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU+eAeBXE5nsZKOL8hbhgkwGPTY8cwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy ZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCIGA1UdEQQbMBmB F3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IBAQACa57IeOLIvWpiB976 FVKwa4qWBy+MIB8bwlqrjy0LQiM/ykf+0aLi4v0IdV8udXeksOeODoza6+kQGntytllydI8t5Wyz 62SHC/4XshJhDJPh+U2SpVRvyd97BsI9wg3Xc5t+lTuuVeghqsQSmVCjhK7KZhWW5DFMs4UqblA4 wXgkEzD+uPLi33knsx2n00VTNCso8kNonYmv9NxNcVyMu81WYwGMrT3n1r2/X/WaJEd3UMGxOHUq 8GKAQ5Q0zG9Pm5S0Hr+2KgNmoEMOTwa92ej/GbJ7diJqxLsmAxESrlZxeqlYa7mQwVkwY8S/I8d4 Fl6rHHdqZ/giZWdnpa+DMYID0DCCA8wCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMjAyMTMxMDQ4WjAvBgkqhkiG 9w0BCQQxIgQgOl6pKYB2TEAG5nWLh+BDNDX7BngehjwFS2PO6gO2cEMwgcEGCSsGAQQBgjcQBDGB szCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3 mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBACrN dZOQ6q7nWvhDA6w5JsPwcVg0HFtyRbHd4lADWxi7JpgJ2JBennJ83Reo4QdWjcH1W2U7cSrB0ygD JwA4vBqDeEVjobEVW/YpVmhmf694UK447IikwyBAWm5/Oak+VLQBTkrkuUVWvyMO3cXG6QkWRNs+ UPSu11ScS/ToPWfr/Y9YChmwNqikT1pbrWhZqHGr0qfyZ9526QGoEHiBlp4jt4IHkiuYDFjFQX1i zMfLKkyEWquuFGuJtNagdHuim/9WmKSstirDLN3Ff+ihf0h0tyN6UqpQ7rEL7uLCXyWWzvLRdHRl uC629Y9i183oiA3env+bQW5hyIXtUYCChJsAAAAAAAA= --Apple-Mail-3BF4E619-BAB3-4912-A609-B175426A2519-- From nobody Sun Dec 2 15:44:11 2018 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 BB5C3130DD0 for ; Sun, 2 Dec 2018 15:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, 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 (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 RiorssYPu83v for ; Sun, 2 Dec 2018 15:44:07 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 6C88B130DCF for ; Sun, 2 Dec 2018 15:44:07 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id h65so6040965ith.3 for ; Sun, 02 Dec 2018 15:44:07 -0800 (PST) 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; bh=hGpZZ0RB5asp00oh5m5Ad5Chwi9CztLFofnH5/Vbk74=; b=GttR+tjgoSFk1cYbMQU/EWItfgqI5suHBzeI15WeedspxOfSIrYiF8oaGumHhXgF4K YTNJ29kqDo7f/j6VcJ+w400tiEa+6fH8VmLUrer1sQCF4xcyVazCMUFuV3Tn8XGgAcR3 16K8SydlDiE+hTZkle+LVUbzBdJAr0w4fiPRx3JdeFyi02HkknbYoDe5PVJF3PbamPxf 2cCXQWQHdG/Hs18E7vR+tvDGa8+QWYeKsySKZKpeqimI7h55EPwECwl3dasMdjO/fyy+ p4BYLqKHMbJF5Nho9dNo6lOrCXvcrcZHEgrHCDlYksOMRm97/QtgBvkaeuamLGAHbSLY 4XxQ== 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=hGpZZ0RB5asp00oh5m5Ad5Chwi9CztLFofnH5/Vbk74=; b=VjUu7vuoiNf/efQAlcM9+HaB23Pdnc2PGqe8rE5WDEGHHLlrmBiz7BrhcZlBbA9rgR EVNHFKOFBCiULlGUeQK2yy4p87TlBDhCkWEbeJsC2zZAY95oXxp96lCBEDWbI/qrNlKn 4flFRkI4MRFyh5F+/91/iHRYvzgqjmen2BOMxv9R2ki8BdS+oXT+NPjcHhTv0v/tNz90 298URgF42bCRwbIzxprXJVE2sJLn/ie1RKhwdR+CmNWhnKM2LCIsI946tg+jwhdDyzvK xgPUDD+BdXUXZU/ZryGQ6+LhsWM4jUeOF+KasQy2U+/dRInsKePare53vQY73UqvA6ta B6RA== X-Gm-Message-State: AA+aEWYIQBI27QmSWQHgUBpGGTitvLOSvkSQpxMOEpRRevHdEEa3buQY SLETQ0vgxFsF+4YosSbU1eEJdFv0noE= X-Google-Smtp-Source: AFSGD/WQjXYxiyenHcMGEAbvypLdpZfJg3mc2YvAC+dH+03ZDj+8+/lROpjYiBPVyTJIJhxcycHx8w== X-Received: by 2002:a02:9549:: with SMTP id y67mr12928389jah.4.1543794246410; Sun, 02 Dec 2018 15:44:06 -0800 (PST) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com. [209.85.166.54]) by smtp.gmail.com with ESMTPSA id 134sm3212800itl.25.2018.12.02.15.44.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Dec 2018 15:44:04 -0800 (PST) Received: by mail-io1-f54.google.com with SMTP id l14so8942539ioj.5 for ; Sun, 02 Dec 2018 15:44:04 -0800 (PST) X-Received: by 2002:a5e:c303:: with SMTP id a3mr11589198iok.53.1543794244030; Sun, 02 Dec 2018 15:44:04 -0800 (PST) MIME-Version: 1.0 References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> In-Reply-To: From: Aaron Parecki Date: Sun, 2 Dec 2018 15:43:51 -0800 X-Gmail-Original-Message-ID: Message-ID: To: torsten@lodderstedt.net Cc: John Bradley , OAuth WG Content-Type: multipart/alternative; boundary="000000000000859bfb057c129bce" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 02 Dec 2018 23:44:11 -0000 --000000000000859bfb057c129bce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In this type of deployment, as far as OAuth is concerned, isn't the backend web server a confidential client? Is there even anything unique to this situation as far as OAuth security goes? I wouldn't have expected an Angular app that talks to its own server backend that's managing OAuth credentials to fall under the umbrella of this BCP. ---- Aaron Parecki aaronparecki.com On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt wrote: > the UI is rendered in the frontend, UI control flow is in the frontend. > just a different cut through the web app=E2=80=99s layering > > All Angular apps I have seen so far work that way. And it makes a lot of > sense to me. The backend can aggregate and optimize access to the > underlying services without the need to fully expose them. > > Am 02.12.2018 um 00:44 schrieb John Bradley : > > How is that different from a regular server client with a web interface i= f > the backed is doing the API calls to the RS? > > > On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: > > I forgot to mention another (architectural) option: split an application > into frontend provided by JS in the browser and a backend, which takes ca= re > of the business logic and handles tokens and API access. Replay detection > at the interface between SPA and backend can utilize standard web > techniques (see OWASP). The backend in turn can use mTLS for sender > constraining. > > Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt < > torsten@lodderstedt.net>: > > IMHO the best mechanism at hand currently to cope with token > leakage/replay in SPAs is to use refresh tokens (rotating w/ replay > detection) and issue short living and privilege restricted access tokens. > > Sender constrained access tokens in SPAs need adoption of token binding o= r > alternative mechanism. mtls could potentially work in deployments with > automated cert rollout but browser UX and interplay with fetch needs some > work. We potentially must consider to warm up application level PoP > mechanisms in conjunction with web crypto. Another path to be evaluated > could be web auth. > > Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig < > Hannes.Tschofenig@arm.com>: > > I share the concern Brian has, which is also the conclusion I came up wit= h > in my other email sent a few minutes ago. > > > > *From:* OAuth *On Behalf Of *Brian Campbell > *Sent:* Friday, November 30, 2018 11:43 PM > *To:* Torsten Lodderstedt > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 > > > > > > On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > > Am 15.11.2018 um 23:01 schrieb Brock Allen : > > > > So you mean at the resource server ensuring the token was really issued > to the client? Isn't that an inherent limitation of all bearer tokens > (modulo HTTP token binding, which is still some time off)? > > Sure. That=E2=80=99s why the Security BCP recommends use of TLS-based met= hods for > sender constraining access tokens ( > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2= ..2). > Token Binding for OAuth ( > https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08 > ) as well > as Mutual TLS for OAuth ( > https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options > available. > > > > Unfortunately even when using the token endpoint, for SPA / in-browser > client applications, the potential mechanisms for sender/key-constraining > access tokens don't work very well or maybe don't work at all. So I don't > know that the recommendation is very realistic. > > > > > *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.* > 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 > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > _______________________________________________ > 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 > --000000000000859bfb057c129bce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In this type of deployment, as far as OAuth is concerned, = isn't the backend web server a confidential client? Is there even anyth= ing unique to this situation as far as OAuth security goes?=C2=A0

<= /div>
I wouldn't have expected an Angular app that talks to its own= server backend that's managing OAuth credentials to fall under the umb= rella of this BCP.

----
Aaron = Parecki


On Sat, Dec 1, 2018 at 11:31 P= M Torsten Lodderstedt <torste= n@lodderstedt.net> wrote:
the UI is rendered = in the frontend, UI control flow is in the frontend. just a different cut t= hrough the web app=E2=80=99s layering=C2=A0

All Angular apps I have seen so far work that way. And it= makes a lot of sense to me. The backend can aggregate and optimize access = to the underlying services without the need to fully expose them.

Am 02.12.2018 um 00:44 schrieb John Bradley <ve7jtb@ve7jtb.com>:
=
=20 =20 =20 =20

How is that different from a regular server client with a web interface if the backed is doing the API calls to the RS?


On 12/1/2018 12:25= PM, Torsten Lodderstedt wrote:
=20
I forgot to mention another (architectural) option: split an application into frontend provided by JS in the browser and a backend, which takes care of the business logic and handles tokens and API access. Replay detection at the interface between SPA and backend can utilize standard web techniques (see OWASP). The backend in turn can use mTLS for sender constraining.

Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <torsten@lodderstedt.net>:

=20
IMHO the best mechanism at hand currently to cope with token leakage/replay in SPAs is to use refresh tokens (rotating w/ replay detection) and issue short living and privilege restricted access tokens.

Sender constrained access tokens in SPAs need adoption of token binding or alternative mechanism. mtls could potentially work in deployments with automated cert rollout but browser UX and interplay with fetch needs some work. We potentially must consider to warm up application level PoP mechanisms in conjunction with web crypto. Another path to be evaluated could be web auth.
=20 =20 =20

I share the concern Brian has, which is also the conclusion I came up with in my other email sent a few minutes ago.

=C2=A0

From:= OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
Sent: Friday, November 30, 2018 11:43 PM
To: Torsten Lodderstedt <torsten@lodderstedt.net> Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00=

=C2=A0

= =C2=A0

On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

> Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.com>:
>
> So you mean at the resource server ensuring the token was really issued to the client? Isn'= t that an inherent limitation of all bearer tokens (modulo HTTP token binding, which is still some time off)?

Sure. That=E2=80=99s why the Security BCP recommend= s use of TLS-based methods for sender constraining access tokens (http= s://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2). Token Binding for OAuth (https://= tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mutual TLS for OAuth (https://to= ols.ietf.org/html/draft-ietf-oauth-mtls-12) are the options available.

=C2=A0

Unfortunately even when using the token endpoint, for SPA / in-browser client applications, the potential mechanisms for sender/key-constraining access tokens don't wor= k very well or maybe don't work at all. So I don&= #39;t know that the recommendation is very realistic.

=C2=A0


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..=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 attachments from your computer. Thank you.

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 the information in any medium. Thank you.
____________________________________________= ___
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oauth

__________________=
_____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/m=
ailman/listinfo/oauth
=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
--000000000000859bfb057c129bce-- From nobody Sun Dec 2 17:16:48 2018 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 16CF9130DE1 for ; Sun, 2 Dec 2018 17:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.759 X-Spam-Level: X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 nnSNf31zV5P0 for ; Sun, 2 Dec 2018 17:16:45 -0800 (PST) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 EEFD11274D0 for ; Sun, 2 Dec 2018 17:16:44 -0800 (PST) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wB31ETqt179017; Mon, 3 Dec 2018 01:16:43 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-2018-07-02; bh=NlEXm6A2DGbKYPfT+16fvQlBLnxVeBdRaAiKsPx7FyM=; b=XEyTczq1gcmzSLMMRtppOKR0icXstCYMWIL8kwptbqYEjLaD/CjUAJnNClezlX5GbaDA 595QHfppRm2uTIX6x6S5jpx8iOXD2e2hAAA/dd6Jztw+IRQaahEaTOs+r53qJB7jcyPA 47VvEc2kVctQ6UBZt8jR9P3D01Y/noIF55pLQZTbsy+wH2yDKHhNUQbhqEjH9xyzUmR1 YO+dU3Q2Hovg3G+lHz3avKuP3SWt8O+YqSRDxETqqK77x4paoNpYaozpXrs0xi810GTd 4Dogbz0JxssPxQ6uJ7ilenwp4zf/ifIN09qfN51XvBCpkdZV/j4bfJ6SHcGheMzNv106 TA== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2p3j8q3ks6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 03 Dec 2018 01:16:43 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wB31Ggj3019495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 3 Dec 2018 01:16:42 GMT 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 wB31Gf8g007506; Mon, 3 Dec 2018 01:16:41 GMT Received: from [10.0.1.20] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 Dec 2018 01:16:41 +0000 Content-Type: multipart/alternative; boundary=Apple-Mail-27C4B204-5E14-4D27-ACCE-BBA32ADDEF6F Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Sun, 2 Dec 2018 17:16:39 -0800 Cc: torsten@lodderstedt.net, OAuth WG Content-Transfer-Encoding: 7bit Message-Id: <450442E3-80FA-416D-9C25-DDFB95B11628@oracle.com> References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> To: Aaron Parecki X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9095 signatures=668686 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-1810050000 definitions=main-1812030011 Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 03 Dec 2018 01:16:47 -0000 --Apple-Mail-27C4B204-5E14-4D27-ACCE-BBA32ADDEF6F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable You may be placing undue confidence in that gateway acting as a confidential= client but having no real security of its own and which could be easily dup= ed.=20 Phil > On Dec 2, 2018, at 3:43 PM, Aaron Parecki wrote: >=20 > In this type of deployment, as far as OAuth is concerned, isn't the backen= d web server a confidential client? Is there even anything unique to this si= tuation as far as OAuth security goes?=20 >=20 > I wouldn't have expected an Angular app that talks to its own server backe= nd that's managing OAuth credentials to fall under the umbrella of this BCP.= >=20 > ---- > Aaron Parecki > aaronparecki.com >=20 >=20 >=20 >> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt wrote: >> the UI is rendered in the frontend, UI control flow is in the frontend. j= ust a different cut through the web app=E2=80=99s layering=20 >>=20 >> All Angular apps I have seen so far work that way. And it makes a lot of s= ense to me. The backend can aggregate and optimize access to the underlying s= ervices without the need to fully expose them. >>=20 >>> Am 02.12.2018 um 00:44 schrieb John Bradley : >>>=20 >>> How is that different from a regular server client with a web interface i= f the backed is doing the API calls to the RS? >>>=20 >>>=20 >>>=20 >>>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: >>>> I forgot to mention another (architectural) option: split an applicatio= n into frontend provided by JS in the browser and a backend, which takes car= e of the business logic and handles tokens and API access. Replay detection a= t the interface between SPA and backend can utilize standard web techniques (= see OWASP). The backend in turn can use mTLS for sender constraining. >>>>=20 >>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt : >>>>=20 >>>>> IMHO the best mechanism at hand currently to cope with token leakage/r= eplay in SPAs is to use refresh tokens (rotating w/ replay detection) and is= sue short living and privilege restricted access tokens. >>>>>=20 >>>>> Sender constrained access tokens in SPAs need adoption of token bindin= g or alternative mechanism. mtls could potentially work in deployments with a= utomated cert rollout but browser UX and interplay with fetch needs some wor= k. We potentially must consider to warm up application level PoP mechanisms i= n conjunction with web crypto. Another path to be evaluated could be web aut= h. >>>>>=20 >>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig : >>>>>=20 >>>>>> I share the concern Brian has, which is also the conclusion I came up= with in my other email sent a few minutes ago. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> From: OAuth On Behalf Of Brian Campbell >>>>>> Sent: Friday, November 30, 2018 11:43 PM >>>>>> To: Torsten Lodderstedt >>>>>> Cc: oauth >>>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt wrote: >>>>>>=20 >>>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen : >>>>>> >=20 >>>>>> > So you mean at the resource server ensuring the token was really is= sued to the client? Isn't that an inherent limitatio= n of all bearer tokens (modulo HTTP token binding, which is still some time o= ff)? >>>>>>=20 >>>>>> Sure. That=E2=80=99s why the Security BCP recommends use of TLS-based= methods for sender constraining access tokens (https://tools.ietf.org/html/= draft-ietf-oauth-security-topics-09#section-2..2). Token Binding for OAuth (= https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mu= tual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) ar= e the options available. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Unfortunately even when using the token endpo= int, for SPA / in-browser client applications, the potential mechanisms for s= ender/key-constraining access tokens don't work very well or maybe don't wor= k at all. So I don't know that the recommendation is very realistic. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.. If you hav= e received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your compute= r. Thank you. >>>>>>=20 >>>>>> IMPORTANT NOTICE: The contents of this email and any attachments are c= onfidential and may also be privileged. If you are not the intended recipien= t, please notify the sender immediately and do not disclose the contents to a= ny 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 >>>>=20 >>>>=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 >> _______________________________________________ >> 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-27C4B204-5E14-4D27-ACCE-BBA32ADDEF6F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
You may be placing undue confidence in= that gateway acting as a confidential client but having no real security of= its own and which could be easily duped. 

Phil

On Dec 2, 2018, a= t 3:43 PM, Aaron Parecki <aaron@pare= cki.com> wrote:

In this type of deployment, as far as OAuth is concerned= , isn't the backend web server a confidential client? Is there even anything= unique to this situation as far as OAuth security goes? 

I wouldn't have expected an Angular app that talks to its own server b= ackend that's managing OAuth credentials to fall under the umbrella of this B= CP.

----
Aaron Parecki
aaronparecki.com<= /div>



On Sat, Dec 1, 2018 at 11:31 PM Torsten Loddersted= t <torsten@lodderstedt.net= > wrote:
the UI is rendered in the frontend, UI cont= rol flow is in the frontend. just a different cut through the web app=E2=80=99= s layering 

All Angula= r apps I have seen so far work that way. And it makes a lot of sense to me. T= he backend can aggregate and optimize access to the underlying services with= out the need to fully expose them.

Am 02.12.2018 u= m 00:44 schrieb John Bradley <ve7jtb@ve7jtb.com>:

=20 =20 =20 =20

How is that different from a regular server client with a web interface if the backed is doing the API calls to the RS?


On 12/1/2018 12:25 P= M, Torsten Lodderstedt wrote:
=20
I forgot to mention another (architectural) option: split an application into frontend provided by JS in the browser and a backend, which takes care of the business logic and handles tokens and API access. Replay detection at the interface between SPA and backend can utilize standard web techniques (see OWASP). The backend in turn can use mTLS for sender constraining.

Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <torsten@lodderstedt.net&= gt;:

=20
IMHO the best mechanism at hand currently to cope with token leakage/replay in SPAs is to use refresh tokens (rotating w/ replay detection) and issue short living and privilege restricted access tokens.

Sender constrained access tokens in SPAs need adoption of token binding or alternative mechanism. mtls could potentially work in deployments with automated cert rollout but browser UX and interplay with fetch needs some work. We potentially must consider to warm up application level PoP mechanisms in conjunction with web crypto. Another path to be evaluated could be web auth.

Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <Hannes.Tschofenig@arm.co= m>:

=20 =20 =20

I share the concern Brian has, which is also the conclusion I came up with in my other email sent a few minutes ago.

 

From:<= /b> OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
Sent: Friday, November 30, 2018 11:43 PM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00<= /span>

 

<= /u> 

On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

> Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.com>:
>
> So you mean at the resource server ensuring the token was really issued to the client? Isn't that an inherent limitation of all bearer tokens (modulo HTTP token binding, which is still some time off)?

Sure. That=E2=80=99s why the Security BCP recommends= use of TLS-based methods for sender constraining access tokens (https:= //tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).= Token Binding for OAuth (https://to= ols.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mutual TLS for OAuth (https://tool= s.ietf.org/html/draft-ietf-oauth-mtls-12) are the options available.

 

Unfortunately even when using the token endpoint, for SPA / in-browser client applications, the potential mechanisms for sender/key-constraining access tokens don't work very well or maybe don't work at all. So I don't know that the recommendation is very realistic.

 


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.

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 the information in any medium. Thank you.
_____________________________________________= __
OAuth mailing list
OAuth@ie= tf.org
https://www.ietf.org/mailman/listinfo/oauth

___________________=
____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai=
lman/listinfo/oauth
=20
________= _______________________________________
OAuth mailing list
OAuth@iet= f.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.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-27C4B204-5E14-4D27-ACCE-BBA32ADDEF6F-- From nobody Sun Dec 2 19:18:16 2018 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 76173130DE2 for ; Sun, 2 Dec 2018 19:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 kpnZLYzBphNx for ; Sun, 2 Dec 2018 19:18:12 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 2C12C124D68 for ; Sun, 2 Dec 2018 19:18:12 -0800 (PST) Received: from [IPv6:2601:282:202:b210:9943:3b40:e867:2ba5] (unknown [IPv6:2601:282:202:b210:9943:3b40:e867:2ba5]) by alkaline-solutions.com (Postfix) with ESMTPSA id 15F66315FE; Mon, 3 Dec 2018 03:18:10 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E450B7E6-D1E7-4056-B43D-542D3D9BCBC8" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sun, 2 Dec 2018 20:18:09 -0700 In-Reply-To: Cc: Torsten Lodderstedt , OAuth WG To: Aaron Parecki References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 03 Dec 2018 03:18:14 -0000 --Apple-Mail=_E450B7E6-D1E7-4056-B43D-542D3D9BCBC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Agreed, if the BCP is meant to describe javascript behavior for best = practices as respect to being an OAuth client, I=E2=80=99m unsure what = would belong in this document for javascript which is instead = interacting over non-standard mechanisms with an OAuth client.=20 Instead, it would be generalized browser javascript security practices. = It would be sure to overlap with some of the recommendations made to a = client managing OAuth in the browser, but such a spec wouldn=E2=80=99t = be under the umbrella of the OAuth WG - would it? We would be talking = about general non-OAuth browser security practices around important = cookies. If (as Hans proposed) there was a mechanism for javascript to get access = tokens to interact with protected resources in lieu of the client, there = could be BCP around managing that (which would likely also overlap with = a genuine javascript-in-browser client), but unfortunately there = aren=E2=80=99t technical specs to support that sort of architecture yet. -DW > On Dec 2, 2018, at 4:43 PM, Aaron Parecki wrote: >=20 > In this type of deployment, as far as OAuth is concerned, isn't the = backend web server a confidential client? Is there even anything unique = to this situation as far as OAuth security goes?=20 >=20 > I wouldn't have expected an Angular app that talks to its own server = backend that's managing OAuth credentials to fall under the umbrella of = this BCP. >=20 > ---- > Aaron Parecki > aaronparecki.com >=20 >=20 >=20 > On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt = > wrote: > the UI is rendered in the frontend, UI control flow is in the = frontend. just a different cut through the web app=E2=80=99s layering=20 >=20 > All Angular apps I have seen so far work that way. And it makes a lot = of sense to me. The backend can aggregate and optimize access to the = underlying services without the need to fully expose them. >=20 > Am 02.12.2018 um 00:44 schrieb John Bradley >: >=20 >> How is that different from a regular server client with a web = interface if the backed is doing the API calls to the RS? >>=20 >>=20 >>=20 >> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: >>> I forgot to mention another (architectural) option: split an = application into frontend provided by JS in the browser and a backend, = which takes care of the business logic and handles tokens and API = access. Replay detection at the interface between SPA and backend can = utilize standard web techniques (see OWASP). The backend in turn can use = mTLS for sender constraining. >>>=20 >>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt = >: >>>=20 >>>> IMHO the best mechanism at hand currently to cope with token = leakage/replay in SPAs is to use refresh tokens (rotating w/ replay = detection) and issue short living and privilege restricted access = tokens. >>>>=20 >>>> Sender constrained access tokens in SPAs need adoption of token = binding or alternative mechanism. mtls could potentially work in = deployments with automated cert rollout but browser UX and interplay = with fetch needs some work. We potentially must consider to warm up = application level PoP mechanisms in conjunction with web crypto. Another = path to be evaluated could be web auth. >>>>=20 >>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig = >: >>>>=20 >>>>> I share the concern Brian has, which is also the conclusion I came = up with in my other email sent a few minutes ago. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: OAuth > On Behalf Of Brian Campbell >>>>> Sent: Friday, November 30, 2018 11:43 PM >>>>> To: Torsten Lodderstedt > >>>>> Cc: oauth > >>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt = > wrote: >>>>>=20 >>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen >: >>>>> >=20 >>>>> > So you mean at the resource server ensuring the token was really = issued to the client? Isn't that an inherent limitation of all bearer = tokens (modulo HTTP token binding, which is still some time off)? >>>>>=20 >>>>> Sure. That=E2=80=99s why the Security BCP recommends use of = TLS-based methods for sender constraining access tokens = (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2= ..2 = ). Token Binding for OAuth = (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08 = ) as = well as Mutual TLS for OAuth = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12 = ) are the options = available.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Unfortunately even when using the token endpoint, for SPA / = in-browser client applications, the potential mechanisms for = sender/key-constraining access tokens don't work very well or maybe = don't work at all. So I don't know that the recommendation is very = realistic. >>>>>=20 >>>>> =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. >>>>>=20 >>>>> 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 = the information in any medium. Thank you. >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=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 = > _______________________________________________ > 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=_E450B7E6-D1E7-4056-B43D-542D3D9BCBC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Agreed, if the BCP is meant to describe javascript behavior = for best practices as respect to being an OAuth client, I=E2=80=99m = unsure what would belong in this document for javascript which is = instead interacting over non-standard mechanisms with an OAuth = client. 

Instead,= it would be generalized browser javascript security practices. It would = be sure to overlap with some of the recommendations made to a client = managing OAuth in the browser, but such a spec wouldn=E2=80=99t be under = the umbrella of the OAuth WG - would it? We would be talking about = general non-OAuth browser security practices around important = cookies.

If = (as Hans proposed) there was a mechanism for javascript to get access = tokens to interact with protected resources in lieu of the client, there = could be BCP around managing that (which would likely also overlap with = a genuine javascript-in-browser client), but unfortunately there = aren=E2=80=99t technical specs to support that sort of architecture = yet.

-DW

On Dec = 2, 2018, at 4:43 PM, Aaron Parecki <aaron@parecki.com> = wrote:

In this type of deployment, as far as OAuth is = concerned, isn't the backend web server a confidential client? Is there = even anything unique to this situation as far as OAuth security = goes? 

I = wouldn't have expected an Angular app that talks to its own server = backend that's managing OAuth credentials to fall under the umbrella of = this BCP.

----
Aaron Parecki
aaronparecki.com



On = Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
the UI is rendered in the frontend, UI control flow is in the = frontend. just a different cut through the web app=E2=80=99s = layering 

All Angular apps I have seen so far work that = way. And it makes a lot of sense to me. The backend can aggregate and = optimize access to the underlying services without the need to fully = expose them.

Am = 02.12.2018 um 00:44 schrieb John Bradley <ve7jtb@ve7jtb.com>:

How is that different from a regular server = client with a web interface if the backed is doing the API calls to the RS?


On 12/1/2018 = 12:25 PM, Torsten Lodderstedt wrote:
=20
I forgot to mention another = (architectural) option: split an application into frontend provided by JS in the browser and a backend, which takes care of the business logic and handles tokens and API access. Replay detection at the interface between SPA and backend can utilize standard web techniques (see OWASP). The backend in turn can use mTLS for sender constraining.

Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <torsten@lodderstedt.net>:

=20
IMHO the best mechanism at hand = currently to cope with token leakage/replay in SPAs is to use refresh tokens (rotating w/ replay detection) and issue short living and privilege restricted access tokens.

Sender constrained access tokens = in SPAs need adoption of token binding or alternative mechanism. mtls could potentially work in deployments with automated cert rollout but browser UX and interplay with fetch needs some work. We potentially must consider to warm up application level PoP mechanisms in conjunction with web crypto. Another path to be evaluated could be web auth.

Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <Hannes.Tschofenig@arm.com>:

=20 =20 =20

I share the concern Brian has, which is also the conclusion I came up with in my other email sent a few minutes ago.

 

From:= OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
Sent: Friday, November 30, 2018 = 11:43 PM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

 

 

On Sat, Nov = 17, 2018 at 4:07 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

> Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.com>:
>
> So you mean at the resource server ensuring the token was really issued to the client? Isn't that an inherent limitation of all bearer tokens (modulo HTTP token binding, which is still some time off)?

Sure. That=E2=80=99s why the Security BCP = recommends use of TLS-based methods for sender constraining access tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09= #section-2..2). Token Binding for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options available.

 

Unfortunately = even when using the token endpoint, for SPA / in-browser client applications, the potential mechanisms for sender/key-constraining access tokens don't work very well or maybe don't work at all. So I don't know that the recommendation is very realistic.

 


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.

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 the information in any medium. Thank you.
_______________________________________________
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
=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
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_E450B7E6-D1E7-4056-B43D-542D3D9BCBC8-- From nobody Sun Dec 2 23:30:49 2018 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 29ADA128D68 for ; Sun, 2 Dec 2018 23:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=zmartzone-eu.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 Y7ncFAKVfndO for ; Sun, 2 Dec 2018 23:30:44 -0800 (PST) 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 A5F0B124C04 for ; Sun, 2 Dec 2018 23:30:44 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id x6so9569432ioa.9 for ; Sun, 02 Dec 2018 23:30:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pmlph3QbuR9hcKFBukKWgZ7F+J8Lp9Q0Oc/V/k+RmoA=; b=R8U3R8lsocGW/BIQAZBdDEEMSbdQ6ulix6iTc9lXCbywWmR1gb9R1sc1uvapbp/nZF 7mLA5buEjsnKS6YVHjRLzdU1D0t5JR6m57bc+ofOHTy4aPeLBT56s1TH48XlEUKYD7UK CNtNLaeH2LDdmHHJ4VQezofHB8FSVMGo9rnov4hlhY9r+veod7HntyPJs0zQSbFB0UVk 4GLFRu75Gjjb30wFYJrUhy0yLI6I3+wfRxxIcGpyF9Vv7lMwF8FGIhFoKIeSFFEDd4QK Zl4lMe+hLgJeCGdJTWHfzDM8qf+665sNmi4/7rXIDUSxD1SXOT/zx2bcrYtLZp2Be2lG zp5w== 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=pmlph3QbuR9hcKFBukKWgZ7F+J8Lp9Q0Oc/V/k+RmoA=; b=UIzKOLpfTNKa7mvV+oWkvfIKAC6t9m3ssfiTXGF2SiVRSMvFIhtHX1ZHMLOwhMZcOM bCsMkXX4FtflYT5EnqbyXS8lycssbetb9F6piWYDBBTGjHPoyF7qwxXHGAISG/ZCxwmy At/6jRuzqglP/UHccwqZ0phP79czN3YMB9ksCIwmH9luCBgqv1DYj7g44+tbtxMW6A60 EDsMVlEbrgBrioLIAkfzu+ReV1XIRnFqDEAoqjDn8a2JCa+Kj5gprPnl7ojEDfRzUPuK EM6xr8hDB58Ebl+YCT1PG6s2q+PDzWgs4v1kY86mNi2YXauPbFtnCxuLZLsVazOHqIFr 3TfQ== X-Gm-Message-State: AA+aEWa6ccc5sDVb4cnJMwSbWiHbtYgVumj5OGd+TwYbvzVqIaFd9r3i XAxbJKnZ4dcQEO4ZpV58GKYZRa+FMhcMT1olbt84r3XD X-Google-Smtp-Source: AFSGD/Uc5aCG5UeG1orsbpdSl2EqeLOF46WKHxhv8SI3Q7Mf7u37k2qejTSPNJXk24ixkMO6W0t2b8bPnD8wG7FGW3k= X-Received: by 2002:a6b:c815:: with SMTP id y21mr12031409iof.98.1543822243776; Sun, 02 Dec 2018 23:30:43 -0800 (PST) MIME-Version: 1.0 References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> In-Reply-To: From: Hans Zandbelt Date: Mon, 3 Dec 2018 08:30:32 +0100 Message-ID: To: David Waite Cc: Aaron Parecki , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006ff282057c1920d0" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 03 Dec 2018 07:30:48 -0000 --0000000000006ff282057c1920d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 3, 2018 at 4:18 AM David Waite wrote: > If (as Hans proposed) there was a mechanism for javascript to get access > tokens to interact with protected resources in lieu of the client, there > could be BCP around managing that (which would likely also overlap with a > genuine javascript-in-browser client), but unfortunately there aren=E2=80= =99t > technical specs to support that sort of architecture yet. > I agree with Aaron and David that this should be written up elsewhere and hopefully be referred to from this BCP as it is relevant; anyone willing to contribute and/or suggest where "elsewhere" is? Hans. > -DW > > On Dec 2, 2018, at 4:43 PM, Aaron Parecki wrote: > > In this type of deployment, as far as OAuth is concerned, isn't the > backend web server a confidential client? Is there even anything unique t= o > this situation as far as OAuth security goes? > > I wouldn't have expected an Angular app that talks to its own server > backend that's managing OAuth credentials to fall under the umbrella of > this BCP. > > ---- > Aaron Parecki > aaronparecki.com > > > > On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> the UI is rendered in the frontend, UI control flow is in the frontend. >> just a different cut through the web app=E2=80=99s layering >> >> All Angular apps I have seen so far work that way. And it makes a lot of >> sense to me. The backend can aggregate and optimize access to the >> underlying services without the need to fully expose them. >> >> Am 02.12.2018 um 00:44 schrieb John Bradley : >> >> How is that different from a regular server client with a web interface >> if the backed is doing the API calls to the RS? >> >> >> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: >> >> I forgot to mention another (architectural) option: split an application >> into frontend provided by JS in the browser and a backend, which takes c= are >> of the business logic and handles tokens and API access. Replay detectio= n >> at the interface between SPA and backend can utilize standard web >> techniques (see OWASP). The backend in turn can use mTLS for sender >> constraining. >> >> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt < >> torsten@lodderstedt.net>: >> >> IMHO the best mechanism at hand currently to cope with token >> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay >> detection) and issue short living and privilege restricted access tokens= . >> >> Sender constrained access tokens in SPAs need adoption of token binding >> or alternative mechanism. mtls could potentially work in deployments wit= h >> automated cert rollout but browser UX and interplay with fetch needs som= e >> work. We potentially must consider to warm up application level PoP >> mechanisms in conjunction with web crypto. Another path to be evaluated >> could be web auth. >> >> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig < >> Hannes.Tschofenig@arm.com>: >> >> I share the concern Brian has, which is also the conclusion I came up >> with in my other email sent a few minutes ago. >> >> >> >> *From:* OAuth *On Behalf Of *Brian Campbell >> *Sent:* Friday, November 30, 2018 11:43 PM >> *To:* Torsten Lodderstedt >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 >> >> >> >> >> >> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >> > Am 15.11.2018 um 23:01 schrieb Brock Allen : >> > >> > So you mean at the resource server ensuring the token was really issue= d >> to the client? Isn't that an inherent limitation of all bearer tokens >> (modulo HTTP token binding, which is still some time off)? >> >> Sure. That=E2=80=99s why the Security BCP recommends use of TLS-based me= thods for >> sender constraining access tokens ( >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-= 2..2). >> Token Binding for OAuth ( >> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08 >> ) as >> well as Mutual TLS for OAuth ( >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options >> available. >> >> >> >> Unfortunately even when using the token endpoint, for SPA / in-browser >> client applications, the potential mechanisms for sender/key-constrainin= g >> access tokens don't work very well or maybe don't work at all. So I don'= t >> know that the recommendation is very realistic. >> >> >> >> >> *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 send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> 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 t= he >> information in any medium. Thank you. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> _______________________________________________ >> 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 > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --0000000000006ff282057c1920d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, De= c 3, 2018 at 4:18 AM David Waite <david@alkaline-solutions.com> wrote:
If (as Hans proposed) there was a mechanism for javascript to= get access tokens to interact with protected resources in lieu of the clie= nt, there could be BCP around managing that (which would likely also overla= p with a genuine javascript-in-browser client), but unfortunately there are= n=E2=80=99t technical specs to support that sort of architecture yet.
=

I agree with Aaron and David that th= is should be written up elsewhere and hopefully be referred to from this BC= P as it is relevant; anyone willing to contribute and/or suggest where &quo= t;elsewhere" is?

Hans.


-DW

On Dec 2, 2018, at 4:43 PM, Aaron Parecki <aaron@parecki.com> wrote:
=
In this type of deployment, as far as OAuth is concerned, isn'= t the backend web server a confidential client? Is there even anything uniq= ue to this situation as far as OAuth security goes?=C2=A0

I wouldn't have expected an Angular app that talks to its own server = backend that's managing OAuth credentials to fall under the umbrella of= this BCP.

----
Aaron Parecki


=

On Sat, Dec 1, = 2018 at 11:31 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
=
=
the UI is rendered in the frontend, UI control flow is in = the frontend. just a different cut through the web app=E2=80=99s layering= =C2=A0

All Angular apps I = have seen so far work that way. And it makes a lot of sense to me. The back= end can aggregate and optimize access to the underlying services without th= e need to fully expose them.

Am 02.12.2018 um 00:= 44 schrieb John Bradley <ve7jtb@ve7jtb.com>:

<= div dir=3D"ltr">

How is that different from a regular server client with = a web interface if the backed is doing the API calls to the RS?


On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
=20
I forgot to mention another (architectural) option: split an application into frontend provided by JS in the browser and a backend, which takes care of the business logic and handles tokens and API access. Replay detection at the interface between SPA and backend can utilize standard web techniques (see OWASP). The backend in turn can use mTLS for sender constraining.

Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <torsten@lodderstedt.net>:

=20
IMHO the best mechanism at hand currently to cope with token leakage/replay in SPAs is to use refresh tokens (rotating w/ replay detection) and issue short living and privilege restricted access tokens.

Sender constrained access tokens in SPAs need adoption of token binding or alternative mechanism. mtls could potentially work in deployments with automated cert rollout but browser UX and interplay with fetch needs some work. We potentially must consider to warm up application level PoP mechanisms in conjunction with web crypto. Another path to be evaluated could be web auth.
=20 =20 =20

I share the concern Brian has, which is also the conclusion I came up with in my other email sent a few minutes ago.

=C2=A0

From: OAuth <oauth-bounces@ietf.org&= gt; On Behalf Of Brian Campbell
Sent: Friday, November 30, 2018 11:43 PM
To: Torsten Lodderstedt <torsten@lodderstedt.net> Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00=

=C2=A0

= =C2=A0

On Sat, Nov 17, 2018 at 4:0= 7 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

> Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.com>:
>
> So you mean at the resource server ensuring the token was really issued to the client? Isn'= t that an inherent limitation of all bearer tokens (modulo HTTP token binding, which is still some time off)?

Sure. That=E2=80=99s why the Security BCP recommend= s use of TLS-based methods for sender constraining access tokens (http= s://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2). Token Binding for OAuth (https://= tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mutual TLS for OAuth (https://to= ols.ietf.org/html/draft-ietf-oauth-mtls-12) are the options available.

=C2=A0

Unfortunately even when usi= ng the token endpoint, for SPA / in-browser client applications, the potential mechanisms for sender/key-constraining access tokens don't wor= k very well or maybe don't work at all. So I don&= #39;t know that the recommendation is very realistic.

=C2=A0


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..=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 attachments from your computer. Thank you.

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 the information in any medium. Thank you.
____________________________________________= ___
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth
=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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
<= a href=3D"mailto:hans.zandbelt@zmartzone.eu" target=3D"_blank">hans.zandbel= t@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
<= /div>
--0000000000006ff282057c1920d0-- From nobody Mon Dec 3 00:25:22 2018 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 7C3BB1286E3 for ; Mon, 3 Dec 2018 00:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, 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 Cr-LaUvj7ftX for ; Mon, 3 Dec 2018 00:25:16 -0800 (PST) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.97]) (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 1681A12777C for ; Mon, 3 Dec 2018 00:25:15 -0800 (PST) Received: from [91.13.153.47] (helo=[192.168.71.112]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gTjXT-0008H0-Vk; Mon, 03 Dec 2018 09:25:12 +0100 Content-Type: multipart/signed; boundary=Apple-Mail-43BBE0E0-19E5-4DFC-A857-070AC36FDBE4; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Mon, 3 Dec 2018 09:25:10 +0100 Cc: David Waite , "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <33A5FD93-0A1C-426E-9F50-519D51094B28@lodderstedt.net> References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> To: Hans Zandbelt X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 03 Dec 2018 08:25:20 -0000 --Apple-Mail-43BBE0E0-19E5-4DFC-A857-070AC36FDBE4 Content-Type: multipart/alternative; boundary=Apple-Mail-CB4EBE80-32D5-45F5-B058-E35E21CB7D56 Content-Transfer-Encoding: 7bit --Apple-Mail-CB4EBE80-32D5-45F5-B058-E35E21CB7D56 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think the BCP needs to point out there are solutions beyond an app directl= y interacting with AS and RSs from the browser. Otherwise people get the wro= ng impression this is the only way to go. To the contrary and as I pointed o= ut, there are a lot of SPAs working as UI of a larger application.=20 Any multi user app needs a database. Will this database be directly exposed t= o the frontend? I don=E2=80=99t think so. There will be a backend, exposing r= elevant capabilities to the SPA. And if this app also uses external services, where do you want to store the r= espective refresh tokens? In the browser=E2=80=99s local storage? I don=E2=80= =99t believe so. They will go into the same backend & database. And there are other reasons: No one will ever be able to implement a PSD2 TP= P as a stand-alone SPA, obviously because it requires a confidential client b= ut there are more aspects.=20 Moreover, some security objectives can only be achieved if a backend is used= . That=E2=80=99s how the discussion started (token binding and the like). IMHO omitting this option significantly reduces the relevance of the BCP. I=E2=80=99m not saying we shall describe the interaction between frontend an= d backend in detail. I advocate for pointing out this option and its benefit= s. That=E2=80=99s it. > Am 03.12.2018 um 08:30 schrieb Hans Zandbelt := >=20 >=20 >> On Mon, Dec 3, 2018 at 4:18 AM David Waite = wrote: >> If (as Hans proposed) there was a mechanism for javascript to get access t= okens to interact with protected resources in lieu of the client, there coul= d be BCP around managing that (which would likely also overlap with a genuin= e javascript-in-browser client), but unfortunately there aren=E2=80=99t tech= nical specs to support that sort of architecture yet. >=20 > I agree with Aaron and David that this should be written up elsewhere and h= opefully be referred to from this BCP as it is relevant; anyone willing to c= ontribute and/or suggest where "elsewhere" is? >=20 > Hans. >=20 >>=20 >> -DW >>=20 >>> On Dec 2, 2018, at 4:43 PM, Aaron Parecki wrote: >>>=20 >>> In this type of deployment, as far as OAuth is concerned, isn't the back= end web server a confidential client? Is there even anything unique to this s= ituation as far as OAuth security goes?=20 >>>=20 >>> I wouldn't have expected an Angular app that talks to its own server bac= kend that's managing OAuth credentials to fall under the umbrella of this BC= P. >>>=20 >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>>=20 >>>=20 >>>=20 >>>> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt wrote: >>>> the UI is rendered in the frontend, UI control flow is in the frontend.= just a different cut through the web app=E2=80=99s layering=20 >>>>=20 >>>> All Angular apps I have seen so far work that way. And it makes a lot o= f sense to me. The backend can aggregate and optimize access to the underlyi= ng services without the need to fully expose them. >>>>=20 >>>>> Am 02.12.2018 um 00:44 schrieb John Bradley : >>>>>=20 >>>>> How is that different from a regular server client with a web interfac= e if the backed is doing the API calls to the RS? >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: >>>>>> I forgot to mention another (architectural) option: split an applicat= ion into frontend provided by JS in the browser and a backend, which takes c= are of the business logic and handles tokens and API access. Replay detectio= n at the interface between SPA and backend can utilize standard web techniqu= es (see OWASP). The backend in turn can use mTLS for sender constraining. >>>>>>=20 >>>>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt : >>>>>>=20 >>>>>>> IMHO the best mechanism at hand currently to cope with token leakage= /replay in SPAs is to use refresh tokens (rotating w/ replay det= ection) and issue short living and privilege restricted access tokens. >>>>>>>=20 >>>>>>> Sender constrained access tokens in SPAs need adoption of token bind= ing or alternative mechanism. mtls could potentially work in deployments wit= h automated cert rollout but browser UX and interplay with fetch needs some w= ork. We potentially must consider to warm up application level PoP mechanism= s in conjunction with web crypto. Another path to be evaluated could be web a= uth. >>>>>>>=20 >>>>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig : >>>>>>>=20 >>>>>>>> I share the concern Brian has, which is also the conclusion I came u= p with in my other email sent a few minutes ago. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> From: OAuth On Behalf Of Brian Campbell >>>>>>>> Sent: Friday, November 30, 2018 11:43 PM >>>>>>>> To: Torsten Lodderstedt >>>>>>>> Cc: oauth >>>>>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt wrote: >>>>>>>>=20 >>>>>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen = : >>>>>>>> >=20 >>>>>>>> > So you mean at the resource server ensuring the token was really i= ssued to the client? Isn't that an inherent limitation of all bearer tokens (= modulo HTTP token binding, which is still some time off)? >>>>>>>>=20 >>>>>>>> Sure. That=E2=80=99s why the Security BCP recommends use of TLS-bas= ed methods for sender constraining access tokens (https://tools.ietf.org/htm= l/draft-ietf-oauth-security-topics-09#section-2..2). Token Binding for OAuth= (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as M= utual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) a= re the options available. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Unfortunately even when using the token endpoint, for SPA / in-brow= ser client applications, the potential mechanisms for sender/key-constrainin= g access tokens don't work very well or maybe don't w= ork at all. So I don't know that the recommendation is very realistic. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and pri= vileged material for the sole use of the intended recipient(s). Any review, u= se, distribution or disclosure by others is strictly prohibited.. If you ha= ve received this communication in error, please noti= fy the sender immediately by e-mail and delete the message and any file atta= chments from your computer. Thank you. >>>>>>>>=20 >>>>>>>> IMPORTANT NOTICE: The contents of this email and any attachments ar= e confidential and may also be privileged. If you are not the intended recip= ient, please notify the sender immediately and do not disclose the contents t= o 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 >>>>>>=20 >>>>>>=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 >>>> _______________________________________________ >>>> 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 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > --=20 > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-CB4EBE80-32D5-45F5-B058-E35E21CB7D56 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I t= hink the BCP needs to point out there are solutions beyond an app directly i= nteracting with AS and RSs from the browser. Otherwise people get the wrong i= mpression this is the only way to go. To the contrary and as I pointed out, t= here are a lot of SPAs working as UI of a larger application. 

Any multi user app needs a database= . Will this database be directly exposed to the frontend? I don=E2=80=99t th= ink so. There will be a backend, exposing relevant capabilities to the SPA.<= /div>

And if this app also uses e= xternal services, where do you want to store the respective refresh tokens? I= n the browser=E2=80=99s local storage? I don=E2=80=99t believe so. They will= go into the same backend & database.

And there are other reasons: No one will ever be able to impl= ement a PSD2 TPP as a stand-alone SPA, obviously because it requires a confi= dential client but there are more aspects. 

<= /div>
Moreover, some security objectives can only be achieve= d if a backend is used. That=E2=80=99s how the discussion started (token bin= ding and the like).

IMHO om= itting this option significantly reduces the relevance of the BCP.

I=E2=80=99m not saying we shall desc= ribe the interaction between frontend and backend in detail. I advocate for p= ointing out this option and its benefits. That=E2=80=99s it.

Am 03.12.2018 um 08:30 schrieb Hans Zandbelt <hans.zandbelt@zmartzone.eu>:


On Mon, Dec 3, 2018 at 4:18 AM David Waite= <david@alkaline-solution= s.com> wrote:
If (as Hans proposed) t= here was a mechanism for javascript to get access tokens to interact with pr= otected resources in lieu of the client, there could be BCP around managing t= hat (which would likely also overlap with a genuine javascript-in-browser cl= ient), but unfortunately there aren=E2=80=99t technical specs to support tha= t sort of architecture yet.

I ag= ree with Aaron and David that this should be written up elsewhere and hopefu= lly be referred to from this BCP as it is relevant; anyone willing to contri= bute and/or suggest where "elsewhere" is?

Hans.=


-DW

On Dec 2, 2018, at 4:43 PM, Aaron Parecki <aaron@parecki.com>= wrote:

In this type of deployment, as far as OAuth is concerned= , isn't the backend web server a confidential client? Is there even anything= unique to this situation as far as OAuth security goes? 

I wouldn't have expected an Angular app that talks to its own server b= ackend that's managing OAuth credentials to fall under the umbrella of this B= CP.

----
Aa= ron Parecki


=
On Sat, Dec 1, 2018 at 11:31= PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
the UI is rendered in the frontend, UI control flow is in the frontend. jus= t a different cut through the web app=E2=80=99s layering 

All Angular apps I have seen so far work= that way. And it makes a lot of sense to me. The backend can aggregate and o= ptimize access to the underlying services without the need to fully expose t= hem.

Am 02.12.2018 um 00:44 schrieb John Bradley &= lt;ve7jtb@ve7jtb.com<= /a>>:

How is t= hat different from a regular server client with a web interface if the backed is doing the API calls to the RS?


On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
=20
I forgot to mention another (architectural) option: split an application into frontend provided by JS in the browser and a backend, which takes care of the business logic and handles tokens and API access. Replay detection at the interface between SPA and backend can utilize standard web techniques (see OWASP). The backend in turn can use mTLS for sender constraining.
=20
IMHO the best mechanism at hand currently to cope with token leakage/replay in SPAs is to use refresh tokens (rotating w/ replay detection) and issue short living and privilege restricted access tokens.

Sender constrained access tokens in SPAs need adoption of token binding or alternative mechanism. mtls could potentially work in deployments with automated cert rollout but browser UX and interplay with fetch needs some work. We potentially must consider to warm up application level PoP mechanisms in conjunction with web crypto. Another path to be evaluated could be web auth.

Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <Hannes.Tschofenig@arm.co= m>:

=20 =20 =20

I share the concern Brian has, which is also the conclusion I came up with in my other email sent a few minutes ago.

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
Sent: Friday, November 30, 2018 11:43 PM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00<= /span>

 

<= u> 

On Sat, Nov 17, 2018 at 4:07= AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

> Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.com>:
>
> So you mean at the resource server ensuring the token was really issued to the client? Isn't that an inherent limitation of all bearer tokens (modulo HTTP token binding, which is still some time off)?

Sure. That=E2=80=99s why the Security BCP recommends= use of TLS-based methods for sender constraining access tokens (https:= //tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).= Token Binding for OAuth (https://to= ols.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mutual TLS for OAuth (https://tool= s.ietf.org/html/draft-ietf-oauth-mtls-12) are the options available.

 

Unfortunately even when usin= g the token endpoint, for SPA / in-browser client applications, the potential mechanisms for sender/key-constraining access tokens don't work very well or maybe don't work at all. So I don't know that the recommendation is very realistic.

 


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.

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 the information in any medium. Thank you.
_____________________________________________= __
OAuth mailing list
OAuth@ie= tf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/oauth
=20
________= _______________________________________
OAuth mailing list
OAuth@iet= f.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


--
________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-CB4EBE80-32D5-45F5-B058-E35E21CB7D56-- --Apple-Mail-43BBE0E0-19E5-4DFC-A857-070AC36FDBE4 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCocw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIFRTCCBC2gAwIBAgIQM9uaxqrCN5lrc/ED e5nwtDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE3MDEwOTAwMDAwMFoXDTE4MDEwOTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYX dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCu wZLNnLP0ur1JFb1K97kryfmVaGmU4ITocfeAzJ7XYOM6mQUVm3Rvve3bsbXteynpZTEeE169/tyT QBSm9hQ8IcGpUYlIhYX2FYChIUKBAAI6iH9wMVvPPU+wxjwSXs6Yi6zgle1jj9V2hIiEU/eHMBNs 0CDfYqn43y+1O4pPBuCeLMlLLNlNiuy22fcubBjXsdT5T29eWgy6zlT+WfgANnHTPLINKwDqC0/F dgmluBJOcdyRVnnN9HzSC4hnnfxjaqqyq3lVpJFJHahDMT8cROQpz+h09WGoGtcvK+dIWQI+sBdX Tuty/CQ+8dl5hW7hB1VbI7YchDiLbH2vmbtLAgMBAAGjggH1MIIB8TAfBgNVHSMEGDAWgBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU+eAeBXE5nsZKOL8hbhgkwGPTY8cwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy ZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCIGA1UdEQQbMBmB F3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IBAQACa57IeOLIvWpiB976 FVKwa4qWBy+MIB8bwlqrjy0LQiM/ykf+0aLi4v0IdV8udXeksOeODoza6+kQGntytllydI8t5Wyz 62SHC/4XshJhDJPh+U2SpVRvyd97BsI9wg3Xc5t+lTuuVeghqsQSmVCjhK7KZhWW5DFMs4UqblA4 wXgkEzD+uPLi33knsx2n00VTNCso8kNonYmv9NxNcVyMu81WYwGMrT3n1r2/X/WaJEd3UMGxOHUq 8GKAQ5Q0zG9Pm5S0Hr+2KgNmoEMOTwa92ej/GbJ7diJqxLsmAxESrlZxeqlYa7mQwVkwY8S/I8d4 Fl6rHHdqZ/giZWdnpa+DMYID0DCCA8wCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMjAzMDgyNTEwWjAvBgkqhkiG 9w0BCQQxIgQgQJOO//0OaJnPV1A8lhW7059EMTGZBY5/XzqMiV+bVo8wgcEGCSsGAQQBgjcQBDGB szCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3 mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAKF/ 9wlrdFB1SMrBRoUPsL3M4ZzPY4czYNNvx20PAONuAP+AOmj8fhP1hizf6xOEZvgf+VKt35+MFwMM kWBd4hbifWMD78Sp19I/r+P0Uzr5L20FabDFyKfGYaH2VnUW1wp7yvGfnxl3tRPVYOmYg4EFBaxz ZQhkOrQb5CRQLjlZlnnta7MyQVmzync4J3Q2ruSgP8zhdTHQ3UzlxR/8hPCX3LJucpGiyGXcz8Op 4zrc4QWNRAYYSYOAGGMAZO1mrbzC1w9YqyWbX/shPN33Bkqw4Ddkrso+66TWH7t46P8QIe2zHJiY AW/QsMdZT9WTGrKvwMxrd7Cgckqqs0Z+WD4AAAAAAAA= --Apple-Mail-43BBE0E0-19E5-4DFC-A857-070AC36FDBE4-- From nobody Mon Dec 3 01:00:47 2018 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 D71C712777C for ; Mon, 3 Dec 2018 01:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=armh.onmicrosoft.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 qpD5HQnleHf0 for ; Mon, 3 Dec 2018 01:00:41 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60054.outbound.protection.outlook.com [40.107.6.54]) (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 C6727126C01 for ; Mon, 3 Dec 2018 01:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/GXrzI/5fEinPCKqYtv+HUnorkAqokFNVseOmO3WCg0=; b=RJHzqZiDv2S3ZM+bBG9MAK0XeTyBR94thCG7YXqFnPf0IT7ZAYPJKmc2idW7LB/VkJqoQLmrhp8Zvs1G+vdDA9EZONB7cJo5taqaKw+ux1/8Wk4TDF/tmLyVi1ILncQXcg5xkA3/wAqF06TFwhcfLJxb6qRC6/OSI+3dkzTLMsE= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1406.eurprd08.prod.outlook.com (10.167.198.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.21; Mon, 3 Dec 2018 09:00:36 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::2056:1db1:e01:4670]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::2056:1db1:e01:4670%3]) with mapi id 15.20.1382.020; Mon, 3 Dec 2018 09:00:36 +0000 From: Hannes Tschofenig To: Vittorio Bertocci , Torsten Lodderstedt CC: Daniel Fett , IETF oauth WG Thread-Topic: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit Thread-Index: AdR/8wsdlCSgLoNZTem+1MxrAorhbwHYZjwAAABEwfcABVOygAAAbOyYAAB2LIAAH9tBAAAIC/AAAEN4+4AADeWWQAAGeO2AAFRHGIAACcKN0A== Date: Mon, 3 Dec 2018 09:00:35 +0000 Message-ID: References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.19] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1406; 6:XaQNXXTrPJqHvanRdH/2W2dldSwaa4ZtPtWFIiTb9cJs3en9L5dmSHXGwoFqxXgogTtrMlS399YOtWMasmB1B499qrXVx2C2nV1wakhp1nEVHxfgkBkkjSZjf8EO64B1cIdkv5m3L9h/rpBFEu85bMowByngwkVAcj4A5cr1hzM24I3nZZIDmN/QrCgRYx5NITHWLWE3K/HRygOKppRulCNrlah3ZPCqOFyIlROMvTNyIk0sbooTWTxFbQv2hynOBEZ8qwhnWdRcMzFb4kGKXif1oCzkYAYXYlpxD3cdjE6w20C0zvkUqr1VLMRYpbn8WD6niDBxYmqvQcmc8nPa5xv3At8sRlFQVG/El3HnzylQXC7JPDfmhgvZ4zhUJwHpa0kPd2H+SvaLCn9HioIuDZLJWAKrJ8dt3f3kbQ7eB79uzql2n2nufbXwQKjJm4fvrZKeqzAQ/pGrwUxbByNfjw==; 5:jX0tCQ+oLKSDuA/+bqLuHUkQetFmPMoYxJjSrB8TJpCBfXAArkXdtEnTRwuxoz1f7MwEfWLc/Zrhq2pjiz9WNAvt9VlaHGkTFDtOldKOyleqf9W7UW9PeI7037mBi8D1iAJVwXyhU9t+SUxl9/gYlQ9gF5UkLGyPRqGCeA/DK6c=; 7:4NfP7dq2Xj1IcvATjLyid3u1ub2bqwdcC7YTTAyYKB3gSGf9t0Vcqj/HpRIqpml9TiroHUo3kwnug475CSW/6GCXyL2JItXdeJp4IDgOSUG4bzRCwYqnaRbgCc6m+ZE3zHqJj1KnkpRs7yJ/elgF6w== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 80f9bc85-6e67-4d5f-ac70-08d658fdca18 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1406; x-ms-traffictypediagnostic: VI1PR0801MB1406: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231455)(999002)(944501493)(52105112)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1406; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1406; x-forefront-prvs: 08756AC3C8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(39860400002)(136003)(396003)(199004)(365934003)(189003)(53754006)(40434004)(7110500001)(26005)(6436002)(71190400001)(71200400001)(53386004)(790700001)(6116002)(3846002)(45080400002)(110136005)(54906003)(72206003)(10710500007)(2906002)(33656002)(4744004)(6246003)(66574009)(316002)(6306002)(966005)(236005)(9686003)(55016002)(97736004)(229853002)(8936002)(25786009)(81156014)(8676002)(81166006)(53936002)(4326008)(93886005)(14454004)(68736007)(476003)(186003)(53546011)(6506007)(99286004)(54896002)(561944003)(66066001)(76176011)(478600001)(7696005)(15650500001)(2420400007)(102836004)(5660300001)(105586002)(486006)(74316002)(106356001)(256004)(5024004)(14444005)(7736002)(446003)(606006)(11346002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1406; H:VI1PR0801MB2112.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-microsoft-antispam-message-info: CbwUGESLY4PQFc96QsGW6dIJNe9KjsDvPMPWhyqKZEHJpPJaiVTHn5JKTD65ZMADyG4YKkfotBQh99DgkVVm1NHUTQeLcFZLfkeEOzPESMwNiGHJqIAdGrvaox8pvvIn+hZbL8dUJmzguzLO4ozBQ73yxRQwd5jOD3hDBxcrU8/KbczfsZe2ckmlXbnOLSXk/5FTDrnyD21oQWvDqT+/HE+qjo3ktRid7Wuf94kAmiaGRS0158DoHAfdTFgn59Xepa2YTMJCg2mX02f4V1NN1QN/8BF4Q8dfJcsC18YpGquCDszXpAdCXnUlzg71z4L0T++1PJSjqNPrV3mEBGAPpzapNuvAEGXsH8ydYRCnCuY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211236D26928008A9CF8038DFAAE0VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 80f9bc85-6e67-4d5f-ac70-08d658fdca18 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2018 09:00:35.8807 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1406 Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 03 Dec 2018 09:00:46 -0000 --_000_VI1PR0801MB211236D26928008A9CF8038DFAAE0VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KGNoYWlyIGhhdCBvZmYpDQoNCkkgYmVsaWV2ZSBtYW55IGluIHRoaXMgZ3JvdXAgaGFkIGNvbmNl cm5zIHdpdGggdGhlIGltcGxpY2l0IGdyYW50IGFscmVhZHkgZm9yIGEgbG9uZyB0aW1lIGJ1dCB0 aG91Z2h0IGl0IHdhcyBuZWNlc3NhcnkgZm9yIHVzZSB3aXRoIEphdmFTY3JpcHQtYmFzZWQgYXBw cyBpbiB0aGUgYnJvd3Nlci4gVHdvIHRoaW5ncyBoYXZlIGhhcHBlbmVkIGluIHRoZSBtZWFud2hp bGUNCg0KICAqICAgQXR0ZW1wdHMgdG8gc2VjdXJlIHRoZSBpbXBsaWNpdCBncmFudCwgZm9yIGV4 YW1wbGUgd2l0aCB0b2tlbiBiaW5kaW5nLCB3ZXJlbuKAmXQgc3VjY2Vzc2Z1bA0KICAqICAgQ09S UyBpcyB3aWRlbHkgZGVwbG95ZWQgbWFraW5nIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgdXNhZ2Ug cG9zc2libGUNCg0KU2luY2Ugd2UgYXJlIG5vdyB0cnlpbmcgdG8gbWFrZSByZWNvbW1lbmRhdGlv bnMgZm9yIE9BdXRoIDIuMCBzZWN1cml0eSBpbiB0aGUgZG9jdW1lbnQgVGhvcnN0ZW4gaXMgZWRp dGluZyB3ZSBvYnZpb3VzbHkgaGF2ZSB0byBtYWtlIGEgcmVjb21tZW5kYXRpb24uDQpBZGRpdGlv bmFsbHksIEFhcm9uIHN0YXJ0ZWQgPGRyYWZ0LXBhcmVja2ktb2F1dGgtYnJvd3Nlci1iYXNlZC1h cHBzPiwgd2hpY2ggaXMgYSBkb2N1bWVudCB3ZSBzaG91bGQgaGF2ZSBiZWVuIHdvcmtpbmcgb24g Zm9yIGFsb25nIHRpbWUgYWxyZWFkeS4NCg0KQ2lhbw0KSGFubmVzDQoNCkZyb206IFZpdHRvcmlv IEJlcnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+DQpTZW50OiBNb25kYXksIERl Y2VtYmVyIDMsIDIwMTggNToxNCBBTQ0KVG86IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5A bG9kZGVyc3RlZHQubmV0Pg0KQ2M6IERhbmllbCBGZXR0IDxmZXR0QGRhbmllbGZldHQuZGU+OyBI YW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT47IElFVEYgb2F1dGgg V0cgPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggU2VjdXJp dHkgVG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBs aWNpdA0KDQpIaSBhbGwsDQpTb3JyeSBmb3Igc3RlcHBpbmcgYSBiaXQgYmFjayBmcm9tIHRoZSBs ZXZlbCBvZiBkZXRhaWwgdGhlIGRpc2N1c3Npb24gYWxyZWFkeSByZWFjaGVkLiBJIGRvIGhhdmUg c29tZSBzcGVjaWZpYyBjb21tZW50cyBvbiB0aGUgZG9jdW1lbnQsIGJ1dCBiZWZvcmUgYnJpbmdp bmcgdGhvc2UgdXAgSSB3YW50ZWQgdG8gcmFpc2UgYSBnZW5lcmFsIHByb2JsZW0gSSBhbSBleHBl cmllbmNpbmcgd2l0aCB0aGlzIGluaXRpYXRpdmUuDQoNCkkgaGF2ZSBhIG51bWJlciBvZiBjdXN0 b21lcnMgdGhhdCBhcmUgcmVhY3RpbmcgdG8gdGhlIG5ld3Mgd2l0aCBkaXN0cmVzcy4gVGhlIGxh bmd1YWdlIHVzZWQgaW4gc29tZSBvZiB0aGUgY29tbXVuaWNhdGlvbnMgYXNzb2NpYXRlZCB3aXRo IHRoaXMgaW5pdGlhdGl2ZSBtYWRlIHRoZW0gZmVlbCBsaWtlIHNvbWUgbmV3IHZ1bG5lcmFiaWxp dHkgd2FzIGRpc2NvdmVyZWQsIGNhbGxpbmcgZm9yIGltbWVkaWF0ZSBhY3Rpb24uDQpUaGUgZmFj dCBpcyB0aGF0IGFzIGZhciBhcyBJIGNhbiB0ZWxsLCBubyBuZXcsIHByZXZpb3VzbHkgdW5rbm93 biBmYWN0IGluZm9ybWVkIHRoaXMgZGVjaXNpb246IG5vIG5ldyB2dWxuZXJhYmlsaXR5LCBub3Ig YW55IG5ldyB0ZWNobm9sb2d5IHRoYXQgd2FzbuKAmXQgYXZhaWxhYmxlIGJlZm9yZSAodGhlIHNl bmRlciBjb25zdHJhaW4gaXMgc3RpbGwgbm90IGFjdGlvbmFibGUgZm9yIG1vc3QgY3VzdG9tZXJz KS4gVGhlIHJpc2tzIG9mIHRoZSBpbXBsaWNpdCBmbG93IGFyZW7igJl0IGJpZ2dlciBub3cgdGhh biB0aGV5IHdlcmUgaW4gT2N0b2Jlci4NClRoYXQgZG9lc27igJl0IG1lYW4gdGhhdCB3ZSBjYW5u b3QgaW1wcm92ZSBndWlkYW5jZSwgb2YgY291cnNlLSBhbmQgbm93IGlzIGFzIGdvb2QgYXMgYW55 IG90aGVyIG1vbWVudCB0byBkbyBzbzogYnV0IGF0IHRoZSBzYW1lIHRpbWUsIEkgdGhpbmsgd2Ug bmVlZCB0byBiZSBjb2duaXphbnQgb2YgdGhlICppbW1lbnNlKiBpbnZlc3RtZW50IGluIGV4aXN0 ZW5jZSB0b2RheSBpbiBmb3JtIG9mIFNES3MgYW5kIGFwcGxpY2F0aW9ucyBidWlsdCBvbiB0aG9z ZSBTREtzIHRoYXQgYXJlIHByZWRpY2F0ZWQgb24gaW1wbGljaXQgZmxvdywgd2l0aCBvdXIgYmxl c3Npbmc6IHVudGlsIHZlcnkgcmVjZW50bHkgdGhlIG9mZmljaWFsIHBvc2l0aW9uIHdhcyDigJxp bXBsaWNpdCBpcyBiYWQgYnV0IGl04oCZcyB0aGUgYmVzdCB3ZSBoYXZlIG5vYXdhZGF5c+KAnS4N ClRvIG1lLCBiZWluZyBjb2duaXphbnQgb2YgdGhhdCBtZWFucyB0aGF0IHdlIHNob3VsZCBoZWxw IHBlb3BsZSB0byBmb3JtdWxhdGUgYWN0aW9uIHByb3BvcnRpb25hdGUgdG8gdGhlIHJpc2suIEFu ZCBpZiB1bnRpbCB5ZXN0ZXJkYXkgd2Ugd2VyZSBvayB3aXRoIHRoZW0gdXNpbmcgaW1wbGljaXQs IHdlIGNhbm5vdCByZWFsaXN0aWNhbGx5IGV4cGVjdCBhbnlvbmUgdG8gc3RhcnQgY2hhbmdpbmcg YWxsIG9mIHRoZWlyIGFwcHMgdG9kYXksIGJ1dCB0aGF04oCZcyB0aGUgbWVzc2FnZSBtYW55IGN1 c3RvbWVycyBhcmUgZ2V0dGluZy4NClRMO0RSLCBJIHRoaW5rIHRoZSBjb21tdW5pdHkgd291bGQg YmUgd2VsbCBzZXJ2ZWQgYnkgY2xhcmlmeWluZyBpbiB0aGUgc2VjdXJpdHkgZG9jdW1lbnQgdGhh dCB0aGVyZSBpcyBubyBuZXcgcmlzayBhbmQgdGhlaXIgZXhpc3RpbmcgY29kZWJhc2UgZGlkbuKA mXQgc3VkZGVubHkgYmVjb21lIGxlc3Mgc2VjdXJlIGFuZCBpbiAqdXJnZW50KiBuZWVkIHRvIHVw ZGF0ZS4NClRvIGF0dGVtcHQgYSBtZXRhcGhvci4gV2UgZGlzY292ZXJlZCBhIG5ldyBkcnVnIGFn YWluc3QgaGVhZGFjaGUgd2l0aCBtaWxkZXIgc2lkZSBlZmZlY3RzIHRoYW4gdGhlIG9uZSB3ZSB3 ZXJlIHByZXNjcmliaW5nIHRoZW0gdW50aWwgbm93LCBidXQgdGhhdCBkb2VzbuKAmXQgbWVhbiB0 aGF0IHRoZXkgc2hvdWxkIHRocm93IGF3YXkgYWxsIHRoZSBzdGFzaCB0aGV5IGhhdmUgb2YgdGhl IG9sZGVyIGRydWcuIFRoZSBvbGQgZHJ1ZyB3aWxsIGtlZXAgd29ya2luZyBhcyBpdCB3b3JrZWQg dW50aWwgbm93LiBPbmNlIHRoZXkgcnVuIG91dCBvZiB0aGVpciBzdGFzaCwgdGhleSBzaG91bGQg Z2V0IHRoZSBuZXcgb25lOyBvciBpZiB0aGUgb2xkIHNpZGUgZWZmZWN0cyB3ZXJlIHBhcnRpY3Vs YXJseSBiYWQgZm9yIHRoZW0sIHBlcmhhcHMgdGhleSBzaG91bGQgY29uc2lkZXIgc3dpdGNoaW5n IHRvZGF5LiBCdXQgdGhpcyBpc27igJl0IGEgcmVjYWxsLg0KDQpBbmQgaWYgaW4gZmFjdCB0aGlz IGdyb3VwIHRoaW5rcyBpdCBzaG91bGQgYmUgYSByZWNhbGwgYW5kIGdldCBldmVyeW9uZSBvZmYg dGhlIG9sZCBvbmUgcmlnaHQgbm93LCBJIHRoaW5rIHdl4oCZbGwgbmVlZCB0byBtYWtlIGEgbXVj aCBzdHJvbmdlciBjYXNlIHRoYW4gd2UgaGF2ZSBkb25lIHNvIGZhci4NCg0KVGhvdWdodHM/DQoN ClRoYW5rcw0KVi4NCg0KDQpPbiBTYXQsIERlYyAxLCAyMDE4IGF0IDA0OjAxIFRvcnN0ZW4gTG9k ZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldD4+IHdyb3RlOg0KSGkgSGFubmVzLA0KDQo+IEFtIDAxLjEyLjIwMTggdW0gMTA6MDYg c2NocmllYiBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTxtYWls dG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4+Og0KPg0KPiBJIGFncmVlIHdpdGggQWFyb24g aGVyZSBhbmQgSSB0aGluayBTZWN0aW9uIDMuOC4xLjIgb2YgZHJhZnQtaWV0Zi1vYXV0aC1zZWN1 cml0eS10b3BpY3MtMTAgIGFscmVhZHkgZG9lcyBhIHByZXR0eSBnb29kIGpvYi4NCg0KbXkgcHJv cG9zYWwgaXMgdG8gYWRkIHRoZSBmb2xsb3dpbmcgZGVmaW5pdGlvbiAoYmFzZWQgb24gMy44LjEu MikgdG8gYSBuZXcg4oCeVGVybWlub2xvZ3kiIHNlY3Rpb24gb3IgdG8gc2VjdGlvbiAyLjEuMjoN Cg0KQSBzZW5kZXIgY29uc3RyYWluZWQgYWNjZXNzIHRva2VuIHNjb3BlcyB0aGUgYXBwbGljYWJp bGl0eSBvZiBhbiBhY2Nlc3MgdG9rZW4gdG8gYSBjZXJ0YWluIHNlbmRlci4gIFRoaXMgc2VuZGVy IGlzDQpvYmxpZ2VkIHRvIGRlbW9uc3RyYXRlIGtub3dsZWRnZSBvZiBhIGNlcnRhaW4gc2VjcmV0 IGFzIHByZXJlcXVpc2l0ZSBmb3IgdGhlIGFjY2VwdGFuY2Ugb2YgdGhhdCB0b2tlbiBhdCB0aGUg cmVjaXBpZW50IChlLmcuIGEgcmVzb3VyY2Ugc2VydmVyKS4NCg0KPg0KPiBJIHdhcywgaG93ZXZl ciwgd29uZGVyaW5nIGFib3V0IHRoZSBzdWJ0bGUgaW1wbGljYXRpb24gb2YgdGhlIHJlcXVpcmVt ZW50IGZvciBzZW5kZXIgY29uc3RyYWluZWQgdG9rZW5zLiBNeSB1bmRlcnN0YW5kaW5nIG9mIHRo ZSB0b2tlbiBiaW5kaW5nIGRpc2N1c3Npb24sIHdoaWNoIGlzIG9uZSBvZiB0aGUgd2F5cyB0byBw cm92aWRlIHNlbmRlci1jb25zdHJhaW5lZCB0b2tlbnMsIGlzIHRoYXQgd2UgZG9u4oCZdCBoYXZl IGdvb2QgZmFpdGggaW4gc2VlaW5nIGRlcGxveW1lbnQgYW55dGltZSBzb29uLiBIZW5jZSwgd2Ug YXJlIGVzc2VudGlhbGx5IChyZWFkaW5nIGluIGJldHdlZW4gdGhlIGxpbmVzIG9mIFNlY3Rpb24g My44LjEuMikgc2F5aW5nIHRoYXQgeW91IGNhbm5vdCB1c2UgaW1wbGljaXQgZ3JhbnQgaW4gYSBw cmFjdGljYWwgc2V0dXAgZm9yIHRoZSB3ZWIqLg0KDQpUaGUgdGV4dCBzaGFsbCBjb252ZXkgdGhh dCBpbXBsaWNpdCBtdXN0IG5vdCBiZSB1c2VkIGF0IGFsbC4gVGhlIG1haW4gcmVhc29uIGJlaW5n IGl0IGlzIHVucHJvdGVjdGVkIGFnYWluc3QgdG9rZW4gaW5qZWN0aW9uIGFuZCBhZGRpdGlvbmFs bHkgYWxzbyBjYW5ub3Qgc2VuZGVyIGNvbnN0cmFpbiB0b2tlbnMuDQoNClRoZSBzZWNvbmQgcGFy dCBvZiB0aGUgc3RhdGVtZW50IHJlbGF0ZXMgdG8gb3RoZXIgcmVzcG9uc2UgdHlwZXMgYW5kIGNv bmRpdGlvbmFsbHkgb3BlbnMgdGhlIE1VU1QgTk9UIGluIGNhc2UgdGhleSBhcmUgcHJvdGVjdGVk IGFnYWluc3QgaW5qZWN0aW9uICh3aGljaCBpcyB0cnVlIGZvciB0aGUgbGlzdGVkIHJlc3BvbnNl IHR5cGVzKSBhbmQgY2FuIGlzc3VlIHNlbmRlciBjb25zdHJhaW5lZCB0b2tlbnMgKHdoaWNoIGRv ZXMgbm90IHdvcmsgdG9kYXkgYnV0IG1pZ2h0IHdvcmsgaW4gdGhlIGZ1dHVyZSkuDQoNCmtpbmQg cmVnYXJkcywNClRvcnN0ZW4uDQoNCj4NCj4gQW0gSSBtaXN1bmRlcnN0YW5kaW5nIGl0Pw0KDQo+ DQo+IENpYW8NCj4gSGFubmVzDQo+DQo+IFBTOiBUaGUgSW9UIGNhc2UgaXMgbGlrZWx5IGRpZmZl cmVudC4NCj4NCj4gRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgQWFyb24gUGFyZWNraQ0KPiBTZW50 OiBTYXR1cmRheSwgRGVjZW1iZXIgMSwgMjAxOCAzOjE4IEFNDQo+IFRvOiBUb3JzdGVuIExvZGRl cnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQ+Pg0KPiBDYzogRGFuaWVsIEZldHQgPGZldHRAZGFuaWVsZmV0dC5kZTxtYWlsdG86ZmV0 dEBkYW5pZWxmZXR0LmRlPj47IElFVEYgb2F1dGggV0cgPG9hdXRoQGlldGYub3JnPG1haWx0bzpv YXV0aEBpZXRmLm9yZz4+DQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIFNlY3VyaXR5 IFRvcGljcyAtLSBSZWNvbW1lbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2YgaW1wbGlj aXQNCj4NCj4gKzENCj4NCj4gSSB3b3VsZCBhbHNvIGxpa2UgdG8gZW5zdXJlIHRoZXJlIGlzIGEg Y2xlYXIgZGVmaW5pdGlvbiBvZiAic2VuZGVyIGNvbnN0cmFpbmVkIiB0b2tlbnMgaW4gdGhpcyBC Q1AuDQo+DQo+IEFhcm9uDQo+DQo+DQo+IE9uIFRodSwgTm92IDI5LCAyMDE4IGF0IDEwOjA2IEFN IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldD4+IHdyb3RlOg0KPiBIaSBhbGwsDQo+DQo+IGJhc2VkIG9uIHlv dXIgZmVlZGJhY2sgb24gdGhlIGxpc3QgYW5kIG9mZiBsaXN0LCBEYW5pZWwgYW5kIEkgcG9saXNo ZWQgdGhlIHRleHQuIFRoYXTigJlzIG91ciBwcm9wb3NhbDoNCj4NCj4g4oCUDQo+IEluIG9yZGVy IHRvIGF2b2lkIHRoZXNlIGlzc3VlcywgY2xpZW50cyBNVVNUIE5PVCB1c2UgdGhlIGltcGxpY2l0 DQo+IGdyYW50IChyZXNwb25zZSB0eXBlICJ0b2tlbiIpIG9yIGFueSBvdGhlciByZXNwb25zZSB0 eXBlIGlzc3VpbmcgYWNjZXNzDQo+IHRva2VucyBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25z ZSwgc3VjaCBhcyAidG9rZW4gaWRfdG9rZW4iIGFuZCAiY29kZSB0b2tlbiBpZF90b2tlbuKAnCwN Cj4gdW5sZXNzIHRoZSBpc3N1ZWQgYWNjZXNzIHRva2VucyBhcmUgc2VuZGVyLWNvbnN0cmFpbmVk IGFuZCBhY2Nlc3MgdG9rZW4gaW5qZWN0aW9uIGluDQo+IHRoZSBhdXRob3JpemF0aW9uIHJlc3Bv bnNlIGlzIHByZXZlbnRlZC4NCj4g4oCUDQo+DQo+IEV4cGxhbnRhdGlvbjoNCj4gLSB3ZSB3YW50 ZWQgdG8gaGF2ZSB0aGUgcmlnaHQgYmFsYW5jZSBiZXR3ZWVuIGEgZ2VuZXJpYyBkZWZpbml0aW9u IG9mIHRoZSByZXNwb25zZSB0eXBlcyB3ZSBkbyBub3QgcmVjb21tZW5kL2FsbG93IHRvIGJlIHVz ZWQgYW5kIGEgY29uY3JldGUvYWN0aW9uYWJsZSBsaXN0IG9mIHRoZSBhZmZlY3RlZCByZXNwb25z ZSB0eXBlcy4NCj4gLSB3ZSBjaGFuZ2VkIGZyb20gU0hPVUxEIE5PVCB0byBNVVNUIE5PVCBhcyBz dWdnZXN0ZWQgYnkgTmF0IGFuZCBzdXBwb3J0ZWQgYnkgV2lsbGlhbQ0KPg0KPiBXZSBsb29rIGZv cndhcmQgdG8gc2VlaW5nIHlvdXIgZmVlZGJhY2suDQo+DQo+IGtpbmQgcmVnYXJkcywNCj4gVG9y c3Rlbi4NCj4NCj4gPiBBbSAyOS4xMS4yMDE4IHVtIDE1OjE1IHNjaHJpZWIgSm9obiBCcmFkbGV5 IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PjoNCj4gPg0KPiA+ IEkgYW0gb2sgd2l0aCB0aGF0Lg0KPiA+DQo+ID4gT24gV2VkLCBOb3YgMjgsIDIwMTgsIDg6MDMg UE0gVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRv cnN0ZW5AbG9kZGVyc3RlZHQubmV0PiB3cm90ZToNCj4gPg0KPiA+ID4gQW0gMjguMTEuMjAxOCB1 bSAyMzo1MCBzY2hyaWViIG4tc2FraW11cmEgPG4tc2FraW11cmFAbnJpLmNvLmpwPG1haWx0bzpu LXNha2ltdXJhQG5yaS5jby5qcD4+Og0KPiA+ID4NCj4gPiA+IFRoYXQgd29ya3MuDQo+ID4NCj4g PiBHb29kIQ0KPiA+DQo+ID4gSSBqdXN0IHJlYWxpemVkIHRoaXMgdGV4dCBoYXMgYW4gaXNzdWUg d2l0aCDigJ50b2tlbuKAnCAob25seSkuIEl0IHdvdWxkIGFsbG93IOKAnnRva2Vu4oCcIHRvIGJl IHVzZWQgaWYgdGhlIHRva2VuIHdvdWxkIHNlbmRlciBjb25zdHJhaW5lZC4gVGhpcyBjb21wbGV0 ZWx5IGlnbm9yZXMgdGhlIGZhY3QgaW1wbGljaXQgYWxzbyBzaGFsbCBiZSBhYmFuZG9uZWQgYmVj YXVzZSBvZiBpdHMgdnVsbmVyYWJpbGl0eSBmb3IgYWNjZXNzIHRva2VuIGluamVjdGlvbi4NCj4g Pg0KPiA+IEkgdGhlcmVmb3JlIHByb3Bvc2UgYSBtb2RpZmllZCB0ZXh0Og0KPiA+DQo+ID4gICAg SW4gb3JkZXIgdG8gYXZvaWQgdGhlc2UgaXNzdWVzLCBDbGllbnRzIFNIT1VMRCBOT1QgdXNlIHRo ZSBpbXBsaWNpdA0KPiA+ICAgIGdyYW50LiBGdXJ0aGVybW9yZSwgY2xpZW50cyBTSE9VTEQgb25s eSB1c2Ugb3RoZXIgcmVzcG9uc2UgdHlwZXMgY2F1c2luZyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgdG8NCj4gPiAgICBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gaW4gdGhlIGF1dGhvcml6YXRpb24g cmVzcG9uc2UsIGlmIHRoZSBwYXJ0aWN1bGFyIHJlc3BvbnNlIHR5cGUgZGV0ZWN0cyBhY2Nlc3Mg dG9rZW4NCj4gPiAgICBpbmplY3Rpb24gYW5kIHRoZSBpc3N1ZWQgYWNjZXNzIHRva2VucyBhcmUg c2VuZGVyLWNvbnN0cmFpbmVkLg0KPiA+DQo+ID4gT3Igd2UganVzdCBzdGF0ZToNCj4gPg0KPiA+ ICAgSW4gb3JkZXIgdG8gYXZvaWQgdGhlc2UgaXNzdWVzLCBDbGllbnRzIFNIT1VMRCBOT1QgdXNl IHRoZSByZXNwb25zZSB0eXBlIOKAnnRva2VuIi4gVGhlIHJlc3BvbnNlIHR5cGVzDQo+ID4g4oCe dG9rZW4gaWRfdG9rZW7igJwgYW5kIOKAnmNvZGUgdG9rZW4gaWRfdG9rZW7igJwgU09VTEQgTk9U IGJlIHVzZWQsIGlmIHRoZSBpc3N1ZWQgYWNjZXNzIHRva2VucyBhcmUgbm90DQo+ID4gc2VuZGVy LWNvbnN0cmFpbmVkLg0KPiA+DQo+ID4gPg0KPiA+ID4gSW4gZmFjdCwgSSB3b3VsZCBmdXJ0aGVy IGdvIGFuZCBzYXkgTVVTVCBOT1QgYnV0IHRoYXQgcHJvYmFibHkgaXMgdG9vIG11Y2ggZm9yIGEg c2VjdXJpdHkgY29uc2lkZXJhdGlvbi4NCj4gPiA+DQo+ID4NCj4gPiBNaWtlIHN1Z2dlc3RlZCB0 byBnbyB3aXRoIGEgU0hPVUxEIE5PVCB0byBnZXQgdGhlIG1lc3NhZ2Ugb3V0IGJ1dCBnaXZlIGlt cGxlbWVudG9ycyB0aW1lIHRvIG1vdmUvY2hhbmdlLg0KPiA+DQo+ID4gPiBCZXN0LA0KPiA+ID4N Cj4gPiA+IE5hdA0KPiA+ID4NCj4gPiA+IE5hdCBTYWtpbXVyYSAvIG4tc2FraW11cmFAbnJpLmNv LmpwPG1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5qcD4gLyArODEtOTAtNjAxMy02Mjc2DQo+ID4g Pg0KPiA+ID4g44GT44Gu44Oh44O844Or44Gr44Gv44CB5pys5p2l44Gu5a6b5YWI44Gu5pa544Gu 44G/44Gr6ZmQ5a6a44GV44KM44Gf5qmf5a+G5oOF5aCx44GM5ZCr44G+44KM44Gm44GE44KL5aC0 5ZCI44GM44GU44GW44GE44G+44GZ44CC44GK5b+D44GC44Gf44KK44Gu44Gq44GE5aC05ZCI44Gv 44CB6Kqg44Gr55Sz44GX6Kiz44GU44GW44GE44G+44Gb44KT44GM44CB6YCB5L+h6ICF44G+44Gn 44GK55+l44KJ44Gb6aCC44GN44CB44G+44Gf5Y+X5L+h44GV44KM44Gf44Oh44O844Or44Gv5YmK 6Zmk44GX44Gm44GP44Gg44GV44GE44G+44GZ44KI44GG44GK6aGY44GE55Sz44GX5LiK44GS44G+ 44GZ44CCDQo+ID4gPg0KPiA+ID4gUExFQVNFIFJFQUQgOlRoaXMgZS1tYWlsIGlzIGNvbmZpZGVu dGlhbCBhbmQgaW50ZW5kZWQgZm9yIHRoZSBuYW1lZCByZWNpcGllbnQgb25seS4NCj4gPiA+IElm IHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBlLW1haWwuDQo+ID4gPg0KPiA+ID4g5beu5Ye65Lq6OiBUb3Jz dGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBs b2RkZXJzdGVkdC5uZXQ+Pg0KPiA+ID4g6YCB5L+h5pel5pmCOiDmsLTmm5zml6UsIDEx5pyIIDI4 LCAyMDE4IDExOjM4IOWNiOW+jA0KPiA+ID4g5a6b5YWIOiBuLXNha2ltdXJhDQo+ID4gPiBDYzog RGljayBIYXJkdDsgSGFubmVzIFRzY2hvZmVuaWc7IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0 aEBpZXRmLm9yZz4NCj4gPiA+IOS7tuWQjTogUmU6IFtPQVVUSC1XR10gT0F1dGggU2VjdXJpdHkg VG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNp dA0KPiA+ID4NCj4gPiA+IEhpIE5hdCwNCj4gPiA+DQo+ID4gPj4gQW0gMjguMTEuMjAxOCB1bSAy MToxMCBzY2hyaWViIG4tc2FraW11cmEgPG4tc2FraW11cmFAbnJpLmNvLmpwPG1haWx0bzpuLXNh a2ltdXJhQG5yaS5jby5qcD4+Og0KPiA+ID4+DQo+ID4gPj4gSSB3b3VsZCBzdXBwb3J0DQo+ID4g Pj4NCj4gPiA+PiAxKSBjbGVhcmx5IGRlZmluaW5nIEltcGxpY2l0IGFzIHRoZSBmbG93IHRoYXQg cmV0dXJucyBhY2Nlc3MgdG9rZW4gZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCAoIHNv bWUgcGVvcGxlIGNvbmZ1c2VzIGltcGxpY2l0IGFzIHRoZSBmbG93IHRoYXQgcmV0dXJucyBJRCBU b2tlbiBpbiB0aGUgZnJvbnQgY2hhbm5lbCkNCj4gPiA+DQo+ID4gPiBUaGF04oCZcyB0aGUgY3Vy cmVudCB0ZXh0Og0KPiA+ID4NCj4gPiA+IEluIG9yZGVyIHRvIGF2b2lkIHRoZXNlIGlzc3Vlcywg Q2xpZW50cyBTSE9VTEQgTk9UIHVzZSB0aGUgaW1wbGljaXQNCj4gPiA+ICAgIGdyYW50IG9yIGFu eSBvdGhlciByZXNwb25zZSB0eXBlIGNhdXNpbmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRv DQo+ID4gPiAgICBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gaW4gdGhlIGF1dGhvcml6YXRpb24gcmVz cG9uc2UuDQo+ID4gPg0KPiA+ID4gV2hhdCB3b3VsZCB5b3UgbGlrZSB0byBtb2RpZnk/DQo+ID4g Pg0KPiA+ID4+DQo+ID4gPj4gMikgQmFubmluZyB0aGUgcmV0dXJuaW5nIG9mIHRoZSBhY2Nlc3Mg dG9rZW4gdGhhdCBhcmUgbm90IHNlbmRlciBjb25zdHJhaW5lZCBmcm9tIHRoZSBhdXRob3JpemF0 aW9uIGVuZHBvaW50DQo+ID4gPg0KPiA+ID4gSW4gb3JkZXIgdG8gYXZvaWQgdGhlc2UgaXNzdWVz LCBDbGllbnRzIFNIT1VMRCBOT1QgdXNlIHRoZSBpbXBsaWNpdA0KPiA+ID4gICAgZ3JhbnQgb3Ig YW55IG90aGVyIHJlc3BvbnNlIHR5cGUgY2F1c2luZyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg dG8NCj4gPiA+ICAgIGlzc3VlIGFuIGFjY2VzcyB0b2tlbiBpbiB0aGUgYXV0aG9yaXphdGlvbiBy ZXNwb25zZSwgaWYgdGhpcyBhY2Nlc3MgdG9rZW5zIGlzIG5vdCBzZW5kZXItY29uc3RyYWludC4N Cj4gPiA+DQo+ID4gPiBXaGF0IGFib3V0IHRoaXM/DQo+ID4gPg0KPiA+ID4ga2luZCByZWdhcmRz LA0KPiA+ID4gVG9yc3Rlbi4NCj4gPiA+DQo+ID4gPj4NCj4gPiA+PiBCZXN0LA0KPiA+ID4+DQo+ ID4gPj4gTmF0DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+IE91dGxvb2sgZm9yIGlPUyDjgpLlhaXm iYsNCj4gPiA+Pg0KPiA+ID4+IOW3ruWHuuS6ujogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiAoRGljayBIYXJkdCA8ZGljay5oYXJk dEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4g44Gu5Luj55CGKQ0KPiA+ ID4+IOmAgeS/oeaXpeaZgjog5rC05puc5pelLCAxMeaciCAyOCwgMjAxOCA4OjU4IOWNiOW+jA0K PiA+ID4+IOWum+WFiDogSGFubmVzIFRzY2hvZmVuaWcNCj4gPiA+PiBDYzogb2F1dGhAaWV0Zi5v cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KPiA+ID4+IOS7tuWQjTogUmU6IFtPQVVUSC1XR10g T0F1dGggU2VjdXJpdHkgVG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5z dGVhZCBvZiBpbXBsaWNpdA0KPiA+ID4+DQo+ID4gPj4gKzENCj4gPiA+Pg0KPiA+ID4+IFdoaWxl IHRoZXJlIGFyZSB2YXJpb3VzIG1lY2hhbmlzbXMgdG8gYWxsZXZpYXRlIHNvbWUgb2YgdGhlIGlz c3VlcyBvZiBpbXBsaWNpdCwgSSBkb24ndCB0aGluayB3ZSBjYW4gcmVjb21tZW5kIHNwZWNpZmlj cywgYW5kIHRoZXJlIG1heSBiZSBmdXR1cmUgb25lcyBpbiB0aGUgZnV0dXJlLiBJIHRoaW5rIHdl IGFsbCBhZ3JlZSB0aGF0IGltcGxpY2l0IHdpdGhvdXQgYW55IG1pdGlnYXRpb24gaXMgcHJvYmxl bWF0aWMuDQo+ID4gPj4NCj4gPiA+PiBIb3cgYWJvdXQgd2UgcmVjb21tZW5kIGFnYWluc3QgdXNp bmcgaW1wbGljaXQgYWxvbmU/DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+IE9uIE1vbiwgTm92IDE5 LCAyMDE4IGF0IDI6MzQgQU0gSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFy bS5jb208bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+PiB3cm90ZToNCj4gPiA+PiBI aSBhbGwsDQo+ID4gPj4NCj4gPiA+PiBUaGUgYXV0aG9ycyBvZiB0aGUgT0F1dGggU2VjdXJpdHkg VG9waWNzIGRyYWZ0IGNhbWUgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCBpdCBpcyBub3QgcG9zc2li bGUgdG8gYWRlcXVhdGVseSBzZWN1cmUgdGhlIGltcGxpY2l0IGZsb3cgYWdhaW5zdCB0b2tlbiBp bmplY3Rpb24gc2luY2UgcG90ZW50aWFsIHNvbHV0aW9ucyBsaWtlIHRva2VuIGJpbmRpbmcgb3Ig SkFSTSBhcmUgaW4gYW4gZWFybHkgc3RhZ2Ugb2YgYWRvcHRpb24uIEZvciB0aGlzIHJlYXNvbiwg YW5kIHNpbmNlIENPUlMgYWxsb3dzIGJyb3dzZXItYmFzZWQgYXBwcyB0byBzZW5kIHJlcXVlc3Rz IHRvIHRoZSB0b2tlbiBlbmRwb2ludCwgVG9yc3RlbiBzdWdnZXN0ZWQgdG8gdXNlIHRoZSBhdXRo b3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiB0aGUgaW1wbGljaXQgZ3JhbnQgaW4gY2FsbCBjYXNl cyBpbiBoaXMgcHJlc2VudGF0aW9uIChzZWUgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9t ZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEwMy1vYXV0aC1zZXNzYi1kcmFmdC1pZXRmLW9h dXRoLXNlY3VyaXR5LXRvcGljcy0wMSkuDQo+ID4gPj4NCj4gPiA+PiBBIGh1bSBpbiB0aGUgcm9v bSBhdCBJRVRGIzEwMyBjb25jbHVkZWQgc3Ryb25nIHN1cHBvcnQgZm9yIGhpcyByZWNvbW1lbmRh dGlvbnMuIFdlIHdvdWxkIGxpa2UgdG8gY29uZmlybSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlz dC4NCj4gPiA+Pg0KPiA+ID4+IFBsZWFzZSBwcm92aWRlIGEgcmVzcG9uc2UgYnkgRGVjZW1iZXIg M3JkLg0KPiA+ID4+DQo+ID4gPj4gQ2lhbw0KPiA+ID4+DQo+ID4gPj4gSGFubmVzICYgUmlmYWF0 DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNv bnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5v dCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBh bnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1 bS4gVGhhbmsgeW91Lg0KPiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gPj4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gPj4gT0F1dGhAaWV0 Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiA+ID4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+ID4+ IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gPiA+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4gPg0KPiA+DQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBPQXV0aCBtYWls aW5nIGxpc3QNCj4gPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+ID4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5n IGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+IC0tDQo+IC0tLS0NCj4gQWFy b24gUGFyZWNraQ0KPiBhYXJvbnBhcmVja2kuY29tPGh0dHA6Ly9hYXJvbnBhcmVja2kuY29tPg0K PiBAYWFyb25waw0KPg0KPiBJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBl bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJl IHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBz dG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBt YWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCklNUE9SVEFOVCBOT1RJQ0U6 IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZp ZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBp dCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFu eSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_VI1PR0801MB211236D26928008A9CF8038DFAAE0VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFn cmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1h cmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJ bWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAs IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHls ZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0 IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3NjkwODEzNjM7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xODEyMTQ5NTAyIC0z NDAzNzcwNjAgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1 NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1Nzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpEZW5nWGlhbjsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo4ODYwNzEyNjY7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE5MzUwMTkwNjYgLTM0MDM3 NzA2MCAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEz NDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2 ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206 MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4oY2hhaXIgaGF0IG9mZik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZlIG1hbnkg aW4gdGhpcyBncm91cCBoYWQgY29uY2VybnMgd2l0aCB0aGUgaW1wbGljaXQgZ3JhbnQgYWxyZWFk eSBmb3IgYSBsb25nIHRpbWUgYnV0IHRob3VnaHQgaXQgd2FzIG5lY2Vzc2FyeSBmb3IgdXNlIHdp dGggSmF2YVNjcmlwdC1iYXNlZCBhcHBzIGluIHRoZSBicm93c2VyLiBUd28gdGhpbmdzIGhhdmUg aGFwcGVuZWQgaW4gdGhlIG1lYW53aGlsZTxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJn aW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPkF0dGVtcHRzIHRv IHNlY3VyZSB0aGUgaW1wbGljaXQgZ3JhbnQsIGZvciBleGFtcGxlIHdpdGggdG9rZW4gYmluZGlu Zywgd2VyZW7igJl0IHN1Y2Nlc3NmdWw8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8y Ij5DT1JTIGlzIHdpZGVseSBkZXBsb3llZCBtYWtpbmcgdGhlIGF1dGhvcml6YXRpb24gY29kZSB1 c2FnZSBwb3NzaWJsZQ0KPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbmNlIHdlIGFy ZSBub3cgdHJ5aW5nIHRvIG1ha2UgcmVjb21tZW5kYXRpb25zIGZvciBPQXV0aCAyLjAgc2VjdXJp dHkgaW4gdGhlIGRvY3VtZW50IFRob3JzdGVuIGlzIGVkaXRpbmcgd2Ugb2J2aW91c2x5IGhhdmUg dG8gbWFrZSBhIHJlY29tbWVuZGF0aW9uLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BZGRpdGlvbmFsbHksIEFhcm9uIHN0YXJ0ZWQgJmx0O2RyYWZ0LXBhcmVja2ktb2F1 dGgtYnJvd3Nlci1iYXNlZC1hcHBzJmd0Oywgd2hpY2ggaXMgYSBkb2N1bWVudCB3ZSBzaG91bGQg aGF2ZSBiZWVuIHdvcmtpbmcgb24gZm9yIGFsb25nIHRpbWUgYWxyZWFkeS4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5DaWFvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I YW5uZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFZpdHRvcmlvIEJlcnRvY2NpICZsdDt2aXR0 b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBE ZWNlbWJlciAzLCAyMDE4IDU6MTQgQU08YnI+DQo8Yj5Ubzo8L2I+IFRvcnN0ZW4gTG9kZGVyc3Rl ZHQgJmx0O3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gRGFuaWVs IEZldHQgJmx0O2ZldHRAZGFuaWVsZmV0dC5kZSZndDs7IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDtI YW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tJmd0OzsgSUVURiBvYXV0aCBXRyAmbHQ7b2F1dGhAaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIFNlY3Vy aXR5IFRvcGljcyAtLSBSZWNvbW1lbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2YgaW1w bGljaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgYWxs LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Tb3JyeSBmb3Igc3RlcHBpbmcgYSBiaXQgYmFjayBmcm9tIHRoZSBsZXZlbCBvZiBkZXRh aWwgdGhlIGRpc2N1c3Npb24gYWxyZWFkeSByZWFjaGVkLiBJIGRvIGhhdmUgc29tZSBzcGVjaWZp YyBjb21tZW50cyBvbiB0aGUgZG9jdW1lbnQsIGJ1dCBiZWZvcmUgYnJpbmdpbmcgdGhvc2UgdXAg SSB3YW50ZWQgdG8gcmFpc2UgYSBnZW5lcmFsIHByb2JsZW0gSSBhbSBleHBlcmllbmNpbmcgd2l0 aCB0aGlzIGluaXRpYXRpdmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBhIG51bWJlciBvZiBjdXN0b21lcnMgdGhhdCBhcmUgcmVh Y3RpbmcgdG8gdGhlIG5ld3Mgd2l0aCBkaXN0cmVzcy4gVGhlIGxhbmd1YWdlIHVzZWQgaW4gc29t ZSBvZiB0aGUgY29tbXVuaWNhdGlvbnMgYXNzb2NpYXRlZCB3aXRoIHRoaXMgaW5pdGlhdGl2ZSBt YWRlIHRoZW0gZmVlbCBsaWtlIHNvbWUgbmV3IHZ1bG5lcmFiaWxpdHkgd2FzIGRpc2NvdmVyZWQs IGNhbGxpbmcgZm9yIGltbWVkaWF0ZSBhY3Rpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZmFjdCBpcyB0aGF0IGFzIGZhciBhcyBJIGNh biB0ZWxsLCBubyBuZXcsIHByZXZpb3VzbHkgdW5rbm93biBmYWN0IGluZm9ybWVkIHRoaXMgZGVj aXNpb246IG5vIG5ldyB2dWxuZXJhYmlsaXR5LCBub3IgYW55IG5ldyB0ZWNobm9sb2d5IHRoYXQg d2FzbuKAmXQgYXZhaWxhYmxlIGJlZm9yZSAodGhlIHNlbmRlciBjb25zdHJhaW4gaXMgc3RpbGwg bm90IGFjdGlvbmFibGUgZm9yIG1vc3QgY3VzdG9tZXJzKS4NCiBUaGUgcmlza3Mgb2YgdGhlIGlt cGxpY2l0IGZsb3cgYXJlbuKAmXQgYmlnZ2VyIG5vdyB0aGFuIHRoZXkgd2VyZSBpbiBPY3RvYmVy LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhh dCBkb2VzbuKAmXQgbWVhbiB0aGF0IHdlIGNhbm5vdCBpbXByb3ZlIGd1aWRhbmNlLCBvZiBjb3Vy c2UtIGFuZCBub3cgaXMgYXMgZ29vZCBhcyBhbnkgb3RoZXIgbW9tZW50IHRvIGRvIHNvOiBidXQg YXQgdGhlIHNhbWUgdGltZSwgSSB0aGluayB3ZSBuZWVkIHRvIGJlIGNvZ25pemFudCBvZiB0aGUg KmltbWVuc2UqIGludmVzdG1lbnQgaW4gZXhpc3RlbmNlIHRvZGF5IGluIGZvcm0gb2YgU0RLcyBh bmQgYXBwbGljYXRpb25zDQogYnVpbHQgb24gdGhvc2UgU0RLcyB0aGF0IGFyZSBwcmVkaWNhdGVk IG9uIGltcGxpY2l0IGZsb3csIHdpdGggb3VyIGJsZXNzaW5nOiB1bnRpbCB2ZXJ5IHJlY2VudGx5 IHRoZSBvZmZpY2lhbCBwb3NpdGlvbiB3YXMg4oCcaW1wbGljaXQgaXMgYmFkIGJ1dCBpdOKAmXMg dGhlIGJlc3Qgd2UgaGF2ZSBub2F3YWRheXPigJ0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBtZSwgYmVpbmcgY29nbml6YW50IG9mIHRoYXQg bWVhbnMgdGhhdCB3ZSBzaG91bGQgaGVscCBwZW9wbGUgdG8gZm9ybXVsYXRlIGFjdGlvbiBwcm9w b3J0aW9uYXRlIHRvIHRoZSByaXNrLiBBbmQgaWYgdW50aWwgeWVzdGVyZGF5IHdlIHdlcmUgb2sg d2l0aCB0aGVtIHVzaW5nIGltcGxpY2l0LCB3ZSBjYW5ub3QgcmVhbGlzdGljYWxseSBleHBlY3Qg YW55b25lIHRvIHN0YXJ0IGNoYW5naW5nIGFsbCBvZiB0aGVpcg0KIGFwcHMgdG9kYXksIGJ1dCB0 aGF04oCZcyB0aGUgbWVzc2FnZSBtYW55IGN1c3RvbWVycyBhcmUgZ2V0dGluZy4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRMO0RSLCBJ IHRoaW5rIHRoZSBjb21tdW5pdHkgd291bGQgYmUgd2VsbCBzZXJ2ZWQgYnkgY2xhcmlmeWluZyBp biB0aGUgc2VjdXJpdHkgZG9jdW1lbnQgdGhhdCB0aGVyZSBpcyBubyBuZXcgcmlzayBhbmQgdGhl aXIgZXhpc3RpbmcgY29kZWJhc2UgZGlkbuKAmXQgc3VkZGVubHkgYmVjb21lIGxlc3Mgc2VjdXJl IGFuZCBpbiAqdXJnZW50KiBuZWVkIHRvIHVwZGF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIGF0dGVtcHQgYSBtZXRhcGhvci4gV2UgZGlz Y292ZXJlZCBhIG5ldyBkcnVnIGFnYWluc3QgaGVhZGFjaGUgd2l0aCBtaWxkZXIgc2lkZSBlZmZl Y3RzIHRoYW4gdGhlIG9uZSB3ZSB3ZXJlIHByZXNjcmliaW5nIHRoZW0gdW50aWwgbm93LCBidXQg dGhhdCBkb2VzbuKAmXQgbWVhbiB0aGF0IHRoZXkgc2hvdWxkIHRocm93IGF3YXkgYWxsIHRoZSBz dGFzaCB0aGV5IGhhdmUgb2YgdGhlIG9sZGVyIGRydWcuIFRoZQ0KIG9sZCBkcnVnIHdpbGwga2Vl cCB3b3JraW5nIGFzIGl0IHdvcmtlZCB1bnRpbCBub3cuIE9uY2UgdGhleSBydW4gb3V0IG9mIHRo ZWlyIHN0YXNoLCB0aGV5IHNob3VsZCBnZXQgdGhlIG5ldyBvbmU7IG9yIGlmIHRoZSBvbGQgc2lk ZSBlZmZlY3RzIHdlcmUgcGFydGljdWxhcmx5IGJhZCBmb3IgdGhlbSwgcGVyaGFwcyB0aGV5IHNo b3VsZCBjb25zaWRlciBzd2l0Y2hpbmcgdG9kYXkuIEJ1dCB0aGlzIGlzbuKAmXQgYSByZWNhbGwu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFuZCBpZiBpbiBmYWN0IHRoaXMgZ3JvdXAgdGhpbmtzIGl0IHNob3VsZCBiZSBhIHJlY2Fs bCBhbmQgZ2V0IGV2ZXJ5b25lIG9mZiB0aGUgb2xkIG9uZSByaWdodCBub3csIEkgdGhpbmsgd2Xi gJlsbCBuZWVkIHRvIG1ha2UgYSBtdWNoIHN0cm9uZ2VyIGNhc2UgdGhhbiB3ZSBoYXZlIGRvbmUg c28gZmFyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaG91Z2h0cz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5WLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gU2F0LCBEZWMgMSwgMjAxOCBhdCAwNDowMSBUb3JzdGVuIExvZGRl cnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiPnRvcnN0 ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBIYW5uZXMsPGJyPg0KPGJyPg0K Jmd0OyBBbSAwMS4xMi4yMDE4IHVtIDEwOjA2IHNjaHJpZWIgSGFubmVzIFRzY2hvZmVuaWcgJmx0 OzxhIGhyZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tIiB0YXJnZXQ9Il9ibGFu ayI+SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsgPGJyPg0KJmd0 OyBJIGFncmVlIHdpdGggQWFyb24gaGVyZSBhbmQgSSB0aGluayBTZWN0aW9uIDMuOC4xLjIgb2Yg ZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTAmbmJzcDsgYWxyZWFkeSBkb2VzIGEg cHJldHR5IGdvb2Qgam9iLg0KPGJyPg0KPGJyPg0KbXkgcHJvcG9zYWwgaXMgdG8gYWRkIHRoZSBm b2xsb3dpbmcgZGVmaW5pdGlvbiAoYmFzZWQgb24gMy44LjEuMikgdG8gYSBuZXcg4oCeVGVybWlu b2xvZ3kmcXVvdDsgc2VjdGlvbiBvciB0byBzZWN0aW9uIDIuMS4yOjxicj4NCjxicj4NCkEgc2Vu ZGVyIGNvbnN0cmFpbmVkIGFjY2VzcyB0b2tlbiBzY29wZXMgdGhlIGFwcGxpY2FiaWxpdHkgb2Yg YW4gYWNjZXNzIHRva2VuIHRvIGEgY2VydGFpbiBzZW5kZXIuJm5ic3A7IFRoaXMgc2VuZGVyIGlz PGJyPg0Kb2JsaWdlZCB0byBkZW1vbnN0cmF0ZSBrbm93bGVkZ2Ugb2YgYSBjZXJ0YWluIHNlY3Jl dCBhcyBwcmVyZXF1aXNpdGUgZm9yIHRoZSBhY2NlcHRhbmNlIG9mIHRoYXQgdG9rZW4gYXQgdGhl IHJlY2lwaWVudCAoZS5nLiBhIHJlc291cmNlIHNlcnZlcikuPGJyPg0KPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IEkgd2FzLCBob3dldmVyLCB3b25kZXJpbmcgYWJvdXQgdGhlIHN1YnRsZSBpbXBsaWNh dGlvbiBvZiB0aGUgcmVxdWlyZW1lbnQgZm9yIHNlbmRlciBjb25zdHJhaW5lZCB0b2tlbnMuIE15 IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHRva2VuIGJpbmRpbmcgZGlzY3Vzc2lvbiwgd2hpY2ggaXMg b25lIG9mIHRoZSB3YXlzIHRvIHByb3ZpZGUgc2VuZGVyLWNvbnN0cmFpbmVkIHRva2VucywgaXMg dGhhdCB3ZSBkb27igJl0IGhhdmUgZ29vZCBmYWl0aCBpbiBzZWVpbmcNCiBkZXBsb3ltZW50IGFu eXRpbWUgc29vbi4gSGVuY2UsIHdlIGFyZSBlc3NlbnRpYWxseSAocmVhZGluZyBpbiBiZXR3ZWVu IHRoZSBsaW5lcyBvZiBTZWN0aW9uIDMuOC4xLjIpIHNheWluZyB0aGF0IHlvdSBjYW5ub3QgdXNl IGltcGxpY2l0IGdyYW50IGluIGEgcHJhY3RpY2FsIHNldHVwIGZvciB0aGUgd2ViKi48YnI+DQo8 YnI+DQpUaGUgdGV4dCBzaGFsbCBjb252ZXkgdGhhdCBpbXBsaWNpdCBtdXN0IG5vdCBiZSB1c2Vk IGF0IGFsbC4gVGhlIG1haW4gcmVhc29uIGJlaW5nIGl0IGlzIHVucHJvdGVjdGVkIGFnYWluc3Qg dG9rZW4gaW5qZWN0aW9uIGFuZCBhZGRpdGlvbmFsbHkgYWxzbyBjYW5ub3Qgc2VuZGVyIGNvbnN0 cmFpbiB0b2tlbnMuDQo8YnI+DQo8YnI+DQpUaGUgc2Vjb25kIHBhcnQgb2YgdGhlIHN0YXRlbWVu dCByZWxhdGVzIHRvIG90aGVyIHJlc3BvbnNlIHR5cGVzIGFuZCBjb25kaXRpb25hbGx5IG9wZW5z IHRoZSBNVVNUIE5PVCBpbiBjYXNlIHRoZXkgYXJlIHByb3RlY3RlZCBhZ2FpbnN0IGluamVjdGlv biAod2hpY2ggaXMgdHJ1ZSBmb3IgdGhlIGxpc3RlZCByZXNwb25zZSB0eXBlcykgYW5kIGNhbiBp c3N1ZSBzZW5kZXIgY29uc3RyYWluZWQgdG9rZW5zICh3aGljaCBkb2VzIG5vdCB3b3JrIHRvZGF5 DQogYnV0IG1pZ2h0IHdvcmsgaW4gdGhlIGZ1dHVyZSkuIDxicj4NCjxicj4NCmtpbmQgcmVnYXJk cyw8YnI+DQpUb3JzdGVuLiA8YnI+DQo8YnI+DQomZ3Q7Jm5ic3A7IDxicj4NCiZndDsgQW0gSSBt aXN1bmRlcnN0YW5kaW5nIGl0Pzxicj4NCjxicj4NCiZndDsmbmJzcDsgPGJyPg0KJmd0OyBDaWFv PGJyPg0KJmd0OyBIYW5uZXM8YnI+DQomZ3Q7Jm5ic3A7IDxicj4NCiZndDsgUFM6IFRoZSBJb1Qg Y2FzZSBpcyBsaWtlbHkgZGlmZmVyZW50LiA8YnI+DQomZ3Q7Jm5ic3A7IDxicj4NCiZndDsgRnJv bTogT0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZiBB YXJvbiBQYXJlY2tpPGJyPg0KJmd0OyBTZW50OiBTYXR1cmRheSwgRGVjZW1iZXIgMSwgMjAxOCAz OjE4IEFNPGJyPg0KJmd0OyBUbzogVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0ibWFp bHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9yc3RlbkBsb2Rk ZXJzdGVkdC5uZXQ8L2E+Jmd0Ozxicj4NCiZndDsgQ2M6IERhbmllbCBGZXR0ICZsdDs8YSBocmVm PSJtYWlsdG86ZmV0dEBkYW5pZWxmZXR0LmRlIiB0YXJnZXQ9Il9ibGFuayI+ZmV0dEBkYW5pZWxm ZXR0LmRlPC9hPiZndDs7IElFVEYgb2F1dGggV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7 IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIFNlY3VyaXR5IFRvcGljcyAtLSBSZWNvbW1l bmQgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2YgaW1wbGljaXQ8YnI+DQomZ3Q7Jm5ic3A7 IDxicj4NCiZndDsgJiM0MzsxPGJyPg0KJmd0OyZuYnNwOyA8YnI+DQomZ3Q7IEkgd291bGQgYWxz byBsaWtlIHRvIGVuc3VyZSB0aGVyZSBpcyBhIGNsZWFyIGRlZmluaXRpb24gb2YgJnF1b3Q7c2Vu ZGVyIGNvbnN0cmFpbmVkJnF1b3Q7IHRva2VucyBpbiB0aGlzIEJDUC48YnI+DQomZ3Q7Jm5ic3A7 IDxicj4NCiZndDsgQWFyb248YnI+DQomZ3Q7Jm5ic3A7IDxicj4NCiZndDsmbmJzcDsgPGJyPg0K Jmd0OyBPbiBUaHUsIE5vdiAyOSwgMjAxOCBhdCAxMDowNiBBTSBUb3JzdGVuIExvZGRlcnN0ZWR0 ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdldD0iX2Js YW5rIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgSGkg YWxsLCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgYmFzZWQgb24geW91ciBmZWVkYmFjayBvbiB0aGUg bGlzdCBhbmQgb2ZmIGxpc3QsIERhbmllbCBhbmQgSSBwb2xpc2hlZCB0aGUgdGV4dC4gVGhhdOKA mXMgb3VyIHByb3Bvc2FsOjxicj4NCiZndDsgPGJyPg0KJmd0OyDigJQ8YnI+DQomZ3Q7IEluIG9y ZGVyIHRvIGF2b2lkIHRoZXNlIGlzc3VlcywgY2xpZW50cyBNVVNUIE5PVCB1c2UgdGhlIGltcGxp Y2l0PGJyPg0KJmd0OyBncmFudCAocmVzcG9uc2UgdHlwZSAmcXVvdDt0b2tlbiZxdW90Oykgb3Ig YW55IG90aGVyIHJlc3BvbnNlIHR5cGUgaXNzdWluZyBhY2Nlc3MgPGJyPg0KJmd0OyB0b2tlbnMg aW4gdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHN1Y2ggYXMgJnF1b3Q7dG9rZW4gaWRfdG9r ZW4mcXVvdDsgYW5kICZxdW90O2NvZGUgdG9rZW4gaWRfdG9rZW7igJwsDQo8YnI+DQomZ3Q7IHVu bGVzcyB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbnMgYXJlIHNlbmRlci1jb25zdHJhaW5lZCBhbmQg YWNjZXNzIHRva2VuIGluamVjdGlvbiBpbg0KPGJyPg0KJmd0OyB0aGUgYXV0aG9yaXphdGlvbiBy ZXNwb25zZSBpcyBwcmV2ZW50ZWQuIDxicj4NCiZndDsg4oCUPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEV4cGxhbnRhdGlvbjogPGJyPg0KJmd0OyAtIHdlIHdhbnRlZCB0byBoYXZlIHRoZSByaWdodCBi YWxhbmNlIGJldHdlZW4gYSBnZW5lcmljIGRlZmluaXRpb24gb2YgdGhlIHJlc3BvbnNlIHR5cGVz IHdlIGRvIG5vdCByZWNvbW1lbmQvYWxsb3cgdG8gYmUgdXNlZCBhbmQgYSBjb25jcmV0ZS9hY3Rp b25hYmxlIGxpc3Qgb2YgdGhlIGFmZmVjdGVkIHJlc3BvbnNlIHR5cGVzLg0KPGJyPg0KJmd0OyAt IHdlIGNoYW5nZWQgZnJvbSBTSE9VTEQgTk9UIHRvIE1VU1QgTk9UIGFzIHN1Z2dlc3RlZCBieSBO YXQgYW5kIHN1cHBvcnRlZCBieSBXaWxsaWFtPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdlIGxvb2sg Zm9yd2FyZCB0byBzZWVpbmcgeW91ciBmZWVkYmFjay48YnI+DQomZ3Q7IDxicj4NCiZndDsga2lu ZCByZWdhcmRzLDxicj4NCiZndDsgVG9yc3Rlbi4mbmJzcDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 ICZndDsgQW0gMjkuMTEuMjAxOCB1bSAxNToxNSBzY2hyaWViIEpvaG4gQnJhZGxleSAmbHQ7PGEg aHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZl N2p0Yi5jb208L2E+Jmd0Ozo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgYW0gb2sg d2l0aCB0aGF0LiZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE9uIFdlZCwg Tm92IDI4LCAyMDE4LCA4OjAzIFBNIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9Im1h aWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0PC9hPiB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgQW0gMjguMTEuMjAxOCB1bSAyMzo1MCBzY2hyaWViIG4tc2FraW11cmEgJmx0OzxhIGhyZWY9 Im1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5qcCIgdGFyZ2V0PSJfYmxhbmsiPm4tc2FraW11cmFA bnJpLmNvLmpwPC9hPiZndDs6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgVGhhdCB3b3Jrcy48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEdvb2QhPGJyPg0K Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJIGp1c3QgcmVhbGl6ZWQgdGhpcyB0ZXh0IGhhcyBh biBpc3N1ZSB3aXRoIOKAnnRva2Vu4oCcIChvbmx5KS4gSXQgd291bGQgYWxsb3cg4oCedG9rZW7i gJwgdG8gYmUgdXNlZCBpZiB0aGUgdG9rZW4gd291bGQgc2VuZGVyIGNvbnN0cmFpbmVkLiBUaGlz IGNvbXBsZXRlbHkgaWdub3JlcyB0aGUgZmFjdCBpbXBsaWNpdCBhbHNvIHNoYWxsIGJlIGFiYW5k b25lZCBiZWNhdXNlIG9mIGl0cyB2dWxuZXJhYmlsaXR5IGZvciBhY2Nlc3MgdG9rZW4gaW5qZWN0 aW9uLg0KPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJIHRoZXJlZm9yZSBwcm9wb3Nl IGEgbW9kaWZpZWQgdGV4dDogPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAm bmJzcDsgSW4gb3JkZXIgdG8gYXZvaWQgdGhlc2UgaXNzdWVzLCBDbGllbnRzIFNIT1VMRCBOT1Qg dXNlIHRoZSBpbXBsaWNpdDxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgZ3JhbnQuIEZ1cnRo ZXJtb3JlLCBjbGllbnRzIFNIT1VMRCBvbmx5IHVzZSBvdGhlciByZXNwb25zZSB0eXBlcyBjYXVz aW5nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0bzxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJz cDsgaXNzdWUgYW4gYWNjZXNzIHRva2VuIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlLCBp ZiB0aGUgcGFydGljdWxhciByZXNwb25zZSB0eXBlIGRldGVjdHMgYWNjZXNzIHRva2VuDQo8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IGluamVjdGlvbiBhbmQgdGhlIGlzc3VlZCBhY2Nlc3Mg dG9rZW5zIGFyZSBzZW5kZXItY29uc3RyYWluZWQuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyBPciB3ZSBqdXN0IHN0YXRlOjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJm5ic3A7SW4gb3JkZXIgdG8gYXZvaWQgdGhlc2UgaXNzdWVzLCBDbGllbnRzIFNIT1VMRCBO T1QgdXNlIHRoZSByZXNwb25zZSB0eXBlIOKAnnRva2VuJnF1b3Q7LiBUaGUgcmVzcG9uc2UgdHlw ZXM8YnI+DQomZ3Q7ICZndDsg4oCedG9rZW4gaWRfdG9rZW7igJwgYW5kIOKAnmNvZGUgdG9rZW4g aWRfdG9rZW7igJwgU09VTEQgTk9UIGJlIHVzZWQsIGlmIHRoZSBpc3N1ZWQgYWNjZXNzIHRva2Vu cyBhcmUgbm90DQo8YnI+DQomZ3Q7ICZndDsgc2VuZGVyLWNvbnN0cmFpbmVkLjxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJbiBmYWN0LCBJ IHdvdWxkIGZ1cnRoZXIgZ28gYW5kIHNheSBNVVNUIE5PVCBidXQgdGhhdCBwcm9iYWJseSBpcyB0 b28gbXVjaCBmb3IgYSBzZWN1cml0eSBjb25zaWRlcmF0aW9uLjxicj4NCiZndDsgJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTWlrZSBzdWdnZXN0ZWQgdG8gZ28gd2l0 aCBhIFNIT1VMRCBOT1QgdG8gZ2V0IHRoZSBtZXNzYWdlIG91dCBidXQgZ2l2ZSBpbXBsZW1lbnRv cnMgdGltZSB0byBtb3ZlL2NoYW5nZS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgQmVzdCw8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBOYXQ8YnI+ DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBOYXQgU2FraW11cmEgLyA8YSBo cmVmPSJtYWlsdG86bi1zYWtpbXVyYUBucmkuY28uanAiIHRhcmdldD0iX2JsYW5rIj5uLXNha2lt dXJhQG5yaS5jby5qcDwvYT4gLyAmIzQzOzgxLTkwLTYwMTMtNjI3Njxicj4NCiZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1m YW1pbHk6RGVuZ1hpYW4iPuOBk+OBruODoeODvOODq+OBq+OBr+OAgeacrOadpeOBruWum+WFiOOB ruaWueOBruOBv+OBq+mZkOWumuOBleOCjOOBn+apn+WvhuaDheWgseOBjOWQq+OBvuOCjOOBpuOB hOOCi+WgtOWQiOOBjOOBlOOBluOBhOOBvuOBmeOAguOBiuW/g+OBguOBn+OCiuOBruOBquOBhOWg tOWQiOOBr+OAgeiqoOOBq+eUs+OBl+ios+OBlOOBluOBhOOBvuOBm+OCk+OBjOOAgemAgeS/oeiA heOBvuOBp+OBiuefpeOCieOBm+mgguOBjeOAgeOBvuOBn+WPl+S/oeOBleOCjOOBn+ODoeODvOOD q+OBr+WJiumZpOOBl+OBpuOBj+OBoOOBleOBhOOBvuOBmeOCiOOBhuOBiumhmOOBhOeUs+OBl+S4 iuOBkuOBvuOBmeOAgjwvc3Bhbj48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyBQTEVBU0UgUkVBRCA6VGhpcyBlLW1haWwgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRl ZCBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudCBvbmx5Ljxicj4NCiZndDsgJmd0OyAmZ3Q7IElmIHlv dSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBlLW1haWwuPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5n WGlhbiI+5beu5Ye65Lq6PC9zcGFuPjogVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9yc3RlbkBs b2RkZXJzdGVkdC5uZXQ8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IDxzcGFuIGxhbmc9IlpI LUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6RGVuZ1hpYW4iPumAgeS/oeaXpeaZgjwvc3Bhbj46IDxz cGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6RGVuZ1hpYW4iPg0K5rC05puc5pel PC9zcGFuPiwgMTE8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OkRlbmdYaWFu Ij7mnIg8L3NwYW4+IDI4LCAyMDE4IDExOjM4DQo8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZv bnQtZmFtaWx5OkRlbmdYaWFuIj7ljYjlvow8L3NwYW4+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPHNw YW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+5a6b5YWIPC9zcGFu Pjogbi1zYWtpbXVyYTxicj4NCiZndDsgJmd0OyAmZ3Q7IENjOiBEaWNrIEhhcmR0OyBIYW5uZXMg VHNjaG9mZW5pZzsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+DQpvYXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyA8c3BhbiBsYW5nPSJa SC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OkRlbmdYaWFuIj7ku7blkI08L3NwYW4+OiBSZTogW09B VVRILVdHXSBPQXV0aCBTZWN1cml0eSBUb3BpY3MgLS0gUmVjb21tZW5kIGF1dGhvcml6YXRpb24g Y29kZSBpbnN0ZWFkIG9mIGltcGxpY2l0PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgSGkgTmF0LCA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyZndDsgQW0gMjguMTEuMjAxOCB1bSAyMToxMCBzY2hyaWViIG4tc2FraW11cmEgJmx0 OzxhIGhyZWY9Im1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5qcCIgdGFyZ2V0PSJfYmxhbmsiPm4t c2FraW11cmFAbnJpLmNvLmpwPC9hPiZndDs6PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7Jmd0OyBJIHdvdWxkIHN1cHBvcnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IDEpIGNsZWFybHkgZGVmaW5pbmcgSW1wbGljaXQg YXMgdGhlIGZsb3cgdGhhdCByZXR1cm5zIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSBhdXRob3JpemF0 aW9uIGVuZHBvaW50ICggc29tZSBwZW9wbGUgY29uZnVzZXMgaW1wbGljaXQgYXMgdGhlIGZsb3cg dGhhdCByZXR1cm5zIElEIFRva2VuIGluIHRoZSBmcm9udCBjaGFubmVsKTxicj4NCiZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoYXTigJlzIHRoZSBjdXJyZW50IHRleHQ6IDxi cj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEluIG9yZGVyIHRvIGF2b2lk IHRoZXNlIGlzc3VlcywgQ2xpZW50cyBTSE9VTEQgTk9UIHVzZSB0aGUgaW1wbGljaXQ8YnI+DQom Z3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgZ3JhbnQgb3IgYW55IG90aGVyIHJlc3BvbnNlIHR5 cGUgY2F1c2luZyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG88YnI+DQomZ3Q7ICZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgaXNzdWUgYW4gYWNjZXNzIHRva2VuIGluIHRoZSBhdXRob3JpemF0aW9u IHJlc3BvbnNlLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFdoYXQg d291bGQgeW91IGxpa2UgdG8gbW9kaWZ5PyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IDIpIEJhbm5pbmcgdGhlIHJl dHVybmluZyBvZiB0aGUgYWNjZXNzIHRva2VuIHRoYXQgYXJlIG5vdCBzZW5kZXIgY29uc3RyYWlu ZWQgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7IEluIG9yZGVyIHRvIGF2b2lkIHRoZXNlIGlzc3VlcywgQ2xpZW50 cyBTSE9VTEQgTk9UIHVzZSB0aGUgaW1wbGljaXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAm bmJzcDsgZ3JhbnQgb3IgYW55IG90aGVyIHJlc3BvbnNlIHR5cGUgY2F1c2luZyB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgdG88YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgaXNzdWUg YW4gYWNjZXNzIHRva2VuIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlLCBpZiB0aGlzIGFj Y2VzcyB0b2tlbnMgaXMgbm90IHNlbmRlci1jb25zdHJhaW50Ljxicj4NCiZndDsgJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFdoYXQgYWJvdXQgdGhpcz88YnI+DQomZ3Q7ICZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBraW5kIHJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7ICZndDsg VG9yc3Rlbi48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IEJlc3QsPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7Jmd0OyBOYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBPdXRsb29rIGZvciBpT1Mg PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+44KS5YWl5omL PC9zcGFuPjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyZndDsgPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+5beu 5Ye65Lq6PC9zcGFuPjogT0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IChE aWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7DQo8c3BhbiBsYW5nPSJaSC1D TiIgc3R5bGU9ImZvbnQtZmFtaWx5OkRlbmdYaWFuIj7jga7ku6PnkIY8L3NwYW4+KTxicj4NCiZn dDsgJmd0OyAmZ3Q7Jmd0OyA8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OkRl bmdYaWFuIj7pgIHkv6Hml6XmmYI8L3NwYW4+OiA8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZv bnQtZmFtaWx5OkRlbmdYaWFuIj4NCuawtOabnOaXpTwvc3Bhbj4sIDExPHNwYW4gbGFuZz0iWkgt Q04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+5pyIPC9zcGFuPiAyOCwgMjAxOCA4OjU4 DQo8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OkRlbmdYaWFuIj7ljYjlvow8 L3NwYW4+PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IDxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0i Zm9udC1mYW1pbHk6RGVuZ1hpYW4iPuWum+WFiDwvc3Bhbj46IEhhbm5lcyBUc2Nob2ZlbmlnPGJy Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyZn dDsgPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+5Lu25ZCN PC9zcGFuPjogUmU6IFtPQVVUSC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNzIC0tIFJlY29tbWVu ZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNpdDxicj4NCiZndDsgJmd0OyAm Z3Q7Jmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJiM0MzsxPGJyPg0KJmd0OyAm Z3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBXaGlsZSB0aGVyZSBhcmUgdmFy aW91cyBtZWNoYW5pc21zIHRvIGFsbGV2aWF0ZSBzb21lIG9mIHRoZSBpc3N1ZXMgb2YgaW1wbGlj aXQsIEkgZG9uJ3QgdGhpbmsgd2UgY2FuIHJlY29tbWVuZCBzcGVjaWZpY3MsIGFuZCB0aGVyZSBt YXkgYmUgZnV0dXJlIG9uZXMgaW4gdGhlIGZ1dHVyZS4gSSB0aGluayB3ZSBhbGwgYWdyZWUgdGhh dCBpbXBsaWNpdCB3aXRob3V0IGFueSBtaXRpZ2F0aW9uIGlzIHByb2JsZW1hdGljLg0KPGJyPg0K Jmd0OyAmZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBIb3cgYWJvdXQgd2Ug cmVjb21tZW5kIGFnYWluc3QgdXNpbmcgaW1wbGljaXQgYWxvbmU/IDxicj4NCiZndDsgJmd0OyAm Z3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7 IE9uIE1vbiwgTm92IDE5LCAyMDE4IGF0IDI6MzQgQU0gSGFubmVzIFRzY2hvZmVuaWcgJmx0Ozxh IGhyZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyAm Z3Q7Jmd0OyBIaSBhbGwsPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7Jmd0OyBUaGUgYXV0aG9ycyBvZiB0aGUgT0F1dGggU2VjdXJpdHkgVG9waWNzIGRyYWZ0IGNh bWUgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCBpdCBpcyBub3QgcG9zc2libGUgdG8gYWRlcXVhdGVs eSBzZWN1cmUgdGhlIGltcGxpY2l0IGZsb3cgYWdhaW5zdCB0b2tlbiBpbmplY3Rpb24gc2luY2Ug cG90ZW50aWFsIHNvbHV0aW9ucyBsaWtlIHRva2VuIGJpbmRpbmcgb3IgSkFSTSBhcmUgaW4gYW4g ZWFybHkgc3RhZ2Ugb2YgYWRvcHRpb24uIEZvciB0aGlzDQogcmVhc29uLCBhbmQgc2luY2UgQ09S UyBhbGxvd3MgYnJvd3Nlci1iYXNlZCBhcHBzIHRvIHNlbmQgcmVxdWVzdHMgdG8gdGhlIHRva2Vu IGVuZHBvaW50LCBUb3JzdGVuIHN1Z2dlc3RlZCB0byB1c2UgdGhlIGF1dGhvcml6YXRpb24gY29k ZSBpbnN0ZWFkIG9mIHRoZSBpbXBsaWNpdCBncmFudCBpbiBjYWxsIGNhc2VzIGluIGhpcyBwcmVz ZW50YXRpb24gKHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0 aW5nLzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEwMy1vYXV0aC1zZXNzYi1kcmFmdC1pZXRmLW9hdXRo LXNlY3VyaXR5LXRvcGljcy0wMSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEwMy1vYXV0aC1zZXNzYi1k cmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0wMTwvYT4pLjxicj4NCiZndDsgJmd0OyAm Z3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgQSBodW0gaW4gdGhlIHJvb20gYXQgSUVU RiMxMDMgY29uY2x1ZGVkIHN0cm9uZyBzdXBwb3J0IGZvciBoaXMgcmVjb21tZW5kYXRpb25zLiBX ZSB3b3VsZCBsaWtlIHRvIGNvbmZpcm0gdGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QuPGJyPg0K Jmd0OyAmZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBQbGVhc2UgcHJvdmlk ZSBhIHJlc3BvbnNlIGJ5IERlY2VtYmVyIDNyZC48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IENpYW88YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsmZ3Q7IEhhbm5lcyAmYW1wOyBSaWZhYXQ8YnI+DQomZ3Q7ICZndDsgJmd0 OyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRl bnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFu ZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBk aXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvcg0KIGFu eSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVt LiBUaGFuayB5b3UuPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IE9BdXRo IG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1 dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 ICZndDsgJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7 IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+ DQomZ3Q7ICZndDsgJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZndDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZn dDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhA aWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgT0F1 dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZn dDsgLS0gPGJyPg0KJmd0OyAtLS0tPGJyPg0KJmd0OyBBYXJvbiBQYXJlY2tpPGJyPg0KJmd0OyA8 YSBocmVmPSJodHRwOi8vYWFyb25wYXJlY2tpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFhcm9ucGFy ZWNraS5jb208L2E+PGJyPg0KJmd0OyBAYWFyb25wazxicj4NCiZndDsmbmJzcDsgPGJyPg0KJmd0 OyBJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0 dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueQ0KIHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkg dGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS48YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNv bnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5v dCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBh bnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVk aXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_VI1PR0801MB211236D26928008A9CF8038DFAAE0VI1PR0801MB2112_-- From nobody Mon Dec 3 01:11:50 2018 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 A9A20130E2A for ; Mon, 3 Dec 2018 01:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tx-ewI-hVrz6 for ; Mon, 3 Dec 2018 01:11:46 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id C871C126C01 for ; Mon, 3 Dec 2018 01:11:46 -0800 (PST) Received: from [IPv6:2601:282:202:b210:4050:23a5:fd62:9bc6] (unknown [IPv6:2601:282:202:b210:4050:23a5:fd62:9bc6]) by alkaline-solutions.com (Postfix) with ESMTPSA id 29E85315FE; Mon, 3 Dec 2018 09:11:46 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: David Waite In-Reply-To: <33A5FD93-0A1C-426E-9F50-519D51094B28@lodderstedt.net> Date: Mon, 3 Dec 2018 02:11:45 -0700 Cc: Hans Zandbelt , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8CB0E6D2-7B0F-4807-9CC2-F740EC95ABCF@alkaline-solutions.com> References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> <33A5FD93-0A1C-426E-9F50-519D51094B28@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 03 Dec 2018 09:11:49 -0000 > On Dec 3, 2018, at 1:25 AM, Torsten Lodderstedt = wrote: >=20 > I think the BCP needs to point out there are solutions beyond an app = directly interacting with AS and RSs from the browser. Otherwise people = get the wrong impression this is the only way to go. To the contrary and = as I pointed out, there are a lot of SPAs working as UI of a larger = application.=20 My feeling is different - these applications all _could_ be = expressed/implemented in terms of OAuth 2/OpenID Connect. Instead of = authorization being done via opaque access tokens, the non-OAuth = application has authorization tracked via opaque cookies. I think we can state this, and that many of the rules given could be = used >=20 > Any multi user app needs a database. Will this database be directly = exposed to the frontend? I don=E2=80=99t think so. There will be a = backend, exposing relevant capabilities to the SPA. Sure, but this doesn=E2=80=99t change the interface being exposed around = the database as being a protected resource - just one protected by a = token acquired via a different non-OAuth manner > And if this app also uses external services, where do you want to = store the respective refresh tokens? In the browser=E2=80=99s local = storage? I don=E2=80=99t believe so. They will go into the same backend = & database. > And there are other reasons: No one will ever be able to implement a = PSD2 TPP as a stand-alone SPA, obviously because it requires a = confidential client but there are more aspects.=20 You could have your AS also be responsible for fetching/maintaining = remote tokens, and issue local environment tokens. It could expose = either local protected resources which use these remote resources, or = provide a reverse proxy that translates the calls directly, including = applying the remote access token. This also looks very similar whether = you are talking about the javascript being OAuth or using a proprietary = cookie-based system. > Moreover, some security objectives can only be achieved if a backend = is used. That=E2=80=99s how the discussion started (token binding and = the like). Cookies have browser-level support, so they can have browser-level = protections asked for (SameSite, HttpOnly, Secure, separate path/domain = limiting). IMHO, the other differences are apples-to-oranges comparing = different protected resources, not access-vs-other-tokens. Is there value in defining =E2=80=9Cofficial=E2=80=9D recommendations = around access tokens within cookies? > IMHO omitting this option significantly reduces the relevance of the = BCP. > I=E2=80=99m not saying we shall describe the interaction between = frontend and backend in detail. I advocate for pointing out this option = and its benefits. That=E2=80=99s it. Again, I think a significant portion of recommendations would have value = for non-oauth-client javascript. But I think we should focus on defining = solely in terms of OAuth clients. I agree we should point out the option = in the sense that it will help people understand that it doesn=E2=80=99t = significantly affect the security requirements. The rest seem points = around protected resources and cases for a local AS to house business = logic. A lot of the above might be recommendations around protected resources = and multi-level authorization (for example: having clients interact with = a local environment which may behind-the-scenes be using OAuth itself = with remote services). I=E2=80=99m unsure how you would rein in scope on = something like this, though. -DW= From nobody Mon Dec 3 01:16:48 2018 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 34DFC1277CC for ; Mon, 3 Dec 2018 01:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_PASS=-0.001] 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 nvvi7DgxAETf for ; Mon, 3 Dec 2018 01:16:43 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450: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 6D240126C01 for ; Mon, 3 Dec 2018 01:16:42 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id n190so2441173wmd.0 for ; Mon, 03 Dec 2018 01:16:42 -0800 (PST) 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=qwQoPAK8bq+W0tw2NzXPUtGEIHjElWYUEViNxnA0TbA=; b=fWA4HSBwbf9VSOTk2dy0xU8umkQB8BvXQm3QXB1LqGsS99t2zKwXpYsO4JcFYaN1Xv tbV8nlGt4SFoKNPHoKo8rlLmLuu9vmDCcScK5eW2ORMLr+ZEHApRIZt4mlwlz+kuTrPV H9mBwbDWhxxgANo7wHVkj6OAd/Ji+kTH+xGLxM6YJe07FYGT66M32YiNxYFw2innDEbg FenW021S02bRI96wDGVZYQXnIltsEfuAqVmFz+u+0Cp1ikZaAKcnDLoOuNuM2fytMFWk k2jVN6+IT42EBKg+/WUjZifxM3j71Zh13U5HcfZwCgQSotgVwSZQUpzK75+9WXBIkGHE 9H/Q== 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=qwQoPAK8bq+W0tw2NzXPUtGEIHjElWYUEViNxnA0TbA=; b=T+h/oFpQeKi3ComP5pc0y3OkNI8Bx9wIZjTemrt37GDyK838GX8bGjE/HETNHK75Ny mUFWF3PwoYiIgC2jDOqJXDyGHQo3AqkTnEPjXP6zcHf9YPwxiyDwYe+h7k8l877HPjzI 3fdmcik7QQR3fVHDB7QHHwUL5UMglpidz9KPkelt3lgjmf/BxEmpKrO/Rh3MTss4ZVN2 xvR1WDX/x/O9VtxBiso1u99PtaQjpQKMxEO466wRgHKyOdhg4m4lSprEtom7YGSEJMSL ekyjohz0EjORlQIxEEjBCZw477yjv9kwb/xNP4w5PB6wSXtwlfOFQAT/MdeSvZlBRmgy 9BCw== X-Gm-Message-State: AA+aEWZv/KFaxPau6cnCfqCGLQLc7sG8rlhkwTs3EdDf+sZf3uSbsGGC bTgNWh0geMaOuRihuhbosxtPLLPXmYY= X-Google-Smtp-Source: AFSGD/XLIqV7jWiMIZb4bbpB8eLFtWqO0AZvTVMWURhvO0xvwRckW2XvIdgXLzXeur4A6cwwizHqMQ== X-Received: by 2002:a7b:cc86:: with SMTP id p6mr7210027wma.19.1543828600247; Mon, 03 Dec 2018 01:16:40 -0800 (PST) Received: from ?IPv6:2003:c1:4f01:3200:a510:9a05:e583:d6df? (p200300C14F013200A5109A05E583D6DF.dip0.t-ipconnect.de. [2003:c1:4f01:3200:a510:9a05:e583:d6df]) by smtp.gmail.com with ESMTPSA id j8sm10230920wrt.40.2018.12.03.01.16.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Dec 2018 01:16:39 -0800 (PST) To: oauth@ietf.org References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> From: Daniel Fett Message-ID: <814b09ee-8c50-94a7-f00e-9dcf61b660d6@yes.com> Date: Mon, 3 Dec 2018 10:16:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0CA2824DAFA31BA089119379" Content-Language: de-DE Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 03 Dec 2018 09:16:47 -0000 This is a multi-part message in MIME format. --------------0CA2824DAFA31BA089119379 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit We also are talking about a stronger attacker model than what was assumed before, and there are good reasons for that:   * We see more dynamic setups now which enable new kinds of attacks. With the AS Mix-Up attack, for example, we have seen that tokens and codes can leak in unexpected ways. PKCE comes to the rescue of the auth code grant, but there's no such thing for implicit, as Hannes said. In these dynamic setups, we also have to assume that endpoints can be misconfigured etc. which is why it makes sense to use a strong attacker model (as we see in the FAPI working group, for example).   * OAuth nowadays is used in high-stakes environments such as financial transactions. We should have multiple lines of defense in place in such environments, and the implicit mode just gives us one (with regards to access token leakage). So, while the text in RFC6749 has not changed, the world around it has changed quite a lot. -Daniel Am 03.12.18 um 10:00 schrieb Hannes Tschofenig: > > (chair hat off) > >   > > I believe many in this group had concerns with the implicit grant > already for a long time but thought it was necessary for use with > JavaScript-based apps in the browser. Two things have happened in the > meanwhile > > * Attempts to secure the implicit grant, for example with token > binding, weren’t successful > * CORS is widely deployed making the authorization code usage possible > >   > > Since we are now trying to make recommendations for OAuth 2.0 security > in the document Thorsten is editing we obviously have to make a > recommendation. > > Additionally, Aaron started , > which is a document we should have been working on for along time > already. > >   > > Ciao > > Hannes > >   > > *From:*Vittorio Bertocci > *Sent:* Monday, December 3, 2018 5:14 AM > *To:* Torsten Lodderstedt > *Cc:* Daniel Fett ; Hannes Tschofenig > ; IETF oauth WG > *Subject:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend > authorization code instead of implicit > >   > > Hi all, > > Sorry for stepping a bit back from the level of detail the discussion > already reached. I do have some specific comments on the document, but > before bringing those up I wanted to raise a general problem I am > experiencing with this initiative. > >   > > I have a number of customers that are reacting to the news with > distress. The language used in some of the communications associated > with this initiative made them feel like some new vulnerability was > discovered, calling for immediate action. > > The fact is that as far as I can tell, no new, previously unknown fact > informed this decision: no new vulnerability, nor any new technology > that wasn’t available before (the sender constrain is still not > actionable for most customers). The risks of the implicit flow aren’t > bigger now than they were in October. > > That doesn’t mean that we cannot improve guidance, of course- and now > is as good as any other moment to do so: but at the same time, I think > we need to be cognizant of the *immense* investment in existence today > in form of SDKs and applications built on those SDKs that are > predicated on implicit flow, with our blessing: until very recently > the official position was “implicit is bad but it’s the best we have > noawadays”. > > To me, being cognizant of that means that we should help people to > formulate action proportionate to the risk. And if until yesterday we > were ok with them using implicit, we cannot realistically expect > anyone to start changing all of their apps today, but that’s the > message many customers are getting.  > > TL;DR, I think the community would be well served by clarifying in the > security document that there is no new risk and their existing > codebase didn’t suddenly become less secure and in *urgent* need to > update. > > To attempt a metaphor. We discovered a new drug against headache with > milder side effects than the one we were prescribing them until now, > but that doesn’t mean that they should throw away all the stash they > have of the older drug. The old drug will keep working as it worked > until now. Once they run out of their stash, they should get the new > one; or if the old side effects were particularly bad for them, > perhaps they should consider switching today. But this isn’t a recall.  > >   > > And if in fact this group thinks it should be a recall and get > everyone off the old one right now, I think we’ll need to make a much > stronger case than we have done so far. > >   > > Thoughts? > >   > > Thanks > > V. > >   > >   > > On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt > > wrote: > > Hi Hannes, > > > Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig > >: > > > > I agree with Aaron here and I think Section 3.8.1.2 of > draft-ietf-oauth-security-topics-10  already does a pretty good job. > > my proposal is to add the following definition (based on 3.8.1.2) > to a new „Terminology" section or to section 2.1.2: > > A sender constrained access token scopes the applicability of an > access token to a certain sender.  This sender is > obliged to demonstrate knowledge of a certain secret as > prerequisite for the acceptance of that token at the recipient > (e.g. a resource server). > > > > > I was, however, wondering about the subtle implication of the > requirement for sender constrained tokens. My understanding of the > token binding discussion, which is one of the ways to provide > sender-constrained tokens, is that we don’t have good faith in > seeing deployment anytime soon. Hence, we are essentially (reading > in between the lines of Section 3.8.1.2) saying that you cannot > use implicit grant in a practical setup for the web*. > > The text shall convey that implicit must not be used at all. The > main reason being it is unprotected against token injection and > additionally also cannot sender constrain tokens. > > The second part of the statement relates to other response types > and conditionally opens the MUST NOT in case they are protected > against injection (which is true for the listed response types) > and can issue sender constrained tokens (which does not work today > but might work in the future). > > kind regards, > Torsten. > > >  > > Am I misunderstanding it? > > >  > > Ciao > > Hannes > >  > > PS: The IoT case is likely different. > >  > > From: OAuth > On Behalf Of Aaron Parecki > > Sent: Saturday, December 1, 2018 3:18 AM > > To: Torsten Lodderstedt > > > Cc: Daniel Fett >; IETF oauth WG > > > Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend > authorization code instead of implicit > >  > > +1 > >  > > I would also like to ensure there is a clear definition of > "sender constrained" tokens in this BCP. > >  > > Aaron > >  > >  > > On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt > > wrote: > > Hi all, > > > > based on your feedback on the list and off list, Daniel and I > polished the text. That’s our proposal: > > > > — > > In order to avoid these issues, clients MUST NOT use the implicit > > grant (response type "token") or any other response type issuing > access > > tokens in the authorization response, such as "token id_token" > and "code token id_token“, > > unless the issued access tokens are sender-constrained and > access token injection in > > the authorization response is prevented. > > — > > > > Explantation: > > - we wanted to have the right balance between a generic > definition of the response types we do not recommend/allow to be > used and a concrete/actionable list of the affected response types. > > - we changed from SHOULD NOT to MUST NOT as suggested by Nat and > supported by William > > > > We look forward to seeing your feedback. > > > > kind regards, > > Torsten.  > > > > > Am 29.11.2018 um 15:15 schrieb John Bradley >: > > > > > > I am ok with that.  > > > > > > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt > wrote: > > > > > > > Am 28.11.2018 um 23:50 schrieb n-sakimura > >: > > > > > > > > That works. > > > > > > Good! > > > > > > I just realized this text has an issue with „token“ (only). It > would allow „token“ to be used if the token would sender > constrained. This completely ignores the fact implicit also shall > be abandoned because of its vulnerability for access token injection. > > > > > > I therefore propose a modified text: > > > > > >    In order to avoid these issues, Clients SHOULD NOT use the > implicit > > >    grant. Furthermore, clients SHOULD only use other response > types causing the authorization server to > > >    issue an access token in the authorization response, if the > particular response type detects access token > > >    injection and the issued access tokens are sender-constrained. > > > > > > Or we just state: > > > > > >   In order to avoid these issues, Clients SHOULD NOT use the > response type „token". The response types > > > „token id_token“ and „code token id_token“ SOULD NOT be used, > if the issued access tokens are not > > > sender-constrained. > > > > > > > > > > > In fact, I would further go and say MUST NOT but that > probably is too much for a security consideration. > > > > > > > > > > Mike suggested to go with a SHOULD NOT to get the message out > but give implementors time to move/change. > > > > > > > Best, > > > > > > > > Nat > > > > > > > > Nat Sakimura / n-sakimura@nri.co.jp > / +81-90-6013-6276 > > > > > > > > > このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。 > > > > > > > > PLEASE READ :This e-mail is confidential and intended for > the named recipient only. > > > > If you are not an intended recipient, please notify the > sender and delete this e-mail. > > > >  > > > > 差出人: Torsten Lodderstedt > > > > > 送信日時: 水曜日, 11月 28, 2018 11:38 午後 > > > > 宛先: n-sakimura > > > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org > > > > > 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend > authorization code instead of implicit > > > >  > > > > Hi Nat, > > > > > > > >> Am 28.11.2018 um 21:10 schrieb n-sakimura > >: > > > >> > > > >> I would support > > > >> > > > >> 1) clearly defining Implicit as the flow that returns > access token from the authorization endpoint ( some people > confuses implicit as the flow that returns ID Token in the front > channel) > > > > > > > > That’s the current text: > > > > > > > > In order to avoid these issues, Clients SHOULD NOT use the > implicit > > > >    grant or any other response type causing the > authorization server to > > > >    issue an access token in the authorization response. > > > > > > > > What would you like to modify? > > > > > > > >> > > > >> 2) Banning the returning of the access token that are not > sender constrained from the authorization endpoint > > > > > > > > In order to avoid these issues, Clients SHOULD NOT use the > implicit > > > >    grant or any other response type causing the > authorization server to > > > >    issue an access token in the authorization response, if > this access tokens is not sender-constraint. > > > > > > > > What about this? > > > > > > > > kind regards, > > > > Torsten. > > > > > > > >> > > > >> Best, > > > >> > > > >> Nat > > > >> > > > >> > > > >> Outlook for iOS を入手 > > > >>  > > > >> 差出人: OAuth > (Dick Hardt > の代理) > > > >> 送信日時: 水曜日, 11月 28, 2018 8:58 午後 > > > >> 宛先: Hannes Tschofenig > > > >> Cc: oauth@ietf.org > > > >> 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend > authorization code instead of implicit > > > >>  > > > >> +1 > > > >> > > > >> While there are various mechanisms to alleviate some of the > issues of implicit, I don't think we can recommend specifics, and > there may be future ones in the future. I think we all agree that > implicit without any mitigation is problematic. > > > >> > > > >> How about we recommend against using implicit alone? > > > >> > > > >> > > > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig > > wrote: > > > >> Hi all, > > > >> > > > >> The authors of the OAuth Security Topics draft came to the > conclusion that it is not possible to adequately secure the > implicit flow against token injection since potential solutions > like token binding or JARM are in an early stage of adoption. For > this reason, and since CORS allows browser-based apps to send > requests to the token endpoint, Torsten suggested to use the > authorization code instead of the implicit grant in call cases in > his presentation (see > https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01). > > > >> > > > >> A hum in the room at IETF#103 concluded strong support for > his recommendations. We would like to confirm the discussion on > the list. > > > >> > > > >> Please provide a response by December 3rd. > > > >> > > > >> 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 the information in any > medium. Thank you. > > > >> _______________________________________________ > > > >> 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 > > -- > > ---- > > Aaron Parecki > > aaronparecki.com > > @aaronpk > >  > > 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 the 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 the information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------0CA2824DAFA31BA089119379 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
We also are talking about a stronger attacker model than what was assumed before, and there are good reasons for that:

  * We see more dynamic setups now which enable new kinds of attacks. With the AS Mix-Up attack, for example, we have seen that tokens and codes can leak in unexpected ways. PKCE comes to the rescue of the auth code grant, but there's no such thing for implicit, as Hannes said. In these dynamic setups, we also have to assume that endpoints can be misconfigured etc. which is why it makes sense to use a strong attacker model (as we see in the FAPI working group, for example).

  * OAuth nowadays is used in high-stakes environments such as financial transactions. We should have multiple lines of defense in place in such environments, and the implicit mode just gives us one (with regards to access token leakage).

So, while the text in RFC6749 has not changed, the world around it has changed quite a lot.

-Daniel

Am 03.12.18 um 10:00 schrieb Hannes Tschofenig:

(chair hat off)

 

I believe many in this group had concerns with the implicit grant already for a long time but thought it was necessary for use with JavaScript-based apps in the browser. Two things have happened in the meanwhile

  • Attempts to secure the implicit grant, for example with token binding, weren’t successful
  • CORS is widely deployed making the authorization code usage possible

 

Since we are now trying to make recommendations for OAuth 2.0 security in the document Thorsten is editing we obviously have to make a recommendation.

Additionally, Aaron started <draft-parecki-oauth-browser-based-apps>, which is a document we should have been working on for along time already.

 

Ciao

Hannes

 

From: Vittorio Bertocci <vittorio.bertocci@auth0.com>
Sent: Monday, December 3, 2018 5:14 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Daniel Fett <fett@danielfett.de>; Hannes Tschofenig <Hannes.Tschofenig@arm.com>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

 

Hi all,

Sorry for stepping a bit back from the level of detail the discussion already reached. I do have some specific comments on the document, but before bringing those up I wanted to raise a general problem I am experiencing with this initiative.

 

I have a number of customers that are reacting to the news with distress. The language used in some of the communications associated with this initiative made them feel like some new vulnerability was discovered, calling for immediate action.

The fact is that as far as I can tell, no new, previously unknown fact informed this decision: no new vulnerability, nor any new technology that wasn’t available before (the sender constrain is still not actionable for most customers). The risks of the implicit flow aren’t bigger now than they were in October.

That doesn’t mean that we cannot improve guidance, of course- and now is as good as any other moment to do so: but at the same time, I think we need to be cognizant of the *immense* investment in existence today in form of SDKs and applications built on those SDKs that are predicated on implicit flow, with our blessing: until very recently the official position was “implicit is bad but it’s the best we have noawadays”.

To me, being cognizant of that means that we should help people to formulate action proportionate to the risk. And if until yesterday we were ok with them using implicit, we cannot realistically expect anyone to start changing all of their apps today, but that’s the message many customers are getting. 

TL;DR, I think the community would be well served by clarifying in the security document that there is no new risk and their existing codebase didn’t suddenly become less secure and in *urgent* need to update.

To attempt a metaphor. We discovered a new drug against headache with milder side effects than the one we were prescribing them until now, but that doesn’t mean that they should throw away all the stash they have of the older drug. The old drug will keep working as it worked until now. Once they run out of their stash, they should get the new one; or if the old side effects were particularly bad for them, perhaps they should consider switching today. But this isn’t a recall. 

 

And if in fact this group thinks it should be a recall and get everyone off the old one right now, I think we’ll need to make a much stronger case than we have done so far.

 

Thoughts?

 

Thanks

V.

 

 

On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Hannes,

> Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig <Hannes.Tschofenig@arm.com>:
>
> I agree with Aaron here and I think Section 3.8.1.2 of draft-ietf-oauth-security-topics-10  already does a pretty good job.

my proposal is to add the following definition (based on 3.8.1.2) to a new „Terminology" section or to section 2.1.2:

A sender constrained access token scopes the applicability of an access token to a certain sender.  This sender is
obliged to demonstrate knowledge of a certain secret as prerequisite for the acceptance of that token at the recipient (e.g. a resource server).

>
> I was, however, wondering about the subtle implication of the requirement for sender constrained tokens. My understanding of the token binding discussion, which is one of the ways to provide sender-constrained tokens, is that we don’t have good faith in seeing deployment anytime soon. Hence, we are essentially (reading in between the lines of Section 3.8.1.2) saying that you cannot use implicit grant in a practical setup for the web*.

The text shall convey that implicit must not be used at all. The main reason being it is unprotected against token injection and additionally also cannot sender constrain tokens.

The second part of the statement relates to other response types and conditionally opens the MUST NOT in case they are protected against injection (which is true for the listed response types) and can issue sender constrained tokens (which does not work today but might work in the future).

kind regards,
Torsten.

> 
> Am I misunderstanding it?

> 
> Ciao
> Hannes
> 
> PS: The IoT case is likely different.
> 
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki
> Sent: Saturday, December 1, 2018 3:18 AM
> To: Torsten Lodderstedt <torsten@lodderstedt.net>
> Cc: Daniel Fett <fett@danielfett.de>; IETF oauth WG <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
> 
> +1
> 
> I would also like to ensure there is a clear definition of "sender constrained" tokens in this BCP.
> 
> Aaron
> 
> 
> On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
> Hi all,
>
> based on your feedback on the list and off list, Daniel and I polished the text. That’s our proposal:
>
> —
> In order to avoid these issues, clients MUST NOT use the implicit
> grant (response type "token") or any other response type issuing access
> tokens in the authorization response, such as "token id_token" and "code token id_token“,
> unless the issued access tokens are sender-constrained and access token injection in
> the authorization response is prevented.
> —
>
> Explantation:
> - we wanted to have the right balance between a generic definition of the response types we do not recommend/allow to be used and a concrete/actionable list of the affected response types.
> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported by William
>
> We look forward to seeing your feedback.
>
> kind regards,
> Torsten. 
>
> > Am 29.11.2018 um 15:15 schrieb John Bradley <ve7jtb@ve7jtb.com>:
> >
> > I am ok with that. 
> >
> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <torsten@lodderstedt.net wrote:
> >
> > > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@nri.co.jp>:
> > >
> > > That works.
> >
> > Good!
> >
> > I just realized this text has an issue with „token“ (only). It would allow „token“ to be used if the token would sender constrained. This completely ignores the fact implicit also shall be abandoned because of its vulnerability for access token injection.
> >
> > I therefore propose a modified text:
> >
> >    In order to avoid these issues, Clients SHOULD NOT use the implicit
> >    grant. Furthermore, clients SHOULD only use other response types causing the authorization server to
> >    issue an access token in the authorization response, if the particular response type detects access token
> >    injection and the issued access tokens are sender-constrained.
> >
> > Or we just state:
> >
> >   In order to avoid these issues, Clients SHOULD NOT use the response type „token". The response types
> > „token id_token“ and „code token id_token“ SOULD NOT be used, if the issued access tokens are not
> > sender-constrained.
> >
> > >
> > > In fact, I would further go and say MUST NOT but that probably is too much for a security consideration.
> > >
> >
> > Mike suggested to go with a SHOULD NOT to get the message out but give implementors time to move/change.
> >
> > > Best,
> > >
> > > Nat
> > >
> > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
> > >
> > > このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。
> > >
> > > PLEASE READ :This e-mail is confidential and intended for the named recipient only.
> > > If you are not an intended recipient, please notify the sender and delete this e-mail.
> > > 
> > > 差出人: Torsten Lodderstedt <torsten@lodderstedt.net>
> > > 送信日時: 水曜日, 11月 28, 2018 11:38 午後
> > > 宛先: n-sakimura
> > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> > > 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
> > > 
> > > Hi Nat,
> > >
> > >> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nri.co.jp>:
> > >>
> > >> I would support
> > >>
> > >> 1) clearly defining Implicit as the flow that returns access token from the authorization endpoint ( some people confuses implicit as the flow that returns ID Token in the front channel)
> > >
> > > That’s the current text:
> > >
> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
> > >    grant or any other response type causing the authorization server to
> > >    issue an access token in the authorization response.
> > >
> > > What would you like to modify?
> > >
> > >>
> > >> 2) Banning the returning of the access token that are not sender constrained from the authorization endpoint
> > >
> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
> > >    grant or any other response type causing the authorization server to
> > >    issue an access token in the authorization response, if this access tokens is not sender-constraint.
> > >
> > > What about this?
> > >
> > > kind regards,
> > > Torsten.
> > >
> > >>
> > >> Best,
> > >>
> > >> Nat
> > >>
> > >>
> > >> Outlook for iOS を入手
> > >> 
> > >> 差出人: OAuth <oauth-bounces@ietf.org> (Dick Hardt <dick.hardt@gmail.com> の代理)
> > >> 送信日時: 水曜日, 11月 28, 2018 8:58 午後
> > >> 宛先: Hannes Tschofenig
> > >> Cc: oauth@ietf.org
> > >> 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
> > >> 
> > >> +1
> > >>
> > >> While there are various mechanisms to alleviate some of the issues of implicit, I don't think we can recommend specifics, and there may be future ones in the future. I think we all agree that implicit without any mitigation is problematic.
> > >>
> > >> How about we recommend against using implicit alone?
> > >>
> > >>
> > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
> > >> Hi all,
> > >>
> > >> The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
> > >>
> > >> A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list.
> > >>
> > >> Please provide a response by December 3rd.
> > >>
> > >> 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 the information in any medium. Thank you.
> > >> _______________________________________________
> > >> 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
> --
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk
> 
> 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 the 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 the information in any medium. Thank you. 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--------------0CA2824DAFA31BA089119379-- From nobody Mon Dec 3 01:39:27 2018 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 E76E9130E2F for ; Mon, 3 Dec 2018 01:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=armh.onmicrosoft.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 2SPJdr_BgsaK for ; Mon, 3 Dec 2018 01:39:22 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150084.outbound.protection.outlook.com [40.107.15.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5F3130E41 for ; Mon, 3 Dec 2018 01:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AfPxNKh7rKNnptt1VzCvYwQw/E5fAw7IiNqDXmBiQc4=; b=AtYFGT2ZKvysIycEvOCdf5NQxseVSzmOaNhbmhu74SSC2/3285kVmG0jwifgDuj5u+VGTTvoigliU5b8nbWGMIuPuJoVbP8OSBs0VRHmZnQPoHQfbcyA05sKGXjr3YCPOdK5mI626qpTdfLAFLZtnXziJ4w++mf9lq6vcYsl9YE= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1535.eurprd08.prod.outlook.com (10.167.210.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.22; Mon, 3 Dec 2018 09:39:17 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::2056:1db1:e01:4670]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::2056:1db1:e01:4670%3]) with mapi id 15.20.1382.020; Mon, 3 Dec 2018 09:39:17 +0000 From: Hannes Tschofenig To: n-sakimura , Aaron Parecki , Torsten Lodderstedt CC: Daniel Fett , IETF oauth WG Thread-Topic: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit Thread-Index: AdR/8wsdlCSgLoNZTem+1MxrAorhbwHYZjwAAABEwfcABVOygAAAbOyYAAB2LIAAH9tBAAAIC/AAAEN4+4AADeWWQAABjqXmABQfVzA= Date: Mon, 3 Dec 2018 09:39:17 +0000 Message-ID: References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.19] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1535; 6:vWxE/Em8GwdlP0PbW9vxchwxTMjlMSLdMKoZ5iE7H46j8vfPTKEBqPzfX7wGc1yALQ+mghpHHyMVDH7YtzD5EENn0Qbl9CMEeFW6MTKOOIRBYqxYdadakn4BlAZdKPQqMhPBb3YwwFOr4KyaWVHilVSwVtTT0MLnh1NAL14S8GUHy1CDJIGR97DkxR61PEnugxOlFetdGgJRmnhXEPXDYLHU4MYSYnEDwG60pdFUVuoomC7CdXGcATEw5mdTJqIohLf0MKXu00DEfVqigOU0F4SU9FjIQBxplYqqpfSr9lBl6v8yhYzubLZVoy5l0wZqbVwntcE3X/h7TKYkTpkfGWqRe0nAX8EX+cjB/r9yH1gOxS8uV+ZeZzrIwYtJN8vaca20ghK3XUBJxWxnsK7EvlGeVp3LNroLVMU4e05lBNCIXnF5nXAAUrFHVilLe1HAN7ZhcrPSsQUYMbiaKmp72g==; 5:rwcsYSCxaL/QtnIPHnSC3r5HWhkroQxarn68sRlxgMYsoK95aczpPWePu9R+KKcLM0KNq8rdYPmzSy9KyPoKEdYTk7H0mPsODH1GI46fzDJ/Raxlg44QzOKeWRxlcmdIK8Lfmo9YjHBYILtr503bM+d8D54gDfwtYlj1QJSbE80=; 7:eFxn+E4dZszctLcCOkkfIdGSjqsDgW6QTahRJn184/ICVV4VImqWiE/+d0fw2UKcySsBH1PL4uhztni/Sge4aUle3DrlMLta5FSVa8+9N+zhfJLfD8m4rHfIccnWKM3BRAxJgp77UaKZBW9I0k673Q== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7a25b4fc-5494-4868-0ec5-08d6590331cc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1535; x-ms-traffictypediagnostic: VI1PR0801MB1535: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231455)(999002)(944501493)(4982022)(52105112)(2017080701022)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1535; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1535; x-forefront-prvs: 08756AC3C8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(39860400002)(136003)(366004)(365934003)(40434004)(53754006)(189003)(199004)(2420400007)(25786009)(4326008)(790700001)(102836004)(71190400001)(97736004)(53546011)(6506007)(476003)(2906002)(71200400001)(6436002)(53386004)(53376002)(6246003)(3846002)(15650500001)(6116002)(7696005)(446003)(316002)(86362001)(54906003)(110136005)(14444005)(4744004)(5024004)(186003)(11346002)(26005)(486006)(256004)(93886005)(99286004)(66574009)(76176011)(68736007)(606006)(5660300001)(66066001)(9686003)(7736002)(53936002)(8676002)(81156014)(81166006)(6306002)(8936002)(54896002)(966005)(72206003)(14454004)(45080400002)(478600001)(33656002)(7110500001)(561944003)(105586002)(55016002)(74316002)(106356001)(236005)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1535; H:VI1PR0801MB2112.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-microsoft-antispam-message-info: y7VzDykPnUuQphs0QUnwA6FuQg68XhlytBa0lmlVmPnS6Y7MrU1XN6ZrPVuZ07P6/ZPn1MKvy68/6L4dm7GIJ2BapgHCSM/R0QdmAKnYXmvffnixzHKWalRx80ibv5Z8DVgdrvj0VVAkCN8MSzYmN+UH7uWNZBP120Ve2IR7nYo9rlRSA0UTJeWNyKfOfd85HHb6Ql3ex+M/3nFVSd9+PaSTd+2fbgNDefp3W4mimG3fqas3q1ell8ZB5YjErWDXvhHuoHZjMD2td62Z64cRx1WoaJZCb6nWHAys/H1eBHtCMHJv8jQgoQ+acRjeuQC9llozRA4zzblKfJ8FufA9ppzUkfVWzqNTB0ydXDLJSrs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211297F33296CA377A40BFFEFAAE0VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7a25b4fc-5494-4868-0ec5-08d6590331cc X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2018 09:39:17.3123 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1535 Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 03 Dec 2018 09:39:26 -0000 --_000_VI1PR0801MB211297F33296CA377A40BFFEFAAE0VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KGNoYWlyIGhhdCBvZmYpDQoNCkhpIE5hdCwNCg0KU2VjdGlvbiAzLjguMS4yPGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xMCNzZWN0 aW9uLTMuOC4xLjI+IG9mIGRyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTEwICBsaXN0 cyB0aGUgZm9sbG93aW5nIG9wdGlvbnMgZm9yIGltcGxlbWVudGluZyBzZW5kZXIgY29uc3RyYWlu dCB0b2tlbnM6DQoNCiAgKiAgIFRva2VuIEJpbmRpbmcNCiAgKiAgIE1UTFMNCiAgKiAgIFNpZ25l ZCBIVFRQIFJlcXVlc3RzDQogICogICBKUE9QDQoNCkpQT1AgaXMgYW4gaW5kaXZpZHVhbCBzdWJt aXNzaW9uLiBUaGUgd29yayBvbiBzaWduZWQgSFRUUCByZXF1ZXN0cyBzdGFsbGVkLiBUb2tlbiBC aW5kaW5nLCBhcyB3ZSBsZWFybmVkIGF0IHRoZSBsYXN0IElFVEYgbWVldGluZywgaGFzIHNlcmlv dXMgZGVwbG95bWVudCBwcm9ibGVtcy4NClRoYXQgZXNzZW50aWFsbHkgbGVhdmVzIHVzIHdpdGgg TVRMUy4gSSBhbSwgaG93ZXZlciwgbm90IGVudGlyZWx5IHN1cmUgTVRMUyB3b3JrcyB3ZWxsIHdp dGggdGhlIGltcGxpY2l0IGdyYW50Lg0KDQpNeSBjb25jbHVzaW9uIHNvIGZhciBmcm9tIHRoZSBk aXNjdXNzaW9uIGlzIHRoYXQgaW1wbGljaXQgZ3JhbnQgY2Fubm90IGJlIHNlY3VyZWQgcHJhY3Rp Y2FsbHkuDQoNCkZvciBJb1QsIGFzIEkgbWVudGlvbmVkLCB0aGUgc3RvcnkgZG9lcyBub3QgbG9v ayBzbyBncmltIHNpbmNlIHdpdGggSW9UIHByb3RvY29scywgQ29BUCBvciBNUVRULCBvbmUgY2Fu IHN0aWxsIHVzZSBUTFMgYXMgd2VsbCBhcyBhcHBsaWNhdGlvbiBsYXllciBzZWN1cml0eS4gKEF0 IGxlYXN0IHRoYXTigJlzIHRoZSBjdXJyZW50IHVuZGVyc3RhbmRpbmcuKQ0KDQpJIGFtIGhhcHB5 IHRvIGdldCBjb3JyZWN0ZWQuDQoNCkNpYW8NCkhhbm5lcw0KDQoNCg0KRnJvbTogbi1zYWtpbXVy YSA8bi1zYWtpbXVyYUBucmkuY28uanA+DQpTZW50OiBTYXR1cmRheSwgRGVjZW1iZXIgMSwgMjAx OCAxMDo0NCBBTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0u Y29tPjsgQWFyb24gUGFyZWNraSA8YWFyb25AcGFyZWNraS5jb20+OyBUb3JzdGVuIExvZGRlcnN0 ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4NCkNjOiBEYW5pZWwgRmV0dCA8ZmV0dEBkYW5p ZWxmZXR0LmRlPjsgSUVURiBvYXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W09BVVRILVdHXSBPQXV0aCBTZWN1cml0eSBUb3BpY3MgLS0gUmVjb21tZW5kIGF1dGhvcml6YXRp b24gY29kZSBpbnN0ZWFkIG9mIGltcGxpY2l0DQoNCk9BdXRoIE1UTFMgaGFzIGJlZW4gaW1wbGVt ZW50ZWQgaW4gQmFua2luZyBpbmR1c3RyeSBzbyB3ZSBoYXZlIGF0IGxlYXN0IGFuIGFsdGVybmF0 aXZlLg0KDQpTZW5kZXIgQ29uc3RyYWluZWQgaW5jbHVkZXMgY2FzZXMgd2hlcmUgaXQgaXMgbm90 IGtleSBib3VuZCBidXQgbmFtZSBib3VuZCBhcyBJIHVuZGVyc3RhbmQgYW5kIGl0IG1heSBoYXZl IHNvbWUgdXRpbGl0eSBzbyB3ZSBmIHRoZXJlIGFyZSBkb3VidHMsIG1lbnRpb25pbmcgdGhlIGJv dGggbWF5IGJlIGdvb2QuDQoNCk91dGxvb2sgZm9yIGlPUzxodHRwczovL2FrYS5tcy9vMHVrZWY+ IOOCkuWFpeaJiw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K5beu5Ye65Lq6 OiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZz4+IChIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAYXJtLmNvbTxtYWls dG86aGFubmVzLnRzY2hvZmVuaWdAYXJtLmNvbT4+IOOBruS7o+eQhikNCumAgeS/oeaXpeaZgjog 5Zyf5puc5pelLCAxMuaciCAxLCAyMDE4IDY6MDcg5Y2I5b6MDQrlrpvlhYg6IEFhcm9uIFBhcmVj a2k7IFRvcnN0ZW4gTG9kZGVyc3RlZHQNCkNjOiBEYW5pZWwgRmV0dDsgSUVURiBvYXV0aCBXRw0K 5Lu25ZCNOiBSZTogW09BVVRILVdHXSBPQXV0aCBTZWN1cml0eSBUb3BpY3MgLS0gUmVjb21tZW5k IGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIGltcGxpY2l0DQoNCkkgYWdyZWUgd2l0aCBB YXJvbiBoZXJlIGFuZCBJIHRoaW5rIFNlY3Rpb24gMy44LjEuMjxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTAjc2VjdGlvbi0zLjgu MS4yPiBvZiBkcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xMCAgYWxyZWFkeSBkb2Vz IGEgcHJldHR5IGdvb2Qgam9iLg0KSSB3YXMsIGhvd2V2ZXIsIHdvbmRlcmluZyBhYm91dCB0aGUg c3VidGxlIGltcGxpY2F0aW9uIG9mIHRoZSByZXF1aXJlbWVudCBmb3Igc2VuZGVyIGNvbnN0cmFp bmVkIHRva2Vucy4gTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgdG9rZW4gYmluZGluZyBkaXNjdXNz aW9uLCB3aGljaCBpcyBvbmUgb2YgdGhlIHdheXMgdG8gcHJvdmlkZSBzZW5kZXItY29uc3RyYWlu ZWQgdG9rZW5zLCBpcyB0aGF0IHdlIGRvbuKAmXQgaGF2ZSBnb29kIGZhaXRoIGluIHNlZWluZyBk ZXBsb3ltZW50IGFueXRpbWUgc29vbi4gSGVuY2UsIHdlIGFyZSBlc3NlbnRpYWxseSAocmVhZGlu ZyBpbiBiZXR3ZWVuIHRoZSBsaW5lcyBvZiBTZWN0aW9uIDMuOC4xLjIpIHNheWluZyB0aGF0IHlv dSBjYW5ub3QgdXNlIGltcGxpY2l0IGdyYW50IGluIGEgcHJhY3RpY2FsIHNldHVwIGZvciB0aGUg d2ViKi4NCg0KQW0gSSBtaXN1bmRlcnN0YW5kaW5nIGl0Pw0KDQpDaWFvDQpIYW5uZXMNCg0KUFM6 IFRoZSBJb1QgY2FzZSBpcyBsaWtlbHkgZGlmZmVyZW50Lg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFs ZiBPZiBBYXJvbiBQYXJlY2tpDQpTZW50OiBTYXR1cmRheSwgRGVjZW1iZXIgMSwgMjAxOCAzOjE4 IEFNDQpUbzogVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFp bHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj4NCkNjOiBEYW5pZWwgRmV0dCA8ZmV0dEBkYW5p ZWxmZXR0LmRlPG1haWx0bzpmZXR0QGRhbmllbGZldHQuZGU+PjsgSUVURiBvYXV0aCBXRyA8b2F1 dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgt V0ddIE9BdXRoIFNlY3VyaXR5IFRvcGljcyAtLSBSZWNvbW1lbmQgYXV0aG9yaXphdGlvbiBjb2Rl IGluc3RlYWQgb2YgaW1wbGljaXQNCg0KKzENCg0KSSB3b3VsZCBhbHNvIGxpa2UgdG8gZW5zdXJl IHRoZXJlIGlzIGEgY2xlYXIgZGVmaW5pdGlvbiBvZiAic2VuZGVyIGNvbnN0cmFpbmVkIiB0b2tl bnMgaW4gdGhpcyBCQ1AuDQoNCkFhcm9uDQoNCg0KT24gVGh1LCBOb3YgMjksIDIwMTggYXQgMTA6 MDYgQU0gVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRv OnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj4gd3JvdGU6DQpIaSBhbGwsDQoNCmJhc2VkIG9uIHlv dXIgZmVlZGJhY2sgb24gdGhlIGxpc3QgYW5kIG9mZiBsaXN0LCBEYW5pZWwgYW5kIEkgcG9saXNo ZWQgdGhlIHRleHQuIFRoYXTigJlzIG91ciBwcm9wb3NhbDoNCg0K4oCUDQpJbiBvcmRlciB0byBh dm9pZCB0aGVzZSBpc3N1ZXMsIGNsaWVudHMgTVVTVCBOT1QgdXNlIHRoZSBpbXBsaWNpdA0KZ3Jh bnQgKHJlc3BvbnNlIHR5cGUgInRva2VuIikgb3IgYW55IG90aGVyIHJlc3BvbnNlIHR5cGUgaXNz dWluZyBhY2Nlc3MNCnRva2VucyBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSwgc3VjaCBh cyAidG9rZW4gaWRfdG9rZW4iIGFuZCAiY29kZSB0b2tlbiBpZF90b2tlbuKAnCwNCnVubGVzcyB0 aGUgaXNzdWVkIGFjY2VzcyB0b2tlbnMgYXJlIHNlbmRlci1jb25zdHJhaW5lZCBhbmQgYWNjZXNz IHRva2VuIGluamVjdGlvbiBpbg0KdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UgaXMgcHJldmVu dGVkLg0K4oCUDQoNCkV4cGxhbnRhdGlvbjoNCi0gd2Ugd2FudGVkIHRvIGhhdmUgdGhlIHJpZ2h0 IGJhbGFuY2UgYmV0d2VlbiBhIGdlbmVyaWMgZGVmaW5pdGlvbiBvZiB0aGUgcmVzcG9uc2UgdHlw ZXMgd2UgZG8gbm90IHJlY29tbWVuZC9hbGxvdyB0byBiZSB1c2VkIGFuZCBhIGNvbmNyZXRlL2Fj dGlvbmFibGUgbGlzdCBvZiB0aGUgYWZmZWN0ZWQgcmVzcG9uc2UgdHlwZXMuDQotIHdlIGNoYW5n ZWQgZnJvbSBTSE9VTEQgTk9UIHRvIE1VU1QgTk9UIGFzIHN1Z2dlc3RlZCBieSBOYXQgYW5kIHN1 cHBvcnRlZCBieSBXaWxsaWFtDQoNCldlIGxvb2sgZm9yd2FyZCB0byBzZWVpbmcgeW91ciBmZWVk YmFjay4NCg0Ka2luZCByZWdhcmRzLA0KVG9yc3Rlbi4NCg0KPiBBbSAyOS4xMS4yMDE4IHVtIDE1 OjE1IHNjaHJpZWIgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRi QHZlN2p0Yi5jb20+PjoNCj4NCj4gSSBhbSBvayB3aXRoIHRoYXQuDQo+DQo+IE9uIFdlZCwgTm92 IDI4LCAyMDE4LCA4OjAzIFBNIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6DQo+DQo+ID4gQW0g MjguMTEuMjAxOCB1bSAyMzo1MCBzY2hyaWViIG4tc2FraW11cmEgPG4tc2FraW11cmFAbnJpLmNv LmpwPG1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5qcD4+Og0KPiA+DQo+ID4gVGhhdCB3b3Jrcy4N Cj4NCj4gR29vZCENCj4NCj4gSSBqdXN0IHJlYWxpemVkIHRoaXMgdGV4dCBoYXMgYW4gaXNzdWUg d2l0aCDigJ50b2tlbuKAnCAob25seSkuIEl0IHdvdWxkIGFsbG93IOKAnnRva2Vu4oCcIHRvIGJl IHVzZWQgaWYgdGhlIHRva2VuIHdvdWxkIHNlbmRlciBjb25zdHJhaW5lZC4gVGhpcyBjb21wbGV0 ZWx5IGlnbm9yZXMgdGhlIGZhY3QgaW1wbGljaXQgYWxzbyBzaGFsbCBiZSBhYmFuZG9uZWQgYmVj YXVzZSBvZiBpdHMgdnVsbmVyYWJpbGl0eSBmb3IgYWNjZXNzIHRva2VuIGluamVjdGlvbi4NCj4N Cj4gSSB0aGVyZWZvcmUgcHJvcG9zZSBhIG1vZGlmaWVkIHRleHQ6DQo+DQo+ICAgIEluIG9yZGVy IHRvIGF2b2lkIHRoZXNlIGlzc3VlcywgQ2xpZW50cyBTSE9VTEQgTk9UIHVzZSB0aGUgaW1wbGlj aXQNCj4gICAgZ3JhbnQuIEZ1cnRoZXJtb3JlLCBjbGllbnRzIFNIT1VMRCBvbmx5IHVzZSBvdGhl ciByZXNwb25zZSB0eXBlcyBjYXVzaW5nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0bw0KPiAg ICBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gaW4gdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIGlm IHRoZSBwYXJ0aWN1bGFyIHJlc3BvbnNlIHR5cGUgZGV0ZWN0cyBhY2Nlc3MgdG9rZW4NCj4gICAg aW5qZWN0aW9uIGFuZCB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbnMgYXJlIHNlbmRlci1jb25zdHJh aW5lZC4NCj4NCj4gT3Igd2UganVzdCBzdGF0ZToNCj4NCj4gICBJbiBvcmRlciB0byBhdm9pZCB0 aGVzZSBpc3N1ZXMsIENsaWVudHMgU0hPVUxEIE5PVCB1c2UgdGhlIHJlc3BvbnNlIHR5cGUg4oCe dG9rZW4iLiBUaGUgcmVzcG9uc2UgdHlwZXMNCj4g4oCedG9rZW4gaWRfdG9rZW7igJwgYW5kIOKA nmNvZGUgdG9rZW4gaWRfdG9rZW7igJwgU09VTEQgTk9UIGJlIHVzZWQsIGlmIHRoZSBpc3N1ZWQg YWNjZXNzIHRva2VucyBhcmUgbm90DQo+IHNlbmRlci1jb25zdHJhaW5lZC4NCj4NCj4gPg0KPiA+ IEluIGZhY3QsIEkgd291bGQgZnVydGhlciBnbyBhbmQgc2F5IE1VU1QgTk9UIGJ1dCB0aGF0IHBy b2JhYmx5IGlzIHRvbyBtdWNoIGZvciBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24uDQo+ID4NCj4N Cj4gTWlrZSBzdWdnZXN0ZWQgdG8gZ28gd2l0aCBhIFNIT1VMRCBOT1QgdG8gZ2V0IHRoZSBtZXNz YWdlIG91dCBidXQgZ2l2ZSBpbXBsZW1lbnRvcnMgdGltZSB0byBtb3ZlL2NoYW5nZS4NCj4NCj4g PiBCZXN0LA0KPiA+DQo+ID4gTmF0DQo+ID4NCj4gPiBOYXQgU2FraW11cmEgLyBuLXNha2ltdXJh QG5yaS5jby5qcDxtYWlsdG86bi1zYWtpbXVyYUBucmkuY28uanA+IC8gKzgxLTkwLTYwMTMtNjI3 Ng0KPiA+DQo+ID4g44GT44Gu44Oh44O844Or44Gr44Gv44CB5pys5p2l44Gu5a6b5YWI44Gu5pa5 44Gu44G/44Gr6ZmQ5a6a44GV44KM44Gf5qmf5a+G5oOF5aCx44GM5ZCr44G+44KM44Gm44GE44KL 5aC05ZCI44GM44GU44GW44GE44G+44GZ44CC44GK5b+D44GC44Gf44KK44Gu44Gq44GE5aC05ZCI 44Gv44CB6Kqg44Gr55Sz44GX6Kiz44GU44GW44GE44G+44Gb44KT44GM44CB6YCB5L+h6ICF44G+ 44Gn44GK55+l44KJ44Gb6aCC44GN44CB44G+44Gf5Y+X5L+h44GV44KM44Gf44Oh44O844Or44Gv 5YmK6Zmk44GX44Gm44GP44Gg44GV44GE44G+44GZ44KI44GG44GK6aGY44GE55Sz44GX5LiK44GS 44G+44GZ44CCDQo+ID4NCj4gPiBQTEVBU0UgUkVBRCA6VGhpcyBlLW1haWwgaXMgY29uZmlkZW50 aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudCBvbmx5Lg0KPiA+IElmIHlv dSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBlLW1haWwuDQo+ID4NCj4gPiDlt67lh7rkuro6IFRvcnN0ZW4gTG9k ZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldD4+DQo+ID4g6YCB5L+h5pel5pmCOiDmsLTmm5zml6UsIDEx5pyIIDI4LCAyMDE4IDEx OjM4IOWNiOW+jA0KPiA+IOWum+WFiDogbi1zYWtpbXVyYQ0KPiA+IENjOiBEaWNrIEhhcmR0OyBI YW5uZXMgVHNjaG9mZW5pZzsgb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0K PiA+IOS7tuWQjTogUmU6IFtPQVVUSC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNzIC0tIFJlY29t bWVuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNpdA0KPiA+DQo+ID4gSGkg TmF0LA0KPiA+DQo+ID4+IEFtIDI4LjExLjIwMTggdW0gMjE6MTAgc2NocmllYiBuLXNha2ltdXJh IDxuLXNha2ltdXJhQG5yaS5jby5qcDxtYWlsdG86bi1zYWtpbXVyYUBucmkuY28uanA+PjoNCj4g Pj4NCj4gPj4gSSB3b3VsZCBzdXBwb3J0DQo+ID4+DQo+ID4+IDEpIGNsZWFybHkgZGVmaW5pbmcg SW1wbGljaXQgYXMgdGhlIGZsb3cgdGhhdCByZXR1cm5zIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSBh dXRob3JpemF0aW9uIGVuZHBvaW50ICggc29tZSBwZW9wbGUgY29uZnVzZXMgaW1wbGljaXQgYXMg dGhlIGZsb3cgdGhhdCByZXR1cm5zIElEIFRva2VuIGluIHRoZSBmcm9udCBjaGFubmVsKQ0KPiA+ DQo+ID4gVGhhdOKAmXMgdGhlIGN1cnJlbnQgdGV4dDoNCj4gPg0KPiA+IEluIG9yZGVyIHRvIGF2 b2lkIHRoZXNlIGlzc3VlcywgQ2xpZW50cyBTSE9VTEQgTk9UIHVzZSB0aGUgaW1wbGljaXQNCj4g PiAgICBncmFudCBvciBhbnkgb3RoZXIgcmVzcG9uc2UgdHlwZSBjYXVzaW5nIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciB0bw0KPiA+ICAgIGlzc3VlIGFuIGFjY2VzcyB0b2tlbiBpbiB0aGUgYXV0 aG9yaXphdGlvbiByZXNwb25zZS4NCj4gPg0KPiA+IFdoYXQgd291bGQgeW91IGxpa2UgdG8gbW9k aWZ5Pw0KPiA+DQo+ID4+DQo+ID4+IDIpIEJhbm5pbmcgdGhlIHJldHVybmluZyBvZiB0aGUgYWNj ZXNzIHRva2VuIHRoYXQgYXJlIG5vdCBzZW5kZXIgY29uc3RyYWluZWQgZnJvbSB0aGUgYXV0aG9y aXphdGlvbiBlbmRwb2ludA0KPiA+DQo+ID4gSW4gb3JkZXIgdG8gYXZvaWQgdGhlc2UgaXNzdWVz LCBDbGllbnRzIFNIT1VMRCBOT1QgdXNlIHRoZSBpbXBsaWNpdA0KPiA+ICAgIGdyYW50IG9yIGFu eSBvdGhlciByZXNwb25zZSB0eXBlIGNhdXNpbmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRv DQo+ID4gICAgaXNzdWUgYW4gYWNjZXNzIHRva2VuIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3Bv bnNlLCBpZiB0aGlzIGFjY2VzcyB0b2tlbnMgaXMgbm90IHNlbmRlci1jb25zdHJhaW50Lg0KPiA+ DQo+ID4gV2hhdCBhYm91dCB0aGlzPw0KPiA+DQo+ID4ga2luZCByZWdhcmRzLA0KPiA+IFRvcnN0 ZW4uDQo+ID4NCj4gPj4NCj4gPj4gQmVzdCwNCj4gPj4NCj4gPj4gTmF0DQo+ID4+DQo+ID4+DQo+ ID4+IE91dGxvb2sgZm9yIGlPUyDjgpLlhaXmiYsNCj4gPj4NCj4gPj4g5beu5Ye65Lq6OiBPQXV0 aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4+ IChEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFp bC5jb20+PiDjga7ku6PnkIYpDQo+ID4+IOmAgeS/oeaXpeaZgjog5rC05puc5pelLCAxMeaciCAy OCwgMjAxOCA4OjU4IOWNiOW+jA0KPiA+PiDlrpvlhYg6IEhhbm5lcyBUc2Nob2ZlbmlnDQo+ID4+ IENjOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQo+ID4+IOS7tuWQjTog UmU6IFtPQVVUSC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3Jp emF0aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNpdA0KPiA+Pg0KPiA+PiArMQ0KPiA+Pg0KPiA+ PiBXaGlsZSB0aGVyZSBhcmUgdmFyaW91cyBtZWNoYW5pc21zIHRvIGFsbGV2aWF0ZSBzb21lIG9m IHRoZSBpc3N1ZXMgb2YgaW1wbGljaXQsIEkgZG9uJ3QgdGhpbmsgd2UgY2FuIHJlY29tbWVuZCBz cGVjaWZpY3MsIGFuZCB0aGVyZSBtYXkgYmUgZnV0dXJlIG9uZXMgaW4gdGhlIGZ1dHVyZS4gSSB0 aGluayB3ZSBhbGwgYWdyZWUgdGhhdCBpbXBsaWNpdCB3aXRob3V0IGFueSBtaXRpZ2F0aW9uIGlz IHByb2JsZW1hdGljLg0KPiA+Pg0KPiA+PiBIb3cgYWJvdXQgd2UgcmVjb21tZW5kIGFnYWluc3Qg dXNpbmcgaW1wbGljaXQgYWxvbmU/DQo+ID4+DQo+ID4+DQo+ID4+IE9uIE1vbiwgTm92IDE5LCAy MDE4IGF0IDI6MzQgQU0gSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5j b208bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+PiB3cm90ZToNCj4gPj4gSGkgYWxs LA0KPiA+Pg0KPiA+PiBUaGUgYXV0aG9ycyBvZiB0aGUgT0F1dGggU2VjdXJpdHkgVG9waWNzIGRy YWZ0IGNhbWUgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCBpdCBpcyBub3QgcG9zc2libGUgdG8gYWRl cXVhdGVseSBzZWN1cmUgdGhlIGltcGxpY2l0IGZsb3cgYWdhaW5zdCB0b2tlbiBpbmplY3Rpb24g c2luY2UgcG90ZW50aWFsIHNvbHV0aW9ucyBsaWtlIHRva2VuIGJpbmRpbmcgb3IgSkFSTSBhcmUg aW4gYW4gZWFybHkgc3RhZ2Ugb2YgYWRvcHRpb24uIEZvciB0aGlzIHJlYXNvbiwgYW5kIHNpbmNl IENPUlMgYWxsb3dzIGJyb3dzZXItYmFzZWQgYXBwcyB0byBzZW5kIHJlcXVlc3RzIHRvIHRoZSB0 b2tlbiBlbmRwb2ludCwgVG9yc3RlbiBzdWdnZXN0ZWQgdG8gdXNlIHRoZSBhdXRob3JpemF0aW9u IGNvZGUgaW5zdGVhZCBvZiB0aGUgaW1wbGljaXQgZ3JhbnQgaW4gY2FsbCBjYXNlcyBpbiBoaXMg cHJlc2VudGF0aW9uIChzZWUgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEw My9tYXRlcmlhbHMvc2xpZGVzLTEwMy1vYXV0aC1zZXNzYi1kcmFmdC1pZXRmLW9hdXRoLXNlY3Vy aXR5LXRvcGljcy0wMSkuDQo+ID4+DQo+ID4+IEEgaHVtIGluIHRoZSByb29tIGF0IElFVEYjMTAz IGNvbmNsdWRlZCBzdHJvbmcgc3VwcG9ydCBmb3IgaGlzIHJlY29tbWVuZGF0aW9ucy4gV2Ugd291 bGQgbGlrZSB0byBjb25maXJtIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0Lg0KPiA+Pg0KPiA+ PiBQbGVhc2UgcHJvdmlkZSBhIHJlc3BvbnNlIGJ5IERlY2VtYmVyIDNyZC4NCj4gPj4NCj4gPj4g Q2lhbw0KPiA+Pg0KPiA+PiBIYW5uZXMgJiBSaWZhYXQNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4g SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90 aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUg aW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBPQXV0aCBtYWlsaW5nIGxp c3QNCj4gPj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IE9BdXRoIG1haWxpbmcg bGlzdA0KPiA+PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+ID4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gPg0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWls aW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCi0tDQotLS0tDQpBYXJvbiBQYXJlY2tpDQphYXJvbnBh cmVja2kuY29tPGh0dHA6Ly9hYXJvbnBhcmVja2kuY29tPg0KQGFhcm9ucGs8aHR0cDovL3R3aXR0 ZXIuY29tL2Fhcm9ucGs+DQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlz IGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28g YmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhl IGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9y IHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4N CklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBv dGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhl IGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_VI1PR0801MB211297F33296CA377A40BFFEFAAE0VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAx MSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3Nl LTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1T IEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpoNQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyA1IENoYXIiOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlz dFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSGVhZGluZzVDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIZWFkaW5nIDUgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0 eWxlLWxpbms6IkhlYWRpbmcgNSI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzJGNTQ5Njt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMDAsIGxpLm1zb25vcm1hbDAwLCBk aXYubXNvbm9ybWFsMDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsMDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvY2hwZGVmYXVsdCwgbGkubXNvY2hwZGVm YXVsdCwgZGl2Lm1zb2NocGRlZmF1bHQNCgl7bXNvLXN0eWxlLW5hbWU6bXNvY2hwZGVmYXVsdDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uZW1haWxzdHlsZTE4 DQoJe21zby1zdHlsZS1uYW1lOmVtYWlsc3R5bGUxODsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLmhlYWRpbmc1Y2hhcjANCgl7bXNvLXN0eWxlLW5hbWU6aGVhZGlu ZzVjaGFyOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWZvbnQtd2VpZ2h0 OmJvbGQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTY0MTgwOTQ3 NDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTYxNDA5 NTMwIDY5MDI2NzMwOCAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0 ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3O30NCkBsaXN0IGwwOmxldmVsMQ0K CXttc28tbGV2ZWwtc3RhcnQtYXQ6MzsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTg3MDUzMjY0MTsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTg0OTAxNTc0O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihjaGFpciBoYXQgb2ZmKSA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGkgTmF0LCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlv biA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1z ZWN1cml0eS10b3BpY3MtMTAjc2VjdGlvbi0zLjguMS4yIj4NCjxzcGFuIHN0eWxlPSJ0ZXh0LWRl Y29yYXRpb246bm9uZSI+My44LjEuMjwvc3Bhbj48L2E+IG9mIGRyYWZ0LWlldGYtb2F1dGgtc2Vj dXJpdHktdG9waWNzLTEwICZuYnNwO2xpc3RzIHRoZSBmb2xsb3dpbmcgb3B0aW9ucyBmb3IgaW1w bGVtZW50aW5nIHNlbmRlciBjb25zdHJhaW50IHRva2VuczoNCjxvOnA+PC9vOnA+PC9wPg0KPHVs IHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMi PlRva2VuIEJpbmRpbmc8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5NVExTPG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+U2lnbmVkIEhUVFAgUmVxdWVzdHM8bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5KUE9QPG86cD48L286cD48L2xpPjwvdWw+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkpQT1AgaXMgYW4gaW5kaXZpZHVhbCBzdWJtaXNzaW9uLiBUaGUgd29yayBvbiBz aWduZWQgSFRUUCByZXF1ZXN0cyBzdGFsbGVkLiBUb2tlbiBCaW5kaW5nLCBhcyB3ZSBsZWFybmVk IGF0IHRoZSBsYXN0IElFVEYgbWVldGluZywgaGFzIHNlcmlvdXMgZGVwbG95bWVudCBwcm9ibGVt cy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBlc3NlbnRpYWxs eSBsZWF2ZXMgdXMgd2l0aCBNVExTLiBJIGFtLCBob3dldmVyLCBub3QgZW50aXJlbHkgc3VyZSBN VExTIHdvcmtzIHdlbGwgd2l0aCB0aGUgaW1wbGljaXQgZ3JhbnQuDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+TXkgY29uY2x1c2lvbiBzbyBmYXIgZnJvbSB0aGUgZGlzY3Vzc2lvbiBpcyB0aGF0 IGltcGxpY2l0IGdyYW50IGNhbm5vdCBiZSBzZWN1cmVkIHByYWN0aWNhbGx5Lg0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkZvciBJb1QsIGFzIEkgbWVudGlvbmVkLCB0aGUgc3RvcnkgZG9lcyBu b3QgbG9vayBzbyBncmltIHNpbmNlIHdpdGggSW9UIHByb3RvY29scywgQ29BUCBvciBNUVRULCBv bmUgY2FuIHN0aWxsIHVzZSBUTFMgYXMgd2VsbCBhcyBhcHBsaWNhdGlvbiBsYXllciBzZWN1cml0 eS4gKEF0IGxlYXN0IHRoYXTigJlzIHRoZSBjdXJyZW50IHVuZGVyc3RhbmRpbmcuKTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGFtIGhhcHB5IHRvIGdldCBjb3JyZWN0ZWQuIDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5DaWFvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I YW5uZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBuLXNh a2ltdXJhICZsdDtuLXNha2ltdXJhQG5yaS5jby5qcCZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBT YXR1cmRheSwgRGVjZW1iZXIgMSwgMjAxOCAxMDo0NCBBTTxicj4NCjxiPlRvOjwvYj4gSGFubmVz IFRzY2hvZmVuaWcgJmx0O0hhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20mZ3Q7OyBBYXJvbiBQYXJl Y2tpICZsdDthYXJvbkBwYXJlY2tpLmNvbSZndDs7IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3Rv cnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gRGFuaWVsIEZldHQgJmx0 O2ZldHRAZGFuaWVsZmV0dC5kZSZndDs7IElFVEYgb2F1dGggV0cgJmx0O29hdXRoQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCBTZWN1cml0eSBU b3BpY3MgLS0gUmVjb21tZW5kIGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIGltcGxpY2l0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9BdXRoIE1UTFMgaGFzIGJlZW4gaW1wbGVtZW50ZWQgaW4gQmFu a2luZyBpbmR1c3RyeSBzbyB3ZSBoYXZlIGF0IGxlYXN0IGFuIGFsdGVybmF0aXZlLg0KPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlbmRlciBD b25zdHJhaW5lZCBpbmNsdWRlcyBjYXNlcyB3aGVyZSBpdCBpcyBub3Qga2V5IGJvdW5kIGJ1dCBu YW1lIGJvdW5kIGFzIEkgdW5kZXJzdGFuZCBhbmQgaXQgbWF5IGhhdmUgc29tZSB1dGlsaXR5IHNv IHdlIGYgdGhlcmUgYXJlIGRvdWJ0cywgbWVudGlvbmluZyB0aGUgYm90aCBtYXkgYmUgZ29vZC4N CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vYWthLm1zL28wdWtlZiI+T3V0bG9vayBmb3IgaU9TPC9h PiA8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZx dW90OyI+DQrjgpLlhaXmiYs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWdu OmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8L2Rp dj4NCjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7 Y29sb3I6YmxhY2siPuW3ruWHuuS6ujwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiBPQXV0aCAmbHQ7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2Vz QGlldGYub3JnPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0Ow0KIChIYW5uZXMgVHNj aG9mZW5pZyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0Bhcm0u Y29tIj5oYW5uZXMudHNjaG9mZW5pZ0Bhcm0uY29tPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jmd0Ow0KPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNrIj7jga7ku6PnkIY8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4pPGJyPg0KPC9zcGFuPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNrIj7pgIHkv6Hm l6XmmYI8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Ojwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjayI+5Zyf5puc 5pelPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LCAxMjwvc3Bhbj48c3BhbiBsYW5n PSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpi bGFjayI+5pyIPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IDEsIDIwMTggNjowNw0K PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290 aGljJnF1b3Q7O2NvbG9yOmJsYWNrIj7ljYjlvow8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPuWum+WFiDwvc3Bhbj48L2I+PGI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiBBYXJvbiBQYXJlY2tpOyBUb3JzdGVuIExvZGRlcnN0ZWR0PGJyPg0KPGI+Q2M6PC9i PiBEYW5pZWwgRmV0dDsgSUVURiBvYXV0aCBXRzxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJa SC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFj ayI+5Lu25ZCNPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIFNlY3Vy aXR5IFRvcGljcyAtLSBSZWNvbW1lbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2YgaW1w bGljaXQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGg1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtd2VpZ2h0Om5vcm1hbCI+SSBhZ3JlZSB3aXRoIEFhcm9uIGhlcmUgYW5kIEkgdGhpbmsN CjxhIG5hbWU9InNlY3Rpb24tMy44LjEuMiI+U2VjdGlvbiA8L2E+PC9zcGFuPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6JnF1b3Q7c2VjdGlvbi0zXC44XC4xXC4yJnF1b3Q7Ij48L3NwYW4+PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJp dHktdG9waWNzLTEwI3NlY3Rpb24tMy44LjEuMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC13ZWlnaHQ6bm9ybWFsO3RleHQtZGVjb3JhdGlvbjpub25lIj4zLjguMS4yPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LXdlaWdodDpub3JtYWwiPg0K IG9mIGRyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTEwICZuYnNwO2FscmVhZHkgZG9l cyBhIHByZXR0eSBnb29kIGpvYi4gPC9zcGFuPjxvOnA+PC9vOnA+PC9oNT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgd2FzLCBob3dldmVyLCB3b25kZXJpbmcgYWJvdXQgdGhlIHN1YnRsZSBpbXBs aWNhdGlvbiBvZiB0aGUgcmVxdWlyZW1lbnQgZm9yIHNlbmRlciBjb25zdHJhaW5lZCB0b2tlbnMu IE15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHRva2VuIGJpbmRpbmcgZGlzY3Vzc2lvbiwgd2hpY2gg aXMgb25lIG9mIHRoZSB3YXlzIHRvIHByb3ZpZGUgc2VuZGVyLWNvbnN0cmFpbmVkIHRva2Vucywg aXMgdGhhdCB3ZSBkb27igJl0IGhhdmUNCiBnb29kIGZhaXRoIGluIHNlZWluZyBkZXBsb3ltZW50 IGFueXRpbWUgc29vbi4gSGVuY2UsIHdlIGFyZSBlc3NlbnRpYWxseSAocmVhZGluZyBpbiBiZXR3 ZWVuIHRoZSBsaW5lcyBvZiBTZWN0aW9uIDMuOC4xLjIpIHNheWluZyB0aGF0IHlvdSBjYW5ub3Qg dXNlIGltcGxpY2l0IGdyYW50IGluIGEgcHJhY3RpY2FsIHNldHVwIGZvciB0aGUgd2ViKi48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QW0gSSBtaXN1bmRlcnN0YW5kaW5nIGl0PzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5DaWFvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I YW5uZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UFM6IFRoZSBJb1QgY2FzZSBpcyBsaWtlbHkg ZGlmZmVyZW50LiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IE9BdXRoICZsdDs8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIGxhbmc9IkVOLVVTIj5v YXV0aC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0Ow0K PGI+T24gQmVoYWxmIE9mIDwvYj5BYXJvbiBQYXJlY2tpPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVy ZGF5LCBEZWNlbWJlciAxLCAyMDE4IDM6MTggQU08YnI+DQo8Yj5Ubzo8L2I+IFRvcnN0ZW4gTG9k ZGVyc3RlZHQgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5u ZXQiPjxzcGFuIGxhbmc9IkVOLVVTIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvc3Bhbj48L2E+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8YnI+DQo8Yj5DYzo8L2I+IERhbmllbCBGZXR0ICZsdDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmZldHRAZGFuaWVsZmV0dC5kZSI+PHNwYW4gbGFuZz0iRU4t VVMiPmZldHRAZGFuaWVsZmV0dC5kZTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs7 IElFVEYgb2F1dGggV0cgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci PjxzcGFuIGxhbmc9IkVOLVVTIj5vYXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0i RU4tVVMiPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggU2Vj dXJpdHkgVG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiBp bXBsaWNpdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQz OzE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHdvdWxkIGFsc28gbGlrZSB0byBlbnN1cmUgdGhlcmUgaXMgYSBjbGVhciBkZWZp bml0aW9uIG9mICZxdW90O3NlbmRlciBjb25zdHJhaW5lZCZxdW90OyB0b2tlbnMgaW4gdGhpcyBC Q1AuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFhcm9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUaHUsIE5vdiAyOSwgMjAxOCBhdCAxMDowNiBBTSBUb3JzdGVuIExvZGRlcnN0ZWR0 ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiPnRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGkgYWxsLCA8YnI+DQo8YnI+DQpiYXNlZCBvbiB5b3VyIGZlZWRiYWNrIG9uIHRo ZSBsaXN0IGFuZCBvZmYgbGlzdCwgRGFuaWVsIGFuZCBJIHBvbGlzaGVkIHRoZSB0ZXh0LiBUaGF0 4oCZcyBvdXIgcHJvcG9zYWw6PGJyPg0KPGJyPg0K4oCUPGJyPg0KSW4gb3JkZXIgdG8gYXZvaWQg dGhlc2UgaXNzdWVzLCBjbGllbnRzIE1VU1QgTk9UIHVzZSB0aGUgaW1wbGljaXQ8YnI+DQpncmFu dCAocmVzcG9uc2UgdHlwZSAmcXVvdDt0b2tlbiZxdW90Oykgb3IgYW55IG90aGVyIHJlc3BvbnNl IHR5cGUgaXNzdWluZyBhY2Nlc3MgPGJyPg0KdG9rZW5zIGluIHRoZSBhdXRob3JpemF0aW9uIHJl c3BvbnNlLCBzdWNoIGFzICZxdW90O3Rva2VuIGlkX3Rva2VuJnF1b3Q7IGFuZCAmcXVvdDtjb2Rl IHRva2VuIGlkX3Rva2Vu4oCcLA0KPGJyPg0KdW5sZXNzIHRoZSBpc3N1ZWQgYWNjZXNzIHRva2Vu cyBhcmUgc2VuZGVyLWNvbnN0cmFpbmVkIGFuZCBhY2Nlc3MgdG9rZW4gaW5qZWN0aW9uIGluDQo8 YnI+DQp0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSBpcyBwcmV2ZW50ZWQuIDxicj4NCuKAlDxi cj4NCjxicj4NCkV4cGxhbnRhdGlvbjogPGJyPg0KLSB3ZSB3YW50ZWQgdG8gaGF2ZSB0aGUgcmln aHQgYmFsYW5jZSBiZXR3ZWVuIGEgZ2VuZXJpYyBkZWZpbml0aW9uIG9mIHRoZSByZXNwb25zZSB0 eXBlcyB3ZSBkbyBub3QgcmVjb21tZW5kL2FsbG93IHRvIGJlIHVzZWQgYW5kIGEgY29uY3JldGUv YWN0aW9uYWJsZSBsaXN0IG9mIHRoZSBhZmZlY3RlZCByZXNwb25zZSB0eXBlcy4NCjxicj4NCi0g d2UgY2hhbmdlZCBmcm9tIFNIT1VMRCBOT1QgdG8gTVVTVCBOT1QgYXMgc3VnZ2VzdGVkIGJ5IE5h dCBhbmQgc3VwcG9ydGVkIGJ5IFdpbGxpYW08YnI+DQo8YnI+DQpXZSBsb29rIGZvcndhcmQgdG8g c2VlaW5nIHlvdXIgZmVlZGJhY2suPGJyPg0KPGJyPg0Ka2luZCByZWdhcmRzLDxicj4NClRvcnN0 ZW4uJm5ic3A7IDxicj4NCjxicj4NCiZndDsgQW0gMjkuMTEuMjAxOCB1bSAxNToxNSBzY2hyaWVi IEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJn ZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0Ozo8YnI+DQomZ3Q7IDxicj4NCiZn dDsgSSBhbSBvayB3aXRoIHRoYXQuJm5ic3A7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBXZWQs IE5vdiAyOCwgMjAxOCwgODowMyBQTSBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVmPSJt YWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVuQGxv ZGRlcnN0ZWR0Lm5ldDwvYT4gd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgQW0gMjgu MTEuMjAxOCB1bSAyMzo1MCBzY2hyaWViIG4tc2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpu LXNha2ltdXJhQG5yaS5jby5qcCIgdGFyZ2V0PSJfYmxhbmsiPm4tc2FraW11cmFAbnJpLmNvLmpw PC9hPiZndDs6PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGF0IHdvcmtzLjxicj4N CiZndDsgPGJyPg0KJmd0OyBHb29kITxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGp1c3QgcmVhbGl6 ZWQgdGhpcyB0ZXh0IGhhcyBhbiBpc3N1ZSB3aXRoIOKAnnRva2Vu4oCcIChvbmx5KS4gSXQgd291 bGQgYWxsb3cg4oCedG9rZW7igJwgdG8gYmUgdXNlZCBpZiB0aGUgdG9rZW4gd291bGQgc2VuZGVy IGNvbnN0cmFpbmVkLiBUaGlzIGNvbXBsZXRlbHkgaWdub3JlcyB0aGUgZmFjdCBpbXBsaWNpdCBh bHNvIHNoYWxsIGJlIGFiYW5kb25lZCBiZWNhdXNlIG9mIGl0cyB2dWxuZXJhYmlsaXR5IGZvciBh Y2Nlc3MgdG9rZW4gaW5qZWN0aW9uLg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgdGhlcmVmb3Jl IHByb3Bvc2UgYSBtb2RpZmllZCB0ZXh0OiA8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5i c3A7IEluIG9yZGVyIHRvIGF2b2lkIHRoZXNlIGlzc3VlcywgQ2xpZW50cyBTSE9VTEQgTk9UIHVz ZSB0aGUgaW1wbGljaXQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBncmFudC4gRnVydGhlcm1vcmUs IGNsaWVudHMgU0hPVUxEIG9ubHkgdXNlIG90aGVyIHJlc3BvbnNlIHR5cGVzIGNhdXNpbmcgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIHRvPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgaXNzdWUgYW4g YWNjZXNzIHRva2VuIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlLCBpZiB0aGUgcGFydGlj dWxhciByZXNwb25zZSB0eXBlIGRldGVjdHMgYWNjZXNzIHRva2VuDQo8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyBpbmplY3Rpb24gYW5kIHRoZSBpc3N1ZWQgYWNjZXNzIHRva2VucyBhcmUgc2VuZGVy LWNvbnN0cmFpbmVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBPciB3ZSBqdXN0IHN0YXRlOjxicj4N CiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtJbiBvcmRlciB0byBhdm9pZCB0aGVzZSBpc3N1 ZXMsIENsaWVudHMgU0hPVUxEIE5PVCB1c2UgdGhlIHJlc3BvbnNlIHR5cGUg4oCedG9rZW4mcXVv dDsuIFRoZSByZXNwb25zZSB0eXBlczxicj4NCiZndDsg4oCedG9rZW4gaWRfdG9rZW7igJwgYW5k IOKAnmNvZGUgdG9rZW4gaWRfdG9rZW7igJwgU09VTEQgTk9UIGJlIHVzZWQsIGlmIHRoZSBpc3N1 ZWQgYWNjZXNzIHRva2VucyBhcmUgbm90DQo8YnI+DQomZ3Q7IHNlbmRlci1jb25zdHJhaW5lZC48 YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSW4gZmFjdCwgSSB3b3Vs ZCBmdXJ0aGVyIGdvIGFuZCBzYXkgTVVTVCBOT1QgYnV0IHRoYXQgcHJvYmFibHkgaXMgdG9vIG11 Y2ggZm9yIGEgc2VjdXJpdHkgY29uc2lkZXJhdGlvbi48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IE1pa2Ugc3VnZ2VzdGVkIHRvIGdvIHdpdGggYSBTSE9VTEQgTk9UIHRvIGdl dCB0aGUgbWVzc2FnZSBvdXQgYnV0IGdpdmUgaW1wbGVtZW50b3JzIHRpbWUgdG8gbW92ZS9jaGFu Z2UuPGJyPg0KPHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj4mZ3Q7IDxicj4N CiZndDsgJmd0OyBCZXN0LDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTmF0PGJyPg0K Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBOYXQgU2FraW11cmEgLyA8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOm4tc2FraW11cmFAbnJpLmNvLmpwIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj5uLXNha2ltdXJhQG5yaS5jby5qcDwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj4gLyAmIzQzOzgxLTkwLTYwMTMt NjI3Njxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkpB IiBzdHlsZT0iZm9udC1mYW1pbHk6RGVuZ1hpYW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPuOB k+OBruODoeODvOODq+OBq+OBr+OAgeacrOadpeOBruWum+WFiOOBruaWueOBruOBv+OBq+mZkOWu muOBleOCjOOBn+apn+WvhuaDheWgseOBjOWQq+OBvuOCjOOBpuOBhOOCi+WgtOWQiOOBjOOBlOOB luOBhOOBvuOBmeOAguOBiuW/g+OBguOBn+OCiuOBruOBquOBhOWgtOWQiOOBr+OAgeiqoOOBq+eU s+OBl+ios+OBlOOBluOBhOOBvuOBm+OCk+OBjOOAgemAgeS/oeiAheOBvuOBp+OBiuefpeOCieOB m+mgguOBjeOAgeOBvuOBn+WPl+S/oeOBleOCjOOBn+ODoeODvOODq+OBr+WJiumZpOOBl+OBpuOB j+OBoOOBleOBhOOBvuOBmeOCiOOBhuOBiumhmOOBhOeUs+OBl+S4iuOBkuOBvuOBmeOAgjwvc3Bh bj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPjxicj4NCjwvc3Bhbj4mZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFBMRUFTRSBSRUFEIDpUaGlzIGUtbWFpbCBpcyBjb25maWRl bnRpYWwgYW5kIGludGVuZGVkIGZvciB0aGUgbmFtZWQgcmVjaXBpZW50IG9ubHkuPGJyPg0KJmd0 OyAmZ3Q7IElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBlLW1haWwuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 IDxicj4NCiZndDsgJmd0OyA8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OkRl bmdYaWFuIj7lt67lh7rkuro8L3NwYW4+OiBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVm PSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVu QGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDxzcGFuIGxhbmc9IlpILUNO IiBzdHlsZT0iZm9udC1mYW1pbHk6RGVuZ1hpYW4iPumAgeS/oeaXpeaZgjwvc3Bhbj46IDxzcGFu IGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6RGVuZ1hpYW4iPg0K5rC05puc5pelPC9z cGFuPiwgMTE8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OkRlbmdYaWFuIj7m nIg8L3NwYW4+IDI4LCAyMDE4IDExOjM4DQo8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OkRlbmdYaWFuIj7ljYjlvow8L3NwYW4+PGJyPg0KJmd0OyAmZ3Q7IDxzcGFuIGxhbmc9 IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6RGVuZ1hpYW4iPuWum+WFiDwvc3Bhbj46IG4tc2Fr aW11cmE8YnI+DQomZ3Q7ICZndDsgQ2M6IERpY2sgSGFyZHQ7IEhhbm5lcyBUc2Nob2ZlbmlnOyA8 YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCm9hdXRoQGll dGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyA8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OkRlbmdYaWFuIj7ku7blkI08L3NwYW4+OiBSZTogW09BVVRILVdHXSBPQXV0aCBTZWN1 cml0eSBUb3BpY3MgLS0gUmVjb21tZW5kIGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIGlt cGxpY2l0PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0OyBIaSBOYXQsIDxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IEFtIDI4LjExLjIwMTggdW0gMjE6MTAgc2No cmllYiBuLXNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86bi1zYWtpbXVyYUBucmkuY28uanAi IHRhcmdldD0iX2JsYW5rIj5uLXNha2ltdXJhQG5yaS5jby5qcDwvYT4mZ3Q7Ojxicj4NCiZndDsg Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJIHdvdWxkIHN1cHBvcnQ8YnI+DQomZ3Q7ICZn dDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgMSkgY2xlYXJseSBkZWZpbmluZyBJbXBsaWNpdCBh cyB0aGUgZmxvdyB0aGF0IHJldHVybnMgYWNjZXNzIHRva2VuIGZyb20gdGhlIGF1dGhvcml6YXRp b24gZW5kcG9pbnQgKCBzb21lIHBlb3BsZSBjb25mdXNlcyBpbXBsaWNpdCBhcyB0aGUgZmxvdyB0 aGF0IHJldHVybnMgSUQgVG9rZW4gaW4gdGhlIGZyb250IGNoYW5uZWwpPGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyBUaGF04oCZcyB0aGUgY3VycmVudCB0ZXh0OiA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IEluIG9yZGVyIHRvIGF2b2lkIHRoZXNlIGlzc3VlcywgQ2xpZW50 cyBTSE9VTEQgTk9UIHVzZSB0aGUgaW1wbGljaXQ8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7 IGdyYW50IG9yIGFueSBvdGhlciByZXNwb25zZSB0eXBlIGNhdXNpbmcgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyIHRvPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBpc3N1ZSBhbiBhY2Nlc3Mg dG9rZW4gaW4gdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UuPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBXaGF0IHdvdWxkIHlvdSBsaWtlIHRvIG1vZGlmeT8gPGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAyKSBCYW5uaW5nIHRoZSBy ZXR1cm5pbmcgb2YgdGhlIGFjY2VzcyB0b2tlbiB0aGF0IGFyZSBub3Qgc2VuZGVyIGNvbnN0cmFp bmVkIGZyb20gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQ8YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7IEluIG9yZGVyIHRvIGF2b2lkIHRoZXNlIGlzc3VlcywgQ2xpZW50cyBTSE9VTEQg Tk9UIHVzZSB0aGUgaW1wbGljaXQ8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IGdyYW50IG9y IGFueSBvdGhlciByZXNwb25zZSB0eXBlIGNhdXNpbmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy IHRvPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gaW4g dGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIGlmIHRoaXMgYWNjZXNzIHRva2VucyBpcyBub3Qg c2VuZGVyLWNvbnN0cmFpbnQuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBXaGF0IGFi b3V0IHRoaXM/PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBraW5kIHJlZ2FyZHMsPGJy Pg0KJmd0OyAmZ3Q7IFRvcnN0ZW4uPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsg PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBCZXN0LDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAm Z3Q7Jmd0OyBOYXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBPdXRsb29rIGZvciBpT1MgPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJm b250LWZhbWlseTpEZW5nWGlhbiI+44KS5YWl5omLPC9zcGFuPjxicj4NCiZndDsgJmd0OyZndDsm bmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OkRlbmdYaWFuIj7lt67lh7rkuro8L3NwYW4+OiBPQXV0aCAmbHQ7PGEgaHJlZj0ibWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2Vz QGlldGYub3JnPC9hPiZndDsgKERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhh cmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZn dDsNCjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6RGVuZ1hpYW4iPuOBruS7 o+eQhjwvc3Bhbj4pPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9 ImZvbnQtZmFtaWx5OkRlbmdYaWFuIj7pgIHkv6Hml6XmmYI8L3NwYW4+OiA8c3BhbiBsYW5nPSJa SC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OkRlbmdYaWFuIj4NCuawtOabnOaXpTwvc3Bhbj4sIDEx PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+5pyIPC9zcGFu PiAyOCwgMjAxOCA4OjU4DQo8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OkRl bmdYaWFuIj7ljYjlvow8L3NwYW4+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8c3BhbiBsYW5nPSJaSC1D TiIgc3R5bGU9ImZvbnQtZmFtaWx5OkRlbmdYaWFuIj7lrpvlhYg8L3NwYW4+OiBIYW5uZXMgVHNj aG9mZW5pZzxicj4NCiZndDsgJmd0OyZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyZn dDsgPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpEZW5nWGlhbiI+5Lu25ZCN PC9zcGFuPjogUmU6IFtPQVVUSC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNzIC0tIFJlY29tbWVu ZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNpdDxicj4NCiZndDsgJmd0OyZn dDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmIzQzOzE8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxi cj4NCiZndDsgJmd0OyZndDsgV2hpbGUgdGhlcmUgYXJlIHZhcmlvdXMgbWVjaGFuaXNtcyB0byBh bGxldmlhdGUgc29tZSBvZiB0aGUgaXNzdWVzIG9mIGltcGxpY2l0LCBJIGRvbid0IHRoaW5rIHdl IGNhbiByZWNvbW1lbmQgc3BlY2lmaWNzLCBhbmQgdGhlcmUgbWF5IGJlIGZ1dHVyZSBvbmVzIGlu IHRoZSBmdXR1cmUuIEkgdGhpbmsgd2UgYWxsIGFncmVlIHRoYXQgaW1wbGljaXQgd2l0aG91dCBh bnkgbWl0aWdhdGlvbiBpcyBwcm9ibGVtYXRpYy4NCjxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBIb3cgYWJvdXQgd2UgcmVjb21tZW5kIGFnYWluc3QgdXNpbmcgaW1wbGlj aXQgYWxvbmU/IDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQom Z3Q7ICZndDsmZ3Q7IE9uIE1vbiwgTm92IDE5LCAyMDE4IGF0IDI6MzQgQU0gSGFubmVzIFRzY2hv ZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tIiB0YXJn ZXQ9Il9ibGFuayI+SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4N CiZndDsgJmd0OyZndDsgSGkgYWxsLDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBUaGUgYXV0aG9ycyBvZiB0aGUgT0F1dGggU2VjdXJpdHkgVG9waWNzIGRyYWZ0IGNhbWUg dG8gdGhlIGNvbmNsdXNpb24gdGhhdCBpdCBpcyBub3QgcG9zc2libGUgdG8gYWRlcXVhdGVseSBz ZWN1cmUgdGhlIGltcGxpY2l0IGZsb3cgYWdhaW5zdCB0b2tlbiBpbmplY3Rpb24gc2luY2UgcG90 ZW50aWFsIHNvbHV0aW9ucyBsaWtlIHRva2VuIGJpbmRpbmcgb3IgSkFSTSBhcmUgaW4gYW4gZWFy bHkgc3RhZ2Ugb2YgYWRvcHRpb24uIEZvciB0aGlzDQogcmVhc29uLCBhbmQgc2luY2UgQ09SUyBh bGxvd3MgYnJvd3Nlci1iYXNlZCBhcHBzIHRvIHNlbmQgcmVxdWVzdHMgdG8gdGhlIHRva2VuIGVu ZHBvaW50LCBUb3JzdGVuIHN1Z2dlc3RlZCB0byB1c2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBp bnN0ZWFkIG9mIHRoZSBpbXBsaWNpdCBncmFudCBpbiBjYWxsIGNhc2VzIGluIGhpcyBwcmVzZW50 YXRpb24gKHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5n LzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEwMy1vYXV0aC1zZXNzYi1kcmFmdC1pZXRmLW9hdXRoLXNl Y3VyaXR5LXRvcGljcy0wMSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEwMy1vYXV0aC1zZXNzYi1kcmFm dC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0wMTwvYT4pLjxicj4NCiZndDsgJmd0OyZndDsg PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBBIGh1bSBpbiB0aGUgcm9vbSBhdCBJRVRGIzEwMyBjb25jbHVk ZWQgc3Ryb25nIHN1cHBvcnQgZm9yIGhpcyByZWNvbW1lbmRhdGlvbnMuIFdlIHdvdWxkIGxpa2Ug dG8gY29uZmlybSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdC48YnI+DQomZ3Q7ICZndDsmZ3Q7 IDxicj4NCiZndDsgJmd0OyZndDsgUGxlYXNlIHByb3ZpZGUgYSByZXNwb25zZSBieSBEZWNlbWJl ciAzcmQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IENpYW88YnI+DQom Z3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgSGFubmVzICZhbXA7IFJpZmFhdDxicj4N CiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsm Z3Q7IDxicj4NCiZndDsgJmd0OyZndDsgSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9m IHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkg YWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9z ZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkNCiBwdXJw b3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFu ayB5b3UuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZn dDsgJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7ICZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyZn dDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhA aWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1h aWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxi cj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QWFyb24gUGFyZWNraTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL2Fhcm9ucGFyZWNraS5jb20i IHRhcmdldD0iX2JsYW5rIj5hYXJvbnBhcmVja2kuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3R3aXR0ZXIu Y29tL2Fhcm9ucGsiIHRhcmdldD0iX2JsYW5rIj5AYWFyb25wazwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1QT1JUQU5U IE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBh cmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv biwNCiB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1h dGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQg YW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVn ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0 byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLA0KIG9yIHN0b3JlIG9y IGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_VI1PR0801MB211297F33296CA377A40BFFEFAAE0VI1PR0801MB2112_-- From nobody Mon Dec 3 02:19:21 2018 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 5FA52130E19 for ; Mon, 3 Dec 2018 02:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=ve7jtb-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 MwqMIdz2CITd for ; Mon, 3 Dec 2018 02:19:17 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 27A0C130DDA for ; Mon, 3 Dec 2018 02:19:17 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id s14so5147711wmh.1 for ; Mon, 03 Dec 2018 02:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JnjxzSZmuuWC7Dj9GWu5G23cbdkfZ94K6jDgl5KT+wQ=; b=o59AuVJm4YY7+Jd43Qe5OVuvXDlyqdNls7zOPgrwjrlDjAs3LnVxyPngshuaqxrJBi lUSwOEbqSmpS9MfewkpQ+ZZ+yDfD83hQLTPHHsbj1y3Vl/Fsamb9foK9krCgmSOQa68f ffaUtU6vY58YHPU7EkAbvTgdR5xdUE0/JXeQvJ1+93j+xyewpSOgev8A6uLEyxgyT46V Rs/WjXrdZitNupBbcAnL1ifTjE9kHorO2n7rDG9/RK9t3Ekh/iQ0Xyowe8RukVe00+hj UeQT9SNGkvGNIVc19Qjyck1v4xHa4UKAoNMGzS98NO/XZQBYvcmpV8X5gi+n1djdcJ/e HZ8A== 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=JnjxzSZmuuWC7Dj9GWu5G23cbdkfZ94K6jDgl5KT+wQ=; b=fwNC9Ri0ccWxErIogxN1NJmZgMlTkEiDNhCNKwRp+slx3Nk+HNyYRdannQpMqDqlke +owhEFTDPDomyImiEPaxVqZ8NvgtUhJaSgMyVMIMH3sg8R7YWPf3ZcDyrBoffRPEvwwV H7unjjiZRlpQfctrHPXdaFo/fQyarh5sp9zg1y1OiHJV7AQpPbzx/CJ8f19KhLvkqqow DzViEdFthDNhW1nINcgb40QZ6bCuvS7TqazDDi1fQ+4Bi/CqvS/b8cxeWjRFOGjLZ56c p+rqCEMcjJm9daj+c8AzmamO0DTCYJPTQHAyInUnm5VV6ZSUyjk1srIoZbxSafwHWmHG nwyw== X-Gm-Message-State: AA+aEWYQsOtfhcSDSmbiP5lKOecH7fd1gjRwyWxzfyLhkG2Oi0JmHcGb cHIIVNHOMjkYuC+IjPeBJfvOrIiDaKWc9FsWRwEFRIeWtVg= X-Google-Smtp-Source: AFSGD/U2snpz50lLYC4HxzaIKu9VFH2TBVb1anQfXVyCe3EYCpF8Dc6uTyuxtbvOMf6cyIcFKOBdEV0KUwp9z5u4rfI= X-Received: by 2002:a7b:c1d7:: with SMTP id a23mr7309627wmj.48.1543832354932; Mon, 03 Dec 2018 02:19:14 -0800 (PST) MIME-Version: 1.0 References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> In-Reply-To: From: John Bradley Date: Mon, 3 Dec 2018 11:19:06 +0100 Message-ID: To: Aaron Parecki Cc: Torsten Lodderstedt , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000001bdcfe057c1b7bb8" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 03 Dec 2018 10:19:20 -0000 --0000000000001bdcfe057c1b7bb8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is my point. >From a security perspective we have a server based confidential client. The fact that it has a angular or other JS UI protected by a cookie seems to not be especially relucent to OAuth. Perhaps from the developer point of view they have a JS SPA and the only difference to them is in one case they are including the OAuth client and in the other they are using a server based proxy. So they see it as the same. Perhaps it is perspective. On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki In this type of deployment, as far as OAuth is concerned, isn't the > backend web server a confidential client? Is there even anything unique t= o > this situation as far as OAuth security goes? > > I wouldn't have expected an Angular app that talks to its own server > backend that's managing OAuth credentials to fall under the umbrella of > this BCP. > > ---- > Aaron Parecki > aaronparecki.com > > > > On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> the UI is rendered in the frontend, UI control flow is in the frontend. >> just a different cut through the web app=E2=80=99s layering >> >> All Angular apps I have seen so far work that way. And it makes a lot of >> sense to me. The backend can aggregate and optimize access to the >> underlying services without the need to fully expose them. >> >> Am 02.12.2018 um 00:44 schrieb John Bradley : >> >> How is that different from a regular server client with a web interface >> if the backed is doing the API calls to the RS? >> >> >> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: >> >> I forgot to mention another (architectural) option: split an application >> into frontend provided by JS in the browser and a backend, which takes c= are >> of the business logic and handles tokens and API access. Replay detectio= n >> at the interface between SPA and backend can utilize standard web >> techniques (see OWASP). The backend in turn can use mTLS for sender >> constraining. >> >> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt < >> torsten@lodderstedt.net>: >> >> IMHO the best mechanism at hand currently to cope with token >> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay >> detection) and issue short living and privilege restricted access tokens= . >> >> Sender constrained access tokens in SPAs need adoption of token binding >> or alternative mechanism. mtls could potentially work in deployments wit= h >> automated cert rollout but browser UX and interplay with fetch needs som= e >> work. We potentially must consider to warm up application level PoP >> mechanisms in conjunction with web crypto. Another path to be evaluated >> could be web auth. >> >> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig < >> Hannes.Tschofenig@arm.com>: >> >> I share the concern Brian has, which is also the conclusion I came up >> with in my other email sent a few minutes ago. >> >> >> >> *From:* OAuth *On Behalf Of *Brian Campbell >> *Sent:* Friday, November 30, 2018 11:43 PM >> *To:* Torsten Lodderstedt >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 >> >> >> >> >> >> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >> > Am 15.11.2018 um 23:01 schrieb Brock Allen : >> > >> > So you mean at the resource server ensuring the token was really issue= d >> to the client? Isn't that an inherent limitation of all bearer tokens >> (modulo HTTP token binding, which is still some time off)? >> >> Sure. That=E2=80=99s why the Security BCP recommends use of TLS-based me= thods for >> sender constraining access tokens ( >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-= 2..2). >> Token Binding for OAuth ( >> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08 >> ) as >> well as Mutual TLS for OAuth ( >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options >> available. >> >> >> >> Unfortunately even when using the token endpoint, for SPA / in-browser >> client applications, the potential mechanisms for sender/key-constrainin= g >> access tokens don't work very well or maybe don't work at all. So I don'= t >> know that the recommendation is very realistic. >> >> >> >> >> *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 send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> 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 t= he >> information in any medium. Thank you. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> _______________________________________________ >> 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 >> > --0000000000001bdcfe057c1b7bb8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is my point.=C2=A0=C2=A0

=
From a security perspective we have a server based confid= ential client.=C2=A0 =C2=A0The fact that it has a angular or other JS UI pr= otected by a cookie seems to not be especially relucent to OAuth.=C2=A0=C2= =A0

Perhaps from the dev= eloper point of view they have a JS SPA and the only difference to them is = in one case they are including the OAuth client and in the other they are u= sing a server based proxy. So they see it as the same.

Perhaps it is perspective.=C2=A0
=
On Mon, Dec 3, 2018, 12:44 = AM Aaron Parecki <aaron@parecki.com= wrote:
In thi= s type of deployment, as far as OAuth is concerned, isn't the backend w= eb server a confidential client? Is there even anything unique to this situ= ation as far as OAuth security goes?=C2=A0

I wouldn'= t have expected an Angular app that talks to its own server backend that= 9;s managing OAuth credentials to fall under the umbrella of this BCP.
=
----
Aaron Pa= recki



On Sat, Dec= 1, 2018 at 11:31 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20 =20 =20 =20

How is that different from a regular server client with a web interface if the backed is doing the API calls to the RS?


On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
=20
I forgot to mention another (architectural) option: split an application into frontend provided by JS in the browser and a backend, which takes care of the business logic and handles tokens and API access. Replay detection at the interface between SPA and backend can utilize standard web techniques (see OWASP). The backend in turn can use mTLS for sender constraining.

Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <torsten= @lodderstedt.net>:

=20
IMHO the best mechanism at hand currently to cope with token leakage/replay in SPAs is to use refresh tokens (rotating w/ replay detection) and issue short living and privilege restricted access tokens.

Sender constrained access tokens in SPAs need adoption of token binding or alternative mechanism. mtls could potentially work in deployments with automated cert rollout but browser UX and interplay with fetch needs some work. We potentially must consider to warm up application level PoP mechanisms in conjunction with web crypto. Another path to be evaluated could be web auth.

Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <Han= nes.Tschofenig@arm.com>:

=20 =20 =20

I share the concern Brian has, which is also the conclusion I came up with in my other email sent a few minutes ago.

=C2=A0

From:= OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
Sent: Friday, November 30, 2018 11:43 PM
To: Torsten Lodderstedt <torsten@lodders= tedt.net>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00=

=C2=A0

= =C2=A0

On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <torsten@lodderstedt= .net> wrote:

> Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.com&= gt;:
>
> So you mean at the resource server ensuring the token was really issued to the client? Isn'= t that an inherent limitation of all bearer tokens (modulo HTTP token binding, which is still some time off)?

Sure. That=E2=80=99s why the Security BCP recommend= s use of TLS-based methods for sender constraining access tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topic= s-09#section-2..2). Token Binding for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options available.

=C2=A0

Unfortunately even when using the token endpoint, for SPA / in-browser client applications, the potential mechanisms for sender/key-constraining access tokens don't wor= k very well or maybe don't work at all. So I don&= #39;t know that the recommendation is very realistic.

=C2=A0


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..=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 attachments from your computer. Thank you.

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 the information in any medium. Thank you.
____________________________________________= ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th

_______________________________________________
OAuth mailing list
O=
Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=20
_______= ________________________________________
OAuth mailing list=
OAuth@ietf.org
https://w= ww.ietf.org/mailman/listinfo/oauth
_= ______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000001bdcfe057c1b7bb8-- From vittorio.bertocci@auth0.com Sun Dec 2 20:14:38 2018 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 CCAC91277C8 for ; Sun, 2 Dec 2018 20:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.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 D9Ca-B0dHucp for ; Sun, 2 Dec 2018 20:14:35 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 6B11A127133 for ; Sun, 2 Dec 2018 20:14:34 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id 83-v6so10004873ljf.10 for ; Sun, 02 Dec 2018 20:14:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TskD8Io26hIGldM2Gk5nsZ35mbKbzf6tqxiW7/mh9Qc=; b=HhE/vREU1w3T6edkaq2u0l96PA2FU8zZH9u4tg9H9cfesbK9p1PkDqc2sGebL+YSvR dVf7SmDYa2IKJ16qySeQJOqTujOwinnHX25HLSgNXp/sg7SW4UjV4f9R2hzapu4fi2AG L/O/28uelAv59Vh1pHMxzPZhub7qX192vPIBhR4yIb3vOlwT5PgrrJs8yUO/EdGs1JTl 5SiSKn8+XbiLWLowjsCyGF7mulJB/Vl3J6ttYzoAf295m9ynpZ8W0JOwG26kV0id/dK3 Wy4E26+MYNkSS6NA6pCFKlx+dx80RPJhzW4tJIXUO57bzhb7egEoTxsiOTy4ylJX19Nb xeiA== 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=TskD8Io26hIGldM2Gk5nsZ35mbKbzf6tqxiW7/mh9Qc=; b=YogTx0hn+GlsohZIP/2zHg1D1ESnWSr9bsueBRbXSzw3xqTABdL7q4lt5Z50/GH+be ahdXVCT/6mnNf6wPxXhuPQDeAtFHBp0mKhk3GJm9LPTrQhRsJ8ALhBXBN4xvXhsBLTht 9SmhQwVjl4dzKSQdv9YfYs9FWGVGsCoFQ/qDdXj6aiMw4w2IUw/fY7y0MQEzbbSj64r4 IUVweoWFDYmAGp7/WMM8UtADpEpxCH1GyHfLuNDwvrwWdrB11bMSWtw/eh8QnVoGHQf2 faUsnwQ0AmUCCol4P8USkvx/isd54aTJth4NbjQtWxNtN02aGRyg0YKrbizWWg99Mbx1 Xhdg== X-Gm-Message-State: AA+aEWah8tuIuzRDhA2E2Ly4116vFt03bPD+FndCZa73zzGBv+AZF+fs PAQn7xj2f+Wu71C5Rdf21Y4f7kTZyaxwge18uP0ulQ== X-Google-Smtp-Source: AFSGD/Xj75HMl27OWiePK6B3z/AcN5kQyOlWC3CZC6bTNIhgclUBGbw3h8+ewTXHEJFm/xLQUaiIzAYo/mKaNSbepo0= X-Received: by 2002:a2e:302:: with SMTP id 2-v6mr3946929ljd.137.1543810472182; Sun, 02 Dec 2018 20:14:32 -0800 (PST) MIME-Version: 1.0 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> In-Reply-To: From: Vittorio Bertocci Date: Sun, 2 Dec 2018 20:14:19 -0800 Message-ID: To: Torsten Lodderstedt Cc: Daniel Fett , Hannes Tschofenig , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000cb9be0057c1662f0" Archived-At: X-Mailman-Approved-At: Mon, 03 Dec 2018 02:59:30 -0800 Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 03 Dec 2018 04:23:13 -0000 --000000000000cb9be0057c1662f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Sorry for stepping a bit back from the level of detail the discussion already reached. I do have some specific comments on the document, but before bringing those up I wanted to raise a general problem I am experiencing with this initiative. I have a number of customers that are reacting to the news with distress. The language used in some of the communications associated with this initiative made them feel like some new vulnerability was discovered, calling for immediate action. The fact is that as far as I can tell, no new, previously unknown fact informed this decision: no new vulnerability, nor any new technology that wasn=E2=80=99t available before (the sender constrain is still not actionab= le for most customers). The risks of the implicit flow aren=E2=80=99t bigger now t= han they were in October. That doesn=E2=80=99t mean that we cannot improve guidance, of course- and n= ow is as good as any other moment to do so: but at the same time, I think we need to be cognizant of the *immense* investment in existence today in form of SDKs and applications built on those SDKs that are predicated on implicit flow, with our blessing: until very recently the official position was =E2=80=9Ci= mplicit is bad but it=E2=80=99s the best we have noawadays=E2=80=9D. To me, being cognizant of that means that we should help people to formulate action proportionate to the risk. And if until yesterday we were ok with them using implicit, we cannot realistically expect anyone to start changing all of their apps today, but that=E2=80=99s the message many custo= mers are getting. TL;DR, I think the community would be well served by clarifying in the security document that there is no new risk and their existing codebase didn=E2=80=99t suddenly become less secure and in *urgent* need to update. To attempt a metaphor. We discovered a new drug against headache with milder side effects than the one we were prescribing them until now, but that doesn=E2=80=99t mean that they should throw away all the stash they ha= ve of the older drug. The old drug will keep working as it worked until now. Once they run out of their stash, they should get the new one; or if the old side effects were particularly bad for them, perhaps they should consider switching today. But this isn=E2=80=99t a recall. And if in fact this group thinks it should be a recall and get everyone off the old one right now, I think we=E2=80=99ll need to make a much stronger c= ase than we have done so far. Thoughts? Thanks V. On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt wrote: > Hi Hannes, > > > Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig < > Hannes.Tschofenig@arm.com>: > > > > I agree with Aaron here and I think Section 3.8.1.2 of > draft-ietf-oauth-security-topics-10 already does a pretty good job. > > my proposal is to add the following definition (based on 3.8.1.2) to a ne= w > =E2=80=9ETerminology" section or to section 2.1.2: > > A sender constrained access token scopes the applicability of an access > token to a certain sender. This sender is > obliged to demonstrate knowledge of a certain secret as prerequisite for > the acceptance of that token at the recipient (e.g. a resource server). > > > > > I was, however, wondering about the subtle implication of the > requirement for sender constrained tokens. My understanding of the token > binding discussion, which is one of the ways to provide sender-constraine= d > tokens, is that we don=E2=80=99t have good faith in seeing deployment any= time soon. > Hence, we are essentially (reading in between the lines of Section 3.8.1.= 2) > saying that you cannot use implicit grant in a practical setup for the we= b*. > > The text shall convey that implicit must not be used at all. The main > reason being it is unprotected against token injection and additionally > also cannot sender constrain tokens. > > The second part of the statement relates to other response types and > conditionally opens the MUST NOT in case they are protected against > injection (which is true for the listed response types) and can issue > sender constrained tokens (which does not work today but might work in th= e > future). > > kind regards, > Torsten. > > > > > Am I misunderstanding it? > > > > > Ciao > > Hannes > > > > PS: The IoT case is likely different. > > > > From: OAuth On Behalf Of Aaron Parecki > > Sent: Saturday, December 1, 2018 3:18 AM > > To: Torsten Lodderstedt > > Cc: Daniel Fett ; IETF oauth WG > > Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorizatio= n > code instead of implicit > > > > +1 > > > > I would also like to ensure there is a clear definition of "sender > constrained" tokens in this BCP. > > > > Aaron > > > > > > On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Hi all, > > > > based on your feedback on the list and off list, Daniel and I polished > the text. That=E2=80=99s our proposal: > > > > =E2=80=94 > > In order to avoid these issues, clients MUST NOT use the implicit > > grant (response type "token") or any other response type issuing access > > tokens in the authorization response, such as "token id_token" and "cod= e > token id_token=E2=80=9C, > > unless the issued access tokens are sender-constrained and access token > injection in > > the authorization response is prevented. > > =E2=80=94 > > > > Explantation: > > - we wanted to have the right balance between a generic definition of > the response types we do not recommend/allow to be used and a > concrete/actionable list of the affected response types. > > - we changed from SHOULD NOT to MUST NOT as suggested by Nat and > supported by William > > > > We look forward to seeing your feedback. > > > > kind regards, > > Torsten. > > > > > Am 29.11.2018 um 15:15 schrieb John Bradley : > > > > > > I am ok with that. > > > > > > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt < > torsten@lodderstedt.net wrote: > > > > > > > Am 28.11.2018 um 23:50 schrieb n-sakimura : > > > > > > > > That works. > > > > > > Good! > > > > > > I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (= only). It would > allow =E2=80=9Etoken=E2=80=9C to be used if the token would sender constr= ained. This > completely ignores the fact implicit also shall be abandoned because of i= ts > vulnerability for access token injection. > > > > > > I therefore propose a modified text: > > > > > > In order to avoid these issues, Clients SHOULD NOT use the implici= t > > > grant. Furthermore, clients SHOULD only use other response types > causing the authorization server to > > > issue an access token in the authorization response, if the > particular response type detects access token > > > injection and the issued access tokens are sender-constrained. > > > > > > Or we just state: > > > > > > In order to avoid these issues, Clients SHOULD NOT use the response > type =E2=80=9Etoken". The response types > > > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2= =80=9C SOULD NOT be used, if the > issued access tokens are not > > > sender-constrained. > > > > > > > > > > > In fact, I would further go and say MUST NOT but that probably is > too much for a security consideration. > > > > > > > > > > Mike suggested to go with a SHOULD NOT to get the message out but giv= e > implementors time to move/change. > > > > > > > Best, > > > > > > > > Nat > > > > > > > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276 > > > > > > > > > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81= =E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3= =81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF= =86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84= =E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3= =81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81= =AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3= =E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3= =81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F= =A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97= =E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5= =89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81= =BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97= =E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 > > > > > > > > PLEASE READ :This e-mail is confidential and intended for the named > recipient only. > > > > If you are not an intended recipient, please notify the sender and > delete this e-mail. > > > > > > > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt > > > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, = 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C > > > > =E5=AE=9B=E5=85=88: n-sakimura > > > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org > > > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recomme= nd authorization > code instead of implicit > > > > > > > > Hi Nat, > > > > > > > >> Am 28.11.2018 um 21:10 schrieb n-sakimura : > > > >> > > > >> I would support > > > >> > > > >> 1) clearly defining Implicit as the flow that returns access token > from the authorization endpoint ( some people confuses implicit as the fl= ow > that returns ID Token in the front channel) > > > > > > > > That=E2=80=99s the current text: > > > > > > > > In order to avoid these issues, Clients SHOULD NOT use the implicit > > > > grant or any other response type causing the authorization serve= r > to > > > > issue an access token in the authorization response. > > > > > > > > What would you like to modify? > > > > > > > >> > > > >> 2) Banning the returning of the access token that are not sender > constrained from the authorization endpoint > > > > > > > > In order to avoid these issues, Clients SHOULD NOT use the implicit > > > > grant or any other response type causing the authorization serve= r > to > > > > issue an access token in the authorization response, if this > access tokens is not sender-constraint. > > > > > > > > What about this? > > > > > > > > kind regards, > > > > Torsten. > > > > > > > >> > > > >> Best, > > > >> > > > >> Nat > > > >> > > > >> > > > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B > > > >> > > > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth (Dick = Hardt < > dick.hardt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86) > > > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5,= 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C > > > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig > > > >> Cc: oauth@ietf.org > > > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recomm= end authorization > code instead of implicit > > > >> > > > >> +1 > > > >> > > > >> While there are various mechanisms to alleviate some of the issues > of implicit, I don't think we can recommend specifics, and there may be > future ones in the future. I think we all agree that implicit without any > mitigation is problematic. > > > >> > > > >> How about we recommend against using implicit alone? > > > >> > > > >> > > > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > > >> Hi all, > > > >> > > > >> The authors of the OAuth Security Topics draft came to the > conclusion that it is not possible to adequately secure the implicit flow > against token injection since potential solutions like token binding or > JARM are in an early stage of adoption. For this reason, and since CORS > allows browser-based apps to send requests to the token endpoint, Torsten > suggested to use the authorization code instead of the implicit grant in > call cases in his presentation (see > https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb= -draft-ietf-oauth-security-topics-01 > ). > > > >> > > > >> A hum in the room at IETF#103 concluded strong support for his > recommendations. We would like to confirm the discussion on the list. > > > >> > > > >> Please provide a response by December 3rd. > > > >> > > > >> 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 > > > >> _______________________________________________ > > > >> 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 > > -- > > ---- > > Aaron Parecki > > aaronparecki.com > > @aaronpk > > > > 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 > --000000000000cb9be0057c1662f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,
Sorry for stepp= ing a bit back from the level of detail the discussion already reached. I d= o have some specific comments on the document, but before bringing those up= I wanted to raise a general problem I am experiencing with this initiative= .

I have a number of cus= tomers that are reacting to the news with distress. The language used in so= me of the communications associated with this initiative made them feel lik= e some new vulnerability was discovered, calling for immediate action.
The fact is that as far as I can tell, no new, previousl= y unknown fact informed this decision: no new vulnerability, nor any new te= chnology that wasn=E2=80=99t available before (the sender constrain is stil= l not actionable for most customers). The risks of the implicit flow aren= =E2=80=99t bigger now than they were in October.
Tha= t doesn=E2=80=99t mean that we cannot improve guidance, of course- and now = is as good as any other moment to do so: but at the same time, I think we n= eed to be cognizant of the *immense* investment in existence today in form = of SDKs and applications built on those SDKs that are predicated on implici= t flow, with our blessing: until very recently the official position was = =E2=80=9Cimplicit is bad but it=E2=80=99s the best we have noawadays=E2=80= =9D.
To me, being cognizant of that means that we sh= ould help people to formulate action proportionate to the risk. And if unti= l yesterday we were ok with them using implicit, we cannot realistically ex= pect anyone to start changing all of their apps today, but that=E2=80=99s t= he message many customers are getting.=C2=A0
TL;DR, = I think the community would be well served by clarifying in the security do= cument that there is no new risk and their existing codebase didn=E2=80=99t= suddenly become less secure and in *urgent* need to update.
To attempt a metaphor. We discovered a new drug against headache = with milder side effects than the one we were prescribing them until now, b= ut that doesn=E2=80=99t mean that they should throw away all the stash they= have of the older drug. The old drug will keep working as it worked until = now. Once they run out of their stash, they should get the new one; or if t= he old side effects were particularly bad for them, perhaps they should con= sider switching today. But this isn=E2=80=99t a recall.=C2=A0

And if in fact this group thinks it s= hould be a recall and get everyone off the old one right now, I think we=E2= =80=99ll need to make a much stronger case than we have done so far.
<= div dir=3D"auto">
Thoughts?

Thanks
V.
=C2=A0

Hi Hannes,

> Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig <Hannes.Tschofenig@arm.com= >:
>
> I agree with Aaron here and I think Section 3.8.1.2 of draft-ietf-oaut= h-security-topics-10=C2=A0 already does a pretty good job.

my proposal is to add the following definition (based on 3.8.1.2) to a new = =E2=80=9ETerminology" section or to section 2.1.2:

A sender constrained access token scopes the applicability of an access tok= en to a certain sender.=C2=A0 This sender is
obliged to demonstrate knowledge of a certain secret as prerequisite for th= e acceptance of that token at the recipient (e.g. a resource server).

>
> I was, however, wondering about the subtle implication of the requirem= ent for sender constrained tokens. My understanding of the token binding di= scussion, which is one of the ways to provide sender-constrained tokens, is= that we don=E2=80=99t have good faith in seeing deployment anytime soon. H= ence, we are essentially (reading in between the lines of Section 3.8.1.2) = saying that you cannot use implicit grant in a practical setup for the web*= .

The text shall convey that implicit must not be used at all. The main reaso= n being it is unprotected against token injection and additionally also can= not sender constrain tokens.

The second part of the statement relates to other response types and condit= ionally opens the MUST NOT in case they are protected against injection (wh= ich is true for the listed response types) and can issue sender constrained= tokens (which does not work today but might work in the future).

kind regards,
Torsten.

>=C2=A0
> Am I misunderstanding it?

>=C2=A0
> Ciao
> Hannes
>=C2=A0
> PS: The IoT case is likely different.
>=C2=A0
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki
> Sent: Saturday, December 1, 2018 3:18 AM
> To: Torsten Lodderstedt <torsten@lodderstedt.net>
> Cc: Daniel Fett <fett@danielfett.de>; IETF oauth WG <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorizati= on code instead of implicit
>=C2=A0
> +1
>=C2=A0
> I would also like to ensure there is a clear definition of "sende= r constrained" tokens in this BCP.
>=C2=A0
> Aaron
>=C2=A0
>=C2=A0
> On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt <torsten@lodderstedt.net= > wrote:
> Hi all,
>
> based on your feedback on the list and off list, Daniel and I polished= the text. That=E2=80=99s our proposal:
>
> =E2=80=94
> In order to avoid these issues, clients MUST NOT use the implicit
> grant (response type "token") or any other response type iss= uing access
> tokens in the authorization response, such as "token id_token&quo= t; and "code token id_token=E2=80=9C,
> unless the issued access tokens are sender-constrained and access toke= n injection in
> the authorization response is prevented.
> =E2=80=94
>
> Explantation:
> - we wanted to have the right balance between a generic definition of = the response types we do not recommend/allow to be used and a concrete/acti= onable list of the affected response types.
> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and suppo= rted by William
>
> We look forward to seeing your feedback.
>
> kind regards,
> Torsten.=C2=A0
>
> > Am 29.11.2018 um 15:15 schrieb John Bradley <ve7jtb@ve7jtb.com>:
> >
> > I am ok with that.=C2=A0
> >
> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <torsten@lodderstedt.net wrote:
> >
> > > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@nri.co.jp>: > > >
> > > That works.
> >
> > Good!
> >
> > I just realized this text has an issue with =E2=80=9Etoken=E2=80= =9C (only). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token = would sender constrained. This completely ignores the fact implicit also sh= all be abandoned because of its vulnerability for access token injection. <= br> > >
> > I therefore propose a modified text:
> >
> >=C2=A0 =C2=A0 In order to avoid these issues, Clients SHOULD NOT u= se the implicit
> >=C2=A0 =C2=A0 grant. Furthermore, clients SHOULD only use other re= sponse types causing the authorization server to
> >=C2=A0 =C2=A0 issue an access token in the authorization response,= if the particular response type detects access token
> >=C2=A0 =C2=A0 injection and the issued access tokens are sender-co= nstrained.
> >
> > Or we just state:
> >
> >=C2=A0 =C2=A0In order to avoid these issues, Clients SHOULD NOT us= e the response type =E2=80=9Etoken". The response types
> > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token= =E2=80=9C SOULD NOT be used, if the issued access tokens are not
> > sender-constrained.
> >
> > >
> > > In fact, I would further go and say MUST NOT but that probab= ly is too much for a security consideration.
> > >
> >
> > Mike suggested to go with a SHOULD NOT to get the message out but= give implementors time to move/change.
> >
> > > Best,
> > >
> > > Nat
> > >
> > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
> > >
> > > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81= =AF=E3=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9= =E3=81=AE=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6= =A9=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81= =A6=E3=81=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84= =E3=81=BE=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3= =81=AE=E3=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81= =AB=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B= =E3=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3= =81=8A=E7=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81= =9F=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB= =E3=81=AF=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3= =81=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94= =B3=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
> > >
> > > PLEASE READ :This e-mail is confidential and intended for th= e named recipient only.
> > > If you are not an intended recipient, please notify the send= er and delete this e-mail.
> > >=C2=A0
> > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt <torsten@lodderstedt.n= et>
> > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6= =97=A5, 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
> > > =E5=AE=9B=E5=85=88: n-sakimura
> > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- = Recommend authorization code instead of implicit
> > >=C2=A0
> > > Hi Nat,
> > >
> > >> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nri.co.jp>= ;:
> > >>
> > >> I would support
> > >>
> > >> 1) clearly defining Implicit as the flow that returns ac= cess token from the authorization endpoint ( some people confuses implicit = as the flow that returns ID Token in the front channel)
> > >
> > > That=E2=80=99s the current text:
> > >
> > > In order to avoid these issues, Clients SHOULD NOT use the i= mplicit
> > >=C2=A0 =C2=A0 grant or any other response type causing the au= thorization server to
> > >=C2=A0 =C2=A0 issue an access token in the authorization resp= onse.
> > >
> > > What would you like to modify?
> > >
> > >>
> > >> 2) Banning the returning of the access token that are no= t sender constrained from the authorization endpoint
> > >
> > > In order to avoid these issues, Clients SHOULD NOT use the i= mplicit
> > >=C2=A0 =C2=A0 grant or any other response type causing the au= thorization server to
> > >=C2=A0 =C2=A0 issue an access token in the authorization resp= onse, if this access tokens is not sender-constraint.
> > >
> > > What about this?
> > >
> > > kind regards,
> > > Torsten.
> > >
> > >>
> > >> Best,
> > >>
> > >> Nat
> > >>
> > >>
> > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
> > >>=C2=A0
> > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-bounces@ietf.org> (= Dick Hardt <di= ck.hardt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86)
> > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C= =E6=97=A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
> > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
> > >> Cc: = oauth@ietf.org
> > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics= -- Recommend authorization code instead of implicit
> > >>=C2=A0
> > >> +1
> > >>
> > >> While there are various mechanisms to alleviate some of = the issues of implicit, I don't think we can recommend specifics, and t= here may be future ones in the future. I think we all agree that implicit w= ithout any mitigation is problematic.
> > >>
> > >> How about we recommend against using implicit alone? > > >>
> > >>
> > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofe= nig@arm.com> wrote:
> > >> Hi all,
> > >>
> > >> The authors of the OAuth Security Topics draft came to t= he conclusion that it is not possible to adequately secure the implicit flo= w against token injection since potential solutions like token binding or J= ARM are in an early stage of adoption. For this reason, and since CORS allo= ws browser-based apps to send requests to the token endpoint, Torsten sugge= sted to use the authorization code instead of the implicit grant in call ca= ses in his presentation (see https://datatracker.ietf.org/meeting/= 103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
> > >>
> > >> A hum in the room at IETF#103 concluded strong support f= or his recommendations. We would like to confirm the discussion on the list= .
> > >>
> > >> Please provide a response by December 3rd.
> > >>
> > >> Ciao
> > >>
> > >> Hannes & Rifaat
> > >>
> > >>=C2=A0
> > >>
> > >> IMPORTANT NOTICE: The contents of this email and any att= achments are confidential and may also be privileged. If you are not the in= tended 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 = the information in any medium. Thank you.
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAut= h@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/= oauth
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAut= h@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/= oauth
> > >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/oauth=
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
> --
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk
>=C2=A0
> IMPORTANT NOTICE: The contents of this email and any attachments are c= onfidential and may also be privileged. If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the informatio= n in any medium. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000cb9be0057c1662f0-- From nobody Mon Dec 3 03:15:29 2018 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 06C2D130E4B for ; Mon, 3 Dec 2018 03:15:28 -0800 (PST) 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 qB1-q9wcA5bb for ; Mon, 3 Dec 2018 03:15:24 -0800 (PST) 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 611E5128DFD for ; Mon, 3 Dec 2018 03:15:24 -0800 (PST) Received: from [87.79.89.127] (helo=[10.2.11.3]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gTmC8-0001t8-TV; Mon, 03 Dec 2018 12:15:21 +0100 From: Torsten Lodderstedt Message-Id: <7FEF0314-88F2-46C7-A22D-C794CC1BB6A0@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_269854A5-5C36-4009-AE1D-1F937CA52066"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Mon, 3 Dec 2018 12:15:19 +0100 In-Reply-To: Cc: Aaron Parecki , IETF oauth WG To: John Bradley References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 03 Dec 2018 11:15:28 -0000 --Apple-Mail=_269854A5-5C36-4009-AE1D-1F937CA52066 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Interesting. Even on this list people felt to see that moving some logic = to a backend could solve some of the problems raised. What I want to = convey is: the solution to a problem in the OAuth space does not = necessarily need to be found on the OAuth protocol level. That=E2=80=99s = a best practice in the same way as some OAuth pattern.=20 What I=E2=80=99m suggesting is a statement in the BCP like =E2=80=94 Implementations MAY consider to move authorization code exchange and = handling of access and refresh tokens to a backend component in order to = fulfill their security goals.=20 Security of the connection between code running in the browser and this = backend component is assumed to utilize browser-level protection = mechanisms. Details are out of scope of this document.=20 =E2=80=94 > Am 03.12.2018 um 11:19 schrieb John Bradley : >=20 > This is my point. =20 >=20 > =46rom a security perspective we have a server based confidential = client. The fact that it has a angular or other JS UI protected by a = cookie seems to not be especially relucent to OAuth. =20 >=20 > Perhaps from the developer point of view they have a JS SPA and the = only difference to them is in one case they are including the OAuth = client and in the other they are using a server based proxy. So they see = it as the same. >=20 > Perhaps it is perspective.=20 >=20 > On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki In this type of deployment, as far as OAuth is concerned, isn't the = backend web server a confidential client? Is there even anything unique = to this situation as far as OAuth security goes?=20 >=20 > I wouldn't have expected an Angular app that talks to its own server = backend that's managing OAuth credentials to fall under the umbrella of = this BCP. >=20 > ---- > Aaron Parecki > aaronparecki.com >=20 >=20 >=20 > On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt = wrote: > the UI is rendered in the frontend, UI control flow is in the = frontend. just a different cut through the web app=E2=80=99s layering=20 >=20 > All Angular apps I have seen so far work that way. And it makes a lot = of sense to me. The backend can aggregate and optimize access to the = underlying services without the need to fully expose them. >=20 > Am 02.12.2018 um 00:44 schrieb John Bradley : >=20 >> How is that different from a regular server client with a web = interface if the backed is doing the API calls to the RS? >>=20 >>=20 >>=20 >> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: >>> I forgot to mention another (architectural) option: split an = application into frontend provided by JS in the browser and a backend, = which takes care of the business logic and handles tokens and API = access. Replay detection at the interface between SPA and backend can = utilize standard web techniques (see OWASP). The backend in turn can use = mTLS for sender constraining. >>>=20 >>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt = : >>>=20 >>>> IMHO the best mechanism at hand currently to cope with token = leakage/replay in SPAs is to use refresh tokens (rotating w/ replay = detection) and issue short living and privilege restricted access = tokens. >>>>=20 >>>> Sender constrained access tokens in SPAs need adoption of token = binding or alternative mechanism. mtls could potentially work in = deployments with automated cert rollout but browser UX and interplay = with fetch needs some work. We potentially must consider to warm up = application level PoP mechanisms in conjunction with web crypto. Another = path to be evaluated could be web auth. >>>>=20 >>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig = : >>>>=20 >>>>> I share the concern Brian has, which is also the conclusion I came = up with in my other email sent a few minutes ago. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: OAuth On Behalf Of Brian Campbell >>>>> Sent: Friday, November 30, 2018 11:43 PM >>>>> To: Torsten Lodderstedt >>>>> Cc: oauth >>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt = wrote: >>>>>=20 >>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen = : >>>>> >=20 >>>>> > So you mean at the resource server ensuring the token was really = issued to the client? Isn't that an inherent limitation of all bearer = tokens (modulo HTTP token binding, which is still some time off)? >>>>>=20 >>>>> Sure. That=E2=80=99s why the Security BCP recommends use of = TLS-based methods for sender constraining access tokens = (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2= ..2). Token Binding for OAuth = (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well = as Mutual TLS for OAuth = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options = available. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Unfortunately even when using the token endpoint, for SPA / = in-browser client applications, the potential mechanisms for = sender/key-constraining access tokens don't work very well or maybe = don't work at all. So I don't know that the recommendation is very = realistic. >>>>>=20 >>>>> =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. >>>>>=20 >>>>> 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 = the information in any medium. Thank you. >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>>=20 >>> 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 --Apple-Mail=_269854A5-5C36-4009-AE1D-1F937CA52066 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODEyMDMxMTE1MjBaMC8GCSqGSIb3DQEJBDEiBCD5 EJU/1vHjrWjhbZphQHgshh0fcbNWFeeowXHEtGepnzCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAg4V4qULgreZmoz4uVZCLmvEZ DpdeyrqNsDD3nf1Ql2woVSUxyyiZ5k2tY1X5YG/BbHUbrjMItqO6cLTK2xVblRA63bdgfzj0lp5w hvKPF+x8e4395zXJEX+7adHH157sP2hvamAUHd4mxJpbP4oO5RKqE9JzZGmar5/Xj3finbCsSWFn Fky1tzaMhgw0dZUWQun1y524wa+CvxY90YqDMXiTvC5dzVPoBHmLhc3RlYyzVk7o6kTJdthGvXnN 0qsBYUEErumjZyhurDlDl4V2xNw76UPWdq/ovrSuix5QXttTPvflw+OYTsLn6qs8oOPS4WULmKIk XwT/1HHOQwtygAAAAAAAAA== --Apple-Mail=_269854A5-5C36-4009-AE1D-1F937CA52066-- From nobody Mon Dec 3 03:50:01 2018 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 9C7D7130E90 for ; Mon, 3 Dec 2018 03:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-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 dlGLQBL-gn41 for ; Mon, 3 Dec 2018 03:49:56 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 B111E130E77 for ; Mon, 3 Dec 2018 03:49:55 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id v11so13299774qtc.2 for ; Mon, 03 Dec 2018 03:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=5zCUn1yblNtxkZI7aZJl4cldSIGtpq006luAjLwTsts=; b=KX3D7LR0JLPEbJ5kAoTLTLkUltaEayk66SwL5etwr1or1DPH8t5aEqJsPdU+1T/JaV JTPj5DDWKY9bo/Fr4cGnQFTxLlTYUMh6kl/R0cKM5DEJKQisX551/wA0wdQ7IXxdyfQ0 ljZ89RqSlQGh3FnkUTKmexKes4WsncvM+gLnQP34VHJPGPzC2Q8R1QbcLxjQVaQVjIjb V7kjw9/Pkb8DRF9GPStI/wDusJgfk3HcjTbJHIErzaQ9cM/8gYosE6pgltWmILKUylqw ocfpQvF8ifKuO3nscHV+LwKh6GTlWEz7wkhGJ5nxs61qAD9cYve9T/i8txo0onZvqiOk Nv1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=5zCUn1yblNtxkZI7aZJl4cldSIGtpq006luAjLwTsts=; b=W9YixTOkqbeiz/wuPleXVeLJuq14PLqxkaDpn9sYxjyO74IZPAcXq9gK/qo4fbi5kB H3SkzGL911WLodqXRBuy7OzS8eDSWle2BSt7pilwmfyW9ynZIXHz8YXA5WDtEfWyQXJG 8GGXOjBClyIFT2jEc7ZVcg5XY3asF/NSQ3nSSVNCo9K9dzfKu4P9W2krVAe5mL1QMc0R adSv8QJM9nUIYLSwtolB3Fng2g/Li8xzlmHCR9Yx7Mt0PbGT8C28MrvzVAcleFBUFOLS CsntFmzgkCTqB3NhzlYhkd6WJcmwt1c/3zp/nknTmP7E1HW0pVTqfd5IsCxdbad7hoNV 8hFg== X-Gm-Message-State: AA+aEWagYHAYsz8y6HCzSrP6Ih1FQOqdJfssnta/8HHM3jYUBeLNfUYm NqLJJLWrd3z+QfyUDf2uun0Z5FRTXKItDJGUnmu6ZVc= X-Google-Smtp-Source: AFSGD/WUBvSgy9D/EG1mDgXrI3TgMmSnSuMhawmy5Ty099uFzaykgzJw1cWstQxg7MLWD1bHqaRdd6v5HcxYs5XlEUo= X-Received: by 2002:a0c:8822:: with SMTP id 31mr15443684qvl.5.1543837794421; Mon, 03 Dec 2018 03:49:54 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 3 Dec 2018 03:49:53 -0800 From: Dominick Baier In-Reply-To: References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> X-Mailer: Airmail (528) MIME-Version: 1.0 Date: Mon, 3 Dec 2018 03:49:53 -0800 Message-ID: To: Vittorio Bertocci , Torsten Lodderstedt Cc: Daniel Fett , IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000053e662057c1cbf85" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 03 Dec 2018 11:50:00 -0000 --00000000000053e662057c1cbf85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Vittorio - While we all agree that implicit is outdated and we can do better (and it is indeed good that this discussion has finally started for real) - the communication around the (preliminary) results of the BCP was unfortunate and not very responsible - quoting: =E2=80=9CSimply put, the implicit grant=E2=80=99s security is broken beyond= repair. It is vulnerable to access token leakage, meaning an attacker can exfiltrate valid access tokens and use it to his own benefit. This might for example result in the attacker accessing the legit user=E2=80=99s health record or initiating a payment, from her bank account." This indeed, as Vittorio pointed out, sounds like a new vulnerability has been found. This spreads FUD ;) Also - simply saying =E2=80=9Cimplicit is evil - switch to code=E2=80=9D me= ans for most people also using refresh token - so we are treating access tokens in the URL with refresh tokens in session storage (over simplified - but you get the idea). Again we all agree that implicit can be improved - but there are some issues to be sorted first to make this a smooth transition. My 2c =E2=80=94=E2=80=94=E2=80=94 Dominick On 3. December 2018 at 11:59:44, Vittorio Bertocci ( vittorio.bertocci=3D40auth0.com@dmarc.ietf.org) wrote: Hi all, Sorry for stepping a bit back from the level of detail the discussion already reached. I do have some specific comments on the document, but before bringing those up I wanted to raise a general problem I am experiencing with this initiative.. I have a number of customers that are reacting to the news with distress. The language used in some of the communications associated with this initiative made them feel like some new vulnerability was discovered, calling for immediate action. The fact is that as far as I can tell, no new, previously unknown fact informed this decision: no new vulnerability, nor any new technology that wasn=E2=80=99t available before (the sender constrain is still not actionab= le for most customers). The risks of the implicit flow aren=E2=80=99t bigger now t= han they were in October. That doesn=E2=80=99t mean that we cannot improve guidance, of course- and n= ow is as good as any other moment to do so: but at the same time, I think we need to be cognizant of the *immense* investment in existence today in form of SDKs and applications built on those SDKs that are predicated on implicit flow, with our blessing: until very recently the official position was =E2=80=9Ci= mplicit is bad but it=E2=80=99s the best we have noawadays=E2=80=9D. To me, being cognizant of that means that we should help people to formulate action proportionate to the risk. And if until yesterday we were ok with them using implicit, we cannot realistically expect anyone to start changing all of their apps today, but that=E2=80=99s the message many custo= mers are getting. TL;DR, I think the community would be well served by clarifying in the security document that there is no new risk and their existing codebase didn=E2=80=99t suddenly become less secure and in *urgent* need to update. To attempt a metaphor. We discovered a new drug against headache with milder side effects than the one we were prescribing them until now, but that doesn=E2=80=99t mean that they should throw away all the stash they ha= ve of the older drug. The old drug will keep working as it worked until now. Once they run out of their stash, they should get the new one; or if the old side effects were particularly bad for them, perhaps they should consider switching today. But this isn=E2=80=99t a recall. And if in fact this group thinks it should be a recall and get everyone off the old one right now, I think we=E2=80=99ll need to make a much stronger c= ase than we have done so far. Thoughts? Thanks V. On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt wrote: > Hi Hannes, > > > Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig < > Hannes.Tschofenig@arm.com>: > > > > I agree with Aaron here and I think Section 3.8.1.2 of > draft-ietf-oauth-security-topics-10 already does a pretty good job. > > my proposal is to add the following definition (based on 3.8.1.2) to a ne= w > =E2=80=9ETerminology" section or to section 2.1.2: > > A sender constrained access token scopes the applicability of an access > token to a certain sender. This sender is > obliged to demonstrate knowledge of a certain secret as prerequisite for > the acceptance of that token at the recipient (e.g. a resource server). > > > > > I was, however, wondering about the subtle implication of the > requirement for sender constrained tokens. My understanding of the token > binding discussion, which is one of the ways to provide sender-constraine= d > tokens, is that we don=E2=80=99t have good faith in seeing deployment any= time soon. > Hence, we are essentially (reading in between the lines of Section 3.8.1.= 2) > saying that you cannot use implicit grant in a practical setup for the > web*.. > > The text shall convey that implicit must not be used at all. The main > reason being it is unprotected against token injection and additionally > also cannot sender constrain tokens. > > The second part of the statement relates to other response types and > conditionally opens the MUST NOT in case they are protected against > injection (which is true for the listed response types) and can issue > sender constrained tokens (which does not work today but might work in th= e > future). > > kind regards, > Torsten. > > > > > Am I misunderstanding it? > > > > > Ciao > > Hannes > > > > PS: The IoT case is likely different. > > > > From: OAuth On Behalf Of Aaron Parecki > > Sent: Saturday, December 1, 2018 3:18 AM > > To: Torsten Lodderstedt > > Cc: Daniel Fett ; IETF oauth WG > > Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorizatio= n > code instead of implicit > > > > +1 > > > > I would also like to ensure there is a clear definition of "sender > constrained" tokens in this BCP. > > > > Aaron > > > > > > On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Hi all, > > > > based on your feedback on the list and off list, Daniel and I polished > the text. That=E2=80=99s our proposal: > > > > =E2=80=94 > > In order to avoid these issues, clients MUST NOT use the implicit > > grant (response type "token") or any other response type issuing access > > tokens in the authorization response, such as "token id_token" and "cod= e > token id_token=E2=80=9C, > > unless the issued access tokens are sender-constrained and access token > injection in > > the authorization response is prevented. > > =E2=80=94 > > > > Explantation: > > - we wanted to have the right balance between a generic definition of > the response types we do not recommend/allow to be used and a > concrete/actionable list of the affected response types. > > - we changed from SHOULD NOT to MUST NOT as suggested by Nat and > supported by William > > > > We look forward to seeing your feedback. > > > > kind regards, > > Torsten. > > > > > Am 29.11.2018 um 15:15 schrieb John Bradley : > > > > > > I am ok with that. > > > > > > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt < > torsten@lodderstedt.net wrote: > > > > > > > Am 28.11.2018 um 23:50 schrieb n-sakimura : > > > > > > > > That works. > > > > > > Good! > > > > > > I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (= only). It would > allow =E2=80=9Etoken=E2=80=9C to be used if the token would sender constr= ained. This > completely ignores the fact implicit also shall be abandoned because of i= ts > vulnerability for access token injection. > > > > > > I therefore propose a modified text: > > > > > > In order to avoid these issues, Clients SHOULD NOT use the implici= t > > > grant. Furthermore, clients SHOULD only use other response types > causing the authorization server to > > > issue an access token in the authorization response, if the > particular response type detects access token > > > injection and the issued access tokens are sender-constrained. > > > > > > Or we just state: > > > > > > In order to avoid these issues, Clients SHOULD NOT use the response > type =E2=80=9Etoken". The response types > > > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2= =80=9C SOULD NOT be used, if the > issued access tokens are not > > > sender-constrained. > > > > > > > > > > > In fact, I would further go and say MUST NOT but that probably is > too much for a security consideration. > > > > > > > > > > Mike suggested to go with a SHOULD NOT to get the message out but giv= e > implementors time to move/change. > > > > > > > Best, > > > > > > > > Nat > > > > > > > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276 > > > > > > > > > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81= =E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3= =81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF= =86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84= =E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3= =81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81= =AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3= =E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3= =81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F= =A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97= =E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5= =89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81= =BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97= =E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 > > > > > > > > PLEASE READ :This e-mail is confidential and intended for the named > recipient only. > > > > If you are not an intended recipient, please notify the sender and > delete this e-mail. > > > > > > > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt > > > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, = 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C > > > > =E5=AE=9B=E5=85=88: n-sakimura > > > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org > > > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recomme= nd authorization > code instead of implicit > > > > > > > > Hi Nat, > > > > > > > >> Am 28.11.2018 um 21:10 schrieb n-sakimura : > > > >> > > > >> I would support > > > >> > > > >> 1) clearly defining Implicit as the flow that returns access token > from the authorization endpoint ( some people confuses implicit as the fl= ow > that returns ID Token in the front channel) > > > > > > > > That=E2=80=99s the current text: > > > > > > > > In order to avoid these issues, Clients SHOULD NOT use the implicit > > > > grant or any other response type causing the authorization serve= r > to > > > > issue an access token in the authorization response. > > > > > > > > What would you like to modify? > > > > > > > >> > > > >> 2) Banning the returning of the access token that are not sender > constrained from the authorization endpoint > > > > > > > > In order to avoid these issues, Clients SHOULD NOT use the implicit > > > > grant or any other response type causing the authorization serve= r > to > > > > issue an access token in the authorization response, if this > access tokens is not sender-constraint. > > > > > > > > What about this? > > > > > > > > kind regards, > > > > Torsten. > > > > > > > >> > > > >> Best, > > > >> > > > >> Nat > > > >> > > > >> > > > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B > > > >> > > > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth (Dick = Hardt < > dick.hardt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86) > > > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5,= 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C > > > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig > > > >> Cc: oauth@ietf.org > > > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recomm= end authorization > code instead of implicit > > > >> > > > >> +1 > > > >> > > > >> While there are various mechanisms to alleviate some of the issues > of implicit, I don't think we can recommend specifics, and there may be > future ones in the future. I think we all agree that implicit without any > mitigation is problematic. > > > >> > > > >> How about we recommend against using implicit alone? > > > >> > > > >> > > > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > > >> Hi all, > > > >> > > > >> The authors of the OAuth Security Topics draft came to the > conclusion that it is not possible to adequately secure the implicit flow > against token injection since potential solutions like token binding or > JARM are in an early stage of adoption. For this reason, and since CORS > allows browser-based apps to send requests to the token endpoint, Torsten > suggested to use the authorization code instead of the implicit grant in > call cases in his presentation (see > https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb= -draft-ietf-oauth-security-topics-01 > ). > > > >> > > > >> A hum in the room at IETF#103 concluded strong support for his > recommendations. We would like to confirm the discussion on the list.. > > > >> > > > >> Please provide a response by December 3rd. > > > >> > > > >> 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 > > > >> _______________________________________________ > > > >> 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 > > -- > > ---- > > Aaron Parecki > > aaronparecki.com > > @aaronpk > > > > 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --00000000000053e662057c1cbf85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I agree with Vittorio -=C2=A0

Wh= ile we all agree that implicit is outdated and we can do better (and it is = indeed good that this discussion has finally started for real) - the commun= ication around the (preliminary) results of the BCP was unfortunate and not= very responsible - quoting:

=E2=80=9CS= imply put, the implicit grant=E2=80=99s security is broken beyond repair. I= t is vulnerable to access token leakage, meaning an attacker can exfiltrate= valid access tokens and use it to his own benefit. This might for example = result in the attacker accessing the legit user=E2=80=99s health record or = initiating a payment, from her bank account."

This indeed, as Vittorio pointed out, sounds like a new vulnerabil= ity has been found. This spreads FUD ;)

Also - sim= ply saying =E2=80=9Cimplicit is evil - switch to code=E2=80=9D means for mo= st people also using refresh token - so we are treating access tokens in th= e URL with refresh tokens in session storage (over simplified - but you get= the idea).

Again we all agree that implicit can b= e improved - but there are some issues to be sorted first to make this a sm= ooth transition.

My 2c

=E2=80=94=E2=80=94=E2=80=94<= div>Dominick

On 3. December 2018 at= 11:59:44, Vittorio Bertocci (vittorio.bertocci=3D40auth0.com@dmarc.ietf.org) wr= ote:

Hi all,
Sorry for stepping a bit back from the level of detail the discussion already reached. I do have some specific comments on the document, but before bringing those up I wanted to raise a general problem I am experiencing with this initiative..

I have a number of customers that are reacting to the news with distress. The language used in some of the communications associated with this initiative made them feel like some new vulnerability was discovered, calling for immediate action.
The fact is that as far as I can tell, no new, previously unknown fact informed this decision: no new vulnerability, nor any new technology that wasn=E2=80=99t available before (the sender constrain is still not actionable for most customers). The risks of the implicit flow aren=E2=80=99t bigger now than they were in October.
That doesn=E2=80=99t mean that we cannot improve guidance= , of course- and now is as good as any other moment to do so: but at the same time, I think we need to be cognizant of the *immense* investment in existence today in form of SDKs and applications built on those SDKs that are predicated on implicit flow, with our blessing: until very recently the official position was =E2=80=9Cimplicit is bad but it=E2=80=99s the best we have noawadays=E2=80=9D.
To me, being cognizant of that means that we should help people to formulate action proportionate to the risk. And if until yesterday we were ok with them using implicit, we cannot realistically expect anyone to start changing all of their apps today, but that=E2=80=99s the message many customers are getting.=C2=A0
TL;DR, I think the community would be well served by clarifying in the security document that there is no new risk and their existing codebase didn=E2=80=99t suddenly become less secure and in *urgent* need to update.
To attempt a metaphor. We discovered a new drug against headache with milder side effects than the one we were prescribing them until now, but that doesn=E2=80=99t mean that they should throw away all the stash they have of the older drug. The old drug will keep working as it worked until now. Once they run out of their stash, they should get the new one; or if the old side effects were particularly bad for them, perhaps they should consider switching today. But this isn=E2=80=99t a recall.=C2=A0

And if in fact this group thinks it should be a recall and get everyone off the old one right now, I think we=E2=80=99ll need to make a much stronger case than we have done so far.

Thoughts?

Thanks
V.
=C2=A0

On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt <torsten@lodderstedt.net&= gt; wrote:
Hi Hannes,

> Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig <Hannes.Tschofenig@arm.com= >:
>
> I agree with Aaron here and I think Section 3.8.1.2 of draft-ietf-oauth-security-topics-10=C2=A0 already does a pretty good job.

my proposal is to add the following definition (based on 3.8.1.2) to a new =E2=80=9ETerminology" section or to section 2.1.2:

A sender constrained access token scopes the applicability of an access token to a certain sender.=C2=A0 This sender is
obliged to demonstrate knowledge of a certain secret as prerequisite for the acceptance of that token at the recipient (e.g. a resource server).

>
> I was, however, wondering about the subtle implication of the requirement for sender constrained tokens. My understanding of the token binding discussion, which is one of the ways to provide sender-constrained tokens, is that we don=E2=80=99t have good faith in seeing deployment anytime soon. Hence, we are essentially (reading in between the lines of Section 3.8.1.2) saying that you cannot use implicit grant in a practical setup for the web*..

The text shall convey that implicit must not be used at all. The main reason being it is unprotected against token injection and additionally also cannot sender constrain tokens.

The second part of the statement relates to other response types and conditionally opens the MUST NOT in case they are protected against injection (which is true for the listed response types) and can issue sender constrained tokens (which does not work today but might work in the future).

kind regards,
Torsten.

>=C2=A0
> Am I misunderstanding it?

>=C2=A0
> Ciao
> Hannes
>=C2=A0
> PS: The IoT case is likely different.
>=C2=A0
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki
> Sent: Saturday, December 1, 2018 3:18 AM
> To: Torsten Lodderstedt <torsten@lodderstedt.net>
> Cc: Daniel Fett <fett@danielfett.de>; IETF oauth WG <oauth@ietf.org&= gt;
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
>=C2=A0
> +1
>=C2=A0
> I would also like to ensure there is a clear definition of "sender constrained" tokens in this BCP.
>=C2=A0
> Aaron
>=C2=A0
>=C2=A0
> On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt <torsten@lo= dderstedt.net> wrote:
> Hi all,
>
> based on your feedback on the list and off list, Daniel and I polished the text. That=E2=80=99s our proposal:
>
> =E2=80=94
> In order to avoid these issues, clients MUST NOT use the implicit
> grant (response type "token") or any other response type issuing access
> tokens in the authorization response, such as "token id_token&quo= t; and "code token id_token=E2=80=9C,
> unless the issued access tokens are sender-constrained and access token injection in
> the authorization response is prevented.
> =E2=80=94
>
> Explantation:
> - we wanted to have the right balance between a generic definition of the response types we do not recommend/allow to be used and a concrete/actionable list of the affected response types.
> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported by William
>
> We look forward to seeing your feedback.
>
> kind regards,
> Torsten.=C2=A0
>
> > Am 29.11.2018 um 15:15 schrieb John Bradley <ve7jtb@ve7jtb.com>:
> >
> > I am ok with that.=C2=A0
> >
> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <torsten@lo= dderstedt.net wrote:
> >
> > > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@nr= i.co.jp>:
> > >
> > > That works.
> >
> > Good!
> >
> > I just realized this text has an issue with =E2=80=9Etoken=E2=80= =9C (only). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token woul= d sender constrained. This completely ignores the fact implicit also shall be abandoned because of its vulnerability for access token injection.
> >
> > I therefore propose a modified text:
> >
> >=C2=A0 =C2=A0 In order to avoid these issues, Clients SHOULD NOT use the implicit
> >=C2=A0 =C2=A0 grant. Furthermore, clients SHOULD only use other response types causing the authorization server to
> >=C2=A0 =C2=A0 issue an access token in the authorization response, if the particular response type detects access token
> >=C2=A0 =C2=A0 injection and the issued access tokens are sender-constrained.
> >
> > Or we just state:
> >
> >=C2=A0 =C2=A0In order to avoid these issues, Clients SHOULD NOT use the response type =E2=80=9Etoken". The response types > > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token= =E2=80=9C SOULD NOT be used, if the issued access tokens are not
> > sender-constrained.
> >
> > >
> > > In fact, I would further go and say MUST NOT but that probably is too much for a security consideration.
> > >
> >
> > Mike suggested to go with a SHOULD NOT to get the message out but give implementors time to move/change.
> >
> > > Best,
> > >
> > > Nat
> > >
> > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
> > >
> > > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=E6= =9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=81= =BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=86= =E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=E3= =82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81= =99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=AA= =E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=E3= =81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=81= =8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=A5= =E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=E4= =BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=89= =8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=BE= =E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=E4= =B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
> > >
> > > PLEASE READ :This e-mail is confidential and intended for the named recipient only.
> > > If you are not an intended recipient, please notify the sender and delete this e-mail.
> > >=C2=A0
> > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt <torsten@lodderstedt.n= et>
> > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6= =97=A5, 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
> > > =E5=AE=9B=E5=85=88: n-sakimura
> > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
> > >=C2=A0
> > > Hi Nat,
> > >
> > >> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nr= i.co.jp>:
> > >>
> > >> I would support
> > >>
> > >> 1) clearly defining Implicit as the flow that returns access token from the authorization endpoint ( some people confuses implicit as the flow that returns ID Token in the front channel)
> > >
> > > That=E2=80=99s the current text:
> > >
> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
> > >=C2=A0 =C2=A0 grant or any other response type causing the authorization server to
> > >=C2=A0 =C2=A0 issue an access token in the authorization response.
> > >
> > > What would you like to modify?
> > >
> > >>
> > >> 2) Banning the returning of the access token that are not sender constrained from the authorization endpoint
> > >
> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
> > >=C2=A0 =C2=A0 grant or any other response type causing the authorization server to
> > >=C2=A0 =C2=A0 issue an access token in the authorization response, if this access tokens is not sender-constraint.
> > >
> > > What about this?
> > >
> > > kind regards,
> > > Torsten.
> > >
> > >>
> > >> Best,
> > >>
> > >> Nat
> > >>
> > >>
> > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
> > >>=C2=A0
> > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-bounces@ietf.org> (= Dick Hardt <di= ck.hardt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86)
> > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C= =E6=97=A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
> > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
> > >> Cc: = oauth@ietf.org
> > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics= -- Recommend authorization code instead of implicit
> > >>=C2=A0
> > >> +1
> > >>
> > >> While there are various mechanisms to alleviate some of the issues of implicit, I don't think we can recommend specifics, and there may be future ones in the future. I think we all agree that implicit without any mitigation is problematic.
> > >>
> > >> How about we recommend against using implicit alone?
> > >>
> > >>
> > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
> > >> Hi all,
> > >>
> > >> The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (see https://datatracker.ietf.org/meeting/103/mat= erials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
> > >>
> > >> A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list..
> > >>
> > >> Please provide a response by December 3rd.
> > >>
> > >> Ciao
> > >>
> > >> Hannes & Rifaat
> > >>
> > >>=C2=A0
> > >>
> > >> 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 the information in any medium. Thank you.
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAut= h@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/= oauth
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAut= h@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/= oauth
> > >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/oauth=
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
> --
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk
>=C2=A0
> 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 the information in any medium. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
--00000000000053e662057c1cbf85-- From nobody Mon Dec 3 03:59:33 2018 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 76207130E77 for ; Mon, 3 Dec 2018 03:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 99-cOCihQLTt for ; Mon, 3 Dec 2018 03:59:26 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 EB86312D7F8 for ; Mon, 3 Dec 2018 03:59:25 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id 96so11887082wrb.2 for ; Mon, 03 Dec 2018 03:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QL5SBSwZ5UC1bmtjFmZ+OzXlDX88nrGr1bV28+jwQxM=; b=LKmGwTKy6xzql6XDpomv0ZYlsIHFnOcM1iGvfPfp0Dxe/TqsNvyDZnVKWaJcFJF9us vBR4IlsdKdaXyZutrPw8uIERF4GXPEhMlMdYoL71oG+r2/aRgIhBwKSvDGrX1U5wDk3v sB7M1Nmd8HQC+huwQB/6XcTmPolQ18aIpbPCpKsKM7HfHuHgh43np9HpvOVHJzFqkQVu H8Bl9zriThpeMQb5H7nHm+j1S3sCwq7DbqRlcfhQusOo4o1Bx3mwhGVkStHIxsuSIPuZ HbU4EOUD6NjT0ZaCc2d5XygcaP5nbaPEmRnK933LBPkw4YOqgaZx1RccLdr+YWmrlZFQ vTnQ== 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=QL5SBSwZ5UC1bmtjFmZ+OzXlDX88nrGr1bV28+jwQxM=; b=G3C0CMVwdkpVGl1h0k7RQff/nR1WBx1kOOL/GsKVy7x/t/grmCC85Z41F39tG6ugr7 zYxqGy1pthcDeBS/Uwf1K53ynPyrtT9ljzXFDwChmvRjV0Zvlt6VxVT0QfBE2APs0V+F dQFffqziDApqwInJCLy30F7/ZJ46htzN9phNtKUYlk83s8vBGGzAuk4K/WubtZAN9cah 8fTynpF4p9qgIxg0bC/62i4ir0UDvVCPGReKrmBB1sIFS9UeDWP9fGVpG+u7lJuSYZ/l It1GSDo/hbUll7wEqQ/0r4042RffA47pTnlAyPpbGdHp7IGk50rWvMcR8qgf3+WCqbu5 MHIw== X-Gm-Message-State: AA+aEWbGXvYlJdl2a6ujbq9JA8fvc70VIzDrSR+qdUYdPyqcCv9siF1l iPUY/ePMdeIly7shnOlcKEO0Y34okh3B0nfgb8UpsQ== X-Google-Smtp-Source: AFSGD/UXxRfC2A8Tq0jseT8dvzE9chiF/Z3dKhD4JsjIDXPiLuwZMeK+edXuI8UL45kshqG33EcN2WKthm/OajzthYk= X-Received: by 2002:a5d:4e0b:: with SMTP id p11mr15176080wrt.227.1543838363728; Mon, 03 Dec 2018 03:59:23 -0800 (PST) MIME-Version: 1.0 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> In-Reply-To: From: John Bradley Date: Mon, 3 Dec 2018 12:59:14 +0100 Message-ID: To: Dominick Baier Cc: Vittorio Bertocci , Torsten Lodderstedt , Daniel Fett , IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000042cf43057c1ce1f5" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 03 Dec 2018 11:59:32 -0000 --00000000000042cf43057c1ce1f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree that the hair on fire messaging is over stated. This is still a document in development and not yet a BCP. No new vunerable have been found, but attackers are evolving. These are security best practices for new implimentations. Not a recommendation to rip things out. As applications are updated they need to consider the BCP recommendations. We do need to be careful about how our discussions are interpreted. There are also worse things people could do than implicit if we scare them back to proprietary solutions. John B. On Mon, Dec 3, 2018, 12:50 PM Dominick Baier I agree with Vittorio - > > While we all agree that implicit is outdated and we can do better (and it > is indeed good that this discussion has finally started for real) - the > communication around the (preliminary) results of the BCP was unfortunate > and not very responsible - quoting: > > =E2=80=9CSimply put, the implicit grant=E2=80=99s security is broken beyo= nd repair. It is > vulnerable to access token leakage, meaning an attacker can exfiltrate > valid access tokens and use it to his own benefit. This might for example > result in the attacker accessing the legit user=E2=80=99s health record o= r > initiating a payment, from her bank account." > > This indeed, as Vittorio pointed out, sounds like a new vulnerability has > been found. This spreads FUD ;) > > Also - simply saying =E2=80=9Cimplicit is evil - switch to code=E2=80=9D = means for most > people also using refresh token - so we are treating access tokens in the > URL with refresh tokens in session storage (over simplified - but you get > the idea). > > Again we all agree that implicit can be improved - but there are some > issues to be sorted first to make this a smooth transition. > > My 2c > > =E2=80=94=E2=80=94=E2=80=94 > Dominick > > On 3. December 2018 at 11:59:44, Vittorio Bertocci ( > vittorio.bertocci=3D40auth0.com@dmarc.ietf.org > ) wrote: > > Hi all, > Sorry for stepping a bit back from the level of detail the discussion > already reached. I do have some specific comments on the document, but > before bringing those up I wanted to raise a general problem I am > experiencing with this initiative.. > > I have a number of customers that are reacting to the news with distress. > The language used in some of the communications associated with this > initiative made them feel like some new vulnerability was discovered, > calling for immediate action. > The fact is that as far as I can tell, no new, previously unknown fact > informed this decision: no new vulnerability, nor any new technology that > wasn=E2=80=99t available before (the sender constrain is still not action= able for > most customers). The risks of the implicit flow aren=E2=80=99t bigger now= than they > were in October. > That doesn=E2=80=99t mean that we cannot improve guidance, of course- and= now is > as good as any other moment to do so: but at the same time, I think we ne= ed > to be cognizant of the *immense* investment in existence today in form of > SDKs and applications built on those SDKs that are predicated on implicit > flow, with our blessing: until very recently the official position was > =E2=80=9Cimplicit is bad but it=E2=80=99s the best we have noawadays=E2= =80=9D. > To me, being cognizant of that means that we should help people to > formulate action proportionate to the risk. And if until yesterday we wer= e > ok with them using implicit, we cannot realistically expect anyone to sta= rt > changing all of their apps today, but that=E2=80=99s the message many cus= tomers are > getting. > TL;DR, I think the community would be well served by clarifying in the > security document that there is no new risk and their existing codebase > didn=E2=80=99t suddenly become less secure and in *urgent* need to update= . > To attempt a metaphor. We discovered a new drug against headache with > milder side effects than the one we were prescribing them until now, but > that doesn=E2=80=99t mean that they should throw away all the stash they = have of > the older drug. The old drug will keep working as it worked until now. On= ce > they run out of their stash, they should get the new one; or if the old > side effects were particularly bad for them, perhaps they should consider > switching today. But this isn=E2=80=99t a recall. > > And if in fact this group thinks it should be a recall and get everyone > off the old one right now, I think we=E2=80=99ll need to make a much stro= nger case > than we have done so far. > > Thoughts? > > Thanks > V. > > > On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt > wrote: > >> Hi Hannes, >> >> > Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig < >> Hannes.Tschofenig@arm.com>: >> > >> > I agree with Aaron here and I think Section 3.8.1.2 of >> draft-ietf-oauth-security-topics-10 already does a pretty good job. >> >> my proposal is to add the following definition (based on 3.8.1.2) to a >> new =E2=80=9ETerminology" section or to section 2.1.2: >> >> A sender constrained access token scopes the applicability of an access >> token to a certain sender. This sender is >> obliged to demonstrate knowledge of a certain secret as prerequisite for >> the acceptance of that token at the recipient (e.g. a resource server). >> >> > >> > I was, however, wondering about the subtle implication of the >> requirement for sender constrained tokens. My understanding of the token >> binding discussion, which is one of the ways to provide sender-constrain= ed >> tokens, is that we don=E2=80=99t have good faith in seeing deployment an= ytime soon. >> Hence, we are essentially (reading in between the lines of Section 3.8.1= .2) >> saying that you cannot use implicit grant in a practical setup for the >> web*.. >> >> The text shall convey that implicit must not be used at all. The main >> reason being it is unprotected against token injection and additionally >> also cannot sender constrain tokens. >> >> The second part of the statement relates to other response types and >> conditionally opens the MUST NOT in case they are protected against >> injection (which is true for the listed response types) and can issue >> sender constrained tokens (which does not work today but might work in t= he >> future). >> >> kind regards, >> Torsten. >> >> > >> > Am I misunderstanding it? >> >> > >> > Ciao >> > Hannes >> > >> > PS: The IoT case is likely different. >> > >> > From: OAuth On Behalf Of Aaron Parecki >> > Sent: Saturday, December 1, 2018 3:18 AM >> > To: Torsten Lodderstedt >> > Cc: Daniel Fett ; IETF oauth WG >> > Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend >> authorization code instead of implicit >> > >> > +1 >> > >> > I would also like to ensure there is a clear definition of "sender >> constrained" tokens in this BCP. >> > >> > Aaron >> > >> > >> > On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> > Hi all, >> > >> > based on your feedback on the list and off list, Daniel and I polished >> the text. That=E2=80=99s our proposal: >> > >> > =E2=80=94 >> > In order to avoid these issues, clients MUST NOT use the implicit >> > grant (response type "token") or any other response type issuing acces= s >> > tokens in the authorization response, such as "token id_token" and >> "code token id_token=E2=80=9C, >> > unless the issued access tokens are sender-constrained and access toke= n >> injection in >> > the authorization response is prevented. >> > =E2=80=94 >> > >> > Explantation: >> > - we wanted to have the right balance between a generic definition of >> the response types we do not recommend/allow to be used and a >> concrete/actionable list of the affected response types. >> > - we changed from SHOULD NOT to MUST NOT as suggested by Nat and >> supported by William >> > >> > We look forward to seeing your feedback. >> > >> > kind regards, >> > Torsten. >> > >> > > Am 29.11.2018 um 15:15 schrieb John Bradley : >> > > >> > > I am ok with that. >> > > >> > > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt < >> torsten@lodderstedt.net wrote: >> > > >> > > > Am 28.11.2018 um 23:50 schrieb n-sakimura : >> > > > >> > > > That works. >> > > >> > > Good! >> > > >> > > I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C = (only). It would >> allow =E2=80=9Etoken=E2=80=9C to be used if the token would sender const= rained. This >> completely ignores the fact implicit also shall be abandoned because of = its >> vulnerability for access token injection. >> > > >> > > I therefore propose a modified text: >> > > >> > > In order to avoid these issues, Clients SHOULD NOT use the implic= it >> > > grant. Furthermore, clients SHOULD only use other response types >> causing the authorization server to >> > > issue an access token in the authorization response, if the >> particular response type detects access token >> > > injection and the issued access tokens are sender-constrained. >> > > >> > > Or we just state: >> > > >> > > In order to avoid these issues, Clients SHOULD NOT use the respons= e >> type =E2=80=9Etoken". The response types >> > > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2= =80=9C SOULD NOT be used, if the >> issued access tokens are not >> > > sender-constrained. >> > > >> > > > >> > > > In fact, I would further go and say MUST NOT but that probably is >> too much for a security consideration. >> > > > >> > > >> > > Mike suggested to go with a SHOULD NOT to get the message out but >> give implementors time to move/change. >> > > >> > > > Best, >> > > > >> > > > Nat >> > > > >> > > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276 >> > > > >> > > > >> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81= =E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3= =81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF= =86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84= =E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3= =81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81= =AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3= =E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3= =81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F= =A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97= =E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5= =89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81= =BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97= =E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 >> > > > >> > > > PLEASE READ :This e-mail is confidential and intended for the name= d >> recipient only. >> > > > If you are not an intended recipient, please notify the sender and >> delete this e-mail. >> > > > >> > > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt >> > > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5,= 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C >> > > > =E5=AE=9B=E5=85=88: n-sakimura >> > > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org >> > > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recomm= end authorization >> code instead of implicit >> > > > >> > > > Hi Nat, >> > > > >> > > >> Am 28.11.2018 um 21:10 schrieb n-sakimura : >> > > >> >> > > >> I would support >> > > >> >> > > >> 1) clearly defining Implicit as the flow that returns access toke= n >> from the authorization endpoint ( some people confuses implicit as the f= low >> that returns ID Token in the front channel) >> > > > >> > > > That=E2=80=99s the current text: >> > > > >> > > > In order to avoid these issues, Clients SHOULD NOT use the implici= t >> > > > grant or any other response type causing the authorization >> server to >> > > > issue an access token in the authorization response. >> > > > >> > > > What would you like to modify? >> > > > >> > > >> >> > > >> 2) Banning the returning of the access token that are not sender >> constrained from the authorization endpoint >> > > > >> > > > In order to avoid these issues, Clients SHOULD NOT use the implici= t >> > > > grant or any other response type causing the authorization >> server to >> > > > issue an access token in the authorization response, if this >> access tokens is not sender-constraint. >> > > > >> > > > What about this? >> > > > >> > > > kind regards, >> > > > Torsten. >> > > > >> > > >> >> > > >> Best, >> > > >> >> > > >> Nat >> > > >> >> > > >> >> > > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B >> > > >> >> > > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth (Dick= Hardt < >> dick.hardt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86) >> > > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5= , 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C >> > > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig >> > > >> Cc: oauth@ietf.org >> > > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recom= mend >> authorization code instead of implicit >> > > >> >> > > >> +1 >> > > >> >> > > >> While there are various mechanisms to alleviate some of the issue= s >> of implicit, I don't think we can recommend specifics, and there may be >> future ones in the future. I think we all agree that implicit without an= y >> mitigation is problematic. >> > > >> >> > > >> How about we recommend against using implicit alone? >> > > >> >> > > >> >> > > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig < >> Hannes.Tschofenig@arm.com> wrote: >> > > >> Hi all, >> > > >> >> > > >> The authors of the OAuth Security Topics draft came to the >> conclusion that it is not possible to adequately secure the implicit flo= w >> against token injection since potential solutions like token binding or >> JARM are in an early stage of adoption. For this reason, and since CORS >> allows browser-based apps to send requests to the token endpoint, Torste= n >> suggested to use the authorization code instead of the implicit grant in >> call cases in his presentation (see >> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sess= b-draft-ietf-oauth-security-topics-01 >> ). >> > > >> >> > > >> A hum in the room at IETF#103 concluded strong support for his >> recommendations. We would like to confirm the discussion on the list.. >> > > >> >> > > >> Please provide a response by December 3rd. >> > > >> >> > > >> 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 t= he >> information in any medium. Thank you. >> > > >> _______________________________________________ >> > > >> 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 >> > -- >> > ---- >> > Aaron Parecki >> > aaronparecki.com >> > @aaronpk >> > >> > 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 t= he >> information in any medium. Thank you. >> >> _______________________________________________ >> 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 > --00000000000042cf43057c1ce1f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that the hair on fire messaging is over stated.= =C2=A0 =C2=A0

This is still a = document in development and not yet a BCP.=C2=A0 =C2=A0No new vunerable hav= e been found, but attackers are evolving.=C2=A0=C2=A0

These are security best practices for new imp= limentations.=C2=A0 =C2=A0Not a recommendation to rip things out.=C2=A0 =C2= =A0 As applications are updated they need to consider the BCP recommendatio= ns.=C2=A0=C2=A0

We do ne= ed to be careful about how our discussions are interpreted.=C2=A0=C2=A0

There are also worse things= people could do than implicit if we scare them back to proprietary solutio= ns.=C2=A0=C2=A0

John B.= =C2=A0=C2=A0

On = Mon, Dec 3, 2018, 12:50 PM Dominick Baier <dbaier@leastprivilege.com wrote:
I agree wit= h Vittorio -=C2=A0

Whil= e we all agree that implicit is outdated and we can do better (and it is in= deed good that this discussion has finally started for real) - the communic= ation around the (preliminary) results of the BCP was unfortunate and not v= ery responsible - quoting:

=E2=80=9CSimply put, the implicit grant=E2=80= =99s security is broken beyond repair. It is vulnerable to access token lea= kage, meaning an attacker can exfiltrate valid access tokens and use it to = his own benefit. This might for example result in the attacker accessing th= e legit user=E2=80=99s health record or initiating a payment, from her bank= account."

This indeed, as Vittorio p= ointed out, sounds like a new vulnerability has been found. This spreads FU= D ;)

Also - simply saying =E2=80=9Cimplicit is evi= l - switch to code=E2=80=9D means for most people also using refresh token = - so we are treating access tokens in the URL with refresh tokens in sessio= n storage (over simplified - but you get the idea).

Again we all agree that implicit can be improved - but there are some iss= ues to be sorted first to make this a smooth transition.

My 2c

=E2=80=94=E2=80=94=E2= =80=94
Dominick

On 3. December 2018 at 11:59:44, Vittorio Bertocci (vittorio.bertocci=3D40auth0.com@dmarc.ietf.org) wrote:

=
Hi all,
Sorry for stepping a bit back from the level of detail the discussion already reached. I do have some specific comments on the document, but before bringing those up I wanted to raise a general problem I am experiencing with this initiative..

I have a number of customers that are reacting to the news with distress. The language used in some of the communications associated with this initiative made them feel like some new vulnerability was discovered, calling for immediate action.
The fact is that as far as I can tell, no new, previously unknown fact informed this decision: no new vulnerability, nor any new technology that wasn=E2=80=99t available before (the sender constrain is still not actionable for most customers). The risks of the implicit flow aren=E2=80=99t bigger now than they were in October.
That doesn=E2=80=99t mean that we cannot improve guidance= , of course- and now is as good as any other moment to do so: but at the same time, I think we need to be cognizant of the *immense* investment in existence today in form of SDKs and applications built on those SDKs that are predicated on implicit flow, with our blessing: until very recently the official position was =E2=80=9Cimplicit is bad but it=E2=80=99s the best we have noawadays=E2=80=9D.
To me, being cognizant of that means that we should help people to formulate action proportionate to the risk. And if until yesterday we were ok with them using implicit, we cannot realistically expect anyone to start changing all of their apps today, but that=E2=80=99s the message many customers are getting.=C2=A0
TL;DR, I think the community would be well served by clarifying in the security document that there is no new risk and their existing codebase didn=E2=80=99t suddenly become less secure and in *urgent* need to update.
To attempt a metaphor. We discovered a new drug against headache with milder side effects than the one we were prescribing them until now, but that doesn=E2=80=99t mean that they should throw away all the stash they have of the older drug. The old drug will keep working as it worked until now. Once they run out of their stash, they should get the new one; or if the old side effects were particularly bad for them, perhaps they should consider switching today. But this isn=E2=80=99t a recall.=C2=A0

And if in fact this group thinks it should be a recall and get everyone off the old one right now, I think we=E2=80=99ll need to make a much stronger case than we have done so far.

Thoughts?

Thanks
V.
=C2=A0

On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Hannes,

> Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig <Hannes.Tsc= hofenig@arm.com>:
>
> I agree with Aaron here and I think Section 3.8.1.2 of draft-ietf-oauth-security-topics-10=C2=A0 already does a pretty good job.

my proposal is to add the following definition (based on 3.8.1.2) to a new =E2=80=9ETerminology" section or to section 2.1.2:

A sender constrained access token scopes the applicability of an access token to a certain sender.=C2=A0 This sender is
obliged to demonstrate knowledge of a certain secret as prerequisite for the acceptance of that token at the recipient (e.g. a resource server).

>
> I was, however, wondering about the subtle implication of the requirement for sender constrained tokens. My understanding of the token binding discussion, which is one of the ways to provide sender-constrained tokens, is that we don=E2=80=99t have good faith in seeing deployment anytime soon. Hence, we are essentially (reading in between the lines of Section 3.8.1.2) saying that you cannot use implicit grant in a practical setup for the web*..

The text shall convey that implicit must not be used at all. The main reason being it is unprotected against token injection and additionally also cannot sender constrain tokens.

The second part of the statement relates to other response types and conditionally opens the MUST NOT in case they are protected against injection (which is true for the listed response types) and can issue sender constrained tokens (which does not work today but might work in the future).

kind regards,
Torsten.

>=C2=A0
> Am I misunderstanding it?

>=C2=A0
> Ciao
> Hannes
>=C2=A0
> PS: The IoT case is likely different.
>=C2=A0
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki
> Sent: Saturday, December 1, 2018 3:18 AM
> To: Torsten Lodderstedt <torsten@lodderstedt.net>
> Cc: Daniel Fett <fett@danielfett.de>; IETF oauth WG <= oauth@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
>=C2=A0
> +1
>=C2=A0
> I would also like to ensure there is a clear definition of "sender constrained" tokens in this BCP.
>=C2=A0
> Aaron
>=C2=A0
>=C2=A0
> On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
> Hi all,
>
> based on your feedback on the list and off list, Daniel and I polished the text. That=E2=80=99s our proposal:
>
> =E2=80=94
> In order to avoid these issues, clients MUST NOT use the implicit
> grant (response type "token") or any other response type issuing access
> tokens in the authorization response, such as "token id_token&quo= t; and "code token id_token=E2=80=9C,
> unless the issued access tokens are sender-constrained and access token injection in
> the authorization response is prevented.
> =E2=80=94
>
> Explantation:
> - we wanted to have the right balance between a generic definition of the response types we do not recommend/allow to be used and a concrete/actionable list of the affected response types.
> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported by William
>
> We look forward to seeing your feedback.
>
> kind regards,
> Torsten.=C2=A0
>
> > Am 29.11.2018 um 15:15 schrieb John Bradley <ve7jtb@ve7jtb.com<= /a>>:
> >
> > I am ok with that.=C2=A0
> >
> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <torsten@lodderstedt.net wrote:
> >
> > > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@nri.co.jp>:
> > >
> > > That works.
> >
> > Good!
> >
> > I just realized this text has an issue with =E2=80=9Etoken=E2=80= =9C (only). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token woul= d sender constrained. This completely ignores the fact implicit also shall be abandoned because of its vulnerability for access token injection.
> >
> > I therefore propose a modified text:
> >
> >=C2=A0 =C2=A0 In order to avoid these issues, Clients SHOULD NOT use the implicit
> >=C2=A0 =C2=A0 grant. Furthermore, clients SHOULD only use other response types causing the authorization server to
> >=C2=A0 =C2=A0 issue an access token in the authorization response, if the particular response type detects access token
> >=C2=A0 =C2=A0 injection and the issued access tokens are sender-constrained.
> >
> > Or we just state:
> >
> >=C2=A0 =C2=A0In order to avoid these issues, Clients SHOULD NOT use the response type =E2=80=9Etoken". The response types > > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token= =E2=80=9C SOULD NOT be used, if the issued access tokens are not
> > sender-constrained.
> >
> > >
> > > In fact, I would further go and say MUST NOT but that probably is too much for a security consideration.
> > >
> >
> > Mike suggested to go with a SHOULD NOT to get the message out but give implementors time to move/change.
> >
> > > Best,
> > >
> > > Nat
> > >
> > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276=
> > >
> > > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=E6= =9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=81= =BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=86= =E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=E3= =82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81= =99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=AA= =E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=E3= =81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=81= =8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=A5= =E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=E4= =BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=89= =8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=BE= =E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=E4= =B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
> > >
> > > PLEASE READ :This e-mail is confidential and intended for the named recipient only.
> > > If you are not an intended recipient, please notify the sender and delete this e-mail.
> > >=C2=A0
> > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt <to= rsten@lodderstedt.net>
> > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6= =97=A5, 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
> > > =E5=AE=9B=E5=85=88: n-sakimura
> > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
> > >=C2=A0
> > > Hi Nat,
> > >
> > >> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nri.co.jp>:
> > >>
> > >> I would support
> > >>
> > >> 1) clearly defining Implicit as the flow that returns access token from the authorization endpoint ( some people confuses implicit as the flow that returns ID Token in the front channel)
> > >
> > > That=E2=80=99s the current text:
> > >
> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
> > >=C2=A0 =C2=A0 grant or any other response type causing the authorization server to
> > >=C2=A0 =C2=A0 issue an access token in the authorization response.
> > >
> > > What would you like to modify?
> > >
> > >>
> > >> 2) Banning the returning of the access token that are not sender constrained from the authorization endpoint
> > >
> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
> > >=C2=A0 =C2=A0 grant or any other response type causing the authorization server to
> > >=C2=A0 =C2=A0 issue an access token in the authorization response, if this access tokens is not sender-constraint.
> > >
> > > What about this?
> > >
> > > kind regards,
> > > Torsten.
> > >
> > >>
> > >> Best,
> > >>
> > >> Nat
> > >>
> > >>
> > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
> > >>=C2=A0
> > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-bounces= @ietf.org> (Dick Hardt <dick.hardt@gmail.com> =E3=81=AE= =E4=BB=A3=E7=90=86)
> > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C= =E6=97=A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
> > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
> > >> Cc: oauth@ietf.org
> > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics= -- Recommend authorization code instead of implicit
> > >>=C2=A0
> > >> +1
> > >>
> > >> While there are various mechanisms to alleviate some of the issues of implicit, I don't think we can recommend specifics, and there may be future ones in the future. I think we all agree that implicit without any mitigation is problematic.
> > >>
> > >> How about we recommend against using implicit alone?
> > >>
> > >>
> > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
> > >> Hi all,
> > >>
> > >> The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (see https://datatracker.ietf.org/meet= ing/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-0= 1).
> > >>
> > >> A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list..
> > >>
> > >> Please provide a response by December 3rd.
> > >>
> > >> Ciao
> > >>
> > >> Hannes & Rifaat
> > >>
> > >>=C2=A0
> > >>
> > >> 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 the information in any medium. Thank you.
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAuth@ietf.org
> > >> https://www.ietf.org/mailma= n/listinfo/oauth
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAuth@ietf.org
> > >> https://www.ietf.org/mailma= n/listinfo/oauth
> > >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinf= o/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oau= th
> --
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk
>=C2=A0
> 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 the information in any medium. Thank you.

_______________________________________________
OAuth mailing list
OAut= h@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
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000042cf43057c1ce1f5-- From nobody Mon Dec 3 06:43:38 2018 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 BBFC0130E5E for ; Mon, 3 Dec 2018 06:43:36 -0800 (PST) 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 JJkYqtiR1dGN for ; Mon, 3 Dec 2018 06:43:32 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.28]) (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 97E32130E7F for ; Mon, 3 Dec 2018 06:43:32 -0800 (PST) Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gTpRX-0002gR-O7; Mon, 03 Dec 2018 15:43:27 +0100 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8D63EF4E-342E-4E70-A137-7FD59F0ED9F5"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Mon, 3 Dec 2018 15:43:26 +0100 In-Reply-To: Cc: Dominick Baier , Vittorio Bertocci , Daniel Fett , IETF oauth WG To: John Bradley References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 03 Dec 2018 14:43:37 -0000 --Apple-Mail=_8D63EF4E-342E-4E70-A137-7FD59F0ED9F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 03.12.2018 um 12:59 schrieb John Bradley : >=20 > I agree that the hair on fire messaging is over stated. =20 >=20 > This is still a document in development and not yet a BCP. No new = vunerable have been found, but attackers are evolving. =20 You are right. Basically, RFC 6749=E2=80=99s security consideration = section already states the vulnerabilities: =C2=A7 10.3 =E2=80=9EWhen using the implicit grant type, the access token is = transmitted in the URI fragment, which can expose it to unauthorized parties.=E2=80= =9C =C2=A7 10.16 =E2=80=9EIn the implicit flow (response_type=3Dtoken), the attacker can = easily switch the token in the response from the authorization server, replacing the real access token with the one previously issued to the attacker." Retrospectively, I=E2=80=99m asking myself why we ever agreed to move = the spec forward given these issues at hand. Why the change now? Not only attackers are evolving, also the use cases for OAuth and the = dynamics of the respective deployments have changed significantly. Just = to give some example, open banking was not a topic in 2012. The = discovery of the mix up attack was kind of a wake up call in late 2015. = We realized token leakage and replay is becoming a major issue. That are the reasons why we started working on the Security BCP as an = update of RFC 6749/4750 security considerations and also RFC 6819. The BCP, by the way, deprecates several other practices: For example, it = introduces exact URI matching, one time use CSRF tokens in state, and = obliges implementors to use code in conjunction with PKCE or nonce, = effectively deprecating the pure code flow. No one every complaint about = this. We also recommend use of sender constraint access tokens simply because = we came to the conclusion focussing on token leakage prevention only = would be a rather thin defense. >=20 > These are security best practices for new implimentations. Not a = recommendation to rip things out. As applications are updated they = need to consider the BCP recommendations. =20 I would go one step further. Given the fact we pointed out the risk = associated with implicit in RFC 6749, implementors should have conducted = a risk assessment before they implemented implicit. If they haven=E2=80=99= t, they should do now using the information we provide in the BCP. If = they conclude by finding application specific mitigations or just assume = the risk, that fine with me.=20 But I don=E2=80=99t want to give implementors the =E2=80=9Eblessing=E2=80=9C= (as Vittorio called it) of this working group to use a flow with such = know security issues, especially since a simpler and more secure option = is available.=20 BTW: I would be ok with making the respective text a SHOULD NOT again = since that would serve the purpose just fine.=20 >=20 > We do need to be careful about how our discussions are interpreted. =20= That=E2=80=99s certainly true. On the other hand, most developers = don=E2=80=99t know anything about the current state of OAuth. What I = have seen in the wild makes me nervous. People think implicit is the = =E2=80=9Elightweight and easy to use=E2=80=9C version of OAuth and = don=E2=80=99t ask for the security implications. That=E2=80=99s why I = think we need to find ways to get developers and API designers educated = on how to properly use OAuth. >=20 > There are also worse things people could do than implicit if we scare = them back to proprietary solutions. =20 Why do you see that risk? We offer an alternative solution, which is = simple to use, secure, and versatile. =20 kind regards, Torsten.=20 >=20 > John B. =20 >=20 > On Mon, Dec 3, 2018, 12:50 PM Dominick Baier = I agree with Vittorio -=20 >=20 > While we all agree that implicit is outdated and we can do better (and = it is indeed good that this discussion has finally started for real) - = the communication around the (preliminary) results of the BCP was = unfortunate and not very responsible - quoting: >=20 > =E2=80=9CSimply put, the implicit grant=E2=80=99s security is broken = beyond repair. It is vulnerable to access token leakage, meaning an = attacker can exfiltrate valid access tokens and use it to his own = benefit. This might for example result in the attacker accessing the = legit user=E2=80=99s health record or initiating a payment, from her = bank account." >=20 > This indeed, as Vittorio pointed out, sounds like a new vulnerability = has been found. This spreads FUD ;) >=20 > Also - simply saying =E2=80=9Cimplicit is evil - switch to code=E2=80=9D= means for most people also using refresh token - so we are treating = access tokens in the URL with refresh tokens in session storage (over = simplified - but you get the idea). >=20 > Again we all agree that implicit can be improved - but there are some = issues to be sorted first to make this a smooth transition. >=20 > My 2c >=20 > =E2=80=94=E2=80=94=E2=80=94 > Dominick >=20 > On 3. December 2018 at 11:59:44, Vittorio Bertocci = (vittorio.bertocci=3D40auth0.com@dmarc.ietf.org) wrote: >=20 >> Hi all, >> Sorry for stepping a bit back from the level of detail the discussion = already reached. I do have some specific comments on the document, but = before bringing those up I wanted to raise a general problem I am = experiencing with this initiative.. >>=20 >> I have a number of customers that are reacting to the news with = distress. The language used in some of the communications associated = with this initiative made them feel like some new vulnerability was = discovered, calling for immediate action. >> The fact is that as far as I can tell, no new, previously unknown = fact informed this decision: no new vulnerability, nor any new = technology that wasn=E2=80=99t available before (the sender constrain is = still not actionable for most customers). The risks of the implicit flow = aren=E2=80=99t bigger now than they were in October. >> That doesn=E2=80=99t mean that we cannot improve guidance, of course- = and now is as good as any other moment to do so: but at the same time, I = think we need to be cognizant of the *immense* investment in existence = today in form of SDKs and applications built on those SDKs that are = predicated on implicit flow, with our blessing: until very recently the = official position was =E2=80=9Cimplicit is bad but it=E2=80=99s the best = we have noawadays=E2=80=9D. >> To me, being cognizant of that means that we should help people to = formulate action proportionate to the risk. And if until yesterday we = were ok with them using implicit, we cannot realistically expect anyone = to start changing all of their apps today, but that=E2=80=99s the = message many customers are getting.=20 >> TL;DR, I think the community would be well served by clarifying in = the security document that there is no new risk and their existing = codebase didn=E2=80=99t suddenly become less secure and in *urgent* need = to update. >> To attempt a metaphor. We discovered a new drug against headache with = milder side effects than the one we were prescribing them until now, but = that doesn=E2=80=99t mean that they should throw away all the stash they = have of the older drug. The old drug will keep working as it worked = until now. Once they run out of their stash, they should get the new = one; or if the old side effects were particularly bad for them, perhaps = they should consider switching today. But this isn=E2=80=99t a recall.=20= >>=20 >> And if in fact this group thinks it should be a recall and get = everyone off the old one right now, I think we=E2=80=99ll need to make a = much stronger case than we have done so far. >>=20 >> Thoughts? >>=20 >> Thanks >> V. >> =20 >>=20 >> On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt = wrote: >> Hi Hannes, >>=20 >> > Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig = : >> > >> > I agree with Aaron here and I think Section 3.8.1.2 of = draft-ietf-oauth-security-topics-10 already does a pretty good job. >>=20 >> my proposal is to add the following definition (based on 3.8.1.2) to = a new =E2=80=9ETerminology" section or to section 2.1.2: >>=20 >> A sender constrained access token scopes the applicability of an = access token to a certain sender. This sender is >> obliged to demonstrate knowledge of a certain secret as prerequisite = for the acceptance of that token at the recipient (e.g. a resource = server). >>=20 >> > >> > I was, however, wondering about the subtle implication of the = requirement for sender constrained tokens. My understanding of the token = binding discussion, which is one of the ways to provide = sender-constrained tokens, is that we don=E2=80=99t have good faith in = seeing deployment anytime soon. Hence, we are essentially (reading in = between the lines of Section 3.8.1.2) saying that you cannot use = implicit grant in a practical setup for the web*.. >>=20 >> The text shall convey that implicit must not be used at all. The main = reason being it is unprotected against token injection and additionally = also cannot sender constrain tokens. >>=20 >> The second part of the statement relates to other response types and = conditionally opens the MUST NOT in case they are protected against = injection (which is true for the listed response types) and can issue = sender constrained tokens (which does not work today but might work in = the future). >>=20 >> kind regards, >> Torsten. >>=20 >> >=20 >> > Am I misunderstanding it? >>=20 >> >=20 >> > Ciao >> > Hannes >> >=20 >> > PS: The IoT case is likely different. >> >=20 >> > From: OAuth On Behalf Of Aaron Parecki >> > Sent: Saturday, December 1, 2018 3:18 AM >> > To: Torsten Lodderstedt >> > Cc: Daniel Fett ; IETF oauth WG = >> > Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend = authorization code instead of implicit >> >=20 >> > +1 >> >=20 >> > I would also like to ensure there is a clear definition of "sender = constrained" tokens in this BCP. >> >=20 >> > Aaron >> >=20 >> >=20 >> > On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt = wrote: >> > Hi all, >> > >> > based on your feedback on the list and off list, Daniel and I = polished the text. That=E2=80=99s our proposal: >> > >> > =E2=80=94 >> > In order to avoid these issues, clients MUST NOT use the implicit >> > grant (response type "token") or any other response type issuing = access >> > tokens in the authorization response, such as "token id_token" and = "code token id_token=E2=80=9C, >> > unless the issued access tokens are sender-constrained and access = token injection in >> > the authorization response is prevented. >> > =E2=80=94 >> > >> > Explantation: >> > - we wanted to have the right balance between a generic definition = of the response types we do not recommend/allow to be used and a = concrete/actionable list of the affected response types. >> > - we changed from SHOULD NOT to MUST NOT as suggested by Nat and = supported by William >> > >> > We look forward to seeing your feedback. >> > >> > kind regards, >> > Torsten.=20 >> > >> > > Am 29.11.2018 um 15:15 schrieb John Bradley : >> > > >> > > I am ok with that.=20 >> > > >> > > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt = > > > >> > > > Am 28.11.2018 um 23:50 schrieb n-sakimura = : >> > > > >> > > > That works. >> > > >> > > Good! >> > > >> > > I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C= (only). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token = would sender constrained. This completely ignores the fact implicit also = shall be abandoned because of its vulnerability for access token = injection. >> > > >> > > I therefore propose a modified text: >> > > >> > > In order to avoid these issues, Clients SHOULD NOT use the = implicit >> > > grant. Furthermore, clients SHOULD only use other response = types causing the authorization server to >> > > issue an access token in the authorization response, if the = particular response type detects access token >> > > injection and the issued access tokens are sender-constrained. >> > > >> > > Or we just state: >> > > >> > > In order to avoid these issues, Clients SHOULD NOT use the = response type =E2=80=9Etoken". The response types >> > > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token = id_token=E2=80=9C SOULD NOT be used, if the issued access tokens are not >> > > sender-constrained. >> > > >> > > > >> > > > In fact, I would further go and say MUST NOT but that probably = is too much for a security consideration. >> > > > >> > > >> > > Mike suggested to go with a SHOULD NOT to get the message out but = give implementors time to move/change. >> > > >> > > > Best, >> > > > >> > > > Nat >> > > > >> > > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276 >> > > > >> > > > = =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=E6= =9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=81= =BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=86= =E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=E3= =82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81= =99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=AA= =E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=E3= =81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=81= =8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=A5= =E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=E4= =BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=89= =8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=BE= =E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=E4= =B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 >> > > > >> > > > PLEASE READ :This e-mail is confidential and intended for the = named recipient only. >> > > > If you are not an intended recipient, please notify the sender = and delete this e-mail. >> > > >=20 >> > > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt = >> > > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5= , 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C >> > > > =E5=AE=9B=E5=85=88: n-sakimura >> > > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org >> > > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- = Recommend authorization code instead of implicit >> > > >=20 >> > > > Hi Nat, >> > > > >> > > >> Am 28.11.2018 um 21:10 schrieb n-sakimura = : >> > > >> >> > > >> I would support >> > > >> >> > > >> 1) clearly defining Implicit as the flow that returns access = token from the authorization endpoint ( some people confuses implicit as = the flow that returns ID Token in the front channel) >> > > > >> > > > That=E2=80=99s the current text: >> > > > >> > > > In order to avoid these issues, Clients SHOULD NOT use the = implicit >> > > > grant or any other response type causing the authorization = server to >> > > > issue an access token in the authorization response. >> > > > >> > > > What would you like to modify? >> > > > >> > > >> >> > > >> 2) Banning the returning of the access token that are not = sender constrained from the authorization endpoint >> > > > >> > > > In order to avoid these issues, Clients SHOULD NOT use the = implicit >> > > > grant or any other response type causing the authorization = server to >> > > > issue an access token in the authorization response, if this = access tokens is not sender-constraint. >> > > > >> > > > What about this? >> > > > >> > > > kind regards, >> > > > Torsten. >> > > > >> > > >> >> > > >> Best, >> > > >> >> > > >> Nat >> > > >> >> > > >> >> > > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B >> > > >>=20 >> > > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth = (Dick Hardt =E3=81=AE=E4=BB=A3=E7=90=86) >> > > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5= , 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C >> > > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig >> > > >> Cc: oauth@ietf.org >> > > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- = Recommend authorization code instead of implicit >> > > >>=20 >> > > >> +1 >> > > >> >> > > >> While there are various mechanisms to alleviate some of the = issues of implicit, I don't think we can recommend specifics, and there = may be future ones in the future. I think we all agree that implicit = without any mitigation is problematic. >> > > >> >> > > >> How about we recommend against using implicit alone? >> > > >> >> > > >> >> > > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig = wrote: >> > > >> Hi all, >> > > >> >> > > >> The authors of the OAuth Security Topics draft came to the = conclusion that it is not possible to adequately secure the implicit = flow against token injection since potential solutions like token = binding or JARM are in an early stage of adoption. For this reason, and = since CORS allows browser-based apps to send requests to the token = endpoint, Torsten suggested to use the authorization code instead of the = implicit grant in call cases in his presentation (see = https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-= draft-ietf-oauth-security-topics-01). >> > > >> >> > > >> A hum in the room at IETF#103 concluded strong support for his = recommendations. We would like to confirm the discussion on the list.. >> > > >> >> > > >> Please provide a response by December 3rd. >> > > >> >> > > >> Ciao >> > > >> >> > > >> Hannes & Rifaat >> > > >> >> > > >>=20 >> > > >> >> > > >> 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 the information in any medium. Thank you. >> > > >> _______________________________________________ >> > > >> 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 >> > -- >> > ---- >> > Aaron Parecki >> > aaronparecki.com >> > @aaronpk >> >=20 >> > 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 = the information in any medium. Thank you. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________=20 >> OAuth mailing list=20 >> OAuth@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/oauth=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_8D63EF4E-342E-4E70-A137-7FD59F0ED9F5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODEyMDMxNDQzMjZaMC8GCSqGSIb3DQEJBDEiBCAP 5ap5m7lc0dQWPwT9XWIoYBvlZtTPRM8yq6r386IyczCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAKcJZzQLONZ3G7xmPRCCWSpcH jeefSgVf+uK8cvqOiKEkFzsNNVoF6Btzdhx4Edymd4CYO67dyGmxPYek52E1reEl2PLrPqLp83Gk +6NOCFho/KfvKHk1x9WnKkNGrO4lANJsSwgZ4IKrSMhJX1j+7LCRNlwF3rKwR1uUG7HwGlwlg7SS qkWlKTKl0NXA7CgcYWaBTEsLj76C9bResenNu3HEuIsUiAa/mY4ebG3xd1mbureGyY4yLto6cOd3 MDAeAJHs+a46HjgGXo6S7p0Xqb3hm8xoPXZREW28FrTcBEKV/NNKCcJSd0otiu9p40LcCkBxGNsK Q8Wdk7kdtpUolwAAAAAAAA== --Apple-Mail=_8D63EF4E-342E-4E70-A137-7FD59F0ED9F5-- From nobody Mon Dec 3 06:57:33 2018 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 EE7B9130E23 for ; Mon, 3 Dec 2018 06:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 ejbDvW_0Sdqc for ; Mon, 3 Dec 2018 06:57:27 -0800 (PST) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 6919E130E19 for ; Mon, 3 Dec 2018 06:57:27 -0800 (PST) Received: by mail-it1-x12b.google.com with SMTP id i145so9644193ita.4 for ; Mon, 03 Dec 2018 06:57:27 -0800 (PST) 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; bh=zWdCeTzcmfGEGFU8iYGOFVaQT//lO/hz4UeeaFtAh/I=; b=rLS4Z09aLdqseMBA1R9oJ7N0f7bPJATv2ELE4Gu1v9+r/7Q818AkTZYusq24nh3flR frusX7pFiIG4zLZw/fsBXZ7Nj/XxdK0YaR72p40q4COd7ntw4MqOkKqsR+mqKi7uaJJG d3p0caKnALZdHJjVGBcCYRwHu87yyo4rlv/cTYvi5jjJ5qVczBj+p+lvjfPiDpXvAAVt px46cBBZnNu/9ndrc6VFp1ya8olQ69X93Snql6tLuPJCa7MUEAl1x38R6ndoNXBXPRwX DiuJjfosuuzkfRFyGFbEqVlej+yZ1rSwLuFacP/kDDdr2NEqj5Lh297RabB5Sdd0j+4e 7cYg== 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=zWdCeTzcmfGEGFU8iYGOFVaQT//lO/hz4UeeaFtAh/I=; b=L4RgsAZv0Y7FTf+Cv9W2UooTYKRoy9eGPrBfnVfksBYq4tOkaGXlHRwTyryNPuU/ax OgzPkfTpbX/NQSPEgiBUOTlOELVZPzMNPfcjX1Mnky4IK5WCFgICeyiQIKvpeD/j4Dtw FKMQH47ASvp7yEeqJcDq+udnK9bKyD0nwVBitktYnmIVMbsheeMZKtfuA/Piz1JJoxeP nEbBsA6dmUqIph3QIU+UxlGkV3kY3wsyuqFMgokjPivllK3X5y4EZ8ccOWvXNhCDSoOC qhZyeiCXYMTGTrXRtlUwZgQGHNtfeGXHPlPclv3oa/vxx5dZJ0YhhOLJTrr2W+QkUhEP jWIQ== X-Gm-Message-State: AA+aEWbj2Dla4fnLBy4+veJb/uqlkPGDpfbWMukCFxCv+zhfreIo1RUX vWw0f2Vfett1D81DpKz/9uVPcnjI/II= X-Google-Smtp-Source: AFSGD/V3rRfCPAC+TBjH4Z+M99snJBKqRfa8vpEgTbn5Sw/N+UrFzVx8OktyTg0Z5MubAB1n7x2J7A== X-Received: by 2002:a02:350a:: with SMTP id k10mr14813732jaa.139.1543849046372; Mon, 03 Dec 2018 06:57:26 -0800 (PST) Received: from mail-it1-f175.google.com (mail-it1-f175.google.com. [209.85.166.175]) by smtp.gmail.com with ESMTPSA id 195sm3676652itm.2.2018.12.03.06.57.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Dec 2018 06:57:25 -0800 (PST) Received: by mail-it1-f175.google.com with SMTP id x19so9678811itl.1 for ; Mon, 03 Dec 2018 06:57:24 -0800 (PST) X-Received: by 2002:a24:2d0b:: with SMTP id x11mr8632811itx.85.1543849044389; Mon, 03 Dec 2018 06:57:24 -0800 (PST) MIME-Version: 1.0 References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> <7FEF0314-88F2-46C7-A22D-C794CC1BB6A0@lodderstedt.net> In-Reply-To: <7FEF0314-88F2-46C7-A22D-C794CC1BB6A0@lodderstedt.net> From: Aaron Parecki Date: Mon, 3 Dec 2018 06:57:12 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Torsten Lodderstedt Cc: IETF oauth WG , John Bradley Content-Type: multipart/alternative; boundary="000000000000e0b372057c1f5d05" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 03 Dec 2018 14:57:31 -0000 --000000000000e0b372057c1f5d05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adding something to that effect, but would like to make it clear that this removes the app from being covered under this BCP. How about: --- Implementations MAY consider moving the authorization code exchange and handling of access and refresh tokens to a backend component in order to avoid the risks inherent in handling access tokens from a purely browser based app. In this case, the backend component can be a confidential client and can be secured accordingly. Security of the connection between code running in the browser and this backend component is assumed to utilize browser-level protection mechanisms. Details are out of scope of this document. --- On Mon, Dec 3, 2018 at 3:15 AM Torsten Lodderstedt wrote: > Interesting. Even on this list people felt to see that moving some logic > to a backend could solve some of the problems raised. What I want to conv= ey > is: the solution to a problem in the OAuth space does not necessarily nee= d > to be found on the OAuth protocol level. That=E2=80=99s a best practice i= n the same > way as some OAuth pattern. > > What I=E2=80=99m suggesting is a statement in the BCP like > > =E2=80=94 > Implementations MAY consider to move authorization code exchange and > handling of access and refresh tokens to a backend component in order to > fulfill their security goals. > > Security of the connection between code running in the browser and this > backend component is assumed to utilize browser-level protection > mechanisms. Details are out of scope of this document. > =E2=80=94 > > > Am 03.12.2018 um 11:19 schrieb John Bradley : > > > > This is my point. > > > > From a security perspective we have a server based confidential client. > The fact that it has a angular or other JS UI protected by a cookie seem= s > to not be especially relucent to OAuth. > > > > Perhaps from the developer point of view they have a JS SPA and the onl= y > difference to them is in one case they are including the OAuth client and > in the other they are using a server based proxy. So they see it as the > same. > > > > Perhaps it is perspective. > > > > On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki > In this type of deployment, as far as OAuth is concerned, isn't the > backend web server a confidential client? Is there even anything unique t= o > this situation as far as OAuth security goes? > > > > I wouldn't have expected an Angular app that talks to its own server > backend that's managing OAuth credentials to fall under the umbrella of > this BCP. > > > > ---- > > Aaron Parecki > > aaronparecki.com > > > > > > > > On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > the UI is rendered in the frontend, UI control flow is in the frontend. > just a different cut through the web app=E2=80=99s layering > > > > All Angular apps I have seen so far work that way. And it makes a lot o= f > sense to me. The backend can aggregate and optimize access to the > underlying services without the need to fully expose them. > > > > Am 02.12.2018 um 00:44 schrieb John Bradley : > > > >> How is that different from a regular server client with a web interfac= e > if the backed is doing the API calls to the RS? > >> > >> > >> > >> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: > >>> I forgot to mention another (architectural) option: split an > application into frontend provided by JS in the browser and a backend, > which takes care of the business logic and handles tokens and API access. > Replay detection at the interface between SPA and backend can utilize > standard web techniques (see OWASP). The backend in turn can use mTLS for > sender constraining. > >>> > >>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt < > torsten@lodderstedt.net>: > >>> > >>>> IMHO the best mechanism at hand currently to cope with token > leakage/replay in SPAs is to use refresh tokens (rotating w/ replay > detection) and issue short living and privilege restricted access tokens. > >>>> > >>>> Sender constrained access tokens in SPAs need adoption of token > binding or alternative mechanism. mtls could potentially work in > deployments with automated cert rollout but browser UX and interplay with > fetch needs some work. We potentially must consider to warm up applicatio= n > level PoP mechanisms in conjunction with web crypto. Another path to be > evaluated could be web auth. > >>>> > >>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig < > Hannes.Tschofenig@arm.com>: > >>>> > >>>>> I share the concern Brian has, which is also the conclusion I came > up with in my other email sent a few minutes ago. > >>>>> > >>>>> > >>>>> > >>>>> From: OAuth On Behalf Of Brian Campbell > >>>>> Sent: Friday, November 30, 2018 11:43 PM > >>>>> To: Torsten Lodderstedt > >>>>> Cc: oauth > >>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >>>>> > >>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen = : > >>>>> > > >>>>> > So you mean at the resource server ensuring the token was really > issued to the client? Isn't that an inherent limitation of all bearer > tokens (modulo HTTP token binding, which is still some time off)? > >>>>> > >>>>> Sure. That=E2=80=99s why the Security BCP recommends use of TLS-bas= ed > methods for sender constraining access tokens ( > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2= ..2). > Token Binding for OAuth ( > https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as > Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-1= 2) > are the options available. > >>>>> > >>>>> > >>>>> > >>>>> Unfortunately even when using the token endpoint, for SPA / > in-browser client applications, the potential mechanisms for > sender/key-constraining access tokens don't work very well or maybe don't > work at all. So I don't know that the recommendation is very realistic. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> 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. > >>>>> > >>>>> IMPORTANT NOTICE: The contents of this email and any attachments ar= e > 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 > >>> > >>> > >>> _______________________________________________ > >>> 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 > > -- ---- Aaron Parecki aaronparecki.com @aaronpk --000000000000e0b372057c1f5d05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adding something to that effect, but would= like to make it clear that this removes the app from being covered under t= his BCP. How about:

---
Implementations MAY consider moving the author= ization code exchange and handling of access and refresh tokens to a backen= d component in order to avoid the risks inherent in handling access tokens = from a purely browser based app. In this case, the backend component can be= a confidential client and can be secured accordingly.

Security of t= he connection between code running in the browser and this backend componen= t is assumed to utilize browser-level protection mechanisms. Details are ou= t of scope of this document.=C2=A0
---



<= /div>

Interesting. Even on this list people felt to see that moving som= e logic to a backend could solve some of the problems raised. What I want t= o convey is: the solution to a problem in the OAuth space does not necessar= ily need to be found on the OAuth protocol level. That=E2=80=99s a best pra= ctice in the same way as some OAuth pattern.

What I=E2=80=99m suggesting is a statement in the BCP like

=E2=80=94
Implementations MAY consider to move authorization code exchange and handli= ng of access and refresh tokens to a backend component in order to fulfill = their security goals.

Security of the connection between code running in the browser and this bac= kend component is assumed to utilize browser-level protection mechanisms. D= etails are out of scope of this document.
=E2=80=94

> Am 03.12.2018 um 11:19 schrieb John Bradley <ve7jtb@ve7jtb.com>:
>
> This is my point.=C2=A0
>
> From a security perspective we have a server based confidential client= .=C2=A0 =C2=A0The fact that it has a angular or other JS UI protected by a = cookie seems to not be especially relucent to OAuth.=C2=A0
>
> Perhaps from the developer point of view they have a JS SPA and the on= ly difference to them is in one case they are including the OAuth client an= d in the other they are using a server based proxy. So they see it as the s= ame.
>
> Perhaps it is perspective.
>
> On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki <aaron@parecki.com wrote:
> In this type of deployment, as far as OAuth is concerned, isn't th= e backend web server a confidential client? Is there even anything unique t= o this situation as far as OAuth security goes?
>
> I wouldn't have expected an Angular app that talks to its own serv= er backend that's managing OAuth credentials to fall under the umbrella= of this BCP.
>
> ----
> Aaron Parecki
> aaronparecki.com
>
>
>
> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt <torsten@lodderstedt.net&= gt; wrote:
> the UI is rendered in the frontend, UI control flow is in the frontend= . just a different cut through the web app=E2=80=99s layering
>
> All Angular apps I have seen so far work that way. And it makes a lot = of sense to me. The backend can aggregate and optimize access to the underl= ying services without the need to fully expose them.
>
> Am 02.12.2018 um 00:44 schrieb John Bradley <ve7jtb@ve7jtb.com>:
>
>> How is that different from a regular server client with a web inte= rface if the backed is doing the API calls to the RS?
>>
>>
>>
>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>> I forgot to mention another (architectural) option: split an a= pplication into frontend provided by JS in the browser and a backend, which= takes care of the business logic and handles tokens and API access. Replay= detection at the interface between SPA and backend can utilize standard we= b techniques (see OWASP). The backend in turn can use mTLS for sender const= raining.
>>>
>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <torsten@lodderstedt.n= et>:
>>>
>>>> IMHO the best mechanism at hand currently to cope with tok= en leakage/replay in SPAs is to use refresh tokens (rotating w/ replay dete= ction) and issue short living and privilege restricted access tokens.
>>>>
>>>> Sender constrained access tokens in SPAs need adoption of = token binding or alternative mechanism. mtls could potentially work in depl= oyments with automated cert rollout but browser UX and interplay with fetch= needs some work. We potentially must consider to warm up application level= PoP mechanisms in conjunction with web crypto. Another path to be evaluate= d could be web auth.
>>>>
>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <Hannes.Tschofenig= @arm.com>:
>>>>
>>>>> I share the concern Brian has, which is also the concl= usion I came up with in my other email sent a few minutes ago.
>>>>>
>>>>>=C2=A0
>>>>>
>>>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Cam= pbell
>>>>> Sent: Friday, November 30, 2018 11:43 PM
>>>>> To: Torsten Lodderstedt <torsten@lodderstedt.net>
>>>>> Cc: oauth <oauth@ietf.org>
>>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-ba= sed-apps-00
>>>>>
>>>>>=C2=A0
>>>>>
>>>>>=C2=A0
>>>>>
>>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt &l= t;torsten@lodd= erstedt.net> wrote:
>>>>>
>>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.co= m>:
>>>>> >
>>>>> > So you mean at the resource server ensuring the t= oken was really issued to the client? Isn't that an inherent limitation= of all bearer tokens (modulo HTTP token binding, which is still some time = off)?
>>>>>
>>>>> Sure. That=E2=80=99s why the Security BCP recommends u= se of TLS-based methods for sender constraining access tokens (https://tools.ietf.org/html/draft-ie= tf-oauth-security-topics-09#section-2..2). Token Binding for OAuth (https://tools.ietf.org/html/draft-ietf-oa= uth-token-binding-08) as well as Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are t= he options available.
>>>>>
>>>>>=C2=A0
>>>>>
>>>>> Unfortunately even when using the token endpoint, for = SPA / in-browser client applications, the potential mechanisms for sender/k= ey-constraining access tokens don't work very well or maybe don't w= ork at all. So I don't know that the recommendation is very realistic.<= br> >>>>>
>>>>>=C2=A0
>>>>>
>>>>>
>>>>> CONFIDENTIALITY NOTICE: This email may contain confide= ntial and privileged material for the sole use of the intended recipient(s)= . Any review, use, distribution or disclosure by others is strictly prohibi= ted..=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 attac= hments from your computer. Thank you.
>>>>>
>>>>> IMPORTANT NOTICE: The contents of this email and any a= ttachments are confidential and may also be privileged. If you are not the = intended recipient, please notify the sender immediately and do not disclos= e the contents to any other person, use it for any purpose, or store or cop= y the information in any medium. Thank you.
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oa= uth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>>
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> > _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

--
----
Aaron Parecki
<= div>aaronparecki.com<= /a>

--000000000000e0b372057c1f5d05-- From nobody Mon Dec 3 07:38:53 2018 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 136A3130E5F for ; Mon, 3 Dec 2018 07:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=ve7jtb-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 TwMxfsRqcW6u for ; Mon, 3 Dec 2018 07:38:48 -0800 (PST) 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 181B612D7EA for ; Mon, 3 Dec 2018 07:38:46 -0800 (PST) Received: by mail-wm1-x32b.google.com with SMTP id a18so6165978wmj.1 for ; Mon, 03 Dec 2018 07:38:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vuj662wPmjnJs7s7we5Yztp5g3419aBmALdBYahchpw=; b=F3iUN6OeXotToJZ/1OFFAg7lT2fRbMfYbjrnmb/f+8Rd/lyD3Io0HN6vF64nYcFVQv Z8Z2sd2EbtOWrkNVMvB/iYC1cU8YC7FkgGVFZI9iifzRutoOnCWj/u2nC1+Ky1XabeY6 4eHaFb05Q3RjIxg+8NWfj6yuc2q69CYvSDOVwP7uMCdNfpR/BCWLo6YjfihTF0DBUg/L qqCtD5Lr8/D2znkNCnGvpoOFhFAm4meS/ZFPPD4WGQQw/wP33Slufb6BHObb0lEWmFkd h8GmuJmobETacdd2d+xOR+CNBzSqRU+CCdKM+dJApK6VtF8Q9YAAYfe3O4S05KcZ5RSr 158w== 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=vuj662wPmjnJs7s7we5Yztp5g3419aBmALdBYahchpw=; b=nDuH8IwfnDmT6Yo6/ldzkgOgaxu6BLImEshiSpCA1XKho8zvkDY22nAFcGCrv81bYS XtscVTq9CcTOk54A0eXC4blwgKVu6K7eCEtdYXJeeJZ7wCiyld0YOI4tbMoI9iG9C5rA PqD+eKUUJ50yruQQlOW7ARyhDEKUvBc4+vCnCT7Hf6uttxZw3UIiksiZJ+mvy275S49l /Bs0hAZKGF9jNMhjqa+W8k4D+baIFccY3eFsUz4KKKbWDZhGz0xux8Rh2EWKj4O00W3c R/CMZHg03N+ab1Lbo0HUa2St07GNjdv0sySS7Eq+fD40NX9s0ho4Idju/FoBVTlcDWg5 MVDw== X-Gm-Message-State: AA+aEWaIL1G5OMS/M7cy4ieIukiUuSJPyAcEJDu2M3hzqMDSJtGEmohj GGnp9hDT14AbOXM75hlmwhcgvMjFqNA1YVJHAzH9CQ== X-Google-Smtp-Source: AFSGD/X3n3JUB8cgTy+gMv4MzzRSmhkL5LsQ0Lg4OpID9Ko9Bd1OOloC0DopWrP+Zqa1m3qbXHRfm/wlX26PbmVrVNc= X-Received: by 2002:a1c:cc1:: with SMTP id 184-v6mr9275947wmm.102.1543851524594; Mon, 03 Dec 2018 07:38:44 -0800 (PST) MIME-Version: 1.0 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> In-Reply-To: From: John Bradley Date: Mon, 3 Dec 2018 16:38:36 +0100 Message-ID: To: Torsten Lodderstedt Cc: Dominick Baier , Vittorio Bertocci , Daniel Fett , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000b5b109057c1ff197" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 03 Dec 2018 15:38:52 -0000 --000000000000b5b109057c1ff197 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Not everyone loves OAuth. Sometimes our discussions on how to make it more secure can be taken out of context and used as reasons to move back to proprietary solutions. We just need to be sensitive to the spin on this. John B. On Mon, Dec 3, 2018, 3:43 PM Torsten Lodderstedt > > > Am 03.12.2018 um 12:59 schrieb John Bradley : > > > > I agree that the hair on fire messaging is over stated. > > > > This is still a document in development and not yet a BCP. No new > vunerable have been found, but attackers are evolving. > > You are right. Basically, RFC 6749=E2=80=99s security consideration secti= on > already states the vulnerabilities: > > =C2=A7 10.3 > > =E2=80=9EWhen using the implicit grant type, the access token is transmit= ted > in the URI fragment, which can expose it to unauthorized parties.=E2= =80=9C > > =C2=A7 10.16 > > =E2=80=9EIn the implicit flow (response_type=3Dtoken), the attacker can e= asily > switch the token in the response from the authorization server, > replacing the real access token with the one previously issued to the > attacker." > > Retrospectively, I=E2=80=99m asking myself why we ever agreed to move the= spec > forward given these issues at hand. > > Why the change now? > > Not only attackers are evolving, also the use cases for OAuth and the > dynamics of the respective deployments have changed significantly. Just t= o > give some example, open banking was not a topic in 2012. The discovery of > the mix up attack was kind of a wake up call in late 2015. We realized > token leakage and replay is becoming a major issue. > > That are the reasons why we started working on the Security BCP as an > update of RFC 6749/4750 security considerations and also RFC 6819. > > The BCP, by the way, deprecates several other practices: For example, it > introduces exact URI matching, one time use CSRF tokens in state, and > obliges implementors to use code in conjunction with PKCE or nonce, > effectively deprecating the pure code flow. No one every complaint about > this. > > We also recommend use of sender constraint access tokens simply because w= e > came to the conclusion focussing on token leakage prevention only would b= e > a rather thin defense. > > > > > These are security best practices for new implimentations. Not a > recommendation to rip things out. As applications are updated they nee= d > to consider the BCP recommendations. > > I would go one step further. Given the fact we pointed out the risk > associated with implicit in RFC 6749, implementors should have conducted = a > risk assessment before they implemented implicit. If they haven=E2=80=99t= , they > should do now using the information we provide in the BCP. If they conclu= de > by finding application specific mitigations or just assume the risk, that > fine with me. > > But I don=E2=80=99t want to give implementors the =E2=80=9Eblessing=E2=80= =9C (as Vittorio called > it) of this working group to use a flow with such know security issues, > especially since a simpler and more secure option is available. > > BTW: I would be ok with making the respective text a SHOULD NOT again > since that would serve the purpose just fine. > > > > > We do need to be careful about how our discussions are interpreted. > > That=E2=80=99s certainly true. On the other hand, most developers don=E2= =80=99t know > anything about the current state of OAuth. What I have seen in the wild > makes me nervous. People think implicit is the =E2=80=9Elightweight and e= asy to > use=E2=80=9C version of OAuth and don=E2=80=99t ask for the security impl= ications. That=E2=80=99s > why I think we need to find ways to get developers and API designers > educated on how to properly use OAuth. > > > > > There are also worse things people could do than implicit if we scare > them back to proprietary solutions. > > Why do you see that risk? We offer an alternative solution, which is > simple to use, secure, and versatile. > > kind regards, > Torsten. > > > > > John B. > > > > On Mon, Dec 3, 2018, 12:50 PM Dominick Baier wrote: > > I agree with Vittorio - > > > > While we all agree that implicit is outdated and we can do better (and > it is indeed good that this discussion has finally started for real) - th= e > communication around the (preliminary) results of the BCP was unfortunate > and not very responsible - quoting: > > > > =E2=80=9CSimply put, the implicit grant=E2=80=99s security is broken be= yond repair. It > is vulnerable to access token leakage, meaning an attacker can exfiltrate > valid access tokens and use it to his own benefit. This might for example > result in the attacker accessing the legit user=E2=80=99s health record o= r > initiating a payment, from her bank account." > > > > This indeed, as Vittorio pointed out, sounds like a new vulnerability > has been found. This spreads FUD ;) > > > > Also - simply saying =E2=80=9Cimplicit is evil - switch to code=E2=80= =9D means for most > people also using refresh token - so we are treating access tokens in the > URL with refresh tokens in session storage (over simplified - but you get > the idea). > > > > Again we all agree that implicit can be improved - but there are some > issues to be sorted first to make this a smooth transition. > > > > My 2c > > > > =E2=80=94=E2=80=94=E2=80=94 > > Dominick > > > > On 3. December 2018 at 11:59:44, Vittorio Bertocci (vittorio.bertocci= =3D > 40auth0.com@dmarc.ietf.org) wrote: > > > >> Hi all, > >> Sorry for stepping a bit back from the level of detail the discussion > already reached. I do have some specific comments on the document, but > before bringing those up I wanted to raise a general problem I am > experiencing with this initiative.. > >> > >> I have a number of customers that are reacting to the news with > distress. The language used in some of the communications associated with > this initiative made them feel like some new vulnerability was discovered= , > calling for immediate action. > >> The fact is that as far as I can tell, no new, previously unknown fact > informed this decision: no new vulnerability, nor any new technology that > wasn=E2=80=99t available before (the sender constrain is still not action= able for > most customers). The risks of the implicit flow aren=E2=80=99t bigger now= than they > were in October. > >> That doesn=E2=80=99t mean that we cannot improve guidance, of course- = and now > is as good as any other moment to do so: but at the same time, I think we > need to be cognizant of the *immense* investment in existence today in fo= rm > of SDKs and applications built on those SDKs that are predicated on > implicit flow, with our blessing: until very recently the official positi= on > was =E2=80=9Cimplicit is bad but it=E2=80=99s the best we have noawadays= =E2=80=9D. > >> To me, being cognizant of that means that we should help people to > formulate action proportionate to the risk. And if until yesterday we wer= e > ok with them using implicit, we cannot realistically expect anyone to sta= rt > changing all of their apps today, but that=E2=80=99s the message many cus= tomers are > getting. > >> TL;DR, I think the community would be well served by clarifying in the > security document that there is no new risk and their existing codebase > didn=E2=80=99t suddenly become less secure and in *urgent* need to update= . > >> To attempt a metaphor. We discovered a new drug against headache with > milder side effects than the one we were prescribing them until now, but > that doesn=E2=80=99t mean that they should throw away all the stash they = have of > the older drug. The old drug will keep working as it worked until now. On= ce > they run out of their stash, they should get the new one; or if the old > side effects were particularly bad for them, perhaps they should consider > switching today. But this isn=E2=80=99t a recall. > >> > >> And if in fact this group thinks it should be a recall and get everyon= e > off the old one right now, I think we=E2=80=99ll need to make a much stro= nger case > than we have done so far. > >> > >> Thoughts? > >> > >> Thanks > >> V. > >> > >> > >> On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi Hannes, > >> > >> > Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig < > Hannes.Tschofenig@arm.com>: > >> > > >> > I agree with Aaron here and I think Section 3.8.1.2 of > draft-ietf-oauth-security-topics-10 already does a pretty good job. > >> > >> my proposal is to add the following definition (based on 3.8.1.2) to a > new =E2=80=9ETerminology" section or to section 2.1.2: > >> > >> A sender constrained access token scopes the applicability of an acces= s > token to a certain sender. This sender is > >> obliged to demonstrate knowledge of a certain secret as prerequisite > for the acceptance of that token at the recipient (e.g. a resource server= ). > >> > >> > > >> > I was, however, wondering about the subtle implication of the > requirement for sender constrained tokens. My understanding of the token > binding discussion, which is one of the ways to provide sender-constraine= d > tokens, is that we don=E2=80=99t have good faith in seeing deployment any= time soon. > Hence, we are essentially (reading in between the lines of Section 3.8.1.= 2) > saying that you cannot use implicit grant in a practical setup for the > web*.. > >> > >> The text shall convey that implicit must not be used at all. The main > reason being it is unprotected against token injection and additionally > also cannot sender constrain tokens. > >> > >> The second part of the statement relates to other response types and > conditionally opens the MUST NOT in case they are protected against > injection (which is true for the listed response types) and can issue > sender constrained tokens (which does not work today but might work in th= e > future). > >> > >> kind regards, > >> Torsten. > >> > >> > > >> > Am I misunderstanding it? > >> > >> > > >> > Ciao > >> > Hannes > >> > > >> > PS: The IoT case is likely different. > >> > > >> > From: OAuth On Behalf Of Aaron Parecki > >> > Sent: Saturday, December 1, 2018 3:18 AM > >> > To: Torsten Lodderstedt > >> > Cc: Daniel Fett ; IETF oauth WG > >> > Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend > authorization code instead of implicit > >> > > >> > +1 > >> > > >> > I would also like to ensure there is a clear definition of "sender > constrained" tokens in this BCP. > >> > > >> > Aaron > >> > > >> > > >> > On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> > Hi all, > >> > > >> > based on your feedback on the list and off list, Daniel and I > polished the text. That=E2=80=99s our proposal: > >> > > >> > =E2=80=94 > >> > In order to avoid these issues, clients MUST NOT use the implicit > >> > grant (response type "token") or any other response type issuing > access > >> > tokens in the authorization response, such as "token id_token" and > "code token id_token=E2=80=9C, > >> > unless the issued access tokens are sender-constrained and access > token injection in > >> > the authorization response is prevented. > >> > =E2=80=94 > >> > > >> > Explantation: > >> > - we wanted to have the right balance between a generic definition o= f > the response types we do not recommend/allow to be used and a > concrete/actionable list of the affected response types. > >> > - we changed from SHOULD NOT to MUST NOT as suggested by Nat and > supported by William > >> > > >> > We look forward to seeing your feedback. > >> > > >> > kind regards, > >> > Torsten. > >> > > >> > > Am 29.11.2018 um 15:15 schrieb John Bradley : > >> > > > >> > > I am ok with that. > >> > > > >> > > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt < > torsten@lodderstedt.net wrote: > >> > > > >> > > > Am 28.11.2018 um 23:50 schrieb n-sakimura = : > >> > > > > >> > > > That works. > >> > > > >> > > Good! > >> > > > >> > > I just realized this text has an issue with =E2=80=9Etoken=E2=80= =9C (only). It > would allow =E2=80=9Etoken=E2=80=9C to be used if the token would sender = constrained. This > completely ignores the fact implicit also shall be abandoned because of i= ts > vulnerability for access token injection. > >> > > > >> > > I therefore propose a modified text: > >> > > > >> > > In order to avoid these issues, Clients SHOULD NOT use the > implicit > >> > > grant. Furthermore, clients SHOULD only use other response type= s > causing the authorization server to > >> > > issue an access token in the authorization response, if the > particular response type detects access token > >> > > injection and the issued access tokens are sender-constrained. > >> > > > >> > > Or we just state: > >> > > > >> > > In order to avoid these issues, Clients SHOULD NOT use the > response type =E2=80=9Etoken". The response types > >> > > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token= =E2=80=9C SOULD NOT be used, if > the issued access tokens are not > >> > > sender-constrained. > >> > > > >> > > > > >> > > > In fact, I would further go and say MUST NOT but that probably i= s > too much for a security consideration. > >> > > > > >> > > > >> > > Mike suggested to go with a SHOULD NOT to get the message out but > give implementors time to move/change. > >> > > > >> > > > Best, > >> > > > > >> > > > Nat > >> > > > > >> > > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276 > >> > > > > >> > > > > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81= =E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3= =81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF= =86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84= =E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3= =81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81= =AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3= =E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3= =81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F= =A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97= =E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5= =89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81= =BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97= =E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 > >> > > > > >> > > > PLEASE READ :This e-mail is confidential and intended for the > named recipient only. > >> > > > If you are not an intended recipient, please notify the sender > and delete this e-mail. > >> > > > > >> > > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt > >> > > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97= =A5, 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C > >> > > > =E5=AE=9B=E5=85=88: n-sakimura > >> > > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org > >> > > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Reco= mmend > authorization code instead of implicit > >> > > > > >> > > > Hi Nat, > >> > > > > >> > > >> Am 28.11.2018 um 21:10 schrieb n-sakimura >: > >> > > >> > >> > > >> I would support > >> > > >> > >> > > >> 1) clearly defining Implicit as the flow that returns access > token from the authorization endpoint ( some people confuses implicit as > the flow that returns ID Token in the front channel) > >> > > > > >> > > > That=E2=80=99s the current text: > >> > > > > >> > > > In order to avoid these issues, Clients SHOULD NOT use the > implicit > >> > > > grant or any other response type causing the authorization > server to > >> > > > issue an access token in the authorization response. > >> > > > > >> > > > What would you like to modify? > >> > > > > >> > > >> > >> > > >> 2) Banning the returning of the access token that are not sende= r > constrained from the authorization endpoint > >> > > > > >> > > > In order to avoid these issues, Clients SHOULD NOT use the > implicit > >> > > > grant or any other response type causing the authorization > server to > >> > > > issue an access token in the authorization response, if this > access tokens is not sender-constraint. > >> > > > > >> > > > What about this? > >> > > > > >> > > > kind regards, > >> > > > Torsten. > >> > > > > >> > > >> > >> > > >> Best, > >> > > >> > >> > > >> Nat > >> > > >> > >> > > >> > >> > > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B > >> > > >> > >> > > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth (Di= ck Hardt < > dick.hardt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86) > >> > > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97= =A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C > >> > > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig > >> > > >> Cc: oauth@ietf.org > >> > > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Rec= ommend > authorization code instead of implicit > >> > > >> > >> > > >> +1 > >> > > >> > >> > > >> While there are various mechanisms to alleviate some of the > issues of implicit, I don't think we can recommend specifics, and there m= ay > be future ones in the future. I think we all agree that implicit without > any mitigation is problematic. > >> > > >> > >> > > >> How about we recommend against using implicit alone? > >> > > >> > >> > > >> > >> > > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > >> > > >> Hi all, > >> > > >> > >> > > >> The authors of the OAuth Security Topics draft came to the > conclusion that it is not possible to adequately secure the implicit flow > against token injection since potential solutions like token binding or > JARM are in an early stage of adoption. For this reason, and since CORS > allows browser-based apps to send requests to the token endpoint, Torsten > suggested to use the authorization code instead of the implicit grant in > call cases in his presentation (see > https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb= -draft-ietf-oauth-security-topics-01 > ). > >> > > >> > >> > > >> A hum in the room at IETF#103 concluded strong support for his > recommendations. We would like to confirm the discussion on the list.. > >> > > >> > >> > > >> Please provide a response by December 3rd. > >> > > >> > >> > > >> Ciao > >> > > >> > >> > > >> Hannes & Rifaat > >> > > >> > >> > > >> > >> > > >> > >> > > >> IMPORTANT NOTICE: The contents of this email and any attachment= s > 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 > >> > > >> _______________________________________________ > >> > > >> 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 > >> > -- > >> > ---- > >> > Aaron Parecki > >> > aaronparecki.com > >> > @aaronpk > >> > > >> > 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 > >> _______________________________________________ > >> 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 > > --000000000000b5b109057c1ff197 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not everyone loves OAuth.=C2=A0 Sometimes our discussions= on how to make it more secure can be taken out of context and used as reas= ons to move back to proprietary solutions.=C2=A0=C2=A0
We just need to be sensitive to the spin on this.= =C2=A0=C2=A0

John B.=C2= =A0

On Mon, Dec = 3, 2018, 3:43 PM Torsten Lodderstedt <torsten@lodderstedt.net wrote:


> Am 03.12.2018 um 12:59 schrieb John Bradley <ve7jtb@ve7jtb.com&g= t;:
>
> I agree that the hair on fire messaging is over stated.=C2=A0 =C2=A0 >
> This is still a document in development and not yet a BCP.=C2=A0 =C2= =A0No new vunerable have been found, but attackers are evolving.=C2=A0

You are right. Basically, RFC 6749=E2=80=99s security consideration section= already states the vulnerabilities:

=C2=A7 10.3

=E2=80=9EWhen using the implicit grant type, the access token is transmitte= d
=C2=A0 =C2=A0in the URI fragment, which can expose it to unauthorized parti= es.=E2=80=9C

=C2=A7 10.16

=E2=80=9EIn the implicit flow (response_type=3Dtoken), the attacker can eas= ily
=C2=A0 =C2=A0switch the token in the response from the authorization server= ,
=C2=A0 =C2=A0replacing the real access token with the one previously issued= to the
=C2=A0 =C2=A0attacker."

Retrospectively, I=E2=80=99m asking myself why we ever agreed to move the s= pec forward given these issues at hand.

Why the change now?

Not only attackers are evolving, also the use cases for OAuth and the dynam= ics of the respective deployments have changed significantly. Just to give = some example, open banking was not a topic in 2012. The discovery of the mi= x up attack was kind of a wake up call in late 2015. We realized token leak= age and replay is becoming a major issue.

That are the reasons why we started working on the Security BCP as an updat= e of RFC 6749/4750 security considerations and also RFC 6819.

The BCP, by the way, deprecates several other practices: For example, it in= troduces exact URI matching, one time use CSRF tokens in state, and obliges= implementors to use code in conjunction with PKCE or nonce, effectively de= precating the pure code flow. No one every complaint about this.

We also recommend use of sender constraint access tokens simply because we = came to the conclusion focussing on token leakage prevention only would be = a rather thin defense.

>
> These are security best practices for new implimentations.=C2=A0 =C2= =A0Not a recommendation to rip things out.=C2=A0 =C2=A0 As applications are= updated they need to consider the BCP recommendations.=C2=A0

I would go one step further. Given the fact we pointed out the risk associa= ted with implicit in RFC 6749, implementors should have conducted a risk as= sessment before they implemented implicit. If they haven=E2=80=99t, they sh= ould do now using the information we provide in the BCP. If they conclude b= y finding application specific mitigations or just assume the risk, that fi= ne with me.

But I don=E2=80=99t want to give implementors the =E2=80=9Eblessing=E2=80= =9C (as Vittorio called it) of this working group to use a flow with such k= now security issues, especially since a simpler and more secure option is a= vailable.

BTW: I would be ok with making the respective text a SHOULD NOT again since= that would serve the purpose just fine.

>
> We do need to be careful about how our discussions are interpreted.=C2= =A0

That=E2=80=99s certainly true. On the other hand, most developers don=E2=80= =99t know anything about the current state of OAuth. What I have seen in th= e wild makes me nervous. People think implicit is the =E2=80=9Elightweight = and easy to use=E2=80=9C version of OAuth and don=E2=80=99t ask for the sec= urity implications. That=E2=80=99s why I think we need to find ways to get = developers and API designers educated on how to properly use OAuth.

>
> There are also worse things people could do than implicit if we scare = them back to proprietary solutions.=C2=A0

Why do you see that risk? We offer an alternative solution, which is simple= to use, secure, and versatile.=C2=A0

kind regards,
Torsten.

>
> John B.=C2=A0
>
> On Mon, Dec 3, 2018, 12:50 PM Dominick Baier <dbaier@leastpr= ivilege.com wrote:
> I agree with Vittorio -
>
> While we all agree that implicit is outdated and we can do better (and= it is indeed good that this discussion has finally started for real) - the= communication around the (preliminary) results of the BCP was unfortunate = and not very responsible - quoting:
>
> =E2=80=9CSimply put, the implicit grant=E2=80=99s security is broken b= eyond repair. It is vulnerable to access token leakage, meaning an attacker= can exfiltrate valid access tokens and use it to his own benefit. This mig= ht for example result in the attacker accessing the legit user=E2=80=99s he= alth record or initiating a payment, from her bank account."
>
> This indeed, as Vittorio pointed out, sounds like a new vulnerability = has been found. This spreads FUD ;)
>
> Also - simply saying =E2=80=9Cimplicit is evil - switch to code=E2=80= =9D means for most people also using refresh token - so we are treating acc= ess tokens in the URL with refresh tokens in session storage (over simplifi= ed - but you get the idea).
>
> Again we all agree that implicit can be improved - but there are some = issues to be sorted first to make this a smooth transition.
>
> My 2c
>
> =E2=80=94=E2=80=94=E2=80=94
> Dominick
>
> On 3. December 2018 at 11:59:44, Vittorio Bertocci (vittorio.bertocci= =3D40auth0.com@dmarc.ietf.org) wrote:
>
>> Hi all,
>> Sorry for stepping a bit back from the level of detail the discuss= ion already reached. I do have some specific comments on the document, but = before bringing those up I wanted to raise a general problem I am experienc= ing with this initiative..
>>
>> I have a number of customers that are reacting to the news with di= stress. The language used in some of the communications associated with thi= s initiative made them feel like some new vulnerability was discovered, cal= ling for immediate action.
>> The fact is that as far as I can tell, no new, previously unknown = fact informed this decision: no new vulnerability, nor any new technology t= hat wasn=E2=80=99t available before (the sender constrain is still not acti= onable for most customers). The risks of the implicit flow aren=E2=80=99t b= igger now than they were in October.
>> That doesn=E2=80=99t mean that we cannot improve guidance, of cour= se- and now is as good as any other moment to do so: but at the same time, = I think we need to be cognizant of the *immense* investment in existence to= day in form of SDKs and applications built on those SDKs that are predicate= d on implicit flow, with our blessing: until very recently the official pos= ition was =E2=80=9Cimplicit is bad but it=E2=80=99s the best we have noawad= ays=E2=80=9D.
>> To me, being cognizant of that means that we should help people to= formulate action proportionate to the risk. And if until yesterday we were= ok with them using implicit, we cannot realistically expect anyone to star= t changing all of their apps today, but that=E2=80=99s the message many cus= tomers are getting.
>> TL;DR, I think the community would be well served by clarifying in= the security document that there is no new risk and their existing codebas= e didn=E2=80=99t suddenly become less secure and in *urgent* need to update= .
>> To attempt a metaphor. We discovered a new drug against headache w= ith milder side effects than the one we were prescribing them until now, bu= t that doesn=E2=80=99t mean that they should throw away all the stash they = have of the older drug. The old drug will keep working as it worked until n= ow. Once they run out of their stash, they should get the new one; or if th= e old side effects were particularly bad for them, perhaps they should cons= ider switching today. But this isn=E2=80=99t a recall.
>>
>> And if in fact this group thinks it should be a recall and get eve= ryone off the old one right now, I think we=E2=80=99ll need to make a much = stronger case than we have done so far.
>>
>> Thoughts?
>>
>> Thanks
>> V.
>>=C2=A0
>>
>> On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt <torsten@= lodderstedt.net> wrote:
>> Hi Hannes,
>>
>> > Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig <= Hannes.Tschofenig@arm.com>:
>> >
>> > I agree with Aaron here and I think Section 3.8.1.2 of draft-= ietf-oauth-security-topics-10=C2=A0 already does a pretty good job.
>>
>> my proposal is to add the following definition (based on 3.8.1.2) = to a new =E2=80=9ETerminology" section or to section 2.1.2:
>>
>> A sender constrained access token scopes the applicability of an a= ccess token to a certain sender.=C2=A0 This sender is
>> obliged to demonstrate knowledge of a certain secret as prerequisi= te for the acceptance of that token at the recipient (e.g. a resource serve= r).
>>
>> >
>> > I was, however, wondering about the subtle implication of the= requirement for sender constrained tokens. My understanding of the token b= inding discussion, which is one of the ways to provide sender-constrained t= okens, is that we don=E2=80=99t have good faith in seeing deployment anytim= e soon. Hence, we are essentially (reading in between the lines of Section = 3.8.1.2) saying that you cannot use implicit grant in a practical setup for= the web*..
>>
>> The text shall convey that implicit must not be used at all. The m= ain reason being it is unprotected against token injection and additionally= also cannot sender constrain tokens.
>>
>> The second part of the statement relates to other response types a= nd conditionally opens the MUST NOT in case they are protected against inje= ction (which is true for the listed response types) and can issue sender co= nstrained tokens (which does not work today but might work in the future).<= br> >>
>> kind regards,
>> Torsten.
>>
>> >
>> > Am I misunderstanding it?
>>
>> >
>> > Ciao
>> > Hannes
>> >
>> > PS: The IoT case is likely different.
>> >
>> > From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Aaron Parecki
>> > Sent: Saturday, December 1, 2018 3:18 AM
>> > To: Torsten Lodderstedt <torsten@lodderstedt.net&= gt;
>> > Cc: Daniel Fett <fett@danielfett.de>; IETF oauth WG= <oauth@ietf.org>
>> > Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend au= thorization code instead of implicit
>> >
>> > +1
>> >
>> > I would also like to ensure there is a clear definition of &q= uot;sender constrained" tokens in this BCP.
>> >
>> > Aaron
>> >
>> >
>> > On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> > Hi all,
>> >
>> > based on your feedback on the list and off list, Daniel and I= polished the text. That=E2=80=99s our proposal:
>> >
>> > =E2=80=94
>> > In order to avoid these issues, clients MUST NOT use the impl= icit
>> > grant (response type "token") or any other response= type issuing access
>> > tokens in the authorization response, such as "token id_= token" and "code token id_token=E2=80=9C,
>> > unless the issued access tokens are sender-constrained and ac= cess token injection in
>> > the authorization response is prevented.
>> > =E2=80=94
>> >
>> > Explantation:
>> > - we wanted to have the right balance between a generic defin= ition of the response types we do not recommend/allow to be used and a conc= rete/actionable list of the affected response types.
>> > - we changed from SHOULD NOT to MUST NOT as suggested by Nat = and supported by William
>> >
>> > We look forward to seeing your feedback.
>> >
>> > kind regards,
>> > Torsten.
>> >
>> > > Am 29.11.2018 um 15:15 schrieb John Bradley <ve7jtb@v= e7jtb.com>:
>> > >
>> > > I am ok with that.
>> > >
>> > > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <torsten@lodderstedt.net wrote:
>> > >
>> > > > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-s= akimura@nri.co.jp>:
>> > > >
>> > > > That works.
>> > >
>> > > Good!
>> > >
>> > > I just realized this text has an issue with =E2=80=9Etok= en=E2=80=9C (only). It would allow =E2=80=9Etoken=E2=80=9C to be used if th= e token would sender constrained. This completely ignores the fact implicit= also shall be abandoned because of its vulnerability for access token inje= ction.
>> > >
>> > > I therefore propose a modified text:
>> > >
>> > >=C2=A0 =C2=A0 In order to avoid these issues, Clients SHO= ULD NOT use the implicit
>> > >=C2=A0 =C2=A0 grant. Furthermore, clients SHOULD only use= other response types causing the authorization server to
>> > >=C2=A0 =C2=A0 issue an access token in the authorization = response, if the particular response type detects access token
>> > >=C2=A0 =C2=A0 injection and the issued access tokens are = sender-constrained.
>> > >
>> > > Or we just state:
>> > >
>> > >=C2=A0 =C2=A0In order to avoid these issues, Clients SHOU= LD NOT use the response type =E2=80=9Etoken". The response types
>> > > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token= id_token=E2=80=9C SOULD NOT be used, if the issued access tokens are not >> > > sender-constrained.
>> > >
>> > > >
>> > > > In fact, I would further go and say MUST NOT but th= at probably is too much for a security consideration.
>> > > >
>> > >
>> > > Mike suggested to go with a SHOULD NOT to get the messag= e out but give implementors time to move/change.
>> > >
>> > > > Best,
>> > > >
>> > > > Nat
>> > > >
>> > > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-= 6013-6276
>> > > >
>> > > > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AB=E3=81=AF=E3=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE= =E6=96=B9=E3=81=AE=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3= =81=9F=E6=A9=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82= =8C=E3=81=A6=E3=81=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96= =E3=81=84=E3=81=BE=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3= =82=8A=E3=81=AE=E3=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA= =A0=E3=81=AB=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE= =E3=81=9B=E3=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3= =81=A7=E3=81=8A=E7=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81= =BE=E3=81=9F=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC= =E3=83=AB=E3=81=AF=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3= =81=95=E3=81=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81= =84=E7=94=B3=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
>> > > >
>> > > > PLEASE READ :This e-mail is confidential and intend= ed for the named recipient only.
>> > > > If you are not an intended recipient, please notify= the sender and delete this e-mail.
>> > > >
>> > > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt &l= t;torsten@lodderstedt.net>
>> > > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6= =9B=9C=E6=97=A5, 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
>> > > > =E5=AE=9B=E5=85=88: n-sakimura
>> > > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org >> > > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security T= opics -- Recommend authorization code instead of implicit
>> > > >
>> > > > Hi Nat,
>> > > >
>> > > >> Am 28.11.2018 um 21:10 schrieb n-sakimura <<= a href=3D"mailto:n-sakimura@nri.co.jp" target=3D"_blank" rel=3D"noreferrer"= >n-sakimura@nri.co.jp>:
>> > > >>
>> > > >> I would support
>> > > >>
>> > > >> 1) clearly defining Implicit as the flow that r= eturns access token from the authorization endpoint ( some people confuses = implicit as the flow that returns ID Token in the front channel)
>> > > >
>> > > > That=E2=80=99s the current text:
>> > > >
>> > > > In order to avoid these issues, Clients SHOULD NOT = use the implicit
>> > > >=C2=A0 =C2=A0 grant or any other response type causi= ng the authorization server to
>> > > >=C2=A0 =C2=A0 issue an access token in the authoriza= tion response.
>> > > >
>> > > > What would you like to modify?
>> > > >
>> > > >>
>> > > >> 2) Banning the returning of the access token th= at are not sender constrained from the authorization endpoint
>> > > >
>> > > > In order to avoid these issues, Clients SHOULD NOT = use the implicit
>> > > >=C2=A0 =C2=A0 grant or any other response type causi= ng the authorization server to
>> > > >=C2=A0 =C2=A0 issue an access token in the authoriza= tion response, if this access tokens is not sender-constraint.
>> > > >
>> > > > What about this?
>> > > >
>> > > > kind regards,
>> > > > Torsten.
>> > > >
>> > > >>
>> > > >> Best,
>> > > >>
>> > > >> Nat
>> > > >>
>> > > >>
>> > > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
>> > > >>
>> > > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oau= th-bounces@ietf.org> (Dick Hardt <dick.hardt@gmail.com> = =E3=81=AE=E4=BB=A3=E7=90=86)
>> > > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4= =E6=9B=9C=E6=97=A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
>> > > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
>> > > >> Cc: oauth@ietf.org
>> > > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Securi= ty Topics -- Recommend authorization code instead of implicit
>> > > >>
>> > > >> +1
>> > > >>
>> > > >> While there are various mechanisms to alleviate= some of the issues of implicit, I don't think we can recommend specifi= cs, and there may be future ones in the future. I think we all agree that i= mplicit without any mitigation is problematic.
>> > > >>
>> > > >> How about we recommend against using implicit a= lone?
>> > > >>
>> > > >>
>> > > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofen= ig <Hannes.Tschofenig@arm.com> wrote:
>> > > >> Hi all,
>> > > >>
>> > > >> The authors of the OAuth Security Topics draft = came to the conclusion that it is not possible to adequately secure the imp= licit flow against token injection since potential solutions like token bin= ding or JARM are in an early stage of adoption. For this reason, and since = CORS allows browser-based apps to send requests to the token endpoint, Tors= ten suggested to use the authorization code instead of the implicit grant i= n call cases in his presentation (see https://datatrack= er.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-s= ecurity-topics-01).
>> > > >>
>> > > >> A hum in the room at IETF#103 concluded strong = support for his recommendations. We would like to confirm the discussion on= the list..
>> > > >>
>> > > >> Please provide a response by December 3rd.
>> > > >>
>> > > >> Ciao
>> > > >>
>> > > >> Hannes & Rifaat
>> > > >>
>> > > >>
>> > > >>
>> > > >> IMPORTANT NOTICE: The contents of this email an= d any attachments are confidential and may also be privileged. If you are n= ot 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 the information in any medium. Thank you.
>> > > >> _______________________________________________=
>> > > >> OAuth mailing list
>> > > >> OAuth@ietf.org
>> > > >> https://www.ietf.o= rg/mailman/listinfo/oauth
>> > > >> _______________________________________________=
>> > > >> OAuth mailing list
>> > > >> OAuth@ietf.org
>> > > >> https://www.ietf.o= rg/mailman/listinfo/oauth
>> > > >
>> > >
>> > > _______________________________________________
>> > > OAuth mailing list
>> > > OAuth@ietf.org
>> > > https://www.ietf.org/mailma= n/listinfo/oauth
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/l= istinfo/oauth
>> > --
>> > ----
>> > Aaron Parecki
>> > aaronparecki.com
>> > @aaronpk
>> >
>> > IMPORTANT NOTICE: The contents of this email and any attachme= nts are confidential and may also be privileged. If you are not the intende= d recipient, please notify the sender immediately and do not disclose the c= ontents to any other person, use it for any purpose, or store or copy the i= nformation in any medium. Thank you.
>>
>> _______________________________________________
>> 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/oau= th

--000000000000b5b109057c1ff197-- From nobody Mon Dec 3 09:53:35 2018 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 BC770124BE5 for ; Mon, 3 Dec 2018 09:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 ZAHSSsBmHo9I for ; Mon, 3 Dec 2018 09:53:31 -0800 (PST) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 7F69B12426A for ; Mon, 3 Dec 2018 09:53:31 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id h65so9894724ith.3 for ; Mon, 03 Dec 2018 09:53:31 -0800 (PST) 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=omwtSA1bS/XydZrdJ4C4mmF/UhA88DT99xYUsSKLkHc=; b=g+mK+ihvI4StoOEKF6Nfd5hNNII5vX+BNNngIbWdWBNiyt7Oen7KnqhG/6J0amTt3O yhgM1QRlUUL0EspoHpNnT7eeosCLi6eM/1AQWGEmQ0R2ZVzftrc3yhHl2QeHtBjNRN2B XXWxTYZxnEqPQRs/EiF4Pf8GSYdFrdyDErmHE= 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=omwtSA1bS/XydZrdJ4C4mmF/UhA88DT99xYUsSKLkHc=; b=MAqTxKMwmLG9GUWtuUWCOO4W4xEadQqnz3F0x+bdud4gRJYJE0PDDUg/STtC3rYPPR yRTQctjlf10wz6J0Z8IrOMXD7sHTiOyu/FFJQddTWrg3QLYd4tfY3eC2F4XW082Sz06C CNoPyP3kFSTT/0a2X7m/a9i7H5C4bJVF5qOPJFQx8IL/jfX5vmERkIVmuwLd0lh3oaY6 0094l6//l4oascGLHus0xAUxNeJpgIZUkF4zPks2pwA6flI0VA++wpD+LsAc6mElA7IK mw08z4QCyK8W/Q9mROlfLnd0nAXomuRlbks3pAwBdEUUTkvdjNOo4pfJoa4EtnbZ7I2a Cm3g== X-Gm-Message-State: AA+aEWa60N/dpRMIpTXexuuXhsXEIg6B8S4+EoeVQMpyPZ9sQGRGnkdg ND/JnW9yx3TX/WgKk30xQ3gm0RAwbvPoJIUY7b/w6/3gtMZeoDDP1cktEiF8wz5kVK5/vfvdgQ9 PdXbdRjbJZIyRvWnF4Hg= X-Google-Smtp-Source: AFSGD/WkR9dlog9gfuYhLuMx2fYPJ2VN7mGdPwn4TBCwH3ol9HTmGRBbNJP+Fds6lYtc/YvKt1gtp7LADpJi3hkCIx0= X-Received: by 2002:a24:3987:: with SMTP id l129mr8309301ita.45.1543859610490; Mon, 03 Dec 2018 09:53:30 -0800 (PST) MIME-Version: 1.0 References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> <7FEF0314-88F2-46C7-A22D-C794CC1BB6A0@lodderstedt.net> In-Reply-To: From: Brian Campbell Date: Mon, 3 Dec 2018 10:53:03 -0700 Message-ID: To: Aaron Parecki Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="000000000000aae2a5057c21d3f0" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 03 Dec 2018 17:53:35 -0000 --000000000000aae2a5057c21d3f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would also like to see something to that effect. I feel that sometimes because SPAs use APIs, there's an unchallenged assumption that OAuth also has to be used with the in-browser code accessing those APIs. Even if the details are out of scope for this document, some text like the below at least gives a nod to the possibility of different approaches, which may ultimately be more secure and easier to mange. https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-00#secti= on-5.1 kinda does this too but I'm a +1 for a little something along the lines of what is being discussed recently in this thread. On Mon, Dec 3, 2018 at 7:57 AM Aaron Parecki wrote: > I support adding something to that effect, but would like to make it clea= r > that this removes the app from being covered under this BCP. How about: > > --- > Implementations MAY consider moving the authorization code exchange and > handling of access and refresh tokens to a backend component in order to > avoid the risks inherent in handling access tokens from a purely browser > based app. In this case, the backend component can be a confidential clie= nt > and can be secured accordingly. > > Security of the connection between code running in the browser and this > backend component is assumed to utilize browser-level protection > mechanisms. Details are out of scope of this document. > --- > > > > > On Mon, Dec 3, 2018 at 3:15 AM Torsten Lodderstedt < > torsten@lodderstedt.net > wrote: > >> Interesting. Even on this list people felt to see that moving some logic >> to a backend could solve some of the problems raised. What I want to con= vey >> is: the solution to a problem in the OAuth space does not necessarily ne= ed >> to be found on the OAuth protocol level. That=E2=80=99s a best practice = in the same >> way as some OAuth pattern. >> >> What I=E2=80=99m suggesting is a statement in the BCP like >> >> =E2=80=94 >> Implementations MAY consider to move authorization code exchange and >> handling of access and refresh tokens to a backend component in order to >> fulfill their security goals. >> >> Security of the connection between code running in the browser and this >> backend component is assumed to utilize browser-level protection >> mechanisms. Details are out of scope of this document. >> =E2=80=94 >> >> > Am 03.12.2018 um 11:19 schrieb John Bradley : >> > >> > This is my point. >> > >> > From a security perspective we have a server based confidential >> client.. The fact that it has a angular or other JS UI protected by a >> cookie seems to not be especially relucent to OAuth. >> > >> > Perhaps from the developer point of view they have a JS SPA and the >> only difference to them is in one case they are including the OAuth clie= nt >> and in the other they are using a server based proxy. So they see it as = the >> same. >> > >> > Perhaps it is perspective. >> > >> > On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki > > In this type of deployment, as far as OAuth is concerned, isn't the >> backend web server a confidential client? Is there even anything unique = to >> this situation as far as OAuth security goes? >> > >> > I wouldn't have expected an Angular app that talks to its own server >> backend that's managing OAuth credentials to fall under the umbrella of >> this BCP. >> > >> > ---- >> > Aaron Parecki >> > aaronparecki.com >> > >> > >> > >> > On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> > the UI is rendered in the frontend, UI control flow is in the >> frontend.. just a different cut through the web app=E2=80=99s layering >> > >> > All Angular apps I have seen so far work that way. And it makes a lot >> of sense to me. The backend can aggregate and optimize access to the >> underlying services without the need to fully expose them. >> > >> > Am 02.12.2018 um 00:44 schrieb John Bradley : >> > >> >> How is that different from a regular server client with a web >> interface if the backed is doing the API calls to the RS? >> >> >> >> >> >> >> >> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: >> >>> I forgot to mention another (architectural) option: split an >> application into frontend provided by JS in the browser and a backend, >> which takes care of the business logic and handles tokens and API access= . >> Replay detection at the interface between SPA and backend can utilize >> standard web techniques (see OWASP). The backend in turn can use mTLS fo= r >> sender constraining. >> >>> >> >>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt < >> torsten@lodderstedt.net>: >> >>> >> >>>> IMHO the best mechanism at hand currently to cope with token >> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay >> detection) and issue short living and privilege restricted access tokens= . >> >>>> >> >>>> Sender constrained access tokens in SPAs need adoption of token >> binding or alternative mechanism. mtls could potentially work in >> deployments with automated cert rollout but browser UX and interplay wit= h >> fetch needs some work. We potentially must consider to warm up applicati= on >> level PoP mechanisms in conjunction with web crypto. Another path to be >> evaluated could be web auth. >> >>>> >> >>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig < >> Hannes.Tschofenig@arm.com>: >> >>>> >> >>>>> I share the concern Brian has, which is also the conclusion I came >> up with in my other email sent a few minutes ago. >> >>>>> >> >>>>> >> >>>>> >> >>>>> From: OAuth On Behalf Of Brian Campbell >> >>>>> Sent: Friday, November 30, 2018 11:43 PM >> >>>>> To: Torsten Lodderstedt >> >>>>> Cc: oauth >> >>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>>>> >> >>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen > >: >> >>>>> > >> >>>>> > So you mean at the resource server ensuring the token was really >> issued to the client? Isn't that an inherent limitation of all bearer >> tokens (modulo HTTP token binding, which is still some time off)? >> >>>>> >> >>>>> Sure. That=E2=80=99s why the Security BCP recommends use of TLS-ba= sed >> methods for sender constraining access tokens ( >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-= 2..2). >> Token Binding for OAuth ( >> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well >> as Mutual TLS for OAuth ( >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options >> available. >> >>>>> >> >>>>> >> >>>>> >> >>>>> Unfortunately even when using the token endpoint, for SPA / >> in-browser client applications, the potential mechanisms for >> sender/key-constraining access tokens don't work very well or maybe don'= t >> work at all. So I don't know that the recommendation is very realistic. >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> 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 send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you. >> >>>>> >> >>>>> 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 t= he >> information in any medium. Thank you. >> >>>> _______________________________________________ >> >>>> 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 >> >> -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > _______________________________________________ > 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._ --000000000000aae2a5057c21d3f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would also like to see something t= o that effect. I feel that sometimes because SPAs use APIs, there's an = unchallenged assumption that OAuth also has to be used with the in-browser = code accessing those APIs. Even if the details are out of scope for this do= cument, some text like the below at least gives a nod to the possibility of= different approaches, which may ultimately be more secure and easier to ma= nge. https://tools.ietf.org/html/draft-parecki-oauth-bro= wser-based-apps-00#section-5.1 kinda does this too but I'm a +1 for= a little something along the lines of what is being discussed recently in = this thread.



On Mon, Dec 3, 2018 at 7:57 AM Aaron Parecki <= aaron@parecki.com> wrote:
I support adding something to that effect, but would like to make it clea= r that this removes the app from being covered under this BCP. How about:

---
Implementations MAY consider moving the authorization code exchan= ge and handling of access and refresh tokens to a backend component in orde= r to avoid the risks inherent in handling access tokens from a purely brows= er based app. In this case, the backend component can be a confidential cli= ent and can be secured accordingly.

Security of the connection betwe= en code running in the browser and this backend component is assumed to uti= lize browser-level protection mechanisms. Details are out of scope of this = document.=C2=A0
---

<= /div>



On Mon, Dec 3, 2018 at 3:15 AM Torst= en Lodderstedt <torsten@lodderstedt.net> wrote:
Interesting. Even on this list people felt to = see that moving some logic to a backend could solve some of the problems ra= ised. What I want to convey is: the solution to a problem in the OAuth spac= e does not necessarily need to be found on the OAuth protocol level. That= =E2=80=99s a best practice in the same way as some OAuth pattern.

What I=E2=80=99m suggesting is a statement in the BCP like

=E2=80=94
Implementations MAY consider to move authorization code exchange and handli= ng of access and refresh tokens to a backend component in order to fulfill = their security goals.

Security of the connection between code running in the browser and this bac= kend component is assumed to utilize browser-level protection mechanisms. D= etails are out of scope of this document.
=E2=80=94

> Am 03.12.2018 um 11:19 schrieb John Bradley <ve7jtb@ve7jtb.com>:
>
> This is my point.=C2=A0
>
> From a security perspective we have a server based confidential client= ..=C2=A0 =C2=A0The fact that it has a angular or other JS UI protected by a= cookie seems to not be especially relucent to OAuth.=C2=A0
>
> Perhaps from the developer point of view they have a JS SPA and the on= ly difference to them is in one case they are including the OAuth client an= d in the other they are using a server based proxy. So they see it as the s= ame.
>
> Perhaps it is perspective.
>
> On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki <aaron@parecki.com wrote:
> In this type of deployment, as far as OAuth is concerned, isn't th= e backend web server a confidential client? Is there even anything unique t= o this situation as far as OAuth security goes?
>
> I wouldn't have expected an Angular app that talks to its own serv= er backend that's managing OAuth credentials to fall under the umbrella= of this BCP.
>
> ----
> Aaron Parecki
> aaronparecki.com
>
>
>
> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt <torsten@lodderstedt.net&= gt; wrote:
> the UI is rendered in the frontend, UI control flow is in the frontend= .. just a different cut through the web app=E2=80=99s layering
>
> All Angular apps I have seen so far work that way. And it makes a lot = of sense to me. The backend can aggregate and optimize access to the underl= ying services without the need to fully expose them.
>
> Am 02.12.2018 um 00:44 schrieb John Bradley <ve7jtb@ve7jtb.com>:
>
>> How is that different from a regular server client with a web inte= rface if the backed is doing the API calls to the RS?
>>
>>
>>
>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>> I forgot to mention another (architectural) option: split an a= pplication into frontend provided by JS in the browser and a backend, which= takes care of the business logic and handles tokens and API access. Replay= detection at the interface between SPA and backend can utilize standard we= b techniques (see OWASP). The backend in turn can use mTLS for sender const= raining.
>>>
>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <torsten@lodderstedt.n= et>:
>>>
>>>> IMHO the best mechanism at hand currently to cope with tok= en leakage/replay in SPAs is to use refresh tokens (rotating w/ replay dete= ction) and issue short living and privilege restricted access tokens.
>>>>
>>>> Sender constrained access tokens in SPAs need adoption of = token binding or alternative mechanism. mtls could potentially work in depl= oyments with automated cert rollout but browser UX and interplay with fetch= needs some work. We potentially must consider to warm up application level= PoP mechanisms in conjunction with web crypto. Another path to be evaluate= d could be web auth.
>>>>
>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <Hannes.Tschofenig= @arm.com>:
>>>>
>>>>> I share the concern Brian has, which is also the concl= usion I came up with in my other email sent a few minutes ago.
>>>>>
>>>>>=C2=A0
>>>>>
>>>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Cam= pbell
>>>>> Sent: Friday, November 30, 2018 11:43 PM
>>>>> To: Torsten Lodderstedt <torsten@lodderstedt.net>
>>>>> Cc: oauth <oauth@ietf.org>
>>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-ba= sed-apps-00
>>>>>
>>>>>=C2=A0
>>>>>
>>>>>=C2=A0
>>>>>
>>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt &l= t;torsten@lodd= erstedt.net> wrote:
>>>>>
>>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.co= m>:
>>>>> >
>>>>> > So you mean at the resource server ensuring the t= oken was really issued to the client? Isn't that an inherent limitation= of all bearer tokens (modulo HTTP token binding, which is still some time = off)?
>>>>>
>>>>> Sure. That=E2=80=99s why the Security BCP recommends u= se of TLS-based methods for sender constraining access tokens (https://tools.ietf.org/html/draft-ie= tf-oauth-security-topics-09#section-2..2). Token Binding for OAuth (https://tools.ietf.org/html/draft-ietf-oa= uth-token-binding-08) as well as Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are t= he options available.
>>>>>
>>>>>=C2=A0
>>>>>
>>>>> Unfortunately even when using the token endpoint, for = SPA / in-browser client applications, the potential mechanisms for sender/k= ey-constraining access tokens don't work very well or maybe don't w= ork at all. So I don't know that the recommendation is very realistic.<= br> >>>>>
>>>>>=C2=A0
>>>>>
>>>>>
>>>>> CONFIDENTIALITY NOTICE: This email may contain confide= ntial and privileged material for the sole use of the intended recipient(s)= .. Any review, use, distribution or disclosure by others is strictly prohib= ited..=C2=A0 If you have received this communication in error, please notif= y the sender immediately by e-mail and delete the message and any file atta= chments from your computer. Thank you.
>>>>>
>>>>> IMPORTANT NOTICE: The contents of this email and any a= ttachments are confidential and may also be privileged. If you are not the = intended recipient, please notify the sender immediately and do not disclos= e the contents to any other person, use it for any purpose, or store or cop= y the information in any medium. Thank you.
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oa= uth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>>
>>> OAuth@ietf= ..org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> > _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

--
----
Aaron Parecki
_______________________________________________
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. --000000000000aae2a5057c21d3f0-- From nobody Mon Dec 3 10:03:53 2018 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 7BFCE130DF5 for ; Mon, 3 Dec 2018 10:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 yMj-L-LSkK1H for ; Mon, 3 Dec 2018 10:03:50 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 21F36124BE5 for ; Mon, 3 Dec 2018 10:03:50 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id i145so10747217ita.4 for ; Mon, 03 Dec 2018 10:03:50 -0800 (PST) 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=+eaGKozTJ5z7uDibctDY416dg4l56aQMAvucwnw+v8U=; b=WpamHamf2OOMHPs5XoxsRpkpb7xmnTKPWij+k4GuOjdGQ/NFz8jvdtWAE9WvDY/+3f CcgvE5F6DOSThBH92NxI+TT1B5m2OAEDk+gYQ9Ivay2Z6H9DtXcKfS5Sk5VfnmXAMHgX NLgTrzQ7cvJAMm9ybse50L9sdF0aBXm8K+Zmw= 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=+eaGKozTJ5z7uDibctDY416dg4l56aQMAvucwnw+v8U=; b=GQKKyqWprDdngcJXu8MajgJNnk1Q96f0R5ZqdCVLG/w6orevEwZ/9/tpHnoCNu4Rp7 XbNmfhQFCpD7V6DTfrH+ccXihvS5uHlmSm9T1l4IbSXrkSBqdvvuJTwVbfaXes7/ybOQ 1ims1TPbe7sc7LPx3bEfqzMOgwnqP6BZ4Vtl0wIRVpKzJNObcDToRHEEUl/uGPkVjFLQ MEfmncbH8wIsxN5Si/JSp7VFyLXlSK6qnrlnNvJZn5Tu0M5zz5KMNY1xtAxBj/xnlFhS Gf20EmtYCFUrghafBz9oiX5sDW6wqvap3tgkiCGQgEfCqqZOiLaCwmcIGI6dsVG5+PfF xx6A== X-Gm-Message-State: AA+aEWal3YwpR1fiMe80JghJUAtGKST/cHoOc3uiGPg7fQ6uDXOCPo39 8W0rN3TIrAih3ZhAbfk2oPCfpfL0NX4mDmO3uim/znaIv35p0glirz9iWB5+LQzSooUHc4h71RJ KPBjSDrQIfe1cYA== X-Google-Smtp-Source: AFSGD/UWSQpQJtJ9vHiqr5G8UCkh49600e5YJSCFQxU3xEgKGaYtusRRRYTlaxA//Kcx+c/6WFDng5l0GRLRD78FJnE= X-Received: by 2002:a05:660c:452:: with SMTP id d18mr1907826itl.124.1543860229361; Mon, 03 Dec 2018 10:03:49 -0800 (PST) MIME-Version: 1.0 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> In-Reply-To: From: Brian Campbell Date: Mon, 3 Dec 2018 11:03:22 -0700 Message-ID: To: Torsten Lodderstedt Cc: Hannes Tschofenig , fett@danielfett.de, oauth Content-Type: multipart/alternative; boundary="0000000000008debf9057c21f8ab" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 03 Dec 2018 18:03:52 -0000 --0000000000008debf9057c21f8ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 1, 2018 at 5:01 AM Torsten Lodderstedt wrote: > > my proposal is to add the following definition (based on 3.8.1.2) to a ne= w > =E2=80=9ETerminology" section or to section 2.1.2: > > A sender constrained access token scopes the applicability of an access > token to a certain sender. This sender is > obliged to demonstrate knowledge of a certain secret as prerequisite for > the acceptance of that token at the recipient (e.g. a resource server). > I think that would be sufficient to avoid reading too much into "sender constrained" based on how it is used elsewhere. Thanks. --=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._ --0000000000008debf9057c21f8ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat= , Dec 1, 2018 at 5:01 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

my proposal is to add the following definition (based on 3.8.1.2) to a new = =E2=80=9ETerminology" section or to section 2.1.2:

A sender constrained access token scopes the applicability of an access tok= en to a certain sender.=C2=A0 This sender is
obliged to demonstrate knowledge of a certain secret as prerequisite for th= e acceptance of that token at the recipient (e.g. a resource server).

I think that would be sufficient to avoid re= ading too much into "sender constrained" based on how it is used = elsewhere. Thanks.=C2=A0
=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. --0000000000008debf9057c21f8ab-- From nobody Mon Dec 3 10:41:39 2018 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 3C11A130E0C for ; Mon, 3 Dec 2018 10:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 ub3rf3tR2g_r for ; Mon, 3 Dec 2018 10:41:36 -0800 (PST) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 702C81277BB for ; Mon, 3 Dec 2018 10:41:36 -0800 (PST) Received: by mail-it1-x12b.google.com with SMTP id x19so10999419itl.1 for ; Mon, 03 Dec 2018 10:41:36 -0800 (PST) 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=0YQlEqPprFhIMBMRFT7+TDNCWcEBh3G7F1pfLaiZ2cE=; b=bs/yL1194e4wvKtOb27rL4rn9zKAzuK0zUSJYi9l4j+E1oegmAnquGKYb4uh13AjMe /XOImBA/Qq8RW0gtmTfEUyczYUTdZINd0rGWVcKdyBc6DSKdIXPA6hQXPiBHl5S9Uuxc LTNUWEGdzJSyfr9jXnq6+x2bkqUg/KBvkaRE4= 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=0YQlEqPprFhIMBMRFT7+TDNCWcEBh3G7F1pfLaiZ2cE=; b=Q9w6NWy6MCXpdWlGtgYFYRgBkxu89ydxL6Fn8gCWXyCbf6cN2iADpU2752pEBAQwfi Xs7lLEuc0ECe8eByTch8RKIb1haNqLMPRw7EZzCxqKXvbGznHQf2UKcQ54HhesccEZB3 rEKuVBBg4lsiyvLH6m0yMcMMq+Ap5wtolRwlmlK/wy5ofTHDyAPyZBT3QuMDHvgzUdoo 6tjfJW7LCrCI17y6K1OrMKILf3fUl04OSWNUgsSjPp3SHznhdsHMRLIipmk1Qb9KuYnn 8mTX6EducHsRyCDGjbMS6FkA2xu/uIeRwnJ6Xe1moaOqMx3e3OWLTXZmjTLNCgreHRz7 ctFQ== X-Gm-Message-State: AA+aEWZyGfjAgDoM3o1u7Humh0xfuhDXRrciDh4wyOAB2RiUeRCUo6Nw r1xPm47syCmyLpRHasZ/z3bSZFWrRTyKj4Hlolx8SqMhATPgop5kWwIZGlAwws9jNQDAo5VDsXO 34KRn+Nd5kztjj7dJ X-Google-Smtp-Source: AFSGD/W7HlmA1mc7J9aP80Dewc74xOErCsKk4xDvTFZMLieKuTwXMgEWuAjEXXTj4LpnaddTpt+04D7/wdjUwS0rjw8= X-Received: by 2002:a02:946e:: with SMTP id a101mr15897577jai.90.1543862495564; Mon, 03 Dec 2018 10:41:35 -0800 (PST) MIME-Version: 1.0 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> In-Reply-To: From: Brian Campbell Date: Mon, 3 Dec 2018 11:41:08 -0700 Message-ID: To: John Bradley Cc: Torsten Lodderstedt , fett@danielfett.de, vittorio.bertocci=40auth0.com@dmarc.ietf.org, oauth Content-Type: multipart/alternative; boundary="000000000000a183b7057c227fed" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 03 Dec 2018 18:41:38 -0000 --000000000000a183b7057c227fed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are saying here. And that was kind of behind the comment I made, or tired to make, about this in Bangkok, which was (more or less) that I don't think the WG should be killing implicit outright but rather that it should begin to recommend against it. I'm not exactly sure what that looks like in this document but maybe toning down some of the scarier language a bit, favoring SHOULDs vs. MUSTs, and including language that helps a reader understand the recommendations as being more considerations for new applications/deployments than as a mandate to rip up existing ones. On Mon, Dec 3, 2018 at 8:39 AM John Bradley wrote: > > We just need to be sensitive to the spin on this. > --=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._ --000000000000a183b7057c227fed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW I'm somewhat sympathetic to what V= ittorio, Dominick, etc. are saying here. And that was kind of behind the co= mment I made, or tired to make, about this in Bangkok, which was (more or l= ess) that I don't think the WG should be killing implicit outright but = rather that it should begin to recommend against it.

I'm not exactly sure what that looks like= in this document but maybe toning down some of the scarier language a bit,= favoring SHOULDs vs. MUSTs, and including language that helps a reader und= erstand the recommendations as being more considerations for new applicatio= ns/deployments than as a mandate to rip up existing ones.
=



On Mon, Dec 3, 2018 at 8:39 AM John Brad= ley <ve7jtb@ve7jt= b.com> wrote:

We just need to be sensitive t= o the spin on this.=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. --000000000000a183b7057c227fed-- From nobody Mon Dec 3 13:50:47 2018 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 EAC2712E7C1 for ; Mon, 3 Dec 2018 13:50:45 -0800 (PST) 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=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 WV7xmTzGxnXc for ; Mon, 3 Dec 2018 13:50:43 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 1E35C12D4ED for ; Mon, 3 Dec 2018 13:50:43 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id l15-v6so12893357lja.9 for ; Mon, 03 Dec 2018 13:50:43 -0800 (PST) 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=4pQ+dkfFieZ/oOPy4CTbmqPJ2OeeA2UVaHst1zawjQ0=; b=XQJcSduv5WHIgeyHDNqUfzPk+ch6v66cSPDmltLltsCcDAwenzLty/40Ql2gAI6txr jexojqjaSEx5oQLattlC3FD+lqPkvt6GpisoIygdVcPERXcb36o6u3mypkQJBfK1+Upd CK4ANId3xzdQI30KVjr8e8x2P92R5GWz8/PItyvvk2piZ7Qt09VGIN/yFXIlgloL1Hh+ rKVFx0p4oXze2xNJQe6c7bjholQlC9/TWTpZ7xQA8Ngklk+jZ9C1BXce6mr49Zte6DAD j9k23Bm04CVmdCn1bxn8k3QJWapqSHU3RYCU4KE5nhifkPHeb/i1klL0YwANu3PwgXW5 oVPA== 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=4pQ+dkfFieZ/oOPy4CTbmqPJ2OeeA2UVaHst1zawjQ0=; b=KlDyUotnr9n1xLK3EYJHwe2p0Lv4C67Xmt7qnlTo8Yxb7CQklILhVpaFNPCEV3Znrp /V6RMnzOIYs6KL59CIN5M33XB6wAQ83XpL2IQK4qud5/MmXRfWQbpswQaoTa3ibdeldz QiWgGHjyASDyfMCalUjeu3KyW38thG2/UW3T+M1Hzl8guZWUIffVFPezL01qsHxQ542o QRzHKp2jVYFGnm71XsBErf8Vw9Y1d4uVBcawbSAmasgkKif+365HkOyoGckyGLZhXe4p Gro226Xu4NYhvEJLaAQJL/0u5z4TidtZJfXJSr54NB1/caFMs8jXFHzO0ANz/sjV3Nm3 8ZMA== X-Gm-Message-State: AA+aEWYrZwNSDXQoaEJ3j2rASMYCt8xdCWO95v5NEvkZ73O5xqEYCKwy dB+eb9PR/SCbQTKc6xkY0mLPCA16AYZ9H8xCPcw= X-Google-Smtp-Source: AFSGD/V32xGruQhmo52oteEWcszTq7+B/B117uzaAbGOpdT+RWTnadi6qrDdat8vRFX3YtETwjPtmiqGVvjqjhpIIlY= X-Received: by 2002:a2e:9e03:: with SMTP id e3-v6mr11240201ljk.4.1543873841150; Mon, 03 Dec 2018 13:50:41 -0800 (PST) MIME-Version: 1.0 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> In-Reply-To: From: Dick Hardt Date: Mon, 3 Dec 2018 13:50:43 -0800 Message-ID: To: Brian Campbell Cc: John Bradley , fett@danielfett.de, vittorio.bertocci=40auth0.com@dmarc.ietf.org, oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000e13ead057c252356" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 03 Dec 2018 21:50:46 -0000 --000000000000e13ead057c252356 Content-Type: text/plain; charset="UTF-8" I disagree. Existing deployments that have not mitigated against the concerns with implicit should be ripped up and updated. For example, at one time, I think it was Instagram that had deployed implicit because it was easier to do. Once the understood the security implications, they changed the implementation. BCPs are rarely a response to a new threat, their are capturing Best Current Practices so that they become widely deployed. On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell wrote: > FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are saying > here. And that was kind of behind the comment I made, or tired to make, > about this in Bangkok, which was (more or less) that I don't think the WG > should be killing implicit outright but rather that it should begin to > recommend against it. > > I'm not exactly sure what that looks like in this document but maybe > toning down some of the scarier language a bit, favoring SHOULDs vs. MUSTs, > and including language that helps a reader understand the recommendations > as being more considerations for new applications/deployments than as a > mandate to rip up existing ones. > > > > On Mon, Dec 3, 2018 at 8:39 AM John Bradley wrote: > >> >> We just need to be sensitive to the spin on this. >> > > *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 > --000000000000e13ead057c252356 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I disagree.=C2=A0

Existing deploy= ments that have not mitigated against the concerns with implicit should be = ripped up and updated.

For example, at one time, I think= it was Instagram that had deployed implicit because it was easier to do. O= nce the understood the security implications, they changed the implementati= on.=C2=A0

BCPs are rarely a response to a new thre= at, their are capturing Best Current Practices so that they become widely d= eployed.




On Mon, Dec 3, 2018 at 10:41 AM Brian= Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
FWIW I'm somewhat s= ympathetic to what Vittorio, Dominick, etc. are saying h= ere. And that was kind of behind the comment I made, or tired to make, abou= t this in Bangkok, which was (more or less) that I don't think the WG s= hould be killing implicit outright but rather that it should begin to recom= mend against it.

<= /span>
I'm not exactly sure what that look= s like in this document but maybe toning down some of the scarier language = a bit, favoring SHOULDs vs. MUSTs, and including language that helps a read= er understand the recommendations as being more considerations for new appl= ications/deployments than as a mandate to rip up existing ones.
=


=

On Mon, Dec 3, 2018 at 8:39 AM John Bradley <ve7jtb@ve7jtb.com> wrote:
We just need to be sensitive to the spin on this.=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 th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000e13ead057c252356-- From marius.scurtescu@coinbase.com Mon Dec 3 16:42:35 2018 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 86EAE130DCC for ; Mon, 3 Dec 2018 16:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=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 YpWMl91DthZ0 for ; Mon, 3 Dec 2018 16:42:33 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 4341E130DCD for ; Mon, 3 Dec 2018 16:42:33 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id 101so7350288pld.6 for ; Mon, 03 Dec 2018 16:42:33 -0800 (PST) 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; bh=Fi6kWLfSnw/b49nY/SFg4pLKJ/owrP1rHrsKDCUR5z4=; b=R0T5jpP7F9FksxVvpm+iH9Ihf9YtC5Rr5XfjlCXOnRWnR3HSR6A7ZWrjBG7vzCqdlC x3BLPN5WZ3PYNM7nZxmNaZBBYMsHz+YVu0GGJaYSWRhsukFSoAKGPEA4wEpp+whaJZZE 5a0qaDqfATFt7cSeB+HjajcMHhuIEmL1zbreY= 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=Fi6kWLfSnw/b49nY/SFg4pLKJ/owrP1rHrsKDCUR5z4=; b=BfL8DUBOwW7eBfX35SykDOu2TG/Yp7SGGjZRleLfu4DCdsh1MsHAE9z3h5XQDk/+eT Oqby1GBqAyTg/PVIMOuwiWKw6SvcqDnnmc+vE5CpbCeBR72VMFONs8oAQFvU75TJXf1C 0g7j1yfK+shvp8giMt1lWDjiEheHvS2RhNIN+v9DA0Nl8lpAHW5NwxvJiUd6JIshsYwB DcUB3Sr3zHZ4cDjA4L64yNmi6v5prRl3A3NzeYue2KarLxSzywbw+Y5dxSSAWKs64rfp MT/VrpI6/VxfS941yiN7GtNkGjoL40fMmAnoRzKD2xKGtIBLFhYy5FN/sTVv2kY5iSx2 qngA== X-Gm-Message-State: AA+aEWayyZZqH7ch4FI2DZAjV/KtWU7f9OjrS+gy/nyayxV4YQS6ePF7 g5vZW4pHXYAIDGAljj/4Gc/alDObNdlwwcG3NX2fVOrzYOM= X-Google-Smtp-Source: AFSGD/XBN3FIBVY5kAwB4uGpXya+/BWAQsa6F/ha5RD975KJy1hcUDVagT12mO0Xpmh407l0trf0XhjtDVPlER7wC10= X-Received: by 2002:a17:902:280b:: with SMTP id e11mr18139655plb.269.1543884152377; Mon, 03 Dec 2018 16:42:32 -0800 (PST) MIME-Version: 1.0 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> In-Reply-To: From: Marius Scurtescu Date: Mon, 3 Dec 2018 16:42:21 -0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000007a4750057c278a7b" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 04 Dec 2018 00:46:44 -0000 --0000000000007a4750057c278a7b Content-Type: text/plain; charset="UTF-8" +1 for the proposed change Providing context around the change and to clarify that this is not a reaction to some emergency would be useful IMO. On Mon, Dec 3, 2018 at 1:50 PM Dick Hardt wrote: > I disagree. > > Existing deployments that have not mitigated against the concerns with > implicit should be ripped up and updated. > > For example, at one time, I think it was Instagram that had deployed > implicit because it was easier to do. Once the understood the security > implications, they changed the implementation. > > BCPs are rarely a response to a new threat, their are capturing Best > Current Practices so that they become widely deployed. > > > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are >> saying here. And that was kind of behind the comment I made, or tired to >> make, about this in Bangkok, which was (more or less) that I don't think >> the WG should be killing implicit outright but rather that it should begin >> to recommend against it. >> >> I'm not exactly sure what that looks like in this document but maybe >> toning down some of the scarier language a bit, favoring SHOULDs vs. MUSTs, >> and including language that helps a reader understand the recommendations >> as being more considerations for new applications/deployments than as a >> mandate to rip up existing ones. >> >> >> >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley wrote: >> >>> >>> We just need to be sensitive to the spin on this. >>> >> >> *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 >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000007a4750057c278a7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for the proposed change

Providin= g context around the change and to clarify that this is not a reaction to s= ome emergency would be useful IMO.

On Mon, Dec 3, 2018 at 1:50 PM Dick Hardt <dick.hardt@gmail.com> wrote:
=
I disagree.=C2=A0

Existing deployments that have not mitigated against the co= ncerns with implicit should be ripped up and updated.

Fo= r example, at one time, I think it was Instagram that had deployed implicit= because it was easier to do. Once the understood the security implications= , they changed the implementation.=C2=A0

BCPs are = rarely a response to a new threat, their are capturing Best Current Practic= es so that they become widely deployed.


<= br>

On Mon= , Dec 3, 2018 at 10:41 AM Brian Campbell <bcampbell=3D40pingidentity.com@dma= rc.ietf.org> wrote:
FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are saying here= . And that was kind of behind the comment I made, or tired to make, about t= his in Bangkok, which was (more or less) that I don't think the WG shou= ld be killing implicit outright but rather that it should begin to recommen= d against it.

I'm not exactly sure what that looks like in this document but maybe = toning down some of the scarier language a bit, favoring SHOULDs vs. MUSTs,= and including language that helps a reader understand the recommendations = as being more considerations for new applications/deployments than as a man= date to rip up existing ones.



<= div dir=3D"ltr">On Mon, Dec 3, 2018 at 8:39 AM John Bradley <ve7jtb@ve7jtb.com> wrote= :

We just need to be sensitive to the spin on this.= =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 t= he sender immediately by e-mail and delete the message and any file attachm= ents from your computer. Thank you.______________________= _________________________
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
--0000000000007a4750057c278a7b-- From nobody Mon Dec 3 16:59:36 2018 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 57446130DCE for ; Mon, 3 Dec 2018 16:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0TY247Ppfqcq for ; Mon, 3 Dec 2018 16:59:30 -0800 (PST) Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 0F797130DBE for ; Mon, 3 Dec 2018 16:59:30 -0800 (PST) Received: by mail-wm1-f44.google.com with SMTP id n190so5353919wmd.0 for ; Mon, 03 Dec 2018 16:59:29 -0800 (PST) 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=D2jW0z7VJYoKIlNIXXJtIzROqibRnufMGMnSuALTuS4=; b=q+PL6CSNkm1R2j5el+sD0OMDs744wyyfAzvh7lagfspGojewiMKSxgKRF5aLkLaIXN N4W9dGYNVBeJtsC+PIAScW9tZktzT8ZALDs5xPRDYWDDQ4A+yb+gWAcNpC/aBkOpAO9c o5Enw5ICAUeBGl7oi9dU64rcwta7NvZxbytzD5lofPnubVVqCjfihD8pcAoauYvXwTnr u7fOERTlaBCbbDSeVHXHtyW9CYG6aiZpBEKCapwWUQGKDUsmXMQl6a59TwEbDO2M859c LN9FI35ik/v5mc5ve9B9zJIxARB4s2b7p6IRmBFW/HrJ6sqjJuIb1VKMLmXBpBd5A9EC eVNw== X-Gm-Message-State: AA+aEWZGoou87Z2wbzShRyNZ1OLRsnXw7GrcOZwbZ3mwjy2F9IFkv8+s W3eRJgTgN0KEV3NlP1QXhfRPwAtMmCaki+DrU9Y= X-Google-Smtp-Source: AFSGD/Wb4KTYFMKX4CwQM5bonsRDyITqnjZSl8qu5oa4SnbotbJf9N8ohTXjJOFRQfgUWsz7nenlI3lC3O1uA71r/QY= X-Received: by 2002:a1c:16ce:: with SMTP id 197mr964219wmw.126.1543885168067; Mon, 03 Dec 2018 16:59:28 -0800 (PST) MIME-Version: 1.0 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> In-Reply-To: From: Nat Sakimura Date: Tue, 4 Dec 2018 09:59:15 +0900 Message-ID: To: Hannes Tschofenig Cc: Aaron Parecki , Torsten Lodderstedt , fett@danielfett.de, oauth Content-Type: multipart/alternative; boundary="000000000000044b05057c27c7d3" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 04 Dec 2018 00:59:35 -0000 --000000000000044b05057c27c7d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hannes, As long as the client is a server-based application, MTLS works fine, and my use-case is exactly that. On the side note: perhaps we may want to take the remaining portion of JPOP up in the near future, as its usefulness is there as Tony pointed out at the time we ported the certs based sender constraint to MTLS in the WG, e.g., when the network after TLS has been terminated cannot be entirely trusted. Best, Nat On Mon, Dec 3, 2018 at 6:39 PM Hannes Tschofenig wrote: > (chair hat off) > > > > Hi Nat, > > > > Section 3.8.1.2 > > of draft-ietf-oauth-security-topics-10 lists the following options for > implementing sender constraint tokens: > > - Token Binding > - MTLS > - Signed HTTP Requests > - JPOP > > > > JPOP is an individual submission. The work on signed HTTP requests > stalled. Token Binding, as we learned at the last IETF meeting, has serio= us > deployment problems. > > That essentially leaves us with MTLS. I am, however, not entirely sure > MTLS works well with the implicit grant. > > > > My conclusion so far from the discussion is that implicit grant cannot be > secured practically. > > > > For IoT, as I mentioned, the story does not look so grim since with IoT > protocols, CoAP or MQTT, one can still use TLS as well as application lay= er > security. (At least that=E2=80=99s the current understanding.) > > > > I am happy to get corrected. > > > > Ciao > > Hannes > > > > > > > > *From:* n-sakimura > *Sent:* Saturday, December 1, 2018 10:44 AM > *To:* Hannes Tschofenig ; Aaron Parecki < > aaron@parecki.com>; Torsten Lodderstedt > *Cc:* Daniel Fett ; IETF oauth WG > *Subject:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend > authorization code instead of implicit > > > > OAuth MTLS has been implemented in Banking industry so we have at least a= n > alternative. > > > > Sender Constrained includes cases where it is not key bound but name boun= d > as I understand and it may have some utility so we f there are doubts, > mentioning the both may be good. > > > > Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B > > > ------------------------------ > > *=E5=B7=AE=E5=87=BA=E4=BA=BA**:* OAuth (Hannes T= schofenig < > hannes.tschofenig@arm.com> =E3=81=AE=E4=BB=A3=E7=90=86) > *=E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82**:* =E5=9C=9F=E6=9B=9C=E6=97=A5, 12= =E6=9C=88 1, 2018 6:07 =E5=8D=88=E5=BE=8C > *=E5=AE=9B=E5=85=88**:* Aaron Parecki; Torsten Lodderstedt > *Cc:* Daniel Fett; IETF oauth WG > *=E4=BB=B6=E5=90=8D**:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend= authorization > code instead of implicit > > > I agree with Aaron here and I think Section 3.8.1.2 > > of draft-ietf-oauth-security-topics-10 already does a pretty good job. > > I was, however, wondering about the subtle implication of the requirement > for sender constrained tokens. My understanding of the token binding > discussion, which is one of the ways to provide sender-constrained tokens= , > is that we don=E2=80=99t have good faith in seeing deployment anytime soo= n. Hence, > we are essentially (reading in between the lines of Section 3.8.1.2) sayi= ng > that you cannot use implicit grant in a practical setup for the web*. > > > > Am I misunderstanding it? > > > > Ciao > > Hannes > > > > PS: The IoT case is likely different. > > > > *From:* OAuth *On Behalf Of *Aaron Parecki > *Sent:* Saturday, December 1, 2018 3:18 AM > *To:* Torsten Lodderstedt > *Cc:* Daniel Fett ; IETF oauth WG > *Subject:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend > authorization code instead of implicit > > > > +1 > > > > I would also like to ensure there is a clear definition of "sender > constrained" tokens in this BCP. > > > > Aaron > > > > > > On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Hi all, > > based on your feedback on the list and off list, Daniel and I polished th= e > text. That=E2=80=99s our proposal: > > =E2=80=94 > In order to avoid these issues, clients MUST NOT use the implicit > grant (response type "token") or any other response type issuing access > tokens in the authorization response, such as "token id_token" and "code > token id_token=E2=80=9C, > unless the issued access tokens are sender-constrained and access token > injection in > the authorization response is prevented. > =E2=80=94 > > Explantation: > - we wanted to have the right balance between a generic definition of the > response types we do not recommend/allow to be used and a > concrete/actionable list of the affected response types. > - we changed from SHOULD NOT to MUST NOT as suggested by Nat and supporte= d > by William > > We look forward to seeing your feedback. > > kind regards, > Torsten. > > > Am 29.11.2018 um 15:15 schrieb John Bradley : > > > > I am ok with that. > > > > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt < > torsten@lodderstedt.net wrote: > > > > > Am 28.11.2018 um 23:50 schrieb n-sakimura : > > > > > > That works. > > > > Good! > > > > I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (on= ly). It would > allow =E2=80=9Etoken=E2=80=9C to be used if the token would sender constr= ained. This > completely ignores the fact implicit also shall be abandoned because of i= ts > vulnerability for access token injection. > > > > I therefore propose a modified text: > > > > In order to avoid these issues, Clients SHOULD NOT use the implicit > > grant. Furthermore, clients SHOULD only use other response types > causing the authorization server to > > issue an access token in the authorization response, if the > particular response type detects access token > > injection and the issued access tokens are sender-constrained. > > > > Or we just state: > > > > In order to avoid these issues, Clients SHOULD NOT use the response > type =E2=80=9Etoken". The response types > > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=80= =9C SOULD NOT be used, if the > issued access tokens are not > > sender-constrained. > > > > > > > > In fact, I would further go and say MUST NOT but that probably is too > much for a security consideration. > > > > > > > Mike suggested to go with a SHOULD NOT to get the message out but give > implementors time to move/change. > > > > > Best, > > > > > > Nat > > > > > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276 > > > > > > > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81= =E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3= =81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF= =86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84= =E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3= =81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81= =AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3= =E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3= =81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F= =A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97= =E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5= =89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81= =BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97= =E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 > > > > > > PLEASE READ :This e-mail is confidential and intended for the named > recipient only. > > > If you are not an intended recipient, please notify the sender and > delete this e-mail. > > > > > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt > > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11= =E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C > > > =E5=AE=9B=E5=85=88: n-sakimura > > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org > > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend= authorization > code instead of implicit > > > > > > Hi Nat, > > > > > >> Am 28.11.2018 um 21:10 schrieb n-sakimura : > > >> > > >> I would support > > >> > > >> 1) clearly defining Implicit as the flow that returns access token > from the authorization endpoint ( some people confuses implicit as the fl= ow > that returns ID Token in the front channel) > > > > > > That=E2=80=99s the current text: > > > > > > In order to avoid these issues, Clients SHOULD NOT use the implicit > > > grant or any other response type causing the authorization server = to > > > issue an access token in the authorization response. > > > > > > What would you like to modify? > > > > > >> > > >> 2) Banning the returning of the access token that are not sender > constrained from the authorization endpoint > > > > > > In order to avoid these issues, Clients SHOULD NOT use the implicit > > > grant or any other response type causing the authorization server = to > > > issue an access token in the authorization response, if this acces= s > tokens is not sender-constraint. > > > > > > What about this? > > > > > > kind regards, > > > Torsten. > > > > > >> > > >> Best, > > >> > > >> Nat > > >> > > >> > > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B > > >> > > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth (Dick Ha= rdt > =E3=81=AE=E4=BB=A3=E7=90=86) > > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 1= 1=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C > > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig > > >> Cc: oauth@ietf.org > > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommen= d authorization > code instead of implicit > > >> > > >> +1 > > >> > > >> While there are various mechanisms to alleviate some of the issues o= f > implicit, I don't think we can recommend specifics, and there may be futu= re > ones in the future. I think we all agree that implicit without any > mitigation is problematic. > > >> > > >> How about we recommend against using implicit alone? > > >> > > >> > > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > >> Hi all, > > >> > > >> The authors of the OAuth Security Topics draft came to the conclusio= n > that it is not possible to adequately secure the implicit flow against > token injection since potential solutions like token binding or JARM are = in > an early stage of adoption. For this reason, and since CORS allows > browser-based apps to send requests to the token endpoint, Torsten > suggested to use the authorization code instead of the implicit grant in > call cases in his presentation (see > https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb= -draft-ietf-oauth-security-topics-01 > ). > > >> > > >> A hum in the room at IETF#103 concluded strong support for his > recommendations. We would like to confirm the discussion on the list. > > >> > > >> Please provide a response by December 3rd. > > >> > > >> 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 > > >> _______________________________________________ > > >> 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 > > -- > > ---- > > Aaron Parecki > > aaronparecki.com > > @aaronpk > > > > 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. > 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 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --000000000000044b05057c27c7d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hannes,=C2=A0

As long as the client is = a server-based application, MTLS works fine, and my use-case is exactly tha= t.=C2=A0

On the side note: perhaps we may want to = take the remaining portion of JPOP up in the near future, as its usefulness= is there as Tony pointed out at the time we ported the certs based sender = constraint to MTLS in the WG, e.g., when the network after TLS has been ter= minated cannot be entirely trusted.=C2=A0

Best,=C2= =A0

Nat

=
On Mon, Dec 3, 2018 at 6:39 PM Hannes Tschofenig <Hannes.Tschofenig@arm.com> w= rote:

(chair hat off)

=C2=A0

Hi Nat,

=C2=A0

Section 3.8.1.2 of draft-ietf-oauth= -security-topics-10 =C2=A0lists the following options for implementing send= er constraint tokens:

  • Token Binding
  • MTLS
  • Signed H= TTP Requests
  • JPOP

=C2=A0

JPOP is an individual submission. The work on signed= HTTP requests stalled. Token Binding, as we learned at the last IETF meeti= ng, has serious deployment problems.

That essentially leaves us with MTLS. I am, however,= not entirely sure MTLS works well with the implicit grant.

=C2=A0

My conclusion so far from the discussion is that imp= licit grant cannot be secured practically.

=C2=A0

For IoT, as I mentioned, the story does not look so = grim since with IoT protocols, CoAP or MQTT, one can still use TLS as well = as application layer security. (At least that=E2=80=99s the current underst= anding.)

=C2=A0

I am happy to get corrected.

=C2=A0

Ciao

Hannes

=C2=A0

=C2=A0

=C2=A0

From: n-sakimura <n-sakimura@nri.co.jp>
Sent: Saturday, December 1, 2018 10:44 AM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Aaron Parecki <<= a href=3D"mailto:aaron@parecki.com" target=3D"_blank">aaron@parecki.com= >; Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Daniel Fett <fett@danielfett.de>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authoriza= tion code instead of implicit

=C2=A0

OAuth MTLS has been implemented in Banking industry = so we have at least an alternative.

=C2=A0

Sender Constrained includes cases where it is not ke= y bound but name bound as I understand and it may have some utility so we f= there are doubts, mentioning the both may be good.

=C2=A0

= Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B

=C2=A0

=E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-boun= ces@ietf.org> (Hannes Tschofenig <hannes.tschofenig@arm.com> =E3=81=AE=E4=BB=A3=E7=90=86) =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E5=9C=9F=E6=9B=9C=E6=97=A5, 12= =E6=9C=88 1, 2018 6:07 =E5=8D=88=E5=BE=8C
=E5=AE=9B=E5=85=88: Aaron Parecki; Torsten Lodderstedt Cc: Daniel Fett; IETF oauth WG
=E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics = -- Recommend authorization code instead of implicit

=C2=A0

I agree with Aaron = here and I think Section 3.8.1.2 of draft-ietf-oauth-security-topics-10 =C2=A0already does a pretty good jo= b.

I was, however, wondering about the subtle implicati= on of the requirement for sender constrained tokens. My understanding of th= e token binding discussion, which is one of the ways to provide sender-cons= trained tokens, is that we don=E2=80=99t have good faith in seeing deployment anytime soon. Hence, we are essentially (r= eading in between the lines of Section 3.8.1.2) saying that you cannot use = implicit grant in a practical setup for the web*.

=C2=A0

Am I misunderstanding it?

=C2=A0

Ciao

Hannes

=C2=A0

PS: The IoT case is likely different. =

=C2=A0

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki
Sent: Saturday, December 1, 2018 3:18 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Daniel Fett <fett@danielfett.de>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authoriza= tion code instead of implicit

=C2=A0

+1

=C2=A0

I would also like to ensure there is a clear definit= ion of "sender constrained" tokens in this BCP.

=C2=A0

Aaron

=C2=A0

=C2=A0

On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt= <torsten@l= odderstedt.net> wrote:

Hi all,

based on your feedback on the list and off list, Daniel and I polished the = text. That=E2=80=99s our proposal:

=E2=80=94
In order to avoid these issues, clients MUST NOT use the implicit
grant (response type "token") or any other response type issuing = access
tokens in the authorization response, such as "token id_token" an= d "code token id_token=E2=80=9C,
unless the issued access tokens are sender-constrained and access token inj= ection in
the authorization response is prevented.
=E2=80=94

Explantation:
- we wanted to have the right balance between a generic definition of the r= esponse types we do not recommend/allow to be used and a concrete/actionabl= e list of the affected response types.
- we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported = by William

We look forward to seeing your feedback.

kind regards,
Torsten.=C2=A0

> Am 29.11.2018 um 15:15 schrieb John Bradley <ve7jtb@ve7jtb.com>:
>
> I am ok with that.=C2=A0
>
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <torsten@lodderstedt.net wr= ote:
>
> > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@nri.co.jp>:
> >
> > That works.
>
> Good!
>
> I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (o= nly). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token would = sender constrained. This completely ignores the fact implicit also shall be= abandoned because of its vulnerability for access token injection.
>
> I therefore propose a modified text:
>
>=C2=A0 =C2=A0 In order to avoid these issues, Clients SHOULD NOT use th= e implicit
>=C2=A0 =C2=A0 grant. Furthermore, clients SHOULD only use other respons= e types causing the authorization server to
>=C2=A0 =C2=A0 issue an access token in the authorization response, if t= he particular response type detects access token
>=C2=A0 =C2=A0 injection and the issued access tokens are sender-constra= ined.
>
> Or we just state:
>
>=C2=A0 =C2=A0In order to avoid these issues, Clients SHOULD NOT use the= response type =E2=80=9Etoken". The response types
> =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2= =80=9C SOULD NOT be used, if the issued access tokens are not
> sender-constrained.
>
> >
> > In fact, I would further go and say MUST NOT but that probably is= too much for a security consideration.
> >
>
> Mike suggested to go with a SHOULD NOT to get the message out but give= implementors time to move/change.
>
> > Best,
> >
> > Nat
> >
> > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-62= 76
> >
> > =E3=81=93= =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=E6=9C=AC=E6= =9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=81=BF=E3=81= =AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=86=E6=83=85= =E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E5= =A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=99=E3=80= =82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=AA=E3=81=84= =E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=E3=81=97=E8= =A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=81=8C=E3=80= =81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=A5=E3=82=89= =E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=E4=BF=A1=E3= =81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=89=8A=E9=99= =A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=BE=E3=81=99= =E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=E4=B8=8A=E3= =81=92=E3=81=BE=E3=81=99=E3=80=82
> >
> > PLEASE READ :This e-mail is confidential and intended for the nam= ed recipient only.
> > If you are not an intended recipient, please notify the sender an= d delete this e-mail.
> >=C2=A0
> > =E5=B7=AE=E5= =87=BA=E4=BA=BA: Torsten Lodderstedt <torsten@lodderstedt.net>
> > =E9=80=81=E4= =BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
> > =E5=AE=9B=E5= =85=88: n-sakimura
> > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> > =E4=BB=B6=E5= =90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorizat= ion code instead of implicit
> >=C2=A0
> > Hi Nat,
> >
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nri.co.jp>: > >>
> >> I would support
> >>
> >> 1) clearly defining Implicit as the flow that returns access = token from the authorization endpoint ( some people confuses implicit as th= e flow that returns ID Token in the front channel)
> >
> > That=E2=80=99s the current text:
> >
> > In order to avoid these issues, Clients SHOULD NOT use the implic= it
> >=C2=A0 =C2=A0 grant or any other response type causing the authori= zation server to
> >=C2=A0 =C2=A0 issue an access token in the authorization response.=
> >
> > What would you like to modify?
> >
> >>
> >> 2) Banning the returning of the access token that are not sen= der constrained from the authorization endpoint
> >
> > In order to avoid these issues, Clients SHOULD NOT use the implic= it
> >=C2=A0 =C2=A0 grant or any other response type causing the authori= zation server to
> >=C2=A0 =C2=A0 issue an access token in the authorization response,= if this access tokens is not sender-constraint.
> >
> > What about this?
> >
> > kind regards,
> > Torsten.
> >
> >>
> >> Best,
> >>
> >> Nat
> >>
> >>
> >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
> >>=C2=A0
> >> =E5=B7=AE= =E5=87=BA=E4=BA=BA: OAuth <oauth-bounces@ietf.org> (Dick Hardt <dick.hardt@gmail.com> =E3=81=AE=E4=BB=A3=E7= =90=86)
> >> =E9=80=81= =E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
> >> =E5=AE=9B= =E5=85=88: Hannes Tschofenig
> >> Cc: oauth= @ietf.org
> >> =E4=BB=B6= =E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authori= zation code instead of implicit
> >>=C2=A0
> >> +1
> >>
> >> While there are various mechanisms to alleviate some of the i= ssues of implicit, I don't think we can recommend specifics, and there = may be future ones in the future. I think we all agree that implicit withou= t any mitigation is problematic.
> >>
> >> How about we recommend against using implicit alone?
> >>
> >>
> >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@a= rm.com> wrote:
> >> Hi all,
> >>
> >> The authors of the OAuth Security Topics draft came to the co= nclusion that it is not possible to adequately secure the implicit flow aga= inst token injection since potential solutions like token binding or JARM a= re in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the t= oken endpoint, Torsten suggested to use the authorization code instead of t= he implicit grant in call cases in his presentation (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-d= raft-ietf-oauth-security-topics-01).
> >>
> >> A hum in the room at IETF#103 concluded strong support for hi= s recommendations. We would like to confirm the discussion on the list.
> >>
> >> Please provide a response by December 3rd.
> >>
> >> Ciao
> >>
> >> Hannes & Rifaat
> >>
> >>=C2=A0
> >>
> >> IMPORTANT NOTICE: The contents of this email and any attachme= nts are confidential and may also be privileged. If you are not the intende= d recipient, please notify the sender immediately and do not disclose the c= ontents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@iet= f.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@iet= f.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
h= ttps://www.ietf.org/mailman/listinfo/oauth

--

----

Aaron Parecki

=C2=A0

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.

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


--
Nat Sakimura = (=3Dnat)
http:= //www.sakimura.org/en/
http://twitter.com/_nat_en
--000000000000044b05057c27c7d3-- From nobody Mon Dec 3 17:08:40 2018 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 CF431130DD8 for ; Mon, 3 Dec 2018 17:08:38 -0800 (PST) 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_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 HmQ1D4rsigC5 for ; Mon, 3 Dec 2018 17:08:35 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 ACA0D130DD3 for ; Mon, 3 Dec 2018 17:08:34 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id x10so14125181wrs.8 for ; Mon, 03 Dec 2018 17:08:34 -0800 (PST) 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=W8a3HUA0OZPPkR1sSkVFIURuFbeugJ9CCL64KZyTng8=; b=NnxF5wvEaXphKOfUAGWZ0Mhl0ih7HDEqSEtJ96bGpiEHMOenYnVU+KyQE/aAtOfllG hcs47blrIHJRLQxr8OWj6k+xAZsARiRDf8CK8pYlRE0tfgtRMssKi4EKAAOO/t07PNVg Wh4HkgkZ1B5ZzwlxGG6PPrVhnFj/025bSjFUFjutg+rpa3UW5JiJLE4h/NBpNNaWQeu8 KPgSkbvZOYNQdWRpIahhWufHoDmgIGmCN5UrWpKQ91bpxCmyeJMgCw88pKz8zlG6x1/x Bc0j3X00sVG1ecHP18nj/7FQU3eE7RYM6+FRg36A0cCZCaPrrCpPc5usyRoptdwEhsyY FOQQ== 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=W8a3HUA0OZPPkR1sSkVFIURuFbeugJ9CCL64KZyTng8=; b=lZzE9Wrk/ljx5ppNGVNXx7pIq0iavyy9PTE/UTmAS15Bd5+5OemAS+vqeZEMAMYjod mxUCkW3tbcfnxEEf77MKNU7NrWND0CGI6D0nys4pEQhN7G7Q3MdRUVH7DuWw4chFp+Sk BpJW2nEbuendr94t/d/xr0bZBn0RMoQg9cq7GegJquP18Ei69h3+4ijVc0x8ZWTqVNvw lus+7wxKdZm4iS+dFsxuJmlVV0tMmWkLAXSMvgFfuqJnoCA+xPLsZZpkvXtV2SIlmMRD U6T8ly+Frh2YPsB2mxrPzwO/yuEZIk6EMK8y18Hd+YTXWMU2/VuaNhdeehwDqz1Rf2P2 /aJw== X-Gm-Message-State: AA+aEWZvsP0DE6eOnFRvrOcJYtN0btrbIqN2zT3Tspq3TT9BXEWDKxQr LfrqKfgR77c67oFGlGsPrIc0NBlScWi5Gn27/z4= X-Google-Smtp-Source: AFSGD/WXfi6TZUp8/Ui0z70SuNyNqvs+vcjX5HLkTArBwVRTyRZAK72OzhDaNe7JKu/23EhlJJohgOLnyA0BMxH86K4= X-Received: by 2002:adf:e34b:: with SMTP id n11mr15162382wrj.91.1543885712856; Mon, 03 Dec 2018 17:08:32 -0800 (PST) MIME-Version: 1.0 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <558F050A-AC67-45B5-8D55-A025444539A2@lodderstedt.net> In-Reply-To: From: Nat Sakimura Date: Tue, 4 Dec 2018 10:08:20 +0900 Message-ID: To: Brian Campbell Cc: Torsten Lodderstedt , fett@danielfett.de, oauth Content-Type: multipart/alternative; boundary="0000000000007d1a96057c27e75d" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 04 Dec 2018 01:08:39 -0000 --0000000000007d1a96057c27e75d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Belated +1 to this. "sender or key constrained" is good. Also, the new definition of "sender constrained" per Torsten states "knowledge of" but that is only applicable to "key constrained" variant I guess, besides "knowledge" is a bit "fluffy". I feel that just saying as suggested by Brian safer. My 2c. Nat On Sat, Dec 1, 2018 at 7:24 AM Brian Campbell wrote: > Kind of, yes. I guess so. I think. It's just semantics. But yeah. Key > constrained might be more appropriate. But the Security Topics document > probably should allow for both/either. > > I don't think that these are necessarily terms with widely agreed upon or > understood meaning. But it was pointed out to me that the OAuth 2.0 Pop > Architecture draft defines sender constraint and key confirmation as > different things ( > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-= 6.2 > and > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-= 6.3 > ). > And the definitions their do kind of make sense when thinking about the > words used. The line between sender and key constrained isn't exactly cle= ar > but it seems MTLS and token binding access tokens are more key constraine= d > than sender. The -08 version of the MTLS draft dropped the use of the > "sender constrained" terminology based on that feedback. > > I dunno. Maybe the Security Topics could say something in a terminology > section that says when sender or key constrained is used within they can = be > taken to mean the same concept. Or something like that. > > On Fri, Nov 30, 2018 at 1:42 PM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi Brian, >> >> we use =E2=80=9Esender constrained tokens=E2=80=9C throughout the BCP to= denote tokens >> bound to a sender in possession of a certain key/secret and I thought th= at >> was established terminology in the group. Are you suggesting =E2=80=9Eke= y >> constrained=E2=80=9D would be more appropriate? >> >> kind regards, >> Torsten. >> >> Am 30.11.2018 um 21:02 schrieb Brian Campbell > >: >> >> As was pointed out to me in WGLC review of the MTLS document, >> "sender-constrained" has or is likely to be interpreted with a pretty >> specific meaning of the token being bound to the client and the client >> authenticating itself to the resource and the resource checking all that >> matches up. That makes the text more restrictive than is likely intended= . >> Perhaps the text should say something like "sender or key constrained" t= o >> allow for different variants of PoP access tokens? >> >> >> >> On Thu, Nov 29, 2018 at 11:06 AM Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> Hi all, >>> >>> based on your feedback on the list and off list, Daniel and I polished >>> the text. That=E2=80=99s our proposal: >>> >>> =E2=80=94 >>> In order to avoid these issues, clients MUST NOT use the implicit >>> grant (response type "token") or any other response type issuing access >>> tokens in the authorization response, such as "token id_token" and "cod= e >>> token id_token=E2=80=9C, >>> unless the issued access tokens are sender-constrained and access token >>> injection in >>> the authorization response is prevented. >>> =E2=80=94 >>> >>> Explantation: >>> - we wanted to have the right balance between a generic definition of >>> the response types we do not recommend/allow to be used and a >>> concrete/actionable list of the affected response types. >>> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and >>> supported by William >>> >>> We look forward to seeing your feedback. >>> >>> kind regards, >>> Torsten. >>> >>> > Am 29.11.2018 um 15:15 schrieb John Bradley : >>> > >>> > I am ok with that. >>> > >>> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt < >>> torsten@lodderstedt.net wrote: >>> > >>> > > Am 28.11.2018 um 23:50 schrieb n-sakimura : >>> > > >>> > > That works. >>> > >>> > Good! >>> > >>> > I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (= only). It would >>> allow =E2=80=9Etoken=E2=80=9C to be used if the token would sender cons= trained. This >>> completely ignores the fact implicit also shall be abandoned because of= its >>> vulnerability for access token injection. >>> > >>> > I therefore propose a modified text: >>> > >>> > In order to avoid these issues, Clients SHOULD NOT use the implici= t >>> > grant. Furthermore, clients SHOULD only use other response types >>> causing the authorization server to >>> > issue an access token in the authorization response, if the >>> particular response type detects access token >>> > injection and the issued access tokens are sender-constrained. >>> > >>> > Or we just state: >>> > >>> > In order to avoid these issues, Clients SHOULD NOT use the response >>> type =E2=80=9Etoken". The response types >>> > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2= =80=9C SOULD NOT be used, if the >>> issued access tokens are not >>> > sender-constrained. >>> > >>> > > >>> > > In fact, I would further go and say MUST NOT but that probably is >>> too much for a security consideration. >>> > > >>> > >>> > Mike suggested to go with a SHOULD NOT to get the message out but giv= e >>> implementors time to move/change. >>> > >>> > > Best, >>> > > >>> > > Nat >>> > > >>> > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276 >>> > > >>> > > >>> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80= =81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE= =E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5= =AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81= =84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE= =E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3= =81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94= =B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93= =E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7= =9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F= =97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF= =E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3= =81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81= =97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 >>> > > >>> > > PLEASE READ :This e-mail is confidential and intended for the named >>> recipient only. >>> > > If you are not an intended recipient, please notify the sender and >>> delete this e-mail. >>> > > >>> > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt >>> > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, = 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C >>> > > =E5=AE=9B=E5=85=88: n-sakimura >>> > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org >>> > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recomme= nd authorization >>> code instead of implicit >>> > > >>> > > Hi Nat, >>> > > >>> > >> Am 28.11.2018 um 21:10 schrieb n-sakimura : >>> > >> >>> > >> I would support >>> > >> >>> > >> 1) clearly defining Implicit as the flow that returns access token >>> from the authorization endpoint ( some people confuses implicit as the = flow >>> that returns ID Token in the front channel) >>> > > >>> > > That=E2=80=99s the current text: >>> > > >>> > > In order to avoid these issues, Clients SHOULD NOT use the implicit >>> > > grant or any other response type causing the authorization serve= r >>> to >>> > > issue an access token in the authorization response. >>> > > >>> > > What would you like to modify? >>> > > >>> > >> >>> > >> 2) Banning the returning of the access token that are not sender >>> constrained from the authorization endpoint >>> > > >>> > > In order to avoid these issues, Clients SHOULD NOT use the implicit >>> > > grant or any other response type causing the authorization serve= r >>> to >>> > > issue an access token in the authorization response, if this >>> access tokens is not sender-constraint. >>> > > >>> > > What about this? >>> > > >>> > > kind regards, >>> > > Torsten. >>> > > >>> > >> >>> > >> Best, >>> > >> >>> > >> Nat >>> > >> >>> > >> >>> > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B >>> > >> >>> > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth (Dick = Hardt < >>> dick.hardt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86) >>> > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5,= 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C >>> > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig >>> > >> Cc: oauth@ietf.org >>> > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recomm= end authorization >>> code instead of implicit >>> > >> >>> > >> +1 >>> > >> >>> > >> While there are various mechanisms to alleviate some of the issues >>> of implicit, I don't think we can recommend specifics, and there may be >>> future ones in the future. I think we all agree that implicit without a= ny >>> mitigation is problematic. >>> > >> >>> > >> How about we recommend against using implicit alone? >>> > >> >>> > >> >>> > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig < >>> Hannes.Tschofenig@arm.com> wrote: >>> > >> Hi all, >>> > >> >>> > >> The authors of the OAuth Security Topics draft came to the >>> conclusion that it is not possible to adequately secure the implicit fl= ow >>> against token injection since potential solutions like token binding or >>> JARM are in an early stage of adoption. For this reason, and since CORS >>> allows browser-based apps to send requests to the token endpoint, Torst= en >>> suggested to use the authorization code instead of the implicit grant i= n >>> call cases in his presentation (see >>> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-ses= sb-draft-ietf-oauth-security-topics-01 >>> ). >>> > >> >>> > >> A hum in the room at IETF#103 concluded strong support for his >>> recommendations. We would like to confirm the discussion on the list. >>> > >> >>> > >> Please provide a response by December 3rd. >>> > >> >>> > >> 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 intende= d >>> 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 = the >>> information in any medium. Thank you. >>> > >> _______________________________________________ >>> > >> 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 >>> >> >> *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 send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> > *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 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --0000000000007d1a96057c27e75d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Belated=C2=A0+1 to this.=C2=A0 "sender or key constra= ined" is good.=C2=A0

Also, the new definition of &q= uot;sender constrained" per Torsten states "knowledge of" bu= t that is only applicable to "key constrained" variant I guess, b= esides "knowledge" is a bit "fluffy". I feel that just = saying as suggested by Brian safer. My 2c.=C2=A0

N= at

On Sat, Dec 1= , 2018 at 7:24 AM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:=
=
Kind of, yes. I gue= ss so. I think. It's just semantics. But yeah. Key constrained might be= more appropriate. But the Security Topics document probably should allow f= or both/either.

I don't think that these = are necessarily terms with widely agreed upon or understood meaning. But it= was pointed out to me that the OAuth 2.0 Pop Architecture draft defines sen= der constraint and key confirmation as different things (https://tools.ietf.org/html/d= raft-ietf-oauth-pop-architecture-08#section-6.2 and https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture= -08#section-6.3). And the definitions their do kind of make sense when = thinking about the words used. The line between sender and key constrained = isn't exactly clear but it seems MTLS and token binding access tokens a= re more key constrained than sender. The -08 version of the MTLS draft drop= ped the use of the "sender constrained" terminology based on that= feedback.

I dunno. Maybe the Security Topics= could say something in a terminology section that says when sender or key = constrained is used within they can be taken to mean the same concept. Or s= omething like that.

On Fri, Nov 30, 2018 at 1:42 PM Torsten L= odderstedt <torsten@lodderstedt.net> wrote:
Hi Brian,

we use =E2=80=9Esender const= rained tokens=E2=80=9C throughout the BCP to denote tokens bound to a sende= r in possession of a certain key/secret and I thought that was established = terminology in the group. Are you suggesting =E2=80=9Ekey constrained=E2=80= =9D would be more appropriate?

kind regards,
Torsten.
Am 30.11.2018 um 21:02 schrieb Brian Campbell <bcampbell@pingidentity.com>:=

<= div>As was pointed out to me in WGLC review of the MTLS document, "sen= der-constrained" has or is likely to be interpreted with a pretty spec= ific meaning of the token being bound to the client and the client authenti= cating itself to the resource and the resource checking all that matches up= . That makes the text more restrictive than is likely intended. Perhaps the= text should say something like "sender or key constrained" to al= low for different variants of PoP access tokens?

<= div>

On Thu,= Nov 29, 2018 at 11:06 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:<= br>
Hi all,

based on your feedback on the list and off list, Daniel and I polished the = text. That=E2=80=99s our proposal:

=E2=80=94
In order to avoid these issues, clients MUST NOT use the implicit
grant (response type "token") or any other response type issuing = access
tokens in the authorization response, such as "token id_token" an= d "code token id_token=E2=80=9C,
unless the issued access tokens are sender-constrained and access token inj= ection in
the authorization response is prevented.
=E2=80=94

Explantation:
- we wanted to have the right balance between a generic definition of the r= esponse types we do not recommend/allow to be used and a concrete/actionabl= e list of the affected response types.
- we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported = by William

We look forward to seeing your feedback.

kind regards,
Torsten.=C2=A0

> Am 29.11.2018 um 15:15 schrieb John Bradley <ve7jtb@ve7jtb.com>:
>
> I am ok with that.=C2=A0
>
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <torsten@lodderstedt.net wr= ote:
>
> > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@nri.co.jp>:
> >
> > That works.
>
> Good!
>
> I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (o= nly). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token would = sender constrained. This completely ignores the fact implicit also shall be= abandoned because of its vulnerability for access token injection.
>
> I therefore propose a modified text:
>
>=C2=A0 =C2=A0 In order to avoid these issues, Clients SHOULD NOT use th= e implicit
>=C2=A0 =C2=A0 grant. Furthermore, clients SHOULD only use other respons= e types causing the authorization server to
>=C2=A0 =C2=A0 issue an access token in the authorization response, if t= he particular response type detects access token
>=C2=A0 =C2=A0 injection and the issued access tokens are sender-constra= ined.
>
> Or we just state:
>
>=C2=A0 =C2=A0In order to avoid these issues, Clients SHOULD NOT use the= response type =E2=80=9Etoken". The response types
> =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2= =80=9C SOULD NOT be used, if the issued access tokens are not
> sender-constrained.
>
> >
> > In fact, I would further go and say MUST NOT but that probably is= too much for a security consideration.
> >
>
> Mike suggested to go with a SHOULD NOT to get the message out but give= implementors time to move/change.
>
> > Best,
> >
> > Nat
> >
> > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
> >
> > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF= =E3=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3= =81=AE=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9= =9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6= =E3=81=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3= =81=BE=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81= =AE=E3=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB= =E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3= =82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81= =8A=E7=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F= =E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3= =81=AF=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81= =84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3= =E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
> >
> > PLEASE READ :This e-mail is confidential and intended for the nam= ed recipient only.
> > If you are not an intended recipient, please notify the sender an= d delete this e-mail.
> >=C2=A0
> > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt <torsten@lodderstedt.net>
> > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5= , 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
> > =E5=AE=9B=E5=85=88: n-sakimura
> > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recom= mend authorization code instead of implicit
> >=C2=A0
> > Hi Nat,
> >
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nri.co.jp>: > >>
> >> I would support
> >>
> >> 1) clearly defining Implicit as the flow that returns access = token from the authorization endpoint ( some people confuses implicit as th= e flow that returns ID Token in the front channel)
> >
> > That=E2=80=99s the current text:
> >
> > In order to avoid these issues, Clients SHOULD NOT use the implic= it
> >=C2=A0 =C2=A0 grant or any other response type causing the authori= zation server to
> >=C2=A0 =C2=A0 issue an access token in the authorization response.=
> >
> > What would you like to modify?
> >
> >>
> >> 2) Banning the returning of the access token that are not sen= der constrained from the authorization endpoint
> >
> > In order to avoid these issues, Clients SHOULD NOT use the implic= it
> >=C2=A0 =C2=A0 grant or any other response type causing the authori= zation server to
> >=C2=A0 =C2=A0 issue an access token in the authorization response,= if this access tokens is not sender-constraint.
> >
> > What about this?
> >
> > kind regards,
> > Torsten.
> >
> >>
> >> Best,
> >>
> >> Nat
> >>
> >>
> >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
> >>=C2=A0
> >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-bounces@ietf.org> (Dick = Hardt <dick.ha= rdt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86)
> >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6= =97=A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
> >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
> >> Cc: oauth= @ietf.org
> >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- R= ecommend authorization code instead of implicit
> >>=C2=A0
> >> +1
> >>
> >> While there are various mechanisms to alleviate some of the i= ssues of implicit, I don't think we can recommend specifics, and there = may be future ones in the future. I think we all agree that implicit withou= t any mitigation is problematic.
> >>
> >> How about we recommend against using implicit alone?
> >>
> >>
> >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@a= rm.com> wrote:
> >> Hi all,
> >>
> >> The authors of the OAuth Security Topics draft came to the co= nclusion that it is not possible to adequately secure the implicit flow aga= inst token injection since potential solutions like token binding or JARM a= re in an early stage of adoption. For this reason, and since CORS allows br= owser-based apps to send requests to the token endpoint, Torsten suggested = to use the authorization code instead of the implicit grant in call cases i= n his presentation (see https://datatracker.ietf.org/meeting/103/= materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).<= br> > >>
> >> A hum in the room at IETF#103 concluded strong support for hi= s recommendations. We would like to confirm the discussion on the list.
> >>
> >> Please provide a response by December 3rd.
> >>
> >> Ciao
> >>
> >> Hannes & Rifaat
> >>
> >>=C2=A0
> >>
> >> IMPORTANT NOTICE: The contents of this email and any attachme= nts are confidential and may also be privileged. If you are not the intende= d recipient, please notify the sender immediately and do not disclose the c= ontents to any other person, use it for any purpose, or store or copy the i= nformation in any medium. Thank you.
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@iet= f.org
> >> https://www.ietf.org/mailman/listinfo/oau= th
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@iet= f.org
> >> https://www.ietf.org/mailman/listinfo/oau= th
> >
>
> _______________________________________________
> 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

<= 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 th= e sender immediately by e-mail and delete the message and any file attachme= nts 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 th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
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
--0000000000007d1a96057c27e75d-- From nobody Tue Dec 4 00:52:03 2018 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 4566C128D68 for ; Tue, 4 Dec 2018 00:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" 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 PW7Pc4r01phh for ; Tue, 4 Dec 2018 00:52:00 -0800 (PST) Received: from sonic317-36.consmr.mail.ne1.yahoo.com (sonic317-36.consmr.mail.ne1.yahoo.com [66.163.184.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 6DA9E130E1D for ; Tue, 4 Dec 2018 00:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1543913519; bh=R0Dp3bQz42KrLH6OiL7gygTLqCH4a173KEPbADbZEFE=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=WC4enOWOyYtaur2MRjutSIJvKnAdwVvrU3j0lzGck0upWSd99/h1l/j3vVn/FP1/6lfVwGeA/P9QlQ8WxXpSLo4KdUb4zkJd7SKt4UDqerJ82PZVM0i8fh+p6coSsNaNRXh+uu7lNaKL3Uir6I527mL2EgmxRYNubP52Qaq4cSCPV8tph9mkXx9St4OlZZGtnzkLAAC0D5B6pMStvym9xPUkPda+LftMT1e6iVZthsNkFGH8v+QiNYTtMY3Cf34N5/GgDY9TZfkCnDyMhGUvzSznVJP2xgmi7jHhjtynmIyWb9vYKrkPYPT8YLk9jw9391EJFhQWdIpqzdXO4Fs28w== X-YMail-OSG: rdSLfEAVM1kscUI3SBh4ZQ4eoiCTczAT.jJ.TTVMOP5GuDTorG9T_gPm25_DGNW ivGLbBSlJl73ej8HeQKht.Ujx0lhQCcunVbWFB2yxyFfyHALhNyE9ug1aZruMJsh_Pv9_1J1Pzv_ fB27HzGhixqrfASJLUantENWkuGr8Vo3V06M.6k_w1u33mn2qWlTrSAEqYVYqEUc._W8ugpmFln4 IJ359cnpLSxsrEmnoEDWm2PKt6mIuZtKIU2m9SmL58zTZwOKZobyO7G6bQCsFDsNQxXMBOrmo65v GhR5dHPJxx0RxgoDMISkqR9ulAS5ZQHWtrgts61X7cddmubgjg99pa.Wn0GnYFJGhr3oCPZcyfm1 8lX17n7t8NGbinEjbKfmmDI7G4j.xsDbcTRDfyF6p6vpPDPoYE8kWo14Kn4LrLRoxOX1w6_bEuO. yy7medvdyMd_A1IXa20MQ9A.LGzKB0NEsX6BHxAIN1FP2iVBbHI3IlnPcrsw8sqURtViALpNI.Hi 23v1re6oDnj1_ok_SRd4F5z1fmJxcdLDB255sMbI_EjIU7T7xbXz3eBQeX1MdrfcIKUOsFR0OS8w kpCKYS.5VPBlCJ5YTkC0k8sKka70.AQsDwibu98LAl4pVW38RCVuOfhEV3fSYolVGCe0ND_zOsDs XGXaYfiFvMLaPrHDSM9MUPOAVYOofg1PGlxdsH0a2ZVNqM1qs4qSHZ8pGzWYQQYu1l2q3v..xmin RyWJRv_Uuq1tLr5EATD.gymh8oxBaruOMuG00LCeoIDo1zWd2wpxB1lTJa.6a4dPeMRIaHahpokm eEFBGJkS3Vb6P_2ZRRNqEd0A56vl3340URvLtHiPWoL7DmWttjnEJpynth29pa52cx3Wkr0AVmWB V6UiOUKxfxY59k1lJeqgTU2LawBhwBHMBUps3RdOu.G0X23u7vgZJt2OVQIsEq70hdaSqLmn.usy DEcBx2f65RqJ5hJ.7.VmvopEJTbmJ6TwiCueMxo_EeiDXQApQK6w9X_lLotcknVOiZUHBn7hJY80 2nDL2GUWQRiSRpJjEDAS7gDNaAk2hCiK.Bw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Tue, 4 Dec 2018 08:51:59 +0000 Date: Tue, 4 Dec 2018 08:50:04 +0000 (UTC) From: Tomek Stojecki To: Brian Campbell , Dick Hardt Cc: fett@danielfett.de, vittorio.bertocci=40auth0.com@dmarc.ietf.org, oauth@ietf.org Message-ID: <458858450.1398445.1543913404101@mail.yahoo.com> In-Reply-To: References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.12827 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36 Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 04 Dec 2018 08:52:02 -0000 I agree with Vittorio, Dominick et al.=C2=A0 > I disagree.=C2=A0 > Existing deployments that have not mitigated against the concerns with im= plicit should be ripped up and updated. Yes, just like future deployments that will not mitigate against the concer= ns of code in the browser should be a concern. Can somebody on the other side of the argument (and I hate to make it sound= like there are two sides, because we're on the same side as far as Implici= t's AT in front-channel is a real issue) address Dominic's comment:=C2=A0 > Also - simply saying =E2=80=9Cimplicit is evil - switch to code=E2=80=9D = means for most people also using refresh token - so we are treating access = tokens in the URL with refresh tokens in session storage (over simplified -= but you get the idea). Does the group agree|disagree that a recommendation to switch to code shoul= d be made as long as it is followed by an explanation and guidance on what = to do with RTs? The ideas that were floated around=C2=A0 - Token bound RTs (even though it was pointed out that token binding is sti= ll considered an emerging standard). So should the recommendation than say = "switch to code and MUST use token bound RTs"? - Have AS not release RTs. "Switch to code and DO NOT request RTs"? Or swit= ch to code and configure AT to not release RTs for this type of client (not= sure what that even looks like in a form of a 3rd party clients)? - RTs short lived and bound to a session - "Switch to code as long as AT ca= n bind and revoke RTs when you log out" Sorry if I have missed an important detail from the list above, people who = have proposed these ideas, feel free to clarify.=C2=A0 On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt wrote:=20 I disagree.=C2=A0 Existing deployments that have not mitigated against the concerns with impl= icit should be ripped up and updated. For example, at one time, I think it was Instagram that had deployed implic= it because it was easier to do. Once the understood the security implicatio= ns, they changed the implementation.=C2=A0 BCPs are rarely a response to a new threat, their are capturing Best Curren= t Practices so that they become widely deployed. On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell wrote: > FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are saying= here. And that was kind of behind the comment I made, or tired to make, ab= out this in Bangkok, which was (more or less) that I don't think the WG sho= uld be killing implicit outright but rather that it should begin to recomme= nd against it.=20 >=20 > I'm not exactly sure what that looks like in this document but maybe toni= ng down some of the scarier language a bit, favoring SHOULDs vs. MUSTs, and= including language that helps a reader understand the recommendations as b= eing more considerations for new applications/deployments than as a mandate= to rip up existing ones.=20 >=20 >=20 >=20 > On Mon, Dec 3, 2018 at 8:39 AM John Bradley wrote: >>=20 >> We just need to be sensitive to the spin on this.=C2=A0=20 >>=20 >=20 > 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...=C2=A0 If you= have received this communication in error, please notify the sender immedi= ately by e-mail and delete the message and any file attachments from your c= omputer. Thank you._______________________________________________ > 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 From nobody Tue Dec 4 05:08:28 2018 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 DB355130DD6 for ; Tue, 4 Dec 2018 05:08:26 -0800 (PST) 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 Y8b3wI0Q1s8N for ; Tue, 4 Dec 2018 05:08:23 -0800 (PST) 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 56E7A126DBF for ; Tue, 4 Dec 2018 05:08:22 -0800 (PST) Received: from [80.155.34.3] (helo=[10.3.12.54]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gUAR1-0000dy-4o; Tue, 04 Dec 2018 14:08:19 +0100 From: Torsten Lodderstedt Message-Id: <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_87E9291C-C7BA-421B-B08D-5EA92ED5AC91"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Tue, 4 Dec 2018 14:08:18 +0100 In-Reply-To: <458858450.1398445.1543913404101@mail.yahoo.com> Cc: Brian Campbell , Dick Hardt , Daniel Fett , Vittorio Bertocci , oauth@ietf.org To: Tomek Stojecki References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 04 Dec 2018 13:08:27 -0000 --Apple-Mail=_87E9291C-C7BA-421B-B08D-5EA92ED5AC91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tomek, > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki = : >=20 > I agree with Vittorio, Dominick et al.=20 >=20 >> I disagree.=20 >=20 >> Existing deployments that have not mitigated against the concerns = with implicit should be ripped up and updated. >=20 > Yes, just like future deployments that will not mitigate against the = concerns of code in the browser should be a concern. I agree. That=E2=80=99s why I pointed point yesterday that the Security = BCP also defines obligations for clients using code.=20 = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.= 1 = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.= 1.1 >=20 > Can somebody on the other side of the argument (and I hate to make it = sound like there are two sides, because we're on the same side as far as = Implicit's AT in front-channel is a real issue) address Dominic's = comment:=20 >=20 >> Also - simply saying =E2=80=9Cimplicit is evil - switch to code=E2=80=9D= means for most people also using refresh token - so we are treating = access tokens in the URL with refresh tokens in session storage (over = simplified - but you get the idea). >=20 > Does the group agree|disagree that a recommendation to switch to code = should be made as long as it is followed by an explanation and guidance = on what to do with RTs? The ideas that were floated around=20 > - Token bound RTs (even though it was pointed out that token binding = is still considered an emerging standard). So should the recommendation = than say "switch to code and MUST use token bound RTs"? > - Have AS not release RTs. "Switch to code and DO NOT request RTs"? Or = switch to code and configure AT to not release RTs for this type of = client (not sure what that even looks like in a form of a 3rd party = clients)? > - RTs short lived and bound to a session - "Switch to code as long as = AT can bind and revoke RTs when you log out=E2=80=9C Basically, the AS does not need to issue refresh tokens. If the AS does = not issue refresh tokens, the integration pattern for SPAs does not = change (beside the code exchange). If the client needs a new access = token, it will perform another authorization request. =20 If it does, this adds another layer of security because it allows the = client to frequently obtain new access tokens, which can be short-lived = and scope restricted.=20 The refresh tokens should be replay protected by issuing new refresh = tokens with every refresh and detect replay for refresh tokens belonging = to the same grant.=20 The AS may additionally bind refresh tokens to AS sessions, but as it = was pointed out by Annabelle and others, there are some implications to = be understood and managed in that context. You may find more text about refresh tokens in the Security BCP = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.= 12 kind regards, Torsten.=20 >=20 > Sorry if I have missed an important detail from the list above, people = who have proposed these ideas, feel free to clarify.=20 >=20 > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt = wrote:=20 >=20 > I disagree.=20 >=20 > Existing deployments that have not mitigated against the concerns with = implicit should be ripped up and updated. >=20 > For example, at one time, I think it was Instagram that had deployed = implicit because it was easier to do. Once the understood the security = implications, they changed the implementation.=20 >=20 > BCPs are rarely a response to a new threat, their are capturing Best = Current Practices so that they become widely deployed. >=20 >=20 >=20 >=20 > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell = wrote: >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are = saying here. And that was kind of behind the comment I made, or tired to = make, about this in Bangkok, which was (more or less) that I don't think = the WG should be killing implicit outright but rather that it should = begin to recommend against it.=20 >>=20 >> I'm not exactly sure what that looks like in this document but maybe = toning down some of the scarier language a bit, favoring SHOULDs vs. = MUSTs, and including language that helps a reader understand the = recommendations as being more considerations for new = applications/deployments than as a mandate to rip up existing ones.=20 >>=20 >>=20 >>=20 >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley = wrote: >>>=20 >>> We just need to be sensitive to the spin on this. =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._______________________________________________ >> 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=_87E9291C-C7BA-421B-B08D-5EA92ED5AC91 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODEyMDQxMzA4MTlaMC8GCSqGSIb3DQEJBDEiBCAM IncHcfCIxWsRiLfc7eQVZIR9+8ENa/TtQ5R0IfMDfTCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAmx2zsD4kUtkXr2s2Y69G/evb ehP+Hy5QbsKr7r050VI69zVDlMO4qMx/mWZmHSENtvJA7wycZTsUk8Or1Um6TRbKrLp6lR7pnAuu 34eVGxAnMvoGjhAgcd8dnUOZNqWJvxcsBqTbCOhzWZ3Zzz0Rc0oYA3QHOCFVq8kl4jExRkhvaJEj 7JLOg2m+///ALt95e8IZKk3DSRYDfyVjIx/2Kezb1N//duRLmPMzAeEfYhttF9gVqG/d+NmJ1iTF m+5nG169HK1l+rlAb2eS/L39PMTK4/+AqaUW7u15Fl1w3xPNCGbq6n+lfa0ZCpEUJqWzXmC8pehj e6voikSHlTWP7QAAAAAAAA== --Apple-Mail=_87E9291C-C7BA-421B-B08D-5EA92ED5AC91-- From nobody Tue Dec 4 10:13:22 2018 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 B3264130E95 for ; Tue, 4 Dec 2018 10:13:20 -0800 (PST) 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 KPFrCakwDKrv for ; Tue, 4 Dec 2018 10:13:19 -0800 (PST) Received: from sonic307-11.consmr.mail.ne1.yahoo.com (sonic307-11.consmr.mail.ne1.yahoo.com [66.163.190.34]) (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 E49EA130E4D for ; Tue, 4 Dec 2018 10:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1543947198; bh=P9X5T/iKbjie9ng4GtXVznPJ+zddOmVCs6HWBReK7p0=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=RzdpgTJKAxxDegAUZyQqn6QNApDwp3AleY8dEiT7Zf3AQT2ZQv4hrjPhpXVj4ZKD4BtZphPO/WjmTepcd9HAJBClV3f4FVTzWCnetHThMFynYK0/QkZ/XGyFm90mir9wCdgR8pjNLh0FHo9extknaVZ2KjKIg+ER5YEFXNaUSQgRRHDaoptfbwLkVMo0cSapfSlMuz3oQjgXAubziRboDfl23lqrtMK0TZwRcWruH2MM0fCg2juw6JhYl5ioFY7ceuSO5qO0KsbttNi/4pPpiXyV5s59jNxVkMPsTK52gb0MQ3sikAO7oz2hRGC6kb0BgoXkZUDEsi2yD8TjOA9ufw== X-YMail-OSG: XNPNhlgVM1let5MPR0K7_H5iCvepimYDxFAn0ZiSfUhcmHZVwA_BwDXD9B3MlR0 Qtt6PiYtN12VvdkcbXw9WWsfxsgSc4otJkktRu9Mxlfx47Xj5Y82MRHeQB0QCoINQDT516nJ2O5b 2pvr0Wy32IHuRcuk98RH2qg0VIrM5HJaZpfkccOuGk.dWgjBgnYkm.NH5I0Aicqu0kbBev.8TMot ZFQMbFH_R5JiXSIyiqh7inF70ACIsADEHqlcG6SJgXhl9EAzQH3MsFxkyur8gtmD5G9DLGCWG1B8 ffm5JXWmKVHgsr3yM.uRgnaBdNkCbOwfumLj5BNk_B7eCTe1rawZ0fcu2bF8LNCs_qNs1ElRnPvC Y2rYYNvFalHxU0yjue2hd6lGlch47d6doG71mE8k1Yi31W6JxGqd14GbeCfDmqY8AdftcRgR7JSp gBxgzxxlHPo63LLrSLazUgfv76FNXIT5VawLekB0kV6dhugCe_0xuXjTklNd6VViaBlGu6e0UrAo FcLGpfiCkZXq3I4R3J4eDEJ2mfazIE5rv.3oC1AlZNRp75Oo4aQrBavVodTVwTzt5OvhazXbw9AO sA_OhSEHEYWCW95ZbTMCwXzGJuQez9NQ8TsmzZ9Gt_FOUbjreIprh7HuWLPBZrHs4gs4dXma8HNu RsP80l0l3KdfykKMj1i42rL_dZCKfi1yPRvq7vMw7gdVYx3UGMBpqcbjI4AeBTQAC.Zmon.TJVlv D2z1WQ1jZFb1aKyRJyEwE4QWu1BkBlquuhp3ARRXJUw9.xNEwmFBAoDmhE9UTugeKuRC9dOq5hTh hTVF1evrUkTeAl7lZ95wFpFUZOvalHABxxEMabSanT.wfOHEciUqJd_55Ar0PBpHMqg4rFglP5CR PBCVqazTy4ALn8SAauOkuipSy.zLoDjoSCNq7dDN_10xb3y8437W8CV_XZBeKCQCQLEslR_cEJRz Faqr_dHtKQv5ElBvpb_HE6d8jsv4Wdlzk0a1vsw9fKICP_2yq7_Hlz5jwSp1OkIl5SL9JED6t0fO dHObIpoZeeQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Tue, 4 Dec 2018 18:13:18 +0000 Date: Tue, 4 Dec 2018 18:03:01 +0000 (UTC) From: Tomek Stojecki To: Tomek Stojecki , Torsten Lodderstedt Cc: Daniel Fett , Vittorio Bertocci , Brian Campbell , oauth@ietf.org Message-ID: <942315098.1664424.1543946581453@mail.yahoo.com> In-Reply-To: <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1664423_1065979997.1543946581450" X-Mailer: WebService/1.1.12827 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36 Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 04 Dec 2018 18:13:21 -0000 ------=_Part_1664423_1065979997.1543946581450 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Torsten!So if I am putting myself in the shoes of somebody who sets= out to do that - switch an existing SPA client (no backend) from Implicit = to Code, the options to think through can be summed up more or less as foll= owing: 1. Do not use RTs2. If you're using RTs, rotate on every refresh AND implem= ent RT token binding (is that stable enough?). Also consider binding RT to = AS session. Is that fair or is that too much of a shortcut? I am familiar with the spec= s you've referenced and have looked at them again, but dealing with a SPA, = some of the recommendations are not feasible (can't authenticate the client= , confidentiality in storage? - not sure how to read that in the context of= a browser) On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderstedt wrote: =20 =20 Hi Tomek, > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki : >=20 > I agree with Vittorio, Dominick et al.=20 >=20 >> I disagree.=20 >=20 >> Existing deployments that have not mitigated against the concerns with i= mplicit should be ripped up and updated. >=20 > Yes, just like future deployments that will not mitigate against the conc= erns of code in the browser should be a concern. I agree. That=E2=80=99s why I pointed point yesterday that the Security BCP= also defines obligations for clients using code.=20 https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1 https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1= .1 >=20 > Can somebody on the other side of the argument (and I hate to make it sou= nd like there are two sides, because we're on the same side as far as Impli= cit's AT in front-channel is a real issue) address Dominic's comment:=20 >=20 >> Also - simply saying =E2=80=9Cimplicit is evil - switch to code=E2=80=9D= means for most people also using refresh token - so we are treating access= tokens in the URL with refresh tokens in session storage (over simplified = - but you get the idea). >=20 > Does the group agree|disagree that a recommendation to switch to code sho= uld be made as long as it is followed by an explanation and guidance on wha= t to do with RTs? The ideas that were floated around=20 > - Token bound RTs (even though it was pointed out that token binding is s= till considered an emerging standard). So should the recommendation than sa= y "switch to code and MUST use token bound RTs"? > - Have AS not release RTs. "Switch to code and DO NOT request RTs"? Or sw= itch to code and configure AT to not release RTs for this type of client (n= ot sure what that even looks like in a form of a 3rd party clients)? > - RTs short lived and bound to a session - "Switch to code as long as AT = can bind and revoke RTs when you log out=E2=80=9C Basically, the AS does not need to issue refresh tokens. If the AS does not= issue refresh tokens, the integration pattern for SPAs does not change (be= side the code exchange). If the client needs a new access token, it will pe= rform another authorization request.=C2=A0=20 If it does, this adds another layer of security because it allows the clien= t to frequently obtain new access tokens, which can be short-lived and scop= e restricted.=20 The refresh tokens should be replay protected by issuing new refresh tokens= with every refresh and detect replay for refresh tokens belonging to the s= ame grant.=20 The AS may additionally bind refresh tokens to AS sessions, but as it was p= ointed out by Annabelle and others, there are some implications to be under= stood and managed in that context. You may find more text about refresh tokens in the Security BCP https://too= ls.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.12 kind regards, Torsten.=20 >=20 > Sorry if I have missed an important detail from the list above, people wh= o have proposed these ideas, feel free to clarify.=20 >=20 > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt wrote:=20 >=20 > I disagree.=20 >=20 > Existing deployments that have not mitigated against the concerns with im= plicit should be ripped up and updated. >=20 > For example, at one time, I think it was Instagram that had deployed impl= icit because it was easier to do. Once the understood the security implicat= ions, they changed the implementation.=20 >=20 > BCPs are rarely a response to a new threat, their are capturing Best Curr= ent Practices so that they become widely deployed. >=20 >=20 >=20 >=20 > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell wrote: >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are sayin= g here. And that was kind of behind the comment I made, or tired to make, a= bout this in Bangkok, which was (more or less) that I don't think the WG sh= ould be killing implicit outright but rather that it should begin to recomm= end against it.=20 >>=20 >> I'm not exactly sure what that looks like in this document but maybe ton= ing down some of the scarier language a bit, favoring SHOULDs vs. MUSTs, an= d including language that helps a reader understand the recommendations as = being more considerations for new applications/deployments than as a mandat= e to rip up existing ones.=20 >>=20 >>=20 >>=20 >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley wrote: >>>=20 >>> We just need to be sensitive to the spin on this.=C2=A0=20 >>>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privileg= ed material for the sole use of the intended recipient(s). Any review, use,= 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._______________________________________________ >> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 ------=_Part_1664423_1065979997.1543946581450 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Torsten!
So if I am putting myself in the sho= es of somebody who sets out to do that - switch an existing SPA client (no = backend) from Implicit to Code, the options to think through can be summed = up more or less as following:

1. Do not use RTs
2. If you're using RTs, rotate on every refresh AND implement RT to= ken binding (is that stable enough?). Also consider binding RT to AS sessio= n.

Is that fair or is that too much of a shortcut?= I am familiar with the specs you've referenced and have looked at them aga= in, but dealing with a SPA, some of the recommendations are not feasible (c= an't authenticate the client, confidentiality in storage? - not sure how to= read that in the context of a browser)

=20
=20
On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten= Lodderstedt <torsten@lodderstedt.net> wrote:


Hi Tomek,

> Am 04.12.2018 um 09:50 schrieb Tomek Stojecki <tstojecki= =3D40yahoo.com@dmarc.ietf.org>:
>
> I agree with Vittorio, Dominick et al.
>
>> I disagree.
>
>> Existing deployments that have not mit= igated against the concerns with implicit should be ripped up and updated.<= br clear=3D"none">>
> Yes, just like future deploy= ments that will not mitigate against the concerns of code in the browser sh= ould be a concern.

I agree. That=E2=80= =99s why I pointed point yesterday that the Security BCP also defines oblig= ations for clients using code.

https://tools.ietf= .org/html/draft-ietf-oauth-security-topics-10#section-2.1
https= ://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1.1

>
> Can som= ebody on the other side of the argument (and I hate to make it sound like t= here are two sides, because we're on the same side as far as Implicit's AT = in front-channel is a real issue) address Dominic's comment:
>
>> Also - simply saying =E2=80=9Cimplici= t is evil - switch to code=E2=80=9D means for most people also using refres= h token - so we are treating access tokens in the URL with refresh tokens i= n session storage (over simplified - but you get the idea).
>
> Does the group agree|disagree that a recomm= endation to switch to code should be made as long as it is followed by an e= xplanation and guidance on what to do with RTs? The ideas that were floated= around
> - Token bound RTs (even though it was point= ed out that token binding is still considered an emerging standard). So sho= uld the recommendation than say "switch to code and MUST use token bound RT= s"?
> - Have AS not release RTs. "Switch to code and D= O NOT request RTs"? Or switch to code and configure AT to not release RTs f= or this type of client (not sure what that even looks like in a form of a 3= rd party clients)?
> - RTs short lived and bound to a = session - "Switch to code as long as AT can bind and revoke RTs when you lo= g out=E2=80=9C

Basically, the AS does = not need to issue refresh tokens. If the AS does not issue refresh tokens, = the integration pattern for SPAs does not change (beside the code exchange)= . If the client needs a new access token, it will perform another authoriza= tion request. 

If it does, this = adds another layer of security because it allows the client to frequently o= btain new access tokens, which can be short-lived and scope restricted.
The refresh tokens should be replay prot= ected by issuing new refresh tokens with every refresh and detect replay fo= r refresh tokens belonging to the same grant.

The AS may additionally bind refresh tokens to AS sessions, but a= s it was pointed out by Annabelle and others, there are some implications t= o be understood and managed in that context.

You may find more text about refresh tokens in the Security BCP https://tools.i= etf.org/html/draft-ietf-oauth-security-topics-10#section-3.12

kind regards,
Torsten.


>
> Sorry if I have m= issed an important detail from the list above, people who have proposed the= se ideas, feel free to clarify.

> =
> On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dic= k Hardt <dick.hardt@gmail.com> wrote:
>
> I disagree.
> > Existing deployments that have not mitigated against t= he concerns with implicit should be ripped up and updated.
>
> For example, at one time, I think it was Ins= tagram that had deployed implicit because it was easier to do. Once the und= erstood the security implications, they changed the implementation.
>
> BCPs are rarely a response to a ne= w threat, their are capturing Best Current Practices so that they become wi= dely deployed.
>
>
>
>
> On Mon, Dec 3, 2= 018 at 10:41 AM Brian Campbell <bcampbell=3D= 40pingidentity.com@dmarc.ietf.org> wrote:
>>= FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are saying = here. And that was kind of behind the comment I made, or tired to make, abo= ut this in Bangkok, which was (more or less) that I don't think the WG shou= ld be killing implicit outright but rather that it should begin to recommen= d against it.
>>
>> I'm n= ot exactly sure what that looks like in this document but maybe toning down= some of the scarier language a bit, favoring SHOULDs vs. MUSTs, and includ= ing language that helps a reader understand the recommendations as being mo= re considerations for new applications/deployments than as a mandate to rip= up existing ones.
>>
>> =
>>
>> On Mon, Dec 3, 2018= at 8:39 AM John Bradley <ve7jtb@ve7jtb.com> wrote:>>>
>>> We just need = to be sensitive to the spin on this. 
>>> =
>>
>> CONFIDENTIALITY NOT= ICE: This email may contain confidential and privileged material for the so= le use of the intended recipient(s). Any review, use, distribution or discl= osure by others is strictly prohibited...  If you have received this c= ommunication in error, please notify the sender immediately by e-mail and d= elete the message and any file attachments from your computer. Thank you.__= _____________________________________________
>> OA= uth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org= /mailman/listinfo/oauth
>>
&= gt; _______________________________________________
> = OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailm= an/listinfo/oauth
>
> ______= _________________________________________
> OAuth mail= ing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinf= o/oauth
_______________________________________= ________
OAuth mailing list
OA= uth@ietf.org
https://w= ww.ietf.org/mailman/listinfo/oauth
------=_Part_1664423_1065979997.1543946581450-- From nobody Tue Dec 4 10:35:22 2018 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 4DF55130F29 for ; Tue, 4 Dec 2018 10:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, 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 (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 2EFd0_VOLVum for ; Tue, 4 Dec 2018 10:35:18 -0800 (PST) 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 2A5A8130ED9 for ; Tue, 4 Dec 2018 10:35:18 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id r9so7019649ioa.1 for ; Tue, 04 Dec 2018 10:35:18 -0800 (PST) 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; bh=LpsXHEyT84rwRuuZpqYtuPxXlaIbd+mPgGQT88Ps0sc=; b=fq7nIub64vOv2EhdDLV/tcKQmQEK6flzQqeEcS2+BM6jU9PJN1so1jyVjk5HllXXKQ 8VJMSOe3Ey8mjHMvGt06BbHImezSdhtSh8lSC4pItpOUJj0KiHVb/PBFTgxEkiYebBM0 FWHm9GR54t16VQqOmPRxRtTuVSkncy4VVtsloeSvA/k2IW8tU/oM9E53bfZTfCRwT/P4 LJkCnI1EExcN75DMgKiQPd/HlTeSoOS9STQBtpUSDL5Fvo/XN+YQ9Qt/DaNZzfty2WE1 unZSw+SN0WkuKgqPFXlUp0k3AoDEdhJUwqMfXdAle6cJS+3wOG1vvKDvkkG75P8pUWBC gruw== 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=LpsXHEyT84rwRuuZpqYtuPxXlaIbd+mPgGQT88Ps0sc=; b=nVh4cBUuzKqm3bHavdgJyyEpA/2HWYZq4TeGnDeLbOJUVSCjmuFr+uYD5WpwJfE6Mj HjOew9qtrGgZm3EE9fcXAo4O4rh2QnuH2tpMYZhGGBVATgZBkIUlZxLyO6fftb4zPDfJ 2qJbpPYELag7FEEUoEFJszywlN35azSSYxzv/xd7Vm1htbj5ERQcYBEtJlCK8u9JtSQX +5i3jSfdIW/acji//IvFuFL/ZKlHkLpRFN+FekX4K5Ge+CM4giSQ3XsN3bV56N0tXzez 1ttiYfxf+sJBSIcBzpT2+JWcAEMWZaeoXF91zPEGPRoyWnA0siugMFXTJnsFu/UlJFGk lJuw== X-Gm-Message-State: AA+aEWae/CEvUO7WZ/TEdc4eIA4cA5aV00wMC7Ks/pgEbIvdXNDfBq8e sggO9KeR1VSfMBSRg7IE8gzZrJkdWZI= X-Google-Smtp-Source: AFSGD/Xhe5iZXfextCmGdgqeNvWTBzt7mS7R3NuW5e2Bd+OBa1m/h9hrP26XzR+dhBPux4fOxgdpmA== X-Received: by 2002:a6b:5804:: with SMTP id m4mr17407318iob.47.1543948517174; Tue, 04 Dec 2018 10:35:17 -0800 (PST) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com. [209.85.166.48]) by smtp.gmail.com with ESMTPSA id n136sm5682434itb.35.2018.12.04.10.35.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 10:35:17 -0800 (PST) Received: by mail-io1-f48.google.com with SMTP id k7so14465684iob.6 for ; Tue, 04 Dec 2018 10:35:15 -0800 (PST) X-Received: by 2002:a6b:8d8a:: with SMTP id p132mr18998777iod.290.1543948515418; Tue, 04 Dec 2018 10:35:15 -0800 (PST) MIME-Version: 1.0 References: <7a2af167-93db-461a-a2a0-47a2f4782c04@rub.de> In-Reply-To: <7a2af167-93db-461a-a2a0-47a2f4782c04@rub.de> From: Aaron Parecki Date: Tue, 4 Dec 2018 10:34:57 -0800 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Cc: Christian.Mainka=40rub.de@dmarc.ietf.org Content-Type: multipart/alternative; boundary="000000000000d028f3057c36860c" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-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: Tue, 04 Dec 2018 18:35:22 -0000 --000000000000d028f3057c36860c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review, Christian! Responses inline. Changes have been made on my GitHub version, not yet published as a new revision on ietf.org. https://github.com/aaronpk/oauth-browser-based-apps On Tue, Nov 27, 2018 at 1:45 AM Christian Mainka wrote: > Hi Aaron, > > I just reviewed the latest update. Thank you for this very interesting > guideline! > > Here are my thoughts: > > - Section 4: "For authorizing users within a browser-based application" > I would like to know whether this guide is for JavaScript Applications > (such as SPas), for Browser Extensions, or for both? > I believe code running in a browser extension has a similar threat profile as code running in a browser, so this should apply to extensions as well. However I would want to hear from others about whether my understanding of this is correct, as I haven't actually implemented OAuth in a browser extension before. > > - Section 5: "applicaiton" -> "application"; "an web email" -> "a web > email" > Thanks, fixed. > > - Section 6: "and MUST use a unique value for each authorization request.= " > I would prefer: > 'The "state" parameter MUST be a unique value for each authorization > request, which is bound to the end-user's HTTP session, and must be > verified upon receiving it in the authorization response.' > Otherwise, it sounds like a nonce for me. > I'm a little worried about saying anything about HTTP sessions, since some apps use the state to encode the session (e.g. a JWT state value) and don't have any HTTP session associated with it at all, effectively using the state value to restore the session. I'll change it to this: "and MUST use a unique value for each authorization request, and MUST verify the returned state in the authorization response matches the original state the app created." > > - Section 7.3: "If authorization servers restrict redirect URIs to a > fixed set of absolute HTTPS URIs without wildcard domains or paths" > Covert redirect can be used by abusing unprotected GET parameters (which > are technically not the PATH). > So maybe it would be better to say simply "without wildcards" or > "without wildcard domains, paths, or querys"? > Thanks, I've added "query string components" to the list. > > - Section 7.6: "dynamic registration" -> "dynamic client registration" > Fixed. > > Best Regards > Christian > > -- > Dr.-Ing. Christian Mainka > Horst G=C3=B6rtz Institute for IT-Security > Chair for Network and Data Security > Ruhr-University Bochum, Germany > > Universit=C3=A4tsstr. 150, ID 2/463 > D-44801 Bochum, Germany > > Telefon: +49 (0) 234 / 32-26796 > Fax: +49 (0) 234 / 32-14347 > http://nds.rub.de/chair/people/cmainka/ > @CheariX > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000d028f3057c36860c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review, C= hristian! Responses inline. Changes have been made on my GitHub version, no= t yet published as a new revision on ietf.org.=C2=A0ht= tps://github.com/aaronpk/oauth-browser-based-apps

On Tue, Nov 27, 2018 at 1:45 AM Christian Mai= nka <Christian.Mainka=3D40rub= .de@dmarc.ietf.org> wrote:
Hi Aaron,

I just reviewed the latest update. Thank you for this very interesting
guideline!

Here are my thoughts:

- Section 4: "For authorizing users within a browser-based application= "
I would like to know whether this guide is for JavaScript Applications
(such as SPas), for Browser Extensions, or for both?
<= br>
I believe code running in a browser extension has a similar t= hreat profile as code running in a browser, so this should apply to extensi= ons as well. However I would want to hear from others about whether my unde= rstanding of this is correct, as I haven't actually implemented OAuth i= n a browser extension before.
=C2=A0

- Section 5: "applicaiton" -> "application"; "a= n web email" -> "a web email"

Thanks, fixed.
=C2=A0

- Section 6: "and MUST use a unique value for each authorization reque= st."
I would prefer:
'The "state" parameter MUST be a unique value for each author= ization
request, which is bound to the end-user's HTTP session, and must be
verified upon receiving it in the authorization response.'
Otherwise, it sounds like a nonce for me.

I'm a little worried about saying anything about HTTP sessions, sinc= e some apps use the state to encode the session (e.g. a JWT state value) an= d don't have any HTTP session associated with it at all, effectively us= ing the state value to restore the session. I'll change it to this:

"and MUST use a unique value for each authorizat= ion request, and MUST verify the returned state in the authorization respon= se matches the original state the app created."
=C2=A0
=

- Section 7.3: "If authorization servers restrict redirect URIs to a fixed set of absolute HTTPS URIs without wildcard domains or paths" Covert redirect can be used by abusing unprotected GET parameters (which are technically not the PATH).
So maybe it would be better to say simply "without wildcards" or<= br> "without wildcard domains, paths, or querys"?

Thanks, I've added "query string components"= to the list.
=C2=A0

- Section 7.6: "dynamic registration" -> "dynamic client = registration"

Fixed.
=C2= =A0

Best Regards
Christian

--
Dr.-Ing. Christian Mainka
Horst G=C3=B6rtz Institute for IT-Security
Chair for Network and Data Security
Ruhr-University Bochum, Germany

Universit=C3=A4tsstr. 150, ID 2/463
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://nds.rub.de/chair/people/cmainka/
@CheariX

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000d028f3057c36860c-- From nobody Tue Dec 4 10:57:06 2018 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 27281130FA6 for ; Tue, 4 Dec 2018 10:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, 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 (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 HeeKtrj8Arvx for ; Tue, 4 Dec 2018 10:57:02 -0800 (PST) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (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 BC08C128CE4 for ; Tue, 4 Dec 2018 10:57:01 -0800 (PST) Received: by mail-io1-xd41.google.com with SMTP id o5so8547307iop.12 for ; Tue, 04 Dec 2018 10:57:01 -0800 (PST) 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; bh=IlhXn7mOn5lgFmiwVxHeqgBSQI1asmOUxm1StYdhDdY=; b=llexRJBqPAX6tP+BzOptlg8MWtYOszw0fA3pN75FCJA2J8sk+wJV0FWVx/M1IlsGs+ 37VFeVzhWbtwwjYoqYAlQ0AASX5Q8BGcZ9JOA4R5UySTuNIoE5JnczPJLoUMcqNhUomG zOQFCAZb0OUCzFR+PBWjWlUeBHV5T1bYHNho5ybdAhK2SjZT90mJEHUjMVtk4Nit1FdV wwJdigrU9h4egucNpBOZ8m7TA0wsf1Svl9p8jQwNHrAtrnM9YCf/V/SZGr9b0s/k+zWO JsRPIzjTE1qDw2sAfe7eaQXbp+95LnZIy+uNmmMAY9fjNxW152zobsHUk555AfqAEzYA K5Ag== 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=IlhXn7mOn5lgFmiwVxHeqgBSQI1asmOUxm1StYdhDdY=; b=UjVeK+AeuzZKl0cliTDGJHTg41L/2ZRprI53Aa8t8mC9uiFhYQQtJ3DwA/XQlCJ3Ng uPE5DhQ553zWmfZBIwe/rVo3h55m7NyJ82JIjkuwpcP9zClJWnoy+0nRu2kGUdwhEYYG 0Yah2XURuAgZVetNwMkHwOiD5lV8LDjPIrgARiFOwG+ztN2WIJA/NgCeuqSg4Av73tUq MfCCt/obbpRIqUWfWKPXcVXeN85JDuftn98fVNy9TMEBHjKdx0Tc4o642FWyzfYqOaww kQYSYbJ5sXlYFlMDbRjgbt1vB+zvL6EBHkcr+TDuaWeJ2RbVE7Ls+GSh6PD+Jtastsm9 Vpww== X-Gm-Message-State: AA+aEWb9U8F7ul+3pdk/TOZZS8K3yQve3gcpImvFYe8+Xn8mpbUZv1gm MxymaY+nGbgRBfvjMZyDg9eQMDAf3Do= X-Google-Smtp-Source: AFSGD/Xrxu+E2ltmJwAI7p6DcMWhEyI4Aq+8ksEOdsIqh/+Bsms6trt03rpRLhmswqDVtWqpriZiXg== X-Received: by 2002:a6b:310b:: with SMTP id j11mr16564409ioa.141.1543949820879; Tue, 04 Dec 2018 10:57:00 -0800 (PST) Received: from mail-it1-f175.google.com (mail-it1-f175.google.com. [209.85.166.175]) by smtp.gmail.com with ESMTPSA id r139sm8505870ior.53.2018.12.04.10.56.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 10:56:59 -0800 (PST) Received: by mail-it1-f175.google.com with SMTP id c9so16158359itj.1 for ; Tue, 04 Dec 2018 10:56:59 -0800 (PST) X-Received: by 2002:a05:660c:452:: with SMTP id d18mr5683031itl.124.1543949818698; Tue, 04 Dec 2018 10:56:58 -0800 (PST) MIME-Version: 1.0 References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> <7FEF0314-88F2-46C7-A22D-C794CC1BB6A0@lodderstedt.net> In-Reply-To: From: Aaron Parecki Date: Tue, 4 Dec 2018 10:56:40 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Brian Campbell Cc: Torsten Lodderstedt , OAuth WG Content-Type: multipart/alternative; boundary="0000000000007ea300057c36d4b6" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 04 Dec 2018 18:57:06 -0000 --0000000000007ea300057c36d4b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for all the discussion here. I've added the paragraph described to the document in a new "Architectural Considerations" section. Currently in the GitHub source code but not yet published as a new IETF draft, which will be coming shortly. https://github.com/aaronpk/oauth-browser-based-apps ---- Aaron Parecki aaronparecki.com @aaronpk On Mon, Dec 3, 2018 at 9:53 AM Brian Campbell wrote: > I would also like to see something to that effect. I feel that sometimes > because SPAs use APIs, there's an unchallenged assumption that OAuth also > has to be used with the in-browser code accessing those APIs. Even if the > details are out of scope for this document, some text like the below at > least gives a nod to the possibility of different approaches, which may > ultimately be more secure and easier to mange. > https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-00#sec= tion-5.1 > kinda does this too but I'm a +1 for a little something along the lines o= f > what is being discussed recently in this thread. > > > > On Mon, Dec 3, 2018 at 7:57 AM Aaron Parecki wrote: > >> I support adding something to that effect, but would like to make it >> clear that this removes the app from being covered under this BCP. How >> about: >> >> --- >> Implementations MAY consider moving the authorization code exchange and >> handling of access and refresh tokens to a backend component in order to >> avoid the risks inherent in handling access tokens from a purely browser >> based app. In this case, the backend component can be a confidential cli= ent >> and can be secured accordingly. >> >> Security of the connection between code running in the browser and this >> backend component is assumed to utilize browser-level protection >> mechanisms. Details are out of scope of this document. >> --- >> >> >> >> >> On Mon, Dec 3, 2018 at 3:15 AM Torsten Lodderstedt < >> torsten@lodderstedt.net > wrote: >> >>> Interesting. Even on this list people felt to see that moving some logi= c >>> to a backend could solve some of the problems raised. What I want to co= nvey >>> is: the solution to a problem in the OAuth space does not necessarily n= eed >>> to be found on the OAuth protocol level. That=E2=80=99s a best practice= in the same >>> way as some OAuth pattern. >>> >>> What I=E2=80=99m suggesting is a statement in the BCP like >>> >>> =E2=80=94 >>> Implementations MAY consider to move authorization code exchange and >>> handling of access and refresh tokens to a backend component in order t= o >>> fulfill their security goals. >>> >>> Security of the connection between code running in the browser and this >>> backend component is assumed to utilize browser-level protection >>> mechanisms. Details are out of scope of this document. >>> =E2=80=94 >>> >>> > Am 03.12.2018 um 11:19 schrieb John Bradley : >>> > >>> > This is my point. >>> > >>> > From a security perspective we have a server based confidential >>> client.. The fact that it has a angular or other JS UI protected by a >>> cookie seems to not be especially relucent to OAuth. >>> > >>> > Perhaps from the developer point of view they have a JS SPA and the >>> only difference to them is in one case they are including the OAuth cli= ent >>> and in the other they are using a server based proxy. So they see it as= the >>> same. >>> > >>> > Perhaps it is perspective. >>> > >>> > On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki >> > In this type of deployment, as far as OAuth is concerned, isn't the >>> backend web server a confidential client? Is there even anything unique= to >>> this situation as far as OAuth security goes? >>> > >>> > I wouldn't have expected an Angular app that talks to its own server >>> backend that's managing OAuth credentials to fall under the umbrella of >>> this BCP. >>> > >>> > ---- >>> > Aaron Parecki >>> > aaronparecki.com >>> > >>> > >>> > >>> > On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> > the UI is rendered in the frontend, UI control flow is in the >>> frontend.. just a different cut through the web app=E2=80=99s layering >>> > >>> > All Angular apps I have seen so far work that way. And it makes a lot >>> of sense to me. The backend can aggregate and optimize access to the >>> underlying services without the need to fully expose them. >>> > >>> > Am 02.12.2018 um 00:44 schrieb John Bradley : >>> > >>> >> How is that different from a regular server client with a web >>> interface if the backed is doing the API calls to the RS? >>> >> >>> >> >>> >> >>> >> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: >>> >>> I forgot to mention another (architectural) option: split an >>> application into frontend provided by JS in the browser and a backend, >>> which takes care of the business logic and handles tokens and API acces= s. >>> Replay detection at the interface between SPA and backend can utilize >>> standard web techniques (see OWASP). The backend in turn can use mTLS f= or >>> sender constraining. >>> >>> >>> >>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt < >>> torsten@lodderstedt.net>: >>> >>> >>> >>>> IMHO the best mechanism at hand currently to cope with token >>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay >>> detection) and issue short living and privilege restricted access token= s. >>> >>>> >>> >>>> Sender constrained access tokens in SPAs need adoption of token >>> binding or alternative mechanism. mtls could potentially work in >>> deployments with automated cert rollout but browser UX and interplay wi= th >>> fetch needs some work. We potentially must consider to warm up applicat= ion >>> level PoP mechanisms in conjunction with web crypto. Another path to be >>> evaluated could be web auth. >>> >>>> >>> >>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig < >>> Hannes.Tschofenig@arm.com>: >>> >>>> >>> >>>>> I share the concern Brian has, which is also the conclusion I cam= e >>> up with in my other email sent a few minutes ago. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> From: OAuth On Behalf Of Brian Campbell >>> >>>>> Sent: Friday, November 30, 2018 11:43 PM >>> >>>>> To: Torsten Lodderstedt >>> >>>>> Cc: oauth >>> >>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>>>> >>> >>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen >> >: >>> >>>>> > >>> >>>>> > So you mean at the resource server ensuring the token was reall= y >>> issued to the client? Isn't that an inherent limitation of all bearer >>> tokens (modulo HTTP token binding, which is still some time off)? >>> >>>>> >>> >>>>> Sure. That=E2=80=99s why the Security BCP recommends use of TLS-b= ased >>> methods for sender constraining access tokens ( >>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section= -2..2). >>> Token Binding for OAuth ( >>> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well >>> as Mutual TLS for OAuth ( >>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options >>> available. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> Unfortunately even when using the token endpoint, for SPA / >>> in-browser client applications, the potential mechanisms for >>> sender/key-constraining access tokens don't work very well or maybe don= 't >>> work at all. So I don't know that the recommendation is very realistic. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> 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 prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you. >>> >>>>> >>> >>>>> IMPORTANT NOTICE: The contents of this email and any attachments >>> are confidential and may also be privileged. If you are not the intende= d >>> 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 = the >>> information in any medium. Thank you. >>> >>>> _______________________________________________ >>> >>>> 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 >>> >>> -- >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* --0000000000007ea300057c36d4b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for all the discussion here. I'= ;ve added the paragraph described to the document in a new "Architectu= ral Considerations" section. Currently in the GitHub source code but n= ot yet published as a new IETF draft, which will be coming shortly.=C2=A0https://githu= b.com/aaronpk/oauth-browser-based-apps

On Mon, Dec 3, 2018 at 9:53 AM Brian= Campbell <bcampbell@pingi= dentity.com> wrote:
I would also like to see something to that e= ffect. I feel that sometimes because SPAs use APIs, there's an unchalle= nged assumption that OAuth also has to be used with the in-browser code acc= essing those APIs. Even if the details are out of scope for this document, = some text like the below at least gives a nod to the possibility of differe= nt approaches, which may ultimately be more secure and easier to mange. https://tools.ietf.org/html/draft-parecki= -oauth-browser-based-apps-00#section-5.1 kinda does this too but I'= m a +1 for a little something along the lines of what is being discussed re= cently in this thread.



On Mon, Dec 3, 2018 at 7:57 AM Aaron Pa= recki <aaron@pare= cki.com> wrote:
I support adding something to that effect, bu= t would like to make it clear that this removes the app from being covered = under this BCP. How about:

---
Implementations MAY consider moving th= e authorization code exchange and handling of access and refresh tokens to = a backend component in order to avoid the risks inherent in handling access= tokens from a purely browser based app. In this case, the backend componen= t can be a confidential client and can be secured accordingly.

Secur= ity of the connection between code running in the browser and this backend = component is assumed to utilize browser-level protection mechanisms. Detail= s are out of scope of this document.=C2=A0
---




On Mon, D= ec 3, 2018 at 3:15 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
=
Interesting. Even o= n this list people felt to see that moving some logic to a backend could so= lve some of the problems raised. What I want to convey is: the solution to = a problem in the OAuth space does not necessarily need to be found on the O= Auth protocol level. That=E2=80=99s a best practice in the same way as some= OAuth pattern.

What I=E2=80=99m suggesting is a statement in the BCP like

=E2=80=94
Implementations MAY consider to move authorization code exchange and handli= ng of access and refresh tokens to a backend component in order to fulfill = their security goals.

Security of the connection between code running in the browser and this bac= kend component is assumed to utilize browser-level protection mechanisms. D= etails are out of scope of this document.
=E2=80=94

> Am 03.12.2018 um 11:19 schrieb John Bradley <ve7jtb@ve7jtb.com>:
>
> This is my point.=C2=A0
>
> From a security perspective we have a server based confidential client= ..=C2=A0 =C2=A0The fact that it has a angular or other JS UI protected by a= cookie seems to not be especially relucent to OAuth.=C2=A0
>
> Perhaps from the developer point of view they have a JS SPA and the on= ly difference to them is in one case they are including the OAuth client an= d in the other they are using a server based proxy. So they see it as the s= ame.
>
> Perhaps it is perspective.
>
> On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki <aaron@parecki.com wrote:
> In this type of deployment, as far as OAuth is concerned, isn't th= e backend web server a confidential client? Is there even anything unique t= o this situation as far as OAuth security goes?
>
> I wouldn't have expected an Angular app that talks to its own serv= er backend that's managing OAuth credentials to fall under the umbrella= of this BCP.
>
> ----
> Aaron Parecki
> aaronparecki.com
>
>
>
> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt <torsten@lodderstedt.net&= gt; wrote:
> the UI is rendered in the frontend, UI control flow is in the frontend= .. just a different cut through the web app=E2=80=99s layering
>
> All Angular apps I have seen so far work that way. And it makes a lot = of sense to me. The backend can aggregate and optimize access to the underl= ying services without the need to fully expose them.
>
> Am 02.12.2018 um 00:44 schrieb John Bradley <ve7jtb@ve7jtb.com>:
>
>> How is that different from a regular server client with a web inte= rface if the backed is doing the API calls to the RS?
>>
>>
>>
>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>> I forgot to mention another (architectural) option: split an a= pplication into frontend provided by JS in the browser and a backend, which= takes care of the business logic and handles tokens and API access. Replay= detection at the interface between SPA and backend can utilize standard we= b techniques (see OWASP). The backend in turn can use mTLS for sender const= raining.
>>>
>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <torsten@lodderstedt.n= et>:
>>>
>>>> IMHO the best mechanism at hand currently to cope with tok= en leakage/replay in SPAs is to use refresh tokens (rotating w/ replay dete= ction) and issue short living and privilege restricted access tokens.
>>>>
>>>> Sender constrained access tokens in SPAs need adoption of = token binding or alternative mechanism. mtls could potentially work in depl= oyments with automated cert rollout but browser UX and interplay with fetch= needs some work. We potentially must consider to warm up application level= PoP mechanisms in conjunction with web crypto. Another path to be evaluate= d could be web auth.
>>>>
>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <Hannes.Tschofenig= @arm.com>:
>>>>
>>>>> I share the concern Brian has, which is also the concl= usion I came up with in my other email sent a few minutes ago.
>>>>>
>>>>>=C2=A0
>>>>>
>>>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Cam= pbell
>>>>> Sent: Friday, November 30, 2018 11:43 PM
>>>>> To: Torsten Lodderstedt <torsten@lodderstedt.net>
>>>>> Cc: oauth <oauth@ietf.org>
>>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-ba= sed-apps-00
>>>>>
>>>>>=C2=A0
>>>>>
>>>>>=C2=A0
>>>>>
>>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt &l= t;torsten@lodd= erstedt.net> wrote:
>>>>>
>>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.co= m>:
>>>>> >
>>>>> > So you mean at the resource server ensuring the t= oken was really issued to the client? Isn't that an inherent limitation= of all bearer tokens (modulo HTTP token binding, which is still some time = off)?
>>>>>
>>>>> Sure. That=E2=80=99s why the Security BCP recommends u= se of TLS-based methods for sender constraining access tokens (https://tools.ietf.org/html/draft-ie= tf-oauth-security-topics-09#section-2..2). Token Binding for OAuth (https://tools.ietf.org/html/draft-ietf-oa= uth-token-binding-08) as well as Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are t= he options available.
>>>>>
>>>>>=C2=A0
>>>>>
>>>>> Unfortunately even when using the token endpoint, for = SPA / in-browser client applications, the potential mechanisms for sender/k= ey-constraining access tokens don't work very well or maybe don't w= ork at all. So I don't know that the recommendation is very realistic.<= br> >>>>>
>>>>>=C2=A0
>>>>>
>>>>>
>>>>> CONFIDENTIALITY NOTICE: This email may contain confide= ntial and privileged material for the sole use of the intended recipient(s)= .. Any review, use, distribution or disclosure by others is strictly prohib= ited..=C2=A0 If you have received this communication in error, please notif= y the sender immediately by e-mail and delete the message and any file atta= chments from your computer. Thank you.
>>>>>
>>>>> IMPORTANT NOTICE: The contents of this email and any a= ttachments are confidential and may also be privileged. If you are not the = intended recipient, please notify the sender immediately and do not disclos= e the contents to any other person, use it for any purpose, or store or cop= y the information in any medium. Thank you.
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oa= uth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>>
>>> OAuth@ietf= ..org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> > _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

--
----
Aaron= Parecki

_______________________________________________
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.
--0000000000007ea300057c36d4b6-- From nobody Tue Dec 4 13:55:15 2018 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 79F95130E51 for ; Tue, 4 Dec 2018 13:55:13 -0800 (PST) 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_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 hGq5B8phLfMT for ; Tue, 4 Dec 2018 13:55:09 -0800 (PST) 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 121B3130DDC for ; Tue, 4 Dec 2018 13:55:04 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id x6so14933264ioa.9 for ; Tue, 04 Dec 2018 13:55:03 -0800 (PST) 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=QSrQIrNbnk+jsm1Fl1iliYBpXNsnwcDTyL19O8F2PuI=; b=FHVMvsElnzNHJ1VCAeTt74nluCYjDPwIibMV8pnTe0xMG2cJ6LMGGmGvkGWgrJKJFz l/yvIWwnfDTzjbQdUB4QMHWtmpJKe1FTGG5dcYwORoURZejcjoM6c2mXhe3sIGUxia7f 1xg8gVdZitRBHsI+/TPtJOjw2OIzfM+DFq/5I= 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=QSrQIrNbnk+jsm1Fl1iliYBpXNsnwcDTyL19O8F2PuI=; b=J8rXXHLOUtV570P3f6/wMrOwcv1Or2e8BPNw82LuVV7lK3clK+qoilBMmdcaSAlG/l Yc8RWvTNg02Mrx/TP+/7jPGag105hrYczp6Yvi8Rolf35e0F1dUtVNAmzl+Sp6w3E/Bl Pn2BX2eWGy1edBBd1JrRfum/LMHe/HaAK5vOB+cxrCcck7NuKECvEpQHORPjZt5Q5t3n fBk5NMspJXuj0AmhJ6RMRAG7H847tzF0FZqPxvCqtMuEl4+nrLxunbaVsJjH6qRWLuLW t+4guhbW4xrhhBzKJGnm7dsYCfJFb7xe+scqceXAam2SOsqHFneF2G0o0Jq0GrVvLUs2 ytEg== X-Gm-Message-State: AA+aEWbl9hLpQBNaFt/uiqOmp9ZS7G9Mh70lAmhRqDXiNq61RvP4VCbj CuZL+DH1F9B7yZ1hc8c+u5EEEc9gW79idFUbXYmBUMAMZkV68GuhKDTNnkIMvg3saKkfINC9Qxs NSppPwgnZw5oYTA== X-Google-Smtp-Source: AFSGD/Vd3p4vjtt6b27pM/eibTIQn/P9oAFpR+VkXEw4DdehhdN7y0B+7fw9i2S+23mgF9OuNxu69fsmVscYCjeE09k= X-Received: by 2002:a6b:6e17:: with SMTP id d23mr8065861ioh.138.1543960503009; Tue, 04 Dec 2018 13:55:03 -0800 (PST) MIME-Version: 1.0 References: <154280782366.11474.16509452820433630629.idtracker@ietfa.amsl.com> In-Reply-To: <154280782366.11474.16509452820433630629.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Tue, 4 Dec 2018 14:54:36 -0700 Message-ID: To: Benjamin Kaduk Cc: The IESG , oauth , draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000054677c057c395110" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-token-exchange-16: (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: Tue, 04 Dec 2018 21:55:14 -0000 --00000000000054677c057c395110 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I apologize for the slow response, Ben. I was on vacation with my family around the Thanksgiving holiday when the ballot position came in. And even on returning and starting to work on it, there's an awful lot here to get through and this kind of thing is very time consuming for me. But thank you for the review - I've attempted to reply, as best I can, to your comments/questions inline below. On Wed, Nov 21, 2018 at 6:43 AM Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-oauth-token-exchange-16: Discuss > > 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-token-exchange/ > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > It looks like allocations in the OAuth URIs registry are merely > "Specification Required", so we should not have the expectation of WG > exclusivity and thus are squatting on unallocated values here. > Process-wise, that's not great and the IESG shouldn't approve a document > that is squatting on codepoints. > In retrospect, RFC 6755 should have used "RFC Required" for the OAuth URIs registry. But that was 2012 and 6755 was my first RFC and I was even more clueless back then than I am now. And what's done is done. In practice the only entries that have been made to the registry have been from RFCs and the only prospective entries (that I'm aware of anyway) are in documents that are on track to be RFCs. This document has followed the same procedures with respect to the OAuth URIs registrations as those other documents. Having said all that, I'm unsure what action you are expecting to see as a result of this DISCUSS comment? > why do we allow both client authentication (i.e., using an > actor token) and a distinct actor_token request parameter? Is it > supposed to be the case that the actor_token parameter is only supplied > for delegation flows? If so, that needs to be made explicit in the > document. > Client authentication is inherited from RFC 6749. It's optional but can be useful for deployments that want to "lock down" who can invoke token exchange. The actor_token and subject_token are inputs into the exchange. They have to be validated but that is not exactly authentication per se. Honestly, I struggle with the wording and how to describe it all (here and in not dissimilar contexts of the authorization grants of RFC 7522 and 7523 ). I've done the best I can in the document. If you can propose some text that you think would make things more clear or explicit, that'd help progress this. But I honestly don't know what to add or change here. > > Are the privacy considerations (e.g., risk of a tailed per-request > error_uri) relating to the use of error_uri discussed in some other > document that we can refer to from this document's security > considerations? (I say a bit more about this in my COMMENT.) > I am not aware of any document with such considerations and I've searched the likely suspects of RFC 6749 and RFC 6819 but don't find anything. The error_uri token endpoint response parameter was defined in the original OAuth 2.0 framework document (RFC 6749) and any considerations around it are applicable to considerably more than this document. It's also very rarely used in practice as far as I know. I don't think that this document, which is a narrow extension of a whole framework with a series of other documents that use error_uri, is the appropriate place to add privacy or security considerations about error_uri. Perhaps https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ would be more appropriate in scope and content? I could remove the one mention of error_uri in this document? It's usage would still be possible/valid by virtue of this document being an extension of RFC 6749 but, out of sight and out of mind, and this doc wouldn't then encourage new usage of it anyway. While usage isn't really happening anyway= . > > Section 2.1 has: > audience > OPTIONAL. The logical name of the target service where the client > intends to use the requested security token. This serves a > purpose similar to the "resource" parameter, but with the client > providing a logical name rather than a location. Interpretation > of the name requires that the value be something that both the > client and the authorization server understand. An OAuth client > identifier, a SAML entity identifier [OASIS.saml-core-2.0-os], an > OpenID Connect Issuer Identifier [OpenID.Core], or a URI are > examples of things that might be used as "audience" parameter > values. [...] > > How does the STS know what type of identifier it is supposed > to interpret the provided audience value as? > The STS will have policy and configuration for the target entities for which it supports the issuance of tokens to in this flow, even if/when those entities are different types of things. The STS will have to search that set of things to find the right one for the given name. In theory I suppose there's potential ambiguity or even name collision. But in practice (as it is the STS that ultimately decides the names it supports and can service) I don't believe there is an actual issue. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The document could perhaps benefit from greater clarity as to whether > "security token"s refer to inputs, outputs, or both, of the token > endpoint (for the interactions defined in this specification). > I have been aware of the potential need here and endeavored to be clear about it throughout the document without being overly repetitive or wordy. I will take another pass through the text and look for opportunities to further clarity. But if there are specific points in the doc that you believe need attention, please point them out so I can be sure they get addressed. > > Section 1 > > The OAuth > 2.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Tokens > [RFC6750] have emerged as popular standards for authorizing third- > party applications access to HTTP and RESTful resources. [...] > > nit: possessive "applications'" > Will fix. > > Section 1.1 > > This section really jumps in quickly with no lead-in to why we would > care or transition from the introduction. I suggest: > > One common use case for an STS (as alluded to in the previous section) > is to allow a resource server A to make calls to a backend service C on > behalf of the requesting user B. Depending on the local site policy an= d > authorization infrastructure, it may be desireable for A to use its own > credentials to access C along with an annotation of some form that A is > acting on behalf of B ("delegation"), or for A to be granted a limited > access > credential to C but that continues to identify B as the authorized > entity ("imperesonation"). Delegation and impersonation can be useful > concepts in other scenarios involving multiple participants as well. > Documents written over time with more than one author sometimes bear the scars of that process in disjoint transitions, which is the case here I think. You're suggestion nicely takes the edge off the transition and provides context for it. Thanks, I'll add that text to the top of sec 1.1. > Section 2.1 > > For example, [RFC7523] > defines client authentication using JSON Web Tokens (JWTs) [JWT]. > > Please clarify that these are still bearer tokens. > Okay. > > The supported methods of client authentication and whether or not to > allow unauthenticated or unidentified clients are deployment > decisions that are at the discretion of the authorization server. > > It seems appropriate to note that omitting client authentication allows > for a compromised token to be leveraged via an STS into other tokens by > anyone possessing the compromised token, and thus that client > authentication allows for additional authorization checks as to which > entities are permitted to impersonate or receive delegations from other > entities. > I'll add a note that says as much (borrowing heavily from your words, thanks). > > The client makes a token exchange request to the token endpoint with > an extension grant type by including the following parameters using > the "application/x-www-form-urlencoded" format with a character > encoding of UTF-8 in the HTTP request entity-body: > > Is there more to say than "just use UTF-8"; any normalization or > canonicalization issues to consider? > Nope, no normalization or canonicalization at this layer. Note that Adam Roach did raise a DISCUSS around citation for the media type https://mailarchive.ietf.org/arch/msg/oauth/Q1K-T2VS3wrHW7lx2EiP58b_DYw , which might result in a change to the wording here but it's still x-www-form-urlencoded with UTF-8 as is better described in https://tools.ietf.org/html/rfc6749#appendix-B > > subject_token > REQUIRED. A security token that represents the identity of the > party on behalf of whom the request is being made. Typically, the > subject of this token will be the subject of the security token > issued in response to this request. > > nit: I think there's a subtle grammar mismatch here, where we start off > by talking about a/the request and end up with "this request". > So changing that last "this request" to say "the request" would fix the mismatch? > In processing the request, the authorization sever MUST validate the > subject token as appropriate for the indicated token type and, if the > actor token is present, also validate it according to its token type. > > I misread this the first time around; I'd suggest something like > "perform the appropriate validation procedures for the indicated token > type" (as opposed to just verifying that the presented token is a > syntactically valid instance of the claimed type). > Makes sense, I'll update accordingly. > > In the absence of one-time-use or other semantics specific to the > token type, the act of performing a token exchange has no impact on > the validity of the subject token or actor token. Furthermore, the > validity of the subject token or actor token have no impact on the > validity of the issued token after the exchange has occurred. > > Do we really want this strong of a statement? I suspect that in many > environments propagating, e.g., expiration time to the exchanged > credential may be desired. > The statement was not in any way intended to prohibit propagating expiration time (or other criteria) to the exchanged credential. The statement was added, best I can recall, in response to a question that came up in a WG chair review asking if the input token(s) would somehow become invalid once used as input to the exchange. Or if some later expiration or other invalidation of the input token(s) would somehow invalidate the new token. The point of the statement in the doc was to try and say that there is no inherit linkage effectual relationship between the tokens outside the exchange event. There could be but that's not a general property of the STS protocol a would be specific to a particular token type or deployment. Does that make any more sense? Do you think the wording could/should be adjusted? > > Section 2.2.1 > > token_type > [...] > contents of the token itself. Note that the meaning of this > parameter is different from the meaning of the "issued_token_type" > parameter, which declares the representation of the issued > security token; the term "token type" is typically used with this > meaning, as it is in all "*_token_type" parameters in this > specification. [...] > > Please disambiguate what "typically used with this meaning" means. > Perhaps it would be even more clear to change this field's name to > "token_access_token_type" to match the name of the registry? > The "token_type" parameter is defined in RFC 6749 for a successful response from the token endpoint so this document effectively inherits it. The name is already defined in RFC 6749 and not in scope for this document to change. I will update the wording to disambiguate "this meaning" per your request. > Section 2.3 > > The following example demonstrates a hypothetical token exchange in > which an OAuth resource server assumes the role of the client during > token exchange in order to trade an access token that it received in > a protected resource request for a token that it will use to call to > a backend service (extra line breaks and indentation in the examples > are for display purposes only). > > We could maybe add some commas or parentheses to help the reader group > the various clauses properly. E.g., it is "(trade an access token (that > it received in a protected resource request)) for a token...", not > "trace an access token that it received (in a protected resource request > for a token)", where parentheses indicate logical grouping. > Will try and do some grouping. > > grant_type=3Durn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchang= e > &resource=3Dhttps%3A%2F%2Fbackend.example.com%2Fapi%20 > &subject_token=3DaccVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC > &subject_token_type=3D > urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token > > Figure 2: Token Exchange Request > Is there really supposed to be a %20 in the resource query parameter's > value? > Nope. Nice catch. Thank you. I'll remove it. > > The token octets in Figures 3 and 4 do not match up, despite the prose > indicating that they are the same token. > Indeed they don't. Look like I missed one token example when updating claim names. I'll fix that. Thanks for catching that one. > > Section 3 > > Would it be appropriate to note (here or elsewhere) that for non-JWT > token formats that are a binary format, the URI used for conveying them > needs to be associated with the semantics of base64 (or otherwise) > encoding them for usage with OAuth? > My thinking had been that it'd be more or less self-evident to the very small group and type of people who would ever undertake such a thing. But a brief note to that effect couldn't hurt. I'll add something as such. > > Token Exchange can work > with both tokens issued by other parties and tokens from the given > authorization server. [...] > > Does "work with" mean "accept as input" or "produce as output" or both? > For input, as both subject_token and actor_token? > Both and yes. The following token type identifiers are defined by this > specification. Other URIs MAY be used to indicate other token types. > I'd also link to the registry here. > The aforementioned other URIs may well be in different namespace so won't ever be in the registry. And that registry also has entries for things other than token types. So I don't think a link to it here would be particularly helpful or even appropriate necessarily. > > Why is the text about "urn:ietf:params:oauth:token-type:jwt" formatted > differently than the other URIs listed? > The list of the ones defined in this doc is a list with each URI in the list appearing in a while th= e :jwt URI is defined elsewhere in RFC 7519 but relevant enough to warrant mention in this doc and it is enclosed in a tag. I feel like I've seen this style of treatment of literal values with list items and in paragraph text in other documents so considered it "normal". Is there a better or more recommended way of doing this kind of thing? > Section 4.1 > > Do we want to consider a more self-describing subject identifier scheme, > akin to > https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers ? > There's nothing precluding the use of such a scheme (well, except that doc doesn't actually define a claim so some claim is needed) but the scope of this document isn't to be that prescriptive in subject identification. > > The example in Figure 5 appears to be using the "implicit issuer" > behavior wherein the "iss" of the actor's "sub" is assumed to be the > same value as in the containing structure. I'm not a fan of this type > of behavior in general, but if it's going to be used, you need to > document the possibility in some fashion. > I'm not a hug fan myself but that's what OpenID Connect did and so it often rears its head. I've tried to make examples that will be meaningful to readers and also somewhat likely to be realistic. In this section it does say: "For example, the combination of the two claims "iss" and "sub" might be necessary to uniquely identify an actor" And sub in RFC 7519 says: "The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique." > > I might also consider some language about how "the nested "act" claims > serve as a history trail that connects the initial request and subject > through the various delegation steps undertaken before reaching the > current actor. In this sense, the current actor is considered to > include the entire authorization/delegation history, leading naturally > to the nested structure described here". (But see also the other ballot > comment about this potentially leaking information to unauthorized > parties; it seems a more careful adjustment of the text is in order > here.) > Okay, I can add something to that effect. > Section 4.2 > > Is this really the first time we're defining "scope" as a JWT claim? I > would have thought that would be defined long ago... > Some things haven't historically happened in OAuth the way one might very reasonably have expected. And this is one such thing. > > Section 4.4 > > Just to double-check: this is "things that can act as me" (where "me" is > the subject of the token containing this field), right? Yes. Honestly, I have a hard time seeing this claim actually being used in practice. But maybe I'm wrong. And I'm just the editor on this one. But yes, that's the intended meaning. The > parenthetical "May Act For" doesn't really help me decide whether this > claim represents the source or target of a permitted delegation, so > maybe "Allowed Impersonators" or similar would be more clear. Even "act > as" or "act on behalf of" instead of "act for" would help me, I think. > [This would have trickle-down effects to later parts of the document as > well, e.g., the IANA Considerations.] > (Not that I claim to be a representative population, of course!) > On looking at it again, I agree "May Act For" isn't a particularly good name nor is it helpful in understanding it. I admit to having a hard time with the language here. But, yeah, "May Act For" isn't very good. What about "Authorized Actor" in the parenthetical and "Authorized Actor - the party that is authorized to become the actor" for the Claim Description in registration? > It would probably also help greatly to note that when a subject_token is > presented to the token endpoint in a token exchange request, the > "may_act" claim in the subject token can be used by the authorization > service to determine whether the client (or party identified in the > actor_token) is authorized to engage in the requested delegation [or > impersonation]. > Okay, I can add something to that effect. > > Section 6 > > Let me say a bit more here about my perception of the potential privacy > considerations involved in the use of an error_uri (so we can figure out > if they are already discussed in a relevant document that we can cite; > JWT itself doesn't seem to cover this topic). By sending an error_uri > instead of an error string, the server is in effect causing the client > to make an outbound request to a URL of the server's choosing. If there > is a proxy between the client and server, this could result in the > server (and/or a party controlled by the server) learning additional > information about the client's identity/location. A malicious server > could also attempt to construct a URI that, when retrieved by the > client, performs some unwanted side effect. Defenses against this > latter scenario are pretty well known in the web comunity, but we may > want to be sure that the need for them is mentioned in a discoverable > place. > Thank you for the further explanation. As I wrote earlier, however, the error_uri response parameter was originally defined in RFC 6749 and any privacy or security considerations for it are applicable to considerably more than this document. > Appendix A.1.1 > > In the following token exchange request, a client is requesting a > token with impersonation semantics. [...] > > What part of the request indicates that impersonation semantics are > requested? > I guess it's not explicitly requesting impersonation semantics per se but only a subject_token is being supplied in the request so impersonation is kinda implied as there is no party identified that could be delegated to. Do you think the wording should be qualified as such or otherwise adjusted? > > Is the use of the "jwt" subject_token_type appropriate, given the > previous discussion about id_token/access_token being generally > preferred (as conveying more meaning)? > The issuer of that token isn't the given AS so it isn't an access_token. And it doesn't have all the claims required to be an id_token. That leaves JWT. And JWT is used a lot in the examples so their claims can also be seen and an "identity" can be traced through the exchange. --=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._ --00000000000054677c057c395110 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">
I apologize for the slow response, Ben. I was on = vacation with my family around the Thanksgiving holiday when the ballot pos= ition came in. And even on returning and starting to work on it, there'= s an awful lot here to get through and this kind of thing is very time cons= uming for me. But thank you for the review - I've attempted to reply, a= s best I can, to your comments/questions inline below.

On Wed, Nov 2= 1, 2018 at 6:43 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
Benjamin Kaduk has entered the following ballot = position for
draft-ietf-oauth-token-exchange-16: Discuss

Please refer to https://www.ietf.org/iesg/s= tatement/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/dr= aft-ietf-oauth-token-exchange/

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

It looks like allocations in the OAuth URIs registry are merely
"Specification Required", so we should not have the expectation o= f WG
exclusivity and thus are squatting on unallocated values here.
Process-wise, that's not great and the IESG shouldn't approve a doc= ument
that is squatting on codepoints.

In ret= rospect, = RFC 6755 should have used "RFC Required" for the OAuth URIs r= egistry. But that was 2012 and 6755 was my first RFC and I was even more cl= ueless back then than I am now. And what's done is done.
=
In practice the only entries that have been made to the regi= stry have been from RFCs and the only prospective entries (that I'm awa= re of anyway) are in documents that are on track to be RFCs. This document = has followed the same procedures with respect to the OAuth URIs registratio= ns as those other documents.

Having said all = that, I'm unsure what action you are expecting to see as a result of th= is DISCUSS comment?



why do we allow both client authentication (i.e., using an
actor token) and a distinct actor_token request parameter?=C2=A0 Is it
supposed to be the case that the actor_token parameter is only supplied
for delegation flows?=C2=A0 If so, that needs to be made explicit in the document.

Client authentication is inhe= rited from RFC 6749. It's optional but can be useful for deployments th= at want to "lock down" who can invoke token exchange.
<= div>
The actor_token and subject_token are inputs into the ex= change. They have to be validated but that is not exactly authentication pe= r se. Honestly, I struggle with the wording and how to describe it all (her= e and in not dissimilar contexts of the authorization grants of RFC 7522 and 7523). I= 've done the best I can in the document. If you can propose some text t= hat you think would make things more clear or explicit, that'd help pro= gress this. But I honestly don't know what to add or change here.
=

=C2=A0

Are the privacy considerations (e.g., risk of a tailed per-request
error_uri) relating to the use of error_uri discussed in some other
document that we can refer to from this document's security
considerations?=C2=A0 (I say a bit more about this in my COMMENT.)

I am not aware of any document with such consid= erations and I've searched the likely suspects of RFC 6749 and RFC 6819= but don't find anything.

The error_uri t= oken endpoint response parameter was defined in the original OAuth 2.0 fram= ework document (RFC 6749) and any considerations around it are applicable t= o considerably more than this document. It's also very rarely used in p= ractice as far as I know. I don't think that this document, which is a = narrow extension of a whole framework with a series of other documents that= use error_uri, is the appropriate place to add privacy or security conside= rations about error_uri.=C2=A0 Perhaps https://datatr= acker.ietf.org/doc/draft-ietf-oauth-security-topics/ would be more appr= opriate in scope and content?

I could remove = the one mention of error_uri in this document? It's usage would still b= e possible/valid by virtue of this document being an extension of RFC 6749 = but, out of sight and out of mind, and this doc wouldn't then encourage= new usage of it anyway. While usage isn't really happening anyway.
=

=C2=A0

Section 2.1 has:
=C2=A0 =C2=A0audience
=C2=A0 =C2=A0 =C2=A0 OPTIONAL.=C2=A0 The logical name of the target service= where the client
=C2=A0 =C2=A0 =C2=A0 intends to use the requested security token.=C2=A0 Thi= s serves a
=C2=A0 =C2=A0 =C2=A0 purpose similar to the "resource" parameter,= but with the client
=C2=A0 =C2=A0 =C2=A0 providing a logical name rather than a location.=C2=A0= Interpretation
=C2=A0 =C2=A0 =C2=A0 of the name requires that the value be something that = both the
=C2=A0 =C2=A0 =C2=A0 client and the authorization server understand.=C2=A0 = An OAuth client
=C2=A0 =C2=A0 =C2=A0 identifier, a SAML entity identifier [OASIS.saml-core-= 2.0-os], an
=C2=A0 =C2=A0 =C2=A0 OpenID Connect Issuer Identifier [OpenID.Core], or a U= RI are
=C2=A0 =C2=A0 =C2=A0 examples of things that might be used as "audienc= e" parameter
=C2=A0 =C2=A0 =C2=A0 values.=C2=A0 [...]

How does the STS know what type of identifier it is supposed
to interpret the provided audience value as?

The STS will have policy and configuration for the target entities fo= r which it supports the issuance of tokens to in this flow, even if/when th= ose entities are different types of things. The STS will have to search tha= t set of things to find the right one for the given name. In theory I suppo= se there's potential ambiguity or even name collision. But in practice = (as it is the STS that ultimately decides the names it supports and can ser= vice) I don't believe there is an actual issue.
=C2=A0
=C2=A0

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

The document could perhaps benefit from greater clarity as to whether
"security token"s refer to inputs, outputs, or both, of the token=
endpoint (for the interactions defined in this specification).

I have been aware of the potential need here and en= deavored to be clear about it throughout the document without being overly = repetitive or wordy. I will take another pass through the text and look for= opportunities to further clarity. But if there are specific points in the = doc that you believe need attention, please point them out so I can be sure= they get addressed.
=C2=A0

Section 1

=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 OAuth =C2=A0 =C2=A02.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Tok= ens
=C2=A0 =C2=A0[RFC6750] have emerged as popular standards for authorizing th= ird-
=C2=A0 =C2=A0party applications access to HTTP and RESTful resources.=C2=A0= [...]

nit: possessive "applications'"

Will fix.
=C2=A0

Section 1.1

This section really jumps in quickly with no lead-in to why we would
care or transition from the introduction.=C2=A0 I suggest:

=C2=A0 One common use case for an STS (as alluded to in the previous sectio= n)
=C2=A0 is to allow a resource server A to make calls to a backend service C= on
=C2=A0 behalf of the requesting user B.=C2=A0 Depending on the local site p= olicy and
=C2=A0 authorization infrastructure, it may be desireable for A to use its = own
=C2=A0 credentials to access C along with an annotation of some form that A= is
=C2=A0 acting on behalf of B ("delegation"), or for A to be grant= ed a limited access
=C2=A0 credential to C but that continues to identify B as the authorized =C2=A0 entity ("imperesonation").=C2=A0 Delegation and impersonat= ion can be useful
=C2=A0 concepts in other scenarios involving multiple participants as well.=

Documents written over time with more = than one author sometimes bear the scars of that process in disjoint transi= tions, which is the case here I think.

You're = suggestion nicely takes the edge off the transition and provides context fo= r it. Thanks, I'll add that text to the top of sec 1.1.
=
=C2=A0

=C2=A0 =C2=A0The supported methods of client authentication and whether or = not to
=C2=A0 =C2=A0allow unauthenticated or unidentified clients are deployment =C2=A0 =C2=A0decisions that are at the discretion of the authorization serv= er.

It seems appropriate to note that omitting client authentication allows
for a compromised token to be leveraged via an STS into other tokens by
anyone possessing the compromised token, and thus that client
authentication allows for additional authorization checks as to which
entities are permitted to impersonate or receive delegations from other
entities.

I'll add a note that says= as much (borrowing heavily from your words, thanks).
=C2=A0=

=C2=A0 =C2=A0The client makes a token exchange request to the token endpoin= t with
=C2=A0 =C2=A0an extension grant type by including the following parameters = using
=C2=A0 =C2=A0the "application/x-www-form-urlencoded" format with = a character
=C2=A0 =C2=A0encoding of UTF-8 in the HTTP request entity-body:

Is there more to say than "just use UTF-8"; any normalization or<= br> canonicalization issues to consider?

No= pe, no normalization or canonicalization at this layer.=C2=A0

Note that Adam Roach did raise a DISCUSS around citation f= or the media type https://mailarchive.ietf.org/a= rch/msg/oauth/Q1K-T2VS3wrHW7lx2EiP58b_DYw , which might result in a cha= nge to the wording here but it's still x-www-form-urlencoded with UTF-8= as is better described in https://tools.ietf.org/html/rfc6749#appendix-B=
=C2=A0

=C2=A0 =C2=A0subject_token
=C2=A0 =C2=A0 =C2=A0 REQUIRED.=C2=A0 A security token that represents the i= dentity of the
=C2=A0 =C2=A0 =C2=A0 party on behalf of whom the request is being made.=C2= =A0 Typically, the
=C2=A0 =C2=A0 =C2=A0 subject of this token will be the subject of the secur= ity token
=C2=A0 =C2=A0 =C2=A0 issued in response to this request.

nit: I think there's a subtle grammar mismatch here, where we start off=
by talking about a/the request and end up with "this request".

So changing that last "this request&= quot; to say "the request" would fix the mismatch?
= =C2=A0


=C2=A0 =C2=A0In the absence of one-time-use or other semantics specific to = the
=C2=A0 =C2=A0token type, the act of performing a token exchange has no impa= ct on
=C2=A0 =C2=A0the validity of the subject token or actor token.=C2=A0 Furthe= rmore, the
=C2=A0 =C2=A0validity of the subject token or actor token have no impact on= the
=C2=A0 =C2=A0validity of the issued token after the exchange has occurred.<= br>
Do we really want this strong of a statement?=C2=A0 I suspect that in many<= br> environments propagating, e.g., expiration time to the exchanged
credential may be desired.

The statemen= t was not in any way intended to prohibit propagating expiration time (or = other criteria) to the exchanged credential. The statement was added, best = I can recall, in response to a question that came up in a WG chair review a= sking if the input token(s) would somehow become invalid once used as input= to the exchange. Or if some later expiration or other invalidation of the = input token(s) would somehow invalidate the new token.=C2=A0 The point of t= he statement in the doc was to try and say that there is no inherit linkage= effectual relationship between the tokens outside the exchange event. Ther= e could be but that's not a general property of the STS protocol a woul= d be specific to a particular token type or deployment.

=
Does that make any more sense? Do you think the wording could/sh= ould be <= span> adjusted?
=C2=A0

Section 2.2.1

=C2=A0 =C2=A0token_type
[...]
=C2=A0 =C2=A0 =C2=A0 contents of the token itself.=C2=A0 Note that the mean= ing of this
=C2=A0 =C2=A0 =C2=A0 parameter is different from the meaning of the "i= ssued_token_type"
=C2=A0 =C2=A0 =C2=A0 parameter, which declares the representation of the is= sued
=C2=A0 =C2=A0 =C2=A0 security token; the term "token type" is typ= ically used with this
=C2=A0 =C2=A0 =C2=A0 meaning, as it is in all "*_token_type" para= meters in this
=C2=A0 =C2=A0 =C2=A0 specification. [...]

Please disambiguate what "typically used with this meaning" means= .
Perhaps it would be even more clear to change this field's name to
"token_access_token_type" to match the name of the registry?
<= /blockquote>

The "token_type" parameter is de= fined in RFC 6749 for a successful response from the token endpoint so this= document effectively inherits it. The name is already defined in RFC 6749 = and not in scope for this document to change.
I will update = the wording to disambiguate "this meaning" per your request.
=

=C2=A0
Section 2.3

=C2=A0 =C2=A0The following example demonstrates a hypothetical token exchan= ge in
=C2=A0 =C2=A0which an OAuth resource server assumes the role of the client = during
=C2=A0 =C2=A0token exchange in order to trade an access token that it recei= ved in
=C2=A0 =C2=A0a protected resource request for a token that it will use to c= all to
=C2=A0 =C2=A0a backend service (extra line breaks and indentation in the ex= amples
=C2=A0 =C2=A0are for display purposes only).

We could maybe add some commas or parentheses to help the reader group
the various clauses properly.=C2=A0 E.g., it is "(trade an access toke= n (that
it received in a protected resource request)) for a token...", not
"trace an access token that it received (in a protected resource reque= st
for a token)", where parentheses indicate logical grouping.

Will try and do some grouping.
=C2=A0

=C2=A0 =C2=A0 grant_type=3Durn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken= -exchange
=C2=A0 =C2=A0 &resource=3Dhttps%3A%2F%2Fbackend.example.com%2Fap= i%20
=C2=A0 =C2=A0 &subject_token=3DaccVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqce= LTC
=C2=A0 =C2=A0 &subject_token_type=3D
=C2=A0 =C2=A0 =C2=A0urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Figure 2: Token Exchange Request
Is there really supposed to be a %20 in the resource query parameter's<= br> value?

Nope. Nice catch. Thank you. I&#= 39;ll remove it.

=C2=A0

The token octets in Figures 3 and 4 do not match up, despite the prose
indicating that they are the same token.

Indeed they don't. Look like I missed one token example when updating= claim names. I'll fix that. Thanks for catching that one.

=C2=A0

Section 3

Would it be appropriate to note (here or elsewhere) that for non-JWT
token formats that are a binary format, the URI used for conveying them
needs to be associated with the semantics of base64 (or otherwise)
encoding them for usage with OAuth?

My = thinking had been that it'd be more or less self-evident to the very sm= all group and type of people who would ever undertake such a thing. But a b= rief note to that effect couldn't hurt. I'll add something as such.=

=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 Token Exchange can work
=C2=A0 =C2=A0with both tokens issued by other parties and tokens from the g= iven
=C2=A0 =C2=A0authorization server.=C2=A0 [...]

Does "work with" mean "accept as input" or "produc= e as output" or both?
For input, as both subject_token and actor_token?

=
Both and yes.
=C2=A0

=C2=A0=C2=A0 The following token type identifiers are defined by this
=C2=A0 =C2=A0specification.=C2=A0 Other URIs MAY be used to indicate other = token types.
I'd also link to the registry here.

The aforementioned other URIs may well be in different namespace so won= 9;t ever be in the registry. And that registry also has entries for things = other than token types. So I don't think a link to it here would be par= ticularly helpful or even appropriate necessarily.
=C2=A0

Why is the text about "urn:ietf:params:oauth:token-type:jwt" form= atted
differently than the other URIs listed?

The list of the ones defined in this doc is a <list style=3D"hangi= ng"> list with each URI in the list appearing in a <t hangText= =3D"URI:here"> while the :jwt URI is defined elsewhere in RFC = 7519 but relevant enough to warrant mention in this doc and it is enclosed = in a <spanx style=3D"verb"> tag. I feel like I've seen = this style of treatment of literal values with list items and in paragraph = text in other documents so considered it "normal". Is there a bet= ter or more recommended way of doing this kind of thing?
=C2=A0

=C2=A0
Section 4.1

Do we want to consider a more self-describing subject identifier scheme, akin to
https://tools.ietf.org/html/draft= -ietf-secevent-subject-identifiers ?

There's nothing precluding the use of such a scheme (well, except tha= t doc doesn't actually define a claim so some claim is needed) but the = scope of this document isn't to be that prescriptive in subject identif= ication.
=C2=A0

The example in Figure 5 appears to be using the "implicit issuer"=
behavior wherein the "iss" of the actor's "sub" is = assumed to be the
same value as in the containing structure.=C2=A0 I'm not a fan of this = type
of behavior in general, but if it's going to be used, you need to
document the possibility in some fashion.

I'm not a hug fan myself but that's what OpenID Connect did and = so it often rears its head.

I've tried to= make examples that will be meaningful to readers and also somewhat likely = to be realistic.

In this section it does say:=
"For example, the combination
=C2=A0=C2=A0 of the tw= o claims "iss" and "sub" might be necessary to uniquely=
=C2=A0=C2=A0 identify an actor"

And = sub in RFC 7519 says:
"The subject value MUST either be = scoped to be
=C2=A0=C2=A0 locally unique in the context of the issuer or= be globally unique."
=C2=A0

<= div>=C2=A0

I might also consider some language about how "the nested "act&qu= ot; claims
serve as a history trail that connects the initial request and subject
through the various delegation steps undertaken before reaching the
current actor.=C2=A0 In this sense, the current actor is considered to
include the entire authorization/delegation history, leading naturally
to the nested structure described here".=C2=A0 (But see also the other= ballot
comment about this potentially leaking information to unauthorized
parties; it seems a more careful adjustment of the text is in order
here.)

=C2=A0Okay, I can add something = to that effect.

=C2=A0
Section 4.2

Is this really the first time we're defining "scope" as a JWT= claim?=C2=A0 I
would have thought that would be defined long ago...
<= br>
Some things haven't historically happened in OAuth the wa= y one might very reasonably have expected. And this is one such thing.
=

=C2=A0

Section 4.4

Just to double-check: this is "things that can act as me" (where = "me" is
the subject of the token containing this field), right?=C2=A0
=

Yes. Honestly, I have a hard time seeing this claim act= ually being used in practice. But maybe I'm wrong. And I'm just the= editor on this one. But yes, that's the intended meaning.
=C2=A0

The
parenthetical "May Act For" doesn't really help me decide whe= ther this
claim represents the source or target of a permitted delegation, so
maybe "Allowed Impersonators" or similar would be more clear.=C2= =A0 Even "act
as" or "act on behalf of" instead of "act for" wou= ld help me, I think.
[This would have trickle-down effects to later parts of the document as
well, e.g., the IANA Considerations.]
(Not that I claim to be a representative population, of course!)

On looking at it again, I agree "May Act For= " isn't a particularly good name nor is it helpful in understandin= g it. I admit to having a hard time with the language here. But, yeah, &qu= ot;May Act For" isn't very good.

Wha= t about "Authorized Actor" in the parenthetical and "Authori= zed Actor - the party that is authorized to become the actor" for the = Claim Description in registration?
=C2=A0


It would probably also help greatly to note that when a subject_token is presented to the token endpoint in a token exchange request, the
"may_act" claim in the subject token can be used by the authoriza= tion
service to determine whether the client (or party identified in the
actor_token) is authorized to engage in the requested delegation [or
impersonation].

Okay, I can add somethi= ng to that effect.
=C2=A0

Section 6

Let me say a bit more here about my perception of the potential privacy
considerations involved in the use of an error_uri (so we can figure out if they are already discussed in a relevant document that we can cite;
JWT itself doesn't seem to cover this topic).=C2=A0 By sending an error= _uri
instead of an error string, the server is in effect causing the client
to make an outbound request to a URL of the server's choosing.=C2=A0 If= there
is a proxy between the client and server, this could result in the
server (and/or a party controlled by the server) learning additional
information about the client's identity/location.=C2=A0 A malicious ser= ver
could also attempt to construct a URI that, when retrieved by the
client, performs some unwanted side effect.=C2=A0 Defenses against this
latter scenario are pretty well known in the web comunity, but we may
want to be sure that the need for them is mentioned in a discoverable
place.

Thank you for the further explan= ation. As I wrote earlier, however, the error_uri response parameter was or= iginally defined in RFC 6749 and any privacy or security considerations for= it are applicable to=20 considerably more than this document.=C2=A0
=C2=A0


Appendix A.1.1

=C2=A0 =C2=A0In the following token exchange request, a client is requestin= g a
=C2=A0 =C2=A0token with impersonation semantics. [...]

What part of the request indicates that impersonation semantics are
requested?

I guess it's not explici= tly requesting impersonation semantics per se but only a subject_token is b= eing supplied in the request so impersonation is kinda implied as there is = no party identified that could be delegated to.

Do= you think the wording should be qualified as such or otherwise adjusted? <= br>

=C2=A0

Is the use of the "jwt" subject_token_type appropriate, given the=
previous discussion about id_token/access_token being generally
preferred (as conveying more meaning)?

= The issuer of that token isn't the given AS so it isn't an access_t= oken. And it doesn't have all the claims required to be an id_token. Th= at leaves JWT.=C2=A0 And JWT is used a lot in the examples so their claims = can also be seen and an "identity" can be traced through the exch= ange.

<= /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. --00000000000054677c057c395110-- From nobody Wed Dec 5 04:17:01 2018 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 2C2FF130E65 for ; Wed, 5 Dec 2018 04:16:53 -0800 (PST) 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=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 e7ceOGoz4atR for ; Wed, 5 Dec 2018 04:16:48 -0800 (PST) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.106]) (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 6B19C130E8A for ; Wed, 5 Dec 2018 04:16:48 -0800 (PST) Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gUW6d-0003tb-Ap; Wed, 05 Dec 2018 13:16:43 +0100 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1C5BEA89-1A67-403A-A7EA-BE73B50E762F"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Wed, 5 Dec 2018 13:16:42 +0100 In-Reply-To: <942315098.1664424.1543946581453@mail.yahoo.com> Cc: Tomek Stojecki , Daniel Fett , Vittorio Bertocci , Brian Campbell , oauth@ietf.org To: Tomek Stojecki References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 05 Dec 2018 12:17:00 -0000 --Apple-Mail=_1C5BEA89-1A67-403A-A7EA-BE73B50E762F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tomek,=20 > Am 04.12.2018 um 19:03 schrieb Tomek Stojecki : >=20 > Thanks Torsten! > So if I am putting myself in the shoes of somebody who sets out to do = that - switch an existing SPA client (no backend) I would like to ask you a question: how many SPAs w/o a backend have you = seen in your projects? > from Implicit to Code, > the options to think through can be summed up more or less as = following: >=20 > 1. Do not use RTs That=E2=80=99s what I stated.=20 > 2. If you're using RTs, rotate on every refresh AND implement RT token = binding (is that stable enough?). Refresh token rotation and sender constrained refresh tokens are = alternative methods to replay detection. I think RT rotation is the more = actionable approach.=20 > Also consider binding RT to AS session. yes. >=20 > Is that fair or is that too much of a shortcut? I am familiar with the = specs you've referenced and have looked at them again, but dealing with = a SPA, some of the recommendations are not feasible (can't authenticate = the client,=20 You could using dynamic registration (see other thread). The protection = would only differ from refresh token rotation if you would use public = key crypto for client authentication. > confidentiality in storage? - not sure how to read that in the context = of a browser) How do you ensure confidentiality of session cookies? kind regards, Torsten.=20 >=20 > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderstedt = wrote: >=20 >=20 > Hi Tomek, >=20 > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki = : > >=20 > > I agree with Vittorio, Dominick et al.=20 > >=20 > >> I disagree.=20 > >=20 > >> Existing deployments that have not mitigated against the concerns = with implicit should be ripped up and updated. > >=20 > > Yes, just like future deployments that will not mitigate against the = concerns of code in the browser should be a concern. >=20 > I agree. That=E2=80=99s why I pointed point yesterday that the = Security BCP also defines obligations for clients using code.=20 >=20 > = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.= 1 > = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.= 1.1 >=20 > >=20 > > Can somebody on the other side of the argument (and I hate to make = it sound like there are two sides, because we're on the same side as far = as Implicit's AT in front-channel is a real issue) address Dominic's = comment:=20 > >=20 > >> Also - simply saying =E2=80=9Cimplicit is evil - switch to code=E2=80= =9D means for most people also using refresh token - so we are treating = access tokens in the URL with refresh tokens in session storage (over = simplified - but you get the idea). > >=20 > > Does the group agree|disagree that a recommendation to switch to = code should be made as long as it is followed by an explanation and = guidance on what to do with RTs? The ideas that were floated around=20 > > - Token bound RTs (even though it was pointed out that token binding = is still considered an emerging standard). So should the recommendation = than say "switch to code and MUST use token bound RTs"? > > - Have AS not release RTs. "Switch to code and DO NOT request RTs"? = Or switch to code and configure AT to not release RTs for this type of = client (not sure what that even looks like in a form of a 3rd party = clients)? > > - RTs short lived and bound to a session - "Switch to code as long = as AT can bind and revoke RTs when you log out=E2=80=9C >=20 > Basically, the AS does not need to issue refresh tokens. If the AS = does not issue refresh tokens, the integration pattern for SPAs does not = change (beside the code exchange). If the client needs a new access = token, it will perform another authorization request. =20 >=20 > If it does, this adds another layer of security because it allows the = client to frequently obtain new access tokens, which can be short-lived = and scope restricted.=20 >=20 > The refresh tokens should be replay protected by issuing new refresh = tokens with every refresh and detect replay for refresh tokens belonging = to the same grant.=20 >=20 > The AS may additionally bind refresh tokens to AS sessions, but as it = was pointed out by Annabelle and others, there are some implications to = be understood and managed in that context. >=20 > You may find more text about refresh tokens in the Security BCP = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.= 12 >=20 > kind regards, > Torsten. >=20 >=20 > >=20 > > Sorry if I have missed an important detail from the list above, = people who have proposed these ideas, feel free to clarify.=20 >=20 > >=20 > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt = wrote:=20 > >=20 > > I disagree.=20 > >=20 > > Existing deployments that have not mitigated against the concerns = with implicit should be ripped up and updated. > >=20 > > For example, at one time, I think it was Instagram that had deployed = implicit because it was easier to do. Once the understood the security = implications, they changed the implementation.=20 > >=20 > > BCPs are rarely a response to a new threat, their are capturing Best = Current Practices so that they become widely deployed. > >=20 > >=20 > >=20 > >=20 > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell = wrote: > >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are = saying here. And that was kind of behind the comment I made, or tired to = make, about this in Bangkok, which was (more or less) that I don't think = the WG should be killing implicit outright but rather that it should = begin to recommend against it.=20 > >>=20 > >> I'm not exactly sure what that looks like in this document but = maybe toning down some of the scarier language a bit, favoring SHOULDs = vs. MUSTs, and including language that helps a reader understand the = recommendations as being more considerations for new = applications/deployments than as a mandate to rip up existing ones.=20 > >>=20 > >>=20 > >>=20 > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley = wrote: > >>>=20 > >>> We just need to be sensitive to the spin on this. =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._______________________________________________ > >> 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_1C5BEA89-1A67-403A-A7EA-BE73B50E762F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODEyMDUxMjE2NDJaMC8GCSqGSIb3DQEJBDEiBCCY KCWwT6tt7qPur8eJmIEIUK/ALk7quVuU4Lc+UE/1oDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAkFAA/Z4LmkAEhA5Y74e54U5c LPZo0LPd+l3zKkmHr2a0mAAIw7FdEVvtnVUxoWYDUxjnoX+u85YC4yeuWYrclkp/4mgEENSnUxUG GPGy3c3q22kWGClFG3rmUpZcFjMGIFmGLeApY6CfUM2bIAnVTxOhoFHy9pT/HrTct4yllvH8H482 984lPGbq3rCJYf+84BtFCJDaJvsrud8ddjR1H8U423RApWNQSWTzhaGeVV+zjW90ZT3SV1fM0vtJ /INUPqk4y4yn6agvU1A3/eeTY2/A+VDAUKZbIe7kFOgUTCMc7EML6hbVygRZXS6K0nGCK4byXRyO r1uBFVHmckhsoAAAAAAAAA== --Apple-Mail=_1C5BEA89-1A67-403A-A7EA-BE73B50E762F-- From nobody Wed Dec 5 06:27:41 2018 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 2A62E128C65 for ; Wed, 5 Dec 2018 06:27:38 -0800 (PST) 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=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 w0BcTw1A_q5I for ; Wed, 5 Dec 2018 06:27:35 -0800 (PST) Received: from sonic307-11.consmr.mail.ne1.yahoo.com (sonic307-11.consmr.mail.ne1.yahoo.com [66.163.190.34]) (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 52327126C01 for ; Wed, 5 Dec 2018 06:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1544020054; bh=r6wyYEzmeCHH49zMi55sUJCS7Q+MHeMCTlb1quESxac=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Vl1V6X5C0+KS8BCSgyyscguFSZ5zmu9104b3vcJ+xP3nysTa5MrfM9/9KY6Z8yP7ZLHhfcwb37xHjW249sGP/0DDVu7zJT3iyBRkyjpdAtd811w/9N4EBZu0hqca3z3jfPTlA49vKh/p9iScoi0gqKNKKDPFF30GWIPDLRrkAfXJPB+iBFeAJo58ymvKQw3W+Iphtf13RPD8ep0r3m6w3jMHC9jL4ONmx4Xzr3RX63G2GbJgKxb4LrfQLuQER2pYjY68yv7HDO+ZE7WtlhpcNng5lsmeJ7Qi97RjH5r5hmyGRk0VI9kksmTz+R/OuTAgNS9nP2PjARLcsEavLFFU3Q== X-YMail-OSG: hxypLAkVM1niPRjTTnbn9waSIiFnvjiAzzS162teve7ji8_o.xp58mZE2wM8d8h AxJ8hpH2Ej4siFSDBhcBnXIPUiZgPoPvC1GiQqmd4aZ_Hrml_ufdMrxQLhARX0mjoaJer_HGZ_9W 9gyTGYM82UpZEOnzwb4Q14VC7YwE5Suf0TSJXwzVlq4gOrXOPDyt9PQM1ghhpoLH73x4brmDoLKE 60Yxtcnf0daqAo1eLETRFktq2fr1BSIkWUTkBH8I5IbDLijz2JmSeSZYm1CSL4C3j.udBXyWMxue AeAhz_J4mx5mKsb8YMx0K9H9CvqY9AoF5jAbpF9XRaoV2Vu0ospoR5nBU08IgdPXYVQXeEhuBgfM dBs.OgRq1iiMjwnfizMi6SjmEOmfskeVnAcWi5BKhu2lrNOnHtxFIvzypBak.xPXGuqTdF2pAcAR ZNBV2UyL8sxfasddjzJ4GhSASOIBjAVYz9pVmZK6tGhP7UyrzJ905987IwDDkyUjliMFFXxiFd5T GrkuHfPKcJo2BafTYH1z82G2jnkj7oECiRcM61t28bbWshZKgIbwHJAjePTDiEmCw8LEg9dcU37N _suY.1e2bXy8KFJx0CyK3F01DTdnLbPwTG5S_9GZdI3BT2y1V.u5b_hCco6JGcdncwsduUqI3.K_ Frz2sjO7Q.kctgrqJjgbCdlMrM.iiDM9J7uBfb4jcDcOZUsqjwkERqXiuCrU_nPcB6JAIQCD6F7A bTX4p7FEPigH_nqRvfHXERBQbeT81N2_5ciQ7_DhUdonlLKbntdIpKdGLi0XXCokZo65fr.Bi77z 9nxVpndfcrjJ6J32sjXZmewzU.bNpHCwYZbi9tN5g_6t8ir7rRFrftJcxbY5HCyFYRtc__67I9Vj p4SuXfUWcfz.qslqeTn3UdV0aYCEhDelyyJWP9Iqkfa7yg5yMPuEqpzokI3NDcMEHb_kIYJGWxjo _nsTmtHTDA0zNQWZr.sCjDjHHhUpu_iMzSTp1LQZ8y4aDbZYCEYURZG97B0WFa.JeJ9f7_NMjMz_ 1QwPa0y9j3XE3oiUr5z4up.3A_dCin9Rd_0Dy7Hyog4SFyYqcb6tiCsIZQoNb9dg8xGvsv9my1Ri 2ausEtx4xmBiq5xRZu8FHJ.wgQjI0XMKddynbEjbnCSc- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Dec 2018 14:27:34 +0000 Date: Wed, 5 Dec 2018 14:27:31 +0000 (UTC) From: Tomek Stojecki To: Torsten Lodderstedt Cc: Daniel Fett , Vittorio Bertocci , Brian Campbell , oauth@ietf.org Message-ID: <1316266210.2176632.1544020051230@mail.yahoo.com> In-Reply-To: References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2176631_767423445.1544020051227" X-Mailer: WebService/1.1.12827 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36 Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 05 Dec 2018 14:27:38 -0000 ------=_Part_2176631_767423445.1544020051227 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Torsten, On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt <= torsten@lodderstedt.net> wrote: =20 =20 >> So if I am putting myself in the shoes of somebody who sets out to do t= hat - switch an existing SPA client (no backend) > I would like to ask you a question: how many SPAs w/o a backend have you = seen in your projects? SPA (html+js) utilizing a 3rd party api that requires authorization?If you = do have a backend, aren't you better of handling the token request on the b= ackend as pointed out herehttps://github.com/aaronpk/oauth-browser-based-ap= ps/blob/master/oauth-browser-based-apps.md#javascript-app-with-a-backend-co= mponent My point of putting (no backend) in parenthesis was to not derail this disc= ussion and of course it had the opposite effect. >> Is that fair or is that too much of a shortcut? I am familiar with the s= pecs you've referenced and have looked at them again, but dealing with a SP= A, some of the recommendations are not feasible (can't authenticate the cli= ent,=C2=A0 > You could using dynamic registration (see other thread). The protection w= ould only differ from refresh token rotation if you would use public key cr= ypto for client authentication. Good point. How well is dynamic registration supported across AS?=C2=A0 >> confidentiality in storage? - not sure how to read that in the context o= f a browser) > How do you ensure confidentiality of session cookies? All I am trying to say is that I think context is important here. So when y= ou point out these best practices, some of them will get people confused as= far as what it means in the browser based app scenario. Maybe it is just m= e :) >=20 > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderstedt wrote: >=20 >=20 > Hi Tomek, >=20 > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki : > >=20 > > I agree with Vittorio, Dominick et al.=20 > >=20 > >> I disagree.=20 > >=20 > >> Existing deployments that have not mitigated against the concerns with= implicit should be ripped up and updated. > >=20 > > Yes, just like future deployments that will not mitigate against the co= ncerns of code in the browser should be a concern. >=20 > I agree. That=E2=80=99s why I pointed point yesterday that the Security B= CP also defines obligations for clients using code.=20 >=20 > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2= .1 > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2= .1.1 >=20 > >=20 > > Can somebody on the other side of the argument (and I hate to make it s= ound like there are two sides, because we're on the same side as far as Imp= licit's AT in front-channel is a real issue) address Dominic's comment:=20 > >=20 > >> Also - simply saying =E2=80=9Cimplicit is evil - switch to code=E2=80= =9D means for most people also using refresh token - so we are treating acc= ess tokens in the URL with refresh tokens in session storage (over simplifi= ed - but you get the idea). > >=20 > > Does the group agree|disagree that a recommendation to switch to code s= hould be made as long as it is followed by an explanation and guidance on w= hat to do with RTs? The ideas that were floated around=20 > > - Token bound RTs (even though it was pointed out that token binding is= still considered an emerging standard). So should the recommendation than = say "switch to code and MUST use token bound RTs"? > > - Have AS not release RTs. "Switch to code and DO NOT request RTs"? Or = switch to code and configure AT to not release RTs for this type of client = (not sure what that even looks like in a form of a 3rd party clients)? > > - RTs short lived and bound to a session - "Switch to code as long as A= T can bind and revoke RTs when you log out=E2=80=9C >=20 > Basically, the AS does not need to issue refresh tokens. If the AS does n= ot issue refresh tokens, the integration pattern for SPAs does not change (= beside the code exchange). If the client needs a new access token, it will = perform another authorization request.=C2=A0=20 >=20 > If it does, this adds another layer of security because it allows the cli= ent to frequently obtain new access tokens, which can be short-lived and sc= ope restricted.=20 >=20 > The refresh tokens should be replay protected by issuing new refresh toke= ns with every refresh and detect replay for refresh tokens belonging to the= same grant.=20 >=20 > The AS may additionally bind refresh tokens to AS sessions, but as it was= pointed out by Annabelle and others, there are some implications to be und= erstood and managed in that context. >=20 > You may find more text about refresh tokens in the Security BCP https://t= ools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.12 >=20 > kind regards, > Torsten. >=20 >=20 > >=20 > > Sorry if I have missed an important detail from the list above, people = who have proposed these ideas, feel free to clarify.=20 >=20 > >=20 > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt wrote:=20 > >=20 > > I disagree.=20 > >=20 > > Existing deployments that have not mitigated against the concerns with = implicit should be ripped up and updated. > >=20 > > For example, at one time, I think it was Instagram that had deployed im= plicit because it was easier to do. Once the understood the security implic= ations, they changed the implementation.=20 > >=20 > > BCPs are rarely a response to a new threat, their are capturing Best Cu= rrent Practices so that they become widely deployed. > >=20 > >=20 > >=20 > >=20 > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell wrote: > >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are say= ing here. And that was kind of behind the comment I made, or tired to make,= about this in Bangkok, which was (more or less) that I don't think the WG = should be killing implicit outright but rather that it should begin to reco= mmend against it.=20 > >>=20 > >> I'm not exactly sure what that looks like in this document but maybe t= oning down some of the scarier language a bit, favoring SHOULDs vs. MUSTs, = and including language that helps a reader understand the recommendations a= s being more considerations for new applications/deployments than as a mand= ate to rip up existing ones.=20 > >>=20 > >>=20 > >>=20 > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley wrote: > >>>=20 > >>> We just need to be sensitive to the spin on this.=C2=A0=20 > >>>=20 > >>=20 > >> 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 = you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from you= r computer. Thank you._______________________________________________ > >> 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth =20 ------=_Part_2176631_767423445.1544020051227 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Torsten,

=20
=20
On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torst= en Lodderstedt <torsten@lodderstedt.net> wrote:


>> So if I am putting myself in= the shoes of somebody who sets out to do that - switch an existing SPA cli= ent (no backend)

> I would like to = ask you a question: how many SPAs w/o a backend have you seen in your proje= cts?

SPA (html+js) utilizi= ng a 3rd party api that requires authorization?
If yo= u do have a backend, aren't you better of handling the token request on the= backend as pointed out here
=
My point of putting (no backend) in parenthesis was to not= derail this discussion and of course it had the opposite effect.

>> Is that fair or is that to= o much of a shortcut? I am familiar with the specs you've referenced and ha= ve looked at them again, but dealing with a SPA, some of the recommendation= s are not feasible (can't authenticate the client, 

> You could using dynamic registration (see = other thread). The protection would only differ from refresh token rotation= if you would use public key crypto for client authentication.

Good point. How well is dynamic registration supported across AS?=  

>> confidentiality in storage? - not sur= e how to read that in the context of a browser)

> How do you ensure confidentiality of session cookies?
<= div dir=3D"ltr">
All I am trying to say is that I think= context is important here. So when you point out these best practices, som= e of them will get people confused as far as what it means in the browser b= ased app scenario. Maybe it is just me :)

>
> O= n Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>=
>
> Hi Tomek,
>
> > Am 04.12.2018 um 09:50 schrieb Tomek St= ojecki <tstojecki=3D40yahoo.com@dmarc.ietf.org&= gt;:
> >
> > I agree with = Vittorio, Dominick et al.
> >
&= gt; >> I disagree.
> >
&g= t; >> Existing deployments that have not mitigated against the concer= ns with implicit should be ripped up and updated.
> &g= t;
> > Yes, just like future deployments that will= not mitigate against the concerns of code in the browser should be a conce= rn.
>
> I agree. That=E2=80=99s = why I pointed point yesterday that the Security BCP also defines obligation= s for clients using code.
>
> <= a shape=3D"rect" href=3D"https://tools.ietf.org/html/draft-ietf-oauth-secur= ity-topics-10#section-2.1" rel=3D"nofollow" target=3D"_blank">https://tools= .ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#sectio= n-2.1.1
>
> >
> > Can somebody on the other side of the argument (and I h= ate to make it sound like there are two sides, because we're on the same si= de as far as Implicit's AT in front-channel is a real issue) address Domini= c's comment:
> >
> >> = Also - simply saying =E2=80=9Cimplicit is evil - switch to code=E2=80=9D me= ans for most people also using refresh token - so we are treating access to= kens in the URL with refresh tokens in session storage (over simplified - b= ut you get the idea).
> >
> &= gt; Does the group agree|disagree that a recommendation to switch to code s= hould be made as long as it is followed by an explanation and guidance on w= hat to do with RTs? The ideas that were floated around
&= gt; > - Token bound RTs (even though it was pointed out that token bindi= ng is still considered an emerging standard). So should the recommendation = than say "switch to code and MUST use token bound RTs"?
&= gt; > - Have AS not release RTs. "Switch to code and DO NOT request RTs"= ? Or switch to code and configure AT to not release RTs for this type of cl= ient (not sure what that even looks like in a form of a 3rd party clients)?=
> > - RTs short lived and bound to a session - "Sw= itch to code as long as AT can bind and revoke RTs when you log out=E2=80= =9C
>
> Basically, the AS does n= ot need to issue refresh tokens. If the AS does not issue refresh tokens, t= he integration pattern for SPAs does not change (beside the code exchange).= If the client needs a new access token, it will perform another authorizat= ion request. 
>
> If it do= es, this adds another layer of security because it allows the client to fre= quently obtain new access tokens, which can be short-lived and scope restri= cted.
>
> The refresh tokens sh= ould be replay protected by issuing new refresh tokens with every refresh a= nd detect replay for refresh tokens belonging to the same grant.
>
> The AS may additionally bind refresh= tokens to AS sessions, but as it was pointed out by Annabelle and others, = there are some implications to be understood and managed in that context.>
> You may find more text about = refresh tokens in the Security BCP https://tools.ietf.org/html/draft-ietf-oauth-securi= ty-topics-10#section-3.12
>
>= ; kind regards,
> Torsten.
>
>
> >
> &g= t; Sorry if I have missed an important detail from the list above, people w= ho have proposed these ideas, feel free to clarify.
>=
> >
> > On Monday, Decem= ber 3, 2018, 10:51:00 PM GMT+1, Dick Hardt <dick.hardt@gm= ail.com> wrote:
> >
>= > I disagree.
> >
> >= Existing deployments that have not mitigated against the concerns with imp= licit should be ripped up and updated.
> >
> > For example, at one time, I think it was Instagram tha= t had deployed implicit because it was easier to do. Once the understood th= e security implications, they changed the implementation.
> >
> > BCPs are rarely a response to a ne= w threat, their are capturing Best Current Practices so that they become wi= dely deployed.
> >
> > > >
> >
&= gt; > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:> >> FWIW I'm somewhat sympathetic to what Vittor= io, Dominick, etc. are saying here. And that was kind of behind the comment= I made, or tired to make, about this in Bangkok, which was (more or less) = that I don't think the WG should be killing implicit outright but rather th= at it should begin to recommend against it.
> >>= ;
> >> I'm not exactly sure what that looks lik= e in this document but maybe toning down some of the scarier language a bit= , favoring SHOULDs vs. MUSTs, and including language that helps a reader un= derstand the recommendations as being more considerations for new applicati= ons/deployments than as a mandate to rip up existing ones.
> >>
> >>
> &= gt;>
> >> On Mon, Dec 3, 2018 at 8:39 AM Joh= n Bradley <ve7jtb@ve7jtb.com> wrote:
> >>>
> >>> We just need to be= sensitive to the spin on this. 
> >>> =
> >>
> >> CONFIDENT= IALITY NOTICE: This email may contain confidential and privileged material = for the sole use of the intended recipient(s). Any review, use, distributio= n or disclosure by others is strictly prohibited...  If you have recei= ved this communication in error, please notify the sender immediately by e-= mail and delete the message and any file attachments from your computer. Th= ank you._______________________________________________
&= gt; >> OAuth mailing list
> >> OA= uth@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
&g= t; > https://www.ietf.org/mailman/listinf= o/oauth
> ________________________________________= _______
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
------=_Part_2176631_767423445.1544020051227-- From nobody Wed Dec 5 07:17:29 2018 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 385FD130DD3 for ; Wed, 5 Dec 2018 07:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 0gZIam6_dWqd for ; Wed, 5 Dec 2018 07:17:13 -0800 (PST) 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 E1AC8130E39 for ; Wed, 5 Dec 2018 07:17:12 -0800 (PST) Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gUYvF-0001UX-Uy; Wed, 05 Dec 2018 16:17:10 +0100 From: Torsten Lodderstedt Message-Id: <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_B1615E67-6683-4489-BFD6-DE129740A055"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Wed, 5 Dec 2018 16:17:09 +0100 In-Reply-To: <1316266210.2176632.1544020051230@mail.yahoo.com> Cc: Daniel Fett , Vittorio Bertocci , Brian Campbell , oauth@ietf.org To: Tomek Stojecki References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 05 Dec 2018 15:17:28 -0000 --Apple-Mail=_B1615E67-6683-4489-BFD6-DE129740A055 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tomek,=20 > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki : >=20 > Hi Torsten, >=20 > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt = wrote: >=20 >=20 > >> So if I am putting myself in the shoes of somebody who sets out to = do that - switch an existing SPA client (no backend) >=20 > > I would like to ask you a question: how many SPAs w/o a backend have = you seen in your projects? >=20 > SPA (html+js) utilizing a 3rd party api that requires authorization? > If you do have a backend, aren't you better of handling the token = request on the backend as pointed out here > = https://github.com/aaronpk/oauth-browser-based-apps/blob/master/oauth-brow= ser-based-apps.md#javascript-app-with-a-backend-component I agree.=20 > My point of putting (no backend) in parenthesis was to not derail this = discussion and of course it had the opposite effect. >=20 You know, I you says =E2=80=9Edon=E2=80=99t look at the green car=E2=80=9C= will cause everyone looking for it :-) It asked just out of curiosity.=20= > >> Is that fair or is that too much of a shortcut? I am familiar with = the specs you've referenced and have looked at them again, but dealing = with a SPA, some of the recommendations are not feasible (can't = authenticate the client,=20 >=20 > > You could using dynamic registration (see other thread). The = protection would only differ from refresh token rotation if you would = use public key crypto for client authentication. >=20 > Good point. How well is dynamic registration supported across AS?=20 I leave that to the vendors :-) >=20 > >> confidentiality in storage? - not sure how to read that in the = context of a browser) >=20 > > How do you ensure confidentiality of session cookies? >=20 > All I am trying to say is that I think context is important here. So = when you point out these best practices, some of them will get people = confused as far as what it means in the browser based app scenario. That=E2=80=99s why we have the more general Security BCP and = client-specific BCPs, like for native apps = (https://tools.ietf.org/html/rfc8252) and the new BCP for SPAs Aaron = started to work on. > Maybe it is just me :) thanks for raising the question! We need this kind of input to govern = the development of our specs. kind regards, Torsten.=20 >=20 > >=20 > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderstedt = wrote: > >=20 > >=20 > > Hi Tomek, > >=20 > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki = : > > >=20 > > > I agree with Vittorio, Dominick et al.=20 > > >=20 > > >> I disagree.=20 > > >=20 > > >> Existing deployments that have not mitigated against the concerns = with implicit should be ripped up and updated. > > >=20 > > > Yes, just like future deployments that will not mitigate against = the concerns of code in the browser should be a concern. > >=20 > > I agree. That=E2=80=99s why I pointed point yesterday that the = Security BCP also defines obligations for clients using code.=20 > >=20 > > = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.= 1 > > = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.= 1.1 > >=20 > > >=20 > > > Can somebody on the other side of the argument (and I hate to make = it sound like there are two sides, because we're on the same side as far = as Implicit's AT in front-channel is a real issue) address Dominic's = comment:=20 > > >=20 > > >> Also - simply saying =E2=80=9Cimplicit is evil - switch to = code=E2=80=9D means for most people also using refresh token - so we are = treating access tokens in the URL with refresh tokens in session storage = (over simplified - but you get the idea). > > >=20 > > > Does the group agree|disagree that a recommendation to switch to = code should be made as long as it is followed by an explanation and = guidance on what to do with RTs? The ideas that were floated around=20 > > > - Token bound RTs (even though it was pointed out that token = binding is still considered an emerging standard). So should the = recommendation than say "switch to code and MUST use token bound RTs"? > > > - Have AS not release RTs. "Switch to code and DO NOT request = RTs"? Or switch to code and configure AT to not release RTs for this = type of client (not sure what that even looks like in a form of a 3rd = party clients)? > > > - RTs short lived and bound to a session - "Switch to code as long = as AT can bind and revoke RTs when you log out=E2=80=9C > >=20 > > Basically, the AS does not need to issue refresh tokens. If the AS = does not issue refresh tokens, the integration pattern for SPAs does not = change (beside the code exchange). If the client needs a new access = token, it will perform another authorization request. =20 > >=20 > > If it does, this adds another layer of security because it allows = the client to frequently obtain new access tokens, which can be = short-lived and scope restricted.=20 > >=20 > > The refresh tokens should be replay protected by issuing new refresh = tokens with every refresh and detect replay for refresh tokens belonging = to the same grant.=20 > >=20 > > The AS may additionally bind refresh tokens to AS sessions, but as = it was pointed out by Annabelle and others, there are some implications = to be understood and managed in that context. > >=20 > > You may find more text about refresh tokens in the Security BCP = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.= 12 > >=20 > > kind regards, > > Torsten. > >=20 > >=20 > > >=20 > > > Sorry if I have missed an important detail from the list above, = people who have proposed these ideas, feel free to clarify.=20 > >=20 > > >=20 > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt = wrote:=20 > > >=20 > > > I disagree.=20 > > >=20 > > > Existing deployments that have not mitigated against the concerns = with implicit should be ripped up and updated. > > >=20 > > > For example, at one time, I think it was Instagram that had = deployed implicit because it was easier to do. Once the understood the = security implications, they changed the implementation.=20 > > >=20 > > > BCPs are rarely a response to a new threat, their are capturing = Best Current Practices so that they become widely deployed. > > >=20 > > >=20 > > >=20 > > >=20 > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell = wrote: > > >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. = are saying here. And that was kind of behind the comment I made, or = tired to make, about this in Bangkok, which was (more or less) that I = don't think the WG should be killing implicit outright but rather that = it should begin to recommend against it.=20 > > >>=20 > > >> I'm not exactly sure what that looks like in this document but = maybe toning down some of the scarier language a bit, favoring SHOULDs = vs. MUSTs, and including language that helps a reader understand the = recommendations as being more considerations for new = applications/deployments than as a mandate to rip up existing ones.=20 > > >>=20 > > >>=20 > > >>=20 > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley = wrote: > > >>>=20 > > >>> We just need to be sensitive to the spin on this. =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._______________________________________________ > > >> 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 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_B1615E67-6683-4489-BFD6-DE129740A055 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODEyMDUxNTE3MDlaMC8GCSqGSIb3DQEJBDEiBCCK 2MIY1KHAZEgxfhDXuUWar/RnIJ9/irSrZCAUzHoA3zCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEALXOLmZZfXqTzIP521V2wfLjH /Jh/Ax4Nl+XUCkmW1FTBZY7Ym6Ehxk/sUvr4w1z3U8xI7pfxpdYrtg+AeFhfAUAOKCGICIMcy+IW KWYQC71rc7yPLawdvw+oBCoTCZdRAYI5tSpiOX2dHLmeY/TFcrZvPu2O2DCDTk6ih03BUDKrlHeX 9hzohyuvu2O/A1DvqZ+Dx5pvUDRab2j3ejpJoH3KJ3j3Q9reKEp9dvH4DgWg9hO2tRx5HvnSqS21 JDQsV5l/YNlF7sl7VKGvn/rrjeaLr22M8cXB5HTqL6eZvk4+aDmpm/imgUT+vwcGQmxR+buxKaDJ 1J4o7mxsZzxhhgAAAAAAAA== --Apple-Mail=_B1615E67-6683-4489-BFD6-DE129740A055-- From nobody Wed Dec 5 09:29:54 2018 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 68AEB130E64 for ; Wed, 5 Dec 2018 09:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TJUtf0tGlPXi for ; Wed, 5 Dec 2018 09:29:50 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 8185F130EA5 for ; Wed, 5 Dec 2018 09:29:50 -0800 (PST) Received: from [IPv6:2601:282:202:b210:14ba:4ca3:69e6:a2ec] (unknown [IPv6:2601:282:202:b210:14ba:4ca3:69e6:a2ec]) by alkaline-solutions.com (Postfix) with ESMTPSA id 9EB6131625; Wed, 5 Dec 2018 17:29:48 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: David Waite In-Reply-To: Date: Wed, 5 Dec 2018 10:29:47 -0700 Cc: Tomek Stojecki , Daniel Fett , Brian Campbell , Vittorio Bertocci , oauth@ietf.org, Tomek Stojecki Content-Transfer-Encoding: quoted-printable Message-Id: References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 05 Dec 2018 17:29:53 -0000 > On Dec 5, 2018, at 5:16 AM, Torsten Lodderstedt = wrote: >=20 > Hi Tomek,=20 >=20 >> Am 04.12.2018 um 19:03 schrieb Tomek Stojecki : >>=20 >> Thanks Torsten! >> So if I am putting myself in the shoes of somebody who sets out to do = that - switch an existing SPA client (no backend) >=20 > I would like to ask you a question: how many SPAs w/o a backend have = you seen in your projects? Pivoting to apps with local domain business logic (aka a backend): Setup - the developer is building a browser-targeted app and at least = one mobile app - their backend would likely be identical across all = three.=20 In that case, would they want client access to that backend to be = secured with access tokens? Or should that backend to be the client to = the AS, and communication from the javascript to the backend be secured = with some non-OAuth method like cookies or API keys?=20 I push for OAuth in most of these cases, unless their strategy for = mobile apps is to =E2=80=9Cwrap=E2=80=9D the browser code and content = into a native app - in which case more flexible access to that backend = can be deferred if desired until there is stronger business need. -DW From nobody Wed Dec 5 11:29:45 2018 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 08ADD130ED7 for ; Wed, 5 Dec 2018 11:29:44 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joshka.net header.b=LCMC2pd8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YZ2Q3b2T 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 U5-IyiiAlyEM for ; Wed, 5 Dec 2018 11:29:42 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E734130DF1 for ; Wed, 5 Dec 2018 11:29:42 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id DC17AD8E for ; Wed, 5 Dec 2018 14:29:41 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Wed, 05 Dec 2018 14:29:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joshka.net; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:date:subject; s=mesmtp; bh=scLUcNG/o9RMI3qO7Gz716E cYXlJ77ySqRBVTr31mZ8=; b=LCMC2pd8wou1uq+bWrBZvOnlUsUWn+p3NQN+hRK Uj63wF+vFstCNyPxFNzmwCk9Jrn/iU9Z/gCHlx65vHu4FE0aKY3oCoqWgjoXHVvu 394DCdpnvyzxI1+JSQy/2mFPyDTa55RNKDYBMor9UM5h7EBe07/DXKBleI9kNZOp Hgfw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=scLUcN G/o9RMI3qO7Gz716EcYXlJ77ySqRBVTr31mZ8=; b=YZ2Q3b2TxDbPcPj64XAZQ1 uWMUJbwmEARQa1hCFdDWvgHkBY80Zwx9JgMkfIoqQMzR7XxSaC9Bn62ykSmoSJH3 iLVIkQn7vzE5gc9O3KBzamuK7OMj10+eb+OWIJL4K0T+PIDdl7iAYdf/aVe6Ngpd E3pJq9B2VN3YaOoCnaNc98kidyShBxuBLUgNha4YMs95/tFmaa9bTkcb5eFAd4Xt 7oCUqu4PKuken4sU4CKHUvwdXfW6uA5eumBt10gffhjVGlh/d7viiCQ/d+y5Zc+C XroOHdFQoXacWuEoLq+dbC87V1w1oEVugJ6c0luZrrir2mFGPObi9B3P17Sba1Jg == X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1DAE09E526; Wed, 5 Dec 2018 14:29:41 -0500 (EST) Message-Id: <1544038181.296618.1600075520.5A927769@webmail.messagingengine.com> From: Josh McKinney To: oauth@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-6837035d Date: Wed, 05 Dec 2018 13:29:41 -0600 Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-token-exchange comments (RESTful / OIDC claims) 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, 05 Dec 2018 19:29:44 -0000 Hiya, In section 1: The STS protocol defined in this specification is not itself RESTful (an STS doesn't lend itself particularly well to a REST approach) but does utilize communication patterns and data formats that should be familiar to developers accustomed to working with RESTful systems. A colleague expressed concern that token exchange can not be RESTful. Given that the token exchange endpoint defined here is the same as the token endpoint, is this a restatement that this endpoint itself is not RESTful as opposed to a different change. AFAICT, none of the other OAuth RFCs mention RESTful concerns. In Section 2.1: Regarding exchanging an access token for an id token, OIDC allows the caller to provide a claims parameter to specify the specific claims returned in an id token. See https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter I'm not sure that this spec explicitly constrains parameters to be passed to this method, but it also doesn't have any language to suggest that it will allow extended parameter lists to be passed and interpreted by the auth server. -- Josh McKinney joshka.net From nobody Wed Dec 5 11:33:22 2018 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 8C19B128A6E for ; Wed, 5 Dec 2018 11:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.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 cnKrF_B2KMmn for ; Wed, 5 Dec 2018 11:33:18 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 7FDA012D4EB for ; Wed, 5 Dec 2018 11:33:17 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id k15-v6so1964189ljc.8 for ; Wed, 05 Dec 2018 11:33:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=y6uOOHQrMAAHcBfp6+9bokyjlIFzHPCTtaXGk0wEmpk=; b=FGxxJfflFjEAqWvyMIZX5FTKH8D76WtZJK3qQM0Wee7DH9X6RwNTP0GZPcqZcu7INI K9sZerJg7I9BjxDH6DJeVbeuyaTP6WSDoDjMssfz4hfYGEofTuLylZRRO5NE6HZsNGcM 1V0Zd6tUSY4WHExVwq8qz5cEZTUdmZ5vPPT+1whXVN/xJIGIFcBbQzUu9XPI+Mevhmqs F8NvMII9h/9HZ090Xdn+7UIiJ6RPZJwN/7S3Cd4apIC6dAh7ONaYda7dWyv2BoGXt5GJ o1QsjtcH1fGq9WhASI+2DUUjmfoEKO/IC9KxBW5jBFhiFYE3EIxqQV6Iufe7KtetUWJf JPjw== 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:reply-to :from:date:message-id:subject:to:cc; bh=y6uOOHQrMAAHcBfp6+9bokyjlIFzHPCTtaXGk0wEmpk=; b=itx1q4KwLvxlmFaVWbXnSIFM1COQJs6DReu+OU46RfrfpKrL30MfnD9r3DXOqK+MFc +KX4U8G3cg00hP67edO7i0xfJMjgmPvWRk1f+sbzlFl6mvVSPYZQu92h/Z25RmOD4MKt Y464I8nuBLDutOdZr75jbi+7BgQAwj33o95CRoL2Oiek8RrevM80wnVAFZP68Q2uRBCq jX5EjZv840QA025cHtx9/7eB9iIkacQ+6fz/8ZRpwpjAk6B8wVw62bmAci0s+xZs5eLg 8e3ezbtj3Z8dYG4CoFdkVzAa7I5qbjifOyr+Dye9gMrzt3GcWYT9LCI43njfLWi0sqcx ZirA== X-Gm-Message-State: AA+aEWY3foYqB4W7b5aE61SIKKyU5BkaqZN1d3BZ5QOcciwsrGBJG1dd r0UCDT9gF+F0zKyoZBk9UpXsMxV//4o9rUg0usvx8g== X-Google-Smtp-Source: AFSGD/WO43Zq8A9q8Za560C4UneitvxOUZrFBBDt/pOdU1Kh2R9UUVQmpfUssfVnavBaCpux/wNUQ2+OqgabdzqY8yU= X-Received: by 2002:a2e:568b:: with SMTP id k11-v6mr16928180lje.105.1544038395348; Wed, 05 Dec 2018 11:33:15 -0800 (PST) MIME-Version: 1.0 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> In-Reply-To: Reply-To: Vittorio@auth0.com From: Vittorio Bertocci Date: Wed, 5 Dec 2018 11:33:03 -0800 Message-ID: To: David Waite Cc: Torsten Lodderstedt , tstojecki@yahoo.com, Daniel Fett , Brian Campbell , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000131cea057c4b7439" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 05 Dec 2018 19:33:20 -0000 --000000000000131cea057c4b7439 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable David, I think you are hitting on something really important here. For non-identity experts, the SPA umbrella covers every app updating the UX via JS instead of postbacks- regardless of the underlying topology. Does the app have its own backend and that backend has no other clients? Does it call its own backend AND other APIs? Does it call 3rd party APIs only? Is the current set of requirement stable for the foreseeable future, or will the app evolve to change its use case? Those are all questions that can be dismissed by advising the developer to use the most generic approach possible, e.g. getting tokens in the browser, however that comes at a complexity price that might be unnecessary if in their particular case just using cookies against their own backed (an extremely common setup, in my experience) would be enough. Even when wrapped in SDKs, that complexity is not entirely free- think ITP and the like. Per the above, just giving a blanket advice for all SPA subtypes might not be the simplest solution for a large number of developers. The question I don't have a good answer for is- how do we help developers with no identity experience (and no interest in acquiring it) to determine in what pattern they fall into, and pick the guidance relevant to their scenario? Maybe by formally enumerating those topologies and giving them names? Do you guys have ideas? On Wed, Dec 5, 2018 at 9:29 AM David Waite wrote: > > > > On Dec 5, 2018, at 5:16 AM, Torsten Lodderstedt > wrote: > > > > Hi Tomek, > > > >> Am 04.12.2018 um 19:03 schrieb Tomek Stojecki : > >> > >> Thanks Torsten! > >> So if I am putting myself in the shoes of somebody who sets out to do > that - switch an existing SPA client (no backend) > > > > I would like to ask you a question: how many SPAs w/o a backend have yo= u > seen in your projects? > > Pivoting to apps with local domain business logic (aka a backend): > > Setup - the developer is building a browser-targeted app and at least one > mobile app - their backend would likely be identical across all three. > > In that case, would they want client access to that backend to be secured > with access tokens? Or should that backend to be the client to the AS, an= d > communication from the javascript to the backend be secured with some > non-OAuth method like cookies or API keys? > > I push for OAuth in most of these cases, unless their strategy for mobile > apps is to =E2=80=9Cwrap=E2=80=9D the browser code and content into a nat= ive app - in which > case more flexible access to that backend can be deferred if desired unti= l > there is stronger business need. > > -DW > > --000000000000131cea057c4b7439 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
David, I think you are hitting on something really importa= nt here.
For non-identity experts, the SPA umbrella covers every app up= dating the UX via JS instead of postbacks- regardless of the underlying top= ology. Does the app have its own backend and that backend has no other clie= nts? Does it call its own backend AND other APIs? Does it call 3rd party AP= Is only? Is the current set of requirement stable for the foreseeable futur= e, or will the app evolve to change its use case?
Those are all q= uestions that can be dismissed by advising the developer to use the most ge= neric approach possible, e.g. getting tokens in the browser, however that c= omes at a complexity price that might be unnecessary if in their particular= case just using cookies against their own backed (an extremely common setu= p, in my experience) would be enough. Even when wrapped in SDKs, that compl= exity is not entirely free- think ITP and the like.
Per the above= , just giving a blanket advice for all SPA subtypes might not be the simple= st solution for a large number of developers.

The = question I don't have a good answer for is- how do we help developers w= ith no identity experience (and no interest in acquiring it) to determine i= n what pattern they fall into, and pick the guidance relevant to their scen= ario? Maybe by formally enumerating those topologies and giving them names?= Do you guys have ideas?=C2=A0

On Wed, Dec 5, 2018 at 9:29 AM David Waite <david@alkaline-solutions.com> wro= te:


> On Dec 5, 2018, at 5:16 AM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:
>
> Hi Tomek,
>
>> Am 04.12.2018 um 19:03 schrieb Tomek Stojecki <tstojecki@yahoo.com>:
>>
>> Thanks Torsten!
>> So if I am putting myself in the shoes of somebody who sets out to= do that - switch an existing SPA client (no backend)
>
> I would like to ask you a question: how many SPAs w/o a backend have y= ou seen in your projects?

Pivoting to apps with local domain business logic (aka a backend):

Setup - the developer is building a browser-targeted app and at least one m= obile app - their backend would likely be identical across all three.

In that case, would they want client access to that backend to be secured w= ith access tokens? Or should that backend to be the client to the AS, and c= ommunication from the javascript to the backend be secured with some non-OA= uth method like cookies or API keys?

I push for OAuth in most of these cases, unless their strategy for mobile a= pps is to =E2=80=9Cwrap=E2=80=9D the browser code and content into a native= app - in which case more flexible access to that backend can be deferred i= f desired until there is stronger business need.

-DW

--000000000000131cea057c4b7439-- From nobody Wed Dec 5 17:15:33 2018 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 144DE1200B3 for ; Wed, 5 Dec 2018 17:15:30 -0800 (PST) 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_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=auth0.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 i-LBiiVmYOMf for ; Wed, 5 Dec 2018 17:15:24 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 C05AE1286E3 for ; Wed, 5 Dec 2018 17:15:23 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id e26so16214810lfc.2 for ; Wed, 05 Dec 2018 17:15:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QNSND7jrag5Knm0fScXpiiAi9y0a1xDCBAo9vC5jedI=; b=fTQJqXopK9cPgm5V2XZaPpN4rgm6knyP6XLRPo4freC8zzhFHXhOSI71H7OtDZGI2l MmES/yhvp9BHKod3gmPFjFHUWg+FsrRDcl6x5H6dEjj679WzuDoEkv02h6LSn3Dg5yKm wpWmW2DZhfyTJPraQOo2dWGTDLy6KERBUybYLGHB8rhcpIZqxPPlV1l9ItbXwjtcBQub MIL/vahtir1MJKR2IqG2wKED7+gofa1zZ4fE/Uh22V0BCT9yjAT3eoyd/eBcHZc1iPOi TPXBbHBEWKgE3BKSnaqfiv0mfOv01dYPFEK8CFLHFYfZoy+nm30TqRihEu+5wAlWlZP+ hjfQ== 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=QNSND7jrag5Knm0fScXpiiAi9y0a1xDCBAo9vC5jedI=; b=Llr+E3zHFNPai8n4f9O3zm0cX5Gi2bNZAKYCgE9WBd7AfwoYGS0yRPp01qOQxyjrpO 1HzBtapX5xz91wZ7mYJgLNLAlacFdU8tEu5PjE04VFT1TteT/XEYVXVbjb5YU5R+JxS1 m3fYkPdzHmkH9QNavnm/dTpcWl/kKGKsKatQKwMrYUV7AO8a51yoxsvE3RTq149DrBnd 95EVU8Nep5Ivi2juiF6sQ2sjCQVyU+GVBfXMRGBccAJ4WLpFt2Dyb9YMTZFy1UqB7dQG jhblpLKdNbIxXNjWW2ZK+/TwU7Q/WNv+396605lKX6pGCGq4g417p21RxTyJaPW0t6LK 23Ig== X-Gm-Message-State: AA+aEWayQutwqzTvF18IGmIme7OXOwkYUg/mRv7LDDDVL+BMeYOlQGnn L9hJyeLPPDvoeliaps4//7LMIqO5rG/nMqX9VhV8kg== X-Google-Smtp-Source: AFSGD/U157HZTd7OLNLBCNXXDKGBwECTRcEZR6z9CFwomgISr+HT3qhAnOO9rAnXWI8ZF5CLqs0PYahEC7sAJVt6KWc= X-Received: by 2002:a19:d486:: with SMTP id l128mr14859350lfg.114.1544058921559; Wed, 05 Dec 2018 17:15:21 -0800 (PST) MIME-Version: 1.0 References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> <7FEF0314-88F2-46C7-A22D-C794CC1BB6A0@lodderstedt.net> In-Reply-To: From: Vittorio Bertocci Date: Wed, 5 Dec 2018 17:15:10 -0800 Message-ID: To: aaron@parecki.com Cc: Brian Campbell , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000884630057c503bd4" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 06 Dec 2018 01:15:30 -0000 --000000000000884630057c503bd4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As mentioned during IIW when this pattern was borught up: I think readers should receive a stronger warning about the known challenges of that approach. Namely, assuming that the developer wants to perform API calls from the browser: - Making the app backend the true client for the AS is tantamount to making the app backend act as an AS for the JS running in the browser. The traffic between the JS layer and its backend for getting the initial token, renewing tokens, doing stepup auth and the like is not codified in any normative document- hence it's not threat modeled. Leaving it as exercise to the reader without proper warnings seems reckless - Various important providers indicate in the access token whether it was issued to a confidential client or to a public one- and resources can rely on that to make authorization decisions (for example allowing access only to specific confidential clients). By having an app backend to act as a proxy and pass those access tokens along to the JS layer, a resource might be fooled into thinking that the caller is a confidential client, while in fact the client is just a public client. Implementers choosing to use the proxy pattern should either ensure resources refrain from using the nature of the client (as certified by the access token) as input to authorization decisions, or should have a way to signal to the AS that the tokens requested are meant to be actually used by a weaker client hence should not mark the ATs as issued to a confidential client. I am not suggesting that the document should necessarily contain this level of detail, but I do think we should hint at those two challenges so that readers have a better idea of the risks inherent to the approach with today's tools. Related to this: if we think this pattern is common, we should consider producing formal guidance on how to handle the necessary exchanges- or we'll end up with a babel of proprietary ways of connecting the JS frontent to the backend, with huge waste of cycles across the industry. On Tue, Dec 4, 2018 at 10:57 AM Aaron Parecki wrote: > Thanks for all the discussion here. I've added the paragraph described to > the document in a new "Architectural Considerations" section. Currently i= n > the GitHub source code but not yet published as a new IETF draft, which > will be coming shortly. > https://github.com/aaronpk/oauth-browser-based-apps > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > > On Mon, Dec 3, 2018 at 9:53 AM Brian Campbell > wrote: > >> I would also like to see something to that effect. I feel that sometimes >> because SPAs use APIs, there's an unchallenged assumption that OAuth als= o >> has to be used with the in-browser code accessing those APIs. Even if th= e >> details are out of scope for this document, some text like the below at >> least gives a nod to the possibility of different approaches, which may >> ultimately be more secure and easier to mange. >> https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-00#se= ction-5.1 >> kinda does this too but I'm a +1 for a little something along the lines = of >> what is being discussed recently in this thread. >> >> >> >> On Mon, Dec 3, 2018 at 7:57 AM Aaron Parecki wrote: >> >>> I support adding something to that effect, but would like to make it >>> clear that this removes the app from being covered under this BCP. How >>> about: >>> >>> --- >>> Implementations MAY consider moving the authorization code exchange and >>> handling of access and refresh tokens to a backend component in order t= o >>> avoid the risks inherent in handling access tokens from a purely browse= r >>> based app. In this case, the backend component can be a confidential cl= ient >>> and can be secured accordingly. >>> >>> Security of the connection between code running in the browser and this >>> backend component is assumed to utilize browser-level protection >>> mechanisms. Details are out of scope of this document. >>> --- >>> >>> >>> >>> >>> On Mon, Dec 3, 2018 at 3:15 AM Torsten Lodderstedt < >>> torsten@lodderstedt.net > wrote: >>> >>>> Interesting. Even on this list people felt to see that moving some >>>> logic to a backend could solve some of the problems raised. What I wan= t to >>>> convey is: the solution to a problem in the OAuth space does not >>>> necessarily need to be found on the OAuth protocol level. That=E2=80= =99s a best >>>> practice in the same way as some OAuth pattern. >>>> >>>> What I=E2=80=99m suggesting is a statement in the BCP like >>>> >>>> =E2=80=94 >>>> Implementations MAY consider to move authorization code exchange and >>>> handling of access and refresh tokens to a backend component in order = to >>>> fulfill their security goals. >>>> >>>> Security of the connection between code running in the browser and thi= s >>>> backend component is assumed to utilize browser-level protection >>>> mechanisms. Details are out of scope of this document. >>>> =E2=80=94 >>>> >>>> > Am 03.12.2018 um 11:19 schrieb John Bradley : >>>> > >>>> > This is my point. >>>> > >>>> > From a security perspective we have a server based confidential >>>> client... The fact that it has a angular or other JS UI protected by= a >>>> cookie seems to not be especially relucent to OAuth. >>>> > >>>> > Perhaps from the developer point of view they have a JS SPA and the >>>> only difference to them is in one case they are including the OAuth cl= ient >>>> and in the other they are using a server based proxy. So they see it a= s the >>>> same. >>>> > >>>> > Perhaps it is perspective. >>>> > >>>> > On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki >>> > In this type of deployment, as far as OAuth is concerned, isn't the >>>> backend web server a confidential client? Is there even anything uniqu= e to >>>> this situation as far as OAuth security goes? >>>> > >>>> > I wouldn't have expected an Angular app that talks to its own server >>>> backend that's managing OAuth credentials to fall under the umbrella o= f >>>> this BCP. >>>> > >>>> > ---- >>>> > Aaron Parecki >>>> > aaronparecki.com >>>> > >>>> > >>>> > >>>> > On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt < >>>> torsten@lodderstedt.net> wrote: >>>> > the UI is rendered in the frontend, UI control flow is in the >>>> frontend... just a different cut through the web app=E2=80=99s layerin= g >>>> > >>>> > All Angular apps I have seen so far work that way. And it makes a lo= t >>>> of sense to me. The backend can aggregate and optimize access to the >>>> underlying services without the need to fully expose them. >>>> > >>>> > Am 02.12.2018 um 00:44 schrieb John Bradley : >>>> > >>>> >> How is that different from a regular server client with a web >>>> interface if the backed is doing the API calls to the RS? >>>> >> >>>> >> >>>> >> >>>> >> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: >>>> >>> I forgot to mention another (architectural) option: split an >>>> application into frontend provided by JS in the browser and a backend, >>>> which takes care of the business logic and handles tokens and API acce= ss. >>>> Replay detection at the interface between SPA and backend can utilize >>>> standard web techniques (see OWASP). The backend in turn can use mTLS = for >>>> sender constraining. >>>> >>> >>>> >>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt < >>>> torsten@lodderstedt.net>: >>>> >>> >>>> >>>> IMHO the best mechanism at hand currently to cope with token >>>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay >>>> detection) and issue short living and privilege restricted access toke= ns. >>>> >>>> >>>> >>>> Sender constrained access tokens in SPAs need adoption of token >>>> binding or alternative mechanism. mtls could potentially work in >>>> deployments with automated cert rollout but browser UX and interplay w= ith >>>> fetch needs some work. We potentially must consider to warm up applica= tion >>>> level PoP mechanisms in conjunction with web crypto. Another path to b= e >>>> evaluated could be web auth. >>>> >>>> >>>> >>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig < >>>> Hannes.Tschofenig@arm.com>: >>>> >>>> >>>> >>>>> I share the concern Brian has, which is also the conclusion I >>>> came up with in my other email sent a few minutes ago. >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> From: OAuth On Behalf Of Brian Campbell >>>> >>>>> Sent: Friday, November 30, 2018 11:43 PM >>>> >>>>> To: Torsten Lodderstedt >>>> >>>>> Cc: oauth >>>> >>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-0= 0 >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt < >>>> torsten@lodderstedt.net> wrote: >>>> >>>>> >>>> >>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen < >>>> brockallen@gmail.com>: >>>> >>>>> > >>>> >>>>> > So you mean at the resource server ensuring the token was >>>> really issued to the client? Isn't that an inherent limitation of all >>>> bearer tokens (modulo HTTP token binding, which is still some time off= )? >>>> >>>>> >>>> >>>>> Sure. That=E2=80=99s why the Security BCP recommends use of TLS-= based >>>> methods for sender constraining access tokens ( >>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#sectio= n-2..2). >>>> Token Binding for OAuth ( >>>> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well >>>> as Mutual TLS for OAuth ( >>>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options >>>> available. >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Unfortunately even when using the token endpoint, for SPA / >>>> in-browser client applications, the potential mechanisms for >>>> sender/key-constraining access tokens don't work very well or maybe do= n't >>>> work at all. So I don't know that the recommendation is very realistic= . >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged material for the sole use of the intended recipient(s)... A= ny >>>> review, use, distribution or disclosure by others is strictly prohibit= ed.. >>>> If you have received this communication in error, please notify the se= nder >>>> immediately by e-mail and delete the message and any file attachments = from >>>> your computer. Thank you. >>>> >>>>> >>>> >>>>> IMPORTANT NOTICE: The contents of this email and any attachments >>>> are confidential and may also be privileged. If you are not the intend= ed >>>> recipient, please notify the sender immediately and do not disclose th= e >>>> 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 >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> 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 >>>> >>>> -- >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000884630057c503bd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As mentioned during IIW when this pattern was borught up: = I think readers should receive a stronger warning about the known challenge= s of that approach. Namely, assuming that the developer wants to perform AP= I calls from the browser:
- Making the app backend the true client for = the AS is tantamount to making the app backend act as an AS for the JS runn= ing in the browser. The traffic between the JS layer and its backend for ge= tting the initial token, renewing tokens, doing stepup auth and the like is= not codified in any normative document- hence it's not threat modeled.= Leaving it as exercise to the reader without proper warnings seems reckles= s
- Various important providers indicate in the access token whet= her it was issued to a confidential client or to a public one- and resource= s can rely on that to make authorization decisions (for example allowing ac= cess only to specific confidential clients). By having an app backend to ac= t as a proxy and pass those access tokens along to the JS layer, a resource= might be fooled into thinking that the caller is a confidential client, wh= ile in fact the client is just a public client. Implementers choosing to us= e the proxy pattern should either ensure resources refrain from using the n= ature of the client (as certified by the access token) as input to authoriz= ation decisions, or should have a way to signal to the AS that the tokens r= equested are meant to be actually used by a weaker client hence should not = mark the ATs as issued to a confidential client.=C2=A0

=
I am not suggesting that the document should necessarily contain this = level of detail, but I do think we should hint at those two challenges so t= hat readers have a better idea of the risks inherent to the approach with t= oday's tools.

Related to this: if we think thi= s pattern is common, we should consider producing formal guidance on how to= handle the necessary exchanges- or we'll end up with a babel of propri= etary ways of connecting the JS frontent to the backend, with huge waste of= cycles across the industry.

On Tue, Dec 4, 2018 at 10:57 AM Aaron Parecki <aaron@parecki.com> wrote:
Thanks for all the= discussion here. I've added the paragraph described to the document in= a new "Architectural Considerations" section. Currently in the G= itHub source code but not yet published as a new IETF draft, which will be = coming shortly.=C2=A0https://github.com/aaronpk/oauth-browser-based-= apps

----
Aaron Parecki
<= div>@aaronpk



On Mon, Dec 3, 2018 at 9:53 AM Brian Campbell <= ;bcampbell@= pingidentity.com> wrote:
I would also like to see something to t= hat effect. I feel that sometimes because SPAs use APIs, there's an unc= hallenged assumption that OAuth also has to be used with the in-browser cod= e accessing those APIs. Even if the details are out of scope for this docum= ent, some text like the below at least gives a nod to the possibility of di= fferent approaches, which may ultimately be more secure and easier to mange= . https://tools.ietf.org/html/draft-pa= recki-oauth-browser-based-apps-00#section-5.1 kinda does this too but I= 'm a +1 for a little something along the lines of what is being discuss= ed recently in this thread.



On Mon, Dec 3, 2018 at 7:57 AM Aar= on Parecki <aaron= @parecki.com> wrote:
I support adding something to that effec= t, but would like to make it clear that this removes the app from being cov= ered under this BCP. How about:

---
Implementations MAY consider movin= g the authorization code exchange and handling of access and refresh tokens= to a backend component in order to avoid the risks inherent in handling ac= cess tokens from a purely browser based app. In this case, the backend comp= onent can be a confidential client and can be secured accordingly.

S= ecurity of the connection between code running in the browser and this back= end component is assumed to utilize browser-level protection mechanisms. De= tails are out of scope of this document.=C2=A0
-= --




On Mo= n, Dec 3, 2018 at 3:15 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:=
Interesting. Ev= en on this list people felt to see that moving some logic to a backend coul= d solve some of the problems raised. What I want to convey is: the solution= to a problem in the OAuth space does not necessarily need to be found on t= he OAuth protocol level. That=E2=80=99s a best practice in the same way as = some OAuth pattern.

What I=E2=80=99m suggesting is a statement in the BCP like

=E2=80=94
Implementations MAY consider to move authorization code exchange and handli= ng of access and refresh tokens to a backend component in order to fulfill = their security goals.

Security of the connection between code running in the browser and this bac= kend component is assumed to utilize browser-level protection mechanisms. D= etails are out of scope of this document.
=E2=80=94

> Am 03.12.2018 um 11:19 schrieb John Bradley <ve7jtb@ve7jtb.com>:
>
> This is my point.=C2=A0
>
> From a security perspective we have a server based confidential client= ...=C2=A0 =C2=A0The fact that it has a angular or other JS UI protected by = a cookie seems to not be especially relucent to OAuth.=C2=A0
>
> Perhaps from the developer point of view they have a JS SPA and the on= ly difference to them is in one case they are including the OAuth client an= d in the other they are using a server based proxy. So they see it as the s= ame.
>
> Perhaps it is perspective.
>
> On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki <aaron@parecki.com wrote:
> In this type of deployment, as far as OAuth is concerned, isn't th= e backend web server a confidential client? Is there even anything unique t= o this situation as far as OAuth security goes?
>
> I wouldn't have expected an Angular app that talks to its own serv= er backend that's managing OAuth credentials to fall under the umbrella= of this BCP.
>
> ----
> Aaron Parecki
> aaronparecki.com
>
>
>
> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt <torsten@lodderstedt.net&= gt; wrote:
> the UI is rendered in the frontend, UI control flow is in the frontend= ... just a different cut through the web app=E2=80=99s layering
>
> All Angular apps I have seen so far work that way. And it makes a lot = of sense to me. The backend can aggregate and optimize access to the underl= ying services without the need to fully expose them.
>
> Am 02.12.2018 um 00:44 schrieb John Bradley <ve7jtb@ve7jtb.com>:
>
>> How is that different from a regular server client with a web inte= rface if the backed is doing the API calls to the RS?
>>
>>
>>
>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>> I forgot to mention another (architectural) option: split an a= pplication into frontend provided by JS in the browser and a backend, which= takes care of the business logic and handles tokens and API access. Replay= detection at the interface between SPA and backend can utilize standard we= b techniques (see OWASP). The backend in turn can use mTLS for sender const= raining.
>>>
>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <torsten@lodderstedt.n= et>:
>>>
>>>> IMHO the best mechanism at hand currently to cope with tok= en leakage/replay in SPAs is to use refresh tokens (rotating w/ replay dete= ction) and issue short living and privilege restricted access tokens.
>>>>
>>>> Sender constrained access tokens in SPAs need adoption of = token binding or alternative mechanism. mtls could potentially work in depl= oyments with automated cert rollout but browser UX and interplay with fetch= needs some work. We potentially must consider to warm up application level= PoP mechanisms in conjunction with web crypto. Another path to be evaluate= d could be web auth.
>>>>
>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <Hannes.Tschofenig= @arm.com>:
>>>>
>>>>> I share the concern Brian has, which is also the concl= usion I came up with in my other email sent a few minutes ago.
>>>>>
>>>>>=C2=A0
>>>>>
>>>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Cam= pbell
>>>>> Sent: Friday, November 30, 2018 11:43 PM
>>>>> To: Torsten Lodderstedt <torsten@lodderstedt.net>
>>>>> Cc: oauth <oauth@ietf.org>
>>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-ba= sed-apps-00
>>>>>
>>>>>=C2=A0
>>>>>
>>>>>=C2=A0
>>>>>
>>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt &l= t;torsten@lodd= erstedt.net> wrote:
>>>>>
>>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.co= m>:
>>>>> >
>>>>> > So you mean at the resource server ensuring the t= oken was really issued to the client? Isn't that an inherent limitation= of all bearer tokens (modulo HTTP token binding, which is still some time = off)?
>>>>>
>>>>> Sure. That=E2=80=99s why the Security BCP recommends u= se of TLS-based methods for sender constraining access tokens (https://tools.ietf.org/html/draft-ie= tf-oauth-security-topics-09#section-2..2). Token Binding for OAuth (https://tools.ietf.org/html/draft-ietf-oa= uth-token-binding-08) as well as Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are t= he options available.
>>>>>
>>>>>=C2=A0
>>>>>
>>>>> Unfortunately even when using the token endpoint, for = SPA / in-browser client applications, the potential mechanisms for sender/k= ey-constraining access tokens don't work very well or maybe don't w= ork at all. So I don't know that the recommendation is very realistic.<= br> >>>>>
>>>>>=C2=A0
>>>>>
>>>>>
>>>>> CONFIDENTIALITY NOTICE: This email may contain confide= ntial and privileged material for the sole use of the intended recipient(s)= ... Any review, use, distribution or disclosure by others is strictly prohi= bited..=C2=A0 If you have received this communication in error, please noti= fy the sender immediately by e-mail and delete the message and any file att= achments from your computer. Thank you.
>>>>>
>>>>> IMPORTANT NOTICE: The contents of this email and any a= ttachments are confidential and may also be privileged. If you are not the = intended recipient, please notify the sender immediately and do not disclos= e the contents to any other person, use it for any purpose, or store or cop= y the information in any medium. Thank you.
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oa= uth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>>
>>> OAuth@ietf= ...org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> > _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

--
----
Aaron Parecki

_______________________________________________
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 th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000884630057c503bd4-- From nobody Wed Dec 5 17:17:32 2018 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 062171200B3 for ; Wed, 5 Dec 2018 17:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, 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 (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 xPz9DuORopeW for ; Wed, 5 Dec 2018 17:17:23 -0800 (PST) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 4E3621286E3 for ; Wed, 5 Dec 2018 17:17:23 -0800 (PST) Received: by mail-it1-x12f.google.com with SMTP id h193so23327831ita.5 for ; Wed, 05 Dec 2018 17:17:23 -0800 (PST) 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; bh=t0APHbluvT4cfTVU8SEpxmphZRDfz1Ay7Dd2bURsX+8=; b=cKCVX8Plpi5nmBHpocxC/GunYYSdX4P0qOjUq2sX11LjQaMfePdzK6CA1CvcoO/HR5 xedNVwucfZlJHLcAx5re0sW1IBTG3a5OwliY1q2gpjtS+XYMiGW4YrKhoJQ9gnKF3DRm eNZpfYtFdWYuF3FNE+0fOtjCH3nuUPKnH2Uv9DC0wwAxwLnkWaQlHvoQydu8rN0zzT0P DRT3LzzOjRGmCVcsbwYwPZ7CU0n2B5SJQGk93Fg/s5WrM8aeyxVzZQLzJ18n1T8MveiP ZRNrhkpdNnQxizA94Gt3NAK1GC8SFk+V0epZ+bDsySfnDkykVqaB+SCD7tZe5RCG+j1C DNZg== 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=t0APHbluvT4cfTVU8SEpxmphZRDfz1Ay7Dd2bURsX+8=; b=kNxdMGGD9eECZZW2Jio1Aw3l358GgAyrpaunOPkASfAvEzjrzZy8O3xZGNRl4Udu+p 0yH7lniLmFK8IfNmd523KNgKaPTZOECnvbJ+tgyNcWfgq0c9FYTcd9XWagO9Xb9chUt/ tWjk0CzezAj+iOTzP53EeAyXU4cpH8FUcezDzNOZg/HvT5MZJCPTBlXXTl/8B6h7knnV i9bpT7lE53yVdbpv0B9Y5aCZJHXmPVCROTJVGfx6dslu9y3L1PK7x8382/sfY8sEKBcF yFoE0cmihrDk00A+G45tM94/0vu5938UNSveBFV7v25EI041Ev36Jfa1eMYnED+R4t3Y bHYg== X-Gm-Message-State: AA+aEWbXUPUXeHnIX4glQSQnEUguiXlfIwWhdFVw/AHaB1ANw3v6QUYu RrSOs+lYcNAZHX9kZKoAtG0vfiWJtwQ= X-Google-Smtp-Source: AFSGD/UyyYcd2+u+3/WiZHmW9FFJjBqVNaFuG6LI5JYVaZ8HEqc3+jO1W52R8MuLII2qcPZ0Ie2UyQ== X-Received: by 2002:a02:970b:: with SMTP id x11mr24216318jai.67.1544059042107; Wed, 05 Dec 2018 17:17:22 -0800 (PST) Received: from mail-it1-f182.google.com (mail-it1-f182.google.com. [209.85.166.182]) by smtp.gmail.com with ESMTPSA id x128sm8198031itb.8.2018.12.05.17.17.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 17:17:20 -0800 (PST) Received: by mail-it1-f182.google.com with SMTP id i145so24605445ita.4 for ; Wed, 05 Dec 2018 17:17:20 -0800 (PST) X-Received: by 2002:a24:4016:: with SMTP id n22mr19366683ita.25.1544059040397; Wed, 05 Dec 2018 17:17:20 -0800 (PST) MIME-Version: 1.0 References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> <7FEF0314-88F2-46C7-A22D-C794CC1BB6A0@lodderstedt.net> In-Reply-To: From: Aaron Parecki Date: Wed, 5 Dec 2018 19:17:08 -0600 X-Gmail-Original-Message-ID: Message-ID: To: Vittorio Bertocci Cc: Brian Campbell , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000009d80e9057c50422e" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 06 Dec 2018 01:17:30 -0000 --0000000000009d80e9057c50422e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's a very good point, I will see what I can adapt from your description below for the spec. I do think it's worth emphasizing like you say. Aaron On Wed, Dec 5, 2018 at 7:15 PM Vittorio Bertocci wrote= : > As mentioned during IIW when this pattern was borught up: I think readers > should receive a stronger warning about the known challenges of that > approach. Namely, assuming that the developer wants to perform API calls > from the browser: > - Making the app backend the true client for the AS is tantamount to > making the app backend act as an AS for the JS running in the browser. Th= e > traffic between the JS layer and its backend for getting the initial toke= n, > renewing tokens, doing stepup auth and the like is not codified in any > normative document- hence it's not threat modeled. Leaving it as exercise > to the reader without proper warnings seems reckless > - Various important providers indicate in the access token whether it was > issued to a confidential client or to a public one- and resources can rel= y > on that to make authorization decisions (for example allowing access only > to specific confidential clients). By having an app backend to act as a > proxy and pass those access tokens along to the JS layer, a resource migh= t > be fooled into thinking that the caller is a confidential client, while i= n > fact the client is just a public client. Implementers choosing to use the > proxy pattern should either ensure resources refrain from using the natur= e > of the client (as certified by the access token) as input to authorizatio= n > decisions, or should have a way to signal to the AS that the tokens > requested are meant to be actually used by a weaker client hence should n= ot > mark the ATs as issued to a confidential client. > > I am not suggesting that the document should necessarily contain this > level of detail, but I do think we should hint at those two challenges so > that readers have a better idea of the risks inherent to the approach wit= h > today's tools. > > Related to this: if we think this pattern is common, we should consider > producing formal guidance on how to handle the necessary exchanges- or > we'll end up with a babel of proprietary ways of connecting the JS fronte= nt > to the backend, with huge waste of cycles across the industry. > > On Tue, Dec 4, 2018 at 10:57 AM Aaron Parecki wrote: > >> Thanks for all the discussion here. I've added the paragraph described t= o >> the document in a new "Architectural Considerations" section. Currently = in >> the GitHub source code but not yet published as a new IETF draft, which >> will be coming shortly. >> https://github.com/aaronpk/oauth-browser-based-apps >> >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> >> >> On Mon, Dec 3, 2018 at 9:53 AM Brian Campbell >> wrote: >> >>> I would also like to see something to that effect. I feel that sometime= s >>> because SPAs use APIs, there's an unchallenged assumption that OAuth al= so >>> has to be used with the in-browser code accessing those APIs. Even if t= he >>> details are out of scope for this document, some text like the below at >>> least gives a nod to the possibility of different approaches, which may >>> ultimately be more secure and easier to mange. >>> https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-00#s= ection-5.1 >>> kinda does this too but I'm a +1 for a little something along the lines= of >>> what is being discussed recently in this thread. >>> >>> >>> >>> On Mon, Dec 3, 2018 at 7:57 AM Aaron Parecki wrote: >>> >>>> I support adding something to that effect, but would like to make it >>>> clear that this removes the app from being covered under this BCP. How >>>> about: >>>> >>>> --- >>>> Implementations MAY consider moving the authorization code exchange an= d >>>> handling of access and refresh tokens to a backend component in order = to >>>> avoid the risks inherent in handling access tokens from a purely brows= er >>>> based app. In this case, the backend component can be a confidential c= lient >>>> and can be secured accordingly. >>>> >>>> Security of the connection between code running in the browser and thi= s >>>> backend component is assumed to utilize browser-level protection >>>> mechanisms. Details are out of scope of this document. >>>> --- >>>> >>>> >>>> >>>> >>>> On Mon, Dec 3, 2018 at 3:15 AM Torsten Lodderstedt < >>>> torsten@lodderstedt.net > wrote: >>>> >>>>> Interesting. Even on this list people felt to see that moving some >>>>> logic to a backend could solve some of the problems raised. What I wa= nt to >>>>> convey is: the solution to a problem in the OAuth space does not >>>>> necessarily need to be found on the OAuth protocol level. That=E2=80= =99s a best >>>>> practice in the same way as some OAuth pattern. >>>>> >>>>> What I=E2=80=99m suggesting is a statement in the BCP like >>>>> >>>>> =E2=80=94 >>>>> Implementations MAY consider to move authorization code exchange and >>>>> handling of access and refresh tokens to a backend component in order= to >>>>> fulfill their security goals. >>>>> >>>>> Security of the connection between code running in the browser and >>>>> this backend component is assumed to utilize browser-level protection >>>>> mechanisms. Details are out of scope of this document. >>>>> =E2=80=94 >>>>> >>>>> > Am 03.12.2018 um 11:19 schrieb John Bradley : >>>>> > >>>>> > This is my point. >>>>> > >>>>> > From a security perspective we have a server based confidential >>>>> client... The fact that it has a angular or other JS UI protected b= y a >>>>> cookie seems to not be especially relucent to OAuth. >>>>> > >>>>> > Perhaps from the developer point of view they have a JS SPA and the >>>>> only difference to them is in one case they are including the OAuth c= lient >>>>> and in the other they are using a server based proxy. So they see it = as the >>>>> same. >>>>> > >>>>> > Perhaps it is perspective. >>>>> > >>>>> > On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki >>>> wrote: >>>>> > In this type of deployment, as far as OAuth is concerned, isn't the >>>>> backend web server a confidential client? Is there even anything uniq= ue to >>>>> this situation as far as OAuth security goes? >>>>> > >>>>> > I wouldn't have expected an Angular app that talks to its own serve= r >>>>> backend that's managing OAuth credentials to fall under the umbrella = of >>>>> this BCP. >>>>> > >>>>> > ---- >>>>> > Aaron Parecki >>>>> > aaronparecki.com >>>>> > >>>>> > >>>>> > >>>>> > On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt < >>>>> torsten@lodderstedt.net> wrote: >>>>> > the UI is rendered in the frontend, UI control flow is in the >>>>> frontend... just a different cut through the web app=E2=80=99s layeri= ng >>>>> > >>>>> > All Angular apps I have seen so far work that way. And it makes a >>>>> lot of sense to me. The backend can aggregate and optimize access to = the >>>>> underlying services without the need to fully expose them. >>>>> > >>>>> > Am 02.12.2018 um 00:44 schrieb John Bradley : >>>>> > >>>>> >> How is that different from a regular server client with a web >>>>> interface if the backed is doing the API calls to the RS? >>>>> >> >>>>> >> >>>>> >> >>>>> >> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: >>>>> >>> I forgot to mention another (architectural) option: split an >>>>> application into frontend provided by JS in the browser and a backend= , >>>>> which takes care of the business logic and handles tokens and API acc= ess. >>>>> Replay detection at the interface between SPA and backend can utilize >>>>> standard web techniques (see OWASP). The backend in turn can use mTLS= for >>>>> sender constraining. >>>>> >>> >>>>> >>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt < >>>>> torsten@lodderstedt.net>: >>>>> >>> >>>>> >>>> IMHO the best mechanism at hand currently to cope with token >>>>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay >>>>> detection) and issue short living and privilege restricted access tok= ens. >>>>> >>>> >>>>> >>>> Sender constrained access tokens in SPAs need adoption of token >>>>> binding or alternative mechanism. mtls could potentially work in >>>>> deployments with automated cert rollout but browser UX and interplay = with >>>>> fetch needs some work. We potentially must consider to warm up applic= ation >>>>> level PoP mechanisms in conjunction with web crypto. Another path to = be >>>>> evaluated could be web auth. >>>>> >>>> >>>>> >>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig < >>>>> Hannes.Tschofenig@arm.com>: >>>>> >>>> >>>>> >>>>> I share the concern Brian has, which is also the conclusion I >>>>> came up with in my other email sent a few minutes ago. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: OAuth On Behalf Of Brian Campbel= l >>>>> >>>>> Sent: Friday, November 30, 2018 11:43 PM >>>>> >>>>> To: Torsten Lodderstedt >>>>> >>>>> Cc: oauth >>>>> >>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-= 00 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt < >>>>> torsten@lodderstedt.net> wrote: >>>>> >>>>> >>>>> >>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen < >>>>> brockallen@gmail.com>: >>>>> >>>>> > >>>>> >>>>> > So you mean at the resource server ensuring the token was >>>>> really issued to the client? Isn't that an inherent limitation of all >>>>> bearer tokens (modulo HTTP token binding, which is still some time of= f)? >>>>> >>>>> >>>>> >>>>> Sure. That=E2=80=99s why the Security BCP recommends use of TLS= -based >>>>> methods for sender constraining access tokens ( >>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#secti= on-2..2). >>>>> Token Binding for OAuth ( >>>>> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as >>>>> well as Mutual TLS for OAuth ( >>>>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options >>>>> available. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Unfortunately even when using the token endpoint, for SPA / >>>>> in-browser client applications, the potential mechanisms for >>>>> sender/key-constraining access tokens don't work very well or maybe d= on't >>>>> work at all. So I don't know that the recommendation is very realisti= c. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 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 prohibi= ted.. >>>>> If you have received this communication in error, please notify the s= ender >>>>> immediately by e-mail and delete the message and any file attachments= from >>>>> your computer. Thank you. >>>>> >>>>> >>>>> >>>>> IMPORTANT NOTICE: The contents of this email and any attachment= s >>>>> are confidential and may also be privileged. If you are not the inten= ded >>>>> recipient, please notify the sender immediately and do not disclose t= he >>>>> contents to any other person, use it for any purpose, or store or cop= y the >>>>> information in any medium. Thank you. >>>>> >>>> _______________________________________________ >>>>> >>>> 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 >>>>> >>>>> -- >>>> ---- >>>> Aaron Parecki >>>> aaronparecki.com >>>> @aaronpk >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- ---- Aaron Parecki aaronparecki.com @aaronpk --0000000000009d80e9057c50422e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's a very good point, I will see what I can = adapt from your description below for the spec. I do think it's worth e= mphasizing like you say.=C2=A0

Aaron


On Wed, Dec 5, 2018 at 7:15 PM Vittorio Berto= cci <Vittorio@auth0.com> wr= ote:
As mentioned = during IIW when this pattern was borught up: I think readers should receive= a stronger warning about the known challenges of that approach. Namely, as= suming that the developer wants to perform API calls from the browser:
= - Making the app backend the true client for the AS is tantamount to making= the app backend act as an AS for the JS running in the browser. The traffi= c between the JS layer and its backend for getting the initial token, renew= ing tokens, doing stepup auth and the like is not codified in any normative= document- hence it's not threat modeled. Leaving it as exercise to the= reader without proper warnings seems reckless
- Various importan= t providers indicate in the access token whether it was issued to a confide= ntial client or to a public one- and resources can rely on that to make aut= horization decisions (for example allowing access only to specific confiden= tial clients). By having an app backend to act as a proxy and pass those ac= cess tokens along to the JS layer, a resource might be fooled into thinking= that the caller is a confidential client, while in fact the client is just= a public client. Implementers choosing to use the proxy pattern should eit= her ensure resources refrain from using the nature of the client (as certif= ied by the access token) as input to authorization decisions, or should hav= e a way to signal to the AS that the tokens requested are meant to be actua= lly used by a weaker client hence should not mark the ATs as issued to a co= nfidential client.=C2=A0

I am not suggesting that = the document should necessarily contain this level of detail, but I do thin= k we should hint at those two challenges so that readers have a better idea= of the risks inherent to the approach with today's tools.
Related to this: if we think this pattern is common, we should= consider producing formal guidance on how to handle the necessary exchange= s- or we'll end up with a babel of proprietary ways of connecting the J= S frontent to the backend, with huge waste of cycles across the industry.

On Tue, Dec 4, 20= 18 at 10:57 AM Aaron Parecki <aaron@parecki.com> wrote:
Thanks for all the discussion = here. I've added the paragraph described to the document in a new "= ;Architectural Considerations" section. Currently in the GitHub source= code but not yet published as a new IETF draft, which will be coming short= ly.=C2=A0https://github.com/aaronpk/oauth-browser-based-apps


On Mon, Dec 3, 2018 at 9:53 AM Brian Camp= bell <bc= ampbell@pingidentity.com> wrote:
I would also like to see someth= ing to that effect. I feel that sometimes because SPAs use APIs, there'= s an unchallenged assumption that OAuth also has to be used with the in-bro= wser code accessing those APIs. Even if the details are out of scope for th= is document, some text like the below at least gives a nod to the possibili= ty of different approaches, which may ultimately be more secure and easier = to mange. https://tools.ietf.org/html/= draft-parecki-oauth-browser-based-apps-00#section-5.1 kinda does this t= oo but I'm a +1 for a little something along the lines of what is being= discussed recently in this thread.



On Mon, Dec 3, 2018 at 7:5= 7 AM Aaron Parecki <aaron@parecki.com> wrote:
I support adding something to th= at effect, but would like to make it clear that this removes the app from b= eing covered under this BCP. How about:

---
Implementations MAY consid= er moving the authorization code exchange and handling of access and refres= h tokens to a backend component in order to avoid the risks inherent in han= dling access tokens from a purely browser based app. In this case, the back= end component can be a confidential client and can be secured accordingly.<= br>
Security of the connection between code running in the browser and t= his backend component is assumed to utilize browser-level protection mechan= isms. Details are out of scope of this document.=C2=A0
---




On Mon, Dec 3, 2018 at 3:15 AM Torsten Lodderstedt <torsten@lodderstedt.net>= ; wrote:
Interes= ting. Even on this list people felt to see that moving some logic to a back= end could solve some of the problems raised. What I want to convey is: the = solution to a problem in the OAuth space does not necessarily need to be fo= und on the OAuth protocol level. That=E2=80=99s a best practice in the same= way as some OAuth pattern.

What I=E2=80=99m suggesting is a statement in the BCP like

=E2=80=94
Implementations MAY consider to move authorization code exchange and handli= ng of access and refresh tokens to a backend component in order to fulfill = their security goals.

Security of the connection between code running in the browser and this bac= kend component is assumed to utilize browser-level protection mechanisms. D= etails are out of scope of this document.
=E2=80=94

> Am 03.12.2018 um 11:19 schrieb John Bradley <ve7jtb@ve7jtb.com>:
>
> This is my point.=C2=A0
>
> From a security perspective we have a server based confidential client= ...=C2=A0 =C2=A0The fact that it has a angular or other JS UI protected by = a cookie seems to not be especially relucent to OAuth.=C2=A0
>
> Perhaps from the developer point of view they have a JS SPA and the on= ly difference to them is in one case they are including the OAuth client an= d in the other they are using a server based proxy. So they see it as the s= ame.
>
> Perhaps it is perspective.
>
> On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki <aaron@parecki.com wrote:
> In this type of deployment, as far as OAuth is concerned, isn't th= e backend web server a confidential client? Is there even anything unique t= o this situation as far as OAuth security goes?
>
> I wouldn't have expected an Angular app that talks to its own serv= er backend that's managing OAuth credentials to fall under the umbrella= of this BCP.
>
> ----
> Aaron Parecki
> aaronparecki.com
>
>
>
> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt <torsten@lodderstedt.net&= gt; wrote:
> the UI is rendered in the frontend, UI control flow is in the frontend= ... just a different cut through the web app=E2=80=99s layering
>
> All Angular apps I have seen so far work that way. And it makes a lot = of sense to me. The backend can aggregate and optimize access to the underl= ying services without the need to fully expose them.
>
> Am 02.12.2018 um 00:44 schrieb John Bradley <ve7jtb@ve7jtb.com>:
>
>> How is that different from a regular server client with a web inte= rface if the backed is doing the API calls to the RS?
>>
>>
>>
>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>> I forgot to mention another (architectural) option: split an a= pplication into frontend provided by JS in the browser and a backend, which= takes care of the business logic and handles tokens and API access. Replay= detection at the interface between SPA and backend can utilize standard we= b techniques (see OWASP). The backend in turn can use mTLS for sender const= raining.
>>>
>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <torsten@lodderstedt.n= et>:
>>>
>>>> IMHO the best mechanism at hand currently to cope with tok= en leakage/replay in SPAs is to use refresh tokens (rotating w/ replay dete= ction) and issue short living and privilege restricted access tokens.
>>>>
>>>> Sender constrained access tokens in SPAs need adoption of = token binding or alternative mechanism. mtls could potentially work in depl= oyments with automated cert rollout but browser UX and interplay with fetch= needs some work. We potentially must consider to warm up application level= PoP mechanisms in conjunction with web crypto. Another path to be evaluate= d could be web auth.
>>>>
>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <Hannes.Tschofenig= @arm.com>:
>>>>
>>>>> I share the concern Brian has, which is also the concl= usion I came up with in my other email sent a few minutes ago.
>>>>>
>>>>>=C2=A0
>>>>>
>>>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Cam= pbell
>>>>> Sent: Friday, November 30, 2018 11:43 PM
>>>>> To: Torsten Lodderstedt <torsten@lodderstedt.net>
>>>>> Cc: oauth <oauth@ietf.org>
>>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-ba= sed-apps-00
>>>>>
>>>>>=C2=A0
>>>>>
>>>>>=C2=A0
>>>>>
>>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt &l= t;torsten@lodd= erstedt.net> wrote:
>>>>>
>>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.co= m>:
>>>>> >
>>>>> > So you mean at the resource server ensuring the t= oken was really issued to the client? Isn't that an inherent limitation= of all bearer tokens (modulo HTTP token binding, which is still some time = off)?
>>>>>
>>>>> Sure. That=E2=80=99s why the Security BCP recommends u= se of TLS-based methods for sender constraining access tokens (https://tools.ietf.org/html/draft-ie= tf-oauth-security-topics-09#section-2..2). Token Binding for OAuth (https://tools.ietf.org/html/draft-ietf-oa= uth-token-binding-08) as well as Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are t= he options available.
>>>>>
>>>>>=C2=A0
>>>>>
>>>>> Unfortunately even when using the token endpoint, for = SPA / in-browser client applications, the potential mechanisms for sender/k= ey-constraining access tokens don't work very well or maybe don't w= ork at all. So I don't know that the recommendation is very realistic.<= br> >>>>>
>>>>>=C2=A0
>>>>>
>>>>>
>>>>> CONFIDENTIALITY NOTICE: This email may contain confide= ntial and privileged material for the sole use of the intended recipient(s)= ... Any review, use, distribution or disclosure by others is strictly prohi= bited..=C2=A0 If you have received this communication in error, please noti= fy the sender immediately by e-mail and delete the message and any file att= achments from your computer. Thank you.
>>>>>
>>>>> IMPORTANT NOTICE: The contents of this email and any a= ttachments are confidential and may also be privileged. If you are not the = intended recipient, please notify the sender immediately and do not disclos= e the contents to any other person, use it for any purpose, or store or cop= y the information in any medium. Thank you.
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oa= uth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>>
>>> OAuth@ietf= ...org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> > _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

--
----
Aaron Parecki
=
_______________________________________________
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 th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
----
Aaron Parecki
<= div>aaronparecki.com<= /a>

--0000000000009d80e9057c50422e-- From nobody Wed Dec 5 17:32:10 2018 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 0FCBF130EFF for ; Wed, 5 Dec 2018 17:32:08 -0800 (PST) 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_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=auth0.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 u70rq1Furspq for ; Wed, 5 Dec 2018 17:32:02 -0800 (PST) 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 27818130F0A for ; Wed, 5 Dec 2018 17:32:00 -0800 (PST) Received: by mail-lf1-x144.google.com with SMTP id i26so16230221lfc.0 for ; Wed, 05 Dec 2018 17:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=FGACXNItXpDVAcY542485ItAbjU0XfcKKIwAWvrHll8=; b=aGN8uFesn2RnFqnY2eOvF3NUkhhoOjtGtagMIvH6/8dV3eQOyObQgIgsMGxKMMR8JP w8cskrKwz53KQW/ubO4EodNe6GkCOdGn6qZnP0MnoZ1sCEyH6uc2MQpjm5MgQfi2MvVo e14YztE7ATeQ0Xgg0DntPIyQn6kLk1o8QZxV54FLKy2LXR6xwHcoxo7Figp3cbfYAdY3 IseqRLwzqITomb+rBuGahJHBUexa7yGoF/1gA5R0SGwxbZ1NrwncAIH0+HuHDS8Ov3Mq ZWkcWReTClebYgn8sCfKKihgM/rBoZfRU42jrlwfPUTOkTjZVe6xDiJjjIfGCIVb43p1 nEZA== 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:reply-to :from:date:message-id:subject:to:cc; bh=FGACXNItXpDVAcY542485ItAbjU0XfcKKIwAWvrHll8=; b=IWnFvC/Aky8Sv7k5fiCeZRHU4ju/aDdA1fUmNaDprMomFXNwgOBQIX209/r4ZD6dQ9 eXjbuIN+N26vN1d7bAYe+4gT8xyzuEoFYi6NpqQem6k1bRj4QauxMzt7aCvRlHMBpeNp qg3/tf1MDYJkwFreZL8nhd7qXwES6urZQyuLszHX9FZiM5b+MPomCzHORmfFNgFOwt3R kpg/79JwZWNN1vXiPFs9Biw7TBlwJ/e5Nv7eSv6JwBt62Bv2m12EexCkiNJKS/8R9jeb utQcmtknyI2iDVO8xchsYb9oxRe8A0vbuBowVd3EcA4+3AYTIJ9zhumriT6nA43NTo2m 4Lcw== X-Gm-Message-State: AA+aEWb4zfjs7aXu5yB8fDq6vw5wwlhQB18KNgeZmAUHKp9kq+OckZ24 uPI0kmbkmjXl2vPSo53D1vVrwHZYFXvujucqzvrB1g== X-Google-Smtp-Source: AFSGD/U43RYnIG7WRzx7Yt2Ya9f7KqHgXP1vm3YUSkOvt/gKLCi+ZKas0scleBmzBSJx6zNUQQchKVbXGyW0S9cyDp0= X-Received: by 2002:a19:ae03:: with SMTP id f3mr16358060lfc.86.1544059918178; Wed, 05 Dec 2018 17:31:58 -0800 (PST) MIME-Version: 1.0 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> In-Reply-To: <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> Reply-To: Vittorio@auth0.com From: Vittorio Bertocci Date: Wed, 5 Dec 2018 17:31:46 -0800 Message-ID: To: Torsten Lodderstedt Cc: Tomek Stojecki , Daniel Fett , Brian Campbell , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000ef718b057c5076be" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 06 Dec 2018 01:32:08 -0000 --000000000000ef718b057c5076be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Torsten/Tomek, Can I ask a clarification on the below? Torsten, you mentioned that an AS doesn't need to issue a RT- the browser code can just repeat an authorization request. Did I get it right? But in order to preserve the user experience, that cannot really happen as a full page redirect; right? That wouldn't fly for any kind of background update, or for retrieving new ATs for different resources based on the same session. So would we now use a hidden frame to retrieve a code in the same way in which we used fragments to get new ATs? Thx V. On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt wrote: > Hi Tomek, > > > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki : > > > > Hi Torsten, > > > > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > > > > > >> So if I am putting myself in the shoes of somebody who sets out to d= o > that - switch an existing SPA client (no backend) > > > > > I would like to ask you a question: how many SPAs w/o a backend have > you seen in your projects? > > > > SPA (html+js) utilizing a 3rd party api that requires authorization? > > If you do have a backend, aren't you better of handling the token > request on the backend as pointed out here > > > https://github.com/aaronpk/oauth-browser-based-apps/blob/master/oauth-bro= wser-based-apps.md#javascript-app-with-a-backend-component > > I agree. > > > My point of putting (no backend) in parenthesis was to not derail this > discussion and of course it had the opposite effect. > > > > You know, I you says =E2=80=9Edon=E2=80=99t look at the green car=E2=80= =9C will cause everyone > looking for it :-) It asked just out of curiosity. > > > >> Is that fair or is that too much of a shortcut? I am familiar with > the specs you've referenced and have looked at them again, but dealing wi= th > a SPA, some of the recommendations are not feasible (can't authenticate t= he > client, > > > > > You could using dynamic registration (see other thread). The > protection would only differ from refresh token rotation if you would use > public key crypto for client authentication. > > > > Good point. How well is dynamic registration supported across AS? > > I leave that to the vendors :-) > > > > > >> confidentiality in storage? - not sure how to read that in the > context of a browser) > > > > > How do you ensure confidentiality of session cookies? > > > > All I am trying to say is that I think context is important here. So > when you point out these best practices, some of them will get people > confused as far as what it means in the browser based app scenario. > > That=E2=80=99s why we have the more general Security BCP and client-speci= fic BCPs, > like for native apps (https://tools.ietf.org/html/rfc8252) and the new > BCP for SPAs Aaron started to work on. > > > Maybe it is just me :) > > thanks for raising the question! We need this kind of input to govern the > development of our specs. > > kind regards, > Torsten. > > > > > > > > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > > > > > > > > Hi Tomek, > > > > > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki 40yahoo.com@dmarc.ietf.org>: > > > > > > > > I agree with Vittorio, Dominick et al. > > > > > > > >> I disagree. > > > > > > > >> Existing deployments that have not mitigated against the concerns > with implicit should be ripped up and updated. > > > > > > > > Yes, just like future deployments that will not mitigate against th= e > concerns of code in the browser should be a concern. > > > > > > I agree. That=E2=80=99s why I pointed point yesterday that the Securi= ty BCP > also defines obligations for clients using code. > > > > > > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2= .1 > > > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2= .1.1 > > > > > > > > > > > Can somebody on the other side of the argument (and I hate to make > it sound like there are two sides, because we're on the same side as far = as > Implicit's AT in front-channel is a real issue) address Dominic's comment= : > > > > > > > >> Also - simply saying =E2=80=9Cimplicit is evil - switch to code=E2= =80=9D means for > most people also using refresh token - so we are treating access tokens i= n > the URL with refresh tokens in session storage (over simplified - but you > get the idea). > > > > > > > > Does the group agree|disagree that a recommendation to switch to > code should be made as long as it is followed by an explanation and > guidance on what to do with RTs? The ideas that were floated around > > > > - Token bound RTs (even though it was pointed out that token bindin= g > is still considered an emerging standard). So should the recommendation > than say "switch to code and MUST use token bound RTs"? > > > > - Have AS not release RTs. "Switch to code and DO NOT request RTs"? > Or switch to code and configure AT to not release RTs for this type of > client (not sure what that even looks like in a form of a 3rd party > clients)? > > > > - RTs short lived and bound to a session - "Switch to code as long > as AT can bind and revoke RTs when you log out=E2=80=9C > > > > > > Basically, the AS does not need to issue refresh tokens. If the AS > does not issue refresh tokens, the integration pattern for SPAs does not > change (beside the code exchange). If the client needs a new access token= , > it will perform another authorization request. > > > > > > If it does, this adds another layer of security because it allows the > client to frequently obtain new access tokens, which can be short-lived a= nd > scope restricted. > > > > > > The refresh tokens should be replay protected by issuing new refresh > tokens with every refresh and detect replay for refresh tokens belonging = to > the same grant. > > > > > > The AS may additionally bind refresh tokens to AS sessions, but as it > was pointed out by Annabelle and others, there are some implications to b= e > understood and managed in that context. > > > > > > You may find more text about refresh tokens in the Security BCP > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3= .12 > > > > > > kind regards, > > > Torsten. > > > > > > > > > > > > > > Sorry if I have missed an important detail from the list above, > people who have proposed these ideas, feel free to clarify. > > > > > > > > > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt < > dick.hardt@gmail.com> wrote: > > > > > > > > I disagree. > > > > > > > > Existing deployments that have not mitigated against the concerns > with implicit should be ripped up and updated. > > > > > > > > For example, at one time, I think it was Instagram that had deploye= d > implicit because it was easier to do. Once the understood the security > implications, they changed the implementation. > > > > > > > > BCPs are rarely a response to a new threat, their are capturing Bes= t > Current Practices so that they become widely deployed. > > > > > > > > > > > > > > > > > > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > > > >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are > saying here. And that was kind of behind the comment I made, or tired to > make, about this in Bangkok, which was (more or less) that I don't think > the WG should be killing implicit outright but rather that it should begi= n > to recommend against it. > > > >> > > > >> I'm not exactly sure what that looks like in this document but > maybe toning down some of the scarier language a bit, favoring SHOULDs vs= . > MUSTs, and including language that helps a reader understand the > recommendations as being more considerations for new > applications/deployments than as a mandate to rip up existing ones. > > > >> > > > >> > > > >> > > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley > wrote: > > > >>> > > > >>> We just need to be sensitive to the spin on this. > > > >>> > > > >> > > > >> 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 fi= le > attachments from your computer. Thank > you._______________________________________________ > > > >> 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 > > --000000000000ef718b057c5076be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Torsten/Tomek,
Can I ask a clarification on the be= low?
Torsten, you mentioned that an AS doesn't need to issue = a RT- the browser code can just repeat an authorization request. Did I get = it right?
But in order to preserve the user experience, that cann= ot really happen as a full page redirect; right? That wouldn't fly for = any kind of background update, or for retrieving new ATs for different reso= urces based on the same session. So would we now use a hidden frame to retr= ieve a code in the same way in which we used fragments to get new ATs?
Thx
V.

On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
<= /div>
Hi Tomek,

> Am 05.12.2018 um 15:27 schrieb Tomek Stojecki <tstojecki@yahoo.com>:
>
> Hi Torsten,
>
> On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:
>
>
> >> So if I am putting myself in the shoes of somebody who sets o= ut to do that - switch an existing SPA client (no backend)
>
> > I would like to ask you a question: how many SPAs w/o a backend h= ave you seen in your projects?
>
> SPA (html+js) utilizing a 3rd party api that requires authorization? > If you do have a backend, aren't you better of handling the token = request on the backend as pointed out here
> https://github.com/aaronpk/oauth-browse= r-based-apps/blob/master/oauth-browser-based-apps.md#javascript-app-with-a-= backend-component

I agree.

> My point of putting (no backend) in parenthesis was to not derail this= discussion and of course it had the opposite effect.
>

You know, I you says =E2=80=9Edon=E2=80=99t look at the green car=E2=80=9C = will cause everyone looking for it :-) It asked just out of curiosity.

> >> Is that fair or is that too much of a shortcut? I am familiar= with the specs you've referenced and have looked at them again, but de= aling with a SPA, some of the recommendations are not feasible (can't a= uthenticate the client,
>
> > You could using dynamic registration (see other thread). The prot= ection would only differ from refresh token rotation if you would use publi= c key crypto for client authentication.
>
> Good point. How well is dynamic registration supported across AS?

I leave that to the vendors :-)

>
> >> confidentiality in storage? - not sure how to read that in th= e context of a browser)
>
> > How do you ensure confidentiality of session cookies?
>
> All I am trying to say is that I think context is important here. So w= hen you point out these best practices, some of them will get people confus= ed as far as what it means in the browser based app scenario.

That=E2=80=99s why we have the more general Security BCP and client-specifi= c BCPs, like for native apps (https://tools.ietf.org/html/rfc8252= ) and the new BCP for SPAs Aaron started to work on.

> Maybe it is just me :)

thanks for raising the question! We need this kind of input to govern the d= evelopment of our specs.

kind regards,
Torsten.

>
> >
> > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderste= dt <torsten= @lodderstedt.net> wrote:
> >
> >
> > Hi Tomek,
> >
> > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki <tstojecki= =3D40yahoo.= com@dmarc.ietf.org>:
> > >
> > > I agree with Vittorio, Dominick et al.
> > >
> > >> I disagree.
> > >
> > >> Existing deployments that have not mitigated against the= concerns with implicit should be ripped up and updated.
> > >
> > > Yes, just like future deployments that will not mitigate aga= inst the concerns of code in the browser should be a concern.
> >
> > I agree. That=E2=80=99s why I pointed point yesterday that the Se= curity BCP also defines obligations for clients using code.
> >
> > https://tools.i= etf.org/html/draft-ietf-oauth-security-topics-10#section-2.1
> > https://tools= .ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1.1
> >
> > >
> > > Can somebody on the other side of the argument (and I hate t= o make it sound like there are two sides, because we're on the same sid= e as far as Implicit's AT in front-channel is a real issue) address Dom= inic's comment:
> > >
> > >> Also - simply saying =E2=80=9Cimplicit is evil - switch = to code=E2=80=9D means for most people also using refresh token - so we are= treating access tokens in the URL with refresh tokens in session storage (= over simplified - but you get the idea).
> > >
> > > Does the group agree|disagree that a recommendation to switc= h to code should be made as long as it is followed by an explanation and gu= idance on what to do with RTs? The ideas that were floated around
> > > - Token bound RTs (even though it was pointed out that token= binding is still considered an emerging standard). So should the recommend= ation than say "switch to code and MUST use token bound RTs"?
> > > - Have AS not release RTs. "Switch to code and DO NOT r= equest RTs"? Or switch to code and configure AT to not release RTs for= this type of client (not sure what that even looks like in a form of a 3rd= party clients)?
> > > - RTs short lived and bound to a session - "Switch to c= ode as long as AT can bind and revoke RTs when you log out=E2=80=9C
> >
> > Basically, the AS does not need to issue refresh tokens. If the A= S does not issue refresh tokens, the integration pattern for SPAs does not = change (beside the code exchange). If the client needs a new access token, = it will perform another authorization request.=C2=A0
> >
> > If it does, this adds another layer of security because it allows= the client to frequently obtain new access tokens, which can be short-live= d and scope restricted.
> >
> > The refresh tokens should be replay protected by issuing new refr= esh tokens with every refresh and detect replay for refresh tokens belongin= g to the same grant.
> >
> > The AS may additionally bind refresh tokens to AS sessions, but a= s it was pointed out by Annabelle and others, there are some implications t= o be understood and managed in that context.
> >
> > You may find more text about refresh tokens in the Security BCP <= a href=3D"https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#s= ection-3.12" rel=3D"noreferrer" target=3D"_blank">https://tools.ietf.org/ht= ml/draft-ietf-oauth-security-topics-10#section-3.12
> >
> > kind regards,
> > Torsten.
> >
> >
> > >
> > > Sorry if I have missed an important detail from the list abo= ve, people who have proposed these ideas, feel free to clarify.
> >
> > >
> > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt &= lt;dick.hardt@gma= il.com> wrote:
> > >
> > > I disagree.
> > >
> > > Existing deployments that have not mitigated against the con= cerns with implicit should be ripped up and updated.
> > >
> > > For example, at one time, I think it was Instagram that had = deployed implicit because it was easier to do. Once the understood the secu= rity implications, they changed the implementation.
> > >
> > > BCPs are rarely a response to a new threat, their are captur= ing Best Current Practices so that they become widely deployed.
> > >
> > >
> > >
> > >
> > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell <bcampbell= =3D4= 0pingidentity.com@dmarc.ietf.org> wrote:
> > >> FWIW I'm somewhat sympathetic to what Vittorio, Domi= nick, etc. are saying here. And that was kind of behind the comment I made,= or tired to make, about this in Bangkok, which was (more or less) that I d= on't think the WG should be killing implicit outright but rather that i= t should begin to recommend against it.
> > >>
> > >> I'm not exactly sure what that looks like in this do= cument but maybe toning down some of the scarier language a bit, favoring S= HOULDs vs. MUSTs, and including language that helps a reader understand the= recommendations as being more considerations for new applications/deployme= nts than as a mandate to rip up existing ones.
> > >>
> > >>
> > >>
> > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley <ve7jtb@ve7jtb.com> w= rote:
> > >>>
> > >>> We just need to be sensitive to the spin on this.=C2= =A0
> > >>>
> > >>
> > >> CONFIDENTIALITY NOTICE: This email may contain confident= ial and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly prohibite= d...=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 attach= ments from your computer. Thank you._______________________________________= ________
> > >> OAuth mailing list
> > >> OAut= h@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/= oauth
> > >>
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ie= tf.org
> > > https://www.ietf.org/mailman/listinfo/oau= th
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ie= tf.org
> > > https://www.ietf.org/mailman/listinfo/oau= th
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/oauth=

--000000000000ef718b057c5076be-- From nobody Wed Dec 5 23:27:43 2018 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 9838E1310D5 for ; Wed, 5 Dec 2018 23:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, 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 eyoFm_7T3CSe for ; Wed, 5 Dec 2018 23:27:36 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) (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 BFA241310D2 for ; Wed, 5 Dec 2018 23:27:35 -0800 (PST) Received: from [91.13.153.47] (helo=[192.168.71.112]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gUo4J-0006Ln-Ij; Thu, 06 Dec 2018 08:27:31 +0100 Content-Type: multipart/signed; boundary=Apple-Mail-E21DDCB2-42DC-4A3A-8F2C-F8DBF0E716FA; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Thu, 6 Dec 2018 08:27:30 +0100 Cc: Tomek Stojecki , Daniel Fett , Brian Campbell , IETF oauth WG Content-Transfer-Encoding: 7bit Message-Id: <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> To: Vittorio@auth0.com X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 06 Dec 2018 07:27:42 -0000 --Apple-Mail-E21DDCB2-42DC-4A3A-8F2C-F8DBF0E716FA Content-Type: multipart/alternative; boundary=Apple-Mail-0793E251-366A-4C3A-8F40-4217CA312007 Content-Transfer-Encoding: 7bit --Apple-Mail-0793E251-366A-4C3A-8F40-4217CA312007 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci : >=20 > Hey Torsten/Tomek, > Can I ask a clarification on the below? > Torsten, you mentioned that an AS doesn't need to issue a RT- the browser c= ode can just repeat an authorization request. Did I get it right? > But in order to preserve the user experience, that cannot really happen as= a full page redirect; right? That wouldn't fly for any kind of background u= pdate, or for retrieving new ATs for different resources based on the same s= ession. So would we now use a hidden frame to retrieve a code in the same wa= y in which we used fragments to get new ATs? That=E2=80=99s what I meant. I also think the RT-based approach is better su= ited in terms of UX and security. > Thx > V. >=20 >> On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt wrote: >> Hi Tomek,=20 >>=20 >> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki : >> >=20 >> > Hi Torsten, >> >=20 >> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt <= torsten@lodderstedt.net> wrote: >> >=20 >> >=20 >> > >> So if I am putting myself in the shoes of somebody who sets out to d= o that - switch an existing SPA client (no backend) >> >=20 >> > > I would like to ask you a question: how many SPAs w/o a backend have y= ou seen in your projects? >> >=20 >> > SPA (html+js) utilizing a 3rd party api that requires authorization? >> > If you do have a backend, aren't you better of handling the token reque= st on the backend as pointed out here >> > https://github.com/aaronpk/oauth-browser-based-apps/blob/master/oauth-b= rowser-based-apps.md#javascript-app-with-a-backend-component >>=20 >> I agree.=20 >>=20 >> > My point of putting (no backend) in parenthesis was to not derail this d= iscussion and of course it had the opposite effect. >> >=20 >>=20 >> You know, I you says =E2=80=9Edon=E2=80=99t look at the green car=E2=80=9C= will cause everyone looking for it :-) It asked just out of curiosity.=20 >>=20 >> > >> Is that fair or is that too much of a shortcut? I am familiar with t= he specs you've referenced and have looked at them again, but dealing with a= SPA, some of the recommendations are not feasible (can't authenticate the c= lient,=20 >> >=20 >> > > You could using dynamic registration (see other thread). The protecti= on would only differ from refresh token rotation if you would use public key= crypto for client authentication. >> >=20 >> > Good point. How well is dynamic registration supported across AS?=20 >>=20 >> I leave that to the vendors :-) >>=20 >> >=20 >> > >> confidentiality in storage? - not sure how to read that in the conte= xt of a browser) >> >=20 >> > > How do you ensure confidentiality of session cookies? >> >=20 >> > All I am trying to say is that I think context is important here. So wh= en you point out these best practices, some of them will get people confused= as far as what it means in the browser based app scenario. >>=20 >> That=E2=80=99s why we have the more general Security BCP and client-speci= fic BCPs, like for native apps (https://tools.ietf.org/html/rfc8252) and the= new BCP for SPAs Aaron started to work on. >>=20 >> > Maybe it is just me :) >>=20 >> thanks for raising the question! We need this kind of input to govern the= development of our specs. >>=20 >> kind regards, >> Torsten.=20 >>=20 >> >=20 >> > >=20 >> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderstedt <= torsten@lodderstedt.net> wrote: >> > >=20 >> > >=20 >> > > Hi Tomek, >> > >=20 >> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki : >> > > >=20 >> > > > I agree with Vittorio, Dominick et al.=20 >> > > >=20 >> > > >> I disagree.=20 >> > > >=20 >> > > >> Existing deployments that have not mitigated against the concerns w= ith implicit should be ripped up and updated. >> > > >=20 >> > > > Yes, just like future deployments that will not mitigate against th= e concerns of code in the browser should be a concern. >> > >=20 >> > > I agree. That=E2=80=99s why I pointed point yesterday that the Securi= ty BCP also defines obligations for clients using code.=20 >> > >=20 >> > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#secti= on-2.1 >> > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#secti= on-2.1.1 >> > >=20 >> > > >=20 >> > > > Can somebody on the other side of the argument (and I hate to make i= t sound like there are two sides, because we're on the same side as far as I= mplicit's AT in front-channel is a real issue) address Dominic's comment:=20= >> > > >=20 >> > > >> Also - simply saying =E2=80=9Cimplicit is evil - switch to code=E2= =80=9D means for most people also using refresh token - so we are treating a= ccess tokens in the URL with refresh tokens in session storage (over simplif= ied - but you get the idea). >> > > >=20 >> > > > Does the group agree|disagree that a recommendation to switch to co= de should be made as long as it is followed by an explanation and guidance o= n what to do with RTs? The ideas that were floated around=20 >> > > > - Token bound RTs (even though it was pointed out that token bindin= g is still considered an emerging standard). So should the recommendation th= an say "switch to code and MUST use token bound RTs"? >> > > > - Have AS not release RTs. "Switch to code and DO NOT request RTs"?= Or switch to code and configure AT to not release RTs for this type of clie= nt (not sure what that even looks like in a form of a 3rd party clients)? >> > > > - RTs short lived and bound to a session - "Switch to code as long a= s AT can bind and revoke RTs when you log out=E2=80=9C >> > >=20 >> > > Basically, the AS does not need to issue refresh tokens. If the AS do= es not issue refresh tokens, the integration pattern for SPAs does not chang= e (beside the code exchange). If the client needs a new access token, it wil= l perform another authorization request. =20 >> > >=20 >> > > If it does, this adds another layer of security because it allows the= client to frequently obtain new access tokens, which can be short-lived and= scope restricted.=20 >> > >=20 >> > > The refresh tokens should be replay protected by issuing new refresh t= okens with every refresh and detect replay for refresh tokens belonging to t= he same grant.=20 >> > >=20 >> > > The AS may additionally bind refresh tokens to AS sessions, but as it= was pointed out by Annabelle and others, there are some implications to be u= nderstood and managed in that context. >> > >=20 >> > > You may find more text about refresh tokens in the Security BCP https= ://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.12 >> > >=20 >> > > kind regards, >> > > Torsten. >> > >=20 >> > >=20 >> > > >=20 >> > > > Sorry if I have missed an important detail from the list above, peo= ple who have proposed these ideas, feel free to clarify.=20 >> > >=20 >> > > >=20 >> > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt wrote:=20 >> > > >=20 >> > > > I disagree.=20 >> > > >=20 >> > > > Existing deployments that have not mitigated against the concerns w= ith implicit should be ripped up and updated. >> > > >=20 >> > > > For example, at one time, I think it was Instagram that had deploye= d implicit because it was easier to do. Once the understood the security imp= lications, they changed the implementation.=20 >> > > >=20 >> > > > BCPs are rarely a response to a new threat, their are capturing Bes= t Current Practices so that they become widely deployed. >> > > >=20 >> > > >=20 >> > > >=20 >> > > >=20 >> > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell wrote: >> > > >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are= saying here. And that was kind of behind the comment I made, or tired to ma= ke, about this in Bangkok, which was (more or less) that I don't think the W= G should be killing implicit outright but rather that it should begin to rec= ommend against it.=20 >> > > >>=20 >> > > >> I'm not exactly sure what that looks like in this document but may= be toning down some of the scarier language a bit, favoring SHOULDs vs. MUST= s, and including language that helps a reader understand the recommendations= as being more considerations for new applications/deployments than as a man= date to rip up existing ones.=20 >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley wr= ote: >> > > >>>=20 >> > > >>> We just need to be sensitive to the spin on this. =20 >> > > >>>=20 >> > > >>=20 >> > > >> 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... If you= have received this communication in error, please notify the sender immedia= tely by e-mail and delete the message and any file attachments from your com= puter. Thank you._______________________________________________ >> > > >> 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 >> > > _______________________________________________ >> > > OAuth mailing list >> > > OAuth@ietf.org >> > > https://www.ietf.org/mailman/listinfo/oauth >>=20 --Apple-Mail-0793E251-366A-4C3A-8F40-4217CA312007 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci= <vittorio.bertocci@auth0.= com>:

Hey Torsten/Tomek,
Can I ask a clarification on the below?
Torsten, you mentioned that an AS doesn't need to issue a RT- the bro= wser code can just repeat an authorization request. Did I get it right?
But in order to preserve the user experience, that cannot really happe= n as a full page redirect; right? That wouldn't fly for any kind of backgrou= nd update, or for retrieving new ATs for different resources based on the sa= me session. So would we now use a hidden frame to retrieve a code in the sam= e way in which we used fragments to get new ATs?

That=E2=80=99s what I meant. I also think the RT-based app= roach is better suited in terms of UX and security.

Thx
V.

On Wed, Dec 5, 2018 at 7:17= AM Torsten Lodderstedt <torst= en@lodderstedt.net> wrote:
Hi T= omek,

> Am 05.12.2018 um 15:27 schrieb Tomek Stojecki <tstojecki@yahoo.com>:
>
> Hi Torsten,
>
> On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt &= lt;torsten@lodd= erstedt.net> wrote:
>
>
> >> So if I am putting myself in the shoes of somebody who sets ou= t to do that - switch an existing SPA client (no backend)
>
> > I would like to ask you a question: how many SPAs w/o a backend ha= ve you seen in your projects?
>
> SPA (html+js) utilizing a 3rd party api that requires authorization? > If you do have a backend, aren't you better of handling the token reque= st on the backend as pointed out here
> https://github.com/aaronpk/oauth-browser-b= ased-apps/blob/master/oauth-browser-based-apps.md#javascript-app-with-a-back= end-component

I agree.

> My point of putting (no backend) in parenthesis was to not derail this d= iscussion and of course it had the opposite effect.
>

You know, I you says =E2=80=9Edon=E2=80=99t look at the green car=E2=80=9C w= ill cause everyone looking for it :-) It asked just out of curiosity.

> >> Is that fair or is that too much of a shortcut? I am familiar w= ith the specs you've referenced and have looked at them again, but dealing w= ith a SPA, some of the recommendations are not feasible (can't authenticate t= he client,
>
> > You could using dynamic registration (see other thread). The prote= ction would only differ from refresh token rotation if you would use public k= ey crypto for client authentication.
>
> Good point. How well is dynamic registration supported across AS?

I leave that to the vendors :-)

>
> >> confidentiality in storage? - not sure how to read that in the= context of a browser)
>
> > How do you ensure confidentiality of session cookies?
>
> All I am trying to say is that I think context is important here. So wh= en you point out these best practices, some of them will get people confused= as far as what it means in the browser based app scenario.

That=E2=80=99s why we have the more general Security BCP and client-specific= BCPs, like for native apps (https://tools.ietf.org/html/rfc8252) and the new BCP for SPAs Aaron started to work on.

> Maybe it is just me :)

thanks for raising the question! We need this kind of input to govern the de= velopment of our specs.

kind regards,
Torsten.

>
> >
> > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Loddersted= t <torsten@l= odderstedt.net> wrote:
> >
> >
> > Hi Tomek,
> >
> > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki <tstojecki=3D= 40yahoo.com@= dmarc.ietf.org>:
> > >
> > > I agree with Vittorio, Dominick et al.
> > >
> > >> I disagree.
> > >
> > >> Existing deployments that have not mitigated against the c= oncerns with implicit should be ripped up and updated.
> > >
> > > Yes, just like future deployments that will not mitigate agai= nst the concerns of code in the browser should be a concern.
> >
> > I agree. That=E2=80=99s why I pointed point yesterday that the Sec= urity BCP also defines obligations for clients using code.
> >
> > https://tools.iet= f.org/html/draft-ietf-oauth-security-topics-10#section-2.1
> > https://tools.i= etf.org/html/draft-ietf-oauth-security-topics-10#section-2.1.1
> >
> > >
> > > Can somebody on the other side of the argument (and I hate to= make it sound like there are two sides, because we're on the same side as f= ar as Implicit's AT in front-channel is a real issue) address Dominic's comm= ent:
> > >
> > >> Also - simply saying =E2=80=9Cimplicit is evil - switch t= o code=E2=80=9D means for most people also using refresh token - so we are t= reating access tokens in the URL with refresh tokens in session storage (ove= r simplified - but you get the idea).
> > >
> > > Does the group agree|disagree that a recommendation to switch= to code should be made as long as it is followed by an explanation and guid= ance on what to do with RTs? The ideas that were floated around
> > > - Token bound RTs (even though it was pointed out that token b= inding is still considered an emerging standard). So should the recommendati= on than say "switch to code and MUST use token bound RTs"?
> > > - Have AS not release RTs. "Switch to code and DO NOT request= RTs"? Or switch to code and configure AT to not release RTs for this type o= f client (not sure what that even looks like in a form of a 3rd party client= s)?
> > > - RTs short lived and bound to a session - "Switch to code as= long as AT can bind and revoke RTs when you log out=E2=80=9C
> >
> > Basically, the AS does not need to issue refresh tokens. If the AS= does not issue refresh tokens, the integration pattern for SPAs does not ch= ange (beside the code exchange). If the client needs a new access token, it w= ill perform another authorization request. 
> >
> > If it does, this adds another layer of security because it allows t= he client to frequently obtain new access tokens, which can be short-lived a= nd scope restricted.
> >
> > The refresh tokens should be replay protected by issuing new refre= sh tokens with every refresh and detect replay for refresh tokens belonging t= o the same grant.
> >
> > The AS may additionally bind refresh tokens to AS sessions, but as= it was pointed out by Annabelle and others, there are some implications to b= e understood and managed in that context.
> >
> > You may find more text about refresh tokens in the Security BCP https://tools.ietf.org/html/= draft-ietf-oauth-security-topics-10#section-3.12
> >
> > kind regards,
> > Torsten.
> >
> >
> > >
> > > Sorry if I have missed an important detail from the list abov= e, people who have proposed these ideas, feel free to clarify.
> >
> > >
> > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt &l= t;dick.hardt@gmail= .com> wrote:
> > >
> > > I disagree.
> > >
> > > Existing deployments that have not mitigated against the conc= erns with implicit should be ripped up and updated.
> > >
> > > For example, at one time, I think it was Instagram that had d= eployed implicit because it was easier to do. Once the understood the securi= ty implications, they changed the implementation.
> > >
> > > BCPs are rarely a response to a new threat, their are capturi= ng Best Current Practices so that they become widely deployed.
> > >
> > >
> > >
> > >
> > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell <bcampbell=3D= 40pin= gidentity.com@dmarc.ietf.org> wrote:
> > >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick,= etc. are saying here. And that was kind of behind the comment I made, or ti= red to make, about this in Bangkok, which was (more or less) that I don't th= ink the WG should be killing implicit outright but rather that it should beg= in to recommend against it.
> > >>
> > >> I'm not exactly sure what that looks like in this documen= t but maybe toning down some of the scarier language a bit, favoring SHOULDs= vs. MUSTs, and including language that helps a reader understand the recomm= endations as being more considerations for new applications/deployments than= as a mandate to rip up existing ones.
> > >>
> > >>
> > >>
> > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley <ve7jtb@ve7jtb.com> wrote= :
> > >>>
> > >>> We just need to be sensitive to the spin on this.&nbs= p;
> > >>>
> > >>
> > >> CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). An= y review, use, distribution or disclosure by others is strictly prohibited..= .  If you have received this communication in error, please notify the s= ender immediately by e-mail and delete the message and any file attachments f= rom your computer. Thank you._______________________________________________=
> > >> OAuth mailing list
> > >> OAuth= @ietf.org
> > >> https://www.ietf.org/mailman/listinfo/oa= uth
> > >>
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@iet= f.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@iet= f.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org=
> > https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-0793E251-366A-4C3A-8F40-4217CA312007-- --Apple-Mail-E21DDCB2-42DC-4A3A-8F2C-F8DBF0E716FA Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCocw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIFRTCCBC2gAwIBAgIQM9uaxqrCN5lrc/ED e5nwtDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE3MDEwOTAwMDAwMFoXDTE4MDEwOTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYX dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCu wZLNnLP0ur1JFb1K97kryfmVaGmU4ITocfeAzJ7XYOM6mQUVm3Rvve3bsbXteynpZTEeE169/tyT QBSm9hQ8IcGpUYlIhYX2FYChIUKBAAI6iH9wMVvPPU+wxjwSXs6Yi6zgle1jj9V2hIiEU/eHMBNs 0CDfYqn43y+1O4pPBuCeLMlLLNlNiuy22fcubBjXsdT5T29eWgy6zlT+WfgANnHTPLINKwDqC0/F dgmluBJOcdyRVnnN9HzSC4hnnfxjaqqyq3lVpJFJHahDMT8cROQpz+h09WGoGtcvK+dIWQI+sBdX Tuty/CQ+8dl5hW7hB1VbI7YchDiLbH2vmbtLAgMBAAGjggH1MIIB8TAfBgNVHSMEGDAWgBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU+eAeBXE5nsZKOL8hbhgkwGPTY8cwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy ZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCIGA1UdEQQbMBmB F3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IBAQACa57IeOLIvWpiB976 FVKwa4qWBy+MIB8bwlqrjy0LQiM/ykf+0aLi4v0IdV8udXeksOeODoza6+kQGntytllydI8t5Wyz 62SHC/4XshJhDJPh+U2SpVRvyd97BsI9wg3Xc5t+lTuuVeghqsQSmVCjhK7KZhWW5DFMs4UqblA4 wXgkEzD+uPLi33knsx2n00VTNCso8kNonYmv9NxNcVyMu81WYwGMrT3n1r2/X/WaJEd3UMGxOHUq 8GKAQ5Q0zG9Pm5S0Hr+2KgNmoEMOTwa92ej/GbJ7diJqxLsmAxESrlZxeqlYa7mQwVkwY8S/I8d4 Fl6rHHdqZ/giZWdnpa+DMYID0DCCA8wCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMjA2MDcyNzMxWjAvBgkqhkiG 9w0BCQQxIgQgVzsgnV4EUUoRU8/gncE4dcLfC/Wbo86t6o8i0PZ/9CYwgcEGCSsGAQQBgjcQBDGB szCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3 mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAK+F qAJKQ1liwEgMlULBuLRgq/M5qbmJoY6gTJyADkzsqc+X2QuKfXXhN/ikMt2D7ValpsOyu3kGrEgx RJSCI9kjBv419lRkyeW/eXwxi7liKUzgG+efBhbPHGMkTBYDoVHN4yfV+0FKtWxFNS2E+8jXpV/5 ej/Hz9widwvVPF90wjWr9vK0sXfnFCIhly03gOpNJLksxE4Gp++IcCrWgO2YQiE9QYJ654lSweab hQYvwC0lMTNLrQ3HdHAWhtOUHi6abw2T1ITIqZSzawHooYbDsWZ9AO/ez0fX4HYwtXX/eX0+n1Ea 473H23p6t7CyyaLeQYKUW5EODTySINqYVaMAAAAAAAA= --Apple-Mail-E21DDCB2-42DC-4A3A-8F2C-F8DBF0E716FA-- From nobody Wed Dec 5 23:40:52 2018 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 812CE1310FF for ; Wed, 5 Dec 2018 23:40:50 -0800 (PST) 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_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=auth0.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 JI9mAwWQn9xO for ; Wed, 5 Dec 2018 23:40:45 -0800 (PST) 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 93F58131103 for ; Wed, 5 Dec 2018 23:40:44 -0800 (PST) Received: by mail-lj1-x241.google.com with SMTP id g11-v6so20768091ljk.3 for ; Wed, 05 Dec 2018 23:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ciX1tl53g5iOgJaXnP8uH782Rculf/kWJ/DZyufSL8s=; b=VoTgRMV7R7pnjOqypoMc1Yf9BO9Zg8HwoFHi0IIWZiu5vYMWGbUepak77g1heegLTI 5Er5h5at6QGXhopnZUpZzj2dwxNGiPZG/8GxAzn3wkDrJYbm6qvA1qlIL0F95Dnm8l2h zqvZ2nwYJHI3YZUcH+p1Jhsbsi7O2RitTYXwEVr6pNGlN8lmKxlMe8niicJT7B79SVWR nrbpHk8a6ZYhJ6qOKvoeuGV+/R67Mz5t/Fmz+Fu1vwWKf6R5RiX2sYQUcuRozY+j4U1S puLsn39DKICANpLpkSoDaL3qs49ruEAV86rm6ze3hcrUDIbHf9dBLsytH7szfyacfO08 mSvw== 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=ciX1tl53g5iOgJaXnP8uH782Rculf/kWJ/DZyufSL8s=; b=pD1wBJ3NJMicKqGDY4u6f4Vv09EDDv7WDiKsgchCZsrH2m7Y7oEBp0Z7WRujcNWJOK QZPscLY/kM+xVzJb73sf/lfgVfNZEtWURFJcs9KgQef2NW/TvjabM50jJ5KdoVjSZWk7 lCVhT/gRyJWeI8TDKj8Yu+hjCHDqVH2VIAFer3qmpGwyi3wpFo7z8VIy0rDy2ll6DemI 3Uf7rtjJePuLLzDL/0fDzrIPmNu/u6M0mlcDL/0C4cIeTeaMkEielxXnJ8gK9JXlRxbS PMlcP3d7285QgKtcMW8qs4wDmUgyngAQ2YpYPeKQvZCJ4Y0XoL9Lkns1Fs0Zf4383Uog Tx7Q== X-Gm-Message-State: AA+aEWYf8/K0u9yoymmTEa7L08VI7LtZu6C8KWMnKOw9jlOyAE9u/9P0 P4weIsIIt9VDZWkiOMWJ21VFT7QGyxFYYpEqQCfe2g== X-Google-Smtp-Source: AFSGD/W6ONCErCBZPwtmzXbSp8FT3SsZX3xa+ga5VscJVSO8ezGvrwO1uB9PdsuylJynpxJVO0ItrqJsuji4ZK5AoN8= X-Received: by 2002:a2e:21a9:: with SMTP id h41-v6mr17297893lji.103.1544082042336; Wed, 05 Dec 2018 23:40:42 -0800 (PST) MIME-Version: 1.0 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> In-Reply-To: <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> From: Vittorio Bertocci Date: Wed, 5 Dec 2018 23:40:31 -0800 Message-ID: To: Torsten Lodderstedt Cc: Brian Campbell , Daniel Fett , IETF oauth WG , Tomek Stojecki Content-Type: multipart/alternative; boundary="000000000000a34d5f057c559d5c" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 06 Dec 2018 07:40:50 -0000 --000000000000a34d5f057c559d5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you! On the RT, more questions: - where would you save the RT? Iam thinking of the no-backend case in particular. There=E2=80=99s a lot of heartburn in the community on where to= save access tokens already, given the larger scope of refresh tokens I would expect objections there would be exacerbated. The user experience bar (number of prompts, full page redirects) should be the one afforded by implicit leveraging AS sessions via persistent cookies. - how would we advise developers about handling distributed sign out? If the session cookie with the AS is no longer the only artifact representing the effective session, it looks like we should be prescriptive on what signals an app should listen for (OIDC checkSession?) and what the expected actions are (e.g. remove the cached RTs). I realize this isn=E2=80=99t stri= ctly OAuth2, but it remains an important difference in end to end scenarios people use implicit for today Thx V. On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt wrote: > > > Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci < > vittorio.bertocci@auth0.com>: > > Hey Torsten/Tomek, > Can I ask a clarification on the below? > Torsten, you mentioned that an AS doesn't need to issue a RT- the browser > code can just repeat an authorization request. Did I get it right? > But in order to preserve the user experience, that cannot really happen a= s > a full page redirect; right? That wouldn't fly for any kind of background > update, or for retrieving new ATs for different resources based on the sa= me > session. So would we now use a hidden frame to retrieve a code in the sam= e > way in which we used fragments to get new ATs? > > > That=E2=80=99s what I meant. I also think the RT-based approach is better= suited > in terms of UX and security. > > Thx > V. > > On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi Tomek, >> >> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki : >> > >> > Hi Torsten, >> > >> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt = < >> torsten@lodderstedt.net> wrote: >> > >> > >> > >> So if I am putting myself in the shoes of somebody who sets out to >> do that - switch an existing SPA client (no backend) >> > >> > > I would like to ask you a question: how many SPAs w/o a backend have >> you seen in your projects? >> > >> > SPA (html+js) utilizing a 3rd party api that requires authorization? >> > If you do have a backend, aren't you better of handling the token >> request on the backend as pointed out here >> > >> https://github.com/aaronpk/oauth-browser-based-apps/blob/master/oauth-br= owser-based-apps.md#javascript-app-with-a-backend-component >> >> I agree. >> >> > My point of putting (no backend) in parenthesis was to not derail this >> discussion and of course it had the opposite effect. >> > >> >> You know, I you says =E2=80=9Edon=E2=80=99t look at the green car=E2=80= =9C will cause everyone >> looking for it :-) It asked just out of curiosity. >> >> > >> Is that fair or is that too much of a shortcut? I am familiar with >> the specs you've referenced and have looked at them again, but dealing w= ith >> a SPA, some of the recommendations are not feasible (can't authenticate = the >> client, >> > >> > > You could using dynamic registration (see other thread). The >> protection would only differ from refresh token rotation if you would us= e >> public key crypto for client authentication. >> > >> > Good point. How well is dynamic registration supported across AS? >> >> I leave that to the vendors :-) >> >> > >> > >> confidentiality in storage? - not sure how to read that in the >> context of a browser) >> > >> > > How do you ensure confidentiality of session cookies? >> > >> > All I am trying to say is that I think context is important here. So >> when you point out these best practices, some of them will get people >> confused as far as what it means in the browser based app scenario. >> >> That=E2=80=99s why we have the more general Security BCP and client-spec= ific >> BCPs, like for native apps (https://tools.ietf.org/html/rfc8252) and the >> new BCP for SPAs Aaron started to work on. >> >> > Maybe it is just me :) >> >> thanks for raising the question! We need this kind of input to govern th= e >> development of our specs. >> >> kind regards, >> Torsten. >> >> > >> > > >> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderstedt = < >> torsten@lodderstedt.net> wrote: >> > > >> > > >> > > Hi Tomek, >> > > >> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki > 40yahoo.com@dmarc.ietf.org>: >> > > > >> > > > I agree with Vittorio, Dominick et al. >> > > > >> > > >> I disagree. >> > > > >> > > >> Existing deployments that have not mitigated against the concerns >> with implicit should be ripped up and updated. >> > > > >> > > > Yes, just like future deployments that will not mitigate against >> the concerns of code in the browser should be a concern. >> > > >> > > I agree. That=E2=80=99s why I pointed point yesterday that the Secur= ity BCP >> also defines obligations for clients using code. >> > > >> > > >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-= 2.1 >> > > >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-= 2.1.1 >> > > >> > > > >> > > > Can somebody on the other side of the argument (and I hate to make >> it sound like there are two sides, because we're on the same side as far= as >> Implicit's AT in front-channel is a real issue) address Dominic's commen= t: >> > > > >> > > >> Also - simply saying =E2=80=9Cimplicit is evil - switch to code= =E2=80=9D means for >> most people also using refresh token - so we are treating access tokens = in >> the URL with refresh tokens in session storage (over simplified - but yo= u >> get the idea). >> > > > >> > > > Does the group agree|disagree that a recommendation to switch to >> code should be made as long as it is followed by an explanation and >> guidance on what to do with RTs? The ideas that were floated around >> > > > - Token bound RTs (even though it was pointed out that token >> binding is still considered an emerging standard). So should the >> recommendation than say "switch to code and MUST use token bound RTs"? >> > > > - Have AS not release RTs. "Switch to code and DO NOT request RTs"= ? >> Or switch to code and configure AT to not release RTs for this type of >> client (not sure what that even looks like in a form of a 3rd party >> clients)? >> > > > - RTs short lived and bound to a session - "Switch to code as long >> as AT can bind and revoke RTs when you log out=E2=80=9C >> > > >> > > Basically, the AS does not need to issue refresh tokens. If the AS >> does not issue refresh tokens, the integration pattern for SPAs does not >> change (beside the code exchange). If the client needs a new access toke= n, >> it will perform another authorization request. >> > > >> > > If it does, this adds another layer of security because it allows th= e >> client to frequently obtain new access tokens, which can be short-lived = and >> scope restricted. >> > > >> > > The refresh tokens should be replay protected by issuing new refresh >> tokens with every refresh and detect replay for refresh tokens belonging= to >> the same grant. >> > > >> > > The AS may additionally bind refresh tokens to AS sessions, but as i= t >> was pointed out by Annabelle and others, there are some implications to = be >> understood and managed in that context. >> > > >> > > You may find more text about refresh tokens in the Security BCP >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-= 3.12 >> > > >> > > kind regards, >> > > Torsten. >> > > >> > > >> > > > >> > > > Sorry if I have missed an important detail from the list above, >> people who have proposed these ideas, feel free to clarify. >> > > >> > > > >> > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt < >> dick.hardt@gmail.com> wrote: >> > > > >> > > > I disagree. >> > > > >> > > > Existing deployments that have not mitigated against the concerns >> with implicit should be ripped up and updated. >> > > > >> > > > For example, at one time, I think it was Instagram that had >> deployed implicit because it was easier to do. Once the understood the >> security implications, they changed the implementation. >> > > > >> > > > BCPs are rarely a response to a new threat, their are capturing >> Best Current Practices so that they become widely deployed. >> > > > >> > > > >> > > > >> > > > >> > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote: >> > > >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. ar= e >> saying here. And that was kind of behind the comment I made, or tired to >> make, about this in Bangkok, which was (more or less) that I don't think >> the WG should be killing implicit outright but rather that it should beg= in >> to recommend against it. >> > > >> >> > > >> I'm not exactly sure what that looks like in this document but >> maybe toning down some of the scarier language a bit, favoring SHOULDs v= s. >> MUSTs, and including language that helps a reader understand the >> recommendations as being more considerations for new >> applications/deployments than as a mandate to rip up existing ones. >> > > >> >> > > >> >> > > >> >> > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley >> wrote: >> > > >>> >> > > >>> We just need to be sensitive to the spin on this. >> > > >>> >> > > >> >> > > >> 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 f= ile >> attachments from your computer. Thank >> you._______________________________________________ >> > > >> 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 >> >> --000000000000a34d5f057c559d5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you!
On the RT, m= ore questions:

- where w= ould you save the RT? Iam thinking of the no-backend case in particular. Th= ere=E2=80=99s a lot of heartburn in the community on where to save access t= okens already, given the larger scope of refresh tokens I would expect obje= ctions there would be exacerbated. The user experience bar (number of promp= ts, full page redirects) should be the one afforded by implicit leveraging = AS sessions via persistent cookies.
=C2=A0
- how would we advise developers about handling distributed s= ign out? If the session cookie with the AS is no longer =C2=A0the only arti= fact representing the effective session, it looks like we should be prescri= ptive on what signals an app should listen for (OIDC checkSession?) and wha= t the expected actions are (e.g. remove the cached RTs). I realize this isn= =E2=80=99t strictly OAuth2, but it remains an important difference in end t= o end scenarios people use implicit for today

Thx
V.

On Wed, Dec 5, 2018 at 23:27 Torsten Lod= derstedt <torsten@lodderstedt= .net> wrote:


A= m 06.12.2018 um 02:31 schrieb Vittorio Bertocci <vittorio.bertocci@auth0.com&g= t;:

Hey Torsten/Tomek,
Can I ask a clarification on the below?
= Torsten, you mentioned that an AS doesn't need to issue a RT- the brows= er code can just repeat an authorization request. Did I get it right?
=
But in order to preserve the user experience, that cannot really happe= n as a full page redirect; right? That wouldn't fly for any kind of bac= kground update, or for retrieving new ATs for different resources based on = the same session. So would we now use a hidden frame to retrieve a code in = the same way in which we used fragments to get new ATs?

That=E2=80=99s what I meant. I also think the RT-= based approach is better suited in terms of UX and security.

Thx
V.=

On Wed, Dec 5, = 2018 at 7:17 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Hi Tomek,

> Am 05.12.2018 um 15:27 schrieb Tomek Stojecki <tstojecki@yahoo.com>:
>
> Hi Torsten,
>
> On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:
>
>
> >> So if I am putting myself in the shoes of somebody who sets o= ut to do that - switch an existing SPA client (no backend)
>
> > I would like to ask you a question: how many SPAs w/o a backend h= ave you seen in your projects?
>
> SPA (html+js) utilizing a 3rd party api that requires authorization? > If you do have a backend, aren't you better of handling the token = request on the backend as pointed out here
> https://github.com/aaronpk/oauth-browse= r-based-apps/blob/master/oauth-browser-based-apps.md#javascript-app-with-a-= backend-component

I agree.

> My point of putting (no backend) in parenthesis was to not derail this= discussion and of course it had the opposite effect.
>

You know, I you says =E2=80=9Edon=E2=80=99t look at the green car=E2=80=9C = will cause everyone looking for it :-) It asked just out of curiosity.

> >> Is that fair or is that too much of a shortcut? I am familiar= with the specs you've referenced and have looked at them again, but de= aling with a SPA, some of the recommendations are not feasible (can't a= uthenticate the client,
>
> > You could using dynamic registration (see other thread). The prot= ection would only differ from refresh token rotation if you would use publi= c key crypto for client authentication.
>
> Good point. How well is dynamic registration supported across AS?

I leave that to the vendors :-)

>
> >> confidentiality in storage? - not sure how to read that in th= e context of a browser)
>
> > How do you ensure confidentiality of session cookies?
>
> All I am trying to say is that I think context is important here. So w= hen you point out these best practices, some of them will get people confus= ed as far as what it means in the browser based app scenario.

That=E2=80=99s why we have the more general Security BCP and client-specifi= c BCPs, like for native apps (https://tools.ietf.org/html/rfc8252= ) and the new BCP for SPAs Aaron started to work on.

> Maybe it is just me :)

thanks for raising the question! We need this kind of input to govern the d= evelopment of our specs.

kind regards,
Torsten.

>
> >
> > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderste= dt <torsten= @lodderstedt.net> wrote:
> >
> >
> > Hi Tomek,
> >
> > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki <tstojecki= =3D40yahoo.= com@dmarc.ietf.org>:
> > >
> > > I agree with Vittorio, Dominick et al.
> > >
> > >> I disagree.
> > >
> > >> Existing deployments that have not mitigated against the= concerns with implicit should be ripped up and updated.
> > >
> > > Yes, just like future deployments that will not mitigate aga= inst the concerns of code in the browser should be a concern.
> >
> > I agree. That=E2=80=99s why I pointed point yesterday that the Se= curity BCP also defines obligations for clients using code.
> >
> > https://tools.i= etf.org/html/draft-ietf-oauth-security-topics-10#section-2.1
> > https://tools= .ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1.1
> >
> > >
> > > Can somebody on the other side of the argument (and I hate t= o make it sound like there are two sides, because we're on the same sid= e as far as Implicit's AT in front-channel is a real issue) address Dom= inic's comment:
> > >
> > >> Also - simply saying =E2=80=9Cimplicit is evil - switch = to code=E2=80=9D means for most people also using refresh token - so we are= treating access tokens in the URL with refresh tokens in session storage (= over simplified - but you get the idea).
> > >
> > > Does the group agree|disagree that a recommendation to switc= h to code should be made as long as it is followed by an explanation and gu= idance on what to do with RTs? The ideas that were floated around
> > > - Token bound RTs (even though it was pointed out that token= binding is still considered an emerging standard). So should the recommend= ation than say "switch to code and MUST use token bound RTs"?
> > > - Have AS not release RTs. "Switch to code and DO NOT r= equest RTs"? Or switch to code and configure AT to not release RTs for= this type of client (not sure what that even looks like in a form of a 3rd= party clients)?
> > > - RTs short lived and bound to a session - "Switch to c= ode as long as AT can bind and revoke RTs when you log out=E2=80=9C
> >
> > Basically, the AS does not need to issue refresh tokens. If the A= S does not issue refresh tokens, the integration pattern for SPAs does not = change (beside the code exchange). If the client needs a new access token, = it will perform another authorization request.=C2=A0
> >
> > If it does, this adds another layer of security because it allows= the client to frequently obtain new access tokens, which can be short-live= d and scope restricted.
> >
> > The refresh tokens should be replay protected by issuing new refr= esh tokens with every refresh and detect replay for refresh tokens belongin= g to the same grant.
> >
> > The AS may additionally bind refresh tokens to AS sessions, but a= s it was pointed out by Annabelle and others, there are some implications t= o be understood and managed in that context.
> >
> > You may find more text about refresh tokens in the Security BCP <= a href=3D"https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#s= ection-3.12" rel=3D"noreferrer" target=3D"_blank">https://tools.ietf.org/ht= ml/draft-ietf-oauth-security-topics-10#section-3.12
> >
> > kind regards,
> > Torsten.
> >
> >
> > >
> > > Sorry if I have missed an important detail from the list abo= ve, people who have proposed these ideas, feel free to clarify.
> >
> > >
> > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt &= lt;dick.hardt@gma= il.com> wrote:
> > >
> > > I disagree.
> > >
> > > Existing deployments that have not mitigated against the con= cerns with implicit should be ripped up and updated.
> > >
> > > For example, at one time, I think it was Instagram that had = deployed implicit because it was easier to do. Once the understood the secu= rity implications, they changed the implementation.
> > >
> > > BCPs are rarely a response to a new threat, their are captur= ing Best Current Practices so that they become widely deployed.
> > >
> > >
> > >
> > >
> > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell <bcampbell= =3D4= 0pingidentity.com@dmarc.ietf.org> wrote:
> > >> FWIW I'm somewhat sympathetic to what Vittorio, Domi= nick, etc. are saying here. And that was kind of behind the comment I made,= or tired to make, about this in Bangkok, which was (more or less) that I d= on't think the WG should be killing implicit outright but rather that i= t should begin to recommend against it.
> > >>
> > >> I'm not exactly sure what that looks like in this do= cument but maybe toning down some of the scarier language a bit, favoring S= HOULDs vs. MUSTs, and including language that helps a reader understand the= recommendations as being more considerations for new applications/deployme= nts than as a mandate to rip up existing ones.
> > >>
> > >>
> > >>
> > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley <ve7jtb@ve7jtb.com> w= rote:
> > >>>
> > >>> We just need to be sensitive to the spin on this.=C2= =A0
> > >>>
> > >>
> > >> CONFIDENTIALITY NOTICE: This email may contain confident= ial and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly prohibite= d...=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 attach= ments from your computer. Thank you._______________________________________= ________
> > >> OAuth mailing list
> > >> OAut= h@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/= oauth
> > >>
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ie= tf.org
> > > https://www.ietf.org/mailman/listinfo/oau= th
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ie= tf.org
> > > https://www.ietf.org/mailman/listinfo/oau= th
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/oauth=

--000000000000a34d5f057c559d5c-- From nobody Thu Dec 6 04:49:29 2018 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 2B39D1286E7 for ; Thu, 6 Dec 2018 04:49:28 -0800 (PST) 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 fIUT3A-B148U for ; Thu, 6 Dec 2018 04:49:23 -0800 (PST) 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 C1DA012D4EA for ; Thu, 6 Dec 2018 04:49:22 -0800 (PST) Received: from [88.128.83.85] (helo=[10.54.161.93]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gUt5j-0006Vv-C6; Thu, 06 Dec 2018 13:49:19 +0100 From: Torsten Lodderstedt Message-Id: <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_9B34935D-BB7F-4E0E-92D2-FFDF39324B9F"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Thu, 6 Dec 2018 13:49:18 +0100 In-Reply-To: Cc: Brian Campbell , Daniel Fett , IETF oauth WG , Tomek Stojecki To: Vittorio Bertocci References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 06 Dec 2018 12:49:28 -0000 --Apple-Mail=_9B34935D-BB7F-4E0E-92D2-FFDF39324B9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Vittorio, > Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci : >=20 > Thank you! > On the RT, more questions: >=20 > - where would you save the RT? Iam thinking of the no-backend case in = particular. There=E2=80=99s a lot of heartburn in the community on where = to save access tokens already, given the larger scope of refresh tokens = I would expect objections there would be exacerbated. Interesting, I=E2=80=99m much more concerned about tokens transmitted in = URLs since those tokens are vulnerable to remote attacks.=20 Regarding protection at rest: what=E2=80=99s the attacker model in those = discussions? XSS? Local attacks on the device? Much of the mechanisms are platform specific and need platform = expertise.=20 =46rom the OAuth protocol perspective, impact of RT leakage can be = limited through rotation. So I would argue RTs are better protected than = ATs. > The user experience bar (number of prompts, full page redirects) = should be the one afforded by implicit leveraging AS sessions via = persistent cookies. sure. I don=E2=80=99t see any technical difference in the way the = browser is utilized for both flows and therefore would be surprised to = see differences in UX.=20 > =20 > - how would we advise developers about handling distributed sign out? = If the session cookie with the AS is no longer the only artifact = representing the effective session, it looks like we should be = prescriptive on what signals an app should listen for (OIDC = checkSession?) and what the expected actions are (e.g. remove the cached = RTs). I realize this isn=E2=80=99t strictly OAuth2, but it remains an = important difference in end to end scenarios people use implicit for = today Interesting question :-) I think login and API access are quite = different.=20 In login the client potentially wants to tightly couple its session = lifecycle to the AS/OP session, simply because it relies on the user id = attested by the OP=E2=80=99s for its local user/session management.=20 For API access, this is not needed. The client =E2=80=9Ejust=E2=80=9C = obtains a credential to access certain APIs on behalf of the resource = owner. The identity of the resource owner on the AS side and the = identity of the client user don=E2=80=99t necessary have a relationship. = As you know, OAuth was intentionally built to hide the resource owner = identity from the client. I think in this case the resource owner or the = AS might have an interest to terminate API access in case of logout at = the AS.=20 Protocol-wize this result in huge differences: In the login case, the = client can check the session with the OP periodically and terminate its = own session in case the identity changed or there is no longer a = session. This typically requires frontend interactions and OpenID = Connect (session mgmt or logout). In the API case, the AS can just revoke the RT when the logout happens.=20= kind regards, Torsten.=20 >=20 > Thx > V. >=20 > On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt = wrote: >=20 >=20 > Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci = : >=20 >> Hey Torsten/Tomek, >> Can I ask a clarification on the below? >> Torsten, you mentioned that an AS doesn't need to issue a RT- the = browser code can just repeat an authorization request. Did I get it = right? >> But in order to preserve the user experience, that cannot really = happen as a full page redirect; right? That wouldn't fly for any kind of = background update, or for retrieving new ATs for different resources = based on the same session. So would we now use a hidden frame to = retrieve a code in the same way in which we used fragments to get new = ATs? >=20 > That=E2=80=99s what I meant. I also think the RT-based approach is = better suited in terms of UX and security. >=20 >> Thx >> V. >>=20 >> On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt = wrote: >> Hi Tomek,=20 >>=20 >> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki = : >> >=20 >> > Hi Torsten, >> >=20 >> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten = Lodderstedt wrote: >> >=20 >> >=20 >> > >> So if I am putting myself in the shoes of somebody who sets out = to do that - switch an existing SPA client (no backend) >> >=20 >> > > I would like to ask you a question: how many SPAs w/o a backend = have you seen in your projects? >> >=20 >> > SPA (html+js) utilizing a 3rd party api that requires = authorization? >> > If you do have a backend, aren't you better of handling the token = request on the backend as pointed out here >> > = https://github.com/aaronpk/oauth-browser-based-apps/blob/master/oauth-brow= ser-based-apps.md#javascript-app-with-a-backend-component >>=20 >> I agree.=20 >>=20 >> > My point of putting (no backend) in parenthesis was to not derail = this discussion and of course it had the opposite effect. >> >=20 >>=20 >> You know, I you says =E2=80=9Edon=E2=80=99t look at the green car=E2=80= =9C will cause everyone looking for it :-) It asked just out of = curiosity.=20 >>=20 >> > >> Is that fair or is that too much of a shortcut? I am familiar = with the specs you've referenced and have looked at them again, but = dealing with a SPA, some of the recommendations are not feasible (can't = authenticate the client,=20 >> >=20 >> > > You could using dynamic registration (see other thread). The = protection would only differ from refresh token rotation if you would = use public key crypto for client authentication. >> >=20 >> > Good point. How well is dynamic registration supported across AS?=20= >>=20 >> I leave that to the vendors :-) >>=20 >> >=20 >> > >> confidentiality in storage? - not sure how to read that in the = context of a browser) >> >=20 >> > > How do you ensure confidentiality of session cookies? >> >=20 >> > All I am trying to say is that I think context is important here. = So when you point out these best practices, some of them will get people = confused as far as what it means in the browser based app scenario. >>=20 >> That=E2=80=99s why we have the more general Security BCP and = client-specific BCPs, like for native apps = (https://tools.ietf.org/html/rfc8252) and the new BCP for SPAs Aaron = started to work on. >>=20 >> > Maybe it is just me :) >>=20 >> thanks for raising the question! We need this kind of input to govern = the development of our specs. >>=20 >> kind regards, >> Torsten.=20 >>=20 >> >=20 >> > >=20 >> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten = Lodderstedt wrote: >> > >=20 >> > >=20 >> > > Hi Tomek, >> > >=20 >> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki = : >> > > >=20 >> > > > I agree with Vittorio, Dominick et al.=20 >> > > >=20 >> > > >> I disagree.=20 >> > > >=20 >> > > >> Existing deployments that have not mitigated against the = concerns with implicit should be ripped up and updated. >> > > >=20 >> > > > Yes, just like future deployments that will not mitigate = against the concerns of code in the browser should be a concern. >> > >=20 >> > > I agree. That=E2=80=99s why I pointed point yesterday that the = Security BCP also defines obligations for clients using code.=20 >> > >=20 >> > > = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.= 1 >> > > = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.= 1.1 >> > >=20 >> > > >=20 >> > > > Can somebody on the other side of the argument (and I hate to = make it sound like there are two sides, because we're on the same side = as far as Implicit's AT in front-channel is a real issue) address = Dominic's comment:=20 >> > > >=20 >> > > >> Also - simply saying =E2=80=9Cimplicit is evil - switch to = code=E2=80=9D means for most people also using refresh token - so we are = treating access tokens in the URL with refresh tokens in session storage = (over simplified - but you get the idea). >> > > >=20 >> > > > Does the group agree|disagree that a recommendation to switch = to code should be made as long as it is followed by an explanation and = guidance on what to do with RTs? The ideas that were floated around=20 >> > > > - Token bound RTs (even though it was pointed out that token = binding is still considered an emerging standard). So should the = recommendation than say "switch to code and MUST use token bound RTs"? >> > > > - Have AS not release RTs. "Switch to code and DO NOT request = RTs"? Or switch to code and configure AT to not release RTs for this = type of client (not sure what that even looks like in a form of a 3rd = party clients)? >> > > > - RTs short lived and bound to a session - "Switch to code as = long as AT can bind and revoke RTs when you log out=E2=80=9C >> > >=20 >> > > Basically, the AS does not need to issue refresh tokens. If the = AS does not issue refresh tokens, the integration pattern for SPAs does = not change (beside the code exchange). If the client needs a new access = token, it will perform another authorization request. =20 >> > >=20 >> > > If it does, this adds another layer of security because it allows = the client to frequently obtain new access tokens, which can be = short-lived and scope restricted.=20 >> > >=20 >> > > The refresh tokens should be replay protected by issuing new = refresh tokens with every refresh and detect replay for refresh tokens = belonging to the same grant.=20 >> > >=20 >> > > The AS may additionally bind refresh tokens to AS sessions, but = as it was pointed out by Annabelle and others, there are some = implications to be understood and managed in that context. >> > >=20 >> > > You may find more text about refresh tokens in the Security BCP = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.= 12 >> > >=20 >> > > kind regards, >> > > Torsten. >> > >=20 >> > >=20 >> > > >=20 >> > > > Sorry if I have missed an important detail from the list above, = people who have proposed these ideas, feel free to clarify.=20 >> > >=20 >> > > >=20 >> > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt = wrote:=20 >> > > >=20 >> > > > I disagree.=20 >> > > >=20 >> > > > Existing deployments that have not mitigated against the = concerns with implicit should be ripped up and updated. >> > > >=20 >> > > > For example, at one time, I think it was Instagram that had = deployed implicit because it was easier to do. Once the understood the = security implications, they changed the implementation.=20 >> > > >=20 >> > > > BCPs are rarely a response to a new threat, their are capturing = Best Current Practices so that they become widely deployed. >> > > >=20 >> > > >=20 >> > > >=20 >> > > >=20 >> > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell = wrote: >> > > >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. = are saying here. And that was kind of behind the comment I made, or = tired to make, about this in Bangkok, which was (more or less) that I = don't think the WG should be killing implicit outright but rather that = it should begin to recommend against it.=20 >> > > >>=20 >> > > >> I'm not exactly sure what that looks like in this document but = maybe toning down some of the scarier language a bit, favoring SHOULDs = vs. MUSTs, and including language that helps a reader understand the = recommendations as being more considerations for new = applications/deployments than as a mandate to rip up existing ones.=20 >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley = wrote: >> > > >>>=20 >> > > >>> We just need to be sensitive to the spin on this. =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._______________________________________________ >> > > >> 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 >> > > _______________________________________________ >> > > OAuth mailing list >> > > OAuth@ietf.org >> > > https://www.ietf.org/mailman/listinfo/oauth >>=20 --Apple-Mail=_9B34935D-BB7F-4E0E-92D2-FFDF39324B9F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODEyMDYxMjQ5MThaMC8GCSqGSIb3DQEJBDEiBCCC 9WDdqtwzBsuvL4S7i166PfPU3aM++PTm8JpiwBX7gTCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAtgqvak5h58sBsci6KBuKh5Gl 1uB5/EWe99Iqf76guJBSmbMSD2waHM2H2SR/hNfWtzyRgtJBSL8TxxKddngPjKHuUy7XkHlLzrvM a2ZvcyCAfFpCh/81ZVX79JhTn0mqMzqzm+hAbWFx5hHTXNG1iuVunPwiob4w6B0zILmZF4LLZ5RL DHgsFylTU75Td3laL3S115XxmgtJDgM7YgPI7Knl+kAnu2nDuqssHv+lEPCCICSZxEadpbYYHxYv nee1mOZjUZGRtFi+Y2qe8nluLzzw9ghAhGcuejGH+M+W4YWaHZxgZaTJ+T6sTdZXRAv1lqxTJ9wz b39Rd//RPnHIDAAAAAAAAA== --Apple-Mail=_9B34935D-BB7F-4E0E-92D2-FFDF39324B9F-- From nobody Thu Dec 6 06:48:36 2018 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 16C771271FF for ; Thu, 6 Dec 2018 06:48:35 -0800 (PST) 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 s3y7QZ-DFbF8 for ; Thu, 6 Dec 2018 06:48:30 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.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 DCC55130E3A for ; Thu, 6 Dec 2018 06:48:29 -0800 (PST) X-AuditID: 12074423-cf3f39e0000053bc-ae-5c0936bb2eea Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 80.86.21436.BB6390C5; Thu, 6 Dec 2018 09:48:27 -0500 (EST) Received: from outgoing-exchange-3.mit.edu (OUTGOING-EXCHANGE-3.MIT.EDU [18.9.28.13]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wB6EliR4011698; Thu, 6 Dec 2018 09:48:26 -0500 Received: from OC11EXEDGE4.EXCHANGE.MIT.EDU (OC11EXEDGE4.EXCHANGE.MIT.EDU [18.9.3.27]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id wB6ElqqK029225; Thu, 6 Dec 2018 09:48:40 -0500 Received: from W92EXCAS20.exchange.mit.edu (18.7.71.33) by OC11EXEDGE4.EXCHANGE.MIT.EDU (18.9.3.27) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 6 Dec 2018 09:47:09 -0500 Received: from OC11EXPO25.exchange.mit.edu ([169.254.1.53]) by W92EXCAS20.exchange.mit.edu ([18.7.71.33]) with mapi id 14.03.0352.000; Thu, 6 Dec 2018 09:47:29 -0500 From: Justin Richer To: Hannes Tschofenig CC: oauth Thread-Topic: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit Thread-Index: AdR/8wsdlCSgLoNZTem+1MxrAorhbwNqXmAA Date: Thu, 6 Dec 2018 14:47:28 +0000 Message-ID: <6F8AA173-9C30-46C6-892B-CEDA40379916@mit.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.9.1.91] Content-Type: multipart/alternative; boundary="_000_6F8AA1739C3046C6892BCEDA40379916mitedu_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0gUYRTtmxl3Z8WRb0dtv1b90fZAJZ+UmET6o8gQooe/zNTJndyl3VV2 VlODMNTykT0VdXF9borbpmSRYom1hOhq9COJrHwrqZiEKBWUNuP4+nM5957DOffjuyRON0qU pNZgYo0GRqeSuBK0zGtf4KtwWUKIZTkkYrjSiUX0/5iXRGMx9ho7iLFa/2BnsXjXY2pWp81k jcHHk1017f2zIH3xetb7tyG5oCerGMhIBA8jS8VHrBi4kjS0Y6jh32dcbHoAGhn9KRWbXoBm ClsJsXkJ0LO1Wy5i08IzvUOYYCaBB1CFPX8de8JQ1J3ncBEwDpVoMt9JCNgDpqDekXreluQ1 arQ64iXCMNTTnCMoCLgfDQzexgVMwUi0UrcGBAkNk1Fr4yFhLIMMKqp7JBEwgLvRL6cdE4MU 6Mt0LSa+DCLr6w+4iL3Q3NSqi2CDoC9aKIgS5Ymoq2xuI0mO+qumiftAYd7hZN4hM++QmXkn HPqjtq5gUbIXlZVMSEXshwqqLRs4Cj3oWyJ2auoAaQO+an1OoJ7R6jg2JZBLYQwG1hgYHqTX moJYdUY7EH5YemJfJ5i7G+sAkAQqN2p2XJpAuzCZXLbeAfaQmMqLKnnDj9wvp6mzNQynSTJm 6FjOARCJqzypXUFkAk2pmewc1pi2SXmThEpB/fWcukjDVMbEXmXZdNa4yfqQpApRY76yBFpu ZFPZrCtanWmbxkiZYO7Gm08e4TUUl87oOW2qyDtBLGmrLKzEycn1urhehwaL+Lpg+c3Xwtam apwmDGkGVqmgPMf5/aBgockwbKWIt417zwMF/2gPiuBPnHbjL38rZ55fAeNX0L3AhBVMzDal zAWSznelpk9jkfHFN9uszaU1spYuTv7Y/1qeWUecdxy0fW1G5ffk1o4LcUldl6qaJmzeDYa4 +tGHR938aqNLQIyl8UxBd/z38m+JM7h3mElZ9mRZETCWlut/+uSS5fm0u0/oqcpz/fIB242a O93ufdrRGGs61TEWrlyssg2vqJ+qCE7DhAbgRo75D9HYn/+2AwAA Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 06 Dec 2018 14:48:35 -0000 --_000_6F8AA1739C3046C6892BCEDA40379916mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IHRoZSBtb3ZlIGF3YXkgZnJvbSB0aGUgaW1wbGljaXQgZmxvdyB0b3dhcmQgdXNp bmcgdGhlIGF1dGhvcml6YXRpb24gY29kZSBmbG93ICh3aXRoIFBLQ0UgYW5kIENPUlMpICBmb3Ig SmF2YVNjcmlwdCBhcHBsaWNhdGlvbnMuIFRoZSBsaW1pdGF0aW9ucyBhbmQgYXNzdW1wdGlvbnMg dGhhdCBzdXJyb3VuZGVkIHRoZSBkZXNpZ24gb2YgdGhlIGltcGxpY2l0IGZsb3cgYmFjayB3aGVu IHdlIHN0YXJ0ZWQgbm8gbG9uZ2VyIGFwcGx5IHRvZGF5LiBJdCB3YXMgYW4gb3B0aW1pemF0aW9u IGZvciBhIGRpZmZlcmVudCB0aW1lLiBUZWNobm9sb2d5IGFuZCBwbGF0Zm9ybXMgaGF2ZSBtb3Zl ZCBmb3J3YXJkLCBhbmQgb3VyIGFkdmljZSBzaG91bGQgbW92ZSB0aGVtIGZvcndhcmQgYXMgd2Vs bC4gRnVydGhlcm1vcmUsIHRoZSBlYXNlIG9mIHVzaW5nIHRoZSBpbXBsaWNpdCBmbG93IGluY29y cmVjdGx5LCBhbmQgdGhlIGRhbWFnZSB0aGF0IGRvaW5nIHNvIGNhbiBjYXVzZSwgaGFzIGRyaXZl biBtZSB0byB0ZWxsaW5nIHBlb3BsZSB0byBzdG9wIHVzaW5nIGl0Lg0KDQpUaGVyZSBhcmUgYSBu dW1iZXIgb2YgaGFja3MgdGhhdCBjYW4gcGF0Y2ggdGhlIGltcGxpY2l0IGZsb3cgdG8gYmUgc2xp Z2h0bHkgYmV0dGVyIGluIHZhcmlvdXMgd2F5cyDigJQgaWYgeW91IHRhY2sgb24gdGhlIOKAnGh5 YnJpZOKAnSBmbG93IGZyb20gT0lEQyBvciBKQVJNIHBsdXMgcG9zdCBtZXNzYWdlcyBhbmQgYSBi dW5jaCBvZiBvdGhlciBzdHVmZiwgdGhlbiBpdCBjYW4gYmUgYmV0dGVyLiBCdXQgaWYgeW914oCZ cmUgZG9pbmcgYWxsIG9mIHRoYXQsIEkgdGhpbmsgeW91IHJlYWxseSBuZWVkIHRvIGFzayB5b3Vy c2VsZjogd2h5PyBXaGF0IGRvIHlvdSBnYWluIGZyb20ganVtcGluZyB0aHJvdWdoIGFsbCBvZiB0 aG9zZSBob29wcyB3aGVuIGEgdmlhYmxlIGFsdGVybmF0aXZlIHNpdHMgdGhlcmU/IElzIGl0IHBy aWRlPyBJIGRvbuKAmXQgc2VlIHdoeSB3ZSBjbGluZyB0byBpdC4gVG8gbWUsIGl04oCZcyBsaWtl IHNheWluZyDigJxoZXkgc3VyZSBteSBsZWcgZ2V0cyBjdXQgb2ZmIHdoZW4gSSBkbyB0aGlzLCBi dXQgSSBjYW4gc3RpdGNoIGl0IGJhY2sgb24h4oCdLCB3aGVuIHlvdSBjb3VsZCBzaW1wbHkgYXZv aWQgY3V0dGluZyB5b3VyIGxlZyBvZmYgaW4gdGhlIGZpcnN0IHBsYWNlLiBUaGUgYmVzdCBjdXJl IGlzIHByZXZlbnRpb24sIGFuZCB3aGF04oCZcyBiZWluZyBhcmd1ZWQgaGVyZSBpcyBwcmV2ZW50 aW9uLg0KDQpTbyBtYW55IG9mIE9BdXRo4oCZcyBwcm9ibGVtcyBpbiB0aGUgd2lsZCBjb21lIGZy b20gb3Zlci11c2Ugb2YgdGhlIGZyb250IGNoYW5uZWwsIGFuZCBhbnkgcGxhY2Ugd2UgY2FuIG1v dmUgYXdheSBmcm9tIHRoYXQgaXMgYSBnb29kIG1vdmUuDQoNCuKAlCBKdXN0aW4NCg0KT24gTm92 IDE5LCAyMDE4LCBhdCA1OjM0IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVu aWdAYXJtLmNvbTxtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4+IHdyb3RlOg0KDQpI aSBhbGwsDQpUaGUgYXV0aG9ycyBvZiB0aGUgT0F1dGggU2VjdXJpdHkgVG9waWNzIGRyYWZ0IGNh bWUgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCBpdCBpcyBub3QgcG9zc2libGUgdG8gYWRlcXVhdGVs eSBzZWN1cmUgdGhlIGltcGxpY2l0IGZsb3cgYWdhaW5zdCB0b2tlbiBpbmplY3Rpb24gc2luY2Ug cG90ZW50aWFsIHNvbHV0aW9ucyBsaWtlIHRva2VuIGJpbmRpbmcgb3IgSkFSTSBhcmUgaW4gYW4g ZWFybHkgc3RhZ2Ugb2YgYWRvcHRpb24uIEZvciB0aGlzIHJlYXNvbiwgYW5kIHNpbmNlIENPUlMg YWxsb3dzIGJyb3dzZXItYmFzZWQgYXBwcyB0byBzZW5kIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBl bmRwb2ludCwgVG9yc3RlbiBzdWdnZXN0ZWQgdG8gdXNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUg aW5zdGVhZCBvZiB0aGUgaW1wbGljaXQgZ3JhbnQgaW4gY2FsbCBjYXNlcyBpbiBoaXMgcHJlc2Vu dGF0aW9uIChzZWUgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRl cmlhbHMvc2xpZGVzLTEwMy1vYXV0aC1zZXNzYi1kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRv cGljcy0wMSkuDQpBIGh1bSBpbiB0aGUgcm9vbSBhdCBJRVRGIzEwMyBjb25jbHVkZWQgc3Ryb25n IHN1cHBvcnQgZm9yIGhpcyByZWNvbW1lbmRhdGlvbnMuIFdlIHdvdWxkIGxpa2UgdG8gY29uZmly bSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdC4NClBsZWFzZSBwcm92aWRlIGEgcmVzcG9uc2Ug YnkgRGVjZW1iZXIgM3JkLg0KQ2lhbw0KSGFubmVzICYgUmlmYWF0DQoNCklNUE9SVEFOVCBOT1RJ Q0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNv bmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVz ZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGlu IGFueSBtZWRpdW0uIFRoYW5rIHlvdS4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRv Ok9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aA0KDQo= --_000_6F8AA1739C3046C6892BCEDA40379916mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <43F9A11C61FF2442A05051FB797CD794@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgc3VwcG9ydCB0aGUgbW92ZSBhd2F5IGZyb20g dGhlIGltcGxpY2l0IGZsb3cgdG93YXJkIHVzaW5nIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZmxv dyAod2l0aCBQS0NFIGFuZCBDT1JTKSAmbmJzcDtmb3IgSmF2YVNjcmlwdCBhcHBsaWNhdGlvbnMu IFRoZSBsaW1pdGF0aW9ucyBhbmQgYXNzdW1wdGlvbnMgdGhhdCBzdXJyb3VuZGVkIHRoZSBkZXNp Z24gb2YgdGhlIGltcGxpY2l0IGZsb3cgYmFjayB3aGVuIHdlIHN0YXJ0ZWQgbm8gbG9uZ2VyIGFw cGx5IHRvZGF5Lg0KIEl0IHdhcyBhbiBvcHRpbWl6YXRpb24gZm9yIGEgZGlmZmVyZW50IHRpbWUu IFRlY2hub2xvZ3kgYW5kIHBsYXRmb3JtcyBoYXZlIG1vdmVkIGZvcndhcmQsIGFuZCBvdXIgYWR2 aWNlIHNob3VsZCBtb3ZlIHRoZW0gZm9yd2FyZCBhcyB3ZWxsLiBGdXJ0aGVybW9yZSwgdGhlIGVh c2Ugb2YgdXNpbmcgdGhlIGltcGxpY2l0IGZsb3cgaW5jb3JyZWN0bHksIGFuZCB0aGUgZGFtYWdl IHRoYXQgZG9pbmcgc28gY2FuIGNhdXNlLCBoYXMgZHJpdmVuIG1lIHRvDQogdGVsbGluZyBwZW9w bGUgdG8gc3RvcCB1c2luZyBpdC4mbmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZXJlIGFyZSBhIG51bWJlciBvZiBoYWNrcyB0aGF0IGNh biBwYXRjaCB0aGUgaW1wbGljaXQgZmxvdyB0byBiZSBzbGlnaHRseSBiZXR0ZXIgaW4gdmFyaW91 cyB3YXlzIOKAlCBpZiB5b3UgdGFjayBvbiB0aGUg4oCcaHlicmlk4oCdIGZsb3cgZnJvbSBPSURD IG9yIEpBUk0gcGx1cyBwb3N0IG1lc3NhZ2VzIGFuZCBhIGJ1bmNoIG9mIG90aGVyIHN0dWZmLCB0 aGVuIGl0IGNhbiBiZSBiZXR0ZXIuIEJ1dCBpZiB5b3XigJlyZSBkb2luZyBhbGwNCiBvZiB0aGF0 LCBJIHRoaW5rIHlvdSByZWFsbHkgbmVlZCB0byBhc2sgeW91cnNlbGY6IHdoeT8gV2hhdCBkbyB5 b3UgZ2FpbiBmcm9tIGp1bXBpbmcgdGhyb3VnaCBhbGwgb2YgdGhvc2UgaG9vcHMgd2hlbiBhIHZp YWJsZSBhbHRlcm5hdGl2ZSBzaXRzIHRoZXJlPyBJcyBpdCBwcmlkZT8gSSBkb27igJl0IHNlZSB3 aHkgd2UgY2xpbmcgdG8gaXQuIFRvIG1lLCBpdOKAmXMgbGlrZSBzYXlpbmcg4oCcaGV5IHN1cmUg bXkgbGVnIGdldHMgY3V0IG9mZiB3aGVuIEkNCiBkbyB0aGlzLCBidXQgSSBjYW4gc3RpdGNoIGl0 IGJhY2sgb24h4oCdLCB3aGVuIHlvdSBjb3VsZCBzaW1wbHkgYXZvaWQgY3V0dGluZyB5b3VyIGxl ZyBvZmYgaW4gdGhlIGZpcnN0IHBsYWNlLiBUaGUgYmVzdCBjdXJlIGlzIHByZXZlbnRpb24sIGFu ZCB3aGF04oCZcyBiZWluZyBhcmd1ZWQgaGVyZSBpcyBwcmV2ZW50aW9uLjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U28gbWFueSBvZiBP QXV0aOKAmXMgcHJvYmxlbXMgaW4gdGhlIHdpbGQgY29tZSBmcm9tIG92ZXItdXNlIG9mIHRoZSBm cm9udCBjaGFubmVsLCBhbmQgYW55IHBsYWNlIHdlIGNhbiBtb3ZlIGF3YXkgZnJvbSB0aGF0IGlz IGEgZ29vZCBtb3ZlLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPg0K4oCUIEp1c3RpbjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj5PbiBOb3YgMTksIDIwMTgsIGF0IDU6MzQgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnICZs dDs8YSBocmVmPSJtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbSIgY2xhc3M9IiI+SGFu bmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJB cHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQpIaSBhbGwsPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KVGhlIGF1dGhvcnMgb2YgdGhl IE9BdXRoIFNlY3VyaXR5IFRvcGljcyBkcmFmdCBjYW1lIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQg aXQgaXMgbm90IHBvc3NpYmxlIHRvIGFkZXF1YXRlbHkgc2VjdXJlIHRoZSBpbXBsaWNpdCBmbG93 IGFnYWluc3QgdG9rZW4gaW5qZWN0aW9uIHNpbmNlIHBvdGVudGlhbCBzb2x1dGlvbnMgbGlrZSB0 b2tlbiBiaW5kaW5nIG9yIEpBUk0gYXJlIGluIGFuIGVhcmx5IHN0YWdlIG9mIGFkb3B0aW9uLiBG b3IgdGhpcyByZWFzb24sDQogYW5kIHNpbmNlIENPUlMgYWxsb3dzIGJyb3dzZXItYmFzZWQgYXBw cyB0byBzZW5kIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludCwgVG9yc3RlbiBzdWdnZXN0 ZWQgdG8gdXNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiB0aGUgaW1wbGljaXQg Z3JhbnQgaW4gY2FsbCBjYXNlcyBpbiBoaXMgcHJlc2VudGF0aW9uIChzZWU8c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEwMy1vYXV0aC1z ZXNzYi1kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0wMSIgc3R5bGU9ImNvbG9yOiBy Z2IoMTQ5LCA3OSwgMTE0KTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAzL21hdGVyaWFscy9zbGlkZXMt MTAzLW9hdXRoLXNlc3NiLWRyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTAxPC9hPiku PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KQSBodW0gaW4gdGhlIHJvb20gYXQgSUVURiMx MDMgY29uY2x1ZGVkIHN0cm9uZyBzdXBwb3J0IGZvciBoaXMgcmVjb21tZW5kYXRpb25zLiBXZSB3 b3VsZCBsaWtlIHRvIGNvbmZpcm0gdGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QuPG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KUGxlYXNlIHByb3ZpZGUgYSByZXNwb25zZSBieSBEZWNlbWJl ciAzcmQuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KQ2lhbzxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkhh bm5lcyAmYW1wOyBSaWZhYXQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25l OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5JTVBP UlRBTlQNCiBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhl ciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yDQogc3RvcmUgb3IgY29weSB0aGUg aW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91LiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVj b3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIg Y2xhc3M9IiI+T0F1dGgNCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm Lm9yZyIgc3R5bGU9ImNvbG9yOiByZ2IoMTQ5LCA3OSwgMTE0KTsgdGV4dC1kZWNvcmF0aW9uOiB1 bmRlcmxpbmU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z aXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9 IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgiIHN0eWxlPSJjb2xvcjogcmdiKDE0OSwgNzksIDExNCk7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi IGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+ PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_6F8AA1739C3046C6892BCEDA40379916mitedu_-- From nobody Thu Dec 6 10:10:12 2018 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 105BA130F0E for ; Thu, 6 Dec 2018 10:10:10 -0800 (PST) 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_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=auth0.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 8ioW3pm5gsie for ; Thu, 6 Dec 2018 10:10:04 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 1176C130F0D for ; Thu, 6 Dec 2018 10:10:03 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id 83-v6so1219042ljf.10 for ; Thu, 06 Dec 2018 10:10:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aUgRjfhdQKHgwdlj1lPhnhiN8V9ChBl4qJ/XqK5ipS8=; b=Sq1d+9iOm8+bu6gr7ssDDNnOwdEUbiPLHWSThwCHn0SJTNJaIkv3Fmll+TeiVvO3M1 PU8cxDehQR8861/aV52W/EX9tUzQOsilNprqOInBThLxC5tOP5qMGB7nikFxNlXnIppa na98ClsJZUF5/f7BwETqIlVHfScuO8oG3S/rnGSh5sHVfqOwSlTSxxUC8yqmDSdL+7Dn vywfSgw7PaxaVw03E7SYIi5ILmk2eqPUMEkIb3XYvDBb8lqL0ipXCH4rv37iEAES96KE 5OlcATkeEtkeCEA21ksgrEKvygRJ88uUaE9bLobSIOB1+egM3GzYTC0zDETzCy2tEnXv N//Q== 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=aUgRjfhdQKHgwdlj1lPhnhiN8V9ChBl4qJ/XqK5ipS8=; b=eYSLMQSc9R6XqEaJngwXkW5CnqkqX4iMnp031iiQyEhQkgv4VQV6sjOfpdJq/CD7Cc fXYyca4APcZEKWXnP+kXlAJ1QtL4uCBQrwZvEUDzkh/5hIV4kHg+ShprCOi2htAC1FUB x96MbfhqwtBwgYphDNFfUtSzVWxlVrGBGOS41UXo5p422+tK6uHCWIwv6RLrAlErBBVs p2HEkvJxH2e2IuU3MGf7BP3X5Y+wmhmXP4vqbZAlsGxyxIRgmCw6CNncMYR2JJWDFBMH 8s4w41ejfjrxjXgb6jXtBZ9l04x+BfGMPgLk7Gn7rzMldNFHd9kkB9+FkZleJ1euSBHQ Y8gA== X-Gm-Message-State: AA+aEWarWhSMk6BdVm9LyvjJwFtO4+kjvMpq9ehD93B0u2VagRmz8IGP 77NrakPfvM7wS/wFwgfAdjDqKQVEd8tIKVmKF6qm4Q== X-Google-Smtp-Source: AFSGD/WAlUEBBDDTAqvAcq0AeNwLAZMPi+Rkj8oCcMXuqhYg9eDt5glxITon2hFUTVOdgZEjAdzJ6Wnu0702o6Po5T0= X-Received: by 2002:a2e:93ce:: with SMTP id p14-v6mr18658965ljh.42.1544119801720; Thu, 06 Dec 2018 10:10:01 -0800 (PST) MIME-Version: 1.0 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> In-Reply-To: <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> From: Vittorio Bertocci Date: Thu, 6 Dec 2018 10:09:50 -0800 Message-ID: To: Torsten Lodderstedt Cc: Brian Campbell , Daniel Fett , IETF oauth WG , Tomek Stojecki Content-Type: multipart/alternative; boundary="00000000000045ccf5057c5e68cf" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 06 Dec 2018 18:10:10 -0000 --00000000000045ccf5057c5e68cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Torsten. I think that a lot of the considerations below need to be tempered with concrete considerations about the features developers can actually rely on today. I agree with identifying the theoretical framework and north star we want to aspire to, but if we are framing the recommendation here in form of practice, we have to ensure it is actionable for developers. I am not pushing back on ideas, but I just want to make sure that when customers hear this advice, they are actually in the position to apply it. And if there are missing pieces, perhaps we should consider this more as guidance to the vendors that need to provide key enablers for this to become viable, and recommend it as practice to customers only when that happened. I add more details inline below, however I have a meta point to make: *did all the vendors on the list work on proof of concepts to ensure that the practices recommended here can work with your product, end to end*? I don't mean just doing a code+PKCE demo in JS, I mean complying with things like RT rotation and revocation end to end, using released features that your customers can use today. If you did, it might really help to use them to make those discussions more concrete. If you didn't, then calling the proposal a practice might be premature. inline: > Regarding protection at rest: what=E2=80=99s the attacker model in those discussions? XSS? Local attacks on the device? The main concern is XSS. You can just google *token session storage* to find an onslaught of articles and forum threads on the topic. To pick one at random, here's the one from Mozilla . We can argue on what's worse between XSS and URL leaks, but I don't think we can ignore the pervasive ongoing debate and perception that use of local storage for sensitive data is bad. > Much of the mechanisms are platform specific and need platform expertise. I don't follow this one. We are targeting the browser, right? What are the platform specific features you are thinking about? > From the OAuth protocol perspective, impact of RT leakage can be limited through rotation. So I would argue RTs are better protected than ATs. AFAIK relatively few providers today offer RT rotation (Microsoft is an example of widely adopted provider who doesn't), and even if they do: if you steal an RT and use it to get an AT you will enjoy full AT use until the legitimate client attempts a refresh, which will be typically at near expiry time, hence gaining very little. And given that even fewer providers offer access token revocation as a consequence of attempted RT reuse, even more frequent refresh attempts won't reduce the time the attacker has to use the access token they obtained. Hence I am not sure I buy the argument that RTs are better protected than ATs, both from the theoretical perspective and the practical one. And in practical terms, if a developer is tied to a provider that doesn't offer full RT rotation asking them to store RTs will make them worse off than they are today. I am of course all for encouraging providers to introduce proper RT rotation support, but until they do developers receiving this guidance TODAY will be stuck between a rock and a hard place. > Interesting question :-) I think login and API access are quite different. Once again, this is very theoretical :) you, myself and the cohort on this lost can appreciate the difference between the two scenarios- but from most practitioners without identity background, sign out is "the user can't use the app anymore until they enter their credentials again". Whether they implement a proper sign in or go straight to API calling, the visible effect they want to achieve is that one. With implicit today, the access is all predicated on a single artifact- the provider session cookie. If I have two apps in two tabs, signing out from one automatically robs the other from the ability to retain continued access. By introducing another artifact that can provide continued access and whose existence is independent from the session cookie, either I explicitly manage the lifecycle of that artifact (by deleting it at the right time) or my app will simply be able to continue accessing API regardless of the fact that my session with the OP ended. > In the API case, the AS can just revoke the RT when the logout happens. That's just not how that works for many of the big providers, and without introducing new switches I don't think it should. RTs are issued for offline access purposes, hence their lifetime can (and often will) exceed the lifetime of sessions. Borrowing from classic web scenarios, I can sign in and out of twitter as much as I want- that should not affect twitter's ability to call APIs even when I don't have a current session. That's the canonical use case I think of when thinking of RTs. The challenge with SPAs is that successfully calling APIs is often used in lieu of proper sign in; we can repeat until we're blue in the face that this leaves apps prone to confused deputy and the like, but in practice people will keep doing it because to the non-initiated that makes intuitive sense. Hence either we introduce a switch that tells the AS that the RT we are asking for needs to be tied to the session, and manage revocation accordingly, or we manage the persistence of the RT at the application side. The latter seems much easier to achieve to me, and above all more immediately actionable given that I doubt providers will be very prompt in introducing new features like the one hypothesized here. On Thu, Dec 6, 2018 at 4:49 AM Torsten Lodderstedt wrote: > Hi Vittorio, > > > Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci : > > > > Thank you! > > On the RT, more questions: > > > > - where would you save the RT? Iam thinking of the no-backend case in > particular. There=E2=80=99s a lot of heartburn in the community on where = to save > access tokens already, given the larger scope of refresh tokens I would > expect objections there would be exacerbated. > > Interesting, I=E2=80=99m much more concerned about tokens transmitted in = URLs > since those tokens are vulnerable to remote attacks. > > Regarding protection at rest: what=E2=80=99s the attacker model in those > discussions? XSS? Local attacks on the device? > > Much of the mechanisms are platform specific and need platform expertise. > > From the OAuth protocol perspective, impact of RT leakage can be limited > through rotation. So I would argue RTs are better protected than ATs. > > > The user experience bar (number of prompts, full page redirects) should > be the one afforded by implicit leveraging AS sessions via persistent > cookies. > > sure. I don=E2=80=99t see any technical difference in the way the browser= is > utilized for both flows and therefore would be surprised to see differenc= es > in UX. > > > > > - how would we advise developers about handling distributed sign out? I= f > the session cookie with the AS is no longer the only artifact representi= ng > the effective session, it looks like we should be prescriptive on what > signals an app should listen for (OIDC checkSession?) and what the expect= ed > actions are (e.g. remove the cached RTs). I realize this isn=E2=80=99t st= rictly > OAuth2, but it remains an important difference in end to end scenarios > people use implicit for today > > Interesting question :-) I think login and API access are quite different= . > > In login the client potentially wants to tightly couple its session > lifecycle to the AS/OP session, simply because it relies on the user id > attested by the OP=E2=80=99s for its local user/session management. > > For API access, this is not needed. The client =E2=80=9Ejust=E2=80=9C obt= ains a credential > to access certain APIs on behalf of the resource owner. The identity of t= he > resource owner on the AS side and the identity of the client user don=E2= =80=99t > necessary have a relationship. As you know, OAuth was intentionally built > to hide the resource owner identity from the client. I think in this case > the resource owner or the AS might have an interest to terminate API acce= ss > in case of logout at the AS. > > Protocol-wize this result in huge differences: In the login case, the > client can check the session with the OP periodically and terminate its o= wn > session in case the identity changed or there is no longer a session. Thi= s > typically requires frontend interactions and OpenID Connect (session mgmt > or logout). > > In the API case, the AS can just revoke the RT when the logout happens. > > kind regards, > Torsten. > > > > > Thx > > V. > > > > On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > > > > > Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci < > vittorio.bertocci@auth0.com>: > > > >> Hey Torsten/Tomek, > >> Can I ask a clarification on the below? > >> Torsten, you mentioned that an AS doesn't need to issue a RT- the > browser code can just repeat an authorization request. Did I get it right= ? > >> But in order to preserve the user experience, that cannot really happe= n > as a full page redirect; right? That wouldn't fly for any kind of > background update, or for retrieving new ATs for different resources base= d > on the same session. So would we now use a hidden frame to retrieve a cod= e > in the same way in which we used fragments to get new ATs? > > > > That=E2=80=99s what I meant. I also think the RT-based approach is bett= er suited > in terms of UX and security. > > > >> Thx > >> V. > >> > >> On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi Tomek, > >> > >> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki : > >> > > >> > Hi Torsten, > >> > > >> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Loddersted= t > wrote: > >> > > >> > > >> > >> So if I am putting myself in the shoes of somebody who sets out t= o > do that - switch an existing SPA client (no backend) > >> > > >> > > I would like to ask you a question: how many SPAs w/o a backend > have you seen in your projects? > >> > > >> > SPA (html+js) utilizing a 3rd party api that requires authorization? > >> > If you do have a backend, aren't you better of handling the token > request on the backend as pointed out here > >> > > https://github.com/aaronpk/oauth-browser-based-apps/blob/master/oauth-bro= wser-based-apps.md#javascript-app-with-a-backend-component > >> > >> I agree. > >> > >> > My point of putting (no backend) in parenthesis was to not derail > this discussion and of course it had the opposite effect. > >> > > >> > >> You know, I you says =E2=80=9Edon=E2=80=99t look at the green car=E2= =80=9C will cause everyone > looking for it :-) It asked just out of curiosity. > >> > >> > >> Is that fair or is that too much of a shortcut? I am familiar wit= h > the specs you've referenced and have looked at them again, but dealing wi= th > a SPA, some of the recommendations are not feasible (can't authenticate t= he > client, > >> > > >> > > You could using dynamic registration (see other thread). The > protection would only differ from refresh token rotation if you would use > public key crypto for client authentication. > >> > > >> > Good point. How well is dynamic registration supported across AS? > >> > >> I leave that to the vendors :-) > >> > >> > > >> > >> confidentiality in storage? - not sure how to read that in the > context of a browser) > >> > > >> > > How do you ensure confidentiality of session cookies? > >> > > >> > All I am trying to say is that I think context is important here. So > when you point out these best practices, some of them will get people > confused as far as what it means in the browser based app scenario. > >> > >> That=E2=80=99s why we have the more general Security BCP and client-sp= ecific > BCPs, like for native apps (https://tools.ietf.org/html/rfc8252) and the > new BCP for SPAs Aaron started to work on. > >> > >> > Maybe it is just me :) > >> > >> thanks for raising the question! We need this kind of input to govern > the development of our specs. > >> > >> kind regards, > >> Torsten. > >> > >> > > >> > > > >> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Loddersted= t > wrote: > >> > > > >> > > > >> > > Hi Tomek, > >> > > > >> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki 40yahoo.com@dmarc.ietf.org>: > >> > > > > >> > > > I agree with Vittorio, Dominick et al. > >> > > > > >> > > >> I disagree. > >> > > > > >> > > >> Existing deployments that have not mitigated against the > concerns with implicit should be ripped up and updated. > >> > > > > >> > > > Yes, just like future deployments that will not mitigate against > the concerns of code in the browser should be a concern. > >> > > > >> > > I agree. That=E2=80=99s why I pointed point yesterday that the Sec= urity BCP > also defines obligations for clients using code. > >> > > > >> > > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2= .1 > >> > > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2= .1.1 > >> > > > >> > > > > >> > > > Can somebody on the other side of the argument (and I hate to > make it sound like there are two sides, because we're on the same side as > far as Implicit's AT in front-channel is a real issue) address Dominic's > comment: > >> > > > > >> > > >> Also - simply saying =E2=80=9Cimplicit is evil - switch to code= =E2=80=9D means > for most people also using refresh token - so we are treating access toke= ns > in the URL with refresh tokens in session storage (over simplified - but > you get the idea). > >> > > > > >> > > > Does the group agree|disagree that a recommendation to switch to > code should be made as long as it is followed by an explanation and > guidance on what to do with RTs? The ideas that were floated around > >> > > > - Token bound RTs (even though it was pointed out that token > binding is still considered an emerging standard). So should the > recommendation than say "switch to code and MUST use token bound RTs"? > >> > > > - Have AS not release RTs. "Switch to code and DO NOT request > RTs"? Or switch to code and configure AT to not release RTs for this type > of client (not sure what that even looks like in a form of a 3rd party > clients)? > >> > > > - RTs short lived and bound to a session - "Switch to code as > long as AT can bind and revoke RTs when you log out=E2=80=9C > >> > > > >> > > Basically, the AS does not need to issue refresh tokens. If the AS > does not issue refresh tokens, the integration pattern for SPAs does not > change (beside the code exchange). If the client needs a new access token= , > it will perform another authorization request. > >> > > > >> > > If it does, this adds another layer of security because it allows > the client to frequently obtain new access tokens, which can be short-liv= ed > and scope restricted. > >> > > > >> > > The refresh tokens should be replay protected by issuing new > refresh tokens with every refresh and detect replay for refresh tokens > belonging to the same grant. > >> > > > >> > > The AS may additionally bind refresh tokens to AS sessions, but as > it was pointed out by Annabelle and others, there are some implications t= o > be understood and managed in that context. > >> > > > >> > > You may find more text about refresh tokens in the Security BCP > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3= .12 > >> > > > >> > > kind regards, > >> > > Torsten. > >> > > > >> > > > >> > > > > >> > > > Sorry if I have missed an important detail from the list above, > people who have proposed these ideas, feel free to clarify. > >> > > > >> > > > > >> > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt < > dick.hardt@gmail.com> wrote: > >> > > > > >> > > > I disagree. > >> > > > > >> > > > Existing deployments that have not mitigated against the concern= s > with implicit should be ripped up and updated. > >> > > > > >> > > > For example, at one time, I think it was Instagram that had > deployed implicit because it was easier to do. Once the understood the > security implications, they changed the implementation. > >> > > > > >> > > > BCPs are rarely a response to a new threat, their are capturing > Best Current Practices so that they become widely deployed. > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> > > >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. > are saying here. And that was kind of behind the comment I made, or tired > to make, about this in Bangkok, which was (more or less) that I don't thi= nk > the WG should be killing implicit outright but rather that it should begi= n > to recommend against it. > >> > > >> > >> > > >> I'm not exactly sure what that looks like in this document but > maybe toning down some of the scarier language a bit, favoring SHOULDs vs= . > MUSTs, and including language that helps a reader understand the > recommendations as being more considerations for new > applications/deployments than as a mandate to rip up existing ones. > >> > > >> > >> > > >> > >> > > >> > >> > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley > wrote: > >> > > >>> > >> > > >>> We just need to be sensitive to the spin on this. > >> > > >>> > >> > > >> > >> > > >> 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 fi= le > attachments from your computer. Thank > you._______________________________________________ > >> > > >> 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 > >> > > --00000000000045ccf5057c5e68cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Torsten.
I think that a lot of the considera= tions below need to be tempered with concrete considerations about the feat= ures developers can actually rely on today.
I agree with identify= ing the theoretical framework and north star we want to aspire to, but if w= e are framing the recommendation here in form of practice, we have to ensur= e it is actionable for developers. I am not pushing back on ideas, but I ju= st want to make sure that when customers hear this advice, they are actuall= y in the position to apply it. And if there are missing pieces, perhaps we = should consider this more as guidance to the vendors that need to provide k= ey enablers for this to become viable, and recommend it as practice to cust= omers only when that happened.
I add more details inline below, h= owever I have a meta point to make: did all the vendors on the list work= on proof of concepts to ensure that the practices recommended here can wor= k with your product, end to end?=C2=A0
I don't mean just = doing a code+PKCE demo in JS, I mean complying with things like RT rotation= and revocation end to end, using released features that your customers can= use today. If you did, it might really help to use them to make those disc= ussions more concrete. If you didn't, then calling the proposal a pract= ice might be premature.
inline:
=C2=A0

> Regarding protection at rest: what=E2=80=99s the attacker model in = those discussions? XSS? Local attacks on the device?
The main con= cern is XSS. You can just google token session storage to find an on= slaught of articles and forum threads on the topic. To pick one at random, = here's the one from Mozilla.
W= e can argue on what's worse between XSS and URL leaks, but I don't = think we can ignore the pervasive ongoing debate and perception that use of= local storage for sensitive data is bad.


>=C2=A0 Much of the mechanisms are platform specific and need pla= tform expertise.=C2=A0
I don't follow this one. We are target= ing the browser, right? What are the platform specific features you are thi= nking about?


> From the OAuth pr= otocol perspective, impact of RT leakage can be limited through rotation. S= o I would argue RTs are better protected than ATs.
AFAIK relative= ly few providers today offer RT rotation (Microsoft is an example of widely= adopted provider who doesn't), and even if they do: if you steal an RT= and use it to get an AT you will enjoy full AT use until the legitimate cl= ient attempts a refresh, which will be typically at near expiry time, hence= gaining very little. And given that even fewer providers offer access toke= n revocation as a consequence of attempted RT reuse, even more frequent ref= resh attempts won't reduce the time the attacker has to use the access = token they obtained. Hence I am not sure I buy the argument that RTs are be= tter protected than ATs, both from the theoretical perspective and the prac= tical one. And in practical terms, if a developer is tied to a provider tha= t doesn't offer full RT rotation asking them to store RTs will make the= m worse off than they are today. I am of course all for encouraging provide= rs to introduce proper RT rotation support, but until they do developers re= ceiving this guidance TODAY will be stuck between a rock and a hard place.<= /div>

> Interesting question :-) I think login and AP= I access are quite different.=C2=A0
Once again, this is very theo= retical :) you, myself and the cohort on this lost can appreciate the diffe= rence between the two scenarios- but from most practitioners without identi= ty background, sign out is "the user can't use the app anymore unt= il they enter their credentials again". Whether they implement a prope= r sign in or go straight to API calling, the visible effect they want to ac= hieve is that one. With implicit today, the access is all predicated on a s= ingle artifact- the provider session cookie. If I have two apps in two tabs= , signing out from one automatically robs the other from the ability to ret= ain continued access. By introducing another artifact that can provide cont= inued access and whose existence is independent from the session cookie, ei= ther I explicitly manage the lifecycle of that artifact (by deleting it at = the right time) or my app will simply be able to continue accessing API reg= ardless of the fact that my session with the OP ended.

=
> In the API case, the AS can just revoke the RT when the logout ha= ppens.
That's just not how that works for many of the big= providers, and without introducing new switches I don't think it shoul= d. RTs are issued for offline access purposes, hence their lifetime can (an= d often will) exceed the lifetime of sessions. Borrowing from classic web s= cenarios, I can sign in and out of twitter as much as I want- that should n= ot affect twitter's ability to call APIs even when I don't have a c= urrent session. That's the canonical use case I think of when thinking = of RTs.
The challenge with SPAs is that successfully calling APIs= is often used in lieu of proper sign in; we can repeat until we're blu= e in the face that this leaves apps prone to confused deputy and the like, = but in practice people will keep doing it because to the non-initiated that= makes intuitive sense. Hence either we introduce a switch that tells the A= S that the RT we are asking for needs to be tied to the session, and manage= revocation accordingly, or we manage the persistence of the RT at the appl= ication side. The latter seems much easier to achieve to me, and above all = more immediately actionable given that I doubt providers will be very promp= t in introducing new features like the one hypothesized here.=C2=A0


On Thu, D= ec 6, 2018 at 4:49 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Vittorio,

> Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci <Vittorio@auth0.com>:
>
> Thank you!
> On the RT, more questions:
>
> - where would you save the RT? Iam thinking of the no-backend case in = particular. There=E2=80=99s a lot of heartburn in the community on where to= save access tokens already, given the larger scope of refresh tokens I wou= ld expect objections there would be exacerbated.

Interesting, I=E2=80=99m much more concerned about tokens transmitted in UR= Ls since those tokens are vulnerable to remote attacks.

Regarding protection at rest: what=E2=80=99s the attacker model in those di= scussions? XSS? Local attacks on the device?

Much of the mechanisms are platform specific and need platform expertise. <= br>
>From the OAuth protocol perspective, impact of RT leakage can be limited th= rough rotation. So I would argue RTs are better protected than ATs.

> The user experience bar (number of prompts, full page redirects) shoul= d be the one afforded by implicit leveraging AS sessions via persistent coo= kies.

sure. I don=E2=80=99t see any technical difference in the way the browser i= s utilized for both flows and therefore would be surprised to see differenc= es in UX.

>=C2=A0
> - how would we advise developers about handling distributed sign out? = If the session cookie with the AS is no longer=C2=A0 the only artifact repr= esenting the effective session, it looks like we should be prescriptive on = what signals an app should listen for (OIDC checkSession?) and what the exp= ected actions are (e.g. remove the cached RTs). I realize this isn=E2=80=99= t strictly OAuth2, but it remains an important difference in end to end sce= narios people use implicit for today

Interesting question :-) I think login and API access are quite different. =

In login the client potentially wants to tightly couple its session lifecyc= le to the AS/OP session, simply because it relies on the user id attested b= y the OP=E2=80=99s for its local user/session management.

For API access, this is not needed. The client =E2=80=9Ejust=E2=80=9C obtai= ns a credential to access certain APIs on behalf of the resource owner. The= identity of the resource owner on the AS side and the identity of the clie= nt user don=E2=80=99t necessary have a relationship. As you know, OAuth was= intentionally built to hide the resource owner identity from the client. I= think in this case the resource owner or the AS might have an interest to = terminate API access in case of logout at the AS.

Protocol-wize this result in huge differences: In the login case, the clien= t can check the session with the OP periodically and terminate its own sess= ion in case the identity changed or there is no longer a session. This typi= cally requires frontend interactions and OpenID Connect (session mgmt or lo= gout).

In the API case, the AS can just revoke the RT when the logout happens.
kind regards,
Torsten.

>
> Thx
> V.
>
> On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt <torsten@lodderstedt.net>= wrote:
>
>
> Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci <vittorio.bertocci@auth0.com= >:
>
>> Hey Torsten/Tomek,
>> Can I ask a clarification on the below?
>> Torsten, you mentioned that an AS doesn't need to issue a RT- = the browser code can just repeat an authorization request. Did I get it rig= ht?
>> But in order to preserve the user experience, that cannot really h= appen as a full page redirect; right? That wouldn't fly for any kind of= background update, or for retrieving new ATs for different resources based= on the same session. So would we now use a hidden frame to retrieve a code= in the same way in which we used fragments to get new ATs?
>
> That=E2=80=99s what I meant. I also think the RT-based approach is bet= ter suited in terms of UX and security.
>
>> Thx
>> V.
>>
>> On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> Hi Tomek,
>>
>> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki <tstojecki@yahoo.com>:<= br> >> >
>> > Hi Torsten,
>> >
>> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lod= derstedt <t= orsten@lodderstedt.net> wrote:
>> >
>> >
>> > >> So if I am putting myself in the shoes of somebody w= ho sets out to do that - switch an existing SPA client (no backend)
>> >
>> > > I would like to ask you a question: how many SPAs w/o a = backend have you seen in your projects?
>> >
>> > SPA (html+js) utilizing a 3rd party api that requires authori= zation?
>> > If you do have a backend, aren't you better of handling t= he token request on the backend as pointed out here
>> > https://github.com/aaronpk/oau= th-browser-based-apps/blob/master/oauth-browser-based-apps.md#javascript-ap= p-with-a-backend-component
>>
>> I agree.
>>
>> > My point of putting (no backend) in parenthesis was to not de= rail this discussion and of course it had the opposite effect.
>> >
>>
>> You know, I you says =E2=80=9Edon=E2=80=99t look at the green car= =E2=80=9C will cause everyone looking for it :-) It asked just out of curio= sity.
>>
>> > >> Is that fair or is that too much of a shortcut? I am= familiar with the specs you've referenced and have looked at them agai= n, but dealing with a SPA, some of the recommendations are not feasible (ca= n't authenticate the client,
>> >
>> > > You could using dynamic registration (see other thread).= The protection would only differ from refresh token rotation if you would = use public key crypto for client authentication.
>> >
>> > Good point. How well is dynamic registration supported across= AS?
>>
>> I leave that to the vendors :-)
>>
>> >
>> > >> confidentiality in storage? - not sure how to read t= hat in the context of a browser)
>> >
>> > > How do you ensure confidentiality of session cookies? >> >
>> > All I am trying to say is that I think context is important h= ere. So when you point out these best practices, some of them will get peop= le confused as far as what it means in the browser based app scenario.
>>
>> That=E2=80=99s why we have the more general Security BCP and clien= t-specific BCPs, like for native apps (https://tools.ietf.org/htm= l/rfc8252) and the new BCP for SPAs Aaron started to work on.
>>
>> > Maybe it is just me :)
>>
>> thanks for raising the question! We need this kind of input to gov= ern the development of our specs.
>>
>> kind regards,
>> Torsten.
>>
>> >
>> > >
>> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten = Lodderstedt <torsten@lodderstedt.net> wrote:
>> > >
>> > >
>> > > Hi Tomek,
>> > >
>> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki <t= stojecki=3D= 40yahoo.com@dmarc.ietf.org>:
>> > > >
>> > > > I agree with Vittorio, Dominick et al.
>> > > >
>> > > >> I disagree.
>> > > >
>> > > >> Existing deployments that have not mitigated ag= ainst the concerns with implicit should be ripped up and updated.
>> > > >
>> > > > Yes, just like future deployments that will not mit= igate against the concerns of code in the browser should be a concern.
>> > >
>> > > I agree. That=E2=80=99s why I pointed point yesterday th= at the Security BCP also defines obligations for clients using code.
>> > >
>> > > https:= //tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1 >> > > http= s://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1.1
>> > >
>> > > >
>> > > > Can somebody on the other side of the argument (and= I hate to make it sound like there are two sides, because we're on the= same side as far as Implicit's AT in front-channel is a real issue) ad= dress Dominic's comment:
>> > > >
>> > > >> Also - simply saying =E2=80=9Cimplicit is evil = - switch to code=E2=80=9D means for most people also using refresh token - = so we are treating access tokens in the URL with refresh tokens in session = storage (over simplified - but you get the idea).
>> > > >
>> > > > Does the group agree|disagree that a recommendation= to switch to code should be made as long as it is followed by an explanati= on and guidance on what to do with RTs? The ideas that were floated around =
>> > > > - Token bound RTs (even though it was pointed out t= hat token binding is still considered an emerging standard). So should the = recommendation than say "switch to code and MUST use token bound RTs&q= uot;?
>> > > > - Have AS not release RTs. "Switch to code and= DO NOT request RTs"? Or switch to code and configure AT to not releas= e RTs for this type of client (not sure what that even looks like in a form= of a 3rd party clients)?
>> > > > - RTs short lived and bound to a session - "Sw= itch to code as long as AT can bind and revoke RTs when you log out=E2=80= =9C
>> > >
>> > > Basically, the AS does not need to issue refresh tokens.= If the AS does not issue refresh tokens, the integration pattern for SPAs = does not change (beside the code exchange). If the client needs a new acces= s token, it will perform another authorization request.=C2=A0
>> > >
>> > > If it does, this adds another layer of security because = it allows the client to frequently obtain new access tokens, which can be s= hort-lived and scope restricted.
>> > >
>> > > The refresh tokens should be replay protected by issuing= new refresh tokens with every refresh and detect replay for refresh tokens= belonging to the same grant.
>> > >
>> > > The AS may additionally bind refresh tokens to AS sessio= ns, but as it was pointed out by Annabelle and others, there are some impli= cations to be understood and managed in that context.
>> > >
>> > > You may find more text about refresh tokens in the Secur= ity BCP https://tools.ie= tf.org/html/draft-ietf-oauth-security-topics-10#section-3.12
>> > >
>> > > kind regards,
>> > > Torsten.
>> > >
>> > >
>> > > >
>> > > > Sorry if I have missed an important detail from the= list above, people who have proposed these ideas, feel free to clarify. >> > >
>> > > >
>> > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dic= k Hardt <dick.= hardt@gmail.com> wrote:
>> > > >
>> > > > I disagree.
>> > > >
>> > > > Existing deployments that have not mitigated agains= t the concerns with implicit should be ripped up and updated.
>> > > >
>> > > > For example, at one time, I think it was Instagram = that had deployed implicit because it was easier to do. Once the understood= the security implications, they changed the implementation.
>> > > >
>> > > > BCPs are rarely a response to a new threat, their a= re capturing Best Current Practices so that they become widely deployed. >> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell <= bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
>> > > >> FWIW I'm somewhat sympathetic to what Vitto= rio, Dominick, etc. are saying here. And that was kind of behind the commen= t I made, or tired to make, about this in Bangkok, which was (more or less)= that I don't think the WG should be killing implicit outright but rath= er that it should begin to recommend against it.
>> > > >>
>> > > >> I'm not exactly sure what that looks like i= n this document but maybe toning down some of the scarier language a bit, f= avoring SHOULDs vs. MUSTs, and including language that helps a reader under= stand the recommendations as being more considerations for new applications= /deployments than as a mandate to rip up existing ones.
>> > > >>
>> > > >>
>> > > >>
>> > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley <= ;ve7jtb@ve7jtb.com> wrote:
>> > > >>>
>> > > >>> We just need to be sensitive to the spin on= this.=C2=A0
>> > > >>>
>> > > >>
>> > > >> CONFIDENTIALITY NOTICE: This email may contain = confidential and privileged material for the sole use of the intended recip= ient(s). Any review, use, distribution or disclosure by others is strictly = prohibited...=C2=A0 If you have received this communication in error, pleas= e notify the sender immediately by e-mail and delete the message and any fi= le attachments from your computer. Thank you.______________________________= _________________
>> > > >> OAuth mailing list
>> > > >> OAuth@ietf.org
>> > > >> https://www.ietf.org/mailman/= listinfo/oauth
>> > > >>
>> > > > _______________________________________________
>> > > > OAuth mailing list
>> > > > OAuth@ietf.org
>> > > > https://www.ietf.org/mailman/list= info/oauth
>> > > >
>> > > > _______________________________________________
>> > > > OAuth mailing list
>> > > > OAuth@ietf.org
>> > > > https://www.ietf.org/mailman/list= info/oauth
>> > > _______________________________________________
>> > > OAuth mailing list
>> > > OAut= h@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/= oauth
>>

--00000000000045ccf5057c5e68cf-- From nobody Thu Dec 6 10:52:08 2018 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 1383C130E50 for ; Thu, 6 Dec 2018 10:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.758 X-Spam-Level: X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Fdn1v1_WZGPf for ; Thu, 6 Dec 2018 10:52:01 -0800 (PST) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 54CEA130F0D for ; Thu, 6 Dec 2018 10:52:00 -0800 (PST) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wB6ImoR5063809; Thu, 6 Dec 2018 18:51:50 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-2018-07-02; bh=zs2M0audaEl7xseafVmP2f0VbElEX5jVRzrQsXJIO1Q=; b=I4rXjBI9C2WqDv/St7SSmIacmdjxCsdmhvobEorRWi4GmFZSto3IO4OdtnLhqsmI/FSm k8GHmIceItb9j9NVYUoWb1RrjWD4P0roRuhvG4p5Q9bVPv1gevAHjSuiqsWxK+xsETOh q5qNPWFS3fcmG43LMn0b9FZjjgVmg+c0/dfkrTBoi3A34Avxe8NY/up7D/t2bFvOPdpC aHZ66fdaT+8dmRK8mXgROWB1W6tMegMRnt9A9Wgy5fL4TIj7I7JMUdMRiQBOVnenAtVR Fzk+K/w8isdxJlKj6FCdC4kZ/MRJCC0yhHs5oib6Ntnj6A74sCvyLfM6UBrcdSImyZE/ 1w== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2p3hqua1r5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 06 Dec 2018 18:51:50 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wB6Ipmjb021805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 6 Dec 2018 18:51:49 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wB6IpmBf012956; Thu, 6 Dec 2018 18:51:48 GMT Received: from [192.168.1.27] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Dec 2018 10:51:47 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-48FE0E08-608E-4F14-8CFC-F5D4B9E948AC Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Thu, 6 Dec 2018 10:51:46 -0800 Cc: Torsten Lodderstedt , Daniel Fett , IETF oauth WG Content-Transfer-Encoding: 7bit Message-Id: <1D4D8636-9C50-4AA0-BF33-3427FCD0E938@oracle.com> References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> To: Vittorio Bertocci X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9099 signatures=668679 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-1810050000 definitions=main-1812060157 Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 06 Dec 2018 18:52:06 -0000 --Apple-Mail-48FE0E08-608E-4F14-8CFC-F5D4B9E948AC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable While I generally agree with justin that moving everything to the back chann= el is good, I worry that checking user login state may be more important.=20= What if upon refresh of a javascript client the AS would like to check the v= alidity of the current user session? Many implementers solve the user experience issue by using prompt none in th= e oidc authentication case. I seem to remember some oauth providers never im= plemented refresh and they were able to create a good experience.=20 Phil > On Dec 6, 2018, at 10:09 AM, Vittorio Bertocci wrote: >=20 > Thank you Torsten. > I think that a lot of the considerations below need to be tempered with co= ncrete considerations about the features developers can actually rely on tod= ay. > I agree with identifying the theoretical framework and north star we want t= o aspire to, but if we are framing the recommendation here in form of practi= ce, we have to ensure it is actionable for developers. I am not pushing back= on ideas, but I just want to make sure that when customers hear this advice= , they are actually in the position to apply it. And if there are missing pi= eces, perhaps we should consider this more as guidance to the vendors that n= eed to provide key enablers for this to become viable, and recommend it as p= ractice to customers only when that happened. > I add more details inline below, however I have a meta point to make: did a= ll the vendors on the list work on proof of concepts to ensure that the prac= tices recommended here can work with your product, end to end?=20 > I don't mean just doing a code+PKCE demo in JS, I mean complying with thin= gs like RT rotation and revocation end to end, using released features that y= our customers can use today. If you did, it might really help to use them to= make those discussions more concrete. If you didn't, then calling the propo= sal a practice might be premature. > inline: > =20 >=20 > > Regarding protection at rest: what=E2=80=99s the attacker model in those= discussions? XSS? Local attacks on the device? > The main concern is XSS. You can just google token session storage to find= an onslaught of articles and forum threads on the topic. To pick one at ran= dom, here's the one from Mozilla. > We can argue on what's worse between XSS and URL leaks, but I don't think w= e can ignore the pervasive ongoing debate and perception that use of local s= torage for sensitive data is bad. >=20 >=20 > > Much of the mechanisms are platform specific and need platform expertis= e.=20 > I don't follow this one. We are targeting the browser, right? What are the= platform specific features you are thinking about? >=20 >=20 > > =46rom the OAuth protocol perspective, impact of RT leakage can be limit= ed through rotation. So I would argue RTs are better protected than ATs. > AFAIK relatively few providers today offer RT rotation (Microsoft is an ex= ample of widely adopted provider who doesn't), and even if they do: if you s= teal an RT and use it to get an AT you will enjoy full AT use until the legi= timate client attempts a refresh, which will be typically at near expiry tim= e, hence gaining very little. And given that even fewer providers offer acce= ss token revocation as a consequence of attempted RT reuse, even more freque= nt refresh attempts won't reduce the time the attacker has to use the access= token they obtained. Hence I am not sure I buy the argument that RTs are be= tter protected than ATs, both from the theoretical perspective and the pract= ical one. And in practical terms, if a developer is tied to a provider that d= oesn't offer full RT rotation asking them to store RTs will make them worse o= ff than they are today. I am of course all for encouraging providers to intr= oduce proper RT rotation support, but until they do developers receiving thi= s guidance TODAY will be stuck between a rock and a hard place. >=20 > > Interesting question :-) I think login and API access are quite differen= t.=20 > Once again, this is very theoretical :) you, myself and the cohort on this= lost can appreciate the difference between the two scenarios- but from most= practitioners without identity background, sign out is "the user can't use t= he app anymore until they enter their credentials again". Whether they imple= ment a proper sign in or go straight to API calling, the visible effect they= want to achieve is that one. With implicit today, the access is all predica= ted on a single artifact- the provider session cookie. If I have two apps in= two tabs, signing out from one automatically robs the other from the abilit= y to retain continued access. By introducing another artifact that can provi= de continued access and whose existence is independent from the session cook= ie, either I explicitly manage the lifecycle of that artifact (by deleting i= t at the right time) or my app will simply be able to continue accessing API= regardless of the fact that my session with the OP ended. >=20 > > In the API case, the AS can just revoke the RT when the logout happens. > That's just not how that works for many of the big providers, and without i= ntroducing new switches I don't think it should. RTs are issued for offline a= ccess purposes, hence their lifetime can (and often will) exceed the lifetim= e of sessions. Borrowing from classic web scenarios, I can sign in and out o= f twitter as much as I want- that should not affect twitter's ability to cal= l APIs even when I don't have a current session. That's the canonical use ca= se I think of when thinking of RTs. > The challenge with SPAs is that successfully calling APIs is often used in= lieu of proper sign in; we can repeat until we're blue in the face that thi= s leaves apps prone to confused deputy and the like, but in practice people w= ill keep doing it because to the non-initiated that makes intuitive sense. H= ence either we introduce a switch that tells the AS that the RT we are askin= g for needs to be tied to the session, and manage revocation accordingly, or= we manage the persistence of the RT at the application side. The latter see= ms much easier to achieve to me, and above all more immediately actionable g= iven that I doubt providers will be very prompt in introducing new features l= ike the one hypothesized here.=20 >=20 >=20 >> On Thu, Dec 6, 2018 at 4:49 AM Torsten Lodderstedt wrote: >> Hi Vittorio, >>=20 >> > Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci : >> >=20 >> > Thank you! >> > On the RT, more questions: >> >=20 >> > - where would you save the RT? Iam thinking of the no-backend case in p= articular. There=E2=80=99s a lot of heartburn in the community on where to s= ave access tokens already, given the larger scope of refresh tokens I would e= xpect objections there would be exacerbated. >>=20 >> Interesting, I=E2=80=99m much more concerned about tokens transmitted in U= RLs since those tokens are vulnerable to remote attacks.=20 >>=20 >> Regarding protection at rest: what=E2=80=99s the attacker model in those d= iscussions? XSS? Local attacks on the device? >>=20 >> Much of the mechanisms are platform specific and need platform expertise.= =20 >>=20 >> >=46rom the OAuth protocol perspective, impact of RT leakage can be limit= ed through rotation. So I would argue RTs are better protected than ATs. >>=20 >> > The user experience bar (number of prompts, full page redirects) should= be the one afforded by implicit leveraging AS sessions via persistent cooki= es. >>=20 >> sure. I don=E2=80=99t see any technical difference in the way the browser= is utilized for both flows and therefore would be surprised to see differen= ces in UX.=20 >>=20 >> > =20 >> > - how would we advise developers about handling distributed sign out? I= f the session cookie with the AS is no longer the only artifact representin= g the effective session, it looks like we should be prescriptive on what sig= nals an app should listen for (OIDC checkSession?) and what the expected act= ions are (e.g. remove the cached RTs). I realize this isn=E2=80=99t strictly= OAuth2, but it remains an important difference in end to end scenarios peop= le use implicit for today >>=20 >> Interesting question :-) I think login and API access are quite different= .=20 >>=20 >> In login the client potentially wants to tightly couple its session lifec= ycle to the AS/OP session, simply because it relies on the user id attested b= y the OP=E2=80=99s for its local user/session management.=20 >>=20 >> For API access, this is not needed. The client =E2=80=9Ejust=E2=80=9C obt= ains a credential to access certain APIs on behalf of the resource owner. Th= e identity of the resource owner on the AS side and the identity of the clie= nt user don=E2=80=99t necessary have a relationship. As you know, OAuth was i= ntentionally built to hide the resource owner identity from the client. I th= ink in this case the resource owner or the AS might have an interest to term= inate API access in case of logout at the AS.=20 >>=20 >> Protocol-wize this result in huge differences: In the login case, the cli= ent can check the session with the OP periodically and terminate its own ses= sion in case the identity changed or there is no longer a session. This typi= cally requires frontend interactions and OpenID Connect (session mgmt or log= out). >>=20 >> In the API case, the AS can just revoke the RT when the logout happens.=20= >>=20 >> kind regards, >> Torsten.=20 >>=20 >> >=20 >> > Thx >> > V. >> >=20 >> > On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt wrote: >> >=20 >> >=20 >> > Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci : >> >=20 >> >> Hey Torsten/Tomek, >> >> Can I ask a clarification on the below? >> >> Torsten, you mentioned that an AS doesn't need to issue a RT- the brow= ser code can just repeat an authorization request. Did I get it right? >> >> But in order to preserve the user experience, that cannot really happe= n as a full page redirect; right? That wouldn't fly for any kind of backgrou= nd update, or for retrieving new ATs for different resources based on the sa= me session. So would we now use a hidden frame to retrieve a code in the sam= e way in which we used fragments to get new ATs? >> >=20 >> > That=E2=80=99s what I meant. I also think the RT-based approach is bett= er suited in terms of UX and security. >> >=20 >> >> Thx >> >> V. >> >>=20 >> >> On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt wrote: >> >> Hi Tomek,=20 >> >>=20 >> >> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki := >> >> >=20 >> >> > Hi Torsten, >> >> >=20 >> >> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Loddersted= t wrote: >> >> >=20 >> >> >=20 >> >> > >> So if I am putting myself in the shoes of somebody who sets out t= o do that - switch an existing SPA client (no backend) >> >> >=20 >> >> > > I would like to ask you a question: how many SPAs w/o a backend ha= ve you seen in your projects? >> >> >=20 >> >> > SPA (html+js) utilizing a 3rd party api that requires authorization?= >> >> > If you do have a backend, aren't you better of handling the token re= quest on the backend as pointed out here >> >> > https://github.com/aaronpk/oauth-browser-based-apps/blob/master/oaut= h-browser-based-apps.md#javascript-app-with-a-backend-component >> >>=20 >> >> I agree.=20 >> >>=20 >> >> > My point of putting (no backend) in parenthesis was to not derail th= is discussion and of course it had the opposite effect. >> >> >=20 >> >>=20 >> >> You know, I you says =E2=80=9Edon=E2=80=99t look at the green car=E2=80= =9C will cause everyone looking for it :-) It asked just out of curiosity.=20= >> >>=20 >> >> > >> Is that fair or is that too much of a shortcut? I am familiar wit= h the specs you've referenced and have looked at them again, but dealing wit= h a SPA, some of the recommendations are not feasible (can't authenticate th= e client,=20 >> >> >=20 >> >> > > You could using dynamic registration (see other thread). The prote= ction would only differ from refresh token rotation if you would use public k= ey crypto for client authentication. >> >> >=20 >> >> > Good point. How well is dynamic registration supported across AS?=20= >> >>=20 >> >> I leave that to the vendors :-) >> >>=20 >> >> >=20 >> >> > >> confidentiality in storage? - not sure how to read that in the co= ntext of a browser) >> >> >=20 >> >> > > How do you ensure confidentiality of session cookies? >> >> >=20 >> >> > All I am trying to say is that I think context is important here. So= when you point out these best practices, some of them will get people confu= sed as far as what it means in the browser based app scenario. >> >>=20 >> >> That=E2=80=99s why we have the more general Security BCP and client-sp= ecific BCPs, like for native apps (https://tools.ietf.org/html/rfc8252) and t= he new BCP for SPAs Aaron started to work on. >> >>=20 >> >> > Maybe it is just me :) >> >>=20 >> >> thanks for raising the question! We need this kind of input to govern t= he development of our specs. >> >>=20 >> >> kind regards, >> >> Torsten.=20 >> >>=20 >> >> >=20 >> >> > >=20 >> >> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Loddersted= t wrote: >> >> > >=20 >> >> > >=20 >> >> > > Hi Tomek, >> >> > >=20 >> >> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki : >> >> > > >=20 >> >> > > > I agree with Vittorio, Dominick et al.=20 >> >> > > >=20 >> >> > > >> I disagree.=20 >> >> > > >=20 >> >> > > >> Existing deployments that have not mitigated against the concer= ns with implicit should be ripped up and updated. >> >> > > >=20 >> >> > > > Yes, just like future deployments that will not mitigate against= the concerns of code in the browser should be a concern. >> >> > >=20 >> >> > > I agree. That=E2=80=99s why I pointed point yesterday that the Sec= urity BCP also defines obligations for clients using code.=20 >> >> > >=20 >> >> > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#se= ction-2.1 >> >> > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#se= ction-2.1.1 >> >> > >=20 >> >> > > >=20 >> >> > > > Can somebody on the other side of the argument (and I hate to ma= ke it sound like there are two sides, because we're on the same side as far a= s Implicit's AT in front-channel is a real issue) address Dominic's comment:= =20 >> >> > > >=20 >> >> > > >> Also - simply saying =E2=80=9Cimplicit is evil - switch to code= =E2=80=9D means for most people also using refresh token - so we are treatin= g access tokens in the URL with refresh tokens in session storage (over simp= lified - but you get the idea). >> >> > > >=20 >> >> > > > Does the group agree|disagree that a recommendation to switch to= code should be made as long as it is followed by an explanation and guidanc= e on what to do with RTs? The ideas that were floated around=20 >> >> > > > - Token bound RTs (even though it was pointed out that token bin= ding is still considered an emerging standard). So should the recommendation= than say "switch to code and MUST use token bound RTs"? >> >> > > > - Have AS not release RTs. "Switch to code and DO NOT request RT= s"? Or switch to code and configure AT to not release RTs for this type of c= lient (not sure what that even looks like in a form of a 3rd party clients)?= >> >> > > > - RTs short lived and bound to a session - "Switch to code as lo= ng as AT can bind and revoke RTs when you log out=E2=80=9C >> >> > >=20 >> >> > > Basically, the AS does not need to issue refresh tokens. If the AS= does not issue refresh tokens, the integration pattern for SPAs does not ch= ange (beside the code exchange). If the client needs a new access token, it w= ill perform another authorization request. =20 >> >> > >=20 >> >> > > If it does, this adds another layer of security because it allows t= he client to frequently obtain new access tokens, which can be short-lived a= nd scope restricted.=20 >> >> > >=20 >> >> > > The refresh tokens should be replay protected by issuing new refre= sh tokens with every refresh and detect replay for refresh tokens belonging t= o the same grant.=20 >> >> > >=20 >> >> > > The AS may additionally bind refresh tokens to AS sessions, but as= it was pointed out by Annabelle and others, there are some implications to b= e understood and managed in that context. >> >> > >=20 >> >> > > You may find more text about refresh tokens in the Security BCP ht= tps://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.12 >> >> > >=20 >> >> > > kind regards, >> >> > > Torsten. >> >> > >=20 >> >> > >=20 >> >> > > >=20 >> >> > > > Sorry if I have missed an important detail from the list above, p= eople who have proposed these ideas, feel free to clarify.=20 >> >> > >=20 >> >> > > >=20 >> >> > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt wrote:=20 >> >> > > >=20 >> >> > > > I disagree.=20 >> >> > > >=20 >> >> > > > Existing deployments that have not mitigated against the concern= s with implicit should be ripped up and updated. >> >> > > >=20 >> >> > > > For example, at one time, I think it was Instagram that had depl= oyed implicit because it was easier to do. Once the understood the security i= mplications, they changed the implementation.=20 >> >> > > >=20 >> >> > > > BCPs are rarely a response to a new threat, their are capturing B= est Current Practices so that they become widely deployed. >> >> > > >=20 >> >> > > >=20 >> >> > > >=20 >> >> > > >=20 >> >> > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell wrote: >> >> > > >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. a= re saying here. And that was kind of behind the comment I made, or tired to m= ake, about this in Bangkok, which was (more or less) that I don't think the W= G should be killing implicit outright but rather that it should begin to rec= ommend against it.=20 >> >> > > >>=20 >> >> > > >> I'm not exactly sure what that looks like in this document but m= aybe toning down some of the scarier language a bit, favoring SHOULDs vs. MU= STs, and including language that helps a reader understand the recommendatio= ns as being more considerations for new applications/deployments than as a m= andate to rip up existing ones.=20 >> >> > > >>=20 >> >> > > >>=20 >> >> > > >>=20 >> >> > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley = wrote: >> >> > > >>>=20 >> >> > > >>> We just need to be sensitive to the spin on this. =20 >> >> > > >>>=20 >> >> > > >>=20 >> >> > > >> CONFIDENTIALITY NOTICE: This email may contain confidential and= privileged material for the sole use of the intended recipient(s). Any revi= ew, use, distribution or disclosure by others is strictly prohibited... If y= ou 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 c= omputer. Thank you._______________________________________________ >> >> > > >> 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 >> >> > > _______________________________________________ >> >> > > OAuth mailing list >> >> > > OAuth@ietf.org >> >> > > https://www.ietf.org/mailman/listinfo/oauth >> >>=20 >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-48FE0E08-608E-4F14-8CFC-F5D4B9E948AC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
While I generally agree with justin that moving everythi= ng to the back channel is good, I worry that checking user login state may b= e more important. 

What if upon refresh of a= javascript client the AS would like to check the validity of the current us= er session?

Many implementers solve the user experience i= ssue by using prompt none in the oidc authentication case. I seem to remembe= r some oauth providers never implemented refresh and they were able to creat= e a good experience. 

Phil

On Dec 6, 2018, at 10:09 AM, Vitto= rio Bertocci <Vi= ttorio=3D40auth0.com@dmarc.ietf.org> wrote:

Thank you Torsten.
I thin= k that a lot of the considerations below need to be tempered with concrete c= onsiderations about the features developers can actually rely on today.
I agree with identifying the theoretical framework and north star we w= ant to aspire to, but if we are framing the recommendation here in form of p= ractice, we have to ensure it is actionable for developers. I am not pushing= back on ideas, but I just want to make sure that when customers hear this a= dvice, they are actually in the position to apply it. And if there are missi= ng pieces, perhaps we should consider this more as guidance to the vendors t= hat need to provide key enablers for this to become viable, and recommend it= as practice to customers only when that happened.
I add more deta= ils inline below, however I have a meta point to make: did all the vendor= s on the list work on proof of concepts to ensure that the practices recomme= nded here can work with your product, end to end? 
I don'= t mean just doing a code+PKCE demo in JS, I mean complying with things like R= T rotation and revocation end to end, using released features that your cust= omers can use today. If you did, it might really help to use them to make th= ose discussions more concrete. If you didn't, then calling the proposal a pr= actice might be premature.
inline:
 

=
> Regarding protection at rest: what=E2=80=99s the attacker model in= those discussions? XSS? Local attacks on the device?
The main con= cern is XSS. You can just google token session storage to find an ons= laught of articles and forum threads on the topic. To pick one at random, he= re's the one from Mozilla.
We can ar= gue on what's worse between XSS and URL leaks, but I don't think we can igno= re the pervasive ongoing debate and perception that use of local storage for= sensitive data is bad.


>  M= uch of the mechanisms are platform specific and need platform expertise.&nbs= p;
I don't follow this one. We are targeting the browser, right? W= hat are the platform specific features you are thinking about?

> =46rom the OAuth protocol perspective, impac= t of RT leakage can be limited through rotation. So I would argue RTs are be= tter protected than ATs.
AFAIK relatively few providers today offe= r RT rotation (Microsoft is an example of widely adopted provider who doesn'= t), and even if they do: if you steal an RT and use it to get an AT you will= enjoy full AT use until the legitimate client attempts a refresh, which wil= l be typically at near expiry time, hence gaining very little. And given tha= t even fewer providers offer access token revocation as a consequence of att= empted RT reuse, even more frequent refresh attempts won't reduce the time t= he attacker has to use the access token they obtained. Hence I am not sure I= buy the argument that RTs are better protected than ATs, both from the theo= retical perspective and the practical one. And in practical terms, if a deve= loper is tied to a provider that doesn't offer full RT rotation asking them t= o store RTs will make them worse off than they are today. I am of course all= for encouraging providers to introduce proper RT rotation support, but unti= l they do developers receiving this guidance TODAY will be stuck between a r= ock and a hard place.

> Interesting question :-)= I think login and API access are quite different. 
Once agai= n, this is very theoretical :) you, myself and the cohort on this lost can a= ppreciate the difference between the two scenarios- but from most practition= ers without identity background, sign out is "the user can't use the app any= more until they enter their credentials again". Whether they implement a pro= per sign in or go straight to API calling, the visible effect they want to a= chieve is that one. With implicit today, the access is all predicated on a s= ingle artifact- the provider session cookie. If I have two apps in two tabs,= signing out from one automatically robs the other from the ability to retai= n continued access. By introducing another artifact that can provide continu= ed access and whose existence is independent from the session cookie, either= I explicitly manage the lifecycle of that artifact (by deleting it at the r= ight time) or my app will simply be able to continue accessing API regardles= s of the fact that my session with the OP ended.

&g= t; In the API case, the AS can just revoke the RT when the logout happens.
That's just not how that works for many of the big providers, a= nd without introducing new switches I don't think it should. RTs are issued f= or offline access purposes, hence their lifetime can (and often will) exceed= the lifetime of sessions. Borrowing from classic web scenarios, I can sign i= n and out of twitter as much as I want- that should not affect twitter's abi= lity to call APIs even when I don't have a current session. That's the canon= ical use case I think of when thinking of RTs.
The challenge with S= PAs is that successfully calling APIs is often used in lieu of proper sign i= n; we can repeat until we're blue in the face that this leaves apps prone to= confused deputy and the like, but in practice people will keep doing it bec= ause to the non-initiated that makes intuitive sense. Hence either we introd= uce a switch that tells the AS that the RT we are asking for needs to be tie= d to the session, and manage revocation accordingly, or we manage the persis= tence of the RT at the application side. The latter seems much easier to ach= ieve to me, and above all more immediately actionable given that I doubt pro= viders will be very prompt in introducing new features like the one hypothes= ized here. 


On Thu, Dec 6, 2018 at 4:49 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Vittorio,

> Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci <Vittorio@auth0.com>:
>
> Thank you!
> On the RT, more questions:
>
> - where would you save the RT? Iam thinking of the no-backend case in p= articular. There=E2=80=99s a lot of heartburn in the community on where to s= ave access tokens already, given the larger scope of refresh tokens I would e= xpect objections there would be exacerbated.

Interesting, I=E2=80=99m much more concerned about tokens transmitted in URL= s since those tokens are vulnerable to remote attacks.

Regarding protection at rest: what=E2=80=99s the attacker model in those dis= cussions? XSS? Local attacks on the device?

Much of the mechanisms are platform specific and need platform expertise.
>=46rom the OAuth protocol perspective, impact of RT leakage can be limit= ed through rotation. So I would argue RTs are better protected than ATs.
=
> The user experience bar (number of prompts, full page redirects) should= be the one afforded by implicit leveraging AS sessions via persistent cooki= es.

sure. I don=E2=80=99t see any technical difference in the way the browser is= utilized for both flows and therefore would be surprised to see differences= in UX.

> 
> - how would we advise developers about handling distributed sign out? I= f the session cookie with the AS is no longer  the only artifact repres= enting the effective session, it looks like we should be prescriptive on wha= t signals an app should listen for (OIDC checkSession?) and what the expecte= d actions are (e.g. remove the cached RTs). I realize this isn=E2=80=99t str= ictly OAuth2, but it remains an important difference in end to end scenarios= people use implicit for today

Interesting question :-) I think login and API access are quite different. <= br>
In login the client potentially wants to tightly couple its session lifecycl= e to the AS/OP session, simply because it relies on the user id attested by t= he OP=E2=80=99s for its local user/session management.

For API access, this is not needed. The client =E2=80=9Ejust=E2=80=9C obtain= s a credential to access certain APIs on behalf of the resource owner. The i= dentity of the resource owner on the AS side and the identity of the client u= ser don=E2=80=99t necessary have a relationship. As you know, OAuth was inte= ntionally built to hide the resource owner identity from the client. I think= in this case the resource owner or the AS might have an interest to termina= te API access in case of logout at the AS.

Protocol-wize this result in huge differences: In the login case, the client= can check the session with the OP periodically and terminate its own sessio= n in case the identity changed or there is no longer a session. This typical= ly requires frontend interactions and OpenID Connect (session mgmt or logout= ).

In the API case, the AS can just revoke the RT when the logout happens.
=
kind regards,
Torsten.

>
> Thx
> V.
>
> On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt <torsten@lodderstedt.net> w= rote:
>
>
> Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci <vittorio.bertocci@auth0.com>:
>
>> Hey Torsten/Tomek,
>> Can I ask a clarification on the below?
>> Torsten, you mentioned that an AS doesn't need to issue a RT- the b= rowser code can just repeat an authorization request. Did I get it right? >> But in order to preserve the user experience, that cannot really ha= ppen as a full page redirect; right? That wouldn't fly for any kind of backg= round update, or for retrieving new ATs for different resources based on the= same session. So would we now use a hidden frame to retrieve a code in the s= ame way in which we used fragments to get new ATs?
>
> That=E2=80=99s what I meant. I also think the RT-based approach is bett= er suited in terms of UX and security.
>
>> Thx
>> V.
>>
>> On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt <torsten@lodderstedt.net= > wrote:
>> Hi Tomek,
>>
>> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki <tstojecki@yahoo.com>: >> >
>> > Hi Torsten,
>> >
>> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodd= erstedt <tor= sten@lodderstedt.net> wrote:
>> >
>> >
>> > >> So if I am putting myself in the shoes of somebody wh= o sets out to do that - switch an existing SPA client (no backend)
>> >
>> > > I would like to ask you a question: how many SPAs w/o a b= ackend have you seen in your projects?
>> >
>> > SPA (html+js) utilizing a 3rd party api that requires authoriz= ation?
>> > If you do have a backend, aren't you better of handling the to= ken request on the backend as pointed out here
>> > https://github.com/aaronpk/oauth-= browser-based-apps/blob/master/oauth-browser-based-apps.md#javascript-app-wi= th-a-backend-component
>>
>> I agree.
>>
>> > My point of putting (no backend) in parenthesis was to not der= ail this discussion and of course it had the opposite effect.
>> >
>>
>> You know, I you says =E2=80=9Edon=E2=80=99t look at the green car=E2= =80=9C will cause everyone looking for it :-) It asked just out of curiosity= .
>>
>> > >> Is that fair or is that too much of a shortcut? I am f= amiliar with the specs you've referenced and have looked at them again, but d= ealing with a SPA, some of the recommendations are not feasible (can't authe= nticate the client,
>> >
>> > > You could using dynamic registration (see other thread). T= he protection would only differ from refresh token rotation if you would use= public key crypto for client authentication.
>> >
>> > Good point. How well is dynamic registration supported across A= S?
>>
>> I leave that to the vendors :-)
>>
>> >
>> > >> confidentiality in storage? - not sure how to read th= at in the context of a browser)
>> >
>> > > How do you ensure confidentiality of session cookies?
= >> >
>> > All I am trying to say is that I think context is important he= re. So when you point out these best practices, some of them will get people= confused as far as what it means in the browser based app scenario.
>>
>> That=E2=80=99s why we have the more general Security BCP and client= -specific BCPs, like for native apps (https://tools.ietf.org/html/r= fc8252) and the new BCP for SPAs Aaron started to work on.
>>
>> > Maybe it is just me :)
>>
>> thanks for raising the question! We need this kind of input to gove= rn the development of our specs.
>>
>> kind regards,
>> Torsten.
>>
>> >
>> > >
>> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten L= odderstedt <= torsten@lodderstedt.net> wrote:
>> > >
>> > >
>> > > Hi Tomek,
>> > >
>> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki <ts= tojecki=3D40= yahoo.com@dmarc.ietf.org>:
>> > > >
>> > > > I agree with Vittorio, Dominick et al.
>> > > >
>> > > >> I disagree.
>> > > >
>> > > >> Existing deployments that have not mitigated aga= inst the concerns with implicit should be ripped up and updated.
>> > > >
>> > > > Yes, just like future deployments that will not miti= gate against the concerns of code in the browser should be a concern.
>> > >
>> > > I agree. That=E2=80=99s why I pointed point yesterday tha= t the Security BCP also defines obligations for clients using code.
>> > >
>> > > https://= tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1
>> > > https:= //tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1.1<= br> >> > >
>> > > >
>> > > > Can somebody on the other side of the argument (and I= hate to make it sound like there are two sides, because we're on the same s= ide as far as Implicit's AT in front-channel is a real issue) address Domini= c's comment:
>> > > >
>> > > >> Also - simply saying =E2=80=9Cimplicit is evil -= switch to code=E2=80=9D means for most people also using refresh token - so= we are treating access tokens in the URL with refresh tokens in session sto= rage (over simplified - but you get the idea).
>> > > >
>> > > > Does the group agree|disagree that a recommendation t= o switch to code should be made as long as it is followed by an explanation a= nd guidance on what to do with RTs? The ideas that were floated around
>> > > > - Token bound RTs (even though it was pointed out th= at token binding is still considered an emerging standard). So should the re= commendation than say "switch to code and MUST use token bound RTs"?
>> > > > - Have AS not release RTs. "Switch to code and DO NO= T request RTs"? Or switch to code and configure AT to not release RTs for th= is type of client (not sure what that even looks like in a form of a 3rd par= ty clients)?
>> > > > - RTs short lived and bound to a session - "Switch t= o code as long as AT can bind and revoke RTs when you log out=E2=80=9C
>> > >
>> > > Basically, the AS does not need to issue refresh tokens. I= f the AS does not issue refresh tokens, the integration pattern for SPAs doe= s not change (beside the code exchange). If the client needs a new access to= ken, it will perform another authorization request. 
>> > >
>> > > If it does, this adds another layer of security because i= t allows the client to frequently obtain new access tokens, which can be sho= rt-lived and scope restricted.
>> > >
>> > > The refresh tokens should be replay protected by issuing n= ew refresh tokens with every refresh and detect replay for refresh tokens be= longing to the same grant.
>> > >
>> > > The AS may additionally bind refresh tokens to AS session= s, but as it was pointed out by Annabelle and others, there are some implica= tions to be understood and managed in that context.
>> > >
>> > > You may find more text about refresh tokens in the Securi= ty BCP https://tools.ietf.= org/html/draft-ietf-oauth-security-topics-10#section-3.12
>> > >
>> > > kind regards,
>> > > Torsten.
>> > >
>> > >
>> > > >
>> > > > Sorry if I have missed an important detail from the l= ist above, people who have proposed these ideas, feel free to clarify.
>> > >
>> > > >
>> > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick= Hardt <dick.ha= rdt@gmail.com> wrote:
>> > > >
>> > > > I disagree.
>> > > >
>> > > > Existing deployments that have not mitigated against= the concerns with implicit should be ripped up and updated.
>> > > >
>> > > > For example, at one time, I think it was Instagram t= hat had deployed implicit because it was easier to do. Once the understood t= he security implications, they changed the implementation.
>> > > >
>> > > > BCPs are rarely a response to a new threat, their ar= e capturing Best Current Practices so that they become widely deployed.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell <b= campbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
>> > > >> FWIW I'm somewhat sympathetic to what Vittorio, D= ominick, etc. are saying here. And that was kind of behind the comment I mad= e, or tired to make, about this in Bangkok, which was (more or less) that I d= on't think the WG should be killing implicit outright but rather that it sho= uld begin to recommend against it.
>> > > >>
>> > > >> I'm not exactly sure what that looks like in thi= s document but maybe toning down some of the scarier language a bit, favorin= g SHOULDs vs. MUSTs, and including language that helps a reader understand t= he recommendations as being more considerations for new applications/deploym= ents than as a mandate to rip up existing ones.
>> > > >>
>> > > >>
>> > > >>
>> > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley <= ve7jtb@ve7jtb.com= > wrote:
>> > > >>>
>> > > >>> We just need to be sensitive to the spin on t= his. 
>> > > >>>
>> > > >>
>> > > >> CONFIDENTIALITY NOTICE: This email may contain c= onfidential and privileged material for the sole use of the intended recipie= nt(s). Any review, use, distribution or disclosure by others is strictly pro= hibited...  If you have received this communication in error, please no= tify the sender immediately by e-mail and delete the message and any file at= tachments from your computer. Thank you.____________________________________= ___________
>> > > >> OAuth mailing list
>> > > >> OAuth@ietf.org
>> > > >> https://www.ietf.org/mailman/li= stinfo/oauth
>> > > >>
>> > > > _______________________________________________
>> > > > OAuth mailing list
>> > > > = OAuth@ietf.org
>> > > > https://www.ietf.org/mailman/listin= fo/oauth
>> > > >
>> > > > _______________________________________________
>> > > > OAuth mailing list
>> > > > = OAuth@ietf.org
>> > > > https://www.ietf.org/mailman/listin= fo/oauth
>> > > _______________________________________________
>> > > OAuth mailing list
>> > > OAuth= @ietf.org
>> > > https://www.ietf.org/mailman/listinfo/oa= uth
>>

________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-48FE0E08-608E-4F14-8CFC-F5D4B9E948AC-- From nobody Thu Dec 6 12:24:12 2018 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 8A16D1311B0 for ; Thu, 6 Dec 2018 12:24:06 -0800 (PST) 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, HTML_MESSAGE=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 aMxVZhmtQwRM for ; Thu, 6 Dec 2018 12:24:03 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id A23211311BC for ; Thu, 6 Dec 2018 12:24:03 -0800 (PST) Received: from [IPv6:2601:282:202:b210:2872:9222:bdc2:684a] (unknown [IPv6:2601:282:202:b210:2872:9222:bdc2:684a]) by alkaline-solutions.com (Postfix) with ESMTPSA id D2C8731625; Thu, 6 Dec 2018 20:24:02 +0000 (UTC) From: David Waite Content-Type: multipart/alternative; boundary="Apple-Mail=_36FFC1DA-A9F8-417A-99E6-3188E7179764" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 6 Dec 2018 13:24:01 -0700 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> <1D4D8636-9C50-4AA0-BF33-3427FCD0E938@oracle.com> To: Phil Hunt , IETF oauth WG In-Reply-To: <1D4D8636-9C50-4AA0-BF33-3427FCD0E938@oracle.com> Message-Id: <9E0E2FD0-ECE7-4A71-870B-21938B8C267F@alkaline-solutions.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 06 Dec 2018 20:24:11 -0000 --Apple-Mail=_36FFC1DA-A9F8-417A-99E6-3188E7179764 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 One benefit of moving to code flow is that the refresh token can be used = to check the validity of the user session (or rather, it allows the AS = another avenue to force authentication events if the AS considers the = user session to be expired (or has a drop in confidence). There are indeed several ASs which, possibly because of an = interpretation of OIDC, assume refresh tokens mean offline access and = are mutually exclusive with public clients. The ability to have refresh tokens track a user session is an AS = implementation detail, and something that these ASs could choose to = change to over time. In the meantime, there shouldn=E2=80=99t be = anything preventing a client from doing the iframe and prompt=3Dnone = step that they are doing today with implicit. Even if the AS is = implemented in terms of stateless sessions, such functionality can be = implemented by encoding user session information into the =E2=80=9Ccode = token". -DW > On Dec 6, 2018, at 11:51 AM, Phil Hunt wrote: >=20 > While I generally agree with justin that moving everything to the back = channel is good, I worry that checking user login state may be more = important.=20 >=20 > What if upon refresh of a javascript client the AS would like to check = the validity of the current user session? >=20 > Many implementers solve the user experience issue by using prompt none = in the oidc authentication case. I seem to remember some oauth providers = never implemented refresh and they were able to create a good = experience.=20 >=20 > Phil > On Dec 6, 2018, at 7:47 AM, Justin Richer wrote: >=20 > I support the move away from the implicit flow toward using the = authorization code flow (with PKCE and CORS) for JavaScript = applications. The limitations and assumptions that surrounded the design = of the implicit flow back when we started no longer apply today. It was = an optimization for a different time. Technology and platforms have = moved forward, and our advice should move them forward as well. = Furthermore, the ease of using the implicit flow incorrectly, and the = damage that doing so can cause, has driven me to telling people to stop = using it.=20 >=20 > There are a number of hacks that can patch the implicit flow to be = slightly better in various ways =E2=80=94 if you tack on the = =E2=80=9Chybrid=E2=80=9D flow from OIDC or JARM plus post messages and a = bunch of other stuff, then it can be better. But if you=E2=80=99re doing = all of that, I think you really need to ask yourself: why? What do you = gain from jumping through all of those hoops when a viable alternative = sits there? Is it pride? I don=E2=80=99t see why we cling to it. To me, = it=E2=80=99s like saying =E2=80=9Chey sure my leg gets cut off when I do = this, but I can stitch it back on!=E2=80=9D, when you could simply avoid = cutting your leg off in the first place. The best cure is prevention, = and what=E2=80=99s being argued here is prevention. >=20 > So many of OAuth=E2=80=99s problems in the wild come from over-use of = the front channel, and any place we can move away from that is a good = move.=20 >=20 > =E2=80=94 Justin --Apple-Mail=_36FFC1DA-A9F8-417A-99E6-3188E7179764 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 One = benefit of moving to code flow is that the refresh token can be used to = check the validity of the user session (or rather, it allows the AS = another avenue to force authentication events if the AS considers the = user session to be expired (or has a drop in confidence).

There are indeed several = ASs which, possibly because of an interpretation of OIDC, assume refresh = tokens mean offline access and are mutually exclusive with public = clients.

The = ability to have refresh tokens track a user session is an AS = implementation detail, and something that these ASs could choose to = change to over time. In the meantime, there shouldn=E2=80=99t be = anything preventing a client from doing the iframe and prompt=3Dnone = step that they are doing today with implicit. Even if the AS is = implemented in terms of stateless sessions, such functionality can be = implemented by encoding user session information into the =E2=80=9Ccode = token".

-DW

On Dec 6, 2018, at 11:51 AM, = Phil Hunt <phil.hunt@oracle.com> wrote:

While I = generally agree with justin that moving everything to the back channel = is good, I worry that checking user login state may be more = important. 

What = if upon refresh of a javascript client the AS would like to check the = validity of the current user session?

Many implementers solve the user = experience issue by using prompt none in the oidc authentication case. I = seem to remember some oauth providers never implemented refresh and they = were able to create a good experience. 

Phil

On Dec 6, 2018, at 7:47 AM, Justin Richer <jricher@mit.edu> = wrote:

I support the move away from the = implicit flow toward using the authorization code flow (with PKCE and = CORS)  for JavaScript applications. The limitations and assumptions = that surrounded the design of the implicit flow back when we started no = longer apply today. It was an optimization for a different time. = Technology and platforms have moved forward, and our advice should move = them forward as well. Furthermore, the ease of using the implicit flow = incorrectly, and the damage that doing so can cause, has driven me to = telling people to stop using it. 

There are a number of hacks that can = patch the implicit flow to be slightly better in various ways =E2=80=94 = if you tack on the =E2=80=9Chybrid=E2=80=9D flow from OIDC or JARM plus = post messages and a bunch of other stuff, then it can be better. But if = you=E2=80=99re doing all of that, I think you really need to ask = yourself: why? What do you gain from jumping through all of those hoops = when a viable alternative sits there? Is it pride? I don=E2=80=99t see = why we cling to it. To me, it=E2=80=99s like saying =E2=80=9Chey sure my = leg gets cut off when I do this, but I can stitch it back on!=E2=80=9D, = when you could simply avoid cutting your leg off in the first place. The = best cure is prevention, and what=E2=80=99s being argued here is = prevention.

So = many of OAuth=E2=80=99s problems in the wild come from over-use of the = front channel, and any place we can move away from that is a good = move. 

=E2=80=94 = Justin
<= /body>= --Apple-Mail=_36FFC1DA-A9F8-417A-99E6-3188E7179764-- From nobody Thu Dec 6 12:42:39 2018 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 0FF73131195 for ; Thu, 6 Dec 2018 12:42:38 -0800 (PST) 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_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=auth0.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 gdWmAr5Ow8tX for ; Thu, 6 Dec 2018 12:42:35 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 900A3130F90 for ; Thu, 6 Dec 2018 12:42:34 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id s5-v6so1604513ljd.12 for ; Thu, 06 Dec 2018 12:42:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aQR8jynsYW7DJsTRHCT/yg1/sClZyPyGK1kTvgpDHjo=; b=hyqB6K5W2KYDQzSPc+9Jw/hZMtMNxhYMOf7T10T1nlgkwI7Pi1GwH0IED52m8AFrRw eV6vw2fq/q36i9KefgB2n+QS9VksnWMXDVGfpFG73OYFcvih0aivqZKoaL/rh1V01Ah6 hySeBleJSWWPVAzFrgRrPkj4N4216a7JK06wIze+sNlRx8nYQholuuntkBnMA4PlUhip /PJEvmD1n2K1uQVOMKG+R1siQFAR/jg8rP22Kok5+Yy1LF1k9ncVR4wjQAmPvLETg7kJ kniv0HP0BsH4A20ZcsTkM90RTDsUfFBSGu0xqxuNTbRpHEFV3AQbCNno+8eH3BZBr3Nh h8ew== 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=aQR8jynsYW7DJsTRHCT/yg1/sClZyPyGK1kTvgpDHjo=; b=V9VtV+ubFAFJjvhWLUbvRHeK+PwT0UMVaFJsRXW687F9L72t78r5hWzJ5rxCFwBad/ 5zM1BdvK6W4IKgDynbeW84xrOaEZKiFaIFl0S2RS7/mQIx58JcxE8DNud5z5zSeXvBhu fo5jllmpDXKH+GdgAmMFAeB1l6aXbdgFldbAYC+2tGjZsNyGnpWqJ5cH3y6j1hUnW1Eq WPxTke/Ge4R8zAr82tp/8RV4arcmqWnxpYp2jpZlCzILlWoBJZCRaR5zLYEVfP6aNs/q 872NTdexPjLumkiK9Nrvc2ppoi/XpNtL/LgcCdHOZyA0NlqnXK5UIdxQM/m/Mv547K41 6HWg== X-Gm-Message-State: AA+aEWbvR5uby8OhWLpPzgB0bhyzVclT0xVH+3RSDeB6mxD679Cxwrgu FR7/3Jj1bPJOV0JeeSlv8XwPpquEk/BZKrZb2mlGsQ== X-Google-Smtp-Source: AFSGD/VK8TPXr32usqfsTzuaF7O4wobQoRbT6UQgtl21ElYttONxQrwQIKv/QCb/qf6n30bWCuanXMUV45m+LCduOPc= X-Received: by 2002:a2e:568b:: with SMTP id k11-v6mr19850169lje.105.1544128952558; Thu, 06 Dec 2018 12:42:32 -0800 (PST) MIME-Version: 1.0 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> <1D4D8636-9C50-4AA0-BF33-3427FCD0E938@oracle.com> <9E0E2FD0-ECE7-4A71-870B-21938B8C267F@alkaline-solutions.com> In-Reply-To: <9E0E2FD0-ECE7-4A71-870B-21938B8C267F@alkaline-solutions.com> From: Vittorio Bertocci Date: Thu, 6 Dec 2018 12:42:21 -0800 Message-ID: To: David Waite Cc: phil.hunt@oracle.com, IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000b487ca057c608909" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 06 Dec 2018 20:42:38 -0000 --000000000000b487ca057c608909 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > There are indeed several ASs which, possibly because of an interpretation of OIDC, assume refresh tokens mean offline access and are mutually exclusive with public clients. AFAIK both Microsoft and Google do support RTs with public clients, but their lifecycle is independent from the session with the AS (which is represented by an artifact that is only indirectly accessible from traditions public clients such as mobile and desktop apps). As you say, the hidden iframe for retrieving a code via prompt=3Dnone remai= n viable - and if at this time that is the only approach universally available (forgetting ITP2 for a moment) that should be emphasized accordingly in the document. On Thu, Dec 6, 2018 at 12:24 PM David Waite wrote: > One benefit of moving to code flow is that the refresh token can be used > to check the validity of the user session (or rather, it allows the AS > another avenue to force authentication events if the AS considers the use= r > session to be expired (or has a drop in confidence). > > There are indeed several ASs which, possibly because of an interpretation > of OIDC, assume refresh tokens mean offline access and are mutually > exclusive with public clients. > > The ability to have refresh tokens track a user session is an AS > implementation detail, and something that these ASs could choose to chang= e > to over time. In the meantime, there shouldn=E2=80=99t be anything preven= ting a > client from doing the iframe and prompt=3Dnone step that they are doing t= oday > with implicit. Even if the AS is implemented in terms of stateless > sessions, such functionality can be implemented by encoding user session > information into the =E2=80=9Ccode token". > > -DW > > On Dec 6, 2018, at 11:51 AM, Phil Hunt wrote: > > While I generally agree with justin that moving everything to the back > channel is good, I worry that checking user login state may be more > important. > > What if upon refresh of a javascript client the AS would like to check th= e > validity of the current user session? > > Many implementers solve the user experience issue by using prompt none in > the oidc authentication case. I seem to remember some oauth providers nev= er > implemented refresh and they were able to create a good experience. > > Phil > > > On Dec 6, 2018, at 7:47 AM, Justin Richer wrote: > > I support the move away from the implicit flow toward using the > authorization code flow (with PKCE and CORS) for JavaScript applications= . > The limitations and assumptions that surrounded the design of the implici= t > flow back when we started no longer apply today. It was an optimization f= or > a different time. Technology and platforms have moved forward, and our > advice should move them forward as well. Furthermore, the ease of using t= he > implicit flow incorrectly, and the damage that doing so can cause, has > driven me to telling people to stop using it. > > There are a number of hacks that can patch the implicit flow to be > slightly better in various ways =E2=80=94 if you tack on the =E2=80=9Chyb= rid=E2=80=9D flow from > OIDC or JARM plus post messages and a bunch of other stuff, then it can b= e > better. But if you=E2=80=99re doing all of that, I think you really need = to ask > yourself: why? What do you gain from jumping through all of those hoops > when a viable alternative sits there? Is it pride? I don=E2=80=99t see wh= y we cling > to it. To me, it=E2=80=99s like saying =E2=80=9Chey sure my leg gets cut = off when I do > this, but I can stitch it back on!=E2=80=9D, when you could simply avoid = cutting > your leg off in the first place. The best cure is prevention, and what=E2= =80=99s > being argued here is prevention. > > So many of OAuth=E2=80=99s problems in the wild come from over-use of the= front > channel, and any place we can move away from that is a good move. > > =E2=80=94 Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000b487ca057c608909 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> There are indeed several ASs which, possibly because = of an interpretation of OIDC, assume refresh tokens mean offline access and= are mutually exclusive with public clients.
AFAIK both Microsoft and G= oogle do support RTs with public clients, but their lifecycle is independen= t from the session with the AS (which is represented by an artifact that is= only indirectly accessible from traditions public clients such as mobile a= nd desktop apps).

As you say, the hidden iframe fo= r retrieving a code via prompt=3Dnone remain viable - and if at this time t= hat is the only approach universally available (forgetting ITP2 for a momen= t) that should be emphasized accordingly in the document.

On Thu, Dec 6, 2018 at 12:24 PM D= avid Waite <david@alkali= ne-solutions.com> wrote:
One benefit of mo= ving to code flow is that the refresh token can be used to check the validi= ty of the user session (or rather, it allows the AS another avenue to force= authentication events if the AS considers the user session to be expired (= or has a drop in confidence).

There are indeed several A= Ss which, possibly because of an interpretation of OIDC, assume refresh tok= ens mean offline access and are mutually exclusive with public clients.

The ability to have refresh tokens track a user sessi= on is an AS implementation detail, and something that these ASs could choos= e to change to over time. In the meantime, there shouldn=E2=80=99t be anyth= ing preventing a client from doing the iframe and prompt=3Dnone step that t= hey are doing today with implicit. Even if the AS is implemented in terms o= f stateless sessions, such functionality can be implemented by encoding use= r session information into the =E2=80=9Ccode token".

-DW

On Dec 6, = 2018, at 11:51 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

While I generally ag= ree with justin that moving everything to the back channel is good, I worry= that checking user login state may be more important.=C2=A0

What if upon refresh of a javascript client the AS would like = to check the validity of the current user session?

Many = implementers solve the user experience issue by using prompt none in the oi= dc authentication case. I seem to remember some oauth providers never imple= mented refresh and they were able to create a good experience.=C2=A0

Phil

On Dec 6, 2018, at 7:47 AM, Justin= Richer <jricher@mi= t.edu> wrote:

I support = the move away from the implicit flow toward using the authorization code fl= ow (with PKCE and CORS) =C2=A0for JavaScript applications. The limitations = and assumptions that surrounded the design of the implicit flow back when w= e started no longer apply today. It was an optimization for a different tim= e. Technology and platforms have moved forward, and our advice should move = them forward as well. Furthermore, the ease of using the implicit flow inco= rrectly, and the damage that doing so can cause, has driven me to telling p= eople to stop using it.=C2=A0

There are a number of hack= s that can patch the implicit flow to be slightly better in various ways = =E2=80=94 if you tack on the =E2=80=9Chybrid=E2=80=9D flow from OIDC or JAR= M plus post messages and a bunch of other stuff, then it can be better. But= if you=E2=80=99re doing all of that, I think you really need to ask yourse= lf: why? What do you gain from jumping through all of those hoops when a vi= able alternative sits there? Is it pride? I don=E2=80=99t see why we cling = to it. To me, it=E2=80=99s like saying =E2=80=9Chey sure my leg gets cut of= f when I do this, but I can stitch it back on!=E2=80=9D, when you could sim= ply avoid cutting your leg off in the first place. The best cure is prevent= ion, and what=E2=80=99s being argued here is prevention.

So many of OAuth=E2=80=99s problems in the wild come from over-use o= f the front channel, and any place we can move away from that is a good mov= e.=C2=A0

=E2=80=94 Justin
____________________________= ___________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000b487ca057c608909-- From nobody Thu Dec 6 12:54:11 2018 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 6F5AC130E68 for ; Thu, 6 Dec 2018 12:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.759 X-Spam-Level: X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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 hcjJbxq69A6j for ; Thu, 6 Dec 2018 12:54:06 -0800 (PST) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 214E8130EDA for ; Thu, 6 Dec 2018 12:54:06 -0800 (PST) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wB6Ks4bG161200; Thu, 6 Dec 2018 20:54:04 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=7nLLVKixEtSJq7eaSx11/V3TUU3gR22DUY9TbMd0zRE=; b=O2LZ586p88FafESIsDGyHKaZo2bygeuiq/sQoOQ5S36rcYgGY7pKK3zkBP12izrNOPlG RxRfqDTAJC0s5DCN50xU4O6z5lQMMvafUzlhHEB8Rd3RS/32BLLwM3/8qVQG1vaHSqyA 8S+ajR15SNRjhHy6Qa2WbsH0PeOMxeiYgdfufo7tmqLGzy3ssL9b+Iv5s3VQeHFlzFjR 9RF0vwDsktzwgiBS1yEnVfKkg6cSi+R8pHtptYOZDrzp65zI9eXF2/CCcJ+294AZ3my2 EE+dImzmoGU2bdUgkgfmbUmdfLIGbEcafSwei89rkiQ6lYd63QNRhf79fakbkeQxHXO+ ag== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2p3hquaj8h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 06 Dec 2018 20:54:03 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wB6Ks09b031456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 6 Dec 2018 20:54:00 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wB6Ks0Uf023776; Thu, 6 Dec 2018 20:54:00 GMT Received: from [192.168.1.19] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Dec 2018 20:53:59 +0000 From: Phil Hunt Message-Id: <8A2BC516-69AA-4CDB-A31E-5AF59FBA9CF0@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7FA2A710-3CA6-483E-AAAF-747524F409A3" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Thu, 6 Dec 2018 12:53:57 -0800 In-Reply-To: <9E0E2FD0-ECE7-4A71-870B-21938B8C267F@alkaline-solutions.com> Cc: IETF oauth WG To: David Waite References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> <1D4D8636-9C50-4AA0-BF33-3427FCD0E938@oracle.com> <9E0E2FD0-ECE7-4A71-870B-21938B8C267F@alkaline-solutions.com> X-Mailer: Apple Mail (2.3445.101.1) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9099 signatures=668679 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-1810050000 definitions=main-1812060175 Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 06 Dec 2018 20:54:09 -0000 --Apple-Mail=_7FA2A710-3CA6-483E-AAAF-747524F409A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 How would the token endpoint detect login status of the user? Phil Oracle Corporation, Cloud Security and Identity Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Dec 6, 2018, at 12:24 PM, David Waite = wrote: >=20 > One benefit of moving to code flow is that the refresh token can be = used to check the validity of the user session (or rather, it allows the = AS another avenue to force authentication events if the AS considers the = user session to be expired (or has a drop in confidence). >=20 > There are indeed several ASs which, possibly because of an = interpretation of OIDC, assume refresh tokens mean offline access and = are mutually exclusive with public clients. >=20 > The ability to have refresh tokens track a user session is an AS = implementation detail, and something that these ASs could choose to = change to over time. In the meantime, there shouldn=E2=80=99t be = anything preventing a client from doing the iframe and prompt=3Dnone = step that they are doing today with implicit. Even if the AS is = implemented in terms of stateless sessions, such functionality can be = implemented by encoding user session information into the =E2=80=9Ccode = token". >=20 > -DW >=20 >> On Dec 6, 2018, at 11:51 AM, Phil Hunt > wrote: >>=20 >> While I generally agree with justin that moving everything to the = back channel is good, I worry that checking user login state may be more = important.=20 >>=20 >> What if upon refresh of a javascript client the AS would like to = check the validity of the current user session? >>=20 >> Many implementers solve the user experience issue by using prompt = none in the oidc authentication case. I seem to remember some oauth = providers never implemented refresh and they were able to create a good = experience.=20 >>=20 >> Phil >=20 >=20 >> On Dec 6, 2018, at 7:47 AM, Justin Richer > wrote: >>=20 >> I support the move away from the implicit flow toward using the = authorization code flow (with PKCE and CORS) for JavaScript = applications. The limitations and assumptions that surrounded the design = of the implicit flow back when we started no longer apply today. It was = an optimization for a different time. Technology and platforms have = moved forward, and our advice should move them forward as well. = Furthermore, the ease of using the implicit flow incorrectly, and the = damage that doing so can cause, has driven me to telling people to stop = using it.=20 >>=20 >> There are a number of hacks that can patch the implicit flow to be = slightly better in various ways =E2=80=94 if you tack on the = =E2=80=9Chybrid=E2=80=9D flow from OIDC or JARM plus post messages and a = bunch of other stuff, then it can be better. But if you=E2=80=99re doing = all of that, I think you really need to ask yourself: why? What do you = gain from jumping through all of those hoops when a viable alternative = sits there? Is it pride? I don=E2=80=99t see why we cling to it. To me, = it=E2=80=99s like saying =E2=80=9Chey sure my leg gets cut off when I do = this, but I can stitch it back on!=E2=80=9D, when you could simply avoid = cutting your leg off in the first place. The best cure is prevention, = and what=E2=80=99s being argued here is prevention. >>=20 >> So many of OAuth=E2=80=99s problems in the wild come from over-use of = the front channel, and any place we can move away from that is a good = move.=20 >>=20 >> =E2=80=94 Justin --Apple-Mail=_7FA2A710-3CA6-483E-AAAF-747524F409A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
How would the token endpoint detect login status of the = user?

Phil

Oracle Corporation, Cloud Security and = Identity Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Dec 6, 2018, at 12:24 PM, David Waite <david@alkaline-solutions.com> wrote:

One benefit of moving = to code flow is that the refresh token can be used to check the validity = of the user session (or rather, it allows the AS another avenue to force = authentication events if the AS considers the user session to be expired = (or has a drop in confidence).

There are indeed several ASs which, possibly because of an = interpretation of OIDC, assume refresh tokens mean offline access and = are mutually exclusive with public clients.

The ability to have refresh tokens = track a user session is an AS implementation detail, and something that = these ASs could choose to change to over time. In the meantime, there = shouldn=E2=80=99t be anything preventing a client from doing the iframe = and prompt=3Dnone step that they are doing today with implicit. Even if = the AS is implemented in terms of stateless sessions, such functionality = can be implemented by encoding user session information into the =E2=80=9C= code token".

-DW

On Dec 6, 2018, at 11:51 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

While I = generally agree with justin that moving everything to the back channel = is good, I worry that checking user login state may be more = important. 

What = if upon refresh of a javascript client the AS would like to check the = validity of the current user session?

Many implementers solve the user = experience issue by using prompt none in the oidc authentication case. I = seem to remember some oauth providers never implemented refresh and they = were able to create a good experience. 

Phil

On Dec 6, 2018, at 7:47 AM, Justin Richer <jricher@mit.edu> = wrote:

I support the move away from the = implicit flow toward using the authorization code flow (with PKCE and = CORS)  for JavaScript applications. The limitations and assumptions = that surrounded the design of the implicit flow back when we started no = longer apply today. It was an optimization for a different time. = Technology and platforms have moved forward, and our advice should move = them forward as well. Furthermore, the ease of using the implicit flow = incorrectly, and the damage that doing so can cause, has driven me to = telling people to stop using it. 

There are a number of hacks that can = patch the implicit flow to be slightly better in various ways =E2=80=94 = if you tack on the =E2=80=9Chybrid=E2=80=9D flow from OIDC or JARM plus = post messages and a bunch of other stuff, then it can be better. But if = you=E2=80=99re doing all of that, I think you really need to ask = yourself: why? What do you gain from jumping through all of those hoops = when a viable alternative sits there? Is it pride? I don=E2=80=99t see = why we cling to it. To me, it=E2=80=99s like saying =E2=80=9Chey sure my = leg gets cut off when I do this, but I can stitch it back on!=E2=80=9D, = when you could simply avoid cutting your leg off in the first place. The = best cure is prevention, and what=E2=80=99s being argued here is = prevention.

So = many of OAuth=E2=80=99s problems in the wild come from over-use of the = front channel, and any place we can move away from that is a good = move. 

=E2=80=94 = Justin
<= /div>

= --Apple-Mail=_7FA2A710-3CA6-483E-AAAF-747524F409A3-- From nobody Thu Dec 6 17:36:45 2018 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 6507512D4E8 for ; Thu, 6 Dec 2018 17:36:44 -0800 (PST) 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, HTML_MESSAGE=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 vnYBK1QYSnnv for ; Thu, 6 Dec 2018 17:36:38 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 941B612426E for ; Thu, 6 Dec 2018 17:36:38 -0800 (PST) Received: from [IPv6:2601:282:202:b210:f870:3ebd:54b2:bbd3] (unknown [IPv6:2601:282:202:b210:f870:3ebd:54b2:bbd3]) by alkaline-solutions.com (Postfix) with ESMTPSA id EA63B31625; Fri, 7 Dec 2018 01:36:36 +0000 (UTC) From: David Waite Message-Id: <9BC47817-C6E5-4B44-B27A-AA5EA1889BD0@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6766468B-C803-4D79-9F42-54717B024F64" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 6 Dec 2018 18:36:35 -0700 In-Reply-To: <8A2BC516-69AA-4CDB-A31E-5AF59FBA9CF0@oracle.com> Cc: IETF oauth WG To: Phil Hunt References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> <1D4D8636-9C50-4AA0-BF33-3427FCD0E938@oracle.com> <9E0E2FD0-ECE7-4A71-870B-21938B8C267F@alkaline-solutions.com> <8A2BC516-69AA-4CDB-A31E-5AF59FBA9CF0@oracle.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 07 Dec 2018 01:36:44 -0000 --Apple-Mail=_6766468B-C803-4D79-9F42-54717B024F64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 For systems with stateful sessions, you could reference that via the = refresh token. If the access tokens are opaque to protected resources = and meant to be used via introspection, you could also reference the = state there as well. For systems with stateteless sessions (e.g. JWT cookies), you have fewer = options. A non-exhaustive list: 1. The refresh token can be modeled after a static user session policy, = e.g. refresh will fail in four hours 2. Refresh tokens may have a sliding window within that policy, e.g. = this refresh token is good for 30 minutes, but on refresh one will be = issued good for another 30 minutes or the end of the four hour window, = whichever is sooner 3. You can have a stateful system just for token revocations. This could = reference a single session, or all sessions for the user (possibly under = a specific client) generated before a particular time. The refresh (and = possibly access) tokens would also have the same information in them for = lookup. Logout could add an entry to this revocation list. An aside: This is kinda/sorta a similar line of thinking that lead to DTVA ( = https://bitbucket.org/openid/connect/raw/f76ffe99c47d4698bc2995c32dc7a402d= d6e8c47/distributed-token-validity-api.txt = ). The =E2=80=9CDistributed=E2= =80=9D part was about pushing the ability to validate access and = id_tokens close to the protected resources/RPs. The goal was also to = build an API that supported this sort of token validation by otherwise = stateless apps. It wasn=E2=80=99t expected that refresh tokens were based on this system = - we envisioned most AS/IDP instances to be built for authentication, = and therefore already have requirements and business processes that = would require more complex / stateful sessions. -DW > On Dec 6, 2018, at 1:53 PM, Phil Hunt wrote: >=20 > How would the token endpoint detect login status of the user? >=20 > Phil >=20 > Oracle Corporation, Cloud Security and Identity Architect > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >> On Dec 6, 2018, at 12:24 PM, David Waite = > = wrote: >>=20 >> One benefit of moving to code flow is that the refresh token can be = used to check the validity of the user session (or rather, it allows the = AS another avenue to force authentication events if the AS considers the = user session to be expired (or has a drop in confidence). >>=20 >> There are indeed several ASs which, possibly because of an = interpretation of OIDC, assume refresh tokens mean offline access and = are mutually exclusive with public clients. >>=20 >> The ability to have refresh tokens track a user session is an AS = implementation detail, and something that these ASs could choose to = change to over time. In the meantime, there shouldn=E2=80=99t be = anything preventing a client from doing the iframe and prompt=3Dnone = step that they are doing today with implicit. Even if the AS is = implemented in terms of stateless sessions, such functionality can be = implemented by encoding user session information into the =E2=80=9Ccode = token". >>=20 >> -DW >>=20 >>> On Dec 6, 2018, at 11:51 AM, Phil Hunt > wrote: >>>=20 >>> While I generally agree with justin that moving everything to the = back channel is good, I worry that checking user login state may be more = important.=20 >>>=20 >>> What if upon refresh of a javascript client the AS would like to = check the validity of the current user session? >>>=20 >>> Many implementers solve the user experience issue by using prompt = none in the oidc authentication case. I seem to remember some oauth = providers never implemented refresh and they were able to create a good = experience.=20 >>>=20 >>> Phil >>=20 >>=20 >>> On Dec 6, 2018, at 7:47 AM, Justin Richer > wrote: >>>=20 >>> I support the move away from the implicit flow toward using the = authorization code flow (with PKCE and CORS) for JavaScript = applications. The limitations and assumptions that surrounded the design = of the implicit flow back when we started no longer apply today. It was = an optimization for a different time. Technology and platforms have = moved forward, and our advice should move them forward as well. = Furthermore, the ease of using the implicit flow incorrectly, and the = damage that doing so can cause, has driven me to telling people to stop = using it.=20 >>>=20 >>> There are a number of hacks that can patch the implicit flow to be = slightly better in various ways =E2=80=94 if you tack on the = =E2=80=9Chybrid=E2=80=9D flow from OIDC or JARM plus post messages and a = bunch of other stuff, then it can be better. But if you=E2=80=99re doing = all of that, I think you really need to ask yourself: why? What do you = gain from jumping through all of those hoops when a viable alternative = sits there? Is it pride? I don=E2=80=99t see why we cling to it. To me, = it=E2=80=99s like saying =E2=80=9Chey sure my leg gets cut off when I do = this, but I can stitch it back on!=E2=80=9D, when you could simply avoid = cutting your leg off in the first place. The best cure is prevention, = and what=E2=80=99s being argued here is prevention. >>>=20 >>> So many of OAuth=E2=80=99s problems in the wild come from over-use = of the front channel, and any place we can move away from that is a good = move.=20 >>>=20 >>> =E2=80=94 Justin >=20 --Apple-Mail=_6766468B-C803-4D79-9F42-54717B024F64 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
For systems with stateful sessions, you could reference that = via the refresh token. If the access tokens are opaque to protected = resources and meant to be used via introspection, you could also = reference the state there as well.

For systems with stateteless sessions = (e.g. JWT cookies), you have fewer options. A non-exhaustive = list:
1. The refresh token can be modeled after a = static user session policy, e.g. refresh will fail in four = hours
2. Refresh tokens may have a sliding window = within that policy, e.g. this refresh token is good for 30 minutes, but = on refresh one will be issued good for another 30 minutes or the end of = the four hour window, whichever is sooner
3. You = can have a stateful system just for token revocations. This could = reference a single session, or all sessions for the user (possibly under = a specific client) generated before a particular time. The refresh (and = possibly access) tokens would also have the same information in them for = lookup. Logout could add an entry to this revocation list.

An aside:

This is kinda/sorta a =  similar line of thinking that lead to DTVA ( https://bitbucket.org/openid/connect/raw/f76ffe99c47d4698bc2995= c32dc7a402dd6e8c47/distributed-token-validity-api.txt ). The = =E2=80=9CDistributed=E2=80=9D part was about pushing the ability to = validate access and id_tokens close to the protected resources/RPs. The = goal was also to build an API that supported this sort of token = validation by otherwise stateless apps.

It wasn=E2=80=99t expected that refresh = tokens were based on this system - we envisioned most AS/IDP instances = to be built for authentication, and therefore already have requirements = and business processes that would require more complex / stateful = sessions.

-DW

On = Dec 6, 2018, at 1:53 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

How = would the token endpoint detect login status of the user?

Phil

Oracle Corporation, Cloud Security and Identity = Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Dec 6, 2018, at 12:24 PM, David Waite <david@alkaline-solutions.com> wrote:

One benefit of moving = to code flow is that the refresh token can be used to check the validity = of the user session (or rather, it allows the AS another avenue to force = authentication events if the AS considers the user session to be expired = (or has a drop in confidence).

There are indeed several ASs which, possibly because of an = interpretation of OIDC, assume refresh tokens mean offline access and = are mutually exclusive with public clients.

The ability to have refresh tokens = track a user session is an AS implementation detail, and something that = these ASs could choose to change to over time. In the meantime, there = shouldn=E2=80=99t be anything preventing a client from doing the iframe = and prompt=3Dnone step that they are doing today with implicit. Even if = the AS is implemented in terms of stateless sessions, such functionality = can be implemented by encoding user session information into the =E2=80=9C= code token".

-DW

On Dec 6, 2018, at 11:51 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

While I = generally agree with justin that moving everything to the back channel = is good, I worry that checking user login state may be more = important. 

What = if upon refresh of a javascript client the AS would like to check the = validity of the current user session?

Many implementers solve the user = experience issue by using prompt none in the oidc authentication case. I = seem to remember some oauth providers never implemented refresh and they = were able to create a good experience. 

Phil

On Dec 6, 2018, at 7:47 AM, Justin Richer <jricher@mit.edu> = wrote:

I support the move away from the = implicit flow toward using the authorization code flow (with PKCE and = CORS)  for JavaScript applications. The limitations and assumptions = that surrounded the design of the implicit flow back when we started no = longer apply today. It was an optimization for a different time. = Technology and platforms have moved forward, and our advice should move = them forward as well. Furthermore, the ease of using the implicit flow = incorrectly, and the damage that doing so can cause, has driven me to = telling people to stop using it. 

There are a number of hacks that can = patch the implicit flow to be slightly better in various ways =E2=80=94 = if you tack on the =E2=80=9Chybrid=E2=80=9D flow from OIDC or JARM plus = post messages and a bunch of other stuff, then it can be better. But if = you=E2=80=99re doing all of that, I think you really need to ask = yourself: why? What do you gain from jumping through all of those hoops = when a viable alternative sits there? Is it pride? I don=E2=80=99t see = why we cling to it. To me, it=E2=80=99s like saying =E2=80=9Chey sure my = leg gets cut off when I do this, but I can stitch it back on!=E2=80=9D, = when you could simply avoid cutting your leg off in the first place. The = best cure is prevention, and what=E2=80=99s being argued here is = prevention.

So = many of OAuth=E2=80=99s problems in the wild come from over-use of the = front channel, and any place we can move away from that is a good = move. 

=E2=80=94 = Justin
<= /div>


= --Apple-Mail=_6766468B-C803-4D79-9F42-54717B024F64-- From nobody Fri Dec 7 04:51:03 2018 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 0DD5112DD85 for ; Fri, 7 Dec 2018 04:51:01 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode.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 djjgdAaUUORb for ; Fri, 7 Dec 2018 04:50:55 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 63F9A12D4F1 for ; Fri, 7 Dec 2018 04:50:55 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id w12so2311030qkb.9 for ; Fri, 07 Dec 2018 04:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UtHFsCfn0VNHP2VCFC5LK7RjOnyfoejquj/oR3lvxnA=; b=M8MJGhNSen1+ZMrtYwSkfNO2/xo82v3mVj18Ypwm2ey1lkbsyjSu0eTVc8/DH3+Qzx Wri/lO9+cpsKkW7otMatIZVL0OU65OGDHyQZpv6gmLI8+Qx/cQznM6aNa8iOQx6uWEA0 ymKUkguzBS0Dus6+W/K6G57jE8S/njl/I78uMYcyGBVFlSgcuPTM+qpRgiic8PMN+vfN 77aAfxda3SIoAzWku4SNcBm+z1hGBBXjfMS+IMtorYrTemAQykftvnhJPYy2q93LuuG9 +Sejm9eXNxVntNeo7BAWHhNPYXQhZPUIYkGnlNmtg+WIyumOva+O2ZrAI4v7dKKCY0OQ TeEg== 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=UtHFsCfn0VNHP2VCFC5LK7RjOnyfoejquj/oR3lvxnA=; b=qTAtjX+RCdkHWE2/qY6Ve8XCJcrs9/4g4kyWpSWxikEi2QLfsdD0Ri+lKjf5IF75XJ A1JxTFO/v9cg8wx+Cpf/u8OSfx5DSLlo5Mc2moxYql770JXueeYsfEVwberidwynj5hE qqsw4J0DIe901L7ebdkx2/ggY1pe7X56zHl4SJwq8HqSwZd133xcTWaGoaE6H0QjxvdP o9KjtAzLdtncFm+yp/EQu+57oYLh4+5sCQZgaEE8vgZXepfOSVnJJbuM+u+PPo4PNKrd IMrKDSLFQ+A32EsvQfCySQ55UH1Adqc70sPsFRpc8UJk3/9KSbCzmCd4SDSf288KcsNf YiZA== X-Gm-Message-State: AA+aEWad2i4w2Z8JG6WiVfY+WOl2GkDS9ehiXQEr84YJjh2cM7UjC70L YhZHba38A2a7qov9eM9hLQ8cn7nYrwE= X-Google-Smtp-Source: AFSGD/VJi2RIoXaLltpjcalV+ykc3Uo6s4iqqFjTyRO06s1OSpEKW/hHTj7vhqmayS58l2++8fQWzA== X-Received: by 2002:a37:3a04:: with SMTP id h4mr1607161qka.53.1544187054181; Fri, 07 Dec 2018 04:50:54 -0800 (PST) Received: from [10.38.127.203] (mobile-107-107-56-28.mycingular.net. [107.107.56.28]) by smtp.gmail.com with ESMTPSA id 21sm3192173qkr.89.2018.12.07.04.50.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Dec 2018 04:50:53 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-43286FD2-6D5F-4688-A310-B40511E65D54 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (16C50) In-Reply-To: Date: Fri, 7 Dec 2018 07:50:51 -0500 Cc: Torsten Lodderstedt , Daniel Fett , IETF oauth WG Content-Transfer-Encoding: 7bit Message-Id: References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> To: Vittorio Bertocci Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 07 Dec 2018 12:51:01 -0000 --Apple-Mail-43286FD2-6D5F-4688-A310-B40511E65D54 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I wanted to address Vittorio=E2=80=99s comment on XSS and LocalStorage. One XSS attack can extract all of LocalStorage in one line of code. It=E2=80= =99s trivial. And after studying XSS for years, I believe that most develope= rs are not capable of building good XSS defense into complex UI=E2=80=99s an= d the trends to use Angular and React are not helping the situation; they ju= st move the problem around. Sure, few dev teams who have VERY specialized and rare developer resources c= an build XSS resistant apps, if they know how to properly escape, sanitize, v= alidate, use safe JS, embed JSON properly, use sandboxing properly, and buil= d unique CSP policies per page. And for most, good luck with that. This is why I still hold onto the belief that OAuth solutions that store tok= ens in the browser for high risk apps is a bad idea.=20 I still encourage developers who are not XSS guru=E2=80=99s to stick to cook= ie based sessions or stateless artifacts to talk to the back end and keep OA= uth tokens only flying intra-server. It=E2=80=99s an unpopular opinion, but e= ven moderately good XSS defense is equally unpopular. At OWASP there are =E2=80=A2several=E2=80=A2 guides you need to master to un= derstand XSS defense. And this does not even scratch the surface of what is n= eeded to master XSS defense in React/Angular, not to mention the complexity o= f CSP which requires per-page policies. https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Ch= eat_Sheet https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet Unpopularity yours, -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On Dec 6, 2018, at 1:09 PM, Vittorio Bertocci wrote: >=20 > Thank you Torsten. > I think that a lot of the considerations below need to be tempered with co= ncrete considerations about the features developers can actually rely on tod= ay. > I agree with identifying the theoretical framework and north star we want t= o aspire to, but if we are framing the recommendation here in form of practi= ce, we have to ensure it is actionable for developers. I am not pushing back= on ideas, but I just want to make sure that when customers hear this advice= , they are actually in the position to apply it. And if there are missing pi= eces, perhaps we should consider this more as guidance to the vendors that n= eed to provide key enablers for this to become viable, and recommend it as p= ractice to customers only when that happened. > I add more details inline below, however I have a meta point to make: did a= ll the vendors on the list work on proof of concepts to ensure that the prac= tices recommended here can work with your product, end to end?=20 > I don't mean just doing a code+PKCE demo in JS, I mean complying with thin= gs like RT rotation and revocation end to end, using released features that y= our customers can use today. If you did, it might really help to use them to= make those discussions more concrete. If you didn't, then calling the propo= sal a practice might be premature. > inline: > =20 >=20 > > Regarding protection at rest: what=E2=80=99s the attacker model in those= discussions? XSS? Local attacks on the device? > The main concern is XSS. You can just google token session storage to find= an onslaught of articles and forum threads on the topic. To pick one at ran= dom, here's the one from Mozilla. > We can argue on what's worse between XSS and URL leaks, but I don't think w= e can ignore the pervasive ongoing debate and perception that use of local s= torage for sensitive data is bad. >=20 >=20 > > Much of the mechanisms are platform specific and need platform expertis= e.=20 > I don't follow this one. We are targeting the browser, right? What are the= platform specific features you are thinking about? >=20 >=20 > > =46rom the OAuth protocol perspective, impact of RT leakage can be limit= ed through rotation. So I would argue RTs are better protected than ATs. > AFAIK relatively few providers today offer RT rotation (Microsoft is an ex= ample of widely adopted provider who doesn't), and even if they do: if you s= teal an RT and use it to get an AT you will enjoy full AT use until the legi= timate client attempts a refresh, which will be typically at near expiry tim= e, hence gaining very little. And given that even fewer providers offer acce= ss token revocation as a consequence of attempted RT reuse, even more freque= nt refresh attempts won't reduce the time the attacker has to use the access= token they obtained. Hence I am not sure I buy the argument that RTs are be= tter protected than ATs, both from the theoretical perspective and the pract= ical one. And in practical terms, if a developer is tied to a provider that d= oesn't offer full RT rotation asking them to store RTs will make them worse o= ff than they are today. I am of course all for encouraging providers to intr= oduce proper RT rotation support, but until they do developers receiving thi= s guidance TODAY will be stuck between a rock and a hard place. >=20 > > Interesting question :-) I think login and API access are quite differen= t.=20 > Once again, this is very theoretical :) you, myself and the cohort on this= lost can appreciate the difference between the two scenarios- but from most= practitioners without identity background, sign out is "the user can't use t= he app anymore until they enter their credentials again". Whether they imple= ment a proper sign in or go straight to API calling, the visible effect they= want to achieve is that one. With implicit today, the access is all predica= ted on a single artifact- the provider session cookie. If I have two apps in= two tabs, signing out from one automatically robs the other from the abilit= y to retain continued access. By introducing another artifact that can provi= de continued access and whose existence is independent from the session cook= ie, either I explicitly manage the lifecycle of that artifact (by deleting i= t at the right time) or my app will simply be able to continue accessing API= regardless of the fact that my session with the OP ended. >=20 > > In the API case, the AS can just revoke the RT when the logout happens. > That's just not how that works for many of the big providers, and without i= ntroducing new switches I don't think it should. RTs are issued for offline a= ccess purposes, hence their lifetime can (and often will) exceed the lifetim= e of sessions. Borrowing from classic web scenarios, I can sign in and out o= f twitter as much as I want- that should not affect twitter's ability to cal= l APIs even when I don't have a current session. That's the canonical use ca= se I think of when thinking of RTs. > The challenge with SPAs is that successfully calling APIs is often used in= lieu of proper sign in; we can repeat until we're blue in the face that thi= s leaves apps prone to confused deputy and the like, but in practice people w= ill keep doing it because to the non-initiated that makes intuitive sense. H= ence either we introduce a switch that tells the AS that the RT we are askin= g for needs to be tied to the session, and manage revocation accordingly, or= we manage the persistence of the RT at the application side. The latter see= ms much easier to achieve to me, and above all more immediately actionable g= iven that I doubt providers will be very prompt in introducing new features l= ike the one hypothesized here.=20 >=20 >=20 >> On Thu, Dec 6, 2018 at 4:49 AM Torsten Lodderstedt wrote: >> Hi Vittorio, >>=20 >> > Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci : >> >=20 >> > Thank you! >> > On the RT, more questions: >> >=20 >> > - where would you save the RT? Iam thinking of the no-backend case in p= articular. There=E2=80=99s a lot of heartburn in the community on where to s= ave access tokens already, given the larger scope of refresh tokens I would e= xpect objections there would be exacerbated. >>=20 >> Interesting, I=E2=80=99m much more concerned about tokens transmitted in U= RLs since those tokens are vulnerable to remote attacks.=20 >>=20 >> Regarding protection at rest: what=E2=80=99s the attacker model in those d= iscussions? XSS? Local attacks on the device? >>=20 >> Much of the mechanisms are platform specific and need platform expertise.= =20 >>=20 >> >=46rom the OAuth protocol perspective, impact of RT leakage can be limit= ed through rotation. So I would argue RTs are better protected than ATs. >>=20 >> > The user experience bar (number of prompts, full page redirects) should= be the one afforded by implicit leveraging AS sessions via persistent cooki= es. >>=20 >> sure. I don=E2=80=99t see any technical difference in the way the browser= is utilized for both flows and therefore would be surprised to see differen= ces in UX.=20 >>=20 >> > =20 >> > - how would we advise developers about handling distributed sign out? I= f the session cookie with the AS is no longer the only artifact representin= g the effective session, it looks like we should be prescriptive on what sig= nals an app should listen for (OIDC checkSession?) and what the expected act= ions are (e.g. remove the cached RTs). I realize this isn=E2=80=99t strictly= OAuth2, but it remains an important difference in end to end scenarios peop= le use implicit for today >>=20 >> Interesting question :-) I think login and API access are quite different= .=20 >>=20 >> In login the client potentially wants to tightly couple its session lifec= ycle to the AS/OP session, simply because it relies on the user id attested b= y the OP=E2=80=99s for its local user/session management.=20 >>=20 >> For API access, this is not needed. The client =E2=80=9Ejust=E2=80=9C obt= ains a credential to access certain APIs on behalf of the resource owner. Th= e identity of the resource owner on the AS side and the identity of the clie= nt user don=E2=80=99t necessary have a relationship. As you know, OAuth was i= ntentionally built to hide the resource owner identity from the client. I th= ink in this case the resource owner or the AS might have an interest to term= inate API access in case of logout at the AS.=20 >>=20 >> Protocol-wize this result in huge differences: In the login case, the cli= ent can check the session with the OP periodically and terminate its own ses= sion in case the identity changed or there is no longer a session. This typi= cally requires frontend interactions and OpenID Connect (session mgmt or log= out). >>=20 >> In the API case, the AS can just revoke the RT when the logout happens.=20= >>=20 >> kind regards, >> Torsten.=20 >>=20 >> >=20 >> > Thx >> > V. >> >=20 >> > On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt wrote: >> >=20 >> >=20 >> > Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci : >> >=20 >> >> Hey Torsten/Tomek, >> >> Can I ask a clarification on the below? >> >> Torsten, you mentioned that an AS doesn't need to issue a RT- the brow= ser code can just repeat an authorization request. Did I get it right? >> >> But in order to preserve the user experience, that cannot really happe= n as a full page redirect; right? That wouldn't fly for any kind of backgrou= nd update, or for retrieving new ATs for different resources based on the sa= me session. So would we now use a hidden frame to retrieve a code in the sam= e way in which we used fragments to get new ATs? >> >=20 >> > That=E2=80=99s what I meant. I also think the RT-based approach is bett= er suited in terms of UX and security. >> >=20 >> >> Thx >> >> V. >> >>=20 >> >> On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt wrote: >> >> Hi Tomek,=20 >> >>=20 >> >> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki := >> >> >=20 >> >> > Hi Torsten, >> >> >=20 >> >> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Loddersted= t wrote: >> >> >=20 >> >> >=20 >> >> > >> So if I am putting myself in the shoes of somebody who sets out t= o do that - switch an existing SPA client (no backend) >> >> >=20 >> >> > > I would like to ask you a question: how many SPAs w/o a backend ha= ve you seen in your projects? >> >> >=20 >> >> > SPA (html+js) utilizing a 3rd party api that requires authorization?= >> >> > If you do have a backend, aren't you better of handling the token re= quest on the backend as pointed out here >> >> > https://github.com/aaronpk/oauth-browser-based-apps/blob/master/oaut= h-browser-based-apps.md#javascript-app-with-a-backend-component >> >>=20 >> >> I agree.=20 >> >>=20 >> >> > My point of putting (no backend) in parenthesis was to not derail th= is discussion and of course it had the opposite effect. >> >> >=20 >> >>=20 >> >> You know, I you says =E2=80=9Edon=E2=80=99t look at the green car=E2=80= =9C will cause everyone looking for it :-) It asked just out of curiosity.=20= >> >>=20 >> >> > >> Is that fair or is that too much of a shortcut? I am familiar wit= h the specs you've referenced and have looked at them again, but dealing wit= h a SPA, some of the recommendations are not feasible (can't authenticate th= e client,=20 >> >> >=20 >> >> > > You could using dynamic registration (see other thread). The prote= ction would only differ from refresh token rotation if you would use public k= ey crypto for client authentication. >> >> >=20 >> >> > Good point. How well is dynamic registration supported across AS?=20= >> >>=20 >> >> I leave that to the vendors :-) >> >>=20 >> >> >=20 >> >> > >> confidentiality in storage? - not sure how to read that in the co= ntext of a browser) >> >> >=20 >> >> > > How do you ensure confidentiality of session cookies? >> >> >=20 >> >> > All I am trying to say is that I think context is important here. So= when you point out these best practices, some of them will get people confu= sed as far as what it means in the browser based app scenario. >> >>=20 >> >> That=E2=80=99s why we have the more general Security BCP and client-sp= ecific BCPs, like for native apps (https://tools.ietf.org/html/rfc8252) and t= he new BCP for SPAs Aaron started to work on. >> >>=20 >> >> > Maybe it is just me :) >> >>=20 >> >> thanks for raising the question! We need this kind of input to govern t= he development of our specs. >> >>=20 >> >> kind regards, >> >> Torsten.=20 >> >>=20 >> >> >=20 >> >> > >=20 >> >> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Loddersted= t wrote: >> >> > >=20 >> >> > >=20 >> >> > > Hi Tomek, >> >> > >=20 >> >> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki : >> >> > > >=20 >> >> > > > I agree with Vittorio, Dominick et al.=20 >> >> > > >=20 >> >> > > >> I disagree.=20 >> >> > > >=20 >> >> > > >> Existing deployments that have not mitigated against the concer= ns with implicit should be ripped up and updated. >> >> > > >=20 >> >> > > > Yes, just like future deployments that will not mitigate against= the concerns of code in the browser should be a concern. >> >> > >=20 >> >> > > I agree. That=E2=80=99s why I pointed point yesterday that the Sec= urity BCP also defines obligations for clients using code.=20 >> >> > >=20 >> >> > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#se= ction-2.1 >> >> > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#se= ction-2.1.1 >> >> > >=20 >> >> > > >=20 >> >> > > > Can somebody on the other side of the argument (and I hate to ma= ke it sound like there are two sides, because we're on the same side as far a= s Implicit's AT in front-channel is a real issue) address Dominic's comment:= =20 >> >> > > >=20 >> >> > > >> Also - simply saying =E2=80=9Cimplicit is evil - switch to code= =E2=80=9D means for most people also using refresh token - so we are treatin= g access tokens in the URL with refresh tokens in session storage (over simp= lified - but you get the idea). >> >> > > >=20 >> >> > > > Does the group agree|disagree that a recommendation to switch to= code should be made as long as it is followed by an explanation and guidanc= e on what to do with RTs? The ideas that were floated around=20 >> >> > > > - Token bound RTs (even though it was pointed out that token bin= ding is still considered an emerging standard). So should the recommendation= than say "switch to code and MUST use token bound RTs"? >> >> > > > - Have AS not release RTs. "Switch to code and DO NOT request RT= s"? Or switch to code and configure AT to not release RTs for this type of c= lient (not sure what that even looks like in a form of a 3rd party clients)?= >> >> > > > - RTs short lived and bound to a session - "Switch to code as lo= ng as AT can bind and revoke RTs when you log out=E2=80=9C >> >> > >=20 >> >> > > Basically, the AS does not need to issue refresh tokens. If the AS= does not issue refresh tokens, the integration pattern for SPAs does not ch= ange (beside the code exchange). If the client needs a new access token, it w= ill perform another authorization request. =20 >> >> > >=20 >> >> > > If it does, this adds another layer of security because it allows t= he client to frequently obtain new access tokens, which can be short-lived a= nd scope restricted.=20 >> >> > >=20 >> >> > > The refresh tokens should be replay protected by issuing new refre= sh tokens with every refresh and detect replay for refresh tokens belonging t= o the same grant.=20 >> >> > >=20 >> >> > > The AS may additionally bind refresh tokens to AS sessions, but as= it was pointed out by Annabelle and others, there are some implications to b= e understood and managed in that context. >> >> > >=20 >> >> > > You may find more text about refresh tokens in the Security BCP ht= tps://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.12 >> >> > >=20 >> >> > > kind regards, >> >> > > Torsten. >> >> > >=20 >> >> > >=20 >> >> > > >=20 >> >> > > > Sorry if I have missed an important detail from the list above, p= eople who have proposed these ideas, feel free to clarify.=20 >> >> > >=20 >> >> > > >=20 >> >> > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt wrote:=20 >> >> > > >=20 >> >> > > > I disagree.=20 >> >> > > >=20 >> >> > > > Existing deployments that have not mitigated against the concern= s with implicit should be ripped up and updated. >> >> > > >=20 >> >> > > > For example, at one time, I think it was Instagram that had depl= oyed implicit because it was easier to do. Once the understood the security i= mplications, they changed the implementation.=20 >> >> > > >=20 >> >> > > > BCPs are rarely a response to a new threat, their are capturing B= est Current Practices so that they become widely deployed. >> >> > > >=20 >> >> > > >=20 >> >> > > >=20 >> >> > > >=20 >> >> > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell wrote: >> >> > > >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. a= re saying here. And that was kind of behind the comment I made, or tired to m= ake, about this in Bangkok, which was (more or less) that I don't think the W= G should be killing implicit outright but rather that it should begin to rec= ommend against it.=20 >> >> > > >>=20 >> >> > > >> I'm not exactly sure what that looks like in this document but m= aybe toning down some of the scarier language a bit, favoring SHOULDs vs. MU= STs, and including language that helps a reader understand the recommendatio= ns as being more considerations for new applications/deployments than as a m= andate to rip up existing ones.=20 >> >> > > >>=20 >> >> > > >>=20 >> >> > > >>=20 >> >> > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley = wrote: >> >> > > >>>=20 >> >> > > >>> We just need to be sensitive to the spin on this. =20 >> >> > > >>>=20 >> >> > > >>=20 >> >> > > >> CONFIDENTIALITY NOTICE: This email may contain confidential and= privileged material for the sole use of the intended recipient(s). Any revi= ew, use, distribution or disclosure by others is strictly prohibited... If y= ou 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 c= omputer. Thank you._______________________________________________ >> >> > > >> 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 >> >> > > _______________________________________________ >> >> > > OAuth mailing list >> >> > > OAuth@ietf.org >> >> > > https://www.ietf.org/mailman/listinfo/oauth >> >>=20 >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-43286FD2-6D5F-4688-A310-B40511E65D54 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I wanted to address Vittorio=E2=80=99s comm= ent on XSS and LocalStorage.

One XSS attack can extract a= ll of LocalStorage in one line of code. It=E2=80=99s trivial. And after stud= ying XSS for years, I believe that most developers are not capable of buildi= ng good XSS defense into complex UI=E2=80=99s and the trends to use Angular a= nd React are not helping the situation; they just move the problem around.

Sure, few dev teams who have VERY specialized and ra= re developer resources can build XSS resistant apps, if they know how to pro= perly escape, sanitize, validate, use safe JS, embed JSON properly, use sand= boxing properly, and build unique CSP policies per page. And for most, good l= uck with that.

This is why I still hold onto the be= lief that OAuth solutions that store tokens in the browser for high risk app= s is a bad idea. 

I still encourage developers= who are not XSS guru=E2=80=99s to stick to cookie based sessions or statele= ss artifacts to talk to the back end and keep OAuth tokens only flying intra= -server. It=E2=80=99s an unpopular opinion, but even moderately good XSS def= ense is equally unpopular.

At OWASP there are =E2=80= =A2several=E2=80=A2 guides you need to master to understand XSS defense. And= this does not even scratch the surface of what is needed to master XSS defe= nse in React/Angular, not to mention the complexity of CSP which requires pe= r-page policies.



Unpopularity yours,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-38= 05

On Dec 6, 2018, at 1:09 PM, Vittorio Bert= occi <Vittorio=3D= 40auth0.com@dmarc.ietf.org> wrote:

Thank you Torsten.
I think that a= lot of the considerations below need to be tempered with concrete considera= tions about the features developers can actually rely on today.
I a= gree with identifying the theoretical framework and north star we want to as= pire to, but if we are framing the recommendation here in form of practice, w= e have to ensure it is actionable for developers. I am not pushing back on i= deas, but I just want to make sure that when customers hear this advice, the= y are actually in the position to apply it. And if there are missing pieces,= perhaps we should consider this more as guidance to the vendors that need t= o provide key enablers for this to become viable, and recommend it as practi= ce to customers only when that happened.
I add more details inline= below, however I have a meta point to make: did all the vendors on the l= ist work on proof of concepts to ensure that the practices recommended here c= an work with your product, end to end? 
I don't mean just= doing a code+PKCE demo in JS, I mean complying with things like RT rotation= and revocation end to end, using released features that your customers can u= se today. If you did, it might really help to use them to make those discuss= ions more concrete. If you didn't, then calling the proposal a practice migh= t be premature.
inline:
 

> R= egarding protection at rest: what=E2=80=99s the attacker model in those disc= ussions? XSS? Local attacks on the device?
The main concern is XSS= . You can just google token session storage to find an onslaught of a= rticles and forum threads on the topic. To pick one at random, here's the one from Mozilla.
We can argue on what= 's worse between XSS and URL leaks, but I don't think we can ignore the perv= asive ongoing debate and perception that use of local storage for sensitive d= ata is bad.


>  Much of the m= echanisms are platform specific and need platform expertise. 
I don't follow this one. We are targeting the browser, right? What are the p= latform specific features you are thinking about?

<= br>
> =46rom the OAuth protocol perspective, impact of RT leaka= ge can be limited through rotation. So I would argue RTs are better protecte= d than ATs.
AFAIK relatively few providers today offer RT rotation= (Microsoft is an example of widely adopted provider who doesn't), and even i= f they do: if you steal an RT and use it to get an AT you will enjoy full AT= use until the legitimate client attempts a refresh, which will be typically= at near expiry time, hence gaining very little. And given that even fewer p= roviders offer access token revocation as a consequence of attempted RT reus= e, even more frequent refresh attempts won't reduce the time the attacker ha= s to use the access token they obtained. Hence I am not sure I buy the argum= ent that RTs are better protected than ATs, both from the theoretical perspe= ctive and the practical one. And in practical terms, if a developer is tied t= o a provider that doesn't offer full RT rotation asking them to store RTs wi= ll make them worse off than they are today. I am of course all for encouragi= ng providers to introduce proper RT rotation support, but until they do deve= lopers receiving this guidance TODAY will be stuck between a rock and a hard= place.

> Interesting question :-) I think login= and API access are quite different. 
Once again, this is ver= y theoretical :) you, myself and the cohort on this lost can appreciate the d= ifference between the two scenarios- but from most practitioners without ide= ntity background, sign out is "the user can't use the app anymore until they= enter their credentials again". Whether they implement a proper sign in or g= o straight to API calling, the visible effect they want to achieve is that o= ne. With implicit today, the access is all predicated on a single artifact- t= he provider session cookie. If I have two apps in two tabs, signing out from= one automatically robs the other from the ability to retain continued acces= s. By introducing another artifact that can provide continued access and who= se existence is independent from the session cookie, either I explicitly man= age the lifecycle of that artifact (by deleting it at the right time) or my a= pp will simply be able to continue accessing API regardless of the fact that= my session with the OP ended.

> In the API case= , the AS can just revoke the RT when the logout happens.
That'= s just not how that works for many of the big providers, and without introdu= cing new switches I don't think it should. RTs are issued for offline access= purposes, hence their lifetime can (and often will) exceed the lifetime of s= essions. Borrowing from classic web scenarios, I can sign in and out of twit= ter as much as I want- that should not affect twitter's ability to call APIs= even when I don't have a current session. That's the canonical use case I t= hink of when thinking of RTs.
The challenge with SPAs is that succ= essfully calling APIs is often used in lieu of proper sign in; we can repeat= until we're blue in the face that this leaves apps prone to confused deputy= and the like, but in practice people will keep doing it because to the non-= initiated that makes intuitive sense. Hence either we introduce a switch tha= t tells the AS that the RT we are asking for needs to be tied to the session= , and manage revocation accordingly, or we manage the persistence of the RT a= t the application side. The latter seems much easier to achieve to me, and a= bove all more immediately actionable given that I doubt providers will be ve= ry prompt in introducing new features like the one hypothesized here. <= /div>


On T= hu, Dec 6, 2018 at 4:49 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Vittorio,

> Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci <Vittorio@auth0.com>:
>
> Thank you!
> On the RT, more questions:
>
> - where would you save the RT? Iam thinking of the no-backend case in p= articular. There=E2=80=99s a lot of heartburn in the community on where to s= ave access tokens already, given the larger scope of refresh tokens I would e= xpect objections there would be exacerbated.

Interesting, I=E2=80=99m much more concerned about tokens transmitted in URL= s since those tokens are vulnerable to remote attacks.

Regarding protection at rest: what=E2=80=99s the attacker model in those dis= cussions? XSS? Local attacks on the device?

Much of the mechanisms are platform specific and need platform expertise.
>=46rom the OAuth protocol perspective, impact of RT leakage can be limit= ed through rotation. So I would argue RTs are better protected than ATs.
=
> The user experience bar (number of prompts, full page redirects) should= be the one afforded by implicit leveraging AS sessions via persistent cooki= es.

sure. I don=E2=80=99t see any technical difference in the way the browser is= utilized for both flows and therefore would be surprised to see differences= in UX.

> 
> - how would we advise developers about handling distributed sign out? I= f the session cookie with the AS is no longer  the only artifact repres= enting the effective session, it looks like we should be prescriptive on wha= t signals an app should listen for (OIDC checkSession?) and what the expecte= d actions are (e.g. remove the cached RTs). I realize this isn=E2=80=99t str= ictly OAuth2, but it remains an important difference in end to end scenarios= people use implicit for today

Interesting question :-) I think login and API access are quite different. <= br>
In login the client potentially wants to tightly couple its session lifecycl= e to the AS/OP session, simply because it relies on the user id attested by t= he OP=E2=80=99s for its local user/session management.

For API access, this is not needed. The client =E2=80=9Ejust=E2=80=9C obtain= s a credential to access certain APIs on behalf of the resource owner. The i= dentity of the resource owner on the AS side and the identity of the client u= ser don=E2=80=99t necessary have a relationship. As you know, OAuth was inte= ntionally built to hide the resource owner identity from the client. I think= in this case the resource owner or the AS might have an interest to termina= te API access in case of logout at the AS.

Protocol-wize this result in huge differences: In the login case, the client= can check the session with the OP periodically and terminate its own sessio= n in case the identity changed or there is no longer a session. This typical= ly requires frontend interactions and OpenID Connect (session mgmt or logout= ).

In the API case, the AS can just revoke the RT when the logout happens.
=
kind regards,
Torsten.

>
> Thx
> V.
>
> On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt <torsten@lodderstedt.net> w= rote:
>
>
> Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci <vittorio.bertocci@auth0.com>:
>
>> Hey Torsten/Tomek,
>> Can I ask a clarification on the below?
>> Torsten, you mentioned that an AS doesn't need to issue a RT- the b= rowser code can just repeat an authorization request. Did I get it right? >> But in order to preserve the user experience, that cannot really ha= ppen as a full page redirect; right? That wouldn't fly for any kind of backg= round update, or for retrieving new ATs for different resources based on the= same session. So would we now use a hidden frame to retrieve a code in the s= ame way in which we used fragments to get new ATs?
>
> That=E2=80=99s what I meant. I also think the RT-based approach is bett= er suited in terms of UX and security.
>
>> Thx
>> V.
>>
>> On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt <torsten@lodderstedt.net= > wrote:
>> Hi Tomek,
>>
>> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki <tstojecki@yahoo.com>: >> >
>> > Hi Torsten,
>> >
>> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodd= erstedt <tor= sten@lodderstedt.net> wrote:
>> >
>> >
>> > >> So if I am putting myself in the shoes of somebody wh= o sets out to do that - switch an existing SPA client (no backend)
>> >
>> > > I would like to ask you a question: how many SPAs w/o a b= ackend have you seen in your projects?
>> >
>> > SPA (html+js) utilizing a 3rd party api that requires authoriz= ation?
>> > If you do have a backend, aren't you better of handling the to= ken request on the backend as pointed out here
>> > https://github.com/aaronpk/oauth-= browser-based-apps/blob/master/oauth-browser-based-apps.md#javascript-app-wi= th-a-backend-component
>>
>> I agree.
>>
>> > My point of putting (no backend) in parenthesis was to not der= ail this discussion and of course it had the opposite effect.
>> >
>>
>> You know, I you says =E2=80=9Edon=E2=80=99t look at the green car=E2= =80=9C will cause everyone looking for it :-) It asked just out of curiosity= .
>>
>> > >> Is that fair or is that too much of a shortcut? I am f= amiliar with the specs you've referenced and have looked at them again, but d= ealing with a SPA, some of the recommendations are not feasible (can't authe= nticate the client,
>> >
>> > > You could using dynamic registration (see other thread). T= he protection would only differ from refresh token rotation if you would use= public key crypto for client authentication.
>> >
>> > Good point. How well is dynamic registration supported across A= S?
>>
>> I leave that to the vendors :-)
>>
>> >
>> > >> confidentiality in storage? - not sure how to read th= at in the context of a browser)
>> >
>> > > How do you ensure confidentiality of session cookies?
= >> >
>> > All I am trying to say is that I think context is important he= re. So when you point out these best practices, some of them will get people= confused as far as what it means in the browser based app scenario.
>>
>> That=E2=80=99s why we have the more general Security BCP and client= -specific BCPs, like for native apps (https://tools.ietf.org/html/r= fc8252) and the new BCP for SPAs Aaron started to work on.
>>
>> > Maybe it is just me :)
>>
>> thanks for raising the question! We need this kind of input to gove= rn the development of our specs.
>>
>> kind regards,
>> Torsten.
>>
>> >
>> > >
>> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten L= odderstedt <= torsten@lodderstedt.net> wrote:
>> > >
>> > >
>> > > Hi Tomek,
>> > >
>> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki <ts= tojecki=3D40= yahoo.com@dmarc.ietf.org>:
>> > > >
>> > > > I agree with Vittorio, Dominick et al.
>> > > >
>> > > >> I disagree.
>> > > >
>> > > >> Existing deployments that have not mitigated aga= inst the concerns with implicit should be ripped up and updated.
>> > > >
>> > > > Yes, just like future deployments that will not miti= gate against the concerns of code in the browser should be a concern.
>> > >
>> > > I agree. That=E2=80=99s why I pointed point yesterday tha= t the Security BCP also defines obligations for clients using code.
>> > >
>> > > https://= tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1
>> > > https:= //tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1.1<= br> >> > >
>> > > >
>> > > > Can somebody on the other side of the argument (and I= hate to make it sound like there are two sides, because we're on the same s= ide as far as Implicit's AT in front-channel is a real issue) address Domini= c's comment:
>> > > >
>> > > >> Also - simply saying =E2=80=9Cimplicit is evil -= switch to code=E2=80=9D means for most people also using refresh token - so= we are treating access tokens in the URL with refresh tokens in session sto= rage (over simplified - but you get the idea).
>> > > >
>> > > > Does the group agree|disagree that a recommendation t= o switch to code should be made as long as it is followed by an explanation a= nd guidance on what to do with RTs? The ideas that were floated around
>> > > > - Token bound RTs (even though it was pointed out th= at token binding is still considered an emerging standard). So should the re= commendation than say "switch to code and MUST use token bound RTs"?
>> > > > - Have AS not release RTs. "Switch to code and DO NO= T request RTs"? Or switch to code and configure AT to not release RTs for th= is type of client (not sure what that even looks like in a form of a 3rd par= ty clients)?
>> > > > - RTs short lived and bound to a session - "Switch t= o code as long as AT can bind and revoke RTs when you log out=E2=80=9C
>> > >
>> > > Basically, the AS does not need to issue refresh tokens. I= f the AS does not issue refresh tokens, the integration pattern for SPAs doe= s not change (beside the code exchange). If the client needs a new access to= ken, it will perform another authorization request. 
>> > >
>> > > If it does, this adds another layer of security because i= t allows the client to frequently obtain new access tokens, which can be sho= rt-lived and scope restricted.
>> > >
>> > > The refresh tokens should be replay protected by issuing n= ew refresh tokens with every refresh and detect replay for refresh tokens be= longing to the same grant.
>> > >
>> > > The AS may additionally bind refresh tokens to AS session= s, but as it was pointed out by Annabelle and others, there are some implica= tions to be understood and managed in that context.
>> > >
>> > > You may find more text about refresh tokens in the Securi= ty BCP https://tools.ietf.= org/html/draft-ietf-oauth-security-topics-10#section-3.12
>> > >
>> > > kind regards,
>> > > Torsten.
>> > >
>> > >
>> > > >
>> > > > Sorry if I have missed an important detail from the l= ist above, people who have proposed these ideas, feel free to clarify.
>> > >
>> > > >
>> > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick= Hardt <dick.ha= rdt@gmail.com> wrote:
>> > > >
>> > > > I disagree.
>> > > >
>> > > > Existing deployments that have not mitigated against= the concerns with implicit should be ripped up and updated.
>> > > >
>> > > > For example, at one time, I think it was Instagram t= hat had deployed implicit because it was easier to do. Once the understood t= he security implications, they changed the implementation.
>> > > >
>> > > > BCPs are rarely a response to a new threat, their ar= e capturing Best Current Practices so that they become widely deployed.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell <b= campbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
>> > > >> FWIW I'm somewhat sympathetic to what Vittorio, D= ominick, etc. are saying here. And that was kind of behind the comment I mad= e, or tired to make, about this in Bangkok, which was (more or less) that I d= on't think the WG should be killing implicit outright but rather that it sho= uld begin to recommend against it.
>> > > >>
>> > > >> I'm not exactly sure what that looks like in thi= s document but maybe toning down some of the scarier language a bit, favorin= g SHOULDs vs. MUSTs, and including language that helps a reader understand t= he recommendations as being more considerations for new applications/deploym= ents than as a mandate to rip up existing ones.
>> > > >>
>> > > >>
>> > > >>
>> > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley <= ve7jtb@ve7jtb.com= > wrote:
>> > > >>>
>> > > >>> We just need to be sensitive to the spin on t= his. 
>> > > >>>
>> > > >>
>> > > >> CONFIDENTIALITY NOTICE: This email may contain c= onfidential and privileged material for the sole use of the intended recipie= nt(s). Any review, use, distribution or disclosure by others is strictly pro= hibited...  If you have received this communication in error, please no= tify the sender immediately by e-mail and delete the message and any file at= tachments from your computer. Thank you.____________________________________= ___________
>> > > >> OAuth mailing list
>> > > >> OAuth@ietf.org
>> > > >> https://www.ietf.org/mailman/li= stinfo/oauth
>> > > >>
>> > > > _______________________________________________
>> > > > OAuth mailing list
>> > > > = OAuth@ietf.org
>> > > > https://www.ietf.org/mailman/listin= fo/oauth
>> > > >
>> > > > _______________________________________________
>> > > > OAuth mailing list
>> > > > = OAuth@ietf.org
>> > > > https://www.ietf.org/mailman/listin= fo/oauth
>> > > _______________________________________________
>> > > OAuth mailing list
>> > > OAuth= @ietf.org
>> > > https://www.ietf.org/mailman/listinfo/oa= uth
>>

________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-43286FD2-6D5F-4688-A310-B40511E65D54-- From nobody Fri Dec 7 14:27:06 2018 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 898CA130ED7 for ; Fri, 7 Dec 2018 14:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wZbcCi0TBcAF for ; Fri, 7 Dec 2018 14:27:03 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 49835126C01 for ; Fri, 7 Dec 2018 14:27:03 -0800 (PST) Received: from [IPv6:2601:282:202:b210:8191:e41d:9df:181f] (unknown [IPv6:2601:282:202:b210:8191:e41d:9df:181f]) by alkaline-solutions.com (Postfix) with ESMTPSA id BD21C3166E; Fri, 7 Dec 2018 22:27:02 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: David Waite X-Mailer: iPhone Mail (16C50) In-Reply-To: Date: Fri, 7 Dec 2018 15:27:01 -0700 Cc: Vittorio Bertocci , Daniel Fett , IETF oauth WG Content-Transfer-Encoding: quoted-printable Message-Id: <787EE945-1B6B-4A63-A248-CB60458EDC01@alkaline-solutions.com> References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> To: Jim Manico Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 07 Dec 2018 22:27:05 -0000 > On Dec 7, 2018, at 5:50 AM, Jim Manico wrote: > I still encourage developers who are not XSS guru=E2=80=99s to stick to co= okie based sessions or stateless artifacts to talk to the back end and keep O= Auth tokens only flying intra-server. It=E2=80=99s an unpopular opinion, but= even moderately good XSS defense is equally unpopular Is this a matter of saying they should have an API for these clients which e= xposes less of the risky activities? That cookies provide a defense against X= SS exfiltration? And/or other? -DW From nobody Fri Dec 7 15:20:58 2018 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 8787E130E1D for ; Fri, 7 Dec 2018 15:20:56 -0800 (PST) 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=unavailable 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 wO_iZLoQVhJV for ; Fri, 7 Dec 2018 15:20:51 -0800 (PST) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 F29FB12D4E7 for ; Fri, 7 Dec 2018 15:20:50 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id y1so2476926plp.9 for ; Fri, 07 Dec 2018 15:20:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Y9A+ELIwVu98rTzaJwRNEFxj+V4HqmaSXkf1HrtGmvk=; b=GqBI32rasb83zQdFbReXJW7aoXsfkk/gHHP6++6aYWw+kpZ7NanczciicaMjmcalzP KGx+yMqDF+KozIwP/Hi+h2gJXYasPvtJ1wM8h4Pj/dXW3c2vRq1Ug6urX6m5VqZl0LCN fNZX4JBYUEP03wJEaD2g0w9uCMMOFAzytBjiFN2IUvvnCTBYdHiFtgEbkp3lfHbjWN5a YdLRVyCNw+j6L0plla/C9U0hMR5hkHyaYAfmklVhHiU1AU8KFZZsnCfiNNbb4gk2VjbF suiucHFGjuHW9DQuOg3fnG6gQgRntLLYcoGVlbUuQkfe8IqRKw0CnYyysvNlGu83pT49 BtBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Y9A+ELIwVu98rTzaJwRNEFxj+V4HqmaSXkf1HrtGmvk=; b=h53r+owSib9zbkuze3k/V+mOsTD0Vewd8F19hsVqY5ZzNKzSepJi/0lFKRSopDNEvY lPQVdzU8fZJRWI1MS1tVcdiPXAgkbIRIZDU08AZ/dCHyh5WPRCCzNXUyiKIc7Gle3wR/ 22JY8a6Ba9Oik2LrcXKYTtWNRI50TL5/ZIuhoo0h+j7nugtEZVvkoW5RmihG0lVL7G0r 3PHgadeUjz68lxH8q7KakP54Evv6BXVTS6HzeinPbbKDXsy9t7TNhRadrHvPA5dCDQ1+ GW/PG7kr1LzyDLrLhx4RClIM24kUb3p+MjPhwyKj+AsmdNgSupasa/7XdjiIv80qU6BP Ypzg== X-Gm-Message-State: AA+aEWaXy+nTFBccAqN6psmO4Yk+dit7o3kfqa0+rXSbAHrH7jAttHMG nwNu0NY5Xg+mSiUe9nS2kIK+CxBW X-Google-Smtp-Source: AFSGD/V/zvRlyaIcA32BdpZOur72n20S7zOfriNOCqmWJTEBzER3kul9Bq5H6IETkaQ5zyLXfuoFJQ== X-Received: by 2002:a17:902:7044:: with SMTP id h4mr3893177plt.35.1544224849458; Fri, 07 Dec 2018 15:20:49 -0800 (PST) Received: from [172.16.80.121] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id v15sm6626948pfn.94.2018.12.07.15.20.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Dec 2018 15:20:48 -0800 (PST) From: Nov Matake Message-Id: <115824C4-61C1-4986-A30F-382A1AA563BB@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3C0681C6-7C6E-48FE-B9F0-CF12256722B6" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Sat, 8 Dec 2018 08:20:45 +0900 In-Reply-To: Cc: Torsten Lodderstedt , Daniel Fett , IETF oauth WG To: Vittorio Bertocci References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 07 Dec 2018 23:20:56 -0000 --Apple-Mail=_3C0681C6-7C6E-48FE-B9F0-CF12256722B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Vittorio, =10=10> did all the vendors on the list work on proof of concepts to = ensure that the practices recommended here can work with your product, = end to end?=20 I=E2=80=99m not currently working on SPA apps nor apps using implicit = flow. However, my previous client is using hybrid flow to fetch access tokens = both for JS App and its backend server in single OAuth dance = transaction. So I imagined how to use code flow for such case. It would probably be using code in backend server and get narrower = scoped token using RT, then pass it to JS app. Then I added MTLS/TB bound feature in that flow as below. = https://www.websequencediagrams.com/?lz=3Dbm90ZSBvdmVyIFNQQSwgUG9wdXAgV2lu= ZG93LCBCYWNrZW5kLCBBdXRoWiBFUCwgVG9rZW4ABQVSZXNvdXJjZSBFUAplbmQgbm90ZQpTUE= EtPgAwBzogSW5pdAoAPgctPlNQQToAQwdSZXEKYWx0IHcvIFRCCiAgADIFAHAMOiBPcGVuAFcN= IACBEA0tPgB1CwBLDCAAgQ0MAEUQAHUJIHcvIFJlZmZlcmVkIFRCSUQAThEAgWsIABgdZWxzZS= B3L28AgS0ZAIEMDAA_IQplbmQKAIJjCDwAgSgUTiAmIENvbnNlbnQAIAkAgikQQ29kZQoAgh0O= AIMICQAXBQCDCAkAg0QIAC4GIChNVExTKQoAg1oIAIM9C0FUIGZvcgCEBwgAIwYtYm91bmQpIC= YgUlQABQ0ATBQAGwgARhgoVEIASgY_ADQLAIQqBgAYBQALDACDag5QSSBSZXF1ZXMAhEgFQQBf= CQCFBAUACyAAVAU&s=3Dearth = For me, it seems very hard to issue TB-bound token for JS app and = MTLS-bound token for its backend server at same time. Do someone has workable recommendation for such case? Thanks nov > On Dec 7, 2018, at 3:09, Vittorio Bertocci = wrote: >=20 > Thank you Torsten. > I think that a lot of the considerations below need to be tempered = with concrete considerations about the features developers can actually = rely on today. > I agree with identifying the theoretical framework and north star we = want to aspire to, but if we are framing the recommendation here in form = of practice, we have to ensure it is actionable for developers. I am not = pushing back on ideas, but I just want to make sure that when customers = hear this advice, they are actually in the position to apply it. And if = there are missing pieces, perhaps we should consider this more as = guidance to the vendors that need to provide key enablers for this to = become viable, and recommend it as practice to customers only when that = happened. > I add more details inline below, however I have a meta point to make: = did all the vendors on the list work on proof of concepts to ensure that = the practices recommended here can work with your product, end to end?=20= > I don't mean just doing a code+PKCE demo in JS, I mean complying with = things like RT rotation and revocation end to end, using released = features that your customers can use today. If you did, it might really = help to use them to make those discussions more concrete. If you didn't, = then calling the proposal a practice might be premature. > inline: > =20 >=20 > > Regarding protection at rest: what=E2=80=99s the attacker model in = those discussions? XSS? Local attacks on the device? > The main concern is XSS. You can just google token session storage to = find an onslaught of articles and forum threads on the topic. To pick = one at random, here's the one from Mozilla = . > We can argue on what's worse between XSS and URL leaks, but I don't = think we can ignore the pervasive ongoing debate and perception that use = of local storage for sensitive data is bad. >=20 >=20 > > Much of the mechanisms are platform specific and need platform = expertise.=20 > I don't follow this one. We are targeting the browser, right? What are = the platform specific features you are thinking about? >=20 >=20 > > =46rom the OAuth protocol perspective, impact of RT leakage can be = limited through rotation. So I would argue RTs are better protected than = ATs. > AFAIK relatively few providers today offer RT rotation (Microsoft is = an example of widely adopted provider who doesn't), and even if they do: = if you steal an RT and use it to get an AT you will enjoy full AT use = until the legitimate client attempts a refresh, which will be typically = at near expiry time, hence gaining very little. And given that even = fewer providers offer access token revocation as a consequence of = attempted RT reuse, even more frequent refresh attempts won't reduce the = time the attacker has to use the access token they obtained. Hence I am = not sure I buy the argument that RTs are better protected than ATs, both = from the theoretical perspective and the practical one. And in practical = terms, if a developer is tied to a provider that doesn't offer full RT = rotation asking them to store RTs will make them worse off than they are = today. I am of course all for encouraging providers to introduce proper = RT rotation support, but until they do developers receiving this = guidance TODAY will be stuck between a rock and a hard place. >=20 > > Interesting question :-) I think login and API access are quite = different.=20 > Once again, this is very theoretical :) you, myself and the cohort on = this lost can appreciate the difference between the two scenarios- but = from most practitioners without identity background, sign out is "the = user can't use the app anymore until they enter their credentials = again". Whether they implement a proper sign in or go straight to API = calling, the visible effect they want to achieve is that one. With = implicit today, the access is all predicated on a single artifact- the = provider session cookie. If I have two apps in two tabs, signing out = from one automatically robs the other from the ability to retain = continued access. By introducing another artifact that can provide = continued access and whose existence is independent from the session = cookie, either I explicitly manage the lifecycle of that artifact (by = deleting it at the right time) or my app will simply be able to continue = accessing API regardless of the fact that my session with the OP ended. >=20 > > In the API case, the AS can just revoke the RT when the logout = happens. > That's just not how that works for many of the big providers, and = without introducing new switches I don't think it should. RTs are issued = for offline access purposes, hence their lifetime can (and often will) = exceed the lifetime of sessions. Borrowing from classic web scenarios, I = can sign in and out of twitter as much as I want- that should not affect = twitter's ability to call APIs even when I don't have a current session. = That's the canonical use case I think of when thinking of RTs. > The challenge with SPAs is that successfully calling APIs is often = used in lieu of proper sign in; we can repeat until we're blue in the = face that this leaves apps prone to confused deputy and the like, but in = practice people will keep doing it because to the non-initiated that = makes intuitive sense. Hence either we introduce a switch that tells the = AS that the RT we are asking for needs to be tied to the session, and = manage revocation accordingly, or we manage the persistence of the RT at = the application side. The latter seems much easier to achieve to me, and = above all more immediately actionable given that I doubt providers will = be very prompt in introducing new features like the one hypothesized = here.=20 >=20 >=20 > On Thu, Dec 6, 2018 at 4:49 AM Torsten Lodderstedt = > wrote: > Hi Vittorio, >=20 > > Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci >: > >=20 > > Thank you! > > On the RT, more questions: > >=20 > > - where would you save the RT? Iam thinking of the no-backend case = in particular. There=E2=80=99s a lot of heartburn in the community on = where to save access tokens already, given the larger scope of refresh = tokens I would expect objections there would be exacerbated. >=20 > Interesting, I=E2=80=99m much more concerned about tokens transmitted = in URLs since those tokens are vulnerable to remote attacks.=20 >=20 > Regarding protection at rest: what=E2=80=99s the attacker model in = those discussions? XSS? Local attacks on the device? >=20 > Much of the mechanisms are platform specific and need platform = expertise.=20 >=20 > >=46rom the OAuth protocol perspective, impact of RT leakage can be = limited through rotation. So I would argue RTs are better protected than = ATs. >=20 > > The user experience bar (number of prompts, full page redirects) = should be the one afforded by implicit leveraging AS sessions via = persistent cookies. >=20 > sure. I don=E2=80=99t see any technical difference in the way the = browser is utilized for both flows and therefore would be surprised to = see differences in UX.=20 >=20 > > =20 > > - how would we advise developers about handling distributed sign = out? If the session cookie with the AS is no longer the only artifact = representing the effective session, it looks like we should be = prescriptive on what signals an app should listen for (OIDC = checkSession?) and what the expected actions are (e.g. remove the cached = RTs). I realize this isn=E2=80=99t strictly OAuth2, but it remains an = important difference in end to end scenarios people use implicit for = today >=20 > Interesting question :-) I think login and API access are quite = different.=20 >=20 > In login the client potentially wants to tightly couple its session = lifecycle to the AS/OP session, simply because it relies on the user id = attested by the OP=E2=80=99s for its local user/session management.=20 >=20 > For API access, this is not needed. The client =E2=80=9Ejust=E2=80=9C = obtains a credential to access certain APIs on behalf of the resource = owner. The identity of the resource owner on the AS side and the = identity of the client user don=E2=80=99t necessary have a relationship. = As you know, OAuth was intentionally built to hide the resource owner = identity from the client. I think in this case the resource owner or the = AS might have an interest to terminate API access in case of logout at = the AS.=20 >=20 > Protocol-wize this result in huge differences: In the login case, the = client can check the session with the OP periodically and terminate its = own session in case the identity changed or there is no longer a = session. This typically requires frontend interactions and OpenID = Connect (session mgmt or logout). >=20 > In the API case, the AS can just revoke the RT when the logout = happens.=20 >=20 > kind regards, > Torsten.=20 >=20 > >=20 > > Thx > > V. > >=20 > > On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt = > wrote: > >=20 > >=20 > > Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci = >: > >=20 > >> Hey Torsten/Tomek, > >> Can I ask a clarification on the below? > >> Torsten, you mentioned that an AS doesn't need to issue a RT- the = browser code can just repeat an authorization request. Did I get it = right? > >> But in order to preserve the user experience, that cannot really = happen as a full page redirect; right? That wouldn't fly for any kind of = background update, or for retrieving new ATs for different resources = based on the same session. So would we now use a hidden frame to = retrieve a code in the same way in which we used fragments to get new = ATs? > >=20 > > That=E2=80=99s what I meant. I also think the RT-based approach is = better suited in terms of UX and security. > >=20 > >> Thx > >> V. > >>=20 > >> On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt = > wrote: > >> Hi Tomek,=20 > >>=20 > >> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki = >: > >> >=20 > >> > Hi Torsten, > >> >=20 > >> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten = Lodderstedt > = wrote: > >> >=20 > >> >=20 > >> > >> So if I am putting myself in the shoes of somebody who sets = out to do that - switch an existing SPA client (no backend) > >> >=20 > >> > > I would like to ask you a question: how many SPAs w/o a backend = have you seen in your projects? > >> >=20 > >> > SPA (html+js) utilizing a 3rd party api that requires = authorization? > >> > If you do have a backend, aren't you better of handling the token = request on the backend as pointed out here > >> > = https://github.com/aaronpk/oauth-browser-based-apps/blob/master/oauth-brow= ser-based-apps.md#javascript-app-with-a-backend-component = > >>=20 > >> I agree.=20 > >>=20 > >> > My point of putting (no backend) in parenthesis was to not derail = this discussion and of course it had the opposite effect. > >> >=20 > >>=20 > >> You know, I you says =E2=80=9Edon=E2=80=99t look at the green = car=E2=80=9C will cause everyone looking for it :-) It asked just out of = curiosity.=20 > >>=20 > >> > >> Is that fair or is that too much of a shortcut? I am familiar = with the specs you've referenced and have looked at them again, but = dealing with a SPA, some of the recommendations are not feasible (can't = authenticate the client,=20 > >> >=20 > >> > > You could using dynamic registration (see other thread). The = protection would only differ from refresh token rotation if you would = use public key crypto for client authentication. > >> >=20 > >> > Good point. How well is dynamic registration supported across AS?=20= > >>=20 > >> I leave that to the vendors :-) > >>=20 > >> >=20 > >> > >> confidentiality in storage? - not sure how to read that in the = context of a browser) > >> >=20 > >> > > How do you ensure confidentiality of session cookies? > >> >=20 > >> > All I am trying to say is that I think context is important here. = So when you point out these best practices, some of them will get people = confused as far as what it means in the browser based app scenario. > >>=20 > >> That=E2=80=99s why we have the more general Security BCP and = client-specific BCPs, like for native apps = (https://tools.ietf.org/html/rfc8252 = ) and the new BCP for SPAs Aaron = started to work on. > >>=20 > >> > Maybe it is just me :) > >>=20 > >> thanks for raising the question! We need this kind of input to = govern the development of our specs. > >>=20 > >> kind regards, > >> Torsten.=20 > >>=20 > >> >=20 > >> > >=20 > >> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten = Lodderstedt > = wrote: > >> > >=20 > >> > >=20 > >> > > Hi Tomek, > >> > >=20 > >> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki = >: > >> > > >=20 > >> > > > I agree with Vittorio, Dominick et al.=20 > >> > > >=20 > >> > > >> I disagree.=20 > >> > > >=20 > >> > > >> Existing deployments that have not mitigated against the = concerns with implicit should be ripped up and updated. > >> > > >=20 > >> > > > Yes, just like future deployments that will not mitigate = against the concerns of code in the browser should be a concern. > >> > >=20 > >> > > I agree. That=E2=80=99s why I pointed point yesterday that the = Security BCP also defines obligations for clients using code.=20 > >> > >=20 > >> > > = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.= 1 = > >> > > = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.= 1.1 = > >> > >=20 > >> > > >=20 > >> > > > Can somebody on the other side of the argument (and I hate to = make it sound like there are two sides, because we're on the same side = as far as Implicit's AT in front-channel is a real issue) address = Dominic's comment:=20 > >> > > >=20 > >> > > >> Also - simply saying =E2=80=9Cimplicit is evil - switch to = code=E2=80=9D means for most people also using refresh token - so we are = treating access tokens in the URL with refresh tokens in session storage = (over simplified - but you get the idea). > >> > > >=20 > >> > > > Does the group agree|disagree that a recommendation to switch = to code should be made as long as it is followed by an explanation and = guidance on what to do with RTs? The ideas that were floated around=20 > >> > > > - Token bound RTs (even though it was pointed out that token = binding is still considered an emerging standard). So should the = recommendation than say "switch to code and MUST use token bound RTs"? > >> > > > - Have AS not release RTs. "Switch to code and DO NOT request = RTs"? Or switch to code and configure AT to not release RTs for this = type of client (not sure what that even looks like in a form of a 3rd = party clients)? > >> > > > - RTs short lived and bound to a session - "Switch to code as = long as AT can bind and revoke RTs when you log out=E2=80=9C > >> > >=20 > >> > > Basically, the AS does not need to issue refresh tokens. If the = AS does not issue refresh tokens, the integration pattern for SPAs does = not change (beside the code exchange). If the client needs a new access = token, it will perform another authorization request. =20 > >> > >=20 > >> > > If it does, this adds another layer of security because it = allows the client to frequently obtain new access tokens, which can be = short-lived and scope restricted.=20 > >> > >=20 > >> > > The refresh tokens should be replay protected by issuing new = refresh tokens with every refresh and detect replay for refresh tokens = belonging to the same grant.=20 > >> > >=20 > >> > > The AS may additionally bind refresh tokens to AS sessions, but = as it was pointed out by Annabelle and others, there are some = implications to be understood and managed in that context. > >> > >=20 > >> > > You may find more text about refresh tokens in the Security BCP = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.= 12 = > >> > >=20 > >> > > kind regards, > >> > > Torsten. > >> > >=20 > >> > >=20 > >> > > >=20 > >> > > > Sorry if I have missed an important detail from the list = above, people who have proposed these ideas, feel free to clarify.=20 > >> > >=20 > >> > > >=20 > >> > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt = > wrote:=20 > >> > > >=20 > >> > > > I disagree.=20 > >> > > >=20 > >> > > > Existing deployments that have not mitigated against the = concerns with implicit should be ripped up and updated. > >> > > >=20 > >> > > > For example, at one time, I think it was Instagram that had = deployed implicit because it was easier to do. Once the understood the = security implications, they changed the implementation.=20 > >> > > >=20 > >> > > > BCPs are rarely a response to a new threat, their are = capturing Best Current Practices so that they become widely deployed. > >> > > >=20 > >> > > >=20 > >> > > >=20 > >> > > >=20 > >> > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell = > wrote: > >> > > >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, = etc. are saying here. And that was kind of behind the comment I made, or = tired to make, about this in Bangkok, which was (more or less) that I = don't think the WG should be killing implicit outright but rather that = it should begin to recommend against it.=20 > >> > > >>=20 > >> > > >> I'm not exactly sure what that looks like in this document = but maybe toning down some of the scarier language a bit, favoring = SHOULDs vs. MUSTs, and including language that helps a reader understand = the recommendations as being more considerations for new = applications/deployments than as a mandate to rip up existing ones.=20 > >> > > >>=20 > >> > > >>=20 > >> > > >>=20 > >> > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley = > wrote: > >> > > >>>=20 > >> > > >>> We just need to be sensitive to the spin on this. =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._______________________________________________ > >> > > >> 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 = > >> > > _______________________________________________ > >> > > OAuth mailing list > >> > > OAuth@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/oauth = > >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_3C0681C6-7C6E-48FE-B9F0-CF12256722B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Vittorio,

=10=10> did all the vendors on the list = work on proof of concepts to ensure that the practices recommended here = can work with your product, end to end? 

I=E2=80=99m not currently working on SPA apps nor = apps using implicit flow.
However, my previous client is using = hybrid flow to fetch access tokens both for JS App and its backend = server in single OAuth dance transaction.

So I imagined how to use code flow for such = case.
It would probably be using code in backend server and = get narrower scoped token using RT, then pass it to JS = app.

Then I added MTLS/TB bound = feature in that flow as below.

For me,  it seems very hard to issue TB-bound = token for JS app and MTLS-bound token for its backend server at same = time.

Do someone has workable = recommendation for such case?

Thanks

nov

On Dec 7, 2018, at 3:09, = Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:

Thank you Torsten.
I think that a lot of the = considerations below need to be tempered with concrete considerations = about the features developers can actually rely on today.
I agree with identifying the theoretical framework and north = star we want to aspire to, but if we are framing the recommendation here = in form of practice, we have to ensure it is actionable for developers. = I am not pushing back on ideas, but I just want to make sure that when = customers hear this advice, they are actually in the position to apply = it. And if there are missing pieces, perhaps we should consider this = more as guidance to the vendors that need to provide key enablers for = this to become viable, and recommend it as practice to customers only = when that happened.
I add more details inline = below, however I have a meta point to make: did all the = vendors on the list work on proof of concepts to ensure that the = practices recommended here can work with your product, end to = end? 
I don't mean just doing a code+PKCE = demo in JS, I mean complying with things like RT rotation and revocation = end to end, using released features that your customers can use today. = If you did, it might really help to use them to make those discussions = more concrete. If you didn't, then calling the proposal a practice might = be premature.
inline:
 

>= Regarding protection at rest: what=E2=80=99s the attacker model in = those discussions? XSS? Local attacks on the device?
The main concern is XSS. You can just google token session storage to find an onslaught of articles = and forum threads on the topic. To pick one at random, here's the one from Mozilla.
We can argue on what's worse between XSS and URL leaks, but I = don't think we can ignore the pervasive ongoing debate and perception = that use of local storage for sensitive data is bad.


>  Much of the mechanisms are platform specific and = need platform expertise. 
I don't follow this = one. We are targeting the browser, right? What are the platform specific = features you are thinking about?


>= =46rom the OAuth protocol perspective, impact of RT leakage can be = limited through rotation. So I would argue RTs are better protected than = ATs.
AFAIK relatively few providers today offer RT = rotation (Microsoft is an example of widely adopted provider who = doesn't), and even if they do: if you steal an RT and use it to get an = AT you will enjoy full AT use until the legitimate client attempts a = refresh, which will be typically at near expiry time, hence gaining very = little. And given that even fewer providers offer access token = revocation as a consequence of attempted RT reuse, even more frequent = refresh attempts won't reduce the time the attacker has to use the = access token they obtained. Hence I am not sure I buy the argument that = RTs are better protected than ATs, both from the theoretical perspective = and the practical one. And in practical terms, if a developer is tied to = a provider that doesn't offer full RT rotation asking them to store RTs = will make them worse off than they are today. I am of course all for = encouraging providers to introduce proper RT rotation support, but until = they do developers receiving this guidance TODAY will be stuck between a = rock and a hard place.

> Interesting question :-) I think login and API access = are quite different. 
Once again, this is very = theoretical :) you, myself and the cohort on this lost can appreciate = the difference between the two scenarios- but from most practitioners = without identity background, sign out is "the user can't use the app = anymore until they enter their credentials again". Whether they = implement a proper sign in or go straight to API calling, the visible = effect they want to achieve is that one. With implicit today, the access = is all predicated on a single artifact- the provider session cookie. If = I have two apps in two tabs, signing out from one automatically robs the = other from the ability to retain continued access. By introducing = another artifact that can provide continued access and whose existence = is independent from the session cookie, either I explicitly manage the = lifecycle of that artifact (by deleting it at the right time) or my app = will simply be able to continue accessing API regardless of the fact = that my session with the OP ended.

> In the API case, the AS can just = revoke the RT when the logout happens.
That's just not how that works for many of the big providers, = and without introducing new switches I don't think it should. RTs are = issued for offline access purposes, hence their lifetime can (and often = will) exceed the lifetime of sessions. Borrowing from classic web = scenarios, I can sign in and out of twitter as much as I want- that = should not affect twitter's ability to call APIs even when I don't have = a current session. That's the canonical use case I think of when = thinking of RTs.
The challenge with SPAs is that = successfully calling APIs is often used in lieu of proper sign in; we = can repeat until we're blue in the face that this leaves apps prone to = confused deputy and the like, but in practice people will keep doing it = because to the non-initiated that makes intuitive sense. Hence either we = introduce a switch that tells the AS that the RT we are asking for needs = to be tied to the session, and manage revocation accordingly, or we = manage the persistence of the RT at the application side. The latter = seems much easier to achieve to me, and above all more immediately = actionable given that I doubt providers will be very prompt in = introducing new features like the one hypothesized here. 


On Thu, Dec 6, 2018 at = 4:49 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Vittorio,

> Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci <Vittorio@auth0.com>:
>
> Thank you!
> On the RT, more questions:
>
> - where would you save the RT? Iam thinking of the no-backend case = in particular. There=E2=80=99s a lot of heartburn in the community on = where to save access tokens already, given the larger scope of refresh = tokens I would expect objections there would be exacerbated.

Interesting, I=E2=80=99m much more concerned about tokens transmitted in = URLs since those tokens are vulnerable to remote attacks.

Regarding protection at rest: what=E2=80=99s the attacker model in those = discussions? XSS? Local attacks on the device?

Much of the mechanisms are platform specific and need platform = expertise.

>=46rom the OAuth protocol perspective, impact of RT leakage can be = limited through rotation. So I would argue RTs are better protected than = ATs.

> The user experience bar (number of prompts, full page redirects) = should be the one afforded by implicit leveraging AS sessions via = persistent cookies.

sure. I don=E2=80=99t see any technical difference in the way the = browser is utilized for both flows and therefore would be surprised to = see differences in UX.

> 
> - how would we advise developers about handling distributed sign = out? If the session cookie with the AS is no longer  the only = artifact representing the effective session, it looks like we should be = prescriptive on what signals an app should listen for (OIDC = checkSession?) and what the expected actions are (e.g. remove the cached = RTs). I realize this isn=E2=80=99t strictly OAuth2, but it remains an = important difference in end to end scenarios people use implicit for = today

Interesting question :-) I think login and API access are quite = different.

In login the client potentially wants to tightly couple its session = lifecycle to the AS/OP session, simply because it relies on the user id = attested by the OP=E2=80=99s for its local user/session management.

For API access, this is not needed. The client =E2=80=9Ejust=E2=80=9C = obtains a credential to access certain APIs on behalf of the resource = owner. The identity of the resource owner on the AS side and the = identity of the client user don=E2=80=99t necessary have a relationship. = As you know, OAuth was intentionally built to hide the resource owner = identity from the client. I think in this case the resource owner or the = AS might have an interest to terminate API access in case of logout at = the AS.

Protocol-wize this result in huge differences: In the login case, the = client can check the session with the OP periodically and terminate its = own session in case the identity changed or there is no longer a = session. This typically requires frontend interactions and OpenID = Connect (session mgmt or logout).

In the API case, the AS can just revoke the RT when the logout happens. =

kind regards,
Torsten.

>
> Thx
> V.
>
> On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>
>
> Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci <vittorio.bertocci@auth0.com>:
>
>> Hey Torsten/Tomek,
>> Can I ask a clarification on the below?
>> Torsten, you mentioned that an AS doesn't need to issue a RT- = the browser code can just repeat an authorization request. Did I get it = right?
>> But in order to preserve the user experience, that cannot = really happen as a full page redirect; right? That wouldn't fly for any = kind of background update, or for retrieving new ATs for different = resources based on the same session. So would we now use a hidden frame = to retrieve a code in the same way in which we used fragments to get new = ATs?
>
> That=E2=80=99s what I meant. I also think the RT-based approach is = better suited in terms of UX and security.
>
>> Thx
>> V.
>>
>> On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> Hi Tomek,
>>
>> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki <tstojecki@yahoo.com>:
>> >
>> > Hi Torsten,
>> >
>> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten = Lodderstedt <torsten@lodderstedt.net> wrote:
>> >
>> >
>> > >> So if I am putting myself in the shoes of = somebody who sets out to do that - switch an existing SPA client (no = backend)
>> >
>> > > I would like to ask you a question: how many SPAs w/o = a backend have you seen in your projects?
>> >
>> > SPA (html+js) utilizing a 3rd party api that requires = authorization?
>> > If you do have a backend, aren't you better of handling = the token request on the backend as pointed out here
>> > https://github.com/aaronpk/oauth-browser-based-apps/blob/master= /oauth-browser-based-apps.md#javascript-app-with-a-backend-component >>
>> I agree.
>>
>> > My point of putting (no backend) in parenthesis was to not = derail this discussion and of course it had the opposite effect.
>> >
>>
>> You know, I you says =E2=80=9Edon=E2=80=99t look at the green = car=E2=80=9C will cause everyone looking for it :-) It asked just out of = curiosity.
>>
>> > >> Is that fair or is that too much of a shortcut? I = am familiar with the specs you've referenced and have looked at them = again, but dealing with a SPA, some of the recommendations are not = feasible (can't authenticate the client,
>> >
>> > > You could using dynamic registration (see other = thread). The protection would only differ from refresh token rotation if = you would use public key crypto for client authentication.
>> >
>> > Good point. How well is dynamic registration supported = across AS?
>>
>> I leave that to the vendors :-)
>>
>> >
>> > >> confidentiality in storage? - not sure how to = read that in the context of a browser)
>> >
>> > > How do you ensure confidentiality of session = cookies?
>> >
>> > All I am trying to say is that I think context is = important here. So when you point out these best practices, some of them = will get people confused as far as what it means in the browser based = app scenario.
>>
>> That=E2=80=99s why we have the more general Security BCP and = client-specific BCPs, like for native apps (https://tools.ietf.org/html/rfc8252) = and the new BCP for SPAs Aaron started to work on.
>>
>> > Maybe it is just me :)
>>
>> thanks for raising the question! We need this kind of input to = govern the development of our specs.
>>
>> kind regards,
>> Torsten.
>>
>> >
>> > >
>> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, = Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> > >
>> > >
>> > > Hi Tomek,
>> > >
>> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki = <tstojecki=3D40yahoo.com@dmarc.ietf.org>:
>> > > >
>> > > > I agree with Vittorio, Dominick et al.
>> > > >
>> > > >> I disagree.
>> > > >
>> > > >> Existing deployments that have not mitigated = against the concerns with implicit should be ripped up and updated.
>> > > >
>> > > > Yes, just like future deployments that will not = mitigate against the concerns of code in the browser should be a = concern.
>> > >
>> > > I agree. That=E2=80=99s why I pointed point yesterday = that the Security BCP also defines obligations for clients using code. =
>> > >
>> > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10= #section-2.1
>> > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10= #section-2.1.1
>> > >
>> > > >
>> > > > Can somebody on the other side of the argument = (and I hate to make it sound like there are two sides, because we're on = the same side as far as Implicit's AT in front-channel is a real issue) = address Dominic's comment:
>> > > >
>> > > >> Also - simply saying =E2=80=9Cimplicit is = evil - switch to code=E2=80=9D means for most people also using refresh = token - so we are treating access tokens in the URL with refresh tokens = in session storage (over simplified - but you get the idea).
>> > > >
>> > > > Does the group agree|disagree that a = recommendation to switch to code should be made as long as it is = followed by an explanation and guidance on what to do with RTs? The = ideas that were floated around
>> > > > - Token bound RTs (even though it was pointed = out that token binding is still considered an emerging standard). So = should the recommendation than say "switch to code and MUST use token = bound RTs"?
>> > > > - Have AS not release RTs. "Switch to code and = DO NOT request RTs"? Or switch to code and configure AT to not release = RTs for this type of client (not sure what that even looks like in a = form of a 3rd party clients)?
>> > > > - RTs short lived and bound to a session - = "Switch to code as long as AT can bind and revoke RTs when you log = out=E2=80=9C
>> > >
>> > > Basically, the AS does not need to issue refresh = tokens. If the AS does not issue refresh tokens, the integration pattern = for SPAs does not change (beside the code exchange). If the client needs = a new access token, it will perform another authorization request.  =
>> > >
>> > > If it does, this adds another layer of security = because it allows the client to frequently obtain new access tokens, = which can be short-lived and scope restricted.
>> > >
>> > > The refresh tokens should be replay protected by = issuing new refresh tokens with every refresh and detect replay for = refresh tokens belonging to the same grant.
>> > >
>> > > The AS may additionally bind refresh tokens to AS = sessions, but as it was pointed out by Annabelle and others, there are = some implications to be understood and managed in that context.
>> > >
>> > > You may find more text about refresh tokens in the = Security BCP https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10= #section-3.12
>> > >
>> > > kind regards,
>> > > Torsten.
>> > >
>> > >
>> > > >
>> > > > Sorry if I have missed an important detail from = the list above, people who have proposed these ideas, feel free to = clarify.
>> > >
>> > > >
>> > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, = Dick Hardt <dick.hardt@gmail.com> wrote:
>> > > >
>> > > > I disagree.
>> > > >
>> > > > Existing deployments that have not mitigated = against the concerns with implicit should be ripped up and updated.
>> > > >
>> > > > For example, at one time, I think it was = Instagram that had deployed implicit because it was easier to do. Once = the understood the security implications, they changed the = implementation.
>> > > >
>> > > > BCPs are rarely a response to a new threat, = their are capturing Best Current Practices so that they become widely = deployed.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell = <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:
>> > > >> FWIW I'm somewhat sympathetic to what = Vittorio, Dominick, etc. are saying here. And that was kind of behind = the comment I made, or tired to make, about this in Bangkok, which was = (more or less) that I don't think the WG should be killing implicit = outright but rather that it should begin to recommend against it.
>> > > >>
>> > > >> I'm not exactly sure what that looks like in = this document but maybe toning down some of the scarier language a bit, = favoring SHOULDs vs. MUSTs, and including language that helps a reader = understand the recommendations as being more considerations for new = applications/deployments than as a mandate to rip up existing ones.
>> > > >>
>> > > >>
>> > > >>
>> > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley = <ve7jtb@ve7jtb.com> wrote:
>> > > >>>
>> > > >>> We just need to be sensitive to the spin = on this. 
>> > > >>>
>> > > >>
>> > > >> 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
>> > > >>
>> > > > = _______________________________________________
>> > > > 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

= --Apple-Mail=_3C0681C6-7C6E-48FE-B9F0-CF12256722B6-- From nobody Fri Dec 7 15:25:14 2018 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 B919E130E7D for ; Fri, 7 Dec 2018 15:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_SINGLE_WORD=2.351, 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=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 mMJ0Gr4Zu3OM for ; Fri, 7 Dec 2018 15:25:11 -0800 (PST) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 3ABF912D4E7 for ; Fri, 7 Dec 2018 15:25:11 -0800 (PST) Received: by mail-oi1-x22f.google.com with SMTP id y1so2961623oie.12 for ; Fri, 07 Dec 2018 15:25:11 -0800 (PST) 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=t6cMWrUQQHUjJIMLAE79XQfd02ob+TbGoDnJX7LqXiY=; b=rlNlTOexa8yd19Q7hoFhO2fduyHFJL2O/hDx4gw4svAjVXnxYyfK0hTltRe7oAXwyS w/CnpnR3yR8qfGe/7Z+bF3CcJRTA279qCN2vOikXMlwBQSmePZD6VUSPqjO/YRz2MjzZ TRp6EsUmLeJOB4RSyU6Iya12G6GCT9jI0ujnCrs3tZLIwknBoAgVht2xqoHw82R2p79p 7ilRxzIMfhcABkHr8e3I/bURzRe9uGnLBwK7hFA159jl19AQu2qSEopSTyZTqakASyVL gSSiglmSGDc5a2/FIKAaoeDxDoTkedKlVL4b/uAX/kIvu0qWl9a9yV3vLW5A3ZudNj8j fqtw== 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=t6cMWrUQQHUjJIMLAE79XQfd02ob+TbGoDnJX7LqXiY=; b=Mz0twYuPJ8/VlMIUjpEHOOn41C+LaMpNJy+SEyTQ0HtFHvR+ljpyEUYTJxz18HX3oJ kM30/X53PJPgbIX4v3BKil7uajZ3d1eE/wGNtGFO3bceX3aSkZcEreG2HmCmz97Xrpng XKTH1f1YLG3sIk2L8adIyGC9kUmgoAGfXTw0KrP3vUoMpMw1rOGOugRfQ9xoUTQGzlNv RxdBXDkCnQhN+U5ZrrpZKU89xv8VSTC9GdEjPKU8vQe7Wqm/FdVxIMcoLqC1ZFTTpMv6 7/k6QxPErS5O4+fj01qPOu/mau6zykdx12ArLBpnc60OcwKBREtZPkFSrB+SCVtAz1y+ M3qA== X-Gm-Message-State: AA+aEWaZ+t11DYTnaEwJ0ELeqABim1UUaxi1ZkwzWRco9fg87INWhvgl 6qtNnP+5H4lFFBsiF9IgriyVl1KZ3rR5uEYPT3JZ8xvC X-Google-Smtp-Source: AFSGD/Uy7lSPhYUZz7O3t95PbIX+wsVqglMcY8d9myWbERP6jgh0z6Eqpz3a5Aem5bcgu0SRuNbhbdi5Y5IFCzf2ePk= X-Received: by 2002:a54:4d8e:: with SMTP id y14mr2482990oix.60.1544225110132; Fri, 07 Dec 2018 15:25:10 -0800 (PST) MIME-Version: 1.0 From: Chef Saroar Date: Sat, 8 Dec 2018 05:24:58 +0600 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000248f4e057c76ed43" 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: Fri, 07 Dec 2018 23:25:13 -0000 --000000000000248f4e057c76ed43 Content-Type: text/plain; charset="UTF-8" Hi --000000000000248f4e057c76ed43 Content-Type: text/html; charset="UTF-8"
Hi
--000000000000248f4e057c76ed43-- From nobody Sat Dec 8 05:12:35 2018 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 3683F12D84C for ; Sat, 8 Dec 2018 05:12:34 -0800 (PST) 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 kF_98SyORvNF for ; Sat, 8 Dec 2018 05:12:29 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) (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 3F46212D4E6 for ; Sat, 8 Dec 2018 05:12:27 -0800 (PST) Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gVcP9-00033X-3h; Sat, 08 Dec 2018 14:12:23 +0100 From: Torsten Lodderstedt Message-Id: <1333FFC2-A2F0-479D-8E7C-9ACFEC8E5724@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_FF02C08D-1A59-4EF3-B155-27ECBFB7B8A3"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Sat, 8 Dec 2018 14:12:21 +0100 In-Reply-To: Cc: Brian Campbell , Daniel Fett , IETF oauth WG , Tomek Stojecki To: Vittorio Bertocci References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 08 Dec 2018 13:12:34 -0000 --Apple-Mail=_FF02C08D-1A59-4EF3-B155-27ECBFB7B8A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Vittorio, > Am 06.12.2018 um 19:09 schrieb Vittorio Bertocci : >=20 > Thank you Torsten. > I think that a lot of the considerations below need to be tempered = with concrete considerations about the features developers can actually = rely on today. > I agree with identifying the theoretical framework and north star we = want to aspire to, but if we are framing the recommendation here in form = of practice, we have to ensure it is actionable for developers. I am not = pushing back on ideas, but I just want to make sure that when customers = hear this advice, they are actually in the position to apply it. And if = there are missing pieces, perhaps we should consider this more as = guidance to the vendors that need to provide key enablers for this to = become viable, and recommend it as practice to customers only when that = happened. I agree. That=E2=80=99s what basically happened with mTLS and Token = Binding. We realized the need to find a reasonable way to prevent token = replay in the course of our in-depth security analysis. Out of the two = options (audience restriction and sender constrained tokens), we = selected sender constrained tokens because they are the most appropriate = measure (or just "build for that purpose" as Dirk Balfanz pointed out at = that time). Token Binding unfortunately lost some traction but mTLS can = be used instead and is being used in the open banking space by all = initiatives I=E2=80=99m aware of (UK OB, STET, BerlinGroup). So we were = right on time.=20 I see the same happening with respect to implicit and SPAs now. I think = the baseline is clear: implicit is replaced by code+PKCE, so SPAs need = to be extended to handle PKCE and exchange the code for an access token. = This step is a huge security improvement since it closes the attack = angle of leakage and injection/replay via the URL. This requires the respective solutions to support response type = code/grant type authorization code (lib & AS), PKCE (lib & AS) and CORS = (AS) for public clients.=20 > I add more details inline below, however I have a meta point to make: = did all the vendors on the list work on proof of concepts to ensure that = the practices recommended here can work with your product, end to end?=20= > I don't mean just doing a code+PKCE demo in JS, I mean complying with = things like RT rotation and revocation end to end, using released = features that your customers can use today. If you did, it might really = help to use them to make those discussions more concrete. If you didn't, = then calling the proposal a practice might be premature. I understand your argument and I would be happy to just document best = security practices. The reality is, most people don=E2=80=99t care about = security and most practices I have seen are more on the bad practice = end. So what shall we do? Sit on our hands? In my observation, the SPA OAuth universe to a large extend developed = completely independent of the rest of the OAuth universe. For example, I = saw SPA libraries recommending implicit and the resource owner = credential grant. Wow! What a mixture when combined with XSS! I think we can transfer some proven techniques from the general OAuth = world into the SPA OAuth world, e.g. code & PKCE. Add CORS to that and = we have a reasonable baseline for SPAs, which copes with the particular = threats implicit is vulnerable to. One hole closed, great! Opening the picture a bit, we must realize token leakage also happens at = resource servers, that's why we included the recommendation for sender = constrained tokens to the BCP (for _all_ kinds of clients!).=20 mTLS works well for native and web apps. It won=E2=80=99t work well for = SPA=E2=80=99s simply because the SPA cannot automatically setup a cert = in the browser, so it would need an external enrollment process. It will = also result in a poor UX due to selection dialogs etc. Token binding = would be the much better solution but lacks adoption. =20 That=E2=80=99s why I think refresh tokens should be considered at least = as a means to limit the impact of access token leakage at RSs. The = measures I propose have been implemented and used in production for = years at Deutsche Telekom (consumer services, millions of unique users). = I also think Oath implemented RT revocation on logout. But I also = realized commercial vendors and other deployments seem to have less = sophisticated implementations in place. So where does this leave us? = Running code exists but more vendors must support these features. One = could also say: What are ideas for some people is proven practice for = others. > inline: > =20 >=20 > > Regarding protection at rest: what=E2=80=99s the attacker model in = those discussions? XSS? Local attacks on the device? > The main concern is XSS. You can just google token session storage to = find an onslaught of articles and forum threads on the topic. To pick = one at random, here's the one from Mozilla. > We can argue on what's worse between XSS and URL leaks, but I don't = think we can ignore the pervasive ongoing debate and perception that use = of local storage for sensitive data is bad. I don=E2=80=99t ignore XSS. I want to solve the problems one after the = other focussing on OAuth related stuff first. Switching from implicit to = code solves leakage and injection in OAuth protocol messages.=20 XSS can be solved in a sustained fashion using browser features only. If = an app includes code from untrusted locations then this code can access = all browser APIs from the SPAs origin. Nothing will stop an attacker = from accessing local storage, web crypto API etc on behalf of the API. = So yes, SPAs need to implement proper XSS protection - independent of = OAuth. Jim already posted an advice on this topic.=20 >=20 >=20 > > Much of the mechanisms are platform specific and need platform = expertise.=20 > I don't follow this one. We are targeting the browser, right? What are = the platform specific features you are thinking about? In this discussion, the platform is the browser.=20 But my focus is not on browser clients only. I=E2=80=99m editing (along = with John, Daniel and Andrey) the OAuth Security BCP. So I=E2=80=99m = looking into recommendations for all sorts of OAuth clients/deployments = and want to make sure a reasonable common security level. That=E2=80=99s = why the place where the access tokens are ultimately used (the RS) and = can leak and be replayed also concerns me. Browser-based clients are just one client categories. Ensuring the = confidentiality of tokens is always a very client platform specific = matter. It works differently on iOS than on Windows 10 and requires = platform expertise and dedicated documentation (which would bloat the = Security BCP). That=E2=80=99s why there is need for client type specific = BCPs. We have one for native apps and now work is being done towards a = SPA BCP. That=E2=80=99s where this kind of consideration should land.=20 >=20 >=20 > > =46rom the OAuth protocol perspective, impact of RT leakage can be = limited through rotation. So I would argue RTs are better protected than = ATs. > AFAIK relatively few providers today offer RT rotation (Microsoft is = an example of widely adopted provider who doesn't), and even if they do: = if you steal an RT and use it to get an AT you will enjoy full AT use = until the legitimate client attempts a refresh, which will be typically = at near expiry time, hence gaining very little. Depends on AT lifetime. With RTs you can have very short ATs lifetime = further reducing the attack window. The AT lifetime should be determined = by the respective RSs sensitivity. =20 > And given that even fewer providers offer access token revocation as a = consequence of attempted RT reuse, even more frequent refresh attempts = won't reduce the time the attacker has to use the access token they = obtained. Hence I am not sure I buy the argument that RTs are better = protected than ATs, both from the theoretical perspective and the = practical one. And in practical terms, if a developer is tied to a = provider that doesn't offer full RT rotation asking them to store RTs = will make them worse off than they are today. I am of course all for = encouraging providers to introduce proper RT rotation support, but until = they do developers receiving this guidance TODAY will be stuck between a = rock and a hard place. It=E2=80=99s a good idea to conduct a survey regarding existing RT = implementation practices. I=E2=80=99m under the impression vendors so = far underestimated the value of RT when it comes to limiting the impact = of token leakage. That=E2=80=99s one reason why I added the RT section = to the Security BCP. >=20 > > Interesting question :-) I think login and API access are quite = different.=20 > Once again, this is very theoretical :) Oh, I just tried to address your arguments with what I consider a = substantial answers :-). =20 > you, myself and the cohort on this lost can appreciate the difference = between the two scenarios- but from most practitioners without identity = background, sign out is "the user can't use the app anymore until they = enter their credentials again=E2=80=9C. Can you give a concrete example? To me it feels like you are explaining = scenarios where OAuth is used for login. > Whether they implement a proper sign in or go straight to API calling, = the visible effect they want to achieve is that one. With implicit = today, the access is all predicated on a single artifact- the provider = session cookie. If I have two apps in two tabs, signing out from one = automatically robs the other from the ability to retain continued = access. Are you assuming the AS revokes the AT on logout? Otherwise the other = app will realize the session termination when it attempts to obtain a = new AT in another authorization flow. > By introducing another artifact that can provide continued access and = whose existence is independent from the session cookie, either I = explicitly manage the lifecycle of that artifact (by deleting it at the = right time) or my app will simply be able to continue accessing API = regardless of the fact that my session with the OP ended. Revoking the RT on logout is the proper solution for OAuth.=20 >=20 > > In the API case, the AS can just revoke the RT when the logout = happens. > That's just not how that works for many of the big providers, and = without introducing new switches I don't think it should. RTs are issued = for offline access purposes, hence their lifetime can (and often will) = exceed the lifetime of sessions. Are those RT=E2=80=99s request for offline_access? Then I would argue = this behavior is just fine and inline with the way OAuth is intended to = work.=20 > Borrowing from classic web scenarios, I can sign in and out of twitter = as much as I want- that should not affect twitter's ability to call APIs = even when I don't have a current session. That's the canonical use case = I think of when thinking of RTs. > The challenge with SPAs is that successfully calling APIs is often = used in lieu of proper sign in; we can repeat until we're blue in the = face that this leaves apps prone to confused deputy and the like, but in = practice people will keep doing it because to the non-initiated that = makes intuitive sense. Hence either we introduce a switch that tells the = AS that the RT we are asking for needs to be tied to the session, and = manage revocation accordingly, or we manage the persistence of the RT at = the application side. You mean discard the RT or revoke it explicitly on the app side? > The latter seems much easier to achieve to me, and above all more = immediately actionable given that I doubt providers will be very prompt = in introducing new features like the one hypothesized here.=20 The scope offline access exists (although in the OIDC universe). Don=E2=80= =99t you think it could be used for that purpose? kind regards, Torsten.=20 >=20 >=20 > On Thu, Dec 6, 2018 at 4:49 AM Torsten Lodderstedt = wrote: > Hi Vittorio, >=20 > > Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci = : > >=20 > > Thank you! > > On the RT, more questions: > >=20 > > - where would you save the RT? Iam thinking of the no-backend case = in particular. There=E2=80=99s a lot of heartburn in the community on = where to save access tokens already, given the larger scope of refresh = tokens I would expect objections there would be exacerbated. >=20 > Interesting, I=E2=80=99m much more concerned about tokens transmitted = in URLs since those tokens are vulnerable to remote attacks.=20 >=20 > Regarding protection at rest: what=E2=80=99s the attacker model in = those discussions? XSS? Local attacks on the device? >=20 > Much of the mechanisms are platform specific and need platform = expertise.=20 >=20 > =46rom the OAuth protocol perspective, impact of RT leakage can be = limited through rotation. So I would argue RTs are better protected than = ATs. >=20 > > The user experience bar (number of prompts, full page redirects) = should be the one afforded by implicit leveraging AS sessions via = persistent cookies. >=20 > sure. I don=E2=80=99t see any technical difference in the way the = browser is utilized for both flows and therefore would be surprised to = see differences in UX.=20 >=20 > > =20 > > - how would we advise developers about handling distributed sign = out? If the session cookie with the AS is no longer the only artifact = representing the effective session, it looks like we should be = prescriptive on what signals an app should listen for (OIDC = checkSession?) and what the expected actions are (e.g. remove the cached = RTs). I realize this isn=E2=80=99t strictly OAuth2, but it remains an = important difference in end to end scenarios people use implicit for = today >=20 > Interesting question :-) I think login and API access are quite = different.=20 >=20 > In login the client potentially wants to tightly couple its session = lifecycle to the AS/OP session, simply because it relies on the user id = attested by the OP=E2=80=99s for its local user/session management.=20 >=20 > For API access, this is not needed. The client =E2=80=9Ejust=E2=80=9C = obtains a credential to access certain APIs on behalf of the resource = owner. The identity of the resource owner on the AS side and the = identity of the client user don=E2=80=99t necessary have a relationship. = As you know, OAuth was intentionally built to hide the resource owner = identity from the client. I think in this case the resource owner or the = AS might have an interest to terminate API access in case of logout at = the AS.=20 >=20 > Protocol-wize this result in huge differences: In the login case, the = client can check the session with the OP periodically and terminate its = own session in case the identity changed or there is no longer a = session. This typically requires frontend interactions and OpenID = Connect (session mgmt or logout). >=20 > In the API case, the AS can just revoke the RT when the logout = happens.=20 >=20 > kind regards, > Torsten.=20 >=20 > >=20 > > Thx > > V. > >=20 > > On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt = wrote: > >=20 > >=20 > > Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci = : > >=20 > >> Hey Torsten/Tomek, > >> Can I ask a clarification on the below? > >> Torsten, you mentioned that an AS doesn't need to issue a RT- the = browser code can just repeat an authorization request. Did I get it = right? > >> But in order to preserve the user experience, that cannot really = happen as a full page redirect; right? That wouldn't fly for any kind of = background update, or for retrieving new ATs for different resources = based on the same session. So would we now use a hidden frame to = retrieve a code in the same way in which we used fragments to get new = ATs? > >=20 > > That=E2=80=99s what I meant. I also think the RT-based approach is = better suited in terms of UX and security. > >=20 > >> Thx > >> V. > >>=20 > >> On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt = wrote: > >> Hi Tomek,=20 > >>=20 > >> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki = : > >> >=20 > >> > Hi Torsten, > >> >=20 > >> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten = Lodderstedt wrote: > >> >=20 > >> >=20 > >> > >> So if I am putting myself in the shoes of somebody who sets = out to do that - switch an existing SPA client (no backend) > >> >=20 > >> > > I would like to ask you a question: how many SPAs w/o a backend = have you seen in your projects? > >> >=20 > >> > SPA (html+js) utilizing a 3rd party api that requires = authorization? > >> > If you do have a backend, aren't you better of handling the token = request on the backend as pointed out here > >> > = https://github.com/aaronpk/oauth-browser-based-apps/blob/master/oauth-brow= ser-based-apps.md#javascript-app-with-a-backend-component > >>=20 > >> I agree.=20 > >>=20 > >> > My point of putting (no backend) in parenthesis was to not derail = this discussion and of course it had the opposite effect. > >> >=20 > >>=20 > >> You know, I you says =E2=80=9Edon=E2=80=99t look at the green = car=E2=80=9C will cause everyone looking for it :-) It asked just out of = curiosity.=20 > >>=20 > >> > >> Is that fair or is that too much of a shortcut? I am familiar = with the specs you've referenced and have looked at them again, but = dealing with a SPA, some of the recommendations are not feasible (can't = authenticate the client,=20 > >> >=20 > >> > > You could using dynamic registration (see other thread). The = protection would only differ from refresh token rotation if you would = use public key crypto for client authentication. > >> >=20 > >> > Good point. How well is dynamic registration supported across AS?=20= > >>=20 > >> I leave that to the vendors :-) > >>=20 > >> >=20 > >> > >> confidentiality in storage? - not sure how to read that in the = context of a browser) > >> >=20 > >> > > How do you ensure confidentiality of session cookies? > >> >=20 > >> > All I am trying to say is that I think context is important here. = So when you point out these best practices, some of them will get people = confused as far as what it means in the browser based app scenario. > >>=20 > >> That=E2=80=99s why we have the more general Security BCP and = client-specific BCPs, like for native apps = (https://tools.ietf.org/html/rfc8252) and the new BCP for SPAs Aaron = started to work on. > >>=20 > >> > Maybe it is just me :) > >>=20 > >> thanks for raising the question! We need this kind of input to = govern the development of our specs. > >>=20 > >> kind regards, > >> Torsten.=20 > >>=20 > >> >=20 > >> > >=20 > >> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten = Lodderstedt wrote: > >> > >=20 > >> > >=20 > >> > > Hi Tomek, > >> > >=20 > >> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki = : > >> > > >=20 > >> > > > I agree with Vittorio, Dominick et al.=20 > >> > > >=20 > >> > > >> I disagree.=20 > >> > > >=20 > >> > > >> Existing deployments that have not mitigated against the = concerns with implicit should be ripped up and updated. > >> > > >=20 > >> > > > Yes, just like future deployments that will not mitigate = against the concerns of code in the browser should be a concern. > >> > >=20 > >> > > I agree. That=E2=80=99s why I pointed point yesterday that the = Security BCP also defines obligations for clients using code.=20 > >> > >=20 > >> > > = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.= 1 > >> > > = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.= 1.1 > >> > >=20 > >> > > >=20 > >> > > > Can somebody on the other side of the argument (and I hate to = make it sound like there are two sides, because we're on the same side = as far as Implicit's AT in front-channel is a real issue) address = Dominic's comment:=20 > >> > > >=20 > >> > > >> Also - simply saying =E2=80=9Cimplicit is evil - switch to = code=E2=80=9D means for most people also using refresh token - so we are = treating access tokens in the URL with refresh tokens in session storage = (over simplified - but you get the idea). > >> > > >=20 > >> > > > Does the group agree|disagree that a recommendation to switch = to code should be made as long as it is followed by an explanation and = guidance on what to do with RTs? The ideas that were floated around=20 > >> > > > - Token bound RTs (even though it was pointed out that token = binding is still considered an emerging standard). So should the = recommendation than say "switch to code and MUST use token bound RTs"? > >> > > > - Have AS not release RTs. "Switch to code and DO NOT request = RTs"? Or switch to code and configure AT to not release RTs for this = type of client (not sure what that even looks like in a form of a 3rd = party clients)? > >> > > > - RTs short lived and bound to a session - "Switch to code as = long as AT can bind and revoke RTs when you log out=E2=80=9C > >> > >=20 > >> > > Basically, the AS does not need to issue refresh tokens. If the = AS does not issue refresh tokens, the integration pattern for SPAs does = not change (beside the code exchange). If the client needs a new access = token, it will perform another authorization request. =20 > >> > >=20 > >> > > If it does, this adds another layer of security because it = allows the client to frequently obtain new access tokens, which can be = short-lived and scope restricted.=20 > >> > >=20 > >> > > The refresh tokens should be replay protected by issuing new = refresh tokens with every refresh and detect replay for refresh tokens = belonging to the same grant.=20 > >> > >=20 > >> > > The AS may additionally bind refresh tokens to AS sessions, but = as it was pointed out by Annabelle and others, there are some = implications to be understood and managed in that context. > >> > >=20 > >> > > You may find more text about refresh tokens in the Security BCP = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.= 12 > >> > >=20 > >> > > kind regards, > >> > > Torsten. > >> > >=20 > >> > >=20 > >> > > >=20 > >> > > > Sorry if I have missed an important detail from the list = above, people who have proposed these ideas, feel free to clarify.=20 > >> > >=20 > >> > > >=20 > >> > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt = wrote:=20 > >> > > >=20 > >> > > > I disagree.=20 > >> > > >=20 > >> > > > Existing deployments that have not mitigated against the = concerns with implicit should be ripped up and updated. > >> > > >=20 > >> > > > For example, at one time, I think it was Instagram that had = deployed implicit because it was easier to do. Once the understood the = security implications, they changed the implementation.=20 > >> > > >=20 > >> > > > BCPs are rarely a response to a new threat, their are = capturing Best Current Practices so that they become widely deployed. > >> > > >=20 > >> > > >=20 > >> > > >=20 > >> > > >=20 > >> > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell = wrote: > >> > > >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, = etc. are saying here. And that was kind of behind the comment I made, or = tired to make, about this in Bangkok, which was (more or less) that I = don't think the WG should be killing implicit outright but rather that = it should begin to recommend against it.=20 > >> > > >>=20 > >> > > >> I'm not exactly sure what that looks like in this document = but maybe toning down some of the scarier language a bit, favoring = SHOULDs vs. MUSTs, and including language that helps a reader understand = the recommendations as being more considerations for new = applications/deployments than as a mandate to rip up existing ones.=20 > >> > > >>=20 > >> > > >>=20 > >> > > >>=20 > >> > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley = wrote: > >> > > >>>=20 > >> > > >>> We just need to be sensitive to the spin on this. =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._______________________________________________ > >> > > >> 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 > >> > > _______________________________________________ > >> > > OAuth mailing list > >> > > OAuth@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/oauth > >>=20 >=20 --Apple-Mail=_FF02C08D-1A59-4EF3-B155-27ECBFB7B8A3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODEyMDgxMzEyMjJaMC8GCSqGSIb3DQEJBDEiBCCo 67FpgEH9yTHiw9ygnIIqqkoKcCFGlMhyQozWlVHo+jCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAqH4T6M9/bOrBAzX4tzXLY+Aj 2Zkjv0f2WBv4IPkCzimH4RXm9VUuzvohQmTP/0moVl/Qw8wGFR6wd/zbtxbtaT7rQ+8+xH2zF6ux YkmAkfSu3kKmNlG/VsV5xQ+CQgwCszHepnRUctnqt+03F0yBrTDgbGPPFE7Zp+tA4XpN59ZygYIK x8ddsyZah4CxUe3C5PzJJGmfW+8e3sE3hMb9tPI8oPBo7cT4WoJTwyXJpHPCKlzLjCEEakGmTESW ebjCDLDgXarwUyVbUQawjtBNdMVxA+YCDnZFMFnytXaK+IdLasZpJkq5PchLrDqeUkxWiJFXokQo QhSZ84X7MnVcDwAAAAAAAA== --Apple-Mail=_FF02C08D-1A59-4EF3-B155-27ECBFB7B8A3-- From nobody Sat Dec 8 05:20:53 2018 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 0019C12DDA3 for ; Sat, 8 Dec 2018 05:20:51 -0800 (PST) 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 Dktbm7I4o0gN for ; Sat, 8 Dec 2018 05:20:50 -0800 (PST) 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 DB65412D4E6 for ; Sat, 8 Dec 2018 05:20:49 -0800 (PST) Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gVcXF-0004hl-Jm; Sat, 08 Dec 2018 14:20:45 +0100 From: Torsten Lodderstedt Message-Id: <9A3744F9-B3D0-4AB3-95AB-7033A40BD51E@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_9E2C64E9-E877-4A93-BF39-1EABB1D88839"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Sat, 8 Dec 2018 14:20:44 +0100 In-Reply-To: <115824C4-61C1-4986-A30F-382A1AA563BB@gmail.com> Cc: Vittorio Bertocci , Daniel Fett , IETF oauth WG To: Nov Matake References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> <115824C4-61C1-4986-A30F-382A1AA563BB@gmail.com> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 08 Dec 2018 13:20:52 -0000 --Apple-Mail=_9E2C64E9-E877-4A93-BF39-1EABB1D88839 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Nov, > Am 08.12.2018 um 00:20 schrieb Nov Matake : >=20 > For me, it seems very hard to issue TB-bound token for JS app and = MTLS-bound token for its backend server at same time. Issuing TB tokens in case of implicit is anyway hard. You need to issue = a HTTP redirect to the RS and the RS must respond by HTTP redirecting = the user agent to the AS (including the referred TBID). This is a new = flow requiring an additional security analysis. Obviously, the RS would = see the state value and could modify the request. And the RS endpoint = must be protected against open redirection.=20 >=20 > Do someone has workable recommendation for such case? Why do you need to issue access tokens to both parties, the frontend and = the backend? I would assume a clear layering would either let the SPA or = the backend perform the calls towards Resource EP. kind regards, Torsten.=20 --Apple-Mail=_9E2C64E9-E877-4A93-BF39-1EABB1D88839 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODEyMDgxMzIwNDRaMC8GCSqGSIb3DQEJBDEiBCDM G6bAYhlR+7nN7Iv2x6iriXJr5HuOD3y+ioF0TNZOuDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAbv7J7jtakLLLYnfyrd8twp/q H//foojxgO2I7YTMnFOmJJXS1Bp9gacDq8eDN5RG0U4TA0fLKa09EK8vyH1Qkx3yJjukw1w+hpDk x301ZZtxBuINCkAdjvp2lVsKgly5hr9+yBsdYxyEUv3udd2BUblAQF46q+A1zBpORNfEKgwj23nB FfBMB3P/EW4aKvvhf6Lr/YfXG+ZO2FmqIWQrQyYd7pG9tWlKXSndAfKIzrQXWY49OWMzsVnpQDUt AI+Yixj4XvFKaPJuOvTZM8WK57eNKbsAmGkPBJUeITw81AYxzRVLToci7vuGEDjz1+enuRHIPSlY 1zwgLqU/v2l9pgAAAAAAAA== --Apple-Mail=_9E2C64E9-E877-4A93-BF39-1EABB1D88839-- From nobody Sat Dec 8 07:29:19 2018 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 7D00D130DE9 for ; Sat, 8 Dec 2018 07:29:17 -0800 (PST) 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=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 7bJ4Lk2b6319 for ; Sat, 8 Dec 2018 07:29:15 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 B8021130DDF for ; Sat, 8 Dec 2018 07:29:15 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id n21so7847918qtl.6 for ; Sat, 08 Dec 2018 07:29:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:user-agent; bh=YVmpFSrogEl5Zg/sAPTxxwUAnc2FmNyT67f3RzWp01A=; b=Ww6J6Rd2d9M9g9bKcfOT9YfLwUqtHCXVvKac7iQ6jnFaiyk8dl2lgymNDqtFNQycLA 7QcAPEKB4z2RIUMYbaOJgb6pGt2woOTVIXaI/eAgotRNG1TWP7cA2qokNlN5TU75dFT7 AZF8wUJ0ebMJfluNGJZcPCtAhK/mwD23RntYHGgaKMrOq8F3dCSma6J7hTt0gC5eq+46 UTSgu/UZQ8MJJP+o+E+j7xr57EA/9vxWyX4iQcu7ZXzdLD7QGkdxJ9BKOQkL49uX/6n7 ex+sH11DfjyQttc6lhZxD2U1l35fhp83uTSMupliIwNY2J/rEHA0P+c2kAiRHgU/Ssbg s8BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :user-agent; bh=YVmpFSrogEl5Zg/sAPTxxwUAnc2FmNyT67f3RzWp01A=; b=sMOqzjKCKB+FO0RjBDqi/oq3nc+hNWgeSQVn340eGuj5EMSO0kbveF8lPuEH7kgV7c lLrLhMKvWNUMUUyCcNVobLg3DH+cHZp2KbG/+OND+7BYhF/W43KD2h3WYxYli8kjoRjh FQmsUL3cFt9lciQBfOFHkw8gNy6FRUQz6wOOlppLWc0QiKuxSKsEgB0p2joXsABHPj9I fQRWgy2U/p1SuColgqMP4qn8VD/mL02PvHgyMo81MfLKs06gJJoi/4DqIjJVheTI9x8g Eg+stZdGvqpkoHHmDc68FS6QfcpSUF3yYxc5J88edtCDbFunKUWgUg/f4oQrHSYqUfif k/Fg== X-Gm-Message-State: AA+aEWaLGLyw+q27lZ8uM94b5hSwiPzHHKXuLiVBfSo9Eiqy0fw1/MR1 aJGC6sh1hzVhrjLMKwDxRdboj+4P X-Google-Smtp-Source: AFSGD/VYP91Zkg0RWhmMTv+A/d4PaEQiCC9EyY6OVbIAwZtQTemMBodBxSJtf6KO5bl2vEAI4AVQwg== X-Received: by 2002:ac8:4818:: with SMTP id g24mr5958256qtq.66.1544282954641; Sat, 08 Dec 2018 07:29:14 -0800 (PST) Received: from [10.0.1.3] (pool-96-253-25-169.prvdri.fios.verizon.net. [96.253.25.169]) by smtp.gmail.com with ESMTPSA id x24sm4559572qtk.70.2018.12.08.07.29.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Dec 2018 07:29:14 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_46060242.577307081508" MIME-Version: 1.0 Date: Sat, 08 Dec 2018 10:29:09 -0500 Message-ID: <6d88c55a-a300-47ff-af77-8fdb7dcfbc25@getmailbird.com> From: "Brock Allen" To: "" User-Agent: Mailbird/2.5.24.0 X-Mailbird-ID: 6d88c55a-a300-47ff-af77-8fdb7dcfbc25@getmailbird.com Archived-At: Subject: [OAUTH-WG] draft-parecki-oauth-browser-based-apps and response_type/fragment 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, 08 Dec 2018 15:29:18 -0000 ------=_NextPart_46060242.577307081508 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Should the BCP suggest using OIDC's response_type=3Dfragment as the mechani= sm for returning the code from the AS? Or simply suggest using the fragment= component of the redirect_uri for the code, without a response_type parame= ter (IOW don't allow it to be dynamic)? -Brock ------=_NextPart_46060242.577307081508 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Should the BCP suggest using OIDC's response_t= ype=3Dfragment as the mechanism for returning the code from the AS? Or simp= ly suggest using the fragment component of the redirect_uri for the code, w= ithout a response_type parameter (IOW don't allow it to be dynamic)?

-Brock

------=_NextPart_46060242.577307081508-- From nobody Sat Dec 8 07:55:35 2018 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 86D50130E27 for ; Sat, 8 Dec 2018 07:55:33 -0800 (PST) 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_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 FQqkO6DwlRH7 for ; Sat, 8 Dec 2018 07:55:31 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 95D95130E23 for ; Sat, 8 Dec 2018 07:55:30 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id g189so3029964pgc.5 for ; Sat, 08 Dec 2018 07:55:30 -0800 (PST) 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=bSfDF2WyRVHx5O+9sMpo2PAmOn6NyCKqbj2jE5U8auU=; b=NdYWt5QD1oOjIaiyJYFD40dpbxox42kARp7N/3uZRigl3VfkBKxa7JospzDNjz/kMG foDNsxNcVWpJmJgTzeyqBEZIj3Ch+fnwvr+fEd9RsuWOv1N+LeRQVbQg8/tFyNFLWXfC 47jNO+fLvoYAoNLlhipCl84k0xKT8AlSL5V502P/tDrgZpvql3cf58KK1bJYa6nj67MC GxjmYPx9g/aJc4eNQPW7a19dWd/1B2G37LjqwvxNeTbs2HfY9FsdN5sIpQPKUDYhJz1Y UDIXQNyxrAs19S1eJpPhv1g0G3xKOfmeM9JIf95x8ha6pIHWljFH80IG+Er5zvQhUmQM vEvA== 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=bSfDF2WyRVHx5O+9sMpo2PAmOn6NyCKqbj2jE5U8auU=; b=p2eNnnNm/XJrZp35N5eP6GPklirpQJXtDj37EUDEyzwHa7NXscWsJ/GpT2RtOYwN9n ZuSYkbmfHgRNAfcy0HHAjXlOY5zJD0VALDRzX+qgtrw9vGVhxyGrkkWxgMorpsYqk/+X Lvwwd7j58MC9D3GmfteJwSohxGMtE9bywJhpRbOih7PQ/nkGxLEHc0YNykacgjIlFIBm T06YZxZPcmeXfG5QFVUob1TFYKuLiJ35p9uJVSWxxv+l+BDSJpaxq6ckuCNQZ8upBEPV UneKEZF6lgrLq2grGYs6zbdsHSr8J1GobspbLWIw2WZ7iMhkoRDVX68jPTOaDSuAVZFC qZBQ== X-Gm-Message-State: AA+aEWbTbSzZC4szisdwRub8slimxzaQkQi3uTfGPxmqTWKg5rnDiRCt LnXidYnQqnfHvxuDIr3zA2n3Fm/B X-Google-Smtp-Source: AFSGD/VBHZ8ltYs+6metX4mH+qgCq0hFaUCqxfIYZtfjlDBn8dRUDVDtNCKJPEvyP52SkblDFrvAgQ== X-Received: by 2002:a65:4142:: with SMTP id x2mr5356656pgp.356.1544284529823; Sat, 08 Dec 2018 07:55:29 -0800 (PST) Received: from [172.16.80.121] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id v14sm13651476pgf.3.2018.12.08.07.55.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Dec 2018 07:55:29 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Nov Matake In-Reply-To: <9A3744F9-B3D0-4AB3-95AB-7033A40BD51E@lodderstedt.net> Date: Sun, 9 Dec 2018 00:55:26 +0900 Cc: Vittorio Bertocci , Daniel Fett , IETF oauth WG Content-Transfer-Encoding: quoted-printable Message-Id: <9AD1602D-9825-4970-B4DB-C0EECEF5442D@gmail.com> References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> <115824C4-61C1-4986-A30F-382A1AA563BB@gmail.com> <9A3744F9-B3D0-4AB3-95AB-7033A40BD51E@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 08 Dec 2018 15:55:34 -0000 Hi Torsten, > On Dec 8, 2018, at 22:20, Torsten Lodderstedt = wrote: >=20 > Hi Nov, >=20 >> Am 08.12.2018 um 00:20 schrieb Nov Matake : >>=20 >> For me, it seems very hard to issue TB-bound token for JS app and = MTLS-bound token for its backend server at same time. >=20 > Issuing TB tokens in case of implicit is anyway hard. You need to = issue a HTTP redirect to the RS and the RS must respond by HTTP = redirecting the user agent to the AS (including the referred TBID). This = is a new flow requiring an additional security analysis. Obviously, the = RS would see the state value and could modify the request. And the RS = endpoint must be protected against open redirection.=20 I understood. But even using code flow, issuing TB-bound access token has same = difficulty, doesn't it? I don=E2=80=99t think this issue is relate to implicit flow. >> Do someone has workable recommendation for such case? >=20 > Why do you need to issue access tokens to both parties, the frontend = and the backend? I would assume a clear layering would either let the = SPA or the backend perform the calls towards Resource EP. My client wanted to access Facebook API both from SPA (for realtime use = case) and its backend (for batch processing). This is normal motivation for developers using = "response_type=3Dcode+token" today. Using backend server as the API gateway for all API calls causes = performance issue. > kind regards, > Torsten.=20 >=20 From nobody Sat Dec 8 09:50:37 2018 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 EC6E2130E59 for ; Sat, 8 Dec 2018 09:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode.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 7reusSC1_W1D for ; Sat, 8 Dec 2018 09:50:34 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 7CA3E130E4D for ; Sat, 8 Dec 2018 09:50:34 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id y1so3274151plp.9 for ; Sat, 08 Dec 2018 09:50:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Yd3B8x9yhOllRP5D9POqiYib3Ix7J8bsKiIbH4W+pR0=; b=OfCtx/5hOZTyMPAkm86QQGYPuG+gW0UMFyHKxWb4AQ+xOeyQRv8i7ItKSOAc2qNXqE MCut0QrcFZL9fKvUcICuGddgy87DFTaHdr3hr/4Zf61jsFiY3KMdau/4+wDp/1PObg+2 2uhYkCGaGwrDkC9jUmUbcqOnXGdm+ILpSsm5XzUt1J65bQA1MEMvpWa3LBlE3xqSbI6q nL5PfkEZZVyPnj70i35pby+5Yq1BbxzGd6ets09Jy5SmPTJdyL/qUi9MzfkP6a2/Mig/ bqpuW7vDRDx7PVu1+4uzOcxX6YVHnSO0RHxxh/sbNb3jIhWbLbRMXpMmfax5nAAn6ttk 1Ulg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=Yd3B8x9yhOllRP5D9POqiYib3Ix7J8bsKiIbH4W+pR0=; b=Oz5Ht6xZs9FjGvMZe77jxWNDq6h6xCi8Qxe+bVLf0hbupSWOl2WyFh4d/mUCPdYs5M 6zJa7Qbc6XwI1xvcG8vAhZcXBbETW5UU+UZUiqbX54bb/08g38iC5WWsipf4Mi+EZc1W OYOQfABIDbKAm2fBrNABxh7Aj7DvfsrmUq79vyS36PL+bn4gwjQrIpPRLm2WQYe9ZXfA 5e/da+5afW+tKaf1GvkQtpfPSHl1i+5yKcPPZVMW1cGod3ZUOH7rf8UxGotc9f7QFvkO r19n+hwUY7zDL02pmRVYjtd9Xz10Eu70BLtGCuWYjriQFi3ZB4olTSxeeNVHN2i8gChu ofOg== X-Gm-Message-State: AA+aEWa60H7zvCWwRdKrOXZFNJnfuOZ/wqOGOZfuLbGbYtrFpV3+Jmas 3tOyoH2CrytIlmoC9Bn6B2dI3lA37Mo= X-Google-Smtp-Source: AFSGD/Wp97fttLY0E8O7+bhrOfCkxMEXQcutCItUPTDQj1Npk6kddMSRvvZx4bm5wRafLf8abp537g== X-Received: by 2002:a17:902:1102:: with SMTP id d2mr6418832pla.138.1544291432737; Sat, 08 Dec 2018 09:50:32 -0800 (PST) Received: from heembo.local (zipline.atenlabs.com. [206.251.244.230]) by smtp.googlemail.com with ESMTPSA id z62sm9893998pfl.33.2018.12.08.09.50.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Dec 2018 09:50:31 -0800 (PST) To: David Waite Cc: Vittorio Bertocci , Daniel Fett , IETF oauth WG References: <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> <787EE945-1B6B-4A63-A248-CB60458EDC01@alkaline-solutions.com> From: Jim Manico Openpgp: preference=signencrypt Autocrypt: addr=jim@manicode.com; prefer-encrypt=mutual; keydata= xsFNBFcMHBYBEADN65JL/EhBkLog2kXXIvM90vyMfDgHWK0qP5lKaMWJdrZ/0AKJnGzOGWFg 8ezOlLp7yJQO/QBm+XDq6yda3uSNg3EugBjnPa24fcsb0fuEmoG0xq1TiF3G8byBxdr7TQqn 9xLUvkivl7XUfpeoKiHXpAwahLJiJsT3Y8oc32qF7IPiQLvqZBNNTesK+cz+MLm5UZxI5ZtH 1bfiyht+5eFrWIOQKFu7EEapRtBScY561xj7WKsLmj0F6cK/vG9CNss8lBsBgpBUXD1aE+Iy BJb98cZwbebfJA/AMg4W/HTcQSxfael8GfbOFidxT5uu45o/X6kjfa3ITU5YKM2EYaDZHiMo Qoojny83O7PrIJaB7JoIRD1h6Jtq0WjtSv08YO8r+d8QmEQ9gMt8oON7YYP69OsK+lBU+mKZ C5OfTW7GEW3egHqd7UtfzU/Sadp8MXr54/U3Elg0/E/da/OoxYyvoBInJVcR8QlfcA1JEr+R YFutoISigv6qSFHBssvaRK93W+R3TdHcJZUu33lk65FKnbbdcPmKWWXk1ZWBcaXZ2Rwa+NyR RCCVw2Sy/jVPCNvTtZuI9oeNXxgKfF2o5pVH3J/P7viKXFQafE9zLJC9Y2E5gP/FfHkFNaem X/RCggxQFtABhhOmHnho4tPeu55Jv0pd8d4xW4YlaeZb15wzGwARAQABzR1KaW0gTWFuaWNv IDxqaW1AbWFuaWNvZGUuY29tPsLBfQQTAQoAJwUCVwwcFgIbIwUJCWYBgAULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAAKCRBMeWW7x/Jmpp2VD/9lhjkr35vO7ZYRvTRnUeF/eDgfCYcRO1MD X0UNjX0rp02MB8BOqlFDiwUR9B3Mzh54GGHUsuUcmClTHm19SSGKvp8m8N68Uo47tc1BV7R9 6sINqgAr6LmIzCjhfABL4WhvpFu4i6eCcx/9kThWuX86IOAdXFiwvaUkYVr8krEDHyQaUn2j 9CbYqnXm6Ig9stJo9mrzB9lOKAxFTDuV7dMcV3zYTZ8T8AqwwRzoWFAT30n8/pU+rYyRmA6w B54LRCcsv7JxkVowmuXcsOZs5hw/qLN6Q1X5LJRAhYCjl+juX1FbiSNV4j3cEiEMKhOjtSVG iwgKHs94yfR9Y6zVcSVhYgUGb6luGLaZo3LbOEB3vinS+VU0yLM7EWDz41CAdPuiue/L4/+n ZnNEdOgSaLB1e9nX5AjbHIb7MYzYH359MwhXJv1uyY5PTg2CWPfJjtoh5R75NjjruZn3XZ1q 9PYVsmw4BiWia+0y7WBqR5UYPUHvqiMoqPxIYSFwECxuXlDDQvqYlaWBMDObxXTFbrHtg4I/ eDsMDWJtj1H/zDaD67DjoRLrZ/iL1eqWAweFXiaPg+q3071W1IxAeYrMoyDM0m5ZYUrwWubT U/T04VV/fJ+1r1Neu+hPEvquH9AguPHn2qYM/nnD8u7TLXd6q6gFQnfpBbsDPPWiqaGEW80m ys7BTQRXDBwWARAAnVe6i3g1q8YnoHsUwmF8XqkIntMJzRSLORr/bkNQ8Z8ajq6wgXcLQlVk cha5Acn/FKhcd8dyForbQvURlrnOrw3h8gna8Jq3muqIMfa6H/F889CPVkx7vW5rGUB7NsmH toSx7TH1IQPUfq99y0cwKGfWttdKBiUG5D7gpKtH3B78hz78+wSK3SUR4KEPdYXSzVqFlnOY McPwoY0jC2q991k4rSZeSEN7iXYhoUqzpMyeMItGhDskmE/0lYiB/ZlBUmq7LP7khQ1fJUf+ BeDyCBHNrK/kYi/ur597cyd92KuIUeDkuNIB/ZxVIZ24f9MTw5JHLcyk6IMzpgdw2NFfxzTL htoHtNhlzLkFAEfWu1OSjlZGh2YfybUt4cxp7ntV5tNRR/MDKrHSABbR4seX5L68KA/74osM LNK7KbpFAViZghoMFB/USzNrog8OBuktczdTYthi/U/UiE8n/sJ7IQ0WFuF2srfAlNrUdPnW QeJhVhKutyajTXai9M+RJ49p30fRhEpcWlvS1Rd7GXTJrLnEiL4u0E9Q5UA/khq2TwXZ4M6C 7KutaBBqz12dc/ENrJv0o6MI9srq14HmE2qqO46/PFJFWKSHWyousaMbKpmB8qPTP2S+swm+ xpk20Ck3Bco5sW8rv+Fza0i3+gXgTeMZ79gRMiWKxpQGaqvUsjkAEQEAAcLBZQQYAQoADwUC VwwcFgIbDAUJCWYBgAAKCRBMeWW7x/JmpgrrEADJ0BEmJX286qV/tT6WBoxffmOJm8ThrxVb NMrNjkQrEX2GiQTcZ93NTX39k7jctG6UFbvIAjhMm3lymAppXIXu66hA2sgnlNwYJkpj6xLj LhkK9rLNFDjWeBeqm4yfsnrST0CoO3j/1KkMSRuLnkFBGLiLjoijfRLudcR+wmRI5Nj0MWD0 3ejNEFyiMn34di3ULHvYdAjPdyIqvUjj9MPuRFz+rYEeBPoAMKsDdl5mQ/3UHGHzxNTTgN8B P1ansWK2oSB0bIBdjB13lUeBYctGUuH89c+3OzuBIwnvGc/J7aYwnLxr/qgPB6bvUltJ8FUz S6nSoFFNr+NIayVCrE3jzgsfyZxQZznX2Faa8dogIcOl5LiosgjUZG1T+7Zt8taaMBBeT6NZ hP/mmd5Oep/5kl+MihTdfj5w9evMItGIfIXr7OUDnO/zOPxL7e8CpZkR95j9Gjy7PrV5ahqK EAKb0rNV3k1XI1OJNefnfZRDMH/oGfhiGmT6KW/43lF18wfIH0u6ysALKGGOC+XCu4/k0xsJ MAdIvVGKXirAoA98RvSlstqMAPj7j7xX3/JWMQ5ynlpaecWtahzscLSut9IxhTIFWpstTGrH TI6CzZ3akG7EQJAN0OxhrA6iGfhL1bNoQZ7HvTf8yYZQSQBaFBqJvwqXFMyfV9QhhXiIQO9H Bw== Message-ID: <2e78c26e-2ed9-400f-9e36-4ffce6035332@manicode.com> Date: Sat, 8 Dec 2018 12:50:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <787EE945-1B6B-4A63-A248-CB60458EDC01@alkaline-solutions.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 08 Dec 2018 17:50:36 -0000 >  Is this a matter of saying they should have an API for these clients which exposes less of the risky activities? That cookies provide a defense against XSS exfiltration? And/or other? HTTPOnly cookies prevent exfiltration of session or token data stored in cookies. Those cookies can be REPLAYED via XSS (stored request forgery via XSS) but they indeed cannot be stolen. I also reject serverless SPA architectures that store tokens from a wide variety of services, especially for high risk apps that use complex web UI's. The chance of building such things securely for most teams is painfully low. - Jim On 12/7/18 5:27 PM, David Waite wrote: >> On Dec 7, 2018, at 5:50 AM, Jim Manico wrote: > >> I still encourage developers who are not XSS guru’s to stick to cookie based sessions or stateless artifacts to talk to the back end and keep OAuth tokens only flying intra-server. It’s an unpopular opinion, but even moderately good XSS defense is equally unpopular > Is this a matter of saying they should have an API for these clients which exposes less of the risky activities? That cookies provide a defense against XSS exfiltration? And/or other? > > -DW > > -- Jim Manico Manicode Security https://www.manicode.com From nobody Sat Dec 8 10:23:44 2018 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 AA01D130E69 for ; Sat, 8 Dec 2018 10:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, 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 (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 sfZHX4ak4L1r for ; Sat, 8 Dec 2018 10:23:41 -0800 (PST) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 792F7130E64 for ; Sat, 8 Dec 2018 10:23:41 -0800 (PST) Received: by mail-it1-x129.google.com with SMTP id x124so4246263itd.1 for ; Sat, 08 Dec 2018 10:23:41 -0800 (PST) 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; bh=djlg7tpQk6H8PCg0mEZiCVKDmQeME0gZ0R9PXOR1cSI=; b=nrYf+vzIMNapXC5JMXv+7bvop5oABTg2iQXHvvnXLM42/SEOxJPUszLo1QqWkFxIPc /0Y4RmHqQviYkSzpHmshIVHwGkVg6hDA5c1G4PaqkxQWvNg9cdM7g8/fe5kzcNymbszU s3luRAXSjjY88IwocddSE5e8oviCtZPCqg8dEAO05ZeSLRkDlRxITC1XP0HnzobvDW4f RWlV8t9/tQHYhxpPpW9/+iZa1MN8gkqBDHKChp/cfOfw+s9KJskNYHsGIUL1me2lMGv+ ohI3PxkTfaL8XQqBEGvuEKGlNYKy6ywcB/WRw60S9KcuZrcjHpYUD8tpg9gXNiLbKiLj vO/g== 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=djlg7tpQk6H8PCg0mEZiCVKDmQeME0gZ0R9PXOR1cSI=; b=fcDEAbyixb8h0tvrXG1zudByD8B57DI5kVFprFMo/pHtSKMm+35kt2Aaotrj1xCxZQ 7wq+GR/fQQ2k6vI6TIbCCoFErLLuk9gVe1MXiYCPVeyG5Zak6omR0NX7Cu8QToPd/n38 J5BpX8ctXs166vNEeWe0LTiMRUEyG53sraYZGnUEQu+p17p72q3PxuTaoSwxEDTKXMWh 8L6M/I2TsoKhQhNNvC26SCpTQrNFRscPgBJpDjNW8Dl+DwoWywUuccmv8bj34WH1zHNB aIgjzvWJXu0M2s4xrPUhlG80uBPgnTNH4wuCOYEm8gyvuo9LEi/A714pmYTECNZb0cZ5 gvCg== X-Gm-Message-State: AA+aEWaxwvJwNx8bv5qw9eLLyMpfEt7euetihT4yvbWwH/AGM1+4nF7X ILAzRWNzPZfi4e/hvbFIAVyAjp+JquU= X-Google-Smtp-Source: AFSGD/XzcStB9SjpI6euRHFcjIKjUT1/Ua/XM06vR8xN3fcpW+1ieiwgA5Cmzda/TiOLfPGj5ZEKcw== X-Received: by 2002:a24:3dd5:: with SMTP id n204mr6583074itn.104.1544293420530; Sat, 08 Dec 2018 10:23:40 -0800 (PST) Received: from mail-it1-f172.google.com (mail-it1-f172.google.com. [209.85.166.172]) by smtp.gmail.com with ESMTPSA id 196sm3524766itu.33.2018.12.08.10.23.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Dec 2018 10:23:39 -0800 (PST) Received: by mail-it1-f172.google.com with SMTP id x19so11806592itl.1 for ; Sat, 08 Dec 2018 10:23:39 -0800 (PST) X-Received: by 2002:a02:8904:: with SMTP id o4mr5958298jaj.35.1544293419402; Sat, 08 Dec 2018 10:23:39 -0800 (PST) MIME-Version: 1.0 References: <6d88c55a-a300-47ff-af77-8fdb7dcfbc25@getmailbird.com> In-Reply-To: <6d88c55a-a300-47ff-af77-8fdb7dcfbc25@getmailbird.com> From: Aaron Parecki Date: Sat, 8 Dec 2018 10:23:27 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Brock Allen Cc: OAuth WG Content-Type: multipart/alternative; boundary="000000000000b14f3d057c86d444" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps and response_type/fragment 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, 08 Dec 2018 18:23:44 -0000 --000000000000b14f3d057c86d444 Content-Type: text/plain; charset="UTF-8" What would be the benefit of using this response type? Are you aware of any OAuth (not OIDC) clients that do this today? - Aaron On Sat, Dec 8, 2018 at 7:29 AM Brock Allen wrote: > Should the BCP suggest using OIDC's response_type=fragment as the > mechanism for returning the code from the AS? Or simply suggest using the > fragment component of the redirect_uri for the code, without a > response_type parameter (IOW don't allow it to be dynamic)? > > -Brock > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000b14f3d057c86d444 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What would be the benefit of using this response type= ? Are you aware of any OAuth (not OIDC) clients that do this today?

- Aaron


On Sat, Dec 8, 2018 at 7:29 AM Brock Alle= n <brockallen@gmail.com> = wrote:
Should the BCP suggest using OIDC's response_type= =3Dfragment as the mechanism for returning the code from the AS? Or simply = suggest using the fragment component of the redirect_uri for the code, with= out a response_type parameter (IOW don't allow it to be dynamic)?

-Brock

__________= _____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000b14f3d057c86d444-- From nobody Sat Dec 8 10:33:50 2018 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 78075130E5F for ; Sat, 8 Dec 2018 10:33:48 -0800 (PST) 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_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 Uf_0RTvVij0D for ; Sat, 8 Dec 2018 10:33:46 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 5D7D4130E4D for ; Sat, 8 Dec 2018 10:33:46 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id n32so8142057qte.11 for ; Sat, 08 Dec 2018 10:33:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc:in-reply-to :references:user-agent; bh=C2/ylAwjpVXESskCwSz9pfMKH7NprXlCDpxZS86G9u0=; b=CWeAF3s9FuHH19ZPcHaB42kCEwBQV9d99qwzPujBmfN/8tF4qX2rXi4srbCvo85kv/ tG0cxaextTu9v/Y++T+vtkSfeCjnpL2iiXBJrp74zGcEdI0SDQuFhY56CpKJWCiZsaLw oM6SQm1cQhC3BwpVv4kSViomWCJ6Hxvu8VWuoGQ2zYqyA5cl3PKrsWH7crK5yOz4QnJ1 Qmo2Oe2pgwdDioIlHkhkQOPLRqGFoDo9/U8Ry5JipdJuzHxeDNlwb/ekhlHV5e60Zp81 VbNSaT851GU1HGyhOAxHBRS94SJgGIr5DgfhumCYiKZ9LkPtgA14TqK3IzSN6n2cOePR sp0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :in-reply-to:references:user-agent; bh=C2/ylAwjpVXESskCwSz9pfMKH7NprXlCDpxZS86G9u0=; b=WLHDSmQKKee9gxVIu76l3oHcZXrmPhREmf8Jhc8452exB9Ss2OWZ5x16Ed0q/JnB2H 80HHm6KvRyja9xzek6iZgRPSsjusNjfX1n9RN06VVfAMwxI0lAo5FZzf0zXONpAIt6+G y0nYPM/YkpBkI4qCi5yuF9jj1idRP+9tr73gK0G9FNaDaQr0tsn1BvlRAdghW0gPjAMl hHcY3ujDyboEn3+ttvf2Mlf7dYi+veOJn972meViqZTbiXyWZMphIJc9NW7dT7JKQqtN 3bSPx72hf2ribaY0e5MiFJCVDpHoISeCXem9mglLGiMJ/7q7lXYExwBp3VxNAAGq7ymN OYvQ== X-Gm-Message-State: AA+aEWaBMsZiiChp91/rIEX/n113jvGYInIpBg4STHNPLrxlK3kDfiXk qaJu9ozMg+m9qEYc1FdTYDIF9HXX X-Google-Smtp-Source: AFSGD/WovxDN6HZCROWa9l2E6mXF6QAE9OKC6wQfJwRYdP9Uaz+F/pRduCbdiFFth1o2CL9FoMOHPw== X-Received: by 2002:a0c:e84f:: with SMTP id l15mr6088381qvo.124.1544294025495; Sat, 08 Dec 2018 10:33:45 -0800 (PST) Received: from [10.0.1.3] (pool-96-253-25-169.prvdri.fios.verizon.net. [96.253.25.169]) by smtp.gmail.com with ESMTPSA id u16sm5253781qkg.14.2018.12.08.10.33.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Dec 2018 10:33:45 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_38525236.797379696134" MIME-Version: 1.0 Date: Sat, 08 Dec 2018 13:33:42 -0500 Message-ID: From: "Brock Allen" To: "Aaron Parecki" Cc: "" In-Reply-To: References: <6d88c55a-a300-47ff-af77-8fdb7dcfbc25@getmailbird.com> User-Agent: Mailbird/2.5.24.0 X-Mailbird-ID: c33d0aef-bc34-4daa-8bc9-8252780f4e69@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps and response_type/fragment 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, 08 Dec 2018 18:33:49 -0000 ------=_NextPart_38525236.797379696134 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable For the same reason the implicit flow uses it -- to reduce exposure of the = response params. I know the code=C2=A0is protected with the code_verifier, = but it wouldn't hurt to reduce its exposure, no? -Brock On 12/8/2018 1:23:41 PM, Aaron Parecki wrote: What would be the benefit of using this response type? Are you aware of any= OAuth (not OIDC) clients that do this today? - Aaron On Sat, Dec 8, 2018 at 7:29 AM Brock Allen wrote: Should the BCP suggest using OIDC's response_type=3Dfragment as the mechani= sm for returning the code from the AS? Or simply suggest using the fragment= component of the redirect_uri for the code, without a response_type parame= ter (IOW don't allow it to be dynamic)? -Brock _______________________________________________ OAuth mailing list OAuth@ietf.org [mailto:OAuth@ietf.org] https://www.ietf.org/mailman/listinfo/oauth [https://www.ietf.org/mailman/l= istinfo/oauth] ------=_NextPart_38525236.797379696134 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A For the s= ame reason the implicit flow uses it -- to reduce exposure of the response = params. I know the code is protected with the code_verifier, but it wouldn't hurt to reduce its = exposure, no?

-Brock

= =0A

O= n 12/8/2018 1:23:41 PM, Aaron Parecki <aaron@parecki.com> wrote:

<= div style=3D"font-family:Arial,Helvetica,sans-serif">
= What would be the benefit of using this response type? Are you aware of any= OAuth (not OIDC) clients that do this today?

<= div>- Aaron


On Sat, Dec 8, 2018 at 7:29 AM Brock Allen <brockallen@gmail.com> wrote:
Should the BCP suggest using OIDC's response_type=3Dfragment as the mechan= ism for returning the code from the AS? Or simply suggest using the fragmen= t component of the redirect_uri for the code, without a response_type param= eter (IOW don't allow it to be dynamic)?

-Bro= ck

_______________________________________= ________
=0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps://www.iet= f.org/mailman/listinfo/oauth
=0A
=0A=0A =0A = ------=_NextPart_38525236.797379696134-- From nobody Sat Dec 8 10:58:10 2018 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 88705130E5F for ; Sat, 8 Dec 2018 10:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, 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 (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 lWj1PPL2cfIo for ; Sat, 8 Dec 2018 10:58:06 -0800 (PST) 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 00E2D130E2F for ; Sat, 8 Dec 2018 10:58:05 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id r9so5905598ioa.1 for ; Sat, 08 Dec 2018 10:58:05 -0800 (PST) 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; bh=T7Hjcl9/zfXEHJKqI9PhxWH7CBbw900rb+BER5PwRUE=; b=VgqbnjnObkdvAqrvDhLZFlb+525gbmn8Rifl4QiHNAc8xzsPMraUcYsWOGVARfWLcX 2U+gVmViCBetJJ8oVUupvq4XLpEBNXrAHOkgPExx0y08trzxdlO1Gt0tmNvxjvSSVkpC np65BBs868QRgsaYu0CWzsCFH8QfGxT/BiUq8Wn0V7t/JRkTk278MnwsVJgeaGhPdTLa CcdH4tlOYg1W+iB2TWA42mgAi0aIHv1EF++6vdU/FHO91oFB4WUlj/314XDRB+oH8jpK 0pr66vOmEIj7/6D2npM2RM4xHUdyd90VmHav4vsa9LemjYd5KD280k2A1TujP0Gtts9V qY5w== 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=T7Hjcl9/zfXEHJKqI9PhxWH7CBbw900rb+BER5PwRUE=; b=poZFd5eZrQKcJ0Sr8zEACLa3WFARGfPZCTnK/1/4SDN4qIaWwTcar4C0dTC2YkTYpc 28xxmU2XofwPvsJGccNRLGbdM40rS0jUA0KXXvAOgT4AiFzBNXBJsdm4c68zEcmw7LfL K8zWmnA5NGff20r6BT3+LFwMXYZjL0FOg64tKczqNNxazXgwq0Tjt4QM1PZyKxlOfRa+ VflfK8liHlFpAOjTRAdC/mDUoEFwC1C++dqxkc9ZkM0iAHPyodRNru2l0wMzROeJSisJ pkhNUv2nZRio8nTrw9JatC6DiryWZ6wElMI3fgexgdj2Yt7Jub04c6lIt+KXRN9aT0K9 rWOQ== X-Gm-Message-State: AA+aEWa46VJS+fh9abHryxiAL+OSKtvsHl+qNQRJIOzpw8CV/6cMBuRL VneLkci+FAuVonyIDG68VmtWo/HAoMo= X-Google-Smtp-Source: AFSGD/X54ia6LPGuRbsj1CAOdIGvNjNRD7T+MnLNF0m70ScqK37vGaAPU2Bdq7x3PyCOzXYxBBHTxQ== X-Received: by 2002:a5d:8d85:: with SMTP id b5mr5916576ioj.38.1544295485089; Sat, 08 Dec 2018 10:58:05 -0800 (PST) Received: from mail-it1-f174.google.com (mail-it1-f174.google.com. [209.85.166.174]) by smtp.gmail.com with ESMTPSA id j129sm3351465itb.41.2018.12.08.10.58.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Dec 2018 10:58:03 -0800 (PST) Received: by mail-it1-f174.google.com with SMTP id c9so12089322itj.1 for ; Sat, 08 Dec 2018 10:58:03 -0800 (PST) X-Received: by 2002:a24:2d0b:: with SMTP id x11mr6595983itx.85.1544295483185; Sat, 08 Dec 2018 10:58:03 -0800 (PST) MIME-Version: 1.0 References: <6d88c55a-a300-47ff-af77-8fdb7dcfbc25@getmailbird.com> In-Reply-To: From: Aaron Parecki Date: Sat, 8 Dec 2018 10:57:52 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Brock Allen Cc: OAuth WG Content-Type: multipart/alternative; boundary="000000000000b420be057c874f8b" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps and response_type/fragment 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, 08 Dec 2018 18:58:10 -0000 --000000000000b420be057c874f8b Content-Type: text/plain; charset="UTF-8" Do you know of anyone currently doing this today in an OAuth-only application? If the group wanted to take some existing OIDC mechanisms and apply them to OAuth, I feel like that needs to happen in a separate RFC, and that's a much bigger discussion. This BCP shouldn't really be defining new behavior. It's similar to how "OAuth 2.0 for Mobile and Native Apps" is not where PKCE is defined, PKCE has its own RFC. - Aaron On Sat, Dec 8, 2018 at 10:33 AM Brock Allen wrote: > For the same reason the implicit flow uses it -- to reduce exposure of the > response params. I know the code is protected with the code_verifier, but > it wouldn't hurt to reduce its exposure, no? > > -Brock > > On 12/8/2018 1:23:41 PM, Aaron Parecki wrote: > What would be the benefit of using this response type? Are you aware of > any OAuth (not OIDC) clients that do this today? > > - Aaron > > > On Sat, Dec 8, 2018 at 7:29 AM Brock Allen wrote: > >> Should the BCP suggest using OIDC's response_type=fragment as the >> mechanism for returning the code from the AS? Or simply suggest using the >> fragment component of the redirect_uri for the code, without a >> response_type parameter (IOW don't allow it to be dynamic)? >> >> -Brock >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --000000000000b420be057c874f8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Do you know of anyone currently doing this today in an OAu= th-only application?

If the gr= oup wanted to take some existing OIDC mechanisms and apply them to OAuth, I= feel like that needs to happen in a separate RFC, and that's a much bi= gger discussion. This BCP shouldn't really be defining new behavior. It= 's similar to how "OAuth 2.0 for Mobile and Native Apps" is n= ot where PKCE is defined, PKCE has its own RFC.

- = Aaron



On Sat, Dec 8, 2018 at 10:33 AM Brock Allen <brockallen@gmail.com> wrote:
=20 =20 =20 =20 =20 For the same reason the implicit fl= ow uses it -- to reduce exposure of the response params. I know the code=C2= =A0is protected with the cod= e_verifier, but it wouldn't hurt to reduce its exposure, no?

-Brock

On 12/8/= 2018 1:23:41 PM, Aaron Parecki <aaron@parecki.com> wrote:

What would be the benef= it of using this response type? Are you aware of any OAuth (not OIDC) clien= ts that do this today?

- Aaron


On Sat, Dec 8, 2018 at 7:29 AM Brock Allen <brockallen@gmail.com> wrote:<= br>
Should the BCP suggest using OIDC's re= sponse_type=3Dfragment as the mechanism for returning the code from the AS?= Or simply suggest using the fragment component of the redirect_uri for the= code, without a response_type parameter (IOW don't allow it to be dyna= mic)?

-Brock
<= br>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=20
--000000000000b420be057c874f8b-- From nobody Sat Dec 8 13:30:04 2018 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 08DE2130F03 for ; Sat, 8 Dec 2018 13:30:03 -0800 (PST) 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=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 WBPlQcAhg007 for ; Sat, 8 Dec 2018 13:29:59 -0800 (PST) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.109]) (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 63857130EFF for ; Sat, 8 Dec 2018 13:29:59 -0800 (PST) Received: from [80.187.103.135] (helo=[10.160.250.168]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gVkAb-0005QI-62; Sat, 08 Dec 2018 22:29:53 +0100 Content-Type: multipart/signed; boundary=Apple-Mail-AED80353-CF0A-4A29-880D-A5B802DB3C4B; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (16B92) In-Reply-To: <9AD1602D-9825-4970-B4DB-C0EECEF5442D@gmail.com> Date: Sat, 8 Dec 2018 22:29:51 +0100 Cc: Vittorio Bertocci , Daniel Fett , IETF oauth WG , bcampbell@pingidentity.com Content-Transfer-Encoding: 7bit Message-Id: References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> <115824C4-61C1-4986-A30F-382A1AA563BB@gmail.com> <9A3744F9-B3D0-4AB3-95AB-7033A40BD51E@lodderstedt.net> <9AD1602D-9825-4970-B4DB-C0EECEF5442D@gmail.com> To: Nov Matake X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 08 Dec 2018 21:30:03 -0000 --Apple-Mail-AED80353-CF0A-4A29-880D-A5B802DB3C4B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 08.12.2018 um 16:55 schrieb Nov Matake : >=20 > But even using code flow, issuing TB-bound access token has same difficult= y, doesn't it? > I don=E2=80=99t think this issue is relate to implicit flow. Determining the referred token binding id and proving ownership of the key i= sn=E2=80=99t easy. Brian is the expert on that topic.= --Apple-Mail-AED80353-CF0A-4A29-880D-A5B802DB3C4B Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCocw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIFRTCCBC2gAwIBAgIQM9uaxqrCN5lrc/ED e5nwtDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE3MDEwOTAwMDAwMFoXDTE4MDEwOTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYX dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCu wZLNnLP0ur1JFb1K97kryfmVaGmU4ITocfeAzJ7XYOM6mQUVm3Rvve3bsbXteynpZTEeE169/tyT QBSm9hQ8IcGpUYlIhYX2FYChIUKBAAI6iH9wMVvPPU+wxjwSXs6Yi6zgle1jj9V2hIiEU/eHMBNs 0CDfYqn43y+1O4pPBuCeLMlLLNlNiuy22fcubBjXsdT5T29eWgy6zlT+WfgANnHTPLINKwDqC0/F dgmluBJOcdyRVnnN9HzSC4hnnfxjaqqyq3lVpJFJHahDMT8cROQpz+h09WGoGtcvK+dIWQI+sBdX Tuty/CQ+8dl5hW7hB1VbI7YchDiLbH2vmbtLAgMBAAGjggH1MIIB8TAfBgNVHSMEGDAWgBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU+eAeBXE5nsZKOL8hbhgkwGPTY8cwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy ZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCIGA1UdEQQbMBmB F3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IBAQACa57IeOLIvWpiB976 FVKwa4qWBy+MIB8bwlqrjy0LQiM/ykf+0aLi4v0IdV8udXeksOeODoza6+kQGntytllydI8t5Wyz 62SHC/4XshJhDJPh+U2SpVRvyd97BsI9wg3Xc5t+lTuuVeghqsQSmVCjhK7KZhWW5DFMs4UqblA4 wXgkEzD+uPLi33knsx2n00VTNCso8kNonYmv9NxNcVyMu81WYwGMrT3n1r2/X/WaJEd3UMGxOHUq 8GKAQ5Q0zG9Pm5S0Hr+2KgNmoEMOTwa92ej/GbJ7diJqxLsmAxESrlZxeqlYa7mQwVkwY8S/I8d4 Fl6rHHdqZ/giZWdnpa+DMYID0DCCA8wCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMjA4MjEyOTUyWjAvBgkqhkiG 9w0BCQQxIgQg52dacYkMIPy6ksmVChTKPHVMDD54PITjKKisu7zQy7YwgcEGCSsGAQQBgjcQBDGB szCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3 mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAESI KCAo2jfkQ6tNgKXKR2nhWdW+lRFUJrqYXFTsRn9aslv9mPa7hPiRStABdhhjcMaZVfeBRL45BOEt Zz6N6w0my/HO4fOgidQSB7UZouWHSEdRd+gQfEYeOWpI3zC2EG9iSKZyKO2IMHfrVL17klspw8SS h//QR/z1XOxp+xh+Qe2seDBcJ0Ox5doxLhqYG9Lig6Rg1XEtE5NVFs7zosIJZVASkc5xdKwGtPt8 JJ1W+a/jBYVr4rkzG1s+bkcY7FmNAHL8x9Ku/tnLOEubT04Y+KQ0SXlHPVef/RmDtJDcZo5DZuo/ 2UYD0bat18RJR8iHcQ2jxeM+ibxViYjLt8kAAAAAAAA= --Apple-Mail-AED80353-CF0A-4A29-880D-A5B802DB3C4B-- From nobody Sat Dec 8 13:49:19 2018 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 A590C130F0E for ; Sat, 8 Dec 2018 13:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, 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 (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 TURJon-xBTrj for ; Sat, 8 Dec 2018 13:49:13 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 B4D85130F1D for ; Sat, 8 Dec 2018 13:49:13 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id x124so4521535itd.1 for ; Sat, 08 Dec 2018 13:49:13 -0800 (PST) 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=rXNaWesS5ip30Wk2RuWDk8zZ6FBal4jvQPsWR5D0WQM=; b=wG0XJMkQtdySYnezmMls5SdvNdsCKdWewvmEV0dIGz9qk18RfESoL6+qVLvFZ7SyM5 fzmv9cU+A4aqMTDk7Y8XmoYiCwJNKohRUMZQW7Pc9XqzLk8LT247aqh27Ih7cRCQL2jh cLBn2+xq6O+qx1WWcUwYbdYJkn2e0/JhyUCkJ+gFwXhhbbM+HgBnDyy5Qt05FykLfQuW gEzDzq+LH8sfWUxoXm2RPzbP2fpAYupT+hB7guigzDHARLxhdYQXPcvKltpyz+OhyJ4y SaG9G9+U3jcifOWYkr3Tk37Ox02A76oWvOyTdrsXgfPNmLSQ9FeX41Y8HvRMLizFtLt3 azOA== 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=rXNaWesS5ip30Wk2RuWDk8zZ6FBal4jvQPsWR5D0WQM=; b=VQ7zr2Q7HI0ze1atPZt6Yt0dgCHAIi7elp6t/V2+9isn5udVWUu6lwpx8//o7gANiw EEAjpqt7HA+dxDo+yuTMVLb65rRwSPJzfnickuHjDqiUtgoqi/RhYQlDFt4TPTjzcl+B 49E/jh3AOdNzbefmes3FoUJtGYd1OObmpX/tn+bNHv7VOR2fQuuZju9KmTAGvSgfyCxQ DrmRs7yiZlaTLl0y3qg8QiSCV4roIEE2svAI/gGB+HECEyizNCUq1yNBwl4p4OkYcJjq PeJwvoNC9Ml/qzb5wHkzxlBgXnJLrZ+ywZ9won9zK+zuw2DisPzCp7U7trlRgUOD/LrC +G8Q== X-Gm-Message-State: AA+aEWZ6g1WqZT40BEnQlnflqiAW4ymOXHBaa3YD5uplPyTVQJcyapaS l5XNhIE0AvxD6q5krWAYd2g2QV8KPNY= X-Google-Smtp-Source: AFSGD/V8Kdvd6xTmxAGbGMPLw7DoLUwT7vzxG9TZB+1HqjQieMPTIBSiXWjc0EfK9T71m1VEwX3wIA== X-Received: by 2002:a24:1c86:: with SMTP id c128mr6423396itc.58.1544305752636; Sat, 08 Dec 2018 13:49:12 -0800 (PST) Received: from mail-it1-f177.google.com (mail-it1-f177.google.com. [209.85.166.177]) by smtp.gmail.com with ESMTPSA id z10sm3267021ioh.20.2018.12.08.13.49.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Dec 2018 13:49:11 -0800 (PST) Received: by mail-it1-f177.google.com with SMTP id p197so12453655itp.0 for ; Sat, 08 Dec 2018 13:49:11 -0800 (PST) X-Received: by 2002:a05:660c:452:: with SMTP id d18mr6360998itl.124.1544305751363; Sat, 08 Dec 2018 13:49:11 -0800 (PST) MIME-Version: 1.0 From: Aaron Parecki Date: Sat, 8 Dec 2018 13:48:59 -0800 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="000000000000bc1584057c89b301" Archived-At: Subject: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-02 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, 08 Dec 2018 21:49:18 -0000 --000000000000bc1584057c89b301 Content-Type: text/plain; charset="UTF-8" Thanks again everyone for the additional feedback on -01. I've incorporated the discussion into a new draft which is now published. https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-02 Here's a summary of the changes: * Added a new section with recommendations for refresh tokens, referencing OAuth 2.0 Security Topics * Added some more details on risks of the implicit flow * Added a new section discussing the situation where a browser app has its own server backend * Mention explicitly that clients must verify "state" * Fixed some minor typos * Updated acknowledgments section * Fixed working group name and target status ---- Aaron Parecki aaronparecki.com @aaronpk --000000000000bc1584057c89b301 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks again everyone for the additi= onal feedback on -01. I've incorporated the discussion into a new draft= which is now published.


<= /div>
Here's a summary of the changes:

* A= dded a new section with recommendations for refresh tokens, referencing OAu= th 2.0 Security Topics
* Added some more details on risks of the = implicit flow
* Added a new section discussing the situation wher= e a browser app has its own server backend
* Mention explicitly t= hat clients must verify "state"
* Fixed some minor typo= s
* Updated acknowledgments section
* Fixed working gro= up name and target status

----
Aaron Parecki
@aaronpk

--000000000000bc1584057c89b301-- From nobody Sat Dec 8 14:53:22 2018 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 2E867130F3A for ; Sat, 8 Dec 2018 14:53:20 -0800 (PST) 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_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 h97z2VKpD9yf for ; Sat, 8 Dec 2018 14:53:17 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 9E9A9126CB6 for ; Sat, 8 Dec 2018 14:53:17 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id w12so4560707qkb.9 for ; Sat, 08 Dec 2018 14:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc:in-reply-to :references:user-agent; bh=7/egPH50ov6UzkZDz8nxGTi2AWZ44Uw3Cerj+qntx/E=; b=BNiMf0eY38er8x8UUeiXQscB9bHsFpbNv/TVZxgGTsLq0eNJuoZa71Fl6KXuMpPbI/ v5Kc8qHD0yFxzYCPWBTxR52fAWQC8WrpqYrptJ94tvcNst4jzLySg+JpjZ5OtbIs3go1 3y5pAZQTSSFM5SJOS8HFZsIKRTas67PWCt9FK/UmCrl48QQBqNxsnZd4DLllDdzaY0WV VyhgXDpwRx5Ce11+7/64cDV/zr/JcUeZgdYfv/6SAcIHjFhc1MsZAyyxX6s0I4FGMY4F IF2olkItmRTcno7CJMKfzjwBKWU0PxT+WnK2nQcEZkBgt7DbwTswHPXIWTRcvhlDMjsr YE+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :in-reply-to:references:user-agent; bh=7/egPH50ov6UzkZDz8nxGTi2AWZ44Uw3Cerj+qntx/E=; b=q+OtG/Tmv8eP7TMTDAMQuA4pKspRyIjvEffUOF2PjHXnxZBnd3EAX0FjMPFQz1tSuC vC8IORSWeHgri8eYjAHS7MwgCadLYEg/QxWdYo4L6VfXcrf/emzBuywOtyvJxqvts/wN j1TgRZchMl+w8Yivn1OeC8Wv6AWpyqCYmUF2CBiZin/0T9DXC8gtk6SgkUqXpgMMICqt zLM8MRs4WJzUhWpu94bnTTC+N0jEpwBEH03l0a3N1hXIIM14inq4Rxa4FfAHEbzyo1R7 Hh5YFYMkWnPvd8/miuwjATIRT/tZlDCYYXofbHfk6RJwJu53ATwrZZigkAjCv47uSd5b u+eA== X-Gm-Message-State: AA+aEWaVnV4V4oz5wJSh1EQbH61kl5w6yRIkyGAfER60bGgQ7zT+6IjA LwilPtRwRfBgn+3Sw1UygI7IDfXK X-Google-Smtp-Source: AFSGD/XXn8BZXhMTVjtaYEELKolU6BGigehMpE8BnzeVattFRVUf7rGdxSXzV0r6qzPiFMduipF9rA== X-Received: by 2002:a37:b405:: with SMTP id d5mr6329680qkf.162.1544309596656; Sat, 08 Dec 2018 14:53:16 -0800 (PST) Received: from [10.0.1.3] (pool-96-253-25-169.prvdri.fios.verizon.net. [96.253.25.169]) by smtp.gmail.com with ESMTPSA id 5sm5021285qkv.93.2018.12.08.14.53.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Dec 2018 14:53:16 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_63220475.012849490289" MIME-Version: 1.0 Date: Sat, 08 Dec 2018 17:53:15 -0500 Message-ID: From: "Brock Allen" To: "Aaron Parecki" Cc: "" In-Reply-To: References: <6d88c55a-a300-47ff-af77-8fdb7dcfbc25@getmailbird.com> User-Agent: Mailbird/2.5.24.0 X-Mailbird-ID: d34d9d15-6b50-4b1e-8483-80f0ab709a98@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps and response_type/fragment 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, 08 Dec 2018 22:53:20 -0000 ------=_NextPart_63220475.012849490289 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Not pure OAuth. This only came up as a question while I was implementing co= de flow/pkce for oidc-client-js. I can appreciate not expanding the current OAuth2 behavior in the BCP, so t= hat's fair. I only wanted to mention it in case it had not been considered. Having said that, I think I will implement an optional response_type in my = code flow/pkce to allow fragment, but default to query (as that's the defau= lt for pure code flow). -Brock On 12/8/2018 1:58:05 PM, Aaron Parecki wrote: Do you know of anyone currently doing this today in an OAuth-only applicati= on? If the group wanted to take some existing OIDC mechanisms and apply them to= OAuth, I feel like that needs to happen in a separate RFC, and that's a mu= ch bigger discussion. This BCP shouldn't really be defining new behavior. I= t's similar to how "OAuth 2.0 for Mobile and Native Apps" is not where PKCE= is defined, PKCE has its own RFC. - Aaron On Sat, Dec 8, 2018 at 10:33 AM Brock Allen wrote: For the same reason the implicit flow uses it -- to reduce exposure of the = response params. I know the code=C2=A0is protected with the code_verifier, = but it wouldn't hurt to reduce its exposure, no? -Brock On 12/8/2018 1:23:41 PM, Aaron Parecki wrote: What would be the benefit of using this response type? Are you aware of any= OAuth (not OIDC) clients that do this today? - Aaron On Sat, Dec 8, 2018 at 7:29 AM Brock Allen wrote: Should the BCP suggest using OIDC's response_type=3Dfragment as the mechani= sm for returning the code from the AS? Or simply suggest using the fragment= component of the redirect_uri for the code, without a response_type parame= ter (IOW don't allow it to be dynamic)? -Brock _______________________________________________ OAuth mailing list OAuth@ietf.org [mailto:OAuth@ietf.org] https://www.ietf.org/mailman/listinfo/oauth [https://www.ietf.org/mailman/l= istinfo/oauth] ------=_NextPart_63220475.012849490289 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A Not pure = OAuth. This only came up as a question while I was implementing code flow/p= kce for oidc-client-js.

I can appreciate not expanding t= he current OAuth2 behavior in the BCP, so that's fair. I only wanted to men= tion it in case it had not been considered.

Having= said that, I think I will implement an optional response_type in my code f= low/pkce to allow fragment, but default to query (as that's the default for= pure code flow).

-Brock

=0A =

On 12/8= /2018 1:58:05 PM, Aaron Parecki <aaron@parecki.com> wrote:

Do you know= of anyone currently doing this today in an OAuth-only application?

If the group wanted to take some exis= ting OIDC mechanisms and apply them to OAuth, I feel like that needs to hap= pen in a separate RFC, and that's a much bigger discussion. This BCP should= n't really be defining new behavior. It's similar to how "OAuth 2.0 for Mob= ile and Native Apps" is not where PKCE is defined, PKCE has its own RFC.

- Aaron


On Sat, Dec 8, 2018 at 10:33 = AM Brock Allen <brockallen@gmail= .com> wrote:
=0A = =0A =0A = =0A =0A = =0A For = the same reason the implicit flow uses it -- to reduce exposure of the resp= onse params. I know the code is protected with the code_verifier, but it wouldn't hurt to reduce= its exposure, no?

-Brock
=0A

On 12/8/2018 1:23:41 PM, Aaron Parecki &= lt;aaron@parecki.com= > wrote:

What would be the benefit of using this response type? = Are you aware of any OAuth (not OIDC) clients that do this today?

- Aaron


On Sat, Dec 8, 2018 at = 7:29 AM Brock Allen <brockallen@gmail.com> wrote:
Should the BCP suggest using OIDC's response_type=3Dfragment as the mec= hanism for returning the code from the AS? Or simply suggest using the frag= ment component of the redirect_uri for the code, without a response_type pa= rameter (IOW don't allow it to be dynamic)?

-Brock

________________= _______________________________
=0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/oauth
=0A
=
=0A
=0A =0A =
=0A=0A =0A =
------=_NextPart_63220475.012849490289-- From nobody Sat Dec 8 18:51:45 2018 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 40CC412F1AC for ; Sat, 8 Dec 2018 18:51:43 -0800 (PST) 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=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 oRllsM7kK6LK for ; Sat, 8 Dec 2018 18:51:41 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 3C95C12E7C1 for ; Sat, 8 Dec 2018 18:51:41 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id y16so4713238qki.7 for ; Sat, 08 Dec 2018 18:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc:in-reply-to :references:user-agent; bh=py0jKtokHE+KpzwlH3fhtuW2TJdVXPyeoHr0bj+O6yI=; b=p71Rzuoq7vmPwQ8zqekxWB/CYIJbWNUHPMeE8shTm2Abrim/buYMu33emyymh01oLT tRLUFF2b1fH303D/rLPEgUI9Lj4sDY6MCWspKgxLnI+ctnIbk5xMpLWZRkQ0Ejx2LWMw uJCjKA1IeSjX8/JW+U/TC/0iKq5+VHjGZLMRk4K5ARimvwSNOgxuULid1NqPSZNExgvI 7UCM0OfFKyzAOcVv9Me7SSLs/PjoZK+ea0ULISmM5CE/58BjN97AgCqyoPhbg4gxNF32 X+M0l6i1MGN0a7GXi63P4UovhfPDZu+dbNz7aYPp6wnkrzo868K2MJx+A3ZouZ0ufZaT QeNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :in-reply-to:references:user-agent; bh=py0jKtokHE+KpzwlH3fhtuW2TJdVXPyeoHr0bj+O6yI=; b=W7ev2RpP28Wwme5fYg2DyUa/GeFfFBVoNVEJjto65LBAhMs0nErJX8rMrtIU5ARFzb yHHmOOs4EsrMwA1i8KZRiN/3nTwhBEMddBmOQTDaIPkghjge9rPWMgmhMnRroVOWtpo9 UPkVMo1BdJ10FJ99rgzlKysW6DFTRySN0QJcPuLCMFm0egdJMqPg/mmSunayZ9he5MCT RxIjtWAnGdRVyhx71exkSarkXqtW6r8VxU24rNLTcbBZWaU1PqI2bVRFnNLA/VMsC2v4 dgE0iR5tasCOMOOQRSKJyz1xOlP/r/rMFv6Lnfbe7cVSJ2Vqug7MLHAaCetP6auaCRTi yUww== X-Gm-Message-State: AA+aEWZ+CN3+i7PugHSuUW7C10j9Xe8CtT9MKpB0UqRhqgSxUlwV6hnq s5wDv6sx0PZlPBXdYOHSbsM= X-Google-Smtp-Source: AFSGD/UIvfh2GvIvTGxJlkK6lpFebp7F9xyiQhdMGbG1UTm84Z6lXZ+3MFMwos9di5blztL9cSpvBQ== X-Received: by 2002:a37:b646:: with SMTP id g67mr6817141qkf.326.1544323900358; Sat, 08 Dec 2018 18:51:40 -0800 (PST) Received: from [10.0.1.3] (pool-96-253-25-169.prvdri.fios.verizon.net. [96.253.25.169]) by smtp.gmail.com with ESMTPSA id c48sm5291690qtd.9.2018.12.08.18.51.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Dec 2018 18:51:39 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_65825061.563492151040" MIME-Version: 1.0 Date: Sat, 08 Dec 2018 21:51:37 -0500 Message-ID: From: "Brock Allen" To: "Phil Hunt" , "David Waite" Cc: "" In-Reply-To: <8A2BC516-69AA-4CDB-A31E-5AF59FBA9CF0@oracle.com> References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> <1D4D8636-9C50-4AA0-BF33-3427FCD0E938@oracle.com> <9E0E2FD0-ECE7-4A71-870B-21938B8C267F@alkaline-solutions.com> <8A2BC516-69AA-4CDB-A31E-5AF59FBA9CF0@oracle.com> User-Agent: Mailbird/2.5.24.0 X-Mailbird-ID: d6d4ecf5-39ea-489c-8024-87c760a9ec23@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 09 Dec 2018 02:51:43 -0000 ------=_NextPart_65825061.563492151040 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >=C2=A0How would the token endpoint detect login status of the user? Oddball idea: why not use the cookie? If the assumption is that the RT is b= eing used from a client-side browser-based app, and CORS allows for credent= ials, then perhaps this is a way to bind the RT to the user's browser sessi= on. The spec does say that alternative credentials are allowed at the token= endpoint... Sounds icky, but compared to iframes back to the authorize endpoint? -Brock ------=_NextPart_65825061.563492151040 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A > = ;How would the token endpoint detect login = status of the user?

Oddball idea: why not use the= cookie? If the assumption is that the RT is being used from a client-side = browser-based app, and CORS allows for credentials, then perhaps this is a = way to bind the RT to the user's browser session. The spec does say that al= ternative credentials are allowed at the token endpoint...

Sounds icky, but compared to iframes back to the authorize endpoin= t?

-Brock

=0A = =0A
------=_NextPart_65825061.563492151040-- From nobody Sat Dec 8 19:28:08 2018 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 62D9D12D4E8 for ; Sat, 8 Dec 2018 19:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.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 YIe349mbgnG5 for ; Sat, 8 Dec 2018 19:28:02 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 2EF72124BE5 for ; Sat, 8 Dec 2018 19:28:01 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id v1-v6so6761342ljd.0 for ; Sat, 08 Dec 2018 19:28:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IOgeHz1ur66oNB8uQyv4FWyCt3ouY+rsyUwI+M3wakQ=; b=L2X2kDTqITXAX+gkIlKtZx3rVcrBRAmrjpREtoMNakIQQkfBla9b4hdzoWAKQnx5W6 nhapF+SM7+PetKVP5WSkGT0ZbDU7UWEiznIJBiCDphmoLIaNXPnlnb5MkWRgC+XBB94Y Hozt6WEoHk2XkhKX/VeUAu1+yGySmal/1YblKwJHaJaUrkESYtpVD+32Uox/t4oJXERi Gns0Ipjyg33SRkH1M2+Ep1OV2iprQRVqWxgjsPerVUiykxKlbfcKTzEIvV7cVBkK1bBx PsuVWc6069Pv4D5IgIjiWj9EZhr2HgRQ3No61UsFilbFvhRloz19Ymb9GlVOgxYhttFu mJrA== 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=IOgeHz1ur66oNB8uQyv4FWyCt3ouY+rsyUwI+M3wakQ=; b=UK0nGOCdCL/RH4nCUkUXR1YggharjGIIvt633ZQSoYpurII7mU1mNUTuAGqm5LSB2k EFrHB+rUNDPOm+CoftgutK4xaXcnPhWd3wKK/lQfCwo1I6PCh3x7OiC7NzDxC6f0quE+ BF9oYp2N37QO1ToWrxpkEc2N9V44ujeb7jAjmrtdy4WA7FdnFlMt5weTLlIqOmHoQj5Z YKXBDqNduNoOWpgwvtL+0j6bGwd/nDwGYtGCw38OsBGQNHDLGmW8/z0sJIE+lNghgmEQ WihJ/dcGgudiVN2LYs3HU4qrDml37jQe9+VdgbvmAYQ0ta8NXT2A2bu2W4ufGfD3EPGr 1Y7g== X-Gm-Message-State: AA+aEWaPJJgp69scAXOID2NLVZeKMQk7QB2N4gZreo3+wrMSu4gJQvOZ JVqU+fwe1Kj2B9NXL8dkKTqh3qKWTVWahsZ/1zdYsQ== X-Google-Smtp-Source: AFSGD/UsDf0pA1qD5qo53GbHhsSVoiKhbe0kjMhKmT1V6HyAA4ZSsiPQ+6gUpeatXYl+xEBbqNteL1Zx/H8xtfdn6pM= X-Received: by 2002:a2e:4819:: with SMTP id v25-v6mr4771190lja.2.1544326078973; Sat, 08 Dec 2018 19:27:58 -0800 (PST) MIME-Version: 1.0 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> <1333FFC2-A2F0-479D-8E7C-9ACFEC8E5724@lodderstedt.net> In-Reply-To: <1333FFC2-A2F0-479D-8E7C-9ACFEC8E5724@lodderstedt.net> From: Vittorio Bertocci Date: Sat, 8 Dec 2018 19:27:47 -0800 Message-ID: To: Torsten Lodderstedt Cc: Brian Campbell , Daniel Fett , IETF oauth WG , Tomek Stojecki Content-Type: multipart/alternative; boundary="0000000000005ae058057c8e6f14" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 09 Dec 2018 03:28:07 -0000 --0000000000005ae058057c8e6f14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Torsten. As another meta comment, in general I am not disagreeing with the guidance- I just think that the language we use should make it easier for practitioners to understand what they are supposed to do to put this guidance in concrete terms. That includes better clarifying risks, opening acknowledging when the recommended remedies aren't likely to be viable in the short term (as we do with TB) and emphasizing guidance that can be widely applied today (for example, mentioning both the use of hidden frame+code for token renewals and use of RTs, but highlighting the factors that make the latter hard to use at this time). Also; I apologize for the length. I think we are approaching the point in which using email as collaboration tool might become inadequate. I am happy to hop on a call if that helps. > This requires the respective solutions to support response type code/grant type authorization code (lib & AS), PKCE (lib & AS) and CORS (AS) for public clients. I am not as worried about those, as support for those is already widespread (as they are required for other scenarios). The thing I was focusing in that mail in particular was the features required for making the use (and above all, storing) of RTs in the browser. As discussed, those features aren't widely available hence I feel any guidance to app developers (as opposed to provider) should warn them about it and probably emphasize more the risks associated to it (eg XSS). The scenario I am worried about is people feeling this gives them license to use RTs in the browser even when those mitigations aren't available. > The reality is, most people don=E2=80=99t care about security and most p= ractices I have seen are more on the bad practice end. So what shall we do? Sit on our hands? Again, I am not suggesting inaction. I am only concerned about ensuring that developers reading this have a clear idea of what's directional (where we think the world should go) and what's practical (what is achievable with the mainstream feature set today). Vendors verifying that what is being proposed here can be achieved with their feature set is the first step to distinguish between the two, and help setting the right expectations on how actionable the guidance is today. Those findings won't change what we suggest as directional, but might change expectations on what developers can do today, hence the tone and the language we use. > The measures I propose have been implemented and used in production for years at Deutsche Telekom (consumer services, millions of unique users). I am not saying that those features are not implementable. I am saying that they might not be available for developers. The fact that DT implemented those measures will not help at all the developer maintaining a SPA app that must work with the Google or Microsoft AS because that's the API ecosystem they took a dependency on. Either the new guidance they receive is feasible on those platforms, or they are stranded in no man's land where they can't keep their current approach (ignoring for a second the urgency/why now discussion we had earlier) AND they can't implement the new one because they can't change vendor ecosystem overnight. In practical term, the above for me means prototyping the new guidance and incorporating the finding in the document. To pick on the same example, if we find that most vendors can use code+hidden iframe for token renewal while few support rotating RTs, guidance should clarify that. > I don=E2=80=99t ignore XSS. I want to solve the problems one after the ot= her focussing on OAuth related stuff first. Switching from implicit to code solves leakage and injection in OAuth protocol messages. I don't think the two things are mutually exclusive or need sequencing. We can recommend switching to code without necessarily bringing RTs into the picture. My main point is, if we do bring them in the picture, we should be careful to list the caveats that come with it. > Browser-based clients are just one client categories. Ensuring the confidentiality of tokens is always a very client platform specific matter. I see. Non browser platforms already store refresh tokens locally, I personally spent a good decade dealing with that on multiple OSes and the approach is in use in many of the most used applicaitons on the planet. For Occam razor, in this discussion I am mostly concerned about doing that in the browser as it is a scenario as the guidance has always been to never use RTs in Javascript, hence that's the area where I feel clarification is needed. That doesn't mean that the rest is uninteresting: but again for Occam razor, the existence of keychain on iOS or of DPAPI on Windows does little to mitigate the discussion on XSS. > Can you give a concrete example? To me it feels like you are explaining scenarios where OAuth is used for login. That's one of the scenarios of interest here. We can debate on whether that's proper or not, but the practical consequence is that if I have two (or N) apps that can call APIs via tokens obtained with the implicit flow, eliminating AS the session cookie will prevent them from getting new tokens automatically, without the developer having to write any code for "signout"= . The moment in which apps switch to code and hold on to RTs, the sheer fact that the AS session cookie is gone will NOT stop individual apps from being able to get new access tokens and call API. That would be an unintended consequence of the switch to code, and regardless of whether it's a consequence of people abusing the protocol or not, I think this scenario should be documented and people should be warned against it. > Are you assuming the AS revokes the AT on logout? Otherwise the other app will realize the session termination when it attempts to obtain a new AT in another authorization flow. All the ASes I have worked on try to be as stateless as possible, and won't revoke ASes in logouts. > Revoking the RT on logout is the proper solution for OAuth. Perhaps, but again in my experience with mainstream providers, that doesn't happen. The fact that it would be the correct behavior in theory doesn't change the risk in the wild, and what i am most concerned about is to help developers avoid suffering unintended consequences as we exercise existing products in new ways and those discrepancies come out. >Are those RT=E2=80=99s request for offline_access? Then I would argue this behavior is just fine and inline with the way OAuth is intended to work. This is another excellent example of differences between theory and practice. Products providing AS functionality won't typically make a very crisp subdivision between OAuth2 and OIDC features- it's the same endpoints, solving similar scenarios. For some of the mainstream providers, requesting offline_access is the ONLY way to get a refresh token, no matter whether you are trying to use OAuth2 or OIDC. That means that the offline usage (as opposed to session) is the ONLY semantic attributed to refresh tokens issued by those providers. Once again we can argue about the sins of the product designers who crafted things that way, but our first responsibility, I believe, should be toward the developers and toward helping them to do the right thing in the environment they operate. Not saying we need to give guidance for each vendor (that's the vendor's job) but I do think we need to think through those details and give the proper headsup ("beware: your AS might issue RTs that keep working even when the session originating them is long gone, hence please make sure to keep an eye on the session status (checkSession etc) and to dispose of all the RTs when you detect that the session is gone" or "make sure that, when you request an RT from a SPA, you use whatever switch your vendor requires to have session bound RTs rather than offline_access ones. Your vendor don;t offer that option? See the other sentence"). > You mean discard the RT or revoke it explicitly on the app side? I mean discard the RT on the app side. >The scope offline access exists (although in the OIDC universe). Don=E2=80= =99t you think it could be used for that purpose? See above. For various vendors, offline_access is the only way of requesting a RT hence it can;t be used as a differentiation between offline and session RTs. On Sat, Dec 8, 2018 at 5:12 AM Torsten Lodderstedt wrote: > Hi Vittorio, > > > Am 06.12.2018 um 19:09 schrieb Vittorio Bertocci : > > > > Thank you Torsten. > > I think that a lot of the considerations below need to be tempered with > concrete considerations about the features developers can actually rely o= n > today. > > I agree with identifying the theoretical framework and north star we > want to aspire to, but if we are framing the recommendation here in form = of > practice, we have to ensure it is actionable for developers. I am not > pushing back on ideas, but I just want to make sure that when customers > hear this advice, they are actually in the position to apply it. And if > there are missing pieces, perhaps we should consider this more as guidanc= e > to the vendors that need to provide key enablers for this to become viabl= e, > and recommend it as practice to customers only when that happened. > > I agree. That=E2=80=99s what basically happened with mTLS and Token Bindi= ng. We > realized the need to find a reasonable way to prevent token replay in the > course of our in-depth security analysis. Out of the two options (audienc= e > restriction and sender constrained tokens), we selected sender constraine= d > tokens because they are the most appropriate measure (or just "build for > that purpose" as Dirk Balfanz pointed out at that time). Token Binding > unfortunately lost some traction but mTLS can be used instead and is bein= g > used in the open banking space by all initiatives I=E2=80=99m aware of (U= K OB, > STET, BerlinGroup). So we were right on time. > > I see the same happening with respect to implicit and SPAs now. I think > the baseline is clear: implicit is replaced by code+PKCE, so SPAs need to > be extended to handle PKCE and exchange the code for an access token. Thi= s > step is a huge security improvement since it closes the attack angle of > leakage and injection/replay via the URL. > > This requires the respective solutions to support response type code/gran= t > type authorization code (lib & AS), PKCE (lib & AS) and CORS (AS) for > public clients. > > > I add more details inline below, however I have a meta point to make: > did all the vendors on the list work on proof of concepts to ensure that > the practices recommended here can work with your product, end to end? > > I don't mean just doing a code+PKCE demo in JS, I mean complying with > things like RT rotation and revocation end to end, using released feature= s > that your customers can use today. If you did, it might really help to us= e > them to make those discussions more concrete. If you didn't, then calling > the proposal a practice might be premature. > > I understand your argument and I would be happy to just document best > security practices. The reality is, most people don=E2=80=99t care about = security > and most practices I have seen are more on the bad practice end. So what > shall we do? Sit on our hands? > > In my observation, the SPA OAuth universe to a large extend developed > completely independent of the rest of the OAuth universe. For example, I > saw SPA libraries recommending implicit and the resource owner credential > grant. Wow! What a mixture when combined with XSS! > > I think we can transfer some proven techniques from the general OAuth > world into the SPA OAuth world, e.g. code & PKCE. Add CORS to that and we > have a reasonable baseline for SPAs, which copes with the particular > threats implicit is vulnerable to. One hole closed, great! > > Opening the picture a bit, we must realize token leakage also happens at > resource servers, that's why we included the recommendation for sender > constrained tokens to the BCP (for _all_ kinds of clients!). > > mTLS works well for native and web apps. It won=E2=80=99t work well for S= PA=E2=80=99s > simply because the SPA cannot automatically setup a cert in the browser, = so > it would need an external enrollment process. It will also result in a po= or > UX due to selection dialogs etc. Token binding would be the much better > solution but lacks adoption. > > That=E2=80=99s why I think refresh tokens should be considered at least a= s a means > to limit the impact of access token leakage at RSs. The measures I propos= e > have been implemented and used in production for years at Deutsche Teleko= m > (consumer services, millions of unique users). I also think Oath > implemented RT revocation on logout. But I also realized commercial vendo= rs > and other deployments seem to have less sophisticated implementations in > place. So where does this leave us? Running code exists but more vendors > must support these features. One could also say: What are ideas for some > people is proven practice for others. > > > > > inline: > > > > > > > Regarding protection at rest: what=E2=80=99s the attacker model in th= ose > discussions? XSS? Local attacks on the device? > > The main concern is XSS. You can just google token session storage to > find an onslaught of articles and forum threads on the topic. To pick one > at random, here's the one from Mozilla. > > We can argue on what's worse between XSS and URL leaks, but I don't > think we can ignore the pervasive ongoing debate and perception that use = of > local storage for sensitive data is bad. > > I don=E2=80=99t ignore XSS. I want to solve the problems one after the ot= her > focussing on OAuth related stuff first. Switching from implicit to code > solves leakage and injection in OAuth protocol messages. > > XSS can be solved in a sustained fashion using browser features only. If > an app includes code from untrusted locations then this code can access a= ll > browser APIs from the SPAs origin. Nothing will stop an attacker from > accessing local storage, web crypto API etc on behalf of the API. So yes, > SPAs need to implement proper XSS protection - independent of OAuth. Jim > already posted an advice on this topic. > > > > > > > > Much of the mechanisms are platform specific and need platform > expertise. > > I don't follow this one. We are targeting the browser, right? What are > the platform specific features you are thinking about? > > In this discussion, the platform is the browser. > > But my focus is not on browser clients only. I=E2=80=99m editing (along w= ith John, > Daniel and Andrey) the OAuth Security BCP. So I=E2=80=99m looking into > recommendations for all sorts of OAuth clients/deployments and want to ma= ke > sure a reasonable common security level. That=E2=80=99s why the place whe= re the > access tokens are ultimately used (the RS) and can leak and be replayed > also concerns me. > > Browser-based clients are just one client categories. Ensuring the > confidentiality of tokens is always a very client platform specific matte= r. > It works differently on iOS than on Windows 10 and requires platform > expertise and dedicated documentation (which would bloat the Security BCP= ). > That=E2=80=99s why there is need for client type specific BCPs. We have o= ne for > native apps and now work is being done towards a SPA BCP. That=E2=80=99s = where this > kind of consideration should land. > > > > > > > > From the OAuth protocol perspective, impact of RT leakage can be > limited through rotation. So I would argue RTs are better protected than > ATs. > > AFAIK relatively few providers today offer RT rotation (Microsoft is an > example of widely adopted provider who doesn't), and even if they do: if > you steal an RT and use it to get an AT you will enjoy full AT use until > the legitimate client attempts a refresh, which will be typically at near > expiry time, hence gaining very little. > > Depends on AT lifetime. With RTs you can have very short ATs lifetime > further reducing the attack window. The AT lifetime should be determined = by > the respective RSs sensitivity. > > > And given that even fewer providers offer access token revocation as a > consequence of attempted RT reuse, even more frequent refresh attempts > won't reduce the time the attacker has to use the access token they > obtained. Hence I am not sure I buy the argument that RTs are better > protected than ATs, both from the theoretical perspective and the practic= al > one. And in practical terms, if a developer is tied to a provider that > doesn't offer full RT rotation asking them to store RTs will make them > worse off than they are today. I am of course all for encouraging provide= rs > to introduce proper RT rotation support, but until they do developers > receiving this guidance TODAY will be stuck between a rock and a hard pla= ce. > > It=E2=80=99s a good idea to conduct a survey regarding existing RT implem= entation > practices. I=E2=80=99m under the impression vendors so far underestimated= the value > of RT when it comes to limiting the impact of token leakage. That=E2=80= =99s one > reason why I added the RT section to the Security BCP. > > > > > > Interesting question :-) I think login and API access are quite > different. > > Once again, this is very theoretical :) > > Oh, I just tried to address your arguments with what I consider a > substantial answers :-). > > > you, myself and the cohort on this lost can appreciate the difference > between the two scenarios- but from most practitioners without identity > background, sign out is "the user can't use the app anymore until they > enter their credentials again=E2=80=9C. > > Can you give a concrete example? To me it feels like you are explaining > scenarios where OAuth is used for login. > > > Whether they implement a proper sign in or go straight to API calling, > the visible effect they want to achieve is that one. With implicit today, > the access is all predicated on a single artifact- the provider session > cookie. If I have two apps in two tabs, signing out from one automaticall= y > robs the other from the ability to retain continued access. > > Are you assuming the AS revokes the AT on logout? Otherwise the other app > will realize the session termination when it attempts to obtain a new AT = in > another authorization flow. > > > By introducing another artifact that can provide continued access and > whose existence is independent from the session cookie, either I explicit= ly > manage the lifecycle of that artifact (by deleting it at the right time) = or > my app will simply be able to continue accessing API regardless of the fa= ct > that my session with the OP ended. > > Revoking the RT on logout is the proper solution for OAuth. > > > > > > In the API case, the AS can just revoke the RT when the logout happen= s. > > That's just not how that works for many of the big providers, and > without introducing new switches I don't think it should. RTs are issued > for offline access purposes, hence their lifetime can (and often will) > exceed the lifetime of sessions. > > Are those RT=E2=80=99s request for offline_access? Then I would argue thi= s > behavior is just fine and inline with the way OAuth is intended to work. > > > Borrowing from classic web scenarios, I can sign in and out of twitter > as much as I want- that should not affect twitter's ability to call APIs > even when I don't have a current session. That's the canonical use case I > think of when thinking of RTs. > > The challenge with SPAs is that successfully calling APIs is often used > in lieu of proper sign in; we can repeat until we're blue in the face tha= t > this leaves apps prone to confused deputy and the like, but in practice > people will keep doing it because to the non-initiated that makes intuiti= ve > sense. Hence either we introduce a switch that tells the AS that the RT w= e > are asking for needs to be tied to the session, and manage revocation > accordingly, or we manage the persistence of the RT at the application si= de. > > You mean discard the RT or revoke it explicitly on the app side? > > > The latter seems much easier to achieve to me, and above all more > immediately actionable given that I doubt providers will be very prompt i= n > introducing new features like the one hypothesized here. > > The scope offline access exists (although in the OIDC universe). Don=E2= =80=99t you > think it could be used for that purpose? > > kind regards, > Torsten. > > > > > > > On Thu, Dec 6, 2018 at 4:49 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Hi Vittorio, > > > > > Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci = : > > > > > > Thank you! > > > On the RT, more questions: > > > > > > - where would you save the RT? Iam thinking of the no-backend case in > particular. There=E2=80=99s a lot of heartburn in the community on where = to save > access tokens already, given the larger scope of refresh tokens I would > expect objections there would be exacerbated. > > > > Interesting, I=E2=80=99m much more concerned about tokens transmitted i= n URLs > since those tokens are vulnerable to remote attacks. > > > > Regarding protection at rest: what=E2=80=99s the attacker model in thos= e > discussions? XSS? Local attacks on the device? > > > > Much of the mechanisms are platform specific and need platform > expertise. > > > > From the OAuth protocol perspective, impact of RT leakage can be limite= d > through rotation. So I would argue RTs are better protected than ATs. > > > > > The user experience bar (number of prompts, full page redirects) > should be the one afforded by implicit leveraging AS sessions via > persistent cookies. > > > > sure. I don=E2=80=99t see any technical difference in the way the brows= er is > utilized for both flows and therefore would be surprised to see differenc= es > in UX. > > > > > > > > - how would we advise developers about handling distributed sign out? > If the session cookie with the AS is no longer the only artifact > representing the effective session, it looks like we should be prescripti= ve > on what signals an app should listen for (OIDC checkSession?) and what th= e > expected actions are (e.g. remove the cached RTs). I realize this isn=E2= =80=99t > strictly OAuth2, but it remains an important difference in end to end > scenarios people use implicit for today > > > > Interesting question :-) I think login and API access are quite > different. > > > > In login the client potentially wants to tightly couple its session > lifecycle to the AS/OP session, simply because it relies on the user id > attested by the OP=E2=80=99s for its local user/session management. > > > > For API access, this is not needed. The client =E2=80=9Ejust=E2=80=9C o= btains a > credential to access certain APIs on behalf of the resource owner. The > identity of the resource owner on the AS side and the identity of the > client user don=E2=80=99t necessary have a relationship. As you know, OAu= th was > intentionally built to hide the resource owner identity from the client. = I > think in this case the resource owner or the AS might have an interest to > terminate API access in case of logout at the AS. > > > > Protocol-wize this result in huge differences: In the login case, the > client can check the session with the OP periodically and terminate its o= wn > session in case the identity changed or there is no longer a session. Thi= s > typically requires frontend interactions and OpenID Connect (session mgmt > or logout). > > > > In the API case, the AS can just revoke the RT when the logout happens. > > > > kind regards, > > Torsten. > > > > > > > > Thx > > > V. > > > > > > On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > > > > > > > > Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci < > vittorio.bertocci@auth0.com>: > > > > > >> Hey Torsten/Tomek, > > >> Can I ask a clarification on the below? > > >> Torsten, you mentioned that an AS doesn't need to issue a RT- the > browser code can just repeat an authorization request. Did I get it right= ? > > >> But in order to preserve the user experience, that cannot really > happen as a full page redirect; right? That wouldn't fly for any kind of > background update, or for retrieving new ATs for different resources base= d > on the same session. So would we now use a hidden frame to retrieve a cod= e > in the same way in which we used fragments to get new ATs? > > > > > > That=E2=80=99s what I meant. I also think the RT-based approach is be= tter > suited in terms of UX and security. > > > > > >> Thx > > >> V. > > >> > > >> On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > >> Hi Tomek, > > >> > > >> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki >: > > >> > > > >> > Hi Torsten, > > >> > > > >> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten > Lodderstedt wrote: > > >> > > > >> > > > >> > >> So if I am putting myself in the shoes of somebody who sets out > to do that - switch an existing SPA client (no backend) > > >> > > > >> > > I would like to ask you a question: how many SPAs w/o a backend > have you seen in your projects? > > >> > > > >> > SPA (html+js) utilizing a 3rd party api that requires authorizatio= n? > > >> > If you do have a backend, aren't you better of handling the token > request on the backend as pointed out here > > >> > > https://github.com/aaronpk/oauth-browser-based-apps/blob/master/oauth-bro= wser-based-apps.md#javascript-app-with-a-backend-component > > >> > > >> I agree. > > >> > > >> > My point of putting (no backend) in parenthesis was to not derail > this discussion and of course it had the opposite effect. > > >> > > > >> > > >> You know, I you says =E2=80=9Edon=E2=80=99t look at the green car=E2= =80=9C will cause > everyone looking for it :-) It asked just out of curiosity. > > >> > > >> > >> Is that fair or is that too much of a shortcut? I am familiar > with the specs you've referenced and have looked at them again, but deali= ng > with a SPA, some of the recommendations are not feasible (can't > authenticate the client, > > >> > > > >> > > You could using dynamic registration (see other thread). The > protection would only differ from refresh token rotation if you would use > public key crypto for client authentication. > > >> > > > >> > Good point. How well is dynamic registration supported across AS? > > >> > > >> I leave that to the vendors :-) > > >> > > >> > > > >> > >> confidentiality in storage? - not sure how to read that in the > context of a browser) > > >> > > > >> > > How do you ensure confidentiality of session cookies? > > >> > > > >> > All I am trying to say is that I think context is important here. > So when you point out these best practices, some of them will get people > confused as far as what it means in the browser based app scenario. > > >> > > >> That=E2=80=99s why we have the more general Security BCP and client-= specific > BCPs, like for native apps (https://tools.ietf.org/html/rfc8252) and the > new BCP for SPAs Aaron started to work on. > > >> > > >> > Maybe it is just me :) > > >> > > >> thanks for raising the question! We need this kind of input to gover= n > the development of our specs. > > >> > > >> kind regards, > > >> Torsten. > > >> > > >> > > > >> > > > > >> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten > Lodderstedt wrote: > > >> > > > > >> > > > > >> > > Hi Tomek, > > >> > > > > >> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki 40yahoo.com@dmarc.ietf.org>: > > >> > > > > > >> > > > I agree with Vittorio, Dominick et al. > > >> > > > > > >> > > >> I disagree. > > >> > > > > > >> > > >> Existing deployments that have not mitigated against the > concerns with implicit should be ripped up and updated. > > >> > > > > > >> > > > Yes, just like future deployments that will not mitigate > against the concerns of code in the browser should be a concern. > > >> > > > > >> > > I agree. That=E2=80=99s why I pointed point yesterday that the S= ecurity > BCP also defines obligations for clients using code. > > >> > > > > >> > > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2= .1 > > >> > > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2= .1.1 > > >> > > > > >> > > > > > >> > > > Can somebody on the other side of the argument (and I hate to > make it sound like there are two sides, because we're on the same side as > far as Implicit's AT in front-channel is a real issue) address Dominic's > comment: > > >> > > > > > >> > > >> Also - simply saying =E2=80=9Cimplicit is evil - switch to co= de=E2=80=9D means > for most people also using refresh token - so we are treating access toke= ns > in the URL with refresh tokens in session storage (over simplified - but > you get the idea). > > >> > > > > > >> > > > Does the group agree|disagree that a recommendation to switch > to code should be made as long as it is followed by an explanation and > guidance on what to do with RTs? The ideas that were floated around > > >> > > > - Token bound RTs (even though it was pointed out that token > binding is still considered an emerging standard). So should the > recommendation than say "switch to code and MUST use token bound RTs"? > > >> > > > - Have AS not release RTs. "Switch to code and DO NOT request > RTs"? Or switch to code and configure AT to not release RTs for this type > of client (not sure what that even looks like in a form of a 3rd party > clients)? > > >> > > > - RTs short lived and bound to a session - "Switch to code as > long as AT can bind and revoke RTs when you log out=E2=80=9C > > >> > > > > >> > > Basically, the AS does not need to issue refresh tokens. If the > AS does not issue refresh tokens, the integration pattern for SPAs does n= ot > change (beside the code exchange). If the client needs a new access token= , > it will perform another authorization request. > > >> > > > > >> > > If it does, this adds another layer of security because it allow= s > the client to frequently obtain new access tokens, which can be short-liv= ed > and scope restricted. > > >> > > > > >> > > The refresh tokens should be replay protected by issuing new > refresh tokens with every refresh and detect replay for refresh tokens > belonging to the same grant. > > >> > > > > >> > > The AS may additionally bind refresh tokens to AS sessions, but > as it was pointed out by Annabelle and others, there are some implication= s > to be understood and managed in that context. > > >> > > > > >> > > You may find more text about refresh tokens in the Security BCP > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3= .12 > > >> > > > > >> > > kind regards, > > >> > > Torsten. > > >> > > > > >> > > > > >> > > > > > >> > > > Sorry if I have missed an important detail from the list above= , > people who have proposed these ideas, feel free to clarify. > > >> > > > > >> > > > > > >> > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt < > dick.hardt@gmail.com> wrote: > > >> > > > > > >> > > > I disagree. > > >> > > > > > >> > > > Existing deployments that have not mitigated against the > concerns with implicit should be ripped up and updated. > > >> > > > > > >> > > > For example, at one time, I think it was Instagram that had > deployed implicit because it was easier to do. Once the understood the > security implications, they changed the implementation. > > >> > > > > > >> > > > BCPs are rarely a response to a new threat, their are capturin= g > Best Current Practices so that they become widely deployed. > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > > >> > > >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc= . > are saying here. And that was kind of behind the comment I made, or tired > to make, about this in Bangkok, which was (more or less) that I don't thi= nk > the WG should be killing implicit outright but rather that it should begi= n > to recommend against it. > > >> > > >> > > >> > > >> I'm not exactly sure what that looks like in this document bu= t > maybe toning down some of the scarier language a bit, favoring SHOULDs vs= . > MUSTs, and including language that helps a reader understand the > recommendations as being more considerations for new > applications/deployments than as a mandate to rip up existing ones. > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley > wrote: > > >> > > >>> > > >> > > >>> We just need to be sensitive to the spin on this. > > >> > > >>> > > >> > > >> > > >> > > >> CONFIDENTIALITY NOTICE: This email may contain confidential > and privileged material for the sole use of the intended recipient(s). An= y > 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 fi= le > attachments from your computer. Thank > you._______________________________________________ > > >> > > >> 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 > > >> > > > > --0000000000005ae058057c8e6f14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Torsten.
As another meta comment, in general I = am not disagreeing with the guidance- I just think that the language we use= should make it easier for practitioners to understand what they are suppos= ed to do to put this guidance in concrete terms. That includes better clari= fying risks, opening acknowledging when the recommended remedies aren't= likely to be viable in the short term (as we do with TB) and emphasizing g= uidance that can be widely applied today (for example, mentioning both the = use of hidden frame+code for token renewals and use of RTs, but highlightin= g the factors that make the latter hard to use at this time).
Als= o; I apologize for the length. I think we are approaching the point in whic= h using email as collaboration tool might become inadequate. I am happy to = hop on a call if that helps.

> This requires the = respective solutions to support response type code/grant type authorization= code (lib & AS), PKCE (lib & AS) and CORS (AS) for public clients.= =C2=A0

I am not as worried about those, as support= for those is already widespread (as they are required for other scenarios)= . The thing I was focusing in that mail in particular was the features requ= ired for making the use (and above all, storing) of RTs in the browser. As = discussed, those features aren't widely available hence I feel any guid= ance to app developers (as opposed to provider) should warn them about it a= nd probably emphasize more the risks associated to it (eg XSS). The scenari= o I am worried about is people feeling this gives them license to use RTs i= n the browser even when those mitigations aren't available.
<= br>

>=C2=A0 The reality is, most people don=E2=80=99t care about security and most prac= tices I have seen are more on the bad practice end. So what shall we do? Si= t on our hands?=C2=A0

Again, I am not suggesting i= naction. I am only concerned about ensuring that developers reading this ha= ve a clear idea of what's directional (where we think the world should = go) and what's practical (what is achievable with the mainstream featur= e set today). Vendors verifying that what is being proposed here can be ach= ieved with their feature set is the first step to distinguish between the t= wo, and help setting the right expectations on how actionable the guidance = is today. Those findings won't change what we suggest as directional, b= ut might change expectations on what developers can do today, hence the ton= e and the language we use.


> The= measures I propose have been implemented and used in production for years = at Deutsche Telekom (consumer services, millions of unique users).

I am not saying that those features are not implementable.= I am saying that they might not be available for developers. The fact that= DT implemented those measures will not help at all the developer maintaini= ng a SPA app that must work with the Google or Microsoft AS because that= 9;s the API ecosystem they took a dependency on. Either the new guidance th= ey receive is feasible on those platforms, or they are stranded in no man&#= 39;s land where they can't keep their current approach (ignoring for a = second the urgency/why now discussion we had earlier) AND they can't im= plement the new one because they can't change vendor ecosystem overnigh= t.
In practical term, the above for me means prototyping the new = guidance and incorporating the finding in the document. To pick on the same= example, if we find that most vendors can use code+hidden iframe for token= renewal while few support rotating RTs, guidance should clarify that.=C2= =A0=C2=A0


> I don=E2=80=99t igno= re XSS. I want to solve the problems one after the other focussing on OAuth= related stuff first. Switching from implicit to code solves leakage and in= jection in OAuth protocol messages.=C2=A0

I don= 9;t think the two things are mutually exclusive or need sequencing. We can = recommend switching to code without necessarily bringing RTs into the pictu= re.=C2=A0
My main point is, if we do bring them in the picture, w= e should be careful to list the caveats that come with it.=C2=A0
=

> Browser-based clients are just one clien= t categories. Ensuring the confidentiality of tokens is always a very clien= t platform specific matter.=C2=A0=C2=A0=C2=A0

= I see. Non browser platforms already store refresh tokens locally, I person= ally spent a good decade dealing with that on multiple OSes and the approac= h is in use in many of the most used applicaitons on the planet.
= For Occam razor, in this discussion I am mostly concerned about doing that = in the browser as it is a scenario as the guidance has always been to never= use RTs in Javascript, hence that's the area where I feel clarificatio= n is needed. That doesn't mean that the rest is uninteresting: but agai= n for Occam razor, the existence of keychain on iOS or of DPAPI on Windows = does little to mitigate the discussion on XSS.

> Can you give a concrete example? To me it feels like you a= re explaining scenarios where OAuth is used for login.=C2=A0=C2=A0

That's one of the scenarios of interest here. We c= an debate on whether that's proper or not, but the practical consequenc= e is that if I have two (or N) apps that can call APIs via tokens obtained = with the implicit flow, eliminating AS the session cookie will prevent them= from getting new tokens automatically, without the developer having to wri= te any code for "signout".
The moment in which apps swi= tch to code and hold on to RTs, the sheer fact that the AS session cookie i= s gone will NOT stop individual apps from being able to get new access toke= ns and call API.
That would be an unintended consequence of the s= witch to code, and regardless of whether it's a consequence of people a= busing the protocol or not, I think this scenario should be documented and = people should be warned against it.


> Are you assuming the AS revokes the AT on logout? Otherwise the other= app will realize the session termination when it attempts to obtain a new = AT in another authorization flow.=C2=A0=C2=A0

= All the ASes I have worked on try to be as stateless as possible, and won&#= 39;t revoke ASes in logouts.


> R= evoking the RT on logout is the proper solution for OAuth.=C2=A0
=
Perhaps, but again in my experience with mainstream provider= s, that doesn't happen. The fact that it would be the correct behavior = in theory doesn't change the risk in the wild, and what i am most conce= rned about is to help developers avoid suffering unintended consequences as= we exercise existing products in new ways and those discrepancies come out= .


>Are those RT=E2=80=99s reques= t for offline_access? Then I would argue this behavior is just fine and inl= ine with the way OAuth is intended to work.=C2=A0

= This is another excellent example of differences between theory and practic= e. Products providing AS functionality won't typically make a very cris= p subdivision between OAuth2 and OIDC features- it's the same endpoints= , solving similar scenarios. For some of the mainstream providers, requesti= ng offline_access is the ONLY way to get a refresh token, no matter whether= you are trying to use OAuth2 or OIDC. That means that the offline usage (a= s opposed to session) is the ONLY semantic attributed to refresh tokens iss= ued by those providers. Once again we can argue about the sins of the produ= ct designers who crafted things that way, but our first responsibility, I b= elieve, should be toward the developers and toward helping them to do the r= ight thing in the environment they operate. Not saying we need to give guid= ance for each vendor (that's the vendor's job) but I do think we ne= ed to think through those details and give the proper headsup ("beware= : your AS might issue RTs that keep working even when the session originati= ng them is long gone, hence please make sure to keep an eye on the session = status (checkSession etc) and to dispose of all the RTs when you detect tha= t the session is gone" or "make sure that, when you request an RT= from a SPA, you use whatever switch your vendor requires to have session b= ound RTs rather than offline_access ones. Your vendor don;t offer that opti= on? See the other sentence").


= > You mean discard the RT or revoke it explicitly on the app side?=C2=A0= =C2=A0

I mean discard the RT on the app side.= =C2=A0


>The scope offline access= exists (although in the OIDC universe). Don=E2=80=99t you think it could b= e used for that purpose?

See above. For various ve= ndors, offline_access is the only way of requesting a RT hence it can;t be = used as a differentiation between offline and session RTs.


On Sat,= Dec 8, 2018 at 5:12 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Vittorio,

> Am 06.12.2018 um 19:09 schrieb Vittorio Bertocci <Vittorio@auth0.com>:
>
> Thank you Torsten.
> I think that a lot of the considerations below need to be tempered wit= h concrete considerations about the features developers can actually rely o= n today.
> I agree with identifying the theoretical framework and north star we w= ant to aspire to, but if we are framing the recommendation here in form of = practice, we have to ensure it is actionable for developers. I am not pushi= ng back on ideas, but I just want to make sure that when customers hear thi= s advice, they are actually in the position to apply it. And if there are m= issing pieces, perhaps we should consider this more as guidance to the vend= ors that need to provide key enablers for this to become viable, and recomm= end it as practice to customers only when that happened.

I agree. That=E2=80=99s what basically happened with mTLS and Token Binding= . We realized the need to find a reasonable way to prevent token replay in = the course of our in-depth security analysis. Out of the two options (audie= nce restriction and sender constrained tokens), we selected sender constrai= ned tokens because they are the most appropriate measure (or just "bui= ld for that purpose" as Dirk Balfanz pointed out at that time). Token = Binding unfortunately lost some traction but mTLS can be used instead and i= s being used in the open banking space by all initiatives I=E2=80=99m aware= of (UK OB, STET, BerlinGroup). So we were right on time.

I see the same happening with respect to implicit and SPAs now. I think the= baseline is clear: implicit is replaced by code+PKCE, so SPAs need to be e= xtended to handle PKCE and exchange the code for an access token. This step= is a huge security improvement since it closes the attack angle of leakage= and injection/replay via the URL.

This requires the respective solutions to support response type code/grant = type authorization code (lib & AS), PKCE (lib & AS) and CORS (AS) f= or public clients.

> I add more details inline below, however I have a meta point to make: = did all the vendors on the list work on proof of concepts to ensure that th= e practices recommended here can work with your product, end to end?
> I don't mean just doing a code+PKCE demo in JS, I mean complying w= ith things like RT rotation and revocation end to end, using released featu= res that your customers can use today. If you did, it might really help to = use them to make those discussions more concrete. If you didn't, then c= alling the proposal a practice might be premature.

I understand your argument and I would be happy to just document best secur= ity practices. The reality is, most people don=E2=80=99t care about securit= y and most practices I have seen are more on the bad practice end. So what = shall we do? Sit on our hands?

In my observation, the SPA OAuth universe to a large extend developed compl= etely independent of the rest of the OAuth universe. For example, I saw SPA= libraries recommending implicit and the resource owner credential grant. W= ow! What a mixture when combined with XSS!

I think we can transfer some proven techniques from the general OAuth world= into the SPA OAuth world, e.g. code & PKCE. Add CORS to that and we ha= ve a reasonable baseline for SPAs, which copes with the particular threats = implicit is vulnerable to. One hole closed, great!

Opening the picture a bit, we must realize token leakage also happens at re= source servers, that's why we included the recommendation for sender co= nstrained tokens to the BCP (for _all_ kinds of clients!).

mTLS works well for native and web apps. It won=E2=80=99t work well for SPA= =E2=80=99s simply because the SPA cannot automatically setup a cert in the = browser, so it would need an external enrollment process. It will also resu= lt in a poor UX due to selection dialogs etc. Token binding would be the mu= ch better solution but lacks adoption.=C2=A0

That=E2=80=99s why I think refresh tokens should be considered at least as = a means to limit the impact of access token leakage at RSs. The measures I = propose have been implemented and used in production for years at Deutsche = Telekom (consumer services, millions of unique users). I also think Oath im= plemented RT revocation on logout. But I also realized commercial vendors a= nd other deployments seem to have less sophisticated implementations in pla= ce. So where does this leave us? Running code exists but more vendors must = support these features. One could also say: What are ideas for some people = is proven practice for others.

=C2=A0

> inline:
>=C2=A0
>
> > Regarding protection at rest: what=E2=80=99s the attacker model i= n those discussions? XSS? Local attacks on the device?
> The main concern is XSS. You can just google token session storage to = find an onslaught of articles and forum threads on the topic. To pick one a= t random, here's the one from Mozilla.
> We can argue on what's worse between XSS and URL leaks, but I don&= #39;t think we can ignore the pervasive ongoing debate and perception that = use of local storage for sensitive data is bad.

I don=E2=80=99t ignore XSS. I want to solve the problems one after the othe= r focussing on OAuth related stuff first. Switching from implicit to code s= olves leakage and injection in OAuth protocol messages.

XSS can be solved in a sustained fashion using browser features only. If an= app includes code from untrusted locations then this code can access all b= rowser APIs from the SPAs origin. Nothing will stop an attacker from access= ing local storage, web crypto API etc on behalf of the API. So yes, SPAs ne= ed to implement proper XSS protection - independent of OAuth. Jim already p= osted an advice on this topic.

>
>
> >=C2=A0 Much of the mechanisms are platform specific and need platf= orm expertise.
> I don't follow this one. We are targeting the browser, right? What= are the platform specific features you are thinking about?

In this discussion, the platform is the browser.

But my focus is not on browser clients only. I=E2=80=99m editing (along wit= h John, Daniel and Andrey) the OAuth Security BCP. So I=E2=80=99m looking i= nto recommendations for all sorts of OAuth clients/deployments and want to = make sure a reasonable common security level. That=E2=80=99s why the place = where the access tokens are ultimately used (the RS) and can leak and be re= played also concerns me.

Browser-based clients are just one client categories. Ensuring the confiden= tiality of tokens is always a very client platform specific matter. It work= s differently on iOS than on Windows 10 and requires platform expertise and= dedicated documentation (which would bloat the Security BCP). That=E2=80= =99s why there is need for client type specific BCPs. We have one for nativ= e apps and now work is being done towards a SPA BCP. That=E2=80=99s where t= his kind of consideration should land.

>
>
> > From the OAuth protocol perspective, impact of RT leakage can be = limited through rotation. So I would argue RTs are better protected than AT= s.
> AFAIK relatively few providers today offer RT rotation (Microsoft is a= n example of widely adopted provider who doesn't), and even if they do:= if you steal an RT and use it to get an AT you will enjoy full AT use unti= l the legitimate client attempts a refresh, which will be typically at near= expiry time, hence gaining very little.

Depends on AT lifetime. With RTs you can have=C2=A0 very short ATs lifetime= further reducing the attack window. The AT lifetime should be determined b= y the respective RSs sensitivity.=C2=A0

> And given that even fewer providers offer access token revocation as a= consequence of attempted RT reuse, even more frequent refresh attempts won= 't reduce the time the attacker has to use the access token they obtain= ed. Hence I am not sure I buy the argument that RTs are better protected th= an ATs, both from the theoretical perspective and the practical one. And in= practical terms, if a developer is tied to a provider that doesn't off= er full RT rotation asking them to store RTs will make them worse off than = they are today. I am of course all for encouraging providers to introduce p= roper RT rotation support, but until they do developers receiving this guid= ance TODAY will be stuck between a rock and a hard place.

It=E2=80=99s a good idea to conduct a survey regarding existing RT implemen= tation practices. I=E2=80=99m under the impression vendors so far underesti= mated the value of RT when it comes to limiting the impact of token leakage= . That=E2=80=99s one reason why I added the RT section to the Security BCP.=

>
> > Interesting question :-) I think login and API access are quite d= ifferent.
> Once again, this is very theoretical :)

Oh, I just tried to address your arguments with what I consider a substanti= al answers :-).=C2=A0

> you, myself and the cohort on this lost can appreciate the difference = between the two scenarios- but from most practitioners without identity bac= kground, sign out is "the user can't use the app anymore until the= y enter their credentials again=E2=80=9C.

Can you give a concrete example? To me it feels like you are explaining sce= narios where OAuth is used for login.

> Whether they implement a proper sign in or go straight to API calling,= the visible effect they want to achieve is that one. With implicit today, = the access is all predicated on a single artifact- the provider session coo= kie. If I have two apps in two tabs, signing out from one automatically rob= s the other from the ability to retain continued access.

Are you assuming the AS revokes the AT on logout? Otherwise the other app w= ill realize the session termination when it attempts to obtain a new AT in = another authorization flow.

> By introducing another artifact that can provide continued access and = whose existence is independent from the session cookie, either I explicitly= manage the lifecycle of that artifact (by deleting it at the right time) o= r my app will simply be able to continue accessing API regardless of the fa= ct that my session with the OP ended.

Revoking the RT on logout is the proper solution for OAuth.

>
> > In the API case, the AS can just revoke the RT when the logout ha= ppens.
> That's just not how that works for many of the big providers, and = without introducing new switches I don't think it should. RTs are issue= d for offline access purposes, hence their lifetime can (and often will) ex= ceed the lifetime of sessions.

Are those RT=E2=80=99s request for offline_access? Then I would argue this = behavior is just fine and inline with the way OAuth is intended to work.
> Borrowing from classic web scenarios, I can sign in and out of twitter= as much as I want- that should not affect twitter's ability to call AP= Is even when I don't have a current session. That's the canonical u= se case I think of when thinking of RTs.
> The challenge with SPAs is that successfully calling APIs is often use= d in lieu of proper sign in; we can repeat until we're blue in the face= that this leaves apps prone to confused deputy and the like, but in practi= ce people will keep doing it because to the non-initiated that makes intuit= ive sense. Hence either we introduce a switch that tells the AS that the RT= we are asking for needs to be tied to the session, and manage revocation a= ccordingly, or we manage the persistence of the RT at the application side.=

You mean discard the RT or revoke it explicitly on the app side?

> The latter seems much easier to achieve to me, and above all more imme= diately actionable given that I doubt providers will be very prompt in intr= oducing new features like the one hypothesized here.

The scope offline access exists (although in the OIDC universe). Don=E2=80= =99t you think it could be used for that purpose?

kind regards,
Torsten.

>
>
> On Thu, Dec 6, 2018 at 4:49 AM Torsten Lodderstedt <torsten@lodderstedt.net&g= t; wrote:
> Hi Vittorio,
>
> > Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci <Vittorio@auth0.com>:
> >
> > Thank you!
> > On the RT, more questions:
> >
> > - where would you save the RT? Iam thinking of the no-backend cas= e in particular. There=E2=80=99s a lot of heartburn in the community on whe= re to save access tokens already, given the larger scope of refresh tokens = I would expect objections there would be exacerbated.
>
> Interesting, I=E2=80=99m much more concerned about tokens transmitted = in URLs since those tokens are vulnerable to remote attacks.
>
> Regarding protection at rest: what=E2=80=99s the attacker model in tho= se discussions? XSS? Local attacks on the device?
>
> Much of the mechanisms are platform specific and need platform experti= se.
>
> From the OAuth protocol perspective, impact of RT leakage can be limit= ed through rotation. So I would argue RTs are better protected than ATs. >
> > The user experience bar (number of prompts, full page redirects) = should be the one afforded by implicit leveraging AS sessions via persisten= t cookies.
>
> sure. I don=E2=80=99t see any technical difference in the way the brow= ser is utilized for both flows and therefore would be surprised to see diff= erences in UX.
>
> >=C2=A0
> > - how would we advise developers about handling distributed sign = out? If the session cookie with the AS is no longer=C2=A0 the only artifact= representing the effective session, it looks like we should be prescriptiv= e on what signals an app should listen for (OIDC checkSession?) and what th= e expected actions are (e.g. remove the cached RTs). I realize this isn=E2= =80=99t strictly OAuth2, but it remains an important difference in end to e= nd scenarios people use implicit for today
>
> Interesting question :-) I think login and API access are quite differ= ent.
>
> In login the client potentially wants to tightly couple its session li= fecycle to the AS/OP session, simply because it relies on the user id attes= ted by the OP=E2=80=99s for its local user/session management.
>
> For API access, this is not needed. The client =E2=80=9Ejust=E2=80=9C = obtains a credential to access certain APIs on behalf of the resource owner= . The identity of the resource owner on the AS side and the identity of the= client user don=E2=80=99t necessary have a relationship. As you know, OAut= h was intentionally built to hide the resource owner identity from the clie= nt. I think in this case the resource owner or the AS might have an interes= t to terminate API access in case of logout at the AS.
>
> Protocol-wize this result in huge differences: In the login case, the = client can check the session with the OP periodically and terminate its own= session in case the identity changed or there is no longer a session. This= typically requires frontend interactions and OpenID Connect (session mgmt = or logout).
>
> In the API case, the AS can just revoke the RT when the logout happens= .
>
> kind regards,
> Torsten.
>
> >
> > Thx
> > V.
> >
> > On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
> >
> >
> > Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci <vittorio.bertocci@auth= 0.com>:
> >
> >> Hey Torsten/Tomek,
> >> Can I ask a clarification on the below?
> >> Torsten, you mentioned that an AS doesn't need to issue a= RT- the browser code can just repeat an authorization request. Did I get i= t right?
> >> But in order to preserve the user experience, that cannot rea= lly happen as a full page redirect; right? That wouldn't fly for any ki= nd of background update, or for retrieving new ATs for different resources = based on the same session. So would we now use a hidden frame to retrieve a= code in the same way in which we used fragments to get new ATs?
> >
> > That=E2=80=99s what I meant. I also think the RT-based approach i= s better suited in terms of UX and security.
> >
> >> Thx
> >> V.
> >>
> >> On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt <torsten@lodderstedt.= net> wrote:
> >> Hi Tomek,
> >>
> >> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki <tstojecki@yahoo.com&= gt;:
> >> >
> >> > Hi Torsten,
> >> >
> >> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torste= n Lodderstedt <torsten@lodderstedt.net> wrote:
> >> >
> >> >
> >> > >> So if I am putting myself in the shoes of someb= ody who sets out to do that - switch an existing SPA client (no backend) > >> >
> >> > > I would like to ask you a question: how many SPAs w= /o a backend have you seen in your projects?
> >> >
> >> > SPA (html+js) utilizing a 3rd party api that requires au= thorization?
> >> > If you do have a backend, aren't you better of handl= ing the token request on the backend as pointed out here
> >> > https://github.com/aaronp= k/oauth-browser-based-apps/blob/master/oauth-browser-based-apps.md#javascri= pt-app-with-a-backend-component
> >>
> >> I agree.
> >>
> >> > My point of putting (no backend) in parenthesis was to n= ot derail this discussion and of course it had the opposite effect.
> >> >
> >>
> >> You know, I you says =E2=80=9Edon=E2=80=99t look at the green= car=E2=80=9C will cause everyone looking for it :-) It asked just out of c= uriosity.
> >>
> >> > >> Is that fair or is that too much of a shortcut?= I am familiar with the specs you've referenced and have looked at them= again, but dealing with a SPA, some of the recommendations are not feasibl= e (can't authenticate the client,
> >> >
> >> > > You could using dynamic registration (see other thr= ead). The protection would only differ from refresh token rotation if you w= ould use public key crypto for client authentication.
> >> >
> >> > Good point. How well is dynamic registration supported a= cross AS?
> >>
> >> I leave that to the vendors :-)
> >>
> >> >
> >> > >> confidentiality in storage? - not sure how to r= ead that in the context of a browser)
> >> >
> >> > > How do you ensure confidentiality of session cookie= s?
> >> >
> >> > All I am trying to say is that I think context is import= ant here. So when you point out these best practices, some of them will get= people confused as far as what it means in the browser based app scenario.=
> >>
> >> That=E2=80=99s why we have the more general Security BCP and = client-specific BCPs, like for native apps (https://tools.ietf.or= g/html/rfc8252) and the new BCP for SPAs Aaron started to work on.
> >>
> >> > Maybe it is just me :)
> >>
> >> thanks for raising the question! We need this kind of input t= o govern the development of our specs.
> >>
> >> kind regards,
> >> Torsten.
> >>
> >> >
> >> > >
> >> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Tor= sten Lodderstedt <torsten@lodderstedt.net> wrote:
> >> > >
> >> > >
> >> > > Hi Tomek,
> >> > >
> >> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki = <tstojecki=3D40yahoo.com@dmarc.ietf.org>:
> >> > > >
> >> > > > I agree with Vittorio, Dominick et al.
> >> > > >
> >> > > >> I disagree.
> >> > > >
> >> > > >> Existing deployments that have not mitigat= ed against the concerns with implicit should be ripped up and updated.
> >> > > >
> >> > > > Yes, just like future deployments that will no= t mitigate against the concerns of code in the browser should be a concern.=
> >> > >
> >> > > I agree. That=E2=80=99s why I pointed point yesterd= ay that the Security BCP also defines obligations for clients using code. <= br> > >> > >
> >> > > h= ttps://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1<= /a>
> >> > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.= 1.1
> >> > >
> >> > > >
> >> > > > Can somebody on the other side of the argument= (and I hate to make it sound like there are two sides, because we're o= n the same side as far as Implicit's AT in front-channel is a real issu= e) address Dominic's comment:
> >> > > >
> >> > > >> Also - simply saying =E2=80=9Cimplicit is = evil - switch to code=E2=80=9D means for most people also using refresh tok= en - so we are treating access tokens in the URL with refresh tokens in ses= sion storage (over simplified - but you get the idea).
> >> > > >
> >> > > > Does the group agree|disagree that a recommend= ation to switch to code should be made as long as it is followed by an expl= anation and guidance on what to do with RTs? The ideas that were floated ar= ound
> >> > > > - Token bound RTs (even though it was pointed = out that token binding is still considered an emerging standard). So should= the recommendation than say "switch to code and MUST use token bound = RTs"?
> >> > > > - Have AS not release RTs. "Switch to cod= e and DO NOT request RTs"? Or switch to code and configure AT to not r= elease RTs for this type of client (not sure what that even looks like in a= form of a 3rd party clients)?
> >> > > > - RTs short lived and bound to a session - &qu= ot;Switch to code as long as AT can bind and revoke RTs when you log out=E2= =80=9C
> >> > >
> >> > > Basically, the AS does not need to issue refresh to= kens. If the AS does not issue refresh tokens, the integration pattern for = SPAs does not change (beside the code exchange). If the client needs a new = access token, it will perform another authorization request.=C2=A0
> >> > >
> >> > > If it does, this adds another layer of security bec= ause it allows the client to frequently obtain new access tokens, which can= be short-lived and scope restricted.
> >> > >
> >> > > The refresh tokens should be replay protected by is= suing new refresh tokens with every refresh and detect replay for refresh t= okens belonging to the same grant.
> >> > >
> >> > > The AS may additionally bind refresh tokens to AS s= essions, but as it was pointed out by Annabelle and others, there are some = implications to be understood and managed in that context.
> >> > >
> >> > > You may find more text about refresh tokens in the = Security BCP https://too= ls.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.12
> >> > >
> >> > > kind regards,
> >> > > Torsten.
> >> > >
> >> > >
> >> > > >
> >> > > > Sorry if I have missed an important detail fro= m the list above, people who have proposed these ideas, feel free to clarif= y.
> >> > >
> >> > > >
> >> > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1= , Dick Hardt <= dick.hardt@gmail.com> wrote:
> >> > > >
> >> > > > I disagree.
> >> > > >
> >> > > > Existing deployments that have not mitigated a= gainst the concerns with implicit should be ripped up and updated.
> >> > > >
> >> > > > For example, at one time, I think it was Insta= gram that had deployed implicit because it was easier to do. Once the under= stood the security implications, they changed the implementation.
> >> > > >
> >> > > > BCPs are rarely a response to a new threat, th= eir are capturing Best Current Practices so that they become widely deploye= d.
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell= <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
> >> > > >> FWIW I'm somewhat sympathetic to what = Vittorio, Dominick, etc. are saying here. And that was kind of behind the c= omment I made, or tired to make, about this in Bangkok, which was (more or = less) that I don't think the WG should be killing implicit outright but= rather that it should begin to recommend against it.
> >> > > >>
> >> > > >> I'm not exactly sure what that looks l= ike in this document but maybe toning down some of the scarier language a b= it, favoring SHOULDs vs. MUSTs, and including language that helps a reader = understand the recommendations as being more considerations for new applica= tions/deployments than as a mandate to rip up existing ones.
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradle= y <ve7jtb@ve7jtb.= com> wrote:
> >> > > >>>
> >> > > >>> We just need to be sensitive to the sp= in on this.=C2=A0
> >> > > >>>
> >> > > >>
> >> > > >> CONFIDENTIALITY NOTICE: This email may con= tain confidential and privileged material for the sole use of the intended = recipient(s). Any review, use, distribution or disclosure by others is stri= ctly prohibited...=C2=A0 If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message and a= ny file attachments from your computer. Thank you._________________________= ______________________
> >> > > >> OAuth mailing list
> >> > > >> OAuth@ietf.org
> >> > > >> https://www.ietf.org/mai= lman/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/list= info/oauth
> >>
>

--0000000000005ae058057c8e6f14-- From nobody Sun Dec 9 00:00:27 2018 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 61361130EF1 for ; Sun, 9 Dec 2018 00:00:25 -0800 (PST) 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, HTML_MESSAGE=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 F8a9XQ8JJ87B for ; Sun, 9 Dec 2018 00:00:23 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 55B1813101E for ; Sun, 9 Dec 2018 00:00:23 -0800 (PST) Received: from [IPv6:2601:282:202:b210:d129:b249:15c0:63a8] (unknown [IPv6:2601:282:202:b210:d129:b249:15c0:63a8]) by alkaline-solutions.com (Postfix) with ESMTPSA id 5CB1A31682; Sun, 9 Dec 2018 08:00:22 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3624627A-ADFE-47A6-AAED-B80E59A428B8" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sun, 9 Dec 2018 01:00:21 -0700 In-Reply-To: Cc: Aaron Parecki , oauth@ietf.org To: Brock Allen References: <6d88c55a-a300-47ff-af77-8fdb7dcfbc25@getmailbird.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps and response_type/fragment 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, 09 Dec 2018 08:00:26 -0000 --Apple-Mail=_3624627A-ADFE-47A6-AAED-B80E59A428B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I assume the original post meant response_mode, not response_type. Fragments have their own data leakage problems, in particular they are = preserved on 3xx redirects (per = https://tools.ietf.org/html/rfc7231#section-7.1.2 = ). The form_post mode = is the safest, but unfortunately was not defined in the original = specifications so it doesn=E2=80=99t have as widespread support. In the absence of a response_mode RFC, I would typically suggest both = killing the code in the referrer as part of processing, and a = server-wide Referrer Policy of never or origin (as those have reasonably = broad support) as server-wide response headers are easier to = operationally audit. -DW > On Dec 8, 2018, at 3:53 PM, Brock Allen wrote: >=20 > Not pure OAuth. This only came up as a question while I was = implementing code flow/pkce for oidc-client-js. >=20 > I can appreciate not expanding the current OAuth2 behavior in the BCP, = so that's fair. I only wanted to mention it in case it had not been = considered. >=20 > Having said that, I think I will implement an optional response_type = in my code flow/pkce to allow fragment, but default to query (as that's = the default for pure code flow). >=20 > -Brock --Apple-Mail=_3624627A-ADFE-47A6-AAED-B80E59A428B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I assume the original post meant response_mode, not = response_type.

Fragments have = their own data leakage problems, in particular they are preserved on 3xx = redirects (per https://tools.ietf.org/html/rfc7231#section-7.1.2). The = form_post mode is the safest, but unfortunately was not defined in the = original specifications so it doesn=E2=80=99t have as widespread = support.

In the = absence of a response_mode RFC, I would typically suggest both killing = the code in the referrer as part of processing, and a server-wide = Referrer Policy of never or origin (as those have reasonably broad = support) as server-wide response headers are easier to operationally = audit.

-DW

On Dec 8, 2018, at 3:53 PM, = Brock Allen <brockallen@gmail.com> wrote:

=20 =20 =20 =20 =20 Not pure OAuth. This only came = up as a question while I was implementing code flow/pkce for = oidc-client-js.

I = can appreciate not expanding the current OAuth2 behavior in the BCP, so = that's fair. I only wanted to mention it in case it had not been = considered.

Having said that, I think I will implement an optional = response_type in my code flow/pkce to allow fragment, but default to = query (as that's the default for pure code flow).

-Brock

= --Apple-Mail=_3624627A-ADFE-47A6-AAED-B80E59A428B8-- From nobody Sun Dec 9 00:57:33 2018 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 00289130F35 for ; Sun, 9 Dec 2018 00:57:31 -0800 (PST) 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, HTML_MESSAGE=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 B5WaKt-IA_jr for ; Sun, 9 Dec 2018 00:57:30 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 3B39E130F09 for ; Sun, 9 Dec 2018 00:57:30 -0800 (PST) Received: from [IPv6:2601:282:202:b210:d129:b249:15c0:63a8] (unknown [IPv6:2601:282:202:b210:d129:b249:15c0:63a8]) by alkaline-solutions.com (Postfix) with ESMTPSA id B120431682; Sun, 9 Dec 2018 08:57:28 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CD3CE160-056B-4587-9F5D-49CEE706F8C1" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sun, 9 Dec 2018 01:57:27 -0700 In-Reply-To: Cc: Torsten Lodderstedt , Daniel Fett , IETF oauth WG To: Vittorio Bertocci References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> <1333FFC2-A2F0-479D-8E7C-9ACFEC8E5724@lodderstedt.net> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 09 Dec 2018 08:57:32 -0000 --Apple-Mail=_CD3CE160-056B-4587-9F5D-49CEE706F8C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 8, 2018, at 8:27 PM, Vittorio Bertocci = wrote: >=20 > > Can you give a concrete example? To me it feels like you are = explaining scenarios where OAuth is used for login. =20 >=20 > That's one of the scenarios of interest here. We can debate on whether = that's proper or not, but the practical consequence is that if I have = two (or N) apps that can call APIs via tokens obtained with the implicit = flow, eliminating AS the session cookie will prevent them from getting = new tokens automatically, without the developer having to write any code = for "signout". > The moment in which apps switch to code and hold on to RTs, the sheer = fact that the AS session cookie is gone will NOT stop individual apps = from being able to get new access tokens and call API. > That would be an unintended consequence of the switch to code, and = regardless of whether it's a consequence of people abusing the protocol = or not, I think this scenario should be documented and people should be = warned against it. The AS is ultimately responsible for the security policy, though - if = the AS policy isn=E2=80=99t supposed to allow my application access = after the user hits log out, it should either: 1. Tie my application refresh tokens to be revoked at the logout event 2. Not give out refresh tokens to my application Note that the session cookie is fulfilling the role of the refresh token = in the second case. Also note that telling a browser to discard the = cookie is not as good as supporting revoking it - if there is no = revocation mechanism, a third party who gets the cookie/refresh token = can use it for as long as policy allows. I don=E2=80=99t expect application developers to use libraries that = locally enforce more restrictive policy just because the operators of = the AS aren=E2=80=99t doing their job setting appropriate policy for = their clients. So this is really more of something that the AS needs to = understand about their own policy. -DW= --Apple-Mail=_CD3CE160-056B-4587-9F5D-49CEE706F8C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Dec 8, 2018, at 8:27 PM, Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:

> = Can you give a concrete example? To me it feels like you are explaining = scenarios where OAuth is used for login.  

That's one of the scenarios of = interest here. We can debate on whether that's proper or not, but the = practical consequence is that if I have two (or N) apps that can call = APIs via tokens obtained with the implicit flow, eliminating AS the = session cookie will prevent them from getting new tokens automatically, = without the developer having to write any code for "signout".
The = moment in which apps switch to code and hold on to RTs, the sheer fact = that the AS session cookie is gone will NOT stop individual apps from = being able to get new access tokens and call API.
That = would be an unintended consequence of the switch to code, and regardless = of whether it's a consequence of people abusing the protocol or not, I = think this scenario should be documented and people should be warned = against it.

The AS is ultimately responsible for the security policy, = though - if the AS policy isn=E2=80=99t supposed to allow my application = access after the user hits log out, it should either:
1. Tie my application refresh tokens to be revoked at the = logout event
2. Not give out refresh tokens to my = application

Note= that the session cookie is fulfilling the role of the refresh token in = the second case. Also note that telling a browser to discard the cookie = is not as good as supporting revoking it - if there is no revocation = mechanism, a third party who gets the cookie/refresh token can use it = for as long as policy allows.

I don=E2=80=99t expect application = developers to use libraries that locally enforce more restrictive policy = just because the operators of the AS aren=E2=80=99t doing their job = setting appropriate policy for their clients. So this is really more of = something that the AS needs to understand about their own = policy.

-DW
= --Apple-Mail=_CD3CE160-056B-4587-9F5D-49CEE706F8C1-- From nobody Sun Dec 9 03:10:34 2018 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 A0D3A127598 for ; Sun, 9 Dec 2018 03:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.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 THwSnbjY7IQ4 for ; Sun, 9 Dec 2018 03:10:29 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 69015124BF6 for ; Sun, 9 Dec 2018 03:10:29 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id v5so5977883lfe.7 for ; Sun, 09 Dec 2018 03:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ONpdSjLbqp8Efy/9xTFuj5S3KrJ7a7unrDlpqi2zNfg=; b=JXM0IJ9eJFh3Iui7iKHDesnbEuvHQFzUcH+329o6YrAehVz2IkgpEfS+krPmzLqrN0 S3ekAl6mj1wXJ3EBxgJY0WWxHOw8ChRQwvgOsZIZ+WeNYhvmllgtB/yFlbYoeHDBsTZP Rf9Yv96621hcCFDuWwnSmvpPO9K+g3ewYMVKM/HFQPv1t2JxJj2NXcOlKClXiwGH7hwD u1W5LNP7TsId8VXlaqKfTP8EvN3IPa+yUC+RqJCS0dwfaJHtt/C5TG2RyIeg3Lx+OEyK UyGPq4YhJ0rjvWzlOST+nWrfJpOn10Ej58rWXNlUGiZ7oYA2LPTr1LGgYF6g3eZ+XW11 ZNRw== 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=ONpdSjLbqp8Efy/9xTFuj5S3KrJ7a7unrDlpqi2zNfg=; b=Th8ZsXQY7Cea/MM03rfFAyIHyPyHLCeg8XQaoz/PUpCJf8sysIenWlojGLFZWkSf+s zEsNbnT9GPypIBs3tKz1SGufKP9hrwbDgIoqqlf+OpwMBEiRqZX+YKfJ0oB/m8X7W0OU urJk5lXAcnqPdy8mUVW71pI7xwWqaA187mqduA5mVWL3DSD8bA5CQS6ElhZ4qJZMINFe O0MHA5qldR2bw1mFTntcLp7AqUCyBR9uB+NWSCAhTW+DzAjDN9QsKoGncmkcEN4j6stC boVJoObaMd0j4HMKYc3cesnH+465Gbza8wcY4qxadyBiNFOY0ZqQ/210a7Q0XtMn4Ilu DZgg== X-Gm-Message-State: AA+aEWa0thyO6i8rHxtitAjE2KS7iwV5aLUuQqGo8PCYgNmsll0RwDWN ekIBVsZXkEKESaASqErRTRHgVeSqHblU+onst8MqbhrHbj4aQg== X-Google-Smtp-Source: AFSGD/USKtxK6/mZYn682s+EDpi1QsGBDyns5ojuey5GgEROsXV2sjq+cW9e4vAIj59jTaHXNYTZJAgu8hcZrE6ms/8= X-Received: by 2002:a19:3b9c:: with SMTP id d28mr4985138lfl.30.1544353827315; Sun, 09 Dec 2018 03:10:27 -0800 (PST) MIME-Version: 1.0 References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> <1333FFC2-A2F0-479D-8E7C-9ACFEC8E5724@lodderstedt.net> In-Reply-To: From: Vittorio Bertocci Date: Sun, 9 Dec 2018 03:10:15 -0800 Message-ID: To: David Waite Cc: Torsten Lodderstedt , Daniel Fett , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000491b9e057c94e560" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 09 Dec 2018 11:10:33 -0000 --000000000000491b9e057c94e560 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think we are running in circles. I am not talking about what provides should do in an ideal world, I am describing something that some providers do today that can impact developers in unintended ways if not take into account. We can agree that in the ideal world providers would take steps to fix the situation, and we should encourage to do so; but in the meanwhile if we don't warn people of those potential issues, some people might end up having issues. Let me try to rephrase one more time to see if I manage to explain the issue I am concerned about here. If you don't issue refresh tokens, the problem I am discussing doesn't occur hence we can ignore that case. I think that the point getting lost is: if you issue refresh tokens, per the longer description in my mail many widely adopted providers will issue refresh tokens whose validity doesn't end when the auth session from which they originated is disposed of. I am not debating whether that's the way it should be or not: it's a reality developers need to deal with today and that they are powerless to change overnight. The result is that if SPA apps are instructed to use refresh tokens as a way of getting new tokens, as opposed to the usual implicit trick, they'll now have a mean to get new tokens that is NOT tied to the session. Whereas with implicit every app relying on the auth session with the AS instantly loses the ability to call APIs, if developers use refresh tokens that aren't revoked with the session (and as established, with some providers they might not have a choice) they will have to perform explicit steps to probe whether the auth session is still ongoing, and dispose of the RTs themselves when it's not. I already suggested how I think this could be handled in the document: either not using RTs in the browser at all (for this potential problem, plus the lack of support for rotating RTs, plus the discussions about the difficulties storing them in XSS resistant fashion), or if we advise using RTs at least giving specific warnings about this scenario (making sure that the RTs issued by the provider of choice are session bound, and if they aren't suggest to developers to take measures like deleting RTs explicitly upon deletion of the auth session w the AS).(*) This doesn't absolve the providers from aligning their capabilities to the bar the scenario requires, but at least saves developers from introducing new issues in their apps as they move away from implicit. Some specific notes: >Note that the session cookie is fulfilling the role of the refresh token in the second case. Yep. That's what I was suggesting with only retrieving the code in the hidden browser and prompt=3Dnone for background renewals, no strict need fo= r RTs. Note that I'd *love* to be able to use RTs in the browser as it would work around the issues with ITP2; but it seems there are issues to iron out before they can be adopted mainstream, or at least more guidance is necessary than the one we've been giving so far. > Also note that telling a browser to discard the cookie is not as good as supporting revoking it - if there is no revocation mechanism, a third party who gets the cookie/refresh token can use it for as long as policy allows. Of course. I am not saying I don't want providers to support revocation, I am saying today some important ones do not today. The fact that the mitigation a developer can do when explicitly managing artifacts lifecycle isn't as good as the one the provider could eventually do doesn't mean it's worthless, especially when it's the only mitigation available. >I don=E2=80=99t expect application developers to use libraries that locall= y enforce more restrictive policy just because the operators of the AS aren= =E2=80=99t doing their job setting appropriate policy for their clients. So this is really more of something that the AS needs to understand about their own policy. I don't understand this. Put yourself in the shoes of a developer using one of those providers. For those developers, the feature set of their AS is an externality- like the weather. They can make feature requests, fill survey, send angry tweets- but if their entire codebase depend on tokens issued by the AS and that AS only issues RTs with offline_access semantic, knowing that the identirati don't agree with that limitation won't help them one bit to update their app to code flow from implicit. Given that there are things we can tell them (*) to either sidestep the problem altogether, or at least handle it, I am not sure I understand the pushback on providing that level of clarity. On Sun, Dec 9, 2018 at 12:57 AM David Waite wrote: > > > On Dec 8, 2018, at 8:27 PM, Vittorio Bertocci < > Vittorio=3D40auth0.com@dmarc.ietf.org> wrote: > > > Can you give a concrete example? To me it feels like you are explaining > scenarios where OAuth is used for login. > > That's one of the scenarios of interest here. We can debate on whether > that's proper or not, but the practical consequence is that if I have two > (or N) apps that can call APIs via tokens obtained with the implicit flow= , > eliminating AS the session cookie will prevent them from getting new toke= ns > automatically, without the developer having to write any code for "signou= t". > The moment in which apps switch to code and hold on to RTs, the sheer fac= t > that the AS session cookie is gone will NOT stop individual apps from bei= ng > able to get new access tokens and call API. > That would be an unintended consequence of the switch to code, and > regardless of whether it's a consequence of people abusing the protocol o= r > not, I think this scenario should be documented and people should be warn= ed > against it. > > > The AS is ultimately responsible for the security policy, though - if the > AS policy isn=E2=80=99t supposed to allow my application access after the= user hits > log out, it should either: > 1. Tie my application refresh tokens to be revoked at the logout event > 2. Not give out refresh tokens to my application > > Note that the session cookie is fulfilling the role of the refresh token > in the second case. Also note that telling a browser to discard the cooki= e > is not as good as supporting revoking it - if there is no revocation > mechanism, a third party who gets the cookie/refresh token can use it for > as long as policy allows. > > I don=E2=80=99t expect application developers to use libraries that local= ly > enforce more restrictive policy just because the operators of the AS aren= =E2=80=99t > doing their job setting appropriate policy for their clients. So this is > really more of something that the AS needs to understand about their own > policy. > > -DW > --000000000000491b9e057c94e560 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think we are running in circles. I am not talking about = what provides should do in an ideal world, I am describing something that s= ome providers do today that can impact developers in unintended ways if not= take into account. We can agree that in the ideal world providers would ta= ke steps to fix the situation, and we should encourage to do so; but in the= meanwhile if we don't warn people of those potential issues, some peop= le might end up having issues. Let me try to rephrase one more time to see = if I manage to explain the issue I am concerned about here.

If= you don't issue refresh tokens, the problem I am discussing doesn'= t occur hence we can ignore that case.
I think that the point getting l= ost is: if you issue refresh tokens, per the longer description in my mail = many widely adopted providers will issue refresh tokens whose validity does= n't end when the auth session from which they originated is disposed of= . I am not debating whether that's the way it should be or not: it'= s a reality developers need to deal with today and that they are powerless = to change overnight.
The result is that if SPA apps are instructe= d to use refresh tokens as a way of getting new tokens, as opposed to the u= sual implicit trick, they'll now have a mean to get new tokens that is = NOT tied to the session.
Whereas with implicit every app relying = on the auth session with the AS instantly loses the ability to call APIs, i= f developers use refresh tokens that aren't revoked with the session (a= nd as established, with some providers they might not have a choice) they w= ill have to perform explicit steps to probe whether the auth session is sti= ll ongoing, and dispose of the RTs themselves when it's not.=C2=A0

I already suggested how I think this could= be handled in the document: either not using RTs in the browser at all (fo= r this potential problem, plus the lack of support for rotating RTs, plus t= he discussions about the difficulties storing them in XSS resistant fashion= ), or if we advise using RTs at least giving specific warnings about this s= cenario (making sure that the RTs issued by the provider of choice are sess= ion bound, and if they aren't suggest to developers to take measures li= ke deleting RTs explicitly upon deletion of the auth session w the AS).(*)<= /div>
This doesn't absolve the providers from aligning their capabi= lities to the bar the scenario requires, but at least saves developers from= introducing new issues in their apps as they move away from implicit.


Some specific notes:

>Note that the session cookie is fulfilling the role of the refre= sh token in the second case.

Yep. That's what = I was suggesting with only retrieving the code in the hidden browser and pr= ompt=3Dnone for background renewals, no strict need for RTs.=C2=A0
Note that I'd *love* to be able to use RTs in the browser as it would= work around the issues with ITP2; but it seems there are issues to iron ou= t before they can be adopted mainstream, or at least more guidance is neces= sary than the one we've been giving so far.

> Also note that telling a browser to discard the cookie is= not as good as supporting revoking it - if there is no revocation mechanis= m, a third party who gets the cookie/refresh token can use it for as long a= s policy allows.

Of course. I am not saying I don&= #39;t want providers to support revocation, I am saying today some importan= t ones do not today. The fact that the mitigation a developer can do when e= xplicitly managing artifacts lifecycle isn't as good as the one the pro= vider could eventually do doesn't mean it's worthless, especially w= hen it's the only mitigation available.


>I don=E2=80=99t expect application developers to use libraries= that locally enforce more restrictive policy just because the operators of= the AS aren=E2=80=99t doing their job setting appropriate policy for their= clients. So this is really more of something that the AS needs to understa= nd about their own policy.

I don't understand = this. Put yourself in the shoes of a developer using one of those providers= . For those developers, the feature set of their AS is an externality- like= the weather. They can make feature requests, fill survey, send angry tweet= s- but if their entire codebase depend on tokens issued by the AS and that = AS only issues RTs with offline_access semantic, knowing that the identirat= i don't agree with that limitation won't help them one bit to updat= e their app to code flow from implicit. Given that there are things we can = tell them (*) to either sidestep the problem altogether, or at least handle= it, I am not sure I understand the pushback on providing that level of cla= rity.


On Sun, Dec 9, 2018 at 12:57 AM David Waite <david@alkaline-solutions.com> wrote:


On Dec= 8, 2018, at 8:27 PM, Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ie= tf.org> wrote:

> Can you give a concrete exampl= e? To me it feels like you are explaining scenarios where OAuth is used for= login.=C2=A0=C2=A0

That's one of the scenarios of interest here. We can debate on wh= ether that's proper or not, but the practical consequence is that if I = have two (or N) apps that can call APIs via tokens obtained with the implic= it flow, eliminating AS the session cookie will prevent them from getting n= ew tokens automatically, without the developer having to write any code for= "signout".
The moment in which apps sw= itch to code and hold on to RTs, the sheer fact that the AS session cookie = is gone will NOT stop individual apps from being able to get new access tok= ens and call API.
That would be an unintended con= sequence of the switch to code, and regardless of whether it's a conseq= uence of people abusing the protocol or not, I think this scenario should b= e documented and people should be warned against it.

The AS is ultimately responsible for the security policy, = though - if the AS policy isn=E2=80=99t supposed to allow my application ac= cess after the user hits log out, it should either:
1. Tie my app= lication refresh tokens to be revoked at the logout event
2. Not = give out refresh tokens to my application

Note tha= t the session cookie is fulfilling the role of the refresh token in the sec= ond case. Also note that telling a browser to discard the cookie is not as = good as supporting revoking it - if there is no revocation mechanism, a thi= rd party who gets the cookie/refresh token can use it for as long as policy= allows.

I don=E2=80=99t expect application develo= pers to use libraries that locally enforce more restrictive policy just bec= ause the operators of the AS aren=E2=80=99t doing their job setting appropr= iate policy for their clients. So this is really more of something that the= AS needs to understand about their own policy.

-D= W
--000000000000491b9e057c94e560-- From nobody Sun Dec 9 05:53:13 2018 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 314AE1293FB for ; Sun, 9 Dec 2018 05:53:12 -0800 (PST) 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=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 JeD_a6STSeHy for ; Sun, 9 Dec 2018 05:53:10 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 19B61126F72 for ; Sun, 9 Dec 2018 05:53:10 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id 189so5075388qkj.8 for ; Sun, 09 Dec 2018 05:53:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc:in-reply-to :references:user-agent; bh=axqDGjlezqfIPvUYSU4mbOWSVcje4xPLmMOemBdfocU=; b=E/shQV50ThvkY40dwmjK/sbMFiHn+cG/+CVyqzO9z+IqJoCvaZRioxk0T3eibvJAJX vFaHGQ/EWIPgLS7xpxOAfogrqMSv/L0MOZZypuAzOJLUKBbglNj0ZEAnk2g8m9PTBoZd 3faGwbMXj1SjzU74k7bzrlV2yRqQDNQNpANQxzmgEVqr47mmer2gfVKutYW6TY7xEnau EErhuXCvirDX165L662oEkp6/ArkFdgBY+pBYEbabZa7IyQ+KvL38P+qsfMHDJyJ/5p7 0o1OyFZj5bO3fbfC98fTB0J4DrNYSMq24Zzk2ntUhUlGGlY03JaaC0OLuECHBkJZF+ZA TBCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :in-reply-to:references:user-agent; bh=axqDGjlezqfIPvUYSU4mbOWSVcje4xPLmMOemBdfocU=; b=eIoaedriia72H1AYKEB6bvi3BIyzZ9e+WHyEixvWbYkIRV9SQhQUY0TxV/KiD6NNAI u1gEU549h6WSpJsZkvCNctCU/PO9LiSz95BT9fxchY8RcXQoIbEUq5rVJ0zl+mY9KC2E QJudZVAaNM5mJO5o1xNWSu6ecR5agE43Lnv9JnJ3+MEM8Porkd+YfytT605RuhT9xFWN xNKjFkgI/7BeyjPXMjMuFEDZ9u8ZYOlSQSXXG5yBwXnXd+dU8kJxMV0/ZNTE7fYYPE28 /sqmSzv54GqexX3R89yZ70rPqdul8Nrxe99G5JGt5/fkjtBjCkVFL6M1hflEkqNCLnMG Z5uw== X-Gm-Message-State: AA+aEWYljfGK8ZWIOAQi51U58XsTLj/nhkWjPGjdH1XJXESEZs/3hFHm sdqdapVtVvNdhIYQPsaM9MoBD1Kb X-Google-Smtp-Source: AFSGD/XnbdMawqrRpyNlXyRg+2/9YrPr3CWeIfR/X7QDFBkg8/vDNtG97WJ0myDm9fxSz7Bv0/8SBA== X-Received: by 2002:a37:10d4:: with SMTP id 81mr7597915qkq.19.1544363589119; Sun, 09 Dec 2018 05:53:09 -0800 (PST) Received: from [10.0.1.3] (pool-96-253-25-169.prvdri.fios.verizon.net. [96.253.25.169]) by smtp.gmail.com with ESMTPSA id b8sm6535415qka.79.2018.12.09.05.53.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Dec 2018 05:53:08 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_4475589.076596026533" MIME-Version: 1.0 Date: Sun, 09 Dec 2018 08:53:06 -0500 Message-ID: From: "Brock Allen" To: "David Waite" Cc: "Aaron Parecki" , "" In-Reply-To: References: <6d88c55a-a300-47ff-af77-8fdb7dcfbc25@getmailbird.com> User-Agent: Mailbird/2.5.24.0 X-Mailbird-ID: eeeed3ba-10d3-4b42-9da2-1460d13e4351@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps and response_type/fragment 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, 09 Dec 2018 13:53:12 -0000 ------=_NextPart_4475589.076596026533 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes, I meant response_mode. Thanks. And those are good points about the referrer policy. Thanks for that insigh= t as well.=C2=A0 In the context of this thread/topic, I'm assuming browser-based JS clients,= and a common deployment is from a CDN, so I suspect the tag approac= h for a referrer policy is sufficient (especially since many SPAs are desig= ned for CDN deployment)? -Brock On 12/9/2018 3:00:23 AM, David Waite wrote: I assume the original post meant response_mode, not response_type. Fragments have their own data leakage problems, in particular they are pres= erved on 3xx redirects (per=C2=A0https://tools.ietf.org/html/rfc7231#sectio= n-7.1.2 [https://tools.ietf.org/html/rfc7231#section-7.1.2]). The form_post= mode is the safest, but unfortunately was not defined in the original spec= ifications so it doesn=E2=80=99t have as widespread support. In the absence of a response_mode RFC, I would typically suggest both killi= ng the code in the referrer as part of processing, and a server-wide Referr= er Policy of never or origin (as those have reasonably broad support) as se= rver-wide response headers are easier to operationally audit. -DW On Dec 8, 2018, at 3:53 PM, Brock Allen wrote: Not pure OAuth. This only came up as a question while I was implementing co= de flow/pkce for oidc-client-js. I can appreciate not expanding the current OAuth2 behavior in the BCP, so t= hat's fair. I only wanted to mention it in case it had not been considered. Having said that, I think I will implement an optional response_type in my = code flow/pkce to allow fragment, but default to query (as that's the defau= lt for pure code flow). -Brock ------=_NextPart_4475589.076596026533 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A Yes, I me= ant response_mode. Thanks.

And those are good points abo= ut the referrer policy. Thanks for that insight as well. 
In the context of this thread/topic, I'm assuming browser-base= d JS clients, and a common deployment is from a CDN, so I suspect the <m= eta> tag approach for a referrer policy is sufficient (especially since = many SPAs are designed for CDN deployment)?

-Brock

=
=0A

On 12/9/2018 3:00:23 AM, David Waite <david@alkaline-= solutions.com> wrote:

I assume the original post meant response_mode, not = response_type.

Fragments have the= ir own data leakage problems, in particular they are preserved on 3xx redir= ects (per https://tools.ietf.org/html/rfc7231#section-7.1.2). The fo= rm_post mode is the safest, but unfortunately was not defined in the origin= al specifications so it doesn=E2=80=99t have as widespread support.

In the absence of a response_m= ode RFC, I would typically suggest both killing the code in the referrer as= part of processing, and a server-wide Referrer Policy of never or origin (= as those have reasonably broad support) as server-wide response headers are= easier to operationally audit.

-DW

On Dec 8, 2018, at 3:53 PM, Brock Allen <brockallen@gmail.com> = wrote:

=0A = =0A =0A = =0A =0A = =0A Not pu= re OAuth. This only came up as a question while I was implementing code flo= w/pkce for oidc-client-js.

I can appreciate not expanding the current OAuth2 behavior in the BCP= , so that's fair. I only wanted to mention it in case it had not been consi= dered.

Having sai= d that, I think I will implement an optional response_type in my code flow/= pkce to allow fragment, but default to query (as that's the default for pur= e code flow).

-Brock

=
=0A =0A =
------=_NextPart_4475589.076596026533-- From nobody Sun Dec 9 06:23:29 2018 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 E4366129A87 for ; Sun, 9 Dec 2018 06:23:27 -0800 (PST) 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=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 361GRoHmj_eF for ; Sun, 9 Dec 2018 06:23:26 -0800 (PST) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 147F31294D0 for ; Sun, 9 Dec 2018 06:23:26 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id a77so7009611oii.5 for ; Sun, 09 Dec 2018 06:23:26 -0800 (PST) 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=NK2IYJiGBL2dTA31nza3GkQ4BO6/ZTRQg2xqaHutNH8=; b=BNl3BH1ZRSpGeNz/lPKW5DoH37H23OhwdL7f0a/m3kWLMwxiFFnN3CTiPeHeBXj5TG W973jqYUE4G7RY5U5y/zocoqpV6ejWy2qR9VQ9UAqcO21nOnRpFIZApMPxqjCTv3MWlr /IN38IwJDtKaomJFhaYVVjEdy1Khnp+jDhZO4I5WKgeHSC2+nHRuucYRbU5mWeGGScJe upQoKskuqU9f03wUiccSkOUWiaVV0rZ5HKBKpp0g3cMWU84XKyoYVeIbmT7g8RSbA0Ay 8+qymaPPFY1sH0QRmHYuorgXExIS3NXBTBYu0Jo0ZjgNmbWcELh3E1EyLTKe9KSpdnwx fNPw== 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=NK2IYJiGBL2dTA31nza3GkQ4BO6/ZTRQg2xqaHutNH8=; b=TzhEeNc+auOfXrlJ+DmpBrwBcDvIFfIEIXEml7sSFyQkdkda8tCeFw+zB4gfVdFwCL IyENTgHJ7rKBsY7Jn+OscMBwiOIch/40JvpnegAqXkshTvpHj1rg4vqHLT7ikB8yNFzC RmLTWVTkvT3YzhGB5ngwwd8ogFTYFnO4ebQFyfOs5689xraeVEWfeyTFfoPo+rdA5mIm hubDz5ceE2AgLhmK0A57JZM3SIeJBifhmUQQBlu5EOaqecI0MFilUpyRfIgJY9SX+SOo e/gj2Bb1h0KlRxrcn5NmVXNtjuaDo/OxpVvlMcb9+bHkY2QekMSRfij1gL/DERvaZcxh T2tA== X-Gm-Message-State: AA+aEWbC+nyEZy2/5BgclYV/3mhtspjFXhgYbds2XLc0mlcFCJSpfxqW gMiK8XBKWE66fyWu6YKCwiZZLO0EmPHkRLGM6w== X-Google-Smtp-Source: AFSGD/VO34dANc2wPtwzCfFeYf/rZ37zVMv0DBySyd8lhgD/e2qe0/i9rEIzZL/iudGVxOml2uVHsg68LIMHJjrtvxE= X-Received: by 2002:aca:60c1:: with SMTP id u184mr5614032oib.45.1544365405178; Sun, 09 Dec 2018 06:23:25 -0800 (PST) MIME-Version: 1.0 References: <6d88c55a-a300-47ff-af77-8fdb7dcfbc25@getmailbird.com> In-Reply-To: From: Filip Skokan Date: Sun, 9 Dec 2018 15:23:13 +0100 Message-ID: To: Brock Allen Cc: david@alkaline-solutions.com, oauth Content-Type: multipart/alternative; boundary="000000000000610f67057c979762" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps and response_type/fragment 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, 09 Dec 2018 14:23:28 -0000 --000000000000610f67057c979762 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As David suggested, it is easier to get rid of the code from a query using a referrer policy header or a meta than getting rid of a fragment which would require the each client to have a javascript snippet rewriting the current window.location.hash S pozdravem, *Filip Skokan* On Sun, Dec 9, 2018 at 2:53 PM Brock Allen wrote: > Yes, I meant response_mode. Thanks. > > And those are good points about the referrer policy. Thanks for that > insight as well. > > In the context of this thread/topic, I'm assuming browser-based JS > clients, and a common deployment is from a CDN, so I suspect the t= ag > approach for a referrer policy is sufficient (especially since many SPAs > are designed for CDN deployment)? > > -Brock > > On 12/9/2018 3:00:23 AM, David Waite wrote= : > I assume the original post meant response_mode, not response_type. > > Fragments have their own data leakage problems, in particular they are > preserved on 3xx redirects (per > https://tools.ietf.org/html/rfc7231#section-7.1.2). The form_post mode is > the safest, but unfortunately was not defined in the original > specifications so it doesn=E2=80=99t have as widespread support. > > In the absence of a response_mode RFC, I would typically suggest both > killing the code in the referrer as part of processing, and a server-wide > Referrer Policy of never or origin (as those have reasonably broad suppor= t) > as server-wide response headers are easier to operationally audit. > > -DW > > On Dec 8, 2018, at 3:53 PM, Brock Allen wrote: > > Not pure OAuth. This only came up as a question while I was implementing > code flow/pkce for oidc-client-js. > > I can appreciate not expanding the current OAuth2 behavior in the BCP, so > that's fair. I only wanted to mention it in case it had not been consider= ed. > > Having said that, I think I will implement an optional response_type in m= y > code flow/pkce to allow fragment, but default to query (as that's the > default for pure code flow). > > -Brock > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000610f67057c979762 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As David suggested,

it is ea= sier to get rid of the code from a query using a referrer policy header or = a meta than getting rid of a fragment which would require the each client t= o have a javascript snippet rewriting the current window.location.hash
S pozdravem,
Filip Skokan
<= br>

On Sun, Dec 9, 201= 8 at 2:53 PM Brock Allen <brocka= llen@gmail.com> wrote:
=20 =20 =20 =20 =20 Yes, I meant response_mode. Thanks.=

And those are good points about the referrer policy. Th= anks for that insight as well.=C2=A0

In the contex= t of this thread/topic, I'm assuming browser-based JS clients, and a co= mmon deployment is from a CDN, so I suspect the <meta> tag approach f= or a referrer policy is sufficient (especially since many SPAs are designed= for CDN deployment)?

-Brock=

On 12/9/2018 3:00:23 AM, David Waite <david@alkaline-solutions.com> wrote= :

I assume th= e original post meant response_mode, not response_type.

Fragments have their own data leakage problems, in particular they are pre= served on 3xx redirects (per=C2=A0https://tools.ietf.org/html/rfc7231#= section-7.1.2). The form_post mode is the safest, but unfortunately was= not defined in the original specifications so it doesn=E2=80=99t have as w= idespread support.

In the absence of a response_mode RFC= , I would typically suggest both killing the code in the referrer as part o= f processing, and a server-wide Referrer Policy of never or origin (as thos= e have reasonably broad support) as server-wide response headers are easier= to operationally audit.

-DW

On Dec 8, 2018, at 3:53 PM, Brock Allen <brockallen@gmail.com= > wrote:

=20 =20 =20 =20 =20 Not pure OAuth. This only came up a= s a question while I was implementing code flow/pkce for oidc-client-js.
I can appreciate not expanding the current OAuth2 behavior= in the BCP, so that's fair. I only wanted to mention it in case it had= not been considered.

Having said that, I think I = will implement an optional response_type in my code flow/pkce to allow frag= ment, but default to query (as that's the default for pure code flow).<= br>

-Brock

=20
_______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000610f67057c979762-- From nobody Sun Dec 9 07:22:31 2018 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 3A41C130EF2 for ; Sun, 9 Dec 2018 07:22:30 -0800 (PST) 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, MIME_QP_LONG_LINE=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=manicode.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 wCN7fO1pT8Eq for ; Sun, 9 Dec 2018 07:22:28 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 047751277BB for ; Sun, 9 Dec 2018 07:22:27 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id q70so5158788qkh.6 for ; Sun, 09 Dec 2018 07:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n8C5piO0jRytsPelYU0K/nIP8IJQ4A+SrMrbwO6N9Ts=; b=Wiqm3moHIVQhgXrGyRb6QdLGn3Mw7YapAmgOTqg6wPKjKJtPMRqnFaozE3Z98vZz44 kaCYBbWD5CisEhmP4NzGhJFC94jHK/zJZkLKGt5H/FlU96xUwR1P+b90gLH5342kk4yY 7/T/IL3tHgWH6IAT+AvVtgiJh63EvkOI07EWUdtgR+owILQ2OAqexMpseOqEeSihEghw uISvE/qftMZWu45j4IRBwQ6IsldB1oQDcG2XlWebdTY1XuBhikY3KbrncSSXYOvEmsjA PTaNUBXUpkIdv7TqJfY1WaOxHIbgLqqcSvNdu7vEQupwcC1ImCtkLDNa9MqMebEjxhyy zcMA== 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=n8C5piO0jRytsPelYU0K/nIP8IJQ4A+SrMrbwO6N9Ts=; b=AhQRJILrCBAHowEWDp1NFx+LBs7wciHVrR9KDEiWpJ/hiDWseNXJLpDxS9PEkWXoaI DtKzE6vOXFv9s8hMnfnInBOHSXwbml4X4Qf613HUY112vk6l2s0eZzgoX2M2D7WYGh/v IJSu48EJxNdfqTYmoJ0El6guJG+VgIo4Bxc6kcJhyV8gDpFiLqD11HgpsG5tpbfAEkY+ LPvFu9n2NIsWG/7ohk874jtY6OFRiLVlgm8zl+yAdMiM8iQYfUoCEuc0wveKO/mLY1c4 McVHp0iuh5KttDPWKgpITSXzX5BK3qe7Y3cuRlbbkY9qPkHL+2hkQtWb41iREfa6X3X2 xPqg== X-Gm-Message-State: AA+aEWawEsYR4iVFhArf2rUwWhiIFjhEv5dj9mywCCNEdZrVf68KGPtR wHXj5y5rs4DdKk6+DqT2VGLU9w== X-Google-Smtp-Source: AFSGD/VGxvmNsTb+4M0CQ7FfE15Dp/pfNTueRqDsPVNn+VtWEbpeRT82bRM5yihdJPyjySihOa2+Bw== X-Received: by 2002:ae9:ef8a:: with SMTP id d132mr7924730qkg.11.1544368946782; Sun, 09 Dec 2018 07:22:26 -0800 (PST) Received: from [10.38.127.203] (mobile-107-107-56-28.mycingular.net. [107.107.56.28]) by smtp.gmail.com with ESMTPSA id p42sm5372082qte.8.2018.12.09.07.22.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Dec 2018 07:22:25 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-2C358F33-D4D2-42C8-AE38-EDD715676A5E Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (16C50) In-Reply-To: Date: Sun, 9 Dec 2018 10:22:24 -0500 Cc: Brock Allen , oauth Content-Transfer-Encoding: 7bit Message-Id: <4EF1B845-FDDA-4E2A-8F5F-8F9620484885@manicode.com> References: <6d88c55a-a300-47ff-af77-8fdb7dcfbc25@getmailbird.com> To: Filip Skokan Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps and response_type/fragment 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, 09 Dec 2018 15:22:30 -0000 --Apple-Mail-2C358F33-D4D2-42C8-AE38-EDD715676A5E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Please keep in mind that these referrer removing standards are relatively ne= w and do not work in older browsers. Sensitive data of any kind in URL=E2=80= =99s is still a very basic insecure coding practice and has no place in stan= dards. Check out caniuse for how fractured support is for even modern browse= rs. IE, Edge and Safari iOS still have only partial support. -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On Dec 9, 2018, at 9:23 AM, Filip Skokan wrote: >=20 > As David suggested, >=20 > it is easier to get rid of the code from a query using a referrer policy h= eader or a meta than getting rid of a fragment which would require the each c= lient to have a javascript snippet rewriting the current window.location.has= h >=20 > S pozdravem, > Filip Skokan >=20 >=20 >> On Sun, Dec 9, 2018 at 2:53 PM Brock Allen wrote: >> Yes, I meant response_mode. Thanks. >>=20 >> And those are good points about the referrer policy. Thanks for that insi= ght as well.=20 >>=20 >> In the context of this thread/topic, I'm assuming browser-based JS client= s, and a common deployment is from a CDN, so I suspect the tag approa= ch for a referrer policy is sufficient (especially since many SPAs are desig= ned for CDN deployment)? >>=20 >> -Brock >>=20 >>> On 12/9/2018 3:00:23 AM, David Waite wrot= e: >>>=20 >>> I assume the original post meant response_mode, not response_type. >>>=20 >>> Fragments have their own data leakage problems, in particular they are p= reserved on 3xx redirects (per https://tools.ietf.org/html/rfc7231#section-7= .1.2). The form_post mode is the safest, but unfortunately was not defined i= n the original specifications so it doesn=E2=80=99t have as widespread suppo= rt. >>>=20 >>> In the absence of a response_mode RFC, I would typically suggest both ki= lling the code in the referrer as part of processing, and a server-wide Refe= rrer Policy of never or origin (as those have reasonably broad support) as s= erver-wide response headers are easier to operationally audit. >>>=20 >>> -DW >>>=20 >>>> On Dec 8, 2018, at 3:53 PM, Brock Allen wrote: >>>>=20 >>>> Not pure OAuth. This only came up as a question while I was implementin= g code flow/pkce for oidc-client-js. >>>>=20 >>>> I can appreciate not expanding the current OAuth2 behavior in the BCP, s= o that's fair. I only wanted to mention it in case it had not been considere= d. >>>>=20 >>>> Having said that, I think I will implement an optional response_type in= my code flow/pkce to allow fragment, but default to query (as that's the de= fault for pure code flow). >>>>=20 >>>> -Brock >>>=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-2C358F33-D4D2-42C8-AE38-EDD715676A5E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Please keep in mind that these referrer rem= oving standards are relatively new and do not work in older browsers. Sensit= ive data of any kind in URL=E2=80=99s is still a very basic insecure coding p= ractice and has no place in standards. Check out caniuse for how fractured s= upport is for even modern browsers. IE, Edge and Safari iOS still have only p= artial support.

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

On Dec 9, 2018, at 9= :23 AM, Filip Skokan <panva.ip@gmai= l.com> wrote:

As David suggested,

it is ea= sier to get rid of the code from a query using a referrer policy header or a= meta than getting rid of a fragment which would require the each client to h= ave a javascript snippet rewriting the current window.location.hash
S pozdravem,
Filip Skokan


On Sun, Dec 9, 2018 at 2:= 53 PM Brock Allen <brockallen@gma= il.com> wrote:
=20 =20 =20 =20 =20 Yes, I meant response_mode. Thanks.<= div>
And those are good points about the referrer policy. Than= ks for that insight as well. 

In the context o= f this thread/topic, I'm assuming browser-based JS clients, and a common dep= loyment is from a CDN, so I suspect the <meta> tag approach for a refe= rrer policy is sufficient (especially since many SPAs are designed for CDN d= eployment)?

-Brock
=

= On 12/9/2018 3:00:23 AM, David Waite <david@alkaline-solutions.com> wrote:

I assume the or= iginal post meant response_mode, not response_type.

Frag= ments have their own data leakage problems, in particular they are preserved= on 3xx redirects (per https://tools.ietf.org/html/rfc7231#section-= 7.1.2). The form_post mode is the safest, but unfortunately was not defi= ned in the original specifications so it doesn=E2=80=99t have as widespread s= upport.

In the absence of a response_mode RFC, I would ty= pically suggest both killing the code in the referrer as part of processing,= and a server-wide Referrer Policy of never or origin (as those have reasona= bly broad support) as server-wide response headers are easier to operational= ly audit.

-DW

On Dec 8, 2018, at 3:53 PM, Brock Allen <brockallen@gmail.com> wrote:
<= div id=3D"gmail-m_4397347040143535969__MailbirdStyleContent" style=3D"font-s= ize:10pt;font-family:"Lucida Console""> =20 =20 =20 =20 =20 Not pure OAuth. This only came up as= a question while I was implementing code flow/pkce for oidc-client-js.
=
I can appreciate not expanding the current OAuth2 behavior in= the BCP, so that's fair. I only wanted to mention it in case it had not bee= n considered.

Having said that, I think I will impl= ement an optional response_type in my code flow/pkce to allow fragment, but d= efault to query (as that's the default for pure code flow).

-Brock

=20
________________________= _______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-2C358F33-D4D2-42C8-AE38-EDD715676A5E-- From nobody Sun Dec 9 08:53:16 2018 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 EA30C126BED for ; Sun, 9 Dec 2018 08:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.76 X-Spam-Level: X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 Duj_jnKGl6VR for ; Sun, 9 Dec 2018 08:53:13 -0800 (PST) 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 34F3B124D68 for ; Sun, 9 Dec 2018 08:53:12 -0800 (PST) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wB9Gi8JX174245; Sun, 9 Dec 2018 16:53:10 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-2018-07-02; bh=DG5AmI+gZZXH22u2uXcN1zTaa1I8QdHpubpJD4Kc8ew=; b=tWhi6X3W2+FZ1mogAYNfPymgTJhhiM+UWKB9WDTxHTwHhTlEPKuvDV1l+vzT0YBe9wws Bzs19Co74kJJJUIkd2Rg921lKhIG00OAk6UevjLVyEHg+V2XeRQ41ecNMfqkE5vJJn3E H/l7wkcgvAxdNh/03E5tCtajJOR9G/m+CNrJkZ5CWHRwlLIzeNP8zpylD6ARcJZxWqkK DokKppuv4HJ4odhagScJLr9fOjOSMF/Z7NkFZhlbp62OC2iScS7G7JO9/Low0+E3ftNw exl5zYv462yYsTWO8kvSbx7+Dy2FBUY3Pdk8OwgvQeg/NO+09qjHAz9rNjBWuOAAWIvD TQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2p86kqjqwe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 09 Dec 2018 16:53:10 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wB9Gr9hu004748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 9 Dec 2018 16:53:09 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wB9Gr9Hb023444; Sun, 9 Dec 2018 16:53:09 GMT Received: from [192.168.1.27] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 09 Dec 2018 08:53:08 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-21F35BE9-0CFF-4651-9D25-A870A61470BA Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Sun, 9 Dec 2018 08:53:03 -0800 Cc: David Waite , oauth@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <458858450.1398445.1543913404101@mail.yahoo.com> <9DF33F99-E78A-4197-BCEA-AC715761FE87@lodderstedt.net> <942315098.1664424.1543946581453@mail.yahoo.com> <1316266210.2176632.1544020051230@mail.yahoo.com> <468E0532-1B5D-4116-B930-A9B8AB7CDA5A@lodderstedt.net> <693F457E-3B0F-4612-AE3B-D18462055932@lodderstedt.net> <194886B0-D8C8-4489-B66B-7993C7FA0F63@lodderstedt.net> <1D4D8636-9C50-4AA0-BF33-3427FCD0E938@oracle.com> <9E0E2FD0-ECE7-4A71-870B-21938B8C267F@alkaline-solutions.com> <8A2BC516-69AA-4CDB-A31E-5AF59FBA9CF0@oracle.com>! To: Brock Allen X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9102 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=862 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812090155 Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 09 Dec 2018 16:53:15 -0000 --Apple-Mail-21F35BE9-0CFF-4651-9D25-A870A61470BA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Yes. This was my worry.=20 Unless the oauth server is also an OIDC OP, it has no notion the user login s= tate. That state is held in cookies belonging to a federated provider.=20 The notion that javascript acting as a client and depends to the user login s= tate is what sets these cases apart. We have to be able to co-ordinate betw= een resource api, AS authorization which builds off of some form of federati= on/sso.=20 Phil > On Dec 8, 2018, at 6:51 PM, Brock Allen wrote: >=20 > > How would the token endpoint detect login status of the user? >=20 > Oddball idea: why not use the cookie? If the assumption is that the RT is b= eing used from a client-side browser-based app, and CORS allows for credenti= als, then perhaps this is a way to bind the RT to the user's browser session= . The spec does say that alternative credentials are allowed at the token en= dpoint... >=20 > Sounds icky, but compared to iframes back to the authorize endpoint? >=20 > -Brock >=20 --Apple-Mail-21F35BE9-0CFF-4651-9D25-A870A61470BA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Yes. This was my worry. 

Unless the oauth server is also an OIDC OP, it has no notion the user login state. That state is held in cookies belonging to a federated provider. 

The notion that javascript acting as a client and depends to the user login state is what sets these cases apart.  We have to be able to co-ordinate between resource api, AS authorization which builds off of some form of federation/sso. 

Phil

On Dec 8, 2018, at 6:51 PM, Brock Allen <brockallen@gmail.com> wrote:

> How would the token endpoint detect login status of the user?

Oddball idea: why not use the cookie? If the assumption is that the RT is being used from a client-side browser-based app, and CORS allows for credentials, then perhaps this is a way to bind the RT to the user's browser session. The spec does say that alternative credentials are allowed at the token endpoint...

Sounds icky, but compared to iframes back to the authorize endpoint?

-Brock

--Apple-Mail-21F35BE9-0CFF-4651-9D25-A870A61470BA-- From nobody Sun Dec 9 13:20:39 2018 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 92CEA128B14 for ; Sun, 9 Dec 2018 13:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_SINGLE_WORD=2.351, 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=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 HyvoUk7zv78z for ; Sun, 9 Dec 2018 13:20:36 -0800 (PST) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 A5610128AFB for ; Sun, 9 Dec 2018 13:20:36 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id y23so7472196oia.4 for ; Sun, 09 Dec 2018 13:20:36 -0800 (PST) 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=OLpo/cgNC3Gm8AUh/2qsUAZHtm41saNHtD6DZfjnzIY=; b=OE0IrPVLXQMLWIfSyPlKVu2fWo7SLue2ReYRHUbMazXLaXhXGAqvD3fgI6wQrSM9X/ KOZ1jGtC8FpKD9fMfwoZzp9h/s4R7Gn2TZTiDZQCtmkmhEQgktsgxB56tfyc4aFJwdvc M2+cH+JUgiQAaktR/UetH5TSyUuNjmRn6t4GIjy1QKAedfFPHsi/ura9yQRZzV1+h/JM RQ4bzRM+PHeO1tcxEfj9B3M9HEQwfIiesgn2sKgistnKBIR1NzufS5qgu8Zf3h3cvSTX TDNvhLrzWSH+XxcdE9WYb+vznibdF71xMxLMODElbgtpj68/SWlnpRtSxUVXBKq4Ux/Z /0tA== 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=OLpo/cgNC3Gm8AUh/2qsUAZHtm41saNHtD6DZfjnzIY=; b=Yy6SRfFPfSQGVFwbEeS5QicxxTM8vUAV4zmqgGdihGvOta8ytRwChafKXqjEqf58Fm exQdg5Hz4Epg+lMM4YRjkMApxmScxlieC0rCw8nL9+weLB1ajQhdlvDcnl2m/EuyqJOk k14YuWLAbs+PWXTcy9saA3F5cAm7TQuPQm19HTlE+s8MkyLuP6cRb5jMS/aHF8wfxLYy TLEiqEVcflHS8EBIfr1RgdiYuWh/0f5LJqipTLs+txfXP8MHvD0IHWne+uPkfzmObX+V JKnH9DHhTUiwTdCBTN3eGnh3ZH+xab1hAyDVkkYk4VLHVexoTqsKKQNxtC9HLOsLX1Hc ytEQ== X-Gm-Message-State: AA+aEWb3RQzCtU7kg1NMPnJXI99mzkSS4AunVE3pc0Vl3tLMKDEy5vzI Pb/xA+iEdzBD4CDNIZtHA7EDZJi6gFUSTGe49JrvSgMv X-Google-Smtp-Source: AFSGD/UhyTE17n93ScG3ZUbUIX4UjiFj/QrvyUIdQXPJrvEJ3xRqY6VU/r86L8A+lEwP85/RF9q6kv1WFIZEI3xmdMw= X-Received: by 2002:aca:adcd:: with SMTP id w196mr6292855oie.353.1544390435644; Sun, 09 Dec 2018 13:20:35 -0800 (PST) MIME-Version: 1.0 From: Chef Saroar Date: Mon, 10 Dec 2018 03:20:22 +0600 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000004fa857057c9d6b7a" 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: Sun, 09 Dec 2018 21:20:38 -0000 --0000000000004fa857057c9d6b7a Content-Type: text/plain; charset="UTF-8" Yes --0000000000004fa857057c9d6b7a Content-Type: text/html; charset="UTF-8"
Yes
--0000000000004fa857057c9d6b7a-- From nobody Mon Dec 10 10:03:39 2018 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 E096A1310B4 for ; Mon, 10 Dec 2018 10:03:37 -0800 (PST) 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_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 XlbGF5bwYDXe for ; Mon, 10 Dec 2018 10:03:35 -0800 (PST) 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 A08311310A7 for ; Mon, 10 Dec 2018 10:03:35 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id f14so9515985iol.4 for ; Mon, 10 Dec 2018 10:03:35 -0800 (PST) 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=qmyZZOa2jNVhqot7qkWIfS+ZeCW3BAM9tDKpptktW5I=; b=ay28vdYmHUTR/31zds3975DKrHJ1RMKOjItbZfAFGdjprSqLDpKip0aWf3sGsP1G9Y wmCArDBPWIVXgfmS8xY10C8LVxnmVFJqZYKZsvxL9Pzk4gkvVFBvXavzTS/okZABmh5H mrzFCEFqnLKGENgvaAHNCmGqoR++aviHBI75I= 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=qmyZZOa2jNVhqot7qkWIfS+ZeCW3BAM9tDKpptktW5I=; b=IBlg6CUVRQPS8Sab43kOD8VMyi4bNEXmDt+k+mYYI3EADPqg5IWHiZES2ZKK8dHAvm F3nkmcOdnCFfaEPvlB/xXjnCf4qoILPPpNVJk++do+f1bZmFka+en7Er2gAh0hk5mMa8 uV3keIIugXtqiBjaCQXFDJBWPfnvCAZn8RrCV8Uv/alrVtQnfqq241hBdx1VXLxwtKKw E4YYcvxRLLLcLL5TMMRFu++MwN3qVqDmBeGN9R1QTCMD2ES33Z7FuFOowOzQSx87orYb HWKatMASc2yLJOLX0P6sHH45N4+2g9HvkIzmC2wiPdPurd+o200BfrZ9lu27gyszdgm/ lUnw== X-Gm-Message-State: AA+aEWZgekPtI3hfvAsqUEwcE6jv39S53ydxz2k5OLa3yDQmL3HoFVUJ +4/xs3lR/PbXKGyBs0LYp7d+F6FP6yZbg78rFVwwymxtximRvcZ+/luPeqPcOj2dUEnDKoioCes DsLpylZasUR7mHxWx X-Google-Smtp-Source: AFSGD/X5QwPoqL8ktoLzQ6vYBcy6/QVIXlrpcvnQTI1FGYJDp3nCrGCsdJqdBuNmut87RT5YWqlXEz3u7YPMcZYg6LQ= X-Received: by 2002:a6b:6e17:: with SMTP id d23mr9311363ioh.138.1544465014857; Mon, 10 Dec 2018 10:03:34 -0800 (PST) MIME-Version: 1.0 References: <6d88c55a-a300-47ff-af77-8fdb7dcfbc25@getmailbird.com> In-Reply-To: From: Brian Campbell Date: Mon, 10 Dec 2018 11:03:08 -0700 Message-ID: To: Aaron Parecki Cc: Brock Allen , oauth Content-Type: multipart/alternative; boundary="000000000000944214057caec85d" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps and response_type/fragment 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, 10 Dec 2018 18:03:38 -0000 --000000000000944214057caec85d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For what it's worth, the response_mode parameter is defined in OAuth 2.0 Multiple Response Type Encoding Practices , which is an OIDF document but not strictly part of OIDC so it can be used and referenced as an extension of OAuth without going fully OIDC. One of the purported benefits of fragment encoding was that it allowed for the redirect uri request to be served from browser cache. On Sat, Dec 8, 2018 at 11:58 AM Aaron Parecki wrote: > Do you know of anyone currently doing this today in an OAuth-only > application? > > If the group wanted to take some existing OIDC mechanisms and apply them > to OAuth, I feel like that needs to happen in a separate RFC, and that's = a > much bigger discussion. This BCP shouldn't really be defining new behavio= r. > It's similar to how "OAuth 2.0 for Mobile and Native Apps" is not where > PKCE is defined, PKCE has its own RFC. > > - Aaron > > > > On Sat, Dec 8, 2018 at 10:33 AM Brock Allen wrote: > >> For the same reason the implicit flow uses it -- to reduce exposure of >> the response params. I know the code is protected with the >> code_verifier, but it wouldn't hurt to reduce its exposure, no? >> >> -Brock >> >> On 12/8/2018 1:23:41 PM, Aaron Parecki wrote: >> What would be the benefit of using this response type? Are you aware of >> any OAuth (not OIDC) clients that do this today? >> >> - Aaron >> >> >> On Sat, Dec 8, 2018 at 7:29 AM Brock Allen wrote: >> >>> Should the BCP suggest using OIDC's response_type=3Dfragment as the >>> mechanism for returning the code from the AS? Or simply suggest using t= he >>> fragment component of the redirect_uri for the code, without a >>> response_type parameter (IOW don't allow it to be dynamic)? >>> >>> -Brock >>> >>> _______________________________________________ >>> 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 > --=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._ --000000000000944214057caec85d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For what it's worth,= the response_mode parameter is defined in OAuth 2.0 = Multiple Response Type Encoding Practices, which is an OIDF document bu= t not strictly part of OIDC so it can be used and referenced as an extensio= n of OAuth without going fully OIDC.

<= div>One of the purported benefits of fragment encoding was that it allowed = for the redirect uri request to be served from browser cache.

On Sat, Dec 8, 201= 8 at 11:58 AM Aaron Parecki <aaron@parecki.com> wrote:
Do you know of anyone currently doing this today= in an OAuth-only application?

If the group wanted to take som= e existing OIDC mechanisms and apply them to OAuth, I feel like that needs = to happen in a separate RFC, and that's a much bigger discussion. This = BCP shouldn't really be defining new behavior. It's similar to how = "OAuth 2.0 for Mobile and Native Apps" is not where PKCE is defin= ed, PKCE has its own RFC.

- Aaron



O= n Sat, Dec 8, 2018 at 10:33 AM Brock Allen <brockallen@gmail.com> wrote:
=
=20 =20 =20 =20 =20 For the same reason the implicit fl= ow uses it -- to reduce exposure of the response params. I know the code=C2= =A0is protected with the cod= e_verifier, but it wouldn't hurt to reduce its exposure, no?

-Brock=

On 12/8/= 2018 1:23:41 PM, Aaron Parecki <aaron@parecki.com> wrote:

What would be the benef= it of using this response type? Are you aware of any OAuth (not OIDC) clien= ts that do this today?

- Aaron


On Sat, Dec 8, 2018 at = 7:29 AM Brock Allen <brockallen@gmail.com> wrote:
Should the BCP suggest using OI= DC's response_type=3Dfragment as the mechanism for returning the code f= rom the AS? Or simply suggest using the fragment component of the redirect_= uri for the code, without a response_type parameter (IOW don't allow it= to be dynamic)?

-Brock

= _______________________________________________
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

<= 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. --000000000000944214057caec85d-- From nobody Tue Dec 11 10:21:41 2018 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 6E0BC130EF1 for ; Tue, 11 Dec 2018 10:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 QJ5CiVEGozYY for ; Tue, 11 Dec 2018 10:21:38 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 39E6F130EDF for ; Tue, 11 Dec 2018 10:21:38 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id b5so5449839iti.2 for ; Tue, 11 Dec 2018 10:21:38 -0800 (PST) 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=iVzx1ovfQQuXMw2wrmzKa5OU3OMDVMF7irbZljJDYYo=; b=FL+V+ddVN0jUYzSkNx6RuSjBjQXvr5cQALLRVnn6GgHnMGzNZZFqSBS92hvVtMY9Rd B0r5ycl93XMOkm3Ee1Tpkdd4qXz9ZN6JaWpq+KePQf/P2CgY8eAwcaULKtn+EOY+MDtR RRFrmbSEQIvSV1e2795bEQXwVpunhajzT7jmo= 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=iVzx1ovfQQuXMw2wrmzKa5OU3OMDVMF7irbZljJDYYo=; b=b9GviiLonWDDqI4yHsurDRyva92CZNzCmMArGafZzFBeqxLyPtviEuVt0hJtUwneEt MEnklYwugCcsiBumRkCZCoV+fNEAXNGa4aKlvZDmt7B9C1Y9Nn5xDW/aFY6VDDuC8r3T 3JfA0sKjmiQgx0hDH6adFrHNEUJukqLEt6/leNh8uVOfzzLQDEKBwUEHGaZt4Y+WtkNn DHKF5aCbppt/u8NaMzvhACKNac1ebI15ITb0I4oNUW19VljhqV7dn9Whg+KFf2N8IqZu Q/yCTj+vRcmnZ1+n6JnOKmAByLaCZL1r2fWIIVMp7+5CDCfGXRCYrutRsbxrr2ZlJE4/ dr0g== X-Gm-Message-State: AA+aEWbbEjhg7NL3m/etEh1FWWW9CFqhpTXSoUb6h3c5AR7iNqPBk5gK FgspjZdYngHmdNCmvE4Ybglq77QyY7GMG3R7CI//5iuvAJzn+hRvyH3jWqwiY9RiXtwCfdkXmd7 UW2bwcvDJyj/rHg== X-Google-Smtp-Source: AFSGD/UwYHxK4Zo1BFTdb17Lz6kcpHZFWvXuj+9GESFn6TCxWNgFD/Er+lv+4lU+avJKF9ZWjZEckXaKdW8bwRTiLIc= X-Received: by 2002:a02:5f9d:: with SMTP id x29mr17350767jad.28.1544552497273; Tue, 11 Dec 2018 10:21:37 -0800 (PST) MIME-Version: 1.0 References: <1544038181.296618.1600075520.5A927769@webmail.messagingengine.com> In-Reply-To: <1544038181.296618.1600075520.5A927769@webmail.messagingengine.com> From: Brian Campbell Date: Tue, 11 Dec 2018 11:21:10 -0700 Message-ID: To: ietf@lists.joshka.net Cc: oauth Content-Type: multipart/alternative; boundary="000000000000f0142c057cc32602" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-token-exchange comments (RESTful / OIDC claims) 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, 11 Dec 2018 18:21:40 -0000 --000000000000f0142c057cc32602 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The OAuth framework itself isn't particularly RESTful so it's not really specific to token exchange. This document just makes mention of it in the context of talking about the shift from XML/SOAP/WS* to JSON/HTTP as one of the motivations for its existence. There's nothing precluding sending additional parameters. In general, OAuth says to ignore unrecognized parameters, which allows for extensions or proprietary additions. On Wed, Dec 5, 2018 at 12:29 PM Josh McKinney wrote= : > Hiya, > > In section 1: > > The STS > protocol defined in this specification is not itself RESTful (an STS > doesn't lend itself particularly well to a REST approach) but does > utilize communication patterns and data formats that should be > familiar to developers accustomed to working with RESTful systems. > > A colleague expressed concern that token exchange can not be RESTful. > Given that the token exchange endpoint defined here is the same as the > token endpoint, is this a restatement that this endpoint itself is not > RESTful as opposed to a different change. AFAICT, none of the other OAuth > RFCs mention RESTful concerns. > > In Section 2.1: > Regarding exchanging an access token for an id token, OIDC allows the > caller to provide a claims parameter to specify the specific claims > returned in an id token. See > https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter > I'm not sure that this spec explicitly constrains parameters to be passed > to this method, but it also doesn't have any language to suggest that it > will allow extended parameter lists to be passed and interpreted by the > auth server. > > > -- > Josh McKinney > joshka.net > > _______________________________________________ > 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._ --000000000000f0142c057cc32602 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The OAuth framework itself isn't part= icularly RESTful so it's not really specific to token exchange. This do= cument just makes mention of it in the context of talking about the shift f= rom XML/SOAP/WS* to JSON/HTTP as one of the motivations for its existence. =

There's nothing precluding se= nding additional parameters. In general, OAuth says to ignore unrecognized = parameters, which allows for extensions or proprietary additions.

On Wed, Dec 5, 2018 = at 12:29 PM Josh McKinney <ietf@lists.joshka.net> wrote:
Hiya,

In section 1:

=C2=A0 =C2=A0The STS
=C2=A0 =C2=A0protocol defined in this specification is not itself RESTful (= an STS
=C2=A0 =C2=A0doesn't lend itself particularly well to a REST approach) = but does
=C2=A0 =C2=A0utilize communication patterns and data formats that should be=
=C2=A0 =C2=A0familiar to developers accustomed to working with RESTful syst= ems.

A colleague expressed concern that token exchange can not be RESTful. Given= that the token exchange endpoint defined here is the same as the token end= point, is this a restatement that this endpoint itself is not RESTful as op= posed to a different change. AFAICT, none of the other OAuth RFCs mention R= ESTful concerns.

In Section 2.1:
Regarding exchanging an access token for an id token, OIDC allows the calle= r to provide a claims parameter to specify the specific claims returned in = an id token. See https://openid= .net/specs/openid-connect-core-1_0.html#ClaimsParameter
I'm not sure that this spec explicitly constrains parameters to be pass= ed to this method, but it also doesn't have any language to suggest tha= t it will allow extended parameter lists to be passed and interpreted by th= e auth server.


--
Josh McKinney
joshka.n= et

_______________________________________________
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. --000000000000f0142c057cc32602-- From nobody Mon Dec 17 06:06:57 2018 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 3CBC3129385 for ; Mon, 17 Dec 2018 06:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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 (1024-bit key) header.d=armh.onmicrosoft.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 1OLIzEMDttAT for ; Mon, 17 Dec 2018 06:06:50 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30045.outbound.protection.outlook.com [40.107.3.45]) (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 0AAD5128CF3 for ; Mon, 17 Dec 2018 06:06:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gE/KK7rk8vi7M/fU4VGX93k0BI7woqimMBXgURivO9k=; b=Czwv4RY628jbOcZJC6ayLgHuFfjB8V13pnzyOOhoqkrfkdozynWc1rRH15SEFmPNU5Ol3uDRyMLpX+fxK1FbrFzEVXaxfaGUSKa5MnLW0tKEFmVaV8k4DnzRLAcq3FAKJ6O+yoRm3XHeTwLGRPBO1iZahbch7L2FSiliy9iXmq8= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1519.eurprd08.prod.outlook.com (10.167.210.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.19; Mon, 17 Dec 2018 14:06:47 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8%3]) with mapi id 15.20.1425.021; Mon, 17 Dec 2018 14:06:46 +0000 From: webex To: IETF oauth WG Thread-Topic: OAuth WG Virtual Office Hours Thread-Index: AdPtPEjpljxHmkIdTBuy8o+0oBv/iSmj1MVg Sender: Hannes Tschofenig Date: Mon, 17 Dec 2018 14:06:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-ms-exchange-messagesentrepresentingtype: 2 x-ms-exchange-meetingforward-message: Forward x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAfiDBEAAAAAAAAAAAAAAAAAAAAAMQAAAHZDYWwtVWlkAQAAAGNmZTE4ZWUxLTZlNjAtNDZjMS1hODg4LWYwMTExZmUxNWI5NQA= x-originating-ip: [80.92.114.221] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1519; 6:meeGQJi0nOsbHy8g4525f2l7PbBEVnyuEUu16jaOf88x3bYmpL3Bq1BKuEiBi87Tm0GfIokQYLM1BH5KboBm2YYnWa6SV46zhSMT+TRYQMJOxskIoyOtISmE3qVTFM0OxpmExBuJq/+AgCno711KVuC1P16hdx85XP/Uhp8P0QN5XC3FEeC+aFCFrjY/jyXUXYB/3HP+BChf5SKhCxX/klatPmFbZe/F65XL2cLlYKX1KPhsDGFINiVJohcq5Grg+9ikUaE+AkuaC7fJPalXzICa90WjMjto5CKroySh0HwBXW27xn63oJ/63KuZU+nP1ZRCx3DRU4p22N4Yvgw4Wq4U9vEk0pKXjAS0LwiVIKFavEgrHxu0v78QTVjZVXcONrEk20tk9E7i+am9xshVsIlOOCrjkLOHq3bE9wl5eGIyur6nKGUp0OR2mqJGg058ZVhncHtzCvfR6cp5FdiKFw==; 5:ByfO7r7Zyh9V9q4bHGm7nXc8X6+nyHdt9f2Pta6TDo2XzPFSmHHgs6VwAl2uajQS0cwadCyqmr1VxJX3ruVfBoKsNA4Kc/QmZsMCkcUcageyOHE4A1MIqQAnWNQYRzIJE5eZi0YIO/StNtqkKSB46NDFAkzfnkgnEfNsZmDLYzA=; 7:IwMTL+3gQgOHKFL11hiS+xCLqRx8sYkwAfhdIYsVTmkfArJI8GMLIkJPLrptu7blxsosb3SBCzCQnfNnUNxR0c6rzdmjPWT62kSCe0JjAqhmcOWxctHj6DDVrrLVohC0X0RPlCQrlQMWfe1xBMGwzQ== x-ms-office365-filtering-correlation-id: b5fb3076-5dfe-42a4-9dfb-08d66428e1cf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1519; x-ms-traffictypediagnostic: VI1PR0801MB1519: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 0 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(5005020)(6040522)(2401047)(8121501046)(3002001)(10201501046)(93006095)(3231475)(944501520)(52105112)(6055026)(148016)(149066)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1519; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1519; x-forefront-prvs: 08897B549D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(366004)(39860400002)(136003)(40434004)(43544003)(199004)(189003)(38314003)(53754006)(26005)(186003)(14454004)(486006)(3846002)(551544002)(256004)(14444005)(6916009)(6116002)(5024004)(66066001)(33656002)(25786009)(72206003)(55016002)(86152003)(76176011)(7696005)(102836004)(966005)(6392003)(7846003)(6436002)(97736004)(478600001)(99286004)(2473003)(236005)(9686003)(42882007)(790700001)(6306002)(54896002)(2906002)(81166006)(53546011)(81156014)(16799955002)(11346002)(6506007)(606006)(53936002)(8676002)(446003)(316002)(5660300001)(68736007)(71190400001)(7736002)(19627405001)(71200400001)(74316002)(8936002)(106356001)(476003)(105586002)(229853002)(114624004)(43062003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1519; H:VI1PR0801MB2112.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-microsoft-antispam-message-info: +danTj538AwOYs90tNXgjXeLYiTrXXsc1xKopVorOiUGVQJYl4eHUIIxzlYqf+lcGZOJW4jygMnwP6RpqVJZ4shthVvxlrUzlB8Mm3v/vSkzUywRv+PErZRoL9nGpyRKTxAAmfEv1VsPdTZEb+hFxTgKEveNSbZZ+sZbDzG7tl/rV75tpxNN22sNy9k/tWk3yD3L5fGG1wmpzmAkIoYh16q0KBXVWvjW5ma8m2mbq8m/+ytvi4JBEF95PjyREucBjN47ri3sjX4eSQxCcOARTXb0ogev/BTCGhxjzoy9yeuAZr2Vmf49MpC2ST+HebfV spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211212DC67770F76212EBAECFABC0VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: b5fb3076-5dfe-42a4-9dfb-08d66428e1cf X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2018 14:06:46.8203 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1519 Archived-At: Subject: [OAUTH-WG] FW: OAuth WG Virtual Office Hours 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, 17 Dec 2018 14:06:55 -0000 --_000_VI1PR0801MB211212DC67770F76212EBAECFABC0VI1PR0801MB2112_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, today is the last OAuth WG Virtual Office Hour. This is a chance to discuss open issues and other administrative tasks the = chairs need to take care of. Ciao Hannes & Rifaat -----Original Appointment----- From: webex > To: webex; Web Authorization Protocol Working Group Subject: OAuth WG Virtual Office Hours When: Montag, 17. Dezember 2018 17:30-18:30 Europe Time. Where: https://ietf.webex.com/ietf Join WebEx meeting Meeting number (access code): 319 789 694 Host key: 952795 Meeting password: n2XuY4zX Join by phone 1-650-479-3208 Call-in toll number (US/Canada) Can't join the meeting? Contact support. IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. You should inform all meeting attendees prior to re= cording if you intend to record the meeting. 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_VI1PR0801MB211212DC67770F76212EBAECFABC0VI1PR0801MB2112_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

today is the last OAuth WG Virtual Office Hour.

This is a chance to discuss open issues and other ad= ministrative tasks the chairs need to take care of.

 

Ciao

Hannes & Rifaat

 

-----Original Appointment-----<= br> From: webex <messenger@web= ex.com>
To: webex; Web Authorization Protocol Working Group
Subject: OAuth WG Virtual Office Hours
When: Montag, 17. Dezember 2018 17:30-18:30 Europe Time.
Where: https://ietf.webex.co= m/ietf

 

Join WebEx meeting

Meeting number (access code): 319 789 6= 94

 

Host key: 952795

 

Meeting password:

n2XuY4zX



 
 
Join by phone 
1-650-479-3208&nbs= p;Call-in toll number (US/Canada) 


 
Can't join the meeting? Contact support.=  
 
IMPORTANT NOTICE: Please note that this WebEx= service allows audio and other information sent during the session to be r= ecorded, which may be discoverable in a legal matter. You should inform all= meeting attendees prior to recording if you intend to record the meeting.

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_VI1PR0801MB211212DC67770F76212EBAECFABC0VI1PR0801MB2112_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpSb21hbmNl IFN0YW5kYXJkIFRpbWUNCkJFR0lOOlNUQU5EQVJEDQpEVFNUQVJUOjE2MDEwMTAxVDAzMDAwMA0K VFpPRkZTRVRGUk9NOiswMjAwDQpUWk9GRlNFVFRPOiswMTAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJ TlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMA0KRU5EOlNUQU5EQVJEDQpCRUdJTjpEQVlM SUdIVA0KRFRTVEFSVDoxNjAxMDEwMVQwMjAwMDANClRaT0ZGU0VURlJPTTorMDEwMA0KVFpPRkZT RVRUTzorMDIwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9O VEg9Mw0KRU5EOkRBWUxJR0hUDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCk9SR0FOSVpF UjtDTj13ZWJleDtTRU5ULUJZPSJNQUlMVE86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbSI6TUFJ TFRPOm1lc3NlbmdlDQogckB3ZWJleC5jb20NCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5U O1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049SUVURiBvYXV0aA0KICBXRzpNQUlM VE86b2F1dGhAaWV0Zi5vcmcNCkRFU0NSSVBUSU9OO0xBTkdVQUdFPWVuLVVTOkhpIGFsbFwsXG5c bnRvZGF5IGlzIHRoZSBsYXN0IE9BdXRoIFdHIFZpcnR1YWwgTw0KIGZmaWNlIEhvdXIuXG5UaGlz IGlzIGEgY2hhbmNlIHRvIGRpc2N1c3Mgb3BlbiBpc3N1ZXMgYW5kIG90aGVyIGFkbWluaXN0cmF0 DQogaXZlIHRhc2tzIHRoZSBjaGFpcnMgbmVlZCB0byB0YWtlIGNhcmUgb2YuXG5cbkNpYW9cbkhh bm5lcyAmIFJpZmFhdFxuXG4tLS0NCiAtLU9yaWdpbmFsIEFwcG9pbnRtZW50LS0tLS1cbkZyb206 IHdlYmV4IDxtZXNzZW5nZXJAd2ViZXguY29tPG1haWx0bzptZXNzZQ0KIG5nZXJAd2ViZXguY29t Pj5cblRvOiB3ZWJleFw7IFdlYiBBdXRob3JpemF0aW9uIFByb3RvY29sIFdvcmtpbmcgR3JvdXBc blN1DQogYmplY3Q6IE9BdXRoIFdHIFZpcnR1YWwgT2ZmaWNlIEhvdXJzXG5XaGVuOiBNb250YWdc LCAxNy4gRGV6ZW1iZXIgMjAxOCAxNzoNCiAzMC0xODozMCBFdXJvcGUgVGltZS5cbldoZXJlOiBo dHRwczovL2lldGYud2ViZXguY29tL2lldGZcblxuSm9pbiBXZWJFeCBtZQ0KIGV0aW5nPGh0dHBz Oi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1jNTc3Y2VjY2IzYzVkM2NkZGE1MjRl NzY5ZWMxDQogZmNjYz5cbk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDMxOSA3ODkgNjk0 XG5cblxuSG9zdCBrZXk6IDk1Mjc5NVxuXG4NCiBcbk1lZXRpbmcgcGFzc3dvcmQ6XG5cbm4yWHVZ NHpYXG5cblxuXG5cblxuSm9pbiBieSBwaG9uZVxuMS02NTAtNDc5LTMyMDggQw0KIGFsbC1pbiB0 b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29u dGFjdCBzdXBwDQogb3J0LjxodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWM+XG5cbklNUE9S VEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQNCiAgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93 cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlcw0KIHNpb24g dG8gYmUgcmVjb3JkZWRcLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0 dGVyLiBZb3Ugc2hvDQogdWxkIGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRlZXMgcHJpb3IgdG8g cmVjb3JkaW5nIGlmIHlvdSBpbnRlbmQgdG8gcmVjb3INCiBkIHRoZSBtZWV0aW5nLlxuSU1QT1JU QU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhYw0KIGht ZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50DQogZW5kZWQgcmVjaXBpZW50XCwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UNCiAgdGhlIGNvbnRlbnRzIHRvIGFu eSBvdGhlciBwZXJzb25cLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlXCwgb3Igc3RvcmUgb3IgYw0K IG9weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91LlxuDQpVSUQ6Y2Zl MThlZTEtNmU2MC00NmMxLWE4ODgtZjAxMTFmZTE1Yjk1DQpSRUNVUlJFTkNFLUlEO1RaSUQ9Um9t YW5jZSBTdGFuZGFyZCBUaW1lOjIwMTgxMjE3VDE3MzAwMA0KU1VNTUFSWTtMQU5HVUFHRT1lbi1V UzpGVzogT0F1dGggV0cgVmlydHVhbCBPZmZpY2UgSG91cnMNCkRUU1RBUlQ7VFpJRD1Sb21hbmNl IFN0YW5kYXJkIFRpbWU6MjAxODEyMTdUMTczMDAwDQpEVEVORDtUWklEPVJvbWFuY2UgU3RhbmRh cmQgVGltZToyMDE4MTIxN1QxODMwMDANCkNMQVNTOlBVQkxJQw0KUFJJT1JJVFk6NQ0KRFRTVEFN UDoyMDE4MDUyMVQxNTMwMDBaDQpUUkFOU1A6T1BBUVVFDQpTVEFUVVM6Q09ORklSTUVEDQpTRVFV RU5DRToxNTI2NDkyMDQ5DQpMT0NBVElPTjtMQU5HVUFHRT1lbi1VUzpodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYNClgtTUlDUk9TT0ZULUNETy1BUFBULVNFUVVFTkNFOjE1MjY0OTIwNDkNClgt TUlDUk9TT0ZULUNETy1PV05FUkFQUFRJRDotMQ0KWC1NSUNST1NPRlQtQ0RPLUJVU1lTVEFUVVM6 VEVOVEFUSVZFDQpYLU1JQ1JPU09GVC1DRE8tSU5URU5ERURTVEFUVVM6QlVTWQ0KWC1NSUNST1NP RlQtQ0RPLUFMTERBWUVWRU5UOkZBTFNFDQpYLU1JQ1JPU09GVC1DRE8tSU1QT1JUQU5DRToxDQpY LU1JQ1JPU09GVC1DRE8tSU5TVFRZUEU6Mw0KWC1NSUNST1NPRlQtRE9OT1RGT1JXQVJETUVFVElO RzpGQUxTRQ0KWC1NSUNST1NPRlQtRElTQUxMT1ctQ09VTlRFUjpGQUxTRQ0KWC1NSUNST1NPRlQt TE9DQVRJT05TOlt7IkRpc3BsYXlOYW1lIjoiaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmIlws IkxvY2F0DQogaW9uQW5ub3RhdGlvbiI6IiJcLCJMb2NhdGlvblVyaSI6IiJcLCJMb2NhdGlvblN0 cmVldCI6IiJcLCJMb2NhdGlvbkNpdHkiOiINCiAiXCwiTG9jYXRpb25TdGF0ZSI6IiJcLCJMb2Nh dGlvbkNvdW50cnkiOiIiXCwiTG9jYXRpb25Qb3N0YWxDb2RlIjoiIlwsIkxvYw0KIGF0aW9uRnVs bEFkZHJlc3MiOiIifV0NCkJFR0lOOlZBTEFSTQ0KREVTQ1JJUFRJT046UkVNSU5ERVINClRSSUdH RVI7UkVMQVRFRD1TVEFSVDotUFQxNU0NCkFDVElPTjpESVNQTEFZDQpFTkQ6VkFMQVJNDQpFTkQ6 VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= --_000_VI1PR0801MB211212DC67770F76212EBAECFABC0VI1PR0801MB2112_-- From nobody Mon Dec 17 12:27:29 2018 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 11AD8126F72 for ; Mon, 17 Dec 2018 12:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 r5DoFHtPcMP3 for ; Mon, 17 Dec 2018 12:27:25 -0800 (PST) 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 51AE4129BBF for ; Mon, 17 Dec 2018 12:27:25 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id t24so11050421ioi.0 for ; Mon, 17 Dec 2018 12:27:25 -0800 (PST) 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=CTqOvl97ovhWdE/IU3fC5NIvhNnIukHStLbrz1Bc+Mk=; b=TN1mWSTwTFdsHmpuOJQ2AfsZ7AhJCEuIkJEx26ujGUKwzc6ggT6I/o6/ixuRvtaCra UxOb2QRdXdWAlANvG5TDQighWsabm9RBGKe3vsvIN3WLtzp309M3hWJjNzatZZ37XHyp 17O9L1z2AZzj7VOGv6bK9CinJ0+Y93RKrpndw= 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=CTqOvl97ovhWdE/IU3fC5NIvhNnIukHStLbrz1Bc+Mk=; b=QbAjRy1HShz3/8aE5l/KYrh54+369rHz5a+rFD6VdOD24MBqSndMqEkHFRaa4LSH9x PRQPnCVVS+ZYNa3cLqSPd+b/Bxei8Yo2xmlqdpamv68tI+V8YSlIg3uidTY+gqIsdAKf aJw2C+K8yqb9iAMYjwrYu7Nx2nBTyf0QktzdCdYnkkQgcwOdOz5zcBZhY7wPI8AsRRxK pWwZZ42X1sXN0kvd+xmmDv8g79RswZybnAlqWIjcxJSZvVf0UafqNJBr9j0XLlz1s7vk M82pupWsn/8UHyl0oLWUVGYpBLXVKAMTKjilZPK0mhaMbkij+iDGCjDJEau/K8CuYxqQ LIDg== X-Gm-Message-State: AA+aEWZDuKdqVUWEUMXnKT9XxzVhRbQ/S3lKOCSH5MjAB/cI6XT6BPWZ SLpU2p9EysVkKyA+DsRk8Tv8G4iv1hraP91vMrkJx84uGRGQal7+SZBBbWZjpgcoyfln/zJvBml /PKtb6lLwocVboweUj4Y= X-Google-Smtp-Source: AFSGD/XEjNPP9ks46yjbSpr7q97DmEx7TbPeVjsiAcaEaMQiiVFXqP7kMMFDIKGyHz2z30SFa+gaDtF4wAoZVHwullw= X-Received: by 2002:a6b:6e09:: with SMTP id d9mr10743388ioh.138.1545078444191; Mon, 17 Dec 2018 12:27:24 -0800 (PST) MIME-Version: 1.0 From: Brian Campbell Date: Mon, 17 Dec 2018 13:26:58 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000d11740057d3d9b5b" Archived-At: Subject: [OAUTH-WG] MTLS and in-browser clients using the token endpoint 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, 17 Dec 2018 20:27:28 -0000 --000000000000d11740057d3d9b5b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While there's been some disagreement about the specific wording etc., there does seem to be general consensus coming out of this WG to, in one form or another, recommend against the use of the implicit grant in favor of authorization code. In order to follow that recommendation, in-browser JavaScript clients will need to use XHR/fetch (and likely CORS) to make requests directly to the token endpoint. Meanwhile there is the MTLS document utilizes TLS client certificates at the token endpoint for client authentication and/or certificate bound access tokens. The security BCP draft even recommends sender/key constrained access tokens and MTLS is close to the only viable way to do that at this time. Unfortunately, however, these two things don't play very nice together. When a browser makes a TLS connection where a client cert is requested by the server in the handshake, even when client certificates are optional and even when it's fetch/XHR, most/many/all browsers will throw up some kind of certificate selection interface to the user. Which is typically a very very bad user experience. From a practical standpoint, this means that a single deployment cannot really support the MTLS draft and have in-browser JavaScript clients using authorization code at the same time. In order to address the conflict here, I'd propose that the MTLS draft introduce a new optional AS metadata parameter that is an MTLS enabled token endpoint alias. Clients that are doing MTLS client authentication and/or certificate bound access tokens would/should/must use the alternative token endpoint when present in the AS's metadata. While all other clients continue to use the standard token endpoint as they always have. This would allow for an AS to deploy an alternative token endpoint alias on a distinct host or port where it will request client certs in the TLS handshake for OAuth clients that use it while keeping the regular token endpoint as it normally is for other clients, especially in-browser JavaScript clients. Thoughts, objections, agreements, etc., on this proposal? PS Bikeshedding on a name for the metadata parameter is also welcome. Some ideas to start: token_endpoint_mtls_alias token_endpoint_mtls mtls_token_endpoint_alias mtls_token_endpoint alt_token_endpoint_mtls mtls_token_endpoint_alt a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_shou= ld_use equally_poor_idea_here --=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._ --000000000000d11740057d3d9b5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wh= ile there's been some disagreement about the specific wording etc., the= re does seem to be general consensus coming out of this WG to, in one form = or another, recommend against the use of the implicit grant in favor of aut= horization code. In order to follow that recommendation, in-browser JavaScr= ipt clients will need to use XHR/fetch (and likely CORS) to make requests d= irectly to the token endpoint.

Meanwhile there is= the MTLS = document utilizes TLS client certificates at the token endpoint for cli= ent authentication and/or certificate bound access tokens. The security BCP= draft even recommends sender/key constrained access tokens and MTLS is clo= se to the only viable way to do that at this time.

Unfortunately, however, these two things don't play very nice tog= ether. When a browser makes a TLS connection where a client cert is request= ed by the server in the handshake, even when client certificates are option= al and even when it's fetch/XHR, most/many/all browsers will throw up s= ome kind of certificate selection interface to the user.=C2=A0 Which is typ= ically a very very bad user experience. From a practical standpoint, this m= eans that a single deployment cannot really support the MTLS draft and have= in-browser JavaScript clients using authorization code at the same time. <= br>

In order to address the conflict here, I'd= propose that the MTLS draft introduce a new optional AS metadata parameter= that is an MTLS enabled token endpoint alias. Clients that are doing MTLS = client authentication and/or certificate bound access tokens would/should/m= ust use the alternative token endpoint when present in the AS's metadat= a. While all other clients continue to use the standard token endpoint as t= hey always have. This would allow for an AS to deploy an alternative token = endpoint alias on a distinct host or port where it will request client cert= s in the TLS handshake for OAuth clients that use it while keeping the regu= lar token endpoint as it normally is for other clients, especially in-brows= er JavaScript clients.

Thoughts, objections, = agreements, etc., on this proposal?

PS Bikesheddin= g on a name for the metadata parameter is also welcome. Some ideas to start= :
token_endpoint_mtls_alias
token_endpoint_mtls
mtls_token_endpoint_alias
mtls_token_endpoint
al= t_token_endpoint_mtls
mtls_token_endpoint_alt
a_token_e= ndpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use
equally_poor_idea_here






<= /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. --000000000000d11740057d3d9b5b-- From nobody Mon Dec 17 12:59:12 2018 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 1E4CC129AB8 for ; Mon, 17 Dec 2018 12:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=armh.onmicrosoft.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 uHHlpNHiZo4n for ; Mon, 17 Dec 2018 12:59:07 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40048.outbound.protection.outlook.com [40.107.4.48]) (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 55C81126F72 for ; Mon, 17 Dec 2018 12:59:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CI70eZFEW3rEyp3rvB6hWKzNidgy2PPvHnACvUYkmnY=; b=FQgB9zX9blxvL9+n6GrbIguS5a2nCkmU0h13wxAaS7jlkMDOKQm/xXnrBpPV3mUl+E57hEPz8iMV0gEWUPDqY7ATQrpPTarjQBFeYjAc0CyN88CiPiUHvAhCg4Nz28Ze2WUE0c2MtvdWDFTnVd+v4D5t6s5cobMBlnrfkzDNEas= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1728.eurprd08.prod.outlook.com (10.168.67.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.20; Mon, 17 Dec 2018 20:59:04 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8%3]) with mapi id 15.20.1425.021; Mon, 17 Dec 2018 20:59:04 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: Conclusion ... OAuth Security Topics -- Recommend authorization code instead of implicit Thread-Index: AdSWSzJyGDZIjF5pR62PcCDRCOzeTA== Date: Mon, 17 Dec 2018 20:59:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.114.221] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1728; 6:FABxggHPeBmc34RNElShC32Y63D5Yq4PfI/ziVsrPGQDzTFL/oTbF8pXFLm8GFT6LarPYF6o4DxyMECcnLjxzpbQVGxoNO5G4YF+6p30SUHsmo9Swes8G31J6bEo3jCzXyy9qV+eRifeWMIAkOVCTsJ72QZnGEm9I1HyFBXmFw4w3w+IIF2SQyj56tjgpnp39YmcqIjJ7fngwxmkfa+KT7qZC2B1zO2sETy059un96fpDS1t4ek4szoqTBI68c2Tq2Z6GcESrbse0e4cYmlplGzNA2F+LkzKEj5NtlaK4ovZcwLv1hO/ArI2m2Xj5N4zT+mn/bm62no6kPsaulfMQ205PH03tR0NQ/wZOzfwdMIydcIw2jTnp75WhyMNM8rIFm+1xNUkOzyjUuY2MCIRQMQyTmuHu+I1d83F2cOszIzPDf6ObpXyZFqzdAcd5u0rPBiaokR12+BVIuCR0eMQ9w==; 5:QyjWcCTgkJQvOssGaVn03S5HWckpTcK7Kkqawccs2i/ssFAfgBBNv1dqznthGtgWYapewFdDyba8jYgAyiyf20mAb919La+GD08h0D7HdzxyqS9sX+CB7BL4GtVUDP7dT7NolxbFRTIidR8F5fkTxnajzrE+F03t6Hcwt/HN0PM=; 7:pxfZoRLucPh+X6Elrd9u9V3RrgrHtG2/qbr47DjSSzsFcAvz9/KeOoAEFnOnEN+HPa6E1FJSZDf+X8U/iHg+fhoHYsEMbbm7Ual144zTQuCngp2yu8qKiSa+VIXokN93BcC+3Wwhq+md0RveU0QPqQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4a771e2d-db6c-4281-8b4e-08d664627a65 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1728; x-ms-traffictypediagnostic: VI1PR0801MB1728: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231475)(944501520)(52105112)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1728; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1728; x-forefront-prvs: 08897B549D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(346002)(396003)(39860400002)(376002)(53754006)(40434004)(189003)(199004)(68736007)(10710500007)(7696005)(2906002)(71190400001)(790700001)(99286004)(3846002)(6116002)(6306002)(9686003)(74316002)(5024004)(236005)(486006)(14454004)(81156014)(7110500001)(53936002)(54896002)(8676002)(966005)(478600001)(5660300001)(97736004)(6436002)(606006)(8936002)(256004)(102836004)(316002)(561944003)(33656002)(81166006)(2420400007)(476003)(72206003)(15650500001)(55016002)(14444005)(7736002)(6916009)(6506007)(53546011)(71200400001)(26005)(66066001)(105586002)(186003)(86362001)(66574012)(25786009)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1728; H:VI1PR0801MB2112.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-microsoft-antispam-message-info: tfwXbt+qBdMZ4aACvcZKnst4/kAYwJsAqmF0sL9Ng2BFJlDolJsuLO5fOq9HrsaTuqZXwaNCXU0Gk+pyxDjD6PRdAbslxR76/t4tEtWodyWjmeIE0bDqezGan+Kzc6AzFNCrtKuIRBHv8Q84cVsHVdPa7uHyprEokeTCUKLYNvFO0JppfBG3DT5sjRgSISREsb8aKqkm2ksWRnu8jh2BXOtvzTgJ71UqE8p5E7a9WropdAgcRpHZ5uXpQms7ANJxRsbQYIQUpaMHSCePNRohkhkYPD4QBq5UFP69CoZ3ePZnP0/M131B7W+EkC4AWRpx spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112029552C678D8D75C327AFABC0VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4a771e2d-db6c-4281-8b4e-08d664627a65 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2018 20:59:04.1770 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1728 Archived-At: Subject: [OAUTH-WG] Conclusion ... OAuth Security Topics -- Recommend authorization code instead of implicit 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, 17 Dec 2018 20:59:11 -0000 --_000_VI1PR0801MB2112029552C678D8D75C327AFABC0VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Rifaat and I went through the discussion in an effort to judge the outcome. First, we would like to thank you all for your input. Torsten, as the edito= r of the OAuth Security BCP, got lots of good feedback. Second, there is strong support recommending against the implicit grant and= the response types "token id_token" and "code token id_token" for all futu= re applications. For already deployed applications please do your threat an= alysis and make your own judgement. Here is a proposal for the new text in Section 2.1.2 of the Security BCP: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10 ---- 2.1.2. Implicit Grant The implicit grant (response type "token") and other response types causing the authorization server to issue access tokens in the authorization response are vulnerable to access token leakage and access token replay as described in Section 3.1, Section 3.2, Section 3.3, and Section 3.6. Moreover, no viable mechanism exists to cryptographically bind access tokens issued in the authorization response to a certain client as it is recommended in Section 2.2. This makes replay detection for such access tokens at resource servers impossible. In order to avoid these issues, clients SHOULD NOT use the implicit grant (response type "token") or any other response type issuing access tokens in the authorization response, such as "token id_token" and "code token id_token", unless the issued access tokens are sender-constrained and access token injection in the authorization response is prevented. A sender constrained access token scopes the applicability of an access token to a certain sender. This sender is obliged to demonstrate knowled= ge of a certain secret as prerequisite for the acceptance of that token at the recipient (e.g., a resource server). Clients SHOULD instead use the response type "code" (aka authorization code grant type) as specified in Section 2.1.1 or any other response type that causes the authorization server to issue access tokens in the token response. This allows the authorization server to detect replay attempts and generally reduces the attack surface since access tokens are not exposed in URLs. It also allows the authorization server to sender-constrain the issued tokens. ---- There was a lot of feedback for advice on how to implement OAuth with singl= e-page applications. Aaron has been working on a draft and we are planning = to start a call for adoption. This document will be a natural home for desc= ribing solutions. Here is the link to the draft: https://tools.ietf.org/htm= l/draft-parecki-oauth-browser-based-apps-02 Ciao Hannes & Rifaat PS: We would like to remind you about the upcoming OAuth Security Workshop = in Stuttgart/Germany (March 20-22, 2019) where we will speak about the abov= e-mentioned topics and much more. Here is the link: https://sec.uni-stuttgart.de/events/osw2019 From: Hannes Tschofenig Sent: Montag, 19. November 2018 11:34 To: oauth Subject: OAuth Security Topics -- Recommend authorization code instead of i= mplicit Hi all, The authors of the OAuth Security Topics draft came to the conclusion that = it is not possible to adequately secure the implicit flow against token inj= ection since potential solutions like token binding or JARM are in an early= stage of adoption. For this reason, and since CORS allows browser-based ap= ps to send requests to the token endpoint, Torsten suggested to use the aut= horization code instead of the implicit grant in call cases in his presenta= tion (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oau= th-sessb-draft-ietf-oauth-security-topics-01). A hum in the room at IETF#103 concluded strong support for his recommendati= ons. We would like to confirm the discussion on the list. Please provide a response by December 3rd. 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_VI1PR0801MB2112029552C678D8D75C327AFABC0VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Rifaat and I went through the discussion in an effor= t to judge the outcome.

 

First, we would like to thank you all for your input= . Torsten, as the editor of the OAuth Security BCP, got lots of good feedba= ck.

 

Second, there is strong support recommending against= the implicit grant and the response types "token id_token" and &= quot;code token id_token" for all future applications. For already dep= loyed applications please do your threat analysis and make your own judgement.

 

Here is a proposal for the new text in Section 2.1.2= of the Security BCP: 

https://tools.ietf.org/html/draft-ietf-oauth-securit= y-topics-10

 

----

 

2.1.2.  Implicit Grant

 

   The implicit grant (response type "= ;token") and other response types

   causing the authorization server to iss= ue access tokens in the

   authorization response are vulnerable t= o access token leakage and

   access token replay as described in Sec= tion 3.1, Section 3.2,

   Section 3.3, and Section 3.6.

 

   Moreover, no viable mechanism exists to= cryptographically bind access

   tokens issued in the authorization resp= onse to a certain client as it

   is recommended in Section 2.2.  Th= is makes replay detection for such

   access tokens at resource servers impos= sible.

  

   In order to avoid these issues, cl= ients SHOULD NOT use the implicit

   grant (response type "token&q= uot;) or any other response type issuing

   access tokens in the authorization= response, such as "token id_token"

   and "code token id_token"= ;, unless the issued access tokens are

   sender-constrained and access toke= n injection in the authorization

   response is prevented. =

 

   A sender constrained access token scope= s the applicability of an access

   token to a certain sender. This se= nder is obliged to demonstrate knowledge

   of a certain secret as prerequisit= e for the acceptance of that token at

   the recipient (e.g., a resource se= rver).

  

   Clients SHOULD instead use the res= ponse type "code" (aka

   authorization code grant type) as speci= fied in Section 2.1.1 or any

   other response type that causes the aut= horization server to issue

   access tokens in the token response.&nb= sp; This allows the authorization

   server to detect replay attempts and ge= nerally reduces the attack

   surface since access tokens are not exp= osed in URLs.  It also allows

   the authorization server to sender-cons= train the issued tokens.  

----

 

There was a lot of feedback for advice on how to imp= lement OAuth with single-page applications. Aaron has been working on a dra= ft and we are planning to start a call for adoption. This document will be = a natural home for describing solutions. Here is the link to the draft: https://tools.ietf.org/html/draft-parecki-o= auth-browser-based-apps-02

 

Ciao

Hannes & Rifaat

 

PS: We would like to remind you about the upcoming O= Auth Security Workshop in Stuttgart/Germany (March 20–22, 2019) where= we will speak about the above-mentioned topics and much more. Here is the = link:

https://sec.uni-stuttgart.de/events/osw2019

 

From: Hannes Tschofenig
Sent: Montag, 19. November 2018 11:34
To: oauth <oauth@ietf.org>
Subject: OAuth Security Topics -- Recommend authorization code inste= ad of implicit

 

Hi all,

 

The authors of the OAuth Security Topics draft ca= me to the conclusion that it is not possible to adequately secure the impli= cit flow against token injection since potential solutions like token bindi= ng or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to sen= d requests to the token endpoint, Torsten suggested to use the authorizatio= n code instead of the implicit grant in call cases in his presentation (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-d= raft-ietf-oauth-security-topics-01).

 

A hum in the room at IETF#103 concluded strong su= pport for his recommendations. We would like to confirm the discussion on t= he list.

 

Please provide a response by December 3rd.

 

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_VI1PR0801MB2112029552C678D8D75C327AFABC0VI1PR0801MB2112_-- From nobody Mon Dec 17 13:02:05 2018 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 AA70712958B for ; Mon, 17 Dec 2018 13:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=armh.onmicrosoft.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 dbHeBoLt_4lM for ; Mon, 17 Dec 2018 13:02:01 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40061.outbound.protection.outlook.com [40.107.4.61]) (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 93CF5126F72 for ; Mon, 17 Dec 2018 13:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=31qaY7jd13Qf8RRrBkVN5Z69UuvpUDEcEy3Bgvt9aZo=; b=ayEhpYP2bEEtoU7Z6iI11YV3MPH8gppNG7dYcWVQowhGyqYQHj4Ae73YI79MG04fMcVLk2bI77Yp//aasxSuInV4LfrLNJOll4vtL7KfJWm93zy4WrNtSbtElDkewwKNBWXF8KOvwYwgHPCAKKrIBV6bH8p6v1gN7MeEQyOIWcg= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1728.eurprd08.prod.outlook.com (10.168.67.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.20; Mon, 17 Dec 2018 21:01:57 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8%3]) with mapi id 15.20.1425.021; Mon, 17 Dec 2018 21:01:57 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: Call for Adoption: OAuth 2.0 for Browser-Based Apps Thread-Index: AdSWS7Oc+Cli+sUWS9WAastnHMBWKw== Date: Mon, 17 Dec 2018 21:01:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.114.221] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1728; 6:NyPRbC2SGMff5vqI2kxvaI+sT1/6bsch59qt9QB7IVNM1MmHdGvQg/gZPtr8gfjGTdN8bWJviXKC/Iwak9CqpF6TDziXucOhddAHvleZ4pt2g7hFkh7jh79mL9ycMYw5nb0iY+wRikGLCrMZoUgBLFuClCu/1uXnHxKqnDYSls26IPsB2zwebRhxwIEbb1zzY+vpV6p4HnpAqlg5jRZPukcth7GTLNY8W7R/ZuK1NjjGO6IA2g7n/vQ73OyznRy7uSg9abt0iN9yNoSXJhhmZJnLaMxE1Hu0YcyfRQV8mB/v9W5K4lckVxO2Ixu3IYv/JqdEUU4FL/d2hekWRSZhgUqmvCwIGlyWOEOTZZfnKSZ8buM48TQETmGIkZWBpFB3oD0zmwUCq6CnAkoSkReMbh554yQKlMwXjQwYACAt0LPcK3hdpJ0IDq8eDGqIQghEwiB+twkhUnjaOms4je317g==; 5:Myqg2ds4h+4Tmh6n5bLBV3lFzoPV3NUFSIPVBJmb8IOQk7wYobiZ5LRW0zRZ0tPJkIft6K06vkKOe/iMvet9HK8Nb89z+iujMZrRUE/w+7QgJV8vw6982ZPbgd8mjtZykqdE2E50kyBExEeMb6QPuwLB8+BguFW+iWaermbeISY=; 7:W6cNDiW1/M3JGZg/OgxcsGYpVME3ZofdUXfGdTHAX9l3Ie3uXM4lnDyrdw1kHHwbh8P1vkBQH51mylSXPK7/bgctScTjB+Ki2xL7aX4WOskiLJt12M/c/ox/0FwqVMDzrc1amNH6ciz6E8rPu9HJew== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 08d9bce9-a9ba-421d-d39d-08d66462e17e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1728; x-ms-traffictypediagnostic: VI1PR0801MB1728: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231475)(944501520)(52105112)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1728; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1728; x-forefront-prvs: 08897B549D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(346002)(396003)(39860400002)(376002)(53754006)(40434004)(189003)(199004)(68736007)(7696005)(2906002)(71190400001)(99286004)(3846002)(6116002)(6306002)(9686003)(74316002)(5024004)(486006)(14454004)(81156014)(53936002)(305945005)(8676002)(966005)(478600001)(5660300001)(97736004)(6436002)(8936002)(256004)(102836004)(316002)(33656002)(81166006)(476003)(72206003)(55016002)(14444005)(7736002)(6916009)(6506007)(71200400001)(26005)(66066001)(105586002)(186003)(86362001)(66574012)(25786009)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1728; H:VI1PR0801MB2112.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-microsoft-antispam-message-info: eSf3r/+fDbix6+MF84nOl1vpSVBMjTRaz3eVl8NJGjKP8NzJxcTZVJW+sn6nTZDVVXqlZDaast9dQww2Ryo7jjWA8bkfblwSvuL6UB625uMZZjNhTSJv45ByqSvD+fqevh3ZpowoHUTfEgWGd2teWE0UuljF4tQkKM8llArllJqqLV6EynNg6PhXfbt1AkQgWNzLQVjxjjCqw/mwOcubrZmI1MWnI34De902WfuZcFvJcTH3oYWFLF4WVkOVGrf2TzjCn7aywfQDWzI7UjbpbeejWI7mGLnFk8TjSuxwvNYWocoSpGbxtKVQbOe+QEmF spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 08d9bce9-a9ba-421d-d39d-08d66462e17e X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2018 21:01:57.1480 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1728 Archived-At: Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 for Browser-Based Apps 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, 17 Dec 2018 21:02:04 -0000 Hi all, We would like to get a confirmation on the mailing list for the adoption of= https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-02 as a= starting point for a BCP document about *OAuth 2.0 for Browser-Based Apps*= . Please, let us know if you support or object to the adoption of this docume= nt by Jan. 7th 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. From nobody Mon Dec 17 13:28:37 2018 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 C7311129AB8 for ; Mon, 17 Dec 2018 13:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=ve7jtb-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 rgzjBF-GBeyT for ; Mon, 17 Dec 2018 13:28:33 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 63A0F12958B for ; Mon, 17 Dec 2018 13:28:33 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id y20so15825138qtm.13 for ; Mon, 17 Dec 2018 13:28:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=ZI/cccjbtYnH5bkeu/4jo9gJaLaB7sbEZcBP4GTwxTI=; b=Vs2HlXwJQBa3K8jv47wZ3M5/4O6RjZLVn4MOuRamMoHHQsxdbti4c6ObkuGa1EorwW xwnuRC7dde8UP2Tz4U5irELWeq6Qg8gQb3NV/OQXbMCa9ZgCtYx+1U17pOqc9HUlMZfq ikDtrY0zVpWPAg01nKYDIQrCtrZ0cqvRTL+hgjP8JzeLWACoxyqqocT/dJPBU3ZXuWeZ 44hTh7JR+GS/3/kgu0f0WF/h5uoog9fmarRie/FTr/5sDi/3FqaJ+u/ezymoGjiAdb4F nl35MOxVmXtcMVdVYdwgzbA9uhYbv8HdzS5vNi0RWTTK6hLM6S9wvtceEYltLQRT9epL iTRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ZI/cccjbtYnH5bkeu/4jo9gJaLaB7sbEZcBP4GTwxTI=; b=ZOeOlVt6sCKx4RvodPllkZkRR/3ZecJSBYKllO2EzEZNgb3DmJnaravbYcGyw6SJ9W 8INbjlTV0QpfRBe7VLpsLbqIpb15ztvH6VOg1sWQaCqUBB1Rs16H2XQX4T/BD2Hf9UBW vR3yDGY2ss/pHVHcsyjA/FjnK3AVF+zpRTn5P6dCsm03HAQUafjNCg2laWaTiCyuHVIp lIsiMhLG3g10urtYhwU+dZgwZV3gGc6EKuar7aJfmOFpXmJBHK4JLhHJnPIRYlcMBK3P OOOpnh/cPdSYrjHi6Y5q9SfCsbXHBOKa8dFpsgsGZZZ7W6AcuJ5MH0twtULlyiH6wqcF AWIg== X-Gm-Message-State: AA+aEWZLGO1Qfkb9n2APxHWwCmRtHThVOBHnXVDHcxp7u29hiCMkLyuO 81p8XPjBkfMqS3NElNEyodPGbEs49kFw2g== X-Google-Smtp-Source: AFSGD/VS01kPHU/MBol5Jhg5dh857WiqE3/6A2nY5p+0LbUvHkuReRGXim+bLWNRGtoUaDFZcO7WZg== X-Received: by 2002:a0c:9659:: with SMTP id 25mr14365930qvy.3.1545082111356; Mon, 17 Dec 2018 13:28:31 -0800 (PST) Received: from [192.168.8.100] ([181.203.54.145]) by smtp.gmail.com with ESMTPSA id t123sm6101919qkc.6.2018.12.17.13.28.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Dec 2018 13:28:30 -0800 (PST) From: John Bradley X-Google-Original-From: John Bradley To: oauth@ietf.org References: Message-ID: <47b3ee89-84a6-4731-171c-3b03fd935e24@ve7jtb.com> Date: Mon, 17 Dec 2018 13:28:29 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Thunderbird/64.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5CABBC66F31D5DF2C0C0E2B5" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint 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, 17 Dec 2018 21:28:36 -0000 This is a multi-part message in MIME format. --------------5CABBC66F31D5DF2C0C0E2B5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Yes that is a general problem with browsers and MTLS. A separate token endpoint is probably useful. I don't really see SPA doing mutual TLS as likely, however once MTLS is turned on on the token endpoint for some clients it can mess up other browser and non browser clients. A separate endpoint in discovery is a good idea  they can always both point to the same place. John B. On 12/17/2018 12:26 PM, Brian Campbell wrote: > While there's been some disagreement about the specific wording etc., > there does seem to be general consensus coming out of this WG to, in > one form or another, recommend against the use of the implicit grant > in favor of authorization code. In order to follow that > recommendation, in-browser JavaScript clients will need to use > XHR/fetch (and likely CORS) to make requests directly to the token > endpoint. > > Meanwhile there is the MTLS document > utilizes TLS > client certificates at the token endpoint for client authentication > and/or certificate bound access tokens. The security BCP draft even > recommends sender/key constrained access tokens and MTLS is close to > the only viable way to do that at this time. > > Unfortunately, however, these two things don't play very nice > together. When a browser makes a TLS connection where a client cert is > requested by the server in the handshake, even when client > certificates are optional and even when it's fetch/XHR, most/many/all > browsers will throw up some kind of certificate selection interface to > the user.  Which is typically a very very bad user experience. From a > practical standpoint, this means that a single deployment cannot > really support the MTLS draft and have in-browser JavaScript clients > using authorization code at the same time. > > In order to address the conflict here, I'd propose that the MTLS draft > introduce a new optional AS metadata parameter that is an MTLS enabled > token endpoint alias. Clients that are doing MTLS client > authentication and/or certificate bound access tokens > would/should/must use the alternative token endpoint when present in > the AS's metadata. While all other clients continue to use the > standard token endpoint as they always have. This would allow for an > AS to deploy an alternative token endpoint alias on a distinct host or > port where it will request client certs in the TLS handshake for OAuth > clients that use it while keeping the regular token endpoint as it > normally is for other clients, especially in-browser JavaScript clients. > > Thoughts, objections, agreements, etc., on this proposal? > > PS Bikeshedding on a name for the metadata parameter is also welcome. > Some ideas to start: > token_endpoint_mtls_alias > token_endpoint_mtls > mtls_token_endpoint_alias > mtls_token_endpoint > alt_token_endpoint_mtls > mtls_token_endpoint_alt > a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use > equally_poor_idea_here > > > > > > > > /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 --------------5CABBC66F31D5DF2C0C0E2B5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Yes that is a general problem with browsers and MTLS. 

A separate token endpoint is probably useful. 

I don't really see SPA doing mutual TLS as likely, however once MTLS is turned on on the token endpoint for some clients it can mess up other browser and non browser clients. 

A separate endpoint in discovery is a good idea  they can always both point to the same place.

John B.

On 12/17/2018 12:26 PM, Brian Campbell wrote:
While there's been some disagreement about the specific wording etc., there does seem to be general consensus coming out of this WG to, in one form or another, recommend against the use of the implicit grant in favor of authorization code. In order to follow that recommendation, in-browser JavaScript clients will need to use XHR/fetch (and likely CORS) to make requests directly to the token endpoint.

Meanwhile there is the MTLS document utilizes TLS client certificates at the token endpoint for client authentication and/or certificate bound access tokens. The security BCP draft even recommends sender/key constrained access tokens and MTLS is close to the only viable way to do that at this time.

Unfortunately, however, these two things don't play very nice together. When a browser makes a TLS connection where a client cert is requested by the server in the handshake, even when client certificates are optional and even when it's fetch/XHR, most/many/all browsers will throw up some kind of certificate selection interface to the user.  Which is typically a very very bad user experience. From a practical standpoint, this means that a single deployment cannot really support the MTLS draft and have in-browser JavaScript clients using authorization code at the same time.

In order to address the conflict here, I'd propose that the MTLS draft introduce a new optional AS metadata parameter that is an MTLS enabled token endpoint alias. Clients that are doing MTLS client authentication and/or certificate bound access tokens would/should/must use the alternative token endpoint when present in the AS's metadata. While all other clients continue to use the standard token endpoint as they always have. This would allow for an AS to deploy an alternative token endpoint alias on a distinct host or port where it will request client certs in the TLS handshake for OAuth clients that use it while keeping the regular token endpoint as it normally is for other clients, especially in-browser JavaScript clients.

Thoughts, objections, agreements, etc., on this proposal?

PS Bikeshedding on a name for the metadata parameter is also welcome. Some ideas to start:
token_endpoint_mtls_alias
token_endpoint_mtls
mtls_token_endpoint_alias
mtls_token_endpoint
alt_token_endpoint_mtls
mtls_token_endpoint_alt
a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use
equally_poor_idea_here







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
--------------5CABBC66F31D5DF2C0C0E2B5-- From nobody Mon Dec 17 13:52:19 2018 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 D203B129AB8 for ; Mon, 17 Dec 2018 13:52:16 -0800 (PST) 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 (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 rYdewga-nPq4 for ; Mon, 17 Dec 2018 13:52:14 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 B35E812426A for ; Mon, 17 Dec 2018 13:52:13 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id v13so13842019wrw.5 for ; Mon, 17 Dec 2018 13:52:13 -0800 (PST) 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=vLEuXWiInsJLGl2GqYhpMf8XeusWuNKL+JnDQhsyGyU=; b=W1wb5n4KYvpPAaeHCckMYXgULXOcM0+lAAjgKO6g26nOqgEsQ5D5Wt+ngH/XnLJum3 199JmArpWSnBelAtM82ehYxSLSU7fNHCK0/b9ivrC1rKqstgNRjeZCSm42fBG+GUixxZ XDUCW++uFgqBbRh8F8/KbMI1di25dT2uTiqXc= 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=vLEuXWiInsJLGl2GqYhpMf8XeusWuNKL+JnDQhsyGyU=; b=jBv7sFdAVvKrFFHPcoFEjP6P5pw630heXVMjp1R0xxO7m5ROJkTnAIoWdDPcZ3TLsn wye9lXBICMYGL1HgRh9vCbm5J3YOqT9tQWtscid3u3wYoslpTBrFy456b+2CK4Fd6a+O cLuF0Bkt4a4FT2zgG1uOMCUeeyOYy778pP+hBXqgBZlVd398pMQheDT95Q+2iPeHtG0B RsIIBEHNG/5CksdlTiQz4E+yvf3ZpoadP0tagQpoBu5Llf6GbSTelQ/mJwEZiMo5eSeB waxLX/KHmgtMXZO5inD5xwGZhzRk0F9JgAZY1L81Cctnt1N+s24eTS8fz/GFKLcpqBEp jIBA== X-Gm-Message-State: AA+aEWaYNAzrSzgrgnrVPgwV3v0Ci6nDry9ZUuCtFHXpzgPs2mzGgN7I Oid/Gx243s2qK7mRFO9gasTNCenNykI= X-Google-Smtp-Source: AFSGD/U/gNH4Sv/GtIWF6ffZfjptQgM6U+/+R5nrpOeLDzwlFdpRq5iVMltGnfSpnWLhpiOib1ODMQ== X-Received: by 2002:adf:c38e:: with SMTP id p14mr12174540wrf.68.1545083531998; Mon, 17 Dec 2018 13:52:11 -0800 (PST) Received: from guest2s-mbp.lan (92.150.32.217.dyn.plus.net. [217.32.150.92]) by smtp.gmail.com with ESMTPSA id x20sm708179wme.6.2018.12.17.13.52.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Dec 2018 13:52:11 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Neil Madden In-Reply-To: Date: Mon, 17 Dec 2018 21:52:08 +0000 Cc: oauth Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Campbell X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint 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, 17 Dec 2018 21:52:17 -0000 I am currently running a Tomcat instance that I have configured to = support, but not demand, client certificates using the = certificateVerification=3D=E2=80=9CoptionalNoCA=E2=80=9D setting. With = this config I am able to authenticate a confidential client using mTLS, = and yet connecting to the same server over HTTPS in either Safari or = Chrome on Mac does not prompt me for any certificate. I don=E2=80=99t = have any client certificates configured in my browser, so does this only = happen if you do? Depending on the deployment scenario, it may also be possible to = terminate TLS at a proxy and use a separate proxy for (intranet) mTLS = clients vs public clients, but that may not suit every deployment. =E2=80=94 Neil > On 17 Dec 2018, at 20:26, Brian Campbell = wrote: >=20 > While there's been some disagreement about the specific wording etc., = there does seem to be general consensus coming out of this WG to, in one = form or another, recommend against the use of the implicit grant in = favor of authorization code. In order to follow that recommendation, = in-browser JavaScript clients will need to use XHR/fetch (and likely = CORS) to make requests directly to the token endpoint. >=20 > Meanwhile there is the MTLS document utilizes TLS client certificates = at the token endpoint for client authentication and/or certificate bound = access tokens. The security BCP draft even recommends sender/key = constrained access tokens and MTLS is close to the only viable way to do = that at this time.=20 >=20 > Unfortunately, however, these two things don't play very nice = together. When a browser makes a TLS connection where a client cert is = requested by the server in the handshake, even when client certificates = are optional and even when it's fetch/XHR, most/many/all browsers will = throw up some kind of certificate selection interface to the user. = Which is typically a very very bad user experience. =46rom a practical = standpoint, this means that a single deployment cannot really support = the MTLS draft and have in-browser JavaScript clients using = authorization code at the same time.=20 >=20 > In order to address the conflict here, I'd propose that the MTLS draft = introduce a new optional AS metadata parameter that is an MTLS enabled = token endpoint alias. Clients that are doing MTLS client authentication = and/or certificate bound access tokens would/should/must use the = alternative token endpoint when present in the AS's metadata. While all = other clients continue to use the standard token endpoint as they always = have. This would allow for an AS to deploy an alternative token endpoint = alias on a distinct host or port where it will request client certs in = the TLS handshake for OAuth clients that use it while keeping the = regular token endpoint as it normally is for other clients, especially = in-browser JavaScript clients.=20 >=20 > Thoughts, objections, agreements, etc., on this proposal? >=20 > PS Bikeshedding on a name for the metadata parameter is also welcome. = Some ideas to start: > token_endpoint_mtls_alias > token_endpoint_mtls > mtls_token_endpoint_alias > mtls_token_endpoint > alt_token_endpoint_mtls > mtls_token_endpoint_alt > = a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_sho= uld_use > equally_poor_idea_here >=20 >=20 >=20 >=20 >=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._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Dec 17 14:10:51 2018 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 A8ACB129AB8 for ; Mon, 17 Dec 2018 14:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-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=ve7jtb-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 lfEP4-dBvlSH for ; Mon, 17 Dec 2018 14:10:47 -0800 (PST) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (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 25663126C01 for ; Mon, 17 Dec 2018 14:10:47 -0800 (PST) Received: by mail-qk1-x742.google.com with SMTP id q1so8301776qkf.13 for ; Mon, 17 Dec 2018 14:10:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=axg+i75JXtbN+w+V36MKV78RGQNUOIXs/De/TQG7N7o=; b=VrkinFo+pL9ot26YpFrvByN6MqqhZrwCyws4GxTj2YDrhl5xlI/HZqS96uYpEJLvQ/ 7qJaIF5jWoZqWgyomMCqMnn8HWPwjhHsuy8gb/BtT1a2K/beY0yN8ElrXEnZrvN37gda zcF8DR0sum7KWi187qiM9v3qp8dztLDvt3bYVUHI3OYkHybNEK5w9SgRef2tnuQalsaT w3exR3Zny04rPS26plqLrd0Li5ai11t5tVNGzf+zoZEKSlPrktRa9EYTjmc/ZoVGbb1D OjhitkfDMNWAtFod8bZ8AStafoouzvFAmjSb44bRuW8K2l7o/qd7KpnaIX3av4O7VEHd rHsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=axg+i75JXtbN+w+V36MKV78RGQNUOIXs/De/TQG7N7o=; b=E/5h86MlXR0p1u/3bMrNBxHGMQW1OsBOdoQS34j2eNcCAwRvYvYe1Q0IGLZLxZKVOT LAKbxxklDwR+/EAqIbZTrtCtUcYBfO7a1+7Hxgx6UlmMgT5YjE2+GQhjHWavGUVt3GhC 6geLJbMC9kRUv1u9a3IGdQJOg06XMstb5TLtNb/VrZSeRw9VxCYEeAbcoS9syDlNOduK bSgLfkLXjDpuaruNDRPZS6tYQ3k6AB9hPQWoJYYUaA5WJy4G3L++idEUQDkIpFBIU4Iq Iot4GUsSIjKlZRkqk4eMZ9VOiOpg12iU70g+cnLH8PGuPP8LNP/Rrhsera3Zhh4bGazR +AMg== X-Gm-Message-State: AA+aEWZ/OBWU/pBYBSF/Ap4vAEpZqbBEtzr75Zha2HjfkV825dUPKZqK FVuhcQ+q1WgNMY12W9UV/soVG9+YUJIBQA== X-Google-Smtp-Source: AFSGD/W1mV8jwsP5ycFV3Fw1qZaBkJhdyB2Mcg0E8ChkigTamE/EhVIRgqOnr4oHs2+W+P9uhL+T9g== X-Received: by 2002:a37:be02:: with SMTP id o2mr14065196qkf.133.1545084645347; Mon, 17 Dec 2018 14:10:45 -0800 (PST) Received: from [192.168.8.100] ([181.203.54.145]) by smtp.gmail.com with ESMTPSA id q38sm8374164qtj.65.2018.12.17.14.10.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Dec 2018 14:10:44 -0800 (PST) From: John Bradley X-Google-Original-From: John Bradley To: oauth@ietf.org References: Message-ID: <74c76953-72fb-ae77-d27b-faf97d7905ef@ve7jtb.com> Date: Mon, 17 Dec 2018 14:10:44 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Thunderbird/64.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint 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, 17 Dec 2018 22:10:50 -0000 I think that works for those browsers if no certificates are installed for the browser.   We should test, but I think if any certificates are available to the browser then it will prompt. John B. On 12/17/2018 1:52 PM, Neil Madden wrote: > I am currently running a Tomcat instance that I have configured to support, but not demand, client certificates using the certificateVerification=“optionalNoCA” setting. With this config I am able to authenticate a confidential client using mTLS, and yet connecting to the same server over HTTPS in either Safari or Chrome on Mac does not prompt me for any certificate. I don’t have any client certificates configured in my browser, so does this only happen if you do? > > Depending on the deployment scenario, it may also be possible to terminate TLS at a proxy and use a separate proxy for (intranet) mTLS clients vs public clients, but that may not suit every deployment. > > — Neil > >> On 17 Dec 2018, at 20:26, Brian Campbell wrote: >> >> While there's been some disagreement about the specific wording etc., there does seem to be general consensus coming out of this WG to, in one form or another, recommend against the use of the implicit grant in favor of authorization code. In order to follow that recommendation, in-browser JavaScript clients will need to use XHR/fetch (and likely CORS) to make requests directly to the token endpoint. >> >> Meanwhile there is the MTLS document utilizes TLS client certificates at the token endpoint for client authentication and/or certificate bound access tokens. The security BCP draft even recommends sender/key constrained access tokens and MTLS is close to the only viable way to do that at this time. >> >> Unfortunately, however, these two things don't play very nice together. When a browser makes a TLS connection where a client cert is requested by the server in the handshake, even when client certificates are optional and even when it's fetch/XHR, most/many/all browsers will throw up some kind of certificate selection interface to the user. Which is typically a very very bad user experience. From a practical standpoint, this means that a single deployment cannot really support the MTLS draft and have in-browser JavaScript clients using authorization code at the same time. >> >> In order to address the conflict here, I'd propose that the MTLS draft introduce a new optional AS metadata parameter that is an MTLS enabled token endpoint alias. Clients that are doing MTLS client authentication and/or certificate bound access tokens would/should/must use the alternative token endpoint when present in the AS's metadata. While all other clients continue to use the standard token endpoint as they always have. This would allow for an AS to deploy an alternative token endpoint alias on a distinct host or port where it will request client certs in the TLS handshake for OAuth clients that use it while keeping the regular token endpoint as it normally is for other clients, especially in-browser JavaScript clients. >> >> Thoughts, objections, agreements, etc., on this proposal? >> >> PS Bikeshedding on a name for the metadata parameter is also welcome. Some ideas to start: >> token_endpoint_mtls_alias >> token_endpoint_mtls >> mtls_token_endpoint_alias >> mtls_token_endpoint >> alt_token_endpoint_mtls >> mtls_token_endpoint_alt >> a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use >> equally_poor_idea_here >> >> >> >> >> >> >> >> 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Dec 17 14:37:08 2018 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 96C9112D4E6 for ; Mon, 17 Dec 2018 14:37:06 -0800 (PST) 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, MIME_QP_LONG_LINE=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=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 6Q6zgajMtU4n for ; Mon, 17 Dec 2018 14:37:04 -0800 (PST) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 7F1FB12958B for ; Mon, 17 Dec 2018 14:37:04 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id p4so13949404wrt.7 for ; Mon, 17 Dec 2018 14:37:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=1FRXuAqRNtpkXqMZ4rKxslIRKpd4aDGP6xMUy/q7rw4=; b=A/m+WrUAdQ+SDWYaU3t8DxvPjvimzemoO0mh1+ULNjsEAHvvFj1KRBbYOcV4LkMgG2 8k2ZQ+O8ngzPkAvzEV7aXbxiG84KflLB87taiLxFuCPFta88K0JIfDhE2QYXbOQw8i4R sc0Z6gIxeOn4RK8oEftPErQo/PQ1T7xUYdZW1DCqUXa8HzwrDuZK8ilOoZP/4oKtneWT verBoIs6DvTMp74cTF98w6NdTDYE6X0L6jmGg+zReYeU8OXUjb8SfvPpRgRHoQ0NvNlt 3s7i2UYXPOlqw+xt2A1tTA/uhhrQY2jSpOM/E2W/GgWdLMgtJkh7p346LfYNmfb3sUD5 Cazw== 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:references:in-reply-to:to; bh=1FRXuAqRNtpkXqMZ4rKxslIRKpd4aDGP6xMUy/q7rw4=; b=TMkY6CYoVQwHAXx8Yw4c1myMoo/qJIllG5+iJuHu7t9tNiHT/vudTKgDMZjCqfcUSP yYXsWYyuyCN/7MjCXjPY7UmcNDMADk6WOwDH5z56Sa5CDRS1b/qQF8GPNGoF2feYs3aM XZTWrI2o08DYhFLt0jda78Aq/+cwd9NHcrixZN7O7kvWWL0fmQRN+8V0bSPkWKMKMiBf EW5M7OTyCc6vx1lM0RqHMNZIXrTstRJnnEeL+AVDOFMexqjhy891uZy4J/gvTbDEOcoR dqSlpgZr7+lL1kilbOQjCRR0H5R+jDkqMN7Tsm2Ql4Nj+Qmh675lsJhLz+p8GiUrkJ4A 0PNw== X-Gm-Message-State: AA+aEWb8S3c1knXXL5jGJUJKP2Ch4+bHsktU4XnlrJL7zt5fwufPNtHM SVCUARpD+RtKTBjskVsJAsnpopM= X-Google-Smtp-Source: AFSGD/Uh0ZHQxkX9DNLWdvXKWx2C5AXy3KJR0Vg4Sq8uEZwayO5ZPPY/5GWhZpSao//Fd5RkjrzrfQ== X-Received: by 2002:adf:dd06:: with SMTP id a6mr13044265wrm.2.1545086222783; Mon, 17 Dec 2018 14:37:02 -0800 (PST) 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 t5sm455343wmd.15.2018.12.17.14.37.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Dec 2018 14:37:01 -0800 (PST) From: Filip Skokan Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Mon, 17 Dec 2018 23:37:00 +0100 Message-Id: References: <74c76953-72fb-ae77-d27b-faf97d7905ef@ve7jtb.com> In-Reply-To: <74c76953-72fb-ae77-d27b-faf97d7905ef@ve7jtb.com> To: John Bradley , oauth@ietf.org X-Mailer: iPhone Mail (16B92) Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint 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, 17 Dec 2018 22:37:07 -0000 Correct. If there are certs installed on the device the browsers are likely g= oing to prompt.=20 Having at least one CA configured together with optional_no_ca (even if its a= CA noone ever has certs for) additionally omits the prompt for some client c= onfigurations.=20 Odesl=C3=A1no z iPhonu 17. 12. 2018 v 23:10, John Bradley : > I think that works for those browsers if no certificates are installed for= the browser. We should test, but I think if any certificates are availabl= e to the browser then it will prompt. >=20 > John B. >=20 >=20 >> On 12/17/2018 1:52 PM, Neil Madden wrote: >> I am currently running a Tomcat instance that I have configured to suppor= t, but not demand, client certificates using the certificateVerification=3D=E2= =80=9CoptionalNoCA=E2=80=9D setting. With this config I am able to authentic= ate a confidential client using mTLS, and yet connecting to the same server o= ver HTTPS in either Safari or Chrome on Mac does not prompt me for any certi= ficate. I don=E2=80=99t have any client certificates configured in my browse= r, so does this only happen if you do? >>=20 >> Depending on the deployment scenario, it may also be possible to terminat= e TLS at a proxy and use a separate proxy for (intranet) mTLS clients vs pub= lic clients, but that may not suit every deployment. >>=20 >> =E2=80=94 Neil >>=20 >>> On 17 Dec 2018, at 20:26, Brian Campbell wrote: >>>=20 >>> While there's been some disagreement about the specific wording etc., th= ere does seem to be general consensus coming out of this WG to, in one form o= r another, recommend against the use of the implicit grant in favor of autho= rization code. In order to follow that recommendation, in-browser JavaScript= clients will need to use XHR/fetch (and likely CORS) to make requests direc= tly to the token endpoint. >>>=20 >>> Meanwhile there is the MTLS document utilizes TLS client certificates at= the token endpoint for client authentication and/or certificate bound acces= s tokens. The security BCP draft even recommends sender/key constrained acce= ss tokens and MTLS is close to the only viable way to do that at this time. >>>=20 >>> Unfortunately, however, these two things don't play very nice together. W= hen a browser makes a TLS connection where a client cert is requested by the= server in the handshake, even when client certificates are optional and eve= n when it's fetch/XHR, most/many/all browsers will throw up some kind of cer= tificate selection interface to the user. Which is typically a very very ba= d user experience. =46rom a practical standpoint, this means that a single d= eployment cannot really support the MTLS draft and have in-browser JavaScrip= t clients using authorization code at the same time. >>>=20 >>> In order to address the conflict here, I'd propose that the MTLS draft i= ntroduce a new optional AS metadata parameter that is an MTLS enabled token e= ndpoint alias. Clients that are doing MTLS client authentication and/or cert= ificate bound access tokens would/should/must use the alternative token endp= oint when present in the AS's metadata. While all other clients continue to u= se the standard token endpoint as they always have. This would allow for an A= S to deploy an alternative token endpoint alias on a distinct host or port w= here it will request client certs in the TLS handshake for OAuth clients tha= t use it while keeping the regular token endpoint as it normally is for othe= r clients, especially in-browser JavaScript clients. >>>=20 >>> Thoughts, objections, agreements, etc., on this proposal? >>>=20 >>> PS Bikeshedding on a name for the metadata parameter is also welcome. So= me ideas to start: >>> token_endpoint_mtls_alias >>> token_endpoint_mtls >>> mtls_token_endpoint_alias >>> mtls_token_endpoint >>> alt_token_endpoint_mtls >>> mtls_token_endpoint_alt >>> a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_s= hould_use >>> equally_poor_idea_here >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileg= ed material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you._______________________________________________ >>> 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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Dec 18 00:55:12 2018 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 601D91310B8 for ; Tue, 18 Dec 2018 00:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=armh.onmicrosoft.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 Y4J0ko5DwpSO for ; Tue, 18 Dec 2018 00:55:09 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80087.outbound.protection.outlook.com [40.107.8.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A941310E1 for ; Tue, 18 Dec 2018 00:55:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wBq79wF+eIXMklVzcpw74kRB3fuI7J3CxKxNi0MnVxc=; b=p5SwlesbUfkscpYuAPEH/fkVuaAKmaQg1/pHz1ZVst9pvXAMhjrbNOPn63KJ48n3ITir7Txh/NTdpA5gPN9SlmiQP7Ov4RK3xI2+vz7RRgbGqRUzcQb6YVcdv3q6tKB5mU9w9bDMneOWfzXGOZ57AP8zrxE/jLNgB+y/nxrGM6Y= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1325.eurprd08.prod.outlook.com (10.167.197.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.20; Tue, 18 Dec 2018 08:55:06 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8%3]) with mapi id 15.20.1425.023; Tue, 18 Dec 2018 08:55:06 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: expires_in Thread-Index: AdSWrkpx8Dh1mpRHTq2oza7vNrUdcA== Date: Tue, 18 Dec 2018 08:55:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.114.221] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1325; 6:b+VPU3PQVKls5r0olvZbGVuj2YX5yVH+dCYlX0G8oKVRzT9R4A7UDt0aaIM1mxDTJHx8epp6m+NnA7Y/Inahy/xAv5Vj/5l06qGxC9x/ajz3sHSk+P/3ftonVY/O5higeM3ytLrLkgLypBBtNw4gnBBIYc8hbEpjb+fB/mCKLlcmJBkbXBYOl5zCp/10+bqZ10Xz/iHOaPKrDPDdSsBwznDcyZKx408tOm3DMDX/QuWa43qsAGPNVYBuh6p3bs8N7ajPtI9nCrsO5Y6sODuzv3nUIIgU+fZ8T9qkwGzYfdzPUQdQkw3uD+Ql7Yj6hB6p0+zxsHibp5UOyiwuZE4d206v58ZnSIPMsFX+i/s9MGGtJ0q5IpYAHz9Uu2Vfo9pntPii6BYD/i2azLtQS1/M3tp54yWZQCc+aXfisbgRoEEd6A5U/se0sFooSc7TZ9L+iv/ly26vPcRqfYxfIGCXtw==; 5:vvFTHtBroKhr8athd13tR9eIWanaUL5ZRwXiUBDo5C2WZA1/imejqlfocG8IoSJTY6ji2respniTwW4XcRuB9V5csF1izTRgTS9274RCgKi8x/LSyZ0zYUrX1JEwzZyV/QIAdJrNYkJ1FRGEXdu0BvwMouJnrjb1FCoKVCqSuLY=; 7:i/YetPgQk0hxpzNhngMS+gG7m+nzyxCbjD865LRhPR+hY6OMLaksHjMXu5X9ja3nEq9DYjbdfaMGOurKEqht1AK1Gjq2Vqw5bARJS2O7d2XQP6KZT1FiTlOUke43crYVVeu7+yzCH04XztJuCoT0rQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d5f61eaf-b877-42ec-ab6d-08d664c681b3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1325; x-ms-traffictypediagnostic: VI1PR0801MB1325: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(3231475)(944501520)(52105112)(93006095)(93001095)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1325; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1325; x-forefront-prvs: 08902E536D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(346002)(376002)(136003)(189003)(199004)(40434004)(53754006)(6916009)(55016002)(305945005)(74316002)(53936002)(105586002)(14454004)(66066001)(68736007)(5660300001)(8676002)(7116003)(81156014)(7736002)(9686003)(106356001)(81166006)(86362001)(99286004)(8936002)(6436002)(3846002)(316002)(6116002)(33656002)(256004)(5024004)(14444005)(25786009)(7696005)(186003)(478600001)(476003)(71200400001)(26005)(2906002)(486006)(72206003)(6506007)(97736004)(102836004)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1325; H:VI1PR0801MB2112.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-microsoft-antispam-message-info: Ur6bIEld3Mcob0hAPWW4z/z7mRPdIWZD2w2QUbJ3VeyDfYTy6KPudwqAsO5XZJG6ZHD2DKLBqkrALCrmXnm/rtdA/dGPICRtihNoKB+2CDV7ZFOrWWETz72aRNpfmevV5f5sBJSHCplIj6uT9zfpjW6TajQT+3NwKvvOD71GOnce00/y/UNemLG3seDAw8HmHL01yOs0ujPzN1Ila3vbWyhQbsRZtckkSoDWfn4kjZW9t426d60+uOpTStF2GIPLQM0y5wFurVktS6XCJdCx5h89EXV1qUpdrLguWIrMsVjaiFFk7/hwQd43T8qbzjNO spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: d5f61eaf-b877-42ec-ab6d-08d664c681b3 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2018 08:55:06.0591 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1325 Archived-At: Subject: [OAUTH-WG] expires_in 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, 18 Dec 2018 08:55:12 -0000 Hi all, In a recent email conversation on the IETF ACE mailing list Ludwig Seitz su= ggested that the expires_in claim in an access token should actually be man= datory. Intuitively it feels like access tokens shouldn't have an unrestricted life= time. I am curious whether recommendations would be useful here. RFC 6819 talks about the expires_in claim and says: 3.1.2. Limited Access Token Lifetime The protocol parameter "expires_in" allows an authorization server (based on its policies or on behalf of the end user) to limit the lifetime of an access token and to pass this information to the client. This mechanism can be used to issue short-lived tokens to OAuth clients that the authorization server deems less secure, or where sending tokens over non-secure channels. draft-ietf-oauth-security-topics-10 only talks about refresh token expiry. In OpenID Connect the expires_in claim is also optional. Ciao Hannes 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. From nobody Tue Dec 18 01:42:44 2018 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 647B01310E7 for ; Tue, 18 Dec 2018 01:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 rNfj3EcelHdP for ; Tue, 18 Dec 2018 01:42:38 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 75BA7130E66 for ; Tue, 18 Dec 2018 01:42:38 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id u4so14190453wrp.3 for ; Tue, 18 Dec 2018 01:42:38 -0800 (PST) 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=1Lf5ZxM7w+sNrMGqaKA9UVzS4K8lb1t8dZU7l/NRKu4=; b=MEi0haBzNGW37R/joNMQrk4ZUQ1S22JKgFOPZKFIA2z4gxaK31bP8Pz3UcIm+5YJHP IoxIS9JP6hGGjNFQYlJtK7130rM9sYvi7nBqUwszlfrPltRxFQOl3k6Tm5/i2aOQ4E8F NLZdvD9Uqj5Y5Ao/kmsMJpzTjXzpdEelDwHPA= 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=1Lf5ZxM7w+sNrMGqaKA9UVzS4K8lb1t8dZU7l/NRKu4=; b=ZmIQqbPAhnbTrQKogybqM2PTTDkxy0RYSKlUS3Y0nWlFl+pUoNlsAWeALoY4SW4GVi rGSp9mV2Hle2z9iloL0fVaYGOvllAfDrpqJaUiX8lYp9SzyKx7TfLm3S7rgCAj2oA/DU /1DPrycWc0CvYE29tTLSTFXj188b5eINKOfEelBZNy08KURh+gu4TPFVeMuo2jZl2uBZ jlM+HrZdP/6uUVf0q+DoDeNxg/PrG2Gf4vJzlW/e+xbp5b9LrRMzQWxVGrab+Y7HDxd4 o+4jeLjwoHVfKgDDV3IDzYLhbgl3/G5+TL3D9SaM+Jg2oo2pGdk3BMd8aet1gmWtCk4K yh6Q== X-Gm-Message-State: AA+aEWb6uXW4hB7iIJK9OQ4hIiTBXDRgQjmhgror/9B3oCAuoRqqklva 4Dpdc1pIZQdkYYLSp1n/OGL1jQ== X-Google-Smtp-Source: AFSGD/U+Af82RQdxO93WruNIjEGaSPYXALqfh3dGzzAKHjkLWyfVJjnBvwNJ5m9RWsgtFF3ZqxWXrQ== X-Received: by 2002:a5d:4586:: with SMTP id p6mr13538832wrq.69.1545126156643; Tue, 18 Dec 2018 01:42:36 -0800 (PST) Received: from guest2s-mbp.lan (92.150.32.217.dyn.plus.net. [217.32.150.92]) by smtp.gmail.com with ESMTPSA id h62sm1472878wmf.11.2018.12.18.01.42.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 01:42:35 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Neil Madden In-Reply-To: Date: Tue, 18 Dec 2018 09:42:34 +0000 Cc: oauth Content-Transfer-Encoding: quoted-printable Message-Id: <554D5147-3785-40DC-9C5A-188A72FC2354@forgerock.com> References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] expires_in 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, 18 Dec 2018 09:42:42 -0000 This is probably a best practice, but we should be careful to not = oversell the benefits. Unless you measure token lifetime in a small = number of seconds, then it=E2=80=99s doubtful that any realistic attack = will be stopped by this. It=E2=80=99s mostly useful at defending against = opportunistic attacks - e.g. a token accidentally gets logged, but the = logs aren=E2=80=99t examined very often. Sender-constrained/PoP tokens, = avoiding passing tokens in URL parameters, and so on are better defences = against this kind of thing. There are two deployment scenarios when short-lived access token are = essential though: 1. If you are employing the =E2=80=9Cself-contained RS=E2=80=9D model = (no introspection calls to the AS) and are using short-lived access = tokens with a refresh token to force the client to check in with the AS = periodically to allow token revocation. [1] 2. If you are using a blacklisting strategy to token revocation, in = which case having a short token lifetime limits the amount of time you = need to blacklist tokens for. On the other hand, is there ever a valid reason for having an access = token be valid for 10 years or so? [1] https://www.ietf.org/mail-archive/web/oauth/current/msg06687.html =E2=80=94 Neil > On 18 Dec 2018, at 08:55, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > In a recent email conversation on the IETF ACE mailing list Ludwig = Seitz suggested that the expires_in claim in an access token should = actually be mandatory. > Intuitively it feels like access tokens shouldn't have an unrestricted = lifetime. I am curious whether recommendations would be useful here. >=20 > RFC 6819 talks about the expires_in claim and says: >=20 > 3.1.2. Limited Access Token Lifetime >=20 > The protocol parameter "expires_in" allows an authorization server > (based on its policies or on behalf of the end user) to limit the > lifetime of an access token and to pass this information to the > client. This mechanism can be used to issue short-lived tokens to > OAuth clients that the authorization server deems less secure, or > where sending tokens over non-secure channels. >=20 > draft-ietf-oauth-security-topics-10 only talks about refresh token = expiry. >=20 > In OpenID Connect the expires_in claim is also optional. >=20 > Ciao > Hannes >=20 > 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 = the information in any medium. Thank you. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Dec 18 02:11:26 2018 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 4C9B4130E09 for ; Tue, 18 Dec 2018 02:11:25 -0800 (PST) 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_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=auth0.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 YREDNg5FgK5p for ; Tue, 18 Dec 2018 02:11:23 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 A29011310F3 for ; Tue, 18 Dec 2018 02:11:22 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id f23so11775507lfc.13 for ; Tue, 18 Dec 2018 02:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9LEFjllf1U7JIUq1XRs3Vri4ob5Jf4rgLvhCQ6nLji8=; b=P0rWYF/D5VkRWYnyvUIRGitS1tqu3HemEFThwrK1+Wm7K1CdzYj4uP9PH1fIY0niyy 0AV9nte6C1huuSFUQOyPBNrvvrLhrUPhxYdEXy6xxt2QcoHf8xQV0qCr1U8BMLYs420w jvPD2aSxr2vOOGtMmhv5iOhI3sVjGUWwj9DH+HHcdZroM26t4cKIIiWmqWvA7bXdHV+n mfk0ZTdnm4F2yQKBFbh1hqJYDiO/jTNDvlHho3lhNF7gdgtVVivf474rqhrVxIHG1ueX Z3lrUfXkoMz+1hNjrsqvyqYQxVbFFktmeRNqDD9f7RyHYfYKBIyzDc843s4Wjvsu4SvB qilw== 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=9LEFjllf1U7JIUq1XRs3Vri4ob5Jf4rgLvhCQ6nLji8=; b=mAsdcQVW6vL5NTXU9V+Dxw2EiKRaV4hGIE8afkwvB8nkaVFkx11sbdQHxCxAXfVGVs E1kA/0UClG9M9HZ2Iq2jgwxBqp/RJxO1+ioADv6VeQr4DBGuIGULphGIRq6u6wQdk9Fk zXbDn/XUaS+BvFqITpqRWBflQd6sznbeffKRfhZpsBGWiY4GKdW7R1L95LmZZmP3ipXg EW1It+l9KcuBTyC06bdWKGITcBVRKxXpDb33PCk0is1UgHk0CbCND77tg7ltoDnh4QbM ZhIrPLd+ki1Km8/htOzpx1EHO//Sex8FI0LmCmom/yAI1AMwvPvQMvNGhsks2HTh21dB ohzQ== X-Gm-Message-State: AA+aEWb41ZQvJ85JALp2iE2s6iGfc6g+yWne4rghBH+n/ygLWkLXJsh3 pGSqNu8IZg2cbTGqTqK3K559whVE0nxZNILJg6ME1Q== X-Google-Smtp-Source: AFSGD/VKhsy9QFwrWOHZNx9nbICV99TVCWBE/r0Pm0sWx17+hllD+gBDe+Lg1jBI6kJctHkLgdyKSgpUBz3ZHqQkk8Y= X-Received: by 2002:a19:1bd2:: with SMTP id b201mr9078986lfb.136.1545127880395; Tue, 18 Dec 2018 02:11:20 -0800 (PST) MIME-Version: 1.0 References: <554D5147-3785-40DC-9C5A-188A72FC2354@forgerock.com> In-Reply-To: <554D5147-3785-40DC-9C5A-188A72FC2354@forgerock.com> From: Vittorio Bertocci Date: Tue, 18 Dec 2018 02:11:09 -0800 Message-ID: To: neil.madden@forgerock.com Cc: Hannes Tschofenig , IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000071a647057d491e19" Archived-At: Subject: Re: [OAUTH-WG] expires_in 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, 18 Dec 2018 10:11:25 -0000 --00000000000071a647057d491e19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It does sound like a best practice and nearly all the providers I've ever worked with do have an expiration for ATs, however there are counterexamples (most notably, dropbox ) and they seem to be doing fine so far. Do we know anyone on Dropbox that can comment on their use case and whether they'd see value in changing their current behavior? On Tue, Dec 18, 2018 at 1:42 AM Neil Madden wrote: > This is probably a best practice, but we should be careful to not oversel= l > the benefits. Unless you measure token lifetime in a small number of > seconds, then it=E2=80=99s doubtful that any realistic attack will be sto= pped by > this. It=E2=80=99s mostly useful at defending against opportunistic attac= ks - e.g. > a token accidentally gets logged, but the logs aren=E2=80=99t examined ve= ry often. > Sender-constrained/PoP tokens, avoiding passing tokens in URL parameters, > and so on are better defences against this kind of thing. > > There are two deployment scenarios when short-lived access token are > essential though: > > 1. If you are employing the =E2=80=9Cself-contained RS=E2=80=9D model (no= introspection > calls to the AS) and are using short-lived access tokens with a refresh > token to force the client to check in with the AS periodically to allow > token revocation. [1] > > 2. If you are using a blacklisting strategy to token revocation, in which > case having a short token lifetime limits the amount of time you need to > blacklist tokens for. > > On the other hand, is there ever a valid reason for having an access toke= n > be valid for 10 years or so? > > [1] https://www.ietf.org/mail-archive/web/oauth/current/msg06687.html > > =E2=80=94 Neil > > > On 18 Dec 2018, at 08:55, Hannes Tschofenig > wrote: > > > > Hi all, > > > > In a recent email conversation on the IETF ACE mailing list Ludwig Seit= z > suggested that the expires_in claim in an access token should actually be > mandatory. > > Intuitively it feels like access tokens shouldn't have an unrestricted > lifetime. I am curious whether recommendations would be useful here. > > > > RFC 6819 talks about the expires_in claim and says: > > > > 3.1.2. Limited Access Token Lifetime > > > > The protocol parameter "expires_in" allows an authorization server > > (based on its policies or on behalf of the end user) to limit the > > lifetime of an access token and to pass this information to the > > client. This mechanism can be used to issue short-lived tokens to > > OAuth clients that the authorization server deems less secure, or > > where sending tokens over non-secure channels. > > > > draft-ietf-oauth-security-topics-10 only talks about refresh token > expiry. > > > > In OpenID Connect the expires_in claim is also optional. > > > > Ciao > > Hannes > > > > 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000071a647057d491e19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It does sound like a best practice and nearly all the prov= iders I've ever worked with do have an expiration for ATs, however ther= e are counterexamples (most notably, dropbox) and they seem to be doing fi= ne so far.
Do we know anyone on Dropbox that can comment on their u= se case and whether they'd see value in changing their current behavior= ?

On Tue, Dec 18= , 2018 at 1:42 AM Neil Madden <neil.madden@forgerock.com> wrote:
This is probably a best practice, but we shoul= d be careful to not oversell the benefits. Unless you measure token lifetim= e in a small number of seconds, then it=E2=80=99s doubtful that any realist= ic attack will be stopped by this. It=E2=80=99s mostly useful at defending = against opportunistic attacks - e.g. a token accidentally gets logged, but = the logs aren=E2=80=99t examined very often. Sender-constrained/PoP tokens,= avoiding passing tokens in URL parameters, and so on are better defences a= gainst this kind of thing.

There are two deployment scenarios when short-lived access token are essent= ial though:

1. If you are employing the =E2=80=9Cself-contained RS=E2=80=9D model (no i= ntrospection calls to the AS) and are using short-lived access tokens with = a refresh token to force the client to check in with the AS periodically to= allow token revocation. [1]

2. If you are using a blacklisting strategy to token revocation, in which c= ase having a short token lifetime limits the amount of time you need to bla= cklist tokens for.

On the other hand, is there ever a valid reason for having an access token = be valid for 10 years or so?

[1] https://www.ietf.org/mail-archi= ve/web/oauth/current/msg06687.html

=E2=80=94 Neil

> On 18 Dec 2018, at 08:55, Hannes Tschofenig <Hannes.Tschofenig@arm.com> = wrote:
>
> Hi all,
>
> In a recent email conversation on the IETF ACE mailing list Ludwig Sei= tz suggested that the expires_in claim in an access token should actually b= e mandatory.
> Intuitively it feels like access tokens shouldn't have an unrestri= cted lifetime. I am curious whether recommendations would be useful here. >
> RFC 6819 talks about the expires_in claim and says:
>
> 3.1.2.=C2=A0 Limited Access Token Lifetime
>
>=C2=A0 =C2=A0The protocol parameter "expires_in" allows an au= thorization server
>=C2=A0 =C2=A0(based on its policies or on behalf of the end user) to li= mit the
>=C2=A0 =C2=A0lifetime of an access token and to pass this information t= o the
>=C2=A0 =C2=A0client.=C2=A0 This mechanism can be used to issue short-li= ved tokens to
>=C2=A0 =C2=A0OAuth clients that the authorization server deems less sec= ure, or
>=C2=A0 =C2=A0where sending tokens over non-secure channels.
>
> draft-ietf-oauth-security-topics-10 only talks about refresh token exp= iry.
>
> In OpenID Connect the expires_in claim is also optional.
>
> Ciao
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments are c= onfidential and may also be privileged. If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the informatio= n in any medium. Thank you.
>
> _______________________________________________
> 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
--00000000000071a647057d491e19-- From nobody Tue Dec 18 03:59:14 2018 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 A4D45130E19 for ; Tue, 18 Dec 2018 03:59:12 -0800 (PST) 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, 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 y6Iu354mgZy2 for ; Tue, 18 Dec 2018 03:59:10 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6B736128B14 for ; Tue, 18 Dec 2018 03:59:10 -0800 (PST) Received: from [172.20.4.108] (unknown [12.108.40.131]) by alkaline-solutions.com (Postfix) with ESMTPSA id 194B331571; Tue, 18 Dec 2018 11:59:08 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: David Waite In-Reply-To: Date: Tue, 18 Dec 2018 06:59:07 -0500 Cc: oauth Content-Transfer-Encoding: quoted-printable Message-Id: <66E27956-1627-46B5-AF60-B7F0CD631513@alkaline-solutions.com> References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] expires_in 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, 18 Dec 2018 11:59:13 -0000 My understanding was that this parameter was advisory to the client - it = neither mandated the client discard the token after the expires_in time, = nor has a requirement that the token is no longer honored by protected = resouces at that point in time (vs earlier or later). Is there meaning that others assign to this value? The only use I=E2=80=99= ve found is to schedule proactive refreshes to hopefully reduce latency = by reducing the need to refresh in-line with user requests. -DW > On Dec 18, 2018, at 3:55 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > In a recent email conversation on the IETF ACE mailing list Ludwig = Seitz suggested that the expires_in claim in an access token should = actually be mandatory. > Intuitively it feels like access tokens shouldn't have an unrestricted = lifetime. I am curious whether recommendations would be useful here. >=20 > RFC 6819 talks about the expires_in claim and says: >=20 > 3.1.2. Limited Access Token Lifetime >=20 > The protocol parameter "expires_in" allows an authorization server > (based on its policies or on behalf of the end user) to limit the > lifetime of an access token and to pass this information to the > client. This mechanism can be used to issue short-lived tokens to > OAuth clients that the authorization server deems less secure, or > where sending tokens over non-secure channels. >=20 > draft-ietf-oauth-security-topics-10 only talks about refresh token = expiry. >=20 > In OpenID Connect the expires_in claim is also optional. >=20 > Ciao > Hannes >=20 > 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 = the information in any medium. Thank you. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Dec 18 04:18:04 2018 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 4589C128B14 for ; Tue, 18 Dec 2018 04:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=risecloud.onmicrosoft.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 SuczTidDPsWf for ; Tue, 18 Dec 2018 04:17:59 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60046.outbound.protection.outlook.com [40.107.6.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8A9C1274D0 for ; Tue, 18 Dec 2018 04:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DcIhOR4KEf+wt0YvnfZJNy4dVwAFhYXz0pcuf+TxxC0=; b=OcNvanoCPLNHgTNbXYSsNkED01UA0d+RL1nzcrLV5hibhh8lk4v7kXriewhrvF/k+HsRkoJVjwLOLhpOPDMuDXbYSfKIpjqbtn+YPVK/x17SwbjCjyGqUCGLzmVNvZSCOkSpbptdSTkDu8WVEqkniLi6r3ppdVgriDGlm6+A0sI= Received: from DB6P189CA0013.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:2e::26) by DB6P18901MB0101.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:26::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.17; Tue, 18 Dec 2018 12:17:56 +0000 Received: from AM5EUR02FT031.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::206) by DB6P189CA0013.outlook.office365.com (2603:10a6:6:2e::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1446.17 via Frontend Transport; Tue, 18 Dec 2018 12:17:56 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by AM5EUR02FT031.mail.protection.outlook.com (10.152.8.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1446.11 via Frontend Transport; Tue, 18 Dec 2018 12:17:55 +0000 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 18 Dec 2018 13:17:55 +0100 To: References: <66E27956-1627-46B5-AF60-B7F0CD631513@alkaline-solutions.com> From: Ludwig Seitz Message-ID: <2ef34983-31b1-9b2a-a28f-ff4e14b2045d@ri.se> Date: Tue, 18 Dec 2018 13:17:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <66E27956-1627-46B5-AF60-B7F0CD631513@alkaline-solutions.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(396003)(346002)(376002)(136003)(2980300002)(189003)(199004)(67846002)(50466002)(7736002)(65826007)(8936002)(106466001)(31686004)(69596002)(36756003)(117156002)(230700001)(486006)(2906002)(81156014)(68736007)(81166006)(2616005)(476003)(508600001)(44832011)(97736004)(6116002)(3846002)(336012)(74482002)(446003)(11346002)(126002)(26005)(106002)(33896004)(2486003)(356004)(86362001)(8676002)(305945005)(23676004)(5660300001)(186003)(16576012)(58126008)(16526019)(53936002)(64126003)(76176011)(77096007)(316002)(14444005)(6916009)(22746007)(6246003)(2351001)(386003)(104016004)(65956001)(22756006)(65806001)(31696002)(53546011)(47776003)(40036005)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P18901MB0101; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; AM5EUR02FT031; 1:lUVr0bVnKqgPcCpooHTdqFeXAJz2k9eoxulWUn9tMEf9BFz/x3Se4RBsiIBNqHow+LGHY+dRVdLmSyPYtYMtvzWyD2xlH/UhCSS4cFt018QDpOrzLY6C2Iyj9GaQcrsO X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 389bd166-56c0-4e10-6410-08d664e2d74f X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:DB6P18901MB0101; X-Microsoft-Exchange-Diagnostics: 1; DB6P18901MB0101; 3:xTJz8e2XqsadOq05h9tCWwbza87AkQMdVRZSu/8rJ4Yq9N6ovqAk8JhrO2FNBz1sgNiXnmdLoqMD5TTIaFoGPCofnHmHroOXgKKguxjCWrAU9urhkc+/+Itt+sT7h4YUSgnT7aRBItpvPrPwDx0iPkUjpx26g7cVAHpZ0mzbWS2CIopm4+/BY8FzF+X0323OzVAWRuT8Ktg6ciW4Dm9Nub/fjRbL0v/mBTzAmBpXa87+dUI3aKzfOdJ/105g8HBKri1pL8oAaAw27alQvGxuD591PHgeCmovyj1zZFPOjp9/UPgxpr29+OYQagqVgOqL7VYswDu+aZ1VJZlgpyIG2/x/DwuR5VM36Sez4RIoIAM=; 25:55KhII110UfD8H+uv+EEr53FVyMPYZbmCFWMIO1wAoNv9J75wxXBP2OpycyRZXBvmCXUO0KSovDJE5Wcx7GEbBGHd93pr0pm2fLOHJHV157alUNapBmm9QO84roqe9m530m6NpSMXD+ip2yLBn4riBJV9FYKp65KJSrasYq4OiBG9L0TJtJ9YVN++HTC/MqCpI52jVVlvwcrH4ANWJRAH8NmkzoMvio75rIy/PnGR43llZ3nq1UUwIwB2/RIvfoKv0PnsksXZGYDmSHDktT7QAUShNdsHztwcdMxMzzGoCPpYjd2d2gTG7A9JAxR0iwonBobEp7y+6islEXQ1r9iHQ== X-MS-TrafficTypeDiagnostic: DB6P18901MB0101: X-Microsoft-Exchange-Diagnostics: 1; DB6P18901MB0101; 31:U/6Gw2SFcn1ySVkMK2BY1td5XxHQzpdPlbNulbc8B5cbCCRpcIdWtc0oU+MP+44fSIbRiFqJNGyEnd9dVyGxi3Akyv//0ad5cluhyoKy/Srvd/mEFYgh5a1h6OL6Oof6RVEzot96hPQ1KfCyFr4qEBVchXgDmsg5gX2afnoUveV+VfvDaRQ6NgoK3dq7C4hVt9NwZWZekiaA11Md7eigSzgVl8hJKr3b460NFgx6N9Y=; 20:cDDu/lOB5V33uQOc5311/XQhOEu2Gyb/o8b1lW93KQNvrem3Ic6K9Zw6T37qjklRUwvnVF7WT5Lv2Q8F4QvtXnC3PCnQtBnNiT3HCmDvvSkIqXD+dmBRwaTVRT+jBFvOKBDxV30qYbs4UYT3AJtWM0ydaXV5KHVylsUlpn2XzUc9eqZBqZaKZizwHlP3yDDG2hD6VSHMhRWNTTUniEp85OseUbJcaHLb2et6j2S9E4fHK4Iyig/LdT3RxgKRZLL5; 4:Zc6vv97CeRLMopYFF/ZcPhdcd4mWnY6kSwNXuYwE5Ay+aPNF7NJU6brD2n8HvYHEyyVxPE4KfBH9IP99b25cFS2K+jdf8BnZM8DlbLULUFRh2pBw0QydENph3eGyk8ycVm4D4wUBrJcviu5ME6LJCKKpFGAq6VnYaOKxOzwgwxJ5ZPQJJolUJwoKv3Llw9Sg0iZKzalVZ2BUOUsKUO1TsA2iEW4zAKRgcN3+/5Oe8sx6NR9Kbr1vmpcQDxEIae8bviopsj8As+BcMtRcNRL05w== X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(3230021)(999002)(6040522)(2401047)(5005006)(8121501046)(3231475)(944501520)(52105112)(93006095)(93004095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(2016111802025)(20161123558120)(20161123560045)(6043046)(201708071742011)(7699051)(76991095); SRVR:DB6P18901MB0101; BCL:0; PCL:0; RULEID:; SRVR:DB6P18901MB0101; X-Forefront-PRVS: 08902E536D X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQMTg5MDFNQjAxMDE7MjM6eFNodUpKdFVGeHdWSU5ucGN3d2dldjhv?= =?utf-8?B?cVZvK3ZYTGk1a3pvcFU3UjFBRXI1b1hCczF2UE5ZK3pWRldqenJ6TTBiYno3?= =?utf-8?B?VVpGd1lweFoxRC9TaE9TaHlwdHczeUZTcnpqZWdaTUtIbGdVbjN0MHRPMTZo?= =?utf-8?B?MVBMN2tkOVZJNERkRlZha0RwdFR6ckEwbU1Xcjh2djBTSFJjb0pWVTgvTENj?= =?utf-8?B?QVo3Z2VKbFdyTEJVZy9rTVEzeTVXSjZBUnd5aEVLSFRUclI2eGNmcUFKMWl6?= =?utf-8?B?RW52QXZpRWRxMTU2Zlo2Y0E1NjV2L3UvNnRkOUcwdGtIWEhzZTVLcHdteVFj?= =?utf-8?B?R0w4bHhRcEZpYmc4dVFzbHlRK25EQk1RY1NEVlljd1lPa0tOZUJYNDFaMUFm?= =?utf-8?B?ZTZHYkRaOXc1dkczdE9BNVlwSm1XV01RRStoNDBjeDRRblhpWXBHWHFWWWd3?= =?utf-8?B?L2h5NFQzRnlsZ3o3TEZEWElDODZKM2dJNlVQSVQ5aXl0STRDdVJKVGUrc1NY?= =?utf-8?B?T2NrQnRRZUl6dFdpdW5zcHoxdWxqS2hsTVhCSTgxa0lvZlNxM1g5SzRXUElm?= =?utf-8?B?YTNKYlJaeG9nTW01RVFzUDVkd1QxVVYzWm9oUzRWNGh1LzlhTThPMDJGOEZH?= =?utf-8?B?c3RjWUdOKzd1bEJFNlp2RTFFaGlKYzFMYWVCVXlLUmNINS9sM2pzNXFYWGRZ?= =?utf-8?B?NVZWOXlqTVFZZ3hRUzdBMzlSak5VdXIrcmdKeHliWW56ekNYT2xuSlJvUUIy?= =?utf-8?B?RkFGbGhWSHVVYWpicS9YOXJPTW52N1dnNUs1YVlkajRpT3B1VXRPV0w1ZG4r?= =?utf-8?B?UFZjOTJJVWVDcFFVZld4NDA3dUhUbndIa0QveHFBWDU4QmhYc0ZRVzRpUldV?= =?utf-8?B?QXFRMUFVTWtuVFJFa0d0ck1VYldDazhqM2daREJHVmNJaFpmWnVwdzlIRzll?= =?utf-8?B?SVpBU1VvOHR1d28zYzVnREh2cUxOLzRIZFJMeEJDMFV6MUpqZHVSNVNyVUUr?= =?utf-8?B?SXVhU08yc2ZYbTFkaTNvT3dBSWowVUxOc3JQd2QyYjlEVFlkMFNFK2gvblFL?= =?utf-8?B?dWkvYmZJaFc1L0hJSmhTVHBZOEV2eE9hRitPMUlodnNxM2ZBb2lZeTdxVG1x?= =?utf-8?B?a2JvSElNcW13OVhuUzRsNWJRY2ZvOHFLMW9oR2hUb1ZuMm1GSHFUN1Ayb1FN?= =?utf-8?B?anNITGJrS1A3RTczdGlBMzN4QWFITjVLZWFJTXJxbUx2TUUxU3V6VzVtMERS?= =?utf-8?B?WDlmTzFlWFJuNUtvOUZRekZwbW92NUl2c1FvdllUaHF1SkFucCtGVEFDU3lo?= =?utf-8?B?QWpUanAzdUowQ2xJSm04b0R3b3pzUFU1MnVHYkdSRmtHd3BiekNLbnpPVVFU?= =?utf-8?B?Rm5PRFRqY3RsSXlKNXBWVE1oc08vd1JiaVdtdUcrYlBJNVdLd1R0ZkEzam9n?= =?utf-8?B?RnIzTUtqQ1RZTXJOM01zS2ZJWk1UTE1wT3N5MEF4RUNPNFFha0ZDYlloUThI?= =?utf-8?B?djBpQUs0MjA3ZEpKTXdQc3pTaGMzMmlreHdYQ0JOZGlSaFZEOGllQ3JDV3lN?= =?utf-8?B?Qy8vU1dHa2JWSGNRaVJNQXFDSEd0dm9mOEQvdjNFSHdLZWtRVVo1M3NQeHR6?= =?utf-8?B?dnRmQW9XSW4zT0cxRUNmeWxLK1NuK2xwbGo4MkhkVFdqcDY4M1dJVVEveGps?= =?utf-8?B?SXlNejJpTVNHTHFqMFpLdEtHSmI1ZzVhZkZIVHVIejBSbnFydm5GdU1PQTZD?= =?utf-8?B?UkdaNTBWVGs4QytsVkRwVVE1a2l0L3BPK1lsZTJwRkNkVTNobVp0NkRubkN6?= =?utf-8?B?NDZ3bnVDemNVSEdqUHZFcHo4akZGeWFMbkZVaXJDZEtUcjZJS0taTXlMNHVG?= =?utf-8?B?NjNtVG5aZzlmUXloYU11dmYzdks2bytPOEcrV1BJTnBVRzlIVCtkVFdGdGtO?= =?utf-8?B?TEczQTM3L0JRa1JKcGhqT1NmTlNhQUlHMUUxOTFZTUFmMkJDLytFOG9VWVJH?= =?utf-8?B?KzAxK2JuUHErVFR2bUtCT3pxWVFwNGlmNk4vZEJ2c3FKNUFFOWRYQUZzUHJM?= =?utf-8?Q?EEyDE9fok/CaCV33nLCJ0mWcEDy?= X-Microsoft-Antispam-Message-Info: fSS6+HJfatIVkqetL4sHXt2EhvfflLsMiN7mgQ80rlcp+4YCdSekIhMLkZ+Yjkoeb/ETty/VzCynJzjaKB54AnsWgJiRbgtpfNZODji4oh951ag2i9LYDRzQjPVBFBZiUje/agCyN1woSYlY7wcQoGRIrjxlkCh8yiuFp4u73Ghs0X63ZdUGWIob+4PLUDiWoyFnSO5ii49Aw3vxeQnTFUPTdAsif1TK9Iof9LpBe9ueJgbtChXiM6ogjELcbmE3N0NnWk/zU8uuugRjUfNxcD/LrHd5wCmXxDW0rlFi6RVaYzSHN68CoYdZggsngnmG X-Microsoft-Exchange-Diagnostics: 1; DB6P18901MB0101; 6:UPKJGc+sjwtqGUAtDwhN0uAUbpBp203NM1VfbALTGrqdljmFkZbAmuZrtpT7IA2cjGk2HcbdTyTmrlEt2FgL6riGiO/zxFvUx89gyOYg6VeNcWUs+zTxXNIcwGj+2xOXPfB4TNyfyKl64QZu6+Bhy10lDZmX6vlOSN2daugeGnNGvsXzdJru1pU9w0Dmk1p8g9RVRm+TnP6Bb5jRUIngd+jL33NT7+OQ6PAP+FZEDq1We3uTumCzsgPk+2nFdUDEsCyjG2qWR2qHU+HRInDfXApE+XhgEMawAyyDCqtWBSFEJLLzitbRkaHpkKtdI6ScWWVW6EytTMEu+309hdxorYJeztkhop1RbOI4NyTNUTbKTCGIWSuNKN4VFomDxvTtYe0dW5d1vBD5fTdWQ1nv22uq6FsYXuWMsx36FJyNAyrJYWoMUDPPEllfE3eOs/n0xZrCt77wxV5NOZT2LH2nnQ==; 5:qRWtxdmpU13ytLhkCrPeSF+jyhqa8c7tFQF8YNylzNFLR+o2yWjRMfFn8H+I5Nk/yiOJOVNBORGcUsUSMcSeMIahtWeFMuWjIc3NCUFLP0uwibJyaw8SVrY+9FHHipHVMaKJhbQl7P+CURlRTfwHPbdQnKLgcgZQlA8xDD83zuI=; 7:2SkB84KiblwE5/yxPQgtzCQ/COndYd4hx6XVVfymv8dEMiMZ5rDfsoBI6R8sgtBnhf9vh1zimC+hmUHmpUb6dwv2c0SyCJLWj9qUlEK8zzTHYWjvbh3Yexn3ZSyMI8nfmVpFNGZTWAgndc9++pZsng== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2018 12:17:55.6413 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 389bd166-56c0-4e10-6410-08d664e2d74f X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0101 Archived-At: Subject: Re: [OAUTH-WG] expires_in 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, 18 Dec 2018 12:18:02 -0000 On 18/12/2018 12:59, David Waite wrote: > My understanding was that this parameter was advisory to the client - > it neither mandated the client discard the token after the expires_in > time, nor has a requirement that the token is no longer honored by > protected resouces at that point in time (vs earlier or later). That is my understanding as well, I would however have expected that this parameter would be aligned with the 'exp' claim of the token. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Tue Dec 18 05:48:57 2018 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 F07B2126DBF for ; Tue, 18 Dec 2018 05:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 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 6MFUvJvs9oOT for ; Tue, 18 Dec 2018 05:48:51 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150054.outbound.protection.outlook.com [40.107.15.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A787E1200B3 for ; Tue, 18 Dec 2018 05:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DvF4PGn6zhfFKWns7NG/JivTLju+QgKN6d/6LUfVYbs=; b=XhizKsKr//0AE8K+/82GXDxHn5e4QfJnP7r7sFF+xz5QvMwLVlj20bh0FM829nH+5cmcMa1y7UOnONe+i81lyOEmovj46pI/s+kPctwfA0bTvpLTRfUA2/fcrLSfzcN/7uG9gbcPGgKEI0YaAZTshVWFrI2bvcG7HzJ1PwX5iEo= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1520.eurprd08.prod.outlook.com (10.167.210.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.17; Tue, 18 Dec 2018 13:48:46 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8%3]) with mapi id 15.20.1425.023; Tue, 18 Dec 2018 13:48:46 +0000 From: Hannes Tschofenig To: David Waite CC: oauth Thread-Topic: exp claim ... was RE: [OAUTH-WG] expires_in Thread-Index: AdSW2GGjAFttJtVJQmy5OvrC/4ISFw== Date: Tue, 18 Dec 2018 13:48:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.114.221] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1520; 6:wrZ6TiWi86d9olj0YJCFTBLZvL3UHQDfH/NtNOWbbQ6rRyOPJ81j9ziGEsID5tNuqTW6NLQACuxMGE+ZoMMg9QBCrzbiQtvbRtHBMUcNx9tNTPAlngOKW9uOjyfWJPfmTW13CkGx+6h/1YbwHZoMUNIb9kwMl5MMrk4GypgEw6W67tCsz0dErQGxiZvfsWCpQWEQOUEgd5/5io0H2QmNfqkmFlD7CAiaOS+3oZW/U7oOiOdRoSPPt0IGeb7rhVlpB7kzV34Nebiw+okjB7V7bUfHTGwqB/C4VQfcveDRAy30njmaTeWqabG8at+medaQF0/IRJHPfhY0q9a7b4w7JG8xlCPsQEtBhey+Jrv6kB+SdYHCqiAabVtK11QfR85IzeFAw0djsftkAY4eAqXROsF7Qk7RKcaEIbZH+OPZx52TqDqKfutFaiOWsCcEA3yeeARbz7mufb3KK+BdvF6oDQ==; 5:+C2gDMcOIfQUUcUHeu9TzxciTU65TuAlhc92dsUqBDx/kVtg1kctq4cnpwSxbLmzH82UnJb/4dTsFLvHUjpn/o9p4PDUHMn4iYSncv2KUqpgexNoUJBISioB3xB/HTkGKu9SM5VmNk2oOXdf5PL5eFNTuPiW45fgFW458Aw9K34=; 7:Hs57fKEuqC7P900D4zVhbNeJALPQK5tzyC/1feUD54E4ooWcRKm81PrWgq1KPcxiUljzj6hda6So6sPyF5SG/S1XWY/iECwcz7lgw+kLESC2pRcADG31MPjlg23BG9XySQpc0QbNR+H25PjxBazlLA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0ebff3c4-426c-4713-b6a4-08d664ef885e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1520; x-ms-traffictypediagnostic: VI1PR0801MB1520: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231475)(944501520)(52105112)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1520; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1520; x-forefront-prvs: 08902E536D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(136003)(376002)(366004)(396003)(40434004)(199004)(53754006)(189003)(13464003)(6506007)(5024004)(14444005)(256004)(68736007)(26005)(966005)(53546011)(5660300001)(102836004)(97736004)(8676002)(2906002)(81156014)(6116002)(3846002)(33656002)(486006)(6436002)(7696005)(14454004)(476003)(81166006)(71190400001)(71200400001)(66066001)(316002)(8936002)(6306002)(9686003)(55016002)(25786009)(4326008)(53936002)(86362001)(478600001)(106356001)(72206003)(105586002)(7736002)(305945005)(6916009)(99286004)(74316002)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1520; H:VI1PR0801MB2112.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-microsoft-antispam-message-info: AvI1/JcFDMzUbKZTps03lETte9igeYTpUwc+ZhTNEHx9gV8/9P6Uxosu3Nq7rYG2X8T+UEQeXqCehjKbQiZzH1bvDXfZbV7P30qG5/p6n5r8C4daeGAqE52qH0UzARmPLtxhZc+g9Tp8i74IqcrVNYKnWqC9O/TMn8NKncMdhcxC6EQzYcL7a+gSZmM+rCWprlDs55SxC8k81fdh4ZbaGqZE6EZPy7bUQIz5uDqXQU17rWkWgCSnDOV//D+TOyUmU2F5EhFYOWIhogvktPKuBvJ0dW9dSYlhaskgqYCGKOLm1nHN7zTfzrpHgZuhVMpz spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0ebff3c4-426c-4713-b6a4-08d664ef885e X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2018 13:48:46.6279 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1520 Archived-At: Subject: [OAUTH-WG] exp claim ... was RE: expires_in 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, 18 Dec 2018 13:48:55 -0000 SGkgRGF2aWQsDQoNCllvdSBqdXN0IGNhdWdodCBhbiBlcnJvci4gVGhhbmtzLg0KDQpUaGVyZSBp cyB0aGUgZXhwaXJlc19pbiBwYXJhbWV0ZXIgc2VudCBmcm9tIHRoZSBBUyB0byB0aGUgY2xpZW50 IGFuZCB0aGUgZXhwIGNsYWltIGluIHRoZSBhY2Nlc3MgdG9rZW4gY3JlYXRlZCBieSB0aGUgQVMg Zm9yIGNvbnN1bXB0aW9uIGJ5IHRoZSBSUy4NCg0KSSBtZWFudCB0byB3cml0ZSBhYm91dCB0aGUg ZXhwIGNsYWltIGJ1dCBJIGluc3RlYWQgbG9va2VkIHVwIHRoZSBleHBpcmVzX2luLiBUaGUgdmFs dWUgaW4gdGhlIGV4cGlyZXNfaW4gcGFyYW1ldGVyIGlzIGFsc28gaW4gbXkgb3BpbmlvbiBhZHZp c29yeS4gVGhlIGV4cCBwYXJhbWV0ZXIgc2hvdWxkbid0IGJlLg0KDQpJbnRlcmVzdGluZ2x5IFJG QyA2ODE5IG5vciBkcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xMCBvbmx5IHRhbGsg YWJvdXQgaGF2aW5nIGEgbWFuZGF0b3J5IGV4cCBjbGFpbSBpbiB0aGUgYWNjZXNzIHRva2VuLiBJ biBPcGVuSUQgQ29ubmVjdCBleHAgaXMgYSBtYW5kYXRvcnkgY2xhaW0uDQoNCkNpYW8NCkhhbm5l cw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGF2aWQgV2FpdGUgPGRhdmlk QGFsa2FsaW5lLXNvbHV0aW9ucy5jb20+DQpTZW50OiBEaWVuc3RhZywgMTguIERlemVtYmVyIDIw MTggMTI6NTkNClRvOiBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNv bT4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBl eHBpcmVzX2luDQoNCk15IHVuZGVyc3RhbmRpbmcgd2FzIHRoYXQgdGhpcyBwYXJhbWV0ZXIgd2Fz IGFkdmlzb3J5IHRvIHRoZSBjbGllbnQgLSBpdCBuZWl0aGVyIG1hbmRhdGVkIHRoZSBjbGllbnQg ZGlzY2FyZCB0aGUgdG9rZW4gYWZ0ZXIgdGhlIGV4cGlyZXNfaW4gdGltZSwgbm9yIGhhcyBhIHJl cXVpcmVtZW50IHRoYXQgdGhlIHRva2VuIGlzIG5vIGxvbmdlciBob25vcmVkIGJ5IHByb3RlY3Rl ZCByZXNvdWNlcyBhdCB0aGF0IHBvaW50IGluIHRpbWUgKHZzIGVhcmxpZXIgb3IgbGF0ZXIpLg0K DQpJcyB0aGVyZSBtZWFuaW5nIHRoYXQgb3RoZXJzIGFzc2lnbiB0byB0aGlzIHZhbHVlPyBUaGUg b25seSB1c2UgSeKAmXZlIGZvdW5kIGlzIHRvIHNjaGVkdWxlIHByb2FjdGl2ZSByZWZyZXNoZXMg dG8gaG9wZWZ1bGx5IHJlZHVjZSBsYXRlbmN5IGJ5IHJlZHVjaW5nIHRoZSBuZWVkIHRvIHJlZnJl c2ggaW4tbGluZSB3aXRoIHVzZXIgcmVxdWVzdHMuDQoNCi1EVw0KDQo+IE9uIERlYyAxOCwgMjAx OCwgYXQgMzo1NSBBTSwgSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5j b20+IHdyb3RlOg0KPg0KPiBIaSBhbGwsDQo+DQo+IEluIGEgcmVjZW50IGVtYWlsIGNvbnZlcnNh dGlvbiBvbiB0aGUgSUVURiBBQ0UgbWFpbGluZyBsaXN0IEx1ZHdpZyBTZWl0eiBzdWdnZXN0ZWQg dGhhdCB0aGUgZXhwaXJlc19pbiBjbGFpbSBpbiBhbiBhY2Nlc3MgdG9rZW4gc2hvdWxkIGFjdHVh bGx5IGJlIG1hbmRhdG9yeS4NCj4gSW50dWl0aXZlbHkgaXQgZmVlbHMgbGlrZSBhY2Nlc3MgdG9r ZW5zIHNob3VsZG4ndCBoYXZlIGFuIHVucmVzdHJpY3RlZCBsaWZldGltZS4gSSBhbSBjdXJpb3Vz IHdoZXRoZXIgcmVjb21tZW5kYXRpb25zIHdvdWxkIGJlIHVzZWZ1bCBoZXJlLg0KPg0KPiBSRkMg NjgxOSB0YWxrcyBhYm91dCB0aGUgZXhwaXJlc19pbiBjbGFpbSBhbmQgc2F5czoNCj4NCj4gMy4x LjIuICBMaW1pdGVkIEFjY2VzcyBUb2tlbiBMaWZldGltZQ0KPg0KPiAgIFRoZSBwcm90b2NvbCBw YXJhbWV0ZXIgImV4cGlyZXNfaW4iIGFsbG93cyBhbiBhdXRob3JpemF0aW9uIHNlcnZlcg0KPiAg IChiYXNlZCBvbiBpdHMgcG9saWNpZXMgb3Igb24gYmVoYWxmIG9mIHRoZSBlbmQgdXNlcikgdG8g bGltaXQgdGhlDQo+ICAgbGlmZXRpbWUgb2YgYW4gYWNjZXNzIHRva2VuIGFuZCB0byBwYXNzIHRo aXMgaW5mb3JtYXRpb24gdG8gdGhlDQo+ICAgY2xpZW50LiAgVGhpcyBtZWNoYW5pc20gY2FuIGJl IHVzZWQgdG8gaXNzdWUgc2hvcnQtbGl2ZWQgdG9rZW5zIHRvDQo+ICAgT0F1dGggY2xpZW50cyB0 aGF0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBkZWVtcyBsZXNzIHNlY3VyZSwgb3INCj4gICB3 aGVyZSBzZW5kaW5nIHRva2VucyBvdmVyIG5vbi1zZWN1cmUgY2hhbm5lbHMuDQo+DQo+IGRyYWZ0 LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTEwIG9ubHkgdGFsa3MgYWJvdXQgcmVmcmVzaCB0 b2tlbiBleHBpcnkuDQo+DQo+IEluIE9wZW5JRCBDb25uZWN0IHRoZSBleHBpcmVzX2luIGNsYWlt IGlzIGFsc28gb3B0aW9uYWwuDQo+DQo+IENpYW8NCj4gSGFubmVzDQo+DQo+IElNUE9SVEFOVCBO T1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJl IGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24s IHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9u IGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90 aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUg aW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Tue Dec 18 07:17:53 2018 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 E2035130EC1 for ; Tue, 18 Dec 2018 07:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=salesforce.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 ZAjBDcEmC-WO for ; Tue, 18 Dec 2018 07:17:32 -0800 (PST) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) (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 2CAAA12896A for ; Tue, 18 Dec 2018 07:17:32 -0800 (PST) Received: by mail-io1-f51.google.com with SMTP id x6so13008335ioa.9 for ; Tue, 18 Dec 2018 07:17:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc:content-transfer-encoding; bh=F1Oies4FVGbLYQ1V1qBhlX6zVrdGEoRUiSof/J8gqw8=; b=auZ4HOu+9eIDQU6b64NcTsiGpphRCrCf9nCgbK1bTpVU3Pn1XwLBZghf+AbXyTlrCa ni0VR4T8ZoBviGx7HvcacbKh1KsaXY3AmLQwLm7NlDXz/qYYeuI7v+4zUTfymhWdsHFA ineUjCeG/8e39zH/xGZKwGqITyZ1+0y75d7Ko= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-transfer-encoding; bh=F1Oies4FVGbLYQ1V1qBhlX6zVrdGEoRUiSof/J8gqw8=; b=bcMvCZbJwvzAjn5HsGUlDLYYSjpO2Tz75IIijWQ97jW+0WfTf1I+qpnOjJcsXWguX0 RIlg+tBZE3do7cMkwxFF9D2MnZwYAsyNdCi0YuraRsa2se4CYXcmT2zt3wZA/JG7SGR2 ArSoQOO5v+H9T/VwtPmFTr+VpuIIgiWs7O49VNPbbb0E5KAoI5Qfd/dIRUXqGhl+1v0i XDcfiCm/pnM19YNhllTElLnYy+EGqskVuXH0tOjcoGy9yBwbiLePNwpv/RzeqjGYaXn2 Onka7Y8jyfcD6ylIHoJgApcfJYYJ/aPj4sCycOGrwnxicDCB4qa/B+fVmsDivwa4SRMz 26zA== X-Gm-Message-State: AA+aEWY1Yl/5NfZBkZSUArzcTw1vv3xqJi+GdqRJAnPy3DAIHNl1BhE9 nrWlL5/OmJtgtTlpHGjV0cLrfOjKnS/tT8S6yYicFQ== X-Google-Smtp-Source: AFSGD/W37A83Y7yfHPwdwipshxtSOLW2f3PXWsS+y4RSVghYK8I4mQ+eSMGc4OWRAY4vf5Qu0X78sUby1pYcwKXgZI8= X-Received: by 2002:a6b:5a14:: with SMTP id o20mr14051082iob.206.1545145578991; Tue, 18 Dec 2018 07:06:18 -0800 (PST) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Tue, 18 Dec 2018 16:06:18 +0100 From: Chuck Mortimore Mime-Version: 1.0 (1.0) References: <66E27956-1627-46B5-AF60-B7F0CD631513@alkaline-solutions.com> <2ef34983-31b1-9b2a-a28f-ff4e14b2045d@ri.se> In-Reply-To: <2ef34983-31b1-9b2a-a28f-ff4e14b2045d@ri.se> Date: Tue, 18 Dec 2018 16:06:18 +0100 Message-ID: To: Ludwig Seitz Cc: oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] expires_in 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, 18 Dec 2018 15:17:49 -0000 We don=E2=80=99t issue expires_in for two reasons 1) we have variable length access tokens who=E2=80=99s lifetime can be extended through activity and we find clients misinterpret expires_in to be absolute (or have no practical means of finding out when it updates) 2) we find it actually makes things worse - with proactive knowledge of when a token expires, aggressive clients tend to keep it alive or proactively refresh the token. As a result the intent to limit the length of the access token actually causes it to be extended in practice. > On Dec 18, 2018, at 4:17 AM, Ludwig Seitz wrote: > >> On 18/12/2018 12:59, David Waite wrote: >> My understanding was that this parameter was advisory to the client - >> it neither mandated the client discard the token after the expires_in >> time, nor has a requirement that the token is no longer honored by >> protected resouces at that point in time (vs earlier or later). > > That is my understanding as well, I would however have expected that this= parameter would be aligned with the 'exp' claim of the token. > > /Ludwig > > > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Dec 18 08:06:48 2018 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 37158130EAF for ; Tue, 18 Dec 2018 08:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, 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 (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 m_DVebyE9P5o for ; Tue, 18 Dec 2018 08:06:44 -0800 (PST) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 EB96A130EB5 for ; Tue, 18 Dec 2018 08:06:43 -0800 (PST) Received: by mail-it1-x136.google.com with SMTP id z7so4946392iti.0 for ; Tue, 18 Dec 2018 08:06:43 -0800 (PST) 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; bh=wa9o18/9VLFGi4jK2Mj17h9qTqvyx2O7a5jRQYrBK3M=; b=Y5Ja4m3n4Nfkfkqc/F2BToCIpd+CkRGzZITVJGT9DW7P49xNOBQ0lqT0462jvB1A8y Kq9DOKnIYHdSMJ6lNXYAEHUDtR2vpFdskKelK3noNk/DGcFCOw9cOVd9Da8uoe0LIaSa ODuMtKHd1qyCUzZfvLGeYPkG2NM/lNLCwq6dPDAII4dQgoFsOtsx12CxDX7xlEQcOAK3 FLcPBYslrjXIt+gwZ6FOnMvkZclSYhV1+I3zEfC/ht1N4pAfBsxQUIx8lKbjLpaXA8WC mPFNjqE4gH9CV+cu+WfcA/tx/DeDy/TF+x5+JImMGA7xpG7umTtSVXInZ/x0ZTRNHg/d m37w== 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=wa9o18/9VLFGi4jK2Mj17h9qTqvyx2O7a5jRQYrBK3M=; b=KU36M4PwcatsImZCkTm0h8Y9LUzgwZR8hOUGiwWdkvKWRq0ZUtj3ylku+e2eph3wj5 aiAlPo4GQ/tuWjHiA5ZQ4G5H5JZ7Szh7QiEZfpjugIciu5D2k/1Z6pRBEWysTz/Ck09X mXmF0aKWNaHb+gE3vMigpq5f5K6OCslYAVvSm4iZRzTIIDhdEftJGDXYc7OmzyUuIkJq rCdKdJvW8rLino2Lz2V/UwuenesVKFbeQv2SKYSeXxnhSQUTtA/3YI+Lj7tREc4xGFJV ong4T3iLFvr8qhpvUfh8ZvwYIClnduk2OXronv9aAiU9zRNtrmYzUbrIj3mbL+OvDZjF x66A== X-Gm-Message-State: AA+aEWZpcSpKp6fLA+2toeMd39xW0x+3R6/xu3ZYPhxnQJFPt8XRznmJ qERbN9+pLBf35sU1MMlUU9VQEX8o4a0= X-Google-Smtp-Source: AFSGD/WXQyI2D4Gt8hhx5IhtZH+w9RM5I3g6UHqvbrL4HSjwcTyiLKMuzJksbYcAGWbbZcEXyJwqrQ== X-Received: by 2002:a24:e1ce:: with SMTP id n197mr3370735ith.123.1545149202887; Tue, 18 Dec 2018 08:06:42 -0800 (PST) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com. [209.85.166.54]) by smtp.gmail.com with ESMTPSA id t2sm7685935iob.7.2018.12.18.08.06.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 08:06:41 -0800 (PST) Received: by mail-io1-f54.google.com with SMTP id x6so13143581ioa.9 for ; Tue, 18 Dec 2018 08:06:41 -0800 (PST) X-Received: by 2002:a6b:b502:: with SMTP id e2mr13915121iof.43.1545149200934; Tue, 18 Dec 2018 08:06:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Tue, 18 Dec 2018 08:06:28 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Hannes Tschofenig Cc: David Waite , oauth Content-Type: multipart/alternative; boundary="0000000000003f310a057d4e1531" Archived-At: Subject: Re: [OAUTH-WG] exp claim ... was RE: expires_in 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, 18 Dec 2018 16:06:47 -0000 --0000000000003f310a057d4e1531 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The "exp" claim is an implementation detail of one type of access token, but obviously doesn't have any meaning to someone using non-JWT tokens. Since not everyone is using JWT access tokens, it seems strange to have a mention of a JWT-specific detail. That said, it sounds like the proposal is to recommend access tokens always have an expiration date? In that case, is it also important that the expiration date be communicated to the client? ---- Aaron Parecki aaronparecki.com @aaronpk On Tue, Dec 18, 2018 at 5:49 AM Hannes Tschofenig wrote: > Hi David, > > You just caught an error. Thanks. > > There is the expires_in parameter sent from the AS to the client and the > exp claim in the access token created by the AS for consumption by the RS= . > > I meant to write about the exp claim but I instead looked up the > expires_in. The value in the expires_in parameter is also in my opinion > advisory. The exp parameter shouldn't be. > > Interestingly RFC 6819 nor draft-ietf-oauth-security-topics-10 only talk > about having a mandatory exp claim in the access token. In OpenID Connect > exp is a mandatory claim. > > Ciao > Hannes > > -----Original Message----- > From: David Waite > Sent: Dienstag, 18. Dezember 2018 12:59 > To: Hannes Tschofenig > Cc: oauth > Subject: Re: [OAUTH-WG] expires_in > > My understanding was that this parameter was advisory to the client - it > neither mandated the client discard the token after the expires_in time, > nor has a requirement that the token is no longer honored by protected > resouces at that point in time (vs earlier or later). > > Is there meaning that others assign to this value? The only use I=E2=80= =99ve found > is to schedule proactive refreshes to hopefully reduce latency by reducin= g > the need to refresh in-line with user requests. > > -DW > > > On Dec 18, 2018, at 3:55 AM, Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > > > Hi all, > > > > In a recent email conversation on the IETF ACE mailing list Ludwig Seit= z > suggested that the expires_in claim in an access token should actually be > mandatory. > > Intuitively it feels like access tokens shouldn't have an unrestricted > lifetime. I am curious whether recommendations would be useful here. > > > > RFC 6819 talks about the expires_in claim and says: > > > > 3.1.2. Limited Access Token Lifetime > > > > The protocol parameter "expires_in" allows an authorization server > > (based on its policies or on behalf of the end user) to limit the > > lifetime of an access token and to pass this information to the > > client. This mechanism can be used to issue short-lived tokens to > > OAuth clients that the authorization server deems less secure, or > > where sending tokens over non-secure channels. > > > > draft-ietf-oauth-security-topics-10 only talks about refresh token > expiry. > > > > In OpenID Connect the expires_in claim is also optional. > > > > Ciao > > Hannes > > > > 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 > --0000000000003f310a057d4e1531 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The "exp" claim is an implementation detail= of one type of access token, but obviously doesn't have any meaning to= someone using non-JWT tokens. Since not everyone is using JWT access token= s, it seems strange to have a mention of a JWT-specific detail.

That said, it sounds like the proposal is to recommend access = tokens always have an expiration date? In that case, is it also important t= hat the expiration date be communicated to the client?

----
Aaron Parecki



On Tue, Dec 18, 2018 at 5:49 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
Hi David,

You just caught an error. Thanks.

There is the expires_in parameter sent from the AS to the client and the ex= p claim in the access token created by the AS for consumption by the RS.
I meant to write about the exp claim but I instead looked up the expires_in= . The value in the expires_in parameter is also in my opinion advisory. The= exp parameter shouldn't be.

Interestingly RFC 6819 nor draft-ietf-oauth-security-topics-10 only talk ab= out having a mandatory exp claim in the access token. In OpenID Connect exp= is a mandatory claim.

Ciao
Hannes

-----Original Message-----
From: David Waite <david@alkaline-solutions.com>
Sent: Dienstag, 18. Dezember 2018 12:59
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: oauth <oauth@iet= f.org>
Subject: Re: [OAUTH-WG] expires_in

My understanding was that this parameter was advisory to the client - it ne= ither mandated the client discard the token after the expires_in time, nor = has a requirement that the token is no longer honored by protected resouces= at that point in time (vs earlier or later).

Is there meaning that others assign to this value? The only use I=E2=80=99v= e found is to schedule proactive refreshes to hopefully reduce latency by r= educing the need to refresh in-line with user requests.

-DW

> On Dec 18, 2018, at 3:55 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com&g= t; wrote:
>
> Hi all,
>
> In a recent email conversation on the IETF ACE mailing list Ludwig Sei= tz suggested that the expires_in claim in an access token should actually b= e mandatory.
> Intuitively it feels like access tokens shouldn't have an unrestri= cted lifetime. I am curious whether recommendations would be useful here. >
> RFC 6819 talks about the expires_in claim and says:
>
> 3.1.2.=C2=A0 Limited Access Token Lifetime
>
>=C2=A0 =C2=A0The protocol parameter "expires_in" allows an au= thorization server
>=C2=A0 =C2=A0(based on its policies or on behalf of the end user) to li= mit the
>=C2=A0 =C2=A0lifetime of an access token and to pass this information t= o the
>=C2=A0 =C2=A0client.=C2=A0 This mechanism can be used to issue short-li= ved tokens to
>=C2=A0 =C2=A0OAuth clients that the authorization server deems less sec= ure, or
>=C2=A0 =C2=A0where sending tokens over non-secure channels.
>
> draft-ietf-oauth-security-topics-10 only talks about refresh token exp= iry.
>
> In OpenID Connect the expires_in claim is also optional.
>
> Ciao
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments are c= onfidential and may also be privileged. If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the informatio= n 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 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
--0000000000003f310a057d4e1531-- From nobody Tue Dec 18 09:27:25 2018 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 1162C131166 for ; Tue, 18 Dec 2018 09:27:24 -0800 (PST) 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_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 7BtaLLPblKby for ; Tue, 18 Dec 2018 09:27:21 -0800 (PST) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 5D1FF126DBF for ; Tue, 18 Dec 2018 09:27:21 -0800 (PST) Received: by mail-it1-x12b.google.com with SMTP id b5so5353231iti.2 for ; Tue, 18 Dec 2018 09:27:21 -0800 (PST) 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=vYlhV5zRCiGsq7i3a4KL5zFdr9OpC6kW9cs7qFfnxPs=; b=cUrRgH7UnPBJehvJnHiNgRqJyRtL2YeuT/1yG4ajqfrRFlgvShKW5vwzgF39D/+KHk uvpds94Ze3npntvhL112UMaR4ft7Oam5GRhi2Sw7/+EMMqu4u0dz+fmwV/0AUDBOIV5r sTgt1qEPmEJBlfi5rTIRhEX3/OAC7Rh0itv7M= 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=vYlhV5zRCiGsq7i3a4KL5zFdr9OpC6kW9cs7qFfnxPs=; b=idjPhL5KXdZVKX4vR3qmqbFdZWILLLNjr1+gwsah8Th5NI8cCRXD6tYgnrlOxsnsLy 0ULCzZpius+utqBSdEc2M/s7XwJ55wMmoBkQNFV4e15RH7H6wuiNBYziJ/ri6KSsfYvQ btxXtOQWt+vn+L6BqyCQs8qS3/c2JlBSJpiumS9xtQ6wLRA1XdLuOBjxzaoBaf8VAiIe FMjQtptr1f8KbMEU7ZlP81YVifqg3zQJjHPXOAhqgmJR/dqiWT4p994P2hXwP3Ug3LGX +gShCV4a0nUudEAdZ+IDsCz3W9re7hMo4g8Ca/+aLTRuHKqzvbKR32dVZlUEGsrx3CXN Pm2g== X-Gm-Message-State: AA+aEWa+ChK73tOfjEA4Eqb6aUqdp/odTbwyVxsTKXBL7ebbuHpYEbca 3L7vESSHJxIeeDailqQOr1uDWBinVRQQ8GgFguFu9olkVDmwhlaQj910DH7xJar1NgjNV8v1dIj dQEQCEeyrKzxxFw== X-Google-Smtp-Source: AFSGD/WAPFA07T333yeBOSDBH2QClv6/gYLIXvNsLsJV4MjCdKlPb0aFWyvArDEo1c/FubBX2PQ3jrgLeRvs6IAxZ9M= X-Received: by 2002:a05:660c:452:: with SMTP id d18mr3627592itl.124.1545154040457; Tue, 18 Dec 2018 09:27:20 -0800 (PST) MIME-Version: 1.0 References: <74c76953-72fb-ae77-d27b-faf97d7905ef@ve7jtb.com> In-Reply-To: From: Brian Campbell Date: Tue, 18 Dec 2018 10:26:53 -0700 Message-ID: To: Filip Skokan Cc: John Bradley , oauth Content-Type: multipart/alternative; boundary="000000000000b48ae9057d4f35b4" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint 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, 18 Dec 2018 17:27:24 -0000 --000000000000b48ae9057d4f35b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I claim no particular expertise here and it's admittedly been a long time since I actually tested the behavior myself. But in my prior experience there were browsers that would prompt the user even when there were no certificates/keys configured for or available to the browser. On Mon, Dec 17, 2018 at 3:37 PM Filip Skokan wrote: > Correct. If there are certs installed on the device the browsers are > likely going to prompt. > > Having at least one CA configured together with optional_no_ca (even if > its a CA noone ever has certs for) additionally omits the prompt for some > client configurations. > > Odesl=C3=A1no z iPhonu > > 17. 12. 2018 v 23:10, John Bradley : > > > I think that works for those browsers if no certificates are installed > for the browser. We should test, but I think if any certificates are > available to the browser then it will prompt. > > > > John B. > > > > > >> On 12/17/2018 1:52 PM, Neil Madden wrote: > >> I am currently running a Tomcat instance that I have configured to > support, but not demand, client certificates using the > certificateVerification=3D=E2=80=9CoptionalNoCA=E2=80=9D setting. With th= is config I am able > to authenticate a confidential client using mTLS, and yet connecting to t= he > same server over HTTPS in either Safari or Chrome on Mac does not prompt = me > for any certificate. I don=E2=80=99t have any client certificates configu= red in my > browser, so does this only happen if you do? > >> > >> Depending on the deployment scenario, it may also be possible to > terminate TLS at a proxy and use a separate proxy for (intranet) mTLS > clients vs public clients, but that may not suit every deployment. > >> > >> =E2=80=94 Neil > >> > >>> On 17 Dec 2018, at 20:26, Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >>> > >>> While there's been some disagreement about the specific wording etc., > there does seem to be general consensus coming out of this WG to, in one > form or another, recommend against the use of the implicit grant in favor > of authorization code. In order to follow that recommendation, in-browser > JavaScript clients will need to use XHR/fetch (and likely CORS) to make > requests directly to the token endpoint. > >>> > >>> Meanwhile there is the MTLS document utilizes TLS client certificates > at the token endpoint for client authentication and/or certificate bound > access tokens. The security BCP draft even recommends sender/key > constrained access tokens and MTLS is close to the only viable way to do > that at this time. > >>> > >>> Unfortunately, however, these two things don't play very nice > together. When a browser makes a TLS connection where a client cert is > requested by the server in the handshake, even when client certificates a= re > optional and even when it's fetch/XHR, most/many/all browsers will throw = up > some kind of certificate selection interface to the user. Which is > typically a very very bad user experience. From a practical standpoint, > this means that a single deployment cannot really support the MTLS draft > and have in-browser JavaScript clients using authorization code at the sa= me > time. > >>> > >>> In order to address the conflict here, I'd propose that the MTLS draf= t > introduce a new optional AS metadata parameter that is an MTLS enabled > token endpoint alias. Clients that are doing MTLS client authentication > and/or certificate bound access tokens would/should/must use the > alternative token endpoint when present in the AS's metadata. While all > other clients continue to use the standard token endpoint as they always > have. This would allow for an AS to deploy an alternative token endpoint > alias on a distinct host or port where it will request client certs in th= e > TLS handshake for OAuth clients that use it while keeping the regular tok= en > endpoint as it normally is for other clients, especially in-browser > JavaScript clients. > >>> > >>> Thoughts, objections, agreements, etc., on this proposal? > >>> > >>> PS Bikeshedding on a name for the metadata parameter is also welcome. > Some ideas to start: > >>> token_endpoint_mtls_alias > >>> token_endpoint_mtls > >>> mtls_token_endpoint_alias > >>> mtls_token_endpoint > >>> alt_token_endpoint_mtls > >>> mtls_token_endpoint_alt > >>> > a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_sh= ould_use > >>> equally_poor_idea_here > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> 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 > >> _______________________________________________ > >> 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 > --=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._ --000000000000b48ae9057d4f35b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I claim no particular expertise here and it's adm= ittedly been a long time since I actually tested the behavior myself.=C2=A0= But in my prior experience there were browsers that would prompt the user = even when there were no certificates/keys configured for or available to th= e browser.



On Mon, Dec 17, 2018 at 3:37 PM Filip Skokan = <panva.ip@gmail.= com> wrote:
Correct. If there are certs installed on the device the browsers are lik= ely going to prompt.

Having at least one CA configured together with optional_no_ca (even if its= a CA noone ever has certs for) additionally omits the prompt for some clie= nt configurations.

Odesl=C3=A1no z iPhonu

17. 12. 2018 v 23:10, John Bradley <ve7jtb@ve7jtb.com>:

> I think that works for those browsers if no certificates are installed= for the browser.=C2=A0 =C2=A0We should test, but I think if any certificat= es are available to the browser then it will prompt.
>
> John B.
>
>
>> On 12/17/2018 1:52 PM, Neil Madden wrote:
>> I am currently running a Tomcat instance that I have configured to= support, but not demand, client certificates using the certificateVerifica= tion=3D=E2=80=9CoptionalNoCA=E2=80=9D setting. With this config I am able t= o authenticate a confidential client using mTLS, and yet connecting to the = same server over HTTPS in either Safari or Chrome on Mac does not prompt me= for any certificate. I don=E2=80=99t have any client certificates configur= ed in my browser, so does this only happen if you do?
>>
>> Depending on the deployment scenario, it may also be possible to t= erminate TLS at a proxy and use a separate proxy for (intranet) mTLS client= s vs public clients, but that may not suit every deployment.
>>
>> =E2=80=94 Neil
>>
>>> On 17 Dec 2018, at 20:26, Brian Campbell <bcampbell=3D40pingide= ntity.com@dmarc.ietf.org> wrote:
>>>
>>> While there's been some disagreement about the specific wo= rding etc., there does seem to be general consensus coming out of this WG t= o, in one form or another, recommend against the use of the implicit grant = in favor of authorization code. In order to follow that recommendation, in-= browser JavaScript clients will need to use XHR/fetch (and likely CORS) to = make requests directly to the token endpoint.
>>>
>>> Meanwhile there is the MTLS document utilizes TLS client certi= ficates at the token endpoint for client authentication and/or certificate = bound access tokens. The security BCP draft even recommends sender/key cons= trained access tokens and MTLS is close to the only viable way to do that a= t this time.
>>>
>>> Unfortunately, however, these two things don't play very n= ice together. When a browser makes a TLS connection where a client cert is = requested by the server in the handshake, even when client certificates are= optional and even when it's fetch/XHR, most/many/all browsers will thr= ow up some kind of certificate selection interface to the user.=C2=A0 Which= is typically a very very bad user experience. From a practical standpoint,= this means that a single deployment cannot really support the MTLS draft a= nd have in-browser JavaScript clients using authorization code at the same = time.
>>>
>>> In order to address the conflict here, I'd propose that th= e MTLS draft introduce a new optional AS metadata parameter that is an MTLS= enabled token endpoint alias. Clients that are doing MTLS client authentic= ation and/or certificate bound access tokens would/should/must use the alte= rnative token endpoint when present in the AS's metadata. While all oth= er clients continue to use the standard token endpoint as they always have.= This would allow for an AS to deploy an alternative token endpoint alias o= n a distinct host or port where it will request client certs in the TLS han= dshake for OAuth clients that use it while keeping the regular token endpoi= nt as it normally is for other clients, especially in-browser JavaScript cl= ients.
>>>
>>> Thoughts, objections, agreements, etc., on this proposal?
>>>
>>> PS Bikeshedding on a name for the metadata parameter is also w= elcome. Some ideas to start:
>>> token_endpoint_mtls_alias
>>> token_endpoint_mtls
>>> mtls_token_endpoint_alias
>>> mtls_token_endpoint
>>> alt_token_endpoint_mtls
>>> mtls_token_endpoint_alt
>>> a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_R= FC_[TBD]_should_use
>>> equally_poor_idea_here
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> CONFIDENTIALITY NOTICE: This email may contain confidential an= d privileged material for the sole use of the intended recipient(s). Any re= view, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 If you have received this communication in error, please notify the sen= der immediately by e-mail and delete the message and any file attachments f= rom your computer. Thank you.______________________________________________= _
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
> _______________________________________________
> 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

<= 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. --000000000000b48ae9057d4f35b4-- From nobody Tue Dec 18 10:14:29 2018 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 75814131195 for ; Tue, 18 Dec 2018 10:14:28 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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 m_t692excwDm for ; Tue, 18 Dec 2018 10:14:24 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) (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 3F94F131192 for ; Tue, 18 Dec 2018 10:14:24 -0800 (PST) Received: from [80.187.81.111] (helo=[172.20.10.2]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gZJsq-0001Tn-A6; Tue, 18 Dec 2018 19:14:20 +0100 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1373A794-6959-4138-ACD9-8E35CDD5D3B2"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Tue, 18 Dec 2018 19:14:18 +0100 In-Reply-To: Cc: oauth To: Hannes Tschofenig References: X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 for Browser-Based Apps 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, 18 Dec 2018 18:14:28 -0000 --Apple-Mail=_1373A794-6959-4138-ACD9-8E35CDD5D3B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Hannes,=20 while I think the current text needs some substantial work, I support = the adoption of this draft as a working group document. I also think we = need to carefully define the boundaries between the Security BCP and the = SPA BCP in order to prevent unnecessary duplications and = inconsistencies. Here are my review comments: "OAuth 2.0 authorization requests from apps running entirely in a browser are unable to use a Client Secret during the process, since they have no way to keep a secret confidential.=E2=80=9C Although I think that=E2=80=99s an important aspect I=E2=80=99m = wondering why the draft starts with it? I don=E2=80=99t think this is = the most important message. If the intend is to align with = https://tools.ietf.org/html/rfc8252, I would propose something like =E2=80=9EOAuth 2.0 authorization requests from browser based apps should = only be made using the code flow. =E2=80=A6" Section 3 "Browser-based application": An application that runs entirely in a web browser, usually written in JavaScript, where the source code is downloaded from a domain prior to execution. Also sometimes referred to as a "single-page application", or "SPA=E2=80=9C. I think this definition is too narrow, which also limits applicability = of this draft. I would argue a browser based application runs portions = of its logic in the browser but not necessarily the entire app. Most = browser based apps have a backend in the same way as mobile apps have a = backend. I think for the purpose of this draft the fact that the UI is = controlled from within the browser, uses browser APIs and underlies = browser security mechanisms & restrictions is much more important. = Moreover, the source code not even needs to be downloaded for every = execution due to browser caching.=20 My proposal: "Browser-based application": An application that is dynamically=20 downloaded and executed in a web browser, usually written in=20 JavaScript. Also sometimes referred to as a "single-page = application", or "SPA=E2=80=9C. Section 4 "Require the OAuth 2.0 state parameter" -> "Use the the state parameter = to carry one-time use CSRF tokens" "...require the hostname of the redirect URI match the hostname of the URL the app was served from=E2=80=9C=20 Are we sure there are no legit reasons to receive the redirect at = another host? Is the AS supposed to determine the app's origin from the = referrer header? "Previously it was recommended that browser-based applications use the OAuth 2.0 Implicit flow. =E2=80=A6=E2=80=9C I suggest to mention broad adoption of CORS after publication of RFC = 6749 as reason why the shift towards code is possible now. Section 5 =E2=80=9ETo conform to this best practice, first-party applications = using OAuth or OpenID Connect MUST use an OAuth Authorization Code flow as described later in this document or use the OAuth Password grant." It does not feel well for me to read =E2=80=9EMUST" and "Password = grant=E2=80=9C in the same sentence. I'm in favor to just recommend 1st = party apps to use code for reasons x, y, z and not mention password. I also think the arguments are more dominante when formatted as bullet = list. Section 6 "In some cases, it may make sense to avoid the use of a strictly browser-based OAuth application entirely, instead using an architecture that can provide better security.=E2=80=9C Reads like OAuth implies degraded app security? 6.1. =E2=80=9EFor simple system architectures, such as when the JavaScript application is served from the same domain as the API (resource server) being accessed, it is likely a better decision to avoid using OAuth entirely, and just use session authentication to communicate with the API.=E2=80=9C What do you mean by same domain? same second level domain? same host? = I'm not sure what this text want to convey. Section 6.2. 2nd paragraph =E2=80=9E=E2=80=A6.The backend component essentially = becomes a new authorization server=E2=80=9C I get the message, but the term "authorization server" misled me when I = read the text for the first time. I was under the impression, your are = proposing OAuth as communication protocol between an app's front and = backend. This is possible but just one option. I suggest to remove the = term. It does not really help. 3rd paragraph =E2=80=9EIn this scenario, the backend component may be a = confidential client which is issued its own client secret. =E2=80=9E Confidential clients can use various authentication methods, =E2=80=9Esecr= et" misleads reader towards traditional client secrets. private_key_jwt = and mTLS are possible (and better options).=20 =E2=80=9EDespite this, there are still some ways in which this application is effectively a public client, as the end result is the application's code is still running in the browser and visible to the user.=E2=80=9C Why does this make the SPA a public client? I see the risk of a browser = based app (and every kind of attacker) to access protected APIs through = the backend. That's the reason why I think the backend should never = directly expose (=3D=3D just proxy) the underlying RS APIs. The = interface between front and backend must be narrowed down to the = specific use case AND the current state of the app. For example, if the = app is in "check out" state it makes sense to initiate a payment but in = no other state. =20 General remark: I would suggest to restructure section 6 to describe the = potential architectures this BCP has in mind. =46rom my perspective = these are: - "pure" SPA - SPA w/ backend - SPA w/o OAuth (as fallback) Section 7.1 =E2=80=9EPublic browser-based apps MUST implement the Proof Key for Code = extension to OAuth, and authorization servers MUST support PKCE for such clients." Any client MUST use PKCE (see Security BCP) - PKCE is used beyond = interception prevention to detect injection. Please refer to section 2.1 = of the security BCP it has all the details. Section 7.2 =E2=80=9EAuthorization servers SHOULD require an exact match of a = registered redirect URI." Please make it a MUST as stated in the Security BCP, Section 2.1 =E2=80=9E If an authorization server wishes to provide some flexibility = in redirect URI usage to clients, it MAY require that only the hostname component of the redirect URI match the hostname of the URL the application is served from.=E2=80=9C Why do you soften the Security BCP requirements? That's the road to open = redirection! Section 8 This section lacks a motivation for RT usage. In my opinion, there are = two reasons:=20 (1) use RTs instead of refresh via authorization code flow (to cope with = ITP2).=20 (2) be able to issue short lived and privilege restricted access tokens = in order to limit the impact of access token leakage at resource = servers. Both are good reasons that deserve dedicated discussions. I therefore = suggest to split & change Section 8 into two sections, =E2=80=9EAccess = Token Refresh" and =E2=80=9EAccess Token Replay Mitigation". The section on access token mitigation should discuss potential options, = including=20 - Token Binding=20 - mTLS - RT rotation =E2=80=A6 Section 9.1 This BCP describes different SPA design where such apps can be either = public or confidential. So I would not preclude confidential clients. Section 9.4 You might want to refer to the Security BCP as it has more details on = this topic.=20 I would also suggest to add use of CORS for CSRF protection in the = browser (see = https://www.ietf.org/mail-archive/web/oauth/current/msg18591.html) since = it is SPA specific.=20 Section 9.6.=20 I would argue enabling CORS is not a security consideration but a = functional requirement towards the AS. 2nd paragraph CORS and authorization of GET&POST requests plays a vital role in CSRF = prevention if the access tokens are conveyed in a cookie as well as for = any automatic way to add authorization headers to outbound requests (see = above). So I think it must be managed properly. Section 9.7 Why do you bind CSP to RTs or long living access tokens. Isn=E2=80=99t = this anyway a good idea to prevent XSS? Section 9.8.6 injection is neglected - I think you could just refer to the Security = BCP for the discussion of the risks associated with implicit. If any = threat is missing there, we can add it there.=20 =E2=80=9EIn OpenID Connect, =E2=80=A6=E2=80=9C=20 Not clear to me what this text shall convey. Is it a statement in favor = of issuing id tokens in the back channel in OIDC? Section 9.8.7 I would put this text in a motivation section along with the explanation = why CORS adoption allows code adoption for SPAs in the introduction of = the BCP. kind regards, Torsten.=20 > Am 17.12.2018 um 22:01 schrieb Hannes Tschofenig = : >=20 > Hi all, >=20 > We would like to get a confirmation on the mailing list for the = adoption of = https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-02 as = a starting point for a BCP document about *OAuth 2.0 for Browser-Based = Apps*. >=20 > Please, let us know if you support or object to the adoption of this = document by Jan. 7th 2019. >=20 > 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 = the information in any medium. Thank you. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_1373A794-6959-4138-ACD9-8E35CDD5D3B2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODEyMTgxODE0MTlaMC8GCSqGSIb3DQEJBDEiBCDd fKgJB9S+0Gf1sEKEgYMya7W9fgICfvrQIOGN0FAh8TCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAqEXn2mHfviriUhLR+NeGSRfq 6RolSt6L5APGsczii43ZfiSZgdq0H2NQg5UBKhk2Ca7onnDAx/D/F5NZ0LF83zy9tTzcj5jfv6qV pq7q/Bt3tKv4irUhU6FnRs5qboB4NQSuIIKvQTEOGchtFFY/fgjrRdydoW4JVWJttedFAtylBHV/ 6Sw72nEJA5iWdxl4AtmtNq5++jzwohQU9I86SBad9T8Y3+9zRrWncYj9q/oVh1PmjlDHPLuIxHTV mDXZ6erSx/eaoLxesc73QWB3PopHCKqKR07PTlgKMWZ8V1xAtL03g31X4Dai7kHiSQlrlJ7IvWkG Oqv0FopX2/b7xgAAAAAAAA== --Apple-Mail=_1373A794-6959-4138-ACD9-8E35CDD5D3B2-- From nobody Tue Dec 18 14:15:33 2018 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 BC1F1129BBF for ; Tue, 18 Dec 2018 14:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.365 X-Spam-Level: X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 t3dXkd1UoaAY for ; Tue, 18 Dec 2018 14:15:28 -0800 (PST) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 DE2DA12D84D for ; Tue, 18 Dec 2018 14:15:27 -0800 (PST) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wBIME15o024575; Tue, 18 Dec 2018 22:15:24 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-2018-07-02; bh=w4Cm8WhYk7Vr98bHKplG/7YFnG5HI0PljBnZfAGz/rU=; b=TIkQGDDy6StWzra1zMjn+8lbyatWeZp6phm6Tm3VFXOOjKK+gNxEwRaq3FMdcyJ2Fe99 VDeVwyLa09tdn3eII7U9/KUFLW8G6SefwIfcF+jKWDODCNFaXWAGhNJL1mKoL0T/aLnQ GEcqwm5rH0is32JWkZSLKUAyHx9dBKdfUm82P1jqAIfOSumOspbWRFioR6G+PGmXpC3S pTbkHZP7RgIqGaiI0O+3KFBNyD1uTO55RWibistUZVrlgA6w/W7OmBmJ3DqCLfs7XbJg e6vLiiEzsTVKuPyImKyQt+ZHHzUXFxWNRCPwvVqxJZDmbgHM+glcMFOc4ztjwuJxUOkp cQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2pcs1tp57b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 18 Dec 2018 22:15:23 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wBIMFN9X007278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 18 Dec 2018 22:15:23 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wBIMFMbS006996; Tue, 18 Dec 2018 22:15:22 GMT Received: from [192.168.1.27] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 Dec 2018 14:15:22 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Tue, 18 Dec 2018 14:15:21 -0800 Cc: Hannes Tschofenig , oauth Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Torsten Lodderstedt X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9111 signatures=668680 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-1810050000 definitions=main-1812180182 Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 for Browser-Based Apps 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, 18 Dec 2018 22:15:31 -0000 +1 Phil > On Dec 18, 2018, at 10:14 AM, Torsten Lodderstedt wrote: >=20 > Hi Hannes,=20 >=20 > while I think the current text needs some substantial work, I support the a= doption of this draft as a working group document. I also think we need to c= arefully define the boundaries between the Security BCP and the SPA BCP in o= rder to prevent unnecessary duplications and inconsistencies. >=20 > Here are my review comments: >=20 > "OAuth 2.0 authorization requests from apps running entirely in a > browser are unable to use a Client Secret during the process, since > they have no way to keep a secret confidential.=E2=80=9C >=20 > Although I think that=E2=80=99s an important aspect I=E2=80=99m wondering w= hy the draft starts with it? I don=E2=80=99t think this is the most importan= t message. If the intend is to align with https://tools.ietf.org/html/rfc825= 2, I would propose something like >=20 > =E2=80=9EOAuth 2.0 authorization requests from browser based apps should o= nly be made > using the code flow. =E2=80=A6" >=20 > Section 3 >=20 > "Browser-based application": An application that runs entirely in a > web browser, usually written in JavaScript, where the source code > is downloaded from a domain prior to execution. Also sometimes > referred to as a "single-page application", or "SPA=E2=80=9C. >=20 > I think this definition is too narrow, which also limits applicability of t= his draft. I would argue a browser based application runs portions of its lo= gic in the browser but not necessarily the entire app. Most browser based ap= ps have a backend in the same way as mobile apps have a backend. I think for= the purpose of this draft the fact that the UI is controlled from within th= e browser, uses browser APIs and underlies browser security mechanisms & res= trictions is much more important. Moreover, the source code not even needs t= o be downloaded for every execution due to browser caching.=20 >=20 > My proposal: >=20 > "Browser-based application": An application that is dynamically=20 > downloaded and executed in a web browser, usually written in=20 > JavaScript. Also sometimes referred to as a "single-page application",= or "SPA=E2=80=9C. >=20 > Section 4 >=20 > "Require the OAuth 2.0 state parameter" -> "Use the the state parameter to= carry one-time use CSRF tokens" >=20 > "...require the > hostname of the redirect URI match the hostname of the URL the app > was served from=E2=80=9C=20 >=20 > Are we sure there are no legit reasons to receive the redirect at another h= ost? Is the AS supposed to determine the app's origin from the referrer head= er? >=20 > "Previously it was recommended that browser-based applications use the > OAuth 2.0 Implicit flow. =E2=80=A6=E2=80=9C >=20 > I suggest to mention broad adoption of CORS after publication of RFC 6749 a= s reason why the shift towards code is possible now. >=20 > Section 5 >=20 > =E2=80=9ETo conform to this best practice, first-party applications using > OAuth or OpenID Connect MUST use an OAuth Authorization Code flow as > described later in this document or use the OAuth Password grant." >=20 > It does not feel well for me to read =E2=80=9EMUST" and "Password grant=E2= =80=9C in the same sentence. I'm in favor to just recommend 1st party apps t= o use code for reasons x, y, z and not mention password. >=20 > I also think the arguments are more dominante when formatted as bullet lis= t. >=20 > Section 6 >=20 > "In some cases, it may make sense to avoid the use of a strictly > browser-based OAuth application entirely, instead using an > architecture that can provide better security.=E2=80=9C >=20 > Reads like OAuth implies degraded app security? >=20 > 6.1. >=20 > =E2=80=9EFor simple system architectures, such as when the JavaScript > application is served from the same domain as the API (resource > server) being accessed, it is likely a better decision to avoid using > OAuth entirely, and just use session authentication to communicate > with the API.=E2=80=9C >=20 > What do you mean by same domain? same second level domain? same host? I'm n= ot sure what this text want to convey. >=20 > Section 6.2. >=20 > 2nd paragraph =E2=80=9E=E2=80=A6.The backend component essentially becomes= a new authorization server=E2=80=9C >=20 > I get the message, but the term "authorization server" misled me when I re= ad the text for the first time. I was under the impression, your are proposi= ng OAuth as communication protocol between an app's front and backend. This i= s possible but just one option. I suggest to remove the term. It does not re= ally help. >=20 > 3rd paragraph =E2=80=9EIn this scenario, the backend component may be a co= nfidential client > which is issued its own client secret. =E2=80=9E >=20 > Confidential clients can use various authentication methods, =E2=80=9Esecr= et" misleads reader towards traditional client secrets. private_key_jwt and m= TLS are possible (and better options).=20 >=20 > =E2=80=9EDespite this, there are still > some ways in which this application is effectively a public client, > as the end result is the application's code is still running in the > browser and visible to the user.=E2=80=9C >=20 > Why does this make the SPA a public client? I see the risk of a browser ba= sed app (and every kind of attacker) to access protected APIs through the ba= ckend. That's the reason why I think the backend should never directly expos= e (=3D=3D just proxy) the underlying RS APIs. The interface between front an= d backend must be narrowed down to the specific use case AND the current sta= te of the app. For example, if the app is in "check out" state it makes sens= e to initiate a payment but in no other state. =20 >=20 > General remark: I would suggest to restructure section 6 to describe the p= otential architectures this BCP has in mind. =46rom my perspective these are= : > - "pure" SPA > - SPA w/ backend > - SPA w/o OAuth (as fallback) >=20 > Section 7.1 >=20 > =E2=80=9EPublic browser-based apps MUST implement the Proof Key for Code e= xtension to OAuth, and authorization > servers MUST support PKCE for such clients." >=20 > Any client MUST use PKCE (see Security BCP) - PKCE is used beyond intercep= tion prevention to detect injection. Please refer to section 2.1 of the secu= rity BCP it has all the details. >=20 > Section 7.2 >=20 > =E2=80=9EAuthorization servers SHOULD require an exact match of a register= ed > redirect URI." >=20 > Please make it a MUST as stated in the Security BCP, Section 2.1 >=20 > =E2=80=9E If an authorization server wishes to provide some flexibility i= n > redirect URI usage to clients, it MAY require that only the hostname > component of the redirect URI match the hostname of the URL the > application is served from.=E2=80=9C >=20 > Why do you soften the Security BCP requirements? That's the road to open r= edirection! >=20 > Section 8 >=20 > This section lacks a motivation for RT usage. In my opinion, there are two= reasons:=20 > (1) use RTs instead of refresh via authorization code flow (to cope with I= TP2).=20 > (2) be able to issue short lived and privilege restricted access tokens in= order to limit the impact of access token leakage at resource servers. >=20 > Both are good reasons that deserve dedicated discussions. I therefore sugg= est to split & change Section 8 into two sections, =E2=80=9EAccess Token Ref= resh" and =E2=80=9EAccess Token Replay Mitigation". >=20 > The section on access token mitigation should discuss potential options, i= ncluding=20 > - Token Binding=20 > - mTLS > - RT rotation > =E2=80=A6 >=20 > Section 9.1 >=20 > This BCP describes different SPA design where such apps can be either publ= ic or confidential. So I would not preclude confidential clients. >=20 > Section 9.4 >=20 > You might want to refer to the Security BCP as it has more details on this= topic.=20 >=20 > I would also suggest to add use of CORS for CSRF protection in the browser= (see https://www.ietf.org/mail-archive/web/oauth/current/msg18591.html) sin= ce it is SPA specific.=20 >=20 > Section 9.6.=20 >=20 > I would argue enabling CORS is not a security consideration but a function= al requirement towards the AS. >=20 > 2nd paragraph >=20 > CORS and authorization of GET&POST requests plays a vital role in CSRF pre= vention if the access tokens are conveyed in a cookie as well as for any aut= omatic way to add authorization headers to outbound requests (see above). So= I think it must be managed properly. >=20 > Section 9.7 >=20 > Why do you bind CSP to RTs or long living access tokens. Isn=E2=80=99t thi= s anyway a good idea to prevent XSS? >=20 > Section 9.8.6 >=20 > injection is neglected - I think you could just refer to the Security BCP f= or the discussion of the risks associated with implicit. If any threat is mi= ssing there, we can add it there.=20 >=20 > =E2=80=9EIn OpenID Connect, =E2=80=A6=E2=80=9C=20 >=20 > Not clear to me what this text shall convey. Is it a statement in favor of= issuing id tokens in the back channel in OIDC? >=20 > Section 9.8.7 >=20 > I would put this text in a motivation section along with the explanation w= hy CORS adoption allows code adoption for SPAs in the introduction of the BC= P. >=20 > kind regards, > Torsten.=20 >=20 >=20 >> Am 17.12.2018 um 22:01 schrieb Hannes Tschofenig : >>=20 >> Hi all, >>=20 >> We would like to get a confirmation on the mailing list for the adoption o= f https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-02 as a= starting point for a BCP document about *OAuth 2.0 for Browser-Based Apps*.= >>=20 >> Please, let us know if you support or object to the adoption of this docu= ment by Jan. 7th 2019. >>=20 >> Ciao >> Hannes & Rifaat >> IMPORTANT NOTICE: The contents of this email and any attachments are conf= idential 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 o= ther person, use it for any purpose, or store or copy the information in any= medium. Thank you. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Tue Dec 18 17:21:02 2018 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 9FCDF130DE8 for ; Tue, 18 Dec 2018 17:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.566 X-Spam-Level: X-Spam-Status: No, score=-14.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 rBDQG8ca5Bzh for ; Tue, 18 Dec 2018 17:20:58 -0800 (PST) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341751276D0 for ; Tue, 18 Dec 2018 17:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1545182458; x=1576718458; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=IwkhY6dwg27mdjazwJh+GiOWSa0gVrEUzblhtuVK9Vs=; b=jKZBqocliOinmEtT3xvA3blwMDgcpVRufCbM+vUuIwzHwJmUHrvdsOkv PIC6uOK3lpoaBvwIIExrpQ0gOVDHUebifpQcLPnvr7HA41Khw31O87MQf Rt6kpTzZFy31JXi+RTwvUCJh7J/NBzYt3TjYx30bEl16hFnvBTSfTCnna k=; X-IronPort-AV: E=Sophos;i="5.56,253,1539648000"; d="scan'208";a="777024313" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-1a-807d4a99.us-east-1.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Dec 2018 01:20:55 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1a-807d4a99.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id wBJ1Kpqu063633 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Dec 2018 01:20:53 GMT Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 19 Dec 2018 01:20:53 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 19 Dec 2018 01:20:52 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Wed, 19 Dec 2018 01:20:52 +0000 From: "Richard Backman, Annabelle" To: Hannes Tschofenig , oauth Thread-Topic: [OAUTH-WG] Call for Adoption: OAuth 2.0 for Browser-Based Apps Thread-Index: AQHUlzkV+Cli+sUWS9WAastnHMBWKw== Date: Wed, 19 Dec 2018 01:20:52 +0000 Message-ID: <691FAEB9-51F7-4967-9F55-9479CA21C7B1@amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.82] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 for Browser-Based Apps 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, 19 Dec 2018 01:21:02 -0000 SSBhbSBpbiBmYXZvciBvZiBhZG9wdGluZyB0aGlzIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVu dC4gVGhlcmUgaXMgYSBjbGVhciBuZWVkIGZvciB1cGRhdGVkIGd1aWRhbmNlIGZvciB0aGVzZSBj bGllbnRzLg0KDQotLSANCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0K IA0KDQrvu79PbiAxMi8xNy8xOCwgMTowMiBQTSwgIk9BdXRoIG9uIGJlaGFsZiBvZiBIYW5uZXMg VHNjaG9mZW5pZyIgPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIEhhbm5lcy5U c2Nob2ZlbmlnQGFybS5jb20+IHdyb3RlOg0KDQogICAgSGkgYWxsLA0KICAgIA0KICAgIFdlIHdv dWxkIGxpa2UgdG8gZ2V0IGEgY29uZmlybWF0aW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QgZm9yIHRo ZSBhZG9wdGlvbiBvZiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFyZWNraS1v YXV0aC1icm93c2VyLWJhc2VkLWFwcHMtMDIgYXMgYSBzdGFydGluZyBwb2ludCBmb3IgYSBCQ1Ag ZG9jdW1lbnQgYWJvdXQgKk9BdXRoIDIuMCBmb3IgQnJvd3Nlci1CYXNlZCBBcHBzKi4NCiAgICAN CiAgICBQbGVhc2UsIGxldCB1cyBrbm93IGlmIHlvdSBzdXBwb3J0IG9yIG9iamVjdCB0byB0aGUg YWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBieSBKYW4uIDd0aCAyMDE5Lg0KICAgIA0KICAgIENp YW8NCiAgICBIYW5uZXMgJiBSaWZhYXQNCiAgICBJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVu dHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRp c2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBw dXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBU aGFuayB5b3UuDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiAgICBPQXV0aCBtYWlsaW5nIGxpc3QNCiAgICBPQXV0aEBpZXRmLm9yZw0K ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCiAgICANCg0K From nobody Tue Dec 18 23:35:31 2018 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 5E59C130DEC for ; Tue, 18 Dec 2018 23:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=risecloud.onmicrosoft.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 1ZdpA21FSmVX for ; Tue, 18 Dec 2018 23:35:25 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on060c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::60c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B4E12426A for ; Tue, 18 Dec 2018 23:35:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EJMjDjLJTcF1ZaH+SuX4Oo+0QhqDZoyisbD8iGSdoJU=; b=Wgv3sHVSjZfz1IEgvn64U/DUfrXvZjDEmKq+u0khoknE1qdSvL/dT+bm1OZ/9V+An122fhfIFvKfXBHv5Ybd4b32JMobxrVvLWYjhfZdFQsJ8LV5bOab/p3C/q9D1WKU+XU/IBp39tZFe0zet5U2KKhfYvAxGw7MRrI7iUGaQdk= Received: from VI1P189CA0011.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:2a::24) by AM5P189MB0321.EURP189.PROD.OUTLOOK.COM (2603:10a6:206:20::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.17; Wed, 19 Dec 2018 07:35:23 +0000 Received: from HE1EUR02FT062.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::204) by VI1P189CA0011.outlook.office365.com (2603:10a6:802:2a::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1446.17 via Frontend Transport; Wed, 19 Dec 2018 07:35:22 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT062.mail.protection.outlook.com (10.152.11.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1446.11 via Frontend Transport; Wed, 19 Dec 2018 07:35:22 +0000 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 19 Dec 2018 08:35:21 +0100 To: References: From: Ludwig Seitz Message-ID: <3ce80a08-32d8-b05e-0642-a30a1467d0aa@ri.se> Date: Wed, 19 Dec 2018 08:35:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(136003)(346002)(396003)(376002)(39860400002)(2980300002)(199004)(189003)(186003)(106466001)(16526019)(2486003)(23676004)(74482002)(14444005)(26005)(356004)(77096007)(44832011)(229853002)(6666004)(386003)(486006)(53936002)(86362001)(446003)(53546011)(2616005)(50466002)(126002)(476003)(11346002)(76176011)(33896004)(508600001)(336012)(65806001)(22746007)(64126003)(6246003)(36756003)(31696002)(81166006)(69596002)(40036005)(6116002)(230700001)(65826007)(3846002)(47776003)(6916009)(22756006)(104016004)(2906002)(117156002)(16576012)(31686004)(316002)(97736004)(58126008)(561944003)(5660300001)(68736007)(305945005)(7736002)(8676002)(106002)(81156014)(67846002)(65956001)(8936002)(2351001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P189MB0321; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR02FT062; 1:B/SYruK3K3kzwkaO4S9dggZqyH0RsyhVUUmILHY1pMxHK5qs5KfJvnbtH3IDC0ahxbghxhIR5uCy3DXikJkzdZ8J8jSH4lWOnS/Pz4/4/MpFcuB8ucV3u9V+0/J3qaYL X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8130e12e-7b53-46d3-b4fb-08d665848891 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:AM5P189MB0321; X-Microsoft-Exchange-Diagnostics: 1; AM5P189MB0321; 3:G5apigngeWmIAKlL1I+4p5K4mW4JHmpi7dkx2JocV0/1qIESDtsfT7RtVhaqCSb9BkW9JzJHeWlr29zVW0Uj4X4soU+cUCEmDh4WsHGS2b49LKmSwFp/RjvvyOdI0HNxgWyeXMf57LlAL2ygz2KYgHNrTP7ztZOFX9WgOrso7oYT0fHPt0TEF8lGQdOJHACL4yubRyHnnGNj8CMlZ5MsMio7Hwdgq6JLMD4qeejeYwgmvBJ9ZGcVjW7ySeVz34JJCM4tlDei/hdNSjSEqM+U9HWGTq0ntGSyxN6e6a4MjwBcE0fxXnlVPOqaPEeRf9Tn2H3FhqRv+6IWWllHOliHkdFAOKCLVp66krc4Tfp+xYM=; 25:l/OfFYr2SR6dPdnN9Sit9fJ9B60we0a33WTJSuTzavrpipQvAb/Q156Zx0dh/3u3W64fLoPyqXKXP9eNDw8wME4XOhbxzGAuPUgJ6q68zEzIdU30PkY/LfSFFpVdIoGmY/6Lbcw6d+y8ApITVBKeXzWD/0Mdo1V+XvuAJ+dSbXI7sZ6ir8GPYzEDHac4Xqp00XnJf3TkDSPSzKLoK/aDdyVwmS6v6KNshTHFXqoxI5bSTYzXYPJ/pv4RjZViSLYvPF7acLUeAX2F8nrfVuMgAZAV6HDdv5h2PxF/aMyps26t4UgYbRFjuI4PQCXh+PF6STixfdRw18EYZ4zy4hzytQ== X-MS-TrafficTypeDiagnostic: AM5P189MB0321: X-Microsoft-Exchange-Diagnostics: 1; AM5P189MB0321; 31:wy8lDceSnBzp2LOHHrSEcjM189LE6r+FImcjvEJO5jdeXlm8sj9/NusbbrfLVXgT63zrC/WyKT8ZCA/g0Jv5sBba8qckMzSdNI7IjzvVvp1Tq/i+HgMBr79GhqIo/OfbmcNqN77lbXs8fjL6sHJtJYHYQvmr/VopWXKoN9vFH4M/Xnmenn9HFu5Wu9J+WVPcf0mKzmMubYXpC9dXa4ECOmSPx0v2NCGJKOYn9CdBioU=; 20:pFIC0Lv+y1CEUhGORZ+6yJupdsR3BIw7HyIk6WlN4Z/uB58YH9Na0bXNCOBLMSC4O0lcadSEje78Z1bjVxA/zBkEK3dVbbx0SqQU70MGd66uTOE3ERKereQ8ITrp3hwOWMoUKOzRJov3aNQyc4dCOU9eeCpdq1mClB7TihV3wR3ecDGpd00T5P2ciVsHhptgU8lJ3lS3YEbkdo84Ro7FDOEITmjO2e8LU4wALD28VEWp5CIwFk4HyKPqy2E9TC3r; 4:VxokyjQZdxGLSBOqKH1El8bqLUjvNVPMLWdNd1kOOMcRMj4TtGprwuqVr+IzekHiw8DshQL79jYjHiOxR5XmKaI+CiIkGLkgUJtmF6QS2DCa2Z/VJnxj+7zDinfHffI9Adj8pYfMf3K0u9PbMjwVXM60I+wdlVzUzx3tdzWOt9sGd/iluLBJQjbgJoPTIKpXVvViLVwFpbj0He++kZXl5mSbeAUgyfotNKP/yqmjKrcabR/+4OEOrZwNIgAusQyqqgE0Eyrz2ahbYqtKJvkoFw== X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231475)(944501520)(52105112)(93006095)(93004095)(148016)(149066)(150057)(6041310)(2016111802025)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(20161123558120)(20161123564045)(20161123562045)(6043046)(201708071742011)(7699051)(76991095); SRVR:AM5P189MB0321; BCL:0; PCL:0; RULEID:; SRVR:AM5P189MB0321; X-Forefront-PRVS: 0891BC3F3D X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQMTg5TUIwMzIxOzIzOnJnQlJHcTNGY1hCemk5QUlnRGpLWTJiVHVH?= =?utf-8?B?cEhMaTJSRnQyZnBZQ0Rjc2FaaExOQmRUMFR1RHpVUVFoWHI0djl5WXdnTWdW?= =?utf-8?B?ZEp0Q0ZYa2ZMUWNoNkl0U21mdHpwcjZrSDZPMTFqWEM3cm5LOE5abXVJYUFI?= =?utf-8?B?L0x6TXhwZVFvYjJWeVNPZ2prWnkvS1JKZWkrakNTYmZlOEFDdWxzMXVuTG9t?= =?utf-8?B?Q0lrS1dobmE2d0laLzNqSGlrNzcrMlhRc3U5eWRTcWhDNEE5TUZ6VzRHbDB6?= =?utf-8?B?SVlQT0Z5Yzh2ek1WS0UxR3VIWnVYMkJYamcxcjRNakNFYTJGaE1sNjloc1Uy?= =?utf-8?B?UVBoY2xpSGwzMC9GU1U5bHBheElSTWRUeUUyajdMR2M0T1NkL1d0WlU3dTRm?= =?utf-8?B?cm8rcVdlS251cHgybGovWi92SFN0VkpXVE9wek1CT0g5d3QxTXVRTEZ5Um45?= =?utf-8?B?bDM5b3hueEtNYnprM3FqMURyN3d4QXhRNlZyaDdWSHpMRHRqS3hZdHdjbUtj?= =?utf-8?B?bTZXRzRlL2tLYkJXR1huWEJCMnV3ZzljcDZVRXBVQUVYdU1lL3lFV0d0S2cx?= =?utf-8?B?Nk4yWllOT3RuZDV2ZjcwMXFGc3lMR1AyTlRrcm96MkRQSVdzTUZFYTloS1d6?= =?utf-8?B?MEZITmoxODZJL2RxS1FMQkQrSldPejNIaGlIajByZ3d3dGFydjZhcG9tY2Rk?= =?utf-8?B?NG1ZOTVLNlYwU0FkYXhSZTdqQzVIR1g5V2VGV2I4K1grN0l1N2pxNUMyWnJK?= =?utf-8?B?a2RtNkhwU0ZWeTlKSWhoYzlHVzl0R0VHWVhNUzVRMHYyZDJhTHNvZEQ1dFdC?= =?utf-8?B?ZTR4d1h1VHNGQ3R5Vk5OTTgyWTc1Y3NaY0JiSTBMS1p4QTRhRVJzQk1zNVpQ?= =?utf-8?B?WGVGUWNPNkRyWGJqbjFjZGpwVEI5bTNJYyt6NkxKV3VYVk5WR00zL1h3WG1a?= =?utf-8?B?NFNwdWY0OU42RWpjYVZBQllyYmJIdUZSOFhCSndMR0hHVDg5Rm5ySzEyOGps?= =?utf-8?B?aVBvNzM4TmdrQkV4Rk0zYjNoZW80Z0tZbjUrbFk0Nk9zNjRDTzZjdmVkYkFM?= =?utf-8?B?dFFUNGQvdys3OWd1Zkhsd2tkZjVHWFhTcGZNdFhoaEhMVGh5RUx1LzAzMUFV?= =?utf-8?B?NW9FdjJmeVo0QmR6RDdDWXlLeGNIZHVZb1NVTUJ0Y2FVN2pzZE8rNi91RStX?= =?utf-8?B?Rlc4OUtNclpJTkVrWG5jMC94ZmpRNXpNRmFmMGQ1OXNiOHIrQ3FEaFphZGFy?= =?utf-8?B?YU9MUTVENnJJb045K0tnSkdGRHNMRUtENWk3YmYrUjcxWmtJQ1NFUUsvRzAv?= =?utf-8?B?SzFZbk9Jbkp4Y0ppa1ZYQlpCaSsvaU82MFB6RllXZHdDRHkvanlQY05ZN3BJ?= =?utf-8?B?TWZRVUlzaHMzbzQ0c2MzeStSekNaRHlkRzlIbGVzOXRtTTFtV3gwU2cvU3Rs?= =?utf-8?B?cHZWQjVsK1loeHBkdlpneWVHVmQxZVh2c0N4VWlUVzdjcVZPNWwyY3NvV1Rn?= =?utf-8?B?Sm5QbmN2dHpJenJONGVKZm0wVXY5NGNkS0FRTG5KVWFzSXgwUTBlaWNpRExs?= =?utf-8?B?aXQveVJTMXoxZ2NoNXpTcGk3Rm9mTFRwSDk2dmJ0RTF4K0tTaWRJUWIxbWJP?= =?utf-8?B?OXltWXVNMGloZmxGSTVkRGc2YjYvUFpQNE1hbitQcE9sNnJiS0ZxcExVcjNJ?= =?utf-8?B?Z093QmNWRFM2SXkzQ3d0YjE5OERUT0xxa0FpeUtWbHZmeWIwOEtuMU1IR01P?= =?utf-8?B?eTJLdWpIYUVoV25vZ3JFMTZ4UHM3eCtNa3hLbW9Oc0xDYWxMdnNVcURsUXJ1?= =?utf-8?B?c3F2OFFCalVLMTFWRUl1ZWptb2ZFejdBYnV2cjVuUHQraFZsS2hzM000UlpU?= =?utf-8?B?bnZwUlUwWXU2c0xDQ011RFcrWlhIekpWQzZET1JwalZISkZoL3hxMjQvbVVy?= =?utf-8?B?TDVYU2xwYmJpT1JURUJxUURDT2l6N29rRzZrOXJOWXREYlZwZzVLaUczRU5n?= =?utf-8?B?bzQzUEEweHpsMzZ2eUFnTjQyZENSMU5pcm9GQVJHRGJzWTdSZi96SjRTeUNo?= =?utf-8?B?ZjllTTR6Uit5amJ5L284TTJXQlQ3aWVTTzRLSDFQSkh2dFRxTXlkMWp5VnRx?= =?utf-8?Q?WNUY+xEVbxtYlWU7AVo2VII=3D?= X-Microsoft-Antispam-Message-Info: V4P3cp0iSQKOZav86eONUAwG8BewWRzPD+xdQyX7YErV/4R6d6b7h0z+/SkjsEQe0U+LuVbwFQXiBASvE9TvxedyPqA19+0Q4rqUvZo8CHNDj9KgLEbiUm8GdIzZOlzfdCYwYoF01xBD8bq5UA/DcZM/VW7Mkzxqc2mWFX01+MkH9doxfXAwjUAk8vScvdpsI148G/xYt08ahhmsQMvwpeUpzu06320ojX9zR4U5dVE1PnZ63vnlg/EbaKh+JTcABfBTFrsvx2yutesQ63N6wDHkGFH5Ly8cPhvRmb/AOFz0quJw7laux73X6z4IV1nH X-Microsoft-Exchange-Diagnostics: 1; AM5P189MB0321; 6:ewC9zserO+GFabMWwWNDDeuje3RUh7T+lGMxAywsSi1LzZzJevUarNNFlIHQ/zbBf0M5sIscbux4CqpYFhxwetF/cbI+xsmu0EpgRJUwiouya1VDaoVjzv5qjTAi3vLQc6R2km6oRL8jgqfeZXCmj5G8fGX6qmF+pTCo05rHo3ZO2YXqAPxRNyTvP/Xs8owk7c/iuAZE6SJ4tJfLNso8QoMrspj06xSc2FxcSJ9RFpGfaYiW/fmhqP4SRNXTDolHOnkIOTFBB002DTnm4lToue5rGHkDFsPVIe09BvrTlxyvI3vGDX+cw8g6GcjEyb0djdYaykurDWytskAp65+dbiF85DniO1yEq/hFSbTp5jEyGqF+tHb3Qnj0LRwjmO4vb2vrlmDCPK5p6YhL6iv+0Fhm582z6Kb4Nm5+ILDJUR18WSEcgc1MHpQh1UFrejnMwHJomJElbbqFpAibDetyQg==; 5:MeS+BjtJ0aU2GQ25OOezYzFoUL6xNEWAbgWVm2tmtYVMDb2VZKFuQldp6Su/+fUwvGbwNnRP7mb/5Y4+s+8fLo7+I4k6UIkjjYgT4OvDSfgTpIcB3eRepJ87esOGElhVhSSbhbHBl1LdxtwP/I33ivvu8vHNA1jygJGDsLZZjZ0=; 7:TS8dVA+wF+XBCpBodiuqwG6RtIZmX6VbXk0736Fm8Rq7o7zEyfrDS7cpduN8mIIHwDxSu+Vlo67EEf6yGErHD9tFEJqUdfWQoD/jGe2PLMNSLEuDEuqqatAPnwHAQGBGL6d/p+h4XJFhJ/FniCPLTQ== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2018 07:35:22.0061 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8130e12e-7b53-46d3-b4fb-08d665848891 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P189MB0321 Archived-At: Subject: Re: [OAUTH-WG] exp claim ... was RE: expires_in 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, 19 Dec 2018 07:35:29 -0000 On 18/12/2018 17:06, Aaron Parecki wrote: > The "exp" claim is an implementation detail of one type of access token, > but obviously doesn't have any meaning to someone using non-JWT tokens. > Since not everyone is using JWT access tokens, it seems strange to have > a mention of a JWT-specific detail. > > That said, it sounds like the proposal is to recommend access tokens > always have an expiration date? In that case, is it also important that > the expiration date be communicated to the client? > The original context was from the ACE WG. In ACE we use pop-tokens exclusively and it is important in some usecases that the client no longer uses the pop-key material when the token has expired. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Wed Dec 19 00:20:45 2018 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 82CA1130DEB for ; Wed, 19 Dec 2018 00:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_PASS=-0.001] 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 r-S08g8u6Opj for ; Wed, 19 Dec 2018 00:20:41 -0800 (PST) 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 AC7DE130DC8 for ; Wed, 19 Dec 2018 00:20:40 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id m22so5384852wml.3 for ; Wed, 19 Dec 2018 00:20:40 -0800 (PST) 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=Ku0j/cK9VkmrzByJoQGS/dTMexLP/rrlbSDnOfsAwR0=; b=ZT26kuS6IzJG5TIsXx196e/WkQhX1cMZjQAsBHG+uRJoYoPA/0dPsEvlEb9Q292GI+ Z2dHyl5yuyoyQDQeDvYMMq3jeoSmh7QYj8C/5X7OEJf0N0g6YauWB1wEhKrG12ie0uO1 ka30ZkrmJsSjtToc32ZOzsO7pZvcZ5/TBq/p9fhExzhDTUqU30qYOofxubwJB73qYjJZ /8+5FnuK3LQcjkL7MV6gVOSQ/s/xovMkEdcn1YtfxyEndsBvQURW0tTzGrcYMsLk3ZuJ ESacfHAnwMEXk8iZW+RCvcvmbN69HdioiM+7t6clRyXsgxI8ByvF+7uHz33CIXtaQ1pY 31TQ== 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=Ku0j/cK9VkmrzByJoQGS/dTMexLP/rrlbSDnOfsAwR0=; b=DqSEKE0klvAD56zTdbrXDcnhbhSQt8I/T7pc0NIEmnRwGpBpivzlvpH02sqJEKqgI3 ERpWbT3h97AFp31y/3N1Zz/KIF3F9+vBBWHinQpay/BezlIDAK4iCIaOKGVybN+wrARx Siy6sWxNKK8Sjl8bJzn7iUozjXIADpr5gQnoCx931NYhSx9mBuv67u/3i8J9CsKi1q9I JJ5JWtB4o5KZQv260x+TYY976IPh8ooLToR0ZLJjOUV7aYiJutpcBsCWuv5jWULLPNM9 kP7FSLznig5OTgfKWvguCoIQrbJNk4LPcpVmjeoLilrjtj7M0Sqjv4+8JHQ7MCxp1cl2 IebA== X-Gm-Message-State: AA+aEWYbWMccV9ErM5eB5c3aoSKTW8XejiGX+PRqQib5jSyZg40WO099 Fq8rVP0OCdprG1UdBMksCF2p518L9btF4w== X-Google-Smtp-Source: AFSGD/Urwr6Q3sMlCHhK9ABQpJKi5gqZb3yasGMtCx8Z4kxFPUeUM3G2anjz55HMBIo6JtGF1/2UiA== X-Received: by 2002:a1c:a755:: with SMTP id q82mr6449199wme.6.1545207638791; Wed, 19 Dec 2018 00:20:38 -0800 (PST) Received: from ?IPv6:2003:c1:4f01:c300:5907:efe:5f7f:84e2? (p200300C14F01C30059070EFE5F7F84E2.dip0.t-ipconnect.de. [2003:c1:4f01:c300:5907:efe:5f7f:84e2]) by smtp.gmail.com with ESMTPSA id l197sm11651002wma.44.2018.12.19.00.20.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Dec 2018 00:20:38 -0800 (PST) To: oauth@ietf.org References: From: Daniel Fett Message-ID: <36ac942f-72f8-f3c7-5eda-43bc2a22beac@yes.com> Date: Wed, 19 Dec 2018 09:20:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D4B05DA258E97767913CF1E4" Content-Language: de-DE Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 for Browser-Based Apps 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, 19 Dec 2018 08:20:43 -0000 This is a multi-part message in MIME format. --------------D4B05DA258E97767913CF1E4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi all, Am 18.12.18 um 19:14 schrieb Torsten Lodderstedt: > Hi Hannes, > > while I think the current text needs some substantial work, I support the adoption of this draft as a working group document. I also think we need to carefully define the boundaries between the Security BCP and the SPA BCP in order to prevent unnecessary duplications and inconsistencies. +1 > General remark: I would suggest to restructure section 6 to describe the potential architectures this BCP has in mind. From my perspective these are: > - "pure" SPA > - SPA w/ backend > - SPA w/o OAuth (as fallback) This distinction is very important and should not be discussed in Section 6, but in the beginning of the document. -Daniel --------------D4B05DA258E97767913CF1E4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi all,

Am 18.12.18 um 19:14 schrieb Torsten Lodderstedt:
Hi Hannes, 

while I think the current text needs some substantial work, I support the adoption of this draft as a working group document. I also think we need to carefully define the boundaries between the Security BCP and the SPA BCP in order to prevent unnecessary duplications and inconsistencies.


+1


General remark: I would suggest to restructure section 6 to describe the potential architectures this BCP has in mind. From my perspective these are:
- "pure" SPA
- SPA w/ backend
- SPA w/o OAuth (as fallback)

This distinction is very important and should not be discussed in Section 6, but in the beginning of the document.


-Daniel

--------------D4B05DA258E97767913CF1E4-- From nobody Fri Dec 21 14:38:23 2018 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 0AA79130EA3 for ; Fri, 21 Dec 2018 14:38:22 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 3-sif7WiNYSu for ; Fri, 21 Dec 2018 14:38:19 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 93871130E9F for ; Fri, 21 Dec 2018 14:38:18 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id e26so4965978lfc.2 for ; Fri, 21 Dec 2018 14:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PVYC4mf/kqzHv+NyW2GfLaZ+OUYq6iy+McHB1od79wU=; b=uU7twoEfUaYwimj+p5HgBWMIfjVdXufnotCE8vsF5M48tot0l8ldQj//jry6ziOkJo wfW0LPFF5QT4XB089S1VW+S5n+4uyqfHGAWezNAPiH9fWy0mtMFuE0cf71AAjCEwIFFU 7DZFTvsLKwtPOkS1Pao2p8mAOG0iMoEK+sNVHgk6Pe+7T/ITRPBr5LLSsukK8A7tmCFi 3Nam7WsMlEh5hMhdYUkxb7ocXtE8ZlB1zi6keSRn3r9Q2q43Tphg8jxAAPVN/e1in3Hb Fz4NGSNFkDY/V9kRELct/TwuvB0QfVXa2ofU+nJd63Zj7mKmUqlT9omsijSv6FlocnMq KPfw== 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=PVYC4mf/kqzHv+NyW2GfLaZ+OUYq6iy+McHB1od79wU=; b=FTyuWnItI0UQr1dCOoU1eM1edv9dDIoyvdRcsPz7M4+VIDZpKNgeeiJEw+C5Xe0x7T Tw6uB6avGmE1J1WMrV2AV8P5VYqYiD67QHW7R9dvFfUdwZg3Jc3887a3l5lf3PnWCiLj AZbQaG38lbD1WHpXBI8JzSYcIJtcpAgdezed59z1JQIbo4NaD3NmWrY3pL/Jc8BJYEek JF5vQJmqzyMzrr96kR2F5+lNQcjmbdWh0eo6Cif13K8kafif/r2tnXlfIFquoiYFcIqD KT+jvllkhaXEpKJczLRwvQ6EjebQz6ylUbCL2lyTXHNqYZhMPx4jO1GUj/HisppEAZ3p melw== X-Gm-Message-State: AA+aEWbDHAFNYM+YICwOL6Zu32RNgmx/QNLEWyTLvGxHfp9yS6XMPXzf JJvfVWMm2T09IqaaTuv2pNfrzM4a276FjT2NvyZ6EZZF X-Google-Smtp-Source: AFSGD/XSlbgbqdkqu0b35tXnK2NWHEYNavQx7mwcRVWwB3VXGWAHExkJ2uLh1uiyeJuQblz99NamBJSgQLv9WCWwRA4= X-Received: by 2002:ac2:4343:: with SMTP id o3mr2474132lfl.129.1545431896728; Fri, 21 Dec 2018 14:38:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 21 Dec 2018 14:37:40 -0800 Message-ID: To: Mike Jones Cc: oauth , Yaron Sheffer Content-Type: multipart/alternative; boundary="0000000000003aba3a057d8fe789" Archived-At: Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-bcp 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, 21 Dec 2018 22:38:22 -0000 --0000000000003aba3a057d8fe789 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 5, 2018 at 12:39 AM Mike Jones wrote: > Hi Eric. Thanks again for your review. > https://github.com/yaronf/I-D/pull/24 is intended to address your review > comments. Text changes made to address each of your comments are listed > below. > > > > *From:* OAuth *On Behalf Of * Eric Rescorla > *Sent:* Monday, August 27, 2018 4:03 AM > *To:* oauth > *Subject:* [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-bcp > > > > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D4649 > > > COMMENTS > S 1.2. > > 1.2. Conventions used in this document > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > > "OPTIONAL" in this document are to be interpreted as described in > > [RFC2119]. > > You will want to cite 8174 here. > > < The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", > > < "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in > this document are to be > > < interpreted as described in {{RFC2119}}. > > --- > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > > > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", > > > "MAY", and "OPTIONAL" in this document are to be interpreted as > > > described in BCP 14 {{RFC2119}} {{RFC8174}} when, and only when, they > > > appear in all capitals, as shown here. > > > S 2.6. > > > > 2.6. Substitution Attacks > > > > There are attacks in which one recipient will have a JWT intended > for > > it and attempt to use it at a different recipient that it was not > > intended for. If not caught, these attacks can result in the > > I don't understand this attack. Can you go into more detail? > > > For instance, if an OAuth 2.0 {{RFC6749}} access token is presented to > an OAuth 2.0 protected resource > > > that it is intended for, that protected resource might attempt to gain > access to a different > > > protected resource by presenting that same access token to the different > protected resource, > > > which the access token is not intended for. > > S 3.2. > > Therefore, applications MUST only allow the use of cryptographically > > current algorithms that meet the security requirements of the > > application.. This set will vary over time as new algorithms are > > introduced and existing algorithms are deprecated due to discovered > > cryptographic weaknesses. Applications must therefore be designed > to > > enable cryptographic agility. > > Is this must normative? > > < Applications must therefore be designed to enable cryptographic agility. > > --- > > > Applications MUST therefore be designed to enable cryptographic agility. > > > S 3.2. > > may be no need to apply another layer of cryptographic protections > to > > the JWT. In such cases, the use of the "none" algorithm can be > > perfectly acceptable. JWTs using "none" are often used in > > application contexts in which the content is optionally signed; then > > the URL-safe claims representation and processing can be the same in > > both the signed and unsigned cases. > > I think you probably need to have a clearer "don't use none by > default" statement here. > > > The "none" algorithm should only be used when the JWT is > cryptographically protected by other means. > Is there a reason this isn't a MUST? S 3.4. > > > ECDH-ES ephemeral public key (epk) inputs should be validated > > according to the recipient's chosen elliptic curve. For the NIST > > prime-order curves P-256, P-384 and P-521, validation MUST be > > performed according to Section 5.6.2.3.4 "ECC Partial Public-Key > > Validation Routine" of NIST Special Publication 800-56A revision 3 > > [nist-sp-800-56a-r3]. > > Is there an X25519 specification for JWE? If so, you should probably > specify the appropriate checks. > > > Likewise, if the "X25519" or "X448" {{RFC8037}} algorithms are used, > > > then the values MUST be validated according {{RFC7748}}. > > S 3.5. > > 3.5. Ensure Cryptographic Keys have Sufficient Entropy > > > > The Key Entropy and Random Values advice in Section 10.1 of > [RFC7515] > > and the Password Considerations in Section 8.8 of [RFC7518] MUST be > > followed. In particular, human-memorizable passwords MUST NOT be > > directly used as the key to a keyed-MAC algorithm such as "HS256". > > If you can't use them "directly" than how should you use them? Do you > want to say anything about password hashing (argon, etc.)? > > > Rather, the principles from {{RFC2898}} SHOULD be used > > > to derive cryptographic keys from user-supplied passwords. > This doesn't seem to have made it in. -Ekr > Given the broad diversity of JWT usage and applications, the best > combination of types, required claims, values, header parameters, key > usages, and issuers to differentiate among different kinds of JWTs > will, in general, be application specific. I get that this is the state we find ourselves in, but it seems like it's unfortunate. This might be a good time to re-emphasize the recommendation for explicit types in 3.11. > For new JWT applications, the use of explicit typing is RECOMMENDED. Thanks again, -- Mike > --0000000000003aba3a057d8fe789 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 5, 2018 at 12:39 AM Mike Jones <Michael.Jones@microsoft.com> wro= te:

Hi Eric.=C2=A0 Th= anks again for your review.=C2=A0 https:/= /github.com/yaronf/I-D/pull/24 is intended to address your review comme= nts.=C2=A0 Text changes made to address each of your comments are listed be= low.

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Eric Rescorla
Sent: Monday, August 27, 2018 4:03 AM
To: oauth <oa= uth@ietf.org>
Subject: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-bcp<= /u>

=C2=A0

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4649


COMMENTS
S 1.2.
>=C2=A0=C2=A0 1.2.=C2=A0 Conventions used in this document
>=C2=A0=C2=A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The key words "MUST", "MU= ST NOT", "REQUIRED", "SHALL", "SHALL NOT"= ;,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "SHOULD", "SHOULD NOT&quo= t;, "RECOMMENDED", "NOT RECOMMENDED", "MAY", = and
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "OPTIONAL" in this document ar= e to be interpreted as described in
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [RFC2119].

You will want to cite 8174 here.

< The key words "MUST", &qu= ot;MUST NOT", "REQUIRED", "SHALL", "SHALL NOT= ", "SHOULD",

< "SHOULD= NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY= ", and "OPTIONAL" in this document are to be

< interpreted = as described in {{RFC2119}}.

---=

> The key word= s "MUST", "MUST NOT", "REQUIRED", "SHALL= ", "SHALL

> NOT", &= quot;SHOULD", "SHOULD NOT", "RECOMMENDED", "N= OT RECOMMENDED",

> "MAY&qu= ot;, and "OPTIONAL" in this document are to be interpreted as<= /u>

> described in= BCP 14 {{RFC2119}} {{RFC8174}} when, and only when, they

> appear in al= l capitals, as shown here.


S 2.6.
>=C2=A0=C2=A0
>=C2=A0=C2=A0 2.6.=C2=A0 Substitution Attacks
>=C2=A0=C2=A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There are attacks in which one recipient= will have a JWT intended for
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it and attempt to use it at a different = recipient that it was not
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 intended for.=C2=A0 If not caught, these= attacks can result in the

I don't understand this attack. Can you go into more detail?

> For instance= , if an OAuth 2.0 {{RFC6749}} access token is presented to an OAuth 2.0 pro= tected resource

> that it is i= ntended for, that protected resource might attempt to gain access to a diff= erent

> protected re= source by presenting that same access token to the different protected reso= urce,

> which the ac= cess token is not intended for.

S 3.2.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Therefore, applications MUST only allow = the use of cryptographically
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 current algorithms that meet the securit= y requirements of the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 application..=C2=A0 This set will vary o= ver time as new algorithms are
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 introduced and existing algorithms are d= eprecated due to discovered
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cryptographic weaknesses.=C2=A0 Applicat= ions must therefore be designed to
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enable cryptographic agility.

Is this must normative?

< Applications must therefore = be designed to enable cryptographic agility.

---=

> Applications= MUST therefore be designed to enable cryptographic agility.<= /span>


S 3.2.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 may be no need to apply another layer of= cryptographic protections to
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the JWT.=C2=A0 In such cases, the use of= the "none" algorithm can be
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 perfectly acceptable.=C2=A0 JWTs using &= quot;none" are often used in
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 application contexts in which the conten= t is optionally signed; then
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the URL-safe claims representation and p= rocessing can be the same in
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 both the signed and unsigned cases.

I think you probably need to have a clearer "don't use none by
default" statement here.

> The "no= ne" algorithm should only be used when the JWT is cryptographically pr= otected by other means.


<= /div>
Is there a reason this isn't a MUST?


S 3.4.

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ECDH-ES ephemeral public key (epk) input= s should be validated
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 according to the recipient's chosen = elliptic curve.=C2=A0 For the NIST
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 prime-order curves P-256, P-384 and P-52= 1, validation MUST be
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 performed according to Section 5.6.2.3.4= "ECC Partial Public-Key
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Validation Routine" of NIST Special= Publication 800-56A revision 3
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [nist-sp-800-56a-r3].

Is there an X25519 specification for JWE? If so, you should probably
specify the appropriate checks.

> Likewise, if= the "X25519" or "X448" {{RFC8037}} algorithms are used= ,

> then the val= ues MUST be validated according {{RFC7748}}.

S 3.5.
>=C2=A0=C2=A0 3.5.=C2=A0 Ensure Cryptographic Keys have Sufficient Entro= py
>=C2=A0=C2=A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The Key Entropy and Random Values advice= in Section 10.1 of [RFC7515]
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and the Password Considerations in Secti= on 8.8 of [RFC7518] MUST be
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 followed.=C2=A0 In particular, human-mem= orizable passwords MUST NOT be
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 directly used as the key to a keyed-MAC = algorithm such as "HS256".

If you can't use them "directly" than how should you use them= ? Do you
want to say anything about password hashing (argon, etc.)?

> Rather, the principles from {{RFC2898}} SHOULD be used

> to derive cr= yptographic keys from user-supplied passwords.

=

This doesn't seem to have made it in.<= /div>

-Ekr

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Given the broad diversity of JWT usage a= nd applications, the best
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 combination of types, required claims, v= alues, header parameters, key
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 usages, and issuers to differentiate amo= ng different kinds of JWTs
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 will, in general, be application specifi= c.

I get that this is the state we find ourselves in, but it seems like
it's unfortunate. This might be a good time to re-emphasize the
recommendation for explicit types in 3.11.

=C2=A0

> For new JWT = applications, the use of explicit typing is RECOMMENDED.

=C2=A0

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Thanks again,

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike

=C2=A0

--0000000000003aba3a057d8fe789-- From nobody Sat Dec 22 06:43:13 2018 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 AC323128766 for ; Sat, 22 Dec 2018 06:43:09 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 oJrc2A-KvAlt for ; Sat, 22 Dec 2018 06:43:07 -0800 (PST) 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 672F112875B for ; Sat, 22 Dec 2018 06:43:06 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id x85-v6so7220374ljb.2 for ; Sat, 22 Dec 2018 06:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=vLUsQBxRc1CexLXhvWWyOLaD5xqBFHg0BUFbeaZUyZ4=; b=lSwGsljR0vPtVLjkAYw1vEdjJdkQphiGR0wHCSiBXVC61VmIhURvzd9UuuIVB2I3y0 5pHFg6s6NLR8ZAD5PZPfqHFarU+gsF6CNUK6uT8yVq7ITZaWQncNB/igYgCEMRWM8iS6 Dg12UitlxEnE+ZaVj8aNgoI/x1m8+btBpQx2GTrCxnyQ7H9uJNDnBF+hdZ3eBaQQ8Ggq F31T9oIuQ5vgeaB83ezA+e0V7x/P4B6vH6XJM+5gspNZACmWiuk+LwMo0+N6uxveWw1d ex+H05a9T7LcHWqDyrFFM/ErpO3aU239pLW0Zz0YkzCFNQLfEhCJx/cvZkynW+jNbzXt G4Mg== 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=vLUsQBxRc1CexLXhvWWyOLaD5xqBFHg0BUFbeaZUyZ4=; b=A0YZcl770jYH1NWmzqnYqhnjv4/PnHpaspNotl/2euGAukcRyQLMsYdcDLC8yn3HB1 nIOru5+tdu3exdiBNkzYgOfanaiqL3pgF1tClwmNZe2uh4WOcZVMAGrIFAW5MpiMEgZi cBrVVKjouuMWKoFd0zaxi8suFNSJsoMmVcr9Eig4ExdsMPEvjFcwji3X/bamBmsgM25C vio+eunaKJRhnV23uHhS3bf/HRiO4CTD2fEBrL6V4CKtYTuy5rzErEntWDwS2WL9BdSO O2tXgK2bjds+5B9/pqY4WJsrOFedDItk+NYD0Lt/l9XbzcfjF4RfG0zsnkZuF3VDsuzp Lf4g== X-Gm-Message-State: AJcUukcgVxL/vMdsQXIrxXkxyXvpw5MM//6UagTX1A/sEanIEDS9w6cp NwXzp+j1LoPtCdZQDD3c+emw9YN1+B5WiBnYb4NGdimyLzc= X-Google-Smtp-Source: ALg8bN7TIAOViQE8/MjpAAh6O8R3VP1uKK7t8/kAQIvJvKVMdeV6KhaxCyAjF+7EjFyjahynw2BdRKKnz8M3S49WW9o= X-Received: by 2002:a2e:1552:: with SMTP id 18-v6mr4027176ljv.68.1545489784213; Sat, 22 Dec 2018 06:43:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Sat, 22 Dec 2018 06:42:27 -0800 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000979ff4057d9d6101" Archived-At: Subject: [OAUTH-WG] Fwd: AD Review of draft-ietf-oauth-jwt-bcp 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, 22 Dec 2018 14:43:12 -0000 --000000000000979ff4057d9d6101 Content-Type: text/plain; charset="UTF-8" CCing the WG because I was wrong about the aliases. ---------- Forwarded message --------- From: Eric Rescorla Date: Sun, Aug 26, 2018 at 2:02 PM Subject: AD Review of draft-ietf-oauth-jwt-bcp To: oauth Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4649 COMMENTS S 1.2. > 1.2. Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > [RFC2119]. You will want to cite 8174 here. S 2.6. > > 2.6. Substitution Attacks > > There are attacks in which one recipient will have a JWT intended for > it and attempt to use it at a different recipient that it was not > intended for. If not caught, these attacks can result in the I don't understand this attack. Can you go into more detail? S 3.2. > Therefore, applications MUST only allow the use of cryptographically > current algorithms that meet the security requirements of the > application. This set will vary over time as new algorithms are > introduced and existing algorithms are deprecated due to discovered > cryptographic weaknesses. Applications must therefore be designed to > enable cryptographic agility. Is this must normative? S 3.2. > may be no need to apply another layer of cryptographic protections to > the JWT. In such cases, the use of the "none" algorithm can be > perfectly acceptable. JWTs using "none" are often used in > application contexts in which the content is optionally signed; then > the URL-safe claims representation and processing can be the same in > both the signed and unsigned cases. I think you probably need to have a clearer "don't use none by default" statement here. S 3.4. > ECDH-ES ephemeral public key (epk) inputs should be validated > according to the recipient's chosen elliptic curve. For the NIST > prime-order curves P-256, P-384 and P-521, validation MUST be > performed according to Section 5.6.2.3.4 "ECC Partial Public-Key > Validation Routine" of NIST Special Publication 800-56A revision 3 > [nist-sp-800-56a-r3]. Is there an X25519 specification for JWE? If so, you should probably specify the appropriate checks. S 3.5. > 3.5. Ensure Cryptographic Keys have Sufficient Entropy > > The Key Entropy and Random Values advice in Section 10.1 of [RFC7515] > and the Password Considerations in Section 8.8 of [RFC7518] MUST be > followed. In particular, human-memorizable passwords MUST NOT be > directly used as the key to a keyed-MAC algorithm such as "HS256". If you can't use them "directly" than how should you use them? Do you want to say anything about password hashing (argon, etc.)? S 3.12. > of JWTs. > > Given the broad diversity of JWT usage and applications, the best > combination of types, required claims, values, header parameters, key > usages, and issuers to differentiate among different kinds of JWTs > will, in general, be application specific. I get that this is the state we find ourselves in, but it seems like it's unfortunate. This might be a good time to re-emphasize the recommendation for explicit types in 3.11. --000000000000979ff4057d9d6101 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
CCing the WG because I was wrong about the aliases.
---------- Forwarded message -= --------
From: Eric Rescorla<= /b> <ekr@rtfm.com&= gt;
Date: Sun, Aug 26, 2018 at 2:02 PM
Subject: AD Review of d= raft-ietf-oauth-jwt-bcp
To: oauth <= oauth@ietf.org>


Rich version of th= is review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4649
=

COMMENTS
S 1.2.
>=C2=A0=C2=A0 1.2.=C2=A0 Conventions used = in this document
>=C2=A0=C2=A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= The key words "MUST", "MUST NOT", "REQUIRED"= , "SHALL", "SHALL NOT",
>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "SHOULD", "SHOULD NOT", "RECOMMENDED",= "NOT RECOMMENDED", "MAY", and
>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "OPTIONAL" in this document are to be interpreted= as described in
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [RFC2119].

Yo= u will want to cite 8174 here.


S 2.6.
>=C2=A0=C2=A0
&g= t;=C2=A0=C2=A0 2.6.=C2=A0 Substitution Attacks
>=C2=A0=C2=A0
>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There are attacks in which one recipient wil= l have a JWT intended for
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it and atte= mpt to use it at a different recipient that it was not
>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 intended for.=C2=A0 If not caught, these attacks can res= ult in the

I don't understand this attack. Can you go into more = detail?


S 3.2.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Therefore, = applications MUST only allow the use of cryptographically
>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 current algorithms that meet the security requirement= s of the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 application.=C2=A0 This set = will vary over time as new algorithms are
>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 introduced and existing algorithms are deprecated due to discovered<= br>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cryptographic weaknesses.=C2=A0 Appli= cations must therefore be designed to
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= enable cryptographic agility.

Is this must normative?


S = 3.2.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 may be no need to apply another = layer of cryptographic protections to
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= the JWT.=C2=A0 In such cases, the use of the "none" algorithm ca= n be
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 perfectly acceptable.=C2=A0 JWTs= using "none" are often used in
>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 application contexts in which the content is optionally signed; then=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the URL-safe claims representation a= nd processing can be the same in
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 both= the signed and unsigned cases.

I think you probably need to have a = clearer "don't use none by
default" statement here.

S 3.4.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ECDH-ES ephemeral public = key (epk) inputs should be validated
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = according to the recipient's chosen elliptic curve.=C2=A0 For the NIST<= br>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 prime-order curves P-256, P-384 and P= -521, validation MUST be
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 performed ac= cording to Section 5.6.2.3.4 "ECC Partial Public-Key
>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Validation Routine" of NIST Special Publication = 800-56A revision 3
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [nist-sp-800-56a-r= 3].

Is there an X25519 specification for JWE? If so, you should prob= ably
specify the appropriate checks.


S 3.5.
>=C2=A0=C2= =A0 3.5.=C2=A0 Ensure Cryptographic Keys have Sufficient Entropy
>=C2= =A0=C2=A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The Key Entropy and Random= Values advice in Section 10.1 of [RFC7515]
>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 and the Password Considerations in Section 8.8 of [RFC7518] MUST be<= br>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 followed.=C2=A0 In particular, human-= memorizable passwords MUST NOT be
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dir= ectly used as the key to a keyed-MAC algorithm such as "HS256".
If you can't use them "directly" than how should you us= e them? Do you
want to say anything about password hashing (argon, etc.)= ?


S 3.12.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 of JWTs.
>=C2=A0=C2=A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Giv= en the broad diversity of JWT usage and applications, the best
>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 combination of types, required claims, values, = header parameters, key
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 usages, and is= suers to differentiate among different kinds of JWTs
>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 will, in general, be application specific.

I get tha= t this is the state we find ourselves in, but it seems like
it's unf= ortunate. This might be a good time to re-emphasize the
recommendation f= or explicit types in 3.11.

--000000000000979ff4057d9d6101-- From nobody Thu Dec 27 23:34:54 2018 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 638E1130FED for ; Thu, 27 Dec 2018 23:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 qEMXCp4NQJKZ for ; Thu, 27 Dec 2018 23:34:50 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 DA8FD130FE8 for ; Thu, 27 Dec 2018 23:34:49 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id h193so26284180ita.5 for ; Thu, 27 Dec 2018 23:34:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ApY3Cvokea3+LTHzLK9hQ5GOmn8nTKFBWNOCzNVRrOk=; b=TnQhe9m/GnjQ+UigW42nid78JhBq+RUWYufkjbQDGnmJW7bhYPKj7sZUcGksvVBDVZ miojPLwuYTVzou0rOLOJPQSvWdACEFGOB93s2DCk4y1jqe24WWMosHvySOdLZZ405SuA 0nFtyF3URJDzq/PR/L+vbqkwvC5qBKiiw+WDHGQ00d3BZmDhKsWiy2mYAGEfEdP/1DMR u/JxFZWe+C2TuTS+r1NEs8mwP8MbGG4y+5+yKySIW+xjB9KS3QQHpCbOLBnSLU7quwjT g61/Y0mP6J3vJyn6Md3lAqX2jVot3csCIG0eNfLigj0On6osRQ84d0TiJxIYkE8tU+YT qKlw== 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=ApY3Cvokea3+LTHzLK9hQ5GOmn8nTKFBWNOCzNVRrOk=; b=JawC30l5fEfO5PQgU/8+1VHvw4+qCd8+z9smz3gv7LYfe7JQQWaPIbbqniO7hSzNWt EEcBTzHHnYIPIiTWsLUp+hnNMHGucjHGWW887VShWUGWHyhUoB8gWf2TvId1X00wy9XF KKZMReZI03SP4qHkniqZxRD3YXFqmep3zBoTK4xUg1SzERDqprTICliu1hXmrmu360Uh LrxXlkBYtTIegyzh5U+O2fYocOoUSgQMkgwdbbRrixkzMyt/I2yd3rElhD1jpPpqRUxl SErUJFYizkBapjXqMfGVM0d0WbynkTEjI1PPS91btRvHI2POnTlrBaD91I5eYEPIFadl IYjA== X-Gm-Message-State: AA+aEWafLKweik+SiV+I9YR2aFZuTwBEA5ZYX16Z/8EQFRddSGe6tl23 llYPinV84dZfOLeKSYXXU5mbUu6+UOLWJI4UcKtVzQ== X-Google-Smtp-Source: AFSGD/WjIrw/kE3kW9N+CtiJnlw/4XrneGSzL9min94+3DxrkwSVReNH6zYIfINbySEvYO5DI6+5VSZ2TF6CXTIxSFc= X-Received: by 2002:a24:c584:: with SMTP id f126mr18711777itg.162.1545982488800; Thu, 27 Dec 2018 23:34:48 -0800 (PST) MIME-Version: 1.0 References: <153305269020.3071.5881779499900104302.idtracker@ietfa.amsl.com> <6EDF694B-553E-45FF-99A4-3034FA393372@cooperw.in> In-Reply-To: <6EDF694B-553E-45FF-99A4-3034FA393372@cooperw.in> From: William Denniss Date: Fri, 28 Dec 2018 17:34:37 +1000 Message-ID: To: Alissa Cooper Cc: IESG , draft-ietf-oauth-device-flow@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, oauth Content-Type: multipart/alternative; boundary="000000000000137bec057e101947" Archived-At: Subject: Re: [OAUTH-WG] Alissa Cooper's No Objection on draft-ietf-oauth-device-flow-11: (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, 28 Dec 2018 07:34:52 -0000 --000000000000137bec057e101947 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alissa, Version -13 contains both these improvements, thank you for your feedback! Detailed response inline below: Best, William On Fri, Aug 3, 2018 at 6:22 AM, Alissa Cooper wrote: > Hi William, > > On Aug 2, 2018, at 2:41 PM, William Denniss wrote: > > Alissa, > > Thank you for your review. Replies inline: > > On Tue, Jul 31, 2018 at 8:58 AM, Alissa Cooper wrote: > >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I support Mirja's DISCUSS point #3 which was also raised by the Gen-ART >> reviewer. The Gen-ART review also included a number of other useful >> comments. >> Please address them. >> > > We're working through the comments, some were addressed in -12, and the > work continues. > > >> >> Perhaps this is implicit, but I found it a little odd that there is no >> mention >> of whether the device codes and user codes are expected to be unique to >> individual devices. >> > > The are definitely expected to be unique. > > Section 3.2 currently states "the authorization server generates a device > verification code and an end-user code that are valid for a limited time" > > The assumption was that the "generated" codes would be unique. I will add > the word unique in future version (13), so it will read "generates a uniq= ue > device verification code=E2=80=A6=E2=80=9D > > > Great. > Section 3.2 of version 13 reads in part: the authorization server generates a *unique* device verification code and an end-user code that are valid for a limited time > > > > >> Section 3.3: >> >> "It is NOT RECOMMENDED for authorization servers to include the user >> code in the verification URI ("verification_uri"), as this increases >> the length and complexity of the URI that the user must type." >> >> I don't fully understand the justification for the normative requirement >> here. >> The user ultimately ends up typing in both strings, right? Is it so much >> more >> complex to type them both into a browser bar contiguously than to type >> the uri >> into the browser bar and the code into some form field on the page such >> that >> the normative requirement is warranted? >> > > Yes, the user will need to type both strings regardless. > > The main reason for the recommended separation is that the URI can't be > validated/corrected =E2=80=93 either they type it correctly and they get = to the > page, or they don't. But for the user-code, the page can display an error > if the user types it wrong. The belief is that it's a better user > experience that they get to the page, and then continue the input from > there rather than get browser errors if they typed the user-code part of > the URI wrong. > > > Got it. I think it would help to add this explanation to the document. > > Added an explanation to Section 3.3 in version 13: It is NOT RECOMMENDED for authorization servers to include the user code in the verification URI ("verification_uri"), as this increases the length and complexity of the URI that the user must type. *While the user must still type the same number of characters with the user_code separated, once they successfully navigate to the verification_uri, any errors in entering the code can be highlighted by the authorization server to improve the user experience.* The next section documents user interaction with "verification_uri_complete", which is designed to carry *both pieces of* information. > Thanks, > Alissa > > > This is also how every implementation I've seen has actually implemented > it. > > As written, if the authorization server were to include the code in the > URI, this would then raise the question of what should be in the user_cod= e > (e.g. would it be the empty string?) and how the device client should > render the instructions in that case. I think the spec is simpler if we > recommend one preferred approach based on the usability best-practices > derived from the implementation experience of earlier drafts. > > Section 3.3.1: >> >> Wouldn't there be textual instructions about how to use the QR code also >> included here? If the point is to illustrate the UI it seems like those >> should >> be included too. >> > > Good point! Figure 3 was updated to include QR scanning instructions. > > Best, > William > > > --000000000000137bec057e101947 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alissa,

Version -13 contains both th= ese improvements, thank you for your feedback!

Det= ailed response inline below:

Best,
Willi= am

On Fri, Aug= 3, 2018 at 6:22 AM, Alissa Cooper <alissa@cooperw.in> wrote= :
Hi William,

On Aug 2, 2018, at 2:41 PM, Willia= m Denniss <wden= niss@google.com> wrote:

Alissa,

= Thank you for your review. Replies inline:

On Tue, Jul 31, 2018 at 8:58 AM, Alissa Cooper <= alissa@cooperw.in> wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Mirja's DISCUSS point #3 which was also raised by the Gen-ART=
reviewer. The Gen-ART review also included a number of other useful comment= s.
Please address them.

We're working = through the comments, some were addressed in -12, and the work continues.
=C2=A0

Perhaps this is implicit, but I found it a little odd that there is no ment= ion
of whether the device codes and user codes are expected to be unique to
individual devices.

The are definitely = expected to be unique.

Section 3.2 currently state= s "the authorization server genera= tes a device verification=C2=A0c= ode and an end-user code that are valid for a limited time"

The assumption was that the "generate= d" codes would be unique. I will add the word unique in future version= (13), so it will read "generates a unique device verification code=E2= =80=A6=E2=80=9D






=C2=A0
Section 3.3:

"It is NOT RECOMMENDED for authorization servers to include the user =C2=A0 =C2=A0code in the verification URI ("verification_uri"), a= s this increases
=C2=A0 =C2=A0the length and complexity of the URI that the user must type.&= quot;

I don't fully understand the justification for the normative requiremen= t here.
The user ultimately ends up typing in both strings, right? Is it so much mo= re
complex to type them both into a browser bar contiguously than to type the = uri
into the browser bar and the code into some form field on the page such tha= t
the normative requirement is warranted?

Yes, the user will need to type both strings regardless.

The main reason for the recommended separation is that the URI can&= #39;t be validated/corrected =E2=80=93 either they type it correctly and th= ey get to the page, or they don't. But for the user-code, the page can = display an error if the user types it wrong. The belief is that it's a = better user experience that they get to the page, and then continue the inp= ut from there rather than get browser errors if they typed the user-code pa= rt of the URI wrong.


Added an explanation to Section 3.3 in version 13:

   It is NOT RECOMMENDED for authorization servers to include the us=
er
   code in the verification URI ("verification_uri"), as this inc=
reases
   the length and complexity of the URI that the user must type.  <=
font color=3D"green">While
   the user must still type the same number of characters with the
   user_code separated, once they successfully navigate to the
   verification_uri, any errors in entering the code can be highlighted
   by the authorization server to improve the user experience.  The next
   section documents user interaction with "verification_uri_complete&=
quot;,
   which is designed to carry both pieces of<=
/font> information.

=C2=A0
Thanks,
Alissa


<= /div>
This is also how every implementation I've seen has actually = implemented it.

As written, if the authorization s= erver were to include the code in the URI, this would then raise the questi= on of what should be in the user_code (e.g. would it be the empty string?) = and how the device client should render the instructions in that case. I th= ink the spec is simpler if we recommend one preferred approach based on the= usability best-practices derived from the implementation experience of ear= lier drafts.

Section 3.3.1:

Wouldn't there be textual instructions about how to use the QR code als= o
included here? If the point is to illustrate the UI it seems like those sho= uld
be included too.

Good point! Figure 3 w= as updated to include QR scanning instructions.

=
Best,
William



--000000000000137bec057e101947-- From nobody Thu Dec 27 23:44:45 2018 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 3DBCA130FF1 for ; Thu, 27 Dec 2018 23:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 2zpQqZNXPx2a for ; Thu, 27 Dec 2018 23:44:42 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 41B75130FEA for ; Thu, 27 Dec 2018 23:44:42 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id w18so27445516ite.1 for ; Thu, 27 Dec 2018 23:44:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SM1iQhojlo38R4HbfR3+0paTSxP0bBtzDbtw0CURCaM=; b=cyWHTVNrgCUOPBdAPU6YpqybePb1KJfi32pDba6S7kMsmCpU37D7CvtQ/fCXYwyXH0 ykSCJdazOukWe+CpfbqMt7KmOYQLHxGIgIcAzLDB3BQskw6Lmyz9AR2d/jzyAIlNm3F5 E/EHCqgnaQOXiQasrtJS/FNPzjTdxEBX/M6Y8A488ESSxEKD2/juoFpCfYRUCB5bqh5H ZUSExk00fdkkxkbufpr0laAYa++wsfdY/GWs9kGeWtZMMy0zPb+XfDJZTsXOLJzh/PI1 w6nEScM7RQpqUKYsH9eA/xo9ROf0FJenKW7gsIXfn/PewxIx/Fsz5oeDtmHhUX4ei/xp jj0g== 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=SM1iQhojlo38R4HbfR3+0paTSxP0bBtzDbtw0CURCaM=; b=XxmARnlkMmpuc0ydv9qL/+O6pkNaTrx+CRTCk7C8sGw1AbTtQPgLfJvFshAqUngriv cl64GgjYGj5KOFVGTruuAnPvyQ8QGyZGo801FrSqoY/7jOT/s+KpOYLYwHbJs9yVBb8M aARxnX2e2ftHNfjxrctKxCs6PgYOyqLcGnjFubyPw7S6SrNBvCKYjkZua0OgOfH+utJE X07pGtflHUS5eoLsYQmN6O8XiVJPYDLHTDHWRsrG+OVCOw4CRglkCgaU/VfpDVwZGTHV t2GjWeTFeGsn+9Ft+gdFYU0UdIlffw8MuaZgqDmHEWKZyzZs700bAqqWINM4qzOB+iws NOLw== X-Gm-Message-State: AA+aEWaMoJ2FP5uPdtgoLGROZveEhNruXJXX4sg9VWvVM4bQmlo0TLhZ CqhiQxkKEnYSfve/ePCxGkJ8QP1wKjlUMuDtI6B7yQ== X-Google-Smtp-Source: AFSGD/UhRik2uQEih/49SpHVUOgUjJnerKnvZyig38Uoc+IfEYhfb3VlZPiGerAJ4CFfdiPnkQUe/gK/UaLtitUe3DA= X-Received: by 2002:a24:8d45:: with SMTP id w66mr16025173itd.137.1545983081250; Thu, 27 Dec 2018 23:44:41 -0800 (PST) MIME-Version: 1.0 References: <153305269020.3071.5881779499900104302.idtracker@ietfa.amsl.com> <20180803233710.GZ68224@kduck.kaduk.org> In-Reply-To: <20180803233710.GZ68224@kduck.kaduk.org> From: William Denniss Date: Fri, 28 Dec 2018 17:44:29 +1000 Message-ID: To: Benjamin Kaduk Cc: William Denniss , Alissa Cooper , oauth , oauth-chairs@ietf.org, The IESG , draft-ietf-oauth-device-flow@ietf.org Content-Type: multipart/alternative; boundary="00000000000063889b057e103cb7" Archived-At: Subject: Re: [OAUTH-WG] Alissa Cooper's No Objection on draft-ietf-oauth-device-flow-11: (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, 28 Dec 2018 07:44:44 -0000 --00000000000063889b057e103cb7 Content-Type: text/plain; charset="UTF-8" Benjamin, On Fri, Aug 3, 2018 at 4:37 PM, Benjamin Kaduk wrote: > > > I am hardly a URI expert, so salt as appropriate, but if the user code was > in the query string, would the server still be able to generate a useful > error page if the user code was typed incorrectly? It might be possible for the server to catch certain types of errors, I agree, but not all possible errors. For example mis-entering path separator wouldn't be catchable on the server, such as for the user input: "device.example.comWDJB-MJHT" or "device.example.com;WDJB-MJHT" It's also more challenging to implement the error handling, as the URI could resolve to another valid URI, e.g. "device.example.com/abc" might be used for something else. Our opinion on usability is that it's better to break it down into two steps: get the URI correct, then type the code correctly. In the latter section, the AS can render helpful instructions, and perform JS validation during the input without needing a page reload. Another advantage of having the code separate is that when the QR code with verification_uri_complete is used, the code could be re-purposed as pairing code. E.g. after scanning the QR Code: (e.g. "is your device displaying WDJB-MJHT ?"). That would be harder to describe with a combined URI + code. This is something we explicitly recommend in Section 3.3.1 (third paragraph). One final point, earlier I said that the user would type the same number of characters regardless, but that was wrong: in the case of the URI, the user would need to type an additional character being the path or query separator. That extra character may not seem like much but it does impact usability (even with no errors), as they would need to navigate to the special characters section on the keyboard. I will tweak the text to reflect this. --00000000000063889b057e103cb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Benjamin,

On Fri, Aug 3, 2018 at 4:37 PM, Benjamin Kaduk <kaduk@mit.edu= > wrote:

I am hardly a URI expert, so salt as appropriate, but if the user co= de was
in the query string, would the server still be able to generate a useful error page if the user code was typed incorrectly?
=C2=A0<= /div>
It might be possible for the server to catch certain types of err= ors, I agree, but not all possible errors. For example mis-entering path se= parator wouldn't be catchable on the server, such as for the user input= :
"device.example.comWDJB-MJHT" or=C2=A0"device.example.com;WDJ= B-MJHT"

It's also more challenging= to implement the error handling, as the URI could resolve to another valid= URI, e.g. "device.example.com/abc" might be used for something else.
<= div>
Our opinion on usability is that it's better to brea= k it down into two steps: get the URI correct, then type the code correctly= . In the latter section, the AS can render helpful instructions, and perfor= m JS validation during the input without needing a page reload.
<= br>
Another advantage of having the code separate is that when th= e QR code with=C2=A0verification_uri_complete is used, the code could be = re-purposed as pairing code. E.g. after scanning the QR Code:=C2=A0(e.g. &q= uot;is your device displaying WDJB-MJHT ?"). That would be harder to d= escribe with a combined URI + code.=C2=A0 This is something we explicitly r= ecommend in Section 3.3.1 (third paragraph).

One final point, earlier I said that the user would type the same numbe= r of characters regardless, but that was wrong: in the case of the URI, the= user would need to type an additional character being the path or query se= parator. That extra character may not seem like much but it does impact usa= bility (even with no errors), as they would need to navigate to the special= characters section on the keyboard. I will tweak the text to reflect this.=



--00000000000063889b057e103cb7-- From nobody Fri Dec 28 09:24:37 2018 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 A4A9C13104F; Fri, 28 Dec 2018 09:24:35 -0800 (PST) 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.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <154601787561.21480.16867279894249777899@ietfa.amsl.com> Date: Fri, 28 Dec 2018 09:24:35 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-11.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, 28 Dec 2018 17:24:36 -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 Security Best Current Practice Authors : Torsten Lodderstedt John Bradley Andrey Labunets Daniel Fett Filename : draft-ietf-oauth-security-topics-11.txt Pages : 32 Date : 2018-12-28 Abstract: This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-11 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-11 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 Dec 28 09:30:37 2018 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 AED9B130E73 for ; Fri, 28 Dec 2018 09:30:35 -0800 (PST) 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_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 TgVSTK5bsgmz for ; Fri, 28 Dec 2018 09:30:33 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 919E4130E46 for ; Fri, 28 Dec 2018 09:30:33 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id x6so17194764ioa.9 for ; Fri, 28 Dec 2018 09:30:33 -0800 (PST) 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=qp1DBAN9/5L1d1gOLuAkFVOZMJGnov8FW8RFHfUsVIY=; b=OE+LXWdQxt7jPuHk5wHjvIhbaopoRBlH3p5/4bjh63ymnfB3o8NdJxUXcSVXvcB7L7 fs3sjjm6yCu4SIhknmdvknNDvhziypNjJgTKDVyPDdDIx+8PMRmFXlv9xSDCnhtcBl/x KmO82YTCRz6k0xBrexhVgY+D15gHBV+j9TwAQ= 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=qp1DBAN9/5L1d1gOLuAkFVOZMJGnov8FW8RFHfUsVIY=; b=AC7nRuyYjMZijW1jO7yPFqy+HfN+NgOsO5wKFXn979uk56NfMJdbEcYIqYuhg9lJgP TDWOc4Wja7seZcQGV+yVIVaUdAlxHSurQukfUb1C4kva5cfMW18tizxPpXArDGyNrCJn JvgQXEngMC69kU6NezL8rZd2hLvJ5D4W+CdrQPTZ4P0mTg1Upb23nuKVigTKcNOPls+s 4XzmhCiXJwFZ2Enx/R0zkyMKY4h5Q4yNElB4huqX5sNTLIaqRFb7zUZS8basODEIRZ8l QpNATMY71mf8LC1jXvgsy/EFZ7y4p0txO7QfCeowW0xs9Ooe5jONslJxSk/cYeH1Olp3 /XKQ== X-Gm-Message-State: AJcUukdn8n0jHngrOJ1I22eXA/VZTyRz4ExrjcPmVGrMrXezHiv3h7F+ IK9wDU6C2ME2BirKHHMkkOh6HUEyVguCPJ6ninLulARN9+K0KKtIXWKYn7JdeAkAQ2OcY7zbSsW QSNvc0cyGH37AzeaVD1Q= X-Google-Smtp-Source: ALg8bN7G3IMeOPcS2laK7oWyQfVfSK78/dOo88vbKh/GmABxP/trvYj0nMp0Ke/Yu+M9FwJgHUBB0bdECHg5n+OpjSA= X-Received: by 2002:a5d:8597:: with SMTP id f23mr20769295ioj.238.1546018232351; Fri, 28 Dec 2018 09:30:32 -0800 (PST) MIME-Version: 1.0 References: <20181227061955.16163.89598@celery-worker-111.ash1.bb-inf.net> In-Reply-To: <20181227061955.16163.89598@celery-worker-111.ash1.bb-inf.net> From: Brian Campbell Date: Fri, 28 Dec 2018 10:30:06 -0700 Message-ID: To: oauth , William Denniss Content-Type: multipart/alternative; boundary="0000000000008e5a91057e186bbf" Archived-At: Subject: [OAUTH-WG] Fwd: [Openid-specs-mobile-profile] Issue #145: 7.3 expires_in and interval should be required to be integers (openid/mobile) 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, 28 Dec 2018 17:30:36 -0000 --0000000000008e5a91057e186bbf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The below issue was raised in an OIDF WG about the so called CIBA draft, which has a number of significant similarities to the Device Flow, including the expires_in and interval response parameters noted in the issue. So *maybe* something to consider for the OAuth 2.0 Device Flow for Browserless and Input Constrained Devices. ---------- Forwarded message --------- From: Joseph Heenan Date: Wed, Dec 26, 2018 at 11:20 PM Subject: [Openid-specs-mobile-profile] Issue #145: 7.3 expires_in and interval should be required to be integers (openid/mobile) To: New issue 145: 7.3 expires_in and interval should be required to be integer= s https://bitbucket.org/openid/mobile/issues/145/73-expires_in-and-interval-s= hould-be Joseph Heenan: expires_in and interval in the authentication response are (I believe) intended to integers, but it's not actually stated anywhere I could find. We should probably be explicit that it's a positive integer, or alternatively we could use a more RFC6749 type definition: > A.14. "expires_in" Syntax > > The "expires_in" element is defined in Sections 4.2.2 and 5.1: > > expires-in =3D 1*DIGIT _______________________________________________ Openid-specs-mobile-profile mailing list Openid-specs-mobile-profile@lists.openid.net http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile --=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._ --0000000000008e5a91057e186bbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The bel= ow issue was raised in an OIDF WG about the so called CIBA draft, which has= a number of significant similarities to the Device Flow, including the exp= ires_in and interval response parameters noted in the issue. So *maybe* som= ething to consider for the OAuth 2.0 Device Flow for Browserless and Input = Constrained Devices.

---------- Forwarded message ---------
From: Joseph Heenan <issues-reply@bitbucket.org>
= Date: Wed, Dec 26, 2018 at 11:20 PM
Subject: [Openid-specs-mobile-profil= e] Issue #145: 7.3 expires_in and interval should be required to be integer= s (openid/mobile)
To: <openid-specs-mobile-profile@lists.openid.net>
=


New issue 145: 7.3 expires_in and interval should be required= to be integers
https://bitbucket= .org/openid/mobile/issues/145/73-expires_in-and-interval-should-be

Joseph Heenan:

expires_in and interval in the authentication response are (I believe) inte= nded to integers, but it's not actually stated anywhere I could find.
We should probably be explicit that it's a positive integer, or alterna= tively we could use a more RFC6749 type definition:

> A.14.=C2=A0 "expires_in" Syntax
>
>=C2=A0 =C2=A0The "expires_in" element is defined in Sections = 4.2.2 and 5.1:
>
>=C2=A0 =C2=A0 =C2=A0expires-in =3D 1*DIGIT


_______________________________________________
Openid-specs-mobile-profile mailing list
Openid-specs-mobile-profile@lists.openid.net
http://lists.openid.net/mailman/= listinfo/openid-specs-mobile-profile

<= 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. --0000000000008e5a91057e186bbf-- From nobody Fri Dec 28 09:50:33 2018 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 6BF08131058 for ; Fri, 28 Dec 2018 09:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 hEJoQWH2xadB for ; Fri, 28 Dec 2018 09:50:27 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 3B1DE131053 for ; Fri, 28 Dec 2018 09:50:27 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id r24so26308329wmh.0 for ; Fri, 28 Dec 2018 09:50:27 -0800 (PST) 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=69pfBM1/bc6pcIOFG/qlADF4dAPqCRvZIBvySGtA83k=; b=Oit9oLwPJWOgenXexs8jLRaBCV22/FWsWhX71lbU8l3S3r1YuDvrNzjpBCNCEIW3+P YzfYd2OQm/jP2xr0RAsxIfsbFZ2hgmQOsYBU1v8ib4NN+3VxOyrr12CSks+x7qPPo7Iz j+onvLSUAHscyx8i6zZFRVh3l0t1XZK2wkLfE= 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=69pfBM1/bc6pcIOFG/qlADF4dAPqCRvZIBvySGtA83k=; b=Y6jvDk6PrdwtTPOYj9d3ijp8nKLRtVhR6TMDoSn9th6D19C6E1VOKJBX167e4cKSb3 E06dbygjJM5n/12G1nUEvMCpdQCravJqGLCS/1UBPw/qTAjDOlHQnV2L8ukuAifQYrSK mre5+z/XDKGRo6nLxtmfH9XT8sF0U7ekFEMKDgHuMcOz89uWlCsLNlpwSW12yShK5qbw 1SyH5WV96NTJ1xxI8NAwahDvedShaJ2GAsK0vLmM8IGE7YH+VG1bBRV+5Ru5IDyu5Iyc XamdHD9+dBn8FLdh3kNMFOUhNCZO1xIECtFcuWvlAIkGxIJgkftusYxqZaRUOF1nHJ5W ytrA== X-Gm-Message-State: AA+aEWYJbkV8mATwR4XX2rTh+2FP1E5+3z3hPRo04/VgEIPiNtUPAGua lnulxhwjdIEHrIEbtxuiIgEOs2Pfb94= X-Google-Smtp-Source: ALg8bN4gzNPENszbS4DJds7wpFflossn2Q0/Td56ZNsDBZZlKNvbl2C5BrYdjVrLtGApad2mEAgOTg== X-Received: by 2002:a1c:b456:: with SMTP id d83mr25902418wmf.115.1546019425488; Fri, 28 Dec 2018 09:50:25 -0800 (PST) Received: from guest2s-mbp.lan (92.150.32.217.dyn.plus.net. [217.32.150.92]) by smtp.gmail.com with ESMTPSA id a18sm43101999wrp.13.2018.12.28.09.50.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Dec 2018 09:50:24 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Neil Madden In-Reply-To: Date: Fri, 28 Dec 2018 17:50:23 +0000 Cc: oauth Content-Transfer-Encoding: quoted-printable Message-Id: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> References: To: Brian Campbell X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint 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, 28 Dec 2018 17:50:32 -0000 On the assumption that this is likely to be a requirement from = customers, I=E2=80=99d be in favour of a new server metadata field. My = favourite bikeshed colour would be: tls_client_auth_token_endpoint On another metadata-related note, given that the additional security of = certificate-bound access tokens vanishes if the resource server = doesn=E2=80=99t understand and enforce the certificate-binding = associated with the access token, is there a general need for a client = to be able to discover if any given RS does actually support this? = Otherwise the whole scheme =E2=80=9Cfails open=E2=80=9D in that the = access token silently degrades to a normal bearer token. Or do we = consider it unlikely that an RS is going to accept a TLS client = certificate without supporting this? =E2=80=94 Neil > On 17 Dec 2018, at 20:26, Brian Campbell = wrote: >=20 > While there's been some disagreement about the specific wording etc., = there does seem to be general consensus coming out of this WG to, in one = form or another, recommend against the use of the implicit grant in = favor of authorization code. In order to follow that recommendation, = in-browser JavaScript clients will need to use XHR/fetch (and likely = CORS) to make requests directly to the token endpoint. >=20 > Meanwhile there is the MTLS document utilizes TLS client certificates = at the token endpoint for client authentication and/or certificate bound = access tokens. The security BCP draft even recommends sender/key = constrained access tokens and MTLS is close to the only viable way to do = that at this time.=20 >=20 > Unfortunately, however, these two things don't play very nice = together. When a browser makes a TLS connection where a client cert is = requested by the server in the handshake, even when client certificates = are optional and even when it's fetch/XHR, most/many/all browsers will = throw up some kind of certificate selection interface to the user. = Which is typically a very very bad user experience. =46rom a practical = standpoint, this means that a single deployment cannot really support = the MTLS draft and have in-browser JavaScript clients using = authorization code at the same time.=20 >=20 > In order to address the conflict here, I'd propose that the MTLS draft = introduce a new optional AS metadata parameter that is an MTLS enabled = token endpoint alias. Clients that are doing MTLS client authentication = and/or certificate bound access tokens would/should/must use the = alternative token endpoint when present in the AS's metadata. While all = other clients continue to use the standard token endpoint as they always = have. This would allow for an AS to deploy an alternative token endpoint = alias on a distinct host or port where it will request client certs in = the TLS handshake for OAuth clients that use it while keeping the = regular token endpoint as it normally is for other clients, especially = in-browser JavaScript clients.=20 >=20 > Thoughts, objections, agreements, etc., on this proposal? >=20 > PS Bikeshedding on a name for the metadata parameter is also welcome. = Some ideas to start: > token_endpoint_mtls_alias > token_endpoint_mtls > mtls_token_endpoint_alias > mtls_token_endpoint > alt_token_endpoint_mtls > mtls_token_endpoint_alt > = a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_sho= uld_use > equally_poor_idea_here >=20 >=20 >=20 >=20 >=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._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Dec 28 10:03:14 2018 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 74C44131063 for ; Fri, 28 Dec 2018 10:03:13 -0800 (PST) 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 y2nYgVYBqV5Z for ; Fri, 28 Dec 2018 10:03:10 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) (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 AFA8E130E7E for ; Fri, 28 Dec 2018 10:03:10 -0800 (PST) Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gcwTU-0003mr-Pi for oauth@ietf.org; Fri, 28 Dec 2018 19:03:08 +0100 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_2159782A-9FD2-4A54-97E1-669837A61D7D"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 28 Dec 2018 19:03:07 +0100 References: <154601787561.21480.16867279894249777899@ietfa.amsl.com> To: oauth In-Reply-To: <154601787561.21480.16867279894249777899@ietfa.amsl.com> Message-Id: <75EF29A8-B856-4F20-BAD1-4A89D5502F19@lodderstedt.net> X-Mailer: Apple Mail (2.3445.102.3) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-11.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, 28 Dec 2018 18:03:13 -0000 --Apple-Mail=_2159782A-9FD2-4A54-97E1-669837A61D7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, the new revision incorporates the outcome of the consensus call on = implicit grant (and the like). It also has more text on Refresh Token = expiration and implementation of Refresh Token replay detection via = Refresh Token rotation.=20 Thanks a lot for all the valuable feedback.=20 kind regards, Torsten,=20 > Am 28.12.2018 um 18:24 schrieb internet-drafts@ietf.org: >=20 >=20 > 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. >=20 > Title : OAuth 2.0 Security Best Current Practice > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Daniel Fett > Filename : draft-ietf-oauth-security-topics-11.txt > Pages : 32 > Date : 2018-12-28 >=20 > Abstract: > This document describes best current security practice for OAuth = 2.0. > It updates and extends the OAuth 2.0 Security Threat Model to > incorporate practical experiences gathered since OAuth 2.0 was > published and covers new threats relevant due to the broader > application of OAuth 2.0. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-11 > = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-11 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-11 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2159782A-9FD2-4A54-97E1-669837A61D7D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODEyMjgxODAzMDdaMC8GCSqGSIb3DQEJBDEiBCBU MeMfcgOLmFe2eYUoD0eUrXcQCspd7EQvpdhQ0AxKXzCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAvwKTW0uFEIsl6tO5rs4LNpnf mMQYSe09wVONfYLgTVy727/CNU2urQE3AlnzixS0wT06UjdKH2AKokZdeAL0bQfUqhXKJK3NAgmA XWbGjws99nfXXgP0qAT8YtLtDtkp50Gv7VnjHnYz4x5IObVvGdorzMA85acTHajcMZMEvLtUKnKH Feie9SVzbdGvA2nmSERY3PcONdRHaobt6p0NCiunrEULq8kCdphmMxjDoPPwxBDc+VUyUjA5dWMw dOHKoOOWjYJqRlPZZXe3nSqdMzbOydxSTaHIhgEvkIKrFO6uGm+inV4GQE/q3JEDVge8T6g5N5+r LHMnKqdpwkNAMwAAAAAAAA== --Apple-Mail=_2159782A-9FD2-4A54-97E1-669837A61D7D-- From nobody Fri Dec 28 14:55:52 2018 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 6D6A4130ED4 for ; Fri, 28 Dec 2018 14:55:49 -0800 (PST) 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_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 IDPlkrDo4Djo for ; Fri, 28 Dec 2018 14:55:46 -0800 (PST) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 DCC8F1311D8 for ; Fri, 28 Dec 2018 14:55:42 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id h65so28538163ith.3 for ; Fri, 28 Dec 2018 14:55:42 -0800 (PST) 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=tVSQBcXycz/r3XsWWDIX+CAHwZxLEovkns0gxyFB6Xg=; b=M/J2LfeOXbC4yaQExYwYsfLp5xLtNKxlPzr6248xtc2+elLH8iJ8a1WPe+KGLERCZg JSJ9MODod67PLZl5yOrFn2HwJSfzwjB8jVGcKXd+lo1NK6kIe6/6cMqWMrI8rRv/PH6M RszV/IJzrljYaNXDdsIULbyUeFsoSBiwT2rdw= 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=tVSQBcXycz/r3XsWWDIX+CAHwZxLEovkns0gxyFB6Xg=; b=sZSCd6glBe/Mf3P0VIy79uNCCrYDk8k63zkNvMw/w0aA+wm0Us6kzbkElTFiyadhkw GOiZf7fkz3ddhmmS/Gsj9g8fQa8fkEmiP5vfRnK/GU7BKFV8X6YkxxRv4WFGCSH8QSzU VQwXG+yUER4+0niZXEpQQF9L22BktgOhGLTS9Du7HZAncWGEJDVmlQV6lXqrnBxj71yY dqs1TcrLpV+bmWYJ8S0xxb86Ox/4MnqukTlnnYFYqI3jcLgBryCB2z2sxIQfb7Zj4DSq jSLrRigRWz0obUYfLts+9NV79VKOPF9gzHnnVUITVPX+gWV+qbdasTJL0e9n7F1+KsUA +dzg== X-Gm-Message-State: AJcUukds3LNgN3j+9QBpXPY+e7VFeS9PjuQT/5UtOrTdbqWSpt9qmRjO AJFb79dcayrpnqcp1mJg1qTbm4Uw7/AGfGq2JrFG+9PGxjXYJavXt9XtlOogLcfNcyY5XSQdlyU +brKZXUG4pxvmTQ== X-Google-Smtp-Source: ALg8bN5T3SCnljJWakzFX6N3QnNbL5U4QqvACUe2pvyxT0m/Pe48aa6fNUXAbyeDPyvnq+Im5HJvmOTWYc6SkpryLSI= X-Received: by 2002:a24:8ac7:: with SMTP id v190mr18791734itd.174.1546037741976; Fri, 28 Dec 2018 14:55:41 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> In-Reply-To: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> From: Brian Campbell Date: Fri, 28 Dec 2018 15:55:15 -0700 Message-ID: To: Neil Madden Cc: oauth Content-Type: multipart/alternative; boundary="0000000000006b972a057e1cf6af" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint 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, 28 Dec 2018 22:55:50 -0000 --0000000000006b972a057e1cf6af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I spent some time this holiday season futzing around with a few different browsers to see what kind of UI, if any, they present to the user when seeing different variations of the server requesting a client certificate during the handshake. In a non-exhaustive and unscientific look at the browsers I had easily at my disposal (FF, Chrome, and Safari on Mac OS), it seems they all behave basically the same. If the browser is configured with, or has access to, one or more client certificates that match the criteria of the CertificateRequest message from the server (basically if issued by one of the CAs in the certificate_authorities of the CertificateRequest), a certificate selection UI prompt will be presented to the user. Otherwise, a certificate selection UI prompt is not presented all. When the CertificateRequest message has an empty certificate_authorities list (likely the case with a optional_no_ca type config), the browsers look for client certificates with any issuer rather than narrowing it down. The observed behavior of the browsers surveyed seems logical and rather reasonable (and better than the last time I futzed with it). Importantly it means that for the situation described in the email that started this thread (a javascript client making a fetch/XHR request to an MTLS token endpoint), users using browsers that are not configured with, or have access to, any client keys/certs will not see any UI prompt at all. I suspect that not having client certs set up is the situation for the vast majority of users and their browsers. And for those that do have client certs set up, I think they are more likely to be the kind of user that is able to deal with the UI prompt okay. All of that is meant as an explanation of sorts to say that I think that things are actually okay enough as is and that I'd like to retract the proposal I'd previously made about the MTLS draft introducing a new AS metadata parameter. It is admittedly interesting (ironic?) that Neil sent a message in support of the proposal as I was writing this. It did give me pause but ultimately didn't change my opinion that it's not worth it to add this new AS metadata parameter. On Fri, Dec 28, 2018 at 10:50 AM Neil Madden wrote: > On the assumption that this is likely to be a requirement from customers, > I=E2=80=99d be in favour of a new server metadata field. My favourite bik= eshed > colour would be: > > tls_client_auth_token_endpoint > > On another metadata-related note, given that the additional security of > certificate-bound access tokens vanishes if the resource server doesn=E2= =80=99t > understand and enforce the certificate-binding associated with the access > token, is there a general need for a client to be able to discover if any > given RS does actually support this? Otherwise the whole scheme =E2=80=9C= fails > open=E2=80=9D in that the access token silently degrades to a normal bear= er token. > Or do we consider it unlikely that an RS is going to accept a TLS client > certificate without supporting this? > > =E2=80=94 Neil > > > On 17 Dec 2018, at 20:26, Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > > > > While there's been some disagreement about the specific wording etc., > there does seem to be general consensus coming out of this WG to, in one > form or another, recommend against the use of the implicit grant in favor > of authorization code. In order to follow that recommendation, in-browser > JavaScript clients will need to use XHR/fetch (and likely CORS) to make > requests directly to the token endpoint. > > > > Meanwhile there is the MTLS document utilizes TLS client certificates a= t > the token endpoint for client authentication and/or certificate bound > access tokens. The security BCP draft even recommends sender/key > constrained access tokens and MTLS is close to the only viable way to do > that at this time. > > > > Unfortunately, however, these two things don't play very nice together. > When a browser makes a TLS connection where a client cert is requested by > the server in the handshake, even when client certificates are optional a= nd > even when it's fetch/XHR, most/many/all browsers will throw up some kind = of > certificate selection interface to the user. Which is typically a very > very bad user experience. From a practical standpoint, this means that a > single deployment cannot really support the MTLS draft and have in-browse= r > JavaScript clients using authorization code at the same time. > > > > In order to address the conflict here, I'd propose that the MTLS draft > introduce a new optional AS metadata parameter that is an MTLS enabled > token endpoint alias. Clients that are doing MTLS client authentication > and/or certificate bound access tokens would/should/must use the > alternative token endpoint when present in the AS's metadata. While all > other clients continue to use the standard token endpoint as they always > have. This would allow for an AS to deploy an alternative token endpoint > alias on a distinct host or port where it will request client certs in th= e > TLS handshake for OAuth clients that use it while keeping the regular tok= en > endpoint as it normally is for other clients, especially in-browser > JavaScript clients. > > > > Thoughts, objections, agreements, etc., on this proposal? > > > > PS Bikeshedding on a name for the metadata parameter is also welcome. > Some ideas to start: > > token_endpoint_mtls_alias > > token_endpoint_mtls > > mtls_token_endpoint_alias > > mtls_token_endpoint > > alt_token_endpoint_mtls > > mtls_token_endpoint_alt > > > a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_sh= ould_use > > equally_poor_idea_here > > > > > > > > > > > > > > > > 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._ --0000000000006b972a057e1cf6af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I spent some time this holiday season futzing around with a few d= ifferent browsers to see what kind of UI, if any, they present to the user = when seeing different variations of the server requesting a client certific= ate during the handshake.

In a no= n-exhaustive and unscientific look at the browsers I had easily at my dispo= sal (FF, Chrome, and Safari on Mac OS), it seems they all behave basically = the same. If the browser is configured with, or has access to, one or more = client certificates that match the criteria of the CertificateRequest messa= ge from the server (basically if issued by one of the CAs in the certificat= e_authorities of the CertificateRequest), a certificate selection UI prompt= will be presented to the user. Otherwise, a certificate selection UI promp= t is not presented all. When the CertificateRequest message has an empty ce= rtificate_authorities list (likely the case with a optional_no_ca type conf= ig), the browsers look for client certificates with any issuer rather than = narrowing it down.

The observed behavior of = the browsers surveyed seems logical and rather reasonable (and better than = the last time I futzed with it). Importantly it means that for the situatio= n described in the email that started this thread (a javascript client maki= ng a fetch/XHR request to an MTLS token endpoint), users using browsers tha= t are not configured with, or have access to, any client keys/certs will no= t see any UI prompt at all. I suspect that not having client certs set up i= s the situation for the vast majority of users and their browsers. And for = those that do have client certs set up, I think they are more likely to be = the kind of user that is able to deal with the UI prompt okay.

All of that is meant as an explanation of sorts to say th= at I think that things are actually okay enough as is and that I'd like= to retract the proposal I'd previously made about the MTLS draft intro= ducing a new AS metadata parameter. It is admittedly interesting (ironic?) = that Neil sent a message in support of the proposal as I was writing this. = It did give me pause but ultimately didn't change my opinion that it= 9;s not worth it to add this new AS metadata parameter.



On Fri, Dec 28, 2018 at 10:50 AM Neil Madden <neil.madden@forgerock.com= > wrote:
= On the assumption that this is likely to be a requirement from customers, I= =E2=80=99d be in favour of a new server metadata field. My favourite bikesh= ed colour would be:

tls_client_auth_token_endpoint

On another metadata-related note, given that the additional security of cer= tificate-bound access tokens vanishes if the resource server doesn=E2=80=99= t understand and enforce the certificate-binding associated with the access= token, is there a general need for a client to be able to discover if any = given RS does actually support this? Otherwise the whole scheme =E2=80=9Cfa= ils open=E2=80=9D in that the access token silently degrades to a normal be= arer token. Or do we consider it unlikely that an RS is going to accept a T= LS client certificate without supporting this?

=E2=80=94 Neil

> On 17 Dec 2018, at 20:26, Brian Campbell <bcampbell=3D40pingidentity.co= m@dmarc.ietf.org> wrote:
>
> While there's been some disagreement about the specific wording et= c., there does seem to be general consensus coming out of this WG to, in on= e form or another, recommend against the use of the implicit grant in favor= of authorization code. In order to follow that recommendation, in-browser = JavaScript clients will need to use XHR/fetch (and likely CORS) to make req= uests directly to the token endpoint.
>
> Meanwhile there is the MTLS document utilizes TLS client certificates = at the token endpoint for client authentication and/or certificate bound ac= cess tokens. The security BCP draft even recommends sender/key constrained = access tokens and MTLS is close to the only viable way to do that at this t= ime.
>
> Unfortunately, however, these two things don't play very nice toge= ther. When a browser makes a TLS connection where a client cert is requeste= d by the server in the handshake, even when client certificates are optiona= l and even when it's fetch/XHR, most/many/all browsers will throw up so= me kind of certificate selection interface to the user.=C2=A0 Which is typi= cally a very very bad user experience. From a practical standpoint, this me= ans that a single deployment cannot really support the MTLS draft and have = in-browser JavaScript clients using authorization code at the same time. >
> In order to address the conflict here, I'd propose that the MTLS d= raft introduce a new optional AS metadata parameter that is an MTLS enabled= token endpoint alias. Clients that are doing MTLS client authentication an= d/or certificate bound access tokens would/should/must use the alternative = token endpoint when present in the AS's metadata. While all other clien= ts continue to use the standard token endpoint as they always have. This wo= uld allow for an AS to deploy an alternative token endpoint alias on a dist= inct host or port where it will request client certs in the TLS handshake f= or OAuth clients that use it while keeping the regular token endpoint as it= normally is for other clients, especially in-browser JavaScript clients. <= br> >
> Thoughts, objections, agreements, etc., on this proposal?
>
> PS Bikeshedding on a name for the metadata parameter is also welcome. = Some ideas to start:
> token_endpoint_mtls_alias
> token_endpoint_mtls
> mtls_token_endpoint_alias
> mtls_token_endpoint
> alt_token_endpoint_mtls
> mtls_token_endpoint_alt
> a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]= _should_use
> equally_poor_idea_here
>
>
>
>
>
>
>
> 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/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. --0000000000006b972a057e1cf6af-- From nobody Fri Dec 28 16:06:51 2018 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 7DD6712008A for ; Fri, 28 Dec 2018 16:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_SINGLE_WORD=2.5, 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=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 sqZ_L8Ze8Sf4 for ; Fri, 28 Dec 2018 16:06:48 -0800 (PST) Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) (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 4C3DD130E19 for ; Fri, 28 Dec 2018 16:06:48 -0800 (PST) Received: by mail-oi1-x244.google.com with SMTP id y23so18436288oia.4 for ; Fri, 28 Dec 2018 16:06:48 -0800 (PST) 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=5gilcOx/fa9RaOhUmZXl89lXcK7rapvVOOvUJMyUwWE=; b=jAhwWn44H5wmwJu1toGgX7qFlS/btv4D/nMm9DXbfq126cogQcuSh5aaWAeSwRP7T9 K/CpRsim6bNdZZGuLzlMhBDtRKl7M7ucip2Mq5m6ctPMuABUItbyFMLzT+Z1NMolKzNJ +Lw9Y6f5+UzC8UiHCMSyU9MWUlwG58cP4Jpgw1cE3ZwJ6cO7wGj+DT0oi8QIJjmlBlZb pl1b09VvMs+JYjl2a6hJJ7MDD7s6h1NoaAWnGjtzO2cLQQlpk0I90lfHu6mKVCueEgvg GLr8o8a9D2qSJRyBpf4ZbYcH7fmm2o1bJ9r0lXB+y3THaCqx8Jrj23x28EKX5PM6Mnum 74ew== 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=5gilcOx/fa9RaOhUmZXl89lXcK7rapvVOOvUJMyUwWE=; b=ge9uYM5TJnzy2Dn53fcHCbF/n+7XUf8MSzMSEf30MhwaYtwcuOHXJhEAopLstf1870 NakUhzW/ltH2UAV8dUPR8MdURN946mFnBMqgMJpd1v1PhMXUHh5Z3y53/mhEBZETnmK3 qbhq3qEFjydyzJGlX4rcMdhf/LFxpPQqdoJ3E6DXN0I0eczKN8wPqE34MWZdcHyz2ZGS PnXScue8QsJqoa+1DC239mrz0NDnGv1tGKteUa4XO/r3hTG3YTyz2C5ifk7a0dIahIpA T2oEScGQhWp1mAPOumXHmcEpS+8b82ufhtILc6JQAPwxm27YaDaztqYcD3ldldo7xqKa jFIg== X-Gm-Message-State: AA+aEWYufFkiw1WEtUUOz87bbqYN2ViafjFPHP0MRwRLzpskCnxypYWF CysPPj0QXzEh6zYieShTYRHRvOIsor2IMDwAbTUea4S80zY= X-Google-Smtp-Source: AFSGD/UNvfecZj0fgTxw6cluZBAdxTXcXAa8EYIlSkj6OUExX5bc84m18tkxtShFW35R2y/NY3OmpfWdgYHyM6l4j+w= X-Received: by 2002:aca:1702:: with SMTP id j2mr19540438oii.267.1546042007234; Fri, 28 Dec 2018 16:06:47 -0800 (PST) MIME-Version: 1.0 From: Chef Saroar Date: Sat, 29 Dec 2018 06:06:32 +0600 Message-ID: To: OAuth@ietf.org Content-Type: multipart/alternative; boundary="000000000000a62cbc057e1df4f5" 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: Sat, 29 Dec 2018 00:06:49 -0000 --000000000000a62cbc057e1df4f5 Content-Type: text/plain; charset="UTF-8" Hi --000000000000a62cbc057e1df4f5 Content-Type: text/html; charset="UTF-8"
Hi
--000000000000a62cbc057e1df4f5--