From nobody Thu May 1 00:15:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272DB1A0A1C for ; Thu, 1 May 2014 00:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 cLnaIeHhwwgd for ; Thu, 1 May 2014 00:15:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) by ietfa.amsl.com (Postfix) with ESMTP id 078C71A0A15 for ; Thu, 1 May 2014 00:15:48 -0700 (PDT) Received: from BY2PR03CA032.namprd03.prod.outlook.com (10.242.234.153) by BY2PR03MB192.namprd03.prod.outlook.com (10.242.36.144) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 1 May 2014 07:15:45 +0000 Received: from BY2FFO11FD022.protection.gbl (2a01:111:f400:7c0c::122) by BY2PR03CA032.outlook.office365.com (2a01:111:e400:2c2c::25) with Microsoft SMTP Server (TLS) id 15.0.934.12 via Frontend Transport; Thu, 1 May 2014 07:15:45 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD022.mail.protection.outlook.com (10.1.15.211) with Microsoft SMTP Server (TLS) id 15.0.929.8 via Frontend Transport; Thu, 1 May 2014 07:15:45 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.63]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0181.007; Thu, 1 May 2014 07:15:18 +0000 From: Mike Jones To: 'Hannes Tschofenig' , 'Brian Campbell' Thread-Topic: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 - Examples Thread-Index: AQHPYHPsqQW6K7XM2UikgyZnVh8GF5siTKYAgARrqoCAAEewAIAAHAEAgAASguCABCnZ8A== Date: Thu, 1 May 2014 07:15:17 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439A1A1570@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <535A3AF4.4060506@gmx.net> <535E127B.2010504@gmx.net> <535E661C.9080002@gmx.net> <4E1F6AAD24975D4BA5B16804296739439A19888B@TK5EX14MBXC288.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439A19888B@TK5EX14MBXC288.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(51694002)(53754006)(199002)(189002)(377454003)(479174003)(13464003)(51704005)(51914003)(24454002)(43784003)(74502001)(74662001)(55846006)(80976001)(15395725003)(76176999)(54356999)(97736001)(50986999)(31966008)(6806004)(76482001)(87936001)(2656002)(86612001)(33656001)(83322001)(46102001)(15975445006)(19580395003)(44976005)(4396001)(81342001)(19580405001)(99396002)(20776003)(79102001)(50466002)(84676001)(77982001)(2009001)(86362001)(575784001)(83072002)(81542001)(80022001)(23676002)(47776003)(85852003)(15202345003)(92566001)(66066001)(92726001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB192; H:mail.microsoft.com; FPR:EE6DF1E6.96FA5111.BFEF7597.5BFB6241.20807; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01986AE76B Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TiQWlpJeBo46bSoiC01QUOqRYtk Cc: "'oauth@ietf.org'" Subject: Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 - Examples X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 07:15:52 -0000 SGFubmVzLCB0aGUgZXhhbXBsZSBhdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTIwI3NlY3Rpb24tMy4xIChhbmQgdGhlIG90aGVyIGV4 YW1wbGVzKSBoYXZlIGJlZW4gY2xhcmlmaWVkIHRvIGFkZHJlc3MgdGhlIGNvbmNlcm5zIHlvdSBy YWlzZWQsIHBvaW50aW5nIG91dCB0aGF0IHRoZSBKU09OIG9iamVjdHMgcHJlc2VudGVkIGluIHRo ZSBkcmFmdHMgY2FuIGJlIGFtYmlndW91cyBhbmQgbWFraW5nIGl0IGNsZWFyIHRoYXQgdGhlIG9j dGV0cyBvZiB0aGUgVVRGLTggZW5jb2RpbmcgYWxzbyBzdXBwbGllZCBhcmUgYXV0aG9yaXRhdGl2 ZSBmb3IgdGhlc2UgZXhhbXBsZXMuDQoNClRoYW5rcyBhZ2FpbiBmb3IgdGhlIHVzZWZ1bCBmZWVk YmFjay4NCg0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IE1pa2UgSm9uZXMgDQpTZW50OiBNb25kYXksIEFwcmlsIDI4LCAyMDE0IDg6NDggQU0NClRvOiBI YW5uZXMgVHNjaG9mZW5pZzsgQnJpYW4gQ2FtcGJlbGwNCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3Vi amVjdDogUkU6IFtPQVVUSC1XR10gZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0xOSAt IEV4YW1wbGVzDQoNCkknbSBub3Qgb3Bwb3NlZCB0byBzYXlpbmcgbW9yZSBhYm91dCB0aGUgZmFj dCB0aGF0IGluIG9yZGVyIHRvIHZlcmlmeSB0aGUgZXhhbXBsZXMsIHBlb3BsZSBuZWVkIHRvIHVz ZSB0aGUgb2N0ZXQgc2VxdWVuY2UgcmVwcmVzZW50YXRpb24sIHJhdGhlciB0aGFuIHRoZSBBU0NJ SSByZXByZXNlbnRhdGlvbiwgc2luY2UgYXNwZWN0cyBvZiB0aGUgQVNDSUkgcmVuZGVyaW5nIHdp bGwgdmFyeSwgaW5jbHVkaW5nIHdoZXRoZXIgbGluZXMgYXJlIHRlcm1pbmF0ZWQgYnkgQ1JMRiBv ciBMRiBzZXF1ZW5jZXMgYW5kIGluIHRoZSBudW1iZXIgb2Ygc3BhY2VzIGF0IHRoZSBiZWdpbm5p bmcgYW5kIGVuZHMgb2YgbGluZXMuDQoNCkkgYWxyZWFkeSBoYXZlIHRvIHByb2R1Y2UgYW4gdXBk YXRlZCBkcmFmdCB0byBzd2FwIHdoZXRoZXIgdHdvIHJlZmVyZW5jZXMgYXJlIG5vcm1hdGl2ZSBv ciBpbmZvcm1hdGl2ZSwgc28gSSBjYW4gYWRkIHRoaXMgY2F2ZWF0IHRoaXMgYXQgdGhlIHNhbWUg dGltZS4NCg0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhhbm5l cyBUc2Nob2ZlbmlnDQpTZW50OiBNb25kYXksIEFwcmlsIDI4LCAyMDE0IDc6MzEgQU0NClRvOiBC cmlhbiBDYW1wYmVsbA0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdH XSBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTE5IC0gRXhhbXBsZXMNCg0KSXQgd291 bGQgYmUgbmljZSB0byBiZSBhYmxlIHRvIHZlcmlmeSB0aGUgZXhhbXBsZXMgaW4gdGhlIGRvY3Vt ZW50KHMpLiBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgQVNDSUkgZHJhZnQgZm9ybWF0IHByb3ZpZGVz IGEgbnVtYmVyIG9mIGxpbWl0YXRpb25zLg0KDQpJIHdvbmRlciB3aGF0IG90aGVycyB0aGluay4g SGF2ZSB5b3UgdHJpZWQgdG8gdmVyaWZ5IHRoZSBleGFtcGxlcz8gSGF2ZSB5b3UgZW5jb3VudGVy IHByb2JsZW1zIHlvdXJzZWxmIGFzIHdlbGw/DQoNCkNpYW8NCkhhbm5lcw0KDQpPbiAwNC8yOC8y MDE0IDAyOjUwIFBNLCBCcmlhbiBDYW1wYmVsbCB3cm90ZToNCj4gVG8gYmUgaG9uZXN0LCBJJ20g a2luZCBvZiBpbmRpZmZlcmVudCB0byBpdC4gWWVzLCB0aGUgaW5wdXQgaW50byB0aGUgDQo+IGV4 YW1wbGUgZW5jb2RpbmdzIGRvIGluY2x1ZGUgQ1IrTEYgKHRoZSBlZGl0b3IgaXMgYSBNaWNyb3Nv ZnQgZ3V5IA0KPiBhZnRlcg0KPiBhbGwpIGJ1dCB0aGV5IGFsc28gaGF2ZSBzcGFjZSBjaGFyYWN0 ZXJzIHRoYXQgYXJlIHJlbW92ZWQgZnJvbSB0aGUgDQo+IGJlZ2lubmluZyBvZiBlYWNoIGxpbmUs IHdoaWNoIGlzbid0IGV4YWN0bHkgb2J2aW91cy4gRGVzY3JpYmluZyB0aGF0IA0KPiBpbiBhIHdh eSB0aGF0IGV2ZXJ5b25lIHdpbGwgZmluZCBlYXN5IHRvIHVuZGVyc3RhbmQgYW5kIHVzZSBzZWVt cyBsaWtlIA0KPiBhIGRpZmZpY3VsdCBlbmRlYXZvci4gVGhlIG9jdGV0IHNlcXVlbmNlIGlzIHRo ZXJlIHRvIHVuYW1iaWd1b3VzbHkgDQo+IHNob3cgd2hhdCB0aGUgaW5wdXQgaW50byB0aGUgZW5j b2Rpbmcgd2FzLiBBbmQgb25lIGNhbiBhbHNvIGFsd2F5cyANCj4gZGVjb2RlIHRoZSBiYXNlNjR1 cmwgY29udGVudCB0b28sIHRvIHNlZSBleGFjdGx5IHdoYXQgdGhlIGlucHV0IHdhcy4NCj4gDQo+ IFNvLCB5ZWFoLCBJIGRvbid0IGtub3cuIEknbSBub3QgYWdhaW5zdCBtZW50aW9uaW5nIHRoZSBc clxuIGJ1dCBJIA0KPiBkb24ndCBwZXJzb25hbGx5IHRoaW5rIGl0IGhlbHBzIG11Y2guDQo+IA0K PiANCj4gDQo+IA0KPiBPbiBNb24sIEFwciAyOCwgMjAxNCBhdCAyOjM0IEFNLCBIYW5uZXMgVHNj aG9mZW5pZyANCj4gPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQgPG1haWx0bzpoYW5uZXMudHNj aG9mZW5pZ0BnbXgubmV0Pj4gd3JvdGU6DQo+IA0KPiAgICAgSGkgQnJpYW4sDQo+IA0KPiAgICAg dGhhbmtzIGZvciB0aGUgcG9pbnRlcnMuDQo+IA0KPiAgICAgSXQgaXMgZWFzeSB0byBzZWUgZnJv bSB5b3VyIGNvZGUgd2hlcmUgdGhlIGlzc3VlIGlzLiBJbiB5b3VyIGNvZGUgdGhlDQo+ICAgICBc clxuIHNlcXVlbmNlIGlzIGFkZGVkIGF0IHRoZSBlbmQgb2YgZWFjaCBsaW5lIGJ1dCBkdWUgdG8g dGhlIG5hdHVyZSBvZg0KPiAgICAgdGhlIEFTQ0lJIGRyYWZ0IGZvcm1hdHRpbmcgYSByZWFkZXIg b25seSBzZWVzIHRoZSBcbiAobmV3IGxpbmUpIGJ1dCBub3QNCj4gICAgIHRoZSBcciBjYXJyaWFn ZSByZXR1cm4uDQo+IA0KPiAgICAgV2hpbGUgdGhlIGRyYWZ0IHByb3ZpZGVzIHRoZSBVVEYtOCBy ZXByZXNlbnRhdGlvbiBvZiBlYWNoIGluZGl2aWR1YWwNCj4gICAgIGNoYXJhY3RlciBidXQsIGFz IEkgbWVudGlvbmVkIGluIG15IGVtYWlsIGJlbG93LCBub25lIG9mIHRoZSB0b29scyBJDQo+ICAg ICBmb3VuZCBwcm9kdWNlIGEgY29udmVuaWVudCB3YXkgdG8gdXNlIHRoaXMgYXMgaW5wdXQgZm9y IHRoZSBiYXNlNjR1cmwNCj4gICAgIGVuY29kaW5nIHByb2NlZHVyZS4NCj4gDQo+ICAgICBJIGJl bGlldmUgaXQgd291bGQgYmUgZ29vZCB0byBtZW50aW9uIHRoYXQgZWFjaCBsaW5lIGluIHRoZSBl eGFtcGxlcyBpcw0KPiAgICAgZm9sbG93ZWQgYnkgdGhlIFxyXG4gY2hhcmFjdGVyIHNlcXVlbmNl IHRvIG1ha2UgaXQgZWFzaWVyIGZvciB0aG9zZSB3aG8NCj4gICAgIHdhbnQgdG8gcmUtY3JlYXRl IHRoZSBleGFtcGxlcy4NCj4gDQo+ICAgICBXaGF0IGRvIHlvdSB0aGluaz8NCj4gDQo+ICAgICBD aWFvDQo+ICAgICBIYW5uZXMNCj4gDQo+IA0KPiAgICAgT24gMDQvMjUvMjAxNCAwMzowMyBQTSwg QnJpYW4gQ2FtcGJlbGwgd3JvdGU6DQo+ICAgICA+IFNvIEpXVCAzLjEgaXMgYmFzZWQgZW50aXJl bHkgb24sIGFuZCBpcyBqdXN0IGEgc3Vic2V0IG9mLCBKV1MgQXBwZW5kaXgNCj4gICAgID4gQS4x LiBBbmQgSSd2ZSBnb3QgYSB0ZXN0IHdoaWNoIHZhbGlkYXRlcyB0aGF0IGV4YW1wbGUgaW4gbXkg Sk9TRQ0KPiAgICAgbGlicmFyeQ0KPiAgICAgPiA8aHR0cHM6Ly9iaXRidWNrZXQub3JnL2JfYy9q b3NlNGo+Og0KPiAgICAgPg0KPiAgICAgaHR0cHM6Ly9iaXRidWNrZXQub3JnL2JfYy9qb3NlNGov c3JjL21hc3Rlci9zcmMvdGVzdC9qYXZhL29yZy9qb3NlNGovandzL0p3c1VzaW5nSG1hY1NoYTI1 NkV4YW1wbGVUZXN0LmphdmENCj4gICAgID4NCj4gICAgID4gQW5kIGhlcmUncyBhIHZlcmlmaWNh dGlvbiBvZiB0aGUgRXhhbXBsZSBFbmNyeXB0ZWQgSldUIGZyb20gQXBwZW5kaXgNCj4gICAgID4g QS4xOg0KPiAgICAgPg0KPiAgICAgaHR0cHM6Ly9iaXRidWNrZXQub3JnL2JfYy9qb3NlNGovc3Jj L21hc3Rlci9zcmMvdGVzdC9qYXZhL29yZy9qb3NlNGovandlL0VuY3J5cHRlZEp3dFRlc3QuamF2 YQ0KPiAgICAgPg0KPiAgICAgPiBUaGUgZXhhbXBsZSBpbiBTZWN0aW9uIDYuMSBpcyBkaWZmZXJl bnQgdGhhbiAzLjEgLSBpdCdzIGEgIlBsYWludGV4dA0KPiAgICAgPiBKV1QiIHVzaW5nIHRoZSAi bm9uZSIgSldTIGFsZy4gSSd2ZSBnb3QgdmVyaWZpY2F0aW9uIG9mIHRoYXQgb25lDQo+ICAgICBh cyB3ZWxsDQo+ICAgICA+IGF0IHRoZSB0b3Agb2YNCj4gICAgID4NCj4gICAgIGh0dHBzOi8vYml0 YnVja2V0Lm9yZy9iX2Mvam9zZTRqL3NyYy9tYXN0ZXIvc3JjL3Rlc3QvamF2YS9vcmcvam9zZTRq L2p3cy9Kd3NQbGFpbnRleHRUZXN0LmphdmENCj4gICAgID4NCj4gICAgID4NCj4gICAgID4gT24g RnJpLCBBcHIgMjUsIDIwMTQgYXQgNDozNyBBTSwgSGFubmVzIFRzY2hvZmVuaWcNCj4gICAgID4g PGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQgPG1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgu bmV0Pg0KPiAgICAgPG1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0DQo+ICAgICA8bWFp bHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+Pj4gd3JvdGU6DQo+ICAgICA+DQo+ICAgICA+ ICAgICBIaSBhbGwsDQo+ICAgICA+DQo+ICAgICA+ICAgICBBcyBhIGRvY3VtZW50IHNoZXBoZXJk IEkgaGF2ZSB0byB2ZXJpZnkgdGhlIGVudGlyZSBkb2N1bWVudA0KPiAgICAgYW5kIHRoaXMNCj4g ICAgID4gICAgIGluY2x1ZGVzIHRoZSBleGFtcGxlcyBhcyB3ZWxsLg0KPiAgICAgPg0KPiAgICAg PiAgICAgU2VjdGlvbiAzLjE6DQo+ICAgICA+DQo+ICAgICA+ICAgICBZb3Ugd3JpdGU6DQo+ICAg ICA+DQo+ICAgICA+ICAgICAiDQo+ICAgICA+ICAgICAgICBUaGUgZm9sbG93aW5nIG9jdGV0IHNl cXVlbmNlIGlzIHRoZSBVVEYtOCByZXByZXNlbnRhdGlvbiBvZg0KPiAgICAgdGhlIEpXVA0KPiAg ICAgPiAgICAgICAgSGVhZGVyL0pXUyBIZWFkZXIgYWJvdmU6DQo+ICAgICA+DQo+ICAgICA+ICAg ICAgICBbMTIzLCAzNCwgMTE2LCAxMjEsIDExMiwgMzQsIDU4LCAzNCwgNzQsIDg3LCA4NCwgMzQs IDQ0LA0KPiAgICAgMTMsIDEwLCAzMiwNCj4gICAgID4gICAgICAgIDM0LCA5NywgMTA4LCAxMDMs IDM0LCA1OCwgMzQsIDcyLCA4MywgNTAsIDUzLCA1NCwgMzQsIDEyNV0NCj4gICAgID4gICAgICIN Cj4gICAgID4NCj4gICAgID4gICAgIFRoZSB2YWx1ZXMgSU1ITyBhcmUgcmVwcmVzZW50ZWQgaW4g RGVjaW1hbCBjb2RlIHBvaW50IHJhdGhlcg0KPiAgICAgdGhhbiBPY3RhbA0KPiAgICAgPiAgICAg VVRGLTggYnl0ZXMsIGFzIHN0YXRlZCBhYm92ZS4NCj4gICAgID4gICAgIFNlZSB0aGUgZm9sbG93 aW5nIG9ubGluZSB0b29sIHRvIHNlZSB0aGUgZGlmZmVyZW5jZToNCj4gICAgID4gICAgIGh0dHA6 Ly93d3cubHRnLmVkLmFjLnVrL35yaWNoYXJkL3V0Zi04LmNnaT9pbnB1dD0lMjImbW9kZT1jaGFy DQo+ICAgICA+DQo+ICAgICA+ICAgICBOb3RlIHRoYXQgeW91IGNvdWxkIGFsc28gc2hvdyBhIGhl eCBlbmNvZGluZyBpbnN0ZWFkIChlLmcuLCB2aWENCj4gICAgID4gICAgIGh0dHA6Ly9vc3Rlcm1p bGxlci5vcmcvY2FsYy9lbmNvZGUuaHRtbCkuIEhpeGllJ3MgZGVjb2Rlcg0KPiAgICAgd291bGQg dGhlbg0KPiAgICAgPiAgICAgcHJvZHVjZSB0aGUgY29ycmVjdCBkZWNvZGluZy4gSGVyZSBpcyB0 aGUgbGluayB0byBoaXMgc29mdHdhcmU6DQo+ICAgICA+ICAgIA0KPiAgICAgaHR0cDovL3NvZnR3 YXJlLmhpeGllLmNoL3V0aWxpdGllcy9jZ2kvdW5pY29kZS1kZWNvZGVyL3V0ZjgtZGVjb2Rlcg0K PiAgICAgPiAgICAgKE5vdGUgdGhhdCB0aGlzIHByb2dyYW0gc2VlbXMgdG8gaGF2ZSBmbGF3cyBm b3IgbW9zdCBvdGhlcg0KPiAgICAgb3B0aW9ucy4pDQo+ICAgICA+DQo+ICAgICA+ICAgICBXaGVu IGRvIGEgQmFzZTY0VVJMIGVuY29kaW5nIG9mDQo+ICAgICA+DQo+ICAgICA+ICAgICB7InR5cCI6 IkpXVCIsImFsZyI6IkhTMjU2In0NCj4gICAgID4NCj4gICAgID4gICAgIHRoZW4gSSBnZXQNCj4g ICAgID4NCj4gICAgID4gICAgIGV5SjBlWEFpT2lKS1YxUWlMQ0poYkdjaU9pSklVekkxTmlKOQ0K PiAgICAgPg0KPiAgICAgPiAgICAgYnV0IHlvdXIgc3BlYyBzYXlzOg0KPiAgICAgPg0KPiAgICAg PiAgICAgZXlKMGVYQWlPaUpLVjFRaUxBMEtJQ0poYkdjaU9pSklVekkxTmlKOQ0KPiAgICAgPg0K PiAgICAgPiAgICAgU2FtZSB3aXRoDQo+ICAgICA+ICAgICB7ImlzcyI6ImpvZSIsImV4cCI6MTMw MDgxOTM4MCwiaHR0cDovL2V4YW1wbGUuY29tL2lzX3Jvb3QiOnRydWV9Lg0KPiAgICAgPg0KPiAg ICAgPiAgICAgTXkgcmVzdWx0Og0KPiAgICAgPiAgICANCj4gICAgIGV5SnBjM01pT2lKcWIyVWlM Q0psZUhBaU9qRXpNREE0TVRrek9EQXNJbWgwZEhBNkx5OWxlR0Z0Y0d4bExtTnZiUzlwYzE5eWIy OTBJanAwY25WbGZRDQo+ICAgICA+DQo+ICAgICA+ICAgICBZb3VyIHJlc3VsdDoNCj4gICAgID4g ICAgDQo+ICAgICBleUpwYzNNaU9pSnFiMlVpTEEwS0lDSmxlSEFpT2pFek1EQTRNVGt6T0RBc0RR b2dJbWgwZEhBNkx5OWxlR0Z0Y0d4bExtTnZiUzlwYzE5eWIyOTBJanAwY25WbGZRDQo+ICAgICA+ DQo+ICAgICA+ICAgICBOb3RlOiBJIGFtIHVzaW5nIHRoaXMgb25saW5lIHRvb2wgZm9yIEJhc2U2 NFVSTCBlbmNvZGluZzoNCj4gICAgID4gICAgIGh0dHA6Ly9ranVyLmdpdGh1Yi5pby9qc2p3cy90 b29sX2I2NHVlbmMuaHRtbC4NCj4gICAgID4gICAgIEludGVyZXN0aW5nbHksIHdoZW4gSSBkdW1w IHRoZSBkYXRhIGludG8gaHR0cDovL2p3dC5pby8gdGhlbiBJDQo+ICAgICBnZXQgYQ0KPiAgICAg PiAgICAgY29ycmVjdCBkZWNvZGluZy4gSXQgbWlnaHQgd2VsbCBiZSB0aGF0IHRoZSBranVyLmdp dGh1Yi5pbw0KPiAgICAgPGh0dHA6Ly9ranVyLmdpdGh1Yi5pbz4NCj4gICAgID4gICAgIDxodHRw Oi8va2p1ci5naXRodWIuaW8+IGhhcyBhIGZsYXcuDQo+ICAgICA+DQo+ICAgICA+ICAgICBKdXN0 IHdhbnRlZCB0byBjaGVjayB3aGF0IHRvb2wgeW91IGhhdmUgdXNlZCB0byBjcmVhdGUgdGhlc2UN Cj4gICAgIGVuY29kaW5ncy4NCj4gICAgID4NCj4gICAgID4NCj4gICAgID4gICAgIFNlY3Rpb24g Ni4xOg0KPiAgICAgPg0KPiAgICAgPiAgICAgVGhlIGV4YW1wbGUgaW4gU2VjdGlvbiA2LjEgaXMg dGhlIHNhbWUgYXMgaW4gMy4xLiBNYXliZSBpdA0KPiAgICAgd291bGQgYmUNCj4gICAgID4gICAg IHVzZWZ1bCB0byBzaG93IHNvbWV0aGluZyBkaWZmZXJlbnQgaGVyZS4NCj4gICAgID4NCj4gICAg ID4gICAgIFRoZSBleGFtcGxlIGluIEFwcGVuZGl4IEEuMSBpcyBtb3JlIHNvcGhpc3RpY2F0ZWQg c2luY2UgaXQNCj4gICAgIGRlbW9uc3RyYXRlcw0KPiAgICAgPiAgICAgZW5jcnlwdGlvbi4gVG8g dmVyaWZ5IGl0IEkgd291bGQgbmVlZCB0byBoYXZlIGEgbGlicmFyeSB0aGF0DQo+ICAgICBzdXBw b3J0cw0KPiAgICAgPiAgICAgSldFIGFuZCBSU0FFUy1QS0NTMS1WMV81IGFuZCBBRVNfMTI4X0NC Q19ITUFDX1NIQV8yNTYuIFdoaWNoDQo+ICAgICBsaWJyYXJ5DQo+ICAgICA+ICAgICBoYXZlIHlv dSBiZWVuIHVzaW5nPw0KPiAgICAgPg0KPiAgICAgPiAgICAgSSB3YXMgd29uZGVyaW5nIHdoZXRo ZXIgaXQgd291bGQgbWFrZSBzZW5zZSB0byBhZGQgdHdvIG90aGVyDQo+ICAgICBleGFtcGxlcywN Cj4gICAgID4gICAgIG5hbWVseSBmb3IgaW50ZWdyaXR5IHByb3RlY3Rpb24uIE9uZSBleGFtcGxl IHNob3dpbmcgYW4NCj4gICAgIEhNQUMtYmFzZWQga2V5ZWQNCj4gICAgID4gICAgIG1lc3NhZ2Ug ZGlnZXN0IGFuZCBhbm90aGVyIG9uZSB1c2luZyBhIGRpZ2l0YWwgc2lnbmF0dXJlLg0KPiAgICAg Pg0KPiAgICAgPiAgICAgSGVyZSBpcyBhIHNpbXBsZSBleGFtcGxlIHRvIGFkZCB0aGF0IGFsbW9z dCBhbGwgSldUIGxpYnJhcmllcw0KPiAgICAgc2VlbSB0byBiZQ0KPiAgICAgPiAgICAgYWJsZSB0 byBjcmVhdGUgYW5kIHZlcmlmeToNCj4gICAgID4NCj4gICAgID4gICAgIEhlYWRlcjoNCj4gICAg ID4gICAgIHsiYWxnIjoiSFMyNTYiLCJ0eXAiOiJKV1QifQ0KPiAgICAgPg0KPiAgICAgPiAgICAg SSB1c2UgdGhlIEhTMjU2IGFsZ29yaXRobSB3aXRoIGEgc2hhcmVkIHNlY3JldCAnMTIzNDUnLg0K PiAgICAgPg0KPiAgICAgPiAgICAgQm9keToNCj4gICAgID4NCj4gICAgID4gICAgIHsiaXNzIjoi aHR0cHM6Ly9hcy5leGFtcGxlLmNvbSIsInN1YiI6Im1haWx0bzpqb2huQGV4YW1wbGUuY29tDQo+ ICAgICA8bWFpbHRvOmpvaG5AZXhhbXBsZS5jb20+DQo+ICAgICA+ICAgICA8bWFpbHRvOmpvaG5A ZXhhbXBsZS5jb20NCj4gICAgIDxtYWlsdG86am9obkBleGFtcGxlLmNvbT4+IiwibmJmIjoxMzk4 NDIwNzUzLCJleHAiOjEzOTg0MjQzNTMsImlhdCI6MTM5ODQyMDc1M30NCj4gICAgID4NCj4gICAg ID4gICAgDQo+ICAgICBqd3QuZW5jb2RlKHsiaXNzIjoiaHR0cHM6Ly9hcy5leGFtcGxlLmNvbSIs InN1YiI6Im1haWx0bzpqb2huQGV4YW1wbGUuY29tDQo+ICAgICA8bWFpbHRvOmpvaG5AZXhhbXBs ZS5jb20+DQo+ICAgICA+ICAgICA8bWFpbHRvOmpvaG5AZXhhbXBsZS5jb20NCj4gICAgIDxtYWls dG86am9obkBleGFtcGxlLmNvbT4+IiwibmJmIjoxMzk4NDIwNzUzLCJleHAiOjEzOTg0MjQzNTMs ImlhdCI6MTM5ODQyMDc1M30sIjEyMzQ1IiwNCj4gICAgID4gICAgICJIUzI1NiIpDQo+ICAgICA+ DQo+ICAgICA+ICAgICBJIHVzZWQgaHR0cDovL3d3dy5vbmxpbmVjb252ZXJzaW9uLmNvbS91bml4 X3RpbWUuaHRtIHRvIGNyZWF0ZSB0aGUNCj4gICAgID4gICAgIGRhdGUvdGltZSB2YWx1ZXM6DQo+ ICAgICA+ICAgICAibmJmIjoxMzk4NDIwNzUzIC0tPiBGcmksIDI1IEFwciAyMDE0IDEwOjEyOjMz IEdNVA0KPiAgICAgPiAgICAgImV4cCI6MTM5ODQyNDM1MyAtLT4gRnJpLCAyNSBBcHIgMjAxNCAx MToxMjozMyBHTVQNCj4gICAgID4gICAgICJpYXQiOjEzOTg0MjA3NTMgLS0+IEZyaSwgMjUgQXBy IDIwMTQgMTA6MTI6MzMgR01UDQo+ICAgICA+DQo+ICAgICA+ICAgICBIZXJlIGlzIHRoZSBvdXRw dXQgY3JlYXRlZCB3aXRoDQo+ICAgICBodHRwczovL2dpdGh1Yi5jb20vcHJvZ3JpdW0vcHlqd3Qv IGFuZA0KPiAgICAgPiAgICAgdmVyaWZpZWQgd2l0aCBodHRwOi8vand0LmlvLzoNCj4gICAgID4g ICAgDQo+ICAgICBleUpoYkdjaU9pSklVekkxTmlJc0luUjVjQ0k2SWtwWFZDSjkuZXlKcGMzTWlP aUpvZEhSd2N6b3ZMMkZ6TG1WNFlXMXdiR1V1WTI5dElpd2lhV0YwSWpveE16azROREl3TnpVekxD SnpkV0lpT2lKdFlXbHNkRzg2YW05b2JrQmxlR0Z0Y0d4bExtTnZiU0lzSW1WNGNDSTZNVE01T0RR eU5ETTFNeXdpYm1KbUlqb3hNems0TkRJd056VXpmUS4wZ2ZSVUlsZXk3MGJNUDdoTjZzTVdrSHdI ZXpkcnYyRTFMQVZjTmRUc3E0DQo+ICAgICA+DQo+ICAgICA+ICAgICBDaWFvDQo+ICAgICA+ICAg ICBIYW5uZXMNCj4gICAgID4NCj4gICAgID4NCj4gICAgID4NCj4gICAgID4gICAgIF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICA+ICAgICBPQXV0 aCBtYWlsaW5nIGxpc3QNCj4gICAgID4gICAgIE9BdXRoQGlldGYub3JnIDxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+IDxtYWlsdG86T0F1dGhAaWV0Zi5vcmcNCj4gICAgIDxtYWlsdG86T0F1dGhAaWV0 Zi5vcmc+Pg0KPiAgICAgPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KPiAgICAgPg0KPiAgICAgPg0KPiANCj4gDQoNCg== From nobody Thu May 1 00:19:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757F81A0A25 for ; Thu, 1 May 2014 00:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 P6WO0NKY4V6Y for ; Thu, 1 May 2014 00:19:34 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id DD1C61A0A15 for ; Thu, 1 May 2014 00:19:34 -0700 (PDT) Received: from BY2PR03MB027.namprd03.prod.outlook.com (10.255.240.41) by BY2PR03MB330.namprd03.prod.outlook.com (10.141.139.18) with Microsoft SMTP Server (TLS) id 15.0.934.12; Thu, 1 May 2014 07:19:31 +0000 Received: from BY2PR03CA049.namprd03.prod.outlook.com (10.141.249.22) by BY2PR03MB027.namprd03.prod.outlook.com (10.255.240.41) with Microsoft SMTP Server (TLS) id 15.0.934.12; Thu, 1 May 2014 07:19:30 +0000 Received: from BL2FFO11FD021.protection.gbl (2a01:111:f400:7c09::155) by BY2PR03CA049.outlook.office365.com (2a01:111:e400:2c5d::22) with Microsoft SMTP Server (TLS) id 15.0.934.12 via Frontend Transport; Thu, 1 May 2014 07:19:30 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD021.mail.protection.outlook.com (10.173.161.100) with Microsoft SMTP Server (TLS) id 15.0.929.8 via Frontend Transport; Thu, 1 May 2014 07:19:29 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.63]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0181.007; Thu, 1 May 2014 07:18:55 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Minor questions regarding draft-ietf-oauth-json-web-token-19 Thread-Index: Ac9lDZvNwUXiaK30S5Cr4jGGLExoyg== Date: Thu, 1 May 2014 07:18:54 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439A1A1593@TK5EX14MBXC288.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(377454003)(189002)(199002)(13464003)(50986999)(54356999)(46406003)(77982001)(2009001)(15975445006)(86612001)(76482001)(31966008)(97736001)(97756001)(55846006)(46102001)(4396001)(87936001)(20776003)(99396002)(47776003)(44976005)(79102001)(6806004)(74502001)(19580405001)(19580395003)(2656002)(83322001)(80976001)(84676001)(66066001)(80022001)(92566001)(92726001)(85852003)(86362001)(74662001)(15202345003)(81342001)(83072002)(81542001)(33656001)(50466002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB027; H:mail.microsoft.com; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01986AE76B Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/dq9JHDeMkSgdqAy3SFU7W0jkubY Subject: Re: [OAUTH-WG] Minor questions regarding draft-ietf-oauth-json-web-token-19 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 07:19:40 -0000 Hi Hannes, I have the changed the RFC 6755 and JWK references in http://tools.ietf.org= /html/draft-ietf-oauth-json-web-token-20 in the manner that you suggested. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, April 23, 2014 4:49 AM To: oauth@ietf.org Subject: [OAUTH-WG] Minor questions regarding draft-ietf-oauth-json-web-tok= en-19 Doing my shepherd write-up I had a few minor questions: * Could you move the RFC 6755 reference to the normative reference section?= Reason: the IANA consideration section depends on the existence of the urn= :ietf:params:oauth registry. * Could you move the JWK reference to the informative reference section? Reason: The JWK is only used in an example and not essential to the impleme= ntation or understanding of the specification. * Would it be sufficient to reference RFC 7159 instead of the [ECMAScript] = reference? * The document registers 'urn:ietf:params:oauth:token-type' and it is used = in the "type" header parameter. The text, however, states that the value can also be set to jwt. Why would = someone prefer to use urn:ietf:params:oauth:token-type instead of the much = shorter jwt value? Ciao Hannes From nobody Fri May 2 09:32:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3691F1A6F6B for ; Fri, 2 May 2014 09:32:21 -0700 (PDT) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 WXAp_emLVInA for ; Fri, 2 May 2014 09:32:19 -0700 (PDT) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 454F61A08DA for ; Fri, 2 May 2014 09:32:19 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id d49so579316eek.0 for ; Fri, 02 May 2014 09:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=sOd/B+iWKMWZG46EhSES/iynmXGoOUoou+/bTV/H6X8=; b=i/xr8gV/Ql04lLAVbCnUhb1fPgeUla7vNn5CdSeWAI98eLFEGJboPvj9Tv3eEnlEd2 TjUhBWxCOTFJgqnaKPQvKkUz1GmdQHKNMU4jm4Al1HNhCbBwVQnLZgdyJw2T+6ExSHeB EH8Lj/X94UzIt20l8sXU0BXrBt9QtFeBLXUlfFCQp6j35r1sB/LD5ESp5uxdd9A9pNve fOHGwVd9WuCDWn4GSdWbgWG03PTwbvy86VPe5q5yvg7kdTPfL3adacQECKI+ALopPJZG +dV5s6PM9B1LyuD17WDN71B7JvuRmtBDqodndpJWtSG8gfedx//ayKCaXLiz2gW3BB33 86pg== X-Received: by 10.14.210.65 with SMTP id t41mr15975415eeo.35.1399048336433; Fri, 02 May 2014 09:32:16 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id y51sm5790935eeu.0.2014.05.02.09.32.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 May 2014 09:32:15 -0700 (PDT) Message-ID: <5363C88E.5070209@gmail.com> Date: Fri, 02 May 2014 17:32:14 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Nr1wTFp6iPKDgaxhsKfqFm20JxM Subject: [OAUTH-WG] [OT] Validation of JWE spec Appendix 1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 16:32:21 -0000 Hi, I'm starting experimenting with JWE, and the 1st thing I wanted to do was to quickly test the example at [1]. Sorry if it is something that is very obvious and off-topic, but I can't seem to validate the encryption of the content encryption key: I keep getting a different output every time the test code runs. The code is the one that I wrote by 'scraping' the code from all over the Web but also I see Jose.4.j [3] produces a different output too. Is it due to the given key properties specified in [1] or it is actually indeed expected that production at [2] is reproducible ? Cheers, Sergey [1] http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-26#appendix-A.1 [2] http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-26#appendix-A.1.3 [3] https://bitbucket.org/b_c/jose4j/wiki/Home From nobody Sat May 3 06:37:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDC41A00C0 for ; Sat, 3 May 2014 06:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable 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 NtZJjiGSjxHA for ; Sat, 3 May 2014 06:37:24 -0700 (PDT) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with ESMTP id 52EAD1A00B6 for ; Sat, 3 May 2014 06:37:24 -0700 (PDT) Received: from mail-ie0-f170.google.com ([209.85.223.170]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKU2TxEeXbeU0U2CMe9bznnNedHATJJu0D@postini.com; Sat, 03 May 2014 06:37:22 PDT Received: by mail-ie0-f170.google.com with SMTP id rd18so6319252iec.29 for ; Sat, 03 May 2014 06:37:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2f/Bh/jyWZCf0fYO+FwVUqbKOdo6rX+h3skFHpSDWiM=; b=JSgtdm9b5oYPLd44jkjiPxFTJt6nkibjOeLKB+iO1c0VgRVCdiYreBFZ96SratD+pi mKnThho5dZ3QljAKwsL+sGMIQ7JF45Ds2u8VqOoLQTVOB9WR4YOuDfunS5HmwnJw+/A1 qSahxJMlE3oivRl4DWwepFWdUI/RVHDFzSQKTxAtE3Y7anYFZfYXwYs1cedLiqotG8p1 t2LUCxL+AfIkCEQR0oC9sacmb3f/1Ux8QyIneEturdK4PLez4JvCTKvI2EFctf6fViEt /ePx9OWTI5pkwz3OW1HvcqNRw0t6CilTDWIixVoH6s1y8ksOQUjKC0r+qifhdlWwMoH4 9mGA== X-Gm-Message-State: ALoCoQkpKr8VX5iWrSzQ95aQZ9K6MoZvo/UMrctOtV0Emh7diGBEO1m7r11wnaIDry4rIoqtFg2ZpQdhb1xIlPNaY6C1OtqgNewpctHmaKi11UVp3z/CSyAQbpYBmjMude3KZHzr/FRN X-Received: by 10.42.136.130 with SMTP id u2mr21852738ict.51.1399124241336; Sat, 03 May 2014 06:37:21 -0700 (PDT) X-Received: by 10.42.136.130 with SMTP id u2mr21852727ict.51.1399124241184; Sat, 03 May 2014 06:37:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Sat, 3 May 2014 06:36:51 -0700 (PDT) In-Reply-To: <5363C88E.5070209@gmail.com> References: <5363C88E.5070209@gmail.com> From: Brian Campbell Date: Sat, 3 May 2014 07:36:51 -0600 Message-ID: To: Sergey Beryozkin , "jose@ietf.org" Content-Type: multipart/alternative; boundary=90e6ba6e8c0664988004f87eff32 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DX-E1w2OD3ZLBPxns8_6J8Ubir8 Cc: "" Subject: Re: [OAUTH-WG] [OT] Validation of JWE spec Appendix 1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 13:37:26 -0000 --90e6ba6e8c0664988004f87eff32 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sergey, This question might be more appropriate for the JOSE WG [0] list (which I've cc'd) as JWE is being developed there. Some of the algorithms, RSAES OAEP being one of them, are probabilistic encryption schemes which incorporate some element of randomness to yield a different output even when encrypting the same content multiple times. So the behavior you are observing is to be expected. That means that exactly reproducing the various steps of the examples in the specs will not be possible in some cases. I was recently discussing this off list with Matt Miller, the author of the JOSE Cookbook [1], and my suggestion was to have the cookbook just make note of which examples, or which parts of which examples, can't be easily reproduced due to non-deterministic algorithms. I think that your question here suggests that that idea might well provide utility to users/readers of that document. Hope that helps, Brian [0] http://tools.ietf.org/wg/jose/ [1] http://tools.ietf.org/html/draft-ietf-jose-cookbook-02 On Fri, May 2, 2014 at 10:32 AM, Sergey Beryozkin wro= te: > Hi, > > I'm starting experimenting with JWE, and the 1st thing I wanted to do was > to quickly test the example at [1]. > > Sorry if it is something that is very obvious and off-topic, but I can't > seem to validate the encryption of the content encryption key: I keep > getting a different output every time the test code runs. > > The code is the one that I wrote by 'scraping' the code from all over the > Web but also I see Jose.4.j [3] produces a different output too. > Is it due to the given key properties specified in [1] or it is actually > indeed expected that production at [2] is reproducible ? > > Cheers, Sergey > > [1] http://tools.ietf.org/html/draft-ietf-jose-json-web- > encryption-26#appendix-A.1 > [2] http://tools.ietf.org/html/draft-ietf-jose-json-web- > encryption-26#appendix-A.1.3 > [3] https://bitbucket.org/b_c/jose4j/wiki/Home > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 [image: Ping Identity logo] Brian Campbell [Enter Title] @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with us=E2=80=A6 [image: twitter logo] = [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo] [image: flipboard logo] [image: rss feed icon] [image: Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] --90e6ba6e8c0664988004f87eff32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sergey,

This question = might be more appropriate for the JOSE WG [0] list (which I've cc'd= ) as JWE is being developed there.

Some of the algo= rithms, RSAES OAEP being one of them, are probabilistic encryption schemes = which incorporate some element of randomness to yield a different output ev= en when encrypting the same content multiple times. So the behavior you are= observing is to be expected.

That means that exactly reproducing the various steps of the exam= ples in the specs will not be possible in some cases. I was recently discus= sing this off list with Matt Miller, the author of the JOSE Cookbook [1], a= nd my suggestion was to have the cookbook just make note of which examples,= or which parts of which examples, can't be easily reproduced due to no= n-deterministic algorithms. I think that your question here suggests that t= hat idea might well provide utility to users/readers of that document.

Hope that helps,
Brian


[0] http://tools.ietf.or= g/wg/jose/
[1] http://tools.ietf.org/html/draft-ietf-jose-= cookbook-02






On Fri, May 2, 2014 at 10:32 AM, Sergey Beryozkin <sberyozkin@gmail.com= > wrote:
Hi,

I'm starting experimenting with JWE, and the 1st thing I wanted to do w= as to quickly test the example at [1].

Sorry if it is something that is very obvious and off-topic, but I can'= t seem to validate the encryption of the content encryption key: I keep get= ting a different output every time the test code runs.

The code is the one that I wrote by 'scraping' the code from all ov= er the Web but also I see Jose.4.j [3] produces a different output too.
Is it due to the given key properties specified in [1] or it is actually in= deed expected that production at [2] is reproducible ?

Cheers, Sergey

[1] http://tools.ietf.org/html/dra= ft-ietf-jose-json-web-encryption-26#appendix-A.1
[2] http://tools.ietf.org/html/d= raft-ietf-jose-json-web-encryption-26#appendix-A.1.3
[3] https://bitbucket.org/b_c/jose4j/wiki/Home

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



--
3D"Ping =09
Brian Campbell
[Enter Title]
=09
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter<= /a> 3D"you= 3D"L= 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register

--90e6ba6e8c0664988004f87eff32-- From nobody Mon May 5 10:08:30 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F381A03A4; Mon, 5 May 2014 10:08:27 -0700 (PDT) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 M7PnJac7umrx; Mon, 5 May 2014 10:08:24 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8931A038B; Mon, 5 May 2014 10:08:24 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hm4so5939242wib.17 for ; Mon, 05 May 2014 10:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=s9Bmno+YbQdzsrCL5+ZH6Tz5B90U1VSs6iN0VqNzxfc=; b=PN4/tLloiqx/0CefwdPfri4ZvcjuLkCSODd2Fj0JjYs0zKDVeUIz+r7Y+hJWU7Z5km JLztG7qjVtMtrpkIh+/cXlsN8uzyzyhp9PSyJuU7s/msQ8/sGlnvbvgaYUt429k72rgd 2VTGWRtdQOcsnF8zFan38VYJTAACr08xjOTJ0qb6rZQpXUwJ7JmrNKFb+51T3QAQmzMf uOchTGO/ygrHeZE7/r6suVrXRofEK1OUrsIzmCSgHKE8kRtXZ/yFa9jXPm79wdiPPKz3 FJQWNftdwsB9wMMM6s374FO0qg5nehcwqloHUTTB8kQgPN9lsdTS2BeQPPuS9jghNV+n p1WA== X-Received: by 10.194.203.2 with SMTP id km2mr2709870wjc.72.1399309700213; Mon, 05 May 2014 10:08:20 -0700 (PDT) Received: from [192.168.2.7] ([89.100.139.33]) by mx.google.com with ESMTPSA id n5sm18976240wiz.1.2014.05.05.10.08.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 10:08:19 -0700 (PDT) Message-ID: <5367C582.3010705@gmail.com> Date: Mon, 05 May 2014 18:08:18 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Brian Campbell , "jose@ietf.org" References: <5363C88E.5070209@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DtFsQv1QDQuSkpVlUSdxmFH-eyc Cc: "" Subject: Re: [OAUTH-WG] [OT] Validation of JWE spec Appendix 1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:08:27 -0000 Hi Brian On 03/05/14 14:36, Brian Campbell wrote: > Hi Sergey, > > This question might be more appropriate for the JOSE WG [0] list (which > I've cc'd) as JWE is being developed there. > Sure, I'll be asking at [0] next time... > Some of the algorithms, RSAES OAEP being one of them, are probabilistic > encryption schemes which incorporate some element of randomness to yield > a different output even when encrypting the same content multiple times. > So the behavior you are observing is to be expected. > I was starting blaming myself for the fact I could not get the code producing a match :-) > That means that exactly reproducing the various steps of the examples in > the specs will not be possible in some cases. I was recently discussing > this off list with Matt Miller, the author of the JOSE Cookbook [1], and > my suggestion was to have the cookbook just make note of which examples, > or which parts of which examples, can't be easily reproduced due to > non-deterministic algorithms. I think that your question here suggests > that that idea might well provide utility to users/readers of that document. > +1 Thanks for the help, Sergey > Hope that helps, > Brian > > > [0] http://tools.ietf.org/wg/jose/ > [1] http://tools.ietf.org/html/draft-ietf-jose-cookbook-02 > > > > > > > On Fri, May 2, 2014 at 10:32 AM, Sergey Beryozkin > wrote: > > Hi, > > I'm starting experimenting with JWE, and the 1st thing I wanted to > do was to quickly test the example at [1]. > > Sorry if it is something that is very obvious and off-topic, but I > can't seem to validate the encryption of the content encryption key: > I keep getting a different output every time the test code runs. > > The code is the one that I wrote by 'scraping' the code from all > over the Web but also I see Jose.4.j [3] produces a different output > too. > Is it due to the given key properties specified in [1] or it is > actually indeed expected that production at [2] is reproducible ? > > Cheers, Sergey > > [1] > http://tools.ietf.org/html/__draft-ietf-jose-json-web-__encryption-26#appendix-A.1 > > [2] > http://tools.ietf.org/html/__draft-ietf-jose-json-web-__encryption-26#appendix-A.1.3 > > [3] https://bitbucket.org/b_c/__jose4j/wiki/Home > > > _________________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/__listinfo/oauth > > > > > > -- > Ping Identity logo > Brian Campbell > [Enter Title] > @ bcampbell@pingidentity.com > phone +1 720.317.2061 > Connect with us… > twitter logo youtube logo > LinkedIn logo > Facebook logo > Google+ logo > slideshare logo > flipboard logo > rss feed icon > > Register for Cloud Identity Summit 2014 | Modern Identity Revolution | > 19–23 July, 2014 | Monterey, CA > > From nobody Tue May 6 15:40:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754211A0660 for ; Tue, 6 May 2014 15:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_RED=0.001] autolearn=ham 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 gBnA8XMP5fmI for ; Tue, 6 May 2014 15:40:25 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 451A11A03D7 for ; Tue, 6 May 2014 15:40:25 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id q8so206752lbi.13 for ; Tue, 06 May 2014 15:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zmnSTDYAdLFSngVRU0GLmGBVuGuTCy+elYsKxHZR1MY=; b=YVldkYmxCp6pzMFn4g5bztHGwfN9nkj0343e8fbB7OKPguElE+hTZ526PE20OFkufL rNKrpQetAy3M9jNcfZUDayB17nTKSp/qvDse7qnXWmxpYJpgS+I6DSba4kUp1CoOasay b13DLKOJlE31Km+Trmg41wzLR3HT561s5Hwqv+HtpRcOkqz1a2lP4fZC7kVz9szBrnqV bxssWnLHItn5PZlCZin04iiKN75oak/wQ/M+VdvDIwr5RdtvelYWDvuUDMt6NmMF/Vma a0J18u6OONDYmPkAMO9WsZ6iKlqhXenuwCvvqW/NREw8CLWmlezoUTcDm7Ek3rHa2Tpv X/PQ== MIME-Version: 1.0 X-Received: by 10.112.137.5 with SMTP id qe5mr35284185lbb.16.1399416020532; Tue, 06 May 2014 15:40:20 -0700 (PDT) Received: by 10.112.105.134 with HTTP; Tue, 6 May 2014 15:40:20 -0700 (PDT) In-Reply-To: References: <53577C73.2010201@gmx.net> Date: Wed, 7 May 2014 07:40:20 +0900 Message-ID: From: Nat Sakimura To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=089e0115fd3ccceeb704f8c2eefe Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/eiDg8231yF1qXh3OC7GKuL9d5mQ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 22:40:27 -0000 --089e0115fd3ccceeb704f8c2eefe Content-Type: text/plain; charset=UTF-8 I was pinged by Mike that the attached message below apparently did not go through to the list. Perhaps it was due to too much "quotation". So, I am forwarding it again, this time with much less "quotes" from earlier massages in the thread. The points in this message is: - I am not aware of any IPR that applies to this specification. - NRI has PHP and Scala implementation of JWT. Cheers, Nat 2014-05-01 19:45 GMT+09:00 Nat Sakimura : > > > > 2014-04-23 17:40 GMT+09:00 Hannes Tschofenig : > > Hi all, >> >> I am working on the shepherd writeup for the JWT bearer document. The >> shepherd write-ups for the assertion draft and the SAML bearer document >> have been completed a while ago already, see >> http://www.ietf.org/mail-archive/web/oauth/current/msg12410.html >> >> A few requests: >> >> - To the document authors: Please confirm that any and all appropriate >> IPR disclosures required for full conformance with the provisions of BCP >> 78 and BCP 79 have already been filed. >> > > I am not aware of any IPR that applies to this specification. > > >> - To all: Are you aware of implementations of this specification? If so, >> I would like to reference them in my write-up. >> > > NRI has PHP and Scala implementation of JWT. > > >> >> - To all: Please also go through the text to make sure that I correctly >> reflect the history and the status of this document. >> >> Here is the most recent version of the write-up: >> >> https://raw.githubusercontent.com/hannestschofenig/tschofenig-ids/master/shepherd-writeups/Writeup_OAuth_JWT-Assertion-Profile.txt >> >> >> (The copy-and-paste of the full version is below.) >> >> Ciao >> Hannes >> >> PS: Note that I have send a mail about a pending issue to the list. In >> response to my question I will update the write-up accordingly. >> >> -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e0115fd3ccceeb704f8c2eefe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was pinged by Mike that the attached message below appar= ently did not go through to the list.=C2=A0
Perhaps it was due to too m= uch "quotation". So, I am forwarding it again, this time with muc= h less "quotes" from earlier massages in the thread.=C2=A0

The points in this message is:=C2=A0

-=C2=A0I= am not aware of any=C2=A0IPR=C2=A0that applies to this specification.
-=C2=A0NRI has PHP and Scala implementation of J= WT.

Ch= eers,=C2=A0

Nat

2014-05-01 19:45 GMT+09:00 Nat Sakimura <sakim= ura@gmail.com>:



2014-04-23 17:40 GMT+09:00 Hannes Tschofenig <= hannes.tscho= fenig@gmx.net>:

Hi all,

I am working on the shepherd writeup for the JWT bearer document. The
shepherd write-ups for the assertion draft and the SAML bearer document
have been completed a while ago already, see
http://www.ietf.org/mail-archive/web/oauth/current/msg1= 2410.html

A few requests:

- To the document authors: Please confirm that any and all appropriate
IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed.

I am not aware of any=C2=A0IPR=C2=A0that applies to this specification.

=

- To all: Are you aware of implementations of this specification? If so, I would like to reference them in my write-up.
<= br>
NRI has PHP and Scala implementation of JWT.=C2=A0
= =C2=A0

- To all: Please also go through the text to make sure that I correctly
reflect the history and the status of this document.

Here is the most recent version of the write-up:
https://raw.githubusercontent.com/hannestschofenig/tschofenig-i= ds/master/shepherd-writeups/Writeup_OAuth_JWT-Assertion-Profile.txt


(The copy-and-paste of the full version is below.)

Ciao
Hannes

PS: Note that I have send a mail about a pending issue to the list. In
response to my question I will update the write-up accordingly.


=
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/<= /a>
@_nat_en
--089e0115fd3ccceeb704f8c2eefe-- From nobody Tue May 6 15:54:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3A71A0650 for ; Tue, 6 May 2014 15:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 JY519bV1zVRK for ; Tue, 6 May 2014 15:54:29 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 54B4F1A03D7 for ; Tue, 6 May 2014 15:54:29 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s46MsOsm018665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 May 2014 22:54:25 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s46MsNjE000983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 6 May 2014 22:54:24 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s46MsN2G009599 for ; Tue, 6 May 2014 22:54:23 GMT Received: from [10.255.54.14] (/64.71.18.60) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 May 2014 15:54:22 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_1ADB8E45-0BAB-41F8-A50B-B24396B6EEA1" Message-Id: <172266CC-2A8C-4724-9D89-F79D290B1E48@oracle.com> Date: Tue, 6 May 2014 15:54:20 -0700 To: OAuth WG Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/eGPcs2EESbJ3NyxRdHcsEKxv4Pk Subject: [OAUTH-WG] JSON Payload signature (re: draft-richer-oauth-signed-http-request-01.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 22:54:30 -0000 --Apple-Mail=_1ADB8E45-0BAB-41F8-A50B-B24396B6EEA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Justin, Any discussion on including JSON payloads in the signed requests? Had = an interesting conversation with Bill and I think this would be a useful = optional feature. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_1ADB8E45-0BAB-41F8-A50B-B24396B6EEA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Justin,

Any discussion on = including JSON payloads in the signed requests?  Had an interesting = conversation with Bill and I think this would be a useful optional = feature.

= --Apple-Mail=_1ADB8E45-0BAB-41F8-A50B-B24396B6EEA1-- From nobody Tue May 6 17:19:47 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010DA1A071A for ; Tue, 6 May 2014 17:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 qTsZ14N6MMt4 for ; Tue, 6 May 2014 17:19:44 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6631A06E1 for ; Tue, 6 May 2014 17:19:44 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 06E211F0834; Tue, 6 May 2014 20:19:40 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DA79C1F07CF; Tue, 6 May 2014 20:19:39 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.73]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Tue, 6 May 2014 20:19:39 -0400 From: "Richer, Justin P." To: Phil Hunt Thread-Topic: [OAUTH-WG] JSON Payload signature (re: draft-richer-oauth-signed-http-request-01.txt) Thread-Index: AQHPaX4lWan1JgF0lkWdgI0FoPC0l5s0hCYA Date: Wed, 7 May 2014 00:19:39 +0000 Message-ID: <97A10407-119B-4443-99C4-6AEE1DDF85A0@mitre.org> References: <172266CC-2A8C-4724-9D89-F79D290B1E48@oracle.com> In-Reply-To: <172266CC-2A8C-4724-9D89-F79D290B1E48@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.11.254] Content-Type: multipart/alternative; boundary="_000_97A10407119B444399C46AEE1DDF85A0mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/tVU01YFBa7-JztH08D0zwedgtzc Cc: OAuth WG Subject: Re: [OAUTH-WG] JSON Payload signature (re: draft-richer-oauth-signed-http-request-01.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 00:19:46 -0000 --_000_97A10407119B444399C46AEE1DDF85A0mitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Seems like a reasonable extension to me, in that it shouldn't break things,= really. Is the suggestion to define a particular member for "other stuff" = or to state that you're allowed to add other stuff inside the payload objec= t? But on the other hand, I'm wondering why other parts of the protocol (like = hashing the HTTP body) wouldn't cover it? Or why you wouldn't want to just = use a JOSE container for your entire protocol? Basically, within a given pr= otocol you could easily put whatever additional stuff you like inside the p= rotected JOSE payload without disrupting things, but I don't see the use ca= se why you'd want to do that and not something else. -- Justin On May 6, 2014, at 6:54 PM, Phil Hunt > wrote: Justin, Any discussion on including JSON payloads in the signed requests? Had an i= nteresting conversation with Bill and I think this would be a useful option= al feature. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_97A10407119B444399C46AEE1DDF85A0mitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <2438D5916900DE489F7C27A4F1D5DA20@imc.mitre.org> Content-Transfer-Encoding: quoted-printable Seems like a reasonable extension to me, in that it shouldn't break things,= really. Is the suggestion to define a particular member for "other st= uff" or to state that you're allowed to add other stuff inside the pay= load object?

But on the other hand, I'm wondering why other parts of the protocol (= like hashing the HTTP body) wouldn't cover it? Or why you wouldn't want to = just use a JOSE container for your entire protocol? Basically, within a giv= en protocol you could easily put whatever additional stuff you like inside the protected JOSE payload witho= ut disrupting things, but I don't see the use case why you'd want to do tha= t and not something else.

 -- Justin

On May 6, 2014, at 6:54 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Justin,

Any discussion on including JSON payloads in the signed requests? &nbs= p;Had an interesting conversation with Bill and I think this would be a use= ful optional feature.

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

--_000_97A10407119B444399C46AEE1DDF85A0mitreorg_-- From nobody Tue May 6 17:34:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0411A071D for ; Tue, 6 May 2014 17:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 HedMTIJUPSag for ; Tue, 6 May 2014 17:34:04 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEE31A072A for ; Tue, 6 May 2014 17:34:03 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s470XvPj019800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 May 2014 00:33:58 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s470Xu3B002234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2014 00:33:57 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s470Xu1D015969; Wed, 7 May 2014 00:33:56 GMT Received: from [10.255.54.0] (/64.71.18.60) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 May 2014 17:33:56 -0700 References: <172266CC-2A8C-4724-9D89-F79D290B1E48@oracle.com> <97A10407-119B-4443-99C4-6AEE1DDF85A0@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <97A10407-119B-4443-99C4-6AEE1DDF85A0@mitre.org> Content-Type: multipart/alternative; boundary=Apple-Mail-F02643CC-B162-4794-8CEF-B5968FEAFE4A Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D167) From: Phil Hunt Date: Tue, 6 May 2014 17:33:56 -0700 To: "Richer, Justin P." X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JSjw3L4TahpYSpxGHPbQVYuziPY Cc: OAuth WG Subject: Re: [OAUTH-WG] JSON Payload signature (re: draft-richer-oauth-signed-http-request-01.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 00:34:06 -0000 --Apple-Mail-F02643CC-B162-4794-8CEF-B5968FEAFE4A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Well... In the case of scim which takes json requests and gives json responses, it w= ould be nice to have signed transactions including json payload from http bo= dy. This could be easily layer on top of scim without required any change to= scim.=20 If however someone wants a json body like a jwt assertion (where both are in= the same json structure) thats a different thing isn't it. :-) Phil > On May 6, 2014, at 17:19, "Richer, Justin P." wrote: >=20 > Seems like a reasonable extension to me, in that it shouldn't break things= , really. Is the suggestion to define a particular member for "other stuff" o= r to state that you're allowed to add other stuff inside the payload object?= >=20 > But on the other hand, I'm wondering why other parts of the protocol (like= hashing the HTTP body) wouldn't cover it? Or why you wouldn't want to just u= se a JOSE container for your entire protocol? Basically, within a given prot= ocol you could easily put whatever additional stuff you like inside the prot= ected JOSE payload without disrupting things, but I don't see the use case w= hy you'd want to do that and not something else. >=20 > -- Justin >=20 >> On May 6, 2014, at 6:54 PM, Phil Hunt wrote: >>=20 >> Justin, >>=20 >> Any discussion on including JSON payloads in the signed requests? Had an= interesting conversation with Bill and I think this would be a useful optio= nal feature. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-F02643CC-B162-4794-8CEF-B5968FEAFE4A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Well...

In the case of scim which takes json requests and gives json responses, it would be nice to have signed transactions including json payload from http body. This could be easily layer on top of scim without required any change to scim. 

If however someone wants a json body like a jwt assertion (where both are in the same json structure) thats a different thing isn't it. :-)

Phil

On May 6, 2014, at 17:19, "Richer, Justin P." <jricher@mitre.org> wrote:

Seems like a reasonable extension to me, in that it shouldn't break things, really. Is the suggestion to define a particular member for "other stuff" or to state that you're allowed to add other stuff inside the payload object?

But on the other hand, I'm wondering why other parts of the protocol (like hashing the HTTP body) wouldn't cover it? Or why you wouldn't want to just use a JOSE container for your entire protocol? Basically, within a given protocol you could easily put whatever additional stuff you like inside the protected JOSE payload without disrupting things, but I don't see the use case why you'd want to do that and not something else.

 -- Justin

On May 6, 2014, at 6:54 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Justin,

Any discussion on including JSON payloads in the signed requests?  Had an interesting conversation with Bill and I think this would be a useful optional feature.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-F02643CC-B162-4794-8CEF-B5968FEAFE4A-- From nobody Tue May 6 19:06:22 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2319C1A0304 for ; Tue, 6 May 2014 19:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 99CgCO9Jmg2e for ; Tue, 6 May 2014 19:06:19 -0700 (PDT) Received: from e23smtp01.au.ibm.com (e23smtp01.au.ibm.com [202.81.31.143]) by ietfa.amsl.com (Postfix) with ESMTP id 48A981A01EF for ; Tue, 6 May 2014 19:06:17 -0700 (PDT) Received: from /spool/local by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 7 May 2014 12:06:12 +1000 Received: from d23dlp03.au.ibm.com (202.81.31.214) by e23smtp01.au.ibm.com (202.81.31.207) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 7 May 2014 12:06:10 +1000 Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [9.190.235.152]) by d23dlp03.au.ibm.com (Postfix) with ESMTP id 471E03578047 for ; Wed, 7 May 2014 12:06:10 +1000 (EST) Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s471ipSl7864822 for ; Wed, 7 May 2014 11:44:52 +1000 Received: from d23av02.au.ibm.com (localhost [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s472697P016435 for ; Wed, 7 May 2014 12:06:09 +1000 Received: from d23ml125.sg.ibm.com (d23ml125.sg.ibm.com [9.127.37.179]) by d23av02.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s47265wi016265 for ; Wed, 7 May 2014 12:06:05 +1000 Auto-Submitted: auto-generated From: Codur Sreedhar Pranam To: oauth@ietf.org Message-ID: Date: Wed, 7 May 2014 10:02:27 +0800 X-MIMETrack: Serialize by Router on d23ml125/23/M/IBM(Release 8.5.3FP6|November 21, 2013) at 05/07/2014 10:02:27 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=C7BBF642DF98B3608f9e8a93df938690918cC7BBF642DF98B360" Content-Disposition: inline X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14050702-1618-0000-0000-0000002F1E4D Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/v_AYOgzLkGJumTLYWBo71ZhweWg Subject: [OAUTH-WG] AUTO: Codur Sreedhar Pranam is out of the office (returning Thu 05/15/2014) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 02:06:21 -0000 --0__=C7BBF642DF98B3608f9e8a93df938690918cC7BBF642DF98B360 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office from Tue 05/06/2014 until Thu 05/15/2014. If anything is urgent then please contact my blue pages manager Chiang = Kai Note: This is an automated response to your message "OAuth Digest, Vol= 67, Issue 5" sent on 05/07/2014 8:34:06. This is the only notification you will receive while this person is awa= y.= --0__=C7BBF642DF98B3608f9e8a93df938690918cC7BBF642DF98B360 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office from Tue= 05/06/2014 until Thu 05/15/2014.

If anything is urgent then = please contact my blue pages manager Chiang Kai


Note: Thi= s is an automated response to your message  "OAuth Digest, Vol 67, Issue 5"<= /font> sent= on 05/07/2014 8:34:06.

This is t= he only notification you will receive while this person is away.= = --0__=C7BBF642DF98B3608f9e8a93df938690918cC7BBF642DF98B360-- From nobody Wed May 7 04:16:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08F41A06D0; Wed, 7 May 2014 04:16:12 -0700 (PDT) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 bIqmOlCuS2M0; Wed, 7 May 2014 04:16:10 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 564911A06D1; Wed, 7 May 2014 04:16:10 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so1114377wib.13 for ; Wed, 07 May 2014 04:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WpuzyB99vtnnitTFFUWDDnBbOh0lJsakZCavfucn0SM=; b=qbQf6s1KS9TZt/WOHgF4C/MXf2PkhFBpI7syf5hMWEJJ9cx9e+HFVcNLqyj/62f7lu LPW/vXILLHgGmb78gwAeAO80Y9I301Ra4TXT+PY5k/KDO6p4XAxmspGItzQXx3pxHolM rzlP3B81w3UxT+YeTYDSDRrUgyD5sTmWXydaDXhWr/c7+3ffbIv4SHmqcgo43namhgTl kpIIBoDu2gJkY1r7kXEqQsa4FO8DfLseDwoRC3RyvqfNeeA3dwysPDVRXl38Bf/xnbce Sx4JyQJdYJDDT5eS4zZDixa531TuJoZZKjhofMQGSkDDzbfdZjXh3csfWLyRZz8dee45 OcsQ== X-Received: by 10.180.93.226 with SMTP id cx2mr7331662wib.16.1399461365680; Wed, 07 May 2014 04:16:05 -0700 (PDT) Received: from [192.168.2.7] ([89.100.139.33]) by mx.google.com with ESMTPSA id xm20sm30944489wib.19.2014.05.07.04.16.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 04:16:04 -0700 (PDT) Message-ID: <536A15F3.7050203@gmail.com> Date: Wed, 07 May 2014 12:16:03 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Brian Campbell , "jose@ietf.org" References: <5363C88E.5070209@gmail.com> <5367C582.3010705@gmail.com> In-Reply-To: <5367C582.3010705@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/grsBg8UPz3udXUoN5LvNydiyF6c Cc: "" Subject: Re: [OAUTH-WG] [OT] Validation of JWE spec Appendix 1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 11:16:12 -0000 Sorry for the noise, wanted to point out to the fact Section A.1.8 explicitly mentions "Note that since the RSAES OAEP computation includes random values, the encryption results above will not be completely reproducible". I wish I read that section first :-) Thanks all, Sergey On 05/05/14 18:08, Sergey Beryozkin wrote: > Hi Brian > On 03/05/14 14:36, Brian Campbell wrote: >> Hi Sergey, >> >> This question might be more appropriate for the JOSE WG [0] list (which >> I've cc'd) as JWE is being developed there. >> > Sure, I'll be asking at [0] next time... >> Some of the algorithms, RSAES OAEP being one of them, are probabilistic >> encryption schemes which incorporate some element of randomness to yield >> a different output even when encrypting the same content multiple times. >> So the behavior you are observing is to be expected. >> > I was starting blaming myself for the fact I could not get the code > producing a match :-) >> That means that exactly reproducing the various steps of the examples in >> the specs will not be possible in some cases. I was recently discussing >> this off list with Matt Miller, the author of the JOSE Cookbook [1], and >> my suggestion was to have the cookbook just make note of which examples, >> or which parts of which examples, can't be easily reproduced due to >> non-deterministic algorithms. I think that your question here suggests >> that that idea might well provide utility to users/readers of that >> document. >> > +1 > > Thanks for the help, > Sergey > >> Hope that helps, >> Brian >> >> >> [0] http://tools.ietf.org/wg/jose/ >> [1] http://tools.ietf.org/html/draft-ietf-jose-cookbook-02 >> >> >> >> >> >> >> On Fri, May 2, 2014 at 10:32 AM, Sergey Beryozkin > > wrote: >> >> Hi, >> >> I'm starting experimenting with JWE, and the 1st thing I wanted to >> do was to quickly test the example at [1]. >> >> Sorry if it is something that is very obvious and off-topic, but I >> can't seem to validate the encryption of the content encryption key: >> I keep getting a different output every time the test code runs. >> >> The code is the one that I wrote by 'scraping' the code from all >> over the Web but also I see Jose.4.j [3] produces a different output >> too. >> Is it due to the given key properties specified in [1] or it is >> actually indeed expected that production at [2] is reproducible ? >> >> Cheers, Sergey >> >> [1] >> >> http://tools.ietf.org/html/__draft-ietf-jose-json-web-__encryption-26#appendix-A.1 >> >> >> >> >> [2] >> >> http://tools.ietf.org/html/__draft-ietf-jose-json-web-__encryption-26#appendix-A.1.3 >> >> >> >> >> [3] https://bitbucket.org/b_c/__jose4j/wiki/Home >> >> >> _________________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/__listinfo/oauth >> >> >> >> >> >> -- >> Ping Identity logo >> Brian Campbell >> [Enter Title] >> @ bcampbell@pingidentity.com >> phone +1 720.317.2061 >> Connect with us… >> twitter logo youtube logo >> LinkedIn logo >> Facebook logo >> Google+ logo >> slideshare logo >> flipboard logo >> rss feed icon >> >> >> Register for Cloud Identity Summit 2014 | Modern Identity Revolution | >> 19–23 July, 2014 | Monterey, CA >> >> > > From nobody Thu May 8 12:04:09 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3255B1A00F4 for ; Thu, 8 May 2014 12:04:08 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 EjfA3am1Hg1o for ; Thu, 8 May 2014 12:04:04 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) by ietfa.amsl.com (Postfix) with ESMTP id AD8971A00DE for ; Thu, 8 May 2014 12:04:03 -0700 (PDT) Received: from BLUPR03CA035.namprd03.prod.outlook.com (10.141.30.28) by BLUPR03MB357.namprd03.prod.outlook.com (10.141.75.151) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 8 May 2014 19:03:58 +0000 Received: from BN1BFFO11FD026.protection.gbl (2a01:111:f400:7c10::1:118) by BLUPR03CA035.outlook.office365.com (2a01:111:e400:879::28) with Microsoft SMTP Server (TLS) id 15.0.934.12 via Frontend Transport; Thu, 8 May 2014 19:03:57 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD026.mail.protection.outlook.com (10.58.144.89) with Microsoft SMTP Server (TLS) id 15.0.929.8 via Frontend Transport; Thu, 8 May 2014 19:03:57 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.63]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0174.002; Thu, 8 May 2014 19:03:23 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 Shepherd Write-up Thread-Index: AQHPXuuAbJx37+xreUSkSd/lWmnNa5shTqCQgBXTv+A= Date: Thu, 8 May 2014 19:03:22 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439A1AE2FB@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <5357AA4C.8080707@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(377454003)(189002)(199002)(13464003)(53754006)(46406003)(15975445006)(81342001)(85852003)(76482001)(92726001)(92566001)(77982001)(97756001)(46102001)(81542001)(19580395003)(44976005)(97736001)(2656002)(66066001)(74662001)(50986999)(54356999)(47776003)(86362001)(33656001)(79102001)(31966008)(2009001)(15395725003)(50466002)(23726002)(83322001)(4396001)(55846006)(83072002)(20776003)(76176999)(19580405001)(86612001)(99396002)(74502001)(80022001)(6806004)(15202345003)(87936001)(84676001)(15398625002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB357; H:mail.microsoft.com; FPR:C60BF1CE.9EDAF301.B1E37B87.42E4C880.20776; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0205EDCD76 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ODSV8OLKrwqYWSlpMtC2j4auF-U Subject: [OAUTH-WG] FW: draft-ietf-oauth-json-web-token-19 Shepherd Write-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 19:04:08 -0000 Forwarding to the mailing list, since I mistakenly replied only to Hannes..= . -----Original Message----- From: Mike Jones=20 Sent: Thursday, April 24, 2014 2:44 PM To: 'Hannes Tschofenig' Subject: RE: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 Shepherd Write-u= p I am not aware of any IPR that applies to this specification. -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, April 23, 2014 4:56 AM To: oauth@ietf.org Subject: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 Shepherd Write-up Hi all, I am working on the shepherd writeup for the JWT. Here are a few questions: - To the document authors: Please confirm that any and all appropriate IPR = disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. - To all: I have included various pointers to implementations in the write-= up. Maybe there are others that should be included. If so, please let me kn= ow. - To all: Please also go through the text to make sure that I correctly ref= lect the history and the status of this document. Here is the latest version of the write-up: https://raw.githubusercontent.com/hannestschofenig/tschofenig-ids/master/sh= epherd-writeups/Writeup_OAuth_JWT.txt Ciao Hannes PS: Here is the copy-and-paste text: -------- Writeup for "JSON Web Token (JWT)" (1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper = type of RFC? Is this type of RFC indicated in the title page header? The RFC type is 'Standards Track' and the type is indicated in the title pa= ge. This document defines the syntax and semantic of information elements. (2) The IESG approval announcement includes a Document Announcement Write-U= p. Please provide such a Document Announcement Write-Up. Recent examples ca= n be found in the "Action" announcements for approved documents. The approv= al announcement contains the following sections: Technical Summary: JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. Working Group Summary: Was there anything in WG process that is worth noting? For example, was the= re controversy about particular points or were there decisions where the co= nsensus was particularly rough? This document was uncontroversial. It allows OAuth deployments to use a sta= ndardized access token format, which increases interoperability of OAuth-ba= sed deployments. Document Quality: This document has gone through many iterations and has received substantial= feedback. A substantial number of implementations exist, as documented at http://open= id.net/developers/libraries/ (scrowl down to the 'JWT/JWS/JWE/JWK/JWA Implementations' section) An Excel document providing additional details can be found here: http://www.oauth-v2.org/wp-content/uploads/2014/04/JWT-Implementations.xlsx Personnel: The document shepherd is Hannes Tschofenig and the responsible area directo= r is Kathleen Moriarty. (3) Briefly describe the review of this document that was performed by the = Document Shepherd. If this version of the document is not ready for publica= tion, please explain why the document is being forwarded to the IESG. The draft authors believe that this document is ready for publication. The document has received review comments from working group members, and f= rom the OAuth working group chairs. Implementations exist and they have tes= ted for interoperability as part of the OpenID Connect interop events. (4) Does the document Shepherd have any concerns about the depth or breadth= of the reviews that have been performed? This document has gotten enough feedback from the working group. (5) Do portions of the document need review from a particular or from broad= er perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML= , or internationalization? If so, describe the review that took place. Since the OAuth working group develops security protocols any feedback from= the security community is always appreciated. The JWT document heavily depends on the work in the JOSE working group sinc= e it re-uses the JWE and the JWS specifications. (6) Describe any specific concerns or issues that the Document Shepherd has= with this document that the Responsible Area Director and/or the IESG shou= ld be aware of? For example, perhaps he or she is uncomfortable with certai= n parts of the document, or has concerns whether there really is a need for= it. In any event, if the WG has discussed those issues and has indicated t= hat it still wishes to advance the document, detail those concerns here. The shepherd has no concerns with this document. (7) Has each author confirmed that any and all appropriate IPR disclosures = required for full conformance with the provisions of BCP 78 and BCP 79 have= already been filed. If not, explain why? [[Confirmation from the authors required.]] (8) Has an IPR disclosure been filed that references this document? If so, = summarize any WG discussion and conclusion regarding the IPR disclosures. Two IPRs have been filed for the JWT specification this document relies on,= see http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3D= draft-ietf-oauth-json-web-token There was no discussion regarding those two IPRs on the mailing list. (9) How solid is the WG consensus behind this document? Does it represent t= he strong concurrence of a few individuals, with others being silent, or do= es the WG as a whole understand and agree with it? The working group has consensus to publish this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discont= ent? If so, please summarise the areas of conflict in separate email messag= es to the Responsible Area Director. (It should be in a separate email beca= use this questionnaire is publicly available.) No appeal or extreme discontent has been raised. (11) Identify any ID nits the Document Shepherd has found in this document.= (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).= Boilerplate checks are not enough; this check needs to be thorough. The shepherd has checked the nits. The shepherd has not verified the exampl= es for correctness. (12) Describe how the document meets any required formal review criteria, s= uch as the MIB Doctor, media type, and URI type reviews. The document does not require a formal review even though it contains JSON-= based examples. (13) Have all references within this document been identified as either nor= mative or informative? Yes. (14) Are there normative references to documents that are not ready for adv= ancement or are otherwise in an unclear state? If such normative references= exist, what is the plan for their completion? There are various JOSE documents that have not been published as RFCs yet. = As such, this document cannot be published before the respective JOSE docum= ents are finalized. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the L= ast Call procedure. The document contains a reference to [ECMAScript] Ecma International, "ECMAScript Language Specification, 5.1 Edition", ECMA 262, June 2011. which might require a downref. RFC 6755 is also a downref. (16) Will publication of this document change the status of any existing RF= Cs? Are those RFCs listed on the title page header, listed in the abstract,= and discussed in the introduction? If the RFCs are not listed in the Abstr= act and Introduction, explain why, and point to the part of the document wh= ere the relationship of this document to the other RFCs is discussed. If th= is information is not in the document, explain why the WG considers it unne= cessary. The publication of this document does not change the status of other RFCs. (17) Describe the Document Shepherd's review of the IANA considerations sec= tion, especially with regard to its consistency with the body of the docume= nt. Confirm that all protocol extensions that the document makes are associ= ated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. C= onfirm that newly created IANA registries include a detailed specification = of the initial contents for the registry, that allocations procedures for f= uture registrations are defined, and a reasonable name for the new registry= has been suggested (see RFC 5226). The document creates a new registry for JWT claims and populates this regis= try with values. It also registers values into two existing registries, namely into * the RFC 6755 created OAuth URN registry, and * the media type registry (18) List any new IANA registries that require Expert Review for future all= ocations. Provide any public guidance that the IESG would find useful in se= lecting the IANA Experts for these new registries. The newly created JWT claims registry requires expert review for future all= ocations. Guidance is given in the document. The document shepherd volunteers to become an expert review. (19) Describe reviews and automated checks performed by the Document Shephe= rd to validate sections of the document written in a formal language, such = as XML code, BNF rules, MIB definitions, etc. There are examples in the document that use a JSON-based encoding. The docu= ment shepherd has reviewed those examples but has not verified the correctn= ess of the cryptographic operations. From nobody Thu May 8 12:26:00 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DB91A00C3; Thu, 8 May 2014 12:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 HH2mzpy2tXLQ; Thu, 8 May 2014 12:25:49 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7311C1A00F2; Thu, 8 May 2014 12:25:49 -0700 (PDT) Received: from [192.168.10.136] ([64.71.18.60]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MKpvc-1WiTwq0t4i-0004Ch; Thu, 08 May 2014 21:25:41 +0200 Message-ID: <536BDA2E.4070907@gmx.net> Date: Thu, 08 May 2014 21:25:34 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Kathleen Moriarty , ext The IESG X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="n1j8QsXF22TfdHSKeAsbewokcBda0W1qL" X-Provags-ID: V03:K0:0cSMPzIhSg8vi3P9ZV8TrJKmrI/UztprvP9W6J0LD4dY8he9U4e 0VcPPfdupQhwgiG7smMQDDXvHv5KaJRfo2tTcbhzTpjaoPZwtrXZOUnil4lCemxgBHiS7P/ YMqGhv+uTXF5ALkeomx7nYSkWSVfUKzLEsjWsaaEzpx4ydzWI3qx4ZnhLpaiDb/ERKzLgO6 7ESkH77nQCExvHZ+T0NVw== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/MAK4k2Erkhdgn-T5V4ApmICehEQ Cc: Derek Atkins , "oauth@ietf.org" Subject: [OAUTH-WG] Shepherd Writeups for JWT, OAuth Assertions, SAML Assertion Profile and JWT Assertion Profile X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 19:25:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --n1j8QsXF22TfdHSKeAsbewokcBda0W1qL Content-Type: multipart/mixed; boundary="------------030301010203090908010907" This is a multi-part message in MIME format. --------------030301010203090908010907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Kathleen, Dear IESG Secretary, as a document shepherd I would like to bring four documents from the OAuth working group to the attention of the IESG: - draft-ietf-oauth-json-web-token-20 - draft-ietf-oauth-assertions-16=09 - draft-ietf-oauth-jwt-bearer-09=09 - draft-ietf-oauth-saml2-bearer-20=09 Please find the write-ups attached to this mail. Ciao Hannes --------------030301010203090908010907 Content-Type: text/plain; charset=UTF-8; name="Writeup_OAuth_Assertion.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Writeup_OAuth_Assertion.txt" Writeup for "Assertion Framework for OAuth 2.0 Client Authentication and = Authorization Grants" (1) What type of RFC is being requested (BCP, Proposed Standard, Internet= Standard, Informational, Experimental, or Historic)? Why is this the pro= per type of RFC? Is this type of RFC indicated in the title page header? The RFC type is 'Standards Track' and the type is indicated in the title = page. Although the document is architectural in nature it is the umbrella= document for two other 'Standards Track' specifications that instantiate= this document for use with SAML assertions and JSON Web Tokens.=20 (2) The IESG approval announcement includes a Document Announcement Write= -Up. Please provide such a Document Announcement Write-Up. Recent example= s can be found in the "Action" announcements for approved documents. The = approval announcement contains the following sections: Technical Summary: This specification provides a framework for the use of assertions with OA= uth 2.0 in the form of a new client authentication mechanism and a new au= thorization grant type. Mechanisms are specified for transporting asserti= ons during interactions with a token endpoint, as well as general process= ing rules. The intent of this specification is to provide a common framework for OAu= th 2.0 to interwork with other identity systems using assertions, and to = provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and proc= essing rules. In order to be implementable, companion specifications are = necessary to provide the corresponding concrete instantiations.=20 Working Group Summary: Was there anything in WG process that is worth noting? For example, was t= here controversy about particular points or were there decisions where th= e consensus was particularly rough? This document has been submitted to the IESG before and was returned to t= he working group due to interoperability concerns. The working group has = discussed those concerns and has worked on several iterations of the docu= ment to reduce the amount of optional functionality.=20 Document Quality: The working group decided to separate the framework for assertion handlin= g from instance documents supporting SAML assertion and JSON-based encode= d tokens. Readers who want to implement the functionality also need to co= nsult one of the extension documents.=20 Personnel: The document shepherd is Hannes Tschofenig and the responsible area direc= tor is Kathleen Moriarty.=20 (3) Briefly describe the review of this document that was performed by th= e Document Shepherd. If this version of the document is not ready for pub= lication, please explain why the document is being forwarded to the IESG.= The draft authors believe that this document is ready for publication. Th= e document has received review comments from working group members, the O= Auth working group chairs, and from the IESG. These review comments have = been taken into account.=20 (4) Does the document Shepherd have any concerns about the depth or bread= th of the reviews that have been performed? This document has gotten feedback from the working group and given the fo= cused use cases it has received adequate review.=20 (5) Do portions of the document need review from a particular or from bro= ader perspective, e.g., security, operational complexity, AAA, DNS, DHCP,= XML, or internationalization? If so, describe the review that took place= =2E Since the OAuth working group develops security protocols any feedback fr= om the security community is always appreciated.=20 (6) Describe any specific concerns or issues that the Document Shepherd h= as with this document that the Responsible Area Director and/or the IESG = should be aware of? For example, perhaps he or she is uncomfortable with = certain parts of the document, or has concerns whether there really is a = need for it. In any event, if the WG has discussed those issues and has i= ndicated that it still wishes to advance the document, detail those conce= rns here. Although the document shepherd had concerns earlier with the document, th= ey have been addressed in the meanwhile.=20 (7) Has each author confirmed that any and all appropriate IPR disclosure= s required for full conformance with the provisions of BCP 78 and BCP 79 = have already been filed. If not, explain why? Yes, the authors (Chuck Mortimore , Brian Camp= bell , Mike Jones , and Yaron Y. Goland ) have confirmed that they = are not aware of any IPRs.=20 (8) Has an IPR disclosure been filed that references this document? If so= , summarize any WG discussion and conclusion regarding the IPR disclosure= s. No IPR disclosures have been filed.=20 (9) How solid is the WG consensus behind this document? Does it represent= the strong concurrence of a few individuals, with others being silent, o= r does the WG as a whole understand and agree with it? The working group has consensus to publish this document.=20 (10) Has anyone threatened an appeal or otherwise indicated extreme disco= ntent? If so, please summarise the areas of conflict in separate email me= ssages to the Responsible Area Director. (It should be in a separate emai= l because this questionnaire is publicly available.) No appeal or extreme discontent has been raised.=20 (11) Identify any ID nits the Document Shepherd has found in this documen= t. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checkli= st). Boilerplate checks are not enough; this check needs to be thorough. The shepherd has checked the nits.=20 (12) Describe how the document meets any required formal review criteria,= such as the MIB Doctor, media type, and URI type reviews. There is no such review necessary.=20 (13) Have all references within this document been identified as either n= ormative or informative? Yes.=20 (14) Are there normative references to documents that are not ready for a= dvancement or are otherwise in an unclear state? If such normative refere= nces exist, what is the plan for their completion? Yes.=20 (15) Are there downward normative references references (see RFC 3967)? I= f so, list these downward references to support the Area Director in the = Last Call procedure. No, there is no need for a downref.=20 (16) Will publication of this document change the status of any existing = RFCs? Are those RFCs listed on the title page header, listed in the abstr= act, and discussed in the introduction? If the RFCs are not listed in the= Abstract and Introduction, explain why, and point to the part of the doc= ument where the relationship of this document to the other RFCs is discus= sed. If this information is not in the document, explain why the WG consi= ders it unnecessary. The publication of this document does not change the status of other RFCs= =2E=20 (17) Describe the Document Shepherd's review of the IANA considerations s= ection, especially with regard to its consistency with the body of the do= cument. Confirm that all protocol extensions that the document makes are = associated with the appropriate reservations in IANA registries. Confirm = that any referenced IANA registries have been clearly identified. Confirm= that newly created IANA registries include a detailed specification of t= he initial contents for the registry, that allocations procedures for fut= ure registrations are defined, and a reasonable name for the new registry= has been suggested (see RFC 5226). The document adds three values to an existing registry established with R= FC 6749.=20 (18) List any new IANA registries that require Expert Review for future a= llocations. Provide any public guidance that the IESG would find useful i= n selecting the IANA Experts for these new registries. The document only adds entries to existing registries and does not define= any new registries.=20 (19) Describe reviews and automated checks performed by the Document Shep= herd to validate sections of the document written in a formal language, s= uch as XML code, BNF rules, MIB definitions, etc. There are only snippets of message exchanges used in the examples; no pse= udo code is contained in the document that requires validation.=20 =20 --------------030301010203090908010907 Content-Type: text/plain; charset=UTF-8; name="Writeup_OAuth_JWT.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Writeup_OAuth_JWT.txt" Writeup for "JSON Web Token (JWT)" (1) What type of RFC is being requested (BCP, Proposed Standard, Internet= Standard, Informational, Experimental, or Historic)? Why is this the pro= per type of RFC? Is this type of RFC indicated in the title page header? The RFC type is 'Standards Track' and the type is indicated in the title = page. This document defines the syntax and semantic of information elemen= ts.=20 =20 (2) The IESG approval announcement includes a Document Announcement Write= -Up. Please provide such a Document Announcement Write-Up. Recent example= s can be found in the "Action" announcements for approved documents. The = approval announcement contains the following sections: Technical Summary: JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. =20 Working Group Summary: Was there anything in WG process that is worth noting? For example, was t= here controversy about particular points or were there decisions where th= e consensus was particularly rough? This document was uncontroversial. It defines a standard JSON-based secur= ity token format, increasing interoperability both among OAuth deployment= s using it and in other application contexts as well. (ID tokens are spec= ified in http://openid.net/specs/openid-connect-core-1_0.html#IDToken) Document Quality: This document has gone through many iterations and has received substanti= al feedback.=20 A substantial number of implementations exist, as documented at=20 http://openid.net/developers/libraries/#jwt (scroll down to the 'JWT/JWS/JWE/JWK/JWA Implementations' section) An Excel document providing additional details can be found here:=20 http://www.oauth-v2.org/wp-content/uploads/2014/04/JWT-Implementations.xl= sx Personnel: The document shepherd is Hannes Tschofenig and the responsible area direc= tor is Kathleen Moriarty.=20 (3) Briefly describe the review of this document that was performed by th= e Document Shepherd. If this version of the document is not ready for pub= lication, please explain why the document is being forwarded to the IESG.= The document is ready for publication. The document has received review c= omments from working group members, and from the OAuth working group chai= rs. Implementations exist and they have tested for interoperability as pa= rt of the OpenID Connect interop events.=20 (4) Does the document Shepherd have any concerns about the depth or bread= th of the reviews that have been performed? This document has gotten enough feedback from the working group.=20 (5) Do portions of the document need review from a particular or from bro= ader perspective, e.g., security, operational complexity, AAA, DNS, DHCP,= XML, or internationalization? If so, describe the review that took place= =2E Since the OAuth working group develops security protocols any feedback fr= om the security community is always appreciated.=20 The JWT document heavily depends on the work in the JOSE working group si= nce it re-uses the JWE and the JWS specifications.=20 (6) Describe any specific concerns or issues that the Document Shepherd h= as with this document that the Responsible Area Director and/or the IESG = should be aware of? For example, perhaps he or she is uncomfortable with = certain parts of the document, or has concerns whether there really is a = need for it. In any event, if the WG has discussed those issues and has i= ndicated that it still wishes to advance the document, detail those conce= rns here. The shepherd has no concerns with this document.=20 (7) Has each author confirmed that any and all appropriate IPR disclosure= s required for full conformance with the provisions of BCP 78 and BCP 79 = have already been filed. If not, explain why? The authors have confirmed that they do not have or that they are not awa= re of any IPR.=20 Mike Jones: http://www.ietf.org/mail-archive/web/oauth/current/msg12753.h= tml Nat Sakimura: http://www.ietf.org/mail-archive/web/oauth/current/msg12747= =2Ehtml John Bradley: http://www.ietf.org/mail-archive/web/oauth/current/msg12671= =2Ehtml=20 (8) Has an IPR disclosure been filed that references this document? If so= , summarize any WG discussion and conclusion regarding the IPR disclosure= s. Two IPRs have been filed for the JWT specification this document relies o= n, see http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&i= d=3Ddraft-ietf-oauth-json-web-token=20 There was no discussion regarding those two IPRs on the mailing list.=20 (9) How solid is the WG consensus behind this document? Does it represent= the strong concurrence of a few individuals, with others being silent, o= r does the WG as a whole understand and agree with it? The working group has consensus to publish this document.=20 (10) Has anyone threatened an appeal or otherwise indicated extreme disco= ntent? If so, please summarise the areas of conflict in separate email me= ssages to the Responsible Area Director. (It should be in a separate emai= l because this questionnaire is publicly available.) No appeal or extreme discontent has been raised.=20 (11) Identify any ID nits the Document Shepherd has found in this documen= t. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checkli= st). Boilerplate checks are not enough; this check needs to be thorough. The shepherd has checked the nits. The shepherd has not verified the exam= ples for correctness.=20 (12) Describe how the document meets any required formal review criteria,= such as the MIB Doctor, media type, and URI type reviews. The document does not require a formal review even though it contains JSO= N-based examples.=20 (13) Have all references within this document been identified as either n= ormative or informative? Yes.=20 (14) Are there normative references to documents that are not ready for a= dvancement or are otherwise in an unclear state? If such normative refere= nces exist, what is the plan for their completion? There are various JOSE documents that have not been published as RFCs yet= =2E As such, this document cannot be published before the respective JOSE= documents are finalized.=20 (15) Are there downward normative references references (see RFC 3967)? I= f so, list these downward references to support the Area Director in the = Last Call procedure. RFC 6755 is a necessary downref.=20 (16) Will publication of this document change the status of any existing = RFCs? Are those RFCs listed on the title page header, listed in the abstr= act, and discussed in the introduction? If the RFCs are not listed in the= Abstract and Introduction, explain why, and point to the part of the doc= ument where the relationship of this document to the other RFCs is discus= sed. If this information is not in the document, explain why the WG consi= ders it unnecessary. The publication of this document does not change the status of other RFCs= =2E=20 (17) Describe the Document Shepherd's review of the IANA considerations s= ection, especially with regard to its consistency with the body of the do= cument. Confirm that all protocol extensions that the document makes are = associated with the appropriate reservations in IANA registries. Confirm = that any referenced IANA registries have been clearly identified. Confirm= that newly created IANA registries include a detailed specification of t= he initial contents for the registry, that allocations procedures for fut= ure registrations are defined, and a reasonable name for the new registry= has been suggested (see RFC 5226). The document creates a new registry for JWT claims and populates this reg= istry with values.=20 It also registers values into two existing registries, namely into=20 * the RFC 6755 created OAuth URN registry, and=20 * the media type registry=20 (18) List any new IANA registries that require Expert Review for future a= llocations. Provide any public guidance that the IESG would find useful i= n selecting the IANA Experts for these new registries. The newly created JWT claims registry requires expert review for future a= llocations. Guidance is given in the document.=20 The document shepherd and the author Michael Jones both volunteer to beco= me expert reviewers. Note that the document recommends that multiple exp= ert reviewers be appointed, with the following text (which also appears i= n the JOSE documents): " It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly-informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert should defer to the judgment of the other Expert(s). " =20 (19) Describe reviews and automated checks performed by the Document Shep= herd to validate sections of the document written in a formal language, s= uch as XML code, BNF rules, MIB definitions, etc. There are examples in the document that use a JSON-based encoding. The do= cument shepherd has reviewed those examples and verified them for correct= ness.=20 --------------030301010203090908010907 Content-Type: text/plain; charset=UTF-8; name="Writeup_OAuth_JWT-Assertion-Profile.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Writeup_OAuth_JWT-Assertion-Profile.txt" Writeup for "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentica= tion and Authorization Grants" (1) What type of RFC is being requested (BCP, Proposed Standard, Internet= Standard, Informational, Experimental, or Historic)? Why is this the pro= per type of RFC? Is this type of RFC indicated in the title page header? The RFC type is 'Standards Track' and the type is indicated in the title = page. This document defines an instantiation for the OAuth assertion fram= ework using JSON Web Tokens. =20 (2) The IESG approval announcement includes a Document Announcement Write= -Up. Please provide such a Document Announcement Write-Up. Recent example= s can be found in the "Action" announcements for approved documents. The = approval announcement contains the following sections: Technical Summary: This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. =20 Working Group Summary: Was there anything in WG process that is worth noting? For example, was t= here controversy about particular points or were there decisions where th= e consensus was particularly rough? This document belongs to the OAuth assertion document bundle consisting o= f the abstract OAuth assertion framework, the SAML assertion profile, and= the JWT assertion profile (this document). Due to the use of the JSON-ba= sed encoding of the assertion it also relies on the work in the JOSE work= ing group (such as JWE/JWS) indirectly through the use of the JWT. This d= ocument has intentionally been kept in sync with the SAML-based version. = Document Quality: This document has gone through many iterations and has received substanti= al feedback.=20 The following implementations are known: * Microsoft Azure Active Directory: http://azure.microsoft.com/en-us/ser= vices/active-directory/ * Google Service Account: https://developers.google.com/accounts/docs/OAu= th2ServiceAccount * Salesforce: https://help.salesforce.com/HTViewHelpDoc?id=3Dremoteaccess= _oauth_jwt_flow.htm&language=3Den_US =20 * Deutsche Telekom * Adobe * PingIdentity * MITREid Connect * Oracle=20 It has to be noted that availability of many JWT implementations will hav= e a positive impact on the future deployment of the JWT bearer assertion = since the development effort is significantly reduced.=20 =20 Personnel: The document shepherd is Hannes Tschofenig and the responsible area direc= tor is Kathleen Moriarty.=20 (3) Briefly describe the review of this document that was performed by th= e Document Shepherd. If this version of the document is not ready for pub= lication, please explain why the document is being forwarded to the IESG.= The document is ready for publication. The document has received review c= omments from working group members, and from the OAuth working group chai= rs. These review comments have been taken into account.=20 (4) Does the document Shepherd have any concerns about the depth or bread= th of the reviews that have been performed? This document has gotten feedback from the working group and given the fo= cused use cases it has received adequate review.=20 (5) Do portions of the document need review from a particular or from bro= ader perspective, e.g., security, operational complexity, AAA, DNS, DHCP,= XML, or internationalization? If so, describe the review that took place= =2E Since the OAuth working group develops security protocols any feedback fr= om the security community is always appreciated.=20 (6) Describe any specific concerns or issues that the Document Shepherd h= as with this document that the Responsible Area Director and/or the IESG = should be aware of? For example, perhaps he or she is uncomfortable with = certain parts of the document, or has concerns whether there really is a = need for it. In any event, if the WG has discussed those issues and has i= ndicated that it still wishes to advance the document, detail those conce= rns here. The shepherd has no concerns with this document.=20 (7) Has each author confirmed that any and all appropriate IPR disclosure= s required for full conformance with the provisions of BCP 78 and BCP 79 = have already been filed. If not, explain why? The authors have confirmed that they do not have or that they are not awa= re of any IPR.=20 Mike Jones: http://www.ietf.org/mail-archive/web/oauth/current/msg12640.h= tml Brian Campbell: http://www.ietf.org/mail-archive/web/oauth/current/msg126= 53.html Chuck Mortimore: http://www.ietf.org/mail-archive/web/oauth/current/msg12= 674.html (8) Has an IPR disclosure been filed that references this document? If so= , summarize any WG discussion and conclusion regarding the IPR disclosure= s. No IPR disclosures have been filed on this document. However, two IPRs ha= ve been filed for the JWT specification this document relies on, see http= ://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraft-i= etf-oauth-json-web-token=20 (9) How solid is the WG consensus behind this document? Does it represent= the strong concurrence of a few individuals, with others being silent, o= r does the WG as a whole understand and agree with it? The working group has consensus to publish this document.=20 (10) Has anyone threatened an appeal or otherwise indicated extreme disco= ntent? If so, please summarise the areas of conflict in separate email me= ssages to the Responsible Area Director. (It should be in a separate emai= l because this questionnaire is publicly available.) No appeal or extreme discontent has been raised.=20 (11) Identify any ID nits the Document Shepherd has found in this documen= t. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checkli= st). Boilerplate checks are not enough; this check needs to be thorough. The shepherd has checked the nits.=20 (12) Describe how the document meets any required formal review criteria,= such as the MIB Doctor, media type, and URI type reviews. There is no such review necessary.=20 (13) Have all references within this document been identified as either n= ormative or informative? Yes.=20 (14) Are there normative references to documents that are not ready for a= dvancement or are otherwise in an unclear state? If such normative refere= nces exist, what is the plan for their completion? Yes. There are normative references to two other OAuth documents, namely = draft-ietf-oauth-assertions and draft-ietf-oauth-json-web-token. The latt= er document has a dependency on documents in the JOSE working group. All = documents will be submitted to the IESG roughly at the same time.=20 (15) Are there downward normative references references (see RFC 3967)? I= f so, list these downward references to support the Area Director in the = Last Call procedure. RFC 6755 defines the urn:ietf:params:oauth URN and is an Informational RF= C. A downref is required.=20 (16) Will publication of this document change the status of any existing = RFCs? Are those RFCs listed on the title page header, listed in the abstr= act, and discussed in the introduction? If the RFCs are not listed in the= Abstract and Introduction, explain why, and point to the part of the doc= ument where the relationship of this document to the other RFCs is discus= sed. If this information is not in the document, explain why the WG consi= ders it unnecessary. The publication of this document does not change the status of other RFCs= =2E=20 (17) Describe the Document Shepherd's review of the IANA considerations s= ection, especially with regard to its consistency with the body of the do= cument. Confirm that all protocol extensions that the document makes are = associated with the appropriate reservations in IANA registries. Confirm = that any referenced IANA registries have been clearly identified. Confirm= that newly created IANA registries include a detailed specification of t= he initial contents for the registry, that allocations procedures for fut= ure registrations are defined, and a reasonable name for the new registry= has been suggested (see RFC 5226). The document registers two sub-namespaces to the urn:ietf:params:oauth UR= N established with RFC 6755.=20 (18) List any new IANA registries that require Expert Review for future a= llocations. Provide any public guidance that the IESG would find useful i= n selecting the IANA Experts for these new registries. The document only adds entries to existing registries and does not define= any new registries.=20 (19) Describe reviews and automated checks performed by the Document Shep= herd to validate sections of the document written in a formal language, s= uch as XML code, BNF rules, MIB definitions, etc. There are only snippets of message exchanges and JWT assertion structures= , which are based on JSON, used in the examples. There is no pseudo code = contained in the document that requires validation.=20 --------------030301010203090908010907 Content-Type: text/plain; charset=UTF-8; name="Writeup_OAuth_SAML_Profile.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Writeup_OAuth_SAML_Profile.txt" Writeup for "SAML 2.0 Profile for OAuth 2.0 Client Authentication and Aut= horization Grants" (1) What type of RFC is being requested (BCP, Proposed Standard, Internet= Standard, Informational, Experimental, or Historic)? Why is this the pro= per type of RFC? Is this type of RFC indicated in the title page header? The RFC type is 'Standards Track' and the type is indicated in the title = page. This document defines one protocol instantiation for the OAuth asse= rtion framework.=20 =20 (2) The IESG approval announcement includes a Document Announcement Write= -Up. Please provide such a Document Announcement Write-Up. Recent example= s can be found in the "Action" announcements for approved documents. The = approval announcement contains the following sections: Technical Summary: This specification defines the use of a SAML 2.0 Bearer Assertion as a me= ans for requesting an OAuth 2.0 access token as well as for use as a mean= s of client authentication. =20 Working Group Summary: Was there anything in WG process that is worth noting? For example, was t= here controversy about particular points or were there decisions where th= e consensus was particularly rough? The OAuth assertion framework, which this document instantiates, has been= submitted to the IESG before and was returned to the working group due t= o interoperability concerns. The working group has discussed those concer= ns and has worked on several iterations of the document to reduce the num= ber of optional functionality. Along with the changes to the assertion fr= amework document changes have been made to this document as well. Document Quality: The working group decided to separate the framework for assertion handlin= g from instance documents. This document is one of those instance documen= ts, which illustrates the use of SAML assertions with OAuth 2.0. Readers = who want to implement the SAML assertion profile are required to also rea= d the corresponding framework document.=20 The document has gone through many iterations and has received substantia= l feedback.=20 Implementations of the specification exist:=20 * Salesforce implementation: https://help.salesforce.com/HTViewHelpDoc?i= d=3Dremoteaccess_oauth_SAML_bearer_flow.htm&language=3Den_US=20 * PingIdentity implementation: http://documentation.pingidentity.com/dis= play/PF71/SAML+2.0+Profile+for+OAuth+2.0+Authorization+Grants http://documentation.pingidentity.com/display/PF71/STS+OAuth+Integration =20 Other implementations, according to a Google search, also seem to exist, = such as from SAP http://help.sap.com/saphelp_nw74/helpdata/en/12/41087770= d9441682e3e02958997846/content.htm =20 Personnel: The document shepherd is Hannes Tschofenig and the responsible area direc= tor is Kathleen Moriarty.=20 (3) Briefly describe the review of this document that was performed by th= e Document Shepherd. If this version of the document is not ready for pub= lication, please explain why the document is being forwarded to the IESG.= The draft authors believe that this document is ready for publication. Th= e document has received review comments from working group members, the O= Auth working group chairs, and from the IESG. These review comments have = been taken into account.=20 (4) Does the document Shepherd have any concerns about the depth or bread= th of the reviews that have been performed? This document has gotten feedback from the working group and given the fo= cused use cases it has received adequate review.=20 (5) Do portions of the document need review from a particular or from bro= ader perspective, e.g., security, operational complexity, AAA, DNS, DHCP,= XML, or internationalization? If so, describe the review that took place= =2E Since the OAuth working group develops security protocols any feedback fr= om the security community is always appreciated.=20 (6) Describe any specific concerns or issues that the Document Shepherd h= as with this document that the Responsible Area Director and/or the IESG = should be aware of? For example, perhaps he or she is uncomfortable with = certain parts of the document, or has concerns whether there really is a = need for it. In any event, if the WG has discussed those issues and has i= ndicated that it still wishes to advance the document, detail those conce= rns here. Although the document shepherd had concerns earlier with the document, th= ey have been addressed in the meanwhile.=20 (7) Has each author confirmed that any and all appropriate IPR disclosure= s required for full conformance with the provisions of BCP 78 and BCP 79 = have already been filed. If not, explain why? Yes, the authors (Chuck Mortimore , Brian Camp= bell , and Mike Jones ) ha= ve confirmed that they are not aware of any IPRs.=20 (8) Has an IPR disclosure been filed that references this document? If so= , summarize any WG discussion and conclusion regarding the IPR disclosure= s. No IPR disclosures have been filed.=20 (9) How solid is the WG consensus behind this document? Does it represent= the strong concurrence of a few individuals, with others being silent, o= r does the WG as a whole understand and agree with it? The working group has consensus to publish this document.=20 (10) Has anyone threatened an appeal or otherwise indicated extreme disco= ntent? If so, please summarise the areas of conflict in separate email me= ssages to the Responsible Area Director. (It should be in a separate emai= l because this questionnaire is publicly available.) No appeal or extreme discontent has been raised.=20 (11) Identify any ID nits the Document Shepherd has found in this documen= t. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checkli= st). Boilerplate checks are not enough; this check needs to be thorough. The shepherd has checked the nits.=20 (12) Describe how the document meets any required formal review criteria,= such as the MIB Doctor, media type, and URI type reviews. There is no such review necessary.=20 (13) Have all references within this document been identified as either n= ormative or informative? Yes.=20 (14) Are there normative references to documents that are not ready for a= dvancement or are otherwise in an unclear state? If such normative refere= nces exist, what is the plan for their completion? Yes.=20 (15) Are there downward normative references references (see RFC 3967)? I= f so, list these downward references to support the Area Director in the = Last Call procedure. There are the following dependencies:=20 * I-D.ietf-oauth-assertions: We submitted this document to the IESG toget= her with this document. I-D.ietf-oauth-assertions is, however, a Standard= s Track document and no downref is needed.=20 * RFC 6755 defines the urn:ietf:params:oauth URN and is an Informational = RFC. A downref is required.=20 * This document also references an OASIS standard, the SAML specification= : OASIS.saml-core-2.0-os (16) Will publication of this document change the status of any existing = RFCs? Are those RFCs listed on the title page header, listed in the abstr= act, and discussed in the introduction? If the RFCs are not listed in the= Abstract and Introduction, explain why, and point to the part of the doc= ument where the relationship of this document to the other RFCs is discus= sed. If this information is not in the document, explain why the WG consi= ders it unnecessary. The publication of this document does not change the status of other RFCs= =2E=20 (17) Describe the Document Shepherd's review of the IANA considerations s= ection, especially with regard to its consistency with the body of the do= cument. Confirm that all protocol extensions that the document makes are = associated with the appropriate reservations in IANA registries. Confirm = that any referenced IANA registries have been clearly identified. Confirm= that newly created IANA registries include a detailed specification of t= he initial contents for the registry, that allocations procedures for fut= ure registrations are defined, and a reasonable name for the new registry= has been suggested (see RFC 5226). The document registers two sub-namespaces (URNs) to the urn:ietf:params:o= auth URN established with RFC 6755.=20 (18) List any new IANA registries that require Expert Review for future a= llocations. Provide any public guidance that the IESG would find useful i= n selecting the IANA Experts for these new registries. The document only adds entries to existing registries and does not define= any new registries.=20 (19) Describe reviews and automated checks performed by the Document Shep= herd to validate sections of the document written in a formal language, s= uch as XML code, BNF rules, MIB definitions, etc. There are only snippets of message exchanges and SAML assertion structure= s, which are based on XML, used in the examples. There is no pseudo code = contained in the document that requires validation.=20 The assertion example is meant as an illustration, it is well formed XML = but is not schema valid because of the "[...omitted for brevity...]" shor= thand in the signature element.=20 --------------030301010203090908010907-- --n1j8QsXF22TfdHSKeAsbewokcBda0W1qL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTa9ovAAoJEGhJURNOOiAtGm4H/iDnNVL9z7cdU7asDOZ4GSuz e0hqlmfQtZaE88rYUocR1J8o6oGCzjplux73ryriGhCVbdOzdH8Dar56Ge0OhEQR TzGfa4lyY3wqLOjhL4mCk21eAjSgELXdU/Y3rRMNaniCqY7iPnkpl9aq42Mv3/ti gknqVuXf/GE24TFIPsuC1WZ24O/Vxes/vjLvVlkZNZQ+2WGiMMYThzZdiEnHcnni 31mlYnBt2x/grz1IlW71K12LEfvPKVe0BVEILJlu1HY+WEPpYZ7/o1PxuoSWeO+Y YOUkHEMqPxOZsO9BapSDEnoHDJeywEyr80xxVGBa4uQ+94YsZ0DiyJWD3zmaibw= =Rdug -----END PGP SIGNATURE----- --n1j8QsXF22TfdHSKeAsbewokcBda0W1qL-- From nobody Thu May 8 14:04:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12401A0151 for ; Thu, 8 May 2014 14:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 dvZ4zM9IgiIR for ; Thu, 8 May 2014 14:04:20 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 11D2D1A0158 for ; Thu, 8 May 2014 14:04:08 -0700 (PDT) Received: from [192.168.10.137] ([64.71.18.60]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MSdNs-1WJ6qk38p2-00RUtk for ; Thu, 08 May 2014 23:04:03 +0200 Message-ID: <536BF140.5070106@gmx.net> Date: Thu, 08 May 2014 23:04:00 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gOj8Fx7wwv3TIa2nE6AHCXAO9e8vqkR7h" X-Provags-ID: V03:K0:OVYIGk2ykG+3G0xDMEmRYEG9hsWD3pnrOlb0tgALah7L9YH0MW8 px7C89rDazgQ+9kukCscyOsEJ2Qvz+le198sjnz7exe8+4qsEB8JrchM2tTjZkv9tMeNTWm vmvoSd7sYoMb+tJpVCoPjDZMZmBQtDbiQote1QTzbxZTsVqIDJXq1wk0zHmnqD7tmqx3Il8 pglxth9H2bNx4OpGOCzwg== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Jb99XHlMMlqdL9n1gn5NxvR5Mxw Subject: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 21:04:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gOj8Fx7wwv3TIa2nE6AHCXAO9e8vqkR7h Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, you might have seen that we pushed the assertion documents and the JWT documents to the IESG today. We have also updated the milestones on the OAuth WG page. This means that we can plan to pick up new work in the group. We have sent a request to Kathleen to change the milestone for the OAuth security mechanisms to use the proof-of-possession terminology. We also expect an updated version of the dynamic client registration spec incorporating last call feedback within about 2 weeks. We would like you to think about adding the following milestones to the charter as part of the re-chartering effort: ----- Nov 2014 Submit 'Token introspection' to the IESG for consideration as a Proposed Standard Starting point: Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as a Proposed Standard Starting point: Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a Proposed Standard Starting point: ----- We also updated the charter text to reflect the current situation. Here is the proposed text: ----- Charter for Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user share his or her photo-sharing sites' long-term credential with the printing site. The OAuth 2.0 protocol suite encompasses * a protocol for obtaining access tokens from an authorization server with the resource owner's consent, * protocols for presenting these access tokens to resource server for access to a protected resource, * guidance for securely using OAuth 2.0, * the ability to revoke access tokens, * standardized format for security tokens encoded in a JSON format (JSON Web Token, JWT), * ways of using assertions with OAuth, and * a dynamic client registration protocol. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token, as well as work that remains to be completed on proof-of-possession and token exchange. The ongoing standardization effort within the OAuth working group will focus on enhancing interoperability and functionality of OAuth deployments, such as a standard for a token introspection service and standards for additional security of OAuth requests. ----- Feedback appreciated. Ciao Hannes & Derek --gOj8Fx7wwv3TIa2nE6AHCXAO9e8vqkR7h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTa/FAAAoJEGhJURNOOiAtfhwH/1LkQyA02FvJwVBdruMUNZZS b15wohj9HYIL2eS9RABL/2x02WZvX4yIPZgARF5nJj/xpvapTgg/CQwvuOby7mdS OKPzUhKTNkzOlYQYFSj68ucZL7YqjdRfkHzKCsfix7mgEV7aN2dunHC68AZuU17s wxxet0mPEB3wGzSzVgPAhxMjTu5XAxrTi5pgw8fwv/FdYbfcB1tekQ+O3/AgW6sB V5ep8pMux9mOElO3VYU+BmVEKln1JnVSlPIStXsc60v45UiZ6JTQjOKrXfwIpAiU Fp+OEkRhwED0hP3HWqudQ50Bwuju0Sj004e5l5veWOjdKV/krL1zYv1OsSzNZWU= =DpnR -----END PGP SIGNATURE----- --gOj8Fx7wwv3TIa2nE6AHCXAO9e8vqkR7h-- From nobody Thu May 8 14:21:25 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58FE1A0175 for ; Thu, 8 May 2014 14:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 RweNbOIMwSLG for ; Thu, 8 May 2014 14:21:16 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 790781A0170 for ; Thu, 8 May 2014 14:21:16 -0700 (PDT) Received: from [192.168.10.137] ([64.71.18.60]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MBVwM-1WaE1g0C3y-00AWLk for ; Thu, 08 May 2014 23:21:10 +0200 Message-ID: <536BF543.9030503@gmx.net> Date: Thu, 08 May 2014 23:21:07 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AOx2b0xtRuHHxdeACbhqCSTl5Td3MkaNf" X-Provags-ID: V03:K0:qmWfZW2Gue+RuhBjJfsZ+/PXp/yRnEySMzqTQs78y07irSbeGnq vXWaUVM1lP7ct0Bv2nNtq+txj6esNADnLb5zIZG5LndrfiSsbfvZhlRdtOvTXmjbS6VtMpC IeEK/daNhg3MH5H/WLbc71YhFwXBqyHB/Km9Oxy42F7OUGEIIv3wytOZh0MFJZFH5oDF4i7 UkE/bbmfCUnBIeJ+eOdqQ== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/KcMmtVbRK0X-6I2O-xkbLR5BMyg Subject: [OAUTH-WG] IIW OAuth PoP and SASL-OAuth Presentation Slides X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 21:21:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AOx2b0xtRuHHxdeACbhqCSTl5Td3MkaNf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, I attended the Internet Identity Workshop (IIW) this week and I gave two OAuth-focused presentations. I wanted to share my slides with the group. The first presentation was a status-update about the proof-of-possession work: http://www.tschofenig.priv.at/oauth/IETF-OAuth-PoP.pptx The second presentation was about the OAuth SASL document (developed in the KITTEN WG): http://www.tschofenig.priv.at/oauth/IETF-SASL-Kitten.pptx Ciao Hannes --AOx2b0xtRuHHxdeACbhqCSTl5Td3MkaNf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTa/VDAAoJEGhJURNOOiAtvQ0H/1LjbNawCdh72dR3J72x4qDf ckR6xuES5JYt+XttffK7WThiDsQYhUeporggMAJd+UbEYV+K3PqK/9K3YwHYEecC 0NaLRa3mT2bTu5+G2TPtRcOtP9/9zS5PfQdwiK3nfPt5FSTgUxqzxpCdqjX6nQWd qSRy2cfvjjb1rmhsz0srhGdkjNcBCloShHUPfESvtbO1op83485hT0De4s4TrN4B ZgdSH21Ynag9iWfz+A6/rFSpnOzcUlELzPnUhg2PLOiMUz/DeTtcDnpljnHcdjsz kaY+Df9n4oB6Z0X8MB10W+6/qxVLx0K3Zq94xhFmpCB8ZJZQXtSpozGV7STA3WM= =bVzz -----END PGP SIGNATURE----- --AOx2b0xtRuHHxdeACbhqCSTl5Td3MkaNf-- From nobody Thu May 8 16:22:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444A41A0185 for ; Thu, 8 May 2014 16:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 60D2qnqxeo58 for ; Thu, 8 May 2014 16:22:29 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 74C081A0173 for ; Thu, 8 May 2014 16:22:29 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s48NMOZV008212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 8 May 2014 23:22:24 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s48NMNI5008053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 8 May 2014 23:22:23 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s48NMN4l015827 for ; Thu, 8 May 2014 23:22:23 GMT Received: from [25.32.11.42] (/24.114.89.30) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 May 2014 16:22:22 -0700 References: <536BFA23.9020900@digitalbazaar.com> From: Phil Hunt Content-Type: multipart/alternative; boundary=Apple-Mail-FE2B3422-7A58-4D33-B697-F4E6C200EB9C X-Mailer: iPhone Mail (11D167) Message-Id: Date: Thu, 8 May 2014 16:22:16 -0700 To: OAuth WG Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/AfzGiIbL0fzD7793E41niS2oX9s Subject: [OAUTH-WG] Fwd: [http-auth] Review Request for third draft of "Signing HTTP Messages" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 23:22:31 -0000 --Apple-Mail-FE2B3422-7A58-4D33-B697-F4E6C200EB9C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable How does this compare with justin's draft? Phil Begin forwarded message: > From: Manu Sporny > Date: May 8, 2014 at 14:41:55 PDT > To: IETF HTTP Auth > Cc: Julian Reschke , Mark Nottingham , Web Payments CG > Subject: [http-auth] Review Request for third draft of "Signing HTTP Messa= ges" >=20 > After feedback from Mark Nottingham[1], Julian Reschke[2], folks in the > HTTP Auth WG, and people in the Web Payments CG, we've modified the HTTP > Signatures specification in the following ways: >=20 > 1. The specification has been renamed to "Signing HTTP Messages". > 2. The specification now covers both a signature-based Authorization > mechanism (client-to-server) as well as a general mechanism to sign > HTTP messages (client-to-server and server-to-client). > 3. A new "Signature" header has been introduced. > 4. The layout has been modified heavily to streamline the information > conveyed in the spec. > 5. New registries have been created for the algorithms referred to in > the specification. > 6. We're now more specific in the way certain canonicalizations are > performed. > 7. More examples have been added, including how to digitally sign > the body of an HTTP message. >=20 > The basic mechanism of generating the signatures has not changed (and > has been stable for over a year). >=20 > The newest spec can be found here: >=20 > http://tools.ietf.org/html/draft-cavage-http-signatures-02 >=20 > The diff is here: >=20 > http://tools.ietf.org/rfcdiff?url2=3Ddraft-cavage-http-signatures-02.txt >=20 > Matt, Yoav, Kathleen, if there are no show stopping review comments, I'd > like to push this spec onto the RFC track in the HTTP Auth WG, or > HTTPbis/2 WG. It'll be ready for a LC in a month or two. I realize that > HTTP Auth may be shutting down next month, so what's the next step to > get the HTTP Signatures spec further down the IETF RFC track? >=20 > -- manu >=20 > [1] http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0038.ht= ml > [2] http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0036.ht= ml >=20 > --=20 > Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) > Founder/CEO - Digital Bazaar, Inc. > blog: The Marathonic Dawn of Web Payments > http://manu.sporny.org/2014/dawn-of-web-payments/ >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth --Apple-Mail-FE2B3422-7A58-4D33-B697-F4E6C200EB9C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

How does this compare with justin's dr= aft?

Phil

Begin forwarded message:

From: Manu Sporny <msporny@digitalbazaar.com>
Date: May 8= , 2014 at 14:41:55 PDT
To: IETF HTTP Auth <http-auth@ietf.org>
Cc: Julian Reschke &l= t;julian.reschke@gmx.de>, Ma= rk Nottingham <mnot@mnot.net>, We= b Payments CG <public-webpay= ments@w3.org>
Subject: [http-auth] Review Request for th= ird draft of "Signing HTTP Messages"

After feedback from Mark Nottingham[1], Julian R= eschke[2], folks in the
HTTP Auth WG, and people in the Web P= ayments CG, we've modified the HTTP
Signatures specification= in the following ways:

1. The specificatio= n has been renamed to "Signing HTTP Messages".
2. The specif= ication now covers both a signature-based Authorization
&nb= sp; mechanism (client-to-server) as well as a general mechanism to sign=
  HTTP messages (client-to-server and server-to-= client).
3. A new "Signature" header has been introduced.
4. The layout has been modified heavily to streamline the info= rmation
  conveyed in the spec.
5= . New registries have been created for the algorithms referred to in<= br>   the specification.
6. We're now more s= pecific in the way certain canonicalizations are
 &nbs= p;performed.
7. More examples have been added, including how= to digitally sign
  the body of an HTTP message.=

The basic mechanism of generating the sign= atures has not changed (and
has been stable for over a year)= .

The newest spec can be found here:=

http://tools.ietf.org/html/draft-cavage-http-signature= s-02

The diff is here:
=
http://tools.ietf.org/rfcdiff?url2=3Ddraft-cavage-= http-signatures-02.txt

Matt, Yoav, Kath= leen, if there are no show stopping review comments, I'd
lik= e to push this spec onto the RFC track in the HTTP Auth WG, or
HTTPbis/2 WG. It'll be ready for a LC in a month or two. I realize that
HTTP Auth may be shutting down next month, so what's the next= step to
get the HTTP Signatures spec further down the IETF R= FC track?

-- manu
[1] http://lists.w3.org/Archives/Public/public-webpayments/= 2014Feb/0038.html
[2] http://lists.w3.org/Archi= ves/Public/public-webpayments/2014Feb/0036.html
<= br>--
Manu Sporny (skype: msporny, twitter: manusporn= y, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.o= rg/2014/dawn-of-web-payments/

_________= ______________________________________
http-auth mailing lis= t
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth
= --Apple-Mail-FE2B3422-7A58-4D33-B697-F4E6C200EB9C-- From nobody Thu May 8 20:47:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21771A01BB for ; Thu, 8 May 2014 20:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 84Kk4daTEirE for ; Thu, 8 May 2014 20:47:13 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 311DB1A01C2 for ; Thu, 8 May 2014 20:47:13 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s493l71D023460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 May 2014 03:47:08 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s493l7f4015053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 May 2014 03:47:07 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s493l6cu022742 for ; Fri, 9 May 2014 03:47:06 GMT Received: from [25.69.96.84] (/24.114.22.64) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 May 2014 20:47:05 -0700 References: From: Phil Hunt Content-Type: multipart/alternative; boundary=Apple-Mail-7302498F-6A7F-4231-9BBB-FE3D69DA09CC X-Mailer: iPhone Mail (11D167) Message-Id: <9378C75B-2146-4E8D-BDD6-B4F495C52B84@oracle.com> Date: Thu, 8 May 2014 20:47:01 -0700 To: OAuth WG Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TRqdDHmmlT1k2arO21FtvKb3hgc Subject: [OAUTH-WG] Fwd: HTTP protocol version in MAC signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 03:47:15 -0000 --Apple-Mail-7302498F-6A7F-4231-9BBB-FE3D69DA09CC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Fyi Phil Begin forwarded message: > From: Blair Strang > Date: May 8, 2014 at 18:47:58 PDT > Resent-To: hannes.tschofenig@gmx.net, jricher@mitre.org, phil.hunt@yahoo.c= om, wmills@yahoo-inc.com > To: draft-ietf-oauth-v2-http-mac@tools.ietf.org > Subject: HTTP protocol version in MAC signatures >=20 > Hi, >=20 > [Not sure if this is the right address to submit this feedback to] >=20 > Looking over http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05 se= ction 5.2. "MAC Input String", it seems that the HTTP request line is used v= erbatim during the construction of MAC tokens. >=20 > Since this includes the transport (HTTP/1.1 versus say HTTP/1.0) it seems t= hat HTTP proxies which run different protocol versions on each leg will brea= k signatures.=20 >=20 > I would recommend removing the HTTP version from the MAC. The transport is= inherently a "per hop" type of thing, while request signatures are conceptu= ally "end to end". >=20 > I am not aware of any specific security benefits derived from including th= e HTTP protocol version in the MAC input string. This may be why AWS version= 2 and AWS version 4 signatures do not include it. >=20 > Thanks and regards, >=20 > Blair. >=20 --Apple-Mail-7302498F-6A7F-4231-9BBB-FE3D69DA09CC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Fyi

Phil

Begin fo= rwarded message:

From: Bl= air Strang <blair.strang@covat= a.com>
Date: May 8, 2014 at 18:47:58 PDT
Resent-To: hannes.tschofenig@gmx.net, jricher@mitre.org, phil.hunt@yahoo.com, wmills@yahoo-inc.com
To: draft-ietf-oauth-v2-http-mac@tools.= ietf.org
Subject: HTTP protocol version in MAC signatures

Hi,

[Not sure if this is the right address to= submit this feedback to]

Looking over&n= bsp;h= ttp://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05 section 5= .2. "MAC Input String", it seems that the HTTP request line is used verbatim= during the construction of MAC tokens.

Since this includes the transport (= HTTP/1.1 versus say HTTP/1.0) it seems that HTTP proxies which run different= protocol versions on each leg will break signatures. 

I would recommend removing the HTTP version from the MAC. Th= e transport is inherently a "per hop" type of thing, while request signature= s are conceptually "end to end".

I am not aware of any specific security benefits derived fro= m including the HTTP protocol version in the MAC input string. This may be w= hy AWS version 2 and AWS version 4 signatures do not include it.

Thanks and regards,

    Blair.

= --Apple-Mail-7302498F-6A7F-4231-9BBB-FE3D69DA09CC-- From nobody Fri May 9 13:51:42 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58F11A00F4 for ; Fri, 9 May 2014 13:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 ykzbTgG61JHB for ; Fri, 9 May 2014 13:51:37 -0700 (PDT) Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id C644C1A00D8 for ; Fri, 9 May 2014 13:51:36 -0700 (PDT) Received: from mail-ie0-f178.google.com ([209.85.223.178]) (using TLSv1) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKU20/0wx8Lr2sib06KBH+LUj67gBFrRtq@postini.com; Fri, 09 May 2014 13:51:32 PDT Received: by mail-ie0-f178.google.com with SMTP id lx4so4423346iec.23 for ; Fri, 09 May 2014 13:51:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=7M1nH2K0RUG4FpuEuN+MRSgtQsHIyY8pjn5jZJwZ/Es=; b=DwNqTubrRvzTqPnlcUTVGKhONNkopFX2dg8zAw9PTIaUc4bh3f10BWD+Im4HppmgwJ bou3pwfO8pu9QVuhepZCFcw31zLZNqNeOoHMHqPwJjU2Fe0emEEyUUk4E7BfCRmHP2UF CTrLM/MYf+Nv0ktniFiGGy5hn229e7qZiV2J+W2CxrvEECzMPs+UNiR5/XKu37BnTyh3 bam8LS0lMuzHIPUPhe9M0YBRIssKaqfzBvXx0+4P+n2QELSRjIJWJV5hfy9yEPWyhFDV GFHEPvJlExi/6iXyDXSInk0/egsZ6xcr92gzxs+JWrVJD+rGizbuggRnPybkELUdt2z7 ILBQ== X-Gm-Message-State: ALoCoQm9Bu+KkOX/3Pfuc5+5kklkn/aAHw5m6+ZZAMALMQBMH478P43izSExJCGcHtLVo1Zp3M0PtATk3YoVxgAcwyg5pS9IISpDGvlZSlRc2V2AY5CgV5MEiulemp4NxEromAdZVssu X-Received: by 10.50.43.201 with SMTP id y9mr13698507igl.12.1399668691522; Fri, 09 May 2014 13:51:31 -0700 (PDT) X-Received: by 10.50.43.201 with SMTP id y9mr13698488igl.12.1399668691430; Fri, 09 May 2014 13:51:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Fri, 9 May 2014 13:51:01 -0700 (PDT) From: Brian Campbell Date: Fri, 9 May 2014 14:51:01 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=089e011825c0282dc904f8fdc379 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/VsDAkaCEGIp9-cmFJ0uvj4_yFgc Cc: John Bradley , Naveen Agarwal Subject: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 20:51:39 -0000 --089e011825c0282dc904f8fdc379 Content-Type: text/plain; charset=UTF-8 I notice that code_verifier is defined as "high entropy cryptographic random string of length less than 128 bytes" [1], which brought a few questions and comments to mind. So here goes: Talking about the length of a string in terms of bytes is always potentially confusing. Maybe characters would be an easier unit for people like me to wrap their little brains around? Why are we putting a length restriction on the code_verifier anyway? It seems like it'd be more appropriate to restrict the length of the code_challenge because that's the thing the AS will have to maintain somehow (store in a DB or memory or encrypt into the code). Am I missing something here? Let me also say that I hadn't looked at this document since its early days in draft -00 or -01 last summer but I like the changes and how it's been kept pretty simple for the common use-case while still allowing for crypto agility/extension. Nice work! [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 --089e011825c0282dc904f8fdc379 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I notice that code_verifier is defined as "high entro= py cryptographic random string of length less than 128 bytes"=C2=A0 [1= ], which brought a few questions and comments to mind. So here goes:
Talking about the length of a string in terms of bytes is always potential= ly confusing. Maybe characters would be an easier unit for people like me t= o wrap their little brains around?

Why are we putting a length restriction on the code_verifier anyway? It= seems like it'd be more appropriate to restrict the length of the code= _challenge because that's the thing the AS will have to maintain someho= w (store in a DB or memory or encrypt into the code). Am I missing somethin= g here?

Let me also say that I hadn't looked at this document since its ear= ly days in draft -00 or -01 last summer but I like the changes and how it&#= 39;s been kept pretty simple for the common use-case while still allowing f= or crypto agility/extension. Nice work!

[1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#sectio= n-3.3
--089e011825c0282dc904f8fdc379-- From nobody Mon May 12 10:59:42 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67EA1A0755 for ; Mon, 12 May 2014 10:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 2roOmdK5B6Co for ; Mon, 12 May 2014 10:59:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5810B1A076B for ; Mon, 12 May 2014 10:59:36 -0700 (PDT) Received: from [192.168.10.142] ([80.92.122.106]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MHnzh-1Wmvi718Sj-003en4; Mon, 12 May 2014 19:59:26 +0200 Message-ID: <53710BF9.7090701@gmx.net> Date: Mon, 12 May 2014 19:59:21 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Phil Hunt , OAuth WG References: <536BFA23.9020900@digitalbazaar.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oUjI6ef6QukWimQwSOrLbur1TS3msamOT" X-Provags-ID: V03:K0:1my5VmwkdFPhOeRkO7AwEg5W/sD+h71yN4EClIDK95t4mXudeZm AUY2czS017STTyQDdRW51M/f4+PjW9kO6xy1Ki+PScLX0wv+8/fyTmlIQgn5fnecFpJXBBT eyZfq8+ofKPkkaEoXmLLQVmcCTWCG6n9Oa0MQyx9IRKPfRQ2W63qExSMnFOGmsEkD8nZcsl gSXYdb+P4EfSAWLuW3YIw== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/GEEbZQDL7tdBxfbevpnVPFwJiiM Subject: Re: [OAUTH-WG] Fwd: [http-auth] Review Request for third draft of "Signing HTTP Messages" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 17:59:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oUjI6ef6QukWimQwSOrLbur1TS3msamOT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Conceptually, draft-cavage-http-signatures-02 is the same as OAuth 1.0. Therefore, the symmetric key part of the document is the same as the MAC token. Not quite sure why the authors have not read the OAuth work. On 05/09/2014 01:22 AM, Phil Hunt wrote: > How does this compare with justin's draft? >=20 > Phil >=20 > Begin forwarded message: >=20 >> *From:* Manu Sporny > > >> *Date:* May 8, 2014 at 14:41:55 PDT >> *To:* IETF HTTP Auth > >> *Cc:* Julian Reschke > >, Mark Nottingham > >, Web Payments CG > > >> *Subject:* *[http-auth] Review Request for third draft of "Signing >> HTTP Messages"* >> >> After feedback from Mark Nottingham[1], Julian Reschke[2], folks in th= e >> HTTP Auth WG, and people in the Web Payments CG, we've modified the HT= TP >> Signatures specification in the following ways: >> >> 1. The specification has been renamed to "Signing HTTP Messages". >> 2. The specification now covers both a signature-based Authorization >> mechanism (client-to-server) as well as a general mechanism to sign >> HTTP messages (client-to-server and server-to-client). >> 3. A new "Signature" header has been introduced. >> 4. The layout has been modified heavily to streamline the information >> conveyed in the spec. >> 5. New registries have been created for the algorithms referred to in >> the specification. >> 6. We're now more specific in the way certain canonicalizations are >> performed. >> 7. More examples have been added, including how to digitally sign >> the body of an HTTP message. >> >> The basic mechanism of generating the signatures has not changed (and >> has been stable for over a year). >> >> The newest spec can be found here: >> >> http://tools.ietf.org/html/draft-cavage-http-signatures-02 >> >> The diff is here: >> >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-cavage-http-signatures-02.t= xt >> >> Matt, Yoav, Kathleen, if there are no show stopping review comments, I= 'd >> like to push this spec onto the RFC track in the HTTP Auth WG, or >> HTTPbis/2 WG. It'll be ready for a LC in a month or two. I realize tha= t >> HTTP Auth may be shutting down next month, so what's the next step to >> get the HTTP Signatures spec further down the IETF RFC track? >> >> -- manu >> >> [1] >> http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0038.ht= ml >> [2] >> http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0036.ht= ml >> >> --=20 >> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) >> Founder/CEO - Digital Bazaar, Inc. >> blog: The Marathonic Dawn of Web Payments >> http://manu.sporny.org/2014/dawn-of-web-payments/ >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --oUjI6ef6QukWimQwSOrLbur1TS3msamOT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTcQv6AAoJEGhJURNOOiAtfCUIAIWdIpitNEJDyexepBwwCtCj o2ldmd1inLbc9FW08zkqzr6fGvGEHhW10sU0XuwEcH50f6aFR/pz/NgqO/Yeqbqd XZxU7H153S0soUdxxusEVwZPJo2FDYREBzLw4BLvBNv91fkuAyaHI1RSJLKzNRM5 2TOXr4NDZaaKc1VApkCZ0+DAq7zYb97UUUYpztpBEu9r9xBF5TJqyuUABbSH4Hnn cuyt1peaBDDZj3c4H6Mx8yPAHiv6bjLD8SuyquckIEQtw8W/6DrYwgUN5UAIpcW6 4aC9yZuvX46dIMgMVofuSy8PPpVHmVwsFk38hpsUtSE5Cc6A4KMv1oSO/D/rRfA= =Kvrp -----END PGP SIGNATURE----- --oUjI6ef6QukWimQwSOrLbur1TS3msamOT-- From nobody Mon May 12 11:03:08 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E5A1A0745 for ; Mon, 12 May 2014 11:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 PZyZlA7iM2b7 for ; Mon, 12 May 2014 11:03:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 87E891A0741 for ; Mon, 12 May 2014 11:03:02 -0700 (PDT) Received: from [192.168.10.142] ([80.92.122.106]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M1Fe4-1X3uHl2a5I-00tBLB; Mon, 12 May 2014 20:02:54 +0200 Message-ID: <53710CC9.2000600@gmx.net> Date: Mon, 12 May 2014 20:02:49 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Phil Hunt , OAuth WG References: <9378C75B-2146-4E8D-BDD6-B4F495C52B84@oracle.com> In-Reply-To: <9378C75B-2146-4E8D-BDD6-B4F495C52B84@oracle.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4mxT4S8hbvtTT2SLGdFo3MUFrs19QfEfR" X-Provags-ID: V03:K0:HhK5LKTG/LKwR6qjeESD2HNf3rvZB42FIjgV53KftRNECPqt+Fg FnEJ9Ke0BFswCPbiLquZm1qX7zqGrxLIS16O3MELk4BgTpj6pPGZp9e/0xbFhHZWTHwa+HF EeMq7JGVSxzx9bP3wUPrGb5woBMfhki2VS8X0d2VDcq5+uJ7t9pnfG6JZC+YNYhl/YcHvSx J/IzuHJlLqbZ8krYOYbUg== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/h-OfjNmNqVsVbO6ky5oFPkVUD64 Cc: blair.strang@covata.com Subject: Re: [OAUTH-WG] Fwd: HTTP protocol version in MAC signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 18:03:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4mxT4S8hbvtTT2SLGdFo3MUFrs19QfEfR Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Phil, Hi Blair, this is a good point. I also don't see a reason why the HTTP protocol version should be included in the keyed message digest (from a security point of view). It might, however, be worthwhile to point out that we are exploring different solution directions, as described in this slide deck http://www.tschofenig.priv.at/oauth/IETF-OAuth-PoP.pptx For this reason it might be interesting to know what AWS implements. Do you guys have a reference? Ciao Hannes On 05/09/2014 05:47 AM, Phil Hunt wrote: > Fyi >=20 > Phil >=20 > Begin forwarded message: >=20 >> *From:* Blair Strang > > >> *Date:* May 8, 2014 at 18:47:58 PDT >> *Resent-To:* hannes.tschofenig@gmx.net >> , jricher@mitre.org >> , phil.hunt@yahoo.com >> , wmills@yahoo-inc.com >> >> *To:* draft-ietf-oauth-v2-http-mac@tools.ietf.org >> >> *Subject:* *HTTP protocol version in MAC signatures* >> >> Hi, >> >> [Not sure if this is the right address to submit this feedback to] >> >> Looking >> over http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05 sectio= n 5.2. >> "MAC Input String", it seems that the HTTP request line is used >> verbatim during the construction of MAC tokens. >> >> Since this includes the transport (HTTP/1.1 versus say HTTP/1.0) it >> seems that HTTP proxies which run different protocol versions on each >> leg will break signatures.=20 >> >> I would recommend removing the HTTP version from the MAC. The >> transport is inherently a "per hop" type of thing, while request >> signatures are conceptually "end to end". >> >> I am not aware of any specific security benefits derived from >> including the HTTP protocol version in the MAC input string. This may >> be why AWS version 2 and AWS version 4 signatures do not include it. >> >> Thanks and regards, >> >> Blair. >> >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --4mxT4S8hbvtTT2SLGdFo3MUFrs19QfEfR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTcQzJAAoJEGhJURNOOiAtLI4IAITiwZlDWjEYr4iTcqWcasu+ tdePJXtjWsymtikQdlZ6tprEEVAhT6mmsicz6WJrKoA6pQYYSfOXRhNYdy9e2VP9 xBXk0fqgw77aNJknvSWay0dMha524LDaufyHhKmRDgsngfwbVH+euHrs4tjTSsMH XcYZiYGoXgG1pZ+pwXA5NhDgw+K9/MeJjNFM0lXfimWDnxKcd/L1ha5f5crMDNJq D6wGpCQaFMIAyNybai83yZJTt0hd7Xbw94Nn+WietWgx7YBja3BsLciqoSKzjBWh Eeg8mz1uPMZwtTK2+ztOTeshSSJ7cm/WJusNeggPk7tOatJfxvbeL3iOmymERjw= =ALZr -----END PGP SIGNATURE----- --4mxT4S8hbvtTT2SLGdFo3MUFrs19QfEfR-- From nobody Mon May 12 14:15:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34A31A0772 for ; Mon, 12 May 2014 14:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 REoL_sQVcawQ for ; Mon, 12 May 2014 14:15:29 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE6D1A077A for ; Mon, 12 May 2014 14:15:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id E203BE2034; Mon, 12 May 2014 17:15:22 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 32044-10; Mon, 12 May 2014 17:15:21 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id A7D60E2031; Mon, 12 May 2014 17:15:20 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.7/Submit) id s4CLFI52026063; Mon, 12 May 2014 17:15:18 -0400 From: Derek Atkins To: Brian Campbell References: Date: Mon, 12 May 2014 17:15:17 -0400 In-Reply-To: (Brian Campbell's message of "Fri, 9 May 2014 14:51:01 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/8hQlUfpxKuo5_t0ezV-pliYCWv0 Cc: John Bradley , oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 21:15:31 -0000 Brian Campbell writes: > I notice that code_verifier is defined as "high entropy cryptographic ran= dom > string of length less than 128 bytes"=C2=A0 [1], which brought a few ques= tions and > comments to mind. So here goes: > > Talking about the length of a string in terms of bytes is always potentia= lly > confusing. Maybe characters would be an easier unit for people like me to= wrap > their little brains around? It depends if it really is characters or bytes. For example there are many multi-byte UTF-8 characters, so if it really is bytes then saying characters is wrong because it could overflow. So let's make sure we know what we're talking about. Historically, if we're talking bytes the IETF often uses the phrase "octets". Would that be less confusing? > Why are we putting a length restriction on the code_verifier anyway? It s= eems > like it'd be more appropriate to restrict the length of the code_challenge > because that's the thing the AS will have to maintain somehow (store in a= DB > or memory or encrypt into the code). Am I missing something here? > > Let me also say that I hadn't looked at this document since its early day= s in > draft -00 or -01 last summer but I like the changes and how it's been kept > pretty simple for the common use-case while still allowing for crypto agi= lity/ > extension. Nice work! > > [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 -derek > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Mon May 12 14:48:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE3D1A077F for ; Mon, 12 May 2014 14:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 8Utswhvrb0uF for ; Mon, 12 May 2014 14:48:36 -0700 (PDT) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id C27E31A077A for ; Mon, 12 May 2014 14:48:35 -0700 (PDT) Received: by mail-ee0-f45.google.com with SMTP id d49so5123601eek.4 for ; Mon, 12 May 2014 14:48:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=bSmTrt5+wiv8PySG+/SdUIFkV6G6tI1RorcWE9nnq8Y=; b=KMJ85aWgRQrq53kg4TKPfIQgvPzOEJ2FafFCP96PBTB06qPlMGKvpRBWnp4Gtqh02g T8VjyHWzjCYk3wg/WR//rDfhJH6sxggaTvhpiSlJG1TA+k6i5XCuPWniVpN9maVTFeuj +suHVpSzjfiEZwlvHUmX6iG/gizhmAre3Z8AyJanD9d42IA9hGiLFOGulPcaiZvYhIzF WFHTIKeF9+6m/ouQp8sJgzzU1qyMg0hCsO/pGNx/OGHGjmkWzbQ7tsYz5xBD28tHhDF2 sEz8p/IQVrDdz3jjG+GrXNkVLxPaudM+0FZfNKbR8mMz5wFw+g+Gb/6txY8dE3YZy/s2 1f6g== X-Gm-Message-State: ALoCoQk4Vsu7zzXsh0vr8HnUJmxehQGVdtdrXHLNKgQojAt8qKjuaLT7kJQapTHtccVLgwswqKNW X-Received: by 10.15.63.200 with SMTP id m48mr35166991eex.87.1399931308828; Mon, 12 May 2014 14:48:28 -0700 (PDT) Received: from [192.168.0.93] ([195.50.165.102]) by mx.google.com with ESMTPSA id 4sm35592999eef.44.2014.05.12.14.48.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 May 2014 14:48:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: John Bradley In-Reply-To: Date: Mon, 12 May 2014 23:48:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> References: To: Derek Atkins X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wav7LG1aVYEwdZgpUzcwS2qnafo Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 21:48:38 -0000 I think octets is more consistent with other JW* and OAuth specs. The code_challange is the same length as the code_verifyer or is a hash = of the code_verifyer so likely smaller than 128octets (43 ish for base64 = 256 bit) Limiting the code_verifyer size sets the upper bound for code_challange, = unless someone comes up with a really creative code challenge algorithm. I will talk to nat about changing it to octets when I see him tomorrow. =20= John B. On May 12, 2014, at 11:15 PM, Derek Atkins wrote: > Brian Campbell writes: >=20 >> I notice that code_verifier is defined as "high entropy cryptographic = random >> string of length less than 128 bytes" [1], which brought a few = questions and >> comments to mind. So here goes: >>=20 >> Talking about the length of a string in terms of bytes is always = potentially >> confusing. Maybe characters would be an easier unit for people like = me to wrap >> their little brains around? >=20 > It depends if it really is characters or bytes. For example there are > many multi-byte UTF-8 characters, so if it really is bytes then saying > characters is wrong because it could overflow. So let's make sure we > know what we're talking about. Historically, if we're talking bytes = the > IETF often uses the phrase "octets". Would that be less confusing? >=20 >> Why are we putting a length restriction on the code_verifier anyway? = It seems >> like it'd be more appropriate to restrict the length of the = code_challenge >> because that's the thing the AS will have to maintain somehow (store = in a DB >> or memory or encrypt into the code). Am I missing something here? >>=20 >> Let me also say that I hadn't looked at this document since its early = days in >> draft -00 or -01 last summer but I like the changes and how it's been = kept >> pretty simple for the common use-case while still allowing for crypto = agility/ >> extension. Nice work! >>=20 >> [1] = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 >=20 > -derek >=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > --=20 > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available From nobody Mon May 12 14:51:06 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB3F1A076F for ; Mon, 12 May 2014 14:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 mn3uLt5yjJ18 for ; Mon, 12 May 2014 14:50:59 -0700 (PDT) Received: from na6sys009bog026.obsmtp.com (na6sys009bog026.obsmtp.com [74.125.150.92]) by ietfa.amsl.com (Postfix) with ESMTP id B60091A035C for ; Mon, 12 May 2014 14:50:58 -0700 (PDT) Received: from mail-ig0-f178.google.com ([209.85.213.178]) (using TLSv1) by na6sys009bob026.postini.com ([74.125.148.12]) with SMTP ID DSNKU3FCPLJDcofeBeSESSihVnefsvIHZslX@postini.com; Mon, 12 May 2014 14:50:53 PDT Received: by mail-ig0-f178.google.com with SMTP id hl10so4442136igb.5 for ; Mon, 12 May 2014 14:50:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=H7JppnSIQRRNHf6WTEAmhXZ7x2SCN/MnaHJP7dePNRc=; b=XPh0aWtBb5s7p2RhBKQD3gT5UAiQSjO8E6AdLOvhQuz2THrujYU07vvCcKeuVx1hwm S6Dnt7Og1nQlDn/I+Omv4Uk9SCw9iXV5Vp1w/9r3Bto4CUBUWeNftm9bLVqKp9G+2jOS nZVIqtKJoPR0FPP/L2vgDlAZMYreKsvRt1WCKEA9I5IEr45dF6Yl660Q4++1hIKAm8UR VbWLC9sRRnsd4MSjgpH2AQ36KIxxZJc/LRG9QkdVO4RiUevl/6oJ8hKiEaR6tU0J9BZY jfBA86DfJ8u/GisuR8Sx+bv2QY0pxS+t72nN3i6WS95yMqOlivDVPtAKeDbnLGelcmCY A8Bg== X-Gm-Message-State: ALoCoQn6zx6lYHLUU7RjKMzugOpWn5kpRXHEz1d3RYg0Isu0mX12E/jJjyznUklb0INm10VziLuFkeRyGCR4CfovCoYbH38AGdeLqYviUIcKe4EcoQqXu8ISox4c4T0QNkUvp0ZTG52d X-Received: by 10.50.79.226 with SMTP id m2mr49021088igx.11.1399931452055; Mon, 12 May 2014 14:50:52 -0700 (PDT) X-Received: by 10.50.79.226 with SMTP id m2mr49021078igx.11.1399931451932; Mon, 12 May 2014 14:50:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Mon, 12 May 2014 14:50:20 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 12 May 2014 15:50:20 -0600 Message-ID: To: Derek Atkins Content-Type: multipart/alternative; boundary=089e01160752e718df04f93af01d Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/4FPJbh8-6cjI9mAfyi8lea0_9JY Cc: John Bradley , oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 21:51:01 -0000 --089e01160752e718df04f93af01d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, it does depend on what it really is and why the length needs to be restricted. That's what the other questions were really about. Octets would be better than bytes, if that's what's intended. On Mon, May 12, 2014 at 3:15 PM, Derek Atkins wrote: > Brian Campbell writes: > > > I notice that code_verifier is defined as "high entropy cryptographic > random > > string of length less than 128 bytes" [1], which brought a few > questions and > > comments to mind. So here goes: > > > > Talking about the length of a string in terms of bytes is always > potentially > > confusing. Maybe characters would be an easier unit for people like me > to wrap > > their little brains around? > > It depends if it really is characters or bytes. For example there are > many multi-byte UTF-8 characters, so if it really is bytes then saying > characters is wrong because it could overflow. So let's make sure we > know what we're talking about. Historically, if we're talking bytes the > IETF often uses the phrase "octets". Would that be less confusing? > > > Why are we putting a length restriction on the code_verifier anyway? It > seems > > like it'd be more appropriate to restrict the length of the > code_challenge > > because that's the thing the AS will have to maintain somehow (store in > a DB > > or memory or encrypt into the code). Am I missing something here? > > > > Let me also say that I hadn't looked at this document since its early > days in > > draft -00 or -01 last summer but I like the changes and how it's been > kept > > pretty simple for the common use-case while still allowing for crypto > agility/ > > extension. Nice work! > > > > [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 > > -derek > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > --=20 [image: Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with us=E2=80=A6 [image: twitter logo] = [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo] [image: flipboard logo] [image: rss feed icon] [image: Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] --089e01160752e718df04f93af01d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, it does depend on what it really is and why the= length needs to be restricted. That's what the other questions were re= ally about.

Octets would be better than bytes, if that= 9;s what's intended.


O= n Mon, May 12, 2014 at 3:15 PM, Derek Atkins <warlord@mit.edu> wrote:
Brian Campbell <bcampbell@pingidentity.com> w= rites:

> I notice that code_verifier is defined as "high entropy cryptogra= phic random
> string of length less than 128 bytes"=C2=A0 [1], which brought a = few questions and
> comments to mind. So here goes:
>
> Talking about the length of a string in terms of bytes is always poten= tially
> confusing. Maybe characters would be an easier unit for people like me= to wrap
> their little brains around?

It depends if it really is characters or bytes. =C2=A0For example the= re are
many multi-byte UTF-8 characters, so if it really is bytes then saying
characters is wrong because it could overflow. =C2=A0So let's make sure= we
know what we're talking about. =C2=A0Historically, if we're talking= bytes the
IETF often uses the phrase "octets". =C2=A0Would that be less con= fusing?

> Why are we putting a length restriction on the code_verifier anyway? I= t seems
> like it'd be more appropriate to restrict the length of the code_c= hallenge
> because that's the thing the AS will have to maintain somehow (sto= re in a DB
> or memory or encrypt into the code). Am I missing something here?
>
> Let me also say that I hadn't looked at this document since its ea= rly days in
> draft -00 or -01 last summer but I like the changes and how it's b= een kept
> pretty simple for the common use-case while still allowing for crypto = agility/
> extension. Nice work!
>
> [1] http://tools.ietf.org/html/draft-sakimura-o= auth-tcse-03#section-3.3

-derek

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

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0Derek Atkins, SB '93 MIT EE, SM '95 MIT = Media Laboratory
=C2=A0 =C2=A0 =C2=A0 =C2=A0Member, MIT Student Information Processing Board= =C2=A0(SIPB)
=C2=A0 =C2=A0 =C2=A0 =C2=A0URL: http://web.mit.edu/warlord/ =C2=A0 =C2=A0PP-ASEL-IA =C2= =A0 =C2=A0 N1NWH
=C2=A0 =C2=A0 =C2=A0 =C2=A0warlord@MIT.E= DU =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0PGP key available



--
--089e01160752e718df04f93af01d-- From nobody Mon May 12 14:54:44 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB8A1A035C for ; Mon, 12 May 2014 14:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 L77D_knNtWF9 for ; Mon, 12 May 2014 14:54:39 -0700 (PDT) Received: from na6sys009bog017.obsmtp.com (na6sys009bog017.obsmtp.com [74.125.150.74]) by ietfa.amsl.com (Postfix) with ESMTP id 33D0F1A0767 for ; Mon, 12 May 2014 14:54:39 -0700 (PDT) Received: from mail-ig0-f177.google.com ([209.85.213.177]) (using TLSv1) by na6sys009bob017.postini.com ([74.125.148.12]) with SMTP ID DSNKU3FDGW4ASgwNx2vgOUQN/N36zW8rnV+M@postini.com; Mon, 12 May 2014 14:54:33 PDT Received: by mail-ig0-f177.google.com with SMTP id l13so4460985iga.16 for ; Mon, 12 May 2014 14:54:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IzlQeM+1rLcwbASAiyYwCDcnl2gfTPZyZAlfsor3gDw=; b=NYsGZd7IbalJdac3LgM3FmoN0LOxYASCn+L8lY2BWZnQk7MDTjMLfkO4EgqZOzu5xY dNig8eAtOFnp2ZlnXBTqiPEIyCj7Ld/eZCwJXUCNJMdXip5Zvv6e2rRu7qgq+7rZE9u4 AxEkXXDOe/tpldZ+JwpZzvfgVAcTG+VLIyHVjUMkzzc3ftxS55O1uUv2vlLP8I1d7GaV a+VRbvxrJbeKUCo7bTLadH/5Q6a+5UkQPfPNVYQOFAkZ2za4ygTA0ewpRtglHa6hFHGf Qi6F5sfKEnYc1tTCvSO/UeyHODYy7EGPzwrn1589kFXr9inKOgiU7aA23rzghKcvEcWf g7Ew== X-Gm-Message-State: ALoCoQlj66GqXNu47+1fwp+nQIi/QpXr5nVx2nDEyDwHrlefO/clN4RBsoaSU5sN19zha1idKdu6a5ffOLw0zpYn3dxQ3nk0KBDTxWQDxpgd0oJdtO/oDE3naTeD2iiXM3rh2XRVwTMx X-Received: by 10.50.153.49 with SMTP id vd17mr48944415igb.40.1399931672814; Mon, 12 May 2014 14:54:32 -0700 (PDT) X-Received: by 10.50.153.49 with SMTP id vd17mr48944385igb.40.1399931672637; Mon, 12 May 2014 14:54:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Mon, 12 May 2014 14:54:02 -0700 (PDT) In-Reply-To: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> References: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> From: Brian Campbell Date: Mon, 12 May 2014 15:54:02 -0600 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=089e014954be0f1a2a04f93afe3c Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/P6wgnqgsYWlCT98xUW3qvmOUDDM Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 21:54:42 -0000 --089e014954be0f1a2a04f93afe3c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right but that's why I'm asking why not just put the limit on code_challange rather than inferring it from code_verifyer + challenge algorithm, which probably bounds it but doesn't necessarily do so? It's not a big deal but would read more clearly, I think. On Mon, May 12, 2014 at 3:48 PM, John Bradley wrote: > I think octets is more consistent with other JW* and OAuth specs. > > The code_challange is the same length as the code_verifyer or is a hash o= f > the code_verifyer so likely smaller than 128octets (43 ish for base64 256 > bit) > > Limiting the code_verifyer size sets the upper bound for code_challange, > unless someone comes up with a really creative code challenge algorithm. > > I will talk to nat about changing it to octets when I see him tomorrow. > > John B. > > On May 12, 2014, at 11:15 PM, Derek Atkins wrote: > > > Brian Campbell writes: > > > >> I notice that code_verifier is defined as "high entropy cryptographic > random > >> string of length less than 128 bytes" [1], which brought a few > questions and > >> comments to mind. So here goes: > >> > >> Talking about the length of a string in terms of bytes is always > potentially > >> confusing. Maybe characters would be an easier unit for people like me > to wrap > >> their little brains around? > > > > It depends if it really is characters or bytes. For example there are > > many multi-byte UTF-8 characters, so if it really is bytes then saying > > characters is wrong because it could overflow. So let's make sure we > > know what we're talking about. Historically, if we're talking bytes th= e > > IETF often uses the phrase "octets". Would that be less confusing? > > > >> Why are we putting a length restriction on the code_verifier anyway? I= t > seems > >> like it'd be more appropriate to restrict the length of the > code_challenge > >> because that's the thing the AS will have to maintain somehow (store i= n > a DB > >> or memory or encrypt into the code). Am I missing something here? > >> > >> Let me also say that I hadn't looked at this document since its early > days in > >> draft -00 or -01 last summer but I like the changes and how it's been > kept > >> pretty simple for the common use-case while still allowing for crypto > agility/ > >> extension. Nice work! > >> > >> [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.= 3 > > > > -derek > > > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > warlord@MIT.EDU PGP key available > > --=20 [image: Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with us=E2=80=A6 [image: twitter logo] = [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo] [image: flipboard logo] [image: rss feed icon] [image: Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] --089e014954be0f1a2a04f93afe3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right but that's why I'm asking why not just put t= he limit on code_challange rather than inferring it from code_verifyer + ch= allenge algorithm, which probably bounds it but doesn't necessarily do = so? It's not a big deal but would read more clearly, I think.


On Mon,= May 12, 2014 at 3:48 PM, John Bradley <ve7jtb@ve7jtb.com> w= rote:
I think octets is more consistent with other= JW* and OAuth specs.

The code_challange is the same length as the code_verifyer or is a hash of = the code_verifyer so likely smaller than 128octets (43 ish for base64 256 b= it)

Limiting the code_verifyer size sets the upper bound for code_challange, un= less someone comes up with a really creative code challenge algorithm.

I will talk to nat about changing it to octets when I see him tomorrow.

John B.

On May 12, 2014, at 11:15 PM, Derek Atkins <warlord@MIT.EDU> wrote:

> Brian Campbell <bcamp= bell@pingidentity.com> writes:
>
>> I notice that code_verifier is defined as "high entropy crypt= ographic random
>> string of length less than 128 bytes" =C2=A0[1], which brough= t a few questions and
>> comments to mind. So here goes:
>>
>> Talking about the length of a string in terms of bytes is always p= otentially
>> confusing. Maybe characters would be an easier unit for people lik= e me to wrap
>> their little brains around?
>
> It depends if it really is characters or bytes. =C2=A0For example ther= e are
> many multi-byte UTF-8 characters, so if it really is bytes then saying=
> characters is wrong because it could overflow. =C2=A0So let's make= sure we
> know what we're talking about. =C2=A0Historically, if we're ta= lking bytes the
> IETF often uses the phrase "octets". =C2=A0Would that be les= s confusing?
>
>> Why are we putting a length restriction on the code_verifier anywa= y? It seems
>> like it'd be more appropriate to restrict the length of the co= de_challenge
>> because that's the thing the AS will have to maintain somehow = (store in a DB
>> or memory or encrypt into the code). Am I missing something here?<= br> >>
>> Let me also say that I hadn't looked at this document since it= s early days in
>> draft -00 or -01 last summer but I like the changes and how it'= ;s been kept
>> pretty simple for the common use-case while still allowing for cry= pto agility/
>> extension. Nice work!
>>
>> [1] http://tools.ietf.org/html/draft-sakimu= ra-oauth-tcse-03#section-3.3
>
> -derek
>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> --
> =C2=A0 =C2=A0 =C2=A0 Derek Atkins, SB '93 MIT EE, SM '95 MIT M= edia Laboratory
> =C2=A0 =C2=A0 =C2=A0 Member, MIT Student Information Processing Board = =C2=A0(SIPB)
> =C2=A0 =C2=A0 =C2=A0 URL: http://web.mit.edu/warlord/ =C2=A0 =C2=A0PP-ASEL-IA =C2= =A0 =C2=A0 N1NWH
> =C2=A0 =C2=A0 =C2=A0 warlord@MIT.ED= U =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0PGP key available




--
--089e014954be0f1a2a04f93afe3c-- From nobody Mon May 12 14:57:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8939D1A035D for ; Mon, 12 May 2014 14:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 eq3OQAO1c1kO for ; Mon, 12 May 2014 14:57:07 -0700 (PDT) Received: from na6sys009bog013.obsmtp.com (na6sys009bog013.obsmtp.com [74.125.150.66]) by ietfa.amsl.com (Postfix) with ESMTP id D64501A0783 for ; Mon, 12 May 2014 14:57:05 -0700 (PDT) Received: from mail-ie0-f179.google.com ([209.85.223.179]) (using TLSv1) by na6sys009bob013.postini.com ([74.125.148.12]) with SMTP ID DSNKU3FDq6nXEIDPhIRoR85G+CL59d1NhWRO@postini.com; Mon, 12 May 2014 14:57:00 PDT Received: by mail-ie0-f179.google.com with SMTP id rd18so2774874iec.38 for ; Mon, 12 May 2014 14:56:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=013IcdjIsvdoDpEdlOgbB2xx0+uLwciCzztCu20uu9M=; b=PSbtVRZ5WjLp9itmEW9L862mVp/KR+GywpHHj42H0tZLYoiOOPKwwSdeWpBJG7vQPq WnT9p+wXEKylEwsqUiGresutzMUi2O1ltmDIoNuWTI1mGxi0Y+O8pd48utuiboOO3+b8 Cyv5WE+fEYqZFckK/unuCnclG0B2Aa7wS0RZ6GiAYjzKEmW/Zn5sNmpdwroMwBJRw4Rm icCP86oOu4diw+CF5CQC1HfRS2Vx/t0wRgN16HZGyzWjqJrzwQMU16sZlFpO02OgDNu1 TaLqdtbPT9Jx4j2DA/TVREN9HSELWzIOAJapba/4HAASndV6QHUvYBPoGfBMu6cSHsEx bv1Q== X-Gm-Message-State: ALoCoQk5GtPjl8cPxrpz3vXjxVr7cYldVcl0xyVWz3x/kn8WXLrS/8VKva7DE1xs7kIAkoaU3cohQ7P1GFH6QgFfRg4kOwfmLc2WwfwxRW0PGyOS59seKtq669ie8R8YK7rKTPX5w8A8 X-Received: by 10.50.4.70 with SMTP id i6mr50447262igi.40.1399931818385; Mon, 12 May 2014 14:56:58 -0700 (PDT) X-Received: by 10.50.4.70 with SMTP id i6mr50447241igi.40.1399931818239; Mon, 12 May 2014 14:56:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Mon, 12 May 2014 14:56:28 -0700 (PDT) In-Reply-To: References: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> From: Brian Campbell Date: Mon, 12 May 2014 15:56:28 -0600 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a11c32a88bcfdcc04f93b066f Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/75gKkZ_pgVsbj6XpafAEthixL1Q Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 21:57:09 -0000 --001a11c32a88bcfdcc04f93b066f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable And it'd give the AS some direct guidance on protecting itself from crazy long code_challenge values rather than relying on the client not to do something creative. On Mon, May 12, 2014 at 3:54 PM, Brian Campbell wrote: > Right but that's why I'm asking why not just put the limit on > code_challange rather than inferring it from code_verifyer + challenge > algorithm, which probably bounds it but doesn't necessarily do so? It's n= ot > a big deal but would read more clearly, I think. > > > On Mon, May 12, 2014 at 3:48 PM, John Bradley wrote: > >> I think octets is more consistent with other JW* and OAuth specs. >> >> The code_challange is the same length as the code_verifyer or is a hash >> of the code_verifyer so likely smaller than 128octets (43 ish for base64 >> 256 bit) >> >> Limiting the code_verifyer size sets the upper bound for code_challange, >> unless someone comes up with a really creative code challenge algorithm. >> >> I will talk to nat about changing it to octets when I see him tomorrow. >> >> John B. >> >> On May 12, 2014, at 11:15 PM, Derek Atkins wrote: >> >> > Brian Campbell writes: >> > >> >> I notice that code_verifier is defined as "high entropy cryptographic >> random >> >> string of length less than 128 bytes" [1], which brought a few >> questions and >> >> comments to mind. So here goes: >> >> >> >> Talking about the length of a string in terms of bytes is always >> potentially >> >> confusing. Maybe characters would be an easier unit for people like m= e >> to wrap >> >> their little brains around? >> > >> > It depends if it really is characters or bytes. For example there are >> > many multi-byte UTF-8 characters, so if it really is bytes then saying >> > characters is wrong because it could overflow. So let's make sure we >> > know what we're talking about. Historically, if we're talking bytes t= he >> > IETF often uses the phrase "octets". Would that be less confusing? >> > >> >> Why are we putting a length restriction on the code_verifier anyway? >> It seems >> >> like it'd be more appropriate to restrict the length of the >> code_challenge >> >> because that's the thing the AS will have to maintain somehow (store >> in a DB >> >> or memory or encrypt into the code). Am I missing something here? >> >> >> >> Let me also say that I hadn't looked at this document since its early >> days in >> >> draft -00 or -01 last summer but I like the changes and how it's been >> kept >> >> pretty simple for the common use-case while still allowing for crypto >> agility/ >> >> extension. Nice work! >> >> >> >> [1] >> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 >> > >> > -derek >> > >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > -- >> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >> > Member, MIT Student Information Processing Board (SIPB) >> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >> > warlord@MIT.EDU PGP key available >> >> > > > -- > [image: Ping Identity logo] > Brian Campbell > Portfolio Architect > @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect > with us=E2=80=A6 [image: twitter logo] [image: > youtube logo] [image: > LinkedIn logo] [image: Facebook > logo] [image: Google+ logo] [image: > slideshare logo] [image: > flipboard logo] [image: rss feed icon] > [image: Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] > > --=20 [image: Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with us=E2=80=A6 [image: twitter logo] = [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo] [image: flipboard logo] [image: rss feed icon] [image: Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] --001a11c32a88bcfdcc04f93b066f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And it'd give the AS some direct guidance on protectin= g itself from crazy long code_challenge values rather than relying on the c= lient not to do something creative.

On Mon, May 12, 2014 at 3:54 PM, Brian Campb= ell <bcampbell@pingidentity.com> wrote:
Right but that's why I'm asking why not just put t= he limit on code_challange rather than inferring it from code_verifyer + ch= allenge algorithm, which probably bounds it but doesn't necessarily do = so? It's not a big deal but would read more clearly, I think.


On Mon, May 12, 2014 at 3:48 PM, John Bradley <ve7jtb@ve7= jtb.com> wrote:
I think octets is more consistent with other= JW* and OAuth specs.

The code_challange is the same length as the code_verifyer or is a hash of = the code_verifyer so likely smaller than 128octets (43 ish for base64 256 b= it)

Limiting the code_verifyer size sets the upper bound for code_challange, un= less someone comes up with a really creative code challenge algorithm.

I will talk to nat about changing it to octets when I see him tomorrow.

John B.

On May 12, 2014, at 11:15 PM, Derek Atkins <warlord@MIT.EDU> wrote:

> Brian Campbell <bcampbell@pingidentity.com> writes:
>
>> I notice that code_verifier is defined as "high entropy crypt= ographic random
>> string of length less than 128 bytes" =C2=A0[1], which brough= t a few questions and
>> comments to mind. So here goes:
>>
>> Talking about the length of a string in terms of bytes is always p= otentially
>> confusing. Maybe characters would be an easier unit for people lik= e me to wrap
>> their little brains around?
>
> It depends if it really is characters or bytes. =C2=A0For example ther= e are
> many multi-byte UTF-8 characters, so if it really is bytes then saying=
> characters is wrong because it could overflow. =C2=A0So let's make= sure we
> know what we're talking about. =C2=A0Historically, if we're ta= lking bytes the
> IETF often uses the phrase "octets". =C2=A0Would that be les= s confusing?
>
>> Why are we putting a length restriction on the code_verifier anywa= y? It seems
>> like it'd be more appropriate to restrict the length of the co= de_challenge
>> because that's the thing the AS will have to maintain somehow = (store in a DB
>> or memory or encrypt into the code). Am I missing something here?<= br> >>
>> Let me also say that I hadn't looked at this document since it= s early days in
>> draft -00 or -01 last summer but I like the changes and how it'= ;s been kept
>> pretty simple for the common use-case while still allowing for cry= pto agility/
>> extension. Nice work!
>>
>> [1] http://tools.ietf.org/html/draft-sakimu= ra-oauth-tcse-03#section-3.3
>
> -derek
>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>
> --
> =C2=A0 =C2=A0 =C2=A0 Derek Atkins, SB '93 MIT EE, SM '95 MIT M= edia Laboratory
> =C2=A0 =C2=A0 =C2=A0 Member, MIT Student Information Processing Board = =C2=A0(SIPB)
> =C2=A0 =C2=A0 =C2=A0 URL: http://web.mit.edu/warlord/ =C2=A0 =C2=A0PP-ASEL-IA =C2= =A0 =C2=A0 N1NWH
> =C2=A0 =C2=A0 =C2=A0 warlord@MIT.EDU =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PGP key available




--
3D"Ping =09
Brian Campbell
= Portfolio Architect
=09
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register




--
--001a11c32a88bcfdcc04f93b066f-- From nobody Mon May 12 23:52:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29781A0828 for ; Mon, 12 May 2014 23:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 w20uycTZgeWJ for ; Mon, 12 May 2014 23:52:32 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 79FA21A07EE for ; Mon, 12 May 2014 23:52:31 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id w7so8125654lbi.23 for ; Mon, 12 May 2014 23:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lMvzJOCLS97iN1gCUFeQ5AzSZ3syMRJ40buSKTwqgOI=; b=NZgy91hSVEoC7GhVU16jPoctGEXMZbFG2mfoJ9C7XB/zXFcPLszn05TYF+G8gSpI2v Bss19eTBpNwxdwZbRWZvP3frisPHTDlAGB9qjdZ4ajZCnirKnvggHulxrR3+qeIKq1sP nMDV4cL4UybfLvDpsSsptuY+/pfwUNYVdWXTg/C4FEDmAw5Pq//dKUGGHu8hgnFDRAnN Bihn68Lo0QRVZ2fhraFdw9r8D+fEKdFSYS9KfLJoxGt3ScrWufky9lkjj4+8FGzcaNmV iAJir5TwTslfnMWrY2vjZT/zMGbiXwyscqETI+2cRJESei0bSjTKpXI/aqp4F5tU0Nys lBew== MIME-Version: 1.0 X-Received: by 10.152.29.133 with SMTP id k5mr669900lah.44.1399963944450; Mon, 12 May 2014 23:52:24 -0700 (PDT) Received: by 10.112.105.134 with HTTP; Mon, 12 May 2014 23:52:24 -0700 (PDT) In-Reply-To: References: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> Date: Tue, 13 May 2014 15:52:24 +0900 Message-ID: From: Nat Sakimura To: Brian Campbell Content-Type: multipart/alternative; boundary=089e0158c8589b81f804f94281ae Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/XHgHcBFNhU5bPATxzMgmMLwqcGQ Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 06:52:35 -0000 --089e0158c8589b81f804f94281ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for octet. We used to have "bytes" in JW* so I used "bytes" here, while at the same time complaining in Jose that it should be "octet". JW* changed to "octet" but I failed to sync with it in the last few edits. I do not quite remember which platform, but the reason for the limit was that some platform had some limitations as to the length of the sting to be passed to it through URI and we did not want the challenges to be truncated by that limit. Best, Nat 2014-05-13 6:56 GMT+09:00 Brian Campbell : > And it'd give the AS some direct guidance on protecting itself from crazy > long code_challenge values rather than relying on the client not to do > something creative. > > > On Mon, May 12, 2014 at 3:54 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Right but that's why I'm asking why not just put the limit on >> code_challange rather than inferring it from code_verifyer + challenge >> algorithm, which probably bounds it but doesn't necessarily do so? It's = not >> a big deal but would read more clearly, I think. >> >> >> On Mon, May 12, 2014 at 3:48 PM, John Bradley wrote: >> >>> I think octets is more consistent with other JW* and OAuth specs. >>> >>> The code_challange is the same length as the code_verifyer or is a hash >>> of the code_verifyer so likely smaller than 128octets (43 ish for base6= 4 >>> 256 bit) >>> >>> Limiting the code_verifyer size sets the upper bound for code_challange= , >>> unless someone comes up with a really creative code challenge algorithm= . >>> >>> I will talk to nat about changing it to octets when I see him tomorrow. >>> >>> John B. >>> >>> On May 12, 2014, at 11:15 PM, Derek Atkins wrote: >>> >>> > Brian Campbell writes: >>> > >>> >> I notice that code_verifier is defined as "high entropy cryptographi= c >>> random >>> >> string of length less than 128 bytes" [1], which brought a few >>> questions and >>> >> comments to mind. So here goes: >>> >> >>> >> Talking about the length of a string in terms of bytes is always >>> potentially >>> >> confusing. Maybe characters would be an easier unit for people like >>> me to wrap >>> >> their little brains around? >>> > >>> > It depends if it really is characters or bytes. For example there ar= e >>> > many multi-byte UTF-8 characters, so if it really is bytes then sayin= g >>> > characters is wrong because it could overflow. So let's make sure we >>> > know what we're talking about. Historically, if we're talking bytes >>> the >>> > IETF often uses the phrase "octets". Would that be less confusing? >>> > >>> >> Why are we putting a length restriction on the code_verifier anyway? >>> It seems >>> >> like it'd be more appropriate to restrict the length of the >>> code_challenge >>> >> because that's the thing the AS will have to maintain somehow (store >>> in a DB >>> >> or memory or encrypt into the code). Am I missing something here? >>> >> >>> >> Let me also say that I hadn't looked at this document since its earl= y >>> days in >>> >> draft -00 or -01 last summer but I like the changes and how it's bee= n >>> kept >>> >> pretty simple for the common use-case while still allowing for crypt= o >>> agility/ >>> >> extension. Nice work! >>> >> >>> >> [1] >>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 >>> > >>> > -derek >>> > >>> >> _______________________________________________ >>> >> OAuth mailing list >>> >> OAuth@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > -- >>> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >>> > Member, MIT Student Information Processing Board (SIPB) >>> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >>> > warlord@MIT.EDU PGP key available >>> >>> >> >> >> -- >> [image: Ping Identity logo] >> Brian Campbell >> Portfolio Architect >> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect >> with us=E2=80=A6 [image: twitter logo] [image: >> youtube logo] [image: >> LinkedIn logo] [image: Facebook >> logo] [image: Google+ logo]<= https://plus.google.com/u/0/114266977739397708540> [image: >> slideshare logo] [image: >> flipboard logo] [image: rss feed icon] >> [image: Register for Cloud Identity Summit 2014 | Modern Identity >> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >> >> > > > -- > [image: Ping Identity logo] > Brian Campbell > Portfolio Architect > @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect > with us=E2=80=A6 [image: twitter logo] [image: > youtube logo] [image: > LinkedIn logo] [image: Facebook > logo] [image: Google+ logo] [image: > slideshare logo] [image: > flipboard logo] [image: rss feed icon] > [image: Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] > > > _______________________________________________ > 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 --089e0158c8589b81f804f94281ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for octet. We used to have "bytes" in JW* so = I used "bytes" here, while at the same time complaining in Jose t= hat it should be "octet". JW* changed to "octet" but I = failed to sync with it in the last few edits.=C2=A0

I do not quite remember which platform, but the reason for t= he limit was that some platform had some limitations as to the length of th= e sting to be passed to it through URI and we did not want the challenges t= o be truncated by that limit.=C2=A0

Best,=C2=A0

Nat


2014-05-13 6:56 = GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:
And it'd give the AS so= me direct guidance on protecting itself from crazy long code_challenge valu= es rather than relying on the client not to do something creative.

On Mon, May 12, 2014 at 3:54 PM, Brian Campb= ell <bcampbell@pingidentity.com> wrote:
Right but that's why I'm asking why not just put t= he limit on code_challange rather than inferring it from code_verifyer + ch= allenge algorithm, which probably bounds it but doesn't necessarily do = so? It's not a big deal but would read more clearly, I think.


On Mon, May 12, 2014 at 3:48 PM, John Bradley <ve7jtb@ve7jtb.com>= ; wrote:
I think octets is more consistent with other= JW* and OAuth specs.

The code_challange is the same length as the code_verifyer or is a hash of = the code_verifyer so likely smaller than 128octets (43 ish for base64 256 b= it)

Limiting the code_verifyer size sets the upper bound for code_challange, un= less someone comes up with a really creative code challenge algorithm.

I will talk to nat about changing it to octets when I see him tomorrow.

John B.

On May 12, 2014, at 11:15 PM, Derek Atkins <warlord@MIT.EDU> wrote:

> Brian Campbell <bcampbell@pingidentity.com> writes:
>
>> I notice that code_verifier is defined as "high entropy crypt= ographic random
>> string of length less than 128 bytes" =C2=A0[1], which brough= t a few questions and
>> comments to mind. So here goes:
>>
>> Talking about the length of a string in terms of bytes is always p= otentially
>> confusing. Maybe characters would be an easier unit for people lik= e me to wrap
>> their little brains around?
>
> It depends if it really is characters or bytes. =C2=A0For example ther= e are
> many multi-byte UTF-8 characters, so if it really is bytes then saying=
> characters is wrong because it could overflow. =C2=A0So let's make= sure we
> know what we're talking about. =C2=A0Historically, if we're ta= lking bytes the
> IETF often uses the phrase "octets". =C2=A0Would that be les= s confusing?
>
>> Why are we putting a length restriction on the code_verifier anywa= y? It seems
>> like it'd be more appropriate to restrict the length of the co= de_challenge
>> because that's the thing the AS will have to maintain somehow = (store in a DB
>> or memory or encrypt into the code). Am I missing something here?<= br> >>
>> Let me also say that I hadn't looked at this document since it= s early days in
>> draft -00 or -01 last summer but I like the changes and how it'= ;s been kept
>> pretty simple for the common use-case while still allowing for cry= pto agility/
>> extension. Nice work!
>>
>> [1] http://tools.ietf.org/html/draft-sakimu= ra-oauth-tcse-03#section-3.3
>
> -derek
>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>
> --
> =C2=A0 =C2=A0 =C2=A0 Derek Atkins, SB '93 MIT EE, SM '95 MIT M= edia Laboratory
> =C2=A0 =C2=A0 =C2=A0 Member, MIT Student Information Processing Board = =C2=A0(SIPB)
> =C2=A0 =C2=A0 =C2=A0 URL: http://web.mit.edu/warlord/ =C2=A0 =C2=A0PP-ASEL-IA =C2= =A0 =C2=A0 N1NWH
> =C2=A0 =C2=A0 =C2=A0 warlord@MIT.EDU =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PGP key available




-= -
3D"Ping =09
Brian Campbell
= Portfolio Architect
=09
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register




--
3D"Ping =09
Brian Campbell
= Portfolio Architect
=09
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--089e0158c8589b81f804f94281ae-- From nobody Tue May 13 08:15:51 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780081A0067 for ; Thu, 8 May 2014 13:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 odnkundjpYJb for ; Thu, 8 May 2014 13:08:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8F31A0131 for ; Thu, 8 May 2014 13:08:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140508200844.25686.56794.idtracker@ietfa.amsl.com> Date: Thu, 08 May 2014 13:08:44 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/vnsgRg3VX_QTsr2TZ_qrC471O0E X-Mailman-Approved-At: Tue, 13 May 2014 08:15:35 -0700 Subject: [OAUTH-WG] Milestones changed for oauth WG X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 20:08:46 -0000 Changed milestone "Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard", resolved as "Done". Changed milestone "Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard", resolved as "Done". Changed milestone "Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard", resolved as "Done". Changed milestone "Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard", resolved as "Done". URL: http://datatracker.ietf.org/wg/oauth/charter/ From scott.fulton@ingenus.info Fri May 2 07:31:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852551A0971 for ; Fri, 2 May 2014 07:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 kM6L_T3XkswR for ; Fri, 2 May 2014 07:31:16 -0700 (PDT) Received: from smtp158.ord.emailsrvr.com (smtp158.ord.emailsrvr.com [173.203.6.158]) by ietfa.amsl.com (Postfix) with ESMTP id 44D9C1A08CB for ; Fri, 2 May 2014 07:31:16 -0700 (PDT) Received: from smtp24.relay.ord1a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp24.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id DD09A198ACB for ; Fri, 2 May 2014 10:31:13 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id D7C5F198AC8 for ; Fri, 2 May 2014 10:31:13 -0400 (EDT) X-Virus-Scanned: OK Received: from smtp192.mex05.mlsrvr.com (unknown [184.106.31.85]) by smtp24.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTPS id EB456198AD0 for ; Fri, 2 May 2014 10:31:12 -0400 (EDT) Received: from ORD2MBX04F.mex05.mlsrvr.com ([fe80::1b:21ff:fe97:1a60]) by ORD2HUB13.mex05.mlsrvr.com ([fe80::be30:5bff:feee:e538%15]) with mapi id 14.03.0169.001; Fri, 2 May 2014 09:31:12 -0500 From: "Scott M. Fulton, III" To: "oauth@ietf.org" Thread-Topic: Fierce EComms editor: Concern about public OAuth/OpenID bug reports Thread-Index: Ac9mEqr6qTTpyFNzRy6FEcohvKS+iw== Date: Fri, 2 May 2014 14:31:11 +0000 Message-ID: <47C37C4BB0D82B44BA633EA1FC84C5F077785525@ORD2MBX04F.mex05.mlsrvr.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.227.73.168] Content-Type: multipart/alternative; boundary="_000_47C37C4BB0D82B44BA633EA1FC84C5F077785525ORD2MBX04Fmex05_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/UFSxjxKUoe54H46xW1gMM7xGLGg X-Mailman-Approved-At: Tue, 13 May 2014 08:15:38 -0700 Subject: [OAUTH-WG] Fierce EComms editor: Concern about public OAuth/OpenID bug reports X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 14:32:17 -0000 --_000_47C37C4BB0D82B44BA633EA1FC84C5F077785525ORD2MBX04Fmex05_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gentlepersons: I'm the editor of the FierceEnterpriseCommunications newsletter (http://fie= rceenterprisecommunications.com), and have seen the Web site posted by the = student in China claiming a serious vulnerability in OAuth and OpenID (http= ://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html). I know= it is OAuth's policy not to discuss bugs publicly for obvious reasons, but= I would be very happy to report this claim to be a hoax if this fellow nev= er discussed it with you first (which might have been the responsible thing= to do) and if this claim is being made up. Have you had any communication= with Wang Jing, and do you have any reason to believe his public claims to= be valid? My thanks in advance for any help you can provide. Yours sincerely, Scott M. Fulton, III Editor, FierceEnterpriseCommunications 5664 Fen Court Indianapolis, IN 46220 USA (317) 430-1855 LinkedIn: Scott M. Fulton III Twitter: @SMFulton3 Skype: scott.fulton --_000_47C37C4BB0D82B44BA633EA1FC84C5F077785525ORD2MBX04Fmex05_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Gentlepersons:

 

I’m the editor of the FierceEnterprise= Communications newsletter (http://fierceenterprisecommunications.com), and have seen the Web site posted by the student in China claiming a serious vulnerabili= ty in OAuth and OpenID (http://tetraph.com/covert_redirect/oauth2_op= enid_covert_redirect.html).  I know it is OAuth’s policy not to discuss bugs publicly for obvious r= easons, but I would be very happy to report this claim to be a hoax if this= fellow never discussed it with you first (which might have been the respon= sible thing to do) and if this claim is being made up.  Have you had any communication with Wang Jing, and do= you have any reason to believe his public claims to be valid?

 

My thanks in advance for any help you can pr= ovide.

 

Yours sincerely,

 

Sc= ott M. Fulton, III

Edito= r, FierceEn= terpriseCommunications

5664 = Fen Court

India= napolis, IN  46220  USA

(317)= 430-1855

Linked= In:  Scott M. Fulton III

Twitte= r:  @SMFulton3

Skype:=   scott.fulton

 

--_000_47C37C4BB0D82B44BA633EA1FC84C5F077785525ORD2MBX04Fmex05_-- From nobody Tue May 13 08:15:54 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591471A010D for ; Thu, 8 May 2014 13:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 mUps7m00Mkkh for ; Thu, 8 May 2014 13:10:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FAC1A0125 for ; Thu, 8 May 2014 13:10:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140508201044.18021.30567.idtracker@ietfa.amsl.com> Date: Thu, 08 May 2014 13:10:44 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/rHdckDPmIjIqJU3sVtI99zvqRZw X-Mailman-Approved-At: Tue, 13 May 2014 08:15:35 -0700 Subject: [OAUTH-WG] Milestones changed for oauth WG X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 20:10:57 -0000 Changed milestone "Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard", set due date to July 2014 from September 2013, added draft-ietf-oauth-dyn-reg to milestone. Changed milestone "Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC", set due date to August 2014 from June 2013, added draft-ietf-oauth-use-cases to milestone. Changed milestone "Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard", set due date to December 2014 from July 2013. URL: http://datatracker.ietf.org/wg/oauth/charter/ From nobody Tue May 13 08:15:56 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49801A0119 for ; Thu, 8 May 2014 13:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 g37Vf7JtInQB for ; Thu, 8 May 2014 13:17:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 834D11A011A for ; Thu, 8 May 2014 13:17:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140508201728.17477.98000.idtracker@ietfa.amsl.com> Date: Thu, 08 May 2014 13:17:28 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/UbEb4FxfEcHrULC3w2oGY3i-_8I X-Mailman-Approved-At: Tue, 13 May 2014 08:15:36 -0700 Subject: [OAUTH-WG] Milestones changed for oauth WG X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 20:17:32 -0000 URL: http://datatracker.ietf.org/wg/oauth/charter/ From nobody Tue May 13 08:15:58 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D591A00B2 for ; Thu, 8 May 2014 13:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Rf3xcErOOHVk for ; Thu, 8 May 2014 13:22:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2BB1A00C3 for ; Thu, 8 May 2014 13:22:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140508202226.22781.58260.idtracker@ietfa.amsl.com> Date: Thu, 08 May 2014 13:22:26 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/nt29gwBKx2x0JRvJtOJ7xUoRtKY X-Mailman-Approved-At: Tue, 13 May 2014 08:15:36 -0700 Subject: [OAUTH-WG] Milestones changed for oauth WG X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 20:22:28 -0000 Deleted milestone "Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item". Deleted milestone "Submit 'HTTP Authentication: MAC Authentication' as a working group item". Changed milestone "Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard", added draft-ietf-oauth-saml2-bearer to milestone. Changed milestone "Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard", added draft-ietf-oauth-assertions to milestone. Changed milestone "Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard", added draft-ietf-oauth-json-web-token to milestone. Changed milestone "Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard", added draft-ietf-oauth-jwt-bearer to milestone. Deleted milestone "Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard". URL: http://datatracker.ietf.org/wg/oauth/charter/ From blair.strang@covata.com Mon May 12 23:34:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D291A07D0 for ; Mon, 12 May 2014 23:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 iWYjTDGeJQyW for ; Mon, 12 May 2014 23:34:37 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6F91A03C2 for ; Mon, 12 May 2014 23:34:37 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id 63so8831813qgz.16 for ; Mon, 12 May 2014 23:34:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YLlbvOIKkii//geXywp1lp3xYrUx6fEA9priBOdJnu8=; b=mKXYzmgpBJNkNW4rBrLIhDfYNSmdbQSbwNZVBAhfErE6/Z2ndTxAh+aJgk+uzQXvOn dsYeCONIf+tOxKx4Wi5e1i/daiJn0L+w+gflpYu97vyDMrAd8N3QndIuIcPrKZA2i9PS ydSMue6+fuEnnqoeTNzsWnIYkZJfuiFQe3m7lDxAA4gGRlKjynxtiN/0VDclkadYFOmt lXSYoODjhFoyb105kCxYhi9qTZ13PLCEwcSUUlVnDzD/uvbwil21w936rzlp/dfk2gma VgFkuhFO3xDjiCPE7W3nMsMICROnOcyi7G7EgQkkKJiIBCFa+EduLjKIJr+9rfbnGtpk Gjrg== X-Gm-Message-State: ALoCoQk85IEjHwbKnuFrtw16xsrPkCBfSiyxJ+e1eIGs889VQOLx0qdsvGdZ+tjXpvoMtCWdYtkj MIME-Version: 1.0 X-Received: by 10.229.79.2 with SMTP id n2mr44763756qck.11.1399962870966; Mon, 12 May 2014 23:34:30 -0700 (PDT) Received: by 10.96.151.170 with HTTP; Mon, 12 May 2014 23:34:30 -0700 (PDT) In-Reply-To: <53710CC9.2000600@gmx.net> References: <9378C75B-2146-4E8D-BDD6-B4F495C52B84@oracle.com> <53710CC9.2000600@gmx.net> Date: Tue, 13 May 2014 16:34:30 +1000 Message-ID: From: Blair Strang To: Hannes Tschofenig , Scott Contini Content-Type: multipart/alternative; boundary=001a1133a1a09f7f8804f94241f4 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/X3J3e9LfAQESXlsF88pQjrKj3t0 X-Mailman-Approved-At: Tue, 13 May 2014 08:15:37 -0700 Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: HTTP protocol version in MAC signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 06:35:54 -0000 --001a1133a1a09f7f8804f94241f4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Hannnes, Yes, so in terms of well-defined specs for HTTP request signing, there is basically AWS, OAuth 1.0a HMAC, and the OAuth 2.0 draft HMAC stuff which is looking a bit abandoned. The v2 and v4 signing processes for AWS are documented here. [1] http://docs.aws.amazon.com/general/latest/gr/signature-version-2.html [2] http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html Looking at the slides you sent, my colleague Scott and I have been working on something running along the same lines. This has largely been for internal use, but we have had our eye on a design with general utility. So far we have been working to clearly define *only* how HTTP requests can be authenticated using a JWT/JWS, independent of the issues of key distribution and sessions (an OAuth2 extension is one option for sessions / key agreement, but there are obviously other ways). We actually have a spec and proof of concept in progress for JWS based request signing. We do need some time to clean up the spec for public consumption, but would you be interested in seeing that? Thanks, Blair. ---- Long form details below here ----- Our view is that request authentication (mac/signature) and the session (or key agreement) mechanisms needed to support it are largely orthogonal. We have been working to specify a mechanism for authenticating HTTP requests using JWT/JWS. (The tokens look just like JWTs, but it is better to specify on top of JWS). Our approach was that the client computes a "signature base string" or "string to sign" in a fashion very similar to AWS v2, while adding header signing similar to that in AWS v4. This fixes a gap in the OAuth 1.0a HMAC token spec. The client then embeds a digest of the "signature base string" in a JWS signed by the client, along with several other required fields (e.g. a field identifying the requestor, optional key id, expiry, list of signed http headers, ...) to authenticate the request. The nice thing about embedding the request digest in a JWT/JWS signed payload is that you get all the flexibility of JWS in terms of algorithms. Also, the implementation also comes out very nice, since you need just string processing of the request to get a canonical version plus a digest operation - and the "hard crypto stuff" can be handled by a JWS library. However, there are some constraints in terms of practicality using the JWS standard (not insurmountable, but there): 1. RSA - A client with a private key can easily RSA-sign HTTP requests, but the Authorization: header will be several hundred bytes long due to the size of the RSA signature. Speed is high, but so is bandwidth required. 2. ECDSA - ECDSA produces much smaller payloads (few hundred bytes) but requires much more processing effort (order of milliseconds). 3. HMAC - A shared HMAC key will be the most efficient in terms of speed & storage, but requires additional session establishment dance which is slightly less elegant than a client using a private key directly. Request authorisation using a private key directly works well for server-to-server or "big client" to server, but not so well for mobile with power and bandwidth constraints. In this case, the approach we are taking for a client to bootstrap from possession of a private key is to send an RSA signed request to establish a shared HMAC key, then use HMAC signed requests. Thanks & regards, Blair. -- Blair Strang | Senior Security Engineer Covata | Own Your Data covata.com Level 4 156 Clarence Street | Sydney NSW 2000 =C2=A9 2014 CDHL parent company for all Covata entities On Tue, May 13, 2014 at 4:02 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Phil, > Hi Blair, > > this is a good point. I also don't see a reason why the HTTP protocol > version should be included in the keyed message digest (from a security > point of view). > > It might, however, be worthwhile to point out that we are exploring > different solution directions, as described in this slide deck > http://www.tschofenig.priv.at/oauth/IETF-OAuth-PoP.pptx > > For this reason it might be interesting to know what AWS implements. Do > you guys have a reference? > > Ciao > Hannes > > > On 05/09/2014 05:47 AM, Phil Hunt wrote: > > Fyi > > > > Phil > > > > Begin forwarded message: > > > >> *From:* Blair Strang >> > > >> *Date:* May 8, 2014 at 18:47:58 PDT > >> *Resent-To:* hannes.tschofenig@gmx.net > >> , jricher@mitre.org > >> , phil.hunt@yahoo.com > >> , wmills@yahoo-inc.com > >> > >> *To:* draft-ietf-oauth-v2-http-mac@tools.ietf.org > >> > >> *Subject:* *HTTP protocol version in MAC signatures* > >> > >> Hi, > >> > >> [Not sure if this is the right address to submit this feedback to] > >> > >> Looking > >> over http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05section= 5.2. > >> "MAC Input String", it seems that the HTTP request line is used > >> verbatim during the construction of MAC tokens. > >> > >> Since this includes the transport (HTTP/1.1 versus say HTTP/1.0) it > >> seems that HTTP proxies which run different protocol versions on each > >> leg will break signatures. > >> > >> I would recommend removing the HTTP version from the MAC. The > >> transport is inherently a "per hop" type of thing, while request > >> signatures are conceptually "end to end". > >> > >> I am not aware of any specific security benefits derived from > >> including the HTTP protocol version in the MAC input string. This may > >> be why AWS version 2 and AWS version 4 signatures do not include it. > >> > >> Thanks and regards, > >> > >> Blair. > >> > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > --001a1133a1a09f7f8804f94241f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Hannnes,

Yes, so in terms of well-de= fined specs for HTTP request signing, there is basically AWS, OAuth 1.0a HM= AC, and the OAuth 2.0 draft HMAC stuff which is looking a bit abandoned.

The v2 and v4 signing processes for AWS are documented = here.
= Looking at the slides you sent, my colleague Scott and I have been working = on something running along the same lines. This has largely been for intern= al use, but we have had our eye on a design with general utility.

So far we have been working to clearly define *onl= y* how HTTP requests can be authenticated using a JWT/JWS, independent of t= he issues of key distribution and sessions (an OAuth2 extension is one opti= on for sessions / key agreement, but there are obviously other ways).

We actually have a spec and proof of c= oncept in progress for JWS based request signing. We do need some time to c= lean up the spec for public consumption, but would you be interested in see= ing that?

Thanks,

=C2=A0 =C2=A0 Blair.

---- Long form detail= s below here -----

Our view is that request authentication (mac/signature) and the sessio= n (or key agreement) mechanisms needed to support it are largely orthogonal= .

We have been working to specify a me= chanism for authenticating HTTP requests using JWT/JWS. (The tokens look ju= st like JWTs, but it is better to specify on top of JWS).

Our approach was that the client computes a "signa= ture base string" or "string to sign" in a fashion very simi= lar to AWS v2, while adding header signing similar to that in AWS v4. This = fixes a gap in the OAuth 1.0a HMAC token spec.=C2=A0

The client then embeds a digest of the "signature = base string" in a JWS signed by the client, along with several other r= equired fields (e.g. a field identifying the requestor, optional key id, ex= piry, list of signed http headers, ...) to authenticate the request.

The nice thing about embedding the request digest in a = JWT/JWS signed payload is that you get all the flexibility of JWS in terms = of algorithms.=C2=A0

Also, the implementatio= n also comes out very nice, since you need just string processing of the re= quest to get a canonical version plus a digest operation - and the "ha= rd crypto stuff" can be handled by a JWS library.=C2=A0

However, there are some constraints in terms of p= racticality using the JWS standard (not insurmountable, but there):

1. RSA - A client with a private key can easily RSA-sig= n HTTP requests, but the Authorization: header will be several hundred byte= s long due to the size of the RSA signature. Speed is high, but so is bandw= idth required.

2. ECDSA - ECDSA produces much smaller payloads (few hu= ndred bytes) but requires much more processing effort (order of millisecond= s).

3. HMAC - A shared HMAC key will be the most e= fficient in terms of speed & storage, but requires additional session e= stablishment dance which is slightly less elegant than a client using a pri= vate key directly.

Request authorisation using a private key directly work= s well for server-to-server or "big client" to server, but not so= well for mobile with power and bandwidth constraints. In this case, the ap= proach we are taking for a client to bootstrap from possession of a private= key is to send an RSA signed request to establish a shared HMAC key, then = use HMAC signed requests.

Thanks & regards,

=C2=A0 = =C2=A0 Blair.

--

On Tue, May 13, 2014 at 4:02 AM, Hannes Tschof= enig <hannes.tschofenig@gmx.net> wrote:
Hi Phil,
Hi Blair,

this is a good point. I also don't see a reason why the HTTP protocol version should be included in the keyed message digest (from a security
point of view).

It might, however, be worthwhile to point out that we are exploring
different solution directions, as described in this slide deck
http://www.tschofenig.priv.at/oauth/IETF-OAuth-PoP.pptx

For this reason it might be interesting to know what AWS implements. Do
you guys have a reference?

Ciao
Hannes


On 05/09/2014 05:47 AM, Phil Hunt wrote:
> Fyi
>
> Phil
>
> Begin forwarded message:
>
>> *From:* Blair Strang <blair.strang@covata.com
>> <mailto:blair.strang= @covata.com>>
>> *Date:* May 8, 2014 at 18:47:58 PDT
>> *Resent-To:* hannes.t= schofenig@gmx.net
>> <mailto:hannes.tsc= hofenig@gmx.net>, jricher@mitre= .org
>> <mailto:jricher@mitre.org<= /a>>, phil.hunt@yahoo.com
>> <mailto:phil.hunt@yahoo.= com>, wmills@yahoo-inc.com
>> <mailto:wmills@yahoo-in= c.com>
>> *To:* draft-ietf-oauth-v2-http-mac@tools.ietf.org
>> <mailto:draft-ietf-oauth-v2-http-mac@tools.ietf.org>
>> *Subject:* *HTTP protocol version in MAC signatures*
>>
>> Hi,
>>
>> [Not sure if this is the right address to submit this feedback to]=
>>
>> Looking
>> over http://tools.ietf.org/html/draft-ietf-oauth-v2-= http-mac-05 section 5.2.
>> "MAC Input String", it seems that the HTTP request line = is used
>> verbatim during the construction of MAC tokens.
>>
>> Since this includes the transport (HTTP/1.1 versus say HTTP/1.0) i= t
>> seems that HTTP proxies which run different protocol versions on e= ach
>> leg will break signatures.
>>
>> I would recommend removing the HTTP version from the MAC. The
>> transport is inherently a "per hop" type of thing, while= request
>> signatures are conceptually "end to end".
>>
>> I am not aware of any specific security benefits derived from
>> including the HTTP protocol version in the MAC input string. This = may
>> be why AWS version 2 and AWS version 4 signatures do not include i= t.
>>
>> Thanks and regards,
>>
>> =C2=A0 =C2=A0 Blair.
>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


--001a1133a1a09f7f8804f94241f4-- From nobody Tue May 13 08:28:09 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155291A00DD for ; Tue, 13 May 2014 08:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 Dcjpbh8Dr6ZU for ; Tue, 13 May 2014 08:28:05 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2F21A00E3 for ; Tue, 13 May 2014 08:28:04 -0700 (PDT) X-AuditID: 1209190e-f79946d000000c39-f7-537239fe830c Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id AE.76.03129.EF932735; Tue, 13 May 2014 11:27:58 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s4DFRunE010553; Tue, 13 May 2014 11:27:57 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4DFRp2x001182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 May 2014 11:27:54 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_CF8164B1-FB58-4C88-AE26-F96EC1BB70A8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Justin Richer In-Reply-To: Date: Tue, 13 May 2014 11:27:47 -0400 Message-Id: References: <9378C75B-2146-4E8D-BDD6-B4F495C52B84@oracle.com> <53710CC9.2000600@gmx.net> To: Blair Strang X-Mailer: Apple Mail (2.1874) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOKsWRmVeSWpSXmKPExsUixG6nrvvPsijYYNprSYvVs9YxWSzdeY/V 4uTbV2wWVx4tZHdg8fi6xttj8ab9bB5LlvxkCmCO4rJJSc3JLEst0rdL4MrYsmIzW8HkhYwV K09/ZmtgXNzJ2MXIySEhYCJx4PI+KFtM4sK99WwgtpDAbCaJR316XYxcQPZGRok3n/eyQDg3 mSSWL20Fc5gFJjFKLH/zhR2khVdAT6JpzUQmEFtYwEXi+9kbzCA2m4CqxPyVt8DinAKBEtsO TWABsVmA4rv3fwKzmQXqJaadXMECMcdKYt2FA0wQ2x4xSjTdeg7WLCKgJTFlci8bxK2yEo8+ NLFMYBSYheyQWUgOmQU2OEni789WRghbW2LZwtfMELaBxNPOV6yY4voSb97NgeqVl9j+dg5U 3FJi8cwbLBC2rcStvgVQNXYSj6YtYl3AyL2KUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11gvN7NE LzWldBMjKB45Jfl2MH49qHSIUYCDUYmHd8GzgmAh1sSy4srcQ4ySHExKoryrTIuChfiS8lMq MxKLM+KLSnNSiw8xqgDterRh9QVGKZa8/LxUJRHez3pAdbwpiZVVqUX5MGXSHCxK4rxvra2C hQTSE0tSs1NTC1KLYLIyHBxKErxTLIAaBYtS01Mr0jJzShDSTBychxglOHiAhp8AqeEtLkjM Lc5Mh8ifYtTlaHq3vIVJCOwCKXHepSBFAiBFGaV5cHNg6fUVozjQi8K8i0CqeICpGW7SK6Al TEBLrKTzQZaUJCKkpBoYK8oYVTkNWl29ohhZDL3/5D17LzjfYss99yuRfDybWHVv72TdJeKv +3BtVJayXewN1Tlfnyeeuyd+4YEqU+O29IgGjbWSbwU8DoiLSd6TuVZffCdts6l2XOmLTQeV lCY+r394719xyarSlad4XIwnNqutbYz7fGNVyq9X3Vc0JW59jJu/KOW3EktxRqKhFnNRcSIA YnqKXooDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wvKJRn7bzE820bYP5gyq8LdY4IA Cc: Scott Contini , OAuth WG Subject: Re: [OAUTH-WG] Fwd: HTTP protocol version in MAC signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 15:28:08 -0000 --Apple-Mail=_CF8164B1-FB58-4C88-AE26-F96EC1BB70A8 Content-Type: multipart/alternative; boundary="Apple-Mail=_995C9D50-2028-4816-AFEC-4F650E92B78A" --Apple-Mail=_995C9D50-2028-4816-AFEC-4F650E92B78A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Blair, You=92re right in that the MAC draft is effectively abandoned now as the = WG has moved on to other signed-token mechanisms. As part of that = effort, I=92ve put together a JWS-based HTTP request signature mechanism = (referenced in Hannes=92s presentation): http://tools.ietf.org/id/draft-richer-oauth-signed-http-request-01.html This differs from the AWS spec (submitted as an HTTP Auth WG Draft, as I = understand it: = http://tools.ietf.org/id/draft-cavage-http-signatures-02.html) in that = it uses JWS as the signing mechanism (without a custom HTTP header = format). There=92s still a fair amount of work that needs to be done in = order to get it in shape, but I think that these different methods can = definitely inform each other. =97 Justin On May 13, 2014, at 2:34 AM, Blair Strang = wrote: > Hi Hannnes, >=20 > Yes, so in terms of well-defined specs for HTTP request signing, there = is basically AWS, OAuth 1.0a HMAC, and the OAuth 2.0 draft HMAC stuff = which is looking a bit abandoned. >=20 > The v2 and v4 signing processes for AWS are documented here. > [1] = http://docs.aws.amazon.com/general/latest/gr/signature-version-2.html > [2] = http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html >=20 > Looking at the slides you sent, my colleague Scott and I have been = working on something running along the same lines. This has largely been = for internal use, but we have had our eye on a design with general = utility. >=20 > So far we have been working to clearly define *only* how HTTP requests = can be authenticated using a JWT/JWS, independent of the issues of key = distribution and sessions (an OAuth2 extension is one option for = sessions / key agreement, but there are obviously other ways). >=20 > We actually have a spec and proof of concept in progress for JWS based = request signing. We do need some time to clean up the spec for public = consumption, but would you be interested in seeing that? >=20 > Thanks, >=20 > Blair. >=20 > ---- Long form details below here ----- >=20 > Our view is that request authentication (mac/signature) and the = session (or key agreement) mechanisms needed to support it are largely = orthogonal. >=20 > We have been working to specify a mechanism for authenticating HTTP = requests using JWT/JWS. (The tokens look just like JWTs, but it is = better to specify on top of JWS). >=20 > Our approach was that the client computes a "signature base string" or = "string to sign" in a fashion very similar to AWS v2, while adding = header signing similar to that in AWS v4. This fixes a gap in the OAuth = 1.0a HMAC token spec.=20 >=20 > The client then embeds a digest of the "signature base string" in a = JWS signed by the client, along with several other required fields (e.g. = a field identifying the requestor, optional key id, expiry, list of = signed http headers, ...) to authenticate the request. >=20 > The nice thing about embedding the request digest in a JWT/JWS signed = payload is that you get all the flexibility of JWS in terms of = algorithms.=20 >=20 > Also, the implementation also comes out very nice, since you need just = string processing of the request to get a canonical version plus a = digest operation - and the "hard crypto stuff" can be handled by a JWS = library.=20 >=20 > However, there are some constraints in terms of practicality using the = JWS standard (not insurmountable, but there): >=20 > 1. RSA - A client with a private key can easily RSA-sign HTTP = requests, but the Authorization: header will be several hundred bytes = long due to the size of the RSA signature. Speed is high, but so is = bandwidth required. >=20 > 2. ECDSA - ECDSA produces much smaller payloads (few hundred bytes) = but requires much more processing effort (order of milliseconds). >=20 > 3. HMAC - A shared HMAC key will be the most efficient in terms of = speed & storage, but requires additional session establishment dance = which is slightly less elegant than a client using a private key = directly. >=20 > Request authorisation using a private key directly works well for = server-to-server or "big client" to server, but not so well for mobile = with power and bandwidth constraints. In this case, the approach we are = taking for a client to bootstrap from possession of a private key is to = send an RSA signed request to establish a shared HMAC key, then use HMAC = signed requests. >=20 > Thanks & regards, >=20 > Blair. >=20 > -- > Blair Strang | Senior Security Engineer > Covata | Own Your Data > covata.com >=20 > Level 4 156 Clarence Street | Sydney NSW 2000 > =A9 2014 CDHL parent company for all Covata entities >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Tue, May 13, 2014 at 4:02 AM, Hannes Tschofenig = wrote: > Hi Phil, > Hi Blair, >=20 > this is a good point. I also don't see a reason why the HTTP protocol > version should be included in the keyed message digest (from a = security > point of view). >=20 > It might, however, be worthwhile to point out that we are exploring > different solution directions, as described in this slide deck > http://www.tschofenig.priv.at/oauth/IETF-OAuth-PoP.pptx >=20 > For this reason it might be interesting to know what AWS implements. = Do > you guys have a reference? >=20 > Ciao > Hannes >=20 >=20 > On 05/09/2014 05:47 AM, Phil Hunt wrote: > > Fyi > > > > Phil > > > > Begin forwarded message: > > > >> *From:* Blair Strang >> > > >> *Date:* May 8, 2014 at 18:47:58 PDT > >> *Resent-To:* hannes.tschofenig@gmx.net > >> , jricher@mitre.org > >> , phil.hunt@yahoo.com > >> , wmills@yahoo-inc.com > >> > >> *To:* draft-ietf-oauth-v2-http-mac@tools.ietf.org > >> > >> *Subject:* *HTTP protocol version in MAC signatures* > >> > >> Hi, > >> > >> [Not sure if this is the right address to submit this feedback to] > >> > >> Looking > >> over http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05 = section 5.2. > >> "MAC Input String", it seems that the HTTP request line is used > >> verbatim during the construction of MAC tokens. > >> > >> Since this includes the transport (HTTP/1.1 versus say HTTP/1.0) it > >> seems that HTTP proxies which run different protocol versions on = each > >> leg will break signatures. > >> > >> I would recommend removing the HTTP version from the MAC. The > >> transport is inherently a "per hop" type of thing, while request > >> signatures are conceptually "end to end". > >> > >> I am not aware of any specific security benefits derived from > >> including the HTTP protocol version in the MAC input string. This = may > >> be why AWS version 2 and AWS version 4 signatures do not include = it. > >> > >> Thanks and regards, > >> > >> Blair. > >> > > > > > > _______________________________________________ > > 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=_995C9D50-2028-4816-AFEC-4F650E92B78A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Blair,

You=92re right in that the = MAC draft is effectively abandoned now as the WG has moved on to other = signed-token mechanisms. As part of that effort, I=92ve put together a = JWS-based HTTP request signature mechanism (referenced in Hannes=92s = presentation):


This differs from the AWS spec = (submitted as an HTTP Auth WG Draft, as I understand it: htt= p://tools.ietf.org/id/draft-cavage-http-signatures-02.html) in that = it uses JWS as the signing mechanism (without a custom HTTP header = format). There=92s still a fair amount of work that needs to be done in = order to get it in shape, but I think that these different methods can = definitely inform each other.

 =97 = Justin


On May 13, = 2014, at 2:34 AM, Blair Strang <blair.strang@covata.com> = wrote:

Hi Hannnes,

Yes, so = in terms of well-defined specs for HTTP request signing, there is = basically AWS, OAuth 1.0a HMAC, and the OAuth 2.0 draft HMAC stuff which = is looking a bit abandoned.

The v2 and v4 signing processes for AWS are = documented here.
Looking at the slides = you sent, my colleague Scott and I have been working on something = running along the same lines. This has largely been for internal use, = but we have had our eye on a design with general utility.

So far we have been working to clearly define *only* = how HTTP requests can be authenticated using a JWT/JWS, independent of = the issues of key distribution and sessions (an OAuth2 extension is one = option for sessions / key agreement, but there are obviously other = ways).

We actually have a spec and proof of = concept in progress for JWS based request signing. We do need some time = to clean up the spec for public consumption, but would you be interested = in seeing that?

Thanks,

    = Blair.

---- Long form details below = here -----

Our view is that request authentication (mac/signature) and the = session (or key agreement) mechanisms needed to support it are largely = orthogonal.

We have been = working to specify a mechanism for authenticating HTTP requests using = JWT/JWS. (The tokens look just like JWTs, but it is better to specify on = top of JWS).

Our approach was that the client computes a = "signature base string" or "string to sign" in a fashion very similar to = AWS v2, while adding header signing similar to that in AWS v4. This = fixes a gap in the OAuth 1.0a HMAC token spec. 

The client then embeds a digest of the "signature = base string" in a JWS signed by the client, along with several other = required fields (e.g. a field identifying the requestor, optional key = id, expiry, list of signed http headers, ...) to authenticate the = request.

The nice thing about embedding the request digest in = a JWT/JWS signed payload is that you get all the flexibility of JWS in = terms of algorithms. 

Also, the = implementation also comes out very nice, since you need just string = processing of the request to get a canonical version plus a digest = operation - and the "hard crypto stuff" can be handled by a JWS = library. 

However, there are some constraints in = terms of practicality using the JWS standard (not insurmountable, but = there):

1. RSA - A client with a private key can easily = RSA-sign HTTP requests, but the Authorization: header will be several = hundred bytes long due to the size of the RSA signature. Speed is high, = but so is bandwidth required.

2. ECDSA - ECDSA produces much smaller payloads (few = hundred bytes) but requires much more processing effort (order of = milliseconds).

3. HMAC - A shared HMAC key will = be the most efficient in terms of speed & storage, but requires = additional session establishment dance which is slightly less elegant = than a client using a private key directly.

Request authorisation using a private key directly = works well for server-to-server or "big client" to server, but not so = well for mobile with power and bandwidth constraints. In this case, the = approach we are taking for a client to bootstrap from possession of a = private key is to send an RSA signed request to establish a shared HMAC = key, then use HMAC signed requests.

Thanks & = regards,

    = Blair.

--
B= lair Strang | Senior Security Engineer
C= ovata | Own Your Data
<= a href=3D"http://covata.com/" target=3D"_blank" = style=3D"font-family:arial,sans-serif;font-size:13px">covata.com

<= span = style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">L= evel 4 156 Clarence Street | Sydney NSW 2000
=A9= 2014 CDHL parent company for all Covata = entities









On Tue, May 13, = 2014 at 4:02 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Phil,
Hi Blair,

this is a good point. I also don't see a reason why the HTTP = protocol
version should be included in the keyed message digest (from a = security
point of view).

It might, however, be worthwhile to point out that we are exploring
different solution directions, as described in this slide deck
http://www.tschofenig.priv.at/oauth/IETF-OAuth-PoP.pptx<= /a>

For this reason it might be interesting to know what AWS implements. = Do
you guys have a reference?

Ciao
Hannes


On 05/09/2014 05:47 AM, Phil Hunt wrote:
> Fyi
>
> Phil
>
> Begin forwarded message:
>
>> *From:* Blair Strang <blair.strang@covata.com
>> <mailto:blair.strang@covata.com>>= ;
>> *Date:* May 8, 2014 at 18:47:58 PDT
>> *Resent-To:* hannes.tschofenig@gmx.net >> <mailto:hannes.tschofenig@gmx.net>= ;, jricher@mitre.org
>> <mailto:jricher@mitre.org>, phil.hunt@yahoo.com
>> <mailto:phil.hunt@yahoo.com>, wmills@yahoo-inc.com
>> <mailto:wmills@yahoo-inc.com>
>> *To:* draft-ietf-oau= th-v2-http-mac@tools.ietf.org
>> <mailto:draft-ietf-oau= th-v2-http-mac@tools.ietf.org>
>> *Subject:* *HTTP protocol version in MAC signatures*
>>
>> Hi,
>>
>> [Not sure if this is the right address to submit this feedback = to]
>>
>> Looking
>> over http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-= 05 section 5.2.
>> "MAC Input String", it seems that the HTTP request line is = used
>> verbatim during the construction of MAC tokens.
>>
>> Since this includes the transport (HTTP/1.1 versus say = HTTP/1.0) it
>> seems that HTTP proxies which run different protocol versions = on each
>> leg will break signatures.
>>
>> I would recommend removing the HTTP version from the MAC. = The
>> transport is inherently a "per hop" type of thing, while = request
>> signatures are conceptually "end to end".
>>
>> I am not aware of any specific security benefits derived = from
>> including the HTTP protocol version in the MAC input string. = This may
>> be why AWS version 2 and AWS version 4 signatures do not = include it.
>>
>> Thanks and regards,
>>
>>     Blair.
>>
>
>
> _______________________________________________
> 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=_995C9D50-2028-4816-AFEC-4F650E92B78A-- --Apple-Mail=_CF8164B1-FB58-4C88-AE26-F96EC1BB70A8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTcjnzAAoJEDPAngkbd+w9BlQIAK1iWQCAVv7vF32qvUAKT1wt R1ssnh6kOlpq4kvcO4Do1yUKj+L70VinihPlu3vkJ4Rl0w6l7e2iAuUYqzReVHps v7YI/I9MNgkKWEpe08DjRHpoONJu5X9ZsoRo5Z0J8CVlKfAhiCBNF1dZOSvgh0ta O3XTWAPmmH0KzWYSPY1nfy2C5ODSfeVkjYS1KNtyxczYrL7o3iFpdwg3Mv4INWel UZbfSKqlxTeAharJ5q/Jeke+qRVqCrFA+8hBQ19vy2/vM//uyvaAOHQdbRH+GftG FODeArxgw3wkHqC2NHWErd0ba9Z9gG8sLYiFasuv9Ho1R3oBBHGRzXD6L5j6zKk= =j4ZP -----END PGP SIGNATURE----- --Apple-Mail=_CF8164B1-FB58-4C88-AE26-F96EC1BB70A8-- From nobody Tue May 13 08:33:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4131A00B2 for ; Tue, 13 May 2014 08:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 m1SAx-nKAoUP for ; Tue, 13 May 2014 08:33:10 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 5472E1A0102 for ; Tue, 13 May 2014 08:33:07 -0700 (PDT) X-AuditID: 12074424-f79546d000000c5e-75-53723b2cff05 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 2C.AE.03166.C2B32735; Tue, 13 May 2014 11:33:00 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s4DFWxFx011528; Tue, 13 May 2014 11:32:59 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4DFWuGN005063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 May 2014 11:32:58 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_22B870BD-48C0-469B-9EDA-D384E0FA2B6E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Justin Richer In-Reply-To: <53710BF9.7090701@gmx.net> Date: Tue, 13 May 2014 11:32:53 -0400 Message-Id: <750D6D1F-AF43-4A8D-A377-65723AE422F1@mit.edu> References: <536BFA23.9020900@digitalbazaar.com> <53710BF9.7090701@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1874) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPKsWRmVeSWpSXmKPExsUixG6nrqtjXRRs0HjB3GLpznusFiffvmKz WDC/kd2B2WPxpv1sHkuW/GTy+Pj0FksAcxSXTUpqTmZZapG+XQJXRvPSt2wFd7Qq5u98ztzA OEWli5GTQ0LAROLStD5WCFtM4sK99WxdjFwcQgKzmSS+XO6BcjYySrztn84MUiUkcJNJYuaK MJAEs8AkRolHN/rZQBK8AnoSTWsmMoHYwgKxEn8unGAEsdkEVCXmr7wFFucUUJc4N+kb2CAW oPjlp9fYQWxmAXuJaasbgOIcQHOsJPo3JEHsqpU4dm01WLmIgKHE9ZnToS6VlXj0oYllAqPA LGRnzEJyxiywsdoSyxa+ZoawDSSedr5ihbDlJba/nQMVt5RYPPMGC4RtK3GrbwFUr53Eo2mL WBcwcqxilE3JrdLNTczMKU5N1i1OTszLSy3SNdfLzSzRS00p3cQIjhsXlR2MzYeUDjEKcDAq 8fD+eFEQLMSaWFZcmXuIUZKDSUmUd5VpUbAQX1J+SmVGYnFGfFFpTmrxIUYVoF2PNqy+wCjF kpefl6okwvtZD6iONyWxsiq1KB+mTJqDRUmc9621VbCQQHpiSWp2ampBahFMVoaDQ0mCt8oK qFGwKDU9tSItM6cEIc3EwXmIUYKDB2h4NkgNb3FBYm5xZjpE/hSjopQ4rwRIQgAkkVGaB9cL S3evGMWB3hLmbQWp4gGmSrjuV0CDmYAGW0nngwwuSURISTUwrpj7VVI1eoeC0ZonCdZ3Su6u XlxxPafaYt6Thlq+qj9NgkvfCDcnTX16P9rooZh6fOg+eYtF/q/3331yo0hfzjFkmfVpxtXK N/TimZtUC/UuVKq0rPX4/Ellyqm/h9sOVxS+CJrqY2HYVbvne/vl7zeObc/hihb+vmL7+RM8 L66F28W9eiFhqcRSnJFoqMVcVJwIAIwHmQRSAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jK21EO4tIbTqjXV5fhGNogmk27M Cc: OAuth WG Subject: Re: [OAUTH-WG] [http-auth] Review Request for third draft of "Signing HTTP Messages" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 15:33:12 -0000 --Apple-Mail=_22B870BD-48C0-469B-9EDA-D384E0FA2B6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 They=92re similar in that they both take elements from the HTTP message = and create a signature on them, and they use the same =93list the order = of the elements=94 trick to avoid normalization to a large extent. The = main difference is that my draft uses JWS as the signature (and = ultimately transport) mechanism and the Cavage draft (and the AWS method = it is born from, as I understand it) uses a new HTTP auth header format, = much like OAuth 1.0 and the (old, dusty, abandoned, = can-we-stop-bringing-it-up) MAC draft. My original (unpublished) version = of the draft didn=92t actually specify or care how you got the key, as I = think that HTTP signing is a general mechanism. That said, there seems to be a lot of interest in solving this case that = OAuth 1.0 managed to get somewhat right-ish. =97 Justin On May 12, 2014, at 1:59 PM, Hannes Tschofenig = wrote: > Conceptually, draft-cavage-http-signatures-02 is the same as OAuth = 1.0. > Therefore, the symmetric key part of the document is the same as the = MAC > token. >=20 > Not quite sure why the authors have not read the OAuth work. >=20 > On 05/09/2014 01:22 AM, Phil Hunt wrote: >> How does this compare with justin's draft? >>=20 >> Phil >>=20 >> Begin forwarded message: >>=20 >>> *From:* Manu Sporny >> > >>> *Date:* May 8, 2014 at 14:41:55 PDT >>> *To:* IETF HTTP Auth > >>> *Cc:* Julian Reschke >> >, Mark Nottingham >> >, Web Payments CG >> > >>> *Subject:* *[http-auth] Review Request for third draft of "Signing >>> HTTP Messages"* >>>=20 >>> After feedback from Mark Nottingham[1], Julian Reschke[2], folks in = the >>> HTTP Auth WG, and people in the Web Payments CG, we've modified the = HTTP >>> Signatures specification in the following ways: >>>=20 >>> 1. The specification has been renamed to "Signing HTTP Messages". >>> 2. The specification now covers both a signature-based Authorization >>> mechanism (client-to-server) as well as a general mechanism to sign >>> HTTP messages (client-to-server and server-to-client). >>> 3. A new "Signature" header has been introduced. >>> 4. The layout has been modified heavily to streamline the = information >>> conveyed in the spec. >>> 5. New registries have been created for the algorithms referred to = in >>> the specification. >>> 6. We're now more specific in the way certain canonicalizations are >>> performed. >>> 7. More examples have been added, including how to digitally sign >>> the body of an HTTP message. >>>=20 >>> The basic mechanism of generating the signatures has not changed = (and >>> has been stable for over a year). >>>=20 >>> The newest spec can be found here: >>>=20 >>> http://tools.ietf.org/html/draft-cavage-http-signatures-02 >>>=20 >>> The diff is here: >>>=20 >>> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-cavage-http-signatures-02.txt >>>=20 >>> Matt, Yoav, Kathleen, if there are no show stopping review comments, = I'd >>> like to push this spec onto the RFC track in the HTTP Auth WG, or >>> HTTPbis/2 WG. It'll be ready for a LC in a month or two. I realize = that >>> HTTP Auth may be shutting down next month, so what's the next step = to >>> get the HTTP Signatures spec further down the IETF RFC track? >>>=20 >>> -- manu >>>=20 >>> [1] >>> = http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0038.html >>> [2] >>> = http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0036.html >>>=20 >>> --=20 >>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) >>> Founder/CEO - Digital Bazaar, Inc. >>> blog: The Marathonic Dawn of Web Payments >>> http://manu.sporny.org/2014/dawn-of-web-payments/ >>>=20 >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >>=20 >>=20 >> _______________________________________________ >> 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=_22B870BD-48C0-469B-9EDA-D384E0FA2B6E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTcjslAAoJEDPAngkbd+w9pXAIAJzv4oJfSyun9GBw2c1nUtUa dHSTPnvVSWOAr+NRf1db7/xuhML05VbBhFF+4MXYfArj1OwK2pipGyf9Zbaz+xzg bL2tdXPdpN4VWB32HvbuFl2fmPbRGkyc9J+PxBS1miJqn/yvw10b7sdVyVOdIote LJitl3reTEbnr+zqU6H7vl9kFLWPQHlYXBO/l44OQ8htlQHETA0VLOTXlrxnOdHG 96HMsC48ZnciV8wcVTsyRMbilu81I1jYIM3MLrQkx7khL1sATc/qE4Ct9AAbDU/G u8KLHYK4kDOZJlvRoVUuWCyMtpERTR2cVn5ZT+ShKBf+BKeoqTxzvLzSCQ/gBZY= =6nWe -----END PGP SIGNATURE----- --Apple-Mail=_22B870BD-48C0-469B-9EDA-D384E0FA2B6E-- From nobody Tue May 13 08:33:20 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062031A0135 for ; Tue, 13 May 2014 08:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 ihn-r2WJVwHR for ; Tue, 13 May 2014 08:33:13 -0700 (PDT) Received: from nm41-vm10.bullet.mail.bf1.yahoo.com (nm41-vm10.bullet.mail.bf1.yahoo.com [216.109.114.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4175E1A0102 for ; Tue, 13 May 2014 08:33:13 -0700 (PDT) Received: from [66.196.81.172] by nm41.bullet.mail.bf1.yahoo.com with NNFMP; 13 May 2014 15:33:06 -0000 Received: from [98.139.212.208] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 13 May 2014 15:33:06 -0000 Received: from [127.0.0.1] by omp1017.mail.bf1.yahoo.com with NNFMP; 13 May 2014 15:33:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 27509.37632.bm@omp1017.mail.bf1.yahoo.com Received: (qmail 15006 invoked by uid 60001); 13 May 2014 15:33:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1399995185; bh=kRfs7gOETXq5sFu9bqdG9DVuFegZA+aKSILoL2TG0ZY=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=zq+V1Eh5EoRN8Pbz10kS4nwXG7sSYrSFfJ09cBAeuuItSSBGkWgIsd2qtzSSTm7xXEkfFcnWvx/qaOJ34TTAt8I/JhwH/ygBdPhPdTRb/y/im0KnU9ENu/VrUCOyXam+VXbZ0JvsZTjO3q9mE7/8MvfKfk7bmKKFAGui7w6QPGg= X-YMail-OSG: onkC_C8VM1kDB5l_WfU3zHJ5rZtYtdTYYxtSzc1ECORenyu 4ju9qtuYpXDcVioEmg5NE7x67s0BWdoS44.z5_b1v6es.oy6DWOfWH7zniRj 9jTIXAxkGWV5.H4UB1n4n9jCTczW_0Ly4PpUbnyccVUwaylG1SEspfRTyMKy .NE96meDgyduZ.8Q_56fNPgOSYGt76OX_pGPXsrybGbHb6_S4mbHIlRCkB2Q 44jOtarW3e.rpf4kgHWhlKG_RZuuE_2subIscZGLsH9eUwIUgpCvKOratv4g _rdp35k_GZarHIAoClXUnFnvenplISGEV2tIHZ6NH6EWl2NQV_7_RXEgmxfN Vg3K_G2.LbVEv1.2xohKX8fh0u1mUDp1GSn5VkyQ0L42h9kgeqq3HAoWyae8 Sg8YofHAMbJNNTVg2lijQQWq87psin_oc1q8ojmpby5WZAii2EqLDMFaIlJM sPYURVxU7cXINk5jN6ZmvzWrZDy0_ieDM_PluVmOdX.i4Wrw7tftqU07v6Uu 4eHbE08OvylQOKbv8qA2hgAS.lOA2vt8lHGPQiyqGjZ_5O31uvfQVcruuuqf hT5ndOGif3ONlAefF_TtP0IA2OFxfBlvKvo.PNTkL9Q_boQxrEPMjuoNYR7m LtMRLr3wFSobDRg4eo2l2yPHKbEi6aM0EUIA9zD6eQcyU6kpEovT8_UdNllt F7NnNCRgVc2_4mBcXHZEd.PGsSH_TqV9QlblMXdVdq7uG.IvdUz59MhMcFNi A5PYtWUASo4aqtH0UJQ1HiNMs5EI5gkRB9DBkRJbgHCBF6A0wELKXGsh2f31 TJ9c- Received: from [98.139.248.67] by web142803.mail.bf1.yahoo.com via HTTP; Tue, 13 May 2014 08:33:05 PDT X-Rocket-MIMEInfo: 002.001, VGhlIE1BQyBkcmFmdCBoYXMgYmVlbiBpZGxlIGZvciBhIHdoaWxlLCB0aGUgbWluZHNoYXJlIGhhcyBiZWVuIG9uIFBPUCB0b2tlbnMuIMKgQWxzbyB3ZSBoYXZlbid0IGhhZCBhbnlvbmUgbG9va2luZyB0byBhY3RpdmVseSBhZG9wdCBhIHNpZ25lZCBIVFRQIHRva2VuIHByb2ZpbGUuIMKgWW91J3JlIHNvbHZpbmcgYSByZWFsIHByb2JsZW0gYW5kIGhhdmUgYSBuZWVkIGZvciBpdCwgc28gcmVraW5kbGluZyB0aGlzIGluIHNvbWUgZm9ybSB3b3VsZCBiZSBnb29kLiDCoEkndmUgYWx3YXlzIG1haW50YWluZWQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <9378C75B-2146-4E8D-BDD6-B4F495C52B84@oracle.com> <53710CC9.2000600@gmx.net> Message-ID: <1399995185.25417.YahooMailNeo@web142803.mail.bf1.yahoo.com> Date: Tue, 13 May 2014 08:33:05 -0700 (PDT) From: Bill Mills To: Blair Strang , Hannes Tschofenig , Scott Contini In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="905790552-1721692184-1399995185=:25417" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6qpUnF0831KkMw3C7Ry5hQLaoB0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: HTTP protocol version in MAC signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 15:33:17 -0000 --905790552-1721692184-1399995185=:25417 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The MAC draft has been idle for a while, the mindshare has been on POP toke= ns. =A0Also we haven't had anyone looking to actively adopt a signed HTTP t= oken profile. =A0You're solving a real problem and have a need for it, so r= ekindling this in some form would be good. =A0I've always maintained that w= e need a signed token type because we have use cases where we use OAuth 1.0= a for Flickr and strategically I'd like to get something in the OAuth 2 fra= mework to replace it.=0A=0AA POP token could include an encrypted HMAC secr= et, but I'm not sure if the extra decrypt required at the server kills the = benefit of the speed of HMAC.=0A=0A=0AOn Tuesday, May 13, 2014 8:16 AM, Bla= ir Strang wrote:=0A =0AHi Hannnes,=0A=0AYes, so i= n terms of well-defined specs for HTTP request signing, there is basically = AWS, OAuth 1.0a HMAC, and the OAuth 2.0 draft HMAC stuff which is looking a= bit abandoned.=0A=0AThe v2 and v4 signing processes for AWS are documented= here.=0A[1]=A0http://docs.aws.amazon.com/general/latest/gr/signature-versi= on-2.html=0A=0A[2]=A0http://docs.aws.amazon.com/general/latest/gr/signature= -version-4.html=0A=0ALooking at the slides you sent, my colleague Scott and= I have been working on something running along the same lines. This has la= rgely been for internal use, but we have had our eye on a design with gener= al utility.=0A=0ASo far we have been working to clearly define *only* how H= TTP requests can be authenticated using a JWT/JWS, independent of the issue= s of key distribution and sessions (an OAuth2 extension is one option for s= essions / key agreement, but there are obviously other ways).=0A=0A=0AWe ac= tually have a spec and proof of concept in progress for JWS based request s= igning. We do need some time to clean up the spec for public consumption, b= ut would you be interested in seeing that?=0A=0AThanks,=0A=0A=A0 =A0 Blair.= =0A=0A---- Long form details below here -----=0A=0AOur view is that request= authentication (mac/signature) and the session (or key agreement) mechanis= ms needed to support it are largely orthogonal.=0A=0AWe have been working t= o specify a mechanism for authenticating HTTP requests using JWT/JWS. (The = tokens look just like JWTs, but it is better to specify on top of JWS).=0A= =0AOur approach was that the client computes a "signature base string" or "= string to sign" in a fashion very similar to AWS v2, while adding header si= gning similar to that in AWS v4. This fixes a gap in the OAuth 1.0a HMAC to= ken spec.=A0=0A=0AThe client then embeds a digest of the "signature base st= ring" in a JWS signed by the client, along with several other required fiel= ds (e.g. a field identifying the requestor, optional key id, expiry, list o= f signed http headers, ...) to authenticate the request.=0A=0AThe nice thin= g about embedding the request digest in a JWT/JWS signed payload is that yo= u get all the flexibility of JWS in terms of algorithms.=A0=0A=0AAlso, the = implementation also comes out very nice, since you need just string process= ing of the request to get a canonical version plus a digest operation - and= the "hard crypto stuff" can be handled by a JWS library.=A0=0A=0AHowever, = there are some constraints in terms of practicality using the JWS standard = (not insurmountable, but there):=0A=0A1. RSA - A client with a private key = can easily RSA-sign HTTP requests, but the Authorization: header will be se= veral hundred bytes long due to the size of the RSA signature. Speed is hig= h, but so is bandwidth required.=0A=0A2. ECDSA - ECDSA produces much smalle= r payloads (few hundred bytes) but requires much more processing effort (or= der of milliseconds).=0A=0A3. HMAC - A shared HMAC key will be the most eff= icient in terms of speed & storage, but requires additional session establi= shment dance which is slightly less elegant than a client using a private k= ey directly.=0A=0ARequest authorisation using a private key directly works = well for server-to-server or "big client" to server, but not so well for mo= bile with power and bandwidth constraints. In this case, the approach we ar= e taking for a client to bootstrap from possession of a private key is to s= end an RSA signed request to establish a shared HMAC key, then use HMAC sig= ned requests.=0A=0AThanks & regards,=0A=0A=A0 =A0 Blair.=0A=0A--=0ABlair St= rang | Senior Security Engineer=0ACovata | Own Your Data=0Acovata.com=0A=0A= Level 4 156 Clarence Street | Sydney NSW 2000=0A=A9 2014 CDHL parent compan= y for all Covata entities=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0AOn Tue, May 13= , 2014 at 4:02 AM, Hannes Tschofenig wrote:=0A= =0AHi Phil,=0A>Hi Blair,=0A>=0A>this is a good point. I also don't see a re= ason why the HTTP protocol=0A>version should be included in the keyed messa= ge digest (from a security=0A>point of view).=0A>=0A>It might, however, be = worthwhile to point out that we are exploring=0A>different solution directi= ons, as described in this slide deck=0A>http://www.tschofenig.priv.at/oauth= /IETF-OAuth-PoP.pptx=0A>=0A>For this reason it might be interesting to know= what AWS implements. Do=0A>you guys have a reference?=0A>=0A>Ciao=0A>Hanne= s=0A>=0A>=0A>On 05/09/2014 05:47 AM, Phil Hunt wrote:=0A>> Fyi=0A>>=0A>> Ph= il=0A>>=0A>> Begin forwarded message:=0A>>=0A>>> *From:* Blair Strang >> >=0A>>> *Date:* M= ay 8, 2014 at 18:47:58 PDT=0A>>> *Resent-To:* hannes.tschofenig@gmx.net=0A>= >> , jricher@mitre.org=0A>>> , phil.hunt@yahoo.com=0A>>> , wmi= lls@yahoo-inc.com=0A>>> =0A>>> *To:* draft-iet= f-oauth-v2-http-mac@tools.ietf.org=0A>>> =0A>>> *Subject:* *HTTP protocol version in MAC signature= s*=0A>=0A>>>=0A>>> Hi,=0A>>>=0A>>> [Not sure if this is the right address t= o submit this feedback to]=0A>>>=0A>>> Looking=0A>>> over http://tools.ietf= .org/html/draft-ietf-oauth-v2-http-mac-05 section 5.2.=0A>>> "MAC Input Str= ing", it seems that the HTTP request line is used=0A>>> verbatim during the= construction of MAC tokens.=0A>>>=0A>>> Since this includes the transport = (HTTP/1.1 versus say HTTP/1.0) it=0A>>> seems that HTTP proxies which run d= ifferent protocol versions on each=0A>>> leg will break signatures.=0A>>>= =0A>>> I would recommend removing the HTTP version from the MAC. The=0A>>> = transport is inherently a "per hop" type of thing, while request=0A>>> sign= atures are conceptually "end to end".=0A>>>=0A>>> I am not aware of any spe= cific security benefits derived from=0A>>> including the HTTP protocol vers= ion in the MAC input string. This may=0A>>> be why AWS version 2 and AWS ve= rsion 4 signatures do not include it.=0A>>>=0A>>> Thanks and regards,=0A>>>= =0A>>> =A0 =A0 Blair.=0A>>>=0A>>=0A>>=0A>> ________________________________= _______________=0A>> OAuth mailing list=0A>> OAuth@ietf.org=0A>> https://ww= w.ietf.org/mailman/listinfo/oauth=0A>>=0A>=0A>=0A=0A=0A____________________= ___________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps:/= /www.ietf.org/mailman/listinfo/oauth --905790552-1721692184-1399995185=:25417 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The MAC draft has been idle for a while, the minds= hare has been on POP tokens.  Also we haven't had anyone looking to ac= tively adopt a signed HTTP token profile.  You're solving a real probl= em and have a need for it, so rekindling this in some form would be good. &= nbsp;I've always maintained that we need a signed token type because we hav= e use cases where we use OAuth 1.0a for Flickr and strategically I'd like t= o get something in the OAuth 2 framework to replace it.

A POP token could include = an encrypted HMAC secret, but I'm not sure if the extra decrypt required at= the server kills the benefit of the speed of HMAC.

On Tuesday, May 13, = 2014 8:16 AM, Blair Strang <blair.strang@covata.com> wrote:
Hi Hannnes,

Yes, so in ter= ms of well-defined specs for HTTP request signing, there is basically AWS, = OAuth 1.0a HMAC, and the OAuth 2.0 draft HMAC stuff which is looking a bit abandoned.=
=0A

The v2 and v4 signing processes= for AWS are documented here.
Looking at the slides you sent, my colleague= Scott and I have been working on something running along the same lines. T= his has largely been for internal use, but we have had our eye on a design = with general utility.
=0A=0A

So= far we have been working to clearly define *only* how HTTP requests can be= authenticated using a JWT/JWS, independent of the issues of key distributi= on and sessions (an OAuth2 extension is one option for sessions / key agree= ment, but there are obviously other ways).
=0A

We actually have a spec and proof = of concept in progress for JWS based request signing. We do need some time = to clean up the spec for public consumption, but would you be interested in= seeing that?
=0A

T= hanks,

 =   Blair.

---- Long= form details below here -----

=0A<= div>Our view is that request authentication (mac/signature) and the session= (or key agreement) mechanisms needed to support it are largely orthogonal.=

We have been work= ing to specify a mechanism for authenticating HTTP requests using JWT/JWS. = (The tokens look just like JWTs, but it is better to specify on top of JWS)= .
=0A

Our approach was that the clie= nt computes a "signature base string" or "string to sign" in a fashion very= similar to AWS v2, while adding header signing similar to that in AWS v4. = This fixes a gap in the OAuth 1.0a HMAC token spec. 
=0A

The client then embeds a digest of the "signature= base string" in a JWS signed by the client, along with several other requi= red fields (e.g. a field identifying the requestor, optional key id, expiry= , list of signed http headers, ...) to authenticate the request.
=0A
The nice thing about embedding the request= digest in a JWT/JWS signed payload is that you get all the flexibility of = JWS in terms of algorithms. 

Also, the implementation also comes out very nice, since you need= just string processing of the request to get a canonical version plus a di= gest operation - and the "hard crypto stuff" can be handled by a JWS librar= y. 
=0A

However, the= re are some constraints in terms of practicality using the JWS standard (no= t insurmountable, but there):
=0A

1.= RSA - A client with a private key can easily RSA-sign HTTP requests, but t= he Authorization: header will be several hundred bytes long due to the size= of the RSA signature. Speed is high, but so is bandwidth required.
= =0A=0A

2. ECDSA - ECDSA produces much sma= ller payloads (few hundred bytes) but requires much more processing effort = (order of milliseconds).

3. HMAC - = A shared HMAC key will be the most efficient in terms of speed & storag= e, but requires additional session establishment dance which is slightly le= ss elegant than a client using a private key directly.
=0A=0A

Request authorisation using a private key directl= y works well for server-to-server or "big client" to server, but not so wel= l for mobile with power and bandwidth constraints. In this case, the approa= ch we are taking for a client to bootstrap from possession of a private key= is to send an RSA signed request to establish a shared HMAC key, then use = HMAC signed requests.
=0A=0A

Thanks = & regards,

    Blair.=

--
Blair St= rang | Senior Security Engineer
=0ACovata | Own Your Data
covata.com
=0A
Level 4 156 Clar= ence Street | Sydney NSW 2000
=0A=A9 2014 CDHL parent company for all Covata entities





=0A


=


On Tue, May 13, 2014 at 4:02 A= M, Hannes Tschofenig <hannes.tschofenig@gmx.net> w= rote:
=0A
Hi = Phil,
=0AHi Blair,
=0A
=0Athis is a good point. I also don't see a reason why the HTTP protocol<= br clear=3D"none">=0Aversion should be included in the keyed message digest= (from a security
=0Apoint of view).
= =0A
=0AIt might, however, be worthwhile to point out that= we are exploring
=0Adifferent solution directions, as de= scribed in this slide deck
=0Ahttp://www.tschofenig.priv.at/oauth/IETF-OAuth-PoP.pptx
=0A
=0AFor this reason it might be i= nteresting to know what AWS implements. Do
=0Ayou guys ha= ve a reference?
=0A
=0ACiao
=0AHannes
=0A
=0A
=0AOn 05/09/2014 05:47 AM, Phil Hunt wrote:
=0A> F= yi
=0A>
=0A> Phil
=0A>
=0A> Begin forwarded message:
=0A>
=0A>> *From:* Blair Strang <blair.strang@covata.= com
=0A>> <mailto:blair.strang@covata.com>>
=0A>> *Date:* May 8, 2014 at 18:47:58 PDT
=0A>> *Resent-To:* hannes.tschofenig@gmx.net
=0A&= gt;> <mailto:hannes.tschofenig@gmx.net>, jricher@mitre.org
=0A>> <m= ailto:jricher@mitre.org>, phil.hunt@yahoo= .com
=0A>> <mailto:phil.hunt@yahoo.com>, wmills@yahoo-inc.com
=0A>> <mailto:wmills@yahoo-inc.com>
=0A>> *To:* draft-ietf-oauth-v2-http-mac@tools.ietf.org
=0A>> <mailto:draft-ietf-= oauth-v2-http-mac@tools.ietf.org>
=0A>> *Sub= ject:* *HTTP protocol version in MAC signatures*
=0A
=
>>
=0A>> Hi,=0A>>
=0A>> [Not sure if thi= s is the right address to submit this feedback to]
=0A>= ;>
=0A>> Looking
=0A>> o= ver http://tools.ietf.org/htm= l/draft-ietf-oauth-v2-http-mac-05 section 5.2.
=0A>= ;> "MAC Input String", it seems that the HTTP request line is used
=0A>> verbatim during the construction of MAC tokens.=0A>>
=0A>> Since this includ= es the transport (HTTP/1.1 versus say HTTP/1.0) it
=0A>= ;> seems that HTTP proxies which run different protocol versions on each=
=0A>> leg will break signatures.
=0A>>
=0A>> I would recommend removing the H= TTP version from the MAC. The
=0A>> transport is in= herently a "per hop" type of thing, while request
=0A>= > signatures are conceptually "end to end".
=0A>>= ;
=0A>> I am not aware of any specific security ben= efits derived from
=0A>> including the HTTP protoco= l version in the MAC input string. This may
=0A>> b= e why AWS version 2 and AWS version 4 signatures do not include it.
=0A>>
=0A>> Thanks and regards,=0A>>
=0A>>     Bla= ir.
=0A>>
=0A>
=0A>
=0A
> __________________________= _____________________
=0A> OAuth mailing list
=0A> OAuth@ietf.org=
=0A> https://www.i= etf.org/mailman/listinfo/oauth
=0A>
=0A
=0A


__________= _____________________________________
OAuth mailing list<= br clear=3D"none">OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=

--905790552-1721692184-1399995185=:25417-- From nobody Tue May 13 09:20:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059A21A00DD for ; Tue, 13 May 2014 09:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 q6z6mGN4k5OB for ; Tue, 13 May 2014 09:20:44 -0700 (PDT) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) by ietfa.amsl.com (Postfix) with ESMTP id B674C1A0087 for ; Tue, 13 May 2014 09:20:43 -0700 (PDT) Received: from [66.196.81.171] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 13 May 2014 15:50:08 -0000 Received: from [98.139.212.196] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 13 May 2014 15:50:08 -0000 Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 13 May 2014 15:50:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 214583.53317.bm@omp1005.mail.bf1.yahoo.com Received: (qmail 64315 invoked by uid 60001); 13 May 2014 15:50:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1399996208; bh=39eTpoYU1b5XVhvSpDUHVnpOW+yKj1ITwkUvYxypfMo=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nDzeAEisp/9j4/H5LLj26gCTYzVBm7Y8HsnHGknJCIR/LyJoDqmfMQlzaexmgtlOjWccDqPrYV8wBtha6Wm3KkYDEZwe8HEyfDpg6yK7AcEODUFAeDBExvKXNqzxzf+qtVj3owRv3fMOImBX+YK2RPDTuUGrfLTb1Sc5WKXkHU4= X-YMail-OSG: _ymD86gVM1mnmDLyxhr30DGRfNNPQN4Jm3CUpy8M1V4XovP hqnyS91S4CfwNNYYym3aeDl9xnmXThV83ANtzwDBdIlbwH6C3rs8GkCAU348 hHVEZ73EwYzOcCyNsjDRVMf9E75lG43bc2gkASoJ3INVB0p1tG94hFl7q6S. GEdrCEGLXWKUmhRpSYcKvKHOjVFSBew9.BoSGdg6u5nkuZ8lDZnPn9sn6gw0 uuHySMHvic2boCtwbYwhsJ1CxvVlTLkYfK0Upo47QxT2OSi14Hqk.7NoIup7 1LNABJeec0WPTuoXo0JIJ5tHsU5lWaCCzvAulZUPUOZ1SomlfpD9QJv7vy7F cIhLu916oYRZ_bjvL6b_UVYDdozKt8psuAut0GZ0c52A7sL5ysT_JbFHCquA jQOwXfHBMrOgmRawLvZyNhtWFA1YGHUu9.BKMgagITjJFS2D5fOMjo57ogTN xRuRtVrHaqM9N_t1DOrNLmErcByKG.GN80f5pTB7F_TTuzGQ89SbKLTib.rB _5UIPOntU.eK.9856qm7HzhgAFDmEgv96CkseBz3c5dpkMOpnjQJP0YHQZiz iQ42BiNejh17DNunO109e.XXo3KMXnQukMGdjYWSKn6MQbRr7egfXkzSi8UF 20B7myKdrV.tSOfjoPAeZSulHlm9CKuBQ Received: from [98.139.248.67] by web142802.mail.bf1.yahoo.com via HTTP; Tue, 13 May 2014 08:50:07 PDT X-Rocket-MIMEInfo: 002.001, SSBkbyBsb29rIGF0IHNvbWUgb2YgdGhlIHN0dWZmIHdlJ3JlIGRvaW5nIGFuZCB0aGluZyAiSXMgdGhhdCBhbGwgZ29ubmEgZml0IGluIG9uZSBoZWFkZXIgbGluZT8iLiDCoCBCcmVha2luZyBzb21lIG9mIHRoaXMgb3V0IGludG8gYSBuZXcgaGVhZGVyIGZpZWxkIGlzIHJlYXNvbmFibGUgYnV0IGRvZXNuJ3QgZmVlbCBhcyBjbGVhbiBhcyBoYXZpbmcgaXQgYWxsIGluIG9uZSBwbGFjZS4KCgpPbiBUdWVzZGF5LCBNYXkgMTMsIDIwMTQgODozMyBBTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBNSVQuRURVPiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <536BFA23.9020900@digitalbazaar.com> <53710BF9.7090701@gmx.net> <750D6D1F-AF43-4A8D-A377-65723AE422F1@mit.edu> Message-ID: <1399996207.18452.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Tue, 13 May 2014 08:50:07 -0700 (PDT) From: Bill Mills To: Justin Richer , Hannes Tschofenig In-Reply-To: <750D6D1F-AF43-4A8D-A377-65723AE422F1@mit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1397251415-2133601556-1399996207=:18452" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/REv0xqcxRSjokKQJl4aeHRBNzZc Cc: OAuth WG Subject: Re: [OAUTH-WG] [http-auth] Review Request for third draft of "Signing HTTP Messages" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:20:47 -0000 --1397251415-2133601556-1399996207=:18452 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I do look at some of the stuff we're doing and thing "Is that all gonna fit= in one header line?". =C2=A0 Breaking some of this out into a new header f= ield is reasonable but doesn't feel as clean as having it all in one place.= =0A=0A=0AOn Tuesday, May 13, 2014 8:33 AM, Justin Richer = wrote:=0A =0AThey=E2=80=99re similar in that they both take elements from t= he HTTP message and create a signature on them, and they use the same =E2= =80=9Clist the order of the elements=E2=80=9D trick to avoid normalization = to a large extent. The main difference is that my draft uses JWS as the sig= nature (and ultimately transport) mechanism and the Cavage draft (and the A= WS method it is born from, as I understand it) uses a new HTTP auth header = format, much like OAuth 1.0 and the (old, dusty, abandoned, can-we-stop-bri= nging-it-up) MAC draft. My original (unpublished) version of the draft didn= =E2=80=99t actually specify or care how you got the key, as I think that HT= TP signing is a general mechanism.=0A=0AThat said, there seems to be a lot = of interest in solving this case that OAuth 1.0 managed to get somewhat rig= ht-ish.=0A=0A=E2=80=94 Justin=0A=0A=0AOn May 12, 2014, at 1:59 PM, Hannes T= schofenig wrote:=0A=0A> Conceptually, draft-cav= age-http-signatures-02 is the same as OAuth 1.0.=0A> Therefore, the symmetr= ic key part of the document is the same as the MAC=0A> token.=0A> =0A> Not = quite sure why the authors have not read the OAuth work.=0A> =0A> On 05/09/= 2014 01:22 AM, Phil Hunt wrote:=0A>> How does this compare with justin's dr= aft?=0A>> =0A>> Phil=0A>> =0A>> Begin forwarded message:=0A>> =0A>>> *From:= * Manu Sporny >> >=0A>>> *Date:* May 8, 2014 at 14:41:55 PDT=0A>>> *To:* IETF HTTP Aut= h >=0A>>> *Cc:* Julian Resch= ke >> >, Mark Notti= ngham >> >, Web Payments CG >> >=0A>>> *Subjec= t:* *[http-auth] Review Request for third draft of "Signing=0A>>> HTTP Mess= ages"*=0A>>> =0A>>> After feedback from Mark Nottingham[1], Julian Reschke[= 2], folks in the=0A>>> HTTP Auth WG, and people in the Web Payments CG, we'= ve modified the HTTP=0A>>> Signatures specification in the following ways:= =0A>>> =0A>>> 1. The specification has been renamed to "Signing HTTP Messag= es".=0A>>> 2. The specification now covers both a signature-based Authoriza= tion=0A>>>=C2=A0 mechanism (client-to-server) as well as a general mechanis= m to sign=0A>>>=C2=A0 HTTP messages (client-to-server and server-to-client)= .=0A>>> 3. A new "Signature" header has been introduced.=0A>>> 4. The layou= t has been modified heavily to streamline the information=0A>>>=C2=A0 conve= yed in the spec.=0A>>> 5. New registries have been created for the algorith= ms referred to in=0A>>>=C2=A0 the specification.=0A>>> 6. We're now more sp= ecific in the way certain canonicalizations are=0A>>>=C2=A0 performed.=0A>>= > 7. More examples have been added, including how to digitally sign=0A>>>= =C2=A0 the body of an HTTP message.=0A>>> =0A>>> The basic mechanism of gen= erating the signatures has not changed (and=0A>>> has been stable for over = a year).=0A>>> =0A>>> The newest spec can be found here:=0A>>> =0A>>> http:= //tools.ietf.org/html/draft-cavage-http-signatures-02=0A>>> =0A>>> The diff= is here:=0A>>> =0A>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-cavage-ht= tp-signatures-02.txt=0A>>> =0A>>> Matt, Yoav, Kathleen, if there are no sho= w stopping review comments, I'd=0A>>> like to push this spec onto the RFC t= rack in the HTTP Auth WG, or=0A>>> HTTPbis/2 WG. It'll be ready for a LC in= a month or two. I realize that=0A>>> HTTP Auth may be shutting down next m= onth, so what's the next step to=0A>>> get the HTTP Signatures spec further= down the IETF RFC track?=0A>>> =0A>>> -- manu=0A>>> =0A>>> [1]=0A>>> http:= //lists.w3.org/Archives/Public/public-webpayments/2014Feb/0038.html=0A>>> [= 2]=0A>>> http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/003= 6.html=0A>>> =0A>>> -- =0A>>> Manu Sporny (skype: msporny, twitter: manuspo= rny, G+: +Manu Sporny)=0A>>> Founder/CEO - Digital Bazaar, Inc.=0A>>> blog:= The Marathonic Dawn of Web Payments=0A>>> http://manu.sporny.org/2014/dawn= -of-web-payments/=0A>>> =0A>>> ____________________________________________= ___=0A>>> http-auth mailing list=0A>>> http-auth@ietf.org =0A>>> https://www.ietf.org/mailman/listinfo/http-auth=0A>> =0A>>= =0A>> _______________________________________________=0A>> OAuth mailing l= ist=0A>> OAuth@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/oauth=0A= >> =0A> =0A> _______________________________________________=0A> OAuth mail= ing list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinfo/oauth= =0A=0A=0A_______________________________________________=0AOAuth mailing li= st=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --1397251415-2133601556-1399996207=:18452 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I do look at some of the stuff we're doing and thi= ng "Is that all gonna fit in one header line?".   Breaking some of thi= s out into a new header field is reasonable but doesn't feel as clean as ha= ving it all in one place.

On Tuesday, May 13, 2014 8:33 AM, Justin Riche= r <jricher@MIT.EDU> wrote:
They=E2=80=99re similar in that they both take elements from the H= TTP message and create a signature on them, and they use the same =E2=80=9Clist the order = of the elements=E2=80=9D trick to avoid normalization to a large extent. Th= e main difference is that my draft uses JWS as the signature (and ultimatel= y transport) mechanism and the Cavage draft (and the AWS method it is born = from, as I understand it) uses a new HTTP auth header format, much like OAu= th 1.0 and the (old, dusty, abandoned, can-we-stop-bringing-it-up) MAC draf= t. My original (unpublished) version of the draft didn=E2=80=99t actually s= pecify or care how you got the key, as I think that HTTP signing is a gener= al mechanism.

That said, there seems t= o be a lot of interest in solving this case that OAuth 1.0 managed to get s= omewhat right-ish.

=E2=80=94 Justin

On May 12, 2014, at 1:59 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
> Conceptually, draft-cavage-http-signatures-02 is the s= ame as OAuth 1.0.
> Therefore, the symmetric key part = of the document is the same as the MAC
> token.
>
> Not quite sure why the authors hav= e not read the OAuth work.
>
> O= n 05/09/2014 01:22 AM, Phil Hunt wrote:
>> How does= this compare with justin's draft?
>>
>> Phil
>>
>> = Begin forwarded message:
>>
>= >> *From:* Manu Sporny <msporny@digi= talbazaar.com
>>> <mailto:mspor= ny@digitalbazaar.com>>
>>> *Date:* May= 8, 2014 at 14:41:55 PDT
>>> *To:* IETF HTTP Aut= h <http-auth@ietf.org <mailto:htt= p-auth@ietf.org>>
>>> *Cc:* Julian Res= chke <julian.reschke@gmx.de
= >>> <mailto:julian.reschke@gmx.de>= >, Mark Nottingham <mnot@mnot.net
>>= > <mailto:mnot@mnot.net>>, Web Payments CG <public-webpayments@w3.org
>= ;>> <mailto:public-webpayments@w3.or= g>>
>>> *Subject:* *[http-auth] Review= Request for third draft of "Signing
>>> HTTP Me= ssages"*
>>>
>>> Aft= er feedback from Mark Nottingham[1], Julian Reschke[2], folks in the
>>> HTTP Auth WG, and people in the Web Payments CG, w= e've modified the HTTP
>>> Signatures specificat= ion in the following ways:
>>>
>>> 1. The specifi= cation has been renamed to "Signing HTTP Messages".
>&= gt;> 2. The specification now covers both a signature-based Authorizatio= n
>>>  mechanism (client-to-server) as well= as a general mechanism to sign
>>>  HTTP m= essages (client-to-server and server-to-client).
>>= > 3. A new "Signature" header has been introduced.
>= ;>> 4. The layout has been modified heavily to streamline the informa= tion
>>>  conveyed in the spec.
>>> 5. New registries have been created for the algorithms = referred to in
>>>  the specification.
>>> 6. We're now more specific in the way certain ca= nonicalizations are
>>>  performed.
>>> 7. More examples have been added, including ho= w to digitally sign
>>>  the body of an HTT= P message.
>>>
>>> T= he basic mechanism of generating the signatures has not changed (and
>>> has been stable for over a year).
>>>
>>> The newest spec can be found= here:
>>>
>>> http://tools.ietf.org/html/draft-cavage-http-signat= ures-02
>>>
>>> = The diff is here:
>>>
>>= ;> http://tools.ietf.org/rfcdiff?url2=3Ddraft-cavage-http-s= ignatures-02.txt
>>>
>= >> Matt, Yoav, Kathleen, if there are no show stopping review comment= s, I'd
>>> like to push this spec onto the RFC t= rack in the HTTP Auth WG, or
>>> HTTPbis/2 WG. I= t'll be ready for a LC in a month or two. I realize that
= >>> HTTP Auth may be shutting down next month, so what's the next = step to
>>> get the HTTP Signatures spec further= down the IETF RFC track?
>>>
>>> -- manu
>>>
>= ;>> [1]
>>> http://lists.w3.org/Archives/Public/public-webpayments/2014Feb= /0038.html
>>> [2]
>>> http://lists.w3.org/Archives/Public/public-= webpayments/2014Feb/0036.html
>>>
>>> --
>>> Manu Sporny (skyp= e: msporny, twitter: manusporny, G+: +Manu Sporny)
>&g= t;> Founder/CEO - Digital Bazaar, Inc.
>>> bl= og: The Marathonic Dawn of Web Payments
>>> http://manu.sporny.org/2014/dawn-of-web-payments/
>>>
>>> _________________= ______________________________
>>> http-auth mai= ling list
>>> http-auth@ietf.org <mailto:http-auth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/http-auth
>>
>>
>> ___= ____________________________________________
>> OAu= th mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/o= auth
>>
>
> _______________________________________________
= > OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________= ________________________________
OAuth mailing list
OAuth@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/oauth

--1397251415-2133601556-1399996207=:18452-- From nobody Tue May 13 10:42:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4D41A0194 for ; Tue, 13 May 2014 10:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 fMdOzcsQbiET for ; Tue, 13 May 2014 10:42:30 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6963D1A01B3 for ; Tue, 13 May 2014 10:42:14 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4DHg2Zk013024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 May 2014 17:42:03 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4DHg1eW005050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2014 17:42:02 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4DHg1p0024619; Tue, 13 May 2014 17:42:01 GMT Received: from [130.35.50.173] (/130.35.50.173) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 May 2014 10:42:01 -0700 Message-ID: <53725968.1010702@oracle.com> Date: Tue, 13 May 2014 10:42:00 -0700 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Blair Strang , Hannes Tschofenig , Scott Contini References: <9378C75B-2146-4E8D-BDD6-B4F495C52B84@oracle.com> <53710CC9.2000600@gmx.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050607020307060502070503" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/5QckZwDbQWblj3KrC9kDa4Vcojc Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: HTTP protocol version in MAC signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 17:42:33 -0000 This is a multi-part message in MIME format. --------------050607020307060502070503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I hate to be one of these "lets-be-careful" guys, but I do have to point out that the AWS documentation and method being referenced is proprietary with its all attendant IP issues. - prateek > Hi Hannnes, > > Yes, so in terms of well-defined specs for HTTP request signing, there > is basically AWS, OAuth 1.0a HMAC, and the OAuth 2.0 draft HMAC stuff > which is looking a bit abandoned. > > The v2 and v4 signing processes for AWS are documented here. > [1] http://docs.aws.amazon.com/general/latest/gr/signature-version-2.html > [2] http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html > > Looking at the slides you sent, my colleague Scott and I have been > working on something running along the same lines. This has largely > been for internal use, but we have had our eye on a design with > general utility. > > So far we have been working to clearly define *only* how HTTP requests > can be authenticated using a JWT/JWS, independent of the issues of key > distribution and sessions (an OAuth2 extension is one option for > sessions / key agreement, but there are obviously other ways). > > We actually have a spec and proof of concept in progress for JWS based > request signing. We do need some time to clean up the spec for public > consumption, but would you be interested in seeing that? > > Thanks, > > Blair. > > ---- Long form details below here ----- > > Our view is that request authentication (mac/signature) and the > session (or key agreement) mechanisms needed to support it are largely > orthogonal. > > We have been working to specify a mechanism for authenticating HTTP > requests using JWT/JWS. (The tokens look just like JWTs, but it is > better to specify on top of JWS). > > Our approach was that the client computes a "signature base string" or > "string to sign" in a fashion very similar to AWS v2, while adding > header signing similar to that in AWS v4. This fixes a gap in the > OAuth 1.0a HMAC token spec. > > The client then embeds a digest of the "signature base string" in a > JWS signed by the client, along with several other required fields > (e.g. a field identifying the requestor, optional key id, expiry, list > of signed http headers, ...) to authenticate the request. > > The nice thing about embedding the request digest in a JWT/JWS signed > payload is that you get all the flexibility of JWS in terms of > algorithms. > > Also, the implementation also comes out very nice, since you need just > string processing of the request to get a canonical version plus a > digest operation - and the "hard crypto stuff" can be handled by a JWS > library. > > However, there are some constraints in terms of practicality using the > JWS standard (not insurmountable, but there): > > 1. RSA - A client with a private key can easily RSA-sign HTTP > requests, but the Authorization: header will be several hundred bytes > long due to the size of the RSA signature. Speed is high, but so is > bandwidth required. > > 2. ECDSA - ECDSA produces much smaller payloads (few hundred bytes) > but requires much more processing effort (order of milliseconds). > > 3. HMAC - A shared HMAC key will be the most efficient in terms of > speed & storage, but requires additional session establishment dance > which is slightly less elegant than a client using a private key directly. > > Request authorisation using a private key directly works well for > server-to-server or "big client" to server, but not so well for mobile > with power and bandwidth constraints. In this case, the approach we > are taking for a client to bootstrap from possession of a private key > is to send an RSA signed request to establish a shared HMAC key, then > use HMAC signed requests. > > Thanks & regards, > > Blair. > > -- > Blair Strang | Senior Security Engineer > Covata | Own Your Data > covata.com > > Level 4 156 Clarence Street | Sydney NSW 2000 > © 2014 CDHL parent company for all Covata entities > > > > > > > > > > On Tue, May 13, 2014 at 4:02 AM, Hannes Tschofenig > > wrote: > > Hi Phil, > Hi Blair, > > this is a good point. I also don't see a reason why the HTTP protocol > version should be included in the keyed message digest (from a > security > point of view). > > It might, however, be worthwhile to point out that we are exploring > different solution directions, as described in this slide deck > http://www.tschofenig.priv.at/oauth/IETF-OAuth-PoP.pptx > > For this reason it might be interesting to know what AWS > implements. Do > you guys have a reference? > > Ciao > Hannes > > > On 05/09/2014 05:47 AM, Phil Hunt wrote: > > Fyi > > > > Phil > > > > Begin forwarded message: > > > >> *From:* Blair Strang > >> >> > >> *Date:* May 8, 2014 at 18:47:58 PDT > >> *Resent-To:* hannes.tschofenig@gmx.net > > >> >, jricher@mitre.org > > >> >, > phil.hunt@yahoo.com > >> >, > wmills@yahoo-inc.com > >> > > >> *To:* draft-ietf-oauth-v2-http-mac@tools.ietf.org > > >> > > >> *Subject:* *HTTP protocol version in MAC signatures* > >> > >> Hi, > >> > >> [Not sure if this is the right address to submit this feedback to] > >> > >> Looking > >> over http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05 > section 5.2. > >> "MAC Input String", it seems that the HTTP request line is used > >> verbatim during the construction of MAC tokens. > >> > >> Since this includes the transport (HTTP/1.1 versus say HTTP/1.0) it > >> seems that HTTP proxies which run different protocol versions > on each > >> leg will break signatures. > >> > >> I would recommend removing the HTTP version from the MAC. The > >> transport is inherently a "per hop" type of thing, while request > >> signatures are conceptually "end to end". > >> > >> I am not aware of any specific security benefits derived from > >> including the HTTP protocol version in the MAC input string. > This may > >> be why AWS version 2 and AWS version 4 signatures do not > include it. > >> > >> Thanks and regards, > >> > >> Blair. > >> > > > > > > _______________________________________________ > > 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 --------------050607020307060502070503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I hate to be one of these "lets-be-careful" guys, but I do have to point out that the AWS documentation and method being referenced is proprietary with its all attendant IP issues.

- prateek
Hi Hannnes,

Yes, so in terms of well-defined specs for HTTP request signing, there is basically AWS, OAuth 1.0a HMAC, and the OAuth 2.0 draft HMAC stuff which is looking a bit abandoned.

The v2 and v4 signing processes for AWS are documented here.
Looking at the slides you sent, my colleague Scott and I have been working on something running along the same lines. This has largely been for internal use, but we have had our eye on a design with general utility.

So far we have been working to clearly define *only* how HTTP requests can be authenticated using a JWT/JWS, independent of the issues of key distribution and sessions (an OAuth2 extension is one option for sessions / key agreement, but there are obviously other ways).

We actually have a spec and proof of concept in progress for JWS based request signing. We do need some time to clean up the spec for public consumption, but would you be interested in seeing that?

Thanks,

    Blair.

---- Long form details below here -----

Our view is that request authentication (mac/signature) and the session (or key agreement) mechanisms needed to support it are largely orthogonal.

We have been working to specify a mechanism for authenticating HTTP requests using JWT/JWS. (The tokens look just like JWTs, but it is better to specify on top of JWS).

Our approach was that the client computes a "signature base string" or "string to sign" in a fashion very similar to AWS v2, while adding header signing similar to that in AWS v4. This fixes a gap in the OAuth 1.0a HMAC token spec. 

The client then embeds a digest of the "signature base string" in a JWS signed by the client, along with several other required fields (e.g. a field identifying the requestor, optional key id, expiry, list of signed http headers, ...) to authenticate the request.

The nice thing about embedding the request digest in a JWT/JWS signed payload is that you get all the flexibility of JWS in terms of algorithms. 

Also, the implementation also comes out very nice, since you need just string processing of the request to get a canonical version plus a digest operation - and the "hard crypto stuff" can be handled by a JWS library. 

However, there are some constraints in terms of practicality using the JWS standard (not insurmountable, but there):

1. RSA - A client with a private key can easily RSA-sign HTTP requests, but the Authorization: header will be several hundred bytes long due to the size of the RSA signature. Speed is high, but so is bandwidth required.

2. ECDSA - ECDSA produces much smaller payloads (few hundred bytes) but requires much more processing effort (order of milliseconds).

3. HMAC - A shared HMAC key will be the most efficient in terms of speed & storage, but requires additional session establishment dance which is slightly less elegant than a client using a private key directly.

Request authorisation using a private key directly works well for server-to-server or "big client" to server, but not so well for mobile with power and bandwidth constraints. In this case, the approach we are taking for a client to bootstrap from possession of a private key is to send an RSA signed request to establish a shared HMAC key, then use HMAC signed requests.

Thanks & regards,

    Blair.

--
Blair Strang | Senior Security Engineer
Covata | Own Your Data
covata.com

Level 4 156 Clarence Street | Sydney NSW 2000
© 2014 CDHL parent company for all Covata entities









On Tue, May 13, 2014 at 4:02 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Phil,
Hi Blair,

this is a good point. I also don't see a reason why the HTTP protocol
version should be included in the keyed message digest (from a security
point of view).

It might, however, be worthwhile to point out that we are exploring
different solution directions, as described in this slide deck
http://www.tschofenig.priv.at/oauth/IETF-OAuth-PoP.pptx

For this reason it might be interesting to know what AWS implements. Do
you guys have a reference?

Ciao
Hannes


On 05/09/2014 05:47 AM, Phil Hunt wrote:
> Fyi
>
> Phil
>
> Begin forwarded message:
>
>> *From:* Blair Strang <blair.strang@covata.com
>> <mailto:blair.strang@covata.com>>
>> *Date:* May 8, 2014 at 18:47:58 PDT
>> *Resent-To:* hannes.tschofenig@gmx.net
>> <mailto:hannes.tschofenig@gmx.net>, jricher@mitre.org
>> <mailto:jricher@mitre.org>, phil.hunt@yahoo.com
>> <mailto:phil.hunt@yahoo.com>, wmills@yahoo-inc.com
>> <mailto:wmills@yahoo-inc.com>
>> *To:* draft-ietf-oauth-v2-http-mac@tools.ietf.org
>> <mailto:draft-ietf-oauth-v2-http-mac@tools.ietf.org>
>> *Subject:* *HTTP protocol version in MAC signatures*
>>
>> Hi,
>>
>> [Not sure if this is the right address to submit this feedback to]
>>
>> Looking
>> over http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05 section 5.2.
>> "MAC Input String", it seems that the HTTP request line is used
>> verbatim during the construction of MAC tokens.
>>
>> Since this includes the transport (HTTP/1.1 versus say HTTP/1.0) it
>> seems that HTTP proxies which run different protocol versions on each
>> leg will break signatures.
>>
>> I would recommend removing the HTTP version from the MAC. The
>> transport is inherently a "per hop" type of thing, while request
>> signatures are conceptually "end to end".
>>
>> I am not aware of any specific security benefits derived from
>> including the HTTP protocol version in the MAC input string. This may
>> be why AWS version 2 and AWS version 4 signatures do not include it.
>>
>> Thanks and regards,
>>
>>     Blair.
>>
>
>
> _______________________________________________
> 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

--------------050607020307060502070503-- From nobody Wed May 14 02:31:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83AB1A0284 for ; Wed, 14 May 2014 02:31:52 -0700 (PDT) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 qQpAA78Y2x7E for ; Wed, 14 May 2014 02:31:50 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D31901A0283 for ; Wed, 14 May 2014 02:31:49 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id r20so7661943wiv.13 for ; Wed, 14 May 2014 02:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=HWI/qQ66cBlkBIlwsuS9aui2mApgj3La4JYHqKjc1n4=; b=vOUehVQ4s1HxX4o4LWr4ifBLZGnQJHEVM+AVpViQTd5vaBU8ZWYYMyRqhQx53YdlBQ WzBxENguOLbOz1WH/+KUku1dn6t0qFUswh/hoBixkLi0p4U4Al/A1IDor/ukf/2ZygJW b5+N7ZQA72w6RSFM6H4OBEOoY3/lBwPSUNqhsZleJXLJFqSqiRbeHa9D35HBv2LVc5JV mtYStUronsHPAKRyS3Wc/DXHBG0cwiBWjkolWs0b7lQiOpz5lGE5qkG0NYlSq0YWAM4G AFXqHf53DFvwRLVbn4HeuaMO2bs2kU1c8i9g+NPGU/7FQrJAjutPUf48DC+WsVyhY0Kw inhA== X-Received: by 10.180.105.72 with SMTP id gk8mr25147517wib.32.1400059902614; Wed, 14 May 2014 02:31:42 -0700 (PDT) Received: from [192.168.2.7] ([89.100.139.33]) by mx.google.com with ESMTPSA id y20sm26716898wiv.14.2014.05.14.02.31.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 May 2014 02:31:41 -0700 (PDT) Message-ID: <537337FC.40500@gmail.com> Date: Wed, 14 May 2014 10:31:40 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: oauth@ietf.org References: <9378C75B-2146-4E8D-BDD6-B4F495C52B84@oracle.com> <53710CC9.2000600@gmx.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/dUrZSGTWcGTJeuM79cgRt1F2YE4 Subject: Re: [OAUTH-WG] Fwd: HTTP protocol version in MAC signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 09:31:53 -0000 Hi On 13/05/14 16:27, Justin Richer wrote: > Blair, > > You’re right in that the MAC draft is effectively abandoned now as the > WG has moved on to other signed-token mechanisms. As part of that > effort, I’ve put together a JWS-based HTTP request signature mechanism > (referenced in Hannes’s presentation): > > http://tools.ietf.org/id/draft-richer-oauth-signed-http-request-01.html > +1 to building a JWS-based solution. IMHO though it is unfortunate that a MAC solution which can make better bearer tokens is not looked at right now and thus it is unavoidable that people will come up with several new approaches 'fragmenting' the MAC space. We actually implemented a HAWK scheme as part of the OAuth2 framework, it works, very simple, the session key is expected to be exchanged via a 2-way TLS as part of the grant to token exchange. I hope OAuth2 will have its own MAC solution ready too, leading to the better interoperability in the OAuth2 space Cheers, Sergey > This differs from the AWS spec (submitted as an HTTP Auth WG Draft, as I > understand it: > http://tools.ietf.org/id/draft-cavage-http-signatures-02.html) in that > it uses JWS as the signing mechanism (without a custom HTTP header > format). There’s still a fair amount of work that needs to be done in > order to get it in shape, but I think that these different methods can > definitely inform each other. > > — Justin > > > On May 13, 2014, at 2:34 AM, Blair Strang > wrote: > >> Hi Hannnes, >> >> Yes, so in terms of well-defined specs for HTTP request signing, there >> is basically AWS, OAuth 1.0a HMAC, and the OAuth 2.0 draft HMAC stuff >> which is looking a bit abandoned. >> >> The v2 and v4 signing processes for AWS are documented here. >> [1] http://docs.aws.amazon.com/general/latest/gr/signature-version-2.html >> [2] http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html >> >> Looking at the slides you sent, my colleague Scott and I have been >> working on something running along the same lines. This has largely >> been for internal use, but we have had our eye on a design with >> general utility. >> >> So far we have been working to clearly define *only* how HTTP requests >> can be authenticated using a JWT/JWS, independent of the issues of key >> distribution and sessions (an OAuth2 extension is one option for >> sessions / key agreement, but there are obviously other ways). >> >> We actually have a spec and proof of concept in progress for JWS based >> request signing. We do need some time to clean up the spec for public >> consumption, but would you be interested in seeing that? >> >> Thanks, >> >> Blair. >> >> ---- Long form details below here ----- >> >> Our view is that request authentication (mac/signature) and the >> session (or key agreement) mechanisms needed to support it are largely >> orthogonal. >> >> We have been working to specify a mechanism for authenticating HTTP >> requests using JWT/JWS. (The tokens look just like JWTs, but it is >> better to specify on top of JWS). >> >> Our approach was that the client computes a "signature base string" or >> "string to sign" in a fashion very similar to AWS v2, while adding >> header signing similar to that in AWS v4. This fixes a gap in the >> OAuth 1.0a HMAC token spec. >> >> The client then embeds a digest of the "signature base string" in a >> JWS signed by the client, along with several other required fields >> (e.g. a field identifying the requestor, optional key id, expiry, list >> of signed http headers, ...) to authenticate the request. >> >> The nice thing about embedding the request digest in a JWT/JWS signed >> payload is that you get all the flexibility of JWS in terms of >> algorithms. >> >> Also, the implementation also comes out very nice, since you need just >> string processing of the request to get a canonical version plus a >> digest operation - and the "hard crypto stuff" can be handled by a JWS >> library. >> >> However, there are some constraints in terms of practicality using the >> JWS standard (not insurmountable, but there): >> >> 1. RSA - A client with a private key can easily RSA-sign HTTP >> requests, but the Authorization: header will be several hundred bytes >> long due to the size of the RSA signature. Speed is high, but so is >> bandwidth required. >> >> 2. ECDSA - ECDSA produces much smaller payloads (few hundred bytes) >> but requires much more processing effort (order of milliseconds). >> >> 3. HMAC - A shared HMAC key will be the most efficient in terms of >> speed & storage, but requires additional session establishment dance >> which is slightly less elegant than a client using a private key directly. >> >> Request authorisation using a private key directly works well for >> server-to-server or "big client" to server, but not so well for mobile >> with power and bandwidth constraints. In this case, the approach we >> are taking for a client to bootstrap from possession of a private key >> is to send an RSA signed request to establish a shared HMAC key, then >> use HMAC signed requests. >> >> Thanks & regards, >> >> Blair. >> >> -- >> Blair Strang | Senior Security Engineer >> Covata | Own Your Data >> covata.com >> >> Level 4 156 Clarence Street | Sydney NSW 2000 >> © 2014 CDHL parent company for all Covata entities >> >> >> >> >> >> >> >> >> >> On Tue, May 13, 2014 at 4:02 AM, Hannes Tschofenig >> > wrote: >> >> Hi Phil, >> Hi Blair, >> >> this is a good point. I also don't see a reason why the HTTP protocol >> version should be included in the keyed message digest (from a >> security >> point of view). >> >> It might, however, be worthwhile to point out that we are exploring >> different solution directions, as described in this slide deck >> http://www.tschofenig.priv.at/oauth/IETF-OAuth-PoP.pptx >> >> For this reason it might be interesting to know what AWS >> implements. Do >> you guys have a reference? >> >> Ciao >> Hannes >> >> >> On 05/09/2014 05:47 AM, Phil Hunt wrote: >> > Fyi >> > >> > Phil >> > >> > Begin forwarded message: >> > >> >> *From:* Blair Strang > >> >> >> >> >> *Date:* May 8, 2014 at 18:47:58 PDT >> >> *Resent-To:* hannes.tschofenig@gmx.net >> >> >> > >, jricher@mitre.org >> >> >> >, >> phil.hunt@yahoo.com >> >> >, >> wmills@yahoo-inc.com >> >> > >> >> *To:* draft-ietf-oauth-v2-http-mac@tools.ietf.org >> >> >> > > >> >> *Subject:* *HTTP protocol version in MAC signatures* >> >> >> >> Hi, >> >> >> >> [Not sure if this is the right address to submit this feedback to] >> >> >> >> Looking >> >> over http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05 >> section 5.2. >> >> "MAC Input String", it seems that the HTTP request line is used >> >> verbatim during the construction of MAC tokens. >> >> >> >> Since this includes the transport (HTTP/1.1 versus say HTTP/1.0) it >> >> seems that HTTP proxies which run different protocol versions >> on each >> >> leg will break signatures. >> >> >> >> I would recommend removing the HTTP version from the MAC. The >> >> transport is inherently a "per hop" type of thing, while request >> >> signatures are conceptually "end to end". >> >> >> >> I am not aware of any specific security benefits derived from >> >> including the HTTP protocol version in the MAC input string. >> This may >> >> be why AWS version 2 and AWS version 4 signatures do not >> include it. >> >> >> >> Thanks and regards, >> >> >> >> Blair. >> >> >> > >> > >> > _______________________________________________ >> > 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 > From nobody Wed May 14 04:38:15 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CD41A0015 for ; Wed, 14 May 2014 04:38:14 -0700 (PDT) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 byJFGwfhErlT for ; Wed, 14 May 2014 04:38:13 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0B86B1A006D for ; Wed, 14 May 2014 04:38:03 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id n12so1791208wgh.5 for ; Wed, 14 May 2014 04:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=rS0XTTq1E6xUiJ34DaJMr7rRUdUsCXWR+/As49XI4Aw=; b=LIhcC1fvkIZatp3sRnfFjSFJH3x2oKZ9a8xOLzorTXEvjTw5dNUWX40Xe7NQL6xW1n 5m+lW4phxbVimiij5we2HhlcVqNV2YZBL290WsCtfZhvpSHfDV1wcg3aQOkBcuQPa/cX qwzdDaFAbm67ljh6p8ticES35ZDliOlbHmk9aEtvq3qHc+i4KPu5udFKTFhiC39U9NfW HOB32l1j0fUumB3tRqL8gNuSF6cs6bi+bltanw2lDMQ4iH5q5McpoVst+RJPdY87IAKb ZdvbCCpku+ImdOR2Ji8D036befQxzMW3Bue0pTjPU7i1T7KI56W3zcKlMhmI28m5UTrE Ye/Q== X-Received: by 10.180.13.208 with SMTP id j16mr25431197wic.58.1400067476979; Wed, 14 May 2014 04:37:56 -0700 (PDT) Received: from [192.168.2.7] ([89.100.139.33]) by mx.google.com with ESMTPSA id ct2sm2162156wjb.33.2014.05.14.04.37.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 May 2014 04:37:56 -0700 (PDT) Message-ID: <53735592.1010008@gmail.com> Date: Wed, 14 May 2014 12:37:54 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/iQ8yGp_uP0uWdXRN88lJ1lEE7LE Subject: [OAUTH-WG] Section 3.2 in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 11:38:14 -0000 Hi Section 3.2 [1] mentions that "If the algorithm is registered, the server MUST reject any request that does not conform to the algorithm" I wonder is this text adds anything extra in addition to what Section 3.7 [2] says where the server is required to reject the request if the verifier and the challenge do not match ? I don't understand how registering the supported algorithms helps given that the client only provides a code_verifier Thanks, Sergey [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.2 [2] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.7 From nobody Wed May 14 04:47:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02781A005C for ; Wed, 14 May 2014 04:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 yFmFMl42R4U3 for ; Wed, 14 May 2014 04:47:02 -0700 (PDT) Received: from na3sys009aog136.obsmtp.com (na3sys009aog136.obsmtp.com [74.125.149.85]) by ietfa.amsl.com (Postfix) with ESMTP id 40BD31A0063 for ; Wed, 14 May 2014 04:47:02 -0700 (PDT) Received: from mail-ie0-f175.google.com ([209.85.223.175]) (using TLSv1) by na3sys009aob136.postini.com ([74.125.148.12]) with SMTP ID DSNKU3NXrvmv1i/JYQYDKlN0KcLyuwBDU70f@postini.com; Wed, 14 May 2014 04:46:56 PDT Received: by mail-ie0-f175.google.com with SMTP id y20so1633000ier.6 for ; Wed, 14 May 2014 04:46:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8n0Haul4GW5bIhDzmOY00cz5eTF2O7qldWM9V55PiWQ=; b=DiSnoLpr6aCIU/1yaQnD5QG0mzwvyQj9eQvYwbgw1KL7tqW6Kh/o9ktfp8JNU/pguc RSudaSQanZLKHvBYK7YKgpY1drXOHTMzsig1JwZx5ILBDXutkEQfyvzwcklXfrEAefuI Pu1Utc3/DV/Ocqcw1KzTPEUyLWASzwOfNydRA0YUxla1C2T/yCvUM8jR1cdcPpzJMcHW OQn+G9blcf/Ysz6MYnGQpUVfh9LGI3uKe0HdSPhbRUXshGN1i/HT/g9we/9HtFIgimH6 jURDGkrbfubeDEuEGybp/8MlzgpBi+acB90ZibW6irc7t+2Y2SsbMHtVY9BjYoTZ8xCl cc0Q== X-Gm-Message-State: ALoCoQnrKYNzxtDMuj9E4jsF19/vP7lCNrAuEs6l0XRN3G0sPgFIAVPUxijAV29QiexQP5GoEtnR+jDdv7wxSweFRn33QmFjZWeNlDKNpx4BoTJAmqFIMDAmA20fUq42yK59MnLdMI3E X-Received: by 10.51.17.99 with SMTP id gd3mr16439817igd.2.1400068014688; Wed, 14 May 2014 04:46:54 -0700 (PDT) X-Received: by 10.51.17.99 with SMTP id gd3mr16439798igd.2.1400068014540; Wed, 14 May 2014 04:46:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Wed, 14 May 2014 04:46:24 -0700 (PDT) In-Reply-To: References: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> From: Brian Campbell Date: Wed, 14 May 2014 05:46:24 -0600 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a11360146ab24b804f95abcd2 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-T7BnzrXP5HL6xW6AQoPWk8cFL8 Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 11:47:04 -0000 --001a11360146ab24b804f95abcd2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That too would suggest that the length limit be on code_challenge because that's the parameter that will be on URIs getting passed around. The code_verifier is sent directly in the POST body from client to AS. On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura wrote: > +1 for octet. We used to have "bytes" in JW* so I used "bytes" here, whil= e > at the same time complaining in Jose that it should be "octet". JW* chang= ed > to "octet" but I failed to sync with it in the last few edits. > > I do not quite remember which platform, but the reason for the limit was > that some platform had some limitations as to the length of the sting to = be > passed to it through URI and we did not want the challenges to be truncat= ed > by that limit. > > Best, > > Nat > > > 2014-05-13 6:56 GMT+09:00 Brian Campbell : > > And it'd give the AS some direct guidance on protecting itself from crazy >> long code_challenge values rather than relying on the client not to do >> something creative. >> >> >> On Mon, May 12, 2014 at 3:54 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> Right but that's why I'm asking why not just put the limit on >>> code_challange rather than inferring it from code_verifyer + challenge >>> algorithm, which probably bounds it but doesn't necessarily do so? It's= not >>> a big deal but would read more clearly, I think. >>> >>> >>> On Mon, May 12, 2014 at 3:48 PM, John Bradley wrote= : >>> >>>> I think octets is more consistent with other JW* and OAuth specs. >>>> >>>> The code_challange is the same length as the code_verifyer or is a has= h >>>> of the code_verifyer so likely smaller than 128octets (43 ish for base= 64 >>>> 256 bit) >>>> >>>> Limiting the code_verifyer size sets the upper bound for >>>> code_challange, unless someone comes up with a really creative code >>>> challenge algorithm. >>>> >>>> I will talk to nat about changing it to octets when I see him tomorrow= . >>>> >>>> John B. >>>> >>>> On May 12, 2014, at 11:15 PM, Derek Atkins wrote: >>>> >>>> > Brian Campbell writes: >>>> > >>>> >> I notice that code_verifier is defined as "high entropy >>>> cryptographic random >>>> >> string of length less than 128 bytes" [1], which brought a few >>>> questions and >>>> >> comments to mind. So here goes: >>>> >> >>>> >> Talking about the length of a string in terms of bytes is always >>>> potentially >>>> >> confusing. Maybe characters would be an easier unit for people like >>>> me to wrap >>>> >> their little brains around? >>>> > >>>> > It depends if it really is characters or bytes. For example there a= re >>>> > many multi-byte UTF-8 characters, so if it really is bytes then sayi= ng >>>> > characters is wrong because it could overflow. So let's make sure w= e >>>> > know what we're talking about. Historically, if we're talking bytes >>>> the >>>> > IETF often uses the phrase "octets". Would that be less confusing? >>>> > >>>> >> Why are we putting a length restriction on the code_verifier anyway= ? >>>> It seems >>>> >> like it'd be more appropriate to restrict the length of the >>>> code_challenge >>>> >> because that's the thing the AS will have to maintain somehow (stor= e >>>> in a DB >>>> >> or memory or encrypt into the code). Am I missing something here? >>>> >> >>>> >> Let me also say that I hadn't looked at this document since its >>>> early days in >>>> >> draft -00 or -01 last summer but I like the changes and how it's >>>> been kept >>>> >> pretty simple for the common use-case while still allowing for >>>> crypto agility/ >>>> >> extension. Nice work! >>>> >> >>>> >> [1] >>>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 >>>> > >>>> > -derek >>>> > >>>> >> _______________________________________________ >>>> >> OAuth mailing list >>>> >> OAuth@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>> > >>>> > -- >>>> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >>>> > Member, MIT Student Information Processing Board (SIPB) >>>> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >>>> > warlord@MIT.EDU PGP key available >>>> >>>> >>> >>> >>> -- >>> [image: Ping Identity logo] >>> Brian Campbell >>> Portfolio Architect >>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect >>> with us=E2=80=A6 [image: twitter logo] [image: >>> youtube logo] [image: >>> LinkedIn logo] [image: >>> Facebook logo] [image: >>> Google+ logo] [imag= e: >>> slideshare logo] [image: >>> flipboard logo] [image: rss feed icon] >>> [image: Register for Cloud Identity Summit 2014 | Modern Identity >>> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >>> >>> >> >> >> -- >> [image: Ping Identity logo] >> Brian Campbell >> Portfolio Architect >> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect >> with us=E2=80=A6 [image: twitter logo] [image: >> youtube logo] [image: >> LinkedIn logo] [image: Facebook >> logo] [image: Google+ logo]<= https://plus.google.com/u/0/114266977739397708540> [image: >> slideshare logo] [image: >> flipboard logo] [image: rss feed icon] >> [image: Register for Cloud Identity Summit 2014 | Modern Identity >> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >> >> >> _______________________________________________ >> 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 > --=20 [image: Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with us=E2=80=A6 [image: twitter logo] = [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo] [image: flipboard logo] [image: rss feed icon] [image: Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] --001a11360146ab24b804f95abcd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That too would suggest that the length limit be on code_ch= allenge because that's the parameter that will be on URIs getting passe= d around. The code_verifier is sent directly in the POST body from client t= o AS.


On Tue,= May 13, 2014 at 12:52 AM, Nat Sakimura <sakimura@gmail.com> wrote:
+1 for octet. We used to ha= ve "bytes" in JW* so I used "bytes" here, while at the = same time complaining in Jose that it should be "octet". JW* chan= ged to "octet" but I failed to sync with it in the last few edits= .=C2=A0

I do not quite remember which platform, but the reason for t= he limit was that some platform had some limitations as to the length of th= e sting to be passed to it through URI and we did not want the challenges t= o be truncated by that limit.=C2=A0

Best,=C2=A0

Nat


2014-05-13 6:56 = GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:

And it'd give the AS so= me direct guidance on protecting itself from crazy long code_challenge valu= es rather than relying on the client not to do something creative.


On Mon, May 12, 2014 at 3:54 PM, Brian Campb= ell <bcampbell@pingidentity.com> wrote:
Right but that's why I'm asking why not just put t= he limit on code_challange rather than inferring it from code_verifyer + ch= allenge algorithm, which probably bounds it but doesn't necessarily do = so? It's not a big deal but would read more clearly, I think.


On Mon, May 12, 2014 at 3:48 PM, John Bradley <ve7jtb@ve7jtb.com>= ; wrote:
I think octets is more consistent with other= JW* and OAuth specs.

The code_challange is the same length as the code_verifyer or is a hash of = the code_verifyer so likely smaller than 128octets (43 ish for base64 256 b= it)

Limiting the code_verifyer size sets the upper bound for code_challange, un= less someone comes up with a really creative code challenge algorithm.

I will talk to nat about changing it to octets when I see him tomorrow.

John B.

On May 12, 2014, at 11:15 PM, Derek Atkins <warlord@MIT.EDU> wrote:

> Brian Campbell <bcampbell@pingidentity.com> writes:
>
>> I notice that code_verifier is defined as "high entropy crypt= ographic random
>> string of length less than 128 bytes" =C2=A0[1], which brough= t a few questions and
>> comments to mind. So here goes:
>>
>> Talking about the length of a string in terms of bytes is always p= otentially
>> confusing. Maybe characters would be an easier unit for people lik= e me to wrap
>> their little brains around?
>
> It depends if it really is characters or bytes. =C2=A0For example ther= e are
> many multi-byte UTF-8 characters, so if it really is bytes then saying=
> characters is wrong because it could overflow. =C2=A0So let's make= sure we
> know what we're talking about. =C2=A0Historically, if we're ta= lking bytes the
> IETF often uses the phrase "octets". =C2=A0Would that be les= s confusing?
>
>> Why are we putting a length restriction on the code_verifier anywa= y? It seems
>> like it'd be more appropriate to restrict the length of the co= de_challenge
>> because that's the thing the AS will have to maintain somehow = (store in a DB
>> or memory or encrypt into the code). Am I missing something here?<= br> >>
>> Let me also say that I hadn't looked at this document since it= s early days in
>> draft -00 or -01 last summer but I like the changes and how it'= ;s been kept
>> pretty simple for the common use-case while still allowing for cry= pto agility/
>> extension. Nice work!
>>
>> [1] http://tools.ietf.org/html/draft-sakimu= ra-oauth-tcse-03#section-3.3
>
> -derek
>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>
> --
> =C2=A0 =C2=A0 =C2=A0 Derek Atkins, SB '93 MIT EE, SM '95 MIT M= edia Laboratory
> =C2=A0 =C2=A0 =C2=A0 Member, MIT Student Information Processing Board = =C2=A0(SIPB)
> =C2=A0 =C2=A0 =C2=A0 URL: http://web.mit.edu/warlord/ =C2=A0 =C2=A0PP-ASEL-IA =C2= =A0 =C2=A0 N1NWH
> =C2=A0 =C2=A0 =C2=A0 warlord@MIT.EDU =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PGP key available




-= -
3D"Ping =09
Brian Campbell
= Portfolio Architect
=09
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register




--
3D"Ping =09
Brian Campbell
= Portfolio Architect
=09
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register


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




--
Nat Sakimura (=3Dnat)Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


--
--001a11360146ab24b804f95abcd2-- From nobody Wed May 14 05:25:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515121A006D for ; Wed, 14 May 2014 05:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 XSln8q553GC9 for ; Wed, 14 May 2014 05:25:11 -0700 (PDT) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with ESMTP id D2A341A005F for ; Wed, 14 May 2014 05:25:10 -0700 (PDT) Received: from mail-ig0-f180.google.com ([209.85.213.180]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKU3NgoDRy6118jIWni+4763XGxpKTswIX@postini.com; Wed, 14 May 2014 05:25:04 PDT Received: by mail-ig0-f180.google.com with SMTP id c1so1679020igq.13 for ; Wed, 14 May 2014 05:25:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=W95H42Att3oT9ScVDDXAUCvk99rQ3goYYi2xcoDE/Z8=; b=WWapx6z1wy1xYy4WwYmN0F5d3NfX30oGglkll3ME9WlSlXKIeYcaINwKfYGqzsnonD gDc4WcgRytWri+eeCpv2DFZ9PV9nN7aawhoHbnTRjP2trEnRGTWzKSlaZ4VSD9reEB8A fwCFcKwnjfKrqztsze9P4GNFMXsJ8TRo9B9+or3x90fC0ii63unKLEYETx/XRlTwq2pC Rm3+NvqDbybg5uW195pQ4UcXAZKnE/s63GXNoU199kuQgkTQ2C4ue/ZmVCV4XbbdkkZ4 pqewt+gqnRX/LGfjHaJcw25Z9Sndu5obVJVuQTkNJrkcHNSKvaiknafKLsl/Q883oj22 cjdg== X-Gm-Message-State: ALoCoQkS4oxtd1t19uH6+F9+G8zCH8EiuAU7yCSoyaECEgIt/ABVudmvJmVyFmm7QiWjT+Om01MsX4h2YOE4zpOxrA0mR9IfjzKBW6SwCfUbbPfaELezn4+LcWph2Vk2oQzw4+AIA2JG X-Received: by 10.43.62.204 with SMTP id xb12mr2808994icb.51.1400070303987; Wed, 14 May 2014 05:25:03 -0700 (PDT) X-Received: by 10.43.62.204 with SMTP id xb12mr2808985icb.51.1400070303849; Wed, 14 May 2014 05:25:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Wed, 14 May 2014 05:24:32 -0700 (PDT) In-Reply-To: <536BF140.5070106@gmx.net> References: <536BF140.5070106@gmx.net> From: Brian Campbell Date: Wed, 14 May 2014 06:24:32 -0600 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=bcaec51a8b1a1f348804f95b4524 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/x9775b9qp5o-XSnrpwdS7j7EZ_s Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 12:25:14 -0000 --bcaec51a8b1a1f348804f95b4524 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago. As I recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter. I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients. On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig wrote: > Hi all, > > you might have seen that we pushed the assertion documents and the JWT > documents to the IESG today. We have also updated the milestones on the > OAuth WG page. > > This means that we can plan to pick up new work in the group. > We have sent a request to Kathleen to change the milestone for the OAuth > security mechanisms to use the proof-of-possession terminology. > > We also expect an updated version of the dynamic client registration > spec incorporating last call feedback within about 2 weeks. > > We would like you to think about adding the following milestones to the > charter as part of the re-chartering effort: > > ----- > > Nov 2014 Submit 'Token introspection' to the IESG for consideration as a > Proposed Standard > Starting point: > > Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as > a Proposed Standard > Starting point: > > Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a > Proposed Standard > Starting point: > > ----- > > We also updated the charter text to reflect the current situation. Here > is the proposed text: > > ----- > > Charter for Working Group > > > The Web Authorization (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that > supports OAuth could allow its users to use a third-party printing Web > site to print their private pictures, without allowing the printing > site to gain full control of the user's account and without having the > user share his or her photo-sharing sites' long-term credential with > the printing site. > > The OAuth 2.0 protocol suite encompasses > > * a protocol for obtaining access tokens from an authorization > server with the resource owner's consent, > * protocols for presenting these access tokens to resource server > for access to a protected resource, > * guidance for securely using OAuth 2.0, > * the ability to revoke access tokens, > * standardized format for security tokens encoded in a JSON format > (JSON Web Token, JWT), > * ways of using assertions with OAuth, and > * a dynamic client registration protocol. > > The working group also developed security schemes for presenting > authorization tokens to access a protected resource. This led to the > publication of the bearer token, as well as work that remains to be > completed on proof-of-possession and token exchange. > > The ongoing standardization effort within the OAuth working group will > focus on enhancing interoperability and functionality of OAuth > deployments, such as a standard for a token introspection service and > standards for additional security of OAuth requests. > > ----- > > Feedback appreciated. > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 [image: Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with us=E2=80=A6 [image: twitter logo] = [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo] [image: flipboard logo] [image: rss feed icon] [image: Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] --bcaec51a8b1a1f348804f95b4524 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would object to 'OAuth Authentication' being pic= ked up by the WG as a work item. The starting point draft has expired and i= t hasn't really been discusses since Berlin nearly a year ago.=C2=A0 As= I recall, there was only very limited interest in it even then. I also don= 't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof o= f Possession for Code Extension' for which there is an excellent startin= g point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-0= 3 - it's a relativity simple security enhancement which addresses p= roblems currently being encountered in deployments of native clients.=C2=A0=




On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofe= nig@gmx.net> wrote:
Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration= as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideratio= n as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a=
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the<= br> user share his or her photo-sharing sites' long-term credential with the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
=C2=A0 (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--
--bcaec51a8b1a1f348804f95b4524-- From nobody Wed May 14 08:32:15 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FF71A02A1 for ; Wed, 14 May 2014 08:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.84 X-Spam-Level: X-Spam-Status: No, score=-4.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 pfqD6XaokUzn for ; Wed, 14 May 2014 08:32:09 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 245201A00CD for ; Wed, 14 May 2014 08:32:09 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4EFVwQR003192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 May 2014 15:31:59 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s4EFVqjh029691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2014 15:31:58 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4EFVqwm019898; Wed, 14 May 2014 15:31:52 GMT Received: from [192.168.1.3] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 May 2014 08:31:52 -0700 References: <536BF140.5070106@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-EB93754D-9132-4096-9237-A1BBDD7A98A7 Content-Transfer-Encoding: 7bit Message-Id: <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> X-Mailer: iPhone Mail (11D167) From: Phil Hunt Date: Wed, 14 May 2014 08:31:49 -0700 To: Brian Campbell X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/FQp91RpCK-_-_3jaeAWkoDNW_Bs Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 15:32:13 -0000 --Apple-Mail-EB93754D-9132-4096-9237-A1BBDD7A98A7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On the contrary. I and others are interested.=20 We are waiting for the charter to pick up the work.=20 Regardless there will be a new draft shortly.=20 Phil > On May 14, 2014, at 5:24, Brian Campbell wrot= e: >=20 > I would object to 'OAuth Authentication' being picked up by the WG as a wo= rk item. The starting point draft has expired and it hasn't really been disc= usses since Berlin nearly a year ago. As I recall, there was only very limi= ted interest in it even then. I also don't believe it fits well with the WG c= harter. >=20 > I would suggest the WG consider picking up 'OAuth Symmetric Proof of Posse= ssion for Code Extension' for which there is an excellent starting point of h= ttp://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity s= imple security enhancement which addresses problems currently being encounte= red in deployments of native clients. =20 >=20 >=20 >=20 >=20 >> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig wrote: >> Hi all, >>=20 >> you might have seen that we pushed the assertion documents and the JWT >> documents to the IESG today. We have also updated the milestones on the >> OAuth WG page. >>=20 >> This means that we can plan to pick up new work in the group. >> We have sent a request to Kathleen to change the milestone for the OAuth >> security mechanisms to use the proof-of-possession terminology. >>=20 >> We also expect an updated version of the dynamic client registration >> spec incorporating last call feedback within about 2 weeks. >>=20 >> We would like you to think about adding the following milestones to the >> charter as part of the re-chartering effort: >>=20 >> ----- >>=20 >> Nov 2014 Submit 'Token introspection' to the IESG for consideration as a >> Proposed Standard >> Starting point: >>=20 >> Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as >> a Proposed Standard >> Starting point: >>=20 >> Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a >> Proposed Standard >> Starting point: >>=20 >> ----- >>=20 >> We also updated the charter text to reflect the current situation. Here >> is the proposed text: >>=20 >> ----- >>=20 >> Charter for Working Group >>=20 >>=20 >> The Web Authorization (OAuth) protocol allows a user to grant a >> third-party Web site or application access to the user's protected >> resources, without necessarily revealing their long-term credentials, >> or even their identity. For example, a photo-sharing site that >> supports OAuth could allow its users to use a third-party printing Web >> site to print their private pictures, without allowing the printing >> site to gain full control of the user's account and without having the >> user share his or her photo-sharing sites' long-term credential with >> the printing site. >>=20 >> The OAuth 2.0 protocol suite encompasses >>=20 >> * a protocol for obtaining access tokens from an authorization >> server with the resource owner's consent, >> * protocols for presenting these access tokens to resource server >> for access to a protected resource, >> * guidance for securely using OAuth 2.0, >> * the ability to revoke access tokens, >> * standardized format for security tokens encoded in a JSON format >> (JSON Web Token, JWT), >> * ways of using assertions with OAuth, and >> * a dynamic client registration protocol. >>=20 >> The working group also developed security schemes for presenting >> authorization tokens to access a protected resource. This led to the >> publication of the bearer token, as well as work that remains to be >> completed on proof-of-possession and token exchange. >>=20 >> The ongoing standardization effort within the OAuth working group will >> focus on enhancing interoperability and functionality of OAuth >> deployments, such as a standard for a token introspection service and >> standards for additional security of OAuth requests. >>=20 >> ----- >>=20 >> Feedback appreciated. >>=20 >> Ciao >> Hannes & Derek >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 > =09 > Brian Campbell > Portfolio Architect > @ bcampbell@pingidentity.com > +1 720.317.2061 > Connect with us=E2=80=A6 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-EB93754D-9132-4096-9237-A1BBDD7A98A7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On the contrary. I and others are inte= rested. 

We are waiting for the charter to pic= k up the work. 

Regardless there will be a new= draft shortly. 

Phil

On May 14, 2014, at 5= :24, Brian Campbell <bcampb= ell@pingidentity.com> wrote:

<= div>
I would object to 'OAuth Authentication' being picked u= p by the WG as a work item. The starting point draft has expired and it hasn= 't really been discusses since Berlin nearly a year ago.  As I recall, t= here was only very limited interest in it even then. I also don't believe it= fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03<= /a> - it's a relativity simple security enhancement which addresses problems= currently being encountered in deployments of native clients. 




= On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig= @gmx.net> wrote:
Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
= security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
= Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--
3D"Ping =09
Br= ian Campbell
Portfolio Architect =09
@ bcampbell@pingidentity.com
+1 720.317.2061
Con= nect with us=E2=80=A6
3D"twitter 3D"youtube 3D"Facebook= 3D"Google+ 3D"slideshare 3D= 3D"rss
3D"Register<= /td>

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-EB93754D-9132-4096-9237-A1BBDD7A98A7-- From nobody Wed May 14 08:39:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DEF1A0110 for ; Wed, 14 May 2014 08:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.241 X-Spam-Level: X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 TPHCGO9ZZq9f for ; Wed, 14 May 2014 08:38:54 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 147C61A00CD for ; Wed, 14 May 2014 08:38:53 -0700 (PDT) X-AuditID: 1209190c-f79946d000000c3b-a7-53738e07cf8d Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id C2.19.03131.70E83735; Wed, 14 May 2014 11:38:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s4EFcjkn001200; Wed, 14 May 2014 11:38:46 -0400 Received: from [18.189.28.96] ([18.189.28.96]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4EFchTv003473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 May 2014 11:38:44 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_160C4D6C-2A9D-4BE0-B675-CB5CA622B0DF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Justin Richer In-Reply-To: Date: Wed, 14 May 2014 11:38:42 -0400 Message-Id: <84B60891-F9E1-4183-9031-8BED6315C70F@mit.edu> References: <536BF140.5070106@gmx.net> To: Brian Campbell X-Mailer: Apple Mail (2.1874) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAKsWRmVeSWpSXmKPExsUixCmqrcveVxxscPkOh8Xq/zcZLZbuvMdq cfLtKzYHZo/Fm/azeSxZ8pPJ4+7RiywBzFFcNimpOZllqUX6dglcGbOnPWIqeN/JWDH9ygHW BsbFpV2MnBwSAiYSN27eZoOwxSQu3FsPZHNxCAnMZpLYdfo2E4SzkVHi3byFzBDOYiaJ319/ gWWYBSYxSsw7OZ0ZpJ9XQE+iac1EJhBbWMBeYtXSr6wgNpuAqsT8lbeA4hwcnAKBEk2fvUDC LEDhuxtawFqZBWIl1i48zAIxxkri7P2LrCDlQgLZEgvnVIOERQT0JW4/ncMOcamsxKMPTSwT GAVmIbtiFpIrZoGNTZL4cmgSK4StLbFs4WtmCNtA4mnnKyzi+hJv3s2B6pWX2P52DlTcUmLx zBssELatxK2+BVA1dhKPpi1iXcDIvYpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXUC83s0QvNaV0 EyM4AiV5djC+Oah0iFGAg1GJh/eGc1GwEGtiWXFl7iFGSQ4mJVHe8o7iYCG+pPyUyozE4oz4 otKc1OJDjCpAux5tWH2BUYolLz8vVUmE90MbUB1vSmJlVWpRPkyZNAeLkjjvW2urYCGB9MSS 1OzU1ILUIpisDAeHkgSvaC9Qo2BRanpqRVpmTglCmomD8xCjBAcP0HB/kBre4oLE3OLMdIj8 KUZdjjvP17YwCYFdICXOq9ADVCQAUpRRmgc3B5ZQXzGKA70ozCsOMooHmIzhJr0CWsIEtOSE WxHIkpJEhJRUA2PLZtWmdEPxm60L7rX9kuIUtI7K7nRnmWece2fiXrMInk/fxK+klP2blLvP RmvKPgMZ059sOScmr5u/ytH8/pKzVye3qjT+eMdwMGNZ0CruLd7qix1Ozq9ITq/017jtnfzk qdnPxX6Xvv0Pmf7o+va12gekWEwNsuw/7RPaGRkV8X0P88NUxQAlluKMREMt5qLiRAC+0pIS gwMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/UL5uiUmgyn-mc46S3J8C3TZtMA8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 15:38:58 -0000 --Apple-Mail=_160C4D6C-2A9D-4BE0-B675-CB5CA622B0DF Content-Type: multipart/alternative; boundary="Apple-Mail=_2756B1C4-3C2F-4363-841E-121CD653A8ED" --Apple-Mail=_2756B1C4-3C2F-4363-841E-121CD653A8ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I agree with Brian and object to the Authentication work item. I think = there=92s limited interest and utility in such a draft, especially now = that OpenID Connect has been published and its core authentication = capabilities are identical to what was called for in the other draft a = year ago (a similarity, I=92ll add, which was noted at the time).=20 =97 Justin On May 14, 2014, at 8:24 AM, Brian Campbell = wrote: > I would object to 'OAuth Authentication' being picked up by the WG as = a work item. The starting point draft has expired and it hasn't really = been discusses since Berlin nearly a year ago. As I recall, there was = only very limited interest in it even then. I also don't believe it fits = well with the WG charter. >=20 > I would suggest the WG consider picking up 'OAuth Symmetric Proof of = Possession for Code Extension' for which there is an excellent starting = point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's = a relativity simple security enhancement which addresses problems = currently being encountered in deployments of native clients. =20 >=20 >=20 >=20 >=20 > On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig = wrote: > Hi all, >=20 > you might have seen that we pushed the assertion documents and the JWT > documents to the IESG today. We have also updated the milestones on = the > OAuth WG page. >=20 > This means that we can plan to pick up new work in the group. > We have sent a request to Kathleen to change the milestone for the = OAuth > security mechanisms to use the proof-of-possession terminology. >=20 > We also expect an updated version of the dynamic client registration > spec incorporating last call feedback within about 2 weeks. >=20 > We would like you to think about adding the following milestones to = the > charter as part of the re-chartering effort: >=20 > ----- >=20 > Nov 2014 Submit 'Token introspection' to the IESG for consideration as = a > Proposed Standard > Starting point: >=20 > Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration = as > a Proposed Standard > Starting point: >=20 > Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a > Proposed Standard > Starting point: >=20 > ----- >=20 > We also updated the charter text to reflect the current situation. = Here > is the proposed text: >=20 > ----- >=20 > Charter for Working Group >=20 >=20 > The Web Authorization (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that > supports OAuth could allow its users to use a third-party printing Web > site to print their private pictures, without allowing the printing > site to gain full control of the user's account and without having the > user share his or her photo-sharing sites' long-term credential with > the printing site. >=20 > The OAuth 2.0 protocol suite encompasses >=20 > * a protocol for obtaining access tokens from an authorization > server with the resource owner's consent, > * protocols for presenting these access tokens to resource server > for access to a protected resource, > * guidance for securely using OAuth 2.0, > * the ability to revoke access tokens, > * standardized format for security tokens encoded in a JSON format > (JSON Web Token, JWT), > * ways of using assertions with OAuth, and > * a dynamic client registration protocol. >=20 > The working group also developed security schemes for presenting > authorization tokens to access a protected resource. This led to the > publication of the bearer token, as well as work that remains to be > completed on proof-of-possession and token exchange. >=20 > The ongoing standardization effort within the OAuth working group will > focus on enhancing interoperability and functionality of OAuth > deployments, such as a standard for a token introspection service and > standards for additional security of OAuth requests. >=20 > ----- >=20 > Feedback appreciated. >=20 > Ciao > Hannes & Derek >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > --=20 > =09 > Brian Campbell > Portfolio Architect > @ bcampbell@pingidentity.com > +1 720.317.2061 > Connect with us=85 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2756B1C4-3C2F-4363-841E-121CD653A8ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = agree with Brian and object to the Authentication work item. I think = there=92s limited interest and utility in such a draft, especially now = that OpenID Connect has been published and its core authentication = capabilities are identical to what was called for in the other draft a = year ago (a similarity, I=92ll add, which was noted at the = time). 

 =97 = Justin

On May 14, 2014, at 8:24 AM, Brian Campbell = <bcampbell@pingidentity.com&= gt; wrote:

I would object to 'OAuth = Authentication' being picked up by the WG as a work item. The starting = point draft has expired and it hasn't really been discusses since Berlin = nearly a year ago.  As I recall, there was only very limited = interest in it even then. I also don't believe it fits well with the WG = charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03<= /a> - it's a relativity simple security enhancement which addresses = problems currently being encountered in deployments of native = clients. 




On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig = <hannes.tschofenig@gmx.net> wrote:
Hi all,

you might have seen that we pushed the assertion documents and the = JWT
documents to the IESG today. We have also updated the milestones on = the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the = OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to = the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as = a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration = as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. = Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term = credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing = Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having = the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group = will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service = and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--
3D"Ping =09
Brian Campbell
Portfolio = Architect
=09
= @ = bcampbell@pingidentity.com
= 3D"phone" = +1 720.317.2061
= Connect with us=85
= 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard
3D"Register

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

= --Apple-Mail=_2756B1C4-3C2F-4363-841E-121CD653A8ED-- --Apple-Mail=_160C4D6C-2A9D-4BE0-B675-CB5CA622B0DF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTc44CAAoJEDPAngkbd+w9P+8H/0Jk1lNwecWG3U91bJltD7nA JFlRW0pC6SK7X1gOCT5L+9ZQvun76CcO1NNXg7ROkDQz/eq+rczgMATcHl83STwj n0c2HJHXMIScyUBNGDxlYAJ/CFGLvhHqPjM/2L79gUNEheu7h9gCL2EW3DqlDbom t3tyRWKSYS3krYvv7lAhWfHpXff+ibbrFvPkw+X2ranXctIU8X2LYKb+UIlVXOsx bJslttrMab5SbcrPZ6ixvvXMj04VmM7EpM4PZW893GMeH07ayNks4iqFScArlbD6 oadk92fTDxhCClnIsFTfDyK3vKM1HkwtqG/fdAAb1F+ANcNN5tpJQ1Ua6sbOih4= =57Kb -----END PGP SIGNATURE----- --Apple-Mail=_160C4D6C-2A9D-4BE0-B675-CB5CA622B0DF-- From nobody Wed May 14 08:42:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09161A02E8 for ; Wed, 14 May 2014 08:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 mKk_Dj44ZJ9d for ; Wed, 14 May 2014 08:41:58 -0700 (PDT) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id D22B81A02AC for ; Wed, 14 May 2014 08:41:57 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id j17so2370001oag.15 for ; Wed, 14 May 2014 08:41:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:from:mime-version:in-reply-to:date :message-id:subject:to:cc:content-type; bh=nX/sU6zEmjtDRQcKZKUMwM0ZFEAjEXk+HIWUC+HlyJ4=; b=WV1zFxv+Ch31onAwatxOlUDdQd7pyw41RPhoTrQOorMzPu3Upnr1TGTQpOrRowJTKN FkVzV5X2GXCOOzksJ0bkSyCkpAk8/TG/+n10/Q0Ug5ps1bG9inK5Sasjm1NCQLIB4Hji AULjDJWJz/+rjrrI4hHQQ+EQKjVFsa0+nEVXT2eO8MwYJJmG/nhva9IBgQXFnqe/8S85 x3xJP5MW5BcSB9kQqH6gbawQyKAouabwCicpidsQL743JTBFAvNXf02otJ4dnrtVmELc OPj6ZXicJ0yrvZMzUWZIkXF2DTLs56ZxlyjYWWVCwnR+rmpJHYl+h03d+QohMUidx4N2 QG4Q== X-Gm-Message-State: ALoCoQn4X6LEUP74SEJ198iYD8ZuWGfT6wr3REOOENPSNE5pO80qREKA+LlyAHL9MMKGeoWPhqbz X-Received: by 10.182.102.99 with SMTP id fn3mr4098056obb.57.1400082111112; Wed, 14 May 2014 08:41:51 -0700 (PDT) References: <536BF140.5070106@gmx.net> <84B60891-F9E1-4183-9031-8BED6315C70F@mit.edu> From: Chuck Mortimore Mime-Version: 1.0 (1.0) In-Reply-To: <84B60891-F9E1-4183-9031-8BED6315C70F@mit.edu> Date: Wed, 14 May 2014 08:41:45 -0700 Message-ID: <-968574624925308911@unknownmsgid> To: Justin Richer Content-Type: multipart/alternative; boundary=089e013d0d68e3c3a904f95e049b Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/i4qWsUPt-8e7Cdfr-SWxQbEC_Bw Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 15:42:00 -0000 --089e013d0d68e3c3a904f95e049b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agree with Brian and Justin here. Work is already covered in Connect - cmort On May 14, 2014, at 8:39 AM, Justin Richer wrote: I agree with Brian and object to the Authentication work item. I think there=E2=80=99s limited interest and utility in such a draft, especially no= w that OpenID Connect has been published and its core authentication capabilities are identical to what was called for in the other draft a year ago (a similarity, I=E2=80=99ll add, which was noted at the time). =E2=80=94 Justin On May 14, 2014, at 8:24 AM, Brian Campbell wrote: I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago. As I recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter. I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients. On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig wrote: > Hi all, > > you might have seen that we pushed the assertion documents and the JWT > documents to the IESG today. We have also updated the milestones on the > OAuth WG page. > > This means that we can plan to pick up new work in the group. > We have sent a request to Kathleen to change the milestone for the OAuth > security mechanisms to use the proof-of-possession terminology. > > We also expect an updated version of the dynamic client registration > spec incorporating last call feedback within about 2 weeks. > > We would like you to think about adding the following milestones to the > charter as part of the re-chartering effort: > > ----- > > Nov 2014 Submit 'Token introspection' to the IESG for consideration as a > Proposed Standard > Starting point: > > Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as > a Proposed Standard > Starting point: > > Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a > Proposed Standard > Starting point: > > ----- > > We also updated the charter text to reflect the current situation. Here > is the proposed text: > > ----- > > Charter for Working Group > > > The Web Authorization (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that > supports OAuth could allow its users to use a third-party printing Web > site to print their private pictures, without allowing the printing > site to gain full control of the user's account and without having the > user share his or her photo-sharing sites' long-term credential with > the printing site. > > The OAuth 2.0 protocol suite encompasses > > * a protocol for obtaining access tokens from an authorization > server with the resource owner's consent, > * protocols for presenting these access tokens to resource server > for access to a protected resource, > * guidance for securely using OAuth 2.0, > * the ability to revoke access tokens, > * standardized format for security tokens encoded in a JSON format > (JSON Web Token, JWT), > * ways of using assertions with OAuth, and > * a dynamic client registration protocol. > > The working group also developed security schemes for presenting > authorization tokens to access a protected resource. This led to the > publication of the bearer token, as well as work that remains to be > completed on proof-of-possession and token exchange. > > The ongoing standardization effort within the OAuth working group will > focus on enhancing interoperability and functionality of OAuth > deployments, such as a standard for a token introspection service and > standards for additional security of OAuth requests. > > ----- > > Feedback appreciated. > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 [image: Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with us=E2=80=A6 [image: twitter logo] = [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo] [image: flipboard logo] [image: rss feed icon] [image: Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] _______________________________________________ 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 --089e013d0d68e3c3a904f95e049b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree with Brian and Justin here. = =C2=A0 Work is already covered in Connect

- cmort

On M= ay 14, 2014, at 8:39 AM, Justin Richer <jricher@mit.edu> wrote:

I agree with Brian and object = to the Authentication work item. I think there=E2=80=99s limited interest a= nd utility in such a draft, especially now that OpenID Connect has been pub= lished and its core authentication capabilities are identical to what was c= alled for in the other draft a year ago (a similarity, I=E2=80=99ll add, wh= ich was noted at the time).=C2=A0

=C2=A0=E2=80=94 Justin

On May 14, 2014= , at 8:24 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to 'OAuth Authe= ntication' being picked up by the WG as a work item. The starting point= draft has expired and it hasn't really been discusses since Berlin nea= rly a year ago.=C2=A0 As I recall, there was only very limited interest in = it even then. I also don't believe it fits well with the WG charter.
I would suggest the WG consider picking up 'OAuth Symmetric Proof o= f Possession for Code Extension' for which there is an excellent startin= g point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-0= 3 - it's a relativity simple security enhancement which addresses p= roblems currently being encountered in deployments of native clients.=C2=A0=




On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofe= nig@gmx.net> wrote:
Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration= as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideratio= n as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a=
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the<= br> user share his or her photo-sharing sites' long-term credential with the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
=C2=A0 (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oa= uth

_______________________________________________
<= span>OAuth mailing list
O= Auth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth
--089e013d0d68e3c3a904f95e049b-- From nobody Wed May 14 08:47:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE501A00B8 for ; Wed, 14 May 2014 08:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 6YwxWQ8vHl83 for ; Wed, 14 May 2014 08:47:29 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEDA1A00A6 for ; Wed, 14 May 2014 08:47:26 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB312.namprd03.prod.outlook.com (10.141.48.28) with Microsoft SMTP Server (TLS) id 15.0.939.12; Wed, 14 May 2014 15:47:18 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0949.001; Wed, 14 May 2014 15:47:18 +0000 From: Anthony Nadalin To: Phil Hunt , Brian Campbell Thread-Topic: [OAUTH-WG] OAuth Milestone Update and Rechartering Thread-Index: AQHPawEbu8OzlywPcU+RkLqz+fSkNptACOgAgAA0VICAAAQKYA== Date: Wed, 14 May 2014 15:47:17 +0000 Message-ID: References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> In-Reply-To: <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.110.65.1] x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(199002)(189002)(377454003)(24454002)(31966008)(83072002)(74662001)(76176999)(15202345003)(19617315010)(19300405004)(21056001)(92566001)(2656002)(87936001)(18206015023)(99396002)(15975445006)(50986999)(74502001)(99286001)(77096999)(74316001)(79102001)(33646001)(19609705001)(86612001)(15198665003)(16236675002)(86362001)(46102001)(19273905006)(54356999)(66066001)(101416001)(19580405001)(76482001)(4396001)(15395725003)(85852003)(77982001)(20776003)(81542001)(64706001)(76576001)(83322001)(19618635001)(81342001)(19625215002)(80022001)(19580395003)(42262001)(9984715005)(24736002)(19621445023); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB312; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; Content-Type: multipart/alternative; boundary="_000_a004992672a54c32a2237112dab67050BLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Drf3nI38EfK0svgCA29V8bkPLEo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 15:47:32 -0000 --_000_a004992672a54c32a2237112dab67050BLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIFBoaWwgb24gdGhpcyBvbmUsIHRoZXJlIGFyZSBpbXBsZW1lbnRhdGlvbnMg b2YgdGhpcyBhbHJlYWR5IGFuZCBtdWNoIGludGVyZXN0DQoNCkZyb206IE9BdXRoIFttYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWwgSHVudA0KU2VudDogV2Vk bmVzZGF5LCBNYXkgMTQsIDIwMTQgODozMiBBTQ0KVG86IEJyaWFuIENhbXBiZWxsDQpDYzogb2F1 dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIE1pbGVzdG9uZSBVcGRh dGUgYW5kIFJlY2hhcnRlcmluZw0KDQpPbiB0aGUgY29udHJhcnkuIEkgYW5kIG90aGVycyBhcmUg aW50ZXJlc3RlZC4NCg0KV2UgYXJlIHdhaXRpbmcgZm9yIHRoZSBjaGFydGVyIHRvIHBpY2sgdXAg dGhlIHdvcmsuDQoNClJlZ2FyZGxlc3MgdGhlcmUgd2lsbCBiZSBhIG5ldyBkcmFmdCBzaG9ydGx5 Lg0KDQpQaGlsDQoNCk9uIE1heSAxNCwgMjAxNCwgYXQgNToyNCwgQnJpYW4gQ2FtcGJlbGwgPGJj YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bT4+IHdyb3RlOg0KSSB3b3VsZCBvYmplY3QgdG8gJ09BdXRoIEF1dGhlbnRpY2F0aW9uJyBiZWlu ZyBwaWNrZWQgdXAgYnkgdGhlIFdHIGFzIGEgd29yayBpdGVtLiBUaGUgc3RhcnRpbmcgcG9pbnQg ZHJhZnQgaGFzIGV4cGlyZWQgYW5kIGl0IGhhc24ndCByZWFsbHkgYmVlbiBkaXNjdXNzZXMgc2lu Y2UgQmVybGluIG5lYXJseSBhIHllYXIgYWdvLiAgQXMgSSByZWNhbGwsIHRoZXJlIHdhcyBvbmx5 IHZlcnkgbGltaXRlZCBpbnRlcmVzdCBpbiBpdCBldmVuIHRoZW4uIEkgYWxzbyBkb24ndCBiZWxp ZXZlIGl0IGZpdHMgd2VsbCB3aXRoIHRoZSBXRyBjaGFydGVyLg0KDQpJIHdvdWxkIHN1Z2dlc3Qg dGhlIFdHIGNvbnNpZGVyIHBpY2tpbmcgdXAgJ09BdXRoIFN5bW1ldHJpYyBQcm9vZiBvZiBQb3Nz ZXNzaW9uIGZvciBDb2RlIEV4dGVuc2lvbicgZm9yIHdoaWNoIHRoZXJlIGlzIGFuIGV4Y2VsbGVu dCBzdGFydGluZyBwb2ludCBvZiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtp bXVyYS1vYXV0aC10Y3NlLTAzIC0gaXQncyBhIHJlbGF0aXZpdHkgc2ltcGxlIHNlY3VyaXR5IGVu aGFuY2VtZW50IHdoaWNoIGFkZHJlc3NlcyBwcm9ibGVtcyBjdXJyZW50bHkgYmVpbmcgZW5jb3Vu dGVyZWQgaW4gZGVwbG95bWVudHMgb2YgbmF0aXZlIGNsaWVudHMuDQoNCg0KT24gVGh1LCBNYXkg OCwgMjAxNCBhdCAzOjA0IFBNLCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdA Z214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4+IHdyb3RlOg0KSGkgYWxs LA0KDQp5b3UgbWlnaHQgaGF2ZSBzZWVuIHRoYXQgd2UgcHVzaGVkIHRoZSBhc3NlcnRpb24gZG9j dW1lbnRzIGFuZCB0aGUgSldUDQpkb2N1bWVudHMgdG8gdGhlIElFU0cgdG9kYXkuIFdlIGhhdmUg YWxzbyB1cGRhdGVkIHRoZSBtaWxlc3RvbmVzIG9uIHRoZQ0KT0F1dGggV0cgcGFnZS4NCg0KVGhp cyBtZWFucyB0aGF0IHdlIGNhbiBwbGFuIHRvIHBpY2sgdXAgbmV3IHdvcmsgaW4gdGhlIGdyb3Vw Lg0KV2UgaGF2ZSBzZW50IGEgcmVxdWVzdCB0byBLYXRobGVlbiB0byBjaGFuZ2UgdGhlIG1pbGVz dG9uZSBmb3IgdGhlIE9BdXRoDQpzZWN1cml0eSBtZWNoYW5pc21zIHRvIHVzZSB0aGUgcHJvb2Yt b2YtcG9zc2Vzc2lvbiB0ZXJtaW5vbG9neS4NCg0KV2UgYWxzbyBleHBlY3QgYW4gdXBkYXRlZCB2 ZXJzaW9uIG9mIHRoZSBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24NCnNwZWMgaW5jb3Jwb3Jh dGluZyBsYXN0IGNhbGwgZmVlZGJhY2sgd2l0aGluIGFib3V0IDIgd2Vla3MuDQoNCldlIHdvdWxk IGxpa2UgeW91IHRvIHRoaW5rIGFib3V0IGFkZGluZyB0aGUgZm9sbG93aW5nIG1pbGVzdG9uZXMg dG8gdGhlDQpjaGFydGVyIGFzIHBhcnQgb2YgdGhlIHJlLWNoYXJ0ZXJpbmcgZWZmb3J0Og0KDQot LS0tLQ0KDQpOb3YgMjAxNCBTdWJtaXQgJ1Rva2VuIGludHJvc3BlY3Rpb24nIHRvIHRoZSBJRVNH IGZvciBjb25zaWRlcmF0aW9uIGFzIGENClByb3Bvc2VkIFN0YW5kYXJkDQpTdGFydGluZyBwb2lu dDogPGRyYWZ0LXJpY2hlci1vYXV0aC1pbnRyb3NwZWN0aW9uLTA0Pg0KDQpKYW4gMjAxNSBTdWJt aXQgJ09BdXRoIEF1dGhlbnRpY2F0aW9uJyB0byB0aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBh cw0KYSBQcm9wb3NlZCBTdGFuZGFyZA0KU3RhcnRpbmcgcG9pbnQ6IDxkcmFmdC1odW50LW9hdXRo LXYyLXVzZXItYTRjLTAxPg0KDQpKYW4gMjAxNSBTdWJtaXQgJ1Rva2VuIEV4Y2hhbmdlJyB0byB0 aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBhcyBhDQpQcm9wb3NlZCBTdGFuZGFyZA0KU3RhcnRp bmcgcG9pbnQ6IDxkcmFmdC1qb25lcy1vYXV0aC10b2tlbi1leGNoYW5nZS0wMD4NCg0KLS0tLS0N Cg0KV2UgYWxzbyB1cGRhdGVkIHRoZSBjaGFydGVyIHRleHQgdG8gcmVmbGVjdCB0aGUgY3VycmVu dCBzaXR1YXRpb24uIEhlcmUNCmlzIHRoZSBwcm9wb3NlZCB0ZXh0Og0KDQotLS0tLQ0KDQpDaGFy dGVyIGZvciBXb3JraW5nIEdyb3VwDQoNCg0KVGhlIFdlYiBBdXRob3JpemF0aW9uIChPQXV0aCkg cHJvdG9jb2wgYWxsb3dzIGEgdXNlciB0byBncmFudCBhDQp0aGlyZC1wYXJ0eSBXZWIgc2l0ZSBv ciBhcHBsaWNhdGlvbiBhY2Nlc3MgdG8gdGhlIHVzZXIncyBwcm90ZWN0ZWQNCnJlc291cmNlcywg d2l0aG91dCBuZWNlc3NhcmlseSByZXZlYWxpbmcgdGhlaXIgbG9uZy10ZXJtIGNyZWRlbnRpYWxz LA0Kb3IgZXZlbiB0aGVpciBpZGVudGl0eS4gRm9yIGV4YW1wbGUsIGEgcGhvdG8tc2hhcmluZyBz aXRlIHRoYXQNCnN1cHBvcnRzIE9BdXRoIGNvdWxkIGFsbG93IGl0cyB1c2VycyB0byB1c2UgYSB0 aGlyZC1wYXJ0eSBwcmludGluZyBXZWINCnNpdGUgdG8gcHJpbnQgdGhlaXIgcHJpdmF0ZSBwaWN0 dXJlcywgd2l0aG91dCBhbGxvd2luZyB0aGUgcHJpbnRpbmcNCnNpdGUgdG8gZ2FpbiBmdWxsIGNv bnRyb2wgb2YgdGhlIHVzZXIncyBhY2NvdW50IGFuZCB3aXRob3V0IGhhdmluZyB0aGUNCnVzZXIg c2hhcmUgaGlzIG9yIGhlciBwaG90by1zaGFyaW5nIHNpdGVzJyBsb25nLXRlcm0gY3JlZGVudGlh bCB3aXRoDQp0aGUgcHJpbnRpbmcgc2l0ZS4NCg0KVGhlIE9BdXRoIDIuMCBwcm90b2NvbCBzdWl0 ZSBlbmNvbXBhc3Nlcw0KDQoqIGEgcHJvdG9jb2wgZm9yIG9idGFpbmluZyBhY2Nlc3MgdG9rZW5z IGZyb20gYW4gYXV0aG9yaXphdGlvbg0Kc2VydmVyIHdpdGggdGhlIHJlc291cmNlIG93bmVyJ3Mg Y29uc2VudCwNCiogcHJvdG9jb2xzIGZvciBwcmVzZW50aW5nIHRoZXNlIGFjY2VzcyB0b2tlbnMg dG8gcmVzb3VyY2Ugc2VydmVyDQpmb3IgYWNjZXNzIHRvIGEgcHJvdGVjdGVkIHJlc291cmNlLA0K KiBndWlkYW5jZSBmb3Igc2VjdXJlbHkgdXNpbmcgT0F1dGggMi4wLA0KKiB0aGUgYWJpbGl0eSB0 byByZXZva2UgYWNjZXNzIHRva2VucywNCiogc3RhbmRhcmRpemVkIGZvcm1hdCBmb3Igc2VjdXJp dHkgdG9rZW5zIGVuY29kZWQgaW4gYSBKU09OIGZvcm1hdA0KICAoSlNPTiBXZWIgVG9rZW4sIEpX VCksDQoqIHdheXMgb2YgdXNpbmcgYXNzZXJ0aW9ucyB3aXRoIE9BdXRoLCBhbmQNCiogYSBkeW5h bWljIGNsaWVudCByZWdpc3RyYXRpb24gcHJvdG9jb2wuDQoNClRoZSB3b3JraW5nIGdyb3VwIGFs c28gZGV2ZWxvcGVkIHNlY3VyaXR5IHNjaGVtZXMgZm9yIHByZXNlbnRpbmcNCmF1dGhvcml6YXRp b24gdG9rZW5zIHRvIGFjY2VzcyBhIHByb3RlY3RlZCByZXNvdXJjZS4gVGhpcyBsZWQgdG8gdGhl DQpwdWJsaWNhdGlvbiBvZiB0aGUgYmVhcmVyIHRva2VuLCBhcyB3ZWxsIGFzIHdvcmsgdGhhdCBy ZW1haW5zIHRvIGJlDQpjb21wbGV0ZWQgb24gcHJvb2Ytb2YtcG9zc2Vzc2lvbiBhbmQgdG9rZW4g ZXhjaGFuZ2UuDQoNClRoZSBvbmdvaW5nIHN0YW5kYXJkaXphdGlvbiBlZmZvcnQgd2l0aGluIHRo ZSBPQXV0aCB3b3JraW5nIGdyb3VwIHdpbGwNCmZvY3VzIG9uIGVuaGFuY2luZyBpbnRlcm9wZXJh YmlsaXR5IGFuZCBmdW5jdGlvbmFsaXR5IG9mIE9BdXRoDQpkZXBsb3ltZW50cywgc3VjaCBhcyBh IHN0YW5kYXJkIGZvciBhIHRva2VuIGludHJvc3BlY3Rpb24gc2VydmljZSBhbmQNCnN0YW5kYXJk cyBmb3IgYWRkaXRpb25hbCBzZWN1cml0eSBvZiBPQXV0aCByZXF1ZXN0cy4NCg0KLS0tLS0NCg0K RmVlZGJhY2sgYXBwcmVjaWF0ZWQuDQoNCkNpYW8NCkhhbm5lcyAmIERlcmVrDQoNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQotLQ0KW1BpbmcgSWRlbnRp dHkgbG9nb108aHR0cHM6Ly93d3cucGluZ2lkZW50aXR5LmNvbS8+DQoNCkJyaWFuIENhbXBiZWxs DQpQb3J0Zm9saW8gQXJjaGl0ZWN0DQpADQoNCmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1h aWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4NCg0KW3Bob25lXQ0KDQorMSA3MjAuMzE3 LjIwNjENCg0KQ29ubmVjdCB3aXRoIHVz4oCmDQoNClt0d2l0dGVyIGxvZ29dPGh0dHBzOi8vdHdp dHRlci5jb20vcGluZ2lkZW50aXR5Plt5b3V0dWJlIGxvZ29dPGh0dHBzOi8vd3d3LnlvdXR1YmUu Y29tL3VzZXIvUGluZ0lkZW50aXR5VFY+W0xpbmtlZEluIGxvZ29dPGh0dHBzOi8vd3d3Lmxpbmtl ZGluLmNvbS9jb21wYW55LzIxODcwPltGYWNlYm9vayBsb2dvXTxodHRwczovL3d3dy5mYWNlYm9v ay5jb20vcGluZ2lkZW50aXR5cGFnZT5bR29vZ2xlKyBsb2dvXTxodHRwczovL3BsdXMuZ29vZ2xl LmNvbS91LzAvMTE0MjY2OTc3NzM5Mzk3NzA4NTQwPltzbGlkZXNoYXJlIGxvZ29dPGh0dHA6Ly93 d3cuc2xpZGVzaGFyZS5uZXQvUGluZ0lkZW50aXR5PltmbGlwYm9hcmQgbG9nb108aHR0cDovL2Zs aXAuaXQvdmpCRjc+W3JzcyBmZWVkIGljb25dPGh0dHBzOi8vd3d3LnBpbmdpZGVudGl0eS5jb20v YmxvZ3MvPg0KDQoNCltSZWdpc3RlciBmb3IgQ2xvdWQgSWRlbnRpdHkgU3VtbWl0IDIwMTQgfCBN b2Rlcm4gSWRlbnRpdHkgUmV2b2x1dGlvbiB8IDE54oCTMjMgSnVseSwgMjAxNCB8IE1vbnRlcmV5 LCBDQV08aHR0cHM6Ly93d3cuY2xvdWRpZGVudGl0eXN1bW1pdC5jb20vPg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_a004992672a54c32a2237112dab67050BLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIHdp dGggUGhpbCBvbiB0aGlzIG9uZSwgdGhlcmUgYXJlIGltcGxlbWVudGF0aW9ucyBvZiB0aGlzIGFs cmVhZHkgYW5kIG11Y2ggaW50ZXJlc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+UGhpbCBIdW50PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2Rh eSwgTWF5IDE0LCAyMDE0IDg6MzIgQU08YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIENhbXBiZWxsPGJy Pg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09B VVRILVdHXSBPQXV0aCBNaWxlc3RvbmUgVXBkYXRlIGFuZCBSZWNoYXJ0ZXJpbmc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gdGhlIGNvbnRy YXJ5LiBJIGFuZCBvdGhlcnMgYXJlIGludGVyZXN0ZWQuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFyZSB3YWl0aW5nIGZvciB0 aGUgY2hhcnRlciB0byBwaWNrIHVwIHRoZSB3b3JrLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRsZXNzIHRoZXJlIHdpbGwg YmUgYSBuZXcgZHJhZnQgc2hvcnRseS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KT24gTWF5IDE0LCAyMDE0LCBhdCA1OjI0LCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj5iY2FtcGJlbGxAcGluZ2lk ZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5JIHdvdWxkIG9iamVjdCB0byAnT0F1dGggQXV0aGVudGljYXRpb24nIGJlaW5nIHBpY2tlZCB1 cCBieSB0aGUgV0cgYXMgYSB3b3JrIGl0ZW0uIFRoZSBzdGFydGluZyBwb2ludCBkcmFmdCBoYXMg ZXhwaXJlZCBhbmQgaXQgaGFzbid0IHJlYWxseSBiZWVuIGRpc2N1c3NlcyBzaW5jZSBCZXJsaW4g bmVhcmx5IGEgeWVhciBhZ28uJm5ic3A7IEFzIEkgcmVjYWxsLCB0aGVyZQ0KIHdhcyBvbmx5IHZl cnkgbGltaXRlZCBpbnRlcmVzdCBpbiBpdCBldmVuIHRoZW4uIEkgYWxzbyBkb24ndCBiZWxpZXZl IGl0IGZpdHMgd2VsbCB3aXRoIHRoZSBXRyBjaGFydGVyLjxicj4NCjxicj4NCkkgd291bGQgc3Vn Z2VzdCB0aGUgV0cgY29uc2lkZXIgcGlja2luZyB1cCAnT0F1dGggU3ltbWV0cmljIFByb29mIG9m IFBvc3Nlc3Npb24gZm9yIENvZGUgRXh0ZW5zaW9uJyBmb3Igd2hpY2ggdGhlcmUgaXMgYW4gZXhj ZWxsZW50IHN0YXJ0aW5nIHBvaW50IG9mDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC10Y3NlLTAzIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC10Y3NlLTAzPC9hPiAt IGl0J3MgYSByZWxhdGl2aXR5IHNpbXBsZSBzZWN1cml0eSBlbmhhbmNlbWVudCB3aGljaCBhZGRy ZXNzZXMgcHJvYmxlbXMgY3VycmVudGx5IGJlaW5nIGVuY291bnRlcmVkIGluIGRlcGxveW1lbnRz IG9mIG5hdGl2ZSBjbGllbnRzLiZuYnNwOw0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFRodSwgTWF5IDgsIDIwMTQgYXQgMzowNCBQTSwgSGFubmVzIFRzY2hvZmVuaWcgJmx0Ozxh IGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0IiB0YXJnZXQ9Il9ibGFuayI+ aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+SGkgYWxsLDxicj4NCjxicj4NCnlvdSBtaWdodCBoYXZlIHNlZW4gdGhhdCB3ZSBwdXNo ZWQgdGhlIGFzc2VydGlvbiBkb2N1bWVudHMgYW5kIHRoZSBKV1Q8YnI+DQpkb2N1bWVudHMgdG8g dGhlIElFU0cgdG9kYXkuIFdlIGhhdmUgYWxzbyB1cGRhdGVkIHRoZSBtaWxlc3RvbmVzIG9uIHRo ZTxicj4NCk9BdXRoIFdHIHBhZ2UuPGJyPg0KPGJyPg0KVGhpcyBtZWFucyB0aGF0IHdlIGNhbiBw bGFuIHRvIHBpY2sgdXAgbmV3IHdvcmsgaW4gdGhlIGdyb3VwLjxicj4NCldlIGhhdmUgc2VudCBh IHJlcXVlc3QgdG8gS2F0aGxlZW4gdG8gY2hhbmdlIHRoZSBtaWxlc3RvbmUgZm9yIHRoZSBPQXV0 aDxicj4NCnNlY3VyaXR5IG1lY2hhbmlzbXMgdG8gdXNlIHRoZSBwcm9vZi1vZi1wb3NzZXNzaW9u IHRlcm1pbm9sb2d5Ljxicj4NCjxicj4NCldlIGFsc28gZXhwZWN0IGFuIHVwZGF0ZWQgdmVyc2lv biBvZiB0aGUgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uPGJyPg0Kc3BlYyBpbmNvcnBvcmF0 aW5nIGxhc3QgY2FsbCBmZWVkYmFjayB3aXRoaW4gYWJvdXQgMiB3ZWVrcy48YnI+DQo8YnI+DQpX ZSB3b3VsZCBsaWtlIHlvdSB0byB0aGluayBhYm91dCBhZGRpbmcgdGhlIGZvbGxvd2luZyBtaWxl c3RvbmVzIHRvIHRoZTxicj4NCmNoYXJ0ZXIgYXMgcGFydCBvZiB0aGUgcmUtY2hhcnRlcmluZyBl ZmZvcnQ6PGJyPg0KPGJyPg0KLS0tLS08YnI+DQo8YnI+DQpOb3YgMjAxNCBTdWJtaXQgJ1Rva2Vu IGludHJvc3BlY3Rpb24nIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzIGE8YnI+DQpQ cm9wb3NlZCBTdGFuZGFyZDxicj4NClN0YXJ0aW5nIHBvaW50OiAmbHQ7ZHJhZnQtcmljaGVyLW9h dXRoLWludHJvc3BlY3Rpb24tMDQmZ3Q7PGJyPg0KPGJyPg0KSmFuIDIwMTUgU3VibWl0ICdPQXV0 aCBBdXRoZW50aWNhdGlvbicgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXM8YnI+DQph IFByb3Bvc2VkIFN0YW5kYXJkPGJyPg0KU3RhcnRpbmcgcG9pbnQ6ICZsdDtkcmFmdC1odW50LW9h dXRoLXYyLXVzZXItYTRjLTAxJmd0Ozxicj4NCjxicj4NCkphbiAyMDE1IFN1Ym1pdCAnVG9rZW4g RXhjaGFuZ2UnIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzIGE8YnI+DQpQcm9wb3Nl ZCBTdGFuZGFyZDxicj4NClN0YXJ0aW5nIHBvaW50OiAmbHQ7ZHJhZnQtam9uZXMtb2F1dGgtdG9r ZW4tZXhjaGFuZ2UtMDAmZ3Q7PGJyPg0KPGJyPg0KLS0tLS08YnI+DQo8YnI+DQpXZSBhbHNvIHVw ZGF0ZWQgdGhlIGNoYXJ0ZXIgdGV4dCB0byByZWZsZWN0IHRoZSBjdXJyZW50IHNpdHVhdGlvbi4g SGVyZTxicj4NCmlzIHRoZSBwcm9wb3NlZCB0ZXh0Ojxicj4NCjxicj4NCi0tLS0tPGJyPg0KPGJy Pg0KQ2hhcnRlciBmb3IgV29ya2luZyBHcm91cDxicj4NCjxicj4NCjxicj4NClRoZSBXZWIgQXV0 aG9yaXphdGlvbiAoT0F1dGgpIHByb3RvY29sIGFsbG93cyBhIHVzZXIgdG8gZ3JhbnQgYTxicj4N CnRoaXJkLXBhcnR5IFdlYiBzaXRlIG9yIGFwcGxpY2F0aW9uIGFjY2VzcyB0byB0aGUgdXNlcidz IHByb3RlY3RlZDxicj4NCnJlc291cmNlcywgd2l0aG91dCBuZWNlc3NhcmlseSByZXZlYWxpbmcg dGhlaXIgbG9uZy10ZXJtIGNyZWRlbnRpYWxzLDxicj4NCm9yIGV2ZW4gdGhlaXIgaWRlbnRpdHku IEZvciBleGFtcGxlLCBhIHBob3RvLXNoYXJpbmcgc2l0ZSB0aGF0PGJyPg0Kc3VwcG9ydHMgT0F1 dGggY291bGQgYWxsb3cgaXRzIHVzZXJzIHRvIHVzZSBhIHRoaXJkLXBhcnR5IHByaW50aW5nIFdl Yjxicj4NCnNpdGUgdG8gcHJpbnQgdGhlaXIgcHJpdmF0ZSBwaWN0dXJlcywgd2l0aG91dCBhbGxv d2luZyB0aGUgcHJpbnRpbmc8YnI+DQpzaXRlIHRvIGdhaW4gZnVsbCBjb250cm9sIG9mIHRoZSB1 c2VyJ3MgYWNjb3VudCBhbmQgd2l0aG91dCBoYXZpbmcgdGhlPGJyPg0KdXNlciBzaGFyZSBoaXMg b3IgaGVyIHBob3RvLXNoYXJpbmcgc2l0ZXMnIGxvbmctdGVybSBjcmVkZW50aWFsIHdpdGg8YnI+ DQp0aGUgcHJpbnRpbmcgc2l0ZS48YnI+DQo8YnI+DQpUaGUgT0F1dGggMi4wIHByb3RvY29sIHN1 aXRlIGVuY29tcGFzc2VzPGJyPg0KPGJyPg0KKiBhIHByb3RvY29sIGZvciBvYnRhaW5pbmcgYWNj ZXNzIHRva2VucyBmcm9tIGFuIGF1dGhvcml6YXRpb248YnI+DQpzZXJ2ZXIgd2l0aCB0aGUgcmVz b3VyY2Ugb3duZXIncyBjb25zZW50LDxicj4NCiogcHJvdG9jb2xzIGZvciBwcmVzZW50aW5nIHRo ZXNlIGFjY2VzcyB0b2tlbnMgdG8gcmVzb3VyY2Ugc2VydmVyPGJyPg0KZm9yIGFjY2VzcyB0byBh IHByb3RlY3RlZCByZXNvdXJjZSw8YnI+DQoqIGd1aWRhbmNlIGZvciBzZWN1cmVseSB1c2luZyBP QXV0aCAyLjAsPGJyPg0KKiB0aGUgYWJpbGl0eSB0byByZXZva2UgYWNjZXNzIHRva2Vucyw8YnI+ DQoqIHN0YW5kYXJkaXplZCBmb3JtYXQgZm9yIHNlY3VyaXR5IHRva2VucyBlbmNvZGVkIGluIGEg SlNPTiBmb3JtYXQ8YnI+DQombmJzcDsgKEpTT04gV2ViIFRva2VuLCBKV1QpLDxicj4NCiogd2F5 cyBvZiB1c2luZyBhc3NlcnRpb25zIHdpdGggT0F1dGgsIGFuZDxicj4NCiogYSBkeW5hbWljIGNs aWVudCByZWdpc3RyYXRpb24gcHJvdG9jb2wuPGJyPg0KPGJyPg0KVGhlIHdvcmtpbmcgZ3JvdXAg YWxzbyBkZXZlbG9wZWQgc2VjdXJpdHkgc2NoZW1lcyBmb3IgcHJlc2VudGluZzxicj4NCmF1dGhv cml6YXRpb24gdG9rZW5zIHRvIGFjY2VzcyBhIHByb3RlY3RlZCByZXNvdXJjZS4gVGhpcyBsZWQg dG8gdGhlPGJyPg0KcHVibGljYXRpb24gb2YgdGhlIGJlYXJlciB0b2tlbiwgYXMgd2VsbCBhcyB3 b3JrIHRoYXQgcmVtYWlucyB0byBiZTxicj4NCmNvbXBsZXRlZCBvbiBwcm9vZi1vZi1wb3NzZXNz aW9uIGFuZCB0b2tlbiBleGNoYW5nZS48YnI+DQo8YnI+DQpUaGUgb25nb2luZyBzdGFuZGFyZGl6 YXRpb24gZWZmb3J0IHdpdGhpbiB0aGUgT0F1dGggd29ya2luZyBncm91cCB3aWxsPGJyPg0KZm9j dXMgb24gZW5oYW5jaW5nIGludGVyb3BlcmFiaWxpdHkgYW5kIGZ1bmN0aW9uYWxpdHkgb2YgT0F1 dGg8YnI+DQpkZXBsb3ltZW50cywgc3VjaCBhcyBhIHN0YW5kYXJkIGZvciBhIHRva2VuIGludHJv c3BlY3Rpb24gc2VydmljZSBhbmQ8YnI+DQpzdGFuZGFyZHMgZm9yIGFkZGl0aW9uYWwgc2VjdXJp dHkgb2YgT0F1dGggcmVxdWVzdHMuPGJyPg0KPGJyPg0KLS0tLS08YnI+DQo8YnI+DQpGZWVkYmFj ayBhcHByZWNpYXRlZC48YnI+DQo8YnI+DQpDaWFvPGJyPg0KSGFubmVzICZhbXA7IERlcmVrPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIg Y2xlYXI9ImFsbCI+DQo8YnI+DQotLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHRh YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8 dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDo1OS4yNXB0Ij4NCjx0ZCB3aWR0aD0iNzUiIHZhbGln bj0idG9wIiBzdHlsZT0id2lkdGg6NTYuMjVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43 NXB0O2hlaWdodDo1OS4yNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LnBpbmdpZGVudGl0eS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRl eHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyNSIgc3Jj PSJodHRwOi8vNC5waW5naWRlbnRpdHkuY29tL3JzL3BpbmdpZGVudGl0eS9pbWFnZXMvRVhQX1BJ Q19zcXVhcmVfbG9nb19SR0Jfd2l0aF9oYXJkX2Ryb3AucG5nIiBhbHQ9IlBpbmcgSWRlbnRpdHkg bG9nbyI+PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3Ai IHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IDcuNXB0O2hlaWdodDo1OS4yNXB0Ij4N CjxkaXYgc3R5bGU9Im1hcmdpbi1ib3R0b206NS4yNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0U2MUQzQyI+QnJpYW4gQ2FtcGJl bGw8L3NwYW4+PC9iPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PlBvcnRmb2xpbyBBcmNoaXRlY3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRi b2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItcmlnaHQ6c29saWQgI0U2 MUQzQyAxLjBwdDtwYWRkaW5nOjBpbiAzLjc1cHQgMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0U2MUQzQyI+QDwvc3Bhbj48L2I+PG86cD48L286cD48 L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDIuMjVwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5r Ij5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXJpZ2h0OnNv bGlkICNFNjNDMUQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48aW1nIGJv cmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyNiIgc3JjPSJodHRwOi8vNC5waW5naWRlbnRpdHkuY29t L3JzL3BpbmdpZGVudGl0eS9pbWFnZXMvRVhQX3Bob25lX2dseXBoLmdpZiIgYWx0PSJwaG9uZSI+ PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDIu MjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj4mIzQzOzEgNzIwLjMxNy4yMDYxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90 ZD4NCjwvdHI+DQo8dHI+DQo8dGQgY29sc3Bhbj0iMiIgc3R5bGU9InBhZGRpbmc6MTEuMjVwdCAu NzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiM5OTk5OTkiPkNvbm5lY3Qgd2l0aCB1c+KApjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIGNvbHNwYW49IjIiIHN0eWxlPSJwYWRk aW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhy ZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vcGluZ2lkZW50aXR5IiB0YXJnZXQ9Il9ibGFuayIgdGl0 bGU9IlBpbmcgb24gVHdpdHRlciI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj48 aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyNyIgc3JjPSJodHRwOi8vNC5waW5naWRlbnRp dHkuY29tL3JzL3BpbmdpZGVudGl0eS9pbWFnZXMvdHdpdHRlci5naWYiIGFsdD0idHdpdHRlciBs b2dvIj48L3NwYW4+PC9hPjxhIGhyZWY9Imh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3VzZXIvUGlu Z0lkZW50aXR5VFYiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUGluZyBvbiBZb3VUdWJlIj48c3Bh biBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAw X2kxMDI4IiBzcmM9Imh0dHA6Ly80LnBpbmdpZGVudGl0eS5jb20vcnMvcGluZ2lkZW50aXR5L2lt YWdlcy95b3V0dWJlLmdpZiIgYWx0PSJ5b3V0dWJlIGxvZ28iPjwvc3Bhbj48L2E+PGEgaHJlZj0i aHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2NvbXBhbnkvMjE4NzAiIHRhcmdldD0iX2JsYW5rIiB0 aXRsZT0iUGluZyBvbiBMaW5rZWRJbiI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25l Ij48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyOSIgc3JjPSJodHRwOi8vNC5waW5naWRl bnRpdHkuY29tL3JzL3BpbmdpZGVudGl0eS9pbWFnZXMvbGlua2VkaW4uZ2lmIiBhbHQ9Ikxpbmtl ZEluIGxvZ28iPjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL3Bp bmdpZGVudGl0eXBhZ2UiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUGluZyBvbiBGYWNlYm9vayI+ PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94 MDAwMF9pMTAzMCIgc3JjPSJodHRwOi8vNC5waW5naWRlbnRpdHkuY29tL3JzL3BpbmdpZGVudGl0 eS9pbWFnZXMvZmFjZWJvb2suZ2lmIiBhbHQ9IkZhY2Vib29rIGxvZ28iPjwvc3Bhbj48L2E+PGEg aHJlZj0iaHR0cHM6Ly9wbHVzLmdvb2dsZS5jb20vdS8wLzExNDI2Njk3NzczOTM5NzcwODU0MCIg dGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSJQaW5nIG9uIEdvb2dsZSYjNDM7Ij48c3BhbiBzdHlsZT0i dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDMxIiBz cmM9Imh0dHA6Ly80LnBpbmdpZGVudGl0eS5jb20vcnMvcGluZ2lkZW50aXR5L2ltYWdlcy9nb29n bGUlMkIuZ2lmIiBhbHQ9Ikdvb2dsZSYjNDM7IGxvZ28iPjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0 cDovL3d3dy5zbGlkZXNoYXJlLm5ldC9QaW5nSWRlbnRpdHkiIHRhcmdldD0iX2JsYW5rIiB0aXRs ZT0iUGluZyBvbiBTbGlkZVNoYXJlIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUi PjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDMyIiBzcmM9Imh0dHA6Ly80LnBpbmdpZGVu dGl0eS5jb20vcnMvcGluZ2lkZW50aXR5L2ltYWdlcy9zbGlkZXNoYXJlLmdpZiIgYWx0PSJzbGlk ZXNoYXJlIGxvZ28iPjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cDovL2ZsaXAuaXQvdmpCRjciIHRh cmdldD0iX2JsYW5rIiB0aXRsZT0iUGluZyBvbiBGbGlwYm9hcmQiPjxzcGFuIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIGlkPSJfeDAwMDBfaTEwMzMiIHNyYz0i aHR0cDovLzQucGluZ2lkZW50aXR5LmNvbS9ycy9waW5naWRlbnRpdHkvaW1hZ2VzL2ZsaXBib2Fy ZC5naWYiIGFsdD0iZmxpcGJvYXJkIGxvZ28iPjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cHM6Ly93 d3cucGluZ2lkZW50aXR5LmNvbS9ibG9ncy8iIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUGluZyBi bG9ncyI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIg aWQ9Il94MDAwMF9pMTAzNCIgc3JjPSJodHRwOi8vNC5waW5naWRlbnRpdHkuY29tL3JzL3Bpbmdp ZGVudGl0eS9pbWFnZXMvcnNzLmdpZiIgYWx0PSJyc3MgZmVlZCBpY29uIj48L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8 L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFs VGFibGUiIGJvcmRlcj0iMSIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0i MzE1IiBzdHlsZT0id2lkdGg6MjM2LjI1cHQ7Ym9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlO2JvcmRl cjpub25lIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjYwLjc1cHQiPg0KPHRkIHdpZHRo PSIxNzIiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTI5LjBwdDtib3JkZXI6bm9uZTtwYWRk aW5nOjExLjI1cHQgMTEuMjVwdCAwaW4gMTEuMjVwdDtoZWlnaHQ6NjAuNzVwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3d3dy5jbG91ZGlkZW50aXR5c3VtbWl0LmNv bS8iIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUmVnaXN0ZXIgZm9yIENsb3VkIElkZW50aXR5IFN1 bW1pdCAyMDE0IHwgTW9kZXJuIElkZW50aXR5IFJldm9sdXRpb24gfCAxOeKAkzIzIEp1bHksIDIw MTQgfCBNb250ZXJleSwgQ0EiPjxzcGFuIHN0eWxlPSJjb2xvcjojQ0NDQ0NDO3RleHQtZGVjb3Jh dGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAzNSIgc3JjPSJodHRwOi8v NC5waW5naWRlbnRpdHkuY29tL3JzL3BpbmdpZGVudGl0eS9pbWFnZXMvRVhQX0NJU18yMDE0Lmdp ZiIgYWx0PSJSZWdpc3RlciBmb3IgQ2xvdWQgSWRlbnRpdHkgU3VtbWl0IDIwMTQgfCBNb2Rlcm4g SWRlbnRpdHkgUmV2b2x1dGlvbiB8IDE54oCTMjMgSnVseSwgMjAxNCB8IE1vbnRlcmV5LCBDQSI+ PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFi bGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5P QXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_a004992672a54c32a2237112dab67050BLUPR03MB309namprd03pro_-- From nobody Wed May 14 09:03:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087D41A00FE for ; Wed, 14 May 2014 09:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 adUYlBToN_F7 for ; Wed, 14 May 2014 09:03:10 -0700 (PDT) Received: from nm14-vm0.bullet.mail.bf1.yahoo.com (nm14-vm0.bullet.mail.bf1.yahoo.com [98.139.213.164]) by ietfa.amsl.com (Postfix) with ESMTP id 91C5E1A00E5 for ; Wed, 14 May 2014 09:03:10 -0700 (PDT) Received: from [98.139.212.152] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 14 May 2014 16:03:03 -0000 Received: from [98.139.212.237] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 14 May 2014 16:03:03 -0000 Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 14 May 2014 16:03:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 568327.58938.bm@omp1046.mail.bf1.yahoo.com Received: (qmail 41490 invoked by uid 60001); 14 May 2014 16:03:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1400083383; bh=XVIz2yHoMInDgIYQFz8iXQ/O1N/H4mp1thSJQkOAYY4=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=eMp2eFUG/ynbrbPQ5oDNtg3fFpln6bMFoGyxJmcJB6XIjp296klTaCGAdVgRuSOZn77RhCvHBuTC40o9IQNvaSRdo/W7O/YtTf+td1DNihXjTK9LONO5AibjZ3kgDvzOGj9mm4bEfnvxkfRe9Dl9XE+ElP2BDiAtCAvHEIIh7Pc= X-YMail-OSG: yhogDzUVM1k2XrqoZrWFZUdMFN1rwMuiMAK2TBqyGvw6GYm pAf8U0PiZoxAA_zsR6Ja4kx77oL6qSA1W9TkcizSm8wwj8rxeIH1xnYLtiBv wg2K1jDjDiA0SXOp0OwPeXZdv3TfLuGE3iykoxUn4lRElZtUxizKZzuJ0krV JU8iRm.RfP70JvXRs1jbuI6hqXnCgLg5OHumPlPQOUcM4hWIdXftW14Im7q_ v0QlmhOYRNgIawpXB9Ag7SM9b_G81WVKhgegOkD4G6rEdt98FlU06f_aBB2b CY7zC1gDc0q4x9t.SG1ldRUSmXPyQiZXIdgPsUHdcX8oh9IEqgTw0yHbRi9L jBslFpJbYhk7HQ34adf_Z2lF4_2Y4wQGTolRE76YJxUZXBdaL5Sidae6lzmX eg1PIGnTH2lRjWmwN93l_4pjh10nVzX_XGG7PkWynJ9vTCGCGJCt9OjPec64 aLSXdVVf63QARSv5gjY4_6qwnU_hBt3SHUPKljMyparsYmg5ykxNzinfm.oO mN1FT5Um7Mfr5_AS9jklRUNQSpEl0uCAKeGumuuIKShXl10YVarWdlZeS90J YKHVM8bQ3m3dMB8s3aKINtI9DSshCWd0E6ZPfVitxJrG0HqdYo1O2_ablhBQ .tec1fSYifrFvL.zdar_2vURQQFevHiSHiFpHScijSBpqe_UWqe2NSJKXiD. PBPIbOy2LxTB53RcfICMHRy1j_p192.lsG76P6SbG.n0yK.1S.8l559v_Xqr 1HJKCExNOgpsik15eSYeHekRUnZHIxgYAPwqcyXVTi_NZaJDt5ds5ojap.MM 6G.i6hs_OPS6B2AlOI28dqxPARYb5_7V9b8igivcnG_nYcKKTa2A41YGU.Tj rRREN1tgGWwfZUpdIUtr0sH0_j1IBaqEfD0q9aMr.kaH1LyJrfwVaaFLAwcZ c9ywXPF4m8MObtOZ8P3tHWKgjgfq3ru4V3moOzCTZ4an8T0VLaI6GGtthgm. vAVGj_9uQ6bBgBhvKTo6C2aWBNdTjZaI28nSprLKDiD9TqXpEM9YjLXlJ20A BT6DKlEUPQbD8StSYwn5t7CF9KlgZpywlL.C4cOcOpVPxgz1MZ_KTiA2pEBS uPOAsKz4JKGNH6Y1Cvqne2S_eSgUPyK3x1tOYEM3KGYv74tPR7VI2pF.9etb CEDSEliWO3VrSiKfGM_uJBmRsC9ESlw0lhreCVgy9kAsvtVmLlXmI8ioYCC1 xcD0- Received: from [98.139.248.67] by web142802.mail.bf1.yahoo.com via HTTP; Wed, 14 May 2014 09:03:03 PDT X-Rocket-MIMEInfo: 002.001, SSB0aGluayB0aGVyZSdzIGEgdXNlIGNhc2UgZm9yIHRoaXMgd29yayB0aGF0IG1heSBvciBtYXkgbm90IGJlIGNvdmVyZWQgYnkgdGhlIFBvUCBzcGVjLCBhbmQgaW4gZmFjdCBJIHRoaW5rIHRoaXMgd29yayBpcyByZWxhdGVkIHRvIHRoYXQuIMKgVGhlIE1BQyB0b2tlbiB3b3JrIGlzIHJlYWxseSBvbmUgdXNlIGNhc2Ugb2YgUE9QIHRva2Vucy4gwqBSYXRoZXIgdGhhbiBzaG91dGluZyBpdCBkb3duIGxldCdzIGZpZ3VyZSBvdXQgaG93IHRvIHNvbHZlIHRoaXMgdXNlIGNhc2UuCgoKT24gV2VkbmVzZGF5LCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <536BF140.5070106@gmx.net> <84B60891-F9E1-4183-9031-8BED6315C70F@mit.edu> Message-ID: <1400083383.78490.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Wed, 14 May 2014 09:03:03 -0700 (PDT) From: Bill Mills To: Justin Richer , Brian Campbell In-Reply-To: <84B60891-F9E1-4183-9031-8BED6315C70F@mit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1397251415-228175191-1400083383=:78490" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YSlJEBvsoVxWWW9kFJuYy9J6C24 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 16:03:13 -0000 --1397251415-228175191-1400083383=:78490 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think there's a use case for this work that may or may not be covered by = the PoP spec, and in fact I think this work is related to that. =C2=A0The M= AC token work is really one use case of POP tokens. =C2=A0Rather than shout= ing it down let's figure out how to solve this use case.=0A=0A=0AOn Wednesd= ay, May 14, 2014 8:39 AM, Justin Richer wrote:=0A =0AI ag= ree with Brian and object to the Authentication work item. I think there=E2= =80=99s limited interest and utility in such a draft, especially now that O= penID Connect has been published and its core authentication capabilities a= re identical to what was called for in the other draft a year ago (a simila= rity, I=E2=80=99ll add, which was noted at the time).=C2=A0=0A=0A=C2=A0=E2= =80=94 Justin=0A=0A=0A=0AOn May 14, 2014, at 8:24 AM, Brian Campbell wrote:=0A=0AI would object to 'OAuth Authentication'= being picked up by the WG as a work item. The starting point draft has exp= ired and it hasn't really been discusses since Berlin nearly a year ago.=C2= =A0 As I recall, there was only very limited interest in it even then. I al= so don't believe it fits well with the WG charter.=0A=0AI would suggest the= WG consider picking up 'OAuth Symmetric Proof of=0A Possession for Code Ex= tension' for which there is an excellent starting=0A point of http://tools.= ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple secur= ity enhancement which addresses problems currently being encountered in dep= loyments of native clients.=C2=A0 =0A=0A=0A=0A=0A=0A=0AOn Thu, May 8, 2014 = at 3:04 PM, Hannes Tschofenig wrote:=0A=0AHi al= l,=0A>=0A>you might have seen that we pushed the assertion documents and th= e JWT=0A>documents to the IESG today. We have also updated the milestones o= n the=0A>OAuth WG page.=0A>=0A>This means that we can plan to pick up new w= ork in the group.=0A>We have sent a request to Kathleen to change the miles= tone for the OAuth=0A>security mechanisms to use the proof-of-possession te= rminology.=0A>=0A>We also expect an updated version of the dynamic client r= egistration=0A>spec incorporating last call feedback within about 2 weeks.= =0A>=0A>We would like you to think about adding the following milestones to= the=0A>charter as part of the re-chartering effort:=0A>=0A>-----=0A>=0A>No= v 2014 Submit 'Token introspection' to the IESG for consideration as a=0A>P= roposed Standard=0A>Starting point: = =0A>=0A>Jan 2015 Submit 'OAuth Authentication' to the IESG for consideratio= n as=0A>a Proposed Standard=0A>Starting point: =0A>=0A>Jan 2015 Submit 'Token Exchange' to the IESG for consideration= as a=0A>Proposed Standard=0A>Starting point: =0A>=0A>-----=0A>=0A>We also updated the charter text to reflect th= e current situation. Here=0A>is the proposed text:=0A>=0A>-----=0A>=0A>Char= ter for Working Group=0A>=0A>=0A>The Web Authorization (OAuth) protocol all= ows a user to grant a=0A>third-party Web site or application access to the = user's protected=0A>resources, without necessarily revealing their long-ter= m credentials,=0A>or even their identity. For example, a photo-sharing site= that=0A>supports OAuth could allow its users to use a third-party printing= Web=0A>site to print their private pictures, without allowing the printing= =0A>site to gain full control of the user's account and without having the= =0A>user share his or her photo-sharing sites' long-term credential with=0A= >the printing site.=0A>=0A>The OAuth 2.0 protocol suite encompasses=0A>=0A>= * a protocol for obtaining access tokens from an authorization=0A>server wi= th the resource owner's consent,=0A>* protocols for presenting these access= tokens to resource server=0A>for access to a protected resource,=0A>* guid= ance for securely using OAuth 2.0,=0A>* the ability to revoke access tokens= ,=0A>* standardized format for security tokens encoded in a JSON format=0A>= =C2=A0 (JSON Web Token, JWT),=0A>* ways of using assertions with OAuth, and= =0A>* a dynamic client registration protocol.=0A>=0A>The working group also= developed security schemes for presenting=0A>authorization tokens to acces= s a protected resource. This led to the=0A>publication of the bearer token,= as well as work that remains to be=0A>completed on proof-of-possession and= token exchange.=0A>=0A>The ongoing standardization effort within the OAuth= working group will=0A>focus on enhancing interoperability and functionalit= y of OAuth=0A>deployments, such as a standard for a token introspection ser= vice and=0A>standards for additional security of OAuth requests.=0A>=0A>---= --=0A>=0A>Feedback appreciated.=0A>=0A>Ciao=0A>Hannes & Derek=0A>=0A>=0A>= =0A>_______________________________________________=0A>OAuth mailing list= =0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>= =0A=0A=0A-- =0A=0A Brian Campbell=0APortfolio Architect=0A@ bcampbell@pingi= dentity.com =0A +1 720.317.2061 =0AConnect with us=E2=80=A6 =0A= =0A_______________________________________________=0AOAuth mailing list=0AO= Auth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A=0A=0A=0A____= ___________________________________________=0AOAuth mailing list=0AOAuth@ie= tf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --1397251415-228175191-1400083383=:78490 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think there's a use case for this work that may = or may not be covered by the PoP spec, and in fact I think this work is rel= ated to that.  The MAC token work is really one use case of POP tokens= .  Rather than shouting it down let's figure out how to solve this use= case.

<= div dir=3D"ltr"> On Wednesday, May 14, 201= 4 8:39 AM, Justin Richer <jricher@MIT.EDU> wrote:
=
I agree with Bria= n and object to the Authentication work item. I think there=E2=80=99s limit= ed interest and utility in such a draft, especially now that OpenID Connect= has been published and its core authentication capabilities are identical = to what was called for in the other draft a year ago (a similarity, I=E2=80= =99ll add, which was noted at the time). 

 =E2=80=94 Justin

<= div>On May 14, 2014, at 8:24 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

<= div dir=3D"ltr">I would object to 'OAuth Authentication' being picked up by= the WG as a work item. The starting point draft has expired and it hasn't = really been discusses since Berlin nearly a year ago.  As I recall, th= ere was only very limited interest in it even then. I also don't believe it= fits well with the WG charter.
=0A=0A=0A
I would suggest the WG consider picking up 'OAuth Symmetric Proof of=0A = Possession for Code Extension' for which there is an excellent starting=0A = point of http://tools.ietf.org/h= tml/draft-sakimura-oauth-tcse-03 - it's a relativity simple security en= hancement which addresses problems currently being encountered in deploymen= ts of native clients. 
=0A=0A=0A
=


On Thu= , May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@g= mx.net> wrote:
=0A=0A
Hi all,
=0A
=0Ay= ou might have seen that we pushed the assertion documents and the JWT
=0Adocuments to the IESG today. We have also updated the miles= tones on the
=0AOAuth WG page.
=0A
=0AThis means that we can plan to pick up new work in the gro= up.
=0AWe have sent a request to Kathleen to change the m= ilestone for the OAuth
=0Asecurity mechanisms to use the = proof-of-possession terminology.
=0A
= =0AWe also expect an updated version of the dynamic client registration
=0Aspec incorporating last call feedback within about 2 week= s.
=0A
=0AWe would like you to think ab= out adding the following milestones to the
=0Acharter as = part of the re-chartering effort:
=0A
= =0A-----
=0A
=0ANov 2014 Submit 'Token = introspection' to the IESG for consideration as a
=0AProp= osed Standard
=0AStarting point: <draft-richer-oauth-i= ntrospection-04>
=0A
=0AJan 2015 Sub= mit 'OAuth Authentication' to the IESG for consideration as
=0Aa Proposed Standard
=0AStarting point: <draft-hu= nt-oauth-v2-user-a4c-01>
=0A
=0AJan = 2015 Submit 'Token Exchange' to the IESG for consideration as a
=0AProposed Standard
=0AStarting point: <draft-= jones-oauth-token-exchange-00>
=0A
= =0A-----
=0A
=0AWe also updated the cha= rter text to reflect the current situation. Here
=0Ais th= e proposed text:
=0A
=0A-----
=0A
=0ACharter for Working Group
=0A
=0A
=0AThe Web Authorization (O= Auth) protocol allows a user to grant a
=0Athird-party We= b site or application access to the user's protected
=0Ar= esources, without necessarily revealing their long-term credentials,
=0Aor even their identity. For example, a photo-sharing site th= at
=0Asupports OAuth could allow its users to use a third= -party printing Web
=0Asite to print their private pictur= es, without allowing the printing
=0Asite to gain full co= ntrol of the user's account and without having the
=0Ause= r share his or her photo-sharing sites' long-term credential with
=0Athe printing site.
=0A
=0A= The OAuth 2.0 protocol suite encompasses
=0A
=0A* a protocol for obtaining access tokens from an authorization
=0Aserver with the resource owner's consent,
=0A* protocols for presenting these access tokens to resource server
=0Afor access to a protected resource,
=0A= * guidance for securely using OAuth 2.0,
=0A* the ability= to revoke access tokens,
=0A* standardized format for se= curity tokens encoded in a JSON format
=0A  (JSON We= b Token, JWT),
=0A* ways of using assertions with OAuth, = and
=0A* a dynamic client registration protocol.
=0A
=0AThe working group also developed securit= y schemes for presenting
=0Aauthorization tokens to acces= s a protected resource. This led to the
=0Apublication of= the bearer token, as well as work that remains to be
=0A= completed on proof-of-possession and token exchange.
=0A<= br clear=3D"none">=0AThe ongoing standardization effort within the OAuth wo= rking group will
=0Afocus on enhancing interoperability a= nd functionality of OAuth
=0Adeployments, such as a stand= ard for a token introspection service and
=0Astandards fo= r additional security of OAuth requests.
=0A
=0A-----
=0A
=0AFeedback apprecia= ted.
=0A
=0ACiao
=0AH= annes & Derek
=0A
=0A
=0A
_______________________________________________<= br clear=3D"none">=0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A



--
=0A=0A
=0A=09
=0A=09=09=09=09=093D"Ping=0A=09=09=09=09=09=0A=09=09=09=09=09
=0A=09=09=09=09=09=09Brian Campbell
Portfolio Architect
=0A=0A=0A=09=09=09=09=09
=0A=09=09=09=09=09=09=09=09=09@=0A=09=09=09=09=09=09=09=09=09bcampbell@pingidenti= ty.com
=0A=09=09=09=09=09=09=09=09=093D"phone"=0A=09=09=09=09=09=09=09=09=09+1 720.31= 7.2061
=0A=09=09=09=09=09=09= =09=09=09Connect with us=E2=80=A6
=0A=09=09=09=09=09=09=09=09=093D"twitter 3D"you= 3D"LinkedIn 3D"Facebook =3D"Google+= 3D"slideshare 3D"fl= <= a rel=3D"nofollow" shape=3D"rect" target=3D"_blank" href=3D"https://www.pin= gidentity.com/blogs/" style=3D"text-decoration:none;" title=3D"Ping blogs">= 3D"rss
=0A=09=09=09=09
=0A=
=0A=0A
=0A=09=0A=0A
=0A=0A______________________= _________________________
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


--1397251415-228175191-1400083383=:78490-- From nobody Wed May 14 09:39:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461951A02B2 for ; Wed, 14 May 2014 09:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 KZPvz9nAhNk2 for ; Wed, 14 May 2014 09:39:07 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id A235F1A0133 for ; Wed, 14 May 2014 09:39:07 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id i4so2454341oah.21 for ; Wed, 14 May 2014 09:39:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6E+mDANUs40zjMwfLIpCoGhaAZ1HRaHiUHCL6i8KK/s=; b=jApq1RhAnLV1aR7BEI3rUoZuXt2Wm0OiaQ+jIbQ+kMRgvLGOc7UBKYRY/viujb/B3/ fxmXqRlM6B/VZ6ViWdOggU2x6YO15jrdnK4fJ07LKPQatw5T3BvolI2IrB7GiURVsl2P 4XhWU62sK2KlMg6Bajcgj/ixMSVZ4xyiFj/5FTZSGvTW5WbeCIS0SXh+scjgHmwF57Bn dJxoPgWwaUc3bvG4W1n/RqWeA62AMA+7InDDbd50HibsBnjH/4Jtoobh4/vuJ54N22eR gGQPhelab6TNWr5bOXCBC12yRno26R/UpqfFBm0ciz3gzx1YLQJEF3wbXrkDJtbi4pQa OzPw== X-Gm-Message-State: ALoCoQlyLeJNRh8n66d3srZ4V+Jk4b3tFzwTMmFag3eTbd8u8flqex4WC471riZPh0tBgz7RVcc6 MIME-Version: 1.0 X-Received: by 10.182.115.199 with SMTP id jq7mr4561188obb.70.1400085540847; Wed, 14 May 2014 09:39:00 -0700 (PDT) Received: by 10.76.75.169 with HTTP; Wed, 14 May 2014 09:39:00 -0700 (PDT) In-Reply-To: References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> Date: Wed, 14 May 2014 09:39:00 -0700 Message-ID: From: Chuck Mortimore To: Anthony Nadalin Content-Type: multipart/alternative; boundary=047d7b67812051531204f95ed16d Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/8qaxKPjF5xiYrFGDDnhq5q3VClk Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 16:39:11 -0000 --047d7b67812051531204f95ed16d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Can you point to one publicly available or publicly documented implementation of a4c? I've never seen one. I will say the a4c spec is almost 100% overlapped with OpenID Connect. Some minor variations in claim names, but it adds 0 incremental value over what we have in Connect. Connect is being successfully deployed at large scale. It would be irresponsible for this working group to confuse developers and the industry with duplicate work, especially given this feels more like an argument over signing IPR agreements. -cmort On Wed, May 14, 2014 at 8:47 AM, Anthony Nadalin wro= te: > I agree with Phil on this one, there are implementations of this already > and much interest > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Wednesday, May 14, 2014 8:32 AM > *To:* Brian Campbell > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering > > > > On the contrary. I and others are interested. > > > > We are waiting for the charter to pick up the work. > > > > Regardless there will be a new draft shortly. > > > Phil > > > On May 14, 2014, at 5:24, Brian Campbell > wrote: > > I would object to 'OAuth Authentication' being picked up by the WG as a > work item. The starting point draft has expired and it hasn't really been > discusses since Berlin nearly a year ago. As I recall, there was only ve= ry > limited interest in it even then. I also don't believe it fits well with > the WG charter. > > I would suggest the WG consider picking up 'OAuth Symmetric Proof of > Possession for Code Extension' for which there is an excellent starting > point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a > relativity simple security enhancement which addresses problems currently > being encountered in deployments of native clients. > > > > On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > > Hi all, > > you might have seen that we pushed the assertion documents and the JWT > documents to the IESG today. We have also updated the milestones on the > OAuth WG page. > > This means that we can plan to pick up new work in the group. > We have sent a request to Kathleen to change the milestone for the OAuth > security mechanisms to use the proof-of-possession terminology. > > We also expect an updated version of the dynamic client registration > spec incorporating last call feedback within about 2 weeks. > > We would like you to think about adding the following milestones to the > charter as part of the re-chartering effort: > > ----- > > Nov 2014 Submit 'Token introspection' to the IESG for consideration as a > Proposed Standard > Starting point: > > Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as > a Proposed Standard > Starting point: > > Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a > Proposed Standard > Starting point: > > ----- > > We also updated the charter text to reflect the current situation. Here > is the proposed text: > > ----- > > Charter for Working Group > > > The Web Authorization (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that > supports OAuth could allow its users to use a third-party printing Web > site to print their private pictures, without allowing the printing > site to gain full control of the user's account and without having the > user share his or her photo-sharing sites' long-term credential with > the printing site. > > The OAuth 2.0 protocol suite encompasses > > * a protocol for obtaining access tokens from an authorization > server with the resource owner's consent, > * protocols for presenting these access tokens to resource server > for access to a protected resource, > * guidance for securely using OAuth 2.0, > * the ability to revoke access tokens, > * standardized format for security tokens encoded in a JSON format > (JSON Web Token, JWT), > * ways of using assertions with OAuth, and > * a dynamic client registration protocol. > > The working group also developed security schemes for presenting > authorization tokens to access a protected resource. This led to the > publication of the bearer token, as well as work that remains to be > completed on proof-of-possession and token exchange. > > The ongoing standardization effort within the OAuth working group will > focus on enhancing interoperability and functionality of OAuth > deployments, such as a standard for a token introspection service and > standards for additional security of OAuth requests. > > ----- > > Feedback appreciated. > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > > [image: Ping Identity logo] > > *Brian Campbell* > Portfolio Architect > > *@* > > bcampbell@pingidentity.com > > [image: phone] > > +1 720.317.2061 > > Connect with us=E2=80=A6 > > [image: twitter logo] [image: youtube > logo] [image: LinkedIn logo]= [image: > Facebook logo] [image: Google+ > logo] [image: > slideshare logo] [image: > flipboard logo] [image: rss feed icon] > > [image: Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] > > > > _______________________________________________ > 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 > > --047d7b67812051531204f95ed16d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can you point to one publicly available or publicly docume= nted implementation of a4c? =C2=A0 =C2=A0I've never seen one.

<= /div>
I will say the a4c spec is almost 100% overlapped with OpenID Con= nect. =C2=A0 Some minor variations in claim names, but it adds 0 incrementa= l value over what we have in Connect. =C2=A0 =C2=A0

Connect is being successfully deployed at large scale. = =C2=A0It would be irresponsible for this working group to confuse developer= s and the industry with duplicate work, especially given this feels more li= ke an argument over signing IPR agreements.

-cmort


On Wed, May 14, 2014 at 8:47 AM, Anthony Nadalin <= span dir=3D"ltr"><tonynad@microsoft.com> wrote:

I agree with Phil on this= one, there are implementations of this already and much interest=

=C2=A0

From: OAuth = [mailto:oauth-b= ounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

=C2=A0

On the contrary. I and others are interested.=C2=A0<= u>

=C2=A0

We are waiting for the charter to pick up the work.= =C2=A0

=C2=A0

Regardless there will be a new draft shortly.=C2=A0<= u>


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:=

I would object to = 9;OAuth Authentication' being picked up by the WG as a work item. The s= tarting point draft has expired and it hasn't really been discusses sin= ce Berlin nearly a year ago.=C2=A0 As I recall, there was only very limited interest in it even then. I also don't believe i= t fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Po= ssession for Code Extension' for which there is an excellent starting p= oint of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a re= lativity simple security enhancement which addresses problems currently bei= ng encountered in deployments of native clients.=C2=A0

=C2=A0<= /p>

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig &l= t;hannes.tsc= hofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration= as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideratio= n as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a=
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the<= br> user share his or her photo-sharing sites' long-term credential with the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
=C2=A0 (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

=0A=09=09=09=09=093D"Register

3D"Ping

Brian Campbell
Portfolio Architect

@

bcampbell@pingidentity.com=

3D"phone"

+1 720.317.2061<= u>

Connect with us=E2=80=A6=

3D"twitter3D"youtube=3D"LinkedIn3D"Facebook3D=3D"slideshare3D"flipboard= 3D"rss

3D"Register

=C2=A0

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


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


--047d7b67812051531204f95ed16d-- From nobody Wed May 14 09:55:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C1C1A0316 for ; Wed, 14 May 2014 09:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.841 X-Spam-Level: X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 HCwFdpRPbs9J for ; Wed, 14 May 2014 09:55:48 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5871A0318 for ; Wed, 14 May 2014 09:55:48 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4EGteQY025459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 May 2014 16:55:41 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4EGtdq5029684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2014 16:55:40 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4EGtdpP029672; Wed, 14 May 2014 16:55:39 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 May 2014 09:55:39 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_2E1FB1AB-1C0C-47C1-A608-DF0D5904B291" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: Date: Wed, 14 May 2014 09:55:37 -0700 Message-Id: <0E7371D4-510A-49A6-8096-8DF5210D5AB6@oracle.com> References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> To: Chuck & Mara Mortimore X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/WaUpCiuXlFLg7MHJENWoz57mpCM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 16:55:53 -0000 --Apple-Mail=_2E1FB1AB-1C0C-47C1-A608-DF0D5904B291 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 For the record, we adjusted draft 01 to make it more compatible with = OIDC at the request of the Connect community. I agreed to change it = because I can agree that it is a good stepping stone for adoption of = Connect. Others may prefer to have a cleanly separate method. I leave = that for the group to decide. The IETF needs a draft that enables and provides user authentication = information to clients.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com On May 14, 2014, at 9:39 AM, Chuck Mortimore = wrote: > Can you point to one publicly available or publicly documented = implementation of a4c? I've never seen one. >=20 > I will say the a4c spec is almost 100% overlapped with OpenID Connect. = Some minor variations in claim names, but it adds 0 incremental value = over what we have in Connect. =20 >=20 > Connect is being successfully deployed at large scale. It would be = irresponsible for this working group to confuse developers and the = industry with duplicate work, especially given this feels more like an = argument over signing IPR agreements. >=20 > -cmort >=20 >=20 > On Wed, May 14, 2014 at 8:47 AM, Anthony Nadalin = wrote: > I agree with Phil on this one, there are implementations of this = already and much interest >=20 > =20 >=20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Wednesday, May 14, 2014 8:32 AM > To: Brian Campbell > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering >=20 > =20 >=20 > On the contrary. I and others are interested.=20 >=20 > =20 >=20 > We are waiting for the charter to pick up the work.=20 >=20 > =20 >=20 > Regardless there will be a new draft shortly.=20 >=20 >=20 > Phil >=20 >=20 > On May 14, 2014, at 5:24, Brian Campbell = wrote: >=20 > I would object to 'OAuth Authentication' being picked up by the WG as = a work item. The starting point draft has expired and it hasn't really = been discusses since Berlin nearly a year ago. As I recall, there was = only very limited interest in it even then. I also don't believe it fits = well with the WG charter. >=20 > I would suggest the WG consider picking up 'OAuth Symmetric Proof of = Possession for Code Extension' for which there is an excellent starting = point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's = a relativity simple security enhancement which addresses problems = currently being encountered in deployments of native clients. =20 >=20 >=20 > =20 >=20 > On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > you might have seen that we pushed the assertion documents and the JWT > documents to the IESG today. We have also updated the milestones on = the > OAuth WG page. >=20 > This means that we can plan to pick up new work in the group. > We have sent a request to Kathleen to change the milestone for the = OAuth > security mechanisms to use the proof-of-possession terminology. >=20 > We also expect an updated version of the dynamic client registration > spec incorporating last call feedback within about 2 weeks. >=20 > We would like you to think about adding the following milestones to = the > charter as part of the re-chartering effort: >=20 > ----- >=20 > Nov 2014 Submit 'Token introspection' to the IESG for consideration as = a > Proposed Standard > Starting point: >=20 > Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration = as > a Proposed Standard > Starting point: >=20 > Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a > Proposed Standard > Starting point: >=20 > ----- >=20 > We also updated the charter text to reflect the current situation. = Here > is the proposed text: >=20 > ----- >=20 > Charter for Working Group >=20 >=20 > The Web Authorization (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that > supports OAuth could allow its users to use a third-party printing Web > site to print their private pictures, without allowing the printing > site to gain full control of the user's account and without having the > user share his or her photo-sharing sites' long-term credential with > the printing site. >=20 > The OAuth 2.0 protocol suite encompasses >=20 > * a protocol for obtaining access tokens from an authorization > server with the resource owner's consent, > * protocols for presenting these access tokens to resource server > for access to a protected resource, > * guidance for securely using OAuth 2.0, > * the ability to revoke access tokens, > * standardized format for security tokens encoded in a JSON format > (JSON Web Token, JWT), > * ways of using assertions with OAuth, and > * a dynamic client registration protocol. >=20 > The working group also developed security schemes for presenting > authorization tokens to access a protected resource. This led to the > publication of the bearer token, as well as work that remains to be > completed on proof-of-possession and token exchange. >=20 > The ongoing standardization effort within the OAuth working group will > focus on enhancing interoperability and functionality of OAuth > deployments, such as a standard for a token introspection service and > standards for additional security of OAuth requests. >=20 > ----- >=20 > Feedback appreciated. >=20 > Ciao > Hannes & Derek >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > -- >=20 >=20 >=20 > Brian Campbell > Portfolio Architect >=20 > @ >=20 > bcampbell@pingidentity.com >=20 >=20 >=20 > +1 720.317.2061 >=20 > Connect with us=85 >=20 >=20 >=20 >=20 >=20 > =20 >=20 > _______________________________________________ > 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 >=20 --Apple-Mail=_2E1FB1AB-1C0C-47C1-A608-DF0D5904B291 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 For = the record, we adjusted draft 01 to make it more compatible with OIDC at = the request of the Connect community.  I agreed to change it = because I can agree that it is a good stepping stone for adoption of = Connect. Others may prefer to have a cleanly separate method. I leave = that for the group to decide.

The IETF needs a draft = that enables and provides user authentication information to = clients. 

Phil

On May 14, 2014, at 9:39 AM, Chuck Mortimore <cmortimore@salesforce.com>= ; wrote:

Can you point to one publicly available = or publicly documented implementation of a4c?    I've never = seen one.

I will say the a4c spec is almost 100% = overlapped with OpenID Connect.   Some minor variations in claim = names, but it adds 0 incremental value over what we have in Connect. =    

Connect is being successfully deployed at large = scale.  It would be irresponsible for this working group to confuse = developers and the industry with duplicate work, especially given this = feels more like an argument over signing IPR agreements.

-cmort


On Wed, May 14, = 2014 at 8:47 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:

I agree with Phil on this one, there are = implementations of this already and much = interest

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and = Rechartering

 

On the contrary. I and others are = interested. 

 

We are waiting for the charter to pick up = the work. 

 

Regardless there will be a new draft = shortly. 


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> = wrote:

I would = object to 'OAuth Authentication' being picked up by the WG as a work = item. The starting point draft has expired and it hasn't really been = discusses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even then. I also don't believe it = fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of = Possession for Code Extension' for which there is an excellent starting = point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a = relativity simple security enhancement which addresses problems = currently being encountered in deployments of native clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes = Tschofenig <hannes.tschofenig@gmx.net> = wrote:

Hi all,

you might have seen that we pushed the assertion documents and the = JWT
documents to the IESG today. We have also updated the milestones on = the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the = OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to = the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as = a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration = as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. = Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term = credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing = Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having = the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group = will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service = and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

3D"Ping

Brian Campbell
Portfolio Architect

@

bcampbell@pingidentity.com

3D"phone"

+1 720.317.2061

Connect with us=85

3D"twitter3D"youtube3D"LinkedIn3D"Facebook3D"Google+3D"slideshare3D"flipboard3D"rss

3D"Register

 

_______________________________________________
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=_2E1FB1AB-1C0C-47C1-A608-DF0D5904B291-- From nobody Wed May 14 10:10:54 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113A41A0109 for ; Wed, 14 May 2014 10:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 w0bWelPJjqig for ; Wed, 14 May 2014 10:10:47 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id 845F01A00B2 for ; Wed, 14 May 2014 10:10:47 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id m1so2561733oag.28 for ; Wed, 14 May 2014 10:10:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7Tn7DKAeLR3QYMCLzlAVIAGLnvTdfBFq/qspAkFmOLQ=; b=JwyD593hMFeq7nmcVdt1CveTLnZRtjl16OLBPXijQFkfKFEgiYJkTPKOz6OSXwRKnD iPtWjaBn+t8YGLNgWPGc0X8oQ1rRrCNYtyoQ4QhZPf1CEAFUE/u2b1Xvv/FD1RcNc4dI BQ7lsbjNKtPo6n3wF3MCB5KRMDDjpaFDu2lxJb//N3NgsyO+4fMT6Efwccc8NNALaD3T GmmLacmZKg5/Ijq14P8uu7E/5eJY17cLYXLtdRwZ945WvLlKAEHI3+0Dy+0x4SnunjjI XgY+PI4iidgJeRrPBNSk0KXi2BLdqlq5KgJsPS65HHw0dcT7kYtqtui0v4Ag0NDnwFIZ LNSg== X-Gm-Message-State: ALoCoQlhR3r8TvpTV1l5jIiwNvAhdC+EeuGK4hmaATeTvTakrYFnGNOMEkPeCudYx3+V/kxhX7Ur MIME-Version: 1.0 X-Received: by 10.60.83.73 with SMTP id o9mr4865061oey.56.1400087440716; Wed, 14 May 2014 10:10:40 -0700 (PDT) Received: by 10.76.75.169 with HTTP; Wed, 14 May 2014 10:10:40 -0700 (PDT) In-Reply-To: <0E7371D4-510A-49A6-8096-8DF5210D5AB6@oracle.com> References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <0E7371D4-510A-49A6-8096-8DF5210D5AB6@oracle.com> Date: Wed, 14 May 2014 10:10:40 -0700 Message-ID: From: Chuck Mortimore To: Phil Hunt Content-Type: multipart/alternative; boundary=089e0118403e8f087404f95f42c4 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/FDZ1xx5TyahtrnaSbPQga8U0pRA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:10:51 -0000 --089e0118403e8f087404f95f42c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > > The IETF needs a draft that enables and provides user authentication > information to clients. > Why? -cmort > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On May 14, 2014, at 9:39 AM, Chuck Mortimore > wrote: > > Can you point to one publicly available or publicly documented > implementation of a4c? I've never seen one. > > I will say the a4c spec is almost 100% overlapped with OpenID Connect. > Some minor variations in claim names, but it adds 0 incremental value ove= r > what we have in Connect. > > Connect is being successfully deployed at large scale. It would be > irresponsible for this working group to confuse developers and the indust= ry > with duplicate work, especially given this feels more like an argument ov= er > signing IPR agreements. > > -cmort > > > On Wed, May 14, 2014 at 8:47 AM, Anthony Nadalin w= rote: > >> I agree with Phil on this one, there are implementations of this >> already and much interest >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt >> *Sent:* Wednesday, May 14, 2014 8:32 AM >> *To:* Brian Campbell >> *Cc:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering >> >> >> >> On the contrary. I and others are interested. >> >> >> >> We are waiting for the charter to pick up the work. >> >> >> >> Regardless there will be a new draft shortly. >> >> >> Phil >> >> >> On May 14, 2014, at 5:24, Brian Campbell >> wrote: >> >> I would object to 'OAuth Authentication' being picked up by the WG as a >> work item. The starting point draft has expired and it hasn't really bee= n >> discusses since Berlin nearly a year ago. As I recall, there was only v= ery >> limited interest in it even then. I also don't believe it fits well with >> the WG charter. >> >> I would suggest the WG consider picking up 'OAuth Symmetric Proof of >> Possession for Code Extension' for which there is an excellent starting >> point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's >> a relativity simple security enhancement which addresses problems curren= tly >> being encountered in deployments of native clients. >> >> >> >> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig < >> hannes.tschofenig@gmx.net> wrote: >> >> Hi all, >> >> you might have seen that we pushed the assertion documents and the JWT >> documents to the IESG today. We have also updated the milestones on the >> OAuth WG page. >> >> This means that we can plan to pick up new work in the group. >> We have sent a request to Kathleen to change the milestone for the OAuth >> security mechanisms to use the proof-of-possession terminology. >> >> We also expect an updated version of the dynamic client registration >> spec incorporating last call feedback within about 2 weeks. >> >> We would like you to think about adding the following milestones to the >> charter as part of the re-chartering effort: >> >> ----- >> >> Nov 2014 Submit 'Token introspection' to the IESG for consideration as a >> Proposed Standard >> Starting point: >> >> Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as >> a Proposed Standard >> Starting point: >> >> Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a >> Proposed Standard >> Starting point: >> >> ----- >> >> We also updated the charter text to reflect the current situation. Here >> is the proposed text: >> >> ----- >> >> Charter for Working Group >> >> >> The Web Authorization (OAuth) protocol allows a user to grant a >> third-party Web site or application access to the user's protected >> resources, without necessarily revealing their long-term credentials, >> or even their identity. For example, a photo-sharing site that >> supports OAuth could allow its users to use a third-party printing Web >> site to print their private pictures, without allowing the printing >> site to gain full control of the user's account and without having the >> user share his or her photo-sharing sites' long-term credential with >> the printing site. >> >> The OAuth 2.0 protocol suite encompasses >> >> * a protocol for obtaining access tokens from an authorization >> server with the resource owner's consent, >> * protocols for presenting these access tokens to resource server >> for access to a protected resource, >> * guidance for securely using OAuth 2.0, >> * the ability to revoke access tokens, >> * standardized format for security tokens encoded in a JSON format >> (JSON Web Token, JWT), >> * ways of using assertions with OAuth, and >> * a dynamic client registration protocol. >> >> The working group also developed security schemes for presenting >> authorization tokens to access a protected resource. This led to the >> publication of the bearer token, as well as work that remains to be >> completed on proof-of-possession and token exchange. >> >> The ongoing standardization effort within the OAuth working group will >> focus on enhancing interoperability and functionality of OAuth >> deployments, such as a standard for a token introspection service and >> standards for additional security of OAuth requests. >> >> ----- >> >> Feedback appreciated. >> >> Ciao >> Hannes & Derek >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> -- >> >> [image: Ping Identity logo] >> >> *Brian Campbell* >> Portfolio Architect >> >> *@* >> >> bcampbell@pingidentity.com >> >> [image: phone] >> >> +1 720.317.2061 >> >> Connect with us=E2=80=A6 >> >> [image: twitter logo] [image: youtube >> logo] [image: LinkedIn logo= ][image: >> Facebook logo] [image: >> Google+ logo] [image: >> slideshare logo] [image: >> flipboard logo] [image: rss feed icon] >> >> [image: Register for Cloud Identity Summit 2014 | Modern Identity >> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >> >> >> >> _______________________________________________ >> 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 >> >> > > --089e0118403e8f087404f95f42c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The IETF needs a draft that enables and provides user authenticatio= n information to clients.=C2=A0

Why?

-cmort=
=C2=A0

Phil

@independentid
phil.hunt@oracle.co= m



On May 14, 2014, at 9:39 AM, Chuck Mortimore <cmortimore@salesforce.co= m> wrote:

Can yo= u point to one publicly available or publicly documented implementation of = a4c? =C2=A0 =C2=A0I've never seen one.

I will say the a4c spec is almost 100% overlapped with OpenI= D Connect. =C2=A0 Some minor variations in claim names, but it adds 0 incre= mental value over what we have in Connect. =C2=A0 =C2=A0

Connect is being successfully deployed at large scale. = =C2=A0It would be irresponsible for this working group to confuse developer= s and the industry with duplicate work, especially given this feels more li= ke an argument over signing IPR agreements.

-cmort


On Wed, May 14, 2014 at 8:47 AM, Anthony Nadalin <= span dir=3D"ltr"><tonynad@microsoft.com> wrote:

I agree with Phil on= this one, there are implementations of this already and much interest

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

=C2=A0

On the contrary. I and others are interested.= =C2=A0

=C2=A0

We are waiting for the charter to pick up the w= ork.=C2=A0

=C2=A0

Regardless there will be a new draft shortly.= =C2=A0


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:=

I would object t= o 'OAuth Authentication' being picked up by the WG as a work item. = The starting point draft has expired and it hasn't really been discusse= s since Berlin nearly a year ago.=C2=A0 As I recall, there was only very limited interest in it even then. I also don't believe i= t fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Po= ssession for Code Extension' for which there is an excellent starting p= oint of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a re= lativity simple security enhancement which addresses problems currently bei= ng encountered in deployments of native clients.=C2=A0

=C2=A0=

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofen= ig <hanne= s.tschofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration= as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideratio= n as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a=
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the<= br> user share his or her photo-sharing sites' long-term credential with the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
=C2=A0 (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

=

Brian Campbell
Portfolio Arc= hitect

@

bcampbell@pingidentity.com

3D"phone"

+1 720.317.2061

Connect with us=E2=80=A6

=3D"twitter3D"youtube3D"LinkedIn3D"Facebook3D"Google+3D"flipboard3D"rss

3D"Register=

=C2=A0

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


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




--089e0118403e8f087404f95f42c4-- From nobody Wed May 14 10:23:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD3D1A0127 for ; Wed, 14 May 2014 10:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_EXTRA_CLOSE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=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 sc3NNslpm4qW for ; Wed, 14 May 2014 10:23:10 -0700 (PDT) Received: from omr-m10.mx.aol.com (omr-m10.mx.aol.com [64.12.143.86]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD401A013E for ; Wed, 14 May 2014 10:23:08 -0700 (PDT) Received: from mtaout-mac02.mx.aol.com (mtaout-mac02.mx.aol.com [172.26.222.206]) by omr-m10.mx.aol.com (Outbound Mail Relay) with ESMTP id 38D0E70274DFC for ; Wed, 14 May 2014 13:23:01 -0400 (EDT) Received: from [10.181.176.188] (unknown [10.181.176.188]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mac02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id E9615380000B2 for ; Wed, 14 May 2014 13:23:00 -0400 (EDT) Message-ID: <5373A674.1060700@aol.com> Date: Wed, 14 May 2014 13:23:00 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "oauth@ietf.org" References: <536BF140.5070106@gmx.net> <84B60891-F9E1-4183-9031-8BED6315C70F@mit.edu> <-968574624925308911@unknownmsgid> In-Reply-To: <-968574624925308911@unknownmsgid> Content-Type: multipart/alternative; boundary="------------070407000600050405060503" x-aol-global-disposition: G X-AOL-VSS-INFO: 5600.1067/98021 X-AOL-VSS-CODE: clean DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1400088181; bh=vo4y7MEjrQ/1sAT50I3uooToR3jhmanw6Vl44Fg7GKU=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=K3ydv2iIyUxM5UkVHdNcjnzqxY3XnOztXzhtb4CViIoCXw3Skq60P1f9+YNASvzmO MLhQQGh+RuyKvijyzBFfLE6FSHlYlswZ7SHUzcFQcTgiDSjtirBmohQxHbAeXp0miA 3jm6bpA7b+qUMWP3PAvqVxLHmKZzochfuZ3qKJVw= x-aol-sid: 3039ac1adece5373a6745c84 X-AOL-IP: 10.181.176.188 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/VyqpQWHZJVsunPawQg_ltCpLjm4 Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:23:13 -0000 This is a multi-part message in MIME format. --------------070407000600050405060503 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I also would like to see the WG not focus on another authentication mechanism and instead look at work like Brian suggested. Thanks, George On 5/14/14, 11:41 AM, Chuck Mortimore wrote: > Agree with Brian and Justin here. Work is already covered in Connect > > - cmort > > On May 14, 2014, at 8:39 AM, Justin Richer > wrote: > >> I agree with Brian and object to the Authentication work item. I >> think there’s limited interest and utility in such a draft, >> especially now that OpenID Connect has been published and its core >> authentication capabilities are identical to what was called for in >> the other draft a year ago (a similarity, I’ll add, which was noted >> at the time). >> >> — Justin >> >> On May 14, 2014, at 8:24 AM, Brian Campbell >> > wrote: >> >>> I would object to 'OAuth Authentication' being picked up by the WG >>> as a work item. The starting point draft has expired and it hasn't >>> really been discusses since Berlin nearly a year ago. As I recall, >>> there was only very limited interest in it even then. I also don't >>> believe it fits well with the WG charter. >>> >>> I would suggest the WG consider picking up 'OAuth Symmetric Proof of >>> Possession for Code Extension' for which there is an excellent >>> starting point of >>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a >>> relativity simple security enhancement which addresses problems >>> currently being encountered in deployments of native clients. >>> >>> >>> >>> >>> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig >>> > wrote: >>> >>> Hi all, >>> >>> you might have seen that we pushed the assertion documents and >>> the JWT >>> documents to the IESG today. We have also updated the milestones >>> on the >>> OAuth WG page. >>> >>> This means that we can plan to pick up new work in the group. >>> We have sent a request to Kathleen to change the milestone for >>> the OAuth >>> security mechanisms to use the proof-of-possession terminology. >>> >>> We also expect an updated version of the dynamic client registration >>> spec incorporating last call feedback within about 2 weeks. >>> >>> We would like you to think about adding the following milestones >>> to the >>> charter as part of the re-chartering effort: >>> >>> ----- >>> >>> Nov 2014 Submit 'Token introspection' to the IESG for >>> consideration as a >>> Proposed Standard >>> Starting point: >>> >>> Jan 2015 Submit 'OAuth Authentication' to the IESG for >>> consideration as >>> a Proposed Standard >>> Starting point: >>> >>> Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a >>> Proposed Standard >>> Starting point: >>> >>> ----- >>> >>> We also updated the charter text to reflect the current >>> situation. Here >>> is the proposed text: >>> >>> ----- >>> >>> Charter for Working Group >>> >>> >>> The Web Authorization (OAuth) protocol allows a user to grant a >>> third-party Web site or application access to the user's protected >>> resources, without necessarily revealing their long-term >>> credentials, >>> or even their identity. For example, a photo-sharing site that >>> supports OAuth could allow its users to use a third-party >>> printing Web >>> site to print their private pictures, without allowing the printing >>> site to gain full control of the user's account and without >>> having the >>> user share his or her photo-sharing sites' long-term credential with >>> the printing site. >>> >>> The OAuth 2.0 protocol suite encompasses >>> >>> * a protocol for obtaining access tokens from an authorization >>> server with the resource owner's consent, >>> * protocols for presenting these access tokens to resource server >>> for access to a protected resource, >>> * guidance for securely using OAuth 2.0, >>> * the ability to revoke access tokens, >>> * standardized format for security tokens encoded in a JSON format >>> (JSON Web Token, JWT), >>> * ways of using assertions with OAuth, and >>> * a dynamic client registration protocol. >>> >>> The working group also developed security schemes for presenting >>> authorization tokens to access a protected resource. This led to the >>> publication of the bearer token, as well as work that remains to be >>> completed on proof-of-possession and token exchange. >>> >>> The ongoing standardization effort within the OAuth working >>> group will >>> focus on enhancing interoperability and functionality of OAuth >>> deployments, such as a standard for a token introspection >>> service and >>> standards for additional security of OAuth requests. >>> >>> ----- >>> >>> Feedback appreciated. >>> >>> Ciao >>> Hannes & Derek >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> -- >>> Ping Identity logo >>> Brian Campbell >>> Portfolio Architect >>> @ bcampbell@pingidentity.com >>> phone +1 720.317.2061 >>> Connect with us… >>> twitter logo youtube logo >>> LinkedIn logo >>> Facebook logo >>> Google+ logo >>> slideshare logo >>> flipboard logo >>> rss feed icon >>> >>> >>> Register for Cloud Identity Summit 2014 | Modern Identity Revolution >>> | 19–23 July, 2014 | Monterey, CA >>> >>> >>> >>> _______________________________________________ >>> 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 -- George Fletcher --------------070407000600050405060503 Content-Type: multipart/related; boundary="------------040301090702050803020704" --------------040301090702050803020704 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I also would like to see the WG not focus on another authentication mechanism and instead look at work like Brian suggested.

Thanks,
George
On 5/14/14, 11:41 AM, Chuck Mortimore wrote:
Agree with Brian and Justin here.   Work is already covered in Connect

- cmort

On May 14, 2014, at 8:39 AM, Justin Richer <jricher@mit.edu> wrote:

I agree with Brian and object to the Authentication work item. I think there’s limited interest and utility in such a draft, especially now that OpenID Connect has been published and its core authentication capabilities are identical to what was called for in the other draft a year ago (a similarity, I’ll add, which was noted at the time). 

 — Justin

On May 14, 2014, at 8:24 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients. 




On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--
Ping Identity logo
Brian Campbell
Portfolio Architect
@ bcampbell@pingidentity.com
phone +1 720.317.2061
Connect with us…
twitter logo youtube logo LinkedIn logo Facebook logo Google+ logo slideshare logo flipboard logo rss feed icon
Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA

_______________________________________________
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

--
George Fletcher
--------------040301090702050803020704 Content-Type: text/html; charset=UTF-8; name="XeC" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="XeC" Content-Base: "https://d2vm7miu7c0y35.cloudfront.net/ embed/card/XeC?scores=1&13554124169 35" Content-Location: "https://d2vm7miu7c0y35.cloudfront.net/ embed/card/XeC?scores=1&13554124169 35" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxIVE1M PjxIRUFEPjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPgo8VElUTEU+RVJST1I6IFRoZSByZXF1ZXN0IGNv dWxkIG5vdCBiZSBzYXRpc2ZpZWQ8L1RJVExFPgo8L0hFQUQ+PEJPRFk+CjxIMT5FUlJPUjwv SDE+CjxIMj5UaGUgcmVxdWVzdCBjb3VsZCBub3QgYmUgc2F0aXNmaWVkLjwvSDI+CjxIUiBu b3NoYWRlIHNpemU9IjFweCI+CjwvQk9EWT48L0hUTUw+Cgo8QlIgY2xlYXI9ImFsbCI+CjxI UiBub3NoYWRlIHNpemU9IjFweCI+CjxBRERSRVNTPgpHZW5lcmF0ZWQgYnkgY2xvdWRmcm9u dCAoQ2xvdWRGcm9udCkKPC9BRERSRVNTPgo8L0JPRFk+PC9IVE1MPg== --------------040301090702050803020704-- --------------070407000600050405060503-- From nobody Wed May 14 10:30:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15D21A014C for ; Wed, 14 May 2014 10:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.841 X-Spam-Level: X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 BAJGAPO3iZ0a for ; Wed, 14 May 2014 10:30:14 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8C71A0134 for ; Wed, 14 May 2014 10:30:14 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4EHU5qh002743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 May 2014 17:30:06 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4EHU4JH013904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2014 17:30:05 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4EHU4X9001740; Wed, 14 May 2014 17:30:04 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 May 2014 10:30:03 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_842A30A8-B336-4B74-8A54-1D792DC53D23" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: <5373A674.1060700@aol.com> Date: Wed, 14 May 2014 10:29:58 -0700 Message-Id: References: <536BF140.5070106@gmx.net> <84B60891-F9E1-4183-9031-8BED6315C70F@mit.edu> <-968574624925308911@unknownmsgid> <5373A674.1060700@aol.com> To: George Fletcher X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/v6IzbEi85jp-50wnOJFy0oZcxb0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:30:17 -0000 --Apple-Mail=_842A30A8-B336-4B74-8A54-1D792DC53D23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This is not an authentication mechanism - it is a method for providing = end-user authentication information to client applications. I will = publish a revised draft shortly.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com On May 14, 2014, at 10:23 AM, George Fletcher wrote: > I also would like to see the WG not focus on another authentication = mechanism and instead look at work like Brian suggested. >=20 > Thanks, > George >=20 > On 5/14/14, 11:41 AM, Chuck Mortimore wrote: >> Agree with Brian and Justin here. Work is already covered in = Connect >>=20 >> - cmort >>=20 >> On May 14, 2014, at 8:39 AM, Justin Richer wrote: >>=20 >>> I agree with Brian and object to the Authentication work item. I = think there=92s limited interest and utility in such a draft, especially = now that OpenID Connect has been published and its core authentication = capabilities are identical to what was called for in the other draft a = year ago (a similarity, I=92ll add, which was noted at the time).=20 >>>=20 >>> =97 Justin >>>=20 >>> On May 14, 2014, at 8:24 AM, Brian Campbell = wrote: >>>=20 >>>> I would object to 'OAuth Authentication' being picked up by the WG = as a work item. The starting point draft has expired and it hasn't = really been discusses since Berlin nearly a year ago. As I recall, = there was only very limited interest in it even then. I also don't = believe it fits well with the WG charter. >>>>=20 >>>> I would suggest the WG consider picking up 'OAuth Symmetric Proof = of Possession for Code Extension' for which there is an excellent = starting point of = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a = relativity simple security enhancement which addresses problems = currently being encountered in deployments of native clients. =20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig = wrote: >>>> Hi all, >>>>=20 >>>> you might have seen that we pushed the assertion documents and the = JWT >>>> documents to the IESG today. We have also updated the milestones on = the >>>> OAuth WG page. >>>>=20 >>>> This means that we can plan to pick up new work in the group. >>>> We have sent a request to Kathleen to change the milestone for the = OAuth >>>> security mechanisms to use the proof-of-possession terminology. >>>>=20 >>>> We also expect an updated version of the dynamic client = registration >>>> spec incorporating last call feedback within about 2 weeks. >>>>=20 >>>> We would like you to think about adding the following milestones to = the >>>> charter as part of the re-chartering effort: >>>>=20 >>>> ----- >>>>=20 >>>> Nov 2014 Submit 'Token introspection' to the IESG for consideration = as a >>>> Proposed Standard >>>> Starting point: >>>>=20 >>>> Jan 2015 Submit 'OAuth Authentication' to the IESG for = consideration as >>>> a Proposed Standard >>>> Starting point: >>>>=20 >>>> Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a >>>> Proposed Standard >>>> Starting point: >>>>=20 >>>> ----- >>>>=20 >>>> We also updated the charter text to reflect the current situation. = Here >>>> is the proposed text: >>>>=20 >>>> ----- >>>>=20 >>>> Charter for Working Group >>>>=20 >>>>=20 >>>> The Web Authorization (OAuth) protocol allows a user to grant a >>>> third-party Web site or application access to the user's protected >>>> resources, without necessarily revealing their long-term = credentials, >>>> or even their identity. For example, a photo-sharing site that >>>> supports OAuth could allow its users to use a third-party printing = Web >>>> site to print their private pictures, without allowing the printing >>>> site to gain full control of the user's account and without having = the >>>> user share his or her photo-sharing sites' long-term credential = with >>>> the printing site. >>>>=20 >>>> The OAuth 2.0 protocol suite encompasses >>>>=20 >>>> * a protocol for obtaining access tokens from an authorization >>>> server with the resource owner's consent, >>>> * protocols for presenting these access tokens to resource server >>>> for access to a protected resource, >>>> * guidance for securely using OAuth 2.0, >>>> * the ability to revoke access tokens, >>>> * standardized format for security tokens encoded in a JSON format >>>> (JSON Web Token, JWT), >>>> * ways of using assertions with OAuth, and >>>> * a dynamic client registration protocol. >>>>=20 >>>> The working group also developed security schemes for presenting >>>> authorization tokens to access a protected resource. This led to = the >>>> publication of the bearer token, as well as work that remains to be >>>> completed on proof-of-possession and token exchange. >>>>=20 >>>> The ongoing standardization effort within the OAuth working group = will >>>> focus on enhancing interoperability and functionality of OAuth >>>> deployments, such as a standard for a token introspection service = and >>>> standards for additional security of OAuth requests. >>>>=20 >>>> ----- >>>>=20 >>>> Feedback appreciated. >>>>=20 >>>> Ciao >>>> Hannes & Derek >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> =09 >>>> Brian Campbell >>>> Portfolio Architect >>>> @ bcampbell@pingidentity.com >>>> +1 720.317.2061 >>>> Connect with us=85 >>>> =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 >>=20 >> _______________________________________________ >> 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=_842A30A8-B336-4B74-8A54-1D792DC53D23 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 This = is not an authentication mechanism - it is a method for providing = end-user authentication information to client applications.  I will = publish a revised draft shortly. 

--089e013a1d8e97d45304f986f622-- From nobody Fri May 16 11:28:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43491A0273 for ; Fri, 16 May 2014 10:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 XOrpLtIpn9aQ for ; Fri, 16 May 2014 10:11:33 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95EAD1A00DF for ; Fri, 16 May 2014 10:11:33 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id at1so2806186iec.19 for ; Fri, 16 May 2014 10:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aOQrr7qNokbkkUftoa+3Yfpxtnp644SQqZqmFMXYjUU=; b=SGhO4YVm/z0mOgth2XmI1bAhKDzW3soiHC8zxWvfJ8TqwQUmMoB0VLKNFp+CbQlwlX 4PpBQrv7wcZ94MDY6vlCKKTp/YEevpTBpKNGGzIPQl2GDwTO+FRqkCYNCEZDFtD03TuA XK/jITiC6IfWnq8KPouE53m+DosODahEBPPXcgcDIjkHeqU+Cbt/2Tav5/MBRlro2z3W WJUQavY+Q92qz6SAav3vxAcsf1qHHFmw3UDBzsyLYqAfzeI6YfEMG/pz/Y9eDpS0tLlv ZC4HMtiwyehSplYjHOCB+aVpTl6CQ9coNrj2+3s3u899nTqXNgoSm7zZETfWJ+V4Ae5q ypqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aOQrr7qNokbkkUftoa+3Yfpxtnp644SQqZqmFMXYjUU=; b=SE3hVmXPrZ8DZPaNGDKwYTWrk9+qerEE12Au6rhY89Q3IWir8i/y1Jsxm41Kr1RToA AZEiqx+Dd2A5ogaMi+TpkZjxQPw2r78jR/g+tWFKQCxTCFM6U4SxRC+Us3FmlkblO/N1 nIWF7DMF/jaFIK4nnCDroD0RtCkOaxMfzrvKtn58VVFpqDXPMdmNhsoxFjW7NnYJPOSH ZVWFB7FW3tm6M1aaQJPHkwQm5TXQv3IkTodsro4I89UgjLcwYrD3o7V0rtxoVaX53IEA Emio43SIxhuLrCdDsbp7bxvIg6iokkJVgHzqH5NpK1Ua1oCg2fNgBCloW8mfm34qlKbg gWbw== X-Gm-Message-State: ALoCoQki7dPqQIPbpt6iGvDk68qC5SsXZYha03b5eF3fUaJ3qBfAmj90nZDCM3afHY7nU+kXGbET X-Received: by 10.43.141.81 with SMTP id jd17mr16672179icc.39.1400260285853; Fri, 16 May 2014 10:11:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.239.207 with HTTP; Fri, 16 May 2014 10:11:05 -0700 (PDT) In-Reply-To: References: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> From: Naveen Agarwal Date: Fri, 16 May 2014 10:11:05 -0700 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=001a11c2d9c0ee88de04f98780c0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/bxvQIas3ANrPi6b9tRmhKn9SGEU X-Mailman-Approved-At: Fri, 16 May 2014 11:08:22 -0700 Cc: oauth Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 17:11:45 -0000 --001a11c2d9c0ee88de04f98780c0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think having a limit is much better (to increase compatibility) than not having one. If servers code developers will have to make a decision on the length they should accept and they'll all select a different one and cause issues. Of course the browser URL size have limits and having much larger than 128 octets is not improving the security much. Thanks Naveen On Fri, May 16, 2014 at 9:32 AM, Brian Campbell wrote: > Yeah, I agree with John here. There are a few good reasons to restrict th= e > length of the code_challenge. One is trying to keep the authorization > request URI to reasonable size as it will eventually run into various > limits on clients and/or servers. The other is constraining the amount of > data that an AS needs to store per code. > > > > > On Fri, May 16, 2014 at 7:41 AM, John Bradley wrote: > >> From the AS side you probably want to know what the max size you need to >> store per code. >> >> On the call to the token endpoint it is a POST so size should not be an >> issue. >> >> >> On May 16, 2014, at 3:10 PM, Nat Sakimura wrote: >> >> Now that I cannot remember what limit we were hitting, it might be a goo= d >> idea to remove the constraint and see if anyone protests. >> >> What do you think? >> >> Nat >> >> >> 2014-05-14 20:46 GMT+09:00 Brian Campbell : >> >>> That too would suggest that the length limit be on code_challenge >>> because that's the parameter that will be on URIs getting passed around= . >>> The code_verifier is sent directly in the POST body from client to AS. >>> >>> >>> On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura wrot= e: >>> >>>> +1 for octet. We used to have "bytes" in JW* so I used "bytes" here, >>>> while at the same time complaining in Jose that it should be "octet". = JW* >>>> changed to "octet" but I failed to sync with it in the last few edits. >>>> >>>> I do not quite remember which platform, but the reason for the limit >>>> was that some platform had some limitations as to the length of the st= ing >>>> to be passed to it through URI and we did not want the challenges to b= e >>>> truncated by that limit. >>>> >>>> Best, >>>> >>>> Nat >>>> >>>> >>>> 2014-05-13 6:56 GMT+09:00 Brian Campbell : >>>> >>>> And it'd give the AS some direct guidance on protecting itself from >>>>> crazy long code_challenge values rather than relying on the client no= t to >>>>> do something creative. >>>>> >>>>> >>>>> On Mon, May 12, 2014 at 3:54 PM, Brian Campbell < >>>>> bcampbell@pingidentity.com> wrote: >>>>> >>>>>> Right but that's why I'm asking why not just put the limit on >>>>>> code_challange rather than inferring it from code_verifyer + challen= ge >>>>>> algorithm, which probably bounds it but doesn't necessarily do so? I= t's not >>>>>> a big deal but would read more clearly, I think. >>>>>> >>>>>> >>>>>> On Mon, May 12, 2014 at 3:48 PM, John Bradley wro= te: >>>>>> >>>>>>> I think octets is more consistent with other JW* and OAuth specs. >>>>>>> >>>>>>> The code_challange is the same length as the code_verifyer or is a >>>>>>> hash of the code_verifyer so likely smaller than 128octets (43 ish = for >>>>>>> base64 256 bit) >>>>>>> >>>>>>> Limiting the code_verifyer size sets the upper bound for >>>>>>> code_challange, unless someone comes up with a really creative code >>>>>>> challenge algorithm. >>>>>>> >>>>>>> I will talk to nat about changing it to octets when I see him >>>>>>> tomorrow. >>>>>>> >>>>>>> John B. >>>>>>> >>>>>>> On May 12, 2014, at 11:15 PM, Derek Atkins wrote: >>>>>>> >>>>>>> > Brian Campbell writes: >>>>>>> > >>>>>>> >> I notice that code_verifier is defined as "high entropy >>>>>>> cryptographic random >>>>>>> >> string of length less than 128 bytes" [1], which brought a few >>>>>>> questions and >>>>>>> >> comments to mind. So here goes: >>>>>>> >> >>>>>>> >> Talking about the length of a string in terms of bytes is always >>>>>>> potentially >>>>>>> >> confusing. Maybe characters would be an easier unit for people >>>>>>> like me to wrap >>>>>>> >> their little brains around? >>>>>>> > >>>>>>> > It depends if it really is characters or bytes. For example ther= e >>>>>>> are >>>>>>> > many multi-byte UTF-8 characters, so if it really is bytes then >>>>>>> saying >>>>>>> > characters is wrong because it could overflow. So let's make sur= e >>>>>>> we >>>>>>> > know what we're talking about. Historically, if we're talking >>>>>>> bytes the >>>>>>> > IETF often uses the phrase "octets". Would that be less confusin= g? >>>>>>> > >>>>>>> >> Why are we putting a length restriction on the code_verifier >>>>>>> anyway? It seems >>>>>>> >> like it'd be more appropriate to restrict the length of the >>>>>>> code_challenge >>>>>>> >> because that's the thing the AS will have to maintain somehow >>>>>>> (store in a DB >>>>>>> >> or memory or encrypt into the code). Am I missing something here= ? >>>>>>> >> >>>>>>> >> Let me also say that I hadn't looked at this document since its >>>>>>> early days in >>>>>>> >> draft -00 or -01 last summer but I like the changes and how it's >>>>>>> been kept >>>>>>> >> pretty simple for the common use-case while still allowing for >>>>>>> crypto agility/ >>>>>>> >> extension. Nice work! >>>>>>> >> >>>>>>> >> [1] >>>>>>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 >>>>>>> > >>>>>>> > -derek >>>>>>> > >>>>>>> >> _______________________________________________ >>>>>>> >> OAuth mailing list >>>>>>> >> OAuth@ietf.org >>>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> > >>>>>>> > -- >>>>>>> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >>>>>>> > Member, MIT Student Information Processing Board (SIPB) >>>>>>> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >>>>>>> > warlord@MIT.EDU PGP key available >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> [image: Ping Identity logo] >>>>>> Brian Campbell >>>>>> Portfolio Architect >>>>>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Conn= ect >>>>>> with us=E2=80=A6 [image: twitter logo] [image: >>>>>> youtube logo] [image: >>>>>> LinkedIn logo] [image: >>>>>> Facebook logo] [image: >>>>>> Google+ logo] [i= mage: >>>>>> slideshare logo] [image: >>>>>> flipboard logo] [image: rss feed icon] >>>>>> [image: Register for Cloud Identity Summit 2014 | Modern Identity >>>>>> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> [image: Ping Identity logo] >>>>> Brian Campbell >>>>> Portfolio Architect >>>>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Conne= ct >>>>> with us=E2=80=A6 [image: twitter logo] [image: >>>>> youtube logo] [image: >>>>> LinkedIn logo] [image: >>>>> Facebook logo] [image: >>>>> Google+ logo] [im= age: >>>>> slideshare logo] [image: >>>>> flipboard logo] [image: rss feed icon] >>>>> [image: Register for Cloud Identity Summit 2014 | Modern Identity >>>>> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> >>> -- >>> [image: Ping Identity logo] >>> Brian Campbell >>> Portfolio Architect >>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect >>> with us=E2=80=A6 [image: twitter logo] [image: >>> youtube logo] [image: >>> LinkedIn logo] [image: >>> Facebook logo] [image: >>> Google+ logo] [imag= e: >>> slideshare logo] [image: >>> flipboard logo] [image: rss feed icon] >>> [image: Register for Cloud Identity Summit 2014 | Modern Identity >>> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >>> >>> >> >> >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> > --001a11c2d9c0ee88de04f98780c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think having a limit is much better (to increas= e compatibility) than not having one. =C2=A0If servers code developers will= have to make a decision on the length they should accept and they'll a= ll select a different one and cause issues.

Of course the browser URL size have limits and having m= uch larger than 128 octets is not improving the security much.
Thanks

Naveen



On Fri,= May 16, 2014 at 9:32 AM, Brian Campbell <bcampbell@pingidentity.= com> wrote:
Yeah, I agree with John her= e. There are a few good reasons to restrict the length of the code_challeng= e. One is trying to keep the authorization request URI to reasonable size a= s it will eventually run into various limits on clients and/or servers. The= other is constraining the amount of data that an AS needs to store per cod= e.




On Fri, May 16, 2014 at 7:41 AM, J= ohn Bradley <ve7jtb@ve7jtb.com> wrote:
From the= AS side you probably want to know what the max size you need to store per = code.

On the call to the token endpoint it is a POST so size = should not be an issue. =C2=A0


On May 16, 2014, at 3:10 PM, Nat Sakimura <sakimura@gmail.com> wrote= :

Now that I cannot remember w= hat limit we were hitting, it might be a good idea to remove the constraint= and see if anyone protests.=C2=A0

What do you think?=C2= =A0

Nat


2014-05-14 20= :46 GMT+09:00 Brian Campbell <bcampbell@pingidentity.com><= /span>:
That too would suggest that= the length limit be on code_challenge because that's the parameter tha= t will be on URIs getting passed around. The code_verifier is sent directly= in the POST body from client to AS.


On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura <sakimura@gmail.com= > wrote:
+1 for octet. We used to ha= ve "bytes" in JW* so I used "bytes" here, while at the = same time complaining in Jose that it should be "octet". JW* chan= ged to "octet" but I failed to sync with it in the last few edits= .=C2=A0

I do not quite remember which platform, but the reason for t= he limit was that some platform had some limitations as to the length of th= e sting to be passed to it through URI and we did not want the challenges t= o be truncated by that limit.=C2=A0

Best,=C2=A0

Nat


2014-05-13 6:56 = GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:

And it'd give the AS so= me direct guidance on protecting itself from crazy long code_challenge valu= es rather than relying on the client not to do something creative.


On Mon, May 12, 2014 at 3:54 PM, Brian Campb= ell <bcampbell@pingidentity.com> wrote:
Right but that's why I'm asking why not just put t= he limit on code_challange rather than inferring it from code_verifyer + ch= allenge algorithm, which probably bounds it but doesn't necessarily do = so? It's not a big deal but would read more clearly, I think.


On= Mon, May 12, 2014 at 3:48 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I think octets is more consistent with other= JW* and OAuth specs.

The code_challange is the same length as the code_verifyer or is a hash of = the code_verifyer so likely smaller than 128octets (43 ish for base64 256 b= it)

Limiting the code_verifyer size sets the upper bound for code_challange, un= less someone comes up with a really creative code challenge algorithm.

I will talk to nat about changing it to octets when I see him tomorrow.

John B.

On May 12, 2014, at 11:15 PM, Derek Atkins <warlord@MIT.EDU> wrote:

> Brian Campbell <bcampbell@pingidentity.com> writes:
>
>> I notice that code_verifier is defined as "high entropy crypt= ographic random
>> string of length less than 128 bytes" =C2=A0[1], which brough= t a few questions and
>> comments to mind. So here goes:
>>
>> Talking about the length of a string in terms of bytes is always p= otentially
>> confusing. Maybe characters would be an easier unit for people lik= e me to wrap
>> their little brains around?
>
> It depends if it really is characters or bytes. =C2=A0For example ther= e are
> many multi-byte UTF-8 characters, so if it really is bytes then saying=
> characters is wrong because it could overflow. =C2=A0So let's make= sure we
> know what we're talking about. =C2=A0Historically, if we're ta= lking bytes the
> IETF often uses the phrase "octets". =C2=A0Would that be les= s confusing?
>
>> Why are we putting a length restriction on the code_verifier anywa= y? It seems
>> like it'd be more appropriate to restrict the length of the co= de_challenge
>> because that's the thing the AS will have to maintain somehow = (store in a DB
>> or memory or encrypt into the code). Am I missing something here?<= br> >>
>> Let me also say that I hadn't looked at this document since it= s early days in
>> draft -00 or -01 last summer but I like the changes and how it'= ;s been kept
>> pretty simple for the common use-case while still allowing for cry= pto agility/
>> extension. Nice work!
>>
>> [1] http://tools.ietf.org/html/draft-sakimu= ra-oauth-tcse-03#section-3.3
>
> -derek
>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>
> --
> =C2=A0 =C2=A0 =C2=A0 Derek Atkins, SB '93 MIT EE, SM '95 MIT M= edia Laboratory
> =C2=A0 =C2=A0 =C2=A0 Member, MIT Student Information Processing Board = =C2=A0(SIPB)
> =C2=A0 =C2=A0 =C2=A0 URL: http://web.mit.edu/warlord/ =C2=A0 =C2=A0PP-ASEL-IA =C2= =A0 =C2=A0 N1NWH
> =C2=A0 =C2=A0 =C2=A0 warlord@MIT.EDU =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PGP key available




--
3D"Ping =09
Brian Campbell
Portfolio Architec= t
=09
@ bc= ampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register




--
3D"Ping =09
Brian Campbell
Portfolio Architec= t
=09
@ bc= ampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register


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




--
Nat Sakimura (=3Dnat)
Chairman, OpenI= D Foundation
http= ://nat.sakimura.org/
@_nat_en



--
3D"Ping =09
Brian Campbell
Portfolio Architec= t
=09
@ bc= ampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register




--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en



--001a11c2d9c0ee88de04f98780c0-- From nobody Fri May 16 14:27:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39ECC1A0248 for ; Fri, 16 May 2014 14:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 aAVMdBsfdJ7O for ; Fri, 16 May 2014 14:27:30 -0700 (PDT) Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 977D41A0157 for ; Fri, 16 May 2014 14:27:29 -0700 (PDT) Received: from [66.196.81.170] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 16 May 2014 21:27:21 -0000 Received: from [98.139.212.240] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 16 May 2014 21:27:21 -0000 Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 16 May 2014 21:27:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 378744.73708.bm@omp1049.mail.bf1.yahoo.com Received: (qmail 90411 invoked by uid 60001); 16 May 2014 21:27:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1400275641; bh=06EFPWT1hvQ2iagOC5SSLF2KgDZd+nGa0ySz2Me6RTs=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0n1t5qrysrafnt8xWvKIploB7zScKLogM6nfy5AC76ER2TZfL+8Aa2plgfPEheC/Ujn+REsnFpKABEFZLpCIksZHpcW0Yxz9f+lGKXNuxlW2FAyfJEZ5Cvirg9w7fDDioQIhDfwCJHRIUhQDEeAQ4HZidHmfXWNDhHUbMkNycVw= X-YMail-OSG: IYGueooVM1myaY78c7txIJMK2N9AzonCz0g5IGxL9cTUitw sfSdXAm8l0.J0VDhbfHS93etKHEcYmnVuItcAjAkwYwOMdhy38fME5yU2bA3 WHNsiGbpVSiE_MjESROfAjA0XFa1p3rgHfgYsqy5S25EV615JR434yX6f_QG .6DSb9xecPugpwWGey3WGgu0z0IQdfRCqG8jdDKH6qY6tiDmBZBeqKWQ_65Z Jra3mYz.kgj2hIxW8Mv.GYfP8bBlVc2q.HYnQFCY7JeFiJ7b9lr3KFUiGPoa giF1wOMo09zeTrNoQKkhFgxULNil0tuhPkSrrYSrGb9aFc9ev2SpxoMEqQgJ orQRQGhqZU_rU8Ht4NmVT3KeIvYkmEh2g2PdQYgkxDCdn_kyMn.YeBtajYue oUZpxaE2K4BsXIBxd3zkJ18gW4vm_BOIcjjdi_E33gKainF070WoTVEAIZ7E o4Gan9rAHgxYbSyLzhhya0wPziKWi42AullSAA3T2ql1MUhm7N_jJLQkiF51 vJRF4xVwBNz4BgFPn0UWYiwhzk3NqVkAwgmLD3Bg7wMVGVOdQx.5XHm4my7j aHk9ZQxMlLgHjPM0KMq9I3Q2w9qEoEXQFqPvSrqj8d3FzKbsTPmTPkRt_PXZ OJi8dvw-- Received: from [209.131.62.113] by web142803.mail.bf1.yahoo.com via HTTP; Fri, 16 May 2014 14:27:21 PDT X-Rocket-MIMEInfo: 002.001, VGhlIEhUVFAgc3BlY3MgZG9uJ3QgbGltaXQgdGhlc2UgdGhpbmdzLCBidXQgaW1wbGVtZW50YXRpb25zIGRvLCBhbmQgdGhlIHByb2JsZW1zIHdoZW4geW91IHJ1biBpbnRvIHRoZW0gYXJlIGEgcmVhIHBhaW4uCgpETyB3ZSB3YW50IHRvIG1ha2UgdGhpcyBhIGhhcmQgbGltaXQsIG9yIHNob3VsZCBpdCBiZSBndWlkYW5jZSBpbiB0aGUgZm9ybSBvZiBSRUNPTU1FTkRFRCBvciBTSE9VTEQ_CgoKT24gRnJpZGF5LCBNYXkgMTYsIDIwMTQgOTozNSBBTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> Message-ID: <1400275641.37471.YahooMailNeo@web142803.mail.bf1.yahoo.com> Date: Fri, 16 May 2014 14:27:21 -0700 (PDT) From: Bill Mills To: Brian Campbell , John Bradley In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="905790552-1123540662-1400275641=:37471" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/hsKG14g5R3dSSWmk9JJSYfzr8KY Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 21:27:33 -0000 --905790552-1123540662-1400275641=:37471 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The HTTP specs don't limit these things, but implementations do, and the pr= oblems when you run into them are a rea pain.=0A=0ADO we want to make this = a hard limit, or should it be guidance in the form of RECOMMENDED or SHOULD= ?=0A=0A=0AOn Friday, May 16, 2014 9:35 AM, Brian Campbell wrote:=0A =0AYeah, I agree with John here. There are a few good= reasons to restrict the length of the code_challenge. One is trying to kee= p the authorization request URI to reasonable size as it will eventually ru= n into various limits on clients and/or servers. The other is constraining = the amount of data that an AS needs to store per code.=0A=0A=0A=0A=0A=0A=0A= On Fri, May 16, 2014 at 7:41 AM, John Bradley wrote:=0A= =0AFrom the AS side you probably want to know what the max size you need to= store per code.=0A>=0A>=0A>=0A>On the call to the token endpoint it is a P= OST so size should not be an issue. =C2=A0=0A>=0A>=0A>=0A>=0A>On May 16, 20= 14, at 3:10 PM, Nat Sakimura wrote:=0A>=0A>Now that I = cannot remember what limit we were hitting, it might be a good idea to remo= ve the constraint and see if anyone protests.=C2=A0=0A>>=0A>>=0A>>What do y= ou think?=C2=A0=0A>>=0A>>=0A>>Nat=0A>>=0A>>=0A>>=0A>>2014-05-14 20:46 GMT+0= 9:00 Brian Campbell :=0A>>=0A>>That too would s= uggest that the length limit be on code_challenge because that's the parame= ter that will be on URIs getting passed around. The code_verifier is sent d= irectly in the POST body from client to AS. =0A>>>=0A>>>=0A>>>=0A>>>=0A>>>O= n Tue, May 13, 2014 at 12:52 AM, Nat Sakimura wrote:= =0A>>>=0A>>>+1 for octet. We used to have "bytes" in JW* so I used "bytes" = here, while at the same time complaining in Jose that it should be "octet".= JW* changed to "octet" but I failed to sync with it in the last few edits.= =C2=A0=0A>>>>=0A>>>>=0A>>>>I do not quite remember which platform, but the = reason for the limit was that some platform had some limitations as to the = length of the sting to be passed to it through URI and we did not want the = challenges to be truncated by that limit.=C2=A0=0A>>>>=0A>>>>=0A>>>>Best,= =C2=A0=0A>>>>=0A>>>>=0A>>>>Nat=0A>>>>=0A>>>>=0A>>>>=0A>>>>2014-05-13 6:56 G= MT+09:00 Brian Campbell :=0A>>>>=0A>>>>=0A>>>>A= nd it'd give the AS some direct guidance on protecting itself from crazy lo= ng code_challenge values rather than relying on the client not to do someth= ing creative. =0A>>>>>=0A>>>>>=0A>>>>>=0A>>>>>=0A>>>>>On Mon, May 12, 2014 = at 3:54 PM, Brian Campbell wrote:=0A>>>>>=0A>>= >>>Right but that's why I'm asking why not just put the limit on code_chall= ange rather than inferring it from code_verifyer + challenge algorithm, whi= ch probably bounds it but doesn't necessarily do so? It's not a big deal bu= t would read more clearly, I think.=0A>>>>>>=0A>>>>>>=0A>>>>>>=0A>>>>>>=0A>= >>>>>On Mon, May 12, 2014 at 3:48 PM, John Bradley wrot= e:=0A>>>>>>=0A>>>>>>I think octets is more consistent with other JW* and OA= uth specs.=0A>>>>>>>=0A>>>>>>>The code_challange is the same length as the = code_verifyer or is a hash of the code_verifyer so likely smaller than 128o= ctets (43 ish for base64 256 bit)=0A>>>>>>>=0A>>>>>>>Limiting the code_veri= fyer size sets the upper bound for code_challange, unless someone comes up = with a really creative code challenge algorithm.=0A>>>>>>>=0A>>>>>>>I will = talk to nat about changing it to octets when I see him tomorrow.=0A>>>>>>>= =0A>>>>>>>John B.=0A>>>>>>>=0A>>>>>>>=0A>>>>>>>On May 12, 2014, at 11:15 PM= , Derek Atkins wrote:=0A>>>>>>>=0A>>>>>>>> Brian Campbell= writes:=0A>>>>>>>>=0A>>>>>>>>> I notice that = code_verifier is defined as "high entropy cryptographic random=0A>>>>>>>>> = string of length less than 128 bytes" =C2=A0[1], which brought a few questi= ons and=0A>>>>>>>>> comments to mind. So here goes:=0A>>>>>>>>>=0A>>>>>>>>>= Talking about the length of a string in terms of bytes is always potential= ly=0A>>>>>>>>> confusing. Maybe characters would be an easier unit for peop= le like me to wrap=0A>>>>>>>>> their little brains around?=0A>>>>>>>>=0A>>>= >>>>> It depends if it really is characters or bytes. =C2=A0For example the= re are=0A>>>>>>>> many multi-byte UTF-8 characters, so if it really is byte= s then saying=0A>>>>>>>> characters is wrong because it could overflow. =C2= =A0So let's make sure we=0A>>>>>>>> know what we're talking about. =C2=A0Hi= storically, if we're talking bytes the=0A>>>>>>>> IETF often uses the phras= e "octets". =C2=A0Would that be less confusing?=0A>>>>>>>>=0A>>>>>>>>> Why = are we putting a length restriction on the code_verifier anyway? It seems= =0A>>>>>>>>> like it'd be more appropriate to restrict the length of the co= de_challenge=0A>>>>>>>>> because that's the thing the AS will have to maint= ain somehow (store in a DB=0A>>>>>>>>> or memory or encrypt into the code).= Am I missing something here?=0A>>>>>>>>>=0A>>>>>>>>> Let me also say that = I hadn't looked at this document since its early days in=0A>>>>>>>>> draft = -00 or -01 last summer but I like the changes and how it's been kept=0A>>>>= >>>>> pretty simple for the common use-case while still allowing for crypto= agility/=0A>>>>>>>>> extension. Nice work!=0A>>>>>>>>>=0A>>>>>>>>> [1] htt= p://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3=0A>>>>>>>>= =0A>>>>>>>> -derek=0A>>>>>>>>=0A>>>>>>>>> _________________________________= ______________=0A>>>>>>>>> OAuth mailing list=0A>>>>>>>>> OAuth@ietf.org=0A= >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth=0A>>>>>>>>=0A>>>>>>>>= --=0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 Derek Atkins, SB '93 MIT EE, SM '95 MIT= Media Laboratory=0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 Member, MIT Student Infor= mation Processing Board =C2=A0(SIPB)=0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 URL: h= ttp://web.mit.edu/warlord/ =C2=A0 =C2=A0PP-ASEL-IA =C2=A0 =C2=A0 N1NWH=0A>>= >>>>>> =C2=A0 =C2=A0 =C2=A0 warlord@MIT.EDU =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PGP key available=0A>>>= >>>>=0A>>>>>>>=0A>>>>>>=0A>>>>>>=0A>>>>>>=0A>>>>>>-- =0A>>>>>>=0A>>>>>> Bri= an Campbell=0A>>>>>>Portfolio Architect=0A>>>>>>@ bcampbell@pingidentity.co= m =0A>>>>>> +1 720.317.2061 =0A>>>>>>Connect with us=E2=80=A6 =0A= >>>>>>=0A>>>>>=0A>>>>>=0A>>>>>-- =0A>>>>>=0A>>>>> Brian Campbell=0A>>>>>Por= tfolio Architect=0A>>>>>@ bcampbell@pingidentity.com =0A>>>>> +1 720.317.20= 61 =0A>>>>>Connect with us=E2=80=A6 =0A>>>>>=0A>>>>>_____________= __________________________________=0A>>>>>OAuth mailing list=0A>>>>>OAuth@i= etf.org=0A>>>>>https://www.ietf.org/mailman/listinfo/oauth=0A>>>>>=0A>>>>>= =0A>>>>=0A>>>>=0A>>>>=0A>>>>-- =0A>>>>Nat Sakimura (=3Dnat)=0A>>>>Chairman,= OpenID Foundation=0A>>>>http://nat.sakimura.org/=0A>>>>@_nat_en=0A>>>=0A>>= >=0A>>>-- =0A>>>=0A>>> Brian Campbell=0A>>>Portfolio Architect=0A>>>@ bcamp= bell@pingidentity.com =0A>>> +1 720.317.2061 =0A>>>Connect with us=E2=80=A6= =0A>>>=0A>>=0A>>=0A>>=0A>>-- =0A>>Nat Sakimura (=3Dnat)=0A>>Chai= rman, OpenID Foundation=0A>>http://nat.sakimura.org/=0A>>@_nat_en=0A>=0A=0A= =0A_______________________________________________=0AOAuth mailing list=0AO= Auth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --905790552-1123540662-1400275641=:37471 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The HTTP specs don't limit these things, but imple= mentations do, and the problems when you run into them are a rea pain.

DO we want to make = this a hard limit, or should it be guidance in the form of RECOMMENDED or S= HOULD?

On Friday, May 16, 2014 9:35 AM, Brian Campbell <bcampbell@pingi= dentity.com> wrote:
<= div id=3D"yiv0673148450">
Yeah, I agree with John here= . There are a few good reasons to restrict the length of the code_challenge= . One is trying to keep the authorization request URI to reasonable size as= it will eventually run into various limits on clients and/or servers. The = other is constraining the amount of data that an AS needs to store per code= .
=0A=0A



On Fri, May 16, 2014 at 7:41 AM, John Bra= dley <ve7jtb@ve7jtb.com> wrote:
=0A=0A
Fro= m the AS side you probably want to know what the max size you need to store= per code.
=0A=0A

On th= e call to the token endpoint it is a POST so size should not be an issue. &= nbsp;


On May 16, 2014, at 3:10 PM,= Nat Sakimura <sakimu= ra@gmail.com> wrote:
=0A=0A
Now that I cannot remember what limit we were hi= tting, it might be a good idea to remove the constraint and see if anyone p= rotests. 

What do you think? =0A
=0A
Nat
=0A


2014-05-14 20:46 GMT+09:00 Brian Campbell = <bcampbell@pingidentity.com>:
= =0A=0A=0A
That= too would suggest that the length limit be on code_challenge because that'= s the parameter that will be on URIs getting passed around. The code_verifi= er is sent directly in the POST body from client to AS.
= =0A=0A=0A=0A=0A


O= n Tue, May 13, 2014 at 12:52 AM, Nat Sakimura <sakimura@gmail.com> wrote:
=0A=0A=0A=0A=0A
+1 for octet. We used to have "bytes" in J= W* so I used "bytes" here, while at the same time complaining in Jose that = it should be "octet". JW* changed to "octet" but I failed to sync with it i= n the last few edits. 
=0A=0A=0A=0A=0A=0A
=
I do not quite remember which platform, but the reason for the limit w= as that some platform had some limitations as to the length of the sting to= be passed to it through URI and we did not want the challenges to be trunc= ated by that limit. 
=0A=0A=0A=0A=0A=0A

Best, 

Nat


2014-05-13 6:56 GMT+09:00 Brian= Campbell <bcampbell@pingidentity.com>:
=0A= =0A=0A=0A=0A

=0A
And it'd give the AS some direct guidance on prot= ecting itself from crazy long code_challenge values rather than relying on = the client not to do something creative.
=0A=0A=0A=0A=0A= =0A

= =0A=0A
On Mon, Ma= y 12, 2014 at 3:54 PM, Brian Campbell <bcampbell@pingidentity.= com> wrote:
=0A=0A=0A=0A=0A=0A=0A=0A
Right but that's why= I'm asking why not just put the limit on code_challange rather than inferr= ing it from code_verifyer + challenge algorithm, which probably bounds it b= ut doesn't necessarily do so? It's not a big deal but would read more clear= ly, I think.
=0A=0A=0A=0A=0A=0A=0A=0A=0A


On Mon, May 12, 2014 at 3:48 PM, John= Bradley <ve7jtb@ve7jtb.com> wrote:
=0A=0A=0A= =0A=0A=0A=0A=0A=0A
I think octe= ts is more consistent with other JW* and OAuth specs.
=0A=
=0AThe code_challange is the same length as the code_ver= ifyer or is a hash of the code_verifyer so likely smaller than 128octets (4= 3 ish for base64 256 bit)
=0A
=0ALimiti= ng the code_verifyer size sets the upper bound for code_challange, unless s= omeone comes up with a really creative code challenge algorithm.
=0A
=0AI will talk to nat about changing it to = octets when I see him tomorrow.
=0A
=0A= John B.
=0A

=0AOn May 12, 2014, at= 11:15 PM, Derek Atkins <wa= rlord@MIT.EDU> wrote:
=0A
=0A>= ; Brian Campbell <bcampbell@pingidentity.com> writes:
= =0A>
=0A>> I notice that code_verifier is define= d as "high entropy cryptographic random
=0A>> strin= g of length less than 128 bytes"  [1], which brought a few questions a= nd
=0A>> comments to mind. So here goes:
=0A>>
=0A>> Talking about the lengt= h of a string in terms of bytes is always potentially
=0A= >> confusing. Maybe characters would be an easier unit for people lik= e me to wrap
=0A>> their little brains around?
=0A>
=0A> It depends if it really is = characters or bytes.  For example there are
=0A> = many multi-byte UTF-8 characters, so if it really is bytes then saying
=0A> characters is wrong because it could overflow.  = So let's make sure we
=0A> know what we're talking abo= ut.  Historically, if we're talking bytes the
=0A>= ; IETF often uses the phrase "octets".  Would that be less confusing?<= br clear=3D"none">=0A>
=0A>> Why are we putting = a length restriction on the code_verifier anyway? It seems
=0A>> like it'd be more appropriate to restrict the length of the c= ode_challenge
=0A>> because that's the thing the AS= will have to maintain somehow (store in a DB
=0A>>= or memory or encrypt into the code). Am I missing something here?
=0A>>
=0A>> Let me also say that I = hadn't looked at this document since its early days in
= =0A>> draft -00 or -01 last summer but I like the changes and how it'= s been kept
=0A>> pretty simple for the common use-= case while still allowing for crypto agility/
=0A>>= extension. Nice work!
=0A>>
=0A&= gt;> [1] http://t= ools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3
=0A>
=0A> -derek
=0A>=0A>> ______________________________________________= _
=0A>> OAuth mailing list
=0A>= ;> OAuth@ietf.org
=0A>> https://www.ietf.org/= mailman/listinfo/oauth
=0A>
=0A&= gt; --
=0A>       Derek Atkins, SB '93 = MIT EE, SM '95 MIT Media Laboratory
=0A>    =   Member, MIT Student Information Processing Board  (SIPB)
=0A>       URL: http://web.mi= t.edu/warlord/    PP-ASEL-IA     N1NWH
=0A>       warlord@MIT.EDU               &= nbsp;        PGP key available
=0A=0A



--
= =0A=0A
=0A=09
=0A=09=09=09=09=093D"Ping=0A=09=09=09=09=09=0A=09=09=09=09=09
=0A=09=09=09=09=09=09Brian Campbell
Portfolio Architect
=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=09=09=09=09=09<= td colspan=3D"1" rowspan=3D"1" style=3D"text-align:center;border-right:1px = solid #e61d3c;padding:0 5px 0 0;">=0A=09=09=09=09=09=09=09=09=09@
=0A=09=09=09=09=09=09=09= =09=09b= campbell@pingidentity.com
=0A=09=09=09=09=09=09=09=09=093D"ph==0A=09=09=09=09=09=09= =09=09=09+1 720.317.2061<= /span>
=0A=09=09=09=09=09=09=09=09= =09Connect with us=E2=80=A6
= =0A=09=09=09=09=09=09=09=09=093D"twitter 3D"youtube= = 3D"LinkedIn 3D"Facebook =3D"Google+= 3D"slideshare 3D"fl= <= a rel=3D"nofollow" shape=3D"rect" target=3D"_blank" href=3D"https://www.pin= gidentity.com/blogs/" style=3D"text-decoration:none;" title=3D"Ping blogs">= 3D"rss
=0A=09=09=09=09
=0A=
=0A=0A
=0A=09=0A=0A
=0A=0A


--
=0A=0A
=0A=09
=0A=09=09=09=09=093D"Register
=0A= =09=09=09=09=093D==0A=09=09=09=09=09=0A=09=09=09= =09=09
=0A=09=09=09=09=09=09Brian Campbell
Por= tfolio Architect
=0A=0A=0A=0A=0A=0A=0A=0A=0A=09=09=09=09= =09<= tr>= =0A=09=09=09=09=09=09=09=09=09<= span style=3D"font-size:14px;">+1 720.317.2061
=0A=09=09=09=09=09= =09=09=09=09@=0A= =09=09=09=09=09=09=09=09=09bcampbell@pingidentity.com
=0A=09=09=09=09=09=09= =09=09=093D"phone"
=0A=09= =09=09=09=09=09=09=09=09Connect with us=E2=80=A6
=0A=09=09=09=09=09=09=09=09=093D"twitter 3D"LinkedIn 3D"Facebook =3D"Google+= 3D"slideshare 3D"fl= <= a rel=3D"nofollow" shape=3D"rect" target=3D"_blank" href=3D"https://www.pin= gidentity.com/blogs/" style=3D"text-decoration:none;" title=3D"Ping blogs">= 3D"rss
=0A=09=09=09=09
=0A=
=0A=0A
=0A=09=0A=0A
=0A=0A
_______________________________________________
=0AOAu= th mailing list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/oauth
=0A
=


=
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foun= dation
http://nat.sakimura.org/
=0A=0A=0A=0A=0A@_nat_en
=0A=0A


--
=0A=0A
=0A= =09
=0A=09=09=09=09=093D"Register
=0A=09=09= =09=09=093D"Ping=0A=09=09=09=09=09=0A=09=09=09=09=09<= div style=3D"margin-bottom:7px;">=0A=09=09=09=09=09=09Brian Campbell
Portfolio= Architect=0A=0A=0A=0A=0A=0A=09=09=09=09=09
=0A=09=09=09=09=09=09=09=09=09@=0A=09=09=09=09=09= =09=09=09=09bcampbell@pingidentity.com
=0A=09=09=09=09=09=09=09=09=09=0A=09=09=09=09= =09=09=09=09=09+1 720.317.206= 1
=0A=09=09=09=09=09=09= =09=09=09Connect with us=E2=80=A6
=0A=09=09=09=09=09=09=09=09=093D"twitter 3D"you= 3D"LinkedIn 3D"Facebook =3D"Google+= 3D"slideshare 3D"fl= <= a rel=3D"nofollow" shape=3D"rect" target=3D"_blank" href=3D"https://www.pin= gidentity.com/blogs/" style=3D"text-decoration:none;" title=3D"Ping blogs">= 3D"rss
=0A=09=09=09=09
=0A=
=0A=0A
=0A=09=0A=0A
=0A=0A


--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundatio= n
http://nat.sakimura.org/
@_nat_en
=0A=0A=0A=0A
=0A


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

=
--905790552-1123540662-1400275641=:37471-- From nobody Tue May 20 05:10:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999B91A0346 for ; Tue, 20 May 2014 05:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 KfpbNcEWknLr for ; Tue, 20 May 2014 05:10:15 -0700 (PDT) Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016BE1A06D9 for ; Tue, 20 May 2014 05:10:14 -0700 (PDT) Received: from mail-ig0-f174.google.com ([209.85.213.174]) (using TLSv1) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKU3tGJipuN6NFFoNbaXJkQQy/MvK1a4qX@postini.com; Tue, 20 May 2014 05:10:14 PDT Received: by mail-ig0-f174.google.com with SMTP id h3so4746102igd.7 for ; Tue, 20 May 2014 05:10:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3C7KEym3fEuDIkTn/K0AwDhF+5+Ni/+qKdsya31duNo=; b=gIAyRhK8pSwoyvBpQBk3SSJ+eH9p0rRCbhk2bEZdtDSeeCdpf3uZ0Cqm6L+MSFIdfs o8u9YjbLNsOx7eqo0PCReP+LmdlrWs/GjAj+SBmh1nCC6mPEa6oa/Go05iJo+2ekHk21 3AecqO7SGxrKKX7e9mCeYNtIJFLFcJ8dLycOy2Bwc1LD+pW3t8ZYzUYUzkvRrI+k02yJ nfpv2vMTbojz1hlDAv2TdDE472kN3MN6Gsn/aaX57qVu91mPPgks3hy7Nw0WoJJvxeAN 0iUPkxyI23zDagOvm/3GQWgWmQshz1kOEDHlLdmM+ZtOF2O3VWC/RcjJOKMKBTKyGihq hDOw== X-Gm-Message-State: ALoCoQlHN4KKrhNw1kXdnkV2U9lYjsIoyOOsoI0Zy6Ah9V1W6Vy4CUr08J/bwnSfa2PHdWBfW3G44s96CN3UQlLGZgWlUMQ4kKnQo1wQh2Zqr48MoBf3TFXdxKXAjxZwF/2TNAts7COL X-Received: by 10.42.52.199 with SMTP id k7mr40205444icg.4.1400587813995; Tue, 20 May 2014 05:10:13 -0700 (PDT) X-Received: by 10.42.52.199 with SMTP id k7mr40205418icg.4.1400587813819; Tue, 20 May 2014 05:10:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Tue, 20 May 2014 05:09:43 -0700 (PDT) In-Reply-To: <1400275641.37471.YahooMailNeo@web142803.mail.bf1.yahoo.com> References: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> <1400275641.37471.YahooMailNeo@web142803.mail.bf1.yahoo.com> From: Brian Campbell Date: Tue, 20 May 2014 06:09:43 -0600 Message-ID: To: Bill Mills Content-Type: multipart/alternative; boundary=485b397dd6091eaca304f9d3c340 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/g_ehOv4UQJLnNDwMxCiKaC1wVgk Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 12:10:26 -0000 --485b397dd6091eaca304f9d3c340 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd say it should be a MUST so that implementations are consistent about it= . On Fri, May 16, 2014 at 3:27 PM, Bill Mills wrote: > The HTTP specs don't limit these things, but implementations do, and the > problems when you run into them are a rea pain. > > DO we want to make this a hard limit, or should it be guidance in the for= m > of RECOMMENDED or SHOULD? > > On Friday, May 16, 2014 9:35 AM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > Yeah, I agree with John here. There are a few good reasons to restrict > the length of the code_challenge. One is trying to keep the authorization > request URI to reasonable size as it will eventually run into various > limits on clients and/or servers. The other is constraining the amount of > data that an AS needs to store per code. > > > > > On Fri, May 16, 2014 at 7:41 AM, John Bradley wrote: > > From the AS side you probably want to know what the max size you need to > store per code. > > On the call to the token endpoint it is a POST so size should not be an > issue. > > > On May 16, 2014, at 3:10 PM, Nat Sakimura wrote: > > Now that I cannot remember what limit we were hitting, it might be a good > idea to remove the constraint and see if anyone protests. > > What do you think? > > Nat > > > 2014-05-14 20:46 GMT+09:00 Brian Campbell : > > That too would suggest that the length limit be on code_challenge because > that's the parameter that will be on URIs getting passed around. The > code_verifier is sent directly in the POST body from client to AS. > > > On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura wrote= : > > +1 for octet. We used to have "bytes" in JW* so I used "bytes" here, whil= e > at the same time complaining in Jose that it should be "octet". JW* chang= ed > to "octet" but I failed to sync with it in the last few edits. > > I do not quite remember which platform, but the reason for the limit was > that some platform had some limitations as to the length of the sting to = be > passed to it through URI and we did not want the challenges to be truncat= ed > by that limit. > > Best, > > Nat > > > 2014-05-13 6:56 GMT+09:00 Brian Campbell : > > And it'd give the AS some direct guidance on protecting itself from crazy > long code_challenge values rather than relying on the client not to do > something creative. > > > On Mon, May 12, 2014 at 3:54 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > > Right but that's why I'm asking why not just put the limit on > code_challange rather than inferring it from code_verifyer + challenge > algorithm, which probably bounds it but doesn't necessarily do so? It's n= ot > a big deal but would read more clearly, I think. > > > On Mon, May 12, 2014 at 3:48 PM, John Bradley wrote: > > I think octets is more consistent with other JW* and OAuth specs. > > The code_challange is the same length as the code_verifyer or is a hash o= f > the code_verifyer so likely smaller than 128octets (43 ish for base64 256 > bit) > > Limiting the code_verifyer size sets the upper bound for code_challange, > unless someone comes up with a really creative code challenge algorithm. > > I will talk to nat about changing it to octets when I see him tomorrow. > > John B. > > On May 12, 2014, at 11:15 PM, Derek Atkins wrote: > > > Brian Campbell writes: > > > >> I notice that code_verifier is defined as "high entropy cryptographic > random > >> string of length less than 128 bytes" [1], which brought a few > questions and > >> comments to mind. So here goes: > >> > >> Talking about the length of a string in terms of bytes is always > potentially > >> confusing. Maybe characters would be an easier unit for people like me > to wrap > >> their little brains around? > > > > It depends if it really is characters or bytes. For example there are > > many multi-byte UTF-8 characters, so if it really is bytes then saying > > characters is wrong because it could overflow. So let's make sure we > > know what we're talking about. Historically, if we're talking bytes th= e > > IETF often uses the phrase "octets". Would that be less confusing? > > > >> Why are we putting a length restriction on the code_verifier anyway? I= t > seems > >> like it'd be more appropriate to restrict the length of the > code_challenge > >> because that's the thing the AS will have to maintain somehow (store i= n > a DB > >> or memory or encrypt into the code). Am I missing something here? > >> > >> Let me also say that I hadn't looked at this document since its early > days in > >> draft -00 or -01 last summer but I like the changes and how it's been > kept > >> pretty simple for the common use-case while still allowing for crypto > agility/ > >> extension. Nice work! > >> > >> [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.= 3 > > > > -derek > > > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > warlord@MIT.EDU PGP key available > > > > > -- > [image: Ping Identity logo] > Brian Campbell > Portfolio Architect > @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with > us=E2=80=A6 [image: twitter logo] [ima= ge: > youtube logo] [image: > LinkedIn logo] [image: Facebook > logo] [image: Google+ logo] [image: > slideshare logo] [image: > flipboard logo] [image: rss feed icon] > [image: Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] > > > > > -- > [image: Ping Identity logo] > Brian Campbell > Portfolio Architect > @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with > us=E2=80=A6 [image: twitter logo] [ima= ge: > youtube logo] [image: > LinkedIn logo] [image: Facebook > logo] [image: Google+ logo] [image: > slideshare logo] [image: > flipboard logo] [image: rss feed icon] > [image: Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] > > > _______________________________________________ > 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 > > > > > -- > [image: Ping Identity logo] > Brian Campbell > Portfolio Architect > @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with > us=E2=80=A6 [image: twitter logo] [ima= ge: > youtube logo] [image: > LinkedIn logo] [image: Facebook > logo] [image: Google+ logo] [image: > slideshare logo] [image: > flipboard logo] [image: rss feed icon] > [image: Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] > > > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --485b397dd6091eaca304f9d3c340 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd say it should be a MUST so that implementations ar= e consistent about it.


On Fri, May 16, 2014 at 3:27 PM, Bill Mills <wmill= s_92105@yahoo.com> wrote:
The HTTP specs don't limit these things, but implementations= do, and the problems when you run into them are a rea pain.

= DO we want to make this a hard limit, or should it be guidance in the form = of RECOMMENDED or SHOULD?

On Friday, May 16, 2014 9:35 AM, B= rian Campbell <bcampbell@pingidentity.com> wrote:
<= div>
Yeah, I agree with John here. There are a few good re= asons to restrict the length of the code_challenge. One is trying to keep t= he authorization request URI to reasonable size as it will eventually run i= nto various limits on clients and/or servers. The other is constraining the= amount of data that an AS needs to store per code.



On Fri, May 16, 2014 at 7:41 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
From the AS side you probably = want to know what the max size you need to store per code.

On the call to the token endpoint it is = a POST so size should not be an issue. =C2=A0


On May 16, 201= 4, at 3:10 PM, Nat Sakimura <sakimura@gmail.com> wro= te:

Now that I ca= nnot remember what limit we were hitting, it might be a good idea to remove= the constraint and see if anyone protests.=C2=A0

What do you think?=C2=A0

Nat


2014-05-14 20:46 GMT+09:00 = Brian Campbell <bcampbell@pingide= ntity.com>:
That too would suggest that the length limit be o= n code_challenge because that's the parameter that will be on URIs gett= ing passed around. The code_verifier is sent directly in the POST body from= client to AS.


On Tue, May= 13, 2014 at 12:52 AM, Nat Sakimura <saki= mura@gmail.com> wrote:
+1 for octet. We used to have "bytes" i= n JW* so I used "bytes" here, while at the same time complaining = in Jose that it should be "octet". JW* changed to "octet&quo= t; but I failed to sync with it in the last few edits.=C2=A0

I do not quite remember which platform, but t= he reason for the limit was that some platform had some limitations as to t= he length of the sting to be passed to it through URI and we did not want t= he challenges to be truncated by that limit.=C2=A0

Best,=C2=A0

Nat


= 2014-05-13 6:56 GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:

And it'd give the AS some direct guidance on = protecting itself from crazy long code_challenge values rather than relying= on the client not to do something creative.


On Mon, May 12, 2014 at 3:54 PM, Brian Campbell <bcampbell@pingidentity.com><= /span> wrote:
Right but that's why I'm asking why not just put t= he limit on code_challange rather than inferring it from code_verifyer + ch= allenge algorithm, which probably bounds it but doesn't necessarily do = so? It's not a big deal but would read more clearly, I think.


On Mon, May 12, = 2014 at 3:48 PM, John Bradley <ve7jtb@ve7j= tb.com> wrote:
I think octets is more consistent with other JW* and OAuth specs.<= br clear=3D"none">
The code_challange is the same length as the code_verifyer or is a hash of = the code_verifyer so likely smaller than 128octets (43 ish for base64 256 b= it)

Limiting the code_verifyer size sets the upper bound for code_challange, un= less someone comes up with a really creative code challenge algorithm.

I will talk to nat about changing it to octets when I see him tomorrow.

John B.

On May 12, 2014, at 11:15 PM, Derek Atkins <warlord@MIT.EDU> wrote:

> Brian Campbell <bcampbell@pingidentity.com= > writes:
>
>> I notice that code_verifier is defined as "high entropy crypt= ographic random
>> string of length less than 128 bytes" =C2=A0[1], which brough= t a few questions and
>> comments to mind. So here goes:
>>
>> Talking about the length of a string in terms of bytes is always p= otentially
>> confusing. Maybe characters would be an easier unit for people lik= e me to wrap
>> their little brains around?
>
> It depends if it really is characters or bytes. =C2=A0For example ther= e are
> many multi-byte UTF-8 characters, so if it really is bytes then saying=
> characters is wrong because it could overflow. =C2=A0So let's make= sure we
> know what we're talking about. =C2=A0Historically, if we're ta= lking bytes the
> IETF often uses the phrase "octets". =C2=A0Would that be les= s confusing?
>
>> Why are we putting a length restriction on the code_verifier anywa= y? It seems
>> like it'd be more appropriate to restrict the length of the co= de_challenge
>> because that's the thing the AS will have to maintain somehow = (store in a DB
>> or memory or encrypt into the code). Am I missing something here?<= br clear=3D"none"> >>
>> Let me also say that I hadn't looked at this document since it= s early days in
>> draft -00 or -01 last summer but I like the changes and how it'= ;s been kept
>> pretty simple for the common use-case while still allowing for cry= pto agility/
>> extension. Nice work!
>>
>> [1] http://= tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3
>
> -derek
>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listin= fo/oauth
>
> --
> =C2=A0 =C2=A0 =C2=A0 Derek Atkins, SB '93 MIT EE, SM '95 MIT M= edia Laboratory
> =C2=A0 =C2=A0 =C2=A0 Member, MIT Student Information Processing Board = =C2=A0(SIPB)
> =C2=A0 =C2=A0 =C2=A0 URL: http://web.mit.edu/warlord/ =C2=A0 =C2=A0PP-ASEL-IA =C2=A0 =C2=A0 N1NWH
> =C2=A0 =C2=A0 =C2=A0 warlord@MIT.EDU =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PGP key a= vailable




--
=0A=09=09=09=09=093D"Register
3D"Ping =09
Brian Campbell
Portfolio Architect
+1 720.317.2061
@ bcampbell@pingidentity.com<= /td>
3D"phone"
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Google+ 3D"slideshare 3D"flipboard =3D"rss
3D"Register




= --
3D"Ping =09
Brian Campbell
Portfolio Architect
+1 720.317.2061
@ bcampbell@pingidentity.com<= /td>
3D"phone"
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Google+ 3D"slideshare 3D"flipboard =3D"rss
3D"Register


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




--
Nat Sakimura (=3Dnat)



= --
3D"Ping =09
Brian Campbell
Portfolio Architect
+1 720.317.2061
@ bcampbell@pingidentity.com<= /td>
3D"phone"
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Google+ 3D"slideshare 3D"flipboard =3D"rss
3D"Register



--
Nat Sakimura (=3Dnat)
Chai= rman, OpenID Foundation
http://nat.sakimura.o= rg/
@_nat_en

=


_________________= ______________________________
OAuth mailing list
OAuth@ie= tf.org
https://www.ietf.org/mailman/lis= tinfo/oauth



--485b397dd6091eaca304f9d3c340-- From nobody Tue May 20 06:03:58 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7682C1A06DE for ; Tue, 20 May 2014 06:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 4zo1wvf3s4GA for ; Tue, 20 May 2014 06:03:54 -0700 (PDT) Received: from na3sys009aog133.obsmtp.com (na3sys009aog133.obsmtp.com [74.125.149.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B6C1A06DA for ; Tue, 20 May 2014 06:03:54 -0700 (PDT) Received: from mail-ie0-f171.google.com ([209.85.223.171]) (using TLSv1) by na3sys009aob133.postini.com ([74.125.148.12]) with SMTP ID DSNKU3tSudlZPt/XbfM+2ccaH20wZS6Sh3A9@postini.com; Tue, 20 May 2014 06:03:54 PDT Received: by mail-ie0-f171.google.com with SMTP id to1so389980ieb.16 for ; Tue, 20 May 2014 06:03:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WOyFPDrhyAixLDbadKsYwT9v8K6fOhJnoXNhELJiixA=; b=bTApheyI5VbA5iCv/8TajktbgSZCsoCSw9rECpUTd6ADmXMPE++peiaEweVOxzUxgM cLw4hRjsKUfHjTyjsisJlMRsURzBMM95lWCu1PZsSY1VVfEOgJaW7Aj1QQ6rE5uLq1PK nYFP96GD/P8GfpI1KYXc6u2bpvMnGUNbRSARem8xYMlxDzFiBNutucEed70rPw2Pl0a2 x5dmZn5TP3T8a3rcBQyg1j1YrZ0un1uqZVCV0jJU9z6IlEalRFGOub+JMcrFaItL+Ea/ MhJoDttWecjFGihlB0n+LJrHNIghoy1Bcq5lvVfuCMdt/SFnjnlQWvvAa5R8coPUVP1F lCeQ== X-Gm-Message-State: ALoCoQl4CwHu2vpiF5yL1skvoJZH6hF762fxdIq9K4R3DyrubIGgHlNOGv0+N1bUJNm5IwW+qfmTXXgQbjCMrWDoHhlUmc+lVvUUFVT6v0bSmurjrDaeRbeFODfEIb7opZuHqRHvUdIk X-Received: by 10.50.43.163 with SMTP id x3mr4756355igl.2.1400591033513; Tue, 20 May 2014 06:03:53 -0700 (PDT) X-Received: by 10.50.43.163 with SMTP id x3mr4756343igl.2.1400591033442; Tue, 20 May 2014 06:03:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Tue, 20 May 2014 06:03:22 -0700 (PDT) In-Reply-To: <5374EE47.9040101@gmail.com> References: <5374EE47.9040101@gmail.com> From: Brian Campbell Date: Tue, 20 May 2014 07:03:22 -0600 Message-ID: To: Sergey Beryozkin Content-Type: multipart/alternative; boundary=047d7bfea156063d9d04f9d48310 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jeD1aXzAy4yrF06VNM8F4Lu2TNc Cc: "" Subject: Re: [OAUTH-WG] Client authentication and assertion grants X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 13:03:56 -0000 --047d7bfea156063d9d04f9d48310 Content-Type: text/plain; charset=UTF-8 Yes Sergey, it's to allow for support of unregistered clients. Typically such clients will have some relationship established with a security token service (STS) where they can obtain assertion grants and the AS trusts the STS to issue such assertions. In that kind of scenario, the identity of the client can be considered unimportant - what's important is that the AS trusts the STS and in turn the STS trusted the client enough to issues it a suitable assertion. On Thu, May 15, 2014 at 10:41 AM, Sergey Beryozkin wrote: > Hi > > I'm reviewing the way client authentication is expected to be done when > either SAML or JWT bearer assertion is used as a grant [1] which > corresponds to the case described in [2]. > > [1] says: "Authentication of the client is optional...". > > Can someone please clarify how it can be optional given that in this case > a subject of the assertion does not identify a client ? Is it about > supporting unregistered clients which have managed to obtain somehow the > assertion grants ? > > Thanks, Sergey > > [1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-4.1 > [2] http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --047d7bfea156063d9d04f9d48310 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes Sergey, it's to allow for support of unregistered = clients. Typically such clients will have some relationship established wit= h a security token service (STS) where they can obtain assertion grants and= the AS trusts the STS to issue such assertions. In that kind of scenario, = the identity of the client can be considered unimportant - what's impor= tant is that the AS trusts the STS and in turn the STS trusted the client e= nough to issues it a suitable assertion.


On Thu,= May 15, 2014 at 10:41 AM, Sergey Beryozkin <sberyozkin@gmail.com= > wrote:
Hi

I'm reviewing the way client authentication is expected to be done when= either SAML or JWT bearer assertion is used as a grant [1] which correspon= ds to the case described in [2].

[1] says: "Authentication of the client is optional...".

Can someone please clarify how it can be optional given that in this case a= subject of the assertion does not identify a client ? Is it about supporti= ng unregistered clients which have managed to obtain somehow the assertion = grants ?

Thanks, Sergey

[1] http://tools.ietf.org/html/draft-ietf-o= auth-assertions-16#section-4.1
[2] http://tools.ietf.org/html/draft-ietf-o= auth-assertions-16#section-6.3

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

--047d7bfea156063d9d04f9d48310-- From nobody Tue May 20 06:57:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400011A0449 for ; Tue, 20 May 2014 06:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 aSEtRs8qmEGm for ; Tue, 20 May 2014 06:57:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1774A1A0336 for ; Tue, 20 May 2014 06:57:05 -0700 (PDT) Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4KDv44l023987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 20 May 2014 09:57:04 -0400 Received: from localhost.localdomain (vpn-60-37.rdu2.redhat.com [10.10.60.37]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s4KDuxAY002239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 20 May 2014 09:57:00 -0400 Message-ID: <537B5F2B.9090501@redhat.com> Date: Tue, 20 May 2014 08:56:59 -0500 From: Anil Saldhana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: oauth@ietf.org References: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> <1400275641.37471.YahooMailNeo@web142803.mail.bf1.yahoo.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060109070408080006010601" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/r3dnWQevzHVzThGaediEqVjSgYI Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 13:57:20 -0000 This is a multi-part message in MIME format. --------------060109070408080006010601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian - I agree with you. It should be MUST as long as the hard limit is generous for usage. On 05/20/2014 07:09 AM, Brian Campbell wrote: > I'd say it should be a MUST so that implementations are consistent > about it. > > > On Fri, May 16, 2014 at 3:27 PM, Bill Mills > wrote: > > The HTTP specs don't limit these things, but implementations do, > and the problems when you run into them are a rea pain. > > DO we want to make this a hard limit, or should it be guidance in > the form of RECOMMENDED or SHOULD? > > On Friday, May 16, 2014 9:35 AM, Brian Campbell > > > wrote: > Yeah, I agree with John here. There are a few good reasons to > restrict the length of the code_challenge. One is trying to keep > the authorization request URI to reasonable size as it will > eventually run into various limits on clients and/or servers. The > other is constraining the amount of data that an AS needs to store > per code. > > > > > On Fri, May 16, 2014 at 7:41 AM, John Bradley > wrote: > > From the AS side you probably want to know what the max size > you need to store per code. > > On the call to the token endpoint it is a POST so size should > not be an issue. > > > On May 16, 2014, at 3:10 PM, Nat Sakimura > wrote: > >> Now that I cannot remember what limit we were hitting, it >> might be a good idea to remove the constraint and see if >> anyone protests. >> >> What do you think? >> >> Nat >> >> >> 2014-05-14 20:46 GMT+09:00 Brian Campbell >> >: >> >> That too would suggest that the length limit be on >> code_challenge because that's the parameter that will be >> on URIs getting passed around. The code_verifier is sent >> directly in the POST body from client to AS. >> >> >> On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura >> > wrote: >> >> +1 for octet. We used to have "bytes" in JW* so I >> used "bytes" here, while at the same time complaining >> in Jose that it should be "octet". JW* changed to >> "octet" but I failed to sync with it in the last few >> edits. >> >> I do not quite remember which platform, but the >> reason for the limit was that some platform had some >> limitations as to the length of the sting to be >> passed to it through URI and we did not want the >> challenges to be truncated by that limit. >> >> Best, >> >> Nat >> >> >> 2014-05-13 6:56 GMT+09:00 Brian Campbell >> > >: >> >> And it'd give the AS some direct guidance on >> protecting itself from crazy long code_challenge >> values rather than relying on the client not to >> do something creative. >> >> >> On Mon, May 12, 2014 at 3:54 PM, Brian Campbell >> > > wrote: >> >> Right but that's why I'm asking why not just >> put the limit on code_challange rather than >> inferring it from code_verifyer + challenge >> algorithm, which probably bounds it but >> doesn't necessarily do so? It's not a big >> deal but would read more clearly, I think. >> >> >> On Mon, May 12, 2014 at 3:48 PM, John Bradley >> > > wrote: >> >> I think octets is more consistent with >> other JW* and OAuth specs. >> >> The code_challange is the same length as >> the code_verifyer or is a hash of the >> code_verifyer so likely smaller than >> 128octets (43 ish for base64 256 bit) >> >> Limiting the code_verifyer size sets the >> upper bound for code_challange, unless >> someone comes up with a really creative >> code challenge algorithm. >> >> I will talk to nat about changing it to >> octets when I see him tomorrow. >> >> John B. >> >> On May 12, 2014, at 11:15 PM, Derek >> Atkins > > wrote: >> >> > Brian Campbell >> > > writes: >> > >> >> I notice that code_verifier is defined >> as "high entropy cryptographic random >> >> string of length less than 128 bytes" >> [1], which brought a few questions and >> >> comments to mind. So here goes: >> >> >> >> Talking about the length of a string >> in terms of bytes is always potentially >> >> confusing. Maybe characters would be >> an easier unit for people like me to wrap >> >> their little brains around? >> > >> > It depends if it really is characters >> or bytes. For example there are >> > many multi-byte UTF-8 characters, so if >> it really is bytes then saying >> > characters is wrong because it could >> overflow. So let's make sure we >> > know what we're talking about. >> Historically, if we're talking bytes the >> > IETF often uses the phrase "octets". >> Would that be less confusing? >> > >> >> Why are we putting a length >> restriction on the code_verifier anyway? >> It seems >> >> like it'd be more appropriate to >> restrict the length of the code_challenge >> >> because that's the thing the AS will >> have to maintain somehow (store in a DB >> >> or memory or encrypt into the code). >> Am I missing something here? >> >> >> >> Let me also say that I hadn't looked >> at this document since its early days in >> >> draft -00 or -01 last summer but I >> like the changes and how it's been kept >> >> pretty simple for the common use-case >> while still allowing for crypto agility/ >> >> extension. Nice work! >> >> >> >> [1] >> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 >> > >> > -derek >> > >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > -- >> > Derek Atkins, SB '93 MIT EE, SM '95 MIT >> Media Laboratory >> > Member, MIT Student Information >> Processing Board (SIPB) >> > URL: http://web.mit.edu/warlord/ >> PP-ASEL-IA N1NWH >> > warlord@MIT.EDU >> >> PGP key available >> >> >> >> >> -- >> Ping Identity logo >> >> Brian Campbell >> Portfolio Architect >> @ bcampbell@pingidentity.com >> >> phone +1 720.317.2061 >> Connect with us... >> twitter logo >> youtube >> logo >> >> LinkedIn logo >> >> Facebook logo >> >> Google+ logo >> >> slideshare logo >> >> flipboard logo rss >> feed icon >> >> Register for Cloud Identity Summit 2014 | >> Modern Identity Revolution | 19--23 July, >> 2014 | Monterey, CA >> >> >> >> >> >> >> -- >> Ping Identity logo >> Brian Campbell >> Portfolio Architect >> @ bcampbell@pingidentity.com >> >> phone +1 720.317.2061 >> Connect with us... >> twitter logo >> youtube logo >> >> LinkedIn logo >> Facebook >> logo >> Google+ logo >> >> slideshare logo >> >> flipboard logo rss feed >> icon >> >> Register for Cloud Identity Summit 2014 | Modern >> Identity Revolution | 19--23 July, 2014 | >> Monterey, CA >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> >> -- >> Ping Identity logo >> Brian Campbell >> Portfolio Architect >> @ bcampbell@pingidentity.com >> >> phone +1 720.317.2061 >> Connect with us... >> twitter logo youtube >> logo >> LinkedIn logo >> Facebook logo >> Google+ logo >> >> slideshare logo >> flipboard logo rss feed icon >> >> >> Register for Cloud Identity Summit 2014 | Modern Identity >> Revolution | 19--23 July, 2014 | Monterey, CA >> >> >> >> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en > > > > _______________________________________________ > 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 --------------060109070408080006010601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Brian - I agree with you.  It should be MUST as long as the hard limit is generous for usage.



On 05/20/2014 07:09 AM, Brian Campbell wrote:
I'd say it should be a MUST so that implementations are consistent about it.


On Fri, May 16, 2014 at 3:27 PM, Bill Mills <wmills_92105@yahoo.com> wrote:
The HTTP specs don't limit these things, but implementations do, and the problems when you run into them are a rea pain.

DO we want to make this a hard limit, or should it be guidance in the form of RECOMMENDED or SHOULD?

On Friday, May 16, 2014 9:35 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Yeah, I agree with John here. There are a few good reasons to restrict the length of the code_challenge. One is trying to keep the authorization request URI to reasonable size as it will eventually run into various limits on clients and/or servers. The other is constraining the amount of data that an AS needs to store per code.




On Fri, May 16, 2014 at 7:41 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
From the AS side you probably want to know what the max size you need to store per code.

On the call to the token endpoint it is a POST so size should not be an issue.  


On May 16, 2014, at 3:10 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Now that I cannot remember what limit we were hitting, it might be a good idea to remove the constraint and see if anyone protests. 

What do you think? 

Nat


2014-05-14 20:46 GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:
That too would suggest that the length limit be on code_challenge because that's the parameter that will be on URIs getting passed around. The code_verifier is sent directly in the POST body from client to AS.


On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura <sakimura@gmail.com> wrote:
+1 for octet. We used to have "bytes" in JW* so I used "bytes" here, while at the same time complaining in Jose that it should be "octet". JW* changed to "octet" but I failed to sync with it in the last few edits. 

I do not quite remember which platform, but the reason for the limit was that some platform had some limitations as to the length of the sting to be passed to it through URI and we did not want the challenges to be truncated by that limit. 

Best, 

Nat


2014-05-13 6:56 GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:

And it'd give the AS some direct guidance on protecting itself from crazy long code_challenge values rather than relying on the client not to do something creative.


On Mon, May 12, 2014 at 3:54 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Right but that's why I'm asking why not just put the limit on code_challange rather than inferring it from code_verifyer + challenge algorithm, which probably bounds it but doesn't necessarily do so? It's not a big deal but would read more clearly, I think.


On Mon, May 12, 2014 at 3:48 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I think octets is more consistent with other JW* and OAuth specs.

The code_challange is the same length as the code_verifyer or is a hash of the code_verifyer so likely smaller than 128octets (43 ish for base64 256 bit)

Limiting the code_verifyer size sets the upper bound for code_challange, unless someone comes up with a really creative code challenge algorithm.

I will talk to nat about changing it to octets when I see him tomorrow.

John B.

On May 12, 2014, at 11:15 PM, Derek Atkins <warlord@MIT.EDU> wrote:

> Brian Campbell <bcampbell@pingidentity.com> writes:
>
>> I notice that code_verifier is defined as "high entropy cryptographic random
>> string of length less than 128 bytes"  [1], which brought a few questions and
>> comments to mind. So here goes:
>>
>> Talking about the length of a string in terms of bytes is always potentially
>> confusing. Maybe characters would be an easier unit for people like me to wrap
>> their little brains around?
>
> It depends if it really is characters or bytes.  For example there are
> many multi-byte UTF-8 characters, so if it really is bytes then saying
> characters is wrong because it could overflow.  So let's make sure we
> know what we're talking about.  Historically, if we're talking bytes the
> IETF often uses the phrase "octets".  Would that be less confusing?
>
>> Why are we putting a length restriction on the code_verifier anyway? It seems
>> like it'd be more appropriate to restrict the length of the code_challenge
>> because that's the thing the AS will have to maintain somehow (store in a DB
>> or memory or encrypt into the code). Am I missing something here?
>>
>> Let me also say that I hadn't looked at this document since its early days in
>> draft -00 or -01 last summer but I like the changes and how it's been kept
>> pretty simple for the common use-case while still allowing for crypto agility/
>> extension. Nice work!
>>
>> [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3
>
> -derek
>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>       Member, MIT Student Information Processing Board  (SIPB)
>       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>       warlord@MIT.EDU                        PGP key available




--
Ping Identity logo
Brian Campbell
Portfolio Architect
@ bcampbell@pingidentity.com
phone +1 720.317.2061
Connect with us…
twitter logo youtube logo LinkedIn logo Facebook logo Google+ logo slideshare logo flipboard logo rss feed icon
Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA




--
Ping Identity logo
Brian Campbell
Portfolio Architect
@ bcampbell@pingidentity.com
phone +1 720.317.2061
Connect with us…
twitter logo youtube logo LinkedIn logo Facebook logo Google+ logo slideshare logo flipboard logo rss feed icon
Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA


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

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



--
Ping Identity logo
Brian Campbell
Portfolio Architect
@ bcampbell@pingidentity.com
phone +1 720.317.2061
Connect with us…
twitter logo youtube logo LinkedIn logo Facebook logo Google+ logo slideshare logo flipboard logo rss feed icon
Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



_______________________________________________
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

--------------060109070408080006010601-- From nobody Tue May 20 07:04:41 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAE81A06FC for ; Tue, 20 May 2014 07:04:32 -0700 (PDT) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 7q7vxxUOBjjY for ; Tue, 20 May 2014 07:04:24 -0700 (PDT) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71EC01A037D for ; Tue, 20 May 2014 07:04:24 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id b57so624635eek.13 for ; Tue, 20 May 2014 07:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bTYvr9UymNux7oRm5VUaPONXYMy4VUcVOcIGKyFPEhI=; b=hW87e4uPjSJUH59+9PrtmByT4XZglXvabSW5RDLkI0NVekO2W5CT/LJvlqrH3QvWEa at7OaI4pMsxNltfubDKIV7y+xQ0S7m9805MP9QWMt0W2D20cntlvMcNMvsRgNMjZcOqX VZsBsE1aQLqXiJoEmR1anNSrFN2rNjMrP2bxS4JcDnlWuj16Bb3oAUka+cybzCFSxJnb EF5rNLC7lSfguGnCQQwL5wqJZ5gMuXXxrHnMW9Y3ebcBlLnsfwTx0QZHwxbFG5TacQ4O Zmbf/c0MUX4hh2w3h5JK3rv3JOQzmSqKrpO+vNVu0cPXXwVOaSo3y7oUWXa32SapVlQB sY2A== X-Received: by 10.14.111.134 with SMTP id w6mr38201827eeg.0.1400594662754; Tue, 20 May 2014 07:04:22 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id s9sm4135141eew.5.2014.05.20.07.04.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 May 2014 07:04:21 -0700 (PDT) Message-ID: <537B60E4.1030903@gmail.com> Date: Tue, 20 May 2014 15:04:20 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Brian Campbell References: <5374EE47.9040101@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/90pvXUvBMJ3PwZoi_E56_TZtpVI Cc: "" Subject: Re: [OAUTH-WG] Client authentication and assertion grants X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 14:04:32 -0000 Hi, Thanks for the clarification, On 20/05/14 14:03, Brian Campbell wrote: > Yes Sergey, it's to allow for support of unregistered clients. Typically > such clients will have some relationship established with a security > token service (STS) where they can obtain assertion grants and the AS > trusts the STS to issue such assertions. In that kind of scenario, the > identity of the client can be considered unimportant - what's important > is that the AS trusts the STS and in turn the STS trusted the client > enough to issues it a suitable assertion. What confuses me still is this: given a grant (whatever grant it is) AS issues a token which is associated with a given client somehow. When a registered client uses JWT or SAML assertion to authenticate it is all clear (I can imagine the client logs on to STS, gets the assertion and authenticates with it to AS). Now if we have an unregistered client using an assertion grant, how do we associate a token with this unregistered client, the text seems to imply that the assertion grant does not identify this unregistered client either, so it is not clear how this client can use the token afterwards, even though AS can validate with STS/etc that the grant is valid. Is the idea that the registration happens after the unregistered client has exchanged an assertion grant for a token ? Sorry, I know I'm missing something obvious here... Thanks, Sergey > > > On Thu, May 15, 2014 at 10:41 AM, Sergey Beryozkin > wrote: > > Hi > > I'm reviewing the way client authentication is expected to be done > when either SAML or JWT bearer assertion is used as a grant [1] > which corresponds to the case described in [2]. > > [1] says: "Authentication of the client is optional...". > > Can someone please clarify how it can be optional given that in this > case a subject of the assertion does not identify a client ? Is it > about supporting unregistered clients which have managed to obtain > somehow the assertion grants ? > > Thanks, Sergey > > [1] > http://tools.ietf.org/html/__draft-ietf-oauth-assertions-__16#section-4.1 > > [2] > http://tools.ietf.org/html/__draft-ietf-oauth-assertions-__16#section-6.3 > > > _________________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/__listinfo/oauth > > > From nobody Tue May 20 07:15:42 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580231A06DA for ; Tue, 20 May 2014 07:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 CFsMncBKefv3 for ; Tue, 20 May 2014 07:15:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0831A06DF for ; Tue, 20 May 2014 07:15:38 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4KEFaW2010833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 20 May 2014 10:15:37 -0400 Received: from [10.10.54.238] (vpn-54-238.rdu2.redhat.com [10.10.54.238]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4KEFZRb016234 for ; Tue, 20 May 2014 10:15:36 -0400 Message-ID: <537B6389.7000207@redhat.com> Date: Tue, 20 May 2014 10:15:37 -0400 From: Bill Burke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: oauth@ietf.org References: <5374EE47.9040101@gmail.com> <537B60E4.1030903@gmail.com> In-Reply-To: <537B60E4.1030903@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JJXO3jrxAi_7xOXjOJxRwrEHC1A Subject: Re: [OAUTH-WG] Client authentication and assertion grants X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 14:15:40 -0000 On 5/20/2014 10:04 AM, Sergey Beryozkin wrote: > Hi, > > Thanks for the clarification, > On 20/05/14 14:03, Brian Campbell wrote: >> Yes Sergey, it's to allow for support of unregistered clients. Typically >> such clients will have some relationship established with a security >> token service (STS) where they can obtain assertion grants and the AS >> trusts the STS to issue such assertions. In that kind of scenario, the >> identity of the client can be considered unimportant - what's important >> is that the AS trusts the STS and in turn the STS trusted the client >> enough to issues it a suitable assertion. > > What confuses me still is this: given a grant (whatever grant it is) AS > issues a token which is associated with a given client somehow. > > When a registered client uses JWT or SAML assertion to authenticate it > is all clear (I can imagine the client logs on to STS, gets the > assertion and authenticates with it to AS). > > Now if we have an unregistered client using an assertion grant, how do > we associate a token with this unregistered client, the text seems to > imply that the assertion grant does not identify this unregistered > client either, so it is not clear how this client can use the token > afterwards, even though AS can validate with STS/etc that the grant is > valid. > > Is the idea that the registration happens after the unregistered client > has exchanged an assertion grant for a token ? > > Sorry, I know I'm missing something obvious here... > The unregistered client could, out-of-band, get its own token with the appropriate claims. The unregistered client would use this token as a credential when asking for an access token. I think what this setup allows you to do is to have a federated set of STS services. Where one STS deals with providing access tokens for applications and another deals with providing access tokens for clients to access application STS services :) Instead of just one auth server having to know about everything, you can delegate things to different servers. Am I on the right track? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From nobody Tue May 20 08:01:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187D21A06D2 for ; Tue, 20 May 2014 08:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 lBRfEWkZpMJS for ; Tue, 20 May 2014 08:01:05 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28BF01A0153 for ; Tue, 20 May 2014 08:01:05 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4KF117R031235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 May 2014 15:01:03 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s4KF10xW023125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 May 2014 15:01:01 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4KF0vIR016522; Tue, 20 May 2014 15:00:57 GMT Received: from [192.168.6.81] (/64.134.241.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 May 2014 08:00:57 -0700 Message-ID: <537B6E29.2060505@oracle.com> Date: Tue, 20 May 2014 08:00:57 -0700 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Sergey Beryozkin , Brian Campbell References: <5374EE47.9040101@gmail.com> <537B60E4.1030903@gmail.com> In-Reply-To: <537B60E4.1030903@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/FXMEc-3GwMPApHggWvT8MbMmN4U Cc: "" Subject: Re: [OAUTH-WG] Client authentication and assertion grants X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 15:01:11 -0000 Sergey - you haven't missed anything. The client remains unregistered throughout the exchange. There is no relationship between the assertion grant (or access token) and the client either. You are pointing out that an AS endpoint supporting unregistered clients (public in OAuth terminology) for exchanging assertion grants --> access tokens is open to several security attacks. The simplest is that the assertion grant could be stolen/forwarded to some malicious third party which could use it to obtain a token and then use it for resource access. As I understand it, the security model depends on the Out-of-Band relationship between the client and the local STS that provided the client with the initial token (assertion grant). The idea is that the AS endpoint trusts the local STS, and hopes that the STS would not provide the assertion grant to a "bad" client. I would not recommend the use of this model for anything substantive. - prateek > What confuses me still is this: given a grant (whatever grant it is) > AS issues a token which is associated with a given client somehow. > > When a registered client uses JWT or SAML assertion to authenticate it > is all clear (I can imagine the client logs on to STS, gets the > assertion and authenticates with it to AS). > > Now if we have an unregistered client using an assertion grant, how do > we associate a token with this unregistered client, the text seems to > imply that the assertion grant does not identify this unregistered > client either, so it is not clear how this client can use the token > afterwards, even though AS can validate with STS/etc that the grant is > valid. > > Is the idea that the registration happens after the unregistered > client has exchanged an assertion grant for a token ? > > Sorry, I know I'm missing something obvious here... > > Thanks, Sergey > > >> >> >> On Thu, May 15, 2014 at 10:41 AM, Sergey Beryozkin > > wrote: >> >> Hi >> >> I'm reviewing the way client authentication is expected to be done >> when either SAML or JWT bearer assertion is used as a grant [1] >> which corresponds to the case described in [2]. >> >> [1] says: "Authentication of the client is optional...". >> >> Can someone please clarify how it can be optional given that in this >> case a subject of the assertion does not identify a client ? Is it >> about supporting unregistered clients which have managed to obtain >> somehow the assertion grants ? >> >> Thanks, Sergey >> >> [1] >> http://tools.ietf.org/html/__draft-ietf-oauth-assertions-__16#section-4.1 >> >> [2] >> http://tools.ietf.org/html/__draft-ietf-oauth-assertions-__16#section-6.3 >> >> >> _________________________________________________ >> 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 Tue May 20 14:58:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4140D1A02B7 for ; Tue, 20 May 2014 14:58:50 -0700 (PDT) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 XS_FqvxMVCLG for ; Tue, 20 May 2014 14:58:48 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA991A01AB for ; Tue, 20 May 2014 14:58:48 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id f8so1735909wiw.10 for ; Tue, 20 May 2014 14:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kgPy1C1H9jrsV216t0MnmQtdiIiCY7afVaMZvbXtToo=; b=XflYIkBWaNyy7YHo9Y5m+9idh/rkPlD4IqvFRqJaDrnOK4shIPkpgZw4AJWJin8VZG KEm3/kUFcVJBj/lNV93OsrJgmwoOjN86Y23Qe7Db0wsT4oZU30idRLvX1GT3KDckVzP3 PnER08LRHQnTWps6qkkSH9Yk1SxHsmh1GBFWHGXl7i1GfKjunXUg4Yeq+rkkZUmMx0yr +n9WbgzkqZezYbUf8VwBH6Nnygfw/MCvPxdjZPGdhj8ex7gZR1i52BIWHEM2dJNxFdd7 4OcHOl5HqeYDaj4ASvsg4xyG9bsPE4gKPtxv+s57X/QRc+ZW5drwQ0cxd4uLgvnVUgRz B06Q== X-Received: by 10.180.91.114 with SMTP id cd18mr6683786wib.28.1400623126691; Tue, 20 May 2014 14:58:46 -0700 (PDT) Received: from [192.168.2.7] ([89.100.139.33]) by mx.google.com with ESMTPSA id bx2sm19926040wjb.47.2014.05.20.14.58.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 May 2014 14:58:45 -0700 (PDT) Message-ID: <537BD008.5040209@gmail.com> Date: Tue, 20 May 2014 22:58:32 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Prateek Mishra , Brian Campbell References: <5374EE47.9040101@gmail.com> <537B60E4.1030903@gmail.com> <537B6E29.2060505@oracle.com> In-Reply-To: <537B6E29.2060505@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YSHw17BHcfXayDsXJlmqwRJHO6A Cc: "" Subject: Re: [OAUTH-WG] Client authentication and assertion grants X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 21:58:50 -0000 Hi Prateek On 20/05/14 16:00, Prateek Mishra wrote: > Sergey - you haven't missed anything. The client remains unregistered > throughout the exchange. > There is no relationship between the assertion grant (or access token) > and the client either. > > You are pointing out that an AS endpoint supporting unregistered clients > (public in OAuth terminology) for > exchanging assertion grants --> access tokens is open to several > security attacks. The simplest is that the > assertion grant could be stolen/forwarded to some malicious third party > which could use it to obtain a token > and then use it for resource access. > > As I understand it, the security model depends on the Out-of-Band > relationship between the client and the local STS > that provided the client with the initial token (assertion grant). The > idea is that the AS endpoint trusts the local > STS, and hopes that the STS would not provide the assertion grant to a > "bad" client. > > I would not recommend the use of this model for anything substantive. > Thanks, it actually helps, I realized it is exactly the same case (very similar to it) where an unregistered/public client gets an authorization code securely entered by the end user who has securely authorized a public client. Next this public client exchanges a code grant for a token and AS optionally accepts by trusting that the end user has securely entered a code into the mobile device/etc... I guess the risk of the assertion being stolen might be minimized by keeping an access token lifespan to a very short period of time... I wonder can the assertion grant have a stronger binding to the unregistered clients somehow... Cheers, Sergey > - prateek >> What confuses me still is this: given a grant (whatever grant it is) >> AS issues a token which is associated with a given client somehow. >> >> When a registered client uses JWT or SAML assertion to authenticate it >> is all clear (I can imagine the client logs on to STS, gets the >> assertion and authenticates with it to AS). >> >> Now if we have an unregistered client using an assertion grant, how do >> we associate a token with this unregistered client, the text seems to >> imply that the assertion grant does not identify this unregistered >> client either, so it is not clear how this client can use the token >> afterwards, even though AS can validate with STS/etc that the grant is >> valid. >> >> Is the idea that the registration happens after the unregistered >> client has exchanged an assertion grant for a token ? >> >> Sorry, I know I'm missing something obvious here... >> >> Thanks, Sergey >> >> >>> >>> >>> On Thu, May 15, 2014 at 10:41 AM, Sergey Beryozkin >> > wrote: >>> >>> Hi >>> >>> I'm reviewing the way client authentication is expected to be done >>> when either SAML or JWT bearer assertion is used as a grant [1] >>> which corresponds to the case described in [2]. >>> >>> [1] says: "Authentication of the client is optional...". >>> >>> Can someone please clarify how it can be optional given that in this >>> case a subject of the assertion does not identify a client ? Is it >>> about supporting unregistered clients which have managed to obtain >>> somehow the assertion grants ? >>> >>> Thanks, Sergey >>> >>> [1] >>> http://tools.ietf.org/html/__draft-ietf-oauth-assertions-__16#section-4.1 >>> >>> >>> [2] >>> http://tools.ietf.org/html/__draft-ietf-oauth-assertions-__16#section-6.3 >>> >>> >>> >>> _________________________________________________ >>> 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 Tue May 20 19:29:45 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74EC1A0443 for ; Tue, 20 May 2014 19:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 QfUj6CZ01tmM for ; Tue, 20 May 2014 19:29:42 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB831A042F for ; Tue, 20 May 2014 19:29:42 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4L2TeSM004227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 May 2014 02:29:40 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4L2TdTw016745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 May 2014 02:29:39 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4L2TcKE016910; Wed, 21 May 2014 02:29:38 GMT Received: from [192.168.6.81] (/64.134.241.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 May 2014 19:29:38 -0700 Message-ID: <537C0F92.3010004@oracle.com> Date: Tue, 20 May 2014 19:29:38 -0700 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Sergey Beryozkin References: <5374EE47.9040101@gmail.com> <537B60E4.1030903@gmail.com> <537B6E29.2060505@oracle.com> <537BD008.5040209@gmail.com> In-Reply-To: <537BD008.5040209@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/cNRtbtSsGM9ByiA5r85EAs0GALE Cc: "" Subject: Re: [OAUTH-WG] Client authentication and assertion grants X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 02:29:45 -0000 The difference between the two scenarios is that the authorization code has a one-use property and also requires the user to be present. These conditions are not available in the (assertion grant --> access token) with a public client. So there are some fundamental differences in security properties between the two. In terms of stronger bindings, I think the PoP work would provide a better model for a public client presenting a SAML/JWT assertion. Key confirmation would ensure that no other client could present the assertion to the AS. > >> > Thanks, it actually helps, I realized it is exactly the same case > (very similar to it) where an unregistered/public client gets an > authorization code securely entered by the end user who has securely > authorized a public client. Next this public client exchanges a code > grant for a token and AS optionally accepts by trusting that the end > user has securely entered a code into the mobile device/etc... > > I guess the risk of the assertion being stolen might be minimized by > keeping an access token lifespan to a very short period of time... > > I wonder can the assertion grant have a stronger binding to the > unregistered clients somehow... > > Cheers, Sergey > >> - prateek >>> What confuses me still is this: given a grant (whatever grant it is) >>> AS issues a token which is associated with a given client somehow. >>> >>> When a registered client uses JWT or SAML assertion to authenticate it >>> is all clear (I can imagine the client logs on to STS, gets the >>> assertion and authenticates with it to AS). >>> >>> Now if we have an unregistered client using an assertion grant, how do >>> we associate a token with this unregistered client, the text seems to >>> imply that the assertion grant does not identify this unregistered >>> client either, so it is not clear how this client can use the token >>> afterwards, even though AS can validate with STS/etc that the grant is >>> valid. >>> >>> Is the idea that the registration happens after the unregistered >>> client has exchanged an assertion grant for a token ? >>> >>> Sorry, I know I'm missing something obvious here... >>> >>> Thanks, Sergey >>> >>> >>>> >>>> >>>> On Thu, May 15, 2014 at 10:41 AM, Sergey Beryozkin >>>> >>> > wrote: >>>> >>>> Hi >>>> >>>> I'm reviewing the way client authentication is expected to be done >>>> when either SAML or JWT bearer assertion is used as a grant [1] >>>> which corresponds to the case described in [2]. >>>> >>>> [1] says: "Authentication of the client is optional...". >>>> >>>> Can someone please clarify how it can be optional given that in >>>> this >>>> case a subject of the assertion does not identify a client ? Is it >>>> about supporting unregistered clients which have managed to obtain >>>> somehow the assertion grants ? >>>> >>>> Thanks, Sergey >>>> >>>> [1] >>>> http://tools.ietf.org/html/__draft-ietf-oauth-assertions-__16#section-4.1 >>>> >>>> >>>> >>>> >>>> [2] >>>> http://tools.ietf.org/html/__draft-ietf-oauth-assertions-__16#section-6.3 >>>> >>>> >>>> >>>> >>>> >>>> _________________________________________________ >>>> 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 Wed May 21 03:02:08 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1032E1A048A for ; Wed, 21 May 2014 03:02:07 -0700 (PDT) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 JmDnj0wJJPxp for ; Wed, 21 May 2014 03:02:05 -0700 (PDT) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531201A0315 for ; Wed, 21 May 2014 03:02:05 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id t10so1353429eei.5 for ; Wed, 21 May 2014 03:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LS62gYJyKp6fgSs45vqkcNjJxo54bWv3SzprgCOKKj0=; b=hLQ8oshYDfC/Ycj2+5QFUQpEH37wklnB7T6XA4eYjowNL0FtFtkeGDhQQpjgKBrNuR kRVR41NlVWAJpkV6YCtT9YYOVbD7V5WNmeORKk1H79MLqpeO6mbHyRPgdVPkqDbOXxn9 1TSIhu2NlrCuBkgb7n39YthJRgUFjgvPYft7WO8BCp2Bn62rYKjEBbeLyjFFVVP4l8f4 fZHrcn4DlLqAaizF+waVjzmn6KKVZVloyFMXPvOXwE3/qF1FSPzn+g2sWXRLl18yf7+Y rEQ0cNMzevRUdI4k7FSoVwz1KRGAbC0nuri8X6Vv41+wq/S8yelYZoKluGeUJrwkmz4n ig/g== X-Received: by 10.14.198.6 with SMTP id u6mr2528857een.60.1400666523460; Wed, 21 May 2014 03:02:03 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id u46sm10670312eel.1.2014.05.21.03.02.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 03:02:02 -0700 (PDT) Message-ID: <537C798D.7070803@gmail.com> Date: Wed, 21 May 2014 11:01:49 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Prateek Mishra References: <5374EE47.9040101@gmail.com> <537B60E4.1030903@gmail.com> <537B6E29.2060505@oracle.com> <537BD008.5040209@gmail.com> <537C0F92.3010004@oracle.com> In-Reply-To: <537C0F92.3010004@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ivo2YEPFb0kUP34mdl5sM-KYDyI Cc: "" Subject: Re: [OAUTH-WG] Client authentication and assertion grants X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 10:02:07 -0000 Hi On 21/05/14 03:29, Prateek Mishra wrote: > The difference between the two scenarios is that the authorization code > has a one-use property and also requires the user to be present. > > These conditions are not available in the (assertion grant --> access > token) with a public client. So there are some fundamental differences > in security properties between the two. > > In terms of stronger bindings, I think the PoP work would provide a > better model for a public client presenting a SAML/JWT assertion. Key > confirmation would ensure that no other client could present the > assertion to the AS. Nice, thanks for the analysis, May be bearer assertions drafts should have text recommending AS to enforce a one time use condition too for public clients using assertions as grants, based on the assertion id, seems like it won't harm, Cheers, Sergey > >> >>> >> Thanks, it actually helps, I realized it is exactly the same case >> (very similar to it) where an unregistered/public client gets an >> authorization code securely entered by the end user who has securely >> authorized a public client. Next this public client exchanges a code >> grant for a token and AS optionally accepts by trusting that the end >> user has securely entered a code into the mobile device/etc... >> >> I guess the risk of the assertion being stolen might be minimized by >> keeping an access token lifespan to a very short period of time... >> >> I wonder can the assertion grant have a stronger binding to the >> unregistered clients somehow... >> >> Cheers, Sergey >> >>> - prateek >>>> What confuses me still is this: given a grant (whatever grant it is) >>>> AS issues a token which is associated with a given client somehow. >>>> >>>> When a registered client uses JWT or SAML assertion to authenticate it >>>> is all clear (I can imagine the client logs on to STS, gets the >>>> assertion and authenticates with it to AS). >>>> >>>> Now if we have an unregistered client using an assertion grant, how do >>>> we associate a token with this unregistered client, the text seems to >>>> imply that the assertion grant does not identify this unregistered >>>> client either, so it is not clear how this client can use the token >>>> afterwards, even though AS can validate with STS/etc that the grant is >>>> valid. >>>> >>>> Is the idea that the registration happens after the unregistered >>>> client has exchanged an assertion grant for a token ? >>>> >>>> Sorry, I know I'm missing something obvious here... >>>> >>>> Thanks, Sergey >>>> >>>> >>>>> >>>>> >>>>> On Thu, May 15, 2014 at 10:41 AM, Sergey Beryozkin >>>>> >>>> > wrote: >>>>> >>>>> Hi >>>>> >>>>> I'm reviewing the way client authentication is expected to be done >>>>> when either SAML or JWT bearer assertion is used as a grant [1] >>>>> which corresponds to the case described in [2]. >>>>> >>>>> [1] says: "Authentication of the client is optional...". >>>>> >>>>> Can someone please clarify how it can be optional given that in >>>>> this >>>>> case a subject of the assertion does not identify a client ? Is it >>>>> about supporting unregistered clients which have managed to obtain >>>>> somehow the assertion grants ? >>>>> >>>>> Thanks, Sergey >>>>> >>>>> [1] >>>>> http://tools.ietf.org/html/__draft-ietf-oauth-assertions-__16#section-4.1 >>>>> >>>>> >>>>> >>>>> >>>>> [2] >>>>> http://tools.ietf.org/html/__draft-ietf-oauth-assertions-__16#section-6.3 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ >>>>> 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 Wed May 21 11:56:56 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE12A1A0691 for ; Wed, 21 May 2014 11:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 yY-KACltAoWR for ; Wed, 21 May 2014 11:56:51 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965471A0280 for ; Wed, 21 May 2014 11:56:49 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4LIukmY011556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 21 May 2014 18:56:46 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s4LIuil2002301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 May 2014 18:56:45 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4LIuheQ000718 for ; Wed, 21 May 2014 18:56:43 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 May 2014 11:56:43 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_4C2C28E9-DD72-416D-9429-2C9EF734A38D" Message-Id: <75D99637-1802-4C1F-83BE-D62AD938F9F4@oracle.com> Date: Wed, 21 May 2014 11:56:41 -0700 To: OAuth WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/B7WVDdXHh6sX9JlRGErfxT_EeFU Subject: [OAUTH-WG] Authen Milestone: Comparing current A4C proposal to OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 18:56:53 -0000 --Apple-Mail=_4C2C28E9-DD72-416D-9429-2C9EF734A38D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Since several have voiced the opinion that the WG should not work on = providing user authentication context because OpenID Connect already has = a solution, I wanted to make clear how A4C is different from OpenID = Connect. OpenID Connect supports providing clients an =93id_token=94 using the = id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid = Auth) of the OAuth Core. http://openid.net/specs/openid-connect-core-1_0.html The A4C draft that was put forward by Mike, Tony, and myself ( = draft-hunt-oauth-v2-user-a4c ) describes a flow similar to the code flow = of normal OAuth. Here are the differences from Connect: Client Authentication Connect does NOT authenticate the client prior to returning the id = token. The Connect flow is single step returning ID_TOKEN to an = unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.3 = appears only for the purpose of issuing an access token (user info = token). The A4C flow is 2-step following the OAuth2 code flow. It requires a = code to be exchanged for ID_TOKEN after client authenticates in the = second step (exactly duplicating the normal OAuth flow). A4C requires = mutual authentication of clients and AS service providers. A4C has the = same logic and security properties of the normal OAuth authorization = flow. User Authentication=20 Both OpenID Connect and A4C return ID tokens which contain pretty much = the same information A4C has additional features to allow clients to negotiate level of = authentication and authentication types (min LOA,ACR,AMR) in addition to = just returning ACR as in the case of OpenID. A4C only make re-auth lighter weight. No need to issue UserInfo tokens = again. Re-auth also re-authenticates the client as well as user. Privacy Option The A4C=92s authentication of the client makes it possible to issue = client-specific subject identifiers. This prevents multiple clients from = colluding to share information. Because Connect doesn=92t know who the client is, the subject identifier = returned is universal. The spec could be used for pseudonymous authentication. As you can see the specs are doing similar things, but they have = different security features. As for need: There are many sites using social network providers to authenticate = using 6749 only, there are ongoing security concerns that many of us = have blogged about. This may rise to the level of BUG on 6749. Some social network providers have indicated a willingness to support an = authenticate only feature. I also had an inquiry if A4C can be supported = in OAuth1 as well as OAuth2. Some of this may be coming from a business = decision to use a proprietary user profile API instead (this is not = Oracle=92s position). There is a consent problem because normal 6749 use requires users to = consent to sharing information. Client developers in many cases would = like an authen only profile where consent is implicit. Developers have been indicating that defining new user-id/pwds and = additionally sharing of profile information both cut back on the %age = success of new user registrations. Many want to offer an authenticate = only option for their users where the users explicitly decide what to = supply in their profile. Pseudonymous authen is a basic feature. I see other areas (e.g. Kitten) where authentication and = re-authentication may be of interest to other IETF groups. There may be much broader requirements in the IETF community that are = not of interest to OpenID Connect and its objectives While it is reasonable to make A4C and Connect as compatible as = possible, I am not sure they can be compatible. A4C and Connect are two = different flows solving different use cases with different security = characteristics. Note: I do not believe that the A4C draft is ready for last call-it is = intended only as input to the WG process. The features and aspects like = how the flow is initiated need to be discussed within the wider IETF = community where broad consensus can be obtained. This is why I feel = having it a work group milestone is important and I am willing to = contribute my time towards it. Because of the ongoing issue of inappropriate use of 6749 and the = broader requirements within the IETF, I feel this work needs to be = discussed within the IETF WG.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_4C2C28E9-DD72-416D-9429-2C9EF734A38D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Since = several have voiced the opinion that the WG should not work on providing = user authentication context because OpenID Connect already has a = solution, I wanted to make clear how A4C is different from OpenID = Connect.

OpenID Connect supports providing clients an = =93id_token=94 using the id_token response type in section 3.2 = (ImplicitAuth) and 3.3 (Hybrid Auth) of the OAuth Core.

The = A4C draft that was put forward by Mike, Tony, and myself ( draf= t-hunt-oauth-v2-user-a4c ) describes a flow similar to the = code flow of normal OAuth. Here are the differences from = Connect:

  • Client = Authentication
    • Connect does NOT authenticate the client = prior to returning the id token. The Connect flow is single step = returning ID_TOKEN to an unauthenticated client in both 3.2 and 3.3. Use = of code flow in 3.3 appears only for the purpose of issuing an access = token (user info token).
    • The A4C flow is 2-step following the = OAuth2 code flow. It requires a code to be exchanged for ID_TOKEN after = client authenticates in the second step (exactly duplicating the normal = OAuth flow).  A4C requires mutual authentication of clients and AS = service providers. A4C has the same logic and security properties of the = normal OAuth authorization flow.
  • User = Authentication 
    • Both OpenID Connect and A4C return ID = tokens which contain pretty much the same = information
    • A4C has additional features to allow = clients to negotiate level of authentication and authentication types = (min LOA,ACR,AMR) in addition to just returning ACR as in the case of = OpenID.
    • A4C only make re-auth lighter weight. No need to issue = UserInfo tokens again. Re-auth also re-authenticates the client as well = as user.
  • Privacy Option
    • The A4C=92s = authentication of the client makes it possible to issue client-specific = subject identifiers. This prevents multiple clients from colluding to = share information.
    • Because Connect doesn=92t know who the client = is, the subject identifier returned is universal.
    • The spec could = be used for pseudonymous = authentication.

As you can see the = specs are doing similar things, but they have different security = features.

As for need:
  • There are many sites using social network = providers to authenticate using 6749 only, there are ongoing security = concerns that many of us have blogged about. This may rise to the = level of BUG on 6749.
  • Some social network providers have = indicated a willingness to support an authenticate only feature. I also = had an inquiry if A4C can be supported in OAuth1 as well as OAuth2. Some = of this may be coming from a business decision to use a proprietary user = profile API instead (this is not Oracle=92s position).
  • There is = a consent problem because normal 6749 use requires users to consent to = sharing information. Client developers in many cases would like an = authen only profile where consent is implicit.
  • Developers have = been indicating that defining new user-id/pwds  and additionally = sharing of profile information both cut back on the %age success of new = user registrations. Many want to offer an authenticate only option for = their users where the users explicitly decide what to supply in their = profile.  Pseudonymous authen is a basic feature.
  • I see = other areas (e.g. Kitten) where authentication and re-authentication may = be of interest to other IETF groups.
    • There may be much = broader requirements in the IETF community that are not of interest to = OpenID Connect and its = objectives

While it is = reasonable to make A4C and Connect as compatible as possible, I am not = sure they can be compatible. A4C and Connect are two different flows = solving different use cases with different security = characteristics.

Note: I do not believe = that the A4C draft is ready for last call-it is intended only as input = to the WG process. The features and aspects like how the flow is = initiated need to be discussed within the wider IETF community where = broad consensus can be obtained. This is why I feel having it a work = group milestone is important and I am willing to contribute my time = towards it.

Because of the ongoing issue of = inappropriate use of 6749 and the broader requirements within the IETF, = I feel this work needs to be discussed within the IETF = WG. 

= --Apple-Mail=_4C2C28E9-DD72-416D-9429-2C9EF734A38D-- From nobody Wed May 21 18:04:02 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FA01A0026 for ; Wed, 21 May 2014 18:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, SPF_PASS=-0.001] autolearn=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 WfIiv8tD6QwT for ; Wed, 21 May 2014 18:03:59 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0588A1A0020 for ; Wed, 21 May 2014 18:03:58 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id l4so2156322lbv.31 for ; Wed, 21 May 2014 18:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mz8tIOqyh3Vwo35FzP/FP8B59zzBg6XN8SD48XdKt2Y=; b=wuDvKiKxLuL3rL3bXTWKjaIzHFiSxWifG69g7YD7FcQBjmu7xiGJR0f3FLvmgqibS3 9oimAX48AhTMBc1/GfFVEQ26wsb/1sQOv4tZdMxq1SXOsgGu+c7qiynfzTnAdj2t6P5Z A16i8HcUFJlyptGEIBqu8hPUx+0g04H/Ukbs2pI8wVoawCatFhaHuvrn2wr4AfGMj25h KuXtqUo3iaORMrqxU7TXmQ2EYpi4EDhwYcPDVkz7puknNw/VdcXFyGdO2Pws4bQYNHSl smx37QA+g3GSeKfQlkS/9l2j7JJPOu80q8IrxI52JRn1RhN+n+R83kZOzMiccfMoRom/ 51iw== MIME-Version: 1.0 X-Received: by 10.112.34.243 with SMTP id c19mr61028lbj.57.1400720636485; Wed, 21 May 2014 18:03:56 -0700 (PDT) Received: by 10.112.105.134 with HTTP; Wed, 21 May 2014 18:03:56 -0700 (PDT) In-Reply-To: <75D99637-1802-4C1F-83BE-D62AD938F9F4@oracle.com> References: <75D99637-1802-4C1F-83BE-D62AD938F9F4@oracle.com> Date: Thu, 22 May 2014 10:03:56 +0900 Message-ID: From: Nat Sakimura To: Phil Hunt Content-Type: multipart/alternative; boundary=14dae93d93d4f7a85b04f9f2afbe Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_gjjQbvyTW6oQwBHMEZIetM4tcU Cc: OAuth WG Subject: Re: [OAUTH-WG] Authen Milestone: Comparing current A4C proposal to OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 01:04:01 -0000 --14dae93d93d4f7a85b04f9f2afbe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Phil, please do not misinform the working group. My responses inline: 2014-05-22 3:56 GMT+09:00 Phil Hunt : > Since several have voiced the opinion that the WG should not work on > providing user authentication context because OpenID Connect already has = a > solution, I wanted to make clear how A4C is different from OpenID Connect= . > > OpenID Connect supports providing clients an =E2=80=9Cid_token=E2=80=9D u= sing the id_token > response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid Auth) of the > OAuth Core. > http://openid.net/specs/openid-connect-core-1_0.html > > The A4C draft that was put forward by Mike, Tony, and myself ( > draft-hunt-oauth-v2-user-a4c ) describes > a flow similar to the code flow of normal OAuth. Here are the differences > from Connect: > > > - Client Authentication > - Connect does NOT authenticate the client prior to returning the > id token. The Connect flow is single step returning ID_TOKEN to an > unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.3= appears > only for the purpose of issuing an access token (user info token). > - The A4C flow is 2-step following the OAuth2 code flow. It > requires a code to be exchanged for ID_TOKEN after client authentic= ates in > the second step (exactly duplicating the normal OAuth flow). A4C r= equires > mutual authentication of clients and AS service providers. A4C has = the same > logic and security properties of the normal OAuth authorization flo= w. > > This is not true. Connect for Code Flow for confidential client DOES authenticate the client before getting an ID Token. Further, the Connect has an option of asymmetrically encrypting ID Token with the public key of the client, which authenticates the client even further. Even further, the Connect has an option of asymmetrically encrypting the request with the public key of the server, which authenticates the server in addition to TLS. > > - User Authentication > - Both OpenID Connect and A4C return ID tokens which contain pretty > much the same information > - A4C has additional features to allow clients to negotiate level of > authentication and authentication types (min LOA,ACR,AMR) in additi= on to > just returning ACR as in the case of OpenID. > > What's the point of having both minimum LoA and AMR instead of ACR? Connect can also return AMR. If you really wanted to have amr_values like feature, you can actually request it by using Claims request as { "id_token": {"amr": {"values": ["otp","rsa"] }}} > > - A4C only make re-auth lighter weight. No need to issue UserInfo > tokens again. Re-auth also re-authenticates the client as well as u= ser. > > I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C is diverting from RFC6749. A4C is NOT OAuth anymore. The very reason OpenID Connect returns an access token from the token endpoint always is to adhere to RFC6749. OpenID Connect with scope=3Dopenid only is essentially the authN only operation. > - Privacy Option > - The A4C=E2=80=99s authentication of the client makes it possible = to issue > client-specific subject identifiers. This prevents multiple clients= from > colluding to share information. > > This is supported by OpenID Connect as well. > > - Because Connect doesn=E2=80=99t know who the client is, the subject > identifier returned is universal. > > As stated above, this is false. It can even return PPID in the case of public client as well. > > - The spec could be used for pseudonymous authentication. > > As state above, OpenID Connect supports this. It in fact advise the use o= f PPID (Pairwise Psuedonymous Identifier in section 17.3). > > As you can see the specs are doing similar things, but they have differen= t > security features. > As stated above, I do not see much. It has less option in general, and added feature is the amr_values and min_alv, which I do not see much value in it but if you really wanted, you can extend the Connect. > > As for need: > > - There are many sites using social network providers to authenticate > using 6749 only, there are ongoing security concerns that many of us h= ave > blogged about. *This may rise to the level of BUG on 6749.* > > Why not just use OpenID Connect? > > - Some social network providers have indicated a willingness to > support an authenticate only feature. I also had an inquiry if A4C can= be > supported in OAuth1 as well as OAuth2. Some of this may be coming from= a > business decision to use a proprietary user profile API instead (this = is > not Oracle=E2=80=99s position). > > Authen only is fine with OpenID Connect. You can also use proprietary or whatever the user profile API "in addition". For the purpose of interoperability, it is better to have a standard user profile API though, and that's why Connect defines a very basic one for this purpose. > > - There is a consent problem because normal 6749 use requires users to > consent to sharing information. Client developers in many cases would = like > an authen only profile where consent is implicit. > > That's an implementation issue. RFC 6749 does not require the users to provide explicit consent. It just states: the authorization server authenticates the resource owner and obtains an authorization decision (by asking the resource owner or by establishing approval via other means). It can be implicit. > > - Developers have been indicating that defining new user-id/pwds and > additionally sharing of profile information both cut back on the %age > success of new user registrations. Many want to offer an authenticate = only > option for their users where the users explicitly decide what to suppl= y in > their profile. Pseudonymous authen is a basic feature. > > This is supported by OpenID Connect as I stated above. > > - I see other areas (e.g. Kitten) where authentication and > re-authentication may be of interest to other IETF groups. > - There may be much broader requirements in the IETF community that > are not of interest to OpenID Connect and its objectives > > > Why not? > While it is reasonable to make A4C and Connect as compatible as possible, > I am not sure they can be compatible. A4C and Connect are two different > flows solving different use cases with different security characteristics= . > Why not? I do not see it. You are essentially reading OpenID Connect wrong. > > Note: I do not believe that the A4C draft is ready for last call-it is > intended only as input to the WG process. The features and aspects like h= ow > the flow is initiated need to be discussed within the wider IETF communit= y > where broad consensus can be obtained. This is why I feel having it a wor= k > group milestone is important and I am willing to contribute my time towar= ds > it. > Since it adds essentially nothing and produces wait-and-see among the implementers, I think accepting this work as an work group item is actively harmful for the internet. If something is needed to worked on in the work group, I would rather want to see a profile of OpenID Connect referencing it. That causes much less confusion. > > Because of the ongoing issue of inappropriate use of 6749 and the broader > requirements within the IETF, I feel this work needs to be discussed with= in > the IETF WG. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > _______________________________________________ > 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 --14dae93d93d4f7a85b04f9f2afbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Phil, please do not misinform the working group.=C2=A0
My responses inline:=C2=A0
=

2014-05-22 3:56 GMT+09:00 Phil Hunt <phil.hunt@oracle.com>:
Since several have voi= ced the opinion that the WG should not work on providing user authenticatio= n context because OpenID Connect already has a solution, I wanted to make c= lear how A4C is different from OpenID Connect.

OpenID Connect supports providing clients an =E2=80=9Cid_tok= en=E2=80=9D using the id_token response type in section 3.2 (ImplicitAuth) = and 3.3 (Hybrid Auth) of the OAuth Core.

The A4C draft that was put forward by Mike, Tony, and m= yself (=C2=A0draft-hunt-oauth-v2-user-a4c=C2=A0)=C2=A0d= escribes a flow similar to the code flow of normal OAuth. Here are the diff= erences from Connect:

  • Client Authentication
    • Connect does = NOT authenticate the client prior to returning the id token. The Connect fl= ow is single step returning ID_TOKEN to an unauthenticated client in both 3= .2 and 3.3. Use of code flow in 3.3 appears only for the purpose of issuing= an access token (user info token).
    • The A4C flow is 2-step following the OAuth2 code flow. It requires a co= de to be exchanged for ID_TOKEN after client authenticates in the second st= ep (exactly duplicating the normal OAuth flow). =C2=A0A4C requires mutual a= uthentication of clients and AS service providers. A4C has the same logic a= nd security properties of the normal OAuth authorization flow.
This is not t= rue.=C2=A0

Connect for Code Flow for confidential client DOES authenticate the cl= ient before getting an ID Token.=C2=A0

Further, th= e Connect has an option of asymmetrically encrypting ID Token with the publ= ic key of the client, which authenticates the client even further.=C2=A0
Even further, the Connect has an option of asymmetrically encrypting the re= quest with the public key of the server, which authenticates the server in = addition to TLS. =C2=A0
  • User Authentication=C2=A0<= /li>
    • Both OpenID Connect and A4C return ID tokens which contain pret= ty much the same information
    • A4C has additional features t= o allow clients to negotiate level of authentication and authentication typ= es (min LOA,ACR,AMR) in addition to just returning ACR as in the case of Op= enID.
What's the point of having both= minimum LoA and AMR instead of ACR? =C2=A0Connect can also return AMR.=C2= =A0
If you really wanted to have amr_values like feature, you can= actually request it by using Claims request as

{ "id_= token": {"amr": {"values": ["otp","= rsa"] }}}
=C2=A0
=
    • A4C only make re-auth lighter weight. No need to issue UserInfo tokens = again. Re-auth also re-authenticates the client as well as user.
    <= /ul>
=C2=A0I RFC6749 Section 5.1 REQUIRES an a= ccess token to be returned. A4C is diverting from RFC6749. A4C is NOT OAuth= anymore. The very reason OpenID Connect returns an access token from the t= oken endpoint always is to adhere to RFC6749.=C2=A0

OpenID Connect with scope=3Dopenid only is essentially = the authN only operation.=C2=A0

  • Privacy Option
      • The A4C=E2=80=99s authentication of the client makes it possible to issue = client-specific subject identifiers. This prevents multiple clients from co= lluding to share information.
This is supported by OpenID Connect= as well. =C2=A0
    • Because Connect doesn= =E2=80=99t know who the client is, the subject identifier returned is unive= rsal.
As stated above, this is = false. It can even return PPID in the case of public client as well.=C2=A0<= /div>
    • The s= pec could be used for pseudonymous authentication.
As state above, OpenID Connect supp= orts this. It in fact advise the use of PPID (Pairwise Psuedonymous Identif= ier in section 17.3).=C2=A0
=C2=A0

As you can see= the specs are doing similar things, but they have different security featu= res.

As stated above, I d= o not see much. It has less option in general, and added feature is the amr= _values and min_alv, which I do not see much value in it but if you really = wanted, you can extend the Connect.=C2=A0
=C2=A0
=

As for need:
  • There are many sites using = social network providers to authenticate using 6749 only, there are ongoing= security concerns that many of us have blogged about. This may rise to = the level of BUG on 6749.
Why not just use OpenID Connect? =C2=A0<= /div>
  • Some social network provid= ers have indicated a willingness to support an authenticate only feature. I= also had an inquiry if A4C can be supported in OAuth1 as well as OAuth2. S= ome of this may be coming from a business decision to use a proprietary use= r profile API instead (this is not Oracle=E2=80=99s position).
Authen only is fine with OpenID Connect.= You can also use proprietary or whatever the user profile API "in add= ition". For the purpose of interoperability, it is better to have a st= andard user profile API though, and that's why Connect defines a very b= asic one for this purpose. =C2=A0
  • There is = a consent problem because normal 6749 use requires users to consent to shar= ing information. Client developers in many cases would like an authen only = profile where consent is implicit.
That's an implementation issue. RFC = 6749 does not require the users to provide explicit consent.=C2=A0
It just states:=C2=A0

=C2=A0the authorization server authenticates the resou= rce owner and obtains
   an authorization decision (by asking the resource owner o=
r by=C2=A0
=C2=A0 = =C2=A0establishing approval via other means).=C2=A0

It can be implicit.=C2=A0
  • Developers have been indicating that defining new user-id/pwds= =C2=A0and additionally sharing of profile information both cut back on the= %age success of new user registrations. Many want to offer an authenticate= only option for their users where the users explicitly decide what to supp= ly in their profile. =C2=A0Pseudonymous authen is a basic feature.
This is supported by OpenID Connect as I= stated above. =C2=A0
  • I see other areas (e.g. Ki= tten) where authentication and re-authentication may be of interest to othe= r IETF groups.
    • There may be much broader requirements in the IE= TF community that are not of interest to OpenID Connect and its objectives<= /li>


Why n= ot?=C2=A0
=C2=A0
While it is = reasonable to make A4C and Connect as compatible as possible, I am not sure= they can be compatible. A4C and Connect are two different flows solving di= fferent use cases with different security characteristics.

Why not? I do not see it. You are es= sentially reading OpenID Connect wrong.=C2=A0
=C2=A0

Note: I do not= believe that the A4C draft is ready for last call-it is intended only as i= nput to the WG process. The features and aspects like how the flow is initi= ated need to be discussed within the wider IETF community where broad conse= nsus can be obtained. This is why I feel having it a work group milestone i= s important and I am willing to contribute my time towards it.

Since it adds essentially noth= ing and produces wait-and-see among the implementers, I think accepting thi= s work as an work group item is actively harmful for the internet. If somet= hing is needed to worked on in the work group, I would rather want to see a= profile of OpenID Connect referencing it. That causes much less confusion.= =C2=A0
=C2=A0
=

Because of the ongoing issue of inappropriate use of 6749 and th= e broader requirements within the IETF, I feel this work needs to be discus= sed within the IETF WG.=C2=A0


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--14dae93d93d4f7a85b04f9f2afbe-- From nobody Wed May 21 18:11:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E281A0018 for ; Wed, 21 May 2014 18:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 dgSnzxrrQKIl for ; Wed, 21 May 2014 18:11:15 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587DC1A0011 for ; Wed, 21 May 2014 18:11:14 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id s7so2085216lbd.22 for ; Wed, 21 May 2014 18:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0EoZpVLDaxuznvGhTosxP22OnEspVJyV7bqF0fGmxDc=; b=U8qQYCz7iGdanWYzjYkFg/pTX2HzzzBzoCgaM3yCKhiDKuw9EN6qnnv4kamX4ET8EY 1Mp3KwB6fWsrph8vpxxcmwCAa1lu5877m1k/SH5qOgHaU4/4shOwubTcRLfCQ7e0jbi/ ATx5yskj1u7iU+v9CWnptfg3VovfuJEZaFZpZY3t1SS6G4ts0DtyamSOIjCmdQO7xxSU b7meLmcWtSxHKy3VbRQM9pYDW708VwBpPAGj10igbrlQFsV8f3ycp+ziYJzWjuCjOqdw FUKQiS+9tRgKvk0UYfpwnpHvBtlbSlEyCuKO+qb/T0GBS33nPIDIIlr2udcLwaEr7uE9 8S0Q== MIME-Version: 1.0 X-Received: by 10.112.13.35 with SMTP id e3mr33103129lbc.44.1400721071824; Wed, 21 May 2014 18:11:11 -0700 (PDT) Received: by 10.112.105.134 with HTTP; Wed, 21 May 2014 18:11:11 -0700 (PDT) In-Reply-To: <537B5F2B.9090501@redhat.com> References: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> <1400275641.37471.YahooMailNeo@web142803.mail.bf1.yahoo.com> <537B5F2B.9090501@redhat.com> Date: Thu, 22 May 2014 10:11:11 +0900 Message-ID: From: Nat Sakimura To: Anil Saldhana Content-Type: multipart/alternative; boundary=001a11c3b5dcea66bb04f9f2c9a3 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/87u15wB70TwcvJcA_ycAgdQGWXA Cc: oauth Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 01:11:26 -0000 --001a11c3b5dcea66bb04f9f2c9a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good! I achieve the purpose :-) So what would be the appropriate length? The current one would do? 2014-05-20 22:56 GMT+09:00 Anil Saldhana : > Brian - I agree with you. It should be MUST as long as the hard limit > is generous for usage. > > > > > On 05/20/2014 07:09 AM, Brian Campbell wrote: > > I'd say it should be a MUST so that implementations are consistent about > it. > > > On Fri, May 16, 2014 at 3:27 PM, Bill Mills wrote= : > >> The HTTP specs don't limit these things, but implementations do, and >> the problems when you run into them are a rea pain. >> >> DO we want to make this a hard limit, or should it be guidance in the >> form of RECOMMENDED or SHOULD? >> >> On Friday, May 16, 2014 9:35 AM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> Yeah, I agree with John here. There are a few good reasons to >> restrict the length of the code_challenge. One is trying to keep the >> authorization request URI to reasonable size as it will eventually run i= nto >> various limits on clients and/or servers. The other is constraining the >> amount of data that an AS needs to store per code. >> >> >> >> >> On Fri, May 16, 2014 at 7:41 AM, John Bradley wrote: >> >> From the AS side you probably want to know what the max size you need to >> store per code. >> >> On the call to the token endpoint it is a POST so size should not be an >> issue. >> >> >> On May 16, 2014, at 3:10 PM, Nat Sakimura wrote: >> >> Now that I cannot remember what limit we were hitting, it might be a >> good idea to remove the constraint and see if anyone protests. >> >> What do you think? >> >> Nat >> >> >> 2014-05-14 20:46 GMT+09:00 Brian Campbell : >> >> That too would suggest that the length limit be on code_challenge becaus= e >> that's the parameter that will be on URIs getting passed around. The >> code_verifier is sent directly in the POST body from client to AS. >> >> >> On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura wrote= : >> >> +1 for octet. We used to have "bytes" in JW* so I used "bytes" here, >> while at the same time complaining in Jose that it should be "octet". JW= * >> changed to "octet" but I failed to sync with it in the last few edits. >> >> I do not quite remember which platform, but the reason for the limit >> was that some platform had some limitations as to the length of the stin= g >> to be passed to it through URI and we did not want the challenges to be >> truncated by that limit. >> >> Best, >> >> Nat >> >> >> 2014-05-13 6:56 GMT+09:00 Brian Campbell : >> >> And it'd give the AS some direct guidance on protecting itself from >> crazy long code_challenge values rather than relying on the client not t= o >> do something creative. >> >> >> On Mon, May 12, 2014 at 3:54 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >> Right but that's why I'm asking why not just put the limit on >> code_challange rather than inferring it from code_verifyer + challenge >> algorithm, which probably bounds it but doesn't necessarily do so? It's = not >> a big deal but would read more clearly, I think. >> >> >> On Mon, May 12, 2014 at 3:48 PM, John Bradley wrote: >> >> I think octets is more consistent with other JW* and OAuth specs. >> >> The code_challange is the same length as the code_verifyer or is a hash >> of the code_verifyer so likely smaller than 128octets (43 ish for base64 >> 256 bit) >> >> Limiting the code_verifyer size sets the upper bound for code_challange, >> unless someone comes up with a really creative code challenge algorithm. >> >> I will talk to nat about changing it to octets when I see him tomorrow. >> >> John B. >> >> On May 12, 2014, at 11:15 PM, Derek Atkins wrote: >> >> > Brian Campbell writes: >> > >> >> I notice that code_verifier is defined as "high entropy cryptographic >> random >> >> string of length less than 128 bytes" [1], which brought a few >> questions and >> >> comments to mind. So here goes: >> >> >> >> Talking about the length of a string in terms of bytes is always >> potentially >> >> confusing. Maybe characters would be an easier unit for people like m= e >> to wrap >> >> their little brains around? >> > >> > It depends if it really is characters or bytes. For example there are >> > many multi-byte UTF-8 characters, so if it really is bytes then saying >> > characters is wrong because it could overflow. So let's make sure we >> > know what we're talking about. Historically, if we're talking bytes t= he >> > IETF often uses the phrase "octets". Would that be less confusing? >> > >> >> Why are we putting a length restriction on the code_verifier anyway? >> It seems >> >> like it'd be more appropriate to restrict the length of the >> code_challenge >> >> because that's the thing the AS will have to maintain somehow (store >> in a DB >> >> or memory or encrypt into the code). Am I missing something here? >> >> >> >> Let me also say that I hadn't looked at this document since its early >> days in >> >> draft -00 or -01 last summer but I like the changes and how it's been >> kept >> >> pretty simple for the common use-case while still allowing for crypto >> agility/ >> >> extension. Nice work! >> >> >> >> [1] >> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 >> > >> > -derek >> > >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > -- >> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >> > Member, MIT Student Information Processing Board (SIPB) >> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >> > warlord@MIT.EDU PGP key available >> >> >> >> >> -- >> [image: Ping Identity logo] >> Brian Campbell >> Portfolio Architect >> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect >> with us=E2=80=A6 [image: twitter logo] [image: >> youtube logo] [image: >> LinkedIn logo] [image: Facebook >> logo] [image: Google+ logo]<= https://plus.google.com/u/0/114266977739397708540> [image: >> slideshare logo] [image: >> flipboard logo] [image: rss feed icon] >> [image: Register for Cloud Identity Summit 2014 | Modern Identity >> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >> >> >> >> >> -- >> [image: Ping Identity logo] >> Brian Campbell >> Portfolio Architect >> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect >> with us=E2=80=A6 [image: twitter logo] [image: >> youtube logo] [image: >> LinkedIn logo] [image: Facebook >> logo] [image: Google+ logo]<= https://plus.google.com/u/0/114266977739397708540> [image: >> slideshare logo] [image: >> flipboard logo] [image: rss feed icon] >> [image: Register for Cloud Identity Summit 2014 | Modern Identity >> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >> >> >> _______________________________________________ >> 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 >> >> >> >> >> -- >> [image: Ping Identity logo] >> Brian Campbell >> Portfolio Architect >> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect >> with us=E2=80=A6 [image: twitter logo] [image: >> youtube logo] [image: >> LinkedIn logo] [image: Facebook >> logo] [image: Google+ logo]<= https://plus.google.com/u/0/114266977739397708540> [image: >> slideshare logo] [image: >> flipboard logo] [image: rss feed icon] >> [image: Register for Cloud Identity Summit 2014 | Modern Identity >> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >> >> >> >> >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> >> _______________________________________________ >> 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 > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c3b5dcea66bb04f9f2c9a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good! I achieve the purpose :-)

So what= would be the appropriate length?=C2=A0
The current one would do?= =C2=A0


2014-05-20 22:56 GMT+09:00 Anil Saldhana <Anil.Saldhana@redhat= .com>:
=20 =20 =20
Brian - I agree with you.=C2=A0 It should be MUST as long as the hard limit is generous for usage.




On 05/20/2014 07:09 AM, Brian Campbell wrote:
I'd say it should be a MUST so that implementati= ons are consistent about it.


On Fri, May 16, 2014 at 3:27 PM, Bill Mills <wmills_92105@yahoo.com> wrote:
The HTTP specs don't limit these things, but implementations do, and the problems when you run into them are a rea pain.

DO we want to make this a hard limit, or should it be guidance in the form of RECOMMENDED or SHOULD?

On Friday, May 16, 2014 9:35 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Yeah, I agree with John here. There are a few good reasons to restrict the length of the code_challenge. One is trying to keep the authorization request URI to reasonable size as it will eventually run into various limits on clients and/or servers. The other is constraining the amount of data that an AS needs to store per code.




On Fri, May 16, 2014 at 7:41 AM, John Bradley &l= t;ve7jtb@ve7jtb.com> wrote:
From the AS side you probably want to know what the max size you need to store per code.

On the call to the token endpoint it is a POST so size should not be an issue. =C2=A0


On May 16, 2014, at 3:10 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Now that I cannot remember what limit we were hitting, it might be a good idea to remove the constraint and see if anyone protests.=C2=A0

What do you think?=C2=A0

Nat


2014-05-14 20:46 GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:
= That too would suggest that the length limit be on code_challenge because that'= s the parameter that will be on URIs getting passed around. The code_verifier is sent directly in the POST body from client to AS.


On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura <sakimura@gmail.com> wrote:
= +1 for octet. We used to have "bytes"= in JW* so I used "bytes"= here, while at the same time complaining in Jose that it should be "octet"= . JW* changed to "octet"= but I failed to sync with it in the last few edits.=C2=A0

I do not quite remember which platform, but the reason for the limit was that some platform had some limitations as to the length of the sting to be passed to it through URI and we did not want the challenges to be truncated by that limit.=C2=A0

Best,=C2=A0<= /div>

Nat


2014-05-13 6:56 GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:

= And it'd give the AS some direct guidance on protecting itself from crazy long code_challenge values rather than relying on the client not to do something creative.


On Mon, May 12, 2014 at 3:54 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:<= br clear=3D"none">
= Right but that's wh= y I'm asking wh= y not just put the limit on code_challange rather than inferring it from code_verifyer + challenge algorithm, which probably bounds it but doesn't necessarily do so? It's not = a big deal but would read more clearly, I think.


On Mon, May 12, 2014 at 3:48 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I think octets is more consistent with other JW* and OAuth specs.

The code_challange is the same length as the code_verifyer or is a hash of the code_verifyer so likely smaller than 128octets (43 ish for base64 256 bit)

Limiting the code_verifyer size sets the upper bound for code_challange, unless someone comes up with a really creative code challenge algorithm.

I will talk to nat about changing it to octets when I see him tomorrow.

John B.

On May 12, 2014, at 11:15 PM, Derek Atkins <warlord@MIT.EDU> wrote:

> Brian Campbell <bcampbell@pingidentity.com> writes:
>
>> I notice that code_verifier is defined as "high entrop= y cryptographic random
>> string of length less than 128 bytes" =C2= =A0[1], which brought a few questions and
>> comments to mind. So here goes:
>>
>> Talking about the length of a string in terms of bytes is always potentially
>> confusing. Maybe characters would be an easier unit for people like me to wrap
>> their little brains around?
>
> It depends if it really is characters or bytes. =C2=A0For example there are
> many multi-byte UTF-8 characters, so if it really is bytes then saying
> characters is wrong because it could overflow. =C2=A0S= o let's make sure we
> know what we're talking about. =C2=A0Historicall= y, if we're talking bytes the
> IETF often uses the phrase "octets"= ;. =C2=A0Would that = be less confusing?
>
>> Why are we putting a length restriction on the code_verifier anyway? It seems
>> like it'd be more appropriate to restrict the length of the code_challenge >> because that'= s the thing the AS will have to maintain somehow (store in a DB
>> or memory or encrypt into the code). Am I missing something here?
>>
>> Let me also say that I hadn't looked at this document since its early days in
>> draft -00 or -01 last summer but I like the changes and how it's been kept
>> pretty simple for the common use-case while still allowing for crypto agility/
>> extension. Nice work!
>>
>> [1] http://tools.ietf.org/ht= ml/draft-sakimura-oauth-tcse-03#section-3.3
>
> -derek
>
>> _________________= ______________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth >
> --
> =C2=A0 =C2= =A0 =C2=A0 Derek Atkins, SB '93 MIT EE= , SM '95 MIT Media Laboratory
> =C2=A0 =C2= =A0 =C2=A0 Member, MIT Student Information Processing Board =C2=A0(SIPB= )
> =C2=A0 =C2= =A0 =C2=A0 URL: http://web.mit.edu/warlord/ =C2=A0 =C2=A0PP-ASEL-IA =C2=A0 =C2=A0 N1= NWH
> =C2=A0 =C2= =A0 =C2=A0 warlord@MIT.EDU =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PGP key available




--
3D"Ping
Brian Campbell Portfolio Architect
@ bcampbell@pingidentity.com
3D"phone= +1 720.317.2061<= /span>
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedI= 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipbo=
3D"Register




--
3D"Ping
Brian Campbell Portfolio Architect
@ bcampbell@pingidentity.com
3D"phone= +1 720.317.2061<= /span>
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedI= 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipbo=
3D"Register


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

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http:= //nat.sakimura.org/
@_nat_en



--
3D"Ping
Brian Campbell Portfolio Architect
@ bcampbell@pingidentity.com
3D"phone= +1 720.317.2061<= /span>
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedI= 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipbo=
3D"Register




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://= nat.sakimura.org/
@_nat_en



__________________________________________= _____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/li= stinfo/oauth





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


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c3b5dcea66bb04f9f2c9a3-- From nobody Wed May 21 18:14:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA951A0018 for ; Wed, 21 May 2014 18:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 6O7wny22cTdI for ; Wed, 21 May 2014 18:13:57 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3231A0020 for ; Wed, 21 May 2014 18:13:56 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id mc6so2168351lab.35 for ; Wed, 21 May 2014 18:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+So+aeSR/vGliXZwLUcd65O0jgVqV14BLR4VpUkjPIQ=; b=v2RbU9N6kSBf/l1kEOJ9+C7N43QjKE2HyBiBPkvD28ZG0unA0F64uSdmXoUSbTD3cQ Zn850WN6i3chTKoOYEoWxkepSZP2s46tATF9HwjJCFDXYZrTaxQpzPprgio8BeyWTk31 58GHL1iwbxGnuKUCDwiHYwGEa7jGFWE7Gknu7L+bc6BbwKJslC9tSNTYkf6QrbT9vgjH 9FZSCIMd0cdO3bmSSNg8CvUUsCrzeBA7bqvUViLZAcLak09Xc+gViHOZEF0q3+zS3lNP QbfYAlHSTDHOzRhnKLIMc1beT3K8JY9IMZF9/FPZDe1IBWcMPhkbzS0QJG9UYsbHFYir Mo5Q== MIME-Version: 1.0 X-Received: by 10.112.159.7 with SMTP id wy7mr20527021lbb.4.1400721234279; Wed, 21 May 2014 18:13:54 -0700 (PDT) Received: by 10.112.105.134 with HTTP; Wed, 21 May 2014 18:13:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 10:13:54 +0900 Message-ID: From: Nat Sakimura To: Josh Mandel Content-Type: multipart/alternative; boundary=001a11c2909899449204f9f2d36d Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/7c4nmcW0BXLIBajPH_2elpRlhE4 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Security considerations in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 01:14:01 -0000 --001a11c2909899449204f9f2d36d Content-Type: text/plain; charset=UTF-8 Thanks. I will push it to the next rev. 2014-05-15 8:43 GMT+09:00 Josh Mandel : > Forgive me if this is well-trodden territory, but I would have expected > the security considerations in this proposal to include a note to the > effect of: > > "In a scenario where a mobile client is contending with malicious apps on > the same device that listen on the same custom URL scheme, it's important > to keep in mind that a malicious app can initiate its own authorization > request. Such a request would appear the same as a legitimate request from > the end-user's perspective. So in this case, a malicious app could request > its own verifier code and successfully obtain authorization using the tcse > protocol." > > Obviously this does not negate the value of the proposal, but it's > something I'd expect readers to keep in mind. > > In particular, it has very strong implications for whitelisted > authorizations, where no end user interaction is required. In such a case, > a malicious app could initiate a request at any time and the user would not > be in the loop to raise a question about its legitimacy. > > On May 9, 2014 4:51 PM, "Brian Campbell" > wrote: > > > > I notice that code_verifier is defined as "high entropy cryptographic > random string of length less than 128 bytes" [1], which brought a few > questions and comments to mind. So here goes: > > > > Talking about the length of a string in terms of bytes is always > potentially confusing. Maybe characters would be an easier unit for people > like me to wrap their little brains around? > > > > Why are we putting a length restriction on the code_verifier anyway? It > seems like it'd be more appropriate to restrict the length of the > code_challenge because that's the thing the AS will have to maintain > somehow (store in a DB or memory or encrypt into the code). Am I missing > something here? > > > > Let me also say that I hadn't looked at this document since its early > days in draft -00 or -01 last summer but I like the changes and how it's > been kept pretty simple for the common use-case while still allowing for > crypto agility/extension. Nice work! > > > > [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 > > > > _______________________________________________ > > 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 > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c2909899449204f9f2d36d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks. I will push it to the next rev.=C2=A0


2014-05-15 8:43 GMT+= 09:00 Josh Mandel <jmandel@gmail.com>:

Forgive me if this is well-tr= odden territory, but I would have expected the security considerations in t= his proposal to include a note to the effect of:

"In a scenario where a mobile client is contending with= malicious apps on the same device that listen on the same custom URL schem= e, it's important to keep in mind that a malicious app can initiate its= own authorization request. Such a request=C2=A0 would appear the same as a= legitimate request from the end-user's perspective. So in this case, a= malicious app could request its own verifier code and successfully obtain = authorization using the tcse protocol."

Obviously this does not negate the value of the proposal, bu= t it's something I'd expect readers to keep in mind.

In particular, it has very strong implications for whitelist= ed authorizations, where no end user interaction is required. In such a cas= e, a malicious app could initiate a request at any time and the user would = not be in the loop to raise a question about its legitimacy.

On May 9, 2014 4:51 PM, "Brian Campbell" <bcampbell@pingid= entity.com> wrote:
>
> I notice that code_verifier is defined as "high entropy cryptogra= phic random string of length less than 128 bytes"=C2=A0 [1], which bro= ught a few questions and comments to mind. So here goes:
>
> Talking about the length of a string in terms of bytes is always poten= tially confusing. Maybe characters would be an easier unit for people like = me to wrap their little brains around?
>
> Why are we putting a length restriction on the code_verifier anyway? I= t seems like it'd be more appropriate to restrict the length of the cod= e_challenge because that's the thing the AS will have to maintain someh= ow (store in a DB or memory or encrypt into the code). Am I missing somethi= ng here?
>
> Let me also say that I hadn't looked at this document since its ea= rly days in draft -00 or -01 last summer but I like the changes and how it&= #39;s been kept pretty simple for the common use-case while still allowing = for crypto agility/extension. Nice work!
>
> [1] http://tools.ietf.org/html/draft-sakimura-o= auth-tcse-03#section-3.3
>
> _______________________________________________
> 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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c2909899449204f9f2d36d-- From nobody Wed May 21 18:21:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6021A0013 for ; Wed, 21 May 2014 18:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 sn0AIqAsPkwU for ; Wed, 21 May 2014 18:21:08 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465091A0012 for ; Wed, 21 May 2014 18:21:08 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id q107so4550329qgd.24 for ; Wed, 21 May 2014 18:21:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=BtDWtJYtuc4h2JgAWS3XmaAz5N0AXam2yb1Nbjq7FDE=; b=fhCyIh4fpIQuTY2NE9wDa5wm/1bp/VNfGpUIKnU53wUlPjsszIOqPawSa7vAqudDoj YRMO0OXiA9TWuKV2zY/VRSN56FmbfADf3+v4U2cdItQZ9grJbj3nLCZZLk8BxLnK7MFA khnc+RLkbY3EmO/UgK+6EwAa0aRTfOFwVfaXk4zuoyBs1Q7PeL30vc+R9RXtFL3I37Vs TDXOc6lKJ9TnoSyfo948+rPJSmh/w/AD/BzMFKP7pcKACEXbov10MB8ja3ee6EH7C/SO IHa1onchVtwu+Sua7XtVS71gRab2YwfH/RlOx5+qtz+whO5FoTvMqNhhre6A6Wm3Ouey BXug== X-Gm-Message-State: ALoCoQksg0VzJZxTCj8MSsLWoShlEQmaSMqApckRFBrpiV1EeN2Q/06lI5YI1ruQIG3ghNBEaERC X-Received: by 10.224.71.145 with SMTP id h17mr45246790qaj.74.1400721666669; Wed, 21 May 2014 18:21:06 -0700 (PDT) Received: from [10.180.232.104] (133.sub-70-215-4.myvzw.com. [70.215.4.133]) by mx.google.com with ESMTPSA id w101sm1769931qge.12.2014.05.21.18.21.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 18:21:01 -0700 (PDT) References: <75D99637-1802-4C1F-83BE-D62AD938F9F4@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-FD861029-2480-4E96-AF7D-2629F29CB14F; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D201) From: John Bradley Date: Wed, 21 May 2014 21:20:58 -0400 To: Nat Sakimura Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/IyxfHQ19dQERechT5Romc54jel4 Cc: OAuth WG Subject: Re: [OAUTH-WG] Authen Milestone: Comparing current A4C proposal to OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 01:21:11 -0000 --Apple-Mail-FD861029-2480-4E96-AF7D-2629F29CB14F Content-Type: multipart/alternative; boundary=Apple-Mail-F2FFE4D4-0975-4803-9E18-318E234FE9D7 Content-Transfer-Encoding: 7bit --Apple-Mail-F2FFE4D4-0975-4803-9E18-318E234FE9D7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Nat. I can't add anything to your response.=20 Let's base our decision on adding authentication to OAuth 2 on reality.=20 Having a profile of Connect with most of the features Phil is looking for sh= ould not be a hard thing. I don't personally think it is required to have t= hat happen in the OAuth WG.=20 John B Sent from my iPhone > On May 21, 2014, at 9:03 PM, Nat Sakimura wrote: >=20 > Phil, please do not misinform the working group.=20 >=20 > My responses inline:=20 >=20 >=20 > 2014-05-22 3:56 GMT+09:00 Phil Hunt : >> Since several have voiced the opinion that the WG should not work on prov= iding user authentication context because OpenID Connect already has a solut= ion, I wanted to make clear how A4C is different from OpenID Connect. >>=20 >> OpenID Connect supports providing clients an =E2=80=9Cid_token=E2=80=9D u= sing the id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybri= d Auth) of the OAuth Core. >> http://openid.net/specs/openid-connect-core-1_0.html >>=20 >> The A4C draft that was put forward by Mike, Tony, and myself ( draft-hunt= -oauth-v2-user-a4c ) describes a flow similar to the code flow of normal OAu= th. Here are the differences from Connect: >>=20 >> Client Authentication >> Connect does NOT authenticate the client prior to returning the id token.= The Connect flow is single step returning ID_TOKEN to an unauthenticated cl= ient in both 3.2 and 3.3. Use of code flow in 3.3 appears only for the purpo= se of issuing an access token (user info token). >> The A4C flow is 2-step following the OAuth2 code flow. It requires a code= to be exchanged for ID_TOKEN after client authenticates in the second step (= exactly duplicating the normal OAuth flow). A4C requires mutual authenticat= ion of clients and AS service providers. A4C has the same logic and security= properties of the normal OAuth authorization flow. > This is not true.=20 >=20 > Connect for Code Flow for confidential client DOES authenticate the client= before getting an ID Token.=20 >=20 > Further, the Connect has an option of asymmetrically encrypting ID Token w= ith the public key of the client, which authenticates the client even furthe= r.=20 > Even further, the Connect has an option of asymmetrically encrypting the r= equest with the public key of the server, which authenticates the server in a= ddition to TLS. =20 >> User Authentication=20 >> Both OpenID Connect and A4C return ID tokens which contain pretty much th= e same information >> A4C has additional features to allow clients to negotiate level of authen= tication and authentication types (min LOA,ACR,AMR) in addition to just retu= rning ACR as in the case of OpenID. > What's the point of having both minimum LoA and AMR instead of ACR? Conne= ct can also return AMR.=20 > If you really wanted to have amr_values like feature, you can actually req= uest it by using Claims request as >=20 > { "id_token": {"amr": {"values": ["otp","rsa"] }}} > =20 >> A4C only make re-auth lighter weight. No need to issue UserInfo tokens ag= ain. Re-auth also re-authenticates the client as well as user. > I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C is div= erting from RFC6749. A4C is NOT OAuth anymore. The very reason OpenID Connec= t returns an access token from the token endpoint always is to adhere to RFC= 6749.=20 >=20 > OpenID Connect with scope=3Dopenid only is essentially the authN only oper= ation.=20 >=20 >> Privacy Option >> The A4C=E2=80=99s authentication of the client makes it possible to issue= client-specific subject identifiers. This prevents multiple clients from co= lluding to share information. > This is supported by OpenID Connect as well. =20 >> Because Connect doesn=E2=80=99t know who the client is, the subject ident= ifier returned is universal. > As stated above, this is false. It can even return PPID in the case of pub= lic client as well.=20 >> The spec could be used for pseudonymous authentication. > As state above, OpenID Connect supports this. It in fact advise the use of= PPID (Pairwise Psuedonymous Identifier in section 17.3).=20 > =20 >>=20 >> As you can see the specs are doing similar things, but they have differen= t security features. >=20 > As stated above, I do not see much. It has less option in general, and add= ed feature is the amr_values and min_alv, which I do not see much value in i= t but if you really wanted, you can extend the Connect.=20 > =20 >>=20 >> As for need: >> There are many sites using social network providers to authenticate using= 6749 only, there are ongoing security concerns that many of us have blogged= about. This may rise to the level of BUG on 6749. > Why not just use OpenID Connect?=20 >> Some social network providers have indicated a willingness to support an a= uthenticate only feature. I also had an inquiry if A4C can be supported in O= Auth1 as well as OAuth2. Some of this may be coming from a business decision= to use a proprietary user profile API instead (this is not Oracle=E2=80=99s= position). > Authen only is fine with OpenID Connect. You can also use proprietary or w= hatever the user profile API "in addition". For the purpose of interoperabil= ity, it is better to have a standard user profile API though, and that's why= Connect defines a very basic one for this purpose. =20 >> There is a consent problem because normal 6749 use requires users to cons= ent to sharing information. Client developers in many cases would like an au= then only profile where consent is implicit. > That's an implementation issue. RFC 6749 does not require the users to pro= vide explicit consent.=20 > It just states:=20 >=20 > the authorization server authenticates the resource owner and obtains > an authorization decision (by asking the resource owner or by=20 > establishing approval via other means).=20 >=20 > It can be implicit.=20 >> Developers have been indicating that defining new user-id/pwds and addit= ionally sharing of profile information both cut back on the %age success of n= ew user registrations. Many want to offer an authenticate only option for th= eir users where the users explicitly decide what to supply in their profile.= Pseudonymous authen is a basic feature. > This is supported by OpenID Connect as I stated above. =20 >> I see other areas (e.g. Kitten) where authentication and re-authenticatio= n may be of interest to other IETF groups. >> There may be much broader requirements in the IETF community that are not= of interest to OpenID Connect and its objectives >=20 > Why not?=20 > =20 >> While it is reasonable to make A4C and Connect as compatible as possible,= I am not sure they can be compatible. A4C and Connect are two different flo= ws solving different use cases with different security characteristics. >=20 > Why not? I do not see it. You are essentially reading OpenID Connect wrong= .=20 > =20 >>=20 >> Note: I do not believe that the A4C draft is ready for last call-it is in= tended only as input to the WG process. The features and aspects like how th= e flow is initiated need to be discussed within the wider IETF community whe= re broad consensus can be obtained. This is why I feel having it a work grou= p milestone is important and I am willing to contribute my time towards it. >=20 > Since it adds essentially nothing and produces wait-and-see among the impl= ementers, I think accepting this work as an work group item is actively harm= ful for the internet. If something is needed to worked on in the work group,= I would rather want to see a profile of OpenID Connect referencing it. That= causes much less confusion.=20 > =20 >>=20 >> Because of the ongoing issue of inappropriate use of 6749 and the broader= requirements within the IETF, I feel this work needs to be discussed within= the IETF WG.=20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-F2FFE4D4-0975-4803-9E18-318E234FE9D7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks Nat. I can't add anything to yo= ur response. 

Let's base our decision on addin= g authentication to OAuth 2 on reality. 

Havin= g a profile of Connect with most of the features Phil is looking for should n= ot be a hard thing.   I don't personally think it is required to have t= hat happen in the OAuth WG. 


Jo= hn B

Sent from my iPhone

On May 21, 2014, at 9:03 PM, N= at Sakimura <sakimura@gmail.com= > wrote:

Phi= l, please do not misinform the working group. 

My re= sponses inline: 


2014-05-22 3:56 GMT+09:00 Phil Hunt <phil.hunt@oracle.com>:
Since several have voiced= the opinion that the WG should not work on providing user authentication co= ntext because OpenID Connect already has a solution, I wanted to make clear h= ow A4C is different from OpenID Connect.

OpenID Connect supports providing clients an =E2=80=9Cid_toke= n=E2=80=9D using the id_token response type in section 3.2 (ImplicitAuth) an= d 3.3 (Hybrid Auth) of the OAuth Core.

The A4C draft that was put forward by Mike, Tony, and my= self ( draft-hunt-oauth-v2-user-a4c ) desc= ribes a flow similar to the code flow of normal OAuth. Here are the differen= ces from Connect:

  • Client Authentication
    • Connect does N= OT authenticate the client prior to returning the id token. The Connect flow= is single step returning ID_TOKEN to an unauthenticated client in both 3.2 a= nd 3.3. Use of code flow in 3.3 appears only for the purpose of issuing an a= ccess token (user info token).
    • The A4C flow is 2-step following the OAuth2 code flow. It requires a cod= e to be exchanged for ID_TOKEN after client authenticates in the second step= (exactly duplicating the normal OAuth flow).  A4C requires mutual auth= entication of clients and AS service providers. A4C has the same logic and s= ecurity properties of the normal OAuth authorization flow.
This is not tr= ue. 

Connect for Code Flow for confidential client DOES authenticate the clien= t before getting an ID Token. 

Further, the= Connect has an option of asymmetrically encrypting ID Token with the public= key of the client, which authenticates the client even further. 
=
Even further, the Connect has an option of asymmetrically encrypting the req= uest with the public key of the server, which authenticates the server in ad= dition to TLS.  
  • User Authentication 
    • Both OpenID Connect and A4C return ID tokens which contain pretty= much the same information
    • A4C has additional features to a= llow clients to negotiate level of authentication and authentication types (= min LOA,ACR,AMR) in addition to just returning ACR as in the case of OpenID.=
What's the point of having both mini= mum LoA and AMR instead of ACR?  Connect can also return AMR. 
If you really wanted to have amr_values like feature, you can actuall= y request it by using Claims request as

  • There is a c= onsent problem because normal 6749 use requires users to consent to sharing i= nformation. Client developers in many cases would like an authen only profil= e where consent is implicit.
That's an implementation issue. RFC 6749 d= oes not require the users to provide explicit consent. 
It ju= st states: 

 the authorization server authenticates the resource owner= and obtains
   an authorization decision (by asking the resource owner or b=
y 
  &nbs= p;establishing approval via other means). 

It can be implicit. 
  • Developers have been indicating that defining new user-id/pwds &= nbsp;and additionally sharing of profile information both cut back on the %a= ge success of new user registrations. Many want to offer an authenticate onl= y option for their users where the users explicitly decide what to supply in= their profile.  Pseudonymous authen is a basic feature.
This is supported by OpenID Connect as I s= tated above.  
  • I see other areas (e.g. Kit= ten) where authentication and re-authentication may be of interest to other I= ETF groups.
    • There may be much broader requirements in the IETF c= ommunity that are not of interest to OpenID Connect and its objectives


Why no= t? 
 
While it is r= easonable to make A4C and Connect as compatible as possible, I am not sure t= hey can be compatible. A4C and Connect are two different flows solving diffe= rent use cases with different security characteristics.

Why not? I do not see it. You are ess= entially reading OpenID Connect wrong. 
 

Note: I do not b= elieve that the A4C draft is ready for last call-it is intended only as inpu= t to the WG process. The features and aspects like how the flow is initiated= need to be discussed within the wider IETF community where broad consensus c= an be obtained. This is why I feel having it a work group milestone is impor= tant and I am willing to contribute my time towards it.

Since it adds essentially nothi= ng and produces wait-and-see among the implementers, I think accepting this w= ork as an work group item is actively harmful for the internet. If something= is needed to worked on in the work group, I would rather want to see a prof= ile of OpenID Connect referencing it. That causes much less confusion. =
 

Because of the ongoing issue of inappropriate use of 6749 and the= broader requirements within the IETF, I feel this work needs to be discusse= d within the IETF WG. 


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




--
Nat Sakim= ura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-F2FFE4D4-0975-4803-9E18-318E234FE9D7-- --Apple-Mail-FD861029-2480-4E96-AF7D-2629F29CB14F Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwNTIyMDEyMDU4WjAjBgkqhkiG9w0BCQQxFgQUeKSoSYo5H0KGaOgj Phz9F0Ore1cwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEADwVH4j7Qul24dj6lnldxwJ5+p1TYoqkUoAr4AXyPxIHz0cZl 6eySp4yANDLHdPmIn8Zi8zmCWcUHAl7+uEYOqfcB83jyc7eBXriHt/SyHVMIV0cinyi4omywadeN WaFlBii2OT+vAqJKUzU4zltZh1aZOCDNkMsbQsoKWnbf7jB4ac5XaHus8ikga6Xt5Ex4yfVc7GXU RL6bnmIZCfyyw1vORn+QKUGZ2p1MAykjMn+SZj+aXhrrybzHos0RbkbZ+2t6OgwZeo3Pv9H92Mbp Z5K218nIRrFpkSh7NB0T33KoxkkT6/eO0gdmkVU7J5QQAEx75yfxnLJbh7z/ata3uQAAAAAAAA== --Apple-Mail-FD861029-2480-4E96-AF7D-2629F29CB14F-- From nobody Wed May 21 18:26:02 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FD61A0013 for ; Wed, 21 May 2014 18:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 BcfAUrOispe4 for ; Wed, 21 May 2014 18:25:58 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AAA41A0012 for ; Wed, 21 May 2014 18:25:57 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id 63so4548142qgz.2 for ; Wed, 21 May 2014 18:25:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=IMvim7NRYcovvHKSvfGls5FRx5rxshKtUkfYmNnfeqA=; b=RPgYBT0VXLBLRFPLmNIZlDAOFZpjoUhsCBfi5Gz4JBCKdFPqKxjFSpNd/utK6t1rBP jqM6XAE3TIInYZH1vXntZp0ENv83SDckgE+BXyZr0+MvOo5X9uazgc4env57qPy/7ggn KscWiOjJ7iE2Hqk5drdsu+WsVltcyXBiVgcYimD8ejrBUKYiDfpH0/QAT+mgQFedhn4y 7roLX2d3UCG2QyPI1iOKcN1NU2XJml+tIIicaWNmvCIY6gj5r9MrBSPZG4OeO0iVAcia EOidjWRqvdOMvv79yMXwUgaS9wQUweTVf8UKZ8p0n8WRuvX8u4scwfGMRKeHhVP9cDvJ rrQA== X-Gm-Message-State: ALoCoQmuGDxiBeKIR7X4TCUK9rUuXJKAjnz2sl6ByNG0wI4pSDtI8x7+t6PR0z70ZxNo/VW3oERG X-Received: by 10.224.169.6 with SMTP id w6mr9267377qay.102.1400721956370; Wed, 21 May 2014 18:25:56 -0700 (PDT) Received: from ?IPv6:2600:1000:b10f:3fd8:c090:df9f:3f95:90a3? ([2600:1000:b10f:3fd8:c090:df9f:3f95:90a3]) by mx.google.com with ESMTPSA id h90sm1778941qge.0.2014.05.21.18.25.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 18:25:55 -0700 (PDT) References: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> <1400275641.37471.YahooMailNeo@web142803.mail.bf1.yahoo.com> <537B5F2B.9090501@redhat.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-42BD3618-822E-41D5-9309-E9F2FC8926EB; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <483196B6-2989-4CEA-946D-6B9C269A257D@ve7jtb.com> X-Mailer: iPhone Mail (11D201) From: John Bradley Date: Wed, 21 May 2014 21:25:52 -0400 To: Nat Sakimura Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9HVn1m-ETU2ln-FVLs4CSQcyvvY Cc: oauth Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 01:26:01 -0000 --Apple-Mail-42BD3618-822E-41D5-9309-E9F2FC8926EB Content-Type: multipart/alternative; boundary=Apple-Mail-BB339337-8FB6-4C66-A9E9-EA0DB4747B63 Content-Transfer-Encoding: 7bit --Apple-Mail-BB339337-8FB6-4C66-A9E9-EA0DB4747B63 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think the current one is probably a OK compromise.=20 Sent from my iPhone > On May 21, 2014, at 9:11 PM, Nat Sakimura wrote: >=20 > Good! I achieve the purpose :-) >=20 > So what would be the appropriate length?=20 > The current one would do?=20 >=20 >=20 > 2014-05-20 22:56 GMT+09:00 Anil Saldhana : >> Brian - I agree with you. It should be MUST as long as the hard limit is= generous for usage. >>=20 >>=20 >>=20 >>=20 >>> On 05/20/2014 07:09 AM, Brian Campbell wrote: >>> I'd say it should be a MUST so that implementations are consistent about= it. >>>=20 >>>=20 >>>> On Fri, May 16, 2014 at 3:27 PM, Bill Mills wr= ote: >>>> The HTTP specs don't limit these things, but implementations do, and th= e problems when you run into them are a rea pain. >>>>=20 >>>> DO we want to make this a hard limit, or should it be guidance in the f= orm of RECOMMENDED or SHOULD? >>>>=20 >>>> On Friday, May 16, 2014 9:35 AM, Brian Campbell wrote: >>>> Yeah, I agree with John here. There are a few good reasons to restrict t= he length of the code_challenge. One is trying to keep the authorization req= uest URI to reasonable size as it will eve= ntually run into various limits on clients and/or servers. The other is cons= training the amount of data that an AS needs to store per code. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Fri, May 16, 2014 at 7:41 AM, John Bradley wrote= : >>>> =46rom the AS side you probably want to know what the max size you need= to store per code. >>>>=20 >>>> On the call to the token endpoint it is a POST so size should not be an= issue. =20 >>>>=20 >>>>=20 >>>>> On May 16, 2014, at 3:10 PM, Nat Sakimura wrote: >>>>>=20 >>>>> Now that I cannot remember what limit we were hitting, it might be a g= ood idea to remove the constraint and see if anyone protests.=20 >>>>>=20 >>>>> What do you think?=20 >>>>>=20 >>>>> Nat >>>>>=20 >>>>>=20 >>>>> 2014-05-14 20:46 GMT+09:00 Brian Campbell = : >>>>> That too would suggest that the length limit be on code_challenge beca= use that's the parameter that will be on URIs getting passed around. The cod= e_verifier is sent directly in the POST body from client to AS.=20 >>>>>=20 >>>>>=20 >>>>> On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura wr= ote: >>>>> +1 for octet. We used to have "bytes" in JW* so I used "bytes" here, w= hile at the same time complaining in Jose that it should be "octet". JW* cha= nged to "octet" but I failed to sync with it in the last few edits.=20 >>>>>=20 >>>>> I do not quite remember which platform, but the reason for the limit w= as that some platform had some limitations as to the length of the sting to b= e passed to it through URI and we did not want the challenges to be truncate= d by that limit.=20 >>>>>=20 >>>>> Best,=20 >>>>>=20 >>>>> Nat >>>>>=20 >>>>>=20 >>>>> 2014-05-13 6:56 GMT+09:00 Brian Campbell := >>>>>=20 >>>>> And it'd give the AS some direct guidance on = protecting itself from crazy long code_chal= lenge values rather than relying on the client not to do something creative.= =20 >>>>>=20 >>>>>=20 >>>>> On Mon, May 12, 2014 at 3:54 PM, Brian Campbell wrote: >>>>> Right but that's why I'm asking why not just put the limit on code_cha= llange rather than inferring it from code_verifyer + challenge algorithm, wh= ich probably bounds it but doesn't necessarily do so? It's not a big deal bu= t would read more clearly, I think. >>>>>=20 >>>>>=20 >>>>> On Mon, May 12, 2014 at 3:48 PM, John Bradley wrot= e: >>>>> I think octets is more consistent with other JW* and OAuth specs. >>>>>=20 >>>>> The code_challange is the same length as the code_verifyer or is a has= h of the code_verifyer so likely smaller than 128octets (43 ish for base64 2= 56 bit) >>>>>=20 >>>>> Limiting the code_verifyer size sets the upper bound for code_challang= e, unless someone comes up with a really creative code challenge algorithm. >>>>>=20 >>>>> I will talk to nat about changing it to octets when I see him tomorrow= . >>>>>=20 >>>>> John B. >>>>>=20 >>>>> On May 12, 2014, at 11:15 PM, Derek Atkins wrote: >>>>>=20 >>>>> > Brian Campbell writes: >>>>> > >>>>> >> I notice that code_verifier is defined as "high entropy cryptograph= ic random >>>>> >> string of length less than 128 bytes" [1], which brought a few que= stions and >>>>> >> comments to mind. So here goes: >>>>> >> >>>>> >> Talking about the length of a string in terms of bytes is always po= tentially >>>>> >> confusing. Maybe characters would be an easier unit for people like= me to wrap >>>>> >> their little brains around? >>>>> > >>>>> > It depends if it really is characters or bytes. For example there a= re >>>>> > many multi-byte UTF-8 characters, so if it really is bytes then sayi= ng >>>>> > characters is wrong because it could overflow. So let's make sure w= e >>>>> > know what we're talking about. Historically, if we're talking bytes= the >>>>> > IETF often uses the phrase "octets". Would that be less confusing? >>>>> > >>>>> >> Why are we putting a length restriction on the code_verifier anyway= ? It seems >>>>> >> like it'd be more appropriate to restrict the length of the code_ch= allenge >>>>> >> because that's the thing the AS will have to maintain somehow (stor= e in a DB >>>>> >> or memory or encrypt into the code). Am I missing something here? >>>>> >> >>>>> >> Let me also say that I hadn't looked at this document since its ear= ly days in >>>>> >> draft -00 or -01 last summer but I like the changes and how it's be= en kept >>>>> >> pretty simple for the common use-case while still allowing for cryp= to agility/ >>>>> >> extension. Nice work! >>>>> >> >>>>> >> [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section= -3.3 >>>>> > >>>>> > -derek >>>>> > >>>>> >> _______________________________________________ >>>>> >> OAuth mailing list >>>>> >> OAuth@ietf.org >>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>> > >>>>> > -- >>>>> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >>>>> > Member, MIT Student Information Processing Board (SIPB) >>>>> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >>>>> > warlord@MIT.EDU PGP key available >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> =09 >>>>> Brian Campbell >>>>> Portfolio Architect >>>>> @ bcampbell@pingidentity.com >>>>> +1 720.317.2061 >>>>> Connect with us=E2=80=A6 >>>>> =20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> =09 >>>>> Brian Campbell >>>>> Portfolio Architect >>>>> @ bcampbell@pingidentity.com >>>>> +1 720.317.2061 >>>>> Connect with us=E2=80=A6 >>>>> =20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> =09 >>>>> Brian Campbell >>>>> Portfolio Architect >>>>> @ bcampbell@pingidentity.com >>>>> +1 720.317.2061 >>>>> Connect with us=E2=80=A6 >>>>> =20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-BB339337-8FB6-4C66-A9E9-EA0DB4747B63 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think the current one is probably a O= K compromise. 

Sent from my iPhone

On May 2= 1, 2014, at 9:11 PM, Nat Sakimura <= sakimura@gmail.com> wrote:

Good! I achieve the purpose :-)

So wha= t would be the appropriate length? 
The current one would do?=  


2014-05-20 22:56 GMT+09:00 Anil Saldhana <Anil.Saldhana@redhat.com= >:
=20 =20 =20
Brian - I agree with you.  It should be MUST as long as the hard limit is generous for usage.




On 05/20/2014 07:09 AM, Brian Campbell wrote:
I'd say it should be a MUST so that implementations are consistent about it.


On Fri, May 16, 2014 at 3:27 PM, Bill Mills <wmills_92105@yahoo.com> wrote:
The HTTP specs don't limit these things, but implementations do, and the problems when you run into them are a rea pain.

DO we want to make this a hard limit, or should it be guidance in the form of RECOMMENDED or SHOULD?

On Friday, May 16, 2014 9:35 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Yeah, I agree with John here. There are a few good reasons to restrict the length of the code_challenge. One is trying to keep the authorization request URI to reasonable size as it will eventually run into various limits on clients and/or servers. The other is constraining the amount of data that an AS needs to store per code.




On Fri, May 16, 2014 at 7:41 AM, John Bradley <= ;ve7jtb@ve7jtb.com> wrote:
= From the AS side you probably want to know what the max size you need to store per code.

On the call to the token endpoint it is a POST so size should not be an issue.  


On May 16, 2014, at 3:10 PM, Nat Sakimura <sakimura@gmail.com> wrote:

=
Now that I cannot remember what limit we were hitting, it might be a good idea to remove the constraint and see if anyone protests. 

What do you think? 

Nat

=
2014-05-14 20:46 GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:
T= hat too would suggest that the length limit be on code_challenge because that's the parameter that will be on URIs getting passed around. The code_verifier is sent directly in the POST body from client to AS.


On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura <sakimura@gmail.com> wrote:
+= 1 for octet. We used to have "bytes" in JW* so I used "bytes" here, while at the same time complaining in Jose that it should be "octet". JW* changed to "octet" but I failed to sync with it in the last few edits. 

I do not quite remember which platform, but the reason for the limit was that some platform had some limitations as to the length of the sting to be passed to it through URI and we did not want the challenges to be truncated by that limit. 
=

Best, 

Nat


2014-05-13 6:56 GMT+09:00 Brian Campbell = <bcampbell@pingidentity.com>:

A= nd it'd give the AS some direct guidance on protecting itself from crazy long code_challenge values rather than relying on the client not to do something creative.


On Mon, May 12, 2014 at 3:54 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:
R= ight but that's why I'm asking why not just put the limit on code_challange rather than inferring it from code_verifyer + challenge algorithm, which probably bounds it but doesn't necessarily do so? It's not a big deal but would read more clearly, I think.


On Mon, May 12, 2014 at 3:48 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I think octets is more consistent with other JW* and OAuth specs.

The code_challange is the same length as the code_verifyer or is a hash of the code_verifyer so likely smaller than 128octets (43 ish for base64 256 bit)

Limiting the code_verifyer size sets the upper bound for code_challange, unless someone comes up with a really creative code challenge algorithm.

I will talk to nat about changing it to octets when I see him tomorrow.

John B.

On May 12, 2014, at 11:15 PM, Derek Atkins <= warlord@MIT.EDU> wrote:

> Brian Campbell <bcampbell@pingidentity.com> writes:
= >
>> I notice that code_verifier is defined as "high entropy cryptographic random
>> string of length less than 128 bytes"  [1], which brought a few questions and
>> comments to mind. So here goes:
>>
>> Talking about the length of a string in terms of bytes is always potentially
>> confusing. Maybe characters would be an easier unit for people like me to wrap
>> their little brains around?
>
> It depends if it really is characters or bytes.  For example there are
> many multi-byte UTF-8 characters, so if it really is bytes then saying
> characters is wrong because it could overflow.  So= let's make sure we
> know what we're talking about.  Historically= , if we're talking bytes the
> IETF often uses the phrase "octets".  Would that b= e less confusing?
>
>> Why are we putting a length restriction on the code_verifier anyway? It seems
>> like it'd be more appropriate to restrict the length of the code_challenge
>> because that's the thing the AS will have to maintain somehow (store in a DB
>> or memory or encrypt into the code). Am I missing something here?
>>
>> Let me also say that I hadn't looked at this document since its early days in
>> draft -00 or -01 last summer but I like the changes and how it's been kept
>> pretty simple for the common use-case while still allowing for crypto agility/
>> extension. Nice work!
>>
>> [1] http://tools.ietf.org/html/= draft-sakimura-oauth-tcse-03#section-3.3
>
> -derek
>
>> __________________= _____________________________
>> OAuth mailing list
>> O= Auth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>    =   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>    =   Member, MIT Student Information Processing Board  (SIPB)=
>    =   URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH=
>    =   warlord@MIT.EDU           &nbs= p;            PGP key available



=
--
3D"Ping
Brian Campbell Portfolio Architect
@ bcampbell@pingidentity.com
3D"phone"= +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Fac= 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register



=
--
3D"Ping
Brian Campbell Portfolio Architect
@ bcampbell@pingidentity.com
3D"phone"= +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Fac= 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register


_______________________________________________
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


=
--
3D"Ping
Brian Campbell Portfolio Architect
@ bcampbell@pingidentity.com
3D"phone"= +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Fac= 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register




--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat= .sakimura.org/
@_nat_en



___________________________________________= ____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/list= info/oauth





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


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




--
Nat Sakim= ura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-BB339337-8FB6-4C66-A9E9-EA0DB4747B63-- --Apple-Mail-42BD3618-822E-41D5-9309-E9F2FC8926EB Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwNTIyMDEyNTUzWjAjBgkqhkiG9w0BCQQxFgQUVYvfMUs3PQVhIQMk pisEabqPQ0EwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAZA8lsnAeVOo+6G0uZVaRYq/24KwtPBtYENLlvth56eYIhqEW H5aWksI+ylgdefOa0Jmj8GEkd/S+fQKlH4cEhMRcusmLic+JoKrH1ua67E9J/LPAuIKJUmZdmkcs C1YbboQ7Z7CYOdimuGcoh8idj61M0ZD5NW1AzSONCCwvUHcEBf3k+yCzOpalF6j+vZuLwBAfuJ5r hu6TR9NaxihxePghZJ3sQcgXUFOIzCGBoN0vf3dUJVS4GgJelJCqSCKlMwQYF5jy31dfzJBxuMjK 0lI6CWvB7DkHHq/hTH243eIAmQle/KbNcpjpevIQ0NRg+zCU72s3irGEkE6wNjND4AAAAAAAAA== --Apple-Mail-42BD3618-822E-41D5-9309-E9F2FC8926EB-- From nobody Wed May 21 18:38:46 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DAB1A0029 for ; Wed, 21 May 2014 18:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 xuuZMrDLeQGs for ; Wed, 21 May 2014 18:38:39 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE951A002D for ; Wed, 21 May 2014 18:38:38 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id p9so2104444lbv.21 for ; Wed, 21 May 2014 18:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TLKzXLx2lIHU8a8q4W6Pg1gaRHPr4Vd9GP2ech2YNLY=; b=Eh9pFgBn4LTvcAbtYM/jQRrYexDns+dSCmMx4M6/hkPefyJtnCZRokfY63a9e5FH3d UBbZ7y0Lz5Mzf99x7r5yLqTXBwSWjuZekoxumTlU4x3V3nxVrbqsduNFzB20hF2DG5sw ub3Qo4CFfPWULDZYrNcs0/JDs04WXSANDFati709YItFCxNzYto1afJtVEtW9tx5C2bH NlZl3aDk32341oHURbJ2gghZmQ5ta0pnl6/5NZgynYofj9empmOfS+d3fdiMyIyGnBEJ dWsm7oteMp1lXhC1nPws7sA/WK7CVNY6DMcgjui9pbOqm28H7PavC7J7ll5PEvctaDRt I1VA== MIME-Version: 1.0 X-Received: by 10.112.41.227 with SMTP id i3mr38049546lbl.41.1400722716193; Wed, 21 May 2014 18:38:36 -0700 (PDT) Received: by 10.112.105.134 with HTTP; Wed, 21 May 2014 18:38:36 -0700 (PDT) In-Reply-To: <483196B6-2989-4CEA-946D-6B9C269A257D@ve7jtb.com> References: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> <1400275641.37471.YahooMailNeo@web142803.mail.bf1.yahoo.com> <537B5F2B.9090501@redhat.com> <483196B6-2989-4CEA-946D-6B9C269A257D@ve7jtb.com> Date: Thu, 22 May 2014 10:38:36 +0900 Message-ID: From: Nat Sakimura To: John Bradley Content-Type: multipart/alternative; boundary=001a113468f0ed7c2004f9f32b3f Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/b7FLw8MeeERbyvhLx8VP7sQqa64 Cc: oauth Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 01:38:43 -0000 --001a113468f0ed7c2004f9f32b3f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Some more questions. Q1. Length limitation on 1. code_challenge only 2. code_verifier only 3. both Q2. Length in 1. Octents 2. Number of characters My preference for Q2 is 1. as number of characters would not dictate the actual length. A character is variable in length. 2014-05-22 10:25 GMT+09:00 John Bradley : > I think the current one is probably a OK compromise. > > Sent from my iPhone > > On May 21, 2014, at 9:11 PM, Nat Sakimura wrote: > > Good! I achieve the purpose :-) > > So what would be the appropriate length? > The current one would do? > > > 2014-05-20 22:56 GMT+09:00 Anil Saldhana : > >> Brian - I agree with you. It should be MUST as long as the hard limit >> is generous for usage. >> >> >> >> >> On 05/20/2014 07:09 AM, Brian Campbell wrote: >> >> I'd say it should be a MUST so that implementations are consistent about >> it. >> >> >> On Fri, May 16, 2014 at 3:27 PM, Bill Mills wrot= e: >> >>> The HTTP specs don't limit these things, but implementations do, and >>> the problems when you run into them are a rea pain. >>> >>> DO we want to make this a hard limit, or should it be guidance in the >>> form of RECOMMENDED or SHOULD? >>> >>> On Friday, May 16, 2014 9:35 AM, Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> Yeah, I agree with John here. There are a few good reasons to >>> restrict the length of the code_challenge. One is trying to keep the >>> authorization request URI to reasonable size as it will eventually run = into >>> various limits on clients and/or servers. The other is constraining the >>> amount of data that an AS needs to store per code. >>> >>> >>> >>> >>> On Fri, May 16, 2014 at 7:41 AM, John Bradley wrote= : >>> >>> From the AS side you probably want to know what the max size you need t= o >>> store per code. >>> >>> On the call to the token endpoint it is a POST so size should not be >>> an issue. >>> >>> >>> On May 16, 2014, at 3:10 PM, Nat Sakimura wrote: >>> >>> Now that I cannot remember what limit we were hitting, it might be a >>> good idea to remove the constraint and see if anyone protests. >>> >>> What do you think? >>> >>> Nat >>> >>> >>> 2014-05-14 20:46 GMT+09:00 Brian Campbell : >>> >>> That too would suggest that the length limit be on code_challenge >>> because that's the parameter that will be on URIs getting passed around= . >>> The code_verifier is sent directly in the POST body from client to AS. >>> >>> >>> On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura wrot= e: >>> >>> +1 for octet. We used to have "bytes" in JW* so I used "bytes" here, >>> while at the same time complaining in Jose that it should be "octet". J= W* >>> changed to "octet" but I failed to sync with it in the last few edits. >>> >>> I do not quite remember which platform, but the reason for the limit >>> was that some platform had some limitations as to the length of the sti= ng >>> to be passed to it through URI and we did not want the challenges to be >>> truncated by that limit. >>> >>> Best, >>> >>> Nat >>> >>> >>> 2014-05-13 6:56 GMT+09:00 Brian Campbell : >>> >>> And it'd give the AS some direct guidance on protecting itself from >>> crazy long code_challenge values rather than relying on the client not = to >>> do something creative. >>> >>> >>> On Mon, May 12, 2014 at 3:54 PM, Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>> Right but that's why I'm asking why not just put the limit on >>> code_challange rather than inferring it from code_verifyer + challenge >>> algorithm, which probably bounds it but doesn't necessarily do so? It's= not >>> a big deal but would read more clearly, I think. >>> >>> >>> On Mon, May 12, 2014 at 3:48 PM, John Bradley wrote= : >>> >>> I think octets is more consistent with other JW* and OAuth specs. >>> >>> The code_challange is the same length as the code_verifyer or is a hash >>> of the code_verifyer so likely smaller than 128octets (43 ish for base6= 4 >>> 256 bit) >>> >>> Limiting the code_verifyer size sets the upper bound for code_challange= , >>> unless someone comes up with a really creative code challenge algorithm= . >>> >>> I will talk to nat about changing it to octets when I see him tomorrow. >>> >>> John B. >>> >>> On May 12, 2014, at 11:15 PM, Derek Atkins wrote: >>> >>> > Brian Campbell writes: >>> > >>> >> I notice that code_verifier is defined as "high entropy cryptographi= c >>> random >>> >> string of length less than 128 bytes" [1], which brought a few >>> questions and >>> >> comments to mind. So here goes: >>> >> >>> >> Talking about the length of a string in terms of bytes is always >>> potentially >>> >> confusing. Maybe characters would be an easier unit for people like >>> me to wrap >>> >> their little brains around? >>> > >>> > It depends if it really is characters or bytes. For example there ar= e >>> > many multi-byte UTF-8 characters, so if it really is bytes then sayin= g >>> > characters is wrong because it could overflow. So let's make sure we >>> > know what we're talking about. Historically, if we're talking bytes >>> the >>> > IETF often uses the phrase "octets". Would that be less confusing? >>> > >>> >> Why are we putting a length restriction on the code_verifier anyway? >>> It seems >>> >> like it'd be more appropriate to restrict the length of the >>> code_challenge >>> >> because that's the thing the AS will have to maintain somehow (store >>> in a DB >>> >> or memory or encrypt into the code). Am I missing something here? >>> >> >>> >> Let me also say that I hadn't looked at this document since its earl= y >>> days in >>> >> draft -00 or -01 last summer but I like the changes and how it's bee= n >>> kept >>> >> pretty simple for the common use-case while still allowing for crypt= o >>> agility/ >>> >> extension. Nice work! >>> >> >>> >> [1] >>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 >>> > >>> > -derek >>> > >>> >> _______________________________________________ >>> >> OAuth mailing list >>> >> OAuth@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > -- >>> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >>> > Member, MIT Student Information Processing Board (SIPB) >>> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >>> > warlord@MIT.EDU PGP key available >>> >>> >>> >>> >>> -- >>> [image: Ping Identity logo] >>> Brian Campbell >>> Portfolio Architect >>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect >>> with us=E2=80=A6 [image: twitter logo] [image: >>> youtube logo] [image: >>> LinkedIn logo] [image: >>> Facebook logo] [image: >>> Google+ logo] [imag= e: >>> slideshare logo] [image: >>> flipboard logo] [image: rss feed icon] >>> [image: Register for Cloud Identity Summit 2014 | Modern Identity >>> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >>> >>> >>> >>> >>> -- >>> [image: Ping Identity logo] >>> Brian Campbell >>> Portfolio Architect >>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect >>> with us=E2=80=A6 [image: twitter logo] [image: >>> youtube logo] [image: >>> LinkedIn logo] [image: >>> Facebook logo] [image: >>> Google+ logo] [imag= e: >>> slideshare logo] [image: >>> flipboard logo] [image: rss feed icon] >>> [image: Register for Cloud Identity Summit 2014 | Modern Identity >>> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> >>> -- >>> [image: Ping Identity logo] >>> Brian Campbell >>> Portfolio Architect >>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect >>> with us=E2=80=A6 [image: twitter logo] [image: >>> youtube logo] [image: >>> LinkedIn logo] [image: >>> Facebook logo] [image: >>> Google+ logo] [imag= e: >>> slideshare logo] [image: >>> flipboard logo] [image: rss feed icon] >>> [image: Register for Cloud Identity Summit 2014 | Modern Identity >>> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >>> >>> >>> >>> >>> -- >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > 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 --001a113468f0ed7c2004f9f32b3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some more questions.=C2=A0

Q1. Length l= imitation on=C2=A0
  1. code_challenge only
  2. code_v= erifier only
  3. both
Q2. Length in
  1. Octents
  2. Number of characters
My preference for Q2 is = 1. as number of characters would not dictate the actual length. A character= is variable in length.=C2=A0
<= br>
2014-05-22 10:25 GMT+09:00 John Bradley <ve= 7jtb@ve7jtb.com>:
I think the current one is probably a OK compromise.= =C2=A0

Sent from my iPhone
<= br>On May 21, 2014, at 9:11 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Good! I achieve t= he purpose :-)

So what would be the appropriate length?= =C2=A0
The current one would do?=C2=A0


2014-05-20 22:56 GMT+09:00 Anil Saldhana <Anil.Saldhana@redhat.com>:
=20 =20 =20
Brian - I agree with you.=C2=A0 It should be MUST as long as the hard limit is generous for usage.




On 05/20/2014 07:09 AM, Brian Campbell wrote:
I'd say it should be a MUST so that implementati= ons are consistent about it.


On Fri, May 16, 2014 at 3:27 PM, Bill Mills <wmills_92105@yahoo.com> wrote:
The HTTP specs don't limit these things, but implementations do, and the problems when you run into them are a rea pain.

DO we want to make this a hard limit, or should it be guidance in the form of RECOMMENDED or SHOULD?

On Friday, May 16, 2014 9:35 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Yeah, I agree with John here. There are a few good reasons to restrict the length of the code_challenge. One is trying to keep the authorization request URI to reasonable size as it will eventually run into various limits on clients and/or servers. The other is constraining the amount of data that an AS needs to store per code.




On Fri, May 16, 2014 at 7:41 AM, John Bradley &l= t;ve7jtb@ve7jtb.com> wrote:
From the AS side you probably want to know what the max size you need to store per code.

On the call to the token endpoint it is a POST so size should not be an issue. =C2=A0


On May 16, 2014, at 3:10 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Now that I cannot remember what limit we were hitting, it might be a good idea to remove the constraint and see if anyone protests.=C2=A0

What do you think?=C2=A0

Nat


2014-05-14 20:46 GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:
= That too would suggest that the length limit be on code_challenge because that'= s the parameter that will be on URIs getting passed around. The code_verifier is sent directly in the POST body from client to AS.


On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura <sakimura@gmail.com> wrote:
= +1 for octet. We used to have "bytes"= in JW* so I used "bytes"= here, while at the same time complaining in Jose that it should be "octet"= . JW* changed to "octet"= but I failed to sync with it in the last few edits.=C2=A0

I do not quite remember which platform, but the reason for the limit was that some platform had some limitations as to the length of the sting to be passed to it through URI and we did not want the challenges to be truncated by that limit.=C2=A0

Best,=C2=A0<= /div>

Nat


2014-05-13 6:56 GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:

= And it'd give the AS some direct guidance on protecting itself from crazy long code_challenge values rather than relying on the client not to do something creative.


On Mon, May 12, 2014 at 3:54 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:<= br clear=3D"none">
= Right but that's wh= y I'm asking wh= y not just put the limit on code_challange rather than inferring it from code_verifyer + challenge algorithm, which probably bounds it but doesn't necessarily do so? It's not = a big deal but would read more clearly, I think.


On Mon, May 12, 2014 at 3:48 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I think octets is more consistent with other JW* and OAuth specs.

The code_challange is the same length as the code_verifyer or is a hash of the code_verifyer so likely smaller than 128octets (43 ish for base64 256 bit)

Limiting the code_verifyer size sets the upper bound for code_challange, unless someone comes up with a really creative code challenge algorithm.

I will talk to nat about changing it to octets when I see him tomorrow.

John B.

On May 12, 2014, at 11:15 PM, Derek Atkins <warlord@MIT.EDU> wrote:

> Brian Campbell <bcampbell@pingidentity.com> writes:
>
>> I notice that code_verifier is defined as "high entrop= y cryptographic random
>> string of length less than 128 bytes" =C2= =A0[1], which brought a few questions and
>> comments to mind. So here goes:
>>
>> Talking about the length of a string in terms of bytes is always potentially
>> confusing. Maybe characters would be an easier unit for people like me to wrap
>> their little brains around?
>
> It depends if it really is characters or bytes. =C2=A0For example there are
> many multi-byte UTF-8 characters, so if it really is bytes then saying
> characters is wrong because it could overflow. =C2=A0S= o let's make sure we
> know what we're talking about. =C2=A0Historicall= y, if we're talking bytes the
> IETF often uses the phrase "octets"= ;. =C2=A0Would that = be less confusing?
>
>> Why are we putting a length restriction on the code_verifier anyway? It seems
>> like it'd be more appropriate to restrict the length of the code_challenge >> because that'= s the thing the AS will have to maintain somehow (store in a DB
>> or memory or encrypt into the code). Am I missing something here?
>>
>> Let me also say that I hadn't looked at this document since its early days in
>> draft -00 or -01 last summer but I like the changes and how it's been kept
>> pretty simple for the common use-case while still allowing for crypto agility/
>> extension. Nice work!
>>
>> [1] http://tools.ietf.org/ht= ml/draft-sakimura-oauth-tcse-03#section-3.3
>
> -derek
>
>> _________________= ______________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth >
> --
> =C2=A0 =C2= =A0 =C2=A0 Derek Atkins, SB '93 MIT EE= , SM '95 MIT Media Laboratory
> =C2=A0 =C2= =A0 =C2=A0 Member, MIT Student Information Processing Board =C2=A0(SIPB= )
> =C2=A0 =C2= =A0 =C2=A0 URL: http://web.mit.edu/warlord/ =C2=A0 =C2=A0PP-ASEL-IA =C2=A0 =C2=A0 N1= NWH
> =C2=A0 =C2= =A0 =C2=A0 warlord@MIT.EDU =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PGP key available




--
3D"Ping
Brian Campbell Portfolio Architect
@ bcampbell@pingidentity.com
3D"phone= +1 720.317.2061<= /span>
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedI= 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipbo=
3D"Register




--
3D"Ping
Brian Campbell Portfolio Architect
@ bcampbell@pingidentity.com
3D"phone= +1 720.317.2061<= /span>
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedI= 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipbo=
3D"Register


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

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http:= //nat.sakimura.org/
@_nat_en



--
3D"Ping
Brian Campbell Portfolio Architect
@ bcampbell@pingidentity.com
3D"phone= +1 720.317.2061<= /span>
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedI= 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipbo=
3D"Register




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://= nat.sakimura.org/
@_nat_en



__________________________________________= _____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/li= stinfo/oauth





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


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___________________= ____________________________
OAuth mailing list
<= span>OAuth@ietf.org=
https://www.ietf.org/mailman/listinfo/oauth



=
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/@_nat_en
--001a113468f0ed7c2004f9f32b3f-- From nobody Wed May 21 19:07:42 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70D31A0045 for ; Wed, 21 May 2014 19:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 A4gdITzY3qku for ; Wed, 21 May 2014 19:07:37 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5C61A0043 for ; Wed, 21 May 2014 19:07:36 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4M27XNA017614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 May 2014 02:07:34 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4M27WxZ021597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 May 2014 02:07:33 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4M27V0E005643; Thu, 22 May 2014 02:07:31 GMT Received: from [25.64.214.196] (/24.114.22.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 May 2014 19:07:31 -0700 References: <75D99637-1802-4C1F-83BE-D62AD938F9F4@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-3CF1E5B6-898E-40E0-A7E9-340948D8B404 Content-Transfer-Encoding: 7bit Message-Id: <43FB363A-358F-4924-ADEE-D16D282645B4@oracle.com> X-Mailer: iPhone Mail (11D167) From: Phil Hunt Date: Wed, 21 May 2014 19:07:19 -0700 To: John Bradley X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Vf26N6JS2YQvZY4TKZZUdaQUDjk Cc: OAuth WG Subject: Re: [OAUTH-WG] Authen Milestone: Comparing current A4C proposal to OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 02:07:41 -0000 --Apple-Mail-3CF1E5B6-898E-40E0-A7E9-340948D8B404 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am offended. I may be wrong but I am NOT mis-informing. Please prove your c= ase.=20 Lets have a proper discussion.=20 Phil > On May 21, 2014, at 18:20, John Bradley wrote: >=20 > Thanks Nat. I can't add anything to your response.=20 >=20 > Let's base our decision on adding authentication to OAuth 2 on reality.=20= >=20 > Having a profile of Connect with most of the features Phil is looking for s= hould not be a hard thing. I don't personally think it is required to have= that happen in the OAuth WG.=20 >=20 >=20 > John B >=20 > Sent from my iPhone >=20 >> On May 21, 2014, at 9:03 PM, Nat Sakimura wrote: >>=20 >> Phil, please do not misinform the working group.=20 >>=20 >> My responses inline:=20 >>=20 >>=20 >> 2014-05-22 3:56 GMT+09:00 Phil Hunt : >>> Since several have voiced the opinion that the WG should not work on pro= viding user authentication context because OpenID Connect already has a solu= tion, I wanted to make clear how A4C is different from OpenID Connect. >>>=20 >>> OpenID Connect supports providing clients an =E2=80=9Cid_token=E2=80=9D u= sing the id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybri= d Auth) of the OAuth Core. >>> http://openid.net/specs/openid-connect-core-1_0.html >>>=20 >>> The A4C draft that was put forward by Mike, Tony, and myself ( draft-hun= t-oauth-v2-user-a4c ) describes a flow similar to the code flow of normal OA= uth. Here are the differences from Connect: >>>=20 >>> Client Authentication >>> Connect does NOT authenticate the client prior to returning the id token= . The Connect flow is single step returning ID_TOKEN to an unauthenticated c= lient in both 3.2 and 3.3. Use of code flow in 3.3 appears only for the purp= ose of issuing an access token (user info token). >>> The A4C flow is 2-step following the OAuth2 code flow. It requires a cod= e to be exchanged for ID_TOKEN after client authenticates in the second step= (exactly duplicating the normal OAuth flow). A4C requires mutual authentic= ation of clients and AS service providers. A4C has the same logic and securi= ty properties of the normal OAuth authorization flow. >> This is not true.=20 >>=20 >> Connect for Code Flow for confidential client DOES authenticate the clien= t before getting an ID Token.=20 >>=20 >> Further, the Connect has an option of asymmetrically encrypting ID Token w= ith the public key of the client, which authenticates the client even furthe= r.=20 >> Even further, the Connect has an option of asymmetrically encrypting the r= equest with the public key of the server, which authenticates the server in a= ddition to TLS. =20 >>> User Authentication=20 >>> Both OpenID Connect and A4C return ID tokens which contain pretty much t= he same information >>> A4C has additional features to allow clients to negotiate level of authe= ntication and authentication types (min LOA,ACR,AMR) in addition to just ret= urning ACR as in the case of OpenID. >> What's the point of having both minimum LoA and AMR instead of ACR? Conn= ect can also return AMR.=20 >> If you really wanted to have amr_values like feature, you can actually re= quest it by using Claims request as >>=20 >> { "id_token": {"amr": {"values": ["otp","rsa"] }}} >> =20 >>> A4C only make re-auth lighter weight. No need to issue UserInfo tokens a= gain. Re-auth also re-authenticates the client as well as user. >> I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C is di= verting from RFC6749. A4C is NOT OAuth anymore. The very reason OpenID Conne= ct returns an access token from the token endpoint always is to adhere to RFC= 6749.=20 >>=20 >> OpenID Connect with scope=3Dopenid only is essentially the authN only ope= ration.=20 >>=20 >>> Privacy Option >>> The A4C=E2=80=99s authentication of the client makes it possible to issu= e client-specific subject identifiers. This prevents multiple clients from c= olluding to share information. >> This is supported by OpenID Connect as well. =20 >>> Because Connect doesn=E2=80=99t know who the client is, the subject iden= tifier returned is universal. >> As stated above, this is false. It can even return PPID in the case of pu= blic client as well.=20 >>> The spec could be used for pseudonymous authentication. >> As state above, OpenID Connect supports this. It in fact advise the use o= f PPID (Pairwise Psuedonymous Identifier in section 17.3).=20 >> =20 >>>=20 >>> As you can see the specs are doing similar things, but they have differe= nt security features. >>=20 >> As stated above, I do not see much. It has less option in general, and ad= ded feature is the amr_values and min_alv, which I do not see much value in i= t but if you really wanted, you can extend the Connect.=20 >> =20 >>>=20 >>> As for need: >>> There are many sites using social network providers to authenticate usin= g 6749 only, there are ongoing security concerns that many of us have blogge= d about. This may rise to the level of BUG on 6749. >> Why not just use OpenID Connect? =20 >>> Some social network providers have indicated a willingness to support an= authenticate only feature. I also had an inquiry if A4C can be supported in= OAuth1 as well as OAuth2. Some of this may be coming from a business decisi= on to use a proprietary user profile API instead (this is not Oracle=E2=80=99= s position). >> Authen only is fine with OpenID Connect. You can also use proprietary or w= hatever the user profile API "in addition". For the purpose of interoperabil= ity, it is better to have a standard user profile API though, and that's why= Connect defines a very basic one for this purpose. =20 >>> There is a consent problem because normal 6749 use requires users to con= sent to sharing information. Client developers in many cases would like an a= uthen only profile where consent is implicit. >> That's an implementation issue. RFC 6749 does not require the users to pr= ovide explicit consent.=20 >> It just states:=20 >>=20 >> the authorization server authenticates the resource owner and obtains >> an authorization decision (by asking the resource owner or by=20 >> establishing approval via other means).=20 >>=20 >> It can be implicit.=20 >>> Developers have been indicating that defining new user-id/pwds and addi= tionally sharing of profile information both cut back on the %age success of= new user registrations. Many want to offer an authenticate only option for t= heir users where the users explicitly decide what to supply in their profile= . Pseudonymous authen is a basic feature. >> This is supported by OpenID Connect as I stated above. =20 >>> I see other areas (e.g. Kitten) where authentication and re-authenticati= on may be of interest to other IETF groups. >>> There may be much broader requirements in the IETF community that are no= t of interest to OpenID Connect and its objectives >>=20 >> Why not?=20 >> =20 >>> While it is reasonable to make A4C and Connect as compatible as possible= , I am not sure they can be compatible. A4C and Connect are two different fl= ows solving different use cases with different security characteristics. >>=20 >> Why not? I do not see it. You are essentially reading OpenID Connect wron= g.=20 >> =20 >>>=20 >>> Note: I do not believe that the A4C draft is ready for last call-it is i= ntended only as input to the WG process. The features and aspects like how t= he flow is initiated need to be discussed within the wider IETF community wh= ere broad consensus can be obtained. This is why I feel having it a work gro= up milestone is important and I am willing to contribute my time towards it.= >>=20 >> Since it adds essentially nothing and produces wait-and-see among the imp= lementers, I think accepting this work as an work group item is actively har= mful for the internet. If something is needed to worked on in the work group= , I would rather want to see a profile of OpenID Connect referencing it. Tha= t causes much less confusion.=20 >> =20 >>>=20 >>> Because of the ongoing issue of inappropriate use of 6749 and the broade= r requirements within the IETF, I feel this work needs to be discussed withi= n the IETF WG.=20 >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-3CF1E5B6-898E-40E0-A7E9-340948D8B404 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I am offended. I may be wrong but I am= NOT mis-informing. Please prove your case. 

L= ets have a proper discussion. 

Phil

On May 2= 1, 2014, at 18:20, John Bradley <ve7= jtb@ve7jtb.com> wrote:

= Thanks Nat. I can't add anything to your response. 

Let's base our decision on adding authentication to OAuth 2 on reality= . 

Having a profile of Connect with most of th= e features Phil is looking for should not be a hard thing.   I don't pe= rsonally think it is required to have that happen in the OAuth WG. 


John B

Sent from my iPhone
=

On May 21, 2014, at 9:03 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Phil, please do not misinform the working= group. 

My responses inline: 


2014-05-22 3:56 GMT+09:00 P= hil Hunt <phil.hunt@oracle.com>:
Since several have voiced= the opinion that the WG should not work on providing user authentication co= ntext because OpenID Connect already has a solution, I wanted to make clear h= ow A4C is different from OpenID Connect.

OpenID Connect supports providing clients an =E2=80=9Cid_toke= n=E2=80=9D using the id_token response type in section 3.2 (ImplicitAuth) an= d 3.3 (Hybrid Auth) of the OAuth Core.

The A4C draft that was put forward by Mike, Tony, and my= self ( draft-hunt-oauth-v2-user-a4c ) desc= ribes a flow similar to the code flow of normal OAuth. Here are the differen= ces from Connect:

  • Client Authentication
    • Connect does N= OT authenticate the client prior to returning the id token. The Connect flow= is single step returning ID_TOKEN to an unauthenticated client in both 3.2 a= nd 3.3. Use of code flow in 3.3 appears only for the purpose of issuing an a= ccess token (user info token).
    • The A4C flow is 2-step following the OAuth2 code flow. It requires a cod= e to be exchanged for ID_TOKEN after client authenticates in the second step= (exactly duplicating the normal OAuth flow).  A4C requires mutual auth= entication of clients and AS service providers. A4C has the same logic and s= ecurity properties of the normal OAuth authorization flow.
This is not tr= ue. 

Connect for Code Flow for confidential client DOES authenticate the clien= t before getting an ID Token. 

Further, the= Connect has an option of asymmetrically encrypting ID Token with the public= key of the client, which authenticates the client even further. 
=
Even further, the Connect has an option of asymmetrically encrypting the req= uest with the public key of the server, which authenticates the server in ad= dition to TLS.  
  • User Authentication 
    • Both OpenID Connect and A4C return ID tokens which contain pretty= much the same information
    • A4C has additional features to a= llow clients to negotiate level of authentication and authentication types (= min LOA,ACR,AMR) in addition to just returning ACR as in the case of OpenID.=
What's the point of having both mini= mum LoA and AMR instead of ACR?  Connect can also return AMR. 
If you really wanted to have amr_values like feature, you can actuall= y request it by using Claims request as

  • There is a c= onsent problem because normal 6749 use requires users to consent to sharing i= nformation. Client developers in many cases would like an authen only profil= e where consent is implicit.
That's an implementation issue. RFC 6749 d= oes not require the users to provide explicit consent. 
It ju= st states: 

 the authorization server authenticates the resource owner= and obtains
   an authorization decision (by asking the resource owner or b=
y 
  &nbs= p;establishing approval via other means). 

It can be implicit. 
  • Developers have been indicating that defining new user-id/pwds &= nbsp;and additionally sharing of profile information both cut back on the %a= ge success of new user registrations. Many want to offer an authenticate onl= y option for their users where the users explicitly decide what to supply in= their profile.  Pseudonymous authen is a basic feature.
This is supported by OpenID Connect as I s= tated above.  
  • I see other areas (e.g. Kit= ten) where authentication and re-authentication may be of interest to other I= ETF groups.
    • There may be much broader requirements in the IETF c= ommunity that are not of interest to OpenID Connect and its objectives


Why no= t? 
 
While it is r= easonable to make A4C and Connect as compatible as possible, I am not sure t= hey can be compatible. A4C and Connect are two different flows solving diffe= rent use cases with different security characteristics.

Why not? I do not see it. You are ess= entially reading OpenID Connect wrong. 
 

Note: I do not b= elieve that the A4C draft is ready for last call-it is intended only as inpu= t to the WG process. The features and aspects like how the flow is initiated= need to be discussed within the wider IETF community where broad consensus c= an be obtained. This is why I feel having it a work group milestone is impor= tant and I am willing to contribute my time towards it.

Since it adds essentially nothi= ng and produces wait-and-see among the implementers, I think accepting this w= ork as an work group item is actively harmful for the internet. If something= is needed to worked on in the work group, I would rather want to see a prof= ile of OpenID Connect referencing it. That causes much less confusion. =
 

Because of the ongoing issue of inappropriate use of 6749 and the= broader requirements within the IETF, I feel this work needs to be discusse= d within the IETF WG. 


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




--
Nat Sakim= ura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-3CF1E5B6-898E-40E0-A7E9-340948D8B404-- From nobody Wed May 21 20:03:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE71C1A008F for ; Wed, 21 May 2014 20:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 jpceM1yRsErh for ; Wed, 21 May 2014 20:03:02 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7527F1A006D for ; Wed, 21 May 2014 20:03:02 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so4634298qgf.21 for ; Wed, 21 May 2014 20:03:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=H1+wJEM9Eo6ip7/cHzdzGbRQuegCUGs5XlGUlK1NKQw=; b=dGCdfJB5JbyVRYu5Jj8nGY1dM/j8fUzKsfN56qqA8+4wBuUn4mdbm6ew9FuLGvHYZR RuQD5YRY4RKmNcIlK5NKBkIGTpAi78zA/Ut9yUchPUdnZyD/cx/qs2Osvf+aR7gEcrV+ iOIjrpHiT3MNPGpXdg1K7It3ChlNtuzBlko3djpTBn74yExuBGV1RkbAGNNpfioCj2cM dvpPFv2I66neXsAdhsYiUEPqwMyemjSDh6U7j/91DEdwWR0+y5sAOqyN0eD+706kug0l 5I2dxkVkjOvUsLG4kgp+g8fWu97/b++8e42kGcjKiJwMDt0Qy1fo/ZAfI2Jf4aXidaSK ivTw== X-Gm-Message-State: ALoCoQmFL5GL0E0P0/UZmAJ7slO1eas8KjFLFnFuCcHofTsndqcIvz33hAQC9Rqhfg3IlVj9VWGS X-Received: by 10.140.19.76 with SMTP id 70mr27922911qgg.82.1400727780676; Wed, 21 May 2014 20:03:00 -0700 (PDT) Received: from [192.168.6.73] ([107.19.172.112]) by mx.google.com with ESMTPSA id u77sm1907367qga.46.2014.05.21.20.02.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 20:02:59 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2C5F13B7-BC9D-4B0D-8B4E-F791D3A55F10"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Bradley In-Reply-To: Date: Wed, 21 May 2014 23:02:45 -0400 Message-Id: <05B66D60-1B94-4595-A08E-7A045AF05ACB@ve7jtb.com> References: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> <1400275641.37471.YahooMailNeo@web142803.mail.bf1.yahoo.com> <537B5F2B.9090501@redhat.com> <483196B6-2989-4CEA-946D-6B9C269A257D@ve7jtb.com> To: Nat Sakimura X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/NWOoWblYSS4GPmP2g1jrD4B4CIo Cc: oauth Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 03:03:06 -0000 --Apple-Mail=_2C5F13B7-BC9D-4B0D-8B4E-F791D3A55F10 Content-Type: multipart/alternative; boundary="Apple-Mail=_3DBDFD57-CD29-402A-8375-5866917AE0E1" --Apple-Mail=_3DBDFD57-CD29-402A-8375-5866917AE0E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Q1 should be both. Limiting one but not the other is confusing to = developers. In the default case they are always the same size. Q2 Octets=20 John B. On May 21, 2014, at 9:38 PM, Nat Sakimura wrote: > Some more questions.=20 >=20 > Q1. Length limitation on=20 > code_challenge only > code_verifier only > both > Q2. Length in > Octents > Number of characters > My preference for Q2 is 1. as number of characters would not dictate = the actual length. A character is variable in length.=20 >=20 >=20 > 2014-05-22 10:25 GMT+09:00 John Bradley : > I think the current one is probably a OK compromise.=20 >=20 > Sent from my iPhone >=20 > On May 21, 2014, at 9:11 PM, Nat Sakimura wrote: >=20 >> Good! I achieve the purpose :-) >>=20 >> So what would be the appropriate length?=20 >> The current one would do?=20 >>=20 >>=20 >> 2014-05-20 22:56 GMT+09:00 Anil Saldhana : >> Brian - I agree with you. It should be MUST as long as the hard = limit is generous for usage. >>=20 >>=20 >>=20 >>=20 >> On 05/20/2014 07:09 AM, Brian Campbell wrote: >>> I'd say it should be a MUST so that implementations are consistent = about it. >>>=20 >>>=20 >>> On Fri, May 16, 2014 at 3:27 PM, Bill Mills = wrote: >>> The HTTP specs don't limit these things, but implementations do, and = the problems when you run into them are a rea pain. >>>=20 >>> DO we want to make this a hard limit, or should it be guidance in = the form of RECOMMENDED or SHOULD? >>>=20 >>> On Friday, May 16, 2014 9:35 AM, Brian Campbell = wrote: >>> Yeah, I agree with John here. There are a few good reasons to = restrict the length of the code_challenge. One is trying to keep the = authorization request URI to reasonable size as it will eventually run = into various limits on clients and/or servers. The other is constraining = the amount of data that an AS needs to store per code. >>>=20 >>>=20 >>>=20 >>>=20 >>> On Fri, May 16, 2014 at 7:41 AM, John Bradley = wrote: >>> =46rom the AS side you probably want to know what the max size you = need to store per code. >>>=20 >>> On the call to the token endpoint it is a POST so size should not be = an issue. =20 >>>=20 >>>=20 >>> On May 16, 2014, at 3:10 PM, Nat Sakimura = wrote: >>>=20 >>>> Now that I cannot remember what limit we were hitting, it might be = a good idea to remove the constraint and see if anyone protests.=20 >>>>=20 >>>> What do you think?=20 >>>>=20 >>>> Nat >>>>=20 >>>>=20 >>>> 2014-05-14 20:46 GMT+09:00 Brian Campbell = : >>>> That too would suggest that the length limit be on code_challenge = because that's the parameter that will be on URIs getting passed around. = The code_verifier is sent directly in the POST body from client to AS.=20= >>>>=20 >>>>=20 >>>> On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura = wrote: >>>> +1 for octet. We used to have "bytes" in JW* so I used "bytes" = here, while at the same time complaining in Jose that it should be = "octet". JW* changed to "octet" but I failed to sync with it in the last = few edits.=20 >>>>=20 >>>> I do not quite remember which platform, but the reason for the = limit was that some platform had some limitations as to the length of = the sting to be passed to it through URI and we did not want the = challenges to be truncated by that limit.=20 >>>>=20 >>>> Best,=20 >>>>=20 >>>> Nat >>>>=20 >>>>=20 >>>> 2014-05-13 6:56 GMT+09:00 Brian Campbell = : >>>>=20 >>>> And it'd give the AS some direct guidance on protecting itself from = crazy long code_challenge values rather than relying on the client not = to do something creative.=20 >>>>=20 >>>>=20 >>>> On Mon, May 12, 2014 at 3:54 PM, Brian Campbell = wrote: >>>> Right but that's why I'm asking why not just put the limit on = code_challange rather than inferring it from code_verifyer + challenge = algorithm, which probably bounds it but doesn't necessarily do so? It's = not a big deal but would read more clearly, I think. >>>>=20 >>>>=20 >>>> On Mon, May 12, 2014 at 3:48 PM, John Bradley = wrote: >>>> I think octets is more consistent with other JW* and OAuth specs. >>>>=20 >>>> The code_challange is the same length as the code_verifyer or is a = hash of the code_verifyer so likely smaller than 128octets (43 ish for = base64 256 bit) >>>>=20 >>>> Limiting the code_verifyer size sets the upper bound for = code_challange, unless someone comes up with a really creative code = challenge algorithm. >>>>=20 >>>> I will talk to nat about changing it to octets when I see him = tomorrow. >>>>=20 >>>> John B. >>>>=20 >>>> On May 12, 2014, at 11:15 PM, Derek Atkins wrote: >>>>=20 >>>> > Brian Campbell writes: >>>> > >>>> >> I notice that code_verifier is defined as "high entropy = cryptographic random >>>> >> string of length less than 128 bytes" [1], which brought a few = questions and >>>> >> comments to mind. So here goes: >>>> >> >>>> >> Talking about the length of a string in terms of bytes is always = potentially >>>> >> confusing. Maybe characters would be an easier unit for people = like me to wrap >>>> >> their little brains around? >>>> > >>>> > It depends if it really is characters or bytes. For example = there are >>>> > many multi-byte UTF-8 characters, so if it really is bytes then = saying >>>> > characters is wrong because it could overflow. So let's make = sure we >>>> > know what we're talking about. Historically, if we're talking = bytes the >>>> > IETF often uses the phrase "octets". Would that be less = confusing? >>>> > >>>> >> Why are we putting a length restriction on the code_verifier = anyway? It seems >>>> >> like it'd be more appropriate to restrict the length of the = code_challenge >>>> >> because that's the thing the AS will have to maintain somehow = (store in a DB >>>> >> or memory or encrypt into the code). Am I missing something = here? >>>> >> >>>> >> Let me also say that I hadn't looked at this document since its = early days in >>>> >> draft -00 or -01 last summer but I like the changes and how it's = been kept >>>> >> pretty simple for the common use-case while still allowing for = crypto agility/ >>>> >> extension. Nice work! >>>> >> >>>> >> [1] = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 >>>> > >>>> > -derek >>>> > >>>> >> _______________________________________________ >>>> >> OAuth mailing list >>>> >> OAuth@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>> > >>>> > -- >>>> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >>>> > Member, MIT Student Information Processing Board (SIPB) >>>> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >>>> > warlord@MIT.EDU PGP key available >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> =09 >>>> Brian Campbell >>>> Portfolio Architect >>>> @ bcampbell@pingidentity.com >>>> +1 720.317.2061 >>>> Connect with us=85 >>>> =20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> =09 >>>> Brian Campbell >>>> Portfolio Architect >>>> @ bcampbell@pingidentity.com >>>> +1 720.317.2061 >>>> Connect with us=85 >>>> =20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> =09 >>>> Brian Campbell >>>> Portfolio Architect >>>> @ bcampbell@pingidentity.com >>>> +1 720.317.2061 >>>> Connect with us=85 >>>> =20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --Apple-Mail=_3DBDFD57-CD29-402A-8375-5866917AE0E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Q1 = should be both.  Limiting one but not the other is confusing to = developers.  In the default case they are always the same = size.

Q2 Octets 

John = B.

On May 21, 2014, at 9:38 PM, Nat = Sakimura <sakimura@gmail.com> = wrote:

Some more = questions. 

Q1. Length limitation = on 
  1. code_challenge only
  2. code_verifier = only
  3. both
Q2. Length = in
  1. Octents
  2. Number of characters
My preference for Q2 = is 1. as number of characters would not dictate the actual length. A = character is variable in length. 


2014-05-22 10:25 GMT+09:00 John Bradley = <ve7jtb@ve7jtb.com>:
I think the current one is probably a OK = compromise. 

Sent from my iPhone

On May 21, 2014, at 9:11 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Good! I achieve the = purpose :-)

So what would be the appropriate = length? 
The current one would do? 


2014-05-20 22:56 GMT+09:00 Anil Saldhana = <Anil.Saldhana@redhat.com>:
=20 =20 =20
Brian - I agree with you.  It should be MUST as long as the hard limit is generous for usage.




On 05/20/2014 07:09 AM, Brian Campbell wrote:
I'd say it should be a MUST so that = implementations are consistent about it.


On Fri, May 16, 2014 at 3:27 PM, Bill Mills <wmills_92105@yahoo.com> wrote:
The HTTP specs don't limit these things, but implementations do, and the problems when you run into them are a rea pain.

DO we want to make this a hard limit, or should it be guidance in the form of RECOMMENDED or SHOULD?

On Friday, May 16, 2014 9:35 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Yeah, I agree with John here. There are a few good reasons to restrict the length of the code_challenge. One is trying to keep the authorization request URI to reasonable size as it will eventually run into various limits on clients and/or servers. The other is constraining the amount of data that an AS needs to store per code.




On Fri, May 16, 2014 at 7:41 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
From the AS side you probably want to know what the max size you need to store per code.

On the call to the token endpoint it is a POST so size should not be an issue.  


On May 16, 2014, at 3:10 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Now that I cannot remember what limit we were hitting, it might be a good idea to remove the constraint and see if anyone protests. 

What do you = think? 

Nat


2014-05-14 20:46 GMT+09:00 Brian Campbell = <bcampbell@pingidentity.com>:
That too would suggest that the length limit be on code_challenge because that's the parameter that will be on URIs getting passed around. The code_verifier is sent directly in the POST body from client to AS.


On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura = <sakimura@gmail.com> wrote:
+1 for octet. We used to have "bytes" in JW* so I used "bytes" here, while at the same time complaining in Jose that it should be "octet". JW* changed to "octet" but I failed to sync with it in the last few edits. 

I do not quite remember which platform, but the reason for the limit was that some platform had some limitations as to the length of the sting to be passed to it through URI and we did not want the challenges to be truncated by that = limit. 

=
Best, 

Nat


=
2014-05-13 6:56 GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:

And it'd give the AS some direct guidance on protecting itself from crazy long code_challenge values rather than relying on the client not to do something creative.


On Mon, May 12, 2014 at 3:54 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Right but that's why I'm asking why not just put the limit on code_challange rather than inferring it from code_verifyer + challenge algorithm, which probably bounds it but doesn't necessarily do so? It's not a big deal but would read more clearly, I think.


On Mon, May 12, 2014 at 3:48 PM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
I think octets is more consistent with other JW* and OAuth specs.

The code_challange is the same length as the code_verifyer or is a hash of the code_verifyer so likely smaller than 128octets (43 ish for base64 256 bit)

Limiting the code_verifyer size sets the upper bound for = code_challange, unless someone comes up with a really creative code challenge algorithm.

I will talk to nat about changing it to octets when I see him tomorrow.

John B.

On May 12, 2014, at 11:15 PM, Derek Atkins <warlord@MIT.EDU> wrote:

> Brian Campbell = <bcampbell@pingidentity.com> writes:
>
>> I notice that code_verifier is defined as "high entropy cryptographic random
>> string of length less than 128 bytes" =  [1], which brought a few questions = and
>> comments to mind. So here goes:
>>
>> Talking about the length of a string in terms of bytes is always potentially
>> confusing. Maybe characters would be an easier unit for people like me to wrap
>> their little brains around?
>
> It depends if it really is characters or bytes. =  For example there are
> many multi-byte UTF-8 characters, so if it really is bytes then saying
> characters is wrong because it could overflow. =  So let's make sure we
> know what we're talking about. =  Historically, if we're talking bytes the
> IETF often uses the phrase "octets".  Would = that be less confusing?
>
>> Why are we putting a length restriction on the code_verifier anyway? It seems
>> like it'd be more appropriate to restrict the length of the = code_challenge
>> because that's the thing the AS will have to maintain somehow (store in a DB
>> or memory or encrypt into the code). Am I missing something here?
>>
>> Let me also say that I hadn't looked at this document since its early days in
>> draft -00 or -01 last summer but I like the changes and how it's been kept
>> pretty simple for the common use-case while still allowing for crypto agility/
>> extension. Nice work!
>>
>> [1] = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#= section-3.3
>
> -derek
>
>> = _______________________________________________
>> OAuth mailing = list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>   =     Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>   =     Member, MIT Student Information Processing Board =  (SIPB)
>   =     URL: http://web.mit.edu/warlord/   =  PP-ASEL-IA     N1NWH
>   =     warlord@MIT.EDU =                     =    PGP key available




--
3D"Ping
Brian = Campbell
Portfolio = Architect
@ = bcampbell@pingidentity.com
3D"phone" = +1 = 720.317.2061
Connect with us=85
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard
3D"Register




--
3D"Ping
Brian = Campbell
Portfolio = Architect
@ = bcampbell@pingidentity.com
3D"phone" = +1 = 720.317.2061
Connect with us=85
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard
3D"Register


_______________________________________________
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



--
3D"Ping
Brian = Campbell
Portfolio = Architect
@ = bcampbell@pingidentity.com
3D"phone" = +1 = 720.317.2061
Connect with us=85
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard
3D"Register




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



=
_______________________________________________
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




--
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________=
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

= --Apple-Mail=_3DBDFD57-CD29-402A-8375-5866917AE0E1-- --Apple-Mail=_2C5F13B7-BC9D-4B0D-8B4E-F791D3A55F10 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA1MjIwMzAyNDVaMCMGCSqGSIb3DQEJBDEWBBQtrbfibkU1gyUK84wcHBIY GeQlNDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAnvzBTeUQuFjMYXg0YTYQyogQavvZpV1Vp43ulomr+lual2WPUGFMb cKm9L32cZcJI6+9r1uD5bRk21M2iTZH98+zEoL1zIdKvhavTk9dmi5YOKJFWES9bbluHaFmmhDyb 2rCTrludIvsMmTqhy2ROOTGNs+uFw0hmFfri1Fzp3Mk2Mo4j1+2iVX+5jakejyLhQSnXo8Rj51iD THwBrh86gq9BBmjUBN567uah6prqil1j+kp3sFWNdtmbamBTgcT/zkgKchegQ9UnNALmDlcnIM+g RIQHOdtwOyU1IY3FRxMu3DajU4w03GP2RRA91DUPfkM8n0zouKPQDqwUvDgdAAAAAAAA --Apple-Mail=_2C5F13B7-BC9D-4B0D-8B4E-F791D3A55F10-- From nobody Thu May 22 03:15:44 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46551A00CD for ; Thu, 22 May 2014 03:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, SPF_PASS=-0.001] autolearn=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 UZMOYPwaZPXM for ; Thu, 22 May 2014 03:15:39 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BFD31A0066 for ; Thu, 22 May 2014 03:15:39 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id hr17so2501425lab.17 for ; Thu, 22 May 2014 03:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BL7WBT9G4X3kxifGJxe/iP45Q6orviCp/mDJKEoTOBg=; b=ssGYZ1dGa/QWRAKtcRNHnOnRA8/H4x7TpM0KM4XM2QLxPebGFjkvxEl1iwLgLRisMU 4AWrOI4CUkomAX0cBRxm0F060wLx2IWUDGsgTiTFWVkHkKcRetf7Wb37yPpMkS+1HFUo jURe6PXtWhjMGEGrQi9kCUH+wcGdwidzhdyXAGUduUp5VffK5ZjuLGpd5BmfqU2Pjqjg EuMsEMeCTc5PhD5Tn6c6LfRJ6L7tIQ9wN7Hl1xQJLCHaFrMHdSh0FA/t6U1a66d1PGby RKtY6t8PJYAccP7RudQ2Iz7GsuLWfSIwOyl3xcEVXCix1+WoszQoSj1LAg9hB5awWP5A UWtg== MIME-Version: 1.0 X-Received: by 10.152.87.176 with SMTP id az16mr32417528lab.43.1400753736380; Thu, 22 May 2014 03:15:36 -0700 (PDT) Received: by 10.112.105.134 with HTTP; Thu, 22 May 2014 03:15:36 -0700 (PDT) In-Reply-To: <43FB363A-358F-4924-ADEE-D16D282645B4@oracle.com> References: <75D99637-1802-4C1F-83BE-D62AD938F9F4@oracle.com> <43FB363A-358F-4924-ADEE-D16D282645B4@oracle.com> Date: Thu, 22 May 2014 19:15:36 +0900 Message-ID: From: Nat Sakimura To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11c2600edff43604f9fa6488 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9FksUzvlXUjLWJ4zw_a2qzVwF_M Cc: OAuth WG Subject: Re: [OAUTH-WG] Authen Milestone: Comparing current A4C proposal to OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 10:15:42 -0000 --001a11c2600edff43604f9fa6488 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable it is all explained in my previous mail. Cheers, Nat 2014-05-22 11:07 GMT+09:00 Phil Hunt : > I am offended. I may be wrong but I am NOT mis-informing. Please prove > your case. > > Lets have a proper discussion. > > Phil > > On May 21, 2014, at 18:20, John Bradley wrote: > > Thanks Nat. I can't add anything to your response. > > Let's base our decision on adding authentication to OAuth 2 on reality. > > Having a profile of Connect with most of the features Phil is looking for > should not be a hard thing. I don't personally think it is required to > have that happen in the OAuth WG. > > > John B > > Sent from my iPhone > > On May 21, 2014, at 9:03 PM, Nat Sakimura wrote: > > Phil, please do not misinform the working group. > > My responses inline: > > > 2014-05-22 3:56 GMT+09:00 Phil Hunt : > >> Since several have voiced the opinion that the WG should not work on >> providing user authentication context because OpenID Connect already has= a >> solution, I wanted to make clear how A4C is different from OpenID Connec= t. >> >> OpenID Connect supports providing clients an =E2=80=9Cid_token=E2=80=9D = using the >> id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid Aut= h) >> of the OAuth Core. >> http://openid.net/specs/openid-connect-core-1_0.html >> >> The A4C draft that was put forward by Mike, Tony, and myself ( >> draft-hunt-oauth-v2-user-a4c ) describes >> a flow similar to the code flow of normal OAuth. Here are the difference= s >> from Connect: >> >> >> - Client Authentication >> - Connect does NOT authenticate the client prior to returning the >> id token. The Connect flow is single step returning ID_TOKEN to an >> unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.= 3 appears >> only for the purpose of issuing an access token (user info token). >> - The A4C flow is 2-step following the OAuth2 code flow. It >> requires a code to be exchanged for ID_TOKEN after client authenti= cates in >> the second step (exactly duplicating the normal OAuth flow). A4C = requires >> mutual authentication of clients and AS service providers. A4C has= the same >> logic and security properties of the normal OAuth authorization fl= ow. >> >> This is not true. > > Connect for Code Flow for confidential client DOES authenticate the clien= t > before getting an ID Token. > > Further, the Connect has an option of asymmetrically encrypting ID Token > with the public key of the client, which authenticates the client even > further. > Even further, the Connect has an option of asymmetrically encrypting the > request with the public key of the server, which authenticates the server > in addition to TLS. > >> >> - User Authentication >> - Both OpenID Connect and A4C return ID tokens which contain >> pretty much the same information >> - A4C has additional features to allow clients to negotiate level of >> authentication and authentication types (min LOA,ACR,AMR) in addit= ion to >> just returning ACR as in the case of OpenID. >> >> What's the point of having both minimum LoA and AMR instead of ACR? > Connect can also return AMR. > If you really wanted to have amr_values like feature, you can actually > request it by using Claims request as > > { "id_token": {"amr": {"values": ["otp","rsa"] }}} > > >> >> - A4C only make re-auth lighter weight. No need to issue UserInfo >> tokens again. Re-auth also re-authenticates the client as well as = user. >> >> I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C is > diverting from RFC6749. A4C is NOT OAuth anymore. The very reason OpenID > Connect returns an access token from the token endpoint always is to adhe= re > to RFC6749. > > OpenID Connect with scope=3Dopenid only is essentially the authN only > operation. > > >> - Privacy Option >> - The A4C=E2=80=99s authentication of the client makes it possible= to >> issue client-specific subject identifiers. This prevents multiple = clients >> from colluding to share information. >> >> This is supported by OpenID Connect as well. > >> >> - Because Connect doesn=E2=80=99t know who the client is, the subject >> identifier returned is universal. >> >> As stated above, this is false. It can even return PPID in the case of > public client as well. > >> >> - The spec could be used for pseudonymous authentication. >> >> As state above, OpenID Connect supports this. It in fact advise the use > of PPID (Pairwise Psuedonymous Identifier in section 17.3). > > >> >> As you can see the specs are doing similar things, but they have >> different security features. >> > > As stated above, I do not see much. It has less option in general, and > added feature is the amr_values and min_alv, which I do not see much valu= e > in it but if you really wanted, you can extend the Connect. > > >> >> As for need: >> >> - There are many sites using social network providers to authenticate >> using 6749 only, there are ongoing security concerns that many of us = have >> blogged about. *This may rise to the level of BUG on 6749.* >> >> Why not just use OpenID Connect? > >> >> - Some social network providers have indicated a willingness to >> support an authenticate only feature. I also had an inquiry if A4C ca= n be >> supported in OAuth1 as well as OAuth2. Some of this may be coming fro= m a >> business decision to use a proprietary user profile API instead (this= is >> not Oracle=E2=80=99s position). >> >> Authen only is fine with OpenID Connect. You can also use proprietary or > whatever the user profile API "in addition". For the purpose of > interoperability, it is better to have a standard user profile API though= , > and that's why Connect defines a very basic one for this purpose. > >> >> - There is a consent problem because normal 6749 use requires users >> to consent to sharing information. Client developers in many cases wo= uld >> like an authen only profile where consent is implicit. >> >> That's an implementation issue. RFC 6749 does not require the users to > provide explicit consent. > It just states: > > the authorization server authenticates the resource owner and obtains > > an authorization decision (by asking the resource owner or by > > establishing approval via other means). > > It can be implicit. > >> >> - Developers have been indicating that defining new user-id/pwds and >> additionally sharing of profile information both cut back on the %age >> success of new user registrations. Many want to offer an authenticate= only >> option for their users where the users explicitly decide what to supp= ly in >> their profile. Pseudonymous authen is a basic feature. >> >> This is supported by OpenID Connect as I stated above. > >> >> - I see other areas (e.g. Kitten) where authentication and >> re-authentication may be of interest to other IETF groups. >> - There may be much broader requirements in the IETF community >> that are not of interest to OpenID Connect and its objectives >> >> >> > Why not? > > >> While it is reasonable to make A4C and Connect as compatible as possible= , >> I am not sure they can be compatible. A4C and Connect are two different >> flows solving different use cases with different security characteristic= s. >> > > Why not? I do not see it. You are essentially reading OpenID Connect > wrong. > > >> >> Note: I do not believe that the A4C draft is ready for last call-it is >> intended only as input to the WG process. The features and aspects like = how >> the flow is initiated need to be discussed within the wider IETF communi= ty >> where broad consensus can be obtained. This is why I feel having it a wo= rk >> group milestone is important and I am willing to contribute my time towa= rds >> it. >> > > Since it adds essentially nothing and produces wait-and-see among the > implementers, I think accepting this work as an work group item is active= ly > harmful for the internet. If something is needed to worked on in the work > group, I would rather want to see a profile of OpenID Connect referencing > it. That causes much less confusion. > > >> >> Because of the ongoing issue of inappropriate use of 6749 and the broade= r >> requirements within the IETF, I feel this work needs to be discussed wit= hin >> the IETF WG. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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 --001a11c2600edff43604f9fa6488 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
it is all explained in my previous mail.=C2=A0

Cheers,=C2=A0

Nat


2014-05-22 11:07 GMT+09:00= Phil Hunt <phil.hunt@oracle.com>:
I am offended. I may = be wrong but I am NOT mis-informing. Please prove your case.=C2=A0

Lets have a proper discussion.=C2=A0

Phil
=

On May 21, 2014, at 18:20, John Bradley <ve7jtb@ve7jtb.com> wrote:

Thanks Nat. I can't add a= nything to your response.=C2=A0

Let's base our= decision on adding authentication to OAuth 2 on reality.=C2=A0
<= br>
Having a profile of Connect with most of the features Phil is looking = for should not be a hard thing. =C2=A0 I don't personally think it is r= equired to have that happen in the OAuth WG.=C2=A0


John B

Sent from my iPhone

On May 21, 2014, at 9:= 03 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Phil, please do not misinform the working group.=C2= =A0

My responses inline:=C2=A0


2014-05-22 3:56 GMT+09:00 Phil Hu= nt <phil.hunt@oracle.com>:
Since several have voi= ced the opinion that the WG should not work on providing user authenticatio= n context because OpenID Connect already has a solution, I wanted to make c= lear how A4C is different from OpenID Connect.

OpenID Connect supports providing clients an =E2=80=9Cid_tok= en=E2=80=9D using the id_token response type in section 3.2 (ImplicitAuth) = and 3.3 (Hybrid Auth) of the OAuth Core.

The A4C draft that was put forward by Mike, Tony, and m= yself (=C2=A0draft-hunt-oauth-v2-user-a4c=C2=A0)=C2=A0d= escribes a flow similar to the code flow of normal OAuth. Here are the diff= erences from Connect:

  • Client Authentication
    • Connect does = NOT authenticate the client prior to returning the id token. The Connect fl= ow is single step returning ID_TOKEN to an unauthenticated client in both 3= .2 and 3.3. Use of code flow in 3.3 appears only for the purpose of issuing= an access token (user info token).
    • The A4C flow is 2-step following the OAuth2 code flow. It requires a co= de to be exchanged for ID_TOKEN after client authenticates in the second st= ep (exactly duplicating the normal OAuth flow). =C2=A0A4C requires mutual a= uthentication of clients and AS service providers. A4C has the same logic a= nd security properties of the normal OAuth authorization flow.
This is not t= rue.=C2=A0

Connect for Code Flow for confidential client DOES authenticate the cl= ient before getting an ID Token.=C2=A0

Further, th= e Connect has an option of asymmetrically encrypting ID Token with the publ= ic key of the client, which authenticates the client even further.=C2=A0
Even further, the Connect has an option of asymmetrically encrypting the re= quest with the public key of the server, which authenticates the server in = addition to TLS. =C2=A0
  • User Authentication=C2=A0<= /li>
    • Both OpenID Connect and A4C return ID tokens which contain pret= ty much the same information
    • A4C has additional features t= o allow clients to negotiate level of authentication and authentication typ= es (min LOA,ACR,AMR) in addition to just returning ACR as in the case of Op= enID.
What's the point of having both= minimum LoA and AMR instead of ACR? =C2=A0Connect can also return AMR.=C2= =A0
If you really wanted to have amr_values like feature, you can= actually request it by using Claims request as

{ "id_= token": {"amr": {"values": ["otp","= rsa"] }}}
=C2=A0
=
    • A4C only make re-auth lighter weight. No need to issue UserInfo tokens = again. Re-auth also re-authenticates the client as well as user.
    <= /ul>
=C2=A0I RFC6749 Section 5.1 REQUIRES an a= ccess token to be returned. A4C is diverting from RFC6749. A4C is NOT OAuth= anymore. The very reason OpenID Connect returns an access token from the t= oken endpoint always is to adhere to RFC6749.=C2=A0

OpenID Connect with scope=3Dopenid only is essentially = the authN only operation.=C2=A0

  • Privacy Option
      • The A4C=E2=80=99s authentication of the client makes it possible to issue = client-specific subject identifiers. This prevents multiple clients from co= lluding to share information.
This is supported by OpenID Connect= as well. =C2=A0
    • Because Connect doesn= =E2=80=99t know who the client is, the subject identifier returned is unive= rsal.
As stated above, this is = false. It can even return PPID in the case of public client as well.=C2=A0<= /div>
    • The s= pec could be used for pseudonymous authentication.
As state above, OpenID Connect supp= orts this. It in fact advise the use of PPID (Pairwise Psuedonymous Identif= ier in section 17.3).=C2=A0
=C2=A0

As you can see= the specs are doing similar things, but they have different security featu= res.

As stated above, I d= o not see much. It has less option in general, and added feature is the amr= _values and min_alv, which I do not see much value in it but if you really = wanted, you can extend the Connect.=C2=A0
=C2=A0
=

As for need:
  • There are many sites using = social network providers to authenticate using 6749 only, there are ongoing= security concerns that many of us have blogged about. This may rise to = the level of BUG on 6749.
Why not just use OpenID Connect? =C2=A0<= /div>
  • Some social network provid= ers have indicated a willingness to support an authenticate only feature. I= also had an inquiry if A4C can be supported in OAuth1 as well as OAuth2. S= ome of this may be coming from a business decision to use a proprietary use= r profile API instead (this is not Oracle=E2=80=99s position).
Authen only is fine with OpenID Connect.= You can also use proprietary or whatever the user profile API "in add= ition". For the purpose of interoperability, it is better to have a st= andard user profile API though, and that's why Connect defines a very b= asic one for this purpose. =C2=A0
  • There is = a consent problem because normal 6749 use requires users to consent to shar= ing information. Client developers in many cases would like an authen only = profile where consent is implicit.
That's an implementation issue. RFC = 6749 does not require the users to provide explicit consent.=C2=A0
It just states:=C2=A0

=C2=A0the authorization server authenticates the resou= rce owner and obtains
   an authorization decision (by asking the resource owner or by=C2=A0<=
/pre>
=C2=A0 =C2=A0estab=
lishing approval via other means).=C2=A0




It can be implicit.=C2=A0



  • Developers have been indicating that defining new user-id/pwds=
 =C2=A0and additionally sharing of profile information both cut back on the=
 %age success of new user registrations. Many want to offer an authenticate=
 only option for their users where the users explicitly decide what to supp=
ly in their profile. =C2=A0Pseudonymous authen is a basic feature.
    • 


This is supported by OpenID Connect as I=
 stated above. =C2=A0



  • I see other areas (e.g. Ki=
tten) where authentication and re-authentication may be of interest to othe=
r IETF groups.
    • There may be much broader requirements in the IE=
TF community that are not of interest to OpenID Connect and its objectives<=
/li>




Why n=
ot?=C2=A0
=C2=A0



While it is =
reasonable to make A4C and Connect as compatible as possible, I am not sure=
 they can be compatible. A4C and Connect are two different flows solving di=
fferent use cases with different security characteristics.




Why not? I do not see it. You are es=
sentially reading OpenID Connect wrong.=C2=A0
=C2=A0




Note: I do not=
 believe that the A4C draft is ready for last call-it is intended only as i=
nput to the WG process. The features and aspects like how the flow is initi=
ated need to be discussed within the wider IETF community where broad conse=
nsus can be obtained. This is why I feel having it a work group milestone i=
s important and I am willing to contribute my time towards it.

Since it adds essentially noth= ing and produces wait-and-see among the implementers, I think accepting thi= s work as an work group item is actively harmful for the internet. If somet= hing is needed to worked on in the work group, I would rather want to see a= profile of OpenID Connect referencing it. That causes much less confusion.= =C2=A0
=C2=A0
=

Because of the ongoing issue of inappropriate use of 6749 and th= e broader requirements within the IETF, I feel this work needs to be discus= sed within the IETF WG.=C2=A0


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___________________= ____________________________
OAuth mailing list
<= span>OAuth@ietf.org=
https://www.ietf.org/mailman/listinfo/oauth



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation=
http://nat.sakim= ura.org/
@_nat_en
--001a11c2600edff43604f9fa6488-- From nobody Thu May 22 05:44:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3361A0020; Thu, 22 May 2014 05:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 N32AEegvs0PZ; Thu, 22 May 2014 05:43:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FA81A0091; Thu, 22 May 2014 05:43:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140522124355.10502.45564.idtracker@ietfa.amsl.com> Date: Thu, 22 May 2014 05:43:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ubd-O0zd7X30ppcXzzhLoVefE9Y Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-17.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 12:43:57 -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 Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Phil Hunt Filename : draft-ietf-oauth-dyn-reg-17.txt Pages : 38 Date : 2014-05-22 Abstract: This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server and the resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 22 05:45:51 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73FE1A0020; Thu, 22 May 2014 05:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 EJwoQSVY00N0; Thu, 22 May 2014 05:45:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5F01A0190; Thu, 22 May 2014 05:45:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140522124541.10502.6364.idtracker@ietfa.amsl.com> Date: Thu, 22 May 2014 05:45:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-QMsZuT3ehJwO5j1DTqU0_8p1fs Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 12:45:48 -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 Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Management Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Phil Hunt Filename : draft-ietf-oauth-dyn-reg-management-01.txt Pages : 16 Date : 2014-05-22 Abstract: This specification defines methods for management of dynamic OAuth 2.0 client registrations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-management-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 22 05:47:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3D41A019F; Thu, 22 May 2014 05:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 sHcaTTGMnEoE; Thu, 22 May 2014 05:46:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9361A0147; Thu, 22 May 2014 05:46:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140522124658.31945.17765.idtracker@ietfa.amsl.com> Date: Thu, 22 May 2014 05:46:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/NUAT0jzHJjpancB7kadM5UNLkgg Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-metadata-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 12:47:00 -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 Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Metadata Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Phil Hunt Filename : draft-ietf-oauth-dyn-reg-metadata-01.txt Pages : 4 Date : 2014-05-22 Abstract: This specification is obsolete. Its previous contents have been merged into draft-ietf-oauth-dyn-reg. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-metadata/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-metadata-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 22 05:51:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3441A00EF for ; Thu, 22 May 2014 05:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 sxLUGn6j9KWT for ; Thu, 22 May 2014 05:51:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DD01A0020 for ; Thu, 22 May 2014 05:51:34 -0700 (PDT) Received: from BY2PR03CA045.namprd03.prod.outlook.com (10.141.249.18) by BY2PR03MB458.namprd03.prod.outlook.com (10.141.141.144) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 22 May 2014 12:51:31 +0000 Received: from BY2FFO11FD053.protection.gbl (2a01:111:f400:7c0c::116) by BY2PR03CA045.outlook.office365.com (2a01:111:e400:2c5d::18) with Microsoft SMTP Server (TLS) id 15.0.944.11 via Frontend Transport; Thu, 22 May 2014 12:51:31 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD053.mail.protection.outlook.com (10.1.15.190) with Microsoft SMTP Server (TLS) id 15.0.949.9 via Frontend Transport; Thu, 22 May 2014 12:51:31 +0000 Received: from TK5EX14MBXC293.redmond.corp.microsoft.com ([169.254.2.113]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0181.007; Thu, 22 May 2014 12:50:56 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Merged OAuth Dynamic Client Registration Spec Thread-Index: Ac91vHyAUJda0skETueEsujfzH6XlA== Date: Thu, 22 May 2014 12:50:55 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD2E250@TK5EX14MBXC293.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD2E250TK5EX14MBXC293r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438001)(199002)(189002)(86362001)(71186001)(84326002)(83072002)(81542001)(55846006)(79102001)(512954002)(85852003)(33656002)(50986999)(16297215004)(86612001)(15202345003)(6806004)(68736004)(19625215002)(74662001)(76482001)(21056001)(74502001)(44976005)(15975445006)(77982001)(20776003)(81156002)(87936001)(19580395003)(99396002)(80022001)(26826002)(2656002)(97736001)(16236675002)(4396001)(81342001)(69596002)(31966008)(19300405004)(83322001)(92726001)(92566001)(84676001)(46102001)(54356999)(64706001)(66066001)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB458; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 021975AE46 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/CNCqrrbBLmXB2KwHgu5jcsJfpm8 Subject: [OAUTH-WG] Merged OAuth Dynamic Client Registration Spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 12:51:36 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD2E250TK5EX14MBXC293r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A new version of the OAuth Dynamic Client Registration specification has be= en published that folds the client metadata definitions back into the core = registration specification, as requested by the working group. The updated= spec is clear that the use of each of the defined client metadata fields i= s optional. The related registration management specification remains sepa= rate. The updated specifications are available at: * http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-17 * http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-01 HTML formatted versions are also available at: * https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-17.html * https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-management-= 01.html -- Mike P.S. I also posted this notice at http://self-issued.info/?p=3D1233 and as= @selfissued. --_000_4E1F6AAD24975D4BA5B16804296739439AD2E250TK5EX14MBXC293r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A new version of the OAuth Dynamic Client Registrati= on specification has been published that folds the client metadata definiti= ons back into the core registration specification, as requested by the work= ing group.  The updated spec is clear that the use of each of the defined client metadata fields is optional.&nb= sp; The related registration management specification remains separate.

 

The updated specifications are available at:

·        http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-= 17

·        http://tools.ietf.org/html/draft-ietf-oau= th-dyn-reg-management-01

 

HTML formatted versions are also available at:<= /o:p>

·        https://self-issued.info/docs/draft-ietf-oau= th-dyn-reg-17.html

·        https://self-issued.info/docs/dra= ft-ietf-oauth-dyn-reg-management-01.html

 

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

 

P.S.  I also posted this notice at http://self-issued.info/?p=3D1233 and as @selfissued.

 

--_000_4E1F6AAD24975D4BA5B16804296739439AD2E250TK5EX14MBXC293r_-- From nobody Thu May 22 06:41:15 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0C71A03B4 for ; Wed, 21 May 2014 13:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 0DXhLU7yiMvT for ; Wed, 21 May 2014 13:45:58 -0700 (PDT) Received: from PPLS5MAIL1.cernercloud.com (ppls5mail1.cernercloud.com [159.140.193.22]) (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 CB7751A019B for ; Wed, 21 May 2014 13:45:58 -0700 (PDT) Received: from pps.filterd (PPLS5MAIL1.cernercloud.com [127.0.0.1]) by PPLS5MAIL1.cernercloud.com (8.14.7/8.14.7) with SMTP id s4LKda3U012499 for ; Wed, 21 May 2014 15:45:56 -0500 Received: from cernmsgls5hub4.cerner.net ([170.71.96.39]) by PPLS5MAIL1.cernercloud.com with ESMTP id 1m10rks6jx-1 for ; Wed, 21 May 2014 15:45:56 -0500 Received: from CERNMSGLS5MB7B.cerner.net ([169.254.3.159]) by CERNMSGLS5HUB4.cerner.net ([170.71.96.39]) with mapi id 14.03.0174.001; Wed, 21 May 2014 15:45:56 -0500 From: "Clippard,Drew" To: "oauth@ietf.org" Thread-Topic: Broken Links to OAuth 1.0x Specs Thread-Index: AQHPdTWpkEFCDzamfkyFeqLc9JdJhw== Date: Wed, 21 May 2014 20:45:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [39.250.140.24] Content-Type: multipart/alternative; boundary="_000_CFA27A9578972MCLIPPARDCERNERCOM_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-21_07:2014-05-21,2014-05-21,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/KwWcCPy9YRmd1e8H7EQn1PNRBiI X-Mailman-Approved-At: Thu, 22 May 2014 06:41:13 -0700 Subject: [OAUTH-WG] Broken Links to OAuth 1.0x Specs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 20:46:00 -0000 --_000_CFA27A9578972MCLIPPARDCERNERCOM_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've noticed that the links to the OAuth 1.0x Specs, specifically [1, 2], l= isted here [3] return a 403 not authorized. Is there someone on this maili= ng list that could fix this? Or is there a better source to use to access = prior versions of the spec? Thanks, Drew [1] http://oauth.net/core/1.0/ [2] http://oauth.net/core/1.0a/ [3] http://oauth.net/documentation/ CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in Kansa= s City, Missouri, U.S.A at (+1) (816)221-1024. --_000_CFA27A9578972MCLIPPARDCERNERCOM_ Content-Type: text/html; charset="us-ascii" Content-ID: <7ED647A9A0C724449488D558201EF50A@cerner.com> Content-Transfer-Encoding: quoted-printable
I've noticed that the links to the OAuth 1.0x Specs, specifically [1, = 2], listed here [3] return a 403 not authorized.  Is there someone on = this mailing list that could fix this?  Or is there a better source to= use to access prior versions of the spec?

Thanks,
Drew

CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in K= ansas City, Missouri, U.S.A at (+1) (816)221-1024.
--_000_CFA27A9578972MCLIPPARDCERNERCOM_-- From nobody Thu May 22 07:09:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2D91A01EB for ; Thu, 22 May 2014 07:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 71MFsxVR2n2d for ; Thu, 22 May 2014 07:09:26 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5B91A01B9 for ; Thu, 22 May 2014 07:09:25 -0700 (PDT) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 22 May 2014 08:09:23 -0600 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 22 May 2014 08:09:20 -0600 Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id B09516E8045 for ; Thu, 22 May 2014 10:09:11 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by b01cxnp22036.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s4ME9B6H51052794 for ; Thu, 22 May 2014 14:09:19 GMT Received: from d01av05.pok.ibm.com (localhost [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s4ME8kpO021188 for ; Thu, 22 May 2014 10:08:46 -0400 Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av05.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s4ME8k72020568 for ; Thu, 22 May 2014 10:08:46 -0400 To: "IETF oauth WG" MIME-Version: 1.0 X-KeepSent: 0950279F:D87D033E-85257CE0:004D3F5B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP5SHF238 December 19, 2013 Message-ID: From: Todd W Lainhart Date: Thu, 22 May 2014 10:08:21 -0400 X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 9.0.1IF1|November 26, 2013) at 05/22/2014 10:08:46, Serialize complete at 05/22/2014 10:08:46 Content-Type: multipart/alternative; boundary="=_alternative 004DAB0685257CE0_=" X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14052214-9332-0000-0000-000000DF443E Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LpTIR2p3yAmHG7sanUdiYuw49qY Subject: [OAUTH-WG] For a client credentials grant, what are you returning as the value of the "sub" element in an introspection response? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:09:29 -0000 This is a multipart message in MIME format. --=_alternative 004DAB0685257CE0_= Content-Type: text/plain; charset="US-ASCII" For folks who have implemented the client credentials grant and introspection, I'm interested to know what you're returning for the value of "sub" in the token introspection response ( http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2.2 ). The "client_id" value requesting the grant, or some other client registration metadata value? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com --=_alternative 004DAB0685257CE0_= Content-Type: text/html; charset="US-ASCII" For folks who have implemented the client credentials grant and introspection, I'm interested to know what you're returning for the value of "sub" in the token introspection response (http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2.2).  The "client_id" value requesting the grant, or some other client registration metadata value?



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com

--=_alternative 004DAB0685257CE0_=-- From nobody Thu May 22 07:27:38 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62811A017A for ; Thu, 22 May 2014 07:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.952 X-Spam-Level: X-Spam-Status: No, score=-6.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Hswpdum0jN-M for ; Thu, 22 May 2014 07:27:33 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id C7AEB1A017D for ; Thu, 22 May 2014 07:27:29 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4MERRFc004617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 22 May 2014 10:27:28 -0400 Received: from localhost.localdomain (vpn-55-122.rdu2.redhat.com [10.10.55.122]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4MEROQY013047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 22 May 2014 10:27:26 -0400 Message-ID: <537E094C.6040504@redhat.com> Date: Thu, 22 May 2014 09:27:24 -0500 From: Anil Saldhana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: oauth@ietf.org References: <75D99637-1802-4C1F-83BE-D62AD938F9F4@oracle.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040403080806020802030601" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/7f1wEZhoGHljIsWz1-w5LaZSGrA Subject: Re: [OAUTH-WG] Authen Milestone: Comparing current A4C proposal to OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:27:36 -0000 This is a multi-part message in MIME format. --------------040403080806020802030601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John/Nat - would it be easy if you both can set up an OIDC profile for this use case? On 05/21/2014 08:20 PM, John Bradley wrote: > Thanks Nat. I can't add anything to your response. > > Let's base our decision on adding authentication to OAuth 2 on reality. > > Having a profile of Connect with most of the features Phil is looking > for should not be a hard thing. I don't personally think it is > required to have that happen in the OAuth WG. > > > John B > > Sent from my iPhone > > On May 21, 2014, at 9:03 PM, Nat Sakimura > wrote: > >> Phil, please do not misinform the working group. >> >> My responses inline: >> >> >> 2014-05-22 3:56 GMT+09:00 Phil Hunt > >: >> >> Since several have voiced the opinion that the WG should not work >> on providing user authentication context because OpenID Connect >> already has a solution, I wanted to make clear how A4C is >> different from OpenID Connect. >> >> OpenID Connect supports providing clients an "id_token" using the >> id_token response type in section 3.2 (ImplicitAuth) and 3.3 >> (Hybrid Auth) of the OAuth Core. >> http://openid.net/specs/openid-connect-core-1_0.html >> >> The A4C draft that was put forward by Mike, Tony, and myself ( >> draft-hunt-oauth-v2-user-a4c >> ) describes >> a flow similar to the code flow of normal OAuth. Here are the >> differences from Connect: >> >> * Client Authentication >> o Connect does NOT authenticate the client prior to >> returning the id token. The Connect flow is single step >> returning ID_TOKEN to an unauthenticated client in both >> 3.2 and 3.3. Use of code flow in 3.3 appears only for the >> purpose of issuing an access token (user info token). >> o The A4C flow is 2-step following the OAuth2 code flow. It >> requires a code to be exchanged for ID_TOKEN after client >> authenticates in the second step (exactly duplicating the >> normal OAuth flow). A4C requires mutual authentication >> of clients and AS service providers. A4C has the same >> logic and security properties of the normal OAuth >> authorization flow. >> >> This is not true. >> >> Connect for Code Flow for confidential client DOES authenticate the >> client before getting an ID Token. >> >> Further, the Connect has an option of asymmetrically encrypting ID >> Token with the public key of the client, which authenticates the >> client even further. >> Even further, the Connect has an option of asymmetrically encrypting >> the request with the public key of the server, which authenticates >> the server in addition to TLS. >> >> * User Authentication >> o Both OpenID Connect and A4C return ID tokens which >> contain pretty much the same information >> o A4C has additional features to allow clients to negotiate >> level of authentication and authentication types (min >> LOA,ACR,AMR) in addition to just returning ACR as in the >> case of OpenID. >> >> What's the point of having both minimum LoA and AMR instead of ACR? >> Connect can also return AMR. >> If you really wanted to have amr_values like feature, you can >> actually request it by using Claims request as >> >> { "id_token": {"amr": {"values": ["otp","rsa"] }}} >> >> o A4C only make re-auth lighter weight. No need to issue >> UserInfo tokens again. Re-auth also re-authenticates the >> client as well as user. >> >> I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C >> is diverting from RFC6749. A4C is NOT OAuth anymore. The very reason >> OpenID Connect returns an access token from the token endpoint always >> is to adhere to RFC6749. >> >> OpenID Connect with scope=openid only is essentially the authN only >> operation. >> >> * Privacy Option >> o The A4C's authentication of the client makes it possible >> to issue client-specific subject identifiers. This >> prevents multiple clients from colluding to share >> information. >> >> This is supported by OpenID Connect as well. >> >> o Because Connect doesn't know who the client is, the >> subject identifier returned is universal. >> >> As stated above, this is false. It can even return PPID in the case >> of public client as well. >> >> o The spec could be used for pseudonymous authentication. >> >> As state above, OpenID Connect supports this. It in fact advise the >> use of PPID (Pairwise Psuedonymous Identifier in section 17.3). >> >> >> As you can see the specs are doing similar things, but they have >> different security features. >> >> >> As stated above, I do not see much. It has less option in general, >> and added feature is the amr_values and min_alv, which I do not see >> much value in it but if you really wanted, you can extend the Connect. >> >> >> As for need: >> >> * There are many sites using social network providers to >> authenticate using 6749 only, there are ongoing security >> concerns that many of us have blogged about. *This may rise >> to the level of BUG on 6749.* >> >> Why not just use OpenID Connect? >> >> * Some social network providers have indicated a willingness to >> support an authenticate only feature. I also had an inquiry >> if A4C can be supported in OAuth1 as well as OAuth2. Some of >> this may be coming from a business decision to use a >> proprietary user profile API instead (this is not Oracle's >> position). >> >> Authen only is fine with OpenID Connect. You can also use proprietary >> or whatever the user profile API "in addition". For the purpose of >> interoperability, it is better to have a standard user profile API >> though, and that's why Connect defines a very basic one for this >> purpose. >> >> * There is a consent problem because normal 6749 use requires >> users to consent to sharing information. Client developers in >> many cases would like an authen only profile where consent is >> implicit. >> >> That's an implementation issue. RFC 6749 does not require the users >> to provide explicit consent. >> It just states: >> >> the authorization server authenticates the resource owner and obtains >> an authorization decision (by asking the resource owner or by >> establishing approval via other means). >> >> It can be implicit. >> >> * Developers have been indicating that defining new >> user-id/pwds and additionally sharing of profile information >> both cut back on the %age success of new user registrations. >> Many want to offer an authenticate only option for their >> users where the users explicitly decide what to supply in >> their profile. Pseudonymous authen is a basic feature. >> >> This is supported by OpenID Connect as I stated above. >> >> * I see other areas (e.g. Kitten) where authentication and >> re-authentication may be of interest to other IETF groups. >> o There may be much broader requirements in the IETF >> community that are not of interest to OpenID Connect and >> its objectives >> >> >> >> Why not? >> >> While it is reasonable to make A4C and Connect as compatible as >> possible, I am not sure they can be compatible. A4C and Connect >> are two different flows solving different use cases with >> different security characteristics. >> >> >> Why not? I do not see it. You are essentially reading OpenID Connect >> wrong. >> >> >> Note: I do not believe that the A4C draft is ready for last >> call-it is intended only as input to the WG process. The features >> and aspects like how the flow is initiated need to be discussed >> within the wider IETF community where broad consensus can be >> obtained. This is why I feel having it a work group milestone is >> important and I am willing to contribute my time towards it. >> >> >> Since it adds essentially nothing and produces wait-and-see among the >> implementers, I think accepting this work as an work group item is >> actively harmful for the internet. If something is needed to worked >> on in the work group, I would rather want to see a profile of OpenID >> Connect referencing it. That causes much less confusion. >> >> >> Because of the ongoing issue of inappropriate use of 6749 and the >> broader requirements within the IETF, I feel this work needs to >> be discussed within the IETF WG. >> >> Phil >> --------------040403080806020802030601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
John/Nat - would it be easy if you both can set up an OIDC profile for this use case?

On 05/21/2014 08:20 PM, John Bradley wrote:
Thanks Nat. I can't add anything to your response. 

Let's base our decision on adding authentication to OAuth 2 on reality. 

Having a profile of Connect with most of the features Phil is looking for should not be a hard thing.   I don't personally think it is required to have that happen in the OAuth WG. 


John B

Sent from my iPhone

On May 21, 2014, at 9:03 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Phil, please do not misinform the working group. 

My responses inline: 


2014-05-22 3:56 GMT+09:00 Phil Hunt <phil.hunt@oracle.com>:
Since several have voiced the opinion that the WG should not work on providing user authentication context because OpenID Connect already has a solution, I wanted to make clear how A4C is different from OpenID Connect.

OpenID Connect supports providing clients an “id_token” using the id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid Auth) of the OAuth Core.

The A4C draft that was put forward by Mike, Tony, and myself ( draft-hunt-oauth-v2-user-a4c ) describes a flow similar to the code flow of normal OAuth. Here are the differences from Connect:

  • Client Authentication
    • Connect does NOT authenticate the client prior to returning the id token. The Connect flow is single step returning ID_TOKEN to an unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.3 appears only for the purpose of issuing an access token (user info token).
    • The A4C flow is 2-step following the OAuth2 code flow. It requires a code to be exchanged for ID_TOKEN after client authenticates in the second step (exactly duplicating the normal OAuth flow).  A4C requires mutual authentication of clients and AS service providers. A4C has the same logic and security properties of the normal OAuth authorization flow.
This is not true. 

Connect for Code Flow for confidential client DOES authenticate the client before getting an ID Token. 

Further, the Connect has an option of asymmetrically encrypting ID Token with the public key of the client, which authenticates the client even further. 
Even further, the Connect has an option of asymmetrically encrypting the request with the public key of the server, which authenticates the server in addition to TLS.  
  • User Authentication 
    • Both OpenID Connect and A4C return ID tokens which contain pretty much the same information
    • A4C has additional features to allow clients to negotiate level of authentication and authentication types (min LOA,ACR,AMR) in addition to just returning ACR as in the case of OpenID.
What's the point of having both minimum LoA and AMR instead of ACR?  Connect can also return AMR. 
If you really wanted to have amr_values like feature, you can actually request it by using Claims request as

{ "id_token": {"amr": {"values": ["otp","rsa"] }}}
 
    • A4C only make re-auth lighter weight. No need to issue UserInfo tokens again. Re-auth also re-authenticates the client as well as user.
 I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C is diverting from RFC6749. A4C is NOT OAuth anymore. The very reason OpenID Connect returns an access token from the token endpoint always is to adhere to RFC6749. 

OpenID Connect with scope=openid only is essentially the authN only operation. 

  • Privacy Option
    • The A4C’s authentication of the client makes it possible to issue client-specific subject identifiers. This prevents multiple clients from colluding to share information.
This is supported by OpenID Connect as well.  
    • Because Connect doesn’t know who the client is, the subject identifier returned is universal.
As stated above, this is false. It can even return PPID in the case of public client as well. 
    • The spec could be used for pseudonymous authentication.
As state above, OpenID Connect supports this. It in fact advise the use of PPID (Pairwise Psuedonymous Identifier in section 17.3). 
 

As you can see the specs are doing similar things, but they have different security features.

As stated above, I do not see much. It has less option in general, and added feature is the amr_values and min_alv, which I do not see much value in it but if you really wanted, you can extend the Connect. 
 

As for need:
  • There are many sites using social network providers to authenticate using 6749 only, there are ongoing security concerns that many of us have blogged about. This may rise to the level of BUG on 6749.
Why not just use OpenID Connect?  
  • Some social network providers have indicated a willingness to support an authenticate only feature. I also had an inquiry if A4C can be supported in OAuth1 as well as OAuth2. Some of this may be coming from a business decision to use a proprietary user profile API instead (this is not Oracle’s position).
Authen only is fine with OpenID Connect. You can also use proprietary or whatever the user profile API "in addition". For the purpose of interoperability, it is better to have a standard user profile API though, and that's why Connect defines a very basic one for this purpose.  
  • There is a consent problem because normal 6749 use requires users to consent to sharing information. Client developers in many cases would like an authen only profile where consent is implicit.
That's an implementation issue. RFC 6749 does not require the users to provide explicit consent. 
It just states: 

 the authorization server authenticates the resource owner and obtains
   an authorization decision (by asking the resource owner or by 
   establishing approval via other means). 

It can be implicit. 
  • Developers have been indicating that defining new user-id/pwds  and additionally sharing of profile information both cut back on the %age success of new user registrations. Many want to offer an authenticate only option for their users where the users explicitly decide what to supply in their profile.  Pseudonymous authen is a basic feature.
This is supported by OpenID Connect as I stated above.  
  • I see other areas (e.g. Kitten) where authentication and re-authentication may be of interest to other IETF groups.
    • There may be much broader requirements in the IETF community that are not of interest to OpenID Connect and its objectives


Why not? 
 
While it is reasonable to make A4C and Connect as compatible as possible, I am not sure they can be compatible. A4C and Connect are two different flows solving different use cases with different security characteristics.

Why not? I do not see it. You are essentially reading OpenID Connect wrong. 
 

Note: I do not believe that the A4C draft is ready for last call-it is intended only as input to the WG process. The features and aspects like how the flow is initiated need to be discussed within the wider IETF community where broad consensus can be obtained. This is why I feel having it a work group milestone is important and I am willing to contribute my time towards it.

Since it adds essentially nothing and produces wait-and-see among the implementers, I think accepting this work as an work group item is actively harmful for the internet. If something is needed to worked on in the work group, I would rather want to see a profile of OpenID Connect referencing it. That causes much less confusion. 
 

Because of the ongoing issue of inappropriate use of 6749 and the broader requirements within the IETF, I feel this work needs to be discussed within the IETF WG. 

Phil

  --------------040403080806020802030601-- From nobody Thu May 22 07:45:15 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41ED31A017D for ; Thu, 22 May 2014 07:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 BZ_pzBXTAabk for ; Thu, 22 May 2014 07:45:11 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BF2E1A0127 for ; Thu, 22 May 2014 07:45:11 -0700 (PDT) X-AuditID: 1209190c-f79946d000000c3b-86-537e0d75effe Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id CD.AE.03131.57D0E735; Thu, 22 May 2014 10:45:09 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s4MEj8ec032683; Thu, 22 May 2014 10:45:09 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4MEj6FG008422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 May 2014 10:45:07 -0400 Message-ID: <537E0D6B.6070304@mit.edu> Date: Thu, 22 May 2014 10:44:59 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Todd W Lainhart , IETF oauth WG References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080302050108090101040003" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IR4hTV1i3lrQs26J+mZrG2dyabxcm3r9gc mDyWLPnJ5HHuWh9zAFMUl01Kak5mWWqRvl0CV8b8qwfZCj7IVkzsS2tgfCbWxcjJISFgInHn yUlGCFtM4sK99WwgtpDAbCaJa1tqIeyNjBJ3JvB1MXIB2beZJN5tug1WxCugJjFp6mOWLkYO DhYBVYnHbypAwmxA5vyVt5hAbFGBKIldfb/YIcoFJU7OfMICYosIeEos/buMGWSmsMAERolJ 73YyQSwLkpg84QgzyExOgWCJSxfMQMLMAmES37bdY53AyD8LyahZSFKzgDqYBawlvu0uggjL S2x/O4cZwtaWWNV7lglZfAEj2ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdQ73czBK91JTSTYzg gJbk2cH45qDSIUYBDkYlHl4L1rpgIdbEsuLK3EOMkhxMSqK8wWxAIb6k/JTKjMTijPii0pzU 4kOMEhzMSiK84txAOd6UxMqq1KJ8mJQ0B4uSOO9ba6tgIYH0xJLU7NTUgtQimKwMB4eSBG8f D1CjYFFqempFWmZOCUKaiYMTZDgP0PAYsOHFBYm5xZnpEPlTjIpS4rzGIAkBkERGaR5cLyzh vGIUB3pFmDcRZAUPMFnBdb8CGswENPjFwlqQwSWJCCmpBkYW9QMJy5vkrTmNdzX5bCvyzMq+ zMB0Kcc+OGqKwK+D7Vc/nDvW/WheK3Oi7We3/XsfX3LY9vzUzzu1ifu2364X2Jl0fMPN/4/b Yj0SVu416UnjfmPQKTOPN/qkKevxCb570job49rsjZp/fVqwh9/WL7nIfV7ctxsBj8z7gu3V BbI/xE7876fEUpyRaKjFXFScCACEbV16EwMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/xX5fod9obOSQWYLLGf4A9B6Ttd4 Subject: Re: [OAUTH-WG] For a client credentials grant, what are you returning as the value of the "sub" element in an introspection response? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:45:14 -0000 This is a multi-part message in MIME format. --------------080302050108090101040003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We return the client_id of the client that the token was issued to. -- Justin On 5/22/2014 10:08 AM, Todd W Lainhart wrote: > For folks who have implemented the client credentials grant and > introspection, I'm interested to know what you're returning for the > value of "sub" in the token introspection response > (http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2.2). > The "client_id" value requesting the grant, or some other client > registration metadata value? > * > > > Todd Lainhart > Rational software > IBM Corporation > 550 King Street, Littleton, MA 01460-1250** > 1-978-899-4705 > 2-276-4705 (T/L) > lainhart@us.ibm.com* > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------080302050108090101040003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
We return the client_id of the client that the token was issued to.

 -- Justin

On 5/22/2014 10:08 AM, Todd W Lainhart wrote:
For folks who have implemented the client credentials grant and introspection, I'm interested to know what you're returning for the value of "sub" in the token introspection response (http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2.2).  The "client_id" value requesting the grant, or some other client registration metadata value?



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com		 



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

--------------080302050108090101040003-- From nobody Thu May 22 07:50:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C46C1A015C for ; Thu, 22 May 2014 07:49:59 -0700 (PDT) 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, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 00oK-lYFaUdX for ; Thu, 22 May 2014 07:49:55 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC1C1A017D for ; Thu, 22 May 2014 07:49:55 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id x3so5837087qcv.38 for ; Thu, 22 May 2014 07:49:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=j6yng4VpU7RfKmIO91c5aDwah2XdVyFIBH2iTHYnqvg=; b=P1AFyNj57l7X0HGKsKQMSiEGzNenmUJSz3HCrU4yP8qFuLI/W69Om/0MH4ntGbmDTA x6TZ++v4mQ9a03J1l8/M/6dJjo+ZzQBW7O3UhvNwkkSM01SLpGjB620VwofIeLEJQep9 Ys0GTlg6af7iEqrcmyFPKlqe6DbL+k7s/5TkDLWCtD8uDDaAHngAcZ1umcl06MrvHbc7 u3xo6hf6luzGI78dVzMjY2JeiaS6Z9d+hUNzxIL4l+o9x8uUXtbxBEn48lkqusiDJWMN AJ6QFY21SjFZ2X4306643OlXeHc3wVmQ+ZH6fPBYa1XDJRTVWQ+SxB7zAaK2OaT7LI3Q ZpRA== X-Gm-Message-State: ALoCoQn5+VO2em/4e3qaI8gVmmRPLC90ZIfRAP/eqmaQYHtCxiZPJQA/Ehy8avq/Wulq+qrItNEB X-Received: by 10.224.32.138 with SMTP id c10mr68606219qad.35.1400770193497; Thu, 22 May 2014 07:49:53 -0700 (PDT) Received: from [10.2.2.165] (PING-IDENTI.bar1.Boston1.Level3.net. [4.31.154.18]) by mx.google.com with ESMTPSA id i16sm30376qge.9.2014.05.22.07.49.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 07:49:52 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_968CD958-F1A8-4441-A128-DC513598FABE"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Bradley In-Reply-To: <537E094C.6040504@redhat.com> Date: Thu, 22 May 2014 10:49:51 -0400 Message-Id: <871F561C-73FB-4783-AEEF-42A9BB68E22D@ve7jtb.com> References: <75D99637-1802-4C1F-83BE-D62AD938F9F4@oracle.com> <537E094C.6040504@redhat.com> To: Anil Saldhana X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ci2vUSmPbByL_d7CZwo-_zGD7T0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Authen Milestone: Comparing current A4C proposal to OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:49:59 -0000 --Apple-Mail=_968CD958-F1A8-4441-A128-DC513598FABE Content-Type: multipart/alternative; boundary="Apple-Mail=_AFA1ED86-C1DB-4BD8-9DB2-F3C278BDED85" --Apple-Mail=_AFA1ED86-C1DB-4BD8-9DB2-F3C278BDED85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Last week I was under the impression that Mike was working with Phil to = come up with a profile of Connect that basically takes a subset of the = basic client profile, and doesn't require changes to OAuth. I was waiting to look at that revision before digging back into this. That is likely still happening despite the confusion caused by this = thread. =20 I am considering doing a ID showing how the Connect Basic profile can be = used to replace proprietary SSO connectors. That would include a reference to = http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as a = way to do do IdP initiated. Basically the existing profile with a single IdP and client credentials = and reiterating the explanation from AOuth that scopes can be implicit = and consent can be granted out of band. That would allow a SAML to Connect proxy as an example. Having more than one input document may help the WG understand the = issues better. =20 Interested in discussing it? John B. On May 22, 2014, at 10:27 AM, Anil Saldhana = wrote:=20 > John/Nat - would it be easy if you both can set up an OIDC profile for = this use case? >=20 > On 05/21/2014 08:20 PM, John Bradley wrote: >> Thanks Nat. I can't add anything to your response.=20 >>=20 >> Let's base our decision on adding authentication to OAuth 2 on = reality.=20 >>=20 >> Having a profile of Connect with most of the features Phil is looking = for should not be a hard thing. I don't personally think it is = required to have that happen in the OAuth WG.=20 >>=20 >>=20 >> John B >>=20 >> Sent from my iPhone >>=20 >> On May 21, 2014, at 9:03 PM, Nat Sakimura wrote: >>=20 >>> Phil, please do not misinform the working group.=20 >>>=20 >>> My responses inline:=20 >>>=20 >>>=20 >>> 2014-05-22 3:56 GMT+09:00 Phil Hunt : >>> Since several have voiced the opinion that the WG should not work on = providing user authentication context because OpenID Connect already has = a solution, I wanted to make clear how A4C is different from OpenID = Connect. >>>=20 >>> OpenID Connect supports providing clients an =93id_token=94 using = the id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid = Auth) of the OAuth Core. >>> http://openid.net/specs/openid-connect-core-1_0.html >>>=20 >>> The A4C draft that was put forward by Mike, Tony, and myself ( = draft-hunt-oauth-v2-user-a4c ) describes a flow similar to the code flow = of normal OAuth. Here are the differences from Connect: >>>=20 >>> Client Authentication >>> Connect does NOT authenticate the client prior to returning the id = token. The Connect flow is single step returning ID_TOKEN to an = unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.3 = appears only for the purpose of issuing an access token (user info = token). >>> The A4C flow is 2-step following the OAuth2 code flow. It requires a = code to be exchanged for ID_TOKEN after client authenticates in the = second step (exactly duplicating the normal OAuth flow). A4C requires = mutual authentication of clients and AS service providers. A4C has the = same logic and security properties of the normal OAuth authorization = flow. >>> This is not true.=20 >>>=20 >>> Connect for Code Flow for confidential client DOES authenticate the = client before getting an ID Token.=20 >>>=20 >>> Further, the Connect has an option of asymmetrically encrypting ID = Token with the public key of the client, which authenticates the client = even further.=20 >>> Even further, the Connect has an option of asymmetrically encrypting = the request with the public key of the server, which authenticates the = server in addition to TLS. =20 >>> User Authentication=20 >>> Both OpenID Connect and A4C return ID tokens which contain pretty = much the same information >>> A4C has additional features to allow clients to negotiate level of = authentication and authentication types (min LOA,ACR,AMR) in addition to = just returning ACR as in the case of OpenID. >>> What's the point of having both minimum LoA and AMR instead of ACR? = Connect can also return AMR.=20 >>> If you really wanted to have amr_values like feature, you can = actually request it by using Claims request as >>>=20 >>> { "id_token": {"amr": {"values": ["otp","rsa"] }}} >>> =20 >>> A4C only make re-auth lighter weight. No need to issue UserInfo = tokens again. Re-auth also re-authenticates the client as well as user. >>> I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C = is diverting from RFC6749. A4C is NOT OAuth anymore. The very reason = OpenID Connect returns an access token from the token endpoint always is = to adhere to RFC6749.=20 >>>=20 >>> OpenID Connect with scope=3Dopenid only is essentially the authN = only operation.=20 >>>=20 >>> Privacy Option >>> The A4C=92s authentication of the client makes it possible to issue = client-specific subject identifiers. This prevents multiple clients from = colluding to share information. >>> This is supported by OpenID Connect as well. =20 >>> Because Connect doesn=92t know who the client is, the subject = identifier returned is universal. >>> As stated above, this is false. It can even return PPID in the case = of public client as well.=20 >>> The spec could be used for pseudonymous authentication. >>> As state above, OpenID Connect supports this. It in fact advise the = use of PPID (Pairwise Psuedonymous Identifier in section 17.3).=20 >>> =20 >>>=20 >>> As you can see the specs are doing similar things, but they have = different security features. >>>=20 >>> As stated above, I do not see much. It has less option in general, = and added feature is the amr_values and min_alv, which I do not see much = value in it but if you really wanted, you can extend the Connect.=20 >>> =20 >>>=20 >>> As for need: >>> There are many sites using social network providers to authenticate = using 6749 only, there are ongoing security concerns that many of us = have blogged about. This may rise to the level of BUG on 6749. >>> Why not just use OpenID Connect? =20 >>> Some social network providers have indicated a willingness to = support an authenticate only feature. I also had an inquiry if A4C can = be supported in OAuth1 as well as OAuth2. Some of = this may be coming from a business decision to use a proprietary user = profile API instead (this is not Oracle=92s position). >>> Authen only is fine with OpenID Connect. You can also use = proprietary or whatever the user profile API "in addition". For the = purpose of interoperability, it is better to have a standard user = profile API though, and that's why Connect defines a very basic one for = this purpose. =20 >>> There is a consent problem because normal 6749 use requires users to = consent to sharing information. Client developers in many cases would = like an authen only profile where consent is implicit. >>> That's an implementation issue. RFC 6749 does not require the users = to provide explicit consent.=20 >>> It just states:=20 >>>=20 >>> the authorization server authenticates the resource owner and = obtains >>> an authorization decision (by asking the resource owner or by=20 >>> establishing approval via other means).=20 >>>=20 >>> It can be implicit.=20 >>> Developers have been indicating that defining new user-id/pwds and = additionally sharing of profile information both cut back on the %age = success of new user registrations. Many want to offer an authenticate = only option for their users where the users explicitly decide what to = supply in their profile. Pseudonymous authen is a basic feature. >>> This is supported by OpenID Connect as I stated above. =20 >>> I see other areas (e.g. Kitten) where authentication and = re-authentication may be of interest to other IETF groups. >>> There may be much broader requirements in the IETF community that = are not of interest to OpenID Connect and its objectives >>>=20 >>>=20 >>> Why not?=20 >>> =20 >>> While it is reasonable to make A4C and Connect as compatible as = possible, I am not sure they can be compatible. A4C and Connect are two = different flows solving different use cases with different security = characteristics. >>>=20 >>> Why not? I do not see it. You are essentially reading OpenID Connect = wrong.=20 >>> =20 >>>=20 >>> Note: I do not believe that the A4C draft is ready for last call-it = is intended only as input to the WG process. The features and aspects = like how the flow is initiated need to be discussed within the wider = IETF community where broad consensus can be obtained. This is why I feel = having it a work group milestone is important and I am willing to = contribute my time towards it. >>>=20 >>> Since it adds essentially nothing and produces wait-and-see among = the implementers, I think accepting this work as an work group item is = actively harmful for the internet. If something is needed to worked on = in the work group, I would rather want to see a profile of OpenID = Connect referencing it. That causes much less confusion.=20 >>> =20 >>>=20 >>> Because of the ongoing issue of inappropriate use of 6749 and the = broader requirements within the IETF, I feel this work needs to be = discussed within the IETF WG.=20 >>>=20 >>> Phil >>>=20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_AFA1ED86-C1DB-4BD8-9DB2-F3C278BDED85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Last = week I was under the impression that Mike was working with Phil to come = up with a profile of Connect that basically takes a subset of the basic = client profile, and doesn't require changes to = OAuth.

I was waiting to look at that revision before = digging back into this.

That is likely still = happening despite the confusion caused by this thread. =   

I am considering doing a ID = showing how the Connect Basic profile can be used to replace proprietary = SSO connectors.
That would include a reference to = http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as = a way to do do IdP initiated.

Basically the = existing profile with a single IdP and client credentials and = reiterating the explanation from AOuth that scopes can be implicit and = consent can be granted out of band.

That would = allow a SAML to Connect proxy as an = example.

Having more than one input document = may help the WG understand the issues better. =  

Interested in discussing = it?

John = B.


On May 22, 2014, at 10:27 = AM, Anil Saldhana <Anil.Saldhana@redhat.com> = wrote: 

=20 =20
John/Nat - would it be easy if you = both can set up an OIDC profile for this use case?

On 05/21/2014 08:20 PM, John Bradley wrote:
Thanks Nat. I can't add anything to your = response. 

Let's base our decision on adding authentication to OAuth 2 on reality. 

Having a profile of Connect with most of the features Phil is looking for should not be a hard thing.   I don't = personally think it is required to have that happen in the OAuth = WG. 


John B

Sent from my iPhone

On May 21, 2014, at 9:03 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Phil, please do not misinform the working group. 

My responses inline: 


2014-05-22 3:56 GMT+09:00 Phil Hunt <phil.hunt@oracle.com>:
Since several have voiced the opinion that the WG should not work on providing user authentication context because OpenID Connect already has a solution, I wanted to make clear how A4C is different from OpenID Connect.

OpenID Connect supports providing clients an =93id_token=94 using the id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid Auth) of the OAuth Core.

The A4C draft that was put forward by Mike, Tony, and myself ( draft-hunt-oauth-v2-user-a4c ) describes a flow similar to the code flow of normal OAuth. Here are the differences from Connect:

  • Client Authentication
    • Connect does NOT authenticate the client prior to returning the id token. The Connect flow is single step returning ID_TOKEN to an unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.3 appears only for the purpose of issuing an access token (user info token).
    • The A4C flow is 2-step following the OAuth2 code flow. It requires a code to be exchanged for ID_TOKEN after client authenticates in the second step (exactly duplicating the normal OAuth flow). =  A4C requires mutual authentication of clients and AS service providers. A4C has the same logic and security properties of the normal OAuth authorization flow.
This is not true. 

Connect for Code Flow for confidential client DOES authenticate the client before getting an ID Token. 

Further, the Connect has an option of asymmetrically encrypting ID Token with the public key of the client, which authenticates the client even further. 
Even further, the Connect has an option of asymmetrically encrypting the request with the public key of the server, which authenticates the server in addition to TLS.  
  • User Authentication 
    • Both OpenID Connect and A4C return ID tokens which contain pretty much the same information
    • A4C has additional features to allow clients to negotiate level of authentication and authentication types (min LOA,ACR,AMR) in addition to just returning ACR as in the case of OpenID.
What's the point of having both minimum LoA and AMR instead of ACR?  Connect can also return = AMR. 
If you really wanted to have amr_values like feature, you can actually request it by using Claims request as

{ "id_token": {"amr": {"values": ["otp","rsa"] }}}
 
    • A4C only make re-auth lighter weight. No need to issue UserInfo tokens again. Re-auth also re-authenticates the client as well as user.
 I RFC6749 Section 5.1 REQUIRES an access = token to be returned. A4C is diverting from RFC6749. A4C is NOT OAuth anymore. The very reason OpenID Connect returns an access token from the token endpoint always is to adhere to RFC6749. 

OpenID Connect with scope=3Dopenid only is essentially the authN only operation. 

  • Privacy Option
    • The A4C=92s authentication of the client makes it possible to issue client-specific subject identifiers. This prevents multiple clients from colluding to share = information.
This is supported by OpenID Connect as well. =  
    • Because Connect doesn=92t know who the client is, the subject identifier returned is universal.
As stated above, this is false. It can even return PPID in the case of public client as well. 
    • The spec could be used for pseudonymous authentication.
As state above, OpenID Connect supports this. It in fact advise the use of PPID (Pairwise Psuedonymous Identifier in section 17.3). 
 

As you can see the specs are doing similar things, but they have different security features.

As stated above, I do not see much. It has less option in general, and added feature is the amr_values and min_alv, which I do not see much value in it but if you really wanted, you can extend the = Connect. 
 

As for need:
  • There are many sites using social network providers to authenticate using 6749 only, there are ongoing security concerns that many of us have blogged about. This may rise to the level of BUG on 6749.
Why not just use OpenID Connect?  
  • Some social network providers have indicated a willingness to support an authenticate only feature. I also had an inquiry if A4C can be supported in OAuth1 as well as OAuth2. Some of this may be coming from a business decision to use a proprietary user profile API instead (this is not Oracle=92s position).
Authen only is fine with OpenID Connect. You can also use proprietary or whatever the user profile API "in addition". For the purpose of interoperability, it is better to have a standard user profile API though, and that's why Connect defines a very basic one for this purpose.  
  • There is a consent problem because normal 6749 use requires users to consent to sharing information. Client developers in many cases would like an authen only profile where consent is implicit.
That's an implementation issue. RFC 6749 does not require the users to provide explicit = consent. 
It just states: 

 the authorization server authenticates the resource owner and obtains
   an authorization decision (by asking the =
resource owner or by 
   establishing approval via other = means). 

It can be implicit. 
  • Developers have been indicating that defining new user-id/pwds  and = additionally sharing of profile information both cut back on the %age success of new user registrations. Many want to offer an authenticate only option for their users where the users explicitly decide what to supply in their profile.  Pseudonymous authen is a basic = feature.
This is supported by OpenID Connect as I stated above.  
  • I see other areas (e.g. Kitten) where authentication and re-authentication may be of interest to other IETF groups.
    • There may be much broader requirements in the IETF community that are not of interest to OpenID Connect and its objectives


Why not? 
 
While it is reasonable to make A4C and Connect as compatible as possible, I am not sure they can be compatible. A4C and Connect are two different flows solving different use cases with different security characteristics.

Why not? I do not see it. You are essentially reading OpenID Connect wrong. 
 

Note: I do not believe that the A4C draft is ready for last call-it is intended only as input to the WG process. The features and aspects like how the flow is initiated need to be discussed within the wider IETF community where broad consensus can be obtained. This is why I feel having it a work group milestone is important and I am willing to contribute my time towards it.

Since it adds essentially nothing and produces wait-and-see among the implementers, I think accepting this work as an work group item is actively harmful for the internet. If something is needed to worked on in the work group, I would rather want to see a profile of OpenID Connect referencing it. That causes much less confusion. 
 

Because of the ongoing issue of inappropriate use of 6749 and the broader requirements within the IETF, I feel this work needs to be discussed within the IETF WG. 

Phil

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

= --Apple-Mail=_AFA1ED86-C1DB-4BD8-9DB2-F3C278BDED85-- --Apple-Mail=_968CD958-F1A8-4441-A128-DC513598FABE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA1MjIxNDQ5NTFaMCMGCSqGSIb3DQEJBDEWBBTM18RWiZv2kYC2LZCpa3mK dUSpcDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAcZ/E9mskHAk2PwBlDKXamS4mPi/Wmpo/EmGyloFT5HwS+c4TRD7zI t/mgJ85Bgkh+zX1ZQDMVWAqb2td+cMuZBQmVHaa2J+/ErUytc7L5icLXB3wcLdJspIvxl3lhJVdh 6rKXXfPMimyrEc09glZt76s+8jq4zCYKqIdgaeHiU2LShjC2cp9yAGSxvpk3vxtKsbUYPrUREOs0 9tKxcX5vTlkuwNnEtmfaD8GjmnkkEK9qUotJrM10xHxdfFLNVk/NDNvdunYPuCcyv/9y5cfs8JaP jp5yGf2o+4SZ56zrjdXgDPvl/rq5bdw3H8Xd70XxOwwnMJa4U1uEKG3uKId0AAAAAAAA --Apple-Mail=_968CD958-F1A8-4441-A128-DC513598FABE-- From nobody Thu May 22 07:59:44 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001EC1A00C6 for ; Thu, 22 May 2014 07:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.952 X-Spam-Level: X-Spam-Status: No, score=-6.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 3eRj7JK9rlzF for ; Thu, 22 May 2014 07:59:31 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 897D51A0208 for ; Thu, 22 May 2014 07:59:31 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4MExUFb021114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 May 2014 10:59:30 -0400 Received: from localhost.localdomain (vpn-55-122.rdu2.redhat.com [10.10.55.122]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4MExP1f007867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 22 May 2014 10:59:27 -0400 Message-ID: <537E10CD.6090309@redhat.com> Date: Thu, 22 May 2014 09:59:25 -0500 From: Anil Saldhana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John Bradley References: <75D99637-1802-4C1F-83BE-D62AD938F9F4@oracle.com> <537E094C.6040504@redhat.com> <871F561C-73FB-4783-AEEF-42A9BB68E22D@ve7jtb.com> In-Reply-To: <871F561C-73FB-4783-AEEF-42A9BB68E22D@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------010109090309050106010002" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/CyYCVFNyabT8FuRinVYi5RjEB3w Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Authen Milestone: Comparing current A4C proposal to OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:59:38 -0000 This is a multi-part message in MIME format. --------------010109090309050106010002 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 05/22/2014 09:49 AM, John Bradley wrote: > Last week I was under the impression that Mike was working with Phil > to come up with a profile of Connect that basically takes a subset of > the basic client profile, and doesn't require changes to OAuth. > > I was waiting to look at that revision before digging back into this. > > That is likely still happening despite the confusion caused by this > thread. > > I am considering doing a ID showing how the Connect Basic profile can > be used to replace proprietary SSO connectors. > That would include a reference to > http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as a > way to do do IdP initiated. > > Basically the existing profile with a single IdP and client > credentials and reiterating the explanation from AOuth that scopes can > be implicit and consent can be granted out of band. > > That would allow a SAML to Connect proxy as an example. > > Having more than one input document may help the WG understand the > issues better. > > Interested in discussing it? Definitely. Anybody else? > > John B. > > > On May 22, 2014, at 10:27 AM, Anil Saldhana > wrote: > >> John/Nat - would it be easy if you both can set up an OIDC profile >> for this use case? >> >> On 05/21/2014 08:20 PM, John Bradley wrote: >>> Thanks Nat. I can't add anything to your response. >>> >>> Let's base our decision on adding authentication to OAuth 2 on reality. >>> >>> Having a profile of Connect with most of the features Phil is >>> looking for should not be a hard thing. I don't personally think >>> it is required to have that happen in the OAuth WG. >>> >>> >>> John B >>> >>> Sent from my iPhone >>> >>> On May 21, 2014, at 9:03 PM, Nat Sakimura >> > wrote: >>> >>>> Phil, please do not misinform the working group. >>>> >>>> My responses inline: >>>> >>>> >>>> 2014-05-22 3:56 GMT+09:00 Phil Hunt >>> >: >>>> >>>> Since several have voiced the opinion that the WG should not >>>> work on providing user authentication context because OpenID >>>> Connect already has a solution, I wanted to make clear how A4C >>>> is different from OpenID Connect. >>>> >>>> OpenID Connect supports providing clients an “id_token” using >>>> the id_token response type in section 3.2 (ImplicitAuth) and >>>> 3.3 (Hybrid Auth) of the OAuth Core. >>>> http://openid.net/specs/openid-connect-core-1_0.html >>>> >>>> The A4C draft that was put forward by Mike, Tony, and myself ( >>>> draft-hunt-oauth-v2-user-a4c >>>> ) describes >>>> a flow similar to the code flow of normal OAuth. Here are the >>>> differences from Connect: >>>> >>>> * Client Authentication >>>> o Connect does NOT authenticate the client prior to >>>> returning the id token. The Connect flow is single step >>>> returning ID_TOKEN to an unauthenticated client in both >>>> 3.2 and 3.3. Use of code flow in 3.3 appears only for >>>> the purpose of issuing an access token (user info token). >>>> o The A4C flow is 2-step following the OAuth2 code flow. >>>> It requires a code to be exchanged for ID_TOKEN after >>>> client authenticates in the second step (exactly >>>> duplicating the normal OAuth flow). A4C requires >>>> mutual authentication of clients and AS service >>>> providers. A4C has the same logic and security >>>> properties of the normal OAuth authorization flow. >>>> >>>> This is not true. >>>> >>>> Connect for Code Flow for confidential client DOES authenticate the >>>> client before getting an ID Token. >>>> >>>> Further, the Connect has an option of asymmetrically encrypting ID >>>> Token with the public key of the client, which authenticates the >>>> client even further. >>>> Even further, the Connect has an option of asymmetrically >>>> encrypting the request with the public key of the server, which >>>> authenticates the server in addition to TLS. >>>> >>>> * User Authentication >>>> o Both OpenID Connect and A4C return ID tokens which >>>> contain pretty much the same information >>>> o A4C has additional features to allow clients to >>>> negotiate level of authentication and authentication >>>> types (min LOA,ACR,AMR) in addition to just returning >>>> ACR as in the case of OpenID. >>>> >>>> What's the point of having both minimum LoA and AMR instead of ACR? >>>> Connect can also return AMR. >>>> If you really wanted to have amr_values like feature, you can >>>> actually request it by using Claims request as >>>> >>>> { "id_token": {"amr": {"values": ["otp","rsa"] }}} >>>> >>>> o A4C only make re-auth lighter weight. No need to issue >>>> UserInfo tokens again. Re-auth also re-authenticates >>>> the client as well as user. >>>> >>>> I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C >>>> is diverting from RFC6749. A4C is NOT OAuth anymore. The very >>>> reason OpenID Connect returns an access token from the token >>>> endpoint always is to adhere to RFC6749. >>>> >>>> OpenID Connect with scope=openid only is essentially the authN only >>>> operation. >>>> >>>> * Privacy Option >>>> o The A4C’s authentication of the client makes it >>>> possible to issue client-specific subject identifiers. >>>> This prevents multiple clients from colluding to share >>>> information. >>>> >>>> This is supported by OpenID Connect as well. >>>> >>>> o Because Connect doesn’t know who the client is, the >>>> subject identifier returned is universal. >>>> >>>> As stated above, this is false. It can even return PPID in the case >>>> of public client as well. >>>> >>>> o The spec could be used for pseudonymous authentication. >>>> >>>> As state above, OpenID Connect supports this. It in fact advise the >>>> use of PPID (Pairwise Psuedonymous Identifier in section 17.3). >>>> >>>> >>>> As you can see the specs are doing similar things, but they >>>> have different security features. >>>> >>>> >>>> As stated above, I do not see much. It has less option in general, >>>> and added feature is the amr_values and min_alv, which I do not see >>>> much value in it but if you really wanted, you can extend the Connect. >>>> >>>> >>>> As for need: >>>> >>>> * There are many sites using social network providers to >>>> authenticate using 6749 only, there are ongoing security >>>> concerns that many of us have blogged about. *This may rise >>>> to the level of BUG on 6749.* >>>> >>>> Why not just use OpenID Connect? >>>> >>>> * Some social network providers have indicated a willingness >>>> to support an authenticate only feature. I also had an >>>> inquiry if A4C can be supported in OAuth1 as well as >>>> OAuth2. Some of this may be coming from a business decision >>>> to use a proprietary user profile API instead (this is not >>>> Oracle’s position). >>>> >>>> Authen only is fine with OpenID Connect. You can also use >>>> proprietary or whatever the user profile API "in addition". For the >>>> purpose of interoperability, it is better to have a standard user >>>> profile API though, and that's why Connect defines a very basic one >>>> for this purpose. >>>> >>>> * There is a consent problem because normal 6749 use requires >>>> users to consent to sharing information. Client developers >>>> in many cases would like an authen only profile where >>>> consent is implicit. >>>> >>>> That's an implementation issue. RFC 6749 does not require the users >>>> to provide explicit consent. >>>> It just states: >>>> >>>> the authorization server authenticates the resource owner and obtains >>>> an authorization decision (by asking the resource owner or by >>>> establishing approval via other means). >>>> >>>> It can be implicit. >>>> >>>> * Developers have been indicating that defining new >>>> user-id/pwds and additionally sharing of profile >>>> information both cut back on the %age success of new user >>>> registrations. Many want to offer an authenticate only >>>> option for their users where the users explicitly decide >>>> what to supply in their profile. Pseudonymous authen is a >>>> basic feature. >>>> >>>> This is supported by OpenID Connect as I stated above. >>>> >>>> * I see other areas (e.g. Kitten) where authentication and >>>> re-authentication may be of interest to other IETF groups. >>>> o There may be much broader requirements in the IETF >>>> community that are not of interest to OpenID Connect >>>> and its objectives >>>> >>>> >>>> >>>> Why not? >>>> >>>> While it is reasonable to make A4C and Connect as compatible as >>>> possible, I am not sure they can be compatible. A4C and Connect >>>> are two different flows solving different use cases with >>>> different security characteristics. >>>> >>>> >>>> Why not? I do not see it. You are essentially reading OpenID >>>> Connect wrong. >>>> >>>> >>>> Note: I do not believe that the A4C draft is ready for last >>>> call-it is intended only as input to the WG process. The >>>> features and aspects like how the flow is initiated need to be >>>> discussed within the wider IETF community where broad consensus >>>> can be obtained. This is why I feel having it a work group >>>> milestone is important and I am willing to contribute my time >>>> towards it. >>>> >>>> >>>> Since it adds essentially nothing and produces wait-and-see among >>>> the implementers, I think accepting this work as an work group item >>>> is actively harmful for the internet. If something is needed to >>>> worked on in the work group, I would rather want to see a profile >>>> of OpenID Connect referencing it. That causes much less confusion. >>>> >>>> >>>> Because of the ongoing issue of inappropriate use of 6749 and >>>> the broader requirements within the IETF, I feel this work >>>> needs to be discussed within the IETF WG. >>>> >>>> Phil >>>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --------------010109090309050106010002 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 05/22/2014 09:49 AM, John Bradley wrote:
Last week I was under the impression that Mike was working with Phil to come up with a profile of Connect that basically takes a subset of the basic client profile, and doesn't require changes to OAuth.

I was waiting to look at that revision before digging back into this.

That is likely still happening despite the confusion caused by this thread.   

I am considering doing a ID showing how the Connect Basic profile can be used to replace proprietary SSO connectors.
That would include a reference to http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as a way to do do IdP initiated.

Basically the existing profile with a single IdP and client credentials and reiterating the explanation from AOuth that scopes can be implicit and consent can be granted out of band.

That would allow a SAML to Connect proxy as an example.

Having more than one input document may help the WG understand the issues better.  

Interested in discussing it?
Definitely.  Anybody else?

John B.


On May 22, 2014, at 10:27 AM, Anil Saldhana <Anil.Saldhana@redhat.com> wrote: 

John/Nat - would it be easy if you both can set up an OIDC profile for this use case?

On 05/21/2014 08:20 PM, John Bradley wrote:
Thanks Nat. I can't add anything to your response. 

Let's base our decision on adding authentication to OAuth 2 on reality. 

Having a profile of Connect with most of the features Phil is looking for should not be a hard thing.   I don't personally think it is required to have that happen in the OAuth WG. 


John B

Sent from my iPhone

On May 21, 2014, at 9:03 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Phil, please do not misinform the working group. 

My responses inline: 


2014-05-22 3:56 GMT+09:00 Phil Hunt <phil.hunt@oracle.com>:
Since several have voiced the opinion that the WG should not work on providing user authentication context because OpenID Connect already has a solution, I wanted to make clear how A4C is different from OpenID Connect.

OpenID Connect supports providing clients an “id_token” using the id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid Auth) of the OAuth Core.

The A4C draft that was put forward by Mike, Tony, and myself ( draft-hunt-oauth-v2-user-a4c ) describes a flow similar to the code flow of normal OAuth. Here are the differences from Connect:

  • Client Authentication
    • Connect does NOT authenticate the client prior to returning the id token. The Connect flow is single step returning ID_TOKEN to an unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.3 appears only for the purpose of issuing an access token (user info token).
    • The A4C flow is 2-step following the OAuth2 code flow. It requires a code to be exchanged for ID_TOKEN after client authenticates in the second step (exactly duplicating the normal OAuth flow).  A4C requires mutual authentication of clients and AS service providers. A4C has the same logic and security properties of the normal OAuth authorization flow.
This is not true. 

Connect for Code Flow for confidential client DOES authenticate the client before getting an ID Token. 

Further, the Connect has an option of asymmetrically encrypting ID Token with the public key of the client, which authenticates the client even further. 
Even further, the Connect has an option of asymmetrically encrypting the request with the public key of the server, which authenticates the server in addition to TLS.  
  • User Authentication 
    • Both OpenID Connect and A4C return ID tokens which contain pretty much the same information
    • A4C has additional features to allow clients to negotiate level of authentication and authentication types (min LOA,ACR,AMR) in addition to just returning ACR as in the case of OpenID.
What's the point of having both minimum LoA and AMR instead of ACR?  Connect can also return AMR. 
If you really wanted to have amr_values like feature, you can actually request it by using Claims request as

{ "id_token": {"amr": {"values": ["otp","rsa"] }}}
 
    • A4C only make re-auth lighter weight. No need to issue UserInfo tokens again. Re-auth also re-authenticates the client as well as user.
 I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C is diverting from RFC6749. A4C is NOT OAuth anymore. The very reason OpenID Connect returns an access token from the token endpoint always is to adhere to RFC6749. 

OpenID Connect with scope=openid only is essentially the authN only operation. 

  • Privacy Option
    • The A4C’s authentication of the client makes it possible to issue client-specific subject identifiers. This prevents multiple clients from colluding to share information.
This is supported by OpenID Connect as well.  
    • Because Connect doesn’t know who the client is, the subject identifier returned is universal.
As stated above, this is false. It can even return PPID in the case of public client as well. 
    • The spec could be used for pseudonymous authentication.
As state above, OpenID Connect supports this. It in fact advise the use of PPID (Pairwise Psuedonymous Identifier in section 17.3). 
 

As you can see the specs are doing similar things, but they have different security features.

As stated above, I do not see much. It has less option in general, and added feature is the amr_values and min_alv, which I do not see much value in it but if you really wanted, you can extend the Connect. 
 

As for need:
  • There are many sites using social network providers to authenticate using 6749 only, there are ongoing security concerns that many of us have blogged about. This may rise to the level of BUG on 6749.
Why not just use OpenID Connect?  
  • Some social network providers have indicated a willingness to support an authenticate only feature. I also had an inquiry if A4C can be supported in OAuth1 as well as OAuth2. Some of this may be coming from a business decision to use a proprietary user profile API instead (this is not Oracle’s position).
Authen only is fine with OpenID Connect. You can also use proprietary or whatever the user profile API "in addition". For the purpose of interoperability, it is better to have a standard user profile API though, and that's why Connect defines a very basic one for this purpose.  
  • There is a consent problem because normal 6749 use requires users to consent to sharing information. Client developers in many cases would like an authen only profile where consent is implicit.
That's an implementation issue. RFC 6749 does not require the users to provide explicit consent. 
It just states: 

 the authorization server authenticates the resource owner and obtains
   an authorization decision (by asking the resource owner or by 
   establishing approval via other means). 

It can be implicit. 
  • Developers have been indicating that defining new user-id/pwds  and additionally sharing of profile information both cut back on the %age success of new user registrations. Many want to offer an authenticate only option for their users where the users explicitly decide what to supply in their profile.  Pseudonymous authen is a basic feature.
This is supported by OpenID Connect as I stated above.  
  • I see other areas (e.g. Kitten) where authentication and re-authentication may be of interest to other IETF groups.
    • There may be much broader requirements in the IETF community that are not of interest to OpenID Connect and its objectives


Why not? 
 
While it is reasonable to make A4C and Connect as compatible as possible, I am not sure they can be compatible. A4C and Connect are two different flows solving different use cases with different security characteristics.

Why not? I do not see it. You are essentially reading OpenID Connect wrong. 
 

Note: I do not believe that the A4C draft is ready for last call-it is intended only as input to the WG process. The features and aspects like how the flow is initiated need to be discussed within the wider IETF community where broad consensus can be obtained. This is why I feel having it a work group milestone is important and I am willing to contribute my time towards it.

Since it adds essentially nothing and produces wait-and-see among the implementers, I think accepting this work as an work group item is actively harmful for the internet. If something is needed to worked on in the work group, I would rather want to see a profile of OpenID Connect referencing it. That causes much less confusion. 
 

Because of the ongoing issue of inappropriate use of 6749 and the broader requirements within the IETF, I feel this work needs to be discussed within the IETF WG. 

Phil

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


--------------010109090309050106010002-- From nobody Thu May 22 08:02:38 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3C31A021E for ; Thu, 22 May 2014 08:02:24 -0700 (PDT) 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, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 bVFN4SmIJWrB for ; Thu, 22 May 2014 08:02:19 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C90F1A021C for ; Thu, 22 May 2014 08:02:19 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id i8so6023269qcq.29 for ; Thu, 22 May 2014 08:02:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=HUAO8H2gEd7A+Gt/jhdDlgxQEiNifQ2C87KOOnqkLb4=; b=TJP4sec4A2tKF80A8r2yW+121wQFc2Q/gAIwkBzN0V34ihLk+5NdGtUJz4NqSBIaE3 Lwgb+Cx/vARLR+mgUrNo3JPXZVNOvVPM4JjSKtz9LSlCkXrFlRW13+mcOIzsbLkZ8aeL 8rPdkxcFK1gWRhN12p+d+nlozI+2nEgVMiQX49JAvrirwu4l+bCkYxtBhY+zyqc672S9 FxNyQRZ6iUSAf9XhQ8CaBYsnXbWCN176leUO6Zq+L3+Zr244XhISnRjFekkkisYSUJAk XUWORZmuN0TC5r0hyAYEA4kVOHyoUj1hNjRKmfLxp5ehMgYZP5Q9fc18f5KTRZPsliun ERag== X-Gm-Message-State: ALoCoQllGmyu8ud6+Eja/ZZbF/j39pBloqvvuT0kBFZVUPYZcEfevflXjgcp1Bfmjlh2WvL/X+uP X-Received: by 10.140.88.241 with SMTP id t104mr77769712qgd.29.1400770937529; Thu, 22 May 2014 08:02:17 -0700 (PDT) Received: from [10.2.2.165] (PING-IDENTI.bar1.Boston1.Level3.net. [4.31.154.18]) by mx.google.com with ESMTPSA id 7sm44230qgj.27.2014.05.22.08.02.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 08:02:16 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_97BA8279-B6B8-475E-8BFB-00CE44D2EFE5"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Bradley In-Reply-To: <537E10CD.6090309@redhat.com> Date: Thu, 22 May 2014 11:02:15 -0400 Message-Id: <18209701-C62F-4CAC-9D2D-E3B305D5ECEC@ve7jtb.com> References: <75D99637-1802-4C1F-83BE-D62AD938F9F4@oracle.com> <537E094C.6040504@redhat.com> <871F561C-73FB-4783-AEEF-42A9BB68E22D@ve7jtb.com> <537E10CD.6090309@redhat.com> To: Anil Saldhana X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/iDRNvFom71-hXk0NR6TXvufteu8 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Authen Milestone: Comparing current A4C proposal to OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 15:02:25 -0000 --Apple-Mail=_97BA8279-B6B8-475E-8BFB-00CE44D2EFE5 Content-Type: multipart/alternative; boundary="Apple-Mail=_A2D61D08-B921-4A59-B4FA-966046B2224D" --Apple-Mail=_A2D61D08-B921-4A59-B4FA-966046B2224D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I was thinking of asking Brian Campbell as long as he doesn't let it go = to his head. I expect Layer7 and others might also have an interest in such a thing. John B. On May 22, 2014, at 10:59 AM, Anil Saldhana = wrote: > On 05/22/2014 09:49 AM, John Bradley wrote: >> Last week I was under the impression that Mike was working with Phil = to come up with a profile of Connect that basically takes a subset of = the basic client profile, and doesn't require changes to OAuth. >>=20 >> I was waiting to look at that revision before digging back into this. >>=20 >> That is likely still happening despite the confusion caused by this = thread. =20 >>=20 >> I am considering doing a ID showing how the Connect Basic profile can = be used to replace proprietary SSO connectors. >> That would include a reference to = http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as a = way to do do IdP initiated. >>=20 >> Basically the existing profile with a single IdP and client = credentials and reiterating the explanation from AOuth that scopes can = be implicit and consent can be granted out of band. >>=20 >> That would allow a SAML to Connect proxy as an example. >>=20 >> Having more than one input document may help the WG understand the = issues better. =20 >>=20 >> Interested in discussing it? > Definitely. Anybody else? >>=20 >> John B. >>=20 >>=20 >> On May 22, 2014, at 10:27 AM, Anil Saldhana = wrote:=20 >>=20 >>> John/Nat - would it be easy if you both can set up an OIDC profile = for this use case? >>>=20 >>> On 05/21/2014 08:20 PM, John Bradley wrote: >>>> Thanks Nat. I can't add anything to your response.=20 >>>>=20 >>>> Let's base our decision on adding authentication to OAuth 2 on = reality.=20 >>>>=20 >>>> Having a profile of Connect with most of the features Phil is = looking for should not be a hard thing. I don't personally think it is = required to have that happen in the OAuth WG.=20 >>>>=20 >>>>=20 >>>> John B >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On May 21, 2014, at 9:03 PM, Nat Sakimura = wrote: >>>>=20 >>>>> Phil, please do not misinform the working group.=20 >>>>>=20 >>>>> My responses inline:=20 >>>>>=20 >>>>>=20 >>>>> 2014-05-22 3:56 GMT+09:00 Phil Hunt : >>>>> Since several have voiced the opinion that the WG should not work = on providing user authentication context because OpenID Connect already = has a solution, I wanted to make clear how A4C is different from OpenID = Connect. >>>>>=20 >>>>> OpenID Connect supports providing clients an =93id_token=94 using = the id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid = Auth) of the OAuth Core. >>>>> http://openid.net/specs/openid-connect-core-1_0.html >>>>>=20 >>>>> The A4C draft that was put forward by Mike, Tony, and myself ( = draft-hunt-oauth-v2-user-a4c ) describes a flow similar to the code flow = of normal OAuth. Here are the differences from Connect: >>>>>=20 >>>>> Client Authentication >>>>> Connect does NOT authenticate the client prior to returning the id = token. The Connect flow is single step returning ID_TOKEN to an = unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.3 = appears only for the purpose of issuing an access token (user info = token). >>>>> The A4C flow is 2-step following the OAuth2 code flow. It requires = a code to be exchanged for ID_TOKEN after client authenticates in the = second step (exactly duplicating the normal OAuth flow). A4C requires = mutual authentication of clients and AS service providers. A4C has the = same logic and security properties of the normal OAuth authorization = flow. >>>>> This is not true.=20 >>>>>=20 >>>>> Connect for Code Flow for confidential client DOES authenticate = the client before getting an ID Token.=20 >>>>>=20 >>>>> Further, the Connect has an option of asymmetrically encrypting ID = Token with the public key of the client, which authenticates the client = even further.=20 >>>>> Even further, the Connect has an option of asymmetrically = encrypting the request with the public key of the server, which = authenticates the server in addition to TLS. =20 >>>>> User Authentication=20 >>>>> Both OpenID Connect and A4C return ID tokens which contain pretty = much the same information >>>>> A4C has additional features to allow clients to negotiate level of = authentication and authentication types (min LOA,ACR,AMR) in addition to = just returning ACR as in the case of OpenID. >>>>> What's the point of having both minimum LoA and AMR instead of = ACR? Connect can also return AMR.=20 >>>>> If you really wanted to have amr_values like feature, you can = actually request it by using Claims request as >>>>>=20 >>>>> { "id_token": {"amr": {"values": ["otp","rsa"] }}} >>>>> =20 >>>>> A4C only make re-auth lighter weight. No need to issue UserInfo = tokens again. Re-auth also re-authenticates the client as well as user. >>>>> I RFC6749 Section 5.1 REQUIRES an access token to be returned. = A4C is diverting from RFC6749. A4C is NOT OAuth anymore. The very reason = OpenID Connect returns an access token from the token endpoint always is = to adhere to RFC6749.=20 >>>>>=20 >>>>> OpenID Connect with scope=3Dopenid only is essentially the authN = only operation.=20 >>>>>=20 >>>>> Privacy Option >>>>> The A4C=92s authentication of the client makes it possible to = issue client-specific subject identifiers. This prevents multiple = clients from colluding to share information. >>>>> This is supported by OpenID Connect as well. =20 >>>>> Because Connect doesn=92t know who the client is, the subject = identifier returned is universal. >>>>> As stated above, this is false. It can even return PPID in the = case of public client as well.=20 >>>>> The spec could be used for pseudonymous authentication. >>>>> As state above, OpenID Connect supports this. It in fact advise = the use of PPID (Pairwise Psuedonymous Identifier in section 17.3).=20 >>>>> =20 >>>>>=20 >>>>> As you can see the specs are doing similar things, but they have = different security features. >>>>>=20 >>>>> As stated above, I do not see much. It has less option in general, = and added feature is the amr_values and min_alv, which I do not see much = value in it but if you really wanted, you can extend the Connect.=20 >>>>> =20 >>>>>=20 >>>>> As for need: >>>>> There are many sites using social network providers to = authenticate using 6749 only, there are ongoing security concerns that = many of us have blogged about. This may rise to the level of BUG on = 6749. >>>>> Why not just use OpenID Connect? =20 >>>>> Some social network providers have indicated a willingness to = support an authenticate only feature. I also had an inquiry if A4C can = be supported in OAuth1 as well as OAuth2. Some of this may be coming = from a business decision to use a proprietary user profile API instead = (this is not Oracle=92s position). >>>>> Authen only is fine with OpenID Connect. You can also use = proprietary or whatever the user profile API "in addition". For the = purpose of interoperability, it is better to have a standard user = profile API though, and that's why Connect defines a very basic one for = this purpose. =20 >>>>> There is a consent problem because normal 6749 use requires users = to consent to sharing information. Client developers in many cases would = like an authen only profile where consent is implicit. >>>>> That's an implementation issue. RFC 6749 does not require the = users to provide explicit consent.=20 >>>>> It just states:=20 >>>>>=20 >>>>> the authorization server authenticates the resource owner and = obtains >>>>> an authorization decision (by asking the resource owner or by=20= >>>>> establishing approval via other means).=20 >>>>>=20 >>>>> It can be implicit.=20 >>>>> Developers have been indicating that defining new user-id/pwds = and additionally sharing of profile information both cut back on the = %age success of new user registrations. Many want to offer an = authenticate only option for their users where the users explicitly = decide what to supply in their profile. Pseudonymous authen is a basic = feature. >>>>> This is supported by OpenID Connect as I stated above. =20 >>>>> I see other areas (e.g. Kitten) where authentication and = re-authentication may be of interest to other IETF groups. >>>>> There may be much broader requirements in the IETF community that = are not of interest to OpenID Connect and its objectives >>>>>=20 >>>>>=20 >>>>> Why not?=20 >>>>> =20 >>>>> While it is reasonable to make A4C and Connect as compatible as = possible, I am not sure they can be compatible. A4C and Connect are two = different flows solving different use cases with different security = characteristics. >>>>>=20 >>>>> Why not? I do not see it. You are essentially reading OpenID = Connect wrong.=20 >>>>> =20 >>>>>=20 >>>>> Note: I do not believe that the A4C draft is ready for last = call-it is intended only as input to the WG process. The features and = aspects like how the flow is initiated need to be discussed within the = wider IETF community where broad consensus can be obtained. This is why = I feel having it a work group milestone is important and I am willing to = contribute my time towards it. >>>>>=20 >>>>> Since it adds essentially nothing and produces wait-and-see among = the implementers, I think accepting this work as an work group item is = actively harmful for the internet. If something is needed to worked on = in the work group, I would rather want to see a profile of OpenID = Connect referencing it. That causes much less confusion.=20 >>>>> =20 >>>>>=20 >>>>> Because of the ongoing issue of inappropriate use of 6749 and the = broader requirements within the IETF, I feel this work needs to be = discussed within the IETF WG.=20 >>>>>=20 >>>>> Phil >>>>>=20 >>> =20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --Apple-Mail=_A2D61D08-B921-4A59-B4FA-966046B2224D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I was = thinking of asking Brian Campbell as long as he doesn't let it go to his = head.

I expect Layer7 and others might also have an = interest in such a thing.

John = B.

On May 22, 2014, at 10:59 AM, Anil Saldhana = <Anil.Saldhana@redhat.com> = wrote:

=20 =20
On 05/22/2014 09:49 AM, John Bradley wrote:
Last week I was under the impression that Mike was working with Phil to come up with a profile of Connect that basically takes a subset of the basic client profile, and doesn't require changes to OAuth.

I was waiting to look at that revision before digging back into this.

That is likely still happening despite the confusion caused by this thread.   

I am considering doing a ID showing how the Connect Basic profile can be used to replace proprietary SSO connectors.
That would include a reference to = http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as a way to do do IdP initiated.

Basically the existing profile with a single IdP and client credentials and reiterating the explanation from AOuth that scopes can be implicit and consent can be granted out of = band.

That would allow a SAML to Connect proxy as an example.

Having more than one input document may help the WG understand the issues better.  

Interested in discussing it?
Definitely.  Anybody else?

John B.


On May 22, 2014, at 10:27 AM, Anil Saldhana <Anil.Saldhana@redhat.com> wrote: 

John/Nat - would it be = easy if you both can set up an OIDC profile for this use case?

On 05/21/2014 08:20 PM, John Bradley wrote:
Thanks Nat. I can't add anything to your response. 

Let's base our decision on adding authentication to OAuth 2 on reality. 

Having a profile of Connect with most of the features Phil is looking for should not be a hard thing.   I don't personally think it is = required to have that happen in the OAuth WG. 


John B

Sent from my iPhone

On May 21, 2014, at 9:03 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Phil, please do not misinform the working group. 

My responses inline: 


2014-05-22 3:56 GMT+09:00 Phil Hunt <phil.hunt@oracle.com>:
Since several have voiced the opinion that the WG should not work on providing user authentication context because OpenID Connect already has a solution, I wanted to make clear how A4C is different from OpenID Connect.

OpenID Connect supports providing clients an =93id_token=94 using the id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid Auth) of the OAuth Core.

The A4C draft that was put forward by Mike, Tony, and myself ( draft-hunt-oauth-v2-user-a4c ) describes a flow similar to the code flow of normal OAuth. Here are the differences from Connect:

  • Client Authentication
    • Connect does NOT authenticate the client prior to returning the id token. The Connect flow is single step returning ID_TOKEN to an unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.3 appears only for the purpose of issuing an access token (user info = token).
    • The A4C flow is 2-step following the OAuth2 code flow. It requires a code to be exchanged for ID_TOKEN after client authenticates in the second step (exactly duplicating the normal OAuth flow). =  A4C requires mutual authentication of clients and AS service providers. A4C has the same logic and security properties of the normal OAuth authorization flow.
This is not = true. 

Connect for Code Flow for confidential client DOES authenticate the client before getting an ID Token. 

Further, the Connect has an option of asymmetrically encrypting ID Token with the public key of the client, which authenticates the client even further. 
Even further, the Connect has an option of asymmetrically encrypting the request with the public key of the server, which authenticates the server in addition to TLS.  
  • User Authentication 
    • Both OpenID Connect and A4C return ID tokens which contain pretty much the same = information
    • A4C has additional features to allow clients to negotiate level of authentication and authentication types (min LOA,ACR,AMR) in addition to just returning ACR as in the case of OpenID.
What's the point of having both minimum LoA and AMR instead of ACR?  Connect = can also return AMR. 
If you really wanted to have amr_values like feature, you can actually request it by using Claims request as

{ "id_token": {"amr": {"values": ["otp","rsa"] = }}}
 
    • A4C only make re-auth lighter weight. No need to issue UserInfo tokens again. Re-auth also re-authenticates the client as well as user.
 I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C is diverting from RFC6749. A4C is NOT OAuth anymore. The very reason OpenID Connect returns an access token from the token endpoint always is to adhere to = RFC6749. 

OpenID Connect with scope=3Dopenid only is essentially the authN only = operation. 

  • Privacy Option
    • The A4C=92s authentication of the client makes it possible to issue client-specific subject identifiers. This prevents multiple clients from colluding to share information.
This is supported by OpenID Connect as well.  
    • Because Connect doesn=92t know who the client is, the subject identifier returned is universal.
As stated above, this is false. It can even return PPID in the case of public client as well. 
    • The spec could be used for pseudonymous = authentication.
As state above, OpenID Connect supports this. It in fact advise the use of PPID (Pairwise Psuedonymous Identifier in section 17.3). 
 

As you can see the specs are doing similar things, but they have different security features.

As stated above, I do not see much. It has less option in general, and added feature is the amr_values and min_alv, which I do not see much value in it but if you really wanted, you can extend the Connect. 
 

As for need:
  • There are many sites using social network providers to authenticate using 6749 only, there are ongoing security concerns that many of us have blogged about. This may rise to the level of BUG on = 6749.
Why not just use OpenID Connect? =  
  • Some social network providers have indicated a willingness to support an authenticate only feature. I also had an inquiry if A4C can be supported in OAuth1 as well as OAuth2. Some of this may be coming from a business decision to use a proprietary user profile API instead (this is not Oracle=92s position).
Authen only is fine with OpenID Connect. You can also use proprietary or whatever the user profile API "in addition". For the purpose of interoperability, it is better to have a standard user profile API though, and that's why Connect defines a very basic one for this purpose.  
  • There is a consent problem because normal 6749 use requires users to consent to sharing information. Client developers in many cases would like an authen only profile where consent is implicit.
That's an implementation issue. RFC 6749 does not require the users to provide explicit consent. 
It just states: 

 the authorization server authenticates the resource owner and obtains
   an authorization decision (by =
asking the resource owner or by 
   establishing approval via other = means). 

It can be implicit. 
  • Developers have been indicating that defining new user-id/pwds  and additionally sharing of profile information both cut back on the %age success of new user registrations. Many want to offer an authenticate only option for their users where the users explicitly decide what to supply in their profile. =  Pseudonymous authen is a basic feature.
This is supported by OpenID Connect as I stated above.  
  • I see other areas (e.g. Kitten) where authentication and re-authentication may be of interest to other IETF = groups.
    • There may be much broader requirements in the IETF community that are not of interest to OpenID Connect and its objectives


Why not? 
 
While it is reasonable to make A4C and Connect as compatible as possible, I am not sure they can be compatible. A4C and Connect are two different flows solving different use cases with different security = characteristics.

Why not? I do not see it. You are essentially reading OpenID Connect = wrong. 
 

Note: I do not believe that the A4C draft is ready for last call-it is intended only as input to the WG process. The features and aspects like how the flow is initiated need to be discussed within the wider IETF community where broad consensus can be obtained. This is why I feel having it a work group milestone is important and I am willing to contribute my time towards it.

Since it adds essentially nothing and produces wait-and-see among the implementers, I think accepting this work as an work group item is actively harmful for the internet. If something is needed to worked on in the work group, I would rather want to see a profile of OpenID Connect referencing it. That causes much less confusion. 
 

Because of the ongoing issue of inappropriate use of 6749 and the broader requirements within the IETF, I feel this work needs to be discussed within the IETF = WG. 

=
Phil

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



= --Apple-Mail=_A2D61D08-B921-4A59-B4FA-966046B2224D-- --Apple-Mail=_97BA8279-B6B8-475E-8BFB-00CE44D2EFE5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA1MjIxNTAyMTVaMCMGCSqGSIb3DQEJBDEWBBSH5jEx0MpucTsW2S4Cyykm tX6dDTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBKeaYVpwfSdPB7WQlMV2nbKQgB/AwSsgf9qipN4I4Xb756pNeQKxOn 0Y9i9V2OvrBdjmjfFBKtJJCfjhkM6VwBJC77YqMWYRQtXsTwKwcE//87qgGyiWsdJpy9EwEPrlbN YcVrE8yi1yjao/4t+CF4DXY5b7BZ4yDBbxGX2LM2SQTWJ9g7j2TgOOKYpH3ZmgObDE6Dd+lpWZjj t6y+B8TF1KmtbfRru50BrWLjoBZamerBOm1UqN0XmSFyz6PZ2xA0bmKkfMalOuj//4F3Uj3acoXm Tctnbbuv9YJcfeBcUmT2NUJ7GOy66P7vff0hGxVfx+hoE7bNp3rZ2DdzsHGpAAAAAAAA --Apple-Mail=_97BA8279-B6B8-475E-8BFB-00CE44D2EFE5-- From nobody Thu May 22 08:58:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41E81A01C8 for ; Thu, 22 May 2014 08:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.952 X-Spam-Level: X-Spam-Status: No, score=-6.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 UOFXPzo7t9LG for ; Thu, 22 May 2014 08:58:19 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id BABB31A01D9 for ; Thu, 22 May 2014 08:58:17 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4MFwFXd019439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 May 2014 11:58:16 -0400 Received: from localhost.localdomain (vpn-55-122.rdu2.redhat.com [10.10.55.122]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4MFwBsu005747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 22 May 2014 11:58:12 -0400 Message-ID: <537E1E93.1000704@redhat.com> Date: Thu, 22 May 2014 10:58:11 -0500 From: Anil Saldhana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John Bradley References: <75D99637-1802-4C1F-83BE-D62AD938F9F4@oracle.com> <537E094C.6040504@redhat.com> <871F561C-73FB-4783-AEEF-42A9BB68E22D@ve7jtb.com> <537E10CD.6090309@redhat.com> <18209701-C62F-4CAC-9D2D-E3B305D5ECEC@ve7jtb.com> In-Reply-To: <18209701-C62F-4CAC-9D2D-E3B305D5ECEC@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------000506050906000101070908" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/kO8JWSzXUR6JW4MywcPIh_s4yy0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Authen Milestone: Comparing current A4C proposal to OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 15:58:22 -0000 This is a multi-part message in MIME format. --------------000506050906000101070908 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 05/22/2014 10:02 AM, John Bradley wrote: > I was thinking of asking Brian Campbell as long as he doesn't let it > go to his head. Probably he needs Paul Madsen's blessings. :-) > > I expect Layer7 and others might also have an interest in such a thing. > I will have a couple of guys on our side lined up. > John B. > > On May 22, 2014, at 10:59 AM, Anil Saldhana > wrote: > >> On 05/22/2014 09:49 AM, John Bradley wrote: >>> Last week I was under the impression that Mike was working with Phil >>> to come up with a profile of Connect that basically takes a subset >>> of the basic client profile, and doesn't require changes to OAuth. >>> >>> I was waiting to look at that revision before digging back into this. >>> >>> That is likely still happening despite the confusion caused by this >>> thread. >>> >>> I am considering doing a ID showing how the Connect Basic profile >>> can be used to replace proprietary SSO connectors. >>> That would include a reference to >>> http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as >>> a way to do do IdP initiated. >>> >>> Basically the existing profile with a single IdP and client >>> credentials and reiterating the explanation from AOuth that scopes >>> can be implicit and consent can be granted out of band. >>> >>> That would allow a SAML to Connect proxy as an example. >>> >>> Having more than one input document may help the WG understand the >>> issues better. >>> >>> Interested in discussing it? >> Definitely. Anybody else? >>> >>> John B. >>> >>> >>> On May 22, 2014, at 10:27 AM, Anil Saldhana >>> > wrote: >>> >>>> John/Nat - would it be easy if you both can set up an OIDC profile >>>> for this use case? >>>> >>>> On 05/21/2014 08:20 PM, John Bradley wrote: >>>>> Thanks Nat. I can't add anything to your response. >>>>> >>>>> Let's base our decision on adding authentication to OAuth 2 on >>>>> reality. >>>>> >>>>> Having a profile of Connect with most of the features Phil is >>>>> looking for should not be a hard thing. I don't personally think >>>>> it is required to have that happen in the OAuth WG. >>>>> >>>>> >>>>> John B >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On May 21, 2014, at 9:03 PM, Nat Sakimura >>>> > wrote: >>>>> >>>>>> Phil, please do not misinform the working group. >>>>>> >>>>>> My responses inline: >>>>>> >>>>>> >>>>>> 2014-05-22 3:56 GMT+09:00 Phil Hunt >>>>> >: >>>>>> >>>>>> Since several have voiced the opinion that the WG should not >>>>>> work on providing user authentication context because OpenID >>>>>> Connect already has a solution, I wanted to make clear how >>>>>> A4C is different from OpenID Connect. >>>>>> >>>>>> OpenID Connect supports providing clients an “id_token” using >>>>>> the id_token response type in section 3.2 (ImplicitAuth) and >>>>>> 3.3 (Hybrid Auth) of the OAuth Core. >>>>>> http://openid.net/specs/openid-connect-core-1_0.html >>>>>> >>>>>> The A4C draft that was put forward by Mike, Tony, and myself >>>>>> ( draft-hunt-oauth-v2-user-a4c >>>>>> ) describes >>>>>> a flow similar to the code flow of normal OAuth. Here are the >>>>>> differences from Connect: >>>>>> >>>>>> * Client Authentication >>>>>> o Connect does NOT authenticate the client prior to >>>>>> returning the id token. The Connect flow is single >>>>>> step returning ID_TOKEN to an unauthenticated client >>>>>> in both 3.2 and 3.3. Use of code flow in 3.3 appears >>>>>> only for the purpose of issuing an access token (user >>>>>> info token). >>>>>> o The A4C flow is 2-step following the OAuth2 code >>>>>> flow. It requires a code to be exchanged for ID_TOKEN >>>>>> after client authenticates in the second step >>>>>> (exactly duplicating the normal OAuth flow). A4C >>>>>> requires mutual authentication of clients and AS >>>>>> service providers. A4C has the same logic and >>>>>> security properties of the normal OAuth authorization >>>>>> flow. >>>>>> >>>>>> This is not true. >>>>>> >>>>>> Connect for Code Flow for confidential client DOES authenticate >>>>>> the client before getting an ID Token. >>>>>> >>>>>> Further, the Connect has an option of asymmetrically encrypting >>>>>> ID Token with the public key of the client, which authenticates >>>>>> the client even further. >>>>>> Even further, the Connect has an option of asymmetrically >>>>>> encrypting the request with the public key of the server, which >>>>>> authenticates the server in addition to TLS. >>>>>> >>>>>> * User Authentication >>>>>> o Both OpenID Connect and A4C return ID tokens which >>>>>> contain pretty much the same information >>>>>> o A4C has additional features to allow clients to >>>>>> negotiate level of authentication and authentication >>>>>> types (min LOA,ACR,AMR) in addition to just returning >>>>>> ACR as in the case of OpenID. >>>>>> >>>>>> What's the point of having both minimum LoA and AMR instead of >>>>>> ACR? Connect can also return AMR. >>>>>> If you really wanted to have amr_values like feature, you can >>>>>> actually request it by using Claims request as >>>>>> >>>>>> { "id_token": {"amr": {"values": ["otp","rsa"] }}} >>>>>> >>>>>> o A4C only make re-auth lighter weight. No need to >>>>>> issue UserInfo tokens again. Re-auth also >>>>>> re-authenticates the client as well as user. >>>>>> >>>>>> I RFC6749 Section 5.1 REQUIRES an access token to be returned. >>>>>> A4C is diverting from RFC6749. A4C is NOT OAuth anymore. The very >>>>>> reason OpenID Connect returns an access token from the token >>>>>> endpoint always is to adhere to RFC6749. >>>>>> >>>>>> OpenID Connect with scope=openid only is essentially the authN >>>>>> only operation. >>>>>> >>>>>> * Privacy Option >>>>>> o The A4C’s authentication of the client makes it >>>>>> possible to issue client-specific subject >>>>>> identifiers. This prevents multiple clients from >>>>>> colluding to share information. >>>>>> >>>>>> This is supported by OpenID Connect as well. >>>>>> >>>>>> o Because Connect doesn’t know who the client is, the >>>>>> subject identifier returned is universal. >>>>>> >>>>>> As stated above, this is false. It can even return PPID in the >>>>>> case of public client as well. >>>>>> >>>>>> o The spec could be used for pseudonymous authentication. >>>>>> >>>>>> As state above, OpenID Connect supports this. It in fact advise >>>>>> the use of PPID (Pairwise Psuedonymous Identifier in section 17.3). >>>>>> >>>>>> >>>>>> As you can see the specs are doing similar things, but they >>>>>> have different security features. >>>>>> >>>>>> >>>>>> As stated above, I do not see much. It has less option in >>>>>> general, and added feature is the amr_values and min_alv, which I >>>>>> do not see much value in it but if you really wanted, you can >>>>>> extend the Connect. >>>>>> >>>>>> >>>>>> As for need: >>>>>> >>>>>> * There are many sites using social network providers to >>>>>> authenticate using 6749 only, there are ongoing security >>>>>> concerns that many of us have blogged about. *This may >>>>>> rise to the level of BUG on 6749.* >>>>>> >>>>>> Why not just use OpenID Connect? >>>>>> >>>>>> * Some social network providers have indicated a >>>>>> willingness to support an authenticate only feature. I >>>>>> also had an inquiry if A4C can be supported in OAuth1 as >>>>>> well as OAuth2. Some of this may be coming from a >>>>>> business decision to use a proprietary user profile API >>>>>> instead (this is not Oracle’s position). >>>>>> >>>>>> Authen only is fine with OpenID Connect. You can also use >>>>>> proprietary or whatever the user profile API "in addition". For >>>>>> the purpose of interoperability, it is better to have a standard >>>>>> user profile API though, and that's why Connect defines a very >>>>>> basic one for this purpose. >>>>>> >>>>>> * There is a consent problem because normal 6749 use >>>>>> requires users to consent to sharing information. Client >>>>>> developers in many cases would like an authen only >>>>>> profile where consent is implicit. >>>>>> >>>>>> That's an implementation issue. RFC 6749 does not require the >>>>>> users to provide explicit consent. >>>>>> It just states: >>>>>> >>>>>> the authorization server authenticates the resource owner and obtains >>>>>> an authorization decision (by asking the resource owner or by >>>>>> establishing approval via other means). >>>>>> >>>>>> It can be implicit. >>>>>> >>>>>> * Developers have been indicating that defining new >>>>>> user-id/pwds and additionally sharing of profile >>>>>> information both cut back on the %age success of new user >>>>>> registrations. Many want to offer an authenticate only >>>>>> option for their users where the users explicitly decide >>>>>> what to supply in their profile. Pseudonymous authen is >>>>>> a basic feature. >>>>>> >>>>>> This is supported by OpenID Connect as I stated above. >>>>>> >>>>>> * I see other areas (e.g. Kitten) where authentication and >>>>>> re-authentication may be of interest to other IETF groups. >>>>>> o There may be much broader requirements in the IETF >>>>>> community that are not of interest to OpenID Connect >>>>>> and its objectives >>>>>> >>>>>> >>>>>> >>>>>> Why not? >>>>>> >>>>>> While it is reasonable to make A4C and Connect as compatible >>>>>> as possible, I am not sure they can be compatible. A4C and >>>>>> Connect are two different flows solving different use cases >>>>>> with different security characteristics. >>>>>> >>>>>> >>>>>> Why not? I do not see it. You are essentially reading OpenID >>>>>> Connect wrong. >>>>>> >>>>>> >>>>>> Note: I do not believe that the A4C draft is ready for last >>>>>> call-it is intended only as input to the WG process. The >>>>>> features and aspects like how the flow is initiated need to >>>>>> be discussed within the wider IETF community where broad >>>>>> consensus can be obtained. This is why I feel having it a >>>>>> work group milestone is important and I am willing to >>>>>> contribute my time towards it. >>>>>> >>>>>> >>>>>> Since it adds essentially nothing and produces wait-and-see among >>>>>> the implementers, I think accepting this work as an work group >>>>>> item is actively harmful for the internet. If something is needed >>>>>> to worked on in the work group, I would rather want to see a >>>>>> profile of OpenID Connect referencing it. That causes much less >>>>>> confusion. >>>>>> >>>>>> >>>>>> Because of the ongoing issue of inappropriate use of 6749 and >>>>>> the broader requirements within the IETF, I feel this work >>>>>> needs to be discussed within the IETF WG. >>>>>> >>>>>> Phil >>>>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > --------------000506050906000101070908 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 05/22/2014 10:02 AM, John Bradley wrote:
I was thinking of asking Brian Campbell as long as he doesn't let it go to his head.
Probably he needs Paul Madsen's blessings. :-)

I expect Layer7 and others might also have an interest in such a thing.

I will have a couple of guys on our side lined up.

John B.

On May 22, 2014, at 10:59 AM, Anil Saldhana <Anil.Saldhana@redhat.com> wrote:

On 05/22/2014 09:49 AM, John Bradley wrote:
Last week I was under the impression that Mike was working with Phil to come up with a profile of Connect that basically takes a subset of the basic client profile, and doesn't require changes to OAuth.

I was waiting to look at that revision before digging back into this.

That is likely still happening despite the confusion caused by this thread.   

I am considering doing a ID showing how the Connect Basic profile can be used to replace proprietary SSO connectors.
That would include a reference to http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as a way to do do IdP initiated.

Basically the existing profile with a single IdP and client credentials and reiterating the explanation from AOuth that scopes can be implicit and consent can be granted out of band.

That would allow a SAML to Connect proxy as an example.

Having more than one input document may help the WG understand the issues better.  

Interested in discussing it?
Definitely.  Anybody else?

John B.


On May 22, 2014, at 10:27 AM, Anil Saldhana <Anil.Saldhana@redhat.com> wrote: 

John/Nat - would it be easy if you both can set up an OIDC profile for this use case?

On 05/21/2014 08:20 PM, John Bradley wrote:
Thanks Nat. I can't add anything to your response. 

Let's base our decision on adding authentication to OAuth 2 on reality. 

Having a profile of Connect with most of the features Phil is looking for should not be a hard thing.   I don't personally think it is required to have that happen in the OAuth WG. 


John B

Sent from my iPhone

On May 21, 2014, at 9:03 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Phil, please do not misinform the working group. 

My responses inline: 


2014-05-22 3:56 GMT+09:00 Phil Hunt <phil.hunt@oracle.com>:
Since several have voiced the opinion that the WG should not work on providing user authentication context because OpenID Connect already has a solution, I wanted to make clear how A4C is different from OpenID Connect.

OpenID Connect supports providing clients an “id_token” using the id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid Auth) of the OAuth Core.

The A4C draft that was put forward by Mike, Tony, and myself ( draft-hunt-oauth-v2-user-a4c ) describes a flow similar to the code flow of normal OAuth. Here are the differences from Connect:

  • Client Authentication
    • Connect does NOT authenticate the client prior to returning the id token. The Connect flow is single step returning ID_TOKEN to an unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.3 appears only for the purpose of issuing an access token (user info token).
    • The A4C flow is 2-step following the OAuth2 code flow. It requires a code to be exchanged for ID_TOKEN after client authenticates in the second step (exactly duplicating the normal OAuth flow).  A4C requires mutual authentication of clients and AS service providers. A4C has the same logic and security properties of the normal OAuth authorization flow.
This is not true. 

Connect for Code Flow for confidential client DOES authenticate the client before getting an ID Token. 

Further, the Connect has an option of asymmetrically encrypting ID Token with the public key of the client, which authenticates the client even further. 
Even further, the Connect has an option of asymmetrically encrypting the request with the public key of the server, which authenticates the server in addition to TLS.  
  • User Authentication 
    • Both OpenID Connect and A4C return ID tokens which contain pretty much the same information
    • A4C has additional features to allow clients to negotiate level of authentication and authentication types (min LOA,ACR,AMR) in addition to just returning ACR as in the case of OpenID.
What's the point of having both minimum LoA and AMR instead of ACR?  Connect can also return AMR. 
If you really wanted to have amr_values like feature, you can actually request it by using Claims request as

{ "id_token": {"amr": {"values": ["otp","rsa"] }}}
 
    • A4C only make re-auth lighter weight. No need to issue UserInfo tokens again. Re-auth also re-authenticates the client as well as user.
 I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C is diverting from RFC6749. A4C is NOT OAuth anymore. The very reason OpenID Connect returns an access token from the token endpoint always is to adhere to RFC6749. 

OpenID Connect with scope=openid only is essentially the authN only operation. 

  • Privacy Option
    • The A4C’s authentication of the client makes it possible to issue client-specific subject identifiers. This prevents multiple clients from colluding to share information.
This is supported by OpenID Connect as well.  
    • Because Connect doesn’t know who the client is, the subject identifier returned is universal.
As stated above, this is false. It can even return PPID in the case of public client as well. 
    • The spec could be used for pseudonymous authentication.
As state above, OpenID Connect supports this. It in fact advise the use of PPID (Pairwise Psuedonymous Identifier in section 17.3). 
 

As you can see the specs are doing similar things, but they have different security features.

As stated above, I do not see much. It has less option in general, and added feature is the amr_values and min_alv, which I do not see much value in it but if you really wanted, you can extend the Connect. 
 

As for need:
  • There are many sites using social network providers to authenticate using 6749 only, there are ongoing security concerns that many of us have blogged about. This may rise to the level of BUG on 6749.
Why not just use OpenID Connect?  
  • Some social network providers have indicated a willingness to support an authenticate only feature. I also had an inquiry if A4C can be supported in OAuth1 as well as OAuth2. Some of this may be coming from a business decision to use a proprietary user profile API instead (this is not Oracle’s position).
Authen only is fine with OpenID Connect. You can also use proprietary or whatever the user profile API "in addition". For the purpose of interoperability, it is better to have a standard user profile API though, and that's why Connect defines a very basic one for this purpose.  
  • There is a consent problem because normal 6749 use requires users to consent to sharing information. Client developers in many cases would like an authen only profile where consent is implicit.
That's an implementation issue. RFC 6749 does not require the users to provide explicit consent. 
It just states: 

 the authorization server authenticates the resource owner and obtains
   an authorization decision (by asking the resource owner or by 
   establishing approval via other means). 

It can be implicit. 
  • Developers have been indicating that defining new user-id/pwds  and additionally sharing of profile information both cut back on the %age success of new user registrations. Many want to offer an authenticate only option for their users where the users explicitly decide what to supply in their profile.  Pseudonymous authen is a basic feature.
This is supported by OpenID Connect as I stated above.  
  • I see other areas (e.g. Kitten) where authentication and re-authentication may be of interest to other IETF groups.
    • There may be much broader requirements in the IETF community that are not of interest to OpenID Connect and its objectives


Why not? 
 
While it is reasonable to make A4C and Connect as compatible as possible, I am not sure they can be compatible. A4C and Connect are two different flows solving different use cases with different security characteristics.

Why not? I do not see it. You are essentially reading OpenID Connect wrong. 
 

Note: I do not believe that the A4C draft is ready for last call-it is intended only as input to the WG process. The features and aspects like how the flow is initiated need to be discussed within the wider IETF community where broad consensus can be obtained. This is why I feel having it a work group milestone is important and I am willing to contribute my time towards it.

Since it adds essentially nothing and produces wait-and-see among the implementers, I think accepting this work as an work group item is actively harmful for the internet. If something is needed to worked on in the work group, I would rather want to see a profile of OpenID Connect referencing it. That causes much less confusion. 
 

Because of the ongoing issue of inappropriate use of 6749 and the broader requirements within the IETF, I feel this work needs to be discussed within the IETF WG. 

Phil

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




--------------000506050906000101070908-- From nobody Thu May 22 08:59:09 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2731A016D for ; Thu, 22 May 2014 08:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 oxr1xyieg1SQ for ; Thu, 22 May 2014 08:59:08 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A931A01DC for ; Thu, 22 May 2014 08:59:08 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id hy4so4590374vcb.25 for ; Thu, 22 May 2014 08:59:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bM2Gqg6SzerybBHDXfXRVm58SAuUX6JvERPvl95YVOc=; b=kP2oWKfJkNfBLrkM73h9+Evf1wfxcDzybfOD+ZcvsaJ0JdFu0oQN95Qy9vRMxSViRf o4+P7JAkbVOmWyA11Gn9LDi2eIe0wpzO+eybYdWZlE+mgHYfIc9YxWkQL8rLbaSovMOd A92bhlQnmZCHfPndUqwABXYjPMIVW19wesGsNB64mkCGHfnU4p6+785N/bH1wAVzieKB 3W4t57xRtpu1PGKfNC2VtYbHr2SA5pETVJuOXAqIxc52tDJ3wbwl9F74zEROWrtNuHu3 kWstT0ObqwOe+eu9N3JWyLUGJZ/1S8NvWePj1PHof22OAsT//AdVM7EohXgqtVuQ75ij Kc+A== X-Gm-Message-State: ALoCoQmPK6WGWZDvc7gsMByiazICt8AGY13NEuZzS6jg8gq5YBBw8VQhbrKClpb54NRaw8+JPB/j X-Received: by 10.52.110.195 with SMTP id ic3mr1493330vdb.53.1400774346141; Thu, 22 May 2014 08:59:06 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by mx.google.com with ESMTPSA id v5sm336722vdx.13.2014.05.22.08.59.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 08:59:05 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id hy4so4709724vcb.11 for ; Thu, 22 May 2014 08:59:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.220.98.143 with SMTP id q15mr2052252vcn.38.1400774345745; Thu, 22 May 2014 08:59:05 -0700 (PDT) Received: by 10.58.86.72 with HTTP; Thu, 22 May 2014 08:59:05 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 08:59:05 -0700 Message-ID: From: Aaron Parecki To: "Clippard,Drew" Content-Type: multipart/alternative; boundary=001a11c1da0649ee3004f9ff311c Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/hvqxAipjR0_G_zwDTYcdR8niAXU Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Broken Links to OAuth 1.0x Specs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 15:59:09 -0000 --001a11c1da0649ee3004f9ff311c Content-Type: text/plain; charset=UTF-8 I recently moved the site to a new server and this was a misconfiguration. It's fixed now, thanks! For future reference, you can suggest any edits to the website here: https://github.com/aaronpk/oauth.net ---- Aaron Parecki aaronparecki.com @aaronpk On Wed, May 21, 2014 at 1:45 PM, Clippard,Drew wrote: > I've noticed that the links to the OAuth 1.0x Specs, specifically [1, > 2], listed here [3] return a 403 not authorized. Is there someone on this > mailing list that could fix this? Or is there a better source to use to > access prior versions of the spec? > > Thanks, > Drew > > [1] http://oauth.net/core/1.0/ > [2] http://oauth.net/core/1.0a/ > [3] http://oauth.net/documentation/ > CONFIDENTIALITY NOTICE This message and any included attachments are from > Cerner Corporation and are intended only for the addressee. The information > contained in this message is confidential and may constitute inside or > non-public information under international, federal, or state securities > laws. Unauthorized forwarding, printing, copying, distribution, or use of > such information is strictly prohibited and may be unlawful. If you are not > the addressee, please promptly delete this message and notify the sender of > the delivery error by e-mail or you may call Cerner's corporate offices in > Kansas City, Missouri, U.S.A at (+1) (816)221-1024. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11c1da0649ee3004f9ff311c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I recently moved the site to a new server and this was a misconfiguration= . It's fixed now, thanks!

For fu= ture reference, you can suggest any edits to the website here:=C2=A0https://github.= com/aaronpk/oauth.net

----
Aaron Parecki



On Wed, May 21, 2014 at 1:45 PM, Clippar= d,Drew <DCLIPPARD@cerner.com> wrote:
I've noticed that the links to the OAuth 1.0x Specs, specifically = [1, 2], listed here [3] return a 403 not authorized. =C2=A0Is there someone= on this mailing list that could fix this? =C2=A0Or is there a better sourc= e to use to access prior versions of the spec?

Thanks,
Drew

CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in K= ansas City, Missouri, U.S.A at (+1) (816)221-1024.

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


--001a11c1da0649ee3004f9ff311c-- From nobody Thu May 22 09:07:54 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997E71A0049 for ; Thu, 22 May 2014 09:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 iUWiiRbtg3sT for ; Thu, 22 May 2014 09:07:43 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0491A011F for ; Thu, 22 May 2014 09:07:42 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id f51so5950623qge.26 for ; Thu, 22 May 2014 09:07:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=lDliS1P6uqh2caWByEorMFbp6R6Ybhjec2PCl9HxN8o=; b=b/9+13/M5ZTuCcLvH+14BYFqUDdoqjVV9AJpkVYOZVoSciFXi92pyyJdGFyO8LY+OB ewzbNJvXOOAn+iIArVmP9seAe+BPz4KycCHGBb0z6Jl8dGQbERCMkGpKgqrNoAiaA2fI gDpXzTxtYzrGhp/bMTsisdKeleYmCmNDyXys2IvHg1QWo7C8cry9rBYRgIP41PEWOZWH FPH6X8SF8oeYyqD9jxEe2DEyUGJexxE9GKuCR6FGXxFeDWbZ4+0ex6V4cRgeW1TN0JEJ DC/PFGRoMfUuWAMjCgN12Opy5gJuBaBzcqaPR1pyMV4Py4HNfhXgS6Khh/Jgwmgry5ds q+Eg== X-Gm-Message-State: ALoCoQnkkcCUTB38Ep0IojmMDrtl758+bZXxwJ6davoWrQOMW1/ofQoB7WdnpbJyARuzTaIc9nUW X-Received: by 10.224.114.81 with SMTP id d17mr79842377qaq.33.1400774860749; Thu, 22 May 2014 09:07:40 -0700 (PDT) Received: from [10.2.2.165] (PING-IDENTI.bar1.Boston1.Level3.net. [4.31.154.18]) by mx.google.com with ESMTPSA id b5sm146376qge.17.2014.05.22.09.07.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 09:07:39 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_804CE8BE-0EDC-4BB3-B49D-37E821268E3A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Bradley In-Reply-To: <537E1E93.1000704@redhat.com> Date: Thu, 22 May 2014 12:07:38 -0400 Message-Id: <7F8AF2EC-FCB6-4684-8DB0-64CBD97472CA@ve7jtb.com> References: <75D99637-1802-4C1F-83BE-D62AD938F9F4@oracle.com> <537E094C.6040504@redhat.com> <871F561C-73FB-4783-AEEF-42A9BB68E22D@ve7jtb.com> <537E10CD.6090309@redhat.com> <18209701-C62F-4CAC-9D2D-E3B305D5ECEC@ve7jtb.com> <537E1E93.1000704@redhat.com> To: Anil Saldhana X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/7sQP7_jkr3WxtHgZVpNLczMAQIg Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Authen Milestone: Comparing current A4C proposal to OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 16:07:45 -0000 --Apple-Mail=_804CE8BE-0EDC-4BB3-B49D-37E821268E3A Content-Type: multipart/alternative; boundary="Apple-Mail=_51161030-FAA4-4199-A6DF-3E4B0011797F" --Apple-Mail=_51161030-FAA4-4199-A6DF-3E4B0011797F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I posted a update to = http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-01=20 Hans has also updated the Connect Apache module with a first cut of = support as a reference https://github.com/pingidentity/mod_auth_openidc. As it turns out the additional code was shorter than the spec. John B. On May 22, 2014, at 11:58 AM, Anil Saldhana = wrote: > On 05/22/2014 10:02 AM, John Bradley wrote: >> I was thinking of asking Brian Campbell as long as he doesn't let it = go to his head. > Probably he needs Paul Madsen's blessings. :-) >>=20 >> I expect Layer7 and others might also have an interest in such a = thing. >>=20 > I will have a couple of guys on our side lined up. >=20 >> John B. >>=20 >> On May 22, 2014, at 10:59 AM, Anil Saldhana = wrote: >>=20 >>> On 05/22/2014 09:49 AM, John Bradley wrote: >>>> Last week I was under the impression that Mike was working with = Phil to come up with a profile of Connect that basically takes a subset = of the basic client profile, and doesn't require changes to OAuth. >>>>=20 >>>> I was waiting to look at that revision before digging back into = this. >>>>=20 >>>> That is likely still happening despite the confusion caused by this = thread. =20 >>>>=20 >>>> I am considering doing a ID showing how the Connect Basic profile = can be used to replace proprietary SSO connectors. >>>> That would include a reference to = http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as a = way to do do IdP initiated. >>>>=20 >>>> Basically the existing profile with a single IdP and client = credentials and reiterating the explanation from AOuth that scopes can = be implicit and consent can be granted out of band. >>>>=20 >>>> That would allow a SAML to Connect proxy as an example. >>>>=20 >>>> Having more than one input document may help the WG understand the = issues better. =20 >>>>=20 >>>> Interested in discussing it? >>> Definitely. Anybody else? >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>> On May 22, 2014, at 10:27 AM, Anil Saldhana = wrote:=20 >>>>=20 >>>>> John/Nat - would it be easy if you both can set up an OIDC profile = for this use case? >>>>>=20 >>>>> On 05/21/2014 08:20 PM, John Bradley wrote: >>>>>> Thanks Nat. I can't add anything to your response.=20 >>>>>>=20 >>>>>> Let's base our decision on adding authentication to OAuth 2 on = reality.=20 >>>>>>=20 >>>>>> Having a profile of Connect with most of the features Phil is = looking for should not be a hard thing. I don't personally think it is = required to have that happen in the OAuth WG.=20 >>>>>>=20 >>>>>>=20 >>>>>> John B >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>> On May 21, 2014, at 9:03 PM, Nat Sakimura = wrote: >>>>>>=20 >>>>>>> Phil, please do not misinform the working group.=20 >>>>>>>=20 >>>>>>> My responses inline:=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> 2014-05-22 3:56 GMT+09:00 Phil Hunt : >>>>>>> Since several have voiced the opinion that the WG should not = work on providing user authentication context because OpenID Connect = already has a solution, I wanted to make clear how A4C is different from = OpenID Connect. >>>>>>>=20 >>>>>>> OpenID Connect supports providing clients an =93id_token=94 = using the id_token response type in section 3.2 (ImplicitAuth) and 3.3 = (Hybrid Auth) of the OAuth Core. >>>>>>> http://openid.net/specs/openid-connect-core-1_0.html >>>>>>>=20 >>>>>>> The A4C draft that was put forward by Mike, Tony, and myself ( = draft-hunt-oauth-v2-user-a4c ) describes a flow similar to the code flow = of normal OAuth. Here are the differences from Connect: >>>>>>>=20 >>>>>>> Client Authentication >>>>>>> Connect does NOT authenticate the client prior to returning the = id token. The Connect flow is single step returning ID_TOKEN to an = unauthenticated client in both 3.2 and = 3.3. Use of code flow in 3.3 appears only for the = purpose of issuing an access token (user info token). >>>>>>> The A4C flow is 2-step following the OAuth2 code flow. It = requires a code to be exchanged for ID_TOKEN after client authenticates = in the second step (exactly duplicating the normal OAuth flow). A4C = requires mutual authentication of clients and AS service providers. A4C = has the same logic and security properties of the normal OAuth = authorization flow. >>>>>>> This is not true.=20 >>>>>>>=20 >>>>>>> Connect for Code Flow for confidential client DOES authenticate = the client before getting an ID Token.=20 >>>>>>>=20 >>>>>>> Further, the Connect has an option of asymmetrically encrypting = ID Token with the public key of the client, which authenticates the = client even further.=20 >>>>>>> Even further, the Connect has an option of asymmetrically = encrypting the request with the public key of the server, which = authenticates the server in addition to TLS. =20 >>>>>>> User Authentication=20 >>>>>>> Both OpenID Connect and A4C return ID tokens which contain = pretty much the same information >>>>>>> A4C has additional features to allow clients to negotiate level = of authentication and authentication types (min LOA,ACR,AMR) in addition = to just returning ACR as in the case of OpenID. >>>>>>> What's the point of having both minimum LoA and AMR instead of = ACR? Connect can also return AMR.=20 >>>>>>> If you really wanted to have amr_values like feature, you can = actually request it by using Claims request as >>>>>>>=20 >>>>>>> { "id_token": {"amr": {"values": ["otp","rsa"] }}} >>>>>>> =20 >>>>>>> A4C only make re-auth lighter weight. No need to issue UserInfo = tokens again. Re-auth also re-authenticates the client as well as user. >>>>>>> I RFC6749 Section 5.1 REQUIRES an access token to be returned. = A4C is diverting from RFC6749. A4C is NOT OAuth anymore. The very reason = OpenID Connect returns an access token from the token endpoint always is = to adhere to RFC6749.=20 >>>>>>>=20 >>>>>>> OpenID Connect with scope=3Dopenid only is essentially the authN = only operation.=20 >>>>>>>=20 >>>>>>> Privacy Option >>>>>>> The A4C=92s authentication of the client makes it possible to = issue client-specific subject identifiers. This prevents multiple = clients from colluding to share information. >>>>>>> This is supported by OpenID Connect as well. =20 >>>>>>> Because Connect doesn=92t know who the client is, the subject = identifier returned is universal. >>>>>>> As stated above, this is false. It can even return PPID in the = case of public client as well.=20 >>>>>>> The spec could be used for pseudonymous authentication. >>>>>>> As state above, OpenID Connect supports this. It in fact advise = the use of PPID (Pairwise Psuedonymous Identifier in section 17.3).=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> As you can see the specs are doing similar things, but they have = different security features. >>>>>>>=20 >>>>>>> As stated above, I do not see much. It has less option in = general, and added feature is the amr_values and min_alv, which I do not = see much value in it but if you really wanted, you can extend the = Connect.=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> As for need: >>>>>>> There are many sites using social network providers to = authenticate using 6749 only, there are ongoing security concerns that = many of us have blogged about. This may rise to the level of BUG on = 6749. >>>>>>> Why not just use OpenID Connect? =20 >>>>>>> Some social network providers have indicated a willingness to = support an authenticate only feature. I also had an inquiry if A4C can = be supported in OAuth1 as well as OAuth2. Some of this may be coming = from a business decision to use a proprietary user profile API instead = (this is not Oracle=92s position). >>>>>>> Authen only is fine with OpenID Connect. You can also use = proprietary or whatever the user profile API "in addition". For the = purpose of interoperability, it is better to have a standard user = profile API though, and that's why Connect defines a very basic one for = this purpose. =20 >>>>>>> There is a consent problem because normal 6749 use requires = users to consent to sharing information. Client developers in many cases = would like an authen only profile where consent is implicit. >>>>>>> That's an implementation issue. RFC 6749 does not require the = users to provide explicit consent.=20 >>>>>>> It just states:=20 >>>>>>>=20 >>>>>>> the authorization server authenticates the resource owner and = obtains >>>>>>> an authorization decision (by asking the resource owner or by=20= >>>>>>> establishing approval via other means).=20 >>>>>>>=20 >>>>>>> It can be implicit.=20 >>>>>>> Developers have been indicating that defining new user-id/pwds = and additionally sharing of profile information both cut back on the = %age success of new user registrations. Many want to offer an = authenticate only option for their users where the users explicitly = decide what to supply in their profile. Pseudonymous authen is a basic = feature. >>>>>>> This is supported by OpenID Connect as I stated above. =20 >>>>>>> I see other areas (e.g. Kitten) where authentication and = re-authentication may be of interest to other IETF groups. >>>>>>> There may be much broader requirements in the IETF community = that are not of interest to OpenID Connect and its objectives >>>>>>>=20 >>>>>>>=20 >>>>>>> Why not?=20 >>>>>>> =20 >>>>>>> While it is reasonable to make A4C and Connect as compatible as = possible, I am not sure they can be compatible. A4C and Connect are two = different flows solving different use cases with different security = characteristics. >>>>>>>=20 >>>>>>> Why not? I do not see it. You are essentially reading OpenID = Connect wrong.=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> Note: I do not believe that the A4C draft is ready for last = call-it is intended only as input to the WG process. The features and = aspects like how the flow is initiated need to be discussed within the = wider IETF community where broad consensus can be obtained. This is why = I feel having it a work group milestone is important and I am willing to = contribute my time towards it. >>>>>>>=20 >>>>>>> Since it adds essentially nothing and produces wait-and-see = among the implementers, I think accepting this work as an work group = item is actively harmful for the internet. If something is needed to = worked on in the work group, I would rather want to see a profile of = OpenID Connect referencing it. That causes much less confusion.=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> Because of the ongoing issue of inappropriate use of 6749 and = the broader requirements within the IETF, I feel this work needs to be = discussed within the IETF WG.=20 >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>> =20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_51161030-FAA4-4199-A6DF-3E4B0011797F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = posted a update to http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-01=  

Hans has also updated the Connect Apache = module with a first cut of support as a reference https://github.c= om/pingidentity/mod_auth_openidc.

As it = turns out the additional code was shorter than the = spec.

John B.

On May = 22, 2014, at 11:58 AM, Anil Saldhana <Anil.Saldhana@redhat.com> = wrote:

=20 =20
On 05/22/2014 10:02 AM, John Bradley wrote:
I was thinking of asking Brian Campbell as long as he doesn't let it go to his head.
Probably he needs Paul Madsen's blessings. :-)

I expect Layer7 and others might also have an interest in such a thing.

I will have a couple of guys on our side lined up.

John B.

On May 22, 2014, at 10:59 AM, Anil Saldhana <Anil.Saldhana@redhat.com> wrote:

On 05/22/2014 09:49 AM, = John Bradley wrote:
Last week I was under the impression that Mike was working with Phil to come up with a profile of Connect that basically takes a subset of the basic client profile, and doesn't require changes to OAuth.

I was waiting to look at that revision before digging back into this.

That is likely still happening despite the confusion caused by this thread.   

I am considering doing a ID showing how the Connect Basic profile can be used to replace proprietary SSO connectors.
That would include a reference to = http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as a way to do do IdP initiated.

Basically the existing profile with a single IdP and client credentials and reiterating the explanation from AOuth that scopes can be implicit and consent can be granted out of band.

That would allow a SAML to Connect proxy as an example.

Having more than one input document may help the WG understand the issues better.  

Interested in discussing it?
Definitely.  Anybody else?

John B.


On May 22, 2014, at 10:27 AM, Anil Saldhana <Anil.Saldhana@redhat.com> wrote: 

John/Nat - = would it be easy if you both can set up an OIDC profile for this use case?

On 05/21/2014 08:20 PM, John Bradley = wrote:
Thanks Nat. I can't add anything to your response. 

Let's base our decision on adding authentication to OAuth 2 on = reality. 

Having a profile of Connect with most of the features Phil is looking for should not be a hard thing.   I don't = personally think it is required to have that happen in the OAuth WG. 


John B

Sent from my iPhone

On May 21, 2014, at 9:03 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Phil, please do not misinform the working group. 

My responses inline: 


2014-05-22 3:56 GMT+09:00 Phil Hunt <phil.hunt@oracle.com>:
Since several have voiced the opinion that the WG should not work on providing user authentication context because OpenID Connect already has a solution, I wanted to make clear how A4C is different from OpenID Connect.

OpenID Connect supports providing clients an =93id_token=94 using the id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid Auth) of the OAuth Core.

The A4C draft that was put forward by Mike, Tony, and myself ( draft-hunt-oauth-v2-user-a4c ) describes a flow similar to the code flow of normal OAuth. Here are the differences from Connect:

  • Client = Authentication
    • Connect does NOT authenticate the client prior to returning the id token. The Connect flow is single step returning ID_TOKEN to an unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.3 appears only for the purpose of issuing an access token (user info token).
    • The A4C flow is 2-step following the OAuth2 code flow. It requires a code to be exchanged for ID_TOKEN after client authenticates in the second step (exactly duplicating the normal OAuth flow).  A4C requires mutual authentication of clients and AS service providers. A4C has the same logic and security properties of the normal OAuth authorization = flow.
This is not true. 

Connect for Code Flow for confidential client DOES authenticate the client before getting an ID Token. 

Further, the Connect has an option of asymmetrically encrypting ID Token with the public key of the client, which authenticates the client even further. 
Even further, the Connect has an option of asymmetrically encrypting the request with the public key of the server, which authenticates the server in addition to TLS.  
  • User = Authentication 
    • Both OpenID Connect and A4C return ID tokens which contain pretty much the same information
    • A4C has additional features to allow clients to negotiate level of authentication and authentication types (min LOA,ACR,AMR) in addition to just returning ACR as in the case of = OpenID.
What's the point of having both minimum LoA and AMR instead of ACR?  Connect can also = return AMR. 
If you really wanted to have amr_values like feature, you can actually request it by using Claims request as

{ = "id_token": {"amr": {"values": ["otp","rsa"] }}}
 
    • A4C only make re-auth lighter weight. No need to issue UserInfo tokens again. Re-auth also re-authenticates the client as well as user.
 I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C is diverting from RFC6749. A4C is NOT OAuth anymore. The very reason OpenID Connect returns an access token from the token endpoint always is to adhere to = RFC6749. 

OpenID Connect with scope=3Dopenid only is = essentially the authN only = operation. 

  • Privacy Option
    • The A4C=92s authentication of the client makes it possible to issue client-specific subject identifiers. This prevents multiple clients from colluding to share = information.
This is supported by OpenID Connect as well.  
    • Because Connect doesn=92t know who the client is, the subject identifier returned is universal.
As stated above, this is false. It can even return PPID in the case of public client as well. 
    • The spec could be used for pseudonymous authentication.
As state above, OpenID Connect supports this. It in fact advise the use of PPID (Pairwise Psuedonymous Identifier in section = 17.3). 
 

As you can see the specs are doing similar things, but they have different security features.

As stated above, I do not see much. It has less option in general, and added feature is the amr_values and min_alv, which I do not see much value in it but if you really wanted, you can extend the = Connect. 
 

As for need:
  • There are many sites using social network providers to authenticate using 6749 only, there are ongoing security concerns that many of us have blogged about. This may rise to the level of BUG on 6749.
Why not just use OpenID Connect?  
  • Some social network providers have indicated a willingness to support an authenticate only feature. I also had an inquiry if A4C can be supported in OAuth1 as well as OAuth2. Some of this may be coming from a business decision to use a proprietary user profile API instead (this is not Oracle=92s position).
Authen only is fine with OpenID Connect. You can also use proprietary or whatever the user profile API "in addition". For the purpose of interoperability, it is better to have a standard user profile API though, and that's why Connect defines a very basic one for this purpose.  
  • There is a consent problem because normal 6749 use requires users to consent to sharing information. Client developers in many cases would like an authen only profile where consent is = implicit.
That's an implementation issue. RFC 6749 does not require the users to provide explicit consent. 
It just states: 

 the authorization server authenticates the resource owner and obtains
   an authorization decision =
(by asking the resource owner or by 
   establishing approval = via other = means). 

It can be = implicit. 
  • Developers have been indicating that defining new user-id/pwds =  and additionally sharing of profile information both cut back on the %age success of new user registrations. Many want to offer an authenticate only option for their users where the users explicitly decide what to supply in their profile. =  Pseudonymous authen is a basic feature.
This is supported by OpenID Connect as I stated above. =  
  • I see other areas (e.g. Kitten) where authentication and re-authentication may be of interest to other IETF groups.
    • There may be much broader requirements in the IETF community that are not of interest to OpenID Connect and its objectives


Why not? 
 
While it is reasonable to make A4C and Connect as compatible as possible, I am not sure they can be compatible. A4C and Connect are two different flows solving different use cases with different security characteristics.

Why not? I do not see it. You are essentially reading OpenID Connect wrong. 
 

Note: I do not believe that the A4C draft is ready for last call-it is intended only as input to the WG process. The features and aspects like how the flow is initiated need to be discussed within the wider IETF community where broad consensus can be obtained. This is why I feel having it a work group milestone is important and I am willing to contribute my time towards it.

Since it adds essentially nothing and produces wait-and-see among the implementers, I think accepting this work as an work group item is actively harmful for the internet. If something is needed to worked on in the work group, I would rather want to see a profile of OpenID Connect referencing it. That causes much less confusion. 
 

Because of the ongoing issue of inappropriate use of 6749 and the broader requirements within the IETF, I feel this work needs to be discussed within the IETF = WG. 

=
Phil

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





= --Apple-Mail=_51161030-FAA4-4199-A6DF-3E4B0011797F-- --Apple-Mail=_804CE8BE-0EDC-4BB3-B49D-37E821268E3A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA1MjIxNjA3MzhaMCMGCSqGSIb3DQEJBDEWBBTNg3sizcA18JY9hxe0v4aI XeI4+TCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCmIS2ljxMbY9CMCND6DXGrklblOtROWGxfEzINieTVbMKfXNCyyeX2 Y+oD5eG3vf/yQw+BRxr5BHlTzGDpMKu+unLsdJOrHnUWCsYLAkFM464fXRuGdTngP3jpAVz1FdEg 5Jvq+rZ6qbjv8rYhtcNrLnor4P9VcDEHURf02rMi/gErOFytMxKksyupdl6wwQc7R92H2/bDwSWD jitsBZ8l0BJw4C8MKuvdOQlrCwTiGGT0TTv6TifM7IotcQf5EocHvo4vu3IpDhJDljzFI1HaKYFE KB5wkbftAvD+t2WYWlRYfTucq9yDPJ6H6br7t8VNsizMuxm76U2GlUGINbrVAAAAAAAA --Apple-Mail=_804CE8BE-0EDC-4BB3-B49D-37E821268E3A-- From nobody Fri May 23 12:51:20 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05FA1A0330 for ; Fri, 23 May 2014 12:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.978 X-Spam-Level: X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 nbeSBFrfxpq4 for ; Fri, 23 May 2014 12:51:13 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6AA1A0328 for ; Fri, 23 May 2014 12:51:12 -0700 (PDT) Received: from mail-ie0-f176.google.com ([209.85.223.176]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKU3+mrcGL4I3aHhoRK86d3MLBobZB2foc@postini.com; Fri, 23 May 2014 12:51:11 PDT Received: by mail-ie0-f176.google.com with SMTP id rl12so5560395iec.35 for ; Fri, 23 May 2014 12:51:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=l9BZJx5LPXYCykfhQO4bUp6eqFR/VNWkRuKXaxojdeg=; b=HDk5SR3TdFTMQa1H8suH/o8X5fKXZtf0vdCo6EJXPc2/Ega/sL0z8BGAr6p/7wEP6q ymFxjPtaX9ERcn0Wyri8ysrKkE5Bq9EIH6UcLUwr7p6jrUGQxmZdNwMvLN9Yrda7AfOm kDPOaNB9PE6ytTkOt9XxyoqRDeqKNer+kL29SHIBQYiuVJ+L+vz09t9OcM+FW15rPpm4 RRavNjF+eLNEN2fK7Vv5Seaj80jemaP7GfFNfzKk1tMhvACNdQJPtf0GA+kvtX/E5LTO yTLNVNTuO0b2+sjikHINhln75eLTk3vnEURZ6aX18BDeXuQ10MAWJs6tSghXmX4Hd8nS Zstg== X-Gm-Message-State: ALoCoQnaomBh68YxvvV97jhmSs3WKdJTPJMtFBfsw77KmZ7nlVC8u3VWys+w/h/Z91SUkbBHQVDDOOCimL9NSrMO3HfF7CeJ4nOpgTGyoiFUXMcO76K/UYV2weaiRopXUiqZx/STt859 X-Received: by 10.43.54.17 with SMTP id vs17mr6767807icb.30.1400874669257; Fri, 23 May 2014 12:51:09 -0700 (PDT) X-Received: by 10.43.54.17 with SMTP id vs17mr6767797icb.30.1400874669154; Fri, 23 May 2014 12:51:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.193 with HTTP; Fri, 23 May 2014 12:50:39 -0700 (PDT) In-Reply-To: <18209701-C62F-4CAC-9D2D-E3B305D5ECEC@ve7jtb.com> References: <75D99637-1802-4C1F-83BE-D62AD938F9F4@oracle.com> <537E094C.6040504@redhat.com> <871F561C-73FB-4783-AEEF-42A9BB68E22D@ve7jtb.com> <537E10CD.6090309@redhat.com> <18209701-C62F-4CAC-9D2D-E3B305D5ECEC@ve7jtb.com> From: Brian Campbell Date: Fri, 23 May 2014 13:50:39 -0600 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=bcaec51b1adf07ba3804fa168ddf Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/slkDuoMxYPUnz8TO_OZSeC1iSDg Cc: oauth Subject: Re: [OAUTH-WG] Authen Milestone: Comparing current A4C proposal to OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 19:51:17 -0000 --bcaec51b1adf07ba3804fa168ddf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Simply having you acknowledge my existence goes to my head, John. I'd be interested in discussing it for sure. I have some reservations and/or confusion regarding your approach but need to actually read the draft before I say anything more. Which I'll try and do at some point here before too long. On Thu, May 22, 2014 at 9:02 AM, John Bradley wrote: > I was thinking of asking Brian Campbell as long as he doesn't let it go t= o > his head. > > I expect Layer7 and others might also have an interest in such a thing. > > John B. > > On May 22, 2014, at 10:59 AM, Anil Saldhana > wrote: > > On 05/22/2014 09:49 AM, John Bradley wrote: > > Last week I was under the impression that Mike was working with Phil to > come up with a profile of Connect that basically takes a subset of the > basic client profile, and doesn't require changes to OAuth. > > I was waiting to look at that revision before digging back into this. > > That is likely still happening despite the confusion caused by this > thread. > > I am considering doing a ID showing how the Connect Basic profile can be > used to replace proprietary SSO connectors. > That would include a reference to > http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as a way > to do do IdP initiated. > > Basically the existing profile with a single IdP and client credentials > and reiterating the explanation from AOuth that scopes can be implicit an= d > consent can be granted out of band. > > That would allow a SAML to Connect proxy as an example. > > Having more than one input document may help the WG understand the > issues better. > > Interested in discussing it? > > Definitely. Anybody else? > > > John B. > > > On May 22, 2014, at 10:27 AM, Anil Saldhana > wrote: > > John/Nat - would it be easy if you both can set up an OIDC profile for > this use case? > > On 05/21/2014 08:20 PM, John Bradley wrote: > > Thanks Nat. I can't add anything to your response. > > Let's base our decision on adding authentication to OAuth 2 on reality. > > Having a profile of Connect with most of the features Phil is looking > for should not be a hard thing. I don't personally think it is required > to have that happen in the OAuth WG. > > > John B > > Sent from my iPhone > > On May 21, 2014, at 9:03 PM, Nat Sakimura wrote: > > Phil, please do not misinform the working group. > > My responses inline: > > > 2014-05-22 3:56 GMT+09:00 Phil Hunt : > >> Since several have voiced the opinion that the WG should not work on >> providing user authentication context because OpenID Connect already has= a >> solution, I wanted to make clear how A4C is different from OpenID Connec= t. >> >> OpenID Connect supports providing clients an =E2=80=9Cid_token=E2=80=9D= using the >> id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid Aut= h) >> of the OAuth Core. >> http://openid.net/specs/openid-connect-core-1_0.html >> >> The A4C draft that was put forward by Mike, Tony, and myself ( >> draft-hunt-oauth-v2-user-a4c ) describes >> a flow similar to the code flow of normal OAuth. Here are the difference= s >> from Connect: >> >> >> - Client Authentication >> - Connect does NOT authenticate the client prior to returning the >> id token. The Connect flow is single step returning ID_TOKEN to an >> unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.= 3 appears >> only for the purpose of issuing an access token (user info token). >> - The A4C flow is 2-step following the OAuth2 code flow. It >> requires a code to be exchanged for ID_TOKEN after client authenti= cates in >> the second step (exactly duplicating the normal OAuth flow). A4C = requires >> mutual authentication of clients and AS service providers. A4C has= the same >> logic and security properties of the normal OAuth authorization fl= ow. >> >> This is not true. > > Connect for Code Flow for confidential client DOES authenticate the > client before getting an ID Token. > > Further, the Connect has an option of asymmetrically encrypting ID Token > with the public key of the client, which authenticates the client even > further. > Even further, the Connect has an option of asymmetrically encrypting the > request with the public key of the server, which authenticates the server > in addition to TLS. > >> >> - User Authentication >> - Both OpenID Connect and A4C return ID tokens which contain >> pretty much the same information >> - A4C has additional features to allow clients to negotiate level of >> authentication and authentication types (min LOA,ACR,AMR) in addit= ion to >> just returning ACR as in the case of OpenID. >> >> What's the point of having both minimum LoA and AMR instead of ACR? > Connect can also return AMR. > If you really wanted to have amr_values like feature, you can actually > request it by using Claims request as > > { "id_token": {"amr": {"values": ["otp","rsa"] }}} > > >> >> - A4C only make re-auth lighter weight. No need to issue UserInfo >> tokens again. Re-auth also re-authenticates the client as well as = user. >> >> I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C is > diverting from RFC6749. A4C is NOT OAuth anymore. The very reason OpenID > Connect returns an access token from the token endpoint always is to adhe= re > to RFC6749. > > OpenID Connect with scope=3Dopenid only is essentially the authN only > operation. > > >> - Privacy Option >> - The A4C=E2=80=99s authentication of the client makes it possible= to >> issue client-specific subject identifiers. This prevents multiple = clients >> from colluding to share information. >> >> This is supported by OpenID Connect as well. > >> >> - Because Connect doesn=E2=80=99t know who the client is, the subjec= t >> identifier returned is universal. >> >> As stated above, this is false. It can even return PPID in the case of > public client as well. > >> >> - The spec could be used for pseudonymous authentication. >> >> As state above, OpenID Connect supports this. It in fact advise the > use of PPID (Pairwise Psuedonymous Identifier in section 17.3). > > >> >> As you can see the specs are doing similar things, but they have >> different security features. >> > > As stated above, I do not see much. It has less option in general, and > added feature is the amr_values and min_alv, which I do not see much valu= e > in it but if you really wanted, you can extend the Connect. > > >> >> As for need: >> >> - There are many sites using social network providers to authenticate >> using 6749 only, there are ongoing security concerns that many of us = have >> blogged about. *This may rise to the level of BUG on 6749.* >> >> Why not just use OpenID Connect? > >> >> - Some social network providers have indicated a willingness to >> support an authenticate only feature. I also had an inquiry if A4C ca= n be >> supported in OAuth1 as well as OAuth2. Some of this may be coming fro= m a >> business decision to use a proprietary user profile API instead (this= is >> not Oracle=E2=80=99s position). >> >> Authen only is fine with OpenID Connect. You can also use proprietary > or whatever the user profile API "in addition". For the purpose of > interoperability, it is better to have a standard user profile API though= , > and that's why Connect defines a very basic one for this purpose. > >> >> - There is a consent problem because normal 6749 use requires users >> to consent to sharing information. Client developers in many cases wo= uld >> like an authen only profile where consent is implicit. >> >> That's an implementation issue. RFC 6749 does not require the users to > provide explicit consent. > It just states: > > the authorization server authenticates the resource owner and obtains > > an authorization decision (by asking the resource owner or by > > establishing approval via other means). > > It can be implicit. > >> >> - Developers have been indicating that defining new user-id/pwds and >> additionally sharing of profile information both cut back on the %age >> success of new user registrations. Many want to offer an authenticate= only >> option for their users where the users explicitly decide what to supp= ly in >> their profile. Pseudonymous authen is a basic feature. >> >> This is supported by OpenID Connect as I stated above. > >> >> - I see other areas (e.g. Kitten) where authentication and >> re-authentication may be of interest to other IETF groups. >> - There may be much broader requirements in the IETF community >> that are not of interest to OpenID Connect and its objectives >> >> >> > Why not? > > >> While it is reasonable to make A4C and Connect as compatible as >> possible, I am not sure they can be compatible. A4C and Connect are two >> different flows solving different use cases with different security >> characteristics. >> > > Why not? I do not see it. You are essentially reading OpenID Connect > wrong. > > >> >> Note: I do not believe that the A4C draft is ready for last call-it is >> intended only as input to the WG process. The features and aspects like = how >> the flow is initiated need to be discussed within the wider IETF communi= ty >> where broad consensus can be obtained. This is why I feel having it a wo= rk >> group milestone is important and I am willing to contribute my time towa= rds >> it. >> > > Since it adds essentially nothing and produces wait-and-see among the > implementers, I think accepting this work as an work group item is active= ly > harmful for the internet. If something is needed to worked on in the work > group, I would rather want to see a profile of OpenID Connect referencing > it. That causes much less confusion. > > >> >> Because of the ongoing issue of inappropriate use of 6749 and the >> broader requirements within the IETF, I feel this work needs to be >> discussed within the IETF WG. >> >> Phil >> >> > _______________________________________________ > 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 > > --bcaec51b1adf07ba3804fa168ddf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Simply having you acknowledge my existence goes to my head= , John.

I'd be interested in discussing it for sure. I have some= reservations and/or confusion regarding your approach but need to actually= read the draft before I say anything more. Which I'll try and do at so= me point here before too long.


On Thu,= May 22, 2014 at 9:02 AM, John Bradley <ve7jtb@ve7jtb.com> w= rote:
I was th= inking of asking Brian Campbell as long as he doesn't let it go to his = head.

I expect Layer7 and others might also have an interest in su= ch a thing.

John B.

On May 22, 2014, at 10:59 AM, Anil Saldhana <Anil.Saldhana@redhat.co= m> wrote:

=20 =20 =20
On 05/22/2014 09:49 AM, John Bradley wrote:
=20 Last week I was under the impression that Mike was working with Phil to come up with a profile of Connect that basically takes a subset of the basic client profile, and doesn't require changes t= o OAuth.

I was waiting to look at that revision before digging back into this.

That is likely still happening despite the confusion caused by this thread. =C2=A0=C2=A0

I am considering doing a ID showing how the Connect Basic profile can be used to replace proprietary SSO connectors.
That would include a reference to=C2=A0http:= //tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as a way to do do IdP initiated.

Basically the existing profile with a single IdP and client credentials and reiterating the explanation from AOuth that scopes can be implicit and consent can be granted out of band.

That would allow a SAML to Connect proxy as an example.

Having more than one input document may help the WG understand the issues better. =C2=A0

Interested in discussing it?
Definitely.=C2=A0 Anybody else?

John B.


On May 22, 2014, at 10:27 AM, Anil Saldhana <Anil.Saldhana@redhat.co= m> wrote:=C2=A0

=20
John/Nat - would it be easy if you both can set up an OIDC profile for this use case?

On 05/21/2014 08:20 PM, John Bradley wrote:
=20
Thanks Nat. I can't add anything to your response.=C2=A0

Let's base our decision on adding authentication to OAuth 2 on reality.=C2=A0

Having a profile of Connect with most of the features Phil is looking for should not be a hard thing. =C2=A0 I don't personally think it is requir= ed to have that happen in the OAuth WG.=C2=A0


John B

Sent from my iPhone

On May 21, 2014, at 9:03 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Phil, please do not misinform the working group.=C2=A0

My responses inline:=C2=A0


2014-05-22 3:56 GMT+09:00 Phil Hunt <phil.hunt@oracle.com>:
Since several have voiced the opinion that the WG should not work on providing user authentication context because OpenID Connect already has a solution, I wanted to make clear how A4C is different from OpenID Connect.

OpenID Connect supports providing clients an =E2=80=9Cid_token=E2=80=9D usi= ng the id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid Auth) of the OAuth Core.

The A4C draft that was put forward by Mike, Tony, and myself (=C2=A0draft-hunt-oauth-v2-user-a4c=C2=A0)=C2=A0describes a flow similar to the code flow of normal OAuth. Here are the differences from Connect:

  • Client Authentication
    • Connect does NOT authenticate the client prior to returning the id token. The Connect flow is single step returning ID_TOKEN to an unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.3 appears only for the purpose of issuing an access token (user info token).
    • The A4C flow is 2-step following the OAuth2 code flow. It requires a code to be exchanged for ID_TOKEN after client authenticates in the second step (exactly duplicating the normal OAuth flow). =C2=A0A4C requires mutual authentication of clients and AS service providers. A4C has the same logic and security properties of the normal OAuth authorization flow.
This is not true.=C2= =A0

Connect for Code Flow for confidential client DOES authenticate the client before getting an ID Token.=C2=A0

Further, the Connect has an option of asymmetrically encrypting ID Token with the public key of the client, which authenticates the client even further.=C2=A0
Even further, the Connect has an option of asymmetrically encrypting the request with the public key of the server, which authenticates the server in addition to TLS. =C2=A0
  • User Authentication=C2=A0
    • Both OpenID Connect and A4C return ID tokens which contain pretty much the same information
    • A4C has additional features to allow clients to negotiate level of authentication and authentication types (min LOA,ACR,AMR) in addition to just returning ACR as in the case of OpenID.
What's the point of having both minimu= m LoA and AMR instead of ACR? =C2=A0Connect can also return AMR.=C2=A0
If you really wanted to have amr_values like feature, you can actually request it by using Claims request as

{ "id_token": {"amr&q= uot;: {"values": ["otp","= ;rsa"] }}}
=C2=A0
    • A4C only make re-auth lighter weight. No need to issue UserInfo tokens again. Re-auth also re-authenticates the client as well as user.
=C2=A0I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C is diverting from RFC6749. A4C is NOT OAuth anymore. The very reason OpenID Connect returns an access token from the token endpoint always is to adhere to RFC6749.=C2= =A0

OpenID Connect with scope=3Dopenid only is essentially the authN only operation.=C2= =A0

  • Privacy Option
    • The A4C=E2=80=99s authentication = of the client makes it possible to issue client-specific subject identifiers. This prevents multiple clients from colluding to share information.
This is supported by OpenID Connect as well. =C2=A0
    • Because Connect doesn=E2=80=99t k= now who the client is, the subject identifier returned is universal.
As stated above, this is false. It can even return PPID in the case of public client as well.=C2=A0
    • The spec could be used for pseudonymous authentication.
As state above, OpenID Connect supports this. It in fact advise the use of PPID (Pairwise Psuedonymous Identifier in section 17.3).=C2=A0
=C2=A0

As you can see the specs are doing similar things, but they have different security features.

As stated above, I do not see much. It has less option in general, and added feature is the amr_values and min_alv, which I do not see much value in it but if you really wanted, you can extend the Connect.=C2=A0
=C2=A0

As for need:
  • There are many sites using social network providers to authenticate using 6749 only, there are ongoing security concerns that many of us have blogged about. This may rise to the level of BUG on 6749.
Why not just use OpenID Connect? =C2=A0
  • Some social network providers have indicated a willingness to support an authenticate only feature. I also had an inquiry if A4C can be supported in OAuth1 as well as OAuth2. Some of this may be coming from a business decision to use a proprietary user profile API instead (this is not Oracle=E2=80= =99s position).
Authen only is fine with OpenID Connect. You can also use proprietary or whatever the user profile API "in addition". For the purpose of interoperability, it is better to have a standard user profile API though, and that's why Connect defines a very basic one for this purpose. =C2=A0
  • There is a consent problem because normal 6749 use requires users to consent to sharing information. Client developers in many cases would like an authen only profile where consent is implicit.
That's an implementation issue. RFC 6749 does not require the users to provide explicit consent.=C2=A0
It just states:=C2=A0

=C2=A0the authorization server authenticates the resource owner and obtains
   an authorization decision (by asking the resource owner o=
r by=C2=A0
=C2=A0 =C2=A0establishing approval via other means= ).=C2=A0

It can be implicit.=C2=A0
  • Developers have been indicating that defining new user-id/pwds =C2=A0and additionally sharing of profile information both cut back on the %age success of new user registrations. Many want to offer an authenticate only option for their users where the users explicitly decide what to supply in their profile. =C2=A0Pseudonymous authen is a basic feature.
This is supported by OpenID Connect as I stated above. =C2=A0
  • I see other areas (e.g. Kitten) where authentication and re-authentication may be of interest to other IETF groups.
    • There may be much broader requirements in the IETF community that are not of interest to OpenID Connect and its objectives


Why not?=C2=A0
=C2=A0
While it is reasonable to make A4C and Connect as compatible as possible, I am not sure they can be compatible. A4C and Connect are two different flows solving different use cases with different security characteristics.

Why not? I do not see it. You are essentially reading OpenID Connect wrong.=C2= =A0
=C2=A0

Note: I do not believe that the A4C draft is ready for last call-it is intended only as input to the WG process. The features and aspects like how the flow is initiated need to be discussed within the wider IETF community where broad consensus can be obtained. This is why I feel having it a work group milestone is important and I am willing to contribute my time towards it.

Since it adds essentially nothing and produces wait-and-see among the implementers, I think accepting this work as an work group item is actively harmful for the internet. If something is needed to worked on in the work group, I would rather want to see a profile of OpenID Connect referencing it. That causes much less confusion.=C2=A0
=C2=A0

Because of the ongoing issue of inappropriate use of 6749 and the broader requirements within the IETF, I feel this work needs to be discussed within the IETF WG.=C2=A0

Phil

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




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


--bcaec51b1adf07ba3804fa168ddf-- From nobody Fri May 23 13:01:30 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D331A0032 for ; Fri, 23 May 2014 13:01:26 -0700 (PDT) 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, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 dcGjGgTcoLGQ for ; Fri, 23 May 2014 13:01:22 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1429D1A0041 for ; Fri, 23 May 2014 13:01:21 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so8761585qcx.41 for ; Fri, 23 May 2014 13:01:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=At6snYKfQnwzpzN6M+kZ0HASz8w5DDagc+qGd+hfgts=; b=DlYmXKDVtqZxHY2mgdLDhDFZhy9WdB0CCeNYLwaAzCsZV7a6TkfXiVxyx/haCSlEi8 ZqT98p7XHTIAGIRvwhGH6wxESr7jTz7fawLe2sNj7IYiU6SIuyqbHNiNDcEpavbFTqsT hbABBtN9l6ym+Hrbj7uqPMT4ZnUwwbCAcW6zfNUdmGPAspJ4FXC24GeI8gC6bZHcYINa FIfKHCRBHPZWULqpMIDdoV1QBZ9D3Cbasx/iDz40RRqF5tqCZk35Jr+qvoO14OQhkQLW MsPkWLDvhVRKdXu4q9MSA2YjbUygafr0Sy+pfqQhTFlwwzWNKuH02Mw7Tay2okpbP7vs 5Q0A== X-Gm-Message-State: ALoCoQkPeOGM/Lu67rQSubXdL7xnWMfLRX553B6NaIpws9/Ad1HHjdlBxRJeyIpFEGGhpz8cYHnm X-Received: by 10.224.166.73 with SMTP id l9mr10372081qay.34.1400875279456; Fri, 23 May 2014 13:01:19 -0700 (PDT) Received: from [192.168.10.81] (ip-64-134-70-115.public.wayport.net. [64.134.70.115]) by mx.google.com with ESMTPSA id 74sm2531921qgf.32.2014.05.23.13.01.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 May 2014 13:01:17 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C10892CA-5BC1-4BE1-BF92-314E8CE41A3E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Bradley In-Reply-To: Date: Fri, 23 May 2014 16:01:15 -0400 Message-Id: References: <75D99637-1802-4C1F-83BE-D62AD938F9F4@oracle.com> <537E094C.6040504@redhat.com> <871F561C-73FB-4783-AEEF-42A9BB68E22D@ve7jtb.com> <537E10CD.6090309@redhat.com> <18209701-C62F-4CAC-9D2D-E3B305D5ECEC@ve7jtb.com> To: Brian Campbell X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/l_ONB1xYpB9caQwAKcS1CWz4nbo Cc: oauth Subject: Re: [OAUTH-WG] Authen Milestone: Comparing current A4C proposal to OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 20:01:27 -0000 --Apple-Mail=_C10892CA-5BC1-4BE1-BF92-314E8CE41A3E Content-Type: multipart/alternative; boundary="Apple-Mail=_F8B50226-BF1D-44EB-815B-5E243D04C78F" --Apple-Mail=_F8B50226-BF1D-44EB-815B-5E243D04C78F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hans, Torsten and I are working on the state draft that allows IdP = initiated. We haven't started documenting the rest of what would need to be in a = profile, but I am guessing that it would be the Connect code flow for = confidential clients to start. A version with the "id_token token" using proof of possession based on = channel id would also be interesting but probably not generally = deployable for a year, though having it ready in time for general = browser deployment may be a nice change. This may or may not want to be in the OAuth WG. That will be up to the = WG to decide. =20 AS initiated OAuth 2 may be something that people are interested in = without the identity layer. John B. On May 23, 2014, at 3:50 PM, Brian Campbell = wrote: > Simply having you acknowledge my existence goes to my head, John. >=20 > I'd be interested in discussing it for sure. I have some reservations = and/or confusion regarding your approach but need to actually read the = draft before I say anything more. Which I'll try and do at some point = here before too long. >=20 >=20 > On Thu, May 22, 2014 at 9:02 AM, John Bradley = wrote: > I was thinking of asking Brian Campbell as long as he doesn't let it = go to his head. >=20 > I expect Layer7 and others might also have an interest in such a = thing. >=20 > John B. >=20 > On May 22, 2014, at 10:59 AM, Anil Saldhana = wrote: >=20 >> On 05/22/2014 09:49 AM, John Bradley wrote: >>> Last week I was under the impression that Mike was working with Phil = to come up with a profile of Connect that basically takes a subset of = the basic client profile, and doesn't require changes to OAuth. >>>=20 >>> I was waiting to look at that revision before digging back into = this. >>>=20 >>> That is likely still happening despite the confusion caused by this = thread. =20 >>>=20 >>> I am considering doing a ID showing how the Connect Basic profile = can be used to replace proprietary SSO connectors. >>> That would include a reference to = http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as a = way to do do IdP initiated. >>>=20 >>> Basically the existing profile with a single IdP and client = credentials and reiterating the explanation from AOuth that scopes can = be implicit and consent can be granted out of band. >>>=20 >>> That would allow a SAML to Connect proxy as an example. >>>=20 >>> Having more than one input document may help the WG understand the = issues better. =20 >>>=20 >>> Interested in discussing it? >> Definitely. Anybody else? >>>=20 >>> John B. >>>=20 >>>=20 >>> On May 22, 2014, at 10:27 AM, Anil Saldhana = wrote:=20 >>>=20 >>>> John/Nat - would it be easy if you both can set up an OIDC profile = for this use case? >>>>=20 >>>> On 05/21/2014 08:20 PM, John Bradley wrote: >>>>> Thanks Nat. I can't add anything to your response.=20 >>>>>=20 >>>>> Let's base our decision on adding authentication to OAuth 2 on = reality.=20 >>>>>=20 >>>>> Having a profile of Connect with most of the features Phil is = looking for should not be a hard thing. I don't personally think it is = required to have that happen in the OAuth WG.=20 >>>>>=20 >>>>>=20 >>>>> John B >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>> On May 21, 2014, at 9:03 PM, Nat Sakimura = wrote: >>>>>=20 >>>>>> Phil, please do not misinform the working group.=20 >>>>>>=20 >>>>>> My responses inline:=20 >>>>>>=20 >>>>>>=20 >>>>>> 2014-05-22 3:56 GMT+09:00 Phil Hunt : >>>>>> Since several have voiced the opinion that the WG should not work = on providing user authentication context because OpenID Connect already = has a solution, I wanted to make clear how A4C is different from OpenID = Connect. >>>>>>=20 >>>>>> OpenID Connect supports providing clients an =93id_token=94 using = the id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid = Auth) of the OAuth Core. >>>>>> http://openid.net/specs/openid-connect-core-1_0.html >>>>>>=20 >>>>>> The A4C draft that was put forward by Mike, Tony, and myself ( = draft-hunt-oauth-v2-user-a4c ) describes a flow similar to the code flow = of normal OAuth. Here are the differences from Connect: >>>>>>=20 >>>>>> Client Authentication >>>>>> Connect does NOT authenticate the client prior to returning the = id token. The Connect flow is single step returning ID_TOKEN to an = unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.3 = appears only for the purpose of issuing an access token (user info = token). >>>>>> The A4C flow is 2-step following the OAuth2 code flow. It = requires a code to be exchanged for ID_TOKEN after client authenticates = in the second step (exactly duplicating the normal OAuth flow). A4C = requires mutual authentication of clients and AS service providers. A4C = has the same logic and security properties of the normal OAuth = authorization flow. >>>>>> This is not true.=20 >>>>>>=20 >>>>>> Connect for Code Flow for confidential client DOES authenticate = the client before getting an ID Token.=20 >>>>>>=20 >>>>>> Further, the Connect has an option of asymmetrically encrypting = ID Token with the public key of the client, which authenticates the = client even further.=20 >>>>>> Even further, the Connect has an option of asymmetrically = encrypting the request with the public key of the server, which = authenticates the server in addition to TLS. =20 >>>>>> User Authentication=20 >>>>>> Both OpenID Connect and A4C return ID tokens which contain pretty = much the same information >>>>>> A4C has additional features to allow clients to negotiate level = of authentication and authentication types (min LOA,ACR,AMR) in addition = to just returning ACR as in the case of OpenID. >>>>>> What's the point of having both minimum LoA and AMR instead of = ACR? Connect can also return AMR.=20 >>>>>> If you really wanted to have amr_values like feature, you can = actually request it by using Claims request as >>>>>>=20 >>>>>> { "id_token": {"amr": {"values": ["otp","rsa"] }}} >>>>>> =20 >>>>>> A4C only make re-auth lighter weight. No need to issue UserInfo = tokens again. Re-auth also re-authenticates the client as well as user. >>>>>> I RFC6749 Section 5.1 REQUIRES an access token to be returned. = A4C is diverting from RFC6749. A4C is NOT OAuth anymore. The very reason = OpenID Connect returns an access token from the token endpoint always is = to adhere to RFC6749.=20 >>>>>>=20 >>>>>> OpenID Connect with scope=3Dopenid only is essentially the authN = only operation.=20 >>>>>>=20 >>>>>> Privacy Option >>>>>> The A4C=92s authentication of the client makes it possible to = issue client-specific subject identifiers. This prevents multiple = clients from colluding to share information. >>>>>> This is supported by OpenID Connect as well. =20 >>>>>> Because Connect doesn=92t know who the client is, the subject = identifier returned is universal. >>>>>> As stated above, this is false. It can even return PPID in the = case of public client as well.=20 >>>>>> The spec could be used for pseudonymous authentication. >>>>>> As state above, OpenID Connect supports this. It in fact advise = the use of PPID (Pairwise Psuedonymous Identifier in section 17.3).=20 >>>>>> =20 >>>>>>=20 >>>>>> As you can see the specs are doing similar things, but they have = different security features. >>>>>>=20 >>>>>> As stated above, I do not see much. It has less option in = general, and added feature is the amr_values and min_alv, which I do not = see much value in it but if you really wanted, you can extend the = Connect.=20 >>>>>> =20 >>>>>>=20 >>>>>> As for need: >>>>>> There are many sites using social network providers to = authenticate using 6749 only, there are ongoing security concerns that = many of us have blogged about. This may rise to the level of BUG on = 6749. >>>>>> Why not just use OpenID Connect? =20 >>>>>> Some social network providers have indicated a willingness to = support an authenticate only feature. I also had an inquiry if A4C can = be supported in OAuth1 as well as OAuth2. Some of this may be coming = from a business decision to use a proprietary user profile API instead = (this is not Oracle=92s position). >>>>>> Authen only is fine with OpenID Connect. You can also use = proprietary or whatever the user profile API "in addition". For the = purpose of interoperability, it is better to have a standard user = profile API though, and that's why Connect defines a very basic one for = this purpose. =20 >>>>>> There is a consent problem because normal 6749 use requires users = to consent to sharing information. Client developers in many cases would = like an authen only profile where consent is implicit. >>>>>> That's an implementation issue. RFC 6749 does not require the = users to provide explicit consent.=20 >>>>>> It just states:=20 >>>>>>=20 >>>>>> the authorization server authenticates the resource owner and = obtains >>>>>> an authorization decision (by asking the resource owner or by=20= >>>>>> establishing approval via other means).=20 >>>>>>=20 >>>>>> It can be implicit.=20 >>>>>> Developers have been indicating that defining new user-id/pwds = and additionally sharing of profile information both cut back on the = %age success of new user registrations. Many want to offer an = authenticate only option for their users where the users explicitly = decide what to supply in their profile. Pseudonymous authen is a basic = feature. >>>>>> This is supported by OpenID Connect as I stated above. =20 >>>>>> I see other areas (e.g. Kitten) where authentication and = re-authentication may be of interest to other IETF groups. >>>>>> There may be much broader requirements in the IETF community that = are not of interest to OpenID Connect and its objectives >>>>>>=20 >>>>>>=20 >>>>>> Why not?=20 >>>>>> =20 >>>>>> While it is reasonable to make A4C and Connect as compatible as = possible, I am not sure they can be compatible. A4C and Connect are two = different flows solving different use cases with different security = characteristics. >>>>>>=20 >>>>>> Why not? I do not see it. You are essentially reading OpenID = Connect wrong.=20 >>>>>> =20 >>>>>>=20 >>>>>> Note: I do not believe that the A4C draft is ready for last = call-it is intended only as input to the WG process. The features and = aspects like how the flow is initiated need to be discussed within the = wider IETF community where broad consensus can be obtained. This is why = I feel having it a work group milestone is important and I am willing to = contribute my time towards it. >>>>>>=20 >>>>>> Since it adds essentially nothing and produces wait-and-see among = the implementers, I think accepting this work as an work group item is = actively harmful for the internet. If something is needed to worked on = in the work group, I would rather want to see a profile of OpenID = Connect referencing it. That causes much less confusion.=20 >>>>>> =20 >>>>>>=20 >>>>>> Because of the ongoing issue of inappropriate use of 6749 and the = broader requirements within the IETF, I feel this work needs to be = discussed within the IETF WG.=20 >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>> =20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail=_F8B50226-BF1D-44EB-815B-5E243D04C78F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hans, = Torsten and I are working on the state draft that allows IdP = initiated.

We haven't started documenting the rest of = what would need to be in a profile, but I am guessing that it would be = the Connect code flow for confidential clients to = start.

A version with the "id_token token" =  using proof of possession based on channel id would also be = interesting but probably not generally deployable for a year, though = having it ready in time for general browser deployment may be a nice = change.

This may or may not want to be in the = OAuth WG.  That will be up to the WG to decide. =   

AS initiated OAuth 2 may be = something that people are interested in without the identity = layer.

John B.

On May = 23, 2014, at 3:50 PM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

Simply having you acknowledge my = existence goes to my head, John.

I'd be interested in discussing = it for sure. I have some reservations and/or confusion regarding your = approach but need to actually read the draft before I say anything more. = Which I'll try and do at some point here before too long.


On = Thu, May 22, 2014 at 9:02 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I was thinking of asking Brian Campbell = as long as he doesn't let it go to his head.

I expect Layer7 and others might also have an interest in = such a thing.

John B.

On May 22, 2014, at 10:59 AM, Anil Saldhana = <Anil.Saldhana@redhat.com> wrote:

=20 =20 =20
On 05/22/2014 09:49 AM, John Bradley wrote:
=20 Last week I was under the impression that Mike was working with Phil to come up with a profile of Connect that basically takes a subset of the basic client profile, and doesn't require changes to OAuth.

I was waiting to look at that revision before digging back into this.

That is likely still happening despite the confusion caused by this thread.   

I am considering doing a ID showing how the Connect Basic profile can be used to replace proprietary SSO connectors.
That would include a reference to http://tools.ietf.org/html/draft-bradley-oauth-jwt-encod= ed-state as a way to do do IdP initiated.

Basically the existing profile with a single IdP and client credentials and reiterating the explanation from AOuth that scopes can be implicit and consent can be granted out of = band.

That would allow a SAML to Connect proxy as an example.

Having more than one input document may help the WG understand the issues better.  

Interested in discussing it?
Definitely.  Anybody else?

John B.


On May 22, 2014, at 10:27 AM, Anil Saldhana <Anil.Saldhana@redhat.com> wrote: 

=20
John/Nat - would it be easy if you both can set up an OIDC profile for this use case?

On 05/21/2014 08:20 PM, John Bradley wrote:
=20
Thanks Nat. I can't add anything to your response. 

Let's base our decision on adding authentication to OAuth 2 on reality. 

Having a profile of Connect with most of the features Phil is looking for should not be a hard thing.   I don't personally think it is = required to have that happen in the OAuth WG. 


John B

Sent from my iPhone

On May 21, 2014, at 9:03 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Phil, please do not misinform the working group. 

My responses inline: 


2014-05-22 3:56 GMT+09:00 Phil Hunt <phil.hunt@oracle.com>:
Since several have voiced the opinion that the WG should not work on providing user authentication context because OpenID Connect already has a solution, I wanted to make clear how A4C is different from OpenID Connect.

OpenID Connect supports providing clients an =93id_token=94 using the id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid Auth) of the OAuth Core.

The A4C draft that was put forward by Mike, Tony, and myself ( draft-hunt-oauth-v2-user-a4c ) describes a flow similar to the code flow of normal OAuth. Here are the differences from Connect:

  • Client Authentication
    • Connect does NOT authenticate the client prior to returning the id token. The Connect flow is single step returning ID_TOKEN to an unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.3 appears only for the purpose of issuing an access token (user info = token).
    • The A4C flow is 2-step following the OAuth2 code flow. It requires a code to be exchanged for ID_TOKEN after client authenticates in the second step (exactly duplicating the normal OAuth flow). =  A4C requires mutual authentication of clients and AS service providers. A4C has the same logic and security properties of the normal OAuth authorization flow.
This is not = true. 

Connect for Code Flow for confidential client DOES authenticate the client before getting an ID Token. 

Further, the Connect has an option of asymmetrically encrypting ID Token with the public key of the client, which authenticates the client even further. 
Even further, the Connect has an option of asymmetrically encrypting the request with the public key of the server, which authenticates the server in addition to TLS.  
  • User Authentication 
    • Both OpenID Connect and A4C return ID tokens which contain pretty much the same = information
    • A4C has additional features to allow clients to negotiate level of authentication and authentication types (min LOA,ACR,AMR) in addition to just returning ACR as in the case of OpenID.
What's the point of having both minimum LoA and AMR instead of ACR?  Connect = can also return AMR. 
If you really wanted to have amr_values like feature, you can actually request it by using Claims request as

{ "id_token": {"amr": {"values": ["otp","rsa"] = }}}
 
    • A4C only make re-auth lighter weight. No need to issue UserInfo tokens again. Re-auth also re-authenticates the client as well as user.
 I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C is diverting from RFC6749. A4C is NOT OAuth anymore. The very reason OpenID Connect returns an access token from the token endpoint always is to adhere to = RFC6749. 

OpenID Connect with scope=3Dopenid only is essentially the authN only = operation. 

  • Privacy Option
    • The A4C=92s authentication of the client makes it possible to issue client-specific subject identifiers. This prevents multiple clients from colluding to share information.
This is supported by OpenID Connect as well.  
    • Because Connect doesn=92t know who the client is, the subject identifier returned is universal.
As stated above, this is false. It can even return PPID in the case of public client as well. 
    • The spec could be used for pseudonymous = authentication.
As state above, OpenID Connect supports this. It in fact advise the use of PPID (Pairwise Psuedonymous Identifier in section 17.3). 
 

As you can see the specs are doing similar things, but they have different security features.

As stated above, I do not see much. It has less option in general, and added feature is the amr_values and min_alv, which I do not see much value in it but if you really wanted, you can extend the Connect. 
 

As for need:
  • There are many sites using social network providers to authenticate using 6749 only, there are ongoing security concerns that many of us have blogged about. This may rise to the level of BUG on = 6749.
Why not just use OpenID Connect? =  
  • Some social network providers have indicated a willingness to support an authenticate only feature. I also had an inquiry if A4C can be supported in OAuth1 as well as OAuth2. Some of this may be coming from a business decision to use a proprietary user profile API instead (this is not Oracle=92s position).
Authen only is fine with OpenID Connect. You can also use proprietary or whatever the user profile API "in addition". For the purpose of interoperability, it is better to have a standard user profile API though, and that's why Connect defines a very basic one for this purpose.  
  • There is a consent problem because normal 6749 use requires users to consent to sharing information. Client developers in many cases would like an authen only profile where consent is implicit.
That's an implementation issue. RFC 6749 does not require the users to provide explicit consent. 
It just states: 

 the authorization server authenticates the resource owner and obtains
   an =
authorization decision (by asking the resource owner or by 
   establishing approval via other = means). 

It can be implicit. 
  • Developers have been indicating that defining new user-id/pwds  and additionally sharing of profile information both cut back on the %age success of new user registrations. Many want to offer an authenticate only option for their users where the users explicitly decide what to supply in their profile. =  Pseudonymous authen is a basic feature.
This is supported by OpenID Connect as I stated above.  
  • I see other areas (e.g. Kitten) where authentication and re-authentication may be of interest to other IETF = groups.
    • There may be much broader requirements in the IETF community that are not of interest to OpenID Connect and its objectives


Why not? 
 
While it is reasonable to make A4C and Connect as compatible as possible, I am not sure they can be compatible. A4C and Connect are two different flows solving different use cases with different security = characteristics.

Why not? I do not see it. You are essentially reading OpenID Connect = wrong. 
 

Note: I do not believe that the A4C draft is ready for last call-it is intended only as input to the WG process. The features and aspects like how the flow is initiated need to be discussed within the wider IETF community where broad consensus can be obtained. This is why I feel having it a work group milestone is important and I am willing to contribute my time towards it.

Since it adds essentially nothing and produces wait-and-see among the implementers, I think accepting this work as an work group item is actively harmful for the internet. If something is needed to worked on in the work group, I would rather want to see a profile of OpenID Connect referencing it. That causes much less confusion. 
 

Because of the ongoing issue of inappropriate use of 6749 and the broader requirements within the IETF, I feel this work needs to be discussed within the IETF = WG. 

=
Phil

 
_______________________________________________
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=_F8B50226-BF1D-44EB-815B-5E243D04C78F-- --Apple-Mail=_C10892CA-5BC1-4BE1-BF92-314E8CE41A3E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA1MjMyMDAxMTZaMCMGCSqGSIb3DQEJBDEWBBSQH7T49LFuq1du2ogrZcEm MopFATCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQClS0B15V4l9cKlbiymUUXl4ZJ7DYPO4LhC2FxwBXztnB5FRccer6g6 qgzhX7K1LAR3UZ5r9a3JBJwv8Jls8wyfGtbQMu3W7Aig3Ky4oxGgSUPA767xUwCfyt4uNfl5ausH Y4K63XJ8bfzsKQfXwnb/nCRkEcRdFnpBdSquysY+NHxpScCoOjt15sVcZEFEfZOWsDwxA00OPZtd Atw3EhI1DO7rH51IrcHkiuOjGDbp5FFHMd39yMCSYiur/iktgXhuAbeey1u4N4YC753rVSr+ORqo VnJKB1iD5X4fUDtf84Beal7VQ9V5RZ/Kfq/YHdXXYpzw/3jxawRVZVIHyhYlAAAAAAAA --Apple-Mail=_C10892CA-5BC1-4BE1-BF92-314E8CE41A3E-- From nobody Wed May 28 09:00:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2AB1A034B for ; Wed, 28 May 2014 09:00:55 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 6Ed8lil9z1VP for ; Wed, 28 May 2014 09:00:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F52C1A016E for ; Wed, 28 May 2014 09:00:53 -0700 (PDT) Received: from BY2PR03CA029.namprd03.prod.outlook.com (10.242.234.150) by BN1PR0301MB0769.namprd03.prod.outlook.com (25.160.78.151) with Microsoft SMTP Server (TLS) id 15.0.949.11; Wed, 28 May 2014 16:00:48 +0000 Received: from BN1BFFO11FD005.protection.gbl (2a01:111:f400:7c10::1:137) by BY2PR03CA029.outlook.office365.com (2a01:111:e400:2c2c::22) with Microsoft SMTP Server (TLS) id 15.0.949.11 via Frontend Transport; Wed, 28 May 2014 16:00:47 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD005.mail.protection.outlook.com (10.58.144.68) with Microsoft SMTP Server (TLS) id 15.0.949.9 via Frontend Transport; Wed, 28 May 2014 16:00:45 +0000 Received: from TK5EX14MBXC293.redmond.corp.microsoft.com ([169.254.2.113]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0181.007; Wed, 28 May 2014 16:00:08 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: New Version Notification for draft-hunt-oauth-v2-user-a4c-03.txt Thread-Index: AQHPeozCYhd9i6B5d0yBEf0zzRk+fJtWJRGA Date: Wed, 28 May 2014 16:00:07 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD3739E@TK5EX14MBXC293.redmond.corp.microsoft.com> References: <20140528155155.23381.50455.idtracker@ietfa.amsl.com> In-Reply-To: <20140528155155.23381.50455.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438001)(13464003)(377454003)(377424004)(199002)(189002)(68736004)(85852003)(19580395003)(64706001)(81342001)(104016001)(76176999)(69596002)(50466002)(83322001)(80022001)(87936001)(15202345003)(6806004)(92566001)(20776003)(44976005)(47776003)(19580405001)(81156002)(77982001)(83072002)(92726001)(15975445006)(99396002)(76482001)(33656002)(23676002)(79102001)(66066001)(55846006)(81542001)(2656002)(86612001)(86362001)(97736001)(21056001)(84676001)(74502001)(4396001)(31966008)(46102001)(26826002)(54356999)(50986999)(74662001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR0301MB0769; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0225B0D5BC Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/gyhSVUs4-uDY04Ro6S4XxWp_wr8 Subject: [OAUTH-WG] FW: New Version Notification for draft-hunt-oauth-v2-user-a4c-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 16:00:55 -0000 VGhlIGE0YyBkcmFmdCBoYXMgYmVlbiB1cGRhdGVkIHRvIHVzZSBhIG5ldyByZXNwb25zZV90eXBl IHZhbHVlIGZvciB0aGUgY2FzZSB3aGVyZSBhbiBhdXRob3JpemF0aW9uIGNvZGUgaXMgZXhjaGFu Z2VkIGZvciBhbiBJRCBUb2tlbiBidXQgbm8gYWNjZXNzIHRva2VuLiAgVGhlIHRyZWF0bWVudCBv ZiB0aGUgYXV0aGVudGljYXRpb24gY29udGV4dCBjbGFzcyByZWZlcmVuY2UgYW5kIGF1dGhlbnRp Y2F0aW9uIGxldmVsIHBhcmFtZXRlcnMgaGFzIGFsc28gYmVlbiB1bmlmaWVkLiAgTGlrZSB0aGUg LTAyIGRyYWZ0LCB0aGlzIGRyYWZ0IHVzZXMgb25seSB0aGUgc3RhbmRhcmQgT0F1dGggMi4wIGVu ZHBvaW50cy4NCg0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10gDQpTZW50OiBXZWRuZXNkYXksIE1heSAyOCwgMjAxNCA4OjUyIEFNDQpUbzogUGhpbCBI dW50OyBBbnRob255IE5hZGFsaW47IFBoaWwgSHVudDsgTWlrZSBKb25lczsgQW50aG9ueSBOYWRh bGluOyBNaWtlIEpvbmVzDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDMudHh0DQpoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IE1pY2hhZWwgQi4gSm9uZXMgYW5kIHBvc3RlZCB0byB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yw0KUmV2 aXNpb246CTAzDQpUaXRsZToJCVByb3ZpZGluZyBVc2VyIEF1dGhlbnRpY2F0aW9uIEluZm9ybWF0 aW9uIHRvIE9BdXRoIDIuMCBDbGllbnRzDQpEb2N1bWVudCBkYXRlOgkyMDE0LTA1LTI4DQpHcm91 cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxNA0KVVJMOiAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1bnQtb2F1dGgtdjItdXNl ci1hNGMtMDMudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy8NCkh0bWxpemVkOiAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTAzDQpE aWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaHVu dC1vYXV0aC12Mi11c2VyLWE0Yy0wMw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgc3BlY2lmaWNhdGlv biBkZWZpbmVzIGEgd2F5IGZvciBPQXV0aCAyLjAgY2xpZW50cyB0byB2ZXJpZnkgdGhlDQogICBp ZGVudGl0eSBvZiB0aGUgRW5kLVVzZXIgYW5kIG9idGFpbiBjb25zZW50IGJhc2VkIHVwb24gdGhl DQogICBhdXRoZW50aWNhdGlvbiBwZXJmb3JtZWQgYnkgYW4gQXV0aG9yaXphdGlvbiBTZXJ2ZXIu ICBUaGUNCiAgIGludGVyYWN0aW9ucyBkZWZpbmVkIGJ5IHRoaXMgc3BlY2lmaWNhdGlvbiBhcmUg aW50ZW50aW9uYWxseQ0KICAgY29tcGF0aWJsZSB3aXRoIHRoZSBPcGVuSUQgQ29ubmVjdCBwcm90 b2NvbC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K


On May 14, 2014, at 10:23 AM, George Fletcher <gffletch@aol.com> = wrote:

=20 =20
I also would like to see the WG not focus on another authentication mechanism and instead look at work like Brian suggested.

Thanks,
George
On 5/14/14, 11:41 AM, Chuck Mortimore wrote:
Agree with Brian and Justin here.   Work is already = covered in Connect

- cmort

On May 14, 2014, at 8:39 AM, Justin Richer <jricher@mit.edu> wrote:

I agree with Brian and object to the Authentication work item. I think there=92s limited interest and utility in such a = draft, especially now that OpenID Connect has been published and its core authentication capabilities are identical to what was called for in the other draft a year ago (a similarity, I=92ll add, which was noted at the time). 

 =97 Justin

On May 14, 2014, at 8:24 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I recall, there was only very = limited interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03<= /a> - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients. 




On Thu, May 8, 2014 at = 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--
3D"Ping
Brian Campbell
Portfolio Architect
@ bcampbell@pingidentity.com
3D"phone" +1 = 720.317.2061
Connect with us=85
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard
3D"Register

_______________________________________________
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

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

= = --Apple-Mail=_842A30A8-B336-4B74-8A54-1D792DC53D23-- From nobody Wed May 14 10:34:09 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DDB1A013E for ; Wed, 14 May 2014 10:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 MNuRdhDP-eqH for ; Wed, 14 May 2014 10:33:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id CDFE31A0102 for ; Wed, 14 May 2014 10:33:55 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4EHXm6R001751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 14 May 2014 13:33:49 -0400 Received: from localhost.localdomain (vpn-54-146.rdu2.redhat.com [10.10.54.146]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4EHXkFp016680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 14 May 2014 13:33:47 -0400 Message-ID: <5373A8FA.9030601@redhat.com> Date: Wed, 14 May 2014 12:33:46 -0500 From: Anil Saldhana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: oauth@ietf.org References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000605030607020103070504" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/in5ITcmyNbQ9amz5hmWykoUyiY0 Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:34:02 -0000 This is a multi-part message in MIME format. --------------000605030607020103070504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tony/Phil, any chance you can have this work done at OIDC? The reason is that it is commonly understood/accepted now that OAuth provides authorization related specs while authentication/profile related specs are coming from OIDC (which builds on top of OAuth2). Regards, Anil On 05/14/2014 10:47 AM, Anthony Nadalin wrote: > > I agree with Phil on this one, there are implementations of this > already and much interest > > *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Wednesday, May 14, 2014 8:32 AM > *To:* Brian Campbell > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering > > On the contrary. I and others are interested. > > We are waiting for the charter to pick up the work. > > Regardless there will be a new draft shortly. > > > Phil > > > On May 14, 2014, at 5:24, Brian Campbell > wrote: > > I would object to 'OAuth Authentication' being picked up by the WG > as a work item. The starting point draft has expired and it hasn't > really been discusses since Berlin nearly a year ago. As I > recall, there was only very limited interest in it even then. I > also don't believe it fits well with the WG charter. > > I would suggest the WG consider picking up 'OAuth Symmetric Proof > of Possession for Code Extension' for which there is an excellent > starting point of > http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a > relativity simple security enhancement which addresses problems > currently being encountered in deployments of native clients. > > On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig > > wrote: > > Hi all, > > you might have seen that we pushed the assertion documents and > the JWT > documents to the IESG today. We have also updated the > milestones on the > OAuth WG page. > > This means that we can plan to pick up new work in the group. > We have sent a request to Kathleen to change the milestone for > the OAuth > security mechanisms to use the proof-of-possession terminology. > > We also expect an updated version of the dynamic client > registration > spec incorporating last call feedback within about 2 weeks. > > We would like you to think about adding the following > milestones to the > charter as part of the re-chartering effort: > > ----- > > Nov 2014 Submit 'Token introspection' to the IESG for > consideration as a > Proposed Standard > Starting point: > > Jan 2015 Submit 'OAuth Authentication' to the IESG for > consideration as > a Proposed Standard > Starting point: > > Jan 2015 Submit 'Token Exchange' to the IESG for consideration > as a > Proposed Standard > Starting point: > > ----- > > We also updated the charter text to reflect the current > situation. Here > is the proposed text: > > ----- > > Charter for Working Group > > > The Web Authorization (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term > credentials, > or even their identity. For example, a photo-sharing site that > supports OAuth could allow its users to use a third-party > printing Web > site to print their private pictures, without allowing the > printing > site to gain full control of the user's account and without > having the > user share his or her photo-sharing sites' long-term > credential with > the printing site. > > The OAuth 2.0 protocol suite encompasses > > * a protocol for obtaining access tokens from an authorization > server with the resource owner's consent, > * protocols for presenting these access tokens to resource server > for access to a protected resource, > * guidance for securely using OAuth 2.0, > * the ability to revoke access tokens, > * standardized format for security tokens encoded in a JSON format > (JSON Web Token, JWT), > * ways of using assertions with OAuth, and > * a dynamic client registration protocol. > > The working group also developed security schemes for presenting > authorization tokens to access a protected resource. This led > to the > publication of the bearer token, as well as work that remains > to be > completed on proof-of-possession and token exchange. > > The ongoing standardization effort within the OAuth working > group will > focus on enhancing interoperability and functionality of OAuth > deployments, such as a standard for a token introspection > service and > standards for additional security of OAuth requests. > > ----- > > Feedback appreciated. > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > > Ping Identity logo > > > > *Brian Campbell* > Portfolio Architect > > *@* > > > > bcampbell@pingidentity.com > > phone > > > > +1 720.317.2061 > > Connect with us... > > twitter logo youtube logo > LinkedIn logo > Facebook logo > Google+ logo > slideshare logo > flipboard logo > rss feed icon > > > Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19--23 July, 2014 | Monterey, CA > > > _______________________________________________ > 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 --------------000605030607020103070504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Tony/Phil,
  any chance you can have this work done at OIDC?

The reason is that it is commonly understood/accepted now that OAuth provides authorization related specs while authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:

I agree with Phil on this one, there are implementations of this already and much interest

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

On the contrary. I and others are interested. 

 

We are waiting for the charter to pick up the work. 

 

Regardless there will be a new draft shortly. 


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

Ping Identity logo

Brian Campbell
Portfolio Architect

@

bcampbell@pingidentity.com

phone

+1 720.317.2061

Connect with us…

twitter logoyoutube logoLinkedIn logoFacebook logoGoogle+ logoslideshare logoflipboard logorss feed icon

Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA

 

_______________________________________________
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

--------------000605030607020103070504-- From nobody Wed May 14 10:45:05 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739B81A014D for ; Wed, 14 May 2014 10:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 5IqIlmTxxQ74 for ; Wed, 14 May 2014 10:45:01 -0700 (PDT) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by ietfa.amsl.com (Postfix) with ESMTP id 33CF11A012F for ; Wed, 14 May 2014 10:45:01 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id wo20so2523567obc.21 for ; Wed, 14 May 2014 10:44:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zAC777+1NnKiJ7DEVP0Lw8OE24a8eq20pfSJ911aFm4=; b=N1aFTgQRHjxDocWFtSEfCaXwIsggz9s2onvTbxMnlXyQRFg76iGNjn/I04z7qnKEP7 H/kYAeS6FhgOMu3AA4/TIyeqBob8Wrp0XLT6x973IlqBmxjp8Y0cYsN8aiiDAkOSyqAx Chi5bdNO3qM7w+9iFCdnXBNrpekH3qLZzASaSk3CbbCA7lhGooZmn2G138jOvQ608Tj2 tUlYFuNh5U4eZBMJXZ6joT+LTj6Q1w+uk4pve8TWwoYtFsz4DOdSIWLnIIiIz4ry09lD 4OITRZwO13bgJs7BjYUWdJ215E5ssC1p+7NnHx9hNcCjt6dKcQO9OGsg1g3fcetJ9E2G aDoQ== X-Gm-Message-State: ALoCoQnALglyaESdB6MYjMhpNdt1xofnVR1ntnXEGf4ftCa2PQLsjPjQFjuCaJQVhgxpfWqt5FNu MIME-Version: 1.0 X-Received: by 10.182.42.228 with SMTP id r4mr5065260obl.20.1400089494203; Wed, 14 May 2014 10:44:54 -0700 (PDT) Received: by 10.76.75.169 with HTTP; Wed, 14 May 2014 10:44:53 -0700 (PDT) In-Reply-To: References: <536BF140.5070106@gmx.net> <84B60891-F9E1-4183-9031-8BED6315C70F@mit.edu> <-968574624925308911@unknownmsgid> <5373A674.1060700@aol.com> Date: Wed, 14 May 2014 10:44:53 -0700 Message-ID: From: Chuck Mortimore To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11c30b0ef4bb1004f95fbc07 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/X_NRFQlzRts-O-c_3CnC7c1RkIE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:45:04 -0000 --001a11c30b0ef4bb1004f95fbc07 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Would still love to hear you answer _why_ "the IETF needs a draft that enables and provides user authentication information to clients." Would still love to see Tony point to the existing a4c implementations. On Wed, May 14, 2014 at 10:29 AM, Phil Hunt wrote: > This is not an authentication mechanism - it is a method for providing > end-user authentication information to client applications. I will publi= sh > a revised draft shortly. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On May 14, 2014, at 10:23 AM, George Fletcher wrote: > > I also would like to see the WG not focus on another authentication > mechanism and instead look at work like Brian suggested. > > Thanks, > George > > On 5/14/14, 11:41 AM, Chuck Mortimore wrote: > > Agree with Brian and Justin here. Work is already covered in Connect > > - cmort > > On May 14, 2014, at 8:39 AM, Justin Richer wrote: > > I agree with Brian and object to the Authentication work item. I think > there=E2=80=99s limited interest and utility in such a draft, especially = now that > OpenID Connect has been published and its core authentication capabilitie= s > are identical to what was called for in the other draft a year ago (a > similarity, I=E2=80=99ll add, which was noted at the time). > > =E2=80=94 Justin > > On May 14, 2014, at 8:24 AM, Brian Campbell > wrote: > > I would object to 'OAuth Authentication' being picked up by the WG as a > work item. The starting point draft has expired and it hasn't really been > discusses since Berlin nearly a year ago. As I recall, there was only ve= ry > limited interest in it even then. I also don't believe it fits well with > the WG charter. > > I would suggest the WG consider picking up 'OAuth Symmetric Proof of > Possession for Code Extension' for which there is an excellent starting > point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a > relativity simple security enhancement which addresses problems currently > being encountered in deployments of native clients. > > > > > On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> Hi all, >> >> you might have seen that we pushed the assertion documents and the JWT >> documents to the IESG today. We have also updated the milestones on the >> OAuth WG page. >> >> This means that we can plan to pick up new work in the group. >> We have sent a request to Kathleen to change the milestone for the OAuth >> security mechanisms to use the proof-of-possession terminology. >> >> We also expect an updated version of the dynamic client registration >> spec incorporating last call feedback within about 2 weeks. >> >> We would like you to think about adding the following milestones to the >> charter as part of the re-chartering effort: >> >> ----- >> >> Nov 2014 Submit 'Token introspection' to the IESG for consideration as a >> Proposed Standard >> Starting point: >> >> Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as >> a Proposed Standard >> Starting point: >> >> Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a >> Proposed Standard >> Starting point: >> >> ----- >> >> We also updated the charter text to reflect the current situation. Here >> is the proposed text: >> >> ----- >> >> Charter for Working Group >> >> >> The Web Authorization (OAuth) protocol allows a user to grant a >> third-party Web site or application access to the user's protected >> resources, without necessarily revealing their long-term credentials, >> or even their identity. For example, a photo-sharing site that >> supports OAuth could allow its users to use a third-party printing Web >> site to print their private pictures, without allowing the printing >> site to gain full control of the user's account and without having the >> user share his or her photo-sharing sites' long-term credential with >> the printing site. >> >> The OAuth 2.0 protocol suite encompasses >> >> * a protocol for obtaining access tokens from an authorization >> server with the resource owner's consent, >> * protocols for presenting these access tokens to resource server >> for access to a protected resource, >> * guidance for securely using OAuth 2.0, >> * the ability to revoke access tokens, >> * standardized format for security tokens encoded in a JSON format >> (JSON Web Token, JWT), >> * ways of using assertions with OAuth, and >> * a dynamic client registration protocol. >> >> The working group also developed security schemes for presenting >> authorization tokens to access a protected resource. This led to the >> publication of the bearer token, as well as work that remains to be >> completed on proof-of-possession and token exchange. >> >> The ongoing standardization effort within the OAuth working group will >> focus on enhancing interoperability and functionality of OAuth >> deployments, such as a standard for a token introspection service and >> standards for additional security of OAuth requests. >> >> ----- >> >> Feedback appreciated. >> >> Ciao >> Hannes & Derek >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > [image: Ping Identity logo] > Brian Campbell > Portfolio Architect > @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect > with us=E2=80=A6 [image: twitter logo] [image: > youtube logo] [image: > LinkedIn logo] [image: Facebook > logo] [image: Google+ logo] [image: > slideshare logo] [image: > flipboard logo] [image: rss feed icon] > [image: Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] > > _______________________________________________ > 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 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 > > --001a11c30b0ef4bb1004f95fbc07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Would still love to hear you answer _why_ "the IETF needs a draft th= at enables and provides user authentication information to clients.&= quot;=C2=A0

Would still love to see Tony point to the existing a4c imple= mentations.=C2=A0




On Wed, May 14, 2014 at 10:29= AM, Phil Hunt <phil.hunt@oracle.com> wrote:
This is = not an authentication mechanism - it is a method for providing end-user aut= hentication information to client applications. =C2=A0I will publish a revi= sed draft shortly.=C2=A0


On May 14, 2014, at 10:23 AM, George F= letcher <gffletch@= aol.com> wrote:

=20 =20 =20
I also would like to see the WG not focus on another authentication mechanism and instead look at work like Brian suggested.

Thanks,
George
On 5/14/14, 11:41 AM, Chuck Mortimore wrote:
=20
Agree with Brian and Justin here. =C2=A0 Work is already covered in Connect

- cmort

On May 14, 2014, at 8:39 AM, Justin Richer <jricher@mit.edu> wrote:

=20 I agree with Brian and object to the Authentication work item. I think there=E2=80=99s limited interest and utility in such a dr= aft, especially now that OpenID Connect has been published and its core authentication capabilities are identical to what was called for in the other draft a year ago (a similarity, I=E2=80= =99ll add, which was noted at the time).=C2=A0

=C2=A0=E2=80=94 Justin

On May 14, 2014, at 8:24 AM, Brian Campbell <bcampbell@pingide= ntity.com> wrote:

=20
I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.=C2=A0 As I recall, there was only very limite= d interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients.=C2=A0




On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@g= mx.net> wrote:
Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to th= e IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to t= he IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IES= G for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
=C2=A0 (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--
3D"Ping
Brian Campbell
Portfolio Architect
@<= /td> bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn =3D"Facebook 3D= <= a href=3D"http://www.slideshare.net/PingIdentity" style=3D"text-decoration:= none" title=3D"Ping on SlideShare" target=3D"_blank">3D"slideshare= 3D"flipboard 3D"rss
=3D"Register

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

_______________________________________________ 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

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


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


--001a11c30b0ef4bb1004f95fbc07-- From nobody Wed May 14 10:48:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04B81A0102 for ; Wed, 14 May 2014 10:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 J8dtAoq4wnYU for ; Wed, 14 May 2014 10:48:27 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 46B971A02BD for ; Wed, 14 May 2014 10:48:27 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id y20so2192747ier.20 for ; Wed, 14 May 2014 10:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=xJmZGK7euksIQI0sQfPLKpNtMnAL5Cz+wXBcDQl/i6E=; b=qMrxTeUq8EwRWTgOhnFjbX4hHnXlKNzNA1RGFdEoB+5jsQThecfDJLdOM1QDZsFfdM uk7+3UX1KZk78Bi4y0DEjDj4yZcCM8UaZ7Qsk0u+PaSDoCCcusfFUoABIZdF7bn/RBxQ 9CGBKLzmccBzjOr3okJBmaJdj3J7S/XscR82J9djwJSFhPDtjGyx1766JjVBbdDaMZpx yP/tetkFDsR2XDzgKf1lzXF9DKJVwNA/qB3KY/+aXaeMgRfXvfIjAEBC3qHvlWhoU3nK 9gJUJUVaRLeunhPtA9GqIzjdKxbiMlfsLdD1ObjNoxAvIQy5CzmtcwFHx6D9oZSdlHfi YivQ== X-Received: by 10.42.109.8 with SMTP id j8mr3338220icp.89.1400089700454; Wed, 14 May 2014 10:48:20 -0700 (PDT) Received: from [192.168.0.192] (CPE0022b0cb82b4-CMbc1401e98fa0.cpe.net.cable.rogers.com. [99.224.82.58]) by mx.google.com with ESMTPSA id p4sm6819377igy.7.2014.05.14.10.48.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 May 2014 10:48:19 -0700 (PDT) Message-ID: <5373AC68.1070200@gmail.com> Date: Wed, 14 May 2014 13:48:24 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Phil Hunt , George Fletcher References: <536BF140.5070106@gmx.net> <84B60891-F9E1-4183-9031-8BED6315C70F@mit.edu> <-968574624925308911@unknownmsgid> <5373A674.1060700@aol.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020909040006050303040605" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/vUitWr0HmOYN4kubsu4xp8oJvCE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:48:36 -0000 This is a multi-part message in MIME format. --------------020909040006050303040605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Phil, neither is Connect an authentication mechanism, it (and SAML, WS-fed etc) is also a 'method for providing end-user authentication information to client applications' We don't need a Connect-- paul On 5/14/14, 1:29 PM, Phil Hunt wrote: > This is not an authentication mechanism - it is a method for providing > end-user authentication information to client applications. I will > publish a revised draft shortly. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On May 14, 2014, at 10:23 AM, George Fletcher > wrote: > >> I also would like to see the WG not focus on another authentication >> mechanism and instead look at work like Brian suggested. >> >> Thanks, >> George >> >> On 5/14/14, 11:41 AM, Chuck Mortimore wrote: >>> Agree with Brian and Justin here. Work is already covered in Connect >>> >>> - cmort >>> >>> On May 14, 2014, at 8:39 AM, Justin Richer >> > wrote: >>> >>>> I agree with Brian and object to the Authentication work item. I >>>> think there's limited interest and utility in such a draft, >>>> especially now that OpenID Connect has been published and its core >>>> authentication capabilities are identical to what was called for in >>>> the other draft a year ago (a similarity, I'll add, which was noted >>>> at the time). >>>> >>>> --- Justin >>>> >>>> On May 14, 2014, at 8:24 AM, Brian Campbell >>>> > wrote: >>>> >>>>> I would object to 'OAuth Authentication' being picked up by the WG >>>>> as a work item. The starting point draft has expired and it hasn't >>>>> really been discusses since Berlin nearly a year ago. As I >>>>> recall, there was only very limited interest in it even then. I >>>>> also don't believe it fits well with the WG charter. >>>>> >>>>> I would suggest the WG consider picking up 'OAuth Symmetric Proof >>>>> of Possession for Code Extension' for which there is an excellent >>>>> starting point of >>>>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a >>>>> relativity simple security enhancement which addresses problems >>>>> currently being encountered in deployments of native clients. >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig >>>>> > wrote: >>>>> >>>>> Hi all, >>>>> >>>>> you might have seen that we pushed the assertion documents and >>>>> the JWT >>>>> documents to the IESG today. We have also updated the >>>>> milestones on the >>>>> OAuth WG page. >>>>> >>>>> This means that we can plan to pick up new work in the group. >>>>> We have sent a request to Kathleen to change the milestone for >>>>> the OAuth >>>>> security mechanisms to use the proof-of-possession terminology. >>>>> >>>>> We also expect an updated version of the dynamic client >>>>> registration >>>>> spec incorporating last call feedback within about 2 weeks. >>>>> >>>>> We would like you to think about adding the following >>>>> milestones to the >>>>> charter as part of the re-chartering effort: >>>>> >>>>> ----- >>>>> >>>>> Nov 2014 Submit 'Token introspection' to the IESG for >>>>> consideration as a >>>>> Proposed Standard >>>>> Starting point: >>>>> >>>>> Jan 2015 Submit 'OAuth Authentication' to the IESG for >>>>> consideration as >>>>> a Proposed Standard >>>>> Starting point: >>>>> >>>>> Jan 2015 Submit 'Token Exchange' to the IESG for consideration >>>>> as a >>>>> Proposed Standard >>>>> Starting point: >>>>> >>>>> ----- >>>>> >>>>> We also updated the charter text to reflect the current >>>>> situation. Here >>>>> is the proposed text: >>>>> >>>>> ----- >>>>> >>>>> Charter for Working Group >>>>> >>>>> >>>>> The Web Authorization (OAuth) protocol allows a user to grant a >>>>> third-party Web site or application access to the user's protected >>>>> resources, without necessarily revealing their long-term >>>>> credentials, >>>>> or even their identity. For example, a photo-sharing site that >>>>> supports OAuth could allow its users to use a third-party >>>>> printing Web >>>>> site to print their private pictures, without allowing the >>>>> printing >>>>> site to gain full control of the user's account and without >>>>> having the >>>>> user share his or her photo-sharing sites' long-term >>>>> credential with >>>>> the printing site. >>>>> >>>>> The OAuth 2.0 protocol suite encompasses >>>>> >>>>> * a protocol for obtaining access tokens from an authorization >>>>> server with the resource owner's consent, >>>>> * protocols for presenting these access tokens to resource server >>>>> for access to a protected resource, >>>>> * guidance for securely using OAuth 2.0, >>>>> * the ability to revoke access tokens, >>>>> * standardized format for security tokens encoded in a JSON format >>>>> (JSON Web Token, JWT), >>>>> * ways of using assertions with OAuth, and >>>>> * a dynamic client registration protocol. >>>>> >>>>> The working group also developed security schemes for presenting >>>>> authorization tokens to access a protected resource. This led >>>>> to the >>>>> publication of the bearer token, as well as work that remains >>>>> to be >>>>> completed on proof-of-possession and token exchange. >>>>> >>>>> The ongoing standardization effort within the OAuth working >>>>> group will >>>>> focus on enhancing interoperability and functionality of OAuth >>>>> deployments, such as a standard for a token introspection >>>>> service and >>>>> standards for additional security of OAuth requests. >>>>> >>>>> ----- >>>>> >>>>> Feedback appreciated. >>>>> >>>>> Ciao >>>>> Hannes & Derek >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Ping Identity logo >>>>> Brian Campbell >>>>> Portfolio Architect >>>>> @ bcampbell@pingidentity.com >>>>> phone +1 720.317.2061 >>>>> Connect with us... >>>>> twitter logo youtube logo >>>>> LinkedIn logo >>>>> Facebook logo >>>>> Google+ logo >>>>> slideshare >>>>> logo flipboard logo >>>>> rss feed icon >>>>> >>>>> >>>>> Register for Cloud Identity Summit 2014 | Modern Identity >>>>> Revolution | 19--23 July, 2014 | Monterey, CA >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 --------------020909040006050303040605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Phil, neither is Connect an authentication mechanism, it (and SAML, WS-fed etc) is also a 'method for providing end-user authentication information to client applications'

We don't need a Connect--

paul
On 5/14/14, 1:29 PM, Phil Hunt wrote:
This is not an authentication mechanism - it is a method for providing end-user authentication information to client applications.  I will publish a revised draft shortly. 


On May 14, 2014, at 10:23 AM, George Fletcher <gffletch@aol.com> wrote:

I also would like to see the WG not focus on another authentication mechanism and instead look at work like Brian suggested.

Thanks,
George
On 5/14/14, 11:41 AM, Chuck Mortimore wrote:
Agree with Brian and Justin here.   Work is already covered in Connect

- cmort

On May 14, 2014, at 8:39 AM, Justin Richer <jricher@mit.edu> wrote:

I agree with Brian and object to the Authentication work item. I think there’s limited interest and utility in such a draft, especially now that OpenID Connect has been published and its core authentication capabilities are identical to what was called for in the other draft a year ago (a similarity, I’ll add, which was noted at the time). 

 — Justin

On May 14, 2014, at 8:24 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients. 




On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--
Ping Identity logo
Brian Campbell
Portfolio Architect
@ bcampbell@pingidentity.com
phone +1 720.317.2061
Connect with us…
twitter logo youtube logo LinkedIn logo Facebook logo Google+ logo slideshare logo flipboard logo rss feed icon
Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA

_______________________________________________
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

--
<XeC.html>
_______________________________________________
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

--------------020909040006050303040605-- From nobody Wed May 14 10:59:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E87F1A0102 for ; Wed, 14 May 2014 10:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 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, T_REMOTE_IMAGE=0.01] autolearn=ham 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 U3tLuaBSa_kE for ; Wed, 14 May 2014 10:59:24 -0700 (PDT) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3463F1A00B2 for ; Wed, 14 May 2014 10:59:23 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id c13so1596345eek.26 for ; Wed, 14 May 2014 10:59:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=GhO20WJpndUgaoCOVSl6E3L5Dhh4/rAxLs7VjATSOko=; b=Si0KvBTJUaDEN2WMnGU6vPcgj8TFiNM6LhjCekP1q7buOscT5NnM9o1yrM081t5ktP xlo1Rgo+VWQS+KxectHefpKUU6mXXqeSdBQisTuBCFUDeh13wFsoTJIfgg4UiUlsDE2n BGfN4joofhG4d32+4HK7wPZ/rWYlM4MELOevgdt7rVFsW2YfxysSZw8RUgvtU2ImkM6U yZgaW50Lym5l0XOaJGn0NFD6NH7C//L31sYClg0kaA00jpGcn6l8GURwGLXfG+dYYIWi dr87FGZGcSejFY91ygxiy4rAQEyFFcehO3acg3rFDHW2nsQfTmjoqjevZyy1GypGvtqf Gy3A== X-Gm-Message-State: ALoCoQl1+HPC7CHFAPoiIZzSOMcmWwdhJRJS7jHdzJXFlNYY8y9Qt15Qo+WBuu/KrgkEnHlIgpJ9 X-Received: by 10.15.49.137 with SMTP id j9mr7477117eew.26.1400090356745; Wed, 14 May 2014 10:59:16 -0700 (PDT) Received: from [10.105.255.214] (vlan105-gw1.ush2.tnib.de. [86.110.65.1]) by mx.google.com with ESMTPSA id 8sm6689762eea.10.2014.05.14.10.59.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 May 2014 10:59:15 -0700 (PDT) References: <536BF140.5070106@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-44BF63E5-7387-40AC-9D85-FE30EC8D03B2; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <60BC637A-FD8D-4C92-A94C-93F89E868CB9@ve7jtb.com> X-Mailer: iPhone Mail (11D201) From: John Bradley Date: Wed, 14 May 2014 19:59:14 +0200 To: Brian Campbell Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YqC7CtcbYFDowiD5zNpYNdUf04w Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:59:28 -0000 --Apple-Mail-44BF63E5-7387-40AC-9D85-FE30EC8D03B2 Content-Type: multipart/alternative; boundary=Apple-Mail-3A1A9F3E-5773-480E-9672-130CE5EED0EE Content-Transfer-Encoding: 7bit --Apple-Mail-3A1A9F3E-5773-480E-9672-130CE5EED0EE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I know a number of people implementing > http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 Having it on a RFC track may make sense.=20 I remain to be convinced that a4c ads anything other than confusion.=20 If the WG wants to take it up it should be aligned with Connect. I think th= ere are more important things to spend time on.=20 Sent from my iPhone > On May 14, 2014, at 2:24 PM, Brian Campbell w= rote: >=20 > I would object to 'OAuth Authentication' being picked up by the WG as a wo= rk item. The starting point draft has expired and it hasn't really been disc= usses since Berlin nearly a year ago. As I recall, there was only very limi= ted interest in it even then. I also don't believe it fits well with the WG c= harter. >=20 > I would suggest the WG consider picking up 'OAuth Symmetric Proof of Posse= ssion for Code Extension' for which there is an excellent starting point of h= ttp://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity s= imple security enhancement which addresses problems currently being encounte= red in deployments of native clients. =20 >=20 >=20 >=20 >=20 >> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig wrote: >> Hi all, >>=20 >> you might have seen that we pushed the assertion documents and the JWT >> documents to the IESG today. We have also updated the milestones on the >> OAuth WG page. >>=20 >> This means that we can plan to pick up new work in the group. >> We have sent a request to Kathleen to change the milestone for the OAuth >> security mechanisms to use the proof-of-possession terminology. >>=20 >> We also expect an updated version of the dynamic client registration >> spec incorporating last call feedback within about 2 weeks. >>=20 >> We would like you to think about adding the following milestones to the >> charter as part of the re-chartering effort: >>=20 >> ----- >>=20 >> Nov 2014 Submit 'Token introspection' to the IESG for consideration as a >> Proposed Standard >> Starting point: >>=20 >> Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as >> a Proposed Standard >> Starting point: >>=20 >> Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a >> Proposed Standard >> Starting point: >>=20 >> ----- >>=20 >> We also updated the charter text to reflect the current situation. Here >> is the proposed text: >>=20 >> ----- >>=20 >> Charter for Working Group >>=20 >>=20 >> The Web Authorization (OAuth) protocol allows a user to grant a >> third-party Web site or application access to the user's protected >> resources, without necessarily revealing their long-term credentials, >> or even their identity. For example, a photo-sharing site that >> supports OAuth could allow its users to use a third-party printing Web >> site to print their private pictures, without allowing the printing >> site to gain full control of the user's account and without having the >> user share his or her photo-sharing sites' long-term credential with >> the printing site. >>=20 >> The OAuth 2.0 protocol suite encompasses >>=20 >> * a protocol for obtaining access tokens from an authorization >> server with the resource owner's consent, >> * protocols for presenting these access tokens to resource server >> for access to a protected resource, >> * guidance for securely using OAuth 2.0, >> * the ability to revoke access tokens, >> * standardized format for security tokens encoded in a JSON format >> (JSON Web Token, JWT), >> * ways of using assertions with OAuth, and >> * a dynamic client registration protocol. >>=20 >> The working group also developed security schemes for presenting >> authorization tokens to access a protected resource. This led to the >> publication of the bearer token, as well as work that remains to be >> completed on proof-of-possession and token exchange. >>=20 >> The ongoing standardization effort within the OAuth working group will >> focus on enhancing interoperability and functionality of OAuth >> deployments, such as a standard for a token introspection service and >> standards for additional security of OAuth requests. >>=20 >> ----- >>=20 >> Feedback appreciated. >>=20 >> Ciao >> Hannes & Derek >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 > =09 > Brian Campbell > Portfolio Architect > @ bcampbell@pingidentity.com > +1 720.317.2061 > Connect with us=E2=80=A6 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-3A1A9F3E-5773-480E-9672-130CE5EED0EE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I know a number of people implementing=

<= br>
Having it on a RFC track may make sense. 

=
I remain to be convinced that a4c ads anything other than confusion.&nb= sp;

If the WG wants to take it up it should be alig= ned with Connect.  I think there are more important things to spend tim= e on. 


Sent from my iPhone

O= n May 14, 2014, at 2:24 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to 'OAuth Authent= ication' being picked up by the WG as a work item. The starting point draft h= as expired and it hasn't really been discusses since Berlin nearly a year ag= o.  As I recall, there was only very limited interest in it even then. I= also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03<= /a> - it's a relativity simple security enhancement which addresses problems= currently being encountered in deployments of native clients. 




= On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig= @gmx.net> wrote:
Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
= security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
= Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--
3D"Ping =09
Br= ian Campbell
Portfolio Architect =09
@ bcampbell@pingidentity.com
+1 720.317.2061
Con= nect with us=E2=80=A6
3D"twitter 3D"youtube 3D"Facebook= 3D"Google+ 3D"slideshare 3D= 3D"rss
3D"Register<= /td>

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-3A1A9F3E-5773-480E-9672-130CE5EED0EE-- --Apple-Mail-44BF63E5-7387-40AC-9D85-FE30EC8D03B2 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwNTE0MTc1OTE1WjAjBgkqhkiG9w0BCQQxFgQUabaJjgscuwVcoY/6 KucGuj9JTT0wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAhIZluZWfYHHNsFO6lZQ3qtUX8YzDWh/IzAbqKARZgoYPJ2oj xqUeSIAm/We9GNOP15KbnL7S+T51Ttn+T2eXIHzF0LzZ1Lv6AZuPA71suuEwLCt0YD8dO15dXo3M dMTDmnDvVBWMOiJQRwRCDKXtWHNnxCtpCEj/8pCXkaefzNUb3KhHo5enrdCwQaftbfnMa7QfCfH3 NcyMeD0gEdkyMliCeHkYcRPEbv/6jnUGaSENBkL+uoIWtNC46iAE7xBDlPIEFbKaSNpOXQXtS4ZJ oxM01o7g3Uo12orN134RYNek/oMb4OtjdEEHRmGKnerilr8YsBZhPGrgN2JFg+GS0gAAAAAAAA== --Apple-Mail-44BF63E5-7387-40AC-9D85-FE30EC8D03B2-- From nobody Wed May 14 11:20:02 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8541A0178 for ; Wed, 14 May 2014 11:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 WqbwvrrrmMk9 for ; Wed, 14 May 2014 11:19:55 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 762EC1A012F for ; Wed, 14 May 2014 11:19:52 -0700 (PDT) Received: from BY2PR03CA028.namprd03.prod.outlook.com (10.242.234.149) by BY2PR03MB586.namprd03.prod.outlook.com (10.141.143.19) with Microsoft SMTP Server (TLS) id 15.0.939.12; Wed, 14 May 2014 18:19:45 +0000 Received: from BN1BFFO11FD025.protection.gbl (2a01:111:f400:7c10::1:155) by BY2PR03CA028.outlook.office365.com (2a01:111:e400:2c2c::21) with Microsoft SMTP Server (TLS) id 15.0.944.11 via Frontend Transport; Wed, 14 May 2014 18:19:44 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD025.mail.protection.outlook.com (10.58.144.88) with Microsoft SMTP Server (TLS) id 15.0.939.9 via Frontend Transport; Wed, 14 May 2014 18:19:44 +0000 Received: from TK5EX14MBXC293.redmond.corp.microsoft.com ([169.254.2.113]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0181.007; Wed, 14 May 2014 18:19:05 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JWT and JOSE have won a Special European Identity Award Thread-Index: Ac9voP4YokPL/tCKRyqbZl2IebRBwA== Date: Wed, 14 May 2014 18:19:04 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD229CD@TK5EX14MBXC293.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD229CDTK5EX14MBXC293r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438001)(51914003)(189002)(199002)(92726001)(21056001)(81342001)(46102001)(77982001)(86612001)(54356999)(86362001)(19625215002)(4396001)(31966008)(15975445006)(79102001)(74502001)(83072002)(81542001)(44976005)(92566001)(83322001)(97736001)(20776003)(16297215004)(50986999)(81156002)(87936001)(84676001)(66066001)(6806004)(74662001)(15202345003)(71186001)(19580395003)(26826002)(68736004)(55846006)(33656001)(512954002)(64706001)(16236675002)(99396002)(19300405004)(84326002)(2009001)(2656002)(76482001)(80022001)(69596002)(85852003)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB586; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0211965D06 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/hgiPQDgTzpZQOEbIqsKkrPTEJ2A Subject: [OAUTH-WG] JWT and JOSE have won a Special European Identity Award X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 18:19:58 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD229CDTK5EX14MBXC293r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Today the JSON Web Token (JWT) and JSON Object Signing and Encryption (JOSE= ) specifications were granted a Special European Identity Award for Best In= novation for Security in the API Economy. I was honored to accept the awar= d, along with Nat Sakimura and John Bradley, on behalf of the contributors = to and implementers of these specifications at the European Identity and Cl= oud Conference. It's great to see this recognition for the impact that these specs are havi= ng by making it easy to use simple JSON-based security tokens and other Web= -friendly cryptographically protected data structures. Special thanks are = due to all of you have built and deployed implementations and provided feed= back on the specs throughout their development; they significantly benefitt= ed from your active involvement! These specifications are: * JSON Web Token (JWT) * JSON Web Signature (JWS) * JSON Web Encryption (JWE) * JSON Web Key (JWK) * JSON Web Algorithms (JWA) The authors are: * John Bradley * Joe Hildebrand * Michael B. Jones * Nat Sakimura Dirk Balfanz, Yaron Goland, John Panzer, and Eric = Rescorla also deserve thanks for their significant co= ntributions to creating these specifications. -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1223 and as= @selfissued. --_000_4E1F6AAD24975D4BA5B16804296739439AD229CDTK5EX14MBXC293r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Today the JSON Web Token (JWT) and JSON Object Signi= ng and Encryption (JOSE) specifications were granted a Special European Ide= ntity Award for Best Innovation for Security in the API Economy.  I wa= s honored to accept the award, along with Nat Sakimura and John Bradley, on behalf of the contributors to and implem= enters of these specifications at the European Identity and Cloud Conf= erence.

 

It’s great to see this recognition for the imp= act that these specs are having by making it easy to use simple JSON-based = security tokens and other Web-friendly cryptographically protected data str= uctures.  Special thanks are due to all of you have built and deployed implementations and provided feedback on th= e specs throughout their development; they significantly benefitted from yo= ur active involvement!

 

These specifications are:

·        JSON Web Token (JWT)

·        JSON Web Signature (JWS)

·        JSON Web Encryption (JWE)

·        JSON Web Key (JWK)

·        JSON Web Algorithms (JWA)

 

The authors are:

·        John= Bradley

·        Joe H= ildebrand

·        Michael= B. Jones

·        Nat Sak= imura     

 

Dirk Balfanz, Yaron Goland, John Panzer, and Eric Rescorla als= o deserve thanks for their significant contributions to creating these spec= ifications.

 

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

 

P.S.  This note was also posted at http://self-issued.info/?p=3D1223 and as @selfissued.

 

--_000_4E1F6AAD24975D4BA5B16804296739439AD229CDTK5EX14MBXC293r_-- From nobody Wed May 14 13:20:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701351A01AB for ; Wed, 14 May 2014 13:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 rwsxiyw4s3Ps for ; Wed, 14 May 2014 13:20:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) by ietfa.amsl.com (Postfix) with ESMTP id BA9901A0190 for ; Wed, 14 May 2014 13:20:06 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB205.namprd02.prod.outlook.com (10.242.165.139) with Microsoft SMTP Server (TLS) id 15.0.939.12; Wed, 14 May 2014 20:19:57 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.236]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.236]) with mapi id 15.00.0939.000; Wed, 14 May 2014 20:19:57 +0000 From: Antonio Sanso To: Mike Jones Thread-Topic: [OAUTH-WG] JWT and JOSE have won a Special European Identity Award Thread-Index: Ac9voP4YmMeygFbPSlS6hXyIq5bS6AAEOBqA Date: Wed, 14 May 2014 20:19:56 +0000 Message-ID: <2CBC08E5-F8DB-4695-A699-BC999B04C4AB@adobe.com> References: <4E1F6AAD24975D4BA5B16804296739439AD229CD@TK5EX14MBXC293.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD229CD@TK5EX14MBXC293.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.83.47.250] x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(51914003)(189002)(199002)(377454003)(24454002)(15975445006)(15202345003)(54356999)(2656002)(74662001)(31966008)(101416001)(76176999)(50986999)(76482001)(74502001)(83716003)(82746002)(19580405001)(19580395003)(87936001)(92566001)(46102001)(92726001)(80022001)(83322001)(77982001)(79102001)(20776003)(83072002)(1511001)(81542001)(16236675002)(85852003)(33656001)(81342001)(36756003)(21056001)(86362001)(99286001)(64706001)(66066001)(4396001)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB205; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; Content-Type: multipart/alternative; boundary="_000_2CBC08E5F8DB4695A699BC999B04C4ABadobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/MzB9-TI2VsAGB13j3mEE5U7eV-4 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWT and JOSE have won a Special European Identity Award X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 20:20:10 -0000 --_000_2CBC08E5F8DB4695A699BC999B04C4ABadobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable nice one Mike et al!! well deserved! regards antonio On May 14, 2014, at 8:19 PM, Mike Jones > wrote: Today the JSON Web Token (JWT) and JSON Object Signing and Encryption (JOSE= ) specifications were granted a Special European Identity Award for Best In= novation for Security in the API Economy. I was honored to accept the awar= d, along with Nat Sakimura and John Bradley, on behalf of the contributors = to and implementers of these specifications at the European Identity and Cl= oud Conference. It=92s great to see this recognition for the impact that these specs are ha= ving by making it easy to use simple JSON-based security tokens and other W= eb-friendly cryptographically protected data structures. Special thanks ar= e due to all of you have built and deployed implementations and provided fe= edback on the specs throughout their development; they significantly benefi= tted from your active involvement! These specifications are: =95 JSON Web Token (JWT) =95 JSON Web Signature (JWS) =95 JSON Web Encryption (JWE) =95 JSON Web Key (JWK) =95 JSON Web Algorithms (JWA) The authors are: =95 John Bradley =95 Joe Hildebrand =95 Michael B. Jones =95 Nat Sakimura Dirk Balfanz, Yaron Goland, John Panzer, and Eric = Rescorla also deserve thanks for their significant co= ntributions to creating these specifications. -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1223 and as= @selfissued. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_2CBC08E5F8DB4695A699BC999B04C4ABadobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <19F40C1E10C42F4DABF41FA52B89C60A@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable nice one Mike et al!! 

well deserved!

regards

antonio

On May 14, 2014, at 8:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Today the JSON Web Token (JWT) and JSON Object Signing and Encryption (JOSE= ) specifications were granted a Special European Identity Award for Best In= novation for Security in the API Economy.  I was honored to accept the= award, along with Nat Sakimura and John Bradley, on behalf of the contributors to and implementers of these specif= ications at the European Identity and Cloud Conference.
 
It=92s great to see this recognition for the impact that these specs are ha= ving by making it easy to use simple JSON-based security tokens and other W= eb-friendly cryptographically protected data structures.  Special than= ks are due to all of you have built and deployed implementations and provided feedback on the specs throughout the= ir development; they significantly benefitted from your active involvement!=
 
These specifications are:
=B7     &= nbsp;  JSON Web Token (JWT)
=B7     &= nbsp;  JSON Web Signature (JWS)
=B7     &= nbsp;  JSON Web Encryption (JWE)
=B7     &= nbsp;  JSON Web Key (JWK)
=B7     &= nbsp;  JSON Web Algorithms (JWA)
 
The authors are:
=B7     &= nbsp;  John Bradley
=B7     &= nbsp;  Joe Hildebrand
=B7     &= nbsp;  Michael B. Jones
=B7     &= nbsp;  Nat Sakimura     
 
Dirk Balfanz, Yaron Goland, John Panzer, and Eric Rescorla als= o deserve thanks for their significant contributions to creating these specifications.
 
            &nb= sp;            =             &nb= sp;            =           -- Mike
 
P.S.  This note was also posted at http://self-issued.info/?p=3D1223 and as @selfissued.
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th

--_000_2CBC08E5F8DB4695A699BC999B04C4ABadobecom_-- From nobody Wed May 14 14:17:02 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AF41A01E3 for ; Wed, 14 May 2014 14:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 uXCbST6krFYj for ; Wed, 14 May 2014 14:16:50 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 411831A01E1 for ; Wed, 14 May 2014 14:16:50 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) with Microsoft SMTP Server (TLS) id 15.0.949.11; Wed, 14 May 2014 21:16:42 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0949.001; Wed, 14 May 2014 21:16:42 +0000 From: Anthony Nadalin To: John Bradley , Brian Campbell Thread-Topic: [OAUTH-WG] OAuth Milestone Update and Rechartering Thread-Index: AQHPawEbu8OzlywPcU+RkLqz+fSkNptACOgAgABdhACAADcWgA== Date: Wed, 14 May 2014 21:16:41 +0000 Message-ID: <5bc620f21ba6446e8925476d4646bad5@BLUPR03MB309.namprd03.prod.outlook.com> References: <536BF140.5070106@gmx.net> <60BC637A-FD8D-4C92-A94C-93F89E868CB9@ve7jtb.com> In-Reply-To: <60BC637A-FD8D-4C92-A94C-93F89E868CB9@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [195.50.165.102] x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(24454002)(189002)(199002)(377454003)(53754006)(19617315010)(83072002)(86362001)(85852003)(76576001)(92566001)(19618635001)(50986999)(19300405004)(19273905006)(19625215002)(15198665003)(15202345003)(77096999)(16236675002)(15395725003)(2656002)(76176999)(87936001)(64706001)(74502001)(81542001)(81342001)(31966008)(15975445006)(20776003)(76482001)(101416001)(80022001)(66066001)(77982001)(74662001)(46102001)(4396001)(21056001)(99286001)(79102001)(74316001)(33646001)(54356999)(19609705001)(19580395003)(19580405001)(83322001)(18206015023)(86612001)(42262001)(9984715005)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB309; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; Content-Type: multipart/alternative; boundary="_000_5bc620f21ba6446e8925476d4646bad5BLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Gb3Q5NC9iwfe_uRdz2KJZkexYGI Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 21:16:55 -0000 --_000_5bc620f21ba6446e8925476d4646bad5BLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIGxpc3QgdGhlIGltcGxlbWVudHN0aW9ucw0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2huIEJyYWRsZXkNClNlbnQ6IFdl ZG5lc2RheSwgTWF5IDE0LCAyMDE0IDEwOjU5IEFNDQpUbzogQnJpYW4gQ2FtcGJlbGwNCkNjOiBv YXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggTWlsZXN0b25lIFVw ZGF0ZSBhbmQgUmVjaGFydGVyaW5nDQoNCkkga25vdyBhIG51bWJlciBvZiBwZW9wbGUgaW1wbGVt ZW50aW5nDQoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1 dGgtdGNzZS0wMw0KDQpIYXZpbmcgaXQgb24gYSBSRkMgdHJhY2sgbWF5IG1ha2Ugc2Vuc2UuDQoN CkkgcmVtYWluIHRvIGJlIGNvbnZpbmNlZCB0aGF0IGE0YyBhZHMgYW55dGhpbmcgb3RoZXIgdGhh biBjb25mdXNpb24uDQoNCklmIHRoZSBXRyB3YW50cyB0byB0YWtlIGl0IHVwIGl0IHNob3VsZCBi ZSBhbGlnbmVkIHdpdGggQ29ubmVjdC4gIEkgdGhpbmsgdGhlcmUgYXJlIG1vcmUgaW1wb3J0YW50 IHRoaW5ncyB0byBzcGVuZCB0aW1lIG9uLg0KDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24g TWF5IDE0LCAyMDE0LCBhdCAyOjI0IFBNLCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQpJ IHdvdWxkIG9iamVjdCB0byAnT0F1dGggQXV0aGVudGljYXRpb24nIGJlaW5nIHBpY2tlZCB1cCBi eSB0aGUgV0cgYXMgYSB3b3JrIGl0ZW0uIFRoZSBzdGFydGluZyBwb2ludCBkcmFmdCBoYXMgZXhw aXJlZCBhbmQgaXQgaGFzbid0IHJlYWxseSBiZWVuIGRpc2N1c3NlcyBzaW5jZSBCZXJsaW4gbmVh cmx5IGEgeWVhciBhZ28uICBBcyBJIHJlY2FsbCwgdGhlcmUgd2FzIG9ubHkgdmVyeSBsaW1pdGVk IGludGVyZXN0IGluIGl0IGV2ZW4gdGhlbi4gSSBhbHNvIGRvbid0IGJlbGlldmUgaXQgZml0cyB3 ZWxsIHdpdGggdGhlIFdHIGNoYXJ0ZXIuDQoNCkkgd291bGQgc3VnZ2VzdCB0aGUgV0cgY29uc2lk ZXIgcGlja2luZyB1cCAnT0F1dGggU3ltbWV0cmljIFByb29mIG9mIFBvc3Nlc3Npb24gZm9yIENv ZGUgRXh0ZW5zaW9uJyBmb3Igd2hpY2ggdGhlcmUgaXMgYW4gZXhjZWxsZW50IHN0YXJ0aW5nIHBv aW50IG9mIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLXRj c2UtMDMgLSBpdCdzIGEgcmVsYXRpdml0eSBzaW1wbGUgc2VjdXJpdHkgZW5oYW5jZW1lbnQgd2hp Y2ggYWRkcmVzc2VzIHByb2JsZW1zIGN1cnJlbnRseSBiZWluZyBlbmNvdW50ZXJlZCBpbiBkZXBs b3ltZW50cyBvZiBuYXRpdmUgY2xpZW50cy4NCg0KDQpPbiBUaHUsIE1heSA4LCAyMDE0IGF0IDM6 MDQgUE0sIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PG1haWx0 bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj4gd3JvdGU6DQpIaSBhbGwsDQoNCnlvdSBtaWdo dCBoYXZlIHNlZW4gdGhhdCB3ZSBwdXNoZWQgdGhlIGFzc2VydGlvbiBkb2N1bWVudHMgYW5kIHRo ZSBKV1QNCmRvY3VtZW50cyB0byB0aGUgSUVTRyB0b2RheS4gV2UgaGF2ZSBhbHNvIHVwZGF0ZWQg dGhlIG1pbGVzdG9uZXMgb24gdGhlDQpPQXV0aCBXRyBwYWdlLg0KDQpUaGlzIG1lYW5zIHRoYXQg d2UgY2FuIHBsYW4gdG8gcGljayB1cCBuZXcgd29yayBpbiB0aGUgZ3JvdXAuDQpXZSBoYXZlIHNl bnQgYSByZXF1ZXN0IHRvIEthdGhsZWVuIHRvIGNoYW5nZSB0aGUgbWlsZXN0b25lIGZvciB0aGUg T0F1dGgNCnNlY3VyaXR5IG1lY2hhbmlzbXMgdG8gdXNlIHRoZSBwcm9vZi1vZi1wb3NzZXNzaW9u IHRlcm1pbm9sb2d5Lg0KDQpXZSBhbHNvIGV4cGVjdCBhbiB1cGRhdGVkIHZlcnNpb24gb2YgdGhl IGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbg0Kc3BlYyBpbmNvcnBvcmF0aW5nIGxhc3QgY2Fs bCBmZWVkYmFjayB3aXRoaW4gYWJvdXQgMiB3ZWVrcy4NCg0KV2Ugd291bGQgbGlrZSB5b3UgdG8g dGhpbmsgYWJvdXQgYWRkaW5nIHRoZSBmb2xsb3dpbmcgbWlsZXN0b25lcyB0byB0aGUNCmNoYXJ0 ZXIgYXMgcGFydCBvZiB0aGUgcmUtY2hhcnRlcmluZyBlZmZvcnQ6DQoNCi0tLS0tDQoNCk5vdiAy MDE0IFN1Ym1pdCAnVG9rZW4gaW50cm9zcGVjdGlvbicgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVy YXRpb24gYXMgYQ0KUHJvcG9zZWQgU3RhbmRhcmQNClN0YXJ0aW5nIHBvaW50OiA8ZHJhZnQtcmlj aGVyLW9hdXRoLWludHJvc3BlY3Rpb24tMDQ+DQoNCkphbiAyMDE1IFN1Ym1pdCAnT0F1dGggQXV0 aGVudGljYXRpb24nIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzDQphIFByb3Bvc2Vk IFN0YW5kYXJkDQpTdGFydGluZyBwb2ludDogPGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMt MDE+DQoNCkphbiAyMDE1IFN1Ym1pdCAnVG9rZW4gRXhjaGFuZ2UnIHRvIHRoZSBJRVNHIGZvciBj b25zaWRlcmF0aW9uIGFzIGENClByb3Bvc2VkIFN0YW5kYXJkDQpTdGFydGluZyBwb2ludDogPGRy YWZ0LWpvbmVzLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAwPg0KDQotLS0tLQ0KDQpXZSBhbHNvIHVw ZGF0ZWQgdGhlIGNoYXJ0ZXIgdGV4dCB0byByZWZsZWN0IHRoZSBjdXJyZW50IHNpdHVhdGlvbi4g SGVyZQ0KaXMgdGhlIHByb3Bvc2VkIHRleHQ6DQoNCi0tLS0tDQoNCkNoYXJ0ZXIgZm9yIFdvcmtp bmcgR3JvdXANCg0KDQpUaGUgV2ViIEF1dGhvcml6YXRpb24gKE9BdXRoKSBwcm90b2NvbCBhbGxv d3MgYSB1c2VyIHRvIGdyYW50IGENCnRoaXJkLXBhcnR5IFdlYiBzaXRlIG9yIGFwcGxpY2F0aW9u IGFjY2VzcyB0byB0aGUgdXNlcidzIHByb3RlY3RlZA0KcmVzb3VyY2VzLCB3aXRob3V0IG5lY2Vz c2FyaWx5IHJldmVhbGluZyB0aGVpciBsb25nLXRlcm0gY3JlZGVudGlhbHMsDQpvciBldmVuIHRo ZWlyIGlkZW50aXR5LiBGb3IgZXhhbXBsZSwgYSBwaG90by1zaGFyaW5nIHNpdGUgdGhhdA0Kc3Vw cG9ydHMgT0F1dGggY291bGQgYWxsb3cgaXRzIHVzZXJzIHRvIHVzZSBhIHRoaXJkLXBhcnR5IHBy aW50aW5nIFdlYg0Kc2l0ZSB0byBwcmludCB0aGVpciBwcml2YXRlIHBpY3R1cmVzLCB3aXRob3V0 IGFsbG93aW5nIHRoZSBwcmludGluZw0Kc2l0ZSB0byBnYWluIGZ1bGwgY29udHJvbCBvZiB0aGUg dXNlcidzIGFjY291bnQgYW5kIHdpdGhvdXQgaGF2aW5nIHRoZQ0KdXNlciBzaGFyZSBoaXMgb3Ig aGVyIHBob3RvLXNoYXJpbmcgc2l0ZXMnIGxvbmctdGVybSBjcmVkZW50aWFsIHdpdGgNCnRoZSBw cmludGluZyBzaXRlLg0KDQpUaGUgT0F1dGggMi4wIHByb3RvY29sIHN1aXRlIGVuY29tcGFzc2Vz DQoNCiogYSBwcm90b2NvbCBmb3Igb2J0YWluaW5nIGFjY2VzcyB0b2tlbnMgZnJvbSBhbiBhdXRo b3JpemF0aW9uDQpzZXJ2ZXIgd2l0aCB0aGUgcmVzb3VyY2Ugb3duZXIncyBjb25zZW50LA0KKiBw cm90b2NvbHMgZm9yIHByZXNlbnRpbmcgdGhlc2UgYWNjZXNzIHRva2VucyB0byByZXNvdXJjZSBz ZXJ2ZXINCmZvciBhY2Nlc3MgdG8gYSBwcm90ZWN0ZWQgcmVzb3VyY2UsDQoqIGd1aWRhbmNlIGZv ciBzZWN1cmVseSB1c2luZyBPQXV0aCAyLjAsDQoqIHRoZSBhYmlsaXR5IHRvIHJldm9rZSBhY2Nl c3MgdG9rZW5zLA0KKiBzdGFuZGFyZGl6ZWQgZm9ybWF0IGZvciBzZWN1cml0eSB0b2tlbnMgZW5j b2RlZCBpbiBhIEpTT04gZm9ybWF0DQogIChKU09OIFdlYiBUb2tlbiwgSldUKSwNCiogd2F5cyBv ZiB1c2luZyBhc3NlcnRpb25zIHdpdGggT0F1dGgsIGFuZA0KKiBhIGR5bmFtaWMgY2xpZW50IHJl Z2lzdHJhdGlvbiBwcm90b2NvbC4NCg0KVGhlIHdvcmtpbmcgZ3JvdXAgYWxzbyBkZXZlbG9wZWQg c2VjdXJpdHkgc2NoZW1lcyBmb3IgcHJlc2VudGluZw0KYXV0aG9yaXphdGlvbiB0b2tlbnMgdG8g YWNjZXNzIGEgcHJvdGVjdGVkIHJlc291cmNlLiBUaGlzIGxlZCB0byB0aGUNCnB1YmxpY2F0aW9u IG9mIHRoZSBiZWFyZXIgdG9rZW4sIGFzIHdlbGwgYXMgd29yayB0aGF0IHJlbWFpbnMgdG8gYmUN CmNvbXBsZXRlZCBvbiBwcm9vZi1vZi1wb3NzZXNzaW9uIGFuZCB0b2tlbiBleGNoYW5nZS4NCg0K VGhlIG9uZ29pbmcgc3RhbmRhcmRpemF0aW9uIGVmZm9ydCB3aXRoaW4gdGhlIE9BdXRoIHdvcmtp bmcgZ3JvdXAgd2lsbA0KZm9jdXMgb24gZW5oYW5jaW5nIGludGVyb3BlcmFiaWxpdHkgYW5kIGZ1 bmN0aW9uYWxpdHkgb2YgT0F1dGgNCmRlcGxveW1lbnRzLCBzdWNoIGFzIGEgc3RhbmRhcmQgZm9y IGEgdG9rZW4gaW50cm9zcGVjdGlvbiBzZXJ2aWNlIGFuZA0Kc3RhbmRhcmRzIGZvciBhZGRpdGlv bmFsIHNlY3VyaXR5IG9mIE9BdXRoIHJlcXVlc3RzLg0KDQotLS0tLQ0KDQpGZWVkYmFjayBhcHBy ZWNpYXRlZC4NCg0KQ2lhbw0KSGFubmVzICYgRGVyZWsNCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRo QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpbUGluZyBJZGVudGl0eSBsb2dvXTxodHRw czovL3d3dy5waW5naWRlbnRpdHkuY29tLz4NCg0KQnJpYW4gQ2FtcGJlbGwNClBvcnRmb2xpbyBB cmNoaXRlY3QNCkANCg0KYmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPg0KDQpbcGhvbmVdDQoNCisxIDcyMC4zMTcuMjA2MQ0KDQpDb25u ZWN0IHdpdGggdXPigKYNCg0KW3R3aXR0ZXIgbG9nb108aHR0cHM6Ly90d2l0dGVyLmNvbS9waW5n aWRlbnRpdHk+W3lvdXR1YmUgbG9nb108aHR0cHM6Ly93d3cueW91dHViZS5jb20vdXNlci9QaW5n SWRlbnRpdHlUVj5bTGlua2VkSW4gbG9nb108aHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2NvbXBh bnkvMjE4NzA+W0ZhY2Vib29rIGxvZ29dPGh0dHBzOi8vd3d3LmZhY2Vib29rLmNvbS9waW5naWRl bnRpdHlwYWdlPltHb29nbGUrIGxvZ29dPGh0dHBzOi8vcGx1cy5nb29nbGUuY29tL3UvMC8xMTQy NjY5Nzc3MzkzOTc3MDg1NDA+W3NsaWRlc2hhcmUgbG9nb108aHR0cDovL3d3dy5zbGlkZXNoYXJl Lm5ldC9QaW5nSWRlbnRpdHk+W2ZsaXBib2FyZCBsb2dvXTxodHRwOi8vZmxpcC5pdC92akJGNz5b cnNzIGZlZWQgaWNvbl08aHR0cHM6Ly93d3cucGluZ2lkZW50aXR5LmNvbS9ibG9ncy8+DQoNCg0K W1JlZ2lzdGVyIGZvciBDbG91ZCBJZGVudGl0eSBTdW1taXQgMjAxNCB8IE1vZGVybiBJZGVudGl0 eSBSZXZvbHV0aW9uIHwgMTnigJMyMyBKdWx5LCAyMDE0IHwgTW9udGVyZXksIENBXTxodHRwczov L3d3dy5jbG91ZGlkZW50aXR5c3VtbWl0LmNvbS8+DQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0 Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aA0K --_000_5bc620f21ba6446e8925476d4646bad5BLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVhc2UgbGlz dCB0aGUgaW1wbGVtZW50c3Rpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPkpvaG4gQnJhZGxleTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNk YXksIE1heSAxNCwgMjAxNCAxMDo1OSBBTTxicj4NCjxiPlRvOjwvYj4gQnJpYW4gQ2FtcGJlbGw8 YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb T0FVVEgtV0ddIE9BdXRoIE1pbGVzdG9uZSBVcGRhdGUgYW5kIFJlY2hhcnRlcmluZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGtub3cgYSBu dW1iZXIgb2YgcGVvcGxlIGltcGxlbWVudGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC10Y3NlLTAzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtdGNzZS0wMzwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IYXZpbmcgaXQgb24gYSBSRkMgdHJhY2sgbWF5IG1ha2Ugc2Vuc2UuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcmVtYWluIHRv IGJlIGNvbnZpbmNlZCB0aGF0IGE0YyBhZHMgYW55dGhpbmcgb3RoZXIgdGhhbiBjb25mdXNpb24u Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPklmIHRoZSBXRyB3YW50cyB0byB0YWtlIGl0IHVwIGl0IHNob3VsZCBiZSBhbGlnbmVkIHdp dGggQ29ubmVjdC4gJm5ic3A7SSB0aGluayB0aGVyZSBhcmUgbW9yZSBpbXBvcnRhbnQgdGhpbmdz IHRvIHNwZW5kIHRpbWUgb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClNlbnQgZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KT24gTWF5IDE0LCAyMDE0LCBhdCAyOjI0IFBNLCBCcmlhbiBD YW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj5i Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5JIHdvdWxkIG9iamVjdCB0byAnT0F1dGggQXV0aGVudGljYXRpb24n IGJlaW5nIHBpY2tlZCB1cCBieSB0aGUgV0cgYXMgYSB3b3JrIGl0ZW0uIFRoZSBzdGFydGluZyBw b2ludCBkcmFmdCBoYXMgZXhwaXJlZCBhbmQgaXQgaGFzbid0IHJlYWxseSBiZWVuIGRpc2N1c3Nl cyBzaW5jZSBCZXJsaW4gbmVhcmx5IGEgeWVhciBhZ28uJm5ic3A7IEFzIEkgcmVjYWxsLCB0aGVy ZQ0KIHdhcyBvbmx5IHZlcnkgbGltaXRlZCBpbnRlcmVzdCBpbiBpdCBldmVuIHRoZW4uIEkgYWxz byBkb24ndCBiZWxpZXZlIGl0IGZpdHMgd2VsbCB3aXRoIHRoZSBXRyBjaGFydGVyLjxicj4NCjxi cj4NCkkgd291bGQgc3VnZ2VzdCB0aGUgV0cgY29uc2lkZXIgcGlja2luZyB1cCAnT0F1dGggU3lt bWV0cmljIFByb29mIG9mIFBvc3Nlc3Npb24gZm9yIENvZGUgRXh0ZW5zaW9uJyBmb3Igd2hpY2gg dGhlcmUgaXMgYW4gZXhjZWxsZW50IHN0YXJ0aW5nIHBvaW50IG9mDQo8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC10Y3NlLTAzIiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0 aC10Y3NlLTAzPC9hPiAtIGl0J3MgYSByZWxhdGl2aXR5IHNpbXBsZSBzZWN1cml0eSBlbmhhbmNl bWVudCB3aGljaCBhZGRyZXNzZXMgcHJvYmxlbXMgY3VycmVudGx5IGJlaW5nIGVuY291bnRlcmVk IGluIGRlcGxveW1lbnRzIG9mIG5hdGl2ZSBjbGllbnRzLiZuYnNwOw0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgTWF5IDgsIDIwMTQgYXQgMzowNCBQTSwgSGFubmVzIFRz Y2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0IiB0 YXJnZXQ9Il9ibGFuayI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgYWxsLDxicj4NCjxicj4NCnlvdSBtaWdodCBoYXZlIHNl ZW4gdGhhdCB3ZSBwdXNoZWQgdGhlIGFzc2VydGlvbiBkb2N1bWVudHMgYW5kIHRoZSBKV1Q8YnI+ DQpkb2N1bWVudHMgdG8gdGhlIElFU0cgdG9kYXkuIFdlIGhhdmUgYWxzbyB1cGRhdGVkIHRoZSBt aWxlc3RvbmVzIG9uIHRoZTxicj4NCk9BdXRoIFdHIHBhZ2UuPGJyPg0KPGJyPg0KVGhpcyBtZWFu cyB0aGF0IHdlIGNhbiBwbGFuIHRvIHBpY2sgdXAgbmV3IHdvcmsgaW4gdGhlIGdyb3VwLjxicj4N CldlIGhhdmUgc2VudCBhIHJlcXVlc3QgdG8gS2F0aGxlZW4gdG8gY2hhbmdlIHRoZSBtaWxlc3Rv bmUgZm9yIHRoZSBPQXV0aDxicj4NCnNlY3VyaXR5IG1lY2hhbmlzbXMgdG8gdXNlIHRoZSBwcm9v Zi1vZi1wb3NzZXNzaW9uIHRlcm1pbm9sb2d5Ljxicj4NCjxicj4NCldlIGFsc28gZXhwZWN0IGFu IHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uPGJyPg0K c3BlYyBpbmNvcnBvcmF0aW5nIGxhc3QgY2FsbCBmZWVkYmFjayB3aXRoaW4gYWJvdXQgMiB3ZWVr cy48YnI+DQo8YnI+DQpXZSB3b3VsZCBsaWtlIHlvdSB0byB0aGluayBhYm91dCBhZGRpbmcgdGhl IGZvbGxvd2luZyBtaWxlc3RvbmVzIHRvIHRoZTxicj4NCmNoYXJ0ZXIgYXMgcGFydCBvZiB0aGUg cmUtY2hhcnRlcmluZyBlZmZvcnQ6PGJyPg0KPGJyPg0KLS0tLS08YnI+DQo8YnI+DQpOb3YgMjAx NCBTdWJtaXQgJ1Rva2VuIGludHJvc3BlY3Rpb24nIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0 aW9uIGFzIGE8YnI+DQpQcm9wb3NlZCBTdGFuZGFyZDxicj4NClN0YXJ0aW5nIHBvaW50OiAmbHQ7 ZHJhZnQtcmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24tMDQmZ3Q7PGJyPg0KPGJyPg0KSmFuIDIw MTUgU3VibWl0ICdPQXV0aCBBdXRoZW50aWNhdGlvbicgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVy YXRpb24gYXM8YnI+DQphIFByb3Bvc2VkIFN0YW5kYXJkPGJyPg0KU3RhcnRpbmcgcG9pbnQ6ICZs dDtkcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTAxJmd0Ozxicj4NCjxicj4NCkphbiAyMDE1 IFN1Ym1pdCAnVG9rZW4gRXhjaGFuZ2UnIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFz IGE8YnI+DQpQcm9wb3NlZCBTdGFuZGFyZDxicj4NClN0YXJ0aW5nIHBvaW50OiAmbHQ7ZHJhZnQt am9uZXMtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDAmZ3Q7PGJyPg0KPGJyPg0KLS0tLS08YnI+DQo8 YnI+DQpXZSBhbHNvIHVwZGF0ZWQgdGhlIGNoYXJ0ZXIgdGV4dCB0byByZWZsZWN0IHRoZSBjdXJy ZW50IHNpdHVhdGlvbi4gSGVyZTxicj4NCmlzIHRoZSBwcm9wb3NlZCB0ZXh0Ojxicj4NCjxicj4N Ci0tLS0tPGJyPg0KPGJyPg0KQ2hhcnRlciBmb3IgV29ya2luZyBHcm91cDxicj4NCjxicj4NCjxi cj4NClRoZSBXZWIgQXV0aG9yaXphdGlvbiAoT0F1dGgpIHByb3RvY29sIGFsbG93cyBhIHVzZXIg dG8gZ3JhbnQgYTxicj4NCnRoaXJkLXBhcnR5IFdlYiBzaXRlIG9yIGFwcGxpY2F0aW9uIGFjY2Vz cyB0byB0aGUgdXNlcidzIHByb3RlY3RlZDxicj4NCnJlc291cmNlcywgd2l0aG91dCBuZWNlc3Nh cmlseSByZXZlYWxpbmcgdGhlaXIgbG9uZy10ZXJtIGNyZWRlbnRpYWxzLDxicj4NCm9yIGV2ZW4g dGhlaXIgaWRlbnRpdHkuIEZvciBleGFtcGxlLCBhIHBob3RvLXNoYXJpbmcgc2l0ZSB0aGF0PGJy Pg0Kc3VwcG9ydHMgT0F1dGggY291bGQgYWxsb3cgaXRzIHVzZXJzIHRvIHVzZSBhIHRoaXJkLXBh cnR5IHByaW50aW5nIFdlYjxicj4NCnNpdGUgdG8gcHJpbnQgdGhlaXIgcHJpdmF0ZSBwaWN0dXJl cywgd2l0aG91dCBhbGxvd2luZyB0aGUgcHJpbnRpbmc8YnI+DQpzaXRlIHRvIGdhaW4gZnVsbCBj b250cm9sIG9mIHRoZSB1c2VyJ3MgYWNjb3VudCBhbmQgd2l0aG91dCBoYXZpbmcgdGhlPGJyPg0K dXNlciBzaGFyZSBoaXMgb3IgaGVyIHBob3RvLXNoYXJpbmcgc2l0ZXMnIGxvbmctdGVybSBjcmVk ZW50aWFsIHdpdGg8YnI+DQp0aGUgcHJpbnRpbmcgc2l0ZS48YnI+DQo8YnI+DQpUaGUgT0F1dGgg Mi4wIHByb3RvY29sIHN1aXRlIGVuY29tcGFzc2VzPGJyPg0KPGJyPg0KKiBhIHByb3RvY29sIGZv ciBvYnRhaW5pbmcgYWNjZXNzIHRva2VucyBmcm9tIGFuIGF1dGhvcml6YXRpb248YnI+DQpzZXJ2 ZXIgd2l0aCB0aGUgcmVzb3VyY2Ugb3duZXIncyBjb25zZW50LDxicj4NCiogcHJvdG9jb2xzIGZv ciBwcmVzZW50aW5nIHRoZXNlIGFjY2VzcyB0b2tlbnMgdG8gcmVzb3VyY2Ugc2VydmVyPGJyPg0K Zm9yIGFjY2VzcyB0byBhIHByb3RlY3RlZCByZXNvdXJjZSw8YnI+DQoqIGd1aWRhbmNlIGZvciBz ZWN1cmVseSB1c2luZyBPQXV0aCAyLjAsPGJyPg0KKiB0aGUgYWJpbGl0eSB0byByZXZva2UgYWNj ZXNzIHRva2Vucyw8YnI+DQoqIHN0YW5kYXJkaXplZCBmb3JtYXQgZm9yIHNlY3VyaXR5IHRva2Vu cyBlbmNvZGVkIGluIGEgSlNPTiBmb3JtYXQ8YnI+DQombmJzcDsgKEpTT04gV2ViIFRva2VuLCBK V1QpLDxicj4NCiogd2F5cyBvZiB1c2luZyBhc3NlcnRpb25zIHdpdGggT0F1dGgsIGFuZDxicj4N CiogYSBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24gcHJvdG9jb2wuPGJyPg0KPGJyPg0KVGhl IHdvcmtpbmcgZ3JvdXAgYWxzbyBkZXZlbG9wZWQgc2VjdXJpdHkgc2NoZW1lcyBmb3IgcHJlc2Vu dGluZzxicj4NCmF1dGhvcml6YXRpb24gdG9rZW5zIHRvIGFjY2VzcyBhIHByb3RlY3RlZCByZXNv dXJjZS4gVGhpcyBsZWQgdG8gdGhlPGJyPg0KcHVibGljYXRpb24gb2YgdGhlIGJlYXJlciB0b2tl biwgYXMgd2VsbCBhcyB3b3JrIHRoYXQgcmVtYWlucyB0byBiZTxicj4NCmNvbXBsZXRlZCBvbiBw cm9vZi1vZi1wb3NzZXNzaW9uIGFuZCB0b2tlbiBleGNoYW5nZS48YnI+DQo8YnI+DQpUaGUgb25n b2luZyBzdGFuZGFyZGl6YXRpb24gZWZmb3J0IHdpdGhpbiB0aGUgT0F1dGggd29ya2luZyBncm91 cCB3aWxsPGJyPg0KZm9jdXMgb24gZW5oYW5jaW5nIGludGVyb3BlcmFiaWxpdHkgYW5kIGZ1bmN0 aW9uYWxpdHkgb2YgT0F1dGg8YnI+DQpkZXBsb3ltZW50cywgc3VjaCBhcyBhIHN0YW5kYXJkIGZv ciBhIHRva2VuIGludHJvc3BlY3Rpb24gc2VydmljZSBhbmQ8YnI+DQpzdGFuZGFyZHMgZm9yIGFk ZGl0aW9uYWwgc2VjdXJpdHkgb2YgT0F1dGggcmVxdWVzdHMuPGJyPg0KPGJyPg0KLS0tLS08YnI+ DQo8YnI+DQpGZWVkYmFjayBhcHByZWNpYXRlZC48YnI+DQo8YnI+DQpDaWFvPGJyPg0KSGFubmVz ICZhbXA7IERlcmVrPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8YnI+DQotLSA8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs cGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDo1OS4yNXB0Ij4NCjx0ZCB3 aWR0aD0iNzUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NTYuMjVwdDtwYWRkaW5nOi43NXB0 IC43NXB0IC43NXB0IC43NXB0O2hlaWdodDo1OS4yNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIGhyZWY9Imh0dHBzOi8vd3d3LnBpbmdpZGVudGl0eS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94 MDAwMF9pMTAyNSIgc3JjPSJodHRwOi8vNC5waW5naWRlbnRpdHkuY29tL3JzL3BpbmdpZGVudGl0 eS9pbWFnZXMvRVhQX1BJQ19zcXVhcmVfbG9nb19SR0Jfd2l0aF9oYXJkX2Ryb3AucG5nIiBhbHQ9 IlBpbmcgSWRlbnRpdHkgbG9nbyI+PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IDcuNXB0O2hl aWdodDo1OS4yNXB0Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbi1ib3R0b206NS4yNXB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0U2MUQz QyI+QnJpYW4gQ2FtcGJlbGw8L3NwYW4+PC9iPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPlBvcnRmb2xpbyBBcmNoaXRlY3Q8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBh ZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt cmlnaHQ6c29saWQgI0U2MUQzQyAxLjBwdDtwYWRkaW5nOjBpbiAzLjc1cHQgMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50 ZXIiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0U2MUQzQyI+QDwvc3Bhbj48 L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGlu IDIuMjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20i IHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXJpZ2h0OnNvbGlkICNFNjNDMUQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246 Y2VudGVyIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyNiIgc3JjPSJodHRwOi8vNC5w aW5naWRlbnRpdHkuY29tL3JzL3BpbmdpZGVudGl0eS9pbWFnZXMvRVhQX3Bob25lX2dseXBoLmdp ZiIgYWx0PSJwaG9uZSI+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBpbiAwaW4gMGluIDIuMjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mIzQzOzEgNzIwLjMxNy4yMDYxPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgY29sc3Bhbj0iMiIgc3R5bGU9InBh ZGRpbmc6MTEuMjVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5OTk5OTkiPkNvbm5lY3Qgd2l0aCB1c+KA pjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIGNvbHNwYW49 IjIiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vcGluZ2lkZW50aXR5IiB0YXJn ZXQ9Il9ibGFuayIgdGl0bGU9IlBpbmcgb24gVHdpdHRlciI+PHNwYW4gc3R5bGU9InRleHQtZGVj b3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyNyIgc3JjPSJodHRw Oi8vNC5waW5naWRlbnRpdHkuY29tL3JzL3BpbmdpZGVudGl0eS9pbWFnZXMvdHdpdHRlci5naWYi IGFsdD0idHdpdHRlciBsb2dvIj48L3NwYW4+PC9hPjxhIGhyZWY9Imh0dHBzOi8vd3d3LnlvdXR1 YmUuY29tL3VzZXIvUGluZ0lkZW50aXR5VFYiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUGluZyBv biBZb3VUdWJlIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVy PSIwIiBpZD0iX3gwMDAwX2kxMDI4IiBzcmM9Imh0dHA6Ly80LnBpbmdpZGVudGl0eS5jb20vcnMv cGluZ2lkZW50aXR5L2ltYWdlcy95b3V0dWJlLmdpZiIgYWx0PSJ5b3V0dWJlIGxvZ28iPjwvc3Bh bj48L2E+PGEgaHJlZj0iaHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2NvbXBhbnkvMjE4NzAiIHRh cmdldD0iX2JsYW5rIiB0aXRsZT0iUGluZyBvbiBMaW5rZWRJbiI+PHNwYW4gc3R5bGU9InRleHQt ZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyOSIgc3JjPSJo dHRwOi8vNC5waW5naWRlbnRpdHkuY29tL3JzL3BpbmdpZGVudGl0eS9pbWFnZXMvbGlua2VkaW4u Z2lmIiBhbHQ9IkxpbmtlZEluIGxvZ28iPjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cHM6Ly93d3cu ZmFjZWJvb2suY29tL3BpbmdpZGVudGl0eXBhZ2UiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUGlu ZyBvbiBGYWNlYm9vayI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJv cmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAzMCIgc3JjPSJodHRwOi8vNC5waW5naWRlbnRpdHkuY29t L3JzL3BpbmdpZGVudGl0eS9pbWFnZXMvZmFjZWJvb2suZ2lmIiBhbHQ9IkZhY2Vib29rIGxvZ28i Pjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cHM6Ly9wbHVzLmdvb2dsZS5jb20vdS8wLzExNDI2Njk3 NzczOTM5NzcwODU0MCIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSJQaW5nIG9uIEdvb2dsZSYjNDM7 Ij48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiBpZD0i X3gwMDAwX2kxMDMxIiBzcmM9Imh0dHA6Ly80LnBpbmdpZGVudGl0eS5jb20vcnMvcGluZ2lkZW50 aXR5L2ltYWdlcy9nb29nbGUlMkIuZ2lmIiBhbHQ9Ikdvb2dsZSYjNDM7IGxvZ28iPjwvc3Bhbj48 L2E+PGEgaHJlZj0iaHR0cDovL3d3dy5zbGlkZXNoYXJlLm5ldC9QaW5nSWRlbnRpdHkiIHRhcmdl dD0iX2JsYW5rIiB0aXRsZT0iUGluZyBvbiBTbGlkZVNoYXJlIj48c3BhbiBzdHlsZT0idGV4dC1k ZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDMyIiBzcmM9Imh0 dHA6Ly80LnBpbmdpZGVudGl0eS5jb20vcnMvcGluZ2lkZW50aXR5L2ltYWdlcy9zbGlkZXNoYXJl LmdpZiIgYWx0PSJzbGlkZXNoYXJlIGxvZ28iPjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cDovL2Zs aXAuaXQvdmpCRjciIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUGluZyBvbiBGbGlwYm9hcmQiPjxz cGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIGlkPSJfeDAw MDBfaTEwMzMiIHNyYz0iaHR0cDovLzQucGluZ2lkZW50aXR5LmNvbS9ycy9waW5naWRlbnRpdHkv aW1hZ2VzL2ZsaXBib2FyZC5naWYiIGFsdD0iZmxpcGJvYXJkIGxvZ28iPjwvc3Bhbj48L2E+PGEg aHJlZj0iaHR0cHM6Ly93d3cucGluZ2lkZW50aXR5LmNvbS9ibG9ncy8iIHRhcmdldD0iX2JsYW5r IiB0aXRsZT0iUGluZyBibG9ncyI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj48 aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAzNCIgc3JjPSJodHRwOi8vNC5waW5naWRlbnRp dHkuY29tL3JzL3BpbmdpZGVudGl0eS9pbWFnZXMvcnNzLmdpZiIgYWx0PSJyc3MgZmVlZCBpY29u Ij48L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90 YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4NCjx0YWJsZSBj bGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMSIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRk aW5nPSIwIiB3aWR0aD0iMzE1IiBzdHlsZT0id2lkdGg6MjM2LjI1cHQ7Ym9yZGVyLWNvbGxhcHNl OmNvbGxhcHNlO2JvcmRlcjpub25lIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjYwLjc1 cHQiPg0KPHRkIHdpZHRoPSIxNzIiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTI5LjBwdDti b3JkZXI6bm9uZTtwYWRkaW5nOjExLjI1cHQgMTEuMjVwdCAwaW4gMTEuMjVwdDtoZWlnaHQ6NjAu NzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3d3dy5jbG91ZGlk ZW50aXR5c3VtbWl0LmNvbS8iIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUmVnaXN0ZXIgZm9yIENs b3VkIElkZW50aXR5IFN1bW1pdCAyMDE0IHwgTW9kZXJuIElkZW50aXR5IFJldm9sdXRpb24gfCAx OeKAkzIzIEp1bHksIDIwMTQgfCBNb250ZXJleSwgQ0EiPjxzcGFuIHN0eWxlPSJjb2xvcjojQ0ND Q0NDO3RleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAz NSIgc3JjPSJodHRwOi8vNC5waW5naWRlbnRpdHkuY29tL3JzL3BpbmdpZGVudGl0eS9pbWFnZXMv RVhQX0NJU18yMDE0LmdpZiIgYWx0PSJSZWdpc3RlciBmb3IgQ2xvdWQgSWRlbnRpdHkgU3VtbWl0 IDIwMTQgfCBNb2Rlcm4gSWRlbnRpdHkgUmV2b2x1dGlvbiB8IDE54oCTMjMgSnVseSwgMjAxNCB8 IE1vbnRlcmV5LCBDQSI+PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0K PC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5bc620f21ba6446e8925476d4646bad5BLUPR03MB309namprd03pro_-- From nobody Wed May 14 14:40:51 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A7A1A02B3 for ; Wed, 14 May 2014 14:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 AQ4ikAEe7PQZ for ; Wed, 14 May 2014 14:40:45 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id C22901A0203 for ; Wed, 14 May 2014 14:40:44 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB310.namprd03.prod.outlook.com (10.141.48.25) with Microsoft SMTP Server (TLS) id 15.0.949.11; Wed, 14 May 2014 21:40:30 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0949.001; Wed, 14 May 2014 21:40:30 +0000 From: Anthony Nadalin To: Chuck Mortimore Thread-Topic: [OAUTH-WG] OAuth Milestone Update and Rechartering Thread-Index: AQHPawEbu8OzlywPcU+RkLqz+fSkNptACOgAgAA0VICAAAQKYIAADrsAgABS4MA= Date: Wed, 14 May 2014 21:40:29 +0000 Message-ID: References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [195.50.165.102] x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(53754006)(377454003)(24454002)(189002)(199002)(86612001)(92566001)(86362001)(76482001)(19617315010)(77982001)(16236675002)(83072002)(101416001)(33646001)(99286001)(85852003)(19625215002)(74316001)(81542001)(81342001)(46102001)(74662001)(19618635001)(74502001)(31966008)(2656002)(87936001)(19580405001)(83322001)(19580395003)(19300405004)(19273905006)(79102001)(64706001)(4396001)(76576001)(15198665003)(80022001)(20776003)(54356999)(66066001)(50986999)(76176999)(18206015023)(15395725003)(77096999)(15975445006)(19609705001)(21056001)(15202345003)(42262001)(24736002)(9984715005); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB310; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; Content-Type: multipart/alternative; boundary="_000_da25696baeb74aa8ae8b57730fdb1b06BLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fvigOwzvHz79-F4dwLRa5LhOpm8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 21:40:49 -0000 --_000_da25696baeb74aa8ae8b57730fdb1b06BLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgYXJlIGZvbGtzIHRoYXQgYXJlIG5vdCBpbXBsZW1lbnRpbmcgY29ubmVjdCBmb3IgdmFy aW91cyByZWFzb25zIChpLmUuIHNlY3VyaXR5IHJlYXNvbnMsIGNvbXBsZXhpdHkgcmVhc29ucywg ZXRjLikuIHRodXMgdGhpcyBpcyBjb21wYXRpYmxlIHdpdGggY29ubmVjdCBpZiBmb2xrcyB3YW50 IHRvIG1vdmUgb24gdG8gY29ubmVjdCwgIHdlIHN1cmVseSBkb27igJl0IHVzZSBjb25uZWN0IGV2 ZXJ3aGVyZSBhcyBpdOKAmXMgb3ZlciBraWxsIHdoZXJlIHdlIG9ubHkgbmVlZCBhIHRoZSBmdW5j dGlvbmFsaXR5IG9mIGE0Yy4NCg0KRnJvbTogQ2h1Y2sgTW9ydGltb3JlIFttYWlsdG86Y21vcnRp bW9yZUBzYWxlc2ZvcmNlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDE0LCAyMDE0IDk6Mzkg QU0NClRvOiBBbnRob255IE5hZGFsaW4NCkNjOiBQaGlsIEh1bnQ7IEJyaWFuIENhbXBiZWxsOyBv YXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggTWlsZXN0b25lIFVw ZGF0ZSBhbmQgUmVjaGFydGVyaW5nDQoNCkNhbiB5b3UgcG9pbnQgdG8gb25lIHB1YmxpY2x5IGF2 YWlsYWJsZSBvciBwdWJsaWNseSBkb2N1bWVudGVkIGltcGxlbWVudGF0aW9uIG9mIGE0Yz8gICAg SSd2ZSBuZXZlciBzZWVuIG9uZS4NCg0KSSB3aWxsIHNheSB0aGUgYTRjIHNwZWMgaXMgYWxtb3N0 IDEwMCUgb3ZlcmxhcHBlZCB3aXRoIE9wZW5JRCBDb25uZWN0LiAgIFNvbWUgbWlub3IgdmFyaWF0 aW9ucyBpbiBjbGFpbSBuYW1lcywgYnV0IGl0IGFkZHMgMCBpbmNyZW1lbnRhbCB2YWx1ZSBvdmVy IHdoYXQgd2UgaGF2ZSBpbiBDb25uZWN0Lg0KDQpDb25uZWN0IGlzIGJlaW5nIHN1Y2Nlc3NmdWxs eSBkZXBsb3llZCBhdCBsYXJnZSBzY2FsZS4gIEl0IHdvdWxkIGJlIGlycmVzcG9uc2libGUgZm9y IHRoaXMgd29ya2luZyBncm91cCB0byBjb25mdXNlIGRldmVsb3BlcnMgYW5kIHRoZSBpbmR1c3Ry eSB3aXRoIGR1cGxpY2F0ZSB3b3JrLCBlc3BlY2lhbGx5IGdpdmVuIHRoaXMgZmVlbHMgbW9yZSBs aWtlIGFuIGFyZ3VtZW50IG92ZXIgc2lnbmluZyBJUFIgYWdyZWVtZW50cy4NCg0KLWNtb3J0DQoN Ck9uIFdlZCwgTWF5IDE0LCAyMDE0IGF0IDg6NDcgQU0sIEFudGhvbnkgTmFkYWxpbiA8dG9ueW5h ZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkkg YWdyZWUgd2l0aCBQaGlsIG9uIHRoaXMgb25lLCB0aGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIG9m IHRoaXMgYWxyZWFkeSBhbmQgbXVjaCBpbnRlcmVzdA0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBC ZWhhbGYgT2YgUGhpbCBIdW50DQpTZW50OiBXZWRuZXNkYXksIE1heSAxNCwgMjAxNCA4OjMyIEFN DQpUbzogQnJpYW4gQ2FtcGJlbGwNCkNjOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCBNaWxlc3RvbmUgVXBkYXRlIGFu ZCBSZWNoYXJ0ZXJpbmcNCg0KT24gdGhlIGNvbnRyYXJ5LiBJIGFuZCBvdGhlcnMgYXJlIGludGVy ZXN0ZWQuDQoNCldlIGFyZSB3YWl0aW5nIGZvciB0aGUgY2hhcnRlciB0byBwaWNrIHVwIHRoZSB3 b3JrLg0KDQpSZWdhcmRsZXNzIHRoZXJlIHdpbGwgYmUgYSBuZXcgZHJhZnQgc2hvcnRseS4NCg0K UGhpbA0KDQpPbiBNYXkgMTQsIDIwMTQsIGF0IDU6MjQsIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJl bGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3 cm90ZToNCkkgd291bGQgb2JqZWN0IHRvICdPQXV0aCBBdXRoZW50aWNhdGlvbicgYmVpbmcgcGlj a2VkIHVwIGJ5IHRoZSBXRyBhcyBhIHdvcmsgaXRlbS4gVGhlIHN0YXJ0aW5nIHBvaW50IGRyYWZ0 IGhhcyBleHBpcmVkIGFuZCBpdCBoYXNuJ3QgcmVhbGx5IGJlZW4gZGlzY3Vzc2VzIHNpbmNlIEJl cmxpbiBuZWFybHkgYSB5ZWFyIGFnby4gIEFzIEkgcmVjYWxsLCB0aGVyZSB3YXMgb25seSB2ZXJ5 IGxpbWl0ZWQgaW50ZXJlc3QgaW4gaXQgZXZlbiB0aGVuLiBJIGFsc28gZG9uJ3QgYmVsaWV2ZSBp dCBmaXRzIHdlbGwgd2l0aCB0aGUgV0cgY2hhcnRlci4NCg0KSSB3b3VsZCBzdWdnZXN0IHRoZSBX RyBjb25zaWRlciBwaWNraW5nIHVwICdPQXV0aCBTeW1tZXRyaWMgUHJvb2Ygb2YgUG9zc2Vzc2lv biBmb3IgQ29kZSBFeHRlbnNpb24nIGZvciB3aGljaCB0aGVyZSBpcyBhbiBleGNlbGxlbnQgc3Rh cnRpbmcgcG9pbnQgb2YgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEt b2F1dGgtdGNzZS0wMyAtIGl0J3MgYSByZWxhdGl2aXR5IHNpbXBsZSBzZWN1cml0eSBlbmhhbmNl bWVudCB3aGljaCBhZGRyZXNzZXMgcHJvYmxlbXMgY3VycmVudGx5IGJlaW5nIGVuY291bnRlcmVk IGluIGRlcGxveW1lbnRzIG9mIG5hdGl2ZSBjbGllbnRzLg0KDQpPbiBUaHUsIE1heSA4LCAyMDE0 IGF0IDM6MDQgUE0sIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0 PG1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj4gd3JvdGU6DQpIaSBhbGwsDQoNCnlv dSBtaWdodCBoYXZlIHNlZW4gdGhhdCB3ZSBwdXNoZWQgdGhlIGFzc2VydGlvbiBkb2N1bWVudHMg YW5kIHRoZSBKV1QNCmRvY3VtZW50cyB0byB0aGUgSUVTRyB0b2RheS4gV2UgaGF2ZSBhbHNvIHVw ZGF0ZWQgdGhlIG1pbGVzdG9uZXMgb24gdGhlDQpPQXV0aCBXRyBwYWdlLg0KDQpUaGlzIG1lYW5z IHRoYXQgd2UgY2FuIHBsYW4gdG8gcGljayB1cCBuZXcgd29yayBpbiB0aGUgZ3JvdXAuDQpXZSBo YXZlIHNlbnQgYSByZXF1ZXN0IHRvIEthdGhsZWVuIHRvIGNoYW5nZSB0aGUgbWlsZXN0b25lIGZv ciB0aGUgT0F1dGgNCnNlY3VyaXR5IG1lY2hhbmlzbXMgdG8gdXNlIHRoZSBwcm9vZi1vZi1wb3Nz ZXNzaW9uIHRlcm1pbm9sb2d5Lg0KDQpXZSBhbHNvIGV4cGVjdCBhbiB1cGRhdGVkIHZlcnNpb24g b2YgdGhlIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbg0Kc3BlYyBpbmNvcnBvcmF0aW5nIGxh c3QgY2FsbCBmZWVkYmFjayB3aXRoaW4gYWJvdXQgMiB3ZWVrcy4NCg0KV2Ugd291bGQgbGlrZSB5 b3UgdG8gdGhpbmsgYWJvdXQgYWRkaW5nIHRoZSBmb2xsb3dpbmcgbWlsZXN0b25lcyB0byB0aGUN CmNoYXJ0ZXIgYXMgcGFydCBvZiB0aGUgcmUtY2hhcnRlcmluZyBlZmZvcnQ6DQoNCi0tLS0tDQoN Ck5vdiAyMDE0IFN1Ym1pdCAnVG9rZW4gaW50cm9zcGVjdGlvbicgdG8gdGhlIElFU0cgZm9yIGNv bnNpZGVyYXRpb24gYXMgYQ0KUHJvcG9zZWQgU3RhbmRhcmQNClN0YXJ0aW5nIHBvaW50OiA8ZHJh ZnQtcmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24tMDQ+DQoNCkphbiAyMDE1IFN1Ym1pdCAnT0F1 dGggQXV0aGVudGljYXRpb24nIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzDQphIFBy b3Bvc2VkIFN0YW5kYXJkDQpTdGFydGluZyBwb2ludDogPGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNl ci1hNGMtMDE+DQoNCkphbiAyMDE1IFN1Ym1pdCAnVG9rZW4gRXhjaGFuZ2UnIHRvIHRoZSBJRVNH IGZvciBjb25zaWRlcmF0aW9uIGFzIGENClByb3Bvc2VkIFN0YW5kYXJkDQpTdGFydGluZyBwb2lu dDogPGRyYWZ0LWpvbmVzLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAwPg0KDQotLS0tLQ0KDQpXZSBh bHNvIHVwZGF0ZWQgdGhlIGNoYXJ0ZXIgdGV4dCB0byByZWZsZWN0IHRoZSBjdXJyZW50IHNpdHVh dGlvbi4gSGVyZQ0KaXMgdGhlIHByb3Bvc2VkIHRleHQ6DQoNCi0tLS0tDQoNCkNoYXJ0ZXIgZm9y IFdvcmtpbmcgR3JvdXANCg0KDQpUaGUgV2ViIEF1dGhvcml6YXRpb24gKE9BdXRoKSBwcm90b2Nv bCBhbGxvd3MgYSB1c2VyIHRvIGdyYW50IGENCnRoaXJkLXBhcnR5IFdlYiBzaXRlIG9yIGFwcGxp Y2F0aW9uIGFjY2VzcyB0byB0aGUgdXNlcidzIHByb3RlY3RlZA0KcmVzb3VyY2VzLCB3aXRob3V0 IG5lY2Vzc2FyaWx5IHJldmVhbGluZyB0aGVpciBsb25nLXRlcm0gY3JlZGVudGlhbHMsDQpvciBl dmVuIHRoZWlyIGlkZW50aXR5LiBGb3IgZXhhbXBsZSwgYSBwaG90by1zaGFyaW5nIHNpdGUgdGhh dA0Kc3VwcG9ydHMgT0F1dGggY291bGQgYWxsb3cgaXRzIHVzZXJzIHRvIHVzZSBhIHRoaXJkLXBh cnR5IHByaW50aW5nIFdlYg0Kc2l0ZSB0byBwcmludCB0aGVpciBwcml2YXRlIHBpY3R1cmVzLCB3 aXRob3V0IGFsbG93aW5nIHRoZSBwcmludGluZw0Kc2l0ZSB0byBnYWluIGZ1bGwgY29udHJvbCBv ZiB0aGUgdXNlcidzIGFjY291bnQgYW5kIHdpdGhvdXQgaGF2aW5nIHRoZQ0KdXNlciBzaGFyZSBo aXMgb3IgaGVyIHBob3RvLXNoYXJpbmcgc2l0ZXMnIGxvbmctdGVybSBjcmVkZW50aWFsIHdpdGgN CnRoZSBwcmludGluZyBzaXRlLg0KDQpUaGUgT0F1dGggMi4wIHByb3RvY29sIHN1aXRlIGVuY29t cGFzc2VzDQoNCiogYSBwcm90b2NvbCBmb3Igb2J0YWluaW5nIGFjY2VzcyB0b2tlbnMgZnJvbSBh biBhdXRob3JpemF0aW9uDQpzZXJ2ZXIgd2l0aCB0aGUgcmVzb3VyY2Ugb3duZXIncyBjb25zZW50 LA0KKiBwcm90b2NvbHMgZm9yIHByZXNlbnRpbmcgdGhlc2UgYWNjZXNzIHRva2VucyB0byByZXNv dXJjZSBzZXJ2ZXINCmZvciBhY2Nlc3MgdG8gYSBwcm90ZWN0ZWQgcmVzb3VyY2UsDQoqIGd1aWRh bmNlIGZvciBzZWN1cmVseSB1c2luZyBPQXV0aCAyLjAsDQoqIHRoZSBhYmlsaXR5IHRvIHJldm9r ZSBhY2Nlc3MgdG9rZW5zLA0KKiBzdGFuZGFyZGl6ZWQgZm9ybWF0IGZvciBzZWN1cml0eSB0b2tl bnMgZW5jb2RlZCBpbiBhIEpTT04gZm9ybWF0DQogIChKU09OIFdlYiBUb2tlbiwgSldUKSwNCiog d2F5cyBvZiB1c2luZyBhc3NlcnRpb25zIHdpdGggT0F1dGgsIGFuZA0KKiBhIGR5bmFtaWMgY2xp ZW50IHJlZ2lzdHJhdGlvbiBwcm90b2NvbC4NCg0KVGhlIHdvcmtpbmcgZ3JvdXAgYWxzbyBkZXZl bG9wZWQgc2VjdXJpdHkgc2NoZW1lcyBmb3IgcHJlc2VudGluZw0KYXV0aG9yaXphdGlvbiB0b2tl bnMgdG8gYWNjZXNzIGEgcHJvdGVjdGVkIHJlc291cmNlLiBUaGlzIGxlZCB0byB0aGUNCnB1Ymxp Y2F0aW9uIG9mIHRoZSBiZWFyZXIgdG9rZW4sIGFzIHdlbGwgYXMgd29yayB0aGF0IHJlbWFpbnMg dG8gYmUNCmNvbXBsZXRlZCBvbiBwcm9vZi1vZi1wb3NzZXNzaW9uIGFuZCB0b2tlbiBleGNoYW5n ZS4NCg0KVGhlIG9uZ29pbmcgc3RhbmRhcmRpemF0aW9uIGVmZm9ydCB3aXRoaW4gdGhlIE9BdXRo IHdvcmtpbmcgZ3JvdXAgd2lsbA0KZm9jdXMgb24gZW5oYW5jaW5nIGludGVyb3BlcmFiaWxpdHkg YW5kIGZ1bmN0aW9uYWxpdHkgb2YgT0F1dGgNCmRlcGxveW1lbnRzLCBzdWNoIGFzIGEgc3RhbmRh cmQgZm9yIGEgdG9rZW4gaW50cm9zcGVjdGlvbiBzZXJ2aWNlIGFuZA0Kc3RhbmRhcmRzIGZvciBh ZGRpdGlvbmFsIHNlY3VyaXR5IG9mIE9BdXRoIHJlcXVlc3RzLg0KDQotLS0tLQ0KDQpGZWVkYmFj ayBhcHByZWNpYXRlZC4NCg0KQ2lhbw0KSGFubmVzICYgRGVyZWsNCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QN Ck9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpbUGluZyBJZGVudGl0eSBsb2dv XTxodHRwczovL3d3dy5waW5naWRlbnRpdHkuY29tLz4NCg0KQnJpYW4gQ2FtcGJlbGwNClBvcnRm b2xpbyBBcmNoaXRlY3QNCkANCg0KYmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJj YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPg0KDQpbcGhvbmVdDQoNCisxIDcyMC4zMTcuMjA2MTx0 ZWw6JTJCMSUyMDcyMC4zMTcuMjA2MT4NCg0KQ29ubmVjdCB3aXRoIHVz4oCmDQoNClt0d2l0dGVy IGxvZ29dPGh0dHBzOi8vdHdpdHRlci5jb20vcGluZ2lkZW50aXR5Plt5b3V0dWJlIGxvZ29dPGh0 dHBzOi8vd3d3LnlvdXR1YmUuY29tL3VzZXIvUGluZ0lkZW50aXR5VFY+W0xpbmtlZEluIGxvZ29d PGh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9jb21wYW55LzIxODcwPltGYWNlYm9vayBsb2dvXTxo dHRwczovL3d3dy5mYWNlYm9vay5jb20vcGluZ2lkZW50aXR5cGFnZT5bR29vZ2xlKyBsb2dvXTxo dHRwczovL3BsdXMuZ29vZ2xlLmNvbS91LzAvMTE0MjY2OTc3NzM5Mzk3NzA4NTQwPltzbGlkZXNo YXJlIGxvZ29dPGh0dHA6Ly93d3cuc2xpZGVzaGFyZS5uZXQvUGluZ0lkZW50aXR5PltmbGlwYm9h cmQgbG9nb108aHR0cDovL2ZsaXAuaXQvdmpCRjc+W3JzcyBmZWVkIGljb25dPGh0dHBzOi8vd3d3 LnBpbmdpZGVudGl0eS5jb20vYmxvZ3MvPg0KDQoNCltSZWdpc3RlciBmb3IgQ2xvdWQgSWRlbnRp dHkgU3VtbWl0IDIwMTQgfCBNb2Rlcm4gSWRlbnRpdHkgUmV2b2x1dGlvbiB8IDE54oCTMjMgSnVs eSwgMjAxNCB8IE1vbnRlcmV5LCBDQV08aHR0cHM6Ly93d3cuY2xvdWRpZGVudGl0eXN1bW1pdC5j b20vPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_da25696baeb74aa8ae8b57730fdb1b06BLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGVyZSBhcmUgZm9sa3MgdGhhdCBhcmUgbm90IGltcGxlbWVudGluZyBjb25uZWN0 IGZvciB2YXJpb3VzIHJlYXNvbnMgKGkuZS4gc2VjdXJpdHkgcmVhc29ucywgY29tcGxleGl0eSBy ZWFzb25zLCBldGMuKS4gdGh1cyB0aGlzIGlzIGNvbXBhdGlibGUgd2l0aCBjb25uZWN0DQogaWYg Zm9sa3Mgd2FudCB0byBtb3ZlIG9uIHRvIGNvbm5lY3QsJm5ic3A7IHdlIHN1cmVseSBkb27igJl0 IHVzZSBjb25uZWN0IGV2ZXJ3aGVyZSBhcyBpdOKAmXMgb3ZlciBraWxsIHdoZXJlIHdlIG9ubHkg bmVlZCBhIHRoZSBmdW5jdGlvbmFsaXR5IG9mIGE0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQ2h1Y2sg TW9ydGltb3JlIFttYWlsdG86Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiBXZWRuZXNkYXksIE1heSAxNCwgMjAxNCA5OjM5IEFNPGJyPg0KPGI+VG86PC9iPiBB bnRob255IE5hZGFsaW48YnI+DQo8Yj5DYzo8L2I+IFBoaWwgSHVudDsgQnJpYW4gQ2FtcGJlbGw7 IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRo IE1pbGVzdG9uZSBVcGRhdGUgYW5kIFJlY2hhcnRlcmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNhbiB5b3UgcG9pbnQgdG8gb25lIHB1YmxpY2x5IGF2YWlsYWJsZSBv ciBwdWJsaWNseSBkb2N1bWVudGVkIGltcGxlbWVudGF0aW9uIG9mIGE0Yz8gJm5ic3A7ICZuYnNw O0kndmUgbmV2ZXIgc2VlbiBvbmUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIHdpbGwgc2F5IHRoZSBhNGMgc3BlYyBpcyBhbG1vc3QgMTAwJSBvdmVybGFw cGVkIHdpdGggT3BlbklEIENvbm5lY3QuICZuYnNwOyBTb21lIG1pbm9yIHZhcmlhdGlvbnMgaW4g Y2xhaW0gbmFtZXMsIGJ1dCBpdCBhZGRzIDAgaW5jcmVtZW50YWwgdmFsdWUgb3ZlciB3aGF0IHdl IGhhdmUgaW4gQ29ubmVjdC4gJm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db25uZWN0IGlzIGJlaW5nIHN1Y2Nlc3NmdWxs eSBkZXBsb3llZCBhdCBsYXJnZSBzY2FsZS4gJm5ic3A7SXQgd291bGQgYmUgaXJyZXNwb25zaWJs ZSBmb3IgdGhpcyB3b3JraW5nIGdyb3VwIHRvIGNvbmZ1c2UgZGV2ZWxvcGVycyBhbmQgdGhlIGlu ZHVzdHJ5IHdpdGggZHVwbGljYXRlIHdvcmssIGVzcGVjaWFsbHkgZ2l2ZW4gdGhpcyBmZWVscyBt b3JlIGxpa2UgYW4gYXJndW1lbnQgb3ZlciBzaWduaW5nIElQUiBhZ3JlZW1lbnRzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tY21vcnQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1heSAxNCwgMjAxNCBhdCA4OjQ3IEFNLCBB bnRob255IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20i IHRhcmdldD0iX2JsYW5rIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUg d2l0aCBQaGlsIG9uIHRoaXMgb25lLCB0aGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIG9mIHRoaXMg YWxyZWFkeSBhbmQgbXVjaCBpbnRlcmVzdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0iMTQ1ZmI2YWNjNWExY2Y3OV9fTWFpbEVuZENvbXBvc2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGggW21haWx0bzo8 YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QaGlsIEh1bnQ8 YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMTQsIDIwMTQgODozMiBBTTxicj4NCjxi PlRvOjwvYj4gQnJpYW4gQ2FtcGJlbGw8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpv YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCBNaWxlc3RvbmUgVXBkYXRlIGFuZCBS ZWNoYXJ0ZXJpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gdGhlIGNvbnRyYXJ5LiBJIGFuZCBvdGhlcnMg YXJlIGludGVyZXN0ZWQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSBhcmUgd2FpdGluZyBmb3IgdGhlIGNoYXJ0ZXIgdG8g cGljayB1cCB0aGUgd29yay4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZGxlc3MgdGhlcmUgd2lsbCBiZSBhIG5ldyBk cmFmdCBzaG9ydGx5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIE1heSAxNCwgMjAxNCwgYXQgNToyNCwgQnJpYW4g Q2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi Pkkgd291bGQgb2JqZWN0IHRvICdPQXV0aCBBdXRoZW50aWNhdGlvbicgYmVpbmcgcGlja2VkIHVw IGJ5IHRoZSBXRyBhcyBhIHdvcmsgaXRlbS4gVGhlIHN0YXJ0aW5nIHBvaW50IGRyYWZ0IGhhcyBl eHBpcmVkIGFuZCBpdCBoYXNuJ3QgcmVhbGx5IGJlZW4gZGlzY3Vzc2VzIHNpbmNlIEJlcmxpbiBu ZWFybHkgYSB5ZWFyDQogYWdvLiZuYnNwOyBBcyBJIHJlY2FsbCwgdGhlcmUgd2FzIG9ubHkgdmVy eSBsaW1pdGVkIGludGVyZXN0IGluIGl0IGV2ZW4gdGhlbi4gSSBhbHNvIGRvbid0IGJlbGlldmUg aXQgZml0cyB3ZWxsIHdpdGggdGhlIFdHIGNoYXJ0ZXIuPGJyPg0KPGJyPg0KSSB3b3VsZCBzdWdn ZXN0IHRoZSBXRyBjb25zaWRlciBwaWNraW5nIHVwICdPQXV0aCBTeW1tZXRyaWMgUHJvb2Ygb2Yg UG9zc2Vzc2lvbiBmb3IgQ29kZSBFeHRlbnNpb24nIGZvciB3aGljaCB0aGVyZSBpcyBhbiBleGNl bGxlbnQgc3RhcnRpbmcgcG9pbnQgb2YNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLXRjc2UtMDMiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLXRjc2UtMDM8L2E+IC0g aXQncyBhIHJlbGF0aXZpdHkgc2ltcGxlIHNlY3VyaXR5IGVuaGFuY2VtZW50IHdoaWNoIGFkZHJl c3NlcyBwcm9ibGVtcyBjdXJyZW50bHkgYmVpbmcgZW5jb3VudGVyZWQgaW4gZGVwbG95bWVudHMg b2YgbmF0aXZlIGNsaWVudHMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiBUaHUsIE1heSA4LCAyMDE0IGF0IDM6MDQgUE0sIEhhbm5lcyBUc2No b2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCIgdGFy Z2V0PSJfYmxhbmsiPmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBhbGwsPGJyPg0KPGJyPg0KeW91IG1pZ2h0IGhhdmUg c2VlbiB0aGF0IHdlIHB1c2hlZCB0aGUgYXNzZXJ0aW9uIGRvY3VtZW50cyBhbmQgdGhlIEpXVDxi cj4NCmRvY3VtZW50cyB0byB0aGUgSUVTRyB0b2RheS4gV2UgaGF2ZSBhbHNvIHVwZGF0ZWQgdGhl IG1pbGVzdG9uZXMgb24gdGhlPGJyPg0KT0F1dGggV0cgcGFnZS48YnI+DQo8YnI+DQpUaGlzIG1l YW5zIHRoYXQgd2UgY2FuIHBsYW4gdG8gcGljayB1cCBuZXcgd29yayBpbiB0aGUgZ3JvdXAuPGJy Pg0KV2UgaGF2ZSBzZW50IGEgcmVxdWVzdCB0byBLYXRobGVlbiB0byBjaGFuZ2UgdGhlIG1pbGVz dG9uZSBmb3IgdGhlIE9BdXRoPGJyPg0Kc2VjdXJpdHkgbWVjaGFuaXNtcyB0byB1c2UgdGhlIHBy b29mLW9mLXBvc3Nlc3Npb24gdGVybWlub2xvZ3kuPGJyPg0KPGJyPg0KV2UgYWxzbyBleHBlY3Qg YW4gdXBkYXRlZCB2ZXJzaW9uIG9mIHRoZSBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb248YnI+ DQpzcGVjIGluY29ycG9yYXRpbmcgbGFzdCBjYWxsIGZlZWRiYWNrIHdpdGhpbiBhYm91dCAyIHdl ZWtzLjxicj4NCjxicj4NCldlIHdvdWxkIGxpa2UgeW91IHRvIHRoaW5rIGFib3V0IGFkZGluZyB0 aGUgZm9sbG93aW5nIG1pbGVzdG9uZXMgdG8gdGhlPGJyPg0KY2hhcnRlciBhcyBwYXJ0IG9mIHRo ZSByZS1jaGFydGVyaW5nIGVmZm9ydDo8YnI+DQo8YnI+DQotLS0tLTxicj4NCjxicj4NCk5vdiAy MDE0IFN1Ym1pdCAnVG9rZW4gaW50cm9zcGVjdGlvbicgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVy YXRpb24gYXMgYTxicj4NClByb3Bvc2VkIFN0YW5kYXJkPGJyPg0KU3RhcnRpbmcgcG9pbnQ6ICZs dDtkcmFmdC1yaWNoZXItb2F1dGgtaW50cm9zcGVjdGlvbi0wNCZndDs8YnI+DQo8YnI+DQpKYW4g MjAxNSBTdWJtaXQgJ09BdXRoIEF1dGhlbnRpY2F0aW9uJyB0byB0aGUgSUVTRyBmb3IgY29uc2lk ZXJhdGlvbiBhczxicj4NCmEgUHJvcG9zZWQgU3RhbmRhcmQ8YnI+DQpTdGFydGluZyBwb2ludDog Jmx0O2RyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDEmZ3Q7PGJyPg0KPGJyPg0KSmFuIDIw MTUgU3VibWl0ICdUb2tlbiBFeGNoYW5nZScgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24g YXMgYTxicj4NClByb3Bvc2VkIFN0YW5kYXJkPGJyPg0KU3RhcnRpbmcgcG9pbnQ6ICZsdDtkcmFm dC1qb25lcy1vYXV0aC10b2tlbi1leGNoYW5nZS0wMCZndDs8YnI+DQo8YnI+DQotLS0tLTxicj4N Cjxicj4NCldlIGFsc28gdXBkYXRlZCB0aGUgY2hhcnRlciB0ZXh0IHRvIHJlZmxlY3QgdGhlIGN1 cnJlbnQgc2l0dWF0aW9uLiBIZXJlPGJyPg0KaXMgdGhlIHByb3Bvc2VkIHRleHQ6PGJyPg0KPGJy Pg0KLS0tLS08YnI+DQo8YnI+DQpDaGFydGVyIGZvciBXb3JraW5nIEdyb3VwPGJyPg0KPGJyPg0K PGJyPg0KVGhlIFdlYiBBdXRob3JpemF0aW9uIChPQXV0aCkgcHJvdG9jb2wgYWxsb3dzIGEgdXNl ciB0byBncmFudCBhPGJyPg0KdGhpcmQtcGFydHkgV2ViIHNpdGUgb3IgYXBwbGljYXRpb24gYWNj ZXNzIHRvIHRoZSB1c2VyJ3MgcHJvdGVjdGVkPGJyPg0KcmVzb3VyY2VzLCB3aXRob3V0IG5lY2Vz c2FyaWx5IHJldmVhbGluZyB0aGVpciBsb25nLXRlcm0gY3JlZGVudGlhbHMsPGJyPg0Kb3IgZXZl biB0aGVpciBpZGVudGl0eS4gRm9yIGV4YW1wbGUsIGEgcGhvdG8tc2hhcmluZyBzaXRlIHRoYXQ8 YnI+DQpzdXBwb3J0cyBPQXV0aCBjb3VsZCBhbGxvdyBpdHMgdXNlcnMgdG8gdXNlIGEgdGhpcmQt cGFydHkgcHJpbnRpbmcgV2ViPGJyPg0Kc2l0ZSB0byBwcmludCB0aGVpciBwcml2YXRlIHBpY3R1 cmVzLCB3aXRob3V0IGFsbG93aW5nIHRoZSBwcmludGluZzxicj4NCnNpdGUgdG8gZ2FpbiBmdWxs IGNvbnRyb2wgb2YgdGhlIHVzZXIncyBhY2NvdW50IGFuZCB3aXRob3V0IGhhdmluZyB0aGU8YnI+ DQp1c2VyIHNoYXJlIGhpcyBvciBoZXIgcGhvdG8tc2hhcmluZyBzaXRlcycgbG9uZy10ZXJtIGNy ZWRlbnRpYWwgd2l0aDxicj4NCnRoZSBwcmludGluZyBzaXRlLjxicj4NCjxicj4NClRoZSBPQXV0 aCAyLjAgcHJvdG9jb2wgc3VpdGUgZW5jb21wYXNzZXM8YnI+DQo8YnI+DQoqIGEgcHJvdG9jb2wg Zm9yIG9idGFpbmluZyBhY2Nlc3MgdG9rZW5zIGZyb20gYW4gYXV0aG9yaXphdGlvbjxicj4NCnNl cnZlciB3aXRoIHRoZSByZXNvdXJjZSBvd25lcidzIGNvbnNlbnQsPGJyPg0KKiBwcm90b2NvbHMg Zm9yIHByZXNlbnRpbmcgdGhlc2UgYWNjZXNzIHRva2VucyB0byByZXNvdXJjZSBzZXJ2ZXI8YnI+ DQpmb3IgYWNjZXNzIHRvIGEgcHJvdGVjdGVkIHJlc291cmNlLDxicj4NCiogZ3VpZGFuY2UgZm9y IHNlY3VyZWx5IHVzaW5nIE9BdXRoIDIuMCw8YnI+DQoqIHRoZSBhYmlsaXR5IHRvIHJldm9rZSBh Y2Nlc3MgdG9rZW5zLDxicj4NCiogc3RhbmRhcmRpemVkIGZvcm1hdCBmb3Igc2VjdXJpdHkgdG9r ZW5zIGVuY29kZWQgaW4gYSBKU09OIGZvcm1hdDxicj4NCiZuYnNwOyAoSlNPTiBXZWIgVG9rZW4s IEpXVCksPGJyPg0KKiB3YXlzIG9mIHVzaW5nIGFzc2VydGlvbnMgd2l0aCBPQXV0aCwgYW5kPGJy Pg0KKiBhIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiBwcm90b2NvbC48YnI+DQo8YnI+DQpU aGUgd29ya2luZyBncm91cCBhbHNvIGRldmVsb3BlZCBzZWN1cml0eSBzY2hlbWVzIGZvciBwcmVz ZW50aW5nPGJyPg0KYXV0aG9yaXphdGlvbiB0b2tlbnMgdG8gYWNjZXNzIGEgcHJvdGVjdGVkIHJl c291cmNlLiBUaGlzIGxlZCB0byB0aGU8YnI+DQpwdWJsaWNhdGlvbiBvZiB0aGUgYmVhcmVyIHRv a2VuLCBhcyB3ZWxsIGFzIHdvcmsgdGhhdCByZW1haW5zIHRvIGJlPGJyPg0KY29tcGxldGVkIG9u IHByb29mLW9mLXBvc3Nlc3Npb24gYW5kIHRva2VuIGV4Y2hhbmdlLjxicj4NCjxicj4NClRoZSBv bmdvaW5nIHN0YW5kYXJkaXphdGlvbiBlZmZvcnQgd2l0aGluIHRoZSBPQXV0aCB3b3JraW5nIGdy b3VwIHdpbGw8YnI+DQpmb2N1cyBvbiBlbmhhbmNpbmcgaW50ZXJvcGVyYWJpbGl0eSBhbmQgZnVu Y3Rpb25hbGl0eSBvZiBPQXV0aDxicj4NCmRlcGxveW1lbnRzLCBzdWNoIGFzIGEgc3RhbmRhcmQg Zm9yIGEgdG9rZW4gaW50cm9zcGVjdGlvbiBzZXJ2aWNlIGFuZDxicj4NCnN0YW5kYXJkcyBmb3Ig YWRkaXRpb25hbCBzZWN1cml0eSBvZiBPQXV0aCByZXF1ZXN0cy48YnI+DQo8YnI+DQotLS0tLTxi cj4NCjxicj4NCkZlZWRiYWNrIGFwcHJlY2lhdGVkLjxicj4NCjxicj4NCkNpYW88YnI+DQpIYW5u ZXMgJmFtcDsgRGVyZWs8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxicj4NCi0t IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRh YmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVp Z2h0OjU5LjI1cHQiPg0KPHRkIHdpZHRoPSI3NSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo1 Ni4yNXB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7aGVpZ2h0OjU5LjI1cHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL3d3dy5waW5naWRlbnRpdHku Y29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+ PGltZyBib3JkZXI9IjAiIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iaHR0cDovLzQucGluZ2lkZW50 aXR5LmNvbS9ycy9waW5naWRlbnRpdHkvaW1hZ2VzL0VYUF9QSUNfc3F1YXJlX2xvZ29fUkdCX3dp dGhfaGFyZF9kcm9wLnBuZyIgYWx0PSJQaW5nIElkZW50aXR5IGxvZ28iPjwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzouNzVw dCAuNzVwdCAuNzVwdCA3LjVwdDtoZWlnaHQ6NTkuMjVwdCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t Ym90dG9tOjUuMjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6I0U2MUQzQyI+QnJpYW4gQ2FtcGJlbGw8L3NwYW4+PC9iPjxicj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlBvcnRmb2xpbyBBcmNoaXRl Y3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFs VGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItcmlnaHQ6c29saWQgI0U2MUQzQyAxLjBwdDtwYWRkaW5n OjBpbiAzLjc1cHQgMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87dGV4dC1hbGlnbjpjZW50ZXIiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojRTYxRDNDIj5APC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGluIDBpbiAwaW4gMi4yNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOmJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8 dGQgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1yaWdodDpzb2xpZCAjRTYzQzFEIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50 ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzt0ZXh0LWFsaWduOmNlbnRlciI+DQo8aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAy NiIgc3JjPSJodHRwOi8vNC5waW5naWRlbnRpdHkuY29tL3JzL3BpbmdpZGVudGl0eS9pbWFnZXMv RVhQX3Bob25lX2dseXBoLmdpZiIgYWx0PSJwaG9uZSI+PG86cD48L286cD48L3A+DQo8L3RkPg0K PHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDIuMjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9InRl bDolMkIxJTIwNzIwLjMxNy4yMDYxIiB0YXJnZXQ9Il9ibGFuayI+JiM0MzsxIDcyMC4zMTcuMjA2 MTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBjb2xz cGFuPSIyIiBzdHlsZT0icGFkZGluZzoxMS4yNXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTk5OTk5 Ij5Db25uZWN0IHdpdGggdXPigKY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4N Cjx0cj4NCjx0ZCBjb2xzcGFuPSIyIiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAu NzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vdHdpdHRlci5j b20vcGluZ2lkZW50aXR5IiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IlBpbmcgb24gVHdpdHRlciI+ PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94 MDAwMF9pMTAyNyIgc3JjPSJodHRwOi8vNC5waW5naWRlbnRpdHkuY29tL3JzL3BpbmdpZGVudGl0 eS9pbWFnZXMvdHdpdHRlci5naWYiIGFsdD0idHdpdHRlciBsb2dvIj48L3NwYW4+PC9hPjxhIGhy ZWY9Imh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3VzZXIvUGluZ0lkZW50aXR5VFYiIHRhcmdldD0i X2JsYW5rIiB0aXRsZT0iUGluZyBvbiBZb3VUdWJlIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0 aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDI4IiBzcmM9Imh0dHA6Ly80 LnBpbmdpZGVudGl0eS5jb20vcnMvcGluZ2lkZW50aXR5L2ltYWdlcy95b3V0dWJlLmdpZiIgYWx0 PSJ5b3V0dWJlIGxvZ28iPjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cHM6Ly93d3cubGlua2VkaW4u Y29tL2NvbXBhbnkvMjE4NzAiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUGluZyBvbiBMaW5rZWRJ biI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgaWQ9 Il94MDAwMF9pMTAyOSIgc3JjPSJodHRwOi8vNC5waW5naWRlbnRpdHkuY29tL3JzL3BpbmdpZGVu dGl0eS9pbWFnZXMvbGlua2VkaW4uZ2lmIiBhbHQ9IkxpbmtlZEluIGxvZ28iPjwvc3Bhbj48L2E+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL3BpbmdpZGVudGl0eXBhZ2UiIHRhcmdl dD0iX2JsYW5rIiB0aXRsZT0iUGluZyBvbiBGYWNlYm9vayI+PHNwYW4gc3R5bGU9InRleHQtZGVj b3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAzMCIgc3JjPSJodHRw Oi8vNC5waW5naWRlbnRpdHkuY29tL3JzL3BpbmdpZGVudGl0eS9pbWFnZXMvZmFjZWJvb2suZ2lm IiBhbHQ9IkZhY2Vib29rIGxvZ28iPjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cHM6Ly9wbHVzLmdv b2dsZS5jb20vdS8wLzExNDI2Njk3NzczOTM5NzcwODU0MCIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxl PSJQaW5nIG9uIEdvb2dsZSYjNDM7Ij48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUi PjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDMxIiBzcmM9Imh0dHA6Ly80LnBpbmdpZGVu dGl0eS5jb20vcnMvcGluZ2lkZW50aXR5L2ltYWdlcy9nb29nbGUlMkIuZ2lmIiBhbHQ9Ikdvb2ds ZSYjNDM7IGxvZ28iPjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cDovL3d3dy5zbGlkZXNoYXJlLm5l dC9QaW5nSWRlbnRpdHkiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUGluZyBvbiBTbGlkZVNoYXJl Ij48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiBpZD0i X3gwMDAwX2kxMDMyIiBzcmM9Imh0dHA6Ly80LnBpbmdpZGVudGl0eS5jb20vcnMvcGluZ2lkZW50 aXR5L2ltYWdlcy9zbGlkZXNoYXJlLmdpZiIgYWx0PSJzbGlkZXNoYXJlIGxvZ28iPjwvc3Bhbj48 L2E+PGEgaHJlZj0iaHR0cDovL2ZsaXAuaXQvdmpCRjciIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0i UGluZyBvbiBGbGlwYm9hcmQiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+PGlt ZyBib3JkZXI9IjAiIGlkPSJfeDAwMDBfaTEwMzMiIHNyYz0iaHR0cDovLzQucGluZ2lkZW50aXR5 LmNvbS9ycy9waW5naWRlbnRpdHkvaW1hZ2VzL2ZsaXBib2FyZC5naWYiIGFsdD0iZmxpcGJvYXJk IGxvZ28iPjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cHM6Ly93d3cucGluZ2lkZW50aXR5LmNvbS9i bG9ncy8iIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUGluZyBibG9ncyI+PHNwYW4gc3R5bGU9InRl eHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAzNCIgc3Jj PSJodHRwOi8vNC5waW5naWRlbnRpdHkuY29tL3JzL3BpbmdpZGVudGl0eS9pbWFnZXMvcnNzLmdp ZiIgYWx0PSJyc3MgZmVlZCBpY29uIj48L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N CjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFi bGU+DQo8L2Rpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2Vs bHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMzE1IiBzdHlsZT0id2lkdGg6MjM2 LjI1cHQ7Ym9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVp Z2h0OjYwLjc1cHQiPg0KPHRkIHdpZHRoPSIxNzIiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6 MTI5LjBwdDtwYWRkaW5nOjExLjI1cHQgMTEuMjVwdCAwaW4gMTEuMjVwdDtoZWlnaHQ6NjAuNzVw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmNsb3VkaWRl bnRpdHlzdW1taXQuY29tLyIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSJSZWdpc3RlciBmb3IgQ2xv dWQgSWRlbnRpdHkgU3VtbWl0IDIwMTQgfCBNb2Rlcm4gSWRlbnRpdHkgUmV2b2x1dGlvbiB8IDE5 4oCTMjMgSnVseSwgMjAxNCB8IE1vbnRlcmV5LCBDQSI+PHNwYW4gc3R5bGU9ImNvbG9yOiNDQ0ND Q0M7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDM1 IiBzcmM9Imh0dHA6Ly80LnBpbmdpZGVudGl0eS5jb20vcnMvcGluZ2lkZW50aXR5L2ltYWdlcy9F WFBfQ0lTXzIwMTQuZ2lmIiBhbHQ9IlJlZ2lzdGVyIGZvciBDbG91ZCBJZGVudGl0eSBTdW1taXQg MjAxNCB8IE1vZGVybiBJZGVudGl0eSBSZXZvbHV0aW9uIHwgMTnigJMyMyBKdWx5LCAyMDE0IHwg TW9udGVyZXksIENBIj48L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_da25696baeb74aa8ae8b57730fdb1b06BLUPR03MB309namprd03pro_-- From nobody Wed May 14 15:05:09 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EBE1A0305 for ; Wed, 14 May 2014 15:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 zWnutssZ9OhR for ; Wed, 14 May 2014 15:05:01 -0700 (PDT) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id F1C301A01B6 for ; Wed, 14 May 2014 15:05:00 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id e51so114703eek.23 for ; Wed, 14 May 2014 15:04:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=VelAmkfKhbOBEs1159sbkCSKIc62p3Ag2ONuBYIQxpE=; b=CSik+CJg0KrhdErZxAS40LbY02dCfAfZdHbZ1ZbDrbwrIoX/qWSlfI12g3OvXTSITb NfjsocBW5HHPgCt13LipUrahrhKtdvfcrjbXqNczG+g7HH6TjWLLYS7EZsumsjsw/xgD ERXd1aB7GU9veLhyeNZcPx7QGy3dKiNCj1BUtqhztKZ24SODBzDnM8++ewWdG8QW/O3s 7iuAjQ1EMgFbWuQJLfiLKu4WqnvPT395gypHnDRrKPbls1ZYvoSv95ygjVsiJkXIGVtU 2LPgCFBrogDesEzJPBL/9upgg4XAQQDLtSxHv8uvKn7gIH62PtT2MAe32KM9eB8ecG+W 2h6Q== X-Gm-Message-State: ALoCoQl99tr56B32dbW5dlUEI+Bsn06hC4Miza7lSyOTgWztXXjpClesgdtpXTKA2bF6svka6xIv X-Received: by 10.15.36.8 with SMTP id h8mr8590383eev.12.1400105093588; Wed, 14 May 2014 15:04:53 -0700 (PDT) Received: from [192.168.0.93] ([195.50.165.102]) by mx.google.com with ESMTPSA id x45sm7919631eee.37.2014.05.14.15.04.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 May 2014 15:04:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5977D06F-B096-4939-A1D5-D02758AA8D16" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: John Bradley In-Reply-To: Date: Thu, 15 May 2014 00:04:32 +0200 Message-Id: References: <536BF140.5070106@gmx.net> <60BC637A-FD8D-4C92-A94C-93F89E868CB9@ve7jtb.com> <5bc620f21ba6446e8925476d4646bad5@BLUPR03MB309.namprd03.prod.outlook.com> To: Brian Campbell X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/WQ0bv-CiPYs5weyQUvOEvERTD0c Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 22:05:06 -0000 --Apple-Mail=_5977D06F-B096-4939-A1D5-D02758AA8D16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have been told that DT has a implementation and I know Google is using = it for the apps they publish on iOS and perhaps other places, though = they may use pre Draft parameter names currently. There are some others I have talked to, but I will need to get there = permission to disclose there names. John B. On May 14, 2014, at 11:59 PM, Brian Campbell = wrote: > I did an implementation of = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 last week. We = are seeing growing demand for some kind of solution to the code callback = interception attack. The industry needs a well documented standard = solution. >=20 >=20 > On Wed, May 14, 2014 at 3:16 PM, Anthony Nadalin = wrote: > Please list the implementstions >=20 > =20 >=20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Wednesday, May 14, 2014 10:59 AM >=20 >=20 > To: Brian Campbell > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering >=20 > =20 >=20 > I know a number of people implementing >=20 >=20 >=20 >=20 > http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 >=20 > =20 >=20 > Having it on a RFC track may make sense.=20 >=20 > =20 >=20 > I remain to be convinced that a4c ads anything other than confusion.=20= >=20 > =20 >=20 > If the WG wants to take it up it should be aligned with Connect. I = think there are more important things to spend time on.=20 >=20 > =20 >=20 >=20 > Sent from my iPhone >=20 >=20 > On May 14, 2014, at 2:24 PM, Brian Campbell = wrote: >=20 > I would object to 'OAuth Authentication' being picked up by the WG as = a work item. The starting point draft has expired and it hasn't really = been discusses since Berlin nearly a year ago. As I recall, there was = only very limited interest in it even then. I also don't believe it fits = well with the WG charter. >=20 > I would suggest the WG consider picking up 'OAuth Symmetric Proof of = Possession for Code Extension' for which there is an excellent starting = point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's = a relativity simple security enhancement which addresses problems = currently being encountered in deployments of native clients. =20 >=20 >=20 > =20 >=20 > On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > you might have seen that we pushed the assertion documents and the JWT > documents to the IESG today. We have also updated the milestones on = the > OAuth WG page. >=20 > This means that we can plan to pick up new work in the group. > We have sent a request to Kathleen to change the milestone for the = OAuth > security mechanisms to use the proof-of-possession terminology. >=20 > We also expect an updated version of the dynamic client registration > spec incorporating last call feedback within about 2 weeks. >=20 > We would like you to think about adding the following milestones to = the > charter as part of the re-chartering effort: >=20 > ----- >=20 > Nov 2014 Submit 'Token introspection' to the IESG for consideration as = a > Proposed Standard > Starting point: >=20 > Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration = as > a Proposed Standard > Starting point: >=20 > Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a > Proposed Standard > Starting point: >=20 > ----- >=20 > We also updated the charter text to reflect the current situation. = Here > is the proposed text: >=20 > ----- >=20 > Charter for Working Group >=20 >=20 > The Web Authorization (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that > supports OAuth could allow its users to use a third-party printing Web > site to print their private pictures, without allowing the printing > site to gain full control of the user's account and without having the > user share his or her photo-sharing sites' long-term credential with > the printing site. >=20 > The OAuth 2.0 protocol suite encompasses >=20 > * a protocol for obtaining access tokens from an authorization > server with the resource owner's consent, > * protocols for presenting these access tokens to resource server > for access to a protected resource, > * guidance for securely using OAuth 2.0, > * the ability to revoke access tokens, > * standardized format for security tokens encoded in a JSON format > (JSON Web Token, JWT), > * ways of using assertions with OAuth, and > * a dynamic client registration protocol. >=20 > The working group also developed security schemes for presenting > authorization tokens to access a protected resource. This led to the > publication of the bearer token, as well as work that remains to be > completed on proof-of-possession and token exchange. >=20 > The ongoing standardization effort within the OAuth working group will > focus on enhancing interoperability and functionality of OAuth > deployments, such as a standard for a token introspection service and > standards for additional security of OAuth requests. >=20 > ----- >=20 > Feedback appreciated. >=20 > Ciao > Hannes & Derek >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > -- >=20 >=20 >=20 > Brian Campbell > Portfolio Architect >=20 > @ >=20 > bcampbell@pingidentity.com >=20 >=20 >=20 > +1 720.317.2061 >=20 > Connect with us=85 >=20 >=20 >=20 >=20 >=20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail=_5977D06F-B096-4939-A1D5-D02758AA8D16 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I have = been told that DT has a implementation and I know Google is using it for = the apps they publish on iOS and perhaps other places, though they may = use pre Draft parameter names currently.

There are = some others I have talked to, but I will need to get there permission to = disclose there names.

John B.
On = May 14, 2014, at 11:59 PM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:



On = Wed, May 14, 2014 at 3:16 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:

Please list the = implementstions

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 14, 2014 10:59 AM


To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone = Update and Rechartering

 

I know a number of people = implementing

 

I remain to be convinced that a4c ads = anything other than confusion. 

 

If the WG wants to take it up it should be = aligned with Connect.  I think there are more important things to = spend time on. 

 


Sent from my iPhone

I would = object to 'OAuth Authentication' being picked up by the WG as a work = item. The starting point draft has expired and it hasn't really been = discusses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even then. I also don't believe it = fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of = Possession for Code Extension' for which there is an excellent starting = point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a = relativity simple security enhancement which addresses problems = currently being encountered in deployments of native clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes = Tschofenig <hannes.tschofenig@gmx.net> = wrote:

Hi all,

you might have seen that we pushed the assertion documents and the = JWT
documents to the IESG today. We have also updated the milestones on = the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the = OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to = the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as = a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration = as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. = Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term = credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing = Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having = the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group = will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service = and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

3D"Ping

Brian Campbell
Portfolio Architect

@

bcampbell@pingidentity.com

3D"phone"

+1 720.317.2061

Connect with us=85

3D"twitter3D"youtube3D"LinkedIn3D"Facebook3D"Google+3D"slideshare3D"flipboard3D"rss

3D"Register

 

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



= --Apple-Mail=_5977D06F-B096-4939-A1D5-D02758AA8D16-- From nobody Wed May 14 15:08:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B32C1A02D7 for ; Wed, 14 May 2014 15:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 cvEVT6ITwG2p for ; Wed, 14 May 2014 15:08:10 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with ESMTP id B2B041A02FA for ; Wed, 14 May 2014 15:08:09 -0700 (PDT) Received: from mail-ie0-f180.google.com ([209.85.223.180]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKU3PpQ2dKRonAQtdJl26/uPVHPzU8Vra8@postini.com; Wed, 14 May 2014 15:08:03 PDT Received: by mail-ie0-f180.google.com with SMTP id as1so221825iec.11 for ; Wed, 14 May 2014 15:07:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/Jh8zFGIwaRwVGEqsSZQf27xLVZfgfNBEol4GtMMWso=; b=BZ9BDMWD0XSA4kG6SZrUBs6Lunv2vEnmuI6xDYhtgRy37S7DOQUmK8JnaRqH5DwUXS aBtS2rzff3bVEzj4EdpX/pvWNHjfYS79rO9EIuNqKzLsyNH/UnwZ5nbPhQP8VknbMwvL SqmTO4Hz9KTQ77Vslz+nn8WVCIxY7N0w/EN90jdD9CnJ66miiQTF5Ja1OlPRbJ4MyonS 7/TGwBd6ZOCgFqxl26IKr6SnPkxmVaeT4L8vDW7I+A1I33QvOYrLNEmNSJuZKNgd25jK uwORbR7aWYDiRvV1bLtpQHvj7g0CfKOahD9mG/nJanjASwOpGYqJ7NMwqk0Wd8Lw0slP cntg== X-Received: by 10.50.153.49 with SMTP id vd17mr8236796igb.40.1400104790823; Wed, 14 May 2014 14:59:50 -0700 (PDT) X-Gm-Message-State: ALoCoQmNFiKCq2sQJ/x/DSBxCHY8RrGhI0B3AjrKGUgYIt7blW+Wn0uud1EBqQwSAauqioGlgWUPk/ZMMLCV1e+4GaJsFPebqFrsBJdkO7Ud+TGdGrNfNwWONNYjiZK22O9fixkz/eMn X-Received: by 10.50.153.49 with SMTP id vd17mr8236782igb.40.1400104790616; Wed, 14 May 2014 14:59:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Wed, 14 May 2014 14:59:20 -0700 (PDT) In-Reply-To: <5bc620f21ba6446e8925476d4646bad5@BLUPR03MB309.namprd03.prod.outlook.com> References: <536BF140.5070106@gmx.net> <60BC637A-FD8D-4C92-A94C-93F89E868CB9@ve7jtb.com> <5bc620f21ba6446e8925476d4646bad5@BLUPR03MB309.namprd03.prod.outlook.com> From: Brian Campbell Date: Wed, 14 May 2014 15:59:20 -0600 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=089e014954beb17c3904f9634cc8 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/w_anptRrhtt6skacqQkOdtc17j0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 22:08:13 -0000 --089e014954beb17c3904f9634cc8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I did an implementation of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 last week. We are seeing growing demand for some kind of solution to the code callback interception attack. The industry needs a well documented standard solution= . On Wed, May 14, 2014 at 3:16 PM, Anthony Nadalin wro= te: > Please list the implementstions > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley > *Sent:* Wednesday, May 14, 2014 10:59 AM > > *To:* Brian Campbell > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering > > > > I know a number of people implementing > > > > http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 > > > > Having it on a RFC track may make sense. > > > > I remain to be convinced that a4c ads anything other than confusion. > > > > If the WG wants to take it up it should be aligned with Connect. I think > there are more important things to spend time on. > > > > > Sent from my iPhone > > > On May 14, 2014, at 2:24 PM, Brian Campbell > wrote: > > I would object to 'OAuth Authentication' being picked up by the WG as a > work item. The starting point draft has expired and it hasn't really been > discusses since Berlin nearly a year ago. As I recall, there was only ve= ry > limited interest in it even then. I also don't believe it fits well with > the WG charter. > > I would suggest the WG consider picking up 'OAuth Symmetric Proof of > Possession for Code Extension' for which there is an excellent starting > point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a > relativity simple security enhancement which addresses problems currently > being encountered in deployments of native clients. > > > > On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > > Hi all, > > you might have seen that we pushed the assertion documents and the JWT > documents to the IESG today. We have also updated the milestones on the > OAuth WG page. > > This means that we can plan to pick up new work in the group. > We have sent a request to Kathleen to change the milestone for the OAuth > security mechanisms to use the proof-of-possession terminology. > > We also expect an updated version of the dynamic client registration > spec incorporating last call feedback within about 2 weeks. > > We would like you to think about adding the following milestones to the > charter as part of the re-chartering effort: > > ----- > > Nov 2014 Submit 'Token introspection' to the IESG for consideration as a > Proposed Standard > Starting point: > > Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as > a Proposed Standard > Starting point: > > Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a > Proposed Standard > Starting point: > > ----- > > We also updated the charter text to reflect the current situation. Here > is the proposed text: > > ----- > > Charter for Working Group > > > The Web Authorization (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that > supports OAuth could allow its users to use a third-party printing Web > site to print their private pictures, without allowing the printing > site to gain full control of the user's account and without having the > user share his or her photo-sharing sites' long-term credential with > the printing site. > > The OAuth 2.0 protocol suite encompasses > > * a protocol for obtaining access tokens from an authorization > server with the resource owner's consent, > * protocols for presenting these access tokens to resource server > for access to a protected resource, > * guidance for securely using OAuth 2.0, > * the ability to revoke access tokens, > * standardized format for security tokens encoded in a JSON format > (JSON Web Token, JWT), > * ways of using assertions with OAuth, and > * a dynamic client registration protocol. > > The working group also developed security schemes for presenting > authorization tokens to access a protected resource. This led to the > publication of the bearer token, as well as work that remains to be > completed on proof-of-possession and token exchange. > > The ongoing standardization effort within the OAuth working group will > focus on enhancing interoperability and functionality of OAuth > deployments, such as a standard for a token introspection service and > standards for additional security of OAuth requests. > > ----- > > Feedback appreciated. > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > > [image: Ping Identity logo] > > *Brian Campbell* > Portfolio Architect > > *@* > > bcampbell@pingidentity.com > > [image: phone] > > +1 720.317.2061 > > Connect with us=E2=80=A6 > > [image: twitter logo] [image: youtube > logo] [image: LinkedIn logo]= [image: > Facebook logo] [image: Google+ > logo] [image: > slideshare logo] [image: > flipboard logo] [image: rss feed icon] > > [image: Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e014954beb17c3904f9634cc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I did an implementation of http://tools.ietf.or= g/html/draft-sakimura-oauth-tcse-03 last week. We are seeing growing d= emand for some kind of solution to the code callback interception attack. T= he industry needs a well documented standard solution.


On Wed,= May 14, 2014 at 3:16 PM, Anthony Nadalin <tonynad@microsoft.com&g= t; wrote:

Please list the implement= stions

=C2=A0

From: OAuth = [mailto:oauth-b= ounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 14, 2014 10:59 AM

To: Brian Campbell
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] OAuth Milestone Update= and Rechartering

=C2=A0

I know a number of people implementing=



=C2=A0

Having it on a RFC track may make sense.=C2=A0

=C2=A0

I remain to be convinced that a4c ads anything other= than confusion.=C2=A0

=C2=A0

If the WG wants to take it up it should be aligned w= ith Connect. =C2=A0I think there are more important things to spend time on= .=C2=A0

=C2=A0


Sent from my iPhone


On May 14, 2014, at 2:24 PM, Brian Campbell <bcampbell@pingidentity.com> wro= te:

I would object to = 9;OAuth Authentication' being picked up by the WG as a work item. The s= tarting point draft has expired and it hasn't really been discusses sin= ce Berlin nearly a year ago.=C2=A0 As I recall, there was only very limited interest in it even then. I also don't believe i= t fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Po= ssession for Code Extension' for which there is an excellent starting p= oint of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a re= lativity simple security enhancement which addresses problems currently bei= ng encountered in deployments of native clients.=C2=A0

=C2=A0<= /p>

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig &l= t;hannes.tsc= hofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration= as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideratio= n as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a=
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the<= br> user share his or her photo-sharing sites' long-term credential with the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
=C2=A0 (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

Brian Campbell
Portfolio Architect

@

bcampbell@pingidentity.com=

3D"phone"

+1 720.317.2061<= u>

Connect with us=E2=80=A6=

3D"twitter3D"youtube3D"LinkedIn3D"Facebook3D"Google+3D"slideshare3D"flipboard= 3D"rss

3D"Register

=C2=A0

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


--089e014954beb17c3904f9634cc8-- From nobody Wed May 14 16:43:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A721A0376 for ; Wed, 14 May 2014 16:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 JqJWBL5o9LzD for ; Wed, 14 May 2014 16:43:11 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7401A038E for ; Wed, 14 May 2014 16:43:10 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id wp18so341106obc.3 for ; Wed, 14 May 2014 16:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=57C9lF/7QHOoSfxaDrAm+NqxNM4NxdiCNlFPy0vKI9k=; b=d2vVqDe4N9IZUk5p3c2CQefWPIXU4/vuycT0sHL9T2KJsaOi60T6Mb6urc8npuibro uk4TOO3aa98juOK/T0WwUKJoT4ziQbrkJABK1k8VEvKsMOqVj2dxQg4RdajcaV4vIEKi KbNyEYWvw6WlMVN65OT/UXfVYFGmOhuVp6uY5BbD4Dr7WKVLT6iDk22XbfdfnGFLKm5r PvkyUnfP9ulaabKaNHl66c8TU+w/fO7JUpkYkD7quiG19FKsXYPVgcGrvOf+drJusUHt ENjG2StohHdM3a5iO+OxWAX60NsSaDHsuzV3zrtUvzgv3ymp6tcPWwOc6hiAZPV4O9d5 Fojg== MIME-Version: 1.0 X-Received: by 10.182.236.229 with SMTP id ux5mr6695363obc.12.1400110983766; Wed, 14 May 2014 16:43:03 -0700 (PDT) Received: by 10.60.0.36 with HTTP; Wed, 14 May 2014 16:43:03 -0700 (PDT) Received: by 10.60.0.36 with HTTP; Wed, 14 May 2014 16:43:03 -0700 (PDT) Date: Wed, 14 May 2014 16:43:03 -0700 Message-ID: From: Josh Mandel To: "oauth@ietf.org WG" Content-Type: multipart/alternative; boundary=001a11c2e9ccd56c3004f964bd54 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LW9Ff_6IYgkAnWvHfieXa51SJJY Subject: [OAUTH-WG] Security considerations in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 23:43:12 -0000 --001a11c2e9ccd56c3004f964bd54 Content-Type: text/plain; charset=ISO-8859-1 Forgive me if this is well-trodden territory, but I would have expected the security considerations in this proposal to include a note to the effect of: "In a scenario where a mobile client is contending with malicious apps on the same device that listen on the same custom URL scheme, it's important to keep in mind that a malicious app can initiate its own authorization request. Such a request would appear the same as a legitimate request from the end-user's perspective. So in this case, a malicious app could request its own verifier code and successfully obtain authorization using the tcse protocol." Obviously this does not negate the value of the proposal, but it's something I'd expect readers to keep in mind. In particular, it has very strong implications for whitelisted authorizations, where no end user interaction is required. In such a case, a malicious app could initiate a request at any time and the user would not be in the loop to raise a question about its legitimacy. On May 9, 2014 4:51 PM, "Brian Campbell" wrote: > > I notice that code_verifier is defined as "high entropy cryptographic random string of length less than 128 bytes" [1], which brought a few questions and comments to mind. So here goes: > > Talking about the length of a string in terms of bytes is always potentially confusing. Maybe characters would be an easier unit for people like me to wrap their little brains around? > > Why are we putting a length restriction on the code_verifier anyway? It seems like it'd be more appropriate to restrict the length of the code_challenge because that's the thing the AS will have to maintain somehow (store in a DB or memory or encrypt into the code). Am I missing something here? > > Let me also say that I hadn't looked at this document since its early days in draft -00 or -01 last summer but I like the changes and how it's been kept pretty simple for the common use-case while still allowing for crypto agility/extension. Nice work! > > [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11c2e9ccd56c3004f964bd54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Forgive me if this is well-trodden territory, but I would ha= ve expected the security considerations in this proposal to include a note = to the effect of:

"In a scenario where a mobile client is contending with= malicious apps on the same device that listen on the same custom URL schem= e, it's important to keep in mind that a malicious app can initiate its= own authorization request. Such a request=A0 would appear the same as a le= gitimate request from the end-user's perspective. So in this case, a ma= licious app could request its own verifier code and successfully obtain aut= horization using the tcse protocol."

Obviously this does not negate the value of the proposal, bu= t it's something I'd expect readers to keep in mind.

In particular, it has very strong implications for whitelist= ed authorizations, where no end user interaction is required. In such a cas= e, a malicious app could initiate a request at any time and the user would = not be in the loop to raise a question about its legitimacy.

On May 9, 2014 4:51 PM, "Brian Campbell" <bcampbell@pingidentity.com>= wrote:
>
> I notice that code_verifier is defined as "high entropy cryptogra= phic random string of length less than 128 bytes"=A0 [1], which brough= t a few questions and comments to mind. So here goes:
>
> Talking about the length of a string in terms of bytes is always poten= tially confusing. Maybe characters would be an easier unit for people like = me to wrap their little brains around?
>
> Why are we putting a length restriction on the code_verifier anyway? I= t seems like it'd be more appropriate to restrict the length of the cod= e_challenge because that's the thing the AS will have to maintain someh= ow (store in a DB or memory or encrypt into the code). Am I missing somethi= ng here?
>
> Let me also say that I hadn't looked at this document since its ea= rly days in draft -00 or -01 last summer but I like the changes and how it&= #39;s been kept pretty simple for the common use-case while still allowing = for crypto agility/extension. Nice work!
>
> [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#secti= on-3.3
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth
>

--001a11c2e9ccd56c3004f964bd54-- From nobody Wed May 14 17:32:00 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EE91A0207 for ; Wed, 14 May 2014 17:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 WYQICWzdzLLA for ; Wed, 14 May 2014 17:31:53 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C038A1A037D for ; Wed, 14 May 2014 17:31:52 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id o6so394853oag.17 for ; Wed, 14 May 2014 17:31:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0I/z4x4CKhfsoS3mCZm0/qYA8YvRX4FevoBBecRsf5c=; b=J/50aw8khgLt7XeLdhV9b5Kb42ijkZcxYrk2viXIAjV+3ll/XeGXA3UPiJxG0L9V8d 61mcTutEAzufxV1xxSmZXyRmfaEj4wkHEQ5lXDqe8qcnLeernH+vQwsusE6x8zgwtmPp 3svryjq8g2dEQK3dRdJZLIHodC4diRQuj6D5lS6fmzq2bnZ32OvwGmxPKpRyzWR12mxf BEXFlQ9wQJv1ES9PzCnqi8GxxMR1co8ivF0yYpXC3BYuOluzNgvgvr6ZXGSrRaGju9DX UZtVU/E7ICYfHwtRzxnOwXKFXFYLy085WX7HRXUMbhZDET3KSdk9cfurxzhcZEEFQnme R0iA== X-Gm-Message-State: ALoCoQma9lng6XUvTqSooW0z9WqZ5eurvKvucQJAOUmQTLQn1dTFgfTvbYHWmPgJgwI86MC3AefL MIME-Version: 1.0 X-Received: by 10.60.145.144 with SMTP id su16mr6700884oeb.64.1400113905522; Wed, 14 May 2014 17:31:45 -0700 (PDT) Received: by 10.76.75.169 with HTTP; Wed, 14 May 2014 17:31:45 -0700 (PDT) In-Reply-To: References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> Date: Wed, 14 May 2014 17:31:45 -0700 Message-ID: From: Chuck Mortimore To: Anthony Nadalin Content-Type: multipart/alternative; boundary=047d7b5d428cfbf3b304f9656b47 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/SFjplCub3T6U8E4WuL14qn4iNBU Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 00:31:57 -0000 --047d7b5d428cfbf3b304f9656b47 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable a4c is connect. For example here's the sample requests: draft-hunt-oauth-v2-user-a4c-01, section 2.1: GET /authenticate? response_type=3Dcode &client_id=3Ds6BhdRkqt3 &redirect_uri=3Dhttps%3A%2F%2Fclient.example.com%2Fcb &state=3Daf0ifjsldkj &prompt=3Dlogin Host: server.example.com OpenID Connect Basic Client Implementer's Guide 1.0 - draft 33, section 2.1.2: GET /authorize? response_type=3Dcode &client_id=3Ds6BhdRkqt3 &redirect_uri=3Dhttps%3A%2F%2Fclient.example.org%2Fcb &scope=3Dopenid%20profile &state=3Daf0ifjsldkj HTTP/1.1 Host: server.example.com The primary contribution of a4c in this case seems to be malformed HTTP, and implying that implementors should deploy a redundant authenticate endpoint. Sample Responses: draft-hunt-oauth-v2-user-a4c-01, section 2.4: HTTP/1.1 200 OK Content-Type: application/json;charset=3DUTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "id_token":"eyJhbGciOiJub25lIn0. eyAic3ViIjoiNWRlZGNjOGItNzM1Yy00MDVmLWUwMjlmIiwicHJvZmlsZSI6Imh0 dHBzOi8vZXhhbXBsZS5jb20vVXNlcnMvNWRlZGNjOGItNzM1Yy00MDVmLWUwMjlm IiwiYXV0aF90aW1lIjoiMTM2Nzk1NjA5NiIsImV4cCI6IjEzNjgwNDI0OTYiLCJh bHYiOiIyIiwiaWF0IjoiMTM2Nzk1NjA5OCIsImlzcyI6Imh0dHBzOi8vc2VydmVy LmV4YW1wbGUuY29tIiwiYXVkIjoiczZCaGRSa3F0MyIsImV4YW1wbGVfc2Vzc2lv bl9wYXJhbWV0ZXIiOiJleGFtcGxlX3ZhbHVlIn0=3D." } OpenID Connect Basic Client Implementer's Guide 1.0 - draft 33, section 2.1.6.2: HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store Pragma: no-cache { "access_token":"SlAV32hkKG", "token_type":"Bearer", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "id_token":"eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso" } a4c seems to toss in a little confusion with an arbitrary example token type. We're still dealing with ws-federation passive profile in saml dominated world. The oauth working group shouldn't repeat that sin. -cmort On Wed, May 14, 2014 at 2:40 PM, Anthony Nadalin wro= te: > There are folks that are not implementing connect for various reasons > (i.e. security reasons, complexity reasons, etc.). thus this is compatibl= e > with connect if folks want to move on to connect, we surely don=E2=80=99= t use > connect everwhere as it=E2=80=99s over kill where we only need a the func= tionality > of a4c. > > > > *From:* Chuck Mortimore [mailto:cmortimore@salesforce.com] > *Sent:* Wednesday, May 14, 2014 9:39 AM > *To:* Anthony Nadalin > *Cc:* Phil Hunt; Brian Campbell; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering > > > > Can you point to one publicly available or publicly documented > implementation of a4c? I've never seen one. > > > > I will say the a4c spec is almost 100% overlapped with OpenID Connect. > Some minor variations in claim names, but it adds 0 incremental value ove= r > what we have in Connect. > > > > Connect is being successfully deployed at large scale. It would be > irresponsible for this working group to confuse developers and the indust= ry > with duplicate work, especially given this feels more like an argument ov= er > signing IPR agreements. > > > > -cmort > > > > On Wed, May 14, 2014 at 8:47 AM, Anthony Nadalin > wrote: > > I agree with Phil on this one, there are implementations of this already > and much interest > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Wednesday, May 14, 2014 8:32 AM > *To:* Brian Campbell > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering > > > > On the contrary. I and others are interested. > > > > We are waiting for the charter to pick up the work. > > > > Regardless there will be a new draft shortly. > > > Phil > > > On May 14, 2014, at 5:24, Brian Campbell > wrote: > > I would object to 'OAuth Authentication' being picked up by the WG as a > work item. The starting point draft has expired and it hasn't really been > discusses since Berlin nearly a year ago. As I recall, there was only ve= ry > limited interest in it even then. I also don't believe it fits well with > the WG charter. > > I would suggest the WG consider picking up 'OAuth Symmetric Proof of > Possession for Code Extension' for which there is an excellent starting > point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a > relativity simple security enhancement which addresses problems currently > being encountered in deployments of native clients. > > > > On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > > Hi all, > > you might have seen that we pushed the assertion documents and the JWT > documents to the IESG today. We have also updated the milestones on the > OAuth WG page. > > This means that we can plan to pick up new work in the group. > We have sent a request to Kathleen to change the milestone for the OAuth > security mechanisms to use the proof-of-possession terminology. > > We also expect an updated version of the dynamic client registration > spec incorporating last call feedback within about 2 weeks. > > We would like you to think about adding the following milestones to the > charter as part of the re-chartering effort: > > ----- > > Nov 2014 Submit 'Token introspection' to the IESG for consideration as a > Proposed Standard > Starting point: > > Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as > a Proposed Standard > Starting point: > > Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a > Proposed Standard > Starting point: > > ----- > > We also updated the charter text to reflect the current situation. Here > is the proposed text: > > ----- > > Charter for Working Group > > > The Web Authorization (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that > supports OAuth could allow its users to use a third-party printing Web > site to print their private pictures, without allowing the printing > site to gain full control of the user's account and without having the > user share his or her photo-sharing sites' long-term credential with > the printing site. > > The OAuth 2.0 protocol suite encompasses > > * a protocol for obtaining access tokens from an authorization > server with the resource owner's consent, > * protocols for presenting these access tokens to resource server > for access to a protected resource, > * guidance for securely using OAuth 2.0, > * the ability to revoke access tokens, > * standardized format for security tokens encoded in a JSON format > (JSON Web Token, JWT), > * ways of using assertions with OAuth, and > * a dynamic client registration protocol. > > The working group also developed security schemes for presenting > authorization tokens to access a protected resource. This led to the > publication of the bearer token, as well as work that remains to be > completed on proof-of-possession and token exchange. > > The ongoing standardization effort within the OAuth working group will > focus on enhancing interoperability and functionality of OAuth > deployments, such as a standard for a token introspection service and > standards for additional security of OAuth requests. > > ----- > > Feedback appreciated. > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > > [image: Ping Identity logo] > > *Brian Campbell* > Portfolio Architect > > *@* > > bcampbell@pingidentity.com > > [image: phone] > > +1 720.317.2061 > > Connect with us=E2=80=A6 > > [image: twitter logo] [image: youtube > logo] [image: LinkedIn logo]= [image: > Facebook logo] [image: Google+ > logo] [image: > slideshare logo] [image: > flipboard logo] [image: rss feed icon] > > [image: Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] > > > > _______________________________________________ > 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 > > > --047d7b5d428cfbf3b304f9656b47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
a4c is connect. =C2=A0 =C2=A0For example here's the sa= mple requests:

draft-hunt-oauth-v2-user-a4c-01, section = 2.1:=C2=A0

=C2=A0 =C2=A0 GET /authenticate?
<= div>=C2=A0 =C2=A0 response_type=3Dcode
=C2=A0 =C2=A0 &client_id=3Ds6BhdRkqt3
=C2=A0 =C2=A0 &= ;redirect_uri=3Dhttps%3A%2F%2Fclien= t.example.com%2Fcb
=C2=A0 =C2=A0 &state=3Daf0ifjsldkj
=C2=A0 =C2=A0 &prompt=3Dlogin
=C2=A0 =C2=A0 Host: server.examp= le.com

OpenID Connect Basic Client Implementer= 's Guide 1.0 - draft 33, section 2.1.2:

= =C2=A0 GET /authorize?
=C2=A0 =C2=A0 response_type=3Dcode
=C2=A0 =C2=A0 &client= _id=3Ds6BhdRkqt3
=C2=A0 =C2=A0 &redirect_uri=3Dhttps%3A%2F%2Fclient.example.org%2Fcb
=C2=A0 =C2=A0 &scope=3Dopenid%20profile
=C2=A0 =C2=A0 &state=3Daf0ifjsldkj HTTP/1.1
=C2=A0 Host:= server.example.com
=C2= =A0=C2=A0

The primary contribution of a4c in this = case seems to be malformed HTTP, and implying that implementors should depl= oy a redundant authenticate endpoint. =C2=A0

Sample Responses:

draft-h= unt-oauth-v2-user-a4c-01, section 2.4:=C2=A0

=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0HTTP/1.1 200 OK
= =C2=A0 =C2=A0 =C2=A0 =C2=A0Content-Type: application/json;charset=3DUTF-8
=C2=A0 =C2=A0 =C2=A0 =C2=A0Cache-Control: no-store
=C2=A0 = =C2=A0 =C2=A0 =C2=A0Pragma: no-cache
=C2=A0 =C2=A0 =C2=A0 =C2=A0{=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"access_token":"= ;2YotnFZFEjr1zCsicMWpAA",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= "token_type":"example",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"expires_in":3600,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"refresh_token":"tGzv3J= OkF0XG5Qx2TlKWIA",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"i= d_token":"eyJhbGciOiJub25lIn0.
=C2=A0 eyAic3ViIjoiNWRlZ= GNjOGItNzM1Yy00MDVmLWUwMjlmIiwicHJvZmlsZSI6Imh0
=C2=A0 dHBzOi8vZXhhbXBsZS5jb20vVXNlcnMvNWRlZGNjOGItNzM1Yy00MDVmLWUwMjl= m
=C2=A0 IiwiYXV0aF90aW1lIjoiMTM2Nzk1NjA5NiIsImV4cCI6IjEzNjgwNDI0= OTYiLCJh
=C2=A0 bHYiOiIyIiwiaWF0IjoiMTM2Nzk1NjA5OCIsImlzcyI6Imh0d= HBzOi8vc2VydmVy
=C2=A0 LmV4YW1wbGUuY29tIiwiYXVkIjoiczZCaGRSa3F0MyIsImV4YW1wbGVfc2Vzc2l= v
=C2=A0 bl9wYXJhbWV0ZXIiOiJleGFtcGxlX3ZhbHVlIn0=3D."
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0

=
OpenID Connect Basic Client Implementer's Guide 1.0 - draft 3= 3, section 2.1.6.2:

=C2=A0 =C2=A0
=C2=A0 HTTP/1.1 200 OK
=C2=A0 Content-Type: applic= ation/json
= =C2=A0 Cache-Control: no-store
=C2=A0 Pragma: no-= cache
=C2=A0 = {
=C2=A0 =C2= =A0"access_token":"SlAV32hkKG",
=C2=A0 =C2=A0"= ;token_type":"Bearer",
=C2=A0 =C2=A0"expires_in":3600,
=C2=A0 =C2=A0"re= fresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
=C2=A0 =C2=A0"= ;id_token":"eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso&qu= ot;
=C2=A0 }<= /div>
=C2=A0 =C2=A0 =C2=A0


a4c seems to toss in a l= ittle confusion with an arbitrary example token type.

We're still dealing wit= h ws-federation passive profile in saml dominated world. =C2=A0The oauth wo= rking group shouldn't repeat that sin.

-cmort


On Wed, May = 14, 2014 at 2:40 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:

There are folks that are not implementing co= nnect for various reasons (i.e. security reasons, complexity reasons, etc.)= . thus this is compatible with connect if folks want to move on to connect,=C2=A0 we surely don=E2=80=99t use con= nect everwhere as it=E2=80=99s over kill where we only need a the functiona= lity of a4c.

=C2=A0

From: Chuck Mortimore [mailto:cmortimore@salesforce.com]

Sent: Wednesday, May 14, 2014 9:39 AM
To: Anthony Nadalin
Cc: Phil Hunt; Brian Campbell; oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

=C2=A0

Can you point to one publicly available or publicly = documented implementation of a4c? =C2=A0 =C2=A0I've never seen one.<= /u>

=C2=A0

I will say the a4c spec is almost 100% overlapped wi= th OpenID Connect. =C2=A0 Some minor variations in claim names, but it adds= 0 incremental value over what we have in Connect. =C2=A0 =C2=A0<= /u>

=C2=A0

Connect is being successfully deployed at large scal= e. =C2=A0It would be irresponsible for this working group to confuse develo= pers and the industry with duplicate work, especially given this feels more= like an argument over signing IPR agreements.

=C2=A0

-cmort

=C2=A0

On Wed, May 14, 2014 at 8:47 AM, Anthony Nadalin <= ;tonynad@microso= ft.com> wrote:

I agree with Phil on this one, there are imp= lementations of this already and much interest

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

=C2=A0

On the contrary. I and others are interested.=C2=A0<= u>

=C2=A0

We are waiting for the charter to pick up the work.= =C2=A0

=C2=A0

Regardless there will be a new draft shortly.=C2=A0<= u>


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:=

I would object to '= OAuth Authentication' being picked up by the WG as a work item. The sta= rting point draft has expired and it hasn't really been discusses since= Berlin nearly a year ago.=C2=A0 As I recall, there was only very limited interest in it even th= en. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Po= ssession for Code Extension' for which there is an excellent starting p= oint of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a re= lativity simple security enhancement which addresses problems currently bei= ng encountered in deployments of native clients.=C2=A0

=C2=A0

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig &l= t;hannes.tsc= hofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration= as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideratio= n as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a=
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the<= br> user share his or her photo-sharing sites' long-term credential with the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
=C2=A0 (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

3D"Ping

Brian Campbell
P= ortfolio Architect

@

bcampbell@pingidentity.com

3D"phone"

+1 720.317.2061

Connect with us=E2=80=A6<= /u>

3D"twitter3D"youtube=3D"LinkedIn3D"Facebook3D=3D"slideshare3D"flipboard= 3D"rss

3D"Regis=

=C2=A0

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


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

=C2=A0


--047d7b5d428cfbf3b304f9656b47-- From nobody Wed May 14 17:37:56 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1361A0393 for ; Wed, 14 May 2014 17:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 FRhgy-Bm9Eim for ; Wed, 14 May 2014 17:37:48 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42931A038B for ; Wed, 14 May 2014 17:37:47 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4F0bdxa019304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 00:37:40 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4F0bdYO007240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 May 2014 00:37:39 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4F0bd5t007230; Thu, 15 May 2014 00:37:39 GMT Received: from [130.35.50.173] (/130.35.50.173) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 May 2014 17:37:38 -0700 Message-ID: <53740C51.1080009@oracle.com> Date: Wed, 14 May 2014 17:37:37 -0700 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Anil Saldhana , oauth@ietf.org References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> In-Reply-To: <5373A8FA.9030601@redhat.com> Content-Type: multipart/alternative; boundary="------------000307010400020209080808" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jaQKlo_CZN-yZO2WCYZYvJllQec Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 00:37:52 -0000 This is a multi-part message in MIME format. --------------000307010400020209080808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Anil, the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the folks who have 100s of millions of users. And, BTW, implementing a few arbitrarily selected features from OIDC is not the same as implementing OIDC. As we all know, the core problem is that of adding an authenticator token to OAuth flows, which is a rather modest extension to OAuth. I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that the specification was "locked down" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification! The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely a minimal extension to OAuth flows to support an authenticator token. In my experience, this is the subset that most customers and implementors are looking for. - prateek > Tony/Phil, > any chance you can have this work done at OIDC? > > The reason is that it is commonly understood/accepted now that OAuth > provides authorization related specs while authentication/profile > related specs are coming from OIDC (which builds on top of OAuth2). > > Regards, > Anil > > On 05/14/2014 10:47 AM, Anthony Nadalin wrote: >> >> I agree with Phil on this one, there are implementations of this >> already and much interest >> >> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt >> *Sent:* Wednesday, May 14, 2014 8:32 AM >> *To:* Brian Campbell >> *Cc:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering >> >> On the contrary. I and others are interested. >> >> We are waiting for the charter to pick up the work. >> >> Regardless there will be a new draft shortly. >> >> >> Phil >> >> >> On May 14, 2014, at 5:24, Brian Campbell > > wrote: >> >> I would object to 'OAuth Authentication' being picked up by the >> WG as a work item. The starting point draft has expired and it >> hasn't really been discusses since Berlin nearly a year ago. As >> I recall, there was only very limited interest in it even then. I >> also don't believe it fits well with the WG charter. >> >> I would suggest the WG consider picking up 'OAuth Symmetric Proof >> of Possession for Code Extension' for which there is an excellent >> starting point of >> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a >> relativity simple security enhancement which addresses problems >> currently being encountered in deployments of native clients. >> >> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig >> > wrote: >> >> Hi all, >> >> you might have seen that we pushed the assertion documents >> and the JWT >> documents to the IESG today. We have also updated the >> milestones on the >> OAuth WG page. >> >> This means that we can plan to pick up new work in the group. >> We have sent a request to Kathleen to change the milestone >> for the OAuth >> security mechanisms to use the proof-of-possession terminology. >> >> We also expect an updated version of the dynamic client >> registration >> spec incorporating last call feedback within about 2 weeks. >> >> We would like you to think about adding the following >> milestones to the >> charter as part of the re-chartering effort: >> >> ----- >> >> Nov 2014 Submit 'Token introspection' to the IESG for >> consideration as a >> Proposed Standard >> Starting point: >> >> Jan 2015 Submit 'OAuth Authentication' to the IESG for >> consideration as >> a Proposed Standard >> Starting point: >> >> Jan 2015 Submit 'Token Exchange' to the IESG for >> consideration as a >> Proposed Standard >> Starting point: >> >> ----- >> >> We also updated the charter text to reflect the current >> situation. Here >> is the proposed text: >> >> ----- >> >> Charter for Working Group >> >> >> The Web Authorization (OAuth) protocol allows a user to grant a >> third-party Web site or application access to the user's >> protected >> resources, without necessarily revealing their long-term >> credentials, >> or even their identity. For example, a photo-sharing site that >> supports OAuth could allow its users to use a third-party >> printing Web >> site to print their private pictures, without allowing the >> printing >> site to gain full control of the user's account and without >> having the >> user share his or her photo-sharing sites' long-term >> credential with >> the printing site. >> >> The OAuth 2.0 protocol suite encompasses >> >> * a protocol for obtaining access tokens from an authorization >> server with the resource owner's consent, >> * protocols for presenting these access tokens to resource server >> for access to a protected resource, >> * guidance for securely using OAuth 2.0, >> * the ability to revoke access tokens, >> * standardized format for security tokens encoded in a JSON >> format >> (JSON Web Token, JWT), >> * ways of using assertions with OAuth, and >> * a dynamic client registration protocol. >> >> The working group also developed security schemes for presenting >> authorization tokens to access a protected resource. This led >> to the >> publication of the bearer token, as well as work that remains >> to be >> completed on proof-of-possession and token exchange. >> >> The ongoing standardization effort within the OAuth working >> group will >> focus on enhancing interoperability and functionality of OAuth >> deployments, such as a standard for a token introspection >> service and >> standards for additional security of OAuth requests. >> >> ----- >> >> Feedback appreciated. >> >> Ciao >> Hannes & Derek >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> -- >> >> Ping Identity logo >> >> >> >> *Brian Campbell* >> Portfolio Architect >> >> *@* >> >> >> >> bcampbell@pingidentity.com >> >> phone >> >> >> >> +1 720.317.2061 >> >> Connect with us... >> >> twitter logo youtube logo >> LinkedIn logo >> Facebook logo >> Google+ logo >> slideshare >> logo flipboard logo >> rss feed icon >> >> >> Register for Cloud Identity Summit 2014 | Modern Identity >> Revolution | 19--23 July, 2014 | Monterey, CA >> >> >> _______________________________________________ >> 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 --------------000307010400020209080808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Anil,

the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token to OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that  the specification was "locked down" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely a minimal extension to OAuth flows to support an authenticator token.  In my experience, this is the subset that most customers and implementors are looking for.


- prateek




Tony/Phil,
  any chance you can have this work done at OIDC?

The reason is that it is commonly understood/accepted now that OAuth provides authorization related specs while authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:

I agree with Phil on this one, there are implementations of this already and much interest

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

On the contrary. I and others are interested. 

 

We are waiting for the charter to pick up the work. 

 

Regardless there will be a new draft shortly. 


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

Ping Identity logo

Brian Campbell
Portfolio Architect

@

bcampbell@pingidentity.com

phone

+1 720.317.2061

Connect with us…

twitter logoyoutube logoLinkedIn logoFacebook logoGoogle+ logoslideshare logoflipboard logorss feed icon

Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA

 

_______________________________________________
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

--------------000307010400020209080808-- From nobody Wed May 14 17:45:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0491A021C for ; Wed, 14 May 2014 17:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 BHwBfbw6-JY6 for ; Wed, 14 May 2014 17:44:53 -0700 (PDT) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D72DC1A0302 for ; Wed, 14 May 2014 17:44:52 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wo20so401313obc.6 for ; Wed, 14 May 2014 17:44:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VotP2+QRzrIsVX5INGGQnZvPtFwFiHej8/7kZ/voIbI=; b=aCM1/gH/4H7gdSdaUblAb6pDlNiB36zmaX5eoKPZcyucif1R+tA8JTBz5mq8+srBzj t7ENrZJqJnaBa09QdfSgAXjSXn+7UXg/Ron+1GD/y8iPjiG17+b3/eTy79Mq7A9/LPTb YhxxinKJ6rzm9bQktnZmDIbDN/2EXsZd3yC7cxS7956ZXAbYuh67QSUv89xsV1JYCaX1 ZmyyQ065AW1Qdk4O1S3ywttWKs1BuE4o+RS+SA8UJsWP3eRwirg1ytX671SEbVlICckx rKBcSQ/Kz+6ygT+o30nUmLW7cbmCIqnpVWrRcCilb8UYhbCIe1JNLUWYNNwGCXnKM37r ERPA== X-Gm-Message-State: ALoCoQnVdupRfsWpllx7osc6gaYK5ueh1XJFwnz9yCz1GtwDwAGr/fSHY8NgyG4fQNwytRCgwEur MIME-Version: 1.0 X-Received: by 10.60.132.12 with SMTP id oq12mr6828209oeb.42.1400114684629; Wed, 14 May 2014 17:44:44 -0700 (PDT) Received: by 10.76.75.169 with HTTP; Wed, 14 May 2014 17:44:44 -0700 (PDT) In-Reply-To: <53740C51.1080009@oracle.com> References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> Date: Wed, 14 May 2014 17:44:44 -0700 Message-ID: From: Chuck Mortimore To: Prateek Mishra Content-Type: multipart/alternative; boundary=047d7b47286e6c2bca04f9659ad5 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/4fww7wJ22w5a1FO0x5eYcTQrTVw Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 00:44:57 -0000 --047d7b47286e6c2bca04f9659ad5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement." I believe you're looking for this: http://openid.net/specs/openid-connect-basic-1_0.html -cmort On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra wrote: > Anil, > > the challenge is that OIDC is a rather large set of specifications, and t= o > my knowledge even the core specification has NOT found > a complete implementation at any large IdP. I am not talking here about > boutique toolkits or startups, I am talking about the folks > who have 100s of millions of users. And, BTW, implementing a few > arbitrarily selected features from OIDC is not the same as implementing > OIDC. > > As we all know, the core problem is that of adding an authenticator token > to OAuth flows, which is a rather modest extension to OAuth. > > I had personally requested the OIDC community about six months ago to > describe some minimal subset which we could all reasonably implement. I w= as > told that the specification was "locked down" and fully debugged and so > on, so no changes could be made. Imagine my surprise to find that in the > final drafts there was a whole new flow - the hybrid flow - that had been > added at the last minute. I had never heard of the hybrid flow in the OAu= th > context - have you? So now you have an even larger specification! > > The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes > precisely a minimal extension to OAuth flows to support an authenticator > token. In my experience, this is the subset that most customers and > implementors are looking for. > > > - prateek > > > > > > Tony/Phil, > any chance you can have this work done at OIDC? > > The reason is that it is commonly understood/accepted now that OAuth > provides authorization related specs while authentication/profile > related specs are coming from OIDC (which builds on top of OAuth2). > > Regards, > Anil > > On 05/14/2014 10:47 AM, Anthony Nadalin wrote: > > I agree with Phil on this one, there are implementations of this already > and much interest > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O= n > Behalf Of *Phil Hunt > *Sent:* Wednesday, May 14, 2014 8:32 AM > *To:* Brian Campbell > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering > > > > On the contrary. I and others are interested. > > > > We are waiting for the charter to pick up the work. > > > > Regardless there will be a new draft shortly. > > > Phil > > > On May 14, 2014, at 5:24, Brian Campbell > wrote: > > I would object to 'OAuth Authentication' being picked up by the WG as a > work item. The starting point draft has expired and it hasn't really been > discusses since Berlin nearly a year ago. As I recall, there was only ve= ry > limited interest in it even then. I also don't believe it fits well with > the WG charter. > > I would suggest the WG consider picking up 'OAuth Symmetric Proof of > Possession for Code Extension' for which there is an excellent starting > point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a > relativity simple security enhancement which addresses problems currently > being encountered in deployments of native clients. > > > > On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > > Hi all, > > you might have seen that we pushed the assertion documents and the JWT > documents to the IESG today. We have also updated the milestones on the > OAuth WG page. > > This means that we can plan to pick up new work in the group. > We have sent a request to Kathleen to change the milestone for the OAuth > security mechanisms to use the proof-of-possession terminology. > > We also expect an updated version of the dynamic client registration > spec incorporating last call feedback within about 2 weeks. > > We would like you to think about adding the following milestones to the > charter as part of the re-chartering effort: > > ----- > > Nov 2014 Submit 'Token introspection' to the IESG for consideration as a > Proposed Standard > Starting point: > > Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as > a Proposed Standard > Starting point: > > Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a > Proposed Standard > Starting point: > > ----- > > We also updated the charter text to reflect the current situation. Here > is the proposed text: > > ----- > > Charter for Working Group > > > The Web Authorization (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that > supports OAuth could allow its users to use a third-party printing Web > site to print their private pictures, without allowing the printing > site to gain full control of the user's account and without having the > user share his or her photo-sharing sites' long-term credential with > the printing site. > > The OAuth 2.0 protocol suite encompasses > > * a protocol for obtaining access tokens from an authorization > server with the resource owner's consent, > * protocols for presenting these access tokens to resource server > for access to a protected resource, > * guidance for securely using OAuth 2.0, > * the ability to revoke access tokens, > * standardized format for security tokens encoded in a JSON format > (JSON Web Token, JWT), > * ways of using assertions with OAuth, and > * a dynamic client registration protocol. > > The working group also developed security schemes for presenting > authorization tokens to access a protected resource. This led to the > publication of the bearer token, as well as work that remains to be > completed on proof-of-possession and token exchange. > > The ongoing standardization effort within the OAuth working group will > focus on enhancing interoperability and functionality of OAuth > deployments, such as a standard for a token introspection service and > standards for additional security of OAuth requests. > > ----- > > Feedback appreciated. > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > > [image: Ping Identity logo] > > *Brian Campbell* > Portfolio Architect > > *@* > > bcampbell@pingidentity.com > > [image: phone] > > +1 720.317.2061 > > Connect with us=E2=80=A6 > > [image: twitter logo] [image: youtube > logo] [image: LinkedIn logo]= [image: > Facebook logo] [image: Google+ > logo] [image: > slideshare logo] [image: > flipboard logo] [image: rss feed icon] > > [image: Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] > > > > _______________________________________________ > 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --047d7b47286e6c2bca04f9659ad5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"I had personally requeste= d the OIDC community about six months ago to describe some minimal subset w= hich we could all reasonably implement."

I believe you're looking for this:= http://o= penid.net/specs/openid-connect-basic-1_0.html

-cmort


=
On Wed, May 14, 2014 at 5:37 PM, Prateek Mis= hra <prateek.mishra@oracle.com> wrote:
=20 =20 =20
Anil,

the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token to OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that=C2=A0 the specification was "locked dow= n" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely a minimal extension to OAuth flows to support an authenticator token.=C2=A0 In my experience, this is the subset that mo= st customers and implementors are looking for.


- prateek





=20
Tony/Phil,
=C2=A0 any chance you can have this work done at OIDC?

The reason is that it is commonly understood/accepted now that OAuth provides authorization related specs while authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:
=20 =20 =20 =20

I agree with Phil on this one, there are implementations of this already and much interest

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

=C2=A0

On the contrary. I and others are interested.=C2=A0

=C2=A0

We are waiting for the charter to pick up the work.=C2=A0

=C2=A0

Regardless there will be a new draft shortly.=C2=A0


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com<= /a>> wrote:

= =C2=A0

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the = IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the= IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG = for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
=C2=A0 (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

=

Brian Campbell
Portfolio Architect

@

bcampbell@pingidentity.com

3D"phone"

+1 720.317.2061

Connec= t with us=E2=80=A6

3D"twitter3D"youtube3D"LinkedIn3D"Facebook3D"Google+= 3D"slideshare3D"flipboard= 3D"rss=

= 3D"Regi==

=C2=A0

______________________________________= _________
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




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


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


--047d7b47286e6c2bca04f9659ad5-- From nobody Wed May 14 18:18:23 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6781A00F9 for ; Wed, 14 May 2014 18:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.841 X-Spam-Level: X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 ma01ucCO_odt for ; Wed, 14 May 2014 18:18:16 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4311A01D5 for ; Wed, 14 May 2014 18:18:15 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4F1I695021484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 01:18:08 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4F1I5pT019716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 May 2014 01:18:06 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4F1I52g019698; Thu, 15 May 2014 01:18:05 GMT Received: from [192.168.1.188] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 May 2014 18:18:04 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_74AC5E75-6FE3-459F-820F-1CCB89D9AC50" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: Date: Wed, 14 May 2014 18:18:03 -0700 Message-Id: <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> To: Chuck & Mara Mortimore X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/F-VkAELloDZs3LVG9CxOBFgU6VU Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 01:18:20 -0000 --Apple-Mail=_74AC5E75-6FE3-459F-820F-1CCB89D9AC50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 That=92s not a minimalistic authn only profile. If you return both an access token AND an id token than the service = provide has to implement both and the client has to figure out what to = do with it. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 14, 2014, at 5:44 PM, Chuck Mortimore = wrote: > "I had personally requested the OIDC community about six months ago to = describe some minimal subset which we could all reasonably implement." >=20 > I believe you're looking for this: = http://openid.net/specs/openid-connect-basic-1_0.html >=20 > -cmort >=20 >=20 >=20 > On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra = wrote: > Anil, >=20 > the challenge is that OIDC is a rather large set of specifications, = and to my knowledge even the core specification has NOT found > a complete implementation at any large IdP. I am not talking here = about boutique toolkits or startups, I am talking about the folks > who have 100s of millions of users. And, BTW, implementing a few = arbitrarily selected features from OIDC is not the same as implementing = OIDC. >=20 > As we all know, the core problem is that of adding an authenticator = token to OAuth flows, which is a rather modest extension to OAuth. >=20 > I had personally requested the OIDC community about six months ago to = describe some minimal subset which we could all reasonably implement. I = was told that the specification was "locked down" and fully debugged = and so on, so no changes could be made. Imagine my surprise to find that = in the final drafts there was a whole new flow - the hybrid flow - that = had been added at the last minute. I had never heard of the hybrid flow = in the OAuth context - have you? So now you have an even larger = specification! >=20 > The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes = precisely a minimal extension to OAuth flows to support an authenticator = token. In my experience, this is the subset that most customers and = implementors are looking for.=20 >=20 >=20 > - prateek >=20 >=20 >=20 >=20 >=20 >> Tony/Phil, >> any chance you can have this work done at OIDC?=20 >>=20 >> The reason is that it is commonly understood/accepted now that OAuth = provides authorization related specs while authentication/profile >> related specs are coming from OIDC (which builds on top of OAuth2). >>=20 >> Regards, >> Anil >>=20 >> On 05/14/2014 10:47 AM, Anthony Nadalin wrote: >>> I agree with Phil on this one, there are implementations of this = already and much interest >>>=20 >>> =20 >>>=20 >>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt >>> Sent: Wednesday, May 14, 2014 8:32 AM >>> To: Brian Campbell >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering >>>=20 >>> =20 >>>=20 >>> On the contrary. I and others are interested.=20 >>>=20 >>> =20 >>>=20 >>> We are waiting for the charter to pick up the work.=20 >>>=20 >>> =20 >>>=20 >>> Regardless there will be a new draft shortly.=20 >>>=20 >>>=20 >>> Phil >>>=20 >>>=20 >>> On May 14, 2014, at 5:24, Brian Campbell = wrote: >>>=20 >>> I would object to 'OAuth Authentication' being picked up by the WG = as a work item. The starting point draft has expired and it hasn't = really been discusses since Berlin nearly a year ago. As I recall, = there was only very limited interest in it even then. I also don't = believe it fits well with the WG charter. >>>=20 >>> I would suggest the WG consider picking up 'OAuth Symmetric Proof of = Possession for Code Extension' for which there is an excellent starting = point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's = a relativity simple security enhancement which addresses problems = currently being encountered in deployments of native clients. =20 >>>=20 >>>=20 >>> =20 >>>=20 >>> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig = wrote: >>>=20 >>> Hi all, >>>=20 >>> you might have seen that we pushed the assertion documents and the = JWT >>> documents to the IESG today. We have also updated the milestones on = the >>> OAuth WG page. >>>=20 >>> This means that we can plan to pick up new work in the group. >>> We have sent a request to Kathleen to change the milestone for the = OAuth >>> security mechanisms to use the proof-of-possession terminology. >>>=20 >>> We also expect an updated version of the dynamic client registration >>> spec incorporating last call feedback within about 2 weeks. >>>=20 >>> We would like you to think about adding the following milestones to = the >>> charter as part of the re-chartering effort: >>>=20 >>> ----- >>>=20 >>> Nov 2014 Submit 'Token introspection' to the IESG for consideration = as a >>> Proposed Standard >>> Starting point: >>>=20 >>> Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration = as >>> a Proposed Standard >>> Starting point: >>>=20 >>> Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a >>> Proposed Standard >>> Starting point: >>>=20 >>> ----- >>>=20 >>> We also updated the charter text to reflect the current situation. = Here >>> is the proposed text: >>>=20 >>> ----- >>>=20 >>> Charter for Working Group >>>=20 >>>=20 >>> The Web Authorization (OAuth) protocol allows a user to grant a >>> third-party Web site or application access to the user's protected >>> resources, without necessarily revealing their long-term = credentials, >>> or even their identity. For example, a photo-sharing site that >>> supports OAuth could allow its users to use a third-party printing = Web >>> site to print their private pictures, without allowing the printing >>> site to gain full control of the user's account and without having = the >>> user share his or her photo-sharing sites' long-term credential with >>> the printing site. >>>=20 >>> The OAuth 2.0 protocol suite encompasses >>>=20 >>> * a protocol for obtaining access tokens from an authorization >>> server with the resource owner's consent, >>> * protocols for presenting these access tokens to resource server >>> for access to a protected resource, >>> * guidance for securely using OAuth 2.0, >>> * the ability to revoke access tokens, >>> * standardized format for security tokens encoded in a JSON format >>> (JSON Web Token, JWT), >>> * ways of using assertions with OAuth, and >>> * a dynamic client registration protocol. >>>=20 >>> The working group also developed security schemes for presenting >>> authorization tokens to access a protected resource. This led to the >>> publication of the bearer token, as well as work that remains to be >>> completed on proof-of-possession and token exchange. >>>=20 >>> The ongoing standardization effort within the OAuth working group = will >>> focus on enhancing interoperability and functionality of OAuth >>> deployments, such as a standard for a token introspection service = and >>> standards for additional security of OAuth requests. >>>=20 >>> ----- >>>=20 >>> Feedback appreciated. >>>=20 >>> Ciao >>> Hannes & Derek >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>>=20 >>>=20 >>>=20 >>> Brian Campbell >>> Portfolio Architect >>>=20 >>> @ >>>=20 >>> bcampbell@pingidentity.com >>>=20 >>>=20 >>>=20 >>> +1 720.317.2061 >>>=20 >>> Connect with us=85 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> =20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_74AC5E75-6FE3-459F-820F-1CCB89D9AC50 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 That=92s= not a minimalistic authn only profile.

If you return = both an access token AND an id token than the service provide has to = implement both and the client has to figure out what to do with = it.
= --Apple-Mail=_CBAAAE58-35C2-4F99-ABAB-CB0A91AFB2FF-- From nobody Fri May 16 09:35:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446261A027A for ; Fri, 16 May 2014 09:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 yglz3IiFeKfE for ; Fri, 16 May 2014 09:35:26 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3551A00B5 for ; Fri, 16 May 2014 09:32:53 -0700 (PDT) Received: from mail-ie0-f171.google.com ([209.85.223.171]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKU3Y9rUuuPTdlAbBJST7DBRws4uUFaK/K@postini.com; Fri, 16 May 2014 09:32:46 PDT Received: by mail-ie0-f171.google.com with SMTP id rl12so2777431iec.16 for ; Fri, 16 May 2014 09:32:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6M5uWRWsOXVvrAiUVSt/8V/iYY9PWOrShaJ+EbqzgRU=; b=mA2v8bMrBwkj9DPXoiZv4jCNt2CimPd9/qvUwUSp2vmTB0BW9x5uobcOaKdS8PDJxV VvPDUReACAazCSD5sgpkM522EQKm7Sww5oZge0me6k0bWrWs0jBR2bejmwKDyTbbh8m2 LLT+gUipH64m8HGhu1oc6IZBAs2tSWra1+vETcVG+Xg9gSuBEsLVUh8XVkBfmeoa3aDJ E2dNNNohHc2uAFpJeUpbmbbA50pIPhg5M4nuQuZdY1nYLw0crmk/X145wZx0VZf2nMZN oU6ZTrdE7KdM8mRfebuWcNBJ9jbHhJK0+EObXGf6MhF9TYXyaItg0PaxykONfKDRlqX5 gTxA== X-Gm-Message-State: ALoCoQlceJXedPZEaMd9vEn0yAbKeoXYJD3yAQFN5wHSa9Sh8eRoprRFQtgaKt0SYCz8ILFlNozczTSq94P6jANKEe8DRLYerpGoQB5uTYU7Lbz0nvzvdsVYJZKPyp+P+LnRlYHAbxWQ X-Received: by 10.50.109.230 with SMTP id hv6mr21889343igb.9.1400257965142; Fri, 16 May 2014 09:32:45 -0700 (PDT) X-Received: by 10.50.109.230 with SMTP id hv6mr21889309igb.9.1400257964915; Fri, 16 May 2014 09:32:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Fri, 16 May 2014 09:32:14 -0700 (PDT) In-Reply-To: References: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> From: Brian Campbell Date: Fri, 16 May 2014 10:32:14 -0600 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=089e013a1d8e97d45304f986f622 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/4UQszrgrmzgjFuz62cPpVijbH7I Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 16:35:29 -0000 --089e013a1d8e97d45304f986f622 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, I agree with John here. There are a few good reasons to restrict the length of the code_challenge. One is trying to keep the authorization request URI to reasonable size as it will eventually run into various limits on clients and/or servers. The other is constraining the amount of data that an AS needs to store per code. On Fri, May 16, 2014 at 7:41 AM, John Bradley wrote: > From the AS side you probably want to know what the max size you need to > store per code. > > On the call to the token endpoint it is a POST so size should not be an > issue. > > > On May 16, 2014, at 3:10 PM, Nat Sakimura wrote: > > Now that I cannot remember what limit we were hitting, it might be a good > idea to remove the constraint and see if anyone protests. > > What do you think? > > Nat > > > 2014-05-14 20:46 GMT+09:00 Brian Campbell : > >> That too would suggest that the length limit be on code_challenge becaus= e >> that's the parameter that will be on URIs getting passed around. The >> code_verifier is sent directly in the POST body from client to AS. >> >> >> On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura wrote= : >> >>> +1 for octet. We used to have "bytes" in JW* so I used "bytes" here, >>> while at the same time complaining in Jose that it should be "octet". J= W* >>> changed to "octet" but I failed to sync with it in the last few edits. >>> >>> I do not quite remember which platform, but the reason for the limit wa= s >>> that some platform had some limitations as to the length of the sting t= o be >>> passed to it through URI and we did not want the challenges to be trunc= ated >>> by that limit. >>> >>> Best, >>> >>> Nat >>> >>> >>> 2014-05-13 6:56 GMT+09:00 Brian Campbell : >>> >>> And it'd give the AS some direct guidance on protecting itself from >>>> crazy long code_challenge values rather than relying on the client not= to >>>> do something creative. >>>> >>>> >>>> On Mon, May 12, 2014 at 3:54 PM, Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>>>> Right but that's why I'm asking why not just put the limit on >>>>> code_challange rather than inferring it from code_verifyer + challeng= e >>>>> algorithm, which probably bounds it but doesn't necessarily do so? It= 's not >>>>> a big deal but would read more clearly, I think. >>>>> >>>>> >>>>> On Mon, May 12, 2014 at 3:48 PM, John Bradley wrot= e: >>>>> >>>>>> I think octets is more consistent with other JW* and OAuth specs. >>>>>> >>>>>> The code_challange is the same length as the code_verifyer or is a >>>>>> hash of the code_verifyer so likely smaller than 128octets (43 ish f= or >>>>>> base64 256 bit) >>>>>> >>>>>> Limiting the code_verifyer size sets the upper bound for >>>>>> code_challange, unless someone comes up with a really creative code >>>>>> challenge algorithm. >>>>>> >>>>>> I will talk to nat about changing it to octets when I see him >>>>>> tomorrow. >>>>>> >>>>>> John B. >>>>>> >>>>>> On May 12, 2014, at 11:15 PM, Derek Atkins wrote: >>>>>> >>>>>> > Brian Campbell writes: >>>>>> > >>>>>> >> I notice that code_verifier is defined as "high entropy >>>>>> cryptographic random >>>>>> >> string of length less than 128 bytes" [1], which brought a few >>>>>> questions and >>>>>> >> comments to mind. So here goes: >>>>>> >> >>>>>> >> Talking about the length of a string in terms of bytes is always >>>>>> potentially >>>>>> >> confusing. Maybe characters would be an easier unit for people >>>>>> like me to wrap >>>>>> >> their little brains around? >>>>>> > >>>>>> > It depends if it really is characters or bytes. For example there >>>>>> are >>>>>> > many multi-byte UTF-8 characters, so if it really is bytes then >>>>>> saying >>>>>> > characters is wrong because it could overflow. So let's make sure >>>>>> we >>>>>> > know what we're talking about. Historically, if we're talking >>>>>> bytes the >>>>>> > IETF often uses the phrase "octets". Would that be less confusing= ? >>>>>> > >>>>>> >> Why are we putting a length restriction on the code_verifier >>>>>> anyway? It seems >>>>>> >> like it'd be more appropriate to restrict the length of the >>>>>> code_challenge >>>>>> >> because that's the thing the AS will have to maintain somehow >>>>>> (store in a DB >>>>>> >> or memory or encrypt into the code). Am I missing something here? >>>>>> >> >>>>>> >> Let me also say that I hadn't looked at this document since its >>>>>> early days in >>>>>> >> draft -00 or -01 last summer but I like the changes and how it's >>>>>> been kept >>>>>> >> pretty simple for the common use-case while still allowing for >>>>>> crypto agility/ >>>>>> >> extension. Nice work! >>>>>> >> >>>>>> >> [1] >>>>>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 >>>>>> > >>>>>> > -derek >>>>>> > >>>>>> >> _______________________________________________ >>>>>> >> OAuth mailing list >>>>>> >> OAuth@ietf.org >>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>> > >>>>>> > -- >>>>>> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >>>>>> > Member, MIT Student Information Processing Board (SIPB) >>>>>> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >>>>>> > warlord@MIT.EDU PGP key available >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> [image: Ping Identity logo] >>>>> Brian Campbell >>>>> Portfolio Architect >>>>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Conne= ct >>>>> with us=E2=80=A6 [image: twitter logo] [image: >>>>> youtube logo] [image: >>>>> LinkedIn logo] [image: >>>>> Facebook logo] [image: >>>>> Google+ logo] [im= age: >>>>> slideshare logo] [image: >>>>> flipboard logo] [image: rss feed icon] >>>>> [image: Register for Cloud Identity Summit 2014 | Modern Identity >>>>> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >>>>> >>>>> >>>> >>>> >>>> -- >>>> [image: Ping Identity logo] >>>> Brian Campbell >>>> Portfolio Architect >>>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connec= t >>>> with us=E2=80=A6 [image: twitter logo] [image: >>>> youtube logo] [image: >>>> LinkedIn logo] [image: >>>> Facebook logo] [image: >>>> Google+ logo] [ima= ge: >>>> slideshare logo] [image: >>>> flipboard logo] [image: rss feed icon] >>>> [image: Register for Cloud Identity Summit 2014 | Modern Identity >>>> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> [image: Ping Identity logo] >> Brian Campbell >> Portfolio Architect >> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect >> with us=E2=80=A6 [image: twitter logo] [image: >> youtube logo] [image: >> LinkedIn logo] [image: Facebook >> logo] [image: Google+ logo]<= https://plus.google.com/u/0/114266977739397708540> [image: >> slideshare logo] [image: >> flipboard logo] [image: rss feed icon] >> [image: Register for Cloud Identity Summit 2014 | Modern Identity >> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > --089e013a1d8e97d45304f986f622 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, I agree with John here. There are a few good reasons= to restrict the length of the code_challenge. One is trying to keep the au= thorization request URI to reasonable size as it will eventually run into v= arious limits on clients and/or servers. The other is constraining the amou= nt of data that an AS needs to store per code.




On Fri, May 16, 2014 at 7:41 AM, John Bradley <ve7jtb@ve7jtb.com><= /span> wrote:
From the= AS side you probably want to know what the max size you need to store per = code.

On the call to the token endpoint it is a POST so size = should not be an issue. =C2=A0

<= div>
On May 16, 2014, at 3:10 PM, Nat Sakimura <= sakimura@gmail.com<= /a>> wrote:

Now that I cannot remember w= hat limit we were hitting, it might be a good idea to remove the constraint= and see if anyone protests.=C2=A0

What do you think?=C2= =A0

Nat


2014-05-14 20= :46 GMT+09:00 Brian Campbell <bcampbell@pingidentity.com><= /span>:
That too would suggest that= the length limit be on code_challenge because that's the parameter tha= t will be on URIs getting passed around. The code_verifier is sent directly= in the POST body from client to AS.


On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura <sakimura@gmail.com= > wrote:
+1 for octet. We used to ha= ve "bytes" in JW* so I used "bytes" here, while at the = same time complaining in Jose that it should be "octet". JW* chan= ged to "octet" but I failed to sync with it in the last few edits= .=C2=A0

I do not quite remember which platform, but the reason for t= he limit was that some platform had some limitations as to the length of th= e sting to be passed to it through URI and we did not want the challenges t= o be truncated by that limit.=C2=A0

Best,=C2=A0

Nat


2014-05-13 6:56 = GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:

And it'd give the AS so= me direct guidance on protecting itself from crazy long code_challenge valu= es rather than relying on the client not to do something creative.


On Mon, May 12, 2014 at 3:54 PM, Brian Campb= ell <bcampbell@pingidentity.com> wrote:
Right but that's why I'm asking why not just put t= he limit on code_challange rather than inferring it from code_verifyer + ch= allenge algorithm, which probably bounds it but doesn't necessarily do = so? It's not a big deal but would read more clearly, I think.


On= Mon, May 12, 2014 at 3:48 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I think octets is more consistent with other= JW* and OAuth specs.

The code_challange is the same length as the code_verifyer or is a hash of = the code_verifyer so likely smaller than 128octets (43 ish for base64 256 b= it)

Limiting the code_verifyer size sets the upper bound for code_challange, un= less someone comes up with a really creative code challenge algorithm.

I will talk to nat about changing it to octets when I see him tomorrow.

John B.

On May 12, 2014, at 11:15 PM, Derek Atkins <warlord@MIT.EDU> wrote:

> Brian Campbell <bcampbell@pingidentity.com> writes:
>
>> I notice that code_verifier is defined as "high entropy crypt= ographic random
>> string of length less than 128 bytes" =C2=A0[1], which brough= t a few questions and
>> comments to mind. So here goes:
>>
>> Talking about the length of a string in terms of bytes is always p= otentially
>> confusing. Maybe characters would be an easier unit for people lik= e me to wrap
>> their little brains around?
>
> It depends if it really is characters or bytes. =C2=A0For example ther= e are
> many multi-byte UTF-8 characters, so if it really is bytes then saying=
> characters is wrong because it could overflow. =C2=A0So let's make= sure we
> know what we're talking about. =C2=A0Historically, if we're ta= lking bytes the
> IETF often uses the phrase "octets". =C2=A0Would that be les= s confusing?
>
>> Why are we putting a length restriction on the code_verifier anywa= y? It seems
>> like it'd be more appropriate to restrict the length of the co= de_challenge
>> because that's the thing the AS will have to maintain somehow = (store in a DB
>> or memory or encrypt into the code). Am I missing something here?<= br> >>
>> Let me also say that I hadn't looked at this document since it= s early days in
>> draft -00 or -01 last summer but I like the changes and how it'= ;s been kept
>> pretty simple for the common use-case while still allowing for cry= pto agility/
>> extension. Nice work!
>>
>> [1] http://tools.ietf.org/html/draft-sakimu= ra-oauth-tcse-03#section-3.3
>
> -derek
>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>
> --
> =C2=A0 =C2=A0 =C2=A0 Derek Atkins, SB '93 MIT EE, SM '95 MIT M= edia Laboratory
> =C2=A0 =C2=A0 =C2=A0 Member, MIT Student Information Processing Board = =C2=A0(SIPB)
> =C2=A0 =C2=A0 =C2=A0 URL: http://web.mit.edu/warlord/ =C2=A0 =C2=A0PP-ASEL-IA =C2= =A0 =C2=A0 N1NWH
> =C2=A0 =C2=A0 =C2=A0 warlord@MIT.EDU =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PGP key available




--
3D"Ping =09
Brian Campbell
Portfolio Architec= t
=09
@ bc= ampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register




--
3D"Ping =09
Brian Campbell
Portfolio Architec= t
=09
@ bc= ampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register


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




--
Nat Sakimura (=3Dnat)
Chairman, OpenI= D Foundation
http= ://nat.sakimura.org/
@_nat_en



--
3D"Ping =09
Brian Campbell
Portfolio Architec= t
=09
@ bc= ampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register




--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en


On May 14, 2014, at 5:44 PM, Chuck Mortimore <cmortimore@salesforce.com>= ; wrote:

"I had = personally requested the OIDC community about six months ago to describe = some minimal subset which we could all reasonably implement."

I believe you're looking for this: = http://open= id.net/specs/openid-connect-basic-1_0.html

-cmort



On Wed, May 14, = 2014 at 5:37 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:
=20 =20 =20
Anil,

the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the = folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token to OAuth flows, which is a rather modest extension to = OAuth.

I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that  the specification was "locked down" = and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely a minimal extension to OAuth flows to support an authenticator token.  In my experience, this is the subset that = most customers and implementors are looking for.


- prateek





=20
Tony/Phil,
  any chance you can have this work done at OIDC?

The reason is that it is commonly understood/accepted now that OAuth provides authorization related specs while authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:
=20 =20 =20 =20

I agree with Phil on this one, there are implementations of this already and much interest

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

On the contrary. I and others are interested. 

 

We are waiting for the charter to = pick up the work. 

 

Regardless there will be a new = draft shortly. 


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I recall, there was = only very limited interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients. 

 

On Thu, May 8, 2014 at 3:04 = PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

3D"Ping

Brian Campbell
Portfolio Architect

@

bcampbell@pingidentity.com

3D"phone"

+1 720.317.2061

Connect with = us=85

3D"twitter3D"youtube3D"LinkedIn3D"Facebook3D"Google+3D"slideshare3D"flipboard3D"rss

3D"Register

 

_______________________________________________
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=_74AC5E75-6FE3-459F-820F-1CCB89D9AC50-- From nobody Wed May 14 18:22:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379DB1A0120 for ; Wed, 14 May 2014 18:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 sZi67s71b0iL for ; Wed, 14 May 2014 18:22:06 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1C81A00F9 for ; Wed, 14 May 2014 18:22:05 -0700 (PDT) X-AuditID: 1209190c-f79946d000000c3b-75-537416b5f37b Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 28.32.03131.5B614735; Wed, 14 May 2014 21:21:57 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s4F1LuJB018933; Wed, 14 May 2014 21:21:56 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4F1Lr3O003610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 May 2014 21:21:55 -0400 Message-ID: <537416A9.5060701@mit.edu> Date: Wed, 14 May 2014 21:21:45 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Phil Hunt , Chuck & Mara Mortimore References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> In-Reply-To: <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> Content-Type: multipart/alternative; boundary="------------040103060403080409040306" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUixCmqrLtVrCTY4Pk1LYsrz76yWpx8+4rN YsH8RnYHZo8lS34yeXx8eovFY/H5LqYA5igum5TUnMyy1CJ9uwSujAW3prIVrPvOXLHl+VvW BsbWZ4xdjJwcEgImEounzmKHsMUkLtxbz9bFyMUhJDCbSeL52UWMEM5GRok5FxvZIZzbTBJt 6xewgLTwCqhJ9DQtBRvFIqAqMXH1clYQmw3Inr/yFhOILSoQJbGr7xc7RL2gxMmZT4B6OThE BBIlLs42BAkzC8hKrDl3iRnEFhawl1i19CsrxK5ZzBJv7m8HS3AK2En07TnCBNEQJvGldTfT BEaBWUjGzkKSmgW0glnAWuLb7iKIsLzE9rdzmCFsbYlVvWeZkMUXMLKtYpRNya3SzU3MzClO TdYtTk7My0st0jXUy80s0UtNKd3ECI4ESZ4djG8OKh1iFOBgVOLhjZhaHCzEmlhWXJl7iFGS g0lJlPf2D6AQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV4TxpJgId6UxMqq1KJ8mJQ0B4uSOO9b a6tgIYH0xJLU7NTUgtQimKwMB4eSBK+OKFCjYFFqempFWmZOCUKaiYMTZDgP0PBukBre4oLE 3OLMdIj8KUZdjjvP17YwCbHk5eelSonzbhABKhIAKcoozYObA0tgrxjFgd4S5lUAGcUDTH5w k14BLWECWnLCrQhkSUkiQkqqgdFyZsCsvunqPxW/heoUuN+Re7JBjHuD5Fmj8In1xwKVT+1T XTApVHzmp36P/XPebtvderW1g2fzy65LFWcyP3Lt79jZk37dvVRSa2NA2Q5hg7rMycLTDy/9 GGrI02Z+eP3/hw/X7px5+7dCaZ9s1ae3AX++7H0d1KxgkCQn9y1I9KDhzifKqmuVWIozEg21 mIuKEwEBUJ9oOwMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TQ2padB_R2nr6eHPiP4-TIWi81g Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 01:22:13 -0000 This is a multi-part message in MIME format. --------------040103060403080409040306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit How is this functionally different from the a4c draft that also allows the return of both an id_token and an access token? -- Justin On 5/14/2014 9:18 PM, Phil Hunt wrote: > That's not a minimalistic authn only profile. > > If you return both an access token AND an id token than the service > provide has to implement both and the client has to figure out what to > do with it. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On May 14, 2014, at 5:44 PM, Chuck Mortimore > > wrote: > >> "I had personally requested the OIDC community about six months ago >> to describe some minimal subset which we could all reasonably implement." >> >> I believe you're looking for this: >> http://openid.net/specs/openid-connect-basic-1_0.html >> >> -cmort >> >> >> >> On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra >> > wrote: >> >> Anil, >> >> the challenge is that OIDC is a rather large set of >> specifications, and to my knowledge even the core specification >> has NOT found >> a complete implementation at any large IdP. I am not talking here >> about boutique toolkits or startups, I am talking about the folks >> who have 100s of millions of users. And, BTW, implementing a few >> arbitrarily selected features from OIDC is not the same as >> implementing OIDC. >> >> As we all know, the core problem is that of adding an >> authenticator token to OAuth flows, which is a rather modest >> extension to OAuth. >> >> I had personally requested the OIDC community about six months >> ago to describe some minimal subset which we could all reasonably >> implement. I was told that the specification was "locked down" >> and fully debugged and so on, so no changes could be made. >> Imagine my surprise to find that in the final drafts there was a >> whole new flow - the hybrid flow - that had been added at the >> last minute. I had never heard of the hybrid flow in the OAuth >> context - have you? So now you have an even larger specification! >> >> The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes >> precisely a minimal extension to OAuth flows to support an >> authenticator token. In my experience, this is the subset that >> most customers and implementors are looking for. >> >> >> - prateek >> >> >> >> >> >>> Tony/Phil, >>> any chance you can have this work done at OIDC? >>> >>> The reason is that it is commonly understood/accepted now that >>> OAuth provides authorization related specs while >>> authentication/profile >>> related specs are coming from OIDC (which builds on top of OAuth2). >>> >>> Regards, >>> Anil >>> >>> On 05/14/2014 10:47 AM, Anthony Nadalin wrote: >>>> >>>> I agree with Phil on this one, there are implementations of >>>> this already and much interest >>>> >>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of >>>> *Phil Hunt >>>> *Sent:* Wednesday, May 14, 2014 8:32 AM >>>> *To:* Brian Campbell >>>> *Cc:* oauth@ietf.org >>>> *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering >>>> >>>> On the contrary. I and others are interested. >>>> >>>> We are waiting for the charter to pick up the work. >>>> >>>> Regardless there will be a new draft shortly. >>>> >>>> >>>> Phil >>>> >>>> >>>> On May 14, 2014, at 5:24, Brian Campbell >>>> >>> > wrote: >>>> >>>> I would object to 'OAuth Authentication' being picked up by >>>> the WG as a work item. The starting point draft has expired >>>> and it hasn't really been discusses since Berlin nearly a >>>> year ago. As I recall, there was only very limited >>>> interest in it even then. I also don't believe it fits well >>>> with the WG charter. >>>> >>>> I would suggest the WG consider picking up 'OAuth Symmetric >>>> Proof of Possession for Code Extension' for which there is >>>> an excellent starting point of >>>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - >>>> it's a relativity simple security enhancement which >>>> addresses problems currently being encountered in >>>> deployments of native clients. >>>> >>>> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig >>>> >>> > wrote: >>>> >>>> Hi all, >>>> >>>> you might have seen that we pushed the assertion >>>> documents and the JWT >>>> documents to the IESG today. We have also updated the >>>> milestones on the >>>> OAuth WG page. >>>> >>>> This means that we can plan to pick up new work in the >>>> group. >>>> We have sent a request to Kathleen to change the >>>> milestone for the OAuth >>>> security mechanisms to use the proof-of-possession >>>> terminology. >>>> >>>> We also expect an updated version of the dynamic client >>>> registration >>>> spec incorporating last call feedback within about 2 weeks. >>>> >>>> We would like you to think about adding the following >>>> milestones to the >>>> charter as part of the re-chartering effort: >>>> >>>> ----- >>>> >>>> Nov 2014 Submit 'Token introspection' to the IESG for >>>> consideration as a >>>> Proposed Standard >>>> Starting point: >>>> >>>> Jan 2015 Submit 'OAuth Authentication' to the IESG for >>>> consideration as >>>> a Proposed Standard >>>> Starting point: >>>> >>>> Jan 2015 Submit 'Token Exchange' to the IESG for >>>> consideration as a >>>> Proposed Standard >>>> Starting point: >>>> >>>> ----- >>>> >>>> We also updated the charter text to reflect the current >>>> situation. Here >>>> is the proposed text: >>>> >>>> ----- >>>> >>>> Charter for Working Group >>>> >>>> >>>> The Web Authorization (OAuth) protocol allows a user to >>>> grant a >>>> third-party Web site or application access to the >>>> user's protected >>>> resources, without necessarily revealing their >>>> long-term credentials, >>>> or even their identity. For example, a photo-sharing >>>> site that >>>> supports OAuth could allow its users to use a >>>> third-party printing Web >>>> site to print their private pictures, without allowing >>>> the printing >>>> site to gain full control of the user's account and >>>> without having the >>>> user share his or her photo-sharing sites' long-term >>>> credential with >>>> the printing site. >>>> >>>> The OAuth 2.0 protocol suite encompasses >>>> >>>> * a protocol for obtaining access tokens from an >>>> authorization >>>> server with the resource owner's consent, >>>> * protocols for presenting these access tokens to >>>> resource server >>>> for access to a protected resource, >>>> * guidance for securely using OAuth 2.0, >>>> * the ability to revoke access tokens, >>>> * standardized format for security tokens encoded in a >>>> JSON format >>>> (JSON Web Token, JWT), >>>> * ways of using assertions with OAuth, and >>>> * a dynamic client registration protocol. >>>> >>>> The working group also developed security schemes for >>>> presenting >>>> authorization tokens to access a protected resource. >>>> This led to the >>>> publication of the bearer token, as well as work that >>>> remains to be >>>> completed on proof-of-possession and token exchange. >>>> >>>> The ongoing standardization effort within the OAuth >>>> working group will >>>> focus on enhancing interoperability and functionality >>>> of OAuth >>>> deployments, such as a standard for a token >>>> introspection service and >>>> standards for additional security of OAuth requests. >>>> >>>> ----- >>>> >>>> Feedback appreciated. >>>> >>>> Ciao >>>> Hannes & Derek >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Ping Identity logo >>>> >>>> >>>> >>>> *Brian Campbell* >>>> Portfolio Architect >>>> >>>> *@* >>>> >>>> >>>> >>>> bcampbell@pingidentity.com >>>> >>>> phone >>>> >>>> >>>> >>>> +1 720.317.2061 >>>> >>>> Connect with us... >>>> >>>> twitter logo youtube logo >>>> LinkedIn logo >>>> Facebook logo >>>> Google+ logo >>>> slideshare >>>> logo flipboard logo >>>> rss feed icon >>>> >>>> >>>> Register for Cloud Identity Summit 2014 | Modern Identity >>>> Revolution | 19--23 July, 2014 | Monterey, CA >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------040103060403080409040306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
How is this functionally different from the a4c draft that also allows the return of both an id_token and an access token?

 -- Justin

On 5/14/2014 9:18 PM, Phil Hunt wrote:
That’s not a minimalistic authn only profile.

If you return both an access token AND an id token than the service provide has to implement both and the client has to figure out what to do with it.


On May 14, 2014, at 5:44 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote:

"I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement."

I believe you're looking for this: http://openid.net/specs/openid-connect-basic-1_0.html

-cmort



On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:
Anil,

the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token to OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that  the specification was "locked down" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely a minimal extension to OAuth flows to support an authenticator token.  In my experience, this is the subset that most customers and implementors are looking for.


- prateek





Tony/Phil,
  any chance you can have this work done at OIDC?

The reason is that it is commonly understood/accepted now that OAuth provides authorization related specs while authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:

I agree with Phil on this one, there are implementations of this already and much interest

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

On the contrary. I and others are interested. 

 

We are waiting for the charter to pick up the work. 

 

Regardless there will be a new draft shortly. 


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

Ping Identity logo

Brian Campbell
Portfolio Architect

@

bcampbell@pingidentity.com

phone

+1 720.317.2061

Connect with us…

twitter logoyoutube logoLinkedIn logoFacebook logoGoogle+ logoslideshare logoflipboard logorss feed icon

Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA

 

_______________________________________________
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



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

--------------040103060403080409040306-- From nobody Wed May 14 18:24:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EE71A01D5 for ; Wed, 14 May 2014 18:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.841 X-Spam-Level: X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 olmiHVHNjqvl for ; Wed, 14 May 2014 18:24:22 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9CF1A00F9 for ; Wed, 14 May 2014 18:24:22 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4F1OEu2026210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 01:24:15 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4F1ODlh018920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 May 2014 01:24:14 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4F1ODe4001488; Thu, 15 May 2014 01:24:13 GMT Received: from [192.168.1.188] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 May 2014 18:24:13 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_398377B8-39B8-4A8A-9765-314599E701A6" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: <537416A9.5060701@mit.edu> Date: Wed, 14 May 2014 18:24:10 -0700 Message-Id: References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> <537416A9.5060701@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TRRjvNX_uvK1GI0wq1Yl825N4c8 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 01:24:25 -0000 --Apple-Mail=_398377B8-39B8-4A8A-9765-314599E701A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It isn=92t required (or should not be). This issue is OIDC = compatibility. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 14, 2014, at 6:21 PM, Justin Richer wrote: > How is this functionally different from the a4c draft that also allows = the return of both an id_token and an access token?=20 >=20 > -- Justin >=20 > On 5/14/2014 9:18 PM, Phil Hunt wrote: >> That=92s not a minimalistic authn only profile. >>=20 >> If you return both an access token AND an id token than the service = provide has to implement both and the client has to figure out what to = do with it. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On May 14, 2014, at 5:44 PM, Chuck Mortimore = wrote: >>=20 >>> "I had personally requested the OIDC community about six months ago = to describe some minimal subset which we could all reasonably = implement." >>>=20 >>> I believe you're looking for this: = http://openid.net/specs/openid-connect-basic-1_0.html >>>=20 >>> -cmort >>>=20 >>>=20 >>>=20 >>> On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra = wrote: >>> Anil, >>>=20 >>> the challenge is that OIDC is a rather large set of specifications, = and to my knowledge even the core specification has NOT found >>> a complete implementation at any large IdP. I am not talking here = about boutique toolkits or startups, I am talking about the folks >>> who have 100s of millions of users. And, BTW, implementing a few = arbitrarily selected features from OIDC is not the same as implementing = OIDC. >>>=20 >>> As we all know, the core problem is that of adding an authenticator = token to OAuth flows, which is a rather modest extension to OAuth. >>>=20 >>> I had personally requested the OIDC community about six months ago = to describe some minimal subset which we could all reasonably implement. = I was told that the specification was "locked down" and fully debugged = and so on, so no changes could be made. Imagine my surprise to find that = in the final drafts there was a whole new flow - the hybrid flow - that = had been added at the last minute. I had never heard of the hybrid flow = in the OAuth context - have you? So now you have an even larger = specification! >>>=20 >>> The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes = precisely a minimal extension to OAuth flows to support an authenticator = token. In my experience, this is the subset that most customers and = implementors are looking for.=20 >>>=20 >>>=20 >>> - prateek >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> Tony/Phil, >>>> any chance you can have this work done at OIDC?=20 >>>>=20 >>>> The reason is that it is commonly understood/accepted now that = OAuth provides authorization related specs while authentication/profile >>>> related specs are coming from OIDC (which builds on top of OAuth2). >>>>=20 >>>> Regards, >>>> Anil >>>>=20 >>>> On 05/14/2014 10:47 AM, Anthony Nadalin wrote: >>>>> I agree with Phil on this one, there are implementations of this = already and much interest >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt >>>>> Sent: Wednesday, May 14, 2014 8:32 AM >>>>> To: Brian Campbell >>>>> Cc: oauth@ietf.org >>>>> Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering >>>>>=20 >>>>> =20 >>>>> On the contrary. I and others are interested.=20 >>>>>=20 >>>>> =20 >>>>> We are waiting for the charter to pick up the work.=20 >>>>>=20 >>>>> =20 >>>>> Regardless there will be a new draft shortly.=20 >>>>>=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>>=20 >>>>> On May 14, 2014, at 5:24, Brian Campbell = wrote: >>>>>=20 >>>>> I would object to 'OAuth Authentication' being picked up by the WG = as a work item. The starting point draft has expired and it hasn't = really been discusses since Berlin nearly a year ago. As I recall, = there was only very limited interest in it even then. I also don't = believe it fits well with the WG charter. >>>>>=20 >>>>> I would suggest the WG consider picking up 'OAuth Symmetric Proof = of Possession for Code Extension' for which there is an excellent = starting point of = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a = relativity simple security enhancement which addresses problems = currently being encountered in deployments of native clients. =20 >>>>>=20 >>>>> =20 >>>>> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig = wrote: >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> you might have seen that we pushed the assertion documents and the = JWT >>>>> documents to the IESG today. We have also updated the milestones = on the >>>>> OAuth WG page. >>>>>=20 >>>>> This means that we can plan to pick up new work in the group. >>>>> We have sent a request to Kathleen to change the milestone for the = OAuth >>>>> security mechanisms to use the proof-of-possession terminology. >>>>>=20 >>>>> We also expect an updated version of the dynamic client = registration >>>>> spec incorporating last call feedback within about 2 weeks. >>>>>=20 >>>>> We would like you to think about adding the following milestones = to the >>>>> charter as part of the re-chartering effort: >>>>>=20 >>>>> ----- >>>>>=20 >>>>> Nov 2014 Submit 'Token introspection' to the IESG for = consideration as a >>>>> Proposed Standard >>>>> Starting point: >>>>>=20 >>>>> Jan 2015 Submit 'OAuth Authentication' to the IESG for = consideration as >>>>> a Proposed Standard >>>>> Starting point: >>>>>=20 >>>>> Jan 2015 Submit 'Token Exchange' to the IESG for consideration as = a >>>>> Proposed Standard >>>>> Starting point: >>>>>=20 >>>>> ----- >>>>>=20 >>>>> We also updated the charter text to reflect the current situation. = Here >>>>> is the proposed text: >>>>>=20 >>>>> ----- >>>>>=20 >>>>> Charter for Working Group >>>>>=20 >>>>>=20 >>>>> The Web Authorization (OAuth) protocol allows a user to grant a >>>>> third-party Web site or application access to the user's protected >>>>> resources, without necessarily revealing their long-term = credentials, >>>>> or even their identity. For example, a photo-sharing site that >>>>> supports OAuth could allow its users to use a third-party printing = Web >>>>> site to print their private pictures, without allowing the = printing >>>>> site to gain full control of the user's account and without having = the >>>>> user share his or her photo-sharing sites' long-term credential = with >>>>> the printing site. >>>>>=20 >>>>> The OAuth 2.0 protocol suite encompasses >>>>>=20 >>>>> * a protocol for obtaining access tokens from an authorization >>>>> server with the resource owner's consent, >>>>> * protocols for presenting these access tokens to resource server >>>>> for access to a protected resource, >>>>> * guidance for securely using OAuth 2.0, >>>>> * the ability to revoke access tokens, >>>>> * standardized format for security tokens encoded in a JSON format >>>>> (JSON Web Token, JWT), >>>>> * ways of using assertions with OAuth, and >>>>> * a dynamic client registration protocol. >>>>>=20 >>>>> The working group also developed security schemes for presenting >>>>> authorization tokens to access a protected resource. This led to = the >>>>> publication of the bearer token, as well as work that remains to = be >>>>> completed on proof-of-possession and token exchange. >>>>>=20 >>>>> The ongoing standardization effort within the OAuth working group = will >>>>> focus on enhancing interoperability and functionality of OAuth >>>>> deployments, such as a standard for a token introspection service = and >>>>> standards for additional security of OAuth requests. >>>>>=20 >>>>> ----- >>>>>=20 >>>>> Feedback appreciated. >>>>>=20 >>>>> Ciao >>>>> Hannes & Derek >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Brian Campbell >>>>> Portfolio Architect >>>>>=20 >>>>> @ >>>>>=20 >>>>> bcampbell@pingidentity.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>> +1 720.317.2061 >>>>>=20 >>>>> Connect with us=85 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_398377B8-39B8-4A8A-9765-314599E701A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 It = isn=92t required (or should not be).  This issue is OIDC = compatibility.


On May 14, 2014, at 6:21 PM, Justin Richer = <jricher@mit.edu> = wrote:

=20 =20
How is this functionally different = from the a4c draft that also allows the return of both an id_token and an access token?

 -- Justin

On 5/14/2014 9:18 PM, Phil Hunt wrote:
That=92s not a minimalistic authn only profile.

If you return both an access token AND an id token than the service provide has to implement both and the client has to figure out what to do with it.


On May 14, 2014, at 5:44 PM, Chuck Mortimore <cmortimore@salesforce.com>= ; wrote:

"I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably = implement."

I believe you're looking for this: http://open= id.net/specs/openid-connect-basic-1_0.html

-cmort



On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:
Anil,

the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily selected features from OIDC is not the same as implementing = OIDC.

As we all know, the core problem is that of adding an authenticator token to OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that  the specification was "locked = down" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely a minimal extension to OAuth flows to support an authenticator = token.  In my experience, this is the subset that most customers and implementors are looking for.


- prateek





Tony/Phil,
  any chance you can have this work = done at OIDC?

The reason is that it is commonly understood/accepted now that OAuth provides authorization related specs while authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:

I agree with Phil on this one, there are implementations of this already and much interest

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil = Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

On the = contrary. I and others are = interested. 

 

We are = waiting for the charter to pick up the work. 

 

Regardless = there will be a new draft = shortly. 


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I recall, = there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients. 

 

On = Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: = <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: = <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: = <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working = Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential = with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, = JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service = and
standards for additional security of OAuth = requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

3D"Ping

Brian = Campbell
Portfolio = Architect

@

bcampbell@pingidentity.com

3D"phone"

+1 720.317.2061

Connect with = us=85

3D"twitter3D"youtube3D"LinkedIn3D"Facebook3D"Google+3D"slideshare3D"flipboard3D"rss

3D"Register
 

_______________________________________________
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



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


= --Apple-Mail=_398377B8-39B8-4A8A-9765-314599E701A6-- From nobody Wed May 14 18:41:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3CE1A0253 for ; Wed, 14 May 2014 18:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 tZVCGrpvnvot for ; Wed, 14 May 2014 18:41:22 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1E21A0113 for ; Wed, 14 May 2014 18:41:22 -0700 (PDT) X-AuditID: 12074422-f79376d000000c58-ca-53741b3a5ef7 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 01.47.03160.A3B14735; Wed, 14 May 2014 21:41:14 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s4F1fDaa023572; Wed, 14 May 2014 21:41:14 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4F1fB94008794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 May 2014 21:41:12 -0400 Message-ID: <53741B2F.4040506@mit.edu> Date: Wed, 14 May 2014 21:41:03 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Phil Hunt References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> <537416A9.5060701@mit.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030706020706020006010006" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUixG6nrmslXRJssPWljcWVZ19ZLU6+fcVm sWB+I7sDs8eSJT+ZPD4+vcXisfh8F1MAcxSXTUpqTmZZapG+XQJXxqbJS5kLZjxmrfh8dgdL A+OV9UxdjJwcEgImEj+XzmSGsMUkLtxbz9bFyMUhJDCbSeLMpg2sEM5GRolrvYuhMreZJP4e vsYO0sIroCZxbcEHRhCbRUBV4uOF/awgNhuQPX/lLbAVogJRErv6fkHVC0qcnPmEBcQWEVCR +Hb1OlgvM1DNscevwWxhAXuJVUu/Qm1+zizR+usm2CBOATuJ3Ve/sEE0hEn83XaKdQKjwCwk c2chSUHYthJ35u5mhrDlJZq3zoaydSUWbVvBjiy+gJFtFaNsSm6Vbm5iZk5xarJucXJiXl5q ka6pXm5miV5qSukmRnA0uCjtYPx5UOkQowAHoxIPb8TU4mAh1sSy4srcQ4ySHExKorzfJEuC hfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwmjAC5XhTEiurUovyYVLSHCxK4rxvra2ChQTSE0tS s1NTC1KLYLIyHBxKEryRUkCNgkWp6akVaZk5JQhpJg5OkOE8QMPLQGp4iwsSc4sz0yHypxh1 Oe48X9vCJMSSl5+XKiXOaw1SJABSlFGaBzcHlsReMYoDvSXM2wVSxQNMgHCTXgEtYQJacsKt CGRJSSJCSqqBMYZd3Oldz9drvm36mws4lpzLnP4pRWlOiX5ydLGifZTM/oX1r88/Wami8X/O 6pwfKeyqDyp6E/IFAo0KImrbZc5YurrekX/pKHNl2lT2tYEcxzo/zzE8EMKS3j3FvdO0ZKuq kvx3Hq2yO990m8v/mmrXM2ju6i6b8CSz5HqPhWlY1RUOHTslluKMREMt5qLiRACrlMFCPQMA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DzF0LsD5tsBAT70d9GX8F5zai24 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 01:41:29 -0000 This is a multi-part message in MIME format. --------------030706020706020006010006 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Actually, it's about OAuth compatibility. With OAuth, you get an access token to be used at a protected resource. That's what it's for, that's what clients do the OAuth dance(s) for. Connect defines that protected resource as the userinfo endpoint (ie, "tells the client what to do with it"). Connect also defines the id token that comes in along side of the bog-standard OAuth token, and Connect is turned on and off through the use of bog-standard OAuth scopes. So that makes it very, very, very easy to take an OAuth server and turn it into a Connect server. I know, I've done just that, and I've walked others through the process as well. But the a4c draft is using something that's almost-but-not-quite-OAuth: You might not get an access token, which is going to confuse the heck out of most OAuth clients that I know since that's what they're trying to get at in the first place, and there's no real way for a client to distinguish its request for something with an id_token vs. without. Additionally, in practice, that access token is hugely useful. Just look at all of the weird OpenID2 and OAuth1 hybrid stuff that people were trying to do back a few years ago on top of all the OpenID2 extensions -- this is exactly because OpenID2 was built for "authentication only" because that's what people thought developers wanted, but it turned out that developers wanted a whole lot more than that. This is one main reason the Facebook Connect and Twitter's OAuth-based login came along and ate everyone's lunch: they gave you authentication, but also something useful about the end user. All said, it sounds like you want Connect but without the UserInfo Endpoint. You'll be glad to know that you can already do that as per the MTI definitions of the server: http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI You are free to implement a SCIM endpoint (which, by the way, you'll probably need that access_token to access) or no endpoint at all, and a compliant client ought to be able to deal with that. In fact, there's a way to get just the id_token in Connect if that's all you care about, but instead of hiding it inside of an existing flow that might return something different depending on (currently-undefined) special circumstances, it puts this mode into a separate response_type entirely to enforce the point that it is different from regular OAuth. -- Justin On 5/14/2014 9:24 PM, Phil Hunt wrote: > It isn’t required (or should not be). This issue is OIDC compatibility. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On May 14, 2014, at 6:21 PM, Justin Richer > wrote: > >> How is this functionally different from the a4c draft that also >> allows the return of both an id_token and an access token? >> >> -- Justin >> >> On 5/14/2014 9:18 PM, Phil Hunt wrote: >>> That’s not a minimalistic authn only profile. >>> >>> If you return both an access token AND an id token than the service >>> provide has to implement both and the client has to figure out what >>> to do with it. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> On May 14, 2014, at 5:44 PM, Chuck Mortimore >>> > wrote: >>> >>>> "I had personally requested the OIDC community about six months ago >>>> to describe some minimal subset which we could all reasonably >>>> implement." >>>> >>>> I believe you're looking for this: >>>> http://openid.net/specs/openid-connect-basic-1_0.html >>>> >>>> -cmort >>>> >>>> >>>> >>>> On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra >>>> > wrote: >>>> >>>> Anil, >>>> >>>> the challenge is that OIDC is a rather large set of >>>> specifications, and to my knowledge even the core specification >>>> has NOT found >>>> a complete implementation at any large IdP. I am not talking >>>> here about boutique toolkits or startups, I am talking about >>>> the folks >>>> who have 100s of millions of users. And, BTW, implementing a >>>> few arbitrarily selected features from OIDC is not the same as >>>> implementing OIDC. >>>> >>>> As we all know, the core problem is that of adding an >>>> authenticator token to OAuth flows, which is a rather modest >>>> extension to OAuth. >>>> >>>> I had personally requested the OIDC community about six months >>>> ago to describe some minimal subset which we could all >>>> reasonably implement. I was told that the specification was >>>> "locked down" and fully debugged and so on, so no changes could >>>> be made. Imagine my surprise to find that in the final drafts >>>> there was a whole new flow - the hybrid flow - that had been >>>> added at the last minute. I had never heard of the hybrid flow >>>> in the OAuth context - have you? So now you have an even larger >>>> specification! >>>> >>>> The value of draft-hunt-oauth-v2-user-a4c-01 is that it >>>> describes precisely a minimal extension to OAuth flows to >>>> support an authenticator token. In my experience, this is the >>>> subset that most customers and implementors are looking for. >>>> >>>> >>>> - prateek >>>> >>>> >>>> >>>> >>>> >>>>> Tony/Phil, >>>>> any chance you can have this work done at OIDC? >>>>> >>>>> The reason is that it is commonly understood/accepted now that >>>>> OAuth provides authorization related specs while >>>>> authentication/profile >>>>> related specs are coming from OIDC (which builds on top of >>>>> OAuth2). >>>>> >>>>> Regards, >>>>> Anil >>>>> >>>>> On 05/14/2014 10:47 AM, Anthony Nadalin wrote: >>>>>> >>>>>> I agree with Phil on this one, there are implementations of >>>>>> this already and much interest >>>>>> >>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of >>>>>> *Phil Hunt >>>>>> *Sent:* Wednesday, May 14, 2014 8:32 AM >>>>>> *To:* Brian Campbell >>>>>> *Cc:* oauth@ietf.org >>>>>> *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering >>>>>> >>>>>> >>>>>> On the contrary. I and others are interested. >>>>>> >>>>>> >>>>>> We are waiting for the charter to pick up the work. >>>>>> >>>>>> >>>>>> Regardless there will be a new draft shortly. >>>>>> >>>>>> >>>>>> Phil >>>>>> >>>>>> >>>>>> On May 14, 2014, at 5:24, Brian Campbell >>>>>> >>>>> > wrote: >>>>>> >>>>>> I would object to 'OAuth Authentication' being picked up >>>>>> by the WG as a work item. The starting point draft has >>>>>> expired and it hasn't really been discusses since Berlin >>>>>> nearly a year ago. As I recall, there was only very >>>>>> limited interest in it even then. I also don't believe it >>>>>> fits well with the WG charter. >>>>>> >>>>>> I would suggest the WG consider picking up 'OAuth >>>>>> Symmetric Proof of Possession for Code Extension' for >>>>>> which there is an excellent starting point of >>>>>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - >>>>>> it's a relativity simple security enhancement which >>>>>> addresses problems currently being encountered in >>>>>> deployments of native clients. >>>>>> >>>>>> >>>>>> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig >>>>>> >>>>> > wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> you might have seen that we pushed the assertion >>>>>> documents and the JWT >>>>>> documents to the IESG today. We have also updated the >>>>>> milestones on the >>>>>> OAuth WG page. >>>>>> >>>>>> This means that we can plan to pick up new work in >>>>>> the group. >>>>>> We have sent a request to Kathleen to change the >>>>>> milestone for the OAuth >>>>>> security mechanisms to use the proof-of-possession >>>>>> terminology. >>>>>> >>>>>> We also expect an updated version of the dynamic >>>>>> client registration >>>>>> spec incorporating last call feedback within about 2 >>>>>> weeks. >>>>>> >>>>>> We would like you to think about adding the following >>>>>> milestones to the >>>>>> charter as part of the re-chartering effort: >>>>>> >>>>>> ----- >>>>>> >>>>>> Nov 2014 Submit 'Token introspection' to the IESG for >>>>>> consideration as a >>>>>> Proposed Standard >>>>>> Starting point: >>>>>> >>>>>> Jan 2015 Submit 'OAuth Authentication' to the IESG >>>>>> for consideration as >>>>>> a Proposed Standard >>>>>> Starting point: >>>>>> >>>>>> Jan 2015 Submit 'Token Exchange' to the IESG for >>>>>> consideration as a >>>>>> Proposed Standard >>>>>> Starting point: >>>>>> >>>>>> ----- >>>>>> >>>>>> We also updated the charter text to reflect the >>>>>> current situation. Here >>>>>> is the proposed text: >>>>>> >>>>>> ----- >>>>>> >>>>>> Charter for Working Group >>>>>> >>>>>> >>>>>> The Web Authorization (OAuth) protocol allows a user >>>>>> to grant a >>>>>> third-party Web site or application access to the >>>>>> user's protected >>>>>> resources, without necessarily revealing their >>>>>> long-term credentials, >>>>>> or even their identity. For example, a photo-sharing >>>>>> site that >>>>>> supports OAuth could allow its users to use a >>>>>> third-party printing Web >>>>>> site to print their private pictures, without >>>>>> allowing the printing >>>>>> site to gain full control of the user's account and >>>>>> without having the >>>>>> user share his or her photo-sharing sites' long-term >>>>>> credential with >>>>>> the printing site. >>>>>> >>>>>> The OAuth 2.0 protocol suite encompasses >>>>>> >>>>>> * a protocol for obtaining access tokens from an >>>>>> authorization >>>>>> server with the resource owner's consent, >>>>>> * protocols for presenting these access tokens to >>>>>> resource server >>>>>> for access to a protected resource, >>>>>> * guidance for securely using OAuth 2.0, >>>>>> * the ability to revoke access tokens, >>>>>> * standardized format for security tokens encoded in >>>>>> a JSON format >>>>>> (JSON Web Token, JWT), >>>>>> * ways of using assertions with OAuth, and >>>>>> * a dynamic client registration protocol. >>>>>> >>>>>> The working group also developed security schemes for >>>>>> presenting >>>>>> authorization tokens to access a protected resource. >>>>>> This led to the >>>>>> publication of the bearer token, as well as work that >>>>>> remains to be >>>>>> completed on proof-of-possession and token exchange. >>>>>> >>>>>> The ongoing standardization effort within the OAuth >>>>>> working group will >>>>>> focus on enhancing interoperability and functionality >>>>>> of OAuth >>>>>> deployments, such as a standard for a token >>>>>> introspection service and >>>>>> standards for additional security of OAuth requests. >>>>>> >>>>>> ----- >>>>>> >>>>>> Feedback appreciated. >>>>>> >>>>>> Ciao >>>>>> Hannes & Derek >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Ping Identity logo >>>>>> >>>>>> >>>>>> >>>>>> *Brian Campbell* >>>>>> Portfolio Architect >>>>>> >>>>>> *@* >>>>>> >>>>>> >>>>>> >>>>>> bcampbell@pingidentity.com >>>>>> >>>>>> >>>>>> phone >>>>>> >>>>>> >>>>>> >>>>>> +1 720.317.2061 >>>>>> >>>>>> Connect with us… >>>>>> >>>>>> twitter logo youtube >>>>>> logo >>>>>> LinkedIn >>>>>> logo Facebook >>>>>> logo Google+ >>>>>> logo >>>>>> slideshare >>>>>> logo flipboard >>>>>> logo rss feed icon >>>>>> >>>>>> >>>>>> Register for Cloud Identity Summit 2014 | Modern Identity >>>>>> Revolution | 19–23 July, 2014 | Monterey, CA >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > --------------030706020706020006010006 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Actually, it's about OAuth compatibility. With OAuth, you get an access token to be used at a protected resource. That's what it's for, that's what clients do the OAuth dance(s) for. Connect defines that protected resource as the userinfo endpoint (ie, "tells the client what to do with it"). Connect also defines the id token that comes in along side of the bog-standard OAuth token, and Connect is turned on and off through the use of bog-standard OAuth scopes. So that makes it very, very, very easy to take an OAuth server and turn it into a Connect server. I know, I've done just that, and I've walked others through the process as well.

But the a4c draft is using something that's almost-but-not-quite-OAuth: You might not get an access token, which is going to confuse the heck out of most OAuth clients that I know since that's what they're trying to get at in the first place, and there's no real way for a client to distinguish its request for something with an id_token vs. without. Additionally, in practice, that access token is hugely useful. Just look at all of the weird OpenID2 and OAuth1 hybrid stuff that people were trying to do back a few years ago on top of all the OpenID2 extensions -- this is exactly because OpenID2 was built for "authentication only" because that's what people thought developers wanted, but it turned out that developers wanted a whole lot more than that. This is one main reason the Facebook Connect and Twitter's OAuth-based login came along and ate everyone's lunch: they gave you authentication, but also something useful about the end user.

All said, it sounds like you want Connect but without the UserInfo Endpoint. You'll be glad to know that you can already do that as per the MTI definitions of the server:

  http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI

You are free to implement a SCIM endpoint (which, by the way, you'll probably need that access_token to access) or no endpoint at all, and a compliant client ought to be able to deal with that. In fact, there's a way to get just the id_token in Connect if that's all you care about, but instead of hiding it inside of an existing flow that might return something different depending on (currently-undefined) special circumstances, it puts this mode into a separate response_type entirely to enforce the point that it is different from regular OAuth.

 -- Justin

On 5/14/2014 9:24 PM, Phil Hunt wrote:
It isn’t required (or should not be).  This issue is OIDC compatibility.


On May 14, 2014, at 6:21 PM, Justin Richer <jricher@mit.edu> wrote:

How is this functionally different from the a4c draft that also allows the return of both an id_token and an access token?

 -- Justin

On 5/14/2014 9:18 PM, Phil Hunt wrote:
That’s not a minimalistic authn only profile.

If you return both an access token AND an id token than the service provide has to implement both and the client has to figure out what to do with it.


On May 14, 2014, at 5:44 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote:

"I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement."

I believe you're looking for this: http://openid.net/specs/openid-connect-basic-1_0.html

-cmort



On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:
Anil,

the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token to OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that  the specification was "locked down" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely a minimal extension to OAuth flows to support an authenticator token.  In my experience, this is the subset that most customers and implementors are looking for.


- prateek





Tony/Phil,
  any chance you can have this work done at OIDC?

The reason is that it is commonly understood/accepted now that OAuth provides authorization related specs while authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:

I agree with Phil on this one, there are implementations of this already and much interest

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

On the contrary. I and others are interested. 

 

We are waiting for the charter to pick up the work. 

 

Regardless there will be a new draft shortly. 


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

Ping Identity logo

Brian Campbell
Portfolio Architect

@

bcampbell@pingidentity.com

phone

+1 720.317.2061

Connect with us…

twitter logoyoutube logoLinkedIn logoFacebook logoGoogle+ logoslideshare logoflipboard logorss feed icon

Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA
 

_______________________________________________
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



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



--------------030706020706020006010006-- From nobody Wed May 14 18:43:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEA31A0383 for ; Wed, 14 May 2014 18:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.841 X-Spam-Level: X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 CHfCmcLVkGZU for ; Wed, 14 May 2014 18:43:04 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5AB41A0113 for ; Wed, 14 May 2014 18:43:03 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4F1gtJD009427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 01:42:56 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4F1gsWU003576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 May 2014 01:42:55 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4F1gsB7017114; Thu, 15 May 2014 01:42:54 GMT Received: from [192.168.1.188] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 May 2014 18:42:53 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_EAF93133-2FB8-4628-BCA2-9A5D83937821" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: <53741B2F.4040506@mit.edu> Date: Wed, 14 May 2014 18:42:53 -0700 Message-Id: <1F00EAF0-CC8F-469F-84F3-50C534325360@oracle.com> References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> <537416A9.5060701@mit.edu> <53741B2F.4040506@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/GT0ioj81gymFDR0S-yuJmmhOCco Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 01:43:09 -0000 --Apple-Mail=_EAF93133-2FB8-4628-BCA2-9A5D83937821 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Right. This is why it has a different point because the client does NOT = want a resource token. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 14, 2014, at 6:41 PM, Justin Richer wrote: > Actually, it's about OAuth compatibility. With OAuth, you get an = access token to be used at a protected resource. That's what it's for, = that's what clients do the OAuth dance(s) for. Connect defines that = protected resource as the userinfo endpoint (ie, "tells the client what = to do with it"). Connect also defines the id token that comes in along = side of the bog-standard OAuth token, and Connect is turned on and off = through the use of bog-standard OAuth scopes. So that makes it very, = very, very easy to take an OAuth server and turn it into a Connect = server. I know, I've done just that, and I've walked others through the = process as well.=20 >=20 > But the a4c draft is using something that's = almost-but-not-quite-OAuth: You might not get an access token, which is = going to confuse the heck out of most OAuth clients that I know since = that's what they're trying to get at in the first place, and there's no = real way for a client to distinguish its request for something with an = id_token vs. without. Additionally, in practice, that access token is = hugely useful. Just look at all of the weird OpenID2 and OAuth1 hybrid = stuff that people were trying to do back a few years ago on top of all = the OpenID2 extensions -- this is exactly because OpenID2 was built for = "authentication only" because that's what people thought developers = wanted, but it turned out that developers wanted a whole lot more than = that. This is one main reason the Facebook Connect and Twitter's = OAuth-based login came along and ate everyone's lunch: they gave you = authentication, but also something useful about the end user. >=20 > All said, it sounds like you want Connect but without the UserInfo = Endpoint. You'll be glad to know that you can already do that as per the = MTI definitions of the server: >=20 > http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI >=20 > You are free to implement a SCIM endpoint (which, by the way, you'll = probably need that access_token to access) or no endpoint at all, and a = compliant client ought to be able to deal with that. In fact, there's a = way to get just the id_token in Connect if that's all you care about, = but instead of hiding it inside of an existing flow that might return = something different depending on (currently-undefined) special = circumstances, it puts this mode into a separate response_type entirely = to enforce the point that it is different from regular OAuth.=20 >=20 > -- Justin >=20 > On 5/14/2014 9:24 PM, Phil Hunt wrote: >> It isn=92t required (or should not be). This issue is OIDC = compatibility. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On May 14, 2014, at 6:21 PM, Justin Richer wrote: >>=20 >>> How is this functionally different from the a4c draft that also = allows the return of both an id_token and an access token?=20 >>>=20 >>> -- Justin >>>=20 >>> On 5/14/2014 9:18 PM, Phil Hunt wrote: >>>> That=92s not a minimalistic authn only profile. >>>>=20 >>>> If you return both an access token AND an id token than the service = provide has to implement both and the client has to figure out what to = do with it. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>> On May 14, 2014, at 5:44 PM, Chuck Mortimore = wrote: >>>>=20 >>>>> "I had personally requested the OIDC community about six months = ago to describe some minimal subset which we could all reasonably = implement." >>>>>=20 >>>>> I believe you're looking for this: = http://openid.net/specs/openid-connect-basic-1_0.html >>>>>=20 >>>>> -cmort >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra = wrote: >>>>> Anil, >>>>>=20 >>>>> the challenge is that OIDC is a rather large set of = specifications, and to my knowledge even the core specification has NOT = found >>>>> a complete implementation at any large IdP. I am not talking here = about boutique toolkits or startups, I am talking about the folks >>>>> who have 100s of millions of users. And, BTW, implementing a few = arbitrarily selected features from OIDC is not the same as implementing = OIDC. >>>>>=20 >>>>> As we all know, the core problem is that of adding an = authenticator token to OAuth flows, which is a rather modest extension = to OAuth. >>>>>=20 >>>>> I had personally requested the OIDC community about six months ago = to describe some minimal subset which we could all reasonably implement. = I was told that the specification was "locked down" and fully debugged = and so on, so no changes could be made. Imagine my surprise to find that = in the final drafts there was a whole new flow - the hybrid flow - that = had been added at the last minute. I had never heard of the hybrid flow = in the OAuth context - have you? So now you have an even larger = specification! >>>>>=20 >>>>> The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes = precisely a minimal extension to OAuth flows to support an authenticator = token. In my experience, this is the subset that most customers and = implementors are looking for.=20 >>>>>=20 >>>>>=20 >>>>> - prateek >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Tony/Phil, >>>>>> any chance you can have this work done at OIDC?=20 >>>>>>=20 >>>>>> The reason is that it is commonly understood/accepted now that = OAuth provides authorization related specs while authentication/profile >>>>>> related specs are coming from OIDC (which builds on top of = OAuth2). >>>>>>=20 >>>>>> Regards, >>>>>> Anil >>>>>>=20 >>>>>> On 05/14/2014 10:47 AM, Anthony Nadalin wrote: >>>>>>> I agree with Phil on this one, there are implementations of this = already and much interest >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil = Hunt >>>>>>> Sent: Wednesday, May 14, 2014 8:32 AM >>>>>>> To: Brian Campbell >>>>>>> Cc: oauth@ietf.org >>>>>>> Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering >>>>>>>=20 >>>>>>> =20 >>>>>>> On the contrary. I and others are interested.=20 >>>>>>>=20 >>>>>>> =20 >>>>>>> We are waiting for the charter to pick up the work.=20 >>>>>>>=20 >>>>>>> =20 >>>>>>> Regardless there will be a new draft shortly.=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>>=20 >>>>>>> On May 14, 2014, at 5:24, Brian Campbell = wrote: >>>>>>>=20 >>>>>>> I would object to 'OAuth Authentication' being picked up by the = WG as a work item. The starting point draft has expired and it hasn't = really been discusses since Berlin nearly a year ago. As I recall, = there was only very limited interest in it even then. I also don't = believe it fits well with the WG charter. >>>>>>>=20 >>>>>>> I would suggest the WG consider picking up 'OAuth Symmetric = Proof of Possession for Code Extension' for which there is an excellent = starting point of = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a = relativity simple security enhancement which addresses problems = currently being encountered in deployments of native clients. =20 >>>>>>>=20 >>>>>>> =20 >>>>>>> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig = wrote: >>>>>>>=20 >>>>>>> Hi all, >>>>>>>=20 >>>>>>> you might have seen that we pushed the assertion documents and = the JWT >>>>>>> documents to the IESG today. We have also updated the milestones = on the >>>>>>> OAuth WG page. >>>>>>>=20 >>>>>>> This means that we can plan to pick up new work in the group. >>>>>>> We have sent a request to Kathleen to change the milestone for = the OAuth >>>>>>> security mechanisms to use the proof-of-possession terminology. >>>>>>>=20 >>>>>>> We also expect an updated version of the dynamic client = registration >>>>>>> spec incorporating last call feedback within about 2 weeks. >>>>>>>=20 >>>>>>> We would like you to think about adding the following milestones = to the >>>>>>> charter as part of the re-chartering effort: >>>>>>>=20 >>>>>>> ----- >>>>>>>=20 >>>>>>> Nov 2014 Submit 'Token introspection' to the IESG for = consideration as a >>>>>>> Proposed Standard >>>>>>> Starting point: >>>>>>>=20 >>>>>>> Jan 2015 Submit 'OAuth Authentication' to the IESG for = consideration as >>>>>>> a Proposed Standard >>>>>>> Starting point: >>>>>>>=20 >>>>>>> Jan 2015 Submit 'Token Exchange' to the IESG for consideration = as a >>>>>>> Proposed Standard >>>>>>> Starting point: >>>>>>>=20 >>>>>>> ----- >>>>>>>=20 >>>>>>> We also updated the charter text to reflect the current = situation. Here >>>>>>> is the proposed text: >>>>>>>=20 >>>>>>> ----- >>>>>>>=20 >>>>>>> Charter for Working Group >>>>>>>=20 >>>>>>>=20 >>>>>>> The Web Authorization (OAuth) protocol allows a user to grant a >>>>>>> third-party Web site or application access to the user's = protected >>>>>>> resources, without necessarily revealing their long-term = credentials, >>>>>>> or even their identity. For example, a photo-sharing site that >>>>>>> supports OAuth could allow its users to use a third-party = printing Web >>>>>>> site to print their private pictures, without allowing the = printing >>>>>>> site to gain full control of the user's account and without = having the >>>>>>> user share his or her photo-sharing sites' long-term credential = with >>>>>>> the printing site. >>>>>>>=20 >>>>>>> The OAuth 2.0 protocol suite encompasses >>>>>>>=20 >>>>>>> * a protocol for obtaining access tokens from an authorization >>>>>>> server with the resource owner's consent, >>>>>>> * protocols for presenting these access tokens to resource = server >>>>>>> for access to a protected resource, >>>>>>> * guidance for securely using OAuth 2.0, >>>>>>> * the ability to revoke access tokens, >>>>>>> * standardized format for security tokens encoded in a JSON = format >>>>>>> (JSON Web Token, JWT), >>>>>>> * ways of using assertions with OAuth, and >>>>>>> * a dynamic client registration protocol. >>>>>>>=20 >>>>>>> The working group also developed security schemes for presenting >>>>>>> authorization tokens to access a protected resource. This led to = the >>>>>>> publication of the bearer token, as well as work that remains to = be >>>>>>> completed on proof-of-possession and token exchange. >>>>>>>=20 >>>>>>> The ongoing standardization effort within the OAuth working = group will >>>>>>> focus on enhancing interoperability and functionality of OAuth >>>>>>> deployments, such as a standard for a token introspection = service and >>>>>>> standards for additional security of OAuth requests. >>>>>>>=20 >>>>>>> ----- >>>>>>>=20 >>>>>>> Feedback appreciated. >>>>>>>=20 >>>>>>> Ciao >>>>>>> Hannes & Derek >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Brian Campbell >>>>>>> Portfolio Architect >>>>>>>=20 >>>>>>> @ >>>>>>>=20 >>>>>>> bcampbell@pingidentity.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> +1 720.317.2061 >>>>>>>=20 >>>>>>> Connect with us=85 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> =20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> 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 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >=20 --Apple-Mail=_EAF93133-2FB8-4628-BCA2-9A5D83937821 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Right. =  This is why it has a different point because the client does NOT = want a resource token.


On May 14, 2014, at 6:41 PM, Justin Richer <jricher@mit.edu> wrote:

=20 =20
Actually, it's about OAuth compatibility. With OAuth, you get an access token to be used at a protected resource. That's what it's for, that's what clients do the OAuth dance(s) for. Connect defines that protected resource as the userinfo endpoint (ie, "tells the client what to do with it"). Connect also defines the id token that comes in along side of the bog-standard OAuth token, and Connect is turned on and off through the use of bog-standard OAuth scopes. So that makes it very, very, very easy to take an OAuth server and turn it into a Connect server. I know, I've done just that, and I've walked others through the process as well.

But the a4c draft is using something that's almost-but-not-quite-OAuth: You might not get an access token, which is going to confuse the heck out of most OAuth clients that I know since that's what they're trying to get at in the first place, and there's no real way for a client to distinguish its request for something with an id_token vs. without. Additionally, in practice, that access token is hugely useful. Just look at all of the weird OpenID2 and OAuth1 hybrid stuff that people were trying to do back a few years ago on top of all the OpenID2 extensions -- this is exactly because OpenID2 was built for "authentication only" because that's what people thought developers wanted, but it turned out that developers wanted a whole lot more than that. This is one main reason the Facebook Connect and Twitter's OAuth-based login came along and ate everyone's lunch: they gave you authentication, but also something useful about the end user.

All said, it sounds like you want Connect but without the UserInfo Endpoint. You'll be glad to know that you can already do that as per the MTI definitions of the server:

  ht= tp://openid.net/specs/openid-connect-core-1_0.html#ServerMTI

You are free to implement a SCIM endpoint (which, by the way, you'll probably need that access_token to access) or no endpoint at all, and a compliant client ought to be able to deal with that. In fact, there's a way to get just the id_token in Connect if that's all you care about, but instead of hiding it inside of an existing flow that might return something different depending on (currently-undefined) special circumstances, it puts this mode into a separate response_type entirely to enforce the point that it is different from regular OAuth.

 -- Justin

On 5/14/2014 9:24 PM, Phil Hunt wrote:
It isn=92t required (or should not be).  This issue is OIDC compatibility.


On May 14, 2014, at 6:21 PM, Justin Richer <jricher@mit.edu> wrote:

How is this functionally different from the a4c draft that also allows the return of both an id_token and an access token?

 -- Justin

On 5/14/2014 9:18 PM, Phil Hunt wrote:
That=92s not a minimalistic authn only profile.

If you return both an access token AND an id token than the service provide has to implement both and the client has to figure out what to do with = it.


On May 14, 2014, at 5:44 PM, Chuck Mortimore <cmortimore@salesforce.com>= ; wrote:

"I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably = implement."

I believe you're looking for this: http://open= id.net/specs/openid-connect-basic-1_0.html

-cmort



On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:
= Anil,

the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token to OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that  the specification was "locked down" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely a minimal extension to OAuth flows to support an authenticator token.  In my experience, this is the subset that most customers and implementors are looking for.


- prateek





Tony/Phil,
  any chance you can have = this work done at OIDC?

The reason is that it is commonly understood/accepted now that OAuth provides authorization related specs while = authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:

I agree with Phil on this one, there are implementations of this already and much interest

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of = Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and = Rechartering

 

On= the contrary. I and others are = interested. 

 

We= are waiting for the charter to pick up the work. 

 

Regardless there will be a new draft shortly. 


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I = recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native = clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG = page.

This means that we can plan to pick up new work in the = group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the = proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 = weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration = as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. = Here
is the proposed text:

-----

Charter for Working = Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's = protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential = with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an = authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource = server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for = presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to = be
completed on = proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth = requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

3D"Ping

Brian = Campbell
Portfolio = Architect

@

bcampbell@pingidentity.com

3D"phone"

+1 720.317.2061

Connect with = us=85

3D"twitter3D"youtube3D"LinkedIn3D"Facebook3D"Google+3D"slideshare3D"flipboard3D"rss

3D"Register
 

_______________________________________________
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



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




= --Apple-Mail=_EAF93133-2FB8-4628-BCA2-9A5D83937821-- From nobody Wed May 14 18:44:06 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2ED1A0391 for ; Wed, 14 May 2014 18:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.841 X-Spam-Level: X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 hfqoqOLkftE7 for ; Wed, 14 May 2014 18:43:55 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8DC1A039B for ; Wed, 14 May 2014 18:43:54 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4F1hkPP000339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 01:43:47 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4F1hj4C004933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 May 2014 01:43:46 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4F1hjsO004929; Thu, 15 May 2014 01:43:45 GMT Received: from [192.168.1.188] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 May 2014 18:43:44 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_0C45AE3E-DE49-4A0A-BF5A-391CC442F7BE" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: <1F00EAF0-CC8F-469F-84F3-50C534325360@oracle.com> Date: Wed, 14 May 2014 18:43:43 -0700 Message-Id: <51BD7E1D-5C8D-4B6F-8F3C-64137CBDA0DA@oracle.com> References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> <537416A9.5060701@mit.edu> <53741B2F.4040506@mit.edu> <1F00EAF0-CC8F-469F-84F3-50C534325360@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/CCa4Oh-3QO431O4OETfUH560Aw4 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 01:44:00 -0000 --Apple-Mail=_0C45AE3E-DE49-4A0A-BF5A-391CC442F7BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sorry I meant to say this is why it has the /authenticate endpoint to = indicate the client only wants the users session information. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 14, 2014, at 6:42 PM, Phil Hunt wrote: > Right. This is why it has a different point because the client does = NOT want a resource token. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On May 14, 2014, at 6:41 PM, Justin Richer wrote: >=20 >> Actually, it's about OAuth compatibility. With OAuth, you get an = access token to be used at a protected resource. That's what it's for, = that's what clients do the OAuth dance(s) for. Connect defines that = protected resource as the userinfo endpoint (ie, "tells the client what = to do with it"). Connect also defines the id token that comes in along = side of the bog-standard OAuth token, and Connect is turned on and off = through the use of bog-standard OAuth scopes. So that makes it very, = very, very easy to take an OAuth server and turn it into a Connect = server. I know, I've done just that, and I've walked others through the = process as well.=20 >>=20 >> But the a4c draft is using something that's = almost-but-not-quite-OAuth: You might not get an access token, which is = going to confuse the heck out of most OAuth clients that I know since = that's what they're trying to get at in the first place, and there's no = real way for a client to distinguish its request for something with an = id_token vs. without. Additionally, in practice, that access token is = hugely useful. Just look at all of the weird OpenID2 and OAuth1 hybrid = stuff that people were trying to do back a few years ago on top of all = the OpenID2 extensions -- this is exactly because OpenID2 was built for = "authentication only" because that's what people thought developers = wanted, but it turned out that developers wanted a whole lot more than = that. This is one main reason the Facebook Connect and Twitter's = OAuth-based login came along and ate everyone's lunch: they gave you = authentication, but also something useful about the end user. >>=20 >> All said, it sounds like you want Connect but without the UserInfo = Endpoint. You'll be glad to know that you can already do that as per the = MTI definitions of the server: >>=20 >> http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI >>=20 >> You are free to implement a SCIM endpoint (which, by the way, you'll = probably need that access_token to access) or no endpoint at all, and a = compliant client ought to be able to deal with that. In fact, there's a = way to get just the id_token in Connect if that's all you care about, = but instead of hiding it inside of an existing flow that might return = something different depending on (currently-undefined) special = circumstances, it puts this mode into a separate response_type entirely = to enforce the point that it is different from regular OAuth.=20 >>=20 >> -- Justin >>=20 >> On 5/14/2014 9:24 PM, Phil Hunt wrote: >>> It isn=92t required (or should not be). This issue is OIDC = compatibility. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>> On May 14, 2014, at 6:21 PM, Justin Richer wrote: >>>=20 >>>> How is this functionally different from the a4c draft that also = allows the return of both an id_token and an access token?=20 >>>>=20 >>>> -- Justin >>>>=20 >>>> On 5/14/2014 9:18 PM, Phil Hunt wrote: >>>>> That=92s not a minimalistic authn only profile. >>>>>=20 >>>>> If you return both an access token AND an id token than the = service provide has to implement both and the client has to figure out = what to do with it. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On May 14, 2014, at 5:44 PM, Chuck Mortimore = wrote: >>>>>=20 >>>>>> "I had personally requested the OIDC community about six months = ago to describe some minimal subset which we could all reasonably = implement." >>>>>>=20 >>>>>> I believe you're looking for this: = http://openid.net/specs/openid-connect-basic-1_0.html >>>>>>=20 >>>>>> -cmort >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra = wrote: >>>>>> Anil, >>>>>>=20 >>>>>> the challenge is that OIDC is a rather large set of = specifications, and to my knowledge even the core specification has NOT = found >>>>>> a complete implementation at any large IdP. I am not talking here = about boutique toolkits or startups, I am talking about the folks >>>>>> who have 100s of millions of users. And, BTW, implementing a few = arbitrarily selected features from OIDC is not the same as implementing = OIDC. >>>>>>=20 >>>>>> As we all know, the core problem is that of adding an = authenticator token to OAuth flows, which is a rather modest extension = to OAuth. >>>>>>=20 >>>>>> I had personally requested the OIDC community about six months = ago to describe some minimal subset which we could all reasonably = implement. I was told that the specification was "locked down" and = fully debugged and so on, so no changes could be made. Imagine my = surprise to find that in the final drafts there was a whole new flow - = the hybrid flow - that had been added at the last minute. I had never = heard of the hybrid flow in the OAuth context - have you? So now you = have an even larger specification! >>>>>>=20 >>>>>> The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes = precisely a minimal extension to OAuth flows to support an authenticator = token. In my experience, this is the subset that most customers and = implementors are looking for.=20 >>>>>>=20 >>>>>>=20 >>>>>> - prateek >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Tony/Phil, >>>>>>> any chance you can have this work done at OIDC?=20 >>>>>>>=20 >>>>>>> The reason is that it is commonly understood/accepted now that = OAuth provides authorization related specs while authentication/profile >>>>>>> related specs are coming from OIDC (which builds on top of = OAuth2). >>>>>>>=20 >>>>>>> Regards, >>>>>>> Anil >>>>>>>=20 >>>>>>> On 05/14/2014 10:47 AM, Anthony Nadalin wrote: >>>>>>>> I agree with Phil on this one, there are implementations of = this already and much interest >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil = Hunt >>>>>>>> Sent: Wednesday, May 14, 2014 8:32 AM >>>>>>>> To: Brian Campbell >>>>>>>> Cc: oauth@ietf.org >>>>>>>> Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> On the contrary. I and others are interested.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> We are waiting for the charter to pick up the work.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> Regardless there will be a new draft shortly.=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On May 14, 2014, at 5:24, Brian Campbell = wrote: >>>>>>>>=20 >>>>>>>> I would object to 'OAuth Authentication' being picked up by the = WG as a work item. The starting point draft has expired and it hasn't = really been discusses since Berlin nearly a year ago. As I recall, = there was only very limited interest in it even then. I also don't = believe it fits well with the WG charter. >>>>>>>>=20 >>>>>>>> I would suggest the WG consider picking up 'OAuth Symmetric = Proof of Possession for Code Extension' for which there is an excellent = starting point of = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a = relativity simple security enhancement which addresses problems = currently being encountered in deployments of native clients. =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig = wrote: >>>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> you might have seen that we pushed the assertion documents and = the JWT >>>>>>>> documents to the IESG today. We have also updated the = milestones on the >>>>>>>> OAuth WG page. >>>>>>>>=20 >>>>>>>> This means that we can plan to pick up new work in the group. >>>>>>>> We have sent a request to Kathleen to change the milestone for = the OAuth >>>>>>>> security mechanisms to use the proof-of-possession terminology. >>>>>>>>=20 >>>>>>>> We also expect an updated version of the dynamic client = registration >>>>>>>> spec incorporating last call feedback within about 2 weeks. >>>>>>>>=20 >>>>>>>> We would like you to think about adding the following = milestones to the >>>>>>>> charter as part of the re-chartering effort: >>>>>>>>=20 >>>>>>>> ----- >>>>>>>>=20 >>>>>>>> Nov 2014 Submit 'Token introspection' to the IESG for = consideration as a >>>>>>>> Proposed Standard >>>>>>>> Starting point: >>>>>>>>=20 >>>>>>>> Jan 2015 Submit 'OAuth Authentication' to the IESG for = consideration as >>>>>>>> a Proposed Standard >>>>>>>> Starting point: >>>>>>>>=20 >>>>>>>> Jan 2015 Submit 'Token Exchange' to the IESG for consideration = as a >>>>>>>> Proposed Standard >>>>>>>> Starting point: >>>>>>>>=20 >>>>>>>> ----- >>>>>>>>=20 >>>>>>>> We also updated the charter text to reflect the current = situation. Here >>>>>>>> is the proposed text: >>>>>>>>=20 >>>>>>>> ----- >>>>>>>>=20 >>>>>>>> Charter for Working Group >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The Web Authorization (OAuth) protocol allows a user to grant a >>>>>>>> third-party Web site or application access to the user's = protected >>>>>>>> resources, without necessarily revealing their long-term = credentials, >>>>>>>> or even their identity. For example, a photo-sharing site that >>>>>>>> supports OAuth could allow its users to use a third-party = printing Web >>>>>>>> site to print their private pictures, without allowing the = printing >>>>>>>> site to gain full control of the user's account and without = having the >>>>>>>> user share his or her photo-sharing sites' long-term credential = with >>>>>>>> the printing site. >>>>>>>>=20 >>>>>>>> The OAuth 2.0 protocol suite encompasses >>>>>>>>=20 >>>>>>>> * a protocol for obtaining access tokens from an authorization >>>>>>>> server with the resource owner's consent, >>>>>>>> * protocols for presenting these access tokens to resource = server >>>>>>>> for access to a protected resource, >>>>>>>> * guidance for securely using OAuth 2.0, >>>>>>>> * the ability to revoke access tokens, >>>>>>>> * standardized format for security tokens encoded in a JSON = format >>>>>>>> (JSON Web Token, JWT), >>>>>>>> * ways of using assertions with OAuth, and >>>>>>>> * a dynamic client registration protocol. >>>>>>>>=20 >>>>>>>> The working group also developed security schemes for = presenting >>>>>>>> authorization tokens to access a protected resource. This led = to the >>>>>>>> publication of the bearer token, as well as work that remains = to be >>>>>>>> completed on proof-of-possession and token exchange. >>>>>>>>=20 >>>>>>>> The ongoing standardization effort within the OAuth working = group will >>>>>>>> focus on enhancing interoperability and functionality of OAuth >>>>>>>> deployments, such as a standard for a token introspection = service and >>>>>>>> standards for additional security of OAuth requests. >>>>>>>>=20 >>>>>>>> ----- >>>>>>>>=20 >>>>>>>> Feedback appreciated. >>>>>>>>=20 >>>>>>>> Ciao >>>>>>>> Hannes & Derek >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Brian Campbell >>>>>>>> Portfolio Architect >>>>>>>>=20 >>>>>>>> @ >>>>>>>>=20 >>>>>>>> bcampbell@pingidentity.com >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> +1 720.317.2061 >>>>>>>>=20 >>>>>>>> Connect with us=85 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_0C45AE3E-DE49-4A0A-BF5A-391CC442F7BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Sorry = I meant to say this is why it has the /authenticate endpoint to indicate = the client only wants the users session information.


On May 14, 2014, at 6:42 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:

Right. =  This is why it has a different point because the client does NOT = want a resource token.


On May 14, 2014, at 6:41 PM, Justin Richer <jricher@mit.edu> wrote:

=20 =20
Actually, it's about OAuth compatibility. With OAuth, you get an access token to be used at a protected resource. That's what it's for, that's what clients do the OAuth dance(s) for. Connect defines that protected resource as the userinfo endpoint (ie, "tells the client what to do with it"). Connect also defines the id token that comes in along side of the bog-standard OAuth token, and Connect is turned on and off through the use of bog-standard OAuth scopes. So that makes it very, very, very easy to take an OAuth server and turn it into a Connect server. I know, I've done just that, and I've walked others through the process as well.

But the a4c draft is using something that's almost-but-not-quite-OAuth: You might not get an access token, which is going to confuse the heck out of most OAuth clients that I know since that's what they're trying to get at in the first place, and there's no real way for a client to distinguish its request for something with an id_token vs. without. Additionally, in practice, that access token is hugely useful. Just look at all of the weird OpenID2 and OAuth1 hybrid stuff that people were trying to do back a few years ago on top of all the OpenID2 extensions -- this is exactly because OpenID2 was built for "authentication only" because that's what people thought developers wanted, but it turned out that developers wanted a whole lot more than that. This is one main reason the Facebook Connect and Twitter's OAuth-based login came along and ate everyone's lunch: they gave you authentication, but also something useful about the end user.

All said, it sounds like you want Connect but without the UserInfo Endpoint. You'll be glad to know that you can already do that as per the MTI definitions of the server:

  ht= tp://openid.net/specs/openid-connect-core-1_0.html#ServerMTI

You are free to implement a SCIM endpoint (which, by the way, you'll probably need that access_token to access) or no endpoint at all, and a compliant client ought to be able to deal with that. In fact, there's a way to get just the id_token in Connect if that's all you care about, but instead of hiding it inside of an existing flow that might return something different depending on (currently-undefined) special circumstances, it puts this mode into a separate response_type entirely to enforce the point that it is different from regular OAuth.

 -- Justin

On 5/14/2014 9:24 PM, Phil Hunt wrote:
It isn=92t required (or should not be).  This issue is OIDC compatibility.


On May 14, 2014, at 6:21 PM, Justin Richer <jricher@mit.edu> wrote:

How is this functionally different from the a4c draft that also allows the return of both an id_token and an access token?

 -- Justin

On 5/14/2014 9:18 PM, Phil Hunt wrote:
That=92s not a minimalistic authn only profile.

If you return both an access token AND an id token than the service provide has to implement both and the client has to figure out what to do with = it.


On May 14, 2014, at 5:44 PM, Chuck Mortimore <cmortimore@salesforce.com>= ; wrote:

"I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably = implement."

I believe you're looking for this: http://open= id.net/specs/openid-connect-basic-1_0.html

-cmort



On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:
= Anil,

the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token to OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that  the specification was "locked down" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely a minimal extension to OAuth flows to support an authenticator token.  In my experience, this is the subset that most customers and implementors are looking for.


- prateek





Tony/Phil,
  any chance you can have = this work done at OIDC?

The reason is that it is commonly understood/accepted now that OAuth provides authorization related specs while = authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:

I agree with Phil on this one, there are implementations of this already and much interest

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of = Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and = Rechartering

 

On= the contrary. I and others are = interested. 

 

We= are waiting for the charter to pick up the work. 

 

Regardless there will be a new draft shortly. 


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I = recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native = clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG = page.

This means that we can plan to pick up new work in the = group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the = proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 = weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration = as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. = Here
is the proposed text:

-----

Charter for Working = Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's = protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential = with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an = authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource = server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for = presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to = be
completed on = proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth = requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

3D"Ping

Brian = Campbell
Portfolio = Architect

@

bcampbell@pingidentity.com

3D"phone"

+1 720.317.2061

Connect with = us=85

3D"twitter3D"youtube3D"LinkedIn3D"Facebook3D"Google+3D"slideshare3D"flipboard3D"rss

3D"Register
 

_______________________________________________
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



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



=


= --Apple-Mail=_0C45AE3E-DE49-4A0A-BF5A-391CC442F7BE-- From nobody Wed May 14 18:58:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C5F1A03A3 for ; Wed, 14 May 2014 18:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 zq30SjhaLRxq for ; Wed, 14 May 2014 18:58:19 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4B71A03A5 for ; Wed, 14 May 2014 18:58:18 -0700 (PDT) X-AuditID: 1209190e-f79946d000000c39-ec-53741f32ca50 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 8B.64.03129.23F14735; Wed, 14 May 2014 21:58:10 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s4F1w9aw024983; Wed, 14 May 2014 21:58:10 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4F1w7Sr013654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 May 2014 21:58:08 -0400 Message-ID: <53741F27.4010100@mit.edu> Date: Wed, 14 May 2014 21:57:59 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Phil Hunt References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> <537416A9.5060701@mit.edu> <53741B2F.4040506@mit.edu> <1F00EAF0-CC8F-469F-84F3-50C534325360@oracle.com> <51BD7E1D-5C8D-4B6F-8F3C-64137CBDA0DA@oracle.com> In-Reply-To: <51BD7E1D-5C8D-4B6F-8F3C-64137CBDA0DA@oracle.com> Content-Type: multipart/alternative; boundary="------------070101090001090801010006" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsUixG6nrmskXxJs8OqIqsWVZ19ZLU6+fcVm sWB+I7sDs8eSJT+ZPD4+vcXisfh8F1MAcxSXTUpqTmZZapG+XQJXxslvr5gLtl/hqPiydyN7 A+ONacxdjJwcEgImEhfvnmGBsMUkLtxbz9bFyMUhJDCbSWLXzGOMEM5GRontL9dBZW4zSRxY 8wyshVdATWL+7QNsIDaLgKrErf2r2EFsNiB7/spbTCC2qECUxK6+X+wQ9YISJ2c+AesVEVCR +Hb1OiOIzQxUc+zxazBbWMBeYtXSr6wQy56xSOxf+RsswSlgJ3H6/Fc2iIYwidfLZ7FPYBSY hWTuLCQpCNtW4s7c3cwQtrxE89bZULauxKJtK9iRxRcwsq1ilE3JrdLNTczMKU5N1i1OTszL Sy3SNdbLzSzRS00p3cQIigZOSb4djF8PKh1iFOBgVOLhjZhaHCzEmlhWXJl7iFGSg0lJlPeb ZEmwEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFeE0agHG9KYmVValE+TEqag0VJnPettVWwkEB6 YklqdmpqQWoRTFaGg0NJgldGDqhRsCg1PbUiLTOnBCHNxMEJMpwHaPh/WZDhxQWJucWZ6RD5 U4yKUuK8EiAJAZBERmkeXC8sWb1iFAd6RZiXG2QFDzDRwXW/AhrMBDT4hFsRyOCSRISUVAOj Qv8V0dPMsRe/2b+RfpK52+Tl3xce6ja1YSY/pgmuYHVP8z4z46bnqlbFV2sXzav5NF++uJir Nv3R30crs+SDWe33SN4JqXjErcf052rknXliOXeXt7A1y4vv23r1bnTG5YCvDBpt753D/igs 72L9ftAhlznbRG8Kh3vGssfGYUFxOmdfBc5UYinOSDTUYi4qTgQAt3H/uTEDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/7w7wLhRlLGezOoxLmt9n1BUH8xs Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 01:58:26 -0000 This is a multi-part message in MIME format. --------------070101090001090801010006 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Right, so instead of being able to use my authorization endpoint, which already authenticates the user and can gather consent, I need to implement a new endpoint that's not-quite-OAuth but is almost like it. But it's enough to be confusing because sometimes I go to this new endpoint endpoint and also get an access token anyway, to use somewhere that I'm not sure where. And I'm not sure I can collapse the two endpoints and re-use my OAuth infrastructure. After all, I still need to use the token endpoint, and by that point my server needs to know which endpoint the user went to in the first place to make that switch. As a developer, this all sounds horribly convoluted and complicated to track. Do I get to re-use any of the components from an authorization endpoint? How do I know whether or not to issue the access token if the user goes to the authentication endpoint? And then there are the optimizations for existing well-known and well-understood use cases: what if my client is sitting in the same browser session and just wants to get the user assertion directly instead of going through a round trip? Do I need to make two round trips if I'm getting a protected API at the same time as authn data? Can I use the same response_type functionality and other extensions on the authentication endpoint? In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is dangerous and confusing and not something I think the OAuth WG should be a part of. And I really just don't see the point of it, unless the goal is to pollute the standards space which Connect currently occupies. Is Connect perfect? Heck no. But it's far and away the best thing we've had in a long time, and it already does every single thing you are asking for from this new draft. -- Justin On 5/14/2014 9:43 PM, Phil Hunt wrote: > Sorry I meant to say this is why it has the /authenticate endpoint to > indicate the client only wants the users session information. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On May 14, 2014, at 6:42 PM, Phil Hunt > wrote: > >> Right. This is why it has a different point because the client does >> NOT want a resource token. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> On May 14, 2014, at 6:41 PM, Justin Richer > > wrote: >> >>> Actually, it's about OAuth compatibility. With OAuth, you get an >>> access token to be used at a protected resource. That's what it's >>> for, that's what clients do the OAuth dance(s) for. Connect defines >>> that protected resource as the userinfo endpoint (ie, "tells the >>> client what to do with it"). Connect also defines the id token that >>> comes in along side of the bog-standard OAuth token, and Connect is >>> turned on and off through the use of bog-standard OAuth scopes. So >>> that makes it very, very, very easy to take an OAuth server and turn >>> it into a Connect server. I know, I've done just that, and I've >>> walked others through the process as well. >>> >>> But the a4c draft is using something that's >>> almost-but-not-quite-OAuth: You might not get an access token, which >>> is going to confuse the heck out of most OAuth clients that I know >>> since that's what they're trying to get at in the first place, and >>> there's no real way for a client to distinguish its request for >>> something with an id_token vs. without. Additionally, in practice, >>> that access token is hugely useful. Just look at all of the weird >>> OpenID2 and OAuth1 hybrid stuff that people were trying to do back a >>> few years ago on top of all the OpenID2 extensions -- this is >>> exactly because OpenID2 was built for "authentication only" because >>> that's what people thought developers wanted, but it turned out that >>> developers wanted a whole lot more than that. This is one main >>> reason the Facebook Connect and Twitter's OAuth-based login came >>> along and ate everyone's lunch: they gave you authentication, but >>> also something useful about the end user. >>> >>> All said, it sounds like you want Connect but without the UserInfo >>> Endpoint. You'll be glad to know that you can already do that as per >>> the MTI definitions of the server: >>> >>> http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI >>> >>> You are free to implement a SCIM endpoint (which, by the way, you'll >>> probably need that access_token to access) or no endpoint at all, >>> and a compliant client ought to be able to deal with that. In fact, >>> there's a way to get just the id_token in Connect if that's all you >>> care about, but instead of hiding it inside of an existing flow that >>> might return something different depending on (currently-undefined) >>> special circumstances, it puts this mode into a separate >>> response_type entirely to enforce the point that it is different >>> from regular OAuth. >>> >>> -- Justin >>> >>> On 5/14/2014 9:24 PM, Phil Hunt wrote: >>>> It isn’t required (or should not be). This issue is OIDC >>>> compatibility. >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>> >>>> >>>> On May 14, 2014, at 6:21 PM, Justin Richer >>> > wrote: >>>> >>>>> How is this functionally different from the a4c draft that also >>>>> allows the return of both an id_token and an access token? >>>>> >>>>> -- Justin >>>>> >>>>> On 5/14/2014 9:18 PM, Phil Hunt wrote: >>>>>> That’s not a minimalistic authn only profile. >>>>>> >>>>>> If you return both an access token AND an id token than the >>>>>> service provide has to implement both and the client has to >>>>>> figure out what to do with it. >>>>>> >>>>>> Phil >>>>>> >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>> >>>>>> >>>>>> >>>>>> On May 14, 2014, at 5:44 PM, Chuck Mortimore >>>>>> > wrote: >>>>>> >>>>>>> "I had personally requested the OIDC community about six months >>>>>>> ago to describe some minimal subset which we could all >>>>>>> reasonably implement." >>>>>>> >>>>>>> I believe you're looking for this: >>>>>>> http://openid.net/specs/openid-connect-basic-1_0.html >>>>>>> >>>>>>> -cmort >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Anil, >>>>>>> >>>>>>> the challenge is that OIDC is a rather large set of >>>>>>> specifications, and to my knowledge even the core >>>>>>> specification has NOT found >>>>>>> a complete implementation at any large IdP. I am not talking >>>>>>> here about boutique toolkits or startups, I am talking about >>>>>>> the folks >>>>>>> who have 100s of millions of users. And, BTW, implementing a >>>>>>> few arbitrarily selected features from OIDC is not the same >>>>>>> as implementing OIDC. >>>>>>> >>>>>>> As we all know, the core problem is that of adding an >>>>>>> authenticator token to OAuth flows, which is a rather modest >>>>>>> extension to OAuth. >>>>>>> >>>>>>> I had personally requested the OIDC community about six >>>>>>> months ago to describe some minimal subset which we could >>>>>>> all reasonably implement. I was told that the specification >>>>>>> was "locked down" and fully debugged and so on, so no >>>>>>> changes could be made. Imagine my surprise to find that in >>>>>>> the final drafts there was a whole new flow - the hybrid >>>>>>> flow - that had been added at the last minute. I had never >>>>>>> heard of the hybrid flow in the OAuth context - have you? So >>>>>>> now you have an even larger specification! >>>>>>> >>>>>>> The value of draft-hunt-oauth-v2-user-a4c-01 is that it >>>>>>> describes precisely a minimal extension to OAuth flows to >>>>>>> support an authenticator token. In my experience, this is >>>>>>> the subset that most customers and implementors are looking >>>>>>> for. >>>>>>> >>>>>>> >>>>>>> - prateek >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Tony/Phil, >>>>>>>> any chance you can have this work done at OIDC? >>>>>>>> >>>>>>>> The reason is that it is commonly understood/accepted now >>>>>>>> that OAuth provides authorization related specs while >>>>>>>> authentication/profile >>>>>>>> related specs are coming from OIDC (which builds on top of >>>>>>>> OAuth2). >>>>>>>> >>>>>>>> Regards, >>>>>>>> Anil >>>>>>>> >>>>>>>> On 05/14/2014 10:47 AM, Anthony Nadalin wrote: >>>>>>>>> >>>>>>>>> I agree with Phil on this one, there are implementations >>>>>>>>> of this already and much interest >>>>>>>>> >>>>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of >>>>>>>>> *Phil Hunt >>>>>>>>> *Sent:* Wednesday, May 14, 2014 8:32 AM >>>>>>>>> *To:* Brian Campbell >>>>>>>>> *Cc:* oauth@ietf.org >>>>>>>>> *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and >>>>>>>>> Rechartering >>>>>>>>> >>>>>>>>> >>>>>>>>> On the contrary. I and others are interested. >>>>>>>>> >>>>>>>>> >>>>>>>>> We are waiting for the charter to pick up the work. >>>>>>>>> >>>>>>>>> >>>>>>>>> Regardless there will be a new draft shortly. >>>>>>>>> >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> >>>>>>>>> On May 14, 2014, at 5:24, Brian Campbell >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> I would object to 'OAuth Authentication' being picked >>>>>>>>> up by the WG as a work item. The starting point draft >>>>>>>>> has expired and it hasn't really been discusses since >>>>>>>>> Berlin nearly a year ago. As I recall, there was only >>>>>>>>> very limited interest in it even then. I also don't >>>>>>>>> believe it fits well with the WG charter. >>>>>>>>> >>>>>>>>> I would suggest the WG consider picking up 'OAuth >>>>>>>>> Symmetric Proof of Possession for Code Extension' for >>>>>>>>> which there is an excellent starting point of >>>>>>>>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - >>>>>>>>> it's a relativity simple security enhancement which >>>>>>>>> addresses problems currently being encountered in >>>>>>>>> deployments of native clients. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> you might have seen that we pushed the assertion >>>>>>>>> documents and the JWT >>>>>>>>> documents to the IESG today. We have also updated >>>>>>>>> the milestones on the >>>>>>>>> OAuth WG page. >>>>>>>>> >>>>>>>>> This means that we can plan to pick up new work in >>>>>>>>> the group. >>>>>>>>> We have sent a request to Kathleen to change the >>>>>>>>> milestone for the OAuth >>>>>>>>> security mechanisms to use the proof-of-possession >>>>>>>>> terminology. >>>>>>>>> >>>>>>>>> We also expect an updated version of the dynamic >>>>>>>>> client registration >>>>>>>>> spec incorporating last call feedback within about >>>>>>>>> 2 weeks. >>>>>>>>> >>>>>>>>> We would like you to think about adding the >>>>>>>>> following milestones to the >>>>>>>>> charter as part of the re-chartering effort: >>>>>>>>> >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> Nov 2014 Submit 'Token introspection' to the IESG >>>>>>>>> for consideration as a >>>>>>>>> Proposed Standard >>>>>>>>> Starting point: >>>>>>>>> >>>>>>>>> Jan 2015 Submit 'OAuth Authentication' to the IESG >>>>>>>>> for consideration as >>>>>>>>> a Proposed Standard >>>>>>>>> Starting point: >>>>>>>>> >>>>>>>>> Jan 2015 Submit 'Token Exchange' to the IESG for >>>>>>>>> consideration as a >>>>>>>>> Proposed Standard >>>>>>>>> Starting point: >>>>>>>>> >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> We also updated the charter text to reflect the >>>>>>>>> current situation. Here >>>>>>>>> is the proposed text: >>>>>>>>> >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> Charter for Working Group >>>>>>>>> >>>>>>>>> >>>>>>>>> The Web Authorization (OAuth) protocol allows a >>>>>>>>> user to grant a >>>>>>>>> third-party Web site or application access to the >>>>>>>>> user's protected >>>>>>>>> resources, without necessarily revealing their >>>>>>>>> long-term credentials, >>>>>>>>> or even their identity. For example, a >>>>>>>>> photo-sharing site that >>>>>>>>> supports OAuth could allow its users to use a >>>>>>>>> third-party printing Web >>>>>>>>> site to print their private pictures, without >>>>>>>>> allowing the printing >>>>>>>>> site to gain full control of the user's account >>>>>>>>> and without having the >>>>>>>>> user share his or her photo-sharing sites' >>>>>>>>> long-term credential with >>>>>>>>> the printing site. >>>>>>>>> >>>>>>>>> The OAuth 2.0 protocol suite encompasses >>>>>>>>> >>>>>>>>> * a protocol for obtaining access tokens from an >>>>>>>>> authorization >>>>>>>>> server with the resource owner's consent, >>>>>>>>> * protocols for presenting these access tokens to >>>>>>>>> resource server >>>>>>>>> for access to a protected resource, >>>>>>>>> * guidance for securely using OAuth 2.0, >>>>>>>>> * the ability to revoke access tokens, >>>>>>>>> * standardized format for security tokens encoded >>>>>>>>> in a JSON format >>>>>>>>> (JSON Web Token, JWT), >>>>>>>>> * ways of using assertions with OAuth, and >>>>>>>>> * a dynamic client registration protocol. >>>>>>>>> >>>>>>>>> The working group also developed security schemes >>>>>>>>> for presenting >>>>>>>>> authorization tokens to access a protected >>>>>>>>> resource. This led to the >>>>>>>>> publication of the bearer token, as well as work >>>>>>>>> that remains to be >>>>>>>>> completed on proof-of-possession and token exchange. >>>>>>>>> >>>>>>>>> The ongoing standardization effort within the >>>>>>>>> OAuth working group will >>>>>>>>> focus on enhancing interoperability and >>>>>>>>> functionality of OAuth >>>>>>>>> deployments, such as a standard for a token >>>>>>>>> introspection service and >>>>>>>>> standards for additional security of OAuth requests. >>>>>>>>> >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> Feedback appreciated. >>>>>>>>> >>>>>>>>> Ciao >>>>>>>>> Hannes & Derek >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Ping Identity logo >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *Brian Campbell* >>>>>>>>> Portfolio Architect >>>>>>>>> >>>>>>>>> *@* >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> bcampbell@pingidentity.com >>>>>>>>> >>>>>>>>> >>>>>>>>> phone >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> +1 720.317.2061 >>>>>>>>> >>>>>>>>> Connect with us… >>>>>>>>> >>>>>>>>> twitter logo youtube >>>>>>>>> logo >>>>>>>>> LinkedIn >>>>>>>>> logo Facebook >>>>>>>>> logo >>>>>>>>> Google+ >>>>>>>>> logo >>>>>>>>> slideshare >>>>>>>>> logo flipboard >>>>>>>>> logo rss feed icon >>>>>>>>> >>>>>>>>> >>>>>>>>> Register for Cloud Identity Summit 2014 | Modern >>>>>>>>> Identity Revolution | 19–23 July, 2014 | Monterey, CA >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>> >> > --------------070101090001090801010006 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Right, so instead of being able to use my authorization endpoint, which already authenticates the user and can gather consent, I need to implement a new endpoint that's not-quite-OAuth but is almost like it. But it's enough to be confusing because sometimes I go to this new endpoint endpoint and also get an access token anyway, to use somewhere that I'm not sure where. And I'm not sure I can collapse the two endpoints and re-use my OAuth infrastructure. After all, I still need to use the token endpoint, and by that point my server needs to know which endpoint the user went to in the first place to make that switch. As a developer, this all sounds horribly convoluted and complicated to track. Do I get to re-use any of the components from an authorization endpoint? How do I know whether or not to issue the access token if the user goes to the authentication endpoint? And then there are the optimizations for existing well-known and well-understood use cases: what if my client is sitting in the same browser session and just wants to get the user assertion directly instead of going through a round trip? Do I need to make two round trips if I'm getting a protected API at the same time as authn data? Can I use the same response_type functionality and other extensions on the authentication endpoint?

In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is dangerous and confusing and not something I think the OAuth WG should be a part of. And I really just don't see the point of it, unless the goal is to pollute the standards space which Connect currently occupies. Is Connect perfect? Heck no. But it's far and away the best thing we've had in a long time, and it already does every single thing you are asking for from this new draft.

 -- Justin

On 5/14/2014 9:43 PM, Phil Hunt wrote:
Sorry I meant to say this is why it has the /authenticate endpoint to indicate the client only wants the users session information.


On May 14, 2014, at 6:42 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Right.  This is why it has a different point because the client does NOT want a resource token.


On May 14, 2014, at 6:41 PM, Justin Richer <jricher@mit.edu> wrote:

Actually, it's about OAuth compatibility. With OAuth, you get an access token to be used at a protected resource. That's what it's for, that's what clients do the OAuth dance(s) for. Connect defines that protected resource as the userinfo endpoint (ie, "tells the client what to do with it"). Connect also defines the id token that comes in along side of the bog-standard OAuth token, and Connect is turned on and off through the use of bog-standard OAuth scopes. So that makes it very, very, very easy to take an OAuth server and turn it into a Connect server. I know, I've done just that, and I've walked others through the process as well.

But the a4c draft is using something that's almost-but-not-quite-OAuth: You might not get an access token, which is going to confuse the heck out of most OAuth clients that I know since that's what they're trying to get at in the first place, and there's no real way for a client to distinguish its request for something with an id_token vs. without. Additionally, in practice, that access token is hugely useful. Just look at all of the weird OpenID2 and OAuth1 hybrid stuff that people were trying to do back a few years ago on top of all the OpenID2 extensions -- this is exactly because OpenID2 was built for "authentication only" because that's what people thought developers wanted, but it turned out that developers wanted a whole lot more than that. This is one main reason the Facebook Connect and Twitter's OAuth-based login came along and ate everyone's lunch: they gave you authentication, but also something useful about the end user.

All said, it sounds like you want Connect but without the UserInfo Endpoint. You'll be glad to know that you can already do that as per the MTI definitions of the server:

  http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI

You are free to implement a SCIM endpoint (which, by the way, you'll probably need that access_token to access) or no endpoint at all, and a compliant client ought to be able to deal with that. In fact, there's a way to get just the id_token in Connect if that's all you care about, but instead of hiding it inside of an existing flow that might return something different depending on (currently-undefined) special circumstances, it puts this mode into a separate response_type entirely to enforce the point that it is different from regular OAuth.

 -- Justin

On 5/14/2014 9:24 PM, Phil Hunt wrote:
It isn’t required (or should not be).  This issue is OIDC compatibility.


On May 14, 2014, at 6:21 PM, Justin Richer <jricher@mit.edu> wrote:

How is this functionally different from the a4c draft that also allows the return of both an id_token and an access token?

 -- Justin

On 5/14/2014 9:18 PM, Phil Hunt wrote:
That’s not a minimalistic authn only profile.

If you return both an access token AND an id token than the service provide has to implement both and the client has to figure out what to do with it.


On May 14, 2014, at 5:44 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote:

"I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement."

I believe you're looking for this: http://openid.net/specs/openid-connect-basic-1_0.html

-cmort



On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:
Anil,

the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token to OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that  the specification was "locked down" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely a minimal extension to OAuth flows to support an authenticator token.  In my experience, this is the subset that most customers and implementors are looking for.


- prateek





Tony/Phil,
  any chance you can have this work done at OIDC?

The reason is that it is commonly understood/accepted now that OAuth provides authorization related specs while authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:

I agree with Phil on this one, there are implementations of this already and much interest

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

On the contrary. I and others are interested. 

 

We are waiting for the charter to pick up the work. 

 

Regardless there will be a new draft shortly. 


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

Ping Identity logo

Brian Campbell
Portfolio Architect

@

bcampbell@pingidentity.com

phone

+1 720.317.2061

Connect with us…

twitter logoyoutube logoLinkedIn logoFacebook logoGoogle+ logoslideshare logoflipboard logorss feed icon

Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA
 

_______________________________________________
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



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






--------------070101090001090801010006-- From nobody Wed May 14 21:56:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781D11A01F9 for ; Wed, 14 May 2014 21:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.84 X-Spam-Level: X-Spam-Status: No, score=-4.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 am6Rp6IAIoa7 for ; Wed, 14 May 2014 21:56:07 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6621A022A for ; Wed, 14 May 2014 21:56:07 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4F4twJI018108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 04:55:59 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4F4tvKd021417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 May 2014 04:55:58 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4F4tvlf022238; Thu, 15 May 2014 04:55:57 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 May 2014 21:55:56 -0700 References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> <537416A9.5060701@mit.edu> <53741B2F.4040506@mit.edu> <1F00EAF0-CC8F-469F-84F3-50C534325360@oracle.com> <51BD7E1D-5C8D-4B6F-8F3C-64137CBDA0DA@oracle.com> <53741F27.4010100@mit.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <53741F27.4010100@mit.edu> Content-Type: multipart/alternative; boundary=Apple-Mail-CB98CA2E-AA4B-434B-8576-6457FA969CA5 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D167) From: Phil Hunt Date: Wed, 14 May 2014 21:55:51 -0700 To: Justin Richer X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/W5s5dSKnSQDuAcjkdQi0W5pn3zs Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 04:56:13 -0000 --Apple-Mail-CB98CA2E-AA4B-434B-8576-6457FA969CA5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think those are things to discuss if the authen is on the charter.=20 So we have now clarified that the basic connect profile doesn't do just auth= en and requires identity profile services.=20 Phil > On May 14, 2014, at 18:57, Justin Richer wrote: >=20 > Right, so instead of being able to use my authorization endpoint, which al= ready authenticates the user and can gather consent, I need to implement a n= ew endpoint that's not-quite-OAuth but is almost like it. But it's enough to= be confusing because sometimes I go to this new endpoint endpoint and also g= et an access token anyway, to use somewhere that I'm not sure where. And I'm= not sure I can collapse the two endpoints and re-use my OAuth infrastructur= e. After all, I still need to use the token endpoint, and by that point my s= erver needs to know which endpoint the user went to in the first place to ma= ke that switch. As a developer, this all sounds horribly convoluted and comp= licated to track. Do I get to re-use any of the components from an authoriza= tion endpoint? How do I know whether or not to issue the access token if the= user goes to the authentication endpoint? And then there are the optimizati= ons for existing well-known and well-understood use cases: what if my client= is sitting in the same browser session and just wants to get the user asser= tion directly instead of going through a round trip? Do I need to make two r= ound trips if I'm getting a protected API at the same time as authn data? Ca= n I use the same response_type functionality and other extensions on the aut= hentication endpoint?=20 >=20 > In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is dang= erous and confusing and not something I think the OAuth WG should be a= part of. And I really just don't see the point of it, unless the goal is to= pollute the standards space which Connect currently occupies. Is Connect pe= rfect? Heck no. But it's far and away the best thing we've had in a long tim= e, and it already does every single thing you are asking for from this new d= raft. >=20 > -- Justin >=20 >> On 5/14/2014 9:43 PM, Phil Hunt wrote: >> Sorry I meant to say this is why it has the /authenticate endpoint to ind= icate the client only wants the users session information. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>> On May 14, 2014, at 6:42 PM, Phil Hunt wrote: >>>=20 >>> Right. This is why it has a different point because the client does NOT= want a resource token. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>> On May 14, 2014, at 6:41 PM, Justin Richer wrote: >>>>=20 >>>> Actually, it's about OAuth compatibility. With OAuth, you get an access= token to be used at a protected resource. That's what it's for, that's what= clients do the OAuth dance(s) for. Connect defines that protected resource a= s the userinfo endpoint (ie, "tells the client what to do with it"). Connect= also defines the id token that comes in along side of the bog-standard OAut= h token, and Connect is turned on and off through the use of bog-standard OA= uth scopes. So that makes it very, very, very easy to take an OAuth server a= nd turn it into a Connect server. I know, I've done just that, and I've walk= ed others through the process as well.=20 >>>>=20 >>>> But the a4c draft is using something that's almost-but-not-quite-OAuth:= You might not get an access token, which is going to confuse the heck out o= f most OAuth clients that I know since that's what they're trying to get at i= n the first place, and there's no real way for a client to distinguish its r= equest for something with an id_token vs. without. Additionally, in practice= , that access token is hugely useful. Just look at all of the weird OpenID2 a= nd OAuth1 hybrid stuff that people were trying to do back a few years ago on= top of all the OpenID2 extensions -- this is exactly because OpenID2 was bu= ilt for "authentication only" because that's what people thought developers w= anted, but it turned out that developers wanted a whole lot more than that. T= his is one main reason the Facebook Connect and Twitter's OAuth-based login c= ame along and ate everyone's lunch: they gave you authentication, but also s= omething useful about the end user. >>>>=20 >>>> All said, it sounds like you want Connect but without the UserInfo Endp= oint. You'll be glad to know that you can already do that as per the MTI def= initions of the server: >>>>=20 >>>> http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI >>>>=20 >>>> You are free to implement a SCIM endpoint (which, by the way, you'll pr= obably need that access_token to access) or no endpoint at all, and a compli= ant client ought to be able to deal with that. In fact, there's a way to get= just the id_token in Connect if that's all you care about, but instead of h= iding it inside of an existing flow that might return something different de= pending on (currently-undefined) special circumstances, it puts this mode in= to a separate response_type entirely to enforce the point that it is differe= nt from regular OAuth.=20 >>>>=20 >>>> -- Justin >>>>=20 >>>>> On 5/14/2014 9:24 PM, Phil Hunt wrote: >>>>> It isn=E2=80=99t required (or should not be). This issue is OIDC comp= atibility. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On May 14, 2014, at 6:21 PM, Justin Richer wrote: >>>>>>=20 >>>>>> How is this functionally different from the a4c draft that also allow= s the return of both an id_token and an access token?=20 >>>>>>=20 >>>>>> -- Justin >>>>>>=20 >>>>>>> On 5/14/2014 9:18 PM, Phil Hunt wrote: >>>>>>> That=E2=80=99s not a minimalistic authn only profile. >>>>>>>=20 >>>>>>> If you return both an access token AND an id token than the service p= rovide has to implement both and the client has to figure out what to do wit= h it. >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On May 14, 2014, at 5:44 PM, Chuck Mortimore wrote: >>>>>>>>=20 >>>>>>>> "I had personally requested the OIDC community about six months ago= to describe some minimal subset which we could all reasonably implement." >>>>>>>>=20 >>>>>>>> I believe you're looking for this: http://openid.net/specs/openid-c= onnect-basic-1_0.html >>>>>>>>=20 >>>>>>>> -cmort >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra wrote: >>>>>>>>> Anil, >>>>>>>>>=20 >>>>>>>>> the challenge is that OIDC is a rather large set of specifications= , and to my knowledge even the core specification has NOT found >>>>>>>>> a complete implementation at any large IdP. I am not talking here a= bout boutique toolkits or startups, I am talking about the folks >>>>>>>>> who have 100s of millions of users. And, BTW, implementing a few a= rbitrarily selected features from OIDC is not the same as implementing OIDC.= >>>>>>>>>=20 >>>>>>>>> As we all know, the core problem is that of adding an authenticato= r token to OAuth flows, which is a rather modest extension to OAuth. >>>>>>>>>=20 >>>>>>>>> I had personally requested the OIDC community about six months ago= to describe some minimal subset which we could all reasonably implement. I w= as told that the specification was "locked down" and fully debugged and so o= n, so no changes could be made. Imagine my surprise to find that in the fina= l drafts there was a whole new flow - the hybrid flow - that had been added a= t the last minute. I had never heard of the hybrid flow in the OAuth context= - have you? So now you have an even larger specification! >>>>>>>>>=20 >>>>>>>>> The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes p= recisely a minimal extension to OAuth flows to support an authenticator toke= n. In my experience, this is the subset that most customers and implementor= s are looking for.=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> - prateek >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Tony/Phil, >>>>>>>>>> any chance you can have this work done at OIDC?=20 >>>>>>>>>>=20 >>>>>>>>>> The reason is that it is commonly understood/accepted now that OA= uth provides authorization related specs while authentication/profile >>>>>>>>>> related specs are coming from OIDC (which builds on top of OAuth2= ). >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Anil >>>>>>>>>>=20 >>>>>>>>>>> On 05/14/2014 10:47 AM, Anthony Nadalin wrote: >>>>>>>>>>> I agree with Phil on this one, there are implementations of this= already and much interest >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>>=20 >>>>>>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hu= nt >>>>>>>>>>> Sent: Wednesday, May 14, 2014 8:32 AM >>>>>>>>>>> To: Brian Campbell >>>>>>>>>>> Cc: oauth@ietf.org >>>>>>>>>>> Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> On the contrary. I and others are interested.=20 >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> We are waiting for the charter to pick up the work.=20 >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> Regardless there will be a new draft shortly.=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Phil >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On May 14, 2014, at 5:24, Brian Campbell wrote: >>>>>>>>>>>=20 >>>>>>>>>>> I would object to 'OAuth Authentication' being picked up by the W= G as a work item. The starting point draft has expired and it hasn't really b= een discusses since Berlin nearly a year ago. As I recall, there was only v= ery limited interest in it even then. I also don't believe it fits well with= the WG charter. >>>>>>>>>>>=20 >>>>>>>>>>> I would suggest the WG consider picking up 'OAuth Symmetric Proo= f of Possession for Code Extension' for which there is an excellent starting= point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a r= elativity simple security enhancement which addresses problems currently bei= ng encountered in deployments of native clients. =20 >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Hi all, >>>>>>>>>>>=20 >>>>>>>>>>> you might have seen that we pushed the assertion documents and t= he JWT >>>>>>>>>>> documents to the IESG today. We have also updated the milestones= on the >>>>>>>>>>> OAuth WG page. >>>>>>>>>>>=20 >>>>>>>>>>> This means that we can plan to pick up new work in the group. >>>>>>>>>>> We have sent a request to Kathleen to change the milestone for t= he OAuth >>>>>>>>>>> security mechanisms to use the proof-of-possession terminology. >>>>>>>>>>>=20 >>>>>>>>>>> We also expect an updated version of the dynamic client registra= tion >>>>>>>>>>> spec incorporating last call feedback within about 2 weeks. >>>>>>>>>>>=20 >>>>>>>>>>> We would like you to think about adding the following milestones= to the >>>>>>>>>>> charter as part of the re-chartering effort: >>>>>>>>>>>=20 >>>>>>>>>>> ----- >>>>>>>>>>>=20 >>>>>>>>>>> Nov 2014 Submit 'Token introspection' to the IESG for considerat= ion as a >>>>>>>>>>> Proposed Standard >>>>>>>>>>> Starting point: >>>>>>>>>>>=20 >>>>>>>>>>> Jan 2015 Submit 'OAuth Authentication' to the IESG for considera= tion as >>>>>>>>>>> a Proposed Standard >>>>>>>>>>> Starting point: >>>>>>>>>>>=20 >>>>>>>>>>> Jan 2015 Submit 'Token Exchange' to the IESG for consideration a= s a >>>>>>>>>>> Proposed Standard >>>>>>>>>>> Starting point: >>>>>>>>>>>=20 >>>>>>>>>>> ----- >>>>>>>>>>>=20 >>>>>>>>>>> We also updated the charter text to reflect the current situatio= n. Here >>>>>>>>>>> is the proposed text: >>>>>>>>>>>=20 >>>>>>>>>>> ----- >>>>>>>>>>>=20 >>>>>>>>>>> Charter for Working Group >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The Web Authorization (OAuth) protocol allows a user to grant a >>>>>>>>>>> third-party Web site or application access to the user's protect= ed >>>>>>>>>>> resources, without necessarily revealing their long-term credent= ials, >>>>>>>>>>> or even their identity. For example, a photo-sharing site that >>>>>>>>>>> supports OAuth could allow its users to use a third-party printi= ng Web >>>>>>>>>>> site to print their private pictures, without allowing the print= ing >>>>>>>>>>> site to gain full control of the user's account and without havi= ng the >>>>>>>>>>> user share his or her photo-sharing sites' long-term credential w= ith >>>>>>>>>>> the printing site. >>>>>>>>>>>=20 >>>>>>>>>>> The OAuth 2.0 protocol suite encompasses >>>>>>>>>>>=20 >>>>>>>>>>> * a protocol for obtaining access tokens from an authorization >>>>>>>>>>> server with the resource owner's consent, >>>>>>>>>>> * protocols for presenting these access tokens to resource serve= r >>>>>>>>>>> for access to a protected resource, >>>>>>>>>>> * guidance for securely using OAuth 2.0, >>>>>>>>>>> * the ability to revoke access tokens, >>>>>>>>>>> * standardized format for security tokens encoded in a JSON form= at >>>>>>>>>>> (JSON Web Token, JWT), >>>>>>>>>>> * ways of using assertions with OAuth, and >>>>>>>>>>> * a dynamic client registration protocol. >>>>>>>>>>>=20 >>>>>>>>>>> The working group also developed security schemes for presenting= >>>>>>>>>>> authorization tokens to access a protected resource. This led to= the >>>>>>>>>>> publication of the bearer token, as well as work that remains to= be >>>>>>>>>>> completed on proof-of-possession and token exchange. >>>>>>>>>>>=20 >>>>>>>>>>> The ongoing standardization effort within the OAuth working grou= p will >>>>>>>>>>> focus on enhancing interoperability and functionality of OAuth >>>>>>>>>>> deployments, such as a standard for a token introspection servic= e and >>>>>>>>>>> standards for additional security of OAuth requests. >>>>>>>>>>>=20 >>>>>>>>>>> ----- >>>>>>>>>>>=20 >>>>>>>>>>> Feedback appreciated. >>>>>>>>>>>=20 >>>>>>>>>>> Ciao >>>>>>>>>>> Hannes & Derek >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Brian Campbell >>>>>>>>>>> Portfolio Architect >>>>>>>>>>>=20 >>>>>>>>>>> @ >>>>>>>>>>>=20 >>>>>>>>>>> bcampbell@pingidentity.com >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>=20 >>>>>>>>>>> Connect with us=E2=80=A6 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-CB98CA2E-AA4B-434B-8576-6457FA969CA5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think those are things to discuss if= the authen is on the charter. 

So we have now= clarified that the basic connect profile doesn't do just authen and require= s identity profile services. 

Phil

On May 1= 4, 2014, at 18:57, Justin Richer <jric= her@mit.edu> wrote:

=20 =20 =20
Right, so instead of being able to use my authorization endpoint, which already authenticates the user and can gather consent, I need to implement a new endpoint that's not-quite-OAuth but is almost like it. But it's enough to be confusing because sometimes I go to this new endpoint endpoint and also get an access token anyway, to use somewhere that I'm not sure where. And I'm not sure I can collapse the two endpoints and re-use my OAuth infrastructure. After all, I still need to use the token endpoint, and by that point my server needs to know which endpoint the user went to in the first place to make that switch. As a developer, this all sounds horribly convoluted and complicated to track. Do I get to re-use any of the components from an authorization endpoint? How do I know whether or not to issue the access token if the user goes to the authentication endpoint? And then there are the optimizations for existing well-known and well-understood use cases: what if my client is sitting in the same browser session and just wants to get the user assertion directly instead of going through a round trip? Do I need to make two round trips if I'm getting a protected API at the same time as authn data? Can I use the same response_type functionality and other extensions on the authentication endpoint?

In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is dangerous and confusing and not something I think the OAuth WG should be a part of. And I really just don't see the point of it, unless the goal is to pollute the standards space which Connect currently occupies. Is Connect perfect? Heck no. But it's far and away the best thing we've had in a long time, and it already does every single thing you are asking for from this new draft.

 -- Justin

On 5/14/2014 9:43 PM, Phil Hunt wrote:
Sorry I meant to say this is why it has the /authenticate endpoint to indicate the client only wants the users session information.


On May 14, 2014, at 6:42 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Right.  This is why it has a different point because the client does NOT want a resource token.


On May 14, 2014, at 6:41 PM, Justin Richer <jricher@mit.edu>= ; wrote:

Actually, it's about OAuth compatibility. With OAuth, you get an access token to be used at a protected resource. That's what it's for, that's what clients do the OAuth dance(s) for. Connect defines that protected resource as the userinfo endpoint (ie, "tells the client what to do with it"). Connect also defines the id token that comes in along side of the bog-standard OAuth token, and Connect is turned on and off through the use of bog-standard OAuth scopes. So that makes it very, very, very easy to take an OAuth server and turn it into a Connect server. I know, I've done just that, and I've walked others through the process as well.

But the a4c draft is using something that's almost-but-not-quite-OAuth: You might not get an access token, which is going to confuse the heck out of most OAuth clients that I know since that's what they're trying to get at in the first place, and there's no real way for a client to distinguish its request for something with an id_token vs. without. Additionally, in practice, that access token is hugely useful. Just look at all of the weird OpenID2 and OAuth1 hybrid stuff that people were trying to do back a few years ago on top of all the OpenID2 extensions -- this is exactly because OpenID2 was built for "authentication only" because that's what people thought developers wanted, but it turned out that developers wanted a whole lot more than that. This is one main reason the Facebook Connect and Twitter's OAuth-based login came along and ate everyone's lunch: they gave you authentication, but also something useful about the end user.

All said, it sounds like you want Connect but without the UserInfo Endpoint. You'll be glad to know that you can already do that as per the MTI definitions of the server:

  http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI

You are free to implement a SCIM endpoint (which, by the way, you'll probably need that access_token to access) or no endpoint at all, and a compliant client ought to be able to deal with that. In fact, there's a way to get just the id_token in Connect if that's all you care about, but instead of hiding it inside of an existing flow that might return something different depending on (currently-undefined) special circumstances, it puts this mode into a separate response_type entirely to enforce the point that it is different from regular OAuth.

 -- Justin

On 5/14/2014 9:24 PM, Phil Hunt wrote:
It isn=E2=80=99t required (or should not be).  This issue is OIDC compatibility.


On May 14, 2014, at 6:21 PM, Justin Richer <jricher@mit.edu> wrote:

How is this functionally different from the a4c draft that also allows the return of both an id_token and an access token?

 -- Justin

On 5/14/2014 9:18 PM, Phil Hunt wrote:
That=E2=80=99s not a minimalistic authn only profile.

If you return both an access token AND an id token than the service provide has to implement both and the client has to figure out what to do with it.



"I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement."

=
I believe you're looking for this: http://op= enid.net/specs/openid-connect-basic-1_0.html

=
-cmor= t



On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:
Anil,

the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token to OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that  the specification was "locked down" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!

The value of draft-hunt-oauth-v2-user= -a4c-01 is that it describes precisely a minimal extension to OAuth flows to support an authenticator token.  In my experience, this is the subset that most customers and implementors are looking for.


- prateek

=



Tony/Phil,   any chance you can have this work done at OIDC?

The reason is that it is commonly understood/accepte= d now that OAuth provides authorization related specs while authentication/pro= file
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:
=

I agree with Phil on this one, there are implementations of this already and much interest

<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,= 125)"> 

From:<= /span> OAu= th [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
= Cc: oauth@= ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

On the contrary. I and others are interested. <= /p>

 

We are waiting for the charter to pick up the work. 

 

Regardless there will be a new draft shortly. 

=


Phil


On May 14, 2014, at 5:24, Brian Campbell <b= campbell@pingidentity.com> wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <ha= nnes.tschofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.
=
This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possessio= n terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:
=
-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
= * standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possessio= n and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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



=
--

3D"Ping

Brian Campbell
Portf= olio Architect

@

=

bcampbell@pingidentity.com

3D"phone"

+1 720.317.2061

Connect with us=E2=80=A6

3D"t=3D"y=3D"=3D"=3D=3D=3D"rss

 

_______________________________________________
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
htt= ps://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/o=
auth






=20
= --Apple-Mail-CB98CA2E-AA4B-434B-8576-6457FA969CA5-- From nobody Wed May 14 22:31:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC561A03D8 for ; Wed, 14 May 2014 22:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 OE5QTTEznz_c for ; Wed, 14 May 2014 22:31:05 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2BB1A03D3 for ; Wed, 14 May 2014 22:31:04 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB311.namprd03.prod.outlook.com (10.141.48.26) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 15 May 2014 05:30:56 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0949.001; Thu, 15 May 2014 05:30:56 +0000 From: Anthony Nadalin To: Justin Richer , Phil Hunt Thread-Topic: [OAUTH-WG] OAuth Milestone Update and Rechartering Thread-Index: AQHPawEbu8OzlywPcU+RkLqz+fSkNptACOgAgAA0VICAAAQKYIAAHggAgAB2bICAAAH9AIAACU+AgAABCYCAAACtAIAABLiAgAAAg4CAAAA7gIAAA/2AgAA7fg4= Date: Thu, 15 May 2014 05:30:55 +0000 Message-ID: References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> <537416A9.5060701@mit.edu> <53741B2F.4040506@mit.edu> <1F00EAF0-CC8F-469F-84F3-50C534325360@oracle.com> <51BD7E1D-5C8D-4B6F-8F3C-64137CBDA0DA@oracle.com>,<53741F27.4010100@mit.edu> In-Reply-To: <53741F27.4010100@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.170.57.185] x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(52314003)(199002)(189002)(479174003)(377454003)(53754006)(24454002)(57704003)(83072002)(21056001)(19273905006)(86362001)(86612001)(76576001)(101416001)(92566001)(74316001)(85852003)(31966008)(2171001)(74662001)(19618635001)(19580395003)(2656002)(74502001)(77982001)(19580405001)(15198665003)(87936001)(81542001)(18206015023)(81342001)(15975445006)(15202345003)(16297215004)(79102001)(19617315010)(77096999)(54356999)(83322001)(16601075003)(50986999)(76176999)(33646001)(76482001)(99286001)(15395725003)(64706001)(80022001)(46102001)(4396001)(66066001)(16236675002)(20776003)(42262001)(24736002)(9984715005); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB311; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; Content-Type: multipart/alternative; boundary="_000_f12568197c4c408eb136327cf20e01dfBLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JpidxaE0N5caUqzsXp_QtDX2234 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 05:31:10 -0000 --_000_f12568197c4c408eb136327cf20e01dfBLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Very odd since you took the registration from connect and pushed it OAuth. Sent from my Windows Phone ________________________________ From: Justin Richer Sent: =FD5/=FD15/=FD2014 3:58 AM To: Phil Hunt Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering Right, so instead of being able to use my authorization endpoint, which alr= eady authenticates the user and can gather consent, I need to implement a n= ew endpoint that's not-quite-OAuth but is almost like it. But it's enough t= o be confusing because sometimes I go to this new endpoint endpoint and als= o get an access token anyway, to use somewhere that I'm not sure where. And= I'm not sure I can collapse the two endpoints and re-use my OAuth infrastr= ucture. After all, I still need to use the token endpoint, and by that poin= t my server needs to know which endpoint the user went to in the first plac= e to make that switch. As a developer, this all sounds horribly convoluted = and complicated to track. Do I get to re-use any of the components from an = authorization endpoint? How do I know whether or not to issue the access to= ken if the user goes to the authentication endpoint? And then there are the= optimizations for existing well-known and well-understood use cases: what = if my client is sitting in the same browser session and just wants to get t= he user assertion directly instead of going through a round trip? Do I need= to make two round trips if I'm getting a protected API at the same time as= authn data? Can I use the same response_type functionality and other exten= sions on the authentication endpoint? In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is dange= rous and confusing and not something I think the OAuth WG should be a part = of. And I really just don't see the point of it, unless the goal is to poll= ute the standards space which Connect currently occupies. Is Connect perfec= t? Heck no. But it's far and away the best thing we've had in a long time, = and it already does every single thing you are asking for from this new dra= ft. -- Justin On 5/14/2014 9:43 PM, Phil Hunt wrote: Sorry I meant to say this is why it has the /authenticate endpoint to indic= ate the client only wants the users session information. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 14, 2014, at 6:42 PM, Phil Hunt > wrote: Right. This is why it has a different point because the client does NOT wa= nt a resource token. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 14, 2014, at 6:41 PM, Justin Richer > wrote: Actually, it's about OAuth compatibility. With OAuth, you get an access tok= en to be used at a protected resource. That's what it's for, that's what cl= ients do the OAuth dance(s) for. Connect defines that protected resource as= the userinfo endpoint (ie, "tells the client what to do with it"). Connect= also defines the id token that comes in along side of the bog-standard OAu= th token, and Connect is turned on and off through the use of bog-standard = OAuth scopes. So that makes it very, very, very easy to take an OAuth serve= r and turn it into a Connect server. I know, I've done just that, and I've = walked others through the process as well. But the a4c draft is using something that's almost-but-not-quite-OAuth: You= might not get an access token, which is going to confuse the heck out of m= ost OAuth clients that I know since that's what they're trying to get at in= the first place, and there's no real way for a client to distinguish its r= equest for something with an id_token vs. without. Additionally, in practic= e, that access token is hugely useful. Just look at all of the weird OpenID= 2 and OAuth1 hybrid stuff that people were trying to do back a few years ag= o on top of all the OpenID2 extensions -- this is exactly because OpenID2 w= as built for "authentication only" because that's what people thought devel= opers wanted, but it turned out that developers wanted a whole lot more tha= n that. This is one main reason the Facebook Connect and Twitter's OAuth-ba= sed login came along and ate everyone's lunch: they gave you authentication= , but also something useful about the end user. All said, it sounds like you want Connect but without the UserInfo Endpoint= . You'll be glad to know that you can already do that as per the MTI defini= tions of the server: http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI You are free to implement a SCIM endpoint (which, by the way, you'll probab= ly need that access_token to access) or no endpoint at all, and a compliant= client ought to be able to deal with that. In fact, there's a way to get j= ust the id_token in Connect if that's all you care about, but instead of hi= ding it inside of an existing flow that might return something different de= pending on (currently-undefined) special circumstances, it puts this mode i= nto a separate response_type entirely to enforce the point that it is diffe= rent from regular OAuth. -- Justin On 5/14/2014 9:24 PM, Phil Hunt wrote: It isn=92t required (or should not be). This issue is OIDC compatibility. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 14, 2014, at 6:21 PM, Justin Richer > wrote: How is this functionally different from the a4c draft that also allows the = return of both an id_token and an access token? -- Justin On 5/14/2014 9:18 PM, Phil Hunt wrote: That=92s not a minimalistic authn only profile. If you return both an access token AND an id token than the service provide= has to implement both and the client has to figure out what to do with it. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 14, 2014, at 5:44 PM, Chuck Mortimore > wrote: "I had personally requested the OIDC community about six months ago to desc= ribe some minimal subset which we could all reasonably implement." I believe you're looking for this: http://openid.net/specs/openid-connect-b= asic-1_0.html -cmort On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra > wrote: Anil, the challenge is that OIDC is a rather large set of specifications, and to = my knowledge even the core specification has NOT found a complete implementation at any large IdP. I am not talking here about bou= tique toolkits or startups, I am talking about the folks who have 100s of millions of users. And, BTW, implementing a few arbitraril= y selected features from OIDC is not the same as implementing OIDC. As we all know, the core problem is that of adding an authenticator token t= o OAuth flows, which is a rather modest extension to OAuth. I had personally requested the OIDC community about six months ago to descr= ibe some minimal subset which we could all reasonably implement. I was told= that the specification was "locked down" and fully debugged and so on, so= no changes could be made. Imagine my surprise to find that in the final dr= afts there was a whole new flow - the hybrid flow - that had been added at = the last minute. I had never heard of the hybrid flow in the OAuth context = - have you? So now you have an even larger specification! The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely= a minimal extension to OAuth flows to support an authenticator token. In = my experience, this is the subset that most customers and implementors are = looking for. - prateek Tony/Phil, any chance you can have this work done at OIDC? The reason is that it is commonly understood/accepted now that OAuth provid= es authorization related specs while authentication/profile related specs are coming from OIDC (which builds on top of OAuth2). Regards, Anil On 05/14/2014 10:47 AM, Anthony Nadalin wrote: I agree with Phil on this one, there are implementations of this already an= d much interest From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, May 14, 2014 8:32 AM To: Brian Campbell Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering On the contrary. I and others are interested. We are waiting for the charter to pick up the work. Regardless there will be a new draft shortly. Phil On May 14, 2014, at 5:24, Brian Campbell > wrote: I would object to 'OAuth Authentication' being picked up by the WG as a wor= k item. The starting point draft has expired and it hasn't really been disc= usses since Berlin nearly a year ago. As I recall, there was only very lim= ited interest in it even then. I also don't believe it fits well with the W= G charter. I would suggest the WG consider picking up 'OAuth Symmetric Proof of Posses= sion for Code Extension' for which there is an excellent starting point of = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity= simple security enhancement which addresses problems currently being encou= ntered in deployments of native clients. On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig > wrote: Hi all, you might have seen that we pushed the assertion documents and the JWT documents to the IESG today. We have also updated the milestones on the OAuth WG page. This means that we can plan to pick up new work in the group. We have sent a request to Kathleen to change the milestone for the OAuth security mechanisms to use the proof-of-possession terminology. We also expect an updated version of the dynamic client registration spec incorporating last call feedback within about 2 weeks. We would like you to think about adding the following milestones to the charter as part of the re-chartering effort: ----- Nov 2014 Submit 'Token introspection' to the IESG for consideration as a Proposed Standard Starting point: Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as a Proposed Standard Starting point: Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a Proposed Standard Starting point: ----- We also updated the charter text to reflect the current situation. Here is the proposed text: ----- Charter for Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user share his or her photo-sharing sites' long-term credential with the printing site. The OAuth 2.0 protocol suite encompasses * a protocol for obtaining access tokens from an authorization server with the resource owner's consent, * protocols for presenting these access tokens to resource server for access to a protected resource, * guidance for securely using OAuth 2.0, * the ability to revoke access tokens, * standardized format for security tokens encoded in a JSON format (JSON Web Token, JWT), * ways of using assertions with OAuth, and * a dynamic client registration protocol. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token, as well as work that remains to be completed on proof-of-possession and token exchange. The ongoing standardization effort within the OAuth working group will focus on enhancing interoperability and functionality of OAuth deployments, such as a standard for a token introspection service and standards for additional security of OAuth requests. ----- Feedback appreciated. Ciao Hannes & Derek _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- [Ping Identity l= ogo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [phone] +1 720.317.2061 Connect with us=85 [twitter logo][youtube = logo]= [LinkedIn logo]<= https://www.linkedin.com/company/21870>[Facebook = logo][Google+ l= ogo][slideshare = logo][flipboard = logo][rss feed = icon] [Register for Cl= oud Identity = Summit 2014 | = Modern = Identity = Revolution | = 19=9623 July, = 2014 | = Monterey, CA] _______________________________________________ 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_f12568197c4c408eb136327cf20e01dfBLUPR03MB309namprd03pro_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Very odd sinc= e you took the registration from connect and pushed it OAuth.

Sent from my Windows Phone
From: Justin Richer
Sent: =FD5/= =FD15/=FD2014 3:58 AM
To: Phil Hunt
Cc: OAuth WG
Subject: Re: [= OAUTH-WG] OAuth Milestone Update and Rechartering

Right, so instead of being able to use my au= thorization endpoint, which already authenticates the user and can gather c= onsent, I need to implement a new endpoint that's not-quite-OAuth but is al= most like it. But it's enough to be confusing because sometimes I go to this new endpoint endpoint and also ge= t an access token anyway, to use somewhere that I'm not sure where. And I'm= not sure I can collapse the two endpoints and re-use my OAuth infrastructu= re. After all, I still need to use the token endpoint, and by that point my server needs to know which endpoi= nt the user went to in the first place to make that switch. As a developer,= this all sounds horribly convoluted and complicated to track. Do I get to = re-use any of the components from an authorization endpoint? How do I know whether or not to issue the acces= s token if the user goes to the authentication endpoint? And then there are= the optimizations for existing well-known and well-understood use cases: w= hat if my client is sitting in the same browser session and just wants to get the user assertion directly ins= tead of going through a round trip? Do I need to make two round trips if I'= m getting a protected API at the same time as authn data? Can I use the sam= e response_type functionality and other extensions on the authentication endpoint?

In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is dange= rous and confusing and not something I think the OAuth WG should be a part = of. And I really just don't see the point of it, unless the goal is to poll= ute the standards space which Connect currently occupies. Is Connect perfect? Heck no. But it's far and away the= best thing we've had in a long time, and it already does every single thin= g you are asking for from this new draft.

 -- Justin

On 5/14/2014 9:43 PM, Phil Hunt wrote:
Sorry I meant to say this is why it has the /auth= enticate endpoint to indicate the client only wants the users session infor= mation.


On May 14, 2014, at 6:42 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Right.  This is why it has a diffe= rent point because the client does NOT want a resource token.


On May 14, 2014, at 6:41 PM, Justin Richer <jricher@mit.edu> wrote:

Actually, it's about OAuth compatibility. Wi= th OAuth, you get an access token to be used at a protected resource. That'= s what it's for, that's what clients do the OAuth dance(s) for. Connect def= ines that protected resource as the userinfo endpoint (ie, "tells the client what to do with it"). C= onnect also defines the id token that comes in along side of the bog-standa= rd OAuth token, and Connect is turned on and off through the use of bog-sta= ndard OAuth scopes. So that makes it very, very, very easy to take an OAuth server and turn it into a Connect server.= I know, I've done just that, and I've walked others through the process as= well.

But the a4c draft is using something that's almost-but-not-quite-OAuth: You= might not get an access token, which is going to confuse the heck out of m= ost OAuth clients that I know since that's what they're trying to get at in= the first place, and there's no real way for a client to distinguish its request for something with an id_= token vs. without. Additionally, in practice, that access token is hugely u= seful. Just look at all of the weird OpenID2 and OAuth1 hybrid stuff that p= eople were trying to do back a few years ago on top of all the OpenID2 extensions -- this is exactly because = OpenID2 was built for "authentication only" because that's what p= eople thought developers wanted, but it turned out that developers wanted a= whole lot more than that. This is one main reason the Facebook Connect and Twitter's OAuth-based login came along and= ate everyone's lunch: they gave you authentication, but also something use= ful about the end user.

All said, it sounds like you want Connect but without the UserInfo Endpoint= . You'll be glad to know that you can already do that as per the MTI defini= tions of the server:

  http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI

You are free to implement a SCIM endpoint (which, by the way, you'll probab= ly need that access_token to access) or no endpoint at all, and a compliant= client ought to be able to deal with that. In fact, there's a way to get j= ust the id_token in Connect if that's all you care about, but instead of hiding it inside of an existing flow th= at might return something different depending on (currently-undefined) spec= ial circumstances, it puts this mode into a separate response_type entirely= to enforce the point that it is different from regular OAuth.

 -- Justin

On 5/14/2014 9:24 PM, Phil Hunt wrote:
It isn=92t required (or should not be).  Thi= s issue is OIDC compatibility.


On May 14, 2014, at 6:21 PM, Justin Richer <jricher@mit.edu> wrote:

How is this functionally different from the = a4c draft that also allows the return of both an id_token and an access tok= en?

 -- Justin

On 5/14/2014 9:18 PM, Phil Hunt wrote:
That=92s not a minimalistic authn only profile.

If you return both an access token AND an id token than the service pr= ovide has to implement both and the client has to figure out what to do wit= h it.


On May 14, 2014, at 5:44 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote:

"I had personally requested the OIDC commun= ity about six months ago to describe some minimal subset which we could all= reasonably implement."

I believe you're looking for this: http://openid.net/specs/openid-connect-basic-1_0.html

-cmort



On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra = <prateek.= mishra@oracle.com> wrote:
Anil,

the challenge is that OIDC is a rather large set of specifications, and to = my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about bou= tique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitraril= y selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token t= o OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to descr= ibe some minimal subset which we could all reasonably implement. I was told= that  the specification was "locked down" and fully debugge= d and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - = the hybrid flow - that had been added at the last minute. I had never heard= of the hybrid flow in the OAuth context - have you? So now you have an eve= n larger specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely= a minimal extension to OAuth flows to support an authenticator token. = ; In my experience, this is the subset that most customers and implementors= are looking for.


- prateek





Tony/Phil,
  any chance you can have this work done at OIDC?

The reason is that it is commonly understood/accepted now that OAuth provid= es authorization related specs while authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:

I agree with Phil on this one, there are i= mplementations of this already and much interest

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

On the contrary. I and others are interested. <= /p>

 

We are waiting for the charter to pick up the work.&= nbsp;

 

Regardless there will be a new draft shortly. <= /p>


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:=

I would object to 'OAut= h Authentication' being picked up by the WG as a work item. The starting po= int draft has expired and it hasn't really been discusses since Berlin near= ly a year ago.  As I recall, there was only very limited interest in it even then. I also don't believe it fits w= ell with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Posses= sion for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relati= vity simple security enhancement which addresses problems currently being e= ncountered in deployments of native clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig &l= t;hannes.tsc= hofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

Brian Campbell
Portfolio Ar= chitect

@

= bcampbell@pingidentity.com

3D"phone"

+1 7= 20.317.2061

Connect with us=85

3D"twitter3D"youtube3D"LinkedIn3D"Facebook3D"Google+3D"slideshare3D"flipboard3D"rss

3D"Register
 

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



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




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


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


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



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






--_000_f12568197c4c408eb136327cf20e01dfBLUPR03MB309namprd03pro_-- From nobody Wed May 14 22:32:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44451A03D1 for ; Wed, 14 May 2014 22:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 BGzG8VcpRd7E for ; Wed, 14 May 2014 22:31:48 -0700 (PDT) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308211A0239 for ; Wed, 14 May 2014 22:31:43 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id e53so232235eek.25 for ; Wed, 14 May 2014 22:31:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=s6SaZQV8KZXVADY2tZNcyKWXCeX46YLCbvryI7UqFzc=; b=Aq/eQJU0eXvfRFgtn20WN8nYWdbWbYTep9hbkglw5pde7j/L5y/6kleA2MfeqJLTnT 41Vtxk4gG+ZDtBIeYygGeHEx0Mkh0VwrVp1zmN+WvCAYgl2H2vcJLjR4Vh6DdhKQYOt9 Xa0aVD0Gc0pPAZyo/i9KPUQMEFoMe2S1cQNwlv36niuQxKN/ldOOXEbwmqyvzCrj+1m+ R1e5bu1Zq82xEJU0QUFTtXSJvrW2PkLUS3Rl36/nfQk1uLGO+nyAgYvCFDr+0IyN2EIU OHWEBIZT5ejVe5Vb+76UndNlKC2WT8r2ExkQQ8KgrbK1dLnMDb0nD+iwhVorsgzBgsrh 67Ng== X-Gm-Message-State: ALoCoQmZDZCAO9U15+A3eU1b0gOkxTJLJng2VLj4JWFjyfxoKdfLi6rPc1FI4KGKVg+bUovS1VGL X-Received: by 10.14.108.198 with SMTP id q46mr11242946eeg.31.1400131894965; Wed, 14 May 2014 22:31:34 -0700 (PDT) Received: from [192.168.0.93] ([195.50.165.102]) by mx.google.com with ESMTPSA id x42sm9907563eel.41.2014.05.14.22.31.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 May 2014 22:31:32 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7589477A-07A0-4DAB-A981-4B54F643766E" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: John Bradley In-Reply-To: Date: Thu, 15 May 2014 07:31:40 +0200 Message-Id: References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> <537416A9.5060701@mit.edu> <53741B2F.4040506@mit.edu> <1F00EAF0-CC8F-469F-84F3-50C534325360@oracle.com> <51BD7E1D-5C8D-4B6F-8F3C-64137CBDA0DA@oracle.com> <53741F27.4010100@mit.edu> To: Phil Hunt X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/81YSgQI73ttI66WmqI00gFZDWEs Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 05:32:15 -0000 --Apple-Mail=_7589477A-07A0-4DAB-A981-4B54F643766E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 No. OAuth requires that if you use the code response type, the token = endpoint must return an access token. Connect dosen't require a user_info endpoint. In the response_type "id_token" only a id_token is returned in the = front channel in a manner similar to SAML POST binding but fragment = encoded by default. So there is a flow in Connect that doesn't deliver an access token. I think this discussion is more about what changes you want to the core = of OAuth. Connect worked around the OAuth spec to be compatible with it. Only the OAuth WG can change OAuth and that seems to be what you want. =20= a4c is a justification for making those changes. We should probably focus on the core issue of what changes to RFC 6749 = you are after, to determine if the WG wants to change the charter. I think focusing on a4c is a read herring. John B. On May 15, 2014, at 6:55 AM, Phil Hunt wrote: > I think those are things to discuss if the authen is on the charter.=20= >=20 > So we have now clarified that the basic connect profile doesn't do = just authen and requires identity profile services.=20 >=20 > Phil >=20 > On May 14, 2014, at 18:57, Justin Richer wrote: >=20 >> Right, so instead of being able to use my authorization endpoint, = which already authenticates the user and can gather consent, I need to = implement a new endpoint that's not-quite-OAuth but is almost like it. = But it's enough to be confusing because sometimes I go to this new = endpoint endpoint and also get an access token anyway, to use somewhere = that I'm not sure where. And I'm not sure I can collapse the two = endpoints and re-use my OAuth infrastructure. After all, I still need to = use the token endpoint, and by that point my server needs to know which = endpoint the user went to in the first place to make that switch. As a = developer, this all sounds horribly convoluted and complicated to track. = Do I get to re-use any of the components from an authorization endpoint? = How do I know whether or not to issue the access token if the user goes = to the authentication endpoint? And then there are the optimizations for = existing well-known and well-understood use cases: what if my client is = sitting in the same browser session and just wants to get the user = assertion directly instead of going through a round trip? Do I need to = make two round trips if I'm getting a protected API at the same time as = authn data? Can I use the same response_type functionality and other = extensions on the authentication endpoint?=20 >>=20 >> In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is = dangerous and confusing and not something I think the OAuth WG should be = a part of. And I really just don't see the point of it, unless the goal = is to pollute the standards space which Connect currently occupies. Is = Connect perfect? Heck no. But it's far and away the best thing we've had = in a long time, and it already does every single thing you are asking = for from this new draft. >>=20 >> -- Justin >>=20 >> On 5/14/2014 9:43 PM, Phil Hunt wrote: >>> Sorry I meant to say this is why it has the /authenticate endpoint = to indicate the client only wants the users session information. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>> On May 14, 2014, at 6:42 PM, Phil Hunt wrote: >>>=20 >>>> Right. This is why it has a different point because the client = does NOT want a resource token. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>> On May 14, 2014, at 6:41 PM, Justin Richer wrote: >>>>=20 >>>>> Actually, it's about OAuth compatibility. With OAuth, you get an = access token to be used at a protected resource. That's what it's for, = that's what clients do the OAuth dance(s) for. Connect defines that = protected resource as the userinfo endpoint (ie, "tells the client what = to do with it"). Connect also defines the id token that comes in along = side of the bog-standard OAuth token, and Connect is turned on and off = through the use of bog-standard OAuth scopes. So that makes it very, = very, very easy to take an OAuth server and turn it into a Connect = server. I know, I've done just that, and I've walked others through the = process as well.=20 >>>>>=20 >>>>> But the a4c draft is using something that's = almost-but-not-quite-OAuth: You might not get an access token, which is = going to confuse the heck out of most OAuth clients that I know since = that's what they're trying to get at in the first place, and there's no = real way for a client to distinguish its request for something with an = id_token vs. without. Additionally, in practice, that access token is = hugely useful. Just look at all of the weird OpenID2 and OAuth1 hybrid = stuff that people were trying to do back a few years ago on top of all = the OpenID2 extensions -- this is exactly because OpenID2 was built for = "authentication only" because that's what people thought developers = wanted, but it turned out that developers wanted a whole lot more than = that. This is one main reason the Facebook Connect and Twitter's = OAuth-based login came along and ate everyone's lunch: they gave you = authentication, but also something useful about the end user. >>>>>=20 >>>>> All said, it sounds like you want Connect but without the UserInfo = Endpoint. You'll be glad to know that you can already do that as per the = MTI definitions of the server: >>>>>=20 >>>>> http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI >>>>>=20 >>>>> You are free to implement a SCIM endpoint (which, by the way, = you'll probably need that access_token to access) or no endpoint at all, = and a compliant client ought to be able to deal with that. In fact, = there's a way to get just the id_token in Connect if that's all you care = about, but instead of hiding it inside of an existing flow that might = return something different depending on (currently-undefined) special = circumstances, it puts this mode into a separate response_type entirely = to enforce the point that it is different from regular OAuth.=20 >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>> On 5/14/2014 9:24 PM, Phil Hunt wrote: >>>>>> It isn=92t required (or should not be). This issue is OIDC = compatibility. >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On May 14, 2014, at 6:21 PM, Justin Richer = wrote: >>>>>>=20 >>>>>>> How is this functionally different from the a4c draft that also = allows the return of both an id_token and an access token?=20 >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>> On 5/14/2014 9:18 PM, Phil Hunt wrote: >>>>>>>> That=92s not a minimalistic authn only profile. >>>>>>>>=20 >>>>>>>> If you return both an access token AND an id token than the = service provide has to implement both and the client has to figure out = what to do with it. >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On May 14, 2014, at 5:44 PM, Chuck Mortimore = wrote: >>>>>>>>=20 >>>>>>>>> "I had personally requested the OIDC community about six = months ago to describe some minimal subset which we could all reasonably = implement." >>>>>>>>>=20 >>>>>>>>> I believe you're looking for this: = http://openid.net/specs/openid-connect-basic-1_0.html >>>>>>>>>=20 >>>>>>>>> -cmort >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra = wrote: >>>>>>>>> Anil, >>>>>>>>>=20 >>>>>>>>> the challenge is that OIDC is a rather large set of = specifications, and to my knowledge even the core specification has NOT = found >>>>>>>>> a complete implementation at any large IdP. I am not talking = here about boutique toolkits or startups, I am talking about the folks >>>>>>>>> who have 100s of millions of users. And, BTW, implementing a = few arbitrarily selected features from OIDC is not the same as = implementing OIDC. >>>>>>>>>=20 >>>>>>>>> As we all know, the core problem is that of adding an = authenticator token to OAuth flows, which is a rather modest extension = to OAuth. >>>>>>>>>=20 >>>>>>>>> I had personally requested the OIDC community about six months = ago to describe some minimal subset which we could all reasonably = implement. I was told that the specification was "locked down" and = fully debugged and so on, so no changes could be made. Imagine my = surprise to find that in the final drafts there was a whole new flow - = the hybrid flow - that had been added at the last minute. I had never = heard of the hybrid flow in the OAuth context - have you? So now you = have an even larger specification! >>>>>>>>>=20 >>>>>>>>> The value of draft-hunt-oauth-v2-user-a4c-01 is that it = describes precisely a minimal extension to OAuth flows to support an = authenticator token. In my experience, this is the subset that most = customers and implementors are looking for.=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> - prateek >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Tony/Phil, >>>>>>>>>> any chance you can have this work done at OIDC?=20 >>>>>>>>>>=20 >>>>>>>>>> The reason is that it is commonly understood/accepted now = that OAuth provides authorization related specs while = authentication/profile >>>>>>>>>> related specs are coming from OIDC (which builds on top of = OAuth2). >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Anil >>>>>>>>>>=20 >>>>>>>>>> On 05/14/2014 10:47 AM, Anthony Nadalin wrote: >>>>>>>>>>> I agree with Phil on this one, there are implementations of = this already and much interest >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>>=20 >>>>>>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of = Phil Hunt >>>>>>>>>>> Sent: Wednesday, May 14, 2014 8:32 AM >>>>>>>>>>> To: Brian Campbell >>>>>>>>>>> Cc: oauth@ietf.org >>>>>>>>>>> Subject: Re: [OAUTH-WG] OAuth Milestone Update and = Rechartering >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> On the contrary. I and others are interested.=20 >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> We are waiting for the charter to pick up the work.=20 >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> Regardless there will be a new draft shortly.=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Phil >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On May 14, 2014, at 5:24, Brian Campbell = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> I would object to 'OAuth Authentication' being picked up by = the WG as a work item. The starting point draft has expired and it = hasn't really been discusses since Berlin nearly a year ago. As I = recall, there was only very limited interest in it even then. I also = don't believe it fits well with the WG charter. >>>>>>>>>>>=20 >>>>>>>>>>> I would suggest the WG consider picking up 'OAuth Symmetric = Proof of Possession for Code Extension' for which there is an excellent = starting point of = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a = relativity simple security enhancement which addresses problems = currently being encountered in deployments of native clients. =20 >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Hi all, >>>>>>>>>>>=20 >>>>>>>>>>> you might have seen that we pushed the assertion documents = and the JWT >>>>>>>>>>> documents to the IESG today. We have also updated the = milestones on the >>>>>>>>>>> OAuth WG page. >>>>>>>>>>>=20 >>>>>>>>>>> This means that we can plan to pick up new work in the = group. >>>>>>>>>>> We have sent a request to Kathleen to change the milestone = for the OAuth >>>>>>>>>>> security mechanisms to use the proof-of-possession = terminology. >>>>>>>>>>>=20 >>>>>>>>>>> We also expect an updated version of the dynamic client = registration >>>>>>>>>>> spec incorporating last call feedback within about 2 weeks. >>>>>>>>>>>=20 >>>>>>>>>>> We would like you to think about adding the following = milestones to the >>>>>>>>>>> charter as part of the re-chartering effort: >>>>>>>>>>>=20 >>>>>>>>>>> ----- >>>>>>>>>>>=20 >>>>>>>>>>> Nov 2014 Submit 'Token introspection' to the IESG for = consideration as a >>>>>>>>>>> Proposed Standard >>>>>>>>>>> Starting point: >>>>>>>>>>>=20 >>>>>>>>>>> Jan 2015 Submit 'OAuth Authentication' to the IESG for = consideration as >>>>>>>>>>> a Proposed Standard >>>>>>>>>>> Starting point: >>>>>>>>>>>=20 >>>>>>>>>>> Jan 2015 Submit 'Token Exchange' to the IESG for = consideration as a >>>>>>>>>>> Proposed Standard >>>>>>>>>>> Starting point: >>>>>>>>>>>=20 >>>>>>>>>>> ----- >>>>>>>>>>>=20 >>>>>>>>>>> We also updated the charter text to reflect the current = situation. Here >>>>>>>>>>> is the proposed text: >>>>>>>>>>>=20 >>>>>>>>>>> ----- >>>>>>>>>>>=20 >>>>>>>>>>> Charter for Working Group >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The Web Authorization (OAuth) protocol allows a user to = grant a >>>>>>>>>>> third-party Web site or application access to the user's = protected >>>>>>>>>>> resources, without necessarily revealing their long-term = credentials, >>>>>>>>>>> or even their identity. For example, a photo-sharing site = that >>>>>>>>>>> supports OAuth could allow its users to use a third-party = printing Web >>>>>>>>>>> site to print their private pictures, without allowing the = printing >>>>>>>>>>> site to gain full control of the user's account and without = having the >>>>>>>>>>> user share his or her photo-sharing sites' long-term = credential with >>>>>>>>>>> the printing site. >>>>>>>>>>>=20 >>>>>>>>>>> The OAuth 2.0 protocol suite encompasses >>>>>>>>>>>=20 >>>>>>>>>>> * a protocol for obtaining access tokens from an = authorization >>>>>>>>>>> server with the resource owner's consent, >>>>>>>>>>> * protocols for presenting these access tokens to resource = server >>>>>>>>>>> for access to a protected resource, >>>>>>>>>>> * guidance for securely using OAuth 2.0, >>>>>>>>>>> * the ability to revoke access tokens, >>>>>>>>>>> * standardized format for security tokens encoded in a JSON = format >>>>>>>>>>> (JSON Web Token, JWT), >>>>>>>>>>> * ways of using assertions with OAuth, and >>>>>>>>>>> * a dynamic client registration protocol. >>>>>>>>>>>=20 >>>>>>>>>>> The working group also developed security schemes for = presenting >>>>>>>>>>> authorization tokens to access a protected resource. This = led to the >>>>>>>>>>> publication of the bearer token, as well as work that = remains to be >>>>>>>>>>> completed on proof-of-possession and token exchange. >>>>>>>>>>>=20 >>>>>>>>>>> The ongoing standardization effort within the OAuth working = group will >>>>>>>>>>> focus on enhancing interoperability and functionality of = OAuth >>>>>>>>>>> deployments, such as a standard for a token introspection = service and >>>>>>>>>>> standards for additional security of OAuth requests. >>>>>>>>>>>=20 >>>>>>>>>>> ----- >>>>>>>>>>>=20 >>>>>>>>>>> Feedback appreciated. >>>>>>>>>>>=20 >>>>>>>>>>> Ciao >>>>>>>>>>> Hannes & Derek >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Brian Campbell >>>>>>>>>>> Portfolio Architect >>>>>>>>>>>=20 >>>>>>>>>>> @ >>>>>>>>>>>=20 >>>>>>>>>>> bcampbell@pingidentity.com >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>=20 >>>>>>>>>>> Connect with us=85 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7589477A-07A0-4DAB-A981-4B54F643766E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 No.

OAuth requires that if you = use the code response type, the token endpoint must return an access = token.

Connect dosen't require a user_info = endpoint.

In the response_type "id_token" =  only a id_token is returned in the front channel in a manner = similar to SAML POST binding but fragment encoded by = default.

So there is a flow in Connect that = doesn't deliver an access token.

I think this = discussion is more about what changes you want to the core of = OAuth.

Connect worked around the OAuth spec to = be compatible with it.

Only the OAuth WG can = change OAuth and that seems to be what you want.  
a4c is = a justification for making those changes.

We = should probably focus on the core issue of what changes to RFC 6749 you = are after, to determine if the WG wants to change the = charter.

I think focusing on a4c is a read = herring.

John = B.

On May 15, 2014, at 6:55 AM, Phil = Hunt <phil.hunt@oracle.com> = wrote:

I think those are things to = discuss if the authen is on the = charter. 

So we have now clarified that = the basic connect profile doesn't do just authen and requires identity = profile services. 

Phil

On May 14, = 2014, at 18:57, Justin Richer <jricher@mit.edu> = wrote:

=20 =20 =20
Right, so instead of being able to = use my authorization endpoint, which already authenticates the user and can gather consent, I need to implement a new endpoint that's not-quite-OAuth but is almost like it. But it's enough to be confusing because sometimes I go to this new endpoint endpoint and also get an access token anyway, to use somewhere that I'm not sure where. And I'm not sure I can collapse the two endpoints and re-use my OAuth infrastructure. After all, I still need to use the token endpoint, and by that point my server needs to know which endpoint the user went to in the first place to make that switch. As a developer, this all sounds horribly convoluted and complicated to track. Do I get to re-use any of the components from an authorization endpoint? How do I know whether or not to issue the access token if the user goes to the authentication endpoint? And then there are the optimizations for existing well-known and well-understood use cases: what if my client is sitting in the same browser session and just wants to get the user assertion directly instead of going through a round trip? Do I need to make two round trips if I'm getting a protected API at the same time as authn data? Can I use the same response_type functionality and other extensions on the authentication endpoint?

In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is dangerous and confusing and not something I think the OAuth WG should be a part of. And I really just don't see the point of it, unless the goal is to pollute the standards space which Connect currently occupies. Is Connect perfect? Heck no. But it's far and away the best thing we've had in a long time, and it already does every single thing you are asking for from this new draft.

 -- Justin

On 5/14/2014 9:43 PM, Phil Hunt wrote:
Sorry I meant to say this is why it has the /authenticate endpoint to indicate the client only wants the users session information.


On May 14, 2014, at 6:42 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Right.  This = is why it has a different point because the client does NOT want a resource token.


On May 14, 2014, at 6:41 PM, Justin Richer <jricher@mit.edu> wrote:

Actually, it's = about OAuth compatibility. With OAuth, you get an access token to be used at a protected resource. That's what it's for, that's what clients do the OAuth dance(s) for. Connect defines that protected resource as the userinfo endpoint (ie, "tells the client what to do with it"). Connect also defines the id token that comes in along side of the bog-standard OAuth token, and Connect is turned on and off through the use of bog-standard OAuth scopes. So that makes it very, very, very easy to take an OAuth server and turn it into a Connect server. I know, I've done just that, and I've walked others through the process as well.

But the a4c draft is using something that's almost-but-not-quite-OAuth: You might not get an access token, which is going to confuse the heck out of most OAuth clients that I know since that's what they're trying to get at in the first place, and there's no real way for a client to distinguish its request for something with an id_token vs. without. Additionally, in practice, that access token is hugely useful. Just look at all of the weird OpenID2 and OAuth1 hybrid stuff that people were trying to do back a few years ago on top of all the OpenID2 extensions -- this is exactly because OpenID2 was built for "authentication only" because that's what people thought developers wanted, but it turned out that developers wanted a whole lot more than that. This is one main reason the Facebook Connect and Twitter's OAuth-based login came along and ate everyone's lunch: they gave you authentication, but also something useful about the end user.

All said, it sounds like you want Connect but without the UserInfo Endpoint. You'll be glad to know that you can already do that as per the MTI definitions of the server:

  ht= tp://openid.net/specs/openid-connect-core-1_0.html#ServerMTI

You are free to implement a SCIM endpoint (which, by the way, you'll probably need that access_token to access) or no endpoint at all, and a compliant client ought to be able to deal with that. In fact, there's a way to get just the id_token in Connect if that's all you care about, but instead of hiding it inside of an existing flow that might return something different depending on (currently-undefined) special circumstances, it puts this mode into a separate response_type entirely to enforce the point that it is different from regular OAuth. =

 -- Justin

On 5/14/2014 9:24 PM, Phil Hunt wrote:
It isn=92t required (or should not be).  This issue is OIDC compatibility.


On May 14, 2014, at 6:21 PM, Justin Richer <jricher@mit.edu> wrote:

=
How is this functionally different from the a4c draft that also allows the return of both an id_token and an access token?

 -- Justin

On 5/14/2014 9:18 PM, Phil Hunt wrote:
That=92s not a minimalistic authn only profile.

If you return both an access token AND an id token than the service provide has to implement both and the client has to figure out what to do with it.


On May 14, 2014, at 5:44 PM, Chuck Mortimore <cmortimore@salesforce.com>= ; wrote:

"I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement."
=
I believe you're looking for this: http://open= id.net/specs/openid-connect-basic-1_0.html
=
-cmort



On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:
Anil,

the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily selected features from OIDC is not the same as implementing = OIDC.

As we all know, the core problem is that of adding an authenticator token to OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that  the specification was "locked down" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!

The value of = draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely a minimal extension to OAuth flows to support an authenticator token.  In my experience, this is the subset that most customers and implementors are looking for.


- = prateek





=
Tony/Phil,
  any = chance you can have this work done at OIDC?

The reason is that it is commonly = understood/accepted now that OAuth provides authorization related specs while = authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin = wrote:

I agree with Phil on this one, there are = implementations of this already and much = interest

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian = Campbell
Cc: oauth@ietf.org
= Subject: Re: [OAUTH-WG] OAuth Milestone Update and = Rechartering

 

On the contrary. I and others are = interested. 

 

We are waiting for the charter to pick up the = work. 

 

Regardless there will be a new draft = shortly. 


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to = 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As = I recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients.  =

 

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG = page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the = proof-of-possession = terminology.

We also expect an updated version of the dynamic client = registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth = Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed = text:

-----

Charter for Working = Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term = credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing = Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite = encompasses

* a protocol for obtaining access tokens from an = authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access = tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON = Web Token, = JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to = be
completed on = proof-of-possession and token exchange.

The ongoing = standardization effort within the OAuth working group will
focus on enhancing = interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service = and
standards for additional security of OAuth requests.

-----

Feedback = appreciated.

Ciao
Hannes & Derek



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




--

3D"Ping

Brian = Campbell
Portfolio = Architect

@

bcampbell@pingidentity.com

3D"phone"

+1 720.317.2061

Connect with = us=85

3D"twitter3D"youtube3D"LinkedIn3D"Facebook3D"Google+3D"slideshare3D"flipboard3D"rss

3D"Register
 

_______________________________________________
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



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






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

= --Apple-Mail=_7589477A-07A0-4DAB-A981-4B54F643766E-- From nobody Wed May 14 23:12:58 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A457B1A03D9 for ; Wed, 14 May 2014 23:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.84 X-Spam-Level: X-Spam-Status: No, score=-4.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 8p0sQCzC5ayS for ; Wed, 14 May 2014 23:12:45 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E167B1A03CE for ; Wed, 14 May 2014 23:12:44 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4F6CaFJ016076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 06:12:36 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s4F6CZMc019788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 May 2014 06:12:35 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s4F6CXBP019697; Thu, 15 May 2014 06:12:33 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 May 2014 23:12:32 -0700 References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> <537416A9.5060701@mit.edu> <53741B2F.4040506@mit.edu> <1F00EAF0-CC8F-469F-84F3-50C534325360@oracle.com> <51BD7E1D-5C8D-4B6F-8F3C-64137CBDA0DA@oracle.com> <53741F27.4010100@mit.edu> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-5ED4AD2A-DB35-46B8-AC1F-59497AD5CCCA Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D167) From: Phil Hunt Date: Wed, 14 May 2014 23:12:28 -0700 To: John Bradley X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/I5Zpb_J0uYCU-nJ1FtViA-uk31k Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 06:12:52 -0000 --Apple-Mail-5ED4AD2A-DB35-46B8-AC1F-59497AD5CCCA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Which flow is that? It certainly wasn't the one Justin pointed to.=20 Phil > On May 14, 2014, at 22:31, John Bradley wrote: >=20 > No. >=20 > OAuth requires that if you use the code response type, the token endpoint m= ust return an access token. >=20 > Connect dosen't require a user_info endpoint. >=20 > In the response_type "id_token" only a id_token is returned in the front c= hannel in a manner similar to SAML POST binding but fragment encoded by defa= ult. >=20 > So there is a flow in Connect that doesn't deliver an access token. >=20 > I think this discussion is more about what changes you want to the core of= OAuth. >=20 > Connect worked around the OAuth spec to be compatible with it. >=20 > Only the OAuth WG can change OAuth and that seems to be what you want. =20= > a4c is a justification for making those changes. >=20 > We should probably focus on the core issue of what changes to RFC 6749 you= are after, to determine if the WG wants to change the charter. >=20 > I think focusing on a4c is a read herring. >=20 > John B. >=20 >> On May 15, 2014, at 6:55 AM, Phil Hunt wrote: >>=20 >> I think those are things to discuss if the authen is on the charter.=20 >>=20 >> So we have now clarified that the basic connect profile doesn't do just a= uthen and requires identity profile services.=20 >>=20 >> Phil >>=20 >>> On May 14, 2014, at 18:57, Justin Richer wrote: >>>=20 >>> Right, so instead of being able to use my authorization endpoint, which a= lready authenticates the user and can gather consent, I need to implement a n= ew endpoint that's not-quite-OAuth but is almost like it. But it's enough to= be confusing because sometimes I go to this new endpoint endpoint and also g= et an access token anyway, to use somewhere that I'm not sure where. And I'm= not sure I can collapse the two endpoints and re-use my OAuth infrastructur= e. After all, I still need to use the token endpoint, and by that point my s= erver needs to know which endpoint the user went to in the first place to ma= ke that switch. As a developer, this all sounds horribly convoluted and comp= licated to track. Do I get to re-use any of the components from an authoriza= tion endpoint? How do I know whether or not to issue the access token if the= user goes to the authentication endpoint? And then there are the optimizati= ons for existing well-known and well-understood use cases: what if my client= is sitting in the same browser session and just wants to get the user asser= tion directly instead of going through a round trip? Do I need to make two r= ound trips if I'm getting a protected API at the same time as authn data? Ca= n I use the same response_type functionality and other extensions on the aut= hentication endpoint?=20 >>>=20 >>> In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is da= ngerous and confusing and not something I think the OAuth WG should be= a part of. And I really just don't see the point of it, unless the goal is t= o pollute the standards space which Connect currently occupies. Is Connect p= erfect? Heck no. But it's far and away the best thing we've had in a long ti= me, and it already does every single thing you are asking for from this new d= raft. >>>=20 >>> -- Justin >>>=20 >>>> On 5/14/2014 9:43 PM, Phil Hunt wrote: >>>> Sorry I meant to say this is why it has the /authenticate endpoint to i= ndicate the client only wants the users session information. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>> On May 14, 2014, at 6:42 PM, Phil Hunt wrote: >>>>>=20 >>>>> Right. This is why it has a different point because the client does N= OT want a resource token. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On May 14, 2014, at 6:41 PM, Justin Richer wrote: >>>>>>=20 >>>>>> Actually, it's about OAuth compatibility. With OAuth, you get an acce= ss token to be used at a protected resource. That's what it's for, that's wh= at clients do the OAuth dance(s) for. Connect defines that protected resourc= e as the userinfo endpoint (ie, "tells the client what to do with it"). Conn= ect also defines the id token that comes in along side of the bog-standard O= Auth token, and Connect is turned on and off through the use of bog-standard= OAuth scopes. So that makes it very, very, very easy to take an OAuth serve= r and turn it into a Connect server. I know, I've done just that, and I've w= alked others through the process as well.=20 >>>>>>=20 >>>>>> But the a4c draft is using something that's almost-but-not-quite-OAut= h: You might not get an access token, which is going to confuse the heck out= of most OAuth clients that I know since that's what they're trying to get a= t in the first place, and there's no real way for a client to distinguish it= s request for something with an id_token vs. without. Additionally, in pract= ice, that access token is hugely useful. Just look at all of the weird OpenI= D2 and OAuth1 hybrid stuff that people were trying to do back a few years ag= o on top of all the OpenID2 extensions -- this is exactly because OpenID2 wa= s built for "authentication only" because that's what people thought develop= ers wanted, but it turned out that developers wanted a whole lot more than t= hat. This is one main reason the Facebook Connect and Twitter's OAuth-based l= ogin came along and ate everyone's lunch: they gave you authentication, but a= lso something useful about the end user. >>>>>>=20 >>>>>> All said, it sounds like you want Connect but without the UserInfo En= dpoint. You'll be glad to know that you can already do that as per the MTI d= efinitions of the server: >>>>>>=20 >>>>>> http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI >>>>>>=20 >>>>>> You are free to implement a SCIM endpoint (which, by the way, you'll p= robably need that access_token to access) or no endpoint at all, and a compl= iant client ought to be able to deal with that. In fact, there's a way to ge= t just the id_token in Connect if that's all you care about, but instead of h= iding it inside of an existing flow that might return something different de= pending on (currently-undefined) special circumstances, it puts this mode in= to a separate response_type entirely to enforce the point that it is differe= nt from regular OAuth.=20 >>>>>>=20 >>>>>> -- Justin >>>>>>=20 >>>>>>> On 5/14/2014 9:24 PM, Phil Hunt wrote: >>>>>>> It isn=E2=80=99t required (or should not be). This issue is OIDC co= mpatibility. >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On May 14, 2014, at 6:21 PM, Justin Richer wrote:= >>>>>>>>=20 >>>>>>>> How is this functionally different from the a4c draft that also all= ows the return of both an id_token and an access token?=20 >>>>>>>>=20 >>>>>>>> -- Justin >>>>>>>>=20 >>>>>>>>> On 5/14/2014 9:18 PM, Phil Hunt wrote: >>>>>>>>> That=E2=80=99s not a minimalistic authn only profile. >>>>>>>>>=20 >>>>>>>>> If you return both an access token AND an id token than the servic= e provide has to implement both and the client has to figure out what to do w= ith it. >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>> @independentid >>>>>>>>> www.independentid.com >>>>>>>>> phil.hunt@oracle.com >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On May 14, 2014, at 5:44 PM, Chuck Mortimore wrote: >>>>>>>>>>=20 >>>>>>>>>> "I had personally requested the OIDC community about six months a= go to describe some minimal subset which we could all reasonably implement."= >>>>>>>>>>=20 >>>>>>>>>> I believe you're looking for this: http://openid.net/specs/openid= -connect-basic-1_0.html >>>>>>>>>>=20 >>>>>>>>>> -cmort >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra wrote: >>>>>>>>>>> Anil, >>>>>>>>>>>=20 >>>>>>>>>>> the challenge is that OIDC is a rather large set of specificatio= ns, and to my knowledge even the core specification has NOT found >>>>>>>>>>> a complete implementation at any large IdP. I am not talking her= e about boutique toolkits or startups, I am talking about the folks >>>>>>>>>>> who have 100s of millions of users. And, BTW, implementing a few= arbitrarily selected features from OIDC is not the same as implementing OID= C. >>>>>>>>>>>=20 >>>>>>>>>>> As we all know, the core problem is that of adding an authentica= tor token to OAuth flows, which is a rather modest extension to OAuth. >>>>>>>>>>>=20 >>>>>>>>>>> I had personally requested the OIDC community about six months a= go to describe some minimal subset which we could all reasonably implement. I= was told that the specification was "locked down" and fully debugged and s= o on, so no changes could be made. Imagine my surprise to find that in the f= inal drafts there was a whole new flow - the hybrid flow - that had been add= ed at the last minute. I had never heard of the hybrid flow in the OAuth con= text - have you? So now you have an even larger specification! >>>>>>>>>>>=20 >>>>>>>>>>> The value of draft-hunt-oauth-v2-user-a4c-01 is that it describe= s precisely a minimal extension to OAuth flows to support an authenticator t= oken. In my experience, this is the subset that most customers and implemen= tors are looking for.=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> - prateek >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> Tony/Phil, >>>>>>>>>>>> any chance you can have this work done at OIDC?=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> The reason is that it is commonly understood/accepted now that O= Auth provides authorization related specs while authentication/profile >>>>>>>>>>>> related specs are coming from OIDC (which builds on top of OAut= h2). >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Anil >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 05/14/2014 10:47 AM, Anthony Nadalin wrote: >>>>>>>>>>>>> I agree with Phil on this one, there are implementations of th= is already and much interest >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil H= unt >>>>>>>>>>>>> Sent: Wednesday, May 14, 2014 8:32 AM >>>>>>>>>>>>> To: Brian Campbell >>>>>>>>>>>>> Cc: oauth@ietf.org >>>>>>>>>>>>> Subject: Re: [OAUTH-WG] OAuth Milestone Update and Recharterin= g >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> On the contrary. I and others are interested.=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> We are waiting for the charter to pick up the work.=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> Regardless there will be a new draft shortly.=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Phil >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On May 14, 2014, at 5:24, Brian Campbell wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I would object to 'OAuth Authentication' being picked up by th= e WG as a work item. The starting point draft has expired and it hasn't real= ly been discusses since Berlin nearly a year ago. As I recall, there was on= ly very limited interest in it even then. I also don't believe it fits well w= ith the WG charter. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I would suggest the WG consider picking up 'OAuth Symmetric Pr= oof of Possession for Code Extension' for which there is an excellent starti= ng point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a= relativity simple security enhancement which addresses problems currently b= eing encountered in deployments of native clients. =20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> you might have seen that we pushed the assertion documents and= the JWT >>>>>>>>>>>>> documents to the IESG today. We have also updated the mileston= es on the >>>>>>>>>>>>> OAuth WG page. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> This means that we can plan to pick up new work in the group. >>>>>>>>>>>>> We have sent a request to Kathleen to change the milestone for= the OAuth >>>>>>>>>>>>> security mechanisms to use the proof-of-possession terminology= . >>>>>>>>>>>>>=20 >>>>>>>>>>>>> We also expect an updated version of the dynamic client regist= ration >>>>>>>>>>>>> spec incorporating last call feedback within about 2 weeks. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> We would like you to think about adding the following mileston= es to the >>>>>>>>>>>>> charter as part of the re-chartering effort: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> ----- >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Nov 2014 Submit 'Token introspection' to the IESG for consider= ation as a >>>>>>>>>>>>> Proposed Standard >>>>>>>>>>>>> Starting point: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Jan 2015 Submit 'OAuth Authentication' to the IESG for conside= ration as >>>>>>>>>>>>> a Proposed Standard >>>>>>>>>>>>> Starting point: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Jan 2015 Submit 'Token Exchange' to the IESG for consideration= as a >>>>>>>>>>>>> Proposed Standard >>>>>>>>>>>>> Starting point: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> ----- >>>>>>>>>>>>>=20 >>>>>>>>>>>>> We also updated the charter text to reflect the current situat= ion. Here >>>>>>>>>>>>> is the proposed text: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> ----- >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Charter for Working Group >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The Web Authorization (OAuth) protocol allows a user to grant a= >>>>>>>>>>>>> third-party Web site or application access to the user's prote= cted >>>>>>>>>>>>> resources, without necessarily revealing their long-term crede= ntials, >>>>>>>>>>>>> or even their identity. For example, a photo-sharing site that= >>>>>>>>>>>>> supports OAuth could allow its users to use a third-party prin= ting Web >>>>>>>>>>>>> site to print their private pictures, without allowing the pri= nting >>>>>>>>>>>>> site to gain full control of the user's account and without ha= ving the >>>>>>>>>>>>> user share his or her photo-sharing sites' long-term credentia= l with >>>>>>>>>>>>> the printing site. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The OAuth 2.0 protocol suite encompasses >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * a protocol for obtaining access tokens from an authorization= >>>>>>>>>>>>> server with the resource owner's consent, >>>>>>>>>>>>> * protocols for presenting these access tokens to resource ser= ver >>>>>>>>>>>>> for access to a protected resource, >>>>>>>>>>>>> * guidance for securely using OAuth 2.0, >>>>>>>>>>>>> * the ability to revoke access tokens, >>>>>>>>>>>>> * standardized format for security tokens encoded in a JSON fo= rmat >>>>>>>>>>>>> (JSON Web Token, JWT), >>>>>>>>>>>>> * ways of using assertions with OAuth, and >>>>>>>>>>>>> * a dynamic client registration protocol. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The working group also developed security schemes for presenti= ng >>>>>>>>>>>>> authorization tokens to access a protected resource. This led t= o the >>>>>>>>>>>>> publication of the bearer token, as well as work that remains t= o be >>>>>>>>>>>>> completed on proof-of-possession and token exchange. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The ongoing standardization effort within the OAuth working gr= oup will >>>>>>>>>>>>> focus on enhancing interoperability and functionality of OAuth= >>>>>>>>>>>>> deployments, such as a standard for a token introspection serv= ice and >>>>>>>>>>>>> standards for additional security of OAuth requests. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> ----- >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Feedback appreciated. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Ciao >>>>>>>>>>>>> Hannes & Derek >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>> Portfolio Architect >>>>>>>>>>>>>=20 >>>>>>>>>>>>> @ >>>>>>>>>>>>>=20 >>>>>>>>>>>>> bcampbell@pingidentity.com >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Connect with us=E2=80=A6 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>=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 >=20 --Apple-Mail-5ED4AD2A-DB35-46B8-AC1F-59497AD5CCCA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Which flow is that? It certainly wasn'= t the one Justin pointed to. 

Phil

On May 14, 2014= , at 22:31, John Bradley <ve7jtb@ve7= jtb.com> wrote:

No.
OAuth requires that if you use the code response type, the t= oken endpoint must return an access token.

Connect d= osen't require a user_info endpoint.

In the respons= e_type "id_token"  only a id_token is returned in the front channel in a= manner similar to SAML POST binding but fragment encoded by default.
<= div>
So there is a flow in Connect that doesn't deliver an acc= ess token.

I think this discussion is more about wh= at changes you want to the core of OAuth.

Connect w= orked around the OAuth spec to be compatible with it.

Only the OAuth WG can change OAuth and that seems to be what you want. &n= bsp;
a4c is a justification for making those changes.
We should probably focus on the core issue of what changes to R= FC 6749 you are after, to determine if the WG wants to change the charter.

I think focusing on a4c is a read herring.

John B.

On May 15, 2014, a= t 6:55 AM, Phil Hunt <phil.hunt@o= racle.com> wrote:

I think those are things to discuss i= f the authen is on the charter. 

So we have no= w clarified that the basic connect profile doesn't do just authen and requir= es identity profile services. 

Phil

On May 1= 4, 2014, at 18:57, Justin Richer <jric= her@mit.edu> wrote:

=20 =20 =20
Right, so instead of being able to use my authorization endpoint, which already authenticates the user and can gather consent, I need to implement a new endpoint that's not-quite-OAuth but is almost like it. But it's enough to be confusing because sometimes I go to this new endpoint endpoint and also get an access token anyway, to use somewhere that I'm not sure where. And I'm not sure I can collapse the two endpoints and re-use my OAuth infrastructure. After all, I still need to use the token endpoint, and by that point my server needs to know which endpoint the user went to in the first place to make that switch. As a developer, this all sounds horribly convoluted and complicated to track. Do I get to re-use any of the components from an authorization endpoint? How do I know whether or not to issue the access token if the user goes to the authentication endpoint? And then there are the optimizations for existing well-known and well-understood use cases: what if my client is sitting in the same browser session and just wants to get the user assertion directly instead of going through a round trip? Do I need to make two round trips if I'm getting a protected API at the same time as authn data? Can I use the same response_type functionality and other extensions on the authentication endpoint?

In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is dangerous and confusing and not something I think the OAuth WG should be a part of. And I really just don't see the point of it, unless the goal is to pollute the standards space which Connect currently occupies. Is Connect perfect? Heck no. But it's far and away the best thing we've had in a long time, and it already does every single thing you are asking for from this new draft.

 -- Justin

On 5/14/2014 9:43 PM, Phil Hunt wrote:
Sorry I meant to say this is why it has the /authenticate endpoint to indicate the client only wants the users session information.


On May 14, 2014, at 6:42 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Right.  This is why it has a different point because the client does NOT want a resource token.


On May 14, 2014, at 6:41 PM, Justin Richer <jricher@mit.edu>= ; wrote:

Actually, it's about OAuth compatibility. With OAuth, you get an access token to be used at a protected resource. That's what it's for, that's what clients do the OAuth dance(s) for. Connect defines that protected resource as the userinfo endpoint (ie, "tells the client what to do with it"). Connect also defines the id token that comes in along side of the bog-standard OAuth token, and Connect is turned on and off through the use of bog-standard OAuth scopes. So that makes it very, very, very easy to take an OAuth server and turn it into a Connect server. I know, I've done just that, and I've walked others through the process as well.

But the a4c draft is using something that's almost-but-not-quite-OAuth: You might not get an access token, which is going to confuse the heck out of most OAuth clients that I know since that's what they're trying to get at in the first place, and there's no real way for a client to distinguish its request for something with an id_token vs. without. Additionally, in practice, that access token is hugely useful. Just look at all of the weird OpenID2 and OAuth1 hybrid stuff that people were trying to do back a few years ago on top of all the OpenID2 extensions -- this is exactly because OpenID2 was built for "authentication only" because that's what people thought developers wanted, but it turned out that developers wanted a whole lot more than that. This is one main reason the Facebook Connect and Twitter's OAuth-based login came along and ate everyone's lunch: they gave you authentication, but also something useful about the end user.

All said, it sounds like you want Connect but without the UserInfo Endpoint. You'll be glad to know that you can already do that as per the MTI definitions of the server:

  http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI

You are free to implement a SCIM endpoint (which, by the way, you'll probably need that access_token to access) or no endpoint at all, and a compliant client ought to be able to deal with that. In fact, there's a way to get just the id_token in Connect if that's all you care about, but instead of hiding it inside of an existing flow that might return something different depending on (currently-undefined) special circumstances, it puts this mode into a separate response_type entirely to enforce the point that it is different from regular OAuth.

 -- Justin

On 5/14/2014 9:24 PM, Phil Hunt wrote:
It isn=E2=80=99t required (or should not be).  This issue is OIDC compatibility.


On May 14, 2014, at 6:21 PM, Justin Richer <jricher@mit.edu> wrote:

How is this functionally different from the a4c draft that also allows the return of both an id_token and an access token?

 -- Justin

On 5/14/2014 9:18 PM, Phil Hunt wrote:
That=E2=80=99s not a minimalistic authn only profile.

If you return both an access token AND an id token than the service provide has to implement both and the client has to figure out what to do with it.



"I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement."

=
I believe you're looking for this: http://op= enid.net/specs/openid-connect-basic-1_0.html

=
-cmor= t



On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:
Anil,

the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token to OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that  the specification was "locked down" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!

The value of draft-hunt-oauth-v2-user= -a4c-01 is that it describes precisely a minimal extension to OAuth flows to support an authenticator token.  In my experience, this is the subset that most customers and implementors are looking for.


- prateek

=



Tony/Phil,   any chance you can have this work done at OIDC?

The reason is that it is commonly understood/accepte= d now that OAuth provides authorization related specs while authentication/pro= file
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:
=

I agree with Phil on this one, there are implementations of this already and much interest

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
= Cc: oauth@= ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

On the contrary. I and others are interested. <= /p>

 

We are waiting for the charter to pick up the work. 

 

Regardless there will be a new draft shortly. 

=


Phil


On May 14, 2014, at 5:24, Brian Campbell <b= campbell@pingidentity.com> wrote:

I would object to 'OAuth Authenticati= on' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <ha= nnes.tschofenig@gmx.net> wrote:

Hi= all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.
=
This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possessio= n terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:
=
-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
= * standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possessio= n and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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



=
--

3D"Ping

Brian Campbell
Portf= olio Architect

@

bcampbell@pingidentity.com
<= p class=3D"MsoNormal" style=3D"text-align:center" align=3D"center">3D"phone"

+1 720.317.2061

Connect with us=E2=80=A6

3D"t=3D"y=3D"=3D"=3D=3D=3D"rss

 

_______________________________________________
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
htt= ps://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/o=
auth






=20
_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.org/mail= man/listinfo/oauth

= --Apple-Mail-5ED4AD2A-DB35-46B8-AC1F-59497AD5CCCA-- From nobody Thu May 15 00:03:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC621A0245 for ; Thu, 15 May 2014 00:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 XyO0-fQZpa8u for ; Thu, 15 May 2014 00:03:26 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE3F1A0243 for ; Thu, 15 May 2014 00:03:26 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 15 May 2014 07:03:18 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0949.001; Thu, 15 May 2014 07:03:18 +0000 From: Anthony Nadalin To: John Bradley , Phil Hunt Thread-Topic: [OAUTH-WG] OAuth Milestone Update and Rechartering Thread-Index: AQHPawEbu8OzlywPcU+RkLqz+fSkNptACOgAgAA0VICAAAQKYIAAHggAgAB2bICAAAH9AIAACU+AgAABCYCAAACtAIAABLiAgAAAg4CAAAA7gIAAA/2AgAAxsoCAAAoCAIAAF2fQ Date: Thu, 15 May 2014 07:03:17 +0000 Message-ID: References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> <537416A9.5060701@mit.edu> <53741B2F.4040506@mit.edu> <1F00EAF0-CC8F-469F-84F3-50C534325360@oracle.com> <51BD7E1D-5C8D-4B6F-8F3C-64137CBDA0DA@oracle.com> <53741F27.4010100@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.110.65.1] x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(52034003)(53754006)(199002)(189002)(24454002)(52314003)(57704003)(377454003)(479174003)(74662001)(46102001)(21056001)(66066001)(77982001)(99286001)(79102001)(4396001)(80022001)(15975445006)(101416001)(76482001)(20776003)(74316001)(18206015023)(86612001)(19580405001)(19609705001)(83322001)(19580395003)(33646001)(54356999)(64706001)(19273905006)(19300405004)(31966008)(81342001)(50986999)(15198665003)(99396002)(19617315010)(86362001)(83072002)(85852003)(19618635001)(92566001)(76576001)(2656002)(74502001)(19625215002)(81542001)(76176999)(87936001)(15202345003)(15395725003)(77096999)(16236675002)(42262001)(9984715005)(24736002)(19621445023); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB309; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; Content-Type: multipart/alternative; boundary="_000_bd52fcf7cac04f91922f7c4b8ecabaf8BLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/4D1E1bBtBII-9A9wkMj89LRCqRc Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 07:03:36 -0000 --_000_bd52fcf7cac04f91922f7c4b8ecabaf8BLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So Oauth already treads into the authentication space to some extent and en= ough of an extent to create additional security issues and threats. From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley Sent: Wednesday, May 14, 2014 10:32 PM To: Phil Hunt Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering No. OAuth requires that if you use the code response type, the token endpoint m= ust return an access token. Connect dosen't require a user_info endpoint. In the response_type "id_token" only a id_token is returned in the front c= hannel in a manner similar to SAML POST binding but fragment encoded by def= ault. So there is a flow in Connect that doesn't deliver an access token. I think this discussion is more about what changes you want to the core of = OAuth. Connect worked around the OAuth spec to be compatible with it. Only the OAuth WG can change OAuth and that seems to be what you want. a4c is a justification for making those changes. We should probably focus on the core issue of what changes to RFC 6749 you = are after, to determine if the WG wants to change the charter. I think focusing on a4c is a read herring. John B. On May 15, 2014, at 6:55 AM, Phil Hunt > wrote: I think those are things to discuss if the authen is on the charter. So we have now clarified that the basic connect profile doesn't do just aut= hen and requires identity profile services. Phil On May 14, 2014, at 18:57, Justin Richer > wrote: Right, so instead of being able to use my authorization endpoint, which alr= eady authenticates the user and can gather consent, I need to implement a n= ew endpoint that's not-quite-OAuth but is almost like it. But it's enough t= o be confusing because sometimes I go to this new endpoint endpoint and als= o get an access token anyway, to use somewhere that I'm not sure where. And= I'm not sure I can collapse the two endpoints and re-use my OAuth infrastr= ucture. After all, I still need to use the token endpoint, and by that poin= t my server needs to know which endpoint the user went to in the first plac= e to make that switch. As a developer, this all sounds horribly convoluted = and complicated to track. Do I get to re-use any of the components from an = authorization endpoint? How do I know whether or not to issue the access to= ken if the user goes to the authentication endpoint? And then there are the= optimizations for existing well-known and well-understood use cases: what = if my client is sitting in the same browser session and just wants to get t= he user assertion directly instead of going through a round trip? Do I need= to make two round trips if I'm getting a protected API at the same time as= authn data? Can I use the same response_type functionality and other exten= sions on the authentication endpoint? In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is dange= rous and confusing and not something I think the OAuth WG should be a part = of. And I really just don't see the point of it, unless the goal is to poll= ute the standards space which Connect currently occupies. Is Connect perfec= t? Heck no. But it's far and away the best thing we've had in a long time, = and it already does every single thing you are asking for from this new dra= ft. -- Justin On 5/14/2014 9:43 PM, Phil Hunt wrote: Sorry I meant to say this is why it has the /authenticate endpoint to indic= ate the client only wants the users session information. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 14, 2014, at 6:42 PM, Phil Hunt > wrote: Right. This is why it has a different point because the client does NOT wa= nt a resource token. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 14, 2014, at 6:41 PM, Justin Richer > wrote: Actually, it's about OAuth compatibility. With OAuth, you get an access tok= en to be used at a protected resource. That's what it's for, that's what cl= ients do the OAuth dance(s) for. Connect defines that protected resource as= the userinfo endpoint (ie, "tells the client what to do with it"). Connect= also defines the id token that comes in along side of the bog-standard OAu= th token, and Connect is turned on and off through the use of bog-standard = OAuth scopes. So that makes it very, very, very easy to take an OAuth serve= r and turn it into a Connect server. I know, I've done just that, and I've = walked others through the process as well. But the a4c draft is using something that's almost-but-not-quite-OAuth: You= might not get an access token, which is going to confuse the heck out of m= ost OAuth clients that I know since that's what they're trying to get at in= the first place, and there's no real way for a client to distinguish its r= equest for something with an id_token vs. without. Additionally, in practic= e, that access token is hugely useful. Just look at all of the weird OpenID= 2 and OAuth1 hybrid stuff that people were trying to do back a few years ag= o on top of all the OpenID2 extensions -- this is exactly because OpenID2 w= as built for "authentication only" because that's what people thought devel= opers wanted, but it turned out that developers wanted a whole lot more tha= n that. This is one main reason the Facebook Connect and Twitter's OAuth-ba= sed login came along and ate everyone's lunch: they gave you authentication= , but also something useful about the end user. All said, it sounds like you want Connect but without the UserInfo Endpoint= . You'll be glad to know that you can already do that as per the MTI defini= tions of the server: http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI You are free to implement a SCIM endpoint (which, by the way, you'll probab= ly need that access_token to access) or no endpoint at all, and a compliant= client ought to be able to deal with that. In fact, there's a way to get j= ust the id_token in Connect if that's all you care about, but instead of hi= ding it inside of an existing flow that might return something different de= pending on (currently-undefined) special circumstances, it puts this mode i= nto a separate response_type entirely to enforce the point that it is diffe= rent from regular OAuth. -- Justin On 5/14/2014 9:24 PM, Phil Hunt wrote: It isn't required (or should not be). This issue is OIDC compatibility. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 14, 2014, at 6:21 PM, Justin Richer > wrote: How is this functionally different from the a4c draft that also allows the = return of both an id_token and an access token? -- Justin On 5/14/2014 9:18 PM, Phil Hunt wrote: That's not a minimalistic authn only profile. If you return both an access token AND an id token than the service provide= has to implement both and the client has to figure out what to do with it. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 14, 2014, at 5:44 PM, Chuck Mortimore > wrote: "I had personally requested the OIDC community about six months ago to desc= ribe some minimal subset which we could all reasonably implement." I believe you're looking for this: http://openid.net/specs/openid-connect-b= asic-1_0.html -cmort On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra > wrote: Anil, the challenge is that OIDC is a rather large set of specifications, and to = my knowledge even the core specification has NOT found a complete implementation at any large IdP. I am not talking here about bou= tique toolkits or startups, I am talking about the folks who have 100s of millions of users. And, BTW, implementing a few arbitraril= y selected features from OIDC is not the same as implementing OIDC. As we all know, the core problem is that of adding an authenticator token t= o OAuth flows, which is a rather modest extension to OAuth. I had personally requested the OIDC community about six months ago to descr= ibe some minimal subset which we could all reasonably implement. I was told= that the specification was "locked down" and fully debugged and so on, so= no changes could be made. Imagine my surprise to find that in the final dr= afts there was a whole new flow - the hybrid flow - that had been added at = the last minute. I had never heard of the hybrid flow in the OAuth context = - have you? So now you have an even larger specification! The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely= a minimal extension to OAuth flows to support an authenticator token. In = my experience, this is the subset that most customers and implementors are = looking for. - prateek Tony/Phil, any chance you can have this work done at OIDC? The reason is that it is commonly understood/accepted now that OAuth provid= es authorization related specs while authentication/profile related specs are coming from OIDC (which builds on top of OAuth2). Regards, Anil On 05/14/2014 10:47 AM, Anthony Nadalin wrote: I agree with Phil on this one, there are implementations of this already an= d much interest From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, May 14, 2014 8:32 AM To: Brian Campbell Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering On the contrary. I and others are interested. We are waiting for the charter to pick up the work. Regardless there will be a new draft shortly. Phil On May 14, 2014, at 5:24, Brian Campbell > wrote: I would object to 'OAuth Authentication' being picked up by the WG as a wor= k item. The starting point draft has expired and it hasn't really been disc= usses since Berlin nearly a year ago. As I recall, there was only very lim= ited interest in it even then. I also don't believe it fits well with the W= G charter. I would suggest the WG consider picking up 'OAuth Symmetric Proof of Posses= sion for Code Extension' for which there is an excellent starting point of = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity= simple security enhancement which addresses problems currently being encou= ntered in deployments of native clients. On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig > wrote: Hi all, you might have seen that we pushed the assertion documents and the JWT documents to the IESG today. We have also updated the milestones on the OAuth WG page. This means that we can plan to pick up new work in the group. We have sent a request to Kathleen to change the milestone for the OAuth security mechanisms to use the proof-of-possession terminology. We also expect an updated version of the dynamic client registration spec incorporating last call feedback within about 2 weeks. We would like you to think about adding the following milestones to the charter as part of the re-chartering effort: ----- Nov 2014 Submit 'Token introspection' to the IESG for consideration as a Proposed Standard Starting point: Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as a Proposed Standard Starting point: Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a Proposed Standard Starting point: ----- We also updated the charter text to reflect the current situation. Here is the proposed text: ----- Charter for Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user share his or her photo-sharing sites' long-term credential with the printing site. The OAuth 2.0 protocol suite encompasses * a protocol for obtaining access tokens from an authorization server with the resource owner's consent, * protocols for presenting these access tokens to resource server for access to a protected resource, * guidance for securely using OAuth 2.0, * the ability to revoke access tokens, * standardized format for security tokens encoded in a JSON format (JSON Web Token, JWT), * ways of using assertions with OAuth, and * a dynamic client registration protocol. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token, as well as work that remains to be completed on proof-of-possession and token exchange. The ongoing standardization effort within the OAuth working group will focus on enhancing interoperability and functionality of OAuth deployments, such as a standard for a token introspection service and standards for additional security of OAuth requests. ----- Feedback appreciated. Ciao Hannes & Derek _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- [Ping Identity l= ogo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [phone] +1 720.317.2061 Connect with us... [twitter logo][youtube = logo]= [LinkedIn logo]<= https://www.linkedin.com/company/21870>[Facebook = logo][Google+ l= ogo][slideshare = logo][flipboard = logo][rss feed = icon] [Register for Cl= oud Identity = Summit 2014 | = Modern = Identity = Revolution | = 19-23 July, = 2014 | = Monterey, CA] _______________________________________________ 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 _______________________________________________ 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 --_000_bd52fcf7cac04f91922f7c4b8ecabaf8BLUPR03MB309namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So Oauth already treads i= nto the authentication space to some extent and enough of an extent to crea= te additional security issues and threats.

 

From: OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 14, 2014 10:32 PM
To: Phil Hunt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering=

 

No.

 

OAuth requires that if you use the code response typ= e, the token endpoint must return an access token.

 

Connect dosen't require a user_info endpoint.

 

In the response_type "id_token"  only= a id_token is returned in the front channel in a manner similar to SAML PO= ST binding but fragment encoded by default.

 

So there is a flow in Connect that doesn't deliver a= n access token.

 

I think this discussion is more about what changes y= ou want to the core of OAuth.

 

Connect worked around the OAuth spec to be compatibl= e with it.

 

Only the OAuth WG can change OAuth and that seems to= be what you want.  

a4c is a justification for making those changes.

 

We should probably focus on the core issue of what c= hanges to RFC 6749 you are after, to determine if the WG wants to change th= e charter.

 

I think focusing on a4c is a read herring.

 

John B.

 

On May 15, 2014, at 6:55 AM, Phil Hunt <phil.hunt@oracle.com> wrote:



I think those are things to discuss if the authen is= on the charter. 

 

So we have now clarified that the basic connect prof= ile doesn't do just authen and requires identity profile services. 


Phil


On May 14, 2014, at 18:57, Justin Richer <jricher@mit.edu> wrote:

Right, so instead of being able to use my authorizat= ion endpoint, which already authenticates the user and can gather consent, = I need to implement a new endpoint that's not-quite-OAuth but is almost lik= e it. But it's enough to be confusing because sometimes I go to this new endpoint endpoint and also get an acces= s token anyway, to use somewhere that I'm not sure where. And I'm not sure = I can collapse the two endpoints and re-use my OAuth infrastructure. After = all, I still need to use the token endpoint, and by that point my server needs to know which endpoint the use= r went to in the first place to make that switch. As a developer, this all = sounds horribly convoluted and complicated to track. Do I get to re-use any= of the components from an authorization endpoint? How do I know whether or not to issue the access token if the us= er goes to the authentication endpoint? And then there are the optimization= s for existing well-known and well-understood use cases: what if my client = is sitting in the same browser session and just wants to get the user assertion directly instead of going through= a round trip? Do I need to make two round trips if I'm getting a protected= API at the same time as authn data? Can I use the same response_type funct= ionality and other extensions on the authentication endpoint?

In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is dange= rous and confusing and not something I think the OAuth WG should be a part = of. And I really just don't see the point of it, unless the goal is to poll= ute the standards space which Connect currently occupies. Is Connect perfect? Heck no. But it's far and away the= best thing we've had in a long time, and it already does every single thin= g you are asking for from this new draft.

 -- Justin

On 5/14/2014 9:43 PM, Phil Hunt wrote:

Sorry I meant to say this is why it has the /authent= icate endpoint to indicate the client only wants the users session informat= ion.

 

 

 

 

On May 14, 2014, at 6:42 PM, Phil Hunt <phil.hunt@oracle.com> wrote:



Right.  This is why it has a different point be= cause the client does NOT want a resource token.

 

 

 

 

On May 14, 2014, at 6:41 PM, Justin Richer <jricher@mit.edu> wrote:



Actually, it's about OAuth compatibility. With OAuth= , you get an access token to be used at a protected resource. That's what i= t's for, that's what clients do the OAuth dance(s) for. Connect defines tha= t protected resource as the userinfo endpoint (ie, "tells the client what to do with it"). Connect al= so defines the id token that comes in along side of the bog-standard OAuth = token, and Connect is turned on and off through the use of bog-standard OAu= th scopes. So that makes it very, very, very easy to take an OAuth server and turn it into a Connect server. I know, I'= ve done just that, and I've walked others through the process as well.

But the a4c draft is using something that's almost-but-not-quite-OAuth: You= might not get an access token, which is going to confuse the heck out of m= ost OAuth clients that I know since that's what they're trying to get at in= the first place, and there's no real way for a client to distinguish its request for something with an id_= token vs. without. Additionally, in practice, that access token is hugely u= seful. Just look at all of the weird OpenID2 and OAuth1 hybrid stuff that p= eople were trying to do back a few years ago on top of all the OpenID2 extensions -- this is exactly because = OpenID2 was built for "authentication only" because that's what p= eople thought developers wanted, but it turned out that developers wanted a= whole lot more than that. This is one main reason the Facebook Connect and Twitter's OAuth-based login came along and= ate everyone's lunch: they gave you authentication, but also something use= ful about the end user.

All said, it sounds like you want Connect but without the UserInfo Endpoint= . You'll be glad to know that you can already do that as per the MTI defini= tions of the server:

  http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI
You are free to implement a SCIM endpoint (which, by the way, you'll probab= ly need that access_token to access) or no endpoint at all, and a compliant= client ought to be able to deal with that. In fact, there's a way to get j= ust the id_token in Connect if that's all you care about, but instead of hiding it inside of an existing flow th= at might return something different depending on (currently-undefined) spec= ial circumstances, it puts this mode into a separate response_type entirely= to enforce the point that it is different from regular OAuth.

 -- Justin

On 5/14/2014 9:24 PM, Phil Hunt wrote:

It isn’t required (or should not be).  Th= is issue is OIDC compatibility.

 

 

 

 

On May 14, 2014, at 6:21 PM, Justin Richer <jricher@mit.edu> wrote:



How is this functionally different from the a4c draf= t that also allows the return of both an id_token and an access token?

 -- Justin

On 5/14/2014 9:18 PM, Phil Hunt wrote:

That’s not a minimalistic authn only profile. =

 

If you return both an access token AND an id token t= han the service provide has to implement both and the client has to figure = out what to do with it.

 

 

 

 

On May 14, 2014, at 5:44 PM, Chuck Mortimore <cmortimore@salesforce.com>= wrote:



"I had personally requested the OIDC community = about six months ago to describe some minimal subset which we could all rea= sonably implement."

 

I believe you're looking for this: http://openid.net/specs/openid-connect-basic-1_0.html

 

-cmort

 

 

 

On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <= prateek.mish= ra@oracle.com> wrote:

Anil,

the challenge is that OIDC is a rather large set of specifications, and to = my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about bou= tique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitraril= y selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token t= o OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to descr= ibe some minimal subset which we could all reasonably implement. I was told= that  the specification was "locked down" and fully debugge= d and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - = the hybrid flow - that had been added at the last minute. I had never heard= of the hybrid flow in the OAuth context - have you? So now you have an eve= n larger specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely= a minimal extension to OAuth flows to support an authenticator token. = ; In my experience, this is the subset that most customers and implementors= are looking for.


- prateek




 

Tony/Phil,
  any chance you can have this work done at OIDC?

The reason is that it is commonly understood/accepted now that OAuth provid= es authorization related specs while authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:

I agree with Phil on this one, there ar= e implementations of this already and much interest

 

From: OAuth [mailto:oauth-bounces@ietf.or= g] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

On the contrary. I and others are interested. 

 

We are waiting for the charter to pick up the work. 

 

Regardless there will be a new draft shortly. 


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:=

I would object to 'OAuth Authentication' being picked up by the WG as a = work item. The starting point draft has expired and it hasn't really been d= iscusses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even th= en. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Posses= sion for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relati= vity simple security enhancement which addresses problems currently being e= ncountered in deployments of native clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.ne= t> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

3D"Ping

Brian Campbell
Portfolio Architect

@

bcampbell@pingidentity.com

3D"phone"

+1 720.317.2061=

Connect with us…<= /p>

3D"twitter= 3D"youtube= 3D"Linke== 3D"Faceb== 3D"== 3D== 3D"fli== 3D"rss=

3D"Register

 

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



_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth




_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth

 


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

 

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

 




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

 

 

 

 

 

 

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

 

--_000_bd52fcf7cac04f91922f7c4b8ecabaf8BLUPR03MB309namprd03pro_-- From nobody Thu May 15 00:12:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111001A020F for ; Thu, 15 May 2014 00:12:55 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Vb7eBUji9nHg for ; Thu, 15 May 2014 00:12:51 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B0B1A01F3 for ; Thu, 15 May 2014 00:12:50 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB310.namprd03.prod.outlook.com (10.141.48.25) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 15 May 2014 07:12:42 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0949.001; Thu, 15 May 2014 07:12:42 +0000 From: Anthony Nadalin To: John Bradley , Brian Campbell Thread-Topic: [OAUTH-WG] OAuth Milestone Update and Rechartering Thread-Index: AQHPawEbu8OzlywPcU+RkLqz+fSkNptACOgAgABdhACAAN2OYA== Date: Thu, 15 May 2014 07:12:41 +0000 Message-ID: References: <536BF140.5070106@gmx.net> <60BC637A-FD8D-4C92-A94C-93F89E868CB9@ve7jtb.com> In-Reply-To: <60BC637A-FD8D-4C92-A94C-93F89E868CB9@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.110.65.1] x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(53754006)(377454003)(24454002)(189002)(199002)(19617315010)(76482001)(86612001)(86362001)(19618635001)(77982001)(92566001)(83072002)(85852003)(33646001)(99396002)(101416001)(16236675002)(99286001)(19625215002)(74316001)(81342001)(46102001)(81542001)(74502001)(2656002)(74662001)(87936001)(31966008)(19580405001)(19580395003)(19300405004)(19273905006)(79102001)(64706001)(4396001)(80022001)(76576001)(54356999)(15198665003)(18206015023)(66066001)(50986999)(15975445006)(83322001)(15395725003)(77096999)(76176999)(19609705001)(21056001)(15202345003)(20776003)(42262001)(9984715005)(24736002)(19621445023); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB310; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; Content-Type: multipart/alternative; boundary="_000_abfbbdc896ee4464b3f6453823fb3755BLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/64glGE9YHU44To6OpOzjXMMpXh0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 07:12:55 -0000 --_000_abfbbdc896ee4464b3f6453823fb3755BLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hlcmUgaXMgdGhlIGNvbmZ1c2lvbiA/DQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gQnJhZGxleQ0KU2VudDogV2VkbmVzZGF5 LCBNYXkgMTQsIDIwMTQgMTA6NTkgQU0NClRvOiBCcmlhbiBDYW1wYmVsbA0KQ2M6IG9hdXRoQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCBNaWxlc3RvbmUgVXBkYXRlIGFu ZCBSZWNoYXJ0ZXJpbmcNCg0KSSBrbm93IGEgbnVtYmVyIG9mIHBlb3BsZSBpbXBsZW1lbnRpbmcN Cg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC10Y3Nl LTAzDQoNCkhhdmluZyBpdCBvbiBhIFJGQyB0cmFjayBtYXkgbWFrZSBzZW5zZS4NCg0KSSByZW1h aW4gdG8gYmUgY29udmluY2VkIHRoYXQgYTRjIGFkcyBhbnl0aGluZyBvdGhlciB0aGFuIGNvbmZ1 c2lvbi4NCg0KSWYgdGhlIFdHIHdhbnRzIHRvIHRha2UgaXQgdXAgaXQgc2hvdWxkIGJlIGFsaWdu ZWQgd2l0aCBDb25uZWN0LiAgSSB0aGluayB0aGVyZSBhcmUgbW9yZSBpbXBvcnRhbnQgdGhpbmdz IHRvIHNwZW5kIHRpbWUgb24uDQoNCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpPbiBNYXkgMTQs IDIwMTQsIGF0IDI6MjQgUE0sIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5 LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToNCkkgd291bGQg b2JqZWN0IHRvICdPQXV0aCBBdXRoZW50aWNhdGlvbicgYmVpbmcgcGlja2VkIHVwIGJ5IHRoZSBX RyBhcyBhIHdvcmsgaXRlbS4gVGhlIHN0YXJ0aW5nIHBvaW50IGRyYWZ0IGhhcyBleHBpcmVkIGFu ZCBpdCBoYXNuJ3QgcmVhbGx5IGJlZW4gZGlzY3Vzc2VzIHNpbmNlIEJlcmxpbiBuZWFybHkgYSB5 ZWFyIGFnby4gIEFzIEkgcmVjYWxsLCB0aGVyZSB3YXMgb25seSB2ZXJ5IGxpbWl0ZWQgaW50ZXJl c3QgaW4gaXQgZXZlbiB0aGVuLiBJIGFsc28gZG9uJ3QgYmVsaWV2ZSBpdCBmaXRzIHdlbGwgd2l0 aCB0aGUgV0cgY2hhcnRlci4NCg0KSSB3b3VsZCBzdWdnZXN0IHRoZSBXRyBjb25zaWRlciBwaWNr aW5nIHVwICdPQXV0aCBTeW1tZXRyaWMgUHJvb2Ygb2YgUG9zc2Vzc2lvbiBmb3IgQ29kZSBFeHRl bnNpb24nIGZvciB3aGljaCB0aGVyZSBpcyBhbiBleGNlbGxlbnQgc3RhcnRpbmcgcG9pbnQgb2Yg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtdGNzZS0wMyAt IGl0J3MgYSByZWxhdGl2aXR5IHNpbXBsZSBzZWN1cml0eSBlbmhhbmNlbWVudCB3aGljaCBhZGRy ZXNzZXMgcHJvYmxlbXMgY3VycmVudGx5IGJlaW5nIGVuY291bnRlcmVkIGluIGRlcGxveW1lbnRz IG9mIG5hdGl2ZSBjbGllbnRzLg0KDQoNCk9uIFRodSwgTWF5IDgsIDIwMTQgYXQgMzowNCBQTSwg SGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8bWFpbHRvOmhhbm5l cy50c2Nob2ZlbmlnQGdteC5uZXQ+PiB3cm90ZToNCkhpIGFsbCwNCg0KeW91IG1pZ2h0IGhhdmUg c2VlbiB0aGF0IHdlIHB1c2hlZCB0aGUgYXNzZXJ0aW9uIGRvY3VtZW50cyBhbmQgdGhlIEpXVA0K ZG9jdW1lbnRzIHRvIHRoZSBJRVNHIHRvZGF5LiBXZSBoYXZlIGFsc28gdXBkYXRlZCB0aGUgbWls ZXN0b25lcyBvbiB0aGUNCk9BdXRoIFdHIHBhZ2UuDQoNClRoaXMgbWVhbnMgdGhhdCB3ZSBjYW4g cGxhbiB0byBwaWNrIHVwIG5ldyB3b3JrIGluIHRoZSBncm91cC4NCldlIGhhdmUgc2VudCBhIHJl cXVlc3QgdG8gS2F0aGxlZW4gdG8gY2hhbmdlIHRoZSBtaWxlc3RvbmUgZm9yIHRoZSBPQXV0aA0K c2VjdXJpdHkgbWVjaGFuaXNtcyB0byB1c2UgdGhlIHByb29mLW9mLXBvc3Nlc3Npb24gdGVybWlu b2xvZ3kuDQoNCldlIGFsc28gZXhwZWN0IGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUgZHluYW1p YyBjbGllbnQgcmVnaXN0cmF0aW9uDQpzcGVjIGluY29ycG9yYXRpbmcgbGFzdCBjYWxsIGZlZWRi YWNrIHdpdGhpbiBhYm91dCAyIHdlZWtzLg0KDQpXZSB3b3VsZCBsaWtlIHlvdSB0byB0aGluayBh Ym91dCBhZGRpbmcgdGhlIGZvbGxvd2luZyBtaWxlc3RvbmVzIHRvIHRoZQ0KY2hhcnRlciBhcyBw YXJ0IG9mIHRoZSByZS1jaGFydGVyaW5nIGVmZm9ydDoNCg0KLS0tLS0NCg0KTm92IDIwMTQgU3Vi bWl0ICdUb2tlbiBpbnRyb3NwZWN0aW9uJyB0byB0aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBh cyBhDQpQcm9wb3NlZCBTdGFuZGFyZA0KU3RhcnRpbmcgcG9pbnQ6IDxkcmFmdC1yaWNoZXItb2F1 dGgtaW50cm9zcGVjdGlvbi0wND4NCg0KSmFuIDIwMTUgU3VibWl0ICdPQXV0aCBBdXRoZW50aWNh dGlvbicgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMNCmEgUHJvcG9zZWQgU3RhbmRh cmQNClN0YXJ0aW5nIHBvaW50OiA8ZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wMT4NCg0K SmFuIDIwMTUgU3VibWl0ICdUb2tlbiBFeGNoYW5nZScgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVy YXRpb24gYXMgYQ0KUHJvcG9zZWQgU3RhbmRhcmQNClN0YXJ0aW5nIHBvaW50OiA8ZHJhZnQtam9u ZXMtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDA+DQoNCi0tLS0tDQoNCldlIGFsc28gdXBkYXRlZCB0 aGUgY2hhcnRlciB0ZXh0IHRvIHJlZmxlY3QgdGhlIGN1cnJlbnQgc2l0dWF0aW9uLiBIZXJlDQpp cyB0aGUgcHJvcG9zZWQgdGV4dDoNCg0KLS0tLS0NCg0KQ2hhcnRlciBmb3IgV29ya2luZyBHcm91 cA0KDQoNClRoZSBXZWIgQXV0aG9yaXphdGlvbiAoT0F1dGgpIHByb3RvY29sIGFsbG93cyBhIHVz ZXIgdG8gZ3JhbnQgYQ0KdGhpcmQtcGFydHkgV2ViIHNpdGUgb3IgYXBwbGljYXRpb24gYWNjZXNz IHRvIHRoZSB1c2VyJ3MgcHJvdGVjdGVkDQpyZXNvdXJjZXMsIHdpdGhvdXQgbmVjZXNzYXJpbHkg cmV2ZWFsaW5nIHRoZWlyIGxvbmctdGVybSBjcmVkZW50aWFscywNCm9yIGV2ZW4gdGhlaXIgaWRl bnRpdHkuIEZvciBleGFtcGxlLCBhIHBob3RvLXNoYXJpbmcgc2l0ZSB0aGF0DQpzdXBwb3J0cyBP QXV0aCBjb3VsZCBhbGxvdyBpdHMgdXNlcnMgdG8gdXNlIGEgdGhpcmQtcGFydHkgcHJpbnRpbmcg V2ViDQpzaXRlIHRvIHByaW50IHRoZWlyIHByaXZhdGUgcGljdHVyZXMsIHdpdGhvdXQgYWxsb3dp bmcgdGhlIHByaW50aW5nDQpzaXRlIHRvIGdhaW4gZnVsbCBjb250cm9sIG9mIHRoZSB1c2VyJ3Mg YWNjb3VudCBhbmQgd2l0aG91dCBoYXZpbmcgdGhlDQp1c2VyIHNoYXJlIGhpcyBvciBoZXIgcGhv dG8tc2hhcmluZyBzaXRlcycgbG9uZy10ZXJtIGNyZWRlbnRpYWwgd2l0aA0KdGhlIHByaW50aW5n IHNpdGUuDQoNClRoZSBPQXV0aCAyLjAgcHJvdG9jb2wgc3VpdGUgZW5jb21wYXNzZXMNCg0KKiBh IHByb3RvY29sIGZvciBvYnRhaW5pbmcgYWNjZXNzIHRva2VucyBmcm9tIGFuIGF1dGhvcml6YXRp b24NCnNlcnZlciB3aXRoIHRoZSByZXNvdXJjZSBvd25lcidzIGNvbnNlbnQsDQoqIHByb3RvY29s cyBmb3IgcHJlc2VudGluZyB0aGVzZSBhY2Nlc3MgdG9rZW5zIHRvIHJlc291cmNlIHNlcnZlcg0K Zm9yIGFjY2VzcyB0byBhIHByb3RlY3RlZCByZXNvdXJjZSwNCiogZ3VpZGFuY2UgZm9yIHNlY3Vy ZWx5IHVzaW5nIE9BdXRoIDIuMCwNCiogdGhlIGFiaWxpdHkgdG8gcmV2b2tlIGFjY2VzcyB0b2tl bnMsDQoqIHN0YW5kYXJkaXplZCBmb3JtYXQgZm9yIHNlY3VyaXR5IHRva2VucyBlbmNvZGVkIGlu IGEgSlNPTiBmb3JtYXQNCiAgKEpTT04gV2ViIFRva2VuLCBKV1QpLA0KKiB3YXlzIG9mIHVzaW5n IGFzc2VydGlvbnMgd2l0aCBPQXV0aCwgYW5kDQoqIGEgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0 aW9uIHByb3RvY29sLg0KDQpUaGUgd29ya2luZyBncm91cCBhbHNvIGRldmVsb3BlZCBzZWN1cml0 eSBzY2hlbWVzIGZvciBwcmVzZW50aW5nDQphdXRob3JpemF0aW9uIHRva2VucyB0byBhY2Nlc3Mg YSBwcm90ZWN0ZWQgcmVzb3VyY2UuIFRoaXMgbGVkIHRvIHRoZQ0KcHVibGljYXRpb24gb2YgdGhl IGJlYXJlciB0b2tlbiwgYXMgd2VsbCBhcyB3b3JrIHRoYXQgcmVtYWlucyB0byBiZQ0KY29tcGxl dGVkIG9uIHByb29mLW9mLXBvc3Nlc3Npb24gYW5kIHRva2VuIGV4Y2hhbmdlLg0KDQpUaGUgb25n b2luZyBzdGFuZGFyZGl6YXRpb24gZWZmb3J0IHdpdGhpbiB0aGUgT0F1dGggd29ya2luZyBncm91 cCB3aWxsDQpmb2N1cyBvbiBlbmhhbmNpbmcgaW50ZXJvcGVyYWJpbGl0eSBhbmQgZnVuY3Rpb25h bGl0eSBvZiBPQXV0aA0KZGVwbG95bWVudHMsIHN1Y2ggYXMgYSBzdGFuZGFyZCBmb3IgYSB0b2tl biBpbnRyb3NwZWN0aW9uIHNlcnZpY2UgYW5kDQpzdGFuZGFyZHMgZm9yIGFkZGl0aW9uYWwgc2Vj dXJpdHkgb2YgT0F1dGggcmVxdWVzdHMuDQoNCi0tLS0tDQoNCkZlZWRiYWNrIGFwcHJlY2lhdGVk Lg0KDQpDaWFvDQpIYW5uZXMgJiBEZXJlaw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQoNCg0KLS0NCltQaW5nIElkZW50aXR5IGxvZ29dPGh0dHBzOi8vd3d3 LnBpbmdpZGVudGl0eS5jb20vPg0KDQpCcmlhbiBDYW1wYmVsbA0KUG9ydGZvbGlvIEFyY2hpdGVj dA0KQA0KDQpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb20+DQoNCltwaG9uZV0NCg0KKzEgNzIwLjMxNy4yMDYxDQoNCkNvbm5lY3Qgd2l0 aCB1c+KApg0KDQpbdHdpdHRlciBsb2dvXTxodHRwczovL3R3aXR0ZXIuY29tL3BpbmdpZGVudGl0 eT5beW91dHViZSBsb2dvXTxodHRwczovL3d3dy55b3V0dWJlLmNvbS91c2VyL1BpbmdJZGVudGl0 eVRWPltMaW5rZWRJbiBsb2dvXTxodHRwczovL3d3dy5saW5rZWRpbi5jb20vY29tcGFueS8yMTg3 MD5bRmFjZWJvb2sgbG9nb108aHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL3BpbmdpZGVudGl0eXBh Z2U+W0dvb2dsZSsgbG9nb108aHR0cHM6Ly9wbHVzLmdvb2dsZS5jb20vdS8wLzExNDI2Njk3Nzcz OTM5NzcwODU0MD5bc2xpZGVzaGFyZSBsb2dvXTxodHRwOi8vd3d3LnNsaWRlc2hhcmUubmV0L1Bp bmdJZGVudGl0eT5bZmxpcGJvYXJkIGxvZ29dPGh0dHA6Ly9mbGlwLml0L3ZqQkY3Pltyc3MgZmVl ZCBpY29uXTxodHRwczovL3d3dy5waW5naWRlbnRpdHkuY29tL2Jsb2dzLz4NCg0KDQpbUmVnaXN0 ZXIgZm9yIENsb3VkIElkZW50aXR5IFN1bW1pdCAyMDE0IHwgTW9kZXJuIElkZW50aXR5IFJldm9s dXRpb24gfCAxOeKAkzIzIEp1bHksIDIwMTQgfCBNb250ZXJleSwgQ0FdPGh0dHBzOi8vd3d3LmNs b3VkaWRlbnRpdHlzdW1taXQuY29tLz4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxt YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQo= --_000_abfbbdc896ee4464b3f6453823fb3755BLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGVyZSBpcyB0 aGUgY29uZnVzaW9uID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl aGFsZiBPZiA8L2I+Sm9obiBCcmFkbGV5PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWF5 IDE0LCAyMDE0IDEwOjU5IEFNPGJyPg0KPGI+VG86PC9iPiBCcmlhbiBDYW1wYmVsbDxicj4NCjxi PkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X R10gT0F1dGggTWlsZXN0b25lIFVwZGF0ZSBhbmQgUmVjaGFydGVyaW5nPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkga25vdyBhIG51bWJlciBv ZiBwZW9wbGUgaW1wbGVtZW50aW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXNha2ltdXJhLW9hdXRoLXRjc2UtMDMiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC10Y3NlLTAzPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhdmlu ZyBpdCBvbiBhIFJGQyB0cmFjayBtYXkgbWFrZSBzZW5zZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSByZW1haW4gdG8gYmUgY29u dmluY2VkIHRoYXQgYTRjIGFkcyBhbnl0aGluZyBvdGhlciB0aGFuIGNvbmZ1c2lvbi4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYg dGhlIFdHIHdhbnRzIHRvIHRha2UgaXQgdXAgaXQgc2hvdWxkIGJlIGFsaWduZWQgd2l0aCBDb25u ZWN0LiAmbmJzcDtJIHRoaW5rIHRoZXJlIGFyZSBtb3JlIGltcG9ydGFudCB0aGluZ3MgdG8gc3Bl bmQgdGltZSBvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KU2VudCBmcm9tIG15IGlQaG9uZTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQpPbiBNYXkgMTQsIDIwMTQsIGF0IDI6MjQgUE0sIEJyaWFuIENhbXBiZWxs ICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iPmJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPkkgd291bGQgb2JqZWN0IHRvICdPQXV0aCBBdXRoZW50aWNhdGlvbicgYmVpbmcg cGlja2VkIHVwIGJ5IHRoZSBXRyBhcyBhIHdvcmsgaXRlbS4gVGhlIHN0YXJ0aW5nIHBvaW50IGRy YWZ0IGhhcyBleHBpcmVkIGFuZCBpdCBoYXNuJ3QgcmVhbGx5IGJlZW4gZGlzY3Vzc2VzIHNpbmNl IEJlcmxpbiBuZWFybHkgYSB5ZWFyIGFnby4mbmJzcDsgQXMgSSByZWNhbGwsIHRoZXJlDQogd2Fz IG9ubHkgdmVyeSBsaW1pdGVkIGludGVyZXN0IGluIGl0IGV2ZW4gdGhlbi4gSSBhbHNvIGRvbid0 IGJlbGlldmUgaXQgZml0cyB3ZWxsIHdpdGggdGhlIFdHIGNoYXJ0ZXIuPGJyPg0KPGJyPg0KSSB3 b3VsZCBzdWdnZXN0IHRoZSBXRyBjb25zaWRlciBwaWNraW5nIHVwICdPQXV0aCBTeW1tZXRyaWMg UHJvb2Ygb2YgUG9zc2Vzc2lvbiBmb3IgQ29kZSBFeHRlbnNpb24nIGZvciB3aGljaCB0aGVyZSBp cyBhbiBleGNlbGxlbnQgc3RhcnRpbmcgcG9pbnQgb2YNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLXRjc2UtMDMiIHRhcmdldD0iX2JsYW5r Ij4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLXRjc2Ut MDM8L2E+IC0gaXQncyBhIHJlbGF0aXZpdHkgc2ltcGxlIHNlY3VyaXR5IGVuaGFuY2VtZW50IHdo aWNoIGFkZHJlc3NlcyBwcm9ibGVtcyBjdXJyZW50bHkgYmVpbmcgZW5jb3VudGVyZWQgaW4gZGVw bG95bWVudHMgb2YgbmF0aXZlIGNsaWVudHMuJm5ic3A7DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gVGh1LCBNYXkgOCwgMjAxNCBhdCAzOjA0IFBNLCBIYW5uZXMgVHNjaG9mZW5p ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiIHRhcmdldD0i X2JsYW5rIj5oYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij5IaSBhbGwsPGJyPg0KPGJyPg0KeW91IG1pZ2h0IGhhdmUgc2VlbiB0aGF0 IHdlIHB1c2hlZCB0aGUgYXNzZXJ0aW9uIGRvY3VtZW50cyBhbmQgdGhlIEpXVDxicj4NCmRvY3Vt ZW50cyB0byB0aGUgSUVTRyB0b2RheS4gV2UgaGF2ZSBhbHNvIHVwZGF0ZWQgdGhlIG1pbGVzdG9u ZXMgb24gdGhlPGJyPg0KT0F1dGggV0cgcGFnZS48YnI+DQo8YnI+DQpUaGlzIG1lYW5zIHRoYXQg d2UgY2FuIHBsYW4gdG8gcGljayB1cCBuZXcgd29yayBpbiB0aGUgZ3JvdXAuPGJyPg0KV2UgaGF2 ZSBzZW50IGEgcmVxdWVzdCB0byBLYXRobGVlbiB0byBjaGFuZ2UgdGhlIG1pbGVzdG9uZSBmb3Ig dGhlIE9BdXRoPGJyPg0Kc2VjdXJpdHkgbWVjaGFuaXNtcyB0byB1c2UgdGhlIHByb29mLW9mLXBv c3Nlc3Npb24gdGVybWlub2xvZ3kuPGJyPg0KPGJyPg0KV2UgYWxzbyBleHBlY3QgYW4gdXBkYXRl ZCB2ZXJzaW9uIG9mIHRoZSBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb248YnI+DQpzcGVjIGlu Y29ycG9yYXRpbmcgbGFzdCBjYWxsIGZlZWRiYWNrIHdpdGhpbiBhYm91dCAyIHdlZWtzLjxicj4N Cjxicj4NCldlIHdvdWxkIGxpa2UgeW91IHRvIHRoaW5rIGFib3V0IGFkZGluZyB0aGUgZm9sbG93 aW5nIG1pbGVzdG9uZXMgdG8gdGhlPGJyPg0KY2hhcnRlciBhcyBwYXJ0IG9mIHRoZSByZS1jaGFy dGVyaW5nIGVmZm9ydDo8YnI+DQo8YnI+DQotLS0tLTxicj4NCjxicj4NCk5vdiAyMDE0IFN1Ym1p dCAnVG9rZW4gaW50cm9zcGVjdGlvbicgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMg YTxicj4NClByb3Bvc2VkIFN0YW5kYXJkPGJyPg0KU3RhcnRpbmcgcG9pbnQ6ICZsdDtkcmFmdC1y aWNoZXItb2F1dGgtaW50cm9zcGVjdGlvbi0wNCZndDs8YnI+DQo8YnI+DQpKYW4gMjAxNSBTdWJt aXQgJ09BdXRoIEF1dGhlbnRpY2F0aW9uJyB0byB0aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBh czxicj4NCmEgUHJvcG9zZWQgU3RhbmRhcmQ8YnI+DQpTdGFydGluZyBwb2ludDogJmx0O2RyYWZ0 LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDEmZ3Q7PGJyPg0KPGJyPg0KSmFuIDIwMTUgU3VibWl0 ICdUb2tlbiBFeGNoYW5nZScgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMgYTxicj4N ClByb3Bvc2VkIFN0YW5kYXJkPGJyPg0KU3RhcnRpbmcgcG9pbnQ6ICZsdDtkcmFmdC1qb25lcy1v YXV0aC10b2tlbi1leGNoYW5nZS0wMCZndDs8YnI+DQo8YnI+DQotLS0tLTxicj4NCjxicj4NCldl IGFsc28gdXBkYXRlZCB0aGUgY2hhcnRlciB0ZXh0IHRvIHJlZmxlY3QgdGhlIGN1cnJlbnQgc2l0 dWF0aW9uLiBIZXJlPGJyPg0KaXMgdGhlIHByb3Bvc2VkIHRleHQ6PGJyPg0KPGJyPg0KLS0tLS08 YnI+DQo8YnI+DQpDaGFydGVyIGZvciBXb3JraW5nIEdyb3VwPGJyPg0KPGJyPg0KPGJyPg0KVGhl IFdlYiBBdXRob3JpemF0aW9uIChPQXV0aCkgcHJvdG9jb2wgYWxsb3dzIGEgdXNlciB0byBncmFu dCBhPGJyPg0KdGhpcmQtcGFydHkgV2ViIHNpdGUgb3IgYXBwbGljYXRpb24gYWNjZXNzIHRvIHRo ZSB1c2VyJ3MgcHJvdGVjdGVkPGJyPg0KcmVzb3VyY2VzLCB3aXRob3V0IG5lY2Vzc2FyaWx5IHJl dmVhbGluZyB0aGVpciBsb25nLXRlcm0gY3JlZGVudGlhbHMsPGJyPg0Kb3IgZXZlbiB0aGVpciBp ZGVudGl0eS4gRm9yIGV4YW1wbGUsIGEgcGhvdG8tc2hhcmluZyBzaXRlIHRoYXQ8YnI+DQpzdXBw b3J0cyBPQXV0aCBjb3VsZCBhbGxvdyBpdHMgdXNlcnMgdG8gdXNlIGEgdGhpcmQtcGFydHkgcHJp bnRpbmcgV2ViPGJyPg0Kc2l0ZSB0byBwcmludCB0aGVpciBwcml2YXRlIHBpY3R1cmVzLCB3aXRo b3V0IGFsbG93aW5nIHRoZSBwcmludGluZzxicj4NCnNpdGUgdG8gZ2FpbiBmdWxsIGNvbnRyb2wg b2YgdGhlIHVzZXIncyBhY2NvdW50IGFuZCB3aXRob3V0IGhhdmluZyB0aGU8YnI+DQp1c2VyIHNo YXJlIGhpcyBvciBoZXIgcGhvdG8tc2hhcmluZyBzaXRlcycgbG9uZy10ZXJtIGNyZWRlbnRpYWwg d2l0aDxicj4NCnRoZSBwcmludGluZyBzaXRlLjxicj4NCjxicj4NClRoZSBPQXV0aCAyLjAgcHJv dG9jb2wgc3VpdGUgZW5jb21wYXNzZXM8YnI+DQo8YnI+DQoqIGEgcHJvdG9jb2wgZm9yIG9idGFp bmluZyBhY2Nlc3MgdG9rZW5zIGZyb20gYW4gYXV0aG9yaXphdGlvbjxicj4NCnNlcnZlciB3aXRo IHRoZSByZXNvdXJjZSBvd25lcidzIGNvbnNlbnQsPGJyPg0KKiBwcm90b2NvbHMgZm9yIHByZXNl bnRpbmcgdGhlc2UgYWNjZXNzIHRva2VucyB0byByZXNvdXJjZSBzZXJ2ZXI8YnI+DQpmb3IgYWNj ZXNzIHRvIGEgcHJvdGVjdGVkIHJlc291cmNlLDxicj4NCiogZ3VpZGFuY2UgZm9yIHNlY3VyZWx5 IHVzaW5nIE9BdXRoIDIuMCw8YnI+DQoqIHRoZSBhYmlsaXR5IHRvIHJldm9rZSBhY2Nlc3MgdG9r ZW5zLDxicj4NCiogc3RhbmRhcmRpemVkIGZvcm1hdCBmb3Igc2VjdXJpdHkgdG9rZW5zIGVuY29k ZWQgaW4gYSBKU09OIGZvcm1hdDxicj4NCiZuYnNwOyAoSlNPTiBXZWIgVG9rZW4sIEpXVCksPGJy Pg0KKiB3YXlzIG9mIHVzaW5nIGFzc2VydGlvbnMgd2l0aCBPQXV0aCwgYW5kPGJyPg0KKiBhIGR5 bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiBwcm90b2NvbC48YnI+DQo8YnI+DQpUaGUgd29ya2lu ZyBncm91cCBhbHNvIGRldmVsb3BlZCBzZWN1cml0eSBzY2hlbWVzIGZvciBwcmVzZW50aW5nPGJy Pg0KYXV0aG9yaXphdGlvbiB0b2tlbnMgdG8gYWNjZXNzIGEgcHJvdGVjdGVkIHJlc291cmNlLiBU aGlzIGxlZCB0byB0aGU8YnI+DQpwdWJsaWNhdGlvbiBvZiB0aGUgYmVhcmVyIHRva2VuLCBhcyB3 ZWxsIGFzIHdvcmsgdGhhdCByZW1haW5zIHRvIGJlPGJyPg0KY29tcGxldGVkIG9uIHByb29mLW9m LXBvc3Nlc3Npb24gYW5kIHRva2VuIGV4Y2hhbmdlLjxicj4NCjxicj4NClRoZSBvbmdvaW5nIHN0 YW5kYXJkaXphdGlvbiBlZmZvcnQgd2l0aGluIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwIHdpbGw8 YnI+DQpmb2N1cyBvbiBlbmhhbmNpbmcgaW50ZXJvcGVyYWJpbGl0eSBhbmQgZnVuY3Rpb25hbGl0 eSBvZiBPQXV0aDxicj4NCmRlcGxveW1lbnRzLCBzdWNoIGFzIGEgc3RhbmRhcmQgZm9yIGEgdG9r ZW4gaW50cm9zcGVjdGlvbiBzZXJ2aWNlIGFuZDxicj4NCnN0YW5kYXJkcyBmb3IgYWRkaXRpb25h bCBzZWN1cml0eSBvZiBPQXV0aCByZXF1ZXN0cy48YnI+DQo8YnI+DQotLS0tLTxicj4NCjxicj4N CkZlZWRiYWNrIGFwcHJlY2lhdGVkLjxicj4NCjxicj4NCkNpYW88YnI+DQpIYW5uZXMgJmFtcDsg RGVyZWs8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxiciBjbGVhcj0iYWxsIj4NCjxicj4NCi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5n PSIwIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjU5LjI1cHQiPg0KPHRkIHdpZHRoPSI3 NSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo1Ni4yNXB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQg Ljc1cHQgLjc1cHQ7aGVpZ2h0OjU5LjI1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJl Zj0iaHR0cHM6Ly93d3cucGluZ2lkZW50aXR5LmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kx MDI1IiBzcmM9Imh0dHA6Ly80LnBpbmdpZGVudGl0eS5jb20vcnMvcGluZ2lkZW50aXR5L2ltYWdl cy9FWFBfUElDX3NxdWFyZV9sb2dvX1JHQl93aXRoX2hhcmRfZHJvcC5wbmciIGFsdD0iUGluZyBJ ZGVudGl0eSBsb2dvIj48L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxp Z249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgNy41cHQ7aGVpZ2h0OjU5 LjI1cHQiPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo1LjI1cHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojRTYxRDNDIj5Ccmlh biBDYW1wYmVsbDwvc3Bhbj48L2I+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+UG9ydGZvbGlvIEFyY2hpdGVjdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0i MCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1yaWdodDpz b2xpZCAjRTYxRDNDIDEuMHB0O3BhZGRpbmc6MGluIDMuNzVwdCAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojRTYxRDNDIj5APC9zcGFuPjwvYj48bzpw PjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMi4yNXB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt cmlnaHQ6c29saWQgI0U2M0MxRCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIi PjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDI2IiBzcmM9Imh0dHA6Ly80LnBpbmdpZGVu dGl0eS5jb20vcnMvcGluZ2lkZW50aXR5L2ltYWdlcy9FWFBfcGhvbmVfZ2x5cGguZ2lmIiBhbHQ9 InBob25lIj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBp biAwaW4gMi4yNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiYjNDM7MSA3MjAuMzE3LjIwNjE8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBjb2xzcGFuPSIyIiBzdHlsZT0icGFkZGluZzox MS4yNXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk5OTk5OSI+Q29ubmVjdCB3aXRoIHVz4oCmPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgY29sc3Bhbj0iMiIgc3R5 bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9waW5naWRlbnRpdHkiIHRhcmdldD0iX2Js YW5rIiB0aXRsZT0iUGluZyBvbiBUd2l0dGVyIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9u Om5vbmUiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDI3IiBzcmM9Imh0dHA6Ly80LnBp bmdpZGVudGl0eS5jb20vcnMvcGluZ2lkZW50aXR5L2ltYWdlcy90d2l0dGVyLmdpZiIgYWx0PSJ0 d2l0dGVyIGxvZ28iPjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cHM6Ly93d3cueW91dHViZS5jb20v dXNlci9QaW5nSWRlbnRpdHlUViIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSJQaW5nIG9uIFlvdVR1 YmUiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIGlk PSJfeDAwMDBfaTEwMjgiIHNyYz0iaHR0cDovLzQucGluZ2lkZW50aXR5LmNvbS9ycy9waW5naWRl bnRpdHkvaW1hZ2VzL3lvdXR1YmUuZ2lmIiBhbHQ9InlvdXR1YmUgbG9nbyI+PC9zcGFuPjwvYT48 YSBocmVmPSJodHRwczovL3d3dy5saW5rZWRpbi5jb20vY29tcGFueS8yMTg3MCIgdGFyZ2V0PSJf YmxhbmsiIHRpdGxlPSJQaW5nIG9uIExpbmtlZEluIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0 aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDI5IiBzcmM9Imh0dHA6Ly80 LnBpbmdpZGVudGl0eS5jb20vcnMvcGluZ2lkZW50aXR5L2ltYWdlcy9saW5rZWRpbi5naWYiIGFs dD0iTGlua2VkSW4gbG9nbyI+PC9zcGFuPjwvYT48YSBocmVmPSJodHRwczovL3d3dy5mYWNlYm9v ay5jb20vcGluZ2lkZW50aXR5cGFnZSIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSJQaW5nIG9uIEZh Y2Vib29rIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIw IiBpZD0iX3gwMDAwX2kxMDMwIiBzcmM9Imh0dHA6Ly80LnBpbmdpZGVudGl0eS5jb20vcnMvcGlu Z2lkZW50aXR5L2ltYWdlcy9mYWNlYm9vay5naWYiIGFsdD0iRmFjZWJvb2sgbG9nbyI+PC9zcGFu PjwvYT48YSBocmVmPSJodHRwczovL3BsdXMuZ29vZ2xlLmNvbS91LzAvMTE0MjY2OTc3NzM5Mzk3 NzA4NTQwIiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IlBpbmcgb24gR29vZ2xlJiM0MzsiPjxzcGFu IHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIGlkPSJfeDAwMDBf aTEwMzEiIHNyYz0iaHR0cDovLzQucGluZ2lkZW50aXR5LmNvbS9ycy9waW5naWRlbnRpdHkvaW1h Z2VzL2dvb2dsZSUyQi5naWYiIGFsdD0iR29vZ2xlJiM0MzsgbG9nbyI+PC9zcGFuPjwvYT48YSBo cmVmPSJodHRwOi8vd3d3LnNsaWRlc2hhcmUubmV0L1BpbmdJZGVudGl0eSIgdGFyZ2V0PSJfYmxh bmsiIHRpdGxlPSJQaW5nIG9uIFNsaWRlU2hhcmUiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRp b246bm9uZSI+PGltZyBib3JkZXI9IjAiIGlkPSJfeDAwMDBfaTEwMzIiIHNyYz0iaHR0cDovLzQu cGluZ2lkZW50aXR5LmNvbS9ycy9waW5naWRlbnRpdHkvaW1hZ2VzL3NsaWRlc2hhcmUuZ2lmIiBh bHQ9InNsaWRlc2hhcmUgbG9nbyI+PC9zcGFuPjwvYT48YSBocmVmPSJodHRwOi8vZmxpcC5pdC92 akJGNyIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSJQaW5nIG9uIEZsaXBib2FyZCI+PHNwYW4gc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAz MyIgc3JjPSJodHRwOi8vNC5waW5naWRlbnRpdHkuY29tL3JzL3BpbmdpZGVudGl0eS9pbWFnZXMv ZmxpcGJvYXJkLmdpZiIgYWx0PSJmbGlwYm9hcmQgbG9nbyI+PC9zcGFuPjwvYT48YSBocmVmPSJo dHRwczovL3d3dy5waW5naWRlbnRpdHkuY29tL2Jsb2dzLyIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxl PSJQaW5nIGJsb2dzIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9y ZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDM0IiBzcmM9Imh0dHA6Ly80LnBpbmdpZGVudGl0eS5jb20v cnMvcGluZ2lkZW50aXR5L2ltYWdlcy9yc3MuZ2lmIiBhbHQ9InJzcyBmZWVkIGljb24iPjwvc3Bh bj48L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0K PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvZGl2Pg0KPHRhYmxlIGNsYXNzPSJN c29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIxIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAi IHdpZHRoPSIzMTUiIHN0eWxlPSJ3aWR0aDoyMzYuMjVwdDtib3JkZXItY29sbGFwc2U6Y29sbGFw c2U7Ym9yZGVyOm5vbmUiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6NjAuNzVwdCI+DQo8 dGQgd2lkdGg9IjE3MiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMjkuMHB0O2JvcmRlcjpu b25lO3BhZGRpbmc6MTEuMjVwdCAxMS4yNXB0IDBpbiAxMS4yNXB0O2hlaWdodDo2MC43NXB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmNsb3VkaWRlbnRpdHlz dW1taXQuY29tLyIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSJSZWdpc3RlciBmb3IgQ2xvdWQgSWRl bnRpdHkgU3VtbWl0IDIwMTQgfCBNb2Rlcm4gSWRlbnRpdHkgUmV2b2x1dGlvbiB8IDE54oCTMjMg SnVseSwgMjAxNCB8IE1vbnRlcmV5LCBDQSI+PHNwYW4gc3R5bGU9ImNvbG9yOiNDQ0NDQ0M7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDM1IiBzcmM9 Imh0dHA6Ly80LnBpbmdpZGVudGl0eS5jb20vcnMvcGluZ2lkZW50aXR5L2ltYWdlcy9FWFBfQ0lT XzIwMTQuZ2lmIiBhbHQ9IlJlZ2lzdGVyIGZvciBDbG91ZCBJZGVudGl0eSBTdW1taXQgMjAxNCB8 IE1vZGVybiBJZGVudGl0eSBSZXZvbHV0aW9uIHwgMTnigJMyMyBKdWx5LCAyMDE0IHwgTW9udGVy ZXksIENBIj48L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5 Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_abfbbdc896ee4464b3f6453823fb3755BLUPR03MB309namprd03pro_-- From nobody Thu May 15 01:23:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A051A0413 for ; Thu, 15 May 2014 01:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 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, T_REMOTE_IMAGE=0.01] autolearn=ham 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 E1aDGqoAzTu7 for ; Thu, 15 May 2014 01:23:17 -0700 (PDT) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587C41A0407 for ; Thu, 15 May 2014 01:23:15 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id e53so369240eek.25 for ; Thu, 15 May 2014 01:23:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=syRx3Jcty7DZR3D5C454vvfXHOsIaZGlocbYTh6uq3I=; b=OawT+qts5MLtUAjuCNJshkDQA2UwiWO8bkSzSFvs0/WBBupowSUejRrNv39xGiJP/U FIPEjRpQW6gY6CnEbOGiUkVjvCVwp4luuttqjzCnijYzTPjqjj6WQKUmk+p4uMe06Bri 7orgmrKjM91qFIo/dlW9Yfg74n9XwulWrQdumblBjAyb4jZ4BFJMy4KrUgHo++3HEmwB C+oulow2MPpbtf2BB5ITOBvKo+6WeiY23LbwaRhJM+RRWdC8nPCDkbguqFOvbvfASQ4D fMkaXhLDxipr3/YBxB0wv6REI72yrvCoEpt1/BYYxba0ahoZCnRib5tVEEvmpU0bs2DF A/nQ== X-Gm-Message-State: ALoCoQk0una2kxoQtFLQ+0v7RShXdp6ed1jyN7ECPDHcspG2BFNoh6kiOTNfBUQlDOo56xM6qByC X-Received: by 10.14.110.2 with SMTP id t2mr860101eeg.108.1400142187995; Thu, 15 May 2014 01:23:07 -0700 (PDT) Received: from [10.105.255.214] (vlan105-gw1.ush2.tnib.de. [86.110.65.1]) by mx.google.com with ESMTPSA id a45sm10900638eez.2.2014.05.15.01.22.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 May 2014 01:23:06 -0700 (PDT) References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> <537416A9.5060701@mit.edu> <53741B2F.4040506@mit.edu> <1F00EAF0-CC8F-469F-84F3-50C534325360@oracle.com> <51BD7E1D-5C8D-4B6F-8F3C-64137CBDA0DA@oracle.com> <53741F27.4010100@mit.edu> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8A6519DA-09D1-4334-864E-72B0F1E3B19A; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <1A0E5844-2A79-4BC2-A6E1-542D788641D4@ve7jtb.com> X-Mailer: iPhone Mail (11D201) From: John Bradley Date: Thu, 15 May 2014 10:22:57 +0200 To: Phil Hunt Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6zfV7hfEfpMFdFVMZSqZawUjHXM Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 08:23:24 -0000 --Apple-Mail-8A6519DA-09D1-4334-864E-72B0F1E3B19A Content-Type: multipart/alternative; boundary=Apple-Mail-04064FD3-B21B-437C-9417-3B5C20180AFF Content-Transfer-Encoding: 7bit --Apple-Mail-04064FD3-B21B-437C-9417-3B5C20180AFF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Phil, I recommend reading the specification.=20 Sent from my iPhone > On May 15, 2014, at 8:12 AM, Phil Hunt wrote: >=20 > Which flow is that? It certainly wasn't the one Justin pointed to.=20 >=20 > Phil >=20 >> On May 14, 2014, at 22:31, John Bradley wrote: >>=20 >> No. >>=20 >> OAuth requires that if you use the code response type, the token endpoint= must return an access token. >>=20 >> Connect dosen't require a user_info endpoint. >>=20 >> In the response_type "id_token" only a id_token is returned in the front= channel in a manner similar to SAML POST binding but fragment encoded by de= fault. >>=20 >> So there is a flow in Connect that doesn't deliver an access token. >>=20 >> I think this discussion is more about what changes you want to the core o= f OAuth. >>=20 >> Connect worked around the OAuth spec to be compatible with it. >>=20 >> Only the OAuth WG can change OAuth and that seems to be what you want. =20= >> a4c is a justification for making those changes. >>=20 >> We should probably focus on the core issue of what changes to RFC 6749 yo= u are after, to determine if the WG wants to change the charter. >>=20 >> I think focusing on a4c is a read herring. >>=20 >> John B. >>=20 >>> On May 15, 2014, at 6:55 AM, Phil Hunt wrote: >>>=20 >>> I think those are things to discuss if the authen is on the charter.=20 >>>=20 >>> So we have now clarified that the basic connect profile doesn't do just a= uthen and requires identity profile services.=20 >>>=20 >>> Phil >>>=20 >>>> On May 14, 2014, at 18:57, Justin Richer wrote: >>>>=20 >>>> Right, so instead of being able to use my authorization endpoint, which= already authenticates the user and can gather consent, I need to implement a= new endpoint that's not-quite-OAuth but is almost like it. But it's enough t= o be confusing because sometimes I go to this new endpoint endpoint and also= get an access token anyway, to use somewhere that I'm not sure where. And I= 'm not sure I can collapse the two endpoints and re-use my OAuth infrastruct= ure. After all, I still need to use the token endpoint, and by that point my= server needs to know which endpoint the user went to in the first place to m= ake that switch. As a developer, this all sounds horribly convoluted and com= plicated to track. Do I get to re-use any of the components from an authoriz= ation endpoint? How do I know whether or not to issue the access token if th= e user goes to the authentication endpoint? And then there are the optimizat= ions for existing well-known and well-understood use cases: what if my clien= t is sitting in the same browser session and just wants to get the user asse= rtion directly instead of going through a round trip? Do I need to make two r= ound trips if I'm getting a protected API at the same time as authn data? Ca= n I use the same response_type functionality and other extensions on the aut= hentication endpoint?=20 >>>>=20 >>>> In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is d= angerous and confusing and not something I think the OAuth WG should be a pa= rt of. And I really just don't see the point of it, unless the goal is to po= llute the standards space which Connect currently occupies. Is Connect perfe= ct? Heck no. But it's far and away the best thing we've had in a long time, a= nd it already does every single thing you are asking for from this new draft= . >>>>=20 >>>> -- Justin >>>>=20 >>>>> On 5/14/2014 9:43 PM, Phil Hunt wrote: >>>>> Sorry I meant to say this is why it has the /authenticate endpoint to i= ndicate the client only wants the users session information. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On May 14, 2014, at 6:42 PM, Phil Hunt wrote: >>>>>>=20 >>>>>> Right. This is why it has a different point because the client does N= OT want a resource token. >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On May 14, 2014, at 6:41 PM, Justin Richer wrote: >>>>>>>=20 >>>>>>> Actually, it's about OAuth compatibility. With OAuth, you get an acc= ess token to be used at a protected resource. That's what it's for, that's w= hat clients do the OAuth dance(s) for. Connect defines that protected resour= ce as the userinfo endpoint (ie, "tells the client what to do with it"). Con= nect also defines the id token that comes in along side of the bog-standard O= Auth token, and Connect is turned on and off through the use of bog-standard= OAuth scopes. So that makes it very, very, very easy to take an OAuth serve= r and turn it into a Connect server. I know, I've done just that, and I've w= alked others through the process as well.=20 >>>>>>>=20 >>>>>>> But the a4c draft is using something that's almost-but-not-quite-OAu= th: You might not get an access token, which is going to confuse the heck ou= t of most OAuth clients that I know since that's what they're trying to get a= t in the first place, and there's no real way for a client to distinguish it= s request for something with an id_token vs. without. Additionally, in pract= ice, that access token is hugely useful. Just look at all of the weird OpenI= D2 and OAuth1 hybrid stuff that people were trying to do back a few years ag= o on top of all the OpenID2 extensions -- this is exactly because OpenID2 wa= s built for "authentication only" because that's what people thought develop= ers wanted, but it turned out that developers wanted a whole lot more than t= hat. This is one main reason the Facebook Connect and Twitter's OAuth-based l= ogin came along and ate everyone's lunch: they gave you authentication, but a= lso something useful about the end user. >>>>>>>=20 >>>>>>> All said, it sounds like you want Connect but without the UserInfo E= ndpoint. You'll be glad to know that you can already do that as per the MTI d= efinitions of the server: >>>>>>>=20 >>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI >>>>>>>=20 >>>>>>> You are free to implement a SCIM endpoint (which, by the way, you'll= probably need that access_token to access) or no endpoint at all, and a com= pliant client ought to be able to deal with that. In fact, there's a way to g= et just the id_token in Connect if that's all you care about, but instead of= hiding it inside of an existing flow that might return something different d= epending on (currently-undefined) special circumstances, it puts this mode i= nto a separate response_type entirely to enforce the point that it is differ= ent from regular OAuth.=20 >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>>> On 5/14/2014 9:24 PM, Phil Hunt wrote: >>>>>>>> It isn=E2=80=99t required (or should not be). This issue is OIDC c= ompatibility. >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On May 14, 2014, at 6:21 PM, Justin Richer wrote= : >>>>>>>>>=20 >>>>>>>>> How is this functionally different from the a4c draft that also al= lows the return of both an id_token and an access token?=20 >>>>>>>>>=20 >>>>>>>>> -- Justin >>>>>>>>>=20 >>>>>>>>>> On 5/14/2014 9:18 PM, Phil Hunt wrote: >>>>>>>>>> That=E2=80=99s not a minimalistic authn only profile. >>>>>>>>>>=20 >>>>>>>>>> If you return both an access token AND an id token than the servi= ce provide has to implement both and the client has to figure out what to do= with it. >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> @independentid >>>>>>>>>> www.independentid.com >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On May 14, 2014, at 5:44 PM, Chuck Mortimore wrote: >>>>>>>>>>>=20 >>>>>>>>>>> "I had personally requested the OIDC community about six months a= go to describe some minimal subset which we could all reasonably implement."= >>>>>>>>>>>=20 >>>>>>>>>>> I believe you're looking for this: http://openid.net/specs/openi= d-connect-basic-1_0.html >>>>>>>>>>>=20 >>>>>>>>>>> -cmort >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra wrote: >>>>>>>>>>>> Anil, >>>>>>>>>>>>=20 >>>>>>>>>>>> the challenge is that OIDC is a rather large set of specificati= ons, and to my knowledge even the core specification has NOT found >>>>>>>>>>>> a complete implementation at any large IdP. I am not talking he= re about boutique toolkits or startups, I am talking about the folks >>>>>>>>>>>> who have 100s of millions of users. And, BTW, implementing a fe= w arbitrarily selected features from OIDC is not the same as implementing OI= DC. >>>>>>>>>>>>=20 >>>>>>>>>>>> As we all know, the core problem is that of adding an authentic= ator token to OAuth flows, which is a rather modest extension to OAuth. >>>>>>>>>>>>=20 >>>>>>>>>>>> I had personally requested the OIDC community about six months a= go to describe some minimal subset which we could all reasonably implement. I= was told that the specification was "locked down" and fully debugged and s= o on, so no changes could be made. Imagine my surprise to find that in the f= inal drafts there was a whole new flow - the hybrid flow - that had been add= ed at the last minute. I had never heard of the hybrid flow in the OAuth con= text - have you? So now you have an even larger specification! >>>>>>>>>>>>=20 >>>>>>>>>>>> The value of draft-hunt-oauth-v2-user-a4c-01 is that it describ= es precisely a minimal extension to OAuth flows to support an authenticator t= oken. In my experience, this is the subset that most customers and implemen= tors are looking for.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> - prateek >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> Tony/Phil, >>>>>>>>>>>>> any chance you can have this work done at OIDC?=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The reason is that it is commonly understood/accepted now that= OAuth provides authorization related specs while authentication/profile >>>>>>>>>>>>> related specs are coming from OIDC (which builds on top of OAu= th2). >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Anil >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 05/14/2014 10:47 AM, Anthony Nadalin wrote: >>>>>>>>>>>>>> I agree with Phil on this one, there are implementations of t= his already and much interest >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil= Hunt >>>>>>>>>>>>>> Sent: Wednesday, May 14, 2014 8:32 AM >>>>>>>>>>>>>> To: Brian Campbell >>>>>>>>>>>>>> Cc: oauth@ietf.org >>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] OAuth Milestone Update and Recharteri= ng >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> On the contrary. I and others are interested.=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> We are waiting for the charter to pick up the work.=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> Regardless there will be a new draft shortly.=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On May 14, 2014, at 5:24, Brian Campbell wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I would object to 'OAuth Authentication' being picked up by t= he WG as a work item. The starting point draft has expired and it hasn't rea= lly been discusses since Berlin nearly a year ago. As I recall, there was o= nly very limited interest in it even then. I also don't believe it fits well= with the WG charter. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I would suggest the WG consider picking up 'OAuth Symmetric P= roof of Possession for Code Extension' for which there is an excellent start= ing point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a= relativity simple security enhancement which addresses problems currently b= eing encountered in deployments of native clients. =20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> you might have seen that we pushed the assertion documents an= d the JWT >>>>>>>>>>>>>> documents to the IESG today. We have also updated the milesto= nes on the >>>>>>>>>>>>>> OAuth WG page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> This means that we can plan to pick up new work in the group.= >>>>>>>>>>>>>> We have sent a request to Kathleen to change the milestone fo= r the OAuth >>>>>>>>>>>>>> security mechanisms to use the proof-of-possession terminolog= y. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> We also expect an updated version of the dynamic client regis= tration >>>>>>>>>>>>>> spec incorporating last call feedback within about 2 weeks. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> We would like you to think about adding the following milesto= nes to the >>>>>>>>>>>>>> charter as part of the re-chartering effort: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Nov 2014 Submit 'Token introspection' to the IESG for conside= ration as a >>>>>>>>>>>>>> Proposed Standard >>>>>>>>>>>>>> Starting point: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Jan 2015 Submit 'OAuth Authentication' to the IESG for consid= eration as >>>>>>>>>>>>>> a Proposed Standard >>>>>>>>>>>>>> Starting point: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Jan 2015 Submit 'Token Exchange' to the IESG for consideratio= n as a >>>>>>>>>>>>>> Proposed Standard >>>>>>>>>>>>>> Starting point: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> We also updated the charter text to reflect the current situa= tion. Here >>>>>>>>>>>>>> is the proposed text: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Charter for Working Group >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The Web Authorization (OAuth) protocol allows a user to grant= a >>>>>>>>>>>>>> third-party Web site or application access to the user's prot= ected >>>>>>>>>>>>>> resources, without necessarily revealing their long-term cred= entials, >>>>>>>>>>>>>> or even their identity. For example, a photo-sharing site tha= t >>>>>>>>>>>>>> supports OAuth could allow its users to use a third-party pri= nting Web >>>>>>>>>>>>>> site to print their private pictures, without allowing the pr= inting >>>>>>>>>>>>>> site to gain full control of the user's account and without h= aving the >>>>>>>>>>>>>> user share his or her photo-sharing sites' long-term credenti= al with >>>>>>>>>>>>>> the printing site. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The OAuth 2.0 protocol suite encompasses >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> * a protocol for obtaining access tokens from an authorizatio= n >>>>>>>>>>>>>> server with the resource owner's consent, >>>>>>>>>>>>>> * protocols for presenting these access tokens to resource se= rver >>>>>>>>>>>>>> for access to a protected resource, >>>>>>>>>>>>>> * guidance for securely using OAuth 2.0, >>>>>>>>>>>>>> * the ability to revoke access tokens, >>>>>>>>>>>>>> * standardized format for security tokens encoded in a JSON f= ormat >>>>>>>>>>>>>> (JSON Web Token, JWT), >>>>>>>>>>>>>> * ways of using assertions with OAuth, and >>>>>>>>>>>>>> * a dynamic client registration protocol. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The working group also developed security schemes for present= ing >>>>>>>>>>>>>> authorization tokens to access a protected resource. This led= to the >>>>>>>>>>>>>> publication of the bearer token, as well as work that remains= to be >>>>>>>>>>>>>> completed on proof-of-possession and token exchange. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The ongoing standardization effort within the OAuth working g= roup will >>>>>>>>>>>>>> focus on enhancing interoperability and functionality of OAut= h >>>>>>>>>>>>>> deployments, such as a standard for a token introspection ser= vice and >>>>>>>>>>>>>> standards for additional security of OAuth requests. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Feedback appreciated. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ciao >>>>>>>>>>>>>> Hannes & Derek >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>>> Portfolio Architect >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> @ >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> bcampbell@pingidentity.com >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Connect with us=E2=80=A6 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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 >>>>>>>>>>=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 >>=20 --Apple-Mail-04064FD3-B21B-437C-9417-3B5C20180AFF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Phil,  I recommend reading the sp= ecification. 

Sent from my iPhone

On May 15, 2014,= at 8:12 AM, Phil Hunt <phil.hunt= @oracle.com> wrote:

Whi= ch flow is that? It certainly wasn't the one Justin pointed to. 
Phil

On May 14, 2014, at 22:31, John Bradley <ve7jtb@ve7jtb.com> wrote:

No.

OAuth requires that if y= ou use the code response type, the token endpoint must return an access toke= n.

Connect dosen't require a user_info endpoint.

In the response_type "id_token"  only a id_token= is returned in the front channel in a manner similar to SAML POST binding b= ut fragment encoded by default.

So there is a flow i= n Connect that doesn't deliver an access token.

I t= hink this discussion is more about what changes you want to the core of OAut= h.

Connect worked around the OAuth spec to be compa= tible with it.

Only the OAuth WG can change OAuth a= nd that seems to be what you want.  
a4c is a justification f= or making those changes.

We should probably focus o= n the core issue of what changes to RFC 6749 you are after, to determine if t= he WG wants to change the charter.

I think focusing= on a4c is a read herring.

John B.

On May 15, 2014, at 6:55 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

I think those are things to discuss if the authen is on the charter. <= /div>

So we have now clarified that the basic connect pro= file doesn't do just authen and requires identity profile services. 

Phil

On May 14, 2014, at 18:57, Justin Richer <= jricher@mit.edu> wrote:

=20 =20 =20
Right, so instead of being able to use my authorization endpoint, which already authenticates the user and can gather consent, I need to implement a new endpoint that's not-quite-OAuth but is almost like it. But it's enough to be confusing because sometimes I go to this new endpoint endpoint and also get an access token anyway, to use somewhere that I'm not sure where. And I'm not sure I can collapse the two endpoints and re-use my OAuth infrastructure. After all, I still need to use the token endpoint, and by that point my server needs to know which endpoint the user went to in the first place to make that switch. As a developer, this all sounds horribly convoluted and complicated to track. Do I get to re-use any of the components from an authorization endpoint? How do I know whether or not to issue the access token if the user goes to the authentication endpoint? And then there are the optimizations for existing well-known and well-understood use cases: what if my client is sitting in the same browser session and just wants to get the user assertion directly instead of going through a round trip? Do I need to make two round trips if I'm getting a protected API at the same time as authn data? Can I use the same response_type functionality and other extensions on the authentication endpoint?

In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is dangerous and confusing and not something I think the OAuth WG should be a part of. And I really just don't see the point of it, unless the goal is to pollute the standards space which Connect currently occupies. Is Connect perfect? Heck no. But it's far and away the best thing we've had in a long time, and it already does every single thing you are asking for from this new draft.

 -- Justin

On 5/14/2014 9:43 PM, Phil Hunt wrote:
Sorry I meant to say this is why it has the /authenticate endpoint to indicate the client only wants the users session information.


On May 14, 2014, at 6:42 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Right.  This is why it has a different point because the client does NOT want a resource token.


On May 14, 2014, at 6:41 PM, Justin Richer <jricher@mit.edu>= ; wrote:

Actually, it's about OAuth compatibility. With OAuth, you get an access token to be used at a protected resource. That's what it's for, that's what clients do the OAuth dance(s) for. Connect defines that protected resource as the userinfo endpoint (ie, "tells the client what to do with it"). Connect also defines the id token that comes in along side of the bog-standard OAuth token, and Connect is turned on and off through the use of bog-standard OAuth scopes. So that makes it very, very, very easy to take an OAuth server and turn it into a Connect server. I know, I've done just that, and I've walked others through the process as well.

But the a4c draft is using something that's almost-but-not-quite-OAuth: You might not get an access token, which is going to confuse the heck out of most OAuth clients that I know since that's what they're trying to get at in the first place, and there's no real way for a client to distinguish its request for something with an id_token vs. without. Additionally, in practice, that access token is hugely useful. Just look at all of the weird OpenID2 and OAuth1 hybrid stuff that people were trying to do back a few years ago on top of all the OpenID2 extensions -- this is exactly because OpenID2 was built for "authentication only" because that's what people thought developers wanted, but it turned out that developers wanted a whole lot more than that. This is one main reason the Facebook Connect and Twitter's OAuth-based login came along and ate everyone's lunch: they gave you authentication, but also something useful about the end user.

All said, it sounds like you want Connect but without the UserInfo Endpoint. You'll be glad to know that you can already do that as per the MTI definitions of the server:

  http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI

You are free to implement a SCIM endpoint (which, by the way, you'll probably need that access_token to access) or no endpoint at all, and a compliant client ought to be able to deal with that. In fact, there's a way to get just the id_token in Connect if that's all you care about, but instead of hiding it inside of an existing flow that might return something different depending on (currently-undefined) special circumstances, it puts this mode into a separate response_type entirely to enforce the point that it is different from regular OAuth.

 -- Justin

On 5/14/2014 9:24 PM, Phil Hunt wrote:
It isn=E2=80=99t required (or should not be).  This issue is OIDC compatibility.


On May 14, 2014, at 6:21 PM, Justin Richer <jricher@mit.edu> wrote:

How is this functionally different from the a4c draft that also allows the return of both an id_token and an access token?

 -- Justin

On 5/14/2014 9:18 PM, Phil Hunt wrote:
That=E2=80=99s not a minimalistic authn only profile.

If you return both an access token AND an id token than the service provide has to implement both and the client has to figure out what to do with it.



"I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement."

=
I believe you're looking for this: http://op= enid.net/specs/openid-connect-basic-1_0.html

=
-cmor= t



On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:
Anil,

the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token to OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that  the specification was "locked down" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!

The value of draft-hunt-oauth-v2-user= -a4c-01 is that it describes precisely a minimal extension to OAuth flows to support an authenticator token.  In my experience, this is the subset that most customers and implementors are looking for.


- prateek

=



Tony/Phil,   any chance you can have this work done at OIDC?

The reason is that it is commonly understood/accepte= d now that OAuth provides authorization related specs while authentication/pro= file
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:
=

I agree with Phil on this one, there are implementations of this already and much interest

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
= Cc: oauth@= ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

On the contrary. I and others are interested. <= /p>

 

We are waiting for the charter to pick up the work. 

 

Regardless there will be a new draft shortly. 

=


Phil


On May 14, 2014, at 5:24, Brian Campbell <b= campbell@pingidentity.com> wrote:

I would object to 'OAuth Authenticati= on' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <ha= nnes.tschofenig@gmx.net> wrote:

Hi= all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.
=
This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possessio= n terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:
=
-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
= * standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possessio= n and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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



=
--

3D"Ping

Brian Campbell
Portf= olio Architect

@

bcampbell@pingidentity.com
<= p class=3D"MsoNormal" style=3D"text-align:center" align=3D"center">3D"phone"

+1 720.317.2061

Connect with us=E2=80=A6

3D"t=3D"y=3D"=3D"=3D=3D=3D"rss

 

_______________________________________________
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
htt= ps://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/o=
auth






=20
_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.org/mail= man/listinfo/oauth

= --Apple-Mail-04064FD3-B21B-437C-9417-3B5C20180AFF-- --Apple-Mail-8A6519DA-09D1-4334-864E-72B0F1E3B19A Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwNTE1MDgyMjU4WjAjBgkqhkiG9w0BCQQxFgQUsr7yZeGM+SFIZEdI /yxeEpHa0KMwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAXWLkaGJO55+LG2cxJPo6GdFDK72KEJTbBZcpP8N6Cj5VXcYx eTsF7y7rqpPM7CE8DWRRLM91QHT+qHqvhRsTKV/PSokivGQ+rn26Yab9eElMlNC2H3BwrLLL+AO6 fItoa3dRX1JZgNYkMdpd+XgPUwn1f3aA6ukz4NZoUSSL4sJUzaLH5+19X3fLhrnMZFrt110UXLTc 1FaohqRzIhMtIy6CDrVJhnaogYnIPlzbDsbZg/AxkUFOufVmh117tVYqsaSnV/7tVU+FUdO81Mb/ BLKur7rXXn2s7zBEjA+YSYdYHPkr+hj+a+7+8vZtbiERfOQEer9TwUXmyXZNTsz09wAAAAAAAA== --Apple-Mail-8A6519DA-09D1-4334-864E-72B0F1E3B19A-- From nobody Thu May 15 01:27:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440A71A0413 for ; Thu, 15 May 2014 01:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 fp-9t7mpSxrG for ; Thu, 15 May 2014 01:27:03 -0700 (PDT) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E75F1A0407 for ; Thu, 15 May 2014 01:27:02 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id b57so384483eek.13 for ; Thu, 15 May 2014 01:26:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=lYzr9eenVG/c4ELqA47yK+Oi77lLb/9AV7bkfGHYRmw=; b=PxUUcVIJI9A0HLlyxIPCGkbfE0jYKSqB28sTIjjvlbG+u7j5NyaeEQNzC8JvvVM9UV 7UZ+9mTpGncT0CahK0z9ffYdSLSSbvB4gBd+cWartNtq3GU60C5lWoY1/sYajBvT7JhH INjdJgH9j2N+VfAgm6Rn1Hcetw6PcxDpvW/t+ObpmjtlmjsIIJWT+rWay3A3L12sBfdS OXzxs3rNZoThJas50mgV/CrFx+pGBYLffDxeTwEnSX3vjUsd2IEGTKImU2cNG0tho0Tc PYdLQ8y25nTVW81eMBUqpRi/7TKZbk63rE5xk2OAWjiV2f/uVEAme0weZh2bKHGGZmXK FR5w== X-Gm-Message-State: ALoCoQkeOpTLbf+TJ4h2edRq/8FuOa7p5GD8N63VoUjQClqJ5XXr9YPtNPTtpBG54lWnGzZYCpMx X-Received: by 10.14.7.72 with SMTP id 48mr847049eeo.114.1400142414565; Thu, 15 May 2014 01:26:54 -0700 (PDT) Received: from [10.105.255.214] (vlan105-gw1.ush2.tnib.de. [86.110.65.1]) by mx.google.com with ESMTPSA id h49sm10905490eeg.21.2014.05.15.01.26.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 May 2014 01:26:53 -0700 (PDT) References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> <537416A9.5060701@mit.edu> <53741B2F.4040506@mit.edu> <1F00EAF0-CC8F-469F-84F3-50C534325360@oracle.com> <51BD7E1D-5C8D-4B6F-8F3C-64137CBDA0DA@oracle.com> <53741F27.4010100@mit.edu> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9F72D215-FC80-4CCD-B2F5-4B42610267F2; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D201) From: John Bradley Date: Thu, 15 May 2014 10:26:52 +0200 To: Anthony Nadalin Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/O2eCV96HFg1YeTc9aCQg85LH6ZQ Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 08:27:10 -0000 --Apple-Mail-9F72D215-FC80-4CCD-B2F5-4B42610267F2 Content-Type: multipart/alternative; boundary=Apple-Mail-DC1310E9-40AA-43DA-B962-3737EFA0F23F Content-Transfer-Encoding: 7bit --Apple-Mail-DC1310E9-40AA-43DA-B962-3737EFA0F23F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable OAuth covers authentication in security consideration=20 This was debated in the WG at the time.=20 Just say that you want to reopen the RFC.=20 Sent from my iPhone > On May 15, 2014, at 9:03 AM, Anthony Nadalin wrote= : >=20 > So Oauth already treads into the authentication space to some extent and e= nough of an extent to create additional security issues and threats. > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Wednesday, May 14, 2014 10:32 PM > To: Phil Hunt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering > =20 > No. > =20 > OAuth requires that if you use the code response type, the token endpoint m= ust return an access token. > =20 > Connect dosen't require a user_info endpoint. > =20 > In the response_type "id_token" only a id_token is returned in the front c= hannel in a manner similar to SAML POST binding but fragment encoded by defa= ult. > =20 > So there is a flow in Connect that doesn't deliver an access token. > =20 > I think this discussion is more about what changes you want to the core of= OAuth. > =20 > Connect worked around the OAuth spec to be compatible with it. > =20 > Only the OAuth WG can change OAuth and that seems to be what you want. =20= > a4c is a justification for making those changes. > =20 > We should probably focus on the core issue of what changes to RFC 6749 you= are after, to determine if the WG wants to change the charter. > =20 > I think focusing on a4c is a read herring. > =20 > John B. > =20 > On May 15, 2014, at 6:55 AM, Phil Hunt wrote: >=20 >=20 > I think those are things to discuss if the authen is on the charter.=20 > =20 > So we have now clarified that the basic connect profile doesn't do just au= then and requires identity profile services.=20 >=20 > Phil >=20 > On May 14, 2014, at 18:57, Justin Richer wrote: >=20 > Right, so instead of being able to use my authorization endpoint, which al= ready authenticates the user and can gather consent, I need to implement a n= ew endpoint that's not-quite-OAuth but is almost like it. But it's enough to= be confusing because sometimes I go to this new endpoint endpoint and also g= et an access token anyway, to use somewhere that I'm not sure where. And I'm= not sure I can collapse the two endpoints and re-use my OAuth infrastructur= e. After all, I still need to use the token endpoint, and by that point my s= erver needs to know which endpoint the user went to in the first place to ma= ke that switch. As a developer, this all sounds horribly convoluted and comp= licated to track. Do I get to re-use any of the components from an authoriza= tion endpoint? How do I know whether or not to issue the access token if the= user goes to the authentication endpoint? And then there are the optimizati= ons for existing well-known and well-understood use cases: what if my client= is sitting in the same browser session and just wants to get the user asser= tion directly instead of going through a round trip? Do I need to make two r= ound trips if I'm getting a protected API at the same time as authn data? Ca= n I use the same response_type functionality and other extensions on the aut= hentication endpoint?=20 >=20 > In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is dang= erous and confusing and not something I think the OAuth WG should be a part o= f. And I really just don't see the point of it, unless the goal is to pollut= e the standards space which Connect currently occupies. Is Connect perfect? H= eck no. But it's far and away the best thing we've had in a long time, and i= t already does every single thing you are asking for from this new draft. >=20 > -- Justin >=20 > On 5/14/2014 9:43 PM, Phil Hunt wrote: > Sorry I meant to say this is why it has the /authenticate endpoint to indi= cate the client only wants the users session information. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > On May 14, 2014, at 6:42 PM, Phil Hunt wrote: >=20 >=20 > Right. This is why it has a different point because the client does NOT w= ant a resource token. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > On May 14, 2014, at 6:41 PM, Justin Richer wrote: >=20 >=20 > Actually, it's about OAuth compatibility. With OAuth, you get an access to= ken to be used at a protected resource. That's what it's for, that's what cl= ients do the OAuth dance(s) for. Connect defines that protected resource as t= he userinfo endpoint (ie, "tells the client what to do with it"). Connect al= so defines the id token that comes in along side of the bog-standard OAuth t= oken, and Connect is turned on and off through the use of bog-standard OAuth= scopes. So that makes it very, very, very easy to take an OAuth server and t= urn it into a Connect server. I know, I've done just that, and I've walked o= thers through the process as well.=20 >=20 > But the a4c draft is using something that's almost-but-not-quite-OAuth: Yo= u might not get an access token, which is going to confuse the heck out of m= ost OAuth clients that I know since that's what they're trying to get at in t= he first place, and there's no real way for a client to distinguish its requ= est for something with an id_token vs. without. Additionally, in practice, t= hat access token is hugely useful. Just look at all of the weird OpenID2 and= OAuth1 hybrid stuff that people were trying to do back a few years ago on t= op of all the OpenID2 extensions -- this is exactly because OpenID2 was buil= t for "authentication only" because that's what people thought developers wa= nted, but it turned out that developers wanted a whole lot more than that. T= his is one main reason the Facebook Connect and Twitter's OAuth-based login c= ame along and ate everyone's lunch: they gave you authentication, but also s= omething useful about the end user. >=20 > All said, it sounds like you want Connect but without the UserInfo Endpoin= t. You'll be glad to know that you can already do that as per the MTI defini= tions of the server: >=20 > http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI >=20 > You are free to implement a SCIM endpoint (which, by the way, you'll proba= bly need that access_token to access) or no endpoint at all, and a compliant= client ought to be able to deal with that. In fact, there's a way to get ju= st the id_token in Connect if that's all you care about, but instead of hidi= ng it inside of an existing flow that might return something different depen= ding on (currently-undefined) special circumstances, it puts this mode into a= separate response_type entirely to enforce the point that it is different f= rom regular OAuth.=20 >=20 > -- Justin >=20 > On 5/14/2014 9:24 PM, Phil Hunt wrote: > It isn=E2=80=99t required (or should not be). This issue is OIDC compatib= ility. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > On May 14, 2014, at 6:21 PM, Justin Richer wrote: >=20 >=20 > How is this functionally different from the a4c draft that also allows the= return of both an id_token and an access token?=20 >=20 > -- Justin >=20 > On 5/14/2014 9:18 PM, Phil Hunt wrote: > That=E2=80=99s not a minimalistic authn only profile. > =20 > If you return both an access token AND an id token than the service provid= e has to implement both and the client has to figure out what to do with it.= > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > On May 14, 2014, at 5:44 PM, Chuck Mortimore w= rote: >=20 >=20 > "I had personally requested the OIDC community about six months ago to des= cribe some minimal subset which we could all reasonably implement." > =20 > I believe you're looking for this: http://openid.net/specs/openid-connect-= basic-1_0.html > =20 > -cmort > =20 > =20 > =20 > On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra wrote: > Anil, >=20 > the challenge is that OIDC is a rather large set of specifications, and to= my knowledge even the core specification has NOT found > a complete implementation at any large IdP. I am not talking here about bo= utique toolkits or startups, I am talking about the folks > who have 100s of millions of users. And, BTW, implementing a few arbitrari= ly selected features from OIDC is not the same as implementing OIDC. >=20 > As we all know, the core problem is that of adding an authenticator token t= o OAuth flows, which is a rather modest extension to OAuth. >=20 > I had personally requested the OIDC community about six months ago to desc= ribe some minimal subset which we could all reasonably implement. I was told= that the specification was "locked down" and fully debugged and so on, so n= o changes could be made. Imagine my surprise to find that in the final draft= s there was a whole new flow - the hybrid flow - that had been added at the l= ast minute. I had never heard of the hybrid flow in the OAuth context - have= you? So now you have an even larger specification! >=20 > The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisel= y a minimal extension to OAuth flows to support an authenticator token. In m= y experience, this is the subset that most customers and implementors are lo= oking for.=20 >=20 >=20 > - prateek >=20 >=20 >=20 >=20 > =20 > Tony/Phil, > any chance you can have this work done at OIDC?=20 >=20 > The reason is that it is commonly understood/accepted now that OAuth provi= des authorization related specs while authentication/profile > related specs are coming from OIDC (which builds on top of OAuth2). >=20 > Regards, > Anil >=20 > On 05/14/2014 10:47 AM, Anthony Nadalin wrote: > I agree with Phil on this one, there are implementations of this already a= nd much interest > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Wednesday, May 14, 2014 8:32 AM > To: Brian Campbell > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering > =20 > On the contrary. I and others are interested.=20 > =20 > We are waiting for the charter to pick up the work.=20 > =20 > Regardless there will be a new draft shortly.=20 >=20 > Phil >=20 > On May 14, 2014, at 5:24, Brian Campbell wrot= e: >=20 > I would object to 'OAuth Authentication' being picked up by the WG as a wo= rk item. The starting point draft has expired and it hasn't really been disc= usses since Berlin nearly a year ago. As I recall, there was only very limi= ted interest in it even then. I also don't believe it fits well with the WG c= harter. >=20 > I would suggest the WG consider picking up 'OAuth Symmetric Proof of Posse= ssion for Code Extension' for which there is an excellent starting point of h= ttp://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity s= imple security enhancement which addresses problems currently being encounte= red in deployments of native clients.=20 >=20 > =20 > On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig wrote: > Hi all, >=20 > you might have seen that we pushed the assertion documents and the JWT > documents to the IESG today. We have also updated the milestones on the > OAuth WG page. >=20 > This means that we can plan to pick up new work in the group. > We have sent a request to Kathleen to change the milestone for the OAuth > security mechanisms to use the proof-of-possession terminology. >=20 > We also expect an updated version of the dynamic client registration > spec incorporating last call feedback within about 2 weeks. >=20 > We would like you to think about adding the following milestones to the > charter as part of the re-chartering effort: >=20 > ----- >=20 > Nov 2014 Submit 'Token introspection' to the IESG for consideration as a > Proposed Standard > Starting point: >=20 > Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as > a Proposed Standard > Starting point: >=20 > Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a > Proposed Standard > Starting point: >=20 > ----- >=20 > We also updated the charter text to reflect the current situation. Here > is the proposed text: >=20 > ----- >=20 > Charter for Working Group >=20 >=20 > The Web Authorization (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that > supports OAuth could allow its users to use a third-party printing Web > site to print their private pictures, without allowing the printing > site to gain full control of the user's account and without having the > user share his or her photo-sharing sites' long-term credential with > the printing site. >=20 > The OAuth 2.0 protocol suite encompasses >=20 > * a protocol for obtaining access tokens from an authorization > server with the resource owner's consent, > * protocols for presenting these access tokens to resource server > for access to a protected resource, > * guidance for securely using OAuth 2.0, > * the ability to revoke access tokens, > * standardized format for security tokens encoded in a JSON format > (JSON Web Token, JWT), > * ways of using assertions with OAuth, and > * a dynamic client registration protocol. >=20 > The working group also developed security schemes for presenting > authorization tokens to access a protected resource. This led to the > publication of the bearer token, as well as work that remains to be > completed on proof-of-possession and token exchange. >=20 > The ongoing standardization effort within the OAuth working group will > focus on enhancing interoperability and functionality of OAuth > deployments, such as a standard for a token introspection service and > standards for additional security of OAuth requests. >=20 > ----- >=20 > Feedback appreciated. >=20 > Ciao > Hannes & Derek >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > -- >=20 > Brian Campbell > Portfolio Architect > @ > bcampbell@pingidentity.com >=20 > +1 720.317.2061 > Connect with us=E2=80=A6 >=20 >=20 > =20 > _______________________________________________ > 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 >=20 >=20 > _______________________________________________ > 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 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 --Apple-Mail-DC1310E9-40AA-43DA-B962-3737EFA0F23F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
OAuth covers authentication in securit= y consideration 

This was debated in the WG at= the time. 

Just say that you want to reopen t= he RFC. 

Sent from my iPhone

On May 15, 201= 4, at 9:03 AM, Anthony Nadalin <= tonynad@microsoft.com> wrote:

=
=

So Oauth already treads int= o the authentication space to some extent and enough of an extent to create a= dditional security issues and threats.

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 14, 2014 10:32 PM
To: Phil Hunt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering<= /o:p>

 

No.

 

OAuth requires that if you use the code response type= , the token endpoint must return an access token.

 

Connect dosen't require a user_info endpoint.

 

In the response_type "id_token"  only a id_token= is returned in the front channel in a manner similar to SAML POST binding b= ut fragment encoded by default.

 

So there is a flow in Connect that doesn't deliver an= access token.

 

I think this discussion is more about what changes yo= u want to the core of OAuth.

 

Connect worked around the OAuth spec to be compatible= with it.

 

Only the OAuth WG can change OAuth and that seems to b= e what you want.  

a4c is a justification for making those changes.=

 

We should probably focus on the core issue of what ch= anges to RFC 6749 you are after, to determine if the WG wants to change the c= harter.

 

I think focusing on a4c is a read herring.=

 

John B.

 

On May 15, 2014, at 6:55 AM, Phil Hunt <phil.hunt@oracle.com> wrote:=



I think those are things to discuss if the authen is o= n the charter. 

 

So we have now clarified that the basic connect profi= le doesn't do just authen and requires identity profile services. =


Phil


On May 14, 2014, at 18:57, Justin Richer <jricher@mit.edu> wrote:

Right, so instead of being able to use my authorizati= on endpoint, which already authenticates the user and can gather consent, I n= eed to implement a new endpoint that's not-quite-OAuth but is almost like it= . But it's enough to be confusing because sometimes I go to this new endpoint endpoint and also get an access= token anyway, to use somewhere that I'm not sure where. And I'm not sure I c= an collapse the two endpoints and re-use my OAuth infrastructure. After all,= I still need to use the token endpoint, and by that point my server needs to know which endpoint the user= went to in the first place to make that switch. As a developer, this all so= unds horribly convoluted and complicated to track. Do I get to re-use any of= the components from an authorization endpoint? How do I know whether or not to issue the access token if the use= r goes to the authentication endpoint? And then there are the optimizations f= or existing well-known and well-understood use cases: what if my client is s= itting in the same browser session and just wants to get the user assertion directly instead of going through a= round trip? Do I need to make two round trips if I'm getting a protected AP= I at the same time as authn data? Can I use the same response_type functiona= lity and other extensions on the authentication endpoint?

In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is danger= ous and confusing and not something I think the OAuth WG should be a part of= . And I really just don't see the point of it, unless the goal is to pollute= the standards space which Connect currently occupies. Is Connect perfect? Heck no. But it's far and away the b= est thing we've had in a long time, and it already does every single thing y= ou are asking for from this new draft.

 -- Justin

On 5/14/2014 9:43 PM, Phil Hunt wrote:

Sorry I meant to say this is why it has the /authenti= cate endpoint to indicate the client only wants the users session informatio= n.

 

 

 

 

On May 14, 2014, at 6:42 PM, Phil Hunt <phil.hunt@oracle.com> wrote:=



Right.  This is why it has a different point bec= ause the client does NOT want a resource token.

 

 

 

 

On May 14, 2014, at 6:41 PM, Justin Richer <jricher@mit.edu> wrote:



Actually, it's about OAuth compatibility. With OAuth,= you get an access token to be used at a protected resource. That's what it'= s for, that's what clients do the OAuth dance(s) for. Connect defines that p= rotected resource as the userinfo endpoint (ie, "tells the client what to do with it"). Connect also defines t= he id token that comes in along side of the bog-standard OAuth token, and Co= nnect is turned on and off through the use of bog-standard OAuth scopes. So t= hat makes it very, very, very easy to take an OAuth server and turn it into a Connect server. I know, I'v= e done just that, and I've walked others through the process as well.

But the a4c draft is using something that's almost-but-not-quite-OAuth: You m= ight not get an access token, which is going to confuse the heck out of most= OAuth clients that I know since that's what they're trying to get at in the= first place, and there's no real way for a client to distinguish its request for something with an id_t= oken vs. without. Additionally, in practice, that access token is hugely use= ful. Just look at all of the weird OpenID2 and OAuth1 hybrid stuff that peop= le were trying to do back a few years ago on top of all the OpenID2 extensions -- this is exactly because O= penID2 was built for "authentication only" because that's what people though= t developers wanted, but it turned out that developers wanted a whole lot mo= re than that. This is one main reason the Facebook Connect and Twitter's OAuth-based login came along and a= te everyone's lunch: they gave you authentication, but also something useful= about the end user.

All said, it sounds like you want Connect but without the UserInfo Endpoint.= You'll be glad to know that you can already do that as per the MTI definiti= ons of the server:

  http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI
=
You are free to implement a SCIM endpoint (which, by the way, you'll probabl= y need that access_token to access) or no endpoint at all, and a compliant c= lient ought to be able to deal with that. In fact, there's a way to get just= the id_token in Connect if that's all you care about, but instead of hiding it inside of an existing flow tha= t might return something different depending on (currently-undefined) specia= l circumstances, it puts this mode into a separate response_type entirely to= enforce the point that it is different from regular OAuth.

 -- Justin

On 5/14/2014 9:24 PM, Phil Hunt wrote:

It isn=E2=80=99t required (or should not be).  T= his issue is OIDC compatibility.

 

 

 

 

On May 14, 2014, at 6:21 PM, Justin Richer <jricher@mit.edu> wrote:



How is this functionally different from the a4c draft= that also allows the return of both an id_token and an access token?

 -- Justin

On 5/14/2014 9:18 PM, Phil Hunt wrote:

That=E2=80=99s not a minimalistic authn only profile.=

 

If you return both an access token AND an id token th= an the service provide has to implement both and the client has to figure ou= t what to do with it.

 

 

 

 

On May 14, 2014, at 5:44 PM, Chuck Mortimore <cmortimore@salesforce.com> w= rote:



"I had personally requested the OIDC community about s= ix months ago to describe some minimal subset which we could all reasonably i= mplement."

 

I believe you're looking for this: http://openid.net/specs/openid-connect-basic-1_0.html

 

-cmort

 

 

 

On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <<= a href=3D"mailto:prateek.mishra@oracle.com" target=3D"_blank">prateek.mishra= @oracle.com> wrote:

Anil,

the challenge is that OIDC is a rather large set of specifications, and to m= y knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about bout= ique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily= selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token to= OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to descri= be some minimal subset which we could all reasonably implement. I was told t= hat  the specification was "locked down" and fully debugged and so on, s= o no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - t= he hybrid flow - that had been added at the last minute. I had never heard o= f the hybrid flow in the OAuth context - have you? So now you have an even l= arger specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely a= minimal extension to OAuth flows to support an authenticator token.  I= n my experience, this is the subset that most customers and implementors are= looking for.


- prateek




 

Tony/Phil,
  any chance you can have this work done at OIDC?

The reason is that it is commonly understood/accepted now that OAuth provide= s authorization related specs while authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:

I agree with Phil on this one, there are i= mplementations of this already and much interest

 

From: OAuth [mailto:oauth-bounces@ietf.org= ] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.or= g
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

On the contrary. I and others are interested. 

 

We are waiting for the charter to pick up the work. =

 

Regardless there will be a new draft shortly. 


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a wo= rk item. The starting point draft has expired and it hasn't really been disc= usses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even the= n. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possess= ion for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativ= ity simple security enhancement which addresses problems currently being enc= ountered in deployments of native clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
= security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
= Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

3D"Ping

 =

Brian Campbell
Portfolio Architect

@

bcampbell@pingidentity.com

3D"phone"

+1 720.317.2061<= /o:p>

Connect with us=E2=80=A6

3D"twitter<= a href=3D"https://www.youtube.com/user/PingIdentityTV" target=3D"_blank" tit= le=3D"Ping on YouTube">3D"youtube<= a href=3D"https://www.linkedin.com/company/21870" target=3D"_blank" title=3D= "Ping on LinkedIn">3D"LinkedIn=<= a href=3D"https://www.facebook.com/pingidentitypage" target=3D"_blank" title= =3D"Ping on Facebook">3D"Facebook=<= a href=3D"https://plus.google.com/u/0/114266977739397708540" target=3D"_blan= k" title=3D"Ping on Google+">3D"Google+<= a href=3D"http://www.slideshare.net/PingIdentity" target=3D"_blank" title=3D= "Ping on SlideShare">3D"slide=<= a href=3D"http://flip.it/vjBF7" target=3D"_blank" title=3D"Ping on Flipboard">3D"flipbo=<= a href=3D"https://www.pingidentity.com/blogs/" target=3D"_blank" title=3D"Pi= ng blogs">3D"rss<= o:p>

3D"Register

 

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



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




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

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
ht= tps://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.iet=
f.org/mailman/listinfo/oauth

 

 

 

 

 

 

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

 

= --Apple-Mail-DC1310E9-40AA-43DA-B962-3737EFA0F23F-- --Apple-Mail-9F72D215-FC80-4CCD-B2F5-4B42610267F2 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwNTE1MDgyNjUzWjAjBgkqhkiG9w0BCQQxFgQUPOhQaogS482fG7nW xBKPEYeTpAYwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAB/7zicFYuvz9fBsQHtIGH/lKxrw3u4tzjcGd3iIL6Eb9xAWY 8tuG2r15WyXvbNPjCPtEeLBhrIUSUTeiqO54i+mB6JP5uOarXQ9yHkpIsDuslhlDUSvLhVdsF2iE cX4lgWqGGJlzteedvXiAf5EdBwen+uYrLJZqcYstgGu7bT0mvTIR5eLKqhqgCOiyCdx+0dzfu2X2 cLYaaZnG/AkvdQ5bgA9JdhHKdjMjWBc0853IvjwRFFjQy3V+sUpw0HUwphfBfpRcGSfVi8iP5wDE o+eIXL1Ou/CHKrVFWhcQhLZjccJqT1FgwAijGq5B5efvV+uQyKe0ud7kNsFYWcmtvwAAAAAAAA== --Apple-Mail-9F72D215-FC80-4CCD-B2F5-4B42610267F2-- From nobody Thu May 15 01:31:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E1E1A0413 for ; Thu, 15 May 2014 01:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 zpLR2m_1yiOF for ; Thu, 15 May 2014 01:30:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E351A0407 for ; Thu, 15 May 2014 01:30:54 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB312.namprd03.prod.outlook.com (10.141.48.28) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 15 May 2014 08:30:44 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0949.001; Thu, 15 May 2014 08:30:44 +0000 From: Anthony Nadalin To: John Bradley Thread-Topic: [OAUTH-WG] OAuth Milestone Update and Rechartering Thread-Index: AQHPawEbu8OzlywPcU+RkLqz+fSkNptACOgAgAA0VICAAAQKYIAAHggAgAB2bICAAAH9AIAACU+AgAABCYCAAACtAIAABLiAgAAAg4CAAAA7gIAAA/2AgAAxsoCAAAoCAIAAF2fQgAAZjACAAACIkA== Date: Thu, 15 May 2014 08:30:44 +0000 Message-ID: <331551c46fc642a18132324510f0da99@BLUPR03MB309.namprd03.prod.outlook.com> References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> <537416A9.5060701@mit.edu> <53741B2F.4040506@mit.edu> <1F00EAF0-CC8F-469F-84F3-50C534325360@oracle.com> <51BD7E1D-5C8D-4B6F-8F3C-64137CBDA0DA@oracle.com> <53741F27.4010100@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.110.65.1] x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(24454002)(52034003)(199002)(189002)(57704003)(479174003)(377454003)(53754006)(83322001)(19580405001)(15202345003)(31966008)(87936001)(74662001)(2656002)(19618635001)(101416001)(74502001)(19273905006)(15198665003)(80022001)(19300405004)(19617315010)(81542001)(19580395003)(64706001)(20776003)(79102001)(92566001)(86362001)(83072002)(85852003)(86612001)(19625215002)(19609705001)(18206015023)(15975445006)(81342001)(21056001)(74316001)(15395725003)(4396001)(46102001)(16236675002)(76482001)(77982001)(50986999)(77096999)(54356999)(99286001)(76176999)(99396002)(33646001)(76576001)(42262001)(9984715005)(24736002)(19621445023); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB312; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; Content-Type: multipart/alternative; boundary="_000_331551c46fc642a18132324510f0da99BLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/1gHWrzLnmY82QTWg_G3rra5-6do Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 08:31:01 -0000 --_000_331551c46fc642a18132324510f0da99BLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGF2ZSBubyBpZGVhIHdoYXQgeW91IGFyZSBzYXlpbmcgaGVyZSwgbm90IGFza2luZyB0byBmb3Ig ZXJyYXRhIG9uIHRoZSBSRkMNCg0KRnJvbTogSm9obiBCcmFkbGV5IFttYWlsdG86dmU3anRiQHZl N2p0Yi5jb21dDQpTZW50OiBUaHVyc2RheSwgTWF5IDE1LCAyMDE0IDE6MjcgQU0NClRvOiBBbnRo b255IE5hZGFsaW4NCkNjOiBQaGlsIEh1bnQ7IE9BdXRoIFdHDQpTdWJqZWN0OiBSZTogW09BVVRI LVdHXSBPQXV0aCBNaWxlc3RvbmUgVXBkYXRlIGFuZCBSZWNoYXJ0ZXJpbmcNCg0KT0F1dGggY292 ZXJzIGF1dGhlbnRpY2F0aW9uIGluIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24NCg0KVGhpcyB3YXMg ZGViYXRlZCBpbiB0aGUgV0cgYXQgdGhlIHRpbWUuDQoNCkp1c3Qgc2F5IHRoYXQgeW91IHdhbnQg dG8gcmVvcGVuIHRoZSBSRkMuDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gTWF5IDE1LCAy MDE0LCBhdCA5OjAzIEFNLCBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbTxt YWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpTbyBPYXV0aCBhbHJlYWR5IHRy ZWFkcyBpbnRvIHRoZSBhdXRoZW50aWNhdGlvbiBzcGFjZSB0byBzb21lIGV4dGVudCBhbmQgZW5v dWdoIG9mIGFuIGV4dGVudCB0byBjcmVhdGUgYWRkaXRpb25hbCBzZWN1cml0eSBpc3N1ZXMgYW5k IHRocmVhdHMuDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEpvaG4gQnJhZGxleQ0KU2VudDogV2VkbmVzZGF5LCBNYXkgMTQsIDIwMTQg MTA6MzIgUE0NClRvOiBQaGlsIEh1bnQNCkNjOiBPQXV0aCBXRw0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gT0F1dGggTWlsZXN0b25lIFVwZGF0ZSBhbmQgUmVjaGFydGVyaW5nDQoNCk5vLg0KDQpP QXV0aCByZXF1aXJlcyB0aGF0IGlmIHlvdSB1c2UgdGhlIGNvZGUgcmVzcG9uc2UgdHlwZSwgdGhl IHRva2VuIGVuZHBvaW50IG11c3QgcmV0dXJuIGFuIGFjY2VzcyB0b2tlbi4NCg0KQ29ubmVjdCBk b3Nlbid0IHJlcXVpcmUgYSB1c2VyX2luZm8gZW5kcG9pbnQuDQoNCkluIHRoZSByZXNwb25zZV90 eXBlICJpZF90b2tlbiIgIG9ubHkgYSBpZF90b2tlbiBpcyByZXR1cm5lZCBpbiB0aGUgZnJvbnQg Y2hhbm5lbCBpbiBhIG1hbm5lciBzaW1pbGFyIHRvIFNBTUwgUE9TVCBiaW5kaW5nIGJ1dCBmcmFn bWVudCBlbmNvZGVkIGJ5IGRlZmF1bHQuDQoNClNvIHRoZXJlIGlzIGEgZmxvdyBpbiBDb25uZWN0 IHRoYXQgZG9lc24ndCBkZWxpdmVyIGFuIGFjY2VzcyB0b2tlbi4NCg0KSSB0aGluayB0aGlzIGRp c2N1c3Npb24gaXMgbW9yZSBhYm91dCB3aGF0IGNoYW5nZXMgeW91IHdhbnQgdG8gdGhlIGNvcmUg b2YgT0F1dGguDQoNCkNvbm5lY3Qgd29ya2VkIGFyb3VuZCB0aGUgT0F1dGggc3BlYyB0byBiZSBj b21wYXRpYmxlIHdpdGggaXQuDQoNCk9ubHkgdGhlIE9BdXRoIFdHIGNhbiBjaGFuZ2UgT0F1dGgg YW5kIHRoYXQgc2VlbXMgdG8gYmUgd2hhdCB5b3Ugd2FudC4NCmE0YyBpcyBhIGp1c3RpZmljYXRp b24gZm9yIG1ha2luZyB0aG9zZSBjaGFuZ2VzLg0KDQpXZSBzaG91bGQgcHJvYmFibHkgZm9jdXMg b24gdGhlIGNvcmUgaXNzdWUgb2Ygd2hhdCBjaGFuZ2VzIHRvIFJGQyA2NzQ5IHlvdSBhcmUgYWZ0 ZXIsIHRvIGRldGVybWluZSBpZiB0aGUgV0cgd2FudHMgdG8gY2hhbmdlIHRoZSBjaGFydGVyLg0K DQpJIHRoaW5rIGZvY3VzaW5nIG9uIGE0YyBpcyBhIHJlYWQgaGVycmluZy4NCg0KSm9obiBCLg0K DQpPbiBNYXkgMTUsIDIwMTQsIGF0IDY6NTUgQU0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNs ZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCg0KDQpJIHRoaW5r IHRob3NlIGFyZSB0aGluZ3MgdG8gZGlzY3VzcyBpZiB0aGUgYXV0aGVuIGlzIG9uIHRoZSBjaGFy dGVyLg0KDQpTbyB3ZSBoYXZlIG5vdyBjbGFyaWZpZWQgdGhhdCB0aGUgYmFzaWMgY29ubmVjdCBw cm9maWxlIGRvZXNuJ3QgZG8ganVzdCBhdXRoZW4gYW5kIHJlcXVpcmVzIGlkZW50aXR5IHByb2Zp bGUgc2VydmljZXMuDQoNClBoaWwNCg0KT24gTWF5IDE0LCAyMDE0LCBhdCAxODo1NywgSnVzdGlu IFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToN ClJpZ2h0LCBzbyBpbnN0ZWFkIG9mIGJlaW5nIGFibGUgdG8gdXNlIG15IGF1dGhvcml6YXRpb24g ZW5kcG9pbnQsIHdoaWNoIGFscmVhZHkgYXV0aGVudGljYXRlcyB0aGUgdXNlciBhbmQgY2FuIGdh dGhlciBjb25zZW50LCBJIG5lZWQgdG8gaW1wbGVtZW50IGEgbmV3IGVuZHBvaW50IHRoYXQncyBu b3QtcXVpdGUtT0F1dGggYnV0IGlzIGFsbW9zdCBsaWtlIGl0LiBCdXQgaXQncyBlbm91Z2ggdG8g YmUgY29uZnVzaW5nIGJlY2F1c2Ugc29tZXRpbWVzIEkgZ28gdG8gdGhpcyBuZXcgZW5kcG9pbnQg ZW5kcG9pbnQgYW5kIGFsc28gZ2V0IGFuIGFjY2VzcyB0b2tlbiBhbnl3YXksIHRvIHVzZSBzb21l d2hlcmUgdGhhdCBJJ20gbm90IHN1cmUgd2hlcmUuIEFuZCBJJ20gbm90IHN1cmUgSSBjYW4gY29s bGFwc2UgdGhlIHR3byBlbmRwb2ludHMgYW5kIHJlLXVzZSBteSBPQXV0aCBpbmZyYXN0cnVjdHVy ZS4gQWZ0ZXIgYWxsLCBJIHN0aWxsIG5lZWQgdG8gdXNlIHRoZSB0b2tlbiBlbmRwb2ludCwgYW5k IGJ5IHRoYXQgcG9pbnQgbXkgc2VydmVyIG5lZWRzIHRvIGtub3cgd2hpY2ggZW5kcG9pbnQgdGhl IHVzZXIgd2VudCB0byBpbiB0aGUgZmlyc3QgcGxhY2UgdG8gbWFrZSB0aGF0IHN3aXRjaC4gQXMg YSBkZXZlbG9wZXIsIHRoaXMgYWxsIHNvdW5kcyBob3JyaWJseSBjb252b2x1dGVkIGFuZCBjb21w bGljYXRlZCB0byB0cmFjay4gRG8gSSBnZXQgdG8gcmUtdXNlIGFueSBvZiB0aGUgY29tcG9uZW50 cyBmcm9tIGFuIGF1dGhvcml6YXRpb24gZW5kcG9pbnQ/IEhvdyBkbyBJIGtub3cgd2hldGhlciBv ciBub3QgdG8gaXNzdWUgdGhlIGFjY2VzcyB0b2tlbiBpZiB0aGUgdXNlciBnb2VzIHRvIHRoZSBh dXRoZW50aWNhdGlvbiBlbmRwb2ludD8gQW5kIHRoZW4gdGhlcmUgYXJlIHRoZSBvcHRpbWl6YXRp b25zIGZvciBleGlzdGluZyB3ZWxsLWtub3duIGFuZCB3ZWxsLXVuZGVyc3Rvb2QgdXNlIGNhc2Vz OiB3aGF0IGlmIG15IGNsaWVudCBpcyBzaXR0aW5nIGluIHRoZSBzYW1lIGJyb3dzZXIgc2Vzc2lv biBhbmQganVzdCB3YW50cyB0byBnZXQgdGhlIHVzZXIgYXNzZXJ0aW9uIGRpcmVjdGx5IGluc3Rl YWQgb2YgZ29pbmcgdGhyb3VnaCBhIHJvdW5kIHRyaXA/IERvIEkgbmVlZCB0byBtYWtlIHR3byBy b3VuZCB0cmlwcyBpZiBJJ20gZ2V0dGluZyBhIHByb3RlY3RlZCBBUEkgYXQgdGhlIHNhbWUgdGlt ZSBhcyBhdXRobiBkYXRhPyBDYW4gSSB1c2UgdGhlIHNhbWUgcmVzcG9uc2VfdHlwZSBmdW5jdGlv bmFsaXR5IGFuZCBvdGhlciBleHRlbnNpb25zIG9uIHRoZSBhdXRoZW50aWNhdGlvbiBlbmRwb2lu dD8NCg0KSW4gdGhlIGVuZCwgdGhlIGE0YyBkcmFmdCBpc24ndCBPQXV0aCwgaXQncyBvbmx5IE9B dXRoLWxpa2UsIHdoaWNoIGlzIGRhbmdlcm91cyBhbmQgY29uZnVzaW5nIGFuZCBub3Qgc29tZXRo aW5nIEkgdGhpbmsgdGhlIE9BdXRoIFdHIHNob3VsZCBiZSBhIHBhcnQgb2YuIEFuZCBJIHJlYWxs eSBqdXN0IGRvbid0IHNlZSB0aGUgcG9pbnQgb2YgaXQsIHVubGVzcyB0aGUgZ29hbCBpcyB0byBw b2xsdXRlIHRoZSBzdGFuZGFyZHMgc3BhY2Ugd2hpY2ggQ29ubmVjdCBjdXJyZW50bHkgb2NjdXBp ZXMuIElzIENvbm5lY3QgcGVyZmVjdD8gSGVjayBuby4gQnV0IGl0J3MgZmFyIGFuZCBhd2F5IHRo ZSBiZXN0IHRoaW5nIHdlJ3ZlIGhhZCBpbiBhIGxvbmcgdGltZSwgYW5kIGl0IGFscmVhZHkgZG9l cyBldmVyeSBzaW5nbGUgdGhpbmcgeW91IGFyZSBhc2tpbmcgZm9yIGZyb20gdGhpcyBuZXcgZHJh ZnQuDQoNCiAtLSBKdXN0aW4NCg0KT24gNS8xNC8yMDE0IDk6NDMgUE0sIFBoaWwgSHVudCB3cm90 ZToNClNvcnJ5IEkgbWVhbnQgdG8gc2F5IHRoaXMgaXMgd2h5IGl0IGhhcyB0aGUgL2F1dGhlbnRp Y2F0ZSBlbmRwb2ludCB0byBpbmRpY2F0ZSB0aGUgY2xpZW50IG9ubHkgd2FudHMgdGhlIHVzZXJz IHNlc3Npb24gaW5mb3JtYXRpb24uDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRl cGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz4NCnBoaWwuaHVudEBv cmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCk9uIE1heSAxNCwg MjAxNCwgYXQgNjo0MiBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCg0KDQoNClJpZ2h0LiAgVGhpcyBpcyB3aHkg aXQgaGFzIGEgZGlmZmVyZW50IHBvaW50IGJlY2F1c2UgdGhlIGNsaWVudCBkb2VzIE5PVCB3YW50 IGEgcmVzb3VyY2UgdG9rZW4uDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVu ZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz4NCnBoaWwuaHVudEBvcmFj bGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCk9uIE1heSAxNCwgMjAx NCwgYXQgNjo0MSBQTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmlj aGVyQG1pdC5lZHU+PiB3cm90ZToNCg0KDQoNCkFjdHVhbGx5LCBpdCdzIGFib3V0IE9BdXRoIGNv bXBhdGliaWxpdHkuIFdpdGggT0F1dGgsIHlvdSBnZXQgYW4gYWNjZXNzIHRva2VuIHRvIGJlIHVz ZWQgYXQgYSBwcm90ZWN0ZWQgcmVzb3VyY2UuIFRoYXQncyB3aGF0IGl0J3MgZm9yLCB0aGF0J3Mg d2hhdCBjbGllbnRzIGRvIHRoZSBPQXV0aCBkYW5jZShzKSBmb3IuIENvbm5lY3QgZGVmaW5lcyB0 aGF0IHByb3RlY3RlZCByZXNvdXJjZSBhcyB0aGUgdXNlcmluZm8gZW5kcG9pbnQgKGllLCAidGVs bHMgdGhlIGNsaWVudCB3aGF0IHRvIGRvIHdpdGggaXQiKS4gQ29ubmVjdCBhbHNvIGRlZmluZXMg dGhlIGlkIHRva2VuIHRoYXQgY29tZXMgaW4gYWxvbmcgc2lkZSBvZiB0aGUgYm9nLXN0YW5kYXJk IE9BdXRoIHRva2VuLCBhbmQgQ29ubmVjdCBpcyB0dXJuZWQgb24gYW5kIG9mZiB0aHJvdWdoIHRo ZSB1c2Ugb2YgYm9nLXN0YW5kYXJkIE9BdXRoIHNjb3Blcy4gU28gdGhhdCBtYWtlcyBpdCB2ZXJ5 LCB2ZXJ5LCB2ZXJ5IGVhc3kgdG8gdGFrZSBhbiBPQXV0aCBzZXJ2ZXIgYW5kIHR1cm4gaXQgaW50 byBhIENvbm5lY3Qgc2VydmVyLiBJIGtub3csIEkndmUgZG9uZSBqdXN0IHRoYXQsIGFuZCBJJ3Zl IHdhbGtlZCBvdGhlcnMgdGhyb3VnaCB0aGUgcHJvY2VzcyBhcyB3ZWxsLg0KDQpCdXQgdGhlIGE0 YyBkcmFmdCBpcyB1c2luZyBzb21ldGhpbmcgdGhhdCdzIGFsbW9zdC1idXQtbm90LXF1aXRlLU9B dXRoOiBZb3UgbWlnaHQgbm90IGdldCBhbiBhY2Nlc3MgdG9rZW4sIHdoaWNoIGlzIGdvaW5nIHRv IGNvbmZ1c2UgdGhlIGhlY2sgb3V0IG9mIG1vc3QgT0F1dGggY2xpZW50cyB0aGF0IEkga25vdyBz aW5jZSB0aGF0J3Mgd2hhdCB0aGV5J3JlIHRyeWluZyB0byBnZXQgYXQgaW4gdGhlIGZpcnN0IHBs YWNlLCBhbmQgdGhlcmUncyBubyByZWFsIHdheSBmb3IgYSBjbGllbnQgdG8gZGlzdGluZ3Vpc2gg aXRzIHJlcXVlc3QgZm9yIHNvbWV0aGluZyB3aXRoIGFuIGlkX3Rva2VuIHZzLiB3aXRob3V0LiBB ZGRpdGlvbmFsbHksIGluIHByYWN0aWNlLCB0aGF0IGFjY2VzcyB0b2tlbiBpcyBodWdlbHkgdXNl ZnVsLiBKdXN0IGxvb2sgYXQgYWxsIG9mIHRoZSB3ZWlyZCBPcGVuSUQyIGFuZCBPQXV0aDEgaHli cmlkIHN0dWZmIHRoYXQgcGVvcGxlIHdlcmUgdHJ5aW5nIHRvIGRvIGJhY2sgYSBmZXcgeWVhcnMg YWdvIG9uIHRvcCBvZiBhbGwgdGhlIE9wZW5JRDIgZXh0ZW5zaW9ucyAtLSB0aGlzIGlzIGV4YWN0 bHkgYmVjYXVzZSBPcGVuSUQyIHdhcyBidWlsdCBmb3IgImF1dGhlbnRpY2F0aW9uIG9ubHkiIGJl Y2F1c2UgdGhhdCdzIHdoYXQgcGVvcGxlIHRob3VnaHQgZGV2ZWxvcGVycyB3YW50ZWQsIGJ1dCBp dCB0dXJuZWQgb3V0IHRoYXQgZGV2ZWxvcGVycyB3YW50ZWQgYSB3aG9sZSBsb3QgbW9yZSB0aGFu IHRoYXQuIFRoaXMgaXMgb25lIG1haW4gcmVhc29uIHRoZSBGYWNlYm9vayBDb25uZWN0IGFuZCBU d2l0dGVyJ3MgT0F1dGgtYmFzZWQgbG9naW4gY2FtZSBhbG9uZyBhbmQgYXRlIGV2ZXJ5b25lJ3Mg bHVuY2g6IHRoZXkgZ2F2ZSB5b3UgYXV0aGVudGljYXRpb24sIGJ1dCBhbHNvIHNvbWV0aGluZyB1 c2VmdWwgYWJvdXQgdGhlIGVuZCB1c2VyLg0KDQpBbGwgc2FpZCwgaXQgc291bmRzIGxpa2UgeW91 IHdhbnQgQ29ubmVjdCBidXQgd2l0aG91dCB0aGUgVXNlckluZm8gRW5kcG9pbnQuIFlvdSdsbCBi ZSBnbGFkIHRvIGtub3cgdGhhdCB5b3UgY2FuIGFscmVhZHkgZG8gdGhhdCBhcyBwZXIgdGhlIE1U SSBkZWZpbml0aW9ucyBvZiB0aGUgc2VydmVyOg0KDQogIGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNz L29wZW5pZC1jb25uZWN0LWNvcmUtMV8wLmh0bWwjU2VydmVyTVRJDQoNCllvdSBhcmUgZnJlZSB0 byBpbXBsZW1lbnQgYSBTQ0lNIGVuZHBvaW50ICh3aGljaCwgYnkgdGhlIHdheSwgeW91J2xsIHBy b2JhYmx5IG5lZWQgdGhhdCBhY2Nlc3NfdG9rZW4gdG8gYWNjZXNzKSBvciBubyBlbmRwb2ludCBh dCBhbGwsIGFuZCBhIGNvbXBsaWFudCBjbGllbnQgb3VnaHQgdG8gYmUgYWJsZSB0byBkZWFsIHdp dGggdGhhdC4gSW4gZmFjdCwgdGhlcmUncyBhIHdheSB0byBnZXQganVzdCB0aGUgaWRfdG9rZW4g aW4gQ29ubmVjdCBpZiB0aGF0J3MgYWxsIHlvdSBjYXJlIGFib3V0LCBidXQgaW5zdGVhZCBvZiBo aWRpbmcgaXQgaW5zaWRlIG9mIGFuIGV4aXN0aW5nIGZsb3cgdGhhdCBtaWdodCByZXR1cm4gc29t ZXRoaW5nIGRpZmZlcmVudCBkZXBlbmRpbmcgb24gKGN1cnJlbnRseS11bmRlZmluZWQpIHNwZWNp YWwgY2lyY3Vtc3RhbmNlcywgaXQgcHV0cyB0aGlzIG1vZGUgaW50byBhIHNlcGFyYXRlIHJlc3Bv bnNlX3R5cGUgZW50aXJlbHkgdG8gZW5mb3JjZSB0aGUgcG9pbnQgdGhhdCBpdCBpcyBkaWZmZXJl bnQgZnJvbSByZWd1bGFyIE9BdXRoLg0KDQogLS0gSnVzdGluDQoNCk9uIDUvMTQvMjAxNCA5OjI0 IFBNLCBQaGlsIEh1bnQgd3JvdGU6DQpJdCBpc27igJl0IHJlcXVpcmVkIChvciBzaG91bGQgbm90 IGJlKS4gIFRoaXMgaXNzdWUgaXMgT0lEQyBjb21wYXRpYmlsaXR5Lg0KDQpQaGlsDQoNCkBpbmRl cGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlk LmNvbS8+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+ DQoNCg0KDQpPbiBNYXkgMTQsIDIwMTQsIGF0IDY6MjEgUE0sIEp1c3RpbiBSaWNoZXIgPGpyaWNo ZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQoNCg0KDQpIb3cgaXMg dGhpcyBmdW5jdGlvbmFsbHkgZGlmZmVyZW50IGZyb20gdGhlIGE0YyBkcmFmdCB0aGF0IGFsc28g YWxsb3dzIHRoZSByZXR1cm4gb2YgYm90aCBhbiBpZF90b2tlbiBhbmQgYW4gYWNjZXNzIHRva2Vu Pw0KDQogLS0gSnVzdGluDQoNCk9uIDUvMTQvMjAxNCA5OjE4IFBNLCBQaGlsIEh1bnQgd3JvdGU6 DQpUaGF04oCZcyBub3QgYSBtaW5pbWFsaXN0aWMgYXV0aG4gb25seSBwcm9maWxlLg0KDQpJZiB5 b3UgcmV0dXJuIGJvdGggYW4gYWNjZXNzIHRva2VuIEFORCBhbiBpZCB0b2tlbiB0aGFuIHRoZSBz ZXJ2aWNlIHByb3ZpZGUgaGFzIHRvIGltcGxlbWVudCBib3RoIGFuZCB0aGUgY2xpZW50IGhhcyB0 byBmaWd1cmUgb3V0IHdoYXQgdG8gZG8gd2l0aCBpdC4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRp ZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0K cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0K T24gTWF5IDE0LCAyMDE0LCBhdCA1OjQ0IFBNLCBDaHVjayBNb3J0aW1vcmUgPGNtb3J0aW1vcmVA c2FsZXNmb3JjZS5jb208bWFpbHRvOmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20+PiB3cm90ZToN Cg0KDQoNCiJJIGhhZCBwZXJzb25hbGx5IHJlcXVlc3RlZCB0aGUgT0lEQyBjb21tdW5pdHkgYWJv dXQgc2l4IG1vbnRocyBhZ28gdG8gZGVzY3JpYmUgc29tZSBtaW5pbWFsIHN1YnNldCB3aGljaCB3 ZSBjb3VsZCBhbGwgcmVhc29uYWJseSBpbXBsZW1lbnQuIg0KDQpJIGJlbGlldmUgeW91J3JlIGxv b2tpbmcgZm9yIHRoaXM6IGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWJh c2ljLTFfMC5odG1sDQoNCi1jbW9ydA0KDQoNCg0KT24gV2VkLCBNYXkgMTQsIDIwMTQgYXQgNToz NyBQTSwgUHJhdGVlayBNaXNocmEgPHByYXRlZWsubWlzaHJhQG9yYWNsZS5jb208bWFpbHRvOnBy YXRlZWsubWlzaHJhQG9yYWNsZS5jb20+PiB3cm90ZToNCkFuaWwsDQoNCnRoZSBjaGFsbGVuZ2Ug aXMgdGhhdCBPSURDIGlzIGEgcmF0aGVyIGxhcmdlIHNldCBvZiBzcGVjaWZpY2F0aW9ucywgYW5k IHRvIG15IGtub3dsZWRnZSBldmVuIHRoZSBjb3JlIHNwZWNpZmljYXRpb24gaGFzIE5PVCBmb3Vu ZA0KYSBjb21wbGV0ZSBpbXBsZW1lbnRhdGlvbiBhdCBhbnkgbGFyZ2UgSWRQLiBJIGFtIG5vdCB0 YWxraW5nIGhlcmUgYWJvdXQgYm91dGlxdWUgdG9vbGtpdHMgb3Igc3RhcnR1cHMsIEkgYW0gdGFs a2luZyBhYm91dCB0aGUgZm9sa3MNCndobyBoYXZlIDEwMHMgb2YgbWlsbGlvbnMgb2YgdXNlcnMu IEFuZCwgQlRXLCBpbXBsZW1lbnRpbmcgYSBmZXcgYXJiaXRyYXJpbHkgc2VsZWN0ZWQgZmVhdHVy ZXMgZnJvbSBPSURDIGlzIG5vdCB0aGUgc2FtZSBhcyBpbXBsZW1lbnRpbmcgT0lEQy4NCg0KQXMg d2UgYWxsIGtub3csIHRoZSBjb3JlIHByb2JsZW0gaXMgdGhhdCBvZiBhZGRpbmcgYW4gYXV0aGVu dGljYXRvciB0b2tlbiB0byBPQXV0aCBmbG93cywgd2hpY2ggaXMgYSByYXRoZXIgbW9kZXN0IGV4 dGVuc2lvbiB0byBPQXV0aC4NCg0KSSBoYWQgcGVyc29uYWxseSByZXF1ZXN0ZWQgdGhlIE9JREMg Y29tbXVuaXR5IGFib3V0IHNpeCBtb250aHMgYWdvIHRvIGRlc2NyaWJlIHNvbWUgbWluaW1hbCBz dWJzZXQgd2hpY2ggd2UgY291bGQgYWxsIHJlYXNvbmFibHkgaW1wbGVtZW50LiBJIHdhcyB0b2xk IHRoYXQgIHRoZSBzcGVjaWZpY2F0aW9uIHdhcyAibG9ja2VkIGRvd24iIGFuZCBmdWxseSBkZWJ1 Z2dlZCBhbmQgc28gb24sIHNvIG5vIGNoYW5nZXMgY291bGQgYmUgbWFkZS4gSW1hZ2luZSBteSBz dXJwcmlzZSB0byBmaW5kIHRoYXQgaW4gdGhlIGZpbmFsIGRyYWZ0cyB0aGVyZSB3YXMgYSB3aG9s ZSBuZXcgZmxvdyAtIHRoZSBoeWJyaWQgZmxvdyAtIHRoYXQgaGFkIGJlZW4gYWRkZWQgYXQgdGhl IGxhc3QgbWludXRlLiBJIGhhZCBuZXZlciBoZWFyZCBvZiB0aGUgaHlicmlkIGZsb3cgaW4gdGhl IE9BdXRoIGNvbnRleHQgLSBoYXZlIHlvdT8gU28gbm93IHlvdSBoYXZlIGFuIGV2ZW4gbGFyZ2Vy IHNwZWNpZmljYXRpb24hDQoNClRoZSB2YWx1ZSBvZiBkcmFmdC1odW50LW9hdXRoLXYyLXVzZXIt YTRjLTAxIGlzIHRoYXQgaXQgZGVzY3JpYmVzIHByZWNpc2VseSBhIG1pbmltYWwgZXh0ZW5zaW9u IHRvIE9BdXRoIGZsb3dzIHRvIHN1cHBvcnQgYW4gYXV0aGVudGljYXRvciB0b2tlbi4gIEluIG15 IGV4cGVyaWVuY2UsIHRoaXMgaXMgdGhlIHN1YnNldCB0aGF0IG1vc3QgY3VzdG9tZXJzIGFuZCBp bXBsZW1lbnRvcnMgYXJlIGxvb2tpbmcgZm9yLg0KDQoNCi0gcHJhdGVlaw0KDQoNCg0KDQoNClRv bnkvUGhpbCwNCiAgYW55IGNoYW5jZSB5b3UgY2FuIGhhdmUgdGhpcyB3b3JrIGRvbmUgYXQgT0lE Qz8NCg0KVGhlIHJlYXNvbiBpcyB0aGF0IGl0IGlzIGNvbW1vbmx5IHVuZGVyc3Rvb2QvYWNjZXB0 ZWQgbm93IHRoYXQgT0F1dGggcHJvdmlkZXMgYXV0aG9yaXphdGlvbiByZWxhdGVkIHNwZWNzIHdo aWxlIGF1dGhlbnRpY2F0aW9uL3Byb2ZpbGUNCnJlbGF0ZWQgc3BlY3MgYXJlIGNvbWluZyBmcm9t IE9JREMgKHdoaWNoIGJ1aWxkcyBvbiB0b3Agb2YgT0F1dGgyKS4NCg0KUmVnYXJkcywNCkFuaWwN Cg0KT24gMDUvMTQvMjAxNCAxMDo0NyBBTSwgQW50aG9ueSBOYWRhbGluIHdyb3RlOg0KSSBhZ3Jl ZSB3aXRoIFBoaWwgb24gdGhpcyBvbmUsIHRoZXJlIGFyZSBpbXBsZW1lbnRhdGlvbnMgb2YgdGhp cyBhbHJlYWR5IGFuZCBtdWNoIGludGVyZXN0DQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWwgSHVudA0KU2VudDogV2VkbmVzZGF5 LCBNYXkgMTQsIDIwMTQgODozMiBBTQ0KVG86IEJyaWFuIENhbXBiZWxsDQpDYzogb2F1dGhAaWV0 Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1 dGggTWlsZXN0b25lIFVwZGF0ZSBhbmQgUmVjaGFydGVyaW5nDQoNCk9uIHRoZSBjb250cmFyeS4g SSBhbmQgb3RoZXJzIGFyZSBpbnRlcmVzdGVkLg0KDQpXZSBhcmUgd2FpdGluZyBmb3IgdGhlIGNo YXJ0ZXIgdG8gcGljayB1cCB0aGUgd29yay4NCg0KUmVnYXJkbGVzcyB0aGVyZSB3aWxsIGJlIGEg bmV3IGRyYWZ0IHNob3J0bHkuDQoNClBoaWwNCg0KT24gTWF5IDE0LCAyMDE0LCBhdCA1OjI0LCBC cmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQpJIHdvdWxkIG9iamVjdCB0byAnT0F1dGggQXV0 aGVudGljYXRpb24nIGJlaW5nIHBpY2tlZCB1cCBieSB0aGUgV0cgYXMgYSB3b3JrIGl0ZW0uIFRo ZSBzdGFydGluZyBwb2ludCBkcmFmdCBoYXMgZXhwaXJlZCBhbmQgaXQgaGFzbid0IHJlYWxseSBi ZWVuIGRpc2N1c3NlcyBzaW5jZSBCZXJsaW4gbmVhcmx5IGEgeWVhciBhZ28uICBBcyBJIHJlY2Fs bCwgdGhlcmUgd2FzIG9ubHkgdmVyeSBsaW1pdGVkIGludGVyZXN0IGluIGl0IGV2ZW4gdGhlbi4g SSBhbHNvIGRvbid0IGJlbGlldmUgaXQgZml0cyB3ZWxsIHdpdGggdGhlIFdHIGNoYXJ0ZXIuDQoN Ckkgd291bGQgc3VnZ2VzdCB0aGUgV0cgY29uc2lkZXIgcGlja2luZyB1cCAnT0F1dGggU3ltbWV0 cmljIFByb29mIG9mIFBvc3Nlc3Npb24gZm9yIENvZGUgRXh0ZW5zaW9uJyBmb3Igd2hpY2ggdGhl cmUgaXMgYW4gZXhjZWxsZW50IHN0YXJ0aW5nIHBvaW50IG9mIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLXRjc2UtMDMgLSBpdCdzIGEgcmVsYXRpdml0eSBz aW1wbGUgc2VjdXJpdHkgZW5oYW5jZW1lbnQgd2hpY2ggYWRkcmVzc2VzIHByb2JsZW1zIGN1cnJl bnRseSBiZWluZyBlbmNvdW50ZXJlZCBpbiBkZXBsb3ltZW50cyBvZiBuYXRpdmUgY2xpZW50cy4N Cg0KT24gVGh1LCBNYXkgOCwgMjAxNCBhdCAzOjA0IFBNLCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFu bmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4+ IHdyb3RlOg0KSGkgYWxsLA0KDQp5b3UgbWlnaHQgaGF2ZSBzZWVuIHRoYXQgd2UgcHVzaGVkIHRo ZSBhc3NlcnRpb24gZG9jdW1lbnRzIGFuZCB0aGUgSldUDQpkb2N1bWVudHMgdG8gdGhlIElFU0cg dG9kYXkuIFdlIGhhdmUgYWxzbyB1cGRhdGVkIHRoZSBtaWxlc3RvbmVzIG9uIHRoZQ0KT0F1dGgg V0cgcGFnZS4NCg0KVGhpcyBtZWFucyB0aGF0IHdlIGNhbiBwbGFuIHRvIHBpY2sgdXAgbmV3IHdv cmsgaW4gdGhlIGdyb3VwLg0KV2UgaGF2ZSBzZW50IGEgcmVxdWVzdCB0byBLYXRobGVlbiB0byBj aGFuZ2UgdGhlIG1pbGVzdG9uZSBmb3IgdGhlIE9BdXRoDQpzZWN1cml0eSBtZWNoYW5pc21zIHRv IHVzZSB0aGUgcHJvb2Ytb2YtcG9zc2Vzc2lvbiB0ZXJtaW5vbG9neS4NCg0KV2UgYWxzbyBleHBl Y3QgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIHRoZSBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24N CnNwZWMgaW5jb3Jwb3JhdGluZyBsYXN0IGNhbGwgZmVlZGJhY2sgd2l0aGluIGFib3V0IDIgd2Vl a3MuDQoNCldlIHdvdWxkIGxpa2UgeW91IHRvIHRoaW5rIGFib3V0IGFkZGluZyB0aGUgZm9sbG93 aW5nIG1pbGVzdG9uZXMgdG8gdGhlDQpjaGFydGVyIGFzIHBhcnQgb2YgdGhlIHJlLWNoYXJ0ZXJp bmcgZWZmb3J0Og0KDQotLS0tLQ0KDQpOb3YgMjAxNCBTdWJtaXQgJ1Rva2VuIGludHJvc3BlY3Rp b24nIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzIGENClByb3Bvc2VkIFN0YW5kYXJk DQpTdGFydGluZyBwb2ludDogPGRyYWZ0LXJpY2hlci1vYXV0aC1pbnRyb3NwZWN0aW9uLTA0Pg0K DQpKYW4gMjAxNSBTdWJtaXQgJ09BdXRoIEF1dGhlbnRpY2F0aW9uJyB0byB0aGUgSUVTRyBmb3Ig Y29uc2lkZXJhdGlvbiBhcw0KYSBQcm9wb3NlZCBTdGFuZGFyZA0KU3RhcnRpbmcgcG9pbnQ6IDxk cmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTAxPg0KDQpKYW4gMjAxNSBTdWJtaXQgJ1Rva2Vu IEV4Y2hhbmdlJyB0byB0aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBhcyBhDQpQcm9wb3NlZCBT dGFuZGFyZA0KU3RhcnRpbmcgcG9pbnQ6IDxkcmFmdC1qb25lcy1vYXV0aC10b2tlbi1leGNoYW5n ZS0wMD4NCg0KLS0tLS0NCg0KV2UgYWxzbyB1cGRhdGVkIHRoZSBjaGFydGVyIHRleHQgdG8gcmVm bGVjdCB0aGUgY3VycmVudCBzaXR1YXRpb24uIEhlcmUNCmlzIHRoZSBwcm9wb3NlZCB0ZXh0Og0K DQotLS0tLQ0KDQpDaGFydGVyIGZvciBXb3JraW5nIEdyb3VwDQoNCg0KVGhlIFdlYiBBdXRob3Jp emF0aW9uIChPQXV0aCkgcHJvdG9jb2wgYWxsb3dzIGEgdXNlciB0byBncmFudCBhDQp0aGlyZC1w YXJ0eSBXZWIgc2l0ZSBvciBhcHBsaWNhdGlvbiBhY2Nlc3MgdG8gdGhlIHVzZXIncyBwcm90ZWN0 ZWQNCnJlc291cmNlcywgd2l0aG91dCBuZWNlc3NhcmlseSByZXZlYWxpbmcgdGhlaXIgbG9uZy10 ZXJtIGNyZWRlbnRpYWxzLA0Kb3IgZXZlbiB0aGVpciBpZGVudGl0eS4gRm9yIGV4YW1wbGUsIGEg cGhvdG8tc2hhcmluZyBzaXRlIHRoYXQNCnN1cHBvcnRzIE9BdXRoIGNvdWxkIGFsbG93IGl0cyB1 c2VycyB0byB1c2UgYSB0aGlyZC1wYXJ0eSBwcmludGluZyBXZWINCnNpdGUgdG8gcHJpbnQgdGhl aXIgcHJpdmF0ZSBwaWN0dXJlcywgd2l0aG91dCBhbGxvd2luZyB0aGUgcHJpbnRpbmcNCnNpdGUg dG8gZ2FpbiBmdWxsIGNvbnRyb2wgb2YgdGhlIHVzZXIncyBhY2NvdW50IGFuZCB3aXRob3V0IGhh dmluZyB0aGUNCnVzZXIgc2hhcmUgaGlzIG9yIGhlciBwaG90by1zaGFyaW5nIHNpdGVzJyBsb25n LXRlcm0gY3JlZGVudGlhbCB3aXRoDQp0aGUgcHJpbnRpbmcgc2l0ZS4NCg0KVGhlIE9BdXRoIDIu MCBwcm90b2NvbCBzdWl0ZSBlbmNvbXBhc3Nlcw0KDQoqIGEgcHJvdG9jb2wgZm9yIG9idGFpbmlu ZyBhY2Nlc3MgdG9rZW5zIGZyb20gYW4gYXV0aG9yaXphdGlvbg0Kc2VydmVyIHdpdGggdGhlIHJl c291cmNlIG93bmVyJ3MgY29uc2VudCwNCiogcHJvdG9jb2xzIGZvciBwcmVzZW50aW5nIHRoZXNl IGFjY2VzcyB0b2tlbnMgdG8gcmVzb3VyY2Ugc2VydmVyDQpmb3IgYWNjZXNzIHRvIGEgcHJvdGVj dGVkIHJlc291cmNlLA0KKiBndWlkYW5jZSBmb3Igc2VjdXJlbHkgdXNpbmcgT0F1dGggMi4wLA0K KiB0aGUgYWJpbGl0eSB0byByZXZva2UgYWNjZXNzIHRva2VucywNCiogc3RhbmRhcmRpemVkIGZv cm1hdCBmb3Igc2VjdXJpdHkgdG9rZW5zIGVuY29kZWQgaW4gYSBKU09OIGZvcm1hdA0KICAoSlNP TiBXZWIgVG9rZW4sIEpXVCksDQoqIHdheXMgb2YgdXNpbmcgYXNzZXJ0aW9ucyB3aXRoIE9BdXRo LCBhbmQNCiogYSBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24gcHJvdG9jb2wuDQoNClRoZSB3 b3JraW5nIGdyb3VwIGFsc28gZGV2ZWxvcGVkIHNlY3VyaXR5IHNjaGVtZXMgZm9yIHByZXNlbnRp bmcNCmF1dGhvcml6YXRpb24gdG9rZW5zIHRvIGFjY2VzcyBhIHByb3RlY3RlZCByZXNvdXJjZS4g VGhpcyBsZWQgdG8gdGhlDQpwdWJsaWNhdGlvbiBvZiB0aGUgYmVhcmVyIHRva2VuLCBhcyB3ZWxs IGFzIHdvcmsgdGhhdCByZW1haW5zIHRvIGJlDQpjb21wbGV0ZWQgb24gcHJvb2Ytb2YtcG9zc2Vz c2lvbiBhbmQgdG9rZW4gZXhjaGFuZ2UuDQoNClRoZSBvbmdvaW5nIHN0YW5kYXJkaXphdGlvbiBl ZmZvcnQgd2l0aGluIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwIHdpbGwNCmZvY3VzIG9uIGVuaGFu Y2luZyBpbnRlcm9wZXJhYmlsaXR5IGFuZCBmdW5jdGlvbmFsaXR5IG9mIE9BdXRoDQpkZXBsb3lt ZW50cywgc3VjaCBhcyBhIHN0YW5kYXJkIGZvciBhIHRva2VuIGludHJvc3BlY3Rpb24gc2Vydmlj ZSBhbmQNCnN0YW5kYXJkcyBmb3IgYWRkaXRpb25hbCBzZWN1cml0eSBvZiBPQXV0aCByZXF1ZXN0 cy4NCg0KLS0tLS0NCg0KRmVlZGJhY2sgYXBwcmVjaWF0ZWQuDQoNCkNpYW8NCkhhbm5lcyAmIERl cmVrDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQot LQ0KW1BpbmcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBJZGVudGl0eSBsb2dvXTxodHRwczovL3d3dy5waW5naWRlbnRpdHkuY29tLz4N Cg0KQnJpYW4gQ2FtcGJlbGwNClBvcnRmb2xpbyBBcmNoaXRlY3QNCkANCg0KYmNhbXBiZWxsQHBp bmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPg0KDQpbcGhv bmVdDQoNCisxIDcyMC4zMTcuMjA2MTx0ZWw6NzIwLjMxNy4yMDYxPg0KDQpDb25uZWN0IHdpdGgg dXPigKYNCg0KW3R3aXR0ZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBsb2dvXTxodHRwczovL3R3aXR0ZXIuY29tL3BpbmdpZGVudGl0 eT5beW91dHViZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGxvZ29dPGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3VzZXIvUGluZ0lkZW50 aXR5VFY+W0xpbmtlZEluICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgbG9nb108aHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2NvbXBhbnkv MjE4NzA+W0ZhY2Vib29rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgbG9nb108aHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL3BpbmdpZGVu dGl0eXBhZ2U+W0dvb2dsZSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBsb2dvXTxodHRwczovL3BsdXMuZ29vZ2xlLmNvbS91LzAvMTE0 MjY2OTc3NzM5Mzk3NzA4NTQwPltzbGlkZXNoYXJlICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxvZ29dPGh0dHA6Ly93d3cuc2xp ZGVzaGFyZS5uZXQvUGluZ0lkZW50aXR5PltmbGlwYm9hcmQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsb2dvXTxodHRwOi8vZmxpcC5p dC92akJGNz5bcnNzIGZlZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBpY29uXTxodHRwczovL3d3dy5waW5naWRlbnRpdHkuY29tL2Js b2dzLz4NCg0KDQpbUmVnaXN0ZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBmb3IgQ2xvdWQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJZGVudGl0eSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN1bW1pdCAyMDE0 IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBNb2Rlcm4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBJZGVudGl0eSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFJldm9sdXRpb24gfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE54oCTMjMgSnVseSwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAy MDE0IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBNb250ZXJleSwgQ0FdPGh0dHBzOi8vd3d3LmNsb3VkaWRlbnRpdHlzdW1taXQuY29t Lz4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K T0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1h aWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWls aW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0K T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxt YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFp bHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86 T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoDQoNCg== --_000_331551c46fc642a18132324510f0da99BLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25z b2xhczt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5 bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGF2ZSBubyBp ZGVhIHdoYXQgeW91IGFyZSBzYXlpbmcgaGVyZSwgbm90IGFza2luZyB0byBmb3IgZXJyYXRhIG9u IHRoZSBSRkM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBu YW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IEpvaG4gQnJhZGxleSBbbWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tXQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBNYXkgMTUsIDIwMTQgMToyNyBBTTxicj4NCjxiPlRvOjwvYj4gQW50 aG9ueSBOYWRhbGluPGJyPg0KPGI+Q2M6PC9iPiBQaGlsIEh1bnQ7IE9BdXRoIFdHPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIE1pbGVzdG9uZSBVcGRhdGUgYW5kIFJl Y2hhcnRlcmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PQXV0aCBjb3ZlcnMgYXV0aGVudGljYXRpb24gaW4gc2VjdXJpdHkgY29uc2lkZXJh dGlvbiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGlzIHdhcyBkZWJhdGVkIGluIHRoZSBXRyBhdCB0aGUgdGltZS4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBz YXkgdGhhdCB5b3Ugd2FudCB0byByZW9wZW4gdGhlIFJGQy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClNlbnQgZnJvbSBteSBp UGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gTWF5IDE1LCAyMDE0LCBhdCA5 OjAzIEFNLCBBbnRob255IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jv c29mdC5jb20iPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28gT2F1dGggYWxyZWFkeSB0cmVhZHMgaW50 byB0aGUgYXV0aGVudGljYXRpb24gc3BhY2UgdG8gc29tZSBleHRlbnQgYW5kIGVub3VnaCBvZiBh biBleHRlbnQgdG8gY3JlYXRlIGFkZGl0aW9uYWwgc2VjdXJpdHkgaXNzdWVzIGFuZCB0aHJlYXRz Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9u IEJlaGFsZiBPZiA8L2I+Sm9obiBCcmFkbGV5PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg TWF5IDE0LCAyMDE0IDEwOjMyIFBNPGJyPg0KPGI+VG86PC9iPiBQaGlsIEh1bnQ8YnI+DQo8Yj5D Yzo8L2I+IE9BdXRoIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRo IE1pbGVzdG9uZSBVcGRhdGUgYW5kIFJlY2hhcnRlcmluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T0F1dGggcmVxdWlyZXMgdGhhdCBpZiB5b3UgdXNlIHRoZSBjb2Rl IHJlc3BvbnNlIHR5cGUsIHRoZSB0b2tlbiBlbmRwb2ludCBtdXN0IHJldHVybiBhbiBhY2Nlc3Mg dG9rZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNvbm5lY3QgZG9zZW4ndCByZXF1aXJlIGEgdXNlcl9pbmZvIGVuZHBvaW50LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgcmVz cG9uc2VfdHlwZSAmcXVvdDtpZF90b2tlbiZxdW90OyAmbmJzcDtvbmx5IGEgaWRfdG9rZW4gaXMg cmV0dXJuZWQgaW4gdGhlIGZyb250IGNoYW5uZWwgaW4gYSBtYW5uZXIgc2ltaWxhciB0byBTQU1M IFBPU1QgYmluZGluZyBidXQgZnJhZ21lbnQgZW5jb2RlZCBieSBkZWZhdWx0LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB0aGVyZSBpcyBh IGZsb3cgaW4gQ29ubmVjdCB0aGF0IGRvZXNuJ3QgZGVsaXZlciBhbiBhY2Nlc3MgdG9rZW4uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhp bmsgdGhpcyBkaXNjdXNzaW9uIGlzIG1vcmUgYWJvdXQgd2hhdCBjaGFuZ2VzIHlvdSB3YW50IHRv IHRoZSBjb3JlIG9mIE9BdXRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Db25uZWN0IHdvcmtlZCBhcm91bmQgdGhlIE9BdXRoIHNwZWMgdG8g YmUgY29tcGF0aWJsZSB3aXRoIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Pbmx5IHRoZSBPQXV0aCBXRyBjYW4gY2hhbmdlIE9BdXRoIGFu ZCB0aGF0IHNlZW1zIHRvIGJlIHdoYXQgeW91IHdhbnQuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YTRjIGlzIGEganVzdGlmaWNhdGlv biBmb3IgbWFraW5nIHRob3NlIGNoYW5nZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHNob3VsZCBwcm9iYWJseSBmb2N1cyBvbiB0aGUg Y29yZSBpc3N1ZSBvZiB3aGF0IGNoYW5nZXMgdG8gUkZDIDY3NDkgeW91IGFyZSBhZnRlciwgdG8g ZGV0ZXJtaW5lIGlmIHRoZSBXRyB3YW50cyB0byBjaGFuZ2UgdGhlIGNoYXJ0ZXIuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgZm9j dXNpbmcgb24gYTRjIGlzIGEgcmVhZCBoZXJyaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2huIEIuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTWF5IDE1 LCAyMDE0LCBhdCA2OjU1IEFNLCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0 aGluayB0aG9zZSBhcmUgdGhpbmdzIHRvIGRpc2N1c3MgaWYgdGhlIGF1dGhlbiBpcyBvbiB0aGUg Y2hhcnRlci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U28gd2UgaGF2ZSBub3cgY2xhcmlmaWVkIHRoYXQgdGhlIGJhc2ljIGNvbm5l Y3QgcHJvZmlsZSBkb2Vzbid0IGRvIGp1c3QgYXV0aGVuIGFuZCByZXF1aXJlcyBpZGVudGl0eSBw cm9maWxlIHNlcnZpY2VzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpPbiBNYXkgMTQsIDIwMTQsIGF0IDE4OjU3LCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJt YWlsdG86anJpY2hlckBtaXQuZWR1Ij5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmlnaHQs IHNvIGluc3RlYWQgb2YgYmVpbmcgYWJsZSB0byB1c2UgbXkgYXV0aG9yaXphdGlvbiBlbmRwb2lu dCwgd2hpY2ggYWxyZWFkeSBhdXRoZW50aWNhdGVzIHRoZSB1c2VyIGFuZCBjYW4gZ2F0aGVyIGNv bnNlbnQsIEkgbmVlZCB0byBpbXBsZW1lbnQgYSBuZXcgZW5kcG9pbnQgdGhhdCdzIG5vdC1xdWl0 ZS1PQXV0aCBidXQgaXMgYWxtb3N0IGxpa2UgaXQuIEJ1dCBpdCdzIGVub3VnaCB0byBiZSBjb25m dXNpbmcNCiBiZWNhdXNlIHNvbWV0aW1lcyBJIGdvIHRvIHRoaXMgbmV3IGVuZHBvaW50IGVuZHBv aW50IGFuZCBhbHNvIGdldCBhbiBhY2Nlc3MgdG9rZW4gYW55d2F5LCB0byB1c2Ugc29tZXdoZXJl IHRoYXQgSSdtIG5vdCBzdXJlIHdoZXJlLiBBbmQgSSdtIG5vdCBzdXJlIEkgY2FuIGNvbGxhcHNl IHRoZSB0d28gZW5kcG9pbnRzIGFuZCByZS11c2UgbXkgT0F1dGggaW5mcmFzdHJ1Y3R1cmUuIEFm dGVyIGFsbCwgSSBzdGlsbCBuZWVkIHRvIHVzZSB0aGUgdG9rZW4NCiBlbmRwb2ludCwgYW5kIGJ5 IHRoYXQgcG9pbnQgbXkgc2VydmVyIG5lZWRzIHRvIGtub3cgd2hpY2ggZW5kcG9pbnQgdGhlIHVz ZXIgd2VudCB0byBpbiB0aGUgZmlyc3QgcGxhY2UgdG8gbWFrZSB0aGF0IHN3aXRjaC4gQXMgYSBk ZXZlbG9wZXIsIHRoaXMgYWxsIHNvdW5kcyBob3JyaWJseSBjb252b2x1dGVkIGFuZCBjb21wbGlj YXRlZCB0byB0cmFjay4gRG8gSSBnZXQgdG8gcmUtdXNlIGFueSBvZiB0aGUgY29tcG9uZW50cyBm cm9tIGFuIGF1dGhvcml6YXRpb24NCiBlbmRwb2ludD8gSG93IGRvIEkga25vdyB3aGV0aGVyIG9y IG5vdCB0byBpc3N1ZSB0aGUgYWNjZXNzIHRva2VuIGlmIHRoZSB1c2VyIGdvZXMgdG8gdGhlIGF1 dGhlbnRpY2F0aW9uIGVuZHBvaW50PyBBbmQgdGhlbiB0aGVyZSBhcmUgdGhlIG9wdGltaXphdGlv bnMgZm9yIGV4aXN0aW5nIHdlbGwta25vd24gYW5kIHdlbGwtdW5kZXJzdG9vZCB1c2UgY2FzZXM6 IHdoYXQgaWYgbXkgY2xpZW50IGlzIHNpdHRpbmcgaW4gdGhlIHNhbWUgYnJvd3NlciBzZXNzaW9u DQogYW5kIGp1c3Qgd2FudHMgdG8gZ2V0IHRoZSB1c2VyIGFzc2VydGlvbiBkaXJlY3RseSBpbnN0 ZWFkIG9mIGdvaW5nIHRocm91Z2ggYSByb3VuZCB0cmlwPyBEbyBJIG5lZWQgdG8gbWFrZSB0d28g cm91bmQgdHJpcHMgaWYgSSdtIGdldHRpbmcgYSBwcm90ZWN0ZWQgQVBJIGF0IHRoZSBzYW1lIHRp bWUgYXMgYXV0aG4gZGF0YT8gQ2FuIEkgdXNlIHRoZSBzYW1lIHJlc3BvbnNlX3R5cGUgZnVuY3Rp b25hbGl0eSBhbmQgb3RoZXIgZXh0ZW5zaW9ucyBvbg0KIHRoZSBhdXRoZW50aWNhdGlvbiBlbmRw b2ludD8gPGJyPg0KPGJyPg0KSW4gdGhlIGVuZCwgdGhlIGE0YyBkcmFmdCBpc24ndCBPQXV0aCwg aXQncyBvbmx5IE9BdXRoLWxpa2UsIHdoaWNoIGlzIGRhbmdlcm91cyBhbmQgY29uZnVzaW5nIGFu ZCBub3Qgc29tZXRoaW5nIEkgdGhpbmsgdGhlIE9BdXRoIFdHIHNob3VsZCBiZSBhIHBhcnQgb2Yu IEFuZCBJIHJlYWxseSBqdXN0IGRvbid0IHNlZSB0aGUgcG9pbnQgb2YgaXQsIHVubGVzcyB0aGUg Z29hbCBpcyB0byBwb2xsdXRlIHRoZSBzdGFuZGFyZHMgc3BhY2Ugd2hpY2ggQ29ubmVjdA0KIGN1 cnJlbnRseSBvY2N1cGllcy4gSXMgQ29ubmVjdCBwZXJmZWN0PyBIZWNrIG5vLiBCdXQgaXQncyBm YXIgYW5kIGF3YXkgdGhlIGJlc3QgdGhpbmcgd2UndmUgaGFkIGluIGEgbG9uZyB0aW1lLCBhbmQg aXQgYWxyZWFkeSBkb2VzIGV2ZXJ5IHNpbmdsZSB0aGluZyB5b3UgYXJlIGFza2luZyBmb3IgZnJv bSB0aGlzIG5ldyBkcmFmdC48YnI+DQo8YnI+DQombmJzcDstLSBKdXN0aW48YnI+DQo8YnI+DQpP biA1LzE0LzIwMTQgOTo0MyBQTSwgUGhpbCBIdW50IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvcnJ5IEkgbWVhbnQgdG8gc2F5IHRoaXMgaXMg d2h5IGl0IGhhcyB0aGUgL2F1dGhlbnRpY2F0ZSBlbmRwb2ludCB0byBpbmRpY2F0ZSB0aGUgY2xp ZW50IG9ubHkgd2FudHMgdGhlIHVzZXJzIHNlc3Npb24gaW5mb3JtYXRpb24uDQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5QaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QGluZGVwZW5kZW50aWQ8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLyI+ d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g TWF5IDE0LCAyMDE0LCBhdCA2OjQyIFBNLCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpw aGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SaWdo dC4gJm5ic3A7VGhpcyBpcyB3aHkgaXQgaGFzIGEgZGlmZmVyZW50IHBvaW50IGJlY2F1c2UgdGhl IGNsaWVudCBkb2VzIE5PVCB3YW50IGEgcmVzb3VyY2UgdG9rZW4uDQo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5QaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+QGluZGVwZW5kZW50aWQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLyI+d3d3Lmlu ZGVwZW5kZW50aWQuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTWF5IDE0 LCAyMDE0LCBhdCA2OjQxIFBNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJp Y2hlckBtaXQuZWR1Ij5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWN0dWFsbHks IGl0J3MgYWJvdXQgT0F1dGggY29tcGF0aWJpbGl0eS4gV2l0aCBPQXV0aCwgeW91IGdldCBhbiBh Y2Nlc3MgdG9rZW4gdG8gYmUgdXNlZCBhdCBhIHByb3RlY3RlZCByZXNvdXJjZS4gVGhhdCdzIHdo YXQgaXQncyBmb3IsIHRoYXQncyB3aGF0IGNsaWVudHMgZG8gdGhlIE9BdXRoIGRhbmNlKHMpIGZv ci4gQ29ubmVjdCBkZWZpbmVzIHRoYXQgcHJvdGVjdGVkIHJlc291cmNlIGFzIHRoZSB1c2VyaW5m bw0KIGVuZHBvaW50IChpZSwgJnF1b3Q7dGVsbHMgdGhlIGNsaWVudCB3aGF0IHRvIGRvIHdpdGgg aXQmcXVvdDspLiBDb25uZWN0IGFsc28gZGVmaW5lcyB0aGUgaWQgdG9rZW4gdGhhdCBjb21lcyBp biBhbG9uZyBzaWRlIG9mIHRoZSBib2ctc3RhbmRhcmQgT0F1dGggdG9rZW4sIGFuZCBDb25uZWN0 IGlzIHR1cm5lZCBvbiBhbmQgb2ZmIHRocm91Z2ggdGhlIHVzZSBvZiBib2ctc3RhbmRhcmQgT0F1 dGggc2NvcGVzLiBTbyB0aGF0IG1ha2VzIGl0IHZlcnksIHZlcnksIHZlcnkNCiBlYXN5IHRvIHRh a2UgYW4gT0F1dGggc2VydmVyIGFuZCB0dXJuIGl0IGludG8gYSBDb25uZWN0IHNlcnZlci4gSSBr bm93LCBJJ3ZlIGRvbmUganVzdCB0aGF0LCBhbmQgSSd2ZSB3YWxrZWQgb3RoZXJzIHRocm91Z2gg dGhlIHByb2Nlc3MgYXMgd2VsbC4NCjxicj4NCjxicj4NCkJ1dCB0aGUgYTRjIGRyYWZ0IGlzIHVz aW5nIHNvbWV0aGluZyB0aGF0J3MgYWxtb3N0LWJ1dC1ub3QtcXVpdGUtT0F1dGg6IFlvdSBtaWdo dCBub3QgZ2V0IGFuIGFjY2VzcyB0b2tlbiwgd2hpY2ggaXMgZ29pbmcgdG8gY29uZnVzZSB0aGUg aGVjayBvdXQgb2YgbW9zdCBPQXV0aCBjbGllbnRzIHRoYXQgSSBrbm93IHNpbmNlIHRoYXQncyB3 aGF0IHRoZXkncmUgdHJ5aW5nIHRvIGdldCBhdCBpbiB0aGUgZmlyc3QgcGxhY2UsIGFuZCB0aGVy ZSdzIG5vDQogcmVhbCB3YXkgZm9yIGEgY2xpZW50IHRvIGRpc3Rpbmd1aXNoIGl0cyByZXF1ZXN0 IGZvciBzb21ldGhpbmcgd2l0aCBhbiBpZF90b2tlbiB2cy4gd2l0aG91dC4gQWRkaXRpb25hbGx5 LCBpbiBwcmFjdGljZSwgdGhhdCBhY2Nlc3MgdG9rZW4gaXMgaHVnZWx5IHVzZWZ1bC4gSnVzdCBs b29rIGF0IGFsbCBvZiB0aGUgd2VpcmQgT3BlbklEMiBhbmQgT0F1dGgxIGh5YnJpZCBzdHVmZiB0 aGF0IHBlb3BsZSB3ZXJlIHRyeWluZyB0byBkbyBiYWNrIGEgZmV3DQogeWVhcnMgYWdvIG9uIHRv cCBvZiBhbGwgdGhlIE9wZW5JRDIgZXh0ZW5zaW9ucyAtLSB0aGlzIGlzIGV4YWN0bHkgYmVjYXVz ZSBPcGVuSUQyIHdhcyBidWlsdCBmb3IgJnF1b3Q7YXV0aGVudGljYXRpb24gb25seSZxdW90OyBi ZWNhdXNlIHRoYXQncyB3aGF0IHBlb3BsZSB0aG91Z2h0IGRldmVsb3BlcnMgd2FudGVkLCBidXQg aXQgdHVybmVkIG91dCB0aGF0IGRldmVsb3BlcnMgd2FudGVkIGEgd2hvbGUgbG90IG1vcmUgdGhh biB0aGF0LiBUaGlzIGlzIG9uZSBtYWluDQogcmVhc29uIHRoZSBGYWNlYm9vayBDb25uZWN0IGFu ZCBUd2l0dGVyJ3MgT0F1dGgtYmFzZWQgbG9naW4gY2FtZSBhbG9uZyBhbmQgYXRlIGV2ZXJ5b25l J3MgbHVuY2g6IHRoZXkgZ2F2ZSB5b3UgYXV0aGVudGljYXRpb24sIGJ1dCBhbHNvIHNvbWV0aGlu ZyB1c2VmdWwgYWJvdXQgdGhlIGVuZCB1c2VyLjxicj4NCjxicj4NCkFsbCBzYWlkLCBpdCBzb3Vu ZHMgbGlrZSB5b3Ugd2FudCBDb25uZWN0IGJ1dCB3aXRob3V0IHRoZSBVc2VySW5mbyBFbmRwb2lu dC4gWW91J2xsIGJlIGdsYWQgdG8ga25vdyB0aGF0IHlvdSBjYW4gYWxyZWFkeSBkbyB0aGF0IGFz IHBlciB0aGUgTVRJIGRlZmluaXRpb25zIG9mIHRoZSBzZXJ2ZXI6PGJyPg0KPGJyPg0KJm5ic3A7 IDxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWNvcmUtMV8w Lmh0bWwjU2VydmVyTVRJIj5odHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1j b3JlLTFfMC5odG1sI1NlcnZlck1USTwvYT48YnI+DQo8YnI+DQpZb3UgYXJlIGZyZWUgdG8gaW1w bGVtZW50IGEgU0NJTSBlbmRwb2ludCAod2hpY2gsIGJ5IHRoZSB3YXksIHlvdSdsbCBwcm9iYWJs eSBuZWVkIHRoYXQgYWNjZXNzX3Rva2VuIHRvIGFjY2Vzcykgb3Igbm8gZW5kcG9pbnQgYXQgYWxs LCBhbmQgYSBjb21wbGlhbnQgY2xpZW50IG91Z2h0IHRvIGJlIGFibGUgdG8gZGVhbCB3aXRoIHRo YXQuIEluIGZhY3QsIHRoZXJlJ3MgYSB3YXkgdG8gZ2V0IGp1c3QgdGhlIGlkX3Rva2VuIGluIENv bm5lY3QgaWYgdGhhdCdzDQogYWxsIHlvdSBjYXJlIGFib3V0LCBidXQgaW5zdGVhZCBvZiBoaWRp bmcgaXQgaW5zaWRlIG9mIGFuIGV4aXN0aW5nIGZsb3cgdGhhdCBtaWdodCByZXR1cm4gc29tZXRo aW5nIGRpZmZlcmVudCBkZXBlbmRpbmcgb24gKGN1cnJlbnRseS11bmRlZmluZWQpIHNwZWNpYWwg Y2lyY3Vtc3RhbmNlcywgaXQgcHV0cyB0aGlzIG1vZGUgaW50byBhIHNlcGFyYXRlIHJlc3BvbnNl X3R5cGUgZW50aXJlbHkgdG8gZW5mb3JjZSB0aGUgcG9pbnQgdGhhdCBpdCBpcw0KIGRpZmZlcmVu dCBmcm9tIHJlZ3VsYXIgT0F1dGguIDxicj4NCjxicj4NCiZuYnNwOy0tIEp1c3Rpbjxicj4NCjxi cj4NCk9uIDUvMTQvMjAxNCA5OjI0IFBNLCBQaGlsIEh1bnQgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXNu4oCZdCByZXF1aXJlZCAob3Ig c2hvdWxkIG5vdCBiZSkuICZuYnNwO1RoaXMgaXNzdWUgaXMgT0lEQyBjb21wYXRpYmlsaXR5Lg0K PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlBoaWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5AaW5kZXBlbmRlbnRp ZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5k ZXBlbmRlbnRpZC5jb20vIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xl LmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBNYXkgMTQsIDIwMTQsIGF0IDY6MjEgUE0sIEp1c3RpbiBSaWNoZXIg Jmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiPmpyaWNoZXJAbWl0LmVkdTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Ib3cgaXMgdGhpcyBmdW5jdGlvbmFsbHkgZGlmZmVyZW50IGZyb20gdGhl IGE0YyBkcmFmdCB0aGF0IGFsc28gYWxsb3dzIHRoZSByZXR1cm4gb2YgYm90aCBhbiBpZF90b2tl biBhbmQgYW4gYWNjZXNzIHRva2VuPw0KPGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVzdGluPGJyPg0K PGJyPg0KT24gNS8xNC8yMDE0IDk6MTggUE0sIFBoaWwgSHVudCB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF04oCZcyBub3QgYSBtaW5pbWFs aXN0aWMgYXV0aG4gb25seSBwcm9maWxlLiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPklmIHlvdSByZXR1cm4gYm90aCBhbiBhY2Nlc3MgdG9rZW4gQU5EIGFu IGlkIHRva2VuIHRoYW4gdGhlIHNlcnZpY2UgcHJvdmlkZSBoYXMgdG8gaW1wbGVtZW50IGJvdGgg YW5kIHRoZSBjbGllbnQgaGFzIHRvIGZpZ3VyZSBvdXQgd2hhdCB0byBkbyB3aXRoIGl0LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+UGhpbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkBpbmRlcGVuZGVudGlkPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVu ZGVudGlkLmNvbS8iPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29t PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIE1heSAxNCwgMjAxNCwgYXQgNTo0NCBQTSwgQ2h1Y2sgTW9ydGltb3JlICZs dDs8YSBocmVmPSJtYWlsdG86Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbSI+Y21vcnRpbW9yZUBz YWxlc2ZvcmNlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDtJIGhhZCBwZXJzb25hbGx5IHJl cXVlc3RlZCB0aGUgT0lEQyBjb21tdW5pdHkgYWJvdXQgc2l4IG1vbnRocyBhZ28gdG8gZGVzY3Jp YmUgc29tZSBtaW5pbWFsIHN1YnNldCB3aGljaCB3ZSBjb3VsZCBhbGwgcmVhc29uYWJseSBpbXBs ZW1lbnQuJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgYmVsaWV2ZSB5b3UncmUgbG9va2luZyBmb3IgdGhpczogPGEgaHJlZj0iaHR0 cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtYmFzaWMtMV8wLmh0bWwiPg0KaHR0 cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtYmFzaWMtMV8wLmh0bWw8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1jbW9y dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdl ZCwgTWF5IDE0LCAyMDE0IGF0IDU6MzcgUE0sIFByYXRlZWsgTWlzaHJhICZsdDs8YSBocmVmPSJt YWlsdG86cHJhdGVlay5taXNocmFAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnByYXRlZWsu bWlzaHJhQG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFuaWwsPGJyPg0KPGJyPg0KdGhlIGNoYWxsZW5nZSBpcyB0aGF0IE9JREMg aXMgYSByYXRoZXIgbGFyZ2Ugc2V0IG9mIHNwZWNpZmljYXRpb25zLCBhbmQgdG8gbXkga25vd2xl ZGdlIGV2ZW4gdGhlIGNvcmUgc3BlY2lmaWNhdGlvbiBoYXMgTk9UIGZvdW5kPGJyPg0KYSBjb21w bGV0ZSBpbXBsZW1lbnRhdGlvbiBhdCBhbnkgbGFyZ2UgSWRQLiBJIGFtIG5vdCB0YWxraW5nIGhl cmUgYWJvdXQgYm91dGlxdWUgdG9vbGtpdHMgb3Igc3RhcnR1cHMsIEkgYW0gdGFsa2luZyBhYm91 dCB0aGUgZm9sa3M8YnI+DQp3aG8gaGF2ZSAxMDBzIG9mIG1pbGxpb25zIG9mIHVzZXJzLiBBbmQs IEJUVywgaW1wbGVtZW50aW5nIGEgZmV3IGFyYml0cmFyaWx5IHNlbGVjdGVkIGZlYXR1cmVzIGZy b20gT0lEQyBpcyBub3QgdGhlIHNhbWUgYXMgaW1wbGVtZW50aW5nIE9JREMuPGJyPg0KPGJyPg0K QXMgd2UgYWxsIGtub3csIHRoZSBjb3JlIHByb2JsZW0gaXMgdGhhdCBvZiBhZGRpbmcgYW4gYXV0 aGVudGljYXRvciB0b2tlbiB0byBPQXV0aCBmbG93cywgd2hpY2ggaXMgYSByYXRoZXIgbW9kZXN0 IGV4dGVuc2lvbiB0byBPQXV0aC48YnI+DQo8YnI+DQpJIGhhZCBwZXJzb25hbGx5IHJlcXVlc3Rl ZCB0aGUgT0lEQyBjb21tdW5pdHkgYWJvdXQgc2l4IG1vbnRocyBhZ28gdG8gZGVzY3JpYmUgc29t ZSBtaW5pbWFsIHN1YnNldCB3aGljaCB3ZSBjb3VsZCBhbGwgcmVhc29uYWJseSBpbXBsZW1lbnQu IEkgd2FzIHRvbGQgdGhhdCZuYnNwOyB0aGUgc3BlY2lmaWNhdGlvbiB3YXMgJnF1b3Q7bG9ja2Vk IGRvd24mcXVvdDsgYW5kIGZ1bGx5IGRlYnVnZ2VkIGFuZCBzbyBvbiwgc28gbm8gY2hhbmdlcyBj b3VsZCBiZSBtYWRlLiBJbWFnaW5lDQogbXkgc3VycHJpc2UgdG8gZmluZCB0aGF0IGluIHRoZSBm aW5hbCBkcmFmdHMgdGhlcmUgd2FzIGEgd2hvbGUgbmV3IGZsb3cgLSB0aGUgaHlicmlkIGZsb3cg LSB0aGF0IGhhZCBiZWVuIGFkZGVkIGF0IHRoZSBsYXN0IG1pbnV0ZS4gSSBoYWQgbmV2ZXIgaGVh cmQgb2YgdGhlIGh5YnJpZCBmbG93IGluIHRoZSBPQXV0aCBjb250ZXh0IC0gaGF2ZSB5b3U/IFNv IG5vdyB5b3UgaGF2ZSBhbiBldmVuIGxhcmdlciBzcGVjaWZpY2F0aW9uITxicj4NCjxicj4NClRo ZSB2YWx1ZSBvZiBkcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTAxIGlzIHRoYXQgaXQgZGVz Y3JpYmVzIHByZWNpc2VseSBhIG1pbmltYWwgZXh0ZW5zaW9uIHRvIE9BdXRoIGZsb3dzIHRvIHN1 cHBvcnQgYW4gYXV0aGVudGljYXRvciB0b2tlbi4mbmJzcDsgSW4gbXkgZXhwZXJpZW5jZSwgdGhp cyBpcyB0aGUgc3Vic2V0IHRoYXQgbW9zdCBjdXN0b21lcnMgYW5kIGltcGxlbWVudG9ycyBhcmUg bG9va2luZyBmb3IuDQo8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJy Pg0KLSBwcmF0ZWVrPC9zcGFuPiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VG9ueS9QaGlsLDxicj4NCiZuYnNwOyBhbnkgY2hhbmNlIHlvdSBjYW4gaGF2ZSB0aGlzIHdv cmsgZG9uZSBhdCBPSURDPyA8YnI+DQo8YnI+DQpUaGUgcmVhc29uIGlzIHRoYXQgaXQgaXMgY29t bW9ubHkgdW5kZXJzdG9vZC9hY2NlcHRlZCBub3cgdGhhdCBPQXV0aCBwcm92aWRlcyBhdXRob3Jp emF0aW9uIHJlbGF0ZWQgc3BlY3Mgd2hpbGUgYXV0aGVudGljYXRpb24vcHJvZmlsZTxicj4NCnJl bGF0ZWQgc3BlY3MgYXJlIGNvbWluZyBmcm9tIE9JREMgKHdoaWNoIGJ1aWxkcyBvbiB0b3Agb2Yg T0F1dGgyKS48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCkFuaWw8YnI+DQo8YnI+DQpPbiAwNS8x NC8yMDE0IDEwOjQ3IEFNLCBBbnRob255IE5hZGFsaW4gd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCBQaGlsIG9uIHRoaXMgb25lLCB0 aGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIG9mIHRoaXMgYWxyZWFkeSBhbmQgbXVjaCBpbnRlcmVz dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0i MTQ1ZmQ1MDVkMzMwZThmOF9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGggWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QaGlsIEh1bnQ8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVz ZGF5LCBNYXkgMTQsIDIwMTQgODozMiBBTTxicj4NCjxiPlRvOjwvYj4gQnJpYW4gQ2FtcGJlbGw8 YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRI LVdHXSBPQXV0aCBNaWxlc3RvbmUgVXBkYXRlIGFuZCBSZWNoYXJ0ZXJpbmc8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5PbiB0aGUgY29udHJhcnkuIEkgYW5kIG90aGVycyBhcmUgaW50ZXJlc3RlZC4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5XZSBhcmUgd2FpdGluZyBmb3IgdGhlIGNoYXJ0ZXIgdG8gcGljayB1cCB0aGUg d29yay4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRsZXNzIHRoZXJlIHdpbGwgYmUgYSBuZXcg ZHJhZnQgc2hvcnRseS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBNYXkgMTQsIDIwMTQsIGF0IDU6MjQsIEJyaWFu IENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20i IHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij5JIHdvdWxkIG9iamVjdCB0byAnT0F1dGggQXV0aGVudGljYXRpb24nIGJlaW5nIHBpY2tlZCB1 cCBieSB0aGUgV0cgYXMgYSB3b3JrIGl0ZW0uIFRoZSBzdGFydGluZyBwb2ludCBkcmFmdCBoYXMg ZXhwaXJlZCBhbmQgaXQgaGFzbid0IHJlYWxseSBiZWVuIGRpc2N1c3NlcyBzaW5jZSBCZXJsaW4g bmVhcmx5IGEgeWVhcg0KIGFnby4mbmJzcDsgQXMgSSByZWNhbGwsIHRoZXJlIHdhcyBvbmx5IHZl cnkgbGltaXRlZCBpbnRlcmVzdCBpbiBpdCBldmVuIHRoZW4uIEkgYWxzbyBkb24ndCBiZWxpZXZl IGl0IGZpdHMgd2VsbCB3aXRoIHRoZSBXRyBjaGFydGVyLjxicj4NCjxicj4NCkkgd291bGQgc3Vn Z2VzdCB0aGUgV0cgY29uc2lkZXIgcGlja2luZyB1cCAnT0F1dGggU3ltbWV0cmljIFByb29mIG9m IFBvc3Nlc3Npb24gZm9yIENvZGUgRXh0ZW5zaW9uJyBmb3Igd2hpY2ggdGhlcmUgaXMgYW4gZXhj ZWxsZW50IHN0YXJ0aW5nIHBvaW50IG9mDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC10Y3NlLTAzIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC10Y3NlLTAzPC9hPiAt IGl0J3MgYSByZWxhdGl2aXR5IHNpbXBsZSBzZWN1cml0eSBlbmhhbmNlbWVudCB3aGljaCBhZGRy ZXNzZXMgcHJvYmxlbXMgY3VycmVudGx5IGJlaW5nIGVuY291bnRlcmVkIGluIGRlcGxveW1lbnRz IG9mIG5hdGl2ZSBjbGllbnRzLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+T24gVGh1LCBNYXkgOCwgMjAxNCBhdCAzOjA0IFBNLCBIYW5uZXMgVHNjaG9mZW5pZyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiIHRhcmdldD0iX2Js YW5rIj5oYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+SGkgYWxsLDxicj4NCjxicj4NCnlvdSBtaWdodCBoYXZlIHNlZW4gdGhh dCB3ZSBwdXNoZWQgdGhlIGFzc2VydGlvbiBkb2N1bWVudHMgYW5kIHRoZSBKV1Q8YnI+DQpkb2N1 bWVudHMgdG8gdGhlIElFU0cgdG9kYXkuIFdlIGhhdmUgYWxzbyB1cGRhdGVkIHRoZSBtaWxlc3Rv bmVzIG9uIHRoZTxicj4NCk9BdXRoIFdHIHBhZ2UuPGJyPg0KPGJyPg0KVGhpcyBtZWFucyB0aGF0 IHdlIGNhbiBwbGFuIHRvIHBpY2sgdXAgbmV3IHdvcmsgaW4gdGhlIGdyb3VwLjxicj4NCldlIGhh dmUgc2VudCBhIHJlcXVlc3QgdG8gS2F0aGxlZW4gdG8gY2hhbmdlIHRoZSBtaWxlc3RvbmUgZm9y IHRoZSBPQXV0aDxicj4NCnNlY3VyaXR5IG1lY2hhbmlzbXMgdG8gdXNlIHRoZSBwcm9vZi1vZi1w b3NzZXNzaW9uIHRlcm1pbm9sb2d5Ljxicj4NCjxicj4NCldlIGFsc28gZXhwZWN0IGFuIHVwZGF0 ZWQgdmVyc2lvbiBvZiB0aGUgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uPGJyPg0Kc3BlYyBp bmNvcnBvcmF0aW5nIGxhc3QgY2FsbCBmZWVkYmFjayB3aXRoaW4gYWJvdXQgMiB3ZWVrcy48YnI+ DQo8YnI+DQpXZSB3b3VsZCBsaWtlIHlvdSB0byB0aGluayBhYm91dCBhZGRpbmcgdGhlIGZvbGxv d2luZyBtaWxlc3RvbmVzIHRvIHRoZTxicj4NCmNoYXJ0ZXIgYXMgcGFydCBvZiB0aGUgcmUtY2hh cnRlcmluZyBlZmZvcnQ6PGJyPg0KPGJyPg0KLS0tLS08YnI+DQo8YnI+DQpOb3YgMjAxNCBTdWJt aXQgJ1Rva2VuIGludHJvc3BlY3Rpb24nIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFz IGE8YnI+DQpQcm9wb3NlZCBTdGFuZGFyZDxicj4NClN0YXJ0aW5nIHBvaW50OiAmbHQ7ZHJhZnQt cmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24tMDQmZ3Q7PGJyPg0KPGJyPg0KSmFuIDIwMTUgU3Vi bWl0ICdPQXV0aCBBdXRoZW50aWNhdGlvbicgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24g YXM8YnI+DQphIFByb3Bvc2VkIFN0YW5kYXJkPGJyPg0KU3RhcnRpbmcgcG9pbnQ6ICZsdDtkcmFm dC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTAxJmd0Ozxicj4NCjxicj4NCkphbiAyMDE1IFN1Ym1p dCAnVG9rZW4gRXhjaGFuZ2UnIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzIGE8YnI+ DQpQcm9wb3NlZCBTdGFuZGFyZDxicj4NClN0YXJ0aW5nIHBvaW50OiAmbHQ7ZHJhZnQtam9uZXMt b2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDAmZ3Q7PGJyPg0KPGJyPg0KLS0tLS08YnI+DQo8YnI+DQpX ZSBhbHNvIHVwZGF0ZWQgdGhlIGNoYXJ0ZXIgdGV4dCB0byByZWZsZWN0IHRoZSBjdXJyZW50IHNp dHVhdGlvbi4gSGVyZTxicj4NCmlzIHRoZSBwcm9wb3NlZCB0ZXh0Ojxicj4NCjxicj4NCi0tLS0t PGJyPg0KPGJyPg0KQ2hhcnRlciBmb3IgV29ya2luZyBHcm91cDxicj4NCjxicj4NCjxicj4NClRo ZSBXZWIgQXV0aG9yaXphdGlvbiAoT0F1dGgpIHByb3RvY29sIGFsbG93cyBhIHVzZXIgdG8gZ3Jh bnQgYTxicj4NCnRoaXJkLXBhcnR5IFdlYiBzaXRlIG9yIGFwcGxpY2F0aW9uIGFjY2VzcyB0byB0 aGUgdXNlcidzIHByb3RlY3RlZDxicj4NCnJlc291cmNlcywgd2l0aG91dCBuZWNlc3NhcmlseSBy ZXZlYWxpbmcgdGhlaXIgbG9uZy10ZXJtIGNyZWRlbnRpYWxzLDxicj4NCm9yIGV2ZW4gdGhlaXIg aWRlbnRpdHkuIEZvciBleGFtcGxlLCBhIHBob3RvLXNoYXJpbmcgc2l0ZSB0aGF0PGJyPg0Kc3Vw cG9ydHMgT0F1dGggY291bGQgYWxsb3cgaXRzIHVzZXJzIHRvIHVzZSBhIHRoaXJkLXBhcnR5IHBy aW50aW5nIFdlYjxicj4NCnNpdGUgdG8gcHJpbnQgdGhlaXIgcHJpdmF0ZSBwaWN0dXJlcywgd2l0 aG91dCBhbGxvd2luZyB0aGUgcHJpbnRpbmc8YnI+DQpzaXRlIHRvIGdhaW4gZnVsbCBjb250cm9s IG9mIHRoZSB1c2VyJ3MgYWNjb3VudCBhbmQgd2l0aG91dCBoYXZpbmcgdGhlPGJyPg0KdXNlciBz aGFyZSBoaXMgb3IgaGVyIHBob3RvLXNoYXJpbmcgc2l0ZXMnIGxvbmctdGVybSBjcmVkZW50aWFs IHdpdGg8YnI+DQp0aGUgcHJpbnRpbmcgc2l0ZS48YnI+DQo8YnI+DQpUaGUgT0F1dGggMi4wIHBy b3RvY29sIHN1aXRlIGVuY29tcGFzc2VzPGJyPg0KPGJyPg0KKiBhIHByb3RvY29sIGZvciBvYnRh aW5pbmcgYWNjZXNzIHRva2VucyBmcm9tIGFuIGF1dGhvcml6YXRpb248YnI+DQpzZXJ2ZXIgd2l0 aCB0aGUgcmVzb3VyY2Ugb3duZXIncyBjb25zZW50LDxicj4NCiogcHJvdG9jb2xzIGZvciBwcmVz ZW50aW5nIHRoZXNlIGFjY2VzcyB0b2tlbnMgdG8gcmVzb3VyY2Ugc2VydmVyPGJyPg0KZm9yIGFj Y2VzcyB0byBhIHByb3RlY3RlZCByZXNvdXJjZSw8YnI+DQoqIGd1aWRhbmNlIGZvciBzZWN1cmVs eSB1c2luZyBPQXV0aCAyLjAsPGJyPg0KKiB0aGUgYWJpbGl0eSB0byByZXZva2UgYWNjZXNzIHRv a2Vucyw8YnI+DQoqIHN0YW5kYXJkaXplZCBmb3JtYXQgZm9yIHNlY3VyaXR5IHRva2VucyBlbmNv ZGVkIGluIGEgSlNPTiBmb3JtYXQ8YnI+DQombmJzcDsgKEpTT04gV2ViIFRva2VuLCBKV1QpLDxi cj4NCiogd2F5cyBvZiB1c2luZyBhc3NlcnRpb25zIHdpdGggT0F1dGgsIGFuZDxicj4NCiogYSBk eW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24gcHJvdG9jb2wuPGJyPg0KPGJyPg0KVGhlIHdvcmtp bmcgZ3JvdXAgYWxzbyBkZXZlbG9wZWQgc2VjdXJpdHkgc2NoZW1lcyBmb3IgcHJlc2VudGluZzxi cj4NCmF1dGhvcml6YXRpb24gdG9rZW5zIHRvIGFjY2VzcyBhIHByb3RlY3RlZCByZXNvdXJjZS4g VGhpcyBsZWQgdG8gdGhlPGJyPg0KcHVibGljYXRpb24gb2YgdGhlIGJlYXJlciB0b2tlbiwgYXMg d2VsbCBhcyB3b3JrIHRoYXQgcmVtYWlucyB0byBiZTxicj4NCmNvbXBsZXRlZCBvbiBwcm9vZi1v Zi1wb3NzZXNzaW9uIGFuZCB0b2tlbiBleGNoYW5nZS48YnI+DQo8YnI+DQpUaGUgb25nb2luZyBz dGFuZGFyZGl6YXRpb24gZWZmb3J0IHdpdGhpbiB0aGUgT0F1dGggd29ya2luZyBncm91cCB3aWxs PGJyPg0KZm9jdXMgb24gZW5oYW5jaW5nIGludGVyb3BlcmFiaWxpdHkgYW5kIGZ1bmN0aW9uYWxp dHkgb2YgT0F1dGg8YnI+DQpkZXBsb3ltZW50cywgc3VjaCBhcyBhIHN0YW5kYXJkIGZvciBhIHRv a2VuIGludHJvc3BlY3Rpb24gc2VydmljZSBhbmQ8YnI+DQpzdGFuZGFyZHMgZm9yIGFkZGl0aW9u YWwgc2VjdXJpdHkgb2YgT0F1dGggcmVxdWVzdHMuPGJyPg0KPGJyPg0KLS0tLS08YnI+DQo8YnI+ DQpGZWVkYmFjayBhcHByZWNpYXRlZC48YnI+DQo8YnI+DQpDaWFvPGJyPg0KSGFubmVzICZhbXA7 IERlcmVrPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8YnI+DQotLSA8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9y ZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDo1OS4y NXB0Ij4NCjx0ZCB3aWR0aD0iNzUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NTYuMjVwdDtw YWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0O2hlaWdodDo1OS4yNXB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly93d3cucGluZ2lkZW50aXR5LmNvbS8iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9y ZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHA6Ly80LnBpbmdpZGVudGl0eS5jb20v cnMvcGluZ2lkZW50aXR5L2ltYWdlcy9FWFBfUElDX3NxdWFyZV9sb2dvX1JHQl93aXRoX2hhcmRf ZHJvcC5wbmciIGFsdD0iUGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIElkZW50aXR5IGxvZ28iPjwvc3Bhbj48L2E+PG86cD48L286 cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVw dCAuNzVwdCA3LjVwdDtoZWlnaHQ6NTkuMjVwdCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9t OjUuMjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6I0U2MUQzQyI+QnJpYW4gQ2FtcGJlbGw8L3NwYW4+PC9iPjxicj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlBvcnRmb2xpbyBBcmNoaXRlY3Q8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg Y2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItcmlnaHQ6c29saWQgI0U2MUQzQyAxLjBwdDtwYWRkaW5nOjBpbiAzLjc1cHQgMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50 ZXIiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojRTYxRDNDIj5APC9zcGFu PjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAw aW4gMi4yNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9 Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1y aWdodDpzb2xpZCAjRTYzQzFEIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlciI+DQo8aW1n IGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyNiIgc3JjPSJodHRwOi8vNC5waW5naWRlbnRpdHku Y29tL3JzL3BpbmdpZGVudGl0eS9pbWFnZXMvRVhQX3Bob25lX2dseXBoLmdpZiIgYWx0PSJwaG9u ZSI+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGlu IDIuMjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiYjNDM7MQ0KPGEgaHJlZj0idGVsOjcyMC4zMTcuMjA2MSIgdGFyZ2V0PSJfYmxhbmsiPjcy MC4zMTcuMjA2MTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4N Cjx0ZCBjb2xzcGFuPSIyIiBzdHlsZT0icGFkZGluZzoxMS4yNXB0IC43NXB0IC43NXB0IC43NXB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojOTk5OTk5Ij5Db25uZWN0IHdpdGggdXPigKY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3Rk Pg0KPC90cj4NCjx0cj4NCjx0ZCBjb2xzcGFuPSIyIiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVw dCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8v dHdpdHRlci5jb20vcGluZ2lkZW50aXR5IiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IlBpbmcgb24N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBUd2l0dGVyIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVy PSIwIiBpZD0iX3gwMDAwX2kxMDI3IiBzcmM9Imh0dHA6Ly80LnBpbmdpZGVudGl0eS5jb20vcnMv cGluZ2lkZW50aXR5L2ltYWdlcy90d2l0dGVyLmdpZiIgYWx0PSJ0d2l0dGVyDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9nbyI+PC9z cGFuPjwvYT48YSBocmVmPSJodHRwczovL3d3dy55b3V0dWJlLmNvbS91c2VyL1BpbmdJZGVudGl0 eVRWIiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IlBpbmcgb24NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBZb3VUdWJlIj48c3BhbiBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDI4 IiBzcmM9Imh0dHA6Ly80LnBpbmdpZGVudGl0eS5jb20vcnMvcGluZ2lkZW50aXR5L2ltYWdlcy95 b3V0dWJlLmdpZiIgYWx0PSJ5b3V0dWJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9nbyI+PC9zcGFuPjwvYT48YSBocmVmPSJodHRw czovL3d3dy5saW5rZWRpbi5jb20vY29tcGFueS8yMTg3MCIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxl PSJQaW5nIG9uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTGlua2VkSW4iPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+ PGltZyBib3JkZXI9IjAiIGlkPSJfeDAwMDBfaTEwMjkiIHNyYz0iaHR0cDovLzQucGluZ2lkZW50 aXR5LmNvbS9ycy9waW5naWRlbnRpdHkvaW1hZ2VzL2xpbmtlZGluLmdpZiIgYWx0PSJMaW5rZWRJ bg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGxvZ28iPjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL3Bp bmdpZGVudGl0eXBhZ2UiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUGluZyBvbg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZhY2Vib29r Ij48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiBpZD0i X3gwMDAwX2kxMDMwIiBzcmM9Imh0dHA6Ly80LnBpbmdpZGVudGl0eS5jb20vcnMvcGluZ2lkZW50 aXR5L2ltYWdlcy9mYWNlYm9vay5naWYiIGFsdD0iRmFjZWJvb2sNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsb2dvIj48L3NwYW4+PC9h PjxhIGhyZWY9Imh0dHBzOi8vcGx1cy5nb29nbGUuY29tL3UvMC8xMTQyNjY5Nzc3MzkzOTc3MDg1 NDAiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUGluZyBvbg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdvb2dsZSYjNDM7Ij48c3BhbiBz dHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kx MDMxIiBzcmM9Imh0dHA6Ly80LnBpbmdpZGVudGl0eS5jb20vcnMvcGluZ2lkZW50aXR5L2ltYWdl cy9nb29nbGUlMkIuZ2lmIiBhbHQ9Ikdvb2dsZSYjNDM7DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9nbyI+PC9zcGFuPjwvYT48YSBo cmVmPSJodHRwOi8vd3d3LnNsaWRlc2hhcmUubmV0L1BpbmdJZGVudGl0eSIgdGFyZ2V0PSJfYmxh bmsiIHRpdGxlPSJQaW5nIG9uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgU2xpZGVTaGFyZSI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3Jh dGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAzMiIgc3JjPSJodHRwOi8v NC5waW5naWRlbnRpdHkuY29tL3JzL3BpbmdpZGVudGl0eS9pbWFnZXMvc2xpZGVzaGFyZS5naWYi IGFsdD0ic2xpZGVzaGFyZQ0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBsb2dvIj48L3NwYW4+PC9hPjxhIGhyZWY9Imh0dHA6Ly9m bGlwLml0L3ZqQkY3IiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IlBpbmcgb24NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGbGlwYm9hcmQi PjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIGlkPSJf eDAwMDBfaTEwMzMiIHNyYz0iaHR0cDovLzQucGluZ2lkZW50aXR5LmNvbS9ycy9waW5naWRlbnRp dHkvaW1hZ2VzL2ZsaXBib2FyZC5naWYiIGFsdD0iZmxpcGJvYXJkDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9nbyI+PC9zcGFuPjwv YT48YSBocmVmPSJodHRwczovL3d3dy5waW5naWRlbnRpdHkuY29tL2Jsb2dzLyIgdGFyZ2V0PSJf YmxhbmsiIHRpdGxlPSJQaW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgYmxvZ3MiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246 bm9uZSI+PGltZyBib3JkZXI9IjAiIGlkPSJfeDAwMDBfaTEwMzQiIHNyYz0iaHR0cDovLzQucGlu Z2lkZW50aXR5LmNvbS9ycy9waW5naWRlbnRpdHkvaW1hZ2VzL3Jzcy5naWYiIGFsdD0icnNzIGZl ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBpY29uIj48L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4N Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAi IGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMzE1IiBzdHlsZT0id2lkdGg6MjM2LjI1cHQ7Ym9yZGVy LWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjYwLjc1cHQi Pg0KPHRkIHdpZHRoPSIxNzIiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTI5LjBwdDtwYWRk aW5nOjExLjI1cHQgMTEuMjVwdCAwaW4gMTEuMjVwdDtoZWlnaHQ6NjAuNzVwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmNsb3VkaWRlbnRpdHlzdW1taXQu Y29tLyIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSJSZWdpc3Rlcg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvciBDbG91ZA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElkZW50 aXR5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgU3VtbWl0IDIwMTQgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAi PjxzcGFuIHN0eWxlPSJjb2xvcjojQ0NDQ0NDO3RleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJv cmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAzNSIgc3JjPSJodHRwOi8vNC5waW5naWRlbnRpdHkuY29t L3JzL3BpbmdpZGVudGl0eS9pbWFnZXMvRVhQX0NJU18yMDE0LmdpZiIgYWx0PSJSZWdpc3Rlcg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGZvciBDbG91ZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIElkZW50aXR5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgU3VtbWl0IDIwMTQgfA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1vZGVybg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElkZW50aXR5 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgUmV2b2x1dGlvbiB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMTnigJMyMyBKdWx5LA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIwMTQgfA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1vbnRlcmV5LCBDQSI+ PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFi bGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9y ZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48 L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86 cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86 cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4N CjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_331551c46fc642a18132324510f0da99BLUPR03MB309namprd03pro_-- From nobody Thu May 15 01:40:44 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DE61A0425 for ; Thu, 15 May 2014 01:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 xKtMQ1NmeQpk for ; Thu, 15 May 2014 01:40:35 -0700 (PDT) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48EE71A0417 for ; Thu, 15 May 2014 01:40:35 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id e53so388135eek.39 for ; Thu, 15 May 2014 01:40:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=e9AHTA+YnwklvcmpLTvTWcwEPMPmudcaY3RkXrAAb7A=; b=WUrj906/3sVTTTCY1/CNjb+FBftmw7XfW2wqvmvccheJo/56JjLtKr0Hdd85WrGSlK 1636gqy2yXf59yHApzyyBpHx6xSLaivKsdsPtYvnFEqFWLjjfe9q4ib/a3/NlK9Zw1aY 9v1S5NVLpSpHeAiGLJr/CcPAgz4diDKPoJBzGEK/g2GqWsw93p3nU4EqAF/uIlQ8mZT9 bPOPG1kmTOAThSSSeMbyEzFFXVdF19kFtB23LFDjclqEHZRP9QSTzvltaiOnl2N/DGWA eQRY86Pf/qFkRqDSrVN6NmG/InlNhwl8wbNFg97GusYAt1FdLnUtBGViQHtFHVNj4Zzj S5Xg== X-Gm-Message-State: ALoCoQkYlbJiAZLSDcsnWba7X1YdTNluicSOb6KoIAxz6pqPnI8/L1mP383Y4mpPttsqYqnsb6X4 X-Received: by 10.14.10.5 with SMTP id 5mr1789796eeu.78.1400143227185; Thu, 15 May 2014 01:40:27 -0700 (PDT) Received: from [10.105.255.214] (vlan105-gw1.ush2.tnib.de. [86.110.65.1]) by mx.google.com with ESMTPSA id h49sm10986599eeg.21.2014.05.15.01.40.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 May 2014 01:40:25 -0700 (PDT) References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> <537416A9.5060701@mit.edu> <53741B2F.4040506@mit.edu> <1F00EAF0-CC8F-469F-84F3-50C534325360@oracle.com> <51BD7E1D-5C8D-4B6F-8F3C-64137CBDA0DA@oracle.com> <53741F27.4010100@mit.edu> <331551c46fc642a18132324510f0da99@BLUPR03MB309.namprd03.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: <331551c46fc642a18132324510f0da99@BLUPR03MB309.namprd03.prod.outlook.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3A6D2783-B32B-4D44-B4FF-DFAA10109D25; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D201) From: John Bradley Date: Thu, 15 May 2014 10:40:21 +0200 To: Anthony Nadalin Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/qM450i0Wkn2ONTNRvKBgriWXBm4 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 08:40:42 -0000 --Apple-Mail-3A6D2783-B32B-4D44-B4FF-DFAA10109D25 Content-Type: multipart/alternative; boundary=Apple-Mail-96AA5CEC-62AC-4AA9-A092-C4969C010218 Content-Transfer-Encoding: 7bit --Apple-Mail-96AA5CEC-62AC-4AA9-A092-C4969C010218 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I thought the a4c required changes to eliminate client registration and to n= ot return an access token.=20 Being clear on if there will be an errata required for a2c to be compliant, = would be helpful.=20 Sent from my iPhone > On May 15, 2014, at 10:30 AM, Anthony Nadalin wrot= e: >=20 > Have no idea what you are saying here, not asking to for errata on the RFC= > =20 > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Thursday, May 15, 2014 1:27 AM > To: Anthony Nadalin > Cc: Phil Hunt; OAuth WG > Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering > =20 > OAuth covers authentication in security consideration=20 > =20 > This was debated in the WG at the time.=20 > =20 > Just say that you want to reopen the RFC.=20 >=20 > Sent from my iPhone >=20 > On May 15, 2014, at 9:03 AM, Anthony Nadalin wrote= : >=20 > So Oauth already treads into the authentication space to some extent and e= nough of an extent to create additional security issues and threats. > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Wednesday, May 14, 2014 10:32 PM > To: Phil Hunt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering > =20 > No. > =20 > OAuth requires that if you use the code response type, the token endpoint m= ust return an access token. > =20 > Connect dosen't require a user_info endpoint. > =20 > In the response_type "id_token" only a id_token is returned in the front c= hannel in a manner similar to SAML POST binding but fragment encoded by defa= ult. > =20 > So there is a flow in Connect that doesn't deliver an access token. > =20 > I think this discussion is more about what changes you want to the core of= OAuth. > =20 > Connect worked around the OAuth spec to be compatible with it. > =20 > Only the OAuth WG can change OAuth and that seems to be what you want. =20= > a4c is a justification for making those changes. > =20 > We should probably focus on the core issue of what changes to RFC 6749 you= are after, to determine if the WG wants to change the charter. > =20 > I think focusing on a4c is a read herring. > =20 > John B. > =20 > On May 15, 2014, at 6:55 AM, Phil Hunt wrote: >=20 >=20 >=20 > I think those are things to discuss if the authen is on the charter.=20 > =20 > So we have now clarified that the basic connect profile doesn't do just au= then and requires identity profile services.=20 >=20 > Phil >=20 > On May 14, 2014, at 18:57, Justin Richer wrote: >=20 > Right, so instead of being able to use my authorization endpoint, which al= ready authenticates the user and can gather consent, I need to implement a n= ew endpoint that's not-quite-OAuth but is almost like it. But it's enough to= be confusing because sometimes I go to this new endpoint endpoint and also g= et an access token anyway, to use somewhere that I'm not sure where. And I'm= not sure I can collapse the two endpoints and re-use my OAuth infrastructur= e. After all, I still need to use the token endpoint, and by that point my s= erver needs to know which endpoint the user went to in the first place to ma= ke that switch. As a developer, this all sounds horribly convoluted and comp= licated to track. Do I get to re-use any of the components from an authoriza= tion endpoint? How do I know whether or not to issue the access token if the= user goes to the authentication endpoint? And then there are the optimizati= ons for existing well-known and well-understood use cases: what if my client= is sitting in the same browser session and just wants to get the user asser= tion directly instead of going through a round trip? Do I need to make two r= ound trips if I'm getting a protected API at the same time as authn data? Ca= n I use the same response_type functionality and other extensions on the aut= hentication endpoint?=20 >=20 > In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is dang= erous and confusing and not something I think the OAuth WG should be a part o= f. And I really just don't see the point of it, unless the goal is to pollut= e the standards space which Connect currently occupies. Is Connect perfect? H= eck no. But it's far and away the best thing we've had in a long time, and i= t already does every single thing you are asking for from this new draft. >=20 > -- Justin >=20 > On 5/14/2014 9:43 PM, Phil Hunt wrote: > Sorry I meant to say this is why it has the /authenticate endpoint to indi= cate the client only wants the users session information. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > On May 14, 2014, at 6:42 PM, Phil Hunt wrote: >=20 >=20 >=20 > Right. This is why it has a different point because the client does NOT w= ant a resource token. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > On May 14, 2014, at 6:41 PM, Justin Richer wrote: >=20 >=20 >=20 > Actually, it's about OAuth compatibility. With OAuth, you get an access to= ken to be used at a protected resource. That's what it's for, that's what cl= ients do the OAuth dance(s) for. Connect defines that protected resource as t= he userinfo endpoint (ie, "tells the client what to do with it"). Connect al= so defines the id token that comes in along side of the bog-standard OAuth t= oken, and Connect is turned on and off through the use of bog-standard OAuth= scopes. So that makes it very, very, very easy to take an OAuth server and t= urn it into a Connect server. I know, I've done just that, and I've walked o= thers through the process as well.=20 >=20 > But the a4c draft is using something that's almost-but-not-quite-OAuth: Yo= u might not get an access token, which is going to confuse the heck out of m= ost OAuth clients that I know since that's what they're trying to get at in t= he first place, and there's no real way for a client to distinguish its requ= est for something with an id_token vs. without. Additionally, in practice, t= hat access token is hugely useful. Just look at all of the weird OpenID2 and= OAuth1 hybrid stuff that people were trying to do back a few years ago on t= op of all the OpenID2 extensions -- this is exactly because OpenID2 was buil= t for "authentication only" because that's what people thought developers wa= nted, but it turned out that developers wanted a whole lot more than that. T= his is one main reason the Facebook Connect and Twitter's OAuth-based login c= ame along and ate everyone's lunch: they gave you authentication, but also s= omething useful about the end user. >=20 > All said, it sounds like you want Connect but without the UserInfo Endpoin= t. You'll be glad to know that you can already do that as per the MTI defini= tions of the server: >=20 > http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI >=20 > You are free to implement a SCIM endpoint (which, by the way, you'll proba= bly need that access_token to access) or no endpoint at all, and a compliant= client ought to be able to deal with that. In fact, there's a way to get ju= st the id_token in Connect if that's all you care about, but instead of hidi= ng it inside of an existing flow that might return something different depen= ding on (currently-undefined) special circumstances, it puts this mode into a= separate response_type entirely to enforce the point that it is different f= rom regular OAuth.=20 >=20 > -- Justin >=20 > On 5/14/2014 9:24 PM, Phil Hunt wrote: > It isn=E2=80=99t required (or should not be). This issue is OIDC compatib= ility. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > On May 14, 2014, at 6:21 PM, Justin Richer wrote: >=20 >=20 >=20 > How is this functionally different from the a4c draft that also allows the= return of both an id_token and an access token?=20 >=20 > -- Justin >=20 > On 5/14/2014 9:18 PM, Phil Hunt wrote: > That=E2=80=99s not a minimalistic authn only profile. > =20 > If you return both an access token AND an id token than the service provid= e has to implement both and the client has to figure out what to do with it.= > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > On May 14, 2014, at 5:44 PM, Chuck Mortimore w= rote: >=20 >=20 >=20 > "I had personally requested the OIDC community about six months ago to des= cribe some minimal subset which we could all reasonably implement." > =20 > I believe you're looking for this: http://openid.net/specs/openid-connect-= basic-1_0.html > =20 > -cmort > =20 > =20 > =20 > On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra wrote: > Anil, >=20 > the challenge is that OIDC is a rather large set of specifications, and to= my knowledge even the core specification has NOT found > a complete implementation at any large IdP. I am not talking here about bo= utique toolkits or startups, I am talking about the folks > who have 100s of millions of users. And, BTW, implementing a few arbitrari= ly selected features from OIDC is not the same as implementing OIDC. >=20 > As we all know, the core problem is that of adding an authenticator token t= o OAuth flows, which is a rather modest extension to OAuth. >=20 > I had personally requested the OIDC community about six months ago to desc= ribe some minimal subset which we could all reasonably implement. I was told= that the specification was "locked down" and fully debugged and so on, so n= o changes could be made. Imagine my surprise to find that in the final draft= s there was a whole new flow - the hybrid flow - that had been added at the l= ast minute. I had never heard of the hybrid flow in the OAuth context - have= you? So now you have an even larger specification! >=20 > The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisel= y a minimal extension to OAuth flows to support an authenticator token. In m= y experience, this is the subset that most customers and implementors are lo= oking for.=20 >=20 >=20 > - prateek >=20 >=20 >=20 >=20 >=20 > =20 > Tony/Phil, > any chance you can have this work done at OIDC?=20 >=20 > The reason is that it is commonly understood/accepted now that OAuth provi= des authorization related specs while authentication/profile > related specs are coming from OIDC (which builds on top of OAuth2). >=20 > Regards, > Anil >=20 > On 05/14/2014 10:47 AM, Anthony Nadalin wrote: > I agree with Phil on this one, there are implementations of this already a= nd much interest > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Wednesday, May 14, 2014 8:32 AM > To: Brian Campbell > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering > =20 > On the contrary. I and others are interested.=20 > =20 > We are waiting for the charter to pick up the work.=20 > =20 > Regardless there will be a new draft shortly.=20 >=20 > Phil >=20 > On May 14, 2014, at 5:24, Brian Campbell wrot= e: >=20 > I would object to 'OAuth Authentication' being picked up by the WG as a wo= rk item. The starting point draft has expired and it hasn't really been disc= usses since Berlin nearly a year ago. As I recall, there was only very limi= ted interest in it even then. I also don't believe it fits well with the WG c= harter. >=20 > I would suggest the WG consider picking up 'OAuth Symmetric Proof of Posse= ssion for Code Extension' for which there is an excellent starting point of h= ttp://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity s= imple security enhancement which addresses problems currently being encounte= red in deployments of native clients.=20 >=20 > =20 > On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig wrote: > Hi all, >=20 > you might have seen that we pushed the assertion documents and the JWT > documents to the IESG today. We have also updated the milestones on the > OAuth WG page. >=20 > This means that we can plan to pick up new work in the group. > We have sent a request to Kathleen to change the milestone for the OAuth > security mechanisms to use the proof-of-possession terminology. >=20 > We also expect an updated version of the dynamic client registration > spec incorporating last call feedback within about 2 weeks. >=20 > We would like you to think about adding the following milestones to the > charter as part of the re-chartering effort: >=20 > ----- >=20 > Nov 2014 Submit 'Token introspection' to the IESG for consideration as a > Proposed Standard > Starting point: >=20 > Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as > a Proposed Standard > Starting point: >=20 > Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a > Proposed Standard > Starting point: >=20 > ----- >=20 > We also updated the charter text to reflect the current situation. Here > is the proposed text: >=20 > ----- >=20 > Charter for Working Group >=20 >=20 > The Web Authorization (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that > supports OAuth could allow its users to use a third-party printing Web > site to print their private pictures, without allowing the printing > site to gain full control of the user's account and without having the > user share his or her photo-sharing sites' long-term credential with > the printing site. >=20 > The OAuth 2.0 protocol suite encompasses >=20 > * a protocol for obtaining access tokens from an authorization > server with the resource owner's consent, > * protocols for presenting these access tokens to resource server > for access to a protected resource, > * guidance for securely using OAuth 2.0, > * the ability to revoke access tokens, > * standardized format for security tokens encoded in a JSON format > (JSON Web Token, JWT), > * ways of using assertions with OAuth, and > * a dynamic client registration protocol. >=20 > The working group also developed security schemes for presenting > authorization tokens to access a protected resource. This led to the > publication of the bearer token, as well as work that remains to be > completed on proof-of-possession and token exchange. >=20 > The ongoing standardization effort within the OAuth working group will > focus on enhancing interoperability and functionality of OAuth > deployments, such as a standard for a token introspection service and > standards for additional security of OAuth requests. >=20 > ----- >=20 > Feedback appreciated. >=20 > Ciao > Hannes & Derek >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > -- >=20 > Brian Campbell > Portfolio Architect > @ > bcampbell@pingidentity.com >=20 > +1 720.317.2061 > Connect with us=E2=80=A6 >=20 >=20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > _______________________________________________ > 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 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 --Apple-Mail-96AA5CEC-62AC-4AA9-A092-C4969C010218 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I thought the a4c required changes to e= liminate client registration and to not return an access token. 
<= div>
Being clear on if there will be an errata required for a2= c to be compliant,  would be helpful. 

Sent from my iPhone<= /div>

On May 15, 2014, at 10:30 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:

Have no idea what you are s= aying here, not asking to for errata on the RFC

 

From: John Brad= ley [mailto:ve7jtb@ve7jtb.com]
Sent: Thursday, May 15, 2014 1:27 AM
To: Anthony Nadalin
Cc: Phil Hunt; OAuth WG
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering<= /o:p>

 

OAuth covers authentication in security consideration=  

 

This was debated in the WG at the time. 

 

Just say that you want to reopen the RFC. <= /o:p>


Sent from my iPhone


On May 15, 2014, at 9:03 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:

So Oauth already treads int= o the authentication space to some extent and enough of an extent to create a= dditional security issues and threats.

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 14, 2014 10:32 PM
To: Phil Hunt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

No.

 

OAuth requires that if you use the code response type= , the token endpoint must return an access token.

 

Connect dosen't require a user_info endpoint.

 

In the response_type "id_token"  only a id_token= is returned in the front channel in a manner similar to SAML POST binding b= ut fragment encoded by default.

 

So there is a flow in Connect that doesn't deliver an= access token.

 

I think this discussion is more about what changes yo= u want to the core of OAuth.

 

Connect worked around the OAuth spec to be compatible= with it.

 

Only the OAuth WG can change OAuth and that seems to b= e what you want.  

a4c is a justification for making those changes.=

 

We should probably focus on the core issue of what ch= anges to RFC 6749 you are after, to determine if the WG wants to change the c= harter.

 

I think focusing on a4c is a read herring.=

 

John B.

 

On May 15, 2014, at 6:55 AM, Phil Hunt <phil.hunt@oracle.com> wrote:=




I think those are things to discuss if the authen is o= n the charter. 

 

So we have now clarified that the basic connect profi= le doesn't do just authen and requires identity profile services. =


Phil


On May 14, 2014, at 18:57, Justin Richer <jricher@mit.edu> wrote:

Right, so instead of being able to use my authorizati= on endpoint, which already authenticates the user and can gather consent, I n= eed to implement a new endpoint that's not-quite-OAuth but is almost like it= . But it's enough to be confusing because sometimes I go to this new endpoint endpoint and also get an access= token anyway, to use somewhere that I'm not sure where. And I'm not sure I c= an collapse the two endpoints and re-use my OAuth infrastructure. After all,= I still need to use the token endpoint, and by that point my server needs to know which endpoint the user= went to in the first place to make that switch. As a developer, this all so= unds horribly convoluted and complicated to track. Do I get to re-use any of= the components from an authorization endpoint? How do I know whether or not to issue the access token if the use= r goes to the authentication endpoint? And then there are the optimizations f= or existing well-known and well-understood use cases: what if my client is s= itting in the same browser session and just wants to get the user assertion directly instead of going through a= round trip? Do I need to make two round trips if I'm getting a protected AP= I at the same time as authn data? Can I use the same response_type functiona= lity and other extensions on the authentication endpoint?

In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is danger= ous and confusing and not something I think the OAuth WG should be a part of= . And I really just don't see the point of it, unless the goal is to pollute= the standards space which Connect currently occupies. Is Connect perfect? Heck no. But it's far and away the b= est thing we've had in a long time, and it already does every single thing y= ou are asking for from this new draft.

 -- Justin

On 5/14/2014 9:43 PM, Phil Hunt wrote:

Sorry I meant to say this is why it has the /authenti= cate endpoint to indicate the client only wants the users session informatio= n.

 

 

 

 

On May 14, 2014, at 6:42 PM, Phil Hunt <phil.hunt@oracle.com> wrote:=




Right.  This is why it has a different point bec= ause the client does NOT want a resource token.

 

 

 

 

On May 14, 2014, at 6:41 PM, Justin Richer <jricher@mit.edu> wrote:




Actually, it's about OAuth compatibility. With OAuth,= you get an access token to be used at a protected resource. That's what it'= s for, that's what clients do the OAuth dance(s) for. Connect defines that p= rotected resource as the userinfo endpoint (ie, "tells the client what to do with it"). Connect also defines t= he id token that comes in along side of the bog-standard OAuth token, and Co= nnect is turned on and off through the use of bog-standard OAuth scopes. So t= hat makes it very, very, very easy to take an OAuth server and turn it into a Connect server. I know, I'v= e done just that, and I've walked others through the process as well.

But the a4c draft is using something that's almost-but-not-quite-OAuth: You m= ight not get an access token, which is going to confuse the heck out of most= OAuth clients that I know since that's what they're trying to get at in the= first place, and there's no real way for a client to distinguish its request for something with an id_t= oken vs. without. Additionally, in practice, that access token is hugely use= ful. Just look at all of the weird OpenID2 and OAuth1 hybrid stuff that peop= le were trying to do back a few years ago on top of all the OpenID2 extensions -- this is exactly because O= penID2 was built for "authentication only" because that's what people though= t developers wanted, but it turned out that developers wanted a whole lot mo= re than that. This is one main reason the Facebook Connect and Twitter's OAuth-based login came along and a= te everyone's lunch: they gave you authentication, but also something useful= about the end user.

All said, it sounds like you want Connect but without the UserInfo Endpoint.= You'll be glad to know that you can already do that as per the MTI definiti= ons of the server:

  http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI
=
You are free to implement a SCIM endpoint (which, by the way, you'll probabl= y need that access_token to access) or no endpoint at all, and a compliant c= lient ought to be able to deal with that. In fact, there's a way to get just= the id_token in Connect if that's all you care about, but instead of hiding it inside of an existing flow tha= t might return something different depending on (currently-undefined) specia= l circumstances, it puts this mode into a separate response_type entirely to= enforce the point that it is different from regular OAuth.

 -- Justin

On 5/14/2014 9:24 PM, Phil Hunt wrote:

It isn=E2=80=99t required (or should not be).  T= his issue is OIDC compatibility.

 

 

 

 

On May 14, 2014, at 6:21 PM, Justin Richer <jricher@mit.edu> wrote:




How is this functionally different from the a4c draft= that also allows the return of both an id_token and an access token?

 -- Justin

On 5/14/2014 9:18 PM, Phil Hunt wrote:

That=E2=80=99s not a minimalistic authn only profile.=

 

If you return both an access token AND an id token th= an the service provide has to implement both and the client has to figure ou= t what to do with it.

 

 

 

 

On May 14, 2014, at 5:44 PM, Chuck Mortimore <cmortimore@salesforce.com> w= rote:




"I had personally requested the OIDC community about s= ix months ago to describe some minimal subset which we could all reasonably i= mplement."

 

I believe you're looking for this: http://openid.net/specs/openid-connect-basic-1_0.html

 

-cmort

 

 

 

On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <<= a href=3D"mailto:prateek.mishra@oracle.com" target=3D"_blank">prateek.mishra= @oracle.com> wrote:

Anil,

the challenge is that OIDC is a rather large set of specifications, and to m= y knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about bout= ique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily= selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token to= OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to descri= be some minimal subset which we could all reasonably implement. I was told t= hat  the specification was "locked down" and fully debugged and so on, s= o no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - t= he hybrid flow - that had been added at the last minute. I had never heard o= f the hybrid flow in the OAuth context - have you? So now you have an even l= arger specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely a= minimal extension to OAuth flows to support an authenticator token.  I= n my experience, this is the subset that most customers and implementors are= looking for.


- prateek





 

Tony/Phil,
  any chance you can have this work done at OIDC?

The reason is that it is commonly understood/accepted now that OAuth provide= s authorization related specs while authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:

I agree with Phil on this one, there are i= mplementations of this already and much interest

 

From: OAuth [mailto:oauth-bounces@ietf.org= ] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.or= g
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

On the contrary. I and others are interested. 

 

We are waiting for the charter to pick up the work. =

 

Regardless there will be a new draft shortly. 


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a wo= rk item. The starting point draft has expired and it hasn't really been disc= usses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even the= n. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possess= ion for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativ= ity simple security enhancement which addresses problems currently being enc= ountered in deployments of native clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
= security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
= Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

3D"Ping

 =

Brian Campbell
Portfolio Architect

@

bcampbell@pingidentity.com

3D"phone"

+1 720.317.2061<= /o:p>

Connect with us=E2=80=A6

3D"twitter<= a href=3D"https://www.youtube.com/user/PingIdentityTV" target=3D"_blank" tit= le=3D"Ping on YouTube">3D"youtube<= a href=3D"https://www.linkedin.com/company/21870" target=3D"_blank" title=3D= "Ping on LinkedIn">3D"LinkedIn=<= a href=3D"https://www.facebook.com/pingidentitypage" target=3D"_blank" title= =3D"Ping on Facebook">3D"Facebook=<= a href=3D"https://plus.google.com/u/0/114266977739397708540" target=3D"_blan= k" title=3D"Ping on Google+">3D"Google+<= a href=3D"http://www.slideshare.net/PingIdentity" target=3D"_blank" title=3D= "Ping on SlideShare">3D"slide=<= a href=3D"http://flip.it/vjBF7" target=3D"_blank" title=3D"Ping on Flipboard">3D"flipbo=<= a href=3D"https://www.pingidentity.com/blogs/" target=3D"_blank" title=3D"Pi= ng blogs">3D"rss<= o:p>

3D"Register

 

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




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





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

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
ht= tps://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.iet=
f.org/mailman/listinfo/oauth

 

 

 

 

 

 

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

 

= --Apple-Mail-96AA5CEC-62AC-4AA9-A092-C4969C010218-- --Apple-Mail-3A6D2783-B32B-4D44-B4FF-DFAA10109D25 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwNTE1MDg0MDIyWjAjBgkqhkiG9w0BCQQxFgQULbUrvzYvScALZRny EwKFB+v/wQcwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAN7RXFwj/edxYAugUlDRmly1bBznJEoo52rIELAQxI4LlQbuA 9AlgZ5KV/RovERh4eqOI0pBtwF2a+Z5PA7BL6DtdA1+DsQbNcCHMve/GJhvkh5HD4IgWVlhLvrp1 s04w44OmHB+PZ/nLD2AYY/0zDw4bWVk8kF5ABrlh84W3smXJg0+6qz+nPYk/+WZ8AYLtT+aB04Xz qGQSvJB0581LAt9jNTgIz9PkVpkE1rOBL/govSaaFNKybBXoX2qMqWQlMuwxILP5fJRKAqk+JG+O 3Lrrk6fH9DOM7ijNe+434M4I8gxr+YGqarOEzM8N7xiZEkmtu5GZ0dXJSP8lhSKL1AAAAAAAAA== --Apple-Mail-3A6D2783-B32B-4D44-B4FF-DFAA10109D25-- From nobody Thu May 15 03:13:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B681A028D for ; Thu, 15 May 2014 03:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.839 X-Spam-Level: X-Spam-Status: No, score=-4.839 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 JNfqLJs7IE7c for ; Thu, 15 May 2014 03:12:57 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638441A0289 for ; Thu, 15 May 2014 03:12:57 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4FACnmW005315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 10:12:50 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4FACmMf003313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 May 2014 10:12:48 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4FAClt3029780; Thu, 15 May 2014 10:12:48 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 May 2014 03:12:46 -0700 References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> <537416A9.5060701@mit.edu> <53741B2F.4040506@mit.edu> <1F00EAF0-CC8F-469F-84F3-50C534325360@oracle.com> <51BD7E1D-5C8D-4B6F-8F3C-64137CBDA0DA@oracle.com> <53741F27.4010100@mit.edu> <331551c46fc642a18132324510f0da99@BLUPR03MB309.namprd03.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-BEA5A7F2-B5C5-41B3-9F20-03CEFE9379DD Content-Transfer-Encoding: 7bit Message-Id: <09A8A220-D5CD-4F32-A424-29F8EA33042A@oracle.com> X-Mailer: iPhone Mail (11D167) From: Phil Hunt Date: Thu, 15 May 2014 03:12:37 -0700 To: John Bradley X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/eTiEQ4Zi_scMBIXUpz587J6QPFY Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 10:13:04 -0000 --Apple-Mail-BEA5A7F2-B5C5-41B3-9F20-03CEFE9379DD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable John, Nope. Read the draft please.=20 The draft is about providing end-user authentication results to clients.=20 It does not saying anything about registration pr require any changes to oau= th.=20 Phil > On May 15, 2014, at 1:40, John Bradley wrote: >=20 > I thought the a4c required changes to eliminate client registration and to= not return an access token.=20 >=20 > Being clear on if there will be an errata required for a2c to be compliant= , would be helpful.=20 >=20 > Sent from my iPhone >=20 >> On May 15, 2014, at 10:30 AM, Anthony Nadalin wro= te: >>=20 >> Have no idea what you are saying here, not asking to for errata on the RFC= >> =20 >> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 >> Sent: Thursday, May 15, 2014 1:27 AM >> To: Anthony Nadalin >> Cc: Phil Hunt; OAuth WG >> Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering >> =20 >> OAuth covers authentication in security consideration=20 >> =20 >> This was debated in the WG at the time.=20 >> =20 >> Just say that you want to reopen the RFC.=20 >>=20 >> Sent from my iPhone >>=20 >> On May 15, 2014, at 9:03 AM, Anthony Nadalin wrot= e: >>=20 >> So Oauth already treads into the authentication space to some extent and e= nough of an extent to create additional security issues and threats. >> =20 >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley >> Sent: Wednesday, May 14, 2014 10:32 PM >> To: Phil Hunt >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering >> =20 >> No. >> =20 >> OAuth requires that if you use the code response type, the token endpoint= must return an access token. >> =20 >> Connect dosen't require a user_info endpoint. >> =20 >> In the response_type "id_token" only a id_token is returned in the front= channel in a manner similar to SAML POST binding but fragment encoded by de= fault. >> =20 >> So there is a flow in Connect that doesn't deliver an access token. >> =20 >> I think this discussion is more about what changes you want to the core o= f OAuth. >> =20 >> Connect worked around the OAuth spec to be compatible with it. >> =20 >> Only the OAuth WG can change OAuth and that seems to be what you want. =20= >> a4c is a justification for making those changes. >> =20 >> We should probably focus on the core issue of what changes to RFC 6749 yo= u are after, to determine if the WG wants to change the charter. >> =20 >> I think focusing on a4c is a read herring. >> =20 >> John B. >> =20 >> On May 15, 2014, at 6:55 AM, Phil Hunt wrote: >>=20 >>=20 >>=20 >> I think those are things to discuss if the authen is on the charter.=20 >> =20 >> So we have now clarified that the basic connect profile doesn't do just a= uthen and requires identity profile services.=20 >>=20 >> Phil >>=20 >> On May 14, 2014, at 18:57, Justin Richer wrote: >>=20 >> Right, so instead of being able to use my authorization endpoint, which a= lready authenticates the user and can gather consent, I need to implement a n= ew endpoint that's not-quite-OAuth but is almost like it. But it's enough to= be confusing because sometimes I go to this new endpoint endpoint and also g= et an access token anyway, to use somewhere that I'm not sure where. And I'm= not sure I can collapse the two endpoints and re-use my OAuth infrastructur= e. After all, I still need to use the token endpoint, and by that point my s= erver needs to know which endpoint the user went to in the first place to ma= ke that switch. As a developer, this all sounds horribly convoluted and comp= licated to track. Do I get to re-use any of the components from an authoriza= tion endpoint? How do I know whether or not to issue the access token if the= user goes to the authentication endpoint? And then there are the optimizati= ons for existing well-known and well-understood use cases: what if my client= is sitting in the same browser session and just wants to get the user asser= tion directly instead of going through a round trip? Do I need to make two r= ound trips if I'm getting a protected API at the same time as authn data? Ca= n I use the same response_type functionality and other extensions on the aut= hentication endpoint?=20 >>=20 >> In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is dan= gerous and confusing and not something I think the OAuth WG should be a part= of. And I really just don't see the point of it, unless the goal is to poll= ute the standards space which Connect currently occupies. Is Connect perfect= ? Heck no. But it's far and away the best thing we've had in a long time, an= d it already does every single thing you are asking for from this new draft.= >>=20 >> -- Justin >>=20 >> On 5/14/2014 9:43 PM, Phil Hunt wrote: >> Sorry I meant to say this is why it has the /authenticate endpoint to ind= icate the client only wants the users session information. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> =20 >> =20 >> On May 14, 2014, at 6:42 PM, Phil Hunt wrote: >>=20 >>=20 >>=20 >> Right. This is why it has a different point because the client does NOT w= ant a resource token. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> =20 >> =20 >> On May 14, 2014, at 6:41 PM, Justin Richer wrote: >>=20 >>=20 >>=20 >> Actually, it's about OAuth compatibility. With OAuth, you get an access t= oken to be used at a protected resource. That's what it's for, that's what c= lients do the OAuth dance(s) for. Connect defines that protected resource as= the userinfo endpoint (ie, "tells the client what to do with it"). Connect a= lso defines the id token that comes in along side of the bog-standard OAuth t= oken, and Connect is turned on and off through the use of bog-standard OAuth= scopes. So that makes it very, very, very easy to take an OAuth server and t= urn it into a Connect server. I know, I've done just that, and I've walked o= thers through the process as well.=20 >>=20 >> But the a4c draft is using something that's almost-but-not-quite-OAuth: Y= ou might not get an access token, which is going to confuse the heck out of m= ost OAuth clients that I know since that's what they're trying to get at in t= he first place, and there's no real way for a client to distinguish its requ= est for something with an id_token vs. without. Additionally, in practice, t= hat access token is hugely useful. Just look at all of the weird OpenID2 and= OAuth1 hybrid stuff that people were trying to do back a few years ago on t= op of all the OpenID2 extensions -- this is exactly because OpenID2 was buil= t for "authentication only" because that's what people thought developers wa= nted, but it turned out that developers wanted a whole lot more than that. T= his is one main reason the Facebook Connect and Twitter's OAuth-based login c= ame along and ate everyone's lunch: they gave you authentication, but also s= omething useful about the end user. >>=20 >> All said, it sounds like you want Connect but without the UserInfo Endpoi= nt. You'll be glad to know that you can already do that as per the MTI defin= itions of the server: >>=20 >> http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI >>=20 >> You are free to implement a SCIM endpoint (which, by the way, you'll prob= ably need that access_token to access) or no endpoint at all, and a complian= t client ought to be able to deal with that. In fact, there's a way to get j= ust the id_token in Connect if that's all you care about, but instead of hid= ing it inside of an existing flow that might return something different depe= nding on (currently-undefined) special circumstances, it puts this mode into= a separate response_type entirely to enforce the point that it is different= from regular OAuth.=20 >>=20 >> -- Justin >>=20 >> On 5/14/2014 9:24 PM, Phil Hunt wrote: >> It isn=E2=80=99t required (or should not be). This issue is OIDC compati= bility. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> =20 >> =20 >> On May 14, 2014, at 6:21 PM, Justin Richer wrote: >>=20 >>=20 >>=20 >> How is this functionally different from the a4c draft that also allows th= e return of both an id_token and an access token?=20 >>=20 >> -- Justin >>=20 >> On 5/14/2014 9:18 PM, Phil Hunt wrote: >> That=E2=80=99s not a minimalistic authn only profile. >> =20 >> If you return both an access token AND an id token than the service provi= de has to implement both and the client has to figure out what to do with it= . >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> =20 >> =20 >> On May 14, 2014, at 5:44 PM, Chuck Mortimore w= rote: >>=20 >>=20 >>=20 >> "I had personally requested the OIDC community about six months ago to de= scribe some minimal subset which we could all reasonably implement." >> =20 >> I believe you're looking for this: http://openid.net/specs/openid-connect= -basic-1_0.html >> =20 >> -cmort >> =20 >> =20 >> =20 >> On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra wrote: >> Anil, >>=20 >> the challenge is that OIDC is a rather large set of specifications, and t= o my knowledge even the core specification has NOT found >> a complete implementation at any large IdP. I am not talking here about b= outique toolkits or startups, I am talking about the folks >> who have 100s of millions of users. And, BTW, implementing a few arbitrar= ily selected features from OIDC is not the same as implementing OIDC. >>=20 >> As we all know, the core problem is that of adding an authenticator token= to OAuth flows, which is a rather modest extension to OAuth. >>=20 >> I had personally requested the OIDC community about six months ago to des= cribe some minimal subset which we could all reasonably implement. I was tol= d that the specification was "locked down" and fully debugged and so on, so= no changes could be made. Imagine my surprise to find that in the final dra= fts there was a whole new flow - the hybrid flow - that had been added at th= e last minute. I had never heard of the hybrid flow in the OAuth context - h= ave you? So now you have an even larger specification! >>=20 >> The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precise= ly a minimal extension to OAuth flows to support an authenticator token. In= my experience, this is the subset that most customers and implementors are l= ooking for.=20 >>=20 >>=20 >> - prateek >>=20 >>=20 >>=20 >>=20 >>=20 >> =20 >> Tony/Phil, >> any chance you can have this work done at OIDC?=20 >>=20 >> The reason is that it is commonly understood/accepted now that OAuth prov= ides authorization related specs while authentication/profile >> related specs are coming from OIDC (which builds on top of OAuth2). >>=20 >> Regards, >> Anil >>=20 >> On 05/14/2014 10:47 AM, Anthony Nadalin wrote: >> I agree with Phil on this one, there are implementations of this already a= nd much interest >> =20 >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt >> Sent: Wednesday, May 14, 2014 8:32 AM >> To: Brian Campbell >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering >> =20 >> On the contrary. I and others are interested.=20 >> =20 >> We are waiting for the charter to pick up the work.=20 >> =20 >> Regardless there will be a new draft shortly.=20 >>=20 >> Phil >>=20 >> On May 14, 2014, at 5:24, Brian Campbell wro= te: >>=20 >> I would object to 'OAuth Authentication' being picked up by the WG as a w= ork item. The starting point draft has expired and it hasn't really been dis= cusses since Berlin nearly a year ago. As I recall, there was only very lim= ited interest in it even then. I also don't believe it fits well with the WG= charter. >>=20 >> I would suggest the WG consider picking up 'OAuth Symmetric Proof of Poss= ession for Code Extension' for which there is an excellent starting point of= http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity= simple security enhancement which addresses problems currently being encoun= tered in deployments of native clients.=20 >>=20 >> =20 >> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig wrote: >> Hi all, >>=20 >> you might have seen that we pushed the assertion documents and the JWT >> documents to the IESG today. We have also updated the milestones on the >> OAuth WG page. >>=20 >> This means that we can plan to pick up new work in the group. >> We have sent a request to Kathleen to change the milestone for the OAuth >> security mechanisms to use the proof-of-possession terminology. >>=20 >> We also expect an updated version of the dynamic client registration >> spec incorporating last call feedback within about 2 weeks. >>=20 >> We would like you to think about adding the following milestones to the >> charter as part of the re-chartering effort: >>=20 >> ----- >>=20 >> Nov 2014 Submit 'Token introspection' to the IESG for consideration as a >> Proposed Standard >> Starting point: >>=20 >> Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as >> a Proposed Standard >> Starting point: >>=20 >> Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a >> Proposed Standard >> Starting point: >>=20 >> ----- >>=20 >> We also updated the charter text to reflect the current situation. Here >> is the proposed text: >>=20 >> ----- >>=20 >> Charter for Working Group >>=20 >>=20 >> The Web Authorization (OAuth) protocol allows a user to grant a >> third-party Web site or application access to the user's protected >> resources, without necessarily revealing their long-term credentials, >> or even their identity. For example, a photo-sharing site that >> supports OAuth could allow its users to use a third-party printing Web >> site to print their private pictures, without allowing the printing >> site to gain full control of the user's account and without having the >> user share his or her photo-sharing sites' long-term credential with >> the printing site. >>=20 >> The OAuth 2.0 protocol suite encompasses >>=20 >> * a protocol for obtaining access tokens from an authorization >> server with the resource owner's consent, >> * protocols for presenting these access tokens to resource server >> for access to a protected resource, >> * guidance for securely using OAuth 2.0, >> * the ability to revoke access tokens, >> * standardized format for security tokens encoded in a JSON format >> (JSON Web Token, JWT), >> * ways of using assertions with OAuth, and >> * a dynamic client registration protocol. >>=20 >> The working group also developed security schemes for presenting >> authorization tokens to access a protected resource. This led to the >> publication of the bearer token, as well as work that remains to be >> completed on proof-of-possession and token exchange. >>=20 >> The ongoing standardization effort within the OAuth working group will >> focus on enhancing interoperability and functionality of OAuth >> deployments, such as a standard for a token introspection service and >> standards for additional security of OAuth requests. >>=20 >> ----- >>=20 >> Feedback appreciated. >>=20 >> Ciao >> Hannes & Derek >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >> -- >>=20 >> Brian Campbell >> Portfolio Architect >> @ >> bcampbell@pingidentity.com >>=20 >> +1 720.317.2061 >> Connect with us=E2=80=A6 >>=20 >>=20 >> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 >> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 --Apple-Mail-BEA5A7F2-B5C5-41B3-9F20-03CEFE9379DD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
John,

Nope. R= ead the draft please. 

The draft is about prov= iding end-user authentication results to clients. 

=
It does not saying anything about registration pr require any changes t= o oauth. 

Phil

On May 15, 2014, a= t 1:40, John Bradley <ve7jtb@ve7jtb.= com> wrote:

I thought t= he a4c required changes to eliminate client registration and to not return a= n access token. 

Being clear on if there will b= e an errata required for a2c to be compliant,  would be helpful. <= br>
Sent from my iPhone

On May 15, 2014, at 10:30 AM, Antho= ny Nadalin <tonynad@microsoft.co= m> wrote:

Have no idea what you are s= aying here, not asking to for errata on the RFC

 

From: John Brad= ley [mailto:ve7jtb@ve7jtb.com]
Sent: Thursday, May 15, 2014 1:27 AM
To: Anthony Nadalin
Cc: Phil Hunt; OAuth WG
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering<= /o:p>

 

OAuth covers authentication in security consideration=  

 

This was debated in the WG at the time. 

 

Just say that you want to reopen the RFC. <= /o:p>


Sent from my iPhone


On May 15, 2014, at 9:03 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:

So Oauth already treads int= o the authentication space to some extent and enough of an extent to create a= dditional security issues and threats.

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 14, 2014 10:32 PM
To: Phil Hunt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

No.

 

OAuth requires that if you use the code response type= , the token endpoint must return an access token.

 

Connect dosen't require a user_info endpoint.

 

In the response_type "id_token"  only a id_token= is returned in the front channel in a manner similar to SAML POST binding b= ut fragment encoded by default.

 

So there is a flow in Connect that doesn't deliver an= access token.

 

I think this discussion is more about what changes yo= u want to the core of OAuth.

 

Connect worked around the OAuth spec to be compatible= with it.

 

Only the OAuth WG can change OAuth and that seems to b= e what you want.  

a4c is a justification for making those changes.=

 

We should probably focus on the core issue of what ch= anges to RFC 6749 you are after, to determine if the WG wants to change the c= harter.

 

I think focusing on a4c is a read herring.=

 

John B.

 

On May 15, 2014, at 6:55 AM, Phil Hunt <phil.hunt@oracle.com> wrote:=




I think those are things to discuss if the authen is o= n the charter. 

 

So we have now clarified that the basic connect profi= le doesn't do just authen and requires identity profile services. =


Phil


On May 14, 2014, at 18:57, Justin Richer <jricher@mit.edu> wrote:

Right, so instead of being able to use my authorizati= on endpoint, which already authenticates the user and can gather consent, I n= eed to implement a new endpoint that's not-quite-OAuth but is almost like it= . But it's enough to be confusing because sometimes I go to this new endpoint endpoint and also get an access= token anyway, to use somewhere that I'm not sure where. And I'm not sure I c= an collapse the two endpoints and re-use my OAuth infrastructure. After all,= I still need to use the token endpoint, and by that point my server needs to know which endpoint the user= went to in the first place to make that switch. As a developer, this all so= unds horribly convoluted and complicated to track. Do I get to re-use any of= the components from an authorization endpoint? How do I know whether or not to issue the access token if the use= r goes to the authentication endpoint? And then there are the optimizations f= or existing well-known and well-understood use cases: what if my client is s= itting in the same browser session and just wants to get the user assertion directly instead of going through a= round trip? Do I need to make two round trips if I'm getting a protected AP= I at the same time as authn data? Can I use the same response_type functiona= lity and other extensions on the authentication endpoint?

In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is danger= ous and confusing and not something I think the OAuth WG should be a part of= . And I really just don't see the point of it, unless the goal is to pollute= the standards space which Connect currently occupies. Is Connect perfect? Heck no. But it's far and away the b= est thing we've had in a long time, and it already does every single thing y= ou are asking for from this new draft.

 -- Justin

On 5/14/2014 9:43 PM, Phil Hunt wrote:

Sorry I meant to say this is why it has the /authenti= cate endpoint to indicate the client only wants the users session informatio= n.

 

 

 

 

On May 14, 2014, at 6:42 PM, Phil Hunt <phil.hunt@oracle.com> wrote:=




Right.  This is why it has a different point bec= ause the client does NOT want a resource token.

 

 

 

 

On May 14, 2014, at 6:41 PM, Justin Richer <jricher@mit.edu> wrote:




Actually, it's about OAuth compatibility. With OAuth,= you get an access token to be used at a protected resource. That's what it'= s for, that's what clients do the OAuth dance(s) for. Connect defines that p= rotected resource as the userinfo endpoint (ie, "tells the client what to do with it"). Connect also defines t= he id token that comes in along side of the bog-standard OAuth token, and Co= nnect is turned on and off through the use of bog-standard OAuth scopes. So t= hat makes it very, very, very easy to take an OAuth server and turn it into a Connect server. I know, I'v= e done just that, and I've walked others through the process as well.

But the a4c draft is using something that's almost-but-not-quite-OAuth: You m= ight not get an access token, which is going to confuse the heck out of most= OAuth clients that I know since that's what they're trying to get at in the= first place, and there's no real way for a client to distinguish its request for something with an id_t= oken vs. without. Additionally, in practice, that access token is hugely use= ful. Just look at all of the weird OpenID2 and OAuth1 hybrid stuff that peop= le were trying to do back a few years ago on top of all the OpenID2 extensions -- this is exactly because O= penID2 was built for "authentication only" because that's what people though= t developers wanted, but it turned out that developers wanted a whole lot mo= re than that. This is one main reason the Facebook Connect and Twitter's OAuth-based login came along and a= te everyone's lunch: they gave you authentication, but also something useful= about the end user.

All said, it sounds like you want Connect but without the UserInfo Endpoint.= You'll be glad to know that you can already do that as per the MTI definiti= ons of the server:

  http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI
=
You are free to implement a SCIM endpoint (which, by the way, you'll probabl= y need that access_token to access) or no endpoint at all, and a compliant c= lient ought to be able to deal with that. In fact, there's a way to get just= the id_token in Connect if that's all you care about, but instead of hiding it inside of an existing flow tha= t might return something different depending on (currently-undefined) specia= l circumstances, it puts this mode into a separate response_type entirely to= enforce the point that it is different from regular OAuth.

 -- Justin

On 5/14/2014 9:24 PM, Phil Hunt wrote:

It isn=E2=80=99t required (or should not be).  T= his issue is OIDC compatibility.

 

 

 

 

On May 14, 2014, at 6:21 PM, Justin Richer <jricher@mit.edu> wrote:




How is this functionally different from the a4c draft= that also allows the return of both an id_token and an access token?

 -- Justin

On 5/14/2014 9:18 PM, Phil Hunt wrote:

That=E2=80=99s not a minimalistic authn only profile.=

 

If you return both an access token AND an id token th= an the service provide has to implement both and the client has to figure ou= t what to do with it.

 

 

 

 

On May 14, 2014, at 5:44 PM, Chuck Mortimore <cmortimore@salesforce.com> w= rote:




"I had personally requested the OIDC community about s= ix months ago to describe some minimal subset which we could all reasonably i= mplement."

 

I believe you're looking for this: http://openid.net/specs/openid-connect-basic-1_0.html

 

-cmort

 

 

 

On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <<= a href=3D"mailto:prateek.mishra@oracle.com" target=3D"_blank">prateek.mishra= @oracle.com> wrote:

Anil,

the challenge is that OIDC is a rather large set of specifications, and to m= y knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about bout= ique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily= selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token to= OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to descri= be some minimal subset which we could all reasonably implement. I was told t= hat  the specification was "locked down" and fully debugged and so on, s= o no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - t= he hybrid flow - that had been added at the last minute. I had never heard o= f the hybrid flow in the OAuth context - have you? So now you have an even l= arger specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely a= minimal extension to OAuth flows to support an authenticator token.  I= n my experience, this is the subset that most customers and implementors are= looking for.


- prateek





 

Tony/Phil,
  any chance you can have this work done at OIDC?

The reason is that it is commonly understood/accepted now that OAuth provide= s authorization related specs while authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:

I agree with Phil on this one, there are i= mplementations of this already and much interest

 

From: OAuth [mailto:oauth-bounces@ietf.org= ] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.or= g
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 

On the contrary. I and others are interested. 

 

We are waiting for the charter to pick up the work. =

 

Regardless there will be a new draft shortly. 


Phil


On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com> wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a wo= rk item. The starting point draft has expired and it hasn't really been disc= usses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even the= n. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possess= ion for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativ= ity simple security enhancement which addresses problems currently being enc= ountered in deployments of native clients. 

 

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
= security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
= Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek



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




--

3D"Ping

 =

Brian Campbell
Portfolio Architect

@

bcampbell@pingidentity.com

3D"phone"

+1 720.317.2061<= /o:p>

Connect with us=E2=80=A6

3D"twitter<= a href=3D"https://www.youtube.com/user/PingIdentityTV" target=3D"_blank" tit= le=3D"Ping on YouTube">3D"youtube<= a href=3D"https://www.linkedin.com/company/21870" target=3D"_blank" title=3D= "Ping on LinkedIn">3D"LinkedIn=<= a href=3D"https://www.facebook.com/pingidentitypage" target=3D"_blank" title= =3D"Ping on Facebook">3D"Facebook=<= a href=3D"https://plus.google.com/u/0/114266977739397708540" target=3D"_blan= k" title=3D"Ping on Google+">3D"Google+<= a href=3D"http://www.slideshare.net/PingIdentity" target=3D"_blank" title=3D= "Ping on SlideShare">3D"slide=<= a href=3D"http://flip.it/vjBF7" target=3D"_blank" title=3D"Ping on Flipboard">3D"flipbo=<= a href=3D"https://www.pingidentity.com/blogs/" target=3D"_blank" title=3D"Pi= ng blogs">3D"rss<= o:p>

3D"Register

 

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




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





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

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
ht= tps://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.iet=
f.org/mailman/listinfo/oauth

 

 

 

 

 

 

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

 

= --Apple-Mail-BEA5A7F2-B5C5-41B3-9F20-03CEFE9379DD-- From nobody Thu May 15 05:38:10 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818591A0285 for ; Thu, 15 May 2014 05:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.978 X-Spam-Level: X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 8wiYCBqt8T7K for ; Thu, 15 May 2014 05:37:56 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78AB11A04E8 for ; Thu, 15 May 2014 05:37:55 -0700 (PDT) Received: from mail-ie0-f177.google.com ([209.85.223.177]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKU3S1HGl/28CtwJ30X5cYtBIzUOTDsgR7@postini.com; Thu, 15 May 2014 05:37:48 PDT Received: by mail-ie0-f177.google.com with SMTP id rp18so922477iec.22 for ; Thu, 15 May 2014 05:37:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XSAjy1cdZc9ZjxaRMVONpQe55/5+0jPupF2lV5La6Ik=; b=IPEzsBY+9fCWqGR+ksmb0seI9gd71amA99h3Iq/WxKyLnfeZQ6ZGQO8k4Bh4Qsd6Xb a9yhMWhICwtmmQ9ajHtHEutwi+UY0IXOJSHP0b12A8M4OmAfIXtjG+bRAZUpK2KA8lbJ 1gDMi60FGlQtQeZfnnClmL1Oe0xwYgT+qPq6iHg58ix54nSvI8dh3IDckBpzjVfHLRpi 26BLVxj31ErdGOoHgRXwzOgUjr8N6jHtUYYgQHQfB3l4n1mKI2giWg8XvhjW7mS7OR9p 6gunUROp/M/bgOuxomCfFXaZ9VD3s4mrGYXGqhp9cPSKzufqPi2IQvbVmV4gglcri5Kz RbHg== X-Gm-Message-State: ALoCoQn8oTamwdJpa0aBEuHnwI/7V6WUrYQFnDHjlYoe0xaiDb9WmjG0TQGy3m7r53cTU0mV3tTHRMI//nzCroaVjPRb/Mu4KBOa25fG40IgD8K89k6GHldF9+mlwJwK7dUpHnmff6V+ X-Received: by 10.50.4.70 with SMTP id i6mr74498986igi.40.1400157468113; Thu, 15 May 2014 05:37:48 -0700 (PDT) X-Received: by 10.50.4.70 with SMTP id i6mr74498965igi.40.1400157467914; Thu, 15 May 2014 05:37:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Thu, 15 May 2014 05:37:17 -0700 (PDT) In-Reply-To: <53740C51.1080009@oracle.com> References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com> From: Brian Campbell Date: Thu, 15 May 2014 06:37:17 -0600 Message-ID: To: Prateek Mishra Content-Type: multipart/alternative; boundary=001a11c32a88814fd504f96f90f8 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/RA71Uutj2zccc1ErT8BLWYvwWWI Cc: oauth Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 12:38:04 -0000 --001a11c32a88814fd504f96f90f8 Content-Type: text/plain; charset=UTF-8 "I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that the specification was "locked down" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!" Prateek, The hybrid flow wasn't new at all. It was an editorial change that attempted to better explain multiple response types like code+token, which is something allowed for by OAuth http://tools.ietf.org/html/rfc6749#section-8.4 and used in Connect since the very beginning (at least as long as I'd been involved, which is 2+ years). Nothing was added to the actual protocol. On Wed, May 14, 2014 at 6:37 PM, Prateek Mishra wrote: > Anil, > > the challenge is that OIDC is a rather large set of specifications, and to > my knowledge even the core specification has NOT found > a complete implementation at any large IdP. I am not talking here about > boutique toolkits or startups, I am talking about the folks > who have 100s of millions of users. And, BTW, implementing a few > arbitrarily selected features from OIDC is not the same as implementing > OIDC. > > As we all know, the core problem is that of adding an authenticator token > to OAuth flows, which is a rather modest extension to OAuth. > > I had personally requested the OIDC community about six months ago to > describe some minimal subset which we could all reasonably implement. I was > told that the specification was "locked down" and fully debugged and so > on, so no changes could be made. Imagine my surprise to find that in the > final drafts there was a whole new flow - the hybrid flow - that had been > added at the last minute. I had never heard of the hybrid flow in the OAuth > context - have you? So now you have an even larger specification! > > The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes > precisely a minimal extension to OAuth flows to support an authenticator > token. In my experience, this is the subset that most customers and > implementors are looking for. > > > - prateek > > --001a11c32a88814fd504f96f90f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

"I had personally requested the OIDC co= mmunity about six months ago to describe some minimal subset which we could all reasonably implement. I was told that=C2=A0 the specification was "locked dow= n" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!"

Prateek,<= br>
The hybrid flow wasn't new at all. It was an editorial cha= nge that attempted to better explain multiple response types like code+toke= n, which is something allowed for by OAuth http://tools.ietf.org/html/rfc6749#section-8.4 and used in Connect since the very beginning (at least as long as I'= d been involved, which is 2+ years).=C2=A0 Nothing was added to the actual = protocol.





On Wed, May 14, 2014 at 6:37 PM, Prateek Mishra <prateek= .mishra@oracle.com> wrote:
=20 =20 =20
Anil,

the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few arbitrarily selected features from OIDC is not the same as implementing OIDC.

As we all know, the core problem is that of adding an authenticator token to OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that=C2=A0 the specification was "locked dow= n" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely a minimal extension to OAuth flows to support an authenticator token.=C2=A0 In my experience, this is the subset that mo= st customers and implementors are looking for.


- prateek

--001a11c32a88814fd504f96f90f8-- From nobody Thu May 15 05:55:06 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB991A0069 for ; Thu, 15 May 2014 05:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 IFi3ytQbD_yC for ; Thu, 15 May 2014 05:55:01 -0700 (PDT) Received: from na3sys009aog131.obsmtp.com (na3sys009aog131.obsmtp.com [74.125.149.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33601A002B for ; Thu, 15 May 2014 05:55:00 -0700 (PDT) Received: from mail-ie0-f181.google.com ([209.85.223.181]) (using TLSv1) by na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID DSNKU3S5HQ28vC17tvlJ9lHFqq5052BKCDlC@postini.com; Thu, 15 May 2014 05:54:54 PDT Received: by mail-ie0-f181.google.com with SMTP id rl12so948741iec.12 for ; Thu, 15 May 2014 05:54:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=w9uLC4hZ8w7rYjRScKbCqiqpAGTVhPJDyvwzm/2+AF8=; b=Kk8YzEPPodgifgC5cHvA/Q0W8ht4VcLytfly/OikmAJgQw0MovS4IRBMO56RS/rWIC 3gjqEX6AbA6LGhpcGPy4oaqW6GdPSCi2LhH+XzuLbh0vTNasBnuP2BOEd0HXzKZhbhMU huGez366MhH+vZCkZH8kw73GL0tRrq/NjgxBgxsRxibcJjpcAx1AWm0bzs/B9uqqWWIP X9dbcld37AYSGO4X0Gc9YwghV+/pBrDKZeBZKFTE+XghbvMLRMx7wzEXRQZ5SP9HH1Ed KsBfClOoh6akuKl5hW5vW4ahi+0oj16HxqeBXb1pO56WlVgnTuakAeRbRtun1u7bt9Lw agbQ== X-Gm-Message-State: ALoCoQnW4CQ2vDF2ygQZhgSVH6kecTGK3WGCMteMSw+KNtHoP6T7lH4Ey3kZZdYry6KdmFhRnclSCn5mbsXp20yF9vacqnxtKobejcDhksxs7E7MTJKU/qXYVllvpGyzLhPaB7y2bV2M X-Received: by 10.42.52.199 with SMTP id k7mr9514462icg.4.1400158493495; Thu, 15 May 2014 05:54:53 -0700 (PDT) X-Received: by 10.42.52.199 with SMTP id k7mr9514448icg.4.1400158493406; Thu, 15 May 2014 05:54:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Thu, 15 May 2014 05:54:22 -0700 (PDT) In-Reply-To: References: <536BF140.5070106@gmx.net> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> From: Brian Campbell Date: Thu, 15 May 2014 06:54:22 -0600 Message-ID: To: Chuck Mortimore Content-Type: multipart/alternative; boundary=485b397dd609a10f2004f96fcd14 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/rQ5ceAHrpWVjbVeysC531j2yuyQ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 12:55:04 -0000 --485b397dd609a10f2004f96fcd14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "We're still dealing with ws-federation passive profile in saml dominated world. The oauth working group shouldn't repeat that sin." Well said, Chuck, I couldn't agree more. The world doesn't need two different OAuth-like SSO protocols and all the confusion and interoperability problems that would come with it for years to come. And that's what we will have, if a4c diverges from either OAuth or Connect. And if it doesn't diverge, it'll just be a restatement of parts of Connect in the IETF. I think that would be a waste of the valuable time of this WG, which has other important work to do. On Wed, May 14, 2014 at 6:31 PM, Chuck Mortimore wrote: > a4c is connect. For example here's the sample requests: > > draft-hunt-oauth-v2-user-a4c-01, section 2.1: > > GET /authenticate? > response_type=3Dcode > &client_id=3Ds6BhdRkqt3 > &redirect_uri=3Dhttps%3A%2F%2Fclient.example.com%2Fcb > &state=3Daf0ifjsldkj > &prompt=3Dlogin > Host: server.example.com > > OpenID Connect Basic Client Implementer's Guide 1.0 - draft 33, section > 2.1.2: > > GET /authorize? > response_type=3Dcode > &client_id=3Ds6BhdRkqt3 > &redirect_uri=3Dhttps%3A%2F%2Fclient.example.org%2Fcb > &scope=3Dopenid%20profile > &state=3Daf0ifjsldkj HTTP/1.1 > Host: server.example.com > > > The primary contribution of a4c in this case seems to be malformed HTTP, > and implying that implementors should deploy a redundant authenticate > endpoint. > > Sample Responses: > > draft-hunt-oauth-v2-user-a4c-01, section 2.4: > > > HTTP/1.1 200 OK > Content-Type: application/json;charset=3DUTF-8 > Cache-Control: no-store > Pragma: no-cache > { > "access_token":"2YotnFZFEjr1zCsicMWpAA", > "token_type":"example", > "expires_in":3600, > "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", > "id_token":"eyJhbGciOiJub25lIn0. > eyAic3ViIjoiNWRlZGNjOGItNzM1Yy00MDVmLWUwMjlmIiwicHJvZmlsZSI6Imh0 > dHBzOi8vZXhhbXBsZS5jb20vVXNlcnMvNWRlZGNjOGItNzM1Yy00MDVmLWUwMjlm > IiwiYXV0aF90aW1lIjoiMTM2Nzk1NjA5NiIsImV4cCI6IjEzNjgwNDI0OTYiLCJh > bHYiOiIyIiwiaWF0IjoiMTM2Nzk1NjA5OCIsImlzcyI6Imh0dHBzOi8vc2VydmVy > LmV4YW1wbGUuY29tIiwiYXVkIjoiczZCaGRSa3F0MyIsImV4YW1wbGVfc2Vzc2lv > bl9wYXJhbWV0ZXIiOiJleGFtcGxlX3ZhbHVlIn0=3D." > } > > > > OpenID Connect Basic Client Implementer's Guide 1.0 - draft 33, section > 2.1.6.2: > > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > Pragma: no-cache > { > "access_token":"SlAV32hkKG", > "token_type":"Bearer", > "expires_in":3600, > "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", > "id_token":"eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso" > } > > > > a4c seems to toss in a little confusion with an arbitrary example token > type. > > We're still dealing with ws-federation passive profile in saml dominated > world. The oauth working group shouldn't repeat that sin. > > -cmort > > > On Wed, May 14, 2014 at 2:40 PM, Anthony Nadalin w= rote: > >> There are folks that are not implementing connect for various reasons >> (i.e. security reasons, complexity reasons, etc.). thus this is compatib= le >> with connect if folks want to move on to connect, we surely don=E2=80= =99t use >> connect everwhere as it=E2=80=99s over kill where we only need a the fun= ctionality >> of a4c. >> >> >> >> *From:* Chuck Mortimore [mailto:cmortimore@salesforce.com] >> *Sent:* Wednesday, May 14, 2014 9:39 AM >> *To:* Anthony Nadalin >> *Cc:* Phil Hunt; Brian Campbell; oauth@ietf.org >> >> *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering >> >> >> >> Can you point to one publicly available or publicly documented >> implementation of a4c? I've never seen one. >> >> >> >> I will say the a4c spec is almost 100% overlapped with OpenID Connect. >> Some minor variations in claim names, but it adds 0 incremental value ov= er >> what we have in Connect. >> >> >> >> Connect is being successfully deployed at large scale. It would be >> irresponsible for this working group to confuse developers and the indus= try >> with duplicate work, especially given this feels more like an argument o= ver >> signing IPR agreements. >> >> >> >> -cmort >> >> >> > --485b397dd609a10f2004f96fcd14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"We're still dealing with ws-federation pass= ive profile in saml dominated world. =C2=A0The oauth working group shouldn't repeat that sin." =

Well said, Chuck, I couldn't agree more.

The = world doesn't need two different OAuth-like SSO protocols and all the c= onfusion and interoperability problems that would come with it for years to= come. And that's what we will have, if a4c diverges from either OAuth = or Connect. And if it doesn't diverge, it'll just be a restatement = of parts of Connect in the IETF. I think that would be a waste of the valua= ble time of this WG, which has other important work to do.


On Wed, May 14, 2014 at 6:31 PM, Chuck Mortimore <<= a href=3D"mailto:cmortimore@salesforce.com" target=3D"_blank">cmortimore@sa= lesforce.com> wrote:
a4c is connect. =C2=A0 =C2= =A0For example here's the sample requests:

draft-hun= t-oauth-v2-user-a4c-01, section 2.1:=C2=A0

=C2=A0 =C2=A0 GET /authenticate?
=C2=A0 =C2= =A0 response_type=3Dcode
=C2=A0 =C2=A0 &client_id=3Ds6BhdRkqt3
=C2=A0 =C2=A0 &= ;redirect_uri=3Dhttps%3A%2F%2Fclient.example.com%2Fcb
=C2=A0 =C2=A0 &stat= e=3Daf0ifjsldkj
=C2=A0 =C2=A0 &prompt=3Dlogin
=C2=A0 =C2=A0 Host: server.example.com

OpenID Connect Basic = Client Implementer's Guide 1.0 - draft 33, section 2.1.2:

=C2=A0 GET /authorize?
=C2=A0 =C2=A0 response_type=3Dcode
=C2=A0 =C2=A0 &client= _id=3Ds6BhdRkqt3
=C2=A0 =C2=A0 &redirect_uri=3Dhttps%3A%2F%2Fclient.example.or= g%2Fcb
=C2=A0 =C2=A0 &scope=3Dopenid%20profile
=C2=A0 =C2=A0 &state=3Daf0ifjsldkj HTTP/1.1
=C2=A0 Host:= server.example.com=
=C2=A0=C2=A0

The primary contributi= on of a4c in this case seems to be malformed HTTP, and implying that implem= entors should deploy a redundant authenticate endpoint. =C2=A0

Sample Responses:

draft-h= unt-oauth-v2-user-a4c-01, section 2.4:=C2=A0

=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0HTTP/1.1 200 OK
= =C2=A0 =C2=A0 =C2=A0 =C2=A0Content-Type: application/json;charset=3DUTF-8
=C2=A0 =C2=A0 =C2=A0 =C2=A0Cache-Control: no-store
=C2=A0 = =C2=A0 =C2=A0 =C2=A0Pragma: no-cache
=C2=A0 =C2=A0 =C2=A0 =C2=A0{=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"access_token":"= ;2YotnFZFEjr1zCsicMWpAA",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= "token_type":"example",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"expires_in":3600,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"refresh_token":"tGzv3J= OkF0XG5Qx2TlKWIA",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"i= d_token":"eyJhbGciOiJub25lIn0.
=C2=A0 eyAic3ViIjoiNWRlZ= GNjOGItNzM1Yy00MDVmLWUwMjlmIiwicHJvZmlsZSI6Imh0
=C2=A0 dHBzOi8vZXhhbXBsZS5jb20vVXNlcnMvNWRlZGNjOGItNzM1Yy00MDVmLWUwMjl= m
=C2=A0 IiwiYXV0aF90aW1lIjoiMTM2Nzk1NjA5NiIsImV4cCI6IjEzNjgwNDI0= OTYiLCJh
=C2=A0 bHYiOiIyIiwiaWF0IjoiMTM2Nzk1NjA5OCIsImlzcyI6Imh0d= HBzOi8vc2VydmVy
=C2=A0 LmV4YW1wbGUuY29tIiwiYXVkIjoiczZCaGRSa3F0MyIsImV4YW1wbGVfc2Vzc2l= v
=C2=A0 bl9wYXJhbWV0ZXIiOiJleGFtcGxlX3ZhbHVlIn0=3D."
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0

Op= enID Connect Basic Client Implementer's Guide 1.0 - draft 33, section <= a href=3D"http://2.1.6.2" target=3D"_blank">2.1.6.2:

=C2=A0 =C2=A0
=C2=A0 HTTP/1.1 200 OK
=C2=A0 Content-Type: application/json
=C2=A0 Cache-Control= : no-store
=C2=A0 Pragma: no-cache<= /div>
=C2=A0 {
= =C2=A0 =C2=A0"access_tok= en":"SlAV32hkKG",
=C2=A0 =C2=A0"token= _type":"Bearer",
=C2=A0 =C2=A0"expires_in":3600,
=C2=A0 =C2=A0"refresh_token":= "tGzv3JOkF0XG5Qx2TlKWIA",
=C2=A0 =C2=A0"id_to= ken":"eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso"
=C2=A0 }
<= div>=C2=A0 =C2=A0 =C2=A0


a4c seems to toss in a l= ittle confusion with an arbitrary example token type.

We're still dealing wit= h ws-federation passive profile in saml dominated world. =C2=A0The oauth wo= rking group shouldn't repeat that sin.

-cmort


On Wed, May 14, 2014 at 2:40 PM, Anthony Nadalin <tonynad@m= icrosoft.com> wrote:

There are folks that are not implementing co= nnect for various reasons (i.e. security reasons, complexity reasons, etc.)= . thus this is compatible with connect if folks want to move on to connect,=C2=A0 we surely don=E2=80=99t use con= nect everwhere as it=E2=80=99s over kill where we only need a the functiona= lity of a4c.

=C2=A0

From: Chuck Mortimore [mailto:cmortimore@salesforce.com]

Sent: Wednesday, May 14, 2014 9:39 AM
To: Anthony Nadalin
Cc: Phil Hunt; Brian Campbell; oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

=C2=A0

Can you point to one publicly available or publicly = documented implementation of a4c? =C2=A0 =C2=A0I've never seen one.<= /u>

=C2=A0

I will say the a4c spec is almost 100% overlapped wi= th OpenID Connect. =C2=A0 Some minor variations in claim names, but it adds= 0 incremental value over what we have in Connect. =C2=A0 =C2=A0<= /u>

=C2=A0

Connect is being successfully deployed at large scal= e. =C2=A0It would be irresponsible for this working group to confuse develo= pers and the industry with duplicate work, especially given this feels more= like an argument over signing IPR agreements.

=C2=A0

-cmort

=C2=A0

--485b397dd609a10f2004f96fcd14-- From nobody Thu May 15 06:23:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9F71A04C2 for ; Thu, 15 May 2014 06:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 oEb3pK5PjY-W for ; Thu, 15 May 2014 06:23:32 -0700 (PDT) Received: from omr-d02.mx.aol.com (omr-d02.mx.aol.com [205.188.109.194]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD7B1A04F8 for ; Thu, 15 May 2014 06:23:30 -0700 (PDT) Received: from mtaout-mae01.mx.aol.com (mtaout-mae01.mx.aol.com [172.26.254.141]) by omr-d02.mx.aol.com (Outbound Mail Relay) with ESMTP id D6165700000B6; Thu, 15 May 2014 09:23:22 -0400 (EDT) Received: from [10.172.2.191] (unknown [10.172.2.191]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mae01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id B2A7338000094; Thu, 15 May 2014 09:23:21 -0400 (EDT) Message-ID: <5374BFCB.5070200@aol.com> Date: Thu, 15 May 2014 09:23:23 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Josh Mandel , "oauth@ietf.org WG" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010108050702000202020202" x-aol-global-disposition: G X-AOL-VSS-INFO: 5600.1067/98035 X-AOL-VSS-CODE: clean DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1400160202; bh=9H+Z9G1DLHWjfVDS9YW6EYwqxJ2CERhv9ja2quDLwoA=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=isLKUpuuiGeIgWwDUZK4S1sk2ShcIbpoHZtr+t/kx5PfZoHe1HN0FrfDDtNvETAs0 uiLUQ9crpXrt+qkgSM0UHeVQ0m+5HLyGKyMUb0ceR1YYWTddzVV4ETgK6diFbgM5rk H2OU4oaYIEbxGJ1ePNGvEI3KPToIMaoIxjw3Fj4Y= x-aol-sid: 3039ac1afe8d5374bfc9200f X-AOL-IP: 10.172.2.191 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/IfDMrxEMgYrEyLYgEELzwkeByQ8 Subject: Re: [OAUTH-WG] Security considerations in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 13:23:35 -0000 This is a multi-part message in MIME format. --------------010108050702000202020202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit True... but isn't this then just a standard "phishing" attack? Even today, any app can attempt to start an authorization if it knows the client_id (which isn't protected) and the registered callback URL. The user has to determine if they think the particular app asking for authorization should be granted that authorization. Am I missing something? Thanks, George On 5/14/14, 7:43 PM, Josh Mandel wrote: > > Forgive me if this is well-trodden territory, but I would have > expected the security considerations in this proposal to include a > note to the effect of: > > "In a scenario where a mobile client is contending with malicious apps > on the same device that listen on the same custom URL scheme, it's > important to keep in mind that a malicious app can initiate its own > authorization request. Such a request would appear the same as a > legitimate request from the end-user's perspective. So in this case, a > malicious app could request its own verifier code and successfully > obtain authorization using the tcse protocol." > > Obviously this does not negate the value of the proposal, but it's > something I'd expect readers to keep in mind. > > In particular, it has very strong implications for whitelisted > authorizations, where no end user interaction is required. In such a > case, a malicious app could initiate a request at any time and the > user would not be in the loop to raise a question about its legitimacy. > > On May 9, 2014 4:51 PM, "Brian Campbell" > wrote: > > > > I notice that code_verifier is defined as "high entropy > cryptographic random string of length less than 128 bytes" [1], which > brought a few questions and comments to mind. So here goes: > > > > Talking about the length of a string in terms of bytes is always > potentially confusing. Maybe characters would be an easier unit for > people like me to wrap their little brains around? > > > > Why are we putting a length restriction on the code_verifier anyway? > It seems like it'd be more appropriate to restrict the length of the > code_challenge because that's the thing the AS will have to maintain > somehow (store in a DB or memory or encrypt into the code). Am I > missing something here? > > > > Let me also say that I hadn't looked at this document since its > early days in draft -00 or -01 last summer but I like the changes and > how it's been kept pretty simple for the common use-case while still > allowing for crypto agility/extension. Nice work! > > > > [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 > > > > _______________________________________________ > > 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 -- George Fletcher --------------010108050702000202020202 Content-Type: multipart/related; boundary="------------000407010901080300010702" --------------000407010901080300010702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit True... but isn't this then just a standard "phishing" attack? Even today, any app can attempt to start an authorization if it knows the client_id (which isn't protected) and the registered callback URL. The user has to determine if they think the particular app asking for authorization should be granted that authorization.

Am I missing something?

Thanks,
George

On 5/14/14, 7:43 PM, Josh Mandel wrote:

Forgive me if this is well-trodden territory, but I would have expected the security considerations in this proposal to include a note to the effect of:

"In a scenario where a mobile client is contending with malicious apps on the same device that listen on the same custom URL scheme, it's important to keep in mind that a malicious app can initiate its own authorization request. Such a request  would appear the same as a legitimate request from the end-user's perspective. So in this case, a malicious app could request its own verifier code and successfully obtain authorization using the tcse protocol."

Obviously this does not negate the value of the proposal, but it's something I'd expect readers to keep in mind.

In particular, it has very strong implications for whitelisted authorizations, where no end user interaction is required. In such a case, a malicious app could initiate a request at any time and the user would not be in the loop to raise a question about its legitimacy.

On May 9, 2014 4:51 PM, "Brian Campbell" <bcampbell@pingidentity.com> wrote:
>
> I notice that code_verifier is defined as "high entropy cryptographic random string of length less than 128 bytes"  [1], which brought a few questions and comments to mind. So here goes:
>
> Talking about the length of a string in terms of bytes is always potentially confusing. Maybe characters would be an easier unit for people like me to wrap their little brains around?
>
> Why are we putting a length restriction on the code_verifier anyway? It seems like it'd be more appropriate to restrict the length of the code_challenge because that's the thing the AS will have to maintain somehow (store in a DB or memory or encrypt into the code). Am I missing something here?
>
> Let me also say that I hadn't looked at this document since its early days in draft -00 or -01 last summer but I like the changes and how it's been kept pretty simple for the common use-case while still allowing for crypto agility/extension. Nice work!
>
> [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3
>
> _______________________________________________
> 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

--
George Fletcher
--------------000407010901080300010702 Content-Type: image/png; name="XeC" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="XeC" iVBORw0KGgoAAAANSUhEUgAAAWcAAABxEAYAAABZ0L78AAAABmJLR0TIyMjIyMhnRJJpAAAA CXBIWXMAAABIAAAASABGyWs+AACAAElEQVR42uzddYAUV77w/W9VtY67MoO7u7u7BQ3uhEAI JLiEQIBA0AiaQIJrgkNwd7fBZ2CGGcatp7XqvH/cy84+uzfPZjfszX3u259/hq6u+tU51XWa X506dVq6dOnSpUuXhMDNzc3Nzc3Nzc3N7Tfp3v6jZs2aNWvW/LOL4+bm5ubm5ubm5vY/y+XL ly9fvgzyn10QNzc3Nzc3Nzc3t/8XuBNnNzc3Nzc3Nzc3t9/BnTi7ubm5ubm5ubm5/Q7uxNnN zc3Nzc3Nzc3td3Anzm5ubm5ubm5ubm6/g+6PBrBa7Xab7T9fyIADHckghbJDaghirBQm+YG2 z1nCEQbEWIpZ14EoY+mWVgFstd4kv/QC/ZoAf78jYMwLuho5E1ydzIfMF0D5hPPGoyB9Rwbb QF0sF9e/Aulg3i+ZX4KzkzU9exgYzwZfjf4RxDhbnCUZHB88O3B7FohVckNlH3DP9a06FLRX OSsyl4J6QBqjdAItT31oLgTWAVnznXGQNyKnTNZ+yCuWG5kzHPKSbf3VbLB4OzJsF8Hy3BqV sx7sg+1TrL1A/8x7nZ8NpAneIX7pYEnMPJmVBbnfZpHaE1ydpTVyRRDV6KyrBtpMzx8CosC2 Py8v7wgo/qYi5nuQNSnDI+Mb8DgVcjsiC7QE5SevWDB7eUZ7bwdh4qmxEui/Nm6U94M629VA +xVqDqn9fvnGUFOqVDz8OWilXYtc90BaJ9oRCcJfChYXQWqCmSAQebhwASD9Hx+kwn9MSXgP CRkI4FM+Bd0X0hJlMLy6mvQwbT0cWH+646V1IIz6564x0HtK01mNmoBzkrxEigRtl5iFJ/g+ 9/zGWADkpZK/vBt0V009zMfg+IwTyQcaQmYBq01tD08SkxdfXApeb4Jn5fYG+8NED+UuPIx5 Xeb5WpCu6trbNkJ2s9Tp4gpkD84d5/MpeN/UfWm4A8HL/JMLXoMSOwrnlFkH1u72CbpFkBae HJgXCtGNQ78Vw8H6iZpjmQyFDnnkRdYAv/4FP4ucAXnNrE/TPgc/f49OgXvhYpOYz/btAOu3 arfUJjAoouXgGV+A40e5u/IBlNtU4oPQjfD4s2df51SAA2MvHl82C7J9rJZrPcCrgzza1w9S 7idX8vGG+fcmR6+Y+Wc3czc3Nzc3N7d34d31OMsINCBLMuEH1EET50FaKl4LFaSR4qbsC9j0 m8UFcD5MW5LUAowBPgW8zoPmr32gVQOa6kqZvwL9eVn1OgOan4hRl4OwiBnOQFCuSRGiDnDO 65V/FzDM9k4IHADaZNcAxwXguKinVQMhu3bYm4DTJ9kvbjeoH+QNyOgE6khnc9vHIOZnJedM AseIrEPp10G6oDxTZ4FI1F2Te4Cy2nDHMBwMDUxZ+gXg6fS8Zj4I5iPmVR7VwPCBboL+JSie rnTHh6B3CsU5EkxrTBf1JUF5TwqTg0De4DrhCgCtkrOyrRgoXdQP7fVAn8REVxCYeuu7apPA mOZh81oH0mhHXXt38B7uedg8GcQ+tbyzOQStCukWcBo8l/kcCjOBzkuv09+CxyNjcmMPg2Wq pYpNA/l9Zby4C9og6XMpBKT57CAMRJIUiAUA8Tcp839QAQEUk0IRINWirrQenG3ES9czKDAr 3NuvPvS3dOje7AA02F8xpez3EPRzEAFGuDj0uv7OZ/BwxPM296pBdlTGYIsfcF1eJHcBQ2fG SV+DubH364gxoIQppe06CHnj95XVAjYlW+g9oVrfklvbtwa/XCmx6AnIOpy2NzAdfId7VA+s AIU7BHYvugqcOY5ixSTIPpeTx1O4X+SFclsPhReG1/VqC0UcEZZyFeDG5AcHM0fDG3vGpswZ oNsrjXpVD7y2yTWc38LrmskHnv4AN8vfr/XzLNC+tbTxLwxh4R6NOm8BXQtjX90Q8DplHqOL hmRn8reZsXD342e+Ry9DVvOsvo+Og6tNTnpuLqTfSRyTWRjyxthiXcf/7Obt5ubm5ubm9i79 4R7nv3AiIUAqLGxSEIiLPBFLQKsn3RGzQa6sX6qcBXW7JcFaGbgif2+YA/JcQwfdPFAmKsPV SyDuyH1ELdAGy/21MiCFiZW6sSD8NeHUgzTWudAyDKTS+skeQ0CdLT5xWUErl9DwUQ3Qkuy3 nFtAuisv0K0FwxnP4f5TwXnActaSAtJpVyElHlz+zr7OCeD62N7Q/hmoEUoLUQ8MC/Wt9B5g 2OJl9q4HcrRtpGMGoNhv29qC1wKptXQSpHOyVTKCOs81yV4a9I/kSwSAY6s8VhsI5rEeZnMM MD6ngOUXUCtrU7UZIJbazDm9QdqgBSnLwalaTNmfgmdRwyDPFYCC3fUhaCesG9JnAwb5ij4a rMNy5Tc1QL/E42BwAPgmBxT1nwVZdzJsGYvhxbiXn2UEQaVjZVqG+oIr1jVEA+gvf8h8QBNp 0mJAQhZx/EeS/H8m0BIGQBNxXAHxSCrHzyDdF18rFtBy1UbaHLA+oZb2EorbCo2JMkNi97SD yWWhZs/yO4t1hbBeAWmhyWDT1AOuM5D5a/Y9x1fwYExa4Wc/QvqXtp9flYZbV+Ii73eC1G8s ianeoN7PmZ+TBj6h+mK3MkCf6rfBuRYaLy3cqUINcJXXCsmJcOajO2eemEDeovshpDJIZUg2 JkCjzZXLNvkFKs8r5F31NWTfiTySeAEazK4tde8F9z+PefP0NTxu/MCy7RU8D7Svc1yEzFh9 4PNh4D0P1TQTqhcvd75RdfD/ODLVPw782wT6e3eG9CVvhmd9Aqlrsozia3i2+vEHSVVBNNQO myeBrW5WZtQX4EpUfXISIbM0N159DECDP7uRu7m5ubm5ub0b7y5xlvmPZMyPbEzAfqkZz0HX UoyiJ7iCtWtOAygrxBlxHZSbRSsUzwX1K7HAeQuUk85eWe+D+EQ/0OQL8nMtVXQBUVtuq+sL Un85gTmgxedOyVBAu5jXMbkT6PboK3vkgu2lGidGgdY3ZURCc3DlWhfYMoGp0tfKdZD7KU05 BkQZxnnfAd0D6ai+LHjv9vpIKQKOdo7dUndwFtZGqp3BtUgthjcY1ortxjRw9dUGi5ug2QmW poBXMa+quj5gz7auyP4O5GvOHa5U8Cyl7JOfg3zHfMUYCXIhNUMqCdJqe01nI7Dudra0FQU2 SX2UlmCfnKu33AZ9il7NOQjc9jgbVB6M3V29c4aB85j9Jc8gy5Xzflp38KwSODBtNujLhGml DoH3PN8Nfr/Ag2WPExJaQ6mvi2wLKgm62Tov0QHUyeJD2QhyXclT/ArijshDARQktP/jExQ4 AYEvhYEZop54CXIzWWEw5MblTrbVhMtTbla+2RUSy2Sejr8HuXVyX2udoMqbih+UnAymnh4N g0Ihdkli7+e94XvrgR+37wFdNd2BvK3gmqL/JrUvFL0b2CcqGe5/8fy+z2Jw7HEVtr4E7+tJ Ne5Vgohg/zalP4PMY/YWaT5QeHzA8obfwqtRb2odnAbvr23uatEbfFLtmw3joGx0ac8iqyCm RELaYx94lZSwNy4DLLds31t6wQvrmyJHLoNrnZivHAf/ctbUxIsgNlnXh8+G0nXLRJVfAUGB QaN8zoDnrzrN+hiS1idcS9VB0pbMr18eh5dyYsSzLyAoLuwSdyFr5fOw9NXAAb1dOgRZpTNP GruAfMens+dEoAZj/+xG7ubm5ubm5vZuvNvEWQbxFJd4DVI5IkkFYWO6HALyh/SS5oOo4tXT vB2kSxzWTwJ5sGyVHCA/NrSNCAQpAL0uG8QcfNkOkkscFXtAG58Xn7IIeKYL8vYD+ZLHpYAv QfXP7vZqOEgWqbpaFxQ1oHz4TNB+TLTEZoHWzNVYnQzKPU9rSBxw06R63ACRnvedOgFEefUz eTEYrNJLLQakCC1HSwIp117IZQFXAXm4czkoDZUKcgboDml5ylSQYsUTMReEpMzUjwROU1u0 BnOG6Ky1ATWRbnIpkHubH5vugTxf+U7nBbisYaIOWNu52qkzQUuRNiifgS3REmybD4ZTuLLW gLJe9wkvwPzM8NTcFdKjMlZbioDuB2K19ZBtlboYI8EnMPhptAS5w61tXZfhlT5eTp8LxdsU HxhcCdRU+69qKIhn0kL8ARvwX/3AugRogIomFQZpN7PFKhBHtJ7iezAfMy02mqBFcN0ntdbC 4ebn990eBTsPnVu9bT8c4d7S092h5vViI0tvAl1zSfW1QtQo38Jhx6HsriK1Ky2HlGJ5X7y8 DK/ltOBfa0FwA/9XziLguCA1si4D/zrm0eYPQPHOuZeVCjEn3wx39QGLp7XM6VtQdnmBguH3 IH5P+uX7aTD4VLsP+obA6uOb9b+EQGov29pHg6BOXMlSncfAk09epN1/ALkVxX7PIxA5xKuf 7jLYmmZX9XwFpT2LHa32K1T+uqCp5Gow/2jUeebBm2VJNTOeQ2zJpD03dsGB69cn7T4AIQ99 dc5y0PBk0aCW0yEi2f/TOhYw/moqLdWArFf+PSyr4E3FvLPxtf4NLbYKVagCh+cennt4Lmz3 3+6/3R+eNH7S+EljUFeoK9QVUPTLol8W/RI67O+wv8N+6JLaJbVLKig1lBpKjX9Dudz+r6pV q1atWrV/frvJLSa3mNwCus7tOrfr3L+Pc+zYsWPHjoGfn5+fn98fL+ez7c+2P9ue/7pQoUKF ChV69+fNv7sebm5ubv8u7y5xFghkwCiFkAoiXjyWPgaOMld8ClJf5bxcA5goTfYJBu2q2iV3 Eyi5Ul2lNjBaqmcaBeKFSJVmAs2lM6wGcUfaqJ0DKcxw1LM68KGy1VQctMuO2dk/A/O0YPEh yAV9RaAnyJZwT3MayKv0Lvk0sME003MtSOfkTeZS4Poyc7ZlMYjBdi97I5AGGuOURJBU+1FX CCi/2q3qRrCHO6Kc3qA67dccHwGL1M2iAugmS6UUM0izdROlXiD1NeV59QGRKjpoL8DVUA11 ZYF5lXpMzgPXLX1hZSEoC3UX1QcgH5GaSHrQyud1s/cB9YljN7vA+Iku1zwR1BhnFfsoyNmW MzKtGZhVryF+DcF3vq/TcxvkTs/ulPE5UCI1NHYM2Kcbqxi9wRDrGxW5BZ6ufhmZ9j0UOVVk T3AYSD9K10RV4IqIkcsD5ZDES8ADHX6ADQdWQKBhAilC0qOBOCjuIIAo+ssPQKmq+0DMAecu ZwHHXQgc7CuplaGxV8VG0evA8pFhxbPjoKutHYsZDVKTrJRKGVB1YLntNSvBj2G/tvj5KoR+ FDrQVB1qjirzYb2h0GZ2udMF5sLjIlmTXifDrgFHLv5QDQzjlZvJxcHaRA30nQm3Eh97BjwA v56GNN9VEOP5XLq8F77usWWjwQFBPQyd5Klg7Z8ZG7gT1FKKSDsJEa8D1hQ9DrmDLeeiD4NF tjQ43wJMHTxkqS7cKPS4xaV18KRunCGmBMgtzZkeZki48eZW4noIT/N8FvgQyqcGHGx2DXyL BlWO7wf+zgIdSi0BrZmuVPILyGuvrrH4gT5E7Hm4BVLLpSYkXQCg+LtssAtOLji54CRsb7q9 6fam+cv1Lr1L7+IvifVDj4ceDz3gYfeH3R92h+vNrje73gzmj5g/Yv4I4AY3uPGOv03cfreQ 6SHTQ6aDMlIZqYz87fU8xnqM9Rj731euHgt6LOixIP/1XxJa/PD7sw6Wm5ub2/8g7y5xhv/o ydQLgReQwXNuAbFYxCqgPGGSGUSolq6NBW2RyztvNEgT5YNmC0gzjQf4CqTFYqm6AEQ6wSIQ hEGurKsCUjVr7+xccMm0zDOCMsdjtG8/kNr4XfLtDbrrcje5P4iNrpnaFpB2Fa0SVhak0rpS usJAT3W9ywJKdZmEumA/4pyT+h44w7P658SAK9VyyBUI1mrW67a+kPe19du8l+Dyc6WLHJC+ lrbrWoKyTD4rLwRjfUMl40AQZQ19pEFgn+BMca4D6Yg6z1UH1ApaCSUEpNpaJ9EAZIf0yNUY XMMcIxUJPH1MNqMdXFvtm+27QDvsKuS8C/IO3Sz9QrDF2b5Xj4JdL0JySoHphE+G7jUYy+rv 6iaD4u1U7FvBPjRjYsIz8LrqOz9gG1hPWWuYykD2FzkXbOngk+WdYLgN6i51lngFNMJBXRBF xAztB5DypE1SLHBCWiblgsgkXNwDNG5THDhHM9dI0M6IOOUkyOdZYywKaZ3fZGRZwLeEPMdh APU9qWFmDqSHZapUBFWfNep+BhzMuXrq8XkwvTLJqXXB8EifHlYIMkrkzDNPgtNtkvdb0yFp adqXt3ZCSo6zfaoZ1I65nwkvMD3UaqTXBu2CbUjSTRC3g3uFVIQKqZGDas0Hx0nrLtcGyOoi u5wdodDhiMF1RsDjwMd7En6CsNDAZf5NIXlQzsL0cZBS3RKW2goM3fKOOqZD9XZlejQxgf1J TmKgF7yJyWod0wOmNuxpGuQLurb6SeYP4ZUzpVV2BYgxxB49ehp+vXBp0pZL0OyLal3fGwE+ 39iPhzyBY/WuzrhRC3IWa688vwd289W7aFqnTp06deoUbP9k+yfbPwFjHWMdYx2YmTAzYWYC NP2u6XdNvwPpnHROOgens05nnc6C6aHTQ6eH5idAZ61nrWetUJ/61P/v+Y5x+y9sbri54eaG 4Pfa77Xf6z+7NG5ubm5uv9e7nMdZ+s9b/RapIOAhlRPdATP3pS9AeklpZSCooY4ZaXWA4RZT 9gcgCzJ0x0DrRys5HKTTYjhfAR7SAeUIUMTWO/shEK+zmp+BssrT278TSPV0U4x9QDpCU0UF rYCW67wC6jP5jeMByBu1M2wE1jvmOCaAqIq/8wdwhthf5sWAVEM8UKeCLkp3x9AMbFdze1ly IKteWnbmQrBrlrEODcQDNVvcAd0EOUOpAB4+hrvmFPD8wDDUozjoW0m95ATQLombLAD6Kxv1 v4IuxBBmKgK0kwbIC8A1x5XpfA/0H+rPyb+CsbHRpDQDrwnmRM/7oP9VKWwIALFKXaA2BP1e ZbXsB9pWl92uB7uXxSPVBrJTvukyg3ZAaqwdAduG7F4ZhyD9TnzxB7tBzXZsse6G3NmWh44X IG2SsqRWoC0T59WLoPtZSVA2gtlgGONRA5R5ssm4HNgsgiQPkMqL+dI+4BTtyAMGi1D5Y2CJ NFwaCFlVc/ZnxIP5vLkGPpBTSC+SjZA53GFKvwCx6a+PJCwF1zx5cl5fyPjCWTzpHBTc4Dcs ag+4puVV8pXgwftxd68Hw+HnN1pv+BhezkjZ9qwwNC1bfH3jD8AQKZl9O4N01zBDawSmTN+W eiN412BctSPgOkPVrETImeqc9uQMxH6T2Co5EhpVrWQJuwIlz/sVDZZBd1h579Y0iAwNuGI4 Dsbxds/A0dCuZJ3Mlh4wzntI4aFLIfB1yPdeq6DplJqFquwHyeG1RoyDg/0uHTuwCX45ebz5 tz/BoyIvTa9WQ5G5odUDj8CTHY9jT5+GJFvSN7caQ43bJaaUbg2FjgVsevns3TWurVu3bt26 Nf/1iBEjRowYAS12tdjVYlf+rXR5pDxSHgmNnzR+0vgJTNw+cfvE7dA6pHVI6xDIPZ17Ovf0 38dP2JuwN2EvjN88fvP4zVD/Yf2H9R9CfY/6HvU94NMmnzb5tAkktk9sn9j+vyjgf/Z0v+0J 79SpU6dOnaBWrVq1atWCjp93/Lzj57BtwrYJ2ybkr/9WZmZmZmZm/i38t38f1n9Y/2F96JbR LaNbBmx4sOHBhgd/v9+NGzdu3Lgx/3g0D2ge0DwAThY/Wfxk8b+P+3Z/76z+/0P8s/VQr6hX 1Cu/PZSkWbNmzZo1g3uGe4Z7hr8/7ntm7JmxZwZ0K9KtSLci+Z938xfNXzR/AQtPLDyx8ATY ytjK2Mr8drlvyjflm/Lfxxl0edDlQZfhRfMXzV80/+P1/cPnm5ub2//vvbse57djZLOBEJDq YWcHMJyeojOoXaRW8iKQ4SlLQL2d/PzpK9BizVkh3UD2NH0hlQOtPpUoAwwUN6SBIFXTd/IE JE/DfqknSI+1z7VYwK4FqDtANJVP6goCHtp5qR9IHaiqPASS5CpSJjBSjNYNBT5SndoIkLZ4 9Q/YCfohfpmhdhADRH91M/hPCG4bsh3MM9NaZUaBdsi6wtoJ5CRpCplACUeCbQ/o2srFlLVg 83RFCy/IHW/v4GwM3HBWdfmDa5M2zhEDTod6Wa0GPBWb1eOglGca74H0pfKToTEY9tJGWwlY zMFEgKun47y+CNCHhqZMcFR2/uCYD9p8McZRHly3HEutIaD96Lzs8gXphK6EoQwYu5kzfc6C 7UlGyeR+YHmVXjzBA7K+yU6I6AuFChdoHjgKlFtM1n8OL29n+sVvhbzOeW3in4HfFY/LvvMh aJp3hWK/gKs7e10hIJUTCXJRQEij6AdSPS2YZWCoYdIZ/CF6RVhiMS+wfCuOigGQdD3m15dD IbiQ3yprITA09uyXokF2UPokmx9cXPx4cMoOMA4z1sx6Bp4llLaer8F8Vpuq/wqCWpvOVHkf xIfKXEkPAfs8egV8BR57lMyoI6DecGUbv4Yqi6uUKf0YlAhpY6HzcHbQ+dLnJ0Nnr2pJLbpD 2ZbVjpT6BV5YXl3IHg6peS8rCF/wOxP6a+Qk8An1OPLYAYYRpmGeKvz4aKfzwCm4tzGu9uVD kJmctcBvK6xrdyBze0Hw9/Pv7N0bimdFt/EdBdqI3JqaA8zNPPaHPQfdAf01ezr8Gn2l1bHK YE7yk32Xgrmmbp1/wz/erMRQMVQMhds/3v7x9o9ABSpQIT8x/EfaR7SPaB8B7Q+2P9j+4N+/ n7ckb0neEhh+fPjx4cchKSkpKSkJ6o6pO6buGHCUc5RzlIOT2SezT2bnDwHZmrs1d2sueHl5 eXl5wY6dO3bu2AkLui/ovqA76Jfql+qXQhWtilZFy0+MFg5cOHDhQJB3yjvlndCNbnT7v5R/ wvYJ2ydsh8Tmic0TmwM/8RM/5b+/L3Ff4r5EWLp06dKlS/MvIIrEFYkrEgcz987cO3MvsIQl LPn31f+fNWDAgAEDBvz22OFSpUqVKlUKvujyRZcvuvzjeP9qPTYV21RsUzEo2KVgl4JdIG53 3O643flxCxQoUKBAATA0NDQ0/NX5/PMvP//y8y/55TPMNMw0zISqalW1qgrPaz6v+bwmbIve Fr0tGnKO5hzNOQqf8zmf/xflnzZt2rRp0yCCCCLIvwC8M+rOqDuj4HPH547PHbCOdax7B5/b v3q+ubm5ub27HmcNkEAqgItcEN9RkLYgarBQ2gry+4S4LoG8Tt5jvgmOhXmF8yaDuK6anAEg 95SeSlVBbCGRQ0CkVFVMA+mY/EJ5AuKpqCx+Aa2p9r22D1hIqpQLkoVrpAN15Tq6wiAVlZYb IkBL0AZLGkjlRQktFJQAKdI4FpRZ/ms92wBlPPzVASBX8alrsINZCzlpigTzAvM61wrwHhPY V0kB42Ovr7TiYGvoHGMZBhmTMiqkHAHL86xJb7qB+koUdhYEbSVb1JHgXGYf5vwSXJ+rt0R/ cAwWJqkciM/kYnI3UG7Kq3TLwfyVcZuhHfh97tXeczz4nvFJ85kAppbG6mZvMIz0KRzwM2hr tZXSG5B3ilLEgW6NfB8PECtcPRw6UCvbf8jJBT5VPjLVh8y7ifongyFtd1q99BrwIvnVmqSl cHTq3fe/bwkbTx3pv2wTLPth65EfrsCPx49P3VYRXg5KHpuUDPr9YpPuO1BzRX/pM9DaaMkU A1N93RVdeTgbfDvral+4WTW+1+O2wHRXhvILeIYoY/xWgdnbs6jxEzAU1ocrVkiblrEh9Tgo O5XphsPgOUXfqEBXyJtmme45AsIzTVLUZvDf6jNVHwfGr8ydc09D22U1JlTrB2oIN/JuQtnD xfr6dYATDc6FXD8Kh49e+eDcKag7s8JPPa/C2UG3C7/5BNbOXn/w0HiI9Y+bFDMBjMHGhl7e oJaVv7VvgapLS45uPRVS02MX5apwMfdm23PNoEFaldyihyBgTKCr+BIw9zfucswBS0Vrr4zB 8GzGizEJUyHGmtrtUTCcv/7wxq5TcGlUrGv3fLBHilLqGXAOtBbOuAaxi5L0yq9/vFlZlliW WJaAs4KzgrNC/vKgoKCgoKC/X3+xZbFlsSX/YbK//fvNN9988803+esfSjmUciglP/F47733 3nvvPVjWb1m/Zf1gxZUVV1ZcyV/+dr0Dnx/4/MBfZUAbHm54uOFh/uu3Q0i+q/hdxe8qwozQ GaEzQvPf39xoc6PNjf5x/et9VO+jeh/B3rZ72+5tC12PdD3S9Uj++z89+OnBT3/VI/g2Advi vcV7izcME8PEMPHb8d9V/f9Z8fHx8fHx+Ynq3/59u5/f61+tx+H5h+cfng+7puyasmvK38dd v379+vXrocSiEotKLPqr417vp3o/1ct/Pav9rPaz2sO3g74d9O2g/DsA+jv6O/o7cOSLI18c +QJsNpvtLz+Y9VfePgS54/mO5zuew/Kyy8suL5v//oN6D+o9+Kv9/bs+t390vrm5ubm92zHO MuBCEc+BIDKwAQp7yADxQjuqLgMxXcxwdATDHJ+ZIYNB+UxpK5cHsVj0FZ+AlCyly1WAweKe sIF4Lh6J7sA1mspnQA5SbAQC81gvhgA28UyrBEQilCEgFRX1RUvgoTxAHQdaF8rL20FaQU8x CmiQWSJBgzztec/7D8GRl7Ehqz5Y6r9ql/ohaK114Z7eoH1pyvA8D3nv57RVvwZxXhtrKAiy QdfDGA/OEWo1xysgU7pu8wLnaUKUuiCd9tN79YPUCzlSXi7khGdnpg0B2xc5K7KPgffnpkEe 40CqIi+WS4LJX1mmew/k7rrTSmPQy+qvrulg66l36AuDaxvfiBtg3OCa42gF1FLKEgkiyvVS 7gz2O45HeRPA9LF+oTEalDgt3bgLckdnHs/ZAttWHnhx4QTcu5p+bW0t8DhlqFH0Lig91fnR reFm7/vlL38KeeNsufZvYeL+HkNmFQVDO3ms0hWUFrqe2np4UCoh+ckc0I03lkxPANmleWfu gHtzYzfcvAkpl2yeKYsgtJXO2z8GbJNyp+QdB+N3XneMq8Evx2O3cxZ41FYP6LeA/bzuoO1T MJ0KsUsDwTDHNEmNhyRPy5GEKpAd70p5/RJqeBVTW+8Bzw26fR7noXbH8t3uH4FrXe4etN6E qpNqFDQ0AEc/ppQMAj9v095kXyi+sFyJmhmw98Xx5xuagu5TIlPjIesDw9MmRnD2tN4Vb6DQ xdD6RapBnHfCibzecDbxcakbHuAbZD5jnA72a9bCKTNAO6jOMkwH355ehy0NwVUuY6brI0j7 2mk0zQDnJd007RhkdrZfyCgHuQXzyhtbAZD5R5qU+YH5gfkBSGukNdKa/B7ojG4Z3TK6QfDP wT8H/5y/fmp0anRqNMQVjiscV/jv46W2S22X2i7/9f0f7/94/0cgnHDCYefOnTt37sz/+1ve bmdNtCZaE+H1w9cPX/9V4txoXKNxjcYBrWhFK2i4qeGmhpvy338V8irkVchvJ1Jvjfph1A+j fvj7nt232/3tLfxmE5tNbDYR2MAGNuT3uC9lKUv/L/X4V+vPAhawgH/au55F4r+rHm+HXLz9 /N6qbahtqP1XQzkCWwS2CGwBFx0XHRcd/zhunbt17ta5C7SjHe2gWPdi3Yt1BwIIICB/SMm7 qm/LKS2ntPwvLhR+63xzc3Nze+tdTkcnkEG8kMJIAOkz8Z3UA0RBqb3YAloETeR4kGZrxfMS QR4VcD/SH9SeoqW6H3Qj2MZiEKfJwgkcJEU8BmknE6VUEAMko9CBiKCBHAgUE4O0uSCtphqP gBiWigNAZflrFoMoZVuQswO4oX/pWRhkVRkq94WcIs8Cn5SBZN3JXhd9wbrBYRJfg22V4Rfz OHD9Kv9kbQQGVfG2RIHpkOfH/r4g19GPkeaB5CfptFhQnFIz3WVwrVV/MHwLpsI+35m/gYwo a0JmL9CVzh2WNRDCFhtvmM+BtYLrQ1EApB+VwrrLoMWKYOIhb7DFM7cq2LpnNciaBjmjc75M fQbWxR6bvNuB/T1Xd1csiCFOXW5P8DhnjPCNBREtyquDQDcXLz4D4xj7kzxAaS0vc/qDroit X+4XEFjYp3BwLdCNef24XDMgTeuW8hWEvR9sdE0A5w3jJ68+ghdbHtW1RcE3GzYs+LE5DD7R ZXeXspDUKvFh9mq4HpYYeisCjn//wmveE/DZKr4OKAwZD1Kb2IeB0lC5Ly+A+GBpkNIaTKm6 muZOUOpMya/MVyCzUco+5y9gvBg8IycGStcRBVVveP1eYp3XC8GYKO3TB4L3cC9zgRfgUK3X lHvQbFn9zEa7wG+mV6B/YXh9K31D8AsoubBAO90ueK1/dd4yCpqeq51SaDM8injUT74AFcfV mFvqc8hbY//q/fpwrXvMxFfTwb9y0BWfufBUi5lzLQJabWu2tt9yONTg6qB7odCwUtFSehs8 nh1f8mF/8JhuHu99AJQDurTHMgR30G+xNILkbrqS3tdBGy6meIaCtFq9kbsHZJeyjK0Q2M60 TdQBzv6xZvX2Vn7p86XPlz4PD3jAA2D/rP2z9s+CgQxk4F+tPzdtbtrcNJjLXOYC+/fv379/ P3z22WefffbZ38e3XbBdsF0AutKVrhAwOWBywGTwfuT9yPvRb5fLtMq0yrTq99dDuiHdkP6r WTzejnW+wAUu/P3bv5XAaCu0FdqK/2L5UG2oNvSvjt8IZYQyAvDBB58/r/7/bv9d9RBVRVVR FXjIQ/7qQkmn0+l0f+B/k7dDM/7i7awvzWhGs/+++roTZjc3t3/kXU5HJyEAf5FGAPALMjHA HREptQMpgK+04iC3NFcM/AHEHrlw7glgiajAPkCvzSQceMxkDoEYg5+QgJaEyUtB+kGbpx0G cVoYtWFAR2Wc3BdEomgrJYC0mNPaUBAfKlHGFyAm5iVkXgetf27vuPog/eg93DsW8p5ef3gz GMRO70o+/cCRrO7QH4C8M2mtsvJAskt9c5uBY7lQLDshU5dZI2U36FbKP0iTQPdIuWnwBMlf XqibDR5zvGP9NoMyK6+lnwymlbmR2YMg8HtzCeMIcIXoWug3gRIkd1IOA32dk509wTBCjpbm QOBhw23fkuCK8Dxj7A15Zxw/+P8KaattZfQ3Iflb51xrJNiKp/bPOQraty67vT6YkqQrpktg WCudFzvA445cTikPxqZOlz0S1GUP+lwbAt72UjNKnAafLeHTnAMgeWHWXLsnOE5n9cmNgJxm ifqiV6BMj6h6zYdA6Pfe5QpshP2rjq853hlSrklfWb+HFwmJMy7Og4BbPkONX0OhLwMaeFsg 1qW9lqLBYXFpbIfiBJ+rcgouroxZfNEH4l+kP8hbAGGL9PX8voKQURFrzB+DcZHcoN63wKfK 2qQ6ED8hq8aTJlDQz+N45BQoPyvMWOsCxG94XSvhKtyenLn8ZTV48VFinZR1UHBq4fCgrlDi x6jTQdfBv7i/7LcJ/KsGrMv7EEQruZsuGQp1Lf1Tof6Q+qHlYzkJOr5q07rCXDg8cX9B5QkY k0yzrCOhnn+1wcXXgscVZYvzZyhTodSl4G5gl+wXDIFwQlxuGTsX7CvlNubeoP/K2Ed6ArrS jvE5QyA01qdRgASvom0VE65Doa99zvn+x9CElu+iefU43uN4j+Mwk5nMBFZXW11tdTXw3+6/ 3X87tJvRbka7GfkJyEXnRedFJyzdu3Tv0r2/HbdQl0JdCnUBJCQk6BzVOapzFIzsOrLryK75 6z0e/3j84/EQGxsbGxsLBecVnFdwHph7m3ube0N4YnhieGL+Q1inFp9afGrxXzqcObXo1KJT i4A2tKENRHaI7BDZAUwzTDNMM8CWacu0Zf7+4+GxwWODxwYIjg+OD46HlOiU6JRoONHjRI8T PaB9YvvE9olw6PChw4cOA93pTvd3X///Kf5d9Xh7h4Md7GAHmO+b75vvQ1hEWERYRP4QiLez vrRq1apVq1b5dz46durYqWOn/Hgnep7oeaLn/9z6urm5uf0j73aoBoCEigQ4pRD0wG4hUQhk G9/r2oAYJo3yqA/KFsMSZRWIx8JLnQ1qX3LU+yA9kVZq20CuJXYqHwNbRLqUBaKUsk2rDfJH ooZrDmgL1d6yDeRm8ieSHrTzYqJuHSgztLXOs+BsIJqrfpDre63m5U9A1BHznCdBmRoxNtgL sgvG3UorBylXk3MzLoPaz/Xc/ivkTkw9njIVnn+Usjf7DWQf0K0ydALlgLGRZ0EIeiF/YIyD AkHmoh49QFfOLGXPAvm0LuFVe/DN8psoB4FtghjuWgtSQ/1E79pgqGhc5bUb7I+1XnQDtZXc 0LgJDJ2Mp4zTQL6oN+hNIIXqTI5vwBDv88hQDkyNpE8CJ0Jitrrc0g20qnYpYyF4XjFUE2lg rikqS9XB/EZeovYD5UN5nn47SDXvFY25AAEH/co4h4HP+9GP4i9AXHzig9cfQ848Y730z6F8 4dIHO9UG32lW/2IP4K53wrCH30ByVmbHaxPA4BusJu0B+bT0iWMP+Nf2PubtB45H1o3SC/Ad YtjumwY5qY75wgFBWeZThqIQPtJzd6QKSU/iDFFrwFA1aKV1I2TNTzj79BeIHhocGBQDvXo1 e9GrFRx5em3RlqIQOzl7xZPzkHTRXjpzCdwfmB13+SfIycn+xrgHAir7fJdXHU5/eGJKfF/I +qnyTlcadPJt3j1cD0HrAx94fwanB1386WEstHzURCrvAy/mPO/0pgukLky/lD0VdGUNYdp2 8OvhX8YnDTxOBC5RPCH9WVKG1R+u269NutMYXnyf1e6pAP/R+hPBH4LlkHPTMwW8DumSbZPB 0Uh8ociQu8vRNbMyeBfQOga/BzmXlMEiAqj0bppV21/a/tL2F7i87/K+y/vgYMeDHQ92hDlz 5syZMwfme8z3mO8BsofsIXuA42vH146v8x8y+0tP7N/0FHY40OFAhwOw8fjG4xuPww/6H/Q/ 6OGJ5xPPJ575PYlvp7HjOte5Dutqrqu5ribQm970hn5l+pXpVwa+LPpl0S+LwqzIWZGzImHv 7b23997OfzjwrX62frZ+tn/uGPwf/rNHsuvarmu7roWVK1euXLkS5nSe03lOZ9hcYnOJzSXg RcCLgBf/l4co31X9/2zvqh5vpzm0X7BfsF+A2XNmz5k9B8bFj4sfFw8FbhS4UeAG9J3Qd0Lf CbAwaWHSwqT8Oxp7w/eG7w2H52Wel3leJj/O2zH2b+P/6fV9zWvc0wC6ubn9C95t4vwf09E5 MQEmPEUsALu1RGCbNIJaQDlRR9NAeEoxUgqIMtJaXS7QXAoXvUDaIxZzAdgtx8lTQf0le+iT KWDv8GLvLU+QJwT4Fx4A+izTU4MKrttWne190P0QVq5UR9Bk/eXAk6DrSD2lMjgi3izJawTp j9OGvzwJuKKehX4H8Xvjk5K7g/17+1XtAIhx4pgrCGzfWb/GBD6VPav7zYBC7QtXL5oKgXF+ lyNTwbOj8SsfE0hxumxagPOadjrvDFi9rScyBXDTEpoTCTlb0o8nAUa9Ty9jDBjjTUfktqB7 pCsmtwDpljxJ9xNIRykitQSppTglVQVdX3WTehyI1i7njQXPWM9B8lTwDPBJ8fEE19ncE1wH wwQR5mgK+kVqjO0omJ/aD6oPQT/No0PAMUBRFmYcAu3Ks/5pNyA1yllAbgL6JENbzx6gLLO0 dG2C+H6mtefLA8EBl/PWgMcOS5XiW8Crie/HXhFQrJHpWINT0MSn2s1q8+BV+bzGjzbBpvIn SqzfCH4eXo7g82CrlLJN+h7uNLE7vb4CzwLajRqjoXaruqmPUiC5QNLxrF6QOyhnnCsHnu/M 0V84Dmpzx3FjBNTbXPpF4/4QvjzBXqA++Bh94oPehzRTsjVhMHhdKDMx0gOym+SOiCsBpv6m G5Yn4Fpkj0vbBVu/21P92AAoYIiKCveG4u0i/AotAtci+y/qaCinlpkXMRael4498uYseC71 /tJQHIwFzS29w0G/ztVedIcsIb101AfDY79iZcZAG7nk+PobIKdrZr34SvByeopq/RZi5ezV ud4gezJYPw1M9txS9h9B8vUamJMNZg+yTWHvsG39Z6I4a+isobOGQuW4ynGV42Dn5J2Td06G 582fN3/eHIwmo8logpa7Wu5quQvGDho7aOwgGBczLmZczN+HDQsLCwsLg1UrV61ctRKWlV1W dllZuPTdpe8ufQfSdem6dB2qVKpSqUolGCmNlEZKUCqvVF6pvPw43Qp3K9ytMKifqJ+on8Dm l5tfbn4J1w9cP3D9QP5++jzr86zPM+h6uOvhrofJH1PyLxpYYWCFgRUgt09un9w++dOjJV1P up50HaZ6TvWc6gmzOszqMKvDv6/+f7Z3VY9hDGMYsHbD2g1rN8ClS5cuXboEeXfy7uTdARax iEXQ41iPYz2OgfxCfiG/gC1bt2zdshWur7q+6voq8KviV8WvCvSb2W9mv5kwcsTIESNHAC1o QYs/v75/Ox2hm5ub2+8l/ccXoxA1a9asWbPmPx/AarXbbTb+MqsGHoALuI0FCcRSPKQzIJ/n J+k9oAuzXOGgfaNutKeDFCc3k1uCVEj2NPYAbmr+Sn3QvtftF81A/Trl3u2TkDfy9LCDr0Ak 6MJ9e4GhdPjLkEwQxbIfps4HeZDvWu8GYJxepXUXL1DqSx/oOkBW3Jnpl1tASp+Xw+KWw1O/ eN2TZMial/FSiwLHz+r3WhIoNjXQ9hgMP8kGQwMIaxywMeALCB8VvSDyM2Cb8okuD7Rf5NHS aHC1JNcRDlS2Bzo/BbmLvrG+J/gdjr5csCgkHH56OvYbkC7L0+ShIG7J00QrsFWw37QtBRHt sqjLQOoousm1AKNm0maCusG+z/ozaPPUr3gG9ifyTCzwJjbv06xBYL2VtTBtNviGGp5KJcE8 0d6VLWAaq5UxFAW9zfehrwBBYq+cEDBZ1eXqUDg2pkzjVxkQ842840El8BloL+/1KWTuEScy Ncj4QN2lnobCU70Sa56Fkp6hSoXjII/TT8n7Faw17On6DRDQ3jRA9IRrPz8Pu7YCohO8x1df CGnpb0a/ugH6x57OAoUheWuW952CULhQaBNXPzB8Jr8ImA3cESdccZC2IeN1+hgYU7X/mG8K gn6N3NgzEeK8Xq95uAKO17zdc+dC0J9xbDSmg1rOsdbUE56/fFMzXUB40UBv7TJIGabPvczg +77u+6IXQPvW1kbpDTVaVCpYawgEefl/6NkTwi8VuO/XHI5aT1959ANk9kst8/IG1Pevd6r8 l2D3cxSSj4Lip1srLYfSe4p9EdUZducd3nGxFWyPOFFox3EI/T7Izz4C0udmVs97AOE19Zcs x0Eaq50TEoiISJ+0LIi6FNnbuyRMUnp/f+zbP7uZ/+/ztkd9VdVVVVdVzV/+9uHA0mdLny19 Fm4MvzH8xnAYdn3Y9WHX84eynD93/tz5c6Bfp1+nX/dn18bNzc3N7X+6y5cvX758+V32OCsI BJApeSCDVE9cRwJpNtdZD1onHMIb5HtsljuBGKmFu7qCUlYa75EF2hbRTKkADGGx+gSkbpqv mAZSDcdJbgArvAYX/BHEnuzkzJVg3Rj7YeJo0KY72ueuBKl/SqfMNNClRZlfXwDp06hXpc+C Z1TVPaWWgO1QWnDSRxD0vs+8yLrgHGnQLLtBa20TzhTwW+FZLepnMN9XktQgMBlFaeGCvGXW F9mTQOepH2eMBf0m1aauAO9MpZcoBaYPguKDn4Npb9TFwt+CUtx/skc9EOUzN1kuQPb71iN5 d8Fa0b7B5gDdd9IO3WlQC0gfiSygtWSXJoC8QG6tWEC000bpJoI4IA1RvwTDYiVLaQUBs00T fDIgd519QnZf0IU7v88xgbrG1t+hgFbdvMTnYxA4YnIWgGLynmFYB8i5r8SnoI3NKudZF/wn +tX2jIfKmWU/jI6B2OlPvyreDJKGppUM9AXFQ20grYOk7bYuWb3AFOtlk0KBPfK0ImvhWWZC b+t1KNhCvl2nN2j1crbqzoL4xhUdtAvUc7YT2UkQluvfolInsAbkZGZ1BEcdKZA8UPfTJ3cL 5H3n/MhmgRNJ16aemQzmJ+bDofPhatPH23+pBRU+LbgiwgHGcOsgv2i43vNOUlZXaHiwomj8 DFIa51R6GgWZB60rbxcGrxveZ4PGQomqpQNrN4fiuSWWhv0CL648u5/QBUzDM28bv4Lcewmn 425Byevl1kRmgHOebapshgLfRd4KssPtareUpxVAv9/VS3iC6ZFSKHU/eH3uuSfhBegPmyso kyDqquO4wwa27Z7bcIBxkC7BORCcI5VL5jmQMMdx0fEMmPlnN/X/nQzrDOsM6+DKkCtDrgzJ /+GKDSM3jNwwEkIjQiNC/2oM7tuHEJtNaDah2QTQp+nT9Gl/di3c3Nzc3P5f88d7nPPsdpsT 0NBwARoGFJAiSMMJVCOOayDG40slkJxYZTtoV7Qx9vYgXkoz9KdAmSclUBikonytTQRRQgRJ BhCjHOtyvgVrm2uPTjwC6/XHHR++AVdta/G8sWCo6NsvWAbDtBLDy30Hrln2r7KWgM/U6g9a 1AS5pNzTkAf2xy97PX8DueNuzbjRHC4dSjfmbYM3WmrB9CIQlez1jX8L0O1xdLfngGm09Ebp BMZzpuL6ymCMIcE1FIKjCzyPHggBsdVXVzsPshyuBj0AyaXvo9UC27PrK+9vhdwzsecTP4e0 QrlDc/eCNdn+yFEOtIXM0HLB8cZxw3EbRHVprYgByoveWnXgS1eSthi0MOdTzRPEUF2Qcg2Y aCxlTAXrOevJ7LmQuS3JN2Eq5OTcqntHhsCHQWNDDoJni8BDYQtAy/HdHXIArCe0BsZl8HCf p8veHiwLDA9c7cCwRNxTe4D23LpSNkP2Afu3qh9Y2mT+og0EVwHXjNxNoGZYY5w7wDbJucrW FHR5epfyDWh3nQ3svcB1QX0oh4Ghuj7OOAKopHQS/mA8ZBrrfRA8Hxh6yz1B975pgZgLjtLi ockbVJuusxYCSphuoZwKgZt8TznPgJfT76DnIqi4tuSspuNBee1K0QrAo5gn/Z9chcC0gFBz Y0honXDr0XOoX6BhSM1fwfXK+nHwbgjeGVrP/BC84zy7+ZSGvHT7EIrB66uxStZV0I5bXS/P QrnMqnMqZsKjOzFLXnWEWN/X1eOMkPJxss+zwhC/J21v/EegWHxy0jXwNJnmZu8HeWxGX1c/ sG/0CHANhIDq/uP9Z0PaAlffnClgnSj3kWtAbljmgswk+P74xI0X0v/sZv6/V/q89Hnp82DJ 2SVnl5yFC+UulLtQDrJ7ZffK7pU/33XzZs2bNW8GI2uMrDGyBpg3mDeYN/zZpXdzc3Nz+3/F 2x7nP544O+x5tucglZDCpdIgHog3Ih5IJEWqDqikkw5SF4JEEaAqy5WjIH4SI1wVgCnyDOkR SINFpJgErqUs0u0Huan+uf4WqNNj3hzbCy+2b568KRrSf8390LQJzA88P/EZA/69vaINVjCL gF+lNeDxsNrpBh5g9irbpWYRkCOJV26A+o3NlH0PXCuuJ9/8AZ5qTybc7At507RM8St4/yjN D7kF6jmWGVLBe5r3Lt+i4BFtjPLoD+aqni884sDsrJJYfDzwY7DDNwrETls522XQfWeZlzUH 8oIeHnupg9TdsZWSYiDHy/qhtTI4e0jtNAWEhZFiATgeO752fA+OoS6j9SuQpxMsigPntIv8 DERq0UpF0PZIfRUNSDO8UjaCWlUMJhlsF23vWUZC1tA3j/O2QubtzG62Z6BsDV0eMAXEDJPw /BEynY5d1t6Q/tqVndED0nKTRUYpsOgyp2StAVuspU7WY7Afc6x3ZYB+E7fl86CXdS0NG0A+ rx+o18AUYtQZYkHaKNuVOqA49MX0M0BuIveXq4A8WR4vToOYIUrJkaA1VTMpD85PtK+0gqDV oYXqDeKetk04QB4vT9Z3A2WKsbgpFozFTY+kOmD4yMcYvA70zXw9/GPA73nAjYBo0BU2lzIu AefzlPgX7SGztvWDx6FQ1CNSp78F6jbHPY9a0GhWw6iBDcE8XtfN2Q6c92WdmAxya0dh7yOQ V+FNxUdNIO+V9LHcHNitXZN2gGoSXYxd4GHp5x0u2kBssno+3QHZvXPHye+Bvp9pg2sEWAuZ b8XNB8Y6PpeWgtXsrK18CqZf/VrqYuDVw/S6GUUgrWFyTy7DXsfS1udq/dnN3c3Nzc3Nze2P eHdDNfKkAGk6iKria3EIJE+pGAagl7jDx0Aa4+gKopyUIxSQ6gqLqAOEKaukwcBRbbC0BkSi KKR9C/IPynNpL+g+y14d1xAeHtii23oNrn74fKvoAYUfl69b2QSlk+oPrXIBnAFx6x9fAN15 z/XyFdB3Dc+I3AByuH6e12egOV037EtA+dBQzXMu5I20W/TTofD1sGbRrcB6UBuTmwaJO19b HdVBDjYfMK8Dw0Z9mtILDEV925m/AAYbusiJ4KqZ80vWRdB/6bPN+AQwZ5zMzIHcHY9evigD ebMSv87VwNlLPSMSQXhKPkwH7Yg6WlwB7QLNtHCQjsiV5TYgt3AFaJ+AGipCHaVACpMOyYdB 7iFPlFNA7i5S1MqAXvucqeAooJvlexjyxnj+6nUf8oZFr3eWgrQavmXyxkJu7ZyF6Zsg44f4 8TH7IWNb4oskA+Q+zW1lCwE5Tr6tbQWvRK+x3uEQeMPvpv9sMOV4n/U6AMZdHqGmpaBbYYrS bwWdIq+XvwNtrYjjJogrwip2gxRFGzEVdKWkz6T9IF1Qjkt3AKM0Sz8TlAh5EZEg3xLLpGag hWm9lXugtRafuFqDOs5eWLND7i57lvUO2JpbZbUy5F1/E5TUGsTwtIvJrSGn0Jtqfk4wfehV 2y8EvD8wVnakgv8Kj1n+LeB2p6en7ALqqNEWKRye/nhnyYWXYHHIvT2WQ4HloRs9o6H2ppon GxWF636PJ8WsBesJo1VbD0ULF88L+g6M6+VJXhbQpalJZfuCX1nfddVqgcfZgK6BX8DJ0pev bVoDakrW7MSuEHjDY7Y0CjwKyrFVvoI7P705fLkIBDYL+cTUGtSNoqz97ewVcX92c3dzc3Nz c3N7F/544jxYfM8GoJ50T7IAMTSnBfCQHuID4EfOyGtBRLFEGQRSXe2lSweUFl2V8sB8KZtf QMuiMaVA/6M+ShcPuV/e87gaB2nN7+WkVIaCjyvn1k2CsuNbdqg4D3w3hkb5NgRnDf8XxVaA 2Ko9yxsOrrY5vbMbgvFS2GbJC6SmooqcDVpzxzz7GRCVnP6kQM5Rx6OgPWDbnH3FWQ2cvbI6 xX8L2h7bKNd8sJRSv5Q+AEOw0lDeCcYBZRzRXiD5stV1EVx9Ys+/soLjdPKJjHmgbcs2u94D V235mnwFXBOch7QKIDJcR1gO0qeYxAjQNZL3yN3A+ZWWqrUHVkqq3AWYqd3jaxA1RQmtCYje 6mbXp8AD/XjPmZDdUJrn8QEk5zjLaRZIE9bm2R9C2uLXO+LLQfLBV91f7oV08eazxA6gXVB/ dHUCz8v+GwMWQbRnsaKFXOBh9lO8boL+O8Mp5TC4Trg+1azg6GX7yqqDvLSsH7I6ghiXMVpc AXm7mCYZQdtKR7ETGCvHST6gK6As1G0HQ4rioxQBpZSSo2igMyu+8k+glZT3yItAbqckcwt0 ubrNkhEM1XULdeuBjebSeh/wzPQa5pULWnElQ64GzkzXclEd7JnW+q4qkHcx9/3cUmCrmro/ uxWkLlTmGo6DebXXJnMalBhbtlGdcDC+8AvwPgTljxY/EF4HguPCjof0ANN20w3DYDB2MwwX M6FSYLMV9b3BNNvcXHcQCGQFdUHpT7i8DQwdPYwBjcD2RrRS3wffquYfjDOgXFapLn3GwVO/ F9nPwyCvrUP/6hh4hQXqvOtCoabecU8WQHYxz7ys6xAWUaC+VznAnTa7ubm5ubn9r/EOepz5 VE0F3heH5I3ALIpJiYBdWkkP0HaJsaoOdCt4o2sMjjfSNFqB1EGcEUEgd1X6yONA18o1RV4N 3P6PsK5aKRmptaBIz7oda34C0SNHlPggFKRnXhUMdsgr/aLBg7Kghtl6Z+4E+bkc64oC09ZC 28pPAq2ra43ND9igvynNAK3lq+2ZU8HV0L5HdUHmzzmzcjpC1oE3M1J3g2urNcDWDYL7+Fb2 nw5B2wJaeIWB8qNSgAhQj75enJYGYlrh2JAVoGw12nQ+wFkK6Y6DKCwVcEWD0pjJkhGUw9pc eoNklF5IU0A6IjoTAaKKFudqAMp5aZYwgLJamir/DFpZ6ZLyAYhNhu0et8E+UP+5lwKpn6qj lFrw5uu8LRYfSKqX8PLFGUhd+fjNw6OQeiPlQfIJUNoaJxvzwP+biKLhX4LnyuC2Qa1BTtTH YAZnZ8t1WyBkP0t5mhYJju6OoVp5UOrLlfRZYPrEbDO8AY8Az21ew8FjhmcNz/Vg/NRDMTUB Q0/j18ZM0G3XL9CfAp2sVNEngvSRcgBvEDWEKvJAGikMWjfQLqkjtbugLdeOuRTQFrmuOvqD +NpR2TUMtIIug/oA0Dv3OfqDLtX1vmQFA/InuufgfdvLbJgFrh3ed41J4GzltGnxkPuRJczZ DCzb87bmjYen+y68f7IS2PMiDodfgRKu0BH1GkG4Lmpq4GegrRcBTido11wDzE7w6uVZi+OQ 2z/X1xoC8jn5Q/kSZK5N7235GEyDTMNNDoj8OuAL71xQz7mGaAuh0nvlvyq5GnR3TasKlobL /e6EPzsCtixlkWMKlAkpsaX4JrhxICZr7/eQe9ix/NFy4H/Qr8u5ubm5ubm5/TF/OHHWddMP MA0AtbizsLMFMEKaTX1gAWuluSCn8JG8FRwtXK0cRnDEpsx/MwAMYcZkkxPk9QEBAXfBtdHh 7agM8jOdKtUCw6pSNUtMhOCe0XY1B9RPvOxefYDJ2XcS34Bilbs5vwL1kXVFdjdQwkosq3Ud 5P2m6b5jgDpqQXUSiGC1rL0z5PV9USepCNiWZ39iKwCu1rZkbQpwTTrtlwOuE1JZVYbXLxMO JsWBK8CeaDFCWJHIEgWHg5zs6u1cCvpyTBQ7QZSPTA5+D/SRIQu9z4LYbIu3TQf8cm7ZN4MY qp8kroLukXqBxeBq4jigDgIhSw+pD2IQi6kOuoO6L4xdwWY3rvDeDllLDcfMEyBFs110JEHS e6+7xE6CpIr319zxhmTfV46XU4BbploeoRDYpoh30algLhtY0q85OEo5SznHQs745IdpQ0Ct bquspoCpqXmY4Qr4fhvo6/c9+K0LaRh0BfxGB/zi3xd8p3pP8+oL5iWehU1dQTdD/0LXFJQD UnFlPIifGCKWgdZPDGIpyO+LICkJxED20goYLTqLDaBeUadq7wO76CSaA6e0Q8ICrp+069pO cDVVt6tNQPPUbqiHQCQ6RzqvgrO9dUheMKid7cWt98D1k3rMMQlcqeoiMRUMXXQPpCpgWuS7 xdgHfCr5CJMEeT/YC7iGw5tBaUNSAuGn4Rtb/twX/C8EfBC0DUIWBHcIKg1V4ioOKvkrlCtT dk+hBZD1Udpu6T44Bkv3Xdfgza3Ek2lLwTDLEKT/FSp4VvMvGgXSRt2ncjtQrNp15xooubio r+Ew3Hl+t4PjQ3jy6s7+O9Hgc6bCjLJHoL5adlPfw3Dq0aVPd5cB4L0/u5G7ubm5ubm5vRt/ OHE+U//C6EtjoHb5aver1QH5mrRFJIJYKZK1W8BxaaScCnIF6WelHHisDEgOvgbJVRK7paSC byHTUvslMFw0lJY+B22t6skmMHQJTSs6BtQr2b1z1oKo7tDZfwZpgfRSOghky12M8aAfUbRJ 9a9AvyxIRN4Ajttv5t0FMU7nqX8O9M/7VMsG5YZ9ltBATlOeGHeC51bPZMNN8PL0bhjYGJzZ 4tOon8DikbQ0vizEf//0wp0tYN2WnpZaF8J+jg4q9AaMN60dcqNBWZcWlm4AXaRPG98HoPVx PnHdArmlXElqCob3RGM5GuwLNKHtAF1NZb+yAFwNtbpaf1DrYtBtAVeC31G/4ZDmdEZqEsTP ShmW9C0krn6svzMBXl19GPJgNVhXu2ZqBcF3fXSJAm3AuDPwU59fwOnl3Kh+AalN4ue8ngby E/Ua4RBcP6h+YBEITS99soALQhtGrgz9Anx/8vf09QWPU+YJpkwwlNGvVDxBb5DOS0GgSEJH VxBX1WaiElgfu2aq34P2WJutNQHpufxINoB2zfVSnQiuwZpVGwFaebFftACliWhJAZCGSY2k sqA8lFeKPqBUQUgpoFxkjVIDJOQcGdCV0wvDS3BMNn1tPgSuvmoNVwiIdS6Lwwr2Oo5ptsHg Km8tZa0JjmH2Rc7hoExQJS0LDCGmyvJN8PjUlOv3HljvWbs4SkF6/6wS6R0gpVi2b0Z5yJmZ a81YBOlXUyq/yYEGtxpcanADDD/7PvUrCEFdg7b7ZYGrpjpKnQW6KL1DcYDa0pUg4sCluErI v0AaKcbc7yB3VOalxDOQ5Uia9uw7uPA0d2dcHyg5vkRkaTvU2Vi2V5ONf3bzdnNzc3Nzc3uX /nDinNMmI9peC3RjlGypBLiaqxU1P5B7SR+xH8SnOMQskLrJ9aWroDTxlDwiwRQQOMl3Eji7 Om4548Czmfd4vxxwvVDHq2tArDXfCBoKuixTuL8JXMWz36S1BP2XpjLmq6DUCB9Wej5Iz6mv LANwfJRXGcRnykDlJYhyUi18QbTWnmrjQeyW54qKQDCfaB+BPFr6yNURvEbI5awnwPmRFuHc DcZt/om6IuCKsYRHfAdv9IkZsR3AecyaElMTgj8PPxw4Bbya+d2J+Ai0KGsf+wcg5kjtlQfg 3Oj6xnkZxApthbCAdEcaJQ6BPNDZzfErSA11X+iLgL2055igEIgLtT+yxUHcd7EfPe4PL7Nv PrmxB5JavObldFDi/Xv5NgPfTyLLRsSBUkf0ktZCRsnXJZMdoBuj2ZWFEPlN5NzwClAwvsTh wp9A8OYCyeErwbegb47XCTBd0R807AR+Yq3SGNTWqqq+BPkLrb7QwDWJ0dQE+0x1vVoAtHEi BAPQRPKXvweDRaeTC4BuqNSLPNACpa+00eA661qndAXbGPW+WgqcWcwUR8DVVf1KHQjOzppR nAJls/ylFA16p3RI2gJqae0JB8EuqSmuH0GUozqjQIoQ26QqoFzUbTB9B6Kv9KHRDMoA/ROP RNDnuS7YPwX9Cmtd631wJdgz7PdAV0996GwD+o7mUkoWGD4zHfXxgJzNeSn2YfC6TeKu5Eiw jbdPdXYHYo0NTV3Af7HXl15lIScrc1tud7DWs4zN/RnsiY56Dk/IG2rzd6RD3kvr5rxK8Drl zd6MdmBZbemQchB8x/nOUWaAtYQ9XG0Jd99/WOXeN5CyO7Xx68JQnwbU+wPt6+0PeOTm5ubm 5kKDTQ02Ndj09+tlFsksklkE9nXY12FfB+hj6WPpY4E11ddUX1Mdhg0bNmzYsHf/BbJ69erV q1f/6/H/6PZubm5ubm7/nf5w4nz95+fanacQnfCwdeQqqFKqwugSkyG3pG2y3QeURmwQs4B1 JIhD4PrCaXHeAL9OPsu8dwK7xCnpS3BkOxu7PgdptKRwAqQWyjmlIohAlumegG6TT5LJCPjS RNKDdkjtp1pAHkAZR3NgmNRHPwC0B2Keegbkg8Ror0FszSuY1gbsWzIyU2LB/tJ6JiMdaOZy pbWHR6tflX6WAGm1k3omdIACc0I+D6kF/pv9v4hUIcvL/MqzBGT4ufpJD8DV+XWjjMXgPcwy NMcK/pWCfMNPgHGHuaavGbRaanFtNUjBIlSygvTU0UUbCfJCnc23JViO+7b0fgCPv8hulB4J L7LuHb2/Bp5/dGPH1TzISbE9s5QFj7jITVF5YOjoN9DzGlg3Zl3JeQZa8dxa9u8h3BbRIOJb KNq7bNliCRAVVfBl1FjwPuE7zOcYyC2Vw/JEkD6XJrETRKR6WnsKopPW31UIxE4+py24qotd YiSIsrxkDkivZb18CkR3zVsbCdrP2mDNCK7y7OMS6A5IL5kH+jpKGakViL1ijOsAiDKO06Ip OEPVceoFcGWJu67CIJ5pN0gA6Yk6mf3AUMKlbiBeCglvEGNFtqgA4o1oJgqCyBMTxBUQW7Sp Wl+QvsBJf3BdFW8kHxD9la+NESCX86hgSAJ9hOGpfQzI9xy/2nqBTu/YYK8BSoBjm+Mr0O82 dzR4Q95D3Sh9bciwZv+Q44QDTQ7pTlUF3Wf6M+Z1oD+lXFVGQ9747DOZbyBjbvrN1GKg1pIS nLdB89HKu1LAdUWs0S0BwxXDLqkKuEI0D88A8NP5l/YygbSNFmo9SL6U/n3WRKAW5Vjxr7ev YguLLSy2EH6e9vO0n6dBvUr1KtWrBPIt+ZZ8K3+9tz+5XWR+kflF5oNkkkySCQZfGXxl8JV/ 3xfI4EqDKw2u9Odt/+8mrolr4hrsbL6z+c7m0C2jW0a3jN+x4SpWsQru3Llz584diImJiYmJ AWdFZ0VnRQiOC44LjoNGjxo9avQIDPcM9wz34HrV61WvV4Vbt27dunULZFmWZTk/bMnTJU+X PA117ta5W+fuPx//txwtfLTw0cKQeTzzeOZx6FakW5FuRf754/W3F0LuCyM3N7f/bf5w4vxi Q2rfJ+fgdMFb1QMsUPq9ktsjB4EuV34pLwLxvWgnlQC6EEsjwEEMLlDPaEZND1IDaSEjQHoo f8UEYBc5UgCwnLKYgAqig7YKxGJpsbICcIl56segu8cxURHEQSzyExD3RUenN+gX6I96dgKn Ka3Xi/6QM+hCsVNfgFo4uV9yFxA31NN5leF50/vLn5WGG589/Om1H0hb7A2lGPAVpcd5Fwb9 C+V08vugTsXLuywYnH5K+K+gu6orKp2HrB2uo+ltwbE+MyDFAv6ezvXWoWA+YVhnvgNSaTXQ MBp0p72rBC+A5PpeqQEL4cGUxDevdfDsyjXpal947Hnv8PU0cEQpToMOfL4qOLdgLsjpumBp EGQvf70y7Rb4Kh41zE2gZMHakZUvQKGzpSYVSYSgZQFnA3eBfpL+fX0vkPazmpogFqmSVglE upaIE4RVDBFmkFW+Zzko01ggaaB+KW3mY6C1tlz7FsS3IkiLAH0N2kh9QRyWyjID5HLaPTEY xCXxNdtBHKSv1g3YKgqI1aBUl4uIdDBNlYKVPLB/rh4WNcAlYxQyaEu0ReILUE+pn2qPQStP IWEAaos9mgaijZgh9QPSaM8OkPaJdowF0URsFa1B/IBMAKjzRS0RBbQTqVIyaG3lgQYvkIKM +5XZoK+gVNBXAHFQei9vEjDRWc/1C0jDpNvUBuWWsss0A7LOWQrKH4P9tjrBeQ28g3yPeMeA YZ6n6lER7AckVfkBskqn30w2A0/ke3I1EDvFVDUArF1te11DIPmb1HO5o8F43jBYeQVenXya mBeB9lrsUX8G/mDS6uPj4+PjA34T/Cb4TYBXjV41etUIClKQgn+13tvEuf6J+ifqnwDa0IY2 8P2t7299fwuG1RhWY1iN/ESm1u1at2vdhie+T3yf+ELLKS2ntJwCxxccX3B8AVjLWMtYy0Dh 9MLphdPhtu627rbu7xOg34pfcVDFQRUHwYvmL5q/aJ5/AVCtWrVq1ar9/fZNApoENAmAGzdu 3LhxA8RQMVQMBXWFukJdAWXOljlb5ixUWlFpRaU/cCHyez3b/mz7s+3waNOjTY82QcaXGV9m fPn7t388/vH4x+MhwT/BP8EfukzqMqnLJFBqKjWVmnDedt523gaXq1yucrkK1Kc+9YHsk9kn s09Cy4UtF7ZcCAVmF5hdYPZ/Eb/F4xaPW/zz8X/Li8kvJr+YDEPTh6YPTQeKUIR/IXF2c3Nz +99O/qMBCg8x60LHwyvx8kriFPjl4v5jZ56B6bDBZv4StJqiOcuACBJ4CNKX0mJpMaDiwgli kJjKDyAtF0elGiBBBINAnBBFxXsgTZY2KDEgbxDHtd7AbUqwErSS0kLda6CxttPlCdpOyY8x oJa0NEmcB479iaPuzwRr/Vi/mMOgfeKKyNgBZGud7UfB9JNXWdNaqDukdqNKHlA7pomrgQ8Y VwbnRlaG1Ha2dZ77QHJ5LfDfBp4vzF4ek0Cnen3qtRE8q3hXivwaxEqlfkAAZH2dVcTiA5kf WM7l/Az2hx6f+lSBlNfeHfyvwsNzrxu8NEDMurMVTj+CmO03F18LA0dP4xGPw2AOjzwa+h64 ajocdhWs771pknEPinwVbQrZA41rtJhXtw1UOlvjVsXvIfpGxIjIMuD1wjDFaAWlpXZWWwO6 I6K41gJMS+Te8mrQV6Wo/C3oqovPpWogxYmWfAPsU+eqwaB7TzurRoISx3ztERjfU7rKH4Fe ZrcIA+kz127XLXBscA50dQPrMOcPrnTIG+9U1LWgjRMrKQjGh3q7+BR0+6WDriEgd9YaacdB maadcV0AJUjIojjorsq9yQXlotxD5IJ0XgqSyoJ0RRoraoMcRlPREXTvywnSQDBslnXyY9A3 kWKlqmDsLa2VOoBhsNSDYDDMk66JjqCESj2lkaCc12UZL4JB8njqvRLMe8ytPd6Ax2x5s1QG zBulb9R+4OvhVVNfFbw/0OUqmyC7Ump06gOwV7ZnW49D6O2wKaEPIPJMRPWia0C+Iy6b+oD8 CWuFJ+j6K7OUy2Ab7RikdYaMDlnTLfdAvaW2UbuD7BDznZHvrqEWzy6eXTwbnm17tu3Ztvzl WSeyTmSdAOdA50DnQAh9Ffoq9NXvj9ulS5cuXbrkJ1pFM4pmFM2Anj179uzZE3yf+D7xffLP lzdyVuSsyFnQIbFDYodEuP3D7R9u//Db698bfW/0vdFQdVXVVVVXQY+sHlk9sqDTm05vOr2B q0OvDr069J8vh81ms9ls4LzkvOS89Pu3837k/cj7EZQrV65cuXL//H4fbHyw8cFGqC5Vl6pL oBulG6UbBVI1qZpUDWrUqFGjRg0oc67MuTLn8rfLOZVzKucUeI33Gu81/t3H/1sns09mn8zO f70/Yn/E/oj843bs2LFjx47BpphNMZtiYGvjrY23NobjRY8XPV40f73f+zn83ni7d+/evXs3 pEanRqdG58fZu3fv3r174cyZM2fOnMlf/vZC5WTxk8VPFgeHw+FwOODw4cOHDx+GLd5bvLd4 w8GOBzse7Pjb5X574Xdn1J1Rd0bBrim7puyaAs8nPp/4fCLseL7j+Y7nsM13m+823/zyP2r4 qOGjhv/8eeLm5vb/nj/c4ywb5DUeg6HRzkrGerehhrlKRpEOYHU6ntjbgZwgn5SOgjSK7SIX xCHxXNQCbnOZi8AX0jTpMxDXtTraK6CklkA28KN8SMoD2vKROAHiMdWk/sBjborJwBZyxXXQ UqUBkhHkLa6FqT6QNuFAzfW/gma99OX9cmD6ofamGjVBFPdu4TsYpOT7PW8B/kuNFwxLIauq vrx/c3DsNOpNSeBMc0zz/Ba0CFM9Q2swNzBoxlGga6ib6Tka1I/5zrkTDE1lH2EEw0OffgHL IS/A8tTQGqzLTLWNDSDvfEDf8B/g7qFX9+LLwL0Pzjw444Rn5kezn5rAWdbnqsdg8CweUM3/ Y3B2yYm0lQT9Vu246zZUWFG5ZVmg1IiKK0vGQ5QpekWBk+CxVNdFPwlyz1pGWtaCvYcYIb4B w2ZdBcNxMM3WHzCUBscUe33796DkYcQLlJlyAB+DZtWM2g7gF2m6KAaOcq5AV0/Qpojz3AFb KzHQtRpEgGoW3uBqocVQHuRn0jRtMkgFtAJiAzhjRTGpFig1pUKiMBhW6duKdJDTGS1mgxJI X/EYlFz5uNQS1DaisTQYnFXVJDKBamKIdAekHWjqMlBG0pa9YDikayIvBCldmsA8cH2nxmh3 QZqlQn3Qnor3RW3QGvJYMoGcKTUkEdSOXMYLxAVxjkyQvpVuyZGg1jcEG9aB1pUB0gdgNNke 2KyA3THd/gPw2HxDaQYii3bsh5wi1maWl2DELIwuCPmwwMqQhSDtVXoYPoM34+M/eLQQXLcI th8EdYF8WKiQZ847pbYG2y6ryfEAPHKVoXLEu2uoRb8s+mXRL+Fq6NXQq6Hg+tb1retbeDH6 xegXo6HowKIDiw4EhjOc4f84XpkyZcqUKZOfaL3Wv9a/1kPjxY0XN178V/vtUbRH0R5w5s6Z O2fu/P7yRuyL2BexD+QYOUaOAXW1ulpd/dvrdyzQsUDHApC4L3Ff4j64X/d+3ft1IfVI6pHU IyA2i81iM1CFKlT5x/tP6ZzSOaVzfqKlu627rbsN3fK65XXLAw8PDw8Pj9/ePmR6yPSQ6X+1 YDWrWf0Pd/sXGd0yumV0g4RVCasSVsHhjYc3Ht4I9gv2C/YLEN4uvF14O2gwtsHYBmOBxzzm cX7ifPra6Wunr0FKdEp0SjQE7QraFbQLGo5vOL7h+H89/t9q7NPYp7EPPOEJT4D2Ee0j2kfA sW7Huh3rBp4xnjGeMdB7Xe91vdeBlCVlSVlwpdGVRlcawfmy58ueLwtNnzV91vTZbx+Pc33P 9T3X9/fHi/KJ8onygdftX7d/3R78r/hf8b8CeXl5eXl5YO9v72/vD2SQQQYk7k/cn7gfot5E vYl6A9euXbt27RpERERERERAq5xWOa1y4P5P93+6/xNcGnhp4KWB0GhLoy2Ntvx2ud9eWK6v vb72+trQNahrUNcg8MnyyfLJyn/24O2FZ0lKUvL3nyZubm7/D/rDPc6O64anCRZ46hn32dG2 4F3Cq49XZZCviCnaLpDs4rz4GkRvcQkbkMtLngMPeMpTkL+TLkujwFHP8crZE+w7nKWd9UHW 5CryaxA7xFIRBmSTLeJBqowfmUB58YwEkD/RcMqQl3ml+OlAkBpkZOdVA2lkmTaVXODzSdO7 vTdBsKXtocHvge/QVtFdS0Jwn6q9K+VAaFrAau/3wPgpPylDQf3QdMpDBWWb7qopDpTduldm AfYrmpc1HNTejk/Vs2BvZ59kKQq2rpaWmbvAq2TgyOAa4PIqdL60DPcNr796XQti1pzdc+Y+ POv+qH5Mb7Av8t5jfAymxz5V/XqBs0tuSF4keD1RpsjNoOaYWq+q2qHKr3UXV/4FonpF9ShQ AfYYDtY4+AJWp228+9MK+HH0ti1bv4ZVXuumr1sFJ++eP3zmA3h9MvlM/PdgOGzykRuAbNad 0E0G1zXttPgMOC4v0fUB+Y1hnH4k6N83tdBvBI9jhvf0w8AwjPHSBZAeCG91FpiGyLniMhia yl9Iu4CPxFVRHNSGakHXeLBud33tHALWb2zzXJVAHirqS+XAJ8v8SrkOpvl6nVQQ9HppsloB DMWlqepy8Kip/EAUmJfKA6S7oN8kR9MD1J3qE3UHOL51aq7r4DysJmmdwTWJbK0/uObSVosD pyqGuTLBdU0bpfYAl0VdLLaDq61oq/0CjvaigUgGV7IYRXGQX+k89T3AsNn0lYcHmJ4Yz5o2 gcdygkVZMKWa1kgdwDvElKBMhZyTGU3THoFlguVYTn3wOxwy1ucAFClY8FohHzBV0Z/1toIh xjjdIwu0mfJwUwXI3ZA3QjQA1xDXbvOMd9dQjT8afzT+COEJ4QnhCRAXHBccF5w/RKPY8WLH ix3//fHe9lC+pV3VrmpXQV4jr5HX5C+XhknDpH9hbOrfjsH+R972DD55+uTpk6f5Pb5VhlYZ WuVf6Gl+O7Ti7VCPtwll7qLcRbmL/vDH8Q+5XC6XywWW05bTltPQtVDXQl0LQd8zfc/0PQOB sYGxgbFwoviJ4ieK85cx0W8Tv3r3692vdx8GLB+wfMByiOoc1TmqM5w6derUqVP/Qvx/0qtf Xv3y6heoPKTykMpD8i+wuMENbkCly5UuV7oML39++fPLn999vLfH4W3inHIo5VDKofw7GfJI eaQ8EqznrOes5yBxVuKsxFlQoECBAgUKQOzk2Mmxk6FU71K9S/XOL0dpS2lLaQvEt41vG9/2 t8v7txeWEbMiZkXMgpO9TvY62St/DPrbxLlli5YtWrb4959Xbm5uf74/3ONcvk3U1tqTwCDk B1l+8LpEkkdSSyhevtimwrchu3pup5zRoD+mf6gfDXzKRqoA/QmiLnBRXOYaZHlkRmTvh4AZ gZ4BFtC6izJaNEibpQhpNJAhLos6IO4wli0gbZdXyp7gappVNkUBa4O48ITr4ExMD7TehOCL /VcM2gH6s8E9Im6Dc5Q9zW4F46aCR8ouBTHAPtt+Dfy7VZvllw4eUy9setIMXtaKPZ+yEmxj iZZrgauqI8B+Agx7Dd7CAvIb5zM1GqT96nH7UpAqCiFtBNsJrwOe78PzV8kPk6fAI/ulTy+c gKcpj1Y++Byyu3osM14F32SvBl7LQU61NrbfBh+bRxvTdIh4WOxo1GAI/bLYyQLfguG2fptx ONx+cO/I/Z5wr1lM7rO68Coh7vRrOyijlE36V2DLUl84voQ7+pj3nmfDwW+O1j7hB1V3VrKU Hw8lGxV7WCQPlA90hQwNIGlwUl5SPQjyCtoXtAR0TcVTfRcwz9KrqheElA6dE9IZPB+YZ/hX B8eH9kuOz8G5yxXmOgDOz1y5WhegodxSmQ3KRFFXGgRygO5jnQXSk3MPWkpDVuNsfcpJ8O3m /YHfcjDsMC4zpQL3FBPfgesTVyXXT+Cc4zrHRlC7iUFiPWgfia9IAbW/+AxvYC9PtG9B+0Qg LgJWMrgLfMxY0Rrk2mIAXwGe4ohoBqIID8Q5kMoJVZQDdZh4LHaBcImzIgbkqfIr6QRIhYwl TMPA8L2WyQnwGmJvZT0KIsVQjA1AYRGklIHsO2mxKevBs7n/EJcA/8UBHfxKQ+hRcVZaD8nH kq68OQaOVCEsyZAZkF3EXhm0l/oPPPe9+wZbvFfxXsV7wc01N9fcXAPqFfWKegUC5gfMD5j/ r8eNaB/RPqI9PJn3ZN6TeVCa0pQGnm5/uv3pduAMZzjzr8f/R5KSkpKSkqDnyJ4je44Ec6o5 1ZwK8fHx8fHxwEEOcpC/JJj/qGf97YWE1Wg1Wo1grGOsY6wDIadDToec/vfV4y3TfdN9032o drza8WrHwVDPUM9QD7jHPe5BZUdlR2UHbBi9YfSG0cABDnAAGgxvMLzBf1GvCpcqXKpwCW7K N+Wb8r8Q/58kVolVYhXIfeQ+cp//YoX/PP5vH56kAhWo8O7ihcSHxIfEQ9rjtMdpj+F1yOuQ 1yEQVjKsZFhJUA4ph5RD+UOXjFuNW41bwZRiSjGlgOWG5YblBqy/tv7a+mvk3zFQUFBAOied k84BfejDf1Gev72wbBnYMrBlIKR9lPZR2kfw5sCbA28OwM2XN1/efAkc5jCHoTWtaf3vP73c 3Nz+RH84cU6ol/LZs2PQwqNudHsFzt26/OxyCNi8XD3tNaFwXAE1ujYowXIfZS/QTVQRW0B7 xUZtDGjl1GzXbqCx6Kd9B9IHopI8FuQlLJKngXOna7vzJsgF5WSlJUgRUjSDAadkwAy8si2x jAHR3XrVXgI8TlUsXyMP9B7hZYvVBO2V7W5eD5AClNvGUyA+xCIvB5dvWrClAxjLhPcvUhP8 O9WeUvoXcP6U86UtEDIicxa7hgBNjF/p0kFrrvo42gATnUWyjgAl1fbqS7AfieheaCK82Jvz yl4Snha6FHnhBDyLuNf9Zg6kD9eX1q8Ej1amHF8TuL519nGUAvmAfEN6Dspmn3365fBixuvF sZ0h/lTyxwnZYNtrK+PqAQl7kn5NuQG2MtZyjqqgi5c7KfVBTRXNHYEg2rgyxQ1whQm9uA+Z O3Oi7T/Avl+OHDw1EC5YLmddqw3yM/lbnRVy9+UNyDsHcl3pI6kUmKNMgebaIPaxXWoLPm19 L3qUhh6vO3q3qw7+Pr5DAgaDoZu+utEH9D8ZthnqQPaonIW5KeCY5fzamQ5vGqd2SwqBK1Wv 1bs1CtJWpY9J84fg06ElA16BKdtUzPwreOaaNpt9oZJSoUYFF3h1N/p6XwT1pva51gq0NvRi M2jjxCytBGhDNJktIG6JlqIiSB9Ko6RToI3WPtaag/BF5QFoniJC1APtiBjAeyDFUks0B2m4 9hPDQBssAkUyqLWoIbaB1pS1Ihdki3GB4RLoq9NT/Qk8almr2T4A8YlhilwAzDW1Bko/sEpZ yelfgJxnnKsvChGdChJaFkofLvQs8n3wmW24bV4C5vc8yup9wUMXuipiAQCN/sisGn8rOjo6 OjoaTvc63et0L6gwr8K8CvP43UMYfku9evXq1asHx72Oex33grvb726/ux2KFClSpEiRv+qJ HsYw/g2zI1S/Wf1m9Zuwt+7eunvrgmmGaYZpRn4Pe3B4cHhwOFxqd6ndpXZQi1rU+r/Ee9sj WZGKVPzrN0pRilLvvvw5vXJ65fQC7y3eW7y3QKFChQoVKpQ/NKBS7Uq1K9XO78F/qH+of6iH 0DahbULb5A/R2Bu2N2xvGHSO7hzdOTp/SElcUFxQXBAEvwx+GfwSAnoH9A7o/fvj/7OiOkV1 iuoEt2vernm7Zv5Y6rduVb5V+VZliO4V3Su617uP93Y2keCpwVODp8LDgg8LPiwIHfd33N9x P+jm6ubq5sKF/hf6X+gPJXJK5JTIyY/n09insU9jaLKtybYm2yC4VXCr4Fb5xzneI94j3uMf l/utHc13NN/RHNouabuk7RIoYytjK2ODqF5RvaJ6wa7YXbG7YoGLXOTiuz+/3Nzc/uf4w4lz mfLFW1ebDnlzHI9zLoH3OI+75g8hZXvC3pSPoYBHiI9/AmS/bz0idYabM+7turwYgur4xoYV gZhqr+qe7woR/v7lCrWAyPO5p0vqoGB8sZ2FOoBxrT7DNB7EAylPiwOnpD52zQL9C5Eh9gJj ZAteYPimwBehGngZ685r0hFcreQA7oOs8kDsA0pwRwsGOhjzlDTQNfRv6g9oGfrSHsPBHFDy TslR4Fcy4YvMTNDanr183QnWOO0XqS64HuS+SQsAy0c5z50B4FpbeH+ZN5Dypec0n9Lwcvpt /dWj8KLU7fk3LJD6XJvMQNAd9XrqNQ8MFqU7myF7ek6l3FGQ0VC9ZBsCCRMy270pCK7RDh9t HTgqquW0faDEG6YZLKAWVnupFtCGOLu4bCAvk+9gAW2ja7mrI6itxVnlNZCLoj4FVz/nXDUD zNVNDby2gKWmNVRrDupopy1vNJgGG3eZvgdXltZP9Yds35yWVh2oWa52Uiokl00zZTeC1WN/ ytzeEXwm+JTyPAfl95aMLzkA1BXaOq0OPHge4/XoLOgG6S1yI7DWsL1nOwtW8rwcJwCzKCUP A62r0lI+CY5TjicZe0A8cA12fAiGEsY0fSco6ij4qshE8Hvgey9gDog56kNtKEi3kcR50C9X uulagOumutQ5FbSO6hsKAouES5QFYee0WAa0ENkEgjQBbzEQtM/FDHktiLZahvoNSJepQE3Q QtVW6nyQ6yvnuAPqfOmMyAb66xWDH+h7aYO13WCOs41wVgQ+N4TIN0HbLRroVoP1UUbZtAUg J3vv9hgI1afXX1FlMFR7Xb165ZvAOaksVUCLFiW49083p39IqaHUUGrAgBoDagyo8Y/X/9tZ MH5rWrC0QmmF0gpBq7hWca3iwPSR6SPTR/m3wmNMMaYY078e//cuL5dVLqtc1rs/bv9uu1ru armrJQxgAAOAmrqaupo6OFfkXJFzRWCz12avzV7AZjazGUJah7QOaQ1Nejbp2aQneDTyaOTR CKo1rNawWkPYd2vfrX238oeaeDfybuTdCBp7N/Zu7A0mnUln+ifi/7Pqe9T3qO8BZ4+fPX72 OGxJ3ZK6JTX//bcJfP0N9TfU3wA0oxnN3n28qOSo5KhkSPki5YuUL8CrpFdJr5KgS9Al6BLA ssSyxLIkfz3CCCMMGjVq1KhRIzjz/pn3z7yfP7Tl7Vj3OovqLKqziN/scf5blQZXGlxpMOwN 3xu+NxykCdIEaQJInaXOUmdocL3B9QbX/9xz0M3N7b+HdOnSpUuXLglRs2bNmjVr/uuBtCDX EPUapKWlr0u+CB5DzE/99sCdHx8+PzkW4lxxjvTeUFRXbEuZY5DULafzs7twf/7zIqeDITzV c31UGLwqkjgl4Qi0iqt3sF8J8A71am+6BX5Gn+f+hcD/ctDMkBegLhYtxUxQV6eeu/sI1HQ1 R1cNDJPCt5edAfJN+3NVAjVGma6OAyFL5eTFoPNTv5EegdrX2FYuArpj8hblFli9Hq67eROy iuwNPBQPb0YlNcv6BnIq2ZfmPQVHbN5EQyTokgqWL2UFNaPyzjIB8OzAo3m358DtsCMFdo2G J1eSh2ZaIK+hh9n3HPge8gzw/BLsPazrrVUhtXDmjLQOYOniCLA+AF17fbb+Pqh2LVWcBl1b 3XVDO9BmynW0VKCdqhd1wTHTPsc5A8QR0UDrDVKEVBt/0MK046IUCG8RzG4Q2eK4JoP8WO4q NQL5kbxH7gDyBXmQVB2kadJSqQ/wk2SmDzjGO16rFcBwXN9W2QuqJF5rt0EaJ1oozUBySZ/z K0ihUpTWH1zeJGvZoEuR7boGYBiivyjPAHWuekI0A/mhdFSJAm2TK1KcBTrzhdCB/oQpT7cd RG9ts/opFJoVXbnAMQjdExoSvAUKDA07Gl4Swt+E7AzLAKfVOVL7ELJsWU0zdkPg6sD5gXdA MkiZ+t4gV5Q/1GaDekfd6LoGQi/a6ieDa6Na2+kD0vtSsrQYlP3yGdkGzsaOaVppUCrqSmlV wNbHuVpcBzFEMkgHQLea2tpgYKSzkasfuKbaK9tvg3WtQ6dOANtaNYNikDPI/v+x99ZxWlvr wva1kjw6Pswgg7sXd5cWd3ctUGiRFijS4tLSUqxQrDjF3R2Ku3txBgZmGJdHkqzvj/fMN/u3 9+nbTWHv7vecuf6ZeZKVlXvdkty5s5KM93YFi24f7BgCuRbkyp39JFR9XEYp8T0U6VxkQf7Z oEb5NLVeA0d/a1bH/wOJ4LHEY4nHEsG+wr7CvgLKyDKyjITLiy8vvrwY4r6L+y7uO6hbt27d unXffX//09i6devWrVuhefPmzZs3/6ulSSeddNJJ531z9uzZs2fPgtq7d+/evXuPG5f6UMXb su3YsfEzyoLL6i2fshVEbeWkz114yLOh927DhYBbv51bD6E/+Jt5Y6H2qhojqmWDV/Jl0+eD 4HnDF/UfF4Y382PnpYRA1OCkkpF9QHso9kSHw/P7LxdErgPzw5Q3KR9Dzjk5HuTKAd5CjNGc oA4wB7rmgDWHPTHoMZin1Iq+Cghf1ap/B4qp5nXOBJ6Kz1kJlBMHdQO8c++OOFcK4pqf3Hfk DsQVX//p7j0QPfS3Xa8DwONibnANUBo4m2cfCtayWb8qsA8C21UqVOIxvFZi4p/+Ctc/OaTv aQyPUp7mePEFxPbXvvZ5CgGzfEz7ZZCT9Ur6Log5lNAntiokXEz+PLEOMEG9LQaAFqg8EA/A NtC6URsKooO4qZ8G5ZrcYS4Hbxtve0MFvYhxS28IcoYcJZeCccK4q38M7EY1BYj2SnsOgFTk TbMCsE8eIQLM6+YpMx+YunTInGBMkUJ+BHqssV7vBbKifGb+BpajWiFRGWQ1cUTeAnlN1hYu kMuMZkZPMK3mKjMYTCcl6QTsNVuZZ8GQZlZzNZhxcptcAzJETmIfmJnN8WY9MCvKY+YzMM+a 4fphkFnFp2oYvG4fOTPhLES3if7yzQ7wNPB2THkAxlk92BsOoSdCn2bKCREdXi2KcIB1sW2z bSBYwiyN7QHwbMWzNo8NUFapVcVlSMqdUt6zFi6du7r5yjSIyhN1IaoqaIWsq7Rl4BPlU8je AV5ni4qKrQTnPr9U8kojiJr3pk7EBsj4W8Y2QQVBu6nedEQDEcoe5SWouSho9gVjuLlEHwKE q3eVnyGlomuU5xoYl/UBxq8QtTR+XkIUePKn1HQ/B98vDbu4C/49MgYEj/qrw/2PCT0Teib0 TNr7mk/NOTXn1Bwwt5nbzG1QLbZabLVYsOWy5bLl+qul/c+jUKFChQr9C6aApJNOOumk859B eHh4eHj4e5iqce7n8/7HBTxel7PhteJgG2IklBgDQe19WwVFw+sJrmc3r0Dwao8S1AaeHHoy 69FRiJvrfphgwPmZjw89qwZZo223gyyQb0tIkxK34JX6ulLSQrCF2wfG7YabhV+3OecPhb/K d6pIJQgckNWT5wS45mnf+80D01d+oqwDdaoobZyG5Lw3lN09wLIsQ78820Er7/8k6A64Tr2s 8ZsL3Lcel4wIAHFMC/GNBJ/8NTx1KoC/N2NK1u1gnxDcKagLxKw+uetaATBHBY0KuAsvFTNH 9DJ4sPdcnVNR8HzQk4An8RA1FEM9C85Q5yG7CSwXPwkdklomVkh4AImZkgMSn4HyuXW6Mgfs 8+y7LT1AjjbC5WvwdDKmuH2BQeznDdDR7C0+AvnALKTXAWWw+JCZYPSV/2du7mwtm1IaxEjj ofkZ2Abb8oufwEyUNdRoSI5PStRNUJLV6RggJ1NPuQfmEOO+eQHE51xU7oOyUizhJ/DmcseZ kWDcoRSFgYPc0T8Hb2XzlKwPWiw/K62Ar1gli4LpZb2sCmKGeVpcBPGDeEUQiGiymoVBPpf5 qQayKP05C0pJvZHoDZq/JdCYDuZZWVXOgcQMSehnIWLVq1KvVoLT7lhq7QD0enBC3Qj2gc6G zhbw8NvH2Z5cBY/m6WOWBNd114KELyFxY2KNkPbw6knMyRgFor9PmB67ElgbP1hbCI8Kh895 aoOSxz8Q+XdC+NFn05L3QaRfTJ6YmiDqRa/Vh4LSTJ0oT4PaUPnS5gfaU8teeR1yujO9zrIF zM7MNnKCFi6GaaPBXlM7LvJBgh43I3YKKF86jzvaw8WEO60fvoInK54WfTERPqZofL6/Otr/ CXyq+1T3qQ7NaU5z+Jt//otsZONPXFink0466aSTzv8k3jlxdnWyVfYo8PjrqC6vIyC4Y0Df 0wPgwZind1N0KH4u5GHtEDjgudB0XR7wNDCOmBsgB9n989SGzAHakQxAvcZl+jXuDDXX1XbX PQBPTj0p89Af3Kfcd5IHgovYbEYt8PbSD7q/BP26HOvRQXlieeRXHihh7NC/AJFdjHZXA0/w b9ybBm+S1s7akQwhdTpk65ET7LPz5CrjANvO3JWdiaBet1ZWJwOnleLaE/AOiC7wIhoSs1zo eHYMaNWsGxMkGAey3AnrAY/vX55/ZTc8K32j9LVc8Dpnyiz3AZDTHf6+r8DW1PqL+iMkl0xu mvgc3tRO+CX2V/Bc1PMaJ0BMF0fU2uAJd2X2fAF6C+8aowh4F5oF5FKQu2WcWAkygzSZANIj U8y+IFJEOwJBRKsd5FgQbVkqVoOtg+0z1Q9EDTMXdUAqZpCRH6yznQ+US6C3dK80yoKZVX9s hIMWruURZUGult2NC8DH4o74CowPZbS8DfpivaK5GOQABtEOxCA1WMsMZhU5TgpQ9snlYgLI TWK6/AJkFXOsWQmYxSE+BxEjsotXgCE2iumgLzTjzU6gRjNYLQ9mPU8D7wFQNUsRBoEap7XS dkLMgLiMSf3gUoWrc27dgFzzc9xJsIPsK29YW8KbDtFPo3OCpYJlnHoU/PP5fe2XCzw7vXsk kJCYVDg+DpK8id0TT4IxWX7DanAddQck5IMTdc/UT5gJYoasro4FeZRCaiFQyig/KBnhQe9H t8NvAbXEBJkC5gRuGj/C6yyvqkRkgbwiW8NMrcD/c78vMm0FUVAtpVUEdP2O2RES/CNzRX8O HBBH1UPgbe954019y8DgvzrM00knnXTSSSed98G7J87rzK8IhKRRb4JccWAxYlLsV8DW0Gde YAV44SfqXfOC5YNMPfWGkGI3Nr75HBJXvrIEhsMncS0z9B8Nvs2sO306gZjEHHMa5O2dp1kh N0Q9jp/ywgmXbiXE7P4FAjZ5J5brApkKqsWtH4I7xrNZTwCxTLPbvgajL0sNJ6iz/Hv5JUPg yiqfVNwH9mPF69YIB1HOtHorgOxsHtVvgbnBW4SR4PnwVfnbYyGu4Y6R2/zA0zH2uJ4Z/BaU 31KjAbx0JI2Jj4en3otDTo+DiI3Rt2IqQnJR8UJpCf6/OIr4ZAYZoL8w6kLC+cQMCYvBfdU4 Yw4EuZLn4i4Ip3nb3ACyvoihLZh+cj7tgZ9kSbKCbCnvyX4gKrOPWyCq0woXyC/lEakDi80R +IJ5k9lyGrgf6IP0RNCeiRKKH4ju4gPswPd6Rr0ymBbjodwM8oZZnJsgApSnSn6QfeQZuR7o TCklDIzfZBazBbCecvIFqK1Fb0WAiBI95HowW0gf2oFRzogzTgOSQnITqJOVLOqnYH4j25oT QW6QW+QEED+KhiIjWA6KdlwGrZ+lIZ8CBTD5CfRvzNLcAXcpd6IxHuQjs5+sBSKv2KBUhHv7 f6v8PAJ0l9HfyAzqCK2xeg6UBCW/cgyiLbGL4rpBNkvY7NBmEFM+7k1sdtDbmRlkO/Ccch/w xoCSohZXm4Eng2eQ+wLQwvxKTAPlvnJJ3QKaryaUraCMFxVZDeK6ml01QTaSEWIzvN7+Zm3S LXB8b13yJhdYh1sGOy+D7bwtKiArSKuWSekF7nj39pQWkFIlfnjcVjB2O8OslYCNRP7VQZ5O Oumkk0466bwf3jlxjv/6TYPkMZD5oqVl0eLQJ7BJ5NAOYH0YtNBbAw4suVJwzUzwdnZ2cF0H n8P2wKSmsKH5qaEzx0GXIs6inz8F157kzeI0nOmxI+aQBZx3fRaEaKDXUHYakyDfoOCLea/B 83lxKyOKQGihgFnPr4KvI6hNpnAwG5vDjcWgbBD9bafAMiFsSZ5PQfnBr35QEjBcKSoFyNue w95aIMsqB7SjgEtbLd+AN/lJ0p3F4Jn1ekrsSVBHZYkvWAU8icFX/Nxwd8Cvxw6vh+dLH+18 MBBeV9BzmQVAm+2Y4tcG1K/4WJ6EuJtJKfEHIfGyq7RrMFja2Uz1IOjX9GLGYVCsSry4ALId a8wY8G7ybjO+BvYzRTwDNVqro34KZkGjkD4S9Il6KT0IFJvSVwkElshhYjaY98w85nrwHpZf yd3gkXIFBigOJZO4DPzCVfErmGvNB+Z2EKNkBlEcvDGekfpxoKUoJfYA5cVx2QqMGLnKzArq YDVW2Q1cFMNkBTAbG58YZUDWkZ1RwFxqrDKyg5pV665tB7leHjUFKFXEZHaClk2ro94DOVRm kp1A3Sdu8QOon2uz+Br09saXcgCwWubCF4ymRi0jEpRNmqbsB6oy29wOel/zotRAidDmKdlA D5Jecw8wVT8la4Ieqr8yV8Pjtk98Xr8BHiib5QsQy5SPzExgvW29oX4I3vtej7sgGIeNbuZC UA+qTbSlIINkgAmIDUY7ZSCYS8RQaoPanRS5A8zR8mPtC5CPzZdShYgfo4bHVgD/UL8yPksg 8xfB7W12ULJyw/oZqB1EZvEFeJOSlif+AFpH6x3f8X91eKeTTjrppJNOOu+Td06cCw3O9FWl HdBftm0+PBP4+AcVdHwDUf1fnXqTBxJzRObxuwV3uj65/bAAvHr12ufFQ1DWWPNlyAk7LWeL HOwHzsnqLz6DIfZ775inGeBlfU+L305D0i+JockTIT4x8cyrNeAX59nsMxmy98laPXNDCKqQ yciWDO7tKR09PYDX9LC7QB0Wcji3BtRJmfFmLyjnjKNGJtBLKMNESVD2y0dcAsqbRV1e0AYG xPnEgqpmmu3bAzLcqvx96TbwxseVPckCz85fOnChA0T0ife6skLKZ2KZ5g+2suY44ykkn08+ nahDbEry2Phl4GlmjjK6g9pbj5U6yBVyLT+Bt6g3wuwG3pGGy0gCZQZB6lIgicfUA2O3d5lx GMzXZoy+HbSxyln1MxBhylAxFbzl9I56URCbqCqKg3hmPpd2kP1EnOgLRmY5Qg4FMYaB8h7I svTEBfKyaEtrUIeLQASYuczdcgnIR8pKnvJ/3j+6AcR2pbk4C2KHmExukNf0JzICqCNbUxM0 j7ZRCwaxXrGKQkAVpsrbICqIAiIAzI/NYmZTEHP4UC4HYzx1WAHeoy5NdgSzmLwqc4B1pbZC yQ3mr+YIsQHIJhtSFuRyMY46IJ/KeTIY6CvzmBdA3JCbKAYyszlQHgWzG5eYAd4F5j6jNqir tI+1EJCYvc3OYH4o9xsNQM41c8j7IL+VrWQukCfkan0WKH3FVHMeMF7tol0BS0lLWQWg5v/5 Zq5eSX/t6Qq2FdatanZIOev+TgyC8A9ed41sDT4P7B/4uMHXdEYHrwNPrBgvgsEs4I10nwPz RMpR5TbQklZ/dZCnk0466aSTTjrvh3dOnHPJ7PWy/gRne19NPN4Yjt47bzuUA56PjPk2PAAc azJUjpkM/h0DNzlaQIzyYrhnFvh2cQ61B0JCNtf059UhYaN5JgHI3sKvb8B18P8mILlsAvju zZjsyArCwStpg3JjS6xpcgnuWW7nPP8b5HxWcHLekkBPy35bK6CWXtg1DbTYgEyZfwY51baQ NSBNY71eA0Q5cVdJAOWhHGY0BVlEmo6nYCubp1uxupBhYcaQvAb4DM28J990uDZp1c+Lx8DL 8MdfPdkPMWOMInwExg6Rwg/gXpEyMmkE6MHKKGqAO8nbyFgE5kYzmlEgn5ifm8vArG+GmqvB mCA7yC1glDYzmW1AfKSUlzeBJYyjMJh9ZSHzNcgtzBUdwYzjtcwEopAsxxoglBzUA+lLGZkN yCOmsBFETwrLSiATzP4yFjgoxvMClO4yhUjgluguMoH8mgLKN2C2wqqngJxofk4NoDADxWow TupB8gKoP6rFRRCoLyzVlPsgt8qOIhIYKIfKfsBuGjMJZB7TLncBTZUMcjWYl4xK5mOQWY3j oguIjFo3JRaspa2hwgZ8az2tPAGlhr5XfgHGNL4zc4GcbL7RVgOn6cV0oCo5zAxgtDIfyV8A VR7SQkBswyKygdlLltYHghyFh9lACTPWyAHiK2HVcoG+QH9OW1CKiACRB0RZPjY/ApFDZjM/ BnMED8Q9MKaZpY2WIIrrugwFUzXvii5g/KAPlKXBU110xwLKOq2WkhnexEb7pQyG1zX9Qt7E gHOKPcq5A6wvxGzncUj+TCw1c4Fnf8oBd8B/Bcntdw/Uu3fv3r17999xSEgnnXTSSSed/7kU LFiwYMGCf377d06cj2a/uW7ncnh6OXpR3EBwFrT20H4C/Ylx2OwKIix2gdWAjKEZXgWUB9fX Ge0vakLmzp6chUvCy7CEyRHtweeBNcR6Eh6ue/2BsRT85sVViNDA0k2bpztAszlFck/w7HvQ R66DOyuuO7e2hYxjsybojaDC5RoX+n8NyUVTrCnDQLWpRZ0OEI2cY7P0AJ7LcFkDlBqE0B/M o8IisoAMJ9r0B7FeO5EpEOxdMz21DoL4Ls/GPvoArrQ5lvt4WXjzTUoGTywkr2aemAbOPbZA ZwDo2cVGEQBJJV3XU3zBu1BfZK4A0V4kKadBiVSza/3AbK9P8ewD5aLZ0owFJVItoeQCs7H5 UJ4AslOZ4SAU4RF3gVlyqtwI2CjGZyBNWUyeBvGdqKR8BbKX7Cqbg1bHMl6rCcYCc4D5IZiz zPrmdFAri4wiFJTbyh2lFZgvzCD5HMwmlGYLWBIsPW2FQK9gZNWzg2kYk8yWQHtpZwSY0mwt XwMwycwMSrxSSd0LylfqVfUkGHmMTkZ3UAuLAmITyKxmilEO5Dr5kouAqVYRF4BvhIV+IJMp QwzI+Z6iJmAWM6qbe0BGi/GhvlkAAIAASURBVLbqcuAmR+QykOfkR7I/UJrWcjnIG0Yx/EH8 LLLoxUD0VhTlAlBR3lXWg3nQPG/WArKJKH4EMZJaxk6gm4w1N4H3A2abH4DYL5epmYFDFDZP gdijdjNmgxysjdKWgFHS6Cs2gNpA0aQvmMtkiJIAdBH5eAyWFaKiUge8JfSxhg2i18UMSiwN oR2D7IkW8O3jxPoEhFWfRjbQT+kVhBvowvP/hEBPJ5100kknnXTeHeVdO3Ct9eyNdENxW06b 2RxK1i3ZNqEJZPk1RxnxK0REplz3DIO7/X8bEZERfJq57ml+IM/6935zDvI0LFQwX3mIjEgu IzuCWYQbyd9C1OLEi/c2wKvbCe2efA7RpZK3vjgLl69d7XW0GPgMCCmdrzGc4Ur1fZUgYUvE pw8HgmK1TbT0B+NrmVF/AeZB6tkrAnXpKbIDFWkgDwNlqMfnoFQwV4gxYFbhvjkDmMU0bzA8 ij2z8kwUhDd77PfMClHDPEvkZ6B9bXvorAMBu30+9B0D6jLlZ+UOmAFS4zFY4205bGNBqatc Uh+CucTcYswFZb2yQVkCWqhWUCsCygClo3IYRFYsPAVxV+wVX4LykdJN+RJEDrWI6gBLVksx 60WQT+VFWR0sJSwltFxgP2k/Zb8K1u6WJlYP2GrYLtoTwHHW3scxEpSVynatP6jV1TpaZ9Bu aLr6BMRukZsyoOxXPlHXgMNim2sPA+cG+11bcbDPtt625gLrC3W45Qwo4yVKe2CHkd+cDaKO +YNcApbM6hZ1LEiTGlwAI0rO4Q6Y3/IV60A+MkPNkyASqUoNMOrrmWUuMFu7w2QUmIeN0co1 kFXlWRqCqC3sSmVgIfv5BCjKAvEaxI9itJoAIlz4ih3AfBayEmhLF3kDRCXxgTBAjjcLy5Zg Ws2iSmtQVMVi7QGWZG2z8zTIiuZe5Q4Yr/XS7AEmskkdCcwyV1MZjHV6eTMcDKHHmxbgsHwm m4BRwHtUfwzGz95M5k7Q7xvD9d4Q1efNzMRSEPM4LjyxCdBa2t0DQPtC6cYeMGqZmfWyf3V4 p5NOOumkk04675N3rjg7htkv2MdA/Bb31ITGEJbMR86u4DNevtQ/gizhQY3s8RB6VRvovwBy tMpgVZ7AbxvjV79aBNk/tZcv8xkUnVdydfYoeFLm2d2rjyDxdLzpMwo0LNMteUC9a+mcEATK cfcm20wIOuCvBKyAiEexhZPrwZ4a+2vMCYF2qzpem5YXkp7Iw1ojUFqJaDkQZDbxQM4FMhKt dAF2i3ayNZjlaSf7grJfaaNFg7dB7LW4MnBDPd/rTBGIGpIUmrQEkrxymPIDOHs7WvqEgrJH vjROgXes+5Q7D+AQ48QWUC6LbooAJU6pYYaDPs9zU78JylhxU3GBaK6VUasCPWQH8SOItcQZ X4K0c1g2AWrTXRwH83NpIRxMp1lWNgflR2W5+jOoiupU64GQwlROgaEaLmMIKN3VHcpPILaK o8oZUIdYDO1XMA+apc3ToI8z6uq3QZuljlMXgrHUTDIvA5NkAfaBZbxaVYkH8VSJV6qA0kDp olQF44beQXqACkySScBvYjlTQEwRg8RV0GbZWqm+YDxzPfBcAvOQnlnPAkpFxUcpDySY34lo MEuKHKISiFmyFAdAllF7qU9By6xu0Bwgk2S8mRvIwwqRCbQbyijtQ6CrQOYFZojh6igQs/mK OiBsykDZGcRzXoknIHqr80UesF60lfDzB7kSu6gC6nw6KnUBr5yfeBG8MzwjUh6AOcNooJjA cPNr8zko2+Q1dgM20V82AzPQXKtPAXWd2lFLAHFK5leKgeOoY4h9KSjrtCa2O5AwOamAcRY8 i7zNjUBQm6n+Yi/ICGn3Lgba/tUhnk466aSTTjrpvC/eueL8untkppTNYA2yTbX3gmAREpm7 JbjsSlTcJbB0pagcA/pa65KU0xAR6f42Jjck90vOm7IbrpV5ue7AXbhX4/noa7UhPvpNXVkO LFGOsfZ74HQEn/FdAmzUz6vnQHYyehn34FGB+9ZnwZBQOuaq2gteHDIuPoqHeysfDlm0GJy3 7Tes9cH8hnqGC1jKFfUwcEU8lCaQUS7jR2C52dbcBNY5llpaMrwefqfKzavwtNODng8+gTdR nhO6P8ggMc2igS3A9kZtBq71nsqea5BcU9c828DMLa+ZVvCs8JTzngRjirFft4N2yvLEugC8 S/VKxnqQ0jhrLgFbc0sJ5TEox7Wumg1UTa2pXQDLWEsTS32wFbZ8ZgkCrnJVVgeKU1J2AAby KfVA7Ba7WAuylsxh3AfXLykjkt+At7s30NMTvMX0F0Zf0A0jj7EN1DC1mJoCyg1xQZkGymfi NldAKkw0b4K4rIxTcgFfydVyEJBECb4CsVhJ4QrIHSITX4C2TNumnQR9gvmDuQXUJnKZqAG2 YdZStsmgNtfuW2uCGqI51R9BlpVFRC2QFnOCuQzMcKaQG9SfGKQqoD1Vmlv8QKyhmPINmDGm laZg7DaemQHg7eftom8Gy3KxRysMlsWKj+USWPdYP3c+BvNbs4ksAmZxfYe5FzwDU24nzgDP J8kPEspBcq2kevHDwPjAu0SvBD51/NTAFMhyJ2tkgYIQtDZ4Wc6LYOvk0y/DOnAGBjbK+DGE 7AudknMGBH4X0il7XnD0CxgX0g/8qgYNyNIMMh7NtCDMBpZvHCsDi4C3q75ZLQ2W78UyYyFo nURV7au/OrzfnmG1h9UeVhvaHmp7qO2htOXT8k7LOy3vXy3d/x7Kli1btuxb3LH4+/Z/lb3+ VfuNOxx3OO4wfLn+y/Vfrodqt6vdrnYbqgysMrDKQBh4c+DNgTfhxdgXY1+MBfmx/Fh+DDNn zpw5cybU8q/lX8sfKi+vvLzychiwZMCSAUvg+fPnz5+/w2Sqd7XTv5rfs8d/ir/8EZfLXS53 uRwMHjx48ODBaX//ntRP3aeO6/f+/m/lr/bTd43Hf9YP/l28c8U5+9mM7aw3IMvCbDv8giH8 x+h7MZfhqefJ3pTDoDRXZ7i+As8jpWTK1/CmQ+wB/3HgE6R0dNSDlB9ls8TG4K6rbzSyQ3Ki t4S9D9jvx+eNCwVlgP9xbzwYHbXZ6jjwpJh+5kxQzosuiY9B+VBrkjQKnnV70zU0Oyz5YOeU jXOgfcNyfo7sUKJftfM9JkDiOtehhFygnaKlVQOZQZakBYgWIkCtAnKUccf9EH4rc7HcxXMQ 1SXGjG0PCfGel5wESwn7dccCUEPFTaUTJJ9OqZP8Gbg7y9lmEJBDidRqgWWiZZCmgznFaKxM AVopPcRKsM6yjtLWgrnK/MXcD+YROU8MBO2Etl4tC3KUnIw/KOOU0cp4kDPl98Yq4BRPmQji tDgm+oO53Fwv14DaU+2qRIK1nFbPNg/UOcpibTCYQ+RaOoE3Th9l7AM1RM2rdAbFQ7RYC3pj Y5XhA9qn2iOtLigJqmLNC9pk1akYYKQYj4x4EA2EXdQATmPIAWAdrJXTRoCswE2+A6WcqCYK AbXlVnxAvSymqO1BG6EuMRuDEWRUMXqAHMZm8woQhVN+A9oJLUZtDGKQeMxiMPsbBaUVZKS5 Qx4DUZUJYgMQJ0Yov4F6SXmilgbPKW8Jz3ywHFG3awHgreI+7XoJ3iPGYeMsaDe0K9ovoNZU 8wlfMMuZLfWfgUXiieYFpa5WQHsCRn5zlXwJflf8avt6Qc0T9CZDPpBX9RXGYbDUtCraXnD6 2nJqccA884h+ArhAZ29NsHyrTCIJ1EVippoLrEXtC+wVQaui3FBKgNJBDFPagLpLeSymANDt rwvvt+dI/JH4I/Fw7t65e+fuAXWoQx1YH7Q+aH0QDGc4w/9qIdP5B051O9Xt1N942l9lr3/V flNPuIdeHHpx6AV07969e/fukMU3i28WX5jabWq3qd1g9OnRp0efhp7ent6eXlhVfVX1VdVh 0JlBZwadAfUT9RP1E/gh6YekH5Lg28XfLv52Mcw5NefUnFPvrvf/NH7PHv8p/vJ76B/oH+gf wJTEKYlTEuGp56nnqQeMc8Y541xaO28Pbw9vDwgfGz42fCwMqjyo8qDKEPgg8EHgg796FP85 /NV+emLWiVknZr19PP6zfvDv5p0rzvodS5JrAdxt8vDVYytcmXZnyZ0dkKlatqq+BSDlokx+ /QIiL0SXdFQA5b4Ism2DyOVJXcwLEDMgLq//DvA2Ndpm2A+2PkGfxT2A5EreXolL4c3+p1mT FIg7+XqCezyYY41bcjG4fFKmqFXgdWJsp7jmENExunT4OLibL/xl7Kew/OKhZpPjINx2p/fh SWDPZm/jVxfM7GYBvSuINWKfbAXKQ+1LZQm4HkRujSgIj+/fPHXzDcS0SZnjjobEOsYUFoC1 iuN7Wx/wfOUtYFyGlJ88C1MygV6Z0iSCsdjcbQwFoYgbNAXzpNnEBEQX1nIftP1aP20FWPpr H2sSzNdmJfkb6B/pjfSdYGQ2go3GIGvKurI/mAvMX8y1IJeYg8ydID+VtfkZRB7hES2AhXRj HfAV18wkYKFYJysCS5iuDwYRxi5DAx7KlxwF0UWZq2QGdan6QG0JymJ1proRLAu0TdoMkD/L XVQCNskloiQoBpOUayBclBK7gFEyhWMgC5pj5W1QlyutlUHABhTlPhiTzSXGWhAdxUBFAdFd 9FCvAx7CRTWwLLXs1eqDkkWJVrqB9br1mvUEyGc4jVgQt6ggm4EMNr81zoEepMfrV0GuMZ/J BuDdaAzxloKkxe5p+jzQlxpj8Af1tbpWGw9oCPEReJt62+u7wDvLO984DrKStBvrQe+hH/Te g+Rfk1vEb4CImi8vPWkF0QuiBobPgeSOCc0iX4CZ4C2WuA2Ssia1ijsN8fXjc8R1gCRn0v3k L8D1uTvM+xgSCib1SQmCBFdi1YRREHclsUdiPHjPGU09O8HWWp1p3nx/gXog+kD0gei0SnCL HC1ytMgBzSY0m9BsAmwbs23MtjFp7WNjY2NjY2HEiBEjRoyAhtsabmu4La39yI9GfjTyo7R2 Y8LHhI8JT9u+X/l+5fuV/8flfS72udjnInTu3Llz585wu9rtarerpa3v3bt37969YdKkSZMm TUpbvuPFjhc7XsDXDb9u+HVD2Lt37969e6F169atW7dOG0/jxo0bN24MS68tvbb02j/qIbUS svLWylsrb0GHhA4JHRIgMTExMTExrRLRJKxJWJOwtEpG6jj/iPctV1SOqBxROaC/2l/tr6ZV xlLX31xxc8XNFb8vz5Q3U95MeQNNdzXd1XQXzCsxr8S8Ev/YLrVy83v2elv9vK3cv7fff5ZW U1pNaTXl9ytdERERERERELoldEvoFuh7se/FvhfTtsvyIsuLLC/g1qBbg24NAnsVexV7lbR4 6dK5S+cundPiIBVd13Vd/+fl/D29p+ov9Y5N3bp169atmxZvP5376dxPf3Oi/7P+mqqf2e7Z 7tnutP7nz58/f/78f94ef+QvE3dP3D1xN+zcuXPnzp1p61MTlgbPGjxr8Aze7H+z/83+92fn VFbXXF1zdU3IlStXrly5IFu2bNmyZfvHdv9/hbIMZSiT5qdlFpRZUGYBNNrWaFujbWn6fVve 9jj693ZKTQBTt+tSpEuRLkXgecbnGZ9n/Nf7wbv66fuy65+Nx3/WD/7dvHPi7C1ihPtPAG9U tN0yAHwymJ6AVpDxmpNMP0LhTKFbQh6BI6OPJbYfJDxW+r1qANpKa5noacDjxCFRGrjL6L0S mgKx4vtkFxizfcvHXQXfrXaP4xX4ZFLrWIcApfWtrp1g2+vXyzUSPKM9pSxvILxh+G3lAri+ TJnjqgJa7YAmIQdgcaUtj4bOhITZ4X1vnQFtuO0zn6dghup9vceAk9pgJQCi6z0q9rAcPHvy wv/5YYiJTQnxVgTjtVJBPQ2WFOt5S19wJXp6u19B8nhvcXdTEGWES0wDmdu4br4EQ9Hr6kXA bEJrcy/I4sYX5iMg1qxnfgrKYPGbUEA0ll+JVWDmNR1mTuA452R7MG+a142KIIaIHgJQI9UU EQGKQQ1agnxt5DWqg3FOj/GcBP2NudpsBjKb9MocwBCZmxXgqGvT7FFg3WppZwkGa3aLtIaA tbWlqLUWiILmG1kO+FAWZQGofdQBaksQj5TvxSJQopXyyihQeyjBym7gF/z5DcwB5kPTH2hC VnqBeU1ul4uBjeI6h4FYMYWqoKG5rHlA66mVs9nBVt9m80kBx3eOSL+q4HA7+vjfAEdd5w6/ umD7ylrIuQP8a/geDioEfk39HwU3AWO8kcF4AuY17rAP/JYHTAmeCVpbW1n7PpDFeMgm8Prq HfRMYJw1CppuMCPNqrIKuIKSbyV1B+/XnsAUK+jt3DmTPwbXtoTfYjvCK0fE5Bc34fFnjxbf t8Oj7571f3IBwltGLoidBvFd3Vu8hSFuhfss8RA+MKZPSkWIPJrSwhsCMS2S4vVTEBUc1819 AFJOeloZ+0B5iMWs//4CdUK2CdkmZIMfOvzQ4YcOsOXplqdbnsKCPgv6LOgDxzod63SsU1r7 qfun7p+6H0Kfhj4NfQo7X+x8sfMFbH229dnWZxA2Lmxc2Dj4tu23bb9tCxOyTsg6IWva9gvL LCyzsMzvL69krWStZIULCy4suLAAPHM8czxzICoqKioqCq4uubrk6pK07S71u9TvUj+ofL3y 9crXYc29NffW3IOPS39c+uPSaeNZdm3ZtWXX4KfzP53/6fwf62X1qtWrVq9KO2GkHrhTE/Ua q2usrrEaZvw649cZv/5xf+9brm/zfZvv23xpUwu2bt26detW+HTpp0s/XQrTC04vOP3/8raU WjVr1axVE5ZUWFJhSQVYuWrlqpWr/i9+8jv2elv9vK3cv7ff90XqCX1P9j3Z92QHy1LLUsvS tAQ+YlfErohdULRb0W5Fu0G5y+Uul7sMwwOGBwwPgIPTDk47OA16eHt4e3gh++vsr7O/hvFN xjcZ3+Td5Uu9wAkMDAwMDEy7ANsSuiV0SygkdEjokNAhrf27+ms5UU6UE7D48uLLiy/D8irL qyyv8vb2+L129evXr1+/PuzPvT/3/txp68+cOXPmzBko1KlQp0KdIMNHGT7K8NH7s3PqBdLq GqtrrK4Bw2oNqzWs1u+3f7zp8abHm0Dpp/RT+kGjxo0aN2qcdqHZOKxxWOMwuDbg2oBrA95e nrc9jv49IfVC6oXUg93Ndjfb3Qxqr629tvZamHZk2pFpR/71fvD3vK2fvi/eNh7f1g/+3bxz 4myf6O3m3QvBi/zX+TSFEIf/Xkt3UPKba4wKELfSSHIcBq2JeV/Wg8BR2r4MWcG2yLbSuAiu C0r2iG3gKeXdHhsHnoSk7H4ZIOdF/35ZEsBeUT7QG4Llt8T5ahQ4Lhh5bKXBMtmxQT6BDK+y TLSWgJCQDOX0YRDmDp7jUxiSz0ZZFCuEt3JNTTkNq++ub/tlXyA2ScbWADHfMtTZHLSdsgrN IeL8s0b3CsGbgjHNE10Q+1rfYZ4CNaNFaP1AjBfllVmQlDflZUJHcC/XEzzTQAw3mpq/ADq1 xErgF3OwKA/qED5XPgJ5lWn6RTCymd/qkWC0M7zGJmAhoygHZmOzk1wDik1JUIJB+VJ8yEqw 9NY+FdVA/sAhpSSoebTzlr4gbioj1Axg3DdzMBXIRKw8BKKNqK9UBYaIiepEMGrL+XQHOcOc gh2MzfpX3o2gvBbbxA5Q+6tfqWWATjTgHojuoq3oAuoK1a3eALoKf/aA8pNaSe0LPFZihQXE HHGXpqCs5xyLQNXV2ZwGbZ2yR7kB4o4sIwaD1tL6o3YFMk3NWj/XcMhyK0vz/E7wmxDwNCQX BK4NScxYF0LdmX/NWRVCs4UVzeEPgVczlsyUGzI1yRKaexTYrznHByVBph+zzMrbDpSlmkP9 Coz9+mz3RNBHeCN0E8yvjVP6t2B+Y+zyHgS52jhsXgFzPVOVUiDyEGcOAT3J8NcbgLOk/73A Q2AdZRvgaAFGA1nJqAFJDxL2xV0Fz2eulcllwJxmfm+sBstey37beHA0d9YMmgf2pbaiAVnA /Ei0djyBpJH6MdtGSFznycw0kAHKZ+qg9xeoqQfIMTvG7BizA5YtW7Zs2bK0A8z076d/P/37 tPanup/qfqo79DrT60yvM6B8onyifAJikVgkFkH3Od3ndJ8DJ7ud7HbyT9zCS02ALy68uPDi wrRKXzmlnFJOAe2qdlW7CtFTo6dGT4XLymXlsgIVK1asWLEiLKm4pOKSihC8IXhD8AZYN3zd 8HXDYd75eefnnQfzJ/Mn86ff33+b1m1at2mdNq7UKSbNdjXb1WxXWruWkS0jW0bC2Xln552d 98fjet9ypSYafy9XlWVVllVZBvN6zOsxr8fv95d6Qg0JCQkJCUm7Nf22vK1+3lXuP+LvK1RP Nj/Z/GTzP477HypYpSlNadjeaHuj7Y2g78K+C/suhDwH8hzIcwCmtJjSYkqLf9xfzsk5J+ec DNWc1ZzVnPAs47OMzzLCosuLLi+6/OfHkUrqrfDUCr2maZqmpflB6oXYn7XH31O2b9m+Zfum VeD/rF/8HqkV24dfPvzy4ZcQ/138d/Hfwa7xu8bvGg9NXzZ92fTl+7fz9I7TO07vCD269+je oztk/Drj1xm//v3+gzcGbwzemFbJ3bRx08ZNG2FFlRVVVlSBN/ve7HuzDybumbhn4p4/Ydd3 PI42ydIkS5Msf2PfqJZRLaPgUt9LfS/1/ff7wdv66fuy69/zR/H4tn7w7+ad5zjbxmlXlDKQ eMztb2kJZoDmb3WDa6b+0kgCzW7blTQG5B79tJwJoqx51zUXnLmxMBYiBhi/2T8G2yDtUMoi sI1XfrQuhITNccPxB/OMu3nSLjAmK62dWcBvRFg5Wwwk3E4s41MJXh1xvUzqBwFP7KvVDRBQ n7M+x8F+PWxoXCS4Wsd394uEC53Dx79YDkU77m+9pDxUK1SvUZ+tID5TvWI4hOe4N+VJJohx pSS7qoH7hr5FzwOOkr5fOoqCeUkOlMPANdQV43oAPGGrOA1GOTnZmAL0luOUZ2Bul5fkAhDD 2cAK4CB2uRnkTnOFbAO8Fg3lWhD7FY9YBlpfrYH2OZjzzFkyCFSptdA+AfMrM8ncC6K/cIpi oK5S1ystwTxjnpHHgTFyPwVAGcF+9VtQsglF8YJ2SXsj6oD+Rh+lPwNRSM2vJoCSLMqKGaBM VQ6I18BL4VRvAJ+L/rwCVWhltBygPDSEcR7YJF8SAvKQklU+AVFB9lP7gygiAsQpUI5Rllwg 5xEqmoJ4LLwWF/j+HHA/4DLYz/lI/x2gZ9PPGvcg7tO49a+uAOuMqKQK4P4xqVzUFBAWNav9 BciT5nW9I+g/6AU9k0EdoIbFjge/yb577QPA3Sqlf4odEirEfx7TD8yLnpLemWAU00Pdw0B+ SAWzPcjxYoqyArgiRim3QRzhlSwPeoDxiQgC20ZnTIAJtvnO7/1HQnL7ZCItoF8xArw1IOiJ vytjNAR+E9QjSwiIr9XcfAyiqIb9FmiVLGUdpUAmy2LUAy1JK67dBC2fOTPlI9DvenomXwG9 naEwBNj8thH13/NDwR8K/lAQ7j64++DuA7g25NqQa0NgyYklJ5acAAYzmMEwm9nMBmRpWVqW Bm2vtlfb+4/9iYviorgI5jPzmfkM6EQnOv3z8hQ/Xfx08dNwb9e9Xfd2wYViF4pdKAaldpTa UWoHWM9bz1vPw75W+1rtawV+K/1W+q2EoFtBt4JuwWeVP6v8WWUI3Ru6N3RvWmW1atWqVatW he1sZ/v/Zf/2W/Zb9ltpvyNzRuaMzAm1dtfaXWs3UJaylAWsWLGCmCqmiql/PK7UW6bvSy7j J+Mn4ycwW5mtzP/mG5KpFz65yEWu/6a/1Mrqu/K2+nlXuf+I2cVmF5tdDLwdvR29HeEz22e2 z2zwssnLJi+bwMaNGzdu3JjW3n3Kfcp9Cr4K/Crwq0A48urIqyOv0m79Dro56Oagm2Abbhtu Gw7nep3rda5XWkW6R/EexXsUh899Pvf53AcObDmw5cAW2Bm7M3ZnLIxmNKPfQb/ikrgkLgGN aESj/2b9f8UbwQQT/O7++r784vdITaRqz6w9s/ZM2N5+e/vt7eHKkitLriyBCV9P+HrCP5HI vK2dU6cCHelxpMeRHjC97PSy0/+bxCu13fQn059MfwKN5zSe03gOhEaHRodGQyihhALBz4Kf BT+D5588/+T5J2+vh/d9HFUWKYuURWn9/rv94G399H3Z9W3jMZV/1g/W+K3xW+P39vb9s7xz xTnGmfCh0RXMsWoGT3fwfqJ3JB5ebosclvId6D8kCTU7BFVWT4X8BpkyBPyW6AQ13DgnFkPG g74NAyZDxkYZPhezwFLbUjuqP4SGBh+0FAFnN7+Mtr7gO9rWgG0QNS/pVMwZ0DP6e+KWQujg bFNTJGT4IGCxszAo2+wjmQ6J+eK6MAlcr9z+3k/Bc9RxN6U1rA0413Vdd9hbbEfQ4iXgrvZy 9SM/eNHkieN5GMR19AR480PyLuMbcxyoTSxdLD+Ct4eex7sfXCM9KZ5hIIswRJ0NrKazUgFM m5xtDgfZh1jZD6SvPC8fgFHbjJTrgQnKc6UViCPqduVzkAspxhegtGK+qAXiJ/mah6Dn18/p 58AcIv3kI5BX5K/yOBirjWnmQsBJMhLMC+ZRcy/I3rK32RPUieocZSgorZR2oh6oo9TxylxQ fhELRTdQX6nh6nZQ9ip7lamg/CAmifxgKW0ZaPkWtJbKNjUfaEXVaVoUaE6tulYbtCQtxlIS rJWtN237wLJZy2f1BzlVRIgwsGaz+Vk18Knr/9TvKlgH2vfac4JsaE41p0Ni3jdLIi4Cvbyz ksqBcldk0/IBk+RN5Rmo1znv6Q9KRTnfGAeWe0pvpRBYu1veqCr4zPS3B12A4NohVzIuh5yZ cg8p+Boytci+MR+QvVjeex8EQo5L+eaVrghhU3N/WuJLyHo7z+wSsyHLjznmFj4C2cvmjS9V BnJr+ReUXg1qHWvuwIrgezt4cEY35K/wweBqJyEoc5h/4XvgWBT8JiQJfIL8+wQVBvGh1tJS GIynrOELUJdpK9RdIAOSWkcehMRc0d8//x5SOicNTtkNRiVjofR5f4Ha9ru237X9Lq0S2iam TUybGPjywZcPvnwAV3+++vPVn9Pap85pWz5w+cDlA9Oeak79u3TZ0mVLl6UlhP8sqdunVioK JxVOKpwEm+ptqrepHpQyS5mlzLSK1YqqK6quqAqVrle6Xul6Wj9Xrly5cuUKDLg64OqAq2lT AlIrD/8//1Vh/COyjs86Puv4tErThQsXLly4kFaZHDli5IiRI/64n/ctV2rF5e/noJ+X5+V5 CV9n/jrz15nfn5/8nr3eVj/vKnfqfn/XXk2zNs3aNG3uonWpdan1bxKA1OWpf1NvaadW6FIv 3FL9b3+u/bn250q71Z06ZWhuibkl5paAH3v+2PPHnmnjj2wR2SKyBeSPzx+fP/7d9Zz6do/U KSWpczVT71AsFAvFQvE3439P/vq2fvC27VKnbMwz5hnzDKh9v/b92vdBu6Zd0679cX9va+e1 99feX3s/LfFK/ZtlR5YdWXakbZd6hy31ocb2BdoXaF8ANjzc8HDDwzR5U+1cqWKlipUqvr3e 3vU4uuPljpc7/qYyvzl0c+jmUCh9ofSF0hf+/X7wtn76vuz6tvH4tn7w7+adK87225nCY8qB WOGt48kE3mte3d4bEne5h8VZIOgT+Th0IRRonXl+lmEQetO3Rcbv4HaEpceLIHgVf7+jmRHs Z5VSAR1BTBDJyXXg1bKkF8Yw0M7GlrduhuDOwcO0s+ApF7z6zUgIj3zsSDkBGVo46vpPg6SK /lW8CpCQ0Nv3R/Ab4O+Rs8DWKUTYJ4DHGfH96+EQe8Zb+dVMOFHh3keHC4KxLSnKMhnC18ZX dq2ApJduh/cCmBaR01wLWg3tQ+0rcP2s5/E0AW8Jo7b3G9BnUFbMBTHMWGj2BtlAbGQLyJVy IvFgzjNHGqGgrFByip1gtjB7G7tBH6l/rc8BbYC2wDIaxDBxRVQFY70xX58B5FNMcRiMfJ69 5gXgGpK6oPQRk0UbEAVEjGgEVGAig8E4JpsaGcC8I9fIjSAfU0r8BOZa+SGxoK4Rn8vbwCom MhIE4pJ4DbKerM8bMI7rc/WVoHyhjdNOg3JDOSLcwESyiZMgP5JP5WoQk4SiFgYeaqHKCtCE pYg1CSxzbc8drUHeE/Ot34JyV4zVKoBrQlKOxNZgfsAmzzaQpdWy1iQQUYrbOh+0jeKxZxJo VtWqhoPa2nbQuRREDstjqwSfb3x2BfYFtb62w1YbdCmHmAlg9qCP+BKsr30W+A8EcRl/pSGo fbXWVivQjpxsA/krwXIdKGFkNW2gKZa71qHgGpaSlHAZrAVUu94PArr6/5rtZzDHM8UoAMpT dZlaHORIWY7DYHxqClkdRHuxXvYAf+k703oV9Iuugfo5cD3XwqxnwfEkZFFYD7CEOWb7VgMx TgxRJgPD3k+gdjvZ7WS3k9C7VO9SvUuBEqlEKpGgrlBXqCvgq4VfLfxqYVr7URlGZRiVAaaM njJ6ymhodqfZnWZ30tYX2V5ke5HtaQ+3/BGFjxc+Xvg4dDrX6Vync/ALv/ALUPlG5RuVb8Bt n9s+t30gS3iW8Czh4Ih1xDpiITJHZI7IHGlTOyhJSUqmPfyS+jBh6lPwpc3SZmkzbX8zF8xc MHPB/19Q/13GjRs3btw4mPjNxG8mfgOuLa4tri3gWOlY6VgJX2T9IusXWf94nO9brlEfjvpw 1IdpiebasLVha8PAOdg52DkYxmQek3nMvyBx/nt7jas0rtK4Sv+8fv6s3L/nJ3/EplGbRm0a BYxiFKP+cf2ZuWfmnpkL1KIWteB6peuVrleC61zn+n/TX2qF687MOzPvzEw78Xr6ePp4+kAF o4JRwYCROUfmHJnz3fWd+vDYJH2SPkmHBhkbZGyQMU1frXe03tF6B9CVrnR9f/76tn7we/b4 vXZFjhc5XuQ42CvbK9sr//NTNP6snXO2zNkyZ8t/XG6dYp1inZL2O2x82Piw8dC7QO8CvQvA i1cvXr14BTOOzzg+4zhYfrT8aPkxzQ5Dpw2dNnTa28v7rsfRhx8+/PDhh2kPUwbnCs4VnAu+ uf/N/W/uQ3Tv6N7Rvf/1fpDK2/rp+7Jr6gXYPxuP2apkq5Ltv5mr/Xt+8O9G/J+5bFJWqFCh QoUKb99Bjw/G3C++B0oH5ttZvh64ovQLnl/h3Jk7z09dgYB1zoE+oyFzGf8K2V6C+UrZY+kG b56/+ijiAtxZ8KhEXAMInZH5pOUWlLiRqX3Oc/Ck2Zvebi/4t6CG2R8iW2oT4oeCjy14iN4S lBtGBbkAXqyMK+2uBUG9xcFs88F8mjgu+RhkmppldIZY8L9p3ZlyB2JLJjlcbvBu0fbHToPc 14JLVuwDBR4Hu+o6YNvlxX0WL4UrpZ+WeHwNUj6VHa2LIexMtnG5YyAxOmlD3CZ4NvVF/Sd7 wMgv8mkPwTxu2GRXQCGPvA6iHTdZCmaoNM3CIPfKs7I7iFyiuWgH5klzv7kDlJzqYKUSKGvE FXUByDvGF/Il4BB95QswP+EbMQnMY+ZN4ywo3+GiMVBOrhXNQVRWLogRINzKXXSwFNSwNwTx SCyhDyhfKRHyBih9lP3qZlDC1S22iaCd0B6o/UEL0e7YOoOcTG5zPcgbMkW6wH7cfsX5GKya LaOzDajPlaJqKVAyqoOtZ8GSaP3clgWUGO2F2gWMfaIb20ApKx5ZDgO3zVDzLrgjXNWTZgE7 mWB8Ao4+9q72V2CuNM56WoL+lWtEyvegVdS2WweDKGfZYf0KxA/qSusckPNZqXYD0zDDzFUg T4kQTQHxTFmm7AFzl3lInw+upSlPEzqA4stuGQ+yNv5KZ/BGmI3VkpAyPiFnzEVw9/empHwK wb2DK4V8Br4/+CaGfA3uOW6flKKgnzVfJo8Hy1Jlm7oXLHkdw4PrgDva3dazCgK/cKAtAGU/ P3rHQGzNBE/id6Cutz71ewpqPqUR0aAc4KqeF3KUzRhn84XF9iWXFx379wd2Oumkk86fJbUC eVm9rF5W4fsO33f4vsO//5b4/6uk3rFJrSCn8z+Ds2fPnj179j1UnF/NiM2jeuHMjw/Cbp8B ucvzJGEUhAzw+c7pB4rud0I5C1Gvrfcit8DFhLORby6CbwXHKXESbK1kBbUNZJhDUIbxoOb3 zWmOhzxXnKrlMjw/+/RJdBzoW62Tk7JBXP/kud4aoOUxj/uEgnOIKi1zwZPPnSBXgnNr4GBx GBLzimUvW8Arv9hbemGw7bT19S0GfsPNHL5ToNyIArurPwdDiW1pmwwx2eOPJYwF1xdGWaMO KJu0SuJDEDvVs/I0uC3uj7xNwKikL5UWkJFaMVOAXGaON5uCDJHZ5FWQFRgsM4N5Vh6V0aDe FHNVC5CNQzQHmU8+IgroafYSB8AYIzcZAqiJSwLckQ3EDJDnRTA2UAYqR2kNSqj4TD0OPJG3 RQxIP3nKXAq0FKVFBTA+kDnMbODobbvkDAZ1itZTVcE61v6pz2/g/1PAy5DfQBwQn0kXKMNF P4sCptXo6lkJpmlcMU+A7Te71b4AtPy2ofalIJ+IDpZmoCarI1QBljPqFu0j0OPMIp7KINxG Xc9HICtLw6gOSjXNV/WAzxm/0T6JYA70rjVGAdFmJ09XEIJnDAXbbd9WgV7QMmvNtBBQe2m/ 2J+AecL4WQ4DcUY0kbfBbMlRORH0Bnp7ozqYN/TzKYXBXOUuknwYrPWkj3ETPA+NIGLB/bV3 gZ4TYpXon2MKQ9KM5CMxWUAbQBP5FeiKq0fSr2BWyXLf7AT2Eo6Cdi/oBz2G3AKirLJVzgPv xqQscWNATpU91aHwZo+7apILzGVmQb0FiJ7WC9Y9YM1iTHJtAmOM/pt8BYE5fKf7lgatH071 NrDsrw71dNJJJ523Y9eEXRN2TUh7v+6UOVPmTJnD75f400nnfxHvnDjneJVpmfIpxHV3nYro DQH71ZXOOpCho+bjWAExluRsiQ3APUo7pn8OxcwCQb4GJJczFsv+oMWrm+yTwfY64aZlNJjl U1zeuhBoBl71/QbsKa7WxiTw8RPTs44C9zr7Z69fgvuqMSvlJLDP28DREsQCBsVEgKu83lW7 DtoWpbimQNCQkLbBJ8B123nNNRjMr2IGOa5AyNcB1lwh8OutU12OHgLPKeaxB/QO+vfmOLBs shYTbYEFog2B4J1iDNSDwRroMH1mguWGM8gvFvQI71B5B7iMQwSAfYLD7rwAtmG26/biYBYw ftP7gPewLr1hoNxVx6t9QUh6K7+AMdfooH8CylXlQ5kMljvWSL+qYFrFQ7MssFpGiA2g/WSp a1sJvJF5OQxGsDfMfQzUwaKMUQK0pRavtQBokVpFax5Qv9SsFg1YogjlS7Dks4x1NgHzV6Sx D7RByi7tExCd6SU7glpenacGgfGJeUHPAXzNI6UPiHFiPVeArbKGfA6ymeyjVwOtLdfkflAd 1p6OMmDEyjbKUxCz1abqOdA/8dbw9gD5IzFUAutnlqG2YuA4ZG9vvQjuO/pPsgGYS80E3QJy kPmdEQrKb6IVbhDR3Df8wfiAJKUHGA+MXmYH4KysJnOD7ymfYOcLkD/p283vIOJ8pD1yJEQ7 3gx81QU8rdzVEh+CecI4YDaFlIvebOZzMJdwSPGDqAuRrSJGgM8c58CAnGDr4Mjg+xvEnUn4 JjoX2D90eq2lQDxTJ9jXgzfBfdRdC2xjVD9LJ7Ac0X9VzkJyjDdr0jxw5vEtErAc4uYkdEn0 Ad9LaqBlyluHUzrppJPOX06Tl01eNnkJTWjCe3hb3/86tj7d+nTr079ainT+Vbz7e5z3J2Rw ZYWcXYLXZgZ8C9gKO59AYik1Xg8GdYH+mxoFGcK1PD41IThnzivGZ2CvYM+s1IeQJlnDwo5D lGoJjy0Mr/K+KmQ9Bnnv+xcvEQIZ1UwFApdCBpffXbcJGTrYkjL1AuVrPrY2AB6wRu4A75uU NvIE2MZYftL6gDO3raE6A9y77FVfL4DoZpF3Hu2HDwrnflBqC4gxih8N4FmRiIsP+oP3S/O6 4QDzllmdn0F8oTRQ4sDMY+YWvUCJ0jqrLyGwfMjJ0B0Qmjvzsty+kLVL7vsF/CHsUM4y+XQI 6pTxWbb64OMK8su0DHznZvgsywPwV0PvZW8Cgccylc3lAH89tHqOTyGgeYYfw5aDb2BgvVAn +HUO2pd5M/iFBLbJdAz8LwfdCC0Ljop+N4Oeg+Nzvw7BZ8Avf9CwjIfAOSrgh0z5wbrQ51bQ ZlDDHM39a4Moae3okxOs++0lffeDesQa75gD1tq2uz4rQR1rdTn8gIa2n5y/grlOqanOBqWC etjaG5SW6nOLBWyfWp7aVoP9uT3SsR+M1uYZMwzERK2C9iOIKuoBZQ9oEZYwdTuISBGhBIF9 mv2ycxz4tPDJ7JsAdqePJeBjkD1FVstOUAYavcznoD0RkUQDu8wPXCp4wt0F4hqBK3NKn8S5 kFQ9bmHsIHB1TGmX5AvKM2WZMhuUFdpu6ygw5ptTPFUgtEPgFcdSyJw/pEBQTVA+VZbZNLA/ sXd2dITM93P65rRCxivZz2UfDYGNAisE7gR/H/8ivhXB8tz2SMsAgfUDSwe/gJBSgT0y1Qar oVw3j4CWX7uglATziuIRsWDMFAP0YWDra62jLQfGM5omoH8lerMBvEPYwf/iT7ymk0466fxv JdvrbK+zvf6rpUjnX8U7V5wtn+nfBY4Bs3X0EUtTeN3OvTRlLWghQa6UkpCQh/3GbjAOR3zv PgRB5ZwLtFiwbVV/UXwhdow8+SgRHBkCejsPQtJx15T4NXBu8Y3zFwDtC+sEtQ849vvX5mNw jUuI05uAXoZK/Aw+Ub4vlZpgqes65QwBb4fkJ55kcGcOaqs1BMvEZH/fDyHEos2VHaBgwWxZ KzYCOShluJIC2h7ziKgK7kZ6HyMneIvI5/JTcDRTR/ECZAFWydJAHs5qY0E7Z13m/wkYVcz1 3tfgXZQ8OPkayDaysbwOyo/aIGtfUM9aH/hmBXWJWtyxBJQBaku3DnKgft1oDKIsjYzWIJqq uagMlkR1uY8T5Br5i7ckmBXMmmYxUOoLi7YIzBSKGfWAiaKOchTsSfaP/SwgbHKdeQYMyRf4 AN+JouYY0D74P2/dUKeIibIj8Aqn2wDRmpXqShC3iJItQGthNtd/AVP3xCfOBJooX1gfgZJP jdU+BWOSHoYXzDY0ojcwUfaXjYG6cp/IAMZVo6GREYyK+oOUQWA00LczDDy3vS9dkyF5VlxM dEaw3bTPsHUCe3d7f8dR8NECtob0AuEvpmmTQeljdnSPBHOY3CnygHlJDuBjsE1UMypHIbmC u6q3L8RY4zYnJAEuv+aOKWC5pf6izgff837HAq9DwL6QHzJfBtXhfJVpEChPtEw0AvUD2xBL eVDnGCMlIOuI0nIyKLM1X0sUYKj9HUPBG5SyOGkLuM4mN0uwQdAkv2Z+W0HNrxa1dofkMe7v k9eC0Y4IdS/oBXWDb0DNq1a2C1CXWmdSGCiibdf6AdD5rw7ydNJJJ5100knn/fDOifPLS9E/ J8yDR2PUQ9FtQd3kV5TPwN41uZ5vJzCdrm7yCCRu8VhS4sB0uV7bO0Km8Y7HOZ0Q9W1izJ1r kLeqrZs9LyRn0Kpp2SB2rDuf0RmMxITuyYfBr1j2Xp4J4Ghs/8V9C5KOXZ3g2gHeKtaimg6Z Vvu9CeoPzhbUt6+DDB3Utc5jkPjM0y+iOdTYWtpd7x7k3pVhSMEN8Nh++/mdzOD+VF4xFTAy iRFGYTBWsFK/DbK2OVTbDzKvHCrqAS7hr+YF5UPLYkcVkD2VnNpNsJV0zPa7B9613jyeqaDV t2bSqoFSSTzVGoBZXK+cUhcIJMJoBHxtJorRoNxWW4t2QLiYpfUC7YS1gaMvGOtlDDvBmtc6 yaKAvKPHG3dB/my04QloHm2lWAGen/XzyRFgzpbPbENAm8ZQ+TPINsbglMrgLW9e8/YBzzh9 vCs7iPrKcTkX7INsW3z7gGu6Oyx5JNBZyU090L6lvS0ayKtl8eYB4WN0ozuouppFGwbGYMPt bQ/mx/oH3vuglmCmeRtcPZKLJTaBuLVxVd8cAndP9zRXITCW6dVducGa1dJBGw7uae4bohQk hcQNV0aA+7Z7bEoPMD2KYZsMNDb7e3tBSoPE+MRV4PfC/4TfYrA98SP4INiW2+7aSoMl2JLb YoJ+WFY0yoAjv6O//UvQ6ju6+T4C/Qd5lBwQcj9LbesMcC9O3u39DLw1vJGujSDChdtbCtzt UmolVgVzPCfEKVA2KscS2oC7WkqdhJrgVzZoeIAFnAN8p/iegaT88U0Sb4M4aiToa0FbLawE gvtjt4164Pk45VzcfTA9akZSwG+gWsgny58MqnTSSSeddNJJ5z+Sd38dXVdn88SGYEuxF3J8 Dimxeh9zHwTUt9XzKQF59+Wq7ywM97I8uxn9Blynkn9UH0FiS1dIxD2wbrdvUMIg9lBisLYJ 9MYps43bkPRAKZaSDRz51aJ+J0DcerY52Q7xHVNeeTXw3tb3+h4Ht90o6coIOZICd3geQtZu 5SsGbQTlkqNpzIdQtI/epNwTKNuw4Kh2DcBZ2rdYaCTYT0r9XjiorS/3EE9BX6EPFq9B3Wfm EDfAaCdGeaaCmU0WN/sBbeVqIwfI5eY28x5YvrUU0JqA51Ozr1Ec1Pr28fYYULZq9S0fgZhn zpM7QXTSs3hjQT9hdDGvg6nISfpFUG/IjJb+YDlh/cVaALwbvP2NCcB6sU/pD/pxT0t9ISht yaysBuNj74u4xeApllLA0wnUTuob50QQ5az5lYNglvNGur8EOc7I460Jxh2um8tAySFTTD+w 3rKss44DlyXFL8kP9DC9SvJB0Hpq6yyh4FlrXJHfgWe7e5c3L1gXaIptLCiXlBLqGTAW6Vfc B8FeyHJN3QuumMQB8dMgsVNC0+hxYM7XFxsPQe/p6ZP8G6huJUb7DczC5BGXQO+pHzTsIJrK Id5skDz9dYOXGtgyOdf4PAFlH4OFF4xwb4o3DqIav3mTshOcbb2jjCDQZlmq2QNBGans0JaB rZNtvNUORn+xRBsG8eXdE40RYAbJ3/CAd44+3psZtJnWbdozEHuNr5WK4Pna+6t+DzwDPEM9 Y8FdP6VcwiFQM2u7bUNA9SoZZWPQP/dIz2B4ufrV3deBkBQUr8S2AGsBtbzMC7a19vu+PcBS Txvt4wR3hZQ7Kd+C9lTtYgOUneY5d3mgKfAe3hObTjrppJNOOun89bxz4myc1VdYSkDoDUcx uwkvYhNaezeDpki7owWktPb2MQ9CyjcxP1kE+F/2z+OfBA/7hGd89hS8rVIS1a7g5+M3V+8I UjUfqyNAPDQ6xs4Bc7s6Vj0A0d++mKxUgkyfBf1sXwq+NbOvMMuD8iBhgLMX+LW1hidq4M3z pIQ5ATrUa1xp0seQ7+eclWtOA0+Ano9vQM2t9DcygDgePdHvObDrzTFvXrD2t5SzPgRjhfpI vgTlutFV6wJiH4PFSTAfmKO8ByHlUML5qCqgB3mqOAJB6aNEqVFgbtKe2xuC+UQbZ/sJ5ASj miwItkX2OvZSYA1Sp1q/gZR8rtbxp0A2YSh+4L1u7DGOgSosvbUcIKab4z29waztaee+DjjU dupIcCUnnku4DWZj477+CKyR9iIyFjzexIevK4Ntnr26/QX4TvHvGtQb1MNKCcsq0EcZDwwb eOp61roKgfrUEqvMAFGGq8ZBUOZpS2z3wNtcOlKugVaX5koHiG0cvS8iGSx11XjlHJiZzXv6 NUhZyEppAbO6OdXIC+o3aoLqB3ThjNIFRFfxEzroRcyRxilQ/fXz4gvw1tXnG/nAbGbu8E4F M9J8LIaAGc5KMRIoSQOxCqzXLbutn4HxkOMyArxD5BUkqINEQ2UayGSJrAQyXO6Sc8DT1B3j nQNmGyXC8IB1tPWs7RHogZ6aZjy4l+hlY6eDiNA3eyuAUlbtIR6DNl24tSygTQtoFjwenIGB 7kyHgYfm53IlyBH6NL0qmIU8PxuTwDHbuR4ThIeK3tFAB+VXaxLQRCwXW8Avt9/D4O/Be9B9 zygF8V3f2F8NA2L/6hBPJ5100kknnXTeF+/8cKDWwH5DHoH4+sa4yD6gr/Kccp+HmErRmVO6 w3XP3WGJuSGpoW07DeDNI0/9F1MgLEvQZhkGmYtkuKMsgaTXzinJd4G9rJCdQemuBlgeQ3BX yyHvZLA1VwuYY+FxtcTA2BuQMCYpWHeAuxMz3KWg+NNMw2o/gwHFW89YexNyT8iRt/ZySH7k euj1BU8274dxP8Pzh8+rX10KUc1vZQ0fChmTbd85y4FNU2eoNlAGKyd5CPKBaG2cA7FG2anM BqmZETwBuctooc8Bbbi6xvoUnLv8LmYKB9+vA78OLQMO1SfZpx5YLzg9ltFgu2f7QC0JAulM vA2OXwIOB5YG33v+VYNbgvOyo7otF9iCtHl6WVCHIOSvED8i7qM3xyGxbPyO6Gqg/Ky+0OJB b6jP9jogpVx8hVcOMHfrDbwPQY4X4ao/GK1lgLkS9JF6T9cFMKexTt4Hezn7BUcV0HJY6lj3 gXbMcsBxCuQN5RfLG5BfiliLBE8vVzXPWNDregd6ykJi1oSHURfB9TIlQ3wmSG7gmppYA+RT oZurwFwj78n1IJqIzdIHOE4LsRtMX6OlsQbMSUawVwfG6V09w8AY4B2h28B8aS73tgDvQe8M d2eQQWZbcQfcZbyTPfXAOsR+2bc/aNuUL60bgBfSS3ZQt2v1tK7gPaf30n8AT7hnbcpoMAcY MfpdMMvzHZXA8qttpCMC1JPWb/xKAfvs5y1PwV7GWcC3NjgXBj7L8Ax8qvvnD80Ktl6WeFtB sIy3vLL1ArevJ7/xK2ifKk3VduDc6HxkbwU+ef1aBkVBQI1ga0hX8IkKqOYfD5a29qa246Ad kC28hUFdZatseU8fP/lPZlreaXmn5f3H5anvMf13kfolr5kzZ86cORNq+dfyr+Wf9uWv1A+b PH/+/Pnz53+11v7fYdWqVatWrUr7gEHqFyAH3hx4c+BNiMoRlSMqx79Pnn+1X/2eP/9P598d r/8utjzd8nTLU5jyZsqbKW/+cf1/mn+n8/8G75w4u2y2UfF7wOEXeM7nKVge+5SSrSEx0igf Y0LUZ9E/vFkH2RZaEgPOQWzF+ELKOvDNaduXJSf45LB/p1yAAjlDnvhGQ0CsT4qyEHL18euX aRpoCVph9WuwXJbLrYtAm+h1BxSCqHOv7iY2hg+mh1gLfgFt7/S4O+UMOKeHaFnzgftHV0zi bBA5ZaReGuKuvQx+1RvULt57AVdBWZ0QZsyHzLFZdP+NoDQR983KoD5RH9leghxitPG2BBEm q+sfgX2Q7Yl1FvjMCJoZ2gX8G2XqnvVHsM31X+iXEdQE2xPbabB0dbic68DvfJA9dBl4eujz kl5CojPu/KutoJ73zkvsAp6A5Hpx88E9ODl3XHVILpn4dfxBwCI3mOfAV/erFjQS1JvqXNaD ctu6TG0I1u1Ot8Mf7F869vjXB98VQTEZw8Anr4+v7wmQvXS3sRFkAdFf7Q7aVi1J3QdmbbOn tw4kDU0aEf8lpCx0y+RSED3v1YDn5eDF2ecF7z2HlCmuJ9H7wf2Bq1zKAtB3efcaNcHcaBw1 iwGr5RI2gaekJ9YzGbxlvIrnMhhWo6SeB5T+SqjSGEQVYRG9wWxHefEr0EKJVWYCgWKzWA3a FHWAdQOoh8Uo4QRveW/l5A9AOaRmU61g22PL7XMNNNTKWk0QxYQikkGZpzXWDoOaYl9pLw3W R9bu9lBQe6otldEg6+n79UYgTsk47x2wjLMlqyY49jtLZBwEZlNlltoOlPbWefZwsGa0BNmn gLHRc9HzAFxfJ26JuwjUkHO8L4AKjHJ1BbfF1Th+MSTvSb4b3wrcx10XEmqB+2LSpKSXYPbz 7kiJBVsP59eWDyBkbMirTN/91eH9ryf1k7d/NSdmnZh1YlbaibDnmZ5nep6BT5d8uuTTJXB2 3tl5Z+fBt22/bftt279a2v98jh49evTo0bQLkRqf1/i8xucwdM3QNUPXwKlup7qd6gbTC00v NL3QXy3t++M/xZ/T+XMcbne43eF2aRdAUw9MPTD1AFxccHHBxQVp7f63+nc674d3Tpx9THe/ jJMg0PS15rwNYeX8T4Y1gtp3c64uWwjqb6vxqPwZCB4W9FCkQJlv8h3M1gXkPq2u4QHfhz7f BN+Hp/kSZyY1h7jcKT6W5mCUFcNTcoOySay1J0PGZYEFM9eFbDdVv5hq0PByoe0lB0NPv75X Z9cHV5DsaFYF46rnYcoA0GZrMfbjkDI+qXh8ADh62RcrZyEm+ln+F8XB9pPVbo2CwoNKR5YR YOup/Sg+AK2Y2GqpCrK5GUFHMCJFI/V7UEztV/sKULYqD8UdkC+M7J7fwPDx2JO7gvGrq17C a9CPulon1gJP1uTmiY1AGkZmyzJwzvMxg1eAO0tyv6S7kJIx+U2cAcZ3+gfyDCgtlfrWMuC+ YXyV8hVoD20rtWfgzBtoCUkA23mfp36TwO9+cFymB+BICvol0yKwbLe9ceigJ+mK/jGYQ40L xmIQpvnQ/AaYYJQ0KoHH41rnGgHW/raallqgXda2W+LBb2zwtpB+EFYrm6PwaPAb4vNbpi/A /FEfmdIAjA+MTd754B7oCXJfB4/qOeNuDsZWfZF+HEyvlHoZ8A7Xu3ongu5rHjQAozu15DMw UvTFnllgvjAuelaDmqTsFjNAuarutrQCLbc11ncV+AVnqJzxFQSZIZ9kywjWZvZZfgVBLLTP cH4OahZrmC0OuGB8Jz4Fa2c+sI4AmV1EqRtBTsSp5gf1kXbMcgxkKXlY3AXlpJFPfw2yuHeI VwMqGfWMX0HdrJRUMgBx6mf2PKBOsd6wqWBf5zzuMxZCP844O3NlsPd3fBMQBr69Aw5kqgQB qwMuZwoFJUpr7LwD4qqa2zIXrFdtp33agLlGG+nIA5Yi9g3O6u8vUGNjY2NjY9M+mdpwW8Nt DbdBswnNJjSbkPbJ19R2e/fu3bt3L7Ru3bp169bQIkeLHC1yQOPGjRs3bgxLry29tvTaP+7n 9ypPf798TPiY8DHhab/7XOxzsc/Ff9wutdLTdFfTXU13wbwS80rMK/H24281pdWUVlN+Xz57 FXsVexVoe6jtobaHoEvnLp27dE7TUyq6ruu6/uft8M/q5++XT+84veP0jtAkrElYkzD47vB3 h787nGa31Pfmzi46u+jsomnb/1k7vqs+dzfb3Wx3s7Tfn5T/pPwn5aFC/wr9K/SHfVP2Tdk3 Je2TxO+qzzmn5pyacyrNXl2KdCnSpQg8z/g84/OM/7jdH/nV28bL7/nz2/YTEREREREBPbw9 vD280Lx58+bNm6fZ9Y/8ZOWtlbdW3oIOCR0SOiS8exy/b70mJiYmJibC4MGDBw8enObPqXd0 UvXwz47vfflrKqe9p72nvfBq4quJryamfQHxr/LvdP5n8s6Jc0CugAPOXJAYmXgiYiV4Lifd iWoL+gXw/ghjBnVLWlsePm7TeNeAdRCa0c8/JRny9claL8swyDJf+9TvNGRu5GxpXQ4ZcmTs bJyEl4YnyHoLnn6YeDdqEij53GXu9YMGajlL+5rQpWNfZU5RUFoElPQXIEp6v1GLgWinBqk3 QL8pRxknQfqbH3ueQFJ/7yLXDxDb8+XriJGQ8/uSJ6u9Bp8FoTlzjAFHgmWNlgnseTVfSyAY XeR2cx4oDnyMj0CdIPqL4+B+lFzf9Qbc+V379Gcg55nXcYEu3cHu9SBtenXvTDD26t96boCW Xaw3+gF7rVUcMaDdsfv7WsCBs7q/A/jQekY5CNbtjqqOY+Ab6p8QXAocF3x2BU4E21j7D74R YAmX9UUe0O+k/OaeA2KUVsHiBXWvtZ6jKljwtQUHg/UX34JBJ0B8qm61fAme2eYqtQVYmjvj A0qC9Vfn4QzDwGn17x92EnwP+RXIWAh8OwaVCS0BznZBYzPNg6wD80ws9SWEJmadnyccgndk GpHDH4K3ZjqR42fwbR8UlbkGWArbknwDQUm01POZDX71AvZnqgBBCzJUznYNHH18l2fSwO9h cL7sv0BIu2yjiyyDkDw52hXfCMEic3De7yAkW6aR+R6DvbXPyYyTQNRRyqrFwVJHPSY+BmWO dBq/grHHqJxcClKepHSK/QS8X6Z0j58DzNRrujqDEeJpnxwGSjYZaNYCo6a+TskOZnaCPQvA bCnLWxTwVPRkM6LAu8bzU1IvMPp5PCkTQSkoC5l1QSzgDnOB28KU7cFT3L3T0xj07d4ofRXI HKbHnA2Kj/KV/BH0Au6NxgZQrfiIi+DMabHIiPcXqFP3T90/dT+EPg19GvoUdr7Y+WLnC9j6 bOuzrc8gbFzYuLBxaRXVNffW3FtzDz4u/XHpj0un3bJcdm3ZtWXX4KfzP53/6fyfl2dC1glZ J2RN+72wzMIyC8v8Y7taNWvVrFUTllRYUmFJBVi5auWqlaven15SKXe53OVyl2F4wPCA4QFw cNrBaQenpSUw2V9nf539NYxvMr7J+L/giw51htcZXmd4WqKzbvi64euGQ7tp7aa1mwZL+i/p v6Q/rFm7Zu2atWnb/avt+Hs8e/7s+bO/mdLSvXv37t27pyWC7du3b9++Pdx23nbedr77/kLq hdQLqZeW0NReW3tt7bUw7ci0I9OO/GP7P/Krt42X3/Pnt+1nWty0uGlx8NGjjx599Ai2bt26 detWyL4n+57se/55faxetXrV6lXvbv/3rdf58+fPnz8/LYHd8WLHix0voMbqGqtrrIYZv874 dcav//z43jejN4/ePHpz2oXq7/Hv9u90/mfxzg8HijXBB6KWgr2yZXtQW0jeELvD8xxsL5jv 8IFdE3aOmHkUzM2ungkjIf+TzNdrTQNrknupZzg80o0TNyZB0Zv2r6qFQfI3whNTGY6Ena8R nRsKVgoZnWs4dF3Vtd2XuSDL2fxrytrA08/7rfdn0Lt6tuuLQXmovpYnQclJJjUa9LXeMFcg iGFmpOEF35X2dcHVId+dsj9XKwz+e7M6g0pAUrvIme5JkKFx4D6/iqDVi/oxuT/I+u61bjfI R+YayoJyXRumDgYxO+WQ6zCkfJJQJ3o+eLzWns7jYCmuvWQuuMyU6a61oDXUrlqugholr8hc YI6RbqMeiJ0iRGwB/aVe1/MrWKyWqzYHGF+41iasBv3bpFhjCAhdfaKtBesge0/fn0AMVW9b ioKaYPtBWQb6XX2Juz9QybhuTAPmy9+MPCDClUzaUjDuyjfqWFDyKaeMUSA+4CkHwXio7xZX QAmxdpJZgT3KaXUqmLP1PMZd0O5Y+1u/B5/slvWZpoOzpRkZmgRKT4uf2gbweuamXAXvLM+r pM+Ac8Yk+QmoHq276A9ynvhFKQuWycpYsRKkR/5kXAKjjlREaQChqxVB+vNM6QR6A7MdRcFo qTvdPcFWyPpCKQbcMLpbTDDyGS53ObDf0MI0Ccbn1kP2hqDswc8E7B9ZGog5YFw0r8m6oEs9 1IwCs7iIMkJAmaistYwCtaxW0BEEqilua9dAC1Bq6/GgF/a+8gwBsY4v1HDQyqg5LP3B/ZH7 qtEJXNGeO4YKShuloWU2GKpZUG4DpkiXuA6iiuq1fw/iiqW62Qt8vGoTfSPYDWtXNea/gqTd uwfqqe6nup/qDjsy78i8IzMovyi/KL+kre/eoXuH7h2gUbdG3Rp1gyP5j+Q/kh8u9b3U91Jf WBe7LnZdLNw9f/f83fNgNjIbmY2AXvSi17/uAJN6grWEWEIsIeCt763vrQ9c4AIXfn+71ArT k81PNj/Z/Pv9pnLhwoULF/6mv5yTc07OORmq7ay2s9pO+CXjLxl/yQiLLi+6vOgyjGY0o/91 w/4HSswtMbfEXBCLxCKx6L9ZvkVsEVvAW9Zb1ls2TT9LKi6puKTiu9vxbfWZOzp3dO5oIJhg gmHQikErBq2AHHtz7M2xFzr90OmHTj/A5JyTc07OCdvYxjb+PE2yNMnS5G9e39gyqmVUyyj4 eczPY34eA5zgBCf+Ud7f86u3jZff4237kaVkKVkKJmSbkG1CNuAe97gH9TbV21RvE0xmMpP/ L3po07pN6zatQbml3FJuwZJzS84tOffn7f++9Xok/kj8kXhYe3HtxbUXgc50pjO0jGwZ2TIS lsxbMm/JPKApTWn6x+N7X/769/H/R+gl9BJ6Cf5t/p3O/yzeOXH+zfpbK48G2aL92xrtwT5F +dKcC6fXPS906RQca/2ow9HtkP9q8PKwMVB4bL6bRbbB6x74v1wFl2vfPfd6LmRzZOmgJwGO JF+XFz4oWuCTfBOgfdZ2ywc1gCBLlqDS8eDekjQp+QAYiZY38gwobcUV7TOQ35grjQagFNJy 0RuMtq6E5HvAFO2l9SIo+5XVPvvBuOSa+WoueL9P+cI2HkLuhPnl7ArZE7LPzTYeLpiPf4ja A8ppj6G0ALOT2ddMBK2upaztWxB7vTm8i0DNYJ9gaQyWJkpXEQ18IZcZgNhBYeUpaJplun0j qHMc7ZxvQNTSO3kFKCPNoaYNxM8uPbk6eHO7n7pmg6mZ7b1LwWvTV7g00OLVTsoq0F+Z4eZF sFRxtPIpDEop9YbWC2RRs7vsDPptockCICsZJbyLwF7eNlMJAccEewf7cJCRUhXdAav0NweA q793dspR0Iu7Gok2oNSxVrIPA+WcuKNuBm0t7ZkM1su2SBkOYjvzzFCIbZHwYVI24KXxWq4A 7bIWZT0ISpi1sXofjM9dk1KugtxpbnMXg+Q54iEHQDXkOT0bWHap+7VCIK7JKWZWUF9S0WgD yn1ZwSgGaoD6meMWOJO1EWotEFO1x8ZBkA2JVTtDwAf+RQOjwZVdL891MEKNreZDsGa0r9fm gJwv8xtfgbeVZyEp4I7yLnd/Dw67bazWFMQJYSr3Qd/n3Wr0Be24WlNsAbWArafdDuKRzCvf gOiilBWvwSdRFlJ+g6AJPof9hoNrg/7COAh6edOlfAmygP5ElgH1ujrZXABaBtthW2nwP2Y5 q44Eq7QFi4oAfPI+AlWWlqVladD2anu1vf+4XlwUF8VFMJ+Zz8xnMNgcbA42IXRv6N7QvWmV pKpVq1atWhW2s53t/8R+PXM8czxz/rzclqWWpZalb7/d7GKzi80uBt6O3o7ejvCZ7TPbZzZ4 2eRlk5dNYOPGjRs3bkxrf67XuV7nesHNFTdX3FwBPYr3KN6jOHzu87nP5z5wYMuBLQe2wM7Y nbE7Y99f4vzP6ufvE+Y/Wp5K6i3xd7Xj2+oz9Zb9o76P+j7qC5UqVqpYqSLYb9lv2W9B0KdB nwZ9Cq9bvG7xusV7UOTfoSxSFimL0vz+7/kjv3rbeKETnej07v2kTg1QD6oH1YN/0+6SuCQu /fG4U/Wbyvuy//vSa2TOyJyROaHW7lq7a+0GylKWsoAVK1YQU8VUMfWfH9/v8bb++rYEbQja ELThr/PvdP7f5p0TZ8+GuO8s+SHlgNYwXgfr12JqYEmwDzWaGm/A/zufRblGwJsCyhEjAK6X f/TgZiJkyR1yI3AG+NfI9IlvfXi91BN6KxGqLihUtn5r6Fjww8TBMWAN8y+aJwK861JeJd8H 5abqEIVBC5O/qH1A9pLZ9Rpg7uaFcQKU28wUl8Cz3HswJQKcs/0jQh5D5JAXGV7eBstcS0vD D6ydnZH2CaB4LI0clSFsRY5KWXeC84j1xa0jkHDd0842AIxxcpFIAOdraz5bOUg4Glc4bi4Q 45rmqgCWIQHfO5LAHeDOqucBW0t7oLMRMEZ8SGZwz4or+/oB2Orbf/E9BGKzyKZ9DdoMy1z7 SxCD1Z+1J2DDFmQfCdwXu0R5EKuMT41sYHyvV3SPBzW/EqxGgCe7p5aeE2zLtKpafVC/tVpt JsiP5HfqaqCg8VpvDAmDYrWoF0A144C7L7gP6ZXlDbA/973kHw/aU9v3vi3BUteiaVtAK6He td4Elpjr9EAQi+Vmz/eg/UoGS2twHNPKmoXB1sR+QVwD513nU7UUqPEy3Jsb5GDrKdUET033 JiM3pDiNPNIP7KOc9/zyQ8oFbzviwLuG75Wj4L6gb9F9wNZSza92APW++rPlQ5ALlIlyKzhS HAftTUH8JOur1UEvJcO89SDgsCOrJStoDdXO1kygrzJ7MBLEA1FRMUDOsqSIj8H7SF9GMFh+ tMzQEsGsYVaSv4Ay3nHRchy8Hb3rXSVBbaaNVlUQ1eUymQPMZuYKIwREZuWNKkHJzQ6tMPhk J0YaICow2mwO1gV8o/wCnmB9sXkX3NfN74wwsD1R7slvwTnSmt1a4b+C5MN3D9TUt0MsH7h8 4PKB0F/tr/ZX09YvXbZ02dJlUHV71e1Vt8PJ2Sdnn5wNW69uvbr1KmS4neF2httw5syZM2fO /E3HpSlNaeASl7gElmuWa5ZrEBUVFRUVBff73u97vy+wnOUs/335Ut9q8UeJ4D9L1qZZm2b9 m4qVdYp1inVK2u9cuXLlypUr7fetqFtRt6Jgbom5JeaWgKTuSd2TuoN/Ff8q/lUg0h3pjnRD kVlFZhWZ9efl+rP6+bNcuXLlypUrb2/Hd9Vn9RPVT1Q/kdbdzK4zu87sCoHzA+cHzofIHJE5 InNAdWt1a3Xru49zx8sdL3e8hA50oAOwOXRz6OZQKH2h9IXSb1FJTOVt4+XvSfXnt+0naUHS gqQFsMdvj98eP2hJS1oC+1rta7WvFTCJSUz699n/fes16/is47OOh8ktJreY3CItnl6MfTH2 xVg4M+LMiDMjgH3sY9+f94e39de3pfrt6rer3/73+Xc6/7N458TZedc/T8gsyNrdv1CuQlCq YqaPcteFoEsBB7x+cNb8bcvjJLg4KrL1rTOgb8pUy7kBgg3PKE8AFFnnmeuIh7pbG42edQSK BeXvWTkAXIvFWGc/EEPFN9Z+ICPFAr0eoMiNJIP8QJRlGIgOcqjSFdQQZZpaEvQ42VxJAkdr 2yzfjhD36NXx2Ofw28Wr2U/HQqFBpWdXeA1qBu2ZbSXIfSDuQdad2RtmWwk+QfZl9uOgZEnp 75oJTDUOKPFgibBksM0Ba4J9o2M9GEUsI9SPQS9PhLgEPlbfuf7jQN/tDffUB2OwPsBbABzZ nOEBa8A7VI/kB1CqaS/U7qBWsETSC5RPzeliHogCym5lFxhxxlW9Mnj2uSulPAD1iXJb2wny ogyQm4BYrbXiD3K3mCg/Bu86T0RyY+CGEq2cBWOW+4KnA8iy8jdRC4RqDfUdDc6XzsEWf2Al 3xo5wFzsGWcsBs8102M8Am8Txcd9DYxT+ivjFsirehU5A8ww+phPwBJpMTUDrD0pIFpA4oiE CUmPwShphDMFLJ+pB2Rz0E1umQb4Pg2YHPAKXOHewUo0yATF0EdCpjyBCwJug5/H1lMpAJYt 2iqlKIhQUUypAd6Lnpn6x6COIKPyEYjV6nlFQlIFzxp9IFhGKI/NNaAMUsuq08AoJjuYl8H7 m2eCewhQji1qAfCO8ZzSdTCzeD91NwHbBNtMrQUIu/mEjaC8pJlcAsZ6va3+GGwFrN9oAaC2 FiMsY0GvbswzD4D8Vswwe4N4LDsbGqhX1NvaQpBH1XVKELh2Ju12VQfjnuIvW4NxQnshboI2 0Bqr7gXmvZ9ATX1IZcroKaOnjIZmd5rdaXYnbX2R7UW2F9me9rDSnpJ7Su4pCb179+7duzcE Pgh8EPgASpulzdImFD5e+Hjh4zBzwcwFMxfAYAYzGOhSuEvhLoWh17xe83rNgxpf1Pji/2vv PeOkKra+7WuHzt2T8xCGLDlIMpAki+QkAgqSRQFBUQEFJAcVREABBQRFEAmi5IySc85xGJic OvcO7wefeccHD/fRA+f2PPfd15f6Ve3atdbeu6vnP6tX1W4w4uF+FYzT/XD3w90Pw7d8y7c8 fn4Y9cOoH0YBoxjFqD8eL9hO6uKsi7MuziqMSPn7+/v7+0MdtY5aR4X3ir9X/L3i/7off/X+ PCoFi67+6nN81PvZrWy3st3KQkaPjB4ZPeDH+B/jf4wH36++X32/Fm73N2rMqDGjxgDf8z3f /+vXeb3p9abXm0LLOy3vtLwDEUkRSRFJMPXK1CtTr/z18f7qfCngwc/zvMh5kfP+wjjOp51P O58uzLX9ttO3nb7tBE2aNGnSpAlItaXaUu3/vuf/uO/ruHHjxo0bBxOmTpg6YSp413rXeteC ZZllmWUZjEgckTgi8a+P+8/4Z5/Xv8p/9+c7yP8shN/+c9X1OnXq1KlT568P8GxS/9HF+kLd 74ufrLkN3tnb/cZraXA68crrZ+bBkvI/d10+AMQL9rdNTeDeT+kLktPg5Ya1nm6wETrmtS7z 4S/g+zbQzTwHxDW2w6ZNYPjKdsMeC8JgbbDuA9Wr/+h8C8TtwtuWSaC/ICyVo0E8zovKVmCv liJdA3KMxeWbkNspfeDtKMjanHosszuobyovZRaHxJGlmlZxgHW1pUnURpA2mcZKfeFa9QNv 7HDCBN+E6vOmwuU37qekzQDjAVPJkBMQtjChZ7GK4Gye/dP9V8A3V52ttwSDwXYqpAcIDnVL 4Edgomb1FwPhU8aIK0FsIVU3zAPtsJgh54C1Z3iruDug7vM84+4LeWOzi6UeBD1aLRXYBIbT 8jK5GBh+MYXYkkHbxdPiOVAVX3ruMdAWGCpZT4E8RFwrlQDdoDXXvwLpsDzXMAj4nHeEo6CZ 9ARtD8hfG5dbNBB/0OOUS+Ar4y6aVw0Cuf7+3kkgz5d2mHuB8IRUXrCDUE0cpd0BeaOUbwsB +WXjBmMp0KO1aoFxIMzSxmq3wfueb7R3IWipelnVCso1/wl/Q7BftfYx7QUTtkuhgHJabSRl guVryy6jCcKGWiMNPUBYGIj3NwDjd4Yr0jtgeFFqJlQHczHDVbERSD1EJ+Hgrxp4Qu8H7nTv Kk8+yCd1s/o+KMXUMJ8E/vDA9kAdMFyUjxosoHbTBtEc6CKsYwfoI1QHo4Hj4pscAp7WHcoT YBtmlyLcoJ0UnpOrgFRDvmLSwdvLO8YdB9pGZVOgGhi/MpaV/CB0FfeIdUHxC2OFL0D7WWkk 9gNCNWtgNhhvmSpLn0PUSutd+2wIrR/xhnkUvPnO+0ffP/d3T/MgQf4zKchV/as5qv+pFOQA V69WvVr1ahB2Pex62HXImpI1JWtK4W4SBbs2/Lv4n3ZfgwT5T+DQoUOHDh16DBFnUoWw8JNw vua1Acerw6znvrk+oyV4aipn7Ochf5bBq4sg7s4dmdoYXpkV3azOPmhXpfoPH3SE3LM5qa7e 4A1N63R5DyQeeNrWuAf4B6irlUUgjteTlFwQNWGhsTcIuWIDYTAIw/UsfQFo9YSp8iJgCnOU lWCyCg0NT4JvonTFkwG5XY/s2ngcXEM2zz/1BsROG9tk3F3Q71beG30V9I95StwJsdeKlU5a AUUrhW8JbwjXns/s5DwIPkNA9E4AraSuCLEg3zNes5jAfSL3uayuYFhpecKigJQsnZcWg9qZ 1kJPMLST1xjvgfqxNkJ6Cpijrg4kQ2C7637mIvDP8+7w1wLLSfMrliQQUrlnMoB2Su+htQQ9 nA+05eCfG3jKWwWED1GktSCsJ93wIyjzA2cDt4Bkvbv/RZCHiPn6KvAfCpxXwkDsJ44Uj4N4 WPxVvwliP2OU0QEhC0LPhCnAU9qzgURgi3TNPAh8Ez21fH3An+Ib5OoEWoye4DoN7hWe1Jzv wVLeOs7mBt9apao6CNSL2iR1Dlhn2S4bR4LUxhpndIDxsmGsZAX5Y9nDEjCuld7XvwNu86l6 Dpw9/A3Fd0B6XghIg8H1nb80oWDYJ+7mDgitfZEBCxiPG84aVoO/uO+7wPcQaOn/WJ0G0nua qgwD6ah0SkwA2wzr+ZASIC8Unxf7gq+n97i3E7g2eRZ754DSQRwsSeDf6S6qWsDcxfCt4WWQ PvT18zWGQCX1I88AUH0M9FQCcbY8xrQcFFlNEgaC0+4MdbcF01njD+Y+oP7gn+VPAusAS3t5 D2hhwjLzJFB/UfeLK0C+YD0knADBK6+W5/7d0zxIkCD/nezz7PPs88AZyxnLGQv0r9C/Qv8K sKLuiror6kL1mOox1WMe3U6QIEH+Ph5ZOFu+MVV3vQgh2b4XooDk5ffcgW8halvcYG08mM5p qZmnoaMz+uvax6DNltZHxnrh1m7v4DQNrJfTv3b/DJHFKi14sihoC7SlnAYhSR+n9wU1RF+Q 3REku3gozA1s4KJwEfRr+m1xHhCq/ujvBFKadantObhd+caRA1Xg7pCJH41bDaYev/6Y2h20 Er590m0QP/Emqi1AVvDL1eCOuK/tjiywzY2a4vgcyolVvKU6wv5Zt15MPQD+BF9N30sQeNZX VPkQDL3NQ8P3g7A/Z1nWK6CX9Rv9KaD/bPzVshXoo5eQ3gNlubJOfw2UDUqE6wLgE/OFTPCv y96RGgpSb8N0gwVMGy0/hVcHz6ve055lYLlkbWU9BGppta92FkzV+FSqD9Imabn8M/CGeJW9 oG1UP1DXg5amugz7QSjFTbUySC8L7yu54Nf86dooELpoNwMfQdTzITG2RPBe9Hzr+Q7yxVxr 1kagk/q0fzjoafwgrQFLY9v60DsglJG2ij1B15Vl3qXga+1b7+4PUjNDA+Pz4Khk72I5DUIp zS33BnWf9opSEpRmVFDngu+872reXdAnaOu170C+ahhvbQvCDeEn00vAeM4KfrD+bN1sAJTr 2jRxEFBDb8Is8Eb4nvF/C9oJYZ/QFwx7jDetDcDXzNfJOwg8W9zHPHch63lnu5xqYJposEmX wXBJHmUYAtn7nC39IyF8u2OC1QWOjfb9YmNQ24pdDe9B9g7nWs/3YHIJYYEICEzULMK7oB8W 4uUrIG+URkufg+mwqbc8E/zfe/t6r4FoFCI4Av4vFV9gPShuNVI5AvYGxvflKDBfMQ8JdYB0 SvxCfg6AMah/9zQPEuQ/k3W3191ed/vv9uLxMXDBwAUDF8DIWiNrjawFDawNrA2sUPGViq9U fAUmbpy4ceLGf78f/9Pua5Ag/0k8snB+sktYwyL9IOeGOCUkBsJm2lo6tkBoJVPHwHroXrFL xFsDoVKlkn27zQFtU3R+1E4Ie+Kc9+B2sGVEp5V3gOm5sIUR98AXHvgx0A+k57Xz/lYgTtGn yQtBnMdx00FQ++pz9Y9BqIzF3w6MHU3vmdeDO9qpptWDU3M+ufpREpRdeLBThh9s1Z/YWUaD sK8MdUNiwFq9/KDS+0DxBAQlH6yZRRsVXQvWY7bWJicUsUbdisqEsIb2E2E7wHnEFZ+3DVwt nD+4kyEsN7pRfE8wljDPsq4CfyO1ohoC5lHmQdZI0PcKW/XZoL7gv+a3geWAobzhBVBekd+2 lQPzE9b0QAxQRK3r/wJ8l3zHPdXB2NXwnPwxBPoHWimNQeghLZebgeF9aZiaDorEBuVbEKfq TmEvGKrKcRYf6PFSe+0o0ENv5WkPQoTQXp4MhtmmmcbXwTjOcM6YBd4+znvZGyBVvvdaShUQ exueN64D2W6obIoBk9003bgV5BHyemNX8I/2HnUPBjFVOmH8CSSX8Z4pCgwt5N5iBMizuKJc BENX81vSTaCDfsSkgW+8MsA/FjilxUpdgXbiBf118C/37vcvBvFTvU7eZYhuERZhlkG8qToY CIZpsse0BwwbjFgHgKefv2vACoGWaoXAHZDrKCNEEQythdr6dJC2GuOJB8Wn9hNXgv6x9n0g GYRRYqKxKYS/EtU/ujH4B/imqL1AP+7vpt4BVRQ3SzXBvNR0xFQWrPPNcyzxoO/Vl4q1wLTF sEjaCoaaQiUpFdTLyhV/IgSOy9mUBuGW6VfLK+Cx+vYrRcFqMpzkRYjZGP6EcRCENwvrGV4W 1ECgn1IL2P13T/EgQf5zKZJWJK1I2t/txeMj5v2Y92PehyUsYck/6lCHOvwLKZF/lf9p9zVI kP8kHlk4hyAnxi4G78jQ5vlpUORm8TqBTtBh/pN3BudC/MxSmTWjwL1PGCveBrGMZ6nrDISe Kd216hTghjjPsBUCki/W+wUYdokbTXUgUD6/zM29ID5vJbEF6ClMkPqBMIdD/neBN8U4+T54 v3S7Xbdhf/Glb329AKy9ciZESZCw4F1DKx2y+16YdqYsoF+qczcCtP3KB65PQTpoWWguAqGV E4+VsIH5kqGCuA3kKEc3y3tg7m1pbHeB4a5lniMXXG5Xj8w1YKsSXiRuGBhfMk8JGQw5He8f u1ETeEd7XqgH5kO25fZfQCuj7vB/BJrIOCEJJAuVhe2gmNVFXIfAW9p9tSzoMepAJQS4Sym9 FGAWvpJugrxe3ypkg9ZI3x/4DASvMFzzgTRL3mVJB8tS4zHxZfC+4BbdK0EcRn1lK4ir5UG2 2qC+IA6WFoCq+ce7fwX/6IDd9y5Ef1q0Q6k6YNokvWf8AiSZo34fSPU1j/IVKA39S1yrQRpk bK2GQyDdN0HdCL75ntE+I6hNxQliKIRUcWD9EvTzLGA1uFPdr3hTQa2u1fGWANszph+kOxCW 5ng9pCQoHu1N322QB+j1DDVAOi5kCAGw3jQt1L8A73O+5aIH0ufkbvV1B0sD41LtXTB3EO2c Aa/Fn+49B3q0vkvoCeZVhmjj20CWeFYcAfp1tbLxA8g8nN49bR5QRDYZp4PyjNBWehLC0hxR pg8g3GsrE7kbPAG/0XsQco+749VbIFYR5nmWgPyk+F3Ir+AZ4jnmawamvpYB8jVQyglLxNOQ dSAjkLMbwraHRNjug3mDuFnzQYmTxYUwE9jXOtY54sAV66rmvQNAx797kgcJEiRIkCBBHg+P LJzvNnL2M7aB8Mz4PmpL8KWkf3DzRfC8kHMocyzkHxdKeDqBabVU29IblKt8qn8MUr7egpnA RLWefwqIS8XuxuGg6sr+rBqgD1Z/0L8C4RPT22FxoL+IQZkOjNcuaifANM1Y1rwWDnU4uPRw Nhx77WT3zB3QM6PXvJefh5BZz2XXNEH6ij4fDWsOLsVZJLMD5ORvqLD8dXCYn7334itgulhi e9w6yKmb3chVBO6Uy+1liYfYb+JuRC+C9FZ59bxTwN0l33prJ7hfdflctcA+yNEj9A5Yp5hu 2maBnhHo4OoJakhgl34fDFEmo+NJ0L1CqDgP9LXE6XNBfVop6r8Chh7GcfJxMDitgyOGgJ6k fSSmANe0+col0PyB1a4dEBjiO+W5DPJPhpriSPBlea+5B4E+3hcv2MC/ifKmH8D6uvVwaFGw 97CVFt8BLeDZ76wMllT7WW0DuGYosrktuKZ5u7nPgaGKPMezAfTQQIwnFqTBUlftSbA7zEPN bYDpUqZlI+ReEPb5qoFDlBebJoJ/RGAAH4DX6+7qvQquwfl70ndB5I7IWOsPYG5syBQ/gMyY vHXOLyC3TPb8fB+EfRz6pj0SVFF4T2wA6lqixVfAYMnbrnQFtZm/cf51MD1pvW0YCbnVcz9Q 74C/Y2CUryYwR+zIfpBPyMsN74JyLn9M3jCQZxoqGuYDH2tL9e5gfNq60rIffFX8kd4EML1N UqAjiC8HjmuhIDfXa/nmQ0g/4wo5A6Srlg7GgRAwKMcMH4BWR3herQoGv22NuA0CS9Teej3w tlTiPRXBnGJMEQeBt1t+TM6vUHp10lG7BE+kVxpV7HvIi8puKx4D/b7weojn757eQYIECRIk SJDHySML50pXKzctdgaSx549424JjX942tNjBcRPqGmuuwwYZipj1UGrpmzhBAjfCV+KG4Ft QpZhLugGNdP/EghTxDJiJujvOA1ZeWAYrTe3HgFmiV+JrcF/3FkivwII44R5ahHQWgT6sRFu X74zTh4IjQwvNaufBlFtnypVIQVcNe5PTnkVBCFnZ95+CDtZ5GSJeDDll3ix0lHIfHJ2lyXt IV4a3aH/dcip5LQGXgbjV9aomOlQZkrJ3SXD4GbL+1F5lSF3Zm6CfRK4j+YF0r8Ey9cOW/FK YKkdMiJcAMMAbuc1g5AVjo6yDM6fPYfdfnCUt90OqQDUEPZLRUDeHV4t/BPw3xGijZ+Buk35 0hcJ3ko5uzOGgl5N76O8DMSLVyQBpJ3SeKERiFuFKDEUxDFm0TQYzBVs1+3rILSo0WJJA+tb ljXmIuDPd77lnATqfP9WzxeQ8WT+MS0OnHX9c7UtoB+R4sRq4Dgb+qm5Csi7xfe1G2DYIRXV OwE7qe03gats/kKlI6gt9RX6FdBUwWDcBlpXTdV2gamZvF1MhxLG0iUT7oPcUj+jjYSrXVL0 /G4gYRgqx4H/rNZKKwv+S/o79Ifwl0J/DQuDrA05DdzFIcOTezQ/GyxnzeO1L0G55Gyn1APd hlGPAfmYcZw8G/Qs0jCB+qM6Ux0Pxn2mw6ZQ0GZpglIfDL1Nk4zxoLRXLdozEEjTftB/BuvL 1mzTXQjsVI8JkyHjcFaLjD1gH21/23ERjEcNg40fgBQl9zVfBI/o7um6Ayi6Q5kN6ib9trAO UN0VXMkQCJP84j0wV/FfyV0GlSzFTVEBiLxvWepIhpyRqQP8VyG0fbTdkQ3/ra+nCxIkSJAg QYL8W3n0XTVGeZ+5fQ2qXyoxsWxRqEST6BcrgKZYI8V24G+V2TG7PohfmzeYokBU+EBJBnWe MECxgbGWOcf+EqjLxWf0oaC2zl3pLg2B2vo9ex+wvBAfom+A/A55G3xFIFQLuxg2CzyN/T/6 68IzJxq+V8YM8R0S1fAm4FPyDGldQVVzO+c0AWOCSycXxOYxpcxzwPBxeEjM88B12/iw8uA/ mXs/txxETYqdEfcixGy1f6yWBik5ZrAlEuxHQ44L68BYLWxMTCo4L6UXudkBPMU8reM3gtls WR2+DES76zWvA8LKGXeZF4BtrPCD0gBkq5qeKoJwTjgnVQPtLc+0/PdB/VrdLllAXKxNllqC 754wV20JyjGtuj4D9K/8q3zRIDeztLT9AkJNLUlxg+5WnnFtB7WIZ4O0GcR4YZJxO3BEKOX9 AvSiWpbrVxDqGnbYxoG6Vv3BPxBCVUs9uRhYz1mv29qD9bxhqV4PrK/L00IiQB0ZGOJ7HgKn /RPVn8FeK+SQsAQiHKZ5htcgr4e/nzgD/M95GvpXQVKJmMUmCZQ4ZaF0GXLXu0p6D0GRqJi3 rWHgftk9JVAGsoprvYUuoN72pXl6gLLSmZdxHYp+Ze2vNgDnetvukD2Qbsz7MtAJtGSlirMP OGpYRONyMNQylDUmAPtJYQRoP+rRQikIKFqsfgICHyiZ4gEQZgkHxbNgO2xpI5eC6IGhQywy mDVzoj0dlHWBZGEI6DpXfIA+SHVrHvBneXd5k0DYb9ispED+SGdU3hAQvLpbewd8dbSfVQWE mmpDZSF4Tvt7qp9CyevxJ0yjIWx04jMlEiGgezqJZcD4mq2P5VmwtYj4IeTC3z29gwQJEiRI kCCPE/FRB5Bu6g3yRHj6bHOtgwJcsc03fAl5oal97rSBvRN/7LEiHFw775xJXgPu4ZnZ2W+D Uj4/Nv8lSK91cv+RFaA+7f7cmQq5lXJeVQH1KcvZ0O9AOeLfpVhBua9eteSBsFS+LkgQusUu GbdDXEZsy5DXwVfPVcb1PoinHHNjMkAv4TykrQFxYmblzJ9B/MYw3OoFaX5In9AjIDxnO2er BPouaa8hEoRc/8fOtlDKXDyj2G4IuxfxtVYHHNusqi8fQi2hnWJCQZKNueah4J6WNS1lNKix UhXTRPAcEobY3oPz85M/yh4NeUN9EVptMP0UujfxOthNti8i2kJ2x/zhXsD3lWtm/l7IbpmV ntIK3G+7b+cuAfW0f7DrFJjfNwWkhmAtamxFezBVNVktg0C9rB8Xx4NyMfCSqwJkX8otk3wd 8p2uhc4hkHE3J14dCCntMrvklYfIRSFRtqlgKWt637AX9NPak56LIJzQXxYd4Fhg0cyvQ8hO x9CwiWCINj9pGQJitFTDsR5ySuXNEVeBs1eu1TcFlFP+ha4D4Ovhedv3Hvhe8q90RoB1i5St KRD7ccizlvmg/KCu1cPAOdX3lnsyuMPVNtphsOnGV/WKoKXxnGQHcbQarkaAoZzQVpwPUa+F GsKzQZ5tWm9tB9YU68fWbSA9y3B5OOiLhKcJgOlVUZWHgKmk4TVpPggdpUTCwJ8buK5+Cf7r vm+0yqCV8+OTwDRUjmc9mFqK7xs+BeNS6Q25JAgthGnGa+C6lveavxm4sjxNnNvAl0Nz3Q9S qHGjsQqIbSylLN9A2M2QfvadUPJoybSiJUHrKWeEboC0iXmbvDMh7pXEbpFuMJ3R+opF/+7p HSRIkCBBggR5nDxyxLmYy9qywWuQUL+EWssIeabMlakJcLnS8ZqH50HG9ejl4mD4acbec2uf hqRcU3KxxVBvbrewzgKw2zDWYAcaufZlh0NgS8769A1gcj6xrFJVyG6Xmnh4D0it9Gcs58Gw 1/ROtZngbxTYpChAP/WKPgXkk0KO4XMQqgr9pYugHEtZlH4LlD7ST5ZUMMdHlomxg1A+7lSC AYxfh6WGtAHhqlZVrw2GZNszpmaQ/YWt7oXJkDEnt+6xzfDEL09cj2gN9w/k9/YPAsczUV8X y4Os0neXX60P3i3O7vnPgfkFmznMBcIX/nz3W5DbzVdW/wG0IWlO10YI+dzYXlMh4v2Y4dFb QZ+vhWgVwDzJ2TB/LESuCJ0bVhv0ExjEN8D1mf+m5z7kH3W39n8CHoOntLcmCKlSf3Mr0O7Q XxBBrKW3UQeCS/B+k28EoQ1VWQjxPSPnOcZBaKjpNaEBuIZ6F2nbQHhP7CnsBst2YzvpOvhK BlrpfSHnRHZeVn/wl1QuMhc8nyjxzu9Av6O96ZsB9k+NM5UOELjo8wWKg2emfzYDIa5e2PDo E3Czb8byzDcgu6drvvYkBL7Wi4ufg2WGaXSgMthTja/LZYBh6jZlAjDC2EWqAvkrvBUZA7kN 3HO9djAukyKlHyHu27Dq5vEgJos7pXqgTDV3MpnAWNm/298KtIPCBt4EcYiSLJQEPVuppo8H k8skUhx8rb1TfZNBWiZMElMgp3tewLUVAlXUiXpdCMRoq5TvwLDBdNRqBe8ZX5rrGIS+Eno4 fCEolxW/9hkoY/RNCiCu1WcYfoZi0WGnxKNQ6WoZQ1JXsHxoKGMbBlIPebO9OUQkRWSGK3B8 +a+9LzWFajy9nf1/9zQPEiRIkCBBgjwOHjni/OTExvM6vg5+j9pZWQTSCYPJIgMjIr6QN0FO e/c3ebUhY4w8xVUGQsISF+qVINAo46Nr6WB8N7J85EhgpudY5hCIeiG2mOMGSHXMk41DIbJS dI0nLkDUqrjnSvUF5aTygz4UhCg26rVA/F4/x2rQrwpevgRtJ+gZoH+qlhVCgHW2Ro5NoNt8 S7RXwTDAYDFsAsmctCBsMbBRnyKuA7/ovuueDWW2F4mL+hTyp+speii4J2XNzPgcioVGbBcr gWGTY0pUczDXcESEXQff+OwmaRVASNAmGKeCeYHtC1sL8FzxdRZ+grzRelvZATkeIdo8HTyf KWOFPqBt1dpLY8Gw3bzd5gHtTW2EmgauU66brm4gnVUz/Tsh4cXwaHsoFEuOuRL+PhgD2iKf BlJAPRpIB0c18wLb12DeaFxqaAuWWYbD0i4w35MPG7rDjZZp2ZlHwW/TB6pfga2zdYqjFLjH uVp6w+DuqxmJmUshp4LrbN7H4H7BWz17KnhmuaPS64DyXaCPMx9cNz2NtTCQoqWT2kIo9kz0 N1FpcC78xsvpEZDcJDvE2xeye7gGe+aBME9X1PUQapLqi6shZp6tvtgOhLXGhlIpyLI4a0r5 4P8m8IP6HkRHhrW0rAPbIvMBgwUI6K9pGyD9bJaUVx+yZ+S+67KBt6bH6vkUvNvyffnfgXuT q0VuJ5BeZLZ3AqgGb4Z4CvRsvb3cBrLPOhf5WkHmGGcxTytIu5ZTPycXskc6R7uXQfbh3OY5 HcB4xuhhLhjLipuFXRCywva08RMIW2QPt20BQ8CQw3RI3Fc8JWo7xN+K6x4XAaFrTeG2e1D0 cukLZb6AQG33UM0E17zHzRcb/t3TO0iQIEGCBAnyOHnkiLPjRFRYQk3Q3tCXkgCibowwnIT0 13N+yH4BXNody30b1BxW/k61m1Dp66pLG40C5bhpnnwXpPraId0Cai1vnusH4IDQiebASnW5 qzRo9/N/9jwPYrmI1gl3QZoSWKVcB+0XcRVbgZLiK+jgn602870KphH+fv5boLZRjklfgp5r yrcPA2GDu588EbgP0nYwrk6sFVsB+F5JDnwK/tYZDe4Whbx+js5pWVCueQ3jk3Xh7JFzBxb4 oG7bKl+VfxnsnfRFMcvh1xXeDUV7Q87hu4MulgbPsLzXU1eApU34qxGHQRoUeMs3G7REZYA2 FrQxxsvRVSDvSf0Z9XtQ3vU1cLUAw3X1O20/uF7yHHKXAVsn6yLHcQiZJzSWDoH1I0M7w88g 7WCedgCSDsXPjBwErqM+QVkCnsn5y3KaQZHJsceiI8BZwRuq1gKxjvyRbIEiz9s/K3YLRIOO VwXPNPdl5zJw3vek5m4B71HPMo8XzFtNJ0yhwCxhr+ljsF+0rg+xgWWgHCq8CZa5UjXlSzCN M35iNcLVqXevOWeAa4GW4+sPll2Gt03XIXpTSAXTIkgZnzr0XhhEL3D0tr4I9ua2tqHV4Fzg zvj7z4HpQ1OUfRg4XjDMMJcD2aAkuAaA1kVLE/dAsil3hNIc9GR1nf8maFV5wdgZchqpQwIp oIneTsoq0J5XLri2gHOq/K2eAaJdqK73gPBAdM24dyEwUalPFsjh4n31PDjSLJ+Ip0DP1Qfq iWBcL+/SnoKQ22YLRUDdE7jl6wHm7fY94SbQV/q36B0h7KfYkvZoiLpQel+5teDJ1nRTH4hO jy8Z0wzCjQlro1PgSPyaQb/a4Mba+6/eCQE6/T0TOycnJycnB5YsWbJkyZLC9l69evXq1QvC wsLCwsL+Ht+CBAkSJEiQ/1d5ZOGsXxYS9UWg2lx18kdDlnJ/xpUYKDFVtVkqQbmJVeVn+0Ji kaqbnn4WtB9imiWWBfGG/4YvAcSreoiwEJzv32p1ajBY02O9VcqD7nQPzH8DmODun10buBfx bUJV0C+JjfRM0J8R7iGDtE9PE1aCXoukwEnwfuQLd/WGQM3rK5K3grZQ60t3yOkr2/NeAsep OysvTgfvpmM9jlUFy5NP7CxxDsyVq2mlD4J+31s7ZCI8+VaRTy0e8A1rsvH2NahYvsL7rSOh +ey6A721IPXUtCe/6wSnvnQPi/OA+5PMK3dPgNzQku54C0xTzMfCfgHfnfyfszeBe1LOkeyP wOAz2Y2tQCguzBd6gPuwniR/ApbnjK6w8uD9Rl3CXshpIS0Rm4MvMrCNnhC90fGCTQCTyVze 9gHkt3Hmuu9CIMI8ydQUQhdan7aehNhnwjvIaeBt4puijwEnefm5V0DqJdzUPwRpjr2kYQzY rptbh34M3tG+Rpb+QAflk0BVEKMNuvEaZHd2b1O+h8BCvyBMBnbKw8VKcPbjm4lp6RC4Isdp s8FhNG00lQFmK3UyysHd9umjxe5gf9LytckDpIlpHgEyTFk/mb+EsF/DpkYPhThjeIp1BOTK OTXy7oPf5S+vvwQZo3LvOD8F31r1hHoZolaE/GJuDCbR9IH+BtjeDAwQD0KGxlF5H8hxkhp+ CaL3hhw3xYKprLxYzQJ/K39dcQd4nmObWg6kbkbBoIO0WTtqqQ56Zb1h4EdQN2id9VmQv9Rd WXWA9Kppt3ER5HV17vOOAMcJ8ybDSkhYm3AsZjsI5cUD1qWgtlaryRfBfiR2a9wlCIxxLXa9 Awd9B9zHTHCy+s0mN/S/b2I3bNiwYcOGhQK6gAIhffLkyZMnT/59/gUJEiTI/xScTpfL54MZ MxYt+vVXuHz55s3s7H+fvbJlk5LCw+Htt/v2feYZsNttNpPp9/74fIEATJ26e/eFC3D5claW 1/vv9CciwmyGd99t2LB8ebDbTSaDofC416tpmgZ79mRm5uVBbq6iKMq/z5/QUFmWZWjQIDIy JATMZlEUHzm/opBH31Vjm2uDaw14892XchaDrVbYqtihULRJq6J1KoI2hXP6YQiUVd5WU0Gf 71W9t4C+YpjeGlRj4C2XEczh4a9G1gK5ZtGF5SuCNMNeL6QR6NtskeFjQNNUu/AO6D2E72kJ wjzOCzGgVaAr34NpreBwzAC1ns0Wvh7CN9eullAbTh2528jrh+O1Yz67dAm6jpayboXD/U3l 9bsfQcLVEu8UCwfb26Ze8a+CVMY8J+xjkNBb+ydA0zea+EdVBP1TPZs+ILyXcIS3oWPNZnEX 28HNgWtan/4GciJcB3PKg/ODrEb3MiFMjC1b9AMwlbFFhiwGT4/849m7IDDL00w7BEJrcR87 QPjVMFu0g3grMNHyNSihchXjR+DeZu4rx4O00veppwf48tSX+QbyF7ra5n4E5lOqI+85yB6S cef+j8B889fh/YFZgVbKBhBHyIvUqWBeaVllWg/CMDrIJ0DPD4R6T0NIT9MdqS5oRslhawlK uphhjgd3lHuMUg1cHTwGzzPAKm2Qtw+IzwtHrFsgLDfilt0Arifytuc4wHPf/VXuRog3RRui 3oXM3IxqV3pASKewxUnVIPRLx+jYdyD7rq+r/xz4c3LeUs9CxtverJSZYN5q+cr0NWSdyP/V exs87b2xviQokhU/N+IMGPYbalrnAC+pHb3REH4i9FlzI1DH+5vn9YfUGFe4qzNkasI38gDQ PyJN+wi0npSiCZi+NbiMiaAeFJ7Tj0DgZ+0jbR74xgfmaL+A8qTyuqc7SJW0T4WaoA+hlUcE xxprknwSSlQs5iyjQUS/qIuRtcDwkf8VLR3Cf4p2Ru8E021xiRgKBw6uXX1sGfxy+qLz8seQ Fq8YtCv/vi+Gh7F79+7du3fDqVOnTp06BTdu3Lhx40bh8RIlSpQoUaKwX4HADhIkSJAg/xpT p37xxZ49kJmZlxcIQJkypUpFRYEgCIIgPD47uq7rug5paRkZTmeh3YkThw9v1qyw38SJ27ad PQsej6YJAjz9dLFiERG/+fM4r/s3b+DGjcxMp7PQ7tSpL7xQvXphvx07MjJycsBqlSRJgmrV QkPtdni83oD+f4JVd+96PD5fod1WrWJiIiIen51HFs7ucs7i2U+B8YJxgXkuSLkhE8P3gcfp beMpBkIx7baQCuoKeSvjQHhCbKGPBimOEMNG0Lep77hfAuPzxb+veA6MR2zbHddArc1PXAdi GCQWBYNJ7+l/CgLPCj42Agf1xmIu6F7hsH4HaE0dNQzEm/49hmJgLd/wjVpvQP7ZrKQt2ZBT JnmXvwPkNWWXezeo00sdKVoVfm17+dzeDGi2N+RkuZfAG5Z21HwU7n9825KpgLGuYUnWcMju krL4/gnIXnR/wJUUONX31ovJUWD9wNEo5Bdwv8BX5dqDd+jNA8c2Qf7I7L3prSHkVmREzCYw 1reY/XUg4PQVz30ZpH5ie2Eo2HtaI0JaATMMFuMwMD4nJ4uTIDRXXKCdA0MJ423HIbh7I2+i Hgu+jq7vfC9B1il9gCEPlHrGnCgdiswLKWn8CDLHZS12DwdpAbf0HMhzuX/WLeArpdb3mUEu IS8R0sFbXiulPQdyCzEk9024Osoh3AAAO3dJREFUp+Wcc+0BSTTWcFQEYy2Dz9gQTJMNlRwv gvU4N7z7wHff83lWKqgnma5bwTTEvE0LAeW4+p5WBYo8F1up7DQIrxcRazsDnhddF+R5kJeS fdHTAVw9tHH+TuCoYT9nOQ7exoFkrQx4e6pb6QCxb8QsjDoN1nnW1pYicNdxb3y2GwKDAv09 x4Cj+uzACsgxeNf6XSB8Lr9ibQiBxdpt6oJ5juUL4zdgPCBnS8dBGa2Fix1BMQbue4uBbaZh uLAaLF/KDrk0yD9KK8KvQO5G/+lAJ7BPMW4W20G5oUXrxaZCsf7FphW7D4aVwl3pTYiNiBwa fg2iwiO/jOoCl978Neny97CuzaZSu0Mh+a6vrCsX5I7iNvtb/2eSbH28Xw7/FdWqVatWrVph fdasWbNmzfrn/YIECRIkyL/GuXNXrmRlQXx8YmJYGNy8ee9eXt6/z57dbrEYDIV2H+TMmZSU 3FwoXTouLiwMDhy4fTsj49/nT1yczWY2F9p9kPR0v19RoGRJu91ggAsXPB7Pv/EFYeHhkiTL kJ7+m4B+3DyycE5546rx+ivgs6beyZoI1W50XtsxA/wRvrKBV0A/KZv5DqSz2gmOgtBcGCAs AD1BPMU7oF/Uz/kagVhSjJI/A+1n4Y6cCFzV+gSagPCSsEhwQ2Cy8Lo4FcSL2l2xARArnFR0 EIbp+8UjoIXgkK3AV8JXgTKglne/rHwNZUYkvFHlE7ilej17J0BGuHwgfyckmrSrjvaQ8oL6 rfwZZNW83+vebvjE8fb1T5bCTVOaIfABRI4xTcmbBfpBZY5zJGTGuBZ5XgXP5/b1xatDfPei PyUlAPNCng/dDOl3o3KLHQLvgfROybHgPWN8zrwHHCGhb4fcBuEWn+tJYM4WFwQkCAsYdPUq 6O+pV51OCO1sfFksBeZdUlggCq62Sn455yT42mt51nqg7qef5AK9IzW1YSD/JHTWz0Jqam6I fzfYGjvKm9uAPEiuaukP3hqeTM/7EJop91YlEAO8IlwHY1m5i+00mMPM4eYYMM63b/FkgFCE ltwAcZuQLDwBalHtw8D3YFsmp0vXwPyysVTUDPA+7euYWxWEtrQwHgZfTuAJZS74tjufzc+B QFPTWqsbXEb3zNxJoC8Q3lYmQHFveC+hBhhdQqQ0HrLNngXaPYjpErrDkg+hJ03p2gnIScpf nN8D3Kr2me4G4kg3fAJaNr1pCuaLtsrWHLC8YnjacBTUpvoRtSuoMeo2oTOoffQj4g2Q10p6 oDaY+prry34IXx8629EBvMu9SfJlcH/kq+WrBLYjBrs0CYpvjj0beh5ijcWWF38T9KLCR5YA 2A+KXY2nIOmDUpbEluAKZN90T4fNL/y8Yd8NuNMl99aNOmApzsfeOFBm6whRwLP/vi+Hf0RB 7vLixYsXL14MvXv37t27d+HxgvZgjnOQIEGCPB4URdNUFXJzf0vZePTxAgGvF7xel+v3qXZ2 e1hYXFyhnQK7D+L3+/2BANy+nZPjdBa2p6aeOnXgQGE9NrZq1aeeenR/C+wU2P3j9aiqrkNG hqL8o+M7dmzZcvQo7Nt34MCNG1Cv3lNPlSgBjRs3b16z5l/3p8BOgd3HzSNnfWT71UYZ4yEj QNu8NiB/JyjSdRC66ru0aKAEqzgGwiRhlbAFSNf3CodB+EhYJlQHf5GrIb+YQNmZnZezG8Qb crIcAC1S6Ca+CfpWPEIZEG4Ln9EDGCVU1a4BHRgiVARdpJJeDYSxQnOhGIjLiWY6+BThXX0d FB1f+vOGF6FpYq0ZHVuC/VlzufiacHlzhny+DJjNlpOh2bAv+eDTB8rDzYsW8523wW+11vTs AHuLsp+XPgXVqr3w/vM5UKpRtTJ1B8HQ0v1rdekC9RwV9JgJEPs+q/LmgXVBTNMiK0D2h/0U 2R48e3OeSy0F7p7u5t73wdjYXj2kPWiZuigfA09PzyzPZDA+Kd8J5IMX7yfuH+F8/I3X738H yZb07zJugTfbM8pVCqR7RovxZzD7rK/augCnBK/UF6RzBo9xLyj9tQzDbsjr56ritYJpsfkF 4yIIs4TUtn4NURVDqoc0A/NxMUI5BAwK+Jy9IeSO+SxPQ/xXEZ+EJUPMDZvfXhcSP7J1dywF oyA2s+eAf4syyx8G+d/mPpufCCmH7n+ePBVUh9orMBPyQ5Qw78tw/Wjm5JOLQK4n3PLOAnbp l3JPg/tX/zJ/Kbh3JPNGphUMn0mR/p1gf8JaQnoLUowZxZ3zwTnZc9u/A3wVvdW834Nnjm9z wAnKfVYJC0Aqxae6DMYY4055LNjL26NNzcFWzrzS9gHINYyZogiBTvpeMRMyP8rL0u7Albk3 e6UnQMbG7KTMK6DsUL73/ATRX0e9aF0G8XuKP5NwHcTv5CGmluDd4a+sfQiOhnHPx3aGvHHO NOFV2HJv85EjUXD4lytfXegE6Xvz9qR1AGfdrE73W4N/hGf6/R8e/4T9sxQsAvyz7Y9KzZo1 a9as+c/LLju67Oiy4++7L4+bjpM7Tu44ufD6HnZfCvr9p7DCscKxwvHnn1tBeXnE5RGXR/zd 3hcyOXNy5uRM+KL/F/2/6P/Xz8/vlt8tvxs8ZXzK+JSx8DrvtLzT8k7Lv/vq/nM/P0H+b1RV UVQVVFVVNe1fL30+r9fthsmThwxp3BjWr58/f8CAwvKP5/1m90H8fp/P7we/PxBQlMJy//6P Pnr77cLyweOPXv5m90ECAU0D0LTfZOyD5YEDp05lZoLZHBmZmFhYf1j/P1sW2H3cPHLEWa5T 2hozHcwZ4SvDZ4O+gycZA3pjuvEaCDu1WH8CqN/qt/W3QGgrvmVYDeJzQmkpEcSDQnfDcpB2 2mNiloL6rv4D8SB6eFIpD0JTnpPMoB/Qx9AQ9AYY6QVEIwjNQegiPKW/AbTVa+unQc9gtdgD xJ9EzXIAlINyscBsKKoV1RvcAnG1jHQZMjPFUZdvwXVnatr1H+Fi+vUzntpQbmXjlGdegLMf /9jpRH8IG1i8gyMFykeXWVppM7x4rNuNXhXButVWzPQ87Oq8s/R3xaDxnpjb+WMg5MTxXG0j nK3of6PUHciaoB1WJoFvUUaRlAVg7C3NKFoW5BH2J8OjwPexf2beBMjx5a3ImwnusoGZQkfI Pui9q2eB6ZjhE0MTMHwrrAtUALGHctQtQCDM65KTwTzV8pPpeQhM97/is0LOobyXss+BrYhl rmUMKM9oFssZcF7yFpEmgLGUXNx4EvxGfa52BJTzgaGey2CbbJht2waedvmrA1PB/5WvddY1 cH2o3LxshNRTafszVoD0s9yYS2BYJkyzjAbveq8odQZ9lRRtDgO+FKvkB8Dl93fOOgliLWbY f4G8cvnD8qLh7P0b77uSoOTB+FFRKsScse53JELKc2lP5e8Hb1ey/GPBUotR8howl5FTyYaw b0IrmxeB8I0w33QMlL3iRWkpyHsN66X3QY0L3BV/htzw/HeyM4GaREltwDrYesxaEWLmhbTX W4Ca6+9pWgWG9uYuxiegyNTwtWF7IeJmMSluAcibLHUc10Ct6R3MSIj+Kt4SeR5k1dY7TIcD L/3yy6XqsDfxaOtTL0J6AzYEfgLtc+OsKBm8T9Pt7icgtJeaShWBe/+OaftwCnKW9+zZs2fP nj8eL8i5a9CgQYMGDQpznR8Xkc0im0U2g9dff/3111//43HHZcdlx+X/3nvydzL2x7E/jv0R 7Ha73W7/u70ppG7dunXr1oWxS8cuHbu0sH18m/Ftxrd5+HOM+ybum7hv/m7vC1nTfE3zNc2h eIfiHYp3gAEMYMBfOH/79u3bt2+HQJVAlUCVwvYtHbd03NIR+tKXvn/3RQb5j0dRCoRsgWT7 15g69c03mzaFUqWKFYuK+uPxB8cvsPsgfr/HEwiA32+1/leL8Pz+31IoFMXjcbkK22XZYrHZ QNdVVVEgEHC58vN/a7daQRQNht8vRnzQ7oMEAr8tDlTVwjzk3yPLFovD8cf6w/r/WQrsPm4e WThnWe8mJPeCuOHhW8tMAOETNV7PAgbzOhbAp+dKF0BcJz4nzAECfCLFgPaZ1kLrA1KLosPL LgbxgHVw9F4QItTBvr2grddvyKeBkeJoFoNg0dfrw0BPIRQzCCVwUROoqX8kGEC/QgndBtzT jfoPoDfnnNYXpA5yHSkBlGfUz5RfQLpvmGrdCU/sji3VoDtE5Oo/h5yEqECJw+btsPr04qzN cVCqXcXTES6onlvtkKkhJIfcjT1XCRLqpR3TtkPkm/bS9g5QplrYCsubILTVWiS8ACkL5ZRL n8C9BPuG0OdAr0VY2e/BufTeN+dkyLNn/pzsg/DpkYsS14M+yzrL4YWcKoFuWnVQR3odaSfB 0EIeKn4HMWsjike9CIYOpKhjIXV/VoM7FSC0RmiFiGdBK+o7KR2E0KgQPWwW2HdYbks7wPmL +xf3cPC39B7J3wPCZUMnYyyQrvf03QdXjueOZzpYRptekveBOkyZ6HWB+44331UEvHmBFpke 0DYZd/h6gLze0Mo+DdzD3E/nPAtirnmu1Aasi817OAlyA+E9/TSI6GNsT0FceHR0lSOQP9n1 fM5VKHInsnHsdZC+Epel94WEzaFRIZMgq1zmEs9KuPtVJjk/Q6lX4p+0b4JArJAfqAXiRPNM y0RQ5tKFj8Eez1TFC6Zl4in9IhicYju5KmTuymua8Q1EJ9jjDVMh7mLUezE/gfkd89fyMUh5 JrO7uzzcHJva/N5QKPtS6WVFzoFjU5F3o0uCYaGxi+0keNrnXwv0gqh6MUkxeyFkWczcqIZw 451zre764PAbJzJOVoP7F/Wq+hFQR8ifRl0DZvijUw6CcZ51hnwTTG0tSfEvPv4J+88oiCgX COjx48ePHz++8PjYsWPHjh0LSUlJSUlJj99+gUBsndA6oXXCP+iQQAIJoM3X5mvz4cs6X9b5 sg6sW7du3bp1kJGRkZGRAVFRUVFRUdCuXbt27dpBn0N9DvU5BOIgcZA4qDASVyCYfhj1w6gf RhVG5m6tubXm1ho4evTo0aNHC80XnBcXFxcXFweWZZZllmXgLOcs5ywHwy8Ovzj8IjSNaBrR NAKUKkoVpQpMz52eOz0XNhbdWHRjUShdunTp0qXB097T3tMeWMMa1vzxcgtyzIumFU0rmgaN ljRa0mjJ4/OjulZdq67B7Ra3W9xuAXd/vPvj3R//eN0PUmJbiW0ltkEJSlDid+3jGc/4/+o5 vs3bvF3of7FJxSYVmwR1vqzzZZ0vIatTVqesTrBj+o7pO6b/+edzbdW1VddWwbRS00pNKwVn z549e/ZsodlyL5V7qdxLMPTc0HNDz8Gc/XP2z/ndi4UKxhuWNixtWNrDc/sfZGPaxrSNaVDu k3KflPsEjEuMS4xLfieca/St0bcGcJzjHH/0z9Gnvk99n/pgU/qm9E3p4HQ6nU4n1Pi8xuc1 Pofx48aPGz8Oom5H3Y66XWjPt9+337cfuk7vOr3rdMibmTczbyYMOTvk7JCz0DKmZUzLmMc3 rx72XKd1mdZlWpfH/73x/zqK8pvAVJRHE2qlS//fgrl9++HDV6/+53YfxO/3+Qoiwb+PSFeu PHDgxImF9YiIChVq1YK4OK/39znQN25kZ2dmgsHgdufkQM2aZcoULQoXL965c+MG5OVZrVFR YDQ6HOHhf7T7IIHAb4L/Yf9WyLLZbDb/sX3atKlTN2x4+PXXqVOzZpEiUL9+48a/X4z4oN3H zSOnahjy/aGB2xBe1bQ0ZCQEkqgsvAF6feFD4VkQlokrDBuApwSvlAmsEHZjAnoqs93jQBua 2yJtDFBBuy2eBlrzjrAMhMZiP90NyDTT5wAiWUQDBsGMBKSSzy3Qn6eDngxCNaGq7gC+43nl W9AFbYhfAr03M4w9QJovhErNQe2tnPOchPAkh7X8VShfpeTYVjPAe1v+3tAYzGKZ1ra+0MPx 4sQ2zcDRxDMyoj/4794fmrsfnMK5Q6nJEDLPcDtsJxRfGhmI6wr6QLmfVARChxVdYeoLkcNt lfPsEDna/qWUDOaBcTvLbQPjfsN4ywpwN8hy3JVAbe+54HNCyIyQZ0ObgqNlzOkiFyC2VtT1 mFSIjYuKiZ4Ikd7Q0GgdSvctGl76LET8ZDsTshei9jl6GiqCaYc+3P0JSI29b2dtgqSUyAHy HgjtZiijTAObTfrMuxEMayjvTATrV8ZS5obg7e+xB5Ig+9tMNe0z8Ox37/BpgFlLcHwDpjjt aGUNwk6a+pYMAWsjw01LX+CuajcvBMce097i+ZDdzBVIHwb+F/XpFIWsRqndXAoY3tZfDWkC 7pXe5PzGUCo15mjx+WD7QE4L3wuuZr453qMQuzwi0XoD7LtNi0w7IL5cRLvwOEhsEFbU+hl4 m+efDdjBscGiiqPA2EL/WEmCjMr3X73dF/w/+jenDoDcRM+yjE5wZWVa+VM94GLCnfDkpZB7 IO+suzhUOFbhbJEEKNGptFDiOzAdMPUKVcBVzL1T+x6sxxyVwppCGDHvReXCveu3vs0qBUef PJZ96jbcKJm/z30YvPV1j9gXPGM9G3JfB+dnzrtpiWDIstyLWgbuqfpG8+ePb6IWbB83bty4 cePGPbxfgXB+WL8CIX3z5s2bN28+fJyC8//qtnUFAuZhP/VvKrqp6KaisOzCsgvLLhT+xF52 d9ndZXfDjNwZuTNyC+sFx78Z/s3wb4Y/vvuZOiF1QuoE6DSl05ROUyBnR86OnB0wY9eMXTN2 FfZb+uzSZ5c+C2ui10SviYZmN5rdaHaj8Kf9tAlpE9ImPNxO7s7cnbk7Ib9sftn8sv+6H8uW L1u+bHmhH81HNR/VfBSUnVl2ZtmZhYL5v5vk5OTk5ORC4f7s0GeHPjv0r48zZeuUrVO2wvEB xwccHwATN07cOHEjTOs8rfO0zpAcmxybHFsYEZ80cdLESb8TAPEb4jfEb4D3mr3X7L1m/9ze /YT7CfcT4EStE7VO1CoUuE3Dm4Y3DYcbTW80vdEUrl69evXq1YeP82ef31eGrwxfGeBbx7eO bx3QyNHI0cgBk4tPLj65OFy8ePHixYswu9LsSrMrPdxOuwntJrSb8F98Th7TvHpcz/V/C/9q qkZeXlbWvXuF5YM8ePzPpmoEAj6fz/ebcP4t8vxbeebM55+PGVNYFrSvXDlqVJ8+hWWvXnXr likDmzdPnPjaazB79sCBnTvDli2TJr3+OtSuHRtrsfxx/AK7D+L3/5ZrrKq/7cPxYClJJpPZ /MfSZktMLF364eXJk1ev+nwPH7fA7uPmkYWzcZE5w/gEhPcJPRARA9qb+kTFDUK+ECKkAmmY 9IbAdr2ysAyED8RPpIkgfOybkTsb1Et5dfJCQPxcmG/eC2o/IUNfBUJt/WtmAZX0kUIE6G5K IAASAoCeRwZeEOYyV2gA+jdIwjzQs9TpHgnETp4rnl5AL7fPuw4wMUdLAaG6UIUsEOtJbzEN 7q/Mqp5+D8Td1566mg5jLd1WDX0TqhyrUL/1VahWr86LrdpBq6yXmnbqB4ZxFT5KDIefVu5s tWM1bG+3N+v0JjCeCszV8qBiY0d4eAOId+gJnveglN8UnfsklH865rKxLYQkxfUtI4C017LP 0R18m7NeTTsD/mHOi67eYEyWLaFlQX/eZIo8A2kb8gZoVeBuldwZvkaQuc1ZRm0LqdszD7pF SP8ye5DrS7jXImNLzrdgPm6uJjlBuO1P04aB3IUp6lCIyra+IlSG6O+sn5trgOOcbFPLgPWM 6Q1jPPhjlNepD96h6o3cVMgVA3tORELaazk1z52BrB2BnpeGg7OW72t3LEh32GGQwd06EOL5 AgiX+hvugbunz5hTEfK3B/YnL4T0fjnHbs6EjA9zvvbcg4y1TmPae2B4Iey6oy+ECI7sqC3g aGf6GjuEGUIOGyuA8LIyzTQO8i/kJ3ieBeMJ6YziAZ4S7bQDtbtot60FbY65qW8QCO1t/XOS IfdSoHh6Z7hc/17otThIj/ScuXcRiows1TlsJhQ7XKx16T4gKEK8tT+4i+UXD6SDJdYxKOQ1 CF0dcyemMqR/mhyatw/OxB75+pQAN1/MPZgbBmpdw3DDKaCz5hO6AKuFJkJtkF4ITy0aB8oG OTReACFLHC78iT/gf5aC/ZgLhG9BxOjBfZr/GQWpGQ/mOheMUzBugZ2/On6BgFm9evXq1av/ WNa7UO9CvQuwfdr2adunFZ43ZsyYMWPGQP1v6n9T/xsYvWb0mtG/i+A+2P9RKdK2SNsibQsj eAWRw6wpWVOyphT229N9T/c93QvrQ5cNXTZ0GQw4OuDogKMQfj38evj1f78fD6bUDDEPMQ8x w+uLX1/8+mIIeTvk7ZC3H9/9+bOEPhf6XOhzMMc3xzfHB63vtb7X+l9ITyq47gJmzJwxc8ZM 2Ja9LXtbNgwxDTENMcEy8zLzMjPEpcSlxKUU9jcuNi42LobY52Ofj33+n9vbPHnz5M2/yxlu 0qRJkyZNoPE7jd9p/E5h+5ZOWzpt+S9eYvRnn9++X/b9su+XwnpBCkyjK42uNLoCi04sOrHo BPTo0aNHjx5/tJM4PnF84njolt8tv1t+oZ28GXkz8mYU9ntc8+pxPdf/LTyYqvFnyx07lix5 443C8kEePP7g+Q9P1fhtH+eCiPODkefCfv+4vV27p5+uXh0cDovlH0WCu3evV69q1T+OX2D3 QQojzr/VHywLIs5/tXzhhUaNKlZ8+Lj/rojzI6dqFJ8T2bvY52C4aT5qdYC2Qs/WyoEQzw39 NuhWvauwGcQEpioNgBHCfOt34HsqZ1bedfAf90ihh8FoMPSQeoDYWb0cWAqs1cPkjcBysafu BeETfR75oO/XL/ArCP2ELiwDNVJvoyWA1FUrKVwF34D8t30CCCkep/cuCLpc1rQApFamddoa EJ6VRbkF6Iu0I+ooMGzwrvTEQsPQJ33tq0P4ddutUgngC/dneweAvVv0sOIjwGEUGpRoCFHe JLfyE0R4It4MewL29NkzbPsEWJV66UBmRYiZ7qmnX4BSF8Im2dqCMV7c7Y2CIl3DRLUJrH1C q0QeHLMZ6pQaCNrurL531kFgQt769L3A22pPvSdYqoU0Dj8A2iJ5nTAH/M/5u2tbwH0/b2R6 DgQifSH57cBe3dxSGgyRvWyqeRPYzxoOWMuC5xO9sR4GUXXDFxumQMSAsMSwXEj7KuN7z1Kw DZY/c60B00Y5U9oHacWyhNQdkPBuZN+4bpC+wzc0eiikf+mrf2UA2COt9R2jQR8vvWdWIX2N W7u1DoTFebHyCQg5bvkutihIP1l/dG8AWwVH69D5IHZTfoj4FIy/ineMyaBNI8n1E9yqf3di RlnwvepNd66Goo1jFttLws29aVX0l8CdoKxK7w9FcsJbyn0gMFf53HwI3C08zwXCIfu+u782 EyLL2L8tcg5crwYGUgps0aYFxlFQomPMtnInoMjtoh+XPARhr4cPj18C/laBKVJDcNfyV/CF Quix8A4RseC4HF0xoiNkP5W+xbkUbp4+FXt+PdxxZL+ZOgC06cbI0KHAfPUV4S3QurLedxbE CqbGYSYQpmlHAhGgPe2rkH0ApPsB3RUDlHw8E/XB1Ir169evX7++MCL8Z/djLshtfpCCcQrG fZjdf0aBgEkalTQqadR/0dGDh99tRyQcE44Jx4BmNKMZCMeF48LvfhrX+mn9tH5/HObBdvWw elg9/M/9FAeKA8WBv6svFBeKC//YT++n99P7AVasWH/nZwHHOMYxoDOd6fzn79Nf9SNQNVA1 ULWwLg2UBkoDQbALdsEO0ihplDTqn9t73ISsCFkRsgLEUeIo8R/Y/7PP58PEDxM/TIR2n7f7 vN3ncPiFwy8cfgEO9TnU51Af2Ji4MXFjIiybtmzasmmwilWs+lccrkENasDGGRtnbPyd4Cz4 h/FBClI2BtcYXGPwP0jZ+LPPryCF4g/9/k/qyz9Dqi3Vlmr/czsP8q/Oq3/2XIP83xSmavxj Ifs47fx+/IelagQCXu/vFwc+jIcdX7780KHLl2HZsiNHbtyADz5o2bJqVejcuWbN0qWhdu1y 5ZKSfjv/2LE/2v2jnf874vwgD0vVGD++U6fixR/u/507eXn5+eB2/+Nx/2MjzuajrnpyEzBU pbtUFECfx23gulBJuAqiT35Nvg0qwhR9LTBMOKQfAfV970zpIviaSTVjZ4M4SFqIApTRzrIA 9KHCe9wAzusr9EjQ0/EQAezByXnQu+p1+AIM/aWD8ndgaGqcaawC0iFHYkxdSF7vm2gsCpcW Z47S50PODF8xYQhIP4qtaQPKRmWXfyeEFIkvXvYHCLVHJxXtCN4fFK/7Pgifiu0YCMpbaqZ3 KQSeCSzxDgftpPdNdT4k9I6rUP0wtFtTW3q6ItT/tHKFiDwIG1KijqEuKGuMA3wfQQlL9M6I GCgXVfaZkBNQTbeG5tSAJ0YaJa0FhCnRIcWXgURY42ItQW3ku5FTF1zxOUdSJgKXtBpMhdAT ob9EjoLYMYm+pFxIvFv09RJDINRnqxRRCoTrhplyeQjdH70gIgAOk2Wq6WtI3ZvWLucqnNl+ sWzaBMjd7A3xLwdbb3uLiGywf2GTbG2has+krcUXQ5keEXHFosBgp43vSyiWH3WoxM9QflBY dr13oOgle8OiX4PtqsViqQelE0qcr9wCImxhvSKPQ8TEUFPcJJCnSlJEOfB0VY95FFCG6/bc PWASzTPM3SB8rf1FwiDho7iNIftAFXFZq0HUm1E/O76FJ8+ULZNwFkLDbR+F9gNpihAptwBb qCXZ0hOsblsvoxXEZqa25sMQezssPukLKNO1eEZZGcofqPBMzaZgTw75PvEXyO3mmqLnQ84Q r0m5D9Y6kTmRNcE0PnJOZB7k6nf75laBW2ePvXTiBKQeyOpz/TCoEeaqllTQX5GijedBU/RV eisQSgifUQS4r2731gPF5lvnvA9KJfVZ13VQrDyn7H58E7VAwBYvXrz4779ICv7gP/hq7T9L wXkPCocCO/+uXOjGKxuvbLyysD5h04RNEzbBvvL7yu8rDxMnTpz4+1y8pk2aNmnapLBekIOb ujF1Y+pGWNV4VeNVjeHu2Ltj7459fH4+M+SZIc8MKazPennWy7NehgXCAmGBANmdsztn/wuC +a9S+0TtE7VPFNY/PfDpgU8PwLwj847MO/Lf58ef5a8+nzdtb9retBXmOFc/Uv1I9SMwqPag 2oNqg/VN65vWN/8YYRUWCguFhYW5wgUpBg/jSuiV0CuhcP2d6+9cf6dw/Ad/GSmICKeMTRmb MhbOfn3267Nf/+v345mlzyx95neLMD/e9/G+j/fBzq47u+7sCq/Oe3Xeq/NgxeUVl1c8wuLZ R51XQf41ClMn/lrEuUmTgQO//bawfJAHj/9xnH8s1AOB37aFe3DXiwd5WPvu3VeupKYWHl+8 +MCBK1cefn5BWWD3j/0KFgf+45QKWf4tNePBcu/e69dTUuD8eZfL4/ljmZ//237ND0/V+A9d HGj7NXJs3CLQO0h1DJdAXM5Y3gclxb870At8T3hWuauA6ZVQ7J+CsZgwWj8DZ+dey83sA6EN k7ontQbjaGZqw8D7odBWXADCz/ys+0B/h+NaMogzhe7SYRCqsFFYDfpZalEGnK8583KuweqZ a85usIDvM9UcsR2qbXuqTf1toBcx3GUXSD3kNPksiNHaNqUEaP3EE4ZewMvUEj6DwFP+G/pZ EP1Sa7YD6/WuZIKwgrfEKcA8MUl9GSiiDZatEOhBmvgWiCsT36laAiofFj+wr4cSr5sWnJ4N WaXCU3NGgngh76jHBuLHie8+4YFKYyrtDVyAxNVpac5pcCopy6esgzPzxMv2d+BOeXOTpDug 3czbmTYKfJ0ym6b2B62o/cvQrWB/L+TLEAVMP1uamhJB/Nj+lf0MaAGlk78ppG3PiRb6gauY 57yaC66Z+ouGnSDGyCXVG8BQ7Us9Cu68lnY6wwtsUl8zhEJY89DiljOgvCid8e2HUttC+hR/ AeQEw/yIopB3xuXxLAZ9prDV9y6Yt2gDw3YCrbXGDADTZLm9+BUYL9EqIg0MfW19cy6C53uP lHURMo25nfkc1LH+ScnnoUypmNjyAQgdL+2LfwVs68Jm4gOlkuuUU4L7I5JV12hI6+VMdVnA /LJZNZ0GsamwUz0CjjTzFFsPCC0XUS9kPtjHOgxhK8D8oX2WpSL48n0lhd3g/MA5yC+A9K7p HVM4RKqxi2OWgLmzeadhFORPut0r9RNIX3Oz31UT5DXJ1W6VBg9GQ/inoA5ljPF10Kdqc9Xf Pn+D1Aug39EP6ZVAG0GsXhmIELLUdSDaiTa+DTxLS73a/5kk7R/fhC3IPS7Ynzk3Nzc3N7ew XlA+LLL8z3bdeNDOv4uXPS97XvaAX/frfh3WjVg3Yt0IGJExImNEBkTfir4VfQsGFhtYbGAx 6BHoEejxuy/k4bbhtuE2mGWeZZ5lhu9Gfjfyu5EQfTv6dvRtSCONtMfgZ+8qvav0rgL3X7j/ wv0XYMukLZO2TIJiu4vtLrYbIqdETomcAplbM7dm/htfdNNf76/31+HeyHsj742EDSkbUjak QKWIShGVIgpTFAqE6t/NX30+BQJ2xooZK2asgBG2EbYRNlAPqYfUQ4WLMUcUH1F8xO/+ceyQ 3iG9Qzr82O3Hbj92K1w0+LBFbAWLKjnPec5Dqw9afdDqgz+mihQstvuMz/gM2DJ5y+Qtk6HS t5W+rfQtf5m+ffv27dsXnLOcs5yzYPPuzbs374aNtzbe2ngLavtr+2v7Cxc//qs86rwK8q+h qr+9QvphQvZfH/e/Hq/A7oMEAn6/3w+S9NuuGQ+jYFeNB7lw4e7d379Y5cH6w84vsPtHf36L /D4sccJms9stFvD5FOX3PbZvP3gwORk0LRBITf3jeU88kZRkNkO1ak8++Y8CPAV2HzfCwYMH Dx48qOt16tSpU6fOXx/AjatBdk3gsuGkvSsIWXyoVQGtnv9z/yHwxbi7eXxgM4bPi1gE6mX9 LV8fOD91a+TxHlAyss7o6tfB+mr4ccMgUM+rmXoScFR16tuAbfoK9VUQehqeNJSD60l3k88t h+KbY2qVrgtKH6WdHgd7MvY6j1QH568uixoJtHJ8X7Q7lMws5SvyC5S/F7/OkAzWLtai7Ae1 vNpCvAdSB2EcJ0Epr2727gHRL3SXj4LwmlRJnA3621p7aR+wRvxYC4D+HIKQAOJ+XVTeBX8N Z4W8DmBMMbRRF4L6gmtKxhugfZHxcuZ3ILkiZ4R1Bu+dzI33HaBPSZ+W/gZIu2SdFeBNle54 0iAr6frOnHRYfW1Pifst4Piw7J+kdPAv8Y7LmgP+THeL7CkgVJNHWi5D2JshdSI2gePt0A3m jWByGF7T7wED1e5+GbwVXeu934Iv27898Ckoy/SL2jDwx/qvetPBN9BlyTkAZqdlnXUwRGRH vhH2FnjvuMd4u4KnmDvL+TNkVs3KSW0M6gxho/M2aO2Fly1FwdnZvz07HULyHCvEKuBPc28T PoTc+u5cV08olxY/ruinIF8QoyyV4WZ4xs27R8FQV95u6QVRa8LU2PYQucd83lQatD36KKUL 3B10Z5h3G2he4yDWgWNiqGQVwPyK/I31JsTkxm+wKRDRPLJ4VCYYBpmvhZwD7QNlt+FNcKU6 yyv54M1UNwSGg0UJOxd2DEKXhc8NuwdiRe1nww5wRt3Pud8ZfN9kD7iTCh6f8lnuFMj2u94O HIC8bfqosK6glxbnm49BYCIzpefAd195n9cg0CvQPdAaAgeUlb7ToMwMdPKeAxaq9zzTQKqk L/H1hGOp+z7ZcOrxT9wCYVuwe0CBgP5XCQ0NDQ0NhWHDhg0bNuzfL5yD/DUKfhlIaZ3SOqU1 tIlvE98mvjC3+aU9L+15aU9hfWPbjW03tv27vQ4S5H8HlSs///z06VClSs2a5cv/6+N8882H H7ZuXVjv3v2DD/6rXSVOnz569MIFOHNm48aRIwvbo6M7d546FUymYsXi4wvbk5M/+uiVVwrr RYqMGLF06cPbH+Sf9fP5bt++dw/S07///t13C9sHDz569MYNqFQpIcFq/eO4aWn37xsMcOLE vXt/5R8Pvz8/PysLWreuXz809I/Hz55NSXG7Ye7cmjVLlPjz4z6MQ4cOHTp06DFEnDXV86O3 Pxi+NTa1HAGtjfaR3hHkssZvDdVBXmJSzImghujDte+BJZ71/ong+Myx37YLjJ9bvjD0BnGz VFc0gfiEcFF4FrS2vKj+AFK0nGF4HVLzsuek5MP1N64vOLQFireJ6xLXBDI/d9d2DwKn0zTR 9BIUW1lmYcWi4C/ifgs33Jp5/2XXYEhwh/e13wTrEXtZQzbotbTBDAWO68318yBOEhaKfhCW iJ3kz0Evqn+uTQWtPz94s4CK6jp1OEiLxROWkaAfEQcZ74E8x7EuMgo0v9ouEAp6B8N0dSUo Cy1Vnc1Bbmu5E/s+mMMi65vnAD1jEkv3BaY42sRMAcs9ySxHQ8Ti6rO9R+CN0zXeO/cd/Lps z4UTP8G6ufvLqF/BvddMp0OTQDmU1yl9H2QfyKx8/33w5rk3WhZD+LawmxH1Iex0aFm7DSwt Im9Z8kF/Rl+iDgB9g+L1rwZ/Fd8403ZwDbPUM5wG03k5VhoEmRezv/R+D95nld2Bd0E+bxwf OAY5S7x9soeAtY15j2US2CMt62z3wHTY0s7XEuQ1hnHaFnDdyQtxz4KwYhGzwpIgv7bf6DsC OSvyO+b0BuGwNELcBMbPDRMNL8PlMTcbXssB22vWQ4Z2ELolrJHRD1Gjil0ssh4ip4dEhjeF 8NthPkcnMM00OUN1MJSzbbePg4AhsEIaBq7xuT/5noT8db6LgedBMltzDGMh/FjM1VgJLDus hxwmUF7Ju+jdBxnZd27fGgoZa+5WubAeAvF647z5oH2svyO8D/lJ7qraN+Dsrsp5NSCQrRXR loK/mvqdPgKUbXoH/QlQ9yt91c3grx54MxAJ+nhtqzoN9JNq38AzoAYCTXzvP/pEfRgFwrZA 6BYI6AKBdevWrVu3bj38/IJUjIJFggXjBN8o+J9JwbZzu77Z9c2ub6Af/egHMIMZzCjcru3N zDcz38z8u70NEuR/F5r2W2Q4Pz8rKz8fTCar9R/tc/xX8fv/cc6wz+d2+3yFdh8kEPjtzXm6 npfndIIo/uNFfn81heNh/TTN4/F6QVH+8ZsBfb7f/MzOdrsVBUJDLRb5d+qzVKmoKI/nt/2h Q0LgwoXMTEGA/zpeDk8/XaJEfPxvkWy3u7A9N9fjUZRCu4+bRxbOyhRXvv4TGOqFfSPGgbrU v1GtCb7Z+heBZWBsaGpCDMit5YaGRPAcCnzlawbieWGJNhcMy8ydDe/A/TH3b99cB8p25Vf/ 92BC+krvCY6jtqHhByH/qZxueT6wv2q+FjEGTKXN6+0DISrcvtkcAc7VziJnNLiyIqVd7peQ WCFyZlQa2HZYXlLrQ8q3aXv9ZaBYo/AiplOgNhV8FAFltFIycBiEyWJbsRFQlIVCGAjbuS+v BN0murPHgVCbGmJVIFJxqs+CctfpynkKDI3tTYu0BrWycE+9BLLTcT2uBhjO2sPiKoP2rHLE mQ1qG+/B/ApgrGeuF/0zqDsMq23PgvqZ9rIugWaVXzYfBlv18sfqvwfPly3f5+k+UG5SmWob voYFXX/46nBduLzVKpc6Cd6KrmYZq8AzMP9abiz4d6RtvDsEXF/kbTaPh9AvHflR0RCSHLLC dBBsl62vmL+D0HdDJjgUiDofVUtNA/9ZzxrXs2BQbIl55SCwW+krlgYl0avpm0D+pGR+sY6Q 1yf3La8GpiaGN8zVQLqrrglJBbfBXdO/AOz7Lf2FUhD/Y0TF6NNgx/BswhRIm2FslfIKhOyy H7BNgqh9Iauid4OzU9G3PX3AMNt4jd3gSAm32vqB5ZrZGfYVGBvKZvtgCPi17dJT4C8aMBED OTnpn3tfgMDXag5bQfvV2MXcHixfhY60vAv2quFrI54HqZjvIC7IbXjzePoGcLXLup/cG5Sz ysL0j8DWxf6l9gX4tihXLAvAW9a/x98N7KIlSTsE0vrAfHdR8H2oVNBLg15frkA+KLe1vmoo 6E+Z4vgQlL66SX8atGPaJk0E4ZJgMPpBEZUV8iP85PpnKRC6BUL6wW3kCvZxLaAgl7latWrV qlX79/sX5PFQ9dWqr1Z9FZaylKUAQxjCkEcdNUiQII+DJ54oVSoiAu7cSUnJyIC4uISEqKjH J6ALKBDM9+//ZqfA7oNUrFi8eEQEnD5961ZmJohiaGhICISFDRr0xRd/7P+w9n/WT9c9Ho8H NC03Ny8PqlQpXjwy8o/nhYYajbL826u5/X5ISPgtgSIszGKRJMjKEkVJguLFQ0Pz8qBu3cRE mw0kSRDE/2Il3q1bv9nNz9d1WYacHI9HVSElJTfX7y+0+7h55FSNew0uvntjC0Suf2JqsREQ SPd0UkuAkqnGBkaBqbexpeE46LLi8tkgd+TurodCIG+2/pVcFYpcfq7qM20g25PjuVcffMuV YcpoMGUbvxGrwdk3Lif8mgK5l9TX8l+GMqWil5fqCglq5JqKuXC60wXn8Tw49/5d/4VLcPHM 3dNSHajyZsUJLV+AOhMrZRYbDU8ci9ogtAShpKGjWAzEjfoWfQXoU7Vm6m3QU8U2QhqI3YTi hsYgpIp79Och1ZR9/dIASO/inX2jLEQMi2gX0gu0T5yu7KkQbjE5K34AoXMdvcrVA187rYL7 AvCBIIsyCLtIkXuB+LkWERgGykz9Z60NiLpY1fAGkKhHa6kgfKXP10+Dmq43EBKAiuyTosD2 uaWK3AhWhc7s8/FdWNf2qPFGH9ATbDOiLoJ7irdxoB6o690lcn8F/aJnVt41EGXtlH8pWN+T 86SZYN5l72LPB4fFYbHOgZAR1pfMp8E8w2wyyGAYIY9SnwPtV1I0A/hLqx8pXtBPaqWU7qDN 104HukHApDytauCp5n3dPxqElXKy8DxI84Q4sSZI04UFwiXQFmgtBAFMbtP7xj2gbRSaa7+A qYr4jPElMOSbf7I+CVo4a4RzoE0ONBRTwVvZ20wrD8693mL+AARGBbYGMkCtJy0S3gIpxnjE dhyM4y3hxnyILhNS1wIU8cUOsl2CO4H7b2T8DPlKToX0zyG7dmrCxc6Qm5/m8c8A9RibAr+C HKe00ZJANIkrTQ2A1UazHAHyh+I6qSjo7/CO9A74J6pleRf0j8nXxwICjYSToCcIv4grgA/E LdIXoMvaKb0WaG8JN8SdoGeI5+Tp8GO3n0d+v+3xT9wgQYIECfKfQVZWTo7TCb17v/PO11/D +fNXrqQ9jkUWD6FChTJlYmJg8eJp015+GSIiwsJ+/2bS9PTcXKcTXnhh9OiFC+HkyStX/tE+ 0Y+LatXKlImPh59+mjSpXz+Ijg4N/b0/2dm/xY4/+ODMmeRkSEv7LfL87yImxmqVZfjww8qV ixSB8PDHI6AfW6qGPM7xnXEtBGbk1M13g/5K9rc5u0AY70pxWUEfXXZ+qZaglnb3cS8HZ/HN 5359G8LML77dLh+EfZYE4TgkTDK+UnQAZA9yV8mzw4mM49qBmWApazSGvgSefbY1+i2I2mEt Gd8QDO8Yy4XXhR1pu8Lv9IZ7I4Qf7nYGd4S0LnADth7bdf77C+Dr5Kfr11AqsfH64vXA4jKd pyeo+7XXRQ8Ip8S7wlwQRwp7pI6g5fKhPwHkBdQznwF37TxfVn+4vPpKz+OlQDmszzB8AfpC 03DNB9GnIiKTL0LF7UU+8yVBdLK1ceIuwCIONnhA/0ZEawhMFjaLISBAS2MrED7Uq6sVQF9H DzYA24WlwiQQw4XbFANtFp2UAAQ0pYh2EISK/tx8HcQNGU2uA/I4bZ76Psh9zF3tG0B7IaxE 5CVQfgmpGnEV1F5+wfk9+Pv7Nud3ACU6MEarCYENWdOzLkKOM+sZuT2Y6hs/FN8Bs8W0w9Ie TJUMw02lQQw3zZc2gHRDkuWDINU1lLPuBOMeuYnYHgzmkL0EAJnntBQQvEwUl4AQokv6BtCa 6rcoC8pQPVXrA2o5JZJFkN9cKcMr4Fub08cbC97egamKCAExUEK5AOpR9nIW5DWmZPN8MC61 rrBNA2MHcwPrQYgbZV9uXAo1OpebFbUGanxX8+XKMyHu06TLpabC5ne3zv66JKS+kTf5Zmmo 3qCmr20bWL1pzb2fh4C+2fOqoSQ0/a5KrfrpcCXubIeMsnDs22PlzleAO4uyIrLGgO95ZbDS BSxjTcvMvUA+ZnjV0A+0imoR/V1Qa2lfKidA/1oYIH4LYnO9uxgK2mX9rmYA7bi+Tx0FdPv3 fTkECRIkSJC/nwLhun79F1+89trf7U2hcD106LPP3nzz7/amULjOmfOPF/H9v8YjC2fLF8oU fysILL+Zd289EOlr4akC2jPeIv4XwbhbaFNyDRDqmu36Gdjivx5YAqaPYyJDqoFhOdPljZD5 lntthgDH1x8fvm82JMwybot7C1zJ5uaucAhLE0Y4EiF2U1yJ4r3g1KlrX6aJIJ4OGZy4APRF mWtSQqFokfLDq7SFlBrX+1yZBxcWXPVey4AjW5LaRyTAc10qzrL3gsCqwDLfZJC3mSIsz4J6 WFvvTQHhlDDXVBToq5cRwsHwgWWSaRfElKiglQGSD5/yXBkGpXZLEXErwX7JFWlpC9dSN+9e FQf2eaXTqrUBYZ3QUUoC/Tbr5fZgGFF0e5muIL8TnV3iadC36w2ZD6wQepIN+kL9PDoIyYzi KIg19WihFBga6gnqByB8rS1Wu4LrK+eTmfdBflXZ7SkNYifzbscGkGMs+yOiwZhnuRB5CcQa lrm2H8H0c6g7XABtqrN/Vix4UWK1eRB4X7+n5YB2SC+u6eBs7lnrOQ7iyy5//mVQJHWXfhFo rrs5A8Iq4Yw4GYwLeUI4D/pOsQ99QH9VWCS4QGjIYiEB9C/4SVwN+mRhISGg9defVfaBHia8 J5YB/TWhqHwXhLXSdrkFSCcNxwwHQT4Z0iDsFlimW6bbfgazw7jGfBDiMq1ubSfUaFq8tsUO 1VrVrlL1GYjbXVauIYGySDhnjobASX0WO6Hhu/XdXcaBs4gz0OhdiOiV8FrpzyDa0n1h2T1g X+goU0aG0EthvYu/BxUya06/2w+Stlbvem4ofO9efmvDbfC/l59zzgPJHVO/zq4Iak9xuuQE o8OsWY+CIVFaYvgCZLO0UHwG6IZT7Az6KjVeOwPaQOW4/ikA5Wj0d0/zIEGCBAkSJMjj4JGF s7RBPiKdBt3tqG/7EYRNMWmxo0DowAUhE6gk++Um4Ft+J+76DZC7RL0aPgbk92MiYr8FT0jg fn51yBudl3xvEFTfWrlu3YUQ3T98RrwNDqSfb7xhNIRH27rHTAa9nXzd8CacG3i8+o5dYJxl bVt8MRSfZfuyfDTU2lb26lM2uNAgsmdJQHhe/VJ7GqpmlPVECuAb7Xo2/T0Q3vI0zmoJ2ipZ tRUHcbm1v80HeiNDnvEHkC6ZN4rRkDLwhHy1EqSczX3vQjuwLYj/0JQFEalRjZNmQfn3K/ta DgGPuWK1u37Qk7Nq3SsCvgX3Ot/4AfQk13s5VUGVwss71oLh2Yj46DzgCWFYaDXgLP2U+aA/ zzlGA6dIZiVoLYUf+RB8H/s76M3Al+/fgBO0AfJdQ2fw3g4sci8DDN7D7u0g5OWuyvwFTPmm 7Ps2sLa0jwnzQ7EtxRKjUqB9dN/6zarA/fR7t7NfgtsrrsXfzYfb/TMGu3pC5qfuEoFpkH/S v1CoA+4c/ZxyEoTWaqQ+EgKhKlo8uE+o6Vp34AlhnL4e9GhhD/OBtXxIJogx4lDxKRCjDB8Y fgBhgxRp+AbkdYbWxgYgzZQz5EkgjzB4jO+DIUl8S14OjKczz4IhWrUG0kGbntHwfnV4rvjz HUo1h6efbUP7kuB9T2wddRN8XwTGeqNBPyx+7msGYqx0WewM0ovmMNsiiBolV7Dkgz6GqubF kFis6N4m4yBgUqYpW8Gf6b/sPw7G9227zS0gcF4dHNYWnn61ersqPoifG5ZR7FVIPujepr8E 289t+WSvC1LmZr5xdxd4zIaz8nqwCMpXpuNgWmmqadwA4iFxn3gU5AjDk/Jv2+cEY85BggQJ EiTI/xAeOcc5SJAgQYIECRIkSJD/yRTkOD/ymwODBAkSJEiQIEGCBPnfQFA4BwkSJEiQIEGC BAnyJwgK5yBBggQJEiRIkCBB/gRB4RwkSJAgQYIECRIkyJ8gKJyDBAkSJEiQIEGCBPkT/P/b 0RWsFgwSJEiQIEGCBAkSJMgf+f8AU44p91En/UsAAAAASUVORK5CYII= --------------000407010901080300010702-- --------------010108050702000202020202-- From nobody Thu May 15 06:59:48 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E68D1A007C for ; Thu, 15 May 2014 06:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 kdOmjnIP8fl0 for ; Thu, 15 May 2014 06:59:43 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC231A007D for ; Thu, 15 May 2014 06:59:42 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id i7so1296631oag.9 for ; Thu, 15 May 2014 06:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sOBr3zNBNS4WkTD65teCeInpVGHDnnv9Zt67T4OkTk4=; b=YW2wf5VDSNxavtWNnkiEC3SP5xBaZd0ap8nJ631QjxEvvPVFWc4BohKU9GI9u63L1r cv1/Ea8gugGmWiwu/YxHCbM7rdaG/QGJ4qocYJhPzDbwILGvRtPyQDHCvX10YZN0uAqQ /E+Fm4ZknPDHPyfQt5I1/RdBwfPCAwnMCvcnQdEHpIFGd+9IStxfdfyL5fXdQ1qFkUF0 7bQzadC+c8hwi5h+bfoNVX7h154UflfYcpG90rpa5NPLGtgTlvaAlrQoFjm+bDjmKoyz kEmT4YQFlMg6i6DrbLAzJYB2pmvHEaBRqqZrutA6buhG0G/MFxFWUkJoBhJyhDTUXu66 3Pxg== X-Received: by 10.60.60.132 with SMTP id h4mr2868759oer.77.1400162375476; Thu, 15 May 2014 06:59:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.0.36 with HTTP; Thu, 15 May 2014 06:59:19 -0700 (PDT) In-Reply-To: <5374BFCB.5070200@aol.com> References: <5374BFCB.5070200@aol.com> From: Josh Mandel Date: Thu, 15 May 2014 09:59:19 -0400 Message-ID: To: George Fletcher Content-Type: multipart/related; boundary=089e0158ab3a04c80e04f970b575 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Yb6ilYJLjykrNuVfoxGO6ePf2cs Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Security considerations in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 13:59:46 -0000 --089e0158ab3a04c80e04f970b575 Content-Type: multipart/alternative; boundary=089e0158ab3a04c80b04f970b574 --089e0158ab3a04c80b04f970b574 Content-Type: text/plain; charset=ISO-8859-1 Hi George, You of course characterize "today's" scenario correctly: any app can start an authorization and successfully complete it if the user approves. But that's not "just" phishing, at least in the typical sense, because the approval screen itself is in fact the approval screen for the genuine app. When a user is looking at that screen, there's nothing in the content, URL bar or SSL settings to indicate anything's wrong. The only possible clue is the temporal context about how she got to that screen (and even that can be counterfeited -- e.g. by a malicious app that waits for the genuine app to launch and then immediately executes a permission request). So there are really two problems: 1. A malicious app can start its own authorization request and successfully complete it if approval is granted 2. A malicious app can intercept the genuine app's authorization process and steal a token-equivalent It's unfair to call #1 a "user-error" because there may be literally no way for the user to tell the difference. If anything, the user-error was to install the malicious app in the first place. But this is a distraction for two reasons: first, because even a knowledgeable end-user can't actually tell what custom URI schemes an app is going to listen on, and second because the presence of a malicious app on-device is a precondition for TSCE anyway. It's already part of the threat model that TSCE mitigates against. So to summarize: TSCE explicitly addresses #2 but is silent about #1. I think it should explicitly explain that it can't solve #1. I claim this is important because concerns #1 and #2 both apply in the same context: a mobile environment where the end-user has *already* installed a malicious app on her device, and that malicious app has registered for the same custom URI scheme as the genuine app. I think this point is especially important given one implication: that TCSE cannot safely be used in conjunction with server-determined permission whitelists. This implication should also be made explicit. -J On Thu, May 15, 2014 at 9:23 AM, George Fletcher wrote: > True... but isn't this then just a standard "phishing" attack? Even > today, any app can attempt to start an authorization if it knows the > client_id (which isn't protected) and the registered callback URL. The user > has to determine if they think the particular app asking for authorization > should be granted that authorization. > > Am I missing something? > > Thanks, > George > > On 5/14/14, 7:43 PM, Josh Mandel wrote: > > Forgive me if this is well-trodden territory, but I would have expected > the security considerations in this proposal to include a note to the > effect of: > > "In a scenario where a mobile client is contending with malicious apps on > the same device that listen on the same custom URL scheme, it's important > to keep in mind that a malicious app can initiate its own authorization > request. Such a request would appear the same as a legitimate request from > the end-user's perspective. So in this case, a malicious app could request > its own verifier code and successfully obtain authorization using the tcse > protocol." > > Obviously this does not negate the value of the proposal, but it's > something I'd expect readers to keep in mind. > > In particular, it has very strong implications for whitelisted > authorizations, where no end user interaction is required. In such a case, > a malicious app could initiate a request at any time and the user would not > be in the loop to raise a question about its legitimacy. > > On May 9, 2014 4:51 PM, "Brian Campbell" > wrote: > > > > I notice that code_verifier is defined as "high entropy cryptographic > random string of length less than 128 bytes" [1], which brought a few > questions and comments to mind. So here goes: > > > > Talking about the length of a string in terms of bytes is always > potentially confusing. Maybe characters would be an easier unit for people > like me to wrap their little brains around? > > > > Why are we putting a length restriction on the code_verifier anyway? It > seems like it'd be more appropriate to restrict the length of the > code_challenge because that's the thing the AS will have to maintain > somehow (store in a DB or memory or encrypt into the code). Am I missing > something here? > > > > Let me also say that I hadn't looked at this document since its early > days in draft -00 or -01 last summer but I like the changes and how it's > been kept pretty simple for the common use-case while still allowing for > crypto agility/extension. Nice work! > > > > [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > -- > [image: George Fletcher] > --089e0158ab3a04c80b04f970b574 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi George,

You of course characterize &= quot;today's" scenario correctly: any app can start an authorizati= on and successfully complete it if the user approves. But that's not &q= uot;just" phishing, at least in the typical sense, because the approva= l screen itself is in fact=A0the approval screen for the genuine app. When = a user is looking at that screen, there's nothing in the content, URL b= ar or SSL settings to indicate anything's wrong. The only possible clue= is the temporal context about how she got to that screen (and even that ca= n be counterfeited -- e.g. by a malicious app that waits for the genuine ap= p to launch and then immediately executes a permission request).

So there are really two problems:

<= div>1. A malicious app can start its own authorization request and successf= ully complete it if approval is granted
2. A malicious app can in= tercept the genuine app's authorization process and steal a token-equiv= alent

It's unfair to call #1 a "user-error" bec= ause there may be literally no way for the user to tell the difference. If = anything, the user-error was to install the malicious app in the first plac= e. But this is a distraction for two reasons: first, because even a knowled= geable end-user can't actually tell what custom URI schemes an app is g= oing to listen on, and second because the presence of a malicious app on-de= vice is a precondition for TSCE anyway. It's already part of the threat= model that TSCE mitigates against.

So to summarize: TSCE explicitly addresses #2 but is si= lent about #1. I think it should explicitly explain that it can't solve= #1. I claim this is important because concerns #1 and #2 both apply in the= same context: a mobile environment where the end-user has *already* instal= led a malicious app on her device, and that malicious app has registered fo= r the same custom URI scheme as the genuine app.=A0

I think this point is especially important given one im= plication: that TCSE cannot safely be used in conjunction with server-deter= mined permission whitelists. This implication should also be made explicit.=

=A0 -J

=
On Thu, May 15, 2014 at 9:23 AM, George Flet= cher <gffletch@aol.com> wrote:
=20 =20 =20
True... but isn't this then just a standard "phishing" attack? Even today, any app= can attempt to start an authorization if it knows the client_id (which isn't protected) and the registered callback URL. The user has to determine if they think the particular app asking for authorization should be granted that authorization.

Am I missing something?

Thanks,
George

On 5/14/14, 7:43 PM, Josh Mandel wrote:

Forgive me if this is well-trodden territory, but I would have expected the security considerations in this proposal to include a note to the effect of:

"In a scenario where a mobile client is contendin= g with malicious apps on the same device that listen on the same custom URL scheme, it's important to keep in mind that a malicious app can initiate its own authorization request. Such a request=A0 would appear the same as a legitimate request from the end-user's perspective. So in this case, a malicious app could request its own verifier code and successfully obtain authorization using the tcse protocol."

Obviously this does not negate the value of the proposal, but it's something I'd expect readers to keep in = mind.

In particular, it has very strong implications for whitelisted authorizations, where no end user interaction is required. In such a case, a malicious app could initiate a request at any time and the user would not be in the loop to raise a question about its legitimacy.

On May 9, 2014 4:51 PM, "Brian Campbell" <= ;bcampbell@= pingidentity.com> wrote:
>
> I notice that code_verifier is defined as "high entropy cryptographic random string of length less than 128 bytes"=A0 = [1], which brought a few questions and comments to mind. So here goes:
>
> Talking about the length of a string in terms of bytes is always potentially confusing. Maybe characters would be an easier unit for people like me to wrap their little brains around?
>
> Why are we putting a length restriction on the code_verifier anyway? It seems like it'd be more appropriate to restrict the length of the code_challenge because that's the thing the AS will have to maintain somehow (store in a DB or memory or encrypt into the code). Am I missing something here?
>
> Let me also say that I hadn't looked at this document sinc= e its early days in draft -00 or -01 last summer but I like the changes and how it's been kept pretty simple for the common use-case while still allowing for crypto agility/extension. Nice work!
>
> [1] http://tools.ietf.org/html/draft-sa= kimura-oauth-tcse-03#section-3.3
>
> _______________________________________________
> 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

--
3D"George

--089e0158ab3a04c80b04f970b574-- --089e0158ab3a04c80e04f970b575 Content-Type: image/png; name=XeC Content-Disposition: inline; filename=XeC Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: a1646ab0a18c28d7_0.1.1 iVBORw0KGgoAAAANSUhEUgAAAWcAAABxEAYAAABZ0L78AAAABmJLR0TIyMjIyMhnRJJpAAAACXBI WXMAAABIAAAASABGyWs+AACAAElEQVR42uzddYAUV77w/W9VtY67MoO7u7u7BQ3uhEAIJLiEQIBA 0AiaQIJrgkNwd7fBZ2CGGcatp7XqvH/cy84+uzfPZjfszX3u259/hq6u+tU51XWaX506dVq6dOnS pUuXhMDNzc3Nzc3Nzc3N7Tfp3v6jZs2aNWvW/LOL4+bm5ubm5ubm5vY/y+XLly9fvgzyn10QNzc3 Nzc3Nzc3t/8XuBNnNzc3Nzc3Nzc3t9/BnTi7ubm5ubm5ubm5/Q7uxNnNzc3Nzc3Nzc3td3Anzm5u bm5ubm5ubm6/g+6PBrBa7Xab7T9fyIADHckghbJDaghirBQm+YG2z1nCEQbEWIpZ14EoY+mWVgFs td4kv/QC/ZoAf78jYMwLuho5E1ydzIfMF0D5hPPGoyB9RwbbQF0sF9e/Aulg3i+ZX4KzkzU9exgY zwZfjf4RxDhbnCUZHB88O3B7FohVckNlH3DP9a06FLRXOSsyl4J6QBqjdAItT31oLgTWAVnznXGQ NyKnTNZ+yCuWG5kzHPKSbf3VbLB4OzJsF8Hy3BqVsx7sg+1TrL1A/8x7nZ8NpAneIX7pYEnMPJmV BbnfZpHaE1ydpTVyRRDV6KyrBtpMzx8CosC2Py8v7wgo/qYi5nuQNSnDI+Mb8DgVcjsiC7QE5Sev WDB7eUZ7bwdh4qmxEui/Nm6U94M629VA+xVqDqn9fvnGUFOqVDz8OWilXYtc90BaJ9oRCcJfChYX QWqCmSAQebhwASD9Hx+kwn9MSXgPCRkI4FM+Bd0X0hJlMLy6mvQwbT0cWH+646V1IIz6564x0HtK 01mNmoBzkrxEigRtl5iFJ/g+9/zGWADkpZK/vBt0V009zMfg+IwTyQcaQmYBq01tD08SkxdfXApe b4Jn5fYG+8NED+UuPIx5Xeb5WpCu6trbNkJ2s9Tp4gpkD84d5/MpeN/UfWm4A8HL/JMLXoMSOwrn lFkH1u72CbpFkBaeHJgXCtGNQ78Vw8H6iZpjmQyFDnnkRdYAv/4FP4ucAXnNrE/TPgc/f49OgXvh YpOYz/btAOu3arfUJjAoouXgGV+A40e5u/IBlNtU4oPQjfD4s2df51SAA2MvHl82C7J9rJZrPcCr gzza1w9S7idX8vGG+fcmR6+Y+Wc3czc3Nzc3N7d34d31OMsINCBLMuEH1EET50FaKl4LFaSR4qbs C9j0m8UFcD5MW5LUAowBPgW8zoPmr32gVQOa6kqZvwL9eVn1OgOan4hRl4OwiBnOQFCuSRGiDnDO 65V/FzDM9k4IHADaZNcAxwXguKinVQMhu3bYm4DTJ9kvbjeoH+QNyOgE6khnc9vHIOZnJedMAseI rEPp10G6oDxTZ4FI1F2Te4Cy2nDHMBwMDUxZ+gXg6fS8Zj4I5iPmVR7VwPCBboL+JSiernTHh6B3 CsU5EkxrTBf1JUF5TwqTg0De4DrhCgCtkrOyrRgoXdQP7fVAn8REVxCYeuu7apPAmOZh81oH0mhH XXt38B7uedg8GcQ+tbyzOQStCukWcBo8l/kcCjOBzkuv09+CxyNjcmMPg2WqpYpNA/l9Zby4C9og 6XMpBKT57CAMRJIUiAUA8Tcp839QAQEUk0IRINWirrQenG3ES9czKDAr3NuvPvS3dOje7AA02F8x pez3EPRzEAFGuDj0uv7OZ/BwxPM296pBdlTGYIsfcF1eJHcBQ2fGSV+DubH364gxoIQppe06CHnj 95XVAjYlW+g9oVrfklvbtwa/XCmx6AnIOpy2NzAdfId7VA+sAIU7BHYvugqcOY5ixSTIPpeTx1O4 X+SFclsPhReG1/VqC0UcEZZyFeDG5AcHM0fDG3vGpswZoNsrjXpVD7y2yTWc38LrmskHnv4AN8vf r/XzLNC+tbTxLwxh4R6NOm8BXQtjX90Q8DplHqOLhmRn8reZsXD342e+Ry9DVvOsvo+Og6tNTnpu LqTfSRyTWRjyxthiXcf/7Obt5ubm5ubm9i794R7nv3AiIUAqLGxSEIiLPBFLQKsn3RGzQa6sX6qc BXW7JcFaGbgif2+YA/JcQwfdPFAmKsPVSyDuyH1ELdAGy/21MiCFiZW6sSD8NeHUgzTWudAyDKTS +skeQ0CdLT5xWUErl9DwUQ3Qkuy3nFtAuisv0K0FwxnP4f5TwXnActaSAtJpVyElHlz+zr7OCeD6 2N7Q/hmoEUoLUQ8MC/Wt9B5g2OJl9q4HcrRtpGMGoNhv29qC1wKptXQSpHOyVTKCOs81yV4a9I/k SwSAY6s8VhsI5rEeZnMMMD6ngOUXUCtrU7UZIJbazDm9QdqgBSnLwalaTNmfgmdRwyDPFYCC3fUh aCesG9JnAwb5ij4arMNy5Tc1QL/E42BwAPgmBxT1nwVZdzJsGYvhxbiXn2UEQaVjZVqG+oIr1jVE A+gvf8h8QBNp0mJAQhZx/EeS/H8m0BIGQBNxXAHxSCrHzyDdF18rFtBy1UbaHLA+oZb2EorbCo2J MkNi97SDyWWhZs/yO4t1hbBeAWmhyWDT1AOuM5D5a/Y9x1fwYExa4Wc/QvqXtp9flYZbV+Ii73eC 1G8sianeoN7PmZ+TBj6h+mK3MkCf6rfBuRYaLy3cqUINcJXXCsmJcOajO2eemEDeovshpDJIZUg2 JkCjzZXLNvkFKs8r5F31NWTfiTySeAEazK4tde8F9z+PefP0NTxu/MCy7RU8D7Svc1yEzFh94PNh 4D0P1TQTqhcvd75RdfD/ODLVPw782wT6e3eG9CVvhmd9Aqlrsozia3i2+vEHSVVBNNQOmyeBrW5W ZtQX4EpUfXISIbM0N159DECDP7uRu7m5ubm5ub0b7y5xlvmPZMyPbEzAfqkZz0HXUoyiJ7iCtWtO AygrxBlxHZSbRSsUzwX1K7HAeQuUk85eWe+D+EQ/0OQL8nMtVXQBUVtuq+sLUn85gTmgxedOyVBA u5jXMbkT6PboK3vkgu2lGidGgdY3ZURCc3DlWhfYMoGp0tfKdZD7KU05BkQZxnnfAd0D6ai+LHjv 9vpIKQKOdo7dUndwFtZGqp3BtUgthjcY1ortxjRw9dUGi5ug2QmWpoBXMa+quj5gz7auyP4O5GvO Ha5U8Cyl7JOfg3zHfMUYCXIhNUMqCdJqe01nI7Dudra0FQU2SX2UlmCfnKu33AZ9il7NOQjc9jgb VB6M3V29c4aB85j9Jc8gy5Xzflp38KwSODBtNujLhGmlDoH3PN8Nfr/Ag2WPExJaQ6mvi2wLKgm6 2Tov0QHUyeJD2QhyXclT/ArijshDARQktP/jExQ4AYEvhYEZop54CXIzWWEw5MblTrbVhMtTbla+ 2RUSy2Sejr8HuXVyX2udoMqbih+UnAymnh4Ng0Ihdkli7+e94XvrgR+37wFdNd2BvK3gmqL/JrUv FL0b2CcqGe5/8fy+z2Jw7HEVtr4E7+tJNe5Vgohg/zalP4PMY/YWaT5QeHzA8obfwqtRb2odnAbv r23uatEbfFLtmw3joGx0ac8iqyCmRELaYx94lZSwNy4DLLds31t6wQvrmyJHLoNrnZivHAf/ctbU xIsgNlnXh8+G0nXLRJVfAUGBQaN8zoDnrzrN+hiS1idcS9VB0pbMr18eh5dyYsSzLyAoLuwSdyFr 5fOw9NXAAb1dOgRZpTNPGruAfMens+dEoAZj/+xG7ubm5ubm5vZuvNvEWQbxFJd4DVI5IkkFYWO6 HALyh/SS5oOo4tXTvB2kSxzWTwJ5sGyVHCA/NrSNCAQpAL0uG8QcfNkOkkscFXtAG58Xn7IIeKYL 8vYD+ZLHpYAvQfXP7vZqOEgWqbpaFxQ1oHz4TNB+TLTEZoHWzNVYnQzKPU9rSBxw06R63ACRnved OgFEefUzeTEYrNJLLQakCC1HSwIp117IZQFXAXm4czkoDZUKcgboDml5ylSQYsUTMReEpMzUjwRO U1u0BnOG6Ky1ATWRbnIpkHubH5vugTxf+U7nBbisYaIOWNu52qkzQUuRNiifgS3REmybD4ZTuLLW gLJe9wkvwPzM8NTcFdKjMlZbioDuB2K19ZBtlboYI8EnMPhptAS5w61tXZfhlT5eTp8LxdsUHxhc CdRU+69qKIhn0kL8ARvwX/3AugRogIomFQZpN7PFKhBHtJ7iezAfMy02mqBFcN0ntdbC4ebn990e BTsPnVu9bT8c4d7S092h5vViI0tvAl1zSfW1QtQo38Jhx6HsriK1Ky2HlGJ5X7y8DK/ltOBfa0Fw A/9XziLguCA1si4D/zrm0eYPQPHOuZeVCjEn3wx39QGLp7XM6VtQdnmBguH3IH5P+uX7aTD4VLsP +obA6uOb9b+EQGov29pHg6BOXMlSncfAk09epN1/ALkVxX7PIxA5xKuf7jLYmmZX9XwFpT2LHa32 K1T+uqCp5Gow/2jUeebBm2VJNTOeQ2zJpD03dsGB69cn7T4AIQ99dc5y0PBk0aCW0yEi2f/TOhYw /moqLdWArFf+PSyr4E3FvLPxtf4NLbYKVagCh+cennt4Lmz33+6/3R+eNH7S+EljUFeoK9QVUPTL ol8W/RI67O+wv8N+6JLaJbVLKig1lBpKjX9Dudz+r6pVq1atWrV/frvJLSa3mNwCus7tOrfr3L+P c+zYsWPHjoGfn5+fn98fL+ez7c+2P9ue/7pQoUKFChV69+fNv7sebm5ubv8u7y5xFghkwCiFkAoi XjyWPgaOMld8ClJf5bxcA5goTfYJBu2q2iV3Eyi5Ul2lNjBaqmcaBeKFSJVmAs2lM6wGcUfaqJ0D Kcxw1LM68KGy1VQctMuO2dk/A/O0YPEhyAV9RaAnyJZwT3MayKv0Lvk0sME003MtSOfkTeZS4Poy c7ZlMYjBdi97I5AGGuOURJBU+1FXCCi/2q3qRrCHO6Kc3qA67dccHwGL1M2iAugmS6UUM0izdROl XiD1NeV59QGRKjpoL8DVUA11ZYF5lXpMzgPXLX1hZSEoC3UX1QcgH5GaSHrQyud1s/cB9YljN7vA +Iku1zwR1BhnFfsoyNmWMzKtGZhVryF+DcF3vq/TcxvkTs/ulPE5UCI1NHYM2Kcbqxi9wRDrGxW5 BZ6ufhmZ9j0UOVVkT3AYSD9K10RV4IqIkcsD5ZDES8ADHX6ADQdWQKBhAilC0qOBOCjuIIAo+ssP QKmq+0DMAecuZwHHXQgc7CuplaGxV8VG0evA8pFhxbPjoKutHYsZDVKTrJRKGVB1YLntNSvBj2G/ tvj5KoR+FDrQVB1qjirzYb2h0GZ2udMF5sLjIlmTXifDrgFHLv5QDQzjlZvJxcHaRA30nQm3Eh97 BjwAv56GNN9VEOP5XLq8F77usWWjwQFBPQyd5Klg7Z8ZG7gT1FKKSDsJEa8D1hQ9DrmDLeeiD4NF tjQ43wJMHTxkqS7cKPS4xaV18KRunCGmBMgtzZkeZki48eZW4noIT/N8FvgQyqcGHGx2DXyLBlWO 7wf+zgIdSi0BrZmuVPILyGuvrrH4gT5E7Hm4BVLLpSYkXQCg+LtssAtOLji54CRsb7q96fam+cv1 Lr1L7+IvifVDj4ceDz3gYfeH3R92h+vNrje73gzmj5g/Yv4I4AY3uPGOv03cfreQ6SHTQ6aDMlIZ qYz87fU8xnqM9Rj731euHgt6LOixIP/1XxJa/PD7sw6Wm5ub2/8g7y5xhv/oydQLgReQwXNuAbFY xCqgPGGSGUSolq6NBW2RyztvNEgT5YNmC0gzjQf4CqTFYqm6AEQ6wSIQhEGurKsCUjVr7+xccMm0 zDOCMsdjtG8/kNr4XfLtDbrrcje5P4iNrpnaFpB2Fa0SVhak0rpSusJAT3W9ywJKdZmEumA/4pyT +h44w7P658SAK9VyyBUI1mrW67a+kPe19du8l+Dyc6WLHJC+lrbrWoKyTD4rLwRjfUMl40AQZQ19 pEFgn+BMca4D6Yg6z1UH1ApaCSUEpNpaJ9EAZIf0yNUYXMMcIxUJPH1MNqMdXFvtm+27QDvsKuS8 C/IO3Sz9QrDF2b5Xj4JdL0JySoHphE+G7jUYy+rv6iaD4u1U7FvBPjRjYsIz8LrqOz9gG1hPWWuY ykD2FzkXbOngk+WdYLgN6i51lngFNMJBXRBFxAztB5DypE1SLHBCWiblgsgkXNwDNG5THDhHM9dI 0M6IOOUkyOdZYywKaZ3fZGRZwLeEPMdhAPU9qWFmDqSHZapUBFWfNep+BhzMuXrq8XkwvTLJqXXB 8EifHlYIMkrkzDNPgtNtkvdb0yFpadqXt3ZCSo6zfaoZ1I65nwkvMD3UaqTXBu2CbUjSTRC3g3uF VIQKqZGDas0Hx0nrLtcGyOoiu5wdodDhiMF1RsDjwMd7En6CsNDAZf5NIXlQzsL0cZBS3RKW2goM 3fKOOqZD9XZlejQxgf1JTmKgF7yJyWod0wOmNuxpGuQLurb6SeYP4ZUzpVV2BYgxxB49ehp+vXBp 0pZL0OyLal3fGwE+39iPhzyBY/WuzrhRC3IWa688vwd289W7aFqnTp06deoUbP9k+yfbPwFjHWMd Yx2YmTAzYWYCNP2u6XdNvwPpnHROOgens05nnc6C6aHTQ6eH5idAZ61nrWetUJ/61P/v+Y5x+y9s bri54eaG4Pfa77Xf6z+7NG5ubm5uv9e7nMdZ+s9b/RapIOAhlRPdATP3pS9AeklpZSCooY4ZaXWA 4RZT9gcgCzJ0x0DrRys5HKTTYjhfAR7SAeUIUMTWO/shEK+zmp+BssrT278TSPV0U4x9QDpCU0UF rYCW67wC6jP5jeMByBu1M2wE1jvmOCaAqIq/8wdwhthf5sWAVEM8UKeCLkp3x9AMbFdze1lyIKte WnbmQrBrlrEODcQDNVvcAd0EOUOpAB4+hrvmFPD8wDDUozjoW0m95ATQLombLAD6Kxv1v4IuxBBm KgK0kwbIC8A1x5XpfA/0H+rPyb+CsbHRpDQDrwnmRM/7oP9VKWwIALFKXaA2BP1eZbXsB9pWl92u B7uXxSPVBrJTvukyg3ZAaqwdAduG7F4ZhyD9TnzxB7tBzXZsse6G3NmWh44XIG2SsqRWoC0T59WL oPtZSVA2gtlgGONRA5R5ssm4HNgsgiQPkMqL+dI+4BTtyAMGi1D5Y2CJNFwaCFlVc/ZnxIP5vLkG PpBTSC+SjZA53GFKvwCx6a+PJCwF1zx5cl5fyPjCWTzpHBTc4Dcsag+4puVV8pXgwftxd68Hw+Hn N1pv+BhezkjZ9qwwNC1bfH3jD8AQKZl9O4N01zBDawSmTN+WeiN412BctSPgOkPVrETImeqc9uQM xH6T2Co5EhpVrWQJuwIlz/sVDZZBd1h579Y0iAwNuGI4Dsbxds/A0dCuZJ3Mlh4wzntI4aFLIfB1 yPdeq6DplJqFquwHyeG1RoyDg/0uHTuwCX45ebz5tz/BoyIvTa9WQ5G5odUDj8CTHY9jT5+GJFvS N7caQ43bJaaUbg2FjgVsevns3TWurVu3bt26Nf/1iBEjRowYAS12tdjVYlf+rXR5pDxSHgmNnzR+ 0vgJTNw+cfvE7dA6pHVI6xDIPZ17Ovf038dP2JuwN2EvjN88fvP4zVD/Yf2H9R9CfY/6HvU94NMm nzb5tAkktk9sn9j+vyjgf/Z0v+0J79SpU6dOnaBWrVq1atWCjp93/Lzj57BtwrYJ2ybkr/9WZmZm ZmZm/i38t38f1n9Y/2F96JbRLaNbBmx4sOHBhgd/v9+NGzdu3Lgx/3g0D2ge0DwAThY/Wfxk8b+P +3Z/76z+/0P8s/VQr6hX1Cu/PZSkWbNmzZo1g3uGe4Z7hr8/7ntm7JmxZwZ0K9KtSLci+Z938xfN XzR/AQtPLDyx8ATYytjK2Mr8drlvyjflm/Lfxxl0edDlQZfhRfMXzV80/+P1/cPnm5ub2//vvbse 57djZLOBEJDqYWcHMJyeojOoXaRW8iKQ4SlLQL2d/PzpK9BizVkh3UD2NH0hlQOtPpUoAwwUN6SB IFXTd/IEJE/DfqknSI+1z7VYwK4FqDtANJVP6goCHtp5qR9IHaiqPASS5CpSJjBSjNYNBT5SndoI kLZ49Q/YCfohfpmhdhADRH91M/hPCG4bsh3MM9NaZUaBdsi6wtoJ5CRpCplACUeCbQ/o2srFlLVg 83RFCy/IHW/v4GwM3HBWdfmDa5M2zhEDTod6Wa0GPBWb1eOglGca74H0pfKToTEY9tJGWwlYzMFE gKun47y+CNCHhqZMcFR2/uCYD9p8McZRHly3HEutIaD96Lzs8gXphK6EoQwYu5kzfc6C7UlGyeR+ YHmVXjzBA7K+yU6I6AuFChdoHjgKlFtM1n8OL29n+sVvhbzOeW3in4HfFY/LvvMhaJp3hWK/gKs7 e10hIJUTCXJRQEij6AdSPS2YZWCoYdIZ/CF6RVhiMS+wfCuOigGQdD3m15dDIbiQ3yprITA09uyX okF2UPokmx9cXPx4cMoOMA4z1sx6Bp4llLaer8F8Vpuq/wqCWpvOVHkfxIfKXEkPAfs8egV8BR57 lMyoI6DecGUbv4Yqi6uUKf0YlAhpY6HzcHbQ+dLnJ0Nnr2pJLbpD2ZbVjpT6BV5YXl3IHg6peS8r CF/wOxP6a+Qk8An1OPLYAYYRpmGeKvz4aKfzwCm4tzGu9uVDkJmctcBvK6xrdyBze0Hw9/Pv7N0b imdFt/EdBdqI3JqaA8zNPPaHPQfdAf01ezr8Gn2l1bHKYE7yk32Xgrmmbp1/wz/erMRQMVQMhds/ 3v7x9o9ABSpQIT8x/EfaR7SPaB8B7Q+2P9j+4N+/n7ckb0neEhh+fPjx4cchKSkpKSkJ6o6pO6bu GHCUc5RzlIOT2SezT2bnDwHZmrs1d2sueHl5eXl5wY6dO3bu2AkLui/ovqA76Jfql+qXQhWtilZF y0+MFg5cOHDhQJB3yjvlndCNbnT7v5R/wvYJ2ydsh8Tmic0TmwM/8RM/5b+/L3Ff4r5EWLp06dKl S/MvIIrEFYkrEgcz987cO3MvsIQlLPn31f+fNWDAgAEDBvz22OFSpUqVKlUKvujyRZcvuvzjeP9q PTYV21RsUzEo2KVgl4JdIG533O643flxCxQoUKBAATA0NDQ0/NX5/PMvP//y8y/55TPMNMw0zISq alW1qgrPaz6v+bwmbIveFr0tGnKO5hzNOQqf8zmf/xflnzZt2rRp0yCCCCLIvwC8M+rOqDuj4HPH 547PHbCOdax7B5/bv3q+ubm5ub27HmcNkEAqgItcEN9RkLYgarBQ2gry+4S4LoG8Tt5jvgmOhXmF 8yaDuK6anAEg95SeSlVBbCGRQ0CkVFVMA+mY/EJ5AuKpqCx+Aa2p9r22D1hIqpQLkoVrpAN15Tq6 wiAVlZYbIkBL0AZLGkjlRQktFJQAKdI4FpRZ/ms92wBlPPzVASBX8alrsINZCzlpigTzAvM61wrw HhPYV0kB42Ovr7TiYGvoHGMZBhmTMiqkHAHL86xJb7qB+koUdhYEbSVb1JHgXGYf5vwSXJ+rt0R/ cAwWJqkciM/kYnI3UG7Kq3TLwfyVcZuhHfh97tXeczz4nvFJ85kAppbG6mZvMIz0KRzwM2hrtZXS G5B3ilLEgW6NfB8PECtcPRw6UCvbf8jJBT5VPjLVh8y7ifongyFtd1q99BrwIvnVmqSlcHTq3fe/ bwkbTx3pv2wTLPth65EfrsCPx49P3VYRXg5KHpuUDPr9YpPuO1BzRX/pM9DaaMkUA1N93RVdeTgb fDvral+4WTW+1+O2wHRXhvILeIYoY/xWgdnbs6jxEzAU1ocrVkiblrEh9TgoO5XphsPgOUXfqEBX yJtmme45AsIzTVLUZvDf6jNVHwfGr8ydc09D22U1JlTrB2oIN/JuQtnDxfr6dYATDc6FXD8Kh49e +eDcKag7s8JPPa/C2UG3C7/5BNbOXn/w0HiI9Y+bFDMBjMHGhl7eoJaVv7VvgapLS45uPRVS02MX 5apwMfdm23PNoEFaldyihyBgTKCr+BIw9zfucswBS0Vrr4zB8GzGizEJUyHGmtrtUTCcv/7wxq5T cGlUrGv3fLBHilLqGXAOtBbOuAaxi5L0yq9/vFlZlliWWJaAs4KzgrNC/vKgoKCgoKC/X3+xZbFl sSX/YbK//fvNN9988803+esfSjmUciglP/F477333nvvPVjWb1m/Zf1gxZUVV1ZcyV/+dr0Dnx/4 /MBfZUAbHm54uOFh/uu3Q0i+q/hdxe8qwozQGaEzQvPf39xoc6PNjf5x/et9VO+jeh/B3rZ72+5t C12PdD3S9Uj++z89+OnBT3/VI/g2AdvivcV7izcME8PEMPHb8d9V/f9Z8fHx8fHx+Ynq3/59u5/f 61+tx+H5h+cfng+7puyasmvK38ddv379+vXrocSiEotKLPqr417vp3o/1ct/Pav9rPaz2sO3g74d 9O2g/DsA+jv6O/o7cOSLI18c+QJsNpvtLz+Y9VfePgS54/mO5zuew/Kyy8suL5v//oN6D+o9+Kv9 /bs+t390vrm5ubm92zHOMuBCEc+BIDKwAQp7yADxQjuqLgMxXcxwdATDHJ+ZIYNB+UxpK5cHsVj0 FZ+AlCyly1WAweKesIF4Lh6J7sA1mspnQA5SbAQC81gvhgA28UyrBEQilCEgFRX1RUvgoTxAHQda F8rL20FaQU8xCmiQWSJBgzztec/7D8GRl7Ehqz5Y6r9ql/ohaK114Z7eoH1pyvA8D3nv57RVvwZx XhtrKAiyQdfDGA/OEWo1xysgU7pu8wLnaUKUuiCd9tN79YPUCzlSXi7khGdnpg0B2xc5K7KPgffn pkEe40CqIi+WS4LJX1mmew/k7rrTSmPQy+qvrulg66l36AuDaxvfiBtg3OCa42gF1FLKEgkiyvVS 7gz2O45HeRPA9LF+oTEalDgt3bgLckdnHs/ZAttWHnhx4QTcu5p+bW0t8DhlqFH0Lig91fnRreFm 7/vlL38KeeNsufZvYeL+HkNmFQVDO3ms0hWUFrqe2np4UCoh+ckc0I03lkxPANmleWfugHtzYzfc vAkpl2yeKYsgtJXO2z8GbJNyp+QdB+N3XneMq8Evx2O3cxZ41FYP6LeA/bzuoO1TMJ0KsUsDwTDH NEmNhyRPy5GEKpAd70p5/RJqeBVTW+8Bzw26fR7noXbH8t3uH4FrXe4etN6EqpNqFDQ0AEc/ppQM Aj9v095kXyi+sFyJmhmw98Xx5xuagu5TIlPjIesDw9MmRnD2tN4Vb6DQxdD6RapBnHfCibzecDbx cakbHuAbZD5jnA72a9bCKTNAO6jOMkwH355ehy0NwVUuY6brI0j72mk0zQDnJd007RhkdrZfyCgH uQXzyhtbAZD5R5qU+YH5gfkBSGukNdKa/B7ojG4Z3TK6QfDPwT8H/5y/fmp0anRqNMQVjiscV/jv 46W2S22X2i7/9f0f7/94/0cgnHDCYefOnTt37sz/+1vebmdNtCZaE+H1w9cPX/9V4txoXKNxjcYB rWhFK2i4qeGmhpvy338V8irkVchvJ1Jvjfph1A+jfvj7nt232/3tLfxmE5tNbDYR2MAGNuT3uC9l KUv/L/X4V+vPAhawgH/au55F4r+rHm+HXLz9/N6qbahtqP1XQzkCWwS2CGwBFx0XHRcd/zhunbt1 7ta5C7SjHe2gWPdi3Yt1BwIIICB/SMm7qm/LKS2ntPwvLhR+63xzc3Nze+tdTkcnkEG8kMJIAOkz 8Z3UA0RBqb3YAloETeR4kGZrxfMSQR4VcD/SH9SeoqW6H3Qj2MZiEKfJwgkcJEU8BmknE6VUEAMk o9CBiKCBHAgUE4O0uSCtphqPgBiWigNAZflrFoMoZVuQswO4oX/pWRhkVRkq94WcIs8Cn5SBZN3J Xhd9wbrBYRJfg22V4RfzOHD9Kv9kbQQGVfG2RIHpkOfH/r4g19GPkeaB5CfptFhQnFIz3WVwrVV/ MHwLpsI+35m/gYwoa0JmL9CVzh2WNRDCFhtvmM+BtYLrQ1EApB+VwrrLoMWKYOIhb7DFM7cq2Lpn NciaBjmjc75MfQbWxR6bvNuB/T1Xd1csiCFOXW5P8DhnjPCNBREtyquDQDcXLz4D4xj7kzxAaS0v c/qDroitX+4XEFjYp3BwLdCNef24XDMgTeuW8hWEvR9sdE0A5w3jJ68+ghdbHtW1RcE3GzYs+LE5 DD7RZXeXspDUKvFh9mq4HpYYeisCjn//wmveE/DZKr4OKAwZD1Kb2IeB0lC5Ly+A+GBpkNIaTKm6 muZOUOpMya/MVyCzUco+5y9gvBg8IycGStcRBVVveP1eYp3XC8GYKO3TB4L3cC9zgRfgUK3XlHvQ bFn9zEa7wG+mV6B/YXh9K31D8AsoubBAO90ueK1/dd4yCpqeq51SaDM8injUT74AFcfVmFvqc8hb Y//q/fpwrXvMxFfTwb9y0BWfufBUi5lzLQJabWu2tt9yONTg6qB7odCwUtFSehs8nh1f8mF/8Jhu Hu99AJQDurTHMgR30G+xNILkbrqS3tdBGy6meIaCtFq9kbsHZJeyjK0Q2M60TdQBzv6xZvX2Vn7p 86XPlz4PD3jAA2D/rP2z9s+CgQxk4F+tPzdtbtrcNJjLXOYC+/fv379/P3z22WefffbZ38e3XbBd sF0AutKVrhAwOWBywGTwfuT9yPvRb5fLtMq0yrTq99dDuiHdkP6rWTzejnW+wAUu/P3bv5XAaCu0 FdqK/2L5UG2oNvSvjt8IZYQyAvDBB58/r/7/bv9d9RBVRVVRFXjIQ/7qQkmn0+l0f+B/k7dDM/7i 7awvzWhGs/+++roTZjc3t3/kXU5HJyEAf5FGAPALMjHAHREptQMpgK+04iC3NFcM/AHEHrlw7glg iajAPkCvzSQceMxkDoEYg5+QgJaEyUtB+kGbpx0GcVoYtWFAR2Wc3BdEomgrJYC0mNPaUBAfKlHG FyAm5iVkXgetf27vuPog/eg93DsW8p5ef3gzGMRO70o+/cCRrO7QH4C8M2mtsvJAskt9c5uBY7lQ LDshU5dZI2U36FbKP0iTQPdIuWnwBMlfXqibDR5zvGP9NoMyK6+lnwymlbmR2YMg8HtzCeMIcIXo Wug3gRIkd1IOA32dk509wTBCjpbmQOBhw23fkuCK8Dxj7A15Zxw/+P8KaattZfQ3Iflb51xrJNiK p/bPOQraty67vT6YkqQrpktgWCudFzvA445cTikPxqZOlz0S1GUP+lwbAt72UjNKnAafLeHTnAMg eWHWXLsnOE5n9cmNgJxmifqiV6BMj6h6zYdA6Pfe5QpshP2rjq853hlSrklfWb+HFwmJMy7Og4Bb PkONX0OhLwMaeFsg1qW9lqLBYXFpbIfiBJ+rcgouroxZfNEH4l+kP8hbAGGL9PX8voKQURFrzB+D cZHcoN63wKfK2qQ6ED8hq8aTJlDQz+N45BQoPyvMWOsCxG94XSvhKtyenLn8ZTV48VFinZR1UHBq 4fCgrlDix6jTQdfBv7i/7LcJ/KsGrMv7EEQruZsuGQp1Lf1Tof6Q+qHlYzkJOr5q07rCXDg8cX9B 5QkYk0yzrCOhnn+1wcXXgscVZYvzZyhTodSl4G5gl+wXDIFwQlxuGTsX7CvlNubeoP/K2Ed6ArrS jvE5QyA01qdRgASvom0VE65Doa99zvn+x9CElu+iefU43uN4j+Mwk5nMBFZXW11tdTXw3+6/3X87 tJvRbka7GfkJyEXnRedFJyzdu3Tv0r2/HbdQl0JdCnUBJCQk6BzVOapzFIzsOrLryK756z0e/3j8 4/EQGxsbGxsLBecVnFdwHph7m3ube0N4YnhieGL+Q1inFp9afGrxXzqcObXo1KJTi4A2tKENRHaI 7BDZAUwzTDNMM8CWacu0Zf7+4+GxwWODxwYIjg+OD46HlOiU6JRoONHjRI8TPaB9YvvE9olw6PCh w4cOA93pTvd3X///Kf5d9Xh7h4Md7GAHmO+b75vvQ1hEWERYRP4QiLezvrRq1apVq1b5dz46durY qWOn/Hgnep7oeaLn/9z6urm5uf0j73aoBoCEigQ4pRD0wG4hUQhkG9/r2oAYJo3yqA/KFsMSZRWI x8JLnQ1qX3LU+yA9kVZq20CuJXYqHwNbRLqUBaKUsk2rDfJHooZrDmgL1d6yDeRm8ieSHrTzYqJu HSgztLXOs+BsIJqrfpDre63m5U9A1BHznCdBmRoxNtgLsgvG3UorBylXk3MzLoPaz/Xc/ivkTkw9 njIVnn+Usjf7DWQf0K0ydALlgLGRZ0EIeiF/YIyDAkHmoh49QFfOLGXPAvm0LuFVe/DN8psoB4Ft ghjuWgtSQ/1E79pgqGhc5bUb7I+1XnQDtZXc0LgJDJ2Mp4zTQL6oN+hNIIXqTI5vwBDv88hQDkyN pE8CJ0Jitrrc0g20qnYpYyF4XjFUE2lgrikqS9XB/EZeovYD5UN5nn47SDXvFY25AAEH/co4h4HP +9GP4i9AXHzig9cfQ848Y730z6F84dIHO9UG32lW/2IP4K53wrCH30ByVmbHaxPA4BusJu0B+bT0 iWMP+Nf2PubtB45H1o3SC/AdYtjumwY5qY75wgFBWeZThqIQPtJzd6QKSU/iDFFrwFA1aKV1I2TN Tzj79BeIHhocGBQDvXo1e9GrFRx5em3RlqIQOzl7xZPzkHTRXjpzCdwfmB13+SfIycn+xrgHAir7 fJdXHU5/eGJKfF/I+qnyTlcadPJt3j1cD0HrAx94fwanB1386WEstHzURCrvAy/mPO/0pgukLky/ lD0VdGUNYdp28OvhX8YnDTxOBC5RPCH9WVKG1R+u269NutMYXnyf1e6pAP/R+hPBH4LlkHPTMwW8 DumSbZPB0Uh8ociQu8vRNbMyeBfQOga/BzmXlMEiAqj0bppV21/a/tL2F7i87/K+y/vgYMeDHQ92 hDlz5syZMwfme8z3mO8BsofsIXuA42vH146v8x8y+0tP7N/0FHY40OFAhwOw8fjG4xuPww/6H/Q/ 6OGJ5xPPJ575PYlvp7HjOte5Dutqrqu5ribQm970hn5l+pXpVwa+LPpl0S+LwqzIWZGzImHv7b23 997OfzjwrX62frZ+tn/uGPwf/rNHsuvarmu7roWVK1euXLkS5nSe03lOZ9hcYnOJzSXgRcCLgBf/ l4co31X9/2zvqh5vpzm0X7BfsF+A2XNmz5k9B8bFj4sfFw8FbhS4UeAG9J3Qd0LfCbAwaWHSwqT8 Oxp7w/eG7w2H52Wel3leJj/O2zH2b+P/6fV9zWvc0wC6ubn9C95t4vwf09E5MQEmPEUsALu1RGCb NIJaQDlRR9NAeEoxUgqIMtJaXS7QXAoXvUDaIxZzAdgtx8lTQf0le+iTKWDv8GLvLU+QJwT4Fx4A +izTU4MKrttWne190P0QVq5UR9Bk/eXAk6DrSD2lMjgi3izJawTpj9OGvzwJuKKehX4H8Xvjk5K7 g/17+1XtAIhx4pgrCGzfWb/GBD6VPav7zYBC7QtXL5oKgXF+lyNTwbOj8SsfE0hxumxagPOadjrv DFi9rScyBXDTEpoTCTlb0o8nAUa9Ty9jDBjjTUfktqB7pCsmtwDpljxJ9xNIRykitQSppTglVQVd X3WTehyI1i7njQXPWM9B8lTwDPBJ8fEE19ncE1wHwwQR5mgK+kVqjO0omJ/aD6oPQT/No0PAMUBR FmYcAu3Ks/5pNyA1yllAbgL6JENbzx6gLLO0dG2C+H6mtefLA8EBl/PWgMcOS5XiW8Crie/HXhFQ rJHpWINT0MSn2s1q8+BV+bzGjzbBpvInSqzfCH4eXo7g82CrlLJN+h7uNLE7vb4CzwLajRqjoXar uqmPUiC5QNLxrF6QOyhnnCsHnu/M0V84Dmpzx3FjBNTbXPpF4/4QvjzBXqA++Bh94oPehzRTsjVh MHhdKDMx0gOym+SOiCsBpv6mG5Yn4Fpkj0vbBVu/21P92AAoYIiKCveG4u0i/AotAtci+y/qaCin lpkXMRael4498uYseC71/tJQHIwFzS29w0G/ztVedIcsIb101AfDY79iZcZAG7nk+PobIKdrZr34 SvByeopq/RZi5ezVud4gezJYPw1M9txS9h9B8vUamJMNZg+yTWHvsG39Z6I4a+isobOGQuW4ynGV 42Dn5J2Td06G582fN3/eHIwmo8logpa7Wu5quQvGDho7aOwgGBczLmZczN+HDQsLCwsLg1UrV61c tRKWlV1WdllZuPTdpe8ufQfSdem6dB2qVKpSqUolGCmNlEZKUCqvVF6pvPw43Qp3K9ytMKifqJ+o n8Dml5tfbn4J1w9cP3D9QP5++jzr86zPM+h6uOvhrofJH1PyLxpYYWCFgRUgt09un9w++dOjJV1P up50HaZ6TvWc6gmzOszqMKvDv6/+f7Z3VY9hDGMYsHbD2g1rN8ClS5cuXboEeXfy7uTdARaxiEXQ 41iPYz2OgfxCfiG/gC1bt2zdshWur7q+6voq8KviV8WvCvSb2W9mv5kwcsTIESNHAC1oQYs/v75/ Ox2hm5ub2+8l/ccXoxA1a9asWbPmPx/AarXbbTb+MqsGHoALuI0FCcRSPKQzIJ/nJ+k9oAuzXOGg faNutKeDFCc3k1uCVEj2NPYAbmr+Sn3QvtftF81A/Trl3u2TkDfy9LCDr0Ak6MJ9e4GhdPjLkEwQ xbIfps4HeZDvWu8GYJxepXUXL1DqSx/oOkBW3Jnpl1tASp+Xw+KWw1O/eN2TZMial/FSiwLHz+r3 WhIoNjXQ9hgMP8kGQwMIaxywMeALCB8VvSDyM2Cb8okuD7Rf5NHSaHC1JNcRDlS2Bzo/BbmLvrG+ J/gdjr5csCgkHH56OvYbkC7L0+ShIG7J00QrsFWw37QtBRHtsqjLQOoousm1AKNm0maCusG+z/oz aPPUr3gG9ifyTCzwJjbv06xBYL2VtTBtNviGGp5KJcE80d6VLWAaq5UxFAW9zfehrwBBYq+cEDBZ 1eXqUDg2pkzjVxkQ842840El8BloL+/1KWTuEScyNcj4QN2lnobCU70Sa56Fkp6hSoXjII/TT8n7 Faw17On6DRDQ3jRA9IRrPz8Pu7YCohO8x1dfCGnpb0a/ugH6x57OAoUheWuW952CULhQaBNXPzB8 Jr8ImA3cESdccZC2IeN1+hgYU7X/mG8Kgn6N3NgzEeK8Xq95uAKO17zdc+dC0J9xbDSmg1rOsdbU E56/fFMzXUB40UBv7TJIGabPvczg+77u+6IXQPvW1kbpDTVaVCpYawgEefl/6NkTwi8VuO/XHI5a T1959ANk9kst8/IG1Pevd6r8l2D3cxSSj4Lip1srLYfSe4p9EdUZducd3nGxFWyPOFFox3EI/T7I zz4C0udmVs97AOE19Zcsx0Eaq50TEoiISJ+0LIi6FNnbuyRMUnp/f+zbP7uZ/+/ztkd9VdVVVVdV zV/+9uHA0mdLny19Fm4MvzH8xnAYdn3Y9WHX84eynD93/tz5c6Bfp1+nX/dn18bNzc3N7X+6y5cv X758+V32OCsIBJApeSCDVE9cRwJpNtdZD1onHMIb5HtsljuBGKmFu7qCUlYa75EF2hbRTKkADGGx +gSkbpqvmAZSDcdJbgArvAYX/BHEnuzkzJVg3Rj7YeJo0KY72ueuBKl/SqfMNNClRZlfXwDp06hX pc+CZ1TVPaWWgO1QWnDSRxD0vs+8yLrgHGnQLLtBa20TzhTwW+FZLepnMN9XktQgMBlFaeGCvGXW F9mTQOepH2eMBf0m1aauAO9MpZcoBaYPguKDn4Npb9TFwt+CUtx/skc9EOUzN1kuQPb71iN5d8Fa 0b7B5gDdd9IO3WlQC0gfiSygtWSXJoC8QG6tWEC000bpJoI4IA1RvwTDYiVLaQUBs00TfDIgd519 QnZf0IU7v88xgbrG1t+hgFbdvMTnYxA4YnIWgGLynmFYB8i5r8SnoI3NKudZF/wn+tX2jIfKmWU/ jI6B2OlPvyreDJKGppUM9AXFQ20grYOk7bYuWb3AFOtlk0KBPfK0ImvhWWZCb+t1KNhCvl2nN2j1 crbqzoL4xhUdtAvUc7YT2UkQluvfolInsAbkZGZ1BEcdKZA8UPfTJ3cL5H3n/MhmgRNJ16aemQzm J+bDofPhatPH23+pBRU+LbgiwgHGcOsgv2i43vNOUlZXaHiwomj8DFIa51R6GgWZB60rbxcGrxve Z4PGQomqpQNrN4fiuSWWhv0CL648u5/QBUzDM28bv4Lcewmn425Byevl1kRmgHOebapshgLfRd4K ssPtareUpxVAv9/VS3iC6ZFSKHU/eH3uuSfhBegPmysokyDqquO4wwa27Z7bcIBxkC7BORCcI5VL 5jmQMMdx0fEMmPlnN/X/nQzrDOsM6+DKkCtDrgzJ/+GKDSM3jNwwEkIjQiNC/2oM7tuHEJtNaDah 2QTQp+nT9Gl/di3c3Nzc3P5f88d7nPPsdpsT0NBwARoGFJAiSMMJVCOOayDG40slkJxYZTtoV7Qx 9vYgXkoz9KdAmSclUBikonytTQRRQgRJBhCjHOtyvgVrm2uPTjwC6/XHHR++AVdta/G8sWCo6Nsv WAbDtBLDy30Hrln2r7KWgM/U6g9a1AS5pNzTkAf2xy97PX8DueNuzbjRHC4dSjfmbYM3WmrB9CIQ lez1jX8L0O1xdLfngGm09EbpBMZzpuL6ymCMIcE1FIKjCzyPHggBsdVXVzsPshyuBj0AyaXvo9UC 27PrK+9vhdwzsecTP4e0QrlDc/eCNdn+yFEOtIXM0HLB8cZxw3EbRHVprYgByoveWnXgS1eSthi0 MOdTzRPEUF2Qcg2YaCxlTAXrOevJ7LmQuS3JN2Eq5OTcqntHhsCHQWNDDoJni8BDYQtAy/HdHXIA rCe0BsZl8HCfp8veHiwLDA9c7cCwRNxTe4D23LpSNkP2Afu3qh9Y2mT+og0EVwHXjNxNoGZYY5w7 wDbJucrWFHR5epfyDWh3nQ3svcB1QX0oh4Ghuj7OOAKopHQS/mA8ZBrrfRA8Hxh6yz1B975pgZgL jtLiockbVJuusxYCSphuoZwKgZt8TznPgJfT76DnIqi4tuSspuNBee1K0QrAo5gn/Z9chcC0gFBz Y0honXDr0XOoX6BhSM1fwfXK+nHwbgjeGVrP/BC84zy7+ZSGvHT7EIrB66uxStZV0I5bXS/PQrnM qnMqZsKjOzFLXnWEWN/X1eOMkPJxss+zwhC/J21v/EegWHxy0jXwNJnmZu8HeWxGX1c/sG/0CHAN hIDq/uP9Z0PaAlffnClgnSj3kWtAbljmgswk+P74xI0X0v/sZv6/V/q89Hnp82DJ2SVnl5yFC+Uu lLtQDrJ7ZffK7pU/33XzZs2bNW8GI2uMrDGyBpg3mDeYN/zZpXdzc3Nz+3/F2x7nP544O+x5tucg lZDCpdIgHog3Ih5IJEWqDqikkw5SF4JEEaAqy5WjIH4SI1wVgCnyDOkRSINFpJgErqUs0u0Huan+ uf4WqNNj3hzbCy+2b568KRrSf8390LQJzA88P/EZA/69vaINVjCLgF+lNeDxsNrpBh5g9irbpWYR kCOJV26A+o3NlH0PXCuuJ9/8AZ5qTybc7At507RM8St4/yjND7kF6jmWGVLBe5r3Lt+i4BFtjPLo D+aqni884sDsrJJYfDzwY7DDNwrETls522XQfWeZlzUH8oIeHnupg9TdsZWSYiDHy/qhtTI4e0jt NAWEhZFiATgeO752fA+OoS6j9SuQpxMsigPntIv8DERq0UpF0PZIfRUNSDO8UjaCWlUMJhlsF23v WUZC1tA3j/O2QubtzG62Z6BsDV0eMAXEDJPw/BEynY5d1t6Q/tqVndED0nKTRUYpsOgyp2StAVus pU7WY7Afc6x3ZYB+E7fl86CXdS0NG0A+rx+o18AUYtQZYkHaKNuVOqA49MX0M0BuIveXq4A8WR4v ToOYIUrJkaA1VTMpD85PtK+0gqDVoYXqDeKetk04QB4vT9Z3A2WKsbgpFozFTY+kOmD4yMcYvA70 zXw9/GPA73nAjYBo0BU2lzIuAefzlPgX7SGztvWDx6FQ1CNSp78F6jbHPY9a0GhWw6iBDcE8XtfN 2Q6c92WdmAxya0dh7yOQV+FNxUdNIO+V9LHcHNitXZN2gGoSXYxd4GHp5x0u2kBssno+3QHZvXPH ye+Bvp9pg2sEWAuZb8XNB8Y6PpeWgtXsrK18CqZf/VrqYuDVw/S6GUUgrWFyTy7DXsfS1udq/dnN 3c3Nzc3Nze2PeHdDNfKkAGk6iKria3EIJE+pGAagl7jDx0Aa4+gKopyUIxSQ6gqLqAOEKaukwcBR bbC0BkSiKKR9C/IPynNpL+g+y14d1xAeHtii23oNrn74fKvoAYUfl69b2QSlk+oPrXIBnAFx6x9f AN15z/XyFdB3Dc+I3AByuH6e12egOV037EtA+dBQzXMu5I20W/TTofD1sGbRrcB6UBuTmwaJO19b HdVBDjYfMK8Dw0Z9mtILDEV925m/AAYbusiJ4KqZ80vWRdB/6bPN+AQwZ5zMzIHcHY9evigDebMS v87VwNlLPSMSQXhKPkwH7Yg6WlwB7QLNtHCQjsiV5TYgt3AFaJ+AGipCHaVACpMOyYdB7iFPlFNA 7i5S1MqAXvucqeAooJvlexjyxnj+6nUf8oZFr3eWgrQavmXyxkJu7ZyF6Zsg44f48TH7IWNb4osk A+Q+zW1lCwE5Tr6tbQWvRK+x3uEQeMPvpv9sMOV4n/U6AMZdHqGmpaBbYYrSbwWdIq+XvwNtrYjj Jogrwip2gxRFGzEVdKWkz6T9IF1Qjkt3AKM0Sz8TlAh5EZEg3xLLpGaghWm9lXugtRafuFqDOs5e WLND7i57lvUO2JpbZbUy5F1/E5TUGsTwtIvJrSGn0Jtqfk4wfehV2y8EvD8wVnakgv8Kj1n+LeB2 p6en7ALqqNEWKRye/nhnyYWXYHHIvT2WQ4HloRs9o6H2pponGxWF636PJ8WsBesJo1VbD0ULF88L +g6M6+VJXhbQpalJZfuCX1nfddVqgcfZgK6BX8DJ0pevbVoDakrW7MSuEHjDY7Y0CjwKyrFVvoI7 P705fLkIBDYL+cTUGtSNoqz97ewVcX92c3dzc3Nzc3N7F/544jxYfM8GoJ50T7IAMTSnBfCQHuID 4EfOyGtBRLFEGQRSXe2lSweUFl2V8sB8KZtfQMuiMaVA/6M+ShcPuV/e87gaB2nN7+WkVIaCjyvn 1k2CsuNbdqg4D3w3hkb5NgRnDf8XxVaA2Ko9yxsOrrY5vbMbgvFS2GbJC6SmooqcDVpzxzz7GRCV nP6kQM5Rx6OgPWDbnH3FWQ2cvbI6xX8L2h7bKNd8sJRSv5Q+AEOw0lDeCcYBZRzRXiD5stV1EVx9 Ys+/soLjdPKJjHmgbcs2u94DV235mnwFXBOch7QKIDJcR1gO0qeYxAjQNZL3yN3A+ZWWqrUHVkqq 3AWYqd3jaxA1RQmtCYje6mbXp8AD/XjPmZDdUJrn8QEk5zjLaRZIE9bm2R9C2uLXO+LLQfLBV91f 7oV08eazxA6gXVB/dHUCz8v+GwMWQbRnsaKFXOBh9lO8boL+O8Mp5TC4Trg+1azg6GX7yqqDvLSs H7I6ghiXMVpcAXm7mCYZQdtKR7ETGCvHST6gK6As1G0HQ4rioxQBpZSSo2igMyu+8k+glZT3yItA bqckcwt0ubrNkhEM1XULdeuBjebSeh/wzPQa5pULWnElQ64GzkzXclEd7JnW+q4qkHcx9/3cUmCr mro/uxWkLlTmGo6DebXXJnMalBhbtlGdcDC+8AvwPgTljxY/EF4HguPCjof0ANN20w3DYDB2MwwX M6FSYLMV9b3BNNvcXHcQCGQFdUHpT7i8DQwdPYwBjcD2RrRS3wffquYfjDOgXFapLn3GwVO/F9nP wyCvrUP/6hh4hQXqvOtCoabecU8WQHYxz7ys6xAWUaC+VznAnTa7ubm5ubn9r/EOepz5VE0F3heH 5I3ALIpJiYBdWkkP0HaJsaoOdCt4o2sMjjfSNFqB1EGcEUEgd1X6yONA18o1RV4N3P6PsK5aKRmp taBIz7oda34C0SNHlPggFKRnXhUMdsgr/aLBg7Kghtl6Z+4E+bkc64oC09ZC28pPAq2ra43ND9ig vynNAK3lq+2ZU8HV0L5HdUHmzzmzcjpC1oE3M1J3g2urNcDWDYL7+Fb2nw5B2wJaeIWB8qNSgAhQ j75enJYGYlrh2JAVoGw12nQ+wFkK6Y6DKCwVcEWD0pjJkhGUw9pceoNklF5IU0A6IjoTAaKKFudq AMp5aZYwgLJamir/DFpZ6ZLyAYhNhu0et8E+UP+5lwKpn6qjlFrw5uu8LRYfSKqX8PLFGUhd+fjN w6OQeiPlQfIJUNoaJxvzwP+biKLhX4LnyuC2Qa1BTtTHYAZnZ8t1WyBkP0t5mhYJju6OoVp5UOrL lfRZYPrEbDO8AY8Az21ew8FjhmcNz/Vg/NRDMTUBQ0/j18ZM0G3XL9CfAp2sVNEngvSRcgBvEDWE KvJAGikMWjfQLqkjtbugLdeOuRTQFrmuOvqD+NpR2TUMtIIug/oA0Dv3OfqDLtX1vmQFA/Inuufg fdvLbJgFrh3ed41J4GzltGnxkPuRJczZDCzb87bmjYen+y68f7IS2PMiDodfgRKu0BH1GkG4Lmpq 4GegrRcBTido11wDzE7w6uVZi+OQ2z/X1xoC8jn5Q/kSZK5N7235GEyDTMNNDoj8OuAL71xQz7mG aAuh0nvlvyq5GnR3TasKlobL/e6EPzsCtixlkWMKlAkpsaX4JrhxICZr7/eQe9ix/NFy4H/Qr8u5 ubm5ubm5/TF/OHHWddMPMA0AtbizsLMFMEKaTX1gAWuluSCn8JG8FRwtXK0cRnDEpsx/MwAMYcZk kxPk9QEBAXfBtdHh7agM8jOdKtUCw6pSNUtMhOCe0XY1B9RPvOxefYDJ2XcS34Bilbs5vwL1kXVF djdQwkosq3Ud5P2m6b5jgDpqQXUSiGC1rL0z5PV9USepCNiWZ39iKwCu1rZkbQpwTTrtlwOuE1JZ VYbXLxMOJsWBK8CeaDFCWJHIEgWHg5zs6u1cCvpyTBQ7QZSPTA5+D/SRIQu9z4LYbIu3TQf8cm7Z N4MYqp8kroLukXqBxeBq4jigDgIhSw+pD2IQi6kOuoO6L4xdwWY3rvDeDllLDcfMEyBFs110JEHS e6+7xE6CpIr319zxhmTfV46XU4BbploeoRDYpoh30algLhtY0q85OEo5SznHQs745IdpQ0Ctbqus poCpqXmY4Qr4fhvo6/c9+K0LaRh0BfxGB/zi3xd8p3pP8+oL5iWehU1dQTdD/0LXFJQDUnFlPIif GCKWgdZPDGIpyO+LICkJxED20goYLTqLDaBeUadq7wO76CSaA6e0Q8ICrp+069pOcDVVt6tNQPPU bqiHQCQ6RzqvgrO9dUheMKid7cWt98D1k3rMMQlcqeoiMRUMXXQPpCpgWuS7xdgHfCr5CJMEeT/Y C7iGw5tBaUNSAuGn4Rtb/twX/C8EfBC0DUIWBHcIKg1V4ioOKvkrlCtTdk+hBZD1Udpu6T44Bkv3 Xdfgza3Ek2lLwTDLEKT/FSp4VvMvGgXSRt2ncjtQrNp15xooubior+Ew3Hl+t4PjQ3jy6s7+O9Hg c6bCjLJHoL5adlPfw3Dq0aVPd5cB4L0/u5G7ubm5ubm5vRt/OHE+U//C6EtjoHb5aver1QH5mrRF JIJYKZK1W8BxaaScCnIF6WelHHisDEgOvgbJVRK7paSCbyHTUvslMFw0lJY+B22t6skmMHQJTSs6 BtQr2b1z1oKo7tDZfwZpgfRSOghky12M8aAfUbRJ9a9AvyxIRN4Ajttv5t0FMU7nqX8O9M/7VMsG 5YZ9ltBATlOeGHeC51bPZMNN8PL0bhjYGJzZ4tOon8DikbQ0vizEf//0wp0tYN2WnpZaF8J+jg4q 9AaMN60dcqNBWZcWlm4AXaRPG98HoPVxPnHdArmlXElqCob3RGM5GuwLNKHtAF1NZb+yAFwNtbpa f1DrYtBtAVeC31G/4ZDmdEZqEsTPShmW9C0krn6svzMBXl19GPJgNVhXu2ZqBcF3fXSJAm3AuDPw U59fwOnl3Kh+AalN4ue8ngbyE/Ua4RBcP6h+YBEITS99soALQhtGrgz9Anx/8vf09QWPU+YJpkww lNGvVDxBb5DOS0GgSEJHVxBX1WaiElgfu2aq34P2WJutNQHpufxINoB2zfVSnQiuwZpVGwFaebFf tACliWhJAZCGSY2ksqA8lFeKPqBUQUgpoFxkjVIDJOQcGdCV0wvDS3BMNn1tPgSuvmoNVwiIdS6L wwr2Oo5ptsHgKm8tZa0JjmH2Rc7hoExQJS0LDCGmyvJN8PjUlOv3HljvWbs4SkF6/6wS6R0gpVi2 b0Z5yJmZa81YBOlXUyq/yYEGtxpcanADDD/7PvUrCEFdg7b7ZYGrpjpKnQW6KL1DcYDa0pUg4sCl uErIv0AaKcbc7yB3VOalxDOQ5Uia9uw7uPA0d2dcHyg5vkRkaTvU2Vi2V5ONf3bzdnNzc3Nzc3uX /nDinNMmI9peC3RjlGypBLiaqxU1P5B7SR+xH8SnOMQskLrJ9aWroDTxlDwiwRQQOMl3Eji7Om45 48Czmfd4vxxwvVDHq2tArDXfCBoKuixTuL8JXMWz36S1BP2XpjLmq6DUCB9Wej5Iz6mvLANwfJRX GcRnykDlJYhyUi18QbTWnmrjQeyW54qKQDCfaB+BPFr6yNURvEbI5awnwPmRFuHcDcZt/om6IuCK sYRHfAdv9IkZsR3AecyaElMTgj8PPxw4Bbya+d2J+Ai0KGsf+wcg5kjtlQfg3Oj6xnkZxApthbCA dEcaJQ6BPNDZzfErSA11X+iLgL2055igEIgLtT+yxUHcd7EfPe4PL7NvPrmxB5JavObldFDi/Xv5 NgPfTyLLRsSBUkf0ktZCRsnXJZMdoBuj2ZWFEPlN5NzwClAwvsThwp9A8OYCyeErwbegb47XCTBd 0R807AR+Yq3SGNTWqqq+BPkLrb7QwDWJ0dQE+0x1vVoAtHEiBAPQRPKXvweDRaeTC4BuqNSLPNAC pa+00eA661qndAXbGPW+WgqcWcwUR8DVVf1KHQjOzppRnAJls/ylFA16p3RI2gJqae0JB8EuqSmu H0GUozqjQIoQ26QqoFzUbTB9B6Kv9KHRDMoA/ROPRNDnuS7YPwX9Cmtd631wJdgz7PdAV0996GwD +o7mUkoWGD4zHfXxgJzNeSn2YfC6TeKu5EiwjbdPdXYHYo0NTV3Af7HXl15lIScrc1tud7DWs4zN /RnsiY56Dk/IG2rzd6RD3kvr5rxK8Drlzd6MdmBZbemQchB8x/nOUWaAtYQ9XG0Jd99/WOXeN5Cy O7Xx68JQnwbU+wPt6+0PeOTm5ubm5kKDTQ02Ndj09+tlFsksklkE9nXY12FfB+hj6WPpY4E11ddU X1Mdhg0bNmzYsHf/BbJ69erVq1f/6/H/6PZubm5ubm7/nf5w4nz95+fanacQnfCwdeQqqFKqwugS kyG3pG2y3QeURmwQs4B1JIhD4PrCaXHeAL9OPsu8dwK7xCnpS3BkOxu7PgdptKRwAqQWyjmlIohA lumegG6TT5LJCPjSRNKDdkjtp1pAHkAZR3NgmNRHPwC0B2Keegbkg8Ror0FszSuY1gbsWzIyU2LB /tJ6JiMdaOZypbWHR6tflX6WAGm1k3omdIACc0I+D6kF/pv9v4hUIcvL/MqzBGT4ufpJD8DV+XWj jMXgPcwyNMcK/pWCfMNPgHGHuaavGbRaanFtNUjBIlSygvTU0UUbCfJCnc23JViO+7b0fgCPv8hu lB4JL7LuHb2/Bp5/dGPH1TzISbE9s5QFj7jITVF5YOjoN9DzGlg3Zl3JeQZa8dxa9u8h3BbRIOJb KNq7bNliCRAVVfBl1FjwPuE7zOcYyC2Vw/JEkD6XJrETRKR6WnsKopPW31UIxE4+py24qotdYiSI srxkDkivZb18CkR3zVsbCdrP2mDNCK7y7OMS6A5IL5kH+jpKGakViL1ijOsAiDKO06IpOEPVceoF cGWJu67CIJ5pN0gA6Yk6mf3AUMKlbiBeCglvEGNFtqgA4o1oJgqCyBMTxBUQW7SpWl+QvsBJf3Bd FW8kHxD9la+NESCX86hgSAJ9hOGpfQzI9xy/2nqBTu/YYK8BSoBjm+Mr0O82dzR4Q95D3Sh9bciw Zv+Q44QDTQ7pTlUF3Wf6M+Z1oD+lXFVGQ9747DOZbyBjbvrN1GKg1pISnLdB89HKu1LAdUWs0S0B wxXDLqkKuEI0D88A8NP5l/YygbSNFmo9SL6U/n3WRKAW5Vjxr7evYguLLSy2EH6e9vO0n6dBvUr1 KtWrBPIt+ZZ8K3+9tz+5XWR+kflF5oNkkkySCQZfGXxl8JV/3xfI4EqDKw2u9Odt/+8mrolr4hrs bL6z+c7m0C2jW0a3jN+x4SpWsQru3Llz584diImJiYmJAWdFZ0VnRQiOC44LjoNGjxo9avQIDPcM 9wz34HrV61WvV4Vbt27dunULZFmWZTk/bMnTJU+XPA117ta5W+fuPx//txwtfLTw0cKQeTzzeOZx 6FakW5FuRf754/W3F0LuCyM3N7f/bf5w4vxiQ2rfJ+fgdMFb1QMsUPq9ktsjB4EuV34pLwLxvWgn lQC6EEsjwEEMLlDPaEZND1IDaSEjQHoof8UEYBc5UgCwnLKYgAqig7YKxGJpsbICcIl56segu8cx URHEQSzyExD3RUenN+gX6I96dgKnKa3Xi/6QM+hCsVNfgFo4uV9yFxA31NN5leF50/vLn5WGG589 /Om1H0hb7A2lGPAVpcd5Fwb9C+V08vugTsXLuywYnH5K+K+gu6orKp2HrB2uo+ltwbE+MyDFAv6e zvXWoWA+YVhnvgNSaTXQMBp0p72rBC+A5PpeqQEL4cGUxDevdfDsyjXpal947Hnv8PU0cEQpToMO fL4qOLdgLsjpumBpEGQvf70y7Rb4Kh41zE2gZMHakZUvQKGzpSYVSYSgZQFnA3eBfpL+fX0vkPaz mpogFqmSVglEupaIE4RVDBFmkFW+Zzko01ggaaB+KW3mY6C1tlz7FsS3IkiLAH0N2kh9QRyWyjID 5HLaPTEYxCXxNdtBHKSv1g3YKgqI1aBUl4uIdDBNlYKVPLB/rh4WNcAlYxQyaEu0ReILUE+pn2qP QStPIWEAaos9mgaijZgh9QPSaM8OkPaJdowF0URsFa1B/IBMAKjzRS0RBbQTqVIyaG3lgQYvkIKM +5XZoK+gVNBXAHFQei9vEjDRWc/1C0jDpNvUBuWWsss0A7LOWQrKH4P9tjrBeQ28g3yPeMeAYZ6n 6lER7AckVfkBskqn30w2A0/ke3I1EDvFVDUArF1te11DIPmb1HO5o8F43jBYeQVenXyamBeB9lrs UX8G/mDS6uPj4+PjA34T/Cb4TYBXjV41etUIClKQgn+13tvEuf6J+ifqnwDa0IY28P2t7299fwuG 1RhWY1iN/ESm1u1at2vdhie+T3yf+ELLKS2ntJwCxxccX3B8AVjLWMtYy0Dh9MLphdPhtu627rbu 7xOg34pfcVDFQRUHwYvmL5q/aJ5/AVCtWrVq1ar9/fZNApoENAmAGzdu3LhxA8RQMVQMBXWFukJd AWXOljlb5ixUWlFpRaU/cCHyez3b/mz7s+3waNOjTY82QcaXGV9mfPn7t388/vH4x+MhwT/BP8Ef ukzqMqnLJFBqKjWVmnDedt523gaXq1yucrkK1Kc+9YHsk9kns09Cy4UtF7ZcCAVmF5hdYPZ/Eb/F 4xaPW/zz8X/Li8kvJr+YDEPTh6YPTQeKUIR/IXF2c3Nz+99O/qMBCg8x60LHwyvx8kriFPjl4v5j Z56B6bDBZv4StJqiOcuACBJ4CNKX0mJpMaDiwglikJjKDyAtF0elGiBBBINAnBBFxXsgTZY2KDEg bxDHtd7AbUqwErSS0kLda6CxttPlCdpOyY8xoJa0NEmcB479iaPuzwRr/Vi/mMOgfeKKyNgBZGud 7UfB9JNXWdNaqDukdqNKHlA7pomrgQ8YVwbnRlaG1Ha2dZ77QHJ5LfDfBp4vzF4ek0Cnen3qtRE8 q3hXivwaxEqlfkAAZH2dVcTiA5kfWM7l/Az2hx6f+lSBlNfeHfyvwsNzrxu8NEDMurMVTj+CmO03 F18LA0dP4xGPw2AOjzwa+h64ajocdhWs771pknEPinwVbQrZA41rtJhXtw1UOlvjVsXvIfpGxIjI MuD1wjDFaAWlpXZWWwO6I6K41gJMS+Te8mrQV6Wo/C3oqovPpWogxYmWfAPsU+eqwaB7TzurRoIS x3ztERjfU7rKH4FeZrcIA+kz127XLXBscA50dQPrMOcPrnTIG+9U1LWgjRMrKQjGh3q7+BR0+6WD riEgd9YaacdBmaadcV0AJUjIojjorsq9yQXlotxD5IJ0XgqSyoJ0RRoraoMcRlPREXTvywnSQDBs lnXyY9A3kWKlqmDsLa2VOoBhsNSDYDDMk66JjqCESj2lkaCc12UZL4JB8njqvRLMe8ytPd6Ax2x5 s1QGzBulb9R+4OvhVVNfFbw/0OUqmyC7Ump06gOwV7ZnW49D6O2wKaEPIPJMRPWia0C+Iy6b+oD8 CWuFJ+j6K7OUy2Ab7RikdYaMDlnTLfdAvaW2UbuD7BDznZHvrqEWzy6eXTwbnm17tu3ZtvzlWSey TmSdAOdA50DnQAh9Ffoq9NXvj9ulS5cuXbrkJ1pFM4pmFM2Anj179uzZE3yf+D7xffLPlzdyVuSs yFnQIbFDYodEuP3D7R9u//Db698bfW/0vdFQdVXVVVVXQY+sHlk9sqDTm05vOr2Bq0OvDr069J8v h81ms9ls4LzkvOS89Pu3837k/cj7EZQrV65cuXL//H4fbHyw8cFGqC5Vl6pLoBulG6UbBVI1qZpU DWrUqFGjRg0oc67MuTLn8rfLOZVzKucUeI33Gu81/t3H/1sns09mn8zOf70/Yn/E/oj843bs2LFj x47BpphNMZtiYGvjrY23NobjRY8XPV40f73f+zn83ni7d+/evXs3pEanRqdG58fZu3fv3r174cyZ M2fOnMlf/vZC5WTxk8VPFgeHw+FwOODw4cOHDx+GLd5bvLd4w8GOBzse7Pjb5X574Xdn1J1Rd0bB rim7puyaAs8nPp/4fCLseL7j+Y7nsM13m+823/zyP2r4qOGjhv/8eeLm5vb/nj/c4ywb5DUeg6HR zkrGerehhrlKRpEOYHU6ntjbgZwgn5SOgjSK7SIXxCHxXNQCbnOZi8AX0jTpMxDXtTraK6CklkA2 8KN8SMoD2vKROAHiMdWk/sBjborJwBZyxXXQUqUBkhHkLa6FqT6QNuFAzfW/gma99OX9cmD6ofam GjVBFPdu4TsYpOT7PW8B/kuNFwxLIauqvrx/c3DsNOpNSeBMc0zz/Ba0CFM9Q2swNzBoxlGga6ib 6Tka1I/5zrkTDE1lH2EEw0OffgHLIS/A8tTQGqzLTLWNDSDvfEDf8B/g7qFX9+LLwL0Pzjw444Rn 5kezn5rAWdbnqsdg8CweUM3/Y3B2yYm0lQT9Vu246zZUWFG5ZVmg1IiKK0vGQ5QpekWBk+CxVNdF Pwlyz1pGWtaCvYcYIb4Bw2ZdBcNxMM3WHzCUBscUe33796DkYcQLlJlyAB+DZtWM2g7gF2m6KAaO cq5AV0/Qpojz3AFbKzHQtRpEgGoW3uBqocVQHuRn0jRtMkgFtAJiAzhjRTGpFig1pUKiMBhW6duK dJDTGS1mgxJIX/EYlFz5uNQS1DaisTQYnFXVJDKBamKIdAekHWjqMlBG0pa9YDikayIvBCldmsA8 cH2nxmh3QZqlQn3Qnor3RW3QGvJYMoGcKTUkEdSOXMYLxAVxjkyQvpVuyZGg1jcEG9aB1pUB0gdg NNke2KyA3THd/gPw2HxDaQYii3bsh5wi1maWl2DELIwuCPmwwMqQhSDtVXoYPoM34+M/eLQQXLcI th8EdYF8WKiQZ847pbYG2y6ryfEAPHKVoXLEu2uoRb8s+mXRL+Fq6NXQq6Hg+tb1retbeDH6xegX o6HowKIDiw4EhjOc4f84XpkyZcqUKZOfaL3Wv9a/1kPjxY0XN178V/vtUbRH0R5w5s6ZO2fu/P7y RuyL2BexD+QYOUaOAXW1ulpd/dvrdyzQsUDHApC4L3Ff4j64X/d+3ft1IfVI6pHUIyA2i81iM1CF KlT5x/tP6ZzSOaVzfqKlu627rbsN3fK65XXLAw8PDw8Pj9/ePmR6yPSQ6X+1YDWrWf0Pd/sXGd0y umV0g4RVCasSVsHhjYc3Ht4I9gv2C/YLEN4uvF14O2gwtsHYBmOBxzzmcX7ifPra6Wunr0FKdEp0 SjQE7QraFbQLGo5vOL7h+H89/t9q7NPYp7EPPOEJT4D2Ee0j2kfAsW7Huh3rBp4xnjGeMdB7Xe91 vdeBlCVlSVlwpdGVRlcawfmy58ueLwtNnzV91vTZbx+Pc33P9T3X9/fHi/KJ8onygdftX7d/3R78 r/hf8b8CeXl5eXl5YO9v72/vD2SQQQYk7k/cn7gfot5EvYl6A9euXbt27RpERERERERAq5xWOa1y 4P5P93+6/xNcGnhp4KWB0GhLoy2Ntvx2ud9eWK6vvb72+trQNahrUNcg8MnyyfLJyn/24O2FZ0lK UvL3nyZubm7/D/rDPc6O64anCRZ46hn32dG24F3Cq49XZZCviCnaLpDs4rz4GkRvcQkbkMtLngMP eMpTkL+TLkujwFHP8crZE+w7nKWd9UHW5CryaxA7xFIRBmSTLeJBqowfmUB58YwEkD/RcMqQl3ml +OlAkBpkZOdVA2lkmTaVXODzSdO7vTdBsKXtocHvge/QVtFdS0Jwn6q9K+VAaFrAau/3wPgpPylD Qf3QdMpDBWWb7qopDpTduldmAfYrmpc1HNTejk/Vs2BvZ59kKQq2rpaWmbvAq2TgyOAa4PIqdL60 DPcNr796XQti1pzdc+Y+POv+qH5Mb7Av8t5jfAymxz5V/XqBs0tuSF4keD1RpsjNoOaYWq+q2qHK r3UXV/4FonpF9ShQAfYYDtY4+AJWp228+9MK+HH0ti1bv4ZVXuumr1sFJ++eP3zmA3h9MvlM/Pdg OGzykRuAbNad0E0G1zXttPgMOC4v0fUB+Y1hnH4k6N83tdBvBI9jhvf0w8AwjPHSBZAeCG91FpiG yLniMhiayl9Iu4CPxFVRHNSGakHXeLBud33tHALWb2zzXJVAHirqS+XAJ8v8SrkOpvl6nVQQ9Hpp sloBDMWlqepy8Kip/EAUmJfKA6S7oN8kR9MD1J3qE3UHOL51aq7r4DysJmmdwTWJbK0/uObSVosD pyqGuTLBdU0bpfYAl0VdLLaDq61oq/0CjvaigUgGV7IYRXGQX+k89T3AsNn0lYcHmJ4Yz5o2gcdy gkVZMKWa1kgdwDvElKBMhZyTGU3THoFlguVYTn3wOxwy1ucAFClY8FohHzBV0Z/1toIhxjjdIwu0 mfJwUwXI3ZA3QjQA1xDXbvOMd9dQjT8afzT+COEJ4QnhCRAXHBccF5w/RKPY8WLHix3//fHe9lC+ pV3VrmpXQV4jr5HX5C+XhknDpH9hbOrfjsH+R972DD55+uTpk6f5Pb5VhlYZWuVf6Gl+O7Ti7VCP twll7qLcRbmL/vDH8Q+5XC6XywWW05bTltPQtVDXQl0LQd8zfc/0PQOBsYGxgbFwoviJ4ieK85cx 0W8Tv3r3692vdx8GLB+wfMByiOoc1TmqM5w6derUqVP/Qvx/0qtfXv3y6heoPKTykMpD8i+wuMEN bkCly5UuV7oML39++fPLn999vLfH4W3inHIo5VDKofw7GfJIeaQ8EqznrOes5yBxVuKsxFlQoECB AgUKQOzk2Mmxk6FU71K9S/XOL0dpS2lLaQvEt41vG9/2t8v7txeWEbMiZkXMgpO9TvY62St/DPrb xLlli5YtWrb4959Xbm5uf74/3ONcvk3U1tqTwCDkB1l+8LpEkkdSSyhevtimwrchu3pup5zRoD+m f6gfDXzKRqoA/QmiLnBRXOYaZHlkRmTvh4AZgZ4BFtC6izJaNEibpQhpNJAhLos6IO4wli0gbZdX yp7gappVNkUBa4O48ITr4ExMD7TehOCL/VcM2gH6s8E9Im6Dc5Q9zW4F46aCR8ouBTHAPtt+Dfy7 VZvllw4eUy9setIMXtaKPZ+yEmxjiZZrgauqI8B+Agx7Dd7CAvIb5zM1GqT96nH7UpAqCiFtBNsJ rwOe78PzV8kPk6fAI/ulTy+cgKcpj1Y++Byyu3osM14F32SvBl7LQU61NrbfBh+bRxvTdIh4WOxo 1GAI/bLYyQLfguG2fptxONx+cO/I/Z5wr1lM7rO68Coh7vRrOyijlE36V2DLUl84voQ7+pj3nmfD wW+O1j7hB1V3VrKUHw8lGxV7WCQPlA90hQwNIGlwUl5SPQjyCtoXtAR0TcVTfRcwz9KrqheElA6d E9IZPB+YZ/hXB8eH9kuOz8G5yxXmOgDOz1y5WhegodxSmQ3KRFFXGgRygO5jnQXSk3MPWkpDVuNs fcpJ8O3m/YHfcjDsMC4zpQL3FBPfgesTVyXXT+Cc4zrHRlC7iUFiPWgfia9IAbW/+AxvYC9PtG9B +0QgLgJWMrgLfMxY0Rrk2mIAXwGe4ohoBqIID8Q5kMoJVZQDdZh4LHaBcImzIgbkqfIr6QRIhYwl TMPA8L2WyQnwGmJvZT0KIsVQjA1AYRGklIHsO2mxKevBs7n/EJcA/8UBHfxKQ+hRcVZaD8nHkq68 OQaOVCEsyZAZkF3EXhm0l/oPPPe9+wZbvFfxXsV7wc01N9fcXAPqFfWKegUC5gfMD5j/r8eNaB/R PqI9PJn3ZN6TeVCa0pQGnm5/uv3pduAMZzjzr8f/R5KSkpKSkqDnyJ4je44Ec6o51ZwK8fHx8fHx wEEOcpC/JJj/qGf97YWE1Wg1Wo1grGOsY6wDIadDToec/vfV4y3TfdN9032odrza8WrHwVDPUM9Q D7jHPe5BZUdlR2UHbBi9YfSG0cABDnAAGgxvMLzBf1GvCpcqXKpwCW7KN+Wb8r8Q/58kVolVYhXI feQ+cp//YoX/PP5vH56kAhWo8O7ihcSHxIfEQ9rjtMdpj+F1yOuQ1yEQVjKsZFhJUA4ph5RD+UOX jFuNW41bwZRiSjGlgOWG5YblBqy/tv7a+mvk3zFQUFBAOiedk84BfejDf1Gev72wbBnYMrBlIKR9 lPZR2kfw5sCbA28OwM2XN1/efAkc5jCHoTWtaf3vP73c3Nz+RH84cU6ol/LZs2PQwqNudHsFzt26 /OxyCNi8XD3tNaFwXAE1ujYowXIfZS/QTVQRW0B7xUZtDGjl1GzXbqCx6Kd9B9IHopI8FuQlLJKn gXOna7vzJsgF5WSlJUgRUjSDAadkwAy8si2xjAHR3XrVXgI8TlUsXyMP9B7hZYvVBO2V7W5eD5AC lNvGUyA+xCIvB5dvWrClAxjLhPcvUhP8O9WeUvoXcP6U86UtEDIicxa7hgBNjF/p0kFrrvo42gAT nUWyjgAl1fbqS7AfieheaCK82Jvzyl4Snha6FHnhBDyLuNf9Zg6kD9eX1q8Ej1amHF8TuL519nGU AvmAfEN6Dspmn3365fBixuvFsZ0h/lTyxwnZYNtrK+PqAQl7kn5NuQG2MtZyjqqgi5c7KfVBTRXN HYEg2rgyxQ1whQm9uA+ZO3Oi7T/Avl+OHDw1EC5YLmddqw3yM/lbnRVy9+UNyDsHcl3pI6kUmKNM gebaIPaxXWoLPm19L3qUhh6vO3q3qw7+Pr5DAgaDoZu+utEH9D8ZthnqQPaonIW5KeCY5fzamQ5v Gqd2SwqBK1Wv1bs1CtJWpY9J84fg06ElA16BKdtUzPwreOaaNpt9oZJSoUYFF3h1N/p6XwT1pva5 1gq0NvRiM2jjxCytBGhDNJktIG6JlqIiSB9Ko6RToI3WPtaag/BF5QFoniJC1APtiBjAeyDFUks0 B2m49hPDQBssAkUyqLWoIbaB1pS1Ihdki3GB4RLoq9NT/Qk8almr2T4A8YlhilwAzDW1Bko/sEpZ yelfgJxnnKsvChGdChJaFkofLvQs8n3wmW24bV4C5vc8yup9wUMXuipiAQCN/sisGn8rOjo6Ojoa Tvc63et0L6gwr8K8CvP43UMYfku9evXq1asHx72Oex33grvb726/ux2KFClSpEiRv+qJHsYw/g2z I1S/Wf1m9Zuwt+7eunvrgmmGaYZpRn4Pe3B4cHhwOFxqd6ndpXZQi1rU+r/Ee9sjWZGKVPzrN0pR ilLvvvw5vXJ65fQC7y3eW7y3QKFChQoVKpQ/NKBS7Uq1K9XO78F/qH+of6iH0DahbULb5A/R2Bu2 N2xvGHSO7hzdOTp/SElcUFxQXBAEvwx+GfwSAnoH9A7o/fvj/7OiOkV1iuoEt2vernm7Zv5Y6rdu Vb5V+VZliO4V3Su617uP93Y2keCpwVODp8LDgg8LPiwIHfd33N9xP+jm6ubq5sKF/hf6X+gPJXJK 5JTIyY/n09insU9jaLKtybYm2yC4VXCr4Fb5xzneI94j3uMfl/utHc13NN/RHNouabuk7RIoYytj K2ODqF5RvaJ6wa7YXbG7YoGLXOTiuz+/3Nzc/uf4w4lzmfLFW1ebDnlzHI9zLoH3OI+75g8hZXvC 3pSPoYBHiI9/AmS/bz0idYabM+7turwYgur4xoYVgZhqr+qe7woR/v7lCrWAyPO5p0vqoGB8sZ2F OoBxrT7DNB7EAylPiwOnpD52zQL9C5Eh9gJjZAteYPimwBehGngZ685r0hFcreQA7oOs8kDsA0pw RwsGOhjzlDTQNfRv6g9oGfrSHsPBHFDyTslR4Fcy4YvMTNDanr183QnWOO0XqS64HuS+SQsAy0c5 z50B4FpbeH+ZN5Dypec0n9Lwcvpt/dWj8KLU7fk3LJD6XJvMQNAd9XrqNQ8MFqU7myF7ek6l3FGQ 0VC9ZBsCCRMy270pCK7RDh9tHTgqquW0faDEG6YZLKAWVnupFtCGOLu4bCAvk+9gAW2ja7mrI6it xVnlNZCLoj4FVz/nXDUDzNVNDby2gKWmNVRrDupopy1vNJgGG3eZvgdXltZP9Yds35yWVh2oWa52 Uiokl00zZTeC1WN/ytzeEXwm+JTyPAfl95aMLzkA1BXaOq0OPHge4/XoLOgG6S1yI7DWsL1nOwtW 8rwcJwCzKCUPA62r0lI+CY5TjicZe0A8cA12fAiGEsY0fSco6ij4qshE8Hvgey9gDog56kNtKEi3 kcR50C9XuulagOumutQ5FbSO6hsKAouES5QFYee0WAa0ENkEgjQBbzEQtM/FDHktiLZahvoNSJep QE3QQtVW6nyQ6yvnuAPqfOmMyAb66xWDH+h7aYO13WCOs41wVgQ+N4TIN0HbLRroVoP1UUbZtAUg J3vv9hgI1afXX1FlMFR7Xb165ZvAOaksVUCLFiW49083p39IqaHUUGrAgBoDagyo8Y/X/9tZMH5r WrC0QmmF0gpBq7hWca3iwPSR6SPTR/m3wmNMMaYY078e//cuL5dVLqtc1rs/bv9uu1ruarmrJQxg AAOAmrqaupo6OFfkXJFzRWCz12avzV7AZjazGUJah7QOaQ1Nejbp2aQneDTyaOTRCKo1rNawWkPY d2vfrX238oeaeDfybuTdCBp7N/Zu7A0mnUln+ifi/7Pqe9T3qO8BZ4+fPX72OGxJ3ZK6JTX//bcJ fP0N9TfU3wA0oxnN3n28qOSo5KhkSPki5YuUL8CrpFdJr5KgS9Al6BLAssSyxLIkfz3CCCMMGjVq 1KhRIzjz/pn3z7yfP7Tl7Vj3OovqLKqziN/scf5blQZXGlxpMOwN3xu+NxykCdIEaQJInaXOUmdo cL3B9QbX/9xz0M3N7b+HdOnSpUuXLglRs2bNmjVr/uuBtCDXEPUapKWlr0u+CB5DzE/99sCdHx8+ PzkW4lxxjvTeUFRXbEuZY5DULafzs7twf/7zIqeDITzVc31UGLwqkjgl4Qi0iqt3sF8J8A71am+6 BX5Gn+f+hcD/ctDMkBegLhYtxUxQV6eeu/sI1HQ1R1cNDJPCt5edAfJN+3NVAjVGma6OAyFL5eTF oPNTv5EegdrX2FYuArpj8hblFli9Hq67eROyiuwNPBQPb0YlNcv6BnIq2ZfmPQVHbN5EQyTokgqW L2UFNaPyzjIB8OzAo3m358DtsCMFdo2GJ1eSh2ZaIK+hh9n3HPge8gzw/BLsPazrrVUhtXDmjLQO YOniCLA+AF17fbb+Pqh2LVWcBl1b3XVDO9BmynW0VKCdqhd1wTHTPsc5A8QR0UDrDVKEVBt/0MK0 46IUCG8RzG4Q2eK4JoP8WO4qNQL5kbxH7gDyBXmQVB2kadJSqQ/wk2SmDzjGO16rFcBwXN9W2Quq JF5rt0EaJ1oozUBySZ/zK0ihUpTWH1zeJGvZoEuR7boGYBiivyjPAHWuekI0A/mhdFSJAm2TK1Kc BTrzhdCB/oQpT7cdRG9ts/opFJoVXbnAMQjdExoSvAUKDA07Gl4Swt+E7AzLAKfVOVL7ELJsWU0z dkPg6sD5gXdAMkiZ+t4gV5Q/1GaDekfd6LoGQi/a6ieDa6Na2+kD0vtSsrQYlP3yGdkGzsaOaVpp UCrqSmlVwNbHuVpcBzFEMkgHQLea2tpgYKSzkasfuKbaK9tvg3WtQ6dOANtaNYNikDPI/v+x99Zx Wlvrwva1kjw6Pswgg7sXd5cWd3ctUGiRFijS4tLSUqxQrDjF3R2Ku3txBgZmGJdHkqzvj/fMN/u3 9+nbTWHv7vecuf6ZeZKVlXvdkty5s5KM93YFi24f7BgCuRbkyp39JFR9XEYp8T0U6VxkQf7ZoEb5 NLVeA0d/a1bH/wOJ4LHEY4nHEsG+wr7CvgLKyDKyjITLiy8vvrwY4r6L+y7uO6hbt27dunXffX// 09i6devWrVuhefPmzZs3/6ulSSeddNJJ531z9uzZs2fPgtq7d+/evXuPG5f6UMXbsu3YsfEzyoLL 6i2fshVEbeWkz114yLOh927DhYBbv51bD6E/+Jt5Y6H2qhojqmWDV/Jl0+eD4HnDF/UfF4Y382Pn pYRA1OCkkpF9QHso9kSHw/P7LxdErgPzw5Q3KR9Dzjk5HuTKAd5CjNGcoA4wB7rmgDWHPTHoMZin 1Iq+Cghf1ap/B4qp5nXOBJ6Kz1kJlBMHdQO8c++OOFcK4pqf3HfkDsQVX//p7j0QPfS3Xa8DwONi bnANUBo4m2cfCtayWb8qsA8C21UqVOIxvFZi4p/+Ctc/OaTvaQyPUp7mePEFxPbXvvZ5CgGzfEz7 ZZCT9Ur6Log5lNAntiokXEz+PLEOMEG9LQaAFqg8EA/ANtC6URsKooO4qZ8G5ZrcYS4Hbxtve0MF vYhxS28IcoYcJZeCccK4q38M7EY1BYj2SnsOgFTkTbMCsE8eIQLM6+YpMx+YunTInGBMkUJ+BHqs sV7vBbKifGb+BpajWiFRGWQ1cUTeAnlN1hYukMuMZkZPMK3mKjMYTCcl6QTsNVuZZ8GQZlZzNZhx cptcAzJETmIfmJnN8WY9MCvKY+YzMM+a4fphkFnFp2oYvG4fOTPhLES3if7yzQ7wNPB2THkAxlk9 2BsOoSdCn2bKCREdXi2KcIB1sW2zbSBYwiyN7QHwbMWzNo8NUFapVcVlSMqdUt6zFi6du7r5yjSI yhN1IaoqaIWsq7Rl4BPlU8jeAV5ni4qKrQTnPr9U8kojiJr3pk7EBsj4W8Y2QQVBu6nedEQDEcoe 5SWouSho9gVjuLlEHwKEq3eVnyGlomuU5xoYl/UBxq8QtTR+XkIUePKn1HQ/B98vDbu4C/49MgYE j/qrw/2PCT0Teib0TNr7mk/NOTXn1Bwwt5nbzG1QLbZabLVYsOWy5bLl+qul/c+jUKFChQr9C6aA pJNOOumk859BeHh4eHj4e5iqce7n8/7HBTxel7PhteJgG2IklBgDQe19WwVFw+sJrmc3r0Dwao8S 1AaeHHoy69FRiJvrfphgwPmZjw89qwZZo223gyyQb0tIkxK34JX6ulLSQrCF2wfG7YabhV+3OecP hb/Kd6pIJQgckNWT5wS45mnf+80D01d+oqwDdaoobZyG5Lw3lN09wLIsQ78820Er7/8k6A64Tr2s 8ZsL3Lcel4wIAHFMC/GNBJ/8NTx1KoC/N2NK1u1gnxDcKagLxKw+uetaATBHBY0KuAsvFTNH9DJ4 sPdcnVNR8HzQk4An8RA1FEM9C85Q5yG7CSwXPwkdklomVkh4AImZkgMSn4HyuXW6Mgfs8+y7LT1A jjbC5WvwdDKmuH2BQeznDdDR7C0+AvnALKTXAWWw+JCZYPSV/2du7mwtm1IaxEjjofkZ2Abb8ouf wEyUNdRoSI5PStRNUJLV6RggJ1NPuQfmEOO+eQHE51xU7oOyUizhJ/DmcseZkWDcoRSFgYPc0T8H b2XzlKwPWiw/K62Ar1gli4LpZb2sCmKGeVpcBPGDeEUQiGiymoVBPpf5qQayKP05C0pJvZHoDZq/ JdCYDuZZWVXOgcQMSehnIWLVq1KvVoLT7lhq7QD0enBC3Qj2gc6Gzhbw8NvH2Z5cBY/m6WOWBNd1 14KELyFxY2KNkPbw6knMyRgFor9PmB67ElgbP1hbCI8Kh895aoOSxz8Q+XdC+NFn05L3QaRfTJ6Y miDqRa/Vh4LSTJ0oT4PaUPnS5gfaU8teeR1yujO9zrIFzM7MNnKCFi6GaaPBXlM7LvJBgh43I3YK KF86jzvaw8WEO60fvoInK54WfTERPqZofL6/Otr/CXyq+1T3qQ7NaU5z+Jt//otsZONPXFink046 6aSTzv8k3jlxdnWyVfYo8PjrqC6vIyC4Y0Df0wPgwZind1N0KH4u5GHtEDjgudB0XR7wNDCOmBsg B9n989SGzAHakQxAvcZl+jXuDDXX1XbXPQBPTj0p89Af3Kfcd5IHgovYbEYt8PbSD7q/BP26HOvR QXlieeRXHihh7NC/AJFdjHZXA0/wb9ybBm+S1s7akQwhdTpk65ET7LPz5CrjANvO3JWdiaBet1ZW JwOnleLaE/AOiC7wIhoSs1zoeHYMaNWsGxMkGAey3AnrAY/vX55/ZTc8K32j9LVc8Dpnyiz3AZDT Hf6+r8DW1PqL+iMkl0xumvgc3tRO+CX2V/Bc1PMaJ0BMF0fU2uAJd2X2fAF6C+8aowh4F5oF5FKQ u2WcWAkygzSZANIjU8y+IFJEOwJBRKsd5FgQbVkqVoOtg+0z1Q9EDTMXdUAqZpCRH6yznQ+US6C3 dK80yoKZVX9shIMWruURZUGult2NC8DH4o74CowPZbS8DfpivaK5GOQABtEOxCA1WMsMZhU5TgpQ 9snlYgLITWK6/AJkFXOsWQmYxSE+BxEjsotXgCE2iumgLzTjzU6gRjNYLQ9mPU8D7wFQNUsRBoEa p7XSdkLMgLiMSf3gUoWrc27dgFzzc9xJsIPsK29YW8KbDtFPo3OCpYJlnHoU/PP5fe2XCzw7vXsk kJCYVDg+DpK8id0TT4IxWX7DanAddQck5IMTdc/UT5gJYoasro4FeZRCaiFQyig/KBnhQe9Ht8Nv AbXEBJkC5gRuGj/C6yyvqkRkgbwiW8NMrcD/c78vMm0FUVAtpVUEdP2O2RES/CNzRX8OHBBH1UPg be954019y8DgvzrM00knnXTSSSed98G7J87rzK8IhKRRb4JccWAxYlLsV8DW0GdeYAV44SfqXfOC 5YNMPfWGkGI3Nr75HBJXvrIEhsMncS0z9B8Nvs2sO306gZjEHHMa5O2dp1khN0Q9jp/ywgmXbiXE 7P4FAjZ5J5brApkKqsWtH4I7xrNZTwCxTLPbvgajL0sNJ6iz/Hv5JUPgyiqfVNwH9mPF69YIB1HO tHorgOxsHtVvgbnBW4SR4PnwVfnbYyGu4Y6R2/zA0zH2uJ4Z/BaU31KjAbx0JI2Jj4en3otDTo+D iI3Rt2IqQnJR8UJpCf6/OIr4ZAYZoL8w6kLC+cQMCYvBfdU4Yw4EuZLn4i4Ip3nb3ACyvoihLZh+ cj7tgZ9kSbKCbCnvyX4gKrOPWyCq0woXyC/lEakDi80R+IJ5k9lyGrgf6IP0RNCeiRKKH4ju4gPs wPd6Rr0ymBbjodwM8oZZnJsgApSnSn6QfeQZuR7oTCklDIzfZBazBbCecvIFqK1Fb0WAiBI95How W0gf2oFRzogzTgOSQnITqJOVLOqnYH4j25oTQW6QW+QEED+KhiIjWA6KdlwGrZ+lIZ8CBTD5CfRv zNLcAXcpd6IxHuQjs5+sBSKv2KBUhHv7f6v8PAJ0l9HfyAzqCK2xeg6UBCW/cgyiLbGL4rpBNkvY 7NBmEFM+7k1sdtDbmRlkO/Ccch/wxoCSohZXm4Eng2eQ+wLQwvxKTAPlvnJJ3QKaryaUraCMFxVZ DeK6ml01QTaSEWIzvN7+Zm3SLXB8b13yJhdYh1sGOy+D7bwtKiArSKuWSekF7nj39pQWkFIlfnjc VjB2O8OslYCNRP7VQZ5OOumkk0466bwf3jlxjv/6TYPkMZD5oqVl0eLQJ7BJ5NAOYH0YtNBbAw4s uVJwzUzwdnZ2cF0Hn8P2wKSmsKH5qaEzx0GXIs6inz8F157kzeI0nOmxI+aQBZx3fRaEaKDXUHYa kyDfoOCLea/B83lxKyOKQGihgFnPr4KvI6hNpnAwG5vDjcWgbBD9bafAMiFsSZ5PQfnBr35QEjBc KSoFyNuew95aIMsqB7SjgEtbLd+AN/lJ0p3F4Jn1ekrsSVBHZYkvWAU8icFX/Nxwd8Cvxw6vh+dL H+18MBBeV9BzmQVAm+2Y4tcG1K/4WJ6EuJtJKfEHIfGyq7RrMFja2Uz1IOjX9GLGYVCsSry4ALId a8wY8G7ybjO+BvYzRTwDNVqro34KZkGjkD4S9Il6KT0IFJvSVwkElshhYjaY98w85nrwHpZfyd3g kXIFBigOJZO4DPzCVfErmGvNB+Z2EKNkBlEcvDGekfpxoKUoJfYA5cVx2QqMGLnKzArqYDVW2Q1c FMNkBTAbG58YZUDWkZ1RwFxqrDKyg5pV665tB7leHjUFKFXEZHaClk2ro94DOVRmkp1A3Sdu8QOo n2uz+Br09saXcgCwWubCF4ymRi0jEpRNmqbsB6oy29wOel/zotRAidDmKdlAD5Jecw8wVT8la4Ie qr8yV8Pjtk98Xr8BHiib5QsQy5SPzExgvW29oX4I3vtej7sgGIeNbuZCUA+qTbSlIINkgAmIDUY7 ZSCYS8RQaoPanRS5A8zR8mPtC5CPzZdShYgfo4bHVgD/UL8yPksg8xfB7W12ULJyw/oZqB1EZvEF eJOSlif+AFpH6x3f8X91eKeTTjrppJNOOu+Td06cCw3O9FWlHdBftm0+PBP4+AcVdHwDUf1fnXqT BxJzRObxuwV3uj65/bAAvHr12ufFQ1DWWPNlyAk7LWeLHOwHzsnqLz6DIfZ775inGeBlfU+L305D 0i+JockTIT4x8cyrNeAX59nsMxmy98laPXNDCKqQyciWDO7tKR09PYDX9LC7QB0Wcji3BtRJmfFm LyjnjKNGJtBLKMNESVD2y0dcAsqbRV1e0AYGxPnEgqpmmu3bAzLcqvx96TbwxseVPckCz85fOnCh A0T0ife6skLKZ2KZ5g+2suY44ykkn08+nahDbEry2Phl4GlmjjK6g9pbj5U6yBVyLT+Bt6g3wuwG 3pGGy0gCZQZB6lIgicfUA2O3d5lxGMzXZoy+HbSxyln1MxBhylAxFbzl9I56URCbqCqKg3hmPpd2 kP1EnOgLRmY5Qg4FMYaB8h7IsvTEBfKyaEtrUIeLQASYuczdcgnIR8pKnvJ/3j+6AcR2pbk4C2KH mExukNf0JzICqCNbUxM0j7ZRCwaxXrGKQkAVpsrbICqIAiIAzI/NYmZTEHP4UC4HYzx1WAHeoy5N dgSzmLwqc4B1pbZCyQ3mr+YIsQHIJhtSFuRyMY46IJ/KeTIY6CvzmBdA3JCbKAYyszlQHgWzG5eY Ad4F5j6jNqirtI+1EJCYvc3OYH4o9xsNQM41c8j7IL+VrWQukCfkan0WKH3FVHMeMF7tol0BS0lL WQWg5v/5Zq5eSX/t6Qq2FdatanZIOev+TgyC8A9ed41sDT4P7B/4uMHXdEYHrwNPrBgvgsEs4I10 nwPzRMpR5TbQklZ/dZCnk0466aSTTjrvh3dOnHPJ7PWy/gRne19NPN4Yjt47bzuUA56PjPk2PAAc azJUjpkM/h0DNzlaQIzyYrhnFvh2cQ61B0JCNtf059UhYaN5JgHI3sKvb8B18P8mILlsAvjuzZjs yArCwStpg3JjS6xpcgnuWW7nPP8b5HxWcHLekkBPy35bK6CWXtg1DbTYgEyZfwY51baQNSBNY71e A0Q5cVdJAOWhHGY0BVlEmo6nYCubp1uxupBhYcaQvAb4DM28J990uDZp1c+Lx8DL8MdfPdkPMWOM InwExg6Rwg/gXpEyMmkE6MHKKGqAO8nbyFgE5kYzmlEgn5ifm8vArG+GmqvBmCA7yC1glDYzmW1A fKSUlzeBJYyjMJh9ZSHzNcgtzBUdwYzjtcwEopAsxxoglBzUA+lLGZkNyCOmsBFETwrLSiATzP4y FjgoxvMClO4yhUjgluguMoH8mgLKN2C2wqqngJxofk4NoDADxWowTupB8gKoP6rFRRCoLyzVlPsg t8qOIhIYKIfKfsBuGjMJZB7TLncBTZUMcjWYl4xK5mOQWY3joguIjFo3JRaspa2hwgZ8az2tPAGl hr5XfgHGNL4zc4GcbL7RVgOn6cV0oCo5zAxgtDIfyV8AVR7SQkBswyKygdlLltYHghyFh9lACTPW yAHiK2HVcoG+QH9OW1CKiACRB0RZPjY/ApFDZjM/BnMED8Q9MKaZpY2WIIrrugwFUzXvii5g/KAP lKXBU110xwLKOq2WkhnexEb7pQyG1zX9Qt7EgHOKPcq5A6wvxGzncUj+TCw1c4Fnf8oBd8B/Bcnt dw/Uu3fv3r17999xSEgnnXTSSSed/7kULFiwYMGCf377d06cj2a/uW7ncnh6OXpR3EBwFrT20H4C /Ylx2OwKIix2gdWAjKEZXgWUB9fXGe0vakLmzp6chUvCy7CEyRHtweeBNcR6Eh6ue/2BsRT85sVV iNDA0k2bpztAszlFck/w7HvQR66DOyuuO7e2hYxjsybojaDC5RoX+n8NyUVTrCnDQLWpRZ0OEI2c Y7P0AJ7LcFkDlBqE0B/Mo8IisoAMJ9r0B7FeO5EpEOxdMz21DoL4Ls/GPvoArrQ5lvt4WXjzTUoG Tywkr2aemAbOPbZAZwDo2cVGEQBJJV3XU3zBu1BfZK4A0V4kKadBiVSza/3AbK9P8ewD5aLZ0owF JVItoeQCs7H5UJ4AslOZ4SAU4RF3gVlyqtwI2CjGZyBNWUyeBvGdqKR8BbKX7Cqbg1bHMl6rCcYC c4D5IZizzPrmdFAri4wiFJTbyh2lFZgvzCD5HMwmlGYLWBIsPW2FQK9gZNWzg2kYk8yWQHtpZwSY 0mwtXwMwycwMSrxSSd0LylfqVfUkGHmMTkZ3UAuLAmITyKxmilEO5Dr5kouAqVYRF4BvhIV+IJMp QwzI+Z6iJmAWM6qbe0BGi/GhvlkAAIAASURBVLbqcuAmR+QykOfkR7I/UJrWcjnIG0Yx/EH8LLLo xUD0VhTlAlBR3lXWg3nQPG/WArKJKH4EMZJaxk6gm4w1N4H3A2abH4DYL5epmYFDFDZPgdijdjNm gxysjdKWgFHS6Cs2gNpA0aQvmMtkiJIAdBH5eAyWFaKiUge8JfSxhg2i18UMSiwNoR2D7IkW8O3j xPoEhFWfRjbQT+kVhBvowvP/hEBPJ5100kknnXTeHeVdO3Ct9eyNdENxW06b2RxK1i3ZNqEJZPk1 RxnxK0REplz3DIO7/X8bEZERfJq57ml+IM/6935zDvI0LFQwX3mIjEguIzuCWYQbyd9C1OLEi/c2 wKvbCe2efA7RpZK3vjgLl69d7XW0GPgMCCmdrzGc4Ur1fZUgYUvEpw8HgmK1TbT0B+NrmVF/AeZB 6tkrAnXpKbIDFWkgDwNlqMfnoFQwV4gxYFbhvjkDmMU0bzA8ij2z8kwUhDd77PfMClHDPEvkZ6B9 bXvorAMBu30+9B0D6jLlZ+UOmAFS4zFY4205bGNBqatcUh+CucTcYswFZb2yQVkCWqhWUCsCygCl o3IYRFYsPAVxV+wVX4LykdJN+RJEDrWI6gBLVksx60WQT+VFWR0sJSwltFxgP2k/Zb8K1u6WJlYP 2GrYLtoTwHHW3scxEpSVynatP6jV1TpaZ9BuaLr6BMRukZsyoOxXPlHXgMNim2sPA+cG+11bcbDP tt625gLrC3W45Qwo4yVKe2CHkd+cDaKO+YNcApbM6hZ1LEiTGlwAI0rO4Q6Y3/IV60A+MkPNkyAS qUoNMOrrmWUuMFu7w2QUmIeN0co1kFXlWRqCqC3sSmVgIfv5BCjKAvEaxI9itJoAIlz4ih3AfBay EmhLF3kDRCXxgTBAjjcLy5ZgWs2iSmtQVMVi7QGWZG2z8zTIiuZe5Q4Yr/XS7AEmskkdCcwyV1MZ jHV6eTMcDKHHmxbgsHwmm4BRwHtUfwzGz95M5k7Q7xvD9d4Q1efNzMRSEPM4LjyxCdBa2t0DQPtC 6cYeMGqZmfWyf3V4p5NOOumkk04675N3rjg7htkv2MdA/Bb31ITGEJbMR86u4DNevtQ/gizhQY3s 8RB6VRvovwBytMpgVZ7AbxvjV79aBNk/tZcv8xkUnVdydfYoeFLm2d2rjyDxdLzpMwo0LNMteUC9 a+mcEATKcfcm20wIOuCvBKyAiEexhZPrwZ4a+2vMCYF2qzpem5YXkp7Iw1ojUFqJaDkQZDbxQM4F MhKtdAF2i3ayNZjlaSf7grJfaaNFg7dB7LW4MnBDPd/rTBGIGpIUmrQEkrxymPIDOHs7WvqEgrJH vjROgXes+5Q7D+AQ48QWUC6LbooAJU6pYYaDPs9zU78JylhxU3GBaK6VUasCPWQH8SOItcQZX4K0 c1g2AWrTXRwH83NpIRxMp1lWNgflR2W5+jOoiupU64GQwlROgaEaLmMIKN3VHcpPILaKo8oZUIdY DO1XMA+apc3ToI8z6uq3QZuljlMXgrHUTDIvA5NkAfaBZbxaVYkH8VSJV6qA0kDpolQF44beQXqA CkySScBvYjlTQEwRg8RV0GbZWqm+YDxzPfBcAvOQnlnPAkpFxUcpDySY34loMEuKHKISiFmyFAdA llF7qU9By6xu0Bwgk2S8mRvIwwqRCbQbyijtQ6CrQOYFZojh6igQs/mKOiBsykDZGcRzXoknIHqr 80UesF60lfDzB7kSu6gC6nw6KnUBr5yfeBG8MzwjUh6AOcNooJjAcPNr8zko2+Q1dgM20V82AzPQ XKtPAXWd2lFLAHFK5leKgeOoY4h9KSjrtCa2O5AwOamAcRY8i7zNjUBQm6n+Yi/ICGn3Lgba/tUh nk466aSTTjrpvC/eueL8untkppTNYA2yTbX3gmAREpm7JbjsSlTcJbB0pagcA/pa65KU0xAR6f42 Jjck90vOm7IbrpV5ue7AXbhX4/noa7UhPvpNXVkOLFGOsfZ74HQEn/FdAmzUz6vnQHYyehn34FGB +9ZnwZBQOuaq2gteHDIuPoqHeysfDlm0GJy37Tes9cH8hnqGC1jKFfUwcEU8lCaQUS7jR2C52dbc BNY5llpaMrwefqfKzavwtNODng8+gTdRnhO6P8ggMc2igS3A9kZtBq71nsqea5BcU9c828DMLa+Z VvCs8JTzngRjirFft4N2yvLEugC8S/VKxnqQ0jhrLgFbc0sJ5TEox7Wumg1UTa2pXQDLWEsTS32w FbZ8ZgkCrnJVVgeKU1J2AAbyKfVA7Ba7WAuylsxh3AfXLykjkt+At7s30NMTvMX0F0Zf0A0jj7EN 1DC1mJoCyg1xQZkGymfiNldAKkw0b4K4rIxTcgFfydVyEJBECb4CsVhJ4QrIHSITX4C2TNumnQR9 gvmDuQXUJnKZqAG2YdZStsmgNtfuW2uCGqI51R9BlpVFRC2QFnOCuQzMcKaQG9SfGKQqoD1Vmlv8 QKyhmPINmDGmlaZg7DaemQHg7eftom8Gy3KxRysMlsWKj+USWPdYP3c+BvNbs4ksAmZxfYe5FzwD U24nzgDPJ8kPEspBcq2kevHDwPjAu0SvBD51/NTAFMhyJ2tkgYIQtDZ4Wc6LYOvk0y/DOnAGBjbK +DGE7AudknMGBH4X0il7XnD0CxgX0g/8qgYNyNIMMh7NtCDMBpZvHCsDi4C3q75ZLQ2W78UyYyFo nURV7au/OrzfnmG1h9UeVhvaHmp7qO2htOXT8k7LOy3vXy3d/x7Kli1btuxb3LH4+/Z/lb3+VfuN Oxx3OO4wfLn+y/Vfrodqt6vdrnYbqgysMrDKQBh4c+DNgTfhxdgXY1+MBfmx/Fh+DDNnzpw5cybU 8q/lX8sfKi+vvLzychiwZMCSAUvg+fPnz5+/w2Sqd7XTv5rfs8d/ir/8EZfLXS53uRwMHjx48ODB aX//ntRP3aeO6/f+/m/lr/bTd43Hf9YP/l28c8U5+9mM7aw3IMvCbDv8giH8x+h7MZfhqefJ3pTD oDRXZ7i+As8jpWTK1/CmQ+wB/3HgE6R0dNSDlB9ls8TG4K6rbzSyQ3Kit4S9D9jvx+eNCwVlgP9x bzwYHbXZ6jjwpJh+5kxQzosuiY9B+VBrkjQKnnV70zU0Oyz5YOeUjXOgfcNyfo7sUKJftfM9JkDi OtehhFygnaKlVQOZQZakBYgWIkCtAnKUccf9EH4rc7HcxXMQ1SXGjG0PCfGel5wESwn7dccCUEPF TaUTJJ9OqZP8Gbg7y9lmEJBDidRqgWWiZZCmgznFaKxMAVopPcRKsM6yjtLWgrnK/MXcD+YROU8M BO2Etl4tC3KUnIw/KOOU0cp4kDPl98Yq4BRPmQjitDgm+oO53Fwv14DaU+2qRIK1nFbPNg/UOcpi bTCYQ+RaOoE3Th9l7AM1RM2rdAbFQ7RYC3pjY5XhA9qn2iOtLigJqmLNC9pk1akYYKQYj4x4EA2E XdQATmPIAWAdrJXTRoCswE2+A6WcqCYKAbXlVnxAvSymqO1BG6EuMRuDEWRUMXqAHMZm8woQhVN+ A9oJLUZtDGKQeMxiMPsbBaUVZKS5Qx4DUZUJYgMQJ0Yov4F6SXmilgbPKW8Jz3ywHFG3awHgreI+ 7XoJ3iPGYeMsaDe0K9ovoNZU8wlfMMuZLfWfgUXiieYFpa5WQHsCRn5zlXwJflf8avt6Qc0T9CZD PpBX9RXGYbDUtCraXnD62nJqccA884h+ArhAZ29NsHyrTCIJ1EVippoLrEXtC+wVQaui3FBKgNJB DFPagLpLeSymANDtrwvvt+dI/JH4I/Fw7t65e+fuAXWoQx1YH7Q+aH0QDGc4w/9qIdP5B051O9Xt 1N942l9lr3/VflNPuIdeHHpx6AV07969e/fukMU3i28WX5jabWq3qd1g9OnRp0efhp7ent6eXlhV fVX1VdVh0JlBZwadAfUT9RP1E/gh6YekH5Lg28XfLv52Mcw5NefUnFPvrvf/NH7PHv8p/vJ76B/o H+gfwJTEKYlTEuGp56nnqQeMc8Y541xaO28Pbw9vDwgfGz42fCwMqjyo8qDKEPgg8EHgg796FP85 /NV+emLWiVknZr19PP6zfvDv5p0rzvodS5JrAdxt8vDVYytcmXZnyZ0dkKlatqq+BSDlokx+/QIi L0SXdFQA5b4Ism2DyOVJXcwLEDMgLq//DvA2Ndpm2A+2PkGfxT2A5EreXolL4c3+p1mTFIg7+XqC ezyYY41bcjG4fFKmqFXgdWJsp7jmENExunT4OLibL/xl7Kew/OKhZpPjINx2p/fhSWDPZm/jVxfM 7GYBvSuINWKfbAXKQ+1LZQm4HkRujSgIj+/fPHXzDcS0SZnjjobEOsYUFoC1iuN7Wx/wfOUtYFyG lJ88C1MygV6Z0iSCsdjcbQwFoYgbNAXzpNnEBEQX1nIftP1aP20FWPprH2sSzNdmJfkb6B/pjfSd YGQ2go3GIGvKurI/mAvMX8y1IJeYg8ydID+VtfkZRB7hES2AhXRjHfAV18wkYKFYJysCS5iuDwYR xi5DAx7KlxwF0UWZq2QGdan6QG0JymJ1proRLAu0TdoMkD/LXVQCNskloiQoBpOUayBclBK7gFEy hWMgC5pj5W1QlyutlUHABhTlPhiTzSXGWhAdxUBFAdFd9FCvAx7CRTWwLLXs1eqDkkWJVrqB9br1 mvUEyGc4jVgQt6ggm4EMNr81zoEepMfrV0GuMZ/JBuDdaAzxloKkxe5p+jzQlxpj8Af1tbpWGw9o CPEReJt62+u7wDvLO984DrKStBvrQe+hH/Teg+Rfk1vEb4CImi8vPWkF0QuiBobPgeSOCc0iX4CZ 4C2WuA2Ssia1ijsN8fXjc8R1gCRn0v3kL8D1uTvM+xgSCib1SQmCBFdi1YRREHclsUdiPHjPGU09 O8HWWp1p3nx/gXog+kD0gei0SnCLHC1ytMgBzSY0m9BsAmwbs23MtjFp7WNjY2NjY2HEiBEjRoyA htsabmu4La39yI9GfjTyo7R2Y8LHhI8JT9u+X/l+5fuV/8flfS72udjnInTu3Llz585wu9rtarer pa3v3bt37969YdKkSZMmTUpbvuPFjhc7XsDXDb9u+HVD2Lt37969e6F169atW7dOG0/jxo0bN24M S68tvbb02j/qIbUSsvLWylsrb0GHhA4JHRIgMTExMTExrRLRJKxJWJOwtEpG6jj/iPctV1SOqBxR OaC/2l/tr6ZVxlLX31xxc8XNFb8vz5Q3U95MeQNNdzXd1XQXzCsxr8S8Ev/YLrVy83v2elv9vK3c v7fff5ZWU1pNaTXl9ytdERERERERELoldEvoFuh7se/FvhfTtsvyIsuLLC/g1qBbg24NAnsVexV7 lbR46dK5S+cundPiIBVd13Vd/+fl/D29p+ov9Y5N3bp169atmxZvP5376dxPf3Oi/7P+mqqf2e7Z 7tnutP7nz58/f/78f94ef+QvE3dP3D1xN+zcuXPnzp1p61MTlgbPGjxr8Aze7H+z/83+92fnVFbX XF1zdU3IlStXrly5IFu2bNmyZfvHdv9/hbIMZSiT5qdlFpRZUGYBNNrWaFujbWn6fVve9jj693ZK TQBTt+tSpEuRLkXgecbnGZ9n/Nf7wbv66fuy65+Nx3/WD/7dvHPi7C1ihPtPAG9UtN0yAHwymJ6A VpDxmpNMP0LhTKFbQh6BI6OPJbYfJDxW+r1qANpKa5noacDjxCFRGrjL6L0SmgKx4vtkFxizfcvH XQXfrXaP4xX4ZFLrWIcApfWtrp1g2+vXyzUSPKM9pSxvILxh+G3lAri+TJnjqgJa7YAmIQdgcaUt j4bOhITZ4X1vnQFtuO0zn6dghup9vceAk9pgJQCi6z0q9rAcPHvywv/5YYiJTQnxVgTjtVJBPQ2W FOt5S19wJXp6u19B8nhvcXdTEGWES0wDmdu4br4EQ9Hr6kXAbEJrcy/I4sYX5iMg1qxnfgrKYPGb UEA0ll+JVWDmNR1mTuA452R7MG+a142KIIaIHgJQI9UUEQGKQQ1agnxt5DWqg3FOj/GcBP2Nudps BjKb9MocwBCZmxXgqGvT7FFg3WppZwkGa3aLtIaAtbWlqLUWiILmG1kO+FAWZQGofdQBaksQj5Tv xSJQopXyyihQeyjBym7gF/z5DcwB5kPTH2hCVnqBeU1ul4uBjeI6h4FYMYWqoKG5rHlA66mVs9nB Vt9m80kBx3eOSL+q4HA7+vjfAEdd5w6/umD7ylrIuQP8a/geDioEfk39HwU3AWO8kcF4AuY17rAP /JYHTAmeCVpbW1n7PpDFeMgm8PrqHfRMYJw1CppuMCPNqrIKuIKSbyV1B+/XnsAUK+jt3DmTPwbX toTfYjvCK0fE5Bc34fFnjxbft8Oj7571f3IBwltGLoidBvFd3Vu8hSFuhfss8RA+MKZPSkWIPJrS whsCMS2S4vVTEBUc1819AFJOeloZ+0B5iMWs//4CdUK2CdkmZIMfOvzQ4YcOsOXplqdbnsKCPgv6 LOgDxzod63SsU1r7qfun7p+6H0Kfhj4NfQo7X+x8sfMFbH229dnWZxA2Lmxc2Dj4tu23bb9tCxOy Tsg6IWva9gvLLCyzsMzvL69krWStZIULCy4suLAAPHM8czxzICoqKioqCq4uubrk6pK07S71u9Tv Uj+ofL3y9crXYc29NffW3IOPS39c+uPSaeNZdm3ZtWXX4KfzP53/6fwf62X1qtWrVq9KO2GkHrhT E/Uaq2usrrEaZvw649cZv/5xf+9brm/zfZvv23xpUwu2bt26detW+HTpp0s/XQrTC04vOP3/8raU WjVr1axVE5ZUWFJhSQVYuWrlqpWr/i9+8jv2elv9vK3cv7ff90XqCX1P9j3Z92QHy1LLUsvStAQ+ YlfErohdULRb0W5Fu0G5y+Uul7sMwwOGBwwPgIPTDk47OA16eHt4e3gh++vsr7O/hvFNxjcZ3+Td 5Uu9wAkMDAwMDEy7ANsSuiV0SygkdEjokNAhrf27+ms5UU6UE7D48uLLiy/D8irLqyyv8vb2+L12 9evXr1+/PuzPvT/3/txp68+cOXPmzBko1KlQp0KdIMNHGT7K8NH7s3PqBdLqGqtrrK4Bw2oNqzWs 1u+3f7zp8abHm0Dpp/RT+kGjxo0aN2qcdqHZOKxxWOMwuDbg2oBrA95enrc9jv49IfVC6oXUg93N djfb3Qxqr629tvZamHZk2pFpR/71fvD3vK2fvi/eNh7f1g/+3bxz4myf6O3m3QvBi/zX+TSFEIf/ Xkt3UPKba4wKELfSSHIcBq2JeV/Wg8BR2r4MWcG2yLbSuAiuC0r2iG3gKeXdHhsHnoSk7H4ZIOdF /35ZEsBeUT7QG4Llt8T5ahQ4Lhh5bKXBMtmxQT6BDK+yTLSWgJCQDOX0YRDmDp7jUxiSz0ZZFCuE t3JNTTkNq++ub/tlXyA2ScbWADHfMtTZHLSdsgrNIeL8s0b3CsGbgjHNE10Q+1rfYZ4CNaNFaP1A jBfllVmQlDflZUJHcC/XEzzTQAw3mpq/ADq1xErgF3OwKA/qED5XPgJ5lWn6RTCymd/qkWC0M7zG JmAhoygHZmOzk1wDik1JUIJB+VJ8yEqw9NY+FdVA/sAhpSSoebTzlr4gbioj1Axg3DdzMBXIRKw8 BKKNqK9UBYaIiepEMGrL+XQHOcOcgh2MzfpX3o2gvBbbxA5Q+6tfqWWATjTgHojuoq3oAuoK1a3e ALoKf/aA8pNaSe0LPFZihQXEHHGXpqCs5xyLQNXV2ZwGbZ2yR7kB4o4sIwaD1tL6o3YFMk3NWj/X cMhyK0vz/E7wmxDwNCQXBK4NScxYF0LdmX/NWRVCs4UVzeEPgVczlsyUGzI1yRKaexTYrznHByVB ph+zzMrbDpSlmkP9Coz9+mz3RNBHeCN0E8yvjVP6t2B+Y+zyHgS52jhsXgFzPVOVUiDyEGcOAT3J 8NcbgLOk/73AQ2AdZRvgaAFGA1nJqAFJDxL2xV0Fz2eulcllwJxmfm+sBstey37beHA0d9YMmgf2 pbaiAVnA/Ei0djyBpJH6MdtGSFznycw0kAHKZ+qg9xeoqQfIMTvG7BizA5YtW7Zs2bK0A8z076d/ P/37tPanup/qfqo79DrT60yvM6B8onyifAJikVgkFkH3Od3ndJ8DJ7ud7HbyT9zCS02ALy68uPDi wrRKXzmlnFJOAe2qdlW7CtFTo6dGT4XLymXlsgIVK1asWLEiLKm4pOKSihC8IXhD8AZYN3zd8HXD Yd75eefnnQfzJ/Mn86ff33+b1m1at2mdNq7UKSbNdjXb1WxXWruWkS0jW0bC2Xln552d98fjet9y pSYafy9XlWVVllVZBvN6zOsxr8fv95d6Qg0JCQkJCUm7Nf22vK1+3lXuP+LvK1RPNj/Z/GTzP477 HypYpSlNadjeaHuj7Y2g78K+C/suhDwH8hzIcwCmtJjSYkqLf9xfzsk5J+ecDNWc1ZzVnPAs47OM zzLCosuLLi+6/OfHkUrqrfDUCr2maZqmpflB6oXYn7XH31O2b9m+ZfumVeD/rF/8HqkV24dfPvzy 4ZcQ/138d/Hfwa7xu8bvGg9NXzZ92fTl+7fz9I7TO07vCD269+jeoztk/Drj1xm//v3+gzcGbwze mFbJ3bRx08ZNG2FFlRVVVlSBN/ve7HuzDybumbhn4p4/Ydd3PI42ydIkS5Msf2PfqJZRLaPgUt9L fS/1/ff7wdv66fuy69/zR/H4tn7w7+ad5zjbxmlXlDKQeMztb2kJZoDmb3WDa6b+0kgCzW7blTQG 5B79tJwJoqx51zUXnLmxMBYiBhi/2T8G2yDtUMoisI1XfrQuhITNccPxB/OMu3nSLjAmK62dWcBv RFg5Wwwk3E4s41MJXh1xvUzqBwFP7KvVDRBQn7M+x8F+PWxoXCS4Wsd394uEC53Dx79YDkU77m+9 pDxUK1SvUZ+tID5TvWI4hOe4N+VJJohxpSS7qoH7hr5FzwOOkr5fOoqCeUkOlMPANdQV43oAPGGr OA1GOTnZmAL0luOUZ2Bul5fkAhDD2cAK4CB2uRnkTnOFbAO8Fg3lWhD7FY9YBlpfrYH2OZjzzFky CFSptdA+AfMrM8ncC6K/cIpioK5S1ystwTxjnpHHgTFyPwVAGcF+9VtQsglF8YJ2SXsj6oD+Rh+l PwNRSM2vJoCSLMqKGaBMVQ6I18BL4VRvAJ+L/rwCVWhltBygPDSEcR7YJF8SAvKQklU+AVFB9lP7 gygiAsQpUI5Rllwg5xEqmoJ4LLwWF/j+HHA/4DLYz/lI/x2gZ9PPGvcg7tO49a+uAOuMqKQK4P4x qVzUFBAWNav9BciT5nW9I+g/6AU9k0EdoIbFjge/yb577QPA3Sqlf4odEirEfx7TD8yLnpLemWAU 00Pdw0B+SAWzPcjxYoqyArgiRim3QRzhlSwPeoDxiQgC20ZnTIAJtvnO7/1HQnL7ZCItoF8xArw1 IOiJvytjNAR+E9QjSwiIr9XcfAyiqIb9FmiVLGUdpUAmy2LUAy1JK67dBC2fOTPlI9DvenomXwG9 naEwBNj8thH13/NDwR8K/lAQ7j64++DuA7g25NqQa0NgyYklJ5acAAYzmMEwm9nMBmRpWVqWBm2v tlfb+4/9iYviorgI5jPzmfkM6EQnOv3z8hQ/Xfx08dNwb9e9Xfd2wYViF4pdKAaldpTaUWoHWM9b z1vPw75W+1rtawV+K/1W+q2EoFtBt4JuwWeVP6v8WWUI3Ru6N3RvWmW1atWqVatWhe1sZ/v/Zf/2 W/Zb9ltpvyNzRuaMzAm1dtfaXWs3UJaylAWsWLGCmCqmiql/PK7UW6bvSy7jJ+Mn4ycwW5mtzP/m G5KpFz65yEWu/6a/1Mrqu/K2+nlXuf+I2cVmF5tdDLwdvR29HeEz22e2z2zwssnLJi+bwMaNGzdu 3JjW3n3Kfcp9Cr4K/Crwq0A48urIqyOv0m79Dro56Oagm2AbbhtuGw7nep3rda5XWkW6R/EexXsU h899Pvf53AcObDmw5cAW2Bm7M3ZnLIxmNKPfQb/ikrgkLgGNaESj/2b9f8UbwQQT/O7++r784vdI TaRqz6w9s/ZM2N5+e/vt7eHKkitLriyBCV9P+HrCP5HIvK2dU6cCHelxpMeRHjC97PSy0/+bxCu1 3fQn059MfwKN5zSe03gOhEaHRodGQyihhALBz4KfBT+D5588/+T5J2+vh/d9HFUWKYuURWn9/rv9 4G399H3Z9W3jMZV/1g/W+K3xW+P39vb9s7xzxTnGmfCh0RXMsWoGT3fwfqJ3JB5ebosclvId6D8k CTU7BFVWT4X8BpkyBPyW6AQ13DgnFkPGg74NAyZDxkYZPhezwFLbUjuqP4SGBh+0FAFnN7+Mtr7g O9rWgG0QNS/pVMwZ0DP6e+KWQujgbFNTJGT4IGCxszAo2+wjmQ6J+eK6MAlcr9z+3k/Bc9RxN6U1 rA0413Vdd9hbbEfQ4iXgrvZy9SM/eNHkieN5GMR19AR480PyLuMbcxyoTSxdLD+Ct4eex7sfXCM9 KZ5hIIswRJ0NrKazUgFMm5xtDgfZh1jZD6SvPC8fgFHbjJTrgQnKc6UViCPqduVzkAspxhegtGK+ qAXiJ/mah6Dn18/p58AcIv3kI5BX5K/yOBirjWnmQsBJMhLMC+ZRcy/I3rK32RPUieocZSgorZR2 oh6oo9TxylxQfhELRTdQX6nh6nZQ9ip7lamg/CAmifxgKW0ZaPkWtJbKNjUfaEXVaVoUaE6tulYb tCQtxlISrJWtN237wLJZy2f1BzlVRIgwsGaz+Vk18Knr/9TvKlgH2vfac4JsaE41p0Ni3jdLIi4C vbyzksqBcldk0/IBk+RN5Rmo1znv6Q9KRTnfGAeWe0pvpRBYu1veqCr4zPS3B12A4NohVzIuh5yZ cg8p+Boytci+MR+QvVjeex8EQo5L+eaVrghhU3N/WuJLyHo7z+wSsyHLjznmFj4C2cvmjS9VBnJr +ReUXg1qHWvuwIrgezt4cEY35K/wweBqJyEoc5h/4XvgWBT8JiQJfIL8+wQVBvGh1tJSGIynrOEL UJdpK9RdIAOSWkcehMRc0d8//x5SOicNTtkNRiVjofR5f4Ha9ru237X9Lq0S2iamTUybGPjywZcP vnwAV3+++vPVn9Pap85pWz5w+cDlA9Oeak79u3TZ0mVLl6UlhP8sqdunVioKJxVOKpwEm+ptqrep HpQyS5mlzLSK1YqqK6quqAqVrle6Xul6Wj9Xrly5cuUKDLg64OqAq2lTAlIrD/8//1Vh/COyjs86 Puv4tErThQsXLly4kFaZHDli5IiRI/64n/ctV2rF5e/noJ+X5+V5CV9n/jrz15nfn5/8nr3eVj/v Knfqfn/XXk2zNs3aNG3uonWpdan1bxKA1OWpf1NvaadW6FIv3FL9b3+u/bn250q71Z06ZWhuibkl 5paAH3v+2PPHnmnjj2wR2SKyBeSPzx+fP/7d9Zz6do/UKSWpczVT71AsFAvFQvE3439P/vq2fvC2 7VKnbMwz5hnzDKh9v/b92vdBu6Zd0679cX9va+e199feX3s/LfFK/ZtlR5YdWXakbZd6hy31ocb2 BdoXaF8ANjzc8HDDwzR5U+1cqWKlipUqvr3e3vU4uuPljpc7/qYyvzl0c+jmUCh9ofSF0hf+/X7w tn76vuz6tvH4tn7w7+adK87225nCY8qBWOGt48kE3mte3d4bEne5h8VZIOgT+Th0IRRonXl+lmEQ etO3Rcbv4HaEpceLIHgVf7+jmRHsZ5VSAR1BTBDJyXXg1bKkF8Yw0M7GlrduhuDOwcO0s+ApF7z6 zUgIj3zsSDkBGVo46vpPg6SK/lW8CpCQ0Nv3R/Ab4O+Rs8DWKUTYJ4DHGfH96+EQe8Zb+dVMOFHh 3keHC4KxLSnKMhnC18ZXdq2ApJduh/cCmBaR01wLWg3tQ+0rcP2s5/E0AW8Jo7b3G9BnUFbMBTHM WGj2BtlAbGQLyJVyIvFgzjNHGqGgrFByip1gtjB7G7tBH6l/rc8BbYC2wDIaxDBxRVQFY70xX58B 5FNMcRiMfJ695gXgGpK6oPQRk0UbEAVEjGgEVGAig8E4JpsaGcC8I9fIjSAfU0r8BOZa+SGxoK4R n8vbwComMhIE4pJ4DbKerM8bMI7rc/WVoHyhjdNOg3JDOSLcwESyiZMgP5JP5WoQk4SiFgYeaqHK CtCEpYg1CSxzbc8drUHeE/Ot34JyV4zVKoBrQlKOxNZgfsAmzzaQpdWy1iQQUYrbOh+0jeKxZxJo VtWqhoPa2nbQuRREDstjqwSfb3x2BfYFtb62w1YbdCmHmAlg9qCP+BKsr30W+A8EcRl/pSGofbXW VivQjpxsA/krwXIdKGFkNW2gKZa71qHgGpaSlHAZrAVUu94PArr6/5rtZzDHM8UoAMpTdZlaHORI WY7DYHxqClkdRHuxXvYAf+k703oV9Iuugfo5cD3XwqxnwfEkZFFYD7CEOWb7VgMxTgxRJgPD3k+g djvZ7WS3k9C7VO9SvUuBEqlEKpGgrlBXqCvgq4VfLfxqYVr7URlGZRiVAaaMnjJ6ymhodqfZnWZ3 0tYX2V5ke5HtaQ+3/BGFjxc+Xvg4dDrX6Vync/ALv/ALUPlG5RuVb8Btn9s+t30gS3iW8Czh4Ih1 xDpiITJHZI7IHGlTOyhJSUqmPfyS+jBh6lPwpc3SZmkzbX8zF8xcMHPB/19Q/13GjRs3btw4mPjN xG8mfgOuLa4tri3gWOlY6VgJX2T9IusXWf94nO9brlEfjvpw1IdpiebasLVha8PAOdg52DkYxmQe k3nMvyBx/nt7jas0rtK4Sv+8fv6s3L/nJ3/EplGbRm0aBYxiFKP+cf2ZuWfmnpkL1KIWteB6peuV rleC61zn+n/TX2qF687MOzPvzEw78Xr6ePp4+kAFo4JRwYCROUfmHJnz3fWd+vDYJH2SPkmHBhkb ZGyQMU1frXe03tF6B9CVrnR9f/76tn7we/b4vXZFjhc5XuQ42CvbK9sr//NTNP6snXO2zNkyZ8t/ XG6dYp1inZL2O2x82Piw8dC7QO8CvQvAi1cvXr14BTOOzzg+4zhYfrT8aPkxzQ5Dpw2dNnTa28v7 rsfRhx8+/PDhh2kPUwbnCs4VnAu+uf/N/W/uQ3Tv6N7Rvf/1fpDK2/rp+7Jr6gXYPxuP2apkq5Lt v5mr/Xt+8O9G/J+5bFJWqFChQoUKb99Bjw/G3C++B0oH5ttZvh64ovQLnl/h3Jk7z09dgYB1zoE+ oyFzGf8K2V6C+UrZY+kGb56/+ijiAtxZ8KhEXAMInZH5pOUWlLiRqX3Oc/Ck2Zvebi/4t6CG2R8i W2oT4oeCjy14iN4SlBtGBbkAXqyMK+2uBUG9xcFs88F8mjgu+RhkmppldIZY8L9p3ZlyB2JLJjlc bvBu0fbHToPc14JLVuwDBR4Hu+o6YNvlxX0WL4UrpZ+WeHwNUj6VHa2LIexMtnG5YyAxOmlD3CZ4 NvVF/Sd7wMgv8mkPwTxu2GRXQCGPvA6iHTdZCmaoNM3CIPfKs7I7iFyiuWgH5klzv7kDlJzqYKUS KGvEFXUByDvGF/Il4BB95QswP+EbMQnMY+ZN4ywo3+GiMVBOrhXNQVRWLogRINzKXXSwFNSwNwTx SCyhDyhfKRHyBih9lP3qZlDC1S22iaCd0B6o/UEL0e7YOoOcTG5zPcgbMkW6wH7cfsX5GKyaLaOz DajPlaJqKVAyqoOtZ8GSaP3clgWUGO2F2gWMfaIb20ApKx5ZDgO3zVDzLrgjXNWTZgE7mWB8Ao4+ 9q72V2CuNM56WoL+lWtEyvegVdS2WweDKGfZYf0KxA/qSusckPNZqXYD0zDDzFUgT4kQTQHxTFmm 7AFzl3lInw+upSlPEzqA4stuGQ+yNv5KZ/BGmI3VkpAyPiFnzEVw9/empHwKwb2DK4V8Br4/+CaG fA3uOW6flKKgnzVfJo8Hy1Jlm7oXLHkdw4PrgDva3dazCgK/cKAtAGU/P3rHQGzNBE/id6Cutz71 ewpqPqUR0aAc4KqeF3KUzRhn84XF9iWXFx379wd2Oumkk86fJbUCeVm9rF5W4fsO33f4vsO//5b4 /6uk3rFJrSCn8z+Ds2fPnj179j1UnF/NiM2jeuHMjw/Cbp8BucvzJGEUhAzw+c7pB4rud0I5C1Gv rfcit8DFhLORby6CbwXHKXESbK1kBbUNZJhDUIbxoOb3zWmOhzxXnKrlMjw/+/RJdBzoW62Tk7JB XP/kud4aoOUxj/uEgnOIKi1zwZPPnSBXgnNr4GBxGBLzimUvW8Arv9hbemGw7bT19S0GfsPNHL5T oNyIArurPwdDiW1pmwwx2eOPJYwF1xdGWaMOKJu0SuJDEDvVs/I0uC3uj7xNwKikL5UWkJFaMVOA XGaON5uCDJHZ5FWQFRgsM4N5Vh6V0aDeFHNVC5CNQzQHmU8+IgroafYSB8AYIzcZAqiJSwLckQ3E DJDnRTA2UAYqR2kNSqj4TD0OPJG3RQxIP3nKXAq0FKVFBTA+kDnMbODobbvkDAZ1itZTVcE61v6p z2/g/1PAy5DfQBwQn0kXKMNFP4sCptXo6lkJpmlcMU+A7Te71b4AtPy2ofalIJ+IDpZmoCarI1QB ljPqFu0j0OPMIp7KINxGXc9HICtLw6gOSjXNV/WAzxm/0T6JYA70rjVGAdFmJ09XEIJnDAXbbd9W gV7QMmvNtBBQe2m/2J+AecL4WQ4DcUY0kbfBbMlRORH0Bnp7ozqYN/TzKYXBXOUuknwYrPWkj3ET PA+NIGLB/bV3gZ4TYpXon2MKQ9KM5CMxWUAbQBP5FeiKq0fSr2BWyXLf7AT2Eo6Cdi/oBz2G3AKi rLJVzgPvxqQscWNATpU91aHwZo+7apILzGVmQb0FiJ7WC9Y9YM1iTHJtAmOM/pt8BYE5fKf7lgat H071NrDsrw71dNJJJ523Y9eEXRN2TUh7v+6UOVPmTJnD75f400nnfxHvnDjneJVpmfIpxHV3nYro DQH71ZXOOpCho+bjWAExluRsiQ3APUo7pn8OxcwCQb4GJJczFsv+oMWrm+yTwfY64aZlNJjlU1ze uhBoBl71/QbsKa7WxiTw8RPTs44C9zr7Z69fgvuqMSvlJLDP28DREsQCBsVEgKu83lW7DtoWpbim QNCQkLbBJ8B123nNNRjMr2IGOa5AyNcB1lwh8OutU12OHgLPKeaxB/QO+vfmOLBsshYTbYEFog2B 4J1iDNSDwRroMH1mguWGM8gvFvQI71B5B7iMQwSAfYLD7rwAtmG26/biYBYwftP7gPewLr1hoNxV x6t9QUh6K7+AMdfooH8CylXlQ5kMljvWSL+qYFrFQ7MssFpGiA2g/WSpa1sJvJF5OQxGsDfMfQzU waKMUQK0pRavtQBokVpFax5Qv9SsFg1YogjlS7Dks4x1NgHzV6SxD7RByi7tExCd6SU7glpenacG gfGJeUHPAXzNI6UPiHFiPVeArbKGfA6ymeyjVwOtLdfkflAd1p6OMmDEyjbKUxCz1abqOdA/8dbw 9gD5IzFUAutnlqG2YuA4ZG9vvQjuO/pPsgGYS80E3QJykPmdEQrKb6IVbhDR3Df8wfiAJKUHGA+M XmYH4KysJnOD7ymfYOcLkD/p283vIOJ8pD1yJEQ73gx81QU8rdzVEh+CecI4YDaFlIvebOZzMJdw SPGDqAuRrSJGgM8c58CAnGDr4Mjg+xvEnUn4JjoX2D90eq2lQDxTJ9jXgzfBfdRdC2xjVD9LJ7Ac 0X9VzkJyjDdr0jxw5vEtErAc4uYkdEn0Ad9LaqBlyluHUzrppJPOX06Tl01eNnkJTWjCe3hb3/86 tj7d+nTr079ainT+Vbz7e5z3J2RwZYWcXYLXZgZ8C9gKO59AYik1Xg8GdYH+mxoFGcK1PD41IThn zivGZ2CvYM+s1IeQJlnDwo5DlGoJjy0Mr/K+KmQ9Bnnv+xcvEQIZ1UwFApdCBpffXbcJGTrYkjL1 AuVrPrY2AB6wRu4A75uUNvIE2MZYftL6gDO3raE6A9y77FVfL4DoZpF3Hu2HDwrnflBqC4gxih8N 4FmRiIsP+oP3S/O64QDzllmdn0F8oTRQ4sDMY+YWvUCJ0jqrLyGwfMjJ0B0Qmjvzsty+kLVL7vsF /CHsUM4y+XQI6pTxWbb64OMK8su0DHznZvgsywPwV0PvZW8Cgccylc3lAH89tHqOTyGgeYYfw5aD b2BgvVAn+HUO2pd5M/iFBLbJdAz8LwfdCC0Ljop+N4Oeg+Nzvw7BZ8Avf9CwjIfAOSrgh0z5wbrQ 51bQZlDDHM39a4Moae3okxOs++0lffeDesQa75gD1tq2uz4rQR1rdTn8gIa2n5y/grlOqanOBqWC etjaG5SW6nOLBWyfWp7aVoP9uT3SsR+M1uYZMwzERK2C9iOIKuoBZQ9oEZYwdTuISBGhBIF9mv2y cxz4tPDJ7JsAdqePJeBjkD1FVstOUAYavcznoD0RkUQDu8wPXCp4wt0F4hqBK3NKn8S5kFQ9bmHs IHB1TGmX5AvKM2WZMhuUFdpu6ygw5ptTPFUgtEPgFcdSyJw/pEBQTVA+VZbZNLA/sXd2dITM93P6 5rRCxivZz2UfDYGNAisE7gR/H/8ivhXB8tz2SMsAgfUDSwe/gJBSgT0y1QaroVw3j4CWX7uglATz iuIRsWDMFAP0YWDra62jLQfGM5omoH8lerMBvEPYwf/iT7ymk0466fxvJdvrbK+zvf6rpUjnX8U7 V5wtn+nfBY4Bs3X0EUtTeN3OvTRlLWghQa6UkpCQh/3GbjAOR3zvPgRB5ZwLtFiwbVV/UXwhdow8 +SgRHBkCejsPQtJx15T4NXBu8Y3zFwDtC+sEtQ849vvX5mNwjUuI05uAXoZK/Aw+Ub4vlZpgqes6 5QwBb4fkJ55kcGcOaqs1BMvEZH/fDyHEos2VHaBgwWxZKzYCOShluJIC2h7ziKgK7kZ6HyMneIvI 5/JTcDRTR/ECZAFWydJAHs5qY0E7Z13m/wkYVcz13tfgXZQ8OPkayDaysbwOyo/aIGtfUM9aH/hm BXWJWtyxBJQBaku3DnKgft1oDKIsjYzWIJqquagMlkR1uY8T5Br5i7ckmBXMmmYxUOoLi7YIzBSK GfWAiaKOchTsSfaP/SwgbHKdeQYMyRf4AN+JouYY0D74P2/dUKeIibIj8Aqn2wDRmpXqShC3iJIt QGthNtd/AVP3xCfOBJooX1gfgZJPjdU+BWOSHoYXzDY0ojcwUfaXjYG6cp/IAMZVo6GREYyK+oOU QWA00LczDDy3vS9dkyF5VlxMdEaw3bTPsHUCe3d7f8dR8NECtob0AuEvpmmTQeljdnSPBHOY3Cny gHlJDuBjsE1UMypHIbmCu6q3L8RY4zYnJAEuv+aOKWC5pf6izgff837HAq9DwL6QHzJfBtXhfJVp EChPtEw0AvUD2xBLeVDnGCMlIOuI0nIyKLM1X0sUYKj9HUPBG5SyOGkLuM4mN0uwQdAkv2Z+W0HN rxa1dofkMe7vk9eC0Y4IdS/oBXWDb0DNq1a2C1CXWmdSGCiibdf6AdD5rw7ydNJJJ5100knn/fDO ifPLS9E/J8yDR2PUQ9FtQd3kV5TPwN41uZ5vJzCdrm7yCCRu8VhS4sB0uV7bO0Km8Y7HOZ0Q9W1i zJ1rkLeqrZs9LyRn0Kpp2SB2rDuf0RmMxITuyYfBr1j2Xp4J4Ghs/8V9C5KOXZ3g2gHeKtaimg6Z Vvu9CeoPzhbUt6+DDB3Utc5jkPjM0y+iOdTYWtpd7x7k3pVhSMEN8Nh++/mdzOD+VF4xFTAyiRFG YTBWsFK/DbK2OVTbDzKvHCrqAS7hr+YF5UPLYkcVkD2VnNpNsJV0zPa7B9613jyeqaDVt2bSqoFS STzVGoBZXK+cUhcIJMJoBHxtJorRoNxWW4t2QLiYpfUC7YS1gaMvGOtlDDvBmtc6yaKAvKPHG3dB /my04QloHm2lWAGen/XzyRFgzpbPbENAm8ZQ+TPINsbglMrgLW9e8/YBzzh9vCs7iPrKcTkX7INs W3z7gGu6Oyx5JNBZyU090L6lvS0ayKtl8eYB4WN0ozuouppFGwbGYMPtbQ/mx/oH3vuglmCmeRtc PZKLJTaBuLVxVd8cAndP9zRXITCW6dVducGa1dJBGw7uae4bohQkhcQNV0aA+7Z7bEoPMD2KYZsM NDb7e3tBSoPE+MRV4PfC/4TfYrA98SP4INiW2+7aSoMl2JLbYoJ+WFY0yoAjv6O//UvQ6ju6+T4C /Qd5lBwQcj9LbesMcC9O3u39DLw1vJGujSDChdtbCtztUmolVgVzPCfEKVA2KscS2oC7WkqdhJrg VzZoeIAFnAN8p/iegaT88U0Sb4M4aiToa0FbLawEgvtjt4164Pk45VzcfTA9akZSwG+gWsgny58M qnTSSSeddNJJ5z+Sd38dXVdn88SGYEuxF3J8Dimxeh9zHwTUt9XzKQF59+Wq7ywM97I8uxn9Blyn kn9UH0FiS1dIxD2wbrdvUMIg9lBisLYJ9MYps43bkPRAKZaSDRz51aJ+J0DcerY52Q7xHVNeeTXw 3tb3+h4Ht90o6coIOZICd3geQtZu5SsGbQTlkqNpzIdQtI/epNwTKNuw4Kh2DcBZ2rdYaCTYT0r9 XjiorS/3EE9BX6EPFq9B3WfmEDfAaCdGeaaCmU0WN/sBbeVqIwfI5eY28x5YvrUU0JqA51Ozr1Ec 1Pr28fYYULZq9S0fgZhnzpM7QXTSs3hjQT9hdDGvg6nISfpFUG/IjJb+YDlh/cVaALwbvP2NCcB6 sU/pD/pxT0t9IShtyaysBuNj74u4xeApllLA0wnUTuob50QQ5az5lYNglvNGur8EOc7I460Jxh2u m8tAySFTTD+w3rKss44DlyXFL8kP9DC9SvJB0Hpq6yyh4FlrXJHfgWe7e5c3L1gXaIptLCiXlBLq GTAW6VfcB8FeyHJN3QuumMQB8dMgsVNC0+hxYM7XFxsPQe/p6ZP8G6huJUb7DczC5BGXQO+pHzTs IJrKId5skDz9dYOXGtgyOdf4PAFlH4OFF4xwb4o3DqIav3mTshOcbb2jjCDQZlmq2QNBGans0JaB rZNtvNUORn+xRBsG8eXdE40RYAbJ3/CAd44+3psZtJnWbdozEHuNr5WK4Pna+6t+DzwDPEM9Y8Fd P6VcwiFQM2u7bUNA9SoZZWPQP/dIz2B4ufrV3deBkBQUr8S2AGsBtbzMC7a19vu+PcBSTxvt4wR3 hZQ7Kd+C9lTtYgOUneY5d3mgKfAe3hObTjrppJNOOun89bxz4myc1VdYSkDoDUcxuwkvYhNaezeD pki7owWktPb2MQ9CyjcxP1kE+F/2z+OfBA/7hGd89hS8rVIS1a7g5+M3V+8IUjUfqyNAPDQ6xs4B c7s6Vj0A0d++mKxUgkyfBf1sXwq+NbOvMMuD8iBhgLMX+LW1hidq4M3zpIQ5ATrUa1xp0seQ7+ec lWtOA0+Ano9vQM2t9DcygDgePdHvObDrzTFvXrD2t5SzPgRjhfpIvgTlutFV6wJiH4PFSTAfmKO8 ByHlUML5qCqgB3mqOAJB6aNEqVFgbtKe2xuC+UQbZ/sJ5ASjmiwItkX2OvZSYA1Sp1q/gZR8rtbx p0A2YSh+4L1u7DGOgSosvbUcIKab4z29waztaee+DjjUdupIcCUnnku4DWZj477+CKyR9iIyFjze xIevK4Ntnr26/QX4TvHvGtQb1MNKCcsq0EcZDwwbeOp61roKgfrUEqvMAFGGq8ZBUOZpS2z3wNtc OlKugVaX5koHiG0cvS8iGSx11XjlHJiZzXv6NUhZyEppAbO6OdXIC+o3aoLqB3ThjNIFRFfxEzro RcyRxilQ/fXz4gvw1tXnG/nAbGbu8E4FM9J8LIaAGc5KMRIoSQOxCqzXLbutn4HxkOMyArxD5BUk qINEQ2UayGSJrAQyXO6Sc8DT1B3jnQNmGyXC8IB1tPWs7RHogZ6aZjy4l+hlY6eDiNA3eyuAUlbt IR6DNl24tSygTQtoFjwenIGB7kyHgYfm53IlyBH6NL0qmIU8PxuTwDHbuR4ThIeK3tFAB+VXaxLQ RCwXW8Avt9/D4O/Be9B9zygF8V3f2F8NA2L/6hBPJ5100kknnXTeF+/8cKDWwH5DHoH4+sa4yD6g r/Kccp+HmErRmVO6w3XP3WGJuSGpoW07DeDNI0/9F1MgLEvQZhkGmYtkuKMsgaTXzinJd4G9rJCd QemuBlgeQ3BXyyHvZLA1VwuYY+FxtcTA2BuQMCYpWHeAuxMz3KWg+NNMw2o/gwHFW89YexNyT8iR t/ZySH7keuj1BU8274dxP8Pzh8+rX10KUc1vZQ0fChmTbd85y4FNU2eoNlAGKyd5CPKBaG2cA7FG 2anMBqmZETwBuctooc8Bbbi6xvoUnLv8LmYKB9+vA78OLQMO1SfZpx5YLzg9ltFgu2f7QC0JAulM vA2OXwIOB5YG33v+VYNbgvOyo7otF9iCtHl6WVCHIOSvED8i7qM3xyGxbPyO6Gqg/Ky+0OJBb6jP 9jogpVx8hVcOMHfrDbwPQY4X4ao/GK1lgLkS9JF6T9cFMKexTt4Hezn7BUcV0HJY6lj3gXbMcsBx CuQN5RfLG5BfiliLBE8vVzXPWNDregd6ykJi1oSHURfB9TIlQ3wmSG7gmppYA+RToZurwFwj78n1 IJqIzdIHOE4LsRtMX6OlsQbMSUawVwfG6V09w8AY4B2h28B8aS73tgDvQe8Md2eQQWZbcQfcZbyT PfXAOsR+2bc/aNuUL60bgBfSS3ZQt2v1tK7gPaf30n8AT7hnbcpoMAcYMfpdMMvzHZXA8qttpCMC 1JPWb/xKAfvs5y1PwV7GWcC3NjgXBj7L8Ax8qvvnD80Ktl6WeFtBsIy3vLL1ArevJ7/xK2ifKk3V duDc6HxkbwU+ef1aBkVBQI1ga0hX8IkKqOYfD5a29qa246AdkC28hUFdZatseU8fP/lPZlreaXmn 5f3H5anvMf13kfolr5kzZ86cORNq+dfyr+Wf9uWv1A+bPH/+/Pnz53+11v7fYdWqVatWrUr7gEHq FyAH3hx4c+BNiMoRlSMqx79Pnn+1X/2eP/9P598dr/8utjzd8nTLU5jyZsqbKW/+cf1/mn+n8/8G 75w4u2y2UfF7wOEXeM7nKVge+5SSrSEx0igfY0LUZ9E/vFkH2RZaEgPOQWzF+ELKOvDNaduXJSf4 5LB/p1yAAjlDnvhGQ0CsT4qyEHL18euXaRpoCVph9WuwXJbLrYtAm+h1BxSCqHOv7iY2hg+mh1gL fgFt7/S4O+UMOKeHaFnzgftHV0zibBA5ZaReGuKuvQx+1RvULt57AVdBWZ0QZsyHzLFZdP+NoDQR 983KoD5RH9leghxitPG2BBEmq+sfgX2Q7Yl1FvjMCJoZ2gX8G2XqnvVHsM31X+iXEdQE2xPbabB0 dbic68DvfJA9dBl4eujzkl5CojPu/KutoJ73zkvsAp6A5Hpx88E9ODl3XHVILpn4dfxBwCI3mOfA V/erFjQS1JvqXNaDctu6TG0I1u1Ot8Mf7F869vjXB98VQTEZw8Anr4+v7wmQvXS3sRFkAdFf7Q7a Vi1J3QdmbbOntw4kDU0aEf8lpCx0y+RSED3v1YDn5eDF2ecF7z2HlCmuJ9H7wf2Bq1zKAtB3efca NcHcaBw1iwGr5RI2gaekJ9YzGbxlvIrnMhhWo6SeB5T+SqjSGEQVYRG9wWxHefEr0EKJVWYCgWKz WA3aFHWAdQOoh8Uo4QRveW/l5A9AOaRmU61g22PL7XMNNNTKWk0QxYQikkGZpzXWDoOaYl9pLw3W R9bu9lBQe6otldEg6+n79UYgTsk47x2wjLMlqyY49jtLZBwEZlNlltoOlPbWefZwsGa0BNmngLHR c9HzAFxfJ26JuwjUkHO8L4AKjHJ1BbfF1Th+MSTvSb4b3wrcx10XEmqB+2LSpKSXYPbz7kiJBVsP 59eWDyBkbMirTN/91eH9ryf1k7d/NSdmnZh1YlbaibDnmZ5nep6BT5d8uuTTJXB23tl5Z+fBt22/ bftt279a2v98jh49evTo0bQLkRqf1/i8xucwdM3QNUPXwKlup7qd6gbTC00vNL3QXy3t++M/xZ/T +XMcbne43eF2aRdAUw9MPTD1AFxccHHBxQVp7f63+nc674d3Tpx9THe/jJMg0PS15rwNYeX8T4Y1 gtp3c64uWwjqb6vxqPwZCB4W9FCkQJlv8h3M1gXkPq2u4QHfhz7fBN+Hp/kSZyY1h7jcKT6W5mCU FcNTcoOySay1J0PGZYEFM9eFbDdVv5hq0PByoe0lB0NPv75XZ9cHV5DsaFYF46rnYcoA0GZrMfbj kDI+qXh8ADh62RcrZyEm+ln+F8XB9pPVbo2CwoNKR5YRYOup/Sg+AK2Y2GqpCrK5GUFHMCJFI/V7 UEztV/sKULYqD8UdkC+M7J7fwPDx2JO7gvGrq17Ca9CPulon1gJP1uTmiY1AGkZmyzJwzvMxg1eA O0tyv6S7kJIx+U2cAcZ3+gfyDCgtlfrWMuC+YXyV8hVoD20rtWfgzBtoCUkA23mfp36TwO9+cFym B+BICvol0yKwbLe9ceigJ+mK/jGYQ40LxmIQpvnQ/AaYYJQ0KoHH41rnGgHW/raallqgXda2W+LB b2zwtpB+EFYrm6PwaPAb4vNbpi/A/FEfmdIAjA+MTd754B7oCXJfB4/qOeNuDsZWfZF+HEyvlHoZ 8A7Xu3ongu5rHjQAozu15DMwUvTFnllgvjAuelaDmqTsFjNAuarutrQCLbc11ncV+AVnqJzxFQSZ IZ9kywjWZvZZfgVBLLTPcH4OahZrmC0OuGB8Jz4Fa2c+sI4AmV1EqRtBTsSp5gf1kXbMcgxkKXlY 3AXlpJFPfw2yuHeIVwMqGfWMX0HdrJRUMgBx6mf2PKBOsd6wqWBf5zzuMxZCP844O3NlsPd3fBMQ Br69Aw5kqgQBqwMuZwoFJUpr7LwD4qqa2zIXrFdtp33agLlGG+nIA5Yi9g3O6u8vUGNjY2NjY9M+ mdpwW8NtDbdBswnNJjSbkPbJ19R2e/fu3bt3L7Ru3bp169bQIkeLHC1yQOPGjRs3bgxLry29tvTa P+7n9ypPf798TPiY8DHhab/7XOxzsc/Ff9wutdLTdFfTXU13wbwS80rMK/H24281pdWUVlN+Xz57 FXsVexVoe6jtobaHoEvnLp27dE7TUyq6ruu6/uft8M/q5++XT+84veP0jtAkrElYkzD47vB3h787 nGa31Pfmzi46u+jsomnb/1k7vqs+dzfb3Wx3s7Tfn5T/pPwn5aFC/wr9K/SHfVP2Tdk3Je2TxO+q zzmn5pyacyrNXl2KdCnSpQg8z/g84/OM/7jdH/nV28bL7/nz2/YTEREREREBPbw9vD280Lx58+bN m6fZ9Y/8ZOWtlbdW3oIOCR0SOiS8exy/b70mJiYmJibC4MGDBw8enObPqXd0UvXwz47vfflrKqe9 p72nvfBq4quJryamfQHxr/LvdP5n8s6Jc0CugAPOXJAYmXgiYiV4LifdiWoL+gXw/ghjBnVLWlse Pm7TeNeAdRCa0c8/JRny9claL8swyDJf+9TvNGRu5GxpXQ4ZcmTsbJyEl4YnyHoLnn6YeDdqEij5 3GXu9YMGajlL+5rQpWNfZU5RUFoElPQXIEp6v1GLgWinBqk3QL8pRxknQfqbH3ueQFJ/7yLXDxDb 8+XriJGQ8/uSJ6u9Bp8FoTlzjAFHgmWNlgnseTVfSyAYXeR2cx4oDnyMj0CdIPqL4+B+lFzf9Qbc +V379Gcg55nXcYEu3cHu9SBtenXvTDD26t96boCWXaw3+gF7rVUcMaDdsfv7WsCBs7q/A/jQekY5 CNbtjqqOY+Ab6p8QXAocF3x2BU4E21j7D74RYAmX9UUe0O+k/OaeA2KUVsHiBXWvtZ6jKljwtQUH g/UX34JBJ0B8qm61fAme2eYqtQVYmjvjA0qC9Vfn4QzDwGn17x92EnwP+RXIWAh8OwaVCS0BznZB YzPNg6wD80ws9SWEJmadnyccgndkGpHDH4K3ZjqR42fwbR8UlbkGWArbknwDQUm01POZDX71AvZn qgBBCzJUznYNHH18l2fSwO9hcL7sv0BIu2yjiyyDkDw52hXfCMEic3De7yAkW6aR+R6DvbXPyYyT QNRRyqrFwVJHPSY+BmWOdBq/grHHqJxcClKepHSK/QS8X6Z0j58DzNRrujqDEeJpnxwGSjYZaNYC o6a+TskOZnaCPQvAbCnLWxTwVPRkM6LAu8bzU1IvMPp5PCkTQSkoC5l1QSzgDnOB28KU7cFT3L3T 0xj07d4ofRXIHKbHnA2Kj/KV/BH0Au6NxgZQrfiIi+DMabHIiPcXqFP3T90/dT+EPg19GvoUdr7Y +WLnC9j6bOuzrc8gbFzYuLBxaRXVNffW3FtzDz4u/XHpj0un3bJcdm3ZtWXX4KfzP53/6fyfl2dC 1glZJ2RN+72wzMIyC8v8Y7taNWvVrFUTllRYUmFJBVi5auWqlaven15SKXe53OVyl2F4wPCA4QFw cNrBaQenpSUw2V9nf539NYxvMr7J+L/giw51htcZXmd4WqKzbvi64euGQ7tp7aa1mwZL+i/pv6Q/ rFm7Zu2atWnb/avt+Hs8e/7s+bO/mdLSvXv37t27pyWC7du3b9++Pdx23nbedr77/kLqhdQLqZeW 0NReW3tt7bUw7ci0I9OO/GP7P/Krt42X3/Pnt+1nWty0uGlx8NGjjx599Ai2bt26detWyL4n+57s e/55faxetXrV6lXvbv/3rdf58+fPnz8/LYHd8WLHix0voMbqGqtrrIYZv874dcav//z43jejN4/e PHpz2oXq7/Hv9u90/mfxzg8HijXBB6KWgr2yZXtQW0jeELvD8xxsL5jv8IFdE3aOmHkUzM2ungkj If+TzNdrTQNrknupZzg80o0TNyZB0Zv2r6qFQfI3whNTGY6Ena8RnRsKVgoZnWs4dF3Vtd2XuSDL 2fxrytrA08/7rfdn0Lt6tuuLQXmovpYnQclJJjUa9LXeMFcgiGFmpOEF35X2dcHVId+dsj9XKwz+ e7M6g0pAUrvIme5JkKFx4D6/iqDVi/oxuT/I+u61bjfIR+YayoJyXRumDgYxO+WQ6zCkfJJQJ3o+ eLzWns7jYCmuvWQuuMyU6a61oDXUrlqugholr8hcYI6RbqMeiJ0iRGwB/aVe1/MrWKyWqzYHGF+4 1iasBv3bpFhjCAhdfaKtBesge0/fn0AMVW9bioKaYPtBWQb6XX2Juz9QybhuTAPmy9+MPCDClUza UjDuyjfqWFDyKaeMUSA+4CkHwXio7xZXQAmxdpJZgT3KaXUqmLP1PMZd0O5Y+1u/B5/slvWZpoOz pRkZmgRKT4uf2gbweuamXAXvLM+rpM+Ac8Yk+QmoHq276A9ynvhFKQuWycpYsRKkR/5kXAKjjlRE aQChqxVB+vNM6QR6A7MdRcFoqTvdPcFWyPpCKQbcMLpbTDDyGS53ObDf0MI0Ccbn1kP2hqDswc8E 7B9ZGog5YFw0r8m6oEs91IwCs7iIMkJAmaistYwCtaxW0BEEqilua9dAC1Bq6/GgF/a+8gwBsY4v 1HDQyqg5LP3B/ZH7qtEJXNGeO4YKShuloWU2GKpZUG4DpkiXuA6iiuq1fw/iiqW62Qt8vGoTfSPY DWtXNea/gqTduwfqqe6nup/qDjsy78i8IzMovyi/KL+kre/eoXuH7h2gUbdG3Rp1gyP5j+Q/kh8u 9b3U91JfWBe7LnZdLNw9f/f83fNgNjIbmY2AXvSi17/uAJN6grWEWEIsIeCt763vrQ9c4AIXfn+7 1ArTk81PNj/Z/Pv9pnLhwoULF/6mv5yTc07OORmq7ay2s9pO+CXjLxl/yQiLLi+6vOgyjGY0o/91 w/4HSswtMbfEXBCLxCKx6L9ZvkVsEVvAW9Zb1ls2TT9LKi6puKTiu9vxbfWZOzp3dO5oIJhggmHQ ikErBq2AHHtz7M2xFzr90OmHTj/A5JyTc07OCdvYxjb+PE2yNMnS5G9e39gyqmVUyyj4eczPY34e A5zgBCf+Ud7f86u3jZff4237kaVkKVkKJmSbkG1CNuAe97gH9TbV21RvE0xmMpP/L3po07pN6zat Qbml3FJuwZJzS84tOffn7f++9Xok/kj8kXhYe3HtxbUXgc50pjO0jGwZ2TISlsxbMm/JPKApTWn6 x+N7X/769/H/R+gl9BJ6Cf5t/p3O/yzeOXH+zfpbK48G2aL92xrtwT5F+dKcC6fXPS906RQca/2o w9HtkP9q8PKwMVB4bL6bRbbB6x74v1wFl2vfPfd6LmRzZOmgJwGOJF+XFz4oWuCTfBOgfdZ2ywc1 gCBLlqDS8eDekjQp+QAYiZY38gwobcUV7TOQ35grjQagFNJy0RuMtq6E5HvAFO2l9SIo+5XVPvvB uOSa+WoueL9P+cI2HkLuhPnl7ArZE7LPzTYeLpiPf4jaA8ppj6G0ALOT2ddMBK2upaztWxB7vTm8 i0DNYJ9gaQyWJkpXEQ18IZcZgNhBYeUpaJplun0jqHMc7ZxvQNTSO3kFKCPNoaYNxM8uPbk6eHO7 n7pmg6mZ7b1LwWvTV7g00OLVTsoq0F+Z4eZFsFRxtPIpDEop9YbWC2RRs7vsDPptockCICsZJbyL wF7eNlMJAccEewf7cJCRUhXdAav0NweAq793dspR0Iu7Gok2oNSxVrIPA+WcuKNuBm0t7ZkM1su2 SBkOYjvzzFCIbZHwYVI24KXxWq4A7bIWZT0ISpi1sXofjM9dk1KugtxpbnMXg+Q54iEHQDXkOT0b WHap+7VCIK7JKWZWUF9S0WgDyn1ZwSgGaoD6meMWOJO1EWotEFO1x8ZBkA2JVTtDwAf+RQOjwZVd L891MEKNreZDsGa0r9fmgJwv8xtfgbeVZyEp4I7yLnd/Dw67bazWFMQJYSr3Qd/n3Wr0Be24WlNs AbWArafdDuKRzCvfgOiilBWvwSdRFlJ+g6AJPof9hoNrg/7COAh6edOlfAmygP5ElgH1ujrZXABa BtthW2nwP2Y5q44Eq7QFi4oAfPI+AlWWlqVladD2anu1vf+4XlwUF8VFMJ+Zz8xnMNgcbA42IXRv 6N7QvWmVpKpVq1atWhW2s53t/8R+PXM8czxz/rzclqWWpZalb7/d7GKzi80uBt6O3o7ejvCZ7TPb ZzZ42eRlk5dNYOPGjRs3bkxrf67XuV7nesHNFTdX3FwBPYr3KN6jOHzu87nP5z5wYMuBLQe2wM7Y nbE7Y99f4vzP6ufvE+Y/Wp5K6i3xd7Xj2+oz9Zb9o76P+j7qC5UqVqpYqSLYb9lv2W9B0KdBnwZ9 Cq9bvG7xusV7UOTfoSxSFimL0vz+7/kjv3rbeKETnej07v2kTg1QD6oH1YN/0+6SuCQu/fG4U/Wb yvuy//vSa2TOyJyROaHW7lq7a+0GylKWsoAVK1YQU8VUMfWfH9/v8bb++rYEbQjaELThr/PvdP7f 5p0TZ8+GuO8s+SHlgNYwXgfr12JqYEmwDzWaGm/A/zufRblGwJsCyhEjAK6Xf/TgZiJkyR1yI3AG +NfI9IlvfXi91BN6KxGqLihUtn5r6Fjww8TBMWAN8y+aJwK861JeJd8H5abqEIVBC5O/qH1A9pLZ 9Rpg7uaFcQKU28wUl8Cz3HswJQKcs/0jQh5D5JAXGV7eBstcS0vDD6ydnZH2CaB4LI0clSFsRY5K WXeC84j1xa0jkHDd0842AIxxcpFIAOdraz5bOUg4Glc4bi4Q45rmqgCWIQHfO5LAHeDOqucBW0t7 oLMRMEZ8SGZwz4or+/oB2Orbf/E9BGKzyKZ9DdoMy1z7SxCD1Z+1J2DDFmQfCdwXu0R5EKuMT41s YHyvV3SPBzW/EqxGgCe7p5aeE2zLtKpafVC/tVptJsiP5HfqaqCg8VpvDAmDYrWoF0A144C7L7gP 6ZXlDbA/973kHw/aU9v3vi3BUteiaVtAK6Hetd4Elpjr9EAQi+Vmz/eg/UoGS2twHNPKmoXB1sR+ QVwD513nU7UUqPEy3Jsb5GDrKdUET033JiM3pDiNPNIP7KOc9/zyQ8oFbzviwLuG75Wj4L6gb9F9 wNZSza92APW++rPlQ5ALlIlyKzhSHAftTUH8JOur1UEvJcO89SDgsCOrJStoDdXO1kygrzJ7MBLE A1FRMUDOsqSIj8H7SF9GMFh+tMzQEsGsYVaSv4Ay3nHRchy8Hb3rXSVBbaaNVlUQ1eUymQPMZuYK IwREZuWNKkHJzQ6tMPhkJ0YaICow2mwO1gV8o/wCnmB9sXkX3NfN74wwsD1R7slvwTnSmt1a4b+C 5MN3D9TUt0MsH7h84PKB0F/tr/ZX09YvXbZ02dJlUHV71e1Vt8PJ2Sdnn5wNW69uvbr1KmS4neF2 httw5syZM2fO/E3HpSlNaeASl7gElmuWa5ZrEBUVFRUVBff73u97vy+wnOUs/335Ut9q8UeJ4D9L 1qZZm2b9m4qVdYp1inVK2u9cuXLlypUr7fetqFtRt6Jgbom5JeaWgKTuSd2TuoN/Ff8q/lUg0h3p jnRDkVlFZhWZ9efl+rP6+bNcuXLlypUrb2/Hd9Vn9RPVT1Q/kdbdzK4zu87sCoHzA+cHzofIHJE5 InNAdWt1a3Xru49zx8sdL3e8hA50oAOwOXRz6OZQKH2h9IXSb1FJTOVt4+XvSfXnt+0naUHSgqQF sMdvj98eP2hJS1oC+1rta7WvFTCJSUz699n/fes16/is47OOh8ktJreY3CItnl6MfTH2xVg4M+LM iDMjgH3sY9+f94e39de3pfrt6rer3/73+Xc6/7N458TZedc/T8gsyNrdv1CuQlCqYqaPcteFoEsB B7x+cNb8bcvjJLg4KrL1rTOgb8pUy7kBgg3PKE8AFFnnmeuIh7pbG42edQSKBeXvWTkAXIvFWGc/ EEPFN9Z+ICPFAr0eoMiNJIP8QJRlGIgOcqjSFdQQZZpaEvQ42VxJAkdr2yzfjhD36NXx2Ofw28Wr 2U/HQqFBpWdXeA1qBu2ZbSXIfSDuQdad2RtmWwk+QfZl9uOgZEnp75oJTDUOKPFgibBksM0Ba4J9 o2M9GEUsI9SPQS9PhLgEPlbfuf7jQN/tDffUB2OwPsBbABzZnOEBa8A7VI/kB1CqaS/U7qBWsETS C5RPzeliHogCym5lFxhxxlW9Mnj2uSulPAD1iXJb2wnyogyQm4BYrbXiD3K3mCg/Bu86T0RyY+CG Eq2cBWOW+4KnA8iy8jdRC4RqDfUdDc6XzsEWf2Al3xo5wFzsGWcsBs8102M8Am8Txcd9DYxT+ivj FsirehU5A8ww+phPwBJpMTUDrD0pIFpA4oiECUmPwShphDMFLJ+pB2Rz0E1umQb4Pg2YHPAKXOHe wUo0yATF0EdCpjyBCwJug5/H1lMpAJYt2iqlKIhQUUypAd6Lnpn6x6COIKPyEYjV6nlFQlIFzxp9 IFhGKI/NNaAMUsuq08AoJjuYl8H7m2eCewhQji1qAfCO8ZzSdTCzeD91NwHbBNtMrQUIu/mEjaC8 pJlcAsZ6va3+GGwFrN9oAaC2FiMsY0GvbswzD4D8Vswwe4N4LDsbGqhX1NvaQpBH1XVKELh2Ju12 VQfjnuIvW4NxQnshboI20Bqr7gXmvZ9ATX1IZcroKaOnjIZmd5rdaXYnbX2R7UW2F9me9rDSnpJ7 Su4pCb179+7duzcEPgh8EPgASpulzdImFD5e+Hjh4zBzwcwFMxfAYAYzGOhSuEvhLoWh17xe83rN gxpf1Pji/2vvPeOkKra+7WuHzt2T8xCGLDlIMpAki+QkAgqSRQFBUQEFJAcVREABBQRFEAmi5IyS c85xGJicOvcO7wefeccHD/fRA+f2PPfd15f6Ve3atdbeu6vnP6tX1W4w4uF+FYzT/XD3w90Pw7d8 y7c8fn4Y9cOoH0YBoxjFqD8eL9hO6uKsi7MuziqMSPn7+/v7+0MdtY5aR4X3ir9X/L3i/7off/X+ PCoFi67+6nN81PvZrWy3st3KQkaPjB4ZPeDH+B/jf4wH36++X32/Fm73N2rMqDGjxgDf8z3f/+vX eb3p9abXm0LLOy3vtLwDEUkRSRFJMPXK1CtTr/z18f7qfCngwc/zvMh5kfP+wjjOp51PO58uzLX9 ttO3nb7tBE2aNGnSpAlItaXaUu3/vuf/uO/ruHHjxo0bBxOmTpg6YSp413rXeteCZZllmWUZjEgc kTgi8a+P+8/4Z5/Xv8p/9+c7yP8shN/+c9X1OnXq1KlT568P8GxS/9HF+kLd74ufrLkN3tnb/cZr aXA68crrZ+bBkvI/d10+AMQL9rdNTeDeT+kLktPg5Ya1nm6wETrmtS7z4S/g+zbQzTwHxDW2w6ZN YPjKdsMeC8JgbbDuA9Wr/+h8C8TtwtuWSaC/ICyVo0E8zovKVmCvliJdA3KMxeWbkNspfeDtKMja nHosszuobyovZRaHxJGlmlZxgHW1pUnURpA2mcZKfeFa9QNv7HDCBN+E6vOmwuU37qekzQDjAVPJ kBMQtjChZ7GK4Gye/dP9V8A3V52ttwSDwXYqpAcIDnVL4Edgomb1FwPhU8aIK0FsIVU3zAPtsJgh 54C1Z3iruDug7vM84+4LeWOzi6UeBD1aLRXYBIbT8jK5GBh+MYXYkkHbxdPiOVAVX3ruMdAWGCpZ T4E8RFwrlQDdoDXXvwLpsDzXMAj4nHeEo6CZ9ARtD8hfG5dbNBB/0OOUS+Ar4y6aVw0Cuf7+3kkg z5d2mHuB8IRUXrCDUE0cpd0BeaOUbwsB+WXjBmMp0KO1aoFxIMzSxmq3wfueb7R3IWipelnVCso1 /wl/Q7BftfYx7QUTtkuhgHJabSRlguVryy6jCcKGWiMNPUBYGIj3NwDjd4Yr0jtgeFFqJlQHczHD VbERSD1EJ+Hgrxp4Qu8H7nTvKk8+yCd1s/o+KMXUMJ8E/vDA9kAdMFyUjxosoHbTBtEc6CKsYwfo I1QHo4Hj4pscAp7WHcoTYBtmlyLcoJ0UnpOrgFRDvmLSwdvLO8YdB9pGZVOgGhi/MpaV/CB0FfeI dUHxC2OFL0D7WWkk9gNCNWtgNhhvmSpLn0PUSutd+2wIrR/xhnkUvPnO+0ffP/d3T/MgQf4zKchV /as5qv+pFOQAV69WvVr1ahB2Pex62HXImpI1JWtK4W4SBbs2/Lv4n3ZfgwT5T+DQoUOHDh16DBFn UoWw8JNwvua1Acerw6znvrk+oyV4aipn7Ochf5bBq4sg7s4dmdoYXpkV3azOPmhXpfoPH3SE3LM5 qa7e4A1N63R5DyQeeNrWuAf4B6irlUUgjteTlFwQNWGhsTcIuWIDYTAIw/UsfQFo9YSp8iJgCnOU lWCyCg0NT4JvonTFkwG5XY/s2ngcXEM2zz/1BsROG9tk3F3Q71beG30V9I95StwJsdeKlU5aAUUr hW8JbwjXns/s5DwIPkNA9E4AraSuCLEg3zNes5jAfSL3uayuYFhpecKigJQsnZcWg9qZ1kJPMLST 1xjvgfqxNkJ6Cpijrg4kQ2C7637mIvDP8+7w1wLLSfMrliQQUrlnMoB2Su+htQQ9nA+05eCfG3jK WwWED1GktSCsJ93wIyjzA2cDt4Bkvbv/RZCHiPn6KvAfCpxXwkDsJ44Uj4N4WPxVvwliP2OU0QEh C0LPhCnAU9qzgURgi3TNPAh8Ez21fH3An+Ib5OoEWoye4DoN7hWe1JzvwVLeOs7mBt9apao6CNSL 2iR1Dlhn2S4bR4LUxhpndIDxsmGsZAX5Y9nDEjCuld7XvwNu86l6Dpw9/A3Fd0B6XghIg8H1nb80 oWDYJ+7mDgitfZEBCxiPG84aVoO/uO+7wPcQaOn/WJ0G0nuaqgwD6ah0SkwA2wzr+ZASIC8Unxf7 gq+n97i3E7g2eRZ754DSQRwsSeDf6S6qWsDcxfCt4WWQPvT18zWGQCX1I88AUH0M9FQCcbY8xrQc FFlNEgaC0+4MdbcF01njD+Y+oP7gn+VPAusAS3t5D2hhwjLzJFB/UfeLK0C+YD0knADBK6+W5/7d 0zxIkCD/nezz7PPs88AZyxnLGQv0r9C/Qv8KsKLuiror6kL1mOox1WMe3U6QIEH+Ph5ZOFu+MVV3 vQgh2b4XooDk5ffcgW8halvcYG08mM5pqZmnoaMz+uvax6DNltZHxnrh1m7v4DQNrJfTv3b/DJHF Ki14sihoC7SlnAYhSR+n9wU1RF+Q3REku3gozA1s4KJwEfRr+m1xHhCq/ujvBFKadantObhd+caR A1Xg7pCJH41bDaYev/6Y2h20Er590m0QP/Emqi1AVvDL1eCOuK/tjiywzY2a4vgcyolVvKU6wv5Z t15MPQD+BF9N30sQeNZXVPkQDL3NQ8P3g7A/Z1nWK6CX9Rv9KaD/bPzVshXoo5eQ3gNlubJOfw2U DUqE6wLgE/OFTPCvy96RGgpSb8N0gwVMGy0/hVcHz6ve055lYLlkbWU9BGppta92FkzV+FSqD9Im abn8M/CGeJW9oG1UP1DXg5amugz7QSjFTbUySC8L7yu54Nf86dooELpoNwMfQdTzITG2RPBe9Hzr +Q7yxVxr1kagk/q0fzjoafwgrQFLY9v60DsglJG2ij1B15Vl3qXga+1b7+4PUjNDA+Pz4Khk72I5 DUIpzS33BnWf9opSEpRmVFDngu+872reXdAnaOu170C+ahhvbQvCDeEn00vAeM4KfrD+bN1sAJTr 2jRxEFBDb8Is8Eb4nvF/C9oJYZ/QFwx7jDetDcDXzNfJOwg8W9zHPHch63lnu5xqYJposEmXwXBJ HmUYAtn7nC39IyF8u2OC1QWOjfb9YmNQ24pdDe9B9g7nWs/3YHIJYYEICEzULMK7oB8W4uUrIG+U Rkufg+mwqbc8E/zfe/t6r4FoFCI4Av4vFV9gPShuNVI5AvYGxvflKDBfMQ8JdYB0SvxCfg6AMah/ 9zQPEuQ/k3W3191ed/vv9uLxMXDBwAUDF8DIWiNrjawFDawNrA2sUPGViq9UfAUmbpy4ceLGf78f /9Pua5Ag/0k8snB+sktYwyL9IOeGOCUkBsJm2lo6tkBoJVPHwHroXrFLxFsDoVKlkn27zQFtU3R+ 1E4Ie+Kc9+B2sGVEp5V3gOm5sIUR98AXHvgx0A+k57Xz/lYgTtGnyQtBnMdx00FQ++pz9Y9BqIzF 3w6MHU3vmdeDO9qpptWDU3M+ufpREpRdeLBThh9s1Z/YWUaDsK8MdUNiwFq9/KDS+0DxBAQlH6yZ RRsVXQvWY7bWJicUsUbdisqEsIb2E2E7wHnEFZ+3DVwtnD+4kyEsN7pRfE8wljDPsq4CfyO1ohoC 5lHmQdZI0PcKW/XZoL7gv+a3geWAobzhBVBekd+2lQPzE9b0QAxQRK3r/wJ8l3zHPdXB2NXwnPwx BPoHWimNQeghLZebgeF9aZiaDorEBuVbEKfqTmEvGKrKcRYf6PFSe+0o0ENv5WkPQoTQXp4Mhtmm mcbXwTjOcM6YBd4+znvZGyBVvvdaShUQexueN64D2W6obIoBk9003bgV5BHyemNX8I/2HnUPBjFV OmH8CSSX8Z4pCgwt5N5iBMizuKJcBENX81vSTaCDfsSkgW+8MsA/FjilxUpdgXbiBf118C/37vcv BvFTvU7eZYhuERZhlkG8qToYCIZpsse0BwwbjFgHgKefv2vACoGWaoXAHZDrKCNEEQythdr6dJC2 GuOJB8Wn9hNXgv6x9n0gGYRRYqKxKYS/EtU/ujH4B/imqL1AP+7vpt4BVRQ3SzXBvNR0xFQWrPPN cyzxoO/Vl4q1wLTFsEjaCoaaQiUpFdTLyhV/IgSOy9mUBuGW6VfLK+Cx+vYrRcFqMpzkRYjZGP6E cRCENwvrGV4W1ECgn1IL2P13T/EgQf5zKZJWJK1I2t/txeMj5v2Y92PehyUsYck/6lCHOvwLKZF/ lf9p9zVIkP8kHlk4hyAnxi4G78jQ5vlpUORm8TqBTtBh/pN3BudC/MxSmTWjwL1PGCveBrGMZ6nr DISeKd216hTghjjPsBUCki/W+wUYdokbTXUgUD6/zM29ID5vJbEF6ClMkPqBMIdD/neBN8U4+T54 v3S7Xbdhf/Glb329AKy9ciZESZCw4F1DKx2y+16YdqYsoF+qczcCtP3KB65PQTpoWWguAqGVE4+V sIH5kqGCuA3kKEc3y3tg7m1pbHeB4a5lniMXXG5Xj8w1YKsSXiRuGBhfMk8JGQw5He8fu1ETeEd7 XqgH5kO25fZfQCuj7vB/BJrIOCEJJAuVhe2gmNVFXIfAW9p9tSzoMepAJQS4Sym9FGAWvpJugrxe 3ypkg9ZI3x/4DASvMFzzgTRL3mVJB8tS4zHxZfC+4BbdK0EcRn1lK4ir5UG22qC+IA6WFoCq+ce7 fwX/6IDd9y5Ef1q0Q6k6YNokvWf8AiSZo34fSPU1j/IVKA39S1yrQRpkbK2GQyDdN0HdCL75ntE+ I6hNxQliKIRUcWD9EvTzLGA1uFPdr3hTQa2u1fGWANszph+kOxCW5ng9pCQoHu1N322QB+j1DDVA Oi5kCAGw3jQt1L8A73O+5aIH0ufkbvV1B0sD41LtXTB3EO2cAa/Fn+49B3q0vkvoCeZVhmjj20CW eFYcAfp1tbLxA8g8nN49bR5QRDYZp4PyjNBWehLC0hxRpg8g3GsrE7kbPAG/0XsQco+749VbIFYR 5nmWgPyk+F3Ir+AZ4jnmawamvpYB8jVQyglLxNOQdSAjkLMbwraHRNjug3mDuFnzQYmTxYUwE9jX OtY54sAV66rmvQNAx797kgcJEiRIkCBBHg+PLJzvNnL2M7aB8Mz4PmpL8KWkf3DzRfC8kHMocyzk HxdKeDqBabVU29IblKt8qn8MUr7egpnARLWefwqIS8XuxuGg6sr+rBqgD1Z/0L8C4RPT22FxoL+I QZkOjNcuaifANM1Y1rwWDnU4uPRwNhx77WT3zB3QM6PXvJefh5BZz2XXNEH6ij4fDWsOLsVZJLMD 5ORvqLD8dXCYn7334itgulhie9w6yKmb3chVBO6Uy+1liYfYb+JuRC+C9FZ59bxTwN0l33prJ7hf dflctcA+yNEj9A5Yp5hu2maBnhHo4OoJakhgl34fDFEmo+NJ0L1CqDgP9LXE6XNBfVop6r8Chh7G cfJxMDitgyOGgJ6kfSSmANe0+col0PyB1a4dEBjiO+W5DPJPhpriSPBlea+5B4E+3hcv2MC/ifKm H8D6uvVwaFGw97CVFt8BLeDZ76wMllT7WW0DuGYosrktuKZ5u7nPgaGKPMezAfTQQIwnFqTBUlft SbA7zEPNbYDpUqZlI+ReEPb5qoFDlBebJoJ/RGAAH4DX6+7qvQquwfl70ndB5I7IWOsPYG5syBQ/ gMyYvHXOLyC3TPb8fB+EfRz6pj0SVFF4T2wA6lqixVfAYMnbrnQFtZm/cf51MD1pvW0YCbnVcz9Q 74C/Y2CUryYwR+zIfpBPyMsN74JyLn9M3jCQZxoqGuYDH2tL9e5gfNq60rIffFX8kd4EML1NUqAj iC8HjmuhIDfXa/nmQ0g/4wo5A6Srlg7GgRAwKMcMH4BWR3herQoGv22NuA0CS9Teej3wtlTiPRXB nGJMEQeBt1t+TM6vUHp10lG7BE+kVxpV7HvIi8puKx4D/b7weojn757eQYIECRIkSJDHySML50pX KzctdgaSx549424JjX942tNjBcRPqGmuuwwYZipj1UGrpmzhBAjfCV+KG4FtQpZhLugGNdP/EghT xDJiJujvOA1ZeWAYrTe3HgFmiV+JrcF/3FkivwII44R5ahHQWgT6sRFuX74zTh4IjQwvNaufBlFt nypVIQVcNe5PTnkVBCFnZ95+CDtZ5GSJeDDll3ix0lHIfHJ2lyXtIV4a3aH/dcip5LQGXgbjV9ao mOlQZkrJ3SXD4GbL+1F5lSF3Zm6CfRK4j+YF0r8Ey9cOW/FKYKkdMiJcAMMAbuc1g5AVjo6yDM6f PYfdfnCUt90OqQDUEPZLRUDeHV4t/BPw3xGijZ+Buk350hcJ3ko5uzOGgl5N76O8DMSLVyQBpJ3S eKERiFuFKDEUxDFm0TQYzBVs1+3rILSo0WJJA+tbljXmIuDPd77lnATqfP9WzxeQ8WT+MS0OnHX9 c7UtoB+R4sRq4Dgb+qm5Csi7xfe1G2DYIRXVOwE7qe03gats/kKlI6gt9RX6FdBUwWDcBlpXTdV2 gamZvF1MhxLG0iUT7oPcUj+jjYSrXVL0/G4gYRgqx4H/rNZKKwv+S/o79Ifwl0J/DQuDrA05DdzF IcOTezQ/GyxnzeO1L0G55Gyn1APdhlGPAfmYcZw8G/Qs0jCB+qM6Ux0Pxn2mw6ZQ0GZpglIfDL1N k4zxoLRXLdozEEjTftB/BuvL1mzTXQjsVI8JkyHjcFaLjD1gH21/23ERjEcNg40fgBQl9zVfBI/o 7um6Ayi6Q5kN6ib9trAOUN0VXMkQCJP84j0wV/FfyV0GlSzFTVEBiLxvWepIhpyRqQP8VyG0fbTd kQ3/ra+nCxIkSJAgQYL8W3n0XTVGeZ+5fQ2qXyoxsWxRqEST6BcrgKZYI8V24G+V2TG7PohfmzeY okBU+EBJBnWeMECxgbGWOcf+EqjLxWf0oaC2zl3pLg2B2vo9ex+wvBAfom+A/A55G3xFIFQLuxg2 CzyN/T/668IzJxq+V8YM8R0S1fAm4FPyDGldQVVzO+c0AWOCSycXxOYxpcxzwPBxeEjM88B12/iw 8uA/mXs/txxETYqdEfcixGy1f6yWBik5ZrAlEuxHQ44L68BYLWxMTCo4L6UXudkBPMU8reM3gtls WR2+DES76zWvA8LKGXeZF4BtrPCD0gBkq5qeKoJwTjgnVQPtLc+0/PdB/VrdLllAXKxNllqC754w V20JyjGtuj4D9K/8q3zRIDeztLT9AkJNLUlxg+5WnnFtB7WIZ4O0GcR4YZJxO3BEKOX9AvSiWpbr VxDqGnbYxoG6Vv3BPxBCVUs9uRhYz1mv29qD9bxhqV4PrK/L00IiQB0ZGOJ7HgKn/RPVn8FeK+SQ sAQiHKZ5htcgr4e/nzgD/M95GvpXQVKJmMUmCZQ4ZaF0GXLXu0p6D0GRqJi3rWHgftk9JVAGsopr vYUuoN72pXl6gLLSmZdxHYp+Ze2vNgDnetvukD2Qbsz7MtAJtGSlirMPOGpYRONyMNQylDUmAPtJ YQRoP+rRQikIKFqsfgICHyiZ4gEQZgkHxbNgO2xpI5eC6IGhQywymDVzoj0dlHWBZGEI6DpXfIA+ SHVrHvBneXd5k0DYb9ispED+SGdU3hAQvLpbewd8dbSfVQWEmmpDZSF4Tvt7qp9CyevxJ0yjIWx0 4jMlEiGgezqJZcD4mq2P5VmwtYj4IeTC3z29gwQJEiRIkCCPE/FRB5Bu6g3yRHj6bHOtgwJcsc03 fAl5oal97rSBvRN/7LEiHFw775xJXgPu4ZnZ2W+DUj4/Nv8lSK91cv+RFaA+7f7cmQq5lXJeVQH1 KcvZ0O9AOeLfpVhBua9eteSBsFS+LkgQusUuGbdDXEZsy5DXwVfPVcb1PoinHHNjMkAv4TykrQFx YmblzJ9B/MYw3OoFaX5In9AjIDxnO2erBPouaa8hEoRc/8fOtlDKXDyj2G4IuxfxtVYHHNusqi8f Qi2hnWJCQZKNueah4J6WNS1lNKixUhXTRPAcEobY3oPz85M/yh4NeUN9EVptMP0UujfxOthNti8i 2kJ2x/zhXsD3lWtm/l7IbpmVntIK3G+7b+cuAfW0f7DrFJjfNwWkhmAtamxFezBVNVktg0C9rB8X x4NyMfCSqwJkX8otk3wd8p2uhc4hkHE3J14dCCntMrvklYfIRSFRtqlgKWt637AX9NPak56LIJzQ XxYd4Fhg0cyvQ8hOx9CwiWCINj9pGQJitFTDsR5ySuXNEVeBs1eu1TcFlFP+ha4D4Ovhedv3Hvhe 8q90RoB1i5StKRD7ccizlvmg/KCu1cPAOdX3lnsyuMPVNtphsOnGV/WKoKXxnGQHcbQarkaAoZzQ VpwPUa+FGsKzQZ5tWm9tB9YU68fWbSA9y3B5OOiLhKcJgOlVUZWHgKmk4TVpPggdpUTCwJ8buK5+ Cf7rvm+0yqCV8+OTwDRUjmc9mFqK7xs+BeNS6Q25JAgthGnGa+C6lveavxm4sjxNnNvAl0Nz3Q9S qHGjsQqIbSylLN9A2M2QfvadUPJoybSiJUHrKWeEboC0iXmbvDMh7pXEbpFuMJ3R+opF/+7pHSRI kCBBggR5nDxyxLmYy9qywWuQUL+EWssIeabMlakJcLnS8ZqH50HG9ejl4mD4acbec2ufhqRcU3Kx xVBvbrewzgKw2zDWYAcaufZlh0NgS8769A1gcj6xrFJVyG6Xmnh4D0it9Gcs58Gw1/ROtZngbxTY pChAP/WKPgXkk0KO4XMQqgr9pYugHEtZlH4LlD7ST5ZUMMdHlomxg1A+7lSCAYxfh6WGtAHhqlZV rw2GZNszpmaQ/YWt7oXJkDEnt+6xzfDEL09cj2gN9w/k9/YPAsczUV8Xy4Os0neXX60P3i3O7vnP gfkFmznMBcIX/nz3W5DbzVdW/wG0IWlO10YI+dzYXlMh4v2Y4dFbQZ+vhWgVwDzJ2TB/LESuCJ0b Vhv0ExjEN8D1mf+m5z7kH3W39n8CHoOntLcmCKlSf3Mr0O7QXxBBrKW3UQeCS/B+k28EoQ1VWQjx PSPnOcZBaKjpNaEBuIZ6F2nbQHhP7CnsBst2YzvpOvhKBlrpfSHnRHZeVn/wl1QuMhc8nyjxzu9A v6O96ZsB9k+NM5UOELjo8wWKg2emfzYDIa5e2PDoE3Czb8byzDcgu6drvvYkBL7Wi4ufg2WGaXSg MthTja/LZYBh6jZlAjDC2EWqAvkrvBUZA7kN3HO9djAukyKlHyHu27Dq5vEgJos7pXqgTDV3MpnA WNm/298KtIPCBt4EcYiSLJQEPVuppo8Hk8skUhx8rb1TfZNBWiZMElMgp3tewLUVAlXUiXpdCMRo q5TvwLDBdNRqBe8ZX5rrGIS+Eno4fCEolxW/9hkoY/RNCiCu1WcYfoZi0WGnxKNQ6WoZQ1JXsHxo KGMbBlIPebO9OUQkRWSGK3B8+a+9LzWFajy9nf1/9zQPEiRIkCBBgjwOHjni/OTExvM6vg5+j9pZ WQTSCYPJIgMjIr6QN0FOe/c3ebUhY4w8xVUGQsISF+qVINAo46Nr6WB8N7J85EhgpudY5hCIeiG2 mOMGSHXMk41DIbJSdI0nLkDUqrjnSvUF5aTygz4UhCg26rVA/F4/x2rQrwpevgRtJ+gZoH+qlhVC gHW2Ro5NoNt8S7RXwTDAYDFsAsmctCBsMbBRnyKuA7/ovuueDWW2F4mL+hTyp+speii4J2XNzPgc ioVGbBcrgWGTY0pUczDXcESEXQff+OwmaRVASNAmGKeCeYHtC1sL8FzxdRZ+grzRelvZATkeIdo8 HTyfKWOFPqBt1dpLY8Gw3bzd5gHtTW2EmgauU66brm4gnVUz/Tsh4cXwaHsoFEuOuRL+PhgD2iKf BlJAPRpIB0c18wLb12DeaFxqaAuWWYbD0i4w35MPG7rDjZZp2ZlHwW/TB6pfga2zdYqjFLjHuVp6 w+DuqxmJmUshp4LrbN7H4H7BWz17KnhmuaPS64DyXaCPMx9cNz2NtTCQoqWT2kIo9kz0N1FpcC78 xsvpEZDcJDvE2xeye7gGe+aBME9X1PUQapLqi6shZp6tvtgOhLXGhlIpyLI4a0r54P8m8IP6HkRH hrW0rAPbIvMBgwUI6K9pGyD9bJaUVx+yZ+S+67KBt6bH6vkUvNvyffnfgXuTq0VuJ5BeZLZ3AqgG b4Z4CvRsvb3cBrLPOhf5WkHmGGcxTytIu5ZTPycXskc6R7uXQfbh3OY5HcB4xuhhLhjLipuFXRCy wva08RMIW2QPt20BQ8CQw3RI3Fc8JWo7xN+K6x4XAaFrTeG2e1D0cukLZb6AQG33UM0E17zHzRcb /t3TO0iQIEGCBAnyOHnkiLPjRFRYQk3Q3tCXkgCibowwnIT013N+yH4BXNody30b1BxW/k61m1Dp 66pLG40C5bhpnnwXpPraId0Cai1vnusH4IDQiebASnW5qzRo9/N/9jwPYrmI1gl3QZoSWKVcB+0X cRVbgZLiK+jgn602870KphH+fv5boLZRjklfgp5ryrcPA2GDu588EbgP0nYwrk6sFVsB+F5JDnwK /tYZDe4Whbx+js5pWVCueQ3jk3Xh7JFzBxb4oG7bKl+VfxnsnfRFMcvh1xXeDUV7Q87hu4MulgbP sLzXU1eApU34qxGHQRoUeMs3G7REZYA2FrQxxsvRVSDvSf0Z9XtQ3vU1cLUAw3X1O20/uF7yHHKX AVsn6yLHcQiZJzSWDoH1I0M7w88g7WCedgCSDsXPjBwErqM+QVkCnsn5y3KaQZHJsceiI8BZwRuq 1gKxjvyRbIEiz9s/K3YLRIOOVwXPNPdl5zJw3vek5m4B71HPMo8XzFtNJ0yhwCxhr+ljsF+0rg+x gWWgHCq8CZa5UjXlSzCNM35iNcLVqXevOWeAa4GW4+sPll2Gt03XIXpTSAXTIkgZnzr0XhhEL3D0 tr4I9ua2tqHV4Fzgzvj7z4HpQ1OUfRg4XjDMMJcD2aAkuAaA1kVLE/dAsil3hNIc9GR1nf8maFV5 wdgZchqpQwIpoIneTsoq0J5XLri2gHOq/K2eAaJdqK73gPBAdM24dyEwUalPFsjh4n31PDjSLJ+I p0DP1QfqiWBcL+/SnoKQ22YLRUDdE7jl6wHm7fY94SbQV/q36B0h7KfYkvZoiLpQel+5teDJ1nRT H4hOjy8Z0wzCjQlro1PgSPyaQb/a4Mba+6/eCQE6/T0TOycnJycnB5YsWbJkyZLC9l69evXq1QvC wsLCwsL+Ht+CBAkSJEiQ/1d5ZOGsXxYS9UWg2lx18kdDlnJ/xpUYKDFVtVkqQbmJVeVn+0Jikaqb nn4WtB9imiWWBfGG/4YvAcSreoiwEJzv32p1ajBY02O9VcqD7nQPzH8DmODun10buBfxbUJV0C+J jfRM0J8R7iGDtE9PE1aCXoukwEnwfuQLd/WGQM3rK5K3grZQ60t3yOkr2/NeAsepOysvTgfvpmM9 jlUFy5NP7CxxDsyVq2mlD4J+31s7ZCI8+VaRTy0e8A1rsvH2NahYvsL7rSOh+ey6A721IPXUtCe/ 6wSnvnQPi/OA+5PMK3dPgNzQku54C0xTzMfCfgHfnfyfszeBe1LOkeyPwOAz2Y2tQCguzBd6gPuw niR/ApbnjK6w8uD9Rl3CXshpIS0Rm4MvMrCNnhC90fGCTQCTyVze9gHkt3Hmuu9CIMI8ydQUQhda n7aehNhnwjvIaeBt4puijwEnefm5V0DqJdzUPwRpjr2kYQzYrptbh34M3tG+Rpb+QAflk0BVEKMN uvEaZHd2b1O+h8BCvyBMBnbKw8VKcPbjm4lp6RC4Isdps8FhNG00lQFmK3UyysHd9umjxe5gf9Ly tckDpIlpHgEyTFk/mb+EsF/DpkYPhThjeIp1BOTKOTXy7oPf5S+vvwQZo3LvOD8F31r1hHoZolaE /GJuDCbR9IH+BtjeDAwQD0KGxlF5H8hxkhp+CaL3hhw3xYKprLxYzQJ/K39dcQd4nmObWg6kbkbB oIO0WTtqqQ56Zb1h4EdQN2id9VmQv9RdWXWA9Kppt3ER5HV17vOOAMcJ8ybDSkhYm3AsZjsI5cUD 1qWgtlaryRfBfiR2a9wlCIxxLXa9Awd9B9zHTHCy+s0mN/S/b2I3bNiwYcOGhQK6gAIhffLkyZMn T/59/gUJEiTI/xScTpfL54MZMxYt+vVXuHz55s3s7H+fvbJlk5LCw+Htt/v2feYZsNttNpPp9/74 fIEATJ26e/eFC3D5claW1/vv9CciwmyGd99t2LB8ebDbTSaDofC416tpmgZ79mRm5uVBbq6iKMq/ z5/QUFmWZWjQIDIyJATMZlEUHzm/opBH31Vjm2uDaw14892XchaDrVbYqtihULRJq6J1KoI2hXP6 YQiUVd5WU0Gf71W9t4C+YpjeGlRj4C2XEczh4a9G1gK5ZtGF5SuCNMNeL6QR6NtskeFjQNNUu/AO 6D2E72kJwjzOCzGgVaAr34NpreBwzAC1ns0Wvh7CN9eullAbTh2528jrh+O1Yz67dAm6jpayboXD /U3l9bsfQcLVEu8UCwfb26Ze8a+CVMY8J+xjkNBb+ydA0zea+EdVBP1TPZs+ILyXcIS3oWPNZnEX 28HNgWtan/4GciJcB3PKg/ODrEb3MiFMjC1b9AMwlbFFhiwGT4/849m7IDDL00w7BEJrcR87QPjV MFu0g3grMNHyNSihchXjR+DeZu4rx4O00veppwf48tSX+QbyF7ra5n4E5lOqI+85yB6Scef+j8B8 89fh/YFZgVbKBhBHyIvUqWBeaVllWg/CMDrIJ0DPD4R6T0NIT9MdqS5oRslhawlKuphhjgd3lHuM Ug1cHTwGzzPAKm2Qtw+IzwtHrFsgLDfilt0Arifytuc4wHPf/VXuRog3RRui3oXM3IxqV3pASKew xUnVIPRLx+jYdyD7rq+r/xz4c3LeUs9CxtverJSZYN5q+cr0NWSdyP/Vexs87b2xviQokhU/N+IM GPYbalrnAC+pHb3REH4i9FlzI1DH+5vn9YfUGFe4qzNkasI38gDQPyJN+wi0npSiCZi+NbiMiaAe FJ7Tj0DgZ+0jbR74xgfmaL+A8qTyuqc7SJW0T4WaoA+hlUcExxprknwSSlQs5iyjQUS/qIuRtcDw kf8VLR3Cf4p2Ru8E021xiRgKBw6uXX1sGfxy+qLz8seQFq8YtCv/vi+Gh7F79+7du3fDqVOnTp06 BTdu3Lhx40bh8RIlSpQoUaKwX4HADhIkSJAg/xpTp37xxZ49kJmZlxcIQJkypUpFRYEgCIIgPD47 uq7rug5paRkZTmeh3YkThw9v1qyw38SJ27adPQsej6YJAjz9dLFiERG/+fM4r/s3b+DGjcxMp7PQ 7tSpL7xQvXphvx07MjJycsBqlSRJgmrVQkPtdni83oD+f4JVd+96PD5fod1WrWJiIiIen51HFs7u cs7i2U+B8YJxgXkuSLkhE8P3gcfpbeMpBkIx7baQCuoKeSvjQHhCbKGPBimOEMNG0Lep77hfAuPz xb+veA6MR2zbHddArc1PXAdiGCQWBYNJ7+l/CgLPCj42Agf1xmIu6F7hsH4HaE0dNQzEm/49hmJg Ld/wjVpvQP7ZrKQt2ZBTJnmXvwPkNWWXezeo00sdKVoVfm17+dzeDGi2N+RkuZfAG5Z21HwU7n98 25KpgLGuYUnWcMjukrL4/gnIXnR/wJUUONX31ovJUWD9wNEo5Bdwv8BX5dqDd+jNA8c2Qf7I7L3p rSHkVmREzCYw1reY/XUg4PQVz30ZpH5ie2Eo2HtaI0JaATMMFuMwMD4nJ4uTIDRXXKCdA0MJ423H Ibh7I2+iHgu+jq7vfC9B1il9gCEPlHrGnCgdiswLKWn8CDLHZS12DwdpAbf0HMhzuX/WLeArpdb3 mUEuIS8R0sFbXiulPQdyCzEk9024Osoh3AAAO3dJREFUp+Wcc+0BSTTWcFQEYy2Dz9gQTJMNlRwv gvU4N7z7wHff83lWKqgnma5bwTTEvE0LAeW4+p5WBYo8F1up7DQIrxcRazsDnhddF+R5kJeSfdHT AVw9tHH+TuCoYT9nOQ7exoFkrQx4e6pb6QCxb8QsjDoN1nnW1pYicNdxb3y2GwKDAv09x4Cj+uzA CsgxeNf6XSB8Lr9ibQiBxdpt6oJ5juUL4zdgPCBnS8dBGa2Fix1BMQbue4uBbaZhuLAaLF/KDrk0 yD9KK8KvQO5G/+lAJ7BPMW4W20G5oUXrxaZCsf7FphW7D4aVwl3pTYiNiBwafg2iwiO/jOoCl978 Neny97CuzaZSu0Mh+a6vrCsX5I7iNvtb/2eSbH28Xw7/FdWqVatWrVphfdasWbNmzfrn/YIECRIk yL/GuXNXrmRlQXx8YmJYGNy8ee9eXt6/z57dbrEYDIV2H+TMmZSU3FwoXTouLiwMDhy4fTsj49/n T1yczWY2F9p9kPR0v19RoGRJu91ggAsXPB7Pv/EFYeHhkiTLkJ7+m4B+3DyycE5546rx+ivgs6be yZoI1W50XtsxA/wRvrKBV0A/KZv5DqSz2gmOgtBcGCAsAD1BPMU7oF/Uz/kagVhSjJI/A+1n4Y6c CFzV+gSagPCSsEhwQ2Cy8Lo4FcSL2l2xARArnFR0EIbp+8UjoIXgkK3AV8JXgTKglne/rHwNZUYk vFHlE7ilej17J0BGuHwgfyckmrSrjvaQ8oL6rfwZZNW83+vebvjE8fb1T5bCTVOaIfABRI4xTcmb BfpBZY5zJGTGuBZ5XgXP5/b1xatDfPeiPyUlAPNCng/dDOl3o3KLHQLvgfROybHgPWN8zrwHHCGh b4fcBuEWn+tJYM4WFwQkCAsYdPUq6O+pV51OCO1sfFksBeZdUlggCq62Sn455yT42mt51nqg7qef 5AK9IzW1YSD/JHTWz0Jqam6IfzfYGjvKm9uAPEiuaukP3hqeTM/7EJop91YlEAO8IlwHY1m5i+00 mMPM4eYYMM63b/FkgFCEltwAcZuQLDwBalHtw8D3YFsmp0vXwPyysVTUDPA+7euYWxWEtrQwHgZf TuAJZS74tjufzc+BQFPTWqsbXEb3zNxJoC8Q3lYmQHFveC+hBhhdQqQ0HrLNngXaPYjpErrDkg+h J03p2gnIScpfnN8D3Kr2me4G4kg3fAJaNr1pCuaLtsrWHLC8YnjacBTUpvoRtSuoMeo2oTOoffQj 4g2Q10p6oDaY+prry34IXx8629EBvMu9SfJlcH/kq+WrBLYjBrs0CYpvjj0beh5ijcWWF38T9KLC R5YA2A+KXY2nIOmDUpbEluAKZN90T4fNL/y8Yd8NuNMl99aNOmApzsfeOFBm6whRwLP/vi+Hf0RB 7vLixYsXL14MvXv37t27d+HxgvZgjnOQIEGCPB4URdNUFXJzf0vZePTxAgGvF7xel+v3qXZ2e1hY XFyhnQK7D+L3+/2BANy+nZPjdBa2p6aeOnXgQGE9NrZq1aeeenR/C+wU2P3j9aiqrkNGhqL8o+M7 dmzZcvQo7Nt34MCNG1Cv3lNPlSgBjRs3b16z5l/3p8BOgd3HzSNnfWT71UYZ4yEjQNu8NiB/JyjS dRC66ru0aKAEqzgGwiRhlbAFSNf3CodB+EhYJlQHf5GrIb+YQNmZnZezG8QbcrIcAC1S6Ca+CfpW PEIZEG4Ln9EDGCVU1a4BHRgiVARdpJJeDYSxQnOhGIjLiWY6+BThXX0dFB1f+vOGF6FpYq0ZHVuC /VlzufiacHlzhny+DJjNlpOh2bAv+eDTB8rDzYsW8523wW+11vTsAHuLsp+XPgXVqr3w/vM5UKpR tTJ1B8HQ0v1rdekC9RwV9JgJEPs+q/LmgXVBTNMiK0D2h/0U2R48e3OeSy0F7p7u5t73wdjYXj2k PWiZuigfA09PzyzPZDA+Kd8J5IMX7yfuH+F8/I3X738HyZb07zJugTfbM8pVCqR7RovxZzD7rK/a ugCnBK/UF6RzBo9xLyj9tQzDbsjr56ritYJpsfkF4yIIs4TUtn4NURVDqoc0A/NxMUI5BAwK+Jy9 IeSO+SxPQ/xXEZ+EJUPMDZvfXhcSP7J1dywFoyA2s+eAf4syyx8G+d/mPpufCCmH7n+ePBVUh9or MBPyQ5Qw78tw/Wjm5JOLQK4n3PLOAnbpl3JPg/tX/zJ/Kbh3JPNGphUMn0mR/p1gf8JaQnoLUowZ xZ3zwTnZc9u/A3wVvdW834Nnjm9zwAnKfVYJC0Aqxae6DMYY4055LNjL26NNzcFWzrzS9gHINYyZ ogiBTvpeMRMyP8rL0u7Albk3e6UnQMbG7KTMK6DsUL73/ATRX0e9aF0G8XuKP5NwHcTv5CGmluDd 4a+sfQiOhnHPx3aGvHHONOFV2HJv85EjUXD4lytfXegE6Xvz9qR1AGfdrE73W4N/hGf6/R8e/4T9 sxQsAvyz7Y9KzZo1a9as+c/LLju67Oiy4++7L4+bjpM7Tu44ufD6HnZfCvr9p7DCscKxwvHnn1tB eXnE5RGXR/zd3hcyOXNy5uRM+KL/F/2/6P/Xz8/vlt8tvxs8ZXzK+JSx8DrvtLzT8k7Lv/vq/nM/ P0H+b1RVUVQVVFVVNe1fL30+r9fthsmThwxp3BjWr58/f8CAwvKP5/1m90H8fp/P7we/PxBQlMJy //6PPnr77cLyweOPXv5m90ECAU0D0LTfZOyD5YEDp05lZoLZHBmZmFhYf1j/P1sW2H3cPHLEWa5T 2hozHcwZ4SvDZ4O+gycZA3pjuvEaCDu1WH8CqN/qt/W3QGgrvmVYDeJzQmkpEcSDQnfDcpB22mNi loL6rv4D8SB6eFIpD0JTnpPMoB/Qx9AQ9AYY6QVEIwjNQegiPKW/AbTVa+unQc9gtdgDxJ9EzXIA lINyscBsKKoV1RvcAnG1jHQZMjPFUZdvwXVnatr1H+Fi+vUzntpQbmXjlGdegLMf/9jpRH8IG1i8 gyMFykeXWVppM7x4rNuNXhXButVWzPQ87Oq8s/R3xaDxnpjb+WMg5MTxXG0jnK3of6PUHciaoB1W JoFvUUaRlAVg7C3NKFoW5BH2J8OjwPexf2beBMjx5a3ImwnusoGZQkfIPui9q2eB6ZjhE0MTMHwr rAtUALGHctQtQCDM65KTwTzV8pPpeQhM97/is0LOobyXss+BrYhlrmUMKM9oFssZcF7yFpEmgLGU XNx4EvxGfa52BJTzgaGey2CbbJht2waedvmrA1PB/5WvddY1cH2o3LxshNRTafszVoD0s9yYS2BY JkyzjAbveq8odQZ9lRRtDgO+FKvkB8Dl93fOOgliLWbYf4G8cvnD8qLh7P0b77uSoOTB+FFRKsSc se53JELKc2lP5e8Hb1ey/GPBUotR8howl5FTyYawb0IrmxeB8I0w33QMlL3iRWkpyHsN66X3QY0L 3BV/htzw/HeyM4GaREltwDrYesxaEWLmhbTXW4Ca6+9pWgWG9uYuxiegyNTwtWF7IeJmMSluAcib LHUc10Ct6R3MSIj+Kt4SeR5k1dY7TIcDL/3yy6XqsDfxaOtTL0J6AzYEfgLtc+OsKBm8T9Pt7icg tJeaShWBe/+OaftwCnKW9+zZs2fPnj8eL8i5a9CgQYMGDQpznR8Xkc0im0U2g9dff/3111//43HH Zcdlx+X/3nvydzL2x7E/jv0R7Ha73W7/u70ppG7dunXr1oWxS8cuHbu0sH18m/Ftxrd5+HOM+ybu m7hv/m7vC1nTfE3zNc2heIfiHYp3gAEMYMBfOH/79u3bt2+HQJVAlUCVwvYtHbd03NIR+tKXvn/3 RQb5j0dRCoRsgWT715g69c03mzaFUqWKFYuK+uPxB8cvsPsgfr/HEwiA32+1/leL8Pz+31IoFMXj cbkK22XZYrHZQNdVVVEgEHC58vN/a7daQRQNht8vRnzQ7oMEAr8tDlTVwjzk3yPLFovD8cf6w/r/ WQrsPm4eWThnWe8mJPeCuOHhW8tMAOETNV7PAgbzOhbAp+dKF0BcJz4nzAECfCLFgPaZ1kLrA1KL osPLLgbxgHVw9F4QItTBvr2grddvyKeBkeJoFoNg0dfrw0BPIRQzCCVwUROoqX8kGEC/QgndBtzT jfoPoDfnnNYXpA5yHSkBlGfUz5RfQLpvmGrdCU/sji3VoDtE5Oo/h5yEqECJw+btsPr04qzNcVCq XcXTES6onlvtkKkhJIfcjT1XCRLqpR3TtkPkm/bS9g5QplrYCsubILTVWiS8ACkL5ZRLn8C9BPuG 0OdAr0VY2e/BufTeN+dkyLNn/pzsg/DpkYsS14M+yzrL4YWcKoFuWnVQR3odaSfB0EIeKn4HMWsj ike9CIYOpKhjIXV/VoM7FSC0RmiFiGdBK+o7KR2E0KgQPWwW2HdYbks7wPmL+xf3cPC39B7J3wPC ZUMnYyyQrvf03QdXjueOZzpYRptekveBOkyZ6HWB+44331UEvHmBFpke0DYZd/h6gLze0Mo+DdzD 3E/nPAtirnmu1Aasi817OAlyA+E9/TSI6GNsT0FceHR0lSOQP9n1fM5VKHInsnHsdZC+Epel94WE zaFRIZMgq1zmEs9KuPtVJjk/Q6lX4p+0b4JArJAfqAXiRPNMy0RQ5tKFj8Eez1TFC6Zl4in9Ihic Yju5KmTuymua8Q1EJ9jjDVMh7mLUezE/gfkd89fyMUh5JrO7uzzcHJva/N5QKPtS6WVFzoFjU5F3 o0uCYaGxi+0keNrnXwv0gqh6MUkxeyFkWczcqIZw451zre764PAbJzJOVoP7F/Wq+hFQR8ifRl0D ZvijUw6CcZ51hnwTTG0tSfEvPv4J+88oiCgXCOjx48ePHz++8PjYsWPHjh0LSUlJSUlJj99+gUBs ndA6oXXCP+iQQAIJoM3X5mvz4cs6X9b5sg6sW7du3bp1kJGRkZGRAVFRUVFRUdCuXbt27dpBn0N9 DvU5BOIgcZA4qDASVyCYfhj1w6gfRhVG5m6tubXm1ho4evTo0aNHC80XnBcXFxcXFweWZZZllmXg LOcs5ywHwy8Ovzj8IjSNaBrRNAKUKkoVpQpMz52eOz0XNhbdWHRjUShdunTp0qXB097T3tMeWMMa 1vzxcgtyzIumFU0rmgaNljRa0mjJ4/OjulZdq67B7Ra3W9xuAXd/vPvj3R//eN0PUmJbiW0ltkEJ SlDid+3jGc/4/+o5vs3bvF3of7FJxSYVmwR1vqzzZZ0vIatTVqesTrBj+o7pO6b/+edzbdW1VddW wbRS00pNKwVnz549e/ZsodlyL5V7qdxLMPTc0HNDz8Gc/XP2z/ndi4UKxhuWNixtWNrDc/sfZGPa xrSNaVDuk3KflPsEjEuMS4xLfieca/St0bcGcJzjHH/0z9Gnvk99n/pgU/qm9E3p4HQ6nU4n1Pi8 xuc1Pofx48aPGz8Oom5H3Y66XWjPt9+337cfuk7vOr3rdMibmTczbyYMOTvk7JCz0DKmZUzLmMc3 rx72XKd1mdZlWpfH/73x/zqK8pvAVJRHE2qlS//fgrl9++HDV6/+53YfxO/3+Qoiwb+PSFeuPHDg xImF9YiIChVq1YK4OK/39znQN25kZ2dmgsHgdufkQM2aZcoULQoXL965c+MG5OVZrVFRYDQ6HOHh f7T7IIHAb4L/Yf9WyLLZbDb/sX3atKlTN2x4+PXXqVOzZpEiUL9+48a/X4z4oN3HzSOnahjy/aGB 2xBe1bQ0ZCQEkqgsvAF6feFD4VkQlokrDBuApwSvlAmsEHZjAnoqs93jQBua2yJtDFBBuy2eBlrz jrAMhMZiP90NyDTT5wAiWUQDBsGMBKSSzy3Qn6eDngxCNaGq7gC+43nlW9AFbYhfAr03M4w9QJov hErNQe2tnPOchPAkh7X8VShfpeTYVjPAe1v+3tAYzGKZ1ra+0MPx4sQ2zcDRxDMyoj/4794fmrsf nMK5Q6nJEDLPcDtsJxRfGhmI6wr6QLmfVARChxVdYeoLkcNtlfPsEDna/qWUDOaBcTvLbQPjfsN4 ywpwN8hy3JVAbe+54HNCyIyQZ0ObgqNlzOkiFyC2VtT1mFSIjYuKiZ4Ikd7Q0GgdSvctGl76LET8 ZDsTshei9jl6GiqCaYc+3P0JSI29b2dtgqSUyAHyHgjtZiijTAObTfrMuxEMayjvTATrV8ZS5obg 7e+xB5Ig+9tMNe0z8Ox37/BpgFlLcHwDpjjtaGUNwk6a+pYMAWsjw01LX+CuajcvBMce097i+ZDd zBVIHwb+F/XpFIWsRqndXAoY3tZfDWkC7pXe5PzGUCo15mjx+WD7QE4L3wuuZr453qMQuzwi0XoD 7LtNi0w7IL5cRLvwOEhsEFbU+hl4m+efDdjBscGiiqPA2EL/WEmCjMr3X73dF/w/+jenDoDcRM+y jE5wZWVa+VM94GLCnfDkpZB7IO+suzhUOFbhbJEEKNGptFDiOzAdMPUKVcBVzL1T+x6sxxyVwppC GDHvReXCveu3vs0qBUefPJZ96jbcKJm/z30YvPV1j9gXPGM9G3JfB+dnzrtpiWDIstyLWgbuqfpG 8+ePb6IWbB83bty4cePGPbxfgXB+WL8CIX3z5s2bN28+fJyC8//qtnUFAuZhP/VvKrqp6KaisOzC sgvLLhT+xF52d9ndZXfDjNwZuTNyC+sFx78Z/s3wb4Y/vvuZOiF1QuoE6DSl05ROUyBnR86OnB0w Y9eMXTN2FfZb+uzSZ5c+C2ui10SviYZmN5rdaHaj8Kf9tAlpE9ImPNxO7s7cnbk7Ib9sftn8sv+6 H8uWL1u+bHmhH81HNR/VfBSUnVl2ZtmZhYL5v5vk5OTk5ORC4f7s0GeHPjv0r48zZeuUrVO2wvEB xwccHwATN07cOHEjTOs8rfO0zpAcmxybHFsYEZ80cdLESb8TAPEb4jfEb4D3mr3X7L1m/9ze/YT7 CfcT4EStE7VO1CoUuE3Dm4Y3DYcbTW80vdEUrl69evXq1YeP82ef31eGrwxfGeBbx7eObx3QyNHI 0cgBk4tPLj65OFy8ePHixYswu9LsSrMrPdxOuwntJrSb8F98Th7TvHpcz/V/C/9qqkZeXlbWvXuF 5YM8ePzPpmoEAj6fz/ebcP4t8vxbeebM55+PGVNYFrSvXDlqVJ8+hWWvXnXrlikDmzdPnPjaazB7 9sCBnTvDli2TJr3+OtSuHRtrsfxx/AK7D+L3/5ZrrKq/7cPxYClJJpPZ/MfSZktMLF364eXJk1ev +nwPH7fA7uPmkYWzcZE5w/gEhPcJPRARA9qb+kTFDUK+ECKkAmmY9IbAdr2ysAyED8RPpIkgfOyb kTsb1Et5dfJCQPxcmG/eC2o/IUNfBUJt/WtmAZX0kUIE6G5KIAASAoCeRwZeEOYyV2gA+jdIwjzQ s9TpHgnETp4rnl5AL7fPuw4wMUdLAaG6UIUsEOtJbzEN7q/Mqp5+D8Td1566mg5jLd1WDX0Tqhyr UL/1VahWr86LrdpBq6yXmnbqB4ZxFT5KDIefVu5stWM1bG+3N+v0JjCeCszV8qBiY0d4eAOId+gJ nveglN8UnfsklH865rKxLYQkxfUtI4C017LP0R18m7NeTTsD/mHOi67eYEyWLaFlQX/eZIo8A2kb 8gZoVeBuldwZvkaQuc1ZRm0LqdszD7pFSP8ye5DrS7jXImNLzrdgPm6uJjlBuO1P04aB3IUp6lCI yra+IlSG6O+sn5trgOOcbFPLgPWM6Q1jPPhjlNepD96h6o3cVMgVA3tORELaazk1z52BrB2BnpeG g7OW72t3LEh32GGQwd06EOL5AgiX+hvugbunz5hTEfK3B/YnL4T0fjnHbs6EjA9zvvbcg4y1TmPa e2B4Iey6oy+ECI7sqC3gaGf6GjuEGUIOGyuA8LIyzTQO8i/kJ3ieBeMJ6YziAZ4S7bQDtbtot60F bY65qW8QCO1t/XOSIfdSoHh6Z7hc/17otThIj/ScuXcRiows1TlsJhQ7XKx16T4gKEK8tT+4i+UX D6SDJdYxKOQ1CF0dcyemMqR/mhyatw/OxB75+pQAN1/MPZgbBmpdw3DDKaCz5hO6AKuFJkJtkF4I Ty0aB8oGOTReACFLHC78iT/gf5aC/ZgLhG9BxOjBfZr/GQWpGQ/mOheMUzBugZ2/On6BgFm9evXq 1av/WNa7UO9CvQuwfdr2adunFZ43ZsyYMWPGQP1v6n9T/xsYvWb0mtG/i+A+2P9RKdK2SNsibQsj eAWRw6wpWVOyphT229N9T/c93QvrQ5cNXTZ0GQw4OuDogKMQfj38evj1f78fD6bUDDEPMQ8xw+uL X1/8+mIIeTvk7ZC3H9/9+bOEPhf6XOhzMMc3xzfHB63vtb7X+l9ITyq47gJmzJwxc8ZM2Ja9LXtb NgwxDTENMcEy8zLzMjPEpcSlxKUU9jcuNi42LobY52Ofj33+n9vbPHnz5M2/yxlu0qRJkyZNoPE7 jd9p/E5h+5ZOWzpt+S9eYvRnn9++X/b9su+XwnpBCkyjK42uNLoCi04sOrHoBPTo0aNHjx5/tJM4 PnF84njolt8tv1t+oZ28GXkz8mYU9ntc8+pxPdf/LTyYqvFnyx07lix5443C8kEePP7g+Q9P1fht H+eCiPODkefCfv+4vV27p5+uXh0cDovlH0WCu3evV69q1T+OX2D3QQojzr/VHywLIs5/tXzhhUaN KlZ8+Lj/rojzI6dqFJ8T2bvY52C4aT5qdYC2Qs/WyoEQzw39NuhWvauwGcQEpioNgBHCfOt34Hsq Z1bedfAf90ihh8FoMPSQeoDYWb0cWAqs1cPkjcBysafuBeETfR75oO/XL/ArCP2ELiwDNVJvoyWA 1FUrKVwF34D8t30CCCkep/cuCLpc1rQApFamddoaEJ6VRbkF6Iu0I+ooMGzwrvTEQsPQJ33tq0P4 ddutUgngC/dneweAvVv0sOIjwGEUGpRoCFHeJLfyE0R4It4MewL29NkzbPsEWJV66UBmRYiZ7qmn X4BSF8Im2dqCMV7c7Y2CIl3DRLUJrH1Cq0QeHLMZ6pQaCNrurL531kFgQt769L3A22pPvSdYqoU0 Dj8A2iJ5nTAH/M/5u2tbwH0/b2R6DgQifSH57cBe3dxSGgyRvWyqeRPYzxoOWMuC5xO9sR4GUXXD FxumQMSAsMSwXEj7KuN7z1KwDZY/c60B00Y5U9oHacWyhNQdkPBuZN+4bpC+wzc0eiikf+mrf2UA 2COt9R2jQR8vvWdWIX2NW7u1DoTFebHyCQg5bvkutihIP1l/dG8AWwVH69D5IHZTfoj4FIy/ineM yaBNI8n1E9yqf3diRlnwvepNd66Goo1jFttLws29aVX0l8CdoKxK7w9FcsJbyn0gMFf53HwI3C08 zwXCIfu+u782EyLL2L8tcg5crwYGUgps0aYFxlFQomPMtnInoMjtoh+XPARhr4cPj18C/laBKVJD cNfyV/CFQuix8A4RseC4HF0xoiNkP5W+xbkUbp4+FXt+PdxxZL+ZOgC06cbI0KHAfPUV4S3QurLe dxbECqbGYSYQpmlHAhGgPe2rkH0ApPsB3RUDlHw8E/XB1Ir169evX7++MCL8Z/djLshtfpCCcQrG fZjdf0aBgEkalTQqadR/0dGDh99tRyQcE44Jx4BmNKMZCMeF48LvfhrX+mn9tH5/HObBdvWwelg9 /M/9FAeKA8WBv6svFBeKC//YT++n99P7AVasWH/nZwHHOMYxoDOd6fzn79Nf9SNQNVA1ULWwLg2U BkoDQbALdsEO0ihplDTqn9t73ISsCFkRsgLEUeIo8R/Y/7PP58PEDxM/TIR2n7f7vN3ncPiFwy8c fgEO9TnU51Af2Ji4MXFjIiybtmzasmmwilWs+lccrkENasDGGRtnbPyd4Cz4h/FBClI2BtcYXGPw P0jZ+LPPryCF4g/9/k/qyz9Dqi3Vlmr/czsP8q/Oq3/2XIP83xSmavxjIfs47fx+/IelagQCXu/v Fwc+jIcdX7780KHLl2HZsiNHbtyADz5o2bJqVejcuWbN0qWhdu1y5ZKSfjv/2LE/2v2jnf874vwg D0vVGD++U6fixR/u/507eXn5+eB2/+Nx/2MjzuajrnpyEzBUpbtUFECfx23gulBJuAqiT35Nvg0q whR9LTBMOKQfAfV970zpIviaSTVjZ4M4SFqIApTRzrIA9KHCe9wAzusr9EjQ0/EQAezByXnQu+p1 +AIM/aWD8ndgaGqcaawC0iFHYkxdSF7vm2gsCpcWZ47S50PODF8xYQhIP4qtaQPKRmWXfyeEFIkv XvYHCLVHJxXtCN4fFK/7Pgifiu0YCMpbaqZ3KQSeCSzxDgftpPdNdT4k9I6rUP0wtFtTW3q6ItT/ tHKFiDwIG1KijqEuKGuMA3wfQQlL9M6IGCgXVfaZkBNQTbeG5tSAJ0YaJa0FhCnRIcWXgURY42It QW3ku5FTF1zxOUdSJgKXtBpMhdATob9EjoLYMYm+pFxIvFv09RJDINRnqxRRCoTrhplyeQjdH70g IgAOk2Wq6WtI3ZvWLucqnNl+sWzaBMjd7A3xLwdbb3uLiGywf2GTbG2has+krcUXQ5keEXHFosBg p43vSyiWH3WoxM9QflBYdr13oOgle8OiX4PtqsViqQelE0qcr9wCImxhvSKPQ8TEUFPcJJCnSlJE OfB0VY95FFCG6/bcPWASzTPM3SB8rf1FwiDho7iNIftAFXFZq0HUm1E/O76FJ8+ULZNwFkLDbR+F 9gNpihAptwBbqCXZ0hOsblsvoxXEZqa25sMQezssPukLKNO1eEZZGcofqPBMzaZgTw75PvEXyO3m mqLnQ84Qr0m5D9Y6kTmRNcE0PnJOZB7k6nf75laBW2ePvXTiBKQeyOpz/TCoEeaqllTQX5GijedB U/RVeisQSgifUQS4r2731gPF5lvnvA9KJfVZ13VQrDyn7H58E7VAwBYvXrz4779ICv7gP/hq7T9L wXkPCocCO/+uXOjGKxuvbLyysD5h04RNEzbBvvL7yu8rDxMnTpz4+1y8pk2aNmnapLBekIObujF1 Y+pGWNV4VeNVjeHu2Ltj7459fH4+M+SZIc8MKazPennWy7NehgXCAmGBANmdsztn/wuC+a9S+0Tt E7VPFNY/PfDpgU8PwLwj847MO/Lf58ef5a8+nzdtb9retBXmOFc/Uv1I9SMwqPag2oNqg/VN65vW N/8YYRUWCguFhYW5wgUpBg/jSuiV0CuhcP2d6+9cf6dw/Ad/GSmICKeMTRmbMhbOfn3267Nf/+v3 45mlzyx95neLMD/e9/G+j/fBzq47u+7sCq/Oe3Xeq/NgxeUVl1c8wuLZR51XQf41ClMn/lrEuUmT gQO//bawfJAHj/9xnH8s1AOB37aFe3DXiwd5WPvu3VeupKYWHl+8+MCBK1cefn5BWWD3j/0KFgf+ 45QKWf4tNePBcu/e69dTUuD8eZfL4/ljmZ//237ND0/V+A9dHGj7NXJs3CLQO0h1DJdAXM5Y3gcl xb870At8T3hWuauA6ZVQ7J+CsZgwWj8DZ+dey83sA6ENk7ontQbjaGZqw8D7odBWXADCz/ys+0B/ h+NaMogzhe7SYRCqsFFYDfpZalEGnK8583KuweqZa85usIDvM9UcsR2qbXuqTf1toBcx3GUXSD3k NPksiNHaNqUEaP3EE4ZewMvUEj6DwFP+G/pZEP1Sa7YD6/WuZIKwgrfEKcA8MUl9GSiiDZatEOhB mvgWiCsT36laAiofFj+wr4cSr5sWnJ4NWaXCU3NGgngh76jHBuLHie8+4YFKYyrtDVyAxNVpac5p cCopy6esgzPzxMv2d+BOeXOTpDug3czbmTYKfJ0ym6b2B62o/cvQrWB/L+TLEAVMP1uamhJB/Nj+ lf0MaAGlk78ppG3PiRb6gauY57yaC66Z+ouGnSDGyCXVG8BQ7Us9Cu68lnY6wwtsUl8zhEJY89Di ljOgvCid8e2HUttC+hR/AeQEw/yIopB3xuXxLAZ9prDV9y6Yt2gDw3YCrbXGDADTZLm9+BUYL9Eq Ig0MfW19cy6C53uPlHURMo25nfkc1LH+ScnnoUypmNjyAQgdL+2LfwVs68Jm4gOlkuuUU4L7I5JV 12hI6+VMdVnA/LJZNZ0GsamwUz0CjjTzFFsPCC0XUS9kPtjHOgxhK8D8oX2WpSL48n0lhd3g/MA5 yC+A9K7pHVM4RKqxi2OWgLmzeadhFORPut0r9RNIX3Oz31UT5DXJ1W6VBg9GQ/inoA5ljPF10Kdq c9XfPn+D1Aug39EP6ZVAG0GsXhmIELLUdSDaiTa+DTxLS73a/5kk7R/fhC3IPS7Ynzk3Nzc3N7ew XlA+LLL8z3bdeNDOv4uXPS97XvaAX/frfh3WjVg3Yt0IGJExImNEBkTfir4VfQsGFhtYbGAx6BHo Eejxuy/k4bbhtuE2mGWeZZ5lhu9Gfjfyu5EQfTv6dvRtSCONtMfgZ+8qvav0rgL3X7j/wv0XYMuk LZO2TIJiu4vtLrYbIqdETomcAplbM7dm/htfdNNf76/31+HeyHsj742EDSkbUjakQKWIShGVIgpT FAqE6t/NX30+BQJ2xooZK2asgBG2EbYRNlAPqYfUQ4WLMUcUH1F8xO/+ceyQ3iG9Qzr82O3Hbj92 K1w0+LBFbAWLKjnPec5Dqw9afdDqgz+mihQstvuMz/gM2DJ5y+Qtk6HSt5W+rfQtf5m+ffv27dsX nLOcs5yzYPPuzbs374aNtzbe2ngLavtr+2v7Cxc//qs86rwK8q+hqr+9QvphQvZfH/e/Hq/A7oME An6/3w+S9NuuGQ+jYFeNB7lw4e7d379Y5cH6w84vsPtHf36L/D4sccJms9stFvD5FOX3PbZvP3gw ORk0LRBITf3jeU88kZRkNkO1ak8++Y8CPAV2HzfCwYMHDx48qOt16tSpU6fOXx/AjatBdk3gsuGk vSsIWXyoVQGtnv9z/yHwxbi7eXxgM4bPi1gE6mX9LV8fOD91a+TxHlAyss7o6tfB+mr4ccMgUM+r mXoScFR16tuAbfoK9VUQehqeNJSD60l3k88th+KbY2qVrgtKH6WdHgd7MvY6j1QH568uixoJtHJ8 X7Q7lMws5SvyC5S/F7/OkAzWLtai7Ae1vNpCvAdSB2EcJ0Epr2727gHRL3SXj4LwmlRJnA3621p7 aR+wRvxYC4D+HIKQAOJ+XVTeBX8NZ4W8DmBMMbRRF4L6gmtKxhugfZHxcuZ3ILkiZ4R1Bu+dzI33 HaBPSZ+W/gZIu2SdFeBNle540iAr6frOnHRYfW1Pifst4Piw7J+kdPAv8Y7LmgP+THeL7CkgVJNH Wi5D2JshdSI2gePt0A3mjWByGF7T7wED1e5+GbwVXeu934Iv27898Ckoy/SL2jDwx/qvetPBN9Bl yTkAZqdlnXUwRGRHvhH2FnjvuMd4u4KnmDvL+TNkVs3KSW0M6gxho/M2aO2Fly1FwdnZvz07HULy HCvEKuBPc28TPoTc+u5cV08olxY/ruinIF8QoyyV4WZ4xs27R8FQV95u6QVRa8LU2PYQucd83lQa tD36KKUL3B10Z5h3G2he4yDWgWNiqGQVwPyK/I31JsTkxm+wKRDRPLJ4VCYYBpmvhZwD7QNlt+FN cKU6yyv54M1UNwSGg0UJOxd2DEKXhc8NuwdiRe1nww5wRt3Pud8ZfN9kD7iTCh6f8lnuFMj2u94O HIC8bfqosK6glxbnm49BYCIzpefAd195n9cg0CvQPdAaAgeUlb7ToMwMdPKeAxaq9zzTQKqkL/H1 hGOp+z7ZcOrxT9wCYVuwe0CBgP5XCQ0NDQ0NhWHDhg0bNuzfL5yD/DUKfhlIaZ3SOqU1tIlvE98m vjC3+aU9L+15aU9hfWPbjW03tv27vQ4S5H8HlSs///z06VClSs2a5cv/6+N8882HH7ZuXVjv3v2D D/6rXSVOnz569MIFOHNm48aRIwvbo6M7d546FUymYsXi4wvbk5M/+uiVVwrrRYqMGLF06cPbH+Sf 9fP5bt++dw/S07///t13C9sHDz569MYNqFQpIcFq/eO4aWn37xsMcOLEvXt/5R8Pvz8/PysLWreu Xz809I/Hz55NSXG7Ye7cmjVLlPjz4z6MQ4cOHTp06DFEnDXV86O3Pxi+NTa1HAGtjfaR3hHkssZv DdVBXmJSzImghujDte+BJZ71/ong+Myx37YLjJ9bvjD0BnGzVFc0gfiEcFF4FrS2vKj+AFK0nGF4 HVLzsuek5MP1N64vOLQFireJ6xLXBDI/d9d2DwKn0zTR9BIUW1lmYcWi4C/ifgs33Jp5/2XXYEhw h/e13wTrEXtZQzbotbTBDAWO68318yBOEhaKfhCWiJ3kz0Evqn+uTQWtPz94s4CK6jp1OEiLxROW kaAfEQcZ74E8x7EuMgo0v9ouEAp6B8N0dSUoCy1Vnc1Bbmu5E/s+mMMi65vnAD1jEkv3BaY42sRM Acs9ySxHQ8Ti6rO9R+CN0zXeO/cd/Lpsz4UTP8G6ufvLqF/BvddMp0OTQDmU1yl9H2QfyKx8/33w 5rk3WhZD+LawmxH1Iex0aFm7DSwtIm9Z8kF/Rl+iDgB9g+L1rwZ/Fd8403ZwDbPUM5wG03k5VhoE mRezv/R+D95nld2Bd0E+bxwfOAY5S7x9soeAtY15j2US2CMt62z3wHTY0s7XEuQ1hnHaFnDdyQtx z4KwYhGzwpIgv7bf6DsCOSvyO+b0BuGwNELcBMbPDRMNL8PlMTcbXssB22vWQ4Z2ELolrJHRD1Gj il0ssh4ip4dEhjeF8NthPkcnMM00OUN1MJSzbbePg4AhsEIaBq7xuT/5noT8db6LgedBMltzDGMh /FjM1VgJLDushxwmUF7Ju+jdBxnZd27fGgoZa+5WubAeAvF647z5oH2svyO8D/lJ7qraN+Dsrsp5 NSCQrRXRloK/mvqdPgKUbXoH/QlQ9yt91c3grx54MxAJ+nhtqzoN9JNq38AzoAYCTXzvP/pEfRgF wrZA6BYI6AKBdevWrVu3bj38/IJUjIJFggXjBN8o+J9JwbZzu77Z9c2ub6Af/egHMIMZzCjcru3N zDcz38z8u70NEuR/F5r2W2Q4Pz8rKz8fTCar9R/tc/xX8fv/cc6wz+d2+3yFdh8kEPjtzXm6npfn dIIo/uNFfn81heNh/TTN4/F6QVH+8ZsBfb7f/MzOdrsVBUJDLRb5d+qzVKmoKI/nt/2hQ0LgwoXM TEGA/zpeDk8/XaJEfPxvkWy3u7A9N9fjUZRCu4+bRxbOyhRXvv4TGOqFfSPGgbrUv1GtCb7Z+heB ZWBsaGpCDMit5YaGRPAcCnzlawbieWGJNhcMy8ydDe/A/TH3b99cB8p25Vf/92BC+krvCY6jtqHh ByH/qZxueT6wv2q+FjEGTKXN6+0DISrcvtkcAc7VziJnNLiyIqVd7peQWCFyZlQa2HZYXlLrQ8q3 aXv9ZaBYo/AiplOgNhV8FAFltFIycBiEyWJbsRFQlIVCGAjbuS+vBN0murPHgVCbGmJVIFJxqs+C ctfpynkKDI3tTYu0BrWycE+9BLLTcT2uBhjO2sPiKoP2rHLEmQ1qG+/B/ApgrGeuF/0zqDsMq23P gvqZ9rIugWaVXzYfBlv18sfqvwfPly3f5+k+UG5SmWobvoYFXX/46nBduLzVKpc6Cd6KrmYZq8Az MP9abiz4d6RtvDsEXF/kbTaPh9AvHflR0RCSHLLCdBBsl62vmL+D0HdDJjgUiDofVUtNA/9ZzxrX s2BQbIl55SCwW+krlgYl0avpm0D+pGR+sY6Q1yf3La8GpiaGN8zVQLqrrglJBbfBXdO/AOz7Lf2F UhD/Y0TF6NNgx/BswhRIm2FslfIKhOyyH7BNgqh9Iauid4OzU9G3PX3AMNt4jd3gSAm32vqB5ZrZ GfYVGBvKZvtgCPi17dJT4C8aMBEDOTnpn3tfgMDXag5bQfvV2MXcHixfhY60vAv2quFrI54HqZjv IC7IbXjzePoGcLXLup/cG5SzysL0j8DWxf6l9gX4tihXLAvAW9a/x98N7KIlSTsE0vrAfHdR8H2o VNBLg15frkA+KLe1vmoo6E+Z4vgQlL66SX8atGPaJk0E4ZJgMPpBEZUV8iP85PpnKRC6BUL6wW3k CvZxLaAgl7latWrVqlX79/sX5PFQ9dWqr1Z9FZaylKUAQxjCkEcdNUiQII+DJ54oVSoiAu7cSUnJ yIC4uISEqKjHJ6ALKBDM9+//ZqfA7oNUrFi8eEQEnD5961ZmJohiaGhICISFDRr0xRd/7P+w9n/W T9c9Ho8HNC03Ny8PqlQpXjwy8o/nhYYajbL826u5/X5ISPgtgSIszGKRJMjKEkVJguLFQ0Pz8qBu 3cREmw0kSRDE/2Il3q1bv9nNz9d1WYacHI9HVSElJTfX7y+0+7h55FSNew0uvntjC0Suf2JqsREQ SPd0UkuAkqnGBkaBqbexpeE46LLi8tkgd+TurodCIG+2/pVcFYpcfq7qM20g25PjuVcffMuVYcpo MGUbvxGrwdk3Lif8mgK5l9TX8l+GMqWil5fqCglq5JqKuXC60wXn8Tw49/5d/4VLcPHM3dNSHajy ZsUJLV+AOhMrZRYbDU8ci9ogtAShpKGjWAzEjfoWfQXoU7Vm6m3QU8U2QhqI3YTihsYgpIp79Och 1ZR9/dIASO/inX2jLEQMi2gX0gu0T5yu7KkQbjE5K34AoXMdvcrVA187rYL7AvCBIIsyCLtIkXuB +LkWERgGykz9Z60NiLpY1fAGkKhHa6kgfKXP10+Dmq43EBKAiuyTosD2uaWK3AhWhc7s8/FdWNf2 qPFGH9ATbDOiLoJ7irdxoB6o690lcn8F/aJnVt41EGXtlH8pWN+T86SZYN5l72LPB4fFYbHOgZAR 1pfMp8E8w2wyyGAYIY9SnwPtV1I0A/hLqx8pXtBPaqWU7qDN104HukHApDytauCp5n3dPxqElXKy 8DxI84Q4sSZI04UFwiXQFmgtBAFMbtP7xj2gbRSaa7+AqYr4jPElMOSbf7I+CVo4a4RzoE0ONBRT wVvZ20wrD8693mL+AARGBbYGMkCtJy0S3gIpxnjEdhyM4y3hxnyILhNS1wIU8cUOsl2CO4H7b2T8 DPlKToX0zyG7dmrCxc6Qm5/m8c8A9RibAr+CHKe00ZJANIkrTQ2A1UazHAHyh+I6qSjo7/CO9A74 J6pleRf0j8nXxwICjYSToCcIv4grgA/ELdIXoMvaKb0WaG8JN8SdoGeI5+Tp8GO3n0d+v+3xT9wg QYIECfKfQVZWTo7TCb17v/PO11/D+fNXrqQ9jkUWD6FChTJlYmJg8eJp015+GSIiwsJ+/2bS9PTc XKcTXnhh9OiFC+HkyStX/tE+0Y+LatXKlImPh59+mjSpXz+Ijg4N/b0/2dm/xY4/+ODMmeRkSEv7 LfL87yImxmqVZfjww8qVixSB8PDHI6AfW6qGPM7xnXEtBGbk1M13g/5K9rc5u0AY70pxWUEfXXZ+ qZaglnb3cS8HZ/HN5359G8LML77dLh+EfZYE4TgkTDK+UnQAZA9yV8mzw4mM49qBmWApazSGvgSe fbY1+i2I2mEtGd8QDO8Yy4XXhR1pu8Lv9IZ7I4Qf7nYGd4S0LnADth7bdf77C+Dr5Kfr11AqsfH6 4vXA4jKdpyeo+7XXRQ8Ip8S7wlwQRwp7pI6g5fKhPwHkBdQznwF37TxfVn+4vPpKz+OlQDmszzB8 AfpC03DNB9GnIiKTL0LF7UU+8yVBdLK1ceIuwCIONnhA/0ZEawhMFjaLISBAS2MrED7Uq6sVQF9H DzYA24WlwiQQw4XbFANtFp2UAAQ0pYh2EISK/tx8HcQNGU2uA/I4bZ76Psh9zF3tG0B7IaxE5CVQ fgmpGnEV1F5+wfk9+Pv7Nud3ACU6MEarCYENWdOzLkKOM+sZuT2Y6hs/FN8Bs8W0w9IeTJUMw02l QQw3zZc2gHRDkuWDINU1lLPuBOMeuYnYHgzmkL0EAJnntBQQvEwUl4AQokv6BtCa6rcoC8pQPVXr A2o5JZJFkN9cKcMr4Fub08cbC97egamKCAExUEK5AOpR9nIW5DWmZPN8MC61rrBNA2MHcwPrQYgb ZV9uXAo1OpebFbUGanxX8+XKMyHu06TLpabC5ne3zv66JKS+kTf5Zmmo3qCmr20bWL1pzb2fh4C+ 2fOqoSQ0/a5KrfrpcCXubIeMsnDs22PlzleAO4uyIrLGgO95ZbDSBSxjTcvMvUA+ZnjV0A+0imoR /V1Qa2lfKidA/1oYIH4LYnO9uxgK2mX9rmYA7bi+Tx0FdPv3fTkECRIkSJC/nwLhun79F1+89trf 7U2hcD106LPP3nzz7/amULjOmfOPF/H9v8YjC2fLF8oUfysILL+Zd289EOlr4akC2jPeIv4Xwbhb aFNyDRDqmu36Gdjivx5YAqaPYyJDqoFhOdPljZD5lntthgDH1x8fvm82JMwybot7C1zJ5uaucAhL E0Y4EiF2U1yJ4r3g1KlrX6aJIJ4OGZy4APRFmWtSQqFokfLDq7SFlBrX+1yZBxcWXPVey4AjW5La RyTAc10qzrL3gsCqwDLfZJC3mSIsz4J6WFvvTQHhlDDXVBToq5cRwsHwgWWSaRfElKiglQGSD5/y XBkGpXZLEXErwX7JFWlpC9dSN+9eFQf2eaXTqrUBYZ3QUUoC/Tbr5fZgGFF0e5muIL8TnV3iadC3 6w2ZD6wQepIN+kL9PDoIyYziKIg19WihFBga6gnqByB8rS1Wu4LrK+eTmfdBflXZ7SkNYifzbscG kGMs+yOiwZhnuRB5CcQalrm2H8H0c6g7XABtqrN/Vix4UWK1eRB4X7+n5YB2SC+u6eBs7lnrOQ7i yy5//mVQJHWXfhForrs5A8Iq4Yw4GYwLeUI4D/pOsQ99QH9VWCS4QGjIYiEB9C/4SVwN+mRhISGg 9defVfaBHia8J5YB/TWhqHwXhLXSdrkFSCcNxwwHQT4Z0iDsFlimW6bbfgazw7jGfBDiMq1ubSfU aFq8tsUO1VrVrlL1GYjbXVauIYGySDhnjobASX0WO6Hhu/XdXcaBs4gz0OhdiOiV8FrpzyDa0n1h 2T1gX+goU0aG0EthvYu/BxUya06/2w+Stlbvem4ofO9efmvDbfC/l59zzgPJHVO/zq4Iak9xuuQE o8OsWY+CIVFaYvgCZLO0UHwG6IZT7Az6KjVeOwPaQOW4/ikA5Wj0d0/zIEGCBAkSJMjj4JGFs7RB PiKdBt3tqG/7EYRNMWmxo0DowAUhE6gk++Um4Ft+J+76DZC7RL0aPgbk92MiYr8FT0jgfn51yBud l3xvEFTfWrlu3YUQ3T98RrwNDqSfb7xhNIRH27rHTAa9nXzd8CacG3i8+o5dYJxlbVt8MRSfZfuy fDTU2lb26lM2uNAgsmdJQHhe/VJ7GqpmlPVECuAb7Xo2/T0Q3vI0zmoJ2ipZtRUHcbm1v80HeiND nvEHkC6ZN4rRkDLwhHy1EqSczX3vQjuwLYj/0JQFEalRjZNmQfn3K/taDgGPuWK1u37Qk7Nq3SsC vgX3Ot/4AfQk13s5VUGVwss71oLh2Yj46DzgCWFYaDXgLP2U+aA/zzlGA6dIZiVoLYUf+RB8H/s7 6M3Al+/fgBO0AfJdQ2fw3g4sci8DDN7D7u0g5OWuyvwFTPmm7Ps2sLa0jwnzQ7EtxRKjUqB9dN/6 zarA/fR7t7NfgtsrrsXfzYfb/TMGu3pC5qfuEoFpkH/Sv1CoA+4c/ZxyEoTWaqQ+EgKhKlo8uE+o 6Vp34AlhnL4e9GhhD/OBtXxIJogx4lDxKRCjDB8YfgBhgxRp+AbkdYbWxgYgzZQz5EkgjzB4jO+D IUl8S14OjKczz4IhWrUG0kGbntHwfnV4rvjzHUo1h6efbUP7kuB9T2wddRN8XwTGeqNBPyx+7msG Yqx0WewM0ovmMNsiiBolV7Dkgz6GqubFkFis6N4m4yBgUqYpW8Gf6b/sPw7G9227zS0gcF4dHNYW nn61ersqPoifG5ZR7FVIPujepr8E289t+WSvC1LmZr5xdxd4zIaz8nqwCMpXpuNgWmmqadwA4iFx n3gU5AjDk/Jv2+cEY85BggQJEiTI/xAeOcc5SJAgQYIECRIkSJD/yRTkOD/ymwODBAkSJEiQIEGC BPnfQFA4BwkSJEiQIEGCBAnyJwgK5yBBggQJEiRIkCBB/gRB4RwkSJAgQYIECRIkyJ8gKJyDBAkS JEiQIEGCBPkT/P/b0RWsFgwSJEiQIEGCBAkSJMgf+f8AU44p91En/UsAAAAASUVORK5CYII= --089e0158ab3a04c80e04f970b575-- From nobody Thu May 15 08:51:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC2D1A0651 for ; Thu, 15 May 2014 08:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.55 X-Spam-Level: X-Spam-Status: No, score=0.55 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 fBPqJEJmW8Up for ; Thu, 15 May 2014 08:51:28 -0700 (PDT) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6241A058E for ; Thu, 15 May 2014 08:51:28 -0700 (PDT) Received: from [66.196.81.171] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 15 May 2014 15:51:20 -0000 Received: from [98.139.212.219] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 15 May 2014 15:51:20 -0000 Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 15 May 2014 15:51:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 472670.75617.bm@omp1028.mail.bf1.yahoo.com Received: (qmail 92602 invoked by uid 60001); 15 May 2014 15:51:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1400169080; bh=7qW3OT8G85yZGS+sBhMaAP++Zo+XAN1yf+hkXk+3rLs=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=E+qS9cgPS5O+EiMX6OGHDI82CphNRXu7wY3/ZxQjBWbIKSV1M/GGJKTc+fqtescITxuRZDlScyxB0WjDVeYJEX6KAiNYivY5QXAG6Bri61PfSL/+JwfMJMQpeASnkcGzw9SF4aL7C3P9BKXHnZk7AKdiFk0d/akcOp3wOx0PqyM= X-YMail-OSG: g8J46QAVM1nZ7eMHcZGUFYcHzz4ws61Yw5_9w4stIzWYVFW 3oweSq2Ut3vzXHfRN1M8GuA8iHXDTIAUO6sVaUvy5QMhA1ZjghfJXf3QwNI_ jc8Qa64lRlDDOI4gNm4DFKq0cFgP5R3KaqAhPlOtzsOXk.IYKZF8e9rzXOUE KC4E1.0Ylu_3419YhZ4yvfR9lhdDZxhFUJX50zTMq6bQ_gPRq.zVlgpF0xE6 1fB16c.s6ggisJAwX1Mniy6T8cYt0V9oahP.uU93fZiKVRbNKPPz89z195hb ynWXP3CFwM07shAFGbtsgJG4uz2ReseQvvCGZM8fZK51IC1.n4ciBnjcUwez 4GPiChvj_ID2mzdleBi00X4_lz8XidqPnM3hkmMLsg8aw6Eku008Iukqo5Lp a6TiE8b.8X93Cy392lSq4hmgqxCkjRem73__0LOgiK0x5U3HbDeyYoeEhCbj EplCIMtF_qTAiunPfC1DliI2ByNefi1hSqh2o9DJeE_wbU9osfIsyyuKCi9A sZo5DYRcojXMxgDPxvTw_BOJHQUzVDxbXQUaOsNuhHIdBb6x5rjHTd3N35DC upw-- Received: from [209.131.62.115] by web142804.mail.bf1.yahoo.com via HTTP; Thu, 15 May 2014 08:51:20 PDT X-Rocket-MIMEInfo: 002.001, SSdtIHJlYWRpbmcgdGhlIEFDNCBkcmFmdCBhbmQgSSB3YW50IHRvIHVuZGVyc3RhbmQgdGhlIHByb2JsZW1zIGl0J3MgYWN0dWFsbHkgdHJ5aW5nIHRvIHNvbHZlLCB3aGljaCBpc24ndCBhcyBjbGVhciBhcyBpdCBjb3VsZCBiZSBpbiB0aGUgcHJvc2UuIMKgSXQgbG9va3MgbGlrZSBpdCdzIGV4dGVuZGluZyBPQXV0aCB0bzoKCjEpIEFsbG93aW5nIHRoZSBjbGllbnQgdG8gc3BlY2lmeSBhIGRlc2lyZWQgYXV0aGVudGljYXRpb24gbGV2ZWwuCjIpIEdpdmluZyB0aGUgY2xpZW50IGFuIG9wYXF1ZSBpZGVudGkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 Message-ID: <1400169080.91434.YahooMailNeo@web142804.mail.bf1.yahoo.com> Date: Thu, 15 May 2014 08:51:20 -0700 (PDT) From: Bill Mills To: OAuth WG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2129327256-1209752072-1400169080=:91434" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/oWM9ySdXyAWmJECf-aTTQ766Dag Subject: [OAUTH-WG] AC4 and what does it solve? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 15:51:29 -0000 ---2129327256-1209752072-1400169080=:91434 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'm reading the AC4 draft and I want to understand the problems it's actual= ly trying to solve, which isn't as clear as it could be in the prose. =A0It= looks like it's extending OAuth to:=0A=0A1) Allowing the client to specify= a desired authentication level.=0A2) Giving the client an opaque identifie= r to differentiate users.=0A3) Telling the client what level of authenticat= ion was used.=0A=0ADo I have this right?=0A=0AThanks,=0A=0A-bill ---2129327256-1209752072-1400169080=:91434 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I'm reading the AC4 draft and I want to understand the p= roblems it's actually trying to solve, which isn't as clear as it could be = in the prose.  It looks like it's extending OAuth to:

1) Allowing the client t= o specify a desired authentication level.
2) Giving the client an opaque identifier to differentia= te users.
3) T= elling the client what level of authentication was used.

Do I have this right?

T= hanks,

-bill
---2129327256-1209752072-1400169080=:91434-- From nobody Thu May 15 09:15:00 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9C11A02D0 for ; Thu, 15 May 2014 09:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 glcT3ISSeIOj for ; Thu, 15 May 2014 09:14:46 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 382F41A0110 for ; Thu, 15 May 2014 09:14:36 -0700 (PDT) X-AuditID: 12074422-f79376d000000c58-bf-5374e7e42ac4 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 2A.FF.03160.4E7E4735; Thu, 15 May 2014 12:14:28 -0400 (EDT) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s4FGER15001550 for ; Thu, 15 May 2014 12:14:28 -0400 Received: from OC11EXEDGE3.EXCHANGE.MIT.EDU (oc11exedge3.exchange.mit.edu [18.9.3.21]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id s4FGER9R029260 for ; Thu, 15 May 2014 12:14:27 -0400 Received: from OC11EXHUB10.exchange.mit.edu (18.9.3.24) by OC11EXEDGE3.EXCHANGE.MIT.EDU (18.9.3.21) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 12:14:11 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.100]) by OC11EXHUB10.exchange.mit.edu ([18.9.3.24]) with mapi id 14.03.0158.001; Thu, 15 May 2014 12:14:27 -0400 From: Thomas Hardjono To: OAuth WG Thread-Topic: [OAUTH-WG] AC4 and what does it solve? Thread-Index: AQHPcFWIpKz8OsBfr0GXcQFQ1ELIOJtBzyYg Date: Thu, 15 May 2014 16:14:27 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A714F72F2@OC11EXPO24.exchange.mit.edu> References: <1400169080.91434.YahooMailNeo@web142804.mail.bf1.yahoo.com> In-Reply-To: <1400169080.91434.YahooMailNeo@web142804.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [18.189.31.171] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001B_01CF7037.36DE3C40" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpik+LIzCtJLcpLzFFi42IRYrdT0X3yvCTYoPutpcXJt6/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8Wb1FeaCj54V6xe1Mzcwdrp1MXJySAiYSLy59JUZwhaTuHBv PVsXIxeHkMBsJolbE08xQzhXGSXu3DsKlbnDKLHr6zEoZzujxJ/919ghnNWMEneftYINYxPQ kDj3ey87iC0iICsx/9JWFhBbWMBY4tKNXUwQcROJ0zvPAcU5gGwjieXbOUHCLAKqEnue7QIb wysQJHHg8G1GEFtIwENiwt5TrCA2p4CnxPvpV8HijEB3fz+1Bmwks4C4xK0n85kg/hGReHjx NBvMb/92PYSyFSVWPz3MBHIzs0Avo8TDJatYIZYJSpyc+YRlAqP4LCSzZiGrm4WkDqLIQOL+ oQ5WCFtbYtnC18wQtrXEjF8H2SBsRYkp3Q/ZIWxTiddHPzIuYORYxSibklulm5uYmVOcmqxb nJyYl5dapGuql5tZopeaUrqJERy9Lko7GH8eVDrEKMDBqMTDGzG1OFiINbGsuDL3EKMkB5OS KG/B45JgIb6k/JTKjMTijPii0pzU4kOMKkC7Hm1YfYFRiiUvPy9VSYQ3+QpQHW9KYmVValE+ TJk0B4uSOO9ba6tgIYH0xJLU7NTUgtQimKwMB4eSBO+JZ0CNgkWp6akVaZk5JQhpJg7OQ4wS HDxAw1eB1PAWFyTmFmemQ+RPMSpKifMueQqUEABJZJTmwfXCku4rRnGgt4R514K08wATNlz3 K6DBTECDT7gVgQwuSURISTUwei9vcG+9OkNJc4265vV/95L2HXGOUptxR+yZKMcXj4XheqtO L/AIfv+U1dnuwLXje50XLNzE7pUsMP3MMx3bDbZ9PT7TEuL1zh1jvVvn9izBjPPpR5EP1za+ j7aazMEm7mJ4tkC/zPbRP9Fbm3a5Tr/oHrj/5tuItfM7Tmlf0dtWueJQwc93tUosxRmJhlrM RcWJAJMp4MiVAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/7iujUuvzbbOJsxgSoFlt6kNYhGE Subject: Re: [OAUTH-WG] AC4 and what does it solve? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 16:14:55 -0000 ------=_NextPart_000_001B_01CF7037.36DE3C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Phil, I also just read draft-hunt-oauth-v2-user-a4c-02. This proposal sounds awfully close to what UMA is doing for consent management. The Resource Owner (RO) in UMA has the option to set access control policy (including expected the authentication LOA of the user/client). The RO also has the option to require the Client/User to provide Claims regarding both entities (UMA distinguishes between the Client and the Human person using the Client). UMA relies on OpenID-Connect OP to provide the Claims. btw. is your intention to create something akin to AuthnContext in SAML2.0? Best. /thomas/ ____________________________________________ From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Bill Mills Sent: Thursday, May 15, 2014 11:51 AM To: OAuth WG Subject: [OAUTH-WG] AC4 and what does it solve? I'm reading the AC4 draft and I want to understand the problems it's actually trying to solve, which isn't as clear as it could be in the prose. =A0It looks like it's extending OAuth to: 1) Allowing the client to specify a desired authentication level. 2) Giving the client an opaque identifier to differentiate users. 3) Telling the client what level of authentication was used. Do I have this right? Thanks, -bill ------=_NextPart_000_001B_01CF7037.36DE3C40 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRYzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG+zCCBeOgAwIBAgIQZinWIcJoBXWy amTeGLwOXDANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTQwMzEzMDAwMDAwWhcNMTUwMzE0MjM1OTU5WjCBwjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM5NDcyMDUzMDM3NzEfMB0GCSqGSIb3 DQEJARYQaGFyZGpvbm9AbWl0LmVkdTEPMA0GA1UECwwGUy9NSU1FMR4wHAYDVQQLDBVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHTAbBgNVBAoM FFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAldwe JSLJ1cE66HSP0U5B226vuOF+DaQknIDJ/NkcRY32lYORq41PkQZ8i6sA5OuNJsNFmsh8+2/Y27jt txJ6D0k0mao5UMWB/EP1yxcTz0d13F4ZM2k5MniihLjrKMNnJWhdgrnu2gaCWN6qsBYZdqQLmfTI juGi0nqDQxNhzCM2RWw84CM6Mjp3FepY/ElvZ6qs1ErqPHBHAH0u5B9G07R1NNYj3Zthlwr+tefl Wnz0vgTQOrehCXoY3OhverIY6LsfX8k70jj8BO1s496grGga9IaEBEG+xeX/MRln5dJwGJidhgm3 u1OF0AHvLdmLuM/13UBJzljauuJ67j6R3QIDAQABo4IDBTCCAwEwDAYDVR0TAQH/BAIwADAOBgNV HQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQf qxJcVHYXcktkA9hu2yxr2cel7jAbBgNVHREEFDASgRBoYXJkam9ub0BtaXQuZWR1MB8GA1UdIwQY MBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUF BzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMl MjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIw T1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1h bnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0 aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQ oE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVm MDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8v d3d3LnN5bWF1dGguY29tL3JwYTArBgpghkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGGx85v FgUxMDkyMjA5BgpghkgBhvhFARAFBCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhW MGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQBU+20ff1cQSUmPgcdmRkvjK2xNG9Pq3ZCcxz/t jsZ/MY0x5NyVgg/Ko0tCoFkCSPB2uUiNGoqJDsXeaGwJ2s4kcynVo84uHK1bi2ZfUgK7eLT5ib4F IQ4cwxqG12sA8J1N0p8nLbkC8zm7eI0rrumZcrla+M4oyJNp8wpUFlds4EsOAxpxgR5sGxG2FIWq I75dE2PQdRNAzi35J00ZXYb5csaw5Upv0acZ/WzMrw5JVJXDufU1h4bi8TcRhuqJ1hkBrhjL1Ajr cnAX1QH7ta9AuUGWR76VpxN1vQ4Fn70IguzJF54kddeSv88lce9MhxX9rLE/oHFf6YrdoZ9qQCnZ MYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEc0AhBmKdYhwmgFdbJqZN4YvA5cMAkGBSsOAwIaBQCgggKrMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDUxNTE2MTQyNlowIwYJKoZIhvcNAQkE MRYEFNZxXL4Tens+uCuZi1wd53h0JTsOMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEq MAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcG BSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQC AzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBmKdYhwmgFdbJq ZN4YvA5cMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEGYp1iHCaAV1smpk3hi8DlwwDQYJKoZIhvcNAQEB BQAEggEAGcmC/QhbCJ36mb7jBqmko+prAqTkLWZ2b05xs0Q2f58SXS+TNteVKmIGrjvnAgjLIrCD TIzJptTM1Q4iSXFYUiMG5Qa3jPvqH3JPyc4Q9QmZS1JUvJt+VV1oJmRtr5tGUMT1tqbWxHFuXmEK AbVZm5SvD1rU4DkXf4uIg1F61PQ031DrgBzy2FsJv+E9zyVcvK9/3l6Ca65y2S1jBG8TzAksPblk J8s6fyT+UTQOcCiMTGPy/5HVQ7edSRV9GlvCbfo13i842QFzv363jaqujNVZBQfMTKbeQM3ahZVT WrPvVVyheoGcXtWzOuDqq3ZODKM+CNmffqQyzFBiHAZ2uAAAAAAAAA== ------=_NextPart_000_001B_01CF7037.36DE3C40-- From nobody Thu May 15 09:42:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803A71A0661 for ; Thu, 15 May 2014 09:42:10 -0700 (PDT) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 nxowi6Laa_PN for ; Thu, 15 May 2014 09:42:07 -0700 (PDT) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420621A0656 for ; Thu, 15 May 2014 09:42:06 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id e51so838492eek.24 for ; Thu, 15 May 2014 09:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=vXow4mxwZn73HyIGX3tJq0RNN7yoYNvvbTU35/3z9Bc=; b=KbzkjFJhp1BHRvRVWQm3Vzzw29EbpFI6JRuv9ZtwckkCFK3hlapdPfjm+UjXIdK1aX vjsjnO3r5gxguUoFYePi7TmrD1MmEDlRXdNqvzls+haBcOOGBssg8rbmex4LGRKicyMF 2YR8iXQuxvdMz6IZW9UMqukp2QsLzpu/sPivEoZuXVEVKz4W3ngzmtORf6mfdtp/afBv x4Gcc+eOeW9DN6O+vbKacQW79Ajz9aoAAG1Dm+LV6xZ7tzEsm999p7oT/NDvVTXRvihe eF98adGp9CWMtIK4XChDxSDIHrUnxsLBL2fNLcv9aaU0pDS34my6iXvxmv471lGh/HHj mMyg== X-Received: by 10.14.1.69 with SMTP id 45mr4034671eec.104.1400172117988; Thu, 15 May 2014 09:41:57 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id l4sm13797544eey.13.2014.05.15.09.41.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 May 2014 09:41:57 -0700 (PDT) Message-ID: <5374EE47.9040101@gmail.com> Date: Thu, 15 May 2014 17:41:43 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/iAreB1rCl0ABGY0lW1SZRlV8u7s Subject: [OAUTH-WG] Client authentication and assertion grants X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 16:42:10 -0000 Hi I'm reviewing the way client authentication is expected to be done when either SAML or JWT bearer assertion is used as a grant [1] which corresponds to the case described in [2]. [1] says: "Authentication of the client is optional...". Can someone please clarify how it can be optional given that in this case a subject of the assertion does not identify a client ? Is it about supporting unregistered clients which have managed to obtain somehow the assertion grants ? Thanks, Sergey [1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-4.1 [2] http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3 From nobody Thu May 15 09:43:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10161A065B for ; Thu, 15 May 2014 09:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 j6kPIXw_a8DP for ; Thu, 15 May 2014 09:43:10 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC501A0649 for ; Thu, 15 May 2014 09:43:10 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4FGh0ke029117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 16:43:01 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4FGgxBf029752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 May 2014 16:43:00 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4FGgxVo003149; Thu, 15 May 2014 16:42:59 GMT Received: from [192.168.1.188] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 May 2014 09:42:58 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: <5E393DF26B791A428E5F003BB6C5342A714F72F2@OC11EXPO24.exchange.mit.edu> Date: Thu, 15 May 2014 09:42:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0C66C6C1-6A95-4666-85AC-F282CA7D1695@oracle.com> References: <1400169080.91434.YahooMailNeo@web142804.mail.bf1.yahoo.com> <5E393DF26B791A428E5F003BB6C5342A714F72F2@OC11EXPO24.exchange.mit.edu> To: Thomas Hardjono X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fIeDk83mkDuYlETrlprxx1GUzEA Cc: OAuth WG Subject: Re: [OAUTH-WG] AC4 and what does it solve? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 16:43:11 -0000 Thomas, The intent was to be compatible with Connect (by request) but to solve = only the authentication issue. That would explain the overlap with UMA. The issue (or bug?) we face is that OAuth Clients who continue to use = 6749 alone, aren=92t really authenticating users. More importantly there is the question that has emerged over the past = year about whether the client should know and be able to request = authentication techniques and or levels. There is a demarcation issue = to sort out. There is also the re-authen requirement that happens a lot where clients = wish to elevate assurance level some how and may want to access a = resource (not related to user profile). In the re-auth case, you know = the users profile, you just want to confirm is this really Thomas? Just = using OpenID means a much more complicated set of requests if only = because everything has to be done twice. Regarding AuthnContext, I understand the same issue happened and the = model chosen (for assurance) didn=92t work. I don=92t want to repeat = past sins (as Brian says). I believe LoA was the solution to the = problem, but I think Mike wants to talk some more about it =97 which is = why it is in draft 02.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com On May 15, 2014, at 9:14 AM, Thomas Hardjono wrote: >=20 > Phil, >=20 > I also just read draft-hunt-oauth-v2-user-a4c-02. > This proposal sounds awfully close to what UMA is > doing for consent management. >=20 > The Resource Owner (RO) in UMA has the option to > set access control policy (including expected the > authentication LOA of the user/client). The RO > also has the option to require the Client/User to > provide Claims regarding both entities (UMA > distinguishes between the Client and the Human > person using the Client). UMA relies on > OpenID-Connect OP to provide the Claims. >=20 > btw. is your intention to create something akin to > AuthnContext in SAML2.0? >=20 > Best. >=20 > /thomas/ >=20 > ____________________________________________ >=20 >=20 > From: OAuth [mailto:oauth-bounces@ietf.org] On > Behalf Of Bill Mills > Sent: Thursday, May 15, 2014 11:51 AM > To: OAuth WG > Subject: [OAUTH-WG] AC4 and what does it solve? >=20 > I'm reading the AC4 draft and I want to understand > the problems it's actually trying to solve, which > isn't as clear as it could be in the prose. It > looks like it's extending OAuth to: >=20 > 1) Allowing the client to specify a desired > authentication level. > 2) Giving the client an opaque identifier to > differentiate users. > 3) Telling the client what level of authentication > was used. >=20 > Do I have this right? >=20 > Thanks, >=20 > -bill > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu May 15 09:54:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179C51A0683 for ; Thu, 15 May 2014 09:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 GV8GbTygj2mV for ; Thu, 15 May 2014 09:54:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9133F1A0672 for ; Thu, 15 May 2014 09:54:14 -0700 (PDT) Received: from DM2PR03CA009.namprd03.prod.outlook.com (10.141.52.157) by DM2PR03MB447.namprd03.prod.outlook.com (10.141.85.18) with Microsoft SMTP Server (TLS) id 15.0.939.12; Thu, 15 May 2014 16:54:06 +0000 Received: from BN1AFFO11FD028.protection.gbl (2a01:111:f400:7c10::104) by DM2PR03CA009.outlook.office365.com (2a01:111:e400:2414::29) with Microsoft SMTP Server (TLS) id 15.0.944.11 via Frontend Transport; Thu, 15 May 2014 16:54:06 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD028.mail.protection.outlook.com (10.58.52.88) with Microsoft SMTP Server (TLS) id 15.0.939.9 via Frontend Transport; Thu, 15 May 2014 16:54:05 +0000 Received: from TK5EX14MBXC293.redmond.corp.microsoft.com ([169.254.2.113]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0181.007; Thu, 15 May 2014 16:53:36 +0000 From: Mike Jones To: Phil Hunt , Thomas Hardjono Thread-Topic: [OAUTH-WG] AC4 and what does it solve? Thread-Index: AQHPcFWLNzwxzuuT906YeqXEBpAfSptB0NGAgAAH9ICAAAFRkA== Date: Thu, 15 May 2014 16:53:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD24FD8@TK5EX14MBXC293.redmond.corp.microsoft.com> References: <1400169080.91434.YahooMailNeo@web142804.mail.bf1.yahoo.com> <5E393DF26B791A428E5F003BB6C5342A714F72F2@OC11EXPO24.exchange.mit.edu> <0C66C6C1-6A95-4666-85AC-F282CA7D1695@oracle.com> In-Reply-To: <0C66C6C1-6A95-4666-85AC-F282CA7D1695@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438001)(164054003)(51704005)(377454003)(13464003)(24454002)(199002)(189002)(46102001)(55846006)(79102001)(76482001)(20776003)(47776003)(77982001)(66066001)(26826002)(80022001)(64706001)(81342001)(84676001)(19580395003)(15975445006)(69596002)(68736004)(81542001)(46406003)(15974865002)(86612001)(33656001)(23726002)(4396001)(21056001)(92566001)(74662001)(31966008)(74502001)(85852003)(97736001)(83072002)(86362001)(92726001)(97756001)(6806004)(50986999)(19580405001)(76176999)(54356999)(2171001)(44976005)(561944003)(83322001)(99396002)(87936001)(2656002)(81156002)(50466002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR03MB447; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0212BDE3BE Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/HlkYA0VeeEqWjFVMkUSO02BT9NE Cc: OAuth WG Subject: Re: [OAUTH-WG] AC4 and what does it solve? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 16:54:17 -0000 The "acr" claim (authentication context class reference) and the "acr_value= s" request parameter are explicitly modelled on the SAML authentication con= text work, but without the more complicated parts that didn't work out well= in practice. In this case, the request is just an ordered list of request= ed "acr" values. Some of those values might be level numbers, but they als= o can and will be URNs such as "urn:mace:incommon:iap:silver" or "urn:mace:= incommon:iap:bronze". In fact, the same values can be used as are used wit= h SAML, if it makes sense in the application context. Phil, I don't understand why you're saying re-auth would be any different w= ith full Connect than with AC4. The re-auth request would be the same - an= OAuth authorization request using prompt=3Dnone - in both cases. Cheers, -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Thursday, May 15, 2014 9:43 AM To: Thomas Hardjono Cc: OAuth WG Subject: Re: [OAUTH-WG] AC4 and what does it solve? Thomas, The intent was to be compatible with Connect (by request) but to solve only= the authentication issue. That would explain the overlap with UMA. The issue (or bug?) we face is that OAuth Clients who continue to use 6749 = alone, aren't really authenticating users. More importantly there is the question that has emerged over the past year = about whether the client should know and be able to request authentication = techniques and or levels. There is a demarcation issue to sort out. There is also the re-authen requirement that happens a lot where clients wi= sh to elevate assurance level some how and may want to access a resource (n= ot related to user profile). In the re-auth case, you know the users profi= le, you just want to confirm is this really Thomas? Just using OpenID mean= s a much more complicated set of requests if only because everything has to= be done twice. Regarding AuthnContext, I understand the same issue happened and the model = chosen (for assurance) didn't work. I don't want to repeat past sins (as Br= ian says). I believe LoA was the solution to the problem, but I think Mike = wants to talk some more about it - which is why it is in draft 02.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com On May 15, 2014, at 9:14 AM, Thomas Hardjono wrote: >=20 > Phil, >=20 > I also just read draft-hunt-oauth-v2-user-a4c-02. > This proposal sounds awfully close to what UMA is doing for consent=20 > management. >=20 > The Resource Owner (RO) in UMA has the option to set access control=20 > policy (including expected the authentication LOA of the user/client).=20 > The RO also has the option to require the Client/User to provide=20 > Claims regarding both entities (UMA distinguishes between the Client=20 > and the Human person using the Client). UMA relies on OpenID-Connect=20 > OP to provide the Claims. >=20 > btw. is your intention to create something akin to AuthnContext in=20 > SAML2.0? >=20 > Best. >=20 > /thomas/ >=20 > ____________________________________________ >=20 >=20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Bill Mills > Sent: Thursday, May 15, 2014 11:51 AM > To: OAuth WG > Subject: [OAUTH-WG] AC4 and what does it solve? >=20 > I'm reading the AC4 draft and I want to understand the problems it's=20 > actually trying to solve, which isn't as clear as it could be in the=20 > prose. It looks like it's extending OAuth to: >=20 > 1) Allowing the client to specify a desired authentication level. > 2) Giving the client an opaque identifier to differentiate users. > 3) Telling the client what level of authentication was used. >=20 > Do I have this right? >=20 > Thanks, >=20 > -bill > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Thu May 15 11:11:45 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738521A008A for ; Thu, 15 May 2014 11:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=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 zpCbhuudvpae for ; Thu, 15 May 2014 11:11:36 -0700 (PDT) Received: from nm31.bullet.mail.bf1.yahoo.com (nm31.bullet.mail.bf1.yahoo.com [72.30.239.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC281A02FE for ; Thu, 15 May 2014 11:11:35 -0700 (PDT) Received: from [66.196.81.172] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 15 May 2014 18:11:28 -0000 Received: from [98.139.212.248] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 15 May 2014 18:11:28 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 15 May 2014 18:11:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 117750.9322.bm@omp1057.mail.bf1.yahoo.com Received: (qmail 50691 invoked by uid 60001); 15 May 2014 18:11:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1400177488; bh=exCBh6Wyz75vx9b66M6PAnEXrVH+G1LuccK2GBQqmU8=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=3KAYMQmrpULfgqWFieUpFF0OfnGPst7N6NxS3yYZXLdp/JbT4F9jCJQS1pJDy5R9udA2dXr9ESS4hgsR2cnriVUdzsnP9xsyehQjiHRBgqV8m18Ig3+M74qAfWS7B7hj+a8VzkB+CpjBE2c3JXCsl14pjlqGRl22D4ONYnzKxnw= X-YMail-OSG: KChOUQAVM1mZkrfIm9L2gaktRPo60NX99qJ4Dt0tF68.A7t t9UJhUzPw5wn9bIul6tOQrqtIjl0sPGkxKziAiFk7N2ttwEsURJ6Ynbs0QVT qY0yPR2Vk0tBg8du3LxY5y.gG6LpiqHhYcjt0twDUhkH3EnDNPeYVIQPmsbT 7_ou5AEyHwJC1wFrrkjoijkCJ4mPjQaGJOWT8N9PhsJwpJMp9TkR13xcckdx 23UTxz9Nu3k73P43V5YQyJQdtfdR1YnhiHeCgCOMFmubWTeU4spFocfQU06c yeeJJrHlXuJufpu7xF_07bYcPvUBcC01FjyvHcPyyACxLPVfwGWUKzHpBpHq 6Fj0I3Md84iQPWWzFYgKGXgjov3YSQ5j3zDoq6gVaSVFvCLA6fzTybbQhVxO wWdhgDzdCSV5O.J9PaKuwK59pVRHN9s8K2zguelfOxrVwcIcRij0WIW3_Koo Dh3H9X1aKbdLnivmkxnC6wi3ZXrKMe0xax6II1F2BezH9Nx6aGmKJGKAImI9 fy.91.513hSV6QWcjoHDpwoaJ7nJxLSdUL6BCMwe.YX2zFK2f8QHL8quff.1 _aSqP5mpm8DB.D0BCb5dxFBM2cDWnpIFlleD_9bIYavi6oC9ZuQoXTc33nvn zf42ZvC1Be0WE Received: from [66.228.162.56] by web142805.mail.bf1.yahoo.com via HTTP; Thu, 15 May 2014 11:11:27 PDT X-Rocket-MIMEInfo: 002.001, VGhlICJyZS1hdXRoIiBwcm9ibGVtIGlzIGFuIGludGVyZXN0aW5nIG9uZSwgdGhlIHF1ZXN0aW9uIG9mIGhvdyBkb2VzIHRoZSBjbGllbnQga25vdyBpZiB0aGUgdXNlciBuZXcgYXV0aGVudGljYXRpb24gbWF0Y2hlcyB0aGUgcHJldmlvdXMgb25lIGZvciBzb21ldGhpbmcgbGlrZSBtYWlsYm94IGFjY2Vzcz8gwqBXaGF0IGhhcHBlbnMgaWYgdGhlIGVuZCB1c2VyIGRvZXNuJ3QgYXV0aCBhcyB0aGUgc2FtZSB1c2VyPyDCoElmIHlvdSByZWFsbHkgbmVlZCB0aGlzIEkgdGhpbmsgQ29ubmVjdCBzb2x2ZXMgdGgBMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <1400169080.91434.YahooMailNeo@web142804.mail.bf1.yahoo.com> <5E393DF26B791A428E5F003BB6C5342A714F72F2@OC11EXPO24.exchange.mit.edu> <0C66C6C1-6A95-4666-85AC-F282CA7D1695@oracle.com> <4E1F6AAD24975D4BA5B16804296739439AD24FD8@TK5EX14MBXC293.redmond.corp.microsoft.com> Message-ID: <1400177487.10351.YahooMailNeo@web142805.mail.bf1.yahoo.com> Date: Thu, 15 May 2014 11:11:27 -0700 (PDT) From: Bill Mills To: Mike Jones , Phil Hunt , Thomas Hardjono In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD24FD8@TK5EX14MBXC293.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1583497461-1742884976-1400177487=:10351" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wiulMTVcxc0I-Rf_XVPm_61t_5A Cc: OAuth WG Subject: Re: [OAUTH-WG] AC4 and what does it solve? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 18:11:42 -0000 --1583497461-1742884976-1400177487=:10351 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The "re-auth" problem is an interesting one, the question of how does the c= lient know if the user new authentication matches the previous one for some= thing like mailbox access? =A0What happens if the end user doesn't auth as = the same user? =A0If you really need this I think Connect solves this well,= and OAuth is currently ocmpletely silent on this.=A0=0A=0A=A0I don't think= the userID indication to the client really does what we want. =A0If we wan= t to do this in OAuth I think it would be better to hand the expired token = back to the AS and say "this is the user I expect" and have the AS fail if = that doesn't match.=0A=0A-bill=0AOn Thursday, May 15, 2014 9:54 AM, Mike Jo= nes wrote:=0A =0AThe "acr" claim (authenticat= ion context class reference) and the "acr_values" request parameter are exp= licitly modelled on the SAML authentication context work, but without the m= ore complicated parts that didn't work out well in practice.=A0 In this cas= e, the request is just an ordered list of requested "acr" values.=A0 Some o= f those values might be level numbers, but they also can and will be URNs s= uch as "urn:mace:incommon:iap:silver" or "urn:mace:incommon:iap:bronze".=A0= In fact, the same values can be used as are used with SAML, if it makes se= nse in the application context.=0A=0APhil, I don't understand why you're sa= ying re-auth would be any different with full Connect than with AC4.=A0 The= re-auth request would be the same - an OAuth authorization request using p= rompt=3Dnone - in both cases.=0A=0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 = Cheers,=0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- Mike=0A=0A-----Origina= l Message-----=0AFrom: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt=0ASent: Thursday, May 15, 2014 9:43 AM=0ATo: Thomas Hardjono=0ACc:= OAuth WG=0ASubject: Re: [OAUTH-WG] AC4 and what does it solve?=0A=0AThomas= ,=0A=0AThe intent was to be compatible with Connect (by request) but to sol= ve only the authentication issue.=A0 That would explain the overlap with UM= A.=0A=0AThe issue (or bug?) we face is that OAuth Clients who continue to u= se 6749 alone, aren't really authenticating users.=0A=0AMore importantly th= ere is the question that has emerged over the past year about whether the c= lient should know and be able to request authentication techniques and or l= evels.=A0 There is a demarcation issue to sort out.=0A=0AThere is also the = re-authen requirement that happens a lot where clients wish to elevate assu= rance level some how and may want to access a resource (not related to user= profile).=A0 In the re-auth case, you know the users profile, you just wan= t to confirm is this really Thomas?=A0 Just using OpenID means a much more = complicated set of requests if only because everything has to be done twice= .=0A=0ARegarding AuthnContext, I understand the same issue happened and the= model chosen (for assurance) didn't work. I don't want to repeat past sins= (as Brian says). I believe LoA was the solution to the problem, but I thin= k Mike wants to talk some more about it - which is why it is in draft 02. = =0A=0APhil=0A=0A@independentid=0Awww.independentid.com=0Aphil.hunt@oracle.c= om=0A=0A=0A=0AOn May 15, 2014, at 9:14 AM, Thomas Hardjono wrote:=0A=0A> =0A> Phil,=0A> =0A> I also just read draft-hunt-oauth-v2-u= ser-a4c-02.=0A> This proposal sounds awfully close to what UMA is doing for= consent =0A> management.=0A> =0A> The Resource Owner (RO) in UMA has the o= ption to set access control =0A> policy (including expected the authenticat= ion LOA of the user/client). =0A> The RO also has the option to require the= Client/User to provide =0A> Claims regarding both entities (UMA distinguis= hes between the Client =0A> and the Human person using the Client). UMA rel= ies on OpenID-Connect =0A> OP to provide the Claims.=0A> =0A> btw. is your = intention to create something akin to AuthnContext in =0A> SAML2.0?=0A> =0A= > Best.=0A> =0A> /thomas/=0A> =0A> ________________________________________= ____=0A> =0A> =0A> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of= Bill Mills=0A> Sent: Thursday, May 15, 2014 11:51 AM=0A> To: OAuth WG=0A> = Subject: [OAUTH-WG] AC4 and what does it solve?=0A> =0A> I'm reading the AC= 4 draft and I want to understand the problems it's =0A> actually trying to = solve, which isn't as clear as it could be in the =0A> prose.=A0 It looks l= ike it's extending OAuth to:=0A> =0A> 1) Allowing the client to specify a d= esired authentication level.=0A> 2) Giving the client an opaque identifier = to differentiate users.=0A> 3) Telling the client what level of authenticat= ion was used.=0A> =0A> Do I have this right?=0A> =0A> Thanks,=0A> =0A> -bil= l=0A> _______________________________________________=0A> OAuth mailing lis= t=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinfo/oauth=0A=0A= =0A_______________________________________________=0AOAuth mailing list=0AO= Auth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A=0A__________= _____________________________________=0AOAuth mailing list=0AOAuth@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/oauth --1583497461-1742884976-1400177487=:10351 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The "re-auth" problem is an interesting one, the q= uestion of how does the client know if the user new authentication matches = the previous one for something like mailbox access?  What happens if t= he end user doesn't auth as the same user?  If you really need this I = think Connect solves this well, and OAuth is currently ocmpletely silent on= this. 


-bill
<= font size=3D"2" face=3D"Arial"> On Thursday, May 15, 2014 9:54 AM, Mike Jon= es <Michael.Jones@microsoft.com> wrote:
The "acr" claim (authentication context class referen= ce) and the "acr_values" request parameter are explicitly modelled on the S= AML authentication context work, but without the more complicated parts tha= t didn't work out well in practice.  In this case, the request is just= an ordered list of requested "acr" values.  Some of those values migh= t be level numbers, but they also can and will be URNs such as "urn:mace:in= common:iap:silver" or "urn:mace:incommon:iap:bronze".  In fact, the sa= me values can be used as are used with SAML, if it makes sense in the appli= cation context.

Phil, I don't understa= nd why you're saying re-auth would be any different with full Connect than = with AC4.  The re-auth request would be the same - an OAuth authorization = request using prompt=3Dnone - in both cases.

              = ;  Cheers,
        &nb= sp;       -- Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, May 15, 2014 9:43 AM
To: Tho= mas Hardjono
Cc: OAuth WG
Subject: Re: = [OAUTH-WG] AC4 and what does it solve?

Thomas,

The intent was to be compatib= le with Connect (by request) but to solve only the authentication issue.&nb= sp; That would explain the overlap with UMA.

The issue (or bug?)= we face is that OAuth Clients who continue to use 6749 alone, aren't reall= y authenticating users.

More important= ly there is the question that has emerged over the past year about whether = the client should know and be able to request authentication techniques and= or levels.  There is a demarcation issue to sort out.

There is also the re-authen requirement that happens = a lot where clients wish to elevate assurance level some how and may want t= o access a resource (not related to user profile).  In the re-auth cas= e, you know the users profile, you just want to confirm is this really Thom= as?  Just using OpenID means a much more complicated set of requests i= f only because everything has to be done twice.

Regarding AuthnContext, I understand the same issue happened and = the model chosen (for assurance) didn't work. I don't want to repeat past sins (as B= rian says). I believe LoA was the solution to the problem, but I think Mike= wants to talk some more about it - which is why it is in draft 02.

Phil

@i= ndependentid
www.independentid.com
phil.hunt@oracle.com



On May 15, 2014, at 9:14 AM, Thoma= s Hardjono <hardjono@MIT.EDU> wrote:

>
> Phil,
>
> I also just read draft-hunt-oauth-v2-user-a4c= -02.
> This proposal sounds awfully close to what UMA = is doing for consent
> management.
>
= > The Resource Owner (RO) in UMA has the option to set access control > policy (including expected the authentication LOA of = the user/client).
> The RO also has the option to req= uire the Client/User to provide
> Claims regarding bo= th entities (UMA distinguishes between the Client
> a= nd the Human person using the Client). UMA relies on OpenID-Connect
> OP to provide the Claims.
>
> btw. is your intention to create something akin to AuthnCont= ext in
> SAML2.0?
>
> Best.
>
> /thomas/>
> _____________________________= _______________
>
>
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of= Bill Mills
> Sent: Thursday, May 15, 2014 11:51 AM> To: OAuth WG
> Subject: [OAUTH-WG= ] AC4 and what does it solve?
>
>= ; I'm reading the AC4 draft and I want to understand the problems it's
> actually trying to solve, which isn't as clear as it co= uld be in the
> prose.  It looks like it's exten= ding OAuth to:
>
> 1) Allowing t= he client to specify a desired authentication level.
>= 2) Giving the client an opaque identifier to differentiate users.
> 3) Telling the client what level of authentication was used.=
>
> Do I have this right?
>
> Thanks,
>
>= -bill
> _____________________________________________= __
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.o= rg/mailman/listinfo/oauth


____________________________________= ___________
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


--1583497461-1742884976-1400177487=:10351-- From nobody Thu May 15 11:29:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84891A02EE for ; Thu, 15 May 2014 11:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 hXiKOrwFdf3j for ; Thu, 15 May 2014 11:29:08 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30DB71A0222 for ; Thu, 15 May 2014 11:29:08 -0700 (PDT) X-AuditID: 1209190d-f798f6d000000c3b-e7-5375076c296f Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 6A.93.03131.C6705735; Thu, 15 May 2014 14:29:00 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s4FISxCo026029; Thu, 15 May 2014 14:28:59 -0400 Received: from OC11EXEDGE4.EXCHANGE.MIT.EDU (oc11exedge4.exchange.mit.edu [18.9.3.27]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id s4FISoqe003546; Thu, 15 May 2014 14:28:58 -0400 Received: from W92EXHUB11.exchange.mit.edu (18.7.73.20) by OC11EXEDGE4.EXCHANGE.MIT.EDU (18.9.3.27) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 14:28:11 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.100]) by W92EXHUB11.exchange.mit.edu ([18.7.73.20]) with mapi id 14.03.0158.001; Thu, 15 May 2014 14:28:55 -0400 From: Thomas Hardjono To: Bill Mills , Mike Jones , Phil Hunt Thread-Topic: [OAUTH-WG] AC4 and what does it solve? Thread-Index: AQHPcFWIpKz8OsBfr0GXcQFQ1ELIOJtBzyYggABMrYCAAAL7gIAAFcKA//++fjA= Date: Thu, 15 May 2014 18:28:54 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A714F7B71@OC11EXPO24.exchange.mit.edu> References: <1400169080.91434.YahooMailNeo@web142804.mail.bf1.yahoo.com> <5E393DF26B791A428E5F003BB6C5342A714F72F2@OC11EXPO24.exchange.mit.edu> <0C66C6C1-6A95-4666-85AC-F282CA7D1695@oracle.com> <4E1F6AAD24975D4BA5B16804296739439AD24FD8@TK5EX14MBXC293.redmond.corp.microsoft.com> <1400177487.10351.YahooMailNeo@web142805.mail.bf1.yahoo.com> In-Reply-To: <1400177487.10351.YahooMailNeo@web142805.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [18.111.13.173] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0007_01CF7049.FFBC0770" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02Te0hTURzHPXd321W8dp2aR0vJi1kkmj2EkSLWHzH7o6QFhYJ2c7dttIfc u4n2R2QhiQ90aq9ZOaEHpZHpH75YtUnmI9QsUCYlC6N8BaZprqzu3fX13+fwffzOD87BRLKn knBMazDRjIHSkRI/VOYbEhunk5qVCY73YXL7jR+ovHd2SiK31RVK5YslI6JUVHH//jKiKGpb kSrmvrhQhdXahaSjGX7JKlqnzaOZvSln/TQjzkFJbrExv6bHBS6Dh6oS4ItB4iC0Lt+TCLwV Dn16xrEfJiNqEdj266qIF2TEKwAXvm4RhDcAPrYOi4VDK4C1S82rkQYAq56XifmIhNgNB37b pbwQTFwDsMWz4O0SERGwcWDYy0HEATg82oHwHMxdpL99ABX4OJxxTXoZJXZCS4kFlAAMw4mT 0NYSKQwbQ+DMvx7vMF8iDVqargOeAbfEUl8jIswKha6JOkRYLhi63/WvL/q3w73KUfCtpch7 URFRDuDwYJe3FCcCYe/tCbQSQOumLutmn3WTTzAlwHFnsVjgWPiwflokcBK85XFIBI6CNaVu qcCJcPr1HLAB7AmIUOkvxukprY6lc+LYHMpgoJm4/fF6rSmeVpmbgfclhOFt4LuDdAICA6Q/ fuY6q5SJqTy2QO8EYRhChuBdwKyUBZwzqgo0FKvJZsw6mnWCaG7W56aGIRCOGowGmgzGFR6T UoarqIKLNGNcs23DUDIUn006pJQRaspEX6DpXJpZU7djGAnxagk3IJCh1XT+ea3OtCEjmK8T QMyfK8/iPTibS+lZrVrQ+0BUeCj+R8wJBC9ozIb17NornwKh3FpBOM3H/bk/sJ6e4ooRrrjn KMMXm6gNKfwyKLNmRv+E9dWT7uyA7qhldY2HnS91y9WOwped81VzH++SdpvUtbL4rbXbh5VH 3In/cLMuq7lioea0w5JS0dm9Y9do4oPIwyfSY4wkrCxS9rZb0mzx/SFXxlLtQQHp45Pb6wfD fGKSL/VkeqZWjtlPVWXklbduOdL+IjX6UW9WFYmyGmrfHhHDUv8BEpTcmcADAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/uVw0XNR95XF5RU_CecGMkG54yFA Cc: OAuth WG Subject: Re: [OAUTH-WG] AC4 and what does it solve? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 18:29:11 -0000 ------=_NextPart_000_0007_01CF7049.FFBC0770 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Phil & Mike, Would it possible to write this as a separate "profile" of Connect and/or UMA? The reason I ask is because a somewhat standalone document could be useful in other deployment scenarios, such as an Enterprise use-case, where some minimal OAuth2.0 "awareness" exists. In this case, I'm thinking specifically of a Kerberos KDC server being able to return a signed/encrypted Claim (JWT) that reports the LOA value of the authentication instance (SP800-63-1 already identifies some Kerberos "levels"). The claim could then be consumed by a Connect OP or UMA AM/AS (without the OP or AS necessarily being a KDC themselves), or other downstream SPs. /thomas/ ____________________________________________ From: Bill Mills [mailto:wmills_92105@yahoo.com]=20 Sent: Thursday, May 15, 2014 2:11 PM To: Mike Jones; Phil Hunt; Thomas Hardjono Cc: OAuth WG Subject: Re: [OAUTH-WG] AC4 and what does it solve? The "re-auth" problem is an interesting one, the question of how does the client know if the user new authentication matches the previous one for something like mailbox access? =A0What happens if the end user doesn't auth as the same user? =A0If you really need this I think Connect solves this well, and OAuth is currently ocmpletely silent on this.=A0 =A0I don't think the userID indication to the client really does what we want. =A0If we want to do this in OAuth I think it would be better to hand the expired token back to the AS and say "this is the user I expect" and have the AS fail if that doesn't match. -bill On Thursday, May 15, 2014 9:54 AM, Mike Jones wrote: The "acr" claim (authentication context class reference) and the "acr_values" request parameter are explicitly modelled on the SAML authentication context work, but without the more complicated parts that didn't work out well in practice.=A0 In this case, the request is just an ordered list of requested "acr" values.=A0 Some of those values might be level numbers, but they also can and will be URNs such as "urn:mace:incommon:iap:silver" or "urn:mace:incommon:iap:bronze".=A0 In fact, the same values can be used as are used with SAML, if it makes sense in the application context. Phil, I don't understand why you're saying re-auth would be any different with full Connect than with AC4.=A0 The re-auth request would be the same - an OAuth authorization request using prompt=3Dnone - in both cases. =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 Cheers, =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Thursday, May 15, 2014 9:43 AM To: Thomas Hardjono Cc: OAuth WG Subject: Re: [OAUTH-WG] AC4 and what does it solve? Thomas, The intent was to be compatible with Connect (by request) but to solve only the authentication issue.=A0 That would explain the overlap with UMA. The issue (or bug?) we face is that OAuth Clients who continue to use 6749 alone, aren't really authenticating users. More importantly there is the question that has emerged over the past year about whether the client should know and be able to request authentication techniques and or levels.=A0 There is a demarcation issue to sort out. There is also the re-authen requirement that happens a lot where clients wish to elevate assurance level some how and may want to access a resource (not related to user profile).=A0 In the re-auth case, you know the users profile, you just want to confirm is this really Thomas?=A0 Just using OpenID means a much more complicated set of requests if only because everything has to be done twice. Regarding AuthnContext, I understand the same issue happened and the model chosen (for assurance) didn't work. I don't want to repeat past sins (as Brian says). I believe LoA was the solution to the problem, but I think Mike wants to talk some more about it - which is why it is in draft 02.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com On May 15, 2014, at 9:14 AM, Thomas Hardjono wrote: >=20 > Phil, >=20 > I also just read draft-hunt-oauth-v2-user-a4c-02. > This proposal sounds awfully close to what UMA is doing for consent=20 > management. >=20 > The Resource Owner (RO) in UMA has the option to set access control=20 > policy (including expected the authentication LOA of the user/client).=20 > The RO also has the option to require the Client/User to provide=20 > Claims regarding both entities (UMA distinguishes between the Client=20 > and the Human person using the Client). UMA relies on OpenID-Connect=20 > OP to provide the Claims. >=20 > btw. is your intention to create something akin to AuthnContext in=20 > SAML2.0? >=20 > Best. >=20 > /thomas/ >=20 > ____________________________________________ >=20 >=20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Bill Mills > Sent: Thursday, May 15, 2014 11:51 AM > To: OAuth WG > Subject: [OAUTH-WG] AC4 and what does it solve? >=20 > I'm reading the AC4 draft and I want to understand the problems it's=20 > actually trying to solve, which isn't as clear as it could be in the=20 > prose.=A0 It looks like it's extending OAuth to: >=20 > 1) Allowing the client to specify a desired authentication level. > 2) Giving the client an opaque identifier to differentiate users. > 3) Telling the client what level of authentication was used. >=20 > Do I have this right? >=20 > Thanks, >=20 > -bill > _______________________________________________ > 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 ------=_NextPart_000_0007_01CF7049.FFBC0770 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRYzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG+zCCBeOgAwIBAgIQZinWIcJoBXWy amTeGLwOXDANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTQwMzEzMDAwMDAwWhcNMTUwMzE0MjM1OTU5WjCBwjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM5NDcyMDUzMDM3NzEfMB0GCSqGSIb3 DQEJARYQaGFyZGpvbm9AbWl0LmVkdTEPMA0GA1UECwwGUy9NSU1FMR4wHAYDVQQLDBVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHTAbBgNVBAoM FFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAldwe JSLJ1cE66HSP0U5B226vuOF+DaQknIDJ/NkcRY32lYORq41PkQZ8i6sA5OuNJsNFmsh8+2/Y27jt txJ6D0k0mao5UMWB/EP1yxcTz0d13F4ZM2k5MniihLjrKMNnJWhdgrnu2gaCWN6qsBYZdqQLmfTI juGi0nqDQxNhzCM2RWw84CM6Mjp3FepY/ElvZ6qs1ErqPHBHAH0u5B9G07R1NNYj3Zthlwr+tefl Wnz0vgTQOrehCXoY3OhverIY6LsfX8k70jj8BO1s496grGga9IaEBEG+xeX/MRln5dJwGJidhgm3 u1OF0AHvLdmLuM/13UBJzljauuJ67j6R3QIDAQABo4IDBTCCAwEwDAYDVR0TAQH/BAIwADAOBgNV HQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQf qxJcVHYXcktkA9hu2yxr2cel7jAbBgNVHREEFDASgRBoYXJkam9ub0BtaXQuZWR1MB8GA1UdIwQY MBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUF BzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMl MjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIw T1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1h bnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0 aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQ oE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVm MDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8v d3d3LnN5bWF1dGguY29tL3JwYTArBgpghkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGGx85v FgUxMDkyMjA5BgpghkgBhvhFARAFBCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhW MGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQBU+20ff1cQSUmPgcdmRkvjK2xNG9Pq3ZCcxz/t jsZ/MY0x5NyVgg/Ko0tCoFkCSPB2uUiNGoqJDsXeaGwJ2s4kcynVo84uHK1bi2ZfUgK7eLT5ib4F IQ4cwxqG12sA8J1N0p8nLbkC8zm7eI0rrumZcrla+M4oyJNp8wpUFlds4EsOAxpxgR5sGxG2FIWq I75dE2PQdRNAzi35J00ZXYb5csaw5Upv0acZ/WzMrw5JVJXDufU1h4bi8TcRhuqJ1hkBrhjL1Ajr cnAX1QH7ta9AuUGWR76VpxN1vQ4Fn70IguzJF54kddeSv88lce9MhxX9rLE/oHFf6YrdoZ9qQCnZ MYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEc0AhBmKdYhwmgFdbJqZN4YvA5cMAkGBSsOAwIaBQCgggKrMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDUxNTE4Mjg1NFowIwYJKoZIhvcNAQkE MRYEFKySkTI0GVZMBtucHA1mZN718CIJMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEq MAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcG BSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQC AzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBmKdYhwmgFdbJq ZN4YvA5cMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEGYp1iHCaAV1smpk3hi8DlwwDQYJKoZIhvcNAQEB BQAEggEATdyy2CIEUMqQfOPCHbPd44Q/dsmtO1Y0HeWAzWEKAJTStvk9fgZek+C4hNcQPiM8HSkC iVikl3S4YlP61JQ56AxXZrrOR7dL2tcR97BURPGUOwab/pGghMUNk0oONik0dlPG2lutDHKoBpci 0tZeBo02kfE58EsCIDazJR9Wti7RRJU5yNlhCRX9ULzyJMfXIVTE6VBFEDU6M13vefq7c2KiQOZo V+9HW+GCBw+CV+BHeS25QRwB86oj+MGEVOOreOKWXx4vsk8Vnwam+3sOJuEJbBbvI7BmkQWcuMz4 vmST7pF3ct01qZoiIYTb4EMY3KPAF3HDzVcUIVqbVrj58gAAAAAAAA== ------=_NextPart_000_0007_01CF7049.FFBC0770-- From nobody Thu May 15 12:32:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05511A0314 for ; Thu, 15 May 2014 12:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 KQNv_t-ZOFvn for ; Thu, 15 May 2014 12:32:15 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B5C1A005A for ; Thu, 15 May 2014 12:32:14 -0700 (PDT) Received: from DM2PR04CA009.namprd04.prod.outlook.com (10.141.96.19) by BL2PR04MB851.namprd04.prod.outlook.com (10.242.197.155) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 15 May 2014 19:32:03 +0000 Received: from BN1BFFO11FD019.protection.gbl (2a01:111:f400:7c10::1:134) by DM2PR04CA009.outlook.office365.com (2a01:111:e400:2428::19) with Microsoft SMTP Server (TLS) id 15.0.944.11 via Frontend Transport; Thu, 15 May 2014 19:32:03 +0000 Received: from ct11msg01.am.mot-solutions.com (192.160.210.20) by BN1BFFO11FD019.mail.protection.outlook.com (10.58.144.82) with Microsoft SMTP Server (TLS) id 15.0.939.9 via Frontend Transport; Thu, 15 May 2014 19:32:03 +0000 Received: from ct11msg01.am.mot-solutions.com (ct11vts03.am.mot.com [10.177.16.162]) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id s4FJW0Qp013210 for ; Thu, 15 May 2014 14:32:01 -0500 (CDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id s4FJW0m5013202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 15 May 2014 14:32:00 -0500 (CDT) Received: from DM2PR04MB735.namprd04.prod.outlook.com (10.141.177.17) by DM2PR04MB735.namprd04.prod.outlook.com (10.141.177.17) with Microsoft SMTP Server (TLS) id 15.0.934.12; Thu, 15 May 2014 19:31:59 +0000 Received: from DM2PR04MB735.namprd04.prod.outlook.com ([10.141.177.17]) by DM2PR04MB735.namprd04.prod.outlook.com ([10.141.177.17]) with mapi id 15.00.0934.000; Thu, 15 May 2014 19:31:59 +0000 From: Lewis Adam-CAL022 To: "oauth@ietf.org" Thread-Topic: HOTK/POP and id_tokens Thread-Index: Ac9wdFU/HUyzh1WMRGCxW55HqTluZQ== Date: Thu, 15 May 2014 19:31:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.179.150.36] x-forefront-prvs: 0212BDE3BE X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(15975445006)(20776003)(15202345003)(19609705001)(79102001)(64706001)(66066001)(80022001)(16236675002)(83072002)(74316001)(85852003)(50986999)(76576001)(18717965001)(76482001)(81542001)(92566001)(83322001)(101416001)(19580395003)(86362001)(74662001)(31966008)(74502001)(21056001)(81342001)(46102001)(19300405004)(99396002)(77982001)(77096999)(99286001)(54356999)(19625215002)(87936001)(33646001)(2656002)(4396001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR04MB735; H:DM2PR04MB735.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: Pass (: domain of motorolasolutions.com designates 192.160.210.20 as permitted sender) receiver=; client-ip=192.160.210.20; helo=ct11msg01.am.mot-solutions.com; Authentication-Results: spf=pass (sender IP is 192.160.210.20) smtp.mailfrom=Adam.Lewis@motorolasolutions.com; Content-Type: multipart/alternative; boundary="_000_f4b6a47f882b4088a88bf9088c41ad72DM2PR04MB735namprd04pro_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:192.160.210.20; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438001)(189002)(199002)(99396002)(77096999)(4396001)(54356999)(44976005)(83322001)(99286001)(83072002)(512954002)(85852003)(81542001)(81342001)(71186001)(2656002)(50986999)(33646001)(19625215002)(87936001)(84326002)(21056001)(19580395003)(76576001)(18717965001)(15202345003)(15975445006)(86362001)(92566001)(6806004)(64706001)(20776003)(31966008)(74662001)(74502001)(66066001)(80022001)(19300405004)(79102001)(16236675002)(46102001)(74316001)(77982001)(76482001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR04MB851; H:ct11msg01.am.mot-solutions.com; FPR:; MLV:sfv; PTR:ct11msg01.mot-solutions.com; MX:1; A:1; LANG:en; X-Forefront-PRVS: 0212BDE3BE X-OriginatorOrg: motorolasolutions.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wbIu00-cUbZivK61jaiO-7kx1JI Subject: [OAUTH-WG] HOTK/POP and id_tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 19:32:18 -0000 --_000_f4b6a47f882b4088a88bf9088c41ad72DM2PR04MB735namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Does the WG plan to include OIDC id_tokens within the scope of the HOTK/POP= work? I've scanned through all of the existing HOTK/POP drafts and none m= ake any reference to id_tokens. Is this effort going to be scoped strictly= to access tokens? I am at a cross road right now where I'm considering using id_tokens in lie= u of access_tokens within our API calls (as we were never using the access = tokens for authorization anyway, but rather had profiled the AT to look ide= ntical to an id_token for authentication, and now that OIDC is complete ...= you get the idea), ... BUT ... we want HOTK/POP badly, and I don't want to= design ourselves out of leveraging that work as it materializes. -adam --_000_f4b6a47f882b4088a88bf9088c41ad72DM2PR04MB735namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Does the WG plan to include OIDC id_tokens within th= e scope of the HOTK/POP work?  I’ve scanned through all of the e= xisting HOTK/POP drafts and none make any reference to id_tokens.  Is = this effort going to be scoped strictly to access tokens? 

 

I am at a cross road right now where I’m consi= dering using id_tokens in lieu of access_tokens within our API calls (as we= were never using the access tokens for authorization anyway, but rather ha= d profiled the AT to look identical to an id_token for authentication, and now that OIDC is complete … you get= the idea), … BUT … we want HOTK/POP badly, and I don’t w= ant to design ourselves out of leveraging that work as it materializes.

 

 

-adam

--_000_f4b6a47f882b4088a88bf9088c41ad72DM2PR04MB735namprd04pro_-- From nobody Thu May 15 14:01:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364AF1A0124 for ; Thu, 15 May 2014 14:00:59 -0700 (PDT) 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 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 Q89jN-OLmbpv for ; Thu, 15 May 2014 14:00:57 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FBFF1A00E5 for ; Thu, 15 May 2014 14:00:56 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id a1so3976710wgh.3 for ; Thu, 15 May 2014 14:00:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=2sObtdOe1rlMFYriLQdPFmxRTAP/feINUXIXUzXYD1A=; b=QKw5z/h4/3nA8+Otn7mHyZpvNqxq9GHPDoirv7zMFM5oXQw0oRDToiugqShi9X8A8o QzNrVX/XTkD0SDTxiXBi3SswFuayc1dABl4rXSpXQzAgTQUCc+s0F2AVoHHaPSJJzbTt lIafSwbTyDeEVoz/fUakRLdsPlYPuJZnSrGVi9O30eI6IQDSYnqLe9vVs9/5YDCwaba0 z09DGAdxFToJtVztEYaTPcy7oIL80exyyz8tYRqBj7xRM/rygttzrHKwbihuh7Capi0T jNRp8knpCE+1j/fo/39uTX0qlOTYdU5WZAzoNL904cls1p7D4AJYLfxpb4cSS2yEuDtb Qx8Q== X-Gm-Message-State: ALoCoQkqmScWFwUYpqrGWAKMudv32kYdkhDqzw3oFI3qSABku37yV1ti2oRL58RJ6A5ddIFQzKJp X-Received: by 10.180.8.66 with SMTP id p2mr33175396wia.37.1400187648245; Thu, 15 May 2014 14:00:48 -0700 (PDT) Received: from [100.71.131.242] (ip-109-43-3-242.web.vodafone.de. [109.43.3.242]) by mx.google.com with ESMTPSA id l9sm11792973wic.21.2014.05.15.14.00.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 May 2014 14:00:46 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4E1D199E-2C29-4085-B5A9-1097DC5289F5; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <95FC2B2E-2FE2-4172-AF67-A109E9129C33@ve7jtb.com> X-Mailer: iPhone Mail (11D201) From: John Bradley Date: Thu, 15 May 2014 23:00:45 +0200 To: Lewis Adam-CAL022 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/H_HB6oCiNnOn7im9TGuUN_h0zFg Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] HOTK/POP and id_tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 21:00:59 -0000 --Apple-Mail-4E1D199E-2C29-4085-B5A9-1097DC5289F5 Content-Type: multipart/alternative; boundary=Apple-Mail-E03B75B3-6C91-4161-8C16-71868A9B5E52 Content-Transfer-Encoding: 7bit --Apple-Mail-E03B75B3-6C91-4161-8C16-71868A9B5E52 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The key for pop via the browser is different than the one between the client= and the RS. The key representation is likely to be the same but presentme= nt will likely be different.=20 This WG is focusing on OAuth tokens and assertion flows.=20 Getting a id_token with HoK for use in an assertion flow may be done in JOSE= or Connect.=20 Nothing is impossible if the WG rechargers and wants to do it as part of JWT= .=20 Sent from my iPhone > On May 15, 2014, at 9:31 PM, Lewis Adam-CAL022 wrote: >=20 > Hi, > =20 > Does the WG plan to include OIDC id_tokens within the scope of the HOTK/PO= P work? I=E2=80=99ve scanned through all of the existing HOTK/POP drafts an= d none make any reference to id_tokens. Is this effort going to be scoped s= trictly to access tokens?=20 > =20 > I am at a cross road right now where I=E2=80=99m considering using id_toke= ns in lieu of access_tokens within our API calls (as we were never using the= access tokens for authorization anyway, but rather had profiled the AT to l= ook identical to an id_token for authentication, and now that OIDC is comple= te =E2=80=A6 you get the idea), =E2=80=A6 BUT =E2=80=A6 we want HOTK/POP bad= ly, and I don=E2=80=99t want to design ourselves out of leveraging that work= as it materializes. > =20 > =20 > -adam > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-E03B75B3-6C91-4161-8C16-71868A9B5E52 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The key for pop via the browser is dif= ferent than the one between the client and the RS.   The key representa= tion is likely to be the same but presentment will likely be different. = ;

This WG is focusing on OAuth tokens and assertion= flows. 

Getting a id_token with HoK for use i= n an assertion flow may be done in JOSE or Connect. 

Nothing is impossible if the WG rechargers and wants to do it as part= of JWT. 

Sent from my iPhone

On May 15, 2014, at 9= :31 PM, Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> wrote:

=

Hi,

 

Does the WG plan to include OIDC id_tokens within the= scope of the HOTK/POP work?  I=E2=80=99ve scanned through all of the e= xisting HOTK/POP drafts and none make any reference to id_tokens.  Is t= his effort going to be scoped strictly to access tokens? 

 

I am at a cross road right now where I=E2=80=99m cons= idering using id_tokens in lieu of access_tokens within our API calls (as we= were never using the access tokens for authorization anyway, but rather had= profiled the AT to look identical to an id_token for authentication, and now that OIDC is complete =E2=80=A6 you ge= t the idea), =E2=80=A6 BUT =E2=80=A6 we want HOTK/POP badly, and I don=E2=80= =99t want to design ourselves out of leveraging that work as it materializes= .

 

 

-adam

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-E03B75B3-6C91-4161-8C16-71868A9B5E52-- --Apple-Mail-4E1D199E-2C29-4085-B5A9-1097DC5289F5 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwNTE1MjEwMDQ2WjAjBgkqhkiG9w0BCQQxFgQUIGB+UvXgOuV02B9o Tm2aa+nfAHowgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAsdu6xQ8WOAMZB/BU7ax295vOwoKjEXZjU73JcATtQjV3ik4+ kkb5InS1UrOvc2bl6cVXlyYraAiRqQl74CQk0P1QSUD1CHua8tsbsmr3h/GviC2kTlih70QIb3N9 ZBZ01RGlEaVVtLswiYTPI+tV25SuH2Wcaq0t5KZd7CDq5X7GkPXSOihBoGXzzrsyprNaDLwRIrf7 sM3SI1gSEiQTiNhgjpTI5FV2hCV/U1ZFdcdX1Rc6hacrDtw1xo2mO3E1veHXvRWowhihQG6ew6gn Y6TaPHKo5fljgR52Lpc+y7PpkFiZG/TS2ExBtYJq4AUKIe7ChUMSoaaF7KRfbz1W4gAAAAAAAA== --Apple-Mail-4E1D199E-2C29-4085-B5A9-1097DC5289F5-- From nobody Fri May 16 06:10:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D371A0230 for ; Fri, 16 May 2014 06:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 6Ir7BgzQFFIh for ; Fri, 16 May 2014 06:10:20 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151B61A005D for ; Fri, 16 May 2014 06:10:19 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id ec20so1942202lab.12 for ; Fri, 16 May 2014 06:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ogFNVJ8p7+e2sSz6nvpZWVr+l5wV465+sHyo4hTZjdY=; b=sCIrbADhUmFHFX1lIq7jXd+ztIa8k+KNbPQCE0GtN+Mtaf+375nlFk2YByJhwitkUk j42liLAcsKc1tfTa0yB/I4NsYVS5WsLCbN4x2EMPOvDFW5GRM0rH57E2ridx2epQxDvB o/A9dXXpVi1gxumF5pQdPelkIVQ+gJtVudZlReIYwe73Hx4BIbm74Pz0QsT7k8DmLyuy PO5oz/pLHXI+1fYyk/q12VNSiMEnlRdzSGlo2EyvTUOjiCeRM5PsQ3ROSVU/9t6jVSAw BouJhiAac3lmso7CiYeRXmR9y6731t6oCspwqB3g4OQALxj6U5u8/fouJd9+vist30bs E+lQ== MIME-Version: 1.0 X-Received: by 10.112.158.101 with SMTP id wt5mr1260056lbb.77.1400245811136; Fri, 16 May 2014 06:10:11 -0700 (PDT) Received: by 10.112.105.134 with HTTP; Fri, 16 May 2014 06:10:11 -0700 (PDT) In-Reply-To: References: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> Date: Fri, 16 May 2014 22:10:11 +0900 Message-ID: From: Nat Sakimura To: Brian Campbell Content-Type: multipart/alternative; boundary=001a11c33f702bd24604f984221a Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/RAvnnTgrpntgI_KHaLW530TnA50 Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 13:10:25 -0000 --001a11c33f702bd24604f984221a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Now that I cannot remember what limit we were hitting, it might be a good idea to remove the constraint and see if anyone protests. What do you think? Nat 2014-05-14 20:46 GMT+09:00 Brian Campbell : > That too would suggest that the length limit be on code_challenge because > that's the parameter that will be on URIs getting passed around. The > code_verifier is sent directly in the POST body from client to AS. > > > On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura wrote= : > >> +1 for octet. We used to have "bytes" in JW* so I used "bytes" here, >> while at the same time complaining in Jose that it should be "octet". JW= * >> changed to "octet" but I failed to sync with it in the last few edits. >> >> I do not quite remember which platform, but the reason for the limit was >> that some platform had some limitations as to the length of the sting to= be >> passed to it through URI and we did not want the challenges to be trunca= ted >> by that limit. >> >> Best, >> >> Nat >> >> >> 2014-05-13 6:56 GMT+09:00 Brian Campbell : >> >> And it'd give the AS some direct guidance on protecting itself from craz= y >>> long code_challenge values rather than relying on the client not to do >>> something creative. >>> >>> >>> On Mon, May 12, 2014 at 3:54 PM, Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>>> Right but that's why I'm asking why not just put the limit on >>>> code_challange rather than inferring it from code_verifyer + challenge >>>> algorithm, which probably bounds it but doesn't necessarily do so? It'= s not >>>> a big deal but would read more clearly, I think. >>>> >>>> >>>> On Mon, May 12, 2014 at 3:48 PM, John Bradley wrote= : >>>> >>>>> I think octets is more consistent with other JW* and OAuth specs. >>>>> >>>>> The code_challange is the same length as the code_verifyer or is a >>>>> hash of the code_verifyer so likely smaller than 128octets (43 ish fo= r >>>>> base64 256 bit) >>>>> >>>>> Limiting the code_verifyer size sets the upper bound for >>>>> code_challange, unless someone comes up with a really creative code >>>>> challenge algorithm. >>>>> >>>>> I will talk to nat about changing it to octets when I see him tomorro= w. >>>>> >>>>> John B. >>>>> >>>>> On May 12, 2014, at 11:15 PM, Derek Atkins wrote: >>>>> >>>>> > Brian Campbell writes: >>>>> > >>>>> >> I notice that code_verifier is defined as "high entropy >>>>> cryptographic random >>>>> >> string of length less than 128 bytes" [1], which brought a few >>>>> questions and >>>>> >> comments to mind. So here goes: >>>>> >> >>>>> >> Talking about the length of a string in terms of bytes is always >>>>> potentially >>>>> >> confusing. Maybe characters would be an easier unit for people lik= e >>>>> me to wrap >>>>> >> their little brains around? >>>>> > >>>>> > It depends if it really is characters or bytes. For example there >>>>> are >>>>> > many multi-byte UTF-8 characters, so if it really is bytes then >>>>> saying >>>>> > characters is wrong because it could overflow. So let's make sure = we >>>>> > know what we're talking about. Historically, if we're talking byte= s >>>>> the >>>>> > IETF often uses the phrase "octets". Would that be less confusing? >>>>> > >>>>> >> Why are we putting a length restriction on the code_verifier >>>>> anyway? It seems >>>>> >> like it'd be more appropriate to restrict the length of the >>>>> code_challenge >>>>> >> because that's the thing the AS will have to maintain somehow >>>>> (store in a DB >>>>> >> or memory or encrypt into the code). Am I missing something here? >>>>> >> >>>>> >> Let me also say that I hadn't looked at this document since its >>>>> early days in >>>>> >> draft -00 or -01 last summer but I like the changes and how it's >>>>> been kept >>>>> >> pretty simple for the common use-case while still allowing for >>>>> crypto agility/ >>>>> >> extension. Nice work! >>>>> >> >>>>> >> [1] >>>>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 >>>>> > >>>>> > -derek >>>>> > >>>>> >> _______________________________________________ >>>>> >> OAuth mailing list >>>>> >> OAuth@ietf.org >>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>> > >>>>> > -- >>>>> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >>>>> > Member, MIT Student Information Processing Board (SIPB) >>>>> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >>>>> > warlord@MIT.EDU PGP key available >>>>> >>>>> >>>> >>>> >>>> -- >>>> [image: Ping Identity logo] >>>> Brian Campbell >>>> Portfolio Architect >>>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connec= t >>>> with us=E2=80=A6 [image: twitter logo] [image: >>>> youtube logo] [image: >>>> LinkedIn logo] [image: >>>> Facebook logo] [image: >>>> Google+ logo] [ima= ge: >>>> slideshare logo] [image: >>>> flipboard logo] [image: rss feed icon] >>>> [image: Register for Cloud Identity Summit 2014 | Modern Identity >>>> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >>>> >>>> >>> >>> >>> -- >>> [image: Ping Identity logo] >>> Brian Campbell >>> Portfolio Architect >>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect >>> with us=E2=80=A6 [image: twitter logo] [image: >>> youtube logo] [image: >>> LinkedIn logo] [image: >>> Facebook logo] [image: >>> Google+ logo] [imag= e: >>> slideshare logo] [image: >>> flipboard logo] [image: rss feed icon] >>> [image: Register for Cloud Identity Summit 2014 | Modern Identity >>> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] >>> >>> >>> _______________________________________________ >>> 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 >> > > > > -- > [image: Ping Identity logo] > Brian Campbell > Portfolio Architect > @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect > with us=E2=80=A6 [image: twitter logo] [image: > youtube logo] [image: > LinkedIn logo] [image: Facebook > logo] [image: Google+ logo] [image: > slideshare logo] [image: > flipboard logo] [image: rss feed icon] > [image: Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c33f702bd24604f984221a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Now that I cannot remember what limit we were hitting, it = might be a good idea to remove the constraint and see if anyone protests.= =C2=A0

What do you think?=C2=A0

Nat


2014-05-14 20= :46 GMT+09:00 Brian Campbell <bcampbell@pingidentity.com><= /span>:
That too would suggest that= the length limit be on code_challenge because that's the parameter tha= t will be on URIs getting passed around. The code_verifier is sent directly= in the POST body from client to AS.

On Tue, May 13, 2014 at 12:52 AM, Nat Saki= mura <sakimura@gmail.com> wrote:
+1 for octet. We used to ha= ve "bytes" in JW* so I used "bytes" here, while at the = same time complaining in Jose that it should be "octet". JW* chan= ged to "octet" but I failed to sync with it in the last few edits= .=C2=A0

I do not quite remember which platform, but the reason for t= he limit was that some platform had some limitations as to the length of th= e sting to be passed to it through URI and we did not want the challenges t= o be truncated by that limit.=C2=A0

Best,=C2=A0

Nat


2014-05-13 6:56 = GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:

And it'd give the AS so= me direct guidance on protecting itself from crazy long code_challenge valu= es rather than relying on the client not to do something creative.


On Mon, May 12, 2014 at 3:54 PM, Brian Campb= ell <bcampbell@pingidentity.com> wrote:
Right but that's why I'm asking why not just put t= he limit on code_challange rather than inferring it from code_verifyer + ch= allenge algorithm, which probably bounds it but doesn't necessarily do = so? It's not a big deal but would read more clearly, I think.


On Mon, May 12, 2014 at 3:48 PM, John Bradley <ve7jtb@ve7jtb.com>= ; wrote:
I think octets is more consistent with other= JW* and OAuth specs.

The code_challange is the same length as the code_verifyer or is a hash of = the code_verifyer so likely smaller than 128octets (43 ish for base64 256 b= it)

Limiting the code_verifyer size sets the upper bound for code_challange, un= less someone comes up with a really creative code challenge algorithm.

I will talk to nat about changing it to octets when I see him tomorrow.

John B.

On May 12, 2014, at 11:15 PM, Derek Atkins <warlord@MIT.EDU> wrote:

> Brian Campbell <bcampbell@pingidentity.com> writes:
>
>> I notice that code_verifier is defined as "high entropy crypt= ographic random
>> string of length less than 128 bytes" =C2=A0[1], which brough= t a few questions and
>> comments to mind. So here goes:
>>
>> Talking about the length of a string in terms of bytes is always p= otentially
>> confusing. Maybe characters would be an easier unit for people lik= e me to wrap
>> their little brains around?
>
> It depends if it really is characters or bytes. =C2=A0For example ther= e are
> many multi-byte UTF-8 characters, so if it really is bytes then saying=
> characters is wrong because it could overflow. =C2=A0So let's make= sure we
> know what we're talking about. =C2=A0Historically, if we're ta= lking bytes the
> IETF often uses the phrase "octets". =C2=A0Would that be les= s confusing?
>
>> Why are we putting a length restriction on the code_verifier anywa= y? It seems
>> like it'd be more appropriate to restrict the length of the co= de_challenge
>> because that's the thing the AS will have to maintain somehow = (store in a DB
>> or memory or encrypt into the code). Am I missing something here?<= br> >>
>> Let me also say that I hadn't looked at this document since it= s early days in
>> draft -00 or -01 last summer but I like the changes and how it'= ;s been kept
>> pretty simple for the common use-case while still allowing for cry= pto agility/
>> extension. Nice work!
>>
>> [1] http://tools.ietf.org/html/draft-sakimu= ra-oauth-tcse-03#section-3.3
>
> -derek
>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>
> --
> =C2=A0 =C2=A0 =C2=A0 Derek Atkins, SB '93 MIT EE, SM '95 MIT M= edia Laboratory
> =C2=A0 =C2=A0 =C2=A0 Member, MIT Student Information Processing Board = =C2=A0(SIPB)
> =C2=A0 =C2=A0 =C2=A0 URL: http://web.mit.edu/warlord/ =C2=A0 =C2=A0PP-ASEL-IA =C2= =A0 =C2=A0 N1NWH
> =C2=A0 =C2=A0 =C2=A0 warlord@MIT.EDU =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PGP key available




-= -
3D"Ping =09
Brian Campbell
= Portfolio Architect
=09
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register




--
3D"Ping =09
Brian Campbell
= Portfolio Architect
=09
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register


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




--
Nat Sakimura (=3Dnat)
Chairman, OpenI= D Foundation
http= ://nat.sakimura.org/
@_nat_en



--
3D"Ping =09
Brian Campbell
= Portfolio Architect
=09
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register




--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en
--001a11c33f702bd24604f984221a-- From nobody Fri May 16 06:41:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609051A0062 for ; Fri, 16 May 2014 06:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 vFl3MPy5xx9z for ; Fri, 16 May 2014 06:41:50 -0700 (PDT) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B50CA1A0069 for ; Fri, 16 May 2014 06:41:49 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id b57so1575965eek.27 for ; Fri, 16 May 2014 06:41:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Re3SYpUcafNoaDte4WlYArQJfHFaUoAYIBwpiuwjrik=; b=MAT9I4pcBQXK7FUxjGwYDVnIPTCDdtaYcyrpFgldIOJimRU+hhQmZaF0g5ZmmhuO+4 N210+CVD8IvybjBXKn/mgEap4JvHRufG4BPj3KJL9idEGSAmZHKS47T3dBR1FS3wpBHD qPZvPQHqwHQZKtk+q/Oro1NNAhQ8ALxXDGzoJthCHM69b6b27l2QeTq4h5PAN/A8bQGt +IWo+adsFPJUQa1D99zdAtg1DiNCrJyWEmtCp8jcWqIbF8RbdD4fNAbzvLDob1PuqgjA RZ+cwozqwncOr/jnQ7DRtWRMezD/JHQTZ/bJ6Ul6HFJiBa1+wrEKKUFBP5iHe100XtMm hf2w== X-Gm-Message-State: ALoCoQnLNyn0pI1ovjKB139s2I22yMrqJ+5gKbdiUrQBLEHt7KZpMzHtl0ICU3riLtOBYVJsI9VQ X-Received: by 10.14.208.195 with SMTP id q43mr22884981eeo.42.1400247701168; Fri, 16 May 2014 06:41:41 -0700 (PDT) Received: from [10.105.255.211] (vlan105-gw1.ush2.tnib.de. [86.110.65.1]) by mx.google.com with ESMTPSA id e44sm20175351eeg.24.2014.05.16.06.41.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 May 2014 06:41:39 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CBAAAE58-35C2-4F99-ABAB-CB0A91AFB2FF" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: John Bradley In-Reply-To: Date: Fri, 16 May 2014 15:41:45 +0200 Message-Id: References: <21A361B0-4E8F-4DAB-9EEB-D48FBCBDFFED@ve7jtb.com> To: Nat Sakimura X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/i952Y7d5QQvCsBHWBNWP-6qrTTI Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 13:41:53 -0000 --Apple-Mail=_CBAAAE58-35C2-4F99-ABAB-CB0A91AFB2FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 =46rom the AS side you probably want to know what the max size you need = to store per code. On the call to the token endpoint it is a POST so size should not be an = issue. =20 On May 16, 2014, at 3:10 PM, Nat Sakimura wrote: > Now that I cannot remember what limit we were hitting, it might be a = good idea to remove the constraint and see if anyone protests.=20 >=20 > What do you think?=20 >=20 > Nat >=20 >=20 > 2014-05-14 20:46 GMT+09:00 Brian Campbell = : > That too would suggest that the length limit be on code_challenge = because that's the parameter that will be on URIs getting passed around. = The code_verifier is sent directly in the POST body from client to AS.=20= >=20 >=20 > On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura = wrote: > +1 for octet. We used to have "bytes" in JW* so I used "bytes" here, = while at the same time complaining in Jose that it should be "octet". = JW* changed to "octet" but I failed to sync with it in the last few = edits.=20 >=20 > I do not quite remember which platform, but the reason for the limit = was that some platform had some limitations as to the length of the = sting to be passed to it through URI and we did not want the challenges = to be truncated by that limit.=20 >=20 > Best,=20 >=20 > Nat >=20 >=20 > 2014-05-13 6:56 GMT+09:00 Brian Campbell : >=20 > And it'd give the AS some direct guidance on protecting itself from = crazy long code_challenge values rather than relying on the client not = to do something creative.=20 >=20 >=20 > On Mon, May 12, 2014 at 3:54 PM, Brian Campbell = wrote: > Right but that's why I'm asking why not just put the limit on = code_challange rather than inferring it from code_verifyer + challenge = algorithm, which probably bounds it but doesn't necessarily do so? It's = not a big deal but would read more clearly, I think. >=20 >=20 > On Mon, May 12, 2014 at 3:48 PM, John Bradley = wrote: > I think octets is more consistent with other JW* and OAuth specs. >=20 > The code_challange is the same length as the code_verifyer or is a = hash of the code_verifyer so likely smaller than 128octets (43 ish for = base64 256 bit) >=20 > Limiting the code_verifyer size sets the upper bound for = code_challange, unless someone comes up with a really creative code = challenge algorithm. >=20 > I will talk to nat about changing it to octets when I see him = tomorrow. >=20 > John B. >=20 > On May 12, 2014, at 11:15 PM, Derek Atkins wrote: >=20 > > Brian Campbell writes: > > > >> I notice that code_verifier is defined as "high entropy = cryptographic random > >> string of length less than 128 bytes" [1], which brought a few = questions and > >> comments to mind. So here goes: > >> > >> Talking about the length of a string in terms of bytes is always = potentially > >> confusing. Maybe characters would be an easier unit for people like = me to wrap > >> their little brains around? > > > > It depends if it really is characters or bytes. For example there = are > > many multi-byte UTF-8 characters, so if it really is bytes then = saying > > characters is wrong because it could overflow. So let's make sure = we > > know what we're talking about. Historically, if we're talking bytes = the > > IETF often uses the phrase "octets". Would that be less confusing? > > > >> Why are we putting a length restriction on the code_verifier = anyway? It seems > >> like it'd be more appropriate to restrict the length of the = code_challenge > >> because that's the thing the AS will have to maintain somehow = (store in a DB > >> or memory or encrypt into the code). Am I missing something here? > >> > >> Let me also say that I hadn't looked at this document since its = early days in > >> draft -00 or -01 last summer but I like the changes and how it's = been kept > >> pretty simple for the common use-case while still allowing for = crypto agility/ > >> extension. Nice work! > >> > >> [1] = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 > > > > -derek > > > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > warlord@MIT.EDU PGP key available >=20 >=20 >=20 >=20 > --=20 > =09 > Brian Campbell > Portfolio Architect > @ bcampbell@pingidentity.com > +1 720.317.2061 > Connect with us=85 > =20 >=20 >=20 >=20 >=20 > --=20 > =09 > Brian Campbell > Portfolio Architect > @ bcampbell@pingidentity.com > +1 720.317.2061 > Connect with us=85 > =20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 >=20 >=20 > --=20 > =09 > Brian Campbell > Portfolio Architect > @ bcampbell@pingidentity.com > +1 720.317.2061 > Connect with us=85 > =20 >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --Apple-Mail=_CBAAAE58-35C2-4F99-ABAB-CB0A91AFB2FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 =46rom = the AS side you probably want to know what the max size you need to = store per code.

On the call to the token endpoint = it is a POST so size should not be an issue. =  


On May 16, = 2014, at 3:10 PM, Nat Sakimura <sakimura@gmail.com> = wrote:

Now that I cannot remember what limit we = were hitting, it might be a good idea to remove the constraint and see = if anyone protests. 

What do you = think? 

Nat


2014-05-14 = 20:46 GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:
That = too would suggest that the length limit be on code_challenge because = that's the parameter that will be on URIs getting passed around. The = code_verifier is sent directly in the POST body from client to AS.


On Tue, May 13, = 2014 at 12:52 AM, Nat Sakimura <sakimura@gmail.com> wrote:
+1 = for octet. We used to have "bytes" in JW* so I used "bytes" here, while = at the same time complaining in Jose that it should be "octet". JW* = changed to "octet" but I failed to sync with it in the last few = edits. 

I do not quite remember which platform, but the reason = for the limit was that some platform had some limitations as to the = length of the sting to be passed to it through URI and we did not want = the challenges to be truncated by that limit. 
=

Best, 

Nat


2014-05-13 = 6:56 GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:

And = it'd give the AS some direct guidance on protecting itself from crazy = long code_challenge values rather than relying on the client not to do = something creative.


On Mon, May 12, 2014 at 3:54 PM, Brian = Campbell <bcampbell@pingidentity.com> = wrote:
Right but that's why I'm asking why not just put the = limit on code_challange rather than inferring it from code_verifyer + = challenge algorithm, which probably bounds it but doesn't necessarily do = so? It's not a big deal but would read more clearly, I think.


On Mon, May 12, 2014 at 3:48 PM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
I think octets is more = consistent with other JW* and OAuth specs.

The code_challange is the same length as the code_verifyer or is a hash = of the code_verifyer so likely smaller than 128octets (43 ish for base64 = 256 bit)

Limiting the code_verifyer size sets the upper bound for code_challange, = unless someone comes up with a really creative code challenge = algorithm.

I will talk to nat about changing it to octets when I see him = tomorrow.

John B.

On May 12, 2014, at 11:15 PM, Derek Atkins <warlord@MIT.EDU> = wrote:

> Brian Campbell <bcampbell@pingidentity.com> writes:
>
>> I notice that code_verifier is defined as "high entropy = cryptographic random
>> string of length less than 128 bytes"  [1], which brought = a few questions and
>> comments to mind. So here goes:
>>
>> Talking about the length of a string in terms of bytes is = always potentially
>> confusing. Maybe characters would be an easier unit for people = like me to wrap
>> their little brains around?
>
> It depends if it really is characters or bytes.  For example = there are
> many multi-byte UTF-8 characters, so if it really is bytes then = saying
> characters is wrong because it could overflow.  So let's make = sure we
> know what we're talking about.  Historically, if we're talking = bytes the
> IETF often uses the phrase "octets".  Would that be less = confusing?
>
>> Why are we putting a length restriction on the code_verifier = anyway? It seems
>> like it'd be more appropriate to restrict the length of the = code_challenge
>> because that's the thing the AS will have to maintain somehow = (store in a DB
>> or memory or encrypt into the code). Am I missing something = here?
>>
>> Let me also say that I hadn't looked at this document since its = early days in
>> draft -00 or -01 last summer but I like the changes and how = it's been kept
>> pretty simple for the common use-case while still allowing for = crypto agility/
>> extension. Nice work!
>>
>> [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#= section-3.3
>
> -derek
>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media = Laboratory
>       Member, MIT Student Information Processing = Board  (SIPB)
>       URL: http://web.mit.edu/warlord/   =  PP-ASEL-IA     N1NWH
>       warlord@MIT.EDU           =              PGP key available




-- =
3D"Ping =09
Brian Campbell
Portfolio = Architect
=09
= @ = bcampbell@pingidentity.com
= 3D"phone" = +1 = 720.317.2061
= Connect with us=85
= 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard
3D"Register




--
3D"Ping =09
Brian Campbell
Portfolio = Architect
=09
= @ = bcampbell@pingidentity.com
= 3D"phone" = +1 = 720.317.2061
= Connect with us=85
= 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard
3D"Register


_______________________________________________
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



--
3D"Ping =09
Brian Campbell
Portfolio = Architect
=09
= @ = bcampbell@pingidentity.com
= 3D"phone" = +1 = 720.317.2061
= Connect with us=85
= 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard
3D"Register




-- =
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en